Quy trình triển khai hệ thống quản lý sản xuất | 9 giai đoạn

Khi bắt đầu cân nhắc một cách cụ thể việc triển khai hệ thống quản lý sản xuất tại nhà máy ở Thái Lan hay Việt Nam, câu hỏi đầu tiên mà doanh nghiệp gặp phải thường là nên bắt đầu từ đâu. Bạn đã tìm hiểu qua các bảng so sánh sản phẩm và mặt bằng chi phí. Dù vậy, quy trình triển khai hệ thống quản lý sản xuất trên thực tế diễn ra thế nào, từ định nghĩa yêu cầu, lựa chọn nhà cung cấp, phân tích Fit&Gap, kiểm thử, chuyển đổi dữ liệu cho đến vận hành chính thức, và ai trong công ty phải làm gì vào lúc nào, thì vẫn còn rất mơ hồ. Bài viết này chia toàn bộ quy trình đó thành 9 giai đoạn, giải thích theo góc nhìn thực tiễn về nội dung công việc, các bên liên quan và những điểm dễ vấp ở từng bước. Đồng thời, bài viết cũng đề cập tới những vấn đề đặc thù của các cơ sở tại ASEAN, chẳng hạn visa công tác cho kỹ sư người Nhật, mùa cao điểm quyết toán vào tháng 12, và năng lực hỗ trợ tiếng Nhật của các nhà tích hợp hệ thống bản địa.

Triển khai hệ thống quản lý sản xuất là gì và vì sao hiện nay được quan tâm

Việc triển khai hệ thống quản lý sản xuất thường được hiểu tại nhiều nhà máy là mua một phần mềm rồi cài vào. Nhưng trên thực tế, đây là một nỗ lực diễn đạt lại bằng ngôn ngữ toàn bộ dòng chảy nghiệp vụ, chuẩn hóa những phần có thể chuẩn hóa, và thiết kế lại chính cách làm việc cho phù hợp với hệ thống. Thứ được mua là phần mềm, nhưng thứ thay đổi là cách con người và thông tin vận động. Chính khoảng lệch trong nhận thức này là điểm xuất phát của phần lớn các thất bại được đề cập ở phần sau.

Bối cảnh khiến nhu cầu xem xét tăng lên

Trong một khảo sát nhắm tới các doanh nghiệp vừa và nhỏ tại Nhật Bản, tỷ lệ doanh nghiệp trả lời rằng đã bắt tay vào DX hoặc đang cân nhắc triển khai DX là 39.1%. Khảo sát được thực hiện từ ngày 5 đến ngày 18 tháng 12 năm 2025 với 1,000 doanh nghiệp vừa và nhỏ trên toàn quốc và được công bố vào tháng 2 năm 2026, mức này gần như đi ngang so với khảo sát trước đó vào tháng 12 năm 2024. Trong khi đó, tỷ lệ ứng dụng AI là 28.4%, tăng 14.1 điểm so với lần khảo sát trước. Có thể đọc ra một bức tranh trong đó tỷ lệ khởi động DX tổng thể đang giậm chân tại chỗ, còn việc sử dụng từng công nghệ riêng lẻ lại tăng tốc rất nhanh.

Nếu thu hẹp vào ngành chế tạo, các con số còn khắc nghiệt hơn. Trong Sách trắng ngành chế tạo năm 2026 được trình lên kỳ họp Quốc hội Nhật Bản lần thứ 221 vào tháng 5 năm 2026, có tới 55% doanh nghiệp vừa và nhỏ trả lời rằng họ chưa xây dựng và cũng không có kế hoạch xây dựng chiến lược ứng dụng công nghệ số. Các khó khăn chung được nêu ra là thiếu kiến thức và bí quyết về công nghệ số, ở mức khoảng 46% đến 58%, và thiếu nhân lực, ở mức khoảng 47% đến 58%. Trước cả câu hỏi có nên đầu tư thiết bị hay không, tình trạng phổ biến là trong nội bộ không có người đủ năng lực thiết kế.

Tại các cơ sở ở nước ngoài, ràng buộc này còn tác động mạnh hơn. Bộ phận hệ thống thông tin của trụ sở chính tại Nhật không nắm rõ nghiệp vụ ở hiện trường, còn tại địa phương thì không có nhân sự IT chuyên trách nào, hoặc chỉ có duy nhất một người kiêm nhiệm. Đó là chuyện không hiếm gặp. Chính vì vậy, việc có sẵn một khuôn mẫu về cách vận hành dự án lại càng có giá trị.

Tiền đề để không dừng lại ở việc chọn hệ thống

Việc triển khai hệ thống quản lý sản xuất có thể được sắp xếp thành hai giai đoạn lớn. Giai đoạn thứ nhất là trước khi triển khai, kéo dài cho tới khi quyết định phương thức, tức là dùng nguyên gói phần mềm đóng gói, bổ sung tùy chỉnh, hay xây dựng hoàn toàn mới từ đầu. Giai đoạn thứ hai là thực thi triển khai, đi từ phân tích Fit&Gap tới chuẩn bị dữ liệu master, thiết lập, tùy chỉnh, kiểm thử, rồi tới vận hành thực tế và chuyển đổi.

Trong hai giai đoạn này, sự quan tâm trong nội bộ hầu như dồn cả vào nửa đầu, tức là chọn cái nào. Nhưng phần lớn khối lượng công việc và rủi ro thất bại lại nằm ở nửa sau. Lý do bài viết này chia nhỏ thành 9 giai đoạn để giải thích là vì khi biết trước điều gì sẽ xảy ra ở nửa sau, chính tiêu chí lựa chọn ở nửa đầu cũng sẽ thay đổi. Thay vì ngồi xem danh sách tính năng của sản phẩm, việc hình dung xem phân tích Fit&Gap sẽ phát sinh bao nhiêu khoảng trống cho doanh nghiệp mình sẽ giúp nâng độ chính xác của việc lựa chọn.

Riêng về góc nhìn so sánh để chọn nhóm sản phẩm nào, chúng tôi đã trình bày trong bài So sánh và cách chọn hệ thống quản lý sản xuất có thể triển khai tại Thái Lan. Bài viết này tập trung vào bước tiếp theo, tức là cách vận hành toàn bộ quy trình triển khai bao gồm cả khâu lựa chọn.

Quy trình triển khai hệ thống quản lý sản xuất | Toàn cảnh 9 giai đoạn

Trước hết là bức tranh tổng thể. Cách gọi tên có thể khác nhau đôi chút tùy nhà cung cấp, nhưng trên thực tế nếu sắp xếp thành 9 giai đoạn dưới đây thì cả khi giải thích nội bộ lẫn khi trao đổi với nhà cung cấp đều ít xảy ra hiểu lầm.

Chín giai đoạn này trông có vẻ tiến thẳng một mạch, nhưng trên thực tế chắc chắn sẽ xảy ra tình huống phân tích Fit&Gap ở giai đoạn 4 phát hiện ra chỗ thiếu sót trong định nghĩa yêu cầu, khiến dự án phải quay lại một phần về giai đoạn 1. Bản thân việc quay lại không phải là thất bại. Vấn đề nằm ở chỗ khi cần quay lại thì không quay lại, mà cứ để mọi thứ mơ hồ rồi tiến tiếp.

Xin bổ sung về thời gian. Chúng tôi không tìm thấy thống kê đáng tin cậy nào, ít nhất là trong các thông tin công khai, chỉ ra thời lượng tiêu chuẩn cho toàn bộ các giai đoạn. Mức tham khảo mà các nhà cung cấp đưa ra cũng thay đổi rất nhiều tùy phạm vi và độ phức tạp của nghiệp vụ. Do đó bài viết này không đưa ra số tháng một cách khẳng định, mà chỉ nên dừng ở mức hiểu có biên độ, rằng nhiều trường hợp được cho là chỉ riêng khâu định nghĩa yêu cầu đã cần khoảng 3 tháng. Về cách lập tiến độ, chúng tôi đã tổng hợp riêng trong bài Thời gian triển khai hệ thống quản lý sản xuất và cách lập kế hoạch.

Giải thích thực tiễn từng giai đoạn

Từ đây chúng ta sẽ lần lượt xem qua 9 giai đoạn. Đặc biệt, phân tích Fit&Gap ở giai đoạn 4 là điểm then chốt gắn trực tiếp với các thống kê về nguyên nhân thất bại nêu ở phần sau, nên sẽ được trình bày kỹ hơn.

Giai đoạn 1 quyết định những gì trong định nghĩa yêu cầu

Định nghĩa yêu cầu thường được hiểu là công đoạn quyết định muốn hệ thống làm gì, nhưng thời gian thực tế lại được dành cho việc trực quan hóa hiện trạng. Thông tin đơn hàng đi qua biểu mẫu nào, chuyển tới đâu, ai phán đoán điều gì, và ở khâu nào thì nó bị thay thế bằng một mẩu giấy ghi tay. Khi lần theo từng bước của lộ trình này, sẽ lộ ra một sự thật là không một ai trong công ty nắm được toàn cảnh.

Tài liệu định nghĩa yêu cầu được định vị như một sản phẩm đầu ra nhằm ngăn ngừa sai lệch nhận thức giữa khách hàng và bên phát triển. Nói cách khác, mục đích của việc viết ra không phải là bao phủ hết mọi thứ mà là đạt được sự đồng thuận. Dù có làm ra một tập tài liệu dày cộp, nếu bộ phận nghiệp vụ không đọc thì nó cũng không làm tròn vai trò.

Trên thực tế, tiến hành theo trình tự sau sẽ ít bị tắc.

• Vạch ranh giới phạm vi nghiệp vụ mục tiêu ngay từ đầu. Là từ nhận đơn tới xuất hàng, hay bao gồm cả tính giá thành, và mua hàng cùng tồn kho thì đưa vào tới đâu.
• Phỏng vấn từng bộ phận về luồng nghiệp vụ hiện hành và vẽ nguyên trạng thành sơ đồ. Không vẽ hình ảnh lý tưởng mà vẽ đúng những gì đang thực sự làm.
• Liệt kê các vấn đề ở mức độ chi tiết của những điều đang gây khó khăn, rồi phân loại thành nhóm sẽ giải quyết bằng hệ thống, nhóm giải quyết bằng quy tắc vận hành, và nhóm lần này chưa xử lý.
• Rà soát các yêu cầu kết nối với hệ thống khác, các biểu mẫu cần thiết và khả năng mở rộng trong tương lai. Nếu để phần này lại sau, giai đoạn 4 sẽ phải làm lại rất nhiều.

Tại các cơ sở ở nước ngoài, điều cần đặc biệt lưu ý là định dạng báo cáo gửi về trụ sở chính tại Nhật. Dù nghiệp vụ tại chỗ không cần, nhưng nếu trụ sở đã quy định cách bóc tách giá thành hay mức độ chi tiết của báo cáo tiến độ, thì đó chính là yêu cầu. Nếu bổ sung yêu cầu của trụ sở vào phút chót của khâu định nghĩa yêu cầu, bạn sẽ phải thiết kế lại.

Giai đoạn 2 lựa chọn nhà cung cấp và cách dùng RFP

Khi các yêu cầu đã tương đối định hình, hãy mời nhà cung cấp gửi đề xuất. Tại đây, nếu không lập RFP mà chỉ tiến hành bằng trao đổi miệng và email, mức độ chi tiết của các đề xuất sẽ khác nhau tùy nhà cung cấp, khiến việc so sánh trở nên bất khả thi. Cách viết RFP cụ thể được chúng tôi tổng hợp trong bài Cách viết RFP cho hệ thống quản lý sản xuất và các mục cần ghi.

Khi lựa chọn tại các cơ sở ASEAN, việc kiểm tra cơ cấu nhân sự và ngôn ngữ hỗ trợ hiệu quả hơn so với so sánh danh sách tính năng. Các hạng mục cần kiểm tra có thể sắp xếp như sau.

Trong số này, dòng đầu tiên là dòng có tác động lớn nhất về sau. Lý do sẽ được nói kỹ ở mục các điểm lưu ý đặc thù của Thái Lan, nhưng nhân sự có thể khai thác yêu cầu bằng tiếng Nhật là nguồn lực hạn chế ngay cả tại các nhà tích hợp hệ thống bản địa, nên việc phân bổ nguồn lực đó cần được chốt trước khi ký hợp đồng.

Giai đoạn 3 những điểm không được để mơ hồ trong hợp đồng

Điều cần quyết ở khâu hợp đồng không hẳn là số tiền, mà là phạm vi và ranh giới trách nhiệm. Đặc biệt ba điểm sau rất dễ trở thành mồi lửa cho tranh chấp về sau.

Thứ nhất là cách xử lý phần tùy chỉnh. Việc phát triển add-on phát sinh từ kết quả phân tích Fit&Gap có nằm trong giá trị hợp đồng hay sẽ được báo giá riêng. Nếu nằm trong thì tối đa bao nhiêu người-ngày. Nếu không vạch rõ ranh giới này, từ giai đoạn 4 trở đi câu chuyện chi phí sẽ kéo dài không dứt.

Thứ hai là phạm vi trách nhiệm chuyển đổi dữ liệu. Việc chuẩn hóa dữ liệu nguồn, tức là sửa các mã hàng trùng lặp hay cách viết không thống nhất trong master khách hàng, thông thường thuộc trách nhiệm bên đặt hàng. Nếu hiểu lầm rằng có thể phó mặc phần này cho nhà cung cấp, dự án sẽ dừng lại ở giai đoạn 7.

Thứ ba là điều kiện nghiệm thu. Căn cứ vào đâu để coi là hoàn thành. Nếu văn bản hóa tiêu chí đạt của UAT ngay khi ký hợp đồng, bạn sẽ giảm được những tranh cãi vô ích ở giai đoạn 6 kiểu như đây là đặc tả hay đây là lỗi.

Toàn cảnh chi phí và cách hiểu về TCO được chúng tôi trình bày riêng trong bài Chi phí triển khai hệ thống quản lý sản xuất và cơ cấu TCO.

Giai đoạn 4 cách tiến hành phân tích Fit&Gap một cách cụ thể

Hạt nhân của giai đoạn thực thi triển khai chính là phân tích Fit&Gap. Đây là công đoạn rà soát những nghiệp vụ mà tính năng chuẩn của gói phần mềm đáp ứng được, gọi là Fit, và những nghiệp vụ không đáp ứng được, gọi là Gap, rồi quyết định hướng xử lý cho từng Gap.

Cách tiến hành đại thể gồm 4 bước sau.

Bước thứ nhất là làm rõ phạm vi và thứ tự ưu tiên của các nghiệp vụ mục tiêu. Nếu cố phân tích mọi nghiệp vụ với cùng một mức độ nhiệt tình, bạn sẽ không kịp hoàn thành trong thời hạn. Hãy bắt đầu từ các dòng chảy cốt lõi gắn trực tiếp với doanh thu và chất lượng, còn các xử lý ngoại lệ mỗi tháng chỉ phát sinh vài lần thì để lại sau hoặc ghi rõ là nằm ngoài phạm vi lần này.

Bước thứ hai là phỏng vấn từng bộ phận. Sắp xếp lại luồng nghiệp vụ hiện hành và các vấn đề, rồi đối chiếu chúng với màn hình của tính năng chuẩn để xác nhận xem thao tác này có chạy được không. Điều quan trọng ở đây là để chính người phụ trách của bộ phận nghiệp vụ tự tay chạm vào màn hình thật. Nếu chỉ đưa tài liệu ra thuyết minh thì sẽ không tìm ra Gap.

Bước thứ ba là chốt đặc tả. Vừa cân nhắc kết nối với hệ thống khác, các biểu mẫu cần thiết và khả năng mở rộng trong tương lai, vừa cố định xem sẽ dùng thiết lập nào của tính năng chuẩn. Biểu mẫu là thứ đặc biệt hay bị bỏ sót, và Gap thường lộ ra dưới dạng bản in giấy mà hiện trường vẫn in hằng ngày lại không có trong tính năng chuẩn.

Bước thứ tư là quyết định hướng xử lý cho các Gap. Tại đây có 3 lựa chọn.

Trên thực tế, người ta không chọn máy móc một trong 3 hướng này, mà ghi thêm vào danh sách Gap các cột về tính tất yếu trong nghiệp vụ và sự tồn tại của phương án thay thế, rồi phán đoán từng mục một. Nếu phân công theo hướng bộ phận nghiệp vụ ra phán quyết còn nhà cung cấp chỉ đóng vai trò trình bày các lựa chọn và ước lượng khối lượng công việc, thì cuộc thảo luận sẽ tiến triển.

Điều dễ mắc phải ở đây là nghiêng quá dễ dãi về phía phát triển add-on. Nếu nhặt hết mọi nguyện vọng của hiện trường, phần lớn danh sách Gap sẽ thành add-on. Khi đó chi phí và thời gian đều phình to, và bạn còn ôm thêm một khối tài sản cần sửa chữa mỗi lần gói phần mềm nâng cấp phiên bản. Ngược lại, nếu cố ép mọi thứ theo hướng BPR thì hiện trường sẽ không chuyển động, và sau khi vận hành sẽ chỉ còn lại một hệ thống không ai dùng.

Một cách hữu hiệu để làm chuẩn phán đoán là đặt câu hỏi sau cho từng mục. Cách làm nghiệp vụ này có liên quan tới lý do khách hàng chọn công ty chúng ta hay không. Nếu không liên quan thì vẫn còn dư địa để chỉnh theo tính năng chuẩn. Nếu có liên quan thì đó là Gap đáng để đầu tư.

Tại các cơ sở ở Thái Lan, còn có thêm góc nhìn đặc thù của nước sở tại. Các yêu cầu về thuế của Thái Lan và mẫu biểu mà đối tác giao dịch yêu cầu là loại Gap không thể né tránh bằng xử lý vận hành hay BPR. Nếu tách riêng những thứ này ra thành add-on bắt buộc ngay từ sớm và tách khỏi các nội dung còn lại, cuộc thảo luận sẽ mạch lạc hơn.

Giai đoạn 5 bên đặt hàng phải làm gì trong thời gian phát triển và tùy chỉnh

Đây là giai đoạn nhà cung cấp làm việc. Bên đặt hàng dễ rơi vào trạng thái chỉ ngồi chờ, nhưng thực tế vẫn có những việc phải làm.

Việc thứ nhất là bắt tay vào chuẩn hóa dữ liệu master để chuẩn bị cho khâu chuyển đổi dữ liệu ở giai đoạn 7. Công việc dẹp bỏ trùng lặp và thống nhất cách viết trong master vật tư, master khách hàng và master công đoạn vừa tốn thời gian vừa cần phán đoán của hiện trường, nên không thể thuê ngoài. Nếu không làm song song trong thời gian phát triển, bạn sẽ bế tắc ngay trước lúc chuyển đổi.

Việc thứ hai là chuẩn bị kế hoạch kiểm thử. Tại giai đoạn tiếp theo, bộ phận nghiệp vụ sẽ thực hiện UAT, nhưng nếu tới lúc đó mới bắt đầu soạn các ca kiểm thử thì sẽ không kịp. Trong thời gian phát triển, bộ phận nghiệp vụ nên viết sẵn ra bằng ngôn ngữ của chính mình các kịch bản kiểu nếu có đơn hàng như thế này thì hệ thống phải xử lý như thế kia.

Việc thứ ba là kiềm chế thay đổi đặc tả. Thay đổi đặc tả sau khi đã bắt đầu phát triển cũng được nêu trong thống kê ở phần sau như là nguyên nhân lớn nhất gây vượt tiến độ. Nếu lập một diễn đàn hằng tuần để phán quyết xem thay đổi có cần thiết hay không, và quy định rằng thay đổi nào không qua diễn đàn đó thì không được tiếp nhận, thì tiến trình sẽ ổn định.

Giai đoạn 6 thiết kế kiểm thử và UAT như thế nào

Kiểm thử chia thành kiểm thử đơn vị và kiểm thử tích hợp do nhà cung cấp thực hiện, và kiểm thử chấp nhận do bên đặt hàng thực hiện, gọi là UAT. Thứ quyết định thành bại của dự án chính là UAT.

Điều cần tránh trong UAT là chỉ xác nhận bằng dữ liệu mẫu sạch đẹp. Trong nghiệp vụ thực tế, các trường hợp ngoại lệ xảy ra hằng ngày, chẳng hạn đơn hàng bị đổi số lượng giữa chừng, hàng trả lại vắt qua ngày chốt sổ, hay tồn kho có đơn vị tính khác nhau. Nếu không đưa những tình huống này vào ca kiểm thử, chỉ một tuần sau khi vận hành sẽ có báo cáo rằng mẫu hình này hệ thống không xử lý được.

Khi soạn ca kiểm thử, sắp xếp theo các góc nhìn sau sẽ giảm sót.

• Kịch bản cơ bản chạy suốt luồng thông thường từ đầu tới cuối
• Kịch bản có thay đổi hoặc hủy bỏ xen vào giữa chừng
• Các giá trị biên như số lượng bằng không, đúng ngày chốt sổ, số chữ số tối đa
• Kiểm tra xem nội dung dữ liệu gửi sang hệ thống khác có đúng không
• Cách hiển thị khi đăng nhập bằng những người dùng có quyền khác nhau

Việc phán quyết đạt của UAT không dựa trên số lượng lỗi phát hiện được, mà dựa trên việc nghiệp vụ có chạy thông từ đầu tới cuối mà không bị đứt hay không. Dù còn lỗi tồn đọng, nếu có biện pháp né tránh và nghiệp vụ vẫn chạy thì vẫn có thể vận hành. Ngược lại, dù lỗi bằng không nhưng nghiệp vụ không chạy thông thì không được phép vận hành.

Giai đoạn 7 chuyển đổi dữ liệu và chuẩn hóa master

Chuyển đổi dữ liệu về mặt kỹ thuật là công việc đơn giản, nhưng lại là giai đoạn tạo gánh nặng lớn nhất cho hiện trường. Lý do là chất lượng của dữ liệu cần chuyển đổi nằm trong phạm vi trách nhiệm của bên đặt hàng.

Công việc bắt đầu từ việc quyết định đối tượng chuyển đổi. Sẽ mang theo dữ liệu thực tích của bao nhiêu năm về trước. Tồn kho thì chuyển đổi hay làm lại bằng kiểm kê. Sản phẩm dở dang thì xử lý ra sao. Chỉ bộ phận nghiệp vụ mới phán đoán được những điều này.

Tiếp theo là chuẩn hóa master. Nếu để nguyên tình trạng cùng một linh kiện lại được gán nhiều mã hàng khác nhau, hay tên khách hàng lẫn lộn giữa ký tự toàn rộng và nửa rộng, rồi cứ thế chuyển đổi, thì cùng vấn đề đó sẽ được tái sản xuất bên trong hệ thống mới. Chuyển đổi cũng là cơ hội cuối cùng để làm sạch dữ liệu, nên rất đáng bỏ công sức vào đây.

Và sau đó là diễn tập chuyển đổi. Hãy thực hiện chuyển đổi thật theo đúng trình tự của lần chính thức, rồi kiểm chứng thời gian cần thiết và kết quả. Đừng dừng lại ở một lần diễn tập, hãy làm ít nhất 2 lần, và lần thứ hai thực hiện đúng khung giờ và đúng đội hình như lần chính thức, khi đó những bất ngờ trong ngày chính thức sẽ giảm đi.

Giai đoạn 8 phán quyết vận hành chính thức tức cắt chuyển

Cắt chuyển là thời điểm ban lãnh đạo phán quyết có vận hành hay không, dựa trên các tiêu chí đã định trước. Nguy hiểm nhất là tiến hành chỉ vì lý do đã trót chốt lịch rồi.

Các tiêu chí dùng để phán quyết cần được văn bản hóa chậm nhất là trước khi bắt đầu UAT. Điển hình là các mục như toàn bộ kịch bản bắt buộc của UAT đã thông qua, không còn lỗi nghiêm trọng chưa xử lý, diễn tập chuyển đổi đã thành công, đào tạo người dùng đã hoàn tất, và đã bảo đảm được đội ngũ tiếp nhận câu hỏi ngay sau khi vận hành.

Phương thức chuyển đổi là chuyển đồng loạt hoặc chạy song song. Chạy song song thì an toàn, nhưng hiện trường sẽ phải nhập cùng một dữ liệu vào 2 hệ thống, gánh nặng tăng gấp đôi. Nếu không giới hạn thời gian và quyết ngay từ đầu khi nào dừng hệ thống cũ, bạn sẽ rơi vào tình cảnh chạy song song kéo dài nửa năm.

Giai đoạn 9 ổn định duy trì và đo lường hiệu quả

Vận hành không phải là kết thúc mà là điểm bắt đầu. Giai đoạn ổn định duy trì có 3 việc phải làm.

Thứ nhất là văn bản hóa quy tắc vận hành. Ai nhập liệu vào lúc nào, kết quả thực tế được đăng ký vào thời điểm nào. Nếu điều này mơ hồ, dữ liệu tuy có trong hệ thống nhưng không khớp với thực tế sẽ ngày càng chất đống.

Thứ hai là duy trì đào tạo. Chỉ với buổi tập huấn tập trung trước khi vận hành thì người dùng không nắm được cách xử lý các trường hợp ngoại lệ. Nếu tổ chức các buổi nhìn lại dựa trên những tình huống đã thực sự xảy ra vào thời điểm 1 tháng và 3 tháng sau khi vận hành, chất lượng vận hành sẽ tăng lên.

Thứ ba là đo lường hiệu quả. Hãy xác nhận bằng con số xem những vấn đề đã đặt ra ở khâu định nghĩa yêu cầu có thực sự được giải quyết hay không. Nếu không làm việc này, bạn sẽ không còn cơ sở nào cho quyết định đầu tư tiếp theo.

Các điểm lưu ý đặc thù của Thái Lan | 3 vấn đề ảnh hưởng tới thiết kế tiến độ

Tới đây là những nội dung chung, không phân biệt trong hay ngoài nước. Từ đây trở đi, chúng tôi đề cập tới những vấn đề mà nếu bê nguyên cách làm ở Nhật Bản sang các cơ sở tại Thái Lan và ASEAN thì sẽ đổ vỡ.

Ràng buộc về visa và giấy phép lao động khi kỹ sư người Nhật đi công tác ngắn ngày

Việc cử kỹ sư người Nhật từ trụ sở chính hoặc từ nhà cung cấp tại Nhật sang để làm định nghĩa yêu cầu và lắp đặt trông có vẻ tự nhiên, nhưng theo chế độ quản lý xuất nhập cảnh và giấy phép lao động của Thái Lan, có những trường hợp không thể thực hiện như vậy.

Tóm tắt chế độ thì như sau. Người mang hộ chiếu phổ thông của các quốc gia thuộc diện miễn thị thực, trong đó có Nhật Bản, có thể nhập cảnh mà không cần visa cho một khoảng thời gian lưu trú nhất định nếu mục đích là du lịch, đàm phán kinh doanh hay khảo sát. Ngoài ra, từ ngày 15 tháng 7 năm 2024, đã có hướng dẫn vận hành rằng người mang hộ chiếu phổ thông của 93 quốc gia và vùng lãnh thổ thuộc diện miễn thị thực, bao gồm Nhật Bản, có thể thuộc diện miễn thị thực trong một số điều kiện nhất định ngay cả với mục đích làm việc, nếu thời gian lưu trú không quá 15 ngày cho mỗi lần nhập cảnh.

Tuy nhiên, điểm quan trọng là nếu công việc bao gồm cung cấp dịch vụ, hỗ trợ kỹ thuật, lắp đặt trong lãnh thổ Thái Lan, hoặc đóng góp nghiệp vụ trực tiếp cho doanh nghiệp Thái Lan, thì điều đó được coi là làm việc. Khi phát sinh hướng dẫn kỹ thuật hay lao động thực tế có kèm thù lao, hoặc khi cần lưu trú quá 60 ngày, thì bắt buộc phải xin visa Non-Immigrant. Thêm vào đó, từ năm 2025, việc đăng ký trước Chấp thuận nhập cảnh điện tử của Thái Lan (ETA) cũng đang được bắt buộc theo từng bước, kể cả với người nhập cảnh theo diện miễn thị thực.

Tác động của chế độ này lên dự án lớn hơn ta tưởng.

• Nếu kỹ sư người Nhật sang tận nơi để phỏng vấn phục vụ định nghĩa yêu cầu, thủ tục cần thiết sẽ thay đổi tùy số ngày lưu trú và nội dung công việc, nên nếu chốt lịch trước thì thủ tục sẽ không kịp
• Cách vận hành gọi người sang ngắn ngày chỉ khi cần trong quãng nghỉ giữa các giai đoạn phát triển sẽ không khả thi nếu không tính tới thời gian chuẩn bị thủ tục xuất nhập cảnh
• Việc có mặt lúc vận hành chính thức thường là đợt lưu trú dài nhất, nên cần kế hoạch dựa trên tiền đề có giấy phép lao động

Về biện pháp xử lý thực tế, có thể chọn nhà cung cấp có kỹ sư người Nhật thường trú tại chỗ, hoặc phân tách đội hình bằng cách giới hạn sự tham gia của kỹ sư phía Nhật ở khâu rà soát thiết kế và hỗ trợ trực tuyến, còn công việc thực tế tại chỗ do nhân sự của pháp nhân sở tại đảm nhận.

Xin lưu ý rằng các nội dung chế độ ghi ở đây là thông tin xác nhận được tại thời điểm viết bài, và cách vận hành quản lý xuất nhập cảnh cũng như giấy phép lao động có thể thay đổi. Khi lập kế hoạch đi lại thực tế, hãy nhất định xác nhận chế độ mới nhất với đại sứ quán hoặc chuyên gia.

Mùa cao điểm quyết toán tháng 12 và kế hoạch cắt chuyển

Tại Thái Lan có nhiều pháp nhân kết thúc năm tài chính vào tháng 12, nên tháng 12 trở thành mùa cao điểm khi cả các công ty kế toán lẫn công ty kiểm toán đều dồn dập xử lý quyết toán và kiểm toán. Bản thân sự thật này đã được chỉ ra rộng rãi trong các bài giải thích về thực hành kế toán.

Từ đây trở đi không phải là điều được ghi trực tiếp trong nguồn dẫn, mà là suy luận trên phương diện vận hành dự án, nhưng trên thực tế có thể cho rằng an toàn hơn nếu không chọn tháng 12 làm thời điểm vận hành chính thức tức cắt chuyển. Lý do như sau.

Ngay sau khi cắt chuyển là quãng thời gian dữ liệu cũ và mới cùng tồn tại và các xử lý ngoài dự kiến liên tục xuất hiện. Trong thời kỳ này thường xuyên phát sinh tình huống cần hỏi ý kiến phán đoán của bộ phận kế toán. Thế nhưng tháng 12 lại đúng là lúc bộ phận kế toán khó xoay xở nhất vì bận quyết toán. Nếu chồng thêm việc tiếp kiểm toán, họ còn phải trả lời các câu hỏi từ công ty kế toán bên ngoài. Phía hiện trường cũng cạn sức vì xuất hàng dồn dập cuối năm và các đơn hàng gấp trước kỳ nghỉ dài.

Cũng vì lý do đó, khoảng thời gian ngay trước và ngay sau tháng quyết toán, ví dụ từ nửa cuối tháng 11 tới tháng 1 năm sau, cũng đáng được xử lý một cách thận trọng. Việc chuyển đổi vắt qua kỳ kế toán vừa có ưu điểm là có thể bắt đầu bằng hệ thống mới ngay từ đầu kỳ, vừa có cái khó là công việc chốt sổ cuối kỳ và công việc chuyển đổi chồng lên nhau. Chọn phương án nào sẽ thay đổi tùy theo nhân lực của bộ phận kế toán và khối lượng dữ liệu cần chuyển đổi.

Về cách tiến hành thực tế, chúng tôi khuyến nghị ngay từ khâu định nghĩa yêu cầu hãy đề nghị bộ phận kế toán đưa ra lịch của họ, tô kín trước những quãng thời gian họ không thể xoay xở, rồi vạch các mốc quan trọng né tránh những quãng đó. Nếu vạch tiến độ trước rồi mới hỏi kế toán, hầu như lúc nào cũng phải vạch lại.

Cách kiểm tra đội ngũ kỹ sư người Nhật của nhà tích hợp hệ thống bản địa

Số lượng kỹ sư người Nhật có thể hỗ trợ bằng tiếng Nhật tại các nhà tích hợp hệ thống ở Thái Lan là nguồn lực hạn chế ở bất kỳ công ty nào. Trong một ví dụ về cơ cấu nhân sự được một nhà cung cấp bản địa công bố, đội hình gồm 7 nhân viên người Nhật thường trú tại Bangkok và 40 nhân viên người Thái, được cho là hỗ trợ cả tiếng Nhật lẫn tiếng Thái. Đây chỉ là ví dụ của một công ty và không đại diện cho chuẩn mực của ngành, nhưng bản thân cấu trúc trong đó nhân sự người Nhật chỉ chiếm một phần nhỏ trong tổng thể là điểm chung của nhiều nhà tích hợp hệ thống bản địa.

Cấu trúc này gây vấn đề ở giai đoạn định nghĩa yêu cầu. Việc có thể đưa nguyên vẹn sắc thái nghiệp vụ mà người phụ trách ở hiện trường kể bằng tiếng Nhật vào bản thiết kế hay không sẽ quyết định độ chính xác của Fit&Gap. Khi phải qua phiên dịch, ngôn ngữ nghiệp vụ bị trừu tượng hóa một lần và các chi tiết rơi rụng. Chính những phần kiểu như thường thì làm đại khái thế này, còn khi ngoại lệ thì làm thế kia, tức đúng những mảnh đất màu mỡ sinh ra Gap, lại là thứ rơi rụng đầu tiên.

Do đó, khi lựa chọn nhà cung cấp, chúng tôi khuyến nghị xác nhận 3 điểm sau bằng con số. Thứ nhất, có bao nhiêu kỹ sư người Nhật tham gia giai đoạn định nghĩa yêu cầu và với tỷ lệ tham gia bao nhiêu. Thứ hai, nhân sự đó có trùng với người phụ trách ở giai đoạn đề xuất hay không. Thứ ba, đội ngũ tiếp nhận câu hỏi bằng tiếng Nhật trong khâu bảo trì sau vận hành gồm bao nhiêu người và làm việc trong khung giờ nào.

Câu trả lời chúng tôi có thể hỗ trợ tiếng Nhật thì gần như nhà cung cấp nào cũng đưa ra. Thứ có ý nghĩa là những con số phía sau câu trả lời đó, tức tỷ lệ tham gia và số người.

Còn một góc nhìn nữa là tính bền vững của đội ngũ. Theo các bài phân tích về xu hướng lao động sở tại, tại Thái Lan mức lương của kỹ sư IT và lập trình viên đang tăng ở mức 8% đến 12% mỗi năm, cao hơn rõ rệt so với mức 3% đến 5% mỗi năm của lao động phổ thông. Khoảng lương tháng cũng trải rộng từ 35,000 baht tới 80,000 baht, cho thấy đây là thị trường có tính dịch chuyển nhân lực cao. Nếu đặt tiền đề bảo trì dài hạn, rất đáng để xác nhận xem đội ngũ có được tổ chức sao cho không phụ thuộc vào một cá nhân cụ thể hay không.

Có thể dùng AI tạo sinh vào định nghĩa yêu cầu và kiểm thử như thế nào

Gần đây đã xuất hiện xu hướng đưa AI tạo sinh vào công đoạn định nghĩa yêu cầu. Đây vẫn chưa phải là phương pháp đã được xác lập, nhưng vẫn đáng để nhận biết như một khả năng.

Các hình thức ứng dụng được giới thiệu chủ yếu có 2 dạng. Dạng thứ nhất là dùng AI tạo sinh như một người phỏng vấn đối thoại, để từ cuộc trao đổi với bộ phận nghiệp vụ mà sinh ra bản nháp tài liệu định nghĩa yêu cầu. Bộ phận nghiệp vụ tuy quen kể về công việc của mình nhưng lại không quen sắp xếp điều đó thành dạng yêu cầu. Ý tưởng là dùng AI để hỗ trợ phép chuyển đổi đó.

Dạng thứ hai là ứng dụng trong công đoạn rà soát. Cách dùng được nêu ra là chuẩn hóa trước các góc nhìn cần kiểm tra, rồi cho AI tạo sinh đọc tài liệu định nghĩa yêu cầu để rút ra những chỗ ghi chép còn thiếu và những mâu thuẫn giữa các phần mô tả. Có thể cho rằng cách này khá hợp với việc kiểm tra tính nhất quán trong tài liệu, vốn là thứ mà rà soát của con người dễ bỏ sót.

Mặt khác, các vấn đề cũng được chỉ ra rõ ràng. Đầu ra của AI tạo sinh có tính bất định, và nếu áp dụng nguyên xi thì có thể phát sinh sai lệch giữa giả định của bên phát triển và nhu cầu thực tế của hiện trường. Tài liệu định nghĩa yêu cầu do AI sinh ra suy cho cùng chỉ là bản nháp. Nó không thay thế được việc bộ phận nghiệp vụ xác nhận và việc kiểm chứng bằng màn hình thật.

Về công đoạn kiểm thử, có thể nghĩ tới hướng dùng AI để sinh ra các ca kiểm thử. Cách phân công là dựa trên tài liệu định nghĩa yêu cầu và tài liệu thiết kế để liệt kê các tổ hợp đầu vào có thể xảy ra, rồi con người dùng kiến thức nghiệp vụ để chọn lọc. Tuy nhiên điều này cũng vậy, danh sách bao phủ do AI sinh ra chưa chắc đã phản ánh mức độ quan trọng trong nghiệp vụ của doanh nghiệp bạn, nên việc xếp thứ tự ưu tiên vẫn cần do con người thực hiện.

Vào thời điểm hiện tại, cách định vị hợp lý là xem AI tạo sinh như một công cụ để dựng nhanh bản nháp cho định nghĩa yêu cầu và kiểm thử, chứ không phải thứ thay thế cho chính việc phán đoán.

Những thất bại thường gặp và cách phòng tránh

Việc dự án triển khai không kết thúc như mong đợi hoàn toàn không phải chuyện hiếm. Trong Khảo sát thực trạng dự án IT 2018 do Nikkei Computer thực hiện sau 10 năm gián đoạn và được đưa tin vào ngày 27 tháng 2 năm 2018, trong số 1,745 dự án triển khai và đổi mới hệ thống, có 47.2% bị đánh giá là thất bại. Đó là con số cho thấy gần một nửa không đạt được kết quả kỳ vọng.

Cơ cấu chi tiết mà khảo sát này chỉ ra tương ứng chính xác với cấu trúc các giai đoạn đã trình bày từ đầu bài.

Việc lý do đứng đầu khiến không đạt được mức độ hài lòng là định nghĩa yêu cầu không đầy đủ chính là lý do bài viết này dành dung lượng lớn cho giai đoạn 1 và giai đoạn 4. Việc lý do đứng đầu gây vượt chi phí là phát sinh công việc phát triển bổ sung chứng minh rằng phán quyết về add-on trong phân tích Fit&Gap là nguyên nhân chính của chi phí. Việc lý do đứng đầu gây vượt tiến độ là thay đổi đặc tả hệ thống diễn ra liên tiếp cho thấy tầm quan trọng của quản lý thay đổi sau khi đã bước vào giai đoạn phát triển.

Cùng khảo sát đó còn đưa ra một chỉ dẫn quan trọng khác. Đó là những doanh nghiệp mà ban lãnh đạo và bộ phận nghiệp vụ phó mặc hoàn toàn cho nhà cung cấp IT thì khó đưa dự án tới thành công. Cần có người chịu trách nhiệm về nghiệp vụ tham gia dự án, tổng hợp các yêu cầu và theo dõi tiến trình.

Như một dữ liệu bổ sung, bài viết giới thiệu Báo cáo khảo sát xu hướng IT doanh nghiệp 2021 đưa ra số liệu cho thấy tùy quy mô dự án mà có từ 67% đến 85% bị chậm tiến độ và từ 60% đến 85% bị vượt ngân sách. Dù biên độ khác nhau theo quy mô, việc ở bất kỳ mức nào cũng có quá nửa số dự án trải qua chậm tiến độ và vượt ngân sách là tiền đề cần tính tới ngay khi lập kế hoạch.

Dựa trên những điều này, cách phòng tránh theo từng giai đoạn có thể sắp xếp như sau.

• Nhất định phải để người chịu trách nhiệm của bộ phận nghiệp vụ tham gia định nghĩa yêu cầu. Nếu chỉ có người phụ trách hệ thống thông tin làm, kết quả sẽ là một bộ yêu cầu mà hiện trường không hề biết tới.
• Đừng mở rộng phạm vi quá mức ngay từ đầu. Nếu đưa toàn bộ nhà máy và toàn bộ nghiệp vụ vào cùng một lúc, cả khối lượng yêu cầu lẫn số bên liên quan đều tăng vọt, khiến khó giữ được chất lượng định nghĩa yêu cầu. Cách làm bắt đầu từ 1 cơ sở và 1 nghiệp vụ rồi nhân rộng là lựa chọn thực tế để phân tán gánh nặng này.
• Hãy quy đổi kết quả phân tích Fit&Gap ra chi phí và thời gian trước khi quyết định hướng xử lý. Chỉ với danh sách số lượng add-on thì không thể phán đoán được.
• Thiết lập thủ tục phê duyệt cho các thay đổi đặc tả sau khi đã bắt đầu phát triển. Mục đích không phải là cấm thay đổi mà là làm cho thay đổi trở nên nhìn thấy được.
• Văn bản hóa tiêu chí phán quyết vận hành trước khi bắt đầu UAT.

Phân tích chi tiết hơn về các nguyên nhân thất bại và các mẫu hình điển hình đã thực sự xảy ra được chúng tôi trình bày riêng trong bài Nguyên nhân khiến việc triển khai hệ thống quản lý sản xuất thất bại và cách xử lý.

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

Triển khai hệ thống quản lý sản xuất mất khoảng bao lâu?

Vì thay đổi rất nhiều theo phạm vi và độ phức tạp của nghiệp vụ nên khó đưa ra một mức tham khảo chung. Chúng tôi cũng chưa xác nhận được trong thông tin công khai một thống kê đáng tin cậy nào chỉ ra thời lượng tiêu chuẩn của từng giai đoạn. Tuy nhiên, nhiều trường hợp được cho là chỉ riêng khâu định nghĩa yêu cầu đã cần khoảng 3 tháng, và xét việc sau đó còn tiếp nối lựa chọn nhà cung cấp, thiết kế, phát triển, kiểm thử và chuyển đổi, bạn cần dự trù một khoảng thời gian tương xứng. Nếu nhà cung cấp đưa ra thời gian ngắn, hãy xác nhận xem trong khoảng thời gian đó bao gồm những gì và không bao gồm những gì. Không hiếm trường hợp báo giá được lập trên tiền đề bên đặt hàng đã tự hoàn tất định nghĩa yêu cầu.

Bước đầu tiên của việc triển khai nên bắt đầu từ đâu?

Không phải là đi thu thập tài liệu sản phẩm, mà hãy bắt đầu từ việc trực quan hóa nghiệp vụ hiện tại. Đó là công việc viết ra theo từng bộ phận dòng chảy thông tin từ nhận đơn tới xuất hàng. Tại bước này thường lộ ra sự thật rằng không một ai trong công ty nắm được toàn cảnh. Đối chiếu với hiện trạng đã được trực quan hóa, hãy liệt kê xem đang khó khăn ở đâu, rồi chọn lọc trong đó những việc nên giải quyết bằng hệ thống. Nếu làm được tới đây trong nội bộ, chất lượng của cuộc trao đổi với nhà cung cấp sẽ thay đổi rất nhiều.

Nên chấp nhận tùy chỉnh gói phần mềm tới mức nào?

Tiêu chí phán đoán thực tiễn là với từng mục một, hãy tự hỏi cách làm nghiệp vụ đó có liên quan tới sức cạnh tranh của công ty mình hay không. Những thứ ít liên quan thì vẫn còn dư địa chỉnh theo tính năng chuẩn, còn những thứ liên quan mạnh thì đó là Gap đáng đầu tư. Tuy nhiên tại các cơ sở ở Thái Lan, tồn tại những Gap không thể né tránh bằng vận hành, chẳng hạn các yêu cầu về thuế của Thái Lan hay mẫu biểu mà đối tác giao dịch yêu cầu. Nếu tách những thứ này ra thành add-on bắt buộc ngay từ sớm và xử lý riêng với các tùy chỉnh tùy chọn, mọi thứ sẽ mạch lạc hơn. Hãy đưa cả yếu tố càng nhiều tùy chỉnh thì gánh nặng sửa chữa khi nâng cấp phiên bản trong tương lai càng chồng chất vào các căn cứ phán đoán.

Nên chọn thời điểm nào để vận hành chính thức?

Tại Thái Lan có nhiều pháp nhân kết thúc năm tài chính vào tháng 12, nên tháng 12 là mùa cao điểm khi cả công ty kế toán lẫn công ty kiểm toán đều dồn dập xử lý quyết toán và kiểm toán. Ngay sau khi cắt chuyển thường xuyên phát sinh tình huống cần hỏi ý kiến phán đoán của bộ phận kế toán, nên trên thực tế có thể cho rằng an toàn hơn nếu không chọn tháng 12 làm thời điểm vận hành chính thức. Khoảng thời gian trước và sau tháng quyết toán cũng đáng được xử lý thận trọng tương tự. Cách làm thực tế là ngay từ khâu định nghĩa yêu cầu hãy hỏi trước bộ phận kế toán về những quãng thời gian họ không thể xoay xở, rồi vạch các mốc quan trọng né tránh những quãng đó.

Có thể cử kỹ sư của công ty từ Nhật sang công tác để làm công việc triển khai không?

Thủ tục cần thiết sẽ thay đổi tùy số ngày lưu trú và nội dung công việc. Nếu là khảo sát hay đàm phán kinh doanh thì có trường hợp có thể nhập cảnh theo khuôn khổ miễn thị thực, nhưng hỗ trợ kỹ thuật, lắp đặt trong lãnh thổ Thái Lan hay đóng góp nghiệp vụ trực tiếp cho doanh nghiệp Thái Lan đều được coi là làm việc. Khi phát sinh lao động thực tế có kèm thù lao hoặc khi cần lưu trú quá 60 ngày, bắt buộc phải xin visa Non-Immigrant. Từ năm 2025, việc đăng ký trước Chấp thuận nhập cảnh điện tử của Thái Lan (ETA) cũng đang được bắt buộc theo từng bước kể cả với người nhập cảnh diện miễn thị thực. Vì chế độ có thể thay đổi, hãy xác nhận cách vận hành mới nhất trước khi lập kế hoạch đi lại. Nếu chốt lịch trước, có nguy cơ thủ tục sẽ không kịp.

Không có nhân sự IT trong công ty thì có triển khai được không?

Vẫn có thể, nhưng tiền đề là người chịu trách nhiệm phía nghiệp vụ phải chủ động tham gia định nghĩa yêu cầu và phân tích Fit&Gap. Khảo sát của Nikkei Computer cũng chỉ ra rằng những doanh nghiệp mà ban lãnh đạo và bộ phận nghiệp vụ phó mặc hoàn toàn cho nhà cung cấp IT thì khó đưa dự án tới thành công. Phần kỹ thuật có thể giao cho nhà cung cấp, nhưng phán đoán về việc nghiệp vụ của công ty mình nên như thế nào thì không thể thuê ngoài. Thứ bù đắp cho sự thiếu vắng nhân sự IT chính là sự tham gia của người hiểu rõ nghiệp vụ nhất.

Kết luận

Việc triển khai hệ thống quản lý sản xuất tiến hành qua 9 giai đoạn gồm định nghĩa yêu cầu, lựa chọn nhà cung cấp, ký hợp đồng, thiết kế và phân tích Fit&Gap, phát triển và tùy chỉnh, kiểm thử và UAT, chuyển đổi dữ liệu, vận hành chính thức, và ổn định duy trì. Khối lượng công việc cùng sự quan tâm dễ dồn về khâu chọn sản phẩm, nhưng thống kê về thất bại cho thấy một sự thật là thứ quyết định mức độ hài lòng là chất lượng của định nghĩa yêu cầu, thứ quyết định chi phí là phán quyết về add-on trong phân tích Fit&Gap, và thứ quyết định thời gian là các thay đổi đặc tả sau khi đã bắt đầu phát triển.

Và tại các cơ sở ASEAN, còn có thêm 3 ràng buộc. Việc kỹ sư người Nhật đi lại liên quan tới chế độ quản lý xuất nhập cảnh và giấy phép lao động, nên không thể chốt lịch trước. Tháng 12 rơi vào mùa cao điểm quyết toán, nên có thể cho rằng an toàn hơn nếu quyết thời điểm cắt chuyển bằng cách tính ngược từ lịch của bộ phận kế toán. Nhân sự hỗ trợ tiếng Nhật của các nhà tích hợp hệ thống bản địa là nguồn lực hạn chế, nên mức độ tham gia vào định nghĩa yêu cầu cần được xác nhận bằng con số trước khi ký hợp đồng. Ba điểm này là những chỗ mà các dự án bê nguyên cách làm của Nhật Bản sang gần như chắc chắn sẽ vấp phải.

Nói ngược lại, nếu hiểu trước dòng chảy 9 giai đoạn này và 3 ràng buộc đó, triển vọng của dự án sẽ cải thiện rất nhiều. Bước đầu tiên không phải là thu thập tài liệu sản phẩm mà là viết ra nghiệp vụ hiện tại của chính công ty mình.

TOMAS TECH đặt trụ sở tại Bangkok và hỗ trợ triển khai hệ thống quản lý sản xuất PEGASUS cho các doanh nghiệp chế tạo Nhật Bản tại Thái Lan cùng các nước ASEAN. Những vấn đề như cách tiến hành định nghĩa yêu cầu, mức độ có thể hấp thụ bằng tính năng chuẩn trong phân tích Fit&Gap, cơ cấu tham gia của kỹ sư người Nhật hay thiết kế thời điểm cắt chuyển, chính là những thứ đáng được sắp xếp ngay ở giai đoạn cân nhắc, tức trước khi quyết định sản phẩm. Ngay cả khi bạn còn chưa quyết định có triển khai hay không, chúng tôi vẫn có thể cùng bạn lắng nghe các vấn đề hiện tại và suy nghĩ về cách tiến hành. Bạn có thể liên hệ thoải mái qua biểu mẫu liên hệ.

Tài liệu tham khảo

• 生産管理システム導入の流れ｜キッセイコムテック
• ITプロジェクト実態調査2018｜日経クロステック
• 企業IT動向調査報告書2021の紹介記事｜Promapedia
• タイ出張でビザは必要か｜BORDER
• タイのERP・販売管理・生産管理システム｜SMRI
• タイの会計の決算時期について｜東京コンサルティンググループ
• 生成AIを活用した要件定義書作成・レビュー高度化のポイント｜KPMGジャパン
• 中小企業のDXに関する調査結果｜創業手帳
• 2026年版ものづくり白書 5分で掴む最重要ポイント｜テクノア
• ものづくり白書2026を読み解く｜BrainPad DOORS
• 2026年最新版タイ労務・タイ労務管理の最新動向｜東京コンサルティンググループ