BPMN (Business Process Model and Notation) là chuẩn ký hiệu quốc tế để vẽ sơ đồ quy trình nghiệp vụ, do tổ chức OMG (Object Management Group) quản lý, phiên bản hiện dùng phổ biến là BPMN 2.0. Mục tiêu của BPMN là tạo ra một "ngôn ngữ chung" mà người nghiệp vụ đọc hiểu được, đồng thời đủ chặt chẽ để kỹ sư phần mềm triển khai, thậm chí để một hệ thống quản lý quy trình chạy trực tiếp.
Với dự án tự động hoá, BPMN có một giá trị rất thực dụng: buộc mọi người nói rõ ai làm, làm gì, khi nào rẽ nhánh, chờ cái gì, và kết thúc ở đâu. Những câu hỏi mà sơ đồ hộp–mũi tên tự do thường bỏ qua — ví dụ "nếu khách không trả lời trong ba ngày thì sao?" — lại chính là chỗ bot hoặc workflow hay hỏng.
Bài này đi qua lịch sử của chuẩn, bốn nhóm ký hiệu cốt lõi đủ dùng cho phần lớn quy trình, cách vẽ một sơ đồ từng bước, các mức chi tiết khác nhau, và những lỗi hay gặp.
Lịch sử ngắn của chuẩn BPMN
BPMN ra đời để lấp khoảng trống giữa sơ đồ nghiệp vụ và mô hình kỹ thuật. Các mốc chính:
- Đầu thập niên 2000: tổ chức BPMI (Business Process Management Initiative) phát triển một ký hiệu quy trình thống nhất; Stephen A. White (IBM) là người dẫn dắt chính bản đặc tả.
- 2004: BPMN 1.0 được công bố.
- 2005: BPMI sáp nhập vào OMG — tổ chức cũng đang quản lý chuẩn UML — và BPMN trở thành chuẩn của OMG.
- 2011: BPMN 2.0 ra đời, đổi tên đầy đủ thành "Business Process Model and Notation", bổ sung định nghĩa ngữ nghĩa thực thi và định dạng trao đổi bằng XML, giúp mô hình chạy được trên phần mềm và chuyển được giữa các công cụ.
- 2013: BPMN 2.0.1 được chấp nhận thành tiêu chuẩn ISO/IEC 19510.
Điểm đáng chú ý của lịch sử này: BPMN không phải ký hiệu của một hãng. Sơ đồ vẽ đúng chuẩn trên công cụ này về nguyên tắc mở được trên công cụ khác, dù trên thực tế mức tương thích còn tuỳ sản phẩm. Với doanh nghiệp, điều đó có nghĩa tài sản mô hình quy trình không bị khoá vào một nhà cung cấp.
Bốn nhóm ký hiệu cốt lõi
Đặc tả BPMN 2.0 rất dài, nhưng phần lớn quy trình doanh nghiệp chỉ cần một tập nhỏ ký hiệu. Nghiên cứu về cách người dùng thực tế dùng BPMN cũng ghi nhận phần lớn sơ đồ chỉ dùng một phần nhỏ trong tổng số ký hiệu.
| Nhóm | Ký hiệu | Hình dạng | Ý nghĩa |
|---|---|---|---|
| Đối tượng luồng | Sự kiện (event) | Hình tròn: viền mảnh là bắt đầu, viền đậm là kết thúc, viền đôi là sự kiện giữa chừng | Điều gì đó xảy ra: nhận đơn, hết hạn, nhận thư |
| Đối tượng luồng | Hoạt động (activity) | Hình chữ nhật bo góc | Một việc được làm: kiểm tra hồ sơ, gửi báo giá |
| Đối tượng luồng | Cổng rẽ (gateway) | Hình thoi | Điểm rẽ nhánh hoặc hợp nhánh theo điều kiện |
| Đối tượng kết nối | Luồng tuần tự, luồng thông điệp, liên kết | Mũi tên liền, mũi tên nét đứt, đường chấm | Thứ tự công việc; trao đổi giữa các bên; gắn ghi chú hoặc dữ liệu |
| Làn bơi | Pool và lane | Khung chữ nhật lớn chia làn | Pool là một bên tham gia (công ty, khách hàng); lane là vai trò bên trong |
| Tạo tác | Đối tượng dữ liệu, chú thích, nhóm | Hình tờ giấy gấp góc, ngoặc chú thích | Dữ liệu dùng hoặc tạo ra; giải thích thêm |
Ba loại cổng rẽ đáng nắm chắc: cổng loại trừ (XOR) — chỉ đi một nhánh theo điều kiện; cổng song song (AND) — đi tất cả các nhánh cùng lúc và chờ tất cả xong mới hợp lại; cổng bao hàm (OR) — đi một hoặc nhiều nhánh tuỳ điều kiện. Nhầm XOR với AND là lỗi phổ biến nhất và làm sai hẳn logic khi đem đi tự động hoá.
Cách vẽ một sơ đồ BPMN từng bước
Ví dụ xuyên suốt: quy trình tiếp nhận và xử lý đề nghị hoàn tiền của một cửa hàng trực tuyến (ví dụ giả định).
- Xác định ranh giới. Quy trình bắt đầu khi nào (khách gửi yêu cầu hoàn tiền) và kết thúc khi nào (tiền đã chuyển, hoặc yêu cầu bị từ chối và khách được thông báo). Không xác định ranh giới, sơ đồ sẽ lan sang cả quy trình bán hàng và kế toán.
- Liệt kê các bên và vai trò. Pool "Khách hàng" và pool "Cửa hàng"; trong pool cửa hàng có lane chăm sóc khách hàng, kho, kế toán.
- Vẽ luồng chuẩn trước (luồng mà phần lớn yêu cầu đi qua): nhận yêu cầu → kiểm tra điều kiện hoàn tiền → nhận lại hàng → kiểm tra hàng → chuyển tiền → thông báo khách.
- Thêm cổng rẽ tại mỗi quyết định: đủ điều kiện hay không; hàng đạt hay không đạt. Mỗi nhánh ra khỏi cổng loại trừ phải có điều kiện ghi rõ.
- Thêm sự kiện thời gian và ngoại lệ: khách không gửi hàng trong số ngày quy định thì đóng yêu cầu; kế toán không xử lý trong hạn thì nhắc trưởng bộ phận.
- Vẽ luồng thông điệp giữa hai pool: thông báo chấp thuận, hướng dẫn gửi hàng, thông báo đã chuyển tiền. Luồng tuần tự không được đi xuyên qua ranh giới pool.
- Kiểm tra với người làm thật, đi từng nhánh với một trường hợp cụ thể: "đơn này rơi vào nhánh nào, ai làm, bao lâu?".
Một sơ đồ tốt cho quy trình cỡ này thường vừa một trang, khoảng mười lăm đến hai mươi lăm phần tử. Vượt quá nhiều, nên tách một phần thành quy trình con (sub-process) và vẽ riêng.
Ba mức chi tiết: mô tả, phân tích và thực thi
Một nhầm lẫn thường gặp là nghĩ chỉ có một cách vẽ BPMN "đúng". Trên thực tế, các tài liệu hướng dẫn và giới thực hành thường phân biệt ba mức. Mức mô tả dành cho lãnh đạo và người nghiệp vụ: chỉ dùng hoạt động, sự kiện bắt đầu–kết thúc, cổng loại trừ và làn bơi; mục tiêu là thống nhất hiểu biết. Mức phân tích dành cho đội cải tiến quy trình: thêm sự kiện thời gian, ngoại lệ, luồng thông điệp, quy trình con; mục tiêu là tìm điểm nghẽn và thiết kế lại.
Mức thực thi dành cho hệ thống chạy quy trình: mỗi hoạt động phải được gắn loại cụ thể (việc của người, việc của dịch vụ, việc chạy kịch bản), dữ liệu đầu vào–đầu ra, biểu thức điều kiện cho từng nhánh. Ở mức này, sơ đồ thực chất là một chương trình.
Cùng một quy trình có thể cần cả ba bản. Sai lầm là trình bày bản thực thi cho hội đồng quản trị, hoặc đưa bản mô tả cho đội lập trình và kỳ vọng họ tự đoán phần còn thiếu. Trước khi vẽ, hãy hỏi: người đọc sơ đồ này là ai và họ sẽ dùng nó để làm gì?
Lỗi hay gặp khi vẽ BPMN
Các lỗi dưới đây làm sơ đồ khó đọc, hoặc tệ hơn, mô tả sai logic khi đem đi tự động hoá.
| Lỗi | Hậu quả | Cách sửa |
|---|---|---|
| Cổng rẽ không ghi điều kiện | Không biết khi nào đi nhánh nào | Ghi điều kiện ngắn trên mỗi nhánh ra |
| Rẽ bằng cổng song song nhưng hợp bằng cổng loại trừ | Quy trình chạy trùng hoặc treo | Dùng cùng loại cổng để tách và hợp |
| Nhánh không dẫn tới sự kiện kết thúc | Hồ sơ "biến mất" giữa chừng | Mọi nhánh phải kết thúc rõ ràng |
| Đặt tên hoạt động bằng danh từ | "Hoá đơn" không nói làm gì | Dùng động từ + đối tượng: "Kiểm tra hoá đơn" |
| Luồng tuần tự đi xuyên pool | Sai ngữ nghĩa giữa các tổ chức | Dùng luồng thông điệp giữa các pool |
| Một sơ đồ ôm cả công ty | Không ai đọc hết | Tách quy trình con, giữ sơ đồ chính một trang |
| Chỉ vẽ luồng lý tưởng | Bỏ sót ngoại lệ, bot hỏng khi chạy thật | Thêm sự kiện thời gian và nhánh lỗi |
Giới nghiên cứu mô hình hoá quy trình đã đưa ra các hướng dẫn như "Seven Process Modeling Guidelines" (7PMG) của Mendling, Reijers và van der Aalst (2010): dùng ít phần tử nhất có thể, giảm số đường đi qua mỗi phần tử, chỉ một sự kiện bắt đầu và một sự kiện kết thúc khi có thể, mô hình có cấu trúc rõ, tránh cổng bao hàm, đặt tên hoạt động theo dạng động từ–đối tượng, và tách mô hình lớn thành phần nhỏ. Danh sách này đáng in ra dán cạnh bàn người vẽ.
Quy ước nội bộ giúp kho sơ đồ dùng được lâu
Khi doanh nghiệp có hàng chục sơ đồ do nhiều người vẽ, vấn đề không còn là ký hiệu mà là sự nhất quán. Một bộ quy ước ngắn, một hai trang, tiết kiệm rất nhiều thời gian: cách đặt tên quy trình (mã phòng ban, động từ, đối tượng), cách đánh phiên bản và ngày hiệu lực, màu sắc dùng cho bước tự động hoá và bước thủ công, cấp chi tiết tối đa cho sơ đồ chính, nơi lưu và ai được sửa.
Nên quy định thêm một phần "thẻ thông tin" đi kèm mỗi sơ đồ: người sở hữu, mục tiêu quy trình, đầu vào và đầu ra, chỉ số đo lường chính, các hệ thống liên quan, ngày rà soát gần nhất. Thẻ thông tin này chính là điểm nối giữa sơ đồ và các dự án tự động hoá sau này: đội triển khai biết ngay cần hỏi ai và đo cái gì.
BPMN trong dự án tự động hoá
Với dự án RPA, sơ đồ BPMN mức phân tích là tài liệu đầu vào chất lượng hơn hẳn bản mô tả bằng văn xuôi. Nó cho thấy ngay những hoạt động nào hoàn toàn dựa trên quy tắc (ứng viên cho bot), những hoạt động cần phán đoán (giữ cho người), những điểm chờ dài (ứng viên cho workflow nhắc việc) và những nhánh ngoại lệ mà bot phải nhận diện để bàn giao.
Một cách làm hiệu quả là tô màu các hoạt động trên sơ đồ hiện trạng theo ba nhóm: tự động hoá được, tự động hoá một phần, giữ cho người. Sau đó vẽ sơ đồ trạng thái mới với bot xuất hiện như một làn riêng. Hai sơ đồ đặt cạnh nhau là công cụ trao đổi rất tốt với người dùng: họ thấy chính xác bước nào thay đổi, bước nào mình vẫn giữ.
Cần nhớ giới hạn: BPMN mô tả luồng điều khiển rất tốt nhưng mô tả dữ liệu và quy tắc quyết định phức tạp không tốt. Với bảng quy tắc nhiều điều kiện, OMG có chuẩn riêng là DMN (Decision Model and Notation); với dữ liệu, cần mô hình dữ liệu riêng. Ép mọi thứ vào một sơ đồ BPMN là cách nhanh nhất để có một sơ đồ không ai đọc.
Câu hỏi thường gặp
BPMN khác lưu đồ (flowchart) truyền thống thế nào?
Lưu đồ truyền thống có ít ký hiệu và không có quy ước chặt về sự kiện, thông điệp giữa các bên hay ngữ nghĩa thực thi. BPMN có đặc tả chính thức, phân biệt rõ luồng tuần tự với luồng thông điệp, có các loại sự kiện và cổng rẽ định nghĩa chặt, nên cùng một sơ đồ được đọc giống nhau và có thể chạy trên phần mềm.
BPMN có liên quan gì đến UML?
Cả hai đều do OMG quản lý. Biểu đồ hoạt động của UML cũng mô tả luồng công việc nhưng hướng tới người phát triển phần mềm. BPMN hướng tới người nghiệp vụ và mô hình hoá quy trình tổ chức, có làn bơi theo bên tham gia và thông điệp giữa các tổ chức, nên phổ biến hơn trong quản lý quy trình.
Có cần học hết đặc tả BPMN 2.0 không?
Không cần cho phần lớn công việc. Nắm vững sự kiện bắt đầu, kết thúc, sự kiện thời gian, hoạt động, quy trình con, ba loại cổng rẽ, làn bơi và luồng thông điệp là đủ vẽ hầu hết quy trình doanh nghiệp. Các ký hiệu nâng cao chỉ cần khi mô hình được đưa vào hệ thống thực thi.
Nên vẽ quy trình hiện trạng hay quy trình mong muốn trước?
Thường nên vẽ hiện trạng trước, ở mức vừa đủ, để mọi người thống nhất vấn đề và đo được điểm xuất phát. Nhưng đừng sa đà vẽ hiện trạng quá chi tiết vì phần lớn sẽ bị thay đổi. Một nguyên tắc thực dụng là dành thời gian cho hiện trạng ít hơn nhiều so với thiết kế quy trình mới.
Ai trong doanh nghiệp nên chịu trách nhiệm cập nhật sơ đồ quy trình?
Người sở hữu quy trình, thường là trưởng bộ phận chịu trách nhiệm kết quả đầu ra, nên chịu trách nhiệm nội dung; một nhóm quy trình hoặc chuyên viên chất lượng giữ chuẩn ký hiệu và kho lưu. Sơ đồ không có người sở hữu sẽ lỗi thời sau vài tháng và mất giá trị tham chiếu.
DMN dùng khi nào thay cho cổng rẽ BPMN?
Khi quyết định phụ thuộc nhiều điều kiện kết hợp, ví dụ mức phê duyệt theo loại chi phí, số tiền, phòng ban và nhà cung cấp. Vẽ bằng chuỗi cổng rẽ sẽ rối; đặt trong một bảng quyết định DMN được gọi từ một hoạt động BPMN thì gọn, dễ kiểm tra và người nghiệp vụ sửa được.