20150720    淡然

续上

4、报价说明

本方案的报价说明请参见“”

2. 业务及系统需求

本节描述对ITSM项目第一期的具体业务及系统需求，供应商应仔细研究本需求部分，提出相应符合要求的系统解决方案。


2.1 业务需求

                希望通过分阶段分步骤，循序渐进的方法实施IT服务管理项目，以ITIL的理念为指导，规范和量化IT的各项服务管理，全面地提高IT服务管理水平，同时满足ISO20000审计和相关监管要求。

                本期项目的业务目标主要包含三方面：

运维流程方面，在进行管理体系规划和服务级别定义，并对事件和服务请求流程、服务台职能、问题管理流程、变更管理流程、配置管理流程流程进行评估和差距分析，提出对应的改进意见和设计方案；

人员方面要保证对运维人员和运维经理进行ISO20000和ITIL不同方面的全面培训和宣导，保证IT流程和各职能有专职的专业的ITIL服务人员，统一服务台并建立虚拟服务台；

工具方面，将流程设计固化到电子平台，通过与ITSM平台进行对接，实现对服务的生命周期进行控制，和对运维服务的监控，回顾，趋势分析等。

2.1.1运维管理体系规划

IT服务体系包括组织规划、制度体系、服务承诺、服务目录、运维人员职责和岗位定义、运维流程和对应的运维手册，整个IT服务体系的每个服务流程的梳理和咨询服务。应包括如下内容：

• ITIL及ISO20000基础知识普及教育
• IT服务管理体系现状调研和评估
• IT服务管理体系最佳实践的讨论
• IT服务管理体系规划设计
• 服务承诺与服务目录
• 管理活动
• 角色和职责
• KPI设计
• 管理报表
• 流程培训
• 演进路线规划
  

2.1.2服务级别管理

服务级别管理是对IT服务的供应进行谈判、定义、评价、管理以及以可接受的成本改进IT服务的质量的流程。所有这些活动要求在一个业务需求和技术都在快速变化的环境中进行。服务级别管理试图在服务质量的供应与需求、客户关系和IT服务成本之间找到某个合适的平衡点。对于服务提供商和客户来说，认识到服务是一个供应和接收的过程这一点是很重要的。服务级别管理包括对下列文本的设计、协商和维护

服务级别管理的主要目标在于，根据业务部门的需求和相关的成本预算，制定恰当的服务级别目标，并将其以服务级别协议的形式确定下来。在服务级别协议中确定的服务级别目标，既是IT服务部门监控和评价实际服务品质的标准，也是协调IT服务部门和业务部门之间有关争议的基本依据。

主要的服务级别管理流程的梳理和咨询活动和内容包括：

·         确定、协商、记录和约定SLR中针对全新或变更的服务的要求，并将其作为针对运营服务的SLA的一部分，在服务生命周期中对其进行管理和审查

·         基于SLA中的目标监视衡量所有运营服务的服务性能                                                  ITSS培训

·         比较、衡量和改进客户满意度

·         生成服务报告

·         开展服务审查，促进整个服务改进计划(SIP)中改进工作的进行

·         审查和修改SLA、服务范围OLA、合同、以及任意其它支撑合同

·         与业务部门、客户和厉害干系人确定并记录合同和关系

·         制定、维护和执行程序来记录、采取行动和解决所有投诉，以及记录和转发赞扬

·         记录和管理所有投诉与赞扬

·         提供适用的管理信息来协助性能管理和展示服务成就

·         提供并保持最新的SLM文档模板与标准。

2.1.3服务台设计和工具实施

                针对目前IT的服务台现状，进行结构化的且机制合理的建议，并在服务合同期间参与服务台的持续优化，以便使服务台能为所有内部用户和IT基础架构管理提供高效率的、高质量的日常运维服务支持。

               服务台职能设计的需求包括：

• 研究并对服务台的机构设置提供优化建议；
• 定义和明确服务台与其他IT团队（包括第三方）的协作模式；
• 提供与用户进行沟通、信息发布和通告的单一窗口；
• 确定先进的、高效的服务台技术平台和接入模式，建立统一服务台，持续培训ITIL专职服务人员，保证服务台活动的畅通和自我改进；
• 实现事件或服务请求的记录、分派、监督通知、解决方案记录、报表统计等过程电子化、自动化，降低人工操作和管理带来的风险；
• 建立并实现IT和客户关系管理的优化和改善机制，确保长期的为用户提供高水平的服务质量，提升用户的信任度和满意度。
  

服务台工具的主要功能应包括：

• 用户服务呼叫/故障报警响应，用户可通过热线电话发出服务呼叫/故障报警，也可以通过登陆系统自助登记，并能查看处理过程和进度；
• 服务请求可以预先定义分配规则，由系统自动分配给处理角色；
• 具备管理权限的人员可随时查看服务请求的执行过程，并可以干预流程，将服务请求重新分配；
• 对于服务请求，可以根据IT部门管理层要求，由管理员自行设计服务请求的：类别、影响度、用户类别等等管理内容，并按照要求设计表单，满足管理需求，同时也方便对请求的统计、分类等工作；
• 对于每个服务请求能够详细记录处理过程；
• 每个服务请求可以和相关解决方案、相关配置等内容关联；
• 记录所有相关的故障和服务请求，分配类别和优先级代码；
• 提供一线阀查和诊断，解决他们能够解决的那些故障或服务请求；
• 升级他们在约定的时间内不能解决的故障或服务请求；
• 使用户随时了解进度；
• 结束所有解决的故障、请求和其它呼叫；
• 按协议进行客户／用户满意度圜呼或调查与用户沟通，使他们了解故障的进度，通知他们即将发生的变更或约定的中断等；
• 经过协议确认，按配置管理的指示及批复来更新配置管理系统。
  

2.1.4事件管理流程设计及工具实施

                事件管理流程涵盖的范围和动作包括记录、分类、调查/诊断、解决已知问题、监控跟踪事件、与用户和问题管理流程交流、最终解决事件。根据提交方式的不同，支持WEB、Email、电话和其它管理软件自动发送等方式。已经有一套事件管理流程，但由于缺乏标准和规范，导致事件解决过程无法形成有效的闭环控制。

                为实现快速解决事件，使其对的各项业务的影响最小化，确保IT给用户提供高质量的系统服务和系统的高可用性，提出以下需求：

• 建立完善的事件管理的流程，明确流程活动、管理机制和相关责任人；
• 依据事件的紧急程度和影响范围等，为事件进行科学、准确的分类、分级，保证不同级别的事件所获得的资源足够；
• 明确流程运行原则，包括责任人原则、事件升级原则等；
• 明确KPI考核的指标，设定关键KPI，通过报表等手段来反映事件管理流程的运行情况；
• 与本期其它流程有机的集成；
• 为服务台人员建立标准的事件接收问询机制，以确保任何事件在第一时间能够快速、准确、清晰的收集到足够的信息，为其高效率的解决得到第一手资料；
• 制定合理的人员角色和职责及考核机制，不同角色能够根据自己的权限看到自己应处理的故障单，并且根据角色的不同所看到的表现形式也是不同的；
• 制定事件模板，通过模板功能的使用对常见事件进行定义，实现标准化描述；
• 建立事件审计机制和功能。能够对数据变化前后的修改人、时间进行记录，保证数据的安全性。
• 
  

2.1.5服务请求设计及工具实施


服务请求是用户对IT部门施加的各种不同类型要求的一般描述。其中许多实际是小的变更，具有低风险、频繁发生、低成本等的特征。例如请求更改密码、请求在特定工作站上安装额外软件应用，以及请求分配一些桌面设备项；或者可能只是问题请求信息。但此类请求的规模和频率、低风险特性意味着，通过单独流程而非阻塞和妨碍正常的故障与变更管理流程，能够使它们得到更好地处理。

服务请求的宗旨是：

• 为用户请求卸接受标准服务提供一个渠道，针对这些服务制定预定义的审批和资格鉴定流程。
  

• 向用户和客户提供有关服务可用性和服务获取程序的信息；                                  ITSS认证
• 收集和提供所请求的标准服务的组件（例如授权和软件介质）；
• 帮助处理一般信息、投诉或意见。
• 
  

2.1.6问题管理流程设计和工具实施

                根据ITIL标准，问题管理的核心是建立一个稳定的系统服务环境，减少报告给帮助台的故障数量。主要包括三方面的工作，一是确认问题，从大量的故障报告中找出问题。二是找到导致问题的根源并解决。三是为解决某个问题，可能需要向变更管理经理提出变更请求。

相对于事件管理，问题管理是比较主动性的管理流程，一方面可作为事件管理的后台支持，针对重大或紧急事件提供解决方案，另方面，该流程通过发现重复发生的事件或趋势分析等手段，确立问题，然后确定事件发生的根本原因，并找出解决方案以消除事件根本原因，从而杜绝事件的再次发生或大大降低事件重复发生的频度，同时通过知识积累，问题管理也可以帮助事件管理人员提高事件解决的效能和效率。主要的问题管理流程的梳理和咨询活动包括：

• 问题创建
• 分类和优先级设定
• 问题处理
• 问题关闭
• 事后回顾
  

本期项目的实施重点是的问题流程，并对问题进行分类和分布，以达到减小事件和问题对业务的负面影响, 及时发现问题引起的根本原因，同时提供和实施解决问题的长期方案, 防止由相同错误引发的事件再次发生，提高IT服务管理水平。

             问题管理的需求主要包括：

• 建立完善的问题管理流程，明确流程活动、管理机制和相关责任人；
• 明确流程运行原则，包括责任人原则、升级原则等；
• 明确KPI考核的指标，制定合理的人员角色和职责及考核机制，通过报表等手段来反映问题管理流程的运行情况；
• 与本期其它流程有机的集成；
• 对问题进行科学的分类及优先级排序；
• 设立KPI，利用开发系统报表等手段对流程的执行提供统计，分析和监控；
• 建立问题审计机制和功能。能够对数据变化前后的修改人、时间进行记录，保证数据的安全性。
  

2.1.7变更管理流程设计和工具实施

                变更管理是对问题管理环节发现的问题，对于系统正常维护需要修改的配置等环节进行控制，主要目的是：协调各类变更过程、记录变更详细历史、通过IT资产评估变更影响范围。变更管理的首要任务是降低与变更相关的风险，从而降低由于变更导致服务故障的可能性。

本期项目要求通过对目前的组织架构进行调研和分析，并参考ITIL标准，提出切实可行的改进意见和变更流程设计建议，为设计统一、全面的变更管理流程，从而使受控的方式管理影响生产系统的所有变更进行的评估、批准、实施和回顾工作。

                变更管理部分的需求主要包括：

• 建立完善的变更管理流程，明确流程活动、管理机制和相关责任人，定义变更管理过程中的角色和职责，包括但不限于请求者、变更经理、变更协调者等；
• 明确流程运行原则，包括但不限于责任人原则、风险评估原则、审批机制等；
• 明确KPI考核的指标，制定合理的人员角色和职责及考核机制；
• 与本期其它流程有机的集成；
• 设计并协助建立包括业务部门和运维部门的变更顾问委员会（CAB）及其子集-紧急变更委员会（ECAB）。
  

设计变更流程时，应包含或管理以下内容：

• 定义和记录IT服务和基础架构的变更；
• 由变更委员会负责对重大变更的评估、批准、资源准备和审核工作；
• 评估变更请求的风险和对技术及业务的影响，进行分类和分级管理。例如风险包括：可用性风险、技术风险、人力成本等，并分类记录。例如变更分级包括：紧急、重大、标准、简单等；
• 制订变更实施方案，应包括变更失败计划以及采取的取消或补救措施；
• 在检查和批准变更后，以受控的方式实施变更过程。对所有变更执行结果及其实施之后所采取的行动进行评审；
• 制订控制紧急变更的授权和实施紧急变更的流程；
• 维护当前的变更计划并按计划通报相关方；
• 对变更记录进行定期分析，以分析逐渐增长的变更级别、频繁重现的类型的趋势和其他相关信息；
• 对从变更分析中所得的结果和结论进行记录。有效识别变更管理的改进方案，并将其纳入服务管理改进计划。
• 
  

2.1.8配置管理流程设计和工具实施

为实现对IT软硬件及相关文档的服务支持和服务交付，需通过配置管理来控制处于持续变化状态中的IT基础架构，鉴别配置项目，收集和管理有关IT架构的文档，为所有其它流程提供IT架构的相关信息。

配置管理设计有如下要求：

• 确定流程责任人；
• 明确管理范围，包括管理宽度与深度；
• 确定配置分类及各配置项属性；
• 确定配置项关系；
• 建立CMDB模型；
• 定义配置管理原则，包括配置项更新原则、CMDB审计原则。
  

配置管理的实施内容包括：

• 配置管理的目标定义；
• 配置管理数据库的范围和深度定义；
• 配置管理项的关系定义；
• 配置管理流程的设计和梳理；
• 配置管理数据的搜集模板、搜集方式的定义；
• 配置信息的搜集、确认和入库。
• 
  

2.1.9配合可能的在ITSM平台上的其他开发项目、任务

                在服务合同期间，应积极配合可能的在ITSM系统平台上的其他开发项目任务，主要包括：

• 识别潜在管理风险，设计并落实风险控制手段，如版本控制、沟通记录等；
• 任何ITSM平台及接口发生故障，无论是否涉及第三方所开发功能、模块，无条件提供故障定位服务，并提出解决方案的建议；
• 在授权下，参加相关项目的终审工作。
  

2.2 系统需求

本节描述对项目一期的具体系统需求，供应商应仔细研究本需求部分，提出相应符合要求的系统解决方案。

2.2.1完整性

完整的方案包括数据整合，数据组织与存储，数据访问，公共基础服务等方面。要求数据整合过程能在统一的平台上进行，数据组织与存储要求结构完整，平台统一，数据访问应有统一的界面。公共基础服务具有一致的接口。

2.2.2扩展性

要求系统必须具有良好的可扩展性。可扩展的平台必须能够随着最终用户、数据、复杂性和功能性的增长而增长；在增长的同时还必须能维持现有的性能水平。开放相关的输入、输出API接口；采用开放标准的协议和规范进行集成；同其它系统的集成不能破坏其原有界面及数据存储的统一性和一致性

2.2.3安全性

系统的数据是企业的商业秘密，必须保证数据安全。系统定位于管理层面，并保证系统使用人员和管理人员的权限有效安全的管理。

2.2.4合规性

对所有核心操作应设计审计跟踪

2.2.5兼容性

工具平台需和ITIL设计有良好的兼容性，在相对独立的功能模块上实现前面的流程功能，并能提供ITIL最佳实践模块

2.2.6易管理性

容易实施、易客户化及方便管理

2.3 认证需求

ISO20000关注的是管理体系，强调“What”－企业要做什么；ITIL更关注流程，强调“How”－如何做。V3的更新，主要是在“How”的方面提高了系统性、指导性，对“What”－IT服务管理体系并未形成大的影响。

因此，ISO 20000-1:2005相对于传统的IT管理，更加强调需求及其实现，并将IT服务的预算和核算引入IT服务管理，将财务管理和服务管理有机的结合起来，促进IT服务的改进和提高。

希望通过本项目，助力通过ISO20000认证。通过引入先进的行业服务标杆和最佳实践，提升运维服务水平，进而使得业务在国内同行业树立标杆，为未来的市场竞争奠定基石。                      ITSS考试

待续：http://www.ITILxf.com/thread-51779-1-1.html

本帖关键字：ITSS

20150720    淡然

续上

4、报价说明

本方案的报价说明请参见“”

2. 业务及系统需求

本节描述对ITSM项目第一期的具体业务及系统需求，供应商应仔细研究本需求部分，提出相应符合要求的系统解决方案。


2.1 业务需求

                希望通过分阶段分步骤，循序渐进的方法实施IT服务管理项目，以ITIL的理念为指导，规范和量化IT的各项服务管理，全面地提高IT服务管理水平，同时满足ISO20000审计和相关监管要求。

                本期项目的业务目标主要包含三方面：

运维流程方面，在进行管理体系规划和服务级别定义，并对事件和服务请求流程、服务台职能、问题管理流程、变更管理流程、配置管理流程流程进行评估和差距分析，提出对应的改进意见和设计方案；

人员方面要保证对运维人员和运维经理进行ISO20000和ITIL不同方面的全面培训和宣导，保证IT流程和各职能有专职的专业的ITIL服务人员，统一服务台并建立虚拟服务台；

工具方面，将流程设计固化到电子平台，通过与ITSM平台进行对接，实现对服务的生命周期进行控制，和对运维服务的监控，回顾，趋势分析等。

2.1.1运维管理体系规划

IT服务体系包括组织规划、制度体系、服务承诺、服务目录、运维人员职责和岗位定义、运维流程和对应的运维手册，整个IT服务体系的每个服务流程的梳理和咨询服务。应包括如下内容：

• ITIL及ISO20000基础知识普及教育
• IT服务管理体系现状调研和评估
• IT服务管理体系最佳实践的讨论
• IT服务管理体系规划设计
• 服务承诺与服务目录
• 管理活动
• 角色和职责
• KPI设计
• 管理报表
• 流程培训
• 演进路线规划
  

2.1.2服务级别管理

服务级别管理是对IT服务的供应进行谈判、定义、评价、管理以及以可接受的成本改进IT服务的质量的流程。所有这些活动要求在一个业务需求和技术都在快速变化的环境中进行。服务级别管理试图在服务质量的供应与需求、客户关系和IT服务成本之间找到某个合适的平衡点。对于服务提供商和客户来说，认识到服务是一个供应和接收的过程这一点是很重要的。服务级别管理包括对下列文本的设计、协商和维护

服务级别管理的主要目标在于，根据业务部门的需求和相关的成本预算，制定恰当的服务级别目标，并将其以服务级别协议的形式确定下来。在服务级别协议中确定的服务级别目标，既是IT服务部门监控和评价实际服务品质的标准，也是协调IT服务部门和业务部门之间有关争议的基本依据。

主要的服务级别管理流程的梳理和咨询活动和内容包括：

·         确定、协商、记录和约定SLR中针对全新或变更的服务的要求，并将其作为针对运营服务的SLA的一部分，在服务生命周期中对其进行管理和审查

·         基于SLA中的目标监视衡量所有运营服务的服务性能                                                  ITSS培训

·         比较、衡量和改进客户满意度

·         生成服务报告

·         开展服务审查，促进整个服务改进计划(SIP)中改进工作的进行

·         审查和修改SLA、服务范围OLA、合同、以及任意其它支撑合同

·         与业务部门、客户和厉害干系人确定并记录合同和关系

·         制定、维护和执行程序来记录、采取行动和解决所有投诉，以及记录和转发赞扬

·         记录和管理所有投诉与赞扬

·         提供适用的管理信息来协助性能管理和展示服务成就

·         提供并保持最新的SLM文档模板与标准。

2.1.3服务台设计和工具实施

                针对目前IT的服务台现状，进行结构化的且机制合理的建议，并在服务合同期间参与服务台的持续优化，以便使服务台能为所有内部用户和IT基础架构管理提供高效率的、高质量的日常运维服务支持。

               服务台职能设计的需求包括：

• 研究并对服务台的机构设置提供优化建议；
• 定义和明确服务台与其他IT团队（包括第三方）的协作模式；
• 提供与用户进行沟通、信息发布和通告的单一窗口；
• 确定先进的、高效的服务台技术平台和接入模式，建立统一服务台，持续培训ITIL专职服务人员，保证服务台活动的畅通和自我改进；
• 实现事件或服务请求的记录、分派、监督通知、解决方案记录、报表统计等过程电子化、自动化，降低人工操作和管理带来的风险；
• 建立并实现IT和客户关系管理的优化和改善机制，确保长期的为用户提供高水平的服务质量，提升用户的信任度和满意度。
  

服务台工具的主要功能应包括：

• 用户服务呼叫/故障报警响应，用户可通过热线电话发出服务呼叫/故障报警，也可以通过登陆系统自助登记，并能查看处理过程和进度；
• 服务请求可以预先定义分配规则，由系统自动分配给处理角色；
• 具备管理权限的人员可随时查看服务请求的执行过程，并可以干预流程，将服务请求重新分配；
• 对于服务请求，可以根据IT部门管理层要求，由管理员自行设计服务请求的：类别、影响度、用户类别等等管理内容，并按照要求设计表单，满足管理需求，同时也方便对请求的统计、分类等工作；
• 对于每个服务请求能够详细记录处理过程；
• 每个服务请求可以和相关解决方案、相关配置等内容关联；
• 记录所有相关的故障和服务请求，分配类别和优先级代码；
• 提供一线阀查和诊断，解决他们能够解决的那些故障或服务请求；
• 升级他们在约定的时间内不能解决的故障或服务请求；
• 使用户随时了解进度；
• 结束所有解决的故障、请求和其它呼叫；
• 按协议进行客户／用户满意度圜呼或调查与用户沟通，使他们了解故障的进度，通知他们即将发生的变更或约定的中断等；
• 经过协议确认，按配置管理的指示及批复来更新配置管理系统。
  

2.1.4事件管理流程设计及工具实施

                事件管理流程涵盖的范围和动作包括记录、分类、调查/诊断、解决已知问题、监控跟踪事件、与用户和问题管理流程交流、最终解决事件。根据提交方式的不同，支持WEB、Email、电话和其它管理软件自动发送等方式。已经有一套事件管理流程，但由于缺乏标准和规范，导致事件解决过程无法形成有效的闭环控制。

                为实现快速解决事件，使其对的各项业务的影响最小化，确保IT给用户提供高质量的系统服务和系统的高可用性，提出以下需求：

• 建立完善的事件管理的流程，明确流程活动、管理机制和相关责任人；
• 依据事件的紧急程度和影响范围等，为事件进行科学、准确的分类、分级，保证不同级别的事件所获得的资源足够；
• 明确流程运行原则，包括责任人原则、事件升级原则等；
• 明确KPI考核的指标，设定关键KPI，通过报表等手段来反映事件管理流程的运行情况；
• 与本期其它流程有机的集成；
• 为服务台人员建立标准的事件接收问询机制，以确保任何事件在第一时间能够快速、准确、清晰的收集到足够的信息，为其高效率的解决得到第一手资料；
• 制定合理的人员角色和职责及考核机制，不同角色能够根据自己的权限看到自己应处理的故障单，并且根据角色的不同所看到的表现形式也是不同的；
• 制定事件模板，通过模板功能的使用对常见事件进行定义，实现标准化描述；
• 建立事件审计机制和功能。能够对数据变化前后的修改人、时间进行记录，保证数据的安全性。
• 
  

2.1.5服务请求设计及工具实施


服务请求是用户对IT部门施加的各种不同类型要求的一般描述。其中许多实际是小的变更，具有低风险、频繁发生、低成本等的特征。例如请求更改密码、请求在特定工作站上安装额外软件应用，以及请求分配一些桌面设备项；或者可能只是问题请求信息。但此类请求的规模和频率、低风险特性意味着，通过单独流程而非阻塞和妨碍正常的故障与变更管理流程，能够使它们得到更好地处理。

服务请求的宗旨是：

• 为用户请求卸接受标准服务提供一个渠道，针对这些服务制定预定义的审批和资格鉴定流程。
  

• 向用户和客户提供有关服务可用性和服务获取程序的信息；                                  ITSS认证
• 收集和提供所请求的标准服务的组件（例如授权和软件介质）；
• 帮助处理一般信息、投诉或意见。
• 
  

2.1.6问题管理流程设计和工具实施

                根据ITIL标准，问题管理的核心是建立一个稳定的系统服务环境，减少报告给帮助台的故障数量。主要包括三方面的工作，一是确认问题，从大量的故障报告中找出问题。二是找到导致问题的根源并解决。三是为解决某个问题，可能需要向变更管理经理提出变更请求。

相对于事件管理，问题管理是比较主动性的管理流程，一方面可作为事件管理的后台支持，针对重大或紧急事件提供解决方案，另方面，该流程通过发现重复发生的事件或趋势分析等手段，确立问题，然后确定事件发生的根本原因，并找出解决方案以消除事件根本原因，从而杜绝事件的再次发生或大大降低事件重复发生的频度，同时通过知识积累，问题管理也可以帮助事件管理人员提高事件解决的效能和效率。主要的问题管理流程的梳理和咨询活动包括：

• 问题创建
• 分类和优先级设定
• 问题处理
• 问题关闭
• 事后回顾
  

本期项目的实施重点是的问题流程，并对问题进行分类和分布，以达到减小事件和问题对业务的负面影响, 及时发现问题引起的根本原因，同时提供和实施解决问题的长期方案, 防止由相同错误引发的事件再次发生，提高IT服务管理水平。

             问题管理的需求主要包括：

• 建立完善的问题管理流程，明确流程活动、管理机制和相关责任人；
• 明确流程运行原则，包括责任人原则、升级原则等；
• 明确KPI考核的指标，制定合理的人员角色和职责及考核机制，通过报表等手段来反映问题管理流程的运行情况；
• 与本期其它流程有机的集成；
• 对问题进行科学的分类及优先级排序；
• 设立KPI，利用开发系统报表等手段对流程的执行提供统计，分析和监控；
• 建立问题审计机制和功能。能够对数据变化前后的修改人、时间进行记录，保证数据的安全性。
  

2.1.7变更管理流程设计和工具实施

                变更管理是对问题管理环节发现的问题，对于系统正常维护需要修改的配置等环节进行控制，主要目的是：协调各类变更过程、记录变更详细历史、通过IT资产评估变更影响范围。变更管理的首要任务是降低与变更相关的风险，从而降低由于变更导致服务故障的可能性。

本期项目要求通过对目前的组织架构进行调研和分析，并参考ITIL标准，提出切实可行的改进意见和变更流程设计建议，为设计统一、全面的变更管理流程，从而使受控的方式管理影响生产系统的所有变更进行的评估、批准、实施和回顾工作。

                变更管理部分的需求主要包括：

• 建立完善的变更管理流程，明确流程活动、管理机制和相关责任人，定义变更管理过程中的角色和职责，包括但不限于请求者、变更经理、变更协调者等；
• 明确流程运行原则，包括但不限于责任人原则、风险评估原则、审批机制等；
• 明确KPI考核的指标，制定合理的人员角色和职责及考核机制；
• 与本期其它流程有机的集成；
• 设计并协助建立包括业务部门和运维部门的变更顾问委员会（CAB）及其子集-紧急变更委员会（ECAB）。
  

设计变更流程时，应包含或管理以下内容：

• 定义和记录IT服务和基础架构的变更；
• 由变更委员会负责对重大变更的评估、批准、资源准备和审核工作；
• 评估变更请求的风险和对技术及业务的影响，进行分类和分级管理。例如风险包括：可用性风险、技术风险、人力成本等，并分类记录。例如变更分级包括：紧急、重大、标准、简单等；
• 制订变更实施方案，应包括变更失败计划以及采取的取消或补救措施；
• 在检查和批准变更后，以受控的方式实施变更过程。对所有变更执行结果及其实施之后所采取的行动进行评审；
• 制订控制紧急变更的授权和实施紧急变更的流程；
• 维护当前的变更计划并按计划通报相关方；
• 对变更记录进行定期分析，以分析逐渐增长的变更级别、频繁重现的类型的趋势和其他相关信息；
• 对从变更分析中所得的结果和结论进行记录。有效识别变更管理的改进方案，并将其纳入服务管理改进计划。
• 
  

2.1.8配置管理流程设计和工具实施

为实现对IT软硬件及相关文档的服务支持和服务交付，需通过配置管理来控制处于持续变化状态中的IT基础架构，鉴别配置项目，收集和管理有关IT架构的文档，为所有其它流程提供IT架构的相关信息。

配置管理设计有如下要求：

• 确定流程责任人；
• 明确管理范围，包括管理宽度与深度；
• 确定配置分类及各配置项属性；
• 确定配置项关系；
• 建立CMDB模型；
• 定义配置管理原则，包括配置项更新原则、CMDB审计原则。
  

配置管理的实施内容包括：

• 配置管理的目标定义；
• 配置管理数据库的范围和深度定义；
• 配置管理项的关系定义；
• 配置管理流程的设计和梳理；
• 配置管理数据的搜集模板、搜集方式的定义；
• 配置信息的搜集、确认和入库。
• 
  

2.1.9配合可能的在ITSM平台上的其他开发项目、任务

                在服务合同期间，应积极配合可能的在ITSM系统平台上的其他开发项目任务，主要包括：

• 识别潜在管理风险，设计并落实风险控制手段，如版本控制、沟通记录等；
• 任何ITSM平台及接口发生故障，无论是否涉及第三方所开发功能、模块，无条件提供故障定位服务，并提出解决方案的建议；
• 在授权下，参加相关项目的终审工作。
  

2.2 系统需求

本节描述对项目一期的具体系统需求，供应商应仔细研究本需求部分，提出相应符合要求的系统解决方案。

2.2.1完整性

完整的方案包括数据整合，数据组织与存储，数据访问，公共基础服务等方面。要求数据整合过程能在统一的平台上进行，数据组织与存储要求结构完整，平台统一，数据访问应有统一的界面。公共基础服务具有一致的接口。

2.2.2扩展性

要求系统必须具有良好的可扩展性。可扩展的平台必须能够随着最终用户、数据、复杂性和功能性的增长而增长；在增长的同时还必须能维持现有的性能水平。开放相关的输入、输出API接口；采用开放标准的协议和规范进行集成；同其它系统的集成不能破坏其原有界面及数据存储的统一性和一致性

2.2.3安全性

系统的数据是企业的商业秘密，必须保证数据安全。系统定位于管理层面，并保证系统使用人员和管理人员的权限有效安全的管理。

2.2.4合规性

对所有核心操作应设计审计跟踪

2.2.5兼容性

工具平台需和ITIL设计有良好的兼容性，在相对独立的功能模块上实现前面的流程功能，并能提供ITIL最佳实践模块

2.2.6易管理性

容易实施、易客户化及方便管理

2.3 认证需求

ISO20000关注的是管理体系，强调“What”－企业要做什么；ITIL更关注流程，强调“How”－如何做。V3的更新，主要是在“How”的方面提高了系统性、指导性，对“What”－IT服务管理体系并未形成大的影响。

因此，ISO 20000-1:2005相对于传统的IT管理，更加强调需求及其实现，并将IT服务的预算和核算引入IT服务管理，将财务管理和服务管理有机的结合起来，促进IT服务的改进和提高。

希望通过本项目，助力通过ISO20000认证。通过引入先进的行业服务标杆和最佳实践，提升运维服务水平，进而使得业务在国内同行业树立标杆，为未来的市场竞争奠定基石。                      ITSS考试

待续：http://www.ITILxf.com/thread-51779-1-1.html

本帖关键字：ITSS