入这个行当已经4年,收获不多,回想起来都埋在日常的琐碎里很少抬起头来看看远方。也许是想尝试自己沉淀一些东西下来,也或许是想看看自己到底都做了些什么,执念的想安排一个小计划出来,把自己工作上的’琐碎’做些整理,通过图片、手写的方式体现出来。

本篇是这个系列的第一篇 – LDB


门店生命周期是我的毕业论文里写的对象,但是在S公司里,大家都习惯的以组织架构来描述关于门店的”周期” – Strategy、RE、Asset、SA、Design、Construction&Facilities·也就是说S公司基本上按照门店的生命周期中划分team,职责和工作上更好区分,好处是显而易见的,方便各team迅速跟进、迅速开店,但同时也会有个弊端,那就是各team的协同。

回到本篇的主题,经过将近3年的系统建设,完成了整个门店生命周期的系统支持建设后,门店, STORE这一核心对象,逐渐显露出来,并在公司快速发展的围逼下,需求铺面而来。

PS,Store Go是我想给这个平台取得名字,简单,但能表达一层基本含义 – Store Share service basing on occasions and can go to anywhere with any scenario

上图中的难点其实没有展开,大致还是围绕着”新零售”变革环境下的迭代支持和价值体现:

  1. 标准门店 + 特色门店,包括各类Siren retail type,包括reserve和各类special equipment & service(比如宠物店)
  2. store profile – 比如DT,Kiosk,
  3. 类似于大食代的Hema盒马店中店,
  4. Tmall天猫虚拟店,口碑、美团点评上的商家店
  5. 多品牌,比如Princi

类型多,跨team跨部门,LDB果真要让store Go的够远、够价值,需要大量的参考、规划和尝试。从一个产品的角度来说,

  • LDB的MVP上Locator的DB,保证数据准确性的前提下,能提供API share service供下游消费方使用;
  • 用户包括S公司内部其他部门,也应该会包括外部第三方应用
  • 跨部门的联动 ,价值体现点,或者说业务需求点,还不明晰。
  • LDB的使用消费方越多,束缚也会多。美国总部也有一套类似的产品,但是由于外接系统多,很多市场上的客制化信息要求都没有,但是零售消费快速迭代却又不得不面对,所以美国的这套系统只能满足企业内部的基本主数据需求,对于外延需求,没法满足。

补充下传统意义上的MDM知识:

ink-image

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.