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