Hôm nay tôi sẽ chia sẻ những trải nghiệm của mình liên quan đến quy trình nghiệp vụ. Xây dựng quy trình nghiệp vụ tương lai phù hợp khi đưa hệ thống vào vận hành cũng là một trong những công việc khó khăn, quan trọng và cũng rất thú vị trong quá trình tư vấn triển khai hệ thống ERP vào doanh nghiệp. Do tôi có trải nghiệm và nghiên cứu về Best Practices của Oracle, SAP nên sẽ dùng mô hình của các giải pháp này để diễn giải cho bài viết của mình.

Cần nắm rõ kiến trúc quy trình nghiệp vụ (business process model) khi xây dựng và chuẩn hóa quy trình nghiệp vụ tương lai (to-be business process). 

Đầu tiên tôi chia sẻ về kiến trúc phân cấp của quy trình theo các Levels chuẩn: Đối với SAP sẽ có 6 cấp còn Oracle sẽ có 5 cấp. Cùng thể hiện một vấn đề nhưng do hai hãng chọn 2 chuẩn khác nhau dẫn đến cách phân cấp khác nhau. Oracle theo chuẩn BPMN (Business Process Model and Notation) trong khi SAP lại theo chuẩn EPC (Event-driven Process Chain). 

Trên các diễn đàn về BPM thì rất nhiều đề tài tranh luận liên quan đến ưu nhược điểm của BPMN và EPC, nhưng nhìn chung BPMN phổ biến, đa dạng hơn, giới công nghệ thích dùng hơn còn EPC thì team kinh doanh, tài chính thích hơn, riêng về ERP thì có vẻ EPC được đánh giá cao hơn (Lưu ý là 2 chuẩn khác nhau nên hệ thống ký hiệu để vẽ quy trình cũng khác nhau). 

Sơ đố EPC (Event-driven Process Chain)

Chúng ta sẽ không đi sâu vào vấn đề này, quan trọng là chúng ta hiểu để vận dụng vào công việc thực tế, bạn nào quan tâm thì có thể tìm hiểu thêm (nếu tìm hiểu chuẩn EPC thì có thể đọc thêm về công cụ ARIS). 

Mô hình 5 cấp sẽ bao gồm (xem hình minh họa):

• L0: Industry: Chuyên ngành / mô hình kinh doanh
• L1: Business process area: Nhóm chức năng như Mua hàng, Kho, Tài chính, Sản xuất, Bán hàng…
• L2: Business process: Các quy trình nghiệp vụ
• L3: Activity: Chức năng cụ thể, bước thực hiện cụ thể trên quy trình
• L4: Task: Các thao tác cụ thể ở từng bước  

Thông qua kiến trúc này thì 3 cấp đầu tiên (L0 – L2) sẽ giải thích về các khái niệm, dùng ngôn ngữ nghiệp vụ để diễn giải quy trình, hoàn toàn không đề cập đến một hệ thống cụ thể nào (business-driven). Vì vậy theo kinh nghiệm của tôi, trước khi nghĩ đến việc đầu tư hệ thống ERP, DN cần mô hình và cụ thể được đến L2 bằng ngôn ngữ nghiệp vụ. Cụ thể là làm rõ được ba thành phần quan trọng: Tổ chức (Organization), Danh mục dùng chung (Master Data) và Quy trình tác nghiệp (Business Process). Trong trường hợp chưa sẵn sàng cho ba thành phần trên thì hoặc là phải thuê đơn vị tư vấn chiến lược, tái cấu trúc để hình thành, hoặc có thể tham khảo Best Practices ở mô hình tương tự (thông qua các đơn vị tư vấn độc lập, đơn vị tư vấn triển khai ERP uy tín có sẵn Best Practices).

Như vậy việc triển khai một giải pháp ERP cụ thể chủ yếu tác động đến L3 – L4: dùng chức năng của hệ thống để hiện thực quy trình ở L2. Một bước cụ thể trên quy trình có thể được thực hiện thủ công hoặc thông qua một chức năng trên hệ thống (L3), để hoàn thành chức năng đó – người sử dụng phải thực hiện vài công việc khác nhau (L4). Đối với các hệ thống ERP lớn như Oracle thì Best Practices của hãng đã hỗ trợ mô hình sẵn các quy trình từ L0 – L3, chi tiết đến từng ngành công nghiệp.

Thực tế triển khai, nhiều người nói quy trình chuẩn theo Best Practices không phù hợp dẫn đến sử dụng không hiệu quả. Điều này thật ra cũng không phải là vấn đề lớn, vì đối với các hệ thống ERP tốt thì khả năng cấu hình khá linh động, hơn nữa theo kiến trúc quy trình, thì sự phù hợp thường nằm ở L3 (chức năng) – L4 (thao tác) chứ không nằm hoàn toàn ở quy trình (L2). Thường thì các đối tác triển khai có kinh nghiệm, có hiểu biết sâu về sản phẩm thì họ giải quyết vấn đề khác biệt này rất giỏi, đó cũng cái “chất” tạo nên sự khác biệt trong dịch vụ tư vấn triển khai của từng đối tác.  

Kể cả khi hệ thống ERP đã đưa vào vận hành trong doanh nghiệp, việc nắm bắt được kiến trúc, mối liên hệ giữa các quy trình cũng giúp cho doanh nghiệp dễ dàng phân tích tác động mỗi khi bổ sung, thay đổi quy trình, thực hiện các bước phân tích tác động cho phù hợp tránh tiền hậu bất nhất, vô tình phá vỡ kiến trúc của hệ thống, ảnh hưởng đến hiệu quả khai thác hệ thống.

Khi tham gia tư vấn triển khai các dự án ERP, nhất là đối với các DN VN thường quy trình không được rõ ràng, nhất quán. Ở quy mô nhỏ thì không sao, nhưng khi tăng trưởng, mở rộng hoặc khi thực hiện giao thương với các đối tác bên ngoài, đòi hỏi chuẩn mực cao thì họ thường gặp trở ngại rất lớn. Bây giờ theo tôi thì môi trường kinh doanh và hội nhập rất cao nên mọi thứ đã tốt hơn rất nhiều, nên thường khi triển khai ERP, sự thay đổi về quy trình cũng có nhưng không nhiều, không thay đổi lớn như cách đây 10 năm. 

Tôi cũng ngạc nhiên là kiến thức về quy trình nghiệp vụ rất cơ bản và được chú trọng đào tạo tại các trường nước ngoài, nhất là nhóm ngành kinh tế và IT, sinh viên được đào tạo mảng chuyên môn này sẽ tiếp cận môi trường làm việc dễ dàng, tiếp cận các hệ thống quản trị cũng thuận lợi. Còn ở Việt Nam có vẻ như chưa được quan tâm và phổ cập đúng mức, các bạn sinh viên ra trường hầu như chẳng biết gì về khái niệm quy trình nghiệp vụ.

Bản thân tôi ban đầu cũng không có khái niệm gì về quy trình nghiệp vụ, nhưng may mắn tham gia nhiều dự án có đòi hòi cao trong việc xây dựng và chuẩn hóa quy trình kinh doanh, nên có điều kiện học tập và trau dồi, cũng được nhiều lời khuyên từ những người thầy trong lĩnh vực tư vấn triển khai ERP, đa số đều khuyên: Phải nắm được Business Process trước khi tìm hiểu chức năng, quy trình trên hệ thống. Vì vậy tôi dành nhiều thời gian để đọc và nghiên cứu Best Practices từ Oracle và SAP, học cách tổ chức quy trình trong đó, cách ứng dụng nó để hiện thực các quy trình kinh doanh trong doanh nghiệp và quan sát mức độ phù hợp khi ứng dụng để điều chỉnh giải pháp, chức năng cho phù hợp. Đối với tôi, mô hình kinh doanh và quy trình tác nghiệp quan trọng hơn hệ thống.

Tác giả: Aidt AronCo-Founder, ARON Consulting Services