• 快捷搜索
  • 全站搜索

金融企业应用系统研发的独特性

2013-06-14 12:06:19作者:中国人寿保险股份有限公司研发中心 丁玮编辑:
从工作实践出发,尝试探索金融单位的软件研发过程在需求、用户、工作标准、系统架构、人员管理等方面所显现的特别之处。

银行、证券、保险公司、监管机构等金融企事业单位的IT部门,作为应用软件的消费群体,同时自身也承担着本单位应用系统的研发职能。这些单位的软件研发过程和微软、百度等专业IT企业有怎样的差异?笔者从工作实践出发,尝试探索金融单位的软件研发过程在需求、用户、工作标准、系统架构、人员管理等方面所显现的特别之处。

一、需求个性定制的特点

         监管环境的硬性要求、市场机会的稍纵即逝,使金融企事业单位的业务部门对系统灵活定制的呼声越来越高。这促使IT部门不断反思和优化工作方式,希望通过增强研发自主掌控来解决这个问题。应用系统的灵活定制,可以快速地响应业务需求,然而过度灵活也会将系统需求引向另一个反面,即随意性。主要体现在系统研发计划无序、变更失控等方面,将为系统建设带来诸多风险和隐患,使工作效果不可控。

         如何既实现灵活性,又规避随意性,是悬在IT部门头上的一柄利剑,如果处理不当,无论是影响需求实现速度,还是任由计划随意变更,为系统带来质量问题或安全隐患,后果都相当严重。笔者认为,IT部门是否有能力对业务需求进行规划,进而做出技术的发展规划,是这个博弈的关键点。规划能力的获得依赖于外部管理环境的配套以及自身能力的提升两个方面。外部管理环境主要是指公司层面的信息化管理委员会或承担类似管理职能的组织,该组织通过规范应用系统研发任务的管理,在一定程度上可以屏蔽各业务部门对应用系统研发工作计划的随意干扰,但经过这层过滤,仍然存在灵活性与计划性的矛盾,提升自身业务规划能力就成为必然选择。规划能力的突出特点是前瞻性,如果IT部门能先于业务部门对业务发展和市场环境变化做出预测,并通过技术加以实现,IT部门就自然而然就对系统建设具有完全的掌控力,赢得这场博弈的胜利。

二、缺乏产品意识的特点

         普通的商业软件产品是软件企业的利润来源,这样的软件在设计之初就对提高客户粘性大费心思。而金融单位内部使用的应用系统,由于缺少相应压力,并非以产品化的思维来做系统建设。在系统推广方面,金融单位的总行、总部、部委对下级单位具有很强的管控力。因此系统建设之初,研发人员已经可以预见即使系统易用性差,可维护性差,但只要基本功能具备,就可以实现上线。在一定程度上,正是由于应用系统面向内部用户,让管理层认为总有机会来弥补系统缺陷,成为这类应用系统质量不高的病根儿。近年来某些公共服务系统发生了宕机瘫痪的事故,引起了很大的社会反响,各单位都加强了对系统非功能性需求的关注。金融单位的应用系统普遍具有海量数据和用户,同时又需要做到快速响应和安全可靠。这些特点促使应用系统的非功能性需求的实施质量成为系统质量的直接决定因素,这已成为许多CIO的共识,这一观念如果要被金融单位管理层和系统需求方广泛接受,尚需假以时日。

三、系统单一来源的特点

         尽管金融单位对很多软件产品的需求是通过外包或者外购来实现的,但从规划一致性的角度出发,这些单位的IT部门被视为单位内部的软件唯一提供方。这种现象用招投标的术语打个比方,就是“单一来源采购”。单位内的业务部门作为系统唯一需求方,是IT部门逻辑上的甲方;而IT部门作为应用系统唯一提供方,对系统需求具有强势的话语权。这造成了业务部门与IT部门之间“互为甲方”的关系。如果不从组织架构层面解决这个问题,部门之间的平行关系就会时常带来实施层面的冲突。

         金融单位内部“单一来源”和“互为甲方”的代价是组织层面难以获得更广泛的信息、更先进的技术。同时,“单一来源”造成的另一个弊端是系统建设缺乏标准化,这同样是缺乏动力所致。金融单位自主研发的应用系统,服务于组织内部,无需对外发布,不会大规模地外接外部系统。因此,系统建设者总可以找到理由拒绝在标准化方面的学习和投入,这并不意味系统标准化对金融单位的应用系统不产生影响。例如,如果系统建设时忽视对既有标准的探究,极容易在系统建成后出现数据定义不能满足实际使用要求的情况。

 1 2 下一页 尾页

扫码即可手机
阅读转发此文

本文评论

相关文章