Mở đầu — vì sao bài này quan trọng
Suốt 19 bài vừa qua của Module 1, bạn đã học rời rạc từng mảnh kỹ năng: mindset BA, mapping competencies, Excel sang SQL, BPMN, use case, business rule, ERD, RTM, UAT, estimation, change management... Mỗi mảnh đều hữu ích, nhưng có một sự thật phũ phàng: nhà tuyển dụng BA không bao giờ hỏi bạn "em biết BPMN không?". Họ hỏi "em đưa anh xem một thứ em từng làm đi". Và lúc đó, người chỉ học lý thuyết sẽ ấp úng, còn người đã ráp các mảnh thành một sản phẩm hoàn chỉnh sẽ tự tin mở laptop ra.
Capstone Module 1 chính là cây cầu giữa "biết" và "làm được". Đây là bài bạn lấy MỘT quy trình tài chính/kế toán mà bạn từng làm thật — đóng sổ tháng, duyệt thanh toán, đối chiếu công nợ, tính lương — rồi re-frame (đóng khung lại) nó dưới góc nhìn của một BA. Bạn không học thêm khái niệm mới. Bạn lắp ráp những gì đã có thành một deliverable (sản phẩm bàn giao) mà sau này có thể bỏ thẳng vào portfolio.
Điều khiến capstone này đặc biệt giá trị với người xuất thân Finance: bạn có lợi thế mà BA "tay ngang" từ ngành khác không có — bạn hiểu nghiệp vụ tài chính từ bên trong. Bạn biết tại sao bút toán phải cân, tại sao cần maker-checker, tại sao kế toán trưởng ký duyệt mà giám đốc tài chính lại ký lần hai. Đó là domain knowledge (kiến thức nghiệp vụ) mà công ty phải trả tiền cho consultant để có được. Capstone này dạy bạn cách biểu đạt kiến thức đó bằng ngôn ngữ BA, để biến thứ bạn vốn coi là hiển nhiên thành tài sản nghề nghiệp.
Hãy coi đây là bài kiểm tra cuối kỳ thực chiến: nếu hoàn thành tử tế, bạn sẽ có trong tay một bộ tài liệu chứng minh năng lực, đủ để gây ấn tượng trong buổi phỏng vấn đầu tiên.
Khái niệm cốt lõi
Capstone là gì và khác bài tập thường ở điểm nào
Bài tập thường tập trung vào một kỹ năng đơn lẻ trong môi trường được dọn sẵn. Capstone là dự án tổng hợp: bạn tự chọn đề, tự xác định phạm vi, tự ráp nhiều kỹ năng, và tự chịu trách nhiệm cho chất lượng đầu ra. Nó mô phỏng đúng cách công việc BA thật vận hành — không ai đưa bạn một đề bài hoàn hảo, bạn phải tự khoanh vùng vấn đề.
Với Module 1, capstone yêu cầu bạn sản xuất ba deliverable cốt lõi quanh một quy trình tài chính có thật:
- Stakeholder analysis + RACI — xác định ai liên quan, ai chịu trách nhiệm gì.
- As-Is + To-Be BPMN — vẽ quy trình hiện tại và quy trình mong muốn.
- Gap analysis + Requirement list — chỉ ra khoảng cách giữa hai trạng thái và liệt kê yêu cầu để lấp khoảng cách đó.
Vì sao re-frame quy trình cũ lại hiệu quả hơn nghĩ đề mới
Nhiều học viên có xu hướng muốn chọn một đề thật "kêu" như "hệ thống thanh toán cho ví điện tử". Đừng. Khi bạn chọn quy trình mình chưa từng làm, bạn sẽ bịa requirement, và người phỏng vấn dày dạn nhận ra ngay trong ba câu hỏi đào sâu. Ngược lại, khi bạn re-frame quy trình đóng sổ cuối tháng mà bạn đã làm 36 lần trong 3 năm, bạn trả lời được mọi câu "thế nếu hóa đơn về trễ thì sao?", "ai phê duyệt điều chỉnh?", "khi nào thì bút toán bị từ chối?". Sự tự tin đó không thể giả vờ.
Re-frame nghĩa là: cùng một quy trình, nhưng đổi góc nhìn. Trước đây bạn nhìn nó như người thực thi — "tôi nhập liệu, tôi đối chiếu, tôi in báo cáo". Bây giờ bạn nhìn nó như người phân tích — "quy trình này có những actor nào, dữ liệu chảy ra sao, đâu là nút thắt, rule nào đang ngầm định, có thể tự động hóa khâu nào". Cùng dữ liệu, khác lăng kính.
Tiêu chí một capstone "đậu"
Một capstone đạt chuẩn portfolio cần thỏa bốn tiêu chí: (1) Phạm vi vừa đủ hẹp — một quy trình con cụ thể, không phải "toàn bộ phòng kế toán"; (2) Có vấn đề thật để giải — chỉ ra được pain point đo đếm được, ví dụ "đóng sổ mất 7 ngày làm việc"; (3) Truy vết được — mỗi requirement nối được về một gap cụ thể; (4) Trình bày sạch — đọc 5 phút là hiểu, không cần bạn ngồi cạnh giải thích.
Tình huống thực tế
Ví dụ 1 — Lan, kế toán công nợ tại công ty phân phối FMCG, re-frame quy trình đối chiếu công nợ
Lan làm kế toán công nợ phải thu ở một nhà phân phối hàng tiêu dùng tại TP.HCM với khoảng 200 đại lý. Cuối mỗi tháng chị mất 5 ngày làm việc để đối chiếu công nợ: tải sao kê ngân hàng, đối chiếu với hóa đơn xuất, gọi điện cho đại lý xác nhận số dư, xử lý các khoản lệch.
Khi làm capstone, Lan khoanh phạm vi rất gọn: chỉ lấy quy trình "đối chiếu và xác nhận số dư công nợ cuối tháng", không ôm cả mảng thu tiền. Ở As-Is BPMN, chị phát hiện ra một sự thật chị chưa từng để ý khi còn làm: có tới 4 lần dữ liệu bị nhập lại thủ công (từ phần mềm kế toán ra Excel, từ Excel ra email, từ email phản hồi của đại lý ngược lại Excel, rồi từ Excel vào phần mềm). Mỗi lần nhập lại là một điểm rủi ro sai sót.
Ở To-Be, chị đề xuất một cổng đối chiếu tự động gửi số dư cho đại lý qua email/Zalo với link xác nhận một chạm. Gap analysis chỉ ra ba khoảng cách: thiếu kênh xác nhận tự động, thiếu cơ chế cảnh báo khoản lệch vượt ngưỡng, thiếu lưu vết lịch sử xác nhận. Từ đó ra 9 requirement.
Bài học rút ra: Sức mạnh của capstone không nằm ở việc vẽ đẹp, mà ở việc nhìn ra cái mà người trong cuộc không thấy. Lan đã làm quy trình đó hàng chục lần nhưng chỉ khi vẽ BPMN chị mới "đếm" được 4 lần nhập trùng. Trong buổi phỏng vấn sau đó, chính chi tiết "4 điểm nhập trùng" này khiến nhà tuyển dụng gật gù.
Ví dụ 2 — Huy, từng làm kế toán thanh toán tại một chuỗi F&B, re-frame quy trình duyệt chi
Huy làm kế toán thanh toán ở một chuỗi nhà hàng 30 chi nhánh. Quy trình duyệt đề nghị thanh toán của anh đi qua nhiều tầng: quản lý chi nhánh đề xuất, kế toán chi nhánh kiểm tra chứng từ, kế toán tổng kiểm tra ngân sách, kế toán trưởng duyệt, giám đốc tài chính ký với khoản trên 50 triệu.
Khi làm Stakeholder analysis, Huy liệt kê 6 nhóm liên quan và lập RACI. Anh phát hiện một vấn đề kinh điển: với khâu "kiểm tra ngân sách", có tới hai người cùng nghĩ mình là người chịu trách nhiệm cuối (kế toán tổng và kế toán trưởng), dẫn đến lúc thì cả hai cùng kiểm, lúc thì cả hai cùng nghĩ người kia đã kiểm. RACI giúp anh chỉ ra: cần đúng MỘT chữ A (Accountable) cho mỗi hoạt động.
To-Be của Huy đề xuất số hóa luồng duyệt bằng workflow có quy tắc định tuyến theo hạn mức, kèm SLA mỗi cấp 24 giờ và auto-escalate (tự động đẩy lên cấp trên) nếu quá hạn. Pain point đo được: thời gian duyệt trung bình hiện tại 4,2 ngày, mục tiêu xuống dưới 1 ngày.
Bài học rút ra: RACI không phải bài tập điền ô cho có. Nó là công cụ phát hiện xung đột trách nhiệm — thứ gây tắc nghẽn quy trình mà ít ai gọi tên được. Khi Huy trình bày "tôi tìm ra hai người cùng giữ chữ A", đó chính là tư duy BA thuần túy, và nó đến trực tiếp từ trải nghiệm Finance của anh.
Ví dụ 3 — Trang, nhân viên phần hành tổng hợp, re-frame quy trình đóng sổ cuối tháng
Trang phụ trách đóng sổ cuối tháng tại một công ty sản xuất quy mô vừa. Chị chọn đề này cho capstone nhưng suýt mắc sai lầm: ban đầu chị định vẽ toàn bộ chu trình đóng sổ — từ trích khấu hao, phân bổ chi phí trả trước, đến lập báo cáo tài chính. Mentor khuyên chị thu hẹp lại chỉ còn khâu "thu thập và hạch toán chi phí phát sinh chưa có hóa đơn (accrual)".
Khi thu hẹp phạm vi, chị làm sâu được hơn. As-Is cho thấy chị phải đi đòi thông tin từ 8 phòng ban khác nhau qua email rời rạc, không có deadline thống nhất, dẫn đến lúc nào cũng có phòng nộp trễ làm cả quy trình tắc. Business rule ngầm mà chị moi ra được: "chi phí ước tính chỉ được ghi nhận nếu có phê duyệt của trưởng bộ phận phát sinh" — một rule chưa ai viết ra giấy nhưng mọi người vẫn làm theo. Việc nắm bắt và viết rõ rule ngầm này chính là điều mà ở Bài 17 bạn đã học (business rule catalog).
Bài học rút ra: Thu hẹp phạm vi không phải là làm ít đi, mà là làm sâu hơn. Một capstone về một khâu accrual được phân tích kỹ sẽ ấn tượng hơn nhiều một capstone ôm cả chu trình đóng sổ nhưng chỗ nào cũng hời hợt. Đây là bài học về scope (phạm vi) mà mọi BA mới vào nghề đều phải học bằng cách vấp.
Hướng dẫn từng bước
Bước 1 — Chọn quy trình và khoanh phạm vi (30 phút)
Liệt kê 3–5 quy trình Finance/kế toán bạn từng làm thật. Với mỗi cái, tự hỏi: tôi có nhớ chi tiết không, nó có pain point rõ ràng không, phạm vi có vừa một quy trình con không. Chọn cái điểm cao nhất cả ba tiêu chí. Viết một câu "scope statement": "Capstone này phân tích quy trình [X], từ khi [sự kiện bắt đầu] đến khi [sự kiện kết thúc], không bao gồm [những gì nằm ngoài]." Câu này cứu bạn khỏi việc phình to mất kiểm soát.
Bước 2 — Stakeholder analysis + RACI (45 phút)
Liệt kê mọi cá nhân/nhóm chạm vào quy trình. Phân loại theo lưới Power/Interest (quyền lực/mức quan tâm) như đã học ở các bài về stakeholder. Sau đó lập bảng RACI: cột là các bước/hoạt động chính, hàng là các stakeholder, điền R (Responsible — người làm), A (Accountable — người chịu trách nhiệm cuối, mỗi hoạt động đúng một A), C (Consulted — người được hỏi ý kiến), I (Informed — người được thông báo). Soi kỹ: có hoạt động nào thiếu A không, có hoạt động nào hai A không.
Bước 3 — Vẽ As-Is BPMN (60 phút)
Dùng Lucidchart, draw.io hoặc Miro. Vẽ đúng quy trình hiện đang chạy, kể cả những khúc xấu xí, thủ công, vòng vo. Dùng swimlane (làn bơi) để mỗi lane là một actor. Đánh dấu rõ các điểm đau: nơi nhập liệu trùng, nơi chờ đợi lâu, nơi hay sai sót, nơi quyết định thủ công. Mẹo: vừa vẽ vừa ghi chú "pain point" bằng sticky note màu đỏ ngay trên sơ đồ.
Bước 4 — Vẽ To-Be BPMN (45 phút)
Vẽ quy trình mong muốn sau cải tiến. Đừng vẽ utopia viển vông — To-Be phải khả thi và giải quyết đúng pain point đã đánh dấu ở As-Is. Thường To-Be sẽ có ít bước hơn, ít lane "chờ" hơn, có thêm các khâu tự động hóa hoặc kiểm soát. Đặt hai sơ đồ cạnh nhau để người đọc thấy ngay sự khác biệt.
Bước 5 — Gap analysis + Requirement list (60 phút)
Lập bảng ba cột: As-Is (hiện trạng) | To-Be (mong muốn) | Gap (khoảng cách cần lấp). Mỗi gap đẻ ra một hoặc vài requirement. Viết requirement theo dạng có thể kiểm chứng được, đặt mã (REQ-01, REQ-02...) để truy vết. Phân loại functional (chức năng) và non-functional (phi chức năng, ví dụ "duyệt phải xong trong 24h"). Cuối cùng ưu tiên hóa bằng MoSCoW (Must/Should/Could/Won't) để thể hiện bạn biết cái gì làm trước.
Bước 6 — Đóng gói deliverable (30 phút)
Gom tất cả vào một tài liệu mạch lạc: bìa + scope statement, stakeholder & RACI, As-Is, To-Be, gap & requirement, và một trang "executive summary" nửa trang tóm tắt vấn đề–giải pháp–giá trị. Xuất PDF. Đây chính là thứ bạn mở ra trong buổi phỏng vấn.
Lỗi thường gặp & mẹo
Lỗi 1 — Phạm vi quá rộng. Triệu chứng: BPMN của bạn dài 40 bước, trải 6 lane, vẽ ba ngày chưa xong. Khắc phục: quay lại scope statement, cắt bớt cho đến khi quy trình gói gọn trong khoảng 10–15 bước. Sâu một khâu hơn rộng mười khâu.
Lỗi 2 — As-Is bị "làm đẹp". Nhiều người vô thức vẽ As-Is theo cách quy trình nên chạy thay vì thực sự chạy, vì ngại phơi bày cái xấu. Hậu quả: gap analysis trở nên rỗng vì As-Is đã quá hoàn hảo. Mẹo: As-Is phải có ít nhất 3 điểm đau, nếu không có thì bạn đang tô hồng.
Lỗi 3 — RACI có hoạt động nhiều hơn một chữ A. Đây là lỗi kinh điển và cũng là cơ hội vàng. Đừng "sửa" cho đẹp — hãy ghi chú lại như một phát hiện trong phần gap. Việc bạn chỉ ra xung đột accountability chính là điểm cộng lớn.
Lỗi 4 — Requirement viết kiểu giải pháp, không phải nhu cầu. Ví dụ sai: "Cần cài phần mềm SAP". Đúng: "Hệ thống phải tự động đối chiếu số dư công nợ và cảnh báo khoản lệch vượt 1% trong vòng 1 giờ sau khi nhập sao kê." Requirement mô tả cái gì cần đạt, không phải mua công cụ nào.
Lỗi 5 — Không nối requirement về gap. Mỗi requirement phải trả lời được câu "nó lấp gap nào?". Nếu một requirement không gắn với gap nào, hoặc bạn đang thừa, hoặc bạn bỏ sót một gap. Đánh số chéo (gap G1 → REQ-01, REQ-02) để tự kiểm tra.
Mẹo vàng: Trước khi đóng gói, đưa capstone cho một người không làm kế toán đọc trong 5 phút rồi hỏi họ "quy trình này đang đau ở đâu và mình định sửa thế nào?". Nếu họ trả lời đúng, capstone của bạn đã đạt độ trong sáng cần thiết cho portfolio.
Bài tập thực hành
Phần A — Bắt buộc. Hoàn thành trọn vẹn 6 bước ở trên cho MỘT quy trình Finance/kế toán bạn từng làm. Đầu ra là một file PDF gồm: scope statement, stakeholder analysis + RACI, As-Is BPMN, To-Be BPMN, gap analysis + requirement list (tối thiểu 8 requirement có mã, có phân loại MoSCoW), và executive summary nửa trang. Đặt tên file theo dạng Capstone_M1_[TênBạn]_[TênQuyTrình].pdf.
Phần B — Tự đánh giá. Chấm capstone của bạn theo rubric sau, mỗi mục 0–2 điểm (tổng 12): scope đủ hẹp; As-Is có ≥3 pain point thật; RACI mỗi hoạt động đúng một A (hoặc ghi chú rõ xung đột); To-Be giải đúng pain point; mỗi requirement nối được về một gap; trình bày đọc 5 phút là hiểu. Đạt từ 9/12 trở lên mới bỏ vào portfolio.
Phần C — Nâng cao (tùy chọn). Viết một đoạn "pitch" 90 giây bằng lời nói, như thể bạn đang trình bày capstone này trong buổi phỏng vấn: nêu quy trình, pain point đo được, đề xuất To-Be, và giá trị mang lại. Ghi âm lại và nghe để luyện cho buổi phỏng vấn thật (sẽ học kỹ ở Bài 44).
Tóm tắt
Capstone Module 1 là nơi bạn biến 19 bài lý thuyết thành một sản phẩm cầm được trên tay. Công thức cốt lõi: chọn một quy trình Finance/kế toán bạn từng làm thật, khoanh phạm vi thật hẹp, rồi re-frame nó qua sáu bước — scope, stakeholder + RACI, As-Is BPMN, To-Be BPMN, gap analysis + requirement, đóng gói. Lợi thế độc nhất của người xuất thân Finance là domain knowledge; capstone dạy bạn cách biểu đạt lợi thế đó bằng ngôn ngữ BA.
Ba điều cần khắc cốt: (1) Sâu hơn rộng — một khâu phân tích kỹ thắng cả chu trình hời hợt; (2) As-Is phải thật, kể cả xấu xí, vì gap nằm ở chỗ xấu xí đó; (3) Mỗi requirement phải truy vết được về một gap. Nếu hoàn thành tử tế với điểm tự đánh giá từ 9/12, bạn không chỉ qua được Module 1 — bạn đã có deliverable đầu tiên cho portfolio BA của mình, thứ sẽ theo bạn vào tận buổi phỏng vấn. Hãy làm nghiêm túc, vì đây là lần đầu bạn "diễn thử" công việc của một BA thực thụ.