2.6 我为什么还要查看员工的私人表格

信息负责人给我展示了云枢科技的 CRM、项目和财务系统，流程看起来完整。一位项目经理随后打开自己的 Excel：“真正排期我用这个，正式系统只在周五补一次。”

那张表不是员工故意违规，而是正式系统没有解决他的每日决定。

我先请他用那张表排一次项目

项目经理每天根据客户优先级、工程师技能和待确认事项调整排期。正式系统只能记录最终日期，无法表达“客户资料未到但工程师暂时预留”这种中间状态。

他的表格解决了真实问题，也产生了风险：团队只有他能看懂，客户名称靠手工输入，周五补进正式系统时经常遗漏变化。与其要求立即停用，我先把它当成现有经营系统的一部分来理解。

这修正了我最初的判断。我原以为影子表格只是数据治理不严，现场证明它同时是员工为填补正式系统缺口创造的工作工具。

每个系统我都会问：谁使用，记录什么事实，什么时候更新，什么决定依赖它，与其他系统怎样交换信息，失效后工作怎么继续。

我也记录文档、群聊、邮件和个人表格。这些“影子工具”常常暴露正式系统缺少的灵活性，也带来版本、权限和人员离职后的风险。

系统图中，我特别标记一个事实在哪里第一次产生、谁能修改、哪个系统被下游当真。客户上线日期在销售表、项目系统和财务开票表中各有一份，但三者含义不同。把它们简单合并，只会制造新的冲突。

我会让员工展示正常工作，也问系统不可用、负责人休假、客户临时变更时怎样继续。这些异常路线往往藏在群聊和个人记忆里，也是后续必须保留或重设计的恢复能力。

两个系统都记录客户，不代表必须双向同步全部字段。我先确认哪个事实由谁负责、其他人何时需要，再决定传什么。

盲目连接会把错误更快复制到更多地方。系统图的目标不是追求一套软件包办全部工作，而是看清事实与动作怎样穿过工具。

云枢科技曾考虑让 CRM 自动覆盖项目系统的上线日期。抽样后发现，CRM 记录的是销售承诺日期，项目系统记录的是当前预计日期。我们没有同步覆盖，而是分别保留并显示差异，由项目负责人确认是否需要调整客户沟通。

共同客户身份可以连接，不同目的的日期不能因为字段名称相似就互相覆盖。

它可以读取哪些系统、用什么身份、只能查询还是允许写入，必须逐项说明。第一阶段通常只读并保留来源；任何写回动作都要有确认、日志和失败处理。

业务负责人决定哪些事实需要跨流程共享，系统负责人说明访问和故障边界，数据主人确认含义，一线岗位验证真实工作。我把这些要求整理成执行约束，工程师再决定具体实现。

系统连接失败时，AI 不能继续使用过期资料而不提示。重要来源不可用，应显示最后更新时间、缩小任务或转回人工。恢复后也要确认中间产生的记录是否需要补齐。

我随机选一笔订单，请销售、项目和财务沿着系统图找出客户承诺、当前计划、开票条件和最后修改人。任何一项找不到或出现两个“最终版本”，就标成待处理事实。

我也请一位不熟悉项目的人按照图追一次。如果仍必须找某位老员工口头解释，说明关键知识还没有进入共同系统。

事实	正式系统	员工实际补充	私人工具为什么存在	不能直接怎样改
客户目标	CRM	销售笔记和群聊	CRM没有保存原话与不确定性	不把聊天摘要自动覆盖CRM
产品能力	产品资料	售前个人文档	正式资料更新慢，例外判断无入口	不把个人判断当成已发布能力
项目排期	项目系统	项目经理Excel	正式系统不能表达预留和等待条件	不先删除表格再要求补录
合同范围	合同文档	本地报价和聊天确认	修改过程分散	不让最新文件名自动成为权威版本
应收与回款	财务ERP	财务催款表	需要记录跟进和客户上下文	不让其他系统覆盖财务事实

我选择先保留项目经理的表格，同时把它解决的中间状态写进后续目标流程。只有替代能力、负责人和退出条件成立后，旧表格才能正式停止。

系统图说明资料在哪里，仍不能说明它是否足以支持 AI 判断。下一节进入数据用途、缺失、历史偏差和权限：有数据为什么仍不能马上做 AI。