Cách đánh giá công nghệ phù hợp quy trình doanh nghiệp

Cách nhìn này gần với nguyên lý Task-Technology Fit: công nghệ chỉ tạo tác động tích cực khi vừa được sử dụng vừa phù hợp với nhiệm vụ mà nó hỗ trợ. Nghiên cứu nền tảng của Goodhue và Thompson kiểm nghiệm mô hình này trên hơn 600 người dùng tại hai doanh nghiệp và nhấn mạnh vai trò của sự phù hợp giữa đặc điểm nhiệm vụ với khả năng của công nghệ.

Vì vậy, đánh giá phù hợp phải tách hai câu hỏi: công nghệ có chất lượng tốt hay không và công nghệ có phù hợp với quy trình cụ thể hay không. Một hệ thống có thể ổn định, bảo mật và nhiều tính năng nhưng vẫn không phù hợp nếu người dùng phải tạo thêm bước trung gian, nhập lại dữ liệu, đổi trình tự xử lý hoặc bỏ qua những kiểm soát cần thiết để sử dụng nó.

Bắt đầu từ luồng công việc thay vì danh sách tính năng

Đơn vị đánh giá đầu tiên nên là quy trình đang tạo ra kết quả kinh doanh, không phải màn hình hay module của phần mềm. ISO 9001:2015 mô tả quy trình như tập hợp các hoạt động có liên quan hoặc tương tác, sử dụng đầu vào để tạo ra kết quả dự kiến; cách tiếp cận theo quá trình đồng thời xem các quy trình như một hệ thống tích hợp chứ không phải những hoạt động rời rạc.

Doanh nghiệp vì vậy cần lập bản đồ quy trình ở mức đủ để nhìn thấy:

·         Điểm bắt đầu và kết thúc

·         Đầu vào và đầu ra

·         Các bước xử lý chính

·         Vai trò chịu trách nhiệm

·         Điểm phê duyệt hoặc kiểm soát

·         Các lần chuyển giao giữa người, phòng ban hoặc hệ thống

·         Dữ liệu được tạo, đọc hoặc cập nhật

·         Ngoại lệ thường gặp

·         Những thao tác thủ công đang tồn tại

Sau đó mới đối chiếu từng yêu cầu với khả năng của công nghệ. Một chức năng chỉ có giá trị khi nó loại bỏ, tự động hóa hoặc hỗ trợ một hoạt động thực sự cần thiết. Ngược lại, hàng chục tính năng không tham gia vào luồng việc không làm mức độ phù hợp tăng lên.

Điểm cần tránh là mô tả quy trình quá chi tiết theo cách vận hành hiện tại rồi yêu cầu hệ thống sao chép nguyên trạng. Quy trình hiện hữu có thể chứa bước dư thừa. Đánh giá phù hợp cần bảo vệ những yêu cầu có lý do nghiệp vụ, kiểm soát hoặc pháp lý rõ ràng, chứ không bảo vệ mọi thói quen đang tồn tại.

Kiểm tra công nghệ có hỗ trợ trọn luồng việc hay chỉ từng thao tác riêng lẻ

Một công nghệ có thể xử lý tốt từng nhiệm vụ nhưng vẫn gây gián đoạn khi các nhiệm vụ được nối thành quy trình hoàn chỉnh. Do đó, khả năng hỗ trợ end-to-end quan trọng hơn việc một số chức năng riêng lẻ hoạt động tốt.

Với mỗi luồng chính, cần kiểm tra liệu hệ thống có duy trì được sự liên tục từ đầu vào đến đầu ra hay không. Các điểm dễ bộc lộ sự không phù hợp gồm chuyển dữ liệu sang Excel để xử lý tiếp, gửi email ngoài hệ thống để xin phê duyệt, nhập cùng một thông tin vào nhiều nơi, đổi công cụ giữa các bước hoặc phải theo dõi trạng thái bằng phương pháp thủ công.

Có thể đánh giá mỗi bước theo bốn trạng thái:

·         Được hệ thống hỗ trợ trực tiếp

·         Được hỗ trợ thông qua cấu hình hợp lý

·         Cần giải pháp vòng hoặc thao tác ngoài hệ thống

·         Không thể thực hiện theo yêu cầu

Hai trạng thái đầu thường biểu hiện mức độ phù hợp tốt hơn hai trạng thái sau. Tuy nhiên, “cấu hình” cũng cần được xem xét về mức độ phức tạp. Một hệ thống chỉ phù hợp trên lý thuyết nếu mỗi thay đổi nhỏ của quy trình đều cần phát triển riêng, can thiệp kỹ thuật sâu hoặc tạo thêm lớp vận hành mà doanh nghiệp khó duy trì.

Ngoại lệ cũng phải được thử nghiệm, không chỉ happy path. Quy trình thực tế thường có hồ sơ thiếu thông tin, giao dịch bị từ chối, yêu cầu quay lại bước trước, thay đổi người phê duyệt hoặc trường hợp cần xử lý khẩn. Công nghệ chỉ phù hợp khi xử lý được các tình huống này mà vẫn giữ trạng thái, lịch sử và trách nhiệm rõ ràng.

Đo mức thay đổi quy trình mà công nghệ buộc doanh nghiệp phải chấp nhận

Không phải mọi thay đổi quy trình đều xấu. Một số thay đổi giúp loại bỏ bước thừa, chuẩn hóa dữ liệu hoặc tăng kiểm soát. Vấn đề nằm ở những thay đổi chỉ xuất hiện vì giới hạn của công nghệ nhưng không tạo thêm giá trị nghiệp vụ.

Mỗi thay đổi được đề xuất nên được phân loại thành ba nhóm:

1.    Thay đổi tạo giá trị, chẳng hạn bỏ nhập liệu lặp hoặc tự động chuyển việc

2.    Thay đổi trung tính, không tạo lợi ích đáng kể nhưng chi phí thích nghi thấp

3.    Thay đổi cưỡng bức, làm quy trình phức tạp hơn chỉ để phù hợp với cách hệ thống hoạt động

Nhóm thứ ba là tín hiệu cần theo dõi sát. Ví dụ, một quy trình hiện chỉ cần một lần phê duyệt nhưng phần mềm buộc phải tạo thêm trạng thái trung gian; hoặc nhân viên phải chuyển dữ liệu sang một mẫu mới rồi nhập lại vào hệ thống mà không có yêu cầu kiểm soát tương ứng. Đây là chi phí thích nghi do công nghệ tạo ra chứ không phải cải tiến quy trình.

Khi đánh giá một thay đổi, câu hỏi quan trọng không phải “quy trình có phải thay đổi không?” mà là “thay đổi này giải quyết vấn đề gì?”. Nếu có thể gắn thay đổi với giảm lỗi, giảm thời gian, tăng khả năng kiểm soát, chuẩn hóa dữ liệu hoặc loại bỏ công việc không cần thiết, thay đổi có cơ sở. Nếu lý do duy nhất là “hệ thống được thiết kế như vậy”, mức độ phù hợp cần được xem xét lại.

Cũng có giới hạn theo chiều ngược lại: yêu cầu công nghệ giữ nguyên tất cả cách làm cũ có thể duy trì cả những hoạt động không còn cần thiết. Mục tiêu là giảm thay đổi không cần thiết, không phải giảm mọi thay đổi.

Đánh giá sự phù hợp với vai trò, dữ liệu, kiểm soát và hệ thống liên quan

Luồng việc chỉ vận hành được khi bốn thành phần đi cùng nhau: người thực hiện, dữ liệu, quyền kiểm soát và các hệ thống trao đổi thông tin. Công nghệ phù hợp phải xử lý được những mối quan hệ này mà không tạo thêm điểm đứt.

Về vai trò, cần kiểm tra hệ thống có thể phân công đúng người, đúng trách nhiệm và đúng phạm vi quyền hay không. Nếu phải cấp quyền quá rộng để người dùng hoàn thành công việc, hoặc một công việc thường xuyên phải chuyển sang tài khoản khác vì mô hình quyền không phù hợp, đây là vấn đề về fit chứ không đơn thuần là trải nghiệm người dùng.

Về dữ liệu, nên xác định nguồn dữ liệu nào là nguồn chính, dữ liệu nào phải được tái sử dụng và dữ liệu nào cần truyền sang hệ thống khác. Công nghệ càng làm tăng nhập liệu trùng, đối chiếu thủ công hoặc sao chép giữa hệ thống thì chi phí vận hành càng cao.

Về kiểm soát, cần giữ được các yêu cầu thực sự có ý nghĩa như phân tách nhiệm vụ, phê duyệt theo thẩm quyền, lịch sử thay đổi hoặc điều kiện bắt buộc trước khi chuyển bước. Tự động hóa nhanh hơn nhưng làm mất kiểm soát cần thiết không thể được xem là phù hợp.

Về chất lượng bản thân sản phẩm công nghệ, doanh nghiệp có thể sử dụng các mô hình tiêu chuẩn như ISO/IEC 25010:2023 để xem xét các đặc tính chất lượng của sản phẩm ICT và phần mềm. Tiêu chuẩn này cung cấp mô hình gồm chín đặc tính chất lượng dùng cho việc xác định yêu cầu và đánh giá sản phẩm. Tuy nhiên, chất lượng sản phẩm và mức phù hợp với quy trình là hai lớp đánh giá khác nhau: đạt các đặc tính chất lượng không tự động chứng minh rằng hệ thống hỗ trợ đúng cách doanh nghiệp cần vận hành.

Xác nhận mức độ phù hợp bằng KPI trước và sau thử nghiệm

Đánh giá bằng workshop hoặc demo chỉ cho biết công nghệ có vẻ phù hợp. Để biết nó có thực sự cải thiện quy trình hay không, doanh nghiệp cần một baseline trước triển khai và số đo sau pilot trên cùng phạm vi công việc.

Các KPI nên phản ánh trực tiếp mục tiêu của quy trình. APQC nhóm chỉ số hiệu suất quy trình theo các khía cạnh như hiệu quả chi phí, năng suất nhân sự, hiệu quả quy trình và cycle time; ví dụ có thời gian xử lý, tỷ lệ lỗi, mức độ tự động hóa hoặc chi phí trên một đơn vị đầu ra. APQC cũng lưu ý rằng chỉ số phù hợp phải phụ thuộc vào mục tiêu, ranh giới, stakeholder và bối cảnh của từng quy trình.

Đối với việc đánh giá công nghệ, một bộ số đo thực tế có thể bao gồm:

·         Thời gian hoàn thành toàn bộ quy trình

·         Thời gian chờ giữa các bước

·         Số lần chuyển giao

·         Số thao tác thủ công

·         Số lần nhập lại cùng dữ liệu

·         Tỷ lệ lỗi hoặc phải làm lại

·         Tỷ lệ trường hợp phải xử lý ngoài hệ thống

·         Thời gian xử lý ngoại lệ

·         Tỷ lệ hoàn thành công việc trong hệ thống

·         Số lỗi tích hợp hoặc đồng bộ dữ liệu

Không cần đặt một ngưỡng chung cho mọi doanh nghiệp. Cycle time của quy trình kế toán, bán hàng và nhân sự có bản chất khác nhau, nên một con số “chuẩn” duy nhất dễ dẫn tới kết luận sai. Benchmark hữu ích nhất trước tiên là baseline của chính quy trình hiện tại, sau đó mới so sánh với mục tiêu nội bộ hoặc benchmark bên ngoài có cùng phạm vi đo.

Ví dụ, nếu pilot giảm thời gian thao tác tại một bước nhưng lại tạo thêm hai lần chuyển giao và nhiều trường hợp xử lý ngoài hệ thống, kết quả không thể được đánh giá chỉ dựa trên tốc độ của bước đó. Chỉ số phải được đọc ở cấp độ end-to-end.

Ra quyết định dựa trên tổng chi phí thích nghi, không chỉ mức đáp ứng chức năng

Kết luận về mức độ phù hợp nên dựa trên cả giá trị nhận được và chi phí để quy trình thích nghi với công nghệ.

Một công nghệ có mức fit cao khi phần lớn luồng việc cốt lõi được hỗ trợ trực tiếp hoặc cấu hình hợp lý; dữ liệu đi xuyên suốt; vai trò và kiểm soát được giữ đúng; ngoại lệ có cách xử lý rõ; các KPI quan trọng cải thiện; và số thay đổi cưỡng bức đối với quy trình ở mức thấp.

Ngược lại, công nghệ có mức fit thấp khi doanh nghiệp phải xây nhiều workaround, tăng nhập liệu thủ công, chia một luồng thành nhiều hệ thống, thay đổi trách nhiệm chỉ vì giới hạn sản phẩm hoặc phát triển tùy chỉnh đáng kể để đạt những yêu cầu vốn là hoạt động bình thường của quy trình.

Khi hai giải pháp đều đáp ứng được chức năng, nên ưu tiên giải pháp tạo ít “chi phí thích nghi” hơn. Chi phí này không chỉ là tiền triển khai mà còn gồm đào tạo, thay đổi vai trò, duy trì tùy chỉnh, xử lý ngoại lệ, kiểm soát thủ công và khối lượng công việc phát sinh sau khi hệ thống đi vào vận hành.

Cách đánh giá thực tế nhất là lập ma trận cho từng quy trình cốt lõi với các tiêu chí: hỗ trợ luồng việc, mức thay đổi bắt buộc, dữ liệu và tích hợp, vai trò và kiểm soát, xử lý ngoại lệ, khả năng đo lường kết quả và chi phí duy trì. Trọng số không nên được sao chép từ một mẫu cố định; quy trình có rủi ro kiểm soát cao sẽ cần trọng số khác quy trình thiên về tốc độ hoặc năng suất.

Công nghệ phù hợp với quy trình doanh nghiệp được xác định bằng khả năng hỗ trợ công việc thực tế từ đầu đến cuối với ít ma sát và ít thay đổi không tạo giá trị. Đánh giá nên bắt đầu từ bản đồ quy trình, kiểm tra từng bước và ngoại lệ, xác định những thay đổi mà hệ thống buộc doanh nghiệp phải thực hiện, rồi xác nhận bằng KPI trước và sau pilot.

Một giải pháp vì thế không nên được chọn chỉ vì đáp ứng nhiều yêu cầu chức năng. Mức phù hợp cao hơn thuộc về giải pháp giúp luồng việc chạy liền mạch, giữ đúng dữ liệu và kiểm soát cần thiết, giảm thao tác ngoài hệ thống và cải thiện kết quả đo được mà không buộc doanh nghiệp phải tái thiết kế quy trình chỉ để phục vụ giới hạn của công nghệ.

Công nghệ có phải phù hợp 100% với quy trình hiện tại không?

Không. Một phần quy trình hiện tại có thể chứa thao tác dư thừa và nên thay đổi. Điều cần phân biệt là thay đổi tạo giá trị với thay đổi chỉ nhằm bù cho giới hạn của công nghệ.

Có thể đánh giá mức độ phù hợp chỉ bằng demo của nhà cung cấp không?

Không nên. Demo giúp kiểm tra khả năng chức năng nhưng khó phản ánh đầy đủ dữ liệu thực tế, ngoại lệ, khối lượng giao dịch, tích hợp và hành vi người dùng. Pilot trên một luồng đại diện cho phép kiểm chứng mức phù hợp bằng KPI thực tế.

Khi nào tùy chỉnh hệ thống vẫn là lựa chọn hợp lý?

Tùy chỉnh có thể hợp lý khi yêu cầu phản ánh một kiểm soát, điều kiện nghiệp vụ hoặc năng lực tạo giá trị thực sự quan trọng và giải pháp chuẩn không đáp ứng được. Nếu phải tùy chỉnh nhiều chỉ để tái tạo những hoạt động phổ biến của quy trình, đó lại là tín hiệu cần xem xét mức độ phù hợp của nền tảng.