Hướng dẫn BPMN với Visual Paradigm

1. BPMN là gì

Mô hình và ký hiệu quy trình kinh doanh (BPMN) là một ngôn ngữ trực quan chuẩn hóa để mô tả cách công việc di chuyển qua một quy trình. Nó giúp các bên liên quan trong kinh doanh, các nhà phân tích và các nhóm kỹ thuật thảo luận về cùng một luồng công việc bằng cách sử dụng các ký hiệu thống nhất. BPMN được duy trì bởi Nhóm Quản lý Đối tượng; BPMN 2.0.2 được công bố dưới tiêu chuẩn ISO/IEC 19510.

Sơ đồ BPMN không chỉ là một sơ đồ luồng: các ký hiệu của nó có ý nghĩa xác định, và các quy tắc kết nối của nó phân biệt luồng quy trình với các thông điệp giữa các bên tham gia. Một mô hình hữu ích có thể tài liệu hóa quy trình hiện tại (“hiện trạng”), làm rõ quy trình được đề xuất (“tương lai”), và giúp các nhóm phát hiện các điểm chậm trễ, việc bàn giao, công việc làm lại, hoặc các đường dẫn ngoại lệ bị thiếu.

2. Các khái niệm cốt lõi của BPMN

Các khối xây dựng chính của BPMN là các đối tượng luồng, các đối tượng kết nối, các làn bơi, dữ liệu và các tài liệu bổ trợ.

Sự kiện

Đường viền và ký hiệu của một sự kiện thể hiện vai trò và kích hoạt của nó:

• Sự kiện bắt đầu:Bắt đầu một đường dẫn quy trình.

• Sự kiện trung gian:Xảy ra trong quá trình—ví dụ, một tin nhắn được nhận hoặc bộ đếm thời gian hết hạn.

• Sự kiện kết thúc:Kết thúc một đường dẫn. Các loại sự kiện kết thúc khác nhau có thể chỉ ra các kết quả khác nhau, chẳng hạn như hoàn thành bình thường hoặc lỗi.

• Sự kiện biên:Gắn vào một hoạt động hoặc quy trình con để thể hiện một sự kiện có thể làm gián đoạn hoặc ảnh hưởng đến nó, chẳng hạn như hết thời gian chờ.

Sử dụng một sự kiện tin nhắnkhi quy trình phản hồi với thông tin liên lạc, và một sự kiện bộ đếm thời giankhi thời gian là một phần của quy tắc quy trình, chẳng hạn như thời hạn chót.

Hoạt động

Đặt tên cho các hoạt động với một động từ + tân ngữ, chẳng hạn như “Kiểm tra tồn kho,” “Phê duyệt thanh toán,” hoặc “Gửi xác nhận.” Sử dụng:

• Nhiệm vụcho một bước đơn lẻ.

• Quy trình conkhi một bước có đủ chi tiết để mô hình hóa riêng biệt.

• Hoạt động gọikhi tái sử dụng một quy trình được định nghĩa toàn cục, nếu phương pháp mô hình hóa của bạn hỗ trợ điều đó.

Các ký hiệu nhiệm vụ phổ biến có thể chỉ định loại công việc, chẳng hạn như công việc do người thực hiện, thủ công hoặc tự động. Chỉ thêm chi tiết như vậy khi nó giúp ích cho người đọc hoặc việc triển khai.

Cổng

Chọn một cổng dựa trên logic quy trình—not chỉ dựa trên hình dạng bạn muốn vẽ:

• Loại loại trừ (XOR):Chọn một trong các đường đi ra. Ví dụ: “Còn hàng?” → Có hoặc Không.

• Loại song song (AND):Bắt đầu tất cả các đường đi ra; điểm hợp nhất tương ứng có thể chờ đợi tất cả các đường đi cần thiết.

• Loại bao hàm (OR):Chọn một hoặc nhiều đường đi ra, tùy thuộc vào các điều kiện.

• Dựa trên sự kiện:Đường đi tiếp theo được xác định bởi sự kiện nào xảy ra trước, chẳng hạn như phản hồi thanh toán hoặc thời gian chờ hết hạn.

Gán nhãn các luồng quyết định đi ra bằng các điều kiện, chẳng hạn như Có / Không hoặc Đã phê duyệt / Bị từ chối. Khi một cổng tách một luồng, hãy làm rõ logic hợp nhất. Việc hợp nhất loại loại trừ đưa các đường đi thay thế trở lại với nhau; việc hợp nhất song song đồng bộ hóa các đường đi đã được bắt đầu song song.

Kết nối các đối tượng và bể

Một luồng tuần tự thể hiện thứ tự quy trình và thường nằm trong một bể. Một luồng tin nhắn thể hiện giao tiếp giữa các bể riêng biệt—ví dụ, một khách hàng gửi đơn hàng đến một công ty. Không sử dụng luồng tin nhắn để thể hiện nhiệm vụ nội bộ tiếp theo, hoặc sử dụng luồng tuần tự để mô tả giao tiếp giữa các bên tham gia riêng biệt.

Các bể có thể đại diện cho các bên tham gia độc lập, chẳng hạn như khách hàng, công ty và nhà cung cấp dịch vụ thanh toán. Các làn trong một bể thể hiện vai trò hoặc bộ phận. Hãy giữ các ranh giới trách nhiệm có ý nghĩa: một làn nên làm rõ ai thực hiện công việc, chứ không chỉ đơn thuần là trang trí sơ đồ.

3. Quy trình mô hình hóa thực tế

1. Xác định phạm vi.Xác định kích hoạt, kết quả và ranh giới của quy trình. Ví dụ: “Từ khi nhận đơn hàng đến khi xác nhận giao hàng.”

2. Xác định các bên tham gia và vai trò.Quyết định bên tham gia nào cần bể riêng biệt và trách nhiệm nào thuộc về các làn.

3. Viết đường đi thành công.Liệt kê các bước thông thường theo thứ tự trước khi thêm các cổng và các đường đi ngoại lệ.

4. Thêm các sự kiện và quyết định.Hiển thị các kích hoạt, kết quả, quy tắc kinh doanh và các đường dẫn thay thế có ý nghĩa.

5. Thêm các bàn giao và dữ liệu.Đánh dấu các thông tin liên lạc giữa các bên tham gia và thông tin cần thiết hoặc được tạo ra ở những nơi giúp cải thiện sự hiểu biết.

6. Kiểm tra tính đầy đủ.Theo dõi từng đường dẫn từ điểm bắt đầu đến điểm kết thúc. Xác nhận rằng các cổng (gateways) có điều kiện dễ hiểu và các đường dẫn ngoại lệ không biến mất một cách mơ hồ.

7. Xem xét cùng với người dùng quy trình.Xác thực mô hình với những người thực hiện hoặc nhận công việc. Điều chỉnh khi nó khác với thực tế.

8. Giữ cho sơ đồ dễ đọc.Sử dụng tên gọi thống nhất, giảm thiểu các đường chéo và di chuyển các quy trình con chi tiết vào các sơ đồ riêng biệt khi cần thiết.

Bắt đầu với một mô hình trả lời câu hỏi kinh doanh. Thêm tất cả các ký hiệu BPMN hoặc chi tiết triển khai cùng một lúc thường làm cho sơ đồ khó xem xét hơn.

4. Ví dụ: thực hiện đơn hàng trực tuyến

Phạm vi:Từ khi khách hàng gửi đơn hàng đến khi xác nhận giao hàng. Ví dụ này tập trung vào quy trình của công ty và sử dụng một bể khách hàng riêng biệt để hiển thị đơn hàng đến và xác nhận gửi đi.

Mô tả quy trình

1. Khách hàng gửi đơn hàng.

2. Công ty nhận đơn hàng và kiểm tra tồn kho.

3. Nếu một mặt hàng không có sẵn, công ty thông báo cho khách hàng và kết thúc đường dẫn đơn hàng đó.

4. Nếu mặt hàng có sẵn, công ty xử lý thanh toán.

5. Nếu thanh toán bị từ chối, công ty thông báo cho khách hàng và kết thúc đường dẫn đó.

6. Nếu thanh toán được phê duyệt, kho hàng sẽ chọn và đóng gói đơn hàng.

7. Công ty giao bưu kiện cho đơn vị vận chuyển và gửi xác nhận giao hàng.

Sơ đồ văn bản

Bể khách hàng:
(Bắt đầu) → Gửi đơn hàng ──thông điệp──▶

Bể công ty:
(Bắt đầu thông điệp: nhận đơn hàng)
  → Kiểm tra tồn kho
  → XOR: Có sẵn hàng?
      Không  → Thông báo khách hàng: không có sẵn → (Kết thúc)
      Có → Xử lý thanh toán
             → XOR: Thanh toán được phê duyệt?
                 Không  → Thông báo khách hàng: thanh toán bị từ chối → (Kết thúc)
                 Có → Chọn và đóng gói đơn hàng
                         → Giao bưu kiện cho đơn vị vận chuyển
                         → Gửi xác nhận giao hàng ──thông điệp──▶ Khách hàng
                         → (Kết thúc)

Mã PlantUML tùy chỉnh BPMN (Chỉ được hỗ trợ bởi Trình chỉnh sửa VPasCode)

@startuml
Tiêu đề: Sơ đồ quy trình kinh doanh thực hiện đơn hàng
<style>
    element { MaximumWidth 160 }
    start   { Backgroundcolor #00695C }
    stop    { Backgroundcolor #C2185B }
    activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
    diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
    arrow   { LineColor #424242; Fontcolor #000000 }
    swimlane{ Fontcolor #000000; FontSize 14 }
</style>

|#F0F8FF|Khách hàng|
start
:<<SendTask>>
Gửi đơn hàng;

|#E8F5E9|Công ty|
:<<ReceiveTask>>
Đơn hàng đã nhận;
:<<UserTask>>
Kiểm tra tồn kho;
if (Có sẵn hàng?) then (có)
  :<<ServiceTask>>
  Xử lý thanh toán;
  if (Thanh toán được phê duyệt?) then (có)
    :<<ManualTask>>
    Chọn và đóng gói đơn hàng;
    :<<SendTask>>
    Giao bưu kiện cho đơn vị vận chuyển;
    :<<SendTask>>
    Gửi xác nhận giao hàng;
  else (không)
    :<<SendTask>>
    Thông báo khách hàng: thanh toán bị từ chối;
  endif
else (không)
  :<<SendTask>>
  Thông báo khách hàng: không có sẵn;
endif
stop
@enduml

Sử dụng luồng tuần tựcho các bước nội bộ của công ty và luồng thông điệpgiữa các bể Khách hàng và Công ty. Gán nhãn các luồng đi ra của mỗi cổng XOR với các điều kiện tương ứng. Trong Visual Paradigm, các câu hỏi “Còn hàng?” và “Thanh toán được phê duyệt?” có thể được đặt làm nhãn cổng, trong khi các mũi tên đi ra mang nhãn “Có” và “Không.”

Các mở rộng khả thi:Thêm sự kiện biên giới thời gian cho quy trình thanh toán nếu doanh nghiệp có thời hạn thanh toán; thêm đường dẫn ngoại lệ cho trường hợp thất bại khi bàn giao cho đơn vị vận chuyển; hoặc mô hình hóa việc chọn hàng và đóng gói như một quy trình con nếu nó cần một quy trình chi tiết riêng.

5. Xây dựng mô hình trong Visual Paradigm

Visual Paradigm cung cấp công cụ mô hình hóa BPMN 2.0 và hỗ trợ phân tích chi tiết quy trình con, do đó một quy trình cấp cao có thể liên kết với sơ đồ quy trình chi tiết hơn. Các tính năng BPMN của nó cũng bao gồm tài liệu hóa các quy trình làm việc và mô hình hóa quy trình hiện tại và quy trình mục tiêu.

Một trình tự xây dựng thực tế:

1. Tạo một Sơ đồ Quy trình Kinh doanh BPMNtrong Visual Paradigm.

2. Thêm một bể Khách hàng và một bể Công ty; chia bể Công ty thành các làn như Dịch vụ Khách hàng, Kho hàng và Vận chuyển nếu các trách nhiệm đó quan trọng.

3. Đặt sự kiện khởi đầu và các hoạt động, sau đó thêm các cổng tồn kho và thanh toán.

4. Vẽ các luồng tuần tự trong bể Công ty; sử dụng luồng thông điệp cho các trao đổi với Khách hàng.

5. Gán nhãn các nhiệm vụ và đường dẫn điều kiện bằng ngôn ngữ đơn giản. Chỉ thêm các đối tượng dữ liệu, chẳng hạn như Đơn hàng hoặc Kết quả Thanh toán, ở những nơi giúp người đọc hiểu rõ quy trình.

6. Sắp xếp sơ đồ sao cho luồng chính được đọc một cách nhất quán—thường là từ trái sang phải—và giảm thiểu các kết nối cắt nhau.

7. Xem xét sơ đồ cùng với các bên liên quan. Nếu chi tiết của một bước làm mờ đi đường dẫn chính, hãy cân nhắc đặt chi tiết đó trong một sơ đồ quy trình con.

8. Lưu và chia sẻ mô hình ở định dạng và không gian làm việc phù hợp với nhóm của bạn.

Visual Paradigm quảng bá các tính năng mô hình hóa sơ đồ BPMN, phân tích chi tiết quy trình, tài liệu hóa quy trình làm việc và mô hình hóa hiện tại/mục tiêu. Khả năng sử dụng các tính năng cụ thể có thể phụ thuộc vào phiên bản.

6. Các lỗi mô hình hóa phổ biến

• Sử dụng kết nối sai:luồng tuần tự là thứ tự quy trình nội bộ; luồng thông điệp là giao tiếp giữa các bên tham gia.

• Sử dụng cổng mà không có logic rõ ràng:Gán nhãn cho quyết định và các điều kiện đầu ra của nó.

• Xử lý mọi hành động như một bể riêng biệt:sử dụng làn cho các trách nhiệm trong một người tham gia; sử dụng các bể riêng biệt cho các người tham gia khác nhau.

• Để các đường dẫn không rõ ràng:hiển thị những gì xảy ra đối với các từ chối, quá thời gian, thiếu thông tin và các ngoại lệ liên quan khác.

• Quá tải một sơ đồ:sử dụng các quy trình con để tách công việc chi tiết khỏi phần tổng quan.

• Mô hình hóa lý tưởng thay vì thực tế:ghi chép chính xác quy trình hiện tại trước khi đề xuất các cải tiến.

• Thêm chi tiết mà không có mục đích:bao gồm dữ liệu, sự kiện và các dấu hiệu nhiệm vụ khi chúng trả lời một câu hỏi về mô hình hóa hoặc rà soát.

7. Danh sách kiểm tra rà soát nhanh

• Sơ đồ có điểm bắt đầu và kết thúc rõ ràng cho mỗi đường dẫn liên quan không?

• Người đọc có thể xác định ai thực hiện mỗi hoạt động không?

• Các quyết định và các điều kiện đầu ra có rõ ràng không?

• Dòng tuần tự và dòng tin nhắn có được sử dụng một cách phù hợp không?

• Các ngoại lệ và kết quả thay thế có được biểu diễn không?

• Sơ đồ có dễ đọc ở kích thước xem dự định không?

• Những người thực hiện quy trình đã xác nhận rằng nó chính xác chưa?