Trong nhiều năm làm việc với các hệ thống chất lượng, an toàn, an ninh, dịch vụ, an toàn thực phẩm và chuyển đổi doanh nghiệp, tôi thường gặp một câu hỏi tưởng như rất đơn giản: “Chị đang làm công việc gì?” Cách gọi “chuyên gia tư vấn hệ thống quản lý” đúng, nhưng chưa phản ánh đầy đủ công việc thực tế.
Tôi cũng có thể nói mình là PM/BA trong các dự án ERP và chuyển đổi số. Tuy nhiên, PM/BA chỉ là một phần của vai trò. Tôi thường bước vào doanh nghiệp khi bài toán còn phân mảnh, yêu cầu chưa rõ, các phòng ban nhìn vấn đề theo những cách khác nhau và chưa ai kết nối được toàn bộ bức tranh.
Công việc của tôi là nhìn thấy bài toán hệ thống phía sau những vấn đề vận hành riêng lẻ; chuyển mục tiêu quản trị thành quy trình, trách nhiệm, dữ liệu và cơ chế kiểm soát; kết nối tiêu chuẩn quốc tế với điều kiện thực tế; chuyển nhu cầu nghiệp vụ thành yêu cầu đủ rõ để đội ngũ công nghệ xây dựng; và đồng hành cho đến khi hệ thống thực sự vận hành, được kiểm soát và tiếp tục cải tiến.
Một vai trò ở gần tuyến đầu của doanh nghiệp
Trong thế giới công nghệ, cách làm này có nét tương đồng với mô hình Forward Deployed Engineer (FDE): một chuyên gia làm việc gần tuyến đầu cùng khách hàng để nhận diện vấn đề, xây dựng giải pháp và đưa giải pháp vào thực tế. Tuy nhiên, phạm vi công việc của tôi rộng hơn công nghệ.
Tôi làm việc tại giao điểm của Governance – Management Systems – Operations – People – Sustainability – Digital Transformation. Có thể mô tả đó là vai trò Forward-Deployed Transformation Architect — cách SoConn định nghĩa một chuyên gia kiến trúc và triển khai chuyển đổi trực tiếp tại doanh nghiệp. Đây không phải một chức danh chuẩn hóa; đó là cách diễn đạt phạm vi trách nhiệm: nhìn toàn hệ thống, kết nối các năng lực chuyên môn và giúp thiết kế trở thành thực hành.
Doanh nghiệp hiếm khi bắt đầu bằng một yêu cầu rõ ràng
Những bài toán khó thường không xuất hiện dưới dạng một bản yêu cầu hoàn chỉnh. Chúng xuất hiện qua các dấu hiệu rất cụ thể:
- Tài liệu nằm ở nhiều nơi, phiên bản không được kiểm soát;
- Sự cố được ghi nhận nhưng không theo dõi đến khi hoàn tất hành động khắc phục;
- Nhiều phòng ban cùng tham gia nhưng trách nhiệm bị đứt gãy;
- Dữ liệu được tổng hợp thủ công qua nhiều bảng tính;
- ERP có nhiều chức năng nhưng chưa phản ánh đúng cách doanh nghiệp vận hành;
- Chứng nhận ISO tồn tại nhưng chưa hỗ trợ hiệu quả quản trị;
- ESG dừng ở báo cáo, chưa trở thành dữ liệu, trách nhiệm và cơ chế quyết định;
- Đào tạo được tổ chức thường xuyên nhưng chưa chứng minh được năng lực sau đào tạo;
- Nhà cung cấp công nghệ chờ yêu cầu, trong khi người sử dụng chưa biết cách diễn đạt yêu cầu.
Nếu xử lý từng biểu hiện riêng lẻ, doanh nghiệp có thể tạo thêm biểu mẫu, thủ tục hoặc phần mềm nhưng vấn đề gốc vẫn còn nguyên. Điều cần thiết trước tiên không phải là chọn công nghệ, mà là nhìn đúng bài toán.
Bắt đầu từ nơi vấn đề thực sự xảy ra
Tôi không bắt đầu bằng câu hỏi “Doanh nghiệp muốn áp dụng tiêu chuẩn hoặc phần mềm nào?”. Tôi bắt đầu từ kết quả cần đạt, điểm nghẽn, dữ liệu dùng để ra quyết định, nơi trách nhiệm bị đứt gãy, rủi ro bị bỏ sót và điều kiện vận hành thực tế.
Đây không phải hoạt động tư vấn đứng bên ngoài doanh nghiệp. Đó là quá trình đồng kiến tạo tại nơi hệ thống sẽ được sử dụng.
Công nghệ chỉ là một cấu phần của hệ thống
Phần mềm không thể tự giải quyết trách nhiệm không rõ, quy trình thiếu logic, dữ liệu không có chủ sở hữu, tiêu chí phê duyệt không thống nhất, ngoại lệ chưa được nhận diện hay người dùng chưa được chuẩn bị. Nếu những nền tảng này chưa được xử lý, công nghệ chỉ số hóa sự phân mảnh đang có.
Trong một dự án ERP, vai trò của tôi vì thế không dừng ở việc thu thập yêu cầu rồi chuyển cho đội phát triển. Tôi cần hiểu mô hình vận hành, xác định phạm vi, phân tích hiện trạng, đồng thiết kế quy trình tương lai, làm rõ trách nhiệm, dữ liệu, yêu cầu nghiệp vụ, thay đổi phạm vi và tiêu chí nghiệm thu.
Điểm gặp nhau giữa quản trị, nghiệp vụ và công nghệ: Hệ thống cần hỗ trợ quyết định nào? Quy trình nào phải được chuẩn hóa trước khi số hóa? Ai được khởi tạo, kiểm tra, phê duyệt và đóng hồ sơ? Ngoại lệ được xử lý ra sao? Điều kiện nào phải được đáp ứng trước khi đưa vào vận hành?
Không “đưa ISO vào doanh nghiệp”
Khi làm việc với ISO 9001, ISO 22000, ISO/IEC 27001, ISO/IEC 20000, HACCP hoặc các hệ thống quản lý khác, mục tiêu không phải là tạo một bộ tài liệu để đạt chứng nhận. Tiêu chuẩn chỉ tạo ra giá trị khi được chuyển hóa thành cơ chế vận hành phù hợp, kết nối bối cảnh và chiến lược; quá trình và trách nhiệm; rủi ro và kiểm soát; dữ liệu và quyết định; đánh giá và cải tiến; năng lực con người và kết quả.
Trong hàng không, công nghệ hàng không và dịch vụ phòng chờ, tôi đã tham gia thiết kế và triển khai những kiến trúc tích hợp chất lượng, an toàn, an ninh, an toàn thông tin, quản lý dịch vụ CNTT, an toàn thực phẩm, chuỗi cung ứng và năng lực vận hành. Điểm chung không nằm ở số lượng tiêu chuẩn, mà ở yêu cầu nhìn doanh nghiệp như một hệ thống thống nhất.
ESG phải được xây dựng như một hệ thống quản trị
ESG không nên bắt đầu từ một báo cáo đẹp. Nó cần bắt đầu từ tính trọng yếu, trách nhiệm, cấu trúc dữ liệu, phương pháp tính, bằng chứng, quản trị rủi ro và cơ chế xem xét của lãnh đạo. Khi những nền tảng này chưa tồn tại, ESG vẫn chỉ là một lớp thông tin nằm bên ngoài hoạt động kinh doanh.
Cách tiếp cận của tôi là: xây hệ thống ESG trước khi kể câu chuyện ESG. Hệ thống đó bao gồm kiến trúc quản trị, đánh giá trọng yếu, dữ liệu, kiểm kê khí nhà kính, cơ chế MRV, trách nhiệm giải trình, chuỗi cung ứng, xem xét của lãnh đạo và mức độ sẵn sàng cho đảm bảo độc lập.
Với F&B, tiêu chuẩn phải đi đến tận điểm phục vụ
Một hệ thống an toàn thực phẩm không thể chỉ tồn tại trong sổ tay HACCP. Nó phải hiện diện tại khâu tiếp nhận, bảo quản, sơ chế, nấu chín, giữ nóng, bảo quản lạnh, trưng bày, phục vụ, vệ sinh, quản lý dị ứng và ứng phó sự cố.
Một giới hạn nhiệt độ chỉ có ý nghĩa khi có người chịu trách nhiệm đo, thiết bị phù hợp, dữ liệu được ghi nhận, cảnh báo khi vượt giới hạn và hành động rõ ràng khi xảy ra sai lệch. Một quy trình chỉ thực sự tồn tại khi nhân viên có thể thực hiện trong điều kiện ca kíp, lưu lượng khách biến động và áp lực phục vụ thực tế. Vì vậy, thiết kế hệ thống luôn phải gắn với đào tạo và chứng minh năng lực.
AI mở ra khả năng mới nhưng không thay thế tư duy hệ thống
AI có thể hỗ trợ phân tích yêu cầu, mô hình hóa quy trình, tạo bản mẫu, thiết kế logic kiểm soát, phân tích dữ liệu, xây dựng tác tử, hỗ trợ kiểm thử và tự động hóa công việc lặp lại. Nhưng khả năng tạo nhanh không đồng nghĩa với khả năng tạo đúng.
Câu hỏi quan trọng không phải “AI có thể làm gì?”, mà là: trong doanh nghiệp này, tại thời điểm này, AI nên tham gia vào công việc nào, với dữ liệu nào, trong giới hạn nào và dưới cơ chế kiểm soát nào? Có bài toán cần AI; có bài toán chỉ cần tự động hóa luồng công việc; có bài toán phải thiết kế lại quy trình; và có quyết định cuối cùng phải thuộc về con người.
Giá trị nằm ở khả năng kết nối những thế giới khác nhau
Trong một chương trình chuyển đổi, mỗi bên nắm giữ một phần của sự thật: lãnh đạo hiểu chiến lược; người vận hành hiểu công việc hằng ngày; chuyên gia tiêu chuẩn hiểu nguyên tắc kiểm soát; công nghệ hiểu kiến trúc và giới hạn nền tảng; nhà cung cấp hiểu sản phẩm của họ.
Nếu không có người kết nối, doanh nghiệp dễ nhận được giải pháp đúng về kỹ thuật nhưng sai về nghiệp vụ; đúng theo tiêu chuẩn nhưng khó vận hành; hoặc đáp ứng trước mắt nhưng không thể mở rộng. Đôi khi giá trị lớn nhất không phải đưa ra ngay một giải pháp, mà là đủ độc lập để nói: “Chúng ta đang giải sai vấn đề.”
Không thay thế chuyên gia — thiết kế để chuyên môn phối hợp
Tôi không thay thế lập trình viên, chuyên gia tài chính, chuyên gia môi trường hoặc chủ sở hữu quy trình. Vai trò của tôi là thiết kế cấu trúc để các năng lực đó phối hợp nhất quán: xác định ranh giới, liên kết, trách nhiệm, dữ liệu đầu vào và đầu ra, tiêu chí kiểm soát và cơ chế ra quyết định.
Vì vậy, cần phân biệt rõ kiến trúc với cấu hình; yêu cầu nghiệp vụ với giải pháp kỹ thuật; trách nhiệm tư vấn với thẩm quyền quyết định; quản trị triển khai với phát triển phần mềm; và chứng nhận với hiệu lực thực tế của hệ thống.
Một tổ hợp năng lực được tích lũy qua thực tiễn
Từ tư vấn viên đến đối tác đồng kiến tạo
Doanh nghiệp ngày càng ít cần những báo cáo đứng độc lập với quá trình triển khai. Họ cần một đối tác có thể đi cùng từ vấn đề đến giải pháp, từ thiết kế đến vận hành và từ vận hành đến cải tiến.
Điều này đặc biệt quan trọng với các dự án Greenfield, nơi mô hình, cơ sở hoặc hệ thống mới được kiến tạo từ nền móng đầu tiên. Đây là cơ hội thiết kế đồng bộ quản trị, vận hành, tiêu chuẩn, dữ liệu, công nghệ và năng lực con người theo nguyên tắc Prevention by Design — phòng ngừa thông qua thiết kế.
Cách tôi định nghĩa công việc của mình
Tôi là Nguyễn Ngọc Thanh Hoa, CQP MCQI — Founder SoConn Vietnam, chuyên gia tư vấn độc lập và kiến trúc sư hệ thống trong các lĩnh vực quản trị tích hợp, chất lượng, hàng không, ESG và chuyển đổi doanh nghiệp.
Tôi không bán riêng một tiêu chuẩn, không bắt đầu bằng một phần mềm và không áp đặt mô hình có sẵn. Tôi bắt đầu từ bối cảnh và mục tiêu của tổ chức; xây dựng nền tảng quản trị; tiếp thu có chọn lọc tiêu chuẩn và thực hành tốt; sau đó chuyển hóa thành một hệ thống phù hợp với con người, nguồn lực và điều kiện vận hành.
Governance is not control — it’s connection.
Quản trị không chỉ là kiểm soát. Quản trị là tạo ra những kết nối đúng để toàn bộ hệ thống có thể cùng vận hành, thích ứng và phát triển. Đó cũng là tinh thần dẫn dắt phương pháp đồng kiến tạo của SoConn.