0%

从主数据谈程序设计思想

在企业应用中,主数据的边界往往被无限扩大,违背程序设计的单一职责原则。它犹如全局配置文件,违背面向对象的思维框架。为什么会这样?因为

在程序设计中,有一个矛盾——用户视角与系统视角的矛盾

  • 用户视角,要求一站式服务;
  • 系统视角,要求单一职责。

认识清楚这一点后,问题就迎刃而解了,把「一站式」服务看成是一个独立的职责。这一点上,程序设计和企业经营、营销思想上是一致的。营销中有个非常重要的思维是站在用户的角度看企业,它与经典的4P理论并不冲突,但恰到好处地补充了从「连接」的两个角度去思考问题。

何为主数据?

在公司现有CRM模型中,ER关系如下:

  • 一个客户下有多个项目。比如中国移动是一个客户,其下有若干项目,包括劳保项目(用于给网咯线路维修工人,采购工作时需要穿戴鞋和手套等)、办公项目(办公室工作人员需要签字笔和写字本)、员工福利(逢年过节的要给员工发放月饼粮油等)和市场营销项目(为答谢合作方赠送诸如戴森吸尘器等小礼物)。
  • 每个项目都要签订一个合同,即项目与合同是1对1的关系。合同电子化信息是纸质合同的一个子集。比如纸质合同约定的内容包括折扣价、年终返利、企业信用卡额度、还款日和还款周期、逾期罚金、运费减免额度、履约时效承诺(下单后多长时间内必须发货,发货后多长时间内必须到货)等等信息。这些配置信息被称作为合同主数据
  • 一个合同下可挂载多个B-PIN,单一个B-PIN不能隶属多个合同。B-PIN是企业账号的意思。B-PIN可以理解为中国移动采购部门的采购员,一个员工福利项目,在客户方也需要多个人运营,比如需要配备多个采购员、一个审核员、若干领导、一个会计等。注意: 这里还并没考虑,一个员工福利项目,在我们商城内部的运营,至少也有客户经理、商务经理、若干运营专员(负责对账开票等)。

image-20190910231957526

  • 何为主数据?就是客户层级、合同层级、B-PIN层级等各层级的配置信息的总和。

  • 层级冲突的仲裁机制? 同一配置项,在不同层级的取值设置可能不一样。比如“是否支持7天无理由退货”,在B-PIN层级设置为支持,在合同层级设置为不支持,在客户层级又设置成支持。 该如何决策?无外乎遵循两种原则:

    • 习俗原则: 像习俗一样,讲究入乡随俗。即低层级的配置覆盖高层级的配置。
    • 法规原则:像法规一样,讲究服从宪法。即高层级的配置覆盖低层级的配置。

image-20190910233934943


主数据的边界?

程序设计中,有一个矛盾——用户视角与系统视角的矛盾。

  • 用户视角: 用户需要的是一站式的服务。拿小汽车打比方,用户需要一个驾驶舱,里面有一站式的仪表盘和各种操控按钮。要汽车倒退,只要挂个倒退档位;要开左转向灯,只要向下扳下车灯操控杆;要知道轮胎的胎压,只要按个按钮就显示出来了。用户操作这一切,并不需要知道当扳下车灯操控杆时,指令是如何传导到转向灯的。
  • 系统视角: 系统设计讲究单一职责,讲究解耦,讲究每个部件只实现一个高度内聚的功能,它封装了数据状态和操作数据的方法。然后再通过协同组装的组合模式来实现一个更复杂、更系统化的能力。还是拿小汽车举例,汽车行业是个供应链高度整合的行业,一辆汽车的部件涉及许许多多供应商,比如变速箱是供应商A的,转向灯是供应商B的,它们都是独立设计,并不知道汽车生产商未来要选谁的驾驶舱或仪表盘,它们也不需要管,彼此之间只要遵循一个工业标准就好,只要符合这个工业标准,各家供应的部件就能最终被整合起来。

主数据是什么呢?它是一个全局性的配置文件。这是违背面向对象的设计理念的,它是面向过程的产物。在面向过程的程序设计中,剥离了一个全局配置文件,然后所有的模块都要读这个全局配置文件,依赖这个全局配置文件。然而面向对象的设计,要求各个模块能够自治,每个模块都是一个对象,每个对象都是数据和方法的封装体,即谁拥有数据,谁就应该拥有对数据的操控权,别人需要操控这个数据,需要把请求委派给它。面向对象的程序设计,一方面强调自治和封装体,另一方面它又该如何化解跟用户视角的矛盾呢?这就是Facade设计模式。它专门解决系统集成问题的,它是流程的组织者,发挥承前启后的作用,对内整合各个模块的资源,对外面向使用方提供一站式服务。示意图如下:

微信小程序就是驾驶舱

微信是国内DAU最高的APP,也是用户使用时长最高的APP。微信小程序也成了触达用户非常好的一个载体或说渠道。我们会看到美团有微信小程序、京东有微信小程序、顺丰有微信小程序、韵达有微信小程序……。微信能给用户一站式的服务,但是我们有没有想过,美团、京东、顺丰、韵达等等它们诞生的时候,微信小程序还没出来呢。而不是像主数据那样,先定义了主数据,然后各个子系统都读取主数据的内容,依赖主数据去构建自己。恰恰相反,按小程序的理念,在电商体系,应该是先构建商品子系统、账户子系统、订单子系统、履约子系统、售后子系统、财务子系统等后,再构建一个一站式集中管理的主数据系统或CRM系统。

不对!认识到这点还不是小程序思想的全部,刚才我们还仅仅澄清了先有主数据还是后有主数据的问题。关于怎么建设一站式集中管理平台,我们还跟小程序有差距——我们习惯让一站式集中管理平台去整合其他各个子系统的资源,而 小程序是只定义好接入标准,让其他子系统自己主动整合进来。小程序靠什么做到让别人主动凑过来?靠触达,靠触达用户的优势,靠用户对它的喜欢。其他子系统一旦接入了微信小程序,就意味着离用户更近了一步。因此其他子系统会自发的接入微信小程序。

反观我们日常所见的,各公司的ERP集成也好、BOSS(Businesss Operational Support System)集成也罢、还有企业运营门户等诸如此类的一站式集中管理平台,绝大多数都经营错了它的核心定位,它应该像小程序一样,只经营触达,经营面向运营人员的渠道,并定义好接入标准,子系统会为了推广它们的新功能主动接入集成平台,集成平台会因为整合更多的子系统不断丰富它的服务生态。

分布式系统的其他集成

前面我们讲了一个企业分布式应用,为了一站式运营管理的需要,在后端对运营人员会集成。同样的,在前台对消费者用户也需要集成,用户只关注他能做什么,并不关注系统是分布式的,还是单体式的。

以京东商品详情页的放心购为例:

业务上它是一种营销手段,通过物流侧的运费、售后侧的7天无理由退货等多个功能服务组合,建立「放心购」品牌形象。这个品牌信息,集成了物流和售后等系统的信息。

再如评论,在搜索里面集成。商品的信息是在商品系统的,商品的评论是在评论系统的,但是在搜索里面,可以按「好评优先」来排名,这样搜索至少要整合「商品」信息和「评论」信息。