Thời gian để chúng tôi triển khai toàn bộ luồng NPL của Sewman, gồm 3 phân hệ cho Hanosimex chỉ là 1 tuần làm tại chỗ, và sau đó là hỗ trợ từ xa là chính. Để làm được điều này, TTSOFT phải nhờ tới Minh Trí. Minh Trí đã giành thời gian, thiết bị và con người, để hướng dẫn tận tình những cán bộ từ phía Hanosimex, giúp chúng tôi có thời gian tập trung vào làm những gì cần thiết hơn để hoàn thiện sản phẩm.

Đầu năm 2009, từ quê ngoại ở Nam Định lên, tôi ghé thăm công ty TNHH Minh Trí tại khu công nghiệp Vĩnh Tuy – Hà Nội, khi đó đang sử dụng hai phân hệ của Sewman là SMS và SMW.

Minh Trí mỗi năm phải quản lý hàng nghìn PO, cả đơn hàng FOB và CM, cả sản xuất tại chỗ, vừa mang đi gia công bên ngoài. Riêng trong nội bộ, có tới 3 nhà máy, 2 ở Hà Nội và 1 ở Thái Bình. Cũng do hệ thống quản lý được khá hiệu quả phần tính toán yêu cầu NPL và yêu cầu cấp phát, nên các chị đã “chịu đựng” được nhiều lỗi trong phân hệ quản lý kho lúc đó.

Nhưng với tôi thì đó là chuyện không chấp nhận được. Quay về tp Hồ Chí Minh, chúng tôi quyết định làm lại toàn bộ phân hệ quản lý kho.

Sau khoảng 45 ngày thì chúng tôi chuyển giao lại phân hệ này cho Minh Trí. Cho tới nay, SMW là một phần không thể thiếu trong công việc hàng ngày của toàn bộ nhà máy, kể từ lãnh đạo tới nhân viên. Cần xem NPL của Style nào, PO nào, còn thừa thiếu bao nhiêu, chỉ cần bật SMW và có thể thấy rất nhanh thông tin mình cần.
Sau khi phân hệ kho được làm lại, và đáp ứng được đầy đủ các yêu cầu của nhà máy, toàn bộ công việc phức tạp nhất trong nhà máy may, là tính toán, cân đối và cấp phát NPL đã hoàn tất, chúng tôi đã quyết định triển khai thêm các phân hệ để đi sâu vào quản lý sản xuất và đặc biệt là phân hệ quản lý bán thành phẩm, phần khó nhất của ngành may. Nó liên kết với hầu hết các phân hệ khác của hệ thống, chi tiết tới từng bó công đoạn trong chuyền, với lượng dữ liệu khổng lồ, sẽ lên tới hơn 10 triệu dòng mỗi năm..

Khi đó tôi nói với chị Hương:

- Để bắt đầu triển khai SMB (tên phân hệ quản lý mã vạch- bán thành phẩm), Hương có dám ngưng hoàn toàn hệ thống cũ, chấp nhận hệ thống mới có thể trục trặc trong vài ngày đầu không.
- Em đồng ý!
- Vậy thì làm.

Trong mấy ngày ở MT, tôi ngồi cùng các anh chị có liên quan ở xưởng cắt, bộ phận thống kê nhà máy thiết kế mới toàn bộ phân hệ quản lý BTP. Đây cũng là một bài học lớn với tôi, khi mọi người tham gia cùng mình từ những ngày đầu tiên, thì tới lúc triển khai, mọi việc sẽ thuận tiện. Vì hệ thống làm ra đã rất sát thực.

Sau khi thiết kế màn hình, tính năng của phân hệ này, tôi liên hệ với anh Đỗ Nam Hải, đề nghị anh xem và cho ý kiến, anh Hải trong vòng 3 ngày gửi lại cho tôi một bản đánh giá chi tiết, có vẽ lại nhiều màn hình cho hợp lý hơn, đặc biệt là màn hình quản lý kế hoạch bán thành phẩm, cho đúng với đặc thù.

Việc còn lại là thiết kế CSDL và lập trình, với TTSOFT thì không phải là khó, cho dù SMB là phân hệ khó nhất đi nữa, thì cũng chỉ sau 30 ngày, chúng tôi đã có thể test phần mềm cùng chị Hương, và sau 30 ngày nữa thì hệ thống được chính thức đưa vào hoạt động. Cho tới ngày hôm nay, hệ thống vẫn ngày ngày in mã vạch cho từng bó bán thành phẩm, dùng mã vạch để theo dõi việc cấp phát bán thành phẩm, quản lý việc chuyển đi thêu in, nhận về. Với xưởng may, hệ thống vẫn hàng ngày ghi nhận tiến độ sản lượng của cả chuyền cũng như từng công nhân.

Vào thời điểm bắt đầu ứng dụng, quả thực là tôi cũng hơi ái ngại, khác với các phân hệ khác, có thể ngưng hoạt động để khắc phục sự cố trong vòng nửa ngày tới một ngày, mà không làm ngưng trệ hoạt động sản xuất, riêng phân hệ SMB thì không thế, thời gian để chúng tôi khắc phục sự cố chỉ được tính bằng giờ!

 Chỉ bằng lòng tin của chị Hương và lãnh đạo công ty vào TTSOFT, và sự quyết tâm của cả hai bên, mà hệ thống đã được đưa vào thực tế.

Đúng là có trục trặc liên tục trong tuần đầu tiên, nhưng tất cả các lỗi, các phát sinh đều được TTSOFT khắc phục trong vòng một tới hai tiếng. Đây cũng là thời điểm mà trình độ viết phần mềm của TTSOFT được thử thách cao độ. Với những ai đã từng viết phần mềm, sẽ hiểu một điều là “sẽ không bao giờ có thể đảm bảo rằng một lỗi nào đó có thể khắc phục được chắc chắn trong vòng một ngày”. Có những lỗi phát sinh nằm ngoài sự kiểm soát của bộ phận lập trình, nó có thể trong phần cứng, trong hệ điều hành, trong hệ quản trị CSDL, nằm trong sự không đồng bộ giữa các phần đó. Với SMB, nó còn nằm ở máy in (mã vạch), nằm ở giấy, nằm ở đầu đọc…

Và đây cũng là điểm khác biệt của Sewman với các sản phẩm phần mềm khác, tại Minh Trí, Sewman được khai thác ở mức thời gian thực, được gắn trực tiếp vào luồng nghiệp vụ của nhà máy, chứ không đơn thuần là thu nhận thông tin quản lý như các phần mềm thông thường. Mỗi ngày, 4 máy in laser Canon khổ A3 được chạy liên tục để in ra gần 1000 tờ mã bó. Chính chúng tôi cũng ngạc nhiên trước những con số này.

Cũng trong dịp triển khai SMB, chúng tôi cũng đã thống nhất bổ sung chức năng tổng hợp và phân tích lương công đoạn, để người quản lý kiểm soát được toàn bộ quá trình khai báo, tính toán lương cho từng công nhân, để phát hiện kịp thời những bất hợp lý trong tính toán, để có thể trả lời nhanh những thắc mắc, khiếu kiện của tổ trưởng và công nhân.

Những chuyện cụ thể của SMB.

Trong quá trình triển khai SMB, do hệ thống chạy với thời gian thực chúng tôi đã phải giải quyết nhiều vấn đề hết sức cụ thể, mà không thể né tránh.
1. Gom bó và chia nhỏ bó.
2. Trình bày kế hoạch bán thành phẩm theo đúng yêu cầu của anh Hải.
3. Sơ đồ cắt thì theo chiều dài, nhu cầu kiểm soát vải thì cần theo trọng lượng.
4. Cắt xong, ghi nhận xong, còn phải hạ cỡ, hoặc điều chuyển qua bó khác.
5. Hệ số lương cho từng PO khác nhau cho từng xưởng và thay đổi theo thời gian
6. Làm sao để người nhập số liệu kiểm phôi bằng mã vạch chỉ dùng 1 bàn tay để vừa nhập số phôi hỏng, vừa đọc được mã vạch liên tục, với tốc độ 2-3 mã/1 s.
7. Làm sao để những thay đổi, chỉnh sửa không làm gián đoạn hoạt động của các phân hệ khác, vốn đã hoạt động ổn định.

Sau khi xử lý thành công những yêu cầu tưởng chừng rất nhỏ, nhưng thực ra rất khó làm, chúng tôi học được mấy bài học lớn:

- Nếu không có quy hoạch tốt từ đầu, thiết kế mô hình CSDL tốt, thì không thể hòan thiện sản phẩm (tôi đang nói tới hệ thống lớn như ERP)
- Nếu không có quyết tâm làm tới cùng, dù khó tới đâu, thì sản phẩm làm ra cũng để chơi, không thể ứng dụng thực tế.
- Nếu không bình tĩnh, tự tin, thì không thể xử lý được những lỗi làm gián đoạn hoạt động sản xuất.

Những cái yêu cầu “cuối cùng” như thế này, thường dẫn tới cái “chết” của việc triển khai ERP. Do chúng phát sinh sau khi mọi thứ đã gần như hoàn thành, cho nên bên thiết kế, triển khai nhiều khi phải thay đổi rất lớn trong cấu trúc hệ thống vì không lường trước được. Mà khi đó thì sức lực đã gần như cạn kiệt, cố gắng đã quá nhiều. Nếu không đủ bình tĩnh, tỉnh táo, cũng như không thực sự nắm vững hệ thống và có kỹ năng lập trình rất tốt, thì không thể làm được. Đây cũng chính là trường hợp 20% chức năng còn lại chiếm 80% thời gian sản xuất, nói cách khác, ở nhiều dự án, thời gian triển khai kéo dài lê thê là như vậy.
Mặt khác, nếu những chức năng nhỏ như thế, mà không làm được, thì không thể triển khai, hoặc triển khai kiểu ép người dùng phải dùng, và sớm muộn cũng dẫn tới kết quả là hệ thống sẽ không được sử dụng. Tôi đã thấy chuyện này ở rất nhiều nơi… đặc biệt là các nơi sản phẩm ERP nước ngoài được triển khai bằng đội ngũ trong nước…