產品特寫

一個軟體小業務眼中的 BPM

蔡佳甫

• 本期導覽
• 產品特寫

產品？工具？平台？

進入資通，有將近三年的時間都跟AgilePoint這個BPM產品相處。老實說，我真是痛恨BPM！不是說這個產品不好，也不是說它對企業毫無幫助。只是，它本身面臨的價值定位，就目前台灣軟體的認知來看大有問題。

這到底是誰的錯呢？是產品？還是資訊教育？

以資訊軟體來看，使用者大都能迅速且正確的理解自己使用的是「辦公室軟體」、「人力資源管理軟體」或是「企業資源管理軟體」。但是，一談到BPM三個英文字，客戶往往會回應：

「喔！我知道，那就是Work Flow」

「喔！這個東西在ERP裡面已經有了？不是嗎？~~」

「喔！那是搞SOA的新工具，專門做EAI的」

「喔！不過就是個電子表單的引擎…」

我很少聽到：BPM，太好了！我們正面臨組職調整、簽核後沒有自動化的困擾；我們公司一直要汰換舊有的Work Flow，但是沒有找到比較好的替代方案，能同時解決平台與整合間的問題。

同樣是資訊產品，爲什麼使用者的認知差異如此大？或許我們得透過BPM的觀念來思考它的服務定位。

BPM (Business Process Management) 直譯為「企業流程管理」。其最早的訴求，是企業內部會不斷的組織變革，同時企業也有成長膨脹的問題，所以得要有個中介軟體能隨著外在環境與內部管理同時俱進。這個觀念在2002年左右提出，但是相關的軟體產品則在2004年左右才問世。從這個訴求來看，它所服務的目標主要有：流程、組織、作業標的。

但是，沒有一個企業的作業流程與別家完全相同；也沒有一個企業的組織規範可以具有普遍共用的特性；這樣的限制下，BPM就不像是個「產品」，而比較像是一個工具。再者，各家企業整合目標各異。有的用在ISO管理上，有的用在數據傳遞上，這樣的應用就讓BPM的身份更形曖昧，從產品轉到了工具，又從工具轉到了平台。

系統的衰退與系統的熵

先前，我曾做過BPM ROI的研究，也做了一些翻譯(電子化業務流程導入調查報告)。但是始終沒有找到BPM ROI的核心精神，因為一般的ERP系統，可以透過結帳時間、庫存週轉等因素作為績效，但是類似的指標條件在BPM上不易見到。於是，許多效能指標就偏向電子表單的傳遞效能、無紙化。

事實上，這是不對的。BPM的服務精神既然是在企業的變化與成長，我們便應該去思考系統的特性是什麼？為什麼需要BPM來搭配？

我們可以發現新系統上線的時候滿意度最高，但是隨著企業組織的變化與成長，系統功能開始受到新需求進行變更；系統或者受到修改、或者透過外掛AP來補強既有的運作，但是終究難逃滿意度趨緩甚是下架終結的命運。這樣的結果，我們可以當成是系統的使用壽年。從另外一個方面來看，我們是否有其他的辦法可以延長其使用或是改善不滿意呢？

如果您仔細思考上面的對照，系統盡量維持原本設計架構來延續其穩定性，便是延長使用壽年的好方法。

中大型企業的核心系統所費不貲，動輒上百萬或是上千萬。但是，往往因為資訊單位的規劃能量，或是使用者需求排山倒海而至，導致系統購買後，無法順利上線或是勉強上線；當然，它的使用年限也跟企業成長息息相關，這就好像孩子長大了，他非得吃上其他的五穀雜糧，三餐只供應牛奶畢竟是不夠的。有趣的是，沒有一家企業在購買的時候不是從長遠的使用角度來做評估，因此就產生了「使用年限」≠「實用年限」的問題。

問題人解決聰明

聰明人解決問題，問題人解決聰明。這些年我看過不少的企業透過正確的規劃延長核心系統的使用年限，也見過不少雄心壯志的資訊主管一上來就是換掉過去所有的核心系統。就我的工作來看，我應該愛死後者，但是跟後者合作，往往不開心！

因為需求的問題不是擴充功能或是買個更強大的系統就能夠徹底解決。需求是一種平衡狀態，必須在系統能力的「有限」和人性需求的「無限」間取得平衡，並且透過這樣的狀態來提昇企業的運作效能。於是乎，系統應該專心做系統該做的事情，中間溝通層的產生，無非就是為了化解系統間的數據整合。

EAI (Enterprise Application Integration) 是上面問題的一種化解方式，不過，它聚焦在大量的系統間。因此對於細部的自動化作業與判斷、計算、檢核就不是那麼的有彈性。我看過梁賓先在2004年寫的一篇文章，我想當時梁先生也面臨了跟我同樣的困境，只是2004~2008幾年下來，台灣的資訊圈子還是搞不懂BPM。

他用了幾個觀念來強化他的論點：

• 「BPM＞EAI+WorkFlow」
• BPM=EAI+WorkFlow ?
• BPM就是Workflow加上Adaptors ?
• BPM 就是EAI加上Activity Modeling工具 ?
• BPM≠EAI+WorkFlow ?
• BPM＞EAI+WorkFlow

我不是BPM的專家，您也別奢望我是專家，不過在上面的關係式上不難看出端倪－ BPM在台灣的應用充滿了吊詭與灰暗。因為它既沒有EAI的尊崇也沒有Work Flow的卑微，它所具有的就是能夠繪製流程、提供跨系統整合的串接。

BPM的目的呢？不見了！除了引擎、服務，它還有什麼？

檢討上面的問題，主要源自於BPM導入前，其實需要經過BPA還有BPR兩道程序。 BPA ( Business Process Assessment-業務流程評估) 目標在於找出業務流程的策略目標與流程連結點，並藉此梳理掉不必要的活動以及精進強化所需要的活動。 BPR ( Business Process Reengineering - 流程再造) 的目的則在於調整並留下適當的活動，並且把它E化以提昇企業的競爭力，這兩件事需要廠商與專業領域顧問相互配合進行，才能分析出BPM的最大效益與可行的途徑。

可惜的是，幾乎沒有廠商會在BPM導入前進行這樣的工作。於是乎新案就是照著企業的現況流程進行E化，舊案就是把前面的平台取代 (replace) 掉，因為後面的平台可以做到前面平台需要大量客製才能達到的目的。

在這樣惡性循環下，BPM沒有發揮應有的效應，只是一再偽裝，彷彿他的身分就是個郵差－「不斷派送他人的文件到應去的位置，簽收收件後就大功告成」。或是一個小工讀生－「不管你調任到哪裡，他都能找到你，幫你處理一堆雜事，但是不要希望他告訴你什麼是對的。」

如果只是這樣，我們真的很難找到購買BPM或是換掉Workflow的好理由。

BPM的ROI在哪裡?

其實，BPM平台除了引擎、流程制定介面、介接整合功能、平台維運管理的要求外，最好要能夠具備分析與模擬的功能。分析的目的是可以透過不同的執行條件來選擇哪個流程比較好。模擬的目的則在於制定不同的執行情況來避免與縮減作業面的管理問題。前者需要的是數據，後者需要的是事件。

分析的過程可以把人員的薪資、工時、組織、作業等方式都帶入，這樣就可以了解到哪個作業是時間最長、最耗成本或是執行上最繁雜；相對的，也可以找出最低成本、最短時間的作業方式。

模擬的過程則是能將不同的系統整合條件放入，如此便可以判斷哪些動作是可以做到、哪些動作可以做到，卻需要付出相對的代價。

在這樣的前提下，BPM的核心精神才能產生，我們也才能保持核心系統的作業機制，透過BPM平台進行有效的服務；這樣的服務是經過流程分析、整合而建立的，它不會光是進行電子表單的簽核，也不是只做為異質系統中的數據傳輸。

BPM的投資效益與其說源自於資訊整合，不如說它延長了各核心系統的使用年限並且保障核心系統的營運。它爭取的是外部競爭與管理變革壓力下，透過自動化作業來提升執行效能，並協助決策達到即時性的統籌目標，所以他的ROI是建立在戰略效應上的。

試想，五個原本五年應更換的大型系統，每個購入單價如果是伍佰萬。透過BPM讓每個系統多延續使用三年，這期間它還能做到縮短作業期程、快速反應資訊、分層授權管理、支援決策分析、累積歷史資料、流程模擬分析。我不是專家，但是我也能感覺的出這是個好東西……。