[原创]莫把流程e化当成流程优化

 

过去几年，IT越来越多的应用到企业运作和流程优化工作中，并以“时不我待”的强劲势头继续发展。很多组织的流程都e化了或正在e化中，在百度上输入“流程e化”搜出近50多万条结果，在Google上搜出的更多，接近300万条。这些e化小则是通过OA将某些Office间的流程自动化，或开发Lotus Notes之类的工作流解决跨部门间的信息流转和审批问题，大则是通过实施比如进销存、ERP、CRM、PLM等企业管理软件来重整企业的运作。

几年前我个人对流程与信息这种“结亲”方式是非常推崇的，实际工作中做了很多流程e化的案子。流程 “e化”的效果也比较明显，比如减少“公文旅行”，自动化一些简单重复劳动，可以方便的获取流程状态和流程绩效数据等等。以04年做过的一个供应商认证审批流程为例：在流程e化前，为审批一个供应商得准备10好几套资料，各种签字加起来超过30多个，这些公文旅行上个把月是毫不稀奇的，专门配置一个文员负责传递文档资料，想知道审批进度，得挨个问一圈，最要命的是这些辛辛苦苦准备的资料时而不时还要玩失踪。自从简化流程并e化以后，运作效果大为改观，审批通常在5个工作日内就能完成，流程走到哪一步一清二楚，再也不会丢失资料，也不怕领导出差了，能上网的地方就可以审批。

但是最近我对e化的态度多了一份谨慎，源于一位朋友给我讲的一个e化案例。这位朋友8月份负责评估一个物料评审流程的优化效果，该流程在今年4月经历过一次优化并e化。但是统计显示，该流程e化后运行周期并未缩短，反而有所变长，流程环节较优化之前还多了几个，问及原因，负责该业务的主管大倒苦水。优化前评审流程一个重要环节就是评审会议，参加评审会议的部门有6个，由于很难凑齐6各部门的负责人开会，流程经常停留在“等待”评审会议环节。流程周期过长，物料不能及时处理，引起不少抱怨和内部投诉，该主管组织优化流程，最大的措施就是e化，据说开发了一个超级复杂的电子系统，有多少个环节我也记不清了。原来评审会议相当于一个并行的审批，现在评审会议不开了，参与评审的6个部门都变成电子流程的一个串行环节，还有两个部门原先是不参加评审会议的，因为电子评审比以前“方便”了，也要求“搭便车”参加电子评审，于是评审由原先6部堂议变成8部盖章。

改成电子评审后，虽然业务主管不再为召集会议难而犯愁，但是并没有轻松下来，跟催审批和协调各部门之间的意见又成了新的难题，很多审批在不同部门间意见难以达成一致，流程在不同部门间踢来踢去，耗费很多时间和精力，这个问题原先也是有的，只是没有现在严重。当时有评审会议，大家有意见可以在会上面对面沟通，扯皮归扯皮，一般到最后还是能够达成妥协。E化后，大家不再开会，沟通随之变得更加简化，大家对着电子系统从本部门的角度说“YES”或者“NO”就完事，至于流程最终结果如何，除了负责物料评审的部门，其它部门是不关心的。为了协调各部门尽快达成一致意见，该主管不得不设立了一个2人协调组，专门跟催审批和调解各部门的分歧。

这位朋友做完评估后感慨都是e化惹的祸，并与我讨论e化算不算流程优化。听完朋友讲的故事，不禁想起在我所服务的组织中也有类似的倾向，谈到对某流程优化时，很多人首先就是想到要给待优化的流程建立一个电子系统将流程e化，有时除了想到e化之外，似乎没有其它思路。

是否e化之风过了头，大家下意识的将e化就当成了优化的全部。就前面的那个物料评审流程而言，e化本身并没有过错，问题是我们e化了一个什么样的流程，e化前后是“舞照跳、马照跑”吗？我想不应当如此，以该流程的评审会议为例，我们e化之前至少应当考虑为什么要评审，为什么要这些部门评审，这些部门在评审中都发挥了什么作用，评审只能是人来决策吗，是否有标准可以遵循，只有评审一种方式吗等一系列问题，彻底思考并真正回答这些问题之后，我们将要e化的流程与原先的流程或许就完全不一样了。

我不反对e化在流程优化中的作用，但是建议流程优化时不要把e化作为优先考虑的措施，流程优化的本质在于思考和创新，抛开本质一味的e化未必能够达到优化的目的。

推荐到鲜果： 查阅更多相关主题的帖子: 流程优化 流程管理案例 信息化 e化 企业变革