对流程设计的合理简化

回应一下某位兄弟的留言，说到流程需要人来管理，把人理顺了，人高兴了，就好办了。大概这个意思吧。

我知道有些话可能政治不正确，但是我所看见的事实就是，有些人，你永远也不能让他/她高兴。这符合我们普遍的认识，就是我们周围的人大概有一类是乐观的，另外一类是悲观的，而财务部门，悲观的人比较多一些。

说到流程的简化，首先要认识到，流程的本身，如果要做得完美，那肯定是复杂的，如果简单了，说明做得不完善。这个道理跟设计一个桌子，或者设计一个开关一样。把东西设计的完整，复杂，说明了考虑的周到，设计者的严密逻辑。这也是SAP的出发点之一。所以第一眼看见SAP的做法，大家都觉得很复杂，不管是哪一个新出来的模块都是这样。

但是第二步，就需要改进，优化，进而包装这个设计，ENCAPSULATE，使用户接触常用的功能，而不常用的功能不是没有，而是隐藏起来。举个例子，刚刚开始做的PORTAL，用的一个设计工具叫IVIEW STUDIO，可以设计IVIEW，功能非常齐全，另外一个方面看，就是复杂，开发者进去之后觉得没有头绪，太复杂了。而后开发出来的是VISUAL COMPOSER，大大简化了制作IVIEW的过程。SAP这时候就推出WIZARD，或者GUIDED PROCEDURE，这就是说可能80％的应用是20％的功能，普遍应用，应该总结出来做为WIZARD进行指导。

结合FUNCTIONAL方面的BPP文件，也有两种争论。一种认为应该严格的按标准写BPP文件，结果一个SOP到LONG TERM PLANNING的BPP文件，大概十几个流程，可以写出一本厚厚的书来，的确完整了，但是谁来看呢？写的人已经很熟悉了，不用看。不写的人没有这么深刻的理解，没有这么同样的知识背景，看这个很头疼，他或许只习惯看图。

一个画流程图的人，是按照标准制作EPC图，还是加上很多FANCY的东西，做出来的流程图很吸引人，也很清楚，不枯燥，但是使用了六种以上的颜色，八种图标，十种箭头呢？ 这永远是争论的话题。

我的理解，在不同的公司需要不同的方式，如果是一个德国的化学公司，机械公司，电子公司，尽管按复杂的，枯燥的文件来招呼吧，他们习惯了这样。如果花哨起来，他们会询问这个不标准的颜色，有什么特别的含义吗？哪里可以找到这个LEGEND或者索引？如果是一个比较缺乏标准化的公司，大多是零售业，消费者产品，（CPG工业），美国的公司，最好遵循这样的原则，只告诉使用者他需要知道的东西，直观，多图少文，不必告诉他为什么，把他当作流程中的一颗钉子，这当然离主人翁思想很远，但是很有效，而且防止了错误的数据输入。这里绝大多数的错误不是系统错误，而是人为的数据输入错误。尤其是在面对一个非视窗习惯的，复杂的软件，几乎所有的非IT美国人都显得束手无策。

在简化流程的过程中，如果分析师有足够的经验，那么就可以平衡客户的意见及行业最佳实践，而做决定，不是事事都听用户的意见，结果弄出个四不象的复杂的流程。比如客户本来的预算过程中有很多步骤，从不同版本之间的拷贝，到重新计算退休金医疗保险的金额，用户提出要分开来，这恰恰是隐患。因为只要拷贝到新版本，就必须重新计算养老金和医疗保险，否则就不是完整的。在旧有系统里，用户习惯了分开走两步，那是系统的限制。现在可以合并的时候，为什么不合并呢，用户没有必要分开走，分开的隐患在于用户可能忘记了第二步，从而出现错误，这个错误是流程设计的错误，结论是，不要时刻都听客户的，当然，我们当面肯定有更加艺术的说法。

很多步骤可以合并，然后以报表或者监视器的方式提供给客户可视，可以DEBUG。但是步骤可以合并。另外有个例子在PP的SOP计划里也是如此，下次再举例吧。

 

今天德国队获得了胜利，我很高兴，究其原因，完全是因为我的职业方向，才开始喜欢这个国家这个文化这个民族，我不知道是否有因为文学而喜欢俄罗斯的，因为巧克力喜欢瑞士的，因为时装喜欢法国的，但是我的确很深刻地体会到了SAP在德国的传统，的确追溯到了19世纪的普鲁士总参谋部体制。这个以后也可以谈，因为对这些背景理解越多，越有助于掌握SAP。

关于国内SAP同行将来的前景，和美国的合作，甚至整个全球的合作，我有很多想法我想是比较切实的，而我们正在印度执行的，这个也要谈到具体的想法。可以让大家明白美国方面SAP行业期待国内的同行什么，和国内的同行应该对全球的SAP行业的合作有什么合理的期待。

推荐到鲜果：