pos机大咖, 008特步CIO唐坤军分享

新闻资讯 | 2023-05-17 10:33 | 投稿人：pos机之家

网上有很多关于pos机大咖, 008特步CIO唐坤军分享的知识，也有很多人为大家解答关于pos机大咖的问题，今天pos机之家(www.poszjia.com)为大家整理了关于这方面的知识，让我们一起来看下吧!

本文目录一览：

1、pos机大咖

pos机大咖

关注并标星✨华东时尚行业CIO联盟

时尚行业信息化大事都不错过

第8期“大咖驾到”微享会我们邀请特步CIO唐坤军为大家分享，分享主题“特步上中台的那些事”。

大咖介绍

分享嘉宾：特步CIO唐坤军

大家好我是特步CIO唐坤军，今天简单分享下特步全渠道中台的一点感受，希望对大家有帮助。特步全渠道中台是2016年9月开始启动的，我们当时启动中台是迫不得已，已经被逼上梁山逼得没办法了。

当时我们用的是用友的分销零售系统，用了整整十年，当时公司总共是7500家店。用友整个系统慢的不得了，很多功能也支持不了，还有用友当时整个团队都全部已经解散。所以我们是在这样没办法的情况下，和国内几家厂商进行了沟通交流，发现都不合适我们。因为体育用品跟纯粹的服装不一样，体育用品有鞋有服装，还有我们整个数据量超级大非常大，所以我们那时候考虑了很久还是把它放弃了，准备上SAP的Retail。也曾经想过还不如SAP的，还不如自己去开发，这些都已经想过了，都已经开始在准备了，但是后来波司登这边在跟阿里在合作，波司登在用阿里的中间件，然后在做分销零售。我们就派人去看，看着觉得挺有意思的，阿里数据库也有，中间件也有，我们可不可以跟他们合作一下。

后来我们这边就派了18个人，技术人员、业务人员，外部还请了几个顾问跟阿里交流，交流完了之后我们觉得是可行的。为什么？当时我基于两个方面的判断，我觉得是可以完全是可以的。第一，阿里一年上万亿的生意额都能支撑，特步目前肯定是可以支持的；第二，当时阿里的双11，那么大的数据量它都能撑得住，特步怎么会不行。基于两点，我觉得我们是可以做的，这个技术上面我觉得是没问题的。还有觉得古谦、平安他们这些人都是很专业的，也是很真诚的，有他们来支撑，而且还有波司登走在前面，我觉得这对我们来说风险会小很多。

所以说基于这些判断，我们开始给公司写报告，我们自己开发。说实话，当时真的也是迫于无奈，买吧，没有合适的。我们隔壁的安踏也很痛苦，他们也是用了两三套系统，用了为涛、SP的Retail，还有另外一套系统。李宁当时也是两套，宏志和道讯，大家都搞得很痛苦。老板也没办法，老板觉得我们也可以去尝试一下，只是说在这个预算内不突破，同意我们去搞。当时我们这个项目在启动的时候，开发人员还不够，我们才12个开发人员，这个开发量还是很大的，所以说我们把整个开发外包给大连华信。整个系统架构的设计是阿里的古谦、平安和白哲来负责支撑的，还有我们内部的几个业务专家，这样的话，我们组成一个团队，我们能做原型设计。在这块我们花了差不多一半的时间做这个事情，这个事情我们当时是以为做的很好，其实事后还是有很多问题，待会我会分享给大家。

我们花了十个月时间把整个分销系统、零售系统、POS系统，还有O2O中台全部开发完，在2017年5月30号在我们福建分公司正式上线。其实我们上一季的时候无数的问题就跑出来了，bug不用说了，肯定是存在的。还有发现我们很多的业务需求我们自己认为搞得很细致，其实我们在做中台的服务中心的时候，这块是个最大的教训，就是我们服务中心根本还没有梳理清楚，导致我们后面极大的返工量。服务中心一定要把我们所有业务流程切片切到最细，就是最简单的一个标准的业务流程，我们要把它梳理出来。如果说我们在开发的时候，我们有能力的话，我们做成一个微服务，最后再进行分装，这是最好的。

我们当时在做原型设计的时候，把很多业务流程设计的很大，做的相对比较复杂。首先服务中心，共享服务中心它一定是最紧急的业务流程，就跟SP里面说的业务的事就是最简单的，标准化的。我们有能力我们能做的出来，但是没有能力的话，我们就会把很多的业务连皮带肉会搞在一起，搞得很复杂。这变成我们是穿新鞋走老路，用的是中台，用的是最新的分布式部署，用的是微服务架构，但是我们做的时候还是过去传统大而全的东西。这个是做中台的时候最忌讳的、最大的弊端，最大的失误，这会导致后面一系列的，当我们有新的需求的时候，有很多问题的时候，我们就涉及到要修改底层架构，中台的服务中心跟我们过去传统一样的时候，一旦我们要进行修改，就要动无数的地方。这是我们在做中台时候给大家一个借鉴，中台的服务中心一定是最简单的一个业务流程，就是把N个最简单的业务流程，我们都给它做成微服务，做成可配置化的、可分装的，这是最好的。

所以说我们当时在设计业务的时候，设计服务中心的时候，一定要请我们业务专家。IT其实做不到，根本做不到，只有业务工作者更懂业务，IT是好像懂，其实不是很透彻的懂，结果导致我们在设计服务中心的时候就会出现很多的问题，我想大部分做中台这些单位，这些设计部门在做原型设计的时候，都会出现这个问题的。

打个比方，我们做库存管理的时候，所有跟库存相关的业务，到底有多少个业务流程是跟库存相关的，我们都把数据列出来。退货谁跟库存相关的，盘点哪些是跟库存相关的，报废跟库存相关的，我们把这些业务流程全部梳理出来，并且把它变成最紧急的、标准化的业务流程，这样我们开发出来变成一个微服务，可以做成可配置化东西，变成一个共享服务中心，这就是我们所谓的库存管理中心，或者叫库存共享中心这样的服务中心。我们把所有影响库存的因素都把它统统列出来，ABCDEFG的全部调出来，把每个业务流程最简单化，最简洁化。然后把跟这些业务流程相关的、个性化的东西，拆到应用中心去，变成应用端。这样应用端是个性化的，应用端可以是随心所欲的，但是我们的服务中心一定是标准化的，可以被各个应用端、可以被各种业务可调用的。这可能是我们在做中台时候最大的注意点，否则的话我们中台做起来之后，变成是用新技术走老路，确实还是传统的那种玩意儿，那就完蛋了，到时候我们再进行系统调整的时候会有无数的返工。

另外其实中台还是分两层意义来讲，一个是业务中台，还有一个是技术中台，首先搞清楚我们要做中台，我们的业务包含哪些，不包含哪些东西，我们的业务中台一定尽可能是成熟的、标准化的那些业务，比方说我们很多，尤其是在供应链方面的计划这些东西，是很复杂的，一直到现在都没有人能把它做成很完整的一个很好的案例的东西，我们就不要去想这些东西了，这东西的话我们可以按照传统的东西去做，不要把这些个性化太强的成为开发的阻碍。尤其是我们在做微服务架构的时候，我建议所有的我们这个应用单位，我们这些IT人员，我们要多去研究一下SAP的这些微服务，SAP是全球最经典的微服务，研究出来之后我们照抄就好了，我们不要自己去想太多的东西。

这是我给大家提了一个醒，还有一个建议，就是关于我们做中台服务中心的时候，我们一些教训跟一些建议。

我们用阿里这个东西的好处是什么呢，也跟大家分享一下，好处是这种分布式部署架构还有服务中心，它最大的好处就是把我们一些业务的应用，把它标准化之后就把它做成服务中心，然后个性化东西变成应用端。所以个性化东西，你再更新的话，在应用端只占了20%，最多30%，你在面对着百分之二十三十的应用端的时候，也是很轻松的，也是非常简单的。那就是绝大部分，大概80%都可以共享变成服务中心，是不动的，是稳态的。

比如说我们特步有45家分公司，我就可以把45家分公司的应用端都变成个性化的，一家分公司一个独立的应用。比如说我应用端有十个的话，那我就十个是个性化都可以，我们可以完全开放给分公司的人员，他们自己去开发，自己去折腾，因为比较简单，都比较小，就服务中心在一块由总部集中来控制来管控。这样我把最简单的那些东西都给放出去，复杂的这东西有总部直接来管理，就是中台服务中心这一块。这样相对的也避免了过去45家分公司只要一提需求的时候，一动起来就要动45家分公司，连皮带肉带筋去撬动。现在每家分公司有个性化需求，只到应用端就好了，那把问题就变得简单了，把范围也收缩了。

第二个，如果说分公司没有能力来做应用的开发也没关系，分公司可以外包给当地的开发商来进行开发，实在没有能力总部来承接也行，也很方便。个性化的应用只需要分公司在应用端变更一下，把系统重新打开变更一下就OK了，不影响任何其他分公司的业务操作业务连续性。这种部署是我们一家分公司一个独立的数据库，是不影响别人的，这个相当于防火墙，有隔离墙，比较方便。

另外是我们在期初的时候，差不多是每周迭代一次，一个月迭代四次。当时迭代得比较频繁，因为问题比较多。我们现在全国45家分公司，大概是6500家店，现在我们全部都有上上去了，现在每个月差不多迭代两次，集中收集需求处理问题。每半个月迭代一次，这样可以把需求控制的很好，不至于很多需求提过来之后，我们盲目地给它去迭代。现在我们的系统除了国内这4500家门店，四十几家分公司，现在我们印度的分公司，我们印度的店，还有越南的分公司，越南的店，还有阿联酋的，大概是在十月份泰国、印度跟越南的分公司我们都已经上线了，所以它在应用方面还是比较方便的。

到目前为止我们总共做了十个服务中心，我们的商品中心、订单中心、库存管理中心、营销中心，营销中心最主要就是我们整个促销活动，零售跟分销这两大模块、大中心，还有会员中心、渠道管理中心、工程管理中心、结算中心、还有物流中心，我们现在很多分公司都有独立的物流仓库，还有OTO中心，主要是把现场跟线下的商品、订单，还有结算进行整合。

现在以线下门店为单位，如果说你愿意跟线上玩，就是现在由我们商品中心发起哪些产品库存比较大，在我们所有分公司发通知，哪些门店的愿意跟线上玩就打勾，那你的商品就自动共享给我们整个线上、共享给我们商品中心。共享之后，然后我们把整个我们结算规则设定清楚，一般我们主要是代销、利润分成还有买断，买断就是货权是属于我，只是暂存在门店，这三种方式。把规则讲清楚之后，你愿意参与进来，就打勾，它就自动就把整个货品共享给我们整个线上。线上接到订单之后，通过O2O服务中心，它自动匹配到离这个消费者最近的门店。我们的规则其实很简单，就是先就全后就近，一个门店的货，第一，需要满足这个消费者的订单，尽量不要拆分成两个订单；第二，先就全后就近，匹配这个消费者，匹配完了之后，系统就自动把订单同步给阿里菜鸟，阿里菜鸟再把离门店最近的物流公司匹配给这家门店，把订单发送给物流公司，物流公司就到这家门店去取货发货。这个效率还是蛮高的，另外同城物流也便宜一半，还是比较方便的。消费者体验来说，时间短。去年我们双十一，一共22万个订单，到第二天下午五点就全部发完了，效率还是蛮高的。

我再来说一下中台做了这么多好处肯定是有的，我想说几个大家要注意的事项，第一个是大家都在谈中台，到底企业要不要做中台，我觉得有两点建议：第一点是做企业中台，你一定要搞清楚到底是做哪一块业务，首先要把业务中台想清楚，哪一个业务要中台化，你才能开始去做，比方说我们供应链这块其实很复杂的，你都没想清楚，盲目去做很容易在设计原型的时候把很多业务搞的颠倒黑白。这样我们做出来东西是没用的，最后这个中台的生命力一定是没有的，一定是在打折的，甚至是用不下去的。

所以说我们要想清楚业务尽可能是成熟的、成型的，有相当的规范化、标准化的业务。分销零售业务其实都是很标准化的东西，我们每家分公司都有陈列标准、商品标准、培训标准、门店装修标准，这种标准的它都有。整个分销零售业务是比较成熟的，它是不断地做精益化管理，不断精益求精的，我觉得这个最能够出成效出成果的。另外供应链为什么说我觉得很难的，我们吴博总结了一句话，我觉得很经典，就是分销零售这块是有很多成熟的标准，如何把它做到更加精益求精。供应链是无数不可预知的因素，要实现三个已知的值，就是交期、质量标准、成本。这块还是比较难搞的，标准化不是很高，成熟的东西不是很多。需要我们去摸索，去探索哪一些比较成熟的已经标准化东西，我们可以把它做成服务中心，用中台的方式来做。

我们做中台的时候一定要有准备，我们在做中台的时候，我们的整个开发跟传统开发完全不一样。传统开发是堆代码，做中台的时候，我们一定要把业务场景化，就是开发人员头脑中一定要有业务场景，代码尽可能不要重复，不要去堆叠，这样写出来的代码是很差的，一定会返工的，做中台服务中心的时候，整个微服务整个代码一定是最简洁的，不要有冗余的代码。你在写某一个微服务的时候，你脑海中的场景肯定是PDCA能够循环的，整个业务从头到结束一定要有业务场景，这样写出的代码才是高质量的。第三个我觉得在设计的时候，将整个数据库的设计用中台做，用互联网架构做。我们最理想的目标是为了实现快，就是我们数据的读要快写要快。常用的数据话，我们写的时候跟读的时候怎样去分离，怎样去做整合，做合并，这都是我们要充分考虑的。你在设计数据库的时候，你不考虑清楚的话，后面很多的优化是会搞的很复杂的。所以我们在设计这些读写分离的时候，我们已经开始涉及到效率。

我们人人都想做中台，但企业没做过中台的时候，千万不要自己去干，在这里面还有很多坑的。阿里的中间件最大的优势是大并发，这是他们的强项，还有他们底层硬件架构这块用Upstart做的开源，企业掌握也是挺难的，这块也是比较复杂的。阿里这个架构现在我们我来总结，它美中不足的是，未来我们在整合数据中心的时候，它的集成整合能力还是比较差的，这个不是它的强项。未来会碰到的一个难题，阿里这块是完全是要靠高质量的开发人员，来进行快速开发，这块儿能力是比较差的。这个是各有利弊的，我觉得如果我们还没做的话，我们要跟已经做过的成熟的这些厂商去合作，这样少走弯路，否则的话我们搞出来的东西会有一堆的问题，对我们团队也好，对于企业也好，都是不利的。我们要搞，我们肯定是尽可能搞成功，第一是让团队要有成长；第二，对公司有价值；第三是我们要有成就感，否则的话我们都会成为劣史，这个千万要小心的，就是不要盲目去干，你要跟成功的、干过的企业去干。

最后我想建议，很多企业肯定一下子拿不出那么多钱来做中台，做中台的成本是很高的，需要的人都是很贵的。我觉得中台前面讲过，无非是两大类，一个是数据中台，一个是业务中台。我觉得要做的时候优先是考虑数据中台，把我们过去的业务，如何把它整合到我们的数据中台上面来，让业务有连续性，再逐步的把过去的那些应用搬到我们应用中台上面，这样能够起到承前启后、平稳平滑过渡的作用，这个是最稳妥的。

做数据中台我实事求是的讲，我觉得伯俊做的非常不错，那可能是因为他们过去有太多的客户，为了让客户不至于用休克疗法把过去的系统全部把它干掉，重新再来。就像特步我们就要休克疗法，推倒重来。但是可以慢慢试，平滑过渡地把过去的业务，不中断、连续性地把很多的数据先搬到终端上面整合过来，再逐步地把那些功能进行替换，最后甚至把所有的功能都调动过来，我觉得这是一个比较稳妥的方案。另外来说，我们好多企业上SP的，如果有HANA的，你可以用HANA作为数据中台进行整合，这是基于你已经有的情况下，没有的话，我觉得最高性价比还是做数据中台，这样是比较合适的。特步之所以能够把分销零售，把很多附属的系统一次性给废掉，特步应用了十年的HANA这个内存数据，我们前端BI是用BO展现的，我们有条件去整合，去把新的全渠道零售中台的数据，跟我们很多的系统进行整合。当时我们是有这个条件的，所以说其他企业在做的时候的要充分考虑到这一点。

最后我想再强调一下，我们做数据中台，一定要强调什么，你把业务中台想清楚没有，到底哪些要业务中台化，你自己把这些想清楚之后，我们再通过技术中台把它实现。我们如果要做的更稳妥，一定是数据中台怎么去构建。还有就是你公司如果连架构师都没有的话，不要搞中台了，这样玩的话会把自己玩死，将所有的命运都是掌握在别人手上，这也是不可取的。所以说要做中台，必须要有自己的架构师，要有一帮人，要有几个相当资深的、核心的开发人员，这样的话我们做迭代做优化的时候，你才有办法去掌控，当你没办法去掌控服务中心的时候，整个中台会倒掉的。

我今天就给大家分享这么多，希望我的建议能够对你们有帮助，也许大家可能不认同，没关系我们可以单独交流，也可以来特步这边交流都可以的，谢谢大家。

提问环节问题一：唐总，请问大概用了多少预算？唐坤军：用了1000万，包含软件硬件。中台不是拼谁钱多，如果你的企业规模不大，企业业务模式稳定，就没必要搞这个，如果企业模式复杂，体量在50亿以上，业务个性化多，组织变化频繁，我们就可以考虑把那块成熟的稳定的业务中台化是比较好的。

问题二：唐总，你们的微服务治理采用什么样的解决方案？唐坤军：微服务治理就是用的阿里中间件

注：以上内容摘自“大咖驾到”微享会，转载仅限学习分享；

如产生版权问题，请联系我们处理；

文章不代表"华东时尚行业CIO联盟“立场！

精彩回顾：

首期大咖驾到 | 高峻峻分享《零售新科学》-数据智能驱动中国零售创新

大咖驾到002 | 陈霈霖分享“喜茶Go小程序背后的数字化引擎”

大咖驾到003 | 毛苇分享“订阅经济-让你的业务几何倍数增长的秘密”

大咖驾到004 | 许绍金分享“企业中如何应对勒索病毒”

大咖驾到005 | 诸老大食品CIO侯有站分享“数字化转型过程中的坎 ”