奥卡姆剃刀原则在ERP项目的应用

一贯崇信“奥卡姆剃刀原则”，如非必要，毫不新增。

在我所实施的项目中，自定义字段、自定义报表很是少。很极端的一个例子是，曾经有一家工厂，生产打印机的部件，产品百分之百外销。

在项目实施完成，成功上线后，我发现整个系统中的自定义的查询报表不超过5张，自定义字段不超过10个，格式化搜索不超过5个……

 

但实施的项目，又能够说是很是复杂。还以上面那家工厂为例，虽然打开他们的系统，你会为它的简单而大吃一惊，但若是真的

按照业务蓝图所规定的流程实际操做一次，你又会很头痛它的复杂。

只要一个不当心，一个输入错误，或者想偷偷懒绕过某张基础单据、绕过某个须要预先定义的设置项，系统都不会容许你保存。

要走通个人流程，估计得花很长的时间吃透我业务蓝图上规定的流程逻辑、单据的流转逻辑，你才可能很顺利地一次性操做成功。

固然，这对真正的用户来讲不存在问题，他只要彻底按平常的业务去操做，没有犯错，那系统会很乐意接受他的数据。

因此，其实并非方案简单，而是习惯把复杂的逻辑藏在背后，用户看到的东西越简单明了越好，但系统中的逻辑必定要很是精细、严谨，经得起错误操做和新手操做的考验。

把一些复杂的事情，花一点时间封装起来，让用户也好，顾问也好，都能简单地应用，这就是在这篇文档里所描述的“方案”的概念。

不断积累可移植移强、通用性强的方案，这就是我追求的目标和我一向的作事方法。也是为何几年前要花50我的天去作的项目，如今也许只须要30我的天的缘由。

作任何事情，都须要有本身的积累。这就比如走路同样，不喜欢走同一条路，一样我也不乐意换一个项目就得从新去作一个方案，或从新去写一段SQL代码，或者从新去开发一个报表、加一个字段……

若是有一个很特殊的需求，咱们只须要从以前的通用方案中随手拈取一个，花几秒钟的时间简单改一改配置，就能放到新的数据库中，那会有更多的精力去关注如何达成项目的目标，而不会为软件的功能限制了你的拳脚而苦恼。因此，须要思考的是：设计任何方案，都不该只知足于当前的客户和他当前的需求，而是要考虑这个方案是否能够扩展它的健壮性，让它能尽可能通用，尽可能提升可移植性，尽可能能作一个简单的勾选和配置，就能知足下一个客户的不一样需求？只有这样不断积累本身的方案，才能越作越轻松，越玩越能感受到ERP的无穷乐趣。

 

一个项目实施如何才能算完美，什么才算是实施能达到最好的目标？我常常思考这个问题，其实并不认为一个方案有多么出乎意料，或者有多么让人赞扬的巧妙思路，或者是否能彻底涵盖客户的全部需求，甚至有多么高的技术含量这些东西是一个完美项目的判断标准。一个项目成功的关键只有简单的两点：

• 达到管理提高的目标。那么如何才算是管理提高了呢？从中小企业定位来看，它能给企业带来的最大提高，就是将先进的管理理念经过顾问设计的管理流程固化和推广，让成长型的中小企业摆脱做坊式管理的桎棝，得到高速成长的助力。固然这是理论化的说法，若是咱们把这个概念说得通俗一点，就是经过上ERP系统，老板能够制定一个游戏规则，而后用ERP这个工具控制住关键点，不按这个规则走就走不通。而后老板能够带着小秘出去晃悠半年回来，发现他的企业仍是规规矩矩按着这个游戏规则在运做，不须要他去盯着，ERP这个工具就帮他达成他想要怎么管理企业的思路了，这就是ERP能给企业带来的管理提高！
• 项目实施完成后，客户能自行维护。这也是评价一个项目实施成功的关键点。若是项目实施完成，顾问离场几年后，客户还不断为添加过帐期间、为某个新业务要改变某个设置，或者为不理解某个单据、某个报表的数字而头痛，那么顾问也烦，客户也对这个系统内心也没底。因此在项目实施过程当中，必需注意培养客户成长起来，永远不要惧怕客户知道得比你多，相反，他知道和了解得越多，对这个系统也就会更有信心，同时对你的难点也会体谅得越多，不会再无休止地给你出难题。

因此，在项目实施中，不会太多关注操做人员的利益，会更多关注流程是否会被操做人员绕过去，会关注是否某个流程的关键点会失去监控，会为那些依赖于操做人员的“自觉性”或者过于依赖操做人员的素质才能干好的事情而难受，在设计的流程中，每每更多会体现部门间的互相牵制，而不会去在乎操做的快捷和便利。所设计的外协加工流程，须要横跨采购、计划、仓库、财务部门共同协做才能完成，会禁止用户直接用MRP的结果生成采购和生产订单，甚至我还会禁止销售订单直接生成采购订单。若是只能选择其一，那会选择让系统去检查必填项，而不会期望一个自动刷新的格式化搜索去减轻输入工做量。我相信站在老板的角度，他也会更关注控制而非便捷。毕竟请个文员的成本，远不如流程失控带来的隐性损失大。

所以你们在下面的方案中，其实能够看到，大多数的方案都是偏向于逻辑的控制，而非减轻操做人员的负担。目标始终在于把ERP作成老板的工具，而不是操做人员的OA工具！

在每一个项目中，为了保证个人流程有效，控制点都有将近上百个。或许有人会怀疑这会影响系统的运行效率。我不想在这里阐述这个担忧是多余的，只想说明一点，只要目标是正确的，那咱们付出多大的代价均可以接受，而且“影响效率”的事还能够经过科学的代码编写来很好地规避。因此当项目实施上线后，不用担忧脱离个人指导，系统会由于错误操做而带来致命和不可挽回的影响。我会很是放心地放手让客户的系统管理员去接手项目，我宁肯不赚客户的维护工单，宁肯远程指导，也逼着系统管理员迅速成长起来，可以自行维护他的（而不是个人）系统。

基于这种风格，在项目实施中和系统上线后，不少时候的表现能够称得上是“残酷”和“无情”。不会让操做用户直接找我，有事情必定要汇报给系统管理员，只会回答系统管理员提出的问题。而在一个项目实施结束后，惊讶地发现，我几乎都叫不出某些操做人员的名字，只知道这张脸孔是哪一个部门的！而系统管理员在一年之后，成长为一个合格的顾问，本身的职业生涯也拓宽后，在他内心，他不会后悔曾经承受的压力和付出的汗水，他对你也会有那么一点点的感激之情！

要作到这点，其实不难，只要在上线后，你足够放心地放手就行！

而你放手的资本，就是你在你的方案中，已经尽量地把全部的意外状况考虑进去，杜绝了全部难以回滚的灾难性操做错误，你的方案容错性已经最大程度获得扩展。这就是你最大的资本！

 

因此，你们在这里阅读这些方案时，稍有一点可供分享的，不是ADDON，不是技术，也不是多么巧妙的SQL语句，而是设计和思考这些方案的思路，以及指望这些方案能达到的目标，这才是但愿与你们一块儿共勉的！