Hỗ trợ triển khai phần mềm đóng gói | 4 bước Fit&Gap và 3 lựa chọn xử lý Gap

Công ty đã thống nhất được rằng hệ thống quản lý sản xuất hoặc ERP sẽ được đưa vào bằng phần mềm đóng gói chứ không phát triển từ đầu. Nhưng ngay sau quyết định đó, câu hỏi tiếp theo thường là “dịch vụ hỗ trợ triển khai thì cụ thể làm những gì cho mình”. Hỗ trợ triển khai phần mềm đóng gói không phải là dịch vụ bán phần mềm, mà là dịch vụ đồng hành cho đến khi hệ thống thực sự dùng được trong nghiệp vụ của doanh nghiệp bạn. Bài viết này sắp xếp lại nội dung của dịch vụ đó theo hai trục chính là 4 bước của phân tích Fit&Gap và 3 lựa chọn xử lý Gap, rồi đi tiếp đến những vấn đề riêng có của cơ sở tại Thái Lan.

Hỗ trợ triển khai phần mềm đóng gói là gì | dịch vụ “làm cho dùng được” chứ không phải “bán”

Trước hết cần thống nhất phạm vi mà từ “hỗ trợ triển khai” đang chỉ tới. Nếu nội bộ vẫn hiểu khác nhau mà đã đi lấy báo giá, bạn sẽ không đọc được ý nghĩa của các hạng mục công việc ghi trong đề xuất, và cuối cùng chỉ còn cách so sánh bằng con số lớn nhỏ.

Phạm vi của hỗ trợ triển khai trải từ định nghĩa yêu cầu đến theo dõi sau vận hành

Hỗ trợ triển khai phần mềm đóng gói là công việc nhận trọn gói một chuỗi tác vụ sau khi sản phẩm đã được chọn, gồm định nghĩa yêu cầu, phân tích Fit&Gap, thiết lập cấu hình, thiết kế chuyển đổi dữ liệu, đào tạo hiện trường và theo dõi sau khi hệ thống đi vào vận hành. Đây không phải kiểu bán license rồi xuất phiếu giao hàng là xong.

Khác biệt này hiện ra rất rõ ở phạm vi công việc trong hợp đồng. Nếu chỉ là hợp đồng bán license, thứ được bàn giao là quyền sử dụng phần mềm cùng phần thiết lập ban đầu. Ngược lại, hợp đồng có bao gồm hỗ trợ triển khai sẽ có thêm phần công việc lắng nghe quy trình nghiệp vụ của doanh nghiệp, tách bạch phần nào chạy được bằng chức năng tiêu chuẩn của gói phần mềm và phần nào không, rồi quyết định luôn cách xử lý phần không chạy được.

Nói cách khác, hỗ trợ triển khai không phải là “công việc giao phần mềm” mà là “công việc đưa nghiệp vụ lên phần mềm”. Vì phần mềm đóng gói vốn được làm ra như một sản phẩm dùng chung, nên tự thân nó sẽ không bao giờ khớp hoàn toàn với hình dạng nghiệp vụ của riêng doanh nghiệp bạn. Thiết kế cách lấp khoảng lệch đó chính là vai trò trung tâm của hỗ trợ triển khai.

Ngã rẽ giữa phát triển từ đầu và mua gói có sẵn thì bạn đã đi qua rồi

Ngay tại thời điểm bạn tìm kiếm thông tin về hỗ trợ triển khai, phần lớn người đọc đã vượt qua ngã rẽ “phát triển từ con số không hay mua phần mềm đóng gói có sẵn”. Cân nhắc chi phí và thời gian phát triển xong, cán cân đã nghiêng về phía chọn gói có sẵn. Hoặc danh sách ứng viên đã thu hẹp còn 2 đến 3 sản phẩm. Giai đoạn của bạn là như vậy.

Thông tin cần ở giai đoạn này không phải bảng so sánh chức năng của các sản phẩm, cũng không phải danh mục giá thị trường. Cái cần là câu chuyện về trình tự “làm thế nào để đưa gói phần mềm đã chọn vào trạng thái dùng được trong nghiệp vụ của mình”. Thế nhưng đa số thông tin tìm được lại là giới thiệu sản phẩm hoặc so sánh chức năng, còn thứ giải thích chính bản thân công việc hỗ trợ triển khai thì không nhiều. Bài viết này ra đời để lấp đúng chỗ trống đó.

“Thuê ngoài phát triển hệ thống” và “hỗ trợ triển khai gói phần mềm” khác nhau ở đâu

Một điểm nữa cần làm rõ là khác biệt so với trường hợp thuê ngoài phát triển hệ thống. Hai bên tiến hành với cơ cấu tổ chức khá giống nhau, nhưng thứ tự những việc phải quyết định thì ngược nhau.

Khi thuê ngoài phát triển từ đầu, trước tiên doanh nghiệp viết ra nghiệp vụ của mình thành yêu cầu, rồi thiết kế và xây dựng hệ thống thỏa mãn các yêu cầu đó. Yêu cầu có trước, hệ thống có sau. Ngược lại, với triển khai phần mềm đóng gói thì hệ thống đã hoàn thiện có trước, và nghiệp vụ của doanh nghiệp được đối chiếu vào đó. Hệ thống có trước, việc áp nghiệp vụ vào có sau.

Chính khác biệt về thứ tự này tạo ra khác biệt về nội dung công việc. Trọng tâm của phát triển từ đầu là thiết kế và lập trình, còn trọng tâm của triển khai gói phần mềm là “đối chiếu” và “quyết định cách xử lý phần chênh lệch”. Và cái tên gắn cho công việc đối chiếu ấy chính là phân tích Fit&Gap.

Hai dòng cuối của bảng này là phần bài viết muốn nhấn mạnh nhất. Chọn phần mềm đóng gói không có nghĩa là chi phí trở nên dễ đọc hơn, mà chỉ là con đường khiến chi phí phình ra đã chuyển sang một chỗ khác. Đó là cảm nhận từ thực tế triển khai.

Vì sao cần hỗ trợ triển khai | nguyên nhân vấp ngã không nhất thiết là thiếu chức năng

Chuyện dự án triển khai phần mềm đóng gói không đi đúng kế hoạch là không hiếm. Chậm ngày go-live, vượt ngân sách, hoặc chạy được nhưng hiện trường không dùng. Khi kết cục như vậy xảy ra, nội bộ hay tổng kết rằng “sản phẩm chọn sai” hoặc “chức năng không đủ”.

Từ đây là quan sát thực tế của chúng tôi qua các dự án đã đồng hành. Khi nhìn lại các dự án, số trường hợp mà nguyên nhân thực sự nằm ở việc sản phẩm thiếu chức năng lại không nhiều như người ta tưởng. Thứ hay gặp hơn là dòng chảy sau đây: triển khai mà chưa đối chiếu đầy đủ giữa nghiệp vụ và hệ thống, đến sát ngày go-live hoặc sau khi go-live thì các khoảng lệch lần lượt lộ ra, và mỗi lần như vậy lại phải đặt hàng phát triển bổ sung.

Thất bại điển hình là triển khai mà bỏ qua phân tích Fit&Gap

Phân tích Fit&Gap được xem là phương pháp phân tích so sánh nghiệp vụ hiện hành cùng các yêu cầu của doanh nghiệp với chức năng của hệ thống sắp đưa vào, để bóc tách ra điểm phù hợp là Fit và điểm chênh lệch là Gap. Tên gọi nghe có vẻ khó, nhưng việc đang làm thì đơn giản là đối chiếu nghiệp vụ với hệ thống.

Bỏ qua công đoạn này thì chuyện gì xảy ra, cứ lần theo trình tự sẽ thấy. Đầu tiên, tại thời điểm ký hợp đồng, báo giá được lập trên giả định mọi thứ chạy bằng chức năng tiêu chuẩn. Tiếp theo, khi bước vào giai đoạn thiết lập cấu hình, từng khoảng lệch riêng lẻ bắt đầu lộ ra kiểu “mẫu chứng từ này khác”, “luồng phê duyệt này không tái hiện được”. Ở thời điểm đó ngày go-live đã ấn định, không còn thời gian để bàn chuyện thay đổi nghiệp vụ, nên quyết định thường là xử lý bằng phát triển bổ sung. Và vì phần phát triển bổ sung này không nằm trong báo giá ban đầu, toàn bộ trở thành chi phí phát sinh thêm.

Điều quan trọng là trong dòng chảy này không có chỗ nào là “ác ý” hay “làm ẩu”. Cả bên triển khai lẫn bên được triển khai, tại mỗi thời điểm đều hành động hợp lý. Vậy mà chi phí vẫn phình ra, bởi đó là vấn đề về cấu trúc, khi công đoạn bóc tách khoảng lệch đã không được đặt ở phía trước.

Chi phí tùy chỉnh không phải là khoản chi chỉ của năm phát sinh

Một điểm nữa cần nắm là bản chất của chi phí tùy chỉnh. Chi phí phát triển bổ sung trông giống một khoản chi chỉ xảy ra một lần trong năm đó, nhưng thực tế không phải vậy.

Phần mềm đóng gói được nhà cung cấp phát hành bản nâng cấp định kỳ. Nếu bạn chỉ vận hành bằng chức năng tiêu chuẩn, việc nâng cấp về cơ bản khép lại ở phía nhà cung cấp. Nhưng nếu đang mang theo phần phát triển bổ sung của riêng mình, thì mỗi lần nâng cấp lại phát sinh việc kiểm chứng xem phần bổ sung đó có chạy trên phiên bản mới hay không, và nếu không chạy thì phải sửa lại.

Nói cách khác, tùy chỉnh kéo theo không chỉ chi phí phát triển lần đầu mà còn cả chi phí kiểm chứng và chi phí sửa chữa cho từng lần nâng cấp về sau. Cấu trúc ở đây là khoản phát triển bổ sung mà bạn phê duyệt lúc triển khai với suy nghĩ “mức tiền này thì chấp nhận được” đang quyết định mặt bằng chi phí bảo trì của 5 năm sau.

Cũng có những gói phần mềm được thiết kế để không cần tùy chỉnh

Mặt khác, phía nhà cung cấp gói phần mềm cũng có cách ứng phó với vấn đề này. Có ý kiến cho rằng trong các gói ERP nội địa dành cho doanh nghiệp vừa và nhỏ, có sản phẩm chuyên biệt cho một loại hình kinh doanh nhất định, tích hợp sẵn các nghiệp vụ cần thiết của loại hình đó vào gói cơ bản, nhờ vậy được thiết kế theo hướng không đòi hỏi tùy chỉnh đặc biệt.

Nếu loại hình kinh doanh của doanh nghiệp trùng với loại hình mà sản phẩm giả định, số lượng Gap vốn dĩ đã ít. Ngược lại, nếu chọn sản phẩm có tính đa dụng cao rồi kéo nó về phía loại hình của mình, số Gap sẽ nhiều lên nhưng đổi lại phạm vi áp dụng rộng hơn. Đây không phải chuyện bên nào tốt hơn, mà là lựa chọn giữa lượng Gap và độ linh hoạt.

Cách đi đáng tránh nhất là chọn sản phẩm mà không ý thức về lựa chọn này, để rồi về sau giật mình vì số lượng Gap. Chính vì vậy, ngay từ giai đoạn thu hẹp danh sách sản phẩm, bạn cần biết trước tư duy của phân tích Fit&Gap.

Bốn bước của phân tích Fit&Gap | nội dung hỗ trợ triển khai tập trung ở đây

Từ đây là phần lõi của bài viết. Câu trả lời thực chất nhất cho câu hỏi dịch vụ hỗ trợ triển khai cụ thể làm gì chính là 4 bước của phân tích Fit&Gap này. Phân tích Fit&Gap được cho là tiến hành theo 4 bước gồm nắm bắt hiện trạng, khảo sát chức năng hệ thống, đánh giá mức độ phù hợp và quyết định phương án xử lý. Ta đi lần lượt.

Bước 1 | Nắm bắt hiện trạng. Bóc tách quy trình nghiệp vụ của toàn bộ các bộ phận

Bước đầu tiên là nắm bắt hiện trạng. Bóc tách quy trình nghiệp vụ của toàn bộ các bộ phận, lập lưu đồ nghiệp vụ và danh sách yêu cầu.

Chìa khóa ở đây nằm ở chữ “toàn bộ các bộ phận”. Với hệ thống quản lý sản xuất thì trung tâm là bộ phận sản xuất, mua hàng và quản lý sản xuất, nhưng trên thực tế bộ phận đảm bảo chất lượng, xuất hàng và kế toán cũng đang gánh một phần của quy trình. Nếu chỉ lấy yêu cầu từ các bộ phận trung tâm, nghiệp vụ của những bộ phận xung quanh sẽ bị bỏ lại bên ngoài hệ thống, và sau khi go-live vẫn còn nguyên các thao tác phụ trợ bằng Excel.

Một chuyện nữa rất hay xảy ra ở bước nắm bắt hiện trạng là “quy trình nghiệp vụ đã được văn bản hóa khác với trình tự mà hiện trường đang thực sự làm”. Lưu đồ thì có, nhưng là bản của vài năm trước và chưa phản ánh các cải tiến sau đó. Hoặc mỗi người phụ trách lại làm hơi khác nhau một chút. Lập danh sách yêu cầu trong tình trạng này đồng nghĩa với thiết kế hệ thống theo một nghiệp vụ không tồn tại.

Thứ nên kỳ vọng ở công ty hỗ trợ triển khai không phải là việc nhận tài liệu sẵn có rồi chép sang danh sách yêu cầu, mà là việc họ xuống hiện trường xác nhận trình tự thực tế và chỉ ra chỗ lệch so với tài liệu. Công đoạn này có được bố trí người và thời gian hay không, bạn có thể phán đoán qua bảng phân rã công việc trong đề xuất.

Bước 2 | Khảo sát chức năng hệ thống. Kiểm chứng tính thao tác và khả năng cấu hình qua demo

Bước thứ hai là khảo sát chức năng của hệ thống sắp đưa vào. Ở đây không chỉ đọc thông tin sản phẩm, mà được cho là nên xác nhận cả tính thao tác thực tế và khả năng thiết lập cấu hình thông qua demo hoặc buổi giới thiệu.

Chuyện catalogue hay danh mục chức năng ghi là “có hỗ trợ” nhưng thực tế lại không chịu nổi vận hành là không hiếm. Ví dụ dù ghi là có hỗ trợ quản lý lô, nếu đặc tả bắt nhập tay số lô ở màn hình nhập liệu từng lần một, thì hiện trường phải đăng ký vài trăm bản ghi kết quả mỗi ngày sẽ không dùng. Dù ghi là hỗ trợ đa ngôn ngữ, cũng có trường hợp màn hình thì được dịch nhưng tên hàng đăng ký trong master chỉ giữ được một ngôn ngữ.

Vì vậy, thứ cần xác nhận ở bước này không phải là có hay không có chức năng, mà là 3 điểm sau. Thứ nhất, số thao tác mà nhân viên hiện trường thực sự phải làm khi dùng chức năng đó. Thứ hai, phạm vi có thể điều chỉnh theo vận hành của doanh nghiệp bằng màn hình cấu hình. Thứ ba, ranh giới mà cấu hình không với tới và bắt buộc phải phát triển nằm ở đâu.

Điểm thứ ba đặc biệt quan trọng. Nếu không nhìn ra ranh giới giữa việc xử lý được bằng cấu hình và việc buộc phải phát triển, bạn sẽ không thể phán đoán được sức nặng của các Gap xuất hiện ở bước tiếp theo.

Bước 3 | Đánh giá mức độ phù hợp. Ghi lại Fit/Gap và mức độ ảnh hưởng tới nghiệp vụ

Bước thứ ba là đánh giá mức độ phù hợp. Đối chiếu yêu cầu nghiệp vụ với chức năng hệ thống để xác định đâu là Fit, đâu là Gap. Và với các Gap, được cho là phải ghi lại cả lý do chênh lệch lẫn mức độ ảnh hưởng tới nghiệp vụ.

Nội dung được ghi lại ở đây chính là phần có giá trị nhất trong các sản phẩm bàn giao của hỗ trợ triển khai. Không đơn thuần lập danh sách “có hỗ trợ” và “không hỗ trợ”, mà lưu lại theo từng yêu cầu vì sao không khớp, và nếu để nguyên không khớp thì nghiệp vụ sẽ gặp trở ngại gì. Chính nhờ bản ghi này mà ở bước kế tiếp bạn mới phán đoán được nên “đổi nghiệp vụ hay đi phát triển”.

Hình thức bản ghi dùng trong thực tế có độ chi tiết đại khái như sau.

Các yếu tố được nêu như là điểm mấu chốt để thành công gồm việc lôi kéo nhân viên hiện trường của toàn bộ các bộ phận vào cuộc, việc gắn mức ưu tiên bắt buộc hay mong muốn cho từng yêu cầu, việc cân nhắc xem liên kết với hệ thống hiện có có cần phát triển bổ sung phần kết nối dữ liệu hay không, và việc mô tả yêu cầu cụ thể đến cả màn hình, nhập liệu, xử lý và kết xuất.

Trong số đó, thứ phát huy tác dụng nhất trong thực tế là phân biệt bắt buộc với mong muốn. Nếu lập danh sách mà không phân biệt, mọi yêu cầu sẽ nằm cạnh nhau với cùng một sức nặng, kết quả là muốn đáp ứng tất cả và chi phí phình ra. Ngược lại, khi đã tách bắt buộc và mong muốn, những yêu cầu được xếp vào nhóm mong muốn sẽ dễ đi tới quyết định “kéo vận hành về hình thức làm được trong phạm vi chức năng tiêu chuẩn”.

Liên kết với hệ thống hiện có cũng là hạng mục hay bị bỏ sót. Nếu không bóc tách ngay ở giai đoạn này việc trao đổi dữ liệu nào với các hệ thống xung quanh như kế toán, chấm công hay quản lý tồn kho sẵn có, thì toàn bộ chi phí phát triển phần liên kết sẽ nằm ngoài báo giá.

Bước 4 | Quyết định phương án xử lý. Chọn từ ba lựa chọn

Bước cuối cùng là quyết định phương án xử lý. Với từng Gap đã bóc tách, bạn chọn phương án tối ưu trong 3 hướng gồm thay đổi quy trình nghiệp vụ, tùy chỉnh hệ thống, hoặc dùng kèm công cụ khác.

Điều quan trọng ở đây là nhận thức rằng bản thân việc phát hiện ra Gap không phải là thất bại. Phần mềm đóng gói là sản phẩm dùng chung, nên gần như không bao giờ có chuyện Gap bằng không. Cái thành vấn đề là đi tiếp mà không phát hiện ra Gap, và là việc tự động chọn tùy chỉnh cho Gap đã phát hiện mà không xem xét các lựa chọn khác.

Trục phán đoán cho ba lựa chọn này là chủ đề trung tâm của bài viết, nên chúng tôi tách ra thành một chương riêng để bàn kỹ.

Ba lựa chọn khi phát hiện Gap và trục phán đoán

Sau khi phân tích Fit&Gap đã bóc tách xong các Gap, việc tiếp theo là quyết định cách xử lý chúng. Trong triển khai gói ERP, các phương án ứng phó với Gap thường được nêu ra gồm 3 lựa chọn là tùy chỉnh gói phần mềm, phát triển add-on cho chức năng còn thiếu, và thay đổi quy trình nghiệp vụ theo chức năng tiêu chuẩn của gói. Bên cạnh đó, ở bước quyết định phương án xử lý của phân tích Fit&Gap, được cho là chọn từ 3 hướng gồm thay đổi quy trình nghiệp vụ, tùy chỉnh hệ thống và tận dụng công cụ khác.

Để dễ phán đoán trong thực tế, bài viết này gộp tùy chỉnh và phát triển add-on vốn có tính chất gần nhau làm một, rồi cộng thêm việc dùng kèm công cụ khác, thành ba lựa chọn.

Lựa chọn 1 | Thay đổi quy trình nghiệp vụ theo chức năng tiêu chuẩn

Lựa chọn đầu tiên là thay đổi phía nghiệp vụ chứ không phải hệ thống. Về mặt chi phí, đây là phương án nhẹ nhất, và về mặt bảo trì sau vận hành cũng là phương án gánh nặng nhỏ nhất.

Đổi lại, độ khó khi thực thi lại cao nhất trong ba lựa chọn. Bạn cần hiện trường chấp nhận thay đổi trình tự làm việc, phải giải thích lý do thay đổi, đào tạo lại và theo sát cho đến khi cách làm mới bám rễ. Nói cho đúng thực tế thì đây là phương án ít tốn tiền nhưng tốn công điều phối trong nội bộ.

Câu hỏi mà chúng tôi hay dùng trong thực tế để làm mốc phán đoán là “bạn có giải thích được vì sao trình tự này lại như vậy không”. Những trình tự có căn cứ từ pháp luật hoặc yêu cầu của khách hàng thì không đổi được. Nhưng nếu lý do chỉ là “xưa nay vẫn làm thế” hay “người tiền nhiệm bàn giao lại kiểu đó”, thì khả năng kéo về chức năng tiêu chuẩn là có. Nếu ở bước nắm bắt hiện trạng bạn đã hỏi luôn cả lý do của từng trình tự, phán đoán này sẽ nhanh hơn nhiều.

Lựa chọn 2 | Lấp bằng tùy chỉnh và phát triển add-on

Lựa chọn thứ hai là động vào phía gói phần mềm. Gồm tùy chỉnh để thay đổi hành vi của chức năng sẵn có, và phát triển add-on để bổ sung chức năng còn thiếu.

Vì không phải thay đổi nghiệp vụ nên sức phản kháng từ hiện trường nhỏ, và trong ngắn hạn đây trông như lựa chọn ít ma sát nhất. Chính vì thế cần lưu ý rằng người ta rất dễ trôi tự động về phương án này mà chưa xem xét thấu đáo.

Như đã đề cập ở chương trước, chi phí của lựa chọn này không dừng lại ở khoản phát triển lần đầu. Mỗi lần nâng cấp phiên bản lại phát sinh việc kiểm chứng hoạt động của phần phát triển bổ sung, và tùy theo thay đổi đặc tả phía chức năng tiêu chuẩn mà có khi phải làm lại. Càng chồng thêm tùy chỉnh, chi phí bảo trì sau vận hành càng tăng lên về mặt cấu trúc. Về việc sau khi go-live sẽ phát sinh liên tục những khoản chi phí nào, chúng tôi đã sắp xếp phần cơ cấu chi tiết trong bài chi phí bảo trì hệ thống nghiệp vụ đang được trả cho những hạng mục nào, nên trước khi quyết định có tùy chỉnh hay không, bạn nên đọc qua một lượt.

Về cách nhìn tổng thể chi phí lúc triển khai, bạn cũng cần nắm được ngoài phí license thì còn những khoản nào cộng thêm. Lấy hệ thống quản lý sản xuất làm ví dụ, cơ cấu các khoản phát sinh ngoài license được tổng hợp trong bài chi phí hệ thống quản lý sản xuất còn gồm những gì ngoài phí license. Khi đưa chi phí xử lý Gap vào báo giá, việc rà theo khung này sẽ giúp bạn bớt bỏ sót hạng mục.

Lựa chọn 3 | Dùng kèm công cụ khác để xử lý ở bên ngoài

Lựa chọn thứ ba là không động vào thân gói phần mềm, chỉ tách riêng nghiệp vụ đó ra xử lý bằng một công cụ khác. Bao gồm cả công cụ lập biểu mẫu, công cụ BI, hoặc giữ nguyên phần xử lý bằng Excel sẵn có.

Lựa chọn này phát huy hiệu quả khi Gap không nằm ở lõi nghiệp vụ mà nằm ở vùng ngoại vi. Ví dụ với Gap chỉ ở mức mẫu bảng tổng hợp nộp riêng cho một khách hàng nhất định mà chức năng biểu mẫu tiêu chuẩn không tạo được, thì kết xuất dữ liệu ra rồi định dạng bằng công cụ khác sẽ rẻ và nhanh hơn.

Điều cần lưu ý là đừng tạo ra trạng thái dữ liệu tồn tại trùng lặp ở hai nơi. Nếu chỉ lấy dữ liệu kết xuất từ gói phần mềm rồi gia công bằng công cụ khác thì không vấn đề gì, nhưng nếu để phía công cụ khác cũng nhập và cập nhật dữ liệu, sẽ sinh ra tình trạng không biết bên nào mới đúng. Khi dùng kèm, hãy xác định trước nguyên tắc giới hạn nơi nhập dữ liệu chỉ ở một chỗ duy nhất.

So sánh ba lựa chọn

Đặt tính chất của ba lựa chọn cạnh nhau, các trục cần nhìn khi phán đoán sẽ hiện ra rõ ràng.

Cách vận dụng bảng này trong thực tế là lập danh sách Gap trước, chỉ giữ lại làm ứng viên tùy chỉnh những Gap vừa là yêu cầu bắt buộc vừa nằm ở lõi nghiệp vụ, còn lại thì xem xét trước xem có xử lý được bằng thay đổi nghiệp vụ hoặc dùng kèm công cụ khác hay không. Nếu làm ngược thứ tự, cả những Gap vốn còn dư địa cân nhắc cũng bị đưa vào diện phát triển.

Chúng tôi cho rằng năng lực của công ty hỗ trợ triển khai bộc lộ rõ nhất chính ở cách họ trình bày ba lựa chọn này. Giữa một công ty chỉ đưa ra báo giá phát triển cho mỗi Gap, và một công ty bày ra cả ảnh hưởng khi đổi nghiệp vụ lẫn cấu hình khi xử lý bằng công cụ khác, tổng mức đầu tư cuối cùng sẽ khác nhau.

Những vấn đề riêng có của hỗ trợ triển khai phần mềm đóng gói tại cơ sở Thái Lan

Từ đây chúng ta kéo câu chuyện về hiện trường Thái Lan. So với triển khai trong nội địa Nhật Bản, việc triển khai gói phần mềm tại cơ sở Thái Lan có một số điều kiện riêng.

Thị trường hỗ trợ triển khai ERP tại Thái Lan có biên độ lựa chọn rất rộng

Tại Thái Lan, nhiều đối tác ERP toàn cầu đang hoạt động hướng tới doanh nghiệp sản xuất vừa và nhỏ. Với Odoo, có đối tác bản địa đã đạt chứng nhận ISO 29110 và hỗ trợ triển khai cùng việc đáp ứng chế độ thuế địa phương. Với SAP Business One cũng có đối tác thực hiện hỗ trợ triển khai. Với Microsoft Dynamics 365 thì có đối tác sở hữu license hỗ trợ việc triển khai. Ngoài ra còn có các nhà cung cấp bản địa và nhà cung cấp IT Nhật Bản phục vụ doanh nghiệp Nhật.

Lập trường của bài viết này là không so sánh xem sản phẩm nào hay đối tác nào ưu việt hơn. Điều mong bạn nắm là quy mô và mặt bằng chi phí của cái dịch vụ được gọi chung bằng một cụm từ “hỗ trợ triển khai ERP” lại khác nhau rất lớn giữa các nhà cung cấp. Đối tác của sản phẩm toàn cầu và nhà cung cấp bản địa khác nhau cả về cơ cấu nhân sự lẫn phạm vi công việc tiêu chuẩn.

Do đó, khi lấy báo giá từ nhiều bên, trước khi so sánh con số bạn cần làm cho thống nhất câu hỏi “trong con số đó đã bao gồm những công việc nào”. Đặc biệt, nhất định phải xác nhận xem phân tích Fit&Gap có được ghi rõ như một hạng mục công việc hay chỉ được ngầm gộp vào phần định nghĩa yêu cầu.

Gap giữa hệ thống chuẩn của trụ sở Nhật Bản và yêu cầu bản địa tại cơ sở Thái Lan

Phần này là quan điểm từ thực tiễn của chúng tôi. Ở cơ sở Thái Lan của các nhà máy Nhật Bản, cấu trúc Fit&Gap khác một bậc so với triển khai trong nội địa Nhật. Lý do là đối tượng đem ra so sánh không phải một cặp gồm “chức năng tiêu chuẩn của gói phần mềm và nghiệp vụ của doanh nghiệp”, mà là bộ ba gồm “hệ thống chuẩn của trụ sở Nhật Bản”, “nghiệp vụ thực tế tại cơ sở Thái Lan” và “chức năng tiêu chuẩn của gói phần mềm”.

Khi trụ sở đã chọn một gói phần mềm làm chuẩn toàn tập đoàn, đôi khi sẽ có chủ trương triển khai đúng sản phẩm đó xuống cơ sở Thái Lan. Bản thân chủ trương này là hợp lý. Tuy nhiên, nếu triển khai nguyên xi, Gap sẽ nảy sinh giữa nó với các yêu cầu bản địa phía Thái Lan. Điển hình là các biểu mẫu liên quan tới thuế, màn hình và biểu mẫu bằng ngôn ngữ bản địa, cùng dòng chảy chứng từ bắt nguồn từ tập quán kinh doanh địa phương.

Rắc rối hơn nữa là trường hợp quyền phán quyết về các Gap này nằm ở trụ sở, còn cơ sở tại chỗ không có quyền quyết định. Cơ sở phát hiện ra Gap nhưng không thể tự quyết việc phá vỡ chuẩn của trụ sở, trong khi yêu cầu pháp luật tại chỗ lại không thể nhượng bộ. Chúng tôi đã chứng kiến những dự án dừng lại vì thế kẹt này.

Biện pháp chúng tôi khuyến nghị là ngay ở bước đánh giá mức độ phù hợp của phân tích Fit&Gap, hãy ghi chép Gap theo hai nhóm tách bạch, một là “Gap bắt nguồn từ pháp luật và chế độ thuế đặc thù của địa phương”, hai là “Gap bắt nguồn từ tập quán vận hành tại chỗ”. Nhóm thứ nhất là đối tượng cần xử lý riêng như một phương án đáp ứng địa phương mà không phá vỡ chuẩn của trụ sở, còn nhóm thứ hai là đối tượng còn dư địa thương lượng để kéo về chuẩn của trụ sở. Nếu trộn lẫn hai nhóm rồi trình lên trụ sở, cuộc thảo luận sẽ biến thành thế đối đầu giữa “sự tùy tiện của cơ sở tại chỗ” và “sự áp đặt của trụ sở”, khiến việc ra quyết định kéo dài.

Có hay không hỗ trợ bằng ngôn ngữ bản địa sẽ quyết định mức độ bám rễ

Một vấn đề nữa cực kỳ lớn trong thực tế là hỗ trợ bằng ngôn ngữ bản địa. Trong hỗ trợ triển khai, phân tích Fit&Gap và định nghĩa yêu cầu thường được tiến hành bằng tiếng Nhật và tiếng Anh, nhưng người sử dụng hệ thống hằng ngày lại là nhân viên bản địa.

Cứ nghĩ tới tình huống đào tạo là thấy rõ. Nếu buổi huấn luyện thao tác chỉ diễn ra bằng tiếng Anh, số người hiểu được nội dung chỉ giới hạn ở một bộ phận nhân viên, số còn lại sẽ nhìn cách làm của người bên cạnh mà bắt chước. Go-live trong trạng thái đó nghĩa là vận hành bắt đầu khi trình tự nhập liệu đúng chưa được truyền đạt, và chất lượng dữ liệu sẽ không ổn định.

Việc tiếp nhận thắc mắc sau go-live cũng vậy. Khi hiện trường có nghi vấn mà không có đầu mối để hỏi bằng ngôn ngữ bản địa, thì bản thân câu hỏi sẽ không còn xuất hiện nữa. Bên triển khai nên đặt nghi vấn rằng việc không có câu hỏi không phải vì mọi thứ đang suôn sẻ, mà vì người ta đã bỏ cuộc.

Vì vậy, khi chọn công ty hỗ trợ triển khai, hãy xác nhận trước khi ký hợp đồng rằng tài liệu hướng dẫn và chương trình đào tạo có được cung cấp bằng ngôn ngữ bản địa hay không, và đầu mối tiếp nhận ban đầu sau go-live có nhân sự xử lý được bằng ngôn ngữ bản địa hay không. Chúng tôi cho rằng đây không phải là sự tiện nghi mang tính tùy chọn, mà là điều kiện quyết định khoản đầu tư có thu hồi được hay không.

Về chế độ hỗ trợ chuyển đổi số dành cho SME tại Thái Lan

Về mặt chi phí, được cho là có tồn tại các chế độ hỗ trợ chuyển đổi số dành cho doanh nghiệp vừa và nhỏ tại Thái Lan. Chương trình d-transform của DEPA, tức Cơ quan Xúc tiến Kinh tế Số Thái Lan, là một trong số đó, và được cho là có khung hỗ trợ một phần chi phí năm đầu tiên dành cho doanh nghiệp vừa và nhỏ có doanh thu năm không quá 300 triệu baht. Mô tả này dựa trên bài viết blog của một nhà cung cấp kinh doanh sản phẩm ERP cụ thể, nên với các chi tiết của chế độ bao gồm tỷ lệ hỗ trợ và mức trần, bạn nhất định phải tự mình kiểm tra bản tóm tắt chế độ chính thức và thông báo mời nộp hồ sơ mới nhất.

Xin giới thiệu thêm tình hình tại nội địa Nhật Bản để tham khảo. Với các doanh nghiệp sản xuất vừa và nhỏ của Nhật Bản làm hàng theo đơn đặt hàng và có quy mô từ 10 đến 200 nhân viên, chi phí triển khai hệ thống quản lý sản xuất dạng đóng gói được xem là ở mức khoảng từ 100 vạn yên đến 500 vạn yên, và nếu triển khai theo từng giai đoạn thì được cho là có thể khởi động từ mức 100 vạn yên. Ngoài ra, một chế độ có thể tận dụng ở thời điểm năm 2026 được nêu ra là khoản trợ cấp cho chuyển đổi số và ứng dụng AI.

Lưu ý rằng mặt bằng chi phí tại nội địa Nhật Bản và mặt bằng chi phí của ERP đám mây tại Thái Lan không thể đem so sánh trực tiếp, vì khác nhau cả về đơn vị tiền tệ lẫn phạm vi đối tượng. Khi giải trình ngân sách của cơ sở Thái Lan với trụ sở Nhật Bản, cách chắc chắn là đừng mang nguyên mặt bằng giá của Nhật sang, mà hãy giải thích dựa trên bảng phân rã công việc trong báo giá lấy được tại địa phương.

Những điểm cần xác nhận khi chọn công ty hỗ trợ triển khai

Chúng tôi quy nội dung từ đầu bài đến đây thành các hạng mục xác nhận khi chọn bên nhận việc.

Họ có thực hiện phân tích Fit&Gap như một hạng mục công việc không

Điều đầu tiên cần xác nhận là phân tích Fit&Gap có được ghi rõ như một hạng mục công việc trong đề xuất hay không. Nếu nó không được viết ra thành tên công đoạn, khả năng là công việc đó chưa được phân bổ nhân công.

Về cách xác nhận, hỏi 3 câu sau đây là thực tế nhất. Để nắm bắt hiện trạng thì sẽ phỏng vấn bao nhiêu bộ phận trong bao nhiêu ngày. Sản phẩm bàn giao của bước đánh giá mức độ phù hợp là danh sách theo định dạng nào. Trong danh sách đó có ghi mức độ ảnh hưởng tới nghiệp vụ của từng Gap hay không. Công ty trả lời cụ thể được 3 điểm này là công ty thực sự đang vận hành công đoạn đó.

Ngoài ra, về cách tiến hành ở giai đoạn trước phân tích Fit&Gap, tức giai đoạn sắp xếp yêu cầu để chọn bên nhận việc, chúng tôi đã trình bày trong bài vì sao báo giá hệ thống quản lý sản xuất chênh nhau tới 3 lần khi lập RFP. Nếu bên nhận việc còn chưa chốt, thì việc bạn viết gì trong RFP sẽ thay đổi chất lượng các đề xuất nhận được, nên xét về trình tự, đọc bài đó trước là hợp lý.

Họ có đưa ra nhiều lựa chọn xử lý Gap không

Thứ hai, khi phát hiện Gap thì họ chỉ đưa báo giá tùy chỉnh, hay trình bày cả các lựa chọn bao gồm thay đổi quy trình nghiệp vụ và dùng kèm công cụ khác.

Điểm này cũng là phần khó phán đoán ở giai đoạn đề xuất. Một cách nhận biết là hãy hỏi xem trong các dự án đã triển khai trước đây, họ có giải thích cụ thể được “trường hợp đã thay đổi phía nghiệp vụ để xử lý Gap” hay không. Công ty kể được thành tích với tư cách dự án phát triển nhưng lại không có trường hợp nào giải quyết bằng cách đổi nghiệp vụ, thì nhiều khả năng tùy chỉnh đã là tiền đề mặc định của họ.

Hình thức hợp đồng và phạm vi công việc có rõ ràng không

Thứ ba là hình thức hợp đồng. Hỗ trợ triển khai là sự pha trộn giữa những công đoạn dễ định nghĩa sản phẩm bàn giao và những công đoạn mang tính đồng hành, khó định nghĩa sản phẩm bàn giao. Thông thường nhóm trước theo hình thức khoán việc, nhóm sau theo hình thức ủy thác công việc, nhưng nếu ký hợp đồng khi vẫn mơ hồ công đoạn nào thuộc nhóm nào, sẽ phát sinh khác biệt nhận thức về điều kiện làm phát sinh chi phí bổ sung.

Về phạm vi trách nhiệm của từng loại hợp đồng và cách nhìn tiêu chuẩn nghiệm thu, chúng tôi đã sắp xếp chi tiết trong bài thực tiễn hợp đồng khoán việc và ủy thác công việc khi thuê ngoài phát triển hệ thống. Ở giai đoạn rà soát hợp đồng hỗ trợ triển khai, hãy để bài đó bên cạnh và đối chiếu loại hợp đồng cùng điều kiện nghiệm thu của từng công đoạn.

Có hệ thống hỗ trợ bằng ngôn ngữ bản địa không

Thứ tư là phần hỗ trợ bằng ngôn ngữ bản địa đã nói ở chương trước. Hãy xác nhận với cả 3 thứ gồm tài liệu hướng dẫn, chương trình đào tạo và đầu mối tiếp nhận thắc mắc sau go-live, rằng mỗi thứ được cung cấp bằng ngôn ngữ nào. Đừng dừng ở câu trả lời “có thể đáp ứng”, mà hãy hỏi sâu tới mức nhân sự phụ trách có thường trú hay phải điều động theo từng lần, khi đó thực trạng sẽ lộ ra.

Phạm vi theo dõi sau vận hành đã được định nghĩa chưa

Thứ năm là giai đoạn sau vận hành. Hợp đồng hỗ trợ triển khai kết thúc ngay ngày go-live hay bao gồm cả một khoảng thời gian sau đó, điều này làm thay đổi rất lớn gánh nặng thực tế.

Ngay sau go-live, chắc chắn sẽ xuất hiện những tình huống nghiệp vụ không lường trước. Đơn hàng bất thường, xử lý cuối tháng đầu tháng, kiểm kê cuối kỳ. Những việc này chỉ phát sinh sau vài tuần đến vài tháng kể từ khi go-live, nên nếu hợp đồng kết thúc đúng ngày go-live, bạn sẽ rơi vào trạng thái không có chỗ hỏi đúng lúc cần hỗ trợ nhất. Tối thiểu, chúng tôi khuyến nghị đưa vào phạm vi hỗ trợ đến khi đi qua kỳ xử lý theo tháng đầu tiên và đợt kiểm kê đầu tiên.

Danh sách kiểm tra xem có đúng với doanh nghiệp bạn không

Đây là các hạng mục để xác nhận việc cân nhắc hỗ trợ triển khai của bạn đang ở giai đoạn nào. Chúng tôi để ở độ chi tiết có thể mang thẳng vào cuộc họp nội bộ.

• Với gói phần mềm đang là ứng viên, bạn có liệt kê được thành danh sách các nghiệp vụ cần xác nhận là chạy được bằng chức năng tiêu chuẩn hay không
• Quy trình nghiệp vụ hiện tại đã được văn bản hóa, và văn bản đó có khớp với trình tự thực tế của hiện trường không
• Các yêu cầu đã được gắn mức ưu tiên bắt buộc hay mong muốn chưa
• Yêu cầu liên kết với các hệ thống xung quanh như kế toán, chấm công, quản lý tồn kho sẵn có đã được bóc tách chưa
• Trong đề xuất, phân tích Fit&Gap có được ghi thành một hạng mục công việc độc lập không
• Với các Gap, phía nhà cung cấp có trình bày cả phương án ứng phó ngoài tùy chỉnh không
• Bạn đã được giải thích về gánh nặng bổ sung khi nâng cấp phiên bản trong trường hợp có thực hiện tùy chỉnh chưa
• Trong hợp đồng, loại hợp đồng và điều kiện nghiệm thu của từng công đoạn có được phân biệt không
• Bạn đã xác nhận tài liệu hướng dẫn, chương trình đào tạo và đầu mối tiếp nhận thắc mắc sau go-live mỗi thứ được cung cấp bằng ngôn ngữ nào chưa
• Kỳ xử lý theo tháng đầu tiên và đợt kiểm kê đầu tiên sau go-live có nằm trong phạm vi hỗ trợ không
• Bạn đã xác định trước những chỗ mà phương châm chuẩn của trụ sở Nhật Bản xung đột với yêu cầu pháp luật tại địa phương chưa

Nếu lấy báo giá khi còn chưa trả lời được “có” cho 4 mục đầu tiên, bạn sẽ không so sánh được con số của mỗi bên đang dựa trên căn cứ nào. Ngược lại, nếu ký hợp đồng mà chưa xác nhận 3 mục cuối, sau go-live rất dễ phát sinh những gánh nặng ngoài dự tính.

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

Hỗ trợ triển khai phần mềm đóng gói thì làm những gì

Đó là dịch vụ đồng hành sau khi sản phẩm đã được chọn, bao gồm định nghĩa yêu cầu, phân tích Fit&Gap, thiết lập cấu hình, thiết kế chuyển đổi dữ liệu, đào tạo hiện trường và theo dõi sau vận hành. Trung tâm của nó là phân tích Fit&Gap, tiến hành theo 4 bước gồm nắm bắt hiện trạng, khảo sát chức năng hệ thống, đánh giá mức độ phù hợp và quyết định phương án xử lý, nhằm đối chiếu nghiệp vụ của doanh nghiệp với chức năng tiêu chuẩn của gói phần mềm rồi quyết định cách xử lý phần không khớp. Phạm vi công việc khác rất nhiều so với hợp đồng chỉ bán license và làm thiết lập ban đầu.

Chi phí hỗ trợ triển khai khoảng bao nhiêu

Biên độ rất rộng tùy theo phạm vi đối tượng và tình hình của cơ sở, nên không thể đưa ra một mức giá chung. Mức tham chiếu được giới thiệu cho nội địa Nhật Bản có ghi ở phần chi phí trong bài, nhưng triển khai tại Thái Lan khác cả về đơn vị tiền tệ lẫn phạm vi đối tượng nên không thể áp thẳng con số đó. Trên thực tế, hãy lấy báo giá từ nhiều bên, làm cho thống nhất cách mỗi công đoạn gồm phân tích Fit&Gap, chuyển đổi dữ liệu, đào tạo và theo dõi sau vận hành được tính vào con số ra sao, rồi mới so sánh. So với bản thân con số, việc xác nhận đây là báo giá lập trước hay sau khi đã chốt phương án xử lý Gap sẽ cho bạn nhiều dữ liệu phán đoán hơn.

Doanh nghiệp có thể tự thực hiện phân tích Fit&Gap không

Với phần nắm bắt hiện trạng và bóc tách yêu cầu thì có nhiều phần doanh nghiệp tự làm được. Việc viết ra quy trình nghiệp vụ của toàn bộ các bộ phận và gắn mức ưu tiên bắt buộc hay mong muốn cho các yêu cầu là công việc có thể khởi động trong nội bộ. Phần khó là khảo sát chức năng hệ thống và đánh giá mức độ phù hợp, bởi để phán đoán ranh giới giữa phạm vi xử lý được bằng cấu hình và phần buộc phải phát triển, bạn cần am hiểu tường tận các mục thiết lập của chính sản phẩm đó. Thực tế, cách phân công hiệu quả là tự làm đến bước nắm bắt hiện trạng, rồi mang tài liệu đó sang nhận phần khảo sát chức năng và đánh giá mức độ phù hợp từ công ty hỗ trợ triển khai.

Khi phát hiện Gap thì có nên tùy chỉnh không

Trước tiên chúng tôi khuyến nghị đặt cạnh nhau 3 lựa chọn. Đó là thay đổi quy trình nghiệp vụ theo chức năng tiêu chuẩn, lấp bằng tùy chỉnh hoặc phát triển add-on, và dùng kèm công cụ khác để xử lý ở bên ngoài. Lấy mốc phán đoán là chỉ giữ lại làm ứng viên tùy chỉnh những Gap vừa có căn cứ từ pháp luật hoặc yêu cầu khách hàng vừa nằm ở lõi nghiệp vụ, còn các trình tự bắt nguồn từ thói quen hay các Gap nằm ở ngoại vi nghiệp vụ thì hãy xem xét trước phương án đổi nghiệp vụ hoặc xử lý bằng công cụ khác. Lý do là tùy chỉnh kéo theo không chỉ chi phí phát triển lần đầu mà còn cả việc kiểm chứng và sửa chữa cho từng lần nâng cấp phiên bản về sau.

Thuê ngoài phát triển hệ thống và hỗ trợ triển khai gói phần mềm khác nhau thế nào

Thứ tự những việc phải quyết định là ngược nhau. Thuê ngoài phát triển từ đầu thì định nghĩa yêu cầu nghiệp vụ của doanh nghiệp trước, rồi thiết kế và xây dựng hệ thống thỏa mãn các yêu cầu đó. Triển khai gói phần mềm thì hệ thống đã hoàn thiện có trước, nghiệp vụ của doanh nghiệp được đối chiếu vào đó và bạn quyết định cách xử lý phần không khớp. Công việc trung tâm của vế trước là thiết kế và lập trình, của vế sau là đối chiếu và quyết định hướng xử lý chênh lệch. Con đường khiến chi phí phình ra cũng khác nhau, vế trước phình vì bổ sung yêu cầu và thay đổi đặc tả, vế sau phình vì tùy chỉnh chồng chất để xử lý Gap.

Khi chọn công ty hỗ trợ triển khai tại cơ sở Thái Lan cần lưu ý gì

Có 3 điểm. Thứ nhất, thị trường hỗ trợ triển khai ERP tại Thái Lan trải rộng từ đối tác của sản phẩm toàn cầu tới nhà cung cấp bản địa, và cùng một cụm từ “hỗ trợ triển khai” nhưng phạm vi công việc cùng mặt bằng chi phí khác nhau rất nhiều, nên hãy làm cho thống nhất bảng phân rã công việc trước khi so sánh con số. Thứ hai, hãy xác nhận trước khi ký hợp đồng rằng tài liệu hướng dẫn, chương trình đào tạo và đầu mối tiếp nhận thắc mắc sau go-live mỗi thứ được cung cấp bằng ngôn ngữ nào. Thứ ba, với những chỗ mà hệ thống chuẩn của trụ sở Nhật Bản xung đột với yêu cầu pháp luật và chế độ thuế tại địa phương, hãy ghi chép tách bạch ngay từ bước phân tích Fit&Gap thành “Gap bắt nguồn từ pháp luật” và “Gap bắt nguồn từ tập quán vận hành”, để cuộc thảo luận giữa trụ sở và cơ sở tại chỗ dễ được sắp xếp hơn.

Tổng kết

Chúng tôi sắp xếp lại các ý chính đã trình bày trong bài về hỗ trợ triển khai phần mềm đóng gói.

• Hỗ trợ triển khai không phải dịch vụ bán phần mềm, mà là dịch vụ đồng hành qua định nghĩa yêu cầu, phân tích Fit&Gap, thiết lập cấu hình, thiết kế chuyển đổi dữ liệu, đào tạo và theo dõi sau vận hành, để đưa hệ thống về trạng thái dùng được trong nghiệp vụ của doanh nghiệp
• Kiểu vấp ngã điển hình của dự án triển khai gói phần mềm không phải là thiếu chức năng, mà nằm ở cấu trúc triển khai khi chưa qua phân tích Fit&Gap rồi chi phí tùy chỉnh chồng chất về sau
• Phân tích Fit&Gap là phương pháp so sánh nghiệp vụ hiện hành cùng các yêu cầu với chức năng hệ thống để bóc tách Fit và Gap, và được cho là tiến hành theo 4 bước gồm nắm bắt hiện trạng, khảo sát chức năng hệ thống, đánh giá mức độ phù hợp và quyết định phương án xử lý
• Ở bước đánh giá mức độ phù hợp, việc ghi lại không chỉ kết luận Fit hay Gap mà cả lý do chênh lệch và mức độ ảnh hưởng tới nghiệp vụ sẽ quyết định chất lượng các phán đoán về sau
• Các điểm mấu chốt để thành công được nêu ra gồm lôi kéo nhân viên hiện trường của toàn bộ các bộ phận vào cuộc, gắn mức ưu tiên bắt buộc hay mong muốn cho các yêu cầu, cân nhắc liên kết với hệ thống hiện có, và mô tả yêu cầu cụ thể đến cả màn hình, nhập liệu, xử lý và kết xuất
• Phương án ứng phó với Gap thường gồm 3 hướng là thay đổi quy trình nghiệp vụ, tùy chỉnh hoặc phát triển add-on, và dùng kèm công cụ khác, trong đó trình tự thực tế là chỉ giữ lại làm ứng viên tùy chỉnh những Gap vừa bắt buộc vừa nằm ở lõi nghiệp vụ
• Tùy chỉnh kéo theo không chỉ chi phí phát triển lần đầu mà còn việc kiểm chứng và sửa chữa cho từng lần nâng cấp về sau, nghĩa là mặt bằng chi phí bảo trì sau vận hành đã được quyết định ngay lúc triển khai
• Tại Thái Lan, biên độ lựa chọn trải rộng từ đối tác ERP toàn cầu tới nhà cung cấp bản địa, và cùng một cụm từ hỗ trợ triển khai nhưng phạm vi công việc cùng mặt bằng chi phí khác nhau, nên cần làm cho thống nhất bảng phân rã công việc trước khi so sánh con số
• Ở cơ sở Thái Lan của các nhà máy Nhật Bản, Gap giữa hệ thống chuẩn của trụ sở và yêu cầu bản địa dễ trở nên lớn về mặt cấu trúc, nên việc ghi chép tách bạch Gap do pháp luật và Gap do tập quán vận hành là cách làm hiệu quả
• Việc có hay không tài liệu hướng dẫn, chương trình đào tạo và đầu mối tiếp nhận thắc mắc bằng ngôn ngữ bản địa không phải vấn đề tiện nghi, mà là điều kiện quyết định khoản đầu tư có thu hồi được hay không

Việc đầu tiên nên làm không phải là so sánh lại sản phẩm, cũng không phải lấy lại báo giá. Đó là tự tiến hành trong nội bộ đến bước bóc tách quy trình nghiệp vụ của toàn bộ các bộ phận và gắn mức ưu tiên bắt buộc hay mong muốn cho các yêu cầu. Có hay không tập tài liệu này sẽ làm thay đổi hoàn toàn mức độ cụ thể của những đề xuất mà công ty hỗ trợ triển khai gửi lại cho bạn.

TOMAS TECH đang hỗ trợ chuyển đổi số tại hiện trường cho các doanh nghiệp sản xuất Nhật Bản hoạt động tại Thái Lan, trong đó có hệ thống quản lý sản xuất PEGASUS. Về hỗ trợ triển khai phần mềm đóng gói, chúng tôi cũng tiếp nhận cả những trao đổi ở giai đoạn sớm hơn như “nên tự làm phân tích Fit&Gap tới đâu” hay “nên sắp xếp thế nào khi chuẩn của trụ sở xung đột với yêu cầu bản địa”. Ngay cả khi bạn mới đang ở giai đoạn thu thập thông tin trước lúc quyết định triển khai cũng không sao, hãy liên hệ với chúng tôi qua trang liên hệ.

Thông tin tham khảo

• DTP Net – Phân tích Fit&Gap là gì. Cách tiến hành theo 4 bước và các điểm mấu chốt để thành công
• Arts and Crafts – Phân tích Fit&Gap trong triển khai ERP và các phương án ứng phó với Gap
• IT trend – Các loại gói ERP và đặc điểm của ERP nội địa dành cho doanh nghiệp vừa và nhỏ
• SF Solutions – Hỗ trợ triển khai Odoo ERP và đáp ứng chế độ thuế địa phương tại Thái Lan
• NEXUS – Nội dung hỗ trợ của các đối tác triển khai SAP Business One trên nền tảng đám mây
• Acclime Thailand – Hỗ trợ triển khai Microsoft Dynamics 365 tại Thái Lan
• MineERP – Mô tả về ERP cho nhà máy SME tại Thái Lan và chương trình DEPA d-transform
• improbe – Mức chi phí tham chiếu khi triển khai hệ thống quản lý sản xuất và các khoản trợ cấp cho doanh nghiệp sản xuất vừa và nhỏ