【iThome 連載單元—5】釐清系統設計範圍的焦點–建立企業與資訊系統層次的使用案例模型

前言

以「信仁慈善醫院」為例,醫院內的業務服務範圍是何其的廣與雜,院方除了有醫師、護士、藥劑師、行政人員 …等內部工作人員擔負各自的執掌與協調合作外,現代化的醫院更是需要有資訊系統的協助,來減輕工作人員的負擔與達成某種程度的自動化。

顯然,由於院內各種不同的業務,就會有各種不同性質的資訊系統來協助,例如,掛號人員透過 “掛號系統” 來處理病患的掛號資訊;醫生透過 “看診系統”,來查詢與紀錄病人的病歷並開立藥方;藥劑師透過 “藥劑管理系統” 來配送藥品並處理病患的領藥事宜。可以這麼說,一家規模如「信仁慈善綜合醫院」,其內的醫療資訊系統,可能不下數十、甚至上百個系統之多,這些系統是否是由一家承包廠商來統籌管理與發包,是否要求系統的單一平台,以簡化系統的溝通,不得而知,但確定的是,站在院方的角度來看待時,絕對有必要委請熟嫻醫療業務的領域專家(Domain Expert)來規劃與設計、紀錄各類醫療與行政的業務流程 (Business Process),才有可能將流程的部分或全部的活動 (Activity),交付給資訊系統作自動化;同樣地,統籌所有資訊系統的架構整合廠商 (也有可能是院方的資訊單位擔任),必須要能有完整的 “Whole Map”,瞭解哪一個資訊系統是在哪一個業務流程的哪一個活動、有哪些使用者會來使用系統、系統是否會需要另一個資訊系統的服務 …等,如此才有可能清晰、明確地掌握,哪些資訊系統是可以同時外包 (Outsourcing)、哪些系統可以 “再利用” 既有的系統服務,系統之間,又該如何傳遞訊息、如何制訂標準的介面溝通規格。即使你是二包的廠商好了,承接某一個資訊系統的設計與實做,你仍須知道,這個資訊系統是處在整體架構中的哪一個 “點 (系統)”,這個 “點”,有沒有從其它的 “點” 進入的資訊、有沒有要將資訊傳出至其它的 “點”,也就是說,要能清楚系統的設計範圍,是在位於那一個層次(Layer)、系統的範圍又是多廣,與外界的互動又是如何,如有才有可能 “聚焦”,往對的方向走、作對的事 (Do the right thing and Do the thing right)。

企業層次 vs. 資訊系統層次

其實,領域專家是可以與資訊專家合作的,來完成在企業面的設計。對領域專家而言,流程的設計與規劃,是屬於 “企業流程再造 (BRP, Business Process Re-engineering)” 的範疇,而對於資訊專家,是可以把 “企業當系統” 來看待,然後利用 “企業塑模 (Business Modeling)” 的技巧,來協助企業流程、規則等的設計與記錄,真正企業的資產,就是將領域專家們的智慧,經過 “企業塑模” 所粹取之後的產出(Artifacts)!!

參考企業塑模的產出,就可以很清楚地瞭解與規劃,哪一些企業流程的活動,是可以經由資訊系統的協助,來達成自動化或減輕工作人員的負擔。

如何分辨塑模設計的產出是屬於企業的層次,還是屬於資訊系統的範疇呢? 筆者最偏好利用 “使用案例圖 (Use Case Diagram)” 來區分兩者的層次,其實根本原理也就是界定系統的範圍後,區別這個設計的範圍,就能知道是屬於企業還是資訊系統的層次,而且經由一些簡單的原則與步驟,還能從企業層次的使用案例模型,轉成資訊系統層次的使用案例模型。

觀察與建立企業與資訊系統的使用案例模型

參考下圖1,這絕對是一個企業層級的使用案例圖,為什麼?因為,系統所涵蓋的範圍是整個醫院。這張企業層級的使用案例圖最有價值的地方在於:真正對企業具有經濟效益的外部參與者 (Actor),來使用這個系統 (企業) 的主要目的 (企業的核心流程)。

範例-企業層級的使用案例
圖1、”範例-企業層級的使用案例

觀察圖1,其系統範圍為 “信仁慈善醫院”,主要的參與者為 “病人”,”病人” 來到醫院的主要目的為 “看病”。”看病” 為該醫院的核心業務流程,也是 “醫院” 為了滿足主要參與者的 “目的”。

“看病” 的業務流程,可以利用 UML 的活動圖 (Activity Diagram) 來描述,如下圖2(僅為範例,並非是完整正確的看病業務流程)。

範例-看病的業務流程
圖2、”範例-看病的業務流程

利用活動圖可以記錄詳細的業務流程,也可以看出哪些活動(Activity)是由哪些人或角色所負責的(利用 Partition 區分責任區塊)。

活動圖表達了企業內部的組織運作,但不容易表達出與該業務流程相關的外部主要參與者(Primary Actor),企業是如何滿足其目標。亦即,若想明確區分企業的 “內” 與 “外”,我們可以利用如上圖 1 的 “企業使用案例圖(Business Use Case Diagram)” 來表達。表達企業層次的使用案例圖(Business level UCD) ,有幾點要注意的:

  • 系統的設計範圍一般以企業、部門等組織為單位,而非單指軟體應用系統。
  • 會著重於描述企業內部的流程;而非系統功能面的行為描述。
  • 通常會以白箱式(White-box)的作法打開企業使用案例(Business Use case)內部,以瞭解內部工作者(internal worker)互動合作的流程。
  • 目標讀者(Target audience)會偏於企業決策層級的管理者、IT高階主管、系統開發的架構師(Architect)等,可以藉由企業層級的使用案例圖來辨別出組織的核心業務。
  • 可以協助從企業流程往技術層面來思考,以定義出適合採用新技術的業務流程。例如,有些人工作業流程,可以藉由電腦資訊化以增加作業效率與成本因素等考量。

為了瞭解其業務流程的內部是如何運作,我們可以以白箱式的表達來剖開 “看病” 這一個企業使用案例,如下圖3。

範例-用白箱的手法呈現企業內部運作流程的組成元素
圖3、”範例-用白箱的手法呈現企業內部運作流程的組成元素

從圖3,可以觀察出 “看病” 這個業務流程,在系統的內部,是由哪些組成元素來完成這個任務。組成元素包括了:內部工作人員、資訊系統等。再來,瞭解這些組成元素互動合作的流程後,就可以得出整體資訊系統層次的使用案例模型,如下圖4。

範例-整體資訊系統層次的使用案例模型
圖4、”範例-整體資訊系統層次的使用案例模型

站在院方的角度,可以把如圖4的掛號、看診、藥劑管理等資訊系統,同時間外包(Outsourcing) 給各個獨立的承包廠商,例如負責看診系統的設計與實做的承包廠商,並不需要讓該廠商瞭解涵蓋看病的整體業務流程,以及如掛號與藥劑管理等領域內的知識與規格,只要讓其瞭解,掛號與藥劑管理系統未來會成為 “看診系統” 的外部參與者,會傳入與送出資訊。所以需要規範的只是,與外部系統之間的溝通協定(Protocol),以及傳遞資訊的格式等,例如使用 “Web Service” 或 “Message Queue” 作為連結的協定、利用 XML 作為資訊的格式 (Format)。

結語 – 將焦點從大範圍精確收斂成系統開發的責任範圍內

利用使用案例圖,可以協助我們從 “鳥瞰” 的視野看系統的全貌、界定系統的範圍、區分系統的內與外(這很重要,如此才能知道什麼該作,什麼不需作)。還有,也比較容易看出使用案例的所表達的層次(level),如企業層級(Business level)、資訊系統層次(System level)等。

企業層級與資訊系統層級的使用案例模型,差別其實只在於系統範圍的大與小。但兩者所表達的意涵是不一樣的:企業層級的使用案例圖,反映的是核心業務流程與其所帶給企業外部用戶的經濟效益;資訊系統層級的使用案例圖,反映的是操作該資訊系統的操作者 (大部分內企業內部的工作者),可以協助其減輕業務工作量與部分業務流程的自動化。

整體、完整的業務流程,會是透過眾多工作人員與好幾個不同性質的資訊系統,協同合作來完成的,而不會是只有一個資訊系統來完成一切。那麼,對只承包某一個資訊系統的廠商而言,雖然不需要瞭解完整的業務流程,但必須知道,該資訊系統,是在整個流程中,位於哪一個活動 (Activity)內,如此才有可能 “聚焦”,確實收斂系統的範圍,而不致於上綱到企業層次的業務流程,把系統責任給複雜化。範圍釐清後,就可以找出誰來操作系統、系統應該提供哪些服務與功能、系統是否需要外部系統的支援等。

“架構” 首重整體,而開發團隊對所謂的整體要能有共識,前提是要能確定系統的設計範圍。我們常以為,系統範圍是固定且明確的,其實不然,筆者的輔導經驗中,發現到團隊成員之間,對系統的範圍界定,常常是模糊不清的。而系統範圍的不明確,往往是造成未來資訊系統開發混亂與複雜的元兇!

文章導覽

   

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *