2007年04月23日

業務流程決定軟體程式,軟體程式追隨業務流程

Tags: 策略管理 競爭優勢 分工 KBV SOA

喲哪桑說「I Don't Like Outsourcing」。他說因為 外包,將確保你的軟體知識不再累積,軟體也無法成為你策略性的核心能耐(Core Competence)

基本上,喲哪桑是從 Resource Based View/Knowledge Based View (RBV/KBV) 之觀點主張不要外包。然而我以為喲哪桑的觀點有必要加以修正,才能正確表達他所要表達的意涵。「軟體」一詞沒有抓準非IT企業的核心能耐之本質,精準地說「軟體開發」並非IT企業的核心能耐,「業務流程」才是非IT企業的核心能耐。


當年我在攻讀 MBA 的時候(雖然我的編程能力非常顯著,但我大學讀國際貿易、研究所修企業管理,是正規的管理科班生), RBV/KBV 還是相當熱門的議題,也不乏從 RBV/KBV 觀點討論整合與外包 (Integration or Outsouring)、 Make or Buy 之策略管理議題。在當時,我們注意到 事實上,如核心能力之類的主張,往往變成一種「感覺不錯」的課題,既然只是一種感覺,就似乎不會有人失敗。(企業策略: 37; C. K. Prahalad等著, 李芳齡譯; 天下遠見出版, 2001第一版)。我還寫了篇「失焦的競爭優勢」的報告作業。人們在提到核心能耐時,常常失焦,並沒有抓準自身企業的業務本質。

當喲哪桑說「軟體無法成為你的策略性的核心能耐」時,我可以了解他所要表達的內容。但「軟體」一詞實在太過含糊,不足以正確表達他的觀點,反而容易令議題失焦。

當我談「軟體外包」的時候,我指的是「軟體開發」的工作。這項工作對於非IT企業而言,並非其核心能耐。將其外包殆無疑義。但企業在軟體外包時常常忽略非常重要的一件事:企業用軟體通常是其業務流程的資訊化映像(Image);亦即企業用軟體的 program 要對應企業的業務流程之 program

對程序員而言,程式就是規則與律令(rule and law)。當一個程序員寫下一道程式時,就等於制訂了使用者的行為規則與律令。例如當我限定使用者名稱的最大長度是4個中文字時,使用者就只能輸入4個中文字。如果使用者的姓名不是漢名因此長度超過4個中文字時,那麼使用者就要改名才行。易言之,我規定了使用者的名稱長度,不合規則者受罰,不得使用(此亦為自由軟體(Free Software)易與倡議公民自主性的社會運動產生聯繫的緣由。因為自由軟體將制訂規則的權力還給了使用者)。在企業中,企業用軟體所規約的內容就是企業的業務流程了。所以程式若規定要先填採購單且經過簽核後才能產生進貨單,就等於規定業務流程必須如此作業。當然對企業而言,這段話應該要反過來說才對。如果我的業務流程規定這麼運作,那麼程式就要對應著設計。企業用軟體的 program 應該要對應企業的業務流程之 program 。

然而許多企業根本沒有意識到這件事,他們沒有意識到軟體程式和業務流程相對應,環環相扣、密不可分。當他們要外包時,只留意到規格與功能需求,而忽略了業務流程。不經意之間,就由外包的軟體公司代訂了企業的業務流程。這往往只有兩種壞結果。

  1. 企業員工抱怨連連。此便為軟體內部映射的業務流程與企業運行之業務流程不一致所產生的不協調狀況。
  2. 為了配合軟體的使用,改變了企業內部原有的業務流程。

喲哪桑說知識無法累積成為核心能耐,指的就是上述第二種壞結果。不幸的是,這種情形非常普遍。

軟體的開發作業可以外包,但業務流程不能外包。業務流程是一家企業針對產業特性與自身競爭優勢之知識累積後才產生的最佳作業實踐方式,是企業重要的知識基礎與核心能耐。策略管理有句名言「策略決定結構、結構追隨策略」。我在此引用修改為「業務流程決定軟體程式,軟體程式追隨業務流程」。

話說回來,有哪個程序員願意天天被客戶抱怨自己設計的軟體不好用?像我就會想「明明是你說不清自己的作業流程,反而抱怨我的軟體不好用」。在資訊技術領域中不是沒有注意到這種情形, SOA 概念正是為了解決上述問題而興起。 SOA 概念很好地將「軟體開發」與「業務流程」兩種範疇切割開來,使軟體能跟隨業務流程快速重組。同時令人們注意到業務流程才是主角,軟體只是工具與配角。


Posted by shirock at 樂多Roodo! │16:09 │回應(2)引用(6)Programming
樂多分類:學術/學習 工具:加入樂多書籤編輯本文
Ads by Roodo! 

引用URL

http://cgi.blog.roodo.com/trackback/3045651
引用列表:
以企業層次的策略觀點來看,核心能耐在於整合各事業體(business unit)以產生綜效。所以,有關核心能耐的問題並不在於如何分工,而是在於有效整合。企業價值鍊活動必須有效地整合才可.....
委外與流程整合【同人的生活派對】 at 2007年04月30日 14:35
當我強調業務流程不應外包時,其意義就等於賦與企業的 CIO 與 MIS 更重要的策略性地位。如果企業的業務流程是由軟體承包廠商制訂,則企業的 CIO 與 MIS 將失去其策略性角色
BPR 並非導入資訊系統後就萬事大吉【石頭閒語】 at 2007年05月1日 22:56
在世界是平的另一端,世界也愈來愈不平;因為整合愈來愈難,要有具備適應環境的變化無常的能力,才是委外服務提供者的功力。事實上,開發企業軟體,並不如一般人所想的「業務流程......
回應石頭成-再論流程整合【同人的生活派對】 at 2007年05月2日 17:43
我們的觀點都指向同一個重點,那就是溝通。當一個企業決定執行資訊系統委外策略時,甲、乙兩方如何有效溝通,將是此分工策略之成敗關鍵。
資訊委外策略成功的關鍵在溝通【石頭閒語】 at 2007年05月3日 18:22
在網路上看到這一篇,突然覺得,這學期學弟們Java作業不也是這樣嗎??學弟們的Java作業是要做一個簡單的ERP,簡單是指要包括進銷存、簡單的人事加上簡單的會計,但是大多數的學弟在期中簡報的時候,沒有辦法回答TA們提出來的問題,真正的原因,是因為他們自己沒有深入了解被訪談的公司的真正需求,常常內容裡有「我認為」、「我想他們是這樣做的」、「他們的流程我不清楚,但是我覺得可以這樣做」之類的話。不可否認的,E化的過程,必然帶有一定程度的BPR,否則就不算是E化,尤其是如果該公司本來沒有任何的IT、IS時,導入E
[轉貼]業務流程決定軟體程式,軟體程式追隨業務流程【現在 是沒有過去的未來】 at 2007年05月3日 22:25
Tags: 策略管理 核心能耐 比較利益 自知 當我在閱讀同人的《企業邊緣決定企業策略》時,有些內容我一直覺得很奇怪。雖然
談核心能耐之聚焦【石頭閒語】 at 2007年05月11日 16:22
回應文章
其實還得要注意一點的是:就算是企業主知道,程式設計公司無法為企業決定其業務流程,但是企業主通常針對業務流程這方面也很少與程式設計公司進行溝通,就算溝通,多半的程式設計師也是無法去瞭解其中所代表的意義(就算了解也是會有搞錯的時候)。

好一點的,有些企業會與所謂的『顧問』進行合作,由顧問進行業務流程的改造,再由程式設計公司進行業務流程的資訊化,這通常會造成相同的問題(甚至花了更多錢,結果還是一樣),其原因還是在溝通。

其實最好的方式,就是由業主指定一個與此正在進行開發的資訊系統有業務關聯的團隊,加入顧問及程式開發公司的專案團隊中,只是問題又來了,如何能夠讓這些各部門的負責人員重視此一團隊而『積極構通』?這通常要看企業主的態度,我個人覺的,類似這種業務流程資訊化的案子,其成功的機率都要視企業主的重視程度而定,而不是資訊主管的積極程度而定。
Posted by Linul at 2007年04月25日 14:08
確實如此。很多企業主都認為,我花了錢你就要寫好程式,其他一概不知道。為什麼我要說「不知道」,因為他們真的不知道。

台灣很多中小企業,經營者大多是業務或技術出身。以 MBA 的眼光去打量,那些經營者其實相當缺乏管理觀念。因此我問業務流程、問 SOP 等等,是一問三不知。

我以前在軟體公司工作時,與客戶訪談就碰到這種情形。客戶反而會說「我怎麼知道?這不是你們要寫的嗎?」也就是說,他們把「業務流程」與程式混為一談了。我問他們的流程,他們認為我在問程式怎麼寫。

我現在在零售與貿易公司做 MIS ,對公司內部管理階層缺乏管理觀念的情形更有直接的感觸。有時候要幫公司內部設計一些軟體程式,也要再三溝通,但結果常常是無疾而終。也好,我領得只是小小MIS的薪水,可不是企管顧問的薪水。無疾而終,我也樂得少做事。多些時間可以上來逛逛部落格。
Posted by 遊手好閒的石頭成 at 2007年04月25日 15:16