業務流程決定軟體程式，軟體程式追隨業務流程
喲哪桑說「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 。
然而許多企業根本沒有意識到這件事，他們沒有意識到軟體程式和業務流程相對應，環環相扣、密不可分。當他們要外包時，只留意到規格與功能需求，而忽略了業務流程。不經意之間，就由外包的軟體公司代訂了企業的業務流程。這往往只有兩種壞結果。
- 企業員工抱怨連連。此便為軟體內部映射的業務流程與企業運行之業務流程不一致所產生的不協調狀況。
- 為了配合軟體的使用，改變了企業內部原有的業務流程。
喲哪桑說知識無法累積成為核心能耐，指的就是上述第二種壞結果。不幸的是，這種情形非常普遍。
軟體的開發作業可以外包，但業務流程不能外包。業務流程是一家企業針對產業特性與自身競爭優勢之知識累積後才產生的最佳作業實踐方式，是企業重要的知識基礎與核心能耐。策略管理有句名言「策略決定結構、結構追隨策略」。我在此引用修改為「業務流程決定軟體程式，軟體程式追隨業務流程」。
話說回來，有哪個程序員願意天天被客戶抱怨自己設計的軟體不好用？像我就會想「明明是你說不清自己的作業流程，反而抱怨我的軟體不好用」。在資訊技術領域中不是沒有注意到這種情形， SOA 概念正是為了解決上述問題而興起。 SOA 概念很好地將「軟體開發」與「業務流程」兩種範疇切割開來，使軟體能跟隨業務流程快速重組。同時令人們注意到業務流程才是主角，軟體只是工具與配角。
樂多舊回應