ISO20000体系的建立和实施方案

network

ISO20000体系的建立和实施方案(2009-11-22 14:09:11)


一、开展培训，职能分工

1.   培训：

A.  全员ISO20000基础知识培训。

a)  培训目的 ：

1)     了解ISO20000标准的内容；

2)     了解ISO20000标准的基本要求；

3)     了解ISO20000标准的实施办法；

4)     了解企业推行ISO20000意义和计划。

b)  学习内容：

1)     什麽是ISO20000标准；

2)     对标准的理解；

3)     本公司推行ISO20000意义；

4)     本公司推行ISO20000的计划和要求。

c)  参加人员和学习时间：

1)     叁加人员：全体人员

2)     学习时间：

B.  骨干培训

a)  培训目的

1)     了解ISO20000标准的基本内容；

2)     领导在体系中的作用；

3)     了解爲什麽要推行ISO20000；

4)     要了解如何推行ISO20000。

b)  学习内容

1)     ISO20000标准的结构、原理和内容概述；

2)     重要的质量概念；

3)     实施标准的指导思想；

4)     领导在体系中的作用；

5)     IT服务管理体系认证、维护和改进的过程。

c)  叁加人员和学习时间

1)     叁加人员：公司总经理、副总经理、各有关部门经理和主管。

2)     学习时间：

C.  文件编写技能培训

a)  培训目的

1)     掌握文件编写方法；

2)     结合本公司实际如何编制有关文件。

b)  学习内容

1)     IT服务管理体系文件总论；

2)     IT服务质量管理手册编写；

3)     程式文件编写；

4)     工作文件编写；

5)     管理计划制定；

6)     管理记录。

c)  叁加人员和学习时间

叁加人员：企业各有关部门领导、ISO20000工作小组内的成员，专职质量管理人员。

学习时间：

2.   建立组织：

A.  领导小组 ISO20000委员会

推行ISO20000，领导是关键，企业领导应作正确决策，并积极地带头叁加这项工作。

1)     带头学习ISO20000基础知识；

2)     积极推动公司工作；

3)     给出人力和物力支援；

4)     成立领导小组，主要领导都应当叁与；

5)     任命管理代表，负责标准中规定的职责；

6)     及时处理有关重大问题；

7)     组织管理评审。

B.  工作机构

为了推行ISO20000，公司应成立专门工作机构，负责全公司推行ISO20000组织协调工作，作爲一个办事核心。应保证：

1)     所有各有关部门都能叁与工作小组；

2)     有专职人员；

3)     有骨干力量。骨干人员应对ISO20000有较全面系统的学习，最好有一定相关工作经历。

C.  管理者代表

公司应按标准要求任命管理者代表。

1)     管理者代表应由最高管理者指定；

2)     管理者代表应是公司管理层成员；

3)     管理者代表应具有如下职责：

l   确保按照标准规定建立、实施和维持IT服务管理体系要求；

l   向管理者报告体系的执行情况，以便评审和改进管理体系；

l   管理者代表的职责还可以包括就IT服务质量管理体系方面与外部机构的联络。

3.   系统调查 诊断

A.  诊断的目的

通过诊断，达到以下目的：

a)   现有体系与标准的符合性：

1)     找出与标准之间差距；

2)     找出形成这些差距原因。

b)  选择合适的IT服务质量管理体系标准及其补充要求：

根据公司运作需要、合同要求、産品特点从ISO9000或其他标准中选择适合於企业的质量管理体系标准；.在(1)的基础上对选定标准进行必要的增删，提出对IT服务质量管理体系补充要求。

c)   识别确定对服务质量管理体系进行修改的内容：

1)     体系标准和要素选择；

2)     机构调整内容；

3)     体系文件清单；

4)     需新编制的文件（清单）。

B.  诊断的依据

诊断工作一般应按某一合适的IT服务质量体系标准、主要合同和本单位一些基本法规。根据各单位具体情况，诊断的依据可以归纳成如下几个方面：

a)  质量体系标准：

例如ISO9000标准

诊断所选择的标准与申请认证的标准应是同一类型的。

b)  合同：

IT服务质量体系应能基本满足各客户的要求，因此，合同应是论断的一个重要依据。

c)  本单位的基本规定、规程：

如有关标准化方面的、有关监控方面的、有安全方面的等等，这些规定、规程是否合理及合理的内容是否被有效运行，诊断时要检查的内容。

d)  社会或行业有关法规

IT服务质量管理体系不仅要满足质量体系标准、合同和公司有关规定，还应该符合国家、地区、行业有关法律、法规、规章制度的要求，诊断时应作爲考虑。

1)     有关安全法规；

2)     有关服务法规；

3)     有关环保法规；

4)     有关劳动法规。

C.  实施诊断的人员

实施诊断员可以是公司内部的人员，也可以公司委托的外部机构，如谘询机构的人员，因此实施诊断的人员可以有如下几方面：

a)   谘询人员：

如果公司聘请了谘询人员，诊断工作可以其爲主进行。爲此谘询机构可以委派专门诊断、检查工作组，制订计划，在企业确认的基础上按计划进行诊断。

b)  内部审核员：

如果公司有经培训合格并胜任该项工作的人员，可以授权其进行诊断工作。

c)   第三方审核机构的人员：

如果公司有需要，可以聘请外部审核机构的审核员爲公司进行诊断。

D.  诊断工作的实施过程

a)  确定诊断小组。

b)  确定诊断依据和诊断物件。

c)   制订诊断计划，编制诊断工作文件。

d)  现场诊断检查

1)     与现场人员交谈，了解情况；

2)     检查现场文件和记录；

3)     如实记录体系运行现状。

e)  提交诊断报告

1)     不合格报告；

2)     诊断结论；

3)     体系文件清单；

4)     需新编制和修订的文件（清单）。

4.   职能分工 体系设计

A.  制订IT服务质量管理方针；

B.  任命管理者代表主要责任：

a)  协助管理者确保按标准的要求建立IT服务质量管理体系。

b)  负责体系的实施和维护。

c)   负责组织内部管理体系审核，向最高管理者报告体系执行情况，以便评审和改进。

d)  就IT服务质量管理体系方面问题与外部联系。

C.  选择体系标准和要素

质量体系要素选择

1)     根据合同要求，可删去所选择标准中包含的某些服务质量管理体系要素或分要素，还可以涉及体系要素证实程度的调整；

2)     按合同要求，规定对质量体系的补充要求，例如统计程式控制要求、安全性要求等。

D.  设计调整组织机构

a.各部门职责应覆盖标准要求。

b.各部门有清楚的职责。

c.各部门工作之间有合理的衔接。

d.职能分工形成书面文件，并经充分讨论。

e.应把有关质量的策划、控制、协调、检查、改进工作都反映出来。

E.  确定新体系中文件结构

典型文件层次

二、编写文件、试点运行

1.   编写文件

A.  列出文件清单：

l   IT服务质量管理手册：手册的构成

l   职能的分配

l   组织间介面

l   手册中要素描述

l   有关支援性文件

l   程式文件：需编制哪些程式文件

l   每个程式文件对应标准那个要素

l   各程式文件之间有无重复、有无遗漏

l   各程式文件形成的记录

l   有关支援性文件

l   工作文件：作业指导书

l   技术类文件

l   管理文件

l   报告和表格

B.  明确哪些旧文件作废、哪些保留：

C.  分配文件编写任务：

各部门叁与

D.  起草文件：

l   工作流程

l   阐述简捷

l   语言标准

l   文件传递

E.  文件讨论：

l   内部讨论─适用性

l   外部检查─完整性

F.  文件批准发效

l   审核、批准

l   复印、装订

l   受控、登记

l   发效、签收

2.   试点运行

A.  体系交底：

l   手册：特点、使用、保管要求；

l   程式：特点、注意事项、形成记录、各程式之间介面；

l   工作文件：需要掌握关键问题如何记录，报告不合格品。

B.  培训、宣传：

l   培训：岗位培训；

l   特殊岗位培训考核；

l   管理人员程式文件培训；

l   全员IT服务质量管理方针、目标培训。

l   宣传：质量方针；

l   试运行计划；

l   ISO20000认证计划；

l   体系文件内容介绍。

C.  其他配套工作：

l   监控；

l   合格分承包方许定；

l   标识的制作。

D.  试运行：

l   补充完善基础工作：边运行，边完善第三层次文件；

l   修改体系文件：边运行，边修改不合适的文件；

l   作爲记录并保存好记录以推供证据。

三、内部审核、正式运行

1.   内部审核、管理评审：

l   至少进行一次内部审核，按ISO20000要求制订审核计划、审核清单、审核报告、不合格项的跟踪和监督等有关活动记录和文件应保存完好，以便以认证检查。

l   至少安排一次管理评审，以评价新体系的有效性和适用性，同时积累一次管理评审活动记录，评审按程式文件要求进行。

2.   正式运行：

l   通过内部审核、管理评审，对体系文件中不切合实际或规定不合适之处进行及时的修改，在一系列修改后，发布第二版质量手册、程式文件进行正式运行。

四、内部审核，准备认证

1.   爲了减少认证一次通过可能存在的某种风险，在由第三方正式审核之前，可以由内部审核组成类似的外部机构进行一次内部审核或请已确认的认证机构进行预审。

2.   企业应本着对自己有利的观点选择认证机构，一般应从以下几个

network

ISO20000中的配置管理和能力管理(2009-11-17 00:06:54)
转载标签：it服务管理ci配置管理it 分类：林威工作记录
今天进行差异访谈了，其实ISO20000的专案早就开始了！但是一直做着无聊的无意义的工作，今天开始算是正式工作开始，但是却不让我满意，首先是我自己就不牛，没有把ITIL和Cobit搞明白！结果今天当有人和我叫板的时候，我无力回击，我知道自己做的没错，只是大家都是在摸着石头过河，也没有必要在会议上拆穿别人，何况在我证据不足的情况下。所以今天回来补了补课！

首先是配置管理，一直以来都在围绕什么是配置管理，配置项到底有哪些这样的问题，“配置管理”是对CI进行管理，但更是对CI关系进行管理，所以可以这样说，CMDB中记录的20%是CI项，80%是CI项之间的关系。    “精而不多”是定义配置项属性的一个原则。既避免因属性过多而增加成本，又可以避免因属性过少而损害有效性。
    企业在实施ITIL项目的时候，配置管理常常被视为项目的“鸡肋”—食之无味，弃之可惜。究其原因主要是因为企业在创建CMDB（配置管理数据库）的时候，往往不知所措，耗费了大量的人力和时间收集各类IT基础架构信息，最后，大功告成的却是一个极其复杂而难以维护的“IT基础架构信息库”。
    这与ITIL描绘的配置管理是企业实践IT服务管理的基础或核心，为ITIL其他流程提供基础信息的关键地位相去甚远。
    那么，我们应该如何构建CMDB呢？
    制定政策  
    企业政策，是企业管理的行动指南和共同纲领。它使企业在认识上形成统一，减少了不必要的沟通成本，并使企业在流程执行上事半功倍。对于构建CMDB而言，主要有以下两类政策。
    宏观政策主要是涉及公司或IT部门层面指导性、方向性的政策，其目标是在企业内部形成统一认识。如：
    ◆ 企业IT内部应当使用统一的配置管理流程，并且使用标准的文档记录和汇报机制。
    配置管理流程的使用主体很大程度上确定了CMDB的范围和细节程度。如果其使用主体IT部门的职责和范围包括了开发和运维的话，那么，IT部门在构建CMDB的时候，要充分考虑两个团队的管理需要确定配置管理的范围和细节程度。一个共享的CMDB将为企业配置管理带来便利，但需要严格定义CMDB中CI（配置项）的访问权限。
    运营政策主要涉及到流程目标、人员、输入、输出、活动以及KPI(关键绩效指标)等各要素以及流程之间相互协调、信息交互方面的指导原则，其目标是使流程能够在政策的指引下稳健、有效地执行。如：
    ◆ 所有有关配置项的变更都需要通过变更管理流程进行控制，变更记录关闭前，必须通知到配置管理并得到批准。
    此项政策反映了两个流程之间关键的交互点。变更管理和配置管理是两个紧密相关的流程，只有成熟的变更控制才能保证CMDB数据的正确性。同时，CMDB应尽可能地反映真实环境的数据，从而更为准确地为其他流程提供管理信息。
    ◆ 如果条件具备，应当采用自动的方式从生产环境中获取配置数据，尽量减少或避免手工采集配置数据。
    此项政策描述了CMDB输入上的指导原则。CMDB需要记录IT基础架构的信息，在大量数据的情况下，手工采集容易导致错误。因而，此政策将有助于CMDB的构建团队仅可能获取相关资源改善流程的运营管理。
    确定范围
    政策的制定为企业构建CMDB营造了良好的环境，配置管理范围的确定才是企业构建CMDB的真正开始。配置管理的范围主要指的是CI的宽度和深度，以及CI的生命周期。（ITIL所提到的配置管理范围主要指的是CI的宽度和深度，CI的生命周期ITIL认为是从CI的接收到最终的报废退出，但在实施过程中，由于流程管理主体的差异化，对CI管理的生命周期的划分也有所不同。）
    确定CI宽度和深度的时候，企业IT部门应当充分考虑以下原则，如表1所示。
    1、企业IT服务的需要
    CMDB模型是为了满足企业的IT服务管理需求而构建的，主要涉及的需求包括：
    ◆ 相关法案和法规对IT管理的需求
    企业对IT的依赖性越来越高，同时，对IT风险的控制也就越来越重要，因此，企业IT部门往往面临着众多的法案和法规，而CMDB的构建将非常有利于企业对IT风险的识别和控制，如Sarbanes-Oxley法案404条款要求控制所有影响财务部的流程，而其中必然会涉及到IT财务应用系统，那么在决定CI范围的时候可以将其识别为CI，并且通过CI之间的关系能够清晰地分析出需要重点控制的CIs。相关法规如表2所示。
    ◆ IT库存和资产管理的需求
    CMDB和企业IT资产管理间存在着非常密切的关系，我们需要识别企业在库存管理和资产管理方面的需求。特别是当我们把提升IT资产管理成熟度作为CMDB项目的一个建设目标时，我们更需要和IT资产经理一起协同作战，共同识别并定义当前IT资产管理的管理范围，例如：合同和IT财务信息。
    与此同时，我们还需要不断比较、分析、筛选配置管理和IT资产管理两者的需求，找到一个平衡点。
    ◆ 服务目录的需求
    对于部分计划实施服务水平管理的企业，将服务目录（Service Catalog）需求纳入到整个CMDB建设中来也是至关重要的。
    “这台服务器是支撑哪些服务的？”，这个问题的答案对于当今的绝大多数企业来说也许只隐藏在部分高级工程师，甚至是IT经理的脑子中。如何让企业IT部门的每个员工都能够回答上面的问题，也逐渐成为企业构建CMDB的目标之一，它帮助我们能够更好的满足服务水平协议（SLAs）的要求，同时也能够进行精确的IT服务成本核算。
    在这个环节中，建立配置项和服务条目（定义在服务目录中）之间的关系是企业需要特别关注的。
2、企业IT服务管理的水平
    CMDB作为整个ITIL体系中的粘合剂，需要将IT服务管理流程的中涉及的数据和信息纳入到CMDB中。企业IT服务管理水平越高，其对CMDB数据的依赖也就越强，CMDB数据的准确性和完整性的要求也就越高。
    而IT服务管理水平很大程度影响了企业CMDB构建的范围和细节程度，例如，有些管理水平较高的企业为了减少人为判断事件的优先级的情况，因此，在CMDB中对每个配置项（CI）添加影响度、紧急度、影响人数等信息。
    3、企业CMDB运营管理成本
    CI的颗粒度决定了CMDB中信息的详细程度，而其详细程度的有效维护则取决于企业IT部门投入的管理成本。如果无法投入相应资源实现CMDB的有效维护，CMDB则无法保证其数据的准确性，也无法发挥其应有的价值。
    企业在初始化构建CMDB的时候，无论从服务管理意识上，还是服务管理水平上往往都处于中下游，而且，难以一次性投入大量的人力和物力，因而，一般性而言，CMDB初始构建应当由粗及细，循序渐进，逐步完善。
    CI生命周期的确定实际上主要是指对如下两个问题的确定。
    1、什么时候识别CI并记录到CMDB
    对于配置管理流程来说，CI全生命周期的理想状态应当包括从采购申请到报废退出。但在实际实施的过程中，流程执行主体的管理范围和职责决定了CI被识别的时间点。
    如配置管理的管理主体是企业IT的运维部门，其IT设备的采购则由采购部门负责，那么，IT运维部门对于采购阶段的IT设备无法进行跟踪管理，只有当采购部门将IT设备移交到运维部门后才被纳入配置管理的范围。
    2、什么时候对CI记录进行删除
    流程执行主体的管理范围和职责同样决定了CI生命周期被删除的时间点。如IT运维部门对于租赁的CI，企业并不关心该CI的报废过程，而只关心其在生产环境的状况，因而，一旦该CI被租赁公司进行了更换，则该CI记录将可能标记为删除。
    但如果企业需要遵守萨班尼斯法案，IT运维部门则必须关注所有CI的报废，因而，需要租赁公司在做相应处理后通知，然后，将该CI记录标记为删除。
    构建模型  
    在前面确定了配置管理范围之后，我们就要开始来梳理配置项信息及其关系，从而设计出CMDB模型蓝图，它是一项极富挑战性的工作，主要包括以下步骤。
    1、定义配置项的关系
    配置项（CI）之间关系的定义也是配置管理建设和IT资产管理建设的区别点之一。一般可以采取两种方法进行具体的梳理工作，一种是“自上而下”；另一种是“自下而上”。
    “自上而下”方法一般要求企业已经明确了对外提供的服务目录，然后基于服务目录按照“业务服务→IT服务→IT系统→IT组件”的顺序进行梳理。
    顾名思义，“自下而上”方法是“自上而下”方法的逆向过程，企业先从对内部IT组件关系进行梳理的过程开始，然后逐步将IT组件映射到IT服务。相对来说，当前“自下而上”的方法适用范围更广。
    2、定义配置项的属性
    在构建CMDB的过程中，除了构建配置项关系外，我们还需要为每个配置项定义属性。对于同一种类型的CI属性的定义，对于同步的企业可能截然不同，这给企业带来了巨大的挑战。一般来说我们遵循一个原则和一套结构。
    一个原则就是“精而不多”，这个原则我相信每个人都能够体会，对于CMDB建设同样适用。简单说，如果我们将大量的属性纳入到CMDB中，那么将存在大量信息需要进行维护，这无疑增加了成本。
    反之，如果属性过少，维护工作虽然减轻了，但是CMDB的有效性就大大降低了。因此，“精而不多”就是我们的平衡点。
    在这里，我们说的“精”在于强调“属性需要具备面向服务的特性”，举例来说，对于一台商用服务器，也许在这台服务器的说明书中包括了上百个属性，但实际上经过我们的筛选，对企业有实际意义往往是CPU个数、CPU主频、内存、硬盘、网卡等信息。
    一套结构指的是通常我们可以把一个配置项（CI）的属性分为五大来源，如表3所示。
    最后，我们还需要构建一份IT服务模型蓝图。蓝图主要起到了两个作用，一方面它是对当前企业CMDB建设工作成果的验证；另一方面，它也是对将来企业CMDB建设方向的一种指引。
    通常，蓝图中应包括以下内容：判断CI的标准；定义CI属性、关系的准则；持续改进方案和过程；当前的IT服务模型等。

然后是能力管理

第一个问题：能力是什么？能力管理的第一个要点：能力计划，你就会发现这个东西难以制作了，先说一下什么是能力，能力指你的服务器的处理能力，能力指你的网络负载，能力指你的工程师人数，能力指你的软件速度，能力指你的硬盘空间，能力指你的打印速度，你可以穷尽吗？可以，但很难，所以第一个问题就出来了，你如何定义你的能力，当你连能力是什么没有搞清楚前，你没有办法去谈什么阀值定义，你连要监视什么都不知道，更谈不上去提升。许多时候能力缩窄为CPU、内存、硬盘、带宽这种根本不用去谈什么能力管理都知道的技术参数，那实施能力管理与不实施能力管理有什么区别呢，除得搞复杂了，增加了管理成本外，带来什么好处了？

第二个问题：业务需求如何被洞悉，业务需求也是一个被说得烂了的词，某一个用户希望你的报表增加一个栏位，或者希望你的系统速度提升哪怕一秒钟，这算不算业务需求？算。客户的某个部门要新进一个人员，需要部署一台机器，需要你对这名人员做某个管理软件的培训，这算不算业务需求？也算，你的客户明年的生产需要扩大50%，算不算业务需求？算，举这些例子是想说明，业务需求你很难主动去识别的，更多是被动的接受到讯息，然后进行响应，它更多不是主动意识的结果。

第三个问题：业务需求与能力的关系。即便你可以随意入侵客户的组织内部，可以主动收集大量的信息，比如上面的几个例子，你都非常清楚了，那么你打算做什么？你可以把每一个业务需求换算成你能力指标吗？你知道增加一台计算，或提升一点系统速度，或者客户的业务量增加一些，会你的CPU、内存、硬盘、带宽、工程师带多少量化的要求吗？除非你可以有一个完美的计算机模型，不然这些业务需求你得到了讯息，你无法做任何事情，当客户的业务需求有质的变化时，比如明年客户的业务量要扩大一倍，这种需求一定是他提前会告之你做准备的，如果只是一些小的业务需求，你的服务是绝可以消化的，因为这些是在你签合同时就定义了，如果是一个比较大的新需求，客户另外需要付费，这也是一个其它的过程，而不是能力管理的范围。

第四个问题：实施能力管理流程，我们到底要做什么。标准会告诉你，你要制作你有能力计划，里面要描述当前与未来对于IT基础设施的能力需求，你要去模拟，去预测你的基础设施的运行情况，你还要做应用选型、监控、分析、调整、实施。这些作业都没有一个基于一个坚实的业务基础，最后更多会流于形式，更重要的没有搞这些时，真正能做的工作事实我们已在做了。而且IITL中对于能力管理好象一直着眼于基础架构，IT服务商真正的能力，最大的能力却不是基础架构，而是人，对服务资源的能力管理却好象是ISO20000或ITIL一直没有明确的。我相信购进一台新设备跟新培养一个服务人员相比，后者更复杂更需要被控制。

network