业务流程决定软件程序，软件程序追随业务流程策略

哟哪桑说「I Don't Like Outsourcing」。他说因为外包，将确保你的软件知识不再累积，软件也无法成为你策略性的核心能力(Core Competence)。

基本上，哟哪桑是从 Resource Based View/Knowledge Based View (RBV/KBV) 之观点主张不要外包。然而我以为哟哪桑的观点有必要加以修正，才能正确表达他所要表达的意涵。「软件」一词没有抓准非IT企业的核心能力之本质，精准地说「软件开发」并非IT企业的核心能力，「业务流程」才是非IT企业的核心能耐。

当年我在攻读 MBA 的时候(*1*1 虽然我的编程能力非常显著，但我大学读国际贸易、研究所修企业管理，是正规的管理科班生)， 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个中文字时，那么使用者就要改名才行。易言之，我规定了使用者的名称长度，不合规则者受罚，不得使用(*2*2 此亦为自由软件(Free Software)易与倡议公民自主性的社会运动产生联系的缘由。因为自由软件将制订规则的权力还给了使用者)。

在企业中，企业用软件所规约的内容就是企业的业务流程了。所以程序若规定要先填采购单且经过签核后才能产生进货单，就等于规定业务流程必须如此作业。当然对企业而言，这段话应该要反过来说才对。如果我的业务流程规定这么运作，那么程序就要对应着设计。企业用软件的 program 应该要对应企业的业务流程之 program 。

然而许多企业根本没有意识到这件事，他们没有意识到软件程序和业务流程相对应，环环相扣、密不可分。当他们要外包时，只留意到规格与功能需求，而忽略了业务流程。不经意之间，就由外包的软件公司代订了企业的业务流程。这往往只有两种坏结果。

·企业员工抱怨连连。此便为软件内部映像的业务流程与企业运行之业务流程不一致所产生的不协调状况。

·为了配合软件的使用，改变了企业内部原有的业务流程。

哟哪桑说知识无法累积成为核心能耐，指的就是上述第二种坏结果。不幸的是，这种情形非常普遍。

软件的开发作业可以外包，但业务流程不能外包。业务流程是一家企业针对产业特性与自身竞争优势之知识累积后才产生的最佳作业实践方式，是企业重要的知识基础与核心能耐。策略管理有句名言「策略决定结构、结构追随策略」。我在此引用修改为「业务流程决定软件程序，软件程序追随业务流程」。

话说回来，有哪个程序员愿意天天被客户抱怨自己设计的软件不好用？像我就会想「明明是你说不清自己的作业流程，反而抱怨我的软件不好用」。

在信息技术领域中不是没有注意到这种情形， SOA 概念正是为了解决上述问题而兴起。 SOA 概念很好地将「软件开发」与「业务流程」两种范畴切割开来，使软件能跟随业务流程快速重组。同时令人们注意到业务流程才是主角，软件只是工具与配角。

查看本文来源