干货推荐：



中国ITSS白皮书2.0【第二版】PDF

ITSS服务项目经理培训

ITSS服务项目经理培训——2-基本概念及方法

ITSS服务项目经理培训——3-IT服务设计

ITSS服务项目经理培训——4-IT服务转换

ITSS服务项目经理培训——5-IT服务运营(3)

ITSS服务项目经理培训——6-IT服务改进

ITSS服务项目经理培训——7-IT服务项目类别

ITSS服务项目经理培训——9-IT服务项目管理知识体系(1)

ITSS服务项目经理培训——10-IT服务项目群管理

4.2服务转换计划

4.2.1目的

服务转换计划的目的是确保服务转换的全过程在有序、可控的条件下顺利的进行。

对于服务转换而言，一个好的计划是不可或缺的，它也是转换计划阶段的重要输出物。

由于服务转换要在“一定的时间、可接受的成本和质量标准”内，以保证新服务或变更服务的顺利发布，并协调和组织构成服务的所有组件（这其中包括组织、人员、流程、知识以及其他资源）。那么，如何在时间一定、有限的资源投入的情况下，确保服务质量可控并达成既定的服务转换目标，就是服务转换计划作用的最直接、最重要的体现。

一个好的服务转换计划，可以让整个服务转换团队有明确的目标，在各自明确的职责范围内很好的协同工作，并且对交付物有明确的、统一的认知，从而确保服务转换能够被顺利执行，并顺利收尾；一个好的服务转换计划，同样也可以让客户对服务转换进度有清晰的了解，对服务转换阶段的交付物有明确的期望，对自身要给予服务转换团队的支持及需要提供的资源有清晰的认识。

一个好的服务转换计划中，还会明确服务转换过程的监控机制、阶段性的回顾机制以及交付物的验收机制，从而进一步确保全过程的顺利执行。

4.2.2活动

转换计划阶段的主要活动，包括计划沟通、计划制定、计划评估确认与计划修订，鉴于服务转换计划对整个服务转换过程的重要指导意义，所以这是一个循环反复的过程。

（1）计划沟通

在制定服务转换计划之前，须分别与客户、服务设计环节的负责人与服务交付团队的负责人进行详细的沟通。分别的要点如下：

• 在和客户的沟通中，要着重了解客户的期望，以及客户能够提供何种资源上的支持；
• 在和服务设计环节负责人的沟通中，要着重了解服务设计的要素，确保无遗漏，以免出现与服务设计差距较大的情况；同时要详细了解服务设计环节中已经考虑到的风险控制机制，以确保在转换阶段将其导入生产环境；
• 在与服务交付团队负责人的沟通中，要着重了解其服务能力，以确保为其计划充足的培训时间与培训内容，同时依据其服务能力定义合理的服务目标。
  

（2）计划制定

在制定服务转换计划的过程中，要做周密的考虑，确保其可执行、可监控，也要确保服务周期与相应的成本投入的合理性。转换计划主要包括如下内容：

转换阶段的责任人

必须有明确的责任人对服务转换的全过程负责，既可以对全过程进行监控，也可以不断的推动全过程的顺利进行，同时协调各团队对出现的问题及时采取补救措施。

角色和职责

通常来说，以下几种角色会参与服务转换过程：

• IT服务项目经理：通常IT运维服务项目的服务转换负责人由该项目的IT服务项目经理来担任，也可以指派专门的服务转换经理作为服务转换的负责人。负责服务转换阶段各项具体工作的落地执行，同时负责服务的测试与发布，对服务转换的结果负责；
• IT服务总监：负责与客户的沟通与协调，主要参与服务转换的阶段性回顾，对服务转换的计划和结果进行审核；
• 客户接口人：负责提供服务交付团队所需的资源与支持；
• PMO（项目管理办公室）：实现IT服务项目组织的战略目标和利益，协调统一管理项目群，调配项目所需要共享组织的资源。
  

具体的IT服务转换过程中涉及的角色与职责实例，参见4.2.5章节。

各阶段的时间点与里程碑

主要描述各阶段要在什么时间点完成，如何确认它的顺利完成。

通常来说，客户对服务转换周期都会有明确的期望或要求，因此要严格的控制各阶段的周期长短，并定义各阶段完成的里程碑；里程碑的好处是让服务转换团队、服务交付团队与客户对各阶段的收尾标识有明确的认知。

各阶段的具体工作任务与负责人

服务转换计划一般分为两部分内容，一部分内容关注如何交接现有的服务（或如何建立起新服务），另一部分内容关注服务管理体系的导入。这两部分内容可以视为两条主线，分别贯穿于服务转换的全过程，且互相制约与影响，通常来说这两条主线并行执行。

对于如何交接服务或如何建立起新服务，更多的是与具体的服务类型有关。例如桌面管理服务相对于数据库管理服务，由于其服务类型不同，其计划也大不相同，因此无法给出标准化的描述。此处我们主要关注服务管理体系的导入。

作为一个计划，一定要有明确的任务列表与分工。此处列示服务转换计划中必须的工作内容：

• 服务转换启动会；
• 服务团队组建计划；
• 服务团队培训与知识转移计划；
• 服务工具5采购、安装部署、测试、初始化与上线计划；
  

5服务工具通常包括：服务管理工具、系统监控工具、知识库工具、远程连接工具、数据库管理工具等。服务工具
初始化主要是指系统客户化配置及信息初始化录入。

• 核对服务目标；
• 核对服务目录；
• 设定服务模型；
• 客户化服务管理流程（事件管理、问题管理、变更管理、配置管理、发布管理、可用性与连续性管理、能力管理、信息安全管理流程等）；
• 设定流程绩效指标；
• 初始化服务文档体系与文档管理规范；
• 初始化配置管理数据库（CMDB）；
• 客户化服务规范；
• 开发工作指导书和标准操作规范；
• 编写服务计划；
• 服务发布会/服务转换总结会。
  

上述各项工作内容，均要指派到具体的责任人，并明确其交付物。

交付物列表

此处仅对上述部分的服务转换工作内容交付物举例说明，如：
“服务团队组建计划”的输出物为：

• 服务运营团队组织结构；
• 服务运营团队角色与职责。
  

“服务工具采购、安装部署、测试、初始化与上线计划”的输出物为：

• 服务工具上线计划。上线计划应包含上线目的、上线时间、上线相关角色和职责定义、沟通计划、上线过程中的风险分析、回退计划、交付物列表和验收标准等上线关键要素；
• 服务工具测试计划。测试计划应包含相关角色和职责定义、测试范围、测试环境、测试进度安排、测试项及具体测试方法等测试关键要素；
• 服务工具测试报告。测试报告应清晰说明测试计划的完成情况、测试过程中发现的已知错误、测试结果的分析说明以及测试结果的审核确认等主要内容；
• 服务工具上线报告。上线报告应清晰说明上线计划的完成情况、上线结果的分析说明、上线过程中相关突发事件的总结与分析、配置管理数据库的更新情况汇总、上线过程中的相关资源支持情况、经验总结及改进建议等主要内容；
• 服务工具操作指南。操作指南需要包含发布范围、目标用户、工具简介、如何下载与安装、如何使用或常见操用方法、支持团队联系方式等信息；
• 服务工具配置手册。配置手册需要包含厂商、版本号、配置变更历史记录、客户化配置方法与说明等重要信息。
  

交付物验收标准

不仅要描述交付物的质量标准（例如交付物是文档，要明确其文档规范、应包含的内容等），还要描述交付物的提交形式，例如是纸质或电子介质等。

除了验收标准，若能同时计划交付物的验收方法则为更佳。

切忌以超出自身的服务能力范围的要求来设定交付物验收标准，这样会为服务转换收尾工作带来很大的困难。

对客户的要求

对服务转换而言，它是服务运营的初始化阶段，也是服务交付团队与客户的磨合期，这是一个双方互动的过程，客户的协助与支持是必不可少的。

服务转换计划中必须对客户方所要提供的资源和支持提出明确的要求，这需要进行细致的考虑，也需要与客户做深入的沟通，切忌提出不切实际的需求。但同时，在把客户方提供的资源和支持视为输入时，则需要明确的计划对此的输出，让客户感受到他所提供的资源和支持是有价值的，也能够取得其最大化的支持。

（3）计划评估与确认

服务转换计划制定完成后，IT服务项目经理要和IT服务总监、PMO以及客户接口人做充分的沟通并做确认。项目干系人要对此计划的风险做评估，确保投入的资源可以按计划输出符合要求的交付物，以确保服务转换顺利完成。

若评估过程中发现有潜在的风险，则要进入计划修订环节。

（4）计划修订

在计划评估确认环节，若发现潜在的风险或不合理的行动计划，则需要对计划进行重新修订。仍需要依据前述的“计划制定”的要求进行仔细的梳理与编排，完成后再次提交评审；如此反复直至服务转换计划得到了所有项目干系人的认可和确认。

4.2.3关键成功因素

服务转换计划阶段的关键成功因素包括如下四项：

• 明确的服务转换阶段责任人；
• 明确的里程碑和交付物，以及交付物的验收标准；
• 对服务资源的准确预测；
• 服务连续性保障。
  

其中，“服务转换阶段的责任人”以及“明确的里程碑和交付物，以及交付物的验收标准”在前面的“计划制定”中已经有了明确的描述，本小节主要对后两点做说明。

对服务能力和资源的准确预测

对服务能力和资源的准确预测，是服务转换计划的成功要素之一：一方面，能力和资源是支撑计划能够得以实施的必要条件，只有在充足的能力和资源保障前提下，才可以按计划完成服务转换的全过程；另一方面，服务转换的目标是服务运营的标准化与规范化，它会为服务运营过程定义阶段化的服务目标，若没有充足的服务能力和资源支撑，也就无法在运营阶段不断的达成预定义的服务目标。

因此，此处所说的服务能力和资源，既是指服务转换阶段的各种能力和资源（包括服务转换团队与客户提供的），也是指服务运营阶段的能力和资源（包括服务人员、服务流程、服务技术、服务资源四方面）。

只有对服务能力和资源有了充分的、正确的预测与认知，才可以定义合理的目标，保证服务运营阶段有能力按照预定义的“标准化”与“规范化”的轨道持续运行，也即保障服务转换的成功实施。

服务能力和资源预测模型，如下：

图4．1．服．务．能．力．与．资．源．预．测．模．型．

服务连续性保障

在服务转换期间，如何保障连续性是重要的关注点。

例如，对于4.1.1节“典型的服务转换场景介绍”中的场景三“服务商的切换”，在整个切换期间存在很多的风险，需要有充足的额外服务资源的保障，以应对切换过程中的各种突发状况。

再例如，对于新上线的应用系统，由于知识库或已知错误库还不完整，因此无法确保服务团队能够应付服务转换过程中的突发事件，则需要制定相应的连续性计划/应急预案，以确保在出现突发事件时能够保障系统的服务不中断。

可靠的连续性保障是用户满意度的关键，特别是在服务转换期间；如果刚接管的服务即出现频繁的服务中断，将会直接影响客户对服务提供商的服务质量、服务能力的期望。

因此，必须在服务转换计划阶段，充分的考虑服务过程中可能出现的突发状况，并预先定义好应急预案；以下简要列出应急预案必须的要素：

• 对可能出现的突发状况的描述；
• 由何人负责启动该应急预案；
• 恢复服务所须的行动步骤和相应的责任人；
• 出现突发状况时的通知机制。
  

4.2.4可能存在的风险和控制

通常来说，可能存在的风险或问题包括：

• 服务转换计划的完整性和条理性；
• 服务转换计划本身的可用性；
• 服务转换交付物的可验收性；
• 与服务设计和服务运营的吻合性。
  

服务转换计划的完整性和条理性

常见的计划完整性问题包括：没有考虑服务转换期间的服务连续性、忽略了服务运营团队的培训、未考虑供应商的配合、未明确对客户的资源要求等。

常见的计划条理性问题包括：

• 服务工具未上线即启动服务测试；
• 未定义服务目标即开始客户化服务管理流程；
• 流程与规范未开发完成即启动团队培训；
• 团队未组建完成即开始进行知识转移。
  

上述问题均会导致计划的各个环节无法顺利的衔接，以至于计划部分或完全失效，部分资源频繁处于等待状态，无法正常工作，或者会出现“无用功”的情况。

在此对于“未定义服务目标即开始客户化服务管理流程”做详细说明：服务管理流程以及相关的资源配置、角色设定等，都是为了支撑服务目标的达成，换句话说，有了服务目标，服务管理流程的规范化才有了明确的导向；进一步，服务管理流程是否能够有效的支撑服务目标的达成，需要进一步设定流程绩效指标（KPI），以便于定期考核并持续改进。

服务转换计划本身的可用性

此处的可用性是指计划本身的可操作性、可交付性和可控制性。

可操作性：是指所有的服务组件或服务资源，可以支撑在规定时间内的计划实施，且无职责盲区或职责的重叠。这也是计划的常见风险之一，需要在计划完成后与职责相关方做明确的沟通以排除风险。

可交付性：是指计划的输出物是明确的、合理的，不超出能力范围，且责任人能够清晰的理解对交付物的要求。这也是建立在充分沟通的基础上，才可以规避此风险。

可控制性：是指各项计划不仅要有责任人，还要有专人负责全程监控、及时预警，并有专人对交付物的质量做初步验收。这是计划阶段最常见的问题，任何计划都需要有责任人、监控人和验收人，从机制上确保计划的顺利进行，缺乏此机制会出现不可预见的风险。

服务转换交付物的可验收性

交付物的验收标准不明确，是计划阶段最大的风险，不仅会导致服务转换团队输出不合格的交付物，也会导致客户对交付物的理解偏差，对验收结果带来严重的影响。

交付物的验收标准要清晰、明确、量化，且可被测量，验收方式要具备可操作性；通常可以遵循SMART原则来进行设定。

• Specific（明确的）：具体就是要清楚地说明要达成的行为标准。明确的目标几乎是所有成功团队的一致特点。很多团队不成功的重要原因之一就因为目标定的模棱两可，或没有将目标有效的传达给相关成员。比如增强客户服务意识，这个目标的描述就很不明确，有很多增强客户服务意识的方法，且增强客户意识到底是什么样的程度，这里都没有具体定义，不明确就没有办法评判、衡量；
• Measurable（可衡量）：指KPI是量化的，且验证这些KPI指标的数据或者信息是可以获得的，无法量化就无法衡量和考核。如热线服务满意度>85%，就是一个可衡量的指标，而将KPI定位为服务效率高，就不是合理指标，其没有具体量化，无法测量和考核；
• Achievable（可达成）：指绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标。如要求客户满意度100%，这个指标订立的很不现实，虽然服务质量本身是一致的，但不同的客户，在不同的情形下，服务感知不同，因而很难达到100%的满意；
• Realistic（现实的）：是指在现实条件下是否可行、可操作。如希望将到场时间由2个小时降低为30分钟。这在既定的成本、资源约束上是不现实，为了达成这个指标，在投入比实际收益要多很多的情况下，KPI指标订立的就不现实；
• Time（时限性）：指标的订立要有明确的时间期限说明，如投诉指标小于3次，1个月和1年的时限，指标级别完全不同，1年投诉小于3次的指标远高于1个月投诉小于3次的指标要求。
  

与服务设计和服务运营的吻合性

最后要强调的风险，是对于整个服务管理的生命周期而言的，由于服务转换衔接了服务设计与服务运营，而服务转换计划又是服务转换的重中之重，计划的好坏直接影响到整个服务管理生命周期的顺利衔接。

常见的风险是服务设计、服务转换、服务运营这三个环节的脱节，各个环节的团队有各自的认知、无法形成有机的整体。



上述风险，需要通过服务转换的计划阶段对其进行有效的衔接，将服务设计的要素完整的导入符合服务管理体系标准的生产环境，为服务运营提供切实可行的指导，真正的达到标准化、规范化的轨道化运营的目的。

4.2.5参考实例





以上实例仅供参考，详细计划的具体制定需要参见4.2.2章节的要求，根据项目实际情况进行编制。

*************************************************************

返回到首页《ITSS认证IT服务项目经理培训教材》_试用版连载http://www.ITILxf.com/thread-36762-1-1.htmlITSS、培训、服务、资格、评估、ITSS培训师、ITSS评估师、实施ITSS、ITSS符合性、ITSS服务工程师、ITSS服务项目经理、ITSS标准、ITSS咨询、ITSS工具、IT服务监理、ITSS体系、ITSS服务质量、评价、指标、运维、治理、咨询、ITSS出版物、ITSS产品、服务监理工具、服务质量评价工具、标准符合性评估工具、服务管理工具、服务治理工具、系统监控工具、辅助决策分析、服务支持管理、基础设施监控、ITSS基础教材、ITSS标准、ITSS服务人员培训教材、标准化、专业化、人员（People）、流程[1]（Process）、技术（Technology）和资源（Resource），简称PPTR、规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision），简称PIOIS、服务交付规范、资源要求、外包管理、服务交付、分类、代码、服务指南、通用要求、指标体系、ITSS落地实践交流-QQ群：21542747

干货推荐：



中国ITSS白皮书2.0【第二版】PDF

ITSS服务项目经理培训

ITSS服务项目经理培训——2-基本概念及方法

ITSS服务项目经理培训——3-IT服务设计

ITSS服务项目经理培训——4-IT服务转换

ITSS服务项目经理培训——5-IT服务运营(3)

ITSS服务项目经理培训——6-IT服务改进

ITSS服务项目经理培训——7-IT服务项目类别

ITSS服务项目经理培训——9-IT服务项目管理知识体系(1)

ITSS服务项目经理培训——10-IT服务项目群管理

4.2服务转换计划

4.2.1目的

服务转换计划的目的是确保服务转换的全过程在有序、可控的条件下顺利的进行。

对于服务转换而言，一个好的计划是不可或缺的，它也是转换计划阶段的重要输出物。

由于服务转换要在“一定的时间、可接受的成本和质量标准”内，以保证新服务或变更服务的顺利发布，并协调和组织构成服务的所有组件（这其中包括组织、人员、流程、知识以及其他资源）。那么，如何在时间一定、有限的资源投入的情况下，确保服务质量可控并达成既定的服务转换目标，就是服务转换计划作用的最直接、最重要的体现。

一个好的服务转换计划，可以让整个服务转换团队有明确的目标，在各自明确的职责范围内很好的协同工作，并且对交付物有明确的、统一的认知，从而确保服务转换能够被顺利执行，并顺利收尾；一个好的服务转换计划，同样也可以让客户对服务转换进度有清晰的了解，对服务转换阶段的交付物有明确的期望，对自身要给予服务转换团队的支持及需要提供的资源有清晰的认识。

一个好的服务转换计划中，还会明确服务转换过程的监控机制、阶段性的回顾机制以及交付物的验收机制，从而进一步确保全过程的顺利执行。

4.2.2活动

转换计划阶段的主要活动，包括计划沟通、计划制定、计划评估确认与计划修订，鉴于服务转换计划对整个服务转换过程的重要指导意义，所以这是一个循环反复的过程。

（1）计划沟通

在制定服务转换计划之前，须分别与客户、服务设计环节的负责人与服务交付团队的负责人进行详细的沟通。分别的要点如下：

• 在和客户的沟通中，要着重了解客户的期望，以及客户能够提供何种资源上的支持；
• 在和服务设计环节负责人的沟通中，要着重了解服务设计的要素，确保无遗漏，以免出现与服务设计差距较大的情况；同时要详细了解服务设计环节中已经考虑到的风险控制机制，以确保在转换阶段将其导入生产环境；
• 在与服务交付团队负责人的沟通中，要着重了解其服务能力，以确保为其计划充足的培训时间与培训内容，同时依据其服务能力定义合理的服务目标。
  

（2）计划制定

在制定服务转换计划的过程中，要做周密的考虑，确保其可执行、可监控，也要确保服务周期与相应的成本投入的合理性。转换计划主要包括如下内容：

转换阶段的责任人

必须有明确的责任人对服务转换的全过程负责，既可以对全过程进行监控，也可以不断的推动全过程的顺利进行，同时协调各团队对出现的问题及时采取补救措施。

角色和职责

通常来说，以下几种角色会参与服务转换过程：

• IT服务项目经理：通常IT运维服务项目的服务转换负责人由该项目的IT服务项目经理来担任，也可以指派专门的服务转换经理作为服务转换的负责人。负责服务转换阶段各项具体工作的落地执行，同时负责服务的测试与发布，对服务转换的结果负责；
• IT服务总监：负责与客户的沟通与协调，主要参与服务转换的阶段性回顾，对服务转换的计划和结果进行审核；
• 客户接口人：负责提供服务交付团队所需的资源与支持；
• PMO（项目管理办公室）：实现IT服务项目组织的战略目标和利益，协调统一管理项目群，调配项目所需要共享组织的资源。
  

具体的IT服务转换过程中涉及的角色与职责实例，参见4.2.5章节。

各阶段的时间点与里程碑

主要描述各阶段要在什么时间点完成，如何确认它的顺利完成。

通常来说，客户对服务转换周期都会有明确的期望或要求，因此要严格的控制各阶段的周期长短，并定义各阶段完成的里程碑；里程碑的好处是让服务转换团队、服务交付团队与客户对各阶段的收尾标识有明确的认知。

各阶段的具体工作任务与负责人

服务转换计划一般分为两部分内容，一部分内容关注如何交接现有的服务（或如何建立起新服务），另一部分内容关注服务管理体系的导入。这两部分内容可以视为两条主线，分别贯穿于服务转换的全过程，且互相制约与影响，通常来说这两条主线并行执行。

对于如何交接服务或如何建立起新服务，更多的是与具体的服务类型有关。例如桌面管理服务相对于数据库管理服务，由于其服务类型不同，其计划也大不相同，因此无法给出标准化的描述。此处我们主要关注服务管理体系的导入。

作为一个计划，一定要有明确的任务列表与分工。此处列示服务转换计划中必须的工作内容：

• 服务转换启动会；
• 服务团队组建计划；
• 服务团队培训与知识转移计划；
• 服务工具5采购、安装部署、测试、初始化与上线计划；
  

5服务工具通常包括：服务管理工具、系统监控工具、知识库工具、远程连接工具、数据库管理工具等。服务工具
初始化主要是指系统客户化配置及信息初始化录入。

• 核对服务目标；
• 核对服务目录；
• 设定服务模型；
• 客户化服务管理流程（事件管理、问题管理、变更管理、配置管理、发布管理、可用性与连续性管理、能力管理、信息安全管理流程等）；
• 设定流程绩效指标；
• 初始化服务文档体系与文档管理规范；
• 初始化配置管理数据库（CMDB）；
• 客户化服务规范；
• 开发工作指导书和标准操作规范；
• 编写服务计划；
• 服务发布会/服务转换总结会。
  

上述各项工作内容，均要指派到具体的责任人，并明确其交付物。

交付物列表

此处仅对上述部分的服务转换工作内容交付物举例说明，如：
“服务团队组建计划”的输出物为：

• 服务运营团队组织结构；
• 服务运营团队角色与职责。
  

“服务工具采购、安装部署、测试、初始化与上线计划”的输出物为：

• 服务工具上线计划。上线计划应包含上线目的、上线时间、上线相关角色和职责定义、沟通计划、上线过程中的风险分析、回退计划、交付物列表和验收标准等上线关键要素；
• 服务工具测试计划。测试计划应包含相关角色和职责定义、测试范围、测试环境、测试进度安排、测试项及具体测试方法等测试关键要素；
• 服务工具测试报告。测试报告应清晰说明测试计划的完成情况、测试过程中发现的已知错误、测试结果的分析说明以及测试结果的审核确认等主要内容；
• 服务工具上线报告。上线报告应清晰说明上线计划的完成情况、上线结果的分析说明、上线过程中相关突发事件的总结与分析、配置管理数据库的更新情况汇总、上线过程中的相关资源支持情况、经验总结及改进建议等主要内容；
• 服务工具操作指南。操作指南需要包含发布范围、目标用户、工具简介、如何下载与安装、如何使用或常见操用方法、支持团队联系方式等信息；
• 服务工具配置手册。配置手册需要包含厂商、版本号、配置变更历史记录、客户化配置方法与说明等重要信息。
  

交付物验收标准

不仅要描述交付物的质量标准（例如交付物是文档，要明确其文档规范、应包含的内容等），还要描述交付物的提交形式，例如是纸质或电子介质等。

除了验收标准，若能同时计划交付物的验收方法则为更佳。

切忌以超出自身的服务能力范围的要求来设定交付物验收标准，这样会为服务转换收尾工作带来很大的困难。

对客户的要求

对服务转换而言，它是服务运营的初始化阶段，也是服务交付团队与客户的磨合期，这是一个双方互动的过程，客户的协助与支持是必不可少的。

服务转换计划中必须对客户方所要提供的资源和支持提出明确的要求，这需要进行细致的考虑，也需要与客户做深入的沟通，切忌提出不切实际的需求。但同时，在把客户方提供的资源和支持视为输入时，则需要明确的计划对此的输出，让客户感受到他所提供的资源和支持是有价值的，也能够取得其最大化的支持。

（3）计划评估与确认

服务转换计划制定完成后，IT服务项目经理要和IT服务总监、PMO以及客户接口人做充分的沟通并做确认。项目干系人要对此计划的风险做评估，确保投入的资源可以按计划输出符合要求的交付物，以确保服务转换顺利完成。

若评估过程中发现有潜在的风险，则要进入计划修订环节。

（4）计划修订

在计划评估确认环节，若发现潜在的风险或不合理的行动计划，则需要对计划进行重新修订。仍需要依据前述的“计划制定”的要求进行仔细的梳理与编排，完成后再次提交评审；如此反复直至服务转换计划得到了所有项目干系人的认可和确认。

4.2.3关键成功因素

服务转换计划阶段的关键成功因素包括如下四项：

• 明确的服务转换阶段责任人；
• 明确的里程碑和交付物，以及交付物的验收标准；
• 对服务资源的准确预测；
• 服务连续性保障。
  

其中，“服务转换阶段的责任人”以及“明确的里程碑和交付物，以及交付物的验收标准”在前面的“计划制定”中已经有了明确的描述，本小节主要对后两点做说明。

对服务能力和资源的准确预测

对服务能力和资源的准确预测，是服务转换计划的成功要素之一：一方面，能力和资源是支撑计划能够得以实施的必要条件，只有在充足的能力和资源保障前提下，才可以按计划完成服务转换的全过程；另一方面，服务转换的目标是服务运营的标准化与规范化，它会为服务运营过程定义阶段化的服务目标，若没有充足的服务能力和资源支撑，也就无法在运营阶段不断的达成预定义的服务目标。

因此，此处所说的服务能力和资源，既是指服务转换阶段的各种能力和资源（包括服务转换团队与客户提供的），也是指服务运营阶段的能力和资源（包括服务人员、服务流程、服务技术、服务资源四方面）。

只有对服务能力和资源有了充分的、正确的预测与认知，才可以定义合理的目标，保证服务运营阶段有能力按照预定义的“标准化”与“规范化”的轨道持续运行，也即保障服务转换的成功实施。

服务能力和资源预测模型，如下：

图4．1．服．务．能．力．与．资．源．预．测．模．型．

服务连续性保障

在服务转换期间，如何保障连续性是重要的关注点。

例如，对于4.1.1节“典型的服务转换场景介绍”中的场景三“服务商的切换”，在整个切换期间存在很多的风险，需要有充足的额外服务资源的保障，以应对切换过程中的各种突发状况。

再例如，对于新上线的应用系统，由于知识库或已知错误库还不完整，因此无法确保服务团队能够应付服务转换过程中的突发事件，则需要制定相应的连续性计划/应急预案，以确保在出现突发事件时能够保障系统的服务不中断。

可靠的连续性保障是用户满意度的关键，特别是在服务转换期间；如果刚接管的服务即出现频繁的服务中断，将会直接影响客户对服务提供商的服务质量、服务能力的期望。

因此，必须在服务转换计划阶段，充分的考虑服务过程中可能出现的突发状况，并预先定义好应急预案；以下简要列出应急预案必须的要素：

• 对可能出现的突发状况的描述；
• 由何人负责启动该应急预案；
• 恢复服务所须的行动步骤和相应的责任人；
• 出现突发状况时的通知机制。
  

4.2.4可能存在的风险和控制

通常来说，可能存在的风险或问题包括：

• 服务转换计划的完整性和条理性；
• 服务转换计划本身的可用性；
• 服务转换交付物的可验收性；
• 与服务设计和服务运营的吻合性。
  

服务转换计划的完整性和条理性

常见的计划完整性问题包括：没有考虑服务转换期间的服务连续性、忽略了服务运营团队的培训、未考虑供应商的配合、未明确对客户的资源要求等。

常见的计划条理性问题包括：

• 服务工具未上线即启动服务测试；
• 未定义服务目标即开始客户化服务管理流程；
• 流程与规范未开发完成即启动团队培训；
• 团队未组建完成即开始进行知识转移。
  

上述问题均会导致计划的各个环节无法顺利的衔接，以至于计划部分或完全失效，部分资源频繁处于等待状态，无法正常工作，或者会出现“无用功”的情况。

在此对于“未定义服务目标即开始客户化服务管理流程”做详细说明：服务管理流程以及相关的资源配置、角色设定等，都是为了支撑服务目标的达成，换句话说，有了服务目标，服务管理流程的规范化才有了明确的导向；进一步，服务管理流程是否能够有效的支撑服务目标的达成，需要进一步设定流程绩效指标（KPI），以便于定期考核并持续改进。

服务转换计划本身的可用性

此处的可用性是指计划本身的可操作性、可交付性和可控制性。

可操作性：是指所有的服务组件或服务资源，可以支撑在规定时间内的计划实施，且无职责盲区或职责的重叠。这也是计划的常见风险之一，需要在计划完成后与职责相关方做明确的沟通以排除风险。

可交付性：是指计划的输出物是明确的、合理的，不超出能力范围，且责任人能够清晰的理解对交付物的要求。这也是建立在充分沟通的基础上，才可以规避此风险。

可控制性：是指各项计划不仅要有责任人，还要有专人负责全程监控、及时预警，并有专人对交付物的质量做初步验收。这是计划阶段最常见的问题，任何计划都需要有责任人、监控人和验收人，从机制上确保计划的顺利进行，缺乏此机制会出现不可预见的风险。

服务转换交付物的可验收性

交付物的验收标准不明确，是计划阶段最大的风险，不仅会导致服务转换团队输出不合格的交付物，也会导致客户对交付物的理解偏差，对验收结果带来严重的影响。

交付物的验收标准要清晰、明确、量化，且可被测量，验收方式要具备可操作性；通常可以遵循SMART原则来进行设定。

• Specific（明确的）：具体就是要清楚地说明要达成的行为标准。明确的目标几乎是所有成功团队的一致特点。很多团队不成功的重要原因之一就因为目标定的模棱两可，或没有将目标有效的传达给相关成员。比如增强客户服务意识，这个目标的描述就很不明确，有很多增强客户服务意识的方法，且增强客户意识到底是什么样的程度，这里都没有具体定义，不明确就没有办法评判、衡量；
• Measurable（可衡量）：指KPI是量化的，且验证这些KPI指标的数据或者信息是可以获得的，无法量化就无法衡量和考核。如热线服务满意度>85%，就是一个可衡量的指标，而将KPI定位为服务效率高，就不是合理指标，其没有具体量化，无法测量和考核；
• Achievable（可达成）：指绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标。如要求客户满意度100%，这个指标订立的很不现实，虽然服务质量本身是一致的，但不同的客户，在不同的情形下，服务感知不同，因而很难达到100%的满意；
• Realistic（现实的）：是指在现实条件下是否可行、可操作。如希望将到场时间由2个小时降低为30分钟。这在既定的成本、资源约束上是不现实，为了达成这个指标，在投入比实际收益要多很多的情况下，KPI指标订立的就不现实；
• Time（时限性）：指标的订立要有明确的时间期限说明，如投诉指标小于3次，1个月和1年的时限，指标级别完全不同，1年投诉小于3次的指标远高于1个月投诉小于3次的指标要求。
  

与服务设计和服务运营的吻合性

最后要强调的风险，是对于整个服务管理的生命周期而言的，由于服务转换衔接了服务设计与服务运营，而服务转换计划又是服务转换的重中之重，计划的好坏直接影响到整个服务管理生命周期的顺利衔接。

常见的风险是服务设计、服务转换、服务运营这三个环节的脱节，各个环节的团队有各自的认知、无法形成有机的整体。



上述风险，需要通过服务转换的计划阶段对其进行有效的衔接，将服务设计的要素完整的导入符合服务管理体系标准的生产环境，为服务运营提供切实可行的指导，真正的达到标准化、规范化的轨道化运营的目的。

4.2.5参考实例





以上实例仅供参考，详细计划的具体制定需要参见4.2.2章节的要求，根据项目实际情况进行编制。

*************************************************************

返回到首页《ITSS认证IT服务项目经理培训教材》_试用版连载http://www.ITILxf.com/thread-36762-1-1.htmlITSS、培训、服务、资格、评估、ITSS培训师、ITSS评估师、实施ITSS、ITSS符合性、ITSS服务工程师、ITSS服务项目经理、ITSS标准、ITSS咨询、ITSS工具、IT服务监理、ITSS体系、ITSS服务质量、评价、指标、运维、治理、咨询、ITSS出版物、ITSS产品、服务监理工具、服务质量评价工具、标准符合性评估工具、服务管理工具、服务治理工具、系统监控工具、辅助决策分析、服务支持管理、基础设施监控、ITSS基础教材、ITSS标准、ITSS服务人员培训教材、标准化、专业化、人员（People）、流程[1]（Process）、技术（Technology）和资源（Resource），简称PPTR、规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision），简称PIOIS、服务交付规范、资源要求、外包管理、服务交付、分类、代码、服务指南、通用要求、指标体系、ITSS落地实践交流-QQ群：21542747