质量部将触手伸到一线部门是大势所趋，质量BP也将是被越来越多组织将采用的模式，我们已经看到不少企业，把质量部定位为“质量运营部”从原来的产品质量升维到大质量的角度来思考质量的职能。在职责里已经开始包含，财务目标规划、预算监控、跨部门流程优化梳理，明显与运营相关的工作。在宋老师给大家反复提出的质量价值闭环体系中，提到，企业运营的核心仪表盘，正是基于“财务模型”。所以，从这个角度看，有点经营协同的意思了。

但这个转变，对于当前的质量人员而言，无异于一场大的转型。在传统质量管理中，是远离“财务”的，质量大师克劳斯比，把质量成本，引入质量管理中，试图打通质量与经营的任督二脉。但在我看来，这个管理工具，根本是无法解决这个问题的，甚至在企业中也很难实用用起来。具体原因，我在我的“打通质量与经营“的专题分享已经讲过这里不累述。所以，打通质量与经营的重任，质量成本，这个工具是承担不了的。

另外，质量赋能，要求质量人员不能仅仅是监督的视角，而是从赋予业务能力的角度来开展工作，但自己把业务做好和监督业务做好，这之间是存在巨大知识、技能鸿沟的。

相对来说，数据是质量人员较为熟悉的区域，但和之前只顾着自己这质量专业指标相比，现在需要真正能对业务实际支撑的数据架构。

很多质量同学看了宋老师提出的质量BP模式后，都会想，我以前就是一个干“城管”的，现在让我相当于成为顶级咨询师，我要有这本事，还在公司这小庙待？

我想，对于如何实施质量BP上，还有必要继续聊聊。

PART

1

质量BP的转型

我们看到很多公司的质量部门负责人，一般都凡事力求严谨、事无巨细，部门似乎也是最忙的团队，无休止的审核计划、巡查考核、纠偏执行。。，但往往细致的工作换来的却是抱怨，业务部门埋怨管的太僵化，不考虑业务的实际情况。

质量人员如被“圈养”一般，沉醉在这样的繁忙中，逐步失去了业务部门所需要的专业性，而且实际我们也会看到现在大量的质量人员，连 8D和根因分析这类基本工具应用都不过关。有次做一个研发问题的根因分析，安排给一个从业界质量标杆公司背景出来的质量部门经理，结果交给我7次，都被我退回，而且每次提交给我的根本原因都不同。我不得不抽时间，给他指导 5why 逻辑应该如何展开。

质量管理人员们由于长期在总部衙门，不在业务中，仅仅懂点内部政策、标准、规范，匮乏的业务知识，也难堪大用。有一次，公司管研发的副总，给我打电话说，“你们质量部的人，咋像个衙门，研发工程师到你们流程标准方面的问题，你们就会回复，自己到公司OA上去查，不能直接给个说法么？” 我这才意识到问题。

另外值得关注的是，即使质量BP们中有专业突出者，其下沉到业务部门后，又如何能够在传统企业匮乏数据的条件下进行质量管理的支持服务呢？

宋老师记得，刚开始推行质量BP时，业务部门的经理其实依旧会把质量BP当成是“卧底”事事防着，根本不把质量BP纳入核心流程中。

但另一方面，业务部门有些方面也是需要质量BP支持的，比如，有的业务部门过程模糊容易出错，需要梳理清晰；做产品需要确定质量目标，了解相关的质量标准和历史的基线数据；制定对应的过程度量评估指标和分析报告，质量考核。有客户过来审核，需要专业应对。出问题，给客户回复报告。往往在这些时候是质量BP们的高光时刻。

有的质量BP可能做的还行，但有些可能折腾半天，给出的数据报告还有考核结果，大家都不认可，天怒人怨，很快失去业务部门的信任。

后来我反思，这样模式问题在哪里？

我后来想明白，我设立质量BP初衷并没错，但是支撑模式并不合适。

从质量专业职能建设的角度，我自然希望用一个相对统一的标准为业务部门解决问题，而不是依赖个人能力，只有这样才能构建 组织级的质量能力，公司的质量专业能力的厚度才能不断增加。另外，依赖个人能力，就没法管理解决方案之间的统一性，如果不需要统一性，质量BP为什么要有质量部门派驻，而不是业务部门自己随意招聘呢？

因此，质量BP的运作模式，也需要 “云平台" 的管理模式。之前把质量BP放到业务部门承担监督、内部咨询的职责，以自生自灭的模式，改进为质量部建立一个强大的后台支持，以此为质量BP提供专业能力的强力补给。

云平台管理模式，由2个层级组成，即服务平台、终端。

服务平台层，主要由下面过程资产和数据组成：

1、质量管理到经营结果这条逻辑链条上的信息和数据，即从，价值创造流、职能专业能力及资源配给到面向市场的有效产出，依次传递的的指标库。

2、构建质量赋能需要的信息和数据，即 度量考核信息、失效模式积累、能力基线、经验教训、质量标准库、制度流程库、行业标杆库、最佳实践库及碎片化的经验知识碎片信息。

终端层，由质量BP充当数据端口。一方面 上传对应的信息到平台；另一方面，也从平台获取能力，向业务部门提供专业的咨询决策信息。

通过运作模式的调整，经过一段时间的积累，原来显得并不专业、底气不足的质量BP也开始变了样了。

比如上文说的，要建立度量系统，质量BP可以，从平台上获取，其他业务部门类似的流程环节的拆分，并配上其他业务部门类似流程环节的指标，根据纵向的历史信息和横向的其他部门信息提出目标值、基线的建议。

此外，还可以发挥引导职能，主动引入外部企业的标杆数据，通过差距分析，推动质量水准的持续提升和改善。

云平台提供了一个质量BP们相互学习的“维基百科”，使得某个质量BP在制定方案时并非孤军作战，而是能够最大程度吸收别人的经验。

尤其是，这种经验也是在公司其他部门或行业企业实践和验证过的（如别人上传的绩效考核指标，就可能是使用过，被证明是能够说明业绩的），随着平台上的信息会随着大家的“维基”变得越来越有价值，并逐渐剔除无效信息。

从另一个角度看，我们也可以说，云平台其实是知识管理的平台，可以最大程度促进了质量BP团队的组织学习，这才是质量BP们专业能力提升的根本原因！

从根本上讲，质量部的专业性和影响力并非仅仅来自云端，而是来自终端每个下沉到业务部门的质量BP。每个质量BP都成为质量部专业能力提升的原动力，他们是贡献者；而人云平台则将这种原动力整合成为一个知识体系，他们又是受益者。

PART

2

如何搭建“云平台”

云平台能否形成如期的影响力，有两个关键点。

一是数据构架。质量运营数据几乎覆盖企业全流程、各方面。究竟要收集哪些数据才能提炼出有价值的参考信息，形成专业支持？这就需要质量部部率先进行数据构架设计。

每个数据集都包括了精心挑选的数据接入点，收集的数据，能够清晰说明“质量管理工作如何提升运营质量”的问题。

这当然是企业能否建立“云平台”的关键，但遗憾的是，大量企业的质量部都没想清楚这个的问题。头疼医头脚疼医脚，然后被不专业老板的乱指挥带偏节奏……质量一把手缺乏数据构架，其实就是“没思路”。

真正强悍的质量一把手，应该能跳出现象看本质，跳出专业看经营，跳出当下看终局。

要让一个云端变得更聪明，显然应该让它获得更多的数据，学习到更多的经验。

举例来说，业务部门最喜欢问的，我们行业的质量指标应该是什么，基线应该是多少？标杆企业多少，我们同类企业多少，竞争对手又是多少？要回答这些问题，一定是基于对行业的深度理解；而基线数据，也一定是用样本数据“喂养”出来的。

所以，我的建议是：

一方面，质量部牵头引入了外部标杆数据、现有的经验数据，这也能形成了云平台的初始价值。另一方面，也可以思考如何在业务部门发展质量BP之外的终端。

例如，某岗位上，一名员工可以第一时间接触到其他人的最佳实践（如被验证的有效提升产品质量的方法、流程优化策略、降低成本的方案），这就不需要质量介入，而在线上自动完成了赋能。

按照这个方向发展，我们可以把每个员工都是变成质量BP，业务人员利用云平台提供的强力支持进行自我管理。至此，质量才叫真正的和业务融为一体！

-End-

如果觉得文章还行，别忘记点关注！