Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
ERP không phải phần mềm làm được nhiều việc, mà là một cơ sở dữ liệu duy nhất mà mọi bộ phận cùng ghi vào. Bài này nói cả cái được lẫn cái giá phải trả.
Trong một buổi khảo sát ở doanh nghiệp phân phối vật tư xây dựng hơn trăm người, chủ doanh nghiệp hỏi đúng câu tưởng như dễ nhất trong cả buổi, rằng sáng nay kho còn bao nhiêu tấn của một mã hàng đang bán chạy.
Ba người có mặt đưa ra ba con số khác nhau. Bạn phụ trách kho mở file nhập xuất gõ tay hằng ngày ra một con số; bạn kế toán mở phần mềm kế toán ra một con số thấp hơn; còn bạn bán hàng nhìn vào file đơn đang chờ giao rồi đưa ra con số thứ ba, thấp hơn cả hai con số kia. Vấn đề là không ai trong ba người nói sai. Đó mới là chỗ đáng nói.
Chuyện hỏng ngay sau đó rất cụ thể: doanh nghiệp không dám hứa ngày giao hàng cho một khách lớn đang chờ, và nửa buổi họp biến thành cuộc đối chiếu số liệu giữa ba cái file.
Điều đầu tiên bạn cần nhìn ra là ba con số kia không lệch nhau vì ai đó cẩu thả, mà lệch vì ba nơi ghi nhận cùng một sự việc vào ba thời điểm khác nhau, bằng ba định nghĩa khác nhau về chữ "còn hàng".
Bạn phụ trách kho ghi khi hàng đã dỡ xuống và kiểm đếm xong, nên con số của bạn ấy là hàng đang nằm trong kho. Bạn kế toán ghi khi chứng từ về tới bàn, mà chứng từ thì có khi về trễ vài ngày, nên con số của bạn ấy là hàng đã đủ giấy tờ. Còn bạn bán hàng trừ ngay khi khách chốt đơn, kể cả khi hàng vẫn nguyên trong kho, nên con số của bạn ấy là hàng còn bán được. Ba định nghĩa đều hợp lý trong phạm vi công việc của từng người, và chúng chỉ thành vấn đề khi có ai đó cần một con số duy nhất để ra quyết định.
Cần lưu ý rằng vấn đề này lớn lên theo số lần bàn giao thông tin giữa các bộ phận chứ không theo tuổi doanh nghiệp, vậy nên có những nơi chạy ba file rời rạc suốt nhiều năm vẫn ổn vì mọi thứ đi qua một người và người đó nhớ hết; khi nào một doanh nghiệp chưa cần ERP là một chủ đề riêng. Ở đây bạn chỉ cần nhớ rằng chi phí thật của phần mềm rời rạc nằm ở chỗ đối chiếu, không nằm ở chỗ nhập liệu.
Phần lớn bài giới thiệu ERP sẽ nói đây là hệ thống quản trị tổng thể, giúp doanh nghiệp quản lý bán hàng, mua hàng, kho và kế toán trên cùng một phần mềm. Câu đó không sai, nhưng nó chỉ mô tả bề mặt.
Bản chất mà bạn va vào ngay ngày đầu đi triển khai là thế này: ERP không phải một phần mềm làm được nhiều việc, mà là một cơ sở dữ liệu duy nhất, nơi mà mọi bộ phận cùng ghi vào. Làm được nhiều việc chỉ là hệ quả, không phải nguyên nhân. Ghép năm phần mềm rời rạc bằng vài đường tích hợp thì bạn vẫn có hệ thống làm được nhiều việc, nhưng mỗi phần mềm vẫn giữ dữ liệu riêng và ba con số ở đầu bài vẫn lệch nhau, chỉ chậm hơn vài giờ.
Chi tiết dễ thấy nhất nằm ở danh mục đối tác: trên Odoo 19, đơn bán hàng gọi đối tác của nó là Khách hàng, đơn mua hàng gọi là Nhà cung cấp, phiếu giao nhận trong kho gọi là Liên hệ, và hóa đơn thì gọi là Đối tác; bốn màn hình, bốn cái tên hiển thị, nhưng cả bốn đều là cùng một trường trỏ về đúng một danh mục liên hệ duy nhất trong cơ sở dữ liệu. Do đó khi khách đổi địa chỉ, bạn sửa một chỗ và cả bốn nơi cùng thấy; khi có người tạo trùng một khách thành hai bản ghi thì cả bốn nơi cùng chịu hậu quả.
Nguyên tắc tương tự chi phối phần hàng hóa, và cách tôi vẫn dùng để giải thích cho người mới là sản phẩm không tự sinh ra và không tự mất đi, mọi biến động chỉ là chuyển hàng từ vị trí này sang vị trí kia. Hệ quả rất thực dụng: một con số tồn kho sai luôn truy ngược ra được một chứng từ do một người cụ thể tạo. Phần đầy đủ thuộc cụm bài về kho.
Cấu trúc đó lộ ra ngay trên thanh menu của một phân hệ Odoo, chia thành master data, dữ liệu phát sinh, báo cáo và cấu hình; cách đọc khung này đã có bài riêng, còn thứ tự nạp hai loại dữ liệu kia lại là một bài khác nữa.
Đây là phần brochure không nói, và cũng là phần khiến nhiều dự án đau.
Cái giá thứ nhất là cái sai của một người trở thành cái sai của cả nhà, và đổi lại bạn có khả năng truy ngược tới đúng người và đúng thời điểm gây ra sai lệch; còn phạm vi lan của một thay đổi rộng tới đâu thì là chuyện của bài phân biệt ERP với CRM và phần mềm kế toán.
Cái giá thứ hai là các bộ phận buộc phải thống nhất định nghĩa trước khi hệ thống được cấu hình. Chữ "hàng khả dụng" ở đầu bài là một ví dụ, và việc chốt xem hàng đã đặt nhưng chưa xuất kho có được tính là khả dụng hay không thường mất nhiều thời gian hơn hẳn việc cấu hình con số đó. Cần lưu ý rằng đây là thương lượng giữa các phòng ban chứ không phải quyết định kỹ thuật, nên người đi triển khai chỉ có thể đưa ra phương án và đề nghị một người đủ thẩm quyền chốt.
Cái giá thứ ba là nhịp làm việc của các bộ phận bị buộc vào nhau, và một bộ phận quen làm dồn vào cuối tuần sẽ chặn tất cả những người đứng sau nó. Trước đây sự lệch nhịp được giấu trong các file rời rạc, còn sau khi lên ERP thì nó hiện ra thành số liệu, và đó là lý do nhiều doanh nghiệp thấy hệ thống mới làm họ chậm đi trong vài tuần đầu. Thứ thật sự xảy ra là hệ thống đang phơi ra một thói quen vốn có từ lâu.
Cái giá thứ tư là phân quyền trở thành công việc thật chứ không còn là một mục nhỏ trong tài liệu, bởi khi mọi người cùng ghi vào một chỗ thì bạn phải trả lời ai được tạo, ai được sửa, ai chỉ được xem, ai được nhìn thấy giá vốn. Trả lời hời hợt thì hoặc người dùng không làm được việc, hoặc dữ liệu nhạy cảm lộ cho người không nên thấy.
Ngoài ra có một giới hạn cần nói thẳng. ERP không sửa được quy trình mà không ai tuân thủ, bởi hệ thống chỉ ghi lại cái người ta làm chứ không làm thay; doanh nghiệp vốn quen chốt đơn qua tin nhắn thì sau khi lên ERP vẫn chốt đơn qua tin nhắn, và nay phải nhập liệu thêm một lần. Tôi cũng không đưa vào bài con số nào về tỷ lệ dự án ERP thất bại, vì các con số phổ biến đều dẫn ngược về vài báo cáo tư vấn định nghĩa chữ "thất bại" mỗi nơi một khác, và tôi chưa tra được bản gốc.
Phía brochure đếm phân hệ, còn phía triển khai đếm dữ liệu dùng chung.
Một bộ giới thiệu điển hình sẽ liệt kê vài chục phân hệ cùng một danh sách tính năng dài, trong khi câu hỏi có giá trị nhất lại là dữ liệu nào được dùng chung và ai được quyền ghi vào từng loại. Số lượng phân hệ gần như không nói lên điều gì, bởi ba phân hệ dùng chung một danh mục khách hàng vẫn giải quyết được bài toán ở đầu bài, còn ba mươi phân hệ mà mỗi phân hệ giữ danh mục riêng thì không.
Khác biệt tiếp theo là brochure mô tả triển khai như một việc cài đặt, trong khi phần lâu nhất của dự án thường là phần thống nhất danh mục và định nghĩa. Trong các dự án triển khai, thời gian dọn danh mục sản phẩm và danh mục khách hàng, gộp bản ghi trùng, thống nhất cách đặt mã, thường vượt xa thời gian cấu hình tính năng; và phần dọn dữ liệu đó thì khách phải tự làm chứ bạn không làm thay được.
Khác biệt cuối cùng nằm ở cách nói về giới hạn. Gần như toàn bộ nội dung tiếng Việt về ERP đều do đơn vị bán hoặc đơn vị triển khai viết, nên chúng dừng ở định nghĩa và ở danh sách lợi ích; người đi triển khai thì buộc phải biết cả những chỗ hệ thống làm không tốt, vì trả lời sai một câu về khả năng đáp ứng thì cái sai ấy quay lại vào lúc bàn giao.
Nếu ai đó giới thiệu một hệ thống và gọi nó là ERP, bạn có thể tự kiểm tra được ngay trên bản demo bằng bốn thao tác dưới đây:
Trong trường hợp hệ thống trả lời trôi chảy cả bốn thao tác, bạn đang nhìn một hệ thống dùng chung dữ liệu thật; ngược lại, nếu tới thao tác thứ hai mà dữ liệu chỉ khớp sau vài phút hoặc phải bấm một nút đồng bộ, thì đó có khả năng là nhiều phần mềm được nối với nhau. Bạn cần biết điều đó trước khi ký hợp đồng triển khai ERP chứ không phải sau. Ranh giới giữa ERP với phần mềm quản lý khách hàng hay phần mềm kế toán là một chủ đề riêng.
Việc còn lại là đi theo một chứng từ, từ lúc nó sinh ra cho tới lúc nó khép lại, để thấy dữ liệu chảy qua từng phân hệ theo trình tự nào và mỗi bước chạm vào bộ phận nào.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận