越是大型公司的 IT 資訊單位，無論是外包或是自行維護/開發的系統，在作「需求分析」階段時，往往都會表達到所謂的「業務流程 (Business Process)」。
甚麼是業務 (或稱為企業)流程？ 這裡節錄 Jacobson 《Object Advantage》一書中，將企業流程定義為：
Put simply, a business process is the set of internal activities performed to serve a customer.（《Object Advantage》, Ivar Jacobson, 1994, p. 3）
（簡單地說，企業流程就是要能夠服務客戶的一連串企業內部的活動）
或者更簡單的解釋，業務流程表達的就是：某個人在某個時間點所作的某件事 (而這些事會呈現出關聯性與先後順序)。
而甚麼是「大業務流程」？簡單的說，就是業務流程範圍更為廣泛，參與的人更多，所涵蓋的時間更長。而且往往因為現實上基於功能執掌，還是不同部門或不同地點就有不同的作業規範與範疇，但彼此這些作業之間仍需要連串在一起。
例如，物流零售業領域，為了表現出從門市的「訂貨/退貨」，到總部的「進貨/出貨」，乃至於轉入財會單位的「帳務處理」，每一個業務範疇，就有其作業流程/作業規範；而把「訂貨/退貨」→「進貨/出貨」→「帳務處理」等作業流程串聯成更大的流程，即為所謂的「大業務流程」。
我走訪過許多大型的 IT 單位，包括顧問輔導或教學等。檢視從該單位 SA (System Analyst, 表示為需求分析師)所整理的業務流程設計圖，無論是使用傳統的流程圖 (flow-chart)，甚或採用 UML 語法所表達出來的活動圖 ((activity diagram)，幾乎普遍是存在兩大問題：
- 想要利用一張圖表現出所有的細節。
- 把資料作為主體，呈現的就是資料傳遞的流程。
第二個問題最難解，這裡牽涉到的就是「資料導向 (data-oriented)」 vs. 「服務導向 (service-oriented)」的分析/設計態度。
若從上述對業務流程的定義，或是後續利用使用案例 (use case)的分析技術，國外軟體大家的最佳實務經驗 (best practices)，均是偏向「服務導向」的開發模式。簡而言之，就是將資料封裝 (encapsulate)至服務之內，如此可避免過早揭露繁瑣的細節。
第一個問題則比較容易調整，主要就是把握住一個最基本的原則：設計圖要能維持「簡潔」。
「簡潔」的目的在於要能適切突顯出「焦點」之所在，而把諸多繁瑣的細節給封裝住。待決定集中的焦點後，再來才是將其內部「剖開」，探究細節的組成與關聯性。
而要能達成簡潔，就需要考量兩個構面－「廣度」與「深度」，要讓設計有「層次感」。
簡而言之，「廣度」考量的是所涵蓋的範圍；「深度」則是考量所揭露出細節的精細度。
以「大業務流程」的設計呈現，我這裡推薦採用「三層次」的表達，我把它稱為 MSS (Multiple - Single - System) 塑模表示法。
- M (Multiple) Process－表達多個業務流程 (Business Process)之間的關聯性，利用「Erickson Penker (俗稱火箭圖) 流程擴展語法」表達。
- S (Single) Process－表達單一業務流程內的作業活動 (activities)。利用 UML 「活動圖」表達。
- S (System) －表達資訊系統所擔負的功能。利用 UML「使用案例 (use case)圖」表達。
閱讀全文 »
