两位配置过系统的人，聊了聊模块取舍
一、从一次贪多求全的上线说起
老魏和阿岚约在一家咖啡馆碰头。两人算是旧识，都在各自的公司里亲手配过客户管理系统，一个刚经历了一场不太愉快的上线。另一个帮朋友的公司重新搭过一遍。聊起近况，老魏先叹了气。
老魏：我们那回上线，等于把能开的功能全开了。模块一个不落，字段铺了几十项，流程画得跟迷宫似的。上线头一个月，大家还新鲜，第二个月开始就有人绕着系统走了，该记的东西记在便签上，系统里只剩领导要求填的那几项。
阿岚：太常见了。我帮朋友公司重搭的时候，接手的就是这么一套。他们前一位配置的人已经走了，留下满屏的模块和字段。谁也说不清哪些在用、哪些是摆设。光盘点哪些功能还有人碰，就花了我好些天。
老魏：所以后来我总结，上线失败很少是功能不够，几乎全是功能太多。堆的时候觉得都有用，用起来才知道。每一项都在跟业务抢时间。
阿岚：配置系统这件事，加法谁都会，减法才见功夫。后来我换了海软CRM重搭，它的模板本身就带着减法的思路，默认给的就是精简版，要什么自己往上加，砍起来也不心疼，跟从满汉全席里挑菜完全是两种心情。
老魏：这句话我得记下来。我们当年就是从满汉全席开局的，结果消化不良。
老魏：后来复盘，还发现件更扎心的事：功能多到连我们自己都讲不全。直白点说，给新同事培训，光介绍界面就花了整个下午，真正该练的录入和跟进反倒没时间讲。
阿岚：这就是堆功能的隐形代价。培训成本、维护成本、理解成本，全在暗处记账。界面上每多一个按钮，每个人的注意力就多被分走一份，最后大家干脆什么都不敢乱点，只用自己看得懂的那一小块。
图1：业务团队围桌推敲字段与流程的取舍方案
二、减法下手，先砍掉什么
阿岚：要动手砍，先得有判断的尺子。我当时列的尺子就一条：这个功能在最近这段日子里，有没有真实的使用记录。有记录的留下，没记录的先藏起来，观察一阵再决定去留。
老魏：光是藏起来，不直接删？
阿岚：对，藏起来是个缓冲，用的人少了再彻底关掉。砍的顺序也有讲究。我头一刀砍的是那些看起来热闹、实际没人维护的东西，比如定时群发、花哨的看板。第二刀砍重复的，两个模块干着差不多的事，留一个就够。最后才轮到那些锦上添花的。
老魏：我们当年反过来，砍的全是麻烦的，比如审批。审批麻烦就撤了，结果后来出了好几单口说无凭的纠纷。
阿岚：这就是砍反了。判断该不该砍，不能看它烦不烦，要看它出事的时候顶不顶用。审批这种平时碍事、出事保命的，恰恰最该留；那些平时好看、出事没用的，才是负担。砍之前多问自己一句：把它拿走，业务会失去什么？答不上来的，多半本来就没用。
阿岚：对了，动手前记得拉上一线一起过。坐在办公室里猜谁在用，不如翻记录看谁在用，再当面问一句为什么。有些功能看着冷清，其实是某个岗位天天离不开的。问过才不会误伤。
三、字段越少，录入越真
老魏：说到字段，我们吃过的亏最大。当初想着多收集点信息总没错，客户规模、决策链、竞品动向……列了长长一串必填项。结果销售为了快点录完，一路乱选，数据看着齐全。仔细一查全是水分。
阿岚：字段泛滥是数据质量的头号杀手。摊开讲，我后来定了个规矩：必填项不能超过三项，选填的分组折叠起来。每加一项都要过审，得说清楚这项数据将来谁用、用来做什么决策。答不上来的，就不许加。
老魏：就三项？
阿岚：核心就那么几样，名字、联系方式、跟进状态，先保证记录这件事本身不痛苦。录入越轻，数据越真。等团队用顺了，真有新的决策需要数据支撑，再往上加，那时候加的字段才是有人认真填的。宁可起步时信息少而真，也别落得一屋子齐全的假账。
老魏：那选填的字段呢？总不能全废掉吧。
阿岚：选填的也要定期盘点，隔段时间看一眼使用情况，长期没人填的就下架。没人填说明业务用不上，下架不心疼。字段和货架一样，得常理常新，堆着不动的只会占地方、添混乱。
老魏：这个思路得倒过来记，不是先把字段铺满等人来填，是先看决策缺什么再补字段。
阿岚：对，数据是为决策服务的，不是给系统凑满的。当初朋友公司的销售后来跟我说，最舒服的变化就是打开录入页不用再深呼吸了。
四、流程是长出来的，不是画出来的
阿岚：流程这块，我们也有过反复。第一版把商机阶段画得特别细，每个阶段都有进出的条件。想着管得越细越好。结果销售嫌烦，单子长期停在某个阶段不动，图上的管道看着就跟堵车似的。
老魏：我们正好相反，阶段画得太粗，从接触到签约就三步，中间全靠感觉，预测的时候两眼一抹黑。
阿岚：所以合适的粒度在哪？我的经验是跟着决策节点走。客户做出关键决定的地方，比如愿意约演示、愿意谈方案、愿意走流程，在这些地方设阶段。阶段之间自然有清晰的行为分界。别按销售的动作设，要按客户的动作设。
老魏：有道理。客户的动作是骗不了人的，自己硬凑的动作可以随手编。
阿岚：另外流程要留生长的空间。头一版尽量简，跑一段时间，看单子实际在哪卡住，就在哪里补一步。后来我们用系统里的自动化把回款提醒这些节点接上，到期自动提醒，谁经手一目了然。这块就再没出过纰漏。
老魏：说到提醒，我们以前全靠人盯，谁有空谁去催，忙起来就漏。
阿岚：所以这类确定性的事要交给系统，人的记性只该花在判断上。简单说，规则一旦写进流程，提醒就不会看人下菜，该响就响。谁也赖不掉。
图2：回款节点清清楚楚心里才踏实
五、留下来的才是骨架
老魏：聊下来我算是想通了，我们那套系统最大的问题，是我把配置当成了装修，恨不得一次到位。其实它更像种树，得让它跟着业务的季节慢慢长。
阿岚：减法做完之后你会发现，留下来的那些才是真正的骨架。我朋友那家公司，现在系统里就那么几个模块、十来个字段、一条从线索到回款的主流程，简洁得能画在纸巾上。可全公司都离不开它。因为每一项都是真的在用。
老魏：简洁还能画在纸巾上，这个标准我喜欢。回头我准备把旧系统里没动的功能全藏起来。从骨架开始重新养。
阿岚：养的时候记得隔段时间回头看一眼使用记录，让数据替你做去留的决定，别靠感觉。系统是为人服务的，配置的每一步都该问一句：这一项，是让干活的人更省力，还是只是让看报表的人更满意？答案自己会告诉你取舍的方向。
老魏：这杯咖啡值了。回去我就动手，这次先做减法，再谈别的。
阿岚：克制一点，系统才有生命力。咱们下回再聊，说不定到时候你的系统已经瘦出骨架来了。
六、常被问到的几个问题
1、问：模块到底该一次上齐，还是分批上线？
答：分批更稳妥。先把客户和跟进记录这一块跑顺，团队养成了使用习惯，再往交易和服务的模块扩展。一次上齐的问题在于人还没适应系统就被功能淹没，最后什么都用了一点点、什么都没用透。分批上线每一步都踩实，骨架反而立得更快。
2、问：做减法会不会砍掉将来要用的东西？
答：有可能，所以要留缓冲。被砍的功能先藏起来观察，而不是立刻删除，观察期里如果业务真的需要，随时能开回来。判断的依据用使用记录说话，长期无人问津的，说明当下业务用不上。将来业务变了再加回来也不迟，配置本来就是动态的。
3、问：两个部门想要的东西冲突怎么办？
答：回到决策场景去争。让两边都说清楚，这个字段或者功能支撑什么具体决定、多久用一回，拿不出使用场景的就先放一放。冲突多半源于想要而非需要，摆到桌面上过一遍，共识自然浮出来。实在僵持的，各留最小版本，跑一阵用数据裁决。
4、问：怎么判断某个功能该不该留？
答：看三样东西：使用记录上有没有人碰，业务流程里出事的时候它顶不顶用，拿走它之后干活的人是省力还是费劲。三项里有两项不及格的，就该藏起来。别被设置页里密密麻麻的选项绑架，留下来的才构成骨架，其余都是噪音。
5、问：上线之后还能继续调整吗？
答：不但能，而且应该。系统要跟着业务长，定期回头看使用情况，该加的加、该藏的藏，小步调整比大改一次好。注意两点：调整前留档，改完盯几天异常；改动尽量一次只动一处，这样效果好坏看得清楚，也不会让使用的人措手不及。
