案例 · D2C 服装零售
11 家门店,3 个线上渠道,每天早上一套数字。
一个在 4 个城市拥有 11 家门店和 3 个线上渠道的服装品牌。月末要花一周核对三份报表,结果还是对不上。
原来哪里出了问题
创始人只想知道一件事:品牌昨天卖了多少。要得到答案,得三个人分别导出三份报表。门店收银软件给出一个数字。2 个电商平台各给一个,对一笔销售何时算数、退货怎么处理,各有各的算法。网站又给出第三个。从来没有人让这三个数字对上过,等它们被粘贴进同一张表,一天已经过去了。
月末更糟。它要花掉大半周,靠一位分析员的电子表格运转,得出的数字,财务团队和采购团队心里都暗暗不信。退货是最痛的地方:电商平台的退货在销售发生几周后才出现,而且出现在另一份报表里,所以大家早已据此行动的销售数字其实是错的,只是谁也看不出来。
底下的采购决策,就建立在这样的数字上。某个城市因为看起来卖得好而被补货,而同一尺码却在 200 公里外的另一家门店里积压着。打折开始得太晚,那时当季早已过去。
我们做了什么
一个所有渠道统一汇报的地方,放在品牌自己的账户里。每个渠道照原来的方式销售;改变的是,每一笔销售、退货和取消都以同样的格式汇入,同一件商品无论从门店、电商平台还是网站卖出,都是同一件商品。每个数字的规则只写一次,所以“销售额”对财务和对采购意味着同一件事。
每位店长都有一块自己门店的看板:卖了什么,什么快缺货了,什么一直没动。创始人看到的是同样的全景,覆盖全部 11 家门店和全部 3 个渠道,每天早上在门店开门前就已就绪。
在此之上,还有一个补货视图,替大家做了原本没人有时间做的阅读。它会标出哪些该补货,哪些该调到同一尺码正在热卖的门店,哪些该抢在季节替您拍板之前打折。系统提出建议,采购团队做决定,他们的每个决定都有记录,所以建议的好坏,是对照采购实际怎么做来评判的,而不是凭一句说法。
老板最后得到了什么
每家门店、每个渠道一套数字,每天早上就绪。月末结账在一个屏幕上完成,财务签字确认的数字,就是采购团队看到的数字。每份报表都有书面定义,所以新来的分析员可以直接被告知某个数字是什么意思,而不用从离职同事留下的东西里去摸索。
创始人最看重的是并行运行:每一份报表,旧版和新版都并排运行,直到两者一致,或者差异得到解释并签字确认。任何人信任的东西,在替代品赢得信任之前,都不会被关掉。
交接复盘坦诚地写明了局限。补货建议的好坏,取决于它底下的库存数据,这就是为什么先做数字、后做建议,也是为什么整套系统的运行成本在开发前就写了下来。
改变了什么,改变了多少。
- 节省时间
月末结账
6 天 变为 1 个上午
从当月最后一个营业日,到拿出一套老板愿意据此行动的数字
- 消除差错
各渠道之间对不上的报表行
每 5 行有 1 行 变为 每 100 行不到 1 行
同一天、同一件商品,两个来源,两个答案
- 堵住流失
一家门店缺货、另一家门店却有货的商品
每月 180 次 变为 每月 25 次
顾客要的尺码没买到,而同款同码正在别的门店卖不出去
每项指标都在开发前书面约定,起始数字也在开工前测得。从“6 天”到“1 个上午”,是同一项指标在完工后按同样方法统计的结果。