1. Tổng quan — Vì sao phải đánh giá nhu cầu bài bản
Ở Bài 1, chúng ta đã thấy Việt Solution — công ty dịch vụ kế toán thuế 18 nhân sự, 120 khách hàng — quyết định đầu tư ERP sau khi Excel bắt đầu "gãy". Nhưng quyết định đầu tư chỉ là bước khởi đầu. Trước khi chọn nhà cung cấp hay phần mềm nào, ban giám đốc dành trọn 2 tháng chỉ để đánh giá nhu cầu.
Nhiều công ty coi bước đánh giá nhu cầu là thủ tục hình thức — gọi nhà cung cấp đến, nghe thuyết trình, ký hợp đồng. Việt Solution từng suýt rơi vào cái bẫy đó. May mắn là giám đốc nhớ một câu nói của người đi trước: "ERP thất bại không phải vì phần mềm dở, mà vì doanh nghiệp không biết mình cần gì." Vì vậy, 2 tháng đánh giá nhu cầu trở thành giai đoạn quan trọng nhất trong toàn bộ dự án.
Bài này kể chi tiết cách Việt Solution đánh giá nhu cầu: từ việc khảo sát nội bộ, phân loại "nỗi đau", đến xác định yêu cầu cốt lõi và xây dựng bản tổng kết nhu cầu để làm kim chỉ nam cho việc chọn nhà cung cấp ở Bài 3.
2. Thách thức — Khi "nỗi đau" nằm rải rác trong công ty
2.1 Mỗi người cảm nhận một vấn đề khác nhau
Khi giám đốc Việt Solution hỏi 18 nhân viên rằng "Vấn đề lớn nhất của công ty là gì?", anh nhận được 18 câu trả lời khác nhau:
| Vị trí | Nỗi đau lớn nhất (theo cảm nhận) |
|---|---|
| Giám đốc | Không nhìn được tổng quan tiến độ |
| Kế toán trưởng | Trễ deadline, không phân bổ được nhân sự |
| Kế toán viên A | Phải nhập lại số liệu nhiều lần |
| Kế toán viên B | Tìm chứng từ cũ rất mất thời gian |
| Chuyên viên thuế | Không cập nhật kịp thay đổi luật |
| Hành chính | Quản lý hợp đồng dịch vụ lộn xộn |
Mỗi người đúng một phần, nhưng không ai nhìn thấy bức tranh tổng thể. Nếu dựa vào cảm nhận để chọn ERP, công ty sẽ mua một phần mềm giải quyết vấn đề của người nói to nhất — thường là người than phiền nhiều nhất — và bỏ sót vấn đề thật sự cốt lõi.
2.2 Phân biệt "nỗi đau" và "triệu chứng"
Một sai lầm phổ biến là nhầm lẫn giữa triệu chứng (điều ta thấy) và nỗi đau thật sự (nguyên nhân gốc). Ví dụ: kế toán viên than phiền "nhập số liệu nhiều lần" — đó là triệu chứng. Nỗi đau gốc là thiếu tích hợp giữa các bước quy trình, khiến dữ liệu phải chuyển tay giữa Excel, phần mềm kế toán và tờ khai thuế.
Việt Solution phải dành thời gian để phân biệt rõ: đâu là triệu chứng có thể giải quyết bằng quy trình mới, đâu là vấn đề cần công nghệ hỗ trợ. Bảng dưới đây tóm tắt kết quả phân tích:
| Triệu chứng (mọi người phàn nàn) | Nỗi đau gốc (nguyên nhân thật) |
|---|---|
| Nhập số liệu nhiều lần | Thiếu tích hợp giữa kế toán và tờ khai |
| Tìm chứng từ chậm | Lưu trữ phân tán, không có chỉ mục |
| Trễ deadline | Không có hệ thống nhắc nhở tự động |
| Giám đốc "mù" thông tin | Không có dashboard tổng hợp |
| Sai sót số liệu | Nhập tay, không có kiểm tra tự động |
| Khách hàng phàn nàn | Không có cổng trực tuyến cho khách |
2.3 "Want" vs "Need" — Cái muốn và cái cần
Khi khảo sát, nhân viên thường đưa ra một danh sách dài yêu cầu — nhưng không phải yêu cầu nào cũng cần thiết. Ví dụ: kế toán viên muốn ERP có tính năng "tự động điền tên khách hàng khi gõ 2 chữ cái đầu". Đó là want (cái muốn) — tiện, nhưng không giải quyết vấn đề cốt lõi. Trong khi đó, "tự động nhắc trước deadline 7 ngày" là need (cái cần) — giải quyết trực tiếp nỗi đau trễ deadline.
Việt Solution áp dụng nguyên tắc: moi tất cả ý kiến ra, rồi dùng ma trận ưu tiên để phân loại. Phần tiếp theo sẽ trình bày chi tiết phương pháp này.
3. Phương pháp đánh giá nhu cầu — 4 bước bài bản
Việt Solution thực hiện đánh giá nhu cầu theo 4 bước, hoàn tất trong 2 tháng.
Bước 1: Khảo sát nội bộ (Tuần 1-2)
Giám đốc và kế toán trưởng phỏng vấn toàn bộ 18 nhân viên, mỗi người 45-60 phút. Mục tiêu không phải là thu thập "yêu cầu tính năng", mà là hiểu quy trình làm việc hiện tại và điểm nghẽn trong quy trình đó.
Bảng câu hỏi phỏng vấn được chuẩn bị trước:
1. Mô tả công việc hàng ngày của bạn (từng bước)
2. Bước nào tốn nhiều thời gian nhất?
3. Bước nào hay xảy ra sai sót?
4. Bạn phải dùng bao nhiêu phần mềm/file Excel khác nhau?
5. Khi cần thông tin từ phòng khác, bạn lấy ở đâu?
6. Điều gì khiến bạn khó chịu nhất trong công việc?
7. Nếu có một phép thuật thay đổi một việc, bạn muốn thay đổi gì?Kết quả phỏng vấn được tổng hợp thành bản đồ quy trình As-Is (hiện trạng) — một sơ đồ trực quan cho thấy công việc chảy từ bước này sang bước khác, và nơi nào bị tắc nghẽn.
Bước 2: Phân tích điểm nghẽn (Tuần 3)
Từ bản đồ quy trình As-Is, ban dự án xác định 5 điểm nghẽn lớn nhất:
| Điểm nghẽn | Tần suất xảy ra | Tác động | Mức độ |
|---|---|---|---|
| Thu thập chứng từ chậm | 40% khách hàng | Trễ toàn bộ quy trình | Nghiêm trọng |
| Nhập liệu trùng lặp | Mỗi khách hàng | Sai sót, tốn thời gian | Nghiêm trọng |
| Kiểm tra đối chiếu thủ công | Cuối tháng | Phát hiện lỗi muộn | Trung bình |
| Không có nhắc deadline | Hàng ngày | Trễ kê khai | Nghiêm trọng |
| Báo cáo cho giám đốc | Cuối tuần | Quyết định chậm | Trung bình |
3 trong 5 điểm nghẽn được xếp mức "nghiêm trọng" — đây chính là vùng cần ERP can thiệp ưu tiên.
Bước 3: Ma trận ưu tiên nhu cầu (Tuần 4)
Ban dự án gom tất cả yêu cầu từ phỏng vấn thành danh sách 47 yêu cầu. Để không bị ngợp, họ xếp mỗi yêu cầu vào ma trận ưu tiên theo hai trục:
- Tác động (cao/trung bình/thấp): yêu cầu này giải quyết được vấn đề nghiêm trọng không?
- Tần suất (thường xuyên/thỉnh thoảng): vấn đề xảy ra hàng ngày hay hàng tháng?
Kết quả phân loại:
| Hạng | Tác động × Tần suất | Số yêu cầu | Ví dụ |
|---|---|---|---|
| Phải có (Must) | Cao × Thường xuyên | 12 | Tự động nhắc deadline, tích hợp kê khai |
| Nên có (Should) | Cao × Thỉnh thoảng | 10 | Báo cáo tự động cho giám đốc |
| Có thì tốt (Nice) | Trung bình | 15 | Tự động điền tên khách hàng |
| Để sau (Later) | Thấp | 10 | Tích hợp mạng xã hội |
Chỉ 12 yêu cầu "Must" mới là yêu cầu cốt lõi — phần còn lại là điểm cộng. Sự phân loại này giúp công ty không bị phân tán và không trả tiền cho tính năng không cần thiết.
Bước 4: Bản tổng kết nhu cầu (Tuần 5-8)
12 yêu cầu "Must" được biên soạn thành Bản tổng kết nhu cầu (Requirements Document) — tài liệu chính thức sẽ gửi cho các nhà cung cấp ERP để họ đưa ra giải pháp. Mỗi yêu cầu được mô tả theo cấu trúc:
Mã yêu cầu: REQ-001
Tên: Tự động nhắc deadline kê khai thuế
Mô tả: Hệ thống tự động sinh công việc và gửi email nhắc nhở
cho kế toán viên trước deadline kê khai theo lịch của
từng khách hàng
Người dùng: Kế toán viên, Giám đốc
Tần suất: Hàng tháng, theo lịch kê khai
Tiêu chí chấp nhận: Nhắc trước 7 ngày và 3 ngày; cảnh báo
giám đốc nếu trễ
Mức ưu tiên: Must (Phải có)Tài liệu gồm 12 yêu cầu như vậy, dài khoảng 15 trang. Đây là vũ khí quan trọng nhất khi đàm phán với nhà cung cấp — vì nó biến cuộc trò chuyện từ "anh có tính năng này không?" thành "đây là nhu cầu của tôi, anh giải quyết thế nào?".
4. Một yêu cầu cốt lõi — Theo dõi deadline tự động
Trong 12 yêu cầu "Must", có một yêu cầu nổi bật là THEN CHỐT đối với ngành dịch vụ kế toán thuế: theo dõi và nhắc deadline kê khai tự động. Đây là ví dụ điển hình cho việc biến một "nỗi đau" thành "yêu cầu kỹ thuật" rõ ràng.
4.1 Vấn đề hiện trạng
Trước ERP, mỗi kế toán viên phụ trách 8-10 khách hàng, mỗi khách hàng có 3-5 loại deadline. Tức là mỗi người phải theo dõi 30-50 deadline mỗi tháng — bằng cách ghi vào lịch cá nhân, sổ tay, hoặc... trí nhớ. Trong tháng cao điểm (cuối quý), số deadline có thể tăng gấp đôi vì thêm báo cáo tài chính quý.
Hệ quả: 14 lần trễ deadline trong năm 2023, dẫn đến 5 khách hàng rời đi.
4.2 Yêu cầu kỹ thuật
Hệ thống ERP phải đáp ứng:
- Lưu lịch kê khai cho từng khách hàng: Mỗi khách hàng có một bộ lịch riêng, tùy theo loại hình doanh nghiệp và lịch sử kê khai
- Tự động sinh công việc: Trước deadline 7 ngày, hệ thống tự tạo công việc "chuẩn bị kê khai" gán cho kế toán viên phụ trách
- Nhắc nhở nhiều tầng: Email nhắc trước 7 ngày, nhắc lại trước 3 ngày, nhắc khẩn trước 1 ngày
- Cảnh báo leo thang: Nếu còn 1 ngày mà chưa hoàn thành, tự động thông báo cho kế toán trưởng; nếu trễ, thông báo cho giám đốc
- Dashboard tổng quan: Giám đốc nhìn thấy tất cả deadline sắp tới, trạng thái từng cái (chưa bắt đầu/đang xử lý/đã nộp/trễ)
- Lưu vết kiểm soát: Ghi lại ai nộp khi nào, số biên nhận, để đối chứng nếu có tranh chấp
4.3 Tiêu chí đo lường thành công
Yêu cầu này được xem là "đáp ứng" chỉ khi:
- Số lần trễ deadline giảm từ 14/năm xuống dưới 2/năm
- Giám đốc có thể trả lời câu hỏi "bao nhiêu khách sắp trễ?" trong dưới 10 giây (mở dashboard)
- Kế toán viên không cần tự ghi deadline vào lịch cá nhân nữa — hệ thống lo hết
5. Những sai lầm cần tránh khi đánh giá nhu cầu
Việt Solution may mắn tránh được nhiều sai lầm nhờ kiên nhẫn, nhưng cũng suýt mắc phải vài cái. Dưới đây là những sai lầm phổ biến mà công ty dịch vụ kế toán thuế dễ vấp phải.
5.1 Sao chép yêu cầu từ công ty khác
Nhiều công ty lấy danh sách yêu cầu của doanh nghiệp khác (thường là nhà cung cấp đưa ra "best practice") và dùng luôn. Vấn đề: quy trình của công ty dịch vụ kế toán thuế rất khác so với công ty thương mại hay sản xuất. Yêu cầu "quản lý kho" chẳng hạn — gần như vô dụng cho công ty dịch vụ.
Việt Solution gần như sa vào bẫy này khi một nhà cung cấp gửi bản "yêu cầu ERP tiêu chuẩn cho SME" dài 80 trang. May mà kế toán trưởng nhận ra rằng 60% yêu cầu trong đó không liên quan đến công ty dịch vụ, và quyết định viết lại từ đầu dựa trên khảo sát nội bộ.
5.2 Bỏ qua yêu cầu của khách hàng
Khi đánh giá nhu cầu, công ty thường chỉ hỏi nhân viên nội bộ mà quên khách hàng — người thật sự sử dụng dịch vụ. Việt Solution phỏng vấn 15 khách hàng đại diện và phát hiện ra yêu cầu mà nội bộ không nghĩ tới: cổng trực tuyến để tải chứng từ và xem tiến độ.
Khách hàng phàn nàn rằng việc gửi chứng từ qua email rồi không biết công ty đã nhận chưa, xử lý đến đâu, rất bất an. Yêu cầu này trở thành một trong 12 yêu cầu "Must" — và sau này là một trong những tính năng được khách hàng đánh giá cao nhất.
5.3 Quá tham lam — muốn giải quyết mọi thứ một lúc
Sau khi khảo sát, ban dự án muốn ERP giải quyết cả 47 yêu cầu luôn. Nhưng kinh nghiệm cho thấy càng tham, càng thất bại — vì phạm vi rộng khiến triển khai kéo dài, nhân viên mệt mỏi, và không tính năng nào hoàn thiện thật sự.
Giải pháp: tập trung vào 12 yêu cầu "Must" trong giai đoạn đầu. 10 yêu cầu "Should" để cho giai đoạn 2 (sau 6 tháng). 15 yêu cầu "Nice" và 10 "Later" — thành thật mà nói, có thể không bao giờ cần.
5.4 Không lượng hóa được "thành công"
Một yêu cầu phổ biến nhưng nguy hiểm: "Hệ thống phải dễ dùng". Dễ dùng với ai? Dễ đến mức nào? Làm sao đo? Nếu không lượng hóa, nhà cung cấp sẽ nói "dễ lắm" và doanh nghiệp không có cơ sở để phản bác.
Việt Solution lượng hóa mọi yêu cầu. Ví dụ với "dễ dùng": "Nhân viên mới sau 2 giờ đào tạo phải thực hiện được quy trình kê khai cơ bản độc lập, không cần hỗ trợ". Đây là tiêu chí có thể kiểm chứng, không phải lời hứa suông.
6. Kết quả — Bản tổng kết nhu cầu và ứng dụng
Sau 2 tháng, Việt Solution hoàn tất Bản tổng kết nhu cầu gồm:
- 12 yêu cầu "Must" (phải có) — mô tả chi tiết, có tiêu chí chấp nhận
- 10 yêu cầu "Should" (nên có) — ưu tiên sau
- 15 yêu cầu "Nice" (có thì tốt) — điểm cộng
- 10 yêu cầu "Later" (để sau) — ghi nhận nhưng không ưu tiên
6.1 Cách sử dụng bản tổng kết nhu cầu
Tài liệu này có 3 công dụng chính:
- Gửi cho nhà cung cấp: Thay vì nghe nhà cung cấp thuyết trình về tính năng, công ty gửi tài liệu và yêu cầu họ trả lời từng yêu cầu — giải quyết thế nào, bằng tính năng nào, cần tùy biến bao nhiêu
- Đánh giá so sánh: Khi có nhiều phương án, dùng 12 yêu cầu "Must" làm tiêu chí chốt — nhà cung cấp nào đáp ứng nhiều nhất sẽ vào vòng trong
- Kiểm tra nghiệm thu: Khi triển khai xong, dùng 12 yêu cầu "Must" làm bảng kiểm nghiệm thu — nhà cung cấp chỉ được thanh toán khoản cuối khi tất cả yêu cầu được đáp ứng
6.2 Sự khác biệt so với cách tiếp cận "nghe thuyết trình"
| Cách tiếp cận "nghe thuyết trình" | Cách tiếp cận "có bản tổng kết nhu cầu" |
|---|---|
| Nhà cung cấp trình bày ưu điểm | Doanh nghiệp chủ động đặt câu hỏi |
| Bị dẫn dắt bởi demo đẹp | So sánh dựa trên nhu cầu thực tế |
| Quyết định dựa trên cảm tính | Quyết định dựa trên bảng điểm |
| Sau triển khai mới phát hiện thiếu | Biết trước nhà cung cấp nào thiếu gì |
7. Bài học rút ra
7.1 Dành cho công ty dịch vụ kế toán thuế
- Đánh giá nhu cầu là khoản đầu tư, không phải chi phí: 2 tháng dành cho đánh giá nhu cầu giúp Việt Solution tránh được việc chọn sai nhà cung cấp — có thể tốn hàng trăm triệu và 1 năm công sức. Đây là khoản đầu tư sinh lời cao nhất trong toàn bộ dự án
- Phân biệt "Must" và "Nice": Không phải yêu cầu nào cũng như nhau. 12 yêu cầu "Must" của Việt Solution có thể khác công ty khác — nhưng nguyên tắc phân loại thì giống nhau. Tập trung vào "Must", gác lại "Nice"
- Hỏi khách hàng, không chỉ hỏi nội bộ: Yêu cầu cổng trực tuyến — tính năng được đánh giá cao nhất sau này — đến từ khách hàng, không phải nhân viên. Khách hàng là người sử dụng dịch vụ cuối cùng, tiếng nói của họ quan trọng không kém
- Lượng hóa mọi thứ: "Dễ dùng", "nhanh", "chính xác" — nếu không lượng hóa, sẽ bị nhà cung cấp lách. Mỗi yêu cầu phải có tiêu chí chấp nhận đo lường được
7.2 Lời khuyên từ Giám đốc Việt Solution
"Ban đầu tôi sốt ruột — tại sao phải mất 2 tháng chỉ để viết tài liệu nhu cầu trong khi nhà cung cấp sẵn sàng ký hợp đồng ngay hôm nay? Nhưng rồi tôi nhận ra: nếu không biết mình cần gì, nhà cung cấp sẽ nói cho tôi biết tôi cần gì — và đó thường là thứ họ muốn bán, không phải thứ tôi cần. Bản tổng kết nhu cầu là tấm khiên bảo vệ tôi khỏi những lời hứa hẹn suông. Khi tôi đưa 12 yêu cầu 'Must' ra, nhà cung cấp phải trả lời từng cái một, không thể lấp liếm. Đó là lúc cuộc đàm phán ngược lại — tôi mới là người đặt câu hỏi."
8. Kết luận
Đánh giá nhu cầu là bước nhàn nhạt nhất nhưng quan trọng nhất trong dự án ERP. Không có demo đẹp, không có phần mềm mới để khám phá, chỉ có phỏng vấn, ghi chép, và phân tích. Nhưng chính 2 tháng này quyết định 80% thành bại của toàn bộ dự án.
Câu chuyện của Việt Solution cho thấy: đừng để nhà cung cấp định nghĩa nhu cầu cho bạn. Hãy tự khảo sát, tự phân tích, tự phân loại. Bản tổng kết nhu cầu — dù thô sơ — vẫn tốt hơn một bài thuyết trình hoàn hảo của nhà cung cấp. Vì khi bạn biết mình cần gì, bạn mới biết nhà cung cấp nào thật sự phù hợp.
Bài tiếp theo (Bài 3) sẽ kể tiếp: Việt Solution dùng bản tổng kết nhu cầu này để đánh giá và chọn nhà cung cấp như thế nào — từ việc lọc 8 ứng viên xuống còn 1, và những tiêu chí nào đã giúp họ đưa ra quyết định đúng.
Nguyên tắc vàng: "Không có ERP 'tốt nhất' — chỉ có ERP 'phù hợp nhất'. Và để biết cái nào phù hợp, bạn phải biết mình cần gì trước khi hỏi nhà cung cấp có gì. Bản tổng kết nhu cầu chính là câu trả lời cho 'tôi cần gì'."