Một trong những kỹ năng quan trọng nhất của Business Analyst và ERP Consultant là khả năng mô tả quy trình doanh nghiệp bằng sơ đồ trực quan. Đây là nền tảng để phân tích hiện trạng, xác định điểm nghẽn (Pain Point), và thiết kế giải pháp ERP thực sự phù hợp với nhu cầu vận hành của từng doanh nghiệp.
Trong hầu hết các dự án ERP thành công, việc xây dựng sơ đồ As-Is (hiện trạng) và To-Be (tương lai mong muốn) luôn là bước không thể thiếu. Hành trình chuẩn của một dự án thường đi từ việc ghi nhận hiện trạng, vẽ sơ đồ As-Is, xác định các điểm nghẽn, thiết kế sơ đồ To-Be, chuyển hóa thành giải pháp ERP cụ thể, và cuối cùng đưa hệ thống vào vận hành chính thức (Go-live). Nếu bước hiểu As-Is không chính xác ngay từ đầu, sơ đồ To-Be xây dựng dựa trên đó cũng sẽ thiếu chính xác theo.
1. As-Is là gì?
As-Is là bản mô tả chi tiết cách doanh nghiệp đang thực sự vận hành ở thời điểm hiện tại, bao gồm cả những phần chưa tối ưu hoặc còn mang tính thủ công. Ví dụ, một quy trình As-Is điển hình trong bán hàng có thể đi qua các bước: khách hàng gửi yêu cầu, đội Sales lập báo giá, gửi báo giá dưới dạng file Excel cho khách hàng, khách hàng xác nhận, tạo đơn hàng, xuất kho, và cuối cùng kế toán xuất hóa đơn thanh toán.
Mục tiêu của việc vẽ As-Is không phải để đánh giá đúng sai, mà để hiểu chính xác hiện trạng đang vận hành như thế nào, làm nền tảng cho các bước phân tích tiếp theo.
2. To-Be là gì?
To-Be là mô hình vận hành mong muốn trong tương lai sau khi doanh nghiệp đã triển khai ERP. Tiếp nối ví dụ ở trên, quy trình To-Be tương ứng có thể được thiết kế lại như sau: cơ hội bán hàng được ghi nhận trên CRM, báo giá được tạo trực tiếp trên hệ thống, chuyển đổi thành đơn hàng bán (Sales Order), liên kết tự động với tồn kho (Inventory), sinh hóa đơn (Invoice) tự động, và toàn bộ dữ liệu được tổng hợp trên dashboard theo thời gian thực. Mục tiêu của To-Be là thiết kế một quy trình tối ưu hơn, loại bỏ những bước thủ công dư thừa và giảm thiểu rủi ro sai sót dữ liệu.
3. Cái giá phải trả khi bỏ qua As-Is và To-Be
Trong một dự án ERP, nhiều doanh nghiệp muốn đi nhanh vào việc cấu hình phần mềm, nhập dữ liệu, và đào tạo người dùng ngay lập tức. Nhưng nếu bỏ qua bước xây dựng As-Is và To-Be một cách bài bản, dự án rất dễ đi sai hướng ngay từ đầu, kéo theo hàng loạt chi phí ẩn xuất hiện nhanh chóng ở những giai đoạn sau.
Hiểu sai yêu cầu ngay từ đầu
Khi chưa có As-Is rõ ràng, đội triển khai chỉ có thể dựa vào những mô tả rời rạc từ từng phòng ban: Sales mô tả theo cách của họ, kế toán mô tả theo cách khác, kho lại có góc nhìn riêng, trong khi ban lãnh đạo lại có kỳ vọng hoàn toàn khác biệt. Kết quả là hệ thống được thiết kế dựa trên cảm nhận chủ quan thay vì dựa trên quy trình thực tế đã được xác nhận, và đến khi chạy thử, người dùng mới phát hiện hệ thống thiếu bước duyệt cần thiết, thiếu biểu mẫu, sai báo cáo, hoặc không phù hợp với cách vận hành thực tế.
Gia tăng yêu cầu phát sinh
Khi không có To-Be rõ ràng làm chuẩn đối chiếu, mọi thay đổi đều có vẻ hợp lý khi được đề xuất riêng lẻ: hôm nay thêm một trường dữ liệu, ngày mai thêm một bước duyệt, tuần sau lại thay đổi quy trình báo giá. Những thay đổi nhỏ lẻ này cộng dồn lại thành khối lượng phát sinh rất lớn, khiến dự án dần mất kiểm soát vì thiếu một bản thiết kế quy trình chuẩn để làm căn cứ đối chiếu.
Tăng chi phí dự án đáng kể
Mỗi lần sửa đổi quy trình đòi hỏi đội dự án phải phân tích lại, cấu hình lại, kiểm thử lại, và đào tạo lại người dùng. Chi phí phát sinh không chỉ nằm ở khoản tiền trả thêm cho đơn vị triển khai, mà còn lớn hơn nhiều ở thời gian của Key User, quản lý, và nhân viên vận hành bị cuốn vào vòng lặp sửa đổi liên tục. Một dự án bị kéo dài thêm hai đến ba tháng có thể khiến doanh nghiệp bỏ lỡ nhiều cơ hội kinh doanh khác trong thời gian đó.
Khó khăn trong đào tạo người dùng
Người dùng khó có thể học tốt nếu họ không hiểu rõ quy trình mới đang được thiết kế cho họ. Nếu chỉ đào tạo theo cách bấm nút trên từng màn hình phần mềm, nhân viên sẽ biết thao tác nhưng không hiểu vì sao cần thực hiện bước đó. Một bản To-Be được xây dựng tốt giúp việc đào tạo trở nên dễ dàng hơn nhiều, vì mỗi chức năng trên hệ thống đều được gắn liền với một nghiệp vụ cụ thể: ai thực hiện, thực hiện khi nào, dữ liệu đầu vào là gì, và kết quả đầu ra là gì.
Khó kiểm soát phạm vi dự án
Không có As-Is và To-Be làm căn cứ, doanh nghiệp rất khó phân biệt đâu là yêu cầu thực sự bắt buộc và đâu chỉ là mong muốn phát sinh thêm trong quá trình triển khai. Dự án vì vậy rất dễ bị kéo rộng phạm vi sang nhiều vấn đề chưa thực sự cần thiết phải xử lý ngay ở giai đoạn này.
Nói tóm lại, một dự án ERP thành công không bắt đầu từ việc cấu hình phần mềm. Nó bắt đầu từ việc hiểu đúng hiện trạng vận hành và thiết kế đúng đắn quy trình mong muốn trong tương lai.
4. Framework xây dựng sơ đồ quy trình
5. Quy trình thực hiện theo sáu bước
Bước đầu tiên là thu thập thông tin thông qua nhiều kênh khác nhau: tổ chức workshop với các phòng ban liên quan, phỏng vấn trực tiếp những người thực hiện công việc hàng ngày, và quan sát thực tế cách vận hành tại hiện trường thay vì chỉ dựa vào mô tả bằng lời.
Bước thứ hai là vẽ sơ đồ As-Is, trong đó cần xác định rõ người thực hiện từng bước, dữ liệu liên quan, trình tự quy trình, và các điểm cần phê duyệt. Bước thứ ba là xác định các điểm nghẽn (Pain Point) cụ thể, ví dụ như tình trạng phải nhập liệu nhiều lần trên nhiều hệ thống khác nhau, dẫn đến sai lệch dữ liệu, và kéo theo báo cáo bị chậm trễ so với yêu cầu thực tế.
Bước thứ tư là thiết kế sơ đồ To-Be, tập trung vào việc loại bỏ những bước không tạo ra giá trị thực sự trong quy trình hiện tại. Bước thứ năm là ánh xạ (mapping) sơ đồ To-Be với các module cụ thể trên hệ thống ERP, ví dụ luồng đi qua CRM, Sales, Purchase, Inventory, và Accounting. Bước cuối cùng là xác nhận lại toàn bộ với khách hàng, đảm bảo có sự đồng thuận rõ ràng trước khi chính thức bước vào giai đoạn triển khai cấu hình hệ thống.
6. Các chỉ số đánh giá chất lượng phân tích As-Is và To-Be
Việc xây dựng As-Is và To-Be không chỉ đơn thuần là vẽ sơ đồ minh họa. Doanh nghiệp cần có những chỉ số rõ ràng để đánh giá chất lượng công tác phân tích nghiệp vụ trước khi bước vào giai đoạn cấu hình hệ thống thực tế.
Độ chính xác của sơ đồ quy trình (Process Mapping Accuracy) đo mức độ sơ đồ phản ánh đúng cách doanh nghiệp đang thực sự vận hành; nếu sơ đồ thiếu bước, sai vai trò, hoặc bỏ sót dữ liệu quan trọng, đội triển khai sẽ hiểu sai bản chất nghiệp vụ ngay từ đầu. Mức độ bao phủ yêu cầu (Requirement Coverage) cho biết các yêu cầu của từng phòng ban đã được ghi nhận đầy đủ hay chưa — nếu chỉ số này thấp, hệ thống sau khi triển khai sẽ thiếu những chức năng quan trọng cần thiết cho vận hành.
Tỷ lệ phát hiện khoảng cách (Gap Identification Rate) giúp doanh nghiệp biết đội dự án đã phát hiện đủ các điểm nghẽn hay chưa, ví dụ dữ liệu vẫn còn nằm rời rạc trên Excel, quy trình phê duyệt chưa được xác định rõ ràng, hay báo cáo vẫn phải tổng hợp thủ công. Mức độ chấp nhận của người dùng (User Acceptance) đo lường mức độ người dùng thực sự hiểu, đồng ý, và sẵn sàng làm theo quy trình mới — bởi ERP chỉ thực sự thành công khi người dùng chấp nhận sử dụng, nếu không hệ thống rất dễ bị bỏ qua sau Go-live. Cuối cùng, tỷ lệ yêu cầu thay đổi (Change Request Rate) phản ánh số lượng yêu cầu phát sinh sau khi đã chốt phạm vi dự án — nếu chỉ số này cao, thường là dấu hiệu cho thấy giai đoạn khảo sát ban đầu chưa đủ sâu hoặc To-Be chưa được xác định rõ ràng ngay từ đầu.
7. Vai trò của ERP trong việc hiện thực hóa To-Be
ERP chính là công cụ giúp hiện thực hóa quy trình To-Be đã thiết kế thành một quy trình vận hành thực tế, có thể đo lường và theo dõi hàng ngày. Nếu As-Is và To-Be là bản thiết kế trên giấy, thì ERP chính là công trình thực tế được xây dựng dựa trên bản thiết kế đó — và chất lượng của công trình phụ thuộc rất nhiều vào chất lượng của bản thiết kế ban đầu.
8. Vai trò của AI trong phân tích quy trình
AI đang hỗ trợ đáng kể công việc phân tích quy trình của Business Analyst và ERP Consultant: sinh sơ đồ quy trình trực quan chỉ từ mô tả bằng văn bản, tóm tắt nhanh nội dung các buổi workshop khảo sát dài, hỗ trợ phát hiện những điểm nghẽn tiềm ẩn dựa trên dữ liệu đã thu thập, và đề xuất những cải tiến quy trình dựa trên các mô hình thực hành tốt trong ngành. Việc kết hợp AI vào giai đoạn phân tích giúp rút ngắn đáng kể thời gian cần thiết để hoàn thành một bộ tài liệu As-Is và To-Be chất lượng cao.
9. Case Study: từ Excel đến dashboard thời gian thực
Một ví dụ thực tế minh họa giá trị của việc phân tích As-Is và To-Be bài bản là trường hợp một doanh nghiệp trong ngành xây dựng, trước đây quản lý toàn bộ dự án bằng các file Excel rời rạc. Ở giai đoạn As-Is, đội phân tích phát hiện dữ liệu bị phân tán trên nhiều file khác nhau và doanh nghiệp không có cách nào theo dõi chính xác chi phí thực tế theo từng dự án cụ thể.
Dựa trên phát hiện đó, đội dự án thiết kế To-Be với hệ thống ERP quản lý dữ liệu tập trung và dashboard hiển thị theo thời gian thực. Sau khi triển khai theo đúng thiết kế đã được xác nhận, doanh nghiệp đã giảm đáng kể thời gian cần thiết để tổng hợp báo cáo hàng tháng, đồng thời kiểm soát lợi nhuận theo từng dự án tốt hơn hẳn so với trước đây.
Kết luận
Việc vẽ sơ đồ As-Is và To-Be không phải là một thủ tục hình thức trong dự án ERP, mà là nền tảng quyết định trực tiếp đến sự thành công của toàn bộ quá trình triển khai sau đó. Một Business Analyst hay ERP Consultant thành thạo kỹ năng này sẽ giúp doanh nghiệp tránh được rất nhiều rủi ro về chi phí phát sinh, phạm vi dự án bị kéo giãn, và khó khăn trong việc đào tạo người dùng — những vấn đề vốn xuất phát từ việc hiểu sai hoặc hiểu chưa đủ sâu về cách doanh nghiệp thực sự đang vận hành.