中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導(dǎo)語：BPMN是業(yè)務(wù)流程建模和標(biāo)注，很多企業(yè)都會(huì)通過BPMN對(duì)業(yè)務(wù)進(jìn)行管理，提高整體的效率；但BPMN在國內(nèi)的理解度還不夠，本文作者以一個(gè)物業(yè)維修流程為例，分享了關(guān)于BPMN建模方法，我們一起來看一下。

BPMN（業(yè)務(wù)流程管理）是一種用于捕獲、設(shè)計(jì)、執(zhí)行、記錄、測(cè)量、監(jiān)控和控制自動(dòng)化以及非自動(dòng)化流程，以滿足公司的目標(biāo)和業(yè)務(wù)策略的系統(tǒng)方法。

通過BPMN，流程可以與業(yè)務(wù)戰(zhàn)略保持一致，藉由業(yè)務(wù)部門內(nèi)部甚至超越公司邊界的流程優(yōu)化，有助于提高公司的運(yùn)轉(zhuǎn)效率。

BPMN在國內(nèi)的應(yīng)用很廣泛，但很多企業(yè)花費(fèi)大價(jià)錢購買了第三方的流程平臺(tái)，卻沒有得到相應(yīng)的收益；我認(rèn)為其根本原因還是在于對(duì)BPMN本身的理解不足——它遠(yuǎn)沒有看上去那么簡單，僅僅是BPMN2.0版本規(guī)范文檔就已經(jīng)達(dá)到了500頁。

因此，在我看來，要想順利的實(shí)施BPMN，一個(gè)對(duì)它有透徹理解的設(shè)計(jì)者是必不可少的；同時(shí)，設(shè)計(jì)者還需要兼具業(yè)務(wù)思維、管理思維，和一定的技術(shù)思維。

本文的以一個(gè)物業(yè)維修流程為例，目的在于介紹一個(gè)系統(tǒng)的BPMN建模方法，為剛剛踏入這個(gè)領(lǐng)域的人提供一個(gè)方向和選擇。

一、傳統(tǒng)流程圖

這是一個(gè)典型的物業(yè)維修流程，這個(gè)流程提供的信息量很少，以至于如果我們要僅僅基于此去設(shè)計(jì)一個(gè)完善的BPMN流程是幾乎不可能的；但是即便是最專業(yè)的物業(yè)管理師，這也是他們僅能提供的流程圖了。

為了達(dá)到我們的目標(biāo)，我們需要先建立一個(gè)戰(zhàn)略層面上的流程，它可能很粗糙，但是它的目的并不是在初期就呈現(xiàn)一個(gè)完整詳細(xì)的視圖。

它的作用可能有如下幾點(diǎn):

• 澄清什么是，和什么不是這個(gè)流程的一部分；
• 為流程確定資源和分配責(zé)任；
• 確定關(guān)鍵績效指標(biāo)并明確其特征；
• 在對(duì)流程著手優(yōu)化前先對(duì)其進(jìn)行一個(gè)大致的回顧。

二、戰(zhàn)略流程模型的要求

• 體積：戰(zhàn)略流程模型應(yīng)當(dāng)盡可能小，流元素最好不要超過10個(gè)，如果一個(gè)流程橫跨幾張紙的話，是沒人能理解得了的。
• 語法：盡可能正確，但是在必要時(shí)可以不那么嚴(yán)謹(jǐn)。

三、戰(zhàn)略流程模型的建模步驟

想要對(duì)一個(gè)流程進(jìn)行初步建模，往往比想象的要難得多，有時(shí)手頭有充足的資料和標(biāo)準(zhǔn)的操作流程可以用，那會(huì)好些，但大多數(shù)時(shí)候都不得不去與客戶深入交流。

當(dāng)產(chǎn)品去和客戶開會(huì)溝通時(shí)，我能很容易的想象到下面的景象——當(dāng)你只畫了一個(gè)圈兩個(gè)矩形：

客戶參會(huì)人員：

• 我們的維修流程并不總是這樣從業(yè)主填寫維修單開始的，業(yè)主也可能是電話報(bào)修；
• 如果維修的工程量比較大的話，我們還得先提出方案，然后交給公司領(lǐng)導(dǎo)審批；
• 如果過了保修期的話，那我們還要收錢的；
• 業(yè)主如果是預(yù)約的話，我們還得根據(jù)他預(yù)約時(shí)間安排工作；
• 并不一定是業(yè)主報(bào)修，也可能是在物業(yè)巡檢的時(shí)候發(fā)現(xiàn)問題，由巡檢員報(bào)修。
• ……….

如果沒有一個(gè)狠人來主持會(huì)議的話，產(chǎn)品會(huì)很容易迷失方向，也會(huì)導(dǎo)致客戶的參會(huì)人員對(duì)你的方案失去興趣，更差的情況是，其他人糊里糊涂地對(duì)一個(gè)錯(cuò)誤的模型達(dá)成了一致。

所以主持會(huì)議的人，需要在開始的時(shí)候先聲明好：所有的流程模型都是不完整的，但是它依然有一些作用。

在一開始找出每一種可能性是不可能的，在這次會(huì)議開始前，就應(yīng)當(dāng)告訴客戶，這第一次的迭代目標(biāo)是什么。

• 我們要記錄流程從開始到結(jié)束的過程；
• 我們最多只記錄這個(gè)流程的N個(gè)步驟；
• 我們只記錄這個(gè)流程的標(biāo)準(zhǔn)形式；

如果會(huì)議期間仍有人想跳出圈定的范圍，應(yīng)當(dāng)立刻阻止。

下面回到正題——物業(yè)維修流程。

基于上面的傳統(tǒng)流程圖，我們可以得到以下信息：

這個(gè)流程往往是由業(yè)主有維修需求引起。

發(fā)起人填寫一個(gè)維修單，發(fā)單部門（也就是行政部）將維修單提交到客戶服務(wù)中心，客戶服務(wù)中心的經(jīng)辦人填寫工程單匯總表，然后把維修任務(wù)下發(fā)到維保部門，主任分配工作給維修工，維修工執(zhí)行任務(wù)，并會(huì)同發(fā)單部門驗(yàn)收以確認(rèn)維修完成。

當(dāng)維修完成的時(shí)候，這個(gè)流程也就結(jié)束了。

基于關(guān)鍵信息，我們可以構(gòu)建如下的流程圖，這里我們出于BPM原則，要先把結(jié)束事件放在需求方的泳道上。

盡管這個(gè)模型有很多問題，但是這個(gè)階段我們要確?？蛻裟芎敛毁M(fèi)力的理解它，因此做到這樣就可以了。

接下來，我們可以開始逐步的糾正這個(gè)錯(cuò)誤的模型了。

1. 泳池和泳道

首先是泳池和泳道，根據(jù)BPMN的規(guī)范要求，每個(gè)流程都應(yīng)當(dāng)有一個(gè)最高的統(tǒng)籌者（這個(gè)請(qǐng)自行查閱BPMN規(guī)范），負(fù)責(zé)協(xié)調(diào)流程中的參與人和系統(tǒng)；但這個(gè)流程不是由流程引擎控制的（它是由發(fā)起人控制的），因此它目前不存在這么一個(gè)協(xié)調(diào)者，當(dāng)業(yè)主報(bào)修時(shí)候，無法路由到下一個(gè)活動(dòng)（如果把分配到下一節(jié)點(diǎn)的受讓人當(dāng)成一種路由方式的話，那么這時(shí)候其實(shí)是流程引擎在當(dāng)協(xié)調(diào)者）。

因此這邊應(yīng)該建模成消息流，另外，應(yīng)當(dāng)把業(yè)主分配到另一個(gè)池里。

我們建模越詳細(xì)，發(fā)現(xiàn)的問題也隨之增加，比如，業(yè)主如果中途不想維修了，在這個(gè)模型下流程是無法“正?！钡亟Y(jié)束的 ；如果需要滿足這個(gè)業(yè)務(wù)需求又不希望通過技術(shù)手段生硬的結(jié)束，那么就會(huì)需要用到邊界事件；另外，如果維修工需要用到一些材料的話，他該怎么辦，是否需要申請(qǐng)，又向誰申請(qǐng)？

對(duì)于戰(zhàn)略模型，為了盡可能簡單，通常不會(huì)使用多個(gè)池，除非是像上面這種業(yè)主是獨(dú)立于物業(yè)公司之外的情況；可是由于我們的關(guān)注點(diǎn)依然應(yīng)當(dāng)集中在物業(yè)公司的內(nèi)部流程上，因此接下來講業(yè)主的池進(jìn)行折疊。

2. 任務(wù)和子流程

任務(wù)經(jīng)常出現(xiàn)在戰(zhàn)略流程模型中，但是子流程很少出現(xiàn)；在戰(zhàn)略流程模型中不會(huì)去指定任務(wù)的類型，也不使用除了循環(huán)之外的標(biāo)記，因?yàn)檠h(huán)相對(duì)來說很容易理解。

子流程應(yīng)該細(xì)化流程模型，在維修流程模型中，我們定義的這些任務(wù)，背后可能并不簡單，他們可能對(duì)應(yīng)著非常復(fù)雜的操作。

但是對(duì)于發(fā)單人填寫登記表這類任務(wù)，從我們得到的信息來看，只管填就行了，所以我們就還是把它們當(dāng)做任務(wù)。

基于這些考慮，我們可以得到下面的模型：

我們只是對(duì)于可能存在復(fù)雜邏輯的任務(wù)做一個(gè)子任務(wù)標(biāo)記，就足夠了。

3. 網(wǎng)關(guān)

上面給出的模型，只是基于最常見的情況，對(duì)于一些確實(shí)有必要做分支的情況，我們就需要用網(wǎng)關(guān)來對(duì)這類情況進(jìn)行建模，但一般來說不會(huì)在戰(zhàn)略流程模型中引入網(wǎng)關(guān)。

4. 事件

在戰(zhàn)略流程模型中使用的事件類型是有限制的：

空類型可以用在開始，中間，結(jié)束事件上，中間事件可以記錄流程執(zhí)行過程中的某個(gè)狀態(tài)，客戶也很容易理解。

消息類型和定時(shí)類型可以被允許作為開始事件和中間事件使用，因?yàn)樗鼈兊姆?hào)一看就能看懂，很容易理解。

至此戰(zhàn)略流程模型就可以結(jié)束了。

四、操作流程模型

1. 目的和好處

在操作流程模型中，就可以開始呈現(xiàn)出流程關(guān)于人和技術(shù)的細(xì)節(jié)了，這里會(huì)涉及到一些問題：

• 對(duì)于流程設(shè)計(jì)者：工作是如何完成的？
• 流程開發(fā)人員：需要通過流程引擎來實(shí)現(xiàn)什么功能？
• 流程參與人員：該怎么完成自己的工作？

要調(diào)和這三個(gè)角色并不簡單，而這也正是操作流程模型需要做的事情，如果很好的回答了這三個(gè)問題，那么就可以得到以下好處：

• 操作流程模型的邏輯，在實(shí)際操作和技術(shù)實(shí)現(xiàn)上是一致的。
• 縮小了業(yè)務(wù)和技術(shù)之間的理解溝通的溝壑，雙方以流程模型作為共同語言。
• 藉由流程引擎實(shí)現(xiàn)的流程，更易于觀測(cè)。

2. 建模要求

在這個(gè)層面上的模型，就不像戰(zhàn)略流程模型能容忍一些語法上的錯(cuò)誤了，我們必須按照規(guī)范來進(jìn)行建模。

除了規(guī)范之外，必須實(shí)現(xiàn)的還有精確性，因?yàn)榭蛻粜枰鶕?jù)這個(gè)流程模型安排工作，同時(shí)，我們也應(yīng)當(dāng)盡可能的不讓這個(gè)流程顯得過于復(fù)雜；畢竟流程參與者關(guān)注的是他們的工作本身而不是BPM，流程對(duì)于他們只是一種達(dá)到目的的手段。

3. 工序

之前有說到，操作流程模型應(yīng)當(dāng)足夠精確但又不過于復(fù)雜，這聽起來可能很矛盾；為此，我們先作一張表格，來看看操作流程模型在三個(gè)角色中的視圖是怎樣的；流程參與者只需要關(guān)注自己需要怎么做，以及什么時(shí)候需要等待其他人完成什么，這樣就不會(huì)被其他人所做的細(xì)節(jié)分散掉注意力。

操作層面的流程模型的核心思想，在于區(qū)分編排和協(xié)作，如之前所講，每個(gè)流程參與者都有自己的一個(gè)池。

把流程引擎作為一個(gè)單獨(dú)的池，可以讓流程開發(fā)者更好的關(guān)注它。

流程設(shè)計(jì)者的角色在這邊非常重要，需要非常懂BPMN，并且能夠從不同參與者的視角對(duì)流程進(jìn)行建模。

設(shè)計(jì)者的工序可能如下：

1. 審查戰(zhàn)略流程模型；
2. 分割泳道到單獨(dú)的池；
3. 在不同參與者的視角下進(jìn)行建模；
4. 為技術(shù)層面的建模做準(zhǔn)備；
5. 進(jìn)行技術(shù)層面的建模，不一定可執(zhí)行，目的在于細(xì)化模型；
6. 加上必要的注釋；

當(dāng)然這也只是一種經(jīng)驗(yàn)方法而已，你也可以直接在技術(shù)層面開始分析和建模，自下而上。

4. 從戰(zhàn)略層面到操作層面

繼續(xù)我們的物業(yè)維修流程例子，為了簡化對(duì)于每個(gè)流程參與者的模型復(fù)雜性，我們需要將物業(yè)公司下面的三個(gè)參與者泳道都分割到單獨(dú)的池中。

同時(shí)，我們也要解決一些顯而易見的邏輯上的錯(cuò)誤，比如：

• 驗(yàn)收沒有聯(lián)合業(yè)主一起；
• 省略了倉管這一參與者；
• 省略了客服專員的每周匯總和進(jìn)度督促；
• 業(yè)主報(bào)修的時(shí)候更多是電話申報(bào)；

這里最大的難點(diǎn)在于，由于存在代發(fā)起的情況，我們很難把業(yè)主的池和接線員的池完全隔離開；雖然在流程引擎的層面上可以用兩個(gè)流程變量來解決問題（發(fā)起人，擁有人），但是在模型展示的層面上這種辦法是沒法很好的表達(dá)出意思的，而且也會(huì)增加開發(fā)的工作量；因此我們可以采用多個(gè)開始事件的形式，來對(duì)這一情況進(jìn)行建模。

這就是將流程參與者分割到單獨(dú)的池后的模型圖，這里依然存在一些問題，比如我們還沒有對(duì)維修項(xiàng)目做分級(jí)，驗(yàn)收未通過的話怎么調(diào)整參數(shù)等等；但這一步我們也只是澄清各個(gè)流程參與者之間的關(guān)系，沒必要過于深究。

5. 站在不同參與者的視角建模

從這一步開始，往往就需要與流程參與人員進(jìn)行更詳細(xì)的交流了。

從業(yè)主開始，我們可以看到業(yè)主相關(guān)的參與者有接線員，行政部門和機(jī)電維修部門，此時(shí)我們可以把這兩者的池進(jìn)行折疊。

根據(jù)我們已知的業(yè)務(wù)場景：

• 如果業(yè)主申報(bào)的維修項(xiàng)目是有償服務(wù)，需要由客服與其進(jìn)行再次確認(rèn)；
• 如果涉及付費(fèi)服務(wù)，業(yè)主需要有一個(gè)付款的操作；

在更深一步的考慮之后，我們發(fā)現(xiàn)業(yè)主池還會(huì)涉及到客服部門，最終我們得到如下模型。

行政部門的流程比較簡單，涉及到的其他池有業(yè)主和客戶服務(wù)中心：

客戶服務(wù)中心這邊應(yīng)當(dāng)注意，在客戶給出的傳統(tǒng)流程圖中，有提到定時(shí)性質(zhì)的統(tǒng)計(jì)和催促的任務(wù)，這種情況我們應(yīng)當(dāng)將它作為另一個(gè)單獨(dú)的流程模型，與當(dāng)前的維修流程模型區(qū)分開來。

通過調(diào)研可以發(fā)現(xiàn)，客戶服務(wù)中心這邊往往在完成物業(yè)服務(wù)之后還會(huì)有一次回訪調(diào)研的過程；因此在維修結(jié)束，確認(rèn)業(yè)主驗(yàn)收完成后，我們也應(yīng)當(dāng)加上回訪的過程，但是回訪并不存在于某個(gè)特定的流程中，因此我們?cè)诖颂帟簳r(shí)省略，后續(xù)作為一個(gè)獨(dú)立的流程進(jìn)行建模。

另外，客戶服務(wù)中心還需要在派單之前與業(yè)主進(jìn)行事前溝通，需要有一定的規(guī)則來給維修事項(xiàng)進(jìn)行分級(jí)：

• 是小修，中修，還是大修？
• 是否需要收費(fèi)？

經(jīng)過調(diào)研我們可以了解到：

• 三種類型的維修都有可能會(huì)需要收費(fèi)；
• 中修和大修往往還需要經(jīng)過額外的審批流程才能繼續(xù)。

我把維修項(xiàng)目評(píng)估任務(wù)放在了這里，是因?yàn)榭头?lián)系業(yè)主之前需要知道維修的價(jià)格以及其他情況。

機(jī)電維修部這邊應(yīng)當(dāng)考慮以下因素：

• 主管分配工作的細(xì)節(jié)；
• 是否應(yīng)當(dāng)記錄返工次數(shù)？
• 區(qū)分不同級(jí)別的維修項(xiàng)目。

主管分配工作這個(gè)任務(wù)的前置條件是收到維修需求，確切的說，是收到由客戶服務(wù)中心填寫的工程單匯總表；當(dāng)前表中已存在的屬性可能有客戶的姓名、維修地址、聯(lián)系電話、維修內(nèi)容、預(yù)約時(shí)間等。

主管此時(shí)需要根據(jù)已知的情況，判斷當(dāng)前的維修方案是否需要走額外的審批流程，而這個(gè)流程，應(yīng)當(dāng)與當(dāng)前的維修流程獨(dú)立開來；至于這個(gè)額外的流程有著怎么樣的過程，目前我無法得知，因此依然用一個(gè)子流程來代替。

倉管這邊需要考慮驗(yàn)收沒有通過的情況下，流程如何進(jìn)行？ 這里的驗(yàn)收事實(shí)上應(yīng)當(dāng)是物料倉庫的驗(yàn)收，與維修流程無關(guān)，但是客戶往往無法清晰的表達(dá)出來這層意思；因此這邊應(yīng)當(dāng)暫時(shí)省略驗(yàn)收這個(gè)步驟，作為一個(gè)獨(dú)立的物料倉檢流程在下一步的時(shí)候進(jìn)行建模。

最后是接線員，接線員的流程比較簡單，接到電話報(bào)修后填寫維修單就可以：

五、技術(shù)流程模型設(shè)計(jì)

之前都是講的人與人之間的流程，從這步開始引入流程引擎，原因之前也提及過，開發(fā)者需要知道他們要用流程引擎來做些什么事情，因此這個(gè)步驟也會(huì)添加包括技術(shù)實(shí)現(xiàn)上的更多細(xì)節(jié)；比如對(duì)于業(yè)主是否已經(jīng)付款的校驗(yàn)，但第一版的技術(shù)流程模型不一定是可執(zhí)行的。

第一版的技術(shù)流程模型如下：

再接下來的設(shè)計(jì)，就需要考慮更多外部因素了，如果我們發(fā)現(xiàn)維修流程中，某個(gè)泳道的流程能夠被其他的流程模型復(fù)用，我們就需要將他們抽離并單獨(dú)部署；如果我們滿足于將這個(gè)龐大的維修流程進(jìn)行單獨(dú)部署，那我們可能還需要再做更多的修改，尤其是事件類型上（消息事件的用法在這里是違反BPMN規(guī)范的，如果部署在同一個(gè)流程定義中的話，更適合的是條件事件）；情況不同，我們后續(xù)的設(shè)計(jì)和實(shí)現(xiàn)也會(huì)非常不一樣。

對(duì)于當(dāng)前這個(gè)維修流程，我更傾向于將所有流程都分開設(shè)計(jì)和實(shí)現(xiàn)，主要理由有如下幾點(diǎn)：

1. 一個(gè)龐大的模型，它的版本遷移過程往往非常復(fù)雜，如果將它進(jìn)行恰當(dāng)?shù)姆纸?，那么我們只需要?duì)發(fā)生了變動(dòng)的部分進(jìn)行遷移即可，可以有效的降低遷移成本。
2. 對(duì)于開發(fā)者來說，龐大的或者過于復(fù)雜的模型會(huì)導(dǎo)致理解和開發(fā)成本迅速上升，而且一個(gè)單體模型，幾乎只能由一個(gè)開發(fā)者來負(fù)責(zé)，不適合多人協(xié)作；而分解的手段可以將一個(gè)單體復(fù)雜模型分解成多個(gè)簡單、可獨(dú)立開發(fā)的流程模型，可以提升開發(fā)效率和降低理解難度。
3. 對(duì)于企業(yè)工作流來說，多個(gè)工作流之間經(jīng)常會(huì)存在共通的部分，就像這里的物業(yè)服務(wù)的回訪流程，將這些公共部分剝離出來；長遠(yuǎn)來看，可以提升模型的復(fù)用率，從而提升開發(fā)效率。

但是這種方案的缺點(diǎn)也是顯而易見的，主要有：

1. 分解到什么程度并不那么容易把握，雖然按照經(jīng)驗(yàn)來說往往是分解到每一個(gè)流程參與者，但在有些時(shí)候也可以將一些任務(wù)比較簡單的參與者流程進(jìn)行合并。
2. 為了實(shí)現(xiàn)流程實(shí)例之間的通信，往往會(huì)存在較多的消息/信號(hào)事件或者調(diào)用活動(dòng)，要求開發(fā)者對(duì)BPMN中的事件有足夠的了解。
3. 流程走向的觀測(cè)可能會(huì)比較繁瑣，因?yàn)樾枰诙鄠€(gè)流程實(shí)例之間來回切換觀察。

下面給出第一版的技術(shù)流程實(shí)現(xiàn)：

業(yè)主流程：

接線員流程：

行政部流程：

客戶服務(wù)中心流程：

維修主管流程：

維修工流程：

倉管流程：

回訪流程：

客服專員催修：

客服專員統(tǒng)計(jì)：

六、結(jié)語

最終的流程模型依然還有很多值得改進(jìn)的地方，比如支付流程的分離和異常處理，維修主管分配任務(wù)的自動(dòng)化規(guī)則，接線員流程的規(guī)則化（使用規(guī)則任務(wù)來根據(jù)輸入?yún)?shù)判斷該發(fā)送什么類型的消息事件，可能是代填維修單，也可能是代填其他的表單）；但出于成本考慮我們不可能就第一版的實(shí)現(xiàn)去無止盡的細(xì)化。

BPMN是一個(gè)很深的學(xué)問，根據(jù)業(yè)務(wù)的復(fù)雜程度，它的建模方法和難度都會(huì)大不相同，甚至?xí)泻虲MMN結(jié)合使用的情況。

至此，本文就告一段落了，希望我的文章能引起身為讀者的你的思考。

作者：悉爾科技? LLLimbo

本文由 @LLLimbo 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自?Unsplash，基于 CC0 協(xié)議