Đánh giá hiện trạng quy trình AS-IS và thiết kế quy trình TO-BE trước khi triển khai giải pháp.

Số hóa một bước chưa chắc cải thiện cả quy trình

Đưa phiếu giấy lên màn hình có thể giúp lưu hồ sơ dễ hơn, nhưng nếu yêu cầu vẫn phải chờ nhiều lượt xác nhận không cần thiết, thời gian xử lý chưa chắc giảm. Khi giải pháp được cấu hình theo quy trình chưa được phân tích, doanh nghiệp có nguy cơ giữ lại điểm nghẽn và làm chúng khó thay đổi hơn.

AS-IS mô tả cách công việc đang diễn ra, còn TO-BE mô tả cách công việc cần diễn ra trong phạm vi tương lai. Hai phần phải được xây từ bằng chứng và mục tiêu, không chỉ từ sơ đồ quy trình đã ban hành hoặc chức năng có trong phần mềm. Mục đích là thiết kế công việc phù hợp trước khi quyết định giải pháp đáp ứng.

Người phân tích cần nhìn toàn luồng từ sự kiện bắt đầu đến kết quả người nhận cần sử dụng. Các năng lực trong chương trình chuyển đổi số giúp nối thiết kế quy trình với trách nhiệm, dữ liệu và thay đổi vận hành. Việc vẽ sơ đồ chỉ là một phương tiện; quyết định cải tiến mới là đầu ra quan trọng.

Chọn ranh giới khảo sát theo nhiệm vụ đầu cuối

Xác định rõ quy trình bắt đầu khi nào và hoàn tất khi nào. Với tiếp nhận đề nghị mua, bắt đầu có thể là lúc một yêu cầu hợp lệ được nộp, còn hoàn tất là khi có quyết định và thông tin được chuyển tới bước mua hàng. Nếu chỉ khảo sát màn hình phê duyệt, đội dự án có thể bỏ qua chất lượng đầu vào hoặc điểm bàn giao sau phê duyệt.

Ghi loại giao dịch, đơn vị, nhóm người dùng và ngoại lệ nằm trong phạm vi. Một quy trình ở trụ sở có thể khác chi nhánh về nguồn lực hoặc quyền hạn. Cần biết khác biệt nào do nhu cầu thật, khác biệt nào do thói quen và khác biệt nào phải giữ vì điều kiện áp dụng.

Chọn mẫu công việc đủ phản ánh luồng thường và các trường hợp khó. Không chỉ quan sát nhân viên thành thạo nhất hoặc hồ sơ hoàn hảo. Các lần bổ sung thông tin, trả lại, hủy, xử lý khẩn hoặc người phê duyệt vắng mặt thường cho thấy những điều mà quy trình chính chưa giải thích.

Thu thập AS-IS bằng quan sát và đối chiếu

Đọc tài liệu hiện có, phỏng vấn các vai trò rồi quan sát cách họ xử lý giao dịch. Ghi công cụ, dữ liệu, bước chờ, thao tác lặp và cách chuyển trách nhiệm. Khi lời mô tả khác hồ sơ, cần tìm nguyên nhân thay vì chọn ngay một phiên bản làm sự thật.

Với mỗi bước, xác định đầu vào, hành động, đầu ra, người thực hiện và điều kiện chuyển tiếp. Ghi cả các bảng tính, email hoặc trao đổi không chính thức đang giữ thông tin quan trọng. Một đường đi ngoài quy trình có thể là cách ứng phó với khoảng trống, nhưng cũng có thể tạo rủi ro mất dấu và sai quyền.

Đo thời gian làm và thời gian chờ nếu có thể, đồng thời ghi giới hạn dữ liệu. Đừng gọi tất cả thời gian giữa hai dấu mốc là thời gian xử lý. Nếu chưa đo được, ghi giả thuyết cần kiểm chứng, không đưa con số ước đoán vào báo cáo như kết quả khảo sát.

Phân tích nguyên nhân trước khi bỏ bước

Một bước phê duyệt có thể tồn tại để kiểm soát ngân sách, quyền hoặc chất lượng. Muốn bỏ hoặc gộp bước, cần hiểu mục đích và hậu quả. Nếu kiểm soát vẫn cần, có thể thay cách thực hiện nhưng phải có phương án tạo bằng chứng và trách nhiệm tương ứng.

Phân biệt điểm chờ do quy tắc, thiếu thông tin, năng lực hoặc bàn giao. Cùng một triệu chứng chậm có thể có nhiều nguyên nhân. Tăng tự động hóa khi đầu vào thiếu thông tin có thể chỉ chuyển lỗi nhanh hơn; thêm người khi quyền chốt chưa rõ cũng chưa xử lý gốc vấn đề.

Bảng đưa ra hướng xem xét, không phải kết luận tự động. Mỗi lựa chọn cần được chủ quy trình và các bên kiểm soát xác nhận. Những thay đổi liên quan an toàn dữ liệu cần phối hợp với năng lực từ chương trình quản lý bảo mật thông tin, thay vì coi nhanh hơn là tiêu chí duy nhất.

Thiết kế TO-BE theo mục tiêu và trách nhiệm

Mô tả công việc tương lai bằng vai trò, đầu vào, quy tắc, kết quả và điều kiện ngoại lệ. Chốt ai tạo dữ liệu, ai quyết định, ai nhận đầu ra và ai xử lý khi giao dịch không đi theo luồng thường. Sơ đồ TO-BE không đầy đủ nếu chỉ có các hộp hành động mà không có quyền và điều kiện chuyển tiếp.

Xem xét lần lượt khả năng loại bỏ việc không cần, đơn giản hóa, chuẩn hóa rồi mới tự động hóa phần phù hợp. Trình tự này giúp tránh đưa quy tắc dư thừa vào cấu hình. Có thể thử cách làm mới ở quy mô nhỏ trước khi cam kết tích hợp lớn, nếu điều kiện công việc cho phép.

Thiết kế phải tính tới người sử dụng và khối lượng thực tế. Một quy trình trông gọn có thể dồn mọi ngoại lệ cho một vai trò quá tải. Kiểm tra cả giờ cao điểm, người thay thế và khả năng hỗ trợ. Không nên thiết kế luồng chỉ hoạt động khi mọi nhân sự chủ chốt có mặt và dữ liệu đều hoàn hảo.

Tách quyết định nghiệp vụ khỏi khả năng phần mềm

Đội dự án cần một TO-BE có căn cứ để đánh giá giải pháp, nhưng cũng phải kiểm tra tính khả thi. Khi hệ thống không hỗ trợ trực tiếp một quy tắc, cần đưa các phương án về chủ nghiệp vụ: điều chỉnh quy trình, cấu hình, tích hợp hoặc phát triển thêm. Không để nhà cung cấp tự chốt chính sách chỉ vì chức năng tiêu chuẩn của họ thuận tiện hơn.

Ngược lại, đừng yêu cầu phần mềm mô phỏng mọi thói quen cũ. Nếu một khác biệt không còn tạo giá trị hay kiểm soát cần thiết, có thể thống nhất thay đổi công việc để dùng khả năng tiêu chuẩn. Quyết định cần dựa trên mục tiêu, chi phí và tác động, được ghi lại cùng người phê duyệt.

Phần phân tích sẽ trở thành căn cứ yêu cầu và nghiệm thu. Cách quản lý trong chương trình quản lý dự án IT hỗ trợ giữ quan hệ từ mục tiêu đến quy trình và sản phẩm. Khi TO-BE đổi, cần xem lại yêu cầu, dữ liệu, đào tạo và kế hoạch liên quan.

Kiểm chứng TO-BE qua từng tình huống

Tổ chức buổi đi qua giao dịch với người thực hiện thật. Dùng hồ sơ mẫu đã được bảo vệ phù hợp, lần lượt kiểm tra luồng thường, thiếu thông tin, thay đổi, từ chối và lỗi kết nối. Người tham gia cần nói mình nhận gì, làm gì và chuyển cho ai ở từng bước.

Ghi các điểm chưa thống nhất thành quyết định mở có chủ và thời hạn. Không nên kết thúc workshop bằng một sơ đồ được gọi là đã chốt nếu các quy tắc quan trọng vẫn chưa có người phê duyệt. Sự đồng ý về hình vẽ không tự chứng minh quy trình có thể vận hành.

Sau khi xác nhận, lập phiên bản TO-BE và điều kiện áp dụng. Cần biết thay đổi nào có hiệu lực từ lúc nào và nhóm nào được đào tạo. Nội dung của chuyên đề quản lý thay đổi IT giúp điều phối chuyển tiếp để quy trình cũ và mới không cùng tạo nghĩa vụ mâu thuẫn.

Tình huống giả định: Phê duyệt đề nghị bảo trì

Một doanh nghiệp giả định muốn đưa đề nghị bảo trì lên hệ thống. AS-IS cho thấy nhân viên điền biểu mẫu, gửi quản lý rồi chờ bộ phận kỹ thuật hỏi thêm mã thiết bị. Đề nghị khẩn được xử lý qua điện thoại, sau đó hồ sơ được bổ sung với thông tin không thống nhất.

Nhóm phân tích không bắt đầu bằng số hóa biểu mẫu hiện có. Họ xác định dữ liệu tối thiểu, phân loại mức ưu tiên, nguồn mã thiết bị và quyền xử lý khẩn. TO-BE cho phép kiểm tra đầu vào, chuyển theo quy tắc đã được phê duyệt và ghi lý do ngoại lệ; trách nhiệm cập nhật trạng thái được phân công rõ.

Buổi kiểm chứng phát hiện người dùng ở một khu vực chưa có dữ liệu thiết bị đầy đủ. Dự án ghi điều kiện chuẩn bị dữ liệu trước khi triển khai ở khu vực đó. Kết quả kỳ vọng là giảm các lần hỏi lại và giữ dấu vết xử lý; doanh nghiệp cần đo thực tế sau áp dụng để xác nhận mức cải thiện.

Hồ sơ phân tích cần được duy trì sau triển khai

Lưu ranh giới, bằng chứng AS-IS, vấn đề, quyết định TO-BE và các điều kiện còn mở trong cùng hệ thống hồ sơ dự án. Người đọc cần truy được vì sao một bước bị bỏ, vì sao một kiểm soát được giữ và ai xác nhận lựa chọn. Điều này hỗ trợ xử lý yêu cầu thay đổi khi những người tham gia ban đầu không còn trực tiếp làm dự án.

• Luồng đầu cuối đã bao gồm các điểm bàn giao chưa?
• Thời gian chờ và thời gian thực hiện đã được phân biệt chưa?
• Ngoại lệ có người xử lý và quyền rõ không?
• Các quy tắc TO-BE đã được phê duyệt đúng thẩm quyền chưa?
• Điều kiện dữ liệu, nguồn lực và hỗ trợ đã được xác nhận chưa?

AS-IS và TO-BE có giá trị khi giúp doanh nghiệp quyết định cách công việc cần thay đổi và điều kiện để thay đổi đó thực hiện được. Bắt đầu từ một luồng có vấn đề rõ, kiểm chứng bằng giao dịch thật, rồi đưa kết quả thành yêu cầu và kế hoạch triển khai có trách nhiệm.

Bài viết liên quan

• Xây dựng Project Charter cho dự án chuyển đổi số: Những nội dung không thể bỏ qua.
• Quản lý yêu cầu nghiệp vụ: Làm thế nào để IT hiểu đúng vấn đề của các phòng ban?
• Chuyển mục tiêu chuyển đổi số thành phạm vi, sản phẩm bàn giao và kết quả dự án.
• 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.

Nguồn tham khảo

1. GOV.UK – Learning about users and their needs
2. APM – Change management and organisational change
3. APM – Understanding requirements, the basis of delivering quality