Nối lại chuỗi từ chiến lược năm đến KPI của từng người

1Tóm tắt điều hành

Doanh nghiệp Việt thường có chiến lược năm, có KPI, có đánh giá. Cái thiếu là sợi dây nối ba thứ đó với nhau, nên chiến lược “tắt” đúng ở chỗ phải biến thành việc của từng phòng ban và từng người.

2Vì sao chiến lược “tắt” ở khâu cascade KPI

Chủ dự án mô tả hiện tượng này ở doanh nghiệp tham chiếu và “rất nhiều công ty” khác: chiến lược năm đã có, nhưng đến chỗ chuyển thành KPI cho từng phòng ban và cá nhân thì dừng lại.

Chuỗi đứt ở đâu, cụ thể từng mắt xích

Bốn nguyên nhân gốc

Điều chính các nhà cung cấp cũng nói ra

Hai nhà cung cấp Việt tự mô tả cùng một nhóm nỗi đau trên trang của họ (đã đọc trong lần khảo sát này):

• Tinamys (Tinasoft), bài blog ngày 10/06/2025: “Mục tiêu bị bỏ quên sau khi thiết lập”; “Không có công cụ đo lường tiến độ rõ ràng” (báo cáo nội bộ, file Excel thủ công); “Nhân viên không thấy vai trò của mình trong mục tiêu lớn”.
• TOPKPI (Toppion), lời chứng thực của một Tổng giám đốc khách hàng trên trang sản phẩm: các cấp quản lý “dựa vào bản đồ chiến lược”, xác định Mục tiêu trọng yếu (KPO) rồi Yếu tố thành công cần thiết (KSF) để “giao KPIs cho cấp dưới tương ứng”. Nội dung này xác nhận chuỗi tuần tự nào cần có, đồng thời cho thấy một đường đi hiện nay là học phương pháp qua tư vấn.

Hệ quả với từng vai trò

3Khảo sát giải pháp hiện có

Bảy sản phẩm, bốn của Việt Nam và ba của quốc tế, được đọc trực tiếp trên trang công khai của họ trong ngày 13/11/2026.

3.1 Việt Nam

TOPKPI (Toppion)

toppion.com.vn · BSC – OKR – KPI · giá: liên hệ tư vấn

Thực sự làm gì

• Phần mềm “quản trị và thực thi chiến lược BSC-OKR-KPI” của một công ty tư vấn/đào tạo BSC; trang giới thiệu gói “10 bước triển khai BSC-KPI” ngay trong phần mềm.
• Công cụ vẽ mô hình xương cá (mục tiêu → yếu tố → KPI); hộp thoại KPI có trường tên, ghi chú, bộ phận phụ trách.
• Phân bổ KPI từ giám đốc xuống trưởng phòng, từ trưởng phòng xuống nhân viên.
• Báo cáo/nhập liệu: liên kết số liệu với KPI tổng, đính kèm tài liệu, tự đánh giá tình hình.
• Dashboard công ty – phòng ban – nhân viên; hệ thống E-Learning BSC-KPI (128 phút theo trang gói bổ trợ).

Mô hình giá (theo trang)

• Gói 1: cài trên server của Toppion, “chi phí đầu tư thấp”, gia hạn theo năm. Gói 2: cài trên server khách hàng, “chi phí đầu tư cao”, phí gia hạn 15%/năm. Không có con số cụ thể: liên hệ. Dùng thử 7 ngày.
• Tự công bố: “+800 doanh nghiệp” (chưa kiểm chứng).

Nhận xét UX (từ ảnh)

• Điểm mạnh: bám đúng phương pháp BSC, từng bước có hướng dẫn; cách hiểu “xương cá” dễ giải thích cho cấp quản lý.
• Điểm yếu thấy được: màn báo cáo là bảng dày đặc nhiều cột, cuộn ngang; hộp thoại KPI chọn bộ phận phụ trách bằng danh sách tick; trong ảnh chưa thấy trọng số hay liên kết KPI cha-con. Phần quyền, vòng phê duyệt và đánh giá cuối kỳ không được mô tả trên trang.
• Định vị: phần mềm đi kèm dịch vụ tư vấn và đào tạo; giá trị chính là phương pháp luận.

Simplamo

simplamo.com · KPI / OKR / OGSM / BSC / 4DX · giá công khai (USD)

Thực sự làm gì

• “Nền tảng cho CEO” thực thi chiến lược, xây theo nhịp họp: menu sản phẩm gồm OKRs & Goals, Scorecard, Meeting, Issues, To-dos, Engagement, Conversation, Process, Vision, Dashboard, Performance Report, Organization Chart, Activity Timeline, cộng Simplamo AI và Meeting Pulse.
• Hỗ trợ nhiều khung phương pháp (KPI, OKR, OGSM, BSC, 4DX) và theo mục tiêu 90 ngày – 1 năm – 3 năm.
• Có bản tiếng Việt (VI) và Anh (EN), ứng dụng di động trên App Store, giải pháp theo ngành và theo quy mô.

Mô hình giá (theo trang giá)

• Theo người dùng/tháng, giảm dần theo bậc: Base $18 (1–25 người dùng), Growth $14 (26–75), Enterprise $8 (từ 76). Cả ba bậc liệt kê cùng bộ tính năng. Có gói riêng cho coaching.
• Tự công bố: “60K Meetings”, đánh giá 9.5 (chưa kiểm chứng).

Nhận xét UX (từ ảnh)

• Điểm mạnh: nhịp họp, to-do và vấn đề gắn liền với mục tiêu nên thúc đẩy thói quen cập nhật hàng tuần; giá minh bạch.
• Điểm yếu thấy được: trang chủ chủ yếu là hình người và thẻ minh hoạ thay vì màn hình sản phẩm thật; mô hình thiên về OKR/họp, chưa thấy mô tả bản đồ chiến lược BSC hay cây cascade có trọng số.
• Định vị: hệ điều hành vận hành của CEO, mạnh ở kỷ luật họp hơn là ở kiến trúc KPI.

Tinamys (Tinasoft)

tinasoft.io · OKRs · giá: chưa thấy công bố, liên hệ

Thực sự làm gì

• Nền tảng quản trị mục tiêu theo OKRs do Tinasoft Việt Nam (công ty gia công phần mềm) phát triển; tên đầy đủ “Mapping Your Success”. Có ứng dụng iPhone miễn phí trên App Store.
• Theo bài giới thiệu: thiết lập OKRs theo công ty, bộ phận, nhóm và cá nhân; hiển thị tiến độ thời gian thực; giao nhiệm vụ có người phụ trách, KPI và thời hạn; tự động báo cáo và phân tích.

Mô hình giá

• Trang giá của Tinasoft chỉ nói về dịch vụ gia công phần mềm; không thấy bảng giá cho Tinamys: liên hệ.
• Con số hiệu quả (“tăng 30%”, “giảm 50% thời gian họp”) là lời quảng bá trên blog, không kèm nguồn.

Nhận xét UX (từ ảnh)

• Điểm mạnh: mô tả nỗi đau sát thực tế Việt Nam, có app di động.
• Điểm yếu thấy được: thông tin sản phẩm công khai nằm trong một bài blog, ít màn hình thật; không thấy mô tả bản đồ chiến lược, trọng số KPI, phân quyền hay đánh giá cuối kỳ. Nhiều chi tiết chỉ có thể xác nhận bằng demo.

Workbase

workbase.vn · quản trị vận hành · giá công khai (VND)

Thực sự làm gì

• Nền tảng quản trị vận hành low-code/no-code: Task & Project, Request & Approval, HR Service, IT Helpdesk, Recurring Task, ESign, Report. Trang sản phẩm nhắc OKR và KPI trong dòng mô tả chung, nhưng module chuyên cho chiến lược → KPI không nằm trong danh sách module chính.
• Phù hợp theo quy mô (startup, SME, enterprise) và nhiều ngành; có ứng dụng di động.

Mô hình giá (theo trang giá)

• Freemium: miễn phí, dưới 30 nhân sự, 10 quy trình, phí triển khai 10.000.000 VNĐ.
• Professional: 100.000 VNĐ/người/tháng, không giới hạn tính năng, hợp đồng tối thiểu 12 tháng.
• Enterprise (trên 300 nhân sự): liên hệ; có API và triển khai trên hạ tầng doanh nghiệp.

Nhận xét UX (từ ảnh)

• Điểm mạnh: giao diện công việc rõ (bộ lọc “Tôi làm / Tôi giao / Tôi giám sát”), phê duyệt là một mô-đun riêng.
• Điểm yếu thấy được (so với bài toán này): là công cụ công việc, không phải công cụ chiến lược: không thấy bản đồ chiến lược, thư viện KPI hay cascade có trọng số. Có thể bổ trợ chứ không thay thế.

3.2 Quốc tế

Perdoo

perdoo.com · OKR & KPI · giá công khai (EUR/USD)

Thực sự làm gì

• Gói Free (tối đa 5 người dùng) đã gồm OKRs & KPIs, Projects & Tasks, Strategy Maps, Meetings, ứng dụng di động, tích hợp Slack & Teams.
• Premium thêm AI Agent, AI Coach, API & MCP Server, Dashboards, tích hợp cao cấp. Supreme thêm Board Views, Custom Dashboards, Performance Reviews, view-only licenses.

Mô hình giá (theo trang giá)

• Free €0; Premium €6.40/người/tháng; Supreme €8.00/người/tháng (thanh toán theo năm); giá giảm theo số licence; không phí triển khai; có gói coaching theo giờ.

Nhận xét UX (từ ảnh)

• Điểm mạnh: bản đồ chiến lược và OKR/KPI cùng một sản phẩm; giá thấp, tự phục vụ; trang chủ có ảnh giao diện thật.
• Điểm yếu thấy được với thị trường Việt: không có tiếng Việt trên trang đã đọc; tính năng đánh giá hiệu suất chỉ ở bậc cao nhất; không có triển khai theo mô hình tư vấn tại chỗ.

Profit.co

profit.co · Strategy + Performance + Projects · giá: Essentials xem trang giá, Enterprise tuỳ chỉnh

Thực sự làm gì

• Nền tảng “strategy execution” gồm nhóm Strategy (OKRs & Goals, Strategy Roadmap, Balanced Scorecard, Hoshin Kanri), Performance (Performance Reviews, Calibration, Compensation, Development Plans), Projects, Engagement (recognition, pulse surveys), Meetings.
• Mọi gói gồm 100+ tích hợp (Slack, Teams, Jira…), phân tích thời gian thực; Enterprise có SCIM & SSO, audit logs, data residency.

Mô hình giá

• Dùng thử 30 ngày; gói Essentials và Enterprise (“custom pricing”). Chưa đọc được đơn giá Essentials trong lần khảo sát này, nên ghi xem trang giá.

Nhận xét UX (từ ảnh)

• Điểm mạnh: phạm vi phủ rộng nhất, từ BSC/Hoshin tới đánh giá và lương thưởng, đúng chuỗi mà bài toán này cần.
• Điểm yếu thấy được: rộng nên nặng; trang chủ nhiều mô-đun, không tiếng Việt, quy trình cascade có trọng số và phê duyệt theo tổ chức Việt Nam cần xác minh qua demo.

Cascade Strategy

cascade.app · strategy execution · giá: liên hệ

Thực sự làm gì

• Tự giới thiệu là “nền tảng cho C-Suite biến chiến lược thành mô hình vận hành”. Trang giá liệt kê: Standard Frameworks & OKRs, tới 50 Advanced Metrics, tới 15 Advanced Reports (Essentials); Custom Strategy Model, không giới hạn metrics và reports, Tapestry AI, data residency, enterprise security (Enterprise).
• Có gói bắt đầu miễn phí cho tối đa 2 người dùng với Basic Access Control.

Mô hình giá

• Essentials và Enterprise: liên hệ (“Platform Pricing”, không đăng giá).

Nhận xét UX (từ ảnh)

• Điểm mạnh: định vị cho lãnh đạo cấp cao, giới hạn số metrics/reports rõ theo gói, “mô hình chiến lược tuỳ chỉnh”.
• Điểm yếu thấy được: trang đã đọc không mô tả đánh giá nhân sự cá nhân; không tiếng Việt; giá không công khai.

Betterworks

betterworks.com · Performance Management + Talent Intelligence · giá công khai (USD)

Thực sự làm gì

• Hai sản phẩm: Performance Management (Goals & OKRs, Conversations, Feedback, 1:1s, Engagement, Analytics) và Talent Intelligence (Calibration, Succession Planning, Skills Intelligence, Individual Development Plans).
• Thế mạnh: từ mục tiêu đến chu kỳ đánh giá; ít nhấn bản đồ chiến lược.

Mô hình giá

• Trang giá nêu gói Performance $8/người/tháng; các gói khác chưa đọc rõ giá, ghi liên hệ.

Nhận xét UX (từ ảnh)

• Điểm mạnh: luồng mục tiêu → hội thoại → calibration trong một sản phẩm, rất sát khâu đánh giá của HR.
• Điểm yếu thấy được: định hướng HR/talent, không phải bản đồ chiến lược cho Ban giám đốc; không tiếng Việt.

4Ma trận so sánh tính năng

Một bảng để thấy chỗ trống: ô nào cũng chỉ ghi điều nhà cung cấp công bố trên trang đã đọc ngày 13/11/2026.

Ba điều rút ra

5Năm persona

Mỗi persona có việc riêng trong chu kỳ năm và cần màn hình riêng. Người nhập dữ liệu và người xem xét là hai việc khác nhau, nên không dùng chung một màn.

Đây là persona giả định để thiết kế, xây từ vai trò tổ chức điển hình, không phải người thật. Cần kiểm chứng bằng phỏng vấn (mục 14).

Vai trò “Admin hệ thống” (kỹ thuật) gộp với HR/Admin ở MVP; ma trận quyền ở mục 8 tách chúng thành hai vai trò riêng khi doanh nghiệp có đội IT.

6Hành trình người dùng

Mỗi hành trình đi qua các màn hình ở mục 12. Cột “Hôm nay” là hiện trạng giả định ở doanh nghiệp dùng Excel và Zalo; cột “Với sản phẩm” là điều cần đạt.

6.1 CEO: từ “chiến lược năm nay chạy thế nào?” đến quyết định

6.2 PMO: dựng chu kỳ và cascade

6.3 Trưởng phòng: nhận, chia, duyệt, báo cáo

6.4 Nhân viên: biết mình được đo gì và báo cáo nhanh

6.5 HR / Admin: từ cơ cấu tổ chức đến xếp loại

7Chu kỳ vận hành năm như một workflow

Mười bước, mỗi bước có người làm, đầu vào, đầu ra, trạng thái và điều gì bị khoá sau khi duyệt. Nguyên tắc chung: đã duyệt thì khoá; muốn sửa thì gửi yêu cầu thay đổi để người duyệt xét.

Vòng đời một KPI

8Mô hình phân quyền

Quyền được cấp theo hai trục: vai trò (làm được thao tác gì với loại đối tượng nào) và phạm vi dữ liệu (thấy dữ liệu của ai). Mọi kiểm tra thực hiện ở máy chủ, không chỉ ẩn nút trên giao diện.

8.1 Ma trận vai trò × đối tượng

8.2 Quy tắc phạm vi dữ liệu

8.3 Chuỗi phê duyệt

8.4 Nguyên tắc

• Không tự duyệt: người tạo không duyệt chính mục của mình, kể cả khi giữ cả hai vai trò.
• Tách quyền quản trị khỏi dữ liệu kinh doanh: Admin hệ thống không xem được giá trị KPI hay điểm đánh giá.
• Mở rộng quyền sang miền dữ liệu khác (ví dụ cho trưởng phòng xem điểm đánh giá của phòng khác) là quyết định chính sách, phải bật có chủ đích và ghi nhật ký.
• Platform admin không mặc định thấy dữ liệu tenant: chỉ thấy thông tin tài khoản và sức khoẻ; muốn xem nội dung phải mở phiên truy cập hỗ trợ có ticket, chỉ đọc, được ghi nhật ký và báo cho Tenant admin (mục 13.3).
• Nhật ký bất biến: ghi người, thời điểm, giá trị trước và sau cho mọi thay đổi ở trạng thái đã duyệt.

9Yêu cầu chức năng

65 yêu cầu chức năng theo 12 module, ưu tiên MoSCoW. Must là phạm vi MVP (39 yêu cầu), Should vào v1 (19), Could vào v2 (7). Mỗi yêu cầu có tiêu chí chấp nhận một dòng để kiểm thử.

Won’t have (chưa làm ở chu kỳ này)

10Mô hình dữ liệu khái niệm

Mười lăm thực thể xoay quanh một đối tượng trung tâm: KPI. KPI có hai khoá ngoại quan trọng, objective_id nối lên chiến lược và parent_kpi_id nối lên KPI cha, nên chuỗi “chiến lược → công ty → phòng → người” là dữ liệu thật, không phải thói quen.

Quy tắc toàn vẹn dữ liệu

• Không tồn tại KPI mồ côi: mọi KPI công ty có objective_id, mọi KPI cấp dưới có parent_kpi_id.
• Tổng trọng số của KPI cá nhân trong một kỳ phải bằng 100% mới được gửi duyệt.
• Điều chuyển nhân sự giữ nguyên lịch sử: phiếu KPI cũ ở phòng cũ, phiếu mới từ ngày hiệu lực ở phòng mới.
• Dữ liệu của mỗi công ty (tenant) tách biệt hoàn toàn; mọi truy vấn mang theo mã công ty.

11Tích hợp và yêu cầu phi chức năng

11.1 Tích hợp

11.2 Yêu cầu phi chức năng

Các mục tiêu số (hiệu năng, thời gian sẵn sàng, thời hạn lưu nhật ký) là đề xuất ban đầu của tài liệu này, không lấy từ nguồn ngoài, và cần được đội kỹ thuật xác nhận trước khi ký kết.

12Bộ màn hình đề xuất

Chín màn hình dựng bằng HTML/CSS cùng một hệ thiết kế, đủ chi tiết để chốt bố cục, thành phần và tương tác trước khi viết mã sản phẩm. Tên sản phẩm “Mạch” là tên tạm cho mockup.

Hình 12.1–12.8 là màn hình máy tính 1440 px (thu nhỏ vừa khung); Hình 12.9 là màn hình điện thoại. Có thể in cả tài liệu ra PDF bằng chức năng in của trình duyệt.

13Quyết định sản phẩm cấp nền tảng (Platform)

Các mục trước mô tả sản phẩm từ góc nhìn một doanh nghiệp dùng nó. Mục này chốt phần nằm phía trên doanh nghiệp: nhiều doanh nghiệp cùng dùng một hệ thống như thế nào, ai quản lý gói và ghế, nhà vận hành làm gì, và một doanh nghiệp mới vào bằng đường nào. Bốn quyết định dưới đây là đề xuất của tài liệu, mỗi quyết định kèm lý do và cái giá phải trả.

13.1 Đa tenant hay đơn tenant

Khách nào dùng mô hình nào

Chuyển một tenant từ dùng chung sang riêng thì cần gì

Vì mọi bản ghi đều mang tenant_id và hai mô hình chạy cùng một bản phát hành, việc chuyển là một thao tác cơ học chứ không phải dự án viết lại:

1. Chuẩn bị: dựng phiên bản riêng cùng bản phát hành, cấu hình SSO, tên miền, tích hợp riêng; báo trước khung giờ chuyển cho Tenant admin.
2. Đóng băng ngắn: tenant chuyển sang chế độ chỉ đọc trong khung giờ đã báo, để không phát sinh bản ghi mới giữa lúc xuất và nhập.
3. Xuất và nhập: xuất mọi bản ghi và tệp đính kèm có tenant_id của khách, nhập vào phiên bản riêng, đối chiếu số bản ghi từng bảng và tổng kiểm tệp.
4. Chuyển hướng: đổi tên miền, SSO và các điểm tích hợp (HRM, Lark/Teams) sang phiên bản mới; Tenant admin kiểm tra đăng nhập và một phiếu KPI mẫu.
5. Dọn bản cũ: giữ bản trên hạ tầng dùng chung ở chế độ chỉ đọc một thời gian ngắn để quay lui được, sau đó xoá hẳn và ghi biên bản xoá (thời gian giữ là đề xuất, chốt cùng khách).

Chi phí thực sự của việc chuyển là một khung giờ chỉ đọc và công kiểm thử của đội vận hành, cộng chi phí vận hành riêng kéo dài sau đó. Chiều ngược lại (riêng về dùng chung) không được hứa ở MVP.

13.2 Trang License và tài khoản (Tenant admin)

Một trang duy nhất cho Tenant admin trả lời năm câu hỏi: đang dùng gói gì, còn bao nhiêu ghế, những module nào đang bật, hạn đến khi nào, và đã bị tính gì. Trang nằm trong màn Quản trị (Hình 12.8) dưới một thẻ riêng. Tên gói “Starter, Business, Enterprise” trong mockup là tên giữ chỗ; tài liệu không đặt giá, mọi mức giá hiển thị là “liên hệ” hoặc “theo hợp đồng” cho đến khi chủ dự án công bố bảng giá.

1. Gói hiện tại. Tên gói, chu kỳ thanh toán, hình thức triển khai. Đơn giá luôn ghi “theo hợp đồng · liên hệ”: giá do chủ dự án công bố, không do giao diện tự tính. Dòng “Triển khai riêng” dẫn thẳng đến đội bán hàng, không tự chuyển được.
2. Ghế. Ba con số khác nhau và phải hiển thị đủ: đã mua (theo hợp đồng), đã cấp (tài khoản đang ở trạng thái kích hoạt, tính vào hạn mức) và hoạt động 30 ngày (đã đăng nhập). Khoảng chênh giữa “đã cấp” và “hoạt động” là chỗ Tenant admin thu hồi ghế. Khi hết ghế: không thể kích hoạt thêm người; lời mời và nhập hàng loạt vượt hạn mức bị từ chối kèm số ghế thiếu và nút “Mua thêm ghế”. Người đang dùng không bị ảnh hưởng. Tài khoản bị vô hiệu hoá (kể cả do đồng bộ HRM báo nghỉ việc) trả ghế ngay. Cảnh báo bắt đầu từ 80% ghế.
3. Thời hạn và gia hạn. Ngày hiệu lực, số ngày còn lại, ngày gia hạn, tự động gia hạn bật hay tắt. Dải cảnh báo xuất hiện khi còn 60 ngày (đề xuất), và email gửi Tenant admin ở các mốc 60, 30, 7 ngày. Khi hết hạn hệ thống không cắt đột ngột; xem lộ trình ngay dưới.
4. Module. Danh sách module theo gói với trạng thái bật/tắt. Module tắt vẫn hiện, kèm cách liên hệ để mở, để Tenant admin biết gói cao hơn có gì. Chặn truy cập module ngoài gói thực hiện ở máy chủ (FR-12.3), không chỉ ẩn nút.
5. Đo lường sử dụng. Dung lượng tệp bằng chứng, lượt gọi API tích hợp và số người dùng hoạt động theo tháng, mỗi con số có hạn mức của gói và thời điểm cập nhật. Hạn mức từng gói do chủ dự án quyết định; con số trong mockup chỉ để minh hoạ. Vượt hạn mức dung lượng hoặc API thì cảnh báo và làm chậm, không xoá dữ liệu.
6. Lịch sử hoá đơn. Mỗi hoá đơn có số, nội dung, ngày, trạng thái và tệp PDF. Cột “Số tiền” hiển thị đúng giá trị trong hợp đồng khi dữ liệu thật có; mockup ghi “theo hợp đồng” vì tài liệu không đặt giá. Hoá đơn gia hạn sắp tới ở trạng thái nháp, chỉ Billing (nền tảng) phát hành.
7. Nâng cấp / hạ gói. Nâng cấp và mua thêm ghế có hiệu lực ngay, phần chênh tính theo số ngày còn lại. Hạ gói có hiệu lực từ kỳ gia hạn kế tiếp và bị chặn nếu số ghế đã cấp lớn hơn gói mới (thông báo cần vô hiệu hoá bao nhiêu tài khoản). Trong MVP các nút tạo một yêu cầu gửi Billing; thanh toán trực tuyến để giai đoạn sau.

Vòng đời tenant khi hết hạn: xuống thang từng bước

Thời lượng từng giai đoạn là đề xuất để chủ dự án chốt; điều cần cố định là thứ tự và nguyên tắc: không mất dữ liệu đột ngột, người dùng luôn được báo trước.

13.3 Quản trị nền tảng (Platform admin)

Đây là console của nhà vận hành sản phẩm, hoàn toàn tách khỏi ứng dụng mà doanh nghiệp dùng: tài khoản riêng, địa chỉ đăng nhập riêng, bắt buộc MFA. Việc của console là trả lời “tenant nào cần chú ý” và cho phép hành động trên tenant mà không đụng vào dữ liệu nghiệp vụ. Tên tenant trong mockup đều là tên hư cấu.

1. Tìm kiếm và bộ lọc. Tìm theo tên tenant, email chủ sở hữu hoặc mã; lọc theo gói, trạng thái (hoạt động, dùng thử, ân hạn, chỉ đọc, tạm ngưng, đang thiết lập) và sức khoẻ. Thẻ tổng quan dẫn thẳng đến các lọc hay dùng nhất: sắp hết hạn, cần chú ý.
2. Danh sách tenant. Mỗi dòng cho biết gói, ghế cấp trên ghế mua, trạng thái, sức khoẻ và kiểu triển khai. Sức khoẻ là chỉ báo gộp từ tín hiệu vận hành (ghế gần đầy, đồng bộ HRM lỗi, chưa có người đăng nhập trong 14 ngày, đã quá hạn), luôn kèm nhãn chữ chứ không chỉ màu. Console chỉ hiện số đếm và trạng thái, không có số KPI hay điểm đánh giá của tenant.
3. Chi tiết tenant. Liên hệ chủ sở hữu, gói, ghế, mức sử dụng và tình trạng tích hợp. Đủ để Support trả lời “vì sao khách không nhập được số liệu” mà chưa cần mở dữ liệu của khách.
4. Hành động trên tenant. Tạm ngưng (người dùng không đăng nhập, dữ liệu giữ nguyên), Kích hoạt lại (khôi phục đúng trạng thái trước đó), Gia hạn dùng thử. Nút không áp dụng được ở trạng thái hiện tại thì mờ đi và có chú thích. Hành động nào cũng bắt buộc lý do và ghi vào nhật ký; vai trò quyết định ai thấy nút nào (bảng dưới).
5. Truy cập hỗ trợ (impersonate). Cách duy nhất để nhân viên nền tảng nhìn thấy nội dung của tenant. Bắt buộc có mã ticket do chính khách tạo và lý do; mặc định chỉ đọc; tối đa 60 phút (đề xuất), muốn tiếp tục phải mở phiên mới với lý do mới. Trong phiên, người hỗ trợ thấy dải đỏ cố định “Đang xem với tư cách hỗ trợ”; không đổi được mật khẩu, MFA hay xuất dữ liệu hàng loạt. Chế độ ghi chỉ mở khi Tenant admin bật rõ ràng cho phiên đó. Tenant dedicated hoặc tenant tự bật “chặn truy cập hỗ trợ” thì phải được Tenant admin duyệt từng phiên.
6. Nhật ký kiểm toán. Mỗi dòng: thời điểm, ai (tài khoản và vai trò), làm gì, đối tượng và chi tiết (ticket, thời lượng, số màn hình đã xem). Nhật ký bất biến, không ai có quyền sửa hoặc xoá, kể cả Super admin. Mỗi phiên hỗ trợ cũng hiện trong nhật ký của chính tenant để Tenant admin tự kiểm tra.
7. Quản trị viên nền tảng. Danh sách tài khoản nhà vận hành, vai trò và tình trạng MFA; chỉ Super admin tạo, đổi vai trò hoặc thu hồi. Vai trò quyết định ai thấy nút nào ở chú thích 4 và 5 (bảng ngay dưới).

Vai trò Platform admin và việc mỗi vai trò được làm

13.4 Onboarding tenant mới

Mục tiêu: một doanh nghiệp mới tự đi từ đăng ký đến chu kỳ chiến lược đầu tiên mà không cần nhân viên nền tảng thao tác tay, và có thể thoát ra làm tiếp bất cứ lúc nào. Mỗi bước dưới đây ghi rõ ai làm, cái gì bắt buộc, cái gì bỏ qua được, tenant đang ở trạng thái nào và hệ thống tự làm gì.

13.5 Yêu cầu và phân quyền bổ sung

Phần nền tảng đã được đưa vào hai bảng có sẵn thay vì tách bảng riêng, để người đọc chỉ có một nguồn:

• Bảng yêu cầu chức năng (mục 9): thêm module 12 “Nền tảng” gồm FR-12.1 đến FR-12.10: 6 Must (cô lập dữ liệu đa tenant, cấp tenant tự động, thực thi license và ghế, tách vai trò Platform admin, nhật ký truy cập hỗ trợ, tạm ngưng/kích hoạt/gia hạn dùng thử), 2 Should (trình hướng dẫn thiết lập, trang license và đo lường), 2 Could (đóng gói triển khai riêng, công cụ chuyển tenant). Tổng yêu cầu là 65.
• Ma trận phân quyền (mục 8.1): thêm cột Platform admin bên cạnh cột Tenant admin (tên gọi mới của “Admin hệ thống”), và ba dòng mới: tenant/gói/license, truy cập hỗ trợ, nhật ký kiểm toán nền tảng. Platform admin có dấu “–” ở mọi dòng dữ liệu nghiệp vụ.
• Mô hình dữ liệu (mục 10): thêm các thực thể mức nền tảng, nằm ngoài phạm vi tenant_id: tenant (trạng thái, kiểu triển khai), license (gói, ghế mua, hạn, module bật), platform_user và vai trò, support_session (ticket, lý do, thời lượng), platform_audit_log. Các thực thể này chỉ truy cập được từ console nền tảng.

Mọi thời lượng, ngưỡng và hạn mức ở mục này (ân hạn 14 ngày, chỉ đọc 30 ngày, phiên hỗ trợ 60 phút, ngưỡng cảnh báo 80% ghế, ngưỡng 500 người dùng) là đề xuất của tài liệu này, chưa lấy từ nguồn ngoài hay từ khách hàng, và cần chủ dự án xác nhận. Tài liệu không đưa ra bảng giá và không dẫn số liệu quy mô thị trường nào.

14MVP, lộ trình, rủi ro và câu hỏi mở

14.1 Ba giai đoạn

14.2 Cố ý để ngoài MVP, và lý do

Lộ trình theo thời gian (tuần, tháng) và chi phí chưa có trong tài liệu này vì phụ thuộc quy mô đội và công nghệ chọn; sẽ ước lượng sau khi chủ dự án chốt các câu hỏi mở bên dưới.

14.3 Rủi ro

14.4 Câu hỏi mở cho chủ dự án

1. Sản phẩm hay dịch vụ? BRD đang viết để xây sản phẩm. Nếu mục tiêu là dịch vụ tư vấn cho một khách cụ thể (như doanh nghiệp tham chiếu), phạm vi nên đổi: giảm tự phục vụ, tăng mẫu và workshop.
2. Quy mô khách mục tiêu có đúng 200–2.000 nhân sự và đã có HRM riêng không? Quy mô nhỏ hơn bỏ được phần lớn tích hợp; lớn hơn cần phân cấp nhiều tầng.
3. Phương pháp ưu tiên: BSC làm xương sống (như tài liệu này) hay OKR trước?
4. Ai thấy điểm đánh giá cá nhân? Đề xuất ở mục 8.2; chính sách thực tế của doanh nghiệp mục tiêu cần xác nhận.
5. Chu kỳ nhập liệu mặc định: tháng hay quý? Ảnh hưởng thiết kế nhắc và duyệt.
6. Mô hình triển khai và giá: tự phục vụ theo người dùng, hay gói có triển khai đi kèm? Khảo sát thị trường cho thấy cả hai cách (mục 3).
7. Doanh nghiệp tham chiếu: có thể phỏng vấn người trong cuộc ở đó để kiểm chứng bảng “chuỗi đứt ở đâu” (mục 2) không?
8. Ngưỡng cho triển khai riêng (dedicated): đề xuất ở mục 13.1 là khách từ khoảng 500 người dùng hoặc thuộc ngành chịu quy định; ngưỡng thật cần khớp với năng lực vận hành và giá “liên hệ” mà chủ dự án muốn bán.

15Phụ lục: nguồn tham khảo

Tất cả trang dưới đây được đọc hoặc chụp ngày 13/11/2026. Nội dung có thể đã thay đổi sau ngày đó.