客户电话打过来，客服说系统里查无此人；财务催款，销售说这单早备注过月结；仓库说没收到发货指令，可客户已经付了定金。你让IT去查，查了半天发现：客户在三个系统里有三个名字、两个手机号、一个还挂在离职销售名下。这不是系统坏了，是同一份数据被各部门各存了一份，谁也不认谁。
先算一笔账：这种乱，一年吃掉你多少钱
不用算大账，算小账就够了。客服为了确认一个客户身份，多打两个电话，每次三五分钟；财务对账发现地址不一致，退回重开一次发票，来回两天；仓库按旧价格发了货，月底盘亏才发现。单笔看都是小钱，乘以客户数、订单数、月份数，就是一笔没人记账的隐性成本。
更贵的是决策成本。老板想看“这个客户到底贡献多少利润”，结果销售系统里是A公司，财务系统里是A公司某分公司，电商后台又是另一个抬头。三份数据拼不到一起，报表出不来，最后只能拍脑袋。
什么数据算“根数据”，什么不算
根数据，就是描述你生意里那些“主体”的信息：客户是谁、产品是什么、门店和仓库在哪、合同和账户归谁。它相对稳定，被所有业务反复引用。
跟它对应的是流水数据——今天卖了20件、收了5000块、发的是哪一单。流水天天变，根数据不常变。还有一类是分析数据，是从流水里算出来的，比如客户年均采购额、某产品复购率。
判断标准很简单：没有这条数据，交易就做不成。客户和产品就是根数据，没有它们就没有买卖；数量、金额、日期是流水，是交易发生时才产生的。你先把“根”认清楚，后面的治理才有对象。
根数据不统一，麻烦会从哪儿冒出来
- 客户域：客户、供应商、员工、合作伙伴，同一个主体在不同系统里名字写法不同、联系人不同、信用额度不同。催款催错人、发货发错地址，都是这么来的。
- 产品域：产品编码、规格、成本价、售价、物料清单。网店改价了，收银系统没改，客户下单看到低价，结账时价格跳变，人直接走了。
- 位置域：门店、仓库、分公司、服务网点。调货时不知道哪个仓有货，配送时地址对不上，售后找不到归属网点。
- 其他：合同、账户、质保、行业特有资产。这类不常动，一动就是大事，比如合同主体变了，开票信息全得跟着改。
为什么“上个系统”解决不了这个问题
很多老板的第一反应是买套软件。但根数据乱的根源不在工具，在规矩。各部门习惯各管一摊，数据留在自己手里才安心；录入没有统一格式，手机号有人写11位有人加区号；客户改了信息，只在跟自己打交道的那一方更新，别处不知道。
所以根数据管理，一半是技术，一半是习惯。没有谁愿意主动交出自己的“小账本”，得靠老板定规矩：谁负责录入、谁负责审核、改了之后多久同步到其他系统。工具只是把规矩固化下来，规矩本身得你先拍板。
小企业怎么动手：别搞大工程，先立三条规矩
第一条，定“唯一入口”。 客户信息以哪个系统为准，产品信息以哪个系统为准，说清楚。其他系统只读不改，要改走申请。这一步不花钱，但最见效果。
第二条，定“最小字段集”。 客户至少统一：全称、统一社会信用代码、主联系人、主联系电话、开票地址。产品至少统一：编码、名称、规格、单位、含税售价。字段不求多，求每个系统都认。
第三条，定“变更谁通知谁”。 客户换电话、产品调价，谁第一个知道，多久内同步到其他系统，出问题找谁。写成一页纸的流程，贴在群里，比买一套昂贵的系统管用。
做到什么程度算够用
不用追求一步到位。先让客户和产品这两类根数据在销售、财务、仓库三个地方对得上，日常对账不再靠打电话确认，就已经回本了。等业务再大一点，再把门店、合同、供应商纳进来。
根数据管理不是IT部门的事，是老板定规矩、各部门守规矩的事。规矩立住了，系统换不换都好办；规矩立不住，换什么系统都是把乱数据搬个家。
微信扫码