Giới thiệu
Khi tôi lần đầu tiên bắt đầu làm việc với Mô hình và Ký hiệu Quy trình Kinh doanh (BPMN) 2.0, tôi đã mắc phải một sai lầm rất phổ biến: tôi coi các cổng như thể chúng là người ra quyết định trong một quy trình. Tất nhiên, những biểu tượng hình thoi đó dường như đang hỏi ‘Chúng ta nên đi theo con đường nào?’ — vì vậy, việc cho rằng chúng đang thực hiện việc suy nghĩ là điều hoàn toàn tự nhiên.
Nhưng sau khi dành thời gian mô hình hóa các quy trình thực tế và xem xét cách các chuyên gia có kinh nghiệm sắp xếp sơ đồ của họ, tôi nhận ra mô hình tư duy này hoàn toàn sai lệch. Sự thật lại tinh tế và thanh lịch hơn nhiều:một cổng hoàn toàn không chịu trách nhiệm ra quyết định. Nó chỉ đơn giản là một bộ định tuyến. Quyết định thực sự diễn ra ở nơi khác — cụ thể là trong hoạt động hoặc nhiệm vụ ngay trước cổng.
Hướng dẫn này đi qua những gì tôi đã học được về sự phân biệt quan trọng này, tại sao nó lại quan trọng đối với việc mô hình hóa quy trình sạch sẽ, và cách tách biệt ‘việc suy nghĩ’ khỏi ‘việc định tuyến’ dẫn đến các sơ đồ vừa chính xác hơn vừa dễ truyền đạt hơn cho các bên liên quan.
Bản chất cốt lõi: Các cổng là bộ định tuyến, chứ không phải người suy nghĩ
Điều quan trọng nhất cần ghi nhớ về các cổng BPMN 2.0 là vai trò chức năng của chúng. Một cổng không đánh giá điều kiện, cân nhắc các lựa chọn hay đưa ra kết luận. Nó chỉ làm đúng một việc:nó định hướng luồng trình tự theo các nhánh thay thếdựa trên thông tin đã được xác định trước.
Hãy hình dung nó như một đèn tín hiệu giao thông tại ngã tư. Đèn tín hiệu không quyết định bạn có cần rẽ trái hay đi thẳng hay không — chính bạn (người lái xe) đã đưa ra quyết định đó trước khi thậm chí đến ngã tư. Đèn tín hiệu chỉ đơn giản thực thi việc định tuyến dựa trên hướng đi đã xác định trước của bạn. Trong BPMN, cổng đóng vai trò cơ học tương tự.
Nhận thức này đã hoàn toàn thay đổi cách tôi tiếp cận việc mô hình hóa quy trình. Thay vì hỏi ‘Cổng này nên quyết định điều gì?’, giờ đây tôi hỏi ‘Nhiệm vụ hay hoạt động nào đã tạo ra kết quả mà cổng này cần định tuyến?’
Nơi thực sự diễn ra quyết định
Một khi bạn chấp nhận rằng các cổng chỉ là bộ định tuyến, câu hỏi tiếp theo sẽ là: nơi thực sự diễn ra việc ra quyết định là ở đâu?
Câu trả lời gần như luôn nằm ởhoạt động hoặc nhiệm vụ ngay trước cổng. Đây là nơi diễn ra công việc tư duy, đánh giá hoặc logic được điều khiển bởi hệ thống. Cổng chỉ đơn giản phản ánh kết quả của công việc đó trong luồng sơ đồ.
Một ví dụ thực tế: Quy trình giao hàng
Hãy xem xét một quy trình giao hàng mà tôi đã mô hình hóa cho một khách hàng logistics. Bản sơ đồ ban đầu có một cổng được gán nhãn ‘Đây có phải là một lô hàng đặc biệt không?’ — điều này khiến nó nghe như thể chính cổng đang đặt câu hỏi.
Sau khi tái cấu trúc, sơ đồ trông như sau:
-
Một nhân viên thực hiện một nhiệm vụ được ghi nhãn rõ ràng là‘Quyết định xem có phải là bưu phẩm thường hay lô hàng đặc biệt’
-
Kết quả của nhiệm vụ đó (thường hay đặc biệt) sau đó được truyền sang một cổng loại loại trừ
-
Cổng định tuyến luồng theo một trong hai nhánh dựa trên kết quả đã được xác định trước đó
Sự khác biệt là tinh tế nhưng có ý nghĩa quan trọng. Nhiệm vụ là nơi diễn ra việc đánh giá — nhân viên kiểm tra kích thước, giá trị, điểm đến và bất kỳ yêu cầu xử lý đặc biệt nào. Cổng chỉ đơn giản nói: ‘Nếu kết quả là ‘đặc biệt’, hãy đi theo hướng này; nếu không, hãy đi theo hướng kia.’
Vai trò chức năng: Nhiệm vụ so với Cổng
Hiểu rõ sự khác biệt giữa nhiệm vụ và cổng đòi hỏi phải rõ ràng về việc mỗi thành phần đại diện cho điều gì:
Các nhiệm vụ đại diện cho các đơn vị công việc thực tế.Chúng là nơi công việc được thực hiện — nơi ai đó đánh giá thông tin, đưa ra lựa chọn, thực hiện tính toán hoặc thực hiện một hành động. Một nhiệm vụ có thể đơn giản như ‘Xác minh địa chỉ khách hàng’ hoặc phức tạp như ‘Xem xét điều kiện đủ tư cách đề cử theo tiêu chí của hội đồng.’
Các cổng kết nối đại diện cho logic định tuyến.Chúng không thực hiện công việc; chúng kiểm soát luồng. Chúng lấy đầu ra từ một tác vụ trước đó và định hướng token quy trình theo nhánh phù hợp. Chính cổng kết nối không có trí tuệ — nó là một cấu trúc cơ học.
Sự tách biệt giữa các vấn đề này là một trong những điều khiến BPMN trở thành ngôn ngữ mô hình hóa mạnh mẽ như vậy. Bằng cách giữ cho công việc và định tuyến riêng biệt, sơ đồ truyền đạt rõ ràng cả hai điều sau đây:điều gìcần phải làm vàcách thứcquy trình nhánh ra dựa trên kết quả.
Cơ chế định tuyến: Cách hoạt động của các cổng kết nối
Khi quyết định đã được đưa ra trong một tác vụ trước đó, cổng kết nối sẽ thực thi quyết định đó thông qua các cơ chế định tuyến cụ thể. Loại thường được sử dụng nhất làcổng kết nối loại loại trừ, đảm bảo rằng chỉ có một trong các nhánh khả dụng được đi qua.
Dưới đây là cách cơ chế này hoạt động trong thực tế:
-
Tác vụ trước đó tạo ra một kết quả duy nhất và xác định
-
Cổng kết nối loại trừ đánh giá kết quả đó dựa trên các nhãn điều kiện của nó
-
Chính xác một luồng tuần tự đầu ra được kích hoạt
-
Token quy trình tiếp tục theo con đường duy nhất đó
Các loại cổng kết nối khác xử lý các tình huống định tuyến khác nhau — cổng song song cho các đường đi đồng thời, cổng bao gồm cho một hoặc nhiều nhánh — nhưng nguyên tắc vẫn như nhau: cổng kết nối định tuyến dựa trên thông tin được xác định ở nơi khác.
Đánh giá phức tạp: Các tình huống thực tế
Khái niệm cổng kết nối như một bộ định tuyến trở nên quan trọng hơn bao giờ hết khi xử lý các quy trình phức tạp liên quan đến nhiều bên liên quan và các tiêu chí quyết định tinh vi.
Quy trình đề cử Giải Nobel
Trong việc mô hình hóa quy trình đề cử Giải Nobel, tôi đã gặp một tình huống mà Người quản lý Danh sách Vấn đề cần xem xét các đề cử và xác định xem chúng có đáp ứng các tiêu chí sẵn sàng cụ thể hay không trước khi quy trình có thể tiếp tục. Điểm then chốt là công việc ‘xem xét và xác định’ được thực hiện trong một tác vụ chuyên biệt được giao cho Người quản lý Danh sách Vấn đề. Cổng kết nối tiếp theo chỉ đơn giản định tuyến quy trình — tiếp tục sang giai đoạn tiếp theo nếu đề cử đã sẵn sàng, hoặc kết thúc quy trình nếu không.
Cổng kết nối không đánh giá chất lượng của đề cử. Người quản lý Danh sách Vấn đề mới làm điều đó. Cổng kết nối chỉ phản ánh quyết định đó trong luồng quy trình.
Quy trình bỏ phiếu qua email
Tương tự, trong các quy trình bỏ phiếu dựa trên email, người chịu trách nhiệm thu thập và kiểm đếm phiếu bầu thực hiện việc xác định thực tế xem đã đạt được đa số hay không, hay một nghị quyết đã được thông qua hay chưa. Một cổng kết nối ở phía sau đó sẽ định tuyến theo đúng cách. Sự phân tách này rõ ràng: con người thực hiện suy nghĩ, cổng kết nối thực hiện định tuyến.
Tại sao sự phân biệt này lại quan trọng
Bạn có thể đang tự hỏi liệu mức độ chính xác này thực sự có quan trọng trong thực tế hay không. Dù sao đi nữa, sơ đồ đều “hoạt động” tốt trong cả hai trường hợp — quy trình chảy đúng cách bất kể bạn gán quyết định cho cổng kết nối hay cho tác vụ trước đó.
Nhưng theo kinh nghiệm của tôi, có một số lợi ích cụ thể khi làm đúng điều này:
1. Trách nhiệm rõ ràng hơn.Khi quyết định được ghi nhận rõ ràng trong một tác vụ, thì rõ ràng ai hoặc cái gì chịu trách nhiệm đưa ra quyết định đó. Bạn có thể giao tác vụ cho một vai trò cụ thể, ước tính thời gian cần thiết, và theo dõi xem nó có được hoàn thành đúng hay không.
2. Giao tiếp tốt hơn với các bên liên quan.Các bên liên quan không chuyên về kỹ thuật hiểu được các nhiệm vụ — chúng đại diện cho công việc mà con người thực hiện. Khi bạn hiển thị cho họ một nhiệm vụ được gán nhãn là “Xem xét và phê duyệt yêu cầu ngân sách”, họ ngay lập tức hiểu được điều gì xảy ra ở bước đó. Một điểm chuyển tiếp được gán nhãn là “Đã được chấp thuận?” thì mơ hồ hơn và khiến người ta đặt câu hỏi về ai đang thực hiện việc chấp thuận.
3. Cải tiến quy trình dễ dàng hơn.Khi bạn cần tối ưu hóa một quy trình, bạn cần biết nơi nào các quyết định được đưa ra. Nếu các quyết định bị chôn vùi bên trong các điểm chuyển tiếp, sẽ khó hơn để xác định các điểm nghẽn, các đánh giá trùng lặp, hoặc các cơ hội để ủy quyền hoặc tự động hóa.
4. Tự động hóa chính xác hơn.Khi triển khai một sơ đồ BPMN trong một động cơ quy trình, sự phân biệt này mang ý nghĩa kỹ thuật quan trọng. Các nhiệm vụ ánh xạ đến các mục công việc; các điểm chuyển tiếp ánh xạ đến các quy tắc định tuyến. Việc trộn lẫn hai khái niệm này dẫn đến sự nhầm lẫn trong quá trình triển khai.
Những sai lầm phổ biến cần tránh
Thông qua quá trình thử nghiệm và sai lầm của bản thân, cùng với việc xem xét các sơ đồ được tạo bởi người khác, tôi đã nhận diện được một số lỗi lặp lại liên quan đến sự phân biệt giữa điểm chuyển tiếp và quyết định:
Gán nhãn các điểm chuyển tiếp là câu hỏi.Một điểm chuyển tiếp được gán nhãn là “Thanh toán có hợp lệ không?” ngụ ý rằng điểm chuyển tiếp này đang thực hiện kiểm tra tính hợp lệ. Thay vào đó, hãy tạo một nhiệm vụ có tên là “Xác minh thanh toán” và để điểm chuyển tiếp định tuyến dựa trên kết quả.
Bỏ qua nhiệm vụ ra quyết định.Đôi khi các nhà mô hình hóa nhảy thẳng từ một nhiệm vụ thu thập thông tin sang một điểm chuyển tiếp, ngầm giả định rằng điểm chuyển tiếp sẽ tự tìm ra điều gì cần làm. Nhưng nếu không có nhiệm vụ nào thực hiện đánh giá một cách rõ ràng, sơ đồ sẽ không đầy đủ — không rõ ai hay cái gì đưa ra quyết định.
Tải quá nhiều logic lên các điểm chuyển tiếp.Một điểm chuyển tiếp duy nhất với các biểu thức điều kiện phức tạp trên nhiều luồng đầu ra thường cho thấy logic quyết định nên được chia nhỏ thành một nhiệm vụ phù hợp với đầu ra rõ ràng, sau đó là các bước định tuyến đơn giản hơn.
Kết luận
Sự phân biệt giữa các điểm chuyển tiếp và quyết định trong BPMN 2.0 là một trong những khái niệm nền tảng, ban đầu có vẻ nhỏ bé nhưng lại có tác động lớn đến chất lượng các mô hình quy trình của bạn. Một khi tôi hiểu rõ rằng các điểm chuyển tiếp là bộ định tuyến — chứ không phải người ra quyết định — các sơ đồ của tôi trở nên sạch sẽ hơn, dễ truyền đạt hơn và dễ triển khai hơn.
Bài học cốt lõi rất đơn giản nhưng mang sức mạnh lớn:quyết định diễn ra trong nhiệm vụ, còn điểm chuyển tiếp chỉ định tuyến dựa trên kết quả.Bằng cách duy trì sự phân biệt này, bạn tạo ra các sơ đồ phản ánh chính xác cách công việc thực sự được thực hiện, ai chịu trách nhiệm cho điều gì, và quy trình nhánh ra như thế nào dựa trên các đánh giá thực tế.
Dù bạn đang mô hình hóa một quy trình vận chuyển đơn giản hay một quy trình phức tạp đa bên liên quan như đề cử Giải Nobel, việc áp dụng nguyên tắc này sẽ giúp bạn tạo ra các sơ đồ BPMN vừa chính xác về mặt kỹ thuật, vừa thực sự hữu ích cho những người cần hiểu và thực hiện quy trình.
Tài liệu tham khảo
- Từ truyện kể đến sơ đồ: Cách công cụ sinh sơ đồ BPMN AI của Visual Paradigm biến đổi quy trình mô hình hóa quy trình: Cách AI chuyển đổi các truyện kể văn bản thành sơ đồ BPMN.
- Nắm vững mô hình hóa quy trình kinh doanh (BPMN 2.0) với các công cụ được hỗ trợ AI của Visual Paradigm: Hướng dẫn nắm vững BPMN 2.0 bằng các công cụ AI.
- Đánh giá BPMN của Visual Paradigm: Cầu nối khoảng cách giữa logic kinh doanh và triển khai kỹ thuật: Đánh giá chi tiết về khả năng BPMN của Visual Paradigm.
- Cập nhật công cụ sinh sơ đồ quy trình kinh doanh AI BPMN: Ghi chú phát hành cho bản cập nhật công cụ sinh sơ đồ BPMN AI.
- Hiểu rõ ký hiệu BPMN: Chìa khóa để mô hình hóa quy trình kinh doanh hiệu quả: Hướng dẫn nền tảng để hiểu ký hiệu BPMN.
- Hướng dẫn BPMN của Visual Paradigm: Video hướng dẫn minh họa các tính năng của BPMN.
- Vượt xa mã nguồn và AI: Tại sao Visual Paradigm vẫn là thiết yếu cho kiến trúc phần mềm chuyên nghiệp: Giá trị bền vững của Visual Paradigm trong kiến trúc phần mềm.
- Giải thích các loại hoạt động BPMN: Giải thích chi tiết về các loại hoạt động BPMN khác nhau.
- Cách NLP được hỗ trợ bởi AI đang cách mạng hóa việc tạo sơ đồ BPMN từ văn bản cho mô hình hóa quy trình doanh nghiệp: Công nghệ NLP đằng sau việc tạo sơ đồ BPMN từ văn bản.
- Tính năng của Visual Paradigm: Tổng quan về các tính năng chính của Visual Paradigm.
- Sơ đồ BPMN và công cụ: Xem xét các công cụ và tính năng vẽ sơ đồ BPMN.
- Trang web chính thức của Visual Paradigm: Trang chủ chính thức của Visual Paradigm.
- Nhấn Bắt đầu AI – Hỗ trợ kỹ thuật: Hỗ trợ kỹ thuật để bắt đầu sử dụng các tính năng AI.
- Thử nghiệm công cụ tạo sơ đồ BPMN được hỗ trợ bởi AI của Visual Paradigm cho việc lập bản đồ quy trình thực tế: Thử nghiệm thực tế với công cụ AI để lập bản đồ trong thực tế.
