本文首載：CIO 的天空 

　　在《資訊透明化對營運流程的衝擊》這一篇文章中，我們提到：企業經由SOA所整合的資料可以藉由商業智慧（BI，Business Intelligence）系統的協助，更進一步地加值資料（訊），創造更多的價值。接下來，再繼續SOA的討論前，我們先發一點時間來看商業智慧系統。

 只是跟著國外的腳步走嗎？

本文首載：CIO 的天空

　　上次提到SOA可減少人員忙亂打電話的時間。但，資訊透通了，對營運流程及企業競爭力倒底有何作用？

縮短商業流程的反應時間

　　資料透通性的強化，會造成什麼樣的結果呢？從剛才供應鏈的例子來看，我們會發現，對經銷商來說，他們不用浪費太多時間在跟催與資料的比對上面；製造商也不 用花費太多的人力回應經銷商的詢問；經銷商與供應商的關係也是相同。所以整體而言，員工們就可以有更時間來做更有價值的事，例如：搶下更多的訂單。

　　特別說明的是，商業流程的反應時間也相對縮短了。再以剛才供應鏈的為例。通常，我們在預估交期時會把溝通所需時間成本評估進去，所以整個供應鏈中的每一個小單位，都會因溝通產生時間成本；或許每一個小單位的溝通時間成本是很小，但在全球化的經營中，這些小的「溝通時間成本」會因著「時差」而被拉大（例 如，台灣業務同仁要向美國的伙伴詢問資料的時候，通常很難即時地找得到人回覆，總要利用電子郵件或其它方式留下問題，等待他們上班後才能答覆。而利用 SOA 來分享整合資訊後，這一些等待的時間就可以被節省下來了），而如果再把這些零零總總的「小」溝通時間成本累加後，往往就是一個很長的時間。

　　因此，隨著資訊透通性的強化，整體溝通成本也 就大量減少。或許在 SOA 剛導入完成的初期，大家還是依據舊有習慣來預估交期，不過，隨著使用者對新運作模式的熟悉與了解，管理者可以慢慢地業務同仁來討 論，以縮短交期。供應鏈中的交期是如此，企業中其它的商業流程亦然，特別是針對全球化經營的企業而言，這種效益會特別明顯。

資料與資訊的加工更容易

　　除了加速企業的生產力及業務流程反應時間外，資訊透通性的結果也可以讓使用者或管理者在同一個時間點上可以看到更多資訊，但是這並不一定是好的，特別是如 果資料沒有做適度的過濾、轉換或整理的情況下，使用者與管理者有可能會看到太多的垃圾資訊，而且是造成同仁們在資料比對上的工作負荷。

　　再以供應鏈需求為例。如果藉由製造商與供應商所提供的服務窗口所取得的資訊未跟經銷商的系統做某種程度的整合，經銷商在比對資料時就可能會需要跨兩個系統 來進行（一個是從原本的業務系統，另一個則是藉由服務窗口取得的資訊），訂單筆數不多時候，或許大概比對一下即可。但是訂單筆數多的時候，這個工作就會很 令業務人員頭大了。當然，更不用談「製造商」有兩、三個、甚至到五個以上時，相關作業人員所面對的辛苦了。

　　因此，只單單利用 SOA 跨組織或系統來取得資料並不代表 SOA 已經建置完成，是否進行最後的「資料整合」（把所取得的資料跟內部系統整合）往往才是最重要的，否則回來一堆資料卻只是要人花更多力氣去比對或轉換，這樣的做法很難實際產生什麼效益，而只造就另外一個效能瓶頸（Performance Bottle Neck）罷了。

　　不過，特別要提的是，由於 SOA 讓資料透通了，因此，從資訊整合的角度來看，我們可以把所取得回來的資料視為內部資料的一部份，直接進行資料的整合與加工，把資料轉換成我們需要的資料，以供內部管理者來使用。甚至，如果再配合BI或KM 這一類系統的協助，我們甚至還可以更進一步進行資料加值的動作讓資訊更有價值。

　　彼得．杜拉克（Peter Druck）曾預言 21 世紀將會是一個知識經濟的時代，SOA 應用的極致化將會加速這個預言的落實。

收集資訊更廣泛、應變更快速

　　藉由 SOA 的幫助，各個獨立組織（系統、組織、或企業）的數位化資訊可以很即時地被串連在一起，因而更進一步地延伸決策管理者所擁有資訊觸角到其它系統、組織、或企業之中。延伸的觸角再透過資料過濾、轉換、組織等資訊整合機制與技術，決策管理者將能全面且即時地讀取資料，且如果有必要，決策者也可以更細部檢視資料細部的內容（不需要再等待下屬或partner的資料收集），最後，如果有即時的決策需求，管理者就可以很立即給與正確的回應。

　　在上述供應鏈的例子中，某經銷商員工有兩筆相同產品的訂單已進入生產過程中。不過由於總生產量是超過一個製造商所能負荷，他把這兩筆訂單分別發包給北美與 南美的製造商進行生產。利用 SOA 的機制，經過一段時間的觀察後該公司發現，南美的製造商的生產進度明顯超前，而北美的製造商卻在生產進度上嚴重落後，此 時經銷商的員工在第一個時間點可以考慮的做法就是：改單–增加南美製造商的生產數量，並減少北美製造商的生產數量等等。

　　不過「改單」通常有政冶因素考量。例如：北美的製造商不願意改單，或者，雖然南美製造商的進度超前，但是他們後面還有一筆更大的訂單要趕，所以南美的製造商也不願意幫忙多接單生產。所以一般情況下，經銷商是不會隨便改單的。

　　因此，為了讓自己的決策更全面，這個業務同仁利用 SOA 所收集整合的資訊，再往更細部觀察，他發現，北美製造商之所以進度落後的主要原因是因為某個原物料 短缺（而這個原物料在南美的製造商中庫存是比較充沛），了解原物料的屬性後，發現原物料本身是屬於質量輕、體積小的穩定性物品、並不具易爆危險，因此經銷 商就可以協調這兩家製造商，是不是直接用空運的方式將原物料由南美運送到北美的製造商手中，以解決交期延宕的罰責及商譽受損問題。

　　當然問題可能不只那麼單純，可能還有其他難以掌握的因素。例如，南美的製造商的原物料只夠供自己生產而無法借調給北美的製造商。但利用 SOA 所成就的資訊 通透性，我們就能掌握所有即時資訊，以便很明確、詳細且盡量精確地面對問題、並思考各種不同解決方案、即時做出回應以避免商業上的損失。

結論

　　在前面的文章中已經提過了，「營運品質」是企業所應該堅持，並且營運長與執行長所應該關切地。特別是在商業競爭激烈的今天，往往有一點小小品質上的疏失， 競爭對手就可能伺機超越你並且取而代之。有了 SOA，並不代表企業在整個營運流程就不會有疏失，但是透過 SOA 的協助，管理者當下可獲得更全面性、更通透 化、更即時的企業整體（甚至整個供應鏈）營運現況，「營運品質」也就相對更有機會被堅持，客戶滿意度及公司本身的經營品質也就會因此而更提升。

本文首載CIO 的天空

之前，我們談到了SOA對人事流程的影響（上）（下）。在SOA的架構下，利用服務元件與窗口的方式，可以讓資料與資訊經由企業所規範並認可的認証機制被傳送出去，這樣子的做法，一方面減少人力的支出，另一方面，它也加速的資料與資訊的傳遞。簡單來說，它強化了資訊的通透性，拉長了企業的資訊觸角。

我們用供應鏈體系的需求為例。過去在協助經銷商進行企業E化的時候發現，在正式拿到訂單後，經銷商方面接下來關切的問題是：我的貨什麼時候會到客戶的手 上，因為一方面有交期的問題；另一方面，貨到後他才可以開始收款。特別是在某些「先下單再生產」的產業，這些業務人員甚至連整個生產過程都會不斷地問，我 的貨上了生管排程了嗎？生產進行是否來得及？目前庫存的原物料是否足夠？原物料的供應商是否來得及供貨等等問題。

面對這一連串「跟催」動作，比較聰明一點的製造商就把生管系統的某些生產進度資料利用Web介面呈現出來供經銷商夥伴們查詢，以節省回覆 這些跟催所產生的人力成本，並且，這種做法一方面能避免掉資訊人口的傳遞時間差，另一方面資料提供的方式也比較容易取得經銷夥伴的信賴（因為，人口所傳遞 的資料是有可能誤傳或是造假的，一般而言，人們比較相信系統直接撈取的資料）。

不過，這種做法也只能讓經銷商看到製造商的資訊，如果要再往上一層看原物料供應商的資訊就不可行了。除非，製造商與原物料供應商間還有其它人工或非人工的 資料/訊傳遞的方式，但相對地，這對供應商與製造商而言，也增加了人力溝通的成本。也就是一方講電話講到口乾，另一方則電話接到手軟。

SOA則可透過「服務元件」與「窗口」的設計，使經銷商直接在公司的內部系統中跟製造商所提供的服務窗口索取製造商的生產資訊，而索取的資訊也可透過系統化方式將取得的生產與訂單資訊整合，方便經銷商工作人員比對與過濾資料。

再來，如果原物料供應商也利用SOA提供相同服務時，製造商在服務窗口的設計上就可以同時向供應商的服務窗口來提出資料請求，並將供應商與製造商內部的資 料整合後回應給銷經商的系統。如此，整個供應鏈體系不論有多長，我們都可以利用相同方式來達到資料整合的效果。最末端的經銷商，就可以即時看到最前端供應 商所提供的資訊。

除了跨企業的供應鏈體系外，SOA還可以應用到其它跨企業、跨組職、及跨系統的資訊整合需求上。 不論資料如何分散各處都可以利用各個企業、組織或系統間的服務窗口們來彼此溝通，讓資料即時地整合到某個使用者正在使用的應用軟體上。對於實際取得資料的 使用者或管理者而言，根本不需要知道實際資料來源或儲存在何處，他們也可以即時使用這些資料，不致因為地理空間距離而失去了資料本身的時效性。

（～續～）

本文首載CIO 的天空

上一次我們提到，SOA對員工工作內容及人事流程會產生變革。事實上管理者角色也同樣有所不同。

管理者角色：除了「人」以外，還要管理「服務窗口」

過去，在商業行為的運作上，商業流程是由人來進行操作的，因此身為管理者，主要管理對象是人。行政作業流程若有所疏失，管理者要盡到教導的責任；作業流程有所耽擱，則要盡到提醒的責任；部門與部門間作業流程有所不順暢或衝突時也需出面協調或修正，以提出新的流程規劃。

不過，在SOA中服務窗口的規劃下，商業「流程」的實踐就不單只由員工來落實。電子化服務窗口本身已經蘊含了商業流程，因此，除了「人」以外，「服務窗口」 也成為管理者所要管理的一部份，系統中有幾個商業行為（流程）正在進行著？是不是所有的商業行為都正常運作著？懸而未決（Pending）的有那些？延擱 （Delay）的有那一些？延擱或懸而未決原因為何？需要人員介入來協調處理嗎？延擱或懸而未決是否代表流程中本身需要被修正？

在非人為的原因如：Partner在SOA 下的系統突然掛點，無法回應資料時，管理者就要適時地介入整個商業行為，來讓商業行為可以繼續正常的運作下去。又例如在人為的原因上：Partner 一直沒有辦法下達商業決策，導致整個系統Pending，並有可能錯失商機，此時管理者就會介入溝通，以促使決策的下達。

一個自動化的服務窗口，可以減少大量的人力支出，不過，這並不表示，他不需要「被管理」。在SOA系統架構中，有被規劃的部份，當然可以讓服務窗口自行來運作，但在例外狀況發生的時候，管理者如果沒有及時介入，極可能會導至商機的流逝。

因此管理者的角色會變得更為重要，因此在人事職位的規劃上，管理者並不能只擁有「管人」的職能（以往，很多管理者或許有能力「叫」別人來幫他們解決問題，不過，自己卻不一定有沒有解決問題的能力）。管理者本身需要對流程有一定的了解，以做好服務元件中商業流程的監控與管理，必要時候，還可參與服務窗口的製作或修改。

變革的彈性

在整體組織架構職務內容進行調整改變，並重新分配人與「服務窗口」的工作內容後，如果發現規劃有疏失，造成已經設計好並上線的服務窗口效率不彰，那該怎麼 辦？如果這麼一個不適任的情況是發生在某個員工身上，那就比較麻煩了，請他走也不對（因為有可能他並沒有犯錯，錯的是企業規劃），要協助他進行轉型，卻也 有轉型失敗的風險。

不過，如果對像是「電子化服務窗口」而言，問題就簡單多了。不論是管理者規劃面或是「服務窗口」本身設計面的問題，管理者都可以直接把這個「服務窗口」給 fire掉；或者，如果管理者捨不得Fire掉它，管理者也可以考慮請他暫時卸任，直到有其它需要的時候，再把他給請出來就可以了。

當然，由於服務窗口是由服務元件與流程組合而成的，所以在一開始如果設計得夠完善，你也可以考慮調整並重新組合這一些服務元件，以減少製作新服務窗口的時 間。至於工作交接的問題，管理者一點都不用擔心，因為這個「服務窗口」不是人，會很認份地做好該做的事情，直到你把其它「服務窗口」設計並測試ok 為止。

因此在整個人事流程上，當有組織調整需求發生時，「服務窗口」的彈性讓企業可降低人事架構調整時的衝擊。

價值再定義

很多企業導入SOA時可能著眼於「以服務取代人」–講白話，就是減少人事成本支出–的效益。雖然大部份公司在做企業電子化的時候或多或少都會有種想法，只不過，SOA 跟以往的企業電子化比較，更有取代人之勢。

不得不承認，某種程度下這件事一定會發生。

不過，我想要提醒的是，SOA或許取代了某部份人的價值，但從另一個角度而言，它也突顯了人不可取代的部份， 例如：創造能力、組織能力、危機處理能力等。因此「SOA對人事流程的『衝突』」並不代表員工一定會失去工作，不過對於一個員工而言，他要思考的是，如何 去精進自己（員工）不可取代的本質學能，甚至善用SOA系統工具所提供的有用資訊，來提升自我（員工）的價值，成為業企不可以取代的部份。

是故從企業人事運作管理的角度來思考，在針對一個職務進行職能的規劃設計以及在針對員工進行積效評比時，這一些不可取代的特性就應該被特別強化出來。例 如：在人才的選擇上，將這些職能列為企業優先考慮的職能，或在員工的培養與獎賞上鼓勵向這方向發展。如此，每當這一類「工作內容被系統取代」的事件發生 時，同時也突顯員工不可被取代的職能（而這一不可被取代的職能，又往往最能促進價值提升者）。一個萬年長青的企業絕對非單靠SOA就可以成功，不然，企業 買SOA就不用僱請員工了。

企業或組職的成功而是靠「人」在其中組織協調、心意更新的變化(Transform by The Renewing of One' s Mind)而達成。

而「被取代」或「善用它」，則是身為萬物之靈的人類有能力決定的。

本文首載CIO 的天空

上回談了「執行長該由人事、營運及決策流程的角度來關心SOA」及「執行長的第四個身份–資訊長」後，接下來，我們由人事流程的角度來談談SOA可能產生的衝擊。對於這個議題，大部份的人，所直接關心的是：我會因此丟工作嗎？

以服務（Service）做為導向（Oriented）的架構（Architecture）出發，來E 化企業，其實已經打破了過去IT 在企業電子化中所扮 演的角色。不論是從金流或物流的角度，過去，IT 在企業經營所扮演的角色都是在「可數位化資訊的傳遞、儲存、或分析」的角色，但現在SOA 的概念利用靈活 的流程來巧妙地結合與組織電子化的服務元件即形成一個個商業上的服務窗口，這樣被建構出來的服務窗口蘊含了商業行政流程與簡單的商業決策能力（當然複製的 決策還是需要由「人」親自來做）。在人事流程上，勢必會造成一些衝擊。

工作內容、職位都可能被「服務」取代

首先，我想大家一定會很擔心自己的工作是不是會被取代掉。從一個企業的角度出發，這是有可能會發生的，特別是一些可以透過無紙化作業並且不需要做太多決策，也沒有太多創造性的工作。

舉個例子，有些做B2C Service 的企業，因為他們提供給客戶多種不同的付款方式，因此在客戶交易總次數量很大並且產品又很多元的時候，這些企業就需要雇用一組會計人員專門來處理客戶付款 資料的比對，資訊化做得比較好的企業，可能會每個月定期跟銀行要相關的匯款電子明細，再以半人工方式轉匯進公司系統中比對金額。

資訊化比較差的企業中，我們甚至會看到有員工拿著一本存款簿（或影本）以及其它繳款方式的證明文件，一筆一筆的去比對與核銷。這樣的作業方式，即不經濟，也不符合效率，更經常是錯誤百出。

用電子匯款明細轉入後，再由電腦來自動進行比對，這是比較聰明的方式，只不過，銀行或該企業仍然避免不掉人工轉出與轉入資料的過程。另一方面，每個月才轉入一次資料無法很即時地 反應資料目前實際的情況（可能客戶已經付款了，但相關的明細還在銀行中，並沒有轉匯回來），當然是有其它方式可以解決，例如再去刷一次存簿或是再跟銀行要 一次電子明細，只不過，這樣子還是很麻煩。

那如果在資訊保密且安全的前提下達成資料交換，銀行資料轉出與該企業資料轉入的人工成本就可以節省下來了。而且匯款金額也可以即時比對核銷，想做就做，並不需要等到月底，甚至在良好的規劃下還可以做到只查詢明細（不需要進行核銷）。因此各種不同付款方式的比對與核銷都可以透過SOA 整合在一個系統中進行。

這樣下來，這一間B2C 的企業還需要一組會計人員嗎？我想，大概可以只留一兩個人來協助處理資料比對後仍然有問題的客戶匯款資料即可，而其它的人員就應該不需要了。

工作內容被取代，但職能的要求提升

前述情況中，電子化服務窗口取代了整個付款比對與核銷的業務（當然，在SOA 架構下，銀行端也會要有一個對應的電子化服務窗口，來負責企業身份認証以及提 供匯款明細），因此原來負責該工作內容的會計職位也應此被取代了，是故在整個人事組織架構上勢必也需做某種程度的調整--例如，裁掉一些人員。只留下少數 人員來管理這一些電子化的「服務窗口」，通常是指行政業務上的管理，以應付一些例外情況（例如：上頭突然交代的任務與突發的複雜決策）。

因此，從人力規劃的角度而言，可以考慮將不同原本是獨立不同工作內容的職務合併在一個職位之中。多個相同工作內容的職位就有可能被合併到一個職位中。

而所留下來的同仁，他們的責任也就相對地提升了。一方面雖然人數減少了，但所要負的責任卻跟起原來人數所負的責任是一樣的；另一方面，這一些留下來的人， 他們或多或少需要協助「服務窗口」的管理。，並且，由於合併所產生的新職務是兩種工作內容的合併，所以同時熟悉兩種職位的「廣度」也是在職位人選考量的關鍵因素。

再者，大部份職位的工作內容會明顯被區分成「可電子化」以及「不可電子化的」兩個部份。「不可電子化的」這一類工作內容並不會因為SOA 的導入而消失，特別是在創造性以及決策性高的工作職位。但是由於「可電子化的」工作內容有可能被轉換成SOA 中一個服務窗口來負責，此時人事部門在職務工作內容的設計上，就需考慮「職位」與「服務窗口」兩者工作內容重新分配的結果。

職位整併後所留下來的同仁，他們所背負的責任也就相對提升。一方面雖然人數減少了，但所背負的責任卻跟原來人數所背負的責任是一樣的；另一方面，這些留下來的人，他們或多或少需要協助「服務窗口」的管理。並且，由於整併所產生的新職務也可能是兩種不同職務工作內容的合併，所以同時熟悉兩種職位的「廣度」也是職位人選考量的關鍵因素。

（～續～）

本文首載CIO 的天空

上一回我們談到執行長與企業三個營運流程相關職權角色以及三個角色與商業自動化的關係，還沒有真正切入IT部份。本周將回到正題，談談SOA如何協助企業營運。

SOA對於三個營運流程的意義

或許有些讀者覺得很奇怪，為什麼談SOA會談到管理？回答這個問題之前，我們先回想一下SOA建構的世界。首先，企業在SOA 的架構中，結合服務元件與服務流程，利用多個服務元件即可組織組合成一個個的服務窗口，提供近似人的自動化商業服務，成為一個「近似人的服務窗口」。

不論從管理流程（堅持營運品質）或策略流程（策略未來價值）的角度來看，「對的人在對的位子上」是整個達到「執行力」的重要基礎，那一個「近似人」的自動化服務窗口呢？在「執行力」的達成上可以扮演什麼樣的角色？重要性又為何？

「找到對的人上車」是管理上的難題。對的人通常都已經在對的位子上了，而不在對的位子上的人，有時候又很難看得出來他是一個對的人。不過，SOA中一個「近似人的服務窗口」應該怎麼「找到」呢？

為了達到企業的執行力與競爭力，執行長必需去找到那個「對的人」，並且找他放在「對的位子」上，相信很多管理者相信都有這樣的經驗，某某同仁或主管幹部的 態度工作與能力都很不錯，可是在他的職位上，總覺得他做起來綁手綁腳的，沒有辦法完全發展開來，因此為了讓「對的人可以在對的位子上」，企業有時甚至須要 進行組織架構的調整，以創造那個「對的位子」。不過，大部份的情況並不會是一個「對的位子」被創造，而會是人才就因此而流逝掉了。

那面對這個「近似人的服務窗口」時又是如何呢？執行者應該要去關心並了解這樣一個「對的服務窗口」是一個怎麼樣的窗口，必要時可以依執行長對企業的需求來 創造這種 「對的服務窗口」；「創造」一個對的服務窗口，遠比找到對的人容易，並且對的人有時候不一定弄得出那個對的位子，但是服務窗口，如果不合用的時候，可以盡 量依職務（服務內容）的需求來修正或再造。

以前幾期提到的例子來說明好了。例如SUN所提供的服務窗口本來只能提供澳圖美德「產品價格查詢」的功能，而隨著企業自動化需求的改變，同一個服務窗口就可以再修正或新增「身份認証」的功能（讓多個下游廠商可以進來查詢）。

不過特別要提醒的是，在SOA架構下並不是說人不重要，「人」還是企業經營中最重要的部份，只不過，當可以用系統自動化的方式來取代「人」的時候，這樣的 情況就更應該被重視。從經營管理的角度來看，一方面自動化本身減少了人力成本的支出。另一方面，為了達到更完善的自動化，執行長必需掌握並規劃一個「對的 服務窗口」，或者說執行長要去針對不同位子（自動化需求）來創造「對的服務窗口」。

接下來，為了提升營運品質（也就是「堅持營運品質」的部份），SOA在管理流程上可以提供什麼樣的協助是執行長所應該關切的呢？這裏有三個部份要說明。

第一，就資訊傳遞的角度而言，SOA可以扮演資訊或資料交換的角色，因此在流程管理上，就必須為了監控、分析營運的實際情形，做到即時管理與修正營運流程 上的細節與例外狀況。在此，我們可以把SOA視為是一個Business Integration 工具，讓企業內部的資訊可以即時為管理者所掌握。因此從企業內部的營運管理來看，執行長應該關心SOA，是因為他（或者他的管理幹部們）需要大量而即時的 商業資訊來協助他們進行管理。

第二，在堅持整體供應鏈「營運品質」的今天，「管理」不能只侷限於單一企業內部，此時SOA整合角色上就會擴充到整個供應鏈上，並且隨著商業行為的複雜化（例如，有些供應商是有多個企業客戶，而這一些企業客戶都與這一間供應商間都有自己獨特的商業行為…等等）。此時，哪一類型的商業整合是SOA可以協助的，整合過程中所需避免與注意的事項，都是管理者應該關心的議題。

第三，為了提升管理效能，「流程改造(BPI，Business Process Improvement)」經常發生在堅持營運品質過程中，特別是在金流與資訊流的部份。而在流程改造的同時，執行長也可考量藉由SOA的協助來建構出新的企業資訊流程架構。

最後是策略流程（也就是「策略未來價值」）的部份。前面已經說過了，策略規劃應該以「打破最少平衡，開創最多價值」為首要考量，而「服務為導向的架構設 計」（SOA）也意謂著「服務」的本身可以被重複使用；換言之，在良好的設計上，理論上它是一個可以做到「系統修改最少，但彈性可變化最多」的架構，可以 協助企業儘量避免破壞原來的核心優勢，以達到最少的「平衡打破率」。所以在進行SOA導入時，執行長可以讓企業的SOA設計規劃者知道你心目中未來可能發 生的商業模式，讓規劃者預想可能發生的商業變化再加以規劃，以減少策略規劃時所造成的「平衡打破率」。

另外，一個新的商業行為需求的產生，在資訊架構上應該要有多少緩衝時間讓整個資訊後勤單位追上新的策略需求呢？這也涉及策略被落實所需要的時間。SOA的入導可以加速系統修改的時間，而切確的系統修改週期，則是執行長在制定策略時，所需要關切的。

上述幾點即是執行長在規劃一個新策略時需要思考的問題。SOA雖然可以在系統的修改上提供快速的反應時間，但如果沒有管理者參與以及了解初期規劃，實作出來的SOA即可能是一個空有SOA的技術、而沒有SOA精神內涵與實踐的架構。

執行長的第四個身份–資訊長

為什麼SOA推廣了這麼久，但在業界成功案例一直不多？這有很多答案，有的人認為是SOA的技術還不夠成熟、有的人則認為是導入費用太高…等。我自己則認為主要的問題出在「IT」與「管理」中一直存在小小的溝。

我在大學讀書時就體會到，資管雖然也是在五管之一，但在跟資管系學生對話時，會發現他們跟其它管理學院的同學關心的問題不太一樣，很多資管的同學們就跟資 工的同學們一樣，只埋首在資訊系統或程式開發的象牙塔中，而沒有意識到IT技術的發展是要去協助處理商業應用與生活應用上的問題。

以SOA推行來說，我們會發現IT業界與IT媒體都有很多說明與討論（不過，也由於是IT業界主導的討論，所以議題大多偏重技術面的陳述），但是在管理業界卻顯少聽見相關議題的討論。其實SOA主要是要解決IT技術在商業行為上所面臨的困境，因此在SOA的實作上，如果要讓SOA發揮最大效益，導入的廠商需要對業主的商業行為與商業流程有深入且透徹的了解。因此在管理界還沒有思考或意識到這些問題以前，單從技術面發展SOA導入的好處就很難被突顯出來。

也正因為這樣一個鴻溝，因此我覺得，除了執行力這本書中說闡明的人事長、營運長、與策略長的三個身份以外，執行長應該還要再多身兼一個身份–資訊長。從前文SOA的討論我們已可以很明顯看得出來這個需求。

從人事流程來看，隨著資訊化的發展，很多原本由「人」負責的工作都可以由系統來取代，因此執行長要同時整合資訊長的角度來協助人事長來思考整體人事架構的 規劃；從營運的角度來看，營運品質的堅持上，執行長也需要整合資訊長的角度來協助營運長來進行營運品質的掌控與提升（縮短交期、增加獲利、提升良率等）； 在策略流程的部份更是如此，在現今這個精確與快速反應的世代中，我們很難在沒有IT做為基礎建設來建構一個企業或新的Business model，IT建設的品質與內涵，也會影響企業成長的速度。

既然公司業務成長的速度卻是我們戰勝競爭對手的關鍵因素，因此執行長應該統整資訊長、人事長、營運長、及策略長的角度來權衡IT架構的建立，以協助公司內部人事（長）、營運（長）以及策略（長）的發展。

本文首載CNET

前幾篇文章中，我們談了許多SOA。SOA所指稱的是一種IT架構，可實現企業電子化與自動化，使IT追得上企業決策面的變化。但企業中誰應該最關 心SOA呢？這答案依企業見仁見智。不過，一般而言，熟悉、規劃與實踐SOA的重責大任基本上直接落在資訊長或技術長的身上。為了好好的保住飯碗，近幾年 來各企業的資訊長或技術長們都致力於了解與學習SOA，深怕那一天企業的執行長會跑過來對他們說：「XX某企業的資訊長只需要一個月就修改商業自動化的程式，來配合企業新的經營策略與模式，那我們呢？」

在我們繼續討論這個問題前，請容我先小小岔題一下，但也是相關的主題。幾年前，有一本叫《執行力（EXECTUTION）》的企管類書籍（作者： Larry Bossidy & Ram Charan，繁體版由台灣天下文化出版）。這本書曾高居Amazon.com 2002年商業暢總排行的第一名在台灣出版時，也造成整個業界的轟動。只要是管理者手上就會有一本，一直到現在，沒事在公司走一圈，都至少眼睛的餘光就可 以掃到5、6本（所以這本書出版到現在，我大概讀了三遍，但每次都是讀別人的，自己從來沒有花錢買過）。這是一本好書，特別是它談到「落實執行力，已達到 競爭力」的論點可以做為許多管理者的借鏡。

自動化和執行力有什麼關係？本文就是要來處理，如何從執行力角度來談，商業自動化技術遠勝CEO們平常不太關心的IT議題。在此之前，我要特別先針對這個本書的架構脈絡，來分享我的一些看法。 執行長的三個身份–人事長、營運長、策略長

在整本書的脈絡上，作者在全書一開始的地方提到，一個執行長應該身兼人事長、營運長、及策略長這三個角色（我想這種規 劃，並不是指企業中不再需要人事長、營運長、及策略長等這三個人，而是說執行長應該要掌握並了解這三個角色，理論上會還是會有人司其職地來來協助執行長， 不過，執行長除了靠他們以外，還要了解掌握，並且成為他們的規劃者與協調者，他應該是主導整個co-work 的連結）。

接下來，作者才在 其它章節中，逐一地依人事長、營運長、及策略長的順序來描述執行長在這三個身份中應該怎樣扮演，最後，在成功落實這三個身份的執行後，即成就了書中所主要 呈現的主題「執行力」（進而達到競爭力）。在這種脈絡下，我們很明顯地可以看下面的邏輯（我稱之為「三個值」）：

掌握人力素質（人事長）
↓　　　　
堅持營運品質（營運長）
↓　　　　
策略未來價值（策略長）

首先，執行長應該要扮演人事長的角色來很切實地掌握人力資源的狀態，唯有清楚地掌握人力的現況，執行長才有可能確切掌握公司的可行與不可行，一方面避免錯誤的決策（人力資源過剩或過操，都算是錯誤的決策），另一方面也邀免人才流失所造成的風險與損失（企管的五管中，「人管」一向都是最難搞定的部份）。

之後，在人員穩定–對的人在對的位子上（「從A到A+」一書中也有類似的觀念）時，接下來執行長才能進一步去要求並堅持營運品質，這裏的營運品質，並不只單純地指著客戶滿意度上在服務方面的營運品質，在廣義上，它也涵括企業內部的品質，例如：成本的節省、人力的降低、流程的減少、績效的提升等（所以作者有提到六個標準差等管理工具）。

為什麼堅持營運品質呢？一方面80% 的利潤是由 20% 的即有客戶中創造出來的，客戶滿意即意謂下一商機的伏筆；另一方面，好的營運品質會大量的減少不必要的運營成本，可以大幅提升企業本身在市場上的競爭優勢。

不過，當然，這一些運作必須建立在人才（員）穩定的基礎上。

而伴隨著企業對「營運品質」的堅持，人才/員的素質也相對被驗証。營運品質無法堅持，有可能是因為人員素質，或是對人的在不對的地置上造成的，因此另一方面在營運品質一旦無法堅持，人員也可能需做適度調整，所以回過來說，「掌握人力素質」還是執行長的第一要務。

最後，當企業本身的運作呈現穩定時，企業才有資格來談未來的策略規劃。如果只會談策略規劃，而無法在營運品質上有一定程度的堅持，策略規劃再美好也沒有用，因為大家在還沒達到那個理想前，可能都會先餓死了。

或許有讀者已經注意到，在「執行力」一書其實是先談「策略規劃」（第七、八章）後再談「營運管理」（第九章）。就整個商業行為而言，書本安排順序並沒有錯，特別是對於剛開始要成立的公司。

至於我在這邊為什麼要把順序轉過來呢？

一方面，「策略規劃」除了要建構在「對的人」的基礎上以外，「策略 規劃」也應該是建構在企業原本的核心競爭力上，「堅持營運品質」的過程中讓執行長可以很清楚地掌握企業的核心競爭力，並且這種過程中也讓執行長可以清楚確 認誰是「對的人」，如此在新的策略規劃才會真的建構在一個穩固的基礎上面。

另一方面，大部份企業也都是處於「營運中」的狀態（除了正要創立新開始的企業外），而新的策略規劃或多或少會打破原本的運營平衡，因此營運品質的堅持應該優先於策劃規劃。否則，當平衡被打破的同時，公司可能賠上原本的核心優勢。

例 如，面對這幾年來最近台商的大陸熱，就策略面考量，我認為大陸應該要去，只不過有些台商在台灣都沒有穩定的基礎，或者可以說，他們在台灣還沒有辦法做到 「堅持營運的品質」，台灣都管不好的情況下，會管得好大陸那邊嗎？有辦法「堅持營運品質」嗎？如果為了進軍大陸甚至打破了台灣這邊好不容易維持的平衡，這 樣一點都不划算。

這裏我們提及執行長與企業三個營運流程相關職權角色，以及商業自動化的關係。在下一次文章，我們將SOA作為文章一開頭所談的IT技術，對於執行長與三個營運流程的意義，以進一步了解為什麼SOA不只是IT長官的責任。

Why SOA？
SOA：美學為架構的IT技術
應「變」是SOA最大價值所在
關於上面三篇文章

本文首載CNET

之前談到 SOA 之所以不同，是因為它結合服務元件及流程，而形成嚴謹而具有美感架構的 IT 概念。但它是不是僅只是於「比較美」而已呢？它對企業運作，是不是真的發揮效益呢？讓我們再隨著昨天的例子繼續走下去。

「變」才是自動化 IT 最大挑戰

伴隨著澳圖美德跟 Sun 原廠生意往來的增加，他們的合作關係越來越密切，也越來越有信任感，因此在兩邊老闆與業務同仁熱切期望與鼓吹下，在短短一個禮拜會議討論後，老闆們握手作出以下決議：「面對市場的快速反應，某些單期的商品，只要是澳圖美德業務人員確認後的訂單， Sun 原廠這邊就可以直接出貨，澳圖美德的同仁只要事後在一個月內補上訂單及貨款即可，以縮短整體的交期。」

這樣的消息對兩個公司的業務同仁而言都是一個普天同慶的大好消息，特別在信任感足夠的前提下，交期縮短的做法會讓客戶滿意度增加，並相對地提升業績，特別對澳圖美德而言，這樣的做法會縮短貨品在途與減少庫存，可大大提升兩個公司在整體銷售上的執行力。

但獲得執行力是要付出代價的。

老闆又繼續說了下去：「為符合這樣的需求，請 IT 人員於半個月內修改系統…」一語未閉，資訊部門的同仁全都當場傻眼（並考慮要不要遞出辭呈）：天啊，當初為了達到整體的商業自動化，花了澳圖美德公司與 Sun 原廠的資訊同仁們三個月時間的系統分析以及六個月的程式撰寫，最後逐一的測試，直到上個月才剛算完全測試完成的系統，半個月要怎麼改啊？瘋了嗎？

IT 主管們（特別是資訊長與技術長）所面臨的最大挑戰並不是一個固定的商業行為，其實大部份跨企業/組織的商業流程自動化需求都可以利用傳統 EAI 所使用的 IT 技術手法來完成；講白了， IT 人員只要把商業的作業流程定義清楚，不管採用什麼技術（VB、JAVA、N-tier、mainframe、有資料庫就用資料庫，沒有資料庫就用最笨的方式，像是 TEXT file等），大部份商業上的需求都還是可以硬生生--不論用苦力技術或高級的方式（例如物件導向加XML）來實作出來，但最大的挑戰往往發生在商業流程改變的時候。

「規劃永遠趕不上商業變化。」這是所有 IT 人的痛，因此當我們談到商業自動化，「流程」只是故事的一半而已。也是 SOA 的切入點所在。

在瞬息萬變的經營環境中， SOA 目的在更深一層去關切並預想商業流程的變異性，並思考、定義與切割一個個服務與流程，以強化企業商業自動化的靈活度。

是行銷名詞還是真的有用？

談到這邊，我想「為什麼要 SOA ？」或「 SOA 是不是一個行銷術語？」應該會得到較清楚的答案。在商業自動化為前提下，「服務元件」與「流程」可視為商業自動化的基本元素。面對商業行為的變異性，在「服務元件」與「流程」的設計與實作上，應該要達到彈性並且可以重複被使用的水準，以減少系統重複開發的時間，這樣子以商業服務為基本元素來做為的出發點，而設計出來的 IT 架構，我們就稱之為「服務導向架構」( SOA )。

而在這樣一個約定而成、公開規範的 SOA 架構下，企業便可藉由「服務元件」與「流程」靈活組合（就像玩樂高積木一般），因應瞬息萬變的商業行為需求。

理解 SOA 的本質後，我們再來看 SOA 中各個資訊原廠或SI廠商所提出的各種五花八門資訊名詞時，應該就會比較清楚個中差異。例如：BPEL（Business Process Execution Language，商業流程執行語言），簡單說就是特定資訊語言可以用定義及規範各個服務元件的執行的先後順序與因果關係（也就是流程）。再如ESB（Enterprise Service Bus，企業服務匯流排）則是服務被實踐的地方，ESB在系統與系統間、企業與企業間，負責整合的作業，讓「服務」的串連形成一個匯流排（Bus），如同巴士（Bus）一般地，傳遞跨系統、組織與企業的資訊服務。

面對企業資訊「整合」的需求， SOA 並不是唯一的答案，但無疑地，隨著 SOA 技術逐漸發展成熟，新的概念與技術可以讓企業面對商業整合時可擁有更大的彈性與效率。而接下來的專欄文章中，我們將陸續探討 SOA 對企業內人事、流程、甚至CEO角色職權的衝擊。

Why SOA？
SOA：美學為架構的IT技術
應「變」是SOA最大價值所在
關於上面三篇文章

本文首載CNET

最近一年多以來， SOA （Service-Oriented Architecture，服務導向架構）成為 IT 界的當紅炸子雞。

隨著媒體與 IT 大廠的炒作，好像一談到「整合」就非 SOA 不可。很多技術詞彙（例如：BPEL、ESB、BAM…）也在這個過程中不斷地被創造出來，但這些一技術詞彙好像並不會幫助我們對於 SOA 在應用上的了解，甚至只會令人更懷疑這些名詞只是 IT 產業又拿出來行銷的噱頭而已。

事實上，技術出身的我不得不承認， SOA 有一種架構性美很容易讓技術人員醉心。但在同事朋友們討論 SOA 的時候，總覺得少了什麼？這樣的美可以幫助我們解決什麼樣的問題呢？如果只是架構上的美，終究也只限於技術架構的美而已，有什麼資訊問題是無法用傳統 EAI （Enterprise Application Integration）技術手法來解決而一定要採用 SOA 嗎？還是它的美只存在於 IT 學院的象牙塔之中呢？

面對業界許多（非 IT 領域）朋友的疑惑，我決定寫這一篇文章來重新為 SOA 「正名」，從 IT 在商業運作上應用的角度來闡述 SOA 主要所要解決的問題，讓大家再從另一個角度來看 SOA 。

定義：不只是技術，是 IT 架構

或許已經有讀者注意到了，我們通常談到 IT ，大部份都會說是XX「技術」，但為什麼沒有聽過有人說 SOA 「技術」呢？如果我們看 SOA （Service-Oriented Architecture）這三個英文字母，會發現 SOA 中的「A」竟然是Architecture（架構）這個字。單就語句結構上來看，如果在「架構」這個字詞後面再扯上「技術」兩個字，還真有點奇怪。

嚴格說來， SOA 這一個詞並不是指一種「技術」，而是指一種 IT 架構，當然，這樣架構下會有各種不同的技術，來解決企業在面對商業自動化的所面臨的各種不同的問題。

本文將先介紹 SOA 對企業的意義，主要在藉由商業自動化，以協助企業解決一個千古不變的難題：變。

自動化服務元件是商業自動化的第一步

SOA （Service-Oriented Architecture，服務導向架構）顧名思義，以「服務」做為導向來出發，以設計並建構我們的系統構架。簡單來說，我們可以說：「服務導向架構」目的是要達到一個自動化的商業行為。

首先，讓我們舉個例子說明。澳圖美德（Automated）科技是一個系統整合廠商，在他的商業行為中，他需要經常對他的供應商（例如 SUN Microsystems）來進行詢料（特別是在庫存中並沒有足夠的備料時）。

早期這樣的一個行為，是由純人工的方式來處理，需要再透過 SUN 業務同仁處理（包括報價及答覆商品的 Delivery Time ），但在整個商業流程中，商品的報價與 Delivery Time 並不會有經常性的異動，因此這樣的做法是一種人力資源的浪費。

為了避免這樣的問題，我們可以將上下流兩個公司的系統做適當的調整，讓 SUN 公司在系統中建架一個服務元件來提供價格與Delivery Time 的資料查詢，直接利用在澳圖美德內部的系統來呼叫 SUN 公司所提供的服務元件，澳圖美德的同仁即可完成報價與Delivery Time（交期）的詢問。所以可以認知到的是，在商業自動化的前提下， SOA 需提供一個「跨系統的資料交換與傳遞的規範與方法」，以便商業上的資訊交換。而在整個架構中，被實做出來以負責資訊的交換與傳遞的程式一個個的模組，我們可稱為服務元件。

或許有些讀者會發現，這樣的做法，不就是幾年前 Web Service 的技術觀念下就已經提出來的做法嗎？這跟 SOA 有什麼關係呢？

當然，如果只是上述的例子中所提到的需求，其實只要用 Web Service就可以做到了。那 SOA 可以再解決什麼樣的問題呢？藉由上面的例子，我們再來拉大企業的需求，以再進一步認識 SOA 。

「服務元件」結合「流程」提供更多樣的自動化服務

由上述的例子，如果單純從資料流的角度來看，我們可以說：「澳圖美德公司與 SUN 公司在做資料交換的動作，讓澳圖美德員工可以很輕易得到他需要的資料。」但其實自動化的商業行為並不只是資料交換那麼單純；例如，以身份認証而言：是不是所有的廠商都不需經過認証就可以呼叫 SUN 公司所提供的元件來取得 SUN 的報價與 Delivery Time 呢？或者不同的協力廠商所取得報價會相同嗎（不同的協力廠商有可能會因不同的規範而有不同的報價）？再從流程的角度來看，整個商業行為並不是在取得報價後就結束了–是不是要有詢價記錄（以便未來的追蹤）？

或者，如果價格合理，那就會進入採購的程序。如果價格不被接受，那則有可能進行到議價的程序，如果該項商品還有多個供應商的話，那也有可能進入到詢價、比較的不同的程序。甚至不同供應商也有可能有不同的作業流程或程序，有些一定要先下單再出貨，有些關係好的則可以先出貨再下單。有的商品則有可能要先下樣品單，甚至樣品交貨的同時也要先付貨款等等。

因此很單純地由一個服務元件來進行資料交換，並無法滿足商業行為自動化的所有需求。在一個完整的商業自動化行為中，往往需要由一組（多個）可能由多個不同系統提供的服務元件來進行服務。

例如，系統應該先進行身份確認（這裏是一個身份確認的服務元件），再來才進行詢報價程序（這裏應該又是另外一個服務元件），最後，當買方確認要進行下單的時候，才會進入採購程序（進入採購流程應該又是另外一組服務元件，甚至有可能對應到另外一個獨立的系統中）。而組職、整合並決定所有的服務元件的使用順序地即是「流程」。因此商業自動化的目的下，如何進行跨程式語言、跨系統、跨組織、甚至跨企業的流程架構、規劃、設計與實作，也是 SOA 要思考與規範的重點項目。

我一開始說 SOA 有種架構性的美，是指它作為一種 IT 架構，竟與哲學中的現象學具有同樣的世界觀 。現象學提到「存有」與「關係」。「存有」在OO（物件導向，Object-Oriented）中（註），可以視為是物件，而在 SOA 中，我們可以說它是服務元件。而關係，在 OO 中就是那個方法，而在 SOA 中，就是跟時間一起被定義在流程之中。 SOA 即是結合服務元件及流程的很嚴謹、很工整的架構。

Why SOA？
SOA：美學為架構的IT技術
應「變」是SOA最大價值所在
關於上面三篇文章

關於下面這三篇文章：

相信很多人都看得出來……
「Why SOA？ 」=「 SOA：美學為架構的IT技術」+「 應「變」是SOA最大價值所在」 。

很多朋友在問我，到底什麼是SOA，我們應該要怎麼理解才會有一個清楚的認識，又不會跟傳統的EAI混淆。「 Why SOA？」 是這一組文章是一開始的架構，目的就是想要用最簡單的方式來把SOA描繪出來（當然，有一些訊息也會隱藏在文章之中）。

「SOA：美學為架構的IT技術」與「應「變」是SOA最大價值所在」這兩篇文章，是與編輯互動後的產物。不得不佩服編輯的功力，短短一個晚上的討論，一篇文章，就有被附與不同的生命呈現不同的面貌。

把這三篇文章都放上來，一方面感謝篇輯的用心，另一方面，希望可能讓不同的讀者從不同的角度與面向來看SOA……

配合流程改變才真能善用 RFID 的優勢

我想正是「高級條碼」一詞誤了大家啊，不論是企業或是提供 RFID Solution 的系統整合廠商，大家在進行 RFID 的導入的時候，都被條碼的使用習慣所制約了（因為它們對 RFID 的期望就是比較高級的條碼），因此，在導入前與導入後，我們常會發現，除了原來的條碼系統改成 RFID 系統外，其它資訊流動及體實物品（產品、人員、原物料）的部份都沒有太多的改變。試想，如果在使用原子筆的時候，我們仍然採用過去使用鉛筆所習慣的作業流程，那會有什麼下場呢？就是原子筆送進削鉛筆機削了。如此以條碼的使用習慣來使用 RFID ，當然，除了成本的增加外，就不會產生其它的效益。

因此在 RFID 的應用上，不論是企業或是提供 RFID Solution 的系統整合廠商都應該特別重新思考的是，這樣一個新技術的引進，在企業整體的作業流程上有什麼可以再被調整、或被省略的？藉由業務流程的省略，企業才有機會減少不必要的成本，而藉由資料傳遞流程的調整，企業也才有機會更加速或通透內部的管理資訊。如果系統整合商一昧地只著眼於 RFID 標籤及讀取頭，而沒有就整體的流程面提出完善的規劃，那當然沒有價值、甚至商機可言。

IT 的重點一直都不是在 IT 技術本身，而是在於技術如何在應用中被實踐或強化出來（有時候真的不得不認同 Nokia 的那句話：科技使終來自於人性。）很多的 RFID 廠商或者媒體都可以給我們很多單純技術上的數據與資料，但是重點還是在於這樣的技術是不是真的是在「人性上」--業務面上--滿足企業的需求。

RFID 導入是企業與 Vendor 共同的責任

看完上面的討論，或許有些人會把問題丟給 RFID solution 的提供商，認為：「這些 Solution 的提供商眼光短淺，沒有在流程及功能面做好好的反省，因此，它們提不出好的 Solution ，那當然 RFID 沒有商機。」當然 vendor 不爭氣而造成今天這樣的局面也是一個事實，不過，問題並沒有這麼單純。

例如，企業本身在選購的時候，只願意付 RFID 硬體的費用，而不願意付給 know-how 的發想人（大部份都是用拗的）。甚至，有的問完 A 廠商怎麼做之後，請 B 廠商來做，而付給 B 廠商單純的硬體費用。這個時候 B 廠商做壞了，責任在誰的身上呢？ B 廠商？還是企業？

更悲情的是，A 廠商可能會因為接不到案子而養不起有應用know-how 的人，最後便面臨倒閉了，久而久之，這樣要較長遠規劃、技術內涵較深的專案，就沒有廠商願意去做了，最後大家都只好變成「眼光短淺」了。其實類似的問題在國內屢見不鮮：顧問、know-how 的成本在「買硬體送服務」中被犧牲掉，最後，人才都只願意去賣硬體，而沒有人願意去談 Know-how、做服務。台灣資訊業所提供的 Know-How 及顧問品質，也就在這樣的惡性循環下日趨「向下沈淪」了。

進一步我們可以思考的是：好的solution know-how 應該是系統廠商負責提出來？還是應該是由企業主們來提呢？就整個資訊流的構面而言，RFID 主要是負責資訊流的最末瑞--與物品連接的那一段，因此如果要真的善用所有 RFID 的優點話，企業內外整個資訊流的部份大改寫並非不可能（從內部的 ERP 到整個 supply chain 都有可能被動到），這種情況下，整體大系統的流程改造，絕不只是 RFID 導入廠商的責任，企業主們也必須負上某種程度的責任，畢竟在公司營運管理 know-how，沒有人比企業更清楚，往往也只有企業業主們真的可以在流程的改造上給與明確的答案。

你說 RFID 是比較高級的條碼？從技術成本面或許如此，只不過，如果你說它「只」是高級條碼而沒有任何新用途，這一點我就有所保留了。相較於條碼，RFID 可以協助企業達到更快速、更便捷、更通透的物品管理。在一切講求快速反應、立即決策的今天， RFID 所提供的物品管理效率正是企業所需要的，而商機，就在這需求中被創造出來。

（前文）

企業需要 BI 嗎？這是一個常常會被問到的問題。講 BI 對很多人而言可能還是太高深了，換角度來問這個問題可能比較容易思考…貴公司需要資料分析嗎？財務分析、成本分析、市場分析或是良率分析嗎？貴公司需要好的分析工具來加速分析的速度嗎？如果上述的兩個答案是肯定的，貴企業應該是需要 BI 的。

簡單地說， BI 就是分析工具。在早期尚未資訊化的時代，分析師藉由筆跟紙（頂多再多一台計算機），要花費大量的計算時間，才有可能從一個角度來進行數據的分析，當然如果老闆要再換一個角度來看數據，分析師則要再大費周章再把整個數據從弄一個角度再來進行分析。後來隨著資料化的發展， Louts、excel 等工具的產生，資料的整理與分析也更方便，此時，一方面藉由上述工具的幫助，另一方面基於市場需求，企業所要進行分析的數據量也就越來越龐大。

但由於這些工具並不方便於多角度的數據分析，再加上所要分析的資料量劇增，許多企業希望可以直接並即時地從企業運行的資料庫中來進行多角度的資料分析，其中儲存企業大量數據與資料的地方，我們就稱之資料倉儲（ DW，Data Warehouse ）而整個進行多維度資料分析的部份，即稱之為商業智慧（ BI ，Business Intelligence ）。

其實， 現在的問題是，是不是花了大錢，買了好的 BI 工具，就可以完成企業 BI 的夢想 ？之前 BI 工具呼聲喊得震天價響，但就我所知，有的企業花了大錢買了好的 BI 工具，可是那個買進來的工具確是叫好不叫座，到最後，企業內部的員工九成還是使用 Excel 來進行資料的分析。 BI 的成效不彰，原因可大至歸類為下列的幾點：

1. 金玉其外，敗絮其中 ： 這是最常被看見但往往也是最重要的問題，前面已經提過了，商業智慧（ BI ）必須建立在資料倉儲（ DW）的基礎上，因此單單有好的 BI 工具，但是底層的資料 倉儲卻沒有辦法針對上層 BI 工具所提的需求，提供即時而穩定的服務時，就像蓋房子一樣，明明是地層沒有打穩，可是卻要把大樓蓋得又高又美是不可能的。這種 情況下，再好的工具也就沒有輒。

2. 缺乏專業的資料分析人員 ：電腦不論是多「超級」，還是比不上人腦聰明，它只是比人腦「快」而已。 BI 工具只是方便並加速資料數據的分析，但是資料分析的方向，以及有效並相關連資料的選擇，則還是要由人腦來決定的。也就是說，整個 BI solution 的導入與運作的過程中 還是需要一個熟悉資料的內容與架構並且有商業敏感度的人參與 （這 個人並不需要一定很懂 IT ，可是應該要資料的本身夠敏感）。然而現實情況是，大部份企業對 BI 工具本身抱了過高的期望，反而在導入的過程中，沒有適時地讓 這方面的人才來發揮他們的長才，並且熟悉 BI 的使用（甚至有些企業以為既然已經有 BI 了，就用不著這些人了）。最後，就搞得 BI 人員自己去搞自己的資料庫 分析，而這些人還是繼續用他們的Excel。

3. 資料未做適度的轉換 ：資料儲倉中的資料，大多是由企業內部系統中的資料 庫轉進來的，因此這些資料不論是資料結構的定義上，或是資料本身，原本都是給系統程式來讀取與儲存的。例如在 RDBMS 的結構下，我們是用PK與FK的對 應來做為兩個資料表之間的關連，有些系統開發者的習慣比較好，會在資料庫中把這些規範出來，有些則不會。不過，不論如何，都還是利用資料庫的語法來做定 義，這樣的定義方式一般的資料分析人員大部份都是看不懂的。資料分析人員並不一定看得懂這樣的資料，因此對於這些資料，則需要做適度的轉換，才方便資料分 析人員的使用。

4. 缺乏資料庫系統人員的維護 ：很多企業會誤會，買了 BI 工具安裝好可以順利的運作就大功告成了。但他並沒有想到一方面隨著時間的成長，資料倉儲中的資料也不斷地成長，另一方面， 資料倉儲中的資料也會隨著分析需求的改變及企業型態的改變而需要被調整 ， 因此如果沒有資料庫系統人員隨時因企業的需求對資料倉儲中的資料（資料本身、 index、view …等）來進行維護，時間一久，資料倉儲中的資料，或許還 可以用，但是架構卻是呈現一團亂，這種情況下也一樣沒有辦法提供好的效能。因此在這樣的情況下，隨著資料的成長，每次分析結果產生的效能越來越差，最早一 張報表產生的時間一個小時，而後來卻要十個鐘頭，當然慢慢地，這樣的工具也就越來越不被分析師所接受了。

5. 缺乏好的呈現方式 ： 完成 BI 的資料分析後所產出的報表應該要如何呈現給老闆看？呈現的方式夠不夠即時？如果老闆不喜歡這樣的呈現方式，或者，老闆必須長時間的等待才可以拿到 這樣的資料。此時，不論大家做了再多的資料分析，都不會得到老闆的青睞。既然如此，久而久之，大家就沒有人想再用這套工具了。

我個人一直覺得 BI 不能單單只視它為一種「工具」，而應該是從 solution 的角度來看待它。如果沒有完善的整體配套規劃，再好的 BI 工具最後也可能變 廢物。有趣的是，通常越好的工具，它需要的配套規劃也需要越完善（例如：導入顧問服務、完善人員的分工架構、資料倉儲的維護…等），相反的，那些不怎樣的 工具反而不需要太多的配套規劃。我想這應該就是 Excel 為什麼至今仍然是 BI 分析主流工具的原因之一。