⭐0
🔥0
👤 Sign In
🌙
VI
👤 Account & Sync
Đăng nhập để đồng bộ note, tiến độ học, và lịch sử hoạt động trên mọi thiết bị.
Not signed in

💰 KA6: Phân Tích Chiến Lược — Công Thức Tài Chính (Dành cho BA) ▾

💵 ROI (Return on Investment) — Lợi nhuận trên đầu tư
ROI (%) = (Net Benefit × 100) ÷ Cost of Change
  • 📖 Câu chuyện thực tế: Chuỗi bán lẻ nâng cấp quản kho từ Excel sang phần mềm chuyên dụng
    • Chi phí dự án: 1 tỷ đồng (phần mềm + cài đặt + đào tạo)
    • Lợi ích dự kiến/năm: 300 triệu (giảm mất hàng, tối ưu tồn kho, giảm nhân sự)
    • ROI = (300 × 100) ÷ 1,000 = 30%
  • 💡 Tại sao quan trọng: ROI cho biết mỗi đồng đầu tư sẽ mang về bao nhiêu đồng lợi nhuận. BA dùng nó để thuyết phục sponsor có nên làm dự án hay không.
  • 📍 Khi dùng: Khi sponsor hỏi "Dự án này có đáng không?" → Nếu ROI > 20%, thường là tốt.
⏰ Payback Period — Thời gian hoàn vốn
Payback Period (years) = Cost of Change ÷ Annual Benefit
  • 📖 Câu chuyện thực tế: Ngân hàng đầu tư vào xác thực sinh trắc học (thay password)
    • Đầu tư: 5 tỷ đồng
    • Lợi ích/năm: 1.5 tỷ (giảm gian lận, giảm chi phí reset password, tăng NPS)
    • Payback = 5 ÷ 1.5 = 3.3 năm — sau đó tiền lãi bù hết chi phí ban đầu
  • 💡 Tại sao quan trọng: Payback Period trả lời: "Bao lâu dự án sẽ bắt đầu sinh lợi?" Nếu dự án hoàn vốn sau 10 năm nhưng công ty chỉ có 5 năm sống, đó là bẫy rủi ro.
  • 📍 Khi dùng: Dự án dài hạn có rủi ro cao (startup, ngành khó dự đoán). Payback < 3 năm = an toàn.
📊 Net Benefit — Lợi ích ròng
Net Benefit = Total Benefits − Total Cost of Ownership (TCO)
  • 📖 Câu chuyện thực tế: E-commerce company xây nền tảng AI gợi ý sản phẩm
    • Lợi ích tính 5 năm: 50 tỷ (tăng doanh thu, giảm return rate)
    • TCO: 30 tỷ (dev, infra, maintenance, training)
    • Net Benefit = 50 − 30 = 20 tỷ — lợi ích thực tế công ty sẽ thu được
  • 💡 Tại sao quan trọng: BA cần biết con số cuối cùng — sau khi trừ ALL chi phí (không chỉ build mà cả vận hành), lợi nhuận thực là bao nhiêu. Đó là lý do để chọn dự án này hay dự án khác.
  • 📍 Khi dùng: So sánh giữa multiple design options. "Option A net = 20 tỷ, Option B net = 15 tỷ" → Rõ ràng chọn A.
💲 Gross vs Net Profit; Gross vs Net Margin
Gross Profit = Revenue − COGS (Cost of Goods Sold)
Net Profit = Gross Profit − Operating Expenses (salary, rent, utilities)
Gross Margin % = (Gross Profit ÷ Revenue) × 100
Net Margin % = (Net Profit ÷ Revenue) × 100
  • 📖 Câu chuyện thực tế: Nhà sản xuất đồ chơi, doanh thu 1 tỷ
    • Chi phí nguyên liệu/sản xuất: 400 tỷ → Gross Profit = 600 tỷ (Gross Margin = 60%)
    • Chi vận hành (lương, thuê xưởng, quảng cáo...): 400 tỷ → Net Profit = 200 tỷ (Net Margin = 20%)
    • BA thấy: gross margin cao nhưng net margin chỉ 20% vì overhead quá lớn → cơ hội tối ưu quy trình
  • 💡 Tại sao quan trọng: Gross Profit là tiêu chí "sản xuất hiệu quả" (giá bán vs chi phí raw material). Net Profit là "kinh doanh hiệu quả" (sau tất cả chi phí). BA cần cả hai để hiểu business health toàn cảnh.
  • 📍 Khi dùng: Phân tích hiệu suất kinh doanh. Nếu gross margin tốt nhưng net margin kém, vấn đề nằm ở overhead, không phải sản xuất.
🔧 TCO — Total Cost of Ownership (Toàn bộ chi phí sở hữu)
TCO = Initial Cost + (Annual Operating Cost × Years) + Training + Support + Decommissioning
  • 📖 Câu chuyện thực tế: So sánh Build vs Buy CRM
    • Build: Dev 5 tỷ + 3 dev duy trì 5 năm (1 tỷ/năm × 5) + 2 architect full-time (500tr/năm × 5) = ~14 tỷ
    • Buy Salesforce: License 200tr/năm × 5 = 1 tỷ + setup/training 500tr = 1.5 tỷ
    • TCO Build = 14 tỷ, TCO Buy = 1.5 tỷ → buy rẻ hơn rõ rệt, nhưng BA cần liệt kê ALL costs (cả lương staff), không chỉ giá license
  • 💡 Tại sao quan trọng: Sponsor hay quên chi phí runtime (licensing, bảo trì, support). TCO ép BA (và sponsor) nhìn thấy full picture. Quyết định Build vs Buy sai lệch có thể cost company hàng tỷ đồng.
  • 📍 Khi dùng: Whenever comparing options (especially Buy vs Build). TCO bắt buộc ở Design Options (KA7.5).

📊 KA7: Kỹ Thuật Ước Tính (Làm sao đoán thời gian dự án?) ▾

📈 PERT — Program Evaluation Review Technique (3-point estimation)
PERT = (Optimistic + 4×Most Likely + Pessimistic) ÷ 6
  • 📖 Câu chuyện thực tế: PM hỏi dev team: "Mất bao lâu để build payment gateway?" — Dev trả lời mơ hồ, BA bắt buộc phải hỏi 3 scenarios
    • Best case (không issue): 5 ngày
    • Most likely (vài issue nhỏ): 8 ngày
    • Worst case (integration nightmare): 15 ngày
    • PERT = (5 + 4×8 + 15) ÷ 6 = 9.17 ngày → BA dùng 9-10 ngày làm estimate, không dùng "hopefully 5"
  • 💡 Tại sao quan trọng: Con người hay quá lạc quan khi ước lượng. PERT buộc phải xem xét worst case. Most Likely weighted 4x vì nó thường đúng nhất.
  • 📍 Khi dùng: Dự án có nhiều uncertainty. Data không rõ ràng. Không có data lịch sử.
🔢 Parametric Estimation — Dựa trên unit cố định
Estimate = Unit Cost/Time × Quantity
  • 📖 Câu chuyện thực tế: Website company nhận request: "Build 20 landing pages tương tự nhau"
    • Data lịch sử: mỗi landing page = 3 ngày
    • Parametric estimate = 3 × 20 = 60 ngày — không cần hỏi lại từng trang vì mẫu mã tương tự
  • 💡 Tại sao quan trọng: Khi công việc lặp lại, parametric rất nhanh và chính xác. Không cần lãng phí thời gian ước cho từng task nhỏ.
  • 📍 Khi dùng: Công việc repetitive có data lịch sử. Ví dụ: 100 api endpoints, mỗi cái tương tự nhau.
⬇️ Top-Down vs ⬆️ Bottom-Up — 2 cách khác nhau
Top-Down: Total Budget ÷ Number of Tasks
Bottom-Up: Σ(Individual Task Estimates)
  • 📖 Câu chuyện thực tế: CEO duyệt budget: "Tôi có 6 tháng, toàn team 10 người"
    • Top-Down: 6 tháng ÷ 10 features = 3 tuần/feature
    • Bottom-Up: BA yêu cầu team ước từng feature — authentication 2 tuần, payment 3 tuần, reporting 2 tuần... → Total = 8 tuần ≈ 2 tháng
  • 💡 Tại sao quan trọng: Top-Down nhanh nhưng hay ngây thơ (chia đều không hiểu từng task khó cỡ nào). Bottom-Up chính xác hơn nhưng chậm. BA dùng cả hai để so sánh: nếu chênh lệch lớn, có vấn đề gì?
  • 📍 Khi dùng: Top-Down khi budget/deadline fixed, cần nhanh. Bottom-Up khi có thời gian và cần chính xác.
🎯 Delphi Technique — Hỏi experts ẩn danh để tránh politics
Round 1: Collect anonymous estimates → Round 2: Share results + discuss → Round 3: Re-estimate → Consensus
  • 📖 Câu chuyện thực tế: Database team 5 experts. Hỏi công khai, senior (A) nói "2 tuần" nhưng junior (B) sợ phản đối nên yên lặng → boss chọn 2 tuần, thực tế cần 4. Đổi sang Delphi:
    • Round 1 (ẩn danh): A: 2w, B: 4w, C: 3w, D: 4w, E: 3.5w
    • Round 2 (share kết quả): mọi người thấy 4/5 người nói gần 4 tuần — A tự nhận "quên compatibility issue"
    • Round 3 (re-estimate): consensus 3.5-4 tuần, không bị politics chi phối
  • 💡 Tại sao quan trọng: Con người có bias. Authority bias (senior nói gì theo đó). Delphi che dấu danh tính, ép phải suy nghĩ độc lập.
  • 📍 Khi dùng: Team lớn, có hierarchy rõ. Hoặc khi ước lần đầu có nhiều divergence.
🌊 Rolling Wave — Ước chi tiết gần, ước chung xa
Near-term (next sprint): Detail estimate | Far-term (6 months out): Rough range
  • 📖 Câu chuyện thực tế: Startup e-commerce dùng Agile, không ai chốt được roadmap 12 tháng (quá nhiều unknowns) → dùng Rolling Wave
    • Sprint tới: ước chi tiết 100% (mọi story rõ ràng)
    • Sprint +1: rough estimate ("3-5 sprints")
    • Sprint +2: even rougher ("maybe 5-8 sprints")
    • Khi lên tới Sprint 1, ước lại chi tiết — cứ thế cuốn chiếu, không bao giờ kém xác
  • 💡 Tại sao quan trọng: Dự án Agile có unknowns quá lớn. Rolling Wave chấp nhận "tôi không biết trước" nhưng cam kết "tôi sẽ ước chi tiết sát thời gian hạn định trước."
  • 📍 Khi dùng: Agile projects, unknowns cao, roadmap linh hoạt. Thay vì ước 12 tháng hôm nay, ước 2 tuần hôm nay + hôm sau ước lại.

🎯 KA7.5-7.6: Kỹ Thuật Ra Quyết Định (Làm sao chọn đúng?) ▾

📊 Decision Matrix (Weighted vs Unweighted)
Simple: Yes/No or 1-5 per criteria | Weighted: Σ(Weight% × Score)
  • 📖 Câu chuyện thực tế: Chọn Cloud provider giữa AWS / Azure / GCP
    • Tiêu chí & trọng số: Cost (30%), Availability (40%), Support (20%), Learning Curve (10%)
    • Điểm 1-5 mỗi tiêu chí → nhân trọng số → cộng lại:
    OptionCostAvail.SupportLearnWeighted score
    AWS45424.1
    Azure34533.9
    GCP53343.6
    • AWS thắng. Nếu không weight (chỉ cộng trực tiếp), cả 3 đều ~4 điểm — weight mới là công cụ phản ánh "cái nào thực sự quan trọng"
  • 💡 Tại sao quan trọng: Weighted matrix ép BA & stakeholders phải nói rõ: "Cái nào quan trọng nhất?" Không weighted thì chỉ là averaging vô nghĩa.
  • 📍 Khi dùng: Khi có 3+ options, cần transparent scoring. Vendor selection, Design option selection.
🌳 Decision Tree — Khoảng 50/50 (có risk)
Expected Value = Σ(Outcome Value × Probability)
  • 📖 Câu chuyện thực tế: SaaS company quyết định "Launch feature A hay feature B?"
    • Feature A: 70% chance thích (value 100 tỷ), 30% chance flop (value 0) → EV = 0.7×100 + 0.3×0 = 70 tỷ
    • Feature B: 50% chance thành công (value 80 tỷ), 50% chance thất bại (value -10 tỷ) → EV = 0.5×80 + 0.5×(-10) = 35 tỷ
    • Feature A có EV cao hơn → chọn A
  • 💡 Tại sao quan trọng: Khi có uncertainty + multiple outcomes, decision tree buộc phải gán xác suất + giá trị. Không chỉ "hy vọng tốt."
  • 📍 Khi dùng: Quyết định có risk (thất bại = mất tiền). Launch vs skip, build vs buy, etc.
⚖️ Balanced Scorecard — 4 góc nhìn không chỉ profit
Financial | Customer | Internal Process | Learning & Growth
  • 📖 Câu chuyện thực tế: Logistics company ước lượng dự án "đơn giản hóa quy trình giao hàng." Chỉ nhìn Financial: cắt 20% cost, great! Nhưng Balanced Scorecard cho thấy:
    • Financial: Save 20% cost ✓
    • Customer: Delivery time từ 24h → 48h ✗
    • Internal: Staff phải retrain → lost productivity ✗
    • Learning: Không có upskilling opportunity ✗
    • Rõ ràng dự án chỉ tốt financial, nhưng xấu 3 góc khác → BA có thể đề xuất cải thiện hoặc skip dự án
  • 💡 Tại sao quan trọng: Công ty không chỉ sống bằng profit. Nếu customer flow, nội bộ tan rã, staff chán nản, dù tiết kiệm 20% cũng vô ích. Balanced Scorecard bắt buộc nhìn full picture.
  • 📍 Khi dùng: Strategic initiatives, transformation projects. Không chỉ cost-cutting.
📉 Variance Analysis & Range of Motion — Đo sai lệch thực tế vs kỳ vọng
Variance = ((Actual − Planned) ÷ Planned) × 100
Range of Motion = Pessimistic − Optimistic
  • 📖 Câu chuyện thực tế: Project plan: conversion rate từ 2% → 3% sau release feature. Actual result: 2.4%
    • Variance = ((2.4 − 3) ÷ 3) × 100 = -20% — project miss target 20%, BA hỏi: "Tại sao miss?"
    • Range of Motion: optimistic 4%, pessimistic 1.5% → Range = 4 − 1.5 = 2.5% — có kỳ vọng quá lạc quan không?
  • 💡 Tại sao quan trọng: BA không chỉ xem dữ liệu mà hỏi "tại sao?" Variance + Range Of Motion giúp identify root cause.
  • 📍 Khi dùng: Post-launch analysis (KA8), retrospectives, learning lessons.

🧩 Thuật Ngữ BABOK Dễ Nhầm Lẫn Nhất ▾

BABOK v3 dùng những thuật ngữ rộng và tổng quát hơn V2, nên nhiều cặp từ trông giống nhau nhưng lại mang ý nghĩa khác biệt rõ rệt — và đề CBAP/CCBA rất thích khai thác đúng những cặp này. Dưới đây là 5 cặp dễ gây nhầm lẫn nhất, cùng mẹo phân biệt nhanh.
Cặp thuật ngữPhân biệtMẹo nhớ
Verify vs Validate
  • Verify: viết đúng chuẩn chất lượng (9 tiêu chí: Complete, Consistent, Feasible...)
  • Validate: đúng cái cần, đủ đạt future state, được stakeholder đồng thuận
 VerIfy = built rIght
ValIdate = built the right thIng
Requirements Traceability vs Requirements Structure
  • Traceability: nối requirement ↔ requirement/design/build/test
  • Structure: xếp tầng trừu tượng (Business → Stakeholder → Solution → Transition)
 Traceability = nối ngang
Structure = xếp tầng
Trace vs Track Requirements
  • Trace: thiết lập liên kết giữa các requirement/artifact
  • Track: theo dõi trạng thái 1 requirement — đề xuất → duyệt → implement → retire
 Trace = "nối dây"
Track = "theo dõi trạng thái"
BA Plan vs Requirements Mgmt Plan
  • RMP: cách elicit/review/approve requirements — hẹp
  • BA Plan: mốc thời gian, stakeholder engagement, giao tiếp — rộng, chứa cả RMP
 RMP chỉ lo requirements
BA Plan lo cả initiative
Viewpoints vs Views
  • Viewpoint: góc nhìn/vị trí quan sát (business owner, dev team...)
  • View: nội dung requirement thấy được từ góc đó — 1 viewpoint chứa nhiều view
 Viewpoint = "đứng ở đâu"
View = "thấy gì" từ đó
📚 Tổng hợp và diễn giải lại từ bài viết "BABoK Terms That Confuse Us The Most" của LN Mishra, Adaptive US.

🕸️ Kỹ Thuật Xuyên Suốt Vòng Đời BA — Liên Kết Với 6 KA & BACCM ▾

50 kỹ thuật trong BABOK v3 không thuộc về "một" KA duy nhất — quan hệ giữa task và technique là many-to-many: 1 task có thể dùng nhiều kỹ thuật, và cùng 1 kỹ thuật khi đặt trong KA khác nhau lại "vận hành" theo mục đích khác nhau. Bảng dưới đây gán mỗi kỹ thuật vào KA mà nó đóng góp nhiều nhất, kèm mô tả ngắn để dễ nhớ mục đích logic của từng kỹ thuật.
⭐ Trọng tâm ôn thi CBAP: theo khảo sát học viên của Adaptive US, 3 nhóm kỹ thuật khiến CBAP candidates chật vật nhất là Financial Analysis, Decision Analysis, và UML-style modelling (sequence/state/data diagrams) — nên dành thêm thời gian cho 3 nhóm này thay vì dàn đều 50 kỹ thuật.
🗺️ Bản đồ kỹ thuật theo dòng chảy 6 KA
KA (thứ tự dòng chảy)Cụm kỹ thuật chính — mô tả ngắn
KA3 — Planning
  • Functional decomposition — chia nhỏ scope lớn thành phần dễ quản lý
  • Estimation — dự đoán khoảng chi phí/effort tổng thể
  • Interface analysis — vẽ ra các điểm kết nối giữa thành phần (6 loại: user, data, API, hardware, business process, external partner)
  • Organizational modelling — thể hiện vai trò & báo cáo trong tổ chức
  • Stakeholder list/map/personas — xác định & hồ sơ hóa stakeholder (dùng chung với RACI: Responsible/Accountable/Consulted/Informed)
  • Scope modelling — vẽ ranh giới phạm vi phân tích/giải pháp
KA4 — Elicitation
  • Group-based: Brainstorming (tạo ý tưởng tự do), Workshops (họp tập trung nhiều SME — 5 vai trò: Sponsor/Facilitator/Scribe/Timekeeper/Participants), Focus groups (thu ý kiến nhóm có điều phối), Collaborative games (hoạt động trực quan — VD: Product Box, Affinity Map, Fishbowl)
  • Individual-based: Interviews (hỏi-đáp 1-1), Observation (quan sát công việc thực tế), Survey/Questionnaire (câu hỏi viết trên diện rộng)
  • Research: Document analysis (khai thác tài liệu có sẵn), Benchmarking & market analysis (so sánh với đối thủ/ngành)
  • Experiment: Prototyping (mô hình sớm để lấy phản hồi)
KA5 — Requirements Life Cycle Mgmt
  • Glossary — định nghĩa thuật ngữ dùng chung
  • Mind mapping — cấu trúc ý tưởng dạng cây
  • Backlog management — theo dõi & sắp xếp việc còn lại
  • Business rules analysis — định nghĩa quy tắc kinh doanh có thể test
  • Lessons learned — ghi nhận thành công/thất bại để rút kinh nghiệm
  • Prioritization — xếp hạng theo tầm quan trọng tương đối
  • Reviews — xác minh/xác nhận nội dung work product
  • Item tracking — ghi log issue, risk, defect
KA6 — Strategy Analysis
  • Balanced scorecard — đo hiệu suất ngoài yếu tố tài chính
  • Business capability analysis — bản đồ những gì tổ chức CÓ THỂ làm
  • Business cases — biện minh đầu tư dựa trên giá trị vs chi phí
  • Business model canvas — 9 khối mô tả cách tạo giá trị
  • Decision analysis — mô hình hóa quyết định phức tạp/bất định
  • Decision modelling — thể hiện cách ra quyết định lặp lại
  • Financial analysis — đánh giá lợi ích/chi phí của đầu tư (còn có: Cost of change, Opportunity cost, Sunk cost, Discount rate, Free cash flow — xem bảng thuật ngữ bên dưới)
  • Risk analysis and management — nhận diện & xử lý sự bất định (5 cách phản ứng: Avoid, Transfer, Mitigate, Accept, Increase)
  • SWOT analysis — điểm mạnh/yếu/cơ hội/thách thức
KA7 — Requirements Analysis & Design Definition
  • Types: Concept modelling (tổ chức từ vựng kinh doanh), Data dictionary (định nghĩa chuẩn cho data element)
  • Viewpoint User: User stories (nhu cầu ngắn gọn), Use cases & scenarios (actor tương tác với giải pháp), NFR analysis (yêu cầu chất lượng/hiệu năng — Availability, Performance, Security, Usability, Scalability, Reliability...), Roles & permissions matrix (ma trận quyền truy cập)
  • Viewpoint Process: Process modelling (luồng hoạt động tuần tự), Sequence diagrams (luồng message giữa object), State modelling (trạng thái & chuyển trạng thái)
  • Viewpoint Data: Data modelling (entity & mối quan hệ), Data flow diagrams (dòng chảy dữ liệu qua hệ thống)
KA8 — Solution Evaluation
  • Acceptance and evaluation criteria — ngưỡng pass/fail hoặc xếp hạng
  • Metrics and KPIs — đo hiệu suất thực tế so với mục tiêu (chỉ số tốt cần: Clear, Relevant, Economical, Adequate, Quantifiable, Trustworthy)
  • Process analysis — tìm cơ hội cải tiến quy trình
  • Root cause analysis — tìm nguyên nhân gốc của vấn đề
  • Vendor assessment — đánh giá năng lực & độ tin cậy vendor
  • Data mining — tìm pattern trong dữ liệu lớn
💰 Financial Analysis — 5 thuật ngữ hay bị bỏ sót
  • Cost of change — chi phí phát sinh riêng cho việc thực hiện thay đổi (không tính chi phí vận hành sau này)
  • Opportunity cost — giá trị của lựa chọn tốt nhất bị bỏ lỡ khi chọn phương án này thay vì phương án khác
  • Sunk cost — chi phí đã bỏ ra rồi, không thu hồi được — không nên đưa vào khi quyết định tiếp tục hay dừng dự án
  • Discount rate — tỷ lệ dùng để quy đổi giá trị tiền tương lai về giá trị hiện tại (vì 1 đồng hôm nay đáng giá hơn 1 đồng năm sau)
  • Free cash flow — dòng tiền còn lại sau khi trừ chi phí vận hành & đầu tư — cho biết công ty còn bao nhiêu tiền mặt thực sự tự do sử dụng
🔀 Cùng 1 Kỹ Thuật — Vận Hành Khác Nhau Theo KA
Đây là điểm hay bị bỏ sót: một kỹ thuật không "cố định" 1 mục đích — logic thay đổi theo câu hỏi mà KA đó đang cần trả lời.
Kỹ thuậtVai trò thay đổi theo từng KA
Estimation (PERT/Parametric/...)
  • KA3 Planning: ước tổng thể cho cả initiative (rough order of magnitude)
  • KA7 RADD: ước chi tiết từng requirement/design option
  • KA8 Solution Eval: ước effort để fix 1 limitation cụ thể
Financial Analysis
  • KA3 Planning: input để duyệt budget ban đầu
  • KA6 Strategy: biện minh đầu tư chiến lược (ROI, Payback, NPV)
  • KA7 RADD: so sánh chi phí giữa các design option (TCO)
  • KA8 Solution Eval: đánh giá giá trị thực tế đạt được so với chi phí
Risk Analysis and Management
  • KA3 Planning: risk register cho công việc BA
  • KA6 Strategy: rủi ro của change strategy được chọn
  • KA7 RADD: rủi ro ảnh hưởng đến quyết định thiết kế
  • KA8 Solution Eval: rủi ro solution không đạt giá trị kỳ vọng
Decision Analysis
  • KA6 Strategy: chọn change strategy nào (Big Bang/Phased/Pilot)
  • KA7 RADD: chọn design option nào (Build/Buy/Hybrid)
  • KA8 Solution Eval: chọn hành động nào (Retire/Enhance/Replace)
Metrics and KPIs
  • KA3 Planning: đo hiệu suất công việc BA (BA performance)
  • KA6 Strategy: định nghĩa chỉ số thành công cho future state
  • KA8 Solution Eval: đo hiệu suất thực tế của solution đã deploy
Document Analysis
  • KA4 Elicitation: khai thác thông tin từ tài liệu có sẵn
  • KA6 Strategy: hiểu current state để tìm gap
  • KA7 RADD: đối chiếu requirement với tài liệu gốc khi verify
📐 Xét theo chức năng: Estimation vs Measurement vs Evaluation
  • Ước tính (Estimation) — trả lời "sẽ mất bao lâu / bao nhiêu chi phí?"
    • Estimation (KA3) — ước lượng tổng thể ban đầu cho cả initiative
    • PERT — trung bình 3 kịch bản: optimistic + 4×likely + pessimistic
    • Parametric — đơn giá × số lượng, dùng khi việc lặp lại
    • Top-Down/Bottom-Up — chia đều budget vs cộng từng task nhỏ
    • Delphi — hỏi ẩn danh nhiều vòng để tránh authority bias
    • Rolling Wave — ước chi tiết gần, ước chung xa (đã học ở nhóm KA7 phía trên)
  • Đo lường (Measurement) — trả lời "đang đạt được bao nhiêu?"
    • Metrics and KPIs — chỉ số đo tiến độ so với mục tiêu
    • Balanced Scorecard — đo 4 góc nhìn, không chỉ tài chính
    • Solution Performance Measures (KA8) — đo hiệu suất solution sau khi deploy
  • Đánh giá (Evaluation) — trả lời "phương án nào tốt nhất / có nên làm không?"
    • Decision Analysis — mô hình hóa quyết định có nhiều phương án
    • Decision Modelling — thể hiện logic của quyết định lặp lại
    • Acceptance and Evaluation Criteria — ngưỡng pass/fail hoặc xếp hạng
    • Financial Analysis — so sánh lợi ích và chi phí bằng tiền
    • Vendor Assessment — đánh giá năng lực & độ tin cậy nhà cung cấp
    • Risk Analysis and Management — nhận diện & xử lý sự bất định
🎯 Liên kết với 6 khái niệm cốt lõi BACCM
Giống như KA, một kỹ thuật cũng có thể phục vụ nhiều khái niệm BACCM cùng lúc — ví dụ Financial Analysis vừa đo Value vừa hỗ trợ quyết định Change. Bảng dưới chỉ nêu khái niệm nó phục vụ rõ nhất.
BACCMKỹ thuật tiêu biểu — mô tả ngắn
Change
  • Business Cases — biện minh nên thay đổi hay không
  • Decision Analysis — chọn hướng thay đổi nào
  • Risk Analysis and Management — rủi ro của việc thay đổi
Need
  • Root Cause Analysis — tìm nguyên nhân gốc của nhu cầu
  • SWOT Analysis — điểm mạnh/yếu để lộ ra nhu cầu
  • Business Capability Analysis — gap giữa cái có và cái cần
Solution
  • Prototyping — hình dung sớm giải pháp
  • Process Modelling — mô tả cách giải pháp vận hành
  • Data Modelling — cấu trúc dữ liệu của giải pháp
Stakeholder
  • Stakeholder List/Map/Personas — xác định ai liên quan
  • Interviews — hiểu nhu cầu từng stakeholder
  • Workshops — đồng bộ nhiều stakeholder cùng lúc
Value
  • Financial Analysis — đo giá trị bằng tiền
  • Metrics and KPIs — đo giá trị bằng chỉ số hiệu suất
  • Balanced Scorecard — đo giá trị đa chiều, không chỉ tài chính
Context
  • Benchmarking and Market Analysis — so sánh với bối cảnh ngoài
  • Organizational Modelling — bối cảnh cấu trúc nội bộ
  • Document Analysis — bối cảnh từ tài liệu hiện có
📚 Tổng hợp và diễn giải lại từ "50 BABOK® Techniques Mind Map & Summary Guidebook" và "Important Techniques for CBAP Certification Examination", Adaptive US. Ghi nhớ: quan hệ task ↔ technique là many-to-many; bảng trên chỉ thể hiện nơi mỗi kỹ thuật đóng góp mạnh nhất.
UML-style modelling là 1 trong 3 nhóm khiến CBAP candidates chật vật nhất (xem phần Techniques trong Formulas). Mỗi loại sơ đồ dưới đây có: (1) bảng ký hiệu kèm hình minh hoạ để hiểu ý nghĩa từng ký hiệu, (2) nút 🤖 Hỏi AI đặt sẵn câu hỏi hay gây nhầm lẫn nhất, (3) nút 🖌️ Thử vẽ mở editor draw.io thật để luyện tay ngay. Đọc → Hỏi AI khi chưa rõ → Vẽ thử — 3 bước để nhớ lâu hơn là chỉ đọc suông.
ℹ️ Các link "Nguồn tham khảo" trỏ tới tài liệu hướng dẫn thực hành của draw.io — hữu ích để xem ví dụ trực quan, nhưng đây không phải văn bản chuẩn hóa chính thức (BPMN/UML do OMG quản lý; Flowchart có liên quan ISO 5807). Phần "Sai lầm thường gặp" là các quy ước phổ biến trong ngành, không phải quy tắc tuyệt đối — có thể khác nhau tùy công cụ, team, hoặc ngữ cảnh dự án. Khi cần độ chính xác cao (thi chứng chỉ, tài liệu chính thức), nên đối chiếu thêm với BABOK Guide hoặc tài liệu chuẩn tương ứng.

🔀 BPMN (Business Process Model and Notation) ▾

Mục đích: chuẩn quốc tế (OMG) để mô tả quy trình nghiệp vụ chi tiết — nhiều team/hệ thống cùng đọc hiểu như nhau, đủ chặt chẽ để làm nền cho tự động hoá. Khi dùng: quy trình phức tạp, nhiều actor/hệ thống, cần thể hiện rẽ nhánh song song hoặc điều kiện rõ ràng.
📖 Theo BABOK v3 §10.35: BPMN là 1 trong nhiều notation mà §10.35 liệt kê cho kỹ thuật Process Modelling (cùng nhóm với Flowchart, Data Flow Diagram, IDEF/IGOE, SIPOC). Điểm đặc trưng BABOK nêu rõ: BPMN phân biệt được hoạt động của từng bên tham gia bằng Pool (1 thực thể độc lập như 1 tổ chức/hệ thống) và Swimlane (1 vai trò bên trong Pool đó) — khi luồng công việc vượt ranh giới 1 swimlane, trách nhiệm chuyển sang vai trò khác.
Start Event
Vòng tròn mảnh — nơi quy trình bắt đầu
End Event
Vòng tròn viền đậm — kết quả cuối của quy trình
Intermediate Event
Vòng tròn đôi — chuyện xảy ra giữa chừng (chờ tin nhắn, hẹn giờ...)
Task
Hình chữ nhật bo góc — 1 bước công việc cụ thể
Exclusive Gateway (XOR)
Hình thoi + X — chỉ đi 1 trong các nhánh (either/or)
Parallel Gateway (AND)
Hình thoi + dấu cộng — tất cả nhánh chạy song song
Inclusive Gateway (OR)
Hình thoi + vòng tròn — chạy 1 hoặc nhiều nhánh tuỳ điều kiện
Sequence Flow
Mũi tên liền nét — thứ tự thực hiện, chỉ nối trong cùng 1 Pool
Message Flow
Mũi tên đứt nét — giao tiếp giữa 2 Pool khác nhau
Pool / Lane
Khung lớn (Pool = 1 tổ chức/hệ thống), chia Lane = vai trò/phòng ban
🧭Ví dụ hoàn chỉnh: "Xử lý đơn hàng"
Start Receive Order In stock? Yes Ship Order End No Notify Backorder End
⚠️Sai lầm thường gặp
  • Nối Sequence Flow băng qua 2 Pool khác nhau — theo quy ước phổ biến, Sequence Flow chỉ nên nối trong cùng 1 Pool; giao tiếp giữa 2 Pool thường dùng Message Flow (đường đứt nét) thay thế
  • Không ghi nhãn nhánh Gateway (thiếu "Yes"/"No" trên các nhánh rẽ) khiến người đọc không biết điều kiện nào dẫn tới nhánh nào
  • Dùng sai loại Gateway: chọn Parallel (+) khi thực ra chỉ cần Exclusive (X) — kiểm tra kỹ chỉ 1 nhánh chạy hay TẤT CẢ nhánh chạy song song
  • Task viết quá mơ hồ (VD: "Xử lý") thay vì hành động cụ thể (VD: "Kiểm tra tồn kho") — Task nên là 1 đơn vị công việc rõ ràng
🔗 Đọc thêm về lỗi này: BPM Tips — Pools & Lanes trong thực tế (có hình minh hoạ lỗi thật) · Good e-Learning — lỗi swimlane thường gặp
🎥 Học vẽ: Camunda Academy — playlist BPMN chính thức (miễn phí)
📚 Nguồn tham khảo: BPMN 2.0 diagrams — draw.io Docs
💡 Mẹo: trong editor vẽ, tìm ô tìm kiếm shape bên trái, gõ "BPMN" hoặc "UML" để mở đúng bộ ký hiệu chuẩn thay vì tự vẽ hình cơ bản. Ký hiệu ở trên là ký hiệu chuẩn quốc tế (OMG), không thuộc về riêng công cụ nào.

📄 Các Loại Tài Liệu BA Thường Dùng ▾

BA không chỉ viết "requirements" chung chung — mỗi loại tài liệu có mục đích, đối tượng đọc, và mức độ chi tiết khác nhau. Hiểu rõ sự khác biệt giúp bạn chọn đúng công cụ cho đúng tình huống, và tránh nhầm lẫn khi đi phỏng vấn hoặc đi thi.
Tài liệuMục đích & đối tượng đọcMức độ chi tiết
Business Case
  • Thuyết phục ban lãnh đạo/sponsor tại sao nên đầu tư
  • Nêu vấn đề, các phương án, chi phí-lợi ích, khuyến nghị
Cấp cao nhất — không đi vào chi tiết kỹ thuật
BRD (Business Requirements Document)
  • Ghi lại nhu cầu kinh doanh — mục tiêu, phạm vi, lý do cần thay đổi
  • Đọc bởi sponsor, quản lý cấp cao
Cấp business — trả lời "tại sao" và "cái gì" ở tầm vĩ mô
FRD (Functional Requirements Document)
  • Mô tả hệ thống phải làm gì cụ thể — chức năng, luồng xử lý
  • Đọc bởi BA, QA, đôi khi cả dev
Cấp chức năng — chi tiết hơn BRD, chưa đi sâu kỹ thuật triển khai
SRS (Software/System Requirements Specification)
  • Đặc tả kỹ thuật hệ thống — giao diện, dữ liệu, ràng buộc, hiệu năng
  • Đọc chủ yếu bởi dev, kiến trúc sư
Cấp kỹ thuật — chi tiết nhất trong 3 loại BRD/FRD/SRS
Use Case Document
  • Mô tả kịch bản tương tác cụ thể giữa Actor và hệ thống
  • Gồm main flow + alternate/exception flow
Trung bình — theo từng bước tương tác, có điều kiện rẽ nhánh
User Story
  • Format ngắn gọn kiểu Agile: "Là [vai trò], tôi muốn [chức năng], để [lợi ích]"
  • Kèm Acceptance Criteria
Nhẹ, linh hoạt — chi tiết dần qua trao đổi trực tiếp (backlog refinement), không cần đặc tả đầy đủ trước
RTM (Requirements Traceability Matrix)
  • Không phải là 1 loại requirement — là bảng liên kết
  • Nối requirement ↔ design ↔ test case ↔ business goal để kiểm soát coverage
Ma trận tham chiếu chéo, không tự nó mô tả nội dung requirement
UAT Script / Test Case
  • Kịch bản kiểm thử để stakeholder/end-user xác nhận
  • Hệ thống đáp ứng đúng nhu cầu trước khi go-live
Rất cụ thể — bước thực hiện, dữ liệu đầu vào, kết quả mong đợi

📎 Mẫu tham khảo ▾

📎 Mẫu tham khảo — format chuẩn cho từng loại tài liệu
Các mẫu dưới đây từ nguồn uy tín, giúp bạn hình dung cấu trúc thật — nhưng luôn điều chỉnh theo quy mô và văn hoá tổ chức của bạn, không nên áp dụng máy móc.
💼 Business Case: Smartsheet — bộ mẫu Business Case
📋 BRD: Smartsheet — mẫu BRD
⚙️ FRD: Smartsheet — mẫu Functional Specification
🖥️ SRS: SRS-Template (GitHub, chuẩn IEEE 830/ISO 29148)
🎭 Use Case: Wikipedia — cấu trúc "fully dressed use case" của Alistair Cockburn
📝 User Story: Visual Paradigm — format & tiêu chí INVEST
🔗 RTM: ProjectManager — hướng dẫn & ví dụ RTM trực quan
✅ UAT: BrowserStack — hướng dẫn & mẫu UAT test case

🗺️ Tài liệu theo Knowledge Area ▾

🗺️ Tài liệu nào xuất hiện ở Knowledge Area nào?
Tài liệu không "thuộc về" 1 KA duy nhất — nhiều loại được tạo ở 1 KA rồi tiếp tục dùng/cập nhật xuyên suốt các KA sau. Bảng dưới đây chỉ nơi mỗi loại tài liệu thường được tạo ra lần đầu.
Knowledge AreaTài liệu điển hình
KA3 — Planning & Monitoring
  • BA Approach
  • Stakeholder Engagement Approach
  • Governance Approach
— các "kế hoạch nền" cho toàn dự án
KA4 — Elicitation & Collaboration
  • Elicitation Activity Plan
  • Biên bản họp/phỏng vấn (interview notes)
— nguyên liệu thô đầu vào
KA5 — Requirements Life Cycle Mgmt
  • RTM (Requirements Traceability Matrix)
  • Nhật ký Change Request
— công cụ theo dõi xuyên suốt
KA6 — Strategy Analysis
  • Business Case
  • Current State / Future State Description
— thuyết phục đầu tư trước khi đi sâu chi tiết
KA7 — Requirements Analysis & Design Definition
  • BRD
  • FRD
  • SRS
  • Use Case Document
  • User Story
— nơi hầu hết tài liệu requirements "sống" chính
KA8 — Solution Evaluation
  • UAT Script / Test Case
  • Báo cáo Solution Performance
— xác nhận giá trị thực tế đạt được

💡 Tài liệu ↔ BACCM ▾

💡 Tài liệu nào phục vụ khái niệm cốt lõi nào trong BACCM?
6 khái niệm BACCM (Change, Need, Solution, Stakeholder, Value, Context) không nằm trên giấy tờ trừu tượng — mỗi tài liệu BA thực chất là cách "ghi lại" 1 hoặc vài khái niệm này ở một thời điểm cụ thể.
Tài liệuKhái niệm BACCM chính
Business CaseNeed (vấn đề/cơ hội cần giải quyết) + Value (lợi ích kỳ vọng nếu đầu tư)
BRDNeed + Change (mục tiêu thay đổi cần đạt)
FRD / SRSSolution (mô tả cụ thể cách thỏa mãn Need)
Use Case / User StoryStakeholder (góc nhìn actor/vai trò) tương tác với Solution
RTMChange — theo dõi & liên kết mọi khái niệm khác xuyên suốt vòng đời, không thiên về 1 concept riêng
UAT / Test CaseValue (xác nhận giá trị đã thực sự đạt được, không chỉ đúng kỹ thuật)

⚠️ Cặp tài liệu dễ nhầm lẫn ▾

⚠️ 4 cặp/nhóm tài liệu hay bị nhầm lẫn nhất
Cặp dễ nhầmPhân biệtMẹo nhớ
BRD vs FRD vs SRS
  • BRD: TẠI SAO cần thay đổi, mục tiêu kinh doanh — không nói hệ thống làm gì cụ thể
  • FRD: hệ thống phải LÀM GÌ — chức năng cụ thể, chưa nói công nghệ triển khai
  • SRS: hệ thống hoạt động NHƯ THẾ NÀO về mặt kỹ thuật — API, database, performance
 Đi từ rộng → hẹp: BRD (why) → FRD (what) → SRS (how, kỹ thuật)
Business Case vs BRD
  • Business Case: thuyết phục ĐẦU TƯ — có nên làm dự án này không, so sánh phương án
  • BRD: giả định ĐÃ được duyệt đầu tư rồi, giờ ghi lại chi tiết nhu cầu kinh doanh cần đáp ứng
 Business Case trả lời "có nên làm không"
BRD trả lời "làm cái gì" (sau khi đã quyết định làm)
User Story vs Use Case
  • User Story: ngắn gọn, 1-2 câu, chi tiết bổ sung dần qua trao đổi — kiểu Agile
  • Use Case: đầy đủ ngay từ đầu, có main flow + alternate/exception flow được viết trước — kiểu truyền thống/Predictive
 User Story = "vé vào cuộc trò chuyện"
Use Case = "kịch bản đầy đủ viết sẵn"
RTM vs "tài liệu requirements"
  • RTM không MÔ TẢ nội dung requirement — nó chỉ LIÊN KẾT requirement với design/test/business goal khác
  • Tài liệu requirements (BRD/FRD/SRS) mới thực sự chứa nội dung, mô tả cái cần làm
 RTM = "sơ đồ dây điện nối các phòng"
BRD/FRD/SRS = "nội thất trong từng phòng"

⚠️ Sai lầm thường gặp ▾

⚠️ Sai lầm thường gặp theo từng loại tài liệu
📋 BRD / FRD / SRS
  • Viết requirement mơ hồ, không đo lường được — VD "cải thiện hiệu suất" thay vì "giảm thời gian xử lý đơn hàng từ 5 ngày còn 1 ngày"
  • Trộn lẫn chi tiết kỹ thuật ("how") vào BRD — BRD chỉ nên nói "cái gì" và "tại sao", để "làm thế nào" cho FRD/SRS
  • Không định nghĩa rõ phạm vi loại trừ (out of scope) — dễ dẫn đến tranh cãi scope creep giữa chừng dự án
  • Bỏ qua non-functional requirements (hiệu năng, bảo mật, khả năng mở rộng) — chỉ tập trung vào functional
  • Không có sign-off chính thức từ stakeholder có thẩm quyền trước khi triển khai — hậu quả là tranh chấp phạm vi 3 tháng sau
📝 User Story
  • Vi phạm tiêu chí INVEST — đặc biệt hay gặp: story quá to/mơ hồ (không Small), thiếu rõ giá trị mang lại (không Valuable)
  • Phần "so that" (để làm gì) mô tả lại requirement thay vì giá trị kinh doanh thực sự — VD "để xem đơn hàng trong bảng" thay vì "để theo dõi lịch sử mua hàng"
  • Vai trò (role) quá chung chung ("là user") hoặc quá hẹp — khó xác định đúng nhu cầu cần đáp ứng
  • Nhồi quá nhiều chi tiết kỹ thuật vào story — giới hạn sáng tạo của dev team, đi ngược tinh thần "Negotiable"
🔗 RTM (Requirements Traceability Matrix)
  • Thiếu ID duy nhất cho từng requirement/test case — khó tham chiếu chéo khi dự án lớn dần
  • Coi RTM là tài liệu làm 1 lần rồi thôi, không cập nhật khi requirement thay đổi — RTM "chết" ngay sau khi tạo
  • Liên kết không đầy đủ — có requirement không map tới test case nào (hoặc ngược lại), tạo lỗ hổng coverage
  • Đặt tên/quy ước không nhất quán giữa các phiên bản — VD không phân biệt "FR-001" bản gốc và bản đã sửa
💼 Business Case
  • Chỉ trình bày 1 phương án duy nhất — không so sánh với các lựa chọn khác (kể cả "không làm gì") để chứng minh đây là phương án tốt nhất
  • Ước tính lợi ích (benefit) quá lạc quan, thiếu cơ sở — dễ bị chất vấn khi trình bày cho ban lãnh đạo
  • Bỏ qua rủi ro và giả định (assumptions) — khiến ban lãnh đạo ra quyết định thiếu thông tin đầy đủ
📚 Nguồn tham khảo: BRD — lỗi thường gặp & BRD vs FRD vs SOW · Visure — cách viết BRD hiệu quả · Visual Paradigm — tiêu chí INVEST cho User Story · 7 lỗi User Story thường gặp · TestRail — hướng dẫn RTM đầy đủ
100%
Focus Mode
🔈 🔊
25:00
Focus
Focus length: 25 min
Break length: 5 min
🗑️
Study Journal
What did you learn today? One entry per day — pick a date below to see or edit past entries.
Chọn kích thước
🖌️ Diagram Editor