首页 > 人工智能 > 正文

IT服务治理(ITSM)前提:变更治理过程

2011-08-22 14:12:30  来源:CIO时代网论坛

摘要:当IT组织努力进步效率和效果之时,他们必须在进步贸易IT服务质量的同时减少无计划的反馈性工作。来自治理方面的压力如此之大,IT前辈面对这种局面也很无奈.......
关键词: IT服务治理 ITS

  当IT组织努力进步效率和效果之时,他们必须在进步贸易IT服务质量的同时减少无计划的反馈性工作。来自治理方面的压力如此之大,IT前辈面对这种局面也很无奈,关于IT治理有无数的陈词谰言,听起来不错,但投资收益却毫无改善。而变更治理却是一个能真正起作用的关键IT服务治理ITSM)过程。当IT组织努力进步效率和效果之时,他们必须在进步贸易IT服务质量的同时减少无计划的反馈性工作。来自治理方面的压力如此之大,IT前辈面对这种局面也很无奈,关于治理有无数的陈词谰言,听起来不错,但投资收益却毫无改善。而变更治理却是一个能真正起作用的关键IT服务治理ITSM)过程。


  有一点很清楚,变更治理并不是一个能解决所有题目的神奇药剂。然而它在进步可用性、安全性和灵活性的同时的确可以大大减少无计划的工作,这样能使更多的员工从事有计划的项目。有可靠的证据证实,这尽不是一个仅仅听起来不错而不能被实现的的陈词谰言。


  人为误差在设计、编码和操纵中蔓延。任何对系统的变更都会造成某种程度的风险,并将产生一个消极的结果。


  据IDC的最新研究表明,近80%的网络可用性事故来源于人为误差。一些组织甚至超过了这个数字。不管怎样,当事件发生时,项目被搁置、资源被调换,直到危机得以缓解。这会导致项目积存和治理失败。


  所有的事情都是一样的,一个系统事故很可能起源于一个变化。是的,环境题目和硬件故障可能是一种原因,但是其概率要低一些。人们往往将百分之八十的维修时间花在试图寻找究竟发生了什么变化。假如能够尽快解决,你数据中心的可用性会变得更高,IT职员将会有更多的时间往关注计划性工作。


  尽管证据表明变更治理和规范的流程是有效的,但在IT行业里有一个很普遍的“牛仔”心态,即员工不喜欢被告知他们必须遵循一个过程。要执行变更治理,或关于它的任何过程,必须有意识地往改变这种文化。


  执行变更治理需要考虑的内容


  在这里我就不重复《ITIL服务转变》中提到的有关变更治理的内容了,我想回顾一下我们真正碰到的一些题目,并对那些在设计和执行变更操纵过程中经常出现的题目进行解释。


  促进文化变革。文化变革的需求并没有得到太多的重视。事实上,正种心态往往也导致了失败。在一个进程的设计和执行期间,要留意寻找合适的人选。对其进行培训,提供交流和预警机制。要及时对工作描述和补偿计划进行更新,使其适合整个进程。最后但同样重要的是,IT治理、ITSM治理和变更治理过程中用户和经理必须努力学习,不断增强对变更治理的需求。


  为什么要有一位变更经理?必须有一个人来为平衡风险或规避风险负责。这个人必须具有大局观,确保在局部层面看起来不错但更高层面可能出题目的变更不被执行。例如,某个网络治理职员可能以为升级一台交换机是低风险的,由于他没有意识到这个改变发生在周末的账户统计期间,这也就暗躲了一份风险。


  要有重点!最好是设计一个过程并在一个特定的IT层面执行,在这一层面业务和IT部分都愿意以该过程为原型并对它进行调试。在一个小范围内变更一个过程比追求一个全有或全无的方法更轻易且政治风险更小。


  从点滴做起。随着复杂博狗性的增加,文化转换的难度和长期持续的变更治理风险也增加了。此时,需要对持续过程改进进行规划,同时要制定发展蓝图以确定过程将随着新版本进行演变。但是,一定要确保从简单做起逐步改进。有时侯变更治理的开始可能是最艰难的。


  多模式。ITIL的变更治理过程可识别多模式的用途:标准的、紧急的、次要的、正规的和主要的。这些仅仅是适当平衡风险、本钱和时间的工作流程。事实上,一个组织可以有多种模式,只要这些模式有实际意义且它们清楚何时遵循何种模式。实施变更治理的组织要适应他们的各种模式,从而具备适当的灵活性和风险治理能力。


  标准的变更模式是至关重要的。谈到模式,标准的模式使低风险、可猜测的变更得以被记录和实施。这些变更不需要提交变更顾问委员会(CAB),这样IT部分就有了更高的灵活性。它们仍然需要仅在授权变更窗口被执行,同时必须被记录以便人们能轻易地回答这个题目“有什么改变吗?”随着时间的推移,符合必要标准的变更应该经过正式审核并遵循这个模式。组织中的大多数变更应该遵循这个模式。备注:假如变更由于任何原因出现明显的题目,那么必须有一种方式来正式撤销变更的标准等级。


  留意紧急变更。对组织而言,紧急变更所承担的风险是最大的。特别留意不要让IT职员以为紧急变更是一个为了弥补计划缺乏而对生产做匆促变更的好方法。紧急变更应该是一个为紧急事件,随后会被CAB、相关副主席或CIO所检测和调查,从而确定为什么企业会陷进危险当中。


  判定变更失败的标准。很多人经常争论是什么导致了一次失败的变更,他们经常将个人、团队行为目标和报酬联系在一起。假如发生偶然事件或变更无法按计划完成,就将一个变更应被视为失败。留意这两个因素——假如一个IT服务产生负面的影响,这种变更是失败的。当变更发生,但不能严格地按计划往执行,它被标记为一个失败的变更,同时会执行相反的计划。失败一定不能被糖衣所包裹。变更的能力必须随着时间的流逝不断进步。假如变更结果是不可预知的,就说明有些事情是常错误的,必须立即改正。


  变更探测。自动化工具可以帮助检测并与一项配置中核准配置的变更进行通讯。利用这些工具,一个团体可以从字面上保证系统未被以任何方式修改,且变更治理过程正在被跟踪。这是非常重要的,由于业务运营和信息安全需要及时了解是否有变更发生。


  责任。IT职员必须遵循变更治理过程,假如他们没有遵循,则必须有明确的处理办法。质量专家W.EdwardsDeming说在一个过程中你只能做两件事——或者遵循它或者正式变更它,没有其他的选项。并且人们不能自发地偏离过程,治理上对过程的确认是很有必要的,这可以降低风险。


  变更治理对IT行业而言是一个关键的控制过程。它尽不是一个用于满足监管机构官僚控制的程序,事实证实对所有组织而言它都是有好处的,包括进步可用性、降低本钱、服从治理、减少安全漏洞等。


第三十八届CIO班招生
国际CIO认证培训
首席数据官(CDO)认证培训
责编:qwenf

免责声明:本网站(http://www.ciotimes.com/)内容主要来自原创、合作媒体供稿和第三方投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
本网站刊载的所有内容(包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等)版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时,请及时通知本站,予以删除。