研发流程管理怎么管？（研发流程管理怎么管理）

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

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

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

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

除了提升流程设计的质量，我们也要用一些好的方法和工具来帮助我们管理流程设计的过程。一个全新的流程设计或者预估有比较大变动的流程优化，我们可以用类似产品开发流程来管理流程开发的过程，把流程优化当作一个项目来管理。一些小的流程优化可以用CR（change request）的方式做流程优化的评审。这两种管理方式涉及到的治理结构和组织，后面会单独分享，现在先看看这两种方式的管理过程。

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

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

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

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

成立推行小组：无论做什么事，一定要先有人，流程推行也不例外，所以首先要成立推行小组。推行组组长，一般由流程owner指定的代表担任，小组成员则由涉及到的部门领导指定成员担任。在HW，推行组的成员一般来源于三个方面：流程部门的流程管理工程师，各产品线质量部质量工程师，各产品线业务部门的业务代表。三者角色不同，看待流程的角度不同，更能全方位，更客观的去评价流程及推行过程中遇到的问题。

制定推行计划：制定推行计划这个过程至关重要，除了要确定推行的整体时间计划（包括后续跟各级领导的汇报沟通时间），试点项目，推行的范围等等，这个阶段最重要的工作是要为推行准备好所有的材料。这些材料包括：培训材料，汇报材料，FAQ，流程变更清单，流程适配表等等。好吧，从流程活动的划分上来说，我应该增加一个活动，叫推行准备。

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

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

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

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

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

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

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

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

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

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

• 有专门的部门，退一万步讲，有专门的职位做流程管理的工作。这个部门的职责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数量大概有 50条左右，涉及更改的流程文件的上百份（包括流程图、模板、指导书、checklist等），所以CR的管理是非常重要的，在华为，我们通过研发流程CCB的运作对研发流程领域所有的CR进行管理。CCB有固定的运作秘书，一般由研发流程部的流程管理工程师担任。运作秘书一般会在前一年的12月制定会议日历，将第二年全年的会议日期确定下来（一般是每月一次，一次半天），然后按照月度会议时间召集会议。

CR的管理过程：CR的发起者通过CR电子流提交材料，材料中说明CR的原因，涉及的流程文件，与相关人的沟通记录等。运作秘书收到电子流以后，会对材料进行初审，初审通过后与相关流程的责任人进行沟通，然后安排议题，组织评审会议。通过CCB会议评审的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的距离缩短一点