以下为现场速记。

 

主持人：感谢唐总的精彩分享!天下午显然中台是一个热门的话题。作为从小穿着波司登羽绒服长大的人，我们今天许多人购买波司登的行为已经转到了线上。而在利用中台技术支撑新零售方面，波司登也做了许多有益的探索，接下来，我们有请波司登 CIO桂益龙和我们分享数据中台支持新零售创新。请大家掌声有请!

波司登 CIO 桂益龙

 

桂益龙：前面韩总讲了大中台，唐总也讲了大中台在特步构建生态圈，我想从另外一个方面讲关于大中台在波司登的一些应用。波司登的IT架构是分三层，我们是有集团、事业部、零售公司，我们分三层，我们集团里面叫共享IT，所以软件开发、网络维护这些是属于共享部分的。事业部也有IT，我们更多的是叫业务IT，从业务交流和业务需求提出，把需求交付给我们开发就交付给我们整个集团。当我们把系统做完之后交给业务部门去实施是由IT部门负责的，我们在一年里面可能会有几百个需求。

 

我接下来想谈一下我们用中台怎么来对接这么多事业部，实际上我们的事业部有几十个亿甚至上百亿的营收，我们也会有大概10个亿营收的事业部，我们也会有几千万营收的事业部，我们的结构是不一样的，这是第一点差异。第二点差异，运营模式有很大的不同，波司登事业部既有批发、也有零售。我们事业部是直接总部到门店的模式，另外还有一些事业部基本上是纯批发模式，90%是批发的，只有少量直营店。还有一些事业部是纯线上的，线下基本上没有店。

 

作为集团的IT来讲，怎么用一个中台去满足不同量级的事业部的需求和不同业务形态的需求，实际上我们在这两年的探索里面还是有比较多的收获的。我们认为用一个中台的方式去面对不同的事业部需求，还是能够做得到的。

 

在讲之前做一个小广告，波司登从这两年开始会有一个比较大的变化，其中第一个最重要的是我们的品牌提升，第二个是产品提升，第三个是优势快返，第四个是资源整合。资源整合讲明白一点，接下来我们可能会在海外收购一些更加高端的羽绒服或者防寒服类似的产品进入到我们的体系里面来。这是我们9月份在纽约时尚周发布的一些新产品，实际上效果还是不错的。不管是从我们最终的消费者、还是原来的一些渠道，他们都非常能够接受我们新的产品、新的形象。

 

接下来我想从两个部分谈一下，第一是业务中台、第二是数据中台，我们怎么在集团层面应用这两块。谈到这一块，我们还是要谈到我们本身作为企业的发展过程，波司登一开始是以羽绒服为产品起家的，那个阶段我们是做商品，商品做出来我们很快就能销售和批发出去。2004年开始我们更加关注渠道，我们不断的看有没有更好的渠道销售商品，再往后是更加关注供应链，最两年我们更加关注消费者。

 

大家在以前都会说消费者是上帝，实际上我们在前三个阶段大家都认为消费者是上帝，因为是上帝，所以我们不敢去接近他、靠近他，我们真正去接触消费者、了解消费者是在第四阶段，实际上第四阶段的需求变化是非常明显的，我们从2018年到目前为止所有的需求里面有三分之一是跟消费者会员相关的，这说明这个市场已经发生了变化。因为市场变化了，需求变化快了，所以我们需要一个能够满足快速变化的系统来支持整个集团各个事业部不同成熟阶段的发展。

 

这是我们原来传统的IT结构，这是以SAP为核心的系统，很多企业都是这样。这也没有什么坏处，以前大家都按照这个系统来运营，它还是有优点的。它既有缺点，也有优点。它的优点是什么呢?第一是流程化，流程化不是坏事情，当有了流程化的时候，我们的业务能够快速运作和高效运转。第二是自动化，我们全国几千家门店每一天所有的销售小票在财务那里要生成凭证，原来靠手工是不可能的，现在可以做到了，业务营收和财务营收是完全一致的，它是没有区别的、没有差异的，这是自动化带来的好处。第三是风险控制，我们整个的流程风控是经过毕马威的流程进行审核的，所以我们在年度财务审计的时候，在风控层面毕马威是完全放心的，这个是传统IT系统带来的好处。

 

它的坏处也是非常明显的，第一是成本非常高，建设周期非常长，我们的系统上线花了一年时间，花了数千完去构建这个系统。第二是如果我们想要做一些个性化的需求，实际上时间是很长的，可能从需求到最终的交付要一到两个月时间，但是我们现在接到的需求经常是一个星期要交货，满足新的需求。比如说我们最近两天接到的要做一个小程序版的微商城，我们需要一个星期就上线，这是我们当前面对的情况。第三是系统之间相互独立，系统整合非常困难，系统整合的接口可能需要好几百个才能把所有的系统打通，所以我们对业务的快速响应能力还是比较差的。

 

我还是想说明一下，我们的系统上线完之后，我们的财务人员减少了三分之二，我们的所有业务大概增加了2到3倍的业务量，但是物流人员也减少了大概20%，传统IT系统还是有它的好处的，当然也有它的缺点。

 

接下来，谈一下业务方面希望是什么，刚才说到我们有不足，时间长、投入大、反应慢。我们的业务要求完全是相反的，第一是低成本试错，最好两到三天上一个版本，成本也不是很大，不行再换一个想法，尤其是在会员运作的时候。第二是用户操作友好，免培训，上线就能用。第三是希望这个系统是一整套系统，不要有那么多接口、用户密码，但是我们又希望每个模块又像一套独立的系统，单独开发、单独发版、单独上线，如果我把一个系统所有的功能都能做到，它是一个非常庞大的系统，它的工程会非常大。当我们有几十个需求在开发的时候，我们发版的时间可能要一到两周才能发一个版本，因为需求很多。但是如果说每个小模块都是一个独立的工程，一到两个人就能够单独开发，开发完就能够上线，这是我们业务部门所需要的系统。最后是响应块，两三天、三五天就能发版，这是我们业务部门需要的，因为现在实在是不一样了。

 

我们回过头看，我们会发现一些互联网的架构还是具有这些特质的。第一是它确实可以做到独立开发，但是应用能力看起来又是整体化的，它所有的用户是在一起的，很多技术资料是共享的，刚才唐总讲到很多东西是共享的，比如说我说会员，很多模块都会用到，只要会员共享服务中心有提供，你只要做一次，其它东西调用和借用就可以了。第二是希望技术是成熟的，能够承受高并发，既然我们要做到所有的门店服务，同时并发量一定是在几千或者几万的高并发，我们需要满足这样的需求。第三是我们作为传统企业来讲，我们对互联网架构当时是没有经验的，我们需要一家公司提供技术支持和技术辅导，而且需要有成功案例，他的技术是领先的，而且是能持续迭代的。当然我们很有幸，我们找到这样的一个合作伙伴，我们一起来做，现在这些条件的满足也对接下来推我们的中台变得更加有信心。

 

这是我们最后建立的零售中台、零售云平台的架构，应该和唐总是类似的。实际上我们搭建的是私有云，下面我们所有的硬件设备都是通过虚拟化做成的，这个硬件设备我们自己来做。再用中间件构建PaaS平台，我们在专业的指导之下逐步建立这些服务中心，在这些服务中心之上再构建各个业务模块。所以我们最后的结果是什么呢?这个套系统看起来是一套系统，但是每个模块又是能够独立进行开发和运维的，所以具有快速响应和服务的能力。

 

后来我们在这个平台之上和业务部门一起做了很多业务创新，比如说微信会员、无卡支付、O2O全渠道、智能供应链、实时数据、零售看板。这些业务都是我们和业务部门一起联合进行创新的，而且交付的周期、交付的时间都不是很长，而且马上能看到效果。当需要调整的时候，我们能够进行快速调整、快速响应。

 

刚才讲到，实际上我们有不同的业务事业部门，他的里体量是不一样的、运作方式是不一样的。其实我们在每个模块里面既要做到数据统一化，又要保证我们不同业务事业部的差异化存在，能够满足这种需求。在会员方面的运作，比如说不通的事业部不同的会员积分是不一样的，活动也是不一样的，积分兑换奖励也是不一样的。但是有一个是一样的，所有会员的基础信息、会员的最早积分是一样的。所以我们兼顾统一，也兼顾差异性。

 

这个全渠道不同的事业部是不一样，但是我们在中台有实现。不同的事业部电商和零售公司是相互独立订货的，我们在“双11”期间需要进行库存统一共享，和门店库存进行共享。像雪中飞事业部是不同的模式，商品电商销售和门店销售是共享的，是放在一个仓库里面的。所以我们在这边既实现了电商和线下完全独立分离，我们实现O2O全渠道共享，我们也实现了纯SPN模式线上和线下共用一盘货的O2O全渠道共享，这个都实现了。

 

刚才讲到会员，不同的事业部有不同的会员积分方式，不同的事业部有不同的活动，不同的事业部有不同的积分兑换，不同的事业部有不同的激励，这些通过中台的共享服务进行共享，让前台的服务有差异。比如说智能供应链两家事业部也是不一样的，比如说渠道两家公司的渠道也是不一样的，在渠道申报里面一家是零售公司到总部渠道开拓流程，另外一家是直接从门店开拓到总部的，模式也是不一样的，我们也是同样支持的。包括物料的采购、装修的过程，这两家事业部也是不一样的，但是没有关系，我们可以通过中台来满足不同的需求。我们的分销是一样的。

 

刚才我简单讲了一下作为一个集团型公司，当我们有多个事业部，而且每个事业部的模式有差距的情况下，甚至业务流程有差距的情况下，我们怎么满足不同的需求。接下来讲一下数据中台，当我们有一个统一的业务中台的时候，我们的统一数据中台就自然而然成立了，要不然我们就变成不同的事业部有不同的数据，我们把它进行打通和整合的时候就需要另外花精力去做。最后我们整体的结构，我回头会做一个展示。

 

这里想解释一下，大家都做了BI系统，为什么我们现在还要提一个关于数据中台的概念呢?我个人认为是这样的，BI系统原来更多解决的是上面两个问题，第一是我们的现状是什么，第二是我们解决问题为什么是这个现状，比如说当前的库存是什么，它是一个现状，我们有多少库存。还会解决为什么，当我们分析门店的成交率、客单价、会员复购，其实这个会帮我们解释为什么这个门店会同比有下滑或同比有增长，他增长的来源是什么呢?有可能是客单价上涨了，有可能是他的会员运营比较好，所以复购率比较好，它会帮助我们解决为什么，但是传统BI基本上不会解决怎么办的问题。

 

但是我认为，数据中台可以帮助我们去解决怎么办。因为我们对于一个问题必须有三步，第一步是描述这个问题是什么问题，第二步是我们要挖掘这个问题背后的原因是什么，第三步是怎么去解决。我相信对于业务部门来讲，怎么去解决问题比前面两步更有价值，你描述我是什么，这10个款式是ToP款、库存是这么多，对于他来讲他只是知道信息而已。

 

我们怎么用数据中台帮助到业务部门解决问题的呢?我们传统的IT架构花了好几千万，这里覆盖的业务是人资、财务、供应链、OA办公、预算、物流系统，这是我们用传统IT系统去覆盖它，而且目前运营得比较好。而且几个事业部共用一套标准和流程，所以对我们来讲是比较能够发挥它的效用的。

 

这里是我们的零售云平台，我们通过中台的方式去满足不同事业部、不同业务模式的需求。最后下面的是数据中台，我们用数据中台把所有传统IT架构的数据和云平台的数据抽到数据中台。还有一个箭头是向上的，也就是这个数据中台还要帮助到我们解决业务部门的问题，让这些数据回归到相应的业务系统里面去。

 

接下来，简单过一下数据中台现在能做哪些呈现。第一是关于人方面，人方面有我们公司的员工，也包括我们的客户，这是我们的一些员工和客户的数据分析，全部都是移动端的。这些都是解决前面的两个问题：是什么、为什么，这是获得的一些数据分析。

 

这是关于场，在这里我会标注我们所有的门店数据、门店构成、门店状况、定位在哪里，方便我们公司各个层级的人去访问门店的时候很快很容易定位到这个门店，然后进行访问。这是对于门店的同比、趋势分析、对门店巡店的结果。

 

接下来讲一下第三部分，数据中台怎么能帮助到业务部门解决问题。目前来讲，我们现在有几个业务场景。

 

第一个业务场景是订单预估，可以叫补单预估。因为波司登在供应链里面有一个比较好的优势，我们每年订货只会订全年销量的三分之一，三分之二的订单来源于国庆之后市场试销之后的补单。这些补单到底补什么?怎么补法?实际上我们以前是靠每个零售公司的商品人员的经验去预估应该补多少，我们现在已经实现了系统自动补单。我们会综合所有的门店、所有的SKU的销售情况，包括每一款SKU的生命周期，而且我们的整个区域比较大，比如说我们的东北现在羽绒服已经启动销售了，我们在湖南还没有开始动。我会根据不同的SKU、不同的门店、不同的区域去预估我们接下来的销售和订单的情况，最后把它汇总交付给后端的供应链生产，实际上对我们快速响应市场帮助是非常大的。像这些订单，我认为就是来源于我们的中台数据的数据分析，解决了我们怎么把订单补单预估准的应用。这是第一点。

 

第二个是自动补货，我们的补货是自动的，比如说当前可用库存是多少，进行自动分配，我们在晚上大概3点的时候，所有门店的补货指令全部自动生成，推送给我们的物流系统，我们的物流系统最早的拣货，华北是5点拣货，3点订单就会生成自动推送给他，不需要人工干预。

 

第三个是自动挑拨建议，实际上羽绒服的特点是高售爆发、快速缺货，基本上我们80%的销售是来源于10月下旬到1月上旬，我们的销量会快速拉起，每个门店必须要在这段时间快速响应。如果现在我的后仓没有货了，但是前面还有补单生产，我们会启动自动挑拨流程。现在手头上没有货了，只能拿仓库的货或者别的门店的货进行挑拨了，我们的系统会产生各个门店的调拨指令，能够快速的把我们的货进行更加均衡的分摊。

 

第四个是如果后仓也没有了，接下来会启动自动归并流程，自动归并到应该归并的门店去。让它集中销售。

 

第五个是促销方案我们现在也在看，不同的地方、不同的款式，我们提出怎么样促销方案，帮助业务解决问题。这是我们在探索中的应用，我个人认为数据中台如果真的能够用这些数据来帮助到业务解决他当前的问题，它还是有一定的业务价值的。

 

最后讲一下业务中台的数据中台，我个人认为业务中台能够帮助我们快速响应业务部门在整个业务的创新探索过程当中的需求，这些需求可能他自己也不认为是正确的，我们会进行快速试错、快速上线、快速修正，这一点我们还是能做到的。像今年我们所有的需求到9月底90%已经完成了，接下来一段时间我们会快速响应一些临时性的创新想法，我相信我们是能做得到的。另外刚才讲到，我们的数据中台能够帮助我们去解决是什么、为什么和怎么办的问题，我们认为业务中台和数据中台为我们公司的创新探索还是非常有帮助的。

 

刚才是一个抛砖引玉，也希望大家提出批评意见，感谢大家!