20150618 MONICAZHANG

续上



3.3运行情况分析



3.2.1总部运行情况分析

信息中心是某总公司领导下的二级单位，承担着某总部（包括西单大楼和白广路大楼）IT基础架构维护、信息系统建设和信息资源的建设的职责。信息中心的主要运维机构由网络控制中心、客户服务中心和汇置通工作组三个部门组成。
客户服务中心：主要负责系统前端的日常维护工作。包括总部和相关单位的桌面维护，协同办公系统(OA)维护、门户网站运行维护、网络管理系统等。客服热线电话是7777和7186。                  ITSS考试
网络控制中心：主要负责系统后端的建设，运行维护工作。目前信息中心的系统维护主要集中在平台级以下，即某骨干网络维护、应用系统平台维护（包括操作系统、中间件、裸数据库）、数据中心、主机维护、以及北京城域网，西单大楼和白广路大楼局域网的维护工作。
汇置通工作部：主要面向在汇置通大厦的某各下属公司在IT运行方面进行进行维护支持。包括：汇置通大楼局域网维护、各单位应用服务器托管服务、维护主机/系统/裸数据库、网络基础应用的维护、协同办公系统(OA)、电子邮件系统、DNS等相关工作。
在长期的运维实践经验积累中某信息中心已经形成了较为完整的服务受理和故障处理流程。有统一的规范和制度，并且在IT服务提供方面与总部形成了较为规范的服务提供合同。
某信息中心目前接受投诉和故障申告的服务对象是某总部的各业务部门和各下属分公司，包括各业务系统平台和客户端故障的处理。处理中三个部门使用不同的流程管理工具执行，根据受理业务不同，形成了不同的处理过程。目前与客户沟通的主要方式是电话，三个部门分别设有各自的业务受理电话，服务受理范围上，网控中心与客服中心主要以职能划分为主，汇置通工作部以服务对象划分为主；服务以5×8小时支持为主，8小时外有值班员处理紧急事件。
在现行的运行管理规定中，针对事件、变更、配置过程有一些制度上的规定，包括运行值班记录、业务受理单、操作单、故障处理记录等均为文档化，并有相应的管理规定，并通过文件服务器共享。                ITSS工具          
没有独立的问题管理流程（与事件管理在一起），系统中的问题在每月的运行分析会上讨论。
运行维护和服务基本围绕网络、业务平台和网络基础应用展开，不涉及客户业务应用的需求管理和开发管理，应用系统自测试、试运行交维，试运行结束验收后正式上线维护。

对于IT管理，信息中心曾建设过两个系统，一个是与网管一起建设的帮助台系统，另一个是东软开发的流程管理平台。
目前网控中心正在使用帮助台系统记录事件，客服中心使用开发的流程管理平台，处理的事件不是全部记入系统，部分事件通过业务受理单、操作单或故障处理单记录流转。

汇置通工作部使用值班记录记录事件。业务受理单用于客户提交服务申告，操作单用于系统变更时的操作处理

三个部门流程基本独立运转，需要协调时通过业务受理单或故障处理单进行转派。

某总部运行情况具有一下特点：

n        IT流程规范执行：目前信息中心已经建立起了比较规范的IT服务流程和制度，并且开发过相关的支持系统。但由于工具的功能不全面，流程记录工作的繁复，实际工作中没有全面的应用起来。IT流程的总体执行效果有待提高，运维人员少，信息没有被记录到系统中，某些情况下导致日常运维难以形成闭环。               ITSS团购
n        项目建设和日常运维工作交互同时进行：目前项目任务工作量大大超过了运维任务。但信息中心人力资源有限，带来了有限的资源和不断增长的项目建设工作量，运行维护工作量间的矛盾。（曾有独立的项目部门，但存在着项目建设后无法移交的困难，最终只能系统和建设人员一起移交。）
n        业务模式转变带来了运维压力：
§ 公司信息化建设要求，以前每月提交管理报告，今后总部希望能够实时看到运维工作的处理结果和处理过程；
§      视频会议、网络直播等实时性的IT服务，对网络带宽、速度和稳定性的要求较高。而且现在在业务运行中，越来越多的使用这些服务；
§      各地的数据中心建设形成数据集中，而数据集中带来的是系统的集中，凸显了运维资源的不足（技术、能力），运维模式急需改变
§      管理制度体系：目前共有几十项制度。从总体上，管理制度没有形成体系。总部信息办的制度和信息中心的制度之间，相互的关联性没有得到体现；现有制度既有面向管理的，也有面向技术。             ITSS软件
n        没有全面使用IT服务管理系统记录日常服务工作：当前运维工作有流程，有记录，有审批。使用纸质载体记录审批，电子文档记录过程的流程运作（操作单），能够满足当前要求；但是工作量统计比较困难、不能进行人员/系统的深入分析，查询、共享和权限管理都很不方便。随着SG186工程建设，运维支持的系统将越来越多，运维工作量越来越大。现有的操作单工作方式将不能满足管理要求，会制约IT服务水平和管理水平的提高。


3.2.2        浙江省运行情况分析

浙江省电力科技信息部目前接受故障申告和服务请求的服务对象是浙江省电力内部的各业务部门客户，包括网络、portal、OA和客户端、桌面故障的处理。目前在省公司已经设立统一的服务台186对客户进行支持，有2名外包人员进行一线的支持，如果一线解决不了将会转到信息安全处相关专责IT人员处理。但是如遇业务系统的问题将不通过186服务台，如业务部门独立找外部厂商开发的业务系统的问题将直接联系外包商处理，如业务系统数据库维护方面的问题，则系统管理员直接联系信息安全处负责此业务系统的IT人员，186服务台的支持服务以7×8小时支持为主。
在现行的运行工作中，针对事件、变更、配置、发布过程有一些制度上的规定，并有相应的管理规定，但是IT人员由于负责领域的不同而划分成不同的小组，每个小组各自有一套流程，因此流程无法统一，知识和资源也无法共享（如知识库只存在于小组内的共享服务器上），产生了以每个小组为单位的信息孤岛现象，同时，即使是有相应的流程和制度，但缺乏实用性，也没有和考核体制挂钩，因此也没被所有维护人员熟悉，不能很好的坚持。事件管理虽然整体执行效果还不错，但对故障的主动发现不多，更多的是在故障发生后进行修复和事后审计；对故障的分类和优先级的判断没有统一的标准，同时对事件发生的处理过程没有有效的记录。
没有独立的问题管理流程，往往是与事件管理在一起，在SAP业务中，问题管理有所体现，但是不清晰。
SAP的变更需要业务部门和技术部门的领导审批，对变更风险和影响有简单的评估，但没有统一的标准，往往是靠每个人自己的经验，变更的质量没有专人控制。                               ITSS体系
对设备等配置项信息有部分记录，但没有在组织中共享，有的配置项信息只有在系统的管理员个人手中才有，命名没有遵循一定的规则，没有配置项信息间的关系记录，不能把事件和IT设备联系起来，也没有管理流程来确保配置信息的定期更新，因此很多不能保证现有数据的准确性和完整性。
存在开发、测试生产环境支持发布管理，但是开发和生产环境比较混乱，经常有功能重复的系统上线，造成了资源的浪费，且没有规范化、严格化的管理流程，导致系统上线后经常需要更改。
目前科技信息部建立了186服务台作为接受故障申告和服务呼叫的窗口，但是服务台受理的范围非常有限，只是负责桌面类故障申告和服务请求的受理，与业务系统相关的事件，用户会直接找负责相应业务系统的管理员申告事件。
桌面类故障申告到服务台后，服务台首先做一线进行处理，一线解决不了，会升级到信息安全处进行二线支持，二线尝试性解决，如遇较大故障需要厂商参与的，会转到三线，即外包商（原厂商）支持。但有的时候，存在着用户绕过服务台直接联系IT人员寻求支持的情况，从而导致186服务台记录事件不全。                        ISO20000培训
业务系统类申告直接找到信息安全处的系统管理员后，管理员会对申告进行处理，对于权限修改，密码设置等服务请求，系统管理员直接进行处理；如果系统管理员判断是用户申告是由故障导致的，系统管理员会对故障等级进行判断，业务系统对事件等级进行了定义，分成重大故障，较大故障，一般故障和一般问题四个级别，重大故障需要向领导汇报，对于如果是需要上报到科技处领导的，系统管理员会上报到科技处领导进行备案，如果不需要则直接进行处理；处理过程中如果需要科技信息部内部员工进行支持的，系统管理员直接去联系相应员工进行协同处理；处理过程中需要厂商支持的，则自己去联系厂商，寻求厂商支持。
对于IT基础架构类事件，没有明确划分出事件的分类和优先级，依靠人为的判断，没有统一的标准。但是基础架构管理员会根据经验判断事件级别，自己认为重大的事件也会上报到领导。
上述的处理过程一般没有进行记录，只有明确了是重大故障级别的事件才会进行记录。
目前科技信息部每个专业小组或管理员会把自己掌握的配置项信息采用电子表格的方式记录下来，在事件处理过程中会参考到这些文档进行信息查询。但是这些配置项信息的文档往往按照自己的个人习惯进行编写，没有统一的命名规则，而且各个小组（管理员）之间的配置项信息没有有效共享，对其他流程没有起到良好的支持作用。
浙江省电力公司科技信息部目前还未有专门的流程电子化平台，依靠手工填写申请表或工作联系单等方式进行流程的流转。SAP系统有自带的solution manager管理平台对服务进行传递，并通过它对主机和数据库系统进行监控。
另外，日常沟通平台主要是利用OA邮件系统以及QQ/MSN等即时通讯工具。


3.2.3陕西省运行情况分析

陕西省电力公司信通中心信息部下设网络组、应用组和终端维护组，分别对网络系统、应用系统和个人终端设备进行管理和提供技术支持。经过多年的建设和运行维护，建立起了一套保障运行、快速提供支持服务的制度和流程。
日常工作中，设立2766服务热线，由终端维护负责接收用户的故障申报和服务请求并将这些事件记录到客服系统中，之后根据事件发生的片区由负责相关片区的技术人员进行处理。如果该人员无法独自解决问题，将根据实际情况做出判断后口头通知网络组或应用系统组的二级支持人员，由他们提供进一步的技术支持直到问题最终解决。               ITSS认证
终端维护组的人员还会对用户的终端设备进行巡检以发现问题并予以解决。除了终端维护组的现场巡检外，网络组也设有转人定时对网络设备、服务器、存储系统以及应用系统的运行情况进行巡检并详细记录每个系统和设备的运行情况。巡检中发现问题，巡检人员首先进行处理，如果无法独自解决问题，则会通知相关的二级支持人员提供进一步的技术支持直到问题最终解决。
对重大或严重的故障，事后要做出故障分析找出原因和解决办法并形成故障分析报告，以备日后查询和参考。
做为管理手段之一，所有人员需要填写周报记录个人每周的工作情况。每月汇总总体的工作完成情况和工作量。在月度会议上会对当月处理的故障情况、项目建设工作进展情况进行回顾和总结。
陕西省电力公司信息化工作的职能管理部门是科信部。具体的信息系统运行维护工作由信通中心的信息部负责。
科信部委托信通中心进行信息系统的运行管理和对基层单位信息系统运行管理的检查，由科信部会同信通中心按照某公司相关标准制定信息系统运行考评要求，信息部具体执行并上报结果。同时科信部还负责省公司信息化建设项目的立项和审批工作。根据情况信息部承担相应的项目建设工作。
在信通中心内部有运行管理部和网络运营部与信息部的关系密切，3个部门分工分别承担电话通讯系统、光纤通讯线缆和网络系统的运行维护工作并在必要时协同解决在这些系统中出现的故障和问题。保障业务部门的正常使用。
信息部在IT运维方面定义了13个流程，覆盖了故障处理、设备变更（新增、拆除、配置变化）、OA程序更新、系统巡检、巡检规范变更、设备出入库、资料借阅几个方面。这些流程均来自信息部多年运维管理工作的经验积累，具有一定的操作性。
故障处理流程由终端故障处理流程、系统故障处理流程组成。分别定义了终端故障处理和系统故障处理的各自时限要求和升级上报要求。
变更管理流程由设备新增流程、设备拆除流程、设备配置变更流程、网络安全设备配置变更流程和巡检规范变更流程组成。分别定义了不同变更需求的责任人、方案审核人以及变更批准人需要处理的工作内容和流程。
系统运行巡检工作流程定义了日常巡检需要完成的内容、流程和时限要求。
视频会议管理流程定义了视频会议系统使用、调试和故障处理的流程和时限要求。
OA程序更新流程定义了新OA程序从交接开始，经过测试到完成上线的流程步骤和时限要求。
设备管理方面设备出入库管理流程定义了新设备入库和设备出库的流程步骤和出库批准人并建立了设备台帐。
资料借阅管理流程对资料的借阅规定了借阅批准人和逾期催还责任人。
上述流程的运转基本没有电子化平台工具的支持。流程运转过程只能够通过记录单进行追踪和统计。统计数据比较困难。
信息部目前还没有电子化的流程平台工具。日常工作中通过手工填写任务单和电话通知的方式进行流程流转。知识共享以在共享文件服务器上存放解决方案、资料为主。最近开始使用StarTeam记录员工的日常工作量。该工具统计功能非常弱，仅做为一个记录工具使用。OA、电子邮件是日常工作沟通的主要平台。
目前信息部已经制定和编写了运维管理的流程和制度并在日常工作中发挥了作用。然而也存在以下这些问题，需要日后逐步完善：
n        目前的电子化平台工具客服系统的使用者是进行终端维护的人员，进行二级技术支持的人员不使用该系统。对于流转到二级技术支持的工单无法在该系统中进行记录。事后无法基于工单流转数据完整复原出整个服务过程的步骤，不利于对服务质量做出相关的分析。
n        由于电子化平台工具功能有限，流程运转的自动化程度不高。流程之间的关联性和相互监督性不够。
n        量化IT服务管理数据困难，多以手工统计为主，KPI量化考核缺少工具支持。
n        有人员培训计划，但执行情况不理想。
n        需要完备知识共享工具以提高知识共享的效率和效果。                ITSS培训
此外，项目建设和日常运维工作交互同时进行，信息部人力资源有限，既要保障项目建设工作的顺利进行又要保障日常运行维护工作顺利开展，对信息部的领导和员工造成了不小的压力。


3.2.4天津市运行情况分析

业务部门信息员与基层单位信息专工
天津市电力公司下设13个业务部门，以及供电分公司、客服中心等近30个基层单位。业务部门和基层单位也有相应的技术人员（信息员或信息专工）负责本业务或本单位的IT服务，与信息技术处共同为各业务部门和基层单位提供IT支持服务。
其中业务部门的信息员收集业务需求、项目管理和开发商联系、协调维护厂商处理应用系统故障；基层单位信息专工配合信息规划及日常基层单位的技术支持。
【启示】
n        一方面，信息员和信息专工是业务部门与科技信息部/信息技术处联系的纽带和沟通桥梁。信息员和信息专工弥补了IT人员对业务难以深入理解业务的欠缺，可以更好地挖掘业务需求。
n        另一方面，作为实质上IT服务支撑组织的一部分，信息员和信息专工渗透到了服务需求的分析和收集、辅助服务设计、协助服务上线、管理和协调应用运维等环节，但信息员和信息专工能力和素质参差不齐，区别较大。另外，作为业务部门的岗位，信息员和信息专工与科技信息部/信息技术处的是相互影响关系，并非受控关系，无法直接考核和管理。从这个方面和国外行业实践来看，未来的最终模式将是由分散走向集中，建立共享的IT服务中心，从而对人力资源、技术资源都更好地统一协调利用。
n        参考ITIL服务级别管理流程，在内部服务支持组织中建立更好的、可重复沟通及约束机制

外部资源
在现有人力资源紧张的情况下，要保证实现信息化有力支撑和推动“一强三优”的企业战略目标实现，外部资源是一个IT服务支撑组织不可忽视的部分。
表格 3‑2 开发商资源及模式

开发商属性
合同签署对象
外部开发商
三产公司
业务部门
✔
✔
科技信息部
✔
✔
业务应用系统开发商是需要关注的资源之一。OA、数据中心、企业门户、财务系统、营销系统、生产MIS等应用系统都涉及不同的开发商。开发商的身份属性也略有不同：有些为行业内知名的外部开发商，有些为天津市电力公司三产公司。
开发商与天津市电力公司的物理关系也因历史因素、业务需要等原因略有不同：经历开发阶段后，因为考虑到后期的维护及产品升级等的连续性，部分开发商直接与业务部门签订维护合同；部分开发商与科技信息部签订维护合同。
同其他企业一样，成型产品厂商也是需要关注和管理的外部资源。因为产品成熟，此类厂商一般具有成熟的维护和支持体系，产品版本和问题管理有其内部较好的管理机制。                           ITIL培训
【启示】
n        服务应当作为一个整体提供给客户，其内部也应有服务负责人（Service Owner）对此服务负责并统一管理；在现有环境中，有些服务应用系统由业务部门与维护厂商签订维护合同，基础架构部分由信息技术处维护，好处是服务的各个组件都有明确的负责人，但缺点也很明显，作为一个统一的整体服务，服务负责人（Service Owner）不明确。
n        参考ITIL服务级别管理流程，通过建立更加明确的约束机制，加强对外部服务支持组织的管理，将信息部门承诺给客户的服务级别指标分解到相应的服务厂商合同。待续







待续：http://ITIL-foundation.cn/thread-50281-1-1.html

本帖关键字：ITSS ISO20000

20150618 MONICAZHANG

续上



3.3运行情况分析



3.2.1总部运行情况分析

信息中心是某总公司领导下的二级单位，承担着某总部（包括西单大楼和白广路大楼）IT基础架构维护、信息系统建设和信息资源的建设的职责。信息中心的主要运维机构由网络控制中心、客户服务中心和汇置通工作组三个部门组成。
客户服务中心：主要负责系统前端的日常维护工作。包括总部和相关单位的桌面维护，协同办公系统(OA)维护、门户网站运行维护、网络管理系统等。客服热线电话是7777和7186。                  ITSS考试
网络控制中心：主要负责系统后端的建设，运行维护工作。目前信息中心的系统维护主要集中在平台级以下，即某骨干网络维护、应用系统平台维护（包括操作系统、中间件、裸数据库）、数据中心、主机维护、以及北京城域网，西单大楼和白广路大楼局域网的维护工作。
汇置通工作部：主要面向在汇置通大厦的某各下属公司在IT运行方面进行进行维护支持。包括：汇置通大楼局域网维护、各单位应用服务器托管服务、维护主机/系统/裸数据库、网络基础应用的维护、协同办公系统(OA)、电子邮件系统、DNS等相关工作。
在长期的运维实践经验积累中某信息中心已经形成了较为完整的服务受理和故障处理流程。有统一的规范和制度，并且在IT服务提供方面与总部形成了较为规范的服务提供合同。
某信息中心目前接受投诉和故障申告的服务对象是某总部的各业务部门和各下属分公司，包括各业务系统平台和客户端故障的处理。处理中三个部门使用不同的流程管理工具执行，根据受理业务不同，形成了不同的处理过程。目前与客户沟通的主要方式是电话，三个部门分别设有各自的业务受理电话，服务受理范围上，网控中心与客服中心主要以职能划分为主，汇置通工作部以服务对象划分为主；服务以5×8小时支持为主，8小时外有值班员处理紧急事件。
在现行的运行管理规定中，针对事件、变更、配置过程有一些制度上的规定，包括运行值班记录、业务受理单、操作单、故障处理记录等均为文档化，并有相应的管理规定，并通过文件服务器共享。                ITSS工具          
没有独立的问题管理流程（与事件管理在一起），系统中的问题在每月的运行分析会上讨论。
运行维护和服务基本围绕网络、业务平台和网络基础应用展开，不涉及客户业务应用的需求管理和开发管理，应用系统自测试、试运行交维，试运行结束验收后正式上线维护。

对于IT管理，信息中心曾建设过两个系统，一个是与网管一起建设的帮助台系统，另一个是东软开发的流程管理平台。
目前网控中心正在使用帮助台系统记录事件，客服中心使用开发的流程管理平台，处理的事件不是全部记入系统，部分事件通过业务受理单、操作单或故障处理单记录流转。

汇置通工作部使用值班记录记录事件。业务受理单用于客户提交服务申告，操作单用于系统变更时的操作处理

三个部门流程基本独立运转，需要协调时通过业务受理单或故障处理单进行转派。

某总部运行情况具有一下特点：

n        IT流程规范执行：目前信息中心已经建立起了比较规范的IT服务流程和制度，并且开发过相关的支持系统。但由于工具的功能不全面，流程记录工作的繁复，实际工作中没有全面的应用起来。IT流程的总体执行效果有待提高，运维人员少，信息没有被记录到系统中，某些情况下导致日常运维难以形成闭环。               ITSS团购
n        项目建设和日常运维工作交互同时进行：目前项目任务工作量大大超过了运维任务。但信息中心人力资源有限，带来了有限的资源和不断增长的项目建设工作量，运行维护工作量间的矛盾。（曾有独立的项目部门，但存在着项目建设后无法移交的困难，最终只能系统和建设人员一起移交。）
n        业务模式转变带来了运维压力：
§ 公司信息化建设要求，以前每月提交管理报告，今后总部希望能够实时看到运维工作的处理结果和处理过程；
§      视频会议、网络直播等实时性的IT服务，对网络带宽、速度和稳定性的要求较高。而且现在在业务运行中，越来越多的使用这些服务；
§      各地的数据中心建设形成数据集中，而数据集中带来的是系统的集中，凸显了运维资源的不足（技术、能力），运维模式急需改变
§      管理制度体系：目前共有几十项制度。从总体上，管理制度没有形成体系。总部信息办的制度和信息中心的制度之间，相互的关联性没有得到体现；现有制度既有面向管理的，也有面向技术。             ITSS软件
n        没有全面使用IT服务管理系统记录日常服务工作：当前运维工作有流程，有记录，有审批。使用纸质载体记录审批，电子文档记录过程的流程运作（操作单），能够满足当前要求；但是工作量统计比较困难、不能进行人员/系统的深入分析，查询、共享和权限管理都很不方便。随着SG186工程建设，运维支持的系统将越来越多，运维工作量越来越大。现有的操作单工作方式将不能满足管理要求，会制约IT服务水平和管理水平的提高。


3.2.2        浙江省运行情况分析

浙江省电力科技信息部目前接受故障申告和服务请求的服务对象是浙江省电力内部的各业务部门客户，包括网络、portal、OA和客户端、桌面故障的处理。目前在省公司已经设立统一的服务台186对客户进行支持，有2名外包人员进行一线的支持，如果一线解决不了将会转到信息安全处相关专责IT人员处理。但是如遇业务系统的问题将不通过186服务台，如业务部门独立找外部厂商开发的业务系统的问题将直接联系外包商处理，如业务系统数据库维护方面的问题，则系统管理员直接联系信息安全处负责此业务系统的IT人员，186服务台的支持服务以7×8小时支持为主。
在现行的运行工作中，针对事件、变更、配置、发布过程有一些制度上的规定，并有相应的管理规定，但是IT人员由于负责领域的不同而划分成不同的小组，每个小组各自有一套流程，因此流程无法统一，知识和资源也无法共享（如知识库只存在于小组内的共享服务器上），产生了以每个小组为单位的信息孤岛现象，同时，即使是有相应的流程和制度，但缺乏实用性，也没有和考核体制挂钩，因此也没被所有维护人员熟悉，不能很好的坚持。事件管理虽然整体执行效果还不错，但对故障的主动发现不多，更多的是在故障发生后进行修复和事后审计；对故障的分类和优先级的判断没有统一的标准，同时对事件发生的处理过程没有有效的记录。
没有独立的问题管理流程，往往是与事件管理在一起，在SAP业务中，问题管理有所体现，但是不清晰。
SAP的变更需要业务部门和技术部门的领导审批，对变更风险和影响有简单的评估，但没有统一的标准，往往是靠每个人自己的经验，变更的质量没有专人控制。                               ITSS体系
对设备等配置项信息有部分记录，但没有在组织中共享，有的配置项信息只有在系统的管理员个人手中才有，命名没有遵循一定的规则，没有配置项信息间的关系记录，不能把事件和IT设备联系起来，也没有管理流程来确保配置信息的定期更新，因此很多不能保证现有数据的准确性和完整性。
存在开发、测试生产环境支持发布管理，但是开发和生产环境比较混乱，经常有功能重复的系统上线，造成了资源的浪费，且没有规范化、严格化的管理流程，导致系统上线后经常需要更改。
目前科技信息部建立了186服务台作为接受故障申告和服务呼叫的窗口，但是服务台受理的范围非常有限，只是负责桌面类故障申告和服务请求的受理，与业务系统相关的事件，用户会直接找负责相应业务系统的管理员申告事件。
桌面类故障申告到服务台后，服务台首先做一线进行处理，一线解决不了，会升级到信息安全处进行二线支持，二线尝试性解决，如遇较大故障需要厂商参与的，会转到三线，即外包商（原厂商）支持。但有的时候，存在着用户绕过服务台直接联系IT人员寻求支持的情况，从而导致186服务台记录事件不全。                        ISO20000培训
业务系统类申告直接找到信息安全处的系统管理员后，管理员会对申告进行处理，对于权限修改，密码设置等服务请求，系统管理员直接进行处理；如果系统管理员判断是用户申告是由故障导致的，系统管理员会对故障等级进行判断，业务系统对事件等级进行了定义，分成重大故障，较大故障，一般故障和一般问题四个级别，重大故障需要向领导汇报，对于如果是需要上报到科技处领导的，系统管理员会上报到科技处领导进行备案，如果不需要则直接进行处理；处理过程中如果需要科技信息部内部员工进行支持的，系统管理员直接去联系相应员工进行协同处理；处理过程中需要厂商支持的，则自己去联系厂商，寻求厂商支持。
对于IT基础架构类事件，没有明确划分出事件的分类和优先级，依靠人为的判断，没有统一的标准。但是基础架构管理员会根据经验判断事件级别，自己认为重大的事件也会上报到领导。
上述的处理过程一般没有进行记录，只有明确了是重大故障级别的事件才会进行记录。
目前科技信息部每个专业小组或管理员会把自己掌握的配置项信息采用电子表格的方式记录下来，在事件处理过程中会参考到这些文档进行信息查询。但是这些配置项信息的文档往往按照自己的个人习惯进行编写，没有统一的命名规则，而且各个小组（管理员）之间的配置项信息没有有效共享，对其他流程没有起到良好的支持作用。
浙江省电力公司科技信息部目前还未有专门的流程电子化平台，依靠手工填写申请表或工作联系单等方式进行流程的流转。SAP系统有自带的solution manager管理平台对服务进行传递，并通过它对主机和数据库系统进行监控。
另外，日常沟通平台主要是利用OA邮件系统以及QQ/MSN等即时通讯工具。


3.2.3陕西省运行情况分析

陕西省电力公司信通中心信息部下设网络组、应用组和终端维护组，分别对网络系统、应用系统和个人终端设备进行管理和提供技术支持。经过多年的建设和运行维护，建立起了一套保障运行、快速提供支持服务的制度和流程。
日常工作中，设立2766服务热线，由终端维护负责接收用户的故障申报和服务请求并将这些事件记录到客服系统中，之后根据事件发生的片区由负责相关片区的技术人员进行处理。如果该人员无法独自解决问题，将根据实际情况做出判断后口头通知网络组或应用系统组的二级支持人员，由他们提供进一步的技术支持直到问题最终解决。               ITSS认证
终端维护组的人员还会对用户的终端设备进行巡检以发现问题并予以解决。除了终端维护组的现场巡检外，网络组也设有转人定时对网络设备、服务器、存储系统以及应用系统的运行情况进行巡检并详细记录每个系统和设备的运行情况。巡检中发现问题，巡检人员首先进行处理，如果无法独自解决问题，则会通知相关的二级支持人员提供进一步的技术支持直到问题最终解决。
对重大或严重的故障，事后要做出故障分析找出原因和解决办法并形成故障分析报告，以备日后查询和参考。
做为管理手段之一，所有人员需要填写周报记录个人每周的工作情况。每月汇总总体的工作完成情况和工作量。在月度会议上会对当月处理的故障情况、项目建设工作进展情况进行回顾和总结。
陕西省电力公司信息化工作的职能管理部门是科信部。具体的信息系统运行维护工作由信通中心的信息部负责。
科信部委托信通中心进行信息系统的运行管理和对基层单位信息系统运行管理的检查，由科信部会同信通中心按照某公司相关标准制定信息系统运行考评要求，信息部具体执行并上报结果。同时科信部还负责省公司信息化建设项目的立项和审批工作。根据情况信息部承担相应的项目建设工作。
在信通中心内部有运行管理部和网络运营部与信息部的关系密切，3个部门分工分别承担电话通讯系统、光纤通讯线缆和网络系统的运行维护工作并在必要时协同解决在这些系统中出现的故障和问题。保障业务部门的正常使用。
信息部在IT运维方面定义了13个流程，覆盖了故障处理、设备变更（新增、拆除、配置变化）、OA程序更新、系统巡检、巡检规范变更、设备出入库、资料借阅几个方面。这些流程均来自信息部多年运维管理工作的经验积累，具有一定的操作性。
故障处理流程由终端故障处理流程、系统故障处理流程组成。分别定义了终端故障处理和系统故障处理的各自时限要求和升级上报要求。
变更管理流程由设备新增流程、设备拆除流程、设备配置变更流程、网络安全设备配置变更流程和巡检规范变更流程组成。分别定义了不同变更需求的责任人、方案审核人以及变更批准人需要处理的工作内容和流程。
系统运行巡检工作流程定义了日常巡检需要完成的内容、流程和时限要求。
视频会议管理流程定义了视频会议系统使用、调试和故障处理的流程和时限要求。
OA程序更新流程定义了新OA程序从交接开始，经过测试到完成上线的流程步骤和时限要求。
设备管理方面设备出入库管理流程定义了新设备入库和设备出库的流程步骤和出库批准人并建立了设备台帐。
资料借阅管理流程对资料的借阅规定了借阅批准人和逾期催还责任人。
上述流程的运转基本没有电子化平台工具的支持。流程运转过程只能够通过记录单进行追踪和统计。统计数据比较困难。
信息部目前还没有电子化的流程平台工具。日常工作中通过手工填写任务单和电话通知的方式进行流程流转。知识共享以在共享文件服务器上存放解决方案、资料为主。最近开始使用StarTeam记录员工的日常工作量。该工具统计功能非常弱，仅做为一个记录工具使用。OA、电子邮件是日常工作沟通的主要平台。
目前信息部已经制定和编写了运维管理的流程和制度并在日常工作中发挥了作用。然而也存在以下这些问题，需要日后逐步完善：
n        目前的电子化平台工具客服系统的使用者是进行终端维护的人员，进行二级技术支持的人员不使用该系统。对于流转到二级技术支持的工单无法在该系统中进行记录。事后无法基于工单流转数据完整复原出整个服务过程的步骤，不利于对服务质量做出相关的分析。
n        由于电子化平台工具功能有限，流程运转的自动化程度不高。流程之间的关联性和相互监督性不够。
n        量化IT服务管理数据困难，多以手工统计为主，KPI量化考核缺少工具支持。
n        有人员培训计划，但执行情况不理想。
n        需要完备知识共享工具以提高知识共享的效率和效果。                ITSS培训
此外，项目建设和日常运维工作交互同时进行，信息部人力资源有限，既要保障项目建设工作的顺利进行又要保障日常运行维护工作顺利开展，对信息部的领导和员工造成了不小的压力。


3.2.4天津市运行情况分析

业务部门信息员与基层单位信息专工
天津市电力公司下设13个业务部门，以及供电分公司、客服中心等近30个基层单位。业务部门和基层单位也有相应的技术人员（信息员或信息专工）负责本业务或本单位的IT服务，与信息技术处共同为各业务部门和基层单位提供IT支持服务。
其中业务部门的信息员收集业务需求、项目管理和开发商联系、协调维护厂商处理应用系统故障；基层单位信息专工配合信息规划及日常基层单位的技术支持。
【启示】
n        一方面，信息员和信息专工是业务部门与科技信息部/信息技术处联系的纽带和沟通桥梁。信息员和信息专工弥补了IT人员对业务难以深入理解业务的欠缺，可以更好地挖掘业务需求。
n        另一方面，作为实质上IT服务支撑组织的一部分，信息员和信息专工渗透到了服务需求的分析和收集、辅助服务设计、协助服务上线、管理和协调应用运维等环节，但信息员和信息专工能力和素质参差不齐，区别较大。另外，作为业务部门的岗位，信息员和信息专工与科技信息部/信息技术处的是相互影响关系，并非受控关系，无法直接考核和管理。从这个方面和国外行业实践来看，未来的最终模式将是由分散走向集中，建立共享的IT服务中心，从而对人力资源、技术资源都更好地统一协调利用。
n        参考ITIL服务级别管理流程，在内部服务支持组织中建立更好的、可重复沟通及约束机制

外部资源
在现有人力资源紧张的情况下，要保证实现信息化有力支撑和推动“一强三优”的企业战略目标实现，外部资源是一个IT服务支撑组织不可忽视的部分。
表格 3‑2 开发商资源及模式

开发商属性
合同签署对象
外部开发商
三产公司
业务部门
✔
✔
科技信息部
✔
✔
业务应用系统开发商是需要关注的资源之一。OA、数据中心、企业门户、财务系统、营销系统、生产MIS等应用系统都涉及不同的开发商。开发商的身份属性也略有不同：有些为行业内知名的外部开发商，有些为天津市电力公司三产公司。
开发商与天津市电力公司的物理关系也因历史因素、业务需要等原因略有不同：经历开发阶段后，因为考虑到后期的维护及产品升级等的连续性，部分开发商直接与业务部门签订维护合同；部分开发商与科技信息部签订维护合同。
同其他企业一样，成型产品厂商也是需要关注和管理的外部资源。因为产品成熟，此类厂商一般具有成熟的维护和支持体系，产品版本和问题管理有其内部较好的管理机制。                           ITIL培训
【启示】
n        服务应当作为一个整体提供给客户，其内部也应有服务负责人（Service Owner）对此服务负责并统一管理；在现有环境中，有些服务应用系统由业务部门与维护厂商签订维护合同，基础架构部分由信息技术处维护，好处是服务的各个组件都有明确的负责人，但缺点也很明显，作为一个统一的整体服务，服务负责人（Service Owner）不明确。
n        参考ITIL服务级别管理流程，通过建立更加明确的约束机制，加强对外部服务支持组织的管理，将信息部门承诺给客户的服务级别指标分解到相应的服务厂商合同。待续







待续：http://ITIL-foundation.cn/thread-50281-1-1.html

本帖关键字：ITSS ISO20000