title: "Giai đoạn B (Business Architecture): Kỹ thuật Value Stream Mapping cho doanh nghiệp phức tạp"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 2 — Giải phẫu ADM (Mastering the ADM Cycle)"
order: 13
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "13 phút"
tags:

• TOGAF
• ADM
• Business Architecture
• Value Stream Mapping
• Enterprise Architecture
• Business Capability

Giai đoạn B (Business Architecture): Kỹ thuật Value Stream Mapping cho doanh nghiệp phức tạp

Một công ty logistics tôi từng làm việc cùng có một phòng Sales rất tự hào: thời gian chốt hợp đồng trung bình 3 ngày, thuộc hàng nhanh nhất ngành. Phòng Vận hành cũng tự hào không kém: tỷ lệ giao hàng đúng hẹn 96%. Phòng CSKH thì báo cáo NPS liên tục cải thiện. Ba con số đẹp, ba phòng ban đều đang làm tốt phần việc của mình. Nhưng khách hàng thì vẫn than phiền rằng từ lúc ký hợp đồng đến lúc lô hàng đầu tiên chạy được là gần ba tuần — trong khi đối thủ chỉ mất một tuần.

Đây chính là cái bẫy mà hầu hết doanh nghiệp rơi vào khi đánh giá hiệu suất: đo lường theo silo chức năng thay vì đo lường theo giá trị mà khách hàng thực sự nhận được. Mỗi phòng ban tối ưu cục bộ (local optimization) cho quy trình của riêng mình, và không ai chịu trách nhiệm cho cái khoảng trống ở giữa — nơi giá trị bị nghẽn lại, chờ đợi, hoặc rơi rụng. Đây cũng chính là lý do Giai đoạn B của ADM (Architecture Development Method) không bắt đầu bằng câu hỏi "hệ thống nào đang chạy" hay "phòng ban nào làm gì", mà bắt đầu bằng câu hỏi nền tảng hơn: doanh nghiệp này tạo ra giá trị cho khách hàng bằng cách nào?

Nhiều Solutions Architect khi bước vào vai trò EA vẫn có phản xạ cũ: mở ngay bức tranh hệ thống, vẽ luồng dữ liệu, liệt kê API. TOGAF đặt Business Architecture ngay sau Architecture Vision không phải ngẫu nhiên — nó buộc bạn phải hiểu "cái gì tạo ra giá trị" trước khi hỏi "cái gì cần công nghệ hỗ trợ". Bỏ qua bước này, bạn sẽ xây được một kiến trúc công nghệ rất đẹp cho một mô hình kinh doanh mà chính công ty cũng chưa hiểu rõ về mình.

Bản chất

Giai đoạn B — Business Architecture — trong ADM là giai đoạn kiến trúc sư mô tả trạng thái hiện tại (Baseline Architecture) và trạng thái mong muốn (Target Architecture) của khía cạnh kinh doanh: chiến lược, quản trị (governance), tổ chức, và các quy trình nghiệp vụ cốt lõi. Đây là nền móng cho toàn bộ các giai đoạn sau — Data Architecture, Application Architecture, Technology Architecture — vì suy cho cùng, hệ thống thông tin tồn tại để phục vụ nghiệp vụ, không phải ngược lại.

Công cụ trung tâm mà bài này tập trung là Value Stream Mapping — kỹ thuật vẽ ra chuỗi các hoạt động tạo giá trị (value stream), bắt đầu từ một tác nhân kích hoạt (trigger — thường là nhu cầu của khách hàng hoặc một sự kiện kinh doanh) và kết thúc bằng giá trị cụ thể được giao tới cho một bên thụ hưởng (stakeholder).

Điểm khác biệt cốt lõi cần nắm rõ: Value Stream KHÔNG phải là một quy trình nghiệp vụ (business process). Đây là nhầm lẫn phổ biến nhất khi các SA mới tiếp cận Business Architecture.

• Business Process là chuỗi các bước, hoạt động, quyết định để hoàn thành một công việc cụ thể, thường nằm gọn trong một hoặc vài phòng ban, và có thể mô tả chi tiết bằng BPMN với đầy đủ luồng rẽ nhánh, exception handling, actor thực hiện từng bước.
• Value Stream là luồng giá trị theo chiều ngang (end-to-end, cross-functional), nhìn từ góc độ khách hàng hoặc stakeholder nhận giá trị, mô tả ở tầng trừu tượng cao hơn nhiều — thường chỉ 5-8 "chặng" (stage), mỗi chặng có thể được hiện thực bởi nhiều quy trình, nhiều phòng ban, nhiều hệ thống.

Nói cách khác: quy trình trả lời câu hỏi "làm thế nào" (how), còn value stream trả lời câu hỏi "giá trị gì, cho ai, qua những chặng nào" (what value, for whom, through which stages) — và quan trọng nhất, nó không quan tâm ranh giới tổ chức. Một value stream có thể xuyên qua Sales, Ops, Finance, CSKH mà không hề bận tâm sơ đồ tổ chức vẽ ranh giới ở đâu. Chính vì tính chất "xuyên phòng ban" này mà value stream mới là công cụ phát hiện ra những khoảng trống (gap) mà không phòng ban nào tự nhìn thấy — vì mỗi phòng ban, theo định nghĩa, chỉ nhìn thấy quy trình của chính mình.

Khung & Kỹ thuật áp dụng

Cấu trúc một Value Stream trong TOGAF/Business Architecture Guild

Một value stream được cấu thành từ các thành phần sau:

Quy trình vẽ Value Stream — 5 bước thực dụng

1. Xác định Stakeholder & Trigger: Value stream luôn bắt đầu từ góc nhìn bên ngoài — khách hàng, đối tác, hoặc một đơn vị nghiệp vụ nhận giá trị. Tránh bắt đầu từ góc nhìn nội bộ ("khi Sales nhận lead...").

2. Vẽ các Value Stream Stage ở tầng cao (high-level, 5-8 chặng): Đây là bước dễ sa đà nhất — SA quen tư duy quy trình sẽ có xu hướng vẽ 20-30 bước chi tiết. Nguyên tắc: nếu một chặng không tạo ra một trạng thái giá trị mới rõ rệt cho stakeholder, nó không phải là một stage riêng, mà là một bước bên trong stage khác.

3. Gán Value Stream Stage Outcome cho từng chặng: Mỗi chặng phải trả lời được "sau chặng này, giá trị đã tiến thêm được gì". Đây chính là cơ sở để đo lường sau này (khác với KPI vận hành của từng phòng ban).

4. Mapping value stream với Business Capability (sẽ đi sâu ở Bài 14): mỗi Value Stream Stage cần một hoặc nhiều Business Capability để thực hiện được. Đây là bước bắc cầu quan trọng — value stream trả lời "giá trị gì", capability trả lời "doanh nghiệp cần năng lực gì để tạo ra giá trị đó", và các giai đoạn sau của ADM mới trả lời "hệ thống/công nghệ nào hỗ trợ năng lực đó".

5. Đối chiếu với Organization Map: đặt value stream cạnh sơ đồ tổ chức để xác định mỗi stage đang được (các) phòng ban nào đảm nhận — đây chính là bước lộ ra các "đường nối liền phòng ban" (handoff) tiềm ẩn rủi ro.

Phân biệt hai loại value stream

TOGAF/Business Architecture Guild phân biệt:

• Core Value Stream: tạo giá trị trực tiếp cho khách hàng bên ngoài (ví dụ: "Từ Yêu cầu Báo giá đến Giao hàng").
• Supporting Value Stream: tạo giá trị cho stakeholder nội bộ, phục vụ cho Core Value Stream vận hành được (ví dụ: "Tuyển dụng Nhân sự mới", "Onboard Nhà cung cấp").

Việc phân loại này giúp EA ưu tiên: Core Value Stream luôn được ưu tiên phân tích và đầu tư trước vì tác động trực tiếp đến doanh thu và trải nghiệm khách hàng.

Case thực tế minh hoạ

Lưu ý: đây là tình huống minh hoạ tổng hợp điển hình, không phải case của một công ty cụ thể có thật, số liệu chỉ mang tính minh hoạ.

Một doanh nghiệp cung cấp dịch vụ B2B (mô hình tương tự công ty logistics/SaaS enterprise) có cấu trúc tổ chức khá điển hình: phòng Sales, phòng Triển khai (Implementation/Onboarding), phòng Vận hành (Operations), phòng CSKH. Ban lãnh đạo yêu cầu đội EA tìm hiểu vì sao "Time-to-Value" — thời gian từ lúc khách hàng ký hợp đồng đến lúc thực sự sử dụng được dịch vụ và thấy giá trị — kéo dài gần gấp ba lần so với cam kết trong hợp đồng, dù mỗi phòng ban báo cáo KPI nội bộ đều đạt hoặc vượt chỉ tiêu.

Đội EA tiến hành vẽ Value Stream "Từ Ký Hợp đồng đến Khách hàng Thấy Giá trị Đầu tiên" (Contract-to-First-Value), với 6 chặng: (1) Ký hợp đồng, (2) Bàn giao thông tin khách hàng cho Triển khai, (3) Cấu hình hệ thống theo yêu cầu khách hàng, (4) Kiểm thử & Nghiệm thu nội bộ, (5) Đào tạo người dùng phía khách hàng, (6) Go-live & Khách hàng ghi nhận giá trị đầu tiên.

Khi đối chiếu từng chặng với Organization Map, một khoảng trống lộ ra ở ranh giới giữa chặng (2) và (3) — giữa phòng Sales và phòng Triển khai. Sales có quy trình nội bộ hoàn chỉnh, đo lường bằng "thời gian chốt deal" (kết thúc ngay khi hợp đồng được ký — coi như xong việc). Triển khai cũng có quy trình nội bộ hoàn chỉnh, đo lường bằng "thời gian cấu hình hệ thống" (bắt đầu tính từ khi "nhận đủ thông tin khách hàng"). Vấn đề nằm ở chữ "nhận đủ" — không có Value Stream Stage Outcome nào được định nghĩa rõ ràng cho việc bàn giao giữa hai phòng. Sales coi bàn giao là gửi một email kèm hợp đồng PDF; Triển khai cần một bộ thông tin kỹ thuật chi tiết hơn nhiều (cấu hình mong muốn, tích hợp hệ thống hiện có, danh sách người dùng, yêu cầu bảo mật...) mà Sales không hề biết là cần thu thập từ đầu.

Kết quả: trung bình mỗi hợp đồng bị "treo" 8-12 ngày ở đúng khoảng trống này — Triển khai phải quay lại liên hệ khách hàng để thu thập lại thông tin mà lẽ ra Sales đã có thể hỏi ngay trong quá trình chốt deal. Cả hai phòng đều báo cáo KPI riêng "xanh" vì không phòng nào đo khoảng thời gian chờ ở giữa — nó rơi vào một vùng không ai sở hữu (ownership gap). Đây chính xác là loại đứt gãy mà không một audit quy trình nội bộ từng phòng ban nào từng phát hiện ra, đơn giản vì audit nội bộ luôn dừng lại ở ranh giới của chính phòng ban đó.

Giải pháp không phải là công nghệ — mà là kiến trúc: định nghĩa lại Value Stream Stage Outcome cho chặng (2) thành một "Handoff Package" cụ thể, rõ ràng, có checklist, được Sales thu thập ngay trong quá trình đàm phán hợp đồng, và trở thành điều kiện đầu vào bắt buộc (entry criteria) cho chặng (3). Chỉ riêng thay đổi cấu trúc trách nhiệm liên phòng ban này (chưa cần đổi hệ thống) đã có tiềm năng rút ngắn đáng kể khoảng trễ Time-to-Value.

📐 Template/Artifact áp dụng ngay

Value Stream Map Canvas — dùng để vẽ và audit một value stream trong buổi làm việc với stakeholder liên phòng ban:

Cách dùng:

1. Điền cột 1-2 trước, chỉ dừng ở mức 5-8 stage — nếu vượt quá, đang lẫn quy trình chi tiết vào value stream.
2. Cột "Entry/Exit Criteria" là nơi phát hiện gap nhanh nhất: nếu Exit Criteria của stage trước không khớp với Entry Criteria của stage sau, đó chính là đường nứt liên phòng ban.
3. Điền "Thời gian hiện tại" bằng dữ liệu thực đo (không phải ước lượng cảm tính) để có Baseline định lượng cho Gap Analysis ở các giai đoạn sau.
4. Với mỗi stage, note lại phòng ban thực hiện — nếu một stage có từ 2 phòng ban trở lên, đánh dấu ưu tiên rà soát handoff.

🎯 Góc nhìn Chief EA

• Nếu tách rời từng phòng ban ra, KPI của ai cũng "xanh" — vậy ai đang chịu trách nhiệm cho tổng thời gian giao giá trị tới khách hàng?
• Value Stream Stage Outcome của tôi có đang được định nghĩa bằng ngôn ngữ giá trị (khách hàng nhận được gì), hay đang lén lẫn vào ngôn ngữ hoạt động nội bộ ("đã gửi email", "đã tạo ticket")?
• Nếu xoá hết ranh giới phòng ban trên giấy, tôi có vẽ lại được đúng luồng giá trị này không, hay tôi đang bị chi phối bởi sơ đồ tổ chức hiện tại?
• Khoảng trống nào trong value stream này không ai sở hữu — và ai là người có thẩm quyền để tôi đề xuất giao trách nhiệm đó?

🔄 Vị trí trong chu trình ADM

Value Stream Mapping trong Giai đoạn B không đứng độc lập — nó là một mắt xích có đầu vào và đầu ra rõ ràng trong chu trình ADM tuần hoàn:

• Nhận đầu vào từ: Architecture Vision (Giai đoạn A, bài 11) — phạm vi, mục tiêu chiến lược, và các stakeholder concern đã được xác lập ở Giai đoạn A chính là khung để chọn value stream nào cần ưu tiên vẽ trước (thường là Core Value Stream gắn trực tiếp với mục tiêu kinh doanh trong Architecture Vision).
• Cho đầu ra sang: Giai đoạn C — Information Systems Architecture (bài 15-16) — Value Stream đã vẽ, cùng với các Value Stream Stage Outcome và mapping Business Capability đi kèm, chính là cơ sở để xác định hệ thống thông tin và ứng dụng nào cần được thiết kế hoặc điều chỉnh để hỗ trợ đúng luồng giá trị đó, thay vì thiết kế hệ thống theo cảm tính hoặc theo ranh giới phòng ban sẵn có.

Nói cách khác: nếu Giai đoạn A trả lời "chúng ta đang đi đâu", thì Value Stream Mapping ở Giai đoạn B trả lời "giá trị chảy qua đâu để đến đó" — và câu trả lời này là điều kiện tiên quyết để Giai đoạn C trả lời tiếp "hệ thống nào cần đứng đúng chỗ để phục vụ dòng chảy đó".

🔗 Bài viết liên quan

• Giai đoạn A (Vision) — nền tảng Architecture Vision mà Value Stream Mapping kế thừa phạm vi và mục tiêu.
• Giai đoạn B (Business Capability) — bước tiếp theo, chuyển từ "giá trị chảy qua đâu" sang "doanh nghiệp cần năng lực gì" để hiện thực hoá value stream.

Bài trước: Giai đoạn A (Stakeholder Management) · Bài tiếp theo: Giai đoạn B (Business Capability)