终于有人把流程讲清楚了！

近些年，随着业务的成功，华为的管理体系也备受推崇，成为各行各业学习的对象，特别是 IPD

（Integrated Product Development，产品集成开发）流程，但凡有产品的公司都想学。其实IPD并不是华

为首创的，也不是华为独创的，只是因为华为的产品获得了较大的成功，所以IPD也跟着功成名就。

IPD的思想来源于美国PRTM咨询公司出版的《培思的力量》，该书详细描述了如何通过改善产品项目管理的四个要素：阶段评审流程、核心小组、结构化开发流程、开发工具和技术提高研发效率，缩短产品上市的周期，提升产品在市场上的成功概率。

将IPD付诸实践并重新获得成功的公司首先是IBM公司，1992年IBM在激烈的市场竞争下，遭遇到了严重的财政困难，公司销售收入停止增长，利润急剧下降。经过分析，IBM发现他们在研发费用、研发损失费用和产品上市时间等几个方面远远落后于业界最佳。为了重新获得市场竞争优势，IBM提出了将产品上市时间压缩一半，在不影响产品开发结果的情况下，将研发费用减少一半的目标。为了达到这个目标，IBM公司应用了IPD的方法，从流程重整和产品重整两个方面来达到缩短产品上市时间、提高产品利润、有效地进行产品开发、为顾客和股东提供更大价值的目标。

IPD在IBM这个巨人身上的实践成果让任正非怦然心动，华为斥巨资请来了IBM的专家顾问团，并在公司内部结集了优势兵力，用“照葫芦画瓢”的强硬方式推行 IPD。任正非说：“先僵化，再固化、再优化。”这句话听起来容易，实际执行则非常困难，特别是僵化的初期，思想、行动都要转变，还需要来自不同的部门的团队共同磨合，所以对业务还是会产生影响，也难免会有各种反对的声音。这个时间段非常需要管理层的坚定。有一段时间，任正非说：“不换思想就换人。”靠着任正非的坚定与坚持，以及一大批种子选手的培养，IPD逐渐在华为生根了。

僵化的目的是自我认知，优化是自我修正的过程，固化则是夯实已有成功。任何企业都有自己的基因，必须找到适合自己的道路。没有什么流程是可以生搬硬套的，也没有流程能够一劳永逸地用一辈子。之所以IPD现在跟华为紧密相连，跟华为这二十来年持续不断地优化IPD有非常大的关系。

华为自1999年启动IPD变革，到2005年才逐步走向成熟，一直到今天，都在持续变革和优化。

（1）华为将 IPD与 MM（市场管理）、OR（需求管理）对接，实现了 IPD端到端流程的衔接。解决了需求驱动不够、客户需求响应不够的问题；将客户需求信息直通到产品开发人员手中，实现需求驱动产品开发。此优化改进，让华为10万人规模开发团队与中小企业开发团队一样轻盈，快速、低成本地满足客户需求。

（2）研发在产品开发过程中占了很大的比重，而研发又分了很多领域，系统、硬件、软件、结构、测试等，为了更好地支撑 IPD，系统地梳理了研发领域的各个流程。同时，华为针对软件研发业务工作量大且相对独立特点，对 IPD流程进行软件开发适配，推出集成 IPD-CMMI流程。2007—2010年，华为继续在各产品线试点敏捷开发方法；吸收敏捷方法在软件开发中优点，考虑电信嵌入式系统庞大而

又复杂的差异；形成适合华为的IPD+敏捷开发流程，将软件从重型过程管理转向轻量过程管理。

（3）华为针对电信市场整体解决方案特点，创造性全新地提出“IPD解决方案流程”，提出解决方案IPD开发模型，为客户提供产品、服务、全球培训、客户支持解决方案。IBM-IPD流程体系解决的是如何开发一个盈利的产品，而“IPD解决方案流程”提出让华为从卖产品的公司迈向卖解决方案与服务的公司，推动华为进入一个更大市场范围，让华为销售稳步迈向2000亿以上台阶。

（4）随着业务范围的拓展，华为又不断推出新的 IPD，如适用于云的、适用于芯片开发的、适用于汽车相关产品的……业务在发展，流程也在发展。二十多年来，华为并没有一直僵化地使用 IBM-IPD，而是在掌握IPD精髓之后，投入大量的人力物力优化IPD流程，让流程运行得更具可操作性且有效率，成为华为不断发展的助推器，所以华为的产品成功了，华为的IPD也成功了。

引用哈默的话：流程是一套完整的贯彻始终的共同为顾客创造价值的活动。把这句话延伸下：一系列可重复、有逻辑顺序的活动，将一个或多个输入转化成明确的、可衡量的、创造客户价值的输出。我觉得可以理解为有层次的、详细的业务书面化表达，如图：

从定义上可以看出，流程是对业务的描述，但这不代表任意业务的执行方式都能成为流程。更准确地讲，流程是业务最佳实践的描述。也就是说，我们要从业务的各种操作方法中找到最佳方法，并用流程描述出来，以便所有的业务人员都能按照同样的方式执行流程，从而保持业务完成的一致性、稳定性，提高成功概率。

流程和我们常说的制度有什么区别呢？

制度一般指要求大家共同遵守的办事规程或行动准则，也指在一定历史条件下形成的法令、礼俗等规范或一定的规则。在不同行业不同部门的不同岗位都有其具体的做事准则，目的都是使各项工作按计划按要求达到预计目标。

制度和流程都可以理解为规则、规范，要求员工在工作中按照规则执行，但两者的表达形式、运用却存在一定的差异。

还有一个更重要的区别：流程有框架，有架构，能够帮助我们理顺整个公司的价值链，这是流程非常重要的一个作用。所以，我们建议简单明了的要求用制度，比如考勤规定；复杂的业务用流程，比如IPD，就是产品开发流程的合集，形成了一个流程体系。实际上，越来越多的企业都开始采用流程的方式来管理业务。

流程就是我们用的电子流吗？

这个说法不准确。随着信息化的推进，很多企业都用上了各种办公系统，也会在系统中走各种各样的电子流。但电子流是否就是流程呢？这还是要回到流程的本质去看，看电子流到底承载了多少内容，有可能是整体业务流程都实现了信息化，那么走一条电子流就等于走完了一个业务流程。但现实中更多的情况是，电子流只是整个业务流程的很小一部分内容，多见于审批、评审、发布等环节，这个时候，就千万不要把电子流等同于流程了。

表中也列出了一些常见的其他指导类文件，需要和流程做区分。

流程管理怎么管？其实就是如何保证流程能实现价值。回应上面一小节提到的三个点，流程管理就是从三方面下手，一方面是提升流程本身的质量；另一方面是管理好流程落地过程中的各种因素，确保流程能够执行落地；最后一方面是建立健全的流程管理机制，确保流程能够持续改善。

提升流程质量，本质上是提升流程设计的质量，按照好的流程标准设计好出流程。如何设计出好的流程？我认为主要从两方面着手：深入理解业务；掌握流程设计的方法、工具。流程是业务的表达，核心是业务逻辑，所以要设计出好的流程，就是要把业务的最佳实践提炼出来。比如产品开发流程，就是将产品开发的最优路径提取出来，形成一组有序、可重复的活动，给做同样工作的人提供共同语言，提供最佳路径，提供指导，降低犯错概率。所以不深入了解业务的人设计出来的流程一定不是好流程。

这里介绍两个小方法给大家，一个是《流程功能展开表》，如图所示。在流程设计的时候可以用这个表，让项目组的成员先把流程按照活动维度梳理一遍，在这个基础上再做研讨和优化，会大大提升速度.

还有进行一个方法叫项目映射，也就是把目前的业务开展方式用流程图的方式呈现出来，再通过与业界最佳实践进行对比，找出问题、差距，进一步找出改善的方向。

除了提升流程设计的质量外，我们也要用一些好的方法和工具来帮助我们管理流程设计的过程。

一个全新的流程设计或预估有比较大变动的流程优化，我们可以用类似产品开发流程来管理流程开发的过程，把流程优化当作一个项目来管理。一些小的流程优化可以用 CR（Change Request）的方式做流程优化的评审。这两种管理方式涉及的治理结构和组织，后面会单独分享，现在先看看这两种方式的管理过程。

先来看流程优化项目的管理，如图所示。这也是一个结构化的管理流程，分为Charter开发、方案设计、详细设计、验证/试点、发布/推行五个大阶段，有4个DCP点。从结构上看和IPD类似，但整个过程的复杂度远低于产品开发，所以看到这里不要被这个流程给吓住了。Charter开发阶段的主要任务是分析业务现状，识别关键需求、关键干系人及确定项目关键人力资源。因此项目任务书的主要内容就是描述项目的背景（业务现状与问题）、关键的优化需求、可行性分析、项目范围及所需资源、关键交付件及关键的利益干系人、项目里程碑。

方案设计阶段，首先是组建项目组并确定项目计划，在这个阶段，项目组的主要任务是分析并完善项目需求，完成流程优化方案及验证的策略；详细设计阶段的主要任务是根据流程优化方案进行详细设计，完成所有交付件（流程图、模板、指导书、检查单、流程培训材料等），选择试点项目进行试点准备；验证和试点阶段的任务是引导试点，并解决试点中发现的问题，优化交付件内容，最后要进行试点总结并做推行准备；发布/推行阶段的主要任务是全面推行，并且解决推行过程中遇到的问题，如有必要，需要再次优化交付件内容，最后进行推行总结，进行结项汇报。

这样的管理流程设计过程有两个好处，一个是流程的优化方案得到充分评审，包括试点阶段，都能查漏补缺；另一个好处是团队作战，能够弥补个人能力不足，团队成员里有熟悉业务的成员，也有熟悉流程设计方法的人员，配合得当的话，流程设计的速度会大大提高。

流程建设的难点并不只是在流程设计上，流程推行的强度和力度在很大程度上才是决定流程是否能真正运行的重要因素。流程推行的过程，并不是随意为之，也有一些关键的动作，换句话说，流程行也有流程，如图所示

成立推行小组：无论做什么事，一定要先有人，流程推行也不例外，所以首先要成立推行小组。推行组组长一般由流程owner指定的代表担任，小组成员则由涉及的部门领导指定成员担任。在华为，推行组的成员一般来源于三个方面：流程部门的流程管理工程师，各产品线质量部质量工程师，各产品线业务部门的业务代表。三者角色不同，看待流程的角度不同，更能全方位客观地去评价流程及推行过程中遇到的问题。制订推行计划：制订推行计划这个过程至关重要，除了要确定推行的整体时间计划（包括后续跟各级领导的汇报沟通时间）、试点项目、推行的范围等以外，这个阶段最重要的工作是要为推行准备好所有的材料。这些材料包括培训材料、汇报材料、FAQ、流程变更清单、流程适配表等。从流程活动的划分上来说，应该增加一个活动，可称为推行准备。

培训：无论是试点还是推行以前，都必须对相关人员进行培训。培训包括整个流程的讲解，流程中重点和难点的说明。培训的时候多给一些场景化的案例，帮助业务人员理解。

试点：无论是新鲜出炉的新流程，还是优化后的流程，我们都建议先试点，再推行。试点项目往往会选择有代表性的项目进行，更能找出问题。试点分为两种方式，走读和试行。走读就是让业务人员通读一遍流程，假设各种场景，看看流程是否能跑通，会不会有什么问题。试行则是直接按照流程来跑业务。选择哪种方式，要根据流程的不同类别、试行项目是否容易选取、试行可能带来的问题等因素综合考虑。

流程优化：试点的过程中，必然会遇到各种问题，有的是流程设计上的缺陷，有的是试点项目对流程的理解不到位，这些问题都需要推行小组组织讨论，该优化流程的地方就要优化流程，该在培训中加强讲解的地方就要在培训材料中加强。总体来说，这是一个反复讨论、反复修改、反复试点的过程。

推行发文：公司的正式发文，××流程发布了，要在××范围内推行。这一步的作用就是昭告天下，同时将流程文件正式纳入流程文件体系。

适配（这条特别针对研发流程等灵活性较大的流程，标准化流程不在此列）：对于灵活性比较大的流程，适配是确定流程是否能顺利推行的关键环节。比如研发流程，一般是基于典型业务场景的标准化动作，而我们的研发项目确实千差万别。所以在推行流程之前，我们一定要进行适配，看看项目的特点是什么，流程中哪些活动是必须做的，哪些活动对于这个项目来说是不需要的，一定要量体裁衣，才能把流程推得好。

推行：在流程适用的范围内，全面推行，这个不用多讲。

流程执行审核：在制订流程推行计划的时候，就要确定流程执行检查的时间点。一般会在流程发布后的三个月或半年进行检查（检查的时间和频次根据流程的不同会有所不同）。检查的方式一般是访谈结合查看证据同时进行。流程的执行检查，一般是抽查，不会检查所有的项目（根据公司的规模、流程推行的范围灵活确定），但检查哪个项目，什么时间检查，不会提前太多公布。审查也是为了改进，所以一定要公布流程的审查情况，哪些项目做得好，哪些项目做得不好，什么原因，都会在审查报告里得到体现。至于流程执行情况的奖惩制度，可以根据公司的具体情况进行设置。

流程推行的理论知识基本上就讲到这里了，我们再看看知识外的关键因素，有且仅有一个：管理层特别是大领导对流程的重视程度。同样的推行方法，同样的流程，不同的领导重视程度就会出来不同的效果。

流程管理三板斧的最后一板斧是管理流程的流程，也就是说，如果把流程作为一个职能，那这个职能本身该如何管理？职能管理的逻辑其实都是类似的，简单来讲，首先根据公司战略规划职能战略，做年度计划，然后按照计划执行，同时做好过程的监控与管理，最后要进行绩效评估。

最后提一点，流程管理的工作要想做得好，确实需要投入大量的人力物力来做保障工作，所以流程组织必不可少，要做到以下几点。

l 有专门的部门，退一万步讲，有专门的职位做流程管理的工作。这个部门的职责：（1）看护企业的流程架构；（2）建设流程管理能力；（3）组织各领域流程的梳理工作。

把流程管理的职责落实到各业务领域一把手的头上。流程建设只能是自上而下的工作，自下而上是无法开展的。那如何自上而下？从领导的职责、重点工作入手。流程推行落地的第一责任人必须是部门一把手，所以必须把这点强化到部门职责里。要形成公司+领域的多层推行组织，要有独立的团队对流程的执行做审查。

最后我们看看两个案例，体会流程管理的成败因素。一个是标杆企业的研发流程管理，一个是流程优化项目以失败告终的案例。

案例一：以版本管理的方式来管理流程提到流程的版本管理，可能很多人都会讲，我们的流程文件也有版本，修订记录也记得很详细，流程文件也都是经过了评审才发布的……但我想跟大家讲的是整个流程体系的版本管理，我们先通过华为研发流程版本管理的案例，让大家感受下什么是流程的版本管理。研发流程作为IPD流程的重要组成部分，每年都要发布一个版本，以保证流程的先进性与实用性。

研发流程版本的生命周期大致分为图中的5个部分。

具体讲每个阶段之前，我们先介绍下研发流程管理体系的治理架构，这里有两个虚拟组织对研发流程负责，一个是研发流程改进委员会，主要负责研发流程版本及研发流程变革项目的全生命周期的审核和批准，研发流程改进委员会由各产品线研发部部长、研发流程部部长、研发流程部5级专家组成。另一个是研发流程CCB（控制变更委员会），主要负责对研发流程CR进行评审。CCB由研发流程部部长、研发流程部5级专家、各产品线研发质量部部长组成。

版本规划：一般在每年的 11月、12月进行，由研发流程部部长和 5级流程专家主导，研发流程各个领域的负责人参与。规划主要是根据目前业务的需求、流程的现状来规划研发流程变革项目，还有一些研发流程领域的探索性业务。举个例子，在某一年做规划的时候，大家对研发外包管理做了探讨：（1）研发外包是目前普遍的业务现状，特别是软件外包，频率非常高；（2）公司有了一些外包的管理要求，主要是对供应商的选择，法律条款方面的内容进行了约束，但是缺少针对研发外包项目的项目管理的内容。这样一来，方向就有了，成立一个研发外包管理的流程变革项目，对业务进行梳理，并发布相应的流程。

另外一个例子，随着开源软件成熟度的提高，以及企业本身降低研发成本的需求，将会有越来越多的项目用到开源软件，那么企业应该如何参与到开源社区的建设，如何规范开源软件的使用过程，规避风险？这些都是需要探讨的内容，所以在某一次的规划会议中，研发流程部也将开源软件的使用作为了一个研究方向，由流程专家与业务专家一起，成立项目做相关的研究。

在做流程项目规划的时候，要考虑项目的范围和难易程度，项目是一期就能完成还是需要分期完成，项目由哪个产品线牵头比较合适，这些都是做规划的时候需要考虑的内容。

研发流程版本规划需得到研发流程改进委员会的批准。

版本实施与监控：研发流程版本主要由两大部分组成，除了规划的流程变革项目以外，另一类主要来源是变更申请（Change Request），以下简称 CR，所以研发流程版本的实施与监控，实际上就是各个研发流程变革项目和CR的实施与监控。

研发流程变革项目的管理方式与前面讲的流程设计过程项目管理过程类似，不再复述，只强调标杆的几个关键点。

立项：变革项目不仅涉及资源的投入，而且它的项目过程、项目结果很有可能带来业务规则的变化、组织的调整，影响的范围也特别广，所以变革项目的立项过程更应谨慎和严谨。

研发流程变革项目成员一般会由流程专家和产品线业务、质量人员组成。流程专家会把握整个流程项目的进度节点，协调各产品线的意见，从流程的角度给出建议及流程文件的修改意见。产品线的业务人员和 QA根据业务的现状和趋势，对于流程现状提出更改建议。最终项目组输出项目材料及流程CR在获得研发流程改进委员会和CCB的同意后，项目成果会跟随研发流程版本发布。

华为的变革项目也不是一帆风顺的，也有几个困难的地方：不是所有产品线都重视流程，所以参与项目的人员的能力和责任性参差不齐；各产品线产品形态各异，要在中间找到平衡点，发布公司级的流程，是一个权衡和拉锯的过程；寻找合适的试点项目。华为的项目进度是出名的紧张，在大家都恨不得一天当作两天用的时候，能找到项目愿意在忙碌中试点新的流程，也不是容易的事。所以也要依托变更项目的推进，在研发流程改进委员会层面来解决这些问题。

再看CR的管理，CR的来源主要有这几部分：日常CR，研发流程变革项目CR，其他领域变革项目CR。

日常CR：华为公司的任何员工发现流程文件中有问题的地方，或与业务不相符的地方，都可以提交CR申请，提交改进建议。

研发流程变革项目CR：流程变革项目可能会发布新的流程，同时也有可能对现有流程有一些改进的地方，涉及现有流程修改的具体内容，都需要提交CR申请。其他流程变革项目 CR：非研发领域的流程项目，但涉及研发流程配套修改的内容，也需要提交CR申请。

每年研发领域的CR数量大概有 50条左右，涉及更改的流程文件的上百份（包括流程图、模板、指导书、Checklist等），所以CR的管理是非常重要的。在华为，我们通过研发流程CCB的运作对研发流程领域所有的 CR 进行管理。CCB 有固定的运作秘书，一般由研发流程部的流程管理工程师担任。

运作秘书一般会在前一年的12月制定会议日历，将第二年全年的会议日期确定下来（一般是每月一次，一次半天），然后按照月度会议时间召集会议。

CR的管理过程：CR的发起者通过CR电子流提交材料，材料中说明CR的原因、涉及的流程文件、与相关人的沟通记录等。运作秘书收到电子流以后，会对材料进行初审，初审通过后与相关流程的责任人进行沟通，然后安排议题，组织评审会议。通过 CCB会议评审的 CR,由运作秘书记录在 CR清单中，在流程版本发布前，集中更改涉及的流程文件，随版本发布。CR管理流程如图所示。

研发流程版本发布：每年的7月、8月是研发流程版本发布的时间。在正式发布之前的一个月左右，是集中修改流程文件的时候。文档需要审批上传，流程图、活动图都要根据 CR 清单实施修改。

等到所有变更都修改完毕后，研发流程部部长会汇集变更中的要点，到研发流程改进委员会和研发部部长会议上进行汇报，经过中央研发部部长同意后，研发流程正式发布。