Tầng thực thi

Capability trả lời CÁI GÌ. Bốn tầng dưới đây trả lời BẰNG CÁCH NÀO và NHỜ CÁI GÌ.

Capability
    ↓
Sub-capability
    ↓
Process          ← Quy trình
    ↓
Activity         ← Hoạt động
    ↓
Application      ← Ứng dụng
    ↓
Technology       ← Công nghệ

Song song với chuỗi đó là Data (Conan biết gì) và Value Stream (giá trị chảy như thế nào).

Value Chain khác Value Stream

Hai khái niệm gần nhau nhưng không cùng góc nhìn, và nhầm lẫn giữa chúng là lỗi phổ biến nhất khi đọc mô hình.

	Value Chain	Value Stream
Góc nhìn	Doanh nghiệp tự nhìn mình	Người thụ hưởng
Câu hỏi	Doanh nghiệp tạo giá trị bằng những hoạt động nào?	Giá trị đi qua những chặng nào để đến được với một người?
Phạm vi	Toàn bộ mô hình vận hành	Một hành trình
Tính chất	Ổn định, thay đổi chậm	Cắt ngang nhiều bộ phận
Dùng để	Chiến lược, mô hình vận hành	Hành trình, chuyển đổi

Ví dụ bệnh viện: Value Chain là các bộ phận làm nên bệnh viện (tiếp nhận, khám chữa, xét nghiệm, dược, thu ngân). Value Stream là hành trình một bệnh nhân đi từ ốm đến khoẻ — không bộ phận nào sở hữu trọn hành trình đó.

Hai dòng này gặp nhau ở Capability Model:

Chiến lược      → Value Chain   → Capability → Đầu tư
Người thụ hưởng → Value Stream  → Capability → Process → Application → Data → Technology

Compass hiện chỉ mô hình hoá Value Stream

Value Chain là góc nhìn doanh nghiệp, hữu ích cho chiến lược và mô hình vận hành, nhưng chưa có trong Compass. Màn hình /glossary giải thích khái niệm này và ghi rõ nó chưa được mô hình hoá, để người đọc không nhầm Value Stream là tất cả.

Trước Value Stream: hiểu người thụ hưởng

Chuỗi giá trị không phải điểm khởi đầu. Trước nó là bốn câu hỏi về con người, và mỗi câu trả lời một việc khác nhau:

#	Khái niệm	Cho biết
1	JTBD (Việc cần hoàn thành)	Người thụ hưởng đang cố hoàn thành điều gì
2	Pains (Điểm đau)	Điều gì đang cản trở họ
3	Needs (Nhu cầu)	Họ cần gì
4	Journey (Hành trình)	Họ trải qua những chặng nào
5	Value Stream	Conan phải tạo ra giá trị gì ở mỗi chặng

Ví dụ với một người học Nemo12:

• JTBD — "Giúp tôi trở thành người dám nói mà không sợ."
• Pain — "Tôi đứng hình khi bị sửa lỗi trước cả lớp."
• Need — "Tôi cần một nơi an toàn để sai."
• Journey stage — Học
• Value Conan phải tạo ra ở chặng đó — "Năng lực của tôi thực sự thay đổi."

Bỏ qua một mắt xích là hỏng cả chuỗi

Nếu nhảy thẳng từ chiến lược sang Value Stream mà không đi qua JTBD, Pains và Needs, các chặng sẽ được đặt tên theo việc Conan làm — vì đó là thứ duy nhất người viết biết rõ. Đó chính là cách một chuỗi giá trị biến thành phễu marketing.

Bốn khái niệm này chưa được mô hình hoá trong Compass — hiện chúng được giải thích ở màn hình /glossary để người đọc biết chuỗi giá trị đến từ đâu. Trong số đó, Need đã có nơi ở: một nhu cầu được viết thành Requirement trong mặt phẳng Requirements (Intent / User / Problem / Outcome / Acceptance), và thuật ngữ needs trên /glossary trỏ sang đó. JTBD, Pains và Journey vẫn chưa lưu thành dữ liệu; nếu cần, chỗ tự nhiên nhất là gắn vào value_streams (JTBD của stakeholder) và value_stream_stages (pains tại từng chặng).

Value Stream

Value Stream trả lời: giá trị đến với một người như thế nào? Capability trả lời: Conan cần khả năng gì để tạo ra giá trị đó?

Điểm mấu chốt: chuỗi giá trị được viết bằng giọng của người thụ hưởng, không phải giọng của Conan.

Phép thử "Tôi"

Mỗi chặng phải đọc lên được một cách tự nhiên như một câu người thụ hưởng tự nói về mình:

• "Tôi biết đến…"
• "Tôi tìm hiểu…"
• "Tôi quyết định…"
• "Tôi học được…"
• "Tôi thấy mình tiến bộ…"
• "Tôi đạt được…"
• "Tôi biết bước tiếp theo…"

Những từ trượt phép thử

Thu hút, Ghi danh, Triển khai, Giữ chân — không ai nói "tôi được giữ chân". Đây là những việc Conan làm lên một người, nên chúng thuộc về năng lực hoặc quy trình, không phải chặng giá trị. Một chuỗi giá trị đặt tên bằng những từ này thực chất là một phễu marketing đội lốt.

Generator seed (scripts/seed.mjs) chặn build nếu một chặng không bắt đầu bằng I , và màn hình /governance kiểm tra lại điều đó trên dữ liệu thật.

Ba chuỗi, ba người thụ hưởng

Mỗi chuỗi phải nêu rõ stakeholder của nó. Một chuỗi không có người thụ hưởng thì chỉ là sơ đồ quy trình.

Chuỗi	Người thụ hưởng	Các chặng
Hành trình của người học	Người học	Biết đến → Tìm hiểu → Quyết định → Bắt đầu → Học → Thấy mình tiến bộ → Đạt được → Biết bước tiếp theo
Hành trình của phụ huynh	Phụ huynh / Gia đình	Nghe về Conan → Dần tin tưởng → Quyết định cho con → Được cập nhật → Thấy con trưởng thành → Giới thiệu cho người khác
Hành trình của giáo viên	Giáo viên	Biết Conan → Gia nhập → Hoà nhập → Giỏi lên → Làm được việc tốt nhất của mình → Thấy tương lai ở đây

Phụ huynh không phải người học và không nhận cùng một giá trị — đó là lý do họ cần một chuỗi riêng chứ không phải một chặng trong chuỗi của người học.

Mỗi chặng mang theo gì

Thành phần	Nguồn
Câu "Tôi…"	statement_en / statement_vi — bắt buộc
Giá trị nhận được	outcome_en / outcome_vi — người thụ hưởng cầm về được gì
Sức khoẻ chặng	Suy ra, không nhập: điểm sức khoẻ thấp nhất trong các năng lực đứng sau chặng
Chỉ số giá trị	Bảng key_results với stage_id — đo trải nghiệm của người, không đo hiệu suất của Conan; mỗi chỉ số nằm dưới một Objective hành trình
Năng lực	stage_capabilities

Sức khoẻ được suy ra chứ không nhập tay vì một chặng chỉ mạnh bằng mắt xích yếu nhất của nó — và nếu lưu thành cột riêng thì sớm muộn nó sẽ lệch khỏi dữ liệu gốc.

Từ một chặng đi xuống tới công nghệ

Bấm vào một chặng trên /value-streams mở ra trọn chuỗi phụ thuộc:

Câu "Tôi…"
    ↓
Giá trị nhận được
    ↓
Chỉ số giá trị · Sức khoẻ chặng
    ↓
Năng lực
    ↓
Quy trình
    ↓
Ứng dụng · Dữ liệu
    ↓
Công nghệ

Đây là màn hình trả lời câu hỏi giá trị đang tắc ở đâu — không chỉ liệt kê các chặng tên là gì.

Key Result của năng lực khác chỉ số giá trị

Từ 0015/0016, thước đo sống trong bảng key_results (bảng kpis chỉ còn là hồ sơ nguồn gốc — xem OKR). Một Key Result nhận đúng một trong hai điểm neo, đúng như kpis trước đây (CHECK ở tầng schema):

Neo vào	Đo cái gì	Ví dụ
capability_id	Conan làm tốt đến đâu	Tỷ lệ chuyển đổi lead thành ghi danh
stage_id	Người thụ hưởng thực sự trải nghiệm gì	Phụ huynh phải hỏi mới có thông tin thay vì được cập nhật

Màn hình chặng đọc key_results theo stage_id, và mỗi chỉ số mở sang Objective hành trình chứa nó.

Process

Process là L4 — tầng đầu tiên mô tả cách làm.

Thuộc tính	Ghi chú
capability_id	Quy trình này hiện thực hoá năng lực nào (bắt buộc)
brand_id	NULL nghĩa là dùng chung cho mọi Brand
owner	Bắt buộc theo Rule 7
likelihood · impact · detectability	Rủi ro riêng của quy trình, cùng công thức với năng lực

Mỗi Process chứa các Activity đã được đánh số thứ tự — bước cụ thể mà người thực hiện làm.

Cùng một năng lực, hai Brand hai quy trình

Ghi danh là một năng lực chuẩn. Nemo12 và Conan School có thể có hai quy trình khác nhau cùng trỏ về năng lực đó. Đây chính là chỗ sự khác biệt giữa các Brand được ghi nhận, mà không làm bẩn mô hình chuẩn.

Application

Danh mục ứng dụng, đọc từ phía năng lực chứ không phải từ phía IT:

• Hỗ trợ năng lực nào — quan hệ nhiều–nhiều với capabilities.
• Chạy trên công nghệ nào — quan hệ với technologies.
• Lưu dữ liệu gì — quan hệ với data_entities.
• Vòng đời: evaluate → active → sunset → retired.

Ứng dụng có brand_id = NULL là nền tảng dùng chung. Một ứng dụng dùng chung hỗ trợ nhiều năng lực của nhiều Brand chính là tín hiệu "xây một lần, dùng nhiều nơi".

Bản ghi ứng dụng có một nhà: mặt phẳng Products

Từ Phase 5, ứng dụng còn có product_id (sản phẩm sở hữu), repository (kho mã), nhiều URL và các Release. Nhà của bản ghi là Products (/products/applications/:code). Màn hình /applications của Compass là góc nhìn từ phía năng lực của cùng bảng đó — thẻ hiện chip sản phẩm và URL chính, dùng chung một bộ trường, sửa ở đâu cũng là một bản ghi. Data và Technology ở lại Compass.

Data

Mỗi thực thể dữ liệu có steward (người trông coi) và mức phân loại:

Phân loại	Ý nghĩa
public	Công khai được
internal	Nội bộ
sensitive	Nhạy cảm — dữ liệu người học, phụ huynh, giáo viên, tài chính

Dữ liệu liên kết hai chiều: năng lực nào cần nó và ứng dụng nào lưu nó.

Technology

Công nghệ không nối thẳng tới năng lực. Nó nối tới ứng dụng, và ứng dụng nối tới năng lực:

Technology → Application → Capability

Nhờ vậy hệ thống trả lời được câu hỏi "nếu Cloudflare D1 gặp sự cố thì năng lực nào bị ảnh hưởng?" mà không cần ai phải khai báo quan hệ đó thủ công — màn hình /technology tự suy ra qua hai bước.

Tool không leo lên thành Capability

Đây là lý do tầng này tồn tại. Padlet, CRM, LMS đều là Application. Chúng có thể bị thay thế bất cứ lúc nào mà mô hình năng lực không đổi một dòng nào.