Bỏ qua để đến Nội dung

Individual vs Standard Software — bẫy AT-software khiến hệ thống khó bảo trì mãi mãi

Phần lớn xưởng sản xuất không cố tình xây phần mềm riêng. Họ chỉ muốn giải quyết một vấn đề cụ thể — nối hệ thống kho với file xuất kế toán, hoặc nối ERP với cổng khai báo hải quan — và một đoạn script nhỏ dần dần phình to thành thứ mà hai năm sau không ai dám đụng vào. Ai cũng ngại sửa, người viết ra nó đã nghỉ việc, và mỗi lần "sửa nhanh" lại mất vài ngày thay vì vài giờ. Đó không phải xui rủi. Đó là một nhóm phần mềm có thể dự đoán trước được, và ngành khoa học thông tin kinh doanh (Business Informatics) có tên gọi chính xác cho lý do vì sao nó xảy ra.

Hai trục, bốn nhóm phần mềm

Bất kỳ phần mềm nào cũng có thể đặt vào hai trục: nó gắn chặt đến mức nào với một nghiệp vụ kinh doanh cụ thể, và nó kết nối sâu đến mức nào với tầng kỹ thuật bên dưới — phần cứng, giao thức mạng, định dạng file, hạ tầng cấp thấp. Từ đó có bốn nhóm.

  • Trung tính (0) — thấp ở cả hai trục, ví dụ một hệ điều hành, không quan tâm nghiệp vụ nào chạy trên nó.
  • Anwendungssoftware (A) — cao ở trục nghiệp vụ nhưng thấp ở trục kỹ thuật: logic ứng dụng thuần túy, như một quy tắc tính giá.
  • Phần mềm kỹ thuật (T) — cao ở trục kỹ thuật nhưng thấp ở trục nghiệp vụ: driver thiết bị, tầng mạng.
  • AT-software — cao ở cả hai trục cùng lúc: vừa chứa logic nghiệp vụ, vừa gắn chặt vào hệ thống kỹ thuật bên dưới.

Vì sao AT-software là nhóm không ai dám đụng vào

AT-software được xác định rõ ràng là nhóm khó bảo trì nhất, và lý do nằm ở cấu trúc, chứ không phải do code viết ẩu:

  • Một thay đổi ở phía nghiệp vụ — quy tắc giá mới, một trường khai báo hải quan mới — có nguy cơ thực sự làm gãy phần kết nối kỹ thuật bên dưới.
  • Một thay đổi ở phía kỹ thuật — định dạng file mới từ hệ thống đối tác, một bản cập nhật giao thức — cũng dễ dàng làm gãy logic nghiệp vụ nằm phía trên.

Để bảo trì an toàn, cần người hiểu cả hai lĩnh vực cùng lúc — không phải một chuyên viên nghiệp vụ và một kỹ sư hệ thống làm việc nối tiếp nhau, mà là một người (hoặc một cặp phối hợp rất chặt) giữ cả hai bức tranh trong đầu cùng lúc. Đó là sự kết hợp hiếm và đắt đỏ, và chính vì vậy các hệ thống này thường mục ruỗng dần: người duy nhất hiểu cả hai phía nghỉ việc, và sau đó không ai dám động vào nữa.

Individualsoftware (gần như) luôn là AT-software

Individualsoftware — phần mềm cá nhân hóa, viết riêng cho một hoặc vài trường hợp sử dụng cụ thể — về bản chất thường chính là AT-software. Nó được viết đúng theo quy trình nghiệp vụ của bạn và gắn trực tiếp vào đúng môi trường kỹ thuật của bạn, không có lớp trừu tượng nào bảo vệ bên này khỏi thay đổi ở bên kia. Ngược lại, Standardsoftware — phần mềm tiêu chuẩn — được xây để dùng được ở nhiều công ty khác nhau mà không cần thay đổi đáng kể, và điều đó thay đổi hoàn toàn bài toán kinh tế:

  • Chi phí phát triển được chia sẻ cho nhiều khách hàng.
  • Triển khai nhanh hơn.
  • Chất lượng nền thường cao hơn, vì nhiều người đã chạy qua cùng đoạn code đó.
  • Các best practice được đóng gói sẵn vào sản phẩm.
  • Cần ít nhân sự chuyên biệt hơn để vận hành.
  • Nhà cung cấp có thêm dịch vụ đi kèm.
  • Dễ tích hợp hơn với các sản phẩm tiêu chuẩn khác.

Phần mềm tiêu chuẩn cũng có những nhược điểm thật sự:

  • Phải gánh chi phí phần cứng/tài nguyên cho phần tổng quát mà mình không dùng đến.
  • Có nguy cơ phụ thuộc nhà cung cấp (vendor lock-in) kéo dài 10 năm hoặc hơn.
  • Chi phí tùy biến (customization) để khớp với quy trình riêng có thể chiếm tới khoảng 40% chi phí triển khai.
  • Giao diện kết nối với các hệ thống khác vẫn có thể gây vấn đề tích hợp thật sự.
  • Việc dùng chung một hệ thống với đối thủ cạnh tranh có thể là bất lợi cạnh tranh thực sự.
  • Nhân sự thường phản kháng một công cụ "một size cho tất cả" không khớp với cách họ thực sự làm việc.

Hệ quả thực tế cho một xưởng sản xuất là thế này: các bộ kết nối (connector/adapter) mà xưởng sản xuất tự xây giữa ERP và mọi thứ xung quanh nó — kho, bán hàng, hải quan, file xuất từ hệ thống đối tác — theo định nghĩa này, gần như luôn là AT-software. Chúng xứng đáng có kiến trúc được thiết kế có chủ đích, có tài liệu, và có một người chịu trách nhiệm rõ ràng hiểu cả quy tắc nghiệp vụ lẫn phần kết nối kỹ thuật — chứ không phải một đoạn script do một người viết vội dưới áp lực deadline mà giờ ai cũng ngại mở ra.

Nguyễn Hải Minh

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ả →
Core-Shell model: vì sao "customize ERP" luôn khó hơn nghĩ
ContactLiên hệ
Send a messageGửi tin nhắn