第六部分讨论的是报表：它如何不再是一份要花两天拼凑的文件，而变成一个随时打开就能看到当前状况的视图。至此，我们在六个部分中搭建的全景已经完整：电子表格何时不再是答案、到底是哪个文件在支撑公司运转、迁移前的数据清洗、迁移的先后顺序、谁能看到什么，以及手工报表的终结。

剩下的，是决定这一切能否见效的部分：投入生产后的第一个月。凡是做过这类项目的人都知道一件事：大多数迁移并不是在建设阶段失败的，而是在使用的头几周失败的。系统能用，数据也在，界面也没错，可真正的工作却悄悄回到了旧文件里。本部分要讲的就是这种情况为什么会发生，以及一份能防止它发生的计划。

抵触不是固执，而是风险计算

第一周你首先会遇到的是团队的迟疑。常见的错误是，老板把这种迟疑理解为抗拒变革或偷懒，并用施压来回应。其实通常两者都不是。

以前打开文件两分钟就能完成任务的员工，现在需要十分钟去学习同一个界面里的操作路径。站在他的角度，他是在为一个别人告诉过他、但他还看不到的好处支付今天的成本；而且他要向上级负责的是今天的产出，而不是项目的成败。这种迟疑完全合乎理性。

如果旧文件的负责人恰好是一个靠熟悉这份文件在公司立足的人，迟疑还会加剧。曾经是某个文件唯一参照的人，可能担心系统会让自己的角色变得多余。无视这种担忧并不能消除它，只会把它压到暗处。正面应对效果更好：在新的安排中给这个人一个公开明确的角色，让他负责本领域的数据质量，从守着一份文件的人，变成数据本身的权威参照。

第一个月真正的变化，是工作变得可见了。数据存在文件里的时候，延迟录入是看不见的。而在系统里，谁在什么时候录入了什么，都有记录。这会让踏实做事的人感到安心，也会让习惯了灵活处理的人感到不自在；与其让大家两周后自己发现，不如在第一次会议上就开诚布公地说清楚。

悄无声息地回到旧文件

第一个月里最危险的事情，并不会大张旗鼓地发生。会上没有人反对系统，但某人电脑上仍开着一份旧文件的副本，他因为更快而在里面记录，打算周末再录进系统。通常他并不会这么做。

这会带来最糟糕的结果：真实数据的来源从一个变成了两个。项目开始前，你有一份大家都认可为参照的、并不准确的文件。现在你有一个不完整的系统和一份不完整的文件，没有人知道哪个更新。你的处境比起点还糟，这正是ERP项目为何失败，以及如何让你的项目成功一文中讨论过的模式之一。

只要留心，信号会很早出现：会上引用的某个数字在系统里根本找不到；上线两周后，团队群里还在分享文件；某位员工要求导出数据到系统外处理，却再也没有导回来。对这些情况，都不要靠指责个人来处理。只问一个问题：文件给了他什么，是系统没有给的？答案通常是缺少一个步骤、缺少一个字段，或者某条路径比必要的更长。一旦知道了，这些问题几天内都能解决。

迁移之后才暴露、而不是之前就暴露的缺口

无论你事先像第三部分所说的那样把数据清洗得多么彻底，总会有一些缺口只能在第一笔真实业务时才被发现。道理很简单：文件容忍空白，空着的单元格就一直空着，没有任何东西会阻止你开出发票。而系统会要求填写这个字段，因为后续某个步骤依赖它。

这个阶段通常会冒出来的问题：

  • 客户和供应商资料不完整。某个客户只登记了名称，没有税号、地址或书面记录的联系人，这些信息过去都是需要时再口头询问。
  • 期初余额对不上。某个客户或某个商品的期初数字与旧文件中的不一致，差额在第一份对账单上就会暴露出来。
  • 从未分类的状态。待处理的订单、部分付款、从未结清的退货。在文件里，它们只是页边的一条备注；在系统里，它们需要一个明确定义的状态。
  • 多种计量单位和价格。某个商品按箱销售、按件采购，对不同等级的客户定价不同，而这一切都记在销售负责人的脑子里，从未写下来。
  • 背后没有任何规则的例外。某个客户多年来一直享受特殊条件，却没有任何文件依据，所以没人知道该如何在系统中定义它，也不知道谁有权批准。

这些都不能证明迁移失败了。恰恰相反，这是迁移带来的第一个真正的好处：系统把文件掩盖的问题暴露了出来。但处理这些问题需要纪律。把每一项都记录在同一张公开的清单上，写明负责给出答案的人和关闭日期。如果每个情况都在私下单独处理，下个月它就会以另一种形式卷土重来。

只做一次的培训是不够的

在陷入困境的项目中，最常见的模式是在上线当天只做一次培训，所有人都参加，把整个系统从头到尾讲一遍。之后大家回到工位，大部分内容都忘了，因为他们是在还用不上的时候听到的。

行之有效的替代做法基于三条原则：

  • 按岗位培训，而不是按系统培训。会计不需要仓库界面，销售负责人也不需要权限设置。每个团队只学习自己每天要走的路径，更短，也更有针对性。
  • 使用一周后再培训一次。真正发挥作用的是第二次培训，因为其中的问题都是来自日常工作的真实问题，而不是假设。而在不同团队中反复出现的问题，会准确告诉你哪个界面不够清楚。
  • 用图片而不是大段文字来编写文档。每个岗位一页纸，按顺序列出步骤并配上截图，张贴出来或发给大家。上线后的大多数问题是记不住的问题，而不是看不懂的问题。

每个团队里还需要有一个大家首先会去问的人，因为员工在提交支持工单之前，会先问身边的同事。这个非正式的角色缩短响应时间的效果，胜过任何外部支持渠道。这种变革管理并不只适用于告别电子表格，我们在如何成功实施ERP一文中，把它作为实施阶段的一部分做过介绍。

Origami的观点

我们把上线日视为项目的中点，而不是终点。一个系统不会仅仅因为能用就在公司里扎根；只有当它成为完成当天工作的最短路径时，它才会扎根。旧路径比新路径更快的每一天，都是在悄悄地与项目作对的一天。

所以在第一个月，我们会维护一份公开的问题记录清单并为每项设定关闭日期，同时衡量实际使用情况，而不是凭印象：谁在登录，哪些业务是在发生时就录入的，以及人们在哪个界面上卡住了。这正是我们在我们的服务中构建定制系统时所采用的做法，因为在第一周修复一个小卡点只需一个小时，而拖到两个月后再修复，付出的代价则是整个团队的信任。

三十天计划

这是一份可以照着执行的计划，它最重要的特点是每个阶段都有明确公布的终点：

  • 第1-7天：有期限的并行运行。工作同时记录在系统和旧文件中，目的只有一个：对比。周末抽取一个小样本，比较两边的数字，并按原因而不是按金额大小记录每一处差异。
  • 第8天：旧文件改为只读。这是整个计划中最重要的一步。文件仍可随时查看，但任何人都不再往里写入。如果没有公布明确的关闭日期，并行运行就会无限期地持续下去，最后总是旧文件胜出，因为它更省事。
  • 第8-14天：第二次培训并填补缺口。针对实际出现的问题，为每个团队安排一次简短的培训，并关闭缺口清单上排名前五的事项。
  • 第15-21天：衡量使用情况。检查谁在真正使用系统、谁没有，对每一笔延迟录入的业务都问一问原因。你从中了解到的，是路径是否清晰的信号，而不是个人纪律的问题。
  • 第22-30天：稳定与复盘。关闭剩余的问题记录，完全从系统中生成第一份月度报表，并与各团队负责人坐下来谈半个小时，找出还有哪些工作在系统之外进行、原因是什么。

衡量成功的诚实标准，不是问卷里的团队满意度，也不是在用界面的数量。它是一个时刻：有人在没有被要求的情况下，不再打开旧文件。到了那个时候，系统就不再是你在管理的一个项目，而是公司的工作方式。

系列结语

在七个部分中，我们走完了整条路线：电子表格已经超出极限的信号、告诉你哪个文件才是你真正系统的盘点、数据清洗、迁移的先后顺序、权限设置、把手工报表变成实时视图，以及最后度过第一个月。

值得记住的结论是：Excel是一款出色的工具，问题从来不在工具本身，而在于人们让它承担了什么。转向系统与其说是一次技术升级，不如说是一个决定：公司的数据属于公司，而不属于某个文件或某个人。而这一切从一小步开始：打开如今支撑你公司运转的那个文件，问一问是谁在更新它、什么时候更新，以及如果那个人不在会怎样。

参考来源