（工商管理专业论文）ITIL最佳管理实践应用分析——以CM银行软件开发中心为例.pdf

l 论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独 立进行研究工作所取得的成果。除文中已经注明引用的内容外，本论 文不包含任何其他个人或集体已经发表或撰写过的作品成果。对本文 的研究作出重要贡献的个人和集体，均己在文中以明确方式标明。本 人完全意识到本声明的法律结果由本人承担。 学位论文作者签名：至殷砂鸟 嗍：1 月哆日 学位论文使用授权声明 本人完全了解中山大学有关保留、使用学位论文的规定，即：学 校有权保留学位论文并向国家主管部门或其指定机构送交论文的电 子版和纸质版，有权将学位论文用于非赢利目的的少量复制并允许论 文进入学校图书馆、院系资料室被查阅，有权将学位论文的内容编入 有关数据库进行检索，可以采用复印、缩印或其他方法保存学位论文。 学位论文作者签名：多面溯各 导师签名：? 苏兹5 计 日期：加厂月乙 日 日期：冲r 月二弓日 专业：工商管理硕士 硕士生：王晓鹏 指导教师：张宏斌副教授 摘要 用分析 中心为例 c m 银行已在2 0 0 4 年完成数据集中，并建立了6 个开发中心，进行银行信 息系统的建设。伴随着信息系统建设规模的扩大，i t 系统f 1 趋复杂，业务对i t 的依赖越来越大，随之而来的是业务部门对i t 服务支持、i t 服务提供能力要求 的提高。如何规范服务标准，提高服务质量，提升服务水平，成为开发中心面临 的主要问题。 本文使用解释型案例研究方法，旨在分析c m 银行广州开发中心i t 服务管 理现状的基础上，对i t i l 最佳管理实践在开发中心的应用进行研究。本文首先 阐述了i t 服务管理理论，介绍了i t i l 最佳管理实践的主要内容；然后描述开发 中心的管理现状，并着重对开发中心管理中存在的问题、实施i t 服务管理的迫 切性进行了分析；最后通过i t i l 应用的具体实施，解决开发中心的i t 服务管理 问题。 本文希望通过c m 银行广州开发中心i t i l 的应用实施，可以实现开发中心 客户满意度的提升、服务流程的改善以及知识系统的建设等目标。同时希望通过 对i t i l 最佳管理实践服务模式及应用的分析，能够为c m 银行其它开发中心、 其它企业内部i t 组织的i t s m 实施起到借鉴作用，为国内i t 服务行业在i t i l 基础上的规范化、标准化建设提供案例参考。 关键词：i t 服务管理，服务，流程，i t i l t h ea p p l i c a t i o na n a l y s i so fi t i l c mb a n k d e v e l o p m e n tc e n t e r a sa ne x a m p l e m a j o r ：m a s t e ro fb u s i n e s sa d m i n i s t r a t i o n n a m e ：w a n gx i a o p e n g s u p e r v i s o r ：p r o f e s s o rz h a n gh o n g b i n a b s t r a c t c mb a n kh a sc o m p l e t e dd a t ac e n t r a l i z i n ga n ds e tu ps i xs o f t w a r ed e v e l o p m e n t k e y w o r d s ：i ts e r v i c em a n a g e m e n t ，s e r v i c e s ，p r o c e s s e s ，i t i l i i i 目录 摘要1 a b s t r a c t 。il 目录i v 第1 章绪论1 1 1 研究背景1 1 2 研究方法2 1 3 研究意义2 1 4 结构安排3 第2 章文献综述4 2 1i t 服务管理综述4 2 2i t i l 最佳管理实践综述5 2 3 本章小结8 第3 章c m 银行广州开发中心现状分析9 3 1c m 银行i t 战略9 3 2 开发中心简介9 3 3 开发中心定位9 3 4 组织架构及职责说明1 0 3 5 项目管理制度1 1 3 6 运维管理制度1 5 3 7 绩效管理制度1 6 3 8 日常管理制度1 7 3 9 开发中心现存管理问题分析1 7 3 1 0 本章小结2 0 第4 章c m 银行广州开发中心i t i l 实施方案2 1 4 1 开发中心i t i l 实施目标2 1 4 2 开发中心i t i l 实施总体方案2 1 4 3 服务台管理分析2 4 4 4 配置管理分析2 6 4 5 事件管理分析2 9 4 6 问题管理分析3 3 4 7 变更管理分析3 5 4 8 发布管理分析3 7 4 9 知识库管理分析3 8 4 1 0 本章小结3 9 第5 章c m 银行广州开发中心i t i l 实施结果4 0 5 1 开发中心i t i l 实施结果4 0 5 2 开发中心i t i l 实施收益4 0 5 3 开发中心i t i l 实施中存在的问题4 2 5 4 启示和建议4 4 i v 5 5 本章小结4 5 第6 章结论与展望4 6 参考文献4 7 附录4 9 后记5 1 v 第1 章绪论 1 1 研究背景 进入2 1 世纪以来，随着企业对i t 服务依赖程度的加深，i t 和i t 部门已经 成为企业中必不可少的组成部分，i t 部门的职能也由i t 技术提供者逐渐转变为 i t 服务提供者。职能的转变，不管从主观上，还是客观上都要求i t 部门从i t 技 术管理向i t 服务管理模式转变。 i t 基础构件库“i t i l ( i ti n f r a s t r u c t u r el i b r a r y ) 是为提高i t 服务管理水平 而总结出的最佳实践。i t i l 自上个世纪8 0 年代后期在英国建立以来，已经成为 i t 领域的最佳实践指南，它包含了一个完整的框架，描述了各个流程的目标， 总体活动、输入输出等，供i t 组织借鉴。经过多年的发展及众多公司的参与， i t i l 逐渐完善起来，其框架体系已被证实适用于所有产业部门的组织，成为i t 服务管理领域的事实标准。 近年来，c m 银行信息系统的建设规模不断扩大，i t 系统日趋复杂，业务对 i t 的依赖也越来越大。而c m 银行广州开发中心从省行科技部门转型而来，人 员、制度基本照搬自省行科技部，但工作职责、定位、服务对象却存在很大的区 别，比如，省行科技部服务于省行业务部门，面向全省银行客户，而开发中心服 务于总行业务部门，面向全国银行客户；又比如，省行科技部门作为省分行唯一 的i t 部门，具有绝对的垄断地位，而广州开发中心作为六大开发中心之一，则 必须时刻考虑着开发中心间的竞争、开发中心的生存、如何争取更多的支持和资 源等问题。 在新的形势下，步l ：发中心的服务级别、服务质量、服务响应时间等都需要有 非常大的提高，急需引入i t 服务管理机制，以建立适应银行业务发展和i t 管理 需要的服务管理流程，提高i t 管理的质量和效率，提升i t 应用水平以及业务部 门与外部客户的满意度，激发员工士气，并促使i t 转变成为银行业务发展的驱 动力。而i t i l 为i t 服务管理提供了综合的、一致的最佳实践方法论，因而在开 发中心引入i t i l 也就顺理成章了。 1 2 研究方法 案例研究是一种经验主义的探究( e m p i r i c a li n q u i r y ) ，它研究现实生活背景 暂时现象( c o n t e m p o r a r yp h e n o m e n o n ) ；在这样一种研究情境中，现象本身 背景之间的界限不明显，( 研究者只能) 大量运用事例证据( e v i d e n c e ) 来 研究( r o b e r tk y i n ，2 0 0 4 ) 。解释性案例研究的目的在于对现象或研究的发 行归纳，并最终做出结论。解释性案例研究适于对相关性或因果性的问题进 察，解释型案例研究侧重于理论检验( t h e o r y t e s t i n g ) ，适用于运用已有的 理论假设来理解和解释现实中企业实践活动的研究任务。 本文使用解释型案例研究方法，对i t i l 最佳管理实践在c m 银行开发中心 的应用进行案例分析。在本文中，首先阐述了i t 服务管理理论，介绍了i t i l 最 佳管理实践的主要内容；然后描述开发中心的管理现状，并着重对开发中心管理 中存在问题、实施i t 服务管理的迫切性进行了分析；最后通过i t i l 应用的具体 实施，解决开发中心的i t 服务管理问题。 1 3 研究意义 i t 组织，不管它是企业内部还是外部的，都是i t 服务提供者，其主要工作 就是提供低成本、高质量的服务( 孙强，左天祖，刘伟，2 0 0 4 ) 。如何提供低成 本、高质量的服务，一直是困扰i t 组织的问题。尽管i t i l 详细描述了i t s m 各 大流程的概念、功能、主要活动、成本效益、关键绩效指标以及关键成功指标等， 但并未阐述i t s m 应该如何具体实施。 本文希望通过对c m 银行广州开发中心现有i t 服务管理模式的分析，以i t i l 最佳管理实践为指导，制定开发中心的i t 服务管理实施方案。通过方案的实施， 可以实现开发中心客户满意度的提升、服务流程的改善以及知识系统的建设等功 能。同时希望通过对i t i l 最佳管理实践服务模式及应用的分析，能够为其它企 业内部i t 组织的i t s m 实施起到借鉴和指导作用，为国内i t 服务行业在i t i l 基础上的规范化、标准化建设提供案例参考。 2 1 4 结构安排 本文旨在分析c m 银行广州丌发中心i t 管理现状的基础上，探讨i t i l 服务 管理理念在开发中心的应用，设计开发中心的i t 服务管理实施方案，并对目前 实施中发现的问题进行阐述。 本文共分六个部分。 第一章绪论，阐述了论文的研究背景、方法和意义。 第二章文献综述，介绍了i t 服务管理、i t i l 最佳管理实践的理论模型，以 及当前国际上对i t 服务管理、i t i l 最佳管理实践的理论分析、应用实践，并描 述了i t i l 对i t 服务管理的框架定义。 第三章开发中心现状描述，介绍c m 银行i t 战略、开发中心定位，以及c m 银行开发中心现存的组织架构、各部门的工作职责，和项目、运维、绩效、日常 等各项管理制度。在丌发中心现状描述的基础上，分析了开发中心现行服务管理 制度中存在的问题，面临的挑战和变革要求。 第四章开发中心i t i l 实施方案设计，以i t i l 最佳管理实践为指导，根据 c m 银行i t 战略及开发中心定位、现存的问题，设计开发中心的i t 服务管理实 施总体目标、总体方案、部门职责、服务目录、关键指标，并描述了服务台、配 置管理、事件管理、问题管理、变更管理、发布管理等模块的实施考虑、实施细 节。 第五幸开发中心i t i l 实施结果分析，分析了i t i l 应用方案在开发中心的实 施结果及实施中各模块出现的问题，并提出了i t i l 实施的启示和建议。 第六章结论与展望，总结i t i l 应用实施的结论，对实施方案的前景、效果， 以及推广的价值提出看法。 第2 章文献综述 2 1 i t 服务管理综述 i t 包括基础设施( 硬件、网络) 、软件( 系统软件、应用软件、中问件和数 据库) 以及文档等。 i t 服务属于服务的范畴。所谓i t 服务，是指是由i t 服务商提供的，综合利 用人力、软件等资源以满足客户的i t 需求，并以让客户感觉协调一致的方式满 足客户的一种或多种需求的应用系统或功能，是在对基础设施及软件系统进行开 发、维护、运营等全面管理的过程中向客户交付的服务。世界i t 研究与咨询机 构加特纳集团( g a r t n e rg r o u p ) 将i t 服务市场划分为七类，分别是硬件支持与 维护服务，软件支持与维护，系统集成，i t 咨询，i t 外包，i t 教育与培训以及 网络服务。 g a r t n e rg r o u p 认为：i t 服务管理是一套通过s l a ( 服务级别协议) 来保证 i t 服务质量的协同流程。它融合了系统管理、网络管理、系统_ 歼发管理等管理 活动以及变更管理、资产管理、问题管理等许多流程理论和实践。 而i t s m 领域的国际权威组织i t s m f ( 国际i t 服务管理论坛) 则认为i t s m 是一种以流程为导向、以客户为中心的方法，它通过整合i t 服务与组织业务， 提高组织i t 服务提供和服务支持的能力及其水平。i t s m 的核心思想是，i t 组 织，不管它是企业内部的还是外部的，都是i t 服务提供者，其主要工作就是提 供低成本、高质量的i t 服务。而i t 服务的质量和成本则需从i t 服务的客户( 购 买i t 服务的) 和用户( 使用i t 服务的) 方加以判断。i t s m 也是一种i t 管理。 不过与传统的i t 管理不同，它是一种以服务为中心的i t 管理。传统i t 管理与 i t s m 的区别如图2 1 所示： 4 传统i t 管理转变 i t s m 技术导向 流程导向 救火队_ 预防为主 被动一 主动 集中式，企n k 自己完成_分布式，外包 孤立的，分散的_集成的，企业范围的 一次性的，混乱的可重复的，职责明确的 非正式的流程_正式的最佳实践 从i t 部门内部考虑一 从业务角度考虑 具体的运营 一i b _ 面向服务的 图2 一l传统i t 管理与i t s m 管理的区别 资料来源：王英，2 0 0 6 还有人把i t s m 称作是i t 管理的”e r p 解决方案”。它将i t 技术支持转化为 可计价的i t 服务，实现企业的i t 部门从成本中心向服务中心和利润中心转化； 它不是以职能为中心，而是以流程为中心，从复杂的i t 管理活动中梳理出核心 的流程，将这些流程规范化、标准化，明确定义各个流程的目标和范围、成本和 效益、运营步骤、关键成功因素和绩效指标、有关人员的责权利，以及各个流程 之间的关系，实现i t 部门运营模式的转变。 归纳起来，实施i t s m 的根本目标有：以客户为中心提供i t 服务；提供高 质鼍、低成本的服务；提供的服务是可准确计价的。 2 2i t i l 最佳管理实践综述 全球i t 服务管理领域的标准组织i t i l ( i n f o r m a t i o nt e c h n o l o g yi n f r a s t r u c t u r e l i b r a r y ，i t 基础设施库) 则认为，i t 服务管理是以流程和服务为中心的管理方法。 通过管理i t 服务，以满足客户的需求( 博恩，2 0 0 6 ) 。 i t i l 足一套被国际上大公司普遍采用的实施i t 服务管理的行业标准。i t i l 以流程为导向、以客户为中心，通过整合i t 服务与企业业务，提高了企业的i t 服务提供和运行管理的能力和水平。i t i l 基于交付高质量的i t 服务、关注客户 关系的i t 服务模式，采用模块化、框架式设计。i t i l 框架共分为六个模块。i t i l 框架模式的中心是服务管理模块，其又分两个核心部分：服务支持和服务提供。 图2 2i t i l 总体架构图 资料米源：p a u l g r a h a m ，2 0 0 2 ( 1 ) 服务管理 服务管理是i t i l 框架的心脏。服务提供( s e r v i c ed e l i v e r y ) ，从客户需求角 度描述满足其业务运作的服务及提供这些服务所需要的资源。服务提供包括：服 务级别管理、i t 服务财务管理、能力管理、i t 服务持续性管理和可用性管理。 服务支持主要讨论客户如何获得可以支持他们活动或业务的服务，以及怎样支持 这些服务。服务支持包括：服务台、事件管理、问题管理、配置管理、变更管理、 发布管理。 ( 2 ) 安全管理 随着互联网技术的飞速发展，i t 安全管理尤为重要。i t 基础设施每时每刻 都面临着黑客、病毒的侵扰与破坏。通过安全管理可以保持信息的机密性、完整 6 性和可用性。安全管理的目标是基于服务级别协议来制定的，同时与服务合同、 法律法规及其组织政策相匹配。 ( 3 ) i t 基础设施管理 i t 基础设施的稳定性关系到i t 服务的每个细节。i t 服务管理中的流程、组 织和工具与i t 基础设施紧密相关；然而，i t 基础设施的部署又必须以合理的成 本满足业务的需求。i t 基础设施管理流程主要包括：i t 基础设施的设计、规划、 部署、运营和技术支持。 ( 4 ) 应用管理 应用管理是负责管理与业务相关的i t 应用系统，并提供非中断的服务。在 应用系统的整个生命周期都需要进行严格管理，包括对应用系统的开发、运营管 理和维护管理。 ( 5 ) 服务管理规划与实施 i t 规划与实施维系到i t 服务管理的成败，同时也决定企业战略目标是否可 以实现。借鉴最佳的实践案例和经验，合理地规划i t 资源、完善i t 实施流程， 进一步实现企业的、业务目标。 ( 6 ) 业务视角 业务视角主要包括：业务持续性管理、合作和外包、在进行激进式变更时如 何承受变更以及实现业务实践的适应性转换。 ( p a u lg r a h a m ，2 0 0 2 ) i t i l 服务模式是基于i t 服务产业内的最佳实践( b e s tp r a c t i c e s ) ，基本上可 以覆盖i t 服务组织大部分的活动。i t i l 出版物涵盖了广泛的i t 服务主题，可以 成为i t 组织的有益参考，组织可以通过使用i t i l 服务模式来为其自身设定改进 目标，并得以发展。i t i l 的书籍中描述了大量的术语，i t 人员通过恰当地适用 这些术语，有助于他们更好地沟通和相互了解；i t i l 为服务管理提供了综合的、 一致的最佳实践，描述了一整套业务部门如何使用i t 系统提高业务效果和效率 的高质量方法；i t i l 描述了服务管理的轮廓模型，描述了各个流程的目标、活动、 关键成功因素等，供i t 组织借鉴。不论企业i t 组织目前在服务管理方面采取何 种方法和实践，都可以应用i t i l ，并可以此增强各流程之间的关系，减少甚至消 除由于不同i t 职能部门缺乏沟通和协作带来的弊端。 2 3 本章小结 本章介绍了i t 服务管理、i t i l 最佳管理实践的理论模型，以及当前国际上 对i t 服务管理、i t i l 最佳管理实践的理论分析、应用实践，并描述了i t i l 对i t 服务管理的框架定义。下面章节将分析丌发中心现状及存在的问题，在此基础上， 结合i t 服务管理理论，以i t i l 最佳管理实践为指导，制定开发中心i t 服务管 理实施方案。 第3 章c m 银行广州开发中心现状分析 3 1c m 银行i t 战略 c m 银行的i t 总体战略规划为：贯彻落实全行发展战略，加大i t 资源整合 及统一管理力度，加快建立总、分行一体化的i t 服务管理体系，以客户为中心， 全面提升服务和创新能力；加大应用丌发力度，加速业务价值的实现，促进工作 效率、市场竞争力和经营管理水平的提高；做好生产环境基础设施的建设，建立 健全信息安全体系，保障业务的安全运行。 3 2 开发中心简介 c m 银行已在2 0 0 4 年完成数据集中，并建立了6 个开发中心，分别位于北 京、上海、广州等地，进行银行信息系统的建设。c m 银行广州开发中心( 以下 简称丌发中心) 属于总行i t 管理部下属的二级部门。丌发中心日常工作主要是 根据总行各、比务部门提出的j i k 务需求，进行软件开发，以及相关系统的运行维护。 开发中心现共有6 7 人，其中主任1 人，副主任2 人，下设综合业务管理部、 银行业务部、项目管理与质量控制部等行政管理部门，以及若干项目开发团队。 软件项目采用采购合作公司技术支持服务的形式合作开发。 3 3 开发中心定位 在总行i t 管理部领导下，开发中心坚持“瞄准国际一流，加大创新力度， 打造系统品牌，提升专业能力”的工作思路，以“国内领先，国际一流”为目标， 进一步推进电子渠道技术创新，致力于打造渠道系统品牌。 按照总行技术部的统一部署，开发中心将以“保安全、突亮点、抓规范、创 品牌”为总体工作思路，建设“三零工程”“零发生重大故障、零发生重大 违规、零发生重大缺陷”，进一步强化项目运行管理，调整渠道项目部署，全力 推进项目建没，全面导入c m m i 管理，建立规范管理文化，深化内部管理，改 进j 作作风，加强客户体验。 9 图3 一l 开发中心组织架构 资料来源：开发中心管理制度，2 0 0 8 3 4 2 各部门职责说明 综合业务管理部职责包括：日常管理( 制度制定完善、计划审订督办、工作 跟踪督办、中心会务管理、员工考勤管理、组织人员考核、人员借调录用、中心 后勤管理) ；公文流转( 公文传递、分流、归档、保密，整理报送计划、报表、 1 0 总结，中心公文起草、核稿、督办) ；财务管理( 财务办法制定和完善、财务预 算编制与执行、财务出纳与会计核算、薪酬体系执行与管理、财务成本核算与控 制) ；财产管理( 财产采购以及账实管理) 。 项目管理与质量控制部工作职责包括：项目计划( 编制中心年度开发计划， 组织协助项目立项工作) ；项目管理( 落实、执行总行项目管理规定，制定中心 项目管理办法及细则，项目进度管理，项目沟通管理，组织项目考核，举办技术 交流活动) ；项目监理( 制定中心项目监理办法及细则，对项目组进行项目监理， 组织开展项目监理活动) ；质量控制( 制定中心质量控制办法及细则，制定质量 控制活动形式，组织丌展质量控制活动，跟踪解决质量控制问题) 。 银行业务部工作职责包括：业务需求( 组织或参与业务需求提出，组织或参 与业务需求分析，协助业务需求概要设计，协助业务需求详细设计) ；业务测试 ( 组织或参与业务测试，组织或参与编写测试案例，提交测试报告) ；业务培训 ( 举办或协助组织业务培t ) l i ，整理业务培训资料) ；服务响应( 查找分析系统业 务运行问题，提供业务解决方案，系统修改问题的业务测试) ；分析调研( 系统 业务运行情况分析，调查了解业务发展方向，同业同类产品的比较分析) 。 项目丌发团队工作职责包括：项目规划( 协助i t 系统的总体规划，协助确 定相关系统的技术架构) ；可研立项( 负责或配合项目可行性研究，负责或配合 项目的立项工作) ；项目开发( 成立项目组、制定项目开发计划，需求分析、设 计编码、系统测试，实施项目管理，确保进度和质量) ；优化推广( 根据需求对 系统进行优化，相关系统的推广上线工作) ；技术支持( 技术支持与技术培训， 服务响应) 。 技术支持与培训部一r 作职责包括：环境建设( 需求分析，方案设计，系统建 没，维护管理) ；技术支持( 主机系统，存储系统，网络系统，系统软件) ；资源 配置( 配置规划，资源调整，商务采购) ；技术培训( 征集培t ) l l 需求，制定培训 计划，举办相关培t j l i ) ；机房管理( 值班员管理，设备进出，人员进出，机房环 境管理，保障管理) 。 3 5 项目管理制度 3 5 1 项目管理 项目立项：项目组编写项目立项思路材料( 即：项目说明书，包括业 务需求，项目范围、总体方案、项目计划、项目人力和项目概算申请表) 总 行下达项目任务书。 项目预算：项目经理根据不同阶段的项目任务书与概算表，编写项目预算申 请材料( 包括项目预算申请签报、项目预算申请表、项目任务书及概算、 项目人员清单及工作量表、项目立项申请报告、项目成本分解确认单) 。 总行进行预算意见批复：完成项目预算批复意见。 项目采购：项目经理编写采购谈判材料( 包括项目任务书、项目预算审 核意见、i t 产品及服务集中采购方式及候选供应商方案、s 0 w 、谈判邀请 函、单一来源采购的请示) 。 项目管理部上报到总行，总行进行采购流程。 项目经理编写项目计划( 项目计划是一个集成文件，与子计划项目进 度计划m p p ) ) 、质量保证计划、配置管理计划和附件项目估算表、项目 生命周期模型选择表、项目风险管理列表一起构成完整的项目计划) 。 需求管理：需求流转路线为：需求提出部门一综合部一中心分管领导( 中心领 导) 一综合部一项目管理部一项目组。 需求登记：项目组在收到需求时，即时填写需求跟踪矩阵登记需求，需 求跟踪矩阵可随时更新。 设计：项目经理组织项目组编写概要设计( 高层设计) 、详细设计( 低层 设计) 。 开发与测试：项目组按照设计方案进行相应的开发与单元测试，编制单元 测试计划，测试完成人及项目经理签署单元测试报告。 集成测试( 系统测试) 计划细化：完善集成测试计划。 集成测试( 系统测试) 执行：根据具体情况，可由项目组或专门的测试部门承 担：可请相关技术运行部门参与。测试完成人及项目经理签署集成测试报告 ( 系统测试报告) 。 用户验收测试计划细化：完善用户验收测试计划。 用户验收测试执行：项目提出部门组织用户验收测试，测试完成人及项目提 1 2 出部门负责人签署用户验收测试报告。测试案例编写：项目组需向项目管理 部提交单元测试案例、集成( 系统) 测试案例、用户验收测试案例。 缺陷登记：项目组使用缺陷登记表或相应缺陷登记工具进行缺陷登记。 上线：项目组制定上线计划，准备上线文档；技术支持部上报上线计 划，项目实施管理条线p l o 审核上线计划；项目管理部组织中心内部评审上 线计划，技术支持部办理总行上线评审手续，项目实施管理条线上线评审；项 目组确定上线版本，提交软件更新申请；项目管理部审核上线材料，技术支持部 审核上线方案；中心领导审批软件更新申请；项目管理部进行版本发布；北京数 据中心审核和发布版本；项目组确定上线环境，负责上线实施；上线实施完成后， 项目组负责上线监控。 验收：项目经理按照项目验收材料清单整理验收相关文档；项目周期结束前 1 5 天提交验收材料给项目管理部；项目管理部负责对项目验收文档进行合规性 检查；技术支持部检杏项目组代码安全检查报告，项目安全需求说明书；项目管 理部向项目申请单位提出验收申请，项目申请单位初审验收申请材料，并配合i t 管理部组织项目的验收。 项目收尾：项目经理在项目验收报告下达后两周内按总行相关要求完成 项目清理和项目决算申请，并力争完成项目决算；项目经理按照北京数据中心和 开发中心要求，安排系统运行维护工作；项目管理部负责对项目收尾工作进行检 查；以上工作完成后，项目经理在接到中心领导、分管领导通知可以解散项目组 后才可以解散项目组。 3 5 2 合作公司考勤管理 综合业务部负责安排合作公司人员工作区域，并摆置座位牌。 综合业务部定期或不定期组织对合作公司人员进行工作纪律和环境卫生检 杏，并公布检查结果。 项目经理对合作公司人员考勤按照中心相关制度进行管理。 合作公司人员每天上、下班应各打卡一次，以门禁系统登记记录作为上下班 考勤的依据。 合作公司人员进场前应申请门禁卡，门禁卡实行实名登记制度，经中心项目 经理和合作公司项目经理批准后，向综合业务部办理申请手续。合作公司人员离 卡归还手续。 因工作等原因需要申请出差或请( 休) 假必须填写合作公司 差审批表，由合作公司项目经理与中心项目经理审批后，提 经理每月必须填写合作公司人员考勤说明，经中心项目经 理签字确认后提交综合业务部，综合业务部定期公布合作公司人员考勤情况。 项目经理每月统计合作公司人员在项目开发期间或维护期间的实际投入工 作量。 项目经理每月根据合作公司人员打卡情况进行人员工作量统计，并于每月最 后1 个工作日前录入项目人员信息管理系统。 项目经理要确保每月的考勤记录与项目人员信息管理系统数据一致，该数据 将作为履行合同和付款凭据。 3 5 3 合作公司人员及变更管理 项目经理及相关人员不得安排合作公司的同一人员同时担任两个或以上项 目的全职工作。 项目经理及相关人员不得擅自同意合作公司变更、新增人员。如因特别原因 变更、新增人员，必须经过中心同意。 项目管理部审核合作公司人员非正常变更信息表及书面说明书，分析变 更人员的资质水平是否符合合同要求。将检查结果填写合作公司人员非正常变 更信息表，在2 个工作日内将材料上报中心领导审批。 中心领导审批变更材料，将意见填写合作公司人员非正常变更信息表。 中心领导同意后，项目经理在1 月内试用该变更人员，并将意见填写合作 公司人员非正常变更信息表，回复到项目管理部归档。 项目管理部收到项目组意见回复后，马上通知合作公司项目经理变更申请结 果。 项目管理部及时将变更信息录入项目人员信息管理系统，并于每月末统计项 目非正常人员变更率。 1 4 3 6 运维管理制度 机房值班人员在接到电话报障或监控到故障时，应立刻登记故障处理登记 表，详细记录故障内容、故障时间、联系人及联系电话等内容。 项目组收到机房值班员以外的报障，必须第一时间拨打报障热线电话通知机 房值班人员，不得瞒报故障。 机房值班人员接到报障后，应根据故障类别，第一时间通知相关项目值班人 员，同时通知技术支持与培训部值班主任，并登记故障处理登记表。 项目值班人员接到报障，应对故障情况进行初步分析，如属于影响交易的故 障，应立刻报告分管故障处理项目组的中心领导及开发中心主任。 值班主任接到报障，应对故障情况进行初步分析，必要时与项目组进行沟通， 如属于影响交易的故障，应立刻报告分管故障处理项目组的中心领导及开发中心 主任。 当不影响交易的故障有可能在较短时间内转变为影响交易的故障或造成较 大影响时，项目值班人员与值班主任应立刻报告分管故障处理项目组的中心领导 及丌发中心主任。 相关项目值班人员接到报障通知后，要立即处理或安排人员处理故障。 值班主任接到办公或开发测试环境报障后，应立刻处理，尽快解决故障。 故障处理如需在开发中心机房登录生产系统进行操作，项目组必须按照丌 发中心应用维护操作管理规定进行申请与审批。 如无法在开发中心机房处理，需运行管理部门在生产系统现场进行处理，由 项目组形成故障解决方案后，立即将解决方案提交运行管理部门。 故障处理完毕以后，机房值班人员应马上联系报障联系人，确认故障己得到 解决，记录故障结束时间，并登记故障处理登记表。 机房值班人员在故障处理完毕后，应马上通过电子邮件方式发送故障处理 登记表给项目值班人员。 项目值班人员在故障处理完毕后，应马上记录处理过程，在一个工作日内于 故障处理臀记表中填写故障内容及处理过程描述，并反馈技术支持与培训部 归档 技术支持与培训部负责定期归档故障处理登记表。 3 7 绩效管理制度 3 7 1 广州开发人员分为项目人员与非项目人员两部分 项目人员是指参与项目技术开发、业务支持等工作的本中心开发、业务人员。 如其他部室人员参与项目工作，作为项目人员进行考核。 非项目人员是指从事项目工作以外的综合业务管理、银行业务、项目管理与 质量控制、技术支持与培训等工作的人员。项目开发部人员无项目任务期问，作 为非项目人员进行考核。 3 7 2 项目人员的绩效考核 项目人员绩效包括项目综合系数、项目考核系数、岗位系数、个人考核系数 等部分。项目人员综合考核系数h 由项目系数n 、项目考核系数b 、岗位系数d 、 个人考核系数k 的乘积构成，h = n b d k 。项目人员最终的绩效考核系数 ( j ) = 项目1 综合考核系数( h 1 ) 项目1 投入时间( t 1 ) 满负荷时间( t ) + 项目2 综 合考核系数( h 2 ) 项目2 投入时问( t 2 ) 满负荷时间( t ) + + 非项目系数( h 0 ) 非项目时间( t o ) 满负荷时间( t ) 。 3 7 3 非项目人员的绩效考核 非项目人员绩效包括部室系数、部室考核系数、岗位系数、个人考核系数等 部分。非项目人员综合考核系数h 由部室系数n 、部室考核系数b 、岗位系数d 、 个人考核系数k 的乘积构成，h = n b d k 。非项目人员最终的绩效考核系 数( j ) = 综合考核系数( h ) 投入时间( t ) 满负荷时间( t ) + 非工作系数( h 0 ) 非 工作时间( t 0 ) 满负荷时间( t ) 。 3 7 4 绩效考核程序 原则上，绩效考核每月组织一次。每月1 日前，由综合业务管理部向各部室 ( 项目组) 下达绩效考核要求，公布考核期满负荷时间，提供各部室( 项目组) 人员在考核期内的公假、请假时间以及打卡考勤记录统计。每月前5 个工作日， 各部室负责人、项目经理对本部室( 项目组) 进行自评，并对本部室( 项目组) 成员在考核期内的工作情况进行考核评定。每月前5 个工作日，综合业务管理部、 项目管理与质量控制部、技术支持与培训部分别对各部室( 项目组) 和个人进行 1 6 日常工作、项目管理和技术支持等方面的考核评定。每月前5 个工作日，综合业 务管理部负责组织各部室( 项目组) 对管理部室进行工作满意度调查，项目管理 与质量控制部负责组织项目岗位确认。每月前5 一l o 个工作日，中心领导负责对 所辖部室( 项目组) 及个人进行考核评定，并根据具体情况确定是否提请中心办 公会研究，由中心办公会议核定考核结果。综合业务管理部根据中心核定意见形 成最终考核结果，作为当月绩效分配的依据。 3 8 日常管理制度 丌发中心以大楼门禁系统的记录作为员工上下班考勤的依据，员工每天上、 下班应各打卡一次。 在开发中心工作时间超过一周的人员应到综合业务管理部领取门禁卡，纳入 开发中心考勤管理的范围。 各部窀开发团队设置外勤登记本，每天记录因外勤、出差等原因不能按时 打卡的员工姓名和证明人，每月汇总经部室开发团队主管签名确认后于下月第 一个工作同交综合业务管理部。 员工迟到、忘打卡等考勤违规每月超过三次的，每再发生一次扣减半天工作 量。 综合业务管理部每周公布考勤记录，并于每月第三个工作日之前汇总上月考 勤记录，作为绩效考核的依据。 3 9 开发中心现存管理问题分析 为满足银行战略和业务需求，i t 部门的被依赖程度越来越高。这种不断增 加的依赖性使银行对高质量i t 服务能满足业务部门需求以及顾客需求的服 务的要求也水涨船高。 在业务部门人员眼中，i t 部门是一个服务部门，他们期望i t 部门能提供符 合服务级别协议的产品或服务。业务部门会把自己看作i t 部门的客户，同时也 期望被i t 部门当作客户来对待。因此，i t 部门提供的服务必须符合业务部门的 需求和顾客的要求，同时要能很好地适应组织结构、业务需求、竞争环境及技术 革新等快速变化的内外凶素。 相对于业务部门高质量i t 服务的需求，开发中心目前的i t 服务支持工作存 在明显的不足。根据开发中心年终总结，2 0 0 7 年开发中心负责的应用系统运行 故障事件数5 3 7 个，其中影响业务次数1 0 8 次，影响业务时间2 2 9 6 小时；平均 的系统可用率为9 9 9 6 ，客户可用率为9 9 4 8 ：问题版本率超过1 0 等。各 个服务指标均存在较大的改进空间。 3 9 1 观念转变问题 开发中心人员绝大部分从省行科技部门转入，存在着观念的转变问题。省行 科技部服务于省行业务部门，面向全省银行客户；而开发中心服务于总行业务部 门，面向全国银行客户，服务级别、服务质量、服务响应时间等都需要有非常大 的提高。例如，曾经出现过银证转帐系统的故障事件，导致全国的银行账户在牛 市的交易高峰期不能将资金转入、转出证券账户，造成极坏的社会影响，银行董 事长亲自向客户道歉。 虽然开发中心和省行科技部门的主要工作都是根据业务部门需求，开发、维 护相应的软件系统，但定位有很大的不同。省行科技部门作为省分行唯一的i t 部门，具有绝对的垄断地位。而开发中心作为六大开发中心之一，则必须时刻考 虑着开发中心间的竞争、开发中心的生存、如何争取更多的支持和资源等问题。 如银行贸易融资系统的开发，就在各个开发中心进行了竞争，胜出者则享有相应 的项目费用、资源配置。 3 9 2 绩效考核问题 开发中心现有的绩效考核全凭主观判断，缺乏准确的可量化的考核数据。不 能提供可信赖的系统，统计分析工作绩效，来向总行报告丌发中心的业绩，也缺 乏量化考核员工绩效的依据。未收集、记录并分析绩效问题，未追踪绩效改进状 况。几乎没有可用的管理信息，来说明员工的时间花在哪方面，谁的效率高，谁 的效率低。问题的处理、事故的解决、日常的维护、软件的开发等均无明细的记 录。即使某件事上某位员工应负责任，但绩效考核办法没有将事件与绩效挂钩。 因此虽然有每月一次的绩效考评( 附表1 ) ，每年一次的年终考评，但基本流于 形式，起不到激励效果。 3 9 3 客户满意度问题 开发中心与业务部门缺乏一致同意的服务级别协议。业务部门按自己的需要 提出需求，开发中心按自己的安排提供服务，导致用户满意度不高，每个用户都 认为自己的问题应该马上得到解决，可期望却常常落空。其情况经常是：用户向 i t 管理人员抱怨已报故障几个小时了，还没有人来处理，但实际情况却是i t 人 员i f 忙于处理影响其它故障无暇分身，或者有多个事件正在排队，又或者已转向 上级处理但用户却不知道。i t 部门和业务部门之间缺乏系统化的沟通途径，造 成服务期望值的差距。虽然开发中心希望通过业务部门提交用户评分表( 附表2 ) 的方式，来监督i t 服务的质量，但由于仅针对项目开发阶段的工作，并且缺乏 统一的量化的标准，满意度调查表或者是串谋，或者是随心所欲的结果，每次均 是1 0 0 满意，达不到监督服务质量的目的。 3 9 4 服务流程问题 开发中心的i t 服务支持有多个入口，如综合业务部，技术支持与培训部， 项目组等，各有不同的流程、服务质量、服务态度，且流程间相互独立，部门间 也缺少沟通交流机制，同时缺乏全程监控的手段，无法监督制度和流程的执行。 虽然开发中心制定了很多管理流程和制度，但是有关人员是否按照该流程操作? 操作的过程如何? 在哪个步骤出现问题? 采取了什么应急手段? 这些问题管理 人员很难全面掌握，凶而不能保证提供标准化的服务。例如，仅对系统报障服务， 就有综合业务部的邮件报障流程、技术支持与培训部的电话值班报障流程、项目 组的系统缺陷处理流程等。 开发中心虽然设立了值班人员，以及相应项目组的二线或三线支持，然而， 这些值班人员和二三线支持都在依靠自己的力量独立解决相同性质的事件，部门 间鲜有沟通和合作，常常导致事件不能很快解决，甚至是由客户自己解决问题， 导致组织提供的服务客户体验较低。曾经出现过网银系统故障后，值班人员未即 时升级，结果在一段时间后，客户直接反应到了总行行长那了，行长询问开发中 心t 任时，主任、项目主管竟然还懵然不知。 开发中心的服务支持工作被动，常常是出了问题才有所行动，大量资源不断 被用来解决重复出现的事件和问题，而不能消除问题的根源。而且在这种重复工 作中，由于缺少对关键i t 人员掌握知识技能的文档化记录，开发中心对关键人 员的依赖程度将不断加深。每天都会有无记录的、不协调的变更活动，常常是解 决了旧的问题，却导致了新的问题。最典型的案例发生在系统发布上线时，由于 1 9 缺乏相应的变更、发布流程，上线经常伴随着一系列的后续补丁。 3 9 5 合作公司管理问题 虽然与公司签有技术支持服务合同、s o w 等，公司以提供人月的方式履行合 同。但对公司的工作情况管理仅凭工作台帐信息表( 附表3 ) ，没有绩效管理、 服务质量管理等手段。仅作考勤管理只能确认人员到位情况，而公司人员的素质、 工作完成情况则无法评估。对公司人员的工作无法跟踪，公司人员造成的事故也 无法惩罚。 3 9 6 知识共享问题 开发中心的各个项目组形成一个个信息孤岛，不能很好地沟通。对“关键技 术人员”依赖程度高，大量知识存于他们的头脑之中，关键人员流动有可能导致 部分系统瘫痪。事故处理的经验不能被其它人员充分利用，在排除同类事件的再 次发生和快速解决方面没有体系。曾经发生过项目人员离开后，源码、文档同时 消失无踪，相应的程序无法修改、优化。 3 1 0 本章小结 本章主要介绍c m 银行i t 战略、丌发中心定位，以及c m 银行开发中心现 存的组织架构、各部门的工作职责，各项项目、运维、绩效、日常各项管理制度。 并研究分析了开发中心面临的挑战、管理制度中存在的问题。下面章节将分析、 研究如何通过引入i t i l 最佳管理实践，以解