BPMN so với Lưu đồ: Khi nào và Tại sao nên sử dụng BPMN cho người mới bắt đầu

Lưu đồ và sơ đồ BPMN đều thể hiện cách công việc chuyển từ bước này sang bước khác. Sự khác biệt chủ yếu nằm ở mục đích và độ chính xác:

Một lưu đồ là một sơ đồ đa năng để thể hiện logic, các bước và các quyết định.
BPMN, hay Mô hình và Ký hiệu Quy trình Kinh doanh, là một ngôn ngữ chuẩn hóa được thiết kế đặc biệt để mô hình hóa các quy trình kinh doanh, trách nhiệm, sự kiện, thông điệp, dữ liệu và tự động hóa.

Lưu đồ thường là cách nhanh nhất để giải thích một thủ tục đơn giản. BPMN trở nên hữu ích hơn khi một quy trình liên quan đến nhiều người, phòng ban, tổ chức, các trường hợp ngoại lệ, thời hạn hoặc hệ thống phần mềm.

BPMN được duy trì dưới dạng một bản đặc tả chính thức bởi Nhóm Quản lý Đối tượng (Object Management Group). Ký hiệu của nó được thiết kế để dễ hiểu đối với các bên liên quan trong kinh doanh, đồng thời vẫn đủ chính xác để hỗ trợ việc triển khai kỹ thuật. Bản đặc tả chính thức hiện được sử dụng phổ biến là BPMN 2.0.2.

1. Lưu đồ là gì?

Lưu đồ là biểu diễn trực quan của một chuỗi các bước. Nó sử dụng các hình dạng đơn giản được nối với nhau bằng mũi tên để thể hiện cách một nhiệm vụ hoặc quyết định được thực hiện.

Một lưu đồ điển hình bao gồm:

Hình bầu dục: Bắt đầu hoặc kết thúc
Hình chữ nhật: Quy trình hoặc hoạt động
Hình thoi: Quyết định
Mũi tên: Hướng dòng chảy
Hình bình hành: Đầu vào hoặc đầu ra
Hình tài liệu: Tài liệu hoặc báo cáo

Ví dụ, một lưu đồ hoàn trả chi phí cơ bản có thể trông như sau:

Bắt đầu
  ↓
Nhân viên nộp báo cáo chi phí
  ↓
Quản lý xem xét báo cáo
  ↓
Có được phê duyệt không?
 ├── Không → Trả báo cáo cho nhân viên
 └── Có → Bộ phận Tài chính phát hành thanh toán
  ↓
Kết thúc

Lưu đồ dễ tạo và dễ hiểu vì chúng sử dụng một số lượng nhỏ các ký hiệu quen thuộc. Chúng hữu ích cho việc:

Giải thích một thủ tục đơn giản
Tài liệu hóa một thuật toán
Mô tả các bước khắc phục sự cố
Lập bản đồ quy trình làm việc cá nhân hoặc của phòng ban
Đào tạo nhân viên
Hiển thị một chuỗi quyết định cơ bản

Hạn chế chính là sơ đồ luồng truyền thống không phải lúc nào cũng thể hiện rõ ràng ai thực hiện mỗi nhiệm vụ, các tổ chức khác nhau giao tiếp như thế nào, hoặc điều gì xảy ra khi các sự kiện làm gián đoạn quy trình bình thường.

2. BPMN là gì?

BPMN là viết tắt của Mô hình và ký hiệu quy trình kinh doanh. Đây là một ký hiệu chuẩn hóa để mô tả các quy trình kinh doanh một cách thống nhất.

Sơ đồ BPMN có thể biểu diễn:

Các hoạt động và nhiệm vụ
Các sự kiện bắt đầu, trung gian và kết thúc
Các quyết định và logic phân nhánh
Công việc song song
Người tham gia và trách nhiệm
Giao tiếp giữa các phòng ban hoặc tổ chức
Tin nhắn
Dữ liệu đầu vào và đầu ra
Bộ đếm thời gian, lỗi, hủy bỏ và tăng cấp
Các quy trình con có thể tái sử dụng
Các hoạt động của con người và tự động hóa

BPMN dựa trên các khái niệm sơ đồ luồng, nhưng nó bổ sung một từ vựng phong phú hơn cho các hoạt động kinh doanh. Các danh mục cốt lõi của nó bao gồm các đối tượng luồng, các đối tượng kết nối, các làn bơi và các tài liệu.

Một quy trình BPMN đơn giản hóa có thể được mô tả như sau:

Khách hàng gửi đơn hàng
        ↓
Hệ thống bán hàng ghi nhận đơn hàng
        ↓
Kho kiểm tra tồn kho
        ↓
Hàng có sẵn không?
 ├── Không → Thông báo cho khách hàng
 └── Có → Chọn và đóng gói đơn hàng
                 ↓
           Đơn vị vận chuyển giao hàng

Trong một sơ đồ BPMN thực tế, mỗi người tham gia có thể xuất hiện trong một bể hoặc làn riêng biệt, và giao tiếp giữa họ có thể được biểu diễn bằng các luồng thông báo.

3. BPMN so với Lưu đồ: Nhìn tổng quan

Đặc điểm	Lưu đồ	BPMN
Mục đích chính	Thể hiện logic hoặc trình tự chung	Mô hình hóa quy trình kinh doanh
Chuẩn hóa	Thường không chính thức hoặc phụ thuộc vào công cụ	Ký hiệu mô hình hóa quốc tế chính thức
Đường cong học tập	Thấp	Trung bình
Số lượng ký hiệu	Bộ nhỏ	Từ vựng chuyên biệt lớn hơn
Vai trò và trách nhiệm	Thường bị giới hạn	Được biểu diễn rõ ràng bằng các bể và làn
Giao tiếp liên tổ chức	Khó thể hiện chính xác	Được biểu diễn bằng các luồng thông báo
Ngoại lệ và gián đoạn	Thường được đơn giản hóa	Sự kiện có thể biểu diễn bộ đếm thời gian, lỗi, thông báo và các vụ việc được nâng cấp
Hoạt động song song	Có thể nhưng thường không rõ ràng	Được hỗ trợ bằng các cổng song song
Hỗ trợ tự động hóa	Hạn chế	Có thể chi tiết đủ để hỗ trợ triển khai
Sử dụng tốt nhất	Thủ tục và logic đơn giản	Quy trình phức tạp, hợp tác và có thể lặp lại
Đối tượng điển hình	Người dùng chung, sinh viên, nhóm	Chuyên viên phân tích, chủ sở hữu quy trình, nhà phát triển, quản lý
Mức độ chi tiết	Thấp đến trung bình	Trung bình đến rất cao

4. Sự khác biệt cốt lõi: Logic chung so với ngữ nghĩa quy trình kinh doanh

Sự phân biệt quan trọng nhất là sơ đồ luồng chủ yếu trả lời câu hỏi:

“Điều gì sẽ xảy ra tiếp theo?”

BPMN có thể trả lời một số câu hỏi bổ sung:

Ai thực hiện mỗi hoạt động?
Bộ phận hoặc tổ chức nào tham gia?
Tương tác này là nội bộ hay bên ngoài?
Bước tiếp theo có phải do thông báo, bộ đếm thời gian, lỗi hoặc điều kiện gây ra không?
Các hoạt động có thể diễn ra song song không?
Dữ liệu nào là cần thiết?
Điều gì sẽ xảy ra nếu quy trình thất bại?
Nhiệm vụ nào được thực hiện bởi con người, hệ thống hoặc quy tắc?
Quy trình này có thể được tự động hóa hoặc giám sát không?

Ví dụ, một sơ đồ luồng có thể nói:

Xem xét đơn → Phê duyệt đơn → Gửi xác nhận

Một mô hình BPMN có thể phân biệt:

Khách hàng nộp đơn.
Nhóm dịch vụ khách hàng xác thực đơn.
Một hệ thống tự động kiểm tra thông tin tín dụng.
Một quản lý phê duyệt các đơn xin trên một mức nhất định.
Một bộ đếm thời gian kích hoạt lời nhắc sau ba ngày làm việc.
Một thông báo được gửi đến khách hàng.
Một đường dẫn lỗi xử lý tài liệu bị thiếu.

Sơ đồ luồng truyền đạt phác thảo. BPMN truyền đạt cấu trúc vận hành.

5. Các yếu tố chính của BPMN mà người mới cần biết

BPMN chứa nhiều ký hiệu, nhưng người mới chỉ cần một bộ cốt lõi nhỏ ban đầu.

Sự kiện

Sự kiện đại diện cho điều gì đó xảy ra thay vì điều gì đó ai đó làm.

Chúng được vẽ dưới dạng hình tròn.

Các loại phổ biến bao gồm:

Sự kiện bắt đầu:Bắt đầu một quy trình
Sự kiện trung gian:Xảy ra trong một quy trình
Sự kiện kết thúc:Hoàn thành một quy trình
Sự kiện tin nhắn:Một tin nhắn được nhận hoặc gửi
Sự kiện bộ đếm thời gian:Có liên quan đến thời hạn hoặc thời gian đã lên lịch
Sự kiện lỗi:Một lỗi xảy ra
Sự kiện tăng cấp:Một vấn đề cần sự chú ý ở cấp cao hơn

Ví dụ:

Một khách hàng đặt hàng.
Thời hạn thanh toán hết hạn.
Một email được nhận.
Xảy ra lỗi hệ thống.

Hoạt động

Hoạt động đại diện cho công việc đang được thực hiện. Chúng được vẽ dưới dạng hình chữ nhật bo tròn.

Chúng có thể là:

Nhiệm vụ: Đơn vị công việc riêng lẻ
Quy trình con: Nhóm các hoạt động liên quan
Nhiệm vụ người dùng: Công việc do một người hoàn thành thông qua hệ thống
Nhiệm vụ dịch vụ: Công việc được thực hiện tự động bởi phần mềm
Nhiệm vụ thủ công: Công việc được thực hiện mà không có sự hỗ trợ của hệ thống
Nhiệm vụ quy tắc kinh doanh: Công việc được xác định bởi một quy tắc kinh doanh hoặc dịch vụ ra quyết định

Đối với người mới bắt đầu, ý tưởng quan trọng nhất rất đơn giản:

Sự kiện xảy ra; hoạt động được thực hiện.

Cổng

Cổng kiểm soát cách quy trình phân nhánh hoặc hợp nhất. Chúng được vẽ dưới dạng hình thoi.

Các loại cổng phổ biến bao gồm:

Cổng loại trừ: Chỉ một đường dẫn được chọn
Cổng song song: Nhiều đường dẫn xảy ra đồng thời
Cổng bao gồm: Một hoặc nhiều đường dẫn có thể được chọn
Cổng dựa trên sự kiện: Đường dẫn tiếp theo phụ thuộc vào sự kiện nào xảy ra trước

Ví dụ về quyết định loại trừ:

Đã nhận thanh toán?
 ├── Có → Giao hàng
 └── Không → Gửi nhắc nhở thanh toán

Ví dụ về công việc song song:

Đơn hàng được phê duyệt
      ↓
 ┌───────────────┬────────────────┐
 │               │                │
Đóng gói đơn hàng   Lập hóa đơn   Thông báo cho khách hàng
 │               │                │
 └───────────────┴────────────────┘
      ↓
Đơn hàng sẵn sàng để giao

Luồng trình tự

Mũi tên liền nét thể hiện thứ tự mà các hoạt động, sự kiện và cổng xảy ra trong cùng một quy trình.

Nhiệm vụ A → Nhiệm vụ B → Nhiệm vụ C

Luồng thông báo

Mũi tên nét đứt biểu thị sự giao tiếp giữa các bên tham gia hoặc các bể (pool) riêng biệt.

Ví dụ:

Khách hàng ──thông báo──> Công ty
Công ty ──xác nhận──> Khách hàng

Luồng thông báo khác với luồng trình tự:

Luồng trình tự:Thể hiện thứ tự công việc trong một quy trình
Luồng thông báo:Thể hiện sự giao tiếp giữa các bên tham gia

Bể (Pools) và Làn (Lanes)

Các làn (swimlanes) tổ chức công việc theo bên tham gia hoặc trách nhiệm.

Một bể (pool)thường đại diện cho một bên tham gia, tổ chức, thực thể kinh doanh hoặc quy trình độc lập.
Một làn (lane)chia một bể thành các vai trò, nhóm, phòng ban hoặc hệ thống.

Ví dụ:

Làn Khách hàng:     Gửi đơn hàng ─────────────── Nhận xác nhận
                         │                              ↑
Làn Bán hàng:            Xem xét đơn hàng ─────── Gửi xác nhận

Bể (Pools) và Làn (Lanes) trả lời một trong những câu hỏi quan trọng nhất về quy trình:

Ai chịu trách nhiệm cho bước này?

Đối tượng dữ liệu và chú thích

Các đối tượng dữ liệu thể hiện thông tin được sử dụng hoặc tạo ra bởi một hoạt động.

Ví dụ:

Đơn xin việc
Hóa đơn
Hợp đồng
Hồ sơ khách hàng
Nhãn vận chuyển

Ghi chú thêm văn bản giải thích mà không làm thay đổi logic quy trình.

6. Khi nào sơ đồ dòng chảy là lựa chọn tốt hơn

Sử dụng sơ đồ dòng chảy khi quy trình đơn giản, tuyến tính hoặc chủ yếu liên quan đến các quyết định.

Sơ đồ dòng chảy thường là đủ khi:

Chỉ có một người tham gia chính
Quy trình chỉ có vài bước
Trách nhiệm không cần được nhấn mạnh
Không có tương tác phức tạp với các bên bên ngoài
Sơ đồ dùng để giải thích nhanh
Quy trình đang được khám phá một cách không chính thức
Bạn đang tài liệu hóa một thuật toán hoặc quy trình khắc phục sự cố
Đối tượng của bạn không quen thuộc với BPMN

Ví dụ, “Cách đặt lại mật khẩu” có thể được biểu diễn tốt hơn bằng một sơ đồ dòng chảy đơn giản:

Bắt đầu
  ↓
Nhập tên đăng nhập
  ↓
Tìm thấy tài khoản?
 ├── Không → Hiển thị lỗi
 └── Có → Gửi email đặt lại
                ↓
          Người dùng tạo mật khẩu
                ↓
               Kết thúc

Sử dụng BPMN cho quy trình này có thể thêm độ phức tạp không cần thiết, trừ khi mục đích là mô hình hóa toàn bộ hoạt động dịch vụ, bao gồm xác minh danh tính, thông báo, tác vụ hệ thống, xử lý escalations và hồ sơ kiểm toán.

7. Khi nào BPMN là lựa chọn tốt hơn

Sử dụng BPMN khi bạn cần mô hình hóa một quy trình kinh doanh thực tế thay vì chỉ mô tả một chuỗi.

BPMN đặc biệt hữu ích khi một quy trình có:

Nhiều phòng ban
Nhiều vai trò hoặc người tham gia
Khách hàng, nhà cung cấp, cơ quan quản lý hoặc đối tác
Việc bàn giao giữa các nhóm
Các hoạt động song song
Thông điệp bên ngoài
Đồng hồ bấm giờ hoặc thời hạn
Xử lý lỗi hoặc ngoại lệ
Các cấp phê duyệt
Các tác vụ hệ thống tự động
Yêu cầu tuân thủ
Các nỗ lực cải tiến quy trình lặp lại
Một mục tiêu tương lai của tự động hóa quy trình làm việc

Các trường hợp sử dụng BPMN điển hình bao gồm:

Phê duyệt đơn mua hàng
Xử lý hồ sơ vay vốn
Yêu cầu bồi thường bảo hiểm
Quy trình hội nhập nhân viên
Chuyển cấp hỗ trợ khách hàng
Xử lý hóa đơn
Trả lại sản phẩm
Chuyển tuyến chăm sóc sức khỏe
Xem xét hợp đồng
Thực hiện giao hàng
Báo cáo quy định
Quy trình triển khai phần mềm

Một quy tắc hữu ích là:

Nếu quy trình vượt qua ranh giới—giữa con người, nhóm, hệ thống hoặc tổ chức—thì BPMN thường đáng để xem xét.

8. Tại sao sử dụng BPMN?

Ngôn ngữ chung

Các nhóm khác nhau thường mô tả cùng một quy trình theo những cách khác nhau. Một quản lý kinh doanh có thể nói về việc phê duyệt, một nhà phát triển nói về các dịch vụ, và một nhân viên nói về các nhiệm vụ hàng ngày.

BPMN cung cấp một ngôn ngữ trực quan chung giúp các nhóm này thảo luận về cùng một quy trình. Mục tiêu thiết kế của nó là dễ sử dụng cho các bên liên quan trong kinh doanh đồng thời đủ chính xác để chuyển đổi thành các thành phần quy trình phần mềm.

Trách nhiệm rõ ràng

Các làn thể hiện trách nhiệm một cách rõ ràng.

Thay vì hiển thị:

Xem xét đơn → Phê duyệt đơn → Tạo tài khoản

BPMN có thể hiển thị:

Khách hàng nộp đơn
Bộ phận chăm sóc khách hàng xác minh thông tin
Nhóm tín dụng thực hiện đánh giá
Quản lý phê duyệt ngoại lệ
Hệ thống IT tạo tài khoản

Điều này có thể làm lộ ra công việc trùng lặp, quyền sở hữu không rõ ràng và các bước chuyển giao không cần thiết.

Phân tích ngoại lệ tốt hơn

Nhiều quy trình thực tế không tuân theo con đường thành công. BPMN giúp việc mô hình hóa trở nên dễ dàng hơn:

Thông tin thiếu sót
Đơn bị từ chối
Hạn chót quá hạn
Thanh toán thất bại
Lỗi hệ thống
Hủy bỏ
Vấn đề được khách hàng nâng cấp
Bồi thường hoặc hành động khắc phục

Sơ đồ dòng chảy có thể hiển thị các ngoại lệ, nhưng BPMN cung cấp các loại sự kiện chuyên biệt và quy ước để biểu diễn chúng rõ ràng hơn.

Hỗ trợ tự động hóa

Mô hình BPMN có thể chứa đủ chi tiết để hướng dẫn việc triển khai quy trình làm việc. Không phải sơ đồ BPMN nào cũng có thể thực thi được, nhưng BPMN phù hợp hơn sơ đồ dòng chảy cơ bản khi mô hình có thể sau này được sử dụng để cấu hình hoặc thiết kế một quy trình tự động.

Ví dụ, một nhà thiết kế quy trình có thể phân biệt giữa:

Một nhiệm vụ do nhân viên thực hiện
Một nhiệm vụ do dịch vụ tự động thực hiện
Một quyết định được đánh giá bởi quy tắc kinh doanh
Một tin nhắn nhận được từ hệ thống khác
Bộ hẹn giờ kích hoạt một hành động

Cải thiện quy trình được nâng cao

Sơ đồ BPMN có thể giúp xác định:

Nút cổ chai
Chuỗi phê duyệt dài
Nhập liệu dữ liệu lặp lại
Các cuộc phê duyệt không cần thiết
Các tác vụ thủ công phù hợp để tự động hóa
Thiếu các đường dẫn xử lý ngoại lệ
Việc bàn giao quá mức
Quyền sở hữu không rõ ràng
Sự chậm trễ do các bên thứ ba gây ra

Điều này khiến BPMN có giá trị không chỉ trong việc tài liệu hóa quy trình mà còn trong việc phân tích và thiết kế lại chúng.

9. Những nhược điểm của BPMN

BPMN rất mạnh mẽ, nhưng không phải lúc nào cũng là lựa chọn đúng đắn.

Nó có đường cong học tập dốc hơn

Sơ đồ luồng thường có thể được hiểu ngay lập tức. BPMN yêu cầu người dùng học các phân biệt như:

Luồng tuần tự so với luồng thông điệp
Sự kiện so với hoạt động
Hồ so với làn
Cổng loại trừ so với cổng song song
Sự kiện làm gián đoạn so với sự kiện không làm gián đoạn
Sự kiện bắt so với sự kiện ném

Sơ đồ có thể trở nên lộn xộn

Một sơ đồ BPMN lớn có thể chứa hàng chục ký hiệu và các đường cắt nhau. Các mô hình được thiết kế kém có thể khó hiểu hơn một sơ đồ luồng đơn giản.

Độ chính xác có thể tạo ra sự tự tin sai lầm

Việc sử dụng các ký hiệu BPMN không tự động làm cho mô hình quy trình trở nên chính xác. Mô hình vẫn phụ thuộc vào thông tin chính xác từ chủ sở hữu quy trình và các chuyên gia về lĩnh vực.

Không phải mọi đối tượng đều cần chi tiết đầy đủ

Các quản lý cấp cao có thể muốn một cái nhìn tổng quan ở mức độ cao về quy trình, trong khi một nhà phát triển quy trình làm việc có thể cần thông tin chi tiết về nhiệm vụ và ngoại lệ. Một sơ đồ hiếm khi phục vụ cả hai mục đích một cách hoàn hảo.

Nó có thể bị lạm dụng

Một thủ tục nội bộ gồm năm bước không nhất thiết cần các sự kiện thông điệp, nhiều hồ và các quy trình con lồng nhau. Ký hiệu phải phù hợp với vấn đề.

10. Hướng dẫn ra quyết định thực tế

Sử dụng các câu hỏi sau để chọn giữa sơ đồ luồng và BPMN:

Có bao nhiêu người tham gia?
- Một người hoặc một nhóm: sơ đồ luồng có thể là đủ.
- Nhiều nhóm hoặc tổ chức: BPMN phù hợp hơn.
Trách nhiệm có quan trọng không?
- Nếu không, hãy sử dụng sơ đồ quy trình.
- Nếu có, hãy sử dụng các làn hoặc các bể trong BPMN.
Có thông tin liên lạc bên ngoài không?
- Nếu không, cả hai ký hiệu đều có thể phù hợp.
- Nếu có, BPMN có thể phân biệt thông điệp với luồng quy trình nội bộ.
Có bộ đếm thời gian, lỗi hoặc quy trình xử lý sự cố không?
- Nếu không, sơ đồ quy trình có thể là đủ.
- Nếu có, BPMN cung cấp các công cụ mô hình hóa rõ ràng hơn.
Quy trình có được tự động hóa không?
- Nếu không, sơ đồ quy trình có thể phù hợp cho một quy trình đơn giản.
- Nếu có, BPMN thường là nền tảng tốt hơn.
Quy trình có cần được tái sử dụng như một tiêu chuẩn chính thức không?
- Nếu không, hãy sử dụng ký hiệu đơn giản nhất mà đối tượng của bạn hiểu.
- Nếu có, BPMN mang lại sự nhất quán cao hơn giữa các sơ đồ và công cụ.
Trình độ kỹ năng của đối tượng của bạn là gì?
- Đối tượng chung: bắt đầu với một sơ đồ quy trình đơn giản hoặc BPMN ở mức độ cao.
- Các nhà phân tích và đội ngũ kỹ thuật: sử dụng BPMN với mức độ chi tiết phù hợp.

11. Phương pháp mô hình hóa BPMN thân thiện với người mới bắt đầu

Bước 1: Xác định ranh giới của quy trình

Quyết định nơi quy trình bắt đầu và kết thúc.

Ví dụ:

Bắt đầu: Khách hàng gửi yêu cầu hỗ trợ
Kết thúc: Khách hàng nhận được giải pháp

Tránh cố gắng mô hình hóa toàn bộ tổ chức cùng một lúc.

Bước 2: Xác định các bên tham gia

Liệt kê những người, nhóm, tổ chức và hệ thống liên quan.

Ví dụ:

Khách hàng
Nhân viên hỗ trợ
Đội ngũ hỗ trợ kỹ thuật
Hệ thống tính phí
Quản lý dịch vụ

Những yếu tố này có thể trở thành các bể (pool) hoặc làn (lane).

Bước 3: Viết trước đường đi thành công (Happy Path)

Ghi lại quy trình bình thường mà không có ngoại lệ.

Tiếp nhận yêu cầu
  ↓
Phân loại yêu cầu
  ↓
Điều tra vấn đề
  ↓
Giải quyết vấn đề
  ↓
Thông báo cho khách hàng
  ↓
Đóng yêu cầu

Điều này cung cấp cho bạn một nền tảng rõ ràng trước khi thêm các yếu tố phức tạp.

Bước 4: Thêm sự kiện bắt đầu và kết thúc

Mọi quy trình BPMN hoàn chỉnh đều phải có điểm bắt đầu và kết thúc rõ ràng.

Ví dụ:

Bắt đầu: Đã nhận tin nhắn
Bắt đầu: Đã đến thời gian hẹn
Bắt đầu: Khách hàng nộp biểu mẫu
Kết thúc: Hồ sơ đã được đóng
Kết thúc: Yêu cầu bị từ chối
Kết thúc: Thanh toán đã hoàn tất

Bước 5: Phân công công việc cho các bên tham gia

Đặt mỗi hoạt động vào làn (lane) phù hợp.

Ví dụ:

Khách hàng:       Nộp yêu cầu ───────────── Nhận giải pháp
Hỗ trợ:                    Phân loại ─ Điều tra ─ Giải quyết
Hệ thống:                                      Gửi thông báo

Bước 6: Thêm cổng quyết định (Gateway)

Sử dụng cổng loại trừ (exclusive gateway) khi chỉ một con đường duy nhất cần được thực hiện.

Vấn đề đã được giải quyết?
 ├── Không → Chuyển cấp
 └── Có → Thông báo cho khách hàng

Đừng sử dụng cổng chỉ vì tên của một nhiệm vụ có chứa câu hỏi. Hãy sử dụng khi quy trình thực sự phân nhánh.

Bước 7: Thêm công việc song song một cách cẩn thận

Sử dụng cổng song song khi các hoạt động thực sự có thể diễn ra cùng lúc.

Ví dụ, sau khi đơn hàng được phê duyệt:

Dự trữ hàng tồn kho
Tạo hóa đơn
Thông báo kho

Nếu một hoạt động phải diễn ra trước hoạt động khác, đừng mô hình hóa chúng song song.

Bước 8: Thêm tin nhắn và dữ liệu

Hiển thị tin nhắn khi các bên tham gia giao tiếp.

Ví dụ:

Khách hàng gửi đơn đăng ký
Nhà cung cấp gửi thông báo vận chuyển
Hệ thống gửi email phê duyệt

Thêm đối tượng dữ liệu khi thông tin quan trọng đối với hoạt động.

Bước 9: Thêm các trường hợp ngoại lệ

Đặt câu hỏi:

Nếu thông tin bắt buộc bị thiếu thì sao?
Nếu khách hàng không phản hồi thì sao?
Nếu thanh toán thất bại thì sao?
Nếu thời hạn hết hạn thì sao?
Nếu hệ thống không khả dụng thì sao?
Nếu nhân viên từ chối yêu cầu thì sao?

Chỉ mô hình hóa các trường hợp ngoại lệ có ý nghĩa đối với việc hiểu hoặc cải thiện quy trình.

Bước 10: Xem lại sơ đồ cùng với chủ sở hữu quy trình

Một sơ đồ nên được xem lại bởi những người thực hiện công việc. Họ có thể xác định:

Các bước bị thiếu
Trách nhiệm không chính xác
Các giải pháp thay thế không chính thức
Các trường hợp ngoại lệ không được ghi lại trong quy trình
Sự chậm trễ và các phê duyệt không cần thiết

12. Ví dụ: Phiên bản sơ đồ dòng chảy so với phiên bản BPMN

Sơ đồ dòng chảy đơn giản

Giả sử một khách hàng trả lại sản phẩm:

Bắt đầu
  ↓
Khách hàng yêu cầu trả lại
  ↓
Việc trả hàng có đủ điều kiện?
 ├── Không → Từ chối yêu cầu
 └── Có → Gửi nhãn trả hàng
                ↓
          Nhận hàng đã trả lại
                ↓
          Xử lý hoàn tiền
                ↓
               Kết thúc

Điều này dễ hiểu và có thể đủ dùng cho việc đào tạo hoặc xem xét tổng quan nhanh.

Phiên bản định hướng BPMN

Một mô hình BPMN chi tiết hơn sẽ phân biệt các bên tham gia:

Khách hàng

Yêu cầu trả lại
đóng gói sản phẩm
Gửi sản phẩm

Dịch vụ khách hàng

Xác minh yêu cầu trả lại
Phê duyệt hoặc từ chối yêu cầu trả lại
Gửi hướng dẫn trả lại

Kho

Nhận sản phẩm
Kiểm tra tình trạng

Tài chính

Xử lý hoàn tiền

Hệ thống

Gửi xác nhận
Cập nhật tồn kho
Ghi nhận hoàn tiền

Mô hình cũng có thể biểu diễn:

Một tin nhắn từ khách hàng
Bộ đếm thời gian cho thời hạn trả lại
Cổng dựa trên tình trạng sản phẩm
Lỗi nếu không nhận được hàng
Các hoạt động tồn kho và hoàn tiền song song
Một tin nhắn xác nhận hoàn tiền

Sơ đồ luồng giải thích logic tổng quát. BPMN giải thích sự hợp tác vận hành.

13. Những lỗi phổ biến của người mới bắt đầu

Lỗi 1: Sử dụng mọi ký hiệu BPMN

Người mới đôi khi cố gắng sử dụng càng nhiều ký hiệu càng tốt. Điều này làm cho sơ đồ khó đọc hơn.

Bắt đầu với:

Sự kiện bắt đầu và kết thúc
Nhiệm vụ
Cổng loại trừ
Luồng tuần tự
Hồ và rãnh
Luồng thông báo khi cần thiết

Chỉ thêm các phần tử nâng cao khi chúng giải quyết được một vấn đề mô hình hóa thực tế.

Sai lầm 2: Nhầm lẫn giữa Luồng tuần tự và Luồng thông báo

Luồng tuần tự thể hiện sự tiến triển bên trong một quy trình. Luồng thông báo thể hiện sự giao tiếp giữa các thực thể tham gia riêng biệt.

Đừng sử dụng luồng thông báo chỉ để làm cho các đường nét trông khác biệt.

Sai lầm 3: Kết hợp Hồ và Rãnh không đúng cách

Sử dụng rãnh để phân chia trách nhiệm trong một thực thể tham gia. Sử dụng các hồ riêng biệt khi các thực thể tham gia là các thực thể hoặc quy trình độc lập.

Ví dụ:

Bán hàng, Tài chính và Vận hành có thể là các rãnh trong cùng một công ty.
Khách hàng và Nhà cung cấp có thể là các hồ riêng biệt.

Sai lầm 4: Coi mọi quyết định đều là loại trừ

Một cổng loại trừ có nghĩa là chỉ đúng một lộ trình được chọn. Nếu nhiều lộ trình có thể xảy ra đồng thời, hãy sử dụng cổng song song. Nếu một hoặc nhiều lộ trình tùy chọn có thể xảy ra, hãy cân nhắc sử dụng cổng bao hàm.

Sai lầm 5: Bỏ sót yếu tố kích hoạt

Một quy trình nên giải thích điều gì khởi tạo nó. “Xử lý đơn hàng” là không rõ ràng trừ khi mô hình chỉ ra liệu yếu tố kích hoạt là:

Đơn hàng của khách hàng
Một lô được lên lịch
Xác nhận thanh toán
Một thông báo từ hệ thống khác

Sai lầm 6: Chỉ mô hình hóa quy trình lý tưởng

Các quy trình thực tế bao gồm việc làm lại, từ chối, trì hoãn và nâng cấp. Một mô hình chỉ thể hiện con đường thuận lợi có thể hấp dẫn nhưng chưa đầy đủ về mặt vận hành.

Sai lầm 7: Đưa quá nhiều văn bản vào bên trong các hoạt động

Nhãn nhiệm vụ thường nên sử dụng định dạng động từ – tân ngữ ngắn gọn:

Duyệt hồ sơ
Xác minh địa chỉ
Phê duyệt hoàn tiền
Gửi xác nhận

Tránh các đoạn văn dài bên trong các hộp công việc. Hãy đặt các giải thích hỗ trợ trong các chú thích hoặc tài liệu.

Lỗi 8: Tạo một sơ đồ khổng lồ duy nhất

Các quy trình lớn nên được chia thành các quy trình con. Một sơ đồ cấp cao có thể hiển thị:

Tiếp nhận đơn hàng → Xử lý thanh toán → Thực hiện đơn hàng → Đóng đơn hàng

Mỗi giai đoạn có thể liên kết đến một sơ đồ chi tiết hơn.

14. Các thực hành tốt nhất của BPMN cho sơ đồ dễ đọc

Bắt đầu bằng một sự kiện khởi đầu rõ ràng.
Kết thúc bằng một hoặc nhiều trạng thái kết thúc có ý nghĩa.
Sắp xếp luồng chính từ trái sang phải hoặc từ trên xuống dưới.
Giữ các đường luồng tuần tự càng thẳng càng tốt.
Tránh các đường cắt nhau.
Sử dụng tên công việc nhất quán.
Giữ sơ đồ chính ở mức độ chi tiết dễ đọc.
Chỉ sử dụng làn khi trách nhiệm là yếu tố quan trọng.
Ghi nhãn các cổng bằng các câu hỏi hoặc điều kiện có ý nghĩa.
Ghi nhãn các đường đi ra khỏi cổng khi ý nghĩa không rõ ràng.
Sử dụng các quy trình con để ẩn các chi tiết không cần thiết.
Phân biệt các đường đi bình thường với các đường đi ngoại lệ.
Giữ các luồng thông điệp giữa các bể phù hợp.
Sử dụng các chú thích một cách tiết kiệm.
Xác thực mô hình với những người thực hiện quy trình.
Tạo các sơ đồ riêng biệt cho “trạng thái hiện tại” và “trạng thái tương lai” khi thiết kế lại một quy trình.

15. Người mới bắt đầu nên học bao nhiêu BPMN?

Bạn không cần phải học toàn bộ quy định BPMN để tạo ra các sơ đồ hữu ích.

Mức độ người mới bắt đầu

Học:

Sự kiện khởi đầu
Sự kiện kết thúc
Nhiệm vụ
Luồng tuần tự
Cổng loại trừ
Cổng song song
Hồ
Làn
Luồng tin nhắn
Đối tượng dữ liệu cơ bản

Điều này là đủ cho nhiều sơ đồ quy trình kinh doanh.

Mức độ trung cấp

Thêm:

Sự kiện hẹn giờ
Sự kiện tin nhắn
Sự kiện lỗi
Quy trình con
Hoạt động gọi
Nhiệm vụ người dùng
Nhiệm vụ dịch vụ
Sự kiện biên
Cổng dựa trên sự kiện
Đường bù đắp

Mức độ nâng cao

Nghiên cứu:

Sơ đồ vũ điệu
Sơ đồ hội thoại
Sự kiện không làm gián đoạn
Quy trình con dựa trên sự kiện
Giao dịch
Bù đắp
Hoạt động đa phiên bản
Tương quan
Ngữ nghĩa thực thi
Quy tắc triển khai cụ thể cho từng công cụ

BPMN hỗ trợ nhiều loại mô hình khác nhau, bao gồm sơ đồ quy trình, hợp tác, khiêu vũ và hội thoại. Người mới bắt đầu thường nên bắt đầu với các sơ đồ quy trình và hợp tác thông thường trước khi nghiên cứu các loại chuyên biệt hơn.

16. BPMN, sơ đồ luồng, và các ký hiệu liên quan

BPMN không phải là ký hiệu mô hình hóa duy nhất.

Sơ đồ luồng:Tốt nhất cho logic và quy trình đơn giản
BPMN:Tốt nhất cho quy trình kinh doanh và hợp tác quy trình làm việc
Sơ đồ hoạt động UML:Hữu ích cho hành vi phần mềm và hệ thống
DMN:Hữu ích cho các quyết định và quy tắc kinh doanh chính thức
CMMN:Hữu ích cho công việc linh hoạt, dựa trên trường hợp khi lộ trình chưa được định nghĩa đầy trước
Bản đồ dòng giá trị:Hữu ích cho việc phân tích giá trị và lãng phí từ đầu đến cuối
Sơ đồ SIPOC:Hữu ích cho phân tích ở cấp độ cao về nhà cung cấp, đầu vào, quy trình, đầu ra và khách hàng

BPMN có thể chỉ ra rằng một quyết định được đưa ra, trong khi một ký hiệu tập trung vào quyết định như DMN có thể mô tả các quy tắc được sử dụng để đưa ra quyết định đó. Các ký hiệu này có thể bổ sung cho nhau thay vì cạnh tranh.

17. Một quy tắc đơn giản

Chọn một sơ đồ luồngkhi:

Bạn cần giải thích một chuỗi các bước hoặc quyết định một cách nhanh chóng và đơn giản nhất có thể.

Chọn BPMNkhi:

Bạn cần hiểu, truyền đạt, phân tích, cải thiện hoặc tự động hóa một quy trình kinh doanh liên quan đến trách nhiệm, sự kiện, hệ thống hoặc tổ chức.

Bạn cũng có thể sử dụng cả hai:

Bắt đầu bằng một sơ đồ luồng đơn giản để hiểu quy trình tổng thể.
Chuyển đổi sang BPMN khi các vai trò, thông điệp, ngoại lệ, thời gian hoặc tự động hóa trở nên quan trọng.
Tạo một sơ đồ BPMN cấp cao dành cho lãnh đạo và một phiên bản chi tiết dành cho các nhà phân tích hoặc nhà phát triển.

Kết luận

Sơ đồ luồng và BPMN không phải là các công cụ cạnh tranh trong mọi tình huống. Sơ đồ luồng là một giải thích trực quan nhẹ nhàng. BPMN là một ngôn ngữ mô hình hóa có cấu trúc dành cho các quy trình đòi hỏi sự rõ ràng, trách nhiệm giải trình và chi tiết vận hành cao hơn.

Đối với người mới bắt đầu, phương pháp tốt nhất là bắt đầu đơn giản:

Xác định ranh giới của quy trình.
Xác định các bên tham gia.
Lập bản đồ cho đường đi bình thường.
Thêm các điểm ra quyết định.
Phân công trách nhiệm.
Chỉ thêm thông điệp, bộ đếm thời gian, dữ liệu và ngoại lệ khi chúng thực sự cần thiết.
Sử dụng các quy trình con để kiểm soát độ phức tạp.

Nếu quy trình của bạn ngắn và được xử lý bởi một người hoặc một nhóm, thì sơ đồ luồng có lẽ là đủ. Nếu quy trình liên quan đến nhiều vai trò, phòng ban, hệ thống, bên thứ ba, thời hạn hoặc tự động hóa, BPMN thường sẽ cung cấp một mô hình rõ ràng và bền vững hơn.

This post is also available in Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.