Trong bài nói về các loại diagram nên dùng trong tài liệu BRD, mình đã dùng 1 ví dụ sơ đồ BPM dưới đây.
Hôm nay chúng ta hãy đi sâu vào và phân tích từng bước để ra được sơ đồ nhé. Let’s go!
1. Lấy requirement
Bằng mọi thủ đoạn, hãy lấy được requirement càng chi tiết càng tốt về quy trình cần phân tích. Ví dụ quy trình bán hàng as-is (khi chưa có website) được client mô tả như sau:
Khách bên anh sẽ inbox fanpage facebook của shop để hỏi sản phẩm. Bạn trực inbox bên anh sẽ chăm sóc. Thường là khách hỏi size còn không, check giá. Bạn trực sẽ check hàng trong kho còn tồn không. Nếu còn thì báo khách thanh toán chuyển khoản trước 100%, hoặc nếu khách chọn COD thì chuyển trước 20%. Xong xuôi thì bạn trực đó tạo đơn hàng vô hệ thống quản lý kho sẵn có của shop anh. Nhân viên bên phía kho sẽ thấy đơn hàng và bắt đầu xuất kho, in bill, đóng gói, giao cho bên vận chuyển. Bên vận chuyển tiến hành giao hàng cho khách. Khách hàng nhận hàng nếu chọn COD thì phải thanh toán thêm 80%. Nếu khách không nhận hàng, bên vận chuyển sẽ giao ngược về, nhân viên kho nhận hàng sẽ tiến hành nhập kho.
Đọc xong quy trình này, bạn sẽ bắt đầu ngợp bởi khá nhiều thông tin. Đặc biệt nếu không phải người trong ngành nghề/lĩnh vực đó.
2. Phân tích requirement
Phân tích hiểu đơn giản chính là chọn lọc → phân loại thông tin.
2.1 Chọn lọc
Hãy scan qua requirement 1 lần nữa, nhưng lần này highlight từ khóa lên, bỏ qua những từ gây nhiễu. Chú ý đến loại từ khóa sau:
- 1 đối tượng (actor)- màu vàng
- 1 hành động (action) – màu đỏ
- 1 thực thể (object)- màu xanh dương
- 1 điều kiện (logic)- màu xanh lá
Khách bên anh sẽ inbox fanpage facebook của shop để hỏi sản phẩm. Bạn trực inbox bên anh sẽ chăm sóc. Thường là khách hỏi size còn không, check giá. Bạn trực sẽ check hàng trong kho còn tồn không. Nếu còn thì báo khách thanh toán chuyển khoản trước 100%, hoặc nếu khách chọn COD thì chuyển trước 20%. Xong xuôi thì bạn trực đó tạo đơn hàngvô hệ thống quản lý kho sẵn có của shop anh. Nhân viên bên phía kho sẽ thấy đơn hàng và bắt đầu xuất kho, in bill, đóng gói, giao cho bên vận chuyển. Bên vận chuyển tiến hành giao hàng cho khách. Khách hàng nhận hàng nếu chọn COD thì phải thanh toán thêm 80%. Nếu khách không nhận hàng, bên vận chuyển sẽ giao ngược về, nhân viên kho nhận hàng sẽ tiến hành nhập kho.
2.2 Phân loại
Tổng hợp các từ khóa theo từng nhóm, 1 số từ dùng đồng nghĩa cũng cần lưu ý gom lại:
| Loại | Từ khóa | Chú giải |
| Đối tượng (actor) |
\* Khách hàng \* Nhân viên tư vấn \* Hệ thống quản lý kho \* Nhân viên kho \* Đơn vị vận chuyển |
Là 1 người hoặc hệ thống đang thực hiện ít nhất 1 hành động nào đó trong quy trình trên. |
| Hành động (action) |
\* Liên hệ cửa hàng \* Trả lời khách hàng \* Check hàng tồn \* Yêu cầu thanh toán \* Thanh toán \* Tạo đơn hàng \* Nhận thông báo đơn hàng mới \* Xuất kho \* In bill \* Giao hàng cho nhà vận chuyển \* Giao hàng cho khách \* Thanh toán COD \* Trả hàng về kho \* Nhập kho hàng trả |
Hành động được thực hiện bởi 1 actor trong quy trình, cho ra 1 output cụ thể. |
| Thực thể (object) |
\* Fanpage FB \* Sản phẩm \* Size \* Giá \* Kho \* Đơn hàng \* Bill |
Thực thể mang thông tin mô tả dữ liệu đầu vào hoặc đầu ra của 1 action bất kỳ trong quy trình. |
| Điều kiện (logic) |
\* Sản phẩm cần tìm còn hàng hay không? \* Khách hàng lựa chọn cách thanh toán nào? \* Khách hàng thanh toán đủ hay không? \* Khách có nhận hàng hay không? |
1 điều kiện có thể chia quy trình thành các nhánh nhỏ hơn. Điều kiện phải thỏa thì các action phía sau mới thực hiện tiếp. |
3. Tạo pool và lane
Giai đoạn phân tích đã xong, giờ bắt đầu vẽ thôi:
Dựa trên việc phân tích, chúng ta đã biết có bao nhiêu actor tham gia quy trình. Bây giờ tiến hành tạo pool và lane cho từng actor.
Ở ví dụ này Tư vấn viên và Nhân viên kho đều thuộc Shop nên mình gom lại thành 2 lane của 1 pool. Các đối tượng khác tương đối độc lập nên mình tách thành mỗi đối tượng 1 Pool.
Việc gom pool và lane phụ thuộc vào tình huống cụ thể. Khi vẽ nhiều các bạn sẽ rút ra được “best practice” cho mình.
Có thể tô màu để dễ phân biệt giữa các pool.
Riêng Pool Hệ thống quản lý kho mình sẽ coi nó như 1 cái “hộp đen” và sử dụng Pool rỗng. Nghĩa là không quan tâm action của nó, chỉ quan tâm input và output khi đi qua nó thôi.
4. Xác định Start – End của từng lane
Hãy đặt câu hỏi Điểm bắt đầu và điểm kết thúc của từng vai trò trong quy trình này là gì?
- Khách hàng: Nhu cầu muốn mua hàng → Nhận được hàng thành công
- Tư vấn viên: Khách hàng inbox (Bắt đầu quy trình tư vấn) → Tư vấn xong
- Nhân viên kho: Hệ thống báo có đơn hàng mới (Bắt đầu quy trình xuất hàng) → Hoàn thành xuất hàng cho bên vận chuyển
- Đơn vị vận chuyển: Nhân viên kho bàn giao hàng (Bắt đầu quy trình giao hàng) → Hoàn thành giao cho khách
Pool Hệ thống quản lý kho không cần phân tích bước này vì là Pool rỗng.
Sau khi phân tích xong, hãy đặt các Start event và End event vào đầu và cuối từng pool tương ứng.
5. Tạo task
Từ bảng phân loại, bắt đầu tạo các task theo thứ tự từ trên xuống dưới và đặt vào pool tương ứng
Ở bước này không chỉ đơn giản là tất cả các action phân tích ở trên được đều được đặt vào đây. Hãy nhớ những quy tắc cần thiết để giữ cho sơ đồ tinh gọn và có tính tổng quát.
Gom các action liên quan thành 1 sub-process.
Mỗi lane giới hạn khoảng 3 – 4 task / sub-process.
Tập trung vào happy flow (main flow), các case ngoại lệ hạn chế thể hiện lên sơ đồ.
Sắp xếp các task theo thứ tự diễn ra (xét trên từng lane)
Sử dụng Động từ + Danh từ để đặt tên cho task.
6. Vẽ luồng đi và logic
Dựa vào trình tự action từ bảng phân loại, vẽ sequence flow (liên kết cùng pool) hoặc message flow (liên kết khác pool) để kết nối các task và event.
Hãy tư duy như vầy, khi vẽ flow cho task:
- Task đó cần input gì để thực hiện được: sau khi xác định được, hãy nhìn xem task/event đứng trước nó có trả ra đủ thông tin mà task đó cần hay không.
- Nếu cảm thấy thiếu input cho 1 task, có nghĩa là bạn đã xác định thiếu action trong bước phân tích. Hãy bổ sung thêm task hoặc event để không lủng logic.
Chọn cổng phù hợp để thể hiện logic diễn ra. Mình rất ít khi sử dụng cổng AND và cổng OR, cục nào mà nhiều task AND hoặc OR thì mình gom thành sub-process hết cho gọn. Chủ yếu dùng cổng XOR để biểu thị các case dị biệt.
Ở ví dụ này mình chọn thể hiện 2 case dị biệt đó là : Khách hàng thanh toán không thành công và Khách hàng không đồng ý nhận hàng.
Còn 1 case nữa là khách chọn hình thức thanh toán nào (COD hay chuyển khoản 100%) mình quyết định không đưa vào BPM mà sẽ mô tả bằng Business Rule để thể hiện chi tiết hơn. Nếu vẽ chi tiết ở sub-process Thực hiện thanh toán của khách hàng thì có thể mình sẽ phân nhánh cho case này.
Bổ sung event cần thiết, điều chỉnh loại start-end cho phù hợp: ở ví dụ này, start event của khách hàng chính là trigger đầu tiên, các start event của những role khác đều cần input từ 1 action khác → Đổi lại sử dụng kiểu Message start event.
7. Sắp xếp gọn gàng
Bạn đã hoàn thành 99% công việc, tiếp đến chính là sắp xếp gọn gàng, điều chỉnh các flow sao cho không bị chồng chéo như tơ nhện. Note thêm chi tiết cho các message flow nếu cần.
Okay hoàn thành rồi. Giờ thì hãy tự tin đặt chiếc sơ đồ này vào tài liệu của bạn nhé.
Hãy tập luyện nhiều hơn để thuần thục các bước. Đến 1 lúc nào đó, bạn có thể lướt rất nhanh qua các bước phân tích mà nhảy thẳng vào việc vẽ luôn.
P/s: Mình có biến tấu cách vẽ 1 chút so với nguyên tắc của BPMN 2.0 để phù hợp với nhu cầu sử dụng và tinh gọn hơn cho sơ đồ BPM. Lược bớt 1 số rule rườm rà, chỉ cần đủ để người đọc hiểu là được. (Ví dụ có 1 số quy ước là liên kết task giữa các pool phải có throw task để gửi message và catch event để bắt message đó trước khi đi tiếp. Mình cảm thấy lược bỏ cũng không ảnh hưởng logic và người đọc vẫn hiểu được nên mình dẹp luôn cho gọn)