Chuyên gia Chuyển đổi số nội bộ - Trung tâm vận hành tối ưu - Khối Vận hành

1. Tổng quan vị trí

Đây là vị trí Chuyên gia chuyển đổi số nội bộ thuộc khối Vận hành, trọng tâm là phân tích quy trình nghiệp vụ, mô hình hóa, số hóa và kiểm soát việc triển khai các giải pháp nội bộ. Vai trò đóng vai trò cầu nối giữa nghiệp vụ, đơn vị vận hành và Công nghệ Thông tin.

Công việc trọng tâm gồm:

1. Khảo sát hiện trạng, tìm điểm tắc nghẽn và mô hình hóa quy trình.
2. Xây dựng tài liệu yêu cầu nghiệp vụ, câu chuyện người dùng và tiêu chí nghiệm thu.
3. Phối hợp Công nghệ Thông tin thiết kế giải pháp, kiểm soát thay đổi yêu cầu.
4. Tổ chức Kiểm thử Chấp nhận Người dùng, xử lý lỗi và nghiệm thu nghiệp vụ.
5. Xây dựng tài liệu hướng dẫn, câu hỏi và câu trả lời, đào tạo người dùng.
6. Đánh giá tác động thay đổi, lập kế hoạch quản trị thay đổi cho từng đề án.
7. Theo dõi mức độ sử dụng, phản hồi người dùng và cải tiến sau triển khai.

Điểm cần lưu ý: phần “Kinh nghiệm” ghi “N/A”, nhưng phần yêu cầu chi tiết nêu tối thiểu 04 năm kinh nghiệm về phân tích nghiệp vụ, quản trị quy trình hoặc tự động hóa. Ứng viên nên xem yêu cầu 04 năm là yêu cầu chính và xác nhận lại với đơn vị tuyển dụng nếu cần tình tiết có khác biệt.

2. Bản đồ năng lực cần đạt

3. Kỹ năng chuyên môn cần có

3.1. Phân tích nghiệp vụ và chuyển đổi quy trình sang số

Ứng viên cần thể hiện quy trình phân tích đầy đủ:

• Phỏng vấn người thực hiện và người sử dụng quy trình.
• Khảo sát tài liệu, dữ liệu và các điểm giao nhận.
• Lập quy trình hiện trạng, xác định thao tác thủ công, chờ đợi, nhập liệu lặp lại và điểm tắc nghẽn.
• Phân tích nguyên nhân bằng cách hỏi “tại sao” nhiều lần, kiểm tra dữ liệu thời gian thực hiện và tần suất lỗi.
• Xác định mục tiêu số hóa có thể đo lường như thời gian xử lý, tỷ lệ xử lý đúng hạn, số lần nhập liệu, tỷ lệ lỗi và mức độ sử dụng.
• Thiết kế quy trình mục tiêu, quy tắc tự động hóa và các trường hợp ngoại lệ.
• Cân bằch giữa tốc độ triển khai, trải nghiệm người dùng, chi phí và rủi ro kiểm soát.

3.2. BPMN

Ứng viên cần không chỉ biết ý nghĩa biểu tượng mà còn phải trình bày được cách sử dụng BPMN trong mô hình hóa nghiệp vụ thực tế:

• Phân vùng, làn bơi và ranh giới tổ chức.
• Sự kiện bắt đầu, kết thúc, trung gian và biên.
• Cổng quyết định, cổng song song và cổng dựa trên sự kiện.
• Hoạt động của người dùng, hệ thống hoặc bên thứ ba.
• Luồng thông thường, luồng ngoại lệ và quy trình chạy song song.
• Đối tượng dữ liệu và kho lưu trữ thông tin.
• Mức độ chi tiết phù hợp với đối tượng sử dụng: quản trị, phân tích nghiệp vụ và triển khai.

Nên chuẩn bị một ví dụ thể hiện rõ điểm kiểm soát, điểm giao hàng và điểm cần phê duyệt. Đây là điểm giúp ứng viên khác biệt với ứng viên chỉ biết vẽ hình.

3.3. BRD, câu chuyện người dùng và tiêu chí nghiệm thu

BRD — Business Requirements Document, Tài liệu Yêu cầu Nghiệp vụ thường cần có:

• Bối cảnh, mục tiêu và phạm vi dự án.
• Quy trình hiện trạng, điểm tắc nghẽn và nguyên nhân.
• Yêu cầu chức năng và yêu cầu phi chức năng.
• Vai trò người sử dụng và nhu cầu theo quyền.
• Quy tắc nghiệp vụ, điều kiện đầu vào, đầu ra và ngoại lệ.
• Yêu cầu kiểm soát phân quyền, kiểm toán và lưu giữ hồ sơ.
• Phụ thuộc dữ liệu, tích hợp và vận hành.
• Tiêu chí nghiệm thu và chỉ số đo lường thành công.
• Rủi ro, giả định, phụ thuộc và kế hoạch quản trị thay đổi.

Mỗi yêu cầu nên có mã định danh để truy vết từ nhu cầu nghiệp vụ đến câu chuyện người dùng, trường hợp kiểm thử, lỗi và quyết định nghiệm thu.

Câu chuyện người dùng có thể viết theo cấu trúc:

> Làm người <vai trò>, tôi muốn <khả năng>, để đạt <giá trị>.

Tiêu chí nghiệm thu nên dùng cấu trúc Given – When – Then, hoặc điều kiện – hành động – kết quả mong đợi, để kiểm thử được ngay. Nêu rõ dữ liệu đầu vào, điều kiện phải đáp ứng, kết quả dự kiến và xử lý ngoại lệ.

3.4. Kiểm thử Chấp nhận Người dùng

Ứng viên cần hiểu UAT không chỉ là “chạy thử theo kịch bản”, mà là xác nhận giải pháp phù hợp nhu cầu nghiệp vụ và có thể vận hành:

• Xác định phạm vi, mục tiêu và người tham gia kiểm thử.
• Phân biệt kiểm thử tích hợp, kiểm thử hệ thống và UAT.
• Chuẩn bị dữ liệu thử đại diện, bao gồm dữ liệu hợp lệ, không hợp lệ và ngoại lệ.
• Viết trường hợp kiểm thử theo yêu cầu và tiêu chí nghiệm thu.
• Phân loại lỗi theo mức độ nghiêm trọng và ưu tiên xử lý.
• Theo dõi lỗi, kiểm thử lại và quản lý biên bản nghiệm thu.
• Xác định điều kiện đạt, điều kiện chưa đạt và quyền ký nghiệm thu của bên nghiệp vụ.

3.5. Phân quyền, kiểm soát và kiểm toán

Đây là nội dung quan trọng vì giải pháp số hóa có thể làm thay đổi trách nhiệm, quyền hạn và dấu vết kiểm toán. Ứng viên cần nắm:

• Nguyên tắc quyền tối thiểu: chỉ cấp đúng quyền cần thiết.
• Phân tách nhiệm vụ: người lập không nên đồng thời phê duyệt hoặc hoàn tất giao dịch.
• Cơ chế phê duyệt bốn mắt đối với giao dịch nhạy cảm.
• Nhật ký thao tác, không thể chỉnh sửa và truy vết người thực hiện.
• Phê duyệt truy cập khẩn cấp và rà soát định kỳ.
• Kiểm soát dữ liệu đầu vào, dữ liệu phân quyền và thông tin nhạy cảm.
• Cơ chế bảo toàn bằng chứng phục vụ kiểm toán và điều tra.

Cần chứng minh khả năng cân bằng giữa tốc độ số hóa và yêu cầu kiểm soát, không đơn thuần sao chép quy trình cũ vào phần mềm.

3.6. Quản trị thay đổi và đo lường sau triển khai

Ứng viên nên biết cách lập kế hoạch quản trị thay đổi gồm:

• Đánh giá tác động đến con người, quy trình, hệ thống, dữ liệu, kiểm soát và khách hàng nội bộ.
• Xác định bên chịu trách nhiệm, bên phê duyệt và các bên liên quan.
• Lập kế hoạch truyền thông, đào tạo và hỗ trợ sau phát hành.
• Xác định tiêu chí go-live, phương án hoàn tác và kế hoạch xử lý sự cố.
• Theo dõi tỷ lệ sử dụng, thời gian xử lý, tỷ lệ lỗi, phản hồi và mức độ hài lòng.
• Đề xuất cải tiến dựa trên dữ liệu thay vì chỉ dựa trên cảm nhận.

4. Kỹ năng mềm cần thể hiện

• Phân tích: đưa ra giả thuyết, xác minh bằng dữ liệu và phân biệt nguyên nhân với triệu chứng.
• Viết tài liệu: logic, súc tích, có cấu trúc, không để người đọc phải tự suy luận.
• Làm việc đa bên: biết điều phối khi nghiệp vụ, Công nghệ Thông tin, kiểm soát và vận hành có mục tiêu khác nhau.
• Cẩn trọng: kiểm tra điều kiện ngoại lệ, quyền hạn, dữ liệu và khả năng truy vết.
• Giao tiếp: trình bày được với cả người không rành công nghệ và chuyên gia.
• Tư duy hệ thống: nhìn toàn bộ quy trình, không chỉ nhiệm vụ được giao.
• Quyết định dựa trên bằng chứng: biết sử dụng dữ liệu thời gian, số lượng và tần suất lỗi.
• Chủ động giải quyết vấn đề: chủ động đề xuất phương án, không chỉ chuyển vấn đề lên cấp trên.

5. Công cụ và kiến thức bổ sung

Các công cụ sau đáng chú ý, nhưng không cần thành thạo tất cả:

• Vẽ quy trình: Microsoft Visio, Lucidchart hoặc phần mềm tương đương.
• Quản lý yêu cầu và công việc: Jira, Confluence hoặc công cụ nội bộ tương đương.
• Phân tích dữ liệu: Excel nâng cao, SQL và Power BI là lợi thế.
• Mô hình hóa và phân tích: Miro, Excel và các công cụ quản lý quy trình.
• Làm việc nhóm và họp: Microsoft Teams, Zoom hoặc công cụ tương đương.
• Kiến thức kỹ thuật nên có: cấu trúc dữ liệu, API, kiểm thử phần mềm và nguyên tắc bảo mật ở mức đủ để trao đổi với Công nghệ Thông tin.

6. Chứng chỉ gợi ý

Tin tuyển dụng không yêu cầu chứng chỉ cụ thể. Các chứng chỉ dưới đây chỉ có giá trị hỗ trợ:

7. Hồ sơ ứng viên nên chuẩn bị

• Hồ sơ ứng tuyển 02 trang, nhấn mạnh các dự án chuyển đổi quy trình và kết quả đo lường.
• Hai nghiên cứu tình huống đã được loại bỏ thông tin mật: một quy trình vận hành phức tạp và một quy trình có điểm kiểm soát, phân quyền.
• Bộ sơ đồ quy trình hiện trạng và quy trình mục tiêu.
• Trích đoạn BRD, câu chuyện người dùng và tiêu chí nghiệm thu.
• Kế hoạch UAT, mẫu biên bản lỗi và tiêu chí nghiệm thu.
• Kế hoạch quản trị thay đổi, đào tạo và theo dõi sau triển khai.
• Danh sách chỉ số đo lường trước và sau dự án.

8. Dấu hiệu cho thấy hồ sơ còn yếu

• Kinh nghiệm được mô tả chung chung như “tham gia hỗ trợ số hóa” nhưng không nêu rõ quy trình, vai trò và kết quả.
• Có kinh nghiệm kỹ thuật nhưng thiếu tư duy nghiệp vụ và tài liệu.
• Nói rất tốt về BPMN nhưng không giải thích được ngoại lệ, phân quyền và kiểm toán.
• Hiểu UAT như một giai đoạn do Công nghệ Thông tin phụ trách hoàn toàn.
• Không có số liệu chứng minh tác động của dự án.
• Không thể giải thích cách theo dõi mức độ sử dụng sau khi giải pháp đã triển khai.

9. Thông điệp định vị nên dùng

Ứng viên phù hợp nhất có thể định vị mình là: người có thể phân tích quy trình vận hành, chuyển quy trình thành yêu cầu có thể kiểm thử, phối hợp triển khai có kiểm soát và đảm bảo người dùng thực sự sử dụng giải pháp. Đây là ứng viên có tư duy đầu cuối, không chỉ tập trung vào tài liệu hoặc công nghệ.