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

用微信扫码二维码

分享至好友和朋友圈

来源：节选自《硬件十万个为什么（开发流程篇）》，北京大学出版社授权发布

01

IPD在华为为什么能成功？

近些年，随着业务的成功，华为的管理体系也备受推崇，成为各行各业学习的对象，特别是 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也成功了。

02

流程到底是什么？

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

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

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

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

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

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

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

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

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

03

流程管理怎么管？

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

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

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

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

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

一个全新的流程设计或预估有比较大变动的流程优化，我们可以用类似产品开发流程来管理流程开发的过程，把流程优化当作一个项目来管理。一些小的流程优化可以用 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 清单实施修改。

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

如果有流程变革项目进度拖延了，没有赶上流程版本发布的节奏，就只能等到下一年。除非非常紧急的情况下，研发流程才会增发版本。

研发流程推行：我认为研发流程的推行是非常重要的环节，也是整个流程管理中比较难的一个环节。流程变革项目在运作的过程中虽然有试点项目，但试点项目毕竟是少数几个项目，不可能覆盖公司所有的项目类型，而推行却是在整个公司的推行。在流程版本发布以后，与产品线接口的流程管理专家会到产品线IPMT，研发管理会议上汇报流程版本的重要变更点，以取得产品线领导的支持。同时，流程管理专家和产品线流程负责人会根据CR清单，逐条对变更进行适配。适配中最重要的两个文件，一个是流程活动，另一个是交付件模板，这两个是关系到流程是否能够正确执行、产品交付是否合格最重要的内容。如果某个变更对某个产品来说确实不需要推行或部分推行，都得在适配的时候提出来，并且给出适配的具体方案。个人认为适配是推行环节中非常重要的一个前奏环节，适配做得好不好，关系到流程推行的难易程度，同时，适配也是对流程管理专家和产品线流程负责人一个非常重大的考验。必须对流程的变更和产品线产品非常熟悉，才能做出正确的适配。如果流程的推行过程，被认为一定是自上而下的，或研发人员认为流程的变更对于业务没有帮助还必须推行，那我认为，这是推行的前期适配工作没有做好。适配也分层级：首先是产品线一级的适配，然后是SPDT，PDT的适配，最后是产品项目的适配。在产品项目的质量策划中，就得明确相关的流程活动及交付件，这也为后续流程的验收打下基础。

流程验收：流程验收是在第二年的5月份左右，验收的过程用图说明

研发流程的变更会涉及产品的整个开发过程，所以验收的项目尽量选择进展时间长的，可以验收到更多的变更点。验收项目的多少也要根据产品线和验收清单的覆盖点来确定。一般情况下一个产

品线差不多验收4、5个项目。如果整体验收结果出来后，发现有一些变更点都没有验收到，可以再补抽查。

交付件的审查主要看新模板的使用情况及交付件的归档，密集是否符合要求。目前对于有特殊市场要求的产品，会审查得更严格一些。

验收会议主要是对项目成员的访谈，包括项目经理、QA、研发人员、配置经理等各领域角色。验收会议的目的主要是对项目过程的规范性和流程遵从性做一个调查和了解，同时对流程变革的内容做一个了解，变革内容是否合适，产品在执行的过程中有没有遇到什么问题和困难，对于流程还有哪些建议，这些都是对流程改进的一个很好的输入。所以，如果你是产品线的研发人员，如果你的项目正在被验收，不要拒绝也不要应付了事，这是一个很好的机会，让流程能离你们更近。

验收报告也分几层：单个项目的验收报告，产品线的验收报告，以及整个研发流程的验收报告。

整个研发流程的验收报告需要在研发流程改进委员会汇报，各个产品线的验收情况会拉通，所以哪个产品线对流程的执行度是什么情况就一目了然了。

研发流程版本管理的过程大致就介绍到此了，大家是否有领悟到把一个领域的流程整体进行版本管理的好处？总结如下。

从全局出发进行统筹规划，有利于抓重点，集中优势兵力攻克最重要的内容；也有利于理清项目之间的关联性，避免为了做项目而做项目的情况。

版本中的项目管理：对项目质量把关，也对项目进度进行管控，把握了版本的整体节奏。统一发布，集中推行，集中验收，有利于业务一线全面了解流程的变更点，更利于流程的推行和验收。

案例二：永远有多远？就像as-is 和 to-be的距离。

这个案例是我亲身参与的流程优化咨询项目的故事，给正在做流程建设的朋友们提供一点思考的方向。这个项目还在商务接洽的时候，老板就跟我们说：“你们不需要和员工接触，就跟我谈就好了，我是这个公司最懂业务的人。”尽管我们强调了让员工参与项目的好处及后续落地的可行性，但是老板坚持说：“他们都不理解我的想法，你们按照我的想法来做，就行了。流程做好后让他们照着执行，不行的话就全部换人。”流程的验收也是老板自己看完就行。整个项目周期要短，一个月内要全部做完。

于是，一个奇怪的项目组就诞生了：

项目经理：对方公司副总兼总裁办G小姐，刚到公司1个月，几乎不懂公司业务。

项目助理：对方公司M小姐，刚到公司2个月，主要负责公司的项目管理，也不懂公司主业务。项目成员：对方公司老板，三个顾问（无行业经验）。也就是说，6人组的项目成员中，真正熟悉业务的有且仅有一个人。从这里，是不是就可以看到风险了？我们当时有意识到这是一个风险，但没有完全重视，因为从前期和老板的谈话中，确实可以看出来他非常懂业务，也看到了他想彻底改变业务的想法，所以对于我们来说，就是用我们的专业知识，加上他对业务的理解，把流程架构、核心业务流程梳理出来。事实上，前期进展得也很迅速，在跟老板谈了两次以后，我们就梳理出了整个的流程架构及这次要梳理的主要业务流程范围（4个主流程），也得到了老板的认可。那问题是怎么发生的呢？

流程的要素有哪些，大家还记得吗？责任人、输入、输出、活动描述，这几个是最基本的要素，而且要理清楚这几个要素其实也不是太难的事情，那问题出在哪里呢？出现在流程细化的过程中。

也许是老板太久没有跟下属沟通过他对业务的畅想了，所以在讨论业务流程的时候，老板畅所欲言，跟我们描绘了很多他对未来业务的想法，包括业务模式的改变、整个业务流的改变，以及整个组织的调整，同时，也要求这些构想都融入流程中，也就是说，我们根据他的描述，整理出来一个to-be的业务流程架构。光有流程的架构、流程主要活动是不够的，必须细化活动内容，也需要梳理文件模板，就在这个阶段，问题得到了充分的暴露。首先，老板对于业务的细节，已经不再了解，毕竟有些业务他已经不需要亲自动手了，在脱离一线的过程中，也就脱离了业务。其次，对于行业来说，我们是彻底的外行，判断不出来老板的to-be中，有多少是与as-is差距巨大的，有多少是可以跳跳就能够得着的，所以只能在老板和一线业务中来回寻找平衡。来来回回的过程中，老板也意识到了，过于激进的改变可能不是最好的处理方式，最终同意大逻辑架构以他的构想为准，但具体业务活动的细节，以业务部门为准，验收也以业务部门的意见为准。这也算是老板对业务部分的妥协，他还无法真正下定决心，让所有事情重新开始。

其实到这个点上，就可以判断项目已经离失败不远了，因为项目的时间已经过半，任务却又回到了起点。只能再次反思，如何做才能让流程优化成功。（1）从项目构成来说，项目成员中必须包括一线业务人员，也就是离实际业务最近的人。只有他们了解业务操作过程中的细节，对各种业务场景的处理方式最熟悉。项目成员中也必须包含懂流程的人，能够帮助大家从细节中解脱出来，看到整个业务流程的大架构，看到流程的层次，看到流程与流程的交界。（2）从项目的流程来讲，第一步永远是现状分析。不了解现状，不足以谈未来，至少我是这样认为的。如果真的是一个新公司，全新的商业模式，另当别论。公司有流程或没有流程，现状分析的方法也有差异。在有流程的情况下，要看流程的执行度，也就是说要看看现在业务是不是按照流程在跑，如果没有按照流程跑，现在真实的业务情况是什么样的？和流程的差异有多大？造成这些差异的原因在哪里？针对没有流程的公司，就需要根据业务情况，把 as-is的流程描述出来。也就是说，在现状分析的阶段，我们要得到as-is流程，以及流程和实际业务的差距分析。（3）描述 to-be。to-be不是空想，而是根据一系列的事实依据提出的优化、改进方向，也就是说，

to-be是有论据来支撑的，to-be能给业务带来的好处，是可以清晰描绘的。对于to-be的构想，要在整个项目的范围内进行充分讨论，看看对于一些典型的业务场景，是否能够走得通。在流程建设项目中，我认为“蓝军”的角色很关键，可以对 to-be提出各种假设，进行攻击，看看 to-be是否真的比 as-is

更优。

（4）将as-is和to-be差异明确的地方拉出来，同时考虑to-be落地的计划。识别to-be在实施过程中可能会受到的阻力以及应对措施，包括识别干系人、与干系人进行沟通等等，都是为将来to-be的有效落地做准备。

（5）业务试点。根据 to-be 的长度和难度，选择试点方式。最好能在典型业务中进行 to-be 的试点，直接根据流程来跑业务，看看会遇到什么样的问题。再来看如何解决问题，或者进行to-be的调整和优化。

套路其实也就这些，只是我们面临不同对象的时候，所需要做的“技巧性”工作会有各种差别，这需要我们在实际项目中灵活的运用了。弯路不能完全避免，只希望我们边走边思考，能少走一点弯路，也能将to-be和as-is的距离缩短一点

04

流程不是万能的

前面讲这么多，是怕大家不重视流程，也希望能够通过有效的流程管理办法帮助大家提升流程能力。但又担心有的管理者对流程的期望过高，导致在看到流程验收报告后，会有失望和失落的感觉，觉得辛辛苦苦做出来的流程辜负了他，甚至对流程、对自己的方向又有产生了怀疑。我只能说，当出现这种情况的时候，也是正常现象，因为流程不是万能的。问题来源于方方面面，我们需要去分辨，哪些属于流程能解决的问题，哪些属于流程解决不了的问题，再去寻找根因，找到对应的解决办法。这

才是管理的终极。仍然结合案例来讲。一个结构开发流程推行半年后进行了验收，在验收过程中暴露出来一些问题：

（1）流程活动看起来很完整了，但实际上在进行开发的过程中，有些活动很难执行落地。

（2）计划和实际的项目进度偏差大。

（3）有的环节等待时间太长。

下面开始抽丝剥茧，对每个问题进行深入访谈、分析。

首先看第一个问题，有些活动难以执行落地。分析以后发现，难以落地的活动主要有两类，一类是计算分析类的活动，一类是与供应商有关的活动。在整个开发过程中，涉及很多需要计算、分析的内容，但是工程师做不出来。模板里定了框架，但没有具体的计算步骤和案例，所以还是不会做。为什么没有案例？因为公司几乎都没有项目从头到尾计算过，完全没有积累。所以这个问题实际上是人员结构、员工能力、公司经验积累、培训力度等几方面的问题。这个结构开发团队里的新人占比67%，能力不足可以理解。那针对能力不足、项目没有积累的现状，怎么做？成立专项小组，挑选有经验的工程师进组，通过师父带徒弟的方式，将这个项目需要分析和计算的内容完善，同时形成培训材料和案例。实际的业务过程，就跟带兵打仗一样，光有兵法不够，得一仗一仗地打，打赢，才能真的形成战斗力。结构件涉及很多和供应商打交道的内容，比如样机制作、开模等，我们设计的东西能不能做出来，有很大部分依赖于供应商，所以如果供应商出现了问题，是比较难处理的。这点首先要保证

双方对业务形成共识，同时在关键节点，我们不能局限于我方的流程，必要的时候要深入了解供应商的加工环节，看看是否能对加工过程进行干预，确保对供应商的要求传递到位。实际上，对供应商的管理能否有效，取决于业务量，所以对于初创企业来说，这本身就是一个难点，只能多协调多沟通，但无法保障流程完全有效。

第二个问题是计划和实际的项目进度偏差大，访谈结果如下。

项目计划是项目经理主导在做，虽然流程中写了结构工程师要参与结构计划的制订，但组内结构工程师没有经验，不知道在做具体设计的时候，多久能做好，也没有向部门内的老工程师请教。较长时间才能完成的任务，中间没有进行阶段检查，所以实际进展不及预期的时候，也未进行干预。工程师遇到难点后，不主动反馈，自己死磕，但是最终也没有磕出来。

这几点说明什么问题？首先还是能力问题，无论是项目管理还是结构工程师，对于项目的难度、需要的时间和资源的估计是不足的，也就是说连适配的能力都欠缺，对自己的认识也不够充分，无法判断完成什么任务需要多少时间。其次是工作方式方法问题，没有形成主动反馈的工作氛围，大家都等着项目管理来催作用，不会提出风险预警。

第三个问题是有的环节等待时间太长。仔细分析下来，等待时间较长的环节是审核环节。新员工较多，骨干员工太少，本来审核就变成了一个瓶颈，再加上前期的设计工作审核工程师参与得少，对工程师的设计思路不清楚，需要花时间去看整个设计的来龙去脉，时间当然就长了。另外 IT系统的key太少，经常登录不上去，无法处理图纸的签核流程。这个问题主要是团队人员结构的问题，从结构上来说，新老搭配是比较好的，一来老人可以带新人，另外也可以对项目产出把关，就不要额外的外援审核团队了。另一个是 IT系统的问题，公司整体发展了，规模变大了，IT系统还维持老样子，这确实对业务也是一种制约。

总结前面几个问题其实不难发现，流程真不是万能的，千万不要认为制订出一套流程后，研发效率马上就提高了，质量问题马上就减少了，整个工作都顺畅无比。只有当流程、组织、能力、文化、IT工具都同步发展了，才能支撑企业的快速发展。

最后想强调一下，流程化的东西都是长期积累下来的。比如硬件开发经常遇到的器件选型，我们需要考虑器件的可靠性、可生产性、可供应性等因素，那么这些因素的考虑，是把之前产品积累的内容，在器件选型的阶段就融入过来，而这些融入的因素不是简单一些思考维度，而是长时间的案例和经验、人员的积累。小公司在没有经验积累的时候，快速迭代变得尤为重要，一个版本的总结和积累非常重要。否则，每个版本都没有进步的话，就不断地原地踏步，做多少个版本，还是一样BUG一堆。

05

流程的核心方法论

“其实很多公司都对研发流程感兴趣，甚至很多公司花重金找咨询公司咨询华为的研发流程。但是如果没有以下几个关键点，很难去复制华为在IPD流程上推广的成功：

（1）从上到下变革的决心。新城容易建设，旧城改造难度大。

（2）有足够多的角色承载在整个流程中。小公司没有那么多人力和角色分配，很难实现IPD流程执行。

（3）有IT系统去承载一些关键内容。如果没有电子流，很多流程完全依赖人的自觉，或者依赖人的管理有时是很难执行的。

（4）掌握流程的精髓、核心方法论，不要生搬硬套，不然画虎不成反类犬。

所以硬十团队根据自身经历，包括在大公司工作的经历，以及自己创业的经历，总结了适合小公司管理硬件开发流程的核心方法论，包括以下四个方面。

1. 先僵化、后优化、再固化

华为自身没有生搬硬套IPD流程，所以成功了。除华为外，中国企业最早引入 IPD项目咨询的时间是 2002年，之后在国内有很多企业引入 IPD。大部分企业IPD流程仍停留在如何“低成本、高效、高质量地开发产品”，产品开发流程上并无变化，导致以下问题。没有建立需求驱动产品开发过程，没有建立需求端到端流程，将会出现以下两种情况：一是 IPD流程成为研发搪塞市场需求和推诿责任的工具；二是在市场冲击下，由于IPD建设不合理，僵化无法面对市场，企业无奈地启用以前流程，以前怎么走还是怎么走，IPD成为历史。

企业建立的IPD流程复杂，流程效率极低，IPD流程与公司运营流程脱节，加上市场在变，业务在变，IPD流程一直僵化在1.0版本。没有优化，认为好东西就不用变化。IPD流程实施后并没有带来显著的竞争力提升，IPD流程成为痛心之点。

高科技企业软件开发工作量占绝大多数，而多数企业仍以IPD流程模型支撑软件开发，软件开发效率与效果均不理想，软件质量差。企业没有想到可以使用“IPD+CMM”或“IPD+敏捷开发流程”解决软件管理问题。

所以，任正非的不败之谜在于“变化”，在于不断地“自我反省与自我修正”。

2. 统筹方法

“关键路径”之所以关键，就是因为这些事务或工作中耦合关系多、执行难度大、延期风险高，对项

目达成目标影响较大的，也因为关键，所以值得项目经理集中精力管理。在拟定计划的过程中，寻找关键路径，合理安排和统筹，并固化下来形成“流程”，这就是统筹方法。

3. 阶段性评审

IPD流程设置了很多技术评审点，小公司可能不需要这多评审点，但是每个环节都应该有个检查点，而不是等东西出来了，做个四不像，最后傻眼了。

但是如果主管水平不够，或者不懂技术，那就麻烦了，因为没法细致到每个细节去把握。每个开发人员都可以造成一种虚假繁荣的景象。

例如华为的度量表、单板返还率、直通率的考核指标，其实都是可以通过人为操作，造成一种虚假繁荣的景象，所以经常不深入细节的主管很容易被蒙蔽。下面介绍两种评审机制DCP和TR。DCP 是 Decision Check Point（业务决策评审点）的缩写，业务决策评审是集成产品开发管理团队（Integrated Product Management Team，IPMT）管理产品投资的重要手段，在决策评审中，IPMT 始终站在投资商的角度来进行评审。整个开发流程包括5个决策评审点，如图所示。

Charter：立项评审。

CDCP（Concept DCP）：概念决策评审。

PDCP（Plan DCP）：计划决策评审。

ADCP（Availability DCP）：可获得性决策评审。

EDCP（EOL DCP）：生命周期终止决策评审。

TR是Technical Review（技术评审）的缩写。通过技术评审，帮助产品开发团队尽早发现产品开发中存在的问题和风险，及时采取相应的解决方案和行动计划，保证产品开发质量，减少浪费。整个开发流程包括以下6个技术评审点，如图所示。

TR1：产品需求和概念评审。

TR2：需求分解和规格评审。

TR3：总体方案评审。

TR4：模块/系统评审。

TR4A：集成测试评审。

TR5：样机评审。

TR6：小批量评审。

个人认为 IPD 流程的一些评审点没有涵盖硬件开发的所有关键点，所以我们不用照搬 IPD 流程的评审点，而是抓住硬件的关键评审点。可以借鉴硬十的开发流程框架，如图所示

在上述框架中，需要抓3个硬件关键评审点：需求、投板、生产导入。

4. 严格把控从上一个环节进入下一个环节的条件这点我特别有感触，如果华为的某些指标达不成公司设定的要求，那么是不允许进入下一个环节的。例如，华为的直通率要求在95%以上，如果达不成这个指标，产品是不让发货的。需要反复地验证和优化设计、工艺等，直到小批量试制达成指标了，才允许过点，进入下一个环节。但是一些小公司，并不在乎这个指标。一旦产品海量发货了，就是给自己找麻烦。曾经在一个小公司待过，那个公司直通率还不到50%时，就开始发货。导致整个硬件团队深陷泥潭，中标如中箭。

最后总结一下，我个人理解的华为研发管理的10个模块，大致上分为“法制”和“人治”两个维度。

个人建议，在学习华为方面，先把“人治”做到，否则也只是邯郸学步，最后弄巧成拙。

20世纪90年代初期，随着迈克尔·哈默接连推出《企业再造》《超越再造》，管理界掀起了一股流程再造的风潮，流程管理也逐渐被大家熟知；20世纪 90年代末期，华为引入 IBM，开始了漫长的产品管理体系的变革，随着华为在商业上取得巨大的成功，华为的管理体系也逐渐被业界熟悉，IPD体系成为被科技制造业争相学习的典范，如今更是辐射到很多其他的行业，甚至金融、互联网都在学。然而，学得好的企业凤毛麟角，学得不怎么好的企业多如牛毛，于是渐渐又出现了另外一些声音，“搞IPD就是建流程”“流程无用”“华为是军事化管理，所以才能执行流程”……在我看来，流程是一种基础管理手段，没有必要神话，业务没搞清楚，流程做得再好也没有用，但也没有必要贬低，因为我们也确实看到了在很多的企业中流程管理发挥的作用。所以我们单独写了本章内容，就是希望能够把流程真实地还原，希望大家能够体会流程管理的本质。如果你所在的企业是创业公司，还在从0到1苦苦挣扎的过程中，这章内容可以先忽略。如果你所在的企业已经解决了生存问题，处于快速扩张阶段；如果你所在的企业已经达到一定规模，但效率

已经出现了瓶颈；如果你所在的企业内卷特别严重，和周边部门的配合特别不顺……你都可以好好地阅读本章节，领悟一些思想。

2月份中标信息：

1、

2、

3、

4、

特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.