Cách xác định phạm vi triển khai công nghệ

Xác định rõ chức năng nào được triển khai

Ranh giới đầu tiên của phạm vi là chức năng mà công nghệ phải thực hiện. Một tuyên bố như “triển khai hệ thống quản lý”, “ứng dụng AI” hoặc “số hóa quy trình” chưa đủ để hình thành phạm vi vì chưa cho biết hệ thống thực sự phải làm gì.

Phạm vi chức năng cần được mô tả bằng các khả năng cụ thể. Chẳng hạn, thay vì ghi “triển khai hệ thống quản lý yêu cầu”, có thể xác định hệ thống phải tiếp nhận yêu cầu, phân loại, chuyển cho người xử lý, theo dõi trạng thái, gửi thông báo và tổng hợp báo cáo. Khi các chức năng được tách rõ, đội triển khai có thể liên kết từng yêu cầu với cấu hình, giao diện, dữ liệu, kiểm thử và tiêu chí nghiệm thu tương ứng.

Quan trọng không kém là xác định chức năng không nằm trong phạm vi. Nếu giai đoạn đầu chỉ tiếp nhận và xử lý yêu cầu nhưng chưa tự động dự báo nhu cầu, chức năng dự báo phải được ghi rõ là ngoài phạm vi hoặc dành cho giai đoạn sau. Việc này ngăn một khả năng “có liên quan” bị hiểu thành một cam kết phải cung cấp.

Không có một số lượng chức năng chuẩn áp dụng cho mọi dự án. Mức chi tiết phù hợp đạt được khi mỗi chức năng đủ rõ để trả lời ba câu hỏi: ai sử dụng, dữ liệu nào được xử lý và kết quả nào phải được tạo ra. Nếu chưa thể liên kết chức năng với các yếu tố này, phạm vi vẫn còn quá khái quát.

Khoanh đúng đơn vị và quy trình được áp dụng

Cùng một công nghệ có thể được triển khai cho toàn doanh nghiệp, một khối nghiệp vụ, một chi nhánh hoặc chỉ một nhóm vận hành. Vì vậy, phạm vi tổ chức phải được xác định độc lập với phạm vi chức năng.

Cần nêu rõ đơn vị nào trực tiếp sử dụng hệ thống, đơn vị nào chỉ cung cấp dữ liệu hoặc phối hợp, và đơn vị nào chưa tham gia trong giai đoạn hiện tại. Ví dụ, một chức năng phê duyệt có thể được áp dụng cho phòng mua hàng tại trụ sở chính nhưng chưa áp dụng cho các công ty thành viên. Nếu chỉ ghi “triển khai chức năng phê duyệt”, hai cách hiểu này đều có thể xảy ra và dẫn đến khác biệt lớn về cấu hình, dữ liệu, phân quyền và khối lượng triển khai.

Ranh giới theo đơn vị cũng phải đi cùng quy trình thực tế. Một đơn vị nằm trong phạm vi không có nghĩa mọi quy trình của đơn vị đó đều được số hóa. Có thể chỉ một bước hoặc một luồng nghiệp vụ được chuyển sang hệ thống mới, còn các bước khác tiếp tục xử lý trên hệ thống hiện hữu hoặc thủ công.

Do đó, tên đơn vị chỉ là điểm bắt đầu. Phạm vi đủ rõ phải cho biết đơn vị đó tham gia vào quy trình nào, tại bước nào và với trách nhiệm gì. Đây cũng là cơ sở để phát hiện các giao điểm liên phòng ban: nếu một quy trình bắt đầu ở đơn vị A nhưng phải được phê duyệt bởi đơn vị B, việc bỏ B khỏi phạm vi có thể khiến chức năng không thể vận hành trọn vẹn.

Xác định nhóm người dùng, vai trò và mức độ tham gia

Phạm vi người dùng không nên được mô tả đơn giản bằng “toàn bộ nhân viên” hoặc “người dùng nội bộ”. Công nghệ thường phục vụ nhiều nhóm có quyền, nhiệm vụ và cách tương tác khác nhau.

Cần xác định tối thiểu các vai trò trực tiếp thực hiện nghiệp vụ, vai trò phê duyệt hoặc giám sát, người quản trị và những đối tượng chỉ xem thông tin nếu họ thực sự nằm trong phạm vi. Với mỗi nhóm, phạm vi nên cho biết họ được dùng chức năng nào và thực hiện hành động gì.

Việc tách vai trò có tác động trực tiếp đến thiết kế quyền truy cập. Một người “có tài khoản” không đồng nghĩa với việc được sử dụng toàn bộ chức năng. Nếu phạm vi người dùng chỉ dựa trên số lượng tài khoản mà không xác định vai trò, hệ thống có thể đáp ứng đúng quy mô kỹ thuật nhưng sai yêu cầu nghiệp vụ.

Số lượng người dùng vẫn là một thông số cần đo khi nó ảnh hưởng đến cấp phép, năng lực hệ thống, hỗ trợ vận hành hoặc kế hoạch triển khai. Tuy nhiên, số lượng không thay thế được phân loại vai trò. Hai dự án cùng có 1.000 người dùng có thể có phạm vi rất khác nếu dự án thứ nhất chỉ cho phép tra cứu, trong khi dự án thứ hai yêu cầu nhập liệu, phê duyệt, quản trị và xử lý đồng thời.

Vì vậy, phạm vi người dùng nên trả lời đồng thời: ai được tham gia, họ thuộc vai trò nào, được sử dụng chức năng nào và ở đơn vị nào. Quan hệ này giúp phát hiện ngay những trường hợp chức năng đã được đưa vào phạm vi nhưng chưa có người chịu trách nhiệm sử dụng.

Xác định hệ thống, dữ liệu và các điểm tích hợp liên quan

Một công nghệ hiếm khi hoạt động hoàn toàn độc lập. Nó có thể phải nhận dữ liệu từ hệ thống khác, gửi kết quả sang một nền tảng kế tiếp, sử dụng dịch vụ xác thực chung hoặc duy trì song song với hệ thống hiện hữu. Vì vậy, ranh giới hệ thống là phần bắt buộc của phạm vi triển khai.

Cần phân biệt hệ thống được triển khai trực tiếp với hệ thống chỉ có quan hệ tích hợp. Nếu một nền tảng mới nhận thông tin nhân sự từ hệ thống HR, hệ thống HR không nhất thiết nằm trong phạm vi thay thế hoặc nâng cấp; nhưng giao diện lấy dữ liệu từ HR lại nằm trong phạm vi nếu đó là điều kiện để nền tảng mới hoạt động.

Mỗi tích hợp nên chỉ rõ hướng trao đổi dữ liệu, loại dữ liệu chính và trách nhiệm của hai đầu. Nếu chỉ ghi “tích hợp ERP” mà không xác định dữ liệu nào được lấy hoặc gửi, phạm vi vẫn chưa đủ để đánh giá công việc cần thực hiện. Tích hợp một chiều đọc danh mục sản phẩm khác đáng kể với đồng bộ hai chiều đơn hàng, tồn kho và trạng thái giao dịch.

Ranh giới dữ liệu cũng cần được làm rõ. Không phải mọi dữ liệu có trong hệ thống nguồn đều phải chuyển sang công nghệ mới. Phạm vi có thể chỉ bao gồm dữ liệu phát sinh mới, một khoảng thời gian lịch sử nhất định hoặc các trường dữ liệu cần cho chức năng đã xác định.

Điểm cần tránh là coi mọi hệ thống có liên quan về mặt nghiệp vụ đều thuộc phạm vi kỹ thuật. Chỉ những hệ thống, giao diện hoặc dữ liệu cần thiết để chức năng trong phạm vi hoạt động đúng mới cần được đưa vào ranh giới triển khai.

Ghép bốn chiều thành một ma trận phạm vi có thể kiểm chứng

Bốn chiều không nên được lập thành bốn danh sách độc lập rồi dừng lại. Phạm vi chỉ thực sự rõ khi chức năng, đơn vị, người dùng và hệ thống được liên kết với nhau.

Một ma trận phạm vi có thể dùng mỗi chức năng làm một dòng và xác định các thông tin tương ứng: đơn vị áp dụng, vai trò sử dụng, hệ thống hoặc dữ liệu liên quan, trạng thái trong hay ngoài phạm vi và điều kiện nghiệm thu. Với cấu trúc này, những khoảng trống trở nên dễ nhận thấy.

Ví dụ, nếu một chức năng được đánh dấu “trong phạm vi” nhưng chưa có đơn vị áp dụng, chưa có nhóm người dùng hoặc chưa xác định nguồn dữ liệu, đó là tín hiệu phạm vi chưa hoàn chỉnh. Ngược lại, nếu một hệ thống tích hợp được liệt kê nhưng không phục vụ bất kỳ chức năng nào, cần kiểm tra lại lý do đưa tích hợp đó vào dự án.

Ma trận cũng giúp biến phạm vi thành cơ sở nghiệm thu. Thay vì đánh giá chung rằng “hệ thống đã triển khai”, từng tổ hợp có thể được kiểm tra: chức năng nào đã hoạt động, cho đúng nhóm người dùng, tại đúng đơn vị và với đúng dữ liệu hoặc hệ thống liên quan.

Các chỉ số trong ma trận nên được dùng để kiểm soát phạm vi thực tế, chẳng hạn số chức năng đã thống nhất, số đơn vị triển khai, số nhóm vai trò, số giao diện tích hợp và số tổ hợp đã có tiêu chí nghiệm thu. Đây không phải benchmark chung của ngành; giá trị cần thiết phụ thuộc vào chính phạm vi của từng chương trình triển khai.

Chốt ranh giới bằng điều kiện, loại trừ và tiêu chí nghiệm thu

Một phạm vi đầy đủ không chỉ nói cái gì được làm, mà còn phải xác định điều kiện khiến cam kết đó được coi là hoàn thành. Đây là bước chuyển từ mô tả phạm vi sang phạm vi có thể quản lý và kiểm chứng.

Mỗi hạng mục quan trọng nên có ba lớp ranh giới. Thứ nhất là nội dung được bao gồm. Thứ hai là các loại trừ rõ ràng, chẳng hạn đơn vị chưa triển khai, chức năng để lại cho giai đoạn sau hoặc dữ liệu lịch sử không chuyển đổi. Thứ ba là các phụ thuộc có thể ảnh hưởng đến khả năng hoàn thành, ví dụ dữ liệu nguồn phải sẵn sàng hoặc hệ thống bên ngoài phải cung cấp giao diện tích hợp.

Tiêu chí nghiệm thu phải bám vào chính ranh giới này. Nếu phạm vi quy định một chức năng dành cho một nhóm người dùng tại một đơn vị cụ thể và cần dữ liệu từ một hệ thống nguồn, việc nghiệm thu phải kiểm tra đúng tổ hợp đó. Một chức năng chạy được trong môi trường thử nghiệm nhưng chưa dùng được với đúng người dùng hoặc chưa nhận đúng dữ liệu chưa chứng minh rằng phạm vi triển khai đã hoàn thành.

Trước khi chốt, có thể kiểm tra từng hạng mục bằng một câu hỏi đơn giản: có thể xác định rõ hạng mục này thuộc hay không thuộc phạm vi mà không cần suy đoán thêm không? Nếu câu trả lời vẫn phụ thuộc vào cách hiểu của từng bên, ranh giới cần được cụ thể hóa thêm.

Khi có yêu cầu thay đổi, cùng cấu trúc này giúp phân biệt thay đổi cấu hình trong phạm vi với mở rộng phạm vi. Thêm một trường hiển thị cho chức năng đã thống nhất có thể là điều chỉnh chi tiết; bổ sung một đơn vị mới, một nhóm người dùng mới, một chức năng mới hoặc một hệ thống tích hợp mới có thể làm thay đổi chính ranh giới triển khai và cần được đánh giá tương ứng.

Phạm vi triển khai công nghệ rõ ràng là một tập hợp các ranh giới có thể kiểm chứng, không phải một mô tả chung về công nghệ sẽ được áp dụng. Cần xác định chức năng nào được triển khai, đơn vị nào áp dụng, nhóm người dùng nào tham gia và hệ thống hoặc dữ liệu nào liên quan, sau đó liên kết bốn chiều này với điều kiện, loại trừ và tiêu chí nghiệm thu. Khi mỗi hạng mục đều có thể xác định rõ “trong phạm vi”, “ngoài phạm vi” và “hoàn thành khi nào”, phạm vi mới đủ cụ thể để làm cơ sở cho thiết kế, triển khai và kiểm soát thay đổi.