Bài 24 — State machine: vòng đời nghiệp vụ

Mở đầu — vì sao bài này quan trọng

Nếu bạn từng làm Sales hoặc Business Development, có một thứ bạn đã sống cùng mỗi ngày mà có thể bạn chưa bao giờ gọi đúng tên của nó: state machine — máy trạng thái.

Hãy nghĩ lại pipeline bán hàng của bạn. Một cơ hội (opportunity) không nhảy lung tung khắp nơi. Nó đi theo một đường rất rõ: từ Lead → MQL (Marketing Qualified Lead) → SQL (Sales Qualified Lead) → Opportunity → và cuối cùng là Closed-Won hoặc Closed-Lost. Bạn không thể "Closed-Won" một cái lead mà chưa từng qua bước demo. Bạn không thể quay ngược một deal đã ký hợp đồng về lại trạng thái "chưa liên hệ". Có những bước được phép, có những bước bị cấm.

Đó chính xác là một state machine. Và đây là tin tốt cho bạn: trực giác về vòng đời mà bạn đã tích lũy suốt nhiều năm bán hàng chính là một trong những công cụ tư duy mạnh nhất của một Business Analyst.

Khi làm BA, bạn sẽ phải mô tả vòng đời của hàng loạt "thực thể nghiệp vụ" (business entity): đơn hàng, hồ sơ vay, yêu cầu bảo hiểm, ticket hỗ trợ, tài khoản người dùng, phiếu giao hàng... Mỗi thực thể này đều có một tập trạng thái hữu hạn và những quy tắc chuyển trạng thái. Nếu bạn mô tả vòng đời này một cách lỏng lẻo, dev sẽ code ra một hệ thống cho phép những hành động vô lý — ví dụ hoàn tiền một đơn hàng chưa thanh toán. Nếu bạn mô tả nó chặt chẽ bằng state machine, bạn bịt kín được hàng loạt lỗ hổng nghiệp vụ ngay từ khi nó còn trên giấy.

Bài này dạy bạn cách biến trực giác pipeline thành một công cụ phân tích chính quy.

Khái niệm cốt lõi

State machine là gì?

Một state machine (máy trạng thái, hay đầy đủ là finite state machine — máy trạng thái hữu hạn) mô tả một thực thể qua bốn thành phần:

• States (các trạng thái): Tập hợp hữu hạn các "tình trạng" mà thực thể có thể ở. Ví dụ với đơn hàng: Chờ thanh toán, Đã thanh toán, Đang giao, Đã giao, Đã hủy, Đã hoàn tiền.
• Transitions (các chuyển tiếp): Những bước đi được phép giữa hai trạng thái. Ví dụ: từ Đã thanh toán được phép sang Đang giao, nhưng không được phép nhảy thẳng sang Đã hoàn tiền mà không qua Đã hủy.
• Events / Triggers (sự kiện kích hoạt): Cái gì làm cho chuyển tiếp xảy ra. Ví dụ: khách bấm "Thanh toán", hệ thống cổng thanh toán xác nhận, nhân viên kho bấm "Bàn giao shipper".
• Guards (điều kiện canh giữ): Các điều kiện phải đúng thì chuyển tiếp mới được phép. Ví dụ: chỉ được chuyển sang Đang giao nếu kho còn đủ hàng.

Điểm mấu chốt — và đây là điều khiến state machine có giá trị: không phải mọi trạng thái đều nối với mọi trạng thái khác. Phần lớn các cặp chuyển tiếp đều bị cấm. Công việc của BA là vẽ rõ ra cái gì được phép, cái gì cấm, và trong điều kiện nào.

Sự khác biệt giữa "status" và "state machine"

Nhiều bạn mới chuyển sang BA nhầm lẫn chỗ này. Một cột status trong database chỉ là một cái nhãn. Một state machine là cái nhãn cộng với toàn bộ luật chơi điều khiển nó được thay đổi như thế nào.

Ví dụ, nói "đơn hàng có status là Đã hủy" thì chỉ là dữ liệu. Nhưng nói "đơn hàng chỉ có thể chuyển sang Đã hủy từ trạng thái Chờ thanh toán hoặc Đã thanh toán, do khách hoặc CSKH kích hoạt, và nếu đang ở Đã thanh toán thì phải sinh đồng thời một yêu cầu hoàn tiền" — đó mới là tư duy state machine. Cái thứ hai mới là thứ dev cần để code, và là thứ kiểm thử cần để viết test case.

Các loại trạng thái đặc biệt cần nhớ

• Initial state (trạng thái khởi đầu): Nơi thực thể bắt đầu. Mọi đơn hàng đều bắt đầu ở Giỏ hàng hoặc Chờ thanh toán.
• Final state (trạng thái kết thúc): Nơi vòng đời kết thúc, không còn chuyển tiếp nào đi ra. Như Đã giao hay Đã hoàn tiền. Trong pipeline Sales, đó chính là Closed-Won và Closed-Lost.
• Trạng thái rẽ nhánh: Những điểm mà từ đó có thể đi nhiều hướng tùy điều kiện. Ví dụ từ Đang xét duyệt của hồ sơ vay có thể sang Duyệt, Từ chối, hoặc Yêu cầu bổ sung hồ sơ.

Vì sao state machine là "quê hương" của ex-Sales

Bạn đã có sẵn mô hình tư duy này. Trong CRM như Salesforce hay HubSpot, mỗi giai đoạn pipeline là một state. "Stage gating" — quy tắc không cho phép kéo deal sang stage tiếp theo nếu chưa điền đủ thông tin — chính là guard condition. "Closed-Lost reason" bắt buộc phải chọn lý do trước khi đóng — đó là một guard. Bạn đã thiết kế và tuân theo state machine mà không gọi tên nó. Giờ chỉ là học cách viết nó ra một cách hệ thống để dev hiểu được.

Tình huống thực tế

Ví dụ 1: Vòng đời đơn hàng tại một sàn TMĐT giả định "Chợ Tốt Mua Sắm"

Giả sử bạn là BA cho một đội sản phẩm tại một sàn thương mại điện tử Việt Nam quy mô vừa, mỗi tháng xử lý khoảng 80.000 đơn. Đội dev hỏi bạn: "Đơn hàng có những trạng thái nào và đi qua nhau ra sao?"

Ban đầu, đội vận hành mô tả mơ hồ: "thì đơn được tạo, rồi giao, rồi xong". Bạn — với phản xạ của một người từng quản pipeline — biết ngay là chưa đủ. Bạn ngồi xuống và bóc tách ra như sau:

• Chờ thanh toán (initial) → Đã thanh toán: khi cổng VNPay xác nhận.
• Chờ thanh toán → Đã hủy: nếu quá 24 giờ chưa thanh toán (event này do hệ thống tự động kích hoạt, không phải con người).
• Đã thanh toán → Đang đóng gói → Đang giao → Đã giao (final).
• Đã thanh toán → Đã hủy + Hoàn tiền: nếu khách hủy trước khi đóng gói, guard là "đơn chưa bàn giao shipper".
• Đang giao → Giao thất bại → Đang giao (giao lại lần 2) hoặc → Hoàn hàng.

Diễn giải: Chính cái transition "quá 24 giờ tự hủy" và guard "chỉ hoàn tiền nếu chưa bàn giao shipper" là những thứ đội vận hành quên béng khi mô tả miệng. Nếu không có state machine, dev rất có thể sẽ cho phép khách bấm "Hủy + hoàn tiền" ngay cả khi đơn đã lên xe shipper — gây thất thoát tiền thật.

Bài học rút ra: State machine ép bạn liệt kê mọi lối ra khỏi mỗi trạng thái. Quá trình liệt kê đó chính là lúc các lỗ hổng nghiệp vụ lộ diện — trước khi chúng trở thành lỗi production tốn tiền.

Ví dụ 2: Hồ sơ vay tại một công ty fintech như FE Credit

Tưởng tượng bạn là BA tại một công ty tài chính tiêu dùng, làm sản phẩm vay trả góp online. Một hồ sơ vay có vòng đời phức tạp hơn đơn hàng nhiều, vì có nhiều bên tham gia: khách, hệ thống chấm điểm tín dụng, chuyên viên thẩm định, bộ phận giải ngân.

Các state chính: Nháp → Đã nộp → Đang chấm điểm tự động → từ đây rẽ nhánh:

• Nếu điểm tín dụng đủ cao → Duyệt sơ bộ → Thẩm định thủ công → Duyệt hoặc Từ chối.
• Nếu điểm thấp dưới ngưỡng → Từ chối tự động (final).
• Ở bất kỳ bước thẩm định nào → Yêu cầu bổ sung hồ sơ → quay lại Đã nộp.
• Duyệt → Chờ ký hợp đồng điện tử → Đã giải ngân (final).

Diễn giải: Điều thú vị ở đây là trạng thái Yêu cầu bổ sung hồ sơ tạo ra một vòng lặp (loop) quay về Đã nộp. Nhiều BA non kinh nghiệm vẽ vòng đời như một đường thẳng một chiều và bỏ sót các vòng lặp này. Nhưng trong nghiệp vụ thật, "đẩy lùi" và "làm lại" là chuyện thường ngày. Một con số thực tế: tại nhiều công ty tài chính tiêu dùng VN, có thể tới 25–30% hồ sơ bị yêu cầu bổ sung ít nhất một lần. Nếu state machine của bạn không có lối quay lại đó, hệ thống sẽ bí.

Bài học rút ra: Hãy hỏi với mỗi trạng thái: "Từ đây, ngoài đi tới, có thể đi lùi hay lặp lại không?" Vòng lặp và đường lùi là nơi BA non kinh nghiệm hay sai nhất.

Ví dụ 3: So sánh trực tiếp với pipeline Sales bạn đã quen

Để thấy rõ bạn đã nắm sẵn khái niệm này, hãy đặt cạnh nhau. Pipeline Sales của bạn: Lead → MQL → SQL → Opportunity → Negotiation → Closed-Won / Closed-Lost.

Giờ thử áp các câu hỏi BA vào chính pipeline đó:

• Guard: Một lead có được nhảy thẳng từ Lead sang Opportunity không? Thông thường là không — phải qua qualification (SQL). Đó là một guard.
• Event: Cái gì biến SQL thành Opportunity? Có thể là sự kiện "khách đồng ý xem demo" hoặc "BANT đủ điều kiện".
• Đường lùi: Một Opportunity có thể tụt về SQL không? Trong thực tế có — khi deal nguội đi. Nhiều CRM cho phép, nhiều CRM lại cấm để giữ kỷ luật forecast.
• Final state có thể tái sinh không? Một Closed-Lost có thể được "mở lại" (reopen) thành SQL không khi khách quay lại sau 6 tháng? Đây là một quyết định thiết kế thật mà ban lãnh đạo Sales phải chọn.

Bài học rút ra: Những câu hỏi bạn từng tranh luận với sales manager về "có cho kéo deal ngược lại stage không" chính là những câu hỏi mà một BA hỏi về bất kỳ thực thể nào. Bạn không học một kỹ năng mới — bạn đang tổng quát hóa một kỹ năng cũ.

Hướng dẫn từng bước

Đây là quy trình 6 bước để xây dựng state machine cho bất kỳ thực thể nghiệp vụ nào.

Bước 1 — Xác định thực thể. Chọn đúng "danh từ" mà bạn đang mô tả vòng đời: đơn hàng, hồ sơ vay, ticket, tài khoản. Một thực thể, một state machine. Đừng trộn vòng đời của đơn hàng với vòng đời của lô hàng vào chung một sơ đồ.

Bước 2 — Liệt kê toàn bộ states. Dùng kỹ thuật elicitation (khai thác yêu cầu): hỏi stakeholder "đơn này có thể đang ở những tình trạng nào?". Gom các từ ngữ họ dùng hằng ngày: "đang treo", "đang chờ duyệt", "đã đóng". Mỗi từ ngữ vận hành đó thường là một state. Đặt tên state ngắn gọn, là danh từ/tính từ rõ ràng, nhất quán (ví dụ luôn dùng Đã ... cho trạng thái hoàn thành).

Bước 3 — Đánh dấu initial và final. Xác định 1 trạng thái khởi đầu và (thường) nhiều trạng thái kết thúc. Closed-Won và Closed-Lost là hai final khác nhau — đừng gộp.

Bước 4 — Vẽ transitions hợp lệ. Lập một ma trận chuyển trạng thái (state transition matrix): kẻ bảng với hàng là trạng thái nguồn, cột là trạng thái đích, ô giao nhau ghi "được phép / cấm / event nào". Đây là công cụ vàng để không bỏ sót: bạn buộc phải xem xét từng cặp trạng thái.

Bước 5 — Gắn event và guard cho mỗi transition. Với mỗi ô "được phép", trả lời: Ai/cái gì kích hoạt? (event) và Điều kiện gì phải đúng? (guard). Ví dụ: transition Đã thanh toán → Đã hủy có event = "khách bấm hủy", guard = "đơn chưa bàn giao shipper".

Bước 6 — Diễn đạt bằng sơ đồ trực quan + đặc tả văn bản. Vẽ state diagram (sơ đồ trạng thái — bạn sẽ học công cụ vẽ ở các bài về BPMN và Mermaid/PlantUML). Mỗi trạng thái là một hình chữ nhật bo góc, mỗi transition là một mũi tên có nhãn event [guard]. Kèm bảng ma trận ở Bước 4 vào tài liệu để dev và QA tra cứu.

Một mẹo định dạng nhãn mũi tên theo chuẩn UML: tên_event [điều_kiện_guard] / hành_động. Ví dụ: khách_bấm_hủy [chưa_bàn_giao_shipper] / sinh_yêu_cầu_hoàn_tiền.

Lỗi thường gặp & mẹo

Lỗi 1 — Bỏ sót trạng thái lỗi và ngoại lệ. BA mới thường chỉ vẽ "happy path" (luồng thuận lợi). Nhưng thực tế đầy Giao thất bại, Thanh toán lỗi, Hết hạn. Mẹo: với mỗi trạng thái, hỏi "nếu bước này thất bại thì đi đâu?".

Lỗi 2 — Bỏ quên đường lùi và vòng lặp. Như ví dụ hồ sơ vay, "yêu cầu bổ sung" tạo vòng lặp. Mẹo: hỏi "trạng thái này có thể bị trả ngược lại không?".

Lỗi 3 — Không định nghĩa guard, để transition "mở toang". Nếu bạn chỉ ghi "Đã thanh toán → Đã hủy" mà không có guard, dev sẽ cho hủy ở mọi tình huống. Mẹo: mọi transition liên quan tiền bạc, tồn kho, hợp đồng đều phải có guard rõ ràng.

Lỗi 4 — Trạng thái "mồ côi" (orphan/dead state). Một trạng thái không có đường vào hoặc không có đường ra (mà không phải final/initial). Mẹo: dùng ma trận để soi — mỗi state không-final phải có ít nhất một transition ra, mỗi state không-initial phải có ít nhất một transition vào.

Lỗi 5 — Nhồi quá nhiều state. Nếu state machine của bạn có 40 trạng thái, có thể bạn đang trộn nhiều thực thể, hoặc đang biến dữ liệu (như "đã thanh toán 1 phần") thành state thay vì thuộc tính. Mẹo: state là "giai đoạn vòng đời", còn các chi tiết định lượng nên là thuộc tính (attribute) của thực thể.

Mẹo vàng cho ex-Sales: Khi phỏng vấn stakeholder vận hành, đừng hỏi lý thuyết "vòng đời của đơn là gì?". Hỏi như bạn từng hỏi khách: "Kể em nghe một đơn hàng điển hình đi từ lúc đặt tới lúc xong như thế nào? Rồi kể em một đơn trục trặc gần đây nhất". Câu chuyện cụ thể sẽ lộ ra cả happy path lẫn ngoại lệ — đúng kỹ năng đặt câu hỏi mở mà bạn đã giỏi từ thời bán hàng.

Bài tập thực hành

Bài tập 1 — Dịch pipeline của chính bạn. Lấy pipeline Sales bạn từng dùng (Lead → ... → Closed). Viết lại nó dưới dạng state machine đầy đủ: liệt kê states, đánh dấu initial/final, và với mỗi transition ghi rõ event + guard. Đặc biệt trả lời: có cho phép kéo deal ngược stage không, và Closed-Lost có reopen được không?

Bài tập 2 — Lập ma trận chuyển trạng thái cho ticket hỗ trợ. Một ticket CSKH có các state: Mới, Đang xử lý, Chờ khách phản hồi, Đã giải quyết, Đã đóng, Mở lại. Hãy kẻ bảng ma trận 6×6, đánh dấu mỗi ô là "được phép" (kèm event) hay "cấm". Sau đó tìm xem có trạng thái mồ côi nào không.

Bài tập 3 — Săn ngoại lệ. Lấy vòng đời đơn hàng TMĐT ở Ví dụ 1. Liệt kê thêm ít nhất 4 trạng thái lỗi/ngoại lệ mà bài chưa nêu (gợi ý: nghĩ về thanh toán, tồn kho, địa chỉ giao, gian lận). Với mỗi cái, ghi nó nối vào state machine ở đâu.

Bài tập 4 (nâng cao) — Đặc tả một transition chuẩn dev. Chọn một transition nhạy cảm về tiền (ví dụ Đã thanh toán → Hoàn tiền). Viết một đoạn đặc tả ngắn gồm: event, danh sách guard, hành động phụ sinh ra (side effect), và ai có quyền kích hoạt. Đây chính là dạng tài liệu bạn sẽ giao cho dev và QA.

Tóm tắt

• State machine mô tả vòng đời một thực thể nghiệp vụ qua bốn thành phần: trạng thái (states), chuyển tiếp (transitions), sự kiện (events) và điều kiện canh giữ (guards).
• Điểm cốt lõi: không phải trạng thái nào cũng nối được với trạng thái nào — công việc của BA là vẽ rõ cái gì được phép, cái gì cấm, và trong điều kiện gì.
• Là ex-Sales, bạn đã sống cùng state machine qua pipeline Lead → ... → Closed-Won/Lost; stage gating chính là guard, đổi stage chính là transition. Bạn chỉ cần tổng quát hóa trực giác đó.
• Quy trình 6 bước: xác định thực thể → liệt kê states → đánh dấu initial/final → vẽ transitions (qua ma trận) → gắn event + guard → diễn đạt bằng sơ đồ + văn bản.
• Đừng chỉ vẽ happy path: săn lùng trạng thái lỗi, đường lùi, vòng lặp và guard cho mọi transition nhạy cảm về tiền/tồn kho/hợp đồng.
• Ma trận chuyển trạng thái là vũ khí chống bỏ sót mạnh nhất — nó ép bạn xét từng cặp trạng thái.

Nắm vững state machine, bạn sẽ thấy nó xuất hiện khắp nơi trong nghiệp vụ — và bạn sẽ là người BA mô tả vòng đời chặt chẽ đến mức dev và QA gần như không còn câu hỏi mơ hồ nào để hỏi lại.