入这个行当已经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
上图中的难点其实没有展开，大致还是围绕着”新零售”变革环境下的迭代支持和价值体现：
- 标准门店 + 特色门店，包括各类Siren retail type，包括reserve和各类special equipment & service（比如宠物店）
- store profile – 比如DT，Kiosk，
- 类似于大食代的Hema盒马店中店，
- Tmall天猫虚拟店，口碑、美团点评上的商家店
- 多品牌，比如Princi
类型多，跨team跨部门，LDB果真要让store Go的够远、够价值，需要大量的参考、规划和尝试。从一个产品的角度来说，
- LDB的MVP上Locator的DB，保证数据准确性的前提下，能提供API share service供下游消费方使用；
- 用户包括S公司内部其他部门，也应该会包括外部第三方应用
- 跨部门的联动 ，价值体现点，或者说业务需求点，还不明晰。
- LDB的使用消费方越多，束缚也会多。美国总部也有一套类似的产品，但是由于外接系统多，很多市场上的客制化信息要求都没有，但是零售消费快速迭代却又不得不面对，所以美国的这套系统只能满足企业内部的基本主数据需求，对于外延需求，没法满足。
补充下传统意义上的MDM知识：
Bonjour Rafe 