IT服务管理整合模型三篇

IT服务管理整合模型 篇1

现代电信企业在完成企业IT架构转型之后,企业业务的正常运行对IT系统地依赖程度不断增强,使IT系统的规模和复杂度不断增加。但对于任何一个IT系统而言,都存在一个“生命周期”的概念,即不仅要完成系统的基础建设,更要确保在IT系统的完整生命周期过程中提供全面的配套管理维护支持,以确保企业IT建设投资能持续、稳定地发挥出效益,并进而使IT系统资源成为企业核心竞争力的一个新内容。因此保证IT架构的安全可靠、正常运行已经成为目前以信息技术运用为基础的现代业务运作模式下企业信息化建设的一个重要方面,也是确保IT服务管理体系能成为保障整个企业IT不间断运行的基础,而不是业务系统运行的瓶颈因素。

通过应用目前业界广泛采用的ITIL(IT基础架构库)管理规范,是有效应对上述IT建设与运维管理挑战的一个重要途径。这是继电信企业业务转型、IT架构转型之后,在IT服务管理方面的又一个重要的转型举措,他将对电信企业内部的IT管理带来以下影响:

(1) 打通IT部门和业务部门之间的结构性障碍,在二者之间建立一个有效的沟通和协调机制,变被动IT管理为主动IT管理,缩短业务响应时间。

(2) 便于全面、系统地实施IT基础架构管理,根据企业的业务需求和成本预算来综合确定IT基础架构的配置,并通过统一的协作流程对IT基础架构进行全面的运行维护管理,以确保能支持更高质量的IT服务运作。

(3) 在目前运营商竞争压力日益增大的背景下,通过IT服务管理所提供的方法和指标体系来进行IT服务的成本和效益的计量,实现对IT投资的科学决策,优化IT资源配置。

(4) 在运营商的IT服务外包过程中,通过IT服务管理来实现对外包IT服务的标准化和模块化,以确保IT外包不会对整体的IT服务质量造成影响或损害。

2 实施策略

2.1 上海电信原有IT运维模式的主要问题

根据电信集团的整体规划,上海电信自2003年开始进行IT转型规划及实施。在转型前期,企业IT运维管理方面主要面临以下问题:

(1) 随着IT应用的转型和集中,原有的以应用为导向的IT运维模式亦面临转型的压力,需要同时解决部门和人员结构调整、维护流程的梳理和整合的多重问题,还包括全员IT服务意识的转变。

(2) 原有的系统维护主要采用被动的IT运维模式,难以有效适应转型后的IT系统架构,也难以有效地控制IT成本、保障IT支撑能力。

(3) 考虑到整个上海电信IT转型实施任务重、周期紧,IT部门人员配置相对不足,因而需要在受限的资源约束条件下来分析ITSM(IT服务管理)实施的问题。

(4) 鉴于主流厂商ITSM解决方案和流程实施的成本均相对较高,需要在IT运维转型过程中全面考虑实施成本和效益的均衡问题。

2.2 上海电信IT服务管理实施的策略

根据IT运维模式存在的上述问题,对上海电信IT服务管理体系的推进策略主要做了如下考虑:

实施流程的选择 优先考虑实施IT服务管理技术操作层面的流程(即事件管理、配置管理、问题管理和变更管理等基础流程)以及帮助台,以期用相对合理的成本尽快建立IT服务的基础框架,全面配合与保障企业IT转型的顺利实施。而对其他管理流程(如IT服务的服务级别保证、IT服务管理的战略层面规划和财务管理等)则考虑在条件具备的情况下陆续完善和实施,并形成核心的IT管理体系。

实施阶段的划分 对4个基础管理流程,考虑从事件管理和配置管理流程入手,率先完成IT实施与维护的日常操作规范化,然后实施问题管理和变更管理流程。而作为IT流程实施基础的帮助台则考虑一开始就实施。采用这种分阶段的实施方案,有助于配合IT部门的调整与转型工作,实现IT管理体系的软着陆,也有助于实施成本在时间轴线上的合理分摊。

配套的管理举措 在进行IT服务管理流程实施的同时,需要强调相关管理举措的同步推进,包括IT部门的架构和人员调整、IT人员的ITIL基础培训、配套基础数据的采集与整理、相关系统接口的规划与实施等,以确保建成的IT服务管理体系得以有效的运行。

3 实施过程

上海电信IT服务管理体系的实施过程主要包括以下几个方面:

3.1 IT服务管理流程设计

在ITIL标准服务流程的基础上,重点结合上海电信IT运维管理的特点,对几个核心ITIL管理流程进行了定制和设计:

事件管理流程 负责解决IT服务的突发事件、问题和客户请求的运维流程。他以解决表征现象为目的,而非根本原因的查找。该流程将面向MBOSS各类业务系统及IT基础设施运行过程中产生的故障和服务请求及服务咨询,并涵盖了网络、终端、应用和业务的相关层面。

配置管理流程 负责描述、跟踪、控制和汇报所有IT基础架构中所有设备或系统的管理流程,以实现对所有配置元素(CI)的有效管理,跟踪并控制上海电信IT服务和基础设施的运行状况。该流程将面向IT生产环境的所有配置元素,包括服务器、存储设备、机房环境、应用软件、网络设备、板卡、客户端、文档资料等。

变更管理流程 负责控制和管理整个IT环境中的变更处理,并与配置管理流程建立接口。该流程提供了对变更的审批、实施管理和控制的机制,并需要由管理工具提供支持。流程管理的范围将包括软件、硬件、网络设备和文档等。

问题管理流程 负责分析检测问题发生的根本原因,以解决并根除这些问题和事件,其中包含主动方面(分析事件并阻止事件的再次发生以提升服务质量)和被动方面(通过在线SLA目标来管理问题)。该流程针对所有IT生产环境中未根本解决的问题和已知错误,可根据事件或问题的优先级进行处理。

在对工作流程进行梳理的基础上,逐步明确了IT部门的组织和人员架构、岗位设置和各岗位在相关流程中的角色、职责,并提供了具体的操作流程定义。这些流程将成为IT部门日常运作管理的基础。

3.2 管理流程的电子化实施和CMDB初始导入

在完成上述的IT服务管理流程设计和细化分解的同时,还需要对这些关键流程的ITSM平台进行电子化实施及系统配置优化,以及对CMDB(配置管理数据库)数据的收集和初始化导入。

上海电信的IT服务管理是基于HP公司的Openview Service Desk产品来实现的,具体项目实施内容主要包括:进行Service Desk客户端的安装、系统配置和软件升级;创建Service Desk角色和用户帐号并分配给与流程相关的用户;修改和扩充CMDB结构;将上海电信收集整理的初始配置信息导入到CMDB;将原先资产管理系统中相关数据一次性导入到CMDB;将OA中人员、组织相关信息一次性整理并导入到CMDB;在Service Desk平台上对相关服务管理流程进行客户化实施的配置工作;服务管理报表功能的设计和配置;进行CMDB审计,确保现有CMDB中数据的准确性和完整性。

其中需要收集和导入的CMDB初始化数据将包括部门、人员、地址、PC终端、板卡、存储设备、打印设备、电源(动力设备)、服务器、局域网、软件、网络、文档等方面。

4 ITSM平台的系统接口整合

为确保所建成的ITSM平台能与相关系统有机整合,并能确保IT服务管理流程和公司内部的相关管理流程衔接,需要对ITSM平台进行全面的接口整合工作。

针对上海电信的IT实际情况,主要进行了两方面的整合工作:

4.1 ITSM与OA之间的整合

在原OA系统中已经提供了在用的企业IT故障申报流程,该项整合工作的目标是减少对企业内部员工操作习惯的影响,并有利于推广ITSM成果。

该项整合工作的具体内容主要包括:

(1) 完成OA故障申告流程到OV SD中申告流程的衔接,实现OA→OV SD的单向数据传递与流程贯通。这样申告处理在经过OA系统内部审批流程之后,即可转入OV SD平台进行处理。具体实现方式是:OA将申告信息转换并提交到中间接口服务器,由OV SD定期轮询接口服务器来批量进行申告信息的导入。

(2) 面向最终用户提供OA界面上的申告查询功能,便于最终用户了解申告处理进度情况。该功能需要解决用户名和OV SD session信息的同步,并直接调用OV SD的查询接口来完成。

(3) 面向最终用户的申告回复流程,以通知申告处理的最终结果。该功能主要通过在OV SD端流程处理完毕后向用户OA邮箱发送邮件方式回复用户来实现。

在上述整合过程中,需要完成OA和OV SD之间的用户数据同步。

4.2 ITSM与安管平台之间的整合

上海电信前期已经建立了基于Symantec SESA产品的综合安全管理平台,并初步建立了企业的IT安全管理流程,为进一步实现企业的IT服务流程与IT安全管理流程的有效衔接,对这两个平台的接口进行整合工作。

SESA与HP SD之间的整合系统架构如图1所示。在该系统中,在SESA/IM服务器上安装OVO Agent模块,并在HP OVO服务器端安装Symantec提供的Relay for OVO模块,从而将SESA/IM服务器所产生的信息通过OVO Agent和Relay模块的协作传递到HP OVO系统,并进一步由OVO根据本地的流程配置,前转到HP SD中的相应IT服务管理流程中加以处理。

对于反向信息流程,则主要考虑通过HP SD本身所提供的事件触发脚本的机制来调用一个本地独立应用程序,完成反馈信息到SESA/IM的反向传递。

SESA-HP SD系统整合工作将主要包含以下方面的内容:

(1) 对上述SESA-SD系统整合流程进行确认,并确认相关人员的基本工作流程和操作模式、界面元素和流程各环节所传递的信息内容。

(2) 对正向和反向流程的技术可行性安排进行现场测试。

(3) 完成OVO Agent、Relay for OVO模块的安装部署和配置。

(4) 完成SESA/IM中对相关安全策略和Relay模块的系统配置,完成对所传递信息的客户化定制工作。

(5) 完成OVO中对安全事故信息接收处理流程的相关配置。

(6) 完成SD的信息返回本地小应用程序编写和部署,并完成SD中事件自动调用脚本的编写和调试。

(7) 对正向和反向流程分别进行流程的贯通测试。

(8) 对整合后的系统整体安排进行压力测试,确认系统的稳定性和可靠性。

5 实施效果

通过以上IT管理流程的建立,改善了上海电信企业IT运维状况,大大提高了解决问题的速度和服务质量,使企业内部的相关支持信息更为畅通和透明,使支持服务的信息更为完整和有效,实现了基本的知识积累和知识管理,并可以帮助企业内部更好地进行量化管理和设定优化指标,最终能够为业务部门和客户提供更高质量的服务并提高他们的满意度。

具体的实施效果主要体现在以下方面:

(1) 使上海电信的IT服务热线有效地管理了服务呼叫和服务请求,全面提升了IT服务的质量水平,提高了最终用户的满意度,保障了各业务支撑系统的正常运行。

(2) 理顺了IT故障处理流程,明确了各部门和岗位的工作职责,并以SLA方式明确了IT部门和业务部门之间的服务级别,并据此对各级别的故障提供了及时的响应和处理。

(3) 使包括IT设备清单、IT设备配置等在内的大量IT基础数据都得到了有效的清理和利用,并建立了各种基础数据之间的关联性,使众多的IT资产得到了有效的管理。

(4) 使各种项目的变更(包括设备变更、应用功能变更、用户权限变更等)得到有效控制。由于上海电信系统众多,目前还未实现统一认证,用户权限的变更关系着信息系统的安全,通过变更管理流程使企业对用户的管理得到加强。同时通过接口整合,实现了IT服务管理与IT安全管理流程的全面衔接。

参考文献

[1]朱海林,方乐,梁晟,等.IT服务[M].北京:机械工业出版社,2006.

IT服务管理整合模型 篇2

关键词:IT服务管理,变更管理,模型,流程

Change Management 是IT 服务管理框架中的重要组成部分。

IT 服务管理中所谓变更change,即可能对IT 服务造成影响的对任何事物的增加、更改或移除。其涵盖范围包括所有的IT 服务、配置项、流程、文档等。这些change 可能是IT 内部发起的,也可能来自用户的要求;既可能是主动发起的改进,也可能是incident、problem 所导致的;既可能是服务改变、应用系统开发启动这样高层次变更,也可能是具体的操作,比如办公室搬家、服务器替换。

负责控制所有change 生命周期的流程就是变更管理流程Change Management Process。Change Management 的首要目的是使有益的Change 发生,同时最小化IT 服务的中断。它通过采用标准化的方法和过程快速高效地处理change。实际上,Change Management 的过程就是用可控的方式保证change 被记录、评估、授权、优先级划分、计划、测试、部署、归档和回顾检查的过程。在这个过程中,相关的信息被记录至配置管理系统,整体的业务风险获得优化。

在ITIL v3 中,v2 时原有的10个流程被进一步分化、加强,Service Strategy 阶段以及Transition Planning and Support 等流程的引入,使得对投资和风险的优化可以更加专业的发生在多个层次上,使Change Management 可以更加专注于处理操作层面change 或是对高层次change 进入实践的最后一步控制,从某种程度上为Change Management 减负,也使这套IT 服务管理架构获得了更好的适应性,以应对更大规模的或是业务管理灵活的组织。

1.变更管理中变更请求受理及评估过程的意义

按照change 的定义,所谓“可能对IT 服务造成影响的”“对任何事物的增加、更改或移除”,意味着IT 服务管理中涉及的change 无处不在,新员工账号的创建、离职员工账号的删除、新电脑的加入、会议室网口的增加、新应用系统的上线、老应用系统或是服务器的下线、服务器密码的统一修改、Windows 系统的定期补丁升级或其他应用系统更新、办公室搬迁、新型号打印机的引入、文件服务器上share folder 的调整、服务合同的续签、对某些网站访问的屏蔽、leased line 带宽升级等等,还包括那些难以分类界定的和IT 有关的需求。

实践中的change数量巨大,而Change Management 要求快速高效地处理change 同时还要控制风险, 在某些组织中还希望尽可能优化资源投入,难度可想而知,于是采用标准化的方法和过程成为必然。同时,change 又是多种多样的,为了达到标准化处理的目的,首先就需要采取分类处理的办法。

Normal change 处理的主要过程为,

1. 接受并核查RFC;

2. 评估Change,记录风险和影响;

3. 计划及授权;

4. 准备Change 执行;

5. 执行Change;

6. 检查并结束Change。

此外对于standard change 可以建立单独的处理流程,

7. Standard Change 流程

分类的过程发生在步骤1. 接受并核查RFC。在所需信息基本完整的情况下,尽早进行分类,可以使后续工作的标准化更加容易。例如可以在步骤1 处选择是否进入standard change 流程以及判断属于哪类standard change。信息收集和分类,是所有后续Change Management 活动的基础,应细腻适度。

步骤2. 评估Change,记录风险和影响,这步是change 授权决策及执行的最重要的基础,也是Change Management 实现其价值的重要步骤。Change Management 的价值不仅体现在change 的实施结果、多个change 间的安排和执行中的资源调度优化上,也体现在通过影响和风险的分析,提出良好的实施方案,以及对风险的避免或弱化,这部分的价值是无论change最终是否实施都存在的。

2.方法和模型

步骤1. 接受并核查RFC

鉴于change 的复杂性,Change Management 所接收的RFC (Request for Change) 可能有各种不同的来源,包括发起自IT 组织本身的,也包括源自客户或是最终用户的。由于Service Desk 是最终用户与IT 组之间的主要联络点(Primary Point of Contact),因此绝大部分直接来自最终用户的变更需求都会是经由Service Desk 及其所主要工作在的Incident Management 流程转至Change Management。此外,其他IT 服务管理流程,如Service Design 中的Service Level Management,Service Transition 中的Transition Planning and Support,Service Operation 中的Problem Management 等等,几乎所有流程,只要涉及变更,都需要触发Change Management,即生成RFC 发送至Change Management,并由Change Management 完成相应的授权及管理控制。

步骤1.1 接收和过滤RFC。RFC 的提交不同的组织中可以采取不同的方式,可以通过电子邮件附带特定格式的word 或是excel 文件、可以通过网页或是InfoPath 提交、也可以采用专用的IT 服务管理信息系统如Remedy 等。无论采用何种方式,一般来说,RFC 中都会包含以下内容,申请者信息、变更的描述、原因、相关记录(incident、problem 或其他change 等)、已知的影响和风险、建议的优先级、建议的实施时间、预期的时间和费用消耗等。

除了明确定义为属于service request 或其它流程处理范围的,或是明确定义为不属于change 或IT 服务范围的,其他所有包含变更的请求都有可能会被发送至Change Management。Change Management 小组成员需要根据相关政策、要求确认所接收到的请求是否为Change Management 处理范围,如果不是,则返还给请求的发送者,或是转发给正确的处理者。如果初步判定为在Change Management 处理范围内,则需确认所需信息是否完整齐备。

步骤1.2 核对相关合同。来自用户的对信息、设备、标准变更、或服务使用权等的请求,如要求重置密码、新用户申请邮件账号等,属于合同范围你的标准服务请求,通常归为service request,由Service Desk 在Request Fulfillment 流程中完成,此类请求不会进入Change Management,或是在1.1 接收和过滤RFC 阶段中即被退回。对于没有被当前服务合同所完全涵盖、同时有必要通过合同进行处理的变更请求,一般首先需要进行进行项目的开发、准备,而不是直接进入Change Management 审批。这种类型的变更请求往往意味着含有较大的商业机会、变更规模或影响较大、现有IT 运营层面的操作无法满足。此外其他的请求,通常Change Management 可以直接受理,其中既可以包括IT 服务合同已包含的服务项目,也可以包括合同中没有但也不必需要合同的服务项目。

步骤1.3 分类。根据已有信息进行分类,依据不同的类别,可以采取不同的处理方式的响应级别。例如对于有固定的操作模式、经常发生、成本和风险都在可控范围内的standard change 应用对应的standard change 流程;对于紧急的变更请求,则须加快响应速度并在后续操作中采取应急的处置方式。进入此步同时意味着正式接受该RFC,因此,如果有应用Change Management 的管理信息系统,应此步或此步之前完成change ticket 的录入。

步骤2 评估Change,记录风险和影响

步骤2.1 识别所需的变更。指识别在此change 中要求变更哪些配置项,需要考虑到其他正在执行或已经计划的change。

步骤2.2 识别受影响的服务和潜在收益。根据2.1 所识别出的配置项识别受影响的服务和潜在收益。

步骤2.3 识别所有受影响的配置项。根据2.2 中识别出的受影响的服务进一步挖掘会受影响的所有配置项,需要考虑到其他正在执行或已经计划的change。

步骤2.4 如果涉及多项变更,可创建多个change 记录。

步骤2.5 评估并记录影响和高风险。可以采用组织中已有的风险管理方法来完成此步,seven Rs 的方法可以帮助风险评估者完成此项工作。7个R 对应着7个问题,它们有助于进一步理解此变更的风险和价值。

Who RAISED the change? 谁提交的此项变更?

What is the REASON for the change? 变更的原因是什么?

What is the RETURN required from the change? 希望达成何种结果?

What are the RISKS involved in the change? 牵扯了哪些风险?

What RESOURCES are required to deliver the change? 需要哪些资源来完成此项变更?

Who is RESPONSIBLE for the build, test and implementation of the change? 谁负责构建、测试和实施此项变更?

What is the RELATIONSHIP between this change and other changes? 此项变更与其他变更间有什么关系?

步骤2.6 联系发起者补充信息。

步骤2.7 拒绝该RFC 并告知发起者。

3.总结

Change Management 流程的实现要求通过标准化的方式,其中的每一个步骤也应尽量做到标准化,并考虑到前一步是下一步的准备,同时避免无效的活动、以全局利益的实现为根本。在Change Management 的实施中,应严格禁止未授权变更的出现。同时,ITIL 的核心方法论是PDCA,流程和规则都不是死的,需要不断改进,Change Management流程步骤也需要根据业务发展不断调整。

参考文献:

1.Sharon Taylor, et al. ITIL Service Transition[M]. UK: TSO, 2007.

作者介绍:

IT服务管理能力模型研究论文 篇3

1ITSM能力成熟度模型设计的决策属性

在模型设计过程中，设计者面临许多决策属性的选择，或者说基于设计者关注或视角的成熟度模型设计属性的决策。在这里，我们从模型设计的4个方面，即定义范围、设计模型、评估设计与反映演变等方面来考察设计决策属性[3]。在定义范围方面，面临的重要决策属性有：①设定关注的焦点，是一般性项目还是特殊性项目，从而定义问题的宽度，它将影响到其他属性决策;②决策的层次。分为组内的、企业内部的、企业内外部及社会的等，这决定了问题的深度;③新颖性和成熟性;④用户关注，分为基于管理、基于技术、基于管理与基于技术相结合等。在设计模型方面，其主要决策属性有：①成熟度聚焦点，聚焦于流程意指集中关注活动和工作实践以及特殊任务的输入与输出，以决定有效的程序;聚焦于对象要求查明产品或服务的特点以加强作业模式;聚焦于人员要求更多关注软能力，即员工的思维和行为;②目标功能，分为单维的和多维的;③设计过程，分为理论驱动、基于实践、基于理论与实践;④设计的产品(即设计对象)，分为形式的文字描述、形式和功能的文字描述、例示的评估工具等。在评估设计方面，其主要决策属性有：①评估方式，分为自评估、第三方评估、指定专业人员评估;②评估应答者，分为管理者、员工、企业合作伙伴以及几者结合;③评估主题，分为设计过程、设计的产品、过程与产品。在反映演变方面，仔细考虑了模型的`设计可变性，这尤其重要。一方面，由于所考查的对象的成熟度逐渐提高，模型的改进活动应及时跟上，即随着技术进步和实践进展而修改为达到一定成熟度等级的要求;另一方面，需要变更形式和功能以保证模型的标准化和总体可接受性，也就是说，将模型框架修正为合适的结构。这样，模型的形式(中间模型或模型框架)和功能都可能是渐进变化的。最后，必须确定模型修改是开放式地由模型用户进行还是封闭式地由设计者来进行。

2基于ITILv3的ITSM能力成熟度模型

2.1现有IT管理能力成熟度模型的比较分析

我们对以下6种IT管理能力成熟度模型进行比较分析：Trillium模型，开发的主要适用于电信通讯业的软件开发生命周期能力成熟度模型;Bootstrap模型，开发的软件开发能力成熟度模型;PMF模型，20开发的软件过程框架能力成熟度模型;CMMI模型，即软件能力成熟度模型集成，于开发;ITSCMM模型，开发的IT服务能力成熟度模型;CMMI-SVC模型，即适用于服务领域的软件能力成熟度模型集成，于开发。从成功率、模型的表示方法、成熟度等级数目、适用范围、详细程度、作为其他模型基础等方面对上述成熟度模型进行了比较分析，如表1所示[4]。

2.2ITSM能力成熟度模型的设计策略

为了构建合理、完善的ITSM能力成熟度模型，本文比较了ITIL、CMMI-SVC和ITSCMM流程的相互关系如表2所示。综合了ITSCMM、CMMI-SVC和ITIL各自的优点与特点，将ITCMM和CMMI-SVC的所有流程与ITLIv3的流程进行整合与调整，建立基于ITILv3的ITSM能力成熟度模型，模型包括阶段式表示法和连续式表示法两种表现形式[4]。

2.3ITSM能力成熟度模型设计

本文所建立的ITSM能力成熟度模型，用5个有序级别的标度测量组织的IT服务能力成熟度，从低级到高级分别为初始级、可重复级、已定义级、已管理级和优化级。

2.3.1连续式模型设计

连续式模型在完成改进的次序上没有太多的明确规定，适用于已经知道流程优先级的企业。连续性模型没有与组织成熟度相关的离散的阶段，其过程域的实践通过支持单个过程域的成长和改进的方式组织。过程改进相关的大部分实践对不同的成熟度级别是共性的，它们属于单个过程域之外，并可应用于所有的过程域。这些共性实践存在于不同的领域当中，通过持续的实施共性实践，使过程域得到改进，成熟度等级得以提高。在评估整个组织时，过程域作为一个整体进行评定，创建了过程域的“阶段”，同一个过程域随着成熟度等级的提高，它的要求也逐渐提高。ITSM能力成熟度连续式模型以战略、人员与组织、流程、支持四个方面描述了其主要特征[5]，如表3所示。

2.3.2阶段式模型设计

阶段式模型给出了具体的流程实施顺序，有助于帮助不知道流程优先级的企业来进行流程改进。阶段式模型定义了不同的成熟度等级，每个成熟度等级都有一组关键过程域，指明了一个企业应该集中在何处改进其组织级过程，每个过程域用满足其目标的实践进行描述。这些实践描述了最有助于过程域的有效实施的基础和活动。阶段式模型通过确定已经达到多少关键过程域，把组织作为一个整体来进行评估。当满足某个特定成熟度等级和低于该成熟度等级的全部关键过程域的所有目标后，该组织就达到了该成熟度等级，完成了过程的改进。基于ITILV3的ITSM能力成熟度阶段式模型的5个成熟度等级的具体描述如下。初始级，IT服务管理过程没有经过任何定义，不存在关键过程域。以无秩序、点对点为特点，有时甚至是混乱的。成功取决于个人的努力和个人英雄主义。可重复级，建立了基本的IT服务管理过程，为组织提供有效的服务建立基础。依据政策保障流程计划的实施，以通过流程重复复制早先取得的类似的成功。已定义级，将IT服务管理过程文档化、标准化，并综合成标准IT服务管理过程指南。组织依据指南定义过程，建立了组织范围内的标准化流程，所有服务均使用经批准的组织标准服务过程交付。已管理级，根据客户、终端用户、组织和流程实施者的需求建立量化指标，收集服务交付过程和服务质量的详细度量值，评估服务质量和流程绩效，定量的进行流程管理。优化级，通过实施过程和引入创造性的思想和技术得到的量化数据反馈，进行持续的流程改造。ITSM能力成熟度阶段式模型的各成熟度等级的相应关键过程域如下：可重复级：服务目录管理，服务级别管理，供应商管理，服务资产与配置管理，事件管理，故障管理，服务请求，监测与控制，服务台，技术管理。已定义级：服务产生，需求管理，IT财务管理，服务组合管理，能力管理，可用性管理，IT服务连续性管理，转换计划与支持，变更管理，发布和部署管理，服务确认与测试，问题管理，访问管理，应用管理。已管理级：信息安全管理，评估，知识管理，服务支持，服务测量。优化级：服务改进。当评估企业成熟度是否达到可重复级时，就要看企业是否满足该级别的所有关键过程域的要求。当评估企业是否达到已定义级时，则要看企业是否同时满足可重复级与已定义级的关键过程域的要求，以此类推。

3结束语