最近更新: 2007-05-01

BPR 並非導入資訊系統後就萬事大吉

本文緣起於一篇討論資訊軟體委外課題的文章。雖是如此,本文的主題卻是組織管理、策略管理,而非軟體工程或資訊管理。

同人 閱讀我的《業務流程決定軟體程式,軟體程式追隨業務流程》之後,於《委外與流程整合》回應道 對於石頭成的這個結論,我並不能認同。雖然企業的核心業務流程不應該外包,但並不代表資訊技術在組織只有支援性的角色而沒有策略性的地位

同人的回應令我十分困惑。當我強調業務流程不應外包時,其意義就等於賦與企業的 CIO 與 MIS 更重要的策略性地位。如果企業的業務流程是由軟體承包廠商制訂,則企業的 CIO 與 MIS 將失去其策略性角色,而真正淪為一個支援性角色。天天處理其他部門同事的電腦不能開、滑鼠不會動、電腦中毒了之類的瑣事。我的結論實際上加重了組織內資訊部門的策略性地位,而非否定。

其實同人對資訊技術的改變促成組織結構改變的說法,我完全認同。這一方面的相關內容,當時在研究所中,我們是以 B2C, B2B 與「組織虛擬化」為課題進行討論。例如《分工 ~ The outsourcing or integration on jobs》一文中,就紀錄了我當時針對我的同學之論文提案內容所作提問。管理學界不否認資訊技術的改變會促成組織的價值鏈創新(即 BPR — 企業流程再造),亦即「外包性工作項目」與「整合性工作項目」將會隨資訊技術而變動 (同人引述企業價值鍊活動必須有效地整合才可以破除分工的迷思。但就我理解,「分工」的意義是「整合與外包之決策」。整合與外包是「分工」之一體兩面。當我們思考「那些」該整合時,就等於思考「那些以外」將外包。反之亦然。),並將其影嚮反饋到組織策略中。

但在那同時,也正好是「網路泡沫化」出現的時期。除了許多 .com 企業一一倒閉之案例外,也有許多企業導入資訊化、網路化系統後並未帶入預期效益的失敗案例。這些案例引起策略管理學界的注意。在進行許多案例研討之後,策略管理學界確定一件事:並不是模仿成功案例,引用相同的資訊技術,導入相同的資訊系統(業務流程)後就萬事大吉了

對於上述結論,學界有許多解釋。其中一種就是我在《業務流程決定軟體程式,軟體程式追隨業務流程》說的內容。在失敗案例中,企業對自身的核心能耐失焦了。在還沒有掌握到本身核心能耐之前,就貿然地引進新的資訊系統。然而新的資訊系統及伴隨而來的業務流程比較好嗎?

沒有比較的對象,就沒有選擇,也就不會有決策如果有人說「我們具有競爭優勢」,卻沒有提到跟誰比或是相對比較基準,那麼這個人所說的競爭優勢,只不過是一種「感覺」而已,沒有實質意義(See: 失焦的競爭優勢)。在問新的資訊系統及伴隨而來的業務流程是否比較好之前,我要先問企業構成原本核心能耐的業務流程有哪些內容,有哪些優、缺點。在企業並未掌握本身核心能耐之前,就要說新的資訊系統及業務流程比較好,只不過是一種感覺而已。

沒有比較的對象,便無從分析優缺點,也就無從知曉該如何應對才能吸納優點、消除缺點。於是在導入新的資訊系統後,便發生了《業務流程決定軟體程式,軟體程式追隨業務流程》所說的壞結果。結果是在策略管理的講義上,又多了一個可以探討的失敗案例。喔,也許現在策略管理已經不流行討論這種案例了。

相關文章
樂多舊網址: http://blog.roodo.com/rocksaying/archives/3106505.html

樂多舊回應
未留名 (#comment-10144119)
Wed, 02 May 2007 22:21:36 +0800
以業務流程為主,這是沒什麼好懷疑的.

重點在解決問題的本質.這很多人都會說知道,但實際在執行的時候其實都不是這樣.

舉個例子,像很多提倡Agile的開發模式的外國Programmer常常都會說,只要用筆在白板上溝通整個系統設計,並不一定要用工具去畫一些UML的圖.(當然我並不是堅持不用工具@@a)

只是想說,很明顯,不管做什麼事,本來就該回到問題的本質去做,資訊科技很明顯在取代重複性工作非常強,搜尋資料也是,要抓住目前能解決的能力,在該用的地方去發揮才是.

我也好奇,跑去了同人那邊看了一下,對於裡面提到以下
「非資訊技術核心能耐的企業常不清楚....,也沒有辦法為企業創造價值」
這真的很有趣,如果站在是軟體開發公司的角度,這種問題真的出現在很多軟體公司吧.但我個人的想法是,這不是非資訊技術核心能耐的企業的錯,這種公司的任務重點在於清楚訂定需求,我覺得成敗最關鍵人物是軟體公司派去溝通需求這個人,這個人大部分的公司都是會從技術角度出發的,都會很酷的跟你說做不到,其實想一下就知道他是站在哪邊為出發點去做事情就知道會不會成功了,既然你是要開發人家的企業流程的資訊軟體,本來就跳進去熟悉人家的領域,把自己當為是客戶公司中的一員,在來思考資訊科技的支援.

如果以商人的角度出發,最佳解是錢都花在刀口上.其實以軟體公司來說,這樣對自己也是很有好處的,節省自己的時間,不必要去開發無意義的功能,以及不能幫助公司解決問題的功能.

不過我的概念還是回歸到做對的事情,根本的去解決問題.
HACGIS@gmail.com(tokimeki) (#comment-10145919)
Wed, 02 May 2007 23:31:13 +0800
我舉個實例好了:
最近我在學著如何估算成本,尤其是供應商提供的成本。
簡單的說,每個產業都有「行規」,連成本計算也有!

而目前我看到的不同製程,光材料成本這一項計算,就不可能用一個結構性的表格來展現,已目前所知道的部份來說,可以分成底下幾類:

1. 材料淨重 x 材料單價
2. (材料淨重 + 固定數量 or 比例的重量) x 材料單價
3. 材料毛重 x 材料單價
4. 材料淨重 x 材料單價 x 某個特殊的比例數字

以上是單純就材料成本的計算,說實話,沒入行多年光憑道聽塗說或是看書,根本不可能了解這幾種材料計算的意義何在!
所以我比較贊同石頭的意見,但我認為第二種壞結果:
「為了配合軟體的使用,改變了企業內部原有的業務流程。」
不盡然完全是壞的。
這有可能是因為軟體的設計是參照某個最佳實務所建構的,而這個最佳實務的作法根據個案不同,有時的確比公司現行的作法好。
因此我覺得在導入外製的系統的過程中,多多少少還是會修改到現行的流程。
未留名 (#comment-10174973)
Thu, 03 May 2007 15:03:50 +0800
說到成本,我任職的百貨流通業也自有一套計算方式。會隨著交易次數、商品數量與時間而不同。說穿了就是看公司跟客戶之間的「關係」決定成本。

這符合經濟學對成本,也就是價格的定義。價格是商品在買者與賣者之間的「關係」;價格不是商品的屬性。

以 Relationship database table 說明,則價格(price)不是商品表(Products)中的欄位。價格是商品表(Products)與客戶表(Customers)之間的多對多關聯表(ProductsToCustomers)中的欄位。

至於應不應該配合新的資訊系統改變原有的業務流程這問題,我在本文結論強調要先看企業對原有的業務流程了解多少。了解之後才能比較,才能知道如何吸納優點、消除缺點。