INFOCHIEF ACADEMY · DIGITAL TRANSFORMATION PROJECT KNOWLEDGE SERIES

Phân tích khoảng cách giữa quy trình hiện tại và khả năng đáp ứng của hệ thống mới.

Khác biệt với phần mềm có thể nằm ở quy trình, dữ liệu hoặc chức năng. Cần xác định tác động và bằng chứng trước khi chọn cấu hình, tích hợp hay phát triển thêm.

Biên soạn: Infochief Academy · Chuyên đề: Quản lý dự án chuyển đổi số

← Trở về danh mục Chuyển đổi số

Phân tích khoảng cách giúp chọn phương án từ nhu cầu và bằng chứng đáp ứng.

Chênh lệch với phần mềm không mặc nhiên là lỗi hệ thống

Sau buổi trình diễn, một phòng ban kết luận hệ thống mới không phù hợp vì thiếu bước xác nhận đang dùng. Nhà cung cấp đề xuất tùy chỉnh. Tuy nhiên, bước xác nhận đó có thể là kiểm soát cần thiết, một thói quen không còn lý do hoặc cách ứng phó với dữ liệu cũ. Mỗi trường hợp dẫn đến một lựa chọn khác nhau.

Phân tích khoảng cách là việc đối chiếu nhu cầu và quy trình mục tiêu với khả năng giải pháp, xác định phần chưa đáp ứng cùng phương án xử lý. Nếu chỉ so sánh phần mềm với mọi thao tác hiện tại, doanh nghiệp có thể đầu tư để giữ lại điểm yếu. Nếu chỉ làm theo chức năng tiêu chuẩn, doanh nghiệp có thể bỏ qua kiểm soát hoặc nhu cầu thật.

Đội dự án cần một hồ sơ khoảng cách đủ để quyết định, không chỉ một bảng đánh dấu có hoặc không. Năng lực trong chương trình quản lý dự án IT hỗ trợ nối kết quả phân tích với phạm vi, nguồn lực, rủi ro và nghiệm thu.

Chốt cơ sở đối chiếu trước khi xem giải pháp

Xác định phiên bản quy trình TO-BE, yêu cầu nghiệp vụ và tiêu chí chấp nhận được dùng để so sánh. Mỗi yêu cầu cần lý do và chủ xác nhận. Nếu quy trình mục tiêu chưa được thống nhất, bảng khoảng cách có thể chỉ phản ánh các mong muốn mâu thuẫn của phòng ban.

Ghi rõ hệ thống và phiên bản, phạm vi chức năng, cấu hình và các thành phần liên quan. Khả năng trong bản trình diễn chưa chắc có trong gói triển khai được mua. Cần xác nhận các điều kiện cấp phép, tích hợp và dữ liệu với tài liệu hoặc thử nghiệm phù hợp; không coi lời mô tả chung là bằng chứng đủ cho cam kết.

Một nhu cầu có thể được đáp ứng bằng tổ hợp nhiều thành phần. Khi đánh giá, cần nhìn luồng công việc đầu cuối, không chỉ màn hình chính. Nếu thông tin phải đi qua hệ thống khác, phân tích cả thời điểm, quyền và khả năng xử lý lỗi để xác định mức đáp ứng thực tế.

Đi qua kịch bản thay vì đánh giá theo cảm giác

Dùng giao dịch đại diện để kiểm tra khả năng giải pháp. Với mỗi bước, xác định người thực hiện, dữ liệu cần, quy tắc, kết quả và ngoại lệ. Ghi bằng chứng về phần đáp ứng, phần cần cấu hình và phần chưa có, cùng những giả định đang chờ xác nhận.

Không chỉ kiểm tra luồng thuận lợi. Cần thử dữ liệu thiếu, yêu cầu thay đổi, người phê duyệt vắng mặt, kết nối lỗi và giao dịch bị hủy nếu chúng thuộc phạm vi. Một hệ thống có thể đáp ứng thao tác bình thường nhưng thiếu khả năng khôi phục hoặc giữ dấu vết khi công việc đổi hướng.

Ghi mức độ chắc chắn của kết luận. Khả năng đã kiểm tra trong môi trường đại diện khác với khả năng chỉ đọc trong tài liệu. Khoảng trống thông tin cần tạo nhiệm vụ xác minh, không bị gộp vào trạng thái “đáp ứng” cho thuận tiến độ.

Phân loại khoảng cách để chọn đúng hướng xử lý

Khoảng cách có thể nằm ở quy trình, dữ liệu, quyền, chức năng, tích hợp hoặc vận hành. Một yêu cầu không thực hiện được vì thiếu mã dữ liệu khác với một yêu cầu phần mềm không hỗ trợ. Nếu phân loại sai, dự án có thể lập trình thêm trong khi điều kiện nền vẫn chưa được xử lý.

Loại khoảng cách	Câu hỏi xác định	Hướng xử lý cần đánh giá
Quy trình hoặc quy tắc	Nhu cầu có lý do còn phù hợp không?	Điều chỉnh TO-BE có phê duyệt
Cấu hình	Khả năng có sẵn nhưng chưa thiết lập?	Cấu hình và kiểm chứng
Dữ liệu	Nguồn, nghĩa hoặc chất lượng chưa đủ?	Chuẩn hóa, làm sạch và giao chủ dữ liệu
Chức năng hoặc tích hợp	Nhiệm vụ cần khả năng chưa có?	Tích hợp, phát triển hoặc đổi phương án
Vận hành	Ai hỗ trợ và xử lý khi thất bại?	Thiết kế dịch vụ, dự phòng và trách nhiệm

Mỗi dòng cần mô tả tác động tới công việc, không chỉ tên thành phần kỹ thuật. Một khoảng cách nhỏ trên màn hình có thể tạo rủi ro lớn về quyền; một khác biệt rõ về giao diện có thể không ảnh hưởng kết quả. Ưu tiên phải dựa trên hậu quả, mức cần thiết và các phụ thuộc.

Đánh giá các phương án trên cùng phạm vi

Phương án đầu là thay đổi quy trình để sử dụng khả năng tiêu chuẩn khi phù hợp. Điều này cần kiểm tra giá trị, kiểm soát và mức chuyển đổi của người dùng. Không nên chọn chỉ vì ít lập trình, nhưng cũng không nên bác bỏ chỉ vì cách làm khác thói quen hiện tại.

Phương án cấu hình cần xác nhận giới hạn, quyền quản trị và ảnh hưởng tới các luồng khác. Phương án tích hợp cần xem chủ dữ liệu, cách trao đổi, xử lý lỗi và hỗ trợ. Phương án phát triển thêm cần tính thiết kế, kiểm thử, bảo trì, cập nhật và phụ thuộc nhà cung cấp, không chỉ chi phí xây dựng ban đầu.

Có thể sử dụng cách xử lý thủ công có kiểm soát trong phạm vi và thời hạn xác định, nếu được chấp nhận theo cơ chế của doanh nghiệp. Cần ghi công sức, rủi ro, người chịu trách nhiệm và điều kiện kết thúc. Một giải pháp tạm không được bỏ quên để trở thành nghĩa vụ lâu dài ngoài kế hoạch.

Khi so sánh, dùng cùng mục tiêu, thời gian và phạm vi chi phí. Nội dung từ chuyên đề ngân sách IT hỗ trợ xem tổng cam kết, còn chuyên đề quản lý nhà cung cấp IT giúp làm rõ nghĩa vụ hỗ trợ và điều kiện thay đổi trong từng phương án.

Hồ sơ quyết định khoảng cách cần có gì?

Mỗi khoảng cách nên có mã, yêu cầu liên quan, kịch bản, bằng chứng và tác động. Ghi phương án đã xem xét, chi phí hoặc công sức ở mức phù hợp, rủi ro còn lại và đề xuất. Người chốt quyết định cùng căn cứ phê duyệt cần được lưu để tránh mở lại tranh luận mà không có thông tin mới.

Trạng thái có thể là đang xác minh, chờ quyết định, đã chốt hoặc đã kiểm chứng. “Đã chốt” chưa có nghĩa đã xử lý xong. Quyết định cấu hình hoặc phát triển phải tạo đầu việc, tiêu chí chấp nhận và kiểm thử; quyết định đổi quy trình phải cập nhật tài liệu, đào tạo và quyền liên quan.

Thiết lập quan hệ giữa khoảng cách với phạm vi và lịch triển khai. Khi một khoảng cách quan trọng chưa có phương án, cần phản ánh vào đánh giá sẵn sàng. Đừng giữ mốc go-live bằng cách chuyển phần chưa giải quyết thành lỗi nhỏ nếu tác động nghiệp vụ chưa được đánh giá.

Tránh biến fit-gap thành danh sách tùy chỉnh

Một workshop dễ bị dẫn dắt bởi bản demo hấp dẫn hoặc phòng ban có tiếng nói mạnh. Người điều phối cần quay về nhu cầu và tiêu chí, phân biệt việc chưa biết với việc chưa đáp ứng. Không nên sử dụng điểm tổng cao để bỏ qua một điều kiện bắt buộc chưa có lời giải.

Thay đổi quy trình phải được chốt đúng thẩm quyền. Nhà cung cấp có thể giải thích cách phần mềm hoạt động, nhưng chủ nghiệp vụ và các bên kiểm soát phải xác nhận cách công việc được phép thay đổi. Các quyết định này cần được nối với mục tiêu của chương trình chuyển đổi số, nơi công nghệ và tổ chức được xem cùng nhau.

Khi cần thêm thời gian xác minh, ghi rõ câu hỏi, bằng chứng và mốc. Việc giữ một dòng “sẽ xử lý sau” không có chủ là nguồn tạo bất ngờ ở giai đoạn kiểm thử. Các khoảng cách phụ thuộc cùng dữ liệu hoặc tích hợp nên được xem thành nhóm để tránh giải quyết rời rạc.

Tình huống giả định: Quy tắc phê duyệt theo hạn mức

Một doanh nghiệp giả định chọn hệ thống có luồng phê duyệt theo giá trị, trong khi quy trình hiện tại yêu cầu mọi đề nghị qua cùng một quản lý. Phòng ban đề nghị phát triển thêm bước xác nhận vì cho rằng hệ thống thiếu quy trình bắt buộc.

Phân tích cho thấy bước xác nhận đang kết hợp hai mục đích: kiểm tra thông tin và chốt thẩm quyền. Chủ nghiệp vụ cùng tài chính tách hai mục đích, thiết kế kiểm tra đầu vào và xác định hạn mức phê duyệt. Một phần được cấu hình bằng khả năng sẵn có; trường hợp vượt quyền cần quy tắc bổ sung được phê duyệt.

Nhóm dự án ghi quyết định cùng kịch bản kiểm thử, cập nhật TO-BE và hướng dẫn người dùng. Họ chưa tuyên bố giải pháp tối ưu chỉ vì giảm tùy chỉnh, mà tiếp tục kiểm chứng ngoại lệ và khả năng vận hành. Bài học là khoảng cách cần được phân tích theo nhiệm vụ và kiểm soát trước khi chọn phương án kỹ thuật.

Kiểm tra kết quả xử lý và giữ khả năng cập nhật

Sau khi thực hiện, kiểm thử lại kịch bản từng tạo khoảng cách. Người xác nhận nghiệp vụ cần thấy công việc hoàn thành và các điều kiện kiểm soát được giữ. Nếu dùng phương án tạm, kiểm tra cả thời hạn, công sức và cơ chế theo dõi để tránh phát sinh công việc ngoài trách nhiệm.

Cơ sở TO-BE và yêu cầu đã có phiên bản rõ chưa?
Kết luận đáp ứng có bằng chứng hay chỉ dựa trên trình diễn?
Các phương án có được so sánh trên cùng phạm vi không?
Quyết định có đúng người chốt và rủi ro còn lại được ghi nhận không?
Kết quả xử lý đã cập nhật tới kiểm thử, quy trình và vận hành chưa?

Phân tích khoảng cách tốt giúp doanh nghiệp biết phần nào cần thay đổi ở công việc và phần nào cần thay đổi ở giải pháp. Hãy bắt đầu từ những nhiệm vụ quan trọng nhất, yêu cầu bằng chứng đáp ứng và đưa các lựa chọn về đúng quyền quyết định trước khi cam kết chi phí phát triển.