Quản lý tài sản CNTT nhà máy 2026 – một nửa hợp đồng nằm ngoài sổ

“Chúng tôi muốn rà soát lại việc quản lý tài sản CNTT của nhà máy, nhưng nên bắt đầu từ đâu”. Đây là câu hỏi chúng tôi thường xuyên nhận được tại các nhà máy Nhật Bản ở Thái Lan. Câu trả lời của chúng tôi lúc nào cũng giống nhau: trước khi đếm số lượng máy tính, hãy lập danh sách các hợp đồng. Bởi vì nguyên nhân khiến việc quản lý đổ vỡ không nằm ở chỗ số lượng hệ thống tăng lên, mà nằm ở chỗ người ra quyết định ký hợp đồng bị phân tán ra ngoài bộ phận CNTT. Bài viết này lấy ví dụ một nhà máy tại Rayong đang mang trên mình 7 hợp đồng, để theo dõi tình trạng một nửa chi tiêu hằng năm nằm ngoài sổ theo dõi tài sản.

Vì sao quản lý tài sản CNTT trong nhà máy luôn bị dời lại – hợp đồng thì tăng, người quản lý thì không

Khi hỏi các nhà máy Nhật Bản tại Thái Lan rằng “công ty có làm quản lý tài sản CNTT không”, phần lớn câu trả lời là “cũng có làm”. Nhưng khi chúng tôi đề nghị “cho chúng tôi xem sổ theo dõi”, thứ được đưa ra lại là danh sách máy tính và máy chủ. Mã tài sản, tên model, năm tháng mua, tên người sử dụng, vị trí lắp đặt. Xét như một bảng quản lý trang thiết bị thì nó được lập rất đúng và vẫn được cập nhật đều đặn.

Thế nhưng khi hỏi tiếp “vậy danh sách phần mềm và dịch vụ đám mây mà công ty đang ký hợp đồng nằm ở đâu”, bầu không khí lập tức thay đổi. Những gì bộ phận CNTT ký thì họ nắm được. Nhưng công cụ trò chuyện do bộ phận hành chính ký, hệ thống nhân sự do bộ phận kế toán ký, hệ thống báo giá do bộ phận kinh doanh ký, thì không ai trả lời ngay được rằng hợp đồng đang nằm ở đâu, phí năm là bao nhiêu, và khi nào tới hạn gia hạn. Hóa đơn vẫn đi qua kế toán nên việc thanh toán không hề gián đoạn. Chỉ có điều, không tồn tại một nơi nào tổng hợp tất cả những khoản đó lại thành “tài sản CNTT”.

Lý do trạng thái này hình thành không phải vì người phụ trách lơ là. Đó là vấn đề cấu trúc. Hệ thống của nhà máy được ký vào đúng thời điểm phát sinh nhu cầu, bởi đúng bộ phận có nhu cầu, và theo đúng tuyến phê duyệt tồn tại vào lúc đó. Hệ thống quản lý sản xuất được quyết bởi sự đồng thuận giữa bộ phận CNTT và giám đốc nhà máy. Hệ thống tiền lương do trưởng phòng kế toán quyết. Dịch vụ đám mây hỗ trợ kinh doanh thì trưởng phòng kinh doanh triển khai theo chỉ đạo của trụ sở chính. Người phê duyệt khác nhau thì nơi lưu hợp đồng cũng khác nhau, và đầu mối nhận thông báo gia hạn cũng khác nhau.

Thêm vào đó, công việc quản lý tài sản CNTT không có thời hạn rõ ràng. Nếu sản xuất dừng thì tất cả mọi người đều lao vào xử lý, nhưng sổ theo dõi cũ đi thì chẳng ai thấy phiền. Chỉ khi có đợt kiểm toán, khi bị chỉ ra vi phạm bản quyền, và khi bị yêu cầu cắt ngân sách mà không biết cắt vào đâu, thì mới thấy phiền. Cả ba tình huống đó một năm may ra xảy ra một lần, nên trong thứ tự ưu tiên hằng ngày, việc này luôn bị đẩy về phía sau.

Hơn nữa, người phụ trách CNTT ở nhà máy trong nhiều trường hợp chỉ có một người. Hoặc là kiêm nhiệm cùng kế toán, hành chính. Khi còn 5 hợp đồng thì trí nhớ vẫn xoay xở được. Khi lên 7 rồi 10 hợp đồng, trí nhớ không còn xoay xở nổi. Nhưng thời điểm người ta nhận ra là hợp đồng đã tăng lên thì thường lại rơi vào sau khi trí nhớ đã không còn xoay xở nổi. Hợp đồng thì tăng, người quản lý thì không. Sự bất đối xứng này chính là hình dạng cơ bản của việc quản lý tài sản CNTT trong nhà máy dần đổ vỡ.

Quản lý tài sản CNTT khác với sổ tài sản thiết bị – thứ phải quản lý là hợp đồng chứ không phải đồ vật

Nhà máy nào cũng có một cuốn sổ tài sản thiết bị rất chỉn chu. Máy dập, máy ép nhựa, máy nén khí, xe nâng. Mỗi thứ đều có mã tài sản, gắn với nguyên giá, khấu hao, lịch sử kiểm tra và nhà thầu bảo trì. Với tư cách một tổ chức, nhà máy cực kỳ thành thạo trong việc quản lý đồ vật bằng sổ sách.

Chính vì thành thạo như vậy nên khi bắt đầu quản lý tài sản CNTT, người ta cũng làm theo đúng lối tư duy đó. Dán tem tài sản lên máy tính, ghi lại mã model của máy chủ, ghi vị trí lắp đặt. Việc này không sai, nhưng so với thực trạng chi tiêu CNTT hiện nay thì nó lệch mất một nửa.

Lý do rất đơn giản: chiến trường chính của chi tiêu đã dịch từ “đồ vật” sang “hợp đồng”. Ở thời kỳ còn mua máy chủ đặt tại chỗ, thực thể của tài sản là đồ vật. Số tiền được chốt ngay tại thời điểm mua, sau đó chỉ còn khấu hao và bảo trì. Nhưng dịch vụ đám mây và SaaS thì không có thực thể. Cái tồn tại chỉ là hợp đồng và những ID người dùng gắn với hợp đồng đó. Số tiền phát sinh hằng tháng, biến động theo số người dùng và theo gói dịch vụ, và nếu để mặc thì nó tự động gia hạn.

Cybernet System nêu ra rằng trong các thách thức sắp tới của quản lý tài sản CNTT, môi trường ảo hóa rất khó đối chiếu bằng mắt thường với môi trường vật lý, còn đám mây thì cần được quản lý theo từng ID người dùng và mang rủi ro biến thành shadow IT. Đây chính là lời giải thích cho việc vì sao cuốn sổ dành cho đồ vật không thể bắt được đám mây. Sổ có cột để ghi vị trí lắp đặt, nhưng không có cột để ghi ID người dùng. Bản thân định dạng của sổ theo dõi đã có hình dạng không thể sao chụp lại được tài sản của ngày hôm nay.

Kết luận về mặt thực hành là như sau. Trong quản lý tài sản CNTT của nhà máy, cần lập một sổ theo dõi hợp đồng tách riêng khỏi sổ theo dõi đồ vật. Đơn vị quản lý không phải mã tài sản mà là số hợp đồng, và những mục cần ghi không phải vị trí lắp đặt mà là bộ phận phê duyệt, phí năm, đơn vị tính phí, ngày gia hạn và hạn chót gửi thông báo chấm dứt. Nếu cố trộn hai thứ này vào cùng một bảng thì cả hai đều dở dang. Hãy tách ra để lập, rồi chỉ liên kết ở những chỗ thực sự cần. Đó là điểm xuất phát.

Cách nhìn chi phí theo đơn vị hợp đồng cũng phát huy tác dụng y hệt khi thiết kế hợp đồng bảo trì. Về cấu trúc khiến việc chỉ so sánh con số phí năm không cho biết bên trong có gì, chúng tôi đã sắp xếp chi tiết trong bài cách đọc chi phí bảo trì hệ thống nghiệp vụ.

Vì sao đến năm 2026 việc rà soát trở nên cấp bách – đám mây và SaaS đã vượt qua sổ theo dõi

Với câu hỏi “từ xưa vẫn vậy mà, sao bây giờ mới phải rà soát”, chúng tôi trả lời rằng vì cơ cấu thị trường đã thay đổi.

Theo báo cáo Thailand IT and Security Market của Mordor Intelligence (cập nhật ngày 7 tháng 8 năm 2026), thị trường CNTT và an ninh của Thái Lan được dự báo mở rộng từ 9.92 tỷ USD năm 2025 lên 10.26 tỷ USD năm 2026, với tốc độ tăng trưởng bình quân năm giai đoạn 2026 đến 2031 là 10.26%. Bản thân việc thị trường tăng trưởng không có gì đáng ngạc nhiên. Thứ đáng chú ý là cơ cấu bên trong. Cũng theo báo cáo này, trong cơ cấu thị trường năm 2025, xét theo cấu phần thì phần mềm chiếm 41.72%, còn xét theo hình thức triển khai thì đám mây chiếm 55.84%.

Theo cấu phần, phần mềm vượt mốc 4 phần 10; theo hình thức triển khai, hơn một nửa toàn thị trường là đám mây. Chồng hai dữ kiện này lên nhau sẽ thấy trọng tâm của hành vi quản lý chi tiêu CNTT tại Thái Lan đang nằm ở đâu. Không phải ở số lượng phần cứng, mà ở hợp đồng phần mềm. Hơn nữa lại không phải hợp đồng dạng cài đặt tại chỗ, mà là hợp đồng đám mây vận hành theo ID người dùng và tính phí hằng tháng.

Sổ theo dõi CNTT của phần lớn nhà máy chưa bắt kịp sự dịch chuyển trọng tâm này. Định dạng của sổ được tạo ra vào thời kỳ máy chủ và máy trạm vẫn còn là trung tâm của chi tiêu. Vì tiếp tục vận hành với đúng tư tưởng thiết kế của thời đó, nên hợp đồng đám mây không lọt vừa vào các cột của sổ, và kết quả là bị đặt “ra ngoài sổ theo dõi”. Chỗ được đặt ra ngoài đó có thể là hộp thư của người phụ trách, có thể là thư mục của bộ phận, và cũng có thể là không ở đâu cả.

Còn một điểm nữa mang tính đặc thù của năm 2026. Phần lớn các SaaS nghiệp vụ được đưa vào trong vài năm gần đây hiện đang bước sang năm thứ hai, năm thứ ba kể từ hợp đồng đầu tiên. Năm đầu tiên thì giá đã được ép xuống nhờ đàm phán lúc triển khai, và người phụ trách vẫn còn nhớ rõ nội dung. Từ năm thứ hai trở đi, cơ chế tự động gia hạn bắt đầu phát huy, người phụ trách được luân chuyển, còn gói dịch vụ thì trôi theo thiết lập ban đầu. Giai đoạn hợp đồng bắt đầu “chuyển động một cách thầm lặng” rơi đúng vào lúc này.

Money Forward Admina, trong bài phân tích về tối ưu hóa chi phí sử dụng SaaS (đăng ngày 30 tháng 1 năm 2026, cập nhật ngày 23 tháng 4 năm 2026), cũng xử lý đúng cấu trúc mà ở đó các khoản phí thuê bao không nắm hết được đang đè nặng lên hoạt động kinh doanh, và nêu việc xóa các tài khoản không cần thiết, rà soát lại gói dịch vụ, sắp xếp lại các công cụ bị trùng lặp làm điểm khởi đầu của thực hành. Nghĩa là ngay tại Nhật Bản vấn đề này cũng đang xảy ra, chứ không phải tình huống đặc thù chỉ có ở cơ sở Thái Lan.

Ba lý do khiến quản lý tài sản CNTT đặc biệt dễ đổ vỡ tại cơ sở Thái Lan

Trên nền đó, cơ sở tại Thái Lan còn có những điểm dễ đổ vỡ riêng. Có ba điểm.

Thứ nhất là tuyến phê duyệt bị nhân đôi. Pháp nhân tại Thái Lan có thẩm quyền phê duyệt của mình, nhưng đồng thời cũng có những hệ thống được triển khai theo chủ trương của trụ sở chính tại Nhật Bản. Các phần mềm nhóm hay dịch vụ lưu trữ đám mây mà trụ sở chính ký như chuẩn chung toàn tập đoàn sẽ không xuất hiện trong sổ theo dõi phía Thái Lan, vì chi phí được ghi nhận ở phía trụ sở chính. Nhưng người thực sự dùng ID lại là nhân viên tại Thái Lan, và khi có người nghỉ việc thì phía Thái Lan mới là bên phải dọn dẹp. Những hợp đồng mà “ai trả tiền” và “ai đang dùng” lệch nhau thì ở sổ theo dõi nào cũng chỉ được ghi một cách dở dang.

Thứ hai là tốc độ thay người rất nhanh. Trên thị trường lao động Thái Lan, chuyển việc là chuyện phổ biến, và việc người phụ trách hệ thống thay đổi sau 2 đến 3 năm không phải hiếm. Quản lý người Nhật cũng thay theo vòng luân chuyển nhiệm kỳ, khoảng 3 đến 5 năm. Xác suất người ký hợp đồng và người gia hạn hợp đồng đó là hai người khác nhau rõ ràng cao hơn so với tại Nhật Bản. Nếu bối cảnh của hợp đồng không được bàn giao lại, quyết định gia hạn sẽ hội tụ về một câu duy nhất là “bằng số tiền năm ngoái nên cho qua”.

Thứ ba là sự phân tán về ngôn ngữ và nơi lưu hợp đồng. Với nhà cung cấp bản địa Thái Lan là hợp đồng tiếng Thái hoặc tiếng Anh, với nhà cung cấp Nhật Bản là hợp đồng tiếng Nhật, còn với SaaS toàn cầu thì chỉ là một thao tác đồng ý điều khoản sử dụng trực tuyến. Ba loại này gần như không bao giờ nằm chung một tủ hồ sơ. Đặc biệt là loại thứ ba, tức các dịch vụ ký trực tuyến và thanh toán bằng thẻ tín dụng, do không tồn tại tờ giấy nào mang hình dạng hợp đồng nên rơi vào trạng thái không có cách nào tìm ra.

Khi ba yếu tố này chồng lên nhau thì điều gì xảy ra. Giữa các hợp đồng mà bộ phận CNTT nắm được và các hợp đồng mà công ty thực sự đang trả tiền sẽ hình thành một khoảng chênh thường trực. Hơn nữa khoảng chênh đó không hiện ra chừng nào việc thanh toán chưa dừng lại. Hóa đơn về tới kế toán, kế toán xử lý với suy nghĩ “tháng nào cũng về nên chắc là đúng”. Đến đây thì trạng thái không ai nói dối mà vẫn không ai biết thực trạng đã hoàn tất.

Về những khó khăn vốn có của việc mở rộng ra cơ sở nước ngoài, mời bạn tham khảo thêm bài những gì xảy ra khi triển khai hệ thống tại cơ sở nước ngoài. Có những phần mà quyết định ở giai đoạn triển khai đã định sẵn hình dạng của việc quản lý tài sản về sau.

Hợp đồng lọt khỏi sổ theo dõi có ba kiểu

Sau khi nhìn thấy rất nhiều hợp đồng lọt khỏi sổ theo dõi, chúng tôi sắp xếp lại rằng cách lọt có ba kiểu. Biết được kiểu thì sẽ biết cách đi tìm.

Kiểu thứ nhất là hợp đồng cấp bộ phận. Đây là các dịch vụ mà những bộ phận như hành chính, kế toán, kinh doanh, đảm bảo chất lượng tự ký một mình để giải quyết bài toán nghiệp vụ của chính mình. Vì số tiền nằm gọn trong hạn mức phê duyệt của bộ phận nên không cần qua phê duyệt của bộ phận CNTT. Hoàn toàn không có ý đồ xấu, ngược lại đó còn là kết quả của việc hiện trường chủ động cải tiến. Nhưng nhìn từ bộ phận CNTT thì đây là những hợp đồng mà bản thân sự tồn tại của chúng cũng không nhìn thấy được. Khi đi tìm kiểu này, con đường ngắn nhất không phải tra theo tên hệ thống, mà là xếp dữ liệu thanh toán của kế toán theo từng bộ phận.

Kiểu thứ hai là hợp đồng cá nhân. Là trường hợp người phụ trách ký bằng thẻ tín dụng cá nhân hoặc tài khoản cá nhân, rồi xử lý qua thanh toán hoàn ứng chi phí. Đặc trưng là phần lớn có đơn giá nhỏ, chẳng hạn công cụ dịch thuật, phần mềm xem bản vẽ, lưu trữ trực tuyến, trợ lý AI. Về mặt số tiền thì thường không lớn, nhưng đây lại là kiểu có rủi ro cao nhất. Bởi vì dữ liệu nghiệp vụ đang được lưu trong một tài khoản nằm ngoài tầm quản lý của công ty, và ngay khi người đó nghỉ việc thì không còn ai truy cập được nữa. Lĩnh vực mà dxeco đề cập trong bài phân tích về shadow IT cũng chính là vùng này.

Kiểu thứ ba là hợp đồng đi kèm. Là các hợp đồng phát sinh kèm theo hợp đồng chính, trong đó hợp đồng chính đã có trong sổ theo dõi nhưng riêng phần đi kèm thì bị thiếu. Bản quyền bổ sung của hệ thống quản lý sản xuất, tùy chọn mở rộng dung lượng lưu trữ của dịch vụ đám mây, tùy chọn kéo dài thời hạn lưu bản sao lưu. Vì xét theo hợp đồng thì vẫn chỉ là một hợp đồng nên rất dễ bỏ sót, thế nhưng phí năm thì tăng đều đặn. Muốn tìm kiểu này thì phải mở tới từng dòng chi tiết của hóa đơn, vì nếu chỉ nhìn theo đơn vị hợp đồng chứ không theo đơn vị dòng chi tiết thì nó sẽ không lộ ra.

Ba kiểu này có nơi cần tìm hoàn toàn khác nhau. Kiểu hợp đồng cấp bộ phận nằm ở dữ liệu thanh toán của kế toán, kiểu hợp đồng cá nhân nằm ở dữ liệu hoàn ứng chi phí, kiểu hợp đồng đi kèm nằm ở dòng chi tiết hóa đơn. Dù có xem đi xem lại bao nhiêu lần thư mục hợp đồng mà bộ phận CNTT đang giữ, không kiểu nào lộ ra cả. Hãy bắt đầu bước đi đầu tiên của việc rà soát bằng cách yêu cầu lấy dữ liệu từ ba nơi này.

Trường hợp mô hình – rà soát 7 hợp đồng của nhà máy tại Rayong

Từ đây chúng ta sẽ xem xét bằng một trường hợp mô hình cụ thể. Nội dung dưới đây là trường hợp mô hình dựa trên tính toán riêng của chúng tôi, không phải số liệu của một doanh nghiệp có thật. Thay vì bản thân các con số, mời bạn nhìn vào cấu trúc, tức là chỗ nào phát sinh rò rỉ và việc rà soát làm dịch chuyển được những gì.

Tiền đề như sau. Một nhà máy lắp ráp linh kiện điện tử của Nhật Bản tại tỉnh Rayong, Thái Lan, với 250 nhân viên. Trong 8 năm qua, nhà máy đã ký 7 hệ thống nghiệp vụ vào những thời điểm khác nhau, với những người phê duyệt khác nhau. Không có nhân sự chuyên trách quản lý tài sản CNTT, và người phụ trách kế toán kiêm nhiệm việc giữ sổ theo dõi bằng Excel. Đây là một cấu hình rất phổ biến.

Sau khi tiến hành rà soát và xếp toàn bộ 7 hợp đồng lên cùng một bảng, kết quả thu được như sau. Phí năm tính bằng THB.

Ngay tại thời điểm lập xong bảng này đã có phát hiện đầu tiên. Tổng phí năm của 4 hợp đồng có trong sổ theo dõi là 636,000, tương đương 49.5% tổng chi tiêu. Ngược lại, tổng phí năm của 3 hợp đồng nằm ngoài sổ là 648,000, tức 50.5% tổng chi tiêu. Nói cách khác, phần chi tiêu CNTT mà nhà máy này nắm được còn chưa tới một nửa chi tiêu thực tế.

Điều chúng tôi mong bạn chú ý ở đây là ranh giới có mặt hay không có mặt trong sổ theo dõi không được phân chia theo “mức độ quan trọng của hệ thống”, cũng không theo “số tiền lớn hay nhỏ”. Thứ duy nhất phân chia là bộ phận phê duyệt. Bốn hợp đồng do bộ phận CNTT phê duyệt thì có mặt đầy đủ, ba hợp đồng do các bộ phận khác phê duyệt thì vắng mặt đầy đủ. Hơn nữa, xét về tổng số tiền thì nhóm ngoài sổ còn nhiều hơn. Xét theo từng hợp đồng đơn lẻ, hợp đồng đắt nhất là hệ thống báo giá và đặt hàng số 7 (264,000) cũng nằm ngoài sổ.

Cấu trúc này không thể khắc phục bằng sự cẩn thận của người phụ trách. Bởi vì người phụ trách của bộ phận CNTT không có bất kỳ phương tiện nào để biết được sự tồn tại của những hợp đồng mà mình không tham gia. Sổ theo dõi chỉ được lấp đầy một nửa không phải vì người phụ trách chỉ làm việc một nửa, mà vì thông tin chỉ đến được với người phụ trách một nửa.

Nghĩa là, cách nâng độ chính xác của quản lý tài sản CNTT không phải là “ghi sổ cẩn thận hơn nữa”, mà là “tạo ra một tuyến đường mà thông tin về các hợp đồng không đi qua bộ phận CNTT nhất định vẫn đến được bộ phận CNTT ở đâu đó”. Sự khác biệt này làm thay đổi rất lớn cách thiết kế công việc, vì vế trước là nỗ lực cá nhân còn vế sau là câu chuyện của cơ chế.

Điều gì đã xảy ra với 3 hợp đồng nằm ngoài sổ theo dõi

Khi tìm hiểu nội dung hợp đồng và thực trạng sử dụng của 3 hợp đồng ngoài sổ, cả ba đều phát sinh lãng phí theo những hình thức khác nhau. Điểm chung là tất cả đều xảy ra trong khoảng thời gian “không có ai nhìn tới”.

Số 7, hệ thống báo giá và đặt hàng (bộ phận kinh doanh phê duyệt, phí năm 264,000). Sang năm thứ hai của hợp đồng, việc tự động gia hạn gói dịch vụ đã chuyển sang gói premium. Phí năm ban đầu là 216,000, nhưng sau khi gia hạn thành 264,000. Chênh lệch là 48,000, tức tăng 22.2% so với phí năm ban đầu. Bộ phận kinh doanh không hề nhận thức được rằng gói đã chuyển lên bậc cao hơn, và cũng không dùng tới các chức năng được bổ sung.

Số 5, chatbot hỏi đáp nội bộ (bộ phận hành chính phê duyệt, phí năm 216,000). Đây là hợp đồng mà bộ phận hành chính ký để nâng hiệu quả xử lý các câu hỏi từ nhân viên. Thế nhưng kết quả khảo sát cho thấy trong phạm vi hợp đồng sẵn có của hệ thống quản lý sản xuất (số 1) đã đi kèm sẵn chức năng FAQ và trợ giúp ngay từ đầu. Nghĩa là chức năng đã bị trùng lặp. Kiểm tra thêm số liệu sử dụng thực tế thì trong 90 lượt hỏi đáp mỗi tháng, phần thực sự được dùng cho hỏi đáp nội bộ chỉ dừng ở 18 lượt (20.0%), phần còn lại là vận hành thử và các phiếu bị tạo trùng.

Số 6, hệ thống tiền lương và nhân sự (bộ phận kế toán phê duyệt, phí năm 168,000). Hệ thống tính phí theo từng ID người dùng, và tài khoản của những người đã nghỉ việc vẫn còn nguyên 5 suất. Mỗi suất có phí tháng là 800 THB, quy ra phí năm là 9,600 THB. Tổng 5 suất tương đương 48,000 THB mỗi năm đang được trả cho những tài khoản không có ai sử dụng.

Xếp ba trường hợp cạnh nhau sẽ thấy nguồn gốc của lãng phí ở mỗi trường hợp một khác. Số 7 là do không theo dõi sự thay đổi của điều kiện hợp đồng. Số 5 là do không kiểm tra sự trùng lặp chức năng với hệ thống khác. Số 6 là do thông tin biến động nhân sự và thông tin tài khoản của hệ thống không liên thông với nhau. Nguyên nhân khác nhau nên biện pháp cũng khác nhau. Không thể dùng một biện pháp duy nhất để giải quyết gọn cả ba.

Và ba trường hợp này chỉ có đúng một điều kiện chung. Tất cả đều nằm ngoài sổ theo dõi và chưa từng một lần có cơ hội được rà soát theo chu kỳ năm. Nói ngược lại, ở 4 hợp đồng có trong sổ thì không phát hiện tình trạng nào như vậy. Bản thân việc ghi vào sổ không trực tiếp tạo ra hiệu quả cắt giảm, nhưng đã được ghi thì ít nhất cũng sinh ra “cơ hội được nhìn tới”. Giá trị thực tiễn của quản lý tài sản CNTT nằm ở chỗ đó.

Đợt tăng giá thầm lặng do tự động gia hạn tạo ra

Trong ba phát hiện, khó nhận ra nhất là việc tự động gia hạn ở hợp đồng số 7. Riêng mục này chúng ta hãy xem tách ra.

Hợp đồng của các dịch vụ đám mây và SaaS hầu hết đều được thiết kế trên tiền đề tự động gia hạn. Chừng nào chưa có biểu thị ý chí chấm dứt hay thay đổi điều kiện thì hợp đồng vẫn tiếp tục với điều kiện như cũ. Đây là một cơ chế hợp lý, giúp giảm gánh nặng thủ tục cho cả người sử dụng, và bản thân nó không phải vấn đề.

Vấn đề là nội dung của cụm “tiếp tục với điều kiện như cũ” không nhất thiết đồng nghĩa với cùng một số tiền. Tự động chuyển lên gói cao hơn, tính phí lũy tiến theo lượng sử dụng, kết thúc phần chiết khấu năm đầu vốn chỉ có thời hạn, điều chỉnh theo tỷ giá hoặc theo đợt sửa giá tại thị trường bản địa. Tất cả những điều đó đều đã được viết trong điều khoản hợp đồng ngay từ đầu, và email thông báo trước cũng đã được gửi đi. Chỉ có điều thông báo ấy được gửi tới địa chỉ email của người đã ký hợp đồng. Nếu người đó đã chuyển công tác thì email không được ai đọc cả.

Ở hợp đồng số 7 của trường hợp mô hình, phí năm tăng từ 216,000 lên 264,000, tức tăng thêm đúng phần chênh lệch 48,000. Xét trong một năm thì đây không phải số tiền đủ lớn để phải làm tờ trình. Cũng không có ai nhận ra là nó đã tăng. Nhưng 48,000 này sẽ phát sinh cả năm sau và năm sau nữa. Hơn nữa, một khi hợp đồng đã được gia hạn ở gói cao hơn thì ở lần gia hạn kế tiếp nó vẫn tiếp tục ở gói cao đó. Khoảng cách lũy kế sẽ giãn ra tỷ lệ thuận với độ dài của quãng thời gian bị bỏ mặc.

Sở dĩ chúng tôi gọi đây là “đợt tăng giá thầm lặng” không phải vì thông báo tăng giá không được gửi tới, mà vì không tồn tại một quyết định phê duyệt cho việc tăng giá đó. Thông thường, khi chi tiêu tăng thì phải có ai đó ra quyết định. Có quyết định thì có ghi chép, có ghi chép thì về sau còn kiểm chứng được. Việc tăng số tiền do tự động gia hạn lại thiếu mất bước ra quyết định này. Chi tiêu tăng mà không ai quyết, nên về sau cũng không còn manh mối nào để truy ngược lại câu hỏi “vì sao nó tăng”.

Biện pháp đối phó đơn giản đến mức đáng ngạc nhiên, chỉ gói gọn trong việc ghi ngày gia hạn và hạn chót gửi thông báo chấm dứt vào sổ theo dõi. Nhiều hợp đồng SaaS có quy định một mốc thời hạn, rằng nếu đề nghị trước ngày gia hạn bao nhiêu ngày thì được thay đổi điều kiện hoặc chấm dứt. Qua mốc đó rồi thì năm ấy không còn dịch chuyển được điều kiện nữa. Nghĩa là thời điểm đàm phán không phải ngày gia hạn, mà là ngày gia hạn trừ đi thời hạn thông báo. Việc sổ theo dõi có ghi ngày này hay không sẽ quyết định việc bạn có đàm phán được hay không.

Một việc nữa cũng rất hiệu quả trên thực tế là đổi đầu mối liên hệ của hợp đồng từ địa chỉ email cá nhân sang địa chỉ dùng chung của bộ phận. Người phụ trách có thay đổi thì thông báo vẫn tiếp tục đến nơi. Về thủ tục thì đây là việc chỉ mất vài phút, nhưng số nhà máy đã làm thì gần như không có.

Vì sao hợp đồng trùng lặp phát sinh – chức năng chồng nhau nhưng hợp đồng thì riêng biệt

Chatbot ở hợp đồng số 5 là ví dụ điển hình của việc trùng lặp chức năng. Tuy nhiên, nếu kết luận rằng “chịu khó tra cứu thì đã biết rồi” thì đó là hiểu sai thực trạng. Bởi vì cấu trúc làm phát sinh trùng lặp có tính tất yếu của riêng nó.

Hãy thử đứng ở vị trí của người phụ trách bộ phận hành chính. Họ đang bị chiếm mất thời gian vì phải trả lời câu hỏi từ nhân viên. Nội quy lao động, số ngày phép còn lại, thủ tục bảo hiểm xã hội, cách viết đơn từ nội bộ. Vì cùng một câu hỏi cứ lặp đi lặp lại nên họ muốn có một cơ chế trả lời tự động. Tra cứu thị trường thì thấy có SaaS chatbot, giá lại nằm gọn trong hạn mức phê duyệt của bộ phận. Thế là triển khai. Trong toàn bộ mạch này không có lấy một sai lầm về mặt phán đoán.

Mặt khác, việc hệ thống quản lý sản xuất có đi kèm chức năng FAQ và trợ giúp thì có được ghi trong hợp đồng và tài liệu sản phẩm của hệ thống quản lý sản xuất. Nhưng tài liệu đó do bộ phận CNTT và người phụ trách quản lý sản xuất của nhà máy giữ, và người phụ trách bộ phận hành chính không có cơ hội đọc tới. Vả lại, nhìn từ bộ phận hành chính thì hệ thống quản lý sản xuất là thứ dành cho hiện trường nhà máy, thuộc một nhóm sản phẩm không liên quan gì tới việc hỏi đáp nội bộ. Việc ý tưởng “biết đâu đọc tài liệu hệ thống quản lý sản xuất là giải quyết được” không nảy ra là điều cực kỳ tự nhiên.

Nói cách khác, hợp đồng trùng lặp sinh ra từ sự bất đối xứng thông tin. Bộ phận chưa ký hợp đồng không có tuyến đường nào để biết trong hợp đồng sẵn có chứa những gì. Đây không phải vấn đề về nỗ lực tra cứu, mà là vấn đề về nơi thông tin được đặt.

Và sự trùng lặp còn xảy ra ở một tầng nữa. Nếu hợp đồng là riêng biệt thì dù chức năng có chồng lên nhau, hệ thống cũng không đưa ra bất kỳ cảnh báo nào. Cơ chế phát hiện việc trong cùng một công ty đang trả tiền hai lần cho cùng một mục đích chức năng không được cài sẵn ở phía từng SaaS nghiệp vụ riêng lẻ. Chỉ có con người khi xếp toàn bộ hợp đồng vào cùng một chỗ, hoặc công cụ quản lý được tạo ra để làm đúng việc đó, mới phát hiện được.

Biện pháp có hiệu quả thực tế là tạo trong sổ theo dõi hợp đồng một cột “chức năng chính”, rồi phân loại bằng khoảng 5 đến 10 thẻ chức năng thô. Mức độ chi tiết như xử lý hỏi đáp, biểu mẫu, tồn kho, thu thập số liệu thực tế, chấm công, luồng phê duyệt là đã đủ. Nếu cùng một thẻ xuất hiện ở hai hợp đồng thì đó là ứng viên của sự trùng lặp. Không cần so sánh chức năng một cách chặt chẽ, chỉ cần có một cửa vào để tìm ra ứng viên rồi đi xác nhận.

Xin lưu ý thêm, trong trường hợp mô hình, quyết định được đưa ra không phải chấm dứt hợp đồng chatbot mà là thu hẹp xuống gói light, vì vẫn còn 18 lượt sử dụng thực tế mỗi tháng. Tìm ra trùng lặp không có nghĩa là bỏ hết luôn mới là đáp án đúng. Hãy giữ lại cách dùng đang có thành tích thực tế, đồng thời điều chỉnh quy mô cho khớp với thực trạng. Để làm được việc điều chỉnh này thì dữ liệu về mức sử dụng thực tế là bắt buộc.

Vì sao phần mềm kỹ thuật là phần đặc biệt khó

Trong quản lý tài sản CNTT của nhà máy, chỗ khó còn lại đến sau cùng là nhóm phần mềm kỹ thuật. Đó là các phần mềm CAD, CAE, phần mềm dùng cho thiết kế và mô phỏng thiết bị.

Bản hướng dẫn so sánh toàn diện các giải pháp quản lý bản quyền dành cho CNTT doanh nghiệp phiên bản 2026 của OpenLM Japan (công bố ngày 17 tháng 6 năm 2026) xếp các phần mềm kỹ thuật như Autodesk, Bentley, ANSYS, Esri, Dassault Systèmes vào nhóm lĩnh vực đòi hỏi việc quản lý bản quyền đặc biệt tốn kém và phức tạp. Trong quản lý tài sản của nhà máy, lĩnh vực này khó là vì những yếu tố sau chồng lên nhau.

Thứ nhất, hình thái bản quyền rất đa dạng. Node lock gắn với một máy cụ thể, floating quản lý số phiên sử dụng đồng thời trong nội bộ, thuê bao chia theo kỳ hạn, bản quyền bổ sung theo từng module. Cùng một sản phẩm nhưng hình thái hợp đồng khác nhau thì đơn vị quản lý cũng thay đổi. Không xác nhận hình thái thì không trả lời được câu hỏi “công ty đang có bao nhiêu bản quyền”.

Thứ hai, rất khó nhìn thấy được liệu bản quyền có thực sự đang được dùng hay không. Với bản quyền floating, thứ ta mua là mức trần số người dùng đồng thời, nên nếu không đo xem thực tế số người dùng đồng thời đạt bao nhiêu so với mức trần thì không biết được số lượng phù hợp là bao nhiêu. Một bản quyền chỉ được khởi động vài lần trong một năm và một bản quyền lúc nào cũng chạm trần vẫn được xếp ngang nhau trên sổ theo dõi như cùng “một bản”.

Thứ ba, đơn giá cao. Số tiền lớn nên khi dư thừa thì ảnh hưởng lớn, mà ngược lại khi thiếu và làm nghiệp vụ đứng lại thì ảnh hưởng cũng lớn. Chính vì thế mà nó khó cắt, và kết quả là đây cũng là vùng dễ tích tụ các quyết định kiểu “mua dư ra cho chắc”.

Cũng bản hướng dẫn đó chỉ ra rằng bản thân việc quản lý bản quyền đang tiến hóa từ giai đoạn nắm được “ai đang có cái gì” sang phân tích sử dụng theo thời gian thực, ứng dụng AI, và đáp ứng các hướng FinOps hay GreenOps. Đây là câu chuyện đặt trong bối cảnh bộ phận CNTT của tập đoàn lớn, nhưng về hướng đi thì cũng đúng với nhà máy. Nghĩa là lập được sổ theo dõi không phải đích đến, mà việc đo mức sử dụng thực tế rồi phản ánh trở lại vào hợp đồng mới là trọn vẹn một chuỗi công việc.

Dù vậy, không cần triển khai tới mức phân tích sử dụng ngay từ đầu. Với nhà máy đang sở hữu phần mềm kỹ thuật, chỉ cần gom 5 mục gồm tên sản phẩm, hình thái bản quyền, số lượng, phí năm và ngày gia hạn lên cùng một trang thì cơ sở để ra quyết định đã khác hẳn. Nhà máy trong trường hợp mô hình không có hợp đồng thuộc lĩnh vực này, nhưng ở những cơ sở có chức năng thiết kế thì đây thường là khoản tiền lớn nhất.

Rà soát rồi thì dịch chuyển được bao nhiêu – chi tiết khoản cắt giảm của trường hợp mô hình

Chúng tôi tổng hợp lại các biện pháp mà nhà máy trong trường hợp mô hình đã thực hiện sau khi rà soát, cùng số tiền cắt giảm được. Xin nhắc lại, đây là tính toán riêng chứ không phải số liệu của doanh nghiệp có thật.

So với tổng chi tiêu 1,284,000, số tiền cắt giảm là 216,000. Tỷ lệ cắt giảm là 16.8%. Nếu trạng thái sau rà soát được duy trì thì lũy kế đơn thuần trong 5 năm sẽ là 1,080,000 được cắt giảm (tính toán này chưa bao gồm chi phí nhân công cho việc rà soát).

Đi vào chi tiết sẽ thấy tính chất của ba biện pháp hoàn toàn khác nhau.

Thu hẹp chatbot (120,000) là quyết định dựa trên cả hai căn cứ là trùng lặp chức năng và mức sử dụng thực tế. Đây là biện pháp có số tiền lớn nhất trong ba biện pháp, và cũng là biện pháp tốn nhiều thời gian xem xét nhất. Bởi vì cần xác nhận chức năng FAQ của hệ thống quản lý sản xuất sẵn có có thực sự dùng được cho mục đích mà bộ phận hành chính cần hay không, rồi phải quyết định sẽ hứng 18 lượt sử dụng thực tế mỗi tháng bằng cách nào. Biện pháp có số tiền càng lớn thì càng cần xác nhận về mặt kỹ thuật và đồng thuận giữa các bộ phận.

Đàm phán điều chỉnh gói (48,000) là cuộc đàm phán để đưa phần đã tăng do tự động gia hạn trở về mức cũ. Vì có bằng chứng thực tế rằng các chức năng được bổ sung không được sử dụng nên vật liệu đàm phán rất rõ ràng. Tuy nhiên việc này không thành nếu không nắm được ngày gia hạn và hạn chót thông báo chấm dứt. Nếu đã qua hạn thì dù đối tác có chịu nghe, số tiền của năm tài chính đó vẫn không dịch chuyển được.

Hủy tài khoản bỏ quên (48,000) là biện pháp đơn giản nhất và thực hiện được nhanh nhất trong ba biện pháp. Chỉ cần đối chiếu danh sách người nghỉ việc với danh sách tài khoản là xong. Không cần xem xét kỹ thuật, cũng không cần đàm phán giữa các bộ phận. Nếu bắt đầu rà soát, chúng tôi khuyến nghị khởi động từ đúng chỗ này. Vì thời gian tới lúc có hiệu quả là ngắn nhất, hơn nữa thành quả lại hiện ra bằng con số nên dễ tạo được sự thấu hiểu trong nội bộ để đẩy tiếp các biện pháp sau.

Mặt khác, biện pháp này cũng có điểm cần lưu ý. Tài khoản của người đã nghỉ việc, khi bị xóa, có thể kéo theo việc mất luôn quyền truy cập vào dữ liệu quá khứ. Với hệ thống tiền lương và nhân sự, có trường hợp phát sinh nghĩa vụ lưu giữ hồ sơ của khoảng thời gian người đó còn làm việc. Trước khi hủy, hãy xác nhận yêu cầu lưu giữ dữ liệu dưới góc độ nhân sự và pháp chế. Đây là thao tác đơn giản, nhưng bỏ qua bước xác nhận thì về sau sẽ phiền.

Về cách tiếp nhận con số tỷ lệ cắt giảm 16.8%, điều quan trọng là đây không phải “hiệu quả chỉ xuất hiện một lần vào năm đầu tiên”. Giá trị bản chất của việc rà soát nằm ở chỗ, hơn cả bản thân số tiền cắt giảm, là từ đó về sau mọi khoản tăng chi đều phải đi qua một bước ra quyết định. Khi đã có sổ theo dõi và cơ chế giám sát gia hạn thì việc tăng chi thầm lặng do tự động gia hạn sẽ không còn xảy ra. Hiệu quả xuất hiện dưới hai hình thức, một lần dưới dạng số tiền cắt giảm, và hằng năm dưới dạng ngăn chặn việc tăng chi.

Quy trình thực hành quản lý tài sản CNTT – bốn giai đoạn sổ theo dõi, rà soát, hợp nhất hợp đồng và giám sát gia hạn

Chúng tôi sắp xếp toàn bộ nội dung phía trên thành bốn giai đoạn theo trình tự thực hành. Thứ tự có ý nghĩa của nó, nên xin đừng bỏ qua giai đoạn nào.

Giai đoạn 1 là hoàn thiện sổ theo dõi. Đích đến là “xếp toàn bộ các hợp đồng liên quan tới CNTT mà công ty đang trả tiền lên cùng một bảng”. Chỉ dựa vào thư mục hợp đồng của bộ phận CNTT thì không lấp đầy được. Hãy yêu cầu kế toán cung cấp dữ liệu thanh toán theo từng bộ phận, trích xuất các mục liên quan tới CNTT từ dữ liệu hoàn ứng chi phí, và mở hóa đơn tới tận dòng chi tiết. Đây là công việc nhặt ba kiểu đã nói ở trên, gồm kiểu cấp bộ phận, kiểu cá nhân và kiểu đi kèm, từ ba nơi khác nhau. Ở giai đoạn này, đừng phán xét tính hợp lý của số tiền. Hãy chỉ nhắm tới việc bao phủ cho đủ. Trộn phán xét vào là công việc sẽ đứng lại.

Giai đoạn 2 là rà soát. Với các hợp đồng đã xếp lên sổ, hãy đối chiếu điều kiện hợp đồng với thực trạng sử dụng. Gói dịch vụ gốc ghi trong hợp đồng và gói đang được áp dụng hiện nay. Số người dùng đã ký và số người dùng thực sự đăng nhập. Chức năng đã ký và chức năng thực sự được dùng. Thứ cần có ở giai đoạn này là dữ liệu sử dụng thực tế xuất ra từ màn hình quản trị của từng dịch vụ. Hầu hết SaaS đều có báo cáo lịch sử đăng nhập hoặc số người dùng hoạt động dành cho quản trị viên. Đừng dựa vào cảm giác rằng “chắc có chức năng không ai dùng”, hãy xác nhận bằng dữ liệu.

Giai đoạn 3 là hợp nhất hợp đồng. Hãy phản ánh phần trùng lặp và phần dư thừa đã nhìn thấy qua rà soát vào việc thay đổi hợp đồng thực tế. Thu hẹp gói, giảm số người dùng, chấm dứt hoặc thu hẹp hợp đồng trùng lặp, sắp xếp lại cho các kỳ gia hạn trùng nhau. Thứ bạn sẽ va phải ở giai đoạn này là việc điều phối giữa các bộ phận. Với bộ phận đang giữ hợp đồng, câu chuyện rất dễ bị nhìn thành việc phủ nhận quyết định của chính họ. Đừng đi theo hướng “đây là tiêu tiền lãng phí”, hãy đi theo hướng “xét trên toàn công ty thì chúng ta đang trả tiền hai lần cho cùng một chức năng, nên cần quyết định gom về bên nào”. Trên thực tế, chỉ riêng khác biệt trong cách nói này đã làm thay đổi tiến độ.

Giai đoạn 4 là giám sát gia hạn. Đây là giai đoạn bị xem nhẹ nhất, và cũng là giai đoạn hiệu quả nhất. Hãy lập danh sách ngày gia hạn và hạn chót thông báo chấm dứt của toàn bộ hợp đồng, rồi đặt cảnh báo bật lên trước hạn thông báo 30 ngày. Về cơ chế thì dùng lịch hẹn lặp lại cũng được. Quan trọng là đặt người nhận cảnh báo là nhiều người chứ không phải một cá nhân, và quyết định trước sẽ làm gì khi cảnh báo bật lên. Hãy ghi vào quy tắc vận hành một câu rằng “với các hợp đồng sắp tới tháng gia hạn, xác nhận mức sử dụng thực tế rồi quyết định tiếp tục, thu hẹp hay chấm dứt”.

Trong bốn giai đoạn này, giai đoạn 1 và 2 là công việc làm một lần, giai đoạn 3 làm tuần tự theo thời điểm gia hạn của từng hợp đồng, còn giai đoạn 4 là vận hành thường xuyên. Thất bại thường gặp là cố làm hoàn hảo giai đoạn 1 và 2 rồi đuối sức, không bao giờ tới được giai đoạn 4. Độ chính xác của sổ theo dõi ở mức 8 phần 10 là được. Trạng thái một cuốn sổ đúng 8 phần 10 nhưng có giám sát gia hạn đi kèm vận hành tốt hơn rất nhiều so với trạng thái một cuốn sổ đúng 10 phần 10 nhưng bị bỏ mặc không cập nhật.

Về thời gian cần thiết, xin chia sẻ cảm nhận trong phạm vi những dự án chúng tôi đã hỗ trợ. Với nhà máy có khoảng 10 hợp đồng, giai đoạn 1 và 2 mất từ 1 đến 2 tháng, còn giai đoạn 3 thì trải theo ngày gia hạn của từng hợp đồng và chạy tuần tự trong 1 năm. Đó là tiến độ thực tế. Đây không phải con số có thể khái quát thành mặt bằng chung, nhưng có một điểm chung là bạn không cần phải thay đổi tất cả cùng một lúc.

Ranh giới giữa phần giữ trong nội bộ và phần giao ra bên ngoài

Nếu tự làm toàn bộ việc quản lý tài sản CNTT thì mọi thứ sẽ dừng ngay khoảnh khắc người phụ trách rời đi. Nếu thuê ngoài toàn bộ thì phải gửi ra bên ngoài thông tin nhạy cảm là thông tin hợp đồng, hơn nữa tốc độ ra quyết định cũng chậm lại. Cần một đường ranh giới.

Cách phân chia đang vận hành hiệu quả trên thực tế là giữ sổ theo dõi và giám sát gia hạn ở trong nội bộ, còn phân tích khi rà soát và thiết kế đàm phán hợp đồng thì giao ra bên ngoài.

Những thứ nên giữ trong nội bộ. Trước hết là bản thân sổ theo dõi. Hợp đồng nào đang tồn tại, trả bao nhiêu tiền, gia hạn khi nào. Đây là thông tin nền tảng của công ty nên không nên gửi ra ngoài. Tiếp theo là việc vận hành giám sát gia hạn. Phần nhận cảnh báo và vận hành quy trình ra quyết định thì đặt trong nội bộ. Nếu giao cả việc ra quyết định cho bên ngoài thì việc điều phối với các bộ phận sẽ không chạy. Thứ ba là việc dọn dẹp tài khoản khi có người nghỉ việc hoặc luân chuyển. Đây là công việc liên thông với thông tin nhân sự nên khép kín trong nội bộ là hợp lý. Khoản 48,000 tìm thấy ở hợp đồng số 6 của trường hợp mô hình lẽ ra đã không phát sinh nếu có cách vận hành này.

Những thứ có thể giao ra bên ngoài. Một là phần phân tích trong lần rà soát đầu tiên. Công việc xếp 7 hay 10 hợp đồng cạnh nhau rồi nhìn ra sự trùng lặp chức năng sẽ càng nhanh khi càng có kinh nghiệm xem cấu hình của nhiều doanh nghiệp. Làm trong nội bộ cũng có mặt khiến cách dùng hiện hữu trở thành tiền đề mặc định, và chính sự trùng lặp lại trở nên khó thấy. Hai là thiết kế đàm phán hợp đồng. Điều kiện nào đàm phán được, nên đưa ra vào thời điểm nào, có thể trình bày phương án thay thế nào. Những phán đoán này phụ thuộc vào cảm nhận về mặt bằng thị trường nên tri thức từ bên ngoài phát huy tác dụng.

Có hai điều kiện để đường ranh giới này vận hành được. Một là đừng để phía nội bộ chỉ có một người phụ trách. Ở Thái Lan chuyển việc là chuyện phổ biến, nên hãy bố trí tối thiểu 2 người biết sổ theo dõi nằm ở đâu và cách vận hành việc gia hạn. Một cuốn sổ theo dõi do một người giữ sẽ trở thành “tập tin tồn tại nhưng không ai mở được” ngay khoảnh khắc người đó nghỉ. Hai là quyết định trước phạm vi thông tin sẽ chuyển ra bên ngoài. Số tiền hợp đồng và điều kiện hợp đồng thì cần chuyển, nhưng thông tin cá nhân của nhân viên thì không. Hãy phân tách rõ rằng thứ cần cho việc rà soát là “số lượng tài khoản” chứ không phải “họ tên”.

Đường ranh giới này cũng phát huy tác dụng ngay ở tình huống bổ sung hệ thống mới. Nếu ngay từ giai đoạn xem xét triển khai đã sắp xếp điều kiện hợp đồng theo đúng các mục của sổ theo dõi thì sau khi vận hành sẽ không phát sinh công việc ghi bổ sung vào sổ. Đừng biến việc triển khai và việc quản lý tài sản thành hai công việc tách rời. Nếu bạn muốn xác nhận từ cấu trúc chi phí triển khai, bài chi phí và cấu trúc phát triển hệ thống nghiệp vụ cũng là tài liệu tham khảo hữu ích.

Những điểm riêng có tác động tại cơ sở Thái Lan và ASEAN

Chúng tôi nêu ra những điểm không xuất hiện trong các cuộc thảo luận tại Nhật Bản nhưng lại phát sinh khi vận hành ở Thái Lan.

Sự pha trộn của đồng tiền hợp đồng và phương thức thanh toán. Hợp đồng CNTT tại cơ sở Thái Lan pha trộn giữa THB, USD và JPY. SaaS toàn cầu thanh toán bằng thẻ tín dụng theo USD, nhà cung cấp Nhật Bản xuất hóa đơn theo JPY qua trụ sở chính, nhà cung cấp bản địa chuyển khoản theo THB. Khi lập sổ theo dõi, nếu xếp ba loại này vào cùng một cột thì không cộng ra tổng được. Trên thực tế, hãy tách sổ thành cột “đồng tiền hợp đồng” và cột “số tiền quy đổi THB”, rồi cố định ngày làm chuẩn cho tỷ giá quy đổi. Nếu chỉ rà soát mỗi năm một lần thì lấy tỷ giá cuối kỳ để quy về là cách dễ xử lý.

Ranh giới giữa hợp đồng của trụ sở chính và hợp đồng bản địa. Như đã nói ở trên, các dịch vụ mà trụ sở chính ký như chuẩn chung toàn tập đoàn sẽ không có trong sổ theo dõi tại chỗ. Nhưng người dùng ID lại là nhân viên tại chỗ. Điều cần chốt ở đây chỉ là một điểm duy nhất, đó là khi có người nghỉ việc thì ai sẽ là người dừng tài khoản. Nếu chi phí do trụ sở chính gánh thì phía tại chỗ khó có động cơ để dừng. Nhưng nếu không dừng thì trạng thái người đã nghỉ việc vẫn truy cập được dữ liệu của công ty sẽ tiếp diễn. Hãy tách câu chuyện chi phí ra khỏi câu chuyện an toàn thông tin, và nhất định đưa vế sau vào phần vận hành tại chỗ.

Ngôn ngữ và nơi lưu hợp đồng. Nếu hợp đồng nằm phân tán ở tiếng Thái, tiếng Anh và tiếng Nhật thì số người có thể xác nhận điều kiện lúc gia hạn sẽ rất hạn chế. Không cần dịch toàn văn, nhưng riêng bốn mục gồm thời hạn hợp đồng, điều kiện gia hạn, hạn chót thông báo chấm dứt và cơ cấu tính phí thì xin hãy chép sang sổ theo dõi bằng tiếng Nhật hoặc tiếng Anh. Dù bản gốc bằng ngôn ngữ nào thì thông tin cần cho việc ra quyết định vẫn ở trạng thái đọc được.

Tần suất thay người phụ trách. Theo cảm nhận từ hiện trường, việc người phụ trách hệ thống phía Thái Lan thay sau 2 đến 3 năm và quản lý người Nhật thay sau 3 đến 5 năm không phải hiếm. Nếu thiết kế trên tiền đề đó thì hãy đặt sổ theo dõi ở thư mục dùng chung chứ không phải máy tính cá nhân, để đầu mối liên hệ hợp đồng là địa chỉ dùng chung của bộ phận, và đặt người nhận cảnh báo gia hạn là nhiều người. Về mặt kỹ thuật thì cả ba đều đơn giản, nhưng không quyết định trước thì chúng không tự nhiên mà thành.

Tập quán thương mại khi gia hạn hợp đồng với nhà cung cấp bản địa. Trong hợp đồng với nhà cung cấp Thái Lan, việc rà soát lại điều kiện lúc gia hạn đôi khi không được hình thức hóa chặt như ở Nhật Bản. Nói ngược lại, nếu phía bạn mang dữ liệu sử dụng thực tế ra đàm phán thì vẫn còn dư địa để điều kiện dịch chuyển. Sở dĩ ở hợp đồng số 7 của trường hợp mô hình điều chỉnh được 48,000 cũng là nhờ có bằng chứng rằng các chức năng bổ sung không được dùng tới. Đàm phán không có dữ liệu sẽ thành mặc cả giá, còn đàm phán có dữ liệu sẽ thành thiết kế lại điều kiện.

Việc triển khai biểu mẫu điện tử và dịch vụ đám mây tại chỗ. Tại cơ sở Thái Lan có sự pha trộn giữa trường hợp mang nguyên sản phẩm đang dùng ở trụ sở chính Nhật Bản sang, và trường hợp mua sắm tại chỗ. Cũng có sản phẩm mà cơ cấu bản quyền khác nhau tùy quốc gia, nên xác nhận hình thức cung cấp tại chỗ trước khi ký là an toàn. Ví dụ trong lĩnh vực biểu mẫu điện tử, có những sản phẩm mà chính cách đếm bản quyền sẽ quyết định cấu trúc chi phí, như trình bày trong bài giá và cơ cấu bản quyền của i-Reporter.

10 mục cần ghi trong bảng rà soát

Về định dạng của sổ theo dõi, chúng tôi nêu ra những mục tối thiểu cần chuẩn bị. Tất cả đều là những mục chỉ phát huy tác dụng khi được viết ra giấy chứ không phải giữ trong trí nhớ.

• Tên hệ thống và nhà cung cấp. Ghi cả tên tiếng Nhật lẫn tên tiếng Anh, để tránh việc gọi tên lệch nhau khi liên hệ với nhà cung cấp
• Bộ phận phê duyệt và người chịu trách nhiệm quản lý hiện nay. Ghi tên người có thể ra quyết định ở thời điểm hiện tại, chứ không phải người đã phê duyệt lúc ký
• Hình thái hợp đồng. Mua đứt, thuê bao theo năm hay tính phí theo tháng. Ghi luôn vào cùng cột việc có tự động gia hạn hay không
• Đơn vị tính phí. Theo ID người dùng, theo số kết nối đồng thời, theo cơ sở, hay theo dung lượng dữ liệu. Đây chính là nguồn phát sinh chi phí biến đổi
• Số lượng đã ký và số lượng dùng thực tế. Xếp cạnh nhau số ID đã ký và số ID thực sự đăng nhập trong 1 tháng gần nhất
• Phí năm và đồng tiền của khoản phí đó. Giữ số tiền quy đổi THB ở một cột riêng và ghi rõ ngày làm chuẩn cho việc quy đổi
• Ngày bắt đầu hợp đồng và ngày gia hạn. Nếu ngày gia hạn chỉ được biết dưới dạng “1 năm sau khi ký” thì hãy tính ra ngày thực tế mà ghi vào
• Hạn chót thông báo chấm dứt. Ghi bằng chính ngày tháng cụ thể là cần đề nghị trước ngày gia hạn bao nhiêu ngày
• Thẻ chức năng chính. Phân loại thô như xử lý hỏi đáp, biểu mẫu, tồn kho, thu thập số liệu thực tế, chấm công, luồng phê duyệt là đủ
• Nơi lưu dữ liệu và cách xử lý khi nghỉ việc. Dữ liệu nằm ở đâu trên đám mây, và khi người dùng nghỉ việc thì ai làm gì

Trong 10 mục, mục thường không điền được đầu tiên là mục thứ tám, hạn chót thông báo chấm dứt. Vì không mở hợp đồng ra thì không biết, hơn nữa với hợp đồng trực tuyến thì nó nằm trong điều khoản sử dụng. Công việc lấp mục này khá tốn công, nhưng vì đây là mục quyết định thời điểm còn đàm phán được nên xin đừng lược bỏ.

Mục thứ năm, số lượng đã ký và số lượng dùng thực tế, cũng thường bị bỏ trống ở nhiều nhà máy. Bởi vì số lượng dùng thực tế phải lấy từ màn hình quản trị của dịch vụ chứ không được ghi trong hợp đồng. Nhưng ngay khoảnh khắc hai con số này được xếp cạnh nhau, các ứng viên để cắt giảm sẽ tự động nổi lên. Cả 5 suất tài khoản bỏ quên phát hiện ở hợp đồng số 6 của trường hợp mô hình cũng có thể được tìm ra ngay trong lần rà soát đầu tiên nếu xếp hai cột này cạnh nhau.

Nếu công ty bạn đã có sổ theo dõi, hãy thử đếm xem trong 10 mục này có bao nhiêu mục đã được điền. Nếu dưới 5 mục thì cuốn sổ đó tuy vẫn hoạt động như một bản ghi tài sản, nhưng đang ở trạng thái không dùng được cho việc quản lý chi phí.

Năm kiểu thất bại thường gặp

Chúng tôi nêu ra 5 thất bại đã thực sự chứng kiến tại các nhà máy Nhật Bản ở Thái Lan.

Bắt đầu từ số lượng máy tính. Đây là kiểu phổ biến nhất. Nghe tới quản lý tài sản CNTT là bắt tay ngay vào kiểm kê thiết bị đầu cuối. Khối lượng công việc lớn, cảm giác hoàn thành cũng lớn, nhưng nhìn từ cơ cấu chi tiêu thì hiệu quả hạn chế. Như đã nói, trung tâm chi tiêu hiện nay đã dịch sang hợp đồng phần mềm và đám mây. Chúng tôi không nói đừng kiểm kê thiết bị đầu cuối, nhưng thứ tự thì hợp đồng phải đi trước. Việc rà soát hợp đồng thường kết thúc trong thời gian ngắn hơn so với việc kiểm đếm toàn bộ thiết bị đầu cuối, và hiệu quả tính bằng tiền cũng ra sớm hơn.

Lập sổ theo dõi chỉ trong phạm vi bộ phận CNTT. Dù có sắp xếp cẩn thận tới đâu những hợp đồng mà bộ phận CNTT nắm được thì, như đã thấy trong trường hợp mô hình, đó cũng chỉ là một nửa chi tiêu. Cửa vào của công việc lập sổ không phải thư mục hợp đồng của bộ phận CNTT, mà là dữ liệu thanh toán của kế toán. Nhầm chỗ này thì kết quả là một cuốn sổ chính xác cao nhưng chỉ có một nửa.

Đi nói chuyện với các bộ phận bằng lăng kính “tiêu tiền lãng phí”. Hợp đồng kiểu cấp bộ phận là thứ mà bộ phận đó đã triển khai bằng một quyết định chính đáng để giải quyết bài toán nghiệp vụ. Nếu truyền đạt kết quả rà soát bằng từ ngữ “có lãng phí” thì bộ phận sẽ phòng thủ, và từ lần sau thông tin sẽ không còn được đưa ra nữa. Quản lý tài sản CNTT là hoạt động vận hành liên tục, nên một mối quan hệ mà thông tin tiếp tục chảy về có giá trị hơn một lần cắt giảm.

Lập xong sổ theo dõi rồi coi như đã xong. Khi lần rà soát đầu tiên tạo ra hiệu quả cắt giảm, người ta dễ có cảm giác đã kết thúc một chặng. Nhưng sổ theo dõi bắt đầu cũ đi ngay từ khoảnh khắc nó được lập. Nửa năm sau sẽ có thêm 2 hợp đồng mới, một năm sau thì điều kiện gia hạn đã đổi. Nếu không đi tới được giai đoạn cuối là giám sát gia hạn thì 2 năm sau mọi thứ sẽ quay lại đúng trạng thái cũ. Lập sổ là công việc, giám sát gia hạn là vận hành. Hai thứ này là hai thứ khác nhau.

Phó mặc hoàn toàn việc dọn tài khoản người nghỉ việc cho bộ phận nhân sự. Đây là trường hợp trong danh mục kiểm tra thủ tục nghỉ việc chỉ có đúng một dòng ghi “dừng tài khoản hệ thống”, mà không ghi cụ thể là hệ thống nào. Người phụ trách nhân sự không giữ danh sách toàn bộ hệ thống nên chỉ dừng được những gì mình biết. Các hợp đồng ngoài sổ theo dõi đương nhiên bị lọt khỏi đó. Biện pháp là liệt kê riêng từng tên hệ thống vào danh mục kiểm tra thủ tục nghỉ việc. Nếu đã có sổ theo dõi thì có thể dùng luôn nó làm danh sách.

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

Quản lý tài sản CNTT là quản lý những gì?

Đó là hoạt động nắm bắt tập trung phần cứng, phần mềm, cùng các hợp đồng và bản quyền gắn với chúng, với tư cách tài sản của công ty. Ở nhà máy, người ta thường bắt đầu từ việc quản lý thiết bị đầu cuối như phần nối dài của sổ tài sản thiết bị, nhưng trung tâm chi tiêu hiện nay đã dịch sang hợp đồng phần mềm và đám mây. Ngay trong báo cáo thị trường Thái Lan của Mordor Intelligence, cơ cấu thị trường năm 2025 cũng cho thấy phần mềm chiếm 41.72% và theo hình thức triển khai thì đám mây chiếm 55.84%. Vì vậy, trong quản lý tài sản CNTT của nhà máy cần lập một sổ theo dõi hợp đồng tách khỏi sổ theo dõi đồ vật, và quản lý bộ phận phê duyệt, phí năm, đơn vị tính phí, ngày gia hạn cùng hạn chót thông báo chấm dứt.

Quản lý bản quyền phần mềm nên bắt đầu từ đâu?

Hãy bắt đầu từ dữ liệu thanh toán của kế toán chứ không phải thư mục hợp đồng. Dù có sắp xếp toàn bộ những hợp đồng mà bộ phận CNTT nắm được thì, như đã thấy trong trường hợp mô hình, nó cũng chỉ ra khoảng một nửa chi tiêu. Hãy xếp dữ liệu thanh toán theo từng bộ phận, trích các mục liên quan tới CNTT từ dữ liệu hoàn ứng chi phí, và mở hóa đơn tới tận dòng chi tiết. Từ ba nơi này bạn sẽ nhặt ra được ba kiểu hợp đồng, gồm kiểu cấp bộ phận, kiểu cá nhân và kiểu đi kèm. Sau khi bao phủ xong mới tiến sang bước rà soát, tức đối chiếu số lượng đã ký với số lượng dùng thực tế. Nếu ngay từ đầu đã định phán xét tính hợp lý của số tiền thì công việc sẽ đứng lại, nên hãy tập trung vào việc xếp ra trước đã.

Để đối phó shadow IT thì trước hết nên chặn cái gì?

Không bắt đầu bằng việc chặn thì kết quả lại tốt hơn. Người phụ trách bắt đầu dùng công cụ bằng hợp đồng cá nhân là vì có nhu cầu công việc. Cấm đồng loạt thì họ chỉ dịch chuyển sang một chỗ còn khó nhìn thấy hơn. Về mặt thực hành, trước hết hãy nắm sự tồn tại của chúng từ dữ liệu hoàn ứng chi phí, rồi chuyển những thứ thực sự cần cho công việc sang hợp đồng của công ty. Trên nền đó, làm rõ nơi lưu dữ liệu và cách xử lý khi nghỉ việc. Cybernet System cũng nêu thách thức rằng đám mây cần được quản lý theo từng ID người dùng và mang rủi ro biến thành shadow IT. Việc chỉnh đơn vị quản lý về đúng ID là biện pháp phải đi trước việc cấm đoán.

Nên cơ chế hóa việc quản lý gia hạn hợp đồng hệ thống như thế nào?

Hãy quản lý theo hạn chót thông báo chấm dứt chứ không theo ngày gia hạn. Nhiều hợp đồng SaaS quy định rằng nếu đề nghị trước ngày gia hạn một số ngày nhất định thì được thay đổi điều kiện hoặc chấm dứt. Qua mốc đó thì năm tài chính ấy không dịch chuyển được điều kiện nữa. Hãy ghi hạn chót thông báo chấm dứt vào sổ theo dõi dưới dạng ngày tháng, và đặt cảnh báo bật lên trước đó 30 ngày. Người nhận cảnh báo nên là nhiều người chứ không phải một cá nhân, đồng thời đổi luôn địa chỉ email liên hệ của hợp đồng sang địa chỉ dùng chung của bộ phận. Tạo ra trạng thái mà người phụ trách có thay đổi thì thông báo vẫn tiếp tục đến nơi, đó chính là thực chất của việc cơ chế hóa.

Việc minh bạch hóa ngân sách CNTT phải làm tới đâu mới có hiệu quả?

Chỉ cần phí năm theo từng hợp đồng được xếp lên một trang và cộng ra được tổng, hiệu quả đầu tiên đã xuất hiện. Trong trường hợp mô hình, ngay tại thời điểm xếp 7 hợp đồng lên một trang đã thấy được rằng “phần có trong sổ theo dõi chỉ chiếm 49.5% tổng chi tiêu”, và từ đó ba biện pháp đã dẫn tới mức cắt giảm 216,000 THB mỗi năm, tương đương tỷ lệ 16.8%. Ở bước tiếp theo, khi xếp cạnh nhau số lượng đã ký và số lượng dùng thực tế thì các ứng viên cắt giảm sẽ nổi lên cụ thể. Không cần xây dựng ngay từ đầu hệ thống tự động thu thập số liệu sử dụng hay bảng điều khiển. Một trang Excel cùng cảnh báo theo ngày gia hạn là đã đủ để vận hành.

Tổng kết

Chúng tôi xin sắp xếp lại các điểm chính.

Quản lý tài sản CNTT trong nhà máy đổ vỡ không phải vì số lượng hệ thống tăng lên, mà vì người phê duyệt hợp đồng bị phân tán ra ngoài bộ phận CNTT. Bộ phận phê duyệt khác nhau thì nơi lưu hợp đồng và đầu mối nhận thông báo gia hạn cũng khác nhau, và thông tin không tới được bộ phận CNTT. Sổ theo dõi chỉ được lấp đầy một nửa không phải do người phụ trách thiếu nỗ lực, mà do tuyến đường của thông tin chưa được thiết kế.

Đối tượng cần quản lý cũng đã thay đổi. Đếm đồ vật theo lối tư duy của sổ tài sản thiết bị thì không bắt được chi tiêu của ngày hôm nay. Trên thị trường CNTT và an ninh của Thái Lan, cơ cấu năm 2025 cho thấy phần mềm chiếm 41.72% và theo hình thức triển khai thì đám mây chiếm 55.84%. Đơn vị quản lý không phải mã tài sản mà là số hợp đồng, và thứ cần ghi lại không phải vị trí lắp đặt mà là bộ phận phê duyệt, phí năm, đơn vị tính phí, ngày gia hạn và hạn chót thông báo chấm dứt.

Trong tính toán của trường hợp mô hình, tổng phí năm của 7 hợp đồng mà nhà máy lắp ráp linh kiện điện tử tại Rayong đang mang là 1,284,000 THB, trong đó phần có mặt trong sổ theo dõi chỉ dừng ở 636,000 THB, tương đương 49.5% tổng chi tiêu. Ở 3 hợp đồng nằm ngoài sổ, lần lượt phát hiện việc phí năm tăng từ 216,000 lên 264,000 do tự động gia hạn (chênh lệch 48,000, tức 22.2%), một hợp đồng trùng lặp chỉ được dùng 18 lượt trong 90 lượt mỗi tháng (20.0%), và khoản lãng phí 48,000 mỗi năm do bỏ quên 5 suất tài khoản của người đã nghỉ việc. Ba biện pháp thực hiện sau rà soát đã cắt giảm 216,000 THB mỗi năm, tỷ lệ cắt giảm là 16.8%, và lũy kế đơn thuần trong 5 năm là 1,080,000 THB. Đây là tính toán riêng chứ không phải số liệu của doanh nghiệp có thật, nên mời bạn nhìn vào cấu trúc, tức là rò rỉ sinh ra ở đâu và bịt lại bằng cách nào, chứ không phải nhìn vào số tiền.

Về mặt thực hành, hãy tiến theo bốn giai đoạn gồm hoàn thiện sổ theo dõi, rà soát, hợp nhất hợp đồng và giám sát gia hạn. Giai đoạn bị xem nhẹ nhất và hiệu quả nhất là giai đoạn thứ tư, giám sát gia hạn. Sổ theo dõi chỉ đúng 8 phần 10 nhưng có giám sát gia hạn thì vẫn vận hành được, còn sổ đúng 10 phần 10 mà không được cập nhật thì 2 năm là quay về như cũ. Đường ranh giới thực tiễn là giữ trong nội bộ sổ theo dõi, giám sát gia hạn và việc dọn tài khoản, còn phần có thể giao ra bên ngoài là phân tích lần đầu và thiết kế đàm phán.

Tại cơ sở Thái Lan, sự pha trộn của đồng tiền hợp đồng, ranh giới giữa hợp đồng của trụ sở chính và hợp đồng bản địa, sự phân tán ngôn ngữ của hợp đồng, cùng tần suất thay người phụ trách đều tác động theo hướng làm đổ vỡ sổ theo dõi. Chính vì vậy mà những thiết kế đơn giản như đặt sổ trong thư mục dùng chung, để đầu mối liên hệ là địa chỉ dùng chung và đặt người nhận cảnh báo là nhiều người lại phát huy tác dụng.

Trước hết, hãy thử bắt đầu từ việc xếp toàn bộ các hợp đồng liên quan tới CNTT mà công ty đang trả tiền lên cùng một trang. Chỉ riêng việc đó đã cho bạn thấy tỷ lệ mình thực sự nắm được là bao nhiêu.

Bạn hoàn toàn có thể liên hệ với chúng tôi ngay cả khi đang ở giai đoạn chưa biết công ty mình có bao nhiêu hợp đồng. TOMAS TECH triển khai và vận hành các hệ thống nghiệp vụ, trong đó có hệ thống quản lý sản xuất, cho các nhà máy Nhật Bản tại Thái Lan, và cũng nhận tư vấn ngay từ bước sắp xếp lại danh sách hợp đồng hiện hữu cùng bạn. Chúng tôi hoan nghênh cả những trao đổi không đặt tiền đề là triển khai hệ thống mới, nên nếu bạn muốn sắp xếp lại hiện trạng trước đã, mời liên hệ với chúng tôi tại đây.

Thông tin tham khảo

• OpenLM Japan — Hướng dẫn so sánh toàn diện các giải pháp quản lý bản quyền dành cho CNTT doanh nghiệp, phiên bản 2026 (tháng 6 năm 2026)
• Cybernet System — Các thách thức sắp tới của quản lý tài sản CNTT (chuyên mục kiến thức quản lý tài sản CNTT)
• Cybernet System — Tầm quan trọng của quản lý bản quyền phần mềm và các điểm cần lưu ý (chuyên mục kiến thức quản lý tài sản CNTT)
• Money Forward Admina — Cẩm nang cắt giảm chi phí SaaS và quản lý bản quyền dành cho bộ phận hệ thống thông tin (công bố tháng 1 năm 2026, cập nhật tháng 4 năm 2026)
• Mordor Intelligence — Thailand IT and Security Market Size and Share Analysis (cập nhật tháng 8 năm 2026)
• dxeco — Shadow IT là gì, rủi ro tiềm ẩn, nguyên nhân và 5 bước từ khảo sát tới đối sách (chuyên mục dxeco)