讲故事能力 ｜ 如何介绍一个企业软件
在ToB软件领域内创业的朋友给我介绍他们的产品，我有时会看得摸不着头脑，很难一下子理解：这个产品究竟解决了什么问题，在同类产品中有什么独特之处，如何衡量其价值以及根据其带来的价值衡量其价格。
我曾经写过一篇“讲故事”能力的重要性的文章《讲好一个故事 ｜ 我们急需提升的能力》，本文展开谈谈如何讲好一个企业软件的故事。
讲故事的有效性由三部分构成：叙事方式、支持数据和视觉效果展现。
除了获取数据源以及优质的PPT视觉效果外，我来重点讲下叙事（narrative），叙事就是把一件事情讲清楚；把事情讲清楚需要根据听众对象，合理组织相关信息的内容、结构和进程。好的叙述进程能使听众与叙述者情绪同频，有节奏感地被叙述者“带着走”。中国古人讲写文章要有“起承转合”，不能“平铺直叙”；而在文学写作中，叙述结构的技巧称为“故事弧（story arc）”，下图是一个典型的故事弧，横轴是时间维度，纵轴是冲突紧张度：
我们做PPT时就要形成“故事弧”结构，亦即“故事线”。怎样做PPT的“故事线”（story line）呢？最简单的方法就是：你把你的一套PPT的每张片子的题目抽出来，把文字拉通读一遍，就是一段完整的故事叙述。你可以自己把这段串起来的文字通读一遍，看看文字是不是通顺，是不是完整表达了想叙述的内容。
在叙事内容上，介绍企业软件时，需要根据不同的听众对象来组织内容。我觉得有三种内容模式：
一、解决方案介绍
针对听众是非技术人员或者深度专业用户的业务领导、普通用户、购买决策者、行业专业人士，主要介绍目的是产品销售、理念推广等。
这种背景下的故事，故事内部不能太技术，也无需过于纠缠业务细节或方案细节。另外，很多讲故事者有个误区——喜欢展示摆了很多块块线线、非常复杂的架构图，实际上这对于促进沟通的效果并不好。
解决方案内容框架一个很好的参考是咨询顾问常用的叙事框架：SCQA，即“情景-冲突-问题-答案”的结构化表达方式，这也是一种典型的假说驱动的问题解决方法（hypothesis driven problem solving）。
例如，我们介绍一款供应链计划软件，可以采用这样的故事线：
- 情景：消费者需求越来越个性化，趋势难以预测；需求端：销售渠道越来越复杂，线上线下相结合；供应端：制造和供应链正在数字化转型。企业数字化转型需要有供应链计划工具来衔接、指导和优化产销执行体系。
- 冲突：市场上虽然已经有供应链计划工具，但是不适合全渠道销售模式；此外，技术架构比较老，运行性能慢，还缺乏先进的人工智能算法，计算准确度低；该类系统由于技术复杂、对数据可得性和准确性的依赖程度高，实施周期长、成本高，用户接受度低，因而实施成功率也较低。
- 问题：目前符合市场需要的供应链计划软件能否解决全渠道计划整合的问题？怎样利用新一代技术架构，利用人工智能技术？如何保证实施成功率？
- 答案：ABC软件的技术架构、应用功能具有这样一些独特性……常见实施风险和相应的应对方案……实施ABC软件给企业带来的价值提升估算。
二、软件产品介绍
针对听众是技术人员或者深度专业用户，介绍主要目的是对产品能力的深入评估、讨论实施计划和实施策略等，应该基于企业应用软件（而非基础软件）的特点，即采用标准化的技术或功能，面向用户交付可用的数字化产品，来叙述软件。
企业应用软件的构成是由系统原子——数据，到系统宏观——架构等四层构成的，例如：
- 数据：客户、商品、地点、类型、价格、交货周期
- 对象：销售订单、商品分类、产销计划
- 功能：订单处理、门店商品组合管理、产销计划管理
- 架构：包含完整功能的销售模块、计划模块，和周边其他系统的集成关系
系统从规划或者实施来说，是从粗到细的过程，而从开发或者实现来说，则是从细到粗的过程。我们在讲产品故事时，可以采用这两种顺序中的某一种，无论哪一种都符合技术人员或者解决方案人员的思维方式。
我自己过去参加先进的大型企业应用软件培训时，培训课程的叙事方式基本都按这样的逻辑框架。现实中，我观察到一些不太好的叙事方式，例如直接跳到功能细节描述，缺乏对数据全貌或架构全貌的理解，又例如有些产品叙述是从流程或者用例角度出发，有可能恰恰说明了该产品缺乏标准化的功能包装或者灵活配置的能力。
三、用户体验介绍
针对听众是非专业的最终用户，用于使用推广、用户增长，或者面向用户的销售，可以使用基于业务流程的用例演示介绍，或者基于用户旅程的直觉式体验介绍。参见《从采购流程数字化案例谈人性化设计和数字化产品的方法》，本文不赘述。
欢迎预约明天的直播节目