Xưởng nào lắp ERP rồi cũng có lúc muốn "sửa một chút thôi." Thêm một trường trên màn hình nhập kho. Đổi cách tính chiết khấu. Cho hệ thống nói đúng ngôn ngữ mà xưởng sản xuất đang dùng hàng ngày. Yêu cầu nghe có vẻ nhỏ. Nhưng nó có thực sự nhỏ hay không phụ thuộc hoàn toàn vào việc bạn đang đụng vào phần nào của ERP — và gần như không ai đưa ra yêu cầu đó biết rằng các phần khác nhau mang mức rủi ro hoàn toàn khác nhau.
Phần mềm tiêu chuẩn generic là có chủ đích
Trong khoa học thông tin doanh nghiệp, phần mềm tiêu chuẩn (standard software) được định nghĩa là phần mềm có thể dùng ở nhiều công ty khác nhau mà không cần thay đổi đáng kể. Đó chính là lý do người ta mua ERP tiêu chuẩn thay vì tự viết: nhà cung cấp chia chi phí phát triển cho hàng trăm khách hàng, xưởng sản xuất có hệ thống hoạt động sau vài tuần thay vì vài năm. Nhưng để dùng được cho hàng trăm công ty khác nhau, phần mềm buộc phải chung chung. Nó không thể biết sẵn xưởng sản xuất của bạn tính phụ phí đơn gấp thế nào, hay đánh số lệnh sản xuất ra sao.
Năm lớp, năm mức rủi ro khác nhau
Mô hình Core-Shell (Core-Shell model) mô tả cấu trúc từ chung chung đến riêng biệt này như các lớp vỏ bọc quanh nhau:
- Lõi kỹ thuật (technical core) — công cụ cơ sở dữ liệu và nền tảng, giống nhau ở mọi khách hàng.
- Lõi nghiệp vụ (business core) — logic kế toán, nghiệp vụ chung áp dụng cho gần như mọi công ty.
- Lớp theo kiểu hình doanh nghiệp (operation-type layer) — phân biệt những thứ cơ bản như sản xuất rời rạc với sản xuất theo dòng chảy liên tục.
- Lớp ngành (industry) — logic ngành ô tô khác hẳn logic ngành nội thất.
- Lớp riêng của từng công ty (company-specific) — những quy tắc chỉ đúng cho riêng xưởng sản xuất của bạn.
Quy luật quan trọng: càng ra xa lõi, công ty càng cần nhiều customization — và customization đó càng dễ vỡ, càng tốn kém để duy trì qua mỗi lần ERP nâng cấp phiên bản.
Không phải kiểu thay đổi nào cũng rủi ro như nhau
Nhà cung cấp gọi quá trình thích ứng phần mềm tiêu chuẩn cho một công ty là "Adaptation," và nó có ba dạng:
- Customizing — cấu hình hệ thống trong phạm vi tham số mà nhà cung cấp đã xây sẵn và hỗ trợ, bật/tắt tùy chọn, điền bảng thiết lập.
- Modification — sửa trực tiếp mã nguồn của lõi hệ thống.
- Extension — gắn thêm phần mở rộng riêng bên cạnh hệ thống lõi.
Customizing thực hiện thuần túy qua cấu hình, không đụng đến mã nguồn, gọi là Parametrization (tham số hóa) — đây là vùng an toàn, vì nó giữ hệ thống release-compatible: tương thích đầy đủ với bản phát hành tiếp theo của nhà cung cấp. Modification lõi là vùng rủi ro. Nó có thể giải quyết vấn đề hôm nay, nhưng lần nâng cấp ERP kế tiếp có thể âm thầm phá vỡ nó, và không ai nhận ra cho đến khi sản xuất bị đình trệ.
Lớp ngoài cùng thường được xây ở đâu
Đây chính là lý do lớp ngoài cùng, riêng của từng công ty, thường được xây như một phần mở rộng tách biệt nằm trên ERP tiêu chuẩn, thay vì sửa vào mã nguồn của chính ERP. Các công ty tư vấn ERP độc lập, chẳng hạn, xây lớp riêng của khách hàng trên nền ERP tiêu chuẩn của họ — như Infor hay ABAS — chính vì các lớp bên dưới không thể và không nên bị đụng vào.
Trước khi bạn duyệt yêu cầu "sửa một chút" tiếp theo trong ERP, hãy hỏi một câu trước: thay đổi này thực sự đụng vào lớp nào? Nếu câu trả lời là một tùy chọn cấu hình mà nhà cung cấp đã hỗ trợ sẵn, cứ đồng ý, không cần lo. Nếu câu trả lời là sửa logic của lõi, hãy coi đó là một quyết định riêng, có ngân sách riêng — vì bạn không trả tiền cho thay đổi đó một lần, mà phải làm lại nó ở mỗi lần nâng cấp sau này.
Nguyễn Hải Minh
Tôi làm việc trong ngành CNTT tại Đức — trực tiếp viết phần mềm và xử lý dữ liệu hệ thống ERP (như INFOR) cho các nhà máy sản xuất của Đức. Về học vấn, tôi có bằng Cử nhân Kỹ thuật CNTT và bằng Kỹ thuật viên Điện tử Thông tin cấp nhà nước tại Đức. Tất cả những nền tảng đó giúp tôi rèn luyện một tư duy hệ thống vững vàng để làm tự động hóa và tối ưu vận hành chuẩn chỉ.
Tìm hiểu thêm về tác giả →