【UML實戰智慧第2回】業務流程建模常見3大現場問題

在UML專案現場，系統分析師可以發覺活動圖（Activity Diagram）比較常被用來表達下列三種流程，分別為業務流程（Business Process）、系統流程（System Process）以及操作流程（Operational Process）。

在我的專案經驗中，倒是比較建議，倘若欲建置的系統並沒有明顯涉及到業務流程時，其實真的沒有必要硬是要產出活動圖。當然，如果遇到建置的系統明顯涉及到複雜的業務流程時，最好可以採用活動圖來表達業務流程，這可以帶來下列幾項好處：
1. 系統分析師可以透過活動圖，來跟使用者或客戶溝通並確認未來系統上線之後的業務流程。

2. 系統分析師可能會需要透過活動圖中的流程動線和控制節點，來表達使用案例執行時的流程動線與邏輯控制。

3. 系統分析師也可以透過活動圖，找出可能遺漏的使用案例（Use Case）。

其實，多數專案時程都被壓縮的很厲害，繪製每一款或每一張UML圖都要花時間、花成本，實在沒有必要為了需要交付分析設計文件，硬是繪製了一堆UML圖。

再者，UML是一種用來溝通的圖形語言，倘若在使用任何一個圖示（詞彙）時，客戶／使用者（甲方）、建置團隊／繪製者／觀看者（乙方）、獨立監審商（丙方）等多方沒有一定水準的共同認知的話，UML就失去了溝通的功效，而且還可能會成為專案成員爆肝的原因之一。

業務流程的定義
Wiki百科對於“Business Process”（業務流程）的定義，十分簡單明瞭、容易理解，可以歸納出業務流程幾個重點，如下：
● 業務流程主要由一組相關的活動（activity）或任務（task）所組成。

● 每一條業務流程通常會有一個特定的目標（goal）。

● 企業或組織在執行完業務流程之後，會提供特定的服務（service）或產出特定的產品（product）。（亦即達到了特定的目標）

● 業務流程之所以設立特定的目標，經常是為了提供給某一個或者某一群特定的客戶（customer），一項具體且能夠被評價的服務或產品。

最後，我們透過心智圖（mind map）呈現上述的重點，善用圖像來協助我們加深印象、強化記憶，如圖1所示。

圖1 業務流程的定義[心智圖]
常見現場問題

在對於業務流程的定義有一點點初步的共識後，我們緊接著來看在UML專案現場中，系統分析師在動手繪製活動圖之前，經常會遇到那些現場問題，而且又該如何處置呢，如圖2所示。

圖2 業務流程的現場問題[心智圖]

繪製？或不繪製？
一直以來，我都是非常建議系統分析師在分析階段，撥一些時間來繪製活動圖的。不過，這樣的建議，在UML專案現場時，也是經常會出現不適用的例外狀況。

我曾經參與過兩個大型專案，專案底下當然包含了十多個、甚至數十個子系統，這兩個專案不約而同地都規畫了一個用來維護共用資料的子系統。諸如此類的公用系統，通常只支援非常片段的業務流程，想要從中找出完整的業務流程可能並不恰當。如果，硬是強求系統分析師在這種情況下繪製活動圖的話，很有可能最後就會變成使用活動圖來描述系統流程或操作流程了。

在很多大型的專案中，客戶／使用者（甲方）會在合約上嚴格地規定建置團隊（乙方）需要交付那些文件。特別是在重要的系統需求規格書（SRS，System Requirement Specification）及系統設計規格書（SDS，System Design Specification）中，客戶／使用者有時還會一併規範了文件的目錄章節，想要藉此管制系統分析師與系統設計師（乙方）的作業和產出。

而且，這樣的文件規範通常會一體適用，不會因為某些系統無明顯業務流程，就特別刪去相關章節。所以，系統分析師若遇到這類無明顯業務流程的系統時，可以秉持著自身的專業素養，與客戶／使用者（甲方）和獨立監審商（丙方）溝通協調，省略這項工作及產出，不要把生命浪費在這種無謂的文件上頭。

很多時候，客戶／使用者（甲方）可能不怎麼懂UML，獨立監審商（丙方）則可能不怎麼懂領域（domain）。在這種情況下，甲方或丙方可能都不易判斷出何時無須繪製業務流程，這時身處其中的系統分析師（乙方）就可以跳出來，以其專業與客戶／使用者（甲方）和獨立監審商（丙方）溝通協調。

未來流程？或現行流程？
系統分析師要是經過了第一個現場問題，確定要採用活動圖繪製業務流程之後，可能會遇到的第二個現場問題是，需要繪製未來的業務流程還是現行的業務流程？

理想上，我們會希望可以先繪製一份現行的業務流程，然後再繪製另一份未來的業務流程。這麼一來，除了可以讓相關人員看到系統上線前後業務流程的差異，也可以顯示建置新系統所帶來的便利與價值。

不過，理想歸理想、理論歸理論，在UML專案現場是非常現實的，一分一秒都在燒錢，所有的工作或產出總是能省略就省略、能刪除就刪除。如果，在UML專案現場少了某項工作或產出也無傷大雅的話，那就是跳過、刪掉、不用做。

換句話說，在UML專案現場中，系統分析師若決定要採用活動圖繪製業務流程的話，就請直接繪製系統建置之後的未來流程吧，別花時間繪製即將過時的現行流程了。

業務流程？或系統流程？

系統分析師在UML專案現場可能會遇到的最後一個問題是，到底該用活動圖來繪製未來的業務流程，還是繪製上線系統的內部流程呢？在錢要花在刀口上，而且專案時程永遠都被壓縮的情況下，這個問題的答案其實不言而喻；我們當然會建議系統分析師使用活動圖來繪製企業組織未來的業務流程，而非系統內部的系統流程啊，如圖3所示。

圖3 現場問題的建議答案[心智圖]

不過，首先此處我們要先澄清一點，就是：其實在UML規格書中並沒有限制活動圖只能用來表達業務流程，或者不能用來表達系統內部的系統流程。活動圖到底想要用來表達什麼樣的流程，完全取決於繪製者。但是，有時候，繪製者自己也不太清楚自己到底拿活動圖表達那個層級（業務或系統）的流程，甚至有時候也會出現不分層級、混雜在一起使用的狀況。所以，若是系統分析師在UML專案現場，發覺使用者／客戶（甲方）、建置團隊（乙方）和獨立監審商（丙方）三方可能各說各話或是沒有共識時，我會建議系統分析師翻出此處的表1，甚至把這張表做成投影片，用來說明並取得甲乙丙三方的共識。

表1 活動圖用於表達業務流程或系統流程

其實，針對UML／SA的所有概念，最好都可以取得使用者／客戶（甲方）、建置團隊（乙方）和獨立監審商（丙方）三方的共同認知，這樣三方才能協力運作，如圖4所示。

圖4 三方協力運作

最後，我們再回過頭來看系統流程這個議題。想當然爾，系統流程也是十分重要的，不過是否該要求系統設計師使用活動圖來表達系統流程，這可能有協商討論的空間。實務上，我們通常會要求系統設計師在系統設計階段，針對每一個使用案例對應產出一張或多張的循序圖（Sequence Diagram），用來表達系統內部一群物件實現使用案例的互動狀況。具體來說，系統設計師可以繪製循序圖來呈現程式執行時，依序呼叫（call）多個方法（method）或函數（function）的動態運作狀況。

不過，說是這樣說，我在UML專案現場其實也是經常遇到客戶／使用者（甲方），要求建置團隊的系統設計師（乙方）必須在系統設計規格書（SDS）中，同時繪製活動圖和循序圖，前者呈現系統流程，後者呈現物件互動。當然，活動圖與循序圖兩者各有優缺點，您可以看一下表2的比較表。

表2 用於系統設計階段的活動圖與循序圖

理想狀況是，針對系統流程較複雜的使用案例，要求系統設計師要同步產出呈現系統流程的活動圖，但是不要針對每一個使用案例，都要求產出活動圖。附帶一提的是，針對每一個使用案例，通常會要求系統設計師產出一張或多張的循序圖，這已經屬於系統設計階段的事情了。現場的作業程序

我在擔任開發專案的UML/SA顧問時，通常都會直接提出作業程序：

1. 系統分析師使用活動圖，繪製系統上線後的未來業務流程。

2. 系統分析師在產出活動圖之後，舉行確認會議，邀請客戶／使用者到場修訂並確認業務流程的內容。

3. 在舉行過確認會議之後，系統分析師還需要產出支援業務流程的初版使用案例圖（不含使用案例敘述）。

上述的第二步驟舉行確認會議，其實是相當重要的，建議系統分析師在會議開始的前一周，就已經先將業務流程的電子檔（或紙本）交付給相關的使用者／客戶，讓相關人員能夠在會議之前有時間先看過資料。

系統分析師要特別注意，使用者／客戶本身也有很多業務要做，通常不怎麼願意花太多時間在建置團隊上頭。所以，系統分析師要把握使用者／客戶參與會議的難得機會，盡量在會議當場就邀請使用者／客戶加入，協同修改出有共識且經過確認的未來業務流程。

再者，有時候，使用者／客戶（甲方）在心態上也會認為自己是花了大錢請建置團隊（乙方）來做事的，所以不見得會好聲好氣地對待建置團隊。在這種不怎麼對等的關係中，系統分析師絕對要把握時機，趕緊跟使用者／客戶把系統上線之後的未來業務流程確認下來。

在下一回內容中，我將一步一步地示範，帶著系統分析師們，一邊學習一邊繪製出表達業務流程的活動圖。