银行IT建设与风险管理交流文档之一
本人在一家城商行（下面以XXX银行指代）负责IT风险管理 工作，前段时间应领导要求与同城另一家银行（下面以XX行指代）的IT部门负责人进行了沟通，我将自己这几年对银行IT建设与风险管理的想法总结成了几篇 文档发给了对方，其中也包括针对对方提出的问题作出的一些个人意见和建议。这里先发出第一篇，希望跟大家交流、学习一下。
题目：针对XX银行IT现状的反馈建议
XX银行作为一家重组后成立的新银行，IT建设正处于起步阶段，可以充分借鉴XXX银行以及国内外其他同行的经验与教训，先规划后实施、建设和管理并重，少走弯路，以实现IT投资效益的最大化，在风险可控的前提下，达到IT大力支撑业务发展的目标。
针对《XX银行IT现状》材料，结合XXX银行的情况以及个人的知识积累，阐述下对材料中提到的各项差距的看法。
差距一：全行IT建设思想和认识不统一
银行业金融机构运用IT是为业务发展服务的，但服务的方式是有差别的，因此需要找好IT的定位。IT是紧跟业务需求实施支持，还是与业务相辅相成，还是利 用技术引导业务创新？这种定位需要结合自身的实际情况来决策，不同的定位决定了不同的IT建设模式，会影响后续人力、物力、资金等一系列的投入。XX银行 目前所处的发展阶段，可能应该将IT定位于主要满足现有的业务发展要求，补充建设欠缺的IT系统，提高信息化水平，支持网点和产品扩张，离通过IT来引领 业务发展，增强核心竞争力还有一定的距离，但这可以是一个中长期的发展战略。
对于IT系统应该采取一种全生命周期的视角去看待，一套系统从设计到开发到上线运行到淘汰，就像人一样是有个连续的过程的。行业经验表明系统开发只占系统生命周期的30%，银行不是为了上一套系统而去开发一套系统，系统的真正价值在于它运行起来，并满足使用目的。为什么要上马一套系统应该经过充分的分析 （按照监管要求必须建设的系统除外），要结合业务需求、技术可行性、成本、收益、实施风险等多种因素来考虑。
差距二：信息科技中长期发展规划欠缺
XXX银行就吃过无规划建设的亏，就像修房子没有设计图纸所造成的后果一样。系统建设只从该系统本身出发考虑，忽略了整个IT架构，忽略了系统间的连接，并且缺乏前瞻性；另一方面，没有规划就不清楚该建什么系统，什么系统先建什么后建。
IT规划一定要有可落地性，在一个宏观整体规划的基础上，最好可以针对IT基础设施、应用架构、数据标准等各个具体的方面制定子规划。子规划的针对性更强、内容更详细，更利于落地，指导具体的建设步骤。
差距三：技术和业务结合不够紧密
隔行如隔山，业务部门与科技部门使用的是不同的语言，相互之间具有天然
的鸿沟，这是不足为奇的，但在银行业金融机构的IT建设之路上必须尽可能地缩小甚至 消除这种鸿沟。绝大多数的IT资源（应用系统、网络、主机等）不是建设起来供科技部门使用的，广大业务部门和员工才是IT资源的真正用户，因此他们应该深 入参与到IT建设中来。但是这种参与不可能自觉发生，需要一些前提条件：
1.意识的建立。IT不是魔术棒，不是简单告诉IT人员需要什么系统，他们就可以变一个完美的系统供你使用。你要对IT人员详细描述你对这个系统的需求， 后者才能将其转化为计算机程序。反之，IT人员也不能对业务熟视无睹，不理解用户的需求是无法开发出好的系统的。业务部门和科技部门可以建立定期的沟通机 制，甚至人员互换计划，促进相互了解和理解。
2.责任制的明确。可以考虑采取“谁使用谁受益，就谁负责”的原则，使系统使用部门承担起牵头建设的责任。
3.成本和收益分摊、系统后评估等机制的建立，才能促使该原则真正地有效。IT系统的建设和维护成本不能完全计算到科技部门头上，因为系统最终使用者是业务部 门，真正的用户为什么不承担使用成本呢？IT系统产生的收益（主要是针对产品类和服务类IT系统，例如理财管理系统、网银等）不能完全计算到业务部门头 上，因为系统的正常运行是由科技部门提供保障的，服务提供者的贡献为什么被忽略了呢？
差距四：科技管理制度和组织架构还需进一步完善
制度是有一个框架的，从策略到标准到流程，逐步细化，越来越具备操作性，同时要覆盖所有的方面。
1.制度的制定不能只由科技部门完成，一开始就应将业务部门、风险管理部门、审计部门加入，共同起草制度草案，而不要等到初稿都写完了再来征求各方意见，这样效率很低。
2.制度制定出来后不是摆设，必须严格执行，定期对执行效果进行审查。
3.必须建立制度的跟踪、更新机制，否则会形成文档和实际操作两张皮的状况。
4.制度一定要全行公示，容易查看，否则员工的惰性容易造成不按制度规定的方式做事。
差距五：人员少、专业化技术水平亟待提高
IT人员配备数量、结构应该与自身对IT的期望、定位和建设模式相联系，不能单纯追求某个比例，应该“按需进人”。例如IT建设的高峰期，需要认真考虑是 招聘大量正式开发员工还是依靠外包公司提供，因为高峰期过后将进入平稳发展期，对开发人员的需求将大幅度降低，如果前期招聘了大量自有员工，后期的人力资 源成本就非常巨大；而依靠外包公司在建设阶段提供专业人员，不需要时可以随时减少购买的人工时数，非常灵活。
对招聘人员的素质要求应该与自身的薪酬体系、机构所处地域的行业发展程度相匹配。例如XXX地区就缺乏大量具备中高等素质的IT人才。如果本地人力资源水平较低，可能就要考虑依靠外包公司提供专业人才。
自身IT人员的培养、继续学习与深造十分必要。因为银行相对是一个比较封闭的环境，IT人员得到锻炼的广度与深度都有限。需要建立持续的知识更新与交流机制，使IT人员不仅跟随技术的发展，同时也跟随业务的发展，例如每年制定IT员工培训计划。
差距六：科技人才激励机制不健全
IT部门在行内属于服务支持部门，不直接创收并且还是所谓的“成本中心”，IT又属于专业技术，所以对于IT部门的考核机制不能与业务部门一样。比如说XX银行的薪酬改革中对科技部和科技人员的考核机制就不完全合理。 针对IT部门和员工的考核可以从内外两个途径来进行，内部不同部门之间相互考核，例如开发部考核架构部、测试部考核开发部、运维部考核测试部；外部系统使用部门考核科技部门。IT部门作为服务提供者，应该接受服务对象的评价，双方的考核依据可以参考签订的服务水平协议。
IT作为日星月异的行业，提供对新技术的培训和学习机会是非常重要的激励方式之一。
差距七：全行IT风险意识淡薄，应急预案不健全
IT风险意识和文化需要自上而下地建立，随着监管的不断加强，董事会和高管层承担着越来越大的责任，这方面应该是逐步会得到改善。另一方面，董事会和高管 层必须向全行范围表明自己对IT风险关注，并对风险管理提供足够的支持，这样才能促使全行员工树立良好的意识。单纯召开固定的会议不足以表明这种关注，因 为普通员工本来就容易产生与高层的距离感。
要敢于对应急预案进行演练，虽然演练本身具备风险。但即使演练时发生风险，我们也是有备而来的，相比意外的风险，更容易控制。不演练就无法检验应急处理的 技术、流程、人员素质是否有效，在面临真正的突发事件时就无法迅速恢复。例如XXX银行曾经在进行演练时就发生过UPS电源损坏的情况，如果不演练就无法 及时发现该问题，真的遇到市电中断需要切换时，就会发现UPS无法供电。
差距八：运维管理经验不足，技术手段不完善
可以考虑尽快实施ITIL项目，建立标准、规范、高效的运维流程、方法与工具。要注重运维操作流程的文档化，以实现知识转移，防范人员风险（某种运维流程只存在于个别运维人员的头脑中，对其产生严重依赖）。
在分析业务发展速度的基础上，进行容量规划，根据需要提前进行自主数据中心的规划建设。
差距九：全行计算机安全体系建设尚不完善
可以参考ISO17799和ISO27001等国际标准来建设完整的信息安全体系。
