Phương pháp xác định yêu cầu trong triển khai ERP 

Việc triển khai thành công một Hệ thống ERP không phụ thuộc vào chất lượng của phần mềm mà phụ thuộc vào chất lượng của dữ liệu đầu vào. Dữ liệu đầu vào quan trọng nhất chính là yêu cầu nghiệp vụ được xác định từ các phòng ban. Yêu cầu không rõ ràng, mơ hồ chính là nguyên nhân số một dẫn đến GAP sai, Customization sai, và phạm vi dự án (Scope) bị mở rộng không kiểm soát.

1. Yêu cầu không rõ ràng là nguyên nhân số một gây thất bại dự án ERP. 

Vậy yêu cầu trong triển khai ERP là gì?

Yêu cầu trong triển khai ERP là tập hợp các điều kiện, khả năng, hoặc nhu cầu bắt buộc mà hệ thống mới phải đáp ứng để giải quyết một vấn đề kinh doanh hoặc đạt được một mục tiêu chiến lược.

Yêu cầu được phân loại để dễ dàng quản lý:

 Yêu cầu chức năng (Functional Requirements): Liên quan trực tiếp đến các nghiệp vụ cốt lõi mà người dùng cần thực hiện (ví dụ: tạo Lệnh sản xuất, tính giá vốn theo phương pháp FIFO, tự động tạo Báo cáo Thuế).

​ Yêu cầu phi chức năng (Non-Functional Requirements): Liên quan đến chất lượng, hiệu suất, và giới hạn hoạt động của hệ thống (ví dụ: Hệ thống phải xử lý 5000 giao dịch mỗi giờ, thời gian phản hồi dưới 2 giây, tính năng bảo mật cấp cao).

Tuy nhiên, thách thức lớn nhất không nằm ở việc phân loại, mà ở việc thu thập và diễn giải yêu cầu một cách chính xác.

2. Hậu quả của việc diễn giải sai lệch yêu cầu từ người dùng

Yêu cầu ban đầu từ người dùng cuối thường chứa đựng nhiều rào cản khiến đội tư vấn dễ bị diễn giải sai, dẫn đến phân tích GAP sai và chức năng tùy chỉnh không đạt mục tiêu:

2.1. Rào cản diễn giải và hậu quả tài chính

Yêu cầu từ người dùng thường được trình bày theo cảm tính hoặc thói quen cũ, không theo cấu trúc dữ liệu logic, dẫn đến sự diễn giải sai lệch:

 Thiếu mô tả chi tiết Pain Point (Vấn đề cốt lõi): Người dùng thường trình bày giải pháp họ muốn ("Tôi cần một nút X") thay vì xác định vấn đề cốt lõi (Pain Point) ("Vấn đề là chúng tôi phải mất 4 giờ để tính toán thủ công"). Thiếu Pain Point, đội tư vấn lập trình ra một tính năng tốn kém nhưng không giải quyết được vấn đề kinh doanh gốc.

 Thiếu tính lượng hóa dữ liệu và quy trình: Yêu cầu trở nên mơ hồ nếu không thể tính toán, đo lường được bằng công thức hoặc quy trình logic. Yêu cầu phải được diễn giải thành:

- Các bước cần làm cụ thể (Workflow/Flowchart) trên hệ thống.

- Logic IF/THEN hoặc công thức tính toán rõ ràng. Nếu một yêu cầu không thể chuyển thành logic này, hệ thống sẽ không thể tự động hóa.

2.2 Nguy cơ tùy chỉnh sai và mất kiểm soát

Khi đội dự án chấp nhận các yêu cầu mơ hồ hoặc mâu thuẫn giữa các phòng ban ("Cái nhìn Silo"), họ sẽ tiến hành tùy chỉnh sai. Hậu quả là:

 Tăng chi phí vượt ngân sách: Phát triển tính năng không giải quyết được vấn đề gốc.

 Hệ thống bị từ chối: Chức năng tùy chỉnh không khả thi trên thực tế, buộc người dùng quay lại làm việc thủ công.

3. Phương pháp luận chuẩn hóa quá trình xác định và đánh giá yêu cầu

Để chuyển đổi yêu cầu từ người dùng thành các tính năng có thể triển khai được và kiểm soát chi phí, doanh nghiệp cần áp dụng các phương pháp luận đánh giá nội bộ nghiêm ngặt:

3.1. Phân loại và ưu tiên yêu cầu (Prioritization Matrix)

Doanh nghiệp phải tự đánh giá được yêu cầu nào là cần thiết bằng cách phân loại chúng dựa trên tính bắt buộc:

 Must Have (Bắt buộc): Các yêu cầu mà nếu thiếu, doanh nghiệp không thể hoạt động hợp pháp hoặc không thể thực hiện quy trình cốt lõi tạo ra lợi thế cạnh tranh. Đây là nhóm duy nhất được ưu tiên Customization.

 Nice to Have / Should Have (Nên có): Các yêu cầu giúp cải thiện hiệu suất hoặc tiện lợi, nhưng không ảnh hưởng đến hoạt động cốt lõi.

3.2. Nguyên tắc ROI và phương án Workaround

Đối với các yêu cầu thuộc nhóm Nice to Have, doanh nghiệp nên tìm kiếm phương án Workaround (Giải pháp thay thế tạm thời) trước khi cân nhắc Customization.

 Workaround: Là giải pháp sử dụng kết hợp tính năng ERP có sẵn với một số bước thủ công nhỏ (ví dụ: dùng bộ lọc và xuất dữ liệu ra Excel để xử lý báo cáo tùy biến, thay vì lập trình một báo cáo hoàn toàn mới).

 ROI là nguyên tắc vàng để quyết định tính cần thiết và hiệu quả của một yêu cầu tùy chỉnh (Customization) lớn. ROI giúp chuyển yêu cầu từ mức độ "mong muốn" sang mức độ "Đầu tư có cơ sở". Doanh nghiệp phải thực hiện tính toán khách quan các yếu tố sau:

a) Tính toán lợi ích (Benefit)

Lợi ích là giá trị kinh doanh có thể định lượng được mà yêu cầu này mang lại. Đây là thước đo hiệu quả dự kiến:

 Giá trị tài chính: Chi phí vận hành được tiết kiệm (ví dụ: giảm chi phí nhân công, giảm lỗi xử lý), doanh thu tăng thêm, hoặc khả năng tuân thủ pháp lý (tránh phạt).

 Giá trị vận hành: Thời gian xử lý được rút ngắn, cải thiện độ chính xác dữ liệu, hoặc tăng tốc độ phản hồi khách hàng.

b) Tính toán chi phí (Cost)

Chi phí không chỉ là chi phí phát triển ban đầu, mà là tổng chi phí sở hữu yêu cầu đó:

 Chi phí Customization (Phát triển): Chi phí lập trình và kiểm thử ban đầu của tính năng tùy chỉnh.

 Chi phí vòng đời (TCO - Total Cost of Ownership): Chi phí bảo trì, chi phí nâng cấp, và rủi ro tích hợp liên quan đến việc giữ lại tính năng tùy chỉnh đó trong suốt vòng đời của hệ thống.

 Chi phí thay đổi quy trình: Chi phí đào tạo lại nhân viên, và thời gian làm quen/thích nghi với quy trình mới.

 Quyết định: Một yêu cầu chỉ nên được tùy chỉnh nếu ROI > 1 (tức là lợi ích vượt trội hơn chi phí) và nó phải thuộc nhóm Must Have (Bắt buộc). Nếu ROI thấp, yêu cầu đó phải được xử lý bằng giải pháp Workaround hoặc hoãn lại.

3.3. Áp dụng kỹ thuật đào sâu vấn đề

Đội dự án cần chuyển từ lắng nghe yêu cầu bề mặt sang đào sâu vào lý do của yêu cầu bằng các kỹ thuật như "5 Whys" (Hỏi "Tại sao" 5 lần). Kỹ thuật này giúp chuyển yêu cầu người dùng thành vấn đề nghiệp vụ gốc (ví dụ: "Tại sao cần in thêm mã vạch?"  "Để đảm bảo nhân viên kho quét đúng sản phẩm để giảm lỗi giao hàng").

Đọc thêm: FIT & GAP Analysis là gì? Phương pháp kiểm soát rủi ro và chi phí trong triển khai ERP?

4. Đội ngũ triển khai ERP cần làm gì để gợi mở yêu cầu như Key User?

Vai trò của đội ngũ triển khai (chuyên gia tư vấn) không chỉ là lắng nghe và ghi nhận, mà là dẫn dắt quá trình phân tích. Họ cần áp dụng các kỹ thuật đối thoại và phân tích chuyên môn để chuyển yêu cầu bề mặt thành logic nghiệp vụ có thể triển khai được.

4.1. Chuyển đổi yêu cầu từ "Giải pháp" sang "Vấn đề cốt lõi"

Chuyên gia tư vấn phải thách thức yêu cầu của Key User bằng cách tập trung vào "Lý do tại sao" (The Why):

 Áp dụng kỹ thuật "5 Whys" (5 Ws): Đây là kỹ thuật đào sâu: Hỏi "Tại sao" (Why) lặp đi lặp lại (thường là 5 lần) để truy vấn đến tận cùng của vấn đề nghiệp vụ, thay vì chấp nhận yêu cầu bề mặt. Ví dụ: Tại sao cần thêm trường dữ liệu X? -> Tại sao dữ liệu đó quan trọng cho quyết định Y?...

 Phân tích Pain Point: Buộc Key User phải mô tả chi tiết Pain Point (điểm đau) hiện tại, lượng hóa mức độ ảnh hưởng của vấn đề đó (ví dụ: mất 4 giờ/ngày để tổng hợp báo cáo), từ đó xác định xem yêu cầu có thực sự là Must Have hay không.

4.2. Chuẩn hóa yêu cầu thành Logic hệ thống

Yêu cầu chỉ có thể được triển khai nếu nó được diễn giải thành logic máy tính. Đội ngũ triển khai cần giúp Key User chuẩn hóa:

 Yêu cầu lượng hóa: Yêu cầu phải được diễn giải thành các yếu tố có thể đo lường được bằng công thức, tham số (Parameter), hoặc quy tắc (Rule).

 Quy trình mô hình hóa (Process Modeling): Chuyển đổi yêu cầu nghiệp vụ thành sơ đồ luồng (Flowchart) hoặc Workflow chi tiết, xác định rõ ràng các bước cần làm trên hệ thống, các điểm phê duyệt, và các module liên kết.

 Kiểm tra tính nhất quán (Consistency Check): So sánh yêu cầu giữa các phòng ban (ví dụ: Yêu cầu của Kế toán về phê duyệt có mâu thuẫn với yêu cầu Tốc độ của Bán hàng không?), đảm bảo tính liên kết xuyên suốt (End-to-End).

4.3. Đề xuất quy trình TO-BE (Best Practices)

Đội ngũ triển khai cần giữ vững vai trò là chuyên gia, không chỉ làm theo yêu cầu, mà là đề xuất quy trình tốt hơn:

 Trình bày quy trình tiêu chuẩn: Liên tục trình bày các quy trình TO-BE (Best Practices) có sẵn của hệ thống ERP để chỉ ra các giải pháp thay thế hiệu quả, từ đó thách thức Key User thay đổi quy trình nội bộ thay vì tùy chỉnh.

 Thẩm định Customization: Đối với các yêu cầu Must Have, chuyên gia phải thực hiện đánh giá sơ bộ về ROI và Rủi ro kỹ thuật (Technical Risk) ngay tại buổi làm việc, cung cấp dữ liệu đầu vào cho quyết định cuối cùng của lãnh đạo (ví dụ: Tùy chỉnh này sẽ làm tăng chi phí bảo trì hàng năm thêm 10%).

Đọc thêm: UAT là gì? Tại sao lại cần UAT trong triển khai ERP?

5. Kết luận

Việc xác định yêu cầu trong triển khai ERP là một quá trình phân tích dựa trên logic và dữ liệu, chứ không phải là quá trình liệt kê mong muốn. Bằng cách yêu cầu người dùng mô tả Pain Point, lượng hóa các bước nghiệp vụ, và sử dụng phương pháp ROI để ưu tiên Must Have, doanh nghiệp có thể kiểm soát chặt chẽ phạm vi dự án, giảm thiểu rủi ro Customization không cần thiết và đảm bảo hệ thống ERP mới mang lại giá trị kinh doanh thực tế.