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

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

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

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

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

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

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

当然，这对真正的用户来说不存在问题，他只要完全按日常的业务去操作，没有犯错，那系统会很乐意接受他的数据。

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

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

不断积累可移植移强、通用性强的方案，这就是我追求的目标和我一贯的做事方法。也是为什么几年前要花50个人天去做的项目，现在也许只需要30个人天的原因。

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

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

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

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

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

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

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

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

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

而你放手的资本，就是你在你的方案中，已经尽可能地把所有的意外情况考虑进去，杜绝了所有难以回滚的灾难性操作错误，你的方案容错性已经最大程度得到扩展。这就是你最大的资本！

所以，大家在这里阅读这些方案时，稍有一点可供分享的，不是ADDON，不是技术，也不是多么巧妙的SQL语句，而是设计和思考这些方案的思路，以及期望这些方案能达到的目标，这才是希望与大家一起共勉的！