大業務流程塑模的MSS三層次原則

越是大型公司的 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),幾乎普遍是存在兩大問題:

  1. 想要利用一張圖表現出所有的細節。
  2. 把資料作為主體,呈現的就是資料傳遞的流程。

第二個問題最難解,這裡牽涉到的就是「資料導向 (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)圖」表達。


這裡就直接借用 Ringle 著作-「UML團隊開發流程與管理(第2版)」,其中 8-1-2 章節內的範例-「電子化採購系統的企業流程」,來說明 MSS 三層次表達的重點。

  • 第一層-火箭圖

    「請/採購業務流程」-火箭圖
    圖1. 「請/採購業務流程」-火箭圖 (Erickson-Penker extension notion).

    當想表達多個業務流程之間的關聯性,並觀察期間重要的輸入/輸出 產出物、參考資訊,以及各作業流程所突顯的目的 (goal),建議使用火箭圖表達,它非常適合表現出所謂的「總覽 (overview)」呈現。

    以上圖1.而言,就可以從其中看得出主要表達兩個業務流程-「請購」與「採購」流程,以及各作業流程主要所參與的人員 (供應商、採購人員),還有兩個流程之間的中介產出-請購確認資訊。更重要的是,突顯出每個流程運作的目的-「請購流程」決定供應商順位優先順序;「採購流程」期望採購高品質物料。

    強烈建議,火箭圖與活動圖的參與人員,宜用角色/部門/組織等表示,也就是從傳統 "人" 的角度來看流程的運作,而沒有資訊系統的參與。資訊系統會延宕至第三層的使用案例圖來呈現。

    主要的原因,在初期的分析階段,過早決定資訊系統的範圍並不妥當,它已經需要從企業經營的角度轉移到資訊系統的規劃,而資訊系統一般則是由軟體架構師 (architect)作整體性的系統規劃,過早加入資訊系統的角色於傳統企業流程上,會造成責任分派上的混淆,且相對也造成設計圖上的複雜度。

  • 第二層-活動圖

    請購作業流程-活動圖
    圖2. 請購作業流程-活動圖 (activity diagram).

    UML 活動圖適合用來表達單一業務流程內的活動細節。觀察上圖1.火箭圖,當欲進一步探究「請購流程」內的作業活動,則可將其 "剖開" (UML 工具可利用超鏈結關聯火箭與活動圖的連結),並利用活動圖展現內部的作業活動情形。

    從圖2.就可以清楚的看出有兩個角色 (或組織單位)參與「請購流程」的作業活動,並於不同的時間點有著各自需擔負的活動工作。與火箭圖一樣的是,盡量不要在兩個層次內表達「資訊系統」角色的參與,盡量強調的就是傳統「人本」的業務流程。

    活動圖最不容易區分的是「活動 (activity)」與「行動 (action)」的界定。簡單的說,在一個「活動單元」內,可包含多個行動。而如何適切界定「活動」的單位,則另文再介紹說明之。

  • 第三層-使用案例圖

    電子化採購系統-使用案例圖
    圖3. 電子化採購系統-使用案例圖 (use case diagram).

    從上圖2.活動圖只表達「人本」的作業活動,再來更進一步來觀察有哪些活動是需要資訊系統的支援,以及是哪一個資訊系統 (名稱)。而當活動轉成由資訊系統來實現時,即成為資訊系統所需擔負的「功能」,也就是稱之為「系統功能 (system functions)」。

    利用使用案例圖 (use case diagram)來表達系統的功能,可說是最佳的利器。因為它可以界定系統開發範圍 (system boundary)、誰來使用系統,以及系統是否需要其它系統的支援。每一個系統功能即成為一個使用案例 (use case),而後再撰寫已過濾的使用案例需求陳述,即可以非常直覺且順暢地橋接至程式寫碼與結構設計 (包括物件與資料模型)階段。

    觀察圖3.使用案例圖,可以理解要開發的資訊系統為「電子化採購系統」,擔負的系統功能 (亦即橢圓形的使用案例)諸如「比價」、「產生請購需求」等;使用系統的參與者 (actor)有 ERP 系統、採購人員、供應商;而系統需要透過「通知系統 (Notify System)」的支援,來達成傳遞通知訊息的需求。

    關於如何從活動圖的活動,轉化至使用案例圖的使用案例,可參考先前寫的一篇:「從企業流程(活動)圖找出資訊系統的使用案例」。

設計圖是否能作為有效的溝通與系統開發依據,務必要能適切的表現出焦點之所在。而要能「聚焦」,設計圖就要要能表現出「簡潔」。「井然有序,層次分明」,溝通也比較不致於陷入細節上的紛爭,如此開發節奏才會更能順暢。

文章導覽

   

共有 4 則迴響

  1. Hello~ kenming大大,takeshi來拜讀您的文章了
    此篇文章(還有另一篇「從企業流程(活動)圖找出資訊系統的使用案例」)在概念上,跟Alistair Cockburn提出的Goal Level(White/Blue/Indigo/Black),或者是 邱郁惠小姐 的企業使用案例和系統使用案例,很類似,不過kenming大大提出的MSS,更讓takeshi覺得容易上手和理解,在圖形的使用上更不容易混淆

    takeshi在需求工程這一塊,目前主要是使用Goal Level這個工具,但總覺得跟之後的OOAD使用UML這一塊,有一些ㄎㄟˊㄎㄟˊ的,感覺不是很一致;現在看到了此篇好文,對takeshi很有幫助,有幫助到剛剛takeshi立馬去天瓏下訂,買一本「UML 團隊開發流程與管理, 2/e」,好好咀嚼

    如有問題還請kenming大大不吝指教 ^^

    • 我有在您的 blog 留言說,設計圖這東西,就是在廣度與深度之間,抓到適切的焦點。焦點能確立,才較有機會針對單一議題作討論與提出相關解決方案的。

      再則,設計圖要能有自己 “自圓其說” 的論點,它並非是定義還是方法,在其根本上,有它想要表達更深一層的內涵。

      而若是他人 (或著書的作者)的設計圖,那就是要能感受到對方的設計意涵為何,並能消化成為自己的想法。並非是模仿或抄襲,那樣意義不大。

      舉 Cockburn 那本書為例,若是弄清系統範圍的定義,也就是在廣度與深度之間,抓到適切表達的 Use Case;所以相對來說,你就會了解何謂 business or system level UC,原來就只是系統的定義,以及廣度的界限,如此而已。

      • takeshi的確可以感受到kenming如上所說的,關於設計圖的焦點、和其廣度與深度之間的拿捏,但如何拿捏到適當的位置才可以清楚表達亦或者是精鍊自己的想法,是takeshi正在學習和突破的地方。

        除此之外,適當的工具也是必要的,類似的概念,方式百百種,相較於Cockburn主要是使用文字的UC來描述不同的廣度和深度,takeshi覺得kenming提出的MSS,更能有效率地表達其焦點,可幫助團隊之間的溝通。

        在takeshi所處的環境,目前沒有一個mentor可以來討論或是分享;所以自己學習的方法,就是在網路或書籍中看到,認為可以對團隊有幫助的工具或概念,就拿出來PDCA一下 :p,再進一步慢慢累積出自己的想法;所以kenming的建議,takeshi會虛心檢討的,謝謝kenming^^

        • 其實沒錯,我們也都是這樣走出來的。 ^^

          很高興除了實作議題之外,也可以涵蓋到軟體設計其它面向的議題。絕對歡迎 takeshi 透過 blog or Msn or Email 等,持續相互討論。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *