BPMN & Process Mapping
TechnicalProcess mapping và BPMN từ beginner đến expert: as-is/to-be workflow, swimlanes, gateways, exceptions, handoffs, bottlenecks, case studies và best practices.
Đăng nhập để đánh dấu kỹ năng và theo dõi tiến độ.
Roadmap — Cách học và đạt kỹ năng
BPMN & Process Mapping là gì?
Process mapping là cách vẽ lại quy trình thật đang diễn ra để mọi người nhìn cùng một thực tế: ai làm gì, theo thứ tự nào, dùng system nào, chờ ai approve, chỗ nào bị delay, và khi có lỗi thì đi đâu. BPMN là một notation chặt hơn để mô tả process bằng event, task, gateway, swimlane, message flow và exception flow.
Với BA/PM, skill này quan trọng vì rất nhiều product problem thực ra là process problem: handoff không rõ, policy mơ hồ, thiếu owner, duplicate data entry, approval quá nhiều bước, hoặc system không phản ánh cách team làm việc thật.
Rule đơn giản: đừng design solution trước khi hiểu process hiện tại. Nếu bạn không vẽ được as-is process, khả năng cao bạn chưa hiểu vấn đề đủ sâu.
Roadmap keyword coverage - các wording trên roadmap nghĩa là gì?
| Roadmap wording | Ý nghĩa khi học skill này | Artifact / evidence | Bài tập thực hành |
|---|---|---|---|
| Vẽ quy trình (Process mapping) | Beginner level: vẽ flow dễ hiểu để stakeholder cùng xác nhận cách công việc thực sự diễn ra. | As-is flowchart, pain point list | Vẽ quy trình hiện tại của một approval process trong 8-12 bước. |
| BPMN / process modeling | Junior/Senior BA level: dùng notation rõ hơn như events, tasks, gateways, swimlanes, exceptions. | BPMN diagram có swimlanes và gateways | Thêm owner, decision point, exception path vào flow đã vẽ. |
| Process mapping | Foundation skill: phát hiện bottleneck, rework, handoff, SLA, data gaps và ownership gaps. | Process map + improvement backlog | Đánh dấu 3 bottlenecks và đề xuất 3 product/process fixes. |
Core concepts: từ beginner đến expert
| Level | Người học cần biết | Output tốt trông như thế nào? | Common mistake |
|---|---|---|---|
| Beginner | Flowchart, start/end, step, decision, owner. | Stakeholder nhìn vào hiểu ngay quy trình hiện tại. | Vẽ đẹp nhưng thiếu owner và exception. |
| Junior BA | Swimlane, handoff, decision point, input/output. | Ai làm gì, khi nào chuyển bước, data nào đi kèm. | Gộp nhiều activity vào một box quá lớn. |
| Senior BA / PM | BPMN event, gateway, message flow, SLA, exception path. | Process đủ rõ để Engineering, QA, Ops và business validate. | Chỉ vẽ happy path, bỏ qua fail/retry/escalation. |
| Lead / Expert | Operating model, controls, metrics, automation opportunities. | Map connect được process, policy, system, people, risk và metrics. | Tự động hóa quy trình tệ thay vì redesign quy trình. |
BPMN notation cheat sheet
How-to: cách vẽ process map đúng cách
- Define scope: process bắt đầu ở đâu và kết thúc khi nào? Ví dụ: "từ lúc candidate nộp CV đến lúc recruiter gửi interview invite".
- List actors: user, internal team, external partner, system, approver, compliance, finance.
- Capture as-is: phỏng vấn người làm thật, xem screen/system thật, lấy sample ticket/email/form thật.
- Separate fact from assumption: nếu chưa chắc, đánh dấu assumption và owner để verify.
- Draw happy path first: start event, task, decision, end event.
- Add exception paths: reject, missing data, duplicate, timeout, system down, manual override, escalation.
- Add metrics: cycle time, wait time, rework rate, error rate, approval SLA, handoff count.
- Validate with stakeholders: business, ops, support, QA, engineering, compliance nếu cần.
- Create to-be flow: simplify, automate, remove approvals, add guardrails, clarify ownership.
- Turn into backlog: each improvement becomes requirement, story, automation task, policy change or training item.
Real-world example 1: Hiring pipeline process
Problem: HR team mất candidate vì review CV quá chậm, hiring manager không biết ai cần approve, candidate bị hỏi lại thông tin đã nộp.
As-is process: Candidate applies -> HR downloads CV -> HR forwards email to hiring manager -> manager replies late -> HR schedules interview manually -> candidate no-shows because time zone not confirmed.
Issues found: duplicate data entry, no SLA, no candidate status, no owner for late manager response, no reminder, no structured rejection reason.
| Process step | Owner | Problem | To-be improvement | Product requirement |
|---|---|---|---|---|
| CV intake | Candidate / System | Manual download and naming | Auto create candidate profile | Parse PDF/DOCX and store original file |
| Screening | Recruiter | No consistent criteria | Scorecard and fit tags | Recruiter can rate Must-have, Nice-to-have, Risk |
| Manager review | Hiring manager | No SLA | 48h review SLA with reminders | Send reminder when review pending > 24h |
| Interview scheduling | Recruiter / Candidate | Timezone confusion | Candidate chooses available slots | Calendar integration and timezone display |
Real-world example 2: SaaS billing approval
Situation: Sales gives custom discount, Finance approves by email, Legal joins late, Engineering needs plan rules but receives unclear requirements.
What process mapping reveals: discount approval is not a feature request only. It has pricing policy, approval threshold, contract terms, billing system, audit log and customer communication.
BPMN elements to include:
- Start event: Sales requests discount.
- Task: Sales enters discount request with ARR, discount %, contract term, reason.
- Gateway: discount ≤ 15%? If yes, Sales Manager approves. If no, Finance + VP Sales approve.
- Exception: legal terms modified -> route to Legal review.
- End event: approved discount synced to billing and audit log created.
Product output: approval workflow, permission model, audit log, notification rules, billing integration and analytics on discount approvals.
Case study: e-commerce return process redesign
Before: Customer contacts support, support asks for order info, warehouse checks item manually, finance refunds manually. Average resolution time: 6 days. Support tickets: high. Customers complain they do not know status.
Process map finding: 70% of delay is waiting time between support and warehouse. The actual inspection takes only 10 minutes. No one owns status communication.
To-be process: Customer starts return in app -> system validates return window -> customer selects reason and uploads photo -> warehouse receives task -> refund auto-approved for low-risk items -> customer gets status notifications.
Outcome metrics: resolution time, tickets per return, refund error rate, fraud rate, customer satisfaction, warehouse SLA.
Lesson: process mapping helps find leverage. The fix was not just "build return page"; it was redesigning ownership, validation rules, notification and refund policy.
Tips and best practices
- Start simple: dùng boxes/arrows trước, BPMN notation sau. Nếu stakeholder không hiểu diagram, diagram thất bại.
- Use swimlanes: mỗi lane là role/team/system. Handoff pain thường lộ ra ngay khi dùng swimlanes.
- Label gateways clearly: mỗi branch phải có condition: Approved/Rejected, Valid/Invalid, Yes/No.
- Show wait time: process bottleneck thường nằm ở chờ approval, không phải task execution.
- Capture systems: Jira, CRM, email, spreadsheet, ERP, billing, internal admin tool. System gap thường tạo manual workaround.
- Validate with real examples: lấy 3 tickets/orders/candidates thật và walk through diagram.
- Keep versioning: As-is v1, validated as-is, to-be proposal, approved to-be. Đừng overwrite history.
- Turn pain into backlog: mỗi bottleneck cần owner, solution type, priority và success metric.
No-nos: những lỗi cần tránh
- Không vẽ process từ phòng họp nếu chưa xem người dùng làm thật. Workshop rất hữu ích, nhưng process thực tế thường khác policy trên giấy.
- Không dùng BPMN quá phức tạp với non-technical stakeholders. Nếu audience là business, hãy dùng notation vừa đủ.
- Không bỏ exception path. Missing data, duplicate, timeout, reject, fraud, permission denied mới là nơi product requirements quan trọng xuất hiện.
- Không nhảy thẳng sang automation. Automating a broken process makes broken things faster.
- Không quên policy. Nhiều process được quyết định bởi policy, compliance hoặc approval threshold, không chỉ UI.
- Không gọi mọi diamond là decision nếu không có condition rõ. Gateway không có label sẽ làm Engineering và QA hiểu khác nhau.
Tools to use
| Tool | Best for | When to use |
|---|---|---|
| Miro / FigJam | Workshop, sticky notes, early process discovery | Khi cần collaborate với stakeholder và iterate nhanh. |
| Lucidchart / Draw.io | Clean flowcharts and BPMN diagrams | Khi cần publish diagram rõ ràng cho team. |
| Camunda Modeler | Formal BPMN | Khi process cần execution/workflow automation hoặc technical precision. |
| Notion / Confluence | Process documentation | Khi cần lưu context, decisions, metrics, links và version history. |
| Jira / Linear | Turn improvements into backlog | Khi to-be process đã được approve và cần delivery tracking. |
Template: process discovery checklist
| Question | Why it matters | Evidence to collect |
|---|---|---|
| Process starts when? | Defines scope and trigger. | Event, request, form, ticket, email. |
| Who owns each step? | Finds accountability gaps. | Role/team/system owner. |
| What input is required? | Finds missing data and validation needs. | Fields, files, permissions, IDs. |
| What decisions happen? | Finds gateways and approval rules. | Decision criteria, thresholds, approvers. |
| What can go wrong? | Finds exception paths. | Error cases, retries, rejections, escalation. |
| How long does each step wait? | Finds bottlenecks. | SLA, average wait, max delay. |
| What system is used? | Finds integration and manual workaround. | CRM, ERP, email, spreadsheet, admin tool. |
| How do we measure success? | Connects process to outcome. | Cycle time, rework, error, satisfaction, cost. |
Beginner to expert practice plan
- Beginner: chọn một process bạn biết, vẽ 8-12 steps, thêm owner cho từng step.
- Junior: chuyển flow thành swimlane diagram, thêm handoffs, inputs/outputs và pain points.
- Mid-level: thêm gateways, exception paths, SLA, system used và metrics.
- Senior: create to-be process, quantify expected improvement, turn into backlog and rollout plan.
- Expert: connect process map to operating model: policy, org design, automation, control, audit, reporting and continuous improvement.
Definition of done for a strong process map
- Scope, start and end events are clear.
- Every step has owner or system.
- Decision gateways have labels and criteria.
- Happy path and exception paths are included.
- Wait time, rework and handoff points are visible.
- Stakeholders validated the process with real examples.
- To-be changes map to requirements, backlog, policy or training.
- Success metrics are defined before implementation.
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.