方法论：业务系统的技术架构(3)

职场上，大家不同的能力，薪水，岗位，最终都会不同程度成为解决不同问题的人。对问题没有感知，对结果没兴趣的产品技术leader，百分百就是废柴，你就是问题本身。这个说起来,就是职业规划和价值观了，不多扯。

六、数据运营

这张图，照搬我一个旧同事的PPT，至今没见过用一页纸把数据解释得如此清楚的

前面说到运营驱动，运营离不开数据。一般的公司， 在一定规模前，暂时都达不到数据运营。

不是说数据不重要。 数据能起到的作用，分三个阶段。这三个阶段简单的说就是发生了什么（报表），为什么发生（数据分析）和将要发生什么（决策支持）。大多数互联网公司，包括那些上市的，其实还没解决业务发生了什么，对，说的没错。别看这么多互联网公司，包括很多上市公司，每天到底多少线索，多少订单，各种转化率，真的没谱。各团队口径差距巨大，这是大概率事情，国内也就BAT（京东，滴滴，美团不够了解）的主营业务算是数据过关。

为什么会产生这样的情况，我们明明人人都在说数据多么多么重要的废话。我理解，这不是技术问题，其实是管理问题。各部门的KPI都是摆设，没有人真正对数据结果负责，比如成交率下跌了两个点，有人会因此离职吗？ 没有，那也就没人去啃那些对不上的数据，各部门数据差异越来越大，在第八章会再次提及。

而这页PPT真正解释牛的在右侧部分，数据正在发生什么和我期望发生什么，这比较超出我的能力， 不解释了，O(∩_∩)O哈哈~

1. 决策人员：决策者、高层管理者，通常只是用送到手中的极简单工具，极少自己分析
2. 分析人员：业务管理者、专业分析人员利用商务智能各种工具向决策者制作数据内容并解释数据含义
3. 一线人员：一线业务人员，利用工具向管理者固定汇报业务状态、进行少量分析

七、什么是CRM

1. CRM的意义是实现收入可预期的最大化

并且可有计划的提升预期。无论什么样的CRM，都是为了营收，这没啥可掩饰的，没有哪家会为免费用户花力气做CRM。

2. 重点是提升人效

客户开源和提升高质量客户的UP值贡献，理论上是管理问题，是运营策略问题。我们 所有CRM的参与者，重点是提升人效。人效，就是人均卖多少商品或人均贡献多少收入，是考核团队首要的KPI。 这里的人包括销售，运营，客服，产品和技术等。

3. 提升人效的路径，就是让机器承担更多的工作，即“服务数字化”

• 标准化，标准化是数字化的基础，计算机只能保存离散的数据，所以标准化的核心是离散化的信息结构化。比如：建单、工单、分配等。
• 自动化，自动化指的是动态过程的数字化，比如流程、规则、权限控制的数字化。“动态”意味着各种存在依赖关系的元素互相之间的状态关系。
• 智能化，直观的理解就是让系统具备思考能力。这意味着系统在比较确定的上下文中具备分析能力。

我在公司时候讲解CRM，常常用比较得罪人的逻辑解释。我说，CRM的理念就是通过标准化操作，让销售和运营平庸化，所有销售业绩差异不应该过大，如果有销售总是远远超常发挥，那说明我们的业务模式出了问题。哈哈，比较得罪人，但是这套理念也适合技术团队。。。

八、业务系统架构实例——横向共享的架构设计

复习：技术架构就是指把不同的功能元素（系统）放在适宜的环节、合适的层级。

公司的CRM应是面向企业不同运营单位的业务系统，会覆盖售前售中售后多个系统集合。我们讲技术架构是系统之间的关系，那如何建立这么多系统之间的关系？

这里讲一下一种技术架构案例，横向共享的设计。你的系统里，那些信息和信息的变化是其他系统关注的？？？

一般交易类业务有三种东西，可能是贯彻公司各业务线的。商品，客户，订单，尤其是前两种。商品和客户的信息保留在多个系统里，面向的也是企业内不同的运营单位，甚至第三方公司。

以商品为例，一个商品从采购仓储直到客户手里，生命周期可能几天到个把年。有负责采购相关的供应链部门，有负责营销的销售部门，有负责物流运输部门，还有售后等其他部门。这么多部门，对应着诸多的系统都有商品相关的信息和状态。

某个系统里，商品的状态信息变化了，其他系统如何第一时间掌握，并及时作出对应动作？？

比如一个简单的问题，商品成交了退订退货等事件，其他相关部门怎么知道呢，然后做相关处理，靠各系统间API调用？？只要业务跑两三年，保证各系统间的API成百上千，

我之前供职的一家公司，上万的员工，有个有趣的现象。供应链部门负责商品采购验收和上架，公司网站展示相应的商品。但是，二者数据长期不一致。能有多不一致？说出来吓死人，有四分之一的商品状态几年来一直对不上，每每想起，赶脚都会被人笑死。

为什么会产生这样的情况? 因为供应链上架是API通知网站以及各部门，其他部门销售了，退订了商品等也是API调用供应链和网站。也就是各系统啥都是API调用。同时什么是上架，下架和成交，各系统定义都不一致，并且API调用不够稳定，又缺乏监控，也就是第五章说的产品技术都完全没有掌握业务结果的意识。。。

理论上说， 如果各系统自身足够强壮，系统间通讯严丝合缝，指标定义清晰明了，那什么问题都不会有，根本不需要做横向共享，不需要搞什么辅助设计。但这几乎是不可能的.

要明白，除非系统上线后永不升级，否则一切都是逐步演进的，日积月累差异会大的惊人

建设主数据，采用横向共享的设计取代系统间API调用的网状依赖。

主数据能做什么，一般主数据的输出是客户或商品全景视图，所有业务系统将有跨业务系统需要的相关信息同步到主数据，并从全景视图获得其他相关的数据。

主数据真正实现各个业务系统的打通

主数据通过统一的数据采集，数据存储，数据管理，需要足够的产品认知能力和全局业务意识。

主数据对外提供的是统一的信息查询和信息变更服务订阅，这里技术实现其实并不复杂，也就是ES和MQ。

例如，销售系统通过主数据的“商品变革信息订阅中心”的信息订阅获取供应链上架的商品后，而供应链和售后等系统通过同样的订阅中心获取商品是否成交的信息决定商品上下架等操作

（编辑：ASP站长网）