项目型运维管理方式的挑战
学习资料： ITIL培训基地专家讲堂直播 300期视频回放当一个组织以项目的形式运作管理时，在管理上积淀是比较困难的。项目本身就是一个独立的权力结构，公司的组织机构是按部门、科室式划分，管理体系也多以部门职能划分流程，这时权力的矛盾就会在业务运作时产生，发生资源的略夺行为。要么部门难以管理，要么项目难以管理。
而项目是一个临时的组织，这种人力的汇聚与释放都比较麻烦，起用一名人力需要相当长的磨合期。而公司的任务往往是周期性的（最小时间单位很大），这时人力释放并不意味可以马上投入利用，这种痛苦没有经历过很难体会到，这比你在ERP中排生产计划还要难。
运维服务一般是以项目的形式管理的，项目内的作业与部门或公司的管理往往存在偏差。如果部门或公司处于强势地位，项目内的作业往往会被冲击，或者被动敷衍配合公司的管理。比如培训，站在部门或公司的角度希望搞员工能力提升的培训，这种计划安排，往往与项目内希望做的培训有非常大的出入。
项目的一线主管，往往认为公司或部门不是帮助他们，而是一个麻烦制造者。一旦项目数量大时，这种情况越普遍。因为项目越多，上层对规范、标准化的愿望就越发强烈，当一线主管花费越来越多的管理资源，配合公司的规范与标准时，对项目的控制力就会下降。一旦发生问题，上层领导就会认为是缺乏规范与标准化所致，形成一个恶性循环。
我经常看到一种现象，当某个项目发生个严重运维事件时，马上会短时间把管理资源堆积起来，对事件进行深入到可怕的分析，然后制订出一个非常完备的制度，要求每个项目进行落实。这种做法会起良性作用吗？
我怀疑，因为反应过度了，也有些缺乏理性。资源永远是有限的，你把多数的资源花在防止概率很低的问题上，而让那些概率较高的问题没有相应的管理资源去控制，你采用的措施会妨碍你达到目的。
对运维服务而言，你让客户用一个最重要的词说出他的要求，他们往往会说“稳定”。同样，运维服务管理也是最需要稳定的，救火堵漏的做法不可取。先稳定你的管理，再去谈改善。永远处于制度的发布与调整中，会让运维服务管理成为最大的运维风险。
我觉得此时领导者的作用非常重要。作为高层领导，由于缺乏细节信息，对自已的运维服务管理缺乏信心，一旦发生问题，就会过度反应，这种现象是非常可怕的。作为运维服务的管理部门，一定要想清楚自已应该做什么，你的管理边界在什么地方。你是一个政策制订者，不应该越过项目的边界去干涉项目的内部事务,这一切只需借助E8.ITSM系统的管理起来。
管理部门负责服务体系的维护与执行监督，及所有服务资源的调配，这才是最重要的。更细节层面，管理部门应该只扮演辅助角色。
学习了，看完之后感觉确实是这么回事，谢谢分享！ 永远处于制度的发布与调整中，会让运维服务管理成为最大的运维风险。
严重同意 永远处于制度的发布与调整中，会让运维服务管理成为最大的运维风险。
有道理，学习了！！！
页:
[1]