前面离题拉拉杂杂谈了一堆主要是回归主题，说明一些我目前观察到部分导入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有着过多的期待。
