Trong quá trình thiết kế và triển khai các hệ thống quản lý, tôi đã trực tiếp xây dựng, soạn thảo và triển khai nhiều quy trình vận hành hiệu quả theo phương thức truyền thống.
Các quy trình được ban hành, đào tạo và triển khai một cách bài bản. Người thực hiện hiểu rõ vai trò của mình; người quản lý biết khi nào cần can thiệp, vấn đề nào cần chuyển tiếp, trường hợp nào phải mở hành động khắc phục, dữ liệu nào cần tổng hợp và khi nào một vấn đề thực sự được xem là khép lại.
Có thể nói, các quy trình đó đang được triển khai và vận hành thông suốt trong thực tế. Nhưng khi chính những quy trình ấy được chuyển sang môi trường số, đặc biệt trong các dự án ERP, một khoảng cách đáng chú ý bắt đầu xuất hiện:
Một quy trình có thể vận hành rất hiệu quả trong thực tế, nhưng để trở thành một quy trình số, nó vẫn cần được chuyển hóa và tinh chỉnh ở một lớp sâu hơn — từ logic xử lý, dữ liệu, trạng thái đến các điểm kết nối với những quy trình khác.
Từ đó, vấn đề không còn đơn thuần là “đưa quy trình lên phần mềm”. Nó trở thành một bài toán về kiến trúc vận hành số: làm thế nào để những gì trước đây được con người hiểu, ghi nhớ, phán đoán và kết nối có thể được chuyển hóa thành logic mà hệ thống có khả năng nhận biết, xử lý và điều phối một cách nhất quán.
Trong hệ thống truyền thống, một phần logic vận hành nằm ở con người
Hãy bắt đầu từ một tình huống khá điển hình.
Một cuộc kiểm tra phát hiện vấn đề. Người thực hiện ghi nhận kết quả; những sai lệch đơn giản có thể được xử lý ngay, trong khi các trường hợp bất thường, nghiêm trọng hoặc có tính lặp lại sẽ được chuyển sang bước điều tra, xử lý sự không phù hợp hoặc CAPA.
Trong môi trường vận hành truyền thống, quá trình này thường diễn ra khá tự nhiên.
Một người quản lý có kinh nghiệm có thể nhanh chóng nhận biết:
Mức độ nghiêm trọng của phát hiện;
Có cần điều tra nguyên nhân hay không;
Vấn đề có liên quan đến một sự việc đã từng xảy ra hay không;
Khi nào cần khởi tạo CAPA;
Trách nhiệm xử lý thuộc về đơn vị nào;
Hồ sơ nào cần được tham chiếu hoặc liên kết;
Tại thời điểm nào vấn đề có thể thực sự được xem là khép lại.
Không phải tất cả những quyết định đó đều cần được mô tả thành từng bước chi tiết trong SOP.
Trong thực tế, một phần đáng kể logic vận hành được thực hiện thông qua kinh nghiệm, khả năng phán đoán, hiểu biết bối cảnh và năng lực kết nối tổng thể của người quản lý hệ thống.
Bởi vậy, một quy định như: “Các phát hiện bất thường hoặc không phù hợp được chuyển sang quy trình xử lý tương ứng.” có thể đã đủ rõ để một người có chuyên môn hiểu và thực hiện đúng. Nhưng khi chuyển sang môi trường số, chữ “tương ứng” lại trở thành một bài toán hoàn toàn khác.
Phần mềm không hiểu chữ “tương ứng” nếu logic phía sau chưa được định nghĩa
Hệ thống số không thể dựa vào kinh nghiệm hay sự hiểu ngầm. Để có thể nhận biết, xử lý và điều phối công việc, những logic trước đây nằm trong con người phải được chuyển hóa thành các điều kiện rõ ràng.
Chẳng hạn như:
Nếu một phát hiện đồng thời liên quan đến an toàn thực phẩm và thiết bị thì hệ thống cần tạo một hồ sơ, nhiều hồ sơ hay chỉ thiết lập các liên kết liên quan?
Nếu đã tồn tại một CAPA đang mở đối với cùng vấn đề hoặc nguyên nhân, hệ thống sẽ liên kết với hồ sơ hiện hữu hay khởi tạo một CAPA mới?
Dữ liệu nào được kế thừa từ hồ sơ nguồn và dữ liệu nào phải được bổ sung?
Đầu ra của quy trình A trở thành đầu vào hoặc điểm kích hoạt của quy trình B như thế nào?
Khi quy trình B hoàn thành, trạng thái của A có cần được cập nhật tự động hay không?
Nếu hành động khắc phục được đánh giá là chưa hiệu lực, hệ thống sẽ mở lại hồ sơ cũ, tạo một vòng xử lý tiếp theo hay khởi tạo một case mới?
Những câu hỏi như vậy có thể trước đây được một người quản lý giàu kinh nghiệm xử lý gần như tự nhiên. Nhưng khi số hóa, chúng phải được nhận diện, chuẩn hóa và chuyển thành các quy tắc nghiệp vụ (business rules), trạng thái, điều kiện kích hoạt và cơ chế liên kết cụ thể.
Vì vậy, một câu tương đối đơn giản trong SOP đôi khi có thể được chuyển hóa thành hàng chục logic xử lý trong hệ thống. Điều cần số hóa không chỉ là các bước của quy trình, mà còn là những logic và mối liên hệ mà trước đây con người vẫn âm thầm xử lý ở khoảng giữa các bước đó.
Đây chính là lý do một quy trình có thể đang vận hành rất hiệu quả trong thực tế nhưng vẫn cần được chuyển hóa và tinh chỉnh ở một lớp sâu hơn trước khi trở thành một quy trình số.
Và khi nhiều quy trình cùng được đưa lên môi trường số, bài toán còn đi xa hơn: không chỉ từng quy trình phải vận hành đúng, mà các quy trình còn phải được thiết kế để kết nối đúng với nhau trong một kiến trúc chung.
Sự khác biệt giữa phần mềm quản lý và một hệ thống quản trị số
Ngày nay, số hóa từng chức năng hoặc từng quy trình riêng lẻ không còn là một bài toán quá khó. Trên thị trường đã có nhiều giải pháp tương đối hoàn chỉnh cho các lĩnh vực như HRM, CRM, WMS, DMS, LMS, kế toán, quản lý thanh toán, quản lý công việc hay quản lý tài liệu. Doanh nghiệp có thể tương đối dễ dàng lựa chọn một nền tảng phù hợp, cấu hình quy trình, thiết lập phân quyền và phê duyệt, lưu trữ hồ sơ, theo dõi trạng thái và tạo báo cáo. Ở cấp độ từng bộ phận hoặc từng nghiệp vụ, các giải pháp đó hoàn toàn có thể vận hành rất tốt.
Vấn đề bắt đầu xuất hiện khi doanh nghiệp đặt ra yêu cầu quản trị số ở cấp độ toàn tổ chức, trong khi từng phần mềm lại được xây dựng hoặc lựa chọn như một giải pháp độc lập, thay vì được nhìn nhận ngay từ đầu như một mảnh ghép trong kiến trúc vận hành số tổng thể.
Cần nhìn nhận rõ rằng, một hệ thống số không được hình thành chỉ bằng việc đặt nhiều phần mềm cạnh nhau. Giá trị của nó nằm ở cách các mảnh ghép được thiết kế để kết nối, dùng chung hoặc trao đổi dữ liệu theo một logic thống nhất, từ đó hình thành dòng thông tin xuyên suốt phục vụ vận hành và quản trị. Nếu những kết nối này không được tính đến ngay từ đầu, từng phần mềm vẫn có thể hoạt động rất tốt trong phạm vi riêng của nó, nhưng ở cấp độ toàn tổ chức, sự phân mảnh lại ngày càng lớn hơn.
Đó chính là ranh giới giữa phần mềm quản lý và hệ thống số.
Phần mềm giúp một công việc hoặc một quy trình được quản lý tốt hơn.
Hệ thống số làm cho nhiều quy trình có thể kết nối, trao đổi dữ liệu và điều phối với nhau như những thành phần của cùng một cơ chế vận hành.
Và nếu các “mảnh ghép” không được thiết kế để tương thích với nhau ngay từ đầu, doanh nghiệp có thể số hóa rất nhiều hoạt động nhưng vẫn chưa hình thành được một hệ thống quản trị số thực sự.
Đừng chỉ số hóa quy trình. Hãy số hóa dòng chảy của công việc.
Khi chuyển từ hệ thống quản lý sang hệ thống quản trị số, câu hỏi không nên chỉ dừng ở: “Quy trình này có những bước nào?” mà cần đi xa hơn: “Quy trình này được kích hoạt từ đâu, nhận dữ liệu gì, tạo ra kết quả gì và kết quả đó sẽ tiếp tục được sử dụng như thế nào trong hệ thống phía sau?”
Theo cách nhìn đó, một quy trình không còn là một chuỗi bước độc lập, mà là một mắt xích trong dòng vận hành tổng thể của tổ chức.
Một cách tiếp cận hữu ích khi thiết kế quy trình số là nhìn quy trình qua sáu lớp: Sự kiện kích hoạt (Trigger) → Đầu vào (Input) → Logic xử lý (Process Logic) → Điểm quyết định (Decision) → Đầu ra (Output) → Điểm kết nối (Connection).
Trong đó, điểm kết nối (Connection) thường là lớp dễ bị bỏ qua nhất. Một quy trình có thể được thiết kế rất tốt khi đứng riêng, nhưng toàn bộ hệ thống vẫn vận hành kém nếu đầu ra của nó không được cấu trúc để trở thành đầu vào phù hợp cho quy trình tiếp theo.
Vì vậy, giá trị của số hóa không nằm ở việc mỗi quy trình đều có một workflow riêng, mà ở khả năng duy trì tính liên tục của dữ liệu, trách nhiệm và trạng thái khi công việc đi qua nhiều quy trình khác nhau.
Điều đó đòi hỏi các điểm nối phải được thiết kế rõ ràng:
Đầu ra nào trở thành đầu vào;
Dữ liệu nào được kế thừa;
Sự kiện nào kích hoạt bước tiếp theo;
Trách nhiệm được chuyển tại thời điểm nào;
Trạng thái nào cần được phản hồi về hồ sơ nguồn;
Điểm nào nên được tự động hóa, điểm nào vẫn cần phán đoán của con người.
Khi những yếu tố này được kiến trúc nhất quán, các quy trình không còn chỉ đứng cạnh nhau trong cùng một nền tảng. Chúng bắt đầu vận hành như những thành phần của một hệ thống thống nhất.
Đừng bắt đầu bằng việc số hóa từng quy trình. Hãy bắt đầu bằng cách hiểu dòng công việc đi xuyên qua hệ thống như thế nào. Bởi trong thực tế, ranh giới của công việc hiếm khi trùng hoàn toàn với ranh giới của một quy trình. Và chính dòng chảy xuyên suốt đó mới là đối tượng cần được kiến trúc nếu doanh nghiệp muốn đi từ số hóa công việc đến quản trị số thực sự.
Chuẩn hóa để số hóa, và số hóa để tiếp tục cải tiến
Có một quan điểm khá phổ biến: “Phải chuẩn hóa quy trình xong rồi mới số hóa.” Điều này đúng. Một quy trình chưa rõ trách nhiệm, logic xử lý, đầu vào – đầu ra hay điểm kiểm soát sẽ rất khó được chuyển lên hệ thống một cách hiệu quả.
Nhưng đó mới chỉ là một chiều. Ở chiều ngược lại, chính quá trình số hóa lại buộc tổ chức phải nhìn quy trình ở mức chi tiết và có cấu trúc hơn. Những điểm trước đây có thể được xử lý bằng kinh nghiệm, thói quen hoặc sự phối hợp ngầm giữa con người sẽ phải được làm rõ thành dữ liệu, trạng thái, quy tắc nghiệp vụ, điều kiện kích hoạt và điểm kết nối.
Qua đó, doanh nghiệp thường nhận ra:
Bước nào còn thực sự tạo giá trị;
Dữ liệu nào đang bị nhập lặp;
Phê duyệt nào có thể được tinh giản;
Điểm chuyển giao nào chưa rõ;
Thông tin nào có thể kế thừa thay vì nhập lại;
Những quy trình nào cần được thiết kế lại để kết nối tốt hơn với toàn hệ thống.
Vì vậy, chuẩn hóa và số hóa không nên được nhìn như hai giai đoạn tách biệt theo một chiều tuyến tính.
Quy trình được chuẩn hóa tốt là nền tảng để số hóa; và số hóa một cách chuẩn mực lại tạo cơ hội để tổ chức tiếp tục tinh chỉnh, đơn giản hóa và nâng cấp chính quy trình vận hành của mình.
Đó cũng là lý do một quy trình đã vận hành hiệu quả trong thực tế vẫn có thể cần được điều chỉnh khi chuyển sang môi trường số.
Điều cốt lõi của chuyển đổi số
Nếu ngày mai người quản lý giỏi nhất của một quy trình không còn ở đó, liệu hệ thống của doanh nghiệp có vẫn biết:
Một vấn đề phải được xử lý theo luồng nào, liên kết với dữ liệu nào, ai chịu trách nhiệm, khi nào bước tiếp theo được kích hoạt và đến đâu thì thực sự được xem là khép lại?
Nếu câu trả lời là chưa, thì doanh nghiệp có thể đã số hóa công việc, nhưng chưa thực sự số hóa hệ thống vận hành. Bởi giá trị sâu nhất của chuyển đổi số không nằm ở việc đưa công việc lên phần mềm, mà ở khả năng chuyển những logic, mối liên hệ và cơ chế điều phối vốn phụ thuộc vào con người thành một kiến trúc có thể vận hành nhất quán, minh bạch và bền vững.
Và có lẽ, đó mới là nơi hành trình chuyển đổi số thực sự bắt đầu.
Nguyễn Ngọc Thanh Hoa, CQP MCQI Founder, SoConn Vietnam
PEOPLE — SYSTEMS — SUSTAINABILITY
Governance is not control — it’s connection.