Đánh giá mức độ sản phẩm đáp ứng các quy định pháp lý, chuẩn mực ngành và các yêu cầu tuân thủ liên quan đến dữ liệu, vận hành và cung ứng dịch vụ, tương xứng với mức trưởng thành và quy mô triển khai

1. Mục tiêu đánh giá

Tiêu chí này dùng để phân biệt “đúng quy định trên giấy” với “tuân thủ được trong vận hành thực tế”.

2. Các chiều đo

3. Thang đánh giá định tính–định lượng

Điểm thấp

• • Chỉ nêu “có tuân thủ” nhưng không nêu được quy định/chuẩn cụ thể và không có cơ chế kiểm soát.
  • Không chứng minh được phạm vi áp dụng (tuân thủ cái gì, ở đâu, cho dữ liệu nào).

Điểm cao

• • Có bản đồ yêu cầu tuân thủ (requirement mapping) gắn với tính năng/dữ liệu/vận hành; có cơ chế kiểm soát thay đổi khi quy định thay đổi.
  • Có hồ sơ truy vết thể hiện tuân thủ trong các tình huống vận hành và kiểm tra.

4. Bằng chứng nên có

5. Trọng tâm theo mức trưởng thành

M1–M2: Tính “đúng ngay từ thiết kế”: phạm vi áp dụng rõ ràng, mô hình dữ liệu/luồng xử lý có điểm kiểm soát, lộ trình hoàn thiện tuân thủ.

M3–M4: Tính “chịu được vận hành và kiểm tra”: kiểm soát thay đổi, khả năng truy vết, bằng chứng vận hành, và mức độ tuân thủ ở quy mô lớn/đa khách hàng.

6. Lỗi thường gặp / Dấu hiệu cảnh báo

• “Checklist tuân thủ” dài nhưng không có mapping sang tính năng/dữ liệu/luồng nghiệp vụ.
• Hồ sơ chứng chỉ/giấy phép không khớp phạm vi sản phẩm (chứng chỉ cho hạ tầng/đơn vị khác; phạm vi không bao phủ dịch vụ thực tế).
• Không xuất trình được dấu vết vận hành (log, audit trail) hoặc chỉ cung cấp ảnh chụp/slide không kiểm chứng.
• Khi hỏi tình huống “quy định thay đổi”, không chỉ ra được quy trình xử lý thay đổi và bằng chứng đã từng xử lý.
• Bằng chứng “đẹp” nhưng không có ngày tháng/phiên bản/đầu mối chịu trách nhiệm, khó quy chiếu.

Đánh giá mức độ sản phẩm tạo được niềm tin thông qua an toàn, minh bạch vận hành, tính toàn vẹn dữ liệu và khả năng chịu sự cố, đặc biệt khi mở rộng quy mô.

1. Mục tiêu đánh giá

Tiêu chí này dùng để phân biệt “có vẻ an toàn” với “đáng tin trong thực chiến”.

2. Các chiều đo

3. Thang đánh giá định tính–định lượng

Điểm thấp

• • Mô tả chung chung “bảo mật cao”, “đảm bảo an toàn” nhưng thiếu cơ chế cụ thể và thiếu kiểm thử.
  • Không có cơ chế truy vết; không chứng minh được kế hoạch ứng phó sự cố/khôi phục.

Điểm cao

• • Có kiểm soát bảo mật và minh bạch vận hành thể hiện trong kiến trúc và quy trình; có kiểm thử và kết quả đo kiểm/đánh giá.
  • Có bằng chứng vận hành về giám sát, xử lý sự cố, khôi phục và duy trì mức dịch vụ khi mở rộng.

4. Bằng chứng nên có

5. Trọng tâm theo mức trưởng thành

M1–M2: Kiến trúc và giả định tin cậy: điểm kiểm soát, ranh giới tin cậy, kế hoạch tối thiểu cho log–phân quyền–bảo vệ dữ liệu..

M3–M4: Bằng chứng thực chiến: vận hành an toàn, phản ứng sự cố, khả năng phục hồi, và mức tin cậy khi chạy ở quy mô lớn/đa khách hàng.

6. Lỗi thường gặp / Dấu hiệu cảnh báo

• “Bảo mật bằng cam kết”: chỉ có policy/slide, không có log, kết quả kiểm thử, hay hồ sơ xử lý sự cố.
• Cung cấp báo cáo kiểm thử nhưng không nêu phạm vi, thời điểm, môi trường, khó đối chiếu.
• Không chứng minh được cơ chế phân quyền thực tế; demo chỉ bằng tài khoản quản trị.
• Nói “có DR/Backup” nhưng không có kết quả diễn tập hoặc không định lượng được RPO/RTO theo vận hành.
• Dữ liệu đầu vào/nguồn dữ liệu không rõ hợp pháp–hợp lệ, nhưng vẫn tuyên bố “đáng tin

Đánh giá mức độ “thông minh có kiểm chứng” của sản phẩm, bao gồm thuật toán/mô hình, khả năng suy luận/tự động hóa và chất lượng kết quả trong bối cảnh sử dụng thực tế.

1. Mục tiêu đánh giá

Tiêu chí này dùng để phân biệt “có AI/thuật toán” với “tạo ra kết quả thông minh đo được.

2. Các chiều đo

3. Thang đánh giá định tính–định lượng

Điểm thấp

• • Chỉ nêu “có AI/ML/Agent” nhưng không nêu được pipeline dữ liệu–mô hình–đánh giá; không có baseline/đo kiểm.
  • Không có kiểm soát: mô hình quyết định “hộp đen”, không biết sai ở đâu và xử lý sai thế nào.

Điểm cao

• • Có đo kiểm có phương pháp; có benchmark/baseline, có phân tích lỗi và điều kiện áp dụng.
  • Có cơ chế kiểm soát–giải trình; tự động hóa đi kèm ràng buộc và giám sát để giảm rủi ro vận hành.

4. Bằng chứng nên có

M1–M2

• • Sơ đồ pipeline dữ liệu–mô hình–đánh giá; mô tả mô hình/thuật toán (tài liệu kỹ thuật).
  • Kết quả benchmark/pilot có đối chiếu baseline; bộ dữ liệu thử nghiệm (mô tả nguồn, đặc tính, cách chia).
  • Nhật ký thí nghiệm (experiment logs) và tiêu chí đánh giá/tiêu chí dừng.

M3–M4

• • Dashboard chất lượng mô hình trong vận hành (drift, lỗi, cảnh báo), quy trình MLOps/ModelOps.
  • Hồ sơ kiểm thử hồi quy (regression) khi cập nhật mô hình; hồ sơ sự cố liên quan đầu ra thông minh và khắc phục.
  • Chứng minh cơ chế kiểm soát (rule/guardrails), human-in-the-loop, audit trail quyết định.

5. Trọng tâm theo mức trưởng thành

M1–M2: Độ “thật” của lõi kỹ thuật: tính mới, kiến trúc, benchmark, tính hợp lệ của thí nghiệm/pilot.

M3–M4: Độ “bền” của thông minh trong vận hành: kiểm soát rủi ro, chất lượng ổn định, giám sát drift, và khả năng tối ưu/điều chỉnh có kỷ luật.

6. Lỗi thường gặp / Dấu hiệu cảnh báo

• Trình bày “AI” nhưng không có benchmark/baseline, chỉ demo tình huống thuận lợi.
• Kết quả đo kiểm không có mô tả dữ liệu, không có điều kiện áp dụng, khó tái hiện.
• Không chứng minh được cơ chế kiểm soát khi sai (fallback, ngưỡng tin cậy, human override).
• Nhầm lẫn giữa “tự động hóa quy tắc” và “thông minh học máy” để thổi phồng năng lực.
• Không có theo dõi drift/suy giảm chất lượng khi triển khai rộng, nhưng vẫn khẳng định ổn định.

Đánh giá khả năng sản phẩm tạo ra trải nghiệm sử dụng hiệu quả và khả năng thích nghi nhanh với thay đổi nghiệp vụ/kỹ thuật, đặc biệt khi mở rộng triển khai

1. Mục tiêu đánh giá

Tiêu chí này dùng để phân biệt “dùng được khi demo” với “dùng được trong tổ chức thật và đổi được khi điều kiện thay đổi”.

2. Các chiều đo

3. Thang đánh giá định tính–định lượng

Điểm thấp

• • UX phụ thuộc hướng dẫn thủ công; người dùng phải dùng Excel/ngoài hệ thống để hoàn thành công việc.
  • Thay đổi nhỏ cũng cần can thiệp kỹ thuật nặng; nâng cấp gây gián đoạn và rủi ro cao.

Điểm cao:

• • UX nhất quán, giảm ma sát, có bằng chứng sử dụng thường xuyên; lỗi thao tác được kiểm soát.
  • Cấu hình được quy trình/tham số nhanh và có quản trị thay đổi; triển khai/nâng cấp có cơ chế kiểm soát và ít gián đoạn.

4. Bằng chứng nên có

M1–M2

• • Kết quả usability test/pilot (kịch bản, thời gian tác vụ, lỗi, phản hồi định tính có cấu trúc).
  • Prototype luồng nghiệp vụ cốt lõi; tài liệu kiến trúc UI/UX (design system, guideline).
  • Demo cấu hình một thay đổi đơn giản (mẫu biểu/luồng) kèm ghi nhận thao tác và thời gian thực hiện.

M3–M4

• • Telemetry/analytics sử dụng (active users, funnel tác vụ, lỗi giao diện), hồ sơ hỗ trợ (ticket taxonomy).
  • Release notes, kế hoạch triển khai, bằng chứng rollout/rollback, thời gian gián đoạn thực tế.
  • Bằng chứng tích hợp (API docs, kết quả tích hợp thực tế, log giao tiếp, chứng nhận tương thích nếu có).

5. Trọng tâm theo mức trưởng thành

M1–M2: Tính rõ ràng của tác vụ lõi, khả dụng tối thiểu, và năng lực cấu hình nền tảng (không khóa chết vào code).

M3–M4: Tính linh hoạt ở quy mô vận hành: quản trị thay đổi, chu kỳ phát hành, giảm gián đoạn, và khả năng tích hợp/triển khai đa môi trường.

6. Lỗi thường gặp / Dấu hiệu cảnh báo

• Demo “mượt” nhưng không có dữ liệu sử dụng thực tế hoặc telemetry bị tắt/không truy xuất.
• Tỷ lệ ticket hỗ trợ cao, nhưng báo cáo chỉ đưa “đánh giá hài lòng” chung chung, không có phân loại lỗi.
• “No-code/low-code” nhưng khi yêu cầu thay đổi quy trình thật thì phải sửa mã nguồn hoặc mất thời gian bất thường.
• Nâng cấp phiên bản không có rollback; kế hoạch triển khai thiếu kiểm soát, dễ gây downtime.
• API/khả năng tích hợp được quảng bá rộng, nhưng không chứng minh được case tích hợp thực tế

Đánh giá mức độ sản phẩm tạo ra giá trị kinh tế đo được cho khách hàng/thị trường (doanh thu, tiết kiệm chi phí, tăng năng suất), phù hợp với giai đoạn trưởng thành của sản phẩm

1. Mục tiêu đánh giá

Tiêu chí này dùng để phân biệt “tiềm năng kinh tế” với “kết quả kinh tế đã xảy ra và có thể kiểm chứng”.

2. Các chiều đo

3. Thang đánh giá định tính–định lượng

Điểm thấp

• • Chỉ nêu “tăng năng suất/tiết kiệm” nhưng không có cách đo; số liệu không đối soát được.
  • Doanh thu/khách hàng có nhưng không chứng minh được lợi ích và/hoặc phụ thuộc quá mức vào dự án đơn lẻ.

Điểm cao

• • Có chỉ số lợi ích đo được, có đối soát trước–sau hoặc so với baseline; dữ liệu nhất quán theo thời gian.
  • Mô hình kinh doanh bền và có bằng chứng mở rộng (tăng trưởng khách hàng/khối lượng đi kèm hiệu quả).

4. Bằng chứng nên có

M1–M2

• • Mô hình lợi ích (value model) và giả định đo lường; thiết kế KPI/OKR cho pilot.
  • Kết quả pilot có đối soát (before–after), biên bản nghiệm thu/đánh giá kết quả thử nghiệm.
  • Bằng chứng về nhu cầu thị trường: hợp đồng thử nghiệm, LOI, pipeline có định danh và điều kiện.

M3–M4

• • Báo cáo doanh thu theo sản phẩm (ARR/GMV theo mô hình kinh doanh phù hợp), đối soát với chứng từ/hóa đơn/hợp đồng.
  • Dashboard vận hành thể hiện sử dụng thực tế và tác động (giảm thời gian xử lý, giảm lỗi, tiết kiệm chi phí).
  • Thư xác nhận/biên bản nghiệm thu của khách hàng về lợi ích và mức độ đạt KPI.

5. Trọng tâm theo mức trưởng thành

M1–M2: Logic tạo giá trị và cách đo: giả định có hợp lý, KPI có thiết kế, pilot có đối soát.

M3–M4: Kết quả đã xảy ra: doanh thu/hiệu quả có đối soát, độ bền theo thời gian, và khả năng mở rộng với chi phí hợp lý.

6. Lỗi thường gặp / Dấu hiệu cảnh báo

• Số liệu doanh thu/khách hàng không đối soát được (thiếu hợp đồng/hóa đơn; số liệu không nhất quán giữa các tài liệu).
• “Case study” chỉ là câu chuyện, không có baseline và phương pháp đo, không có chữ ký/xác nhận.
• Trộn lẫn doanh thu dịch vụ dự án với doanh thu sản phẩm để làm đẹp chỉ số.
• KPI “giảm chi phí” nhưng không chỉ ra cấu phần chi phí và cách tính; số liệu thay đổi theo cách trình bày.
• Tăng trưởng nhanh nhưng không chứng minh được năng lực vận hành (dẫn đến rủi ro suy giảm chất lượng và giá trị thực

Đánh giá mức độ sản phẩm tạo ra tác động xã hội/môi trường có thể kiểm chứng (tính bao trùm, giảm phát thải, an sinh, an toàn), không đồng nhất với hoạt động truyền thông hay thiện nguyện ngoài sản phẩm

1. Mục tiêu đánh giá

Tiêu chí này dùng để phân biệt “tuyên bố ESG” với “tác động ESG gắn trực tiếp vào sản phẩm và đo được”.

2. Các chiều đo

3. Thang đánh giá định tính–định lượng

Điểm thấp

• • Nêu “đóng góp xã hội/Net Zero” nhưng không chỉ ra cơ chế sản phẩm và không có phương pháp đo.
  • Đo lường dựa trên ước tính tự khai thiếu baseline, thiếu đối soát.

Điểm cao

• • Cơ chế tác động gắn vào tính năng; có chỉ số đo và đối soát (trước–sau hoặc theo chuẩn đo).
  • Có xác nhận/kiểm chứng từ triển khai thực tế, có quản trị rủi ro tác động ngoài ý muốn.

4. Bằng chứng nên có

M1–M2

• • Lý thuyết thay đổi (theory of change) gắn với tính năng; thiết kế chỉ số (KPIs) và phương pháp đo cho pilot.
  • Kết quả thử nghiệm/pilot có baseline và phương pháp thu thập dữ liệu tác động.
  • Tài liệu đánh giá rủi ro tác động và biện pháp giảm thiểu (impact risk assessment).

M3–M4

• • Báo cáo tác động định lượng (ví dụ: giảm thời gian xử lý y tế, giảm phát thải, giảm thất thoát) kèm dữ liệu nguồn và cách tính.
  • Xác nhận của bên thụ hưởng/đơn vị triển khai (biên bản nghiệm thu, thư xác nhận chỉ số).
  • Dashboard vận hành thể hiện tác động theo thời gian và phạm vi triển khai.

5. Trọng tâm theo mức trưởng thành

M1–M2: Cơ chế tác động và thiết kế đo: chỉ số đúng, baseline đúng, dữ liệu thu thập khả thi.

M3–M4: Tác động đã xảy ra và bền: đối soát dữ liệu, xác nhận bên thứ ba/khách hàng, và quản trị rủi ro tác động khi mở rộng.

6. Lỗi thường gặp / Dấu hiệu cảnh báo

• Đưa báo cáo ESG cấp doanh nghiệp thay cho tác động do sản phẩm tạo ra.
• Chỉ số tác động thay đổi theo “cách kể”, không có phương pháp tính và dữ liệu nguồn.
• Dùng “số người tiếp cận”/lượt xem thay cho tác động thực (outcome).
• Trộn lẫn hoạt động CSR/thiện nguyện với giá trị ESG của sản phẩm.
• Không đánh giá tác động ngoài ý muốn (ví dụ: thiên lệch, loại trừ nhóm yếu thế, rủi ro dữ liệu) nhưng vẫn khẳng định “tích cực”.

Đánh giá khả năng sản phẩm duy trì tính cạnh tranh trong trung–dài hạn thông qua kiến trúc mở rộng, năng lực đổi mới liên tục, thích ứng chuẩn mới và quản trị rủi ro công nghệ

1. Mục tiêu đánh giá

Tiêu chí này dùng để phân biệt “tầm nhìn” với “năng lực sẵn sàng có nền tảng và lộ trình thực thi”.

2. Các chiều đo

3. Thang đánh giá định tính–định lượng

Điểm thấp

• • Roadmap mang tính khẩu hiệu; kiến trúc khó mở rộng, phụ thuộc nặng vào một thành phần/nhà cung cấp mà không có phương án dự phòng.
  • Không có cơ chế phát hành và kiểm soát chất lượng khi thay đổi; nâng cấp gây đứt gãy.

Điểm cao

• • Kiến trúc cho phép tiến hóa, tích hợp và mở rộng; có lộ trình và cơ chế thực thi (release governance, chất lượng, tương thích).
  • Có quản trị rủi ro công nghệ và bằng chứng đã thích ứng với thay đổi (chuẩn mới, môi trường mới, quy mô mới).

4. Bằng chứng nên có

M1–M2

• • Roadmap có mốc, ưu tiên, phụ thuộc và tiêu chí hoàn thành; backlog/issue tracker thể hiện công việc R&D.
  • Tài liệu kiến trúc mục tiêu (target architecture), nguyên tắc thiết kế, chiến lược API/chuẩn dữ liệu.
  • Kế hoạch quản trị rủi ro kỹ thuật (dependency map, phương án thay thế, chiến lược IP cơ bản).

M3–M4

• • Lịch sử phát hành và nâng cấp (release history), kết quả kiểm thử hồi quy, tỷ lệ lỗi sau phát hành, cơ chế rollback.
  • Bằng chứng mở rộng môi trường/khách hàng (multi-tenant, đa vùng/đa cloud nếu có), tài liệu tương thích và tích hợp hệ sinh thái.
  • Hồ sơ xử lý thay đổi chuẩn/quy định/công nghệ (change records) và tác động lên sản phẩm.

5. Trọng tâm theo mức trưởng thành

M1–M2: Nền tảng sẵn sàng: kiến trúc định hướng tiến hóa, roadmap có kỷ luật, quản trị rủi ro phụ thuộc và khóa công nghệ.

M3–M4: Bằng chứng tiến hóa: lịch sử nâng cấp ít gián đoạn, thích ứng chuẩn/hệ sinh thái, và năng lực mở rộng/đổi mới liên tục trong vận hành.

6. Lỗi thường gặp / Dấu hiệu cảnh báo

• Roadmap “đẹp” nhưng không có dấu vết thực thi (repo/issue tracker/release history không phản ánh).
• Kiến trúc quảng bá “microservices/cloud-native” nhưng không chứng minh được modularity, quan sát vận hành và triển khai thực tế.
• Phụ thuộc vào một nền tảng/nhà cung cấp ở điểm sống còn, không có phương án thoát hoặc phương án chỉ nằm trên giấy.
• Nâng cấp thường gây gián đoạn; không có regression test/rollback; chất lượng sau phát hành không được theo dõi.
• Tuyên bố “quốc tế hóa” nhưng không có bằng chứng tương thích chuẩn, bảo mật, và vận hành đa môi trường.