Shopee工具越加越乱：环节没理清之前别上系统

上工具的常见时机

第一种常见的时机是出了问题之后。比如某次库存对不上，当天就去买了一套库存系统。这个动作本身没有错，但买之前通常没有人回答一个问题，就是这次对不上是因为流程里没有定义，还是因为执行时漏了一步。这两种原因的解法完全不同。一个是改流程，一个是补执行。

第二种时机是看到同行在用。听说别人上了某个系统之后效率提升明显，就跟着上。这里容易被忽略的是对方的环节已经理清、分工已经固定，系统装在成型的流程上才会见效。自己的环节还在来回变，装上去就等于把变化锁死在系统里。

第三种时机是团队人数上来之后。两三个人的时候喊一句就能交接，人多了喊不过来，于是急着上协作类的系统。问题是协作系统要先有明确的交接点才有意义。人数变多暴露出来的，其实是交接点从来没有被定义过。

第四种时机是大促之前。担心大促期间忙不过来，提前上一套系统压阵。大促期间订单与流量的波动本身就是变量，这时候上新系统会把两个变量叠在一起，出了问题分不清是流程的毛病还是系统的问题。

第五种时机是交接出过事故之后。发错货、漏发货、价格报错，回头一查发现是交接时漏了一句说明。这时候上系统的冲动最强，也最容易把系统的功能当作流程的定义，结果把一条本来就模糊的边界固化了下来。

判断时机对不对，可以先问一个动作层面的问题：这个工具上完之后，谁的工作量会减少。如果答不出具体的人，只答得出整体效率会提升，那说明这个需求还是模糊的。模糊的需求对应的一定是模糊的验收标准，后面没法评估。

接着问第二个问题：这个工具接的上游是谁。上游的名称要能具体到某个环节，不能是笼统的业务部门。上游明确之后，才知道工具要吃什么格式的数据，也才知道上线前需要上游配合做什么准备，准备工作往往比上线本身更费时间。

第三个动作是把现在的做法拍下来。用截图或者手写记录，把当前每个步骤谁在做、花多久、交给谁，逐条记下来。这份记录不需要精美，它的作用是在上线后做对比，看哪些步骤真的被减少了。没有基线就没有对比，也就无法评估这笔投入。

第四个动作是列一张不做的清单。把希望工具解决但这次不解决的问题写下来，明确排除。这份清单能防止上线过程中不断加需求，把一个本来只解决一个问题的工具拖成四不像。范围一旦被拖大，上线时间会成倍地长。

第五个动作才是去看工具。有了前四步的准备，看工具的时候就有判断依据了，不会被动功能列表带着走。这时候要问的是它能不能接上现有的输入格式、产出能不能被下游直接使用，而不是它能做多少件事。

有一个案例可以说明时机的差别。两家规模接近的店铺都在同一季度上了取数系统。一家在上的时候已经有固定的取数表和口径说明，上线只花了一周，之后每月报表自己生成。另一家上线时连取数口径都在讨论，最后花了两个月，中间报表还断了两期。

后一家的问题不在于系统，而在于它试图用系统来推动口径的讨论。系统的字段一旦建好就会引导大家按它填，填的时候又发现不对，于是来回改字段。这个过程本身消耗的时间，比坐下来开两次会讨论口径要多得多。

还有一个边界情况是季节性强的类目。这类类目在大促周期的数据形态和平时差别很大，用大促期间的数据去验证系统，结论会失真。更合适的做法是在平销期上线和验证，等系统稳了再经历一次大促，看它扛不扛得住。

另一个边界是团队有人离职的时期。这个阶段交接本来就紧张，再叠加上系统，很容易出现某些入口没人接管。如果确实赶上了，建议把上线时间往后推一个月，或者只上最确定的那个环节，其余等人员稳定之后再排。

关于时机的记录方法很简单，就是在决定上任何一个工具之前，写一句话说明为什么是现在。半年后回头看这句话，能判断当时的决定对不对。如果一句话写不出来，多半说明这个决定是被外部推着做的，不是自己的节奏。

工具应该上在已经跑通的环节上，而不是用来代替理清环节

环节没理清就上会怎样

最直接的结果是数字变成两份。手上的表格里有一份，系统里有一份。两边对不上时，没人说得清哪边是对的。这种局面比只有一个数字更难处理，因为多出来的那一份看起来更权威。它反而更耽误判断。

第二个结果是交接方式没有变化。系统里虽然建了任务和状态栏，实际交接还是靠群里说一句或者当面叮嘱。系统的状态字段被当成记事本，没有人真正依赖它推进工作。这种情况在上线后前两周最容易被掩盖。

第三个结果是字段口径对不上。系统里要求填一个数值，填的人不清楚这个数值算哪一段时间的量，于是同一栏里混着不同的口径。时间一长，这一栏的数据就没法用来做比较。它只能看，不能算。

第四个结果是买回来的功能闲置。买的时候按功能清单挑，上完才发现日常真正用到的只有其中几个入口。闲置的功能不消耗时间，但它消耗了钱和维护的注意力。每多一个入口，就多一个需要被记得的地方。

第五个结果是新人上手变慢。原本跟着做一周就能顶上手，现在要先学系统、再学流程，而系统里的流程又和实际做法不一致。新人不知道该信系统还是该信带他的人。学习的时间因此被拉长了一截。

要确认是不是发生了这种情况，可以在上线两周后做一次现场观察。不看报表，就看一天里大家实际怎么交接的。如果任务真实流转还在群里发生，系统里的状态栏只是被顺手续填一下，那系统的推进作用就还没有建立起来。

第二个动作是抽查系统的字段。随机挑几栏，问填的人这个数值算的是哪一段时间、包含哪些项。答案不一致的栏目先记下来。这类栏目在后续分析里会变成噪音，越早发现越好，最好在上线一个月内处理完。

第三个动作是找出被绕过的环节。把每天用的入口列一遍，标注哪些是必须进的、哪些是可进可不进的。可进可不进的那几个入口是重点，它们要么可以合并，要么说明流程里对应的一步本身就没有人负责。

第四个动作是把口头交接的内容记下来。连续记录一周，看大家在群里传的都是什么信息。这些内容就是系统里缺失的字段。把这一周的内容整理成一张清单，就是系统下一轮要补的东西，比凭空设计栏位准确得多。

最后一个动作是给系统里的每一栏找负责人。一栏没有负责人的时候，要么长期空着，要么填进去的内容没有人核对。两种情况都会让下游不敢用这份数据。把负责人补上，是把系统真正接进流程的第一步。

有一个具体案例。一家店上了协作系统之后，任务卡在待确认状态的平均时长反而变长了。查下来是因为原来口头一问就推进的事，现在要等对方登录系统去点确认，而对方不一定当天登录。多出来的这一步，抵消了系统带来的可见性。

这个案例的教训是，不是所有环节都适合加确认动作。确认动作适合用在责任重、金额大的交接上，用在日常小事的交接上只会增加等待。判断标准可以是差错的影响范围，影响范围大的加确认，小事的直接过。

另一个案例是两套系统各存一份顾客信息。客服在一边改，运营在另一边改，两边不一致时谁也不知道以哪边为准。最后的处理办法是把其中一边降级成只读，另一边的修改每天同步一次。降级之后，争议立刻少了很多。

边界条件是单人环节。如果某个环节从头到尾只有一个人做，中间加系统反而多了一层操作。这种环节更值得关注的是他的产出能不能被下游直接使用，而不是他有没有在系统里留下过程记录。过程记录对单人环节的价值相对有限。

记录这些问题的办法是建一个上线观察表，写上发现时间、现象、涉及环节、临时处理、是否已解决。上线后的第一个月密集记录，之后就按周记。表不用长，能让人看出问题是在收敛还是在增加就够了。

系统解决的是执行效率，解决不了环节之间没有定义这件事

理清环节的标志是什么

第一个标志是能说出交接点有几个。不是笼统地说有几个环节，而是能明确到某个环节做完之后，把什么东西交给谁。交接点的数量本身就是一个可以核对的指标。说不出来，就说明还没理清。

第二个标志是上游给的字段能列出来。比如做关键词清单的环节，需要上游给的可能是品名、规格编号、目标站点、目标价格档位。这些字段能一条条写下来，下游才有可能稳定地接住，而不是每次重新问一遍。

第三个标志是判断条件能被别人复述。如果一件事的取舍只能靠本人的经验，那么在别人手里就会出现不一样的结果。理清之后，判断条件应该能被写成几句话，别人照着做能得出接近的结论，误差在可接受范围内。

第四个标志是产出结构稳定。同一个环节这一期产出的东西和上一期结构一样，下游就不用每次都重新适应。结构一变，下游的接法就要改一次。改的次数多了，接的人就会自己另存一份，版本又开始分叉。

第五个标志是异常有固定的回查路径。出现对不上时，知道先查哪一段、再查哪一段，而不是从头翻一遍。有路径意味着环节之间的因果已经被想清楚了。这一点比有没有系统更能说明问题已经被理清。

检查是否理清，可以用一个动作来测。找一个平时不参与这个环节的同事，把写好的说明交给他，让他照着做一遍。他在哪一步需要回头问人，那一步就是还没写清的地方。这个测试花的时间不长，但指向非常明确。

第二个动作是画一张交接图。把环节排成一排，在每两个环节之间画一条线，线上写清楚传的是什么。凡是画线的时候犹豫的地方，就是交接点还没有定义的地方。犹豫的次数减少，说明图越来越接近真实。

第三个动作是对着上一期的数据反向走一遍。从最后的产出往前推，看每一步需要的输入能不能在上一份留存里找到。找不到的那一段，说明上游当时没有留痕，也就意味着重新做一遍的时候不能复现。

第四个动作是列出还不确定的事项。理清不等于所有细节都定死，而是知道哪些地方还有不确定。把不确定的事项和影响范围写下来，逐一安排验证的时间。承认不确定比假装确定更有利于推进，因为它能避免后面出意外。

检查做完之后要留一份记录，写明检查的日期和发现的问题。这份记录在下一次环节调整时可以拿来对照，看之前发现的问题有没有被真正解决。没有这份记录，同样的问题会被反复发现、反复讨论，却始终没有人负责关闭。

举一个可参考的例子。一家店铺把交接点梳理完之后，发现原本以为有十几个交接点，实际只有六个。多出来的那些是因为两个人互相以为对方负责，实际两边都在做同一件事。梳理掉重复动作之后，等于凭空多出了一个人力。

另一个例子来自关键词到竞品的这一段。原来的做法是关键词清单发过去之后，对方自己挑要盯哪些词。梳理之后，清单上直接标出哪些词对应哪一类对手，对方只负责补充。这一改，中间来回问的次数降了大半。

一个容易被忽略的边界是新老业务混在一起的时候。老业务的交接点早就形成了默契，不需要写；新业务没有默契，必须写。如果混在一张说明里，老的觉得多余、新的觉得不够。更合适的做法是分开写，各自维护。

还有一个边界是环境变化。物流方式换了、结算周期改了、平台后台改版了，原来的交接点可能需要调整。这类变化之后要主动检查一遍交接图，看有没有哪条线的输入已经拿不到了，不要等出了事故才发现。

关于记录方式，建议把交接图和一个说明文件放在一起。图给全局，说明给细节，两者版本号一致。每次调整时同时更新，避免出现图是新版、说明是旧版的情况。这一点在多人协作时尤其重要，因为不同的人看的可能是不同的版本。

先手写再上工具

手写的第一个作用是暴露问题。用最普通的表格跑一遍，哪里对不上、哪里要多问一句、哪里要等两天，全部会自己冒出来。系统的容错会把这些问题藏起来，让人以为流程本身是顺的，等到出事故才发现缝还在。

手写的第二个作用是改动成本低。表格改一栏只要几秒钟，系统改一个字段要走一轮确认和测试。环节还在调整的阶段，改动频率高，适合放在能快速改的地方。等形状固定了再搬，返工的量会小很多。

手写还有一个隐性好处，就是参与的人都知道数据从哪来。表格里的每一栏都是某个人自己填的，来源清楚。系统上线之后，数据是自动流过来的，一旦错了反而更难追到源头。这两种状态需要分别对待。

手写阶段的表格不用做得多漂亮。字段名写清楚、每栏的口径写在表头备注里、版本标上日期，做到这三点就够用了。追求排版和公式花掉的时间，不如多跑一轮流程，把没想清楚的地方补上，收益更实在。

手写通常要跑满两轮。第一轮用来发现问题，第二轮用来验证改过之后能不能重复。只跑一轮就上系统，等于把第一轮暴露出来的问题直接搬进系统。搬进去之后再改，涉及的人更多，代价也更高。

手写的具体做法可以定得很简单。建一张表，左边是被交付方需要的东西，右边是交付方手上有东西。两列对不上的地方就是接口缺口。这张表画一次通常要半小时，但它能把大部分模糊的地方一次性暴露干净。

跑第一轮的时候，建议把每次被打断的次数记下来。被问一句、被打一个电话、被临时拉进一个群，都算一次打断。打断次数最多的那个环节就是当前最堵的地方。这个数字比任何主观感受都更能说明问题在哪儿。

第二轮开始前，先针对打断最多的位置改一次做法，比如把口头交代改成固定格式的一条消息，或者把临时问改成提前一天收一次。第二轮再统计一次打断次数，两次一对比，改动有没有效就很清楚了。

手写阶段要留意一个陷阱，就是把表格做得过于复杂。公式套得太多的表，只有做表的人能看懂，别人接手要重新学一遍。手写的目的是让交接清楚，不是为了把表格做成产品。结构简单、字段清楚，就是好的状态。

最后要给手写阶段设一个结束点。跑完两轮、打断次数降到可接受的量级、交接点全部写下来，就可以结束。不设结束点的话，手写会一直延续下去，做的事情越来越细，却迟迟不进入下一阶段，前面的简化效果也会被拖没。

有一个具体的例子。一家店在手写阶段把交接从口头改成固定格式的消息，就三项内容，货号、数量、到货时间。改完之后，因为漏信息导致的错发在一个月里降到了零。这种改进不需要任何系统支持，只需要把要说的话固定下来。

另一个例子是关于判断条件的。原来挑关键词凭感觉，后来手写阶段把条件写成了三条可对照的规则。写下来之后才发现，其中有两条其实重复，第三条几乎没被用到。删掉之后，判断反而更快，不同的人做出来也更一致。

边界条件之一是数据量很小的时候。品类很少、订单很少的店铺，手写表格就完全够用，硬上系统是浪费。判断原则可以看每天需要人工处理的条数，条数在几十以内，表格的效率并不比系统低，维护成本还要小得多。

另一个边界是多人并行的场景。几个人同时改一张在线表格会出现覆盖，这时候手写阶段的表格就需要拆成各自维护、定期合并的形式。合并的时点定下来，比如每天下班前一次，避免两个人拿着不同版本做判断。

手写阶段结束时要留一份东西，包括交接点清单、字段口径说明、判断条件、异常回查路径。这四样就是迁移时的输入。少了哪一样，迁移的时候就要重新想一遍。把它们先在纸上写出来，迁移就变成一个搬运的动作。

迁移到工具的条件

第一个条件是输入输出的格式已经稳定。上游给什么、什么格式、什么时候给，这三件事不再来回商量。如果上游给的东西每次格式都不一样，迁移过去只会把混乱从表格搬到系统里，混乱本身并没有减少。

第二个条件是口径已经统一。同一个指标在一个团队里只有一种算法，写在哪里都一样。口径没统一就迁移，系统会把两种算法都固定下来。之后每个月的数字都会带着这个矛盾，越往后越难改。

第三个条件是有一份完整的样例数据。拿上一期的真实数据在系统里跑一遍，看看结果和手写结果能不能对上。对不上的部分先标出来，逐条确认是系统的问题还是手写的问题，不要直接改手写的结论去迁就系统。

第四个条件是有并行的过渡期。迁移之后的一段时间，两边同时跑，结果互相比对。这个阶段通常需要跨一个完整的结算周期，否则跨期的那一段对不上，看不出问题出在哪里，也说不清谁的数对。

迁移失败最常见的原因不是系统不好用，而是迁移的时候顺手改了流程。把两件事放在一起做，出了问题分不清是系统不适应还是新流程有问题。最后两件事都要推倒重来，前面省下的时间都还了回去。

检查第一个条件是否满足，看最近三期上游交过来的东西。把三期放在一起比一比，如果字段的顺序、名称、时间点基本一致，就可以判断格式已经稳定。三期里有两期不一样，说明还没有稳定，先去找上游对齐，不要急着迁移。

检查第二个条件，需要在团队里做一次口径提问。同一个指标同时问三个人，看他们回答的算法是不是同一套。答案不一致的时候，先解决这个不一致，再谈迁移。口径不统一是迁移之后最难返工的问题，代价比其它问题都高。

第三个条件的验证方式是拿真实数据试跑。选一期数据量中等的，不选最大的也不选最小的，在系统里完整跑一遍，把每一步的中间结果记下来，和手写的中间结果逐项对照。对不上的地方要追到底，不要用调整手写结果的方式让它对上。

第四个条件是要提前约定并行期的结束方式。并行多久、以什么标准判定可以停止并行，这两件事要在开始之前说定。标准可以定成连续两期上下数字一致，也可以定成关键字段完全一致。没有标准，并行期会一直拖下去，两边都要维护。

如果四个条件里有条件不满足，但业务上确实等不及，可以用小范围试行的办法。选一个站点或者一类商品先跑，其余维持现状。试行的范围要小到出问题不影响主流程，同时大到能暴露真实问题。试行结束再决定是否扩大。

一个值得参考的做法是留一份迁移对照表，左边是手写表的栏位，右边是系统里的字段，中间写格式转换规则。凡是对不上的地方就标红，逐条解决。这张表在迁移完成之后不删，以后系统改版时可以拿出来重新核对一遍。

有一个案例是关于并行期的。一家店规定并行两期，但第二期正好跨了月底，结算口径不一致，两边数字差了一截，于是并行期被延长到了第四期。后来回看，如果一开始就把并行期的起点避开结算边界，可以省掉两个月。

边界情况是系统供应商换人或者改版。这时候已经稳定的字段可能被调整，接法要重新确认。建议在迁移之后把输入输出的样例保存一份，包括当时的字段名和格式。有这份样例，下一次改版时可以直接对照，不用从头回忆。

另一个边界是季节性数据。用旺季数据迁移，字段里的数量级会比平时大很多，格式上可能出现位数变化。更稳的做法是平销期迁移，旺季来临之前再单独压测一次，看流程在量大的时候会不会卡住。

关于记录，迁移过程中建议记一份问题流水。每条写清发现时间、现象、原因、处理方式。这份流水在并行期结束时复盘一次，把重复出现的问题转成后续的检查项。流水本身不用给别人看，但重复出现的模式往往藏在这里面。

越是规则确定的环节越适合交给工具，越需要判断的越要留在手上

上工具的顺序

顺序排错最典型的表现是工具上了没人用。系统在那里，数据是空的，大家还是用原来的方式做。这种情况往往不是执行不配合，而是这个环节的判断依赖上一个环节的产出，而上一个环节还没准备好，交不出东西。

通常排在前面的是规则最确定的环节。比如数据的采集与汇总，取数范围、时间口径、汇总方式都能写死，不需要每次判断。这类环节搬到系统里最省事，也最容易看出效果，适合作为第一个上系统的位置。

排在中间的是有一定规则但需要判断的环节。比如关键词的归类、竞品的筛选，规则能定出七八成，剩下需要人来看。这类环节适合系统做粗筛、人工做确认的两段式处理，两边各做自己擅长的部分。

排在后面的是判断占比很高的环节。比如卖什么好这类决策，要考虑资金、库存周转、团队能力这些约束条件，规则只能提供参考。这类环节上工具的价值在于把参考信息备齐，而不是替人做决定。

顺序还要跟团队能力对一下。如果团队里没人能维护系统的字段和取值规则，就先别上那么复杂的。上一个没有人维护的系统，处境比手工表格更糟，因为里面的数据会慢慢变得不可信，还会拖累别的环节。

排顺序的时候可以先画一张表。横轴是六个环节，纵轴写三行，分别是规则确定性、对上游的依赖程度、出错的影响范围。三行打完分，顺序基本就出来了。这个打分不用精确，靠相对高低就足够做决定，花十分钟就能完成。

第一个上系统的位置建议选在取数与汇总。这个环节的规则最容易写死，改动最少，而且它一旦稳定，后面所有环节拿到的数字都跟着稳定。把这一层先做扎实，等于给后面每一步都省了一次核对，回报是逐层放大的。

第二个位置一般放在需要粗筛的环节。比如从大量候选里筛出一小批进入下一步，这种活儿重复度高，交出去省时间。但要把筛的条件写清楚，包括哪些进、哪些不进、边界情况怎么处理。条件不写清，筛出来的东西下游不敢用。

中间的判断环节要往后退。这类环节的产出会被后面好几步依赖，一旦定错方向，改动会牵连一大片。往后退一段时间，等前面的数据稳定了再上，判断的准确度也会提高，因为到时候手上的参考信息比现在多。

顺序定完之后要写一份时间线，写明每个阶段预计什么时候开始、上完之后的验收标准是什么。时间线不用很细，但验收标准要能判断真假，比如交接还需要额外解释的次数降到了几次以内。这条写清，后面才不容易糊过去。

有一个案例能说明顺序的差别。两家店同期上了同一类工具，一家从取数开始，一家从选品开始。从取数开始的那家，三个月后已经把六成的手工汇总动作省掉；从选品开始的那家，工具上完了，但输入的数据还在手工整理，效果没有出来。

这个差别的道理很朴素：越靠上游的环节稳定，下游得到的输入就越可靠。上游还在手工整理，下游用工具算出来的结果也是建立在手工数据上的，准确度并没有提高。工具解决的是执行，不解决数据的来源质量。

边界条件是团队的规模。三五人的团队，交接本来就靠面对面，上工具的顺序影响没那么大，可以先挑最费时间的那个环节。人数多、跨班次的团队，顺序就重要得多，因为交接次数成倍增加，上游不稳会一路放大到下一个人手上。

另一个边界是已经有历史数据的情况。如果店铺已经积累了几年的数据，可以考虑先把历史数据整理进系统，再上线新的流程。这样工具一上线就有参照，判断异常时有基线可用，而不是从零开始累积。

顺序的维护方式是每季度复看一次。业务变了、团队变了，合适的顺序也可能变。复看的时候对着当初的时间线，看哪一步实际推进得比预期慢，慢的原因是什么，是条件不够还是优先级变了。这份复看记录比时间线本身更有价值。

前期慢一点把环节理清，后面每一步都省力

给工具做减法

减法可以从一个问题开始，就是这个数是从哪里来的。如果一个系统里的数字是人工从别的地方复制过去的，那这一层通常可以去掉，改成直接引用来源。复制这个动作既费时间，又制造了两个版本，还要额外核对。

第二个线索是使用人数。只有一个人在用、而且只有他自己看得懂的系统，多数可以退回到表格。系统存在的意义是让多人共用一套规则，一个人用的系统其实只是一张造型复杂的表格，维护成本却按系统算。

第三个线索是登录次数。每天要打开多少个后台、每个后台打开几次，能反映真实的依赖关系。有的后台一周才开一次，却占了培训和交接的篇幅。这类入口值得考虑合并或者降级，把注意力留给高频的那几个。

减法不要一次做太多。同时下掉几个系统，容易让某些依赖它的人突然没有工具可用。更稳的做法是先停用一段时间，看有没有人来找。没人来找就说明确实可以去掉，有人来找就把留下的理由问清楚。

减完之后要复一次接口。系统少了，环节之间的接口也要重新确认一遍，看有没有哪一段的输入以前是靠某个系统自动带过来的，现在需要手工补。这一步很容易被漏掉，漏掉之后会在下一次结算时集中暴露。

做减法之前先做一次清点。把所有正在用的后台、插件、表格列出来，每一项写上用途、使用者、上次打开的时间。这份清单往往比想象中长，很多人第一次清点时会发现自己有将近一半的入口已经很久没进过了。

清点完之后按两个维度分组。一个是使用频率，另一个是这份数据有没有别的地方可以拿到。频率低又没有别的地方可拿的，先留着但降级，不再写进交接文档。频率低且有替代来源的，直接去掉，把替代来源的取数方法写清楚。

合并的时候要注意时间口径。两个系统里看起来是同一个指标，取数时间点可能不一样。合并之前要确认取数口径，否则合并之后的数字会变，别人会以为是自己看错了。口径确认的动作很简单，就是各取一次数，比一比。

减少入口之后，交接文档要跟着改。文档里还写着已经下线的系统，新人照着找不到入口，会以为是自己权限不够。文档更新的时点最好固定成每季度一次，或者每次增减入口时立刻改，别让文档和现实脱节。

最后一个动作是给留下的系统定负责人。每个入口有一个明确的人负责取数口径和维护，遇到疑难问题时知道找谁。没有负责人的入口在出问题时最容易变成无人认领，最后大家一起绕开它，前面的整理就白做了。

有一个典型案例。一家店清点之后发现有四个入口都在看销售数字，分别是后台报表、自己的表格、进销存系统、还有一个记账软件。四个数字平时对不上，每个月要额外花时间解释差异。合并成两个之后，解释的工作直接消失。

另一个案例是关于插件的。装了十几个浏览器插件之后，打开页面的速度明显变慢，而且没有人记得哪些是当初为什么装的。按清点清单过了一遍，只留了三个在用的。这个动作花的是一小时，省下的是每天的等待。

边界条件是合规与留痕的要求。有些入口不能随便停，比如涉及税务或者对账依据的部分，即使很少打开也要留着。做减法之前先确认哪些属于这一类，把它们单独列出来标注为不可停用，避免减完之后又不得不恢复。

另一个边界是交接期。如果在减法的同时正好有人离职或者入职，入口的增减会和人员变动缠在一起，容易出漏子。更稳的做法是错开，先完成人员交接，稳定一个月之后再动入口。

记录方法上建议留一份入口台账，写明名称、用途、负责人、最后打开时间、是否可停用。每季度更新一次。这份台账在下一次有人问这个入口能不能去掉时，就是现成的答案，不必再重新梳理一遍。

常见问题（FAQ）