Hệ thống quản lý sản xuất 2026 – Phát triển riêng hay mua phần mềm đóng gói

Trên màn chiếu của phòng họp là bảng so sánh chức năng của ba sản phẩm phần mềm đóng gói. Những dấu tròn, dấu chéo và dấu tam giác xếp thành hàng, sản phẩm có nhiều dấu tròn nhất đã được đánh dấu. Đến đây thì mất hai tuần. Vậy mà vẫn chưa chốt được, vì phía hiện trường cứ nói mãi một câu rằng hồ sơ kiểm tra của nhà máy sẽ không chạy nổi với cái này. Việc chọn phát triển hệ thống quản lý sản xuất riêng từ đầu hay mua phần mềm đóng gói sẽ không được phân định trên bảng so sánh đó. Thứ quyết định không phải là các dấu tròn dấu chéo về chức năng, mà chỉ một điểm duy nhất là trong 5 năm sau khi hệ thống chạy thật, mỗi năm quy tắc nghiệp vụ của bạn thay đổi bao nhiêu người-tháng.

Tiêu chí chọn phát triển hệ thống quản lý sản xuất riêng từ đầu không nằm ở danh sách chức năng

Lý do bảng so sánh chức năng không đưa ra được câu trả lời rất đơn giản. Bảng đó chấm điểm tròn hay chéo cho nghiệp vụ ở thời điểm hiện tại. Còn hệ thống chỉ thực sự bị đánh giá sau khi đã chạy thật, khi chính nghiệp vụ bắt đầu thay đổi.

Quy tắc nghiệp vụ trong nhà máy không bao giờ đứng yên. Có khách hàng mới thì có thêm biểu mẫu. Có đợt đánh giá của khách hàng thì có thêm hạng mục ghi chép. Thêm một chuyền sản xuất thì cấu trúc dữ liệu chủ về công đoạn thay đổi. Luật thay đổi thì thời hạn lưu trữ thay đổi. Những thay đổi như vậy phát sinh đều đặn mỗi năm sau khi hệ thống đã chạy, với một khối lượng khá ổn định.

Khác biệt thật sự giữa phần mềm đóng gói và phát triển riêng nằm ở chỗ hấp thụ những thay đổi phát sinh hằng năm đó bằng bao nhiêu công, và trả bao nhiêu tiền cho số công ấy. Chức năng có đủ hay không là bài toán của ngày đầu tiên, còn hấp thụ được thay đổi hay không là bài toán của 5 năm còn lại. Xét về số tiền, vế sau mới là vế lớn.

Vì sao câu nói chức năng đã đủ rồi lại sụp đổ sau ba năm

Giả sử tại thời điểm triển khai, chức năng tiêu chuẩn của phần mềm đóng gói phủ được 90% nghiệp vụ. Phần 10% còn lại được lấp bằng vài thiết lập nhẹ và một lượng nhỏ chỉnh sửa, hệ thống chạy thật trót lọt. Đến đây vẫn là thành công.

Vấn đề nổ ra vào năm thứ ba. Những quy tắc nghiệp vụ được thêm vào trong ba năm đó dĩ nhiên phát sinh mà không hề đếm xỉa đến triết lý thiết kế của phần mềm đóng gói. Độ chi tiết của hồ sơ kiểm tra mà khách hàng yêu cầu, logic phân bổ giá thành mà trụ sở chính đòi hỏi, tất cả đều được quyết định mà không biết gì về giả định của sản phẩm. Muốn đưa chúng lên hệ thống thì phải thò tay vào phía sau chức năng tiêu chuẩn.

Một khi đã thò tay vào phía sau, lần nâng cấp phiên bản kế tiếp sẽ kéo theo công việc làm lại đúng chỗ đó. Chỗ vừa làm lại xong lại tiếp tục gánh thêm yêu cầu mới. Sự chồng chất này diễn ra trong ba đến năm năm, và khi nhận ra thì nhà máy đã ở trạng thái đang dùng phần mềm đóng gói mà không còn giữ lại được một lợi ích nào của phần mềm đóng gói.

Bản tổng hợp của Godlan dẫn lại báo cáo ERP năm 2026 của Panorama Consulting Group cho thấy hệ quả của cấu trúc này bằng con số. Phân tích hơn 2,400 dự án triển khai trong khoảng từ tháng 9 năm 2025 đến tháng 1 năm 2026 cho thấy 73% dự án ERP trong ngành sản xuất rời rạc không đạt mục tiêu, cao hơn mức trung bình 68% của toàn bộ các ngành. Mức vượt chi phí trung bình là 215% so với trung bình ngành 189%, vượt tiến độ là 30% so với trung bình ngành 25%, và tỷ lệ đạt mục tiêu là 27%. Cách đọc những con số này là ngành sản xuất dễ thất bại hơn các ngành khác.

Cũng chính bản tổng hợp đó chỉ ra cách xử lý. So với chỉnh sửa sâu, việc thích ứng ở mức vừa phải trong khuôn khổ triết lý thiết kế của sản phẩm cho kết quả tốt hơn, và 45% doanh nghiệp đạt kết quả tốt nhất bằng cách này. Nói cách khác, nếu chọn phần mềm đóng gói thì hãy dùng nó một cách nhẹ nhàng, còn nếu muốn xây dựng thật sâu thì hãy bỏ hẳn nền tảng đóng gói. Nửa vời là tệ nhất. Về những thứ đổ vỡ ngay trong giai đoạn triển khai, chúng tôi đã tổng hợp riêng trong bài 5 đứt gãy khiến triển khai hệ thống quản lý sản xuất thất bại.

Câu hỏi cần quyết có thể thu về đúng một câu

Vì vậy, câu hỏi cần tranh luận trong cuộc họp lựa chọn không phải là sản phẩm nào nhiều chức năng hơn.

Nhà máy của chúng ta là kiểu nhà máy có bao nhiêu người-tháng quy tắc nghiệp vụ thay đổi mỗi năm.

Chỉ một câu này thôi. Trong bài viết, khối lượng đó được ký hiệu là x, đơn vị là người-tháng mỗi năm. Người-tháng là đơn vị đo khối lượng công việc, tương đương công sức của một người làm trong một tháng. Nhà máy có x nhỏ thì phần mềm đóng gói rẻ hơn, nhà máy có x lớn thì phát triển riêng rẻ hơn. Và trong mô hình tính được trình bày ở phần sau, điểm ranh giới giữa hai bên rơi vào một con số cụ thể là khoảng 1.4 người-tháng mỗi năm.

x không phải cảm nhận chủ quan, nó đo được từ lịch sử thay đổi của 24 tháng đã qua. Cách đo được viết thành 5 bước ở nửa sau bài viết.

Đây không phải hai lựa chọn mà là ba, và đắt nhất lại là phương án ở giữa

Cái bẫy đầu tiên nằm ngay trong cách đặt đề bài phần mềm đóng gói hay phát triển riêng. Bởi vì thứ mà nhiều nhà máy thực sự chọn lại là phương án ở giữa. Mua phần mềm đóng gói rồi xây dựng thêm thật nhiều cho những chỗ còn thiếu. Trong nội bộ, phương án này thường được giải thích là lấy phần hay của cả hai bên, và tờ trình phê duyệt cũng dễ được thông qua.

Trong mô hình tính này, chính phương án ở giữa đó lại đắt nhất.

Định nghĩa ba phương án A, B, C

Để so sánh, ba phương án được định nghĩa bằng người-tháng. Tất cả các con số dưới đây đều dựa trên cùng một quy mô giả định là một nhà máy Nhật tại Thái Lan với 40 người dùng hệ thống quản lý sản xuất.

Phương án A tương ứng với cái mà bản tổng hợp của Godlan gọi là thích ứng ở mức vừa phải trong khuôn khổ triết lý thiết kế của sản phẩm. Phương án B là trạng thái đã bước ra ngoài khuôn khổ đó. Phương án C là hình thức tự mình nắm luôn cả phần nền.

Điểm đáng lưu ý là khoảng cách giữa 22 người-tháng của B và 26 người-tháng của C chỉ có 4 người-tháng. Trực giác cho rằng mua phần mềm đóng gói thì khối lượng phải xây dựng sẽ giảm không còn đúng khi đã đi tới mức chỉnh sửa sâu. Công việc đặt một nghiệp vụ không khớp với chức năng tiêu chuẩn lên trên chính chức năng tiêu chuẩn ấy có khi còn không rẻ hơn việc viết từ tờ giấy trắng. Lý do là phải chèn vào trong khi vẫn phải bám theo cấu trúc dữ liệu và trình tự xử lý sẵn có.

Vì sao chỉnh sửa sâu phần mềm đóng gói lại thành ra phải nộp hai khoản thuế

Phương án B đắt không chỉ vì chi phí xây dựng cao. Mà vì ngay cả khi đã trả xong chi phí xây dựng, cấu trúc chi phí vẫn buộc bạn phải tiếp tục trả hai khoản mục mỗi năm.

Khoản thuế thứ nhất là phí bản quyền. Chừng nào còn dùng phần mềm đóng gói làm nền thì dù chất bao nhiêu chỉnh sửa lên trên, phí bản quyền cũng không giảm. Trong mô hình này, phí đó là 40 người dùng × 2,500 THB mỗi tháng = 1,200,000 THB mỗi năm, tức 6,000,000 THB trong 5 năm. Phương án A cũng trả đúng số tiền này, nhưng A dùng đúng phần chức năng tiêu chuẩn tương ứng với số tiền đã trả. Còn B thì ghi đè phần lớn chức năng tiêu chuẩn bằng chỉnh sửa của mình, mà vẫn tiếp tục trả tiền cho cả phần chức năng tiêu chuẩn đã bị ghi đè đó.

Khoản thuế thứ hai là công làm lại phần chỉnh sửa khi nâng cấp phiên bản. Khi phiên bản của phần mềm đóng gói lên đời, những chỗ đã chỉnh sửa phải được kiểm tra lại hoạt động, và phần lớn phải làm lại. Càng chỉnh sửa nhiều thì công việc làm lại này càng lớn. Mô hình này giả định trong 5 năm có một lần nâng cấp phiên bản, và tại thời điểm đó phải làm lại 40% khối lượng chỉnh sửa đã tích lũy. Vì chỉnh sửa ban đầu của B lớn tới 14 người-tháng nên riêng khoản làm lại này, B đã gánh khoảng 2.4 lần phương án A khi x = 1, tức 1,368,000 THB so với 576,000 THB, và khoảng 1.5 lần khi x = 4, tức 2,448,000 THB so với 1,656,000 THB.

Cả hai khoản này đều không tồn tại ở phương án phát triển riêng. Phát triển riêng không có phí bản quyền, cũng không có công làm lại theo kế hoạch phiên bản của một công ty khác. Đổi lại thì cần chi phí hạ tầng và chi phí bảo trì, nhưng như sẽ thấy ở phần sau, tổng của hai khoản đó vẫn nhỏ hơn phí bản quyền.

Hơn nữa, hai khoản thuế này còn có một tính chất là trả tiền mà nghiệp vụ không tốt lên. Công làm lại phần chỉnh sửa khi nâng cấp phiên bản không hiện thực hóa được một yêu cầu nghiệp vụ nào. Nó chỉ lấy thứ đang chạy được và làm lại để nó vẫn chạy được như cũ. Đó là lý do người phụ trách luôn vất vả mỗi lần phải giải thích khoản mục này trong cuộc họp ngân sách.

Mô hình tính tổng chi phí 5 năm – điểm cân bằng là 1.4 người-tháng mỗi năm

Từ đây sẽ đặt các con số tiền. Toàn bộ những gì dưới đây là mô hình tính của chúng tôi, không phải báo giá cho một dự án cụ thể. Vì mọi giả định đều được viết ra hết, bạn hãy thay bằng số liệu của chính mình khi đọc.

Các giả định về đơn giá người-tháng, số người dùng và thời gian

Đơn giá 180,000 THB mỗi người-tháng là một con số có biên độ. Thực tế trên thị trường trải từ 150,000 đến 250,000 THB mỗi người-tháng. Cũng trong khảo sát đó của ERI SalaryExpert, lập trình viên tại Bangkok có 1 đến 3 năm kinh nghiệm nhận 834,099 THB mỗi năm, còn người từ 8 năm kinh nghiệm trở lên nhận 1,362,287 THB, quy ra tháng thì chênh nhau khoảng 44,000 THB. Bố trí ai và bao nhiêu người sẽ làm đơn giá dịch chuyển.

Xin đặt thêm mặt bằng giá ở nước ngoài để tham khảo. Theo bản tổng hợp năm 2026 của LI Solutions, chi phí bảo trì trong phát triển phần mềm thuê ngoài thường ở mức 15 đến 25% chi phí xây dựng ban đầu mỗi năm, hệ thống nghiệp vụ quy mô vừa và nhỏ nằm trong khoảng 50,000 đến 120,000 USD, còn hệ thống xây dựng đầy đủ bao gồm tích hợp, phân tích và kiểm thử chất lượng nằm trong khoảng 100,000 đến 500,000 USD. Về thị trường Nhật Bản, bản tổng hợp năm 2026 của c3index đưa ra chi phí xây dựng hệ thống lõi từ 5 triệu yên đến 300 triệu yên tùy quy mô. Vì khác cả đơn vị tiền lẫn phạm vi công việc nên những con số này hoàn toàn không được quy đổi vào phần tính bằng THB của bài viết. Chúng chỉ dùng để đối chiếu cảm nhận về mặt bằng giá.

Cách đặt chi phí bảo trì ở mức 12% cần được giải thích thêm. Mặt bằng theo LI Solutions là 15 đến 25%, nhưng trong mô hình này phần bổ sung chức năng đã được tách riêng thành x nên bảo trì được đặt thấp hơn, ở mức 12%. Với trường hợp x = 1 người-tháng mỗi năm, cộng gộp lại thì con số tương ứng là 15.8% chi phí xây dựng ban đầu mỗi năm, tức nằm quanh cận dưới của mặt bằng. Nếu x = 4 người-tháng mỗi năm thì là 27.4%, hơi vượt mặt bằng. Khi thay bằng số liệu của mình, bạn hãy kiểm tra xem sự nhất quán này còn giữ được hay không.

Trong bảng trên, hai thứ chúng tôi mong bạn thay bằng số liệu của mình là đơn giá người-tháng và số người dùng. Chỉ cần thay hai giá trị đó là bạn đã có thể vẽ lại hướng của các kết luận dưới đây cho đúng với nhà máy mình. Nếu bạn băn khoăn về cách đặt chi phí hạ tầng, hãy tham khảo thêm bài Chọn đám mây hay tại chỗ cho quản lý sản xuất.

Công thức tổng chi phí 5 năm

Tổng chi phí 5 năm của ba phương án đều viết được thành hàm bậc nhất theo x.

• Phương án A(x) = 1,980,000 + 6,000,000 + 900,000x + 0.4 × (3 + 5x) × 180,000 = 8,196,000 + 1,260,000x
• Phương án B(x) = 3,960,000 + 6,000,000 + 900,000x + 0.4 × (14 + 5x) × 180,000 = 10,968,000 + 1,260,000x
• Phương án C(x) = 4,680,000 + 1,200,000 + 2,808,000 + 900,000x = 8,688,000 + 900,000x

Chi tiết từng số hạng như sau.

Cả ba phương án đều được đo từ cùng một mốc gốc là cách vận hành bằng Excel hiện tại. Để không đếm hai lần phần giá trị mang lại, chúng tôi chỉ so sánh bằng tổng chi tiêu chứ không so sánh bằng khoản tiết kiệm. Số hạng 900,000x của chỉnh sửa hằng năm là chung cho cả ba phương án, vì dù chọn phương án nào thì bản thân sự thay đổi của quy tắc nghiệp vụ cũng không biến mất.

Khi x = 1 người-tháng mỗi năm

Đây là nhà máy mỗi năm phát sinh yêu cầu chỉnh sửa bằng 1 người-tháng, tức tương đương 20 ngày làm việc.

Rẻ nhất là phương án A. Tuy nhiên khoảng cách với C chỉ là 132,000 THB, tức chỉ nhiều hơn 1.4% so với A. Trong tổng chi tiêu gần 10 triệu THB suốt 5 năm mà chênh nhau 130,000 THB thì trên thực tế hai bên ngang nhau. Chỉ cần dịch chuyển giả định một chút là thứ tự sẽ đổi chỗ.

Ngược lại, phương án B là 12,228,000 THB, cao hơn A tới 2,772,000 THB, tức nhiều hơn 29.3% so với A. So với C thì cũng cao hơn 2,640,000 THB, tức nhiều hơn 27.5% so với C. Ngay cả ở nhà máy có x nhỏ, chỉnh sửa sâu vẫn đắt vượt trội, đó là điều xác nhận được tại đây.

Khi x = 4 người-tháng mỗi năm

Đây là nhà máy mỗi năm phát sinh yêu cầu chỉnh sửa bằng 4 người-tháng, tức 80 ngày làm việc. Nhà máy nhiều đơn hàng theo yêu cầu riêng, mỗi khách hàng lại có biểu mẫu và hạng mục kiểm tra khác nhau thường rơi vào mức này.

Thứ tự đổi chỗ. Rẻ nhất là phương án C với 12,288,000 THB. Phương án A cao hơn C 948,000 THB, tức nhiều hơn 7.7% so với C. Phương án B cao hơn C 3,720,000 THB, tức nhiều hơn 30.3% so với C.

Chênh lệch giữa phương án B và A luôn cố định ở mức 2,772,000 THB, cả khi x = 1 lẫn khi x = 4. Lý do là hệ số góc của phần chỉnh sửa hằng năm ở hai phương án bằng nhau, đều là 1,260,000x, khác biệt chỉ nằm ở khối lượng chỉnh sửa ban đầu và khối lượng làm lại khi nâng cấp. Nói cách khác, số tiền cộng thêm do chỉnh sửa sâu sẽ không bao giờ được thu hồi, dù x có lớn đến đâu. Lập luận bênh vực chỉnh sửa sâu là xây dựng sẵn từ đầu thì sau này thay đổi sẽ nhẹ nhàng hơn, nhưng một khi hệ số góc của hai bên bằng nhau thì sẽ không có thời điểm nào B đuổi kịp A dù thay đổi có tăng lên. Khoản 2,772,000 THB này chính là cái giá của bản thân lựa chọn đặt hệ thống lên trên nền phần mềm đóng gói.

Công thức tìm điểm cân bằng chi phí và cách thay bằng số liệu của nhà máy bạn

Ta đi tìm giá trị x mà tại đó tổng chi phí 5 năm của phương án A và phương án C bằng nhau. Đây là điểm cân bằng giữa hai phương án về mặt chi phí, không phải điểm hòa vốn giữa doanh thu và chi phí.

“`

8,196,000 + 1,260,000x = 8,688,000 + 900,000x

360,000x = 492,000

x ≈ 1.37

“`

Điểm cân bằng là khoảng 1.4 người-tháng mỗi năm. Nếu quy một người-tháng bằng 20 ngày làm việc thì đó là khoảng 28 người-ngày mỗi năm. Tại điểm này, tổng chi phí 5 năm của cả hai phương án đều bằng khoảng 9,918,000 THB.

Diễn giải cấu trúc của công thức bằng lời thì như sau. Con số 492,000 THB ở vế phải là lợi thế của phương án A về mặt chi phí cố định. Phía C trả nhiều hơn 2,700,000 THB ở khâu xây dựng ban đầu, nhưng bù lại chi phí duy trì trong 5 năm của C ít hơn 2,208,000 THB, nên tính trừ đi thì A xuất phát từ vị trí có lợi hơn đúng 492,000 THB. Chi tiết của khoảng cách chi phí duy trì là phí bản quyền 6,000,000 THB so với hạ tầng cộng bảo trì của C là 4,008,000 THB, tức chênh 398,400 THB mỗi năm và 1,992,000 THB trong 5 năm. Cộng thêm 216,000 THB tiền làm lại khi nâng cấp của A thì thành 2,208,000 THB.

Con số 360,000x ở vế trái là phần A phải trả nhiều hơn C mỗi khi x tăng thêm 1 người-tháng. Bản thân phần chỉnh sửa hằng năm là chung cho cả ba phương án, nhưng riêng A còn phải làm lại 40% khối lượng chỉnh sửa đó sau 5 năm, nên mỗi người-tháng bị cộng thêm 0.4 × 5 × 180,000 = 360,000 THB. Thời điểm phần cộng thêm này ăn hết 492,000 THB chính là điểm cân bằng.

Quy trình thay bằng số liệu của nhà máy bạn gồm ba bước.

1. Thay đơn giá người-tháng bằng mức thực tế của bạn. Nếu đổi 180,000 THB thành 150,000 THB thì hãy nhân toàn bộ những số hạng tỷ lệ với người-tháng cho 0.833. Chỗ dễ bỏ sót ở đây là chi phí bảo trì của phương án C. Vì chi phí bảo trì được đặt bằng 12% chi phí xây dựng ban đầu mỗi năm nên khi đơn giá giảm thì chi phí xây dựng ban đầu giảm, kéo theo chi phí bảo trì cũng giảm. Nghĩa là có bốn thứ cần nhân 0.833, gồm chi phí xây dựng ban đầu, chỉnh sửa hằng năm, phần làm lại khi nâng cấp và chi phí bảo trì của C. Chỉ có hai thứ không đổi là phí bản quyền và chi phí hạ tầng. Nếu cứ để chi phí bảo trì của C ở nguyên mức 561,600 THB mỗi năm thì bạn sẽ ước tính thừa 468,000 THB cho tổng 5 năm của C và đặt sai vị trí điểm cân bằng.
2. Thay số người dùng. Nếu đổi 40 người thành 80 người thì phí bản quyền thành 2,400,000 THB mỗi năm và lợi thế chi phí cố định của A biến mất. Với phần mềm đóng gói tính tiền theo người dùng, số người trực tiếp kéo điểm cân bằng xuống thấp.
3. Đo x của chính nhà máy bạn rồi thế vào công thức. Cách đo là nội dung của chương tiếp theo.

Con số điểm cân bằng khoảng 1.4 người-tháng mỗi năm phụ thuộc rất mạnh vào hai giả định vừa nêu. Đơn giá giảm thì C có lợi, số người dùng giảm thì A có lợi. Quan trọng hơn bản thân con số là hiểu được nó dịch chuyển theo hướng nào rồi áp vào nhà máy mình. Về dải chi phí rộng hơn theo từng khoản mục, chúng tôi đã tổng hợp trong bài Chi phí hệ thống quản lý sản xuất.

Xin nói thêm rằng mô hình tính này cố ý không bao gồm một số thứ. Chúng tôi không viết số năm thu hồi vốn. Cả ba phương án đều là chi tiêu và không đặt được quan hệ đầu tư với thu hồi một cách duy nhất, nên chúng tôi không đưa ra một số năm mà mẫu số không có căn cứ. Ngoài ra, mô hình giả định 22 người-tháng của phương án B và 26 người-tháng của phương án C đạt tới mức phù hợp nghiệp vụ tương đương nhau. Trên thực tế cũng có trường hợp B bị chức năng tiêu chuẩn kéo lại nên mức phù hợp còn lỏng lẻo, và cũng có trường hợp C bị xây dựng quá mức cần thiết.

5 bước đo khối lượng chỉnh sửa hằng năm x của nhà máy bạn, phần thực hành cho việc chọn hệ thống quản lý sản xuất

Đây mới là phần chính. x không ra được bằng cảm nhận. Nó được rút ra một cách máy móc từ các ghi chép đã có. Thời gian cần khoảng ba ngày với hai người, và một tuần nếu tài liệu nằm rải rác.

Bước 1 – Thu thập lịch sử thay đổi của 24 tháng đã qua

Có bốn nơi để thu thập.

• Phiếu yêu cầu gửi cho bộ phận CNTT hoặc kỹ thuật sản xuất, ticket nội bộ, thư mục email yêu cầu
• Email và báo giá gửi nhà cung cấp, lịch sử đặt hàng phát triển bổ sung
• Lịch sử sửa đổi của các file Excel, gồm ngày trong tên file, lịch sử thêm sheet, sheet ghi lịch sử thay đổi
• Ngày giờ cập nhật của macro và Access, phần ghi chú trong các module VBA

Lý do chọn mốc 24 tháng là để san phẳng ảnh hưởng của tính mùa vụ và kỳ quyết toán. Nếu chỉ lấy 12 tháng thì những thay đổi dồn vào cuối kỳ sẽ tác động quá mức. Ngược lại, nếu truy ngược tới 36 tháng thì sẽ có nhiều trường hợp người phụ trách khi đó đã nghỉ nên không còn ai xác định được nội dung.

Ở giai đoạn này chỉ cần thu thập số lượng vụ việc, chưa đánh giá nội dung. Mỗi vụ việc ghi thành một dòng trong bảng tính. Các cột chỉ cần năm tháng phát sinh, nơi yêu cầu, một dòng tóm tắt và đã xử lý hay chưa là đủ.

Bước 2 – Tách thay đổi quy tắc nghiệp vụ ra khỏi việc sửa cách dùng

Chia số vụ việc đã thu thập thành hai nhóm. Chỉ nhóm thứ nhất mới được tính vào x.

Nhóm quy tắc nghiệp vụ đã thay đổi, được tính vào x

• Khách hàng yêu cầu nên hạng mục kiểm tra hoặc hạng mục ghi chép tăng lên
• Một dòng sản phẩm mới được khởi động và cấu trúc dữ liệu chủ về công đoạn phải thay đổi
• Thay đổi cách phân bổ giá thành hoặc cách đánh giá tồn kho
• Lập biểu mẫu mới với bố cục theo đúng quy cách của khách hàng
• Luật hoặc tiêu chuẩn sửa đổi nên phải thay đổi thời hạn lưu trữ hoặc độ chi tiết của truy xuất nguồn gốc
• Có thêm chi nhánh hoặc kho nên phải mở rộng hệ thống mã

Nhóm chỉ sửa cách dùng, không tính vào x

• Sửa dữ liệu do nhập sai, bảo trì dữ liệu chủ theo vụ việc đơn lẻ
• Thêm quyền, đăng ký người dùng, cấp lại mật khẩu
• In biểu mẫu bị lệch nên chỉnh lại lề
• Trả lời các câu hỏi kiểu không biết dùng thế nào
• Khởi động lại máy chủ, các việc liên quan đến sao lưu

Làm nghiêm việc phân loại này chính là thứ quyết định độ chính xác của x. Nếu trộn cả các câu hỏi vận hành vào thì x sẽ phình lên gấp hai đến ba lần thực tế. Khi phân vân, bạn hãy lấy tiêu chí là vụ việc này có phát sinh hay không nếu vẫn tiếp tục làm đúng nghiệp vụ cũ. Nếu nó đã không phát sinh thì đó là thay đổi quy tắc nghiệp vụ, còn nếu vẫn làm nghiệp vụ cũ mà nó vẫn xảy ra thì đó là vận hành.

Bước 3 – Làm tròn quy mô thành ba mức rồi quy ra năm

Những vụ việc còn lại được làm tròn thành ba mức theo khối lượng công xử lý. Ước tính quá chi tiết chỉ tốn thời gian mà không làm tăng độ chính xác.

Sau khi cộng tổng, hãy chia cho 24 rồi nhân với 12. Đó là số người-tháng mỗi năm.

Xin nêu hai ví dụ.

Nhà máy P, mặt hàng sản xuất hàng loạt cố định, ít khách hàng. Trong 24 tháng có 7 vụ việc thuộc nhóm thay đổi quy tắc nghiệp vụ. Nhỏ 0.2 người-tháng × 5 vụ = 1.0, vừa 0.5 người-tháng × 2 vụ = 1.0. Tổng cộng 2.0 người-tháng. Quy ra năm là 2.0 ÷ 24 × 12 = 1.0 người-tháng mỗi năm.

Nhà máy Q, làm theo đơn hàng riêng, mỗi khách hàng một kiểu biểu mẫu và hạng mục kiểm tra. Trong 24 tháng có 19 vụ việc thuộc nhóm này. Nhỏ 0.2 người-tháng × 10 vụ = 2.0, vừa 0.5 người-tháng × 6 vụ = 3.0, lớn 1.0 người-tháng × 3 vụ = 3.0. Tổng cộng 8.0 người-tháng. Quy ra năm là 8.0 ÷ 24 × 12 = 4.0 người-tháng mỗi năm.

Hai ví dụ này ứng đúng với x = 1 và x = 4 trong phần tính ở trên. Nhà máy P có phương án A là rẻ nhất, còn nhà máy Q có phương án C là rẻ nhất. Cùng là nhà máy Nhật với 40 người dùng mà câu trả lời lại ngược nhau.

Bước 4 – Cộng thêm những thay đổi đã chắc chắn trong hai năm tới

Nếu chỉ quyết bằng quá khứ thì bạn sẽ bỏ sót phần tương lai đã chắc chắn. Bốn nhóm sau đây có thể lấy ra từ kế hoạch kinh doanh hoặc từ dự báo đơn hàng của bộ phận kinh doanh.

• Kế hoạch khởi động dòng sản phẩm mới, gồm bổ sung dữ liệu chủ về công đoạn và lập tiêu chuẩn kiểm tra mới
• Yêu cầu tăng cường truy xuất nguồn gốc từ khách hàng, gồm độ chi tiết của việc truy vết theo lô và thời gian lưu trữ hồ sơ
• Đáp ứng luật và tiêu chuẩn, gồm quy định môi trường, quản lý xuất khẩu, gia hạn chứng nhận ngành
• Mở thêm chi nhánh hoặc chuyển giao sản xuất, gồm mở rộng hệ thống mã và di chuyển tồn kho giữa các chi nhánh

Hãy ước tính chúng theo đúng ba mức đó, lấy phần của hai năm chia cho 24 rồi nhân với 12, sau đó cộng vào giá trị của bước 3. Nếu chỉ dùng số liệu thực tế của quá khứ, bạn sẽ đánh giá x thấp hơn thực tế ở những nhà máy đang trên đà tăng trưởng.

Ở ngành sản xuất Thái Lan, phần tương lai này có trọng lượng đáng kể. Theo tổng hợp của JETRO, hồ sơ xin đầu tư nộp lên BOI của Thái Lan năm 2025 đạt mức cao nhất từ trước tới nay, khoảng 1,800 tỷ baht. Bangkok Shuho còn cho biết vào tháng 6 năm 2026, chế độ rút ngắn thủ tục cấp phép dành cho lĩnh vực sản xuất tiên tiến mang tên Thailand Fast Pass đã chính thức khởi động, với tổng giá trị các dự án thuộc diện áp dụng vượt 700 tỷ baht. Đầu tư xung quanh dịch chuyển cũng có nghĩa là cơ cấu đơn hàng và danh mục sản phẩm của chính bạn sẽ dịch chuyển.

Bước 5 – Thế giá trị x thu được vào công thức

Hãy thế vào phương án A(x) = 8,196,000 + 1,260,000x và phương án C(x) = 8,688,000 + 900,000x rồi so sánh. Nếu x thấp hơn 1.4 một cách rõ ràng thì chọn dùng phần mềm đóng gói theo chuẩn, nếu cao hơn một cách rõ ràng thì chọn phát triển riêng. Trường hợp x rơi vào khoảng từ 1.0 đến 1.8 thì riêng mô hình tính này chưa quyết được. Vì tổng chi phí ngang nhau nên bạn sẽ phải quyết bằng những điều kiện ngoài tiền.

Đặc điểm của những nhà máy dễ có x lớn

Hãy tự chẩn đoán bằng số mục đúng với mình. Nếu đúng từ ba mục trở lên thì chưa cần đo bạn cũng đã thuộc nhóm có x lớn.

1. Làm theo đơn hàng riêng, nhiều chủng loại ít số lượng, mỗi khách hàng một kiểu biểu mẫu và hạng mục kiểm tra
2. Khách hàng đánh giá nhiều, cứ mỗi lần đánh giá là hạng mục ghi chép lại tăng
3. Kế hoạch kinh doanh có ghi việc tăng chi nhánh hoặc tăng chủng loại sản xuất
4. Hiện trường có tiếng nói mạnh, văn hóa để đề xuất cải tiến đi thẳng lên thành yêu cầu với hệ thống

Ngược lại, x nhỏ ở những nhà máy có mặt hàng sản xuất hàng loạt cố định, ít khách hàng, và quy tắc nghiệp vụ do chuẩn của trụ sở chính quy định. Trong trường hợp đó, bản thân quyền thay đổi quy tắc nghiệp vụ tại chỗ vốn đã rất ít nên x không tăng lên được về mặt cấu trúc.

Mục số 1, kiểu làm theo đơn hàng riêng, là đại diện tiêu biểu cho nhóm có x lớn. Cách thiết kế cho nghiệp vụ mà công đoạn thay đổi theo từng đơn hàng được bàn kỹ trong bài Quản lý sản xuất theo đơn hàng riêng.

Bốn điều kiện khiến phần mềm đóng gói vẫn là đáp án đúng và bốn điều kiện khiến phát triển riêng là đáp án đúng

Có những trường hợp không thể quyết chỉ bằng x. Sau đây là các điều kiện ngoài tiền.

Bốn điều kiện khiến phần mềm đóng gói, tức phương án A, là đáp án đúng

1. x được dự báo thấp hơn 1 người-tháng mỗi năm. Hãy xác nhận rằng nó thấp hơn ở cả số liệu thực tế của 24 tháng đã qua lẫn phần đã chắc chắn trong hai năm tới. Chỉ một trong hai thì chưa đủ.
2. Trụ sở chính nắm chuẩn nghiệp vụ và nơi sở tại không có quyền thay đổi quy tắc nghiệp vụ. Trong trường hợp này, phần lớn yêu cầu phát sinh tại chỗ sẽ kết thúc ở bước hỏi trụ sở chính rồi bị bác, nên không tích lũy vào x.
3. Thời hạn khởi động ngắn. Khi có những mốc như phải kịp nhà máy đi vào hoạt động hoặc phải có cơ chế ghi chép trước kỳ đánh giá, khoảng cách giữa 11 người-tháng và 26 người-tháng ban đầu là một ràng buộc còn nặng hơn cả tiền.
4. Nội bộ không có bộ máy để duy trì tài liệu đặc tả và mã nguồn về lâu dài. Phát triển riêng là phương án mà bản gốc của đặc tả nằm trong tay chính công ty bạn. Nếu không giữ nổi thì đừng chọn phương án đó.

Bốn điều kiện khiến phát triển riêng, tức phương án C, là đáp án đúng

1. x vượt 1.8 người-tháng mỗi năm. Đây là mức đã tính dư so với điểm cân bằng 1.4. Xét đến sai số của phép đo, việc chỉ nhỉnh hơn 1.4 một chút chưa đủ làm căn cứ phán đoán.
2. Bản thân quy tắc nghiệp vụ đang là năng lực cạnh tranh. Nếu cách quản lý công đoạn đặc thù, cách tính giá thành riêng hoặc các thỏa thuận với khách hàng chính là yếu tố khác biệt hóa, thì việc vứt bỏ chúng để chạy theo chuẩn của phần mềm đóng gói là một tổn thất về mặt kinh doanh.
3. Có tiền đề sử dụng từ 5 năm trở lên, và kế hoạch có ghi việc mở rộng chi nhánh hoặc thêm chủng loại. Kỳ so sánh càng kéo dài tới 7 năm hay 10 năm thì phần phí bản quyền tích lũy càng có lợi cho C.
4. Có ý chí và bộ máy để tự giữ bản gốc của đặc tả về lâu dài. Điều kiện là quản lý được tài liệu phân tích yêu cầu, định nghĩa bảng dữ liệu và lịch sử thay đổi như tài sản của công ty, và duy trì được trạng thái bàn giao được ngay cả khi người phụ trách thay đổi.

Điều kiện thứ tư là mục có cái giá phải trả lớn nhất khi không đáp ứng được. Ngày 28 tháng 5 năm 2025, Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản đã công bố báo cáo tổng kết của Ủy ban hiện đại hóa hệ thống cũ, trong đó tổng kết tình hình ứng phó với cảnh báo về cái gọi là “vách đá năm 2025” mà báo cáo DX năm 2018 đã nêu, tức là nếu để mặc thì trong 5 năm kể từ 2025 sẽ phát sinh thiệt hại kinh tế tối đa 12 nghìn tỷ yên mỗi năm. Cái gọi là hệ thống cũ ở đây không phải bản thân việc được viết bằng công nghệ đời cũ. Nó nói đến trạng thái mà cả người giải thích được nội dung lẫn tài liệu đều đã mất. Theo nghĩa này, một hệ thống phát triển riêng mà không có tài liệu đặc tả và một hệ thống chỉnh sửa sâu mà không lưu lại ghi chép về các chỉnh sửa sẽ đáp xuống cùng một chỗ. Chọn phương án C có nghĩa là hứa duy trì được bộ máy sao cho 5 năm sau vẫn có người trong công ty giải thích được nội dung bên trong nó.

Vậy còn phương án B, phần mềm đóng gói chỉnh sửa sâu, thì sao. Trong mô hình này, B không rẻ nhất ở bất kỳ giá trị x nào. Nó luôn cao hơn A 2,772,000 THB, còn khoảng cách với C là 2,640,000 THB khi x = 1 và 3,720,000 THB khi x = 4, tức x càng tăng thì khoảng cách càng giãn ra. Nếu vẫn có lý do để chọn B thì lý do đó nằm ngoài mô hình. Chẳng hạn khi trụ sở chính đặt yêu cầu bắt buộc phải là sản phẩm đóng gói vì lý do kế toán hợp nhất, hoặc khi cần bảo đảm sản phẩm từ nhà cung cấp để phục vụ việc đánh giá. Trong trường hợp đó, hãy ghi rõ trong tờ trình phê duyệt rằng bạn chọn nó khi đã biết là bất lợi về tiền. Mục đích là để về sau, khi bị hỏi vì sao lại đắt thế này, bạn vẫn ở trong trạng thái giải thích được.

Làm bằng AI thì rẻ, điều đó có đúng không

Trong các cuộc họp lựa chọn của năm 2026, luận điểm này chắc chắn sẽ xuất hiện. Đó là lập luận rằng AI viết được mã nên phát triển riêng bây giờ rẻ rồi. Hãy nhìn con số để phán đoán.

Theo khảo sát của DX, tức getdx.com, phân tích hơn 400 công ty trong 14 tháng, mức cải thiện trung vị của thông lượng pull request nhờ đưa trợ lý lập trình AI vào là 7.76%. Phần lớn doanh nghiệp nằm trong khoảng 5 đến 15%, còn ở phân vị 90 là 43.9%. Và bản thân việc viết mã chỉ chiếm khoảng 14% một ngày làm việc của lập trình viên. Chi phí công cụ được nêu ở mức 200 đến 600 USD cho mỗi người-tháng, gồm phí thuê bao và phí token.

Là trung vị 7.76%, không phải gấp mấy lần. Khác biệt này mang tính quyết định. Nếu năng suất tăng gấp mấy lần thì 26 người-tháng của phương án C sẽ còn khoảng 8 người-tháng và bản thân cấu trúc so sánh sẽ thay đổi. Với 7.76% thì 26 người-tháng chỉ còn khoảng 24 người-tháng, vì 26 × 7.76% tương đương khoảng 2.0 người-tháng. Hơn nữa, phép tính này còn là một ước lượng khá dễ dãi vì đã giả định cùng tỷ lệ đó cũng có hiệu lực với cả phân tích yêu cầu, kiểm thử, chuyển đổi dữ liệu và khởi động chứ không riêng phần viết mã. Nếu viết mã chỉ chiếm 14% một ngày thì mức lan tỏa thực tế sẽ còn nhỏ hơn con số này.

Vì sao mô hình tính này không đưa hiệu quả của AI vào

Mô hình tính trong bài đặt hiệu quả của AI bằng không. Có hai lý do.

Lý do thứ nhất là chỉ chiết khấu cho một bên thì kết luận sẽ vỡ. Hãy thử xem độ nhạy. Giả sử 26 người-tháng ban đầu của phương án C giảm được 2 người-tháng, thì chi phí xây dựng ban đầu giảm 360,000 THB, và chi phí bảo trì bằng 12% của nó trong 5 năm cũng giảm 216,000 THB, tổng cộng giảm 576,000 THB. Trong khi đó lợi thế chi phí cố định của phương án A chỉ có 492,000 THB, nên chỉ chừng đó thôi là về mặt lý thuyết điểm cân bằng đã biến mất. Nhưng cùng hiệu quả AI ấy cũng tác động lên 11 người-tháng của phương án A và 22 người-tháng của phương án B. Một mô hình chỉ áp chiết khấu cho riêng C là phép tính đã định trước kết luận.

Lý do thứ hai là biết được hướng nhưng không đặt được biên độ. Điều có thể nói về hướng là AI tác động vào người-tháng chứ không tác động vào phí bản quyền. Phương án A và B ôm khoản bản quyền 6,000,000 THB trong 5 năm, và khoản này không giảm một baht nào dù hiệu suất phát triển có tăng đến đâu. Phương án C, nơi phần lớn tổng chi phí là người-tháng, trong 8,688,000 THB khi x = 0 thì phần không gắn với người-tháng chỉ là 1,200,000 THB hạ tầng, tức 13.8%, sẽ là bên hưởng lợi từ việc tăng hiệu suất. Vì vậy, nếu đưa AI vào thì điểm cân bằng sẽ dịch theo hướng thấp xuống, tức theo hướng có lợi cho phát triển riêng. Nói ngược lại, con số 1.4 người-tháng mỗi năm mà bài viết đưa ra là con số đã nghiêng về phía khắt khe với phát triển riêng.

Xin nói thêm, bản thân chi phí của công cụ lập trình AI, tức 200 đến 600 USD mỗi tháng cho một lập trình viên, cũng không được đưa vào phần tính bằng THB của bài viết, giống như các nguồn tính bằng USD khác. Tuy nhiên, biên độ giảm là thứ được suy ngược từ mức trung vị 7.76%, khác hẳn với những lập luận đặt tiền đề năng suất tăng gấp mấy lần. Trình tự đọc đúng không phải là vì có AI nên hãy tự làm, mà là vì x lớn nên tự làm, và AI chỉ đẩy thêm một chút cho phán đoán đó.

Ranh giới thực tế của việc tự làm hệ thống quản lý sản xuất trong nội bộ

Từ chuyện AI làm được, câu chuyện đôi khi tiến thêm một bước thành tự làm trong nội bộ. Việc tự phát triển hệ thống quản lý sản xuất trong nội bộ là hữu ích nếu giới hạn phạm vi. Xin nêu ranh giới bằng ba điểm.

Những thứ hợp với tự làm nội bộ. Nhập báo cáo hằng ngày, hiển thị tiến độ đơn giản, trích xuất dữ liệu từ hệ thống có sẵn để làm báo cáo, bảng thông tin treo ở hiện trường. Đây là những vùng không giữ bản gốc của dữ liệu, và hỏng thì tồn kho hay việc xuất hàng cũng không dừng.

Những thứ không hợp với tự làm nội bộ. Bản gốc của dữ liệu tồn kho, tính giá thành, hồ sơ truy xuất nguồn gốc cho khách hàng, liên kết cốt lõi với các hệ thống khác. Ở đây, trạng thái không còn ai sửa được ngay khi người phụ trách nghỉ việc sẽ trở thành rủi ro kinh doanh.

Tiêu chí phán đoán. Khi chương trình đó dừng thì việc xuất hàng ngày hôm sau có dừng theo không. Nếu có thì nó nằm ngoài phạm vi tự làm nội bộ. Không có gì bảo đảm người viết ra nó ba năm sau vẫn còn ở nhà máy này.

Về cảm nhận chi phí cho các ứng dụng nghiệp vụ có giới hạn phạm vi, chúng tôi bàn trong bài Phát triển ứng dụng nghiệp vụ cho nhà máy. Đó là một trục phán đoán khác với việc có nên phát triển riêng toàn bộ hệ thống quản lý sản xuất hay không.

Thời gian triển khai hệ thống quản lý sản xuất chênh nhau bao nhiêu

Sau tiền thì câu hỏi chắc chắn được đặt ra là thời gian. Phần này cũng được trình bày dưới dạng mô hình tính của chúng tôi.

Giả định. Số người làm song song phía nhà cung cấp bình quân 2.5 người, tỷ lệ làm việc thực tế 80% đã bao gồm cả thời gian chờ phía người dùng xác nhận và các đình trệ do hoàn cảnh hiện trường. Số tháng theo lịch được tính bằng người-tháng ÷ 2.5 ÷ 0.8.

Điểm đáng đọc là khoảng cách giữa B và C chỉ có 2.0 tháng. Phương án B, xét cả về mặt thời gian, cũng chỉ rút ngắn được tới mức cách phát triển riêng đúng hai tháng. Vậy mà khi x = 4, tổng chi phí 5 năm của nó lại cao hơn C tới 3,720,000 THB. Tính ra là trả 1,860,000 THB cho mỗi tháng để khởi động sớm hơn hai tháng. Ngay cả khi x = 1, lấy khoản chênh 2,640,000 THB chia cho hai tháng thì cũng là 1,320,000 THB mỗi tháng. Lý lẽ muốn khởi động sớm nên chỉnh sửa sâu cần được kiểm chứng bằng việc nó có xứng với số tiền này hay không.

Lý do thật sự khiến thời gian kéo dài

Bảng trên là con số suy ngược từ khối lượng công việc phía nhà cung cấp, nhưng trong các dự án thực tế, nguyên nhân chính khiến thời gian kéo dài lại không nằm ở phía nhà cung cấp. Có ba nguyên nhân.

Nguyên nhân thứ nhất là không quyết được. Trong lúc phân tích yêu cầu sẽ nảy ra những việc chưa ngã ngũ thuộc về phía nghiệp vụ, kiểu như biểu mẫu này ai duyệt, tồn kho này thuộc trách nhiệm của ai. Vì đó không phải chuyện của hệ thống nên nhà cung cấp chỉ còn cách chờ. Việc đặt tỷ lệ làm việc thực tế ở mức 80% trong mô hình trên chính là để tính cả thời gian chờ này. Ở các nhà máy Nhật, do phải chèn thêm bước xác nhận với trụ sở chính nên cũng có dự án tụt xuống mức 60 mấy phần trăm.

Nguyên nhân thứ hai là nghiệp vụ hiện hành chưa được tài liệu hóa. Những nghiệp vụ đang chạy bằng Excel và bằng trí nhớ của người kỳ cựu chỉ lần đầu được diễn đạt thành lời khi phân tích yêu cầu. Bản thân công việc này đôi khi mất vài tháng. Hơn nữa, nó phát sinh dù bạn chọn phương án A, B hay C. Không phải cứ dùng phần mềm đóng gói là được miễn.

Nguyên nhân thứ ba là chuyển đổi dữ liệu. Dữ liệu chủ về mặt hàng, dữ liệu chủ về đối tác, số dư tồn kho đầu kỳ. Việc rà soát trùng lặp và thiếu sót của dữ liệu hiện có là không tránh khỏi với bất kỳ phương án nào. Đó chính là lý do 26 người-tháng của phương án C đã bao gồm 6 người-tháng cho kiểm thử, chuyển đổi dữ liệu và khởi động.

Trong báo cáo ERP năm 2026 của Panorama Consulting Group mà Godlan dẫn lại, mức vượt tiến độ của các dự án ERP ngành sản xuất trung bình là 30%, so với trung bình ngành 25%. Cách làm thực tế là hãy thông báo trong nội bộ con số đã cộng thêm 30% vào số tháng ở bảng trên.

Những vấn đề bổ sung khi đặt hàng tại Thái Lan

Có những phần mà tiêu chuẩn phán đoán ở Nhật Bản không dùng nguyên xi được. Khi thuê ngoài phát triển phần mềm cho một công ty phát triển phần mềm tại Thái Lan, sẽ có thêm năm vấn đề.

Ngôn ngữ và tài liệu đặc tả

Ở nhà máy tại Thái Lan, ba ngôn ngữ vận hành cùng lúc là tiếng Nhật với trụ sở chính và nhân viên biệt phái, tiếng Anh với nhà cung cấp và cấp quản lý, tiếng Thái với công nhân hiện trường. Hãy quyết ngay từ đầu rằng tài liệu đặc tả viết bằng ngôn ngữ nào và màn hình hiển thị bằng ngôn ngữ nào. Nếu cứ tiến hành mà không quyết điểm này, bạn sẽ rơi vào trạng thái phân tích yêu cầu bằng tiếng Anh, màn hình bằng tiếng Thái, phê duyệt bằng tiếng Nhật, và mỗi lần thay đổi là phải dịch ba lần.

Ranh giới thực tế là chọn một ngôn ngữ duy nhất làm bản gốc của tài liệu đặc tả, các ngôn ngữ còn lại chỉ là bản dịch tham chiếu. Nếu giữ bản gốc bằng hai ngôn ngữ thì mỗi lần sửa đổi lại sinh ra sai lệch và không còn biết bên nào đúng. Nhãn trên màn hình thì khác, những màn hình mà hiện trường sử dụng bắt buộc phải có tiếng Thái. Nếu chọn phương án C thì hãy đưa việc đa ngôn ngữ vào ngay từ đầu khâu thiết kế. Gắn thêm về sau sẽ rất tốn kém.

Bộ máy phát triển và tính lưu động của nhân sự

Theo ERI SalaryExpert, thu nhập năm của lập trình viên tại Bangkok bình quân là 1,185,019 THB, với 1 đến 3 năm kinh nghiệm là 834,099 THB, và từ 8 năm trở lên là 1,362,287 THB. So với Nhật Bản thì đây là mức thấp hơn, nhưng ở góc độ giữ được người có kinh nghiệm thì lại có một vấn đề khác. Đó là tần suất nhảy việc cao hơn Nhật Bản, nên chuyện thay người phụ trách giữa chừng dự án dễ xảy ra.

Biện pháp được đặt ngay ở khâu hợp đồng. Quy trách nhiệm bàn giao khi thay người phụ trách về phía nhà cung cấp, định nghĩa tài liệu thiết kế và lịch sử thay đổi là sản phẩm bàn giao, và dập tắt sự phụ thuộc vào một nhân sự chủ chốt duy nhất ngay từ khâu sơ đồ tổ chức dự án. Hãy ưu tiên ba việc này trước cả việc thương lượng số tiền báo giá.

BOI và môi trường đầu tư

Với các pháp nhân đang hưởng ưu đãi của BOI, tức Ủy ban Đầu tư Thái Lan, cách xử lý tài sản phần mềm và điều kiện về nhà cung cấp khác nhau theo từng dự án. Hãy xác nhận với công ty kế toán về cách hạch toán chi phí phát triển và ảnh hưởng tới ưu đãi trước khi đặt hàng. Với phương án B và C là những phương án có số tiền lớn, để việc xác nhận này lại sau sẽ thành vấn đề vào cuối kỳ.

Bản thân môi trường đầu tư cũng đang dịch chuyển. Như JETRO đưa tin, hồ sơ xin đầu tư nộp lên BOI năm 2025 đạt mức cao nhất từ trước tới nay, khoảng 1,800 tỷ baht, và theo Bangkok Shuho thì tháng 6 năm 2026, chế độ rút ngắn thủ tục cấp phép cho lĩnh vực sản xuất tiên tiến mang tên Thailand Fast Pass đã khởi động, với tổng giá trị các dự án thuộc diện áp dụng vượt 700 tỷ baht. Đầu tư xung quanh tăng tốc cũng có nghĩa là danh mục sản phẩm và cơ cấu chi nhánh của chính bạn nhiều khả năng cũng dịch chuyển trong 5 năm. Điều này tác động theo hướng đẩy x lên cao.

Bàn giao khi rút lui hoặc khi đổi nhà cung cấp

Đây là chỗ bị bỏ sót nhiều nhất. Hãy ghi vào hợp đồng rằng khi hợp đồng với nhà cung cấp kết thúc, hoặc khi bạn đổi nhà cung cấp, thì những gì sẽ còn lại trong tay công ty bạn. Tối thiểu là bốn điểm sau.

1. Bản quyền tác giả hoặc quyền sử dụng mã nguồn. Ai là người nắm giữ, và có nhờ được công ty khác sửa đổi hay không.
2. Bàn giao tài liệu thiết kế, định nghĩa bảng dữ liệu và lịch sử thay đổi. Hãy ghi rõ định dạng bàn giao và trách nhiệm cập nhật.
3. Xuất dữ liệu. Phải xuất được toàn bộ dữ liệu đang vận hành ở một định dạng tiêu chuẩn. Nếu bị khóa trong một định dạng không xuất ra được thì việc chọn lại phương án trở thành bất khả thi trên thực tế.
4. Chủ sở hữu tài khoản và hạ tầng của môi trường vận hành thật. Hợp đồng đám mây đứng tên công ty bạn hay đứng tên nhà cung cấp sẽ quyết định độ khó của việc chuyển đổi.

Nếu chọn phương án C mà bốn điểm này không được bảo đảm thì tiền đề tự mình nắm giữ không thành lập. Bạn chỉ đơn giản là không phải trả phí bản quyền, đổi lại sự phụ thuộc vào nhà cung cấp bị đóng khung thành cấu trúc. Với phương án A và B, riêng phần đã chỉnh sửa thì vấn đề này vẫn còn nguyên.

Cái bẫy khi so sánh với mặt bằng giá ở Nhật Bản

Khi trình lên trụ sở chính, bạn có thể bị đem ra so với mặt bằng giá của Nhật Bản. Theo bản tổng hợp năm 2026 của c3index, chi phí xây dựng hệ thống lõi tại Nhật Bản trải rộng từ 5 triệu yên đến 300 triệu yên tùy quy mô. Việc bạn bị so với chỗ nào trong dải rộng đó sẽ khiến câu chuyện thay đổi tùy ý.

Để phép so sánh thành lập, hãy đặt cạnh nhau số người-tháng và cách phân chia vai trò chứ không phải số tiền. Con số 26 người-tháng không phụ thuộc vào đơn vị tiền. Nhà cung cấp Nhật Bản nhìn cùng phạm vi đó là bao nhiêu người-tháng, và trong số người-tháng ấy có bao gồm phân tích yêu cầu và chuyển đổi dữ liệu hay không. Khi đã khớp được điểm này thì mới đi tiếp sang phần bàn về chênh lệch đơn giá. Chỉ so đơn giá với nhau thì không ra kết luận, vì phạm vi bao gồm bên trong là khác nhau.

Câu hỏi thường gặp

Rốt cuộc phát triển hệ thống quản lý sản xuất riêng từ đầu và mua phần mềm đóng gói thì bên nào rẻ hơn

Điều đó do yêu cầu chỉnh sửa hằng năm sau khi hệ thống chạy thật, tức x, quyết định. Trong mô hình tính của bài viết, với nhà máy Nhật tại Thái Lan, 40 người dùng, 5 năm và đơn giá 180,000 THB mỗi người-tháng, nếu x = 1 người-tháng mỗi năm thì dùng phần mềm đóng gói theo chuẩn là rẻ nhất với 9,456,000 THB, còn phát triển riêng là 9,588,000 THB, cao hơn 132,000 THB, chênh lệch chỉ 1.4% so với A. Nếu x = 4 người-tháng mỗi năm thì phát triển riêng rẻ nhất với 12,288,000 THB, còn dùng phần mềm đóng gói theo chuẩn cao hơn 948,000 THB, tức nhiều hơn 7.7% so với phát triển riêng. Điểm cân bằng là khoảng 1.4 người-tháng mỗi năm, tương đương khoảng 28 người-ngày mỗi năm. Vì điểm cân bằng này phụ thuộc vào đơn giá người-tháng và số người dùng, hãy vẽ lại bằng số liệu của chính bạn.

Thời gian triển khai hệ thống quản lý sản xuất mất bao lâu

Với cùng giả định của mô hình, tức 2.5 người làm song song và tỷ lệ làm việc thực tế 80%, thì dùng phần mềm đóng gói theo chuẩn khoảng 5.5 tháng, phần mềm đóng gói chỉnh sửa sâu khoảng 11.0 tháng, phát triển riêng khoảng 13.0 tháng. Tuy nhiên, trong báo cáo ERP năm 2026 của Panorama Consulting Group mà Godlan dẫn lại, mức vượt tiến độ của các dự án ERP ngành sản xuất trung bình là 30%, so với trung bình ngành 25%. Hãy cộng thêm 30% dự phòng vào con số thời gian mà bạn thông báo trong nội bộ. Nguyên nhân chính khiến thời gian kéo dài không phải tốc độ làm việc của nhà cung cấp, mà là ba thứ gồm những việc chưa ngã ngũ phía nghiệp vụ, nghiệp vụ hiện hành chưa được tài liệu hóa, và chuyển đổi dữ liệu.

Tùy chỉnh phần mềm đóng gói đến mức nào thì còn nằm trong phạm vi chấp nhận được

Về mặt tiền, đó là phạm vi mà chỉnh sửa ban đầu còn nằm trong 3 người-tháng, tức phương án A của bài viết. Nếu vượt qua mức đó và đi tới 14 người-tháng, tức phương án B, thì tổng chi phí 5 năm sẽ cao hơn phương án dùng phần mềm đóng gói theo chuẩn 2,772,000 THB, và cao hơn phát triển riêng 2,640,000 THB khi x = 1 và 3,720,000 THB khi x = 4. Về mặt tư duy, bản tổng hợp của Panorama Consulting Group do Godlan dẫn lại là tài liệu đáng tham khảo. So với chỉnh sửa sâu, việc thích ứng ở mức vừa phải trong khuôn khổ triết lý thiết kế của sản phẩm cho kết quả tốt hơn, và 45% doanh nghiệp đạt kết quả tốt nhất bằng cách này. Thời điểm bạn cần tới những chỉnh sửa vượt ra ngoài triết lý thiết kế của sản phẩm chính là tín hiệu để xem xét lại việc chọn phần mềm đóng gói khác hay tự nắm luôn cả phần nền.

Có tự làm hệ thống quản lý sản xuất trong nội bộ được không

Nếu giới hạn phạm vi thì được. Nhập báo cáo hằng ngày, hiển thị tiến độ đơn giản, trích xuất dữ liệu từ hệ thống có sẵn để làm báo cáo và bảng thông tin treo ở hiện trường là những thứ hợp với tự làm nội bộ. Ngược lại, bản gốc của dữ liệu tồn kho, tính giá thành, hồ sơ truy xuất nguồn gốc cho khách hàng và liên kết cốt lõi thì không hợp. Tiêu chí phán đoán là khi chương trình đó dừng thì việc xuất hàng ngày hôm sau có dừng theo không. Nếu có thì nó nằm ngoài phạm vi tự làm nội bộ. Với cả phương án tự làm dựa trên trợ lý lập trình AI, khảo sát hơn 400 công ty trong 14 tháng của DX cho thấy mức cải thiện trung vị của thông lượng pull request là 7.76%, và phần lớn doanh nghiệp nằm trong khoảng 5 đến 15%. Tốc độ làm ra có tăng lên đôi chút, nhưng bài toán ai sẽ sửa sau khi người làm ra nó nghỉ việc thì không thay đổi.

Khi thuê ngoài cho công ty phát triển phần mềm tại Thái Lan thì hợp đồng cần ghi những gì

Tối thiểu là bốn điểm. Bản quyền tác giả hoặc quyền sử dụng mã nguồn, tức có nhờ được công ty khác sửa đổi hay không. Định dạng bàn giao và trách nhiệm cập nhật của tài liệu thiết kế, định nghĩa bảng dữ liệu và lịch sử thay đổi. Khả năng xuất toàn bộ dữ liệu đang vận hành ở định dạng tiêu chuẩn. Và tên chủ tài khoản của môi trường vận hành thật cùng tên chủ hợp đồng đám mây. Ngoài ra, hãy đưa vào điều khoản quy trách nhiệm bàn giao khi thay người phụ trách về phía nhà cung cấp. Thị trường lập trình viên tại Bangkok có tính lưu động nhân sự cao nên việc thay người giữa chừng dự án không hiếm. Chốt trước năm hạng mục này sẽ làm giảm tổng chi tiêu cuối cùng nhiều hơn là thương lượng số tiền báo giá.

Hiện chúng tôi đang chạy bằng Excel, việc đầu tiên nên làm là gì

Không phải xin tài liệu giới thiệu sản phẩm, mà là đếm lịch sử thay đổi của 24 tháng đã qua. Hãy thu thập phiếu yêu cầu, email gửi nhà cung cấp, lịch sử sửa đổi file Excel và ngày cập nhật của các macro, chia chúng thành nhóm quy tắc nghiệp vụ đã thay đổi và nhóm chỉ sửa cách dùng, làm tròn nhóm thứ nhất thành ba mức 0.2, 0.5 và 1.0 người-tháng rồi cộng tổng, sau đó chia cho 24 và nhân với 12. Đó chính là x của bạn. Cộng thêm những thay đổi đã chắc chắn trong hai năm tới rồi thế vào công thức trong bài, bạn sẽ có câu trả lời bằng tiền cho việc phần mềm đóng gói hay phát triển riêng rẻ hơn với nhà máy mình. Công việc này mất khoảng ba ngày với hai người, và một tuần nếu tài liệu nằm rải rác. Nó đáng làm trước cả việc so sánh sản phẩm.

Kết luận

Ranh giới giữa phát triển hệ thống quản lý sản xuất riêng từ đầu và mua phần mềm đóng gói không nằm ở danh sách chức năng. Nó chỉ nằm ở một điểm là x, tức mỗi năm quy tắc nghiệp vụ thay đổi bao nhiêu người-tháng sau khi hệ thống chạy thật.

Lựa chọn không phải hai mà là ba, và đắt nhất là phương án ở giữa. Phương án B, chỉnh sửa sâu phần mềm đóng gói, trở thành hình thức phải nộp hai khoản thuế mỗi năm là phí bản quyền và công làm lại phần chỉnh sửa khi nâng cấp phiên bản, khiến tổng chi phí 5 năm luôn cao hơn phương án dùng phần mềm đóng gói theo chuẩn 2,772,000 THB, và cao hơn phát triển riêng 2,640,000 THB khi x = 1 và 3,720,000 THB khi x = 4. Vì hệ số góc của hai bên bằng nhau nên phần cộng thêm này không được thu hồi dù x có lớn đến đâu.

Kết luận về tiền rút gọn thành một công thức. Phương án A(x) = 8,196,000 + 1,260,000x, phương án C(x) = 8,688,000 + 900,000x. Hai bên bằng nhau tại x ≈ 1.37, tức khoảng 1.4 người-tháng mỗi năm, tương đương khoảng 28 người-ngày mỗi năm, và khi đó tổng chi phí 5 năm của cả hai đều bằng khoảng 9,918,000 THB. Nếu x = 1 thì phần mềm đóng gói rẻ hơn 132,000 THB, tức chỉ chênh 1.4% so với A nên trên thực tế là ngang nhau. Nếu x = 4 thì phát triển riêng rẻ hơn 948,000 THB, tức A nhiều hơn 7.7% so với C. Hãy thay đơn giá người-tháng và số người dùng bằng số liệu của chính bạn. Đơn giá giảm thì phát triển riêng có lợi, số người dùng tăng thì phí bản quyền tích lũy phát huy tác dụng và điểm cân bằng hạ xuống.

Câu làm bằng AI thì rẻ đúng về hướng nhưng sai về biên độ. Trong khảo sát của DX, mức cải thiện trung vị của thông lượng pull request là 7.76%, không phải gấp mấy lần. Vì mô hình tính trong bài đặt hiệu quả của AI bằng không nên con số 1.4 người-tháng mỗi năm đã nghiêng về phía khắt khe với phát triển riêng. Dù vậy, thứ làm dịch chuyển phán đoán vẫn là x chứ không phải AI.

Và việc đầu tiên nên làm không phải xin tài liệu giới thiệu sản phẩm, mà là đếm lịch sử thay đổi của 24 tháng đã qua. Công việc này kết thúc trong vài ngày, và kết quả của nó sẽ làm căn cứ cho một quyết định ở quy mô gần 10 triệu THB trong 5 năm.

Bạn đang ở giai đoạn chưa chọn phương án nào cũng không sao. Chúng tôi có thể hỗ trợ ngay từ bước cùng bạn xếp các phiếu yêu cầu và email gửi nhà cung cấp đang có trong tay ra để đếm xem x của nhà máy bạn là bao nhiêu. Chỉ riêng việc thay lại đơn giá người-tháng và số người dùng của bạn vào công thức của ba phương án rồi xem thứ tự đổi chỗ ở đâu cũng đã đủ làm thay đổi mặt bằng tranh luận trong nội bộ. Mọi trao đổi xin gửi qua biểu mẫu liên hệ.

Tài liệu tham khảo

• ERP Implementation Failure Statistics, Godlan dẫn lại 2026 ERP Report của Panorama Consulting Group
• AI Coding Assistant Pricing and Impact, DX tại getdx.com
• Custom Software Development Cost 2026, LI Solutions
• Báo cáo tổng kết của Ủy ban hiện đại hóa hệ thống cũ, ngày 28 tháng 5 năm 2025, METI và IPA
• Báo cáo phân tích khu vực về thay đổi cơ cấu của ngành sản xuất Thái Lan, JETRO
• Bài viết liên quan đến Thailand Fast Pass, Bangkok Shuho
• Software Developer Salary in Bangkok, Thailand, ERI SalaryExpert
• Mặt bằng chi phí xây dựng hệ thống lõi, c3index

Toàn bộ số tiền trong bài viết là mô hình tính dựa trên các giả định do chúng tôi tạm đặt, không phải báo giá cho một dự án cụ thể. Nếu thay đổi các giả định, gồm đơn giá 180,000 THB mỗi người-tháng, 40 người dùng, 5 năm, phí bản quyền 2,500 THB cho mỗi người dùng mỗi tháng, hạ tầng 240,000 THB mỗi năm, bảo trì 12% mỗi năm và tỷ lệ làm lại khi nâng cấp 40%, thì kết luận cũng thay đổi. Các nhóm sản phẩm và các khảo sát được nhắc tới trong bài đều thuộc về các công ty và tổ chức tương ứng, không phải sản phẩm của chúng tôi. Các số liệu dựa trên nội dung đã được công bố tính đến tháng 8 năm 2026.