Hế lô ajinomoto anh em. Hôm nay là thứ Sáu và anh em đang đọc blog Thinhnotes.com 😎

Tiếp nối chủ đề của bài một về BPMN, hôm nay mình sẽ tiếp tục đi sâu hơn vào BPMN với chủ đề: Giải ngố các ký hiệu BPMN.

Vì đặc thù bài này là ra mắt, lý giải, nên mình sợ nó sẽ hơi khô khan với bạn bè. Do đó bài này mình đã cố ý chôm chỉa khá nhiều hình ảnh bỏ vào. Một phần để nhìn cho nó nguy hại, phần khác nó sẽ giúp bạn bè đỡ ngán, và dễ tưởng tượng hơn .

Okay, let’s gooooo ! ! !

Điều đầu tiên mình muốn nói là nhìn BPMN nó tùm lum tùm la vậy thôi, chứ thật ra nó chỉ có… 6 cục chính.

Nắm chắc được ý nghĩa 6 cục này, thì dù có gặp hình BPMN phức tạp thế nào đi chăng nữa, bạn bè vẫn thuận tiện bỏ túi cái một .

1. Swimlane

Swimlane được xem như là linh hồn của BPMN, làm nó khác hẳn những diagram khác. Swimlane bao gồm Pool và Lane.

Pool thể hiện một tổ chức, một bộ phận, một phòng ban, một vai trò hoặc một hệ thống nào đó. Còn Lane thể hiện các cá nhân riêng lẻ, người sẽ làm các hoạt động cụ thể.

Hình BPMN này gồm 2 POOLS ( Bank, Customer ) và 3 LANES ( Sales Rep, Sales Manager và Risk Analyst ). Nguồn : Signavio. com

2. Activities

2.1. Có 4 loại chính

Activity tập trung trả lời câu hỏi làm gì. Tức là nó mô tả tất cả các công việc có trong quy trình. Activity gồm 4 loại sau.

Task và Sub-Process chắc đồng đội cũng dễ hiểu. Còn Transaction và Call Activity mình sẽ lý giải thêm chút xíu .

Transaction về cơ bản cũng tương tự Sub-Process, nhưng nó khác ở chỗ: transaction là một chuỗi các task thể hiện sự giao dịch, tức là có payment trong đó. Còn Sub-Process thì rộng nghĩa hơn. Ví dụ dưới đây cho anh em dễ hiểu.

Còn Call Activity như mình có giải thích ở hình trên thì bản chất nó giống như: mình gọi lại (triệu hồi) một quy trình mà mình đã define trước đó rồi. Ví dụ.

Đó là tổng quan về 4 loại Activity :

• Task: ô hình chữ nhật bình thường
• Sub-Process: ô hình chữ nhật nét đứt, có dấu cộng ở giữa
• Transaction: ô hình chữ nhật có 2 nét bao ngoài
• Call Activity: ô hình chữ nhật có 1 nét bao ngoài rất đậm.

2.2. Các đồ nghề trang điểm khác

Anh em nắm rõ 4 loại trên là ô kê rồi. Tuy nhiên, để thể hiện được nhiều “ý đồ” nguy hiểm hơn thì anh em phải nắm thêm mấy cái lẻ tẻ khác, gọi là Activity Marker và Task Type.

Ngó có vẻ nhiều, nhưng anh em đừng hoang mang hồ ngọc hà quá. Cũng không quá phức tạp và khó nhớ lắm. Nói theo kiểu BA thì mình sẽ facilitate nó cho anh em, tức là làm cho nó dễ hiểu hơn.

Đầu tiên sẽ là …

Sub-Process

Cái này dễ ẹc, dẹp qua một bên .

Loop

Là hành động mà nó lặp đi lặp lại theo trình tự.

Ví dụ một hôm sếp nhu yếu đồng đội kể một câu truyện mê hoặc trong đêm Year-End Party của công ty. Anh em sẽ làm theo những bước sau : brainstorm với đồng bọn >> soạn thảo kịch bản nháp >> chỉnh sửa bản nháp >> hoàn thành xong >> trình sếp để ổng duyệt .

Thì lúc này, bước Edit Draft là một bước được lặp đi lặp lại nhiều lần theo trình tự. Tức là sửa lần 1, sửa lần 2, sửa lần 3, sửa lần thứ “n”… Đến khi nào cảm thấy ổn rồi thì sẽ sang bước tiếp theo: Finalize story. Đó là Loop Task.

Multi-Instance

Đây là cái rất hay nhầm với Loop. Cái này cũng là hành động lặp đi lặp lại nhiều lần, nhưng nó cần các data set khác nhau.

Ví dụ làm quy trình tiến độ duyệt report. Case study đặt ra là : mỗi tháng Director sẽ duyệt report của những Manager .

Hành động duyệt các report này được thể hiện bằng một Task (tạm gọi là Evaluate Report), lặp đi lặp lại nhiều lần. Nhưng với mỗi lần duyệt, sẽ là một report khác nhau, được gửi từ các ông Manager khác nhau. Đó là các data khác nhau. Gộp lại sẽ thành một data set gồm nhiều data khác nhau.

BPMN 2.0 hơi màu mè hoa lá hẹ một chút là nó chia Multi-Instance ra làm 2 loại: song song (parallel) và tuần tự (sequential).

• Song song tức là lặp đi lặp lại nhưng làm đồng thời, cùng một lúc. Ví dụ như ông sếp cùng một lúc duyệt các report.
• Còn tuần tự là xong cái này, mới tới cái khác. Ví dụ ông sếp duyệt report cho Manager A rồi mới tới duyệt report cho Manager B.

Quay lại với Loop, bạn bè hoàn toàn có thể thấy Multi-Instance ( MI ) giống với Loop. Nhưng như mình nói, MI khác Loop ở chỗ nó đến từ nhiều data set khác nhau. Lấy luôn ví dụ phía trên cho đồng đội dễ so sánh .

Ví dụ ở bước Edit Draft, thay vì anh em phải tự edit lặp đi lặp lại nhiều lần, thì anh em có thể nhờ bạn bè, đồng bọn edit dùm.

Điều này có nghĩa : khi mỗi người bạn sửa dùm, họ sẽ gửi lại bản nháp mà họ sửa, tức đó là một data. Mỗi người bạn là mỗi bản nháp khác nhau, là mỗi data khác nhau. Các data này gộp lại sẽ thành một bộ data set gồm những bản nháp khác nhau .

Khi dùng MI Parallel, tức là cùng một lúc gửi cho cả 1 đống đứa cùng sửa.

Còn MI Sequential là gửi cho thằng A sửa, rồi lấy cái bản nháp của thằng A, gửi cho thằng B sửa, thằng A xong thì mới tới thằng B. Tiếp tục như vậy, sẽ gửi cho thẳng C, thằng D…

Để cụ thể hơn thì bạn bè hoàn toàn có thể note vào quá trình, lặp lại bao nhiêu lần ( hoặc một điều kiện kèm theo bất kể ) thì mới được cho phép quá trình chuyển qua bước tiếp theo .

Ad Hoc

Cái này thì cũng không khó hiểu, nghĩa sao dịch vậy. Ad hoc tức là được hình thành khi cần thiết và dành cho một mục đích cụ thể nhất định. Bà con hay gọi nôm na là “tùy cơ ứng biến”.

Vậy Ad Hoc Task sẽ bộc lộ những task đặc biệt quan trọng, có một mục tiêu chuyên được dùng đơn cử .

Ví dụ một dealer bán xe, họ có quy trình làm việc với các ngân hàng rất rõ ràng. Nhưng riêng với ngân hàng BuTaLo-BaTaCho thì lại có quy trình làm việc khá đặc biệt, chỉ dành riêng cho ngân hàng này.

Do đó, bạn bè sẽ đưa tiến trình này thuộc diện Ad Hoc. Và thường thì nó sẽ nằm trong một Sub-Process .
Ad Hoc biểu lộ một thứ gì đó rất đặc biệt quan trọng và sinh ra chỉ phục cho một đối tượng người tiêu dùng hoặc một mục tiêu duy nhất.

Compensation

Cái tên nói lên quá rõ. Compensation = Đền bù. Tức là phải có cái gì đó, thì mới đền bù.

Compensation task cũng chỉ là một task bình thường. Nhưng nó khác task bình thường ở chỗ: chỉ duy nhất xảy ra sau một task cụ thể nào đó.

Ví dụ : ăn bánh thì phải trả tiền. Task trả tiền là compensation, luôn xảy ra ngay sau task ăn bánh. Quay trở lại với ví dụ ban nãy .

Tóm váy lần một, Activity Marker giúp anh em thể hiện được hành vi khi thực hiện một hành động nào đó. Ví dụ thực hiện hành động một cách lặp đi lặp lại (Loop), hoặc chỉ thực hiện khi có một hành động cụ thể trước đó (Compensation).

Send Task/ Receive Task

Cái này thì quá rõ. Một task thể hiện sự nhận/ gửi thông tin, tài liệu, hoặc một data object.

User Task

User Task là task được thực hiện bởi người dùng, trên hệ thống và không thể tách nhỏ ra được nữa.

Manual Task

Manual Task là task được thực hiện bởi người dùng, ngoài hệ thống và được thực hiện một cách thủ công. 

Service Task

Service Task là task được thực hiện tự động bởi hệ thống.

Script Task

Script Task là task được thực hiện dựa trên một engine nào đó của hệ thống. Từ “script” ở đây có nghĩa là một đoạn code được viết ra để engine có thể parse đoạn code này chạy và thực hiện công việc.

Loại này mình thấy hiếm Open, bản thân mình thì cũng chưa từng dùng khi nào hết. Nên thôi next nhẹ qua nhé đồng đội .

Business Rule Task

Lại một lần nữa, cái tên nói lên quá rõ. Business Rule Task thể hiện một task, mà task đó dựa vào một cái rule nào đó. Anh này thì cũng mới có trong BPMN 2.0 thôi. Ví dụ một phát cho nóng.

ĐÂY LÀ HÌNH VẼ CHƯA ĐÚNG ( bạn bè chờ xíu nó sẽ load ra rõ hơn ) Sau khi dùng Business Rules Task, đồng đội sẽ có được một quá trình ngăn nắp, đẹp chai ngời ngợi dưới đây .

Tóm váy lần hai, Task Type giúp anh em thể hiện được tính chất, bản chất của các hoạt động. Biết được: à, task này làm trong hệ thống hay ngoài hệ thống (user task hay manual task). Hoặc task này chạy tự động hay user sẽ làm (service task hay user task).

Ô kê, bạn bè sẽ cùng overview lại bằng hình dưới đây .
Trong này có Send Task, Receive Task, Business Rules Task, User Task và Manual Task.

3. Flow

Anh em xem hình cho ngắn gọn, súc tích nhé 😊

4. Gateways

Gateway nghĩa là cái cổng, mà khi qua cái cổng này, luồng đi của hệ thống sẽ bị thay đổi tùy vào các điều kiện khác nhau.

BPMN thì có rất nhiều Gateway, khoảng chừng … 68 cái. Tuy nhiên dùng nhiều nhất mình thấy chỉ có 4 loại sau .

4.1. Exclusive Gateway

Exclusive, hay còn gọi là XOR Gateway. Nó thể hiện: nhánh này hoặc nhánh kia, nhưng chỉ được phép một trong hai (hoặc nhiều) nhánh.

4.2. Inclusive Gateway

Inclusive Gateway cũng tương tự Exclusive Gateway, nhưng khác ở chỗ nó cho phép xảy ra nhiều nhánh, chứ không duy nhất một nhánh như XOR. Tuy nhiên một khi các nhánh được activate, nó phải được complete hết trước khi merge lại.

4.3. Parallel Gateway

Parallel Gateway nghĩa là các nhánh phải cùng xảy ra song song với nhau. Chỉ cần một trong các nhánh chưa được complete thì các nhánh khác không thể merge lại, và quy trình không thể đi tiếp được.

4.4. Event-Driven Gateway

Event-Driven, tức là dựa vào Event, hướng theo Event mà chạy. Về cơ bản, Event-Driven Gateway khá giống với Exclusive Gateway (XOR) vì hai tụi này chỉ cho phép một nhánh chạy duy nhất.

Nhưng nó khác ở chỗ Exclusive Gateway thì dựa vào điều kiện để chạy, còn Event-Driven Gateway dựa vào event để chạy. Tức là khi có một sự kiện nào đó xảy ra thì nó sẽ kích nhánh của sự kiện đó chạy.

Thay vì nhờ vào vào điều kiện kèm theo, những nhánh sẽ nhờ vào vào sự kiện. Có thể bạn bè sẽ hơi bị confuse giữa condition và sự kiện, thấy nó cứ giống giống nhau. Nhưng mục tiêu dùng của hai anh này là trọn vẹn khác nhau, do đó mục tiêu dùng Exclusive Gateway hay Event-Driven Gateway cũng sẽ khác nhau .

• Condition: thường đơn giản, và nó trả lời cho câu hỏi ở task trước đó. Ví dụ về quê thì về quê bằng máy bay hay về quê bằng tàu lửa? It’s very simple.
• Event: còn event thường phức tạp hơn. Các event được gán vào các nhánh sẽ trả lời chi tiết hơn về các thông tin như: thời gian, ai là người làm, làm như thế nào… Hay nói nôm na là trả lời cho câu hỏi: sự việc gì xảy ra? 

Để hiểu cụ thể hơn về Event thì đồng đội cùng chuyển qua phần số 5 .

5. Events

Như ở trên mình có nói thì Event diễn tả một sự việc xảy ra trong quy trình, thường mang yếu tố bên ngoài. Chứ không phải một việc gì đó được chủ đích làm bởi user (vì nếu vậy thì nó là Activity mất rồi). Event được chia làm 3 giai đoạn:

• Start: bắt đầu
• Intermediate: ngay tức thì/ ở giữa
• End: kết thúc.

Tiếp đến, Event có rất nhiều loại. Mỗi loại bộc lộ một ý nghĩa khác nhau. Anh em xem hình sau sẽ rõ .
Một nùi những loại Event theo góc nhìn 3 quá trình : Start – Intermediate – End ( Hình mình lấy bên Training-Course-Material. com ). Bấm vào nút View Full Size để xem rõ hơn. Mặc dù Event có rất nhiều loại, nhưng không phải lúc cũng sử dụng đủ những loại này hết .

Ở bài này mình chỉ giới thiệu cho anh em 2 loại Event được dùng nhiều nhất, đó là: Timer Event và Message Event.

• Message Event: diễn tả sự việc gửi và nhận thông tin, có đầy đủ Start, Intermediate và End.
• Time Event: diễn tả một sự việc liên quan đến thời gian, nhưng chỉ có Start và Intermediate, không có End.

Một điểm nữa anh em cần chú ý là phải phân biệt được các Start Event, Intermediate Event và End Event.

• Start Event là 1 vòng tròn nhạt bên ngoài.
• Intermediate Event là 2 vòng tròn bên ngoài.
• Và End Event là 1 vòng tròn đậm bên ngoài.

Ngoài ra, còn một khái niệm nữa về Event đó là Boundary Event. Boundary Event được thể hiện bởi các Event dính liền với hình chữ nhật bao quanh task. Ví dụ.

Task Subprocess A có dính một Boundary Event. Nghĩa là khi quá trình chạy tới task này, nếu trong thời hạn X và hành vi Y xảy ra, thì quá trình sẽ đi theo nhánh tới task Handle Timeout. Còn nếu không thì tiến trình sẽ qua task Subprocess B .
Cách dùng như vầy trực diện và đơn thuần hơn rất nhiều so với dùng Event-Drivent Gateway .

Mình nói Boundary Event, để bắc cầu qua một loại Event khác, đó là: Interrupting Event và Non-Interrupting Event. Vì 2 loại event này đều phải được dùng dưới dạng Boundary Event. Tức là event phải được vẽ dính liền với hình chữ nhật bao quanh task.

Interrupting Event là khi task Subprocess A đạt được điều kiện trong thời gian A và hành động Y xảy ra, thì khi đó quy trình chuyển qua nhánh Handle Timeout. Và dừng toàn bộ task Subprocess A.

Còn Non-Interrupting Event cũng tương tự. Nhưng khi chuyển qua nhánh Handle Timeout, task Subprocess A vẫn diễn ra bình thường.

6. Information Artifact

Và thành phần cuối cùng trong BPMN là Information Artifact – thể hiện một thứ rất quan trọng trong bất kỳ quy trình nào, đó là thông tin, dữ liệu.

Mình sẽ ví dụ một phát ngay cho nóng .

.
.
.
That’s it. Đó là những gì mình muốn san sẻ trong bài ngày thời điểm ngày hôm nay. Nắm được những nội dung cơ bản trên là bạn bè đã hoàn toàn có thể quẩy BPMN tới bến rồi. Mình sẽ summarize lại một tí trước khi kết thúc .
BPMN gồm 6 thành phần chính .

• Swimlane: linh hồn của BPMN, thể hiện hành vi theo những vai trò một cách rõ ràng.
• Activity: thể hiện hành vi.
• Flow: thể hiện luồng đi của hành động.
• Gateway: thể hiện các cổng điều kiện kèm theo có trong quy trình.
• Event: thể hiện vấn đề xảy ra trong suốt quy trình.
• Information Artifact: thể hiện các tài liệu liên quan.

Hi vọng đồng đội sẽ rút chích được gì đó cho chính mình sau bài này 🙂 Hẹn gặp bạn bè ở bài post tiếp theo, nói về BPMN phần cuối : thực hành thực tế và những best practices khi vẽ BPMN.
Bái baiii, si du ờ gennnn ! ! !

Like this:

Like

Loading…

Bài viết liên quan

Source: https://final-blade.com
Category: Kiến thức Internet