zl程序教程

您现在的位置是:首页 >  其他

当前栏目

中台夜话20211115

2023-03-15 22:04:33 时间

两周时间很快,两眨眼就过去了,两周时间也很长,要 14 次睡过去,14 次醒过来。又到了 thoughworks 的 EMPC中台解决方案团队 catchup 的时候了,这一次我给大家汇报一下昨天G同事特别有代表性的分享:线下零售行业的数字化转型应该注意哪些架构上的坑?

1 问题:数字化转型路上沉重的 POS 机

X 企业是一个大型的连锁药店,数字化转型让业务形态从原来的进店选购支付,变成了线上下单支付,店面取药或者快递送药的模式。但所有门店系统升级 POS 机硬件成本巨大,所以只能在 POS 机上安装软插件。X 企业原本以为按照了软插件就能顺利开展业务,但灾难才刚刚开始:

  • 软插件会导致线上订单和线下冲突,造成门店无法操作 POS 机,一堆怨声载道的线下消费者在收银台前排队
  • 线上优惠活动复杂,但 POS 机的优惠逻辑无法及时更新优惠规则,导致小票上的优惠详情混乱,客户咨询和投诉增多
  • 线上订单推送到门店之后一旦 POS 机出现问题,就会导致连锁店总部无法获取订单的结果,以至于对账出问题。

关于这个问题的完整解决方案我请分享者 A 同事 专门准备一篇文章来介绍,今天的《中台夜话》还是主要说说,基于这个主题引发的讨论。

2 讨论和思考

和坚:其实这次的分享我们想表达的主要是,通过架构的调整,我们把原来本来是门店 POS 处理的逻辑放置到了服务器端,线上订单直接由服务器的订单管理系统计算好以后把结果推送给门店直接打印,然后再服务器端把线上订单发送给订单中心,而不是等待门店 POS 机处理后的订单信息。

A 同事:没错,整个过程其实就是一个把业务逻辑从线下迁移到服务器端的过程。

B 同事:我这面刚好也在做一个零售客户的项目,它们也有很多门店,每个门店都有 POS 机。但是这个客户比较好的一点是 POS 机没有那么重,它每个订单的计价,优惠的计算,都是在服务端完成的,所以这个项目的数字化改造就轻松很多。

A 同事:关于零售行业的线下设备和线下系统是挺有讨论价值的一个点。当业务的数字化越来越成熟的时候,门店 POS 机,门店系统是可以越来越弱化的。可以退化成甚至只有一个扫描枪。

和坚:这个点我往下延伸一下,不只是 POS 机,这种情况对于很多拥有线下门店系统的零售企业也还是比较常见的问题。比如说一个充电场站,目前所有充电桩的计费规则都是需要通过服务器下发给充电桩的,然后每个充电桩自己基于计费规则来处理充电订单,并由充电桩计算好最终的订单金额再上传给服务器。如果把这个问题稍微抽象一点,这就是一个线下和服务器,业务逻辑和计算逻辑应该放在哪一端的问题。我们在这些项目中有没有提炼一些规则和方法用来判定什么逻辑应该放线下,什么逻辑应该放线上?

A 同事:目前还没有,但是我觉得这是一个挺有意思的课题。

B 同事:我觉得这要看企业对于线下设备断网的容忍程度,如果容忍程度比较高,那就应该把所有的计算逻辑都放到线上做。我认为 POS 机就是一个历史遗留问题,这些东西本身放在线上计算是没有任何问题的。而且如果连锁零售云端化做的好,本身价格的控制,营销活动的设计就是应该中心化做。现在把这些逻辑下发到店里,只是为了解决一个断网的问题,如果门店断网的情况非常少,那就不应该由门店处理这些逻辑。而且断网也是门店完全无法运作,还是可以下单,只是优惠用不了。

A 同事:这点我是挺同意的,就是说我们需要识别出来哪些是门店的核心业务,门店系统要保障离线状态下核心业务依然可以正常运行,晚一点上线了再上报订单信息给服务器也是可以接受的。这个场景有点像三方平台销售的情况,在一个不受管控的系统上用中央侧的优惠券成本蛮高的,第三方平台也许无法使用中央侧的优惠,但是边缘系统要能运作。为什么边缘系统基础的价格可以算优惠价格不能算呢,其实就是优惠的模型相对来说太复杂了。

3 夜话小结

在《解构 TOGAF-2-EA的野心》提到过企业架构不仅仅企业 IT 系统的问题,而是能够更好帮助企业规划业务方向,制定业务合规性的。

这次夜话讨论的这个问题就展现了 EA 的价值,一开始看起来只是线下遗留系统和线上系统如何更合理协作的问题。但按照企业架构的方法,就应该从业务架构开始,分析各种下单场景的的服务蓝图,然后分析哪些是门店的核心业务,然后才能设计出合理的应用架构,门店核心业务必须由门店的应用系统支撑,其他复杂计算模型由中心化的应用系统支撑。

最后,不知道你有没有发现,其实这个零售数字化场景要解决的问题,和企业建设中台时要面对的问题是类似的,前台就是门店 POS 机,中台就是中心侧的服务器。那么在设计企业架构的时候,有思考过什么是前台的核心业务吗,什么是前台如果和中台断联依然可以正常运行的吗?