1. 对于标准的理解

行业中有很多标准，诸如ISO、GB等针对降低协作成本的、保证质量的、提升协作效率的，保证合规的等等。大部分标准其实都规定了做什么，但没有规定怎么做，所以对于想直接按照标准实施的用户而言是一个不好的消息，但对于需要创新为主且需要满足Automotive SPICE规定的企业而言是一个好消息。

在如上Automotive SPICE手册中的图为例，Automotive SPICE的评估模型关注于What部分，关注目标，以及为了达成目标而需要做什么、为什么做、依赖的关键技术等。对于How，则需要企业根据自身的情况去构建组织、团队、流程、考核等How所需的方法、工具，这些方法与工具可以协助达到最初制定的指标。这个How算是组织级别的抽象的指导方法、工具、模板等。这一步需要应用到具体的项目、项目组、子公司等具体的事宜时则又需要根据实际情况裁剪。比如一个需要2年才可以完成的项目与一个仅有1个月时间且客户需要马上交付的项目，如果二者用同样的产出物、同样的审批流程、同样的上线及维护资源支持的话肯定是不合理的。

为此如果我们将这套标准简化为"操作手册"或"检查清单"，那么这种认知偏差将导致许多企业陷入实施困境——他们机械地对照标准条款逐项打勾，却未能真正理解标准背后的哲学内涵，没有利用此次机会真正地使自己的发展走上一个新台阶。

比如我在某国内头部企业做研发时，针对大型项目可以用CMM5的标准流程，而对于微型项目则需要裁剪，比如对于代码检查、测试需要严格保留，而对于需求文档、设计文档则可以简化，因为大家很容易针对这些达成一致。

2. 标准的审核人员也不仅仅是查看最终的产出物

如上图所示，评估人员需要看企业正在做什么以及正在做的这些事的方法、工具，也就是抽象出来的指导各个部门Doing的方法、工具。最后把企业如何做（How）与PA的的What进行对应，也就意味着这不仅仅是企业产生的一堆文档，也包含了产生这些文档的逻辑，以及文档之外的内容，比如会议、组织架构、流程等。

这里的How是怎么做或怎么得到产出的方法、工具；Doing是根据How具体执行的实践。

评估人员需要审核Doing, How, What之间的一致性，这是站在负责任的角度。如果企业为了得到标准临时凑齐了各种文档，比如培训记录，协作流程图，需求与设计一致性的文档等等，有可能能通过标准的审核，但对企业而言百害而无一利。

如果是站在自我发展的角度，企业也必须保证过程能够产生标准规定的必要产出物及对应的举措。

以如下的SWE.1为例。

如下是Level 1标准：

如果用PA Level 1审核SWE.1，那么SWE.1规定的内容需要有，比如需求、分析结果等。

而至于Level 2标准：

就涉及到过程的策略、计划、资源需求、协作矩阵等，这些是需要大家协作的，需要组织、流程、系统的协作，而不是仅仅一个产出物。比如计划怎么做、成本如何评估、软件需求是否符合系统需求等，不是仅仅一个文档的输出，而是需要哪些人参与、那些人审批、各自的输入是什么、输出是什么、如何考核、什么时间点评估、怎么才算评审通过等等，这是需要组织上面规划，建立战略，而流程规定了协作的标准，人按照标准执行，系统协助执行、评估、预测、保证数据强一致性等。

尤其是到Level3后需要把这些How应用到其它部门、项目，如果这个How没有，那就无法正确地、有实效地产生必要的产出，而在多方协同混乱的状况中痛不欲生。

这些How不会规定在标准中，而是企业根据标准要求的输出、原则而设计的过程，这个过程是真正帮助企业发展的而不是文档的输出。比如很多企业都在学习头部企业，学习华为的IPD、ISC、ITR等，有些企业甚至购买了全套的这些流程的模板，但真正能做到的企业很少，也是因为这些模板、甚至流程框架都是抽象的，都是What及How部门，而要做到Doing，就涉及组织架构、企业文化、系统、协作力度、信息共享程度、员工主动性、部门墙的厚度、为他人考虑的意愿、短期主义为长期主义服务、领导支持、责权利一致等等。就好像很多企业也满足了CMM3， CMM5，也实施了IPD，但开发的大部分产品还是不能满足市场需求，还是有很差的质量。

有些企业会认为结果最重要，过程是次要的，希望3个月或最多半年就有看得见的结果，站在客户生存的角度没有错，但如果要长久发展的话还是要注重过程，把过程固化。业务的优化是建立在固化的基础上，而不是混乱的基础上。过程的固化意味着很多产出是可以预测的，至少相比于混乱而言是这样的，那么在可预测的基础上去做优化才是有意义的。如果未来产出不可控、不可预测，我们优化的目标是什么？哪些不足是我们需要优化的？哪些资源需要配合我们的优化呢？

3. 理论与实践结合

没有理论的指导很多工作无法执行或执行不好，而没有实践的验证与修正则理论就变成了僵化的本本主义。而理解理论与理解实践的往往是不同的人，如果二者不能协作，则二者对理论与实践的理解都不属于真正的理解。比如我们做软件架构，我们会根据需求画用例图，去找对应的组件，去定义组件的接口，构建动态的活动图，但如果我们知道了系统论，知道了联系观，知道了不同实体之间的矛盾等，就更能深刻的理解软件架构，我们会主动地发现没有考虑的利益相关者，发现组件协作的必要性，发现协作对整体系统的影响，发现需求的变化对其它相关方的影响等等，可以把这个抽象应用到硬件架构，应用到具体的组织、流程改造。但每个具体的应用又有区别，人之间的影响与系统之间的影响，以及人与系统之间的影响考虑的具体因素是不同的，我们需要把抽象进一步具象，也需要修改抽象。

理论与实践的结合，也是抽象与具体的结合，相辅相成，一个让大部分部门受益，一个让具体的业务收益，最终是大家收益。

4. How类似理论

我们不能仅仅说我们要打胜仗，还要规定大概的思路。比如我们要通过新产品切入某个客户群体，这个一个结果。我们还要有大致的路径，比如怎么调研，怎么分析需求，怎么分析市场，怎么分析竞品，怎么研发，怎么销售等等。然后到具体的调研，也有调研的大致路径，但具体到调研的问卷、调研的地点、工作时间等就需要具体情况具体分析了。

没有How，大家怎么配合呢？怎么支持呢？怎么落地呢？交给一个人去协调最终无法做好需要一致协作才能完成的事。

5. How指导Doing，Doing更新How

标准中的How与Doing就是理论与实践，当然了，严格讲这两个都是企业具体执行的实践，但相对How更抽象，更理论。

在企业中有些流程我们需要精确到每个步骤，每个动作，比如企业中的SOP（Standard Operating Procedure）。也有的流程需要给人或部门以创新或发挥自己主观能动性的能力，比如产品创新、解决疑难问题、与客户建立稳定的商务关系等。为此这个How不能一概而论，但最好有How，有根据How出来的Doing。这也与流程分类框架类似。

6. 流程框架

如果大家熟悉 APQC 的流程分类框架就知道其为了通用型就只有分类，也就是只有企业应该做什么，但对于怎么做却未提及，也就是没有部门与部门之间的协作，更不用说人与人之间的协作了。如下图APQC的13个大分类及小分类，都是告诉企业应该做什么。

大分类截图：

2.0这个分类的细化（样例）：

很多企业请了咨询公司做了上层规划，也就是战略及做什么可以保证战略的落地，但缺乏How及Doing。比如对标头部企业，他们做敏捷开发，我们也做敏捷开发，但敏捷开发涉及的多方协同、客户关系、质量管理、代码提交原则、行业专家、客户体验、工作项不能过多、员工主动领任务、员工主动为质量负责、文档简化及多样性便于理解、如何应用瀑布开发中各阶段的一致性于敏捷开发中、给予工作量评估的容忍度与迭代、员工素质等等，这些How及Doing不考虑的话注定仅仅是徒有其形而已。

再比如集团没有上收采购权，而是规定了必需有专门的采购能力，采购能力中必需有供应商管理，供应商管理中必需有供应商调研->供应商招标->供应商实地考察->供应商谈判->供应商考核机制->供应商绩效监控->供应商退出机制等，但对于如何实地考察就交给具体的分公司具体制定。

规定这些大的What及How，可以找到共有能力从而集中管理，比如有的集团把采购统一管理了，有的把供应商统一管理了，有的把供应商谈判同意管理了等等。如果只有Doing没有How就很难找出统一管理的能力及剔除冗余的能力，也增加了各个部门及分公司实施的成本；如果只有How或How与企业实际不符，则就是理论与实际脱节，是各种浪费的主要症结之一。

7. 结尾

所以站在持续发展的角度，需要理论与实际结合，先了解自身，小步快跑，不要被竞争对手、各种管理模式、各种新型技术蒙蔽了心智，忘记了自身企业的文化、业务主线、解决的问题等。