在以IT制造业著称的台湾，经由十余年来的推广，ERP已然成为企业级信息软件的主流旗舰，由许多大专院校均可看到相关专门课程便可看出ERP受重视的程度。

    也由于ERP的普及性与基础性，使得ERP在各企业内有了一个很有利的立足点，而依据这个立足点，各ERP大厂也莫不致力于设法跨大自己的版图。最明显的莫如Oracle近年来连串的并购动作(笔者过去曾接触的Siebel、PeopleSoft、BEA均先后被并，中签率还真不低)。

    而随着BPM需求的提升，各ERP大厂自也不会放过这个商机而纷纷切入BPM市场：Oracle并购了Collaxa后推出Oracle BPEL Process Manager，SAP则是强调BPM的精神一直存在于SAP内并推出SAP Exchange Infrastructure (XI)。

    综观各种条件，ERP厂商实在是有着相当不错的先天条件，毕竟依据以色列籍的产业工程协会顾问Avraham Shtub教授（有人问我为什么不用Gartner的定义，我认为因为Shtub的定义比较简短而有效地把ERP跟流程结合）对ERP下的定义：“ERP 是一个单一的信息系统，这个信息系统提供一个整合的数据库及精致的模式库来支持组织的所有流程。”所以处理流程对ERP来说几乎可以说是天职。只不过 ERP软件包虽然宣称具有相当的弹性与强大的功能，但却难以满足所有企业在流程与功能上的需求，因此多数的企业在导入ERP系统时仍必须面对到底要修改 ERP系统来配合企业流程还是修改企业流程来配合ERP系统的课题。

    关于这点业界普遍认为企业级的软件包（这里主要指如ERP、HR、CRM等对一般使用人员有一定操作顺序的系统，而不含平台类如Portal、DW、DB 等）它的价值是在流程而不是技术，因为其内建的business process都是软件公司找顾问设计出来的best practice。而依据前进国际的ERP导入经验：该公司客户没有一个不经过定制化。但企业排得上全球五百大的寥寥无几，“如果你是台积电或巨大机械（捷安特制造商），我们相信我们软件应该为你大幅修改；”他说，“但如果你不是，那有多少理由相信你的流程是独特而有价值的呢？”一旦修改过大，也就失去了导入ERP的原意 。

    另一派则认为软件包的这些限制主要是为了方便软件供货商能大量重复销售之用。这一方面是软件供货商本身的商业考虑，另一方面则是市场需求。即便如台积、联电这般的大企业在导入时也免不了常常会问：“别家是怎么做的？”供货商自然需要汇总出所谓Best Practice来满足这类的咨询需求。另一方面企业越来越没耐心、要求速效也是因素。由大前研一著作中可窥知早期企管顾问在辅导客户时可是得经历对该企业相当份量的实地探访后才会开始给出建议要采取哪些措施。而今企业则是先决定是要导入BSC(平衡计分卡)、ISO、ABC…后才找顾问公司来像上课一般的实施导入。连企管顾问都得顺应市场标准化、模块化了，（现今BSC等名词都是现今企管常用的“销售套餐”）又怎能说是因为信息公司存心不良想取巧，套用 Best Practice便宜行事？

    “到底要修改ERP系统来配合企业流程还是修改企业流程来配合ERP系统？”就我来看是个假议题。在问这问题之前，应该先问的问题是“该买软件包还是自行开发?”或是晚一些的“该买哪一家软件包？”。而不是等到购入特定ERP了才来烦恼要改多少。

    就好比以情人节大餐为例，第一步要决定的是要自己在家搞烛光晚餐还是出去吃，若决定要出去吃那第二步才是决定要去哪吃、吃什么。而非不管三七二十一先冲到了王品牛排却硬要厨房给你搞个羊肉炉出来。当然肯不惜成本用钱砸也不见得不行啦，不过何苦呢？结果就是花了几倍的钱请一个可能根本没煮过羊肉炉的大厨来做羊肉炉而且原料与厨具都不对，虽是一流的大厨但那羊肉炉的滋味除了国王的新衣效应外只怕没啥值得称道。(不过这点业者的业务手段也需要负点责任，毕竟王品的业务不会在客户于门外询问羊肉炉时响应想吃啥都没问题，先进门再说。)

　　前面离题拉拉杂杂谈了一堆主要是回归主题，说明一些我目前观察到部分导入ERP企业的现象或问题。同样的现象在国外或在不同企业导入ERP时不见得会发生。

    稳定性重于弹性——首先比较明显的是ERP的发展历程是由MRP起家，因此先天较注重的就是如何确保有足够的数据来支持产生一个可供信赖的MRP排程，较注重后台骨干的事务系统角色如稳定、数据保存与尤其是数据运算。ERP传统的操作前提也是认定凡输入系统的数据均为具有相当可信度的低变动性数据–数据必须要可靠才能算出可信的排程，否则工厂的排程可就天下大乱。这也是为啥直觉上一个简单的修改订单动作到了ERP可能就得一路回转好几个程序才能达成。也因着这样的传统，因此 ERP先天认为数据的确认是在登打入系统前就应完成的动作，故传统上早期ERP设计的目标操作人员就不是一般人员而是专业的事务人员。

    功能复杂——由于ERP起初是设计给专业的事务人员使用，且功能实在众多，加上由于庞大的数据量与数据复杂度，造成了操作复杂度超出一般可直觉化操作的范围，因此对一般使用者的接受度向来不高。最明显就是，虽然ERP本身就有相当强大与准确的各式报表，但几乎没有哪家企业的哪一层主管会自己进ERP看报表的（会计与信息单位是异数），一般都是由助理或是会计、信息单位来代劳。同理要一般主管进ERP系统进行各种查询与审核也满困难的。

    这方面ERP厂商企图透过web化或说portal化接口的方式来改善已有一段时日，但革命显然尚未成功。这可说为了满足发展历程中各种特殊的需求而陆续加入的功能太多太庞大，一方面还没抓到sweet point，一方面则是舍不得放弃既有功能，有点类似在i-phone面市前的各种高阶手机：功能一支比一支强，对于真正懂得如何使用的人确实十分方便，但对于大多数人而言却是太过复杂、难以使用而无法形成足够使用诱因。

    权限控管严格——再来则是ERP由于模块分工精细，数据庞大，各种的权限控管也因此复杂化。最传统的控管方式就是一次登入一个模块，若要参考其它模块的数据就得跳出原模块后再重新进入新模块 (这可曾是EIP好一段时间的商机所在，透过EIP的portlet来一次access不同模块的信息)。以流程的观点来看所造成的不便就好比当你跟人以 email联络时，得在第一个专用信箱发信，但当对方回信时却是回到另一个第二信箱而你登入并于第二信箱回复对方后，当对方再度回信却又是回到另一个第三信箱于是你得登入并于第三信箱回复…etc。不同的信箱(模块)专门负责收不同阶段(status)的信件，而不是在单一信箱便可综观全局处理完所有的事。

    以专业化分工的观点，一个专业部门的操作人员应仅负责单一专业事务故只专门处理单一信箱（模块）的工作没啥不便。但对于分工没那么细的企业而言，可能一人身兼几个步骤，或是需具有跨部门视野的较高阶主管而言，要追踪流程综观全局就相当的不便。

    此外如前所述ERP先天注重的是信息流（Data flow、Information flow）的查验与计算。业务流程（Business flow）上的决策行为、行动计划等并非其关注的领域；而系统上的决策行为与行动计划就又牵扯到管理思维的不同。尤其是美国、西欧等国，习惯自动化的管理思维，也就是将逻辑交给系统管，符合规定的就系统按照SOP（标准作业程序）进行，不合规定的就直接挡掉，也不用啥主管来参与审核或是拟定行动计划了，因此也就不用啥人工签核与主管参与了。主管负责的是更策略性、规划性、决策性、领导性的工作而非批准假单、订单、采购单这些事。

    但在东亚、南欧等地区则不是如此运作的。无法摆脱图章文化是一个因素，还有就是对于“规则”的不信任，或是说思想比较“活”，不想被规则绑死。于是按规则来办不敢接的单台湾硬是有办法先接下后再想办法获利，这样的弹性与经营模式也是台湾电子业成功的因素之。

　　定制化的困难以及后果

    而当一家公司愿意投入资源来改善以上情况，想要定制化时，先不管较难处理的后端流程逻辑，光以直觉上应该较单纯的UI要客制也多比一般人预期的难。主要是各家ERP都有自己独家的特化程序语言与上段提及的权限问题及各种相依数据之防呆查验等，造成的相互影响往往远比一开始所能预料到的复杂得多。而且更惨的是当ERP要升级时，这些客制部分往往不保证能正常运作。是以不少企业可都有着ERP升级比导入反花了更高成本的经验。即便不谈升级，当运行期间发生问题时，原厂往往是不支持的，不少原厂support网站可都明写着(虽然字体都不大)：只接受能在OOB安装(Out of box即产品最初干净未经客制的安装)上重现的问题，其它问题请按照顾问标准收费。

    ERP-centric solution的问题

    上述这些ERP的限制是目前企业在应用ERP时可能遇到的问题，而目前ERP相关领导厂商所提出的BPM解决方案却偏重解决自家模块间的流程整合与弹性调整，也较偏向前述自动化的面向，这个发展也是顺着“自动化”思维的需求所产生，对于企业文化不同的地区来说不合用。

    除上述如使用者接口等缺点外，ERP凭借其超重量级的压倒性优势地位，长久以来对其本身与外部系统间的整合方案一直不是十分热衷（由传统ERP厂商观点来看，何必费力去整合外部系统呢？用功能相仿的自家ＸＸ模块来替代该外部系统不是更好更有利？是以才会不断的扩充新模块新功能，期望能达到所谓的Total solution），因此与外部系统的整合是另一个目前由ERP厂商所提出的BPM解决方案上着墨较少的部份。这部分随着SOA风潮吹入ERP领域或许可有相当的改善幅度，不过至少还得等一段时日便是。

    最后要提的是，虽然理想中一个良好的独立BPM系统（非ERP build-in BPM）可以：

    ?补强ERP所不涵盖的业务流程与外部流程。

    ?以流程的观点将所有事项集中在统一的使用者接口。

    ?以客制简化的审核画面来取代ERP过于复杂的操作页面。

    ?跨越模块限制将所需数据一次一体呈现。

    不过也有其主要限制如：

    ?无法违反ERP模块内的基本流程。比如ERP就是要先有订单才能出货，用了BPM也无法逼ERP先出货了再补订单。

    ? 难以涵盖所有ERP复杂的检核规则。结果就是于外部系统产生的数据不见得能完全通过ERP的检核成功汇入ERP。解法一是输入画面维持在ERP环境下输入，待 ERP检核通过，再将业务所需信息传给BPM进行业务流程。不然就是ERP厂商大发慈悲提供相对应的完整web service给外部系统先行套用相同规则检核。

    这两点主要限制也是需要让各位知道的，免得对于用BPM来改善ERP有着过多的期待。