Triển khai hệ thống small start — chia nhỏ dự án theo quan hệ giữa quy mô và QCD

Triển khai hệ thống theo hướng small start thường bị nhắc tới như một phương án thỏa hiệp dành cho lúc thiếu ngân sách. Nhưng khi nhìn vào dữ liệu sơ cấp, đánh giá đó bị đảo ngược. Dự án có quy mô càng lớn thì tỷ lệ bị xếp vào nhóm không đạt ở cả chất lượng, ngân sách lẫn tiến độ càng cao. Nói cách khác, chính quyết định chia dự án ở độ lớn nào mới là hoạt động quản trị rủi ro lớn nhất khi đổi mới hệ thống lõi của nhà máy. Bài viết này trình bày các con số thực tế từ những khảo sát đã công bố, rồi sắp xếp lại hai câu hỏi, chia ở đâu và tuyệt đối không được chia ở đâu.

Chia nhỏ không phải là thỏa hiệp — kết luận trước

Khi các nhà máy Nhật Bản tại Thái Lan và ASEAN bàn tới việc đổi mới hệ thống quản lý sản xuất, phương án xuất hiện đầu tiên thường là làm một lần cho xong. Từ đơn hàng tới xuất hàng, kèm tồn kho, giá thành và cả hồ sơ chất lượng, tất cả được thay thế cùng lúc. Về mặt lý lẽ thì nghe hợp lý, vì triển khai theo giai đoạn sẽ khiến hệ thống cũ và mới cùng tồn tại trong suốt thời gian chuyển đổi, và phần công sức đó là có thật.

Vấn đề là khi xem một khảo sát tổng hợp các dự án đã hoàn thành theo từng nhóm quy mô, trực giác nói trên bị chính các con số phản bác. Chương 7 về phát triển hệ thống trong báo cáo Corporate IT Trend Survey Report 2026 của Japan Users Association of Information Systems (JUAS), tương ứng kỳ khảo sát năm tài khóa 2025, viết về mức độ tuân thủ QCD, tức chất lượng, chi phí và tiến độ, theo quy mô dự án như sau.

Tỷ lệ không đạt ở nhóm quy mô dự án dưới 10 người-tháng đều thấp hơn 10,0% cho cả ba chỉ tiêu QCD, trong khi ở nhóm từ 500 người-tháng trở lên thì cao, với 29,6% ở chất lượng, 42,2% ở ngân sách và 47,8% ở tiến độ.

Báo cáo còn ghi rõ rằng ở cả ba chỉ tiêu QCD, quy mô dự án càng nhỏ thì tỷ lệ tốt càng cao, và quy mô dự án càng lớn thì tỷ lệ tốt càng thấp. Nếu chỉ đặt hai đầu cực cạnh nhau, bức tranh là thế này.

Cách đọc bảng này cần thận trọng. Các con số về chất lượng và ngân sách lấy từ một hình chia quy mô thành năm nhóm, còn con số 47,8% của tiến độ lấy từ một hình khác chia quy mô thành ba nhóm. Trong bảng ba nhóm không tồn tại nhóm dưới 10 người-tháng, nên chỉ có thể đọc ra điều đó từ câu tổng kết trong phần lời của báo cáo. Vì vậy riêng ô dưới bên trái của bảng trên được đặt nguyên phần mô tả bằng lời chứ không phải một con số.

Dù vậy, thông điệp vẫn rất rõ. Nếu cố làm một lần cả khối cỡ 500 người-tháng, tỷ lệ dự án vượt ngân sách vào khoảng bốn phần mười, tỷ lệ trễ tiến độ vào khoảng năm phần mười. Đây không phải ngoại lệ có thể né được nếu làm khéo, mà là hình ảnh trung bình rút ra từ việc tổng hợp rất nhiều dự án. Ngược lại, nếu chia thành các phần dưới 10 người-tháng thì tỷ lệ không đạt ở cả ba chỉ tiêu QCD đều dưới một phần mười. Chia nhỏ không phải là thừa nhận mình thiếu năng lực, mà là lựa chọn tự đặt mình vào phía có lợi về mặt thống kê.

Bài viết này xuyên suốt chỉ một luận điểm. Chia nhỏ không phải là thỏa hiệp. Giữa quy mô dự án và tỷ lệ không đạt QCD tồn tại một quan hệ có dữ liệu sơ cấp chứng minh, và chính cách chia mới là hoạt động quản trị rủi ro lớn nhất.

Dữ liệu nói gì về quan hệ giữa quy mô dự án và QCD

Trước hết, xin đặt ra đầy đủ các con số làm căn cứ, không lược bớt. Nguồn là hình 7-1-4 mang tên mức độ tuân thủ QCD trong phát triển hệ thống theo quy mô dự án, thuộc báo cáo Corporate IT Trend Survey Report 2026 của JUAS, kỳ khảo sát năm tài khóa 2025. Đơn vị đều là %, còn n là số lượng dự án.

Mức độ tuân thủ về chất lượng

Tỷ lệ không hài lòng về chất lượng tăng đều theo quy mô, từ 5,4% lên 29,6%. Nếu thực sự lấy hai đầu cực chia cho nhau thì 29,6 chia 5,4 bằng 5,48 lần. Có người sẽ muốn nói tròn thành sáu lần, nhưng kết quả phép chia là 5,48 chứ không phải sáu. Bài viết này giữ nguyên 5,48 lần và không làm tròn.

Tiếp theo là ngân sách. Ta xem phần ngân sách của cùng hình đó.

Mức độ tuân thủ về ngân sách

Tỷ số hai đầu cực của mức vượt ngân sách là 42,2 chia 6,0 bằng 7,03 lần. Độ dốc này gắt hơn mức 5,48 lần của chất lượng, tức là ảnh hưởng của quy mô thể hiện mạnh hơn. Trong thực tế ra quyết định đầu tư của nhà máy, chênh lệch này mới là thứ gây đau. Sự không hài lòng về chất lượng còn có chỗ để khỏa lấp bằng cách vận hành, nhưng vượt ngân sách thì dẫn thẳng tới việc phải làm lại hồ sơ xin phê duyệt.

Cũng xin lưu ý, đừng tự tạo ra tỷ số giữa các nhóm ở giữa. Ví dụ phép tính mức vượt ngân sách 19,6% của nhóm từ 50 đến dưới 100 người-tháng gấp bao nhiêu lần mức 6,0% của nhóm dưới 10 người-tháng là khả thi về số học, nhưng thứ mà báo cáo gán ý nghĩa là tính đơn điệu, tức quy mô càng lớn thì tỷ lệ không đạt càng tăng, chứ không phải từng bội số riêng lẻ. Trong bài viết này, chỉ hai tỷ số nói trên được dùng như tỷ số.

Với tiến độ, cách chia nhóm thay đổi. Hình 7-1-3 của cùng báo cáo, mang tên mức độ tuân thủ tiến độ trong phát triển hệ thống theo quy mô dự án và theo năm, số liệu năm tài khóa 2025, chia thành ba nhóm.

Mức độ tuân thủ về tiến độ (ba nhóm)

Ở đây cần đối chiếu số lượng nhóm. Bảng chất lượng và ngân sách có năm nhóm, bảng tiến độ có ba nhóm. Vì số nhóm khác nhau nên không được đặt ngang hàng một dòng của bảng năm nhóm với một dòng của bảng ba nhóm. Có thể kiểm chứng bằng số lượng. Các phép cộng dưới đây đều do bài viết này tự cộng các giá trị n trong bảng của báo cáo. Cộng n của bảng chất lượng được 688 cộng 562 cộng 405 cộng 319 cộng 223 bằng 2.197 dự án, cộng n của bảng tiến độ được 1.647 cộng 317 cộng 226 bằng 2.190 dự án, lệch nhau 7 dự án. Ngoài ra, ba nhóm nhỏ nhất của bảng chất lượng, tức 688 cộng 562 cộng 405 bằng 1.655 dự án, cũng lệch 8 dự án so với nhóm dưới 100 người-tháng của bảng tiến độ là 1.647 dự án. Điều đó có nghĩa là tổng thể được tổng hợp không hoàn toàn trùng nhau, và không thể nối hai bảng lại để suy ra tỷ lệ trễ tiến độ của nhóm dưới 10 người-tháng.

Cũng cần nắm các tiền đề khi đọc những con số này. Thứ nhất, đây là khảo sát nhắm vào các doanh nghiệp người dùng trong nội địa Nhật Bản, không phải là tổng hợp các dự án của pháp nhân tại Thái Lan. Khi áp vào nhà máy Nhật Bản ở Thái Lan, nên dùng như tham chiếu về xu hướng chứ không thể lấy nguyên làm giá trị dự báo cho công ty mình. Thứ hai, n là số lượng dự án chứ không phải số doanh nghiệp. Toàn bộ khảo sát có 957 công ty trả lời hợp lệ, nhưng vì một công ty có thể trả lời cho nhiều dự án nên đừng lẫn lộn giá trị n trong bảng với con số 957 công ty. Thứ ba, từ kỳ khảo sát năm tài khóa 2025, các lựa chọn trả lời hài lòng vượt kỳ vọng, hoàn thành dưới mức dự kiến và hoàn thành sớm hơn dự kiến mới được bổ sung. Chính báo cáo đã lưu ý rằng phía cải thiện đã được tăng thêm một bậc lựa chọn và cần tính đến ảnh hưởng của việc đó, nên không thể đem so sánh đơn giản mức cải thiện so với năm trước. Thứ mà bài viết này sử dụng chỉ là so sánh giữa các nhóm quy mô trong cùng một kỳ khảo sát.

Việc tổng các dòng có chỗ không bằng đúng 100,0% là do làm tròn. Cũng không nên lấy các giá trị trong bảng cộng trừ trực tiếp với nhau để chế ra chỉ số mới.

Vì sao dự án lớn dễ vỡ — yêu cầu nghiệp vụ không tới được đặc tả

Ta đã biết quy mô có quan hệ với tỷ lệ không đạt QCD. Vậy vì sao lớn thì dễ vỡ. Một hình khác trong cùng báo cáo gợi ý lý do nằm ở phía trước đó. Đó là hình 7-2-7, mang tên các vấn đề trong việc đẩy mạnh tự làm nội bộ khi phát triển hệ thống, câu hỏi nhiều lựa chọn, năm tài khóa 2025, n bằng 953.

Bảng này là câu hỏi nhiều lựa chọn nên cộng dọc lại không có ý nghĩa gì. Tổng sẽ vượt quá 100%. Thứ cần đọc là thứ hạng và mức độ.

Ba mục đầu nói về lượng nhân lực, chất nhân lực và nhân lực quản lý dự án, tức chuyện đầu người và độ thuần thục. Nhưng trong mạch của bài viết này, nặng ký nhất là mục thứ tư và thứ năm. Hiểu biết chưa đủ về nghiệp vụ hiện hành chiếm 38,2%, còn thiếu năng lực hoạch định hệ thống, tức không chuyển được yêu cầu kinh doanh thành đặc tả hệ thống, chiếm 34,5%. Nghĩa là hơn một phần ba doanh nghiệp nêu ra chính chỗ vấp trong việc dịch nghiệp vụ của mình thành đặc tả, khi nói về các vấn đề của tự làm nội bộ.

Chỗ này nối thẳng với vấn đề quy mô. Dự án càng lớn thì quãng đường từ lúc chốt yêu cầu đến lúc màn hình đầu tiên chạy được càng dài. Với cỡ 500 người-tháng, cái mong muốn vận hành như thế này ghi trong biên bản họp định nghĩa yêu cầu phải mất nhiều tháng mới thành hình để hiện trường thử được. Trong khoảng thời gian đó, không có cách nào xác nhận yêu cầu đã được dịch đúng sang đặc tả hay chưa. Lỗi dịch sẽ lộ ra ở giai đoạn kiểm thử, tệ nhất là sau khi đã vận hành chính thức. Lúc muốn sửa thì các chức năng xung quanh đã chồng lên nhau, nên phạm vi ảnh hưởng của việc sửa rất rộng. Đây chính là con đường phát sinh chủ yếu của vượt ngân sách và trễ tiến độ.

Ngược lại, nếu chia thành các phần dưới 10 người-tháng thì quãng đường từ lúc viết yêu cầu đến lúc nhìn thấy thứ chạy được rất ngắn. Lỗi dịch được phát hiện sớm, khi phạm vi ảnh hưởng còn nhỏ. Bản chất của small start không phải là giảm khối lượng phải làm, mà là tạo ra cơ chế phát hiện sớm lỗi dịch. Tổng khối lượng phải làm cuối cùng có thể vẫn như cũ. Khác nhau ở quãng đường mà ta đi tiếp trong khi vẫn đang mang lỗi.

Trong phần tổng kết của cùng chương, báo cáo cũng nói rằng thiếu hụt kỹ năng của nhân viên và của nhà cung cấp đang trở nên rõ rệt hơn với tư cách yếu tố làm xấu QCD. Kỹ năng không thể nâng lên trong ngắn hạn. Nếu phải thay đổi thiết kế trên tiền đề có những thứ không nâng lên được, thì nước đi khả dĩ là giảm độ phức tạp phải xử lý trong một lần.

Thêm một điểm nữa, chuyện thiếu về lượng nhân lực không chỉ có trong khảo sát nội địa. Trong khảo sát DX Trend Survey năm tài khóa 2025 của Information-technology Promotion Agency, Japan (IPA), với 1.799 công ty thu về phiếu và thời gian khảo sát từ 17/4/2026 đến 12/6/2026, tổng của hai mức hơi thiếu và thiếu nghiêm trọng đối với lượng nhân lực thúc đẩy DX là 85,5%. Tuy nhiên đây là một khảo sát khác với JUAS, khác cả chủ thể khảo sát, thời điểm lẫn nhóm doanh nghiệp được hỏi. Không thể đặt cạnh các con số của JUAS để tính tỷ lệ, cũng không thể bàn lớn nhỏ trên cùng một thước đo. Ở đây nó chỉ được tham chiếu như bối cảnh cho thấy nhận thức về việc thiếu người đang được chia sẻ rộng rãi.

Chia ở đâu — cách xác định đơn vị chia

Khi đã quyết chia nhỏ, việc tiếp theo là chia thế nào. Với hệ thống nghiệp vụ của nhà máy, các cách chia thực sự vận hành được có thể quy về khoảng bốn kiểu.

Trong số đó, ít thất bại nhất là chia theo công đoạn và chia theo biểu mẫu. Cả hai đều rõ ràng về việc ai ở hiện trường sẽ dùng, và việc vận hành thành công hay không có thể được phán định bằng cảm nhận thực tế của hiện trường. Ngược lại, chia thuần theo thời gian là nguy hiểm. Khi cắt bớt chức năng cho vừa khung ba tháng, có lúc thứ bị cắt lại là thứ không được phép cắt. Thời gian nên đặt như một ràng buộc, còn đơn vị chia thì để phía nghiệp vụ quyết định, đó mới là đúng thứ tự.

Trường hợp chia theo cơ sở cần thận trọng thêm một bậc nữa. Khi cách vận hành đang lệch nhau giữa nhiều nhà máy tại Thái Lan, trong chênh lệch đó có lẫn hai loại, loại tất yếu phải khác vì sản phẩm và thiết bị khác nhau, và loại chỉ đơn giản là trôi dần mỗi lần đổi người phụ trách. Loại thứ nhất thì giữ, loại thứ hai thì thống nhất ngay ở đợt 1. Nếu triển khai ra các cơ sở mà không làm việc phân loại này, số lượng tùy biến riêng cho từng cơ sở sẽ tăng lên, và rốt cuộc lại phải gánh đúng độ phức tạp của một dự án gộp lớn.

Cách tiến hành cụ thể khi chia theo biểu mẫu đã được tổng hợp trong bài viết về triển khai biểu mẫu điện tử. Về thứ tự thay thế khi thoát khỏi vận hành bằng giấy, xin tham khảo cách thoát vận hành giấy tờ tại nhà máy bằng hệ thống biểu mẫu điện tử. Còn về phạm vi đối tượng và mức chi phí khi chia theo công đoạn, bài chi phí và cách chọn hệ thống quản lý công đoạn sẽ là tài liệu tham khảo tốt.

Khi đã chốt đơn vị chia, nhất định phải viết đồng thời phần sẽ bổ sung gì từ đợt 2 trở đi. Hãy kiểm tra xem trong tài liệu thiết kế của đợt 1 đã liệt kê được, dù chỉ là tên gọi, các trường dữ liệu, màn hình và đầu mối kết nối sẽ thêm ở đợt 2 hay chưa. Nếu để trống chỗ này mà làm đợt 1, thì đợt 2 sẽ phải làm lại từ phần nền. Đây chính là cửa ngõ dẫn tới kiểu thất bại không có thiết kế nhân rộng được nói tới ở phần sau.

Những chỗ không được chia — dữ liệu chủ, cấp phát số, phân quyền

Đây là phần bài viết này muốn truyền đạt nhất. Có rất nhiều bài viết khuyến khích small start, nhưng không nhiều bài nêu rõ những chỗ không được chia. Và trong thực tế, sự cố thường xảy ra đúng ở ba chỗ này.

Hành động chia nhỏ là chia tách chức năng. Nhưng nếu chia luôn cả phần nền dùng chung nằm phía sau chức năng, thì từ đợt 2 trở đi chắc chắn sẽ phát sinh quản lý trùng lặp. Phần nền ở đây cụ thể là ba thứ, dữ liệu chủ, cấp phát số và phân quyền.

Không được chia dữ liệu chủ

Dữ liệu chủ mặt hàng, dữ liệu chủ đối tác, dữ liệu chủ công đoạn, dữ liệu chủ thiết bị, dữ liệu chủ đơn vị đo. Nếu tạo những thứ này theo kiểu chỉ phần dùng lần này, tức bám vào phạm vi của đợt 1, thì đợt 2 chắc chắn sẽ sinh ra một bộ dữ liệu chủ khác. Kiểu hỏng thường gặp là như sau.

Vì đợt 1 chỉ lấy kiểm tra nhập kho làm đối tượng, nên dữ liệu chủ mặt hàng chỉ đăng ký hàng mua vào. Sang đợt 2 phải xử lý việc ghi nhận lắp ráp, thế là cần đăng ký cả hàng tự sản xuất. Nhưng dữ liệu chủ mặt hàng của đợt 1 không có các trường để mang hàng tự sản xuất, tức công đoạn, thời gian tiêu chuẩn và cấu thành, nên người ta tạo một bộ dữ liệu chủ khác cho đợt 2. Ngay thời điểm đó, cùng một khái niệm mặt hàng lại tồn tại hai sổ cái. Từ đó về sau, mỗi lần thêm hoặc sửa mặt hàng đều phải sửa ở hai nơi, và chắc chắn sẽ có mặt hàng chỉ được sửa ở một bên.

Cách né tránh rất đơn giản. Riêng phần thiết kế trường dữ liệu của dữ liệu chủ thì phải làm theo phạm vi của hình hài cuối cùng, chứ không theo phạm vi của đợt 1. Còn phần thực sự nhập giá trị vào thì chỉ cần nhập phần dùng ở đợt 1 là đủ. Thứ tự đúng là tạo cái vỏ theo hình hài cuối cùng rồi lấp ruột dần theo từng giai đoạn. Công sức tạo cái vỏ là nhỏ nếu đem so với công sức làm chức năng. Tiết kiệm ở chỗ này thì về sau sẽ phải trả lại gấp nhiều lần.

Thêm một điểm nữa, hệ thống mã của dữ liệu chủ cũng phải chốt dứt điểm ngay ở đợt 1. Số ký tự và ý nghĩa của mã mặt hàng, mã cơ sở, mã công đoạn. Sửa những thứ này về sau sẽ kéo theo việc chuyển đổi toàn bộ dữ liệu hiện có. Thời điểm rẻ nhất để cố định chúng là lúc dữ liệu còn ít, tức ngay tại đợt 1.

Không được chia việc cấp phát số

Số lệnh sản xuất, số lô, số chứng từ, số chỉ thị, số phiếu kiểm tra. Nếu chia tách quy tắc cấp phát số và chủ thể cấp phát số, sẽ phát sinh trùng số hoặc nhảy số.

Một ví dụ điển hình. Đợt 1 lấy đóng gói xuất hàng làm đối tượng và để hệ thống mới cấp phát số kiện đóng gói. Đợt 2 phải xử lý việc chuyển kho, nhưng vì tệp Excel hiện có cũng đang đánh số theo cùng một hệ mã số, nên cả hai bên cùng phát hành một số giống nhau. Ở kho sẽ tồn tại hai nhãn mang cùng một số, và mối tương ứng giữa vật thật với dữ liệu không còn giữ được.

Điều phiền phức của sự cố này là nó bị phát hiện muộn. Trùng số chỉ lộ ra khi tình cờ hai chứng từ cùng số được xử lý đồng thời. Nó thường xuất hiện dưới dạng nửa năm sau, lúc kiểm kê, mới biết là không khớp. Đến lúc đó thì chỉ còn cách dùng người truy ngược xem dữ liệu nào mới đúng.

Cấp phát số nhất định phải có một nguồn phát hành duy nhất. Nếu hệ thống của đợt 1 là nguồn phát hành, thì hệ mã số của các loại số sẽ dùng từ đợt 2 trở đi cũng phải nằm trong đó. Cả những loại số của các mảng chưa hệ thống hóa cũng nên đặt trước chỗ cho hệ mã số của chúng. Việc đặt trước này chỉ tốn một trang trong tài liệu thiết kế.

Ở những nhà máy coi trọng truy xuất nguồn gốc, điểm này mang ý nghĩa đặc biệt nặng. Nếu tính liên tục của số lô bị đứt, thì bản thân việc điều tra truy ngược không còn thực hiện được. Chia nhỏ và truy xuất nguồn gốc không mâu thuẫn với nhau, nhưng điều đó chỉ đúng khi việc cấp phát số không bị chia.

Không được chia phân quyền

Đăng ký người dùng, cây tổ chức, luồng phê duyệt, phạm vi được xem. Nếu mỗi đợt giữ những thứ này một cách độc lập, tài khoản của người đã nghỉ việc sẽ còn lại.

Ở các cơ sở tại Thái Lan, vấn đề này còn nghiêm trọng hơn so với ở Nhật Bản. Trong môi trường có sự thay đổi nhân sự người bản địa, nếu sổ người dùng bị tách rời theo từng hệ thống thì chắc chắn sẽ sinh ra tình trạng đã xóa ở hệ thống A nhưng vẫn còn ở hệ thống B. Tình huống một tài khoản có quyền nhập kết quả sản xuất vẫn sống dù chủ nhân đã nghỉ việc là thứ rất khó giải thích, cả khi bị kiểm toán lẫn dưới góc nhìn đảm bảo chất lượng.

Người dùng và phân quyền phải được đặt ở một chỗ duy nhất dùng chung toàn công ty, ngay từ thời điểm đợt 1. Nếu đã có nền tảng xác thực sẵn có thì gom về đó. Nếu chưa có thì làm ở đợt 1, và toàn bộ các đợt về sau đều tham chiếu tới đó. Nhìn riêng đợt 1 thì trông giống một khoản đầu tư thừa, nhưng nhìn tới đợt thứ ba thì chắc chắn là rẻ hơn.

Cái nào được chia, cái nào không

Sắp xếp lại thì được như sau.

Nửa dưới của bảng này chính là cái có thể gọi là đợt 0. Trước khi làm chức năng của đợt 1, hãy đặt nó xuống trước với tư cách phần nền dùng chung. Về công sức thì nó chỉ chiếm một phần nhỏ của tổng thể, nhưng nếu chạy mà không đặt nó xuống thì công sức của đợt 2 và đợt 3 sẽ phình ra. Kiểu đã chia nhỏ rồi mà vẫn khổ y như làm gộp lớn, phần lớn rơi vào đúng mô hình này.

Về cấu trúc chi phí khi lấy việc tích hợp với hệ thống lõi làm tiền đề, bài chi phí phát triển hệ thống nghiệp vụ và cách nghĩ về tích hợp ERP phân rã theo từng lớp. Có thể dùng bài đó để xác nhận phần tương ứng với đợt 0 nằm ở lớp nào.

Vì sao việc chia nhỏ đặc biệt hiệu quả ở các cơ sở tại Thái Lan

Tới đây vẫn là lập luận chung dựa trên dữ liệu khảo sát trong nội địa Nhật Bản. Với các nhà máy Nhật Bản tại Thái Lan và ASEAN, còn có thêm những hoàn cảnh làm cho việc chia nhỏ càng có lợi.

Thứ nhất, dự án dài thì vắt qua nhiều đợt thay người. Theo bài Thailand Job Market 2026 Outlook của RECRUITdee, ngân sách tăng lương trung bình của năm 2026 vào khoảng 4,7%, còn ở các lĩnh vực đòi hỏi kỹ năng cao thì mức đãi ngộ tăng khi nhảy việc là từ 15 đến 30%. Hai con số này không cùng đơn vị đo. 4,7% là mức tăng theo năm khi vẫn tại vị, còn 15 đến 30% là mức nhảy vọt nhất thời khi đổi chỗ làm. Chúng không ở trong quan hệ có thể đem chia hay cộng cho nhau, nhưng nếu đặt cạnh mà nhìn thì cũng thấy được động cơ khiến người có kỹ năng dịch chuyển nằm ở đâu. Cùng báo cáo đó nêu tỷ lệ nghỉ việc trong khu vực vào khoảng 17,5%. Con số này được ghi là của khu vực, tức regional, và không được ghi rõ là con số riêng của Thái Lan, nên không thể khẳng định đó là tỷ lệ nghỉ việc của Thái Lan. Dù vậy nó vẫn dùng được như một tham chiếu về mặt bằng. Ngoài ra, báo cáo đó không ghi bản thân các mức lương bằng tiền, nên bài viết này không đề cập tới số tiền.

Thử giả định một dự án kéo dài 18 tháng, và xin nói rõ khoảng thời gian này là giá trị giả định dùng để minh họa. Không có gì bảo đảm rằng nhân viên bản địa từng tham gia định nghĩa yêu cầu vẫn còn tại vị lúc hệ thống vận hành. Nhân viên Nhật Bản biệt phái cũng có thể được thay giữa chừng dự án theo mốc hết nhiệm kỳ. Lý do vì sao lại quyết như vậy thường không nằm trong biên bản định nghĩa yêu cầu, mà chỉ nằm trong đầu người có mặt lúc đó. Khi người thay đổi, ngữ cảnh ấy mất đi. Chỉ nhìn vào tài liệu đặc tả còn lại thì thành ra không hiểu vì sao lại thiết kế thế này, rồi phải dừng để đi xác nhận. Đây chính là yếu tố khuếch đại trễ tiến độ mang tính đặc thù của các cơ sở tại Thái Lan.

Nếu chia thành các đợt ba tháng, khả năng cùng một người phụ trách từ định nghĩa yêu cầu tới lúc vận hành sẽ cao hơn. Sản phẩm hoàn thành trước khi ngữ cảnh kịp mất đi. Đây không phải lý thuyết tổ chức, mà đơn giản là vấn đề độ dài thời gian. Xin nói thêm, phán đoán về việc chia nhỏ dự án cũng dùng được y như vậy tại các cơ sở ở Việt Nam, vì cơ chế đằng sau là quan hệ giữa quy mô và tỷ lệ không đạt QCD chứ không phải đặc thù của một quốc gia. Còn thị trường lao động và các số liệu thống kê của Việt Nam thì bài viết này không đề cập, vì chúng nằm ngoài các nguồn mà bài đã kiểm chứng.

Thứ hai, có hoàn cảnh nơi ra quyết định bị phân tán. Giám đốc nhà máy của pháp nhân Thái Lan, trưởng khối quản trị, bộ phận hệ thống thông tin của trụ sở Nhật Bản, và tùy trường hợp còn có bộ phận kinh doanh của trụ sở. Dự án lớn cố lấy đồng thuận của tất cả những người này trong một lần. Bản thân việc tạo đồng thuận đã tốn thời gian, và chi phí để thay đổi nội dung đã đồng thuận lại cao. Với một đợt nhỏ thì phạm vi ra quyết định cũng nhỏ theo. Việc có thể dùng kết quả thực tế của đợt 1 để xin phê duyệt cho đợt 2 cũng là một lợi thế.

Thứ ba là sự bất định của môi trường kinh tế. Cùng báo cáo đó nêu dự báo tăng trưởng kinh tế năm 2026 của Thái Lan vào khoảng 1,6%, và ghi rõ nguồn gốc là IMF. Trong giai đoạn tăng trưởng chậm, hồ sơ xin phê duyệt cho khoản đầu tư lớn khó được thông qua, và kể cả khi thông qua thì vẫn có rủi ro bị rà soát lại giữa chừng. Small start, tức cách cho phép cắt quyết định đầu tư theo từng ba tháng, là cách tiến hành hợp với môi trường này.

Về việc chọn đối tác đặt hàng tại Thái Lan, bài cách chọn công ty phát triển hệ thống tại Thái Lan đã sắp xếp các trục phán đoán. Nếu đi theo hướng chia nhỏ, việc duy trì cùng một đối tác đã hiểu phần nền dùng chung sẽ rẻ hơn về lâu dài so với việc đổi đối tác theo từng đợt.

Những kiểu thất bại điển hình của small start

Không phải cứ chia nhỏ là chắc chắn thành công. Small start có những kiểu thất bại riêng của nó. Bốn kiểu hay gặp là như sau.

1. Dừng lại ở PoC. Làm một PoC để xác nhận hiệu quả, rồi hài lòng ở chỗ đã xác nhận được và dừng luôn. Nguyên nhân phần lớn là trong thiết kế của PoC không viết điều kiện chuyển sang chạy thật. Cái gì đạt tới mức nào thì tiến sang triển khai chính thức, ai là người phán định, và khi đó ngân sách lấy từ đâu. Nếu không chốt ba điều này ngay lúc bắt đầu PoC, thì PoC sẽ mãi chỉ là PoC.

2. Nhỏ quá nên không ra hiệu quả. Đã điện tử hóa một biểu mẫu, nhưng phía trước và phía sau biểu mẫu đó vẫn là giấy, nên rốt cuộc việc chép lại số liệu vẫn còn. Thậm chí còn tăng thêm chỗ phải nhập, khiến công sức nhiều hơn trước. Đơn vị chia nên là đơn vị nhỏ nhất mà nghiệp vụ đi trọn một vòng, chứ không phải đơn vị nhỏ nhất của chức năng. Nếu điện tử hóa nhật báo tác nghiệp thì phải cho đi trọn một vòng từ nhật báo tới tổng hợp rồi phản ánh vào kết quả sản xuất. Điều cần tránh là thiết kế có chỗ quay lại giấy ở giữa chừng.

3. Không có thiết kế nhân rộng. Đợt 1 thành công, nhưng khi định mở rộng sang nhà máy thứ hai thì đợt 1 lại bám quá sát cách vận hành của nhà máy thứ nhất nên không dùng được. Nếu giữ đúng phần những chỗ không được chia ở chương trước thì phần lớn đã phòng được, nhưng ngoài ra vẫn cần nêu rõ ngay lúc thiết kế đợt 1 việc phân loại thiết lập nào thay đổi theo cơ sở và thiết lập nào thì không.

4. Đổi nhà cung cấp theo từng đợt. Việc lấy báo giá cạnh tranh từng lần nhìn thì rẻ, nhưng vì hiểu biết về phần nền dùng chung không được kế thừa, nên từ đợt 2 trở đi sẽ đội thêm phần công sức mang tên khảo sát đặc tả của đợt trước. Ý đồ đằng sau dữ liệu chủ và cấp phát số có những phần không thể viết hết vào tài liệu, và phần đó nằm trong đầu người đã làm đợt trước.

Điểm chung của bốn kiểu này là sai lầm tối ưu hóa đợt 1 một cách đơn lẻ. Small start không phải là làm một dự án nhỏ một lần, mà là phân rã một mục tiêu lớn thành một chuỗi các dự án nhỏ. Nếu không có thiết kế cho cả chuỗi, thì đó chỉ là phát triển quy mô nhỏ, và phần lợi thu được từ quan hệ giữa quy mô với QCD cũng chỉ nhận được một phần.

Chọn gì cho đợt 1 — bắt đầu từ triệu chứng

Vậy nên chọn gì cho đợt đầu tiên. Những điều phiền toái được nói tới ở hiện trường nhà máy hầu như đều rơi vào một trong bốn triệu chứng sau.

Dễ xử lý nhất cho đợt 1 là xóa bỏ nhập liệu hai lần. Có ba lý do. Thứ nhất, phạm vi rõ ràng, vì có thể liệt kê đối tượng dưới dạng những trường đang được nhập vào cả tờ giấy này lẫn tệp Excel kia. Thứ hai, đo hiệu quả rất đơn giản, chỉ cần xét số lần nhập và thời gian nhập có giảm hay không. Thứ ba, sức cản từ hiện trường nhỏ, vì nhập liệu hai lần là việc vô ích với tất cả mọi người và gần như không ai phản đối việc bỏ nó đi.

Nếu bắt đầu từ giới hạn của quản lý bằng Excel, hãy tách bạch xem giới hạn đó là giới hạn gì. Tệp bị phân mảnh khiến không biết đâu là bản mới nhất là vấn đề chia sẻ và phân quyền, tính toán nặng là vấn đề khối lượng dữ liệu, tổng hợp phải làm tay là vấn đề cấu trúc. Mỗi loại có một toa thuốc khác nhau. Nếu gộp tất cả vào cách nói bỏ Excel để chuyển sang hệ thống, thì yêu cầu sẽ nở ra và đợt 1 sẽ phình to.

Khắc phục phụ thuộc cá nhân là việc quan trọng, nhưng thường là chủ đề quá nặng cho đợt 1. Phụ thuộc cá nhân nghĩa là quy trình chưa được văn bản hóa, nên trước khi hệ thống hóa còn phải kiểm kê lại chính nghiệp vụ đó. Như đã thấy ở chương trước, tỷ lệ doanh nghiệp nêu hiểu biết chưa đủ về nghiệp vụ hiện hành như một vấn đề là 38,2%. Đây là phần việc tốn thời gian. Cách làm thực tế hơn cho đợt 1 là chỉ giải quyết bước đầu của phụ thuộc cá nhân, chẳng hạn trong các tiêu chí phán định mà chỉ đương sự biết, chỉ đưa lên hệ thống phần có thể viết ra bằng con số.

Xin đặt ra một cam kết khi nói về hiệu quả. Hãy cố định đường cơ sở về một mốc duy nhất và tuyên bố rõ mốc đó. Ví dụ hãy viết rằng lấy làm chuẩn tổng thời gian từ lúc ghi chép tới lúc hoàn tất tổng hợp của nhật báo tác nghiệp công đoạn A, trong một tháng, cụ thể là tháng 6 năm 2026. Việc đo sau cải thiện cũng phải dùng đúng định nghĩa đó. Nếu đổi chuẩn theo từng tháng hoặc chọn lại tháng nào có lợi, thì con số vẫn tạo ra được nhưng không mang ý nghĩa gì.

Về phần ước tính bằng tiền, vì các dữ liệu công bố không chứa mặt bằng đơn giá người-tháng hay chi phí triển khai, nên bài viết này không đưa ra con số tuyệt đối. Nếu tự ước tính trong công ty mình thì trình tự như sau. Trước hết đo tổng thời gian mỗi tháng của phần công việc thuộc phạm vi. Tiếp theo nhân với đơn giá nhân công thực tế của chính công ty để ra mức tương đương chi phí nhân công mỗi tháng. Sau đó đo tổng thời gian sau cải thiện theo đúng định nghĩa cũ rồi lấy hiệu số. Cuối cùng đem hiệu số này so với chi phí triển khai được đưa ra trong báo giá thực tế. Đơn giá dùng ở đây là số thực của chính công ty chứ không phải mặt bằng bên ngoài. Toàn bộ những điều trên là trình tự để bạn đặt số của công ty mình vào mà tính, chứ không phải các con số do bài viết này đưa ra.

Khi đã bước sang giai đoạn chọn sản phẩm, bài so sánh và tuyển chọn hệ thống quản lý sản xuất đã tổng hợp các trục đánh giá. Nếu đi theo small start, thứ cần coi trọng khi chọn sản phẩm không phải là độ phủ chức năng, mà là cấu trúc có cho phép mở rộng phạm vi theo từng giai đoạn hay không.

Ranh giới giữa tự làm nội bộ và thuê ngoài trong quan hệ với small start

Khi quyết cách chia nhỏ, một thứ được quyết cùng lúc là ai sẽ làm. Trong phần tổng kết của cùng chương, báo cáo JUAS nêu các điểm sau.

• Khoảng 70% doanh nghiệp đặt mục tiêu về mặt phương châm là dùng kết hợp cả tự làm nội bộ lẫn thuê ngoài
• Trên thực tế cũng vậy, các giai đoạn đầu nguồn như hoạch định hệ thống và định nghĩa yêu cầu chức năng có tỷ lệ tự làm nội bộ cao, còn phần dựng hệ thống như thiết kế, lập trình và kiểm thử thì có tỷ lệ thuê ngoài cao
• Ở kỳ khảo sát năm tài khóa 2025, trong các hiệu quả kỳ vọng từ tự làm nội bộ, cắt giảm chi phí đã xếp trên tích lũy tri thức, và báo cáo suy đoán đây là ảnh hưởng của việc giá của nhà cung cấp tăng mạnh

Cấu trúc này ăn khớp rất tốt với thiết kế của small start. Việc giữ phần đầu nguồn ở nội bộ đồng nghĩa với việc tự mình quyết định chỗ chia. Chia ở đâu, đưa gì vào phần nền dùng chung của đợt 0, những điều đó chỉ người hiểu nghiệp vụ của chính công ty mới phán đoán được. Hai con số đã thấy ở chương trước, hiểu biết chưa đủ về nghiệp vụ hiện hành 38,2% và thiếu năng lực hoạch định hệ thống 34,5%, chính là vấn đề của phần đầu nguồn này. Nếu khoán trắng chỗ này ra ngoài, chỗ chia sẽ bị quyết theo tiêu chí dễ làm, và sản phẩm thu được là một đợt mà vòng nghiệp vụ bị đứt ở giữa.

Ngược lại, thiết kế, lập trình và kiểm thử là phần có thể dùng sức bên ngoài. Nếu đi theo hướng chia nhỏ thì khối lượng lập trình của mỗi đợt là nhỏ, nên tải quản lý bên thuê ngoài cũng nhỏ theo.

Về bản thân ranh giới ai nắm giữ lớp nào, bài hỗ trợ tự làm nội bộ AI và cách quyết định lớp nào giữ lại trong công ty đã bàn tới. Bài đó cắt dọc theo hướng ai nắm giữ lớp nào, còn bài này cắt ngang theo hướng một dự án nên chia ở đâu. Hai bài bổ sung cho nhau, và trong thực tế cần quyết cả hai cùng lúc. Chỉ quyết đường cắt dọc thì độ lớn của mỗi đợt vẫn chưa được xác định, còn chỉ quyết cách chia ngang thì vẫn chưa rõ ai nắm phần đầu nguồn.

Điểm này cũng trùng với nhận định về thiếu hụt kỹ năng đã nhắc tới ở trên. Nghĩa là không phải cứ nghiêng về tự làm nội bộ thì xong, hay cứ nghiêng về thuê ngoài thì xong. Nghiêng về phía nào đi nữa, biện pháp giảm độ phức tạp phải xử lý trong một lần vẫn phát huy tác dụng.

Cách chạy đợt 1 trong 13 tuần (khoảng 90 ngày)

Cuối cùng, xin đặt cách tiến hành thực tế lên trục thời gian. Dưới đây là bố cục tiêu chuẩn do bài viết này đề xuất, còn thời lượng và cách phân bổ là giá trị giả định. Xin điều chỉnh theo bộ máy của công ty bạn.

Điểm mấu chốt của bố cục này là đặt đợt 0 vào tuần 3 và 4. Sẽ có lúc bạn muốn bỏ qua chỗ này để vào định nghĩa yêu cầu ngay từ tuần 5, nhưng cái giá của việc bỏ qua chắc chắn sẽ tới ở đợt 2. Nói ngược lại, việc có dành nổi hai tuần cho đợt 0 hay không chính là ranh giới quyết định small start có vận hành được hay không.

Điểm mấu chốt thứ hai là đưa việc liệt kê tên các mục của đợt 2 trở đi vào tuần 5 và 6. Chưa cần thiết kế, chỉ cần xếp tên ra. Dù vậy vẫn biết được cái vỏ của dữ liệu chủ còn thiếu trường nào hay không. Việc này xong trong vài ngày, nhưng có làm hay không sẽ làm thay đổi công sức của đợt 2.

Việc lấy tiêu chí phán định của tuần 11 là chỉ riêng người phụ trách ở hiện trường cũng vận hành được một ngày cũng có chủ ý. Chạy được khi thành viên dự án đứng bên cạnh thì không có nghĩa là vận hành được. Có chạy nổi khi đã buông tay hay không mới là điểm đạt hay không đạt thực chất.

Và khi 13 tuần kết thúc, nhất định phải nhìn lại trước khi bước vào đợt tiếp theo. Đơn vị chia đã hợp lý chưa, đợt 0 còn thiếu gì, định nghĩa đo hiệu quả có dùng tiếp được không. Chính việc nhìn lại này tạo ra cơ chế càng chồng nhiều đợt thì độ chính xác càng tăng.

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

DX nhà máy nên bắt đầu từ đâu

Trước hết hãy chọn một triệu chứng. Trong bốn thứ, nhập liệu hai lần, chép sai số liệu, giới hạn của quản lý bằng Excel và phụ thuộc cá nhân, hãy chọn thứ mà hiện trường kêu là đau nhất. Sau đó xác nhận xem triệu chứng đó có cắt được theo đơn vị nhỏ nhất mà nghiệp vụ đi trọn một vòng hay không. Nếu cắt được thì đó là đợt 1. Nếu không cắt được, ví dụ phải đi hết cả công đoạn mới ra hiệu quả, thì nới phạm vi rộng ra một chút. Về thứ tự thì là xác định triệu chứng, đo đường cơ sở, thiết kế phần nền dùng chung, rồi mới lập trình đợt 1. Nếu bắt đầu từ chữ DX thì phạm vi sẽ phân tán, nên thực tế hơn là bắt đầu từ điều phiền toái.

Giới hạn của quản lý bằng Excel đến khi nào

Có ba loại giới hạn, và thứ tự đến cũng như nguyên nhân đều khác nhau. Loại thứ nhất là giới hạn về chia sẻ, tức tệp bị tách thành nhiều bản và không còn biết đâu là bản mới nhất. Loại thứ hai là giới hạn về dung lượng và tốc độ, tức số dòng tăng lên khiến mở tệp mất thời gian. Loại thứ ba là giới hạn về cấu trúc, tức mỗi lần tổng hợp lại phải sao chép dán bằng tay. Loại hay gây tác động nhất trong thực tế là loại thứ ba, và nó phát sinh ngay cả khi số dòng còn ít. Phán đoán rằng số dòng còn ít nên vẫn ổn có thể là do nhận nhầm loại giới hạn. Ngoài ra, các nguồn mà bài viết này tham chiếu không chứa giá trị chuẩn đã công bố nào về số dòng hay số bản ghi cụ thể của giới hạn.

Muốn bỏ nhập liệu hai lần thì bắt tay từ đâu

Trước hết hãy viết ra giấy các trường đang bị nhập hai lần. Một sơ đồ chỉ gồm các mũi tên nối ô nào của biểu mẫu nào đang được chép sang đâu là đủ. Tiếp theo, trong các mũi tên đó hãy chọn mũi tên có số lượng nhiều, hoặc mũi tên tốn nhiều thời gian cho mỗi lần. Nếu bỏ được một bên thì đó là lời giải rẻ nhất. Nếu cả hai bên đều cần thì cho nhập một lần, còn bên kia được sinh ra tự động. Việc này làm được trước khi mua hệ thống. Thậm chí làm trước sẽ giúp tiền đề của báo giá rõ ràng hơn.

Trong ngành sản xuất, khắc phục phụ thuộc cá nhân bắt đầu từ đâu

Phụ thuộc cá nhân có loại quy trình chưa được văn bản hóa và loại tiêu chí phán định chưa được ngôn ngữ hóa. Loại trước phần lớn sẽ gỡ được nếu làm tài liệu quy trình, còn loại sau đòi hỏi công việc biểu diễn tiêu chí phán định bằng con số trước khi hệ thống hóa. Vấn đề là có thay thế được cái đang phán đoán bằng mắt thành cái nếu con số này nằm trong khoảng này thì đạt hay không. Cách thực tế là đưa lên hệ thống dần dần, bắt đầu từ những phần thay thế được. Nếu định ngôn ngữ hóa toàn bộ trong một lần thì sẽ dừng ngay tại đó. Trong khảo sát của JUAS, có 38,2% doanh nghiệp nêu hiểu biết chưa đủ về nghiệp vụ hiện hành như một vấn đề của tự làm nội bộ, và đó cũng chính là mặt trái của phụ thuộc cá nhân.

Có nên bỏ vận hành giấy tờ trong một lần

An toàn hơn là không làm trong một lần. Lý do là tờ giấy đôi khi mang thêm các chức năng ngoài việc ghi chép. Dán thông báo, chuyền tay để phê duyệt, ghi chú ngay tại hiện trường, nộp ra bên ngoài. Nếu định thay thế tất cả cùng lúc thì việc bỏ sót sẽ bị phát hiện sau khi đã vận hành. Hãy chọn một biểu mẫu, liệt kê đủ mọi chức năng mà biểu mẫu đó đang đảm nhiệm, rồi mới thay thế. Cách chắc chắn là thiết lập được trình tự này trên một biểu mẫu rồi mới sang biểu mẫu tiếp theo.

Small start rốt cuộc có tốn kém hơn khi tính tổng không

Phần công sức do hệ thống cũ và mới cùng tồn tại trong thời gian chuyển đổi thì đúng là tăng lên. Tuy nhiên thứ cần đem ra so sánh không phải là kịch bản triển khai gộp một lần diễn ra suôn sẻ, mà là giá trị kỳ vọng của những gì thực sự xảy ra. Trong khảo sát của JUAS, tỷ lệ dự án có ngân sách vượt so với kế hoạch ở nhóm từ 500 người-tháng trở lên là 42,2%, còn ở nhóm dưới 10 người-tháng là 6,0%. Tỷ số hai đầu cực là 42,2 chia 6,0 bằng 7,03 lần. Trễ tiến độ cũng vậy, ở nhóm từ 500 người-tháng trở lên là 47,8%. Cần đưa cả phần vượt và phần trễ của kịch bản làm gộp vào rồi mới so sánh. Xin lưu ý, khảo sát này nhắm vào các doanh nghiệp người dùng trong nội địa Nhật Bản, không phải kết quả thực tế của pháp nhân tại Thái Lan. Hãy dùng nó như tham chiếu về xu hướng.

Cải tiến quy trình quản lý sản xuất nên làm trước hay sau khi triển khai hệ thống

Làm trước. Nhưng không cần làm toàn bộ ở phía trước. Việc cải tiến nghiệp vụ nhà máy bằng hệ thống cũng vậy, chỉ cần với phạm vi của đợt 1 thì vẽ lại quy trình hiện trạng, bỏ đi những lãng phí đã thấy rõ, rồi mới đưa lên hệ thống. Nếu hệ thống hóa mà vẫn để nguyên lãng phí thì lãng phí sẽ bị cố định lại. Mặt khác, nếu định làm xong hoàn hảo việc cải tiến quy trình rồi mới bước vào hệ thống thì sẽ mãi không bắt đầu được. Thực tế hơn là làm theo vòng lặp, cải tiến giới hạn trong phạm vi đợt 1, cho chạy thật rồi mới sang bước cải tiến tiếp theo.

Đợt 1 nên có quy mô bao nhiêu là hợp lý

Thứ mà dữ liệu công bố cho thấy là xu hướng nhóm dưới 10 người-tháng có tỷ lệ không đạt QCD thấp nhất. Báo cáo JUAS ghi rằng ở nhóm quy mô dự án dưới 10 người-tháng thì cả ba chỉ tiêu QCD đều thấp hơn 10,0%. Tuy nhiên đây là khảo sát trong nội địa Nhật Bản, và ranh giới 10 người-tháng là cách chia nhóm để tổng hợp của khảo sát chứ không phải giá trị được đưa ra như một khuyến nghị. Về mặt thực tiễn, thứ tự hợp lý là lấy độ lớn được xác định một cách tự nhiên khi chia theo đơn vị nhỏ nhất mà nghiệp vụ đi trọn một vòng, và nếu độ lớn đó trở nên quá lớn thì xem lại cách chia. Nếu nói theo thời gian, một mốc tham khảo là từ định nghĩa yêu cầu tới lúc vận hành có gói gọn trong khoảng ba tháng hay không, và xin nói rõ con số ba tháng này là giá trị giả định của bài viết chứ không dựa trên nguồn nào.

Ngân sách cho các đợt từ đợt 2 trở đi lấy ở đâu

Hãy dùng kết quả đo hiệu quả của đợt 1 vào hồ sơ xin phê duyệt cho đợt 2. Chính vì vậy mà việc cố định định nghĩa đường cơ sở ngay từ đầu là quan trọng. Nếu đợt 1 kết thúc rồi mới bắt đầu nghĩ đo thế nào thì sẽ không tạo được con số có thể so sánh. Việc đặt bước đo đường cơ sở vào tuần 1 và 2 chính là vì lý do này. Ngoài ra, ở những tổ chức vận hành theo khung ngân sách năm tài khóa, việc khớp ranh giới các đợt theo quý và chạy nhiều đợt trong năm sẽ dễ điều chỉnh hướng đi giữa chừng hơn là khớp theo ranh giới năm tài khóa.

Tổng kết

Triển khai hệ thống theo hướng small start không phải là lựa chọn của việc tiếc tiền đầu tư. Như báo cáo Corporate IT Trend Survey Report 2026 của JUAS cho thấy, giữa quy mô dự án và tỷ lệ không đạt QCD tồn tại một quan hệ rõ ràng. Không hài lòng về chất lượng là 5,4% ở nhóm dưới 10 người-tháng và 29,6% ở nhóm từ 500 người-tháng trở lên, tức 5,48 lần nếu tính theo tỷ số. Vượt ngân sách là 6,0% ở nhóm dưới 10 người-tháng và 42,2% ở nhóm từ 500 người-tháng trở lên, tức 7,03 lần nếu tính theo tỷ số. Trễ tiến độ, theo bảng tổng hợp ba nhóm có cách chia khác, là 47,8% ở nhóm từ 500 người-tháng trở lên. Chia nhỏ là quyết định tự đặt mình vào phía có lợi của quan hệ đó, và bản thân nó chính là hoạt động quản trị rủi ro lớn nhất.

Đồng thời, cách chia cũng có những lằn ranh phải giữ. Màn hình được chia, biểu mẫu được chia, logic nghiệp vụ cũng được chia. Nhưng thiết kế trường của dữ liệu chủ, hệ thống mã, việc cấp phát số, người dùng và phân quyền, cách xử lý thời điểm, chính sách lưu lịch sử thì không được chia. Chia những thứ này thì cái giá đắt sẽ tới sau, dưới dạng sổ cái trùng lặp, trùng số và tài khoản của người đã nghỉ việc. Hãy đặt phần nền dùng chung xuống trước với tư cách đợt 0. Đó chính là ranh giới biến small start từ phát triển quy mô nhỏ đơn thuần thành việc phân rã một mục tiêu lớn.

Ở các cơ sở tại Thái Lan và ASEAN còn có thêm hoàn cảnh dự án dài thì vắt qua nhiều đợt thay người. Người quyết yêu cầu có còn tại vị tới lúc vận hành hay không phụ thuộc vào độ dài thời gian. Ở điểm này nữa, cách chia thành các đợt khoảng ba tháng là hợp lý.

Cuối cùng, toàn bộ các con số mà bài viết này tham chiếu đều dựa trên các khảo sát đã công bố ở nội địa Nhật Bản hoặc ở phạm vi khu vực, và không phải là giá trị dự báo cho một nhà máy cụ thể. Vì các nguồn không chứa số tiền hay đơn giá người-tháng nên bài viết không nêu ra. Phán đoán của công ty bạn xin hãy đặt trên đường cơ sở là số thực của chính công ty.

TOMAS TECH lấy Bangkok, Thái Lan làm cơ sở, thực hiện các hệ thống quản lý sản xuất, IoT và FA cho các doanh nghiệp sản xuất Nhật Bản. Nên chia ở đâu, đợt 0 nên gồm những gì, những điều đó thay đổi theo nghiệp vụ tại hiện trường và tình trạng của các hệ thống hiện có. Nếu bạn muốn trao đổi từ khâu xác định phạm vi của đợt 1 hay thiết kế phần nền dùng chung, xin liên hệ qua biểu mẫu liên hệ. Chúng tôi hỗ trợ miễn phí tới bước khảo sát hiện trạng và đề xuất phương án chia nhỏ.

Thông tin tham khảo

• JUAS Corporate IT Trend Survey Report 2026 (Chapter 7, System Development) — Japan Users Association of Information Systems. Tham chiếu các hình 7-1-3, 7-1-4 và 7-2-7
• JUAS Corporate IT Trend Survey 2026, thông cáo báo chí đợt 2 — tổng quan khảo sát, 957 công ty trả lời hợp lệ, thời gian khảo sát từ 5/9/2025 đến 24/10/2025
• JUAS Corporate IT Trend Survey, trang giới thiệu khảo sát — vị trí của khảo sát và danh sách các kỳ trước
• IPA DX Trend Survey năm tài khóa 2025, thông cáo báo chí — Information-technology Promotion Agency, Japan. Số phiếu thu về 1.799 công ty, thiếu hụt về lượng nhân lực thúc đẩy DX 85,5%
• Thailand Job Market 2026 Outlook — RECRUITdee. Ngân sách tăng lương trung bình khoảng 4,7%, tỷ lệ nghỉ việc trong khu vực khoảng 17,5%, dự báo tăng trưởng kinh tế khoảng 1,6% với nguồn gốc là IMF
• JUAS Corporate IT Trend Survey 2026, thông cáo báo chí đợt 1 — thông báo đầu tiên về việc công bố khảo sát