Checklist kiểm kê phần mềm và bản quyền cho SME

TL;DR: Checklist kiểm kê phần mềm doanh nghiệp cần trả lời sáu câu hỏi: đang dùng gì, ai chịu trách nhiệm, bao nhiêu tài khoản hoạt động, dữ liệu nằm đâu, khi nào gia hạn và quy trình nào sẽ dừng nếu công cụ bị ngắt. Chỉ sau khi có danh mục này, doanh nghiệp mới nên quyết định giữ, thay, tích hợp hay loại bỏ.

Kiểm kê trước, sau đó phân loại theo bốn hướng: giữ, thay, tích hợp hoặc loại bỏ.

Một khoản phí phần mềm xuất hiện trên sao kê không có nghĩa đó là toàn bộ công cụ doanh nghiệp đang dùng. Một tài khoản không đăng nhập trong 30 ngày cũng chưa chắc có thể hủy. Và hai ứng dụng có chức năng giống nhau chưa chắc đang phục vụ cùng một quy trình.

Vì vậy, kiểm kê không phải là lập một danh sách tên app cho đủ. Đầu ra cần là bản đồ công cụ, người dùng, dữ liệu và phụ thuộc vận hành — đủ rõ để mỗi quyết định cắt giảm không tạo ra một sự cố mới.

ℹ️ Info: Phạm vi tư vấn: Bài viết cung cấp khung kiểm kê công cụ và vận hành, không phải ý kiến pháp lý hay cuộc kiểm toán tuân thủ. Khi cần kết luận về quyền sử dụng, điều khoản hợp đồng hoặc nghĩa vụ pháp lý, doanh nghiệp nên đối chiếu hồ sơ gốc và tham vấn chuyên gia phù hợp.

Vì sao phải kiểm kê trước khi đổi phần mềm?

Doanh nghiệp phải kiểm kê trước khi chuyển đổi vì danh sách phần mềm hiện tại chứa cả những phụ thuộc không thể nhìn thấy từ hóa đơn: dữ liệu lịch sử, tài khoản tích hợp, biểu mẫu đang nhúng trên website, quy trình phê duyệt và thói quen bàn giao giữa các phòng ban. Hủy một công cụ trước khi nhận diện các phụ thuộc này có thể tiết kiệm một khoản license nhưng làm dừng công việc quan trọng hơn nhiều.

Ba cách bắt đầu thường dẫn đến quyết định sai:

• Chỉ hỏi kế toán đang trả tiền cho app nào. Cách này bỏ sót gói miễn phí, app nhân viên tự đăng ký, phần mềm đi kèm thiết bị và tài khoản do phòng ban thanh toán riêng.
• Chỉ hỏi IT có những tài khoản nào. IT có thể quản lý danh tính và thiết bị nhưng không luôn biết quy trình nghiệp vụ đang phụ thuộc vào từng công cụ.
• Chỉ so tính năng trên website nhà cung cấp. Hai sản phẩm cùng có chat, lưu trữ hay biểu mẫu nhưng khác nhau ở dữ liệu, phân quyền, tích hợp và cách đội ngũ đang dùng.

Kiểm kê đúng giúp doanh nghiệp chuyển câu hỏi từ “app nào đắt?” sang bốn câu hỏi hữu ích hơn:

1. Công cụ nào đang tạo giá trị và cần giữ?
2. Chức năng nào đang bị mua trùng?
3. Hệ thống nào có thể chuyển hoặc gom về một workspace chung?
4. Hệ thống chuyên dụng nào phải giữ và tích hợp thay vì cố thay thế?

Nếu doanh nghiệp chưa rõ vì sao danh mục công cụ thường phình ra theo thời gian, hãy đọc thêm bài vì sao càng nhiều phần mềm, doanh nghiệp càng khó kiểm soát bản quyền và dữ liệu.

Chuẩn bị gì trước khi bắt đầu kiểm kê?

Một cuộc kiểm kê nhỏ vẫn cần phạm vi, người chịu trách nhiệm và ngày chốt dữ liệu. Nếu không, mỗi phòng ban sẽ gửi một phiên bản khác nhau và danh mục hết hạn ngay khi vừa hoàn thành.

Checklist chuẩn bị

• Chỉ định một owner của danh mục, có quyền yêu cầu các phòng ban xác nhận thông tin.
• Chốt phạm vi: toàn doanh nghiệp hay một nhóm công cụ, phòng ban hoặc pháp nhân.
• Chốt ngày ghi nhận dữ liệu để số tài khoản, chi phí và trạng thái không bị trộn giữa nhiều thời điểm.
• Thu thập hợp đồng, hóa đơn, email gia hạn và sao kê thanh toán liên quan.
• Xuất danh sách tài khoản từ hệ thống quản trị nếu nhà cung cấp hỗ trợ.
• Hỏi từng trưởng bộ phận về app do nhân viên tự đăng ký hoặc tự thanh toán.
• Ghi nhận cả gói miễn phí, bản dùng thử, tài khoản dùng chung và công cụ cài trên máy.
• Thống nhất bốn nhãn quyết định: giữ, thay, tích hợp, loại bỏ.
• Đặt ngày duyệt danh mục và người có quyền phê duyệt từng thay đổi.

⚠️ Warning: Không yêu cầu nhân viên gửi mật khẩu, mã khôi phục hoặc token tích hợp vào bảng kiểm kê. Danh mục chỉ cần ghi người quản trị, phương thức đăng nhập, phạm vi quyền và nơi lưu bí mật theo chính sách nội bộ.

Danh mục kiểm kê phần mềm cần có những trường nào?

Danh mục tối thiểu phải cho biết công cụ phục vụ ai, ai chịu trách nhiệm, dữ liệu ở đâu, khi nào phát sinh nghĩa vụ gia hạn và điều gì phụ thuộc vào nó. Chỉ ghi tên phần mềm và giá là chưa đủ để ra quyết định chuyển đổi.

Dùng bảng sau làm mẫu khởi đầu:

Cách điền để danh mục dùng được

• Phần mềm: Ghi đúng tên sản phẩm và gói đang dùng nếu đã xác minh; không suy đoán theo tên trên sao kê.
• Bộ phận: Liệt kê các đơn vị thực sự sử dụng, không chỉ bộ phận đứng tên mua.
• Chủ sở hữu: Chọn một business owner chịu trách nhiệm về nhu cầu nghiệp vụ. Nhà cung cấp hoặc nhân viên IT không phải business owner.
• User hoạt động: Dùng định nghĩa phù hợp với công cụ. Có nơi cần nhìn đăng nhập; có nơi phải nhìn tác vụ, giao dịch hoặc dữ liệu phát sinh.
• Chi phí: Ghi kỳ thanh toán, thuế và đơn vị tiền tệ nếu có. Đánh dấu “chờ đối chiếu” thay vì tự ước lượng.
• Gia hạn: Ghi ngày, chu kỳ, thời hạn báo hủy và người nhận thông báo.
• Dữ liệu: Nêu loại dữ liệu, vị trí lưu và đầu mối quản trị; không chép dữ liệu nhạy cảm vào danh mục.
• Phụ thuộc: Ghi quy trình, thiết bị, biểu mẫu, API, tài khoản dịch vụ và báo cáo liên quan.
• Quyết định: Chỉ gắn nhãn sau khi business owner, IT và tài chính đã xác nhận phần việc của họ.

Doanh nghiệp có thể bổ sung các trường như nhà cung cấp, số license đã mua, phương thức đăng nhập, mức độ quan trọng, điều khoản lưu dữ liệu, khả năng export và người phê duyệt. Mục tiêu không phải tạo bảng càng dài càng tốt, mà là đủ dữ kiện để không hủy nhầm.

Checklist kiểm kê phần mềm theo từng bước

Quy trình dưới đây đi từ bằng chứng thanh toán tới việc xác nhận nghiệp vụ. Mỗi bước tạo ra một đầu ra có người chịu trách nhiệm, thay vì một buổi họp chung rồi không ai cập nhật bảng.

Bước 1: Lập danh sách ban đầu từ nhiều nguồn

Gom dữ liệu từ kế toán, IT, danh sách đăng nhập tập trung, thiết bị công ty và trưởng các phòng ban. Đừng dùng riêng một nguồn làm danh mục chính thức vì mỗi nguồn chỉ thấy một phần hiện trạng.

Bước 2: Xác định owner và người quản trị

Mỗi công cụ cần một business owner xác nhận nhu cầu và một đầu mối quản trị tài khoản. Nếu chưa tìm được owner, đánh dấu để điều tra; đừng mặc định công cụ không còn cần thiết.

Bước 3: Đối chiếu tài khoản được cấp với mức sử dụng

So danh sách license với nhân sự hiện tại và dữ liệu hoạt động phù hợp. Tách rõ tài khoản đang dùng, chưa kích hoạt, tạm nghỉ, tài khoản dịch vụ và tài khoản của người đã rời công ty.

Bước 4: Ghi vị trí dữ liệu và khả năng lấy dữ liệu ra

Xác định loại dữ liệu đang lưu, ai có quyền truy cập, dữ liệu nào cần giữ và phương án export nếu dừng dịch vụ. Kiểm tra bằng thao tác thực tế hoặc tài liệu chính thức, không dựa vào giả định.

Bước 5: Vẽ các phụ thuộc vận hành

Với mỗi công cụ, hỏi: nếu ngắt vào sáng mai thì quy trình nào dừng? Ghi cả tích hợp tự động, biểu mẫu, link chia sẻ, báo cáo, lịch nhắc và công việc thủ công dựa trên công cụ đó.

Bước 6: Đối chiếu hợp đồng và ngày gia hạn

Xác nhận số lượng, chu kỳ thanh toán, người nhận hóa đơn và điều kiện thay đổi hoặc chấm dứt. Nếu hồ sơ thiếu, ghi trạng thái cần làm rõ; không biến suy đoán thành dữ liệu chính thức.

Bước 7: Phân loại và duyệt quyết định

Gắn nhãn giữ, thay, tích hợp hoặc loại bỏ. Với mọi thay đổi, ghi người duyệt, việc cần hoàn thành trước khi thực hiện và phương án quay lại nếu pilot thất bại.

Kiểm tra nhanh trước khi đóng đợt kiểm kê

• Mọi dòng đều có business owner hoặc trạng thái cần xác minh.
• Tài khoản của người đã nghỉ đã được rà soát theo quy trình offboarding.
• Tài khoản dịch vụ và tích hợp không bị nhầm với license nhàn rỗi.
• App tự đăng ký và gói miễn phí đã được ghi nhận.
• Ngày gia hạn và đầu mối nhận thông báo đã được xác nhận.
• Dữ liệu cần lưu và cách lấy dữ liệu ra đã được ghi.
• Mỗi đề xuất loại bỏ đều có kiểm tra phụ thuộc và người phê duyệt.
• Danh mục có ngày cập nhật gần nhất và lịch rà soát tiếp theo.

Làm sao phát hiện license trùng lặp và tài khoản không còn dùng?

Hãy tìm sự trùng lặp ở cấp nhu cầu và quy trình, không chỉ ở danh sách tính năng. Hai công cụ đều có quản lý công việc có thể đang phục vụ hai nhóm hoàn toàn khác nhau; ngược lại, một nhân viên có thể dùng ba công cụ cho cùng một việc vì không có tiêu chuẩn chung.

Dấu hiệu cần kiểm tra

• Một người được cấp nhiều công cụ cho cùng một tác vụ như chat, họp, lưu file hoặc giao việc.
• Phòng ban mua riêng một app trong khi doanh nghiệp đã có tính năng tương đương ở nền tảng chung.
• License đã cấp nhưng chưa kích hoạt hoặc không phát sinh tác vụ trong khoảng quan sát phù hợp.
• Tài khoản thuộc về nhân viên đã nghỉ, nhà thầu đã kết thúc công việc hoặc email không còn tồn tại.
• Nhiều gói thử nghiệm tự chuyển sang trả phí nhưng không có owner.
• Một tài khoản dùng chung khiến doanh nghiệp không biết ai đang truy cập và không thể thu hồi theo từng người.

Không nên dùng duy nhất số lần đăng nhập để kết luận. Công cụ ký số, báo cáo theo quý hoặc xử lý sự cố có thể ít mở nhưng vẫn quan trọng. Với mỗi license nghi ngờ không còn dùng, hãy hỏi thêm:

1. Có dữ liệu hoặc lịch sử nào cần giữ không?
2. Có tích hợp nào đang chạy bằng tài khoản này không?
3. Có thời điểm nghiệp vụ đặc biệt khiến công cụ chỉ dùng theo tháng hoặc quý không?
4. Nếu thu hồi, người dùng có phương án thay thế đã được thử chưa?

Phân loại phần mềm thành giữ, thay, tích hợp và loại bỏ

Bốn nhãn này buộc doanh nghiệp nói rõ ý định với từng công cụ. “Để xem sau” có thể vẫn cần, nhưng phải có owner và hạn xử lý thay vì nằm vô thời hạn trong bảng.

Một công cụ có thể được phân loại khác nhau theo phạm vi. Ví dụ, doanh nghiệp có thể giữ phần mềm chuyên ngành làm hệ thống nguồn, nhưng thay kênh chat và bảng theo dõi thủ công xung quanh nó bằng một workspace chung. Bài kiến trúc giữ LarkSuite và tích hợp Odoo minh họa rõ cách phân ranh giới này. Đây thường là quyết định an toàn hơn việc buộc một nền tảng phải thay mọi thứ.

Nếu cần đưa chi phí chuyển đổi vào quyết định, dùng khung trong bài cách tính tổng chi phí sở hữu của bộ công cụ làm việc, thay vì chỉ so phí license.

Những quy trình nào cần pilot trước khi chuyển?

Mọi quy trình có ảnh hưởng đến doanh thu, thanh toán, dữ liệu quan trọng, nhiều phòng ban hoặc tích hợp bên ngoài đều nên được pilot trước khi mở rộng. Pilot là thử nghiệm có phạm vi, owner, tiêu chí thành công và đường lui; không phải cho vài người dùng thử tự do rồi hỏi họ có thích giao diện hay không.

Ưu tiên pilot khi quy trình có một trong các đặc điểm sau:

• Nhiều vai trò cùng nhập, duyệt hoặc nhận thông báo.
• Có deadline cố định mà trễ sẽ ảnh hưởng khách hàng hoặc báo cáo.
• Dữ liệu phải chuyển từ hệ thống cũ hoặc đồng bộ với hệ thống khác.
• Có phân quyền khác nhau giữa nhân viên, quản lý và đối tác.
• Đang phụ thuộc vào file, bot, API hoặc tài khoản dịch vụ.
• Người dùng phải hoàn thành một tác vụ cốt lõi hằng ngày.

Cổng qua pilot tối thiểu

• Quy trình chạy được từ đầu đến cuối bằng dữ liệu thử nghiệm phù hợp.
• Business owner xác nhận kết quả nghiệp vụ đúng.
• Quyền truy cập được kiểm tra theo từng vai trò.
• Người dùng pilot tự hoàn thành tác vụ chính.
• Lỗi chặn công việc đã được xử lý hoặc có phương án rõ ràng.
• Dữ liệu phát sinh trong giai đoạn chạy song song được đối chiếu.
• Có cách quay về hệ thống cũ nếu chưa đạt.

Bài tiếp theo trình bày đầy đủ lộ trình 30–60–90 ngày chuyển đổi LarkSuite, gồm gate, adoption và rollback cho từng giai đoạn.

Ai chịu trách nhiệm duyệt và cập nhật danh mục?

Danh mục cần một owner duy trì, nhưng quyết định không nên thuộc riêng một bộ phận. Mỗi vai trò xác nhận một loại rủi ro khác nhau:

Danh mục nên được rà soát theo lịch phù hợp với chu kỳ mua sắm của doanh nghiệp và ngay khi có sự kiện lớn: đổi nhân sự chủ chốt, sáp nhập phòng ban, triển khai nền tảng mới, gia hạn hợp đồng lớn hoặc phát hiện app tự phát. Không có một tần suất duy nhất đúng cho mọi SME; điều quan trọng là lịch rà soát phải xảy ra trước các quyết định gia hạn, không phải sau khi hóa đơn đã phát sinh.

Điều LarkSuite không thay thế

LarkSuite có thể hợp nhất một phần lớp cộng tác và vận hành nội bộ như chat, lịch, họp, tài liệu, wiki, dữ liệu công việc và workflow, tùy phạm vi triển khai và gói sử dụng. Nhưng LarkSuite không thay thế hệ điều hành và không mặc định thay thế phần mềm kế toán, CAD, thiết kế chuyên nghiệp, chữ ký số hoặc ứng dụng nghiệp vụ đặc thù.

Vì vậy, mục tiêu của kiểm kê không phải chứng minh mọi công cụ đều có thể chuyển sang LarkSuite. Mục tiêu là tìm ra ba ranh giới:

• Nhóm chức năng có thể gom về workspace chung.
• Hệ thống chuyên dụng cần giữ nhưng nên tích hợp.
• Công cụ không còn giá trị hoặc bị mua trùng có thể loại bỏ an toàn.

Sau kiểm kê, doanh nghiệp cần có đầu ra gì?

Một cuộc kiểm kê hoàn chỉnh không kết thúc bằng bảng tính dài. Nó cần tạo ra gói quyết định có thể hành động:

1. Danh mục đã có owner và ngày cập nhật.
2. Danh sách tài khoản cần cấp lại, thu hồi hoặc xác minh.
3. Lịch gia hạn và đầu mối phụ trách.
4. Bản đồ dữ liệu và phụ thuộc quan trọng.
5. Danh sách giữ, thay, tích hợp và loại bỏ đã được duyệt.
6. Một hoặc hai quy trình được chọn để pilot.
7. Tiêu chí qua cổng và phương án rollback.

Khi bảy đầu ra này đã rõ, doanh nghiệp mới có cơ sở để lập ngân sách và roadmap. Nếu chưa rõ, việc mua thêm nền tảng chỉ tạo thêm một dòng trong danh mục phần mềm đang phình ra.

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

Bao lâu nên kiểm kê phần mềm một lần?

Tần suất phụ thuộc chu kỳ mua và mức thay đổi nhân sự, nhưng danh mục phải được rà soát trước các đợt gia hạn quan trọng. Ngoài lịch định kỳ, nên cập nhật khi có nhân sự chủ chốt rời công ty, đổi quy trình, triển khai nền tảng mới hoặc phát hiện công cụ tự đăng ký.

Ai nên chịu trách nhiệm quản lý license?

Nên có một owner quản lý danh mục tập trung, còn thông tin phải được xác nhận bởi business owner, IT và tài chính. Giao toàn bộ cho một bộ phận dễ tạo điểm mù: tài chính thấy chi phí nhưng không thấy phụ thuộc; IT thấy tài khoản nhưng có thể không thấy giá trị nghiệp vụ.

App do nhân viên tự đăng ký có cần đưa vào kiểm kê không?

Có. Cả app miễn phí, bản dùng thử và app tự thanh toán đều có thể chứa dữ liệu công việc hoặc tạo phụ thuộc. Việc đưa vào danh mục không đồng nghĩa cấm ngay; đó là bước để đánh giá nhu cầu, dữ liệu và rủi ro.

Làm sao xử lý tài khoản của nhân viên đã nghỉ?

Thực hiện theo quy trình offboarding: thu hồi hoặc chuyển quyền, xác định dữ liệu cần bàn giao, kiểm tra tích hợp dùng tài khoản đó và lưu bằng chứng xử lý. Không nên xóa ngay trước khi business owner xác nhận dữ liệu và phụ thuộc đã được xử lý.

Có nên hủy ngay phần mềm trùng chức năng không?

Không. Trước tiên phải xác nhận quy trình, dữ liệu, tích hợp, thời hạn hợp đồng và phương án thay thế. Chỉ hủy sau khi pilot đạt, người dùng đã chuyển được tác vụ chính và có người phê duyệt.

Kiểm kê phần mềm có phải kiểm toán pháp lý không?

Không. Kiểm kê vận hành giúp doanh nghiệp biết đang dùng công cụ nào, ai dùng và phụ thuộc gì. Việc kết luận quyền sử dụng hoặc tuân thủ cần dựa trên hợp đồng, điều khoản cấp phép và tư vấn chuyên môn phù hợp.