[p=30,2,left]学习资料：IT运维管理社区专家讲堂直播300期视频回放

[p=30,2,center]

当一个组织以项目的形式运作管理时，在管理上积淀是比较困难的。项目本身就是一个独立的权力结构，公司的组织机构是按部门、科室式划分，管理体系也多以部门职能划分流程，这时权力的矛盾就会在业务运作时产生，发生资源的略夺行为。要么部门难以管理，要么项目难以管理。

　　而项目是一个临时的组织，这种人力的汇聚与释放都比较麻烦，起用一名人力需要相当长的磨合期。而公司的任务往往是周期性的（最小时间单位很大），这时人力释放并不意味可以马上投入利用，这种痛苦没有经历过很难体会到，这比你在ERP中排生产计划还要难。

　　运维服务一般是以项目的形式管理的，项目内的作业与部门或公司的管理往往存在偏差。如果部门或公司处于强势地位，项目内的作业往往会被冲击，或者被动敷衍配合公司的管理。比如培训，站在部门或公司的角度希望搞员工能力提升的培训，这种计划安排，往往与项目内希望做的培训有非常大的出入。

　　项目的一线主管，往往认为公司或部门不是帮助他们，而是一个麻烦制造者。一旦项目数量大时，这种情况越普遍。因为项目越多，上层对规范、标准化的愿望就越发强烈，当一线主管花费越来越多的管理资源，配合公司的规范与标准时，对项目的控制力就会下降。一旦发生问题，上层领导就会认为是缺乏规范与标准化所致，形成一个恶性循环。

　　我经常看到一种现象，当某个项目发生个严重运维事件时，马上会短时间把管理资源堆积起来，对事件进行深入到可怕的分析，然后制订出一个非常完备的制度，要求每个项目进行落实。这种做法会起良性作用吗？

　　我怀疑，因为反应过度了，也有些缺乏理性。资源永远是有限的，你把多数的资源花在防止概率很低的问题上，而让那些概率较高的问题没有相应的管理资源去控制，你采用的措施会妨碍你达到目的。

　　对运维服务而言，你让客户用一个最重要的词说出他的要求，他们往往会说“稳定”。同样，运维服务管理也是最需要稳定的，救火堵漏的做法不可取。先稳定你的管理，再去谈改善。永远处于制度的发布与调整中，会让运维服务管理成为最大的运维风险。

　　我觉得此时领导者的作用非常重要。作为高层领导，由于缺乏细节信息，对自已的运维服务管理缺乏信心，一旦发生问题，就会过度反应，这种现象是非常可怕的。作为运维服务的管理部门，一定要想清楚自已应该做什么，你的管理边界在什么地方。你是一个政策制订者，不应该越过项目的边界去干涉项目的内部事务,这一切只需借助E8.ITSM系统的管理起来。

　　管理部门负责服务体系的维护与执行监督，及所有服务资源的调配，这才是最重要的。更细节层面，管理部门应该只扮演辅助角色。

学习了，看完之后感觉确实是这么回事，谢谢分享！

永远处于制度的发布与调整中，会让运维服务管理成为最大的运维风险。
严重同意

永远处于制度的发布与调整中，会让运维服务管理成为最大的运维风险。
有道理，学习了！！！