系统运维-去手工

企业IT系统产品团队，在无项目、日常运维阶段，难免做的事情无法体现价值，缺少方向。将运维工作，美名曰去手工。既体现了为业务带来的价值，也通过量化指标、价值分析倒推团队每月版本计划。

维护去手工作业清单，包括

• 版本月份

• 手工类型

• 优先级

• 建议方法

• 关联系统

• 需求部门/角色

• 手工操作内容

• 业务现状

• 建议方法

• 案例

• 预期收益

• 开发人员

• 状态

• 备注

当然不是每一项都是必填信息，其中关键的是角色/现状/解决方法，从而确定需求。已经预期收益，可通过手工耗时、所占工作比例、操作人数来体现。预期收益指标，既是排优先级的一个关键考量因素，也是到了团队总结工作时价值的体现。

---

其实去手工的本质，是在解决数据问题。信息化系统本来玩的就是信息流。数据问题，体现在四个方面

• 缺失

• 拉通

• 提升

• 手工计算->系统计算

最能带来价值的，是前三项。最后一项，是运维阶段最常处理的，但却是最拿不出的结果，带来的往往是效率的提升。因此在梳理去手工需求时，需有意识的按照数据维度分类，注重解决数据缺失、拉通以及提升数据质量的需求。

---

另一个在梳理需求阶段需注意的，是业务提出的针对顽疾的解决需求，往往是打补丁的需求。因为长期困扰业务的问题，往往不是简简单单能解决的。不然业务早就解决了，还能长年留在那里？因此当业务代表提出，这个需求很重要，能解决公司的长期痛点时，要留意确实是优化方案、改善业务，还是打补丁方式的“歪门邪道”方法？打补丁没价值、浪费开发资源不说，更严重的是若考虑不周，反而会起到适得其反的影响，导致陷入到这个问题中，成功背锅。

以供应链降库存运动为例，为何每次降库存运动的结果，是短期内指标下来了，长期看库存不降反增？就因为针对降库存的举措，指标不治本，把表面问题处理下，供应商先别发货，能发给渠道商的都推出去。短期内看数据确实变好了。但业务模式没有改变，产销会没有，物料需求计划不准，没有替代料关系，封存库存呆滞。过一段时间库存又会上来了。而且之前的解决方案，使系统产生的应激反应，导致复原的问题只会比之前更加严重。

以纯业务举例，看似与IT系统的运维工作无关，其实道理是相同的。针对系统顽疾，往往对应的是业务顽疾，贸然打补丁，只会在你想不通的其他场景，产生更多更严重的问题。顽疾问题，先出优化方案，确定了可行性再去做，拒绝打补丁工作。当然，优化方案，往往就意味着启动一个项目了，而不属于运维工作范畴内。