就像前面几篇文章介绍过的，SoCar一直在跟踪和梳理智能电驱化以后的产品战略如何管理，场景极大丰富以后车辆的竞争力如何评价、如何描述等问题。几年下来我们逐渐形成了一些逻辑框架，并且从这些逻辑框架出发，设计并积累可以有效支撑下一阶段产品定义、产品开发和产品评价工作的关键数据以及参考指标等。我们把这些数据全都整合到了场景体验对标库这样一个产品当中。今天这篇文章既是方法论和逻辑的介绍，也是SoCar场景体验对标库整个框架的介绍，当然也算是一篇硬广。
场景体验对标库所要解决的核心问题
随着软硬件的解耦，一方面车辆能用算法解决的问题，就不再需要增加新的硬件，另一方面固有硬件也需要配合算法改变自身的结构，让自己变得更加好用，或者说是硬件要做软件的资源。这种产品定义和设计逻辑的变化必然导致传统的工程对标不再像以往那般有用，或者至少需要引入新的视角。
▲来自SoCar
于是我们就需要找到智能电驱时代能够串联所有产品特征的关键线索，显然一切产品升级和创新都是为了帮助用户解决更多问题，带来更好体验而服务的。那么场景和体验就是所有这些问题最为关键的线索。以往由于传统燃油车的使用场景早已充分固化，所以产品的内涵和外延基本稳定，我们可以通过一组相对固化的指标管理这些产品特征。但现在这个前提被突破了，场景就需要被放置在指标的前面，起到更加重要的统筹作用。比如我们按照指标去调教换挡档杆的手感，最终我们会发现如果只看这些细节指标，而忽略了几乎所有电动车都已经切换到了操作更加简单，更容易形成肌肉记忆的怀挡，即便我们把档杆调教的再有吸入感，位置再清晰，也没有改变一个设计形式创造的价值更大。因此在当下这个赛道切换周期，我们更应该从整车或者系统层级出发，在真实的使用场景和完整的上下文中思考和解决用户体验问题。
此外，由于智能电驱车与传统燃油车不同，其产品竞争力解析需要沿着从体验层到场景层，再到服务层和物理层的模式逐层展开（这个逻辑我在之前的文章《如何理解并评价智能车的产品竞争力》当中详细介绍过，大家可以参考），因此对标分析的数据结构也将有别于传统车的围绕参数、配置的梳理逻辑。如果不做出这种改变，车企永远无法跳出堆叠配置，越来越卷的恶性循环。
也就是说，SoCar推出的场景体验对标库在本质上是沿着智能车的产品竞争力模型逐层解析的，以场景为关键线索的新型对标模式。它是顺应智能电驱化背景，为解决车企产品定义、产品竞争力评价和产品生命周期管理工作而推出的更加具有针对性的工具体系。
场景体验对标库的数据架构和逻辑基础
就如上文介绍的那样，SoCar场景体验对标库中每个车型都是沿着体验层、场景层、服务层和物理层四个层级展开的。这四个层级既是我们定义智能车的逻辑基础，也是我们审视所有同类产品的逻辑基础。当然这里需要补充说明一点的是，很多车企在场景层和服务层会增加一个功能层，但不同车企功能清单的分类方式和颗粒度不同，SoCar为了保证该数据库可以同时服务更多车企，我们跳过了这个缺乏数据标准的层级，而是直接将车辆的产品资源原子化，从原子服务这一层入手，既可以组合成各家车企所需的功能清单，又可以横向对比不同产品开展功能定义的产品潜力。
▲来自SoCar
当然更加重要的是，在四个层级可以逐层展开的同时，每一层数据之间又需要保留清晰的关联关系。比如A、B两个车型可以应对同样多的使用场景，但他们各自拥有的原子服务不同，调用这些原子服务的排列组合也不同。我们可以通过详细展开对比两个车型原子服务的覆盖、调用逻辑深度分析他们应对各种场景最终体验差异的具体原因。再比如A、B两个车型支撑同样多的原子服务，但使用的物理层，也就是具体的组件或者配置数量是不同的，显然使用组件少的车型硬件使用效率更高，成本或者下一阶段的降本空间也就越大。只有把原子服务和物理层各组件之间的映射关系全面梳理出来才能真正看清这里的复杂关系。如果我们再穿越一层，从场景层直接到物理层，就更加可以为车辆的配置选型评估提供更为直接的参考数据输入了。
所以说SoCar建立的这套场景体验对标库既是展开产品竞争力评价的工具，也可以用来管理产品定义和产品开发，甚至为开发部门设置KPI或者挑战性目标。
对标所需的测试场景来自哪里？场景体验对标库与用户体验场景库的关系是什么？
场景层既然是场景体验对标库的关键线索，那么对标测试的场景来自哪里就是很核心的问题了。在这方面我们最大的积累其实就是过去五年来持续搜集、积累和拓展的用户体验场景库。当然更加重要的是，我们把用户用车的场景做了结构化，让“用户故事”代表的场景可以对比，可以统计，也可以解构和重构。做到了这一点，我们就可以将用户体验场景库中的典型场景有效抽取出来，作为场景体验对标库测试场景的来源。然后再通过场景体验对标库将不同车辆不同设计方案的用户体验闭环回场景库。
因此场景体验对标库与用户体验场景库是一个闭环的左环和右环的关系。没有场景库，或者场景库的积累不够坚实，场景体验对标库就缺乏基础；没有场景体验对标库，用户体验场景库就缺乏每个场景中真实解决方案的反馈，用户体验场景库就很难再进一步深入下去。这也是为什么SoCar先用5年的时间在做场景库（当然也是先从零散的搜集、规范和整理入手，再慢慢形成标准格式，最后再到数据库系统和嵌入流程的工具链），在场景库基本稳定成型后，体验对标库才逐步提上日程。
车企如何应用场景体验对标库？哪些部门适合使用场景体验对标库？
如前文所说，SoCar这一版场景体验对标库是服务于车企从产品规划到产品定义，再到产品营销和生命周期管理这一完整链条服务的。这个链条连接了车企从战略规划部门到产品定义部门，再到开发部门和营销部门等多个核心节点。只不过各部门的分工不同，应用该系统的入口和方式各有不同。
▲来自SoCar
首先是战略规划部门，需要从场景层入手，动态跟踪市场中代表前瞻趋势的各车型在典型场景中的体验表现，进而分析不同车企场景的取舍和覆盖逻辑，为自身的产品规划和产品定位提供支撑。毕竟下一阶段车企产品规划的逻辑也不能再简单依靠尺寸、价格、厢体形式这些维度做传统的市场细分了，而是需要从目标用户与核心场景的角度先要回答清楚每款车型的定位问题。
其次是产品定义部门，需要在产品定位强相关的场景中，研究目标车型的竞争策略问题。这个时候核心竞品和趋势竞品在典型场景中的具体表现，以及支撑这些场景所需的原子服务就是定义部门首先需要重点关注的问题。围绕目标车型的竞争策略，产品定义部门需要给出明确的场景排序和体验目标，最终这些又要转化为目标车型所需原子服务清单（相当于为目标场景要资源）。在原子服务清单确定后，定义部门可以将这些目标输入给开发部门，作为产品开发的关键目标。同时，为了支撑同样一组原子服务清单，开发部门设计的产品方案肯定是所需硬件越少效率越高，这个时候定义部门还可以通过服务层和物理层的关系，为开发部门提供一个成本和硬件效率的关键目标。
▲来自SoCar
然后到了开发部门，开发部门从定义部门获得的目标包括两个：需要支持的原子服务清单，以及支撑这些原子服务清单需要的物理层需要精炼到何种程度。显然如何同时满足这两个目标，开发部门需要参考优秀竞品的很多设计思路，这个时候服务层和物理层的数据关系就成为开发部门最有效的参考依据了。
再到后面是营销团队，理论上车辆的营销包装、市场推广也需要从场景出发，将这辆车的优势场景，尤其是种草场景传播出去。以前很多车企都是车辆出来以后市场部门再基于自己拿到的实车重新编故事，做推广。现在如果从定义阶段即引入了场景化的思维，车辆的传播所需的故事脚本也就可以直接锁定了。如果营销团队再通过了解并横向对比同行竞品在这些场景上的体验表现，可以进一步判断早期定义的场景是否依然有效，并进一步优化自己的传播策略。
最后到了产品周期管理部门，尤其是OTA管理团队。通过对比自身产品与核心竞品在各场景中的表现，同时梳理目标车型已经具备的原子服务还有哪些在各种场景中依然未被有效利用，车企即可通过OTA或者其他形式的升级，在不增加配置的情况下持续优化用户体验。此外也可以通过分析哪些原子服务在场景中被调用的次数几乎为零，或者哪些物理层的组建提供的原子服务不仅数量有限，而且重要性不高，这些部分就将成为车企中长期降本的主要着力点。
以上文字内容先从逻辑和使用方式角度做了一个初步介绍，具体内容我们将陆续释放。
关注So.Car官方公众号
掌握So.Car最新观点动向
