Mở đầu — vì sao bài này quan trọng
Bạn vừa đi qua 29 bài đầu tiên của Module 1. Đó là một chặng đường dài: từ chỗ hiểu BA khác Sales thế nào, đến việc mapping kỹ năng cũ sang competencies mới, học BPMN, viết use case, lập business rule catalog, vẽ state machine, làm quen API, Jira, Confluence, facilitation, wireframe và Agile. Mỗi bài là một mảnh ghép. Nhưng vấn đề muôn thuở của người tự học là: học rời rạc thì biết nhiều thứ, mà ráp lại thành một sản phẩm hoàn chỉnh thì lúng túng.
Capstone 1 sinh ra để giải quyết đúng điều đó. Đây không phải bài học lý thuyết mới. Đây là bài "đóng gói" — nơi bạn lấy chính một deal hoặc dự án Sales/BD mà bạn đã từng làm, rồi tái dựng (re-frame) toàn bộ nó dưới góc nhìn BA. Bạn sẽ tự tay sản xuất ra ba sản phẩm cốt lõi: phân tích stakeholder kèm ma trận RACI, sơ đồ quy trình As-Is và To-Be bằng BPMN, và một gói tài liệu yêu cầu sơ khởi.
Tại sao điều này quan trọng đến mức xứng đáng có hẳn một bài? Vì ba lý do.
Thứ nhất, nhà tuyển dụng BA tại Việt Nam không tuyển dựa trên việc bạn "biết" BPMN — họ tuyển dựa trên việc bạn "làm ra được" một artefact dùng được. Capstone này chính là viên gạch đầu tiên cho portfolio của bạn (mà chúng ta sẽ hoàn thiện ở Bài 46).
Thứ hai, dùng deal cũ của chính bạn giúp bạn học nhanh hơn nhiều so với dùng một case lạ. Bạn đã biết bối cảnh, biết khách hàng cằn nhằn gì, biết deal suýt đổ ở đâu. Việc còn lại chỉ là dịch nó sang "ngôn ngữ BA".
Thứ ba, đây là bài kiểm tra trung thực nhất xem bạn đã thực sự "chuyển đổi tư duy" hay chưa. Nếu bạn vẫn re-frame deal theo kiểu "tôi đã chốt được hợp đồng X", bạn chưa qua. Nếu bạn re-frame được thành "vấn đề nghiệp vụ của khách là gì, quy trình hiện tại nghẽn ở đâu, giải pháp thay đổi quy trình ra sao", bạn đã bắt đầu suy nghĩ như một BA thật sự.
Khái niệm cốt lõi
Capstone 1 yêu cầu bạn tạo ra một bộ deliverables. Trước khi bắt tay, hãy hiểu rõ bản chất từng thành phần và vì sao chúng ghép với nhau thành một câu chuyện mạch lạc.
Re-framing: từ "deal" sang "vấn đề nghiệp vụ"
Cốt lõi của toàn bộ Capstone nằm ở động tác re-frame. Một người Sales nhìn một thương vụ qua lăng kính: ai là người ký, giá trị hợp đồng bao nhiêu, đối thủ là ai, làm sao đẩy nhanh chốt deal. Một BA nhìn cùng tình huống đó qua lăng kính: tổ chức khách hàng đang gặp vấn đề gì, quy trình nào đang gây đau, các bên liên quan nào bị ảnh hưởng, và giải pháp cần thay đổi điều gì để tạo ra giá trị đo lường được.
Đây không phải hai câu chuyện khác nhau — đó là cùng một câu chuyện kể từ hai góc. Khả năng "xoay góc kể chuyện" này chính là năng lực mà nhà tuyển dụng tìm kiếm ở một ex-Sales chuyển BA.
Stakeholder analysis + RACI
Stakeholder analysis là việc nhận diện tất cả các bên liên quan đến giải pháp, rồi phân loại họ theo mức độ ảnh hưởng (influence) và mức độ quan tâm (interest). Công cụ kinh điển là ma trận Power/Interest (2x2): nhóm quyền lực cao - quan tâm cao thì "quản lý sát sao" (manage closely); quyền lực cao - quan tâm thấp thì "giữ hài lòng" (keep satisfied); quyền lực thấp - quan tâm cao thì "giữ thông tin" (keep informed); quyền lực thấp - quan tâm thấp thì "theo dõi" (monitor).
RACI là ma trận phân vai trên từng hoạt động/quyết định của dự án, với bốn vai:
- R (Responsible) — người trực tiếp làm việc đó.
- A (Accountable) — người chịu trách nhiệm cuối cùng, người duyệt (mỗi hoạt động chỉ có đúng MỘT chữ A).
- C (Consulted) — người được hỏi ý kiến trước khi làm (giao tiếp hai chiều).
- I (Informed) — người được thông báo sau khi xong (giao tiếp một chiều).
As-Is và To-Be BPMN
As-Is là sơ đồ quy trình hiện tại — cách mọi việc đang diễn ra, kể cả những bước thủ công, lặp lại, gây nghẽn. To-Be là quy trình tương lai sau khi áp giải pháp. Khoảng cách giữa hai sơ đồ này chính là "giá trị" của dự án, và là nơi bạn chứng minh mình hiểu nghiệp vụ chứ không chỉ bán phần mềm. Bạn đã học ký pháp BPMN 2.0 ở Bài 21 — giờ là lúc dùng nó cho dữ liệu thật.
Gói requirement sơ khởi
Phần thứ ba (mà ý định gốc của đề để dở dang) là các yêu cầu rút ra từ khoảng cách As-Is → To-Be: một danh sách business requirement cấp cao, vài user story kèm acceptance criteria, và một bộ business rule tối thiểu. Đây là bản nháp của BRD/SRS mà bạn sẽ học bài bản ở Module 2.
Tình huống thực tế
Ví dụ 1 — Chị Trang, ex-Account Executive bán phần mềm chấm công
Chị Trang từng làm AE tại một công ty SaaS HR ở TP.HCM, từng chốt một deal triển khai hệ thống chấm công cho một chuỗi F&B 18 chi nhánh, giá trị khoảng 240 triệu/năm. Khi làm Capstone, chị suýt viết lại deal theo kiểu "tôi đã thuyết phục chủ chuỗi mua gói Premium".
Mentor bắt chị xoay góc. Vấn đề nghiệp vụ thật của khách là gì? Hóa ra mỗi cuối tháng, kế toán phải gom file Excel chấm công từ 18 quản lý cửa hàng, ai gửi trễ thì lương trễ, sai sót khoảng 6-8% bảng lương mỗi tháng, dẫn đến nhân viên khiếu nại và nghỉ việc. As-Is BPMN của chị có 14 bước, ba điểm nghẽn rõ rệt: thu thập file thủ công, đối soát bằng tay, và phê duyệt qua Zalo không có dấu vết. To-Be rút còn 8 bước, dữ liệu chấm công đổ thẳng vào hệ thống, đối soát tự động, phê duyệt có log.
Bài học: Khi re-frame, con số "240 triệu" của Sales biến thành "giảm sai sót bảng lương từ 7% xuống dưới 1%" của BA. Cùng một deal, nhưng câu sau mới là ngôn ngữ tuyển dụng BA. Chị Trang dùng chính artefact này để qua vòng case study khi phỏng vấn.
Ví dụ 2 — Anh Dũng, ex-BD ngành logistics
Anh Dũng làm BD cho một startup giao vận tại Hà Nội, từng ký hợp đồng cung cấp giải pháp quản lý đơn cho một nhà phân phối FMCG. Khi làm RACI, anh mắc lỗi điển hình của dân Sales: gán chữ A (Accountable) cho... chính khách hàng ký hợp đồng, vì "anh ấy là sếp lớn".
Mentor chỉ ra: trong dự án triển khai, người ký hợp đồng (giám đốc) là stakeholder quyền lực cao nhưng thường chỉ Informed ở cấp vận hành; người thực sự Accountable cho việc nghiệp vụ chạy đúng là trưởng phòng vận hành. Anh Dũng vẽ lại Power/Interest: giám đốc (cao/thấp → keep satisfied), trưởng phòng vận hành (cao/cao → manage closely), nhân viên nhập đơn (thấp/cao → keep informed), phòng IT khách (cao/thấp). Khi mapping RACI cho hoạt động "duyệt quy trình nhập đơn mới", anh đặt R cho mình (BA) + nhân viên nghiệp vụ, A cho trưởng phòng vận hành, C cho IT, I cho giám đốc.
Bài học: "Người ký tiền" và "người chịu trách nhiệm nghiệp vụ" thường là hai người khác nhau. Sales hay nhầm hai vai này. RACI buộc bạn tách bạch — và đây chính là loại tinh tế khiến BA được tin tưởng.
Ví dụ 3 — Chị Linh, ex-Sales bảo hiểm bancassurance
Chị Linh từng bán gói bảo hiểm liên kết ngân hàng. Deal chị chọn cho Capstone là việc một chi nhánh ngân hàng muốn số hóa quy trình tư vấn bảo hiểm tại quầy. Khi vẽ As-Is, chị phát hiện điều mà hồi làm Sales chị chưa từng để ý: quy trình hiện tại có một bước "khách ký giấy xác nhận đã được tư vấn" hoàn toàn bằng giấy, và bước này tồn tại vì lý do tuân thủ (compliance) của Ngân hàng Nhà nước, không thể bỏ.
Nhờ vẽ As-Is đầy đủ, chị giữ lại bước này trong To-Be dưới dạng e-signature có lưu vết, thay vì xóa bỏ như bản năng "tinh giản cho gọn". Chị còn rút được một business rule quan trọng: "Mọi hồ sơ tư vấn phải lưu bản ghi xác nhận của khách trong tối thiểu 5 năm."
Bài học: As-Is không chỉ để chê quy trình cũ. Nó giúp bạn phát hiện những ràng buộc nghiệp vụ và pháp lý mà nếu bỏ qua khi thiết kế To-Be, cả dự án có thể vi phạm quy định. Đây là tư duy "domain expertise" mà ex-Sales có sẵn lợi thế.
Hướng dẫn từng bước
Dưới đây là quy trình 7 bước để hoàn thành Capstone 1. Hãy làm tuần tự, mỗi bước cho ra một sản phẩm cụ thể.
Bước 1 — Chọn deal và viết một đoạn bối cảnh (context). Chọn một deal/dự án bạn thực sự hiểu sâu. Viết 5-7 câu: khách là ai, ngành gì, quy mô, vấn đề nghiệp vụ họ gặp, và giải pháp đã bán. Quan trọng: viết phần "vấn đề nghiệp vụ" trước phần "giải pháp" — đây là cú đảo tư duy đầu tiên.
Bước 2 — Liệt kê stakeholder và vẽ Power/Interest. Liệt kê tối thiểu 6 bên liên quan (cả phía khách và phía bạn). Đặt từng người vào một trong bốn ô của ma trận Power/Interest, kèm một câu lý do. Đừng quên các stakeholder "ẩn" như phòng IT, phòng pháp chế, hay người dùng cuối.
Bước 3 — Lập ma trận RACI. Chọn 6-10 hoạt động/quyết định chính của dự án (ví dụ: thu thập yêu cầu, duyệt quy trình, UAT, go-live). Lập bảng với cột là các stakeholder, hàng là hoạt động. Điền R-A-C-I. Tự kiểm tra: mỗi hàng có đúng một A không? Có hàng nào toàn I (không ai làm) không?
Bước 4 — Vẽ As-Is BPMN. Dùng Lucidchart, draw.io hoặc Miro. Thể hiện đúng các swimlane (mỗi vai một lane), task, gateway và điểm nghẽn. Đánh dấu rõ 2-4 điểm pain (dùng annotation). Mục tiêu: ai nhìn vào cũng thấy "à, chỗ này đang khổ".
Bước 5 — Vẽ To-Be BPMN. Vẽ quy trình sau giải pháp, giải quyết các pain đã đánh dấu ở As-Is. Với mỗi pain, chỉ rõ trong To-Be nó được xử lý bằng cách nào. Giữ lại các bước ràng buộc compliance (như ví dụ chị Linh).
Bước 6 — Rút requirement từ khoảng cách As-Is → To-Be. Mỗi thay đổi giữa hai sơ đồ là một yêu cầu. Viết: 4-6 business requirement cấp cao, 3-5 user story theo mẫu "Là [vai], tôi muốn [hành động] để [giá trị]" kèm acceptance criteria, và 2-3 business rule.
Bước 7 — Đóng gói thành một tài liệu. Ghép cả 4 phần thành một file (PDF hoặc Confluence page): Context → Stakeholder + RACI → As-Is/To-Be → Requirements. Thêm một đoạn "executive summary" 4-5 câu ở đầu. Đây chính là artefact portfolio đầu tiên của bạn.
Lỗi thường gặp & mẹo
Lỗi 1 — Re-frame nửa vời, vẫn kể chuyện bán hàng. Triệu chứng: phần context viết về "tôi đã chốt deal thế nào" thay vì "khách gặp vấn đề gì". Mẹo: ép mình viết phần vấn đề nghiệp vụ mà tuyệt đối không nhắc đến tên sản phẩm hay giá tiền.
Lỗi 2 — Gán nhiều chữ A trên một hoạt động. Triệu chứng: vì nể nang, bạn cho hai-ba người cùng Accountable. Nguyên tắc bất di bất dịch: mỗi hoạt động đúng một A. Nếu thấy có hai, nghĩa là bạn chưa làm rõ ai quyết định cuối cùng — và đó chính là rủi ro dự án.
Lỗi 3 — As-Is vẽ quá đẹp. Triệu chứng: As-Is trông gọn gàng, không có pain. Nếu quy trình cũ hoàn hảo thì đã không cần dự án. Hãy can đảm vẽ ra sự lộn xộn thật: các bước thủ công, các vòng lặp gửi đi gửi lại, các điểm chờ.
Lỗi 4 — To-Be là "phép màu", không truy được nguồn gốc. Triệu chứng: To-Be xuất hiện các bước mới mà không nối với pain nào ở As-Is. Mẹo: lập một bảng nhỏ "Pain ở As-Is → Cách xử lý ở To-Be → Requirement tương ứng". Bảng này đảm bảo mọi thứ truy vết (traceable) được — một thói quen vàng của BA.
Lỗi 5 — Quên stakeholder ẩn. Dân Sales quen tập trung vào người ra quyết định mua. Nhưng người dùng cuối, IT, pháp chế mới là người làm dự án thành hay bại. Mẹo: với mỗi swimlane trong BPMN, hãy hỏi "vai này có nằm trong danh sách stakeholder của tôi chưa?".
Mẹo tổng quát: Đừng cầu toàn. Capstone này là bản v1, không phải tài liệu nộp cho khách hàng thật. Mục tiêu là chứng minh bạn ghép được các mảnh Module 1 thành một câu chuyện mạch lạc. Bạn sẽ tinh chỉnh nó nhiều lần trong Module 2.
Bài tập thực hành
- Chọn deal (15 phút). Viết đoạn context 5-7 câu cho một deal bạn từng làm, theo nguyên tắc "vấn đề nghiệp vụ trước, giải pháp sau".
- Stakeholder + RACI (45 phút). Liệt kê tối thiểu 6 stakeholder, đặt vào ma trận Power/Interest, rồi lập RACI cho ít nhất 6 hoạt động. Tự kiểm tra quy tắc một-A-mỗi-hàng.
- As-Is BPMN (45 phút). Vẽ quy trình hiện tại với swimlane và đánh dấu tối thiểu 3 điểm pain.
- To-Be BPMN (45 phút). Vẽ quy trình mới, mỗi pain phải được giải quyết rõ ràng.
- Bảng truy vết + requirement (40 phút). Lập bảng "Pain → To-Be → Requirement", rồi viết 4 business requirement, 3 user story có acceptance criteria, 2 business rule.
- Đóng gói (20 phút). Ghép tất cả thành một tài liệu có executive summary. Đặt tên file theo chuẩn portfolio: "Capstone1_[Tên bạn]_[Tên dự án].pdf".
- Tự chấm (10 phút). Tự cho điểm theo 5 tiêu chí, mỗi tiêu chí 2 điểm: (a) re-frame đúng góc BA, (b) RACI hợp lệ, (c) As-Is có pain thật, (d) To-Be giải quyết pain, (e) requirement truy vết được. Dưới 7/10 thì làm lại phần yếu nhất.
Tóm tắt
Bài 30 là điểm chốt của Module 1: thay vì học thêm khái niệm mới, bạn tổng hợp toàn bộ kỹ năng đã học để sản xuất một artefact hoàn chỉnh từ chính trải nghiệm Sales/BD của mình. Trọng tâm là động tác re-frame — xoay một deal từ góc bán hàng sang góc vấn đề nghiệp vụ.
Bốn deliverable cốt lõi: (1) context nêu vấn đề nghiệp vụ; (2) stakeholder analysis với ma trận Power/Interest và RACI hợp lệ (nhớ: một A mỗi hoạt động); (3) cặp As-Is/To-Be BPMN trong đó As-Is phơi bày pain thật và To-Be giải quyết từng pain; (4) gói requirement truy vết được từ khoảng cách giữa hai sơ đồ.
Ba bài học từ Trang, Dũng và Linh cho thấy: con số deal phải dịch thành chỉ số nghiệp vụ; người ký tiền khác người chịu trách nhiệm nghiệp vụ; và As-Is giúp phát hiện ràng buộc compliance không được bỏ. Hãy làm xong Capstone này một cách nghiêm túc — nó vừa khóa lại Module 1, vừa trở thành viên gạch đầu tiên cho portfolio BA mà bạn sẽ mang đi phỏng vấn.