第一百二十四章　我的旧签名批准了这张表 (第1/2页)
　　
　　把时间拨回二〇一一年一月十七日，阮秋请了三天病假。
　　
　　她不是重病。孩子从城外来澜城过短假，夜里发高烧，红姨陪她去医院。医生建议孩子观察，阮秋作为唯一在场家属请三天。青川酒店人事按规定批准，病假工资和床位都没有问题。
　　
　　她回来后，二月份排班从二十四个班降到十七个。
　　
　　主管解释旺季结束，所有人班次都少。阮秋与同岗位六人比较，别人降两到四个，她降七个；固定楼层也换给一名临时转正员工。她问原因，主管给她看系统建议：阮秋“近期连续性较低，宜作弹性补位”。页面没有红黄绿，只是一行灰字。
　　
　　红姨把打印页拍在我桌上。
　　
　　“你不是停了？”她问。
　　
　　我先看签字。系统建议功能由平台运营委员会十二月二十九日通过，标题《节后人员优化排班》。批准链最上方引用董事会年度授权，授权签署日期二〇一〇年一月八日，我的名字在第一位。
　　
　　那天我们审预算和历史责任，也通过一揽子日常授权。其中“运营安全与人员连续性”允许人力部在合法、必要、最小范围内使用岗位、班次、培训、住宿安排与紧急保护数据，具体模型由运营委员会审。没有人把稳定性排序单独送回董事会，因为委员会认为只是排班工具。
　　
　　“我的签名不是批准这张表。”我说。
　　
　　红姨看着我：“可没有你的签名，它能不能出来？”
　　
　　不能。
　　
　　旧签名不是无限授权，却是权限链的一段。若我只说运营委员会越界，便像当年每个老板都说自己只催结果，不知道方启荣如何找一笔差不多的钱装进去。制度比黑桌正规，责任也不能因分了七层便蒸发。
　　
　　我让周萍调完整审批和日志。
　　
　　软件公司在颜色隐藏后，按严凤要求提交三个修订选项。第一，完全删除稳定性评分，只显示员工主动填写的可用时间；第二，保留出勤与换班预测，不使用病假、住宿和联系人；第三，后台保留全模型，前台只给排班建议。严凤推荐第二，运营委员会为了“不中断现有优化”选了第三，条件是建议不得用于薪酬、续约和处罚。
　　
　　阮秋的三天病假直接进入模型。联系人没有扣分，住宿也没有；单是“近八周连续病假”便让排序下降。主管看到建议后把固定楼层给别人，没有写这是处罚。他甚至认为自己在保护阮秋，怕她孩子再病时换班困难。
　　
　　“你问过她吗？”红姨问主管。
　　
　　“她请假时说孩子需要照顾。”
　　
　　“三天以后呢？”
　　
　　主管没有问。
　　
　　算法没有决定她少七个班，一个人决定了；那个人也没有恶意，只把一条概率当成她接下来一个月的生活。
　　
　　黎真查到系统建议在四家公司被调用四百余次。大多数只用于填空班，其中六十二次影响固定班，二十一人因病假、临时换班或住宿距离下降排序。没有证据显示工资单自动扣款，却有些人因班次减少实际收入下降。
　　
　　严凤要求给她机会解释。
　　
　　董事会临时会议上，她带了预测准确率。使用建议后，临时缺岗下降，经理排班时间缩短，连续超时也减少。若全部关闭，春节前酒店和供应夜班会回到人工拼表。
　　
　　“我没有用病名，也没有看家庭内容。”她说，“系统只看能不能按计划来。酒店不能每天临时找人。”
　　
　　红姨问：“病假批准以后，为什么还要在下一月再付一次？”
　　
　　“不是付，是预测。”
　　
　　“阮秋少了七个班，工资少了。你叫它什么，她付的都是钱。”
　　
　　严凤说，经理不应把建议当处罚，责任在执行培训。
　　
　　“你把人按稳定性排好，再说经理不该按顺序用？”郭玉兰问。
　　
　　严凤停了几秒。她承认产品设计会诱导使用，但坚持不能因为误用便放弃所有分析。
　　
　　梁仲平提出保留不含病假和保护数据的两周负荷模型，只看已经排的工时、岗位资格和本人申报可用时段。其余数据封存用于调查，不再进入建议。受影响员工按少班事实补偿，不必证明经理有歧视故意。
　　
　　红姨第一次没有反对他。
　　
　　严陆担心补偿范围。若二十一人都按过去平均班次补，可能把旺季自然下降也算公司责任。黎真提出用同岗位、同项目、同月份对比，排除整体缩班，差额再看具体调班记录。阮秋的七个少班里，三到四个可归系统影响，余下属于淡季。
　　
　　“她到底少三还是四？”赵坤问。
　　
　　没有任何表能绝对回答。主管若没有建议，可能也会调一部分；同事是否愿意换班又会改变。最后按四个班补，取对员工较有利的合理值，并恢复后续平等排班。二十余人逐项核，不一律给同数。
　　
　　我在会上提出撤销自己的年度授权，所有涉及保护资料的用途重新列举。
　　
　　律师提醒，不能只撤一张签名。若当夜系统失去住宿与紧急联系人权限，员工接送和事故联络会中断。需要先拆功能，再撤授权。
　　
　　我们给七天过渡。病假、联系人和住宿当日退出排序；紧急调用保留在独立模块；接送只看上车点与班次，不看家庭住址；员工自报可用时间可随时修改，不因不填私人原因降低排序。七日后旧授权终止，新授权逐项生效。
　　
　　七天里最先出问题的是夜间接送。
　　
　　过去系统按住宿区域自动排三条车线，隐藏具体门牌却仍知道区域。新规则只看员工选择的上车点，一些人临时改点，第一晚两辆Innova多绕二十公里，一名员工错过末班。经理抱怨没有住址便无法优化。
　　
　　红姨让司机和员工代表把常用公共上车点重新画出来。每个人可选主点和备用点，不解释为什么；确认班次后才将当晚名单给司机，次日不留在司机手机。平台可以用匿名人数优化路线，不能从路线反推谁住哪间屋。
　　
　　一名员工住得远，任何公共点都要走二十多分钟。她愿提供精确接送地点，只限连续夜班。系统允许自愿细化，权限到当班调度，三个月后自动询问是否继续。最小化不是所有人都只准给同样少的数据，而是多给的人知道为哪一次、多长时间、可以收回。
　　
　　第二个问题是事故联系人。
　　
　　车站酒店一名厨工工作时晕倒，本人意识不清，独立模块按紧急条件开放联系人。值班经理查看后打电话，系统记时间和原因。家属到院后问公司从哪里有号码，员工入职时提供过，却未收到新用途说明。号码的使用合理，告知仍不足。
　　
　　人力部向所有人补发一张小卡：什么情况会调用、谁可看、调用记录如何查、可否更新或不提供。有人选择不提供，要求事故时只联系指定同事；公司接受，并提醒最坏后果。选择有代价不等于选择无效，只要代价真实说明，不用少班惩罚。
　　
　　
　　
　　（本章未完，请点击下一页继续阅读）