Tiêu chí chọn phần mềm eOffice: bộ khung chấm điểm cho tổ chức lớn

Câu hỏi thật của người đi chọn phần mềm eOffice không phải "sản phẩm nào tốt nhất", mà "làm sao so sánh được năm bản chào hàng khi cả năm đều nói mình có đủ tính năng". Câu trả lời ngắn: đừng so bảng tính năng, hãy dựng một bộ tiêu chí chấm điểm được của riêng tổ chức, cho trọng số theo mức độ quan trọng, và bắt mọi nhà cung cấp chứng minh trên cùng một kịch bản nghiệp vụ.

Bài này đưa ra bộ tiêu chí chọn phần mềm eOffice chia theo năm tầng, cách quy đổi thành điểm số, quy trình tổ chức một đợt đánh giá thực tế, và những dấu hiệu cảnh báo nên nhận ra sớm. Bộ khung này trung lập, dùng được cho bất kỳ nhà cung cấp nào, kể cả để đánh giá chính hệ thống bạn đang chạy.

Vì sao bảng tính năng luôn dẫn tới quyết định sai

Bảng tính năng có ba khuyết tật cố hữu. Thứ nhất, nó chỉ ghi nhận sự tồn tại chứ không ghi nhận chất lượng: "có phân quyền" có thể là ba vai trò cứng, cũng có thể là ma trận quyền theo đơn vị, theo loại văn bản và theo độ mật. Thứ hai, nó do bên bán soạn, nên mọi ô đều được tick. Thứ ba, nó bỏ qua toàn bộ phần khó của một dự án lớn: dữ liệu cũ, thói quen văn thư, năng lực đội vận hành, và những gì xảy ra ở năm thứ ba.

Một bộ tiêu chí tốt phải làm ngược lại: mỗi tiêu chí được phát biểu dưới dạng một câu hỏi có thể kiểm chứng bằng thao tác hoặc bằng tài liệu, chứ không phải bằng lời hứa. Nếu bạn không nghĩ ra cách kiểm chứng một tiêu chí, tiêu chí đó chưa dùng được.

Bộ tiêu chí chọn phần mềm eOffice gồm năm tầng

Năm tầng xếp theo thứ tự nên xét: nghiệp vụ, kỹ thuật, tuân thủ, vận hành, thương mại. Sai ở tầng dưới thì mọi ưu điểm ở tầng trên đều vô nghĩa. Một hệ thống đẹp nhưng không phát hành được văn bản đúng thể thức là hệ thống không dùng được, dù API có mở đến đâu.

Tầng nghiệp vụ: hệ thống có làm đúng việc văn thư không

Đây là tầng bị bỏ qua nhiều nhất vì ai cũng mặc định nó hiển nhiên.

• Thể thức và kỹ thuật trình bày. Văn bản phát hành ra phải đúng thể thức theo Nghị định 30/2020/NĐ-CP về công tác văn thư: số, ký hiệu, nơi nhận, phần thẩm quyền ký, dấu chỉ độ mật và độ khẩn. Yêu cầu nhà cung cấp phát hành thử ba loại văn bản khác nhau và in ra đối chiếu. Chi tiết hơn về nhóm yêu cầu này nằm trong bài về phần mềm quản lý công văn theo Nghị định 30.
• Sổ văn bản và cấp số. Cấp số tự động theo sổ, theo năm, theo đơn vị; xử lý được văn bản thu hồi, văn bản thay thế, văn bản mật. Hỏi thẳng: nếu hai người bấm phát hành cùng lúc thì số nhảy thế nào.
• Luồng phê duyệt nhiều cấp. Trình ký qua nhiều cấp, ký thay, ký thừa lệnh, ủy quyền khi lãnh đạo đi vắng, trả lại kèm ý kiến, chuyển ngang giữa các đơn vị. Kịch bản khó nhất là văn bản bị trả về giữa chừng rồi đi lại từ một bước nào đó, không phải từ đầu.
• Ký số. Ký số cá nhân và ký số tổ chức, ký trên thiết bị di động, ký hàng loạt, và giữ được hiệu lực kiểm tra chữ ký sau khi văn bản đã lưu trữ nhiều năm. Khung pháp lý hiện hành là Nghị định 23/2025/NĐ-CP về chữ ký điện tử và dịch vụ tin cậy; phần thực hành đã bàn trong bài về ký số nội bộ.
• Hồ sơ công việc và nộp lưu. Văn bản gom được thành hồ sơ, hồ sơ đóng lại và nộp lưu được, kèm siêu dữ liệu để sau này tra cứu. Nhiều hệ thống dừng ở mức lưu file rời.
• Tìm kiếm. Tìm theo trích yếu, số ký hiệu, thời gian, đơn vị, người ký, và tìm trong nội dung file đính kèm tiếng Việt có dấu.

Tầng kỹ thuật: yêu cầu kỹ thuật phần mềm văn phòng điện tử

Tầng này nên do bộ phận công nghệ thông tin chấm, không để bên mua sắm chấm hộ.

• Kiến trúc và môi trường chạy. Hệ thống chạy trên nền gì, đóng gói ra sao, có dựng lại được từ đầu trên hạ tầng của tổ chức trong bao lâu. Hỏi về môi trường phát triển, kiểm thử và chạy thật tách biệt.
• Tích hợp SSO và Active Directory. Người dùng đăng nhập một lần bằng tài khoản sẵn có, không sinh thêm một tập mật khẩu mới. Kiểm tra cụ thể giao thức hỗ trợ, đồng bộ cây tổ chức từ LDAP hay Active Directory, và điều gì xảy ra khi một nhân sự nghỉ việc hoặc chuyển đơn vị: tài khoản có bị khóa theo và quyền cũ có bị thu hồi không.
• Phân quyền theo vai trò. Quyền phải gắn với vai trò và vị trí trong cây tổ chức, không gắn cứng vào từng người. Thử một tình huống: một trưởng phòng kiêm nhiệm hai đơn vị thì nhìn thấy những gì.
• API mở. Có tài liệu API công khai cho bên thứ ba, có cơ chế xác thực riêng cho tích hợp máy với máy, và có webhook để hệ thống khác biết khi văn bản đổi trạng thái. API mở là điều kiện để sau này nối với nhân sự, tài chính hay hệ thống báo cáo mà không phải nhờ vả nhà cung cấp từng lần.
• Hiệu năng và khả năng mở rộng hệ thống. Yêu cầu con số cụ thể ở quy mô của bạn, không phải quy mô demo: bao nhiêu người dùng đồng thời, dung lượng lưu trữ tăng bao nhiêu mỗi năm, thời gian mở một văn bản có đính kèm lớn. Hỏi luôn cách mở rộng khi số đơn vị tăng gấp đôi.
• Sao lưu và phục hồi. Hai con số phải có trong hợp đồng: mất tối đa bao nhiêu dữ liệu và ngừng dịch vụ tối đa bao lâu khi sự cố. Quan trọng hơn, yêu cầu nhà cung cấp diễn tập phục hồi ít nhất một lần trong giai đoạn nghiệm thu, chứ đừng tin bản mô tả quy trình.

Tầng tuân thủ: dữ liệu ở đâu và ai đã đụng vào

• Vị trí dữ liệu. Dữ liệu và bản sao lưu nằm ở đâu về mặt vật lý, ai có quyền quản trị hạ tầng đó, và nhà cung cấp có truy cập được vào dữ liệu vận hành không. Đây là câu hỏi kiến trúc, không phải câu hỏi chính sách; phần phân tích dài hơn nằm trong bài on-premise hay cloud khi tuân thủ dữ liệu.
• Nhật ký truy vết. Mọi thao tác đọc, sửa, phát hành, tải về đều để lại vết, có mốc thời gian và danh tính, và nhật ký này không được sửa bởi chính người quản trị nghiệp vụ. Hỏi thời gian giữ nhật ký và cách trích xuất khi cần phục vụ thanh tra.
• Nghĩa vụ bảo vệ dữ liệu cá nhân. eOffice chứa hồ sơ nhân sự, đơn thư, thông tin công dân, nên nằm trong phạm vi Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và Nghị định 356/2025/NĐ-CP hướng dẫn thi hành. Phần mềm cần hỗ trợ được các nghĩa vụ vận hành: xác định phạm vi dữ liệu cá nhân đang xử lý, đáp ứng yêu cầu của chủ thể dữ liệu, xóa hoặc ẩn danh khi hết thời hạn lưu, và cung cấp bằng chứng khi lập hồ sơ đánh giá tác động. Danh mục việc phải làm ở phía tổ chức nằm trong checklist tuân thủ.
• Vai trò pháp lý của nhà cung cấp. Trong hợp đồng, nhà cung cấp là bên xử lý dữ liệu theo ủy quyền hay chỉ là bên bán phần mềm. Hai vai trò này kéo theo hai bộ nghĩa vụ khác nhau và phải viết rõ.

Tầng vận hành: sau khi ký hợp đồng thì ai làm gì

• Kế hoạch triển khai. Có mốc, có người chịu trách nhiệm hai phía, có tiêu chí nghiệm thu từng giai đoạn. Kế hoạch chỉ ghi "3 tháng" là chưa phải kế hoạch.
• Chuyển đổi dữ liệu cũ. Ai làm sạch, ai nhập, sổ văn bản cũ có nối tiếp số được không, dữ liệu từ hệ thống trước có mang sang được không.
• Đào tạo. Đào tạo tách theo nhóm: văn thư, lãnh đạo, chuyên viên, quản trị hệ thống. Hỏi có đào tạo lại khi nhân sự thay đổi và tài liệu hướng dẫn có bàn giao dưới dạng chỉnh sửa được không.
• Hỗ trợ và cam kết chất lượng dịch vụ. SLA phải phân mức sự cố, ghi thời gian phản hồi và thời gian khắc phục cho từng mức, kèm chế tài khi vi phạm. Kênh hỗ trợ và giờ hỗ trợ ghi rõ, không để "hỗ trợ 24/7" trôi nổi.
• Nâng cấp. Bản vá bảo mật ra theo nhịp nào, ai chịu chi phí nâng cấp phiên bản lớn, và phần tùy biến riêng của bạn có bị vỡ khi nâng cấp không. Đây là câu hỏi phân biệt rõ nhất giữa các nhà cung cấp.

Tầng thương mại: điều khoản hợp đồng phần mềm cần lưu ý

• Cấu trúc chi phí. Bóc tách phí bản quyền hoặc phí triển khai ban đầu, phí tùy biến, phí bảo trì hằng năm, chi phí hạ tầng và chi phí nhân sự nội bộ. So sánh trên tổng chi phí năm năm, vì mô hình rẻ ở năm đầu thường không rẻ ở năm thứ tư.
• Quyền sở hữu dữ liệu. Ghi rõ dữ liệu thuộc về tổ chức, và ghi rõ nghĩa vụ bàn giao dữ liệu ở định dạng đọc được kèm mô tả cấu trúc khi kết thúc hợp đồng.
• Quyền với phần tùy biến. Phần mã nguồn viết riêng theo yêu cầu của bạn thuộc về ai, bạn có được nhận mã nguồn phần đó không, và có được thuê bên khác bảo trì không.
• Điều khoản rời bỏ. Thời gian hỗ trợ chuyển đổi sau khi chấm dứt, chi phí xuất dữ liệu, và cam kết không giữ dữ liệu làm điều kiện đàm phán. Nếu điều khoản rời bỏ khó viết, chi phí khóa nhà cung cấp của bạn đang cao.
• Bảo mật và trách nhiệm. Nghĩa vụ thông báo khi xảy ra sự cố lộ lọt, phạm vi bồi thường, và quyền của bạn được kiểm tra an toàn thông tin trước khi đưa vào chạy thật.

Quy đổi thành điểm số

Bộ tiêu chí chỉ hữu ích khi ra được một con số để hội đồng tranh luận. Cách làm gọn nhất gồm ba bước.

Bước một, đánh dấu các tiêu chí bắt buộc. Đây là những thứ mà thiếu là loại, không cần chấm tiếp: chạy được trên hạ tầng của tổ chức nếu đó là yêu cầu của bạn, phát hành đúng thể thức, ký số hợp chuẩn, có nhật ký truy vết. Thường chỉ nên có năm đến tám tiêu chí bắt buộc; nhiều hơn nghĩa là bạn đang mô tả một sản phẩm cụ thể chứ không phải nhu cầu.

Bước hai, cho trọng số cho phần còn lại theo năm tầng. Với tổ chức đang chuẩn hóa quy trình nội bộ, tầng nghiệp vụ và vận hành thường nặng hơn. Với tổ chức đã có hệ thống công nghệ thông tin phức tạp, tầng kỹ thuật nặng hơn vì rủi ro tích hợp lớn hơn.

Bước ba, chấm theo bằng chứng chứ không theo lời đáp. Quy ước ba mức là đủ: đã thấy tận mắt trong bản chạy thử, có tài liệu chứng minh, chỉ mới nghe nói. Mức thứ ba nên được tính bằng không. Ràng buộc này thay đổi hoàn toàn chất lượng đợt đánh giá.

Cách tổ chức một đợt đánh giá nhà cung cấp phần mềm

• Gửi trước kịch bản nghiệp vụ của chính bạn. Đừng ngồi xem demo mẫu. Soạn năm đến bảy tình huống có thật, gồm cả tình huống xấu, gửi trước cho mọi nhà cung cấp và yêu cầu diễn lại đúng kịch bản đó. Ví dụ: một công văn đến được số hóa, phân về hai đơn vị, một đơn vị xin gia hạn, văn bản trả lời bị lãnh đạo trả về sửa, sau đó phát hành và nộp lưu.
• Yêu cầu người trực tiếp thao tác. Để văn thư và chuyên viên của bạn tự bấm trong buổi đánh giá. Người bán thao tác lúc nào cũng mượt.
• Chạy thử với dữ liệu thật. Một đợt thử giới hạn ở một đơn vị, trong hai đến bốn tuần, với dữ liệu thật đã che phần nhạy cảm, cho biết nhiều hơn ba tháng họp. Đặt trước tiêu chí kết thúc: bao nhiêu văn bản đi trọn vòng, bao nhiêu lỗi chặn, bao nhiêu người dùng làm được mà không cần hỏi.
• Kiểm tra tham chiếu, nhưng hỏi đúng câu. Xin danh sách khách hàng có quy mô tương đương và gọi trực tiếp. Đừng hỏi "có hài lòng không". Hãy hỏi: đợt triển khai trễ bao lâu so với kế hoạch, sự cố nghiêm trọng gần nhất mất bao lâu để khắc phục, và nếu chọn lại thì họ sẽ làm khác điều gì.
• Kiểm thử an toàn thông tin trước khi chạy thật. Đưa vào hợp đồng quyền được đánh giá an toàn hệ thống, và quyền dừng nghiệm thu nếu phát hiện lỗ hổng mức cao.

Dấu hiệu cảnh báo khi nghe chào hàng

• Nhận mọi yêu cầu mà không hỏi lại. Một đội có kinh nghiệm luôn hỏi ngược về quy mô, cây tổ chức, dữ liệu cũ. Gật đầu với mọi thứ là dấu hiệu chưa hiểu bài toán hoặc chưa định làm.
• Tránh câu hỏi về vị trí dữ liệu và nhật ký. Nếu câu trả lời chuyển thành khẩu hiệu về bảo mật thay vì mô tả kiến trúc, cần hỏi kỹ hơn.
• Không cho chạy thử trên dữ liệu của bạn. Lý do đưa ra thường là bảo mật hoặc kỹ thuật, nhưng kết quả là bạn ký hợp đồng mà chưa từng thấy hệ thống làm việc thật.
• Báo giá trọn gói không bóc tách. Một con số duy nhất cho mọi thứ khiến bạn không thể so sánh, và thường đi kèm phát sinh ở giai đoạn tùy biến.
• Không nói được về nâng cấp. Nhà cung cấp không trả lời được câu hỏi phần tùy biến của bạn sẽ ra sao sau hai lần nâng cấp là nhà cung cấp chưa từng đi hết một vòng đời sản phẩm.
• Danh sách khách hàng không kiểm chứng được. Logo trên slide mà không cho gọi tham chiếu thì nên coi như không có.
• Sức ép về thời hạn ưu đãi. Giảm giá có hạn là kỹ thuật bán hàng, không phải dữ kiện để ra quyết định đầu tư nhiều năm.

Kết

Bộ tiêu chí chọn phần mềm eOffice không nhằm tìm ra sản phẩm hoàn hảo, mà nhằm buộc mọi bên chào hàng chứng minh trên cùng một thước đo, và buộc chính tổ chức phát biểu rõ đâu là thứ không thể thỏa hiệp. Phần lớn dự án thất bại không phải vì chọn nhầm sản phẩm, mà vì không ai viết ra tiêu chí trước khi xem demo.

Tetra eOffice được xây theo hướng tùy biến trên hạ tầng của khách hàng, nên chúng tôi quen với việc bị chấm theo những tiêu chí như trên. Nếu bạn đang dựng bảng đánh giá cho một đợt lựa chọn, hãy đặt lịch tư vấn để chạy thử bộ tiêu chí đó trên đúng kịch bản nghiệp vụ của tổ chức.