如何理解并评价智能车的产品竞争力？

两个月前我曾写过一篇同一主题的文章，当时重点强调为了适应智能电驱时代场景深度和宽度均在大幅增加的挑战，车企需要改变过往配置直接承接用户需求的定义模式，而是在场景层和物理层（配置）之间构建一个虚拟层，即原子服务，然后将原子服务作为车辆响应各种场景和需求的资源池，通过功能定义组织调用各种原子服务去响应场景层的各种变化。在这个思路指导下，能用算法解决的问题就坚决不用增加硬件的方案，反过来设计硬件之初就需要充分考虑到算法的要求。

因为产品定义的逻辑改变了，我们评价一款智能车产品竞争力的逻辑也必须跟着改变。总体而言，在智能化变革仍在深入和加速的当下，我们理解和评价一款智能车产品竞争力的逻辑必须满足：

1、 如何定义就应该如何评价，当然反之亦然。今天矛盾的源头在于市场风向和用户需求都已经改变了，但很多车企的产品定义思路没变。大家如果非要用旧时代的定义思路去审视新时代的产品，就必然出现鸡同鸭讲的尴尬局面。

2、 智能化变革落地到产品定义领域，改变最大的就是软件和硬件的关系，因此相关的产品竞争力评价必须既要正确处理软硬件的协同关系，又要分别针对软件和硬件展开梳理。

3、 智能车产品竞争力评价不能是静态的，也就是这个评价的不仅仅针对的是一个时间节点，而应站在这部车可以具备的升级潜力这个视角看，评价该车型未来一个时间周期内可以获得的产品能力。

4、 产品竞争力虽然评价的是产品，但产品背后的车企更加重要。透过一家车企的作品看这家车企的战略能力、逻辑能力和组织能力同样是产品竞争力评价输出的关键信息。

正因如此，SoCar在设计新的产品竞争力评价模型时，才明确地把智能车解构为体验层、场景层、服务层和物理层四个层级。这里再简单重复一下四个层级分别对应的评价标的：体验层对应车企的品牌战略和整体感受的营造方向；场景层对应车辆需要响应的各种使用场景和每个场景下面的用户需求；服务层对应的是车辆的原子化的功能资源，也就是车辆在功能定义中可以被调用的资源；物理层则是指向车辆的具体配置或者硬件。

其中服务层，也就是原子服务的提出，除了可以解决软硬件协作关系问题外，更是为了解决产品评价不是面向一个特定时点，而是需要兼顾未来相当一段时间产品升级潜力的问题。因为服务层指向的并非确定的配置或者硬件，而是可以借助软件去控制硬件达成的车辆控制目标（也就是某项配置能力），或者单纯依靠软件实现的某种车辆控制目标。因此服务层我们统计的只是车辆具备的某些特定维度的能力，而非具体的实现方案。但这些能力又可以被应用在具体功能定义当中，形成承接场景和用户需求的功能或功能组合。与此同时，车辆拥有某些原子服务，又不意味着目前已经充分使用了这些能力，未来可以通过持续的OTA或其他方式的升级迭代，陆续完善这些原子服务的排列组合方式、调用逻辑等，进行用户体验的优化。从这个角度看，原子服务既可以评价当下，也可以评价未来。当然评价结果更可以是非常具体的产品能力优化路径，尤其是可以在不增加配置的前提下，实现更多功能。

那么如何通过一台车的评价看清背后这家车企的战略、逻辑和组织能力呢？

显然借助各层数据的现状和对应关系，尤其是跨层之间的数据对比关系，我们可以获得更多洞察。

首先在体验层，我们看的是一部车带给用户的整体价值和体验感受，虽然这一层目前缺乏严格有效的量化评价方式，但这一层是最适合与车企品牌战略对接的内容。

其次是场景层，场景层包含了场景覆盖与场景选择两个方向的问题。前者指向这部车可以应对的所有场景，也就是宽度问题，后者指向这部车具有优势的、试图创新和突破的场景，指向深度问题。显然对于产品定位问题而言，场景层的选择和取舍最能说明问题不过了。此外，把体验层和场景层结合起来看，一款车选择了哪些场景，然后在这些场景中兑现了什么样的体验，以及这个背后是否合理、有效，最能体现这家车企品牌管理和产品策划的能力，如果两者是割裂的，背后一定意味着上述两个智能团队也是割裂的。

透过服务层，我们看一台车选择提供了所有原子服务中的哪些，放弃了哪些，这就意味着该车型功能定义的机会倾向在了哪些方面。如果我们把场景层与服务层也结合起来看，服务层的取舍应当是用来支撑场景层所需的功能定义的。如果两者不能匹配，则说明该车企产品策划与开发之间缺乏有效共识，或者说明该车型把资源投入到了错误的方向上。因为每个原子服务理论上都是需要投入成本的，需要投入哪些、投入多少，都是由该车型的产品定位和竞争策略决定的。逻辑上，在产品定义过程中，企划部门需要把场景选择圈定好，然后依据场景选择和场景排序锁定所需的原子服务。然后研发部门再以实现所需的原子服务为目标，定义产品方案。

最后，到了物理层，每一个配置都可以被视为原子服务的提供方。在原子服务相同的情况下，物理层应当越简约，也就是服务提供方的数量越少越好。如果车企的定义逻辑是由开发部门以达成确定的原子服务列表为目标，去收敛配置的话，理论上这一层最能考验开发部门的水平和绩效。如果我们把场景层、服务层与物理层结合起来分析，可以打开每部智能车支撑各种使用场景的产品应对逻辑，自然相关的问题和产品优化方向也可以梳理的更为具体。比如有些配置同时提供了多种原子服务，但其中一部分在场景层的使用效率非常低，或者基本没有必要。那么我们就可以尝试剔除这些冗余的配置能力，自然采购部门对于这些配置的选择要求也就可以随之降低。此外通过这一层我们也可以看到每款车的成本能力。

以上仅仅是SoCar在过去几年开展相关产品定义、评价和优化的基本逻辑。在具体操作过程中面临的实际问题肯定比本文要复杂很多。因此真正应用上述逻辑，一方面我们需要一个完善的，按照上述逻辑构建的产品体验对标数据库，及时全面了解行业的整体水平。另一方面我们需要沉淀更多的案例，在沉淀案例的过程中积累实操经验。针对数据库构建的问题，SoCar的长期目标是要建设可以打通从场景发现、积累到筛选，然后将筛选出来的典型场景应用于产品对标评价（场景层的测试场景），进而跟踪各场景所需原子服务和具体服务提供方（物理层）的完整数据链条。至少到目前为止，我们已经基本打通了上述几大环节中最为关键的部分，也欢迎大家与我们一同打造和深化这种真正沿着智能车逻辑展开的“行业基础设施”。

下一篇文章是硬广，专门介绍我们已经成型的这些方法和工具。