华为流程架构实践：企业流程体系的分类、分层与衔接，附168页华为案例-EA之家

附件为华为168页可编辑PPTX文件。

华为流程架构最值得看的，不是流程多，也不是文件全，而是它把企业流程体系里最难处理的几个问题，做成了一套能够长期运行的东西。很多企业也在做流程，结果往往是流程图越来越多，文件越来越厚，协调会议越来越频繁，真正的经营效率却没有明显改善。问题不在于企业没有流程，而在于没有把流程真正组织成体系。

流程架构要解决的，恰恰不是“有没有流程”这个问题，而是企业能不能把自己的经营活动，变成一套清楚、稳定、可复制、可持续优化的运行方式。说得更直白一点，流程架构不是为了把流程画出来，而是为了把企业怎么把事做成，完整地讲清楚。

真正把这件事讲清楚，要抓住三个关键词：分类、分层、衔接。分类，是先把企业在管什么事分清楚；分层，是把这些事展开到不同管理层级；衔接，则是把这些事从头到尾真正连起来。流程架构一旦离开这三件事，就很容易变成流程图的堆积，或者制度文件的整理，最后既看不出主次，也支撑不了经营。

一、流程架构先要解决的，是企业到底在管哪些事

很多企业一做流程梳理，习惯按部门去分。销售有销售流程，采购有采购流程，财务有财务流程，研发有研发流程，看起来很完整，实际上还是部门视角。这种分法只能说明“谁在做事”，却说明不了“企业是怎么把事做成的”。

流程架构的第一步，不是列部门，也不是列职责，而是把企业经营活动按性质分出来。因为部门是组织单元，流程是经营单元；部门解决的是管理边界，流程解决的是价值如何形成。两者有关，但不能混用。企业一旦把流程分类做成部门目录，后面再怎么细化，也很难真正拉出主线。

从经营运行的角度看，企业流程大体都可以分成三类。

第一类，是直接创造客户价值、直接形成经营结果的流程。比如市场、销售、研发、交付、服务。这些流程决定企业怎么获取需求、怎么形成方案、怎么完成交易、怎么把产品或服务交到客户手里。它们是企业最核心的主业务流程。

第二类，是围绕主业务流程提供支撑和保障的流程。比如供应、采购、渠道、质量、平台、数据、运营支撑。这些流程不一定直接面对客户，但直接影响主业务能不能跑顺、跑快、跑稳。没有这一类流程，主业务流程就会变成单点冲刺，无法稳定复制。

第三类，是构成企业经营底盘的基础管理流程。比如人力、财经、法务、IT、风控、行政。这些流程不直接创造收入，但它们决定企业能不能在规模扩大之后仍然可控，能不能把增长变成有质量的增长。

流程分类做到这里，企业才算第一次把自己的事分清。因为分类不是简单整理，而是在回答三个根本问题：什么是主线，什么是支撑，什么是底盘；什么该优先打通，什么该重点保障，什么该长期建设；哪些流程决定客户感知，哪些流程决定经营效率，哪些流程决定组织可持续。

很多流程体系之所以后面越做越散，根子就在这里。前面分类没有立住，后面分层再细，责任再多，最后也只是把混乱描述得更精细而已。

二、流程架构不是一张总图，而是一套分层表达

企业把事情分清之后，接着就会碰到第二个问题：这些事情要展开到什么程度。这个问题，就是分层。

很多企业流程工作做不下去，并不是因为没有内容，而是因为层次没有拉开。有的内容停留在原则口号层面，讲的是“加强协同、以客户为中心、提升效率”；有的内容却已经细到岗位动作、表单字段、审批路径。前者太虚，后者太碎，放在同一套体系里，彼此根本接不上。管理层看不出重点，执行层也用不上，流程架构自然就失去了作用。

所以，流程分层不是为了把文件做厚，而是为了让不同层级的人看到不同层级的问题。

最上面一层，讲的是企业流程版图。哪些是价值创造流程，哪些是支撑保障流程，哪些是基础管理流程，企业的经营活动总体是怎样分布的。这一层是给管理层看的，解决的是流程体系的总体布局问题。

往下一层，要能看到流程域和流程组。也就是说，在某一个业务领域里，到底由哪些关键流程共同构成。这一层是给业务负责人看的，解决的是一个业务板块如何系统管理的问题。

再往下，才进入具体流程、子流程、活动和任务。到了这一层，流程才真正开始进入执行：每一步由谁做，输入是什么，输出是什么，什么时候交接，满足什么条件才能往下走，哪些节点必须控制，哪些节点可以授权处理，哪些例外情况需要升级。

分层的价值，就在于把原来混在一起的内容拉开。高层看的是主线、重点和全貌；中层看的是接口、责任和关键节点；基层看的是动作、标准和交付要求。层次一旦拉开，流程体系才真正能够兼顾管理和执行。否则，流程文件再多，也只是资料；流程图再细，也只是局部说明。

更重要的是，分层建立的不是形式，而是共同语言。没有统一的分层标准，企业内部对“流程”这个词的理解就会不断漂移。有人说的是大流程，有人说的是子流程，有人说的是操作步骤，最后大家都在谈流程，却谈的不是一件事。这种情况下，流程架构不可能真正成立。

三、流程架构真正见水平的地方，在于把主线拉出来

分类解决“有哪些流程”，分层解决“这些流程展开到什么程度”，但流程架构最见水平的地方，其实在于能不能把主线拉出来。

很多企业流程并不少，问题也不是没有流程，而是没有主线。每个部门都有自己的流程，单看都说得过去，合在一起却总是接不上。因为部门流程解决的是“我这一段怎么干”，流程架构要解决的，却是“这件事从头到尾怎么成”。

这两者有本质区别。

比如客户需求进来之后，谁先识别，谁来判断价值，谁把需求转成方案，谁组织研发或交付，谁负责验收，谁推动回款，谁处理问题和例外。这不是某一个部门能独立讲清楚的，而是一条跨部门、跨角色、跨系统的完整主线。只有把这条主线拉出来，企业才第一次真正看到，一件事到底是怎么从头走到尾的。

流程一旦缺少主线，就会变成一段一段拼出来的局部动作。每一段都可能没错，但连在一起就出问题。前面觉得自己已经完成了，后面却接不住；资料已经提交了，但标准不一致；节点已经到了，但责任没有收口；每个部门都说自己完成了职责，最后客户看到的却是慢、乱、推、拖。

所以，流程架构最核心的价值，不是把流程列全，而是把最关键的那几条经营主线从部门边界里拉出来，变成整个企业共同面对、共同维护、共同优化的管理对象。

主线一旦立住，企业对流程的理解就会发生变化。流程不再只是部门动作，而变成经营活动的完整链条；流程管理也不再只是规范动作，而变成管理结果、管理协同、管理交付。

四、衔接不是画几个接口，而是把边界、责任和规则讲清楚

流程架构做到这里，真正难的部分才刚刚开始。因为主线拉出来之后，马上就会遇到一个更现实的问题：这条线上的各个环节怎么接。

企业里大量的低效、返工、扯皮、推诿，本质上都不是单点问题，而是衔接问题。问题很少出在“某个动作完全没人做”，更多出在“前后接不上”。前面说自己已经交付，后面说条件还不具备；一个部门按自己的标准做完，另一个部门却按另一套标准接收；事情出问题时，参与者很多，但没有人对最后结果真正兜底。

这说明，流程架构里的衔接，从来不只是接口列表，而是三个层面的统一。

第一个，是边界要清。流程从哪里开始，到哪里结束；这一段该谁管，下一段何时接手；什么结果算这一阶段真正完成，什么状态才允许进入下一阶段。边界不清，流程就会层层加码，或者层层外推。

第二个，是责任要清。谁是牵头人，谁是配合方，谁在关键节点上把关，谁对最终结果负责，谁来处理例外和冲突。流程架构不能只是把动作写下来，更重要的是把结果责任收拢起来。否则就会出现一种很常见的局面：动作有人做，结果却没人扛。

第三个，是规则要清。什么条件算合格，什么信息必须齐备，什么环节可以灵活处理，什么环节必须严格控制，出现例外时谁有权判断。企业运行中最难管的，往往不是人人看得见的动作，而是那些长期靠经验、靠默契、靠老员工带出来的“默认规则”。流程架构往深处做，做的正是这件事：把过去那些说不清、靠人脑补的地方，变成组织层面的共同标准。

所以，衔接不是附属问题，而是流程架构的核心问题。流程和流程怎么接，节点和节点怎么交，规则和规则怎么统一，例外情况怎么处理，跨部门分歧如何裁决，这些内容讲不清，流程架构就只是一个好看的框架，不能成为真正的经营基础。