系统上线三个月，日活只剩三个人

一家做区域连锁的公司，去年上了一套管理系统，覆盖门店巡检、排班、库存、报销。上线时注册账号 214 个，培训做了三场。三个月后看后台，日均活跃 3 人，都是总部的运营。

这不是个例。我们接触过的内部系统里，上线半年后日活掉到两位数以下的比例不低。原因通常不是功能少，而是这套系统对使用者没有好处。

一、先算一下一线的录入成本

一条数据进系统要几步？打开小程序、登录、找入口、选门店、填五个字段、拍照上传、提交。熟练的人 40 秒，不熟练的一分半。

一个督导一天跑 6 家店，每家 8 个检查项，就是 48 条记录，光录入接近 40 分钟。而他原本在微信群里发几张照片、打一行字，30 秒搞定。

系统的收益归总部（数据可查），成本归一线（多花 40 分钟）。在这种结构下，员工绕过系统是理性选择，不是态度问题。

判断线很清楚：单条录入超过 30 秒，或者一天要录超过 30 条，就必须做批量、模板、扫码这类降成本的设计，否则一定被绕开。

二、审批链每多一级，系统就少一批用户

见过一条报销流程走 6 级：发起人、店长、区域经理、财务、副总、总经理。系统里走完平均 4 天，群里 @ 一下 4 小时。

结果是：急事走微信，事后在系统里补流程。补的时候日期不对、金额不对、附件不全，数据就废了。

内部系统的审批链，三级基本是上限。超过三级的部分用金额分流——5000 元以下两级，以上再加一级，而不是所有事所有人都在同一条链上排队。

三、同一个数据填两遍，报表就已经不可信

最典型的场景：门店销售数据，POS 里有一份，管理系统里手工填一份，总部 Excel 里还有一份。三份对不上，月底对账对两天。

只要存在"系统里填一遍、别处再填一遍"，这个字段的可信度就是零。要么做接口把源头数据接进来，要么把它从系统里删掉——留着比没有更糟，因为它会让人以为这里有数据。

四、报表要服务填数据的人

老板要看汇总，一线要看的是"我今天还差什么"。很多系统只做了前者。

一个具体的改法：巡检模块在督导打开首页时，直接显示"本店本月 3 项未整改，其中 1 项已超期"，点进去就是那三条。他不用去报表里筛，也不用等人催。

当系统能帮他把活干完，而不是给他多加一份记录工作，日活才会自己涨上来。

五、如果重做一遍，会怎么排优先级

先做减法：首版功能砍到"一线每天必须用一次"的那两三件事，路径压到三步以内，不需要他填的字段全部去掉。

再做回流：系统算出来的结果要回到他的工作里——排班表自动生成、库存预警直接推送、整改单自动派到他手上。

最后才是给管理层做报表。顺序反了，系统就会变成一个只进不出的数据坟场。

判断一个内部系统值不值得做

看三个数：一线每天用它的次数、用完能不能少干一件事、管理层看的报表里有多少是系统直接出的。

第一个小于 1，说明它是负担；第二个答"不能"，说明它是形式；第三个占比低，说明数据还在系统外。三个都过关，这个系统才算真的上线。

管理系统开发的难点从来不在功能数量。愿意让人少填一个字段、少走一级审批，比多加五个模块有用。原型阶段就把字段和流程摆出来看一遍，比开发完再改便宜太多，原型费在签约开发时全额抵扣。