開始使用BPMN進行流程模組化

https://camunda.com/bpmn/

我為什麼要關心BPMN?

Business Process Model and Notation (BPMN) is the global standard for process modeling and one of the most important components of successful Business-IT-Alignment.

業務流程模型和符号(BPMN)是流程模組化的全球标準，也是成功實作業務- it一緻性的最重要元件之一。

More and more organizations are using BPMN and in more and more universities BPMN is taught as a subject. These are the reasons:

越來越多的組織正在使用BPMN，在越來越多的大學中，BPMN被作為一門學科來教授。原因如下:

• 标準 Standard：

  BPMN is not owned by a certain enterprise but by an institution (OMG), which is already established through other world-wide standards, e.g., UML. The standard is supported by many software products; you are less dependent on any particular vendor’s products.

  BPMN不是由某個企業擁有的，而是由一個機構(OMG)擁有的，OMG 已經通過其他世界範圍的标準建立起來了，例如UML。許多軟體産品都支援該标準;您不太依賴于任何特定供應商的産品。

• 簡單 Simplicity：

  The principle behind BPMN is rather simple which is why you can start working with this notation very quickly.

  BPMN背後的原理相當簡單，這就是為什麼您可以非常迅速地開始使用這種表示法的原因。

• 表達能力 Power of expression：

  If necessary, you can describe precisely how a process functions with BPMN. However, this is more difficult than only roughly describing the process. This way of precise modeling is possible, but not mandatory.

  如果有必要，您可以精确描述流程如何使用 BPMN 運作。然而，這比僅僅粗略地描述這個過程要困難得多。這種精确模組化的方式是可能的，但不是強制性的。

• 在 IT 界的實作 Implementation in IT：

  BPMN has been primarily developed to support technical implementation of processes (“Process Automation”). The more important the IT is in a company, the more helpful the use of BPMN becomes.

  BPMN的開發主要是為了支援過程的技術實作(“過程自動化”)。IT 在公司中越重要，BPMN 的使用就越有幫助。

BPMN中的一個簡單流

Let’s begin our BPMN tutorial with a rather simple process diagram:

讓我們從一個相當簡單的流程圖開始我們的BPMN教程:

• Start Event:

  

  Start event show which event causes the process to start. Start Events are always catching events.

  啟動事件顯示導緻流程啟動的事件。啟動事件總是捕獲事件。

• Task:

  

  Tasks are the heart of the process. Ultimately, something has to happen to bring about a desired outcome. In BPMN, a task is technically part of the activities category, which also includes the sub-process

  任務是流程的核心。最終，必須發生一些事情來帶來想要的結果。在 BPMN 中，任務在技術上是活動類别的一部分，它還包括子流程

• Intermediate Event:

  

  Intermediate events represent a status that is reached in the process and that is modeled explicitly. They are used infrequently, but intermediate events can be useful, for example if you regard reaching a certain status as a milestone and you want to measure the time until that milestone is reached. Intermediate none events are always throwing events.

  中間事件表示流程中達到的狀态，并顯式模組化。它們并不經常使用，但中間事件可能很有用，例如，如果您将達到某個狀态視為裡程碑，并且希望度量達到該裡程碑所需的時間。中間的 none 事件總是會抛出事件。

• End Event:

  

  End event mark the status reached at the end of the process path. End events are always throwing events.

  結束事件标記流程路徑結束處所達到的狀态。結束事件總是會抛出事件。

This diagram shows a simple process triggered by someone being hungry. The result is that someone must shop for groceries and prepare a meal. After that, someone will eat the meal and have his or her hunger satisfied.

這張圖顯示了一個由饑餓引發的簡單過程。結果就是必須有人去買雜貨，準備一頓飯。之後，有人會吃這頓飯，讓他或她的饑餓得到滿足。

最佳實踐:命名規約

When naming tasks, we try to adhere to the object-oriented design principle of using the [verb] + [object] pattern. We would say “acquire groceries,” for example, not “first take care of shopping for groceries.”

在命名任務時，我們盡量堅持使用[動詞]+[對象]模式的面向對象設計原則。例如，我們會說“購買雜貨”，而不是“首先負責購買雜貨”。

Events refer to something that has already happened regardless of the process (if they are catching events) or as a result of the process (if they are throwing events). For this reason, we use the [object] and make the [verb] passive in voice, so we write “hunger noticed.” BPMN does not require you to model start and end events for a process – you can leave them out – but if you model a start event, you must model an end event for each path. The same is true for end events, which require start events. We always create our models with start and end events for two reasons: first, that way it’s possible to determine the process trigger, and second, you can describe the final status of each path end. We only sometimes abandon this practice with sub-processes. More on this later.

事件指的是已經發生的事情，與程序無關(如果它們捕獲事件)，或者是程序的結果(如果它們抛出事件)。出于這個原因，我們使用[賓語]和[動詞]的被動語态，是以我們寫“饑餓被注意到了”。BPMN 不要求您對流程的開始和結束事件進行模組化 — 您可以忽略它們 — 但是如果您對開始事件進行模組化，則必須為每個路徑模組化一個結束事件。結束事件也是如此，它需要開始事件。我們總是使用開始和結束事件建立模型，原因有二:第一，這樣就可以确定流程觸發器，第二，您可以描述每個路徑結束的最終狀态。我們隻是有時在子過程中放棄這種實踐。稍後再詳細說明。

常見問題：水準繪制BPMN圖是必須的嗎?如果我喜歡垂直畫呢?

You could always draw your diagrams from top to bottom instead from left to right – the BPMN 2.0 standard does not forbid it. However, we do not recommend it: It is very uncommon, and experience has proven that people tend to understand the process flow better if it is described in the same way as written text (from left to right, at least in the western world).

你總是可以從上到下繪制圖表，而不是從左到右 — BPMN 2.0 标準并沒有禁止這樣做。然而，我們不推薦這樣做：這種情況非常罕見，而且經驗證明，如果用與書面文本相同的方式描述過程流，人們往往會更好地了解過程流(至少在西方世界中是從左到右)。

執行個體

運輸過程

In this diagram you can find the preparing steps a hardware retailer has to fulfill before the ordered goods can actually be shipped to the customer:

在這個圖表中，你可以找到硬體零售商在訂購的貨物實際被運送給客戶之前必須完成的準備步驟:

• Start Event:

  

  The plain start event ‘goods to ship’ indicates that this preparation should be done now.

  普通的啟動事件“貨物傳遞”表示現在應該完成這個準備工作。

• Parallel Gateway:

  

  Right after the instantiation of the process, there are two things done in parallel, as the parallel gateway indicates: While the clerk has to decide whether this is a normal postal or a spacial shipment (we do not define the criteria how to decide this inside the process model), the warehouse worker can already start packaging the goods.

  在流程執行個體化之後，有兩件事是并行完成的，正如并行網關指出的那樣:雖然職員必須決定這是正常的郵寄還是特殊運輸(我們沒有在流程模型中定義如何決定的标準)，但倉庫從業人員已經可以開始包裝貨物了。

• Task:

  

  This clerk’s task, which is followed by the exclusive gateway ‘mode of delivery’, is a good example of clarifying the recommended usage of an exclusive data-based gateway: The gateway is not responsible for the decision whether this is a special or a postal shipment. Instead, this decision is undertaken in the activity before. The gateway only works as a router, which is based on the result of the previous task, and provides alternative paths. A task represents an actual unit of work, while a gateway is only routing the sequence flow.

  這個職員的任務，後面是獨家網關“傳遞模式”，這是一個很好的例子，說明了基于資料的獨家網關的建議用法:網關不負責決定這是一個特殊的貨物還是郵政貨物。相反，這個決定是在之前的活動中進行的。網關隻是一個路由器，它是基于上一個任務的結果，并提供了可選路徑。任務代表一個實際的工作單元，而網關隻路由序列流。

• Exclusive Gateway:

  

  This gateway is called ‘exclusive’ because only one of the following two branches can be traversed: If we need a special shipment, the clerk requests quotes from different carriers, then assigns a carrier and prepares the paperwork. However, if normal post shipment is fine, the clerk needs to check if extra insurance is necessary.

  這個網關被稱為“獨家”，因為以下兩個分支中隻有一個可以被周遊：如果我們需要一個特殊的運輸，店員從不同的承運人請求報價，然後配置設定一個承運人并準備檔案。但是，如果正常的郵寄是可以的，店員需要檢查是否需要額外的保險

• Inclusive Gateway:

  

  If extra insurance is required, the logistics manager has to take out that insurance. In any case, the clerk has to fill in a postal label for the shipment. For this scenario, the shown inclusive gateway is helpful, because we can show that one branch is always taken, while the other one only if the extra insurance is required, but IF it is taken, this can happen in parrallel to the first branch. Because of this parallelism, we need the synchronizing inclusive gateway right behand ‘Fill in a Post label’ and ‘Take out extra insurance’.

  如果需要額外的保險，物流經理必須購買該保險。在任何情況下，職員都要填寫郵寄标簽。對于這個場景，所示的包容性網關是有幫助的，因為我們可以表明，一個分支總是被占用，而另一個分支隻有在需要額外保險的情況下才會被占用，但如果它被占用，這可能會與第一個分支并行發生。由于這種并行性，我們需要在“填寫郵寄标簽”和“購買額外的保險”旁邊設定同步的包容性網關。

• Inclusive Gateway(Synchronizing):

  

  In this scenario, the inclusive gateway will always wait for ‘Fill in a Postal label’ to be completed, because that is always started. If extra insurance is required, the inclusive gateway will also wait for ‘Taken out extra insurance’ to be finished.

  在此場景中，包容性網關将始終等待“填寫郵政标簽”完成，因為這總是被啟動。如果需要額外的保險，包容性網關也将等待“采取額外的保險”完成。

• Parallel Gateway (Synchronizing):

  

  Furthermore, we also need the synchronizing parallel gateway before the last task ‘add paperwork and move package to pick area’, because we want to make sure that everything has been fulfilled before the last task is executed.

  此外，在最後一個任務“添加文書和移動包裹到選擇區域”之前，我們還需要同步并行網關，因為我們想要確定在最後一個任務執行之前，所有事情都已經完成。

In this example, we only used one pool and different lanes for the people involved in this process, which automatically means that we blank out the communication between those people: We just assume that they are somehow communicating with each other. If we had a process engine driving this process, that engine would assign user tasks and therefore be responsible for the communication between those people. If we do not have such a process engine, but want to model the communication between the people involved explicitly, we would have to use a collaboration diagram as described in the next chapter.

在本例中，我們隻為參與此過程的人員使用了一個泳池和不同的泳道，這自動意味着我們忽略了這些人員之間的通信:我們隻是假設他們以某種方式互相通信。如果我們有一個流程引擎來驅動這個流程，該引擎将配置設定使用者任務，是以負責這些人之間的通信。如果我們沒有這樣的流程引擎，但是想要顯式地對相關人員之間的通信模組化，我們将不得不使用在下一章中描述的協作關系圖。

披薩協作

This example is about Business-To-Business-Collaboration. Because we want to explicitly model the interaction between a pizza customer and the vendor, we have classified them as “participants”, therefore providing them with dedicated pools:

這個例子是關于企業對企業協作的。因為我們想顯式地對披薩客戶和供應商之間的互動進行模組化，是以我們将他們分類為“參與者”，是以為他們提供專用泳池:

• Start Event:

  

  If we step through the diagram, we should start with the pizza customer, who has noticed her stomach growling. The customer therefore selects a pizza and orders it.

  如果我們逐漸浏覽這個圖表，我們應該從披薩顧客開始，她注意到她的胃在咆哮。是以，顧客選擇一份披薩并點餐。

• Event-based Gateway:

  

  The customer waits for the pizza to be delivered. The event-based gateway indicates that the customer actually waits for two different events that could happen next: Either the pizza is delivered, as indicated with the following message event, or there is no delivery for 60 minutes, i.e., after one hour the customer skips waiting and calls the vendor, asking for the pizza. We now assume that the clerk promises the pizza to be delivered soon, and the customer waits for the pizza again, asking again after the next 60 minutes, and so on.

  客戶等待披薩被送到。基于事件的網關表明，客戶實際上等待兩個不同的事件，然後可能發生:要麼像下面的消息事件所訓示的那樣傳遞披薩，要麼60分鐘内沒有傳遞，即，一個小時後，客戶跳過等待，打電話給供應商，要求傳遞披薩。我們現在假設店員承諾很快就會送出披薩，而客戶再次等待披薩，并在接下來的60分鐘後再次詢問，以此類推。

• Message Event:

  

  In this example, we use message events not only for informational objects such as the pizza order, but also for physical objects, like the pizza. We can do this because those physical objects actually inherently act as informational objects: When the pizza arrives at the customer’s door, she will recognize this arrival and therefore know that the pizza has arrived, which is exactly the purpose of the accordant message event in the customer’s pool. Of course we can only use the model that way because this example is not meant to be executed by a process engine.

  在本例中，我們不僅将消息事件用于資訊對象(如披薩訂單)，還用于實體對象(如披薩)。我們可以這樣做，因為這些實體對象實際上本質上充當了資訊對象:當披薩到達客戶的門口時，她将識别這個到達，是以知道披薩已經到達，這正是客戶泳池中相應消息事件的目的。當然，我們隻能以這種方式使用模型，因為此示例并不打算由流程引擎執行。

• Start Event:

  

  Let’s have a close look at the vendor process now. It is triggered by the order of the customer, as shown by the message start event and the message flow going from ‘order a pizza’ to that event. After baking the pizza, the delivery boy will deliver the pizza and receive payment.

  現在讓我們仔細看看供應商流程。它由客戶的訂單觸發，如消息啟動事件和從“訂購披薩”到該事件的消息流所示。烤好披薩後，送外賣的小哥會送出披薩并收取費用。

Please note that there are no default semantics in this type of modeling, which means you can model collaboration diagrams to show the interaction between business partners, but also zoom into one company, modeling the interaction between different departments, teams or even single workers and software systems in collaboration diagrams. It is totally up to the purpose of the model and therefore a decision the modeler has to make, whether a collaboration diagram with different pools is useful, or whether one should stick to one pool with different lanes, as shown in the previous chapter.

請注意，在這種類型的模組化中沒有預設語義，這意味着您可以模組化協作關系圖來顯示業務夥伴之間的互動，但也可以放大到一個公司，在協作關系圖中模組化不同部門、團隊甚至單個勞工和軟體系統之間的互動。這完全取決于模型的目的，是以，模組化者必須做出決定，不同泳池的協作圖是否有用，或者是否應該像前一章所示的那樣，堅持使用一個具有不同泳道的泳池。