我们给七天过渡。病假、联系人和住宿当日退出排序；紧急调用保留在独立模块；接送只看上车点与班次，不看家庭住址；员工自报可用时间可随时修改，不因不填私人原因降低排序。七日后旧授权终止，新授权逐项生效。
七天里最先出问题的是夜间接送。
过去系统按住宿区域自动排三条车线，隐藏具体门牌却仍知道区域。新规则只看员工选择的上车点，一些人临时改点，第一晚两辆Innova多绕二十公里，一名员工错过末班。经理抱怨没有住址便无法优化。
红姨让司机和员工代表把常用公共上车点重新画出来。每个人可选主点和备用点，不解释为什么；确认班次后才将当晚名单给司机，次日不留在司机手机。平台可以用匿名人数优化路线，不能从路线反推谁住哪间屋。
一名员工住得远，任何公共点都要走二十多分钟。她愿提供精确接送地点，只限连续夜班。系统允许自愿细化，权限到当班调度，三个月后自动询问是否继续。最小化不是所有人都只准给同样少的数据，而是多给的人知道为哪一次、多长时间、可以收回。
第二个问题是事故联系人。
车站酒店一名厨工工作时晕倒，本人意识不清，独立模块按紧急条件开放联系人。值班经理查看后打电话，系统记时间和原因。家属到院后问公司从哪里有号码，员工入职时提供过，却未收到新用途说明。号码的使用合理，告知仍不足。
人力部向所有人补发一张小卡：什么情况会调用、谁可看、调用记录如何查、可否更新或不提供。有人选择不提供，要求事故时只联系指定同事；公司接受，并提醒最坏后果。选择有代价不等于选择无效，只要代价真实说明，不用少班惩罚。
第三个问题来自经理。
主管过去能看到员工病假结束日期，方便知道何时返岗；新系统将病假细节完全隔离后，排班只显示“当前不可用”与可用起日。一名员工提前复工，医务和人事已确认，系统未及时更新，少排两天。严凤承认流程断点，增加员工本人可查看和纠正可用状态，不必向主管说明病名。
员工数据保护若只做删除，会让该有的信息也断。七天过渡真正做的是把“经理想知道什么”和“经理完成工作必须知道什么”分开。前者可以无穷，后者通常更窄，却需要更准、更及时。
旧授权终止那天，我在系统里看到自己的签名变灰。旁边不是“无效”，而是“已终止，历史调用见封存日志”。过去
本章未完，请点击下一页继续阅读！