It服务管理技术的制作方法

专利名称：It服务管理技术的制作方法
技术领域：
本发明涉及服务管理技术，尤其指一种IT服务管理技术。
背景技术：
IT技术日新月异，企业IT系统越来越来越复杂。服务器从Z系列主机到Unix月艮务器以及PC才几分布于7>司的各个部门，通过数以万计的网络设备连接在一起。同时在这些异构系统构成的硬件平台之上是庞大的企业应用系统，从SCM(供应链管理)、ERP (企业资源规划)到CRM(客户关系管理)，无一不是支持公司业务增长的强劲动力和基础设施。如何保障IT系统的正常运行，从而保障公司的核心业务，已经日益成为一个CIO (首席信息执行官)乃至CEO (首席执行官)需要仔细思考的问题。
让我们筒单回顾一下IT系统发展中的三个重要技术局域网络、客户机/服务器和因特网。局域网使公司部门和项目小组成员共享信息成为可能，而且公司的高层管理人员可以借助特定工具评估每一个公司部门的业绩，有助于迅速掌握公司的运营情况并迅速做出响应。随之出现了客户机/服务器模式，每一个部门乃至每一个项目组都可以使用自己的服务器管理本部门的业务，在公司的内部形成了大量垂直分布的信息系统，系统之间需要网络连接起来，IT系统的复杂性进一步增加。而因特网技术的出现，以及电子商务的成熟，使得企业可以提供在线交易， 这在拓宽了公司经营渠道的同时，使事情变得更为复杂。设想一下，你
可能在中国的北京通过一台PC机提交一笔交易，而该交易会通过网络
传送到位于美国纽约的网络服务器，网络服务器会进一步与位于德国柏 林的应用服务器和数据库服务器通信以便完成这笔交易。每增加一个环 节就会增加一份出问题的可能性，同时客户对于我们的业务系统却提出
了更为苛刻的可用性条件，公司业务的全球化使得我们必须提供24x7 的可用性。中间任何一个环节出现问题，都可能直接影响到公司的业务 顺利进行，造成重大损失。如何管理并改善^^司的IT系统，当今企业面 临重重挑战。
2003年Morgan-StanleyCIO的调查指出，CIOs希望他们2003年下 半年的IT预算保持平稳。4他们全年的期望是增长微不足道的1% 。 CIOs曾被明确要求降低成本，并且将工作重点转移到业务更少、更重要 的IT领域； 一言以蔽之，就是要做到事半功倍。我们发现自己所处的经 济环境要求所有企业全面降低自身的成本，其中也包括他们的IT基础架 构成本。所有人都在寻找能够事半功倍的途径。IT主管总是在问下面这 些问题如何让当前的IT基础架构发挥更大的功效？如何借助目前的 IT员工管理当前越来越复杂的环境？如何更好地利用已就位的IT基 础架构使企业在无需额外投资的前提下提供具有竟争力的产品？降低 IT成本时企业面临的又一大挑战。
业务的发展速率在日益加快，业务的灵敏性也备受关注。近期对 IBM客户所作的一次调查表明，60%的客户认为，迅速对商机、竟争和 法规做出反应是他们关注的焦点。但即便今天的企业已经开始进行运作改革，也是步履维艰，并经常采用手工方式。有时，回应较小变更的时 间长达数天或数周。如果企业反应迟緩，则可能在竟争中失去重要的客 户，同时由于失去商机而丧失市场份额，而事实上，只要他们足够灵活， 就完全可以把握这些商机。企业呼唤更出色的系统管理工具，这些工具 可帮助他们随需应变，并且将企业自身的业务规则融合到系统中。
在复杂的异构环境中管理服务等级、在保持可用性和可靠性的同时
提高资源利用率、降低IT成本、提高运作变化的灵活性和速度，这四 大业务挑战合并在一起带来了第五项挑战即管理不断增长的风险。这 些业务挑战的十万火急自然而然地引来了业务风险。重要的东西就会带 来巨大的风险。这是您不容回避的事实。应对这些重大业务挑战也令风 险不断升级。例如，要在复杂的异构环境中获得服务等级协议，同时还 要求降低IT成本，这势必困难重重而且加大了风险。在提高运作变化的 灵活性和速度的同时提高资源利用率更加危险。但也许全部挑战的最大 风险并非应对这些挑战，而是风险竟争所带来的损害。
如何应对这些挑战， 一个显而易见的答案就是采用系统管理帮助您 实现一个随需应变的IT系统，使IT系统能够更好地支撑公司的业务增长 和创新。
IT系统管理已经有二十多年的历史，IT系统管理不仅仅是一 系列管 理软件，而是由组织、流程、数据和工具四个有机组成部分组成的完整 系统。组织是指你需要有一定的人员，组织结构来进行系统管理，包括 用户服务人员、网络操作人员以及系统管理人员等。流程是指对于特定 事件有一定的处理流程，如事件管理、更改管理以及问题管理等。工具 主要是一些协助实现IT系统管理的软件，利用这些软件能够实现一些管理工作的自动化，减少人力。数据指IT系统管理的规章制度以及系统运 行的一些数据和统计信息等。IT系统管理通过将被业界证实的最好实践 引入企业组织，可以为企业带来大量的好处。
1T系统管理通过定义清晰的IT系统管理目标，支持企业的远景和战 略。IT管理者集中精力于业务关键系统，能够更好支持公司的长远发展。 目前企业的IT系统大多是垂直的子系统，与公司业务流程相孤立，难以 准确定义每一个IT系统对于企业业务运行的影响和重要性。采用IT系 统管理后，可以将整个IT系统与公司的业务流程一致起来。CEO和CIO 可以更多地从业务的角度来看待IT系统，更加容易确定公司IT系统的 投资方向，确定业务关键系统，从而使IT系统更好地为企业的创新发展 提供动力。

发明内容
本发明在于提供一种解决上述问题的IT服务管理技术。 ,本发明采用如下技术方案 一种IT服务管理技术，其特征在于， 包括如下步骤
服务台(Service Desk) 突发事件管理(Incident Management ) 问题管理(Problem Management) 酉己置管理(Configuration Management) 变更管理(Change- Management)发布管理(Release Management) 所述的服务台(Service Desk)是IT服务组织和用户相互联系的接入 点。服务台曾经被称为帮助台(HelpDesk)。 Help Desk的主要任务是记 录，分解和监控提出的问题。 一个服务台可以具备更宽范的角色，如接收 变更请求(RFC),并且可以支撑多种流程中的操作。服务台是服务提供者 和用户之间的日常工作的单一联系点。它也是报告突发事伴和提交服务 请求的焦点。正因为如此，服务台的职责是保持将服务相关信息，行为和 契机通知用户，并追踪了解用户每日的行为。例如，服务台可能扮演用户 提交变更请求的联系点，基于变更管理流程传达变更实施计划，并保持将 变更实施进程通知用户。变更管理应该确保服务台随时保持对变更行为 情况的掌握。
在任何对SLA产生影响的事件面前，服务台处于第一线，并维护 高速的信息流通道.围绕突发事件，服务台有可能在其权限范围被授权 实施变更。此类变更的范围可能被预先定义。当所有相关变更发生时， 变更管理流程将被告知。基本上，当对任何CI的规范做出修改之前，变 更流程都需要对其进行预先审批。
所述突发事件管理流程致力于解决突发事件，并快速恢复服务供应 突发事件被记录下来,并且事件记录的质量决定了相关的其它流程的效 力。
服务台接近于突发事件管理流程和问题管理流程，并处于它们之间. 如果没有适当的控制，变更有可能引入新的突发事件。罔此需要建立有 效途径对变更进行跟踪。这是为什么建议持续不断地将突发事件记录在 同一个CMDB中，并分类为"问题"，"已知错误，，，"变更记录，，等信息，以促进服务台界面的信息沟通能力，筒化事件调查和报告。突发事 件的优先权及其升级需要作为服务级别管理流程中的一部分进行协商，
并在SLA中备案。
突发事件管理的目标
突发事件管理的目标是尽可能迅速地根据SLA中定义的普通服务 级别作出反应，使产生问题后对业务行为及组织和用户的影响最小。突 发事件管理也应该保留对事件的有效记录，以便于衡量和改进流程，并 向其它流程汇报。
所述的对于突发事件有两种处理方法， 一种是对其做出服务快速响 应，尽快恢复其正常运行,另一种是鉴别和解决问题根源。这两种方法之 间存在微妙的区别，而且经常被互相混淆.对其做好区分具有重要意义。
如果问题被怀疑存在于IT架构内部，问题管理流程将会瞄准其潜 在的根源。 一个问题可能是被突发事件暴露出来的，但是显然，问题管理 的目标是解决问题根源，预防其可能产生的干扰，而不是迅速恢复系统 运行。
当问题被识别后(被识别的问题通常称之为已知错误)，通常需要进 行一个业务决策，决定是否采取永久性措施改进系统架构，以预防再次发
生新的突发事件。如果需要，提交一个变更请求来实现改进。
为了有效和高效地识别突发事件背后的问题根源及其发展趋势，问 题管理流程需要准确全面的突发事件的记录。问题管理流程同样需要和 可用性管理流程密切联络，以确定这些趋势并明确补救措施的重要性。
所述的配置管理致力于控制一个变化中的IT架构(标准化和状态监控)，鉴别配置项目(清册,相互关联，审核与注册)，收集和管理有关IT架 构的文档，为所有其它流程提供IT架构的相关信息。
配置管理是所有其它服务管理流程不可分割的一部分。拥有当前架 构中所有部件的最新的，准确的，全面的和详细的信息，并管理其变更， 使这些信息有效而高效地支持其它流程运行。变更管理可以与配置管理 集成。至少，建议在配置管理系统中控制变更的登录和实施，并自在配置 管理系统的帮助下对变更影响做出评估。因此所有变更请求应该被输入 配置管理数据库(CMDB)，并随着变更请求的进展随时更新记录，直至其 实施.配置管理系统识别一个变更项目和架构中其它部件的关系，将这些 部件的所有人召集到影响评估流程中来。不管一个变更是否在架构中实 施，相互关联的配置管理记录应该在CMDB中得到更新。最好在变更发 生时，使用集成工具自动地更新记录。
CMDB应该开放给整个服务支持组，使所有人理解部件失效可能 的原因，从而使突发事件和问题可以被更容易地解决。CMDB还应当被 用来把突发事件及问题记录和其它记录联系起来，比如失效的配置项 目(Configuration Item - CI)和用户之间的联系。如果缺少了配置管理流 程的集成，发布管理将难以实现，并可能错误连连。
所述的变更管理专注于对IT架构实施可控的变更。此流程的目标是 确定所需的变更，并决定这些变更如何在对IT服务产生最小的不利影 响的范围内得以实施。同时确保其变更是可追溯的，而且是经过整个组 织内部有效地磋商和协调的。在客户组织提交变更请求后,由配置管理流 程监控其状态，与问题管理和若干其它流程进行协调。变更实施履行一 特定的路径，包括定义，计划，建立，测试，接受，实施，和评估。变更管理流程依赖于配置数据的准确性，以确保获知所有实行变更 造成的影响。因此变更管理与配置管理之间有密切的联系。
变更流程的详细内容应在SLA中存档，确保用户知道提交变更申请 的程序，项目目标及时间，以及实施变更造成的影响。
变更的详细内容需要通知服务台。即使变更经过了全面测试，仍然 很有可能存在实施变更的过程中发生各种困难，这些困难可能缘于变更 没有按需求或预期运行，或者对变更对功能造成的影响产生质疑。
变更咨询会议(Change Advisory Board - CAB)由可向变更管理小组
提供专家意见的人员组成。这个会议很可能由来自于所有领域的IT及 业务单位的人参与。
所述的发布是指一组配置项目(Configuration Items CI)经过测试被引 入处于活动状态的环境中。发布管理的主要目标是确保发布信息被成功 地公布，包括归纳综合，测试与存档。
发布管理确保只有经过测试和正确授权的软硬件版本才能提供给IT 运行环境。发布管理与配置管理和变更管理的行为密切相关。真实的变 更实施经常通过发布管理行为得以贯彻。
变更的结果可能经常来自于新硬件，新版本软件，以及新的文档 (自行建立，或购买而来)等.对它们进行控制，并打包和颁发。有关存档 安全和公布程序应该和变更管理和配置管理流程紧密集成。发布的程序 也可能作为突发事件管理和问题管理流程中不可分割的一部分，同时 还和CMDB密切相连，以维护及时更新的记录。
本发明明确了IT服务是面向客户需求的，并且我们已经把客户需求量化为IT服务所遵从的质量标准体系。那么接下来，我们就要运用IT服 务的管理方法达到既定的质量目标，或者说是履行IT服务組织和客户之 间达成的服务协议。
IT服务管理被认为是基于流程的和面向服务的管理。流程总是具有 一个既定的目；^示。
IT服务管理流程的目标是为IT J良务质量而服务。质量管理和流程 控制形成组织及其政策的一部分。
了解IT服务管理的价值对于IT服务组织最终具备一个清晰的服务 管理功能定义是十分重要的。IT服务管理对于IT服务组织的主要贡献 如下
翻提高服务质量 支持更可靠的业务；
■使实现IT服务一致性的程序更具有针对性，当需要它们时提供可靠 的能力；
■提供描述现有IT能力的更清晰的視鵬为现有服务提供更有价值的信息；
■通过对IT支持理解的提高，为业务提供更大的灵活性；
■更主动的员工-由于能够更好地理解其能力和管理期望，有助于IT
服务组织的员工提高其对于工作的满意度； ■由于IT服务提供者了解客户所期望的服务，并最终实现交付，可以提
高客户对于服务的满意度； ■提高所提供服务的灵活性和适应性；
■提供系统导向的益处，如在安全，精确性，速度，可用性等所需服务级别规定的各项目标上得以提高； ■缩短变更周期，提高成功率。
这些益处的重要性因组织而异。其可衡量性也有所不同。借助ITIL 理论有助于对其量化，从而提高可操作性。
其中服务交付(ServiceDelivery)和服务支持(Service Support)是IT服 务运4亍的核心内容。
投资回报率可以通过NPV ( Net Present Value )和Payback Period来 计算。NPV将未来五年的投资回报转化为今天的收益值。投资回报必须 转化为今天的收益值，因为将来的开销和收益跟现在賺取的收益并不等 值。企业可以根据一个折扣表，将未来的收益转化为现在的收益。这个 折扣表可以根据通货膨胀率或者公司内部的计算机制编制。在分析IT系 统管理项目的投资回报率时，我们会考虑到购买软件的初始一次性费用， 包括软件的授权费、安装和整合的费用。另外还要考虑到培训、支持和 维护的费用(大约每年15%)的费用。回报包括每年的节省开支、管理 效率以及应用的可用性。在计算每年的开支和收益时，必须将其转换为 现在的花费。如图所示，为NPV的示例。
另外一种筒单计算投资汇报率的方法采用投资收回期(Payback Period),这种计算方法筒单地将我们计算的未来投资回报会在多少时间 内达到我们实现系统管理方案的费用。如图所示，为投资收回期示意图。


图1是本发明IT组织构架示意图。本发明的目的、功能及优点将结合实施例，参照附图做进一步说明。
具体实施例方式
如图l所示，本发明一种IT服务管理技术，其特征在于，包括 如下步骤
月l务台(Service Desk)
突发事件管理(Incident Management )
问题管理(Problem Management)
配置管理(Configuration Management)
变更管理(Change Management)
发布管理(Release Management) 所述的服务台(Service Desk)是IT服务组织和用户相互联系的接入 点。服务台曾经被称为帮助台(HelpDesk)。 Help Desk的主要任务是记 录，分解和监控提出的问题。 一个服务台可以具备更宽范的角色，如接收 变更请求(RFC)，并且可以支撑多种流程中的操作。服务台是服务提供者 和用户之间的日常工作的单一联系点。它也是报告突发事件和提交服务 请求的焦点。正因为如此，服务台的职责是保持将服务相关信息，行为和 契机通知用户，并追踪了解用户每日的行为。例如，服务台可能扮演用户 提交变更请求的联系点,基于变更管理流程传达变更实施计划，并保持将 变更实施进程通知用户。变更管理应该确保服务台随时保持对变更行为 情况的掌握。
在任何对SLA产生影响的事件面前，服务台处于第一线，并维护 高速的信息流通道。围绕突发事件，服务台有可能在其权限范围被授权实施变更。此类变更的范围可能被预先定义。当所有相关变更发生时，变更管理流程将被告知。基本上，当对任何CI的规范做出修改之前，变更流程都需要对其进行预先审批。所述突发事件管理流程致力于解决突发事件，并快速恢复服务供应.突发事件被记录下来，并且事件记录的质量决定了相关的其它流程的效力。服务台接近于突发事件管理流程和问题管理流程，并处于它们之间. 如果没有适当的控制，变更有可能引入新的突发事件。因此需要建立有 效途径对变更进行跟踪。这是为什么建议持续不断地将突发事件记录在同一个CMDB中，并分类为"问题"，"已知错误"，"变更记录，，等 信息，以促进服务台界面的信息沟通能力，简化事件调查和报告。突发事 件的优先权及其升级需要作为服务级别管理流程中的一部分进行协商， 并在SLA中备案。突发事件管理的目标突发事件管理的目标是尽可能迅速地根据SLA中定义的普通服务 级别作出反应，使产生问题后对业务行为及组织和用户的影响最小。突 发事件管理也应该保留对事件的有效记录，以便于衡量和改进流程，并 向其它流程汇才艮。所述的对于突发事件有两种处理方法， 一种是对其做出服务快速响应，尽快恢复其正常运行,另一种是鉴别和解决问题根源。这两种方法之 间存在微妙的区别，而且经常被互相混淆.对其做好区分具有重要意义。 如果问题被怀疑存在于IT架构内部，问题管理流程将会瞄准其潜 在的根源。 一个问题可能是被突发事件暴露出来的，但是显然，问题管理 的目标是解决问题根源，预防其可能产生的干扰，而不是迅速恢复系统18运行。当问题被识别后(被识别的问题通常称之为已知错误)，通常需要进 行一个业务决策,决定是否采取永久性措施改进系统架构，以预防再次发 生新的突发事件。如果需要，提交一个变更请求来实现改进。为了有效和高效地识别突发事件背后的问题根源及其发展趋势，问 题管理流程需要准确全面的突发事件的记录。问题管理流程同样需要和 可用性管理流程密切联络，以确定这些趋势并明确补救措施的重要性。所述的配置管理致力于控制一个变化中的IT架构(标准化和状态监 控)，鉴别配置项目(清册,相互关联，审核与注册)，收集和管理有关IT架 构的文档，为所有其它流程提供IT架构的相关信息。配置管理是所有其它服务管理流程不可分割的一部分。拥有当前架 构中所有部件的最新的，准确的，全面的和详细的信息，并管理其变更， 使这些信息有效而高效地支持其它流程运行。变更管理可以与配置管理 集成。至少，建议在配置管理系统中控制变更的登录和实施，并自在配置 管理系统的帮助下对变更影响做出评估。因此所有变更请求应该被输入 配置管理数据库(CMDB),并随着变更请求的进展随时更新记录，直至其 实施。配置管理系统识别一个变更项目和架构中其它部件的关系，将这 些部件的所有人召集到影响评估流程中来。不管一个变更是否在架构中 实施，相互关联的配置管理记录应该在CMDB中得到更新。最好在变更 发生时，使用集成工具自动地更新记录。CMDB应该开放给整个服务支持组，使所有人理解部件失效可能 的原因，从而使突发事件和问题可以被更容易地解决。CMDB还应当被 用来把突发事件及问题记录和其它记录联系起来，比如失效的配置项目(Configuration Item - CI)和用户之间的联系。如果缺少了配置管理流 程的集成，发布管理将难以实现，并可能错误连连。所述的变更管理专注于对IT架构实施可控的变更。此流程的目标是 确定所需的变更，并决定这些变更如何在对IT服务产生最小的不利影 响的范围内得以实施。同时确保其变更是可追溯的，而且是经过整个组 织内部有效地磋商和协调的。在客户组织提交变更请求后，由配置管理流 程监控其状态，与问题管理和若干其它流程进行协调。变更实施履行一 特定的路径，包括定义，计划，建立，测试，接受，实施，和评估。变更管理流程依赖于配置数据的准确性，以确保获知所有实行变更 造成的影响。因此变更管理与配置管理之间有密切的联系。变更流程的详细内容应在SLA中存档，确保用户知道提交变更申请 的程序，项目目标及时间，以及实施变更造成的影响。变更的详细内容需要通知服务台。即使变更经过了全面测试，仍然 很有可能存在实施变更的过程中发生各种困难，这些困难可能缘于变更 没有按需求或预期运行，或者对变更对功能造成的影响产生质疑。变更咨询会议(Change Advisory Board - CAB)由可向变更管理小组提供专家意见的人员组成。这个会议很可能由来自于所有领域的IT.及 业务单位的人参与。所述的发布是指一组配置项目(Configuration Items CI)经过测试被引 入处于活动状态的环境中。发布管理的主要目标是确保发布信息被成功 地公布，包括归纳综合，测试与存档。发布管理确保只有经过测试和正确授权的软硬件版本才能提供给IT 运行环境。发布管理与配置管理和变更管理的行为密切相关。真实的变 更实施经常通过发布管理行为得以贯彻。20变更的结果可能经常来自于新硬件，新版本软件，以及新的文档 (自行建立，或购买而来)等。对它们进行控制，并打包和颁发。有关存 档安全和公布程序应该和变更管理和配置管理流程紧密集成。发布的程 序也可能作为突发事件管理和问题管理流程中不可分割的一部分，同时还和CMDB密切相连，以维护及时更新的记录。本发明明确了IT服务是面向客户需求的，并且我们已经把客户需求 量化为IT服务所遵从的质量标准体系。那么接下来，我们就要运用IT服 务的管理方法达到既定的质量目标，或者说是履行IT服务组织和客户之 间达成的l良务协议。IT服务管理被认为是基于流程的和面向服务的管理。流程总是具有 一个既定的目标。IT服务管理流程的目标是为IT服务质量而服务。'质量管理和流程 控制形成组织及其政策的 一部分。了解IT服务管理的价值对于IT服务组织最终具备一个清晰的服务 管理功能定义是十分重要的。IT服务管理对于IT服务组织的主要贡献 如下■提高服务质量 支持更可靠的业务；■使实现IT服务一致性的程序更具有针对性，当需要它们时提供可靠 的能力；躍提供描述现有IT能力的更清晰的视图； ■为现有服务提供更有价值的信息；■通过对IT支持理解的提高，为业务提供更大的灵活性；和管理期望，有助于IT服务组织的员工提高其对于工作的满意度； ■由于IT服务提供者了解客户所期望的服务，并最终实现交付，可以提高客户对于服务的满意度；■提高所提供服务的灵活性和适应性；■提供系统导向的益处，如在安全，精确性，速度，可用性等所需服务级别规定的各项目标上得以提高； ■缩短变更周期，提高成功率。这些益处的重要性因组织而异。其可衡量性也有所不同。借助ITIL 理论有助于对其量化，从而提高可操作性。其中服务交付(ServiceDelivery)和服务支持(Service Support)是IT月艮 务运4亍的核心内容。投资回I艮率可以通过NPV ( Net Present Value )和Payback Period来 计算。NPV将未来五年的投资回报转化为今天的收益值。投资回报必须 转化为今天的收益值，因为将来的开销和收益跟现在賺取的收益并不等 值。企业可以根据一个折扣表，将未来的收益转化为现在的收益。这个 折扣表可以根据通货膨胀率或者公司内部的计算机制编制。在分析IT系 统管理项目的投资回报率时，我们会考虑到购买软件的初始一次性费用， 包括软件的授权费、安装和整合的费用。另外还要考虑到培训、支持和 维护的费用(大约每年15°/。)的费用。回报包括每年的节省开支、管理 效率以及应用的可用性。在计算每年的开支和收益时，必须将其转换为 li在的花费。如图所示，为NPV的示例。另外 一种筒单计算投资汇报率的方法采用投资收回期(Payback Period),这种计算方法筒单地将我们计算的未来投资回报会在多少时间 内达到我们实现系统管理方案的费用。如图所示，为投资收回期示意图。 在评估IT系统管理项目的投资回^^率时，我们应该着重研究如下几个方 面*管理自动化增强通过自动化IT管理流程，提高IT的生产效率，提高管理有效性。(Tools) *可用性增强减少系统以外停机时间，降低因系统异常停机导致内部员工和外部客户不能访问业务系统带来的业务损失。
业务系统管理带来的好处将IT系统和核心业务系统直接联系在一起，不是管理IT系统的资源，如服务器、网络设备等物理资源，而是直接根据业务系统管理IT系统，如ERP系统。 *精筒高效的维护人员队伍。*流程化，削减企业管理费用开支，提高管理有效性。 很多组织采用了ITIL和CobiT,并获得了可观的成果。 复杂的IT系统给企业带来了巨大挑战，只有实施IT系统管理，才 能在随需应变时代中从容面对重重挑战，创建和运作一个成功的企业 关注重点(Focused )、实时响应(Responsive )、随才几应变(Variable )、 弹性运营(Resilient )。以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范 围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利 保护范围内。
权利要求
1、一种IT服务管理技术，其特征在于，包括如下步骤服务台(Service Desk)突发事件管理(Incident Management)问题管理(Problem Management)配置管理(Configuration Management)变更管理(Change Management)发布管理(Release Management)。
2、 如权利要求1中所述的IT服务管理技术，其特征在于所述的服务 台(ServiceDesk)是IT服务组织和用户相互联系的接入点.服务台曾经被称为 帮助台(Help Desk). Help Desk的主要任务是记录，分解和监控提出的问题. 一个服务台可以具备更宽范的角色，如接收变更请求(RFC),并且可以支撑多 种流程中的操作.服务台是服务提供者和用户之间的日常工作的单一联系点. 它也是报告突发事件和提交服务请求的焦点.正因为如此，服务台的职责是 保持将服务相关信息，行为和契机通知用户，并追踪了解用户每日的行为.例 如，服务台可能扮演用户提交变更请求的联系点,基于变更管理流程传达变更 实施计划，并保持将变更实施进程通知用户.变更管理应该确保服务台随时 保持对变更行为情况的掌握.在任何对SLA产生影响的事件面前，服务台处于第一线，并维护高速的 信息流通道.围绕突发事件，服务台有可能在其权限范围被授权实施变更.此 类变更的范围可能被预先定义.当所有相关变更发生时，变更管理流程将被 告知.基本上，当对任何CI的规范做出修改之前，变更流程都需要对其进行 预先审批。
3、 如权利要求1中所述的IT服务管理技术，其特征在于所述突发事件 管理流程致力于解决突发事件，并快速恢复服务供应.突发事件被记录下来， 并且事件记录的质量决定了相关的其它流程的效力.服务台接近于突发事件管理流程和问题管理流程，并处于它们之间.如 果没有适当的控制，变更有可能引入新的突发事件.因此需要建立有效途径 对变更进行跟踪.这是为什么建议持续不断地将突发事件记录在同 一个 CMDB中，并分类为"问题"，"已知错误"，"变更记录"等信息，以促进 服务台界面的信息沟通能力，简化事件调查和报告.突发事件的优先权及其升 级需要作为服务级别管理流程中的一部分进行协商，并在SLA中备案.突发事件管理的目标突发事件管理的目标是尽可能迅速地根据SLA中定义的普通服务级别作 出反应，使产生问题后对业务行为及组织和用户的影响最小.突发事件管理 也应该保留对事件的有效记录，以便于衡量和改进流程，并向其它流程汇报。
4、 如权利要求1中所述的IT服务管理技术，其特征在于所述的对于突 发事件有两种处理方法， 一种是对其做出服务快速响应，尽快恢复其正常运 行，另一种是鉴别和解决问题根源.这两种方法之间存在揭t妙的区另ij，而且经 常被互相混淆对其做好区分具有重要意义.如果问题被怀疑存在于IT架构内部，问题管理流程将会瞄准其潜在的根 源. 一个问题可能是被突发事件暴露出来的，但是显然，问题管理的目标是解 决问题根源，预防其可能产生的千扰，而不是迅速恢复系统运行.当问题被识别后(被识别的问题通常称之为已知错误)，通常需要进行一 个业务决策,决定是否采取永久性措施改进系统架构，以预防再次发生新的突 发事件.如果需要，提交一个变更请求来实现改进.为了有效和高效地识别突发事件背后的问题根源及其发展趋势，问题管 理流程需要准确全面的突发事件的记录.问题管理流程同样需要和可用性管 理流程密切联络，以确定这些趋势并明确补救措施的重要性。
5、 如权利要求1中所述的IT服务管理技术，其特征在于所述的配置管 理致力于控制一个变化中的IT架构(标准化和状态监控)，鉴别配置项目(清册: 相互关联，审核与注册)，收集和管理有关IT架构的文档，为所有其它流程提 供IT架构的相关信息.配置管理是所有其它服务管理流程不可分割的一部分.拥有当前架构中 所有部件的最新的，准确的，全面的和详细的信息，并管理其变更，^使这些信 息有效而高效地支持其它流程运行.变更管理可以与配置管理集成.至少，建 议在配置管理系统中控制变更的登录和实施，并自在配置管理系统的帮助下 对变更影响做出评估.因此所有变更请求应该被输入配置管理数据库(CMDB)， 并随着变更请求的进展随时更新记录，直至其实施.配置管理系统识别一个变 更项目和架构中其它部件的关系，将这些部件的所有人召集到影响评估流程 中来.不管一个变更是否在架构中实施，相互关联的配置管理记录应该在CMDB中得到更新.最好在变更发生时，使用集成工具自动地更新记录.CMDB应该开^:给整个服务支持组，使所有人理解部件失效可能的原因， 从而使突发事件和问题可以被更容易地解决.CMDB还应当被用来把突发事 件及问题记录和其它记录联系起来，比如失效的配置项目(Configuration Item画 CI)和用户之间的联系.如果缺少了配置管理流程的集成，发布管理将难以实 现，并可能错误连连。
6、 如权利要求1中所述的IT服务管理技术，其特征在于所述的变更管 理专注于对IT架构实施可控的变更.此流程的目标是确定所需的变更，并决定这些变更如何在对IT服务产生最小的不利影响的范围内得以实施.同时确 保其变更是可追溯的，而且是经过整个组织内部有效地磋商和协调的.在客 户组织提交变更请求后，由配置管理流程监控其状态，与问题管理和若千其它 流程进行协调.变更实施履行一特定的路径，包括定义，计划，建立，测试， 接受，实施，和评估.变更管理流程依赖于配置数据的准确性，以确保获知所有实行变更造成 的影响.因此变更管理与配置管理之间有密切的联系.变更流程的详细内容应在SLA中存档，确保用户知道提交变更申请的程 序，项目目标及时间，以及实施变更造成的影响.变更的详细内容需要通知服务台.即使变更经过了全面测试，仍然很有 可能存在实施变更的过程中发生各种困难，这些困难可能缘于变更没有按需 求或预期运行，或者对变更对功能造成的影响产生质疑.变更咨询会议(Change Advisory Board - CAB)由可向变更管理小组提供专 家意见的人员组成.这个会议很可能由来自于所有领域的IT及业务单位的人 参与.如权利要求1中所述的IT服务管理技术，其特征在于所述的发布是指一 组配置项目(Configuration Items CI)经过测试被引入处于活动状态的环境 中.发布管理的主要目标是确保发布信息被成功地公布，包括归纳综合，测试 与存档.发布管理确保只有经过测试和正确授权的软硬件版本才能提供给IT运 行环境.发布管理与配置管理和变更管理的行为密切相关.真实的变更实施 经常通过发布管理行为得以贯彻.变更的结果可能经常来自于新硬件，新版本软件，以及新的文档(自行建立，或购买而来)等.对它们进行控制，并打包和颁发.有关存档安全和公布程 序应该和变更管理和配置管理流程紧密集成.发布的程序也可能作为突发事件管理和问题管理流程中不可分割的一部分，同时还和CMDB密切相连，以 维护及时更新的记录。
全文摘要
本发明涉及服务管理技术，尤其指一种IT服务管理技术，包括如下步骤服务台；突发事件管理；问题管理；配置管理(Configuration Management)变更管理；发布管理。服务台是IT服务组织和用户相互联系的接入点，服务台曾经被称为帮助台的主要任务是记录，分解和监控提出的问题。一个服务台可以具备更宽范的角色，如接收变更请求(RFC)，并且可以支撑多种流程中的操作，服务台是服务提供者和用户之间的日常工作的单一联系点，它也是报告突发事件和提交服务请求的焦点。
文档编号G06Q10/00GK101673366SQ20081022214
公开日2010年3月17日 申请日期2008年9月10日 优先权日2008年9月10日
发明者明 卢 申请人:北京正辰科技发展有限责任公司