|
|
|
|
|
IT服务部署实施执行是整个IT服务部署实施过程中周期最长的一个阶段，是一个被多重机制严格管控的不断推进的过程，通过有效的监控和变更方法开展工作，保证项目以计划设定或变更批准后的方式进行实施。其目的是协调各种资源，按照IT服务部署实施计划的要求输出相应的交付物，使包括客户、第三方供应商、项目团队等在内的所有项目干系人，在有效地执行跟踪、评估检查和变更控制下，按照服务级别协议和项目计划，持续改进实施项目。系统规划与管理师通过管理项目执行和监控阶段，为项目收尾奠定基础。
|
|
|
|
实际上，IT服务部署实施执行阶段更深层次的目的，是利用各种可能的方法提升资源效率，利用标准化与规范化的手段来弱化服务运营团队中的个人能力影响或依赖因素，并不断地寻求资源投入与服务级别的平衡点，以最终搭建成确保达成服务级别协议（SLA）的最有效资源组合。
|
|
|
|
上述目的也是对IT服务部署实施的总体定位“将IT服务运营纳入标准化与规范化的管理轨道”的进一步阐述，是将IT服务部署实施环节纳入IT服务管理生命周期的真正意义所在。只有将服务进行标准化与规范化，才能弱化人员个人能力因素的影响，才可以用更合理的资源来保障服务级别协议的达成，才能体现出部署实施真正的价值。
|
|
|
|
在IT服务部署实施执行阶段中，系统规划与管理师应至少与所有项目干系人达成以下12方面的共识。
|
|
|
|
|
|
（2）项目的交付物及其约束条件，包括无形的交付物（如保障IT系统稳定运行）和有形的交付物（如服务报告）。
|
|
|
|
（3）项目的交付方式、交付时间及其投入，如通过现场或远程方式提供服务。
|
|
|
|
（4）项目的范围，通常包括基础环境、硬件、软件、场地等服务范围。
|
|
|
|
（5）项目初步实现所要求的条件，如人员、资源、技术、过程。
|
|
|
|
|
|
（7）对部署实施计划所需资源的验证，包括由服务商自行提供的资源、第三方（供应商）提供的资源、客户提供的资源等。只有在相关资源都安排到位的情况下，才可以正式启动部署实施。
|
|
|
|
（8）与项目干系人做计划的正式声明和沟通，对各种资源提出正式的要求。如果仅是资源充足，但缺乏各资源之间的配合，也无法达成目标。这涉及包括服务提供商内部的决策者、规划设计团队、部署实施团队、服务运营团队，还包括第三方供应商或设备原厂商、客户方接口人或项目管理团队等项目干系人，甚至涉及其他各种类型的技术支持渠道等。
|
|
|
|
（9）角色和职责包括：成员角色、权利、职责和能力。
|
|
|
|
.角色：描述了为完成IT服务项目所进行的职责划分。项目成员角色的例子包括一线／二线工程师、项目协调员、资产管理员、文档管理员、呼叫中心员工等。考虑到权利、职责和边界问题，角色的透明性对于项目是否成功至关重要。
|
|
|
|
.权利：指能够支配项目资源和决策的权利。项目决策的例子包括选择完成任务的方法，质量接受水平，以及如何对项目进行中的偏差做出反应。当团队成员的权利与他们的职责匹配时，他们能做得最好。
|
|
|
|
.职责：指为了完成IT服务项目任务和活动，项目团队应该执行的工作。
|
|
|
|
.能力：指完成项目活动所需要的技能和能力。如果项目团队成员不具备所需的能力，就会损害执行。发现这种不匹配时，须采取一些预先的措施，如培训、雇佣额外的人员或调整项目范围。
|
|
|
|
（10）项目的组织结构图。项目的组织结构图以图形表示项目汇报关系，根据项目的不同需要，可以是正式的或非正式的，高度细节化的或粗略描述的。例如，5个人的服务台项目的组织结构图与15个人的机房搬迁项目的组织结构图的精确度和详细度会有所不同。
|
|
|
|
（11）人员配备管理计划。人员配备管理计划描述的是人力资源需求何时及怎样被满足，可以是正式的或非正式的，既可以非常详细，也可以比较概略。为了指导正在进行的团队成员获取和开发活动，人员配备管理计划随着项目的继续要进行更新。人员管理计划中的信息随着项目应用领域和规模的不同而不同，但是具体条目应该考虑包括人员获取、时间表、人力资源释放标注、培训需求、认可和建立、遵从某些约定及安全性。
|
|
|
|
人力资源规划是一个动态的过程，必须关注影响人力资源规划的各种因素。一些组织在人力资源开发与管理的实践中，往往缺乏动态的人力资源规划和开发观念，把人力资源规划理解为静态的收集信息和相关的认识政策信息，无论是在观念上还是实践上都有依赖于以往规划、一劳永逸的思想。这是一种错误观念。因为这种静态观念与动态的市场需求和人才自身发展的需求是极不适应的，造成人力资源得不到合理利用，甚至严重影响了人力资源的稳定性，对组织的发展极为不利。因此，组织在做人力资源规划时，须坚持动态的规划，密切关注影响人力资源规划的一些重要因素。
|
|
|
|
|
|
|
|
（1）按规划开展活动，以实现项目目标，创造项目的可交付成果，包括：
|
|
|
|
|
|
.与项目干系人正式地对部署实施计划做沟通，特别是确认各角色与对应的职责。
|
|
|
|
|
|
|
|
|
|
.知识库：由于部署实施是服务运营的初始化阶段，在部署实施执行期间已经开始了服务的并行测试，此阶段是积累知识的最佳时期。部署实施团队要与服务运营团队积极配合，定期总结部署实施期间出现的各种常见故障和已知错误（如TOP10的已知错误），将其整理并归纳入知识库。
|
|
|
|
.面向服务的配置管理数据库（CMDB）：配置管理数据库的初始化及客户化，要依据服务提供商能管理的范围来确定，不属于自身管理范围的项目不需要纳入配置管理数据库进行管理。通常来说，配置管理数据库包括如下要素：硬件、软件（软件许可也应纳入CMDB的管控）、文档（服务级别协议、工作说明书等）、人员（服务提供商自身的服务人员）。
|
|
|
|
注意，所有经过客户化的服务管理过程文档和服务规范文档应纳入配置管理的范围。一旦纳入配置管理的范围，则其变更就要受到变更管理过程的控制。下图给出了一个CMDB模型示例。
|
|
|
|
|
|
|
|
（4）执行已经计划好的过程、方法、标准，包括以下内容。
|
|
|
|
服务目标及测量机制。部署实施执行阶段的首要活动就是定义服务管理的目标，目标一定是量化的且可被测量的，同时目标又是合理的、可达到的。既然目标要求可测量，那么就需要同时定义其测量机制。此处的测量机制不仅指计算公式、数据获取方法，更重要的是指测量的“机制”，如多重测量机制（如月度、季度、年度）、多重测量方式（如服务回顾、满意度调查、IT服务审计等）。
|
|
|
|
通常，服务目标包括客户满意度、系统可用性等关键指标，需要依据具体的情况来制订。
|
|
|
|
IT服务管理过程和过程考核指标的确定。制订了服务目标后，就要客户化服务管理过程来支撑服务目标的达成，同时设定过程绩效指标，来考核过程的合理性并为其持续改进打下基础。
|
|
|
|
部署实施的总体目标包括“确保新服务或变更的服务与客户的业务组织、业务过程的顺利衔接”，因此，服务管理过程客户化的过程，不仅要考虑服务管理体系或服务管理标准的要求，还要考虑与客户业务过程、客户的组织结构的接口。
|
|
|
|
以数据中心服务外包为例，对于变更管理过程，既要有IT环节的审批，也要有业务环节的审批，包括财务环节的审批。因此，在客户化变更审批过程时，审批的角色就要涉及客户的业务部门负责人、财务部门负责人等。
|
|
|
|
文档管理。文档管理需要设定文档的编、审、批、发、改的权限，还包括：文档的命名规则、文档编号规则、文档的密级及保密期、文档的发布范围管理规则、文档外发管理、文档的作废管理机制、外来文档管理机制（更细的还要包括文档的编写规范、排版规范等）。对于外包类服务，通常必须遵循客户方的文档管理规范。
|
|
|
|
受控的变更管理机制。对于变更管理过程来说，需要注意两方面：变更管理的范围，要与配置管理的范围保持一致；变更类型的定义。
|
|
|
|
.紧急变更：指系统出现重大突发事件，为解决这些突发事件而提出的变更，如果不立即采取措施而按照正常变更管理过程，将会严重影响正常的业务运作，此时应遵循紧急变更管理过程。
|
|
|
|
.标准变更：指风险很小或没有风险的变更，并且执行这些变更的步骤和方法已经很成熟，这些变更事先已经得到审批并记录在案，遵循简化的标准变更管理过程。单个标准变更发生时，无须送至变更经理处进行审批，直接进行变更执行即可。
|
|
|
|
.常规变更：指其他不在标准变更、紧急变更范围内的变更，定义为常规变更，遵循常规变更管理过程。
|
|
|
|
.变更的审批机制。串行审批（如依次审批）、并行审批（如举手表决）。
|
|
|
|
.变更管理委员会。需要明确变更管理委员会的成员名单，通常包含客户方接口人或客户方决策人、服务项目总监、服务经理。
|
|
|
|
.紧急变更委员会。需要明确紧急变更管理委员会的成员名单，通常包含在变更管理委员会中。
|
|
|
|
.变更窗口机制。对于软件、硬件的变更通常要遵循变更窗口机制，尽量避开正常业务时间或业务高峰时段，以免影响业务的正常运转。
|
|
|
|
对于不同的变更类型，可以为其中某种类型定义“预审批”的机制，以减少变更审批的工作量，提高变更审批的效率。
|
|
|
|
（5）可信赖的发布管理机制。对于发布管理过程来说，要注意以下6方面：①发布计划。②系统测试（包括已知错误的收集）。③实施与部署计划。④回退计划。⑤验收机制。⑥系统说明书。其中，回退计划是重中之重，一定要确保在发布失败的情况下可以正确回退。要特别注意的是，回退计划也需要经过验证。
|
|
|
|
（6）IT服务连续性管理机制。对于IT服务连续性管理机制而言，不仅包括硬件、软件的连续性管理机制（如双机热备、定期数据备份与数据恢复测试等），还要考虑人员的连续性。
|
|
|
|
IT服务是由人员来交付的，所以人员的连续性是非常关键的因素。在确保有备份人员的情况下，还要保证备份人员的可用性，包括对IT环境的熟悉程度、对服务知识的掌握程度等方面，所以要设定连续性的管理机制，来确保备份人员能够获取到服务运营团队的知识。
|
|
|
|
（7）IT服务回顾机制。IT服务回顾既要考虑与客户的回顾机制与回顾内容，还要考虑服务运营团队内部的回顾机制与回顾内容。通常来说，与客户的回顾内容主要包括：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
回顾机制不仅指服务内容，还包括服务回顾的频率、不同级别的服务回顾的参与人等方面。
|
|
|
|
（8）满意度管理机制。在IT服务部署实施的执行阶段，要与客户协商并定义满意度的管理机制。例如，是按周期做客户满意度调查，还是每个服务请求完成后即做实时的满意度数据采集等。不仅要定义满意度数据的采集机制，还要定义满意度指标未达成时的改进机制。
|
|
|
|
（9）标准操作程序（服务作业指导书）。对服务运营“标准化”和“规范化”的最直接的体现。在IT服务部署实施执行阶段要列举IT服务运营过程中出现的常规操作，并为其开发作业指导书或标准操作规范，如对呼叫中心服务要开发《热线服务标准话述》，对桌面管理服务要开发《新机安装标准操作规范》，对服务器维护要开发《服务器例行巡检检查清单》、《服务器例行巡检操作规范》等。
|
|
|
|
标准操作程序（服务作业指导书）也是服务连续性的一个重要保障。对于IT服务运营过程中的人员变更，新的服务人员通过这些标准化的文档就可以迅速开始提供标准化的服务。
|
|
|
|
（10）IT服务质量计划。IT服务质量管理包含服务的功能性、安全性、可靠性、响应性、有形性和友好性。要在这些方面全面管理服务质量，就需要在部署实施阶段开发服务质量计划。服务质量计划同样关注的是质量管理机制，如项目组的内部服务回顾就是服务质量管理机制的一种直接体现，除此之外还可以有如下质量管理机制。
|
|
|
|
.项目组内部的抽检机制。如系统规划与管理师不定期地抽查服务请求的记录，包括录入是否规范、分类是否准确、常见故障的解决方案是否加入知识库等。
|
|
|
|
.定期抽检机制。如PMO或QA不定期地抽查服务项目的运营情况，是否执行了服务回顾，是否有客户投诉发生等。
|
|
|
|
.IT服务质量体系的内部审计、管理评审或外部审计，检查其服务管理过程是否在持续优化与改进，是否可以支撑其服务目标的达成等。
|
|
|
|
上述所有内容均需要在部署实施执行阶段形成周密的计划，以便在服务运营期间遵照执行和监督检查。
|
|
|
|
（11）特有的过程、专有的规范。一些特殊的行业或特殊的组织会有一些特殊的过程或规范，或者对于一些特定的应用系统、硬件设备会有其特殊的维护要求，这些均需要在部署实施的执行阶段进行详细定义。
|
|
|
|
例如，某零售组织为了加强对经销商的销售数据管理力度，在每个经销商处都部署了POS系统，用于订货单查询和上传销售数据。在系统运维服务过程中，经销商的用户权限管理过程和授权标准就需要在部署实施的执行阶段进行清晰的定义。
|
|
|
|
|
|
|
|
.组织项目团队对项目任务进行准确描述和评审，保证项目任务是所要求的。
|
|
|
|
.使项目团队了解概况，并向他们分配项目任务和提交任务相关信息，如所需成本和工作量投入、完成时间表、进度报告、与任务相关的人员或技术接口关系、任务描述等。
|
|
|
|
.识别与任务有关的问题和风险，并通过必要的变更和其他措施进行处理。
|
|
|
|
|
|
|
|
.收集目前所有已开始项目任务的进展信息，如通过定期检查报告进行收集。
|
|
|
|
|
|
.对未完成或未开始的项目任务所需的预期时间和工作量投入进行评估。
|
|
|
|
.对目前项目资源的使用情况进行评估，并对这些资源在后续阶段的可用性进行评估。
|
|
|
|
.与项目团队一起对项目是否可以在预算内按时完成进行评审。
|
|
|
|
|
|
|
|
|
|
.对项目问题进行评估和分类，以确认它们是否是变更申请、规范偏离或普遍存在的问题。
|
|
|
|
|
|
.收集所有与项目问题有关的信息，如成本、进度、风险等。
|
|
|
|
.如项目问题与已识别的现有风险相关，或带来新风险，则需要更新项目风险列表。
|
|
|
|
.明确项目问题的处理方法，一种处理方法可能对应多个项目问题。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.通过“汇报项目问题”活动，提交可能引起项目偏差超过容许偏差水平的项目问题。
|
|
|
|
|
|
|
|
|
|
|
|
.在需要寻求项目管理委员会的指导时，应将该问题的所有信息汇总并提出建议、意见。
|
|
|
|
|
|
|
|
|
|
|
|
.就偏差进行全面影响分析，包括项目干系人关系、技术、预算等。
|
|
|
|
|
|
|
|
|
|
.必须认识到项目变更控制贯穿于整个项目的执行和监控阶段中。
|
|
|
|
|
|
|
|
|
|
.对引起变更的项目问题进行影响分析，包括变更什么、需要多少投入、对项目计划有什么影响、是否会造成超出容许的项目偏差，对项目风险有什么影响等。
|
|
|
|
|
|
|
|
.必须认识到项目交付物管理贯穿于整个项目执行和监控阶段。
|
|
|
|
.与项目团队协商确定需要的项目交付物（阶段性交付物）及时间要求。
|
|
|
|
|
|
|
|
|
|
（10）服务目标——清晰化、全面化。从时间长度上来说，IT服务部署实施阶段在IT服务生命周期中只占很小的一部分，而IT服务运营是一个很长的过程。因此，在IT服务部署实施期间定义服务目标时不能只定义初期的目标，还要有规划性，为IT服务运营定义阶段性的目标，以便于IT服务运营质量与能力的持续提升，不断提高客户的满意度与忠诚度。
|
|
|
|
（11）标准操作程序（或服务作业指导书）——标准化、规范化。标准操作程序（或服务作业指导书）已在上一小节详细阐述，在此仅强调它是达成服务标准化和规范化的必要手段，也是IT服务部署实施执行阶段的最重要的工作内容。
|
|
|
|
（12）IT服务运营培训——有效性、及时性。不能仅开发标准操作程序（或服务作业指导书），IT服务运营团队还须理解并深入掌握其内容，这就需要通过培训来落实。培训不仅通过课堂培训的形式，还可以通过现场培训、考试等形式来验证服务运营团队对相关内容的掌握程度。
|
|
|
|
（13）过程绩效指标——SMART。为了支撑服务目标的“轨道化”，服务管理过程也需要持续优化来支撑目标的达成。同时，由于服务运营的成熟度随着时间不断增长，也会对服务管理过程的优化提出必需的要求。
|
|
|
|
那么，过程的哪些方面需要优化呢？这就是过程绩效指标的作用体现，通过过程绩效指标来从不同的方面考核过程的效率和成熟度，并确定需要提升和优化的方面，再进一步进行优化调整，以支撑服务运营水平的不断提高。同时，过程绩效指标的设定也要遵循SMART原则。
|
|
|
|
|
|
.资源的可用性。此处的资源不仅指硬件、软件、工具等，也包括人员，如服务运营团队、供应商的技术支持人员等。相关资源的可用性一定要在执行阶段进行验证，避免实施执行阶段由于资源变更而引起进度的延缓。
|
|
|
|
.资源的连续性。除要关注资源的可用性外，还要关注资源的连续性。在条件允许的情况下，要考虑硬件／软件的冗余，甚至人员的备份机制，以最大限度地规避部署实施期间的资源风险。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.客户期望服务级别协议的考核条款违反相关规定而无法执行。
|
|
|
|
（2）相关资源的能力不足。在执行阶段，仅验证了系统监控工具已经准备到位，但未对其支持功能做验证，如无法监控到存储设备的容量情况、无法监控到服务器的进程信息等，这都会严重影响到服务实施的进度。因此，对各种服务支持资源的验证要做充分考虑并设计完备的验证计划，不仅要考虑其可用性和连续性，还要考虑其能力情况。
|
|
|
|
（3）交付物认知水平不一致。交付物认知水平也是部署实施阶段一直在强调的问题，对交付物的理解不一致是服务管理项目潜在的风险之一，会直接影响到客户的满意度。
|
|
|
|
（4）服务级别协议中服务范围不够明确，使得项目范围、成本、进度等可能发生较大偏差，甚至导致项目无法完成。
|
|
|
|
（5）项目实施过程中服务范围发生变化，与约定服务范围冲突，可能加大服务技术难度，增加投入成本。
|
|
|
|
（6）由于资源不够或项目成员承担项目过多，在项目计划中所计划的资源得不到保证，项目任务无法按时、按质完成。
|
|
|
|
（7）项目团队成员职责分工不明确，导致项目在执行过程中接口混乱、工作量加大、沟通和管理成本成倍增加、项目任务出现盲区。
|
|
|
|
（8）系统规划与管理师在某些具体管理操作层面失误，导致项目在执行过程中服务团队不稳定，个体成员工作量加大，身心疲惫，出现抱怨，不能愉快地投入工作，进度滞后，项目任务出现脱节，项目实施不规范，项目质量出现问题。
|
|
|
|
（9）项目组内部沟通不力，造成项目问题积压，导致项目后期出现更大的问题。
|
|
|
|
（10）第三方供应商交付了不符合要求的产品，使得项目无法正常执行。
|
|
|
|
（11）服务目标、测量手段、服务能力与成熟度。部署实施执行阶段的常见风险是定义了量化的服务目标，但缺乏获取它的切实可行的测量手段，或者服务能力不能够支撑达成此目标，或者服务目标的设定超越了目前的服务运营团队的成熟度。上述情况都会对客户满意度造成潜在的影响。因此，在部署实施执行期间，要实际获取和测量已定义的服务目标。对于无法测量的目标要及时修订；对于可测量但与预期差距太大的目标，或者与服务能力不对称的目标，也要及时与项目干系人沟通，并及时调整。
|
|
|
|
（12）配置管理的广度与颗粒度。部署实施执行阶段的另一个风险在于配置管理。一方面，对于不属于自身管理范围的各项目不应纳入配置管理的范围，否则会对未来的服务运营工作产生很大的影响，严重影响工作效率。另一方面，对于自身管理范围内的各配置项，也要依据自身的服务能力来设置其颗粒度。例如，对于计算机的内存，可以定义为计算配置项的一个属性，也可以定义为一个单独的内存配置项。服务团队的资源或能力不足以支持到这么细的颗粒度管理，这样的配置管理数据库的设计，可能导致服务运营团队需要单独配置一名工程师来专门负责配置管理数据库的日常管理与维护，这样会得不偿失。因此，一定要依据服务运营团队的服务能力来设定配置管理的广度和颗粒度。
|
|
|
|
|
|
|
|
|
|
|
|
IT服务部署实施过程检查表实例如上表所示。通过服务质量看板，可以清晰识别出哪些服务在什么时间段内未达到部署实施目标（或服务质量要求），以及目标达成情况的发展趋势，有助于在部署实施阶段及早发现问题并及时纠正，如下表所示。
|
|
|
|
|
|
|
