转载

系统实施前搞业务流程详细设计咨询没用

我经常遇到有些企业在上ERP以及类似的大型企业管理信息系统（例如CRM、PLM、HR系统等）之前，启动一个“流程梳理”项目，他们的大致要求是：面向特定业务范围，按照流程分级的原则，输出在未来信息系统支持的环境下，从宏观到微观，至少是到“三级流程”的业务流程说明、管控权责设计、数据要求、管理变革分析等等。

我问对方：ERP这类系统基本采用实施套装软件，这些软件本身具有其应用逻辑（亦即所谓的“最佳业务实践”），你们连软件选型方案都没定，做这种 三级流程详细设计 的意义是什么？

对方回答，宏观的“规划”太虚了，我们要能落地的方案。搞这么细，目标是能指导系统方案的落地。只要能把未来业务流程讲清楚，不管是用什么品牌的套装软件，或者是自行开发，直接拿着这些业务流程文档，交给实施公司或者软件开发人员来开发或者配置就好了。

我的疑问是：那这样梳理出来的这些详细流程文档，究竟是描述的业务现状 （AS-IS） ，还是未来 （To-Be） ？

如果只是“现状流程”，那就是把业务现状放进系统里去，显然不符合用IT系统来提升管理的要求。

如果是“未来流程”（To-Be），我很难想象，脱离软件参考业务模型，光去分析业务部门的“需求”或者凭着顾问拍脑袋，就能做出管理提升的未来流程？

打个比方，在仓库进行采购收货的业务场景中，是否允许对供应商订单超交的部分进行收货？在ERP系统里，这是个流程控制点，可以允许采购订单超收，也可以不允许订单超收，体现了“计划-采购-库存-应付帐款结算”等各个业务环节的端到端流程集成的思想。然而，没有套装软件的参考流程，亦即所谓的“最佳实践”作为指引，你在流程梳理中，不从部门协作的角度出发，怎么可能出从业务人员需求描述的角度识别这个管理问题？

参考阅读：

不在一个频道上 | “流程”和“场景”有什么区别？

从业务流程到知识管理到自动化 | 走出业务流程的丛林

【总裁必读】上SAP系统前不读此文要后悔（中 ）

所以，从白纸上开始画流程框架及流程，再结合跟业务部门去“访谈需求”，不落到具体系统里去讨论流程，我认为做出来的流程是模棱两可的，介于As-is和真正的To-be之间，姑且叫“ could-be ”流程。“业务流程”其实只是展示业务的形式， could-be流程可以用来展示和分析企业业务的局部问题；如果让系统实施方来接手这样的业务流程文档，无法直接用来做开发和配置。

业务流程不是一个专业，只是一个方法；就像你Word用得再好，打字再流利，也不能证明你是作家，极端点说，我认为”业务流程咨询”是个伪命题，流程分析最终还是要落到业务的系统实现方案本身。

“业务流程详细设计”是ERP类信息系统实施方案的一部分，是不可能脱离软件存在的，它和软件的关系，是鸡和蛋的关系。绝不是先有详细流程，后有可运行的系统。业务流程的最佳业务实践也是管理类套装软件所提供的价值。

需要说明的是，“详细业务流程”也并不等于软件系统内含的流程，软件开发的“流程”是用来解释软件本身的任务和功能，一般包括如下内容：