车企为什么需要构建场景数字化系统？
当下以用户为中心、场景化、用户体验等概念在智能车的产品定义与开发中可谓绝对的“政治正确”，也是在经历了若干个完整产品定义与开发的过程后，笔者逐步意识到这些概念中，唯一能够真正起到串联和工具作用的只有“场景”本身，虽然这个词已经快被用烂了。场景在需求、产品和开发之间的“耦合”作用，体现在单一场景/用例在某创新定义或功能开发时提供微环境；连续性的场景/用例组成用户旅程，保证产品和功能的叙事性和完整性；场景库则是从产品和开发全局出发，最后必然形成的数据沉淀。这些数据无论车企关注与否，在完成1-2款产品策划与开发后已经产生并对后续项目环节持续产生影响，只不过取决于车企是否建立有效的数字化系统将其结构和单元稳固下来，形成可沉淀和生长的数据库。
因此，在车企工作流中，场景更像是一种语言，构建一个“语境”和“语义结构”，让研发链上的各个部门能够形成共识，并通过这套共用结构，完成各自的数据积累与迭代。换句话说，场景库才是车企实现研发数字化转型的“设施和枢纽”。
智能车时代，车企要想实现真正快速的产品响应，特别是对新场景新模式支撑效率的提升，如果不在业务层面做好沉淀，仅仅在纯技术层面进行沉淀和改进，其工作效率的提升是有天花板的。而如果将核心能力以服务的方式进行有效沉淀，实现服务在不同场景中的业务能力重用，这样随着业务层面的沉淀，一个新建系统可能有30%～40%的核心业务服务和数据模型都是现成的，只需要基于这些现成的服务进行组装和扩展来实现新系统的需求，这种方式的效率一定是指数级提升的，场景如同引擎，组织、实现服务和能力的“复用”是场景库的最大价值，也是“SOA”的最大价值。
场景库在企划与开发部门落地应用的异同
相对于领先的造车新势力，大部分车企策划和开发环节存在显著上下游关系，两者是相对独立的组织。在工作过程中各自的研究对象、研究内容与关注点也存在显著不同。这使得大家在对于场景的理解和应用侧重上，存在明显差异：
首先，对于企划部门，核心工作是研究用户需求，结合市场竞品表现，输出产品目标，因此对于场景库的应用有以下几点：
- 用户研究：通过场景分解洞察用户需求，并将需求通过场景库结构进行归纳沉淀；
- 产品定义：以场景为引擎和线索，通过场景的层级结构，建立从体验主线到User Journey再到三级事件的线索，有序组织和调用原子级服务，完成产品功能目标定义；
- 创新定义：通过结构化场景，快速定位单一场景或用例，针对明确痛点设计创新解决方案，并将其有效纳入到结构中；
- 产品评价：与产品定义类似，从场景库中提取完整的结构线索，形成测试用例；
可以看到企划部门是以用户为核心，应用场景库以“需求”为导向，解决的是谁在什么场合下，想要解决什么问题，期待获得什么体验的问题；应用集中于“点”和“线”，“点”在于单个use case的突破性创新，“线”在于场景叙事的结构合理和完备。因此企划部门需要围绕目标用户，准确定义体验主线，建立叙事，从而在保证功能完整、体验一致性前提下，突破痛点难例，形成竞争优势。
以智能车当前普遍提供的“小憩模式”为例，在企划工作流中，小憩模式的场景源于在用户想要在车辆维持上电的状态下（意味着空调系统工作）在车内以舒适的躺姿休息。通过场景的分解，在小憩这条场景线索下的叙事结构还需要囊括远程设置、是否按照工作日习惯自动设定、是否提醒、是否车内唤醒、小憩过程中对车辆设置的调整、结束后状态等，这些叙事体无疑在配合和呈现上需要具有足够高的一致性体验；而对单点场景需求的共情和演绎，会发现除了空调和座椅外，还需要音乐、氛围、香氛、屏幕、闹钟等的功能服务的配合来共同完成一个更具竞争力的“小憩模式”。
而对于开发部门，核心工作是提供解决方案和功能管理，达成产品目标，这里场景库的应用有以下几个方面：
- 功能目标落地：针对功能开发过程中的细节，通过体系化的场景保证功能细节定义的完备性；
- 新技术、新硬件的应用管理与效率增益：通过场景将技术/硬件内容分解转化为可“复用”的原子服务，纳入整体场景管理结构中；这里智能车对车载摄像头的高效多重利用是个不错的例子，在场景下探索如何低成本实现产品目标的达成，以场景为引擎，通过原子级服务的组合调用生成功能，进而实现更少硬件实现更多功能，这一步与企划部门的工作重合性极高，尤其在智能车大背景下，是未来企划与开发融合的契机，也是真正意义上的产品经理价值所在，这个后续趋势里会讲到；
- 场景库是研发部门的“中台”，是实现“SOA”的必由之路：场景库作为开发部门的“数据中台”，实现需求与服务、服务与软硬件之间的解耦，管理服务的组合调用关系、甚至于系统化管理硬件和解决方案；这样开发团队、技术平台和供应链体系则成为了整个研发体系的后台，保证可以源源不断的为这套系统填充血肉；
- 开发部门要解决的更加重要的问题是技术架构的可持续性，软件和功能的可生长性以及持续迭代的连续性和潜能等问题。这些都必须从最初的架构入手，否则每件事都面临推到重来就会不可持续。
这样，开发部门是以“功能性场景”为核心，应用场景库是以“功能服务”“SOA”为导向，解决的是用户要什么服务，如何解决，可能会遇到什么问题（事件），如何呈现更好的问题。对于场景库的应用集中在“面”和“结构细节”，“面”在于针对特定功能服务，需要考虑足够全面甚至是冗余的事件叠加；“结构细节”在于场景需求究竟通过何种服务和硬件性能来支撑，以及不同极限场景下对于解决方案性能标定的要求；
同样以“小憩模式”为例，为实现具有竞争力且体验一致的“小憩模式”目标，在开发的环境下，需要考虑场景“面”的完备性，如低频事件的叠加：小憩时候突然下雨，雨刷器的启动问题、后排车门/窗未关时启动小憩模式、低电量时小憩等等，最后以各功能模块形成结构细节，通过适应性的调用顺序或应急顺序，形成一致性的产品体验。
综上来看，场景库是企划确定产品目标的语境和源头，凸显了场景库的工具属性；而对于开发部门则是基础设施，是高效达成产品目标的管理体系，管理和沉淀的作用更为凸显。企划通过场景库提供准确的需求指向，开发通过场景库全面落实明确的调用关系。
几点趋势
上述存在于企划和开发部门之间场景应用的差异大概率表现在组织架构较为传统的OEM中，而对于一些领先的新势力，在组织架构上通过设立产品中心、数字化中心、产品/体验经理等方式，建立从需求到功能落地的跨界团队，已逐步将这样的差异消弭。这样的跨界团队承担了专业认知壁垒的消弭和能力边界的突破，未来这些团队将作为车企中枢，从无到有建设并管理产品体验，他们会是场景库价值最大化的实际操盘手。
另一方面，EEA中央集成，三电技术路径逐渐清晰，硬件结构收敛，同时通过几轮智能车迭代，技术硬件也逐步趋稳，未来汽车产品智能也会像手机智能一样，下车体也就是底盘会加速向最高效率的通用化结构收敛，但上车体会呈现出更大的差异化和灵活性。进而每部车适用的场景，以及从这些场景出发连接的功能和服务会成为差异化的主要方面。
因此在未来的产品研发环节中，可能将不会存在有当前普遍意义上的产品概念（细分定位、策略），也不再需要丰富的产品谱系，真正产生差异的是产品宏观尺度（基本尺寸、造型），产生价值的是微观场景概念（场景体验、服务组合范围和方式）。如同手机，将不再有音乐手机、游戏手机、拍照手机，只有尺寸造型不一、服务生态和体验差异的智能终端产品。
关注So.Car官方公众号
掌握So.Car最新观点动向
