XXX集团XXX项目IT服务管理需求分析报告.docx

XXX集团XXX项目IT服务管理需求分析报告.docx

《XXX集团XXX项目IT服务管理需求分析报告.docx》由会员分享，可在线阅读，更多相关《XXX集团XXX项目IT服务管理需求分析报告.docx（105页珍藏版）》请在冰豆网上搜索。

XXX集团XXX项目IT服务管理需求分析报告

IT服务需求分析报告

（全部）

文档说明

1项目背景

当今通信市场正由传统的以通信网和市场为中心的竞争转变为以客户为中心的服务质量的竞争。

为在新形势下，利用现有资源，提高现有的维护工作效率，XXX建设了新大楼和亦庄两个XX中心机房，以统一为BSS、OSS、MSS等关键业务系统提供支撑服务，面对BSS、OSS、MSS等关键业务系统的复杂多样性和不断扩充的业务需求，如何保障各业务系统的正常稳定运行，从而确保并逐步提升XX的服务质量，迫切要求建立一个能够对XX机房负责承载的业务系统进行集中监控、集中维护、集中管理的信息安全和网管监控系统。

XX信息安全和网管监控系统应不仅能够对系统的网络边界、核心网段提供安全防护，及时监测并发现各增值业务系统中存在的、潜在的各类问题，以保证系统的稳定运行和业务的正常开展；同时还将对服务和运行维护工作进行规范化、流程化管理。

通过发现、总结和挖掘所存在问题，不断明确管理重点并优化管理流程，从而加强服务和运行维护管理能力、提高服务和运行维护工作效率、改善服务和运行维护工作质量，进而保证各关键业务系统服务质量和运行维护水平的可持续性提升。

2项目运维访谈介绍

2006-2010年XXXX战略的重点是：

以“统一规划、规范管理、分步实施、创造价值“为指导原则，全面开展应用系统的整合、数据中心的整合、以及DCN网络的整合。

伴随数据中心整合的脚步，XX运维集中化也提到了议事日程上。

在运维集中化战略的大前提下项目组在3月针对XX基础架构部分进行了初步的网络、系统和平台的运维现状调研，受到了XX部主管领导的重视，并指出运维工作不能孤立的划分为基础架构或应用等层面，应从服务对象及维护对象着手进行调研，并为XX建成后的统一运维提出可行性的方案作为访谈目标之一。

为了实现建立统一运维体系调研全面的运维现状，项目组于4月进行了运维深度访谈，对XX部所维护的各应用系统软硬件现状、维护现状、维护流程等进行了全面而深入的了解，本文结合访谈现状，进行了需求汇总和差距分析。

访谈记录详见附录

2.1受访者

本次调研中访谈了以下人员：

姓名

职务

访谈日期

2.2文件

本次访谈中获取了以下XXX集团的文件：

文件类型

名称

文件

文件

文件

文件

文件

文件

文件

文件

文件

图表

图表

图表

3运维现状与差距分析

3.1信息系统服务内容清单

3.1.1面向用户服务目录

序号

服务目录

1

系统软件/技术问题咨询

2

系统软件/故障申告

3

系统软件/功能变更开发

4

系统软件/功能配置变更

5

系统权限/新建/删除/变更

6

系统硬件变更：

办公/生产

7

网络故障申告：

办公/生产

8

网络变更：

办公/生产

9

安全管理：

办公/生产

3.1.2运维服务详细内容

软件服务

桌面通用软件

操作系统

IE版本低或被恶意修改

IE打不开二级链接

IE经常死机或自动退出

IE使用或操作类问题

IE无法浏览内网或外网

备份或导数据

补丁版本低

操作中系统报错或蓝屏

带入带出域

更改用户配置文件

共享文件夹类

计算机名称不符合要求

计算机升级重装OS

弱口令

使用方面的咨询

网络设置问题

无法登录系统

系统无法启动

系统运行慢

硬件驱动程序

用户帐号或密码问题

域策略应用问题

其他

常用工具

Acrobat

McAfee问题

MSN问题

Office类问题

超级解霸

解压缩工具

金山词霸

看图软件

其他部门应用系统

输入法

其他

邮件问题

OE中无法收发邮件

outlook使用咨询

POP方式问题

PST文件过大或出错

WEB页邮箱问题

查杀邮件内病毒

打补丁

导出数据、联系人、个人通讯录

导入数据

第三方软件等影响无法发送邮件

更改邮箱名称

共享联系人

共享日历

其他

删除帐号

设置个人签名

使用类咨询

添加其他邮箱

添加新个人文件夹

无法ping通邮件服务器（可以ping通网关）

无法发送某邮件地址

新建帐号

邮件规则类问题

邮件组问题

邮箱已满或被关闭

帐号到期

重新配置Outlook

基础架构软件

中间件

BEAWeblogic问题

tuxedo问题

IBMWebspere问题

MQ问题

BizTalk问题

数据库

Oracle9i

DB2

MSSQL

NCRTeredata

操作系统

Unix

Windows

基础应用平台

安全监控系统

防病毒系统

认证及加密系统

网管系统

应用系统

故障申告/功能变更

BSS

XX计费帐务系统整合（南方一期）

南方客户服务系统

集团客户投诉中心系统

OSS

新网络资源管理系统

原XX控股骨干网资源管理系统

原控股安徽省本地资源管理系统

EAI

XXX业务订单调度系统

EAI联接系统

MSS

ERP系统人力资源管理系统

ERP系统财务资源管理系统

集团门户和办公系统

邮件系统

域管理系统

防病毒系统

系统管理

综合统计信息管理系统

硬件服务

终端外设类

笔记本

借用

领用

回收

声卡

显示卡

其他

台式机

光驱

回收

键盘

借用

联系维修商维修

领用

内存

声卡

鼠标

网卡

显示卡

显示器

硬盘

主板

其他

其他

主机类

故障/扩容/升级/迁移/割接/备份

服务器

Hp

IBM

Sun

Dell

其他

存储

Hp

IBM

Sun

EMC

存储服务器

网络设备

故障/扩容/割接

骨干网（核心、汇聚、接入）

路由器

交换机

Hub

光电转换器

线路

拨号服务器

Modem

局域网（办公、生产、数据中心）

路由器

交换机

Hub

光电转换器

线路

拨号服务器

Modem

负载均衡设备

安全设备

入侵检测

防火墙

机房设备

空调

电源设备

UPS

机房内布线架

机柜

其他硬件设备

网络服务

Ipsecvpn,远程拨号业务服务器端问题

Wlan类

VPN

无法登录VPN

在家中设置拨号

安装VPNClient

其他

网关ping不通

视频会议

网口问题

网线问题

新开网口

用户ping服务器严重丢包

制作网线

DCN网络

MSS网

网控DCN网

其他

安全服务

终端安全

防病毒

Virusscan、EPOAgent软件损坏感染病毒

补丁安装不完全感染病毒

各种补丁（系统补丁，重要临时补丁，Outlook补丁等）安装完全，Virusscan、EPOAgent运行正常情况下感染病毒。

客户端私自安装盗版非法软件感染病毒

客户端用机显示感染病毒，但无法自动清除

域外计算机感染病毒

漏洞攻击

应用系统安全

网络安全

DCN网络安全

3.2维护现状总结与ITSM差距分析

3.2.1事件流程/服务台

✧简介

描述（事件管理）:

管理事件的处理过程以确保尽快恢复到正常的运作。

减小对业务运作的影响。

描述（服务台）:

接收，记录，分类，一线支持，解决和关闭问题；监控跟踪事件并及时进行各方反馈的收集及沟通；改善用户关系，响应时间，与用户沟通和进行有效的团队合作。

为管理层集中提供管理信息。

✧对应关系

对XX部来说事件流程的管理范围应是所有运维工作过程中的突发事件、服务请求、疑问、咨询等，如下表显示哪些用户请求属于事件流程管理范畴

事件管理范畴

服务目录

1

系统软件/技术问题咨询

2

系统软件/故障申告

5

预授权的系统权限新建/删除/变更

6

系统硬件故障：

办公/生产

7

网络故障申告：

办公/生产

8

安全事件：

办公/生产

9

其他用户突发事件请求

✧流程情况：

XX部初步定义了运维管理规程和故障处理流程，但没有明确定义的事件管理流程规范。

上述运维管理规程定义了故障的分级、升级、等运维指标，还定义了如“先局内后局外；先本端后对端；先交换后IP。

先重点后一般；先语音后数据；先调通后修理，故障消除后立即复原”的故障处理原则，并使用适当的记录和文档资料模板辅助流程的执行，包括：

需求变更单模版等。

在实际工作中，由于各应用系统分散运维，运维水平参差不齐，当前的事件处理部分由运维人员手工处理，除重大故障和告警等故障外基本没有事件记录，使得实际的运维处理过程和书面制定的规范有些差异。

事件处理部分有两块业务从人员技能构成到流程管理相对比较完整：

终端支持运维由于较早的投入了ITSM的管理方法及电子工具，目前事件流程相对比较规范，但是由于该电子系统并未延伸到后台管理，使这部分业务在事件流程的整个生命周期中对后台部分的支持管控显得不太有力，造成服务质量的不统一，前后台知识传递不顺畅。

客服系统支持部分有明确的人员分工、故障分级等，但故障记录还采用手工方式，咨询及其他受理并不记录。

这两块的事件管理已经具备基本雏形，有专人专管，并且针对事件流程有绩效考核

在紧急事件的处理的工作细化方面，定义了部分紧急事件处理流程。

在实际工作中，各维护负责人会根据经验判断何种故障为紧急故障，并协调相关资源和及时上报。

在紧急故障处理中，专门明确定义了沟通的方式和方法，明确定义责任体系，按照组织架构中的职责体系进行协调处理。

所有紧急故障或者申告均会进行总结和分析，并有后续行动计划

不是所有的事件均进行记录，终端支持部分是全部来话均进行了记录，客服支持业务是故障均会有详细记录，ERP等有自身的Web网站支持，其他部分业务对于维护人员主动发现的问题或者直接找到维护人员处理的问题，则没有记录，但是重大故障都会有记录汇报故障情况、原因等。

定义了故障的分类和处理时限以及优先级等，但对于事件严重等级和处理时限的定义由故障发起人自己判断，有一定的主观性。

没有专人对事件管理流程负责，部分事件流程基本缺失，没有明确定义的事件流程衡量指标和流程监控。

终端支持有较完整的知识库，但是个文档库，不太方便查阅；其他事件流程暂无知识经验库积累。

✧系统情况：

在流程的工具化层面只有客户端支持有一个hpopenviewhelpdesk作为流程平台；ERP方面有一个可以进行受理、查询、关闭的公开Web网站，但不是一个完整的流程平台。

其他业务均无流程工具支持。

作为日常运维监控的另一个重要方面――系统监控平台和网络监控等，可以实现对事件的主动告警，由于系统分散在不同机房，监控工具随各机房配备监控工具，没有统一的系统监控和安全管理，所以也没有实现监控系统和运维管理平台之间的集成。

✧人员情况：

在日常运维工作分工方面，各业务分散运维，没有统一模式，除客服系统运维7×24外，其他业务运维基本上都是5*8，XX运维人员主要承担系统管理、协调内部业务部门及开发厂商、代维厂商的职责，应用运维按应用系统种类划分，基础架构运维按网络、主机、数据库、存储等IT领域划分岗位；硬件主要有原厂商的维保，软件及应用维护主要由代维厂商实际执行。

✧优势与主要问题：

内部IT客户端支持及客服系统支持人员结构相对较完整，业务成熟度高，积累了丰富的流程经验。

有部分电子化的监控和运维管理平台，大部分故障均有详细的申告记录和处理记录。

但同时也存在一定的问题，如监控平台和服务管理平台之间的集成上，经常由于同一个问题引发告警风暴。

除客户端支持外其他业务基本没有专人对事件管理流程负责，没有对于流程的衡量和考核指标，在流程的电子化平台执行中存在一定的问题，如对事件的及时处理缺乏考核。

该平台基本上是一个工作流处理平台，也就没有和其他流程之间衔接的说法。

3.2.2问题流程

✧简介

描述:

事件控制，问题控制，错误控制，上报，症结原因分析和预防性管理确保预防问题的发生，如果问题已经发生，则预防其再次发生。

问题管理为管理层提供有价值的管理信息。

✧流程情况：

目前在运维工作中未明确将事件和问题进行区分，没有专门的问题管理规范流程。

也没有专门的人员从事该流程管理工作。

但在实际操作上，客户已经有了一些初步的问题和事件的划分概念，并在实际工作中尝试。

如存在部分与问题管理相关的活动和工作要求，如故障处理原则中“先调通后修理，故障消除后立即复原”就是要求在故障处理中，在采取一定措施恢复服务后，再进行深层原因的分析和彻底查找解决方案和规避措施，同时会提交故障分析报告，并据此进行其它潜在问题的研究和预防。

由于缺乏正式的衡量点，目前的工作主要是依赖运维人员的经验和意识进行，处于自发状态。

从主动性问题防范的角度，目前重复规律性的事件和趋势分析主要依赖对运维人员和代维厂商的的经验和主动工作意识，没有明确的流程活动定义。

从实际工作的角度，运维人员对于重大问题均会进行问题根本原因的查找、解决方案实施、处理结果汇报等工作，但没有采用专门的问题分类、分级解决方法，可能导致资源使用和解决方案有效利用方面的欠缺。

没有专门针对性的问题流程管理和责任人，也没有流程的监控和优化活动。

事件流程和问题流程之间有一些自发默认的流程衔接。

对于问题的根本原因分析后，会发起变更来解决问题，但没有明确的流程衔接定义。

✧人员情况：

基于XX部组织架构和流程的现状，没有设立专门的问题经理。

一般由维护人员担负问题处理专家的职责。

✧系统情况：

随着XX的建设，集中的网络和安全监控系统将会为问题的预防和发现提供便捷的信息平台。

在维护管理平台方面，现有的终端业务运维管理系统中没有区分事件和问题，将事件和问题统一处理。

其他应用业务没有运维系统，也就谈不上对问题管理的系统支持了。

✧优势与主要问题：

没有对问题和事件有比较清晰的划分，基本都没有问题管理流程，大家处理问题的模式基本都是被动管理，即有了问题，通过主管经理召开会议讨论的方式进行。

处于一种初始的状态，更谈不上完善的流程和流程监控。

应持续对运维人员灌输问题管理的相关概念和内容，树立问题管理的意识。

需要对所有重大问题均深入进行分析，对分析结果通过变更进行改进等。

针对标准的问题管理的要求，缺乏针对问题的分类、解决优先级、分析结果。

缺乏流程规范，流程负责人以及流程的衔接。

3.2.3变更流程

✧简介

描述:

变更记录，影响评估，时间安排，计划与实施。

有效地制定变更决策并安排工作进度。

提高分布式企业中变更的可视性和通报能力。

减少变更带来的负面影响。

✧对应关系

变更管理范畴

服务目录

1

系统软件/功能变更开发

2

系统软件/功能配置变更

5

须审批的系统权限新建/删除/变更

6

系统硬件变更：

办公/生产

7

网络变更：

办公/生产

8

安全管理变更：

办公/生产

9

其他IT环境内的变更

✧流程情况：

从流程规范的角度看，XX部没有设计和定义统一的变更管理流程。

但各应用系统都有类似的文档来描述需求功能等变更管理流程，如需求变更流程、系统割接管理规范和软件版本管理规范。

为配合应用软件版本、需求变更的变更管理流程执行，还定义了一系列的辅助表格工具，如《软件版本升级需求申请表》、《需求申请单》和《需求变更完工单》等模板。

实际工作中，没有严格按照该流程规范执行，各应用的变更基本上使用一个约定俗成的模式进行，如果认为对前台业务有影响，均有实施方案、计划以及测试方案，测试报告等，需要按照变更内容向有关的部门提交申请并得到批准后实施，实施前会向影响用户发布变更影响通知。

现有范围的应用系统的变更管理流程主要有业务部门发起，IT组件的变更由维护人员负责，没有设定明确的流程责任人负责对流程的使用效果、范围进行监控和提升。

从流程衔接的角度，在变更处理中，会用到一些配置信息，没有流程或者工具支撑。

✧人员情况：

没有正式定义变更流程经理的职责，任何人员都可以根据情况发起变更，召集相关部门开会讨论。

在规划、协调，实施过程中各级运维部门和系统集成商均会涉及其中。

✧系统情况：

没有工具支撑。

对于重大的影响前台业务的变更，一般会通过OA系统发布变更通知。

✧优势与主要问题：

针对应用系统的新版本发布有流程规范，重大IT基础架构的变更有割接管理流程，总的来说，对于影响到一线前台业务的变更控制有约定俗成的变更流程，但对于一般的变更没有流程控制。

没有一个统一的变更管理流程规范，各个应用业务均制定了有关变更方面的流程。

由于有些应用系统的IT设备位于其他部门机房托管，其IT组件和应用系统的变更完全独立。

变更管理和其他流程没有定义的流程衔接，但实际工作中，均会有事件或者问题引发变更，变更处理中，可能会修改配置。

3.2.4配置流程

✧简介

描述:

验证，控制，状态管理，项目验证（硬件，软件，人员，位置，文档，业务流程），构成IT环境及现有环境中的相互关系；提高IT资产管理水平，更好地支持变更管理；改善事件与问题管理；便于评估法规条例的依从状况。

✧流程情况：

XX部尚未定义配置管理流程，实际工作中仅完成了部分资产管理的工作。

当前的配置管理基本上处于各小组范围内进行配置管理工作，没有配置管理的策略，配置信息基本在各管理员自己掌握，配置信息的详细程度，对运维支撑的程度没有统一的标准，而且存在大量配置信息与原有存档不一致的情况，对那些IT组件进行配置管理以及管理到什么程度没有定义，完全处于相关IT组件负责人的个人能力。

从整体上看，没有完整的配置管理流程，也就没有与其它运维流程形成明确的衔接。

从访谈上看，IT组件的管理员普遍意识到配置管理在日常运维工作中的重要性，并且希望在本期项目中能帮助他们初步建立统一CMDB。

✧人员情况：

XX部目前没有定义配置管理的专门角色。

在现有情况下主要配置信息在各管理员手中，有一部分在代维厂商处管理。

但上述所有的管理工作主要依赖于系统负责人的经验和意识。

从流程上看，处于较为欠缺的状态

✧系统情况：

所有的配置信息均保存在相关配置项负责人自己手中，但没有完整意义上的配置管理电子系统。

✧优势与主要问题：

配置管理的工作在实际工作并未开展，各IT组件负责人掌握一部分配置信息，对部分关键IT组件有统一的命名规范和标签。

但没有完善的配置管理流程规范，尚没有将其与其他运维流程，如事件/故障等管理流程相衔接。

技术信息的配置没有统一要求。

由系统或业务应用的支持人员根据自己的经验进行管理。

但各IT组件负责人已经意识到配置管理的重要性，在配置管理推广上应会起到正面的作用，但仍需加强运维人员的配置管理理念。

实施配置管理的初始化工作较艰巨。

4本期需求分析

4.1本期实施范围和运维管理模式

结合上述运维现状及本期项目就是要保障XX自身运维管理的运维目标，如下图所示：

附图1.近期建设范围

首先保证XX建成后其内部运维管理的覆盖是全面的，流程是顺畅的，能达到协调各责任人快速处理XX内部运维突发事件恢复服务的第一目标。

另外根据XX部运维集中的规划，将在本期建立统一接入的客户受理接口，将对XX部目前所支持的业务服务和内部IT客户的受理接口统一，实现用户满意度的提升，服务质量的监督等。

这也是充分契合XX集团“服务编织未来”的企业理念，是XX集团对内部及外部的运维支持趋近于统一的明智之选。

如上图所示的红色‘T’字型部位即是本期实施的重点，‘T’字型框架也是未来实现统一的IT服务支撑体系的骨架，随着本期项目的顺利开展，伴随应用系统的整合和DCN网络的整合，将会分期分批的不断在骨架中填充更多应用系统的支持，在建设中不断校正。

附图2.目标运维业务模式

如上图所示依据信息化建设规划建立全面的统一的服务台是XX信息系统服务支撑体系建设的目标之一，作为各系统、用户受理的单一联系点，全面支持网管/安全突发事件、客户端桌面支持业务、客服系统支持业务，及其他各专业应用系统的支持受理工作，并围绕统一受理平台展开各管理流程的建设和推广工作，将规划中的流程虚拟角色定义在日常运维工作中得以实现。

4.2本期XX运维管理实施内容

综上本期的实施范围建议：

❑运维电子化平台的部署

-平台功能的需求分析

-平台的安装、部署

❑统一受理平台的建设

-建设统一受理服务台

-接受来自客户端、客服系统、其他应用系统及DCN网络用户的服务受理

❑事件管理流程的部署

-XX系统突发事件流程设计、实施

❑问题管理流程的部署

-XX系统问题流程设计、实施

❑配置管理流程的部署

-XX配置流程设计、实施

-XX配置信息管理库建设

❑变更管理流程的部署

-XX变更流程设计、实施

❑运维服务管理平台与监控管理平台/安全管理平台接口的实现

-运维服务管理平台能够接受来自于监控管理平台和安全管理平台的事件信息，然后按照事件管理流程进行处理，当处理结束后，将反馈信息返回给监控管理平台或安全管理平台中。

-运维服务管理平台能够接受来自于监控管理平台的配置信息，且当运维服务管理平台的配置信息发生变动后，能够将该变动信息发送到监控管理平台中。

-服务管理平台提供查看CI的接口。

❑运维服务管理平台与其他管理系统接口的实现

-服务管理平台可以发送信息到邮件系统

4.2.1运维电子化平台的部署

作为有效支撑服务体系建设的工具化手段，将使用BMC公司的Remedy产品在本期建设XX运维管理平台，系统部署如下图所示：

4.2.2统一受理服务台

4.2.2.1服务台现状

目前XX部服务台情况如下表所示：

应用系统

电话号码

是否使用呼叫中心设备

有无电子工具支持

运维模式

终端桌面支持

是

有hpopenview

5X9

客服系统支持

是

无

7X24

ERP系统支持

否

有ERPWeb网站

5X9

其他专业系统

否

无

5X9

利用现有呼叫中心设备的IVR支持如下示意：

4.2.2.2本期建设统一受理服务台方案比较

✧方案一：

↘设置统一服务台热线，现有呼叫中心利旧

利用现有排队机、IVR、CTI设置一个XX部对外统一服务热线，如1234，或将现有XX号码设置为统一服务热线，对拨打用户来说收听相应的IVR语言留言进入不同的技能支持组，对外既是统一受理服务台

↘配备服务台人员

配置专职的服务台人员，受理除客户端支持、客服系统支持外的其他应用系统和IT问题，该服务台受集团信息化部直接管辖。

客户端支持、客服系统支持及新设立的统一服务台人员构成了信息化部统一服务台

↘修改IVR语音，增加‘其他系统问题’

修改现有CTI设置，在语言引导中加入其他系统支持的语音留言，并将该语音配置到新设置的服务台人员受理

↘新建其他系统问题服务台支持人员使用本期流程平台系统

终端支持、客服支持仍采用现有支持方式，在本期不做改变。

‘其他系统问题’全部记录在本期Remedy流程平台系统上，但不依赖于平台处理，分派处理等环节不在系统中实现，闭环于帮助台，对申告用户