Khi nào doanh nghiệp chưa cần ERP, và khi nào thì cần thật

Hai loại vấn đề hay bị gọi chung một tên

Loại thứ nhất nằm bên trong một bộ phận. Kế toán đóng sổ chậm; đội bán hàng không nhớ đã hứa gì với khách nào; kho đếm bằng sổ tay nên hôm nào cũng lệch vài dòng. Đặc điểm chung là mọi thông tin cần để giải quyết đều nằm trong tay chính bộ phận đó.

Loại thứ hai nằm ở chỗ nối giữa các bộ phận: một thông tin do bộ phận này tạo ra nhưng bộ phận khác mới là người dùng, và trên đường đi từ nơi tạo tới nơi dùng thì nó bị chép tay, bị nhập lại, bị hiểu khác đi hoặc chậm mất vài ngày. ERP sinh ra cho đúng loại thứ hai, vì cơ chế của nó là các bộ phận cùng ghi vào và cùng đọc ra từ một chỗ.

Từ đó có một quy tắc lọc dùng được ngay:

Nếu giải quyết xong vấn đề mà không bộ phận nào khác cần biết, thì đó chưa phải là bài toán của ERP.

Những dấu hiệu doanh nghiệp chưa cần ERP

Dấu hiệu đầu tiên là cơn đau chỉ có một địa chỉ, tức bạn hỏi từng trưởng bộ phận việc gì làm họ mất thời gian nhất và các câu trả lời không dính dáng gì tới nhau. Khi đó, phần mềm chuyên cho đúng bộ phận đang đau sẽ rẻ hơn, xong nhanh hơn, và bỏ đi được nếu chọn sai, còn hệ thống dùng chung thì rất khó bỏ.

Dấu hiệu thứ hai là quy trình chưa ổn định, tức doanh nghiệp đang thử một mô hình kinh doanh mới và mỗi quý một cách làm. Cần lưu ý rằng triển khai ERP về bản chất là ghi lại cách làm hiện tại vào hệ thống dưới dạng cấu hình và quy tắc, nên cách làm còn đổi thì phần vừa dựng xong sẽ phải đập đi làm lại.

Dấu hiệu thứ ba là master data chưa có hình hài: danh mục sản phẩm nằm ở ba file, mỗi file một cách đặt mã, còn danh sách khách hàng thì mỗi nhân viên bán hàng giữ một bản riêng. Hãy nhớ rằng hệ thống chỉ chạy được khi đã có master data, nên việc đầu tiên là gom, và doanh nghiệp tự làm được mà chưa cần mua gì.

Dấu hiệu thứ tư là không có ai bên trong đủ thẩm quyền chốt quy trình. Yêu cầu do một nhân viên nêu ra chưa phải yêu cầu của doanh nghiệp, nó chỉ trở thành yêu cầu khi có người đủ thẩm quyền xác nhận; nếu dự án được giao trọn cho một bạn phụ trách hệ thống thông tin thì mỗi quyết định sẽ bị đẩy qua đẩy lại.

Dấu hiệu thứ năm là thời điểm: nếu sáu tháng tới có một mùa cao điểm không được phép trượt thì đó là lúc chuẩn bị chứ chưa phải lúc bắt đầu, bởi giai đoạn chuyển hệ thống luôn làm chậm vận hành.

Những dấu hiệu doanh nghiệp cần thật

Dấu hiệu rõ nhất là một sự kiện kinh doanh phải được ghi lại nhiều lần bởi nhiều người: một lần nhận hàng từ nhà cung cấp được ghi ở biên bản nhận của kho, ghi lại ở bảng theo dõi của mua hàng, rồi nhập lần thứ ba khi kế toán vào hóa đơn đầu vào, và không có gì bảo đảm ba bản ghi đó khớp nhau ngoài sự cẩn thận của ba con người ở ba thời điểm khác nhau.

Dấu hiệu thứ hai là cùng một câu hỏi cho ra hai câu trả lời. Bạn hỏi công nợ của một khách hàng, kế toán trả lời một con số, đội bán hàng trả lời một con số khác, và cả hai đều có căn cứ của mình. Vấn đề khi đó là hai bộ phận giữ hai bản sự thật, không bản nào đủ thẩm quyền bác bỏ bản kia. Cảnh này ở dạng đầy đủ nằm trong bài ERP là gì.

Dấu hiệu thứ ba là đã có người làm việc đối soát toàn thời gian. Khi các bộ phận lệch nhau, phản xạ tự nhiên là cắt một người ra ngồi ghép số liệu giữa các nơi; nhưng khi việc đó chiếm trọn thời gian của một người thì doanh nghiệp đang trả lương cho chi phí phối hợp, và chi phí ấy tăng theo khối lượng giao dịch chứ không đứng yên.

Dấu hiệu thứ tư là các phần mềm chuyên biệt đã đủ nhưng chỗ nối giữa chúng thì không: mỗi phần mềm làm tốt phần việc của nó, còn công sức thì đổ vào việc chuyển dữ liệu qua lại.

Ngưỡng ra quyết định

Câu hỏi hay gặp là doanh nghiệp bao nhiêu người thì nên làm ERP, và đây là câu hỏi đặt sai chỗ, vì hai doanh nghiệp cùng quy mô nhân sự có thể có khối lượng giao dịch và số chỗ nối giữa các bộ phận khác nhau rất xa. Nếu ai đó đưa cho bạn một con số nhân sự làm ngưỡng, hãy hỏi họ con số đó lấy từ đâu.

Thay vào đó, câu hỏi thứ nhất nên hỏi là một sự kiện kinh doanh của bạn đang được ghi lại ở mấy nơi và bởi mấy người:

Đây là ngưỡng do bài này đề xuất chứ không phải chuẩn ngành, nhưng ưu điểm của nó là đếm được.

Câu hỏi thứ hai là khi số liệu lệch nhau thì ai chịu thiệt: chỉ một bộ phận chịu thì đó vẫn là bài toán của bộ phận đó, còn nếu người chịu thiệt là khách hàng, dòng tiền, hoặc quyết định của ban lãnh đạo, thì bài toán đã vượt khỏi phạm vi của một phòng ban.

Ràng buộc từ hệ thống cũ

Khi đã quyết định làm, có một nguyên tắc mà một quản lý dự án lâu năm ở công ty triển khai luôn nhắc trước mọi buổi demo:

Hệ thống mới ít nhất phải bằng hệ thống cũ ở những việc người dùng đang làm được.

Nghe thì hiển nhiên, nhưng nó bị vi phạm liên tục vì không ai chịu liệt kê cái cũ ra: doanh nghiệp mô tả những gì mình còn thiếu, đội triển khai thiết kế theo đúng những gì được mô tả, và không bên nào nhớ tới một chị kế toán vẫn in một báo cáo cố định mỗi sáng trên phần mềm cũ, thứ không có trong tài liệu nào nhưng là cách chị bắt đầu ngày làm việc.

Hậu quả hiện ra rất muộn, lúc người dùng thật ngồi xuống thao tác, dưới dạng một câu hỏi mà ai đi triển khai cũng từng nghe: phần mềm cũ có cái này, sao bên em không có. Khi câu đó xuất hiện thì hai bên không còn bàn tính năng mà đang bàn niềm tin.

Cách phòng là liệt kê trước rồi đưa danh sách đó cho bên triển khai và yêu cầu trả lời từng dòng. Cần chú ý rằng "không làm được theo cách cũ" là câu trả lời chấp nhận được, miễn nó được nói ra ngay lúc đó; thứ không chấp nhận được là nó bị phát hiện vào giai đoạn nghiệm thu.

Việc phải chuẩn bị trước khi bắt đầu

Một số việc doanh nghiệp phải tự làm trước, vì không ai làm thay được:

• Liệt kê những việc cách làm hiện tại đang làm được, kể cả việc làm bằng Excel
• Gom danh mục sản phẩm, khách hàng và nhà cung cấp về một bản duy nhất, thống nhất cách đặt mã
• Chỉ định một người bên trong có thẩm quyền chốt quy trình và theo dự án xuyên suốt
• Chốt danh sách báo cáo mà ban lãnh đạo thật sự đọc hằng tuần
• Xác định các mốc kinh doanh không được đụng vào trước khi chốt lịch dự án

Bốn dòng đầu làm được mà chưa cần chi đồng nào cho phần mềm. Riêng việc gom master data hãy làm sớm, bởi dữ liệu trong hệ thống dùng chung có tính liên kết và sửa một mã sai sau khi đã phát sinh giao dịch khó hơn nhiều so với sửa trong Excel.

Vài trường hợp đi ngược các dấu hiệu trên

Trường hợp thứ nhất là doanh nghiệp bị ràng buộc từ bên ngoài, chẳng hạn công ty mẹ yêu cầu số liệu theo một chuẩn thống nhất, và ngưỡng do bên ngoài đặt.

Một số trường hợp khác thì bộ phận đang đau lại chính là nơi phát sinh dữ liệu cho mọi bộ phận khác, mà kho hay rơi vào tình huống này; vì số liệu kho là đầu vào của bán hàng, mua hàng và kế toán, nên đó là vấn đề phối hợp đang đội lốt vấn đề nội bộ.

Giới hạn của cách nghĩ này

Cần nói thẳng rằng những dấu hiệu và ngưỡng trong bài là quan sát mà mình rút ra từ nghề, không phải một mô hình đã được đo đạc; chúng giúp bạn đặt câu hỏi đúng, nhưng không thay được việc nhìn vào quy trình thật của doanh nghiệp bạn.

Ngoài ra có một kỳ vọng nên được gỡ ngay từ đầu:

Hệ thống không sửa được một quy trình sai, nó chỉ làm quy trình hiện tại chạy nhanh hơn và làm chỗ sai lộ ra sớm hơn.

Nếu doanh nghiệp đang kỳ vọng mua hệ thống về thì cách làm việc tự khắc đúng lên, kỳ vọng đó nên được chỉnh trước khi ký, vì đó là mẫu hình dẫn tới thất bại. Về chi phí, bài này cố tình không đưa con số nào, bởi đó là chủ đề đủ lớn để nói riêng.

Nếu tới đây bạn kết luận rằng vấn đề của mình vẫn nằm gọn trong một bộ phận thì câu hỏi kế tiếp là nên mua phần mềm chuyên nào, và muốn trả lời được thì trước hết phải phân biệt ERP với CRM và với phần mềm kế toán, ba thứ hay bị đặt cạnh nhau nhưng trả lời ba câu hỏi khác nhau.