Trước khi đề xuất giải pháp, BA cần hiểu và trình bày rõ quy trình hiện tại (AS-IS) và quy trình mong muốn (TO-BE) — mô hình hoá bằng sơ đồ giúp mọi stakeholder cùng nhìn thấy 1 bức tranh thống nhất, tránh hiểu lầm do diễn giải bằng lời khác nhau.
"Khi nào dùng Exclusive Gateway, khi nào dùng Parallel Gateway?" — Exclusive Gateway dùng khi quy trình chỉ có thể đi theo đúng 1 hướng dựa trên điều kiện (vd. đơn hàng được duyệt HOẶC bị từ chối, không thể cả hai). Parallel Gateway dùng khi nhiều hoạt động xảy ra đồng thời không phụ thuộc nhau (vd. vừa gửi email xác nhận vừa cập nhật kho hàng cùng lúc).
"Bạn vẽ AS-IS process trước khi đề xuất giải pháp để làm gì, tại sao không đi thẳng vào TO-BE?" — AS-IS giúp phát hiện điểm nghẽn thật sự trong quy trình hiện tại (không đoán mò), tạo sự đồng thuận với stakeholder rằng vấn đề đã được hiểu đúng trước khi đề xuất thay đổi, và làm căn cứ đo lường cải tiến sau này (so sánh trước/sau).
"Quy trình có nhiều exception case phức tạp, làm sao trình bày để không rối cho stakeholder không chuyên?" — Có thể tách sơ đồ chính (happy path) riêng với các sơ đồ phụ mô tả từng exception case, thay vì nhồi tất cả vào 1 sơ đồ khổng lồ khó đọc — ưu tiên khả năng giao tiếp hơn là thể hiện đầy đủ mọi chi tiết trong 1 hình.
Draw.io, Lucidchart, Visio cho vẽ sơ đồ thủ công — hoặc các công cụ BPM chuyên nghiệp hơn (Camunda, Bizagi) khi công ty cần thực thi quy trình tự động (workflow automation), không chỉ dừng ở tài liệu mô tả.
Kể 1 case cụ thể: quy trình nào bạn đã mô hình hoá, vấn đề phát hiện được qua việc vẽ AS-IS (thường là bước thừa, chờ đợi không cần thiết, hoặc điểm nghẽn phê duyệt), và cải tiến đề xuất trong TO-BE cùng kết quả đo được.