20150618MONICAZHANG

续上




[p=19,null,left]3.2各地IT运维情况汇总

[p=16,null,center]表格3‑1IT运维情况汇总

[td]

		[p=19,null,center]总部	[p=19,null,center]浙江	[p=19,null,center]陕西
[p=19,null,center]事件管理	[p=19,null,center]优势	ž各部门有热线电话； ž事件管理活动目标明确，以尽快恢复客户服务为目标，在实际工作中贯彻的很好； ž业务受理和故障处理过程中有很强的风险评估意识； ž故障处理有明确的故障定级标准和汇报机制，保障维护情况的及时通报； ž定期有运维报告分析服务情况； ž有周例会和月例会对内部运维情况进行沟通； ž有备岗、备件更换制度来保障业务的快速恢复，基本上满足了客户对恢复业务的要求； ž事件有文档记录，通过文件服务器进行共享； ž事件在处理完后一般会通知客户，保障了外部信息沟通的闭环； ž存在电子化的工具平台对事件进行记录、分派和分析，同时归档的纸质文档对审批和客户满意度记录都有记录。	ž为用户提供了统一的故障受理电话； ž对于桌面维护，建立了规范的故障处理流程； ž网络监控电子化水平较高，具有统一的网络监控工具，减轻了运维人员工作压力，提高了工作效率；ITSS考试 ž能够对重大事件进行记录。	ž已有的故障处理流程定义了故障处理规范性要求并在实际工作被执行； ž管理层重视故障处理工作； ž定期召开的月度会议保证了事件处理信息有一定程度上的回顾和内部交流沟通； ž不定期的客户满意度调查，使关注客户感受、是否满意有一定程度上的体现； ž二次开发后的IBM监控软件Tivoli开始试运行，提高了监控IT系统的有效性。
	[p=19,null,center]不足	ž根据业务类型不同，存在多处理流程，需近一步明晰和整合以简化操作； ž服务台主要实现值班职能，对事件的监管职能不足； ž信息没有全部被记录到系统中，某些情况下导致日常运维难以形成闭环； ž部分业务受理的处理性能标准由客户临时决定，影响了人力资源的有效分配； ž缺少层次化的处理过程，高级资源可能浪费在处理简单的事务中； ž事件处理的结果记录有些比较粗略，不能达到形成知识共享的需要； ž处理和维护信息由多部门分管，难以整体回顾和分析服务情况； ž处理信息由纸面和系统记录，关联性不强，为处理历史回顾带来一定困扰； ž纸质的记录使管理工作量加大，不利于统计分析； ž工具的功能不全面，流程记录工作的繁复，实际工作中没有全面的应用起来； ž没有统一的平台来记录，跟踪，分析和监控事件的操作； ž电子化处理平台当前的利用率不高； ž缺乏流程和工具的支持，没有统一的平台来记录，跟踪，分析和监控事件的操作； ž事件的处理过程难于监控，没有相应的跟踪与升级机制； ž没有事件的优先级定义标准，没有建立优先级和解决时限的关联关系，从而不能保证事件解决的实效性和IT资源的有效利用； ž事件多为事后记录，记录不全或多渠道记录； ž没有知识库，知识目前以文档化记录居多，不利于知识的查找和共享，不能很好地做知识积累，也不能向用户提供，以减少事件的数量。	ž故障受理电话目前只用于受理桌面类事件，其他故障和申告还是以机房热线或者直接找到相关IT运维人员为主，缺乏统一的故障受理流程； ž缺乏重大事件升级到问题的机制；ITSS工具 ž桌面类事件基本能够进行记录，但是其他类型事件记录以个人工作习惯为主，缺乏统一的事件记录机制； ž没有设立明确的事件经理角色； ž没有电子化工具支撑事件管理； ž没有对事件进行适当的分类，不利于事件量化、统计和知识积累； ž缺乏和问题管理、配置管理、变更管理之间的关联； ž目前没有专门的知识库工具，不能很好地做整个中心的知识积累，也不能向用户有效提供知识查询，以减少事件的数量；	ž故障有分级定义，但定义描述不够明确，比较难于准确分级； ž事件升级标准定义不够明确，升级正确与否依赖员工的工作经验； ž缺乏能够统计员工工作量和工作效率的工具； ž缺乏知识管理工具，不利于知识共享。
[p=19,null,center]问题管理	[p=19,null,center]优势	ž问题发现后会指派专人负责分析解决。 ž	ž能够按照季度在一定程度上进行问题趋势分析活动（运行分析会）；ITSS团购 ž员工工作认真，存在着自发进行的问题活动，例如网络流量趋势分析。	ž虽然没有定义问题管理流程，但是故障处理流程中定义了对重大事件、或严重故障必须有事后的故障分析并形成故障分析报告。这个活动可以说是一种问题管理的方式； ž故障有分类，重大或严重的事件资深技术人员立即介入解决行动； ž故障分析报告记录故障原因、解决方案； ž管理层重视彻底解决问题并致力于解决问题以减少事件的发生。
	[p=19,null,center]不足	ž没有明显的问题管理流程存在； ž问题管理中的一些活动存在于事件管理过程中，重大故障一般才会被做为问题处理； ž一般以被动响应故障为主。	ž缺乏统一的问题管理流程； ž没有明确的问题管理角色； ž虽然存在着一些问题管理活动，但是定义不完全； ž缺乏电子平台支持。	ž没有定义问题管理流程； ž问题与故障未作区分。
[p=19,null,center]配置管理	[p=19,null,center]优势	ž有设备管理信息记录，并存在关联关系，能够为服务人员提供大部分处理信息； ž客服系统中有配置管理数据库； ž有通过设备档案卡记录进入生产环境的设备信息； žIP地址、操作系统版本、开放服务进程也有相应文档记录	ž目前运维工作人员认识到了细致的配置管理工作能够为运维工作带来好处； ž目前已经具备配置管理的雏形，能够能够按照网络、应用等方面分类对配置项信息进行记录，并有专人负责。	ž
	[p=19,null,center]不足	ž没有明显的配置管理流程； ž已有的配置管理数据库，因缺乏维护，数据已与实际环境不一致，未在使用； ž配置管理流程涉及的范围不全，由于人力问题，存在缺少定期审计的现象。	ž缺乏统一的配置管理流程； ž缺少规范、标准的配置管理计划；ITSS软件 ž没有形成完整，统一的配置管理数据库，导致不能在科技处范围内提供正确并且统一的IT元素配置信息； ž没有定期的配置项审核行为，无法确保个人手中的配置收集信息与实际IT环境保持一致； ž配置管理没有合适的电子化工具平台进行支持，而是以文档的方式进行存放，在日常运维工作中，无法给解决故障、恢复服务以有力支持，并且无法对科技信息部的所有IT资源提供全局性的、方便快捷的查询和统计。	ž没有定义配置管理流程； ž现有的配置管理活动局限于设备的出入库记录、个人负责维护系统或设备的配置信息； ž记录信息多保存在共享服务器上； ž对配置信息的收集没有统一规定格式、内容要求，信息是否收集全面依赖个人的工作经验； ž没有定期的审核以及为管理层提供管理报告的能力。
[p=19,null,center]变更管理	[p=19,null,center]优势	ž重视对变更的处理； ž变更过程中有较为完善的计划和评估过程，能够保障变更过程的可靠执行； ž对系统变更有严格的管控和安全措施，控制系统变更带来的影响；ITSS体系 ž有明确的流程，并且通过《操作单》，《故障处理单》等表单工具对计划、审批及测试过程进行严格的控制，基本达到了变更控制的主要目的； ž与事件管理流程有较为明显的分界。	l对于业务有影响的变更，能够主动通知收到影响的用户，提升了客户体验； l对于影响范围较大的变更，能够事先制定变更计划，控制变更风险。	l信息部对设备的增加、删除、配置更改定义了相应的变更管理流程； l管理层了解变更管理的重要性并进行了严格的控制； l对不同的变更要求，有不同的变更管理流程定义了明确的处理步骤和审批负责人。有效地控制了变更的风险； l对较大的变更，会经过讨论对变更方案进行评审； l变更时会考虑到时间计划、备份计划以及恢复计划等。
	[p=19,null,center]不足	ž变更管理流程与其它流程很难达到信息共享和协调的要求； ž对变更的回顾过程也不明确。	ž缺乏统一的变更管理流程； ž变更紧急程度没有清晰定义，紧急程度判断以个人工作经验为主； ž变更类别没有清晰定义，没有明确划分紧急变更、简单变更和标准变更； ž缺乏电子平台支持，降低了工作效率，并且不利于提取考核指标。ISO20000培训	ž目前没有平台工具对变更管理活动进行跟踪； ž没有为管理层生成反映变更管理状况的数据和报告； ž疏于从客户处了解他们对变更活动的满意情况和看法。
[p=19,null,center]发布管理	[p=19,null,center]优势	ž业务范围中不包括针对业务系统的开发管理和上线工作； ž发布过程主要在变更管理过程中控制。	žSAP系统具有独立的测试环境，对软件上线做了严格测试，保障正式上线的安全性和可靠性； ž	ž为OA程序更新、新设备上线定义了相应的管理流程，对开展这些活动进行了控制。
	[p=19,null,center]不足	ž	ž对其它软件的开发过程并未整体管理，没有严格区分开发、测试、生产环境； ž缺少对软件版本和License的记录控制； ž没有建立DSL（最终软件库）。	ž对发布管理活动本身的研究不够； ž由于配置管理活动的不足，发布管理难于得到来自配置管理的支持； ž没有专门反映发布管理活动的信息和报告提交给管理层； ž疏于了解客户对发布的满意情况和要求。
[p=19,null,center]服务级别管理	[p=19,null,center]优势	ž信息中心与包括总部及直属单位在内的客户签订有服务合同对服务范围和性能有一定的约定； ž处理结果有客户的签字反馈； ž每月统计处理事件的情况作为服务分析； ž每月与客户开技术联络会。	ž在实际工作中业务部门对科技信息部是有一定的服务级别要求的。	ž服务级别管理活动的必要性和好处已经为组织所认识； ž信息部已经开展了一些服务级别管理的活动； ž在现行的故障处理活动中定义了响应时间、处理完成的时限要求，运行中要求达到“四率”要求并向管理层报告“四率”达标情况。
	[p=19,null,center]不足	ž客户经常会提出些超出服务范围内容的服务申请，对于服务范围的理解双方还有偏差，缺少对客户提出的新服务需求进行及时的服务范围变更； ž服务过程中的一些数据无法量化，对于客户难以提供全面的服务分析报告	ž没有定义清晰的服务目录，也没有各业务部门签订服务级别协议。ITIL培训	ž缺少明确定义的服务目录和与业务用户达成的服务级别协议（SLA）； ž还没有达到为其他流程提供服务目标、服务要求，提供质量标准的程度； ž无法对客户提供服务级别达标情况的报告。
[p=19,null,center]可用性管理	[p=19,null,center]优势	ž对各在维系统有相应的监控系统提供可用性评估中的部分数据。	ž	ž围绕达标“四率”要求，信息部在日常运行维护中规定了一系列的管理措施和流程； ž系统运行巡检工作流程和巡检内容检查表具体体现了保障IT系统可用性方面的努力。
	[p=19,null,center]不足	ž没有形成完整的流程； ž可用性监测与评估职责没有明显的职责分配； ž对于服务可用性未见明显的监测方法与工具。	ž目前没有建立相关的流程来确保和监控一些重要业务系统的可用性。	ž由于其他流程的缺失，可用性管理活动还未能充分发挥它的作用； ž对可用性的数据比较局限与最终对“四率”的达标结果，对影响可用性的信息分析还不够深入； ž疏于了解业务用户对可用性的感受。
[p=19,null,center]容量管理	[p=19,null,center]优势	ž相关管理层已经逐步意识到量化管理的重要性； ž已初步建立了一些量化管理工具，如网络管理工具、应用管理工具。	ž在实际工作中自发的开始了一些容量管理相关的活动，建立了一些量化管理工具。	ž在实际工作中现行的一些做法其实具有了容量管理的内容，如日常巡检是检查设备、系统资源等的利用率； ž管理层重视设备、系统容量对IT服务的影响，并采取措施进行监控； ž有规范的巡检报告记录设备、系统的容量使用情况。
	[p=19,null,center]不足	ž主要集中在对当前系统能力和容量的监测，与改进，未见明显与业务需求相关的系统规划与预测过程。	ž没有完善的容量管理流程，还没有系统的从业务的视觉来总体考虑容量管理的相关内容。	ž还没有定义、形成容量管理流程； ž由于其他IT服务管理流程的缺失，容量管理活动的作用有限，还未能充分发挥其作用。
[p=19,null,center]IT可持续性管理	[p=19,null,center]优势	ž有详细的应急方案和备件储备，能够保障在重大事件处理时快速恢复； ž对系统中可能存在的信息安全事件发布了较为完善的应急预案，并且对预案制定了演练要求，并定期演练； ž对灾难处理情况有报告和回顾。	ž针对一些重要的系统中建立了相应的应急预案，并且对预案制定了演练要求； ž对灾难处理情况有报告和回顾。	žITSS培训
	[p=19,null,center]不足	ž应急预案针对系统制定的，没有针对业务制定，缺乏对业务影响的分析； ž对于计划本身的变更与回顾也缺少明确的流程和规定支持；	ž应急预案针对系统制定的，没有针对业务制定，缺乏对业务影响的分析； ž对于计划本身的变更与回顾也缺少明确的流程和规定支持； ž操作方法和过程不够明细和完善，增加了培训难度，降低了计划实施的可靠性。	ž没有对容灾有过多的考虑，相关的活动没有开展。
[p=19,null,center]IT财务管理	[p=19,null,center]优势	ž	ž存在着一些成本方面的预算和管理。	ž
	[p=19,null,center]不足	ž对于IT成本的考察多以系统成分和人力资源配置经验获得，缺少量化评估数据支持。	ž没有对IT组织的其它成本如人工成本进行核算； ž不能够向业务部门收取相关的服务费用。ITSS认证	ž还没有开展针对IT运行财务状况的分析管理活动； ž向使用IT服务的业务部门收费目前还没有提上议事日程。

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

本帖关键字：ITSSISO20000[p=17,null,left]

20150618MONICAZHANG

续上




[p=19,null,left]3.2各地IT运维情况汇总

[p=16,null,center]表格3‑1IT运维情况汇总

[td]

		[p=19,null,center]总部	[p=19,null,center]浙江	[p=19,null,center]陕西
[p=19,null,center]事件管理	[p=19,null,center]优势	ž各部门有热线电话； ž事件管理活动目标明确，以尽快恢复客户服务为目标，在实际工作中贯彻的很好； ž业务受理和故障处理过程中有很强的风险评估意识； ž故障处理有明确的故障定级标准和汇报机制，保障维护情况的及时通报； ž定期有运维报告分析服务情况； ž有周例会和月例会对内部运维情况进行沟通； ž有备岗、备件更换制度来保障业务的快速恢复，基本上满足了客户对恢复业务的要求； ž事件有文档记录，通过文件服务器进行共享； ž事件在处理完后一般会通知客户，保障了外部信息沟通的闭环； ž存在电子化的工具平台对事件进行记录、分派和分析，同时归档的纸质文档对审批和客户满意度记录都有记录。	ž为用户提供了统一的故障受理电话； ž对于桌面维护，建立了规范的故障处理流程； ž网络监控电子化水平较高，具有统一的网络监控工具，减轻了运维人员工作压力，提高了工作效率；ITSS考试 ž能够对重大事件进行记录。	ž已有的故障处理流程定义了故障处理规范性要求并在实际工作被执行； ž管理层重视故障处理工作； ž定期召开的月度会议保证了事件处理信息有一定程度上的回顾和内部交流沟通； ž不定期的客户满意度调查，使关注客户感受、是否满意有一定程度上的体现； ž二次开发后的IBM监控软件Tivoli开始试运行，提高了监控IT系统的有效性。
	[p=19,null,center]不足	ž根据业务类型不同，存在多处理流程，需近一步明晰和整合以简化操作； ž服务台主要实现值班职能，对事件的监管职能不足； ž信息没有全部被记录到系统中，某些情况下导致日常运维难以形成闭环； ž部分业务受理的处理性能标准由客户临时决定，影响了人力资源的有效分配； ž缺少层次化的处理过程，高级资源可能浪费在处理简单的事务中； ž事件处理的结果记录有些比较粗略，不能达到形成知识共享的需要； ž处理和维护信息由多部门分管，难以整体回顾和分析服务情况； ž处理信息由纸面和系统记录，关联性不强，为处理历史回顾带来一定困扰； ž纸质的记录使管理工作量加大，不利于统计分析； ž工具的功能不全面，流程记录工作的繁复，实际工作中没有全面的应用起来； ž没有统一的平台来记录，跟踪，分析和监控事件的操作； ž电子化处理平台当前的利用率不高； ž缺乏流程和工具的支持，没有统一的平台来记录，跟踪，分析和监控事件的操作； ž事件的处理过程难于监控，没有相应的跟踪与升级机制； ž没有事件的优先级定义标准，没有建立优先级和解决时限的关联关系，从而不能保证事件解决的实效性和IT资源的有效利用； ž事件多为事后记录，记录不全或多渠道记录； ž没有知识库，知识目前以文档化记录居多，不利于知识的查找和共享，不能很好地做知识积累，也不能向用户提供，以减少事件的数量。	ž故障受理电话目前只用于受理桌面类事件，其他故障和申告还是以机房热线或者直接找到相关IT运维人员为主，缺乏统一的故障受理流程； ž缺乏重大事件升级到问题的机制；ITSS工具 ž桌面类事件基本能够进行记录，但是其他类型事件记录以个人工作习惯为主，缺乏统一的事件记录机制； ž没有设立明确的事件经理角色； ž没有电子化工具支撑事件管理； ž没有对事件进行适当的分类，不利于事件量化、统计和知识积累； ž缺乏和问题管理、配置管理、变更管理之间的关联； ž目前没有专门的知识库工具，不能很好地做整个中心的知识积累，也不能向用户有效提供知识查询，以减少事件的数量；	ž故障有分级定义，但定义描述不够明确，比较难于准确分级； ž事件升级标准定义不够明确，升级正确与否依赖员工的工作经验； ž缺乏能够统计员工工作量和工作效率的工具； ž缺乏知识管理工具，不利于知识共享。
[p=19,null,center]问题管理	[p=19,null,center]优势	ž问题发现后会指派专人负责分析解决。 ž	ž能够按照季度在一定程度上进行问题趋势分析活动（运行分析会）；ITSS团购 ž员工工作认真，存在着自发进行的问题活动，例如网络流量趋势分析。	ž虽然没有定义问题管理流程，但是故障处理流程中定义了对重大事件、或严重故障必须有事后的故障分析并形成故障分析报告。这个活动可以说是一种问题管理的方式； ž故障有分类，重大或严重的事件资深技术人员立即介入解决行动； ž故障分析报告记录故障原因、解决方案； ž管理层重视彻底解决问题并致力于解决问题以减少事件的发生。
	[p=19,null,center]不足	ž没有明显的问题管理流程存在； ž问题管理中的一些活动存在于事件管理过程中，重大故障一般才会被做为问题处理； ž一般以被动响应故障为主。	ž缺乏统一的问题管理流程； ž没有明确的问题管理角色； ž虽然存在着一些问题管理活动，但是定义不完全； ž缺乏电子平台支持。	ž没有定义问题管理流程； ž问题与故障未作区分。
[p=19,null,center]配置管理	[p=19,null,center]优势	ž有设备管理信息记录，并存在关联关系，能够为服务人员提供大部分处理信息； ž客服系统中有配置管理数据库； ž有通过设备档案卡记录进入生产环境的设备信息； žIP地址、操作系统版本、开放服务进程也有相应文档记录	ž目前运维工作人员认识到了细致的配置管理工作能够为运维工作带来好处； ž目前已经具备配置管理的雏形，能够能够按照网络、应用等方面分类对配置项信息进行记录，并有专人负责。	ž
	[p=19,null,center]不足	ž没有明显的配置管理流程； ž已有的配置管理数据库，因缺乏维护，数据已与实际环境不一致，未在使用； ž配置管理流程涉及的范围不全，由于人力问题，存在缺少定期审计的现象。	ž缺乏统一的配置管理流程； ž缺少规范、标准的配置管理计划；ITSS软件 ž没有形成完整，统一的配置管理数据库，导致不能在科技处范围内提供正确并且统一的IT元素配置信息； ž没有定期的配置项审核行为，无法确保个人手中的配置收集信息与实际IT环境保持一致； ž配置管理没有合适的电子化工具平台进行支持，而是以文档的方式进行存放，在日常运维工作中，无法给解决故障、恢复服务以有力支持，并且无法对科技信息部的所有IT资源提供全局性的、方便快捷的查询和统计。	ž没有定义配置管理流程； ž现有的配置管理活动局限于设备的出入库记录、个人负责维护系统或设备的配置信息； ž记录信息多保存在共享服务器上； ž对配置信息的收集没有统一规定格式、内容要求，信息是否收集全面依赖个人的工作经验； ž没有定期的审核以及为管理层提供管理报告的能力。
[p=19,null,center]变更管理	[p=19,null,center]优势	ž重视对变更的处理； ž变更过程中有较为完善的计划和评估过程，能够保障变更过程的可靠执行； ž对系统变更有严格的管控和安全措施，控制系统变更带来的影响；ITSS体系 ž有明确的流程，并且通过《操作单》，《故障处理单》等表单工具对计划、审批及测试过程进行严格的控制，基本达到了变更控制的主要目的； ž与事件管理流程有较为明显的分界。	l对于业务有影响的变更，能够主动通知收到影响的用户，提升了客户体验； l对于影响范围较大的变更，能够事先制定变更计划，控制变更风险。	l信息部对设备的增加、删除、配置更改定义了相应的变更管理流程； l管理层了解变更管理的重要性并进行了严格的控制； l对不同的变更要求，有不同的变更管理流程定义了明确的处理步骤和审批负责人。有效地控制了变更的风险； l对较大的变更，会经过讨论对变更方案进行评审； l变更时会考虑到时间计划、备份计划以及恢复计划等。
	[p=19,null,center]不足	ž变更管理流程与其它流程很难达到信息共享和协调的要求； ž对变更的回顾过程也不明确。	ž缺乏统一的变更管理流程； ž变更紧急程度没有清晰定义，紧急程度判断以个人工作经验为主； ž变更类别没有清晰定义，没有明确划分紧急变更、简单变更和标准变更； ž缺乏电子平台支持，降低了工作效率，并且不利于提取考核指标。ISO20000培训	ž目前没有平台工具对变更管理活动进行跟踪； ž没有为管理层生成反映变更管理状况的数据和报告； ž疏于从客户处了解他们对变更活动的满意情况和看法。
[p=19,null,center]发布管理	[p=19,null,center]优势	ž业务范围中不包括针对业务系统的开发管理和上线工作； ž发布过程主要在变更管理过程中控制。	žSAP系统具有独立的测试环境，对软件上线做了严格测试，保障正式上线的安全性和可靠性； ž	ž为OA程序更新、新设备上线定义了相应的管理流程，对开展这些活动进行了控制。
	[p=19,null,center]不足	ž	ž对其它软件的开发过程并未整体管理，没有严格区分开发、测试、生产环境； ž缺少对软件版本和License的记录控制； ž没有建立DSL（最终软件库）。	ž对发布管理活动本身的研究不够； ž由于配置管理活动的不足，发布管理难于得到来自配置管理的支持； ž没有专门反映发布管理活动的信息和报告提交给管理层； ž疏于了解客户对发布的满意情况和要求。
[p=19,null,center]服务级别管理	[p=19,null,center]优势	ž信息中心与包括总部及直属单位在内的客户签订有服务合同对服务范围和性能有一定的约定； ž处理结果有客户的签字反馈； ž每月统计处理事件的情况作为服务分析； ž每月与客户开技术联络会。	ž在实际工作中业务部门对科技信息部是有一定的服务级别要求的。	ž服务级别管理活动的必要性和好处已经为组织所认识； ž信息部已经开展了一些服务级别管理的活动； ž在现行的故障处理活动中定义了响应时间、处理完成的时限要求，运行中要求达到“四率”要求并向管理层报告“四率”达标情况。
	[p=19,null,center]不足	ž客户经常会提出些超出服务范围内容的服务申请，对于服务范围的理解双方还有偏差，缺少对客户提出的新服务需求进行及时的服务范围变更； ž服务过程中的一些数据无法量化，对于客户难以提供全面的服务分析报告	ž没有定义清晰的服务目录，也没有各业务部门签订服务级别协议。ITIL培训	ž缺少明确定义的服务目录和与业务用户达成的服务级别协议（SLA）； ž还没有达到为其他流程提供服务目标、服务要求，提供质量标准的程度； ž无法对客户提供服务级别达标情况的报告。
[p=19,null,center]可用性管理	[p=19,null,center]优势	ž对各在维系统有相应的监控系统提供可用性评估中的部分数据。	ž	ž围绕达标“四率”要求，信息部在日常运行维护中规定了一系列的管理措施和流程； ž系统运行巡检工作流程和巡检内容检查表具体体现了保障IT系统可用性方面的努力。
	[p=19,null,center]不足	ž没有形成完整的流程； ž可用性监测与评估职责没有明显的职责分配； ž对于服务可用性未见明显的监测方法与工具。	ž目前没有建立相关的流程来确保和监控一些重要业务系统的可用性。	ž由于其他流程的缺失，可用性管理活动还未能充分发挥它的作用； ž对可用性的数据比较局限与最终对“四率”的达标结果，对影响可用性的信息分析还不够深入； ž疏于了解业务用户对可用性的感受。
[p=19,null,center]容量管理	[p=19,null,center]优势	ž相关管理层已经逐步意识到量化管理的重要性； ž已初步建立了一些量化管理工具，如网络管理工具、应用管理工具。	ž在实际工作中自发的开始了一些容量管理相关的活动，建立了一些量化管理工具。	ž在实际工作中现行的一些做法其实具有了容量管理的内容，如日常巡检是检查设备、系统资源等的利用率； ž管理层重视设备、系统容量对IT服务的影响，并采取措施进行监控； ž有规范的巡检报告记录设备、系统的容量使用情况。
	[p=19,null,center]不足	ž主要集中在对当前系统能力和容量的监测，与改进，未见明显与业务需求相关的系统规划与预测过程。	ž没有完善的容量管理流程，还没有系统的从业务的视觉来总体考虑容量管理的相关内容。	ž还没有定义、形成容量管理流程； ž由于其他IT服务管理流程的缺失，容量管理活动的作用有限，还未能充分发挥其作用。
[p=19,null,center]IT可持续性管理	[p=19,null,center]优势	ž有详细的应急方案和备件储备，能够保障在重大事件处理时快速恢复； ž对系统中可能存在的信息安全事件发布了较为完善的应急预案，并且对预案制定了演练要求，并定期演练； ž对灾难处理情况有报告和回顾。	ž针对一些重要的系统中建立了相应的应急预案，并且对预案制定了演练要求； ž对灾难处理情况有报告和回顾。	žITSS培训
	[p=19,null,center]不足	ž应急预案针对系统制定的，没有针对业务制定，缺乏对业务影响的分析； ž对于计划本身的变更与回顾也缺少明确的流程和规定支持；	ž应急预案针对系统制定的，没有针对业务制定，缺乏对业务影响的分析； ž对于计划本身的变更与回顾也缺少明确的流程和规定支持； ž操作方法和过程不够明细和完善，增加了培训难度，降低了计划实施的可靠性。	ž没有对容灾有过多的考虑，相关的活动没有开展。
[p=19,null,center]IT财务管理	[p=19,null,center]优势	ž	ž存在着一些成本方面的预算和管理。	ž
	[p=19,null,center]不足	ž对于IT成本的考察多以系统成分和人力资源配置经验获得，缺少量化评估数据支持。	ž没有对IT组织的其它成本如人工成本进行核算； ž不能够向业务部门收取相关的服务费用。ITSS认证	ž还没有开展针对IT运行财务状况的分析管理活动； ž向使用IT服务的业务部门收费目前还没有提上议事日程。

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

本帖关键字：ITSSISO20000[p=17,null,left]