为什么传个SAP请求要这么费劲？

有一天下班班车上，旁边的同事问我手机流量多不？我说还行。她让我共享热点，打开笔记本连接VPN，快速修改SAP系统配置，发布请求立马生效，及时解决了用户的问题。

跟同事交流，说之前东家为了不让内部顾问经常传输请求导致SAP系统发生故障，采取一周只能传输两次请求的做法，而且每次传请求前都需要填OA申请，附上开发说明书、配置说明书和测试报告，流转很多审批环节到达Basis后统一传输，哪怕只是改个字母改个栏位，这些流程都必不可少。

之所以这么费劲，就是想减少或者避免SAP系统发生故障的概率。

同事的回答一针见血：即使这样做，该出问题的迟早都会出问题。

我叹了口气，深表同意。

有时候很多东西看似有管起来了，有流程固化了，但实际上整个过程规则和逻辑并不严谨，或者只是想当然的严谨，比如：没人会去认真检查你的三份文档是不是真的写得完整和正确；没人会去注意你的文档跟系统的修改是不是一致的；没人会去审核针对这个需求系统这样修改是不是合理的，有没有错误；没人会去问你是不是真的做了测试，请求号是否都传输了；

这些问题仅仅依靠流程审批，一周传2次请求的做法是无法解决的，既然无法解决，那“该出问题的迟早都会出问题”。很多人闭着眼睛签字，出问题只怪提单传请求的人，那设置这套僵硬流程的意义又在哪里呢？

经历过那么多的SAP项目，基本上很多企业传输请求都不复杂，内部顾问和比较资深的开发都有权限，而且是随时能传。再不济也只是填个申请单，审核过了就能传输了，也从来没有因此发生过导SAP出大故障的情况。

再说了，传输个请求能出什么大故障？有什么疏漏疏忽问题及时修改再传输一次就好了，谁能保证永远不犯错误，做事永远滴水不漏？出错并不可怕，可怕的是苛刻的试错成本！

最后想说的是：管理和流程不应该成为拖垮工作效率和降低用户体验的绊脚石。想当然以为都管理起来了，实际上啥也没有。而杜绝问题如果仅依靠少做或者不做来解决的话，无异于因噎废食！（因为吃饭可能会噎着，所以一周就吃两顿饭~）