迈克尔·哈默在他的《超越再造》书的开始，就提出了一个重要观点：“公司走向以流程为中心并不创造或发明他们的流程。因为流程本来就在那里，只是没有受到相应的尊重和了解。”

    可见，流程本身是业务运作的载体。企业为了提升管理，引入了各种管理理念，建立了各种管理体系，而最终各管理体系的要求要落实在一套业务流程中。通过流程实现对各管理体系的集成，从而形成一套统一的对实际业务运作的描述和指导。流程管理最朴素的原理：“让具体干活的人知道怎么干活”。

    企业要形成一套和业务紧密结合、对业务能起到明确指导作用的业务流程，就不能“拍脑袋就来”，有以下三方面的注意事项：

    第一， 要用现场版一步步的流程来暴露问题，不要抽象、美化流程。

    曾经有家企业画了一个物流入库流程，描述成这样“申购-审批-下单-到货-验收-入库”，来交流他的困惑，“怎么从这个流程中找到问题、分析优化、提升解决，指导业务呢”？

    我们的回答是：流程描述到这个颗粒度，是发现不了问题的。这个流程太标准和典型了，而我们要的是现场的实际发生的情况：申购是否电脑上误操作了3次，审批是否排队等了2天，反复找领导4次，下单是否和供应商纠缠2回，到货时候的在场人是否缺位，验收的时候是否敷衍结果埋下隐患，入库以后是否从台帐到电脑上的信息反映延迟了3天。

    也就是说，为了让流程描述贴近业务，就要带着笔和纸、照相机、录像机，到现场去，一个动作一个动作去跟，那个采购计划员一天8小时是怎么消耗的、结果又加班4个小时是为了什么，那个采购经理画的10个圈都画在什么单据上、为什么要画，这样才可能去发现问题、分析问题、解决问题，从而达到业务改进。我们要的“现场实录”版本的流程描述，而不是几个管理参谋人员在办公室里逻辑想像出来的、抽象美化过的简洁流程。

    第二，不要流水帐流程，通过流程多一些维度和属性信息，集成各管理体系的要求。

    流水账流程图只描述业务的流水账流转和主体的跟随标注情况，好的流程图应该是一种“跨职能的垂直活动流转图”，它不仅描述流程的流转过程，而且能让人一目了然地看出这个流程涉及哪些部门/岗位、这个部门/岗位在这个流程里一共做了哪些活动、流程的协调统筹部门、明确了流程的节点责任人、流程的执行要点等。

[page]    在流程的每一节点，我们还可以附加以下属性信息：

    1）ISO9000或者内控等管理体系的要求：将各管理体系的要求作为属性标签，添加到流程的具体活动节点上。

    2）时间要求：如流程活动中“采购申请提交”的执行时间应该在每月5号，某个环节的审核时间要求在1天内等，通过时间要素的明确使流程的运作形成固定节拍。

    第三，跳出流程来认识流程、“见木也见林”。

    如果“只见木不见林”，一头扎进一个具体流程去描述，不能从整体上来认识流程的话，往往会导致三个方面的问题：

    1. 业务活动的切分不清晰，不知道哪些工作应该归入哪个流程，可能就会在流程描述的时候造成冗余或遗漏，不是两个流程彼此有重复的部分，就是两个流程都遗漏了一段；

    2.各人对业务颗粒度的理解不一致、流程描述口径不一致，有的流程描述地特别宏观粗放，把业务的颗粒度做的很大，有的流程则抠的特别细、甚至细化到岗位内部执行的逐个动作；

    3.流程之间的关系不清晰，只注意了本流程的内部，难以把握流程的上家（内外部供应商）和下家（内外部客户）。

    因此，流程不是对VISIO符号的简单引用，也不是对流程的很多底层细节进行100%的机械描摹，一套清楚描述的流程文件应有以下作用：

    1.体现和落实企业战略的要求，明晰核心业务；

    2.展现出每个流程上的跨部门、跨岗位的协同全貌和工作走向；

    3.集成各管理体系要求和最佳实践，落实到具体的流程活动，为企业所有业务人员提供一套统一的工作指引；

    4.帮助建立流程导向的组织架构，和人力资源部门维护的“部门职责”“岗位职责”能够对应起来。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。