全渠道零售中台与数字化转型(2)-从“业务”角度看数字化转型与中台的实施

前言

        这篇文章其实是第1篇的补充，因此很多内容在上次第1篇里说过，只是这边用业务的角度、CTO、CIO、甚至是时下最流行的CDO、CSO的角度去理解第1篇中的为什么要采取那些技术上的点。

• 假设你是一个刚踏上XXO岗位的新人，那么你会发觉这篇文章将成为你未来职业人生的引导；
•  如果你已经在XXO岗位了而你正陷入一些疑惑、困惑时你会发觉这篇文章为你理清乱绪提供了“排查入口”；
• 如果你是一个从互联网进入一些传统大型零售企业的XXO，你也同样会发觉该篇文章是一篇帮助你“生存下去”的宝典；

        为什么这样说呢？因为，我们以结果为导向，本人目前成功完成了两个千万级投入零售中台项目的落地，曾经成功指导过每年耗资上亿 RMB的数字化转型。为什么可以成功而不是像目前外面很多“见光倒”、“项目未上线XXO就走人”呢？那么我都把它列在了这篇文章里了，这里面有“心理、博弈、策略、技术、沟通”等综合因素的运用。

        因此你们也可以把这一篇当作是“XXO防被割韭菜宝典”，因为被割多了“韭菜”，最后被割的就一定是你的“人头”。

从12年前我国开始进入电商谈中国零售IT的变形过程

        我第一次踏足零售行业是2009年当时我们正在做某知名运动品牌中国区的在线购物网站。那时我们用的是Oracle ATG eCommerce Suite套件。那个年代中国的零售还停留在：线上叫电商、线下叫零售这么一个概念。当时国内也没有出现“新零售”这个概念，因此那个时候如果要把线下的零售搬到线上目的只是为了扩宽营销渠道而己。那么在当年国内ALI，JD系的技术能力还没有完全成熟时当一个传统企业需要快速把业务推到线上只有依靠一些国际一线大品牌IT软件供应商的成熟套件，如当时世界上最著名的：Oracle ATG eCommerce Suite与IBM的Websphere eCommerce Suite。当然在当时还有一个Sibel，不过它是偏制造业。那个时候国外还有三个“非套件”类架构也可以帮助到一些“垂直品牌”快速的建立起自己的门户型网站，它们一个是magenta、一个是sitecore、一个叫salesforce，这三个都是SAAS类解决方案。

        当年的这“五大”曾经因为一些“500强企业”的推崇，于是在业界第一次推出了“multi channel“这么一个概念即多渠道系统。它们曾统治过业界一段时间，这个时间是从2009年到2013年。时间很短暂，乃至至今这五大几乎已经消声匿迹了，只可谓是昙花一现。从2014年开始以ALI系为主提出一个叫全渠道的概念即”omni-channel“，以银行IT团队为首也提出了一个”大后台“系统的概念。这两个概念并于最终在2015-2016年形成了”全渠道数字化零售中台“这么一个东西。同一时间，在2014-2015年业界开始出现了新零售的苗子。

        那么我们先来谈一下为什么会出现”全渠道“这么一个东西吧。它的出现是因为以下3个原因：

1. 曾经的大卖场以家乐福、大润发为代表的线下流量入口出现”租金上涨、用工涨价“导致了反向把这些成本分摊到了那些入驻进大卖场柜台的供应商的成本上，这也就造成了大量的“同质化竞争”。同时，随着淘宝连续4次的双11大促彻底改变了中国人的消费习惯，整个线上流量的入口远远超过了线下这些曾经传统大卖场的流量；
2. 随着线下大卖场这种曾经的流量入口的逐步萎缩，越来越多的品牌商思索着用这么昂贵的”入场会费“同时又”买不到越来越多的流量“，因此这些品牌商开始谋求变革；
3. 09年开始出现的”五大“即ATG、WebSpwhere eCommerce、magenta、sitecore、salesforce它们都是“500强体系化”的东西，因此它们都会绑定“商业版”的一些内容同时它们的诞生也并不是在中国的本土，因此在价格和性能上出现了水土不符。那么我们知道中国在10～18年这8年间出现了一个名词叫“人口流量红利”。为什么会出现这么个“红利”呢？咱人多地广呗，那么本来设计面向的只是一个把传统的线下零售整合、装璜一下推到线上却从未想到因为我们人多、业务模式多变、大并发高流量。如果为了满足模式多变、大并发高流量这些点，那么这“5大”就必须大规模使用大量的商业套件同时还不一定达到国内动不动就是千级、万级、十万级每秒并发；

        所以，在当时以一些国际上著名的同时在中国已经“深耕”了近20年的FMCG（Fast Moving Consumer Goods - 快速消费品）企业为代表，它们开始在深思这么一个系统的诞生，我有幸在当年参加了类似的研讨会，当时大家讨论的主题其实很简单，为以下几点：

1. 首先，我们需要一个“开放的、可以随时快速响应中国特色的、多变的业务模式”的这么一个架构，它要可以随改随用。对于需求的变更不需要走很漫长的“大厂（当年的大厂）式的cr ticket流程“，它要足够的灵活和open；
2. 其次，我们需要一个“可适用高流量大并发”的互联网化的平台产品，如：淘宝平台；
3. 再者是，我们需要的“平台”可以提升消费者的购物体验，在各个销售渠道（网店、实体店，包括官方网站、社交媒体平台和移动设备）上提供一致的产品、顾客服务和信息；
4. 在日趋严重的“同质化竞争”中，以“技术”手段来取得最终用户的差异化需求、精分客户、投其所好的“不对称”竞争优势从而跳脱打折、打折、再打折或者是类似我比你叫卖的更低这样的怪圈；

        围绕着以上四个点，我们分析了传统的电商类软件，发觉了以下这些“痛点”：

1. 架构设计过重，特别是如一些商业套件甚至要求用“小型机”，不利于随改随用、无法相应快速的业务变化；
2. 底层架构设计根本没有考虑到高流量、大并发的场景。或者说为了支持千级万级并发，企业需要付出的成本与收益“不对称”；
3. 系统的数据流、存储方式、甚至是交互即我们说原来的、旧有的这个业务模式无法解决我们上面的“业务痛点”；
4. 前端的一个页面的改变就会影响到后台改一堆的代码、配置、全回归测试，而这一切都仅仅是为了改变前端的一个展示问题；
5. 传统零售商们的legacy系统太老旧、太重，用的都是“银行、保险”类似的“强校验”核心系统，根本无法支持2012、2013年后开始出现的一些特别是API化的功能，因为这些系统用的都是FTP、EDI、SOCKET通讯机制。而对这些系统的改造所付出的成本足以“重建”一家零售公司了；

        以上的这5个传统软件的痛点结合着当年淘宝轰轰烈烈的去IOE得到的显著成功，于是业界把我们前面提到的我们希望能够有一个系统，这个系统我们一开始对它进行了一个定义（我们把它且称为“定义1.0”）即：高度集成化、去legacy、用户界面逻辑与业务逻辑可以相结合并且可配置。

        这个定义在当年新起的微服务概念到落地到普及的过程中进一步的演变成了“定义2.0”，即：我们能够希望有一个系统，它是后端legacy业务逻辑的上浮、前端用户逻辑的下沉。

        于是，全渠道中台omni-channel就这么诞生了，我们现在又喜欢叫它称为全渠道数字化中台。

        非常巧的是，在中台这个名词诞生的那一年，传统线下零售如：大润发、家乐福这些20多年来的业务模式也走到了尽头，因此结合着“中台”的理念新零售的概念开始普及。

        中台不等于新零售，新零售一定包含着“数字化中台”。

        如何理解2014，2015年传统大卖场模式的衰退和新零售的新起呢？我们用比较白的话来说一下传统零售和新零售的本质区别吧：

传统零售	新零售
经验产品组合，推式供货，计划生产	按需组合产品，最优供应链，智能制造
线上线下割裂、渠道割裂	线上线下随时随地，零售即体验服务
模糊的消费者画像，对消费者的观察角度颗粒粗糙	数字化消费者，并且可清晰辨识和服务，网状互联消费者的“画像”

        这三个区别就是传统零售和新零售的本质区别，如果我们用一句白话来形容传统零售和新零售那就是“从坐商到走商”的质的区别。

从2016年开始业内很大零售巨大转型出现“大象转身”、缓慢的原因又是什么呢？

        其实这里面深层次的一个道理在于以下这么一条“链路”：

        曾经的那些巨头都是国际知名名牌，它们来到中国时用的是20年前，30年前国外总部的那套重型的我前文提到过的类似于银行、保险的核心系统架构。这样的架构有5个地方对企业形成了阻力：

1. 第1个点在于：全部软硬件清一色”名牌“化，什么CISCO、什么ORANGE，特别的贵，这些东西已经运行了20年、30年了。而往往这些零售巨头在90年代初中期进入我国时拿到的也是最优惠的政策和大块的地皮，因此开设了上百、上千家店。这些系统都是我说的甚至连WebService都不支持更不要说接口API这些东西了，很多都是socket、FTP、EDI通讯，有的甚至还是单片机，但真的很贵！动辄就是上亿美元、欧元这样的规模；
2. 第2个点在于：制度问题，这些曾经的巨头他们和我们国内的BAT一类的互联网化的企业不一样，在国内我们国人是把中国本地就作为了将来辐射全球的总部来看的，所以对国人来说在这片土地上发展零售那可是无任何退路的，这片土地就是我们的大本营！而这些曾经的巨头对于他们来说中国只是一个全球项目中的"country"，来这边任职的历任CEO都是“职业经理人”，而不像我们本土化的都是“创业者”。职业经理人最最致命的一点那就是“看重KPI、看重稳”，而不是想着创新。如果你和他们说“我要改这个、改那个，要多少刀、多少欧”，那职业经理人心里想着：你改完，1-2年了，再过2年我就得回国了，这对我有什么好处？在我任期内还要花这么多钱？我的KPI还受影响、我的年终奖也依赖着我的KPI呢？这是我经历过的大企所遇到的在数字化转型时职业经理人典型的思想，有时甚至一个领导层都是充满着这种想法，因此在国内一些显而易见的道理在职业经理人面前就要转化成不断的说服、再教育、甚至是要从0开始的“培训”、再转化成上千页上万页的数字去说服，这也是为什么我们中国人可以在10天内造一座“火神山”，而美国修缮一座桥要用3年的道理，太多的bla bla bla！
3. 第3个点在于：企业“内耗”。在国内如果一个创新点子被大家接受好，从上到下高度统一思想全心全力的付之于实施，在这些“大巨头”内我们知道国外总部往往会派若干个“O”来国内任职，领导班子一级全是老外，然后老外当然也要培育自己的势力，这就在企业内部形成了一个个的“诸侯”，这些“诸侯”都有封地。我的是“财务”、你的是“HR”、他的是“电商”。现在电商要做一个项目要动到我的财务？对不起，我的财务有我自己的供应商、有我自己的体系，你的东西哪怕再好我说不能碰就不能碰？有人说，难道CEO不能协调吗？对，CEO无法协调这样的事，是因为CEO是职业经理人，职业经理人在决策项目时会玩一招叫“委员会”的游戏，游戏规则很简单那就是：你要做一个新项目，只要你说得出要么这个项目可以省钱要么这个项目可以赢利并且附上ROI计算公式并且合理，那么我会让你的项目通过。通过后还有一点就是：你的项目不能动到原有的东西，如果你真的动到了原有的一些东西你就算举了一堆的证告诉他，可以保证原先的逻辑、数据都还在的不会错的那也是没有用的，因为游戏规则就是这么设定的，你动到了原来的东西就有“风险”；
4. 第4个点在于：基建层面即infrastructure层面，这些传统的大鳄们可都是30年前、20年前进入中国的。那时还没有云用的都是data center，如同legacy system一样的道理那些个data center里用的可都是传统的硬件架构啊，什么RACK、什么万兆光纤、什么机房门禁，单单一个路由到国外接通总部的互联网或者是dns就要每年几百万。反观国内的数字化转型我们先不说硬件设施只说业务响应能力，特别是在618、双11时必须是24*7、必须实时弹性扩充、必须是集群分担压力，运维设施、人员随用随改、随叫随到？传统的data center当然除了它的底层架构固化做不到外就算人员响应效率这块是可以做到的，但实际是这些外资巨头们还有一样东西叫security compliance（安全条例），有上百条！你开一个远程调用端口，一个审批流会跑到国外总部转一圈回来再到data center内操作人员去最终执行，这这个流程就1天半没了，然后开完端口你万一发觉开错了再要一个CR单叫“取消”，然后又一天半时间没了，花了3天取消了开错端口的问题后要开一个正确的远程调用端口，再来1天半，所以整个开端口工作用了4天半。。。试想一下这个场景在国内。。。如果面临快速叠代是不是等端口开好了黄花菜也凉了？就算你这一次给审批通过了，按照国内数字化业务的叠代速度，那数据中心的人天天接到很多CR需求，那些管理你企业infra的人可都是老外，他们是接受不了我们国内这种快速响应的模式的，于是他们会以各种理由不让你做CR，没有为什么就是要求你降低你的开发速度；
5. 第5个点在于：开发模式。我们说了，国内的数字化业务非常快速、叠代非常快，而这些巨头们用的开发也是总部指定的，那些高大上的知名软件开发可都是有一套套流程和规范的，同时他们的技术栈甚至到现在还有停留在使用J2EE1.1或者是DELPHI、C、COBOL这种层面的，和他们谈API真心是有点像在说“火星语”一样；

综上所述，我们总结成三个点导致了这些曾经的零售巨头们的转型如此之慢如此之痛苦，那就是：制度、运维底层、开发这三者的全面落后制约了这些企业的数字化变革、新零售变革的节奏。很多来不及变革那么就面临着被兼并、撤资这样的下场。       

零售界IT技术的三次演变

第一次演变：传统零售开始谋求线上电商模式变革的第一次技术上的演变是把线下零售模式完全照抄照搬到线上的一次尝试。

 

        我们可以看到一个典型的线下零售模式中一个顾客来到店里面，他做不同的事需要询问不同的“柜台人员“。于是以一些曾经的零售巨头们认为线上模式就是把这"一个个的柜员替换成一个个的APP“！就叫线上模式，于是我们的第一代零售线上模式成了以下这么一个样子。

这种模式造成了几个问题：

1. APP只是后面legacy系统延伸到to c端的触角，却并未考虑legacy间彼此打通，造成了客户需要在多个APP间切换，事实上直到现在还有部分“巨头”竟然是这么干的，而且这些APP属于同一个企业内的不同部门、不同业务运营管理，因此客户享受到和得到的服务信息都是不对称的，这个体验是极差的。我举一例来说，我们经常有时会收到或者在网上买到一些零售厂商直接发放的：什么什么尊享卡，而用这个尊享卡到门店去享受打折时，门店人员是不知道有这么一个“活动”的，因此他此时还要打电话给到后台转了一通电话后才最后告诉你“只有网上可以享受得到这个权益哦，亲”，因此请问如果换作你是消费者，你会怎么思考这个体验；
2. 每个APP由于只是legacy单纯的to c端的触角，因此它们根本没有考虑到大流量、高并发这样的场景，这也造成了一些“巨头”们的系统脆弱不堪，在这种模式下一些APP只要流量稍稍一大动不动就“APP卡死、APP白屏啦”的现象频频出现；
3. 那么为了满足性能，零售企业能够采取的就是不断的砸钱在扩宽扩大硬件上！商业版数据库1个不够？那我来50个！小型机一台不够？那来10台？商业版中间件1台不够？来100个。而一堆成本“烧掉”后得到回报可能仅仅只是多增加了100-200个TPS，这依旧无法面对千、万级TPS的流量。一边在“烧成本“，一边销售上迟迟不见回报，没有多少企业可以撑得住这种模式；

第二次演变：

        即所谓的SOA时代。

你们不是说我们一个个都是”烟囱“式的APP吗？好，我用SOA、EAI等一些在2010～2014年看起来“前卫”的东西，把legacy全部集成起来，前端只有一个APP不就成了？这种模式看似解决了“体验”的问题，去带来了更惨重的经历：

1. legacy间使用了更昂贵的SOA、EAI等商业组件去”为了连接而连接“起来；
2. 当legacy连接了起来，前端APP也变成了一个的时候，依旧没有在零售企业系统内部的“企业级架构”上发生任何根本性的变化，于是当下面场景倒来时零售企业的legacy依旧会在分分钟内被“流量“打爆

        被打爆了怎么办？于是：加硬件、加小型机、加企业数据库、加带宽。。。。。。结果这次要多加点东西了，是什么东西？就是要比1.0模式里多加企业级商业中间件，这下可好，4个、6个商业级中间件一要。。。老老贵了。但就是为了换取系统有限的一点TPS的增加进而付出的成本却更加贵了，因此这种模式只”烧了“不超过2年就不再被人所提起了；

第三次演变：进入微服务的时代

        这次演变正是由我们国人在结合了我们自有零售特色以及相应的开源技术特别是微服务系列技术成熟后的一种业务+技术的革命性演变，它具体表现成如下的一种企业架构：

        我们可以看到在这种模式下整个架构发生了革命性的变化：

1. 全渠道、多功能，可以从架构图上看到前端的业务通过”内容管理“发生了”下沉“；
2. 后端的legacy通过data transformer（数据转换-轻量级企业网关）发生了“上浮”；
3. 整个架构层面出现了"service“层面，在这个层面和”功能应用“层面间还出现了微服务网关这么一个东西；

        至此，新零售的核心业务系统-全渠道中台的架构成形了。

是什么样的契机促施了新零售的出现呢

先来看看2012年左右零售界开始出现的危机

 

新零售来了

        什么是新零售呢？

        新零售是我们人口基数造成的人口流量红利下必然诞生的一种事物，它的本质就是：把传统的“坐商”变成了“走商”。它是伴随着前面那些企业在转型中所遇到的痛点而随之诞生的一系列技术综合应用下的产物，新零售它并不是一个新东西，它恰恰就是零售的本质，因此在谈新零售的本质前我要说一下零售的本质，零售的本质是什么？

        用711超市创始人铃木敏文的话说，零售的本质就是“站在消费者的角度去彻底思考和解决消费者的所需”。

        新零售就是使用的是技术手段去发掘、去满足、去创造一个用户的需求，它讲究的就是使用技术手段去做到传统零售做的不好或者是无法做到的一系列的手段。

        新零售从现在来看它的发展会成为一个技术领域，或许我用技术领域去称呼新零售还是太局限了，因为新零售它既蕴含着5000年来中华民族从货郎演变到百货超市的商业模式又兼顾着符有中国特色的数字化技术栈的应用，它是一个技术+业务的混合体进而产生了1+1>2的效果。    

又是哪些技术推动了新零售的诞生呢

1. docker化，因为由于docker化我们在面对业务大促时使得我们的系统可以高度可弹性扩充；
2. 页面与后端交互变成了后来的前后端分离技术，使得我们后端的应用服务可以以无状态（现在我们把它称为云原生标准）的形式任意伸缩；
3. 微服务治理框架如以dubbo和spring cloud为代表的框架的出现，决定了微服务真正可以得到落地。因为在只出现docker技术时我们此时还在设计和编码时额外需要考虑：如何做服务间的load balance，当时用昂贵的商业组件是可以做得到这一点的，可是往往在面临每秒千级、万级并发时，我们光买这些商业版的LB(load balance）就需要付出巨额的代价，而dubbo和spring cloud的适时出现，解决了我们这个难题；
4. 云化技术，使得整个企业在infrastructure上不仅仅解放的是传统运维手段而是得到了一个高度灵活、实时响应、24*7保障的平台，我们在谈企业架构时不能只看重灵活，因为零售是一个以零售业为核心的一个混合的知识体系，在以业务为核心的体系内要知道no one will buy for flexible（没有人仅仅只是为了灵活而买单）这个道理，因此对于云化技术我要强调的优点是：随时可扩充、按需购买、运维解放生产力这三个点，即我们最近三年出现的一句很时髦的名词叫：cost effective（这钱花了值）；

        在我看来以上4点是革命性的变化，其它的技术它其实只是一个“旧瓶装新酒”，未发生根本上的“质”的变化，如果要说了远点其实dubbo、spring cloud也是一个“旧瓶装新酒”的东西，它们其实是EJB3.0的延续而己，这个有点说了远了，我会以后单独写一个博客来讨论为什么出现了dubbo和spring cloud这样的微服务框架。

谈谈传统零售在数字化转型中的那些重点、难点升级方面吧

        如前面所说：零售行业它首先是以“零售”为核心的一个“业务”领域，它的升级改造不能仅仅论系统而系统，而是一个体系化的改造，如果我们非要论系统而系统那么我们来这样看待零售系统的升级改造。

        我们把零售业务划成这么几个模块然后来谈这些业务模块的技术改造会更符合“零售行业的升级和改造场景有哪些”这个话题！

主数据即商品数据的技术改造

        传统零售的主数据一般都是一些老牌的类似ERP一类的东西诸如MDM，MDM的出现是一个好东西但是它不符合互联网、新零售模式，原因在于：大家想像一下，在淘宝里面一个商品的属性它带有视频、多图、评论这些互联网化的“属性”，而这些属性在传统的MDM内是没有的，有人说：那我加入这些属性吧？你是可以加，可是MDM不同点在什么地方：所谓的MDM不仅仅只是一个存储，它内含主数据变动的审核流程，这个流程是可以让一个商品属性的改动审批一直走到CFO 、CEO这个层面啊！在快速叠代一个大促场景、一个会员活动场景中我们不可能使用这么重的审核流程的，因此这一块技术上的升级改造分成两种方法：

1. 彻底去除掉原有的MDM，把整个主数据业务逻辑上浮到中台，这是彻底的一种改造，我比较倾向于这种方案；
2. 柔性改造，即需要使用互联网化的data transformer来把原有的MDM中的数据抽取、变形到中台的“商品中心”中去，然后在中台的商品中心内对这部分来自于MDM的数据进行“互联网化的文描的再造与丰富”，在业内我们把这种手段称为“对MDM主数据的enrichment“，此时需要你的这个data transformer一定要在选型时考虑支持多种（目前世面上所有主流的文件格式转换）文件的格式转换、转换的时效性（实时流处理）、性能，此处我推荐用轻量级ESB来解决这个问题可以很好的做到这个柔性方案，ESB虽然是出现在零售数字化2.0中的一个东西，但不代表它是一个“过时的太重的东西”，因为真的是有几个ESB它们与时俱进了，它们已经接近或者就可以作为一个“API网关”来使用了，即可以做到轻量化、又满足多样化文件格式转换又兼顾到了微服务理念，比如说mule esb，它是开源免费的，它以图形化完成数据流转换首先加快了我们做数据转换的开发时效性又可以在底层架构上完全满足我们对于开发的实时性、性能的高效的需求；

用户中心的改造

        彻底去除传统的CRM而把用户中心升级成一个“会员中心”，这个会员中心必须考虑千万乃至亿的数据库存储方案，我们都知道DB能力再强但是对于一个具有上千张表并且每一个单表超过千万和亿条数据的存储级别时，你的SQL写的再好也满足不了我们在高并发大流量场景下要达到任何查询<1秒这么一个需求，因此此时我们就要考虑“数据垂直分片”的设计了，那么我们常用的手法有“哈希一致性算法”，这是“会员中心”模块设计时非常重要的一个技术点，因为在零售系统内我们会有“流水”的记录，流水是永（或者说一段年限内）不作物理删除的，因此光会员中心的一个“积分流水场景”就足以在3个月、长者半年内给你产生上亿条记录，此时在设计的一开始你就必须考虑“数据垂直折分”这个技术；

供应链

        说白了就是库存、物流、配送模块的改造，现代互联网下的供应链讲究的是：分布式、高时效、多渠道接入这么一个理念（其实这些已经不是只是停留在一个理念层面上的问题了，一些做的好的新零售正在这么干），我们把它说白了点就是：即要考虑到库存交易上的“强交易、强校验”又要考虑到一个高并发、时效性这么一个“鱼与熊掌”兼得的方法，那么我们此时就要在设计这个模块时考虑到“分布式、微服务中的那个著名的分布式事务”的东西了。为了在满足”业务幂等“的前提下又要考虑到”高时效“，那么势必我们比较倾向于”补偿式事务处理机制“，因为虽然”2PC“事务处理可以保证我们的事务强一致，但是它的效率也是最低的；

促销中心中的改造

        这是零售中很重要的一个”流量端抓手“，促销中心可是真金白银的给零售企业带来钱的啊。它必须是API化，很多传统零售巨头的促销中心使用了一些重量级、严谨的”企业业务规则引擎”，这不仅仅使得它在业务上“太重”同时也根本无法支持互联网场景下的大流量、高并发。因此这一块我们会使用很多轻量的、API化的规则引擎去制作这一个模块。大家可能不知道，一个零售企业的线上线下以及涉及到一些第三方渠道的订单场景加在一起的完整促销有多少条不同的规则？我告诉你，我碰到过的最多的规则有880条规则，彼此间还有排列组合以及互斥。那么这些促销规则每次在组合时、变动时都找我们的IT团队来做变更吗？不可能，这不又走入了传统的零售、供应商动不动要改代码、接CR Ticket的开发模式了。因此在新零售场景内我们会把促销分成“因子和公式”两部分，把公式部分交给业务部门即日常运营管理的团队去负责，IT只负责因子。举个简单的例子来说：A+B+C要变成A*B*C可以以图形化的方式开放给到运营管理团队去做变更，而对于A、B、C这样的因子假设现在新的场景中需要一个D，那么制作这个D的任务就交给IT团队去完成了，并且这个促销引擎必须是API化的；

全渠道订单中心

        这就是近3年出现在业界的OMS一词的来源（Order Management System）又称为“全渠道订单中心”。什么叫全渠道订单中心？它不就是用户加购物车再点击一下提交吗？不。。。。。。我们想一下零售场景中在“订单”这一场景下会经常发生一些什么样的事：

• to c端的订单，这个我们都知道，用户提交订单；
• 大、小宗批发下单，这就叫to B端的订单；
• 订单下完了我们要路由到大仓（仓库）去下单，假设我是一个全国性的门店，全国所有的城市的门店有300家我们把它们归到三个大区中去，如：华东、华北、华南设三个仓，那么来自上海的订单和来自广东的订单它必须要路由到不同的地区的大仓去的对吧？这时就要有“订单路由功能”；
• 基于订单路由，我要真的发展全国性订单、全渠道订单那么此时订单是不是即有可能来自我自建的电商平台也同时有可能来自一些第三方订单如：饿百、美团、京东？或者我的订单要路由到第三方去？亦或者如天猫店，c端用户统一在一个平台下单后单子再路由到“接入天猫的商家”自己后台系统中的订单系统中？
• 更复杂的是零售界还有一种玩法，比如说一些垂直品牌如：某知名化妆品直接由商家发起打给你的平台一笔钱告诉你这个月我的这支口红只卖99元，和原价间引起的差额我直接打钱给你平台来补贴你，你每天只要把订单流水、金额给到我，我校对后把我们两个平台间的差价通过我的帐户打给你的帐户，这种玩法叫做介于to c端-x轴和to 大B端-y轴当中的一个多出来的z轴，我们把这个介于to c和to B间的额外的这个轴叫作to小b玩法，这就是B2b2c，大家一般都用Bbc来“爱称它”，订单系统需要含有这种逻辑和技术；

SCRM技术

        前面我说了“会员中心”，它是传统crm的升级，那什么叫SCRM呢？即social crm或者又叫全渠道CRM，再说白了它就是传说中的“数据中台”。这一块要看零售企业自身的业务分布和布局了因此在零售行业内目前有两种SCRM的做法：

• 把SCRM叫作单独的“市场营销模块”，把会员中心叫做“CRM Foundation“模块。会员只做权益、积分类交易包括积分商城，促销模块呢做”普通促销“或者又叫做”General Promotion“，然后把了一个SCRM即市场营销模块去做”精准营销”（Individual Promotion）如：千人千面相关技术就是SCRM所特有的，这种做法符合传统零售到新零售循序渐进的演变法则，在这种做法内SCRM它的位置”偏后，只做分析、洗数据用“；
• • 更激进的手法：那就是没有会员中心了、也没有促销中心了，直接就一个SCRM，它冲到了to c端即前端去了，它内置促销、洗数据、实时分析、会员全功能。现在知道这个S即Social指的是什么意思了吧？它就是代指一切“流量端的接入”，目前互联网化的零售企业都用的是这种SCRM，它的做法很激进但是一次性的投入是会比较大的；

CMS（content management system）-内容管理引擎

        这个内容管理引擎是一个to APP & to 微信小程序的东西，前面大家看到了一个名词叫“用户端逻辑的下沉”，什么个意思呢？说白点就是：我要换一个APP的目录、首页、布局、促销页，此时我不需要改动代码只需要在后台让运营管理人员按照因子、公式折分法则，做一下调整同时辅以：在后台运营管理平台端所见即所得的效果，运营管理端人员在后台界面上看着一个APP或者是微信的界面，然后拿鼠标在上面拖拖拽拽、点点画画，然后一按【发布】按钮，前端我的APP就完成了不仅仅在布局、甚至在促销轮播、优惠活动上的变化了，这是一个技术含量很高的组件。我这边举一个例子，大家去看JD或者是拼多多小程序里的”产品类别“这一个栏目，我们注意在APP或者是小程序的TOP顶部有一个个的小圆圈，这些小圆圈叫”页签“，就这么一个简单的技术，如果你没有CMS的情况下，你要怎么做请试想一下？是不是把原先类目的service层进行重用，然后改一下中间传输层、前端页面或者是小程序或者是APP改一下，前后端再一起来一次发版？我告诉你我在几个大型项目中如果用了CMS我会怎么做？打开后端打开运营管理平台->在类目显示时勾选“页签功能”，然后给页签绑定“自定义数据源”->选择商品信息->点【发布】按钮，前端的PC站、小程序、APP端瞬间完成了新的内容和文描的切换。大家现在回忆一下我说的：前端业务逻辑的下沉到底指的是什么意思了吧？

抵御黑产、薅羊毛的技术

        即：零售风控技术，拼多多事件大家应该还未忘记吧？BAT在一开始惑多惑少，都被“薅过羊毛”，那么WAF、DDOS已经远远不够用了，由此而发展出了一个特别的领域，那就是“风控”，这个风控涉及到的内容足以写一篇单独的教程或者开设一个学课了，其中涉及到“数学模型、理论、博弈学、大数据、密码学“等一系列学课；

最后总结一下零售行业的数字化升级改造在于一句话：商品API化、促销API化、订单API化、用户AP化。

零售数字化转型中的“外采模式“ VS ”自研发模式“

        前面已经有过详细论述了，传统零售的转型的阻力源于：内部制度、infrastructure底层、开发模式上的限制导致了传统零售转型困难和受阻。它们的痛点在于：一边在用”烧成本“的方式去换取有限的”额外流量“、一边又无法快速搭上已经在高速行进中的”新零售“这班高铁了。

        这10多年来接触了太多的技术服务商。但是这个话题过于敏感，也可能会给人以一些个人偏见问题。因此在此我是比较坚持选择“自开发道路“，为什么？其实要举例来说的话那么光这一个主题就可以写成一整本书，我们以结果为导向来说为什么我坚持自主开发呢？因为成功的那些都是100%自主开发从而才能“杀出一条血路”来的。

        因此，在这个点上我以一个经历过且成功落地了两个大型零售中台的甲方观点来说：我不排斥外采，但是这个外采一定需要坚持以下几点核心原则，这几点核心原则也注定了为什么在外面很多新零售或者是中台项目失败的关键因素，因此这些核心点是缺一不可！这个我甚至已经准备好单独写一篇博客，它的标题我也想好了叫”CIO如何防止被割韭菜宝典“。这边我只说一下”甲方外采核心原则“：

1. 系统框架必须符合现在的”业界标准“即开源、标准、通用技术，不仅仅要考虑系统内那么多模块所涉及到的技术采用的都是市场中最通用、最标准的框架、组件，同时还要考虑系统内的任何（这边必须是任何，一个点都不可以遗露）技术、组件都可以在本地市场找到大量的”开发资源“即开发人员，框架、架构、组件开源化、标准化，保持系统的”纯洁性“、相关技术所涉及到的开发资源要”普遍化“；
2. 一定要买源码，而且必须是100%的源码，杜绝出现技术底层我可以不要而只要业务代码这种做法；按照你本企业转型后的期望业务指标设定”压力测试、性能指标“对若干侯选外采系统进行严格的”性能测试“；
3. 甲方必须配置一个”安全团队”，人数可以开始从两个人起步，但是必须要有专业的“安全人员”，并且严格执行“安全标准”如：代码扫描、漏洞扫描、安全加固、业务层安全加固；
4. 甲方必须在启动这样的项目前把核心角色和人员：项目经理、PO（互联网化的产品经理）、自己开发团队、架构师、测试、数据库、devops（运维）配置全；
5. 坚持只让供应商提供软件、源码，而由甲方的核心IT角色和人员来做安装、开发、上线或者是必须由甲方的全面管控、指导下：供应商出人力（全部/部分人力）配合完成：调试、安装、开发、上线工作以避免被“过多绑架”；

        零售数字化系统是”心脏“，是”命“，这也是为什么国内成功转型的一些零售商最终都变成了”以零售为核心的科技型企业“的道理，因为一旦你要启动数字化变形工作，科技就成了第一生产力了。我们可以为了节约时间进行外采，但是最终这个”原子弹“还得要自己造出来。毛主席在1959年计划两弹一星规划时说了一句话，这句话到现在以及将来都不会过时，这句话叫：爹有娘有不如自己有。

        这边如果一定要严格来区分外采还是自研发，我就拿我曾操作过的手法来做说明吧：

1. 中小型没有能力筹建甲方型专业数字化团队来管控项目的那些企业可以考虑成熟的SAAS，尽量少或者不要开发；
2. 中大型企业根据自身业务特性，坚持本企业的核心系统、业务系统用我上述说的坚持自开发或者框架、架构+源码提供的情况下的甲方管控供应商出人基础上的自开发模式，而对于一些非甲方企业所应有或者该有的能力比方说：我要做一个货架缺货识别，需要摄像头对于饮料还是肉类有一个“机器识别”，这个识别既带有“图形识别算法”又带有“自建模、训练“能力，那对于一般的传统型零售企业来说它可以具备devops和开发的能力，但是要具备这种非常专业领域甚至可以说是科学领域的技术能力，那么我们把这种能力可以认为是“外采”，外采过来后倒过来给本企业的业务去赋能，比如说一些：刷脸购中识别人脸的API可以以SAAS模式外采，然后把这个API反输入和返回结果结合本企业的商品主数据、订单、会员流程完成本企业的一个刷脸购业务；
3. 对于已经成熟、有实力、已经开始进入了高速发展的大型企业并且已经把科技作为了第一生产力的那些企业是可以自筹这样的团队的，如现在的BAT、JD、苏宁已经从前到后实现了技术无死角的完全由自己筹建了，包括国外的AWS就是这样的组织结构；

新零售内已经不分技术还是业务职能了是否有技术解决不了的业务？

        从2017-2018年来看，整个业界其实已经高度达成了一个一致，那就是：随着互联网的普及、技术门槛的降低，技术和业务已经不分你我、不分边界并且形成了一个“相互渗透的局面了”。我在前面说新零售的出现中就已经提到过，这是一个以”零售业务为核心、以技术为引擎”的综合性领域。技术需要懂业务、业务要以技术为第一生产力，这也就是在最近3年出现了一种新兴的团队：Digital（数字化团队）的由来，而基于数字化团队也出现了之前和传统的CTO所不一样的一种角色，有两个这样的角色值得提一下，一种叫：CDO即Chief Digital Officer，一种叫：CSO即Chief Strategy Officer。CDO负责数字化转型中的业务+技术的设计、协调、落地而CSO解决本企业内在推进数字化项目中时所带来的“RIO、方向是否准确、并把数字化团队落地的东西去反推业务说白了就是在零售的实际运营、营销上的策略的调整和落地”。而CDO和CSO这两种角色目前的要求都是定位为技术出身又懂业务的人员身上，如外面大量急缺的一些CDO、CSO职位要求最好是在ALI系内曾做过P8的人员（领域专家）。这让我想起了在5年前在业界出现过的一句著名的话，“好的产品一定出自技术、互联网企业又懂业务、又懂技术、又懂运营将成为未来对人才的要求“，这也就是为什么我说现在业界已经在发生了而不是将要发生的一件事就是技术和业务正在互相渗透、不再区分你我、不再区分边界了。

        哪些问题是现在的技术不能解决的，我这边想提一点个人意见，那就是技术和业务由于边界已经不再那么清晰了、并且是互相渗透。

        我们举一个例子来说：一个天文学家，它知道银河系旋转的理论，然后这个天文学家把它的”业务知识“写成开发文档找程序员实现，试问哪个程序员可以实现？那么这个天文学家肯定是自己用计算机技术去实现这个原理。这就是我对第二个问题的回答

 

新零售的未来发展趋势

        新零售“它是以零售业务为核心的一系列数字化技术的应用与创新”的一个新兴领域”。

        从整体发展来看，它甚至可以发展成一个新的操作系统。为什么用新的操作系统来形容新零售的发展方向？

        试想在未来不久，你只要戴上一块手表、一幅眼镜。当你行走或者是行驶在大街上，你需要喝一个可乐了，眼球转动一下，智能眼镜自动下单然后一架无人机拿着可乐悬停在了你的头上。如果你快要没油了，你轻点一下手表上的某个功能键，你身边有一辆无人驾驶车经过然后向你的车的油箱内开始注入燃油。

        要知道，我们的生活，哪一天、哪一小时有离开过零售吗？还真没有！因此零售会深入到一个人的最本质需求中，那么当把这些需求用各种选进技术实现后，我们的生活是不是仅次于matrix了？亦或者说“智慧人生”模式开启了，那么此时新零售已经不再是一个个软件开发供应商或者是一个个互联网企业，它就会变成一块“城市的芯片”，渗透在我们每天的生活中了。

        中国势必会走一条和西方不同的零售模式，这在前面我也提到过，它是由国情的不同决定的。

        但是有一个点我觉得我们是需要借鉴的：那就是国内的电商赢在模式上，国外不是说不行，AWS也很强、Netflix的技术很牛逼。但是国内和国外不一样的地方或者说我们国内可以学习别人的地方在于：中间件和一些底层的东西还是国外的，”芯片“什么时候我们也能自己造？如果真的到了那个时候，比如说service mesh或者是nginx亦或者是mysql这样的东西是国人造的？哎呀，我真心希望我可以快点看到这一天，那我一定会开心的从椅子上跳起来。