前言

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

顯然，由於院內各種不同的業務，就會有各種不同性質的資訊系統來協助，例如，掛號人員透過 “掛號系統” 來處理病患的掛號資訊；醫生透過 “看診系統”，來查詢與紀錄病人的病歷並開立藥方；藥劑師透過 “藥劑管理系統” 來配送藥品並處理病患的領藥事宜。可以這麼說，一家規模如「信仁慈善綜合醫院」，其內的醫療資訊系統，可能不下數十、甚至上百個系統之多，這些系統是否是由一家承包廠商來統籌管理與發包，是否要求系統的單一平台，以簡化系統的溝通，不得而知，但確定的是，站在院方的角度來看待時，絕對有必要委請熟嫻醫療業務的領域專家(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)內，如此才有可能 “聚焦”，確實收斂系統的範圍，而不致於上綱到企業層次的業務流程，把系統責任給複雜化。範圍釐清後，就可以找出誰來操作系統、系統應該提供哪些服務與功能、系統是否需要外部系統的支援等。

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