|
在《移动互联网生态系统解剖（上）》中，我们已经谈到了移动互联网的服务，分别从移动互联网的情境化、随身性、参与力三个方面进行了阐述，本文就试图将移动互联网的生态体系分为四个层次：技术层、资源层、应用层、服务层，以此出发来梳理对移动互联网的认识，以及车联网的应用。作为目前尚处于应用层的车联网，本文也将探讨如何向服务层升级。 服务层：方案智能，流程定制 服务要做好，需要一个完整的生命周期，并且各有关键之处： 一、服务启动前，找到解决方案 这里有两个关键点：更精确地识别意图，就是知道用户想要什么样的而结果；达到同一个结果可能有多个方案，需要根据用户的条件、偏好，根据服务的能力、资源等进行选择。 解决这两个问题，需要：
比如，在凯迪拉克故障解决案例中，车主在去机场的路上发动机自动熄火，那么解决方案可能是：通用服务商派一个高级技师和一辆凯迪拉克到车主顺路的汽车修理店会合，车主开走派来的凯迪拉克，从机场回来时他的车将修好，再开走自己的车；可能这个修理店不是通用的4S店，但是能提供修车场所、维修工具和修理技师。 二、服务实施时，过程能够无缝的衔接 关键点是：服务不是按“内部管理的流程优化”来驱动的，而是按“外部需求的流程定制”来驱动的，人员和计算机系统都需要适应这一变化。如果是多服务商时，通常会有一个主服务商，对从服务商的服务，采取联合、打包或分租等模式；比如上面的非通用4S店。 三、服务结束后，形成反馈。 应用层：随用随有，无缝对接 在解决问题的服务中，需要把多个应用对接在一起。比如在解决上述汽车故障的案例中，要把故障分析、导航、呼叫、远程诊断等多个应用组合起来。 这其中需要完成两部分工作：
首先是提供图谱。可以是目前各大平台（腾讯、UC等）的目录式结构（树形结构），也可以是P2P模式那样的网络式结构。其次是发现图谱中所需要的应用，除了现在的关键词搜索，搜索还应支持情境、以及未来大数据的智能。最后是集成。应用不管是Native式还是Web式，都应该在安装、界面、网络协议、输入输出上很容易集成在一起，或者使用同一个规格，或者能转化和匹配。 从应用层面来看，目前的车联网，一方面已经朝着服务在做，另一方面平台化才刚开始。因而，车联网中的服务，将主要是定制化方案。或许，我们将很快能在福特、宝马、通用等车联网平台上，使用到这样的服务。 资源层：乐于分享，状态可控 资源分享的案例，在《车云会沙龙头脑风暴：中国出行进化论》中，易到用车创始人周航的象限图，是非常典型的。第一维度是使用权，分为使用权转移和不转移；第二维度是服务者身份，分为B和C，由此组合成了四个象限。其典型业务分别有：出租车拼车、汽车租赁、搭顺风车、私车租借。这都是分享的不同方式，依据不同的维度来做划分和组合。比如，同样的业务，可以把拼车作为空间上的分享，把租车作为时间上的分享。 再如在汽车故障解决方案中，给车主暂用的凯迪拉克车，将发生使用权转移为分时模式，非通用4S店的场地、工具、技师等，也都属于不同的分享模式。 正如《车云会沙龙头脑风暴：中国出行进化论》中所顾虑的，资源分享后，可控性成了关键，是否涉及车辆安全、政策法规、保险模式等，这点至关重要。另外，状态可控也包含解决资源共享时的资源冲突问题，比如非通用的4S店是否能最快地提供场地、工具、技师等。 还有更高效的办法。例如，E-Service并不需要派一个技师，只是一个普通司机带上零部件就可，到4S店后，由这家4S店的技师，连接通用的测试系统，与通用高级技师视频沟通，然后就可以修复好故障车了。这种方案，也包含一种资源分享，那就是在线测试系统、远程视频等信息资源的分享。 通过信息资源来解决实体资源、人力资源的问题，正是ICT(Information Communication Technology)带来的生产力。实体资源的复制要消耗生产成本，即使像汽车租赁这样的分享模式，也会加快实体资源的损耗，而且越用价值越低。人力资源则不可以复制，分享也只能在有限的时空之内，是成本增长、有限范围内增加使用会增加价值的样式。而信息资源则完全不一样，其复制和分享可降为零成本，使用越多规模越大价值越高。通过信息资源来转化实体资源和人力资源，将带来根本性的变化。比如通用高级技师，比如私车租赁。 技术层：开放互通，云中计算 虽然信息资源有着降成本涨价值的能力，但是，它与业务存在着双重矛盾：第一点矛盾是只有业务多、业务使用多时，信息资源才能发挥效能；第二点矛盾在于某些业务创新之时，ICT往往跟不上节奏——这是因为ICT系统的建设（在信息资源与实体资源、人力资源、价格价值之间建立转化关系）并不能快速成行。技术层面需要突破这两个问题。 在移动互联网方面这点有大量的应用，比如许多第三方应用，都利用了微博API、微信API。而车载互联网也开启了这样的进程，比如福特Applink、通用Mylink。Applink已经集成国内的多个应用，这些应用之前已经在iOS、Android的手机上广泛使用；福特进一步开放了其Applink API，将有更多的已有应用移植过来，甚至也会出现福特专属APP。开放互通的技术层，也有助于解决业务量的问题。尽管iDrive不像Applink这样向外部开放，但是在技术层面上，其技术体系也可能是开放结构，以助于宝马保持创新步伐。 前文之所以拿凯迪拉克的车辆故障解决方案为例，是因为E-Service在信息层面及4S店内服务上已经打通了车机Onstar、手机My Cadillac、4S店系统。而要达到本文中假想的服务流程，下一步则需要更深刻更广泛地转化其业务和流程到这个大系统上，之后再打通与外部系统的信息及业务（比如非通用4S店）。 虽然通用走在前面，或许，还未公开的、与微软云合作的丰田，会再次后来者居上。云计算代表着目前ICT的最快建设方案，这种快速不仅仅在于更快地获得计算资源和部署系统，更重要的是，它将支持企业从“流程优化”改革成“流程创新”。 从应用层向服务层升级 目前车联网，大多停留在应用层面，以解决汽车故障为例，包括：故障分析类的应用，告诉车主这个故障是什么、起因等；导航应用，可以查找到附近的各种修理店的位置和电话等；车机系统（如onstar），可以使用厂商的在线服务。 虽然可以把这些APP提供的信息综合起来找到解决方案，但是找到和安装这些应用是个麻烦；通过多种信息来找到方法，也不是件容易的事；怎么实施解决方案，遇到问题如何解决，更是未知。 因此，需要新型的应用来解决这个问题。 简单的方法是定制方案：针对车主的问题，做一个服务类APP，把这些APP（或功能）、客户及其车辆、服务商的资源等连接起来。但这也不是容易的。即使如目前的花了大代价的凯迪拉克的E-Service，已经把手机APP、车机与4S店系统对接在一起的，也难以在线地、临场地、快捷地给予解决。 虽然定制化不是容易的，但是，从更深层的服务层生态链的角度，这种方法还不能够形成“生态”自适应地解决新出现的问题。生态链的自适应方案应该类似以下这种情境：
关于自适应方案的更详细内容，可以参考《互联网周刊》2013年6月5日总第545期的《将要浮现的A2A模式》，据作者姜奇平估计：自适应方案将很快出现在微信等这样的移动互联网的大平台上。 服务层生态链的这些要求，需要生态链的各个层的配合。
车载互联网应用层升级服务层多角度分析 车云小结：车载互联网生态链将以服务为核心 车载互联网（笔者杜撰的名字）与移动互联网，是存在交集的；车载互联网也有着情境化、随身性。当然，由于汽车占用人们的时间不多，情境化的范围有限；也由于汽车行驶位置的限制，信息采集的范围不灵活。这催生了手机与车机的相互融合，但是在业务上，二者既有区别又有衔接。 手机最先是一种通信工具，上网功能使其成为一种信息工具，而移动互联网的快速发展则将它演变成了服务工具。车载系统由于与汽车的绑定关系，它首先是一种出行工具，车载互联网也能使得它成为信息工具和服务工具，但是，正因为出行的限制，其信息工具的作用有限，而服务工具的能力，更应该突显在与出行相关的方面。载人载货出行，应是车联网服务的关键所在。例如导航提供出行服务，出行之前，存在着找一辆车、以及与这俩车的交互等问题；出行之后，同样存在车的使用与管理需求。另一方面，汽车的多样化，以及将来车的能源的多样化，也将衍生更多服务，比如房车所带来的吃住行、电热能等的结合问题。 借助目前的移动互联网，车载互联网将有效地构建一个生态链，并从目前的应用层面升级到服务层面。 |
|
|
相对于传统互联网、移动互联网而言，或许我们可以将当前通过车机、手机而来的汽车联网称为车载互联网。车载互联网，是车载娱乐导航系统的进化，将提供更多的联网能力，比如车况、通信、车机与手机互通等。
