汽车业务数据化：任督二脉与易筋经

汽车业务数据化：任督二脉 与 易筋经

（学习笔记：给熟悉工程的IT或BP的同事）

业务数据化，不是数字 表

业务数据化，不是互联 办公

不是SAP、ERP，也不是任何CRM、DMS系统

如果您也认同，一片树叶无法代替整座森林的话。

那么业务数据化，到底是什么？

四十年前

大概在40年前的百货商店，各个柜台与收银台之间的联系，都是通过上下两个铁丝线连接的。每个线上都串着几个铁夹子。

某个柜台完成一笔买卖，会在上面一个铁丝线上，选择一个铁夹子，夹上手写的发票、客户的支付金额（那时候只有纸币），然后沿着铁丝线，“嗖”的一声，铁夹子带着钱款及发票，就飞向了收银台；收银台完成收款核对，找好零钱、发票确认敲章后，在下面的铁丝线上找个夹子，再“嗖”一下送回柜台，就在这样上下两根线之间，两声“嗖”就完成了整个交易。

今天再也看不到这样的景象，但是却给了笔者业务数据化的形象基础。

任督二脉

业务数据化，也有两根线；与故事相同，一根线对内，一根线对外。

对内，业务数据化以产品为线，所有部门的工作成果皆related到这个产品端；产品是标准属性，覆盖全生命周期的，完全可以通过产品这根线（任脉），把公司内部对内的各项业务层面的工作串联起来。

对外，业务数据化以客户为线，所有总部支持部门、营销部门、产品部门、销售团队、经销商团队等全部可以关联到客户这一端。客户是单一固定属性，一成不变，完全可以通过客户这根线（督脉），把所有公司内部对外的业务团队、以及外部经销商团队等外部资源的各项工作串联起来。

以产品（任脉）为线，尝试串联一下。以产品为中心，通过全生命周期的产品时间跨度，来串联起来各个阶段的利益攸关方。

把Pre-product阶段、工程开发Pre G8阶段、工程开发G8-G5阶段、工程开发G5-G4阶段、工程开发G4-G1阶段、产品Launch阶段、产品成熟阶段、产品升级阶段、产品退市阶段 等9个产品阶段，分别让对应的专业团队，细化这9个阶段的专业性工作；把每一阶段的利益攸关方，全部囊括进来，形成以产品为中心的利益攸关方链条。

（此处，图示法 会十分明显）

核心要点：

之一，通过把业务深度细化，拆解到可以全部具体单人/业务单元 能够直接进行操作的程度；全业务链的拆解能力，是一个十分繁琐的，但是十分重要的基础工作。

之二，把业务拆解下来的单元，全部与产品进行逻辑联系的链接，建立起业务逻辑的产品化能力

之三，把与产品逻辑链接的最小业务单元，进行数据化；形成全业务链的数据化能力。

之四，把业务链的数据，以“产品”特性为唯一接口，建立起全业务链产品化的数据能力

之五，把业务产品化的数据能力，以统一产品属性（比如车型代码），在全业务链流通，形成产品化的全业务链数据流。这才是终极目的，这才算打通了任脉。没有形成数据流动，一切静态的数据，其价值都是十分有限的。

打通了任脉（产品）的内功还不能显现，必须与督脉（客户）一起打通，形成任督二脉的流通，才能发挥招式（业务）的威力。届时，哪怕是最简单的太祖长拳，都能打出降龙十八掌的威力。P.S. 牛逼的企业如过江之鲫，但提起这数据化的任督二脉，没几个企业真正能够打通的。

以客户（督脉）为线，尝试串联一下。通过客户的预知、体验、购买、服务、传播的完整行为，来串联起各业务环节的利益攸关方。（Q: is it enough ?）

把产品概念阶段、油泥模型阶段、产品评审阶段、产品OTS阶段、产品工程样车阶段、产品Launch阶段、产品交付服务阶段、产品售后服务阶段、客户关系维护阶段 等9个阶段所涉及的利益攸关方囊括进来，分别各自以用户为中心，拆解并链接自己业务链中与用户相关的部分，并各自形成与客户的内在逻辑，随客户属性变化而变化。

这里的客户是广义的，买过车的，没买过的；员工、客户、供应商、经销商、合作伙伴、亲朋好友等等，任何一个对我们的品牌、产品可能产生价值增值的人都是我们的客户。

从产品概念阶段到产品上市阶段，每个部分我们都可以有选择性的向我们的客户传递内容、促成互动、形成反馈、再形成内容传递的PDCA循环过程；不同群体，传递不同内容；这完全由数据分析的结果决定。要形成业务单元的小循环、业务链的中循环、任督二脉的大循环、乃至公司及其利益攸关方的集体大循环。

从产品销售成功到客户关系维护阶段，同样道理，一系列小循环、大循环都是必须的。此处就不展开了。

上文“以客户（督脉）为线，尝试的串联“，笔者留了一个伏笔 is it enough？笔者认为，如果仅仅考虑“客户的预知、体验、购买、服务、传播的完整行为”是欠缺的。从客户的单次销售行为看，覆盖客户购买（销售成功）、客户满意（售后服务）、客户忠诚（主动传播）似乎还不够，至少要加上“车辆转售”似乎才完满。

从客户的多次反复购买角度，则又是显得不够；汽车已经演变为一个重复购买行为的产业；而且重复购买期越来越短。我们需要考虑的不仅仅是单次的购买与服务，更是基于客户变化的需求，持续更新产品，不断迭代满足客户的过程。

业务逻辑讲清楚了，就一定可以形成数据流了吗？

数据流是一种业务透明化最高的境界，这是一种能力，一种囊括了体系、标准、流程、逻辑、市场与业务洞察、组织及人员能力洞察、业务链内在逻辑洞察 的超级能力；要做到这个能力，还需要“易筋经”。

易筋经

这是武林至宝，是各种招式能够发挥威力的基础内功；要想发挥业务数据化的威力，甚至要想打通产品与客户这两条任督二脉，都需要易筋经。

因此，笔者对业务数据化的理解，任督二脉只是阶段性目标，甚至完全不是目标；是企业在练就了“易筋经”之后的一种能力。如果说，上述故事里，上下两个铁丝线、夹子等基础设施是易筋经的话，那么上下两根能够承载发票与现金的传递、链接与流通功能，就应该是任督二脉；而销售或客户服务，就是少林长拳的招式，客户满意度与忠诚度才是我们真正的目标。

少林长拳说，欲练神功，必先…练好易筋经；那么，易筋经是什么？

是SaaS, PasS, IaaS

SaaS：Software as a Service 软件即服务

它是一种通过Internet提供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联 向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联 获得厂商提供的服务。

SaaS说成人话就是：大家所广泛见到的各种App，各种企业、个人所用的各种终端软件。

在汽车工业领域，

SaaS指的是主机厂的终端用户App吗？显然不是。

是面向市场的终端App + 企业应用的各种软件吗？ 也不是。

笔者认为，SaaS是“任督二脉”的产品、客户两条完整链条中，所能触及到的全部利益攸关方的全部终端软件应用。包括对面个人的各种 交App，面对组织的各种SAP，ERP，CRM，以及面对供应商/经销商的各种SMS，DMS等等。所有能够为终端最终user提供服务的，都算。这里的user不仅仅是购买我们汽车的人。他们类似八爪鱼的一个个触角、类似树根的一根根末梢；负责收集、整理、汇集、交互各种数据，不断处理各种小循环，同时往中台数据层PaaS不断传递与交互数据，形成一个个中循环。

各个任脉（产品）端末梢的信息都会被SaaS内置逻辑protocol转换成产品化的有逻辑数据，形成任脉的数据流。

各个督脉（用户）端末梢的信息，都会被SaaS转换成一个个用户为中心的“用户云”；单个用户所形成的数据流，都会是一个庞大的数据云。

任脉（产品）的数据流，督脉（用户）的数据云，通过易筋经的内功（PaaS）中台数据来进行交互。

PaaS: Platform as a Service，平台即服务

它是把服务器平台作为一种服务来提供的模式。即数据流、数据云，都可以在这个PaaS服务平台上，实现数据再交换，并共同获得某种新的服务。比如：涉及小循环以外的、用户的信息，如何作用给工程，只能通过中台的再处理，可以是二次数据离析得到强逻辑关联的信息，从而工程对于这样的用户信息的protocol才能识别、读懂，也才能应用。这样的服务，只有PaaS这样的数据中台才能完成。

PaaS数据中台的成功表现，即有赖于SaaS端的信息，又要从逻辑层级上高于SaaS；设计方面，数据中台需要囊括所有的SaaS终端，还要具备持续接受新的终端不断加入的开放接口。逻辑方面，数据中台既要有任脉（产品），也要有督脉（用户），不但要厘清两者各自的业务逻辑，形成产品化逻辑数据，以及用户的数据云；更要为任督二脉的延展做好准备，保留业务滚动持续的更新。数据方面，不但要形成任督二脉各自的标准化，还要能形成任督二脉相互数据交互的内在逻辑，更要基于此逻辑形成更高一层次的数据交互。

这样的PaaS数据中台，才能体现其Service之本意。

IaaS：Infrastructure as a Service，基础设施即服务

这里讲的是通常概念的基础设施，是物理的设施，属于数据处理的物理层。

这就不用多讲了吧，这一部分，有钱就行。

下一步，其实还有，如果把C2B接入进来，思考维度又要更拔高一层，那就更搞脑子了；

如果于此同时，再把每一个单一user（不是上文的用户，而是督脉全线上的user）的功能再融合、放大，形成一个无数个“蜂窝群”，代表特定时间、特定地点、特定需求、有共同标签的“ 群”；我们的PaaS都要继续降级到类似SaaS了，那就更复杂了。

（又臭又长，拗口搞脑子，还索然无味；能读完，辛苦您了！）

《自嘲》（转）

本是后山人，

偶做前堂客。

醉舞经阁半卷书，

坐井说天阔。

大志戏功名，

海斗量福祸。

论到囊中羞涩时，

怒指乾坤错。