库存跟踪,则可以帮助管理货品的课长跟踪缺货单品,在岗位上完成请货、监控、调整、检视的整个业务过程。
1.2移动办公,实时数据
实时数据展示,首先要在数仓设立实时分区,基于移动端数据平台,把需要做实时报表的数据筛选出来,在GP数据库中建立实时中间表,这个暂且不谈,下文会介绍到。实时分区完成后,移动端数据展现也有很多功课要做。
梳理优秀店长思维逻辑,发现门店的实时数据展示逻辑如下:
1.第一顺位是我整体KPI的达成,即销售数据:销售额、目标、达成率。
2.第二顺位是我门店客流情况,即顾客数据:来客数、客单价。
3.第三顺位是发现哪个部门的问题,即细分数据:各课组数据、同期时段、同期全天。这些数据都要求做到实时,并且仓库保存历史快照,这个后面会说到,只是为了说明,这张实时数据表思维清晰,看起来简单,背后的工程是巨大的。
1.3异常分析,断供监控
除了实时数据被动展示,还需要关注异常状态的主动管理,尤其是生鲜水产类快销品的异常,是很多同行业商超重点关注的模块。对于这些异常,单个业务系统很难做到,往往需要多个业务系统综合取数,沿用大数据平台,实现多系统业务单表分析,按照预设的异常类别,进行筛选排序,在移动端展示。
在试用过程中,异常状态往往得不到业务人员的认可,原因在于:不同的业务人员,对不同的商品,在不同的时间段,有着不一样的异常判断。在通用异常的基础上,如何做到异常状态的因地制宜,就显得尤为重要。为此,信息部通过手机端开放了提意见板块,在留言板社区广泛收集业务人员意见,预设了9种异常状态,形成简单自助式的异常分析工具。
生鲜部门一直有一个问题,由于商品动销快,常常会出现有些货卖空了,连库存都没了,这就提了一个需求,要求对断销单品进行监控,做到实时数据表中,如右上。
1.4聚焦单品,扫码巡场
“随时随地、敏捷上传、高效下达”,以商品管理为例:门店业务人员长时间在现场,开发了对于单品的扫码巡场工具,强化商品生命周期管理意识。各课课长,通过移动端,扫描单品条形码或者手输单品编码,即可查询单品的最新价格、最后一次调价、库存SKU数量、最近一次请货、请货状态等等,满足商品生命周期的管理。有如下两个应用:
应用一:各课课长每天的工作中,有一项是检查排面价签,有的商品没有价签,课长自己也忘了价格是多少,以往需要跑到信息部查看,然后打标签,半天后拿到。有了巡场工具,课长通过巡场扫码,用手机编辑商品信息,发送给信息专员打印价签。实现真正的移动办公,高效沟通。
应用二:在大盘点的时候,“查库存,PDA不足,手机APP来凑”,各课课长通过手机先做各自区域的预盘点,提前校对库存、高架、排面的数量,减少20%漏盘单品,降低50%错盘单品,大大提升盘点效率。
盘点扫码查询单品库存、售价、最近一次进货日期&数量等数据:
2.数仓总线:以不变应万变
“春江水暖鸭先知”,门店单元作为零售企业的神经末梢,在“新零售”的颠覆下,未来会衍生出无限可能的数据形态,要应对新数据量质齐下的冲击,这对整个系统平台的架构提出了挑战。传统的数据建设思路是围绕业务为中心,先处理数据上传,补齐数据库,通过业务把后台数据整齐后,再考虑数据下达,去优化数据传送和展示。
这种逆向建仓的过程,投资收益快、实现难度小,但是应对需求多变的门店业务缺乏灵活性、扩展性,业务端稍有变动就涉及整个数据结构的变动。这里,笔者建议通过建立统一中控平台的方式实现门店业务侧的数据采集和下发,保证数据结构的稳健与灵活性。
1.中控——即中央控制,即实现数据池效果,未来的目标是数入一池,数出一孔。建立中控平台,就需要数仓搭建,这里简洁描述成四步:
第一步,维度设计:
1.选取建模的业务处理过程。这里选商品、门店、类别、供应商、品牌等事务。
1.定义业务处理的粒度。选取到单品的粒度。
2.选定用于每个事实表行的维度。例:画出单品—库存—货架的ER图,描述关系
3.确定用于形成每个事实表行的数字型事实。部分事实是IT能决定的,部分需要和业务部门沟通。形成维度表。
第二步,值链引入:
1.值链选取。这里的引入了商品销售、供给、订单管理三个值链。
2.值链集成。将值链的数据,利用数仓总线,规范化引入ODS表中。
第三步,创建模型:
基础表只是数仓底层,后面还需要依据不同类型的数据特点建立模型,例如:库存模型,订单模型,采购模型,顾客购物篮模型等等。
第四步,ETL过程:
业务系统的数据经过清洗,切片,去重后,通过ETL抽取到GP数据库中,维度表和事实表做交叠查询,以单品粒度展示在整合表中。整个数据处理的过程耗时不到15分钟。
如下图,就是GP数据库的ETL流程图(前端展现可忽略)。
三、让移动端成为业务宠儿
在移动端应用探索的最后,想和已经在使用移动端应用的玩家对话,如何让移动端成为业务人员的宠儿?
移动端先天的优势,就不多说了,站在信息人员的角度,笔者建议遵从以下:
1.一个中心:数据为经验”服务“
我相信IT人员都清楚地知道什么是数据,但很少IT人员具备业务经验;所以说,经验(业务人员)是不会被取代的,这是很自然的职责分工,希望各位玩家客观看待。
开发移动端就是要“服务业务”,是永恒的主题,“微信”张小龙2018年公开课提到了两点:
“用完即走”——指的是工具不应该占用额外时间,做移动端的初衷就是提升效率,业务人员每天已经很忙了,如果打开页面卡顿,数据加载缓慢,甚至需要费时费力去查找数据,这就不利于增效。“用完即走”总结来说,就是使用移动端,0进入成本,0离开成本。“去中心化”——移动端开发避免自以为是,应该充分发挥业务人员的各自需求。举个例子:很多移动端都会设置一个统一的入口,统一的页面,业务人员打开后还需要点开路径才能看到自己想看的,为什么不直接进入收藏夹么?“去中心化”总结来说,就是把选择的权利还给业务人员。
2.两个基本点:增大碰撞面积、移动端做减法
“增大碰撞面积”——站在业务人员的角度,拿到数据——产生决策的过程,中间是数据与经验产生的碰撞。对于业务人员来说,数据和经验碰撞才有价值,由于业务人员的经验来自平日点点滴滴的积累,经验的深度、广度千差万别,所以应当增加数据重量:辨识度、含义、关联度。让每一个数据成为沉重的榴弹炮,击中业务人员的经验区。“移动端做减法”——越复杂的平台,使用体验越差;越开放的平台,互动感知越差;在移动端设计伊始,有20多张复杂报表,涉及复杂的查询参数,可用性可读性很差,在门店试点的2个月中,深受诟病,最后只剩下:实时销售表、生鲜断销监控、生鲜负毛利监控。
仔细的读者已经发现,这两个基本点是相互制约的,要增也要减,要碰撞也要精准。这就引出了另一个话题,移动端应用一定是一个不断完善不断发展的过程,随着业务人员的数据分析能力提高,门店数据的种类和数量不断增长,未来的门店移动端将有广阔的应用场景。