Quả trứng hay con gà: nên chạy ERP chuẩn trước hay tuỳ biến sâu trước?

Câu trả lời thường được nói ra như một nguyên tắc, mà nguyên tắc thì khó cãi và cũng khó tin. Bài này quy nó ra tiền, và nói rõ lập luận đứng trên đúng ba con số nào — đặt cả ba về 0 thì hai lộ trình bằng nhau.

Trong mọi dự án ERP đều có một lúc phải quyết: đưa hệ thống chuẩn vào chạy trước, hay tuỳ biến sâu theo đặc thù từng bộ phận rồi mới go-live?

Câu trả lời thường được nói ra như một nguyên tắc — dựng khung xương chuẩn trước, kaizen từng bộ phận sau. Nhưng nguyên tắc thì khó cãi mà cũng khó tin. Bài này quy nó ra tiền: sai thứ tự tốn thêm bao nhiêu, và lập luận đó đứng trên đúng ba con số nào.

1. Ba cạm bẫy của "tuỳ biến sâu ngay từ đầu"

Khi ban dự án cố làm hài lòng mọi phòng ban bằng cách chép lại thói quen cũ lên phần mềm mới:

Tự động hoá sự hỗn loạn. Nếu quy trình nền chưa chuẩn, danh mục còn trùng lặp và nguyên tắc hạch toán còn nhập nhằng, tuỳ biến sâu chỉ là dùng công nghệ để số hoá một quy trình sai. Hệ thống mới sẽ tạo ra lỗi nhanh hơn và ở quy mô lớn hơn.

Phá vỡ tính toàn vẹn dữ liệu. Một tính năng may đo cho Kinh doanh có thể giúp Sales thao tác rất nhanh, nhưng dễ bỏ qua ràng buộc hạch toán, làm gãy luồng chứng từ của Kế toán hoặc sai tồn kho khả dụng. Tối ưu cục bộ ở một bộ phận thường tạo tắc nghẽn ở chỗ khác. Đây chính là điều bài đầu tiên gọi là dữ liệu phân mảnh, chỉ khác là lần này doanh nghiệp tự tạo ra nó.

Nợ kỹ thuật. Hàng trăm dòng tuỳ biến viết vội trước ngày go-live biến hệ thống thành một khối chắp vá. Không nâng cấp được, chi phí bảo trì tăng, và lỗi ngầm khó truy.

2. Mô hình ba tầng

Phần này do biên tập viết tiếp từ nguyên tắc mà bài nêu — bản gốc dừng lại trước khi trình bày ba tầng. Đây là cách diễn giải, không phải nguyên văn của tác giả.

Ba tầng phải xong theo thứ tự, vì tầng trên chỉ đứng được khi tầng dưới đã vững.

1. Nền chuẩn chạy được. Danh mục sạch, nguyên tắc hạch toán rõ, và ít nhất một chứng từ đi hết một vòng từ lúc phát sinh đến lúc lên báo cáo. Chưa có tầng này thì mọi thứ bên trên đều dựng trên cát. Đích đến ở đây không phải "đẹp", mà là "chạy được và đúng".
2. Chuẩn hoá cách làm. Một điểm nhập dữ liệu cho mỗi loại thông tin, bỏ các file Excel chạy ngoài luồng, thống nhất cách gọi tên và cách phân loại. Tầng này ít ai thích vì nó đụng đến thói quen, nhưng nó là thứ quyết định tầng ba tốn bao nhiêu.
3. Kaizen theo bộ phận. Giờ mới tuỳ biến — nhưng theo đúng chuẩn của trang này: đo trước, sửa sau, từng đợt, mỗi đợt kèm một phép đo. Ba bài trước trên trang này đều là ví dụ của tầng ba, và không bài nào trong số đó làm được nếu tầng một chưa chạy.

Điều đáng nói nhất về thứ tự này không nằm ở kỹ thuật: một phần đáng kể các yêu cầu "phải có" sẽ tự biến mất sau vài tháng chạy nền chuẩn. Không phải vì ai đó thuyết phục được ai, mà vì khi công việc thật chạy qua hệ thống thật, người dùng tự thấy thứ mình đòi lúc đầu không còn cần thiết. Tuỳ biến trước là trả tiền cho cả những thứ đó.

3. Quy ra tiền

Chênh lệch giữa hai lộ trình nằm ở bốn khoản, và chỉ lộ trình tuỳ-biến-trước phải trả:

Khoản thứ tư thường bị bỏ quên vì nó không xuất hiện trên bất kỳ hoá đơn nào. Nhưng năm tháng chưa go-live là năm tháng doanh nghiệp không được hưởng gì cả, trong khi vẫn trả lương cho đội dự án.

Và đây là chỗ cần thành thật: toàn bộ lập luận nằm trong ba con số — tỉ lệ làm lại, tỉ lệ tự biến mất, và số tháng trễ. Đặt cả ba về 0 thì hai lộ trình tốn đúng bằng nhau. Bảng tính ở trên cho bạn làm điều đó. Nếu ở doanh nghiệp của bạn cả ba thật sự bằng 0 thì thứ tự không còn là câu hỏi tiền bạc, và bài này không áp dụng.

4. Câu trả lời thật: làm cả hai cùng lúc

Đặt vấn đề thành "chuẩn trước hay tuỳ biến trước" là một câu hỏi sai, và nó sai theo cách tốn tiền. Trong thực tế, lộ trình rẻ nhất là dựng nền chuẩn và đồng thời tuỳ biến sâu cho một vài khâu quyết định vận hành — chỉ vài khâu, và phải là khâu quyết định thật.

Lý do không nằm ở kỹ thuật mà ở hành vi: một hệ thống thiếu đúng khâu mà người ta sống bằng nó thì người ta sẽ không dùng. Họ không phản đối ra mặt; họ chỉ lặng lẽ mở lại file Excel cũ. Và khi đó doanh nghiệp trả đủ tiền cho một hệ thống mà vẫn vận hành bằng công cụ cũ — khoản lỗ này không xuất hiện trên hoá đơn nào, nhưng nó có thật và đo được.

Thế nào là một "khâu quyết định vận hành"

Ba dấu hiệu, phải có cả ba:

1. Nó nằm trên đường đi của tiền hoặc của hàng mỗi ngày, không phải một báo cáo cuối tháng.
2. Thiếu nó thì người dùng có đường vòng — và đường vòng đó rẻ hơn việc dùng hệ thống.
3. Nó không sửa được bằng cấu hình, tức đã thử đặt lại tham số mà vẫn không ra.

Nếu một yêu cầu không đủ cả ba, nó thuộc tầng ba và hãy để nó chờ. Phần lớn yêu cầu "phải có" không đủ ba dấu hiệu này — đó chính là lý do một phần đáng kể tự biến mất sau vài tháng.

Kinh nghiệm thực tế là con số này nhỏ: vài khâu, không phải vài chục. Nếu danh sách "quyết định vận hành" của bạn dài hai mươi mục thì gần như chắc chắn nó chưa được sàng, và bạn đang trên đường quay lại lộ trình tuỳ-biến-hết-trước dưới một cái tên khác.

Ba lộ trình, đo cạnh nhau

Bảng tính ở trên so ba lộ trình trên cùng một khung nhìn. Với giả định mặc định, lộ trình kết hợp rẻ nhất — nhưng điều đáng chú ý là nó rẻ hơn lộ trình chuẩn-thuần không nhiều, còn rẻ hơn lộ trình tuỳ-biến-hết-trước thì rất nhiều. Nói cách khác: chọn sai giữa "chuẩn thuần" và "kết hợp" là một sai lầm nhỏ; chọn tuỳ-biến-hết-trước mới là sai lầm đắt.

Và phần trung thực: nếu bỏ qua các khâu quyết định mà không mất gì — tức đặt phần lợi ích mất đi về 0 — thì chuẩn thuần rẻ hơn kết hợp, đúng như lẽ phải. Toàn bộ lý do làm sớm vài khâu nằm ở chỗ thiếu chúng thì người dùng né hệ thống. Nếu ở doanh nghiệp bạn điều đó không đúng, đừng làm sớm.

5. Khi nào thứ tự này sai

Nguyên tắc nào cũng có vùng không áp dụng, và nói ra vùng đó là cách duy nhất để nguyên tắc đáng tin:

• Khi nền chuẩn không chạy nổi nghiệp vụ cốt lõi. Có ngành mà thiếu một luồng đặc thù thì hệ thống không ghi nổi một chứng từ hợp lệ. Lúc đó "tầng một" của bạn buộc phải bao gồm luồng ấy — nó là nền, không phải tuỳ biến.
• Khi ràng buộc pháp lý không cho chạy tạm. Hoá đơn, thuế, ngành có quy định riêng: không có chuyện go-live với một phiên bản "gần đúng".
• Khi tuỳ biến rẻ hơn chi phí thuyết phục. Một thay đổi nhỏ, rõ ràng, không đụng sổ sách, mà gỡ được lực cản của cả một phòng ban — làm luôn. Ba bài trước trên trang này đều thuộc loại đó.

Thứ tự không phải chuyện kỷ luật hay chuyện đúng sai về kiến trúc. Nó là chuyện tiền: làm sai thứ tự thì bạn trả cho những tuỳ biến mà chính người yêu cầu sẽ thôi cần, và trả bằng những tháng chưa được hưởng gì.

Các con số trong bài là số minh hoạ, không lấy từ hệ thống hay dự án của khách hàng nào. Hãy thay bằng số của chính bạn trong bảng tính ở trên.