Business Process Model – BPM

Phần trước chúng ta đã nói về SCD – một cái nhìn toàn cảnh. Hôm nay sẽ bàn về 1 loại tài liệu khác chứa đựng nhiều thông tin hơn. Đó là BPM – lược đồ quy trình nghiệp vụ

Nếu SCD là 1 cái địa đồ thô sơ thì BPM sẽ ở tầm Google Map. BPM bắt đầu chỉ rõ các con đường kết nối với nhau như thế nào, ở ngã ba nên rẽ trái hay phải , chỗ nào bị sạt núi…

BPM giúp gì?

BPM giả lập trình tự và logic mà các đối tượng trao đổi dữ liệu để đạt được 1 kết quả cụ thể cuối cùng.

Bạn sẽ dùng tới công cụ này khi phải đối mặt với:

• 1 quy trình cụ thể: có 1 kết quả cuối cùng cụ thể cần đạt được
• Có nhiều đối tượng liên quan đến quy trình
• Có nhiều hành động được thực hiện để đạt kết quả cuối cùng
• Có nhiều logic và tình huống có thể xảy ra.

Không phải quy trình nào cũng đè ra vẽ BPM làm chi, chừng nào bạn cảm thấy sẽ rất khó hiểu nếu mô tả bằng chữ thì hãy cân nhắc.

Cách vẽ BPM

Để tránh sa đà vào chi tiết, bài viết này chỉ giới thiệu sơ lược và đưa ra ví dụ khái quát. Mình đã viết 1 bài hướng dẫn từng cụ thể, chi tiết từng bước để ra được 1 BPMN xài được.

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.

Một đoạn text dài, nhiều thông tin đan chéo nhau đúng không.

Vì ghi theo văn nói, nên sẽ không theo 1 trình tự nhất định, nhiều khi nói cái này thì nhảy sang cái kia. Rồi lâu lâu lại lòi ra 1 “nhân vật” bất ngờ nào đó không báo trước. Đừng có viết vào document. Dev đọc được lại chửi cho.

Bỏ ra tầm 30-45p để “chuyển hóa” nó thành 1 bức ảnh như thế này sẽ nâng tầm giá trị của 1 BA.

Giờ thì đã thấy rõ quy trình này gồm những ai cùng tham gia, thực hiện những hành động gì, theo trình tự nào.

Nhìn vào sơ đồ này, dễ dàng thấy ngay được:

• Các đối tượng tham gia vào quy trình
• Điểm bắt đầu và kết thúc của từng nhóm đối tượng trong quy trình
• Chọn ra 1 action bất kỳ trong bức tranh này cũng thấy có thể suy ngược ra được cần điều kiện gì để action này xảy ra (input), và sau khi nó xảy ra thì trả ra thông tin gì (output)

So sánh 1 chút để thấy được sự ưu việt của sơ đồ quy trình

• Lược bỏ tất cả từ ngữ dư thừa
• Các hành động đều có PIC, input, output rõ ràng
• Sắp xếp và phân loại rất rõ, đưa sơ đồ này cho 1 role bất kỳ trong quy trình, họ có thể thấy được ngay tất cả các action họ phải làm, trình tự và kết quả cần đạt được

Lưu ý:

• Đừng tham lam dồn tất cả thông tin vào 1 sơ đồ BPM. Hãy gói gọn trong 1 hoặc 1/2 trang giấy
• Nếu 1 role nào đó có quá nhiều action cần thực hiện trong 1 quy trình, hãy cố gắng gom nhóm các action đó lại thành 1 quy trình riêng biệt (Sub-Process). Bạn có thể làm rõ các Sub-process đó trong 1 sơ đồ khác. Keep it simple stupid!
• Lưu ý 1 chút về tính thẩm mỹ và các cách sắp xếp, không có đúng hoặc sai trong cái này. Nhưng mục đích của BPM là làm mọi thứ rõ ràng chứ không phải rối hơn. Đừng ẩu!
• Mindset thần thánh 3-levels
  • Mỗi role, hãy cô đọng lại thành 3 hoặc 4 task / Subprocess chính họ cần làm.
  • Chọn ra 3 hoặc 4 logic cốt lõi.
  • Hạn chế thể hiện alternative và exception flow. Chỉ 1 flow vui vẻ đã có thể ngốn hết thời gian rồi. Hãy tách riêng chúng ra.

Đón xem phần 3 trong chuỗi 3 bài tại đây.