本站小编为你精心准备了基于系统管控的企业信息论文参考范文,愿这些范文能点燃您思维的火花,激发您的写作灵感。欢迎深入阅读并收藏。
1.案例中的缺陷分析
在经过中国证监会调查后,光大证券此次乌龙事件的原委已经公布。从事件发生的原委来看,此次乌龙事件暴露的问题不仅仅是软件程序问题,更是对公司核心业务信息系统的风险控制问题,光大证券在其自营业务的策略交易系统的管理中存在较为严重的设计和运行缺陷。
1.1信息系统的程序开发存在设计缺陷调查结果显示,光大证券策略投资部自营业务使用的策略交易系统中,无论是订单生成系统还是订单执行系统,均存在严重的程序设计错误。其中,订单生成系统中套利模块的“重下”功能的买入函数将“个股”写成了“ETF一篮子股票”;而订单执行系统将市价委托订单的股票买入价格默认为“0”,导致无法对超出账户授信额度的交易进行校验并限制。目前,很多企业的信息系统在设计阶段都会存在程序上的问题。因为在程序开发中,业务人员为了提升操作的效率,往往将很多控制性的要求在程序中弱化,而程序法开人员也没有足够的风险意识,只是简单满足业务人员的需求,导致很多操作程序的后台逻辑存在严重漏洞。
1.2信息系统的操作执行没有制衡,存在严重不足从本次乌龙事件的发生原因来看,光大证券交易环节不仅存在程序的设计缺陷,其运行缺陷也显露无疑。一般来说,从订单生成到完成交易,在系统自动审查的基础上,至少还应存在交易员审查、部门审查和公司审查三个关口,而“乌龙指”的发生说明这三个关口都存在严重的缺陷。
1.2.1在交易员层面。公司应对交易员设定对于交易品种、开盘限额、止损限额的三种事项的风险控制机制。而实际操作中,由于系统设置的错误,导致后两种根本没发挥作用,而交易员也没有进行很好的价格自我检查,缺少必要的双人复核机制。另一方面,交易员在准备使用“重下”功能时,由于不了解该功能的操作,所以请教了程序员,而程序员直接在交易员的实盘操作中,演示了系统功能,这表明无论是业务人员还是程序人员风险意识极其淡薄。
1.2.2在部门层面。公司的要求是部门实盘限额2亿元,当日操作限额8000万元,但是从实际结果来看,这些控制要求都没发挥作用,公司对业务部门根本没有严格的金额上线控制。另一方面,公司的风险控制部门在本次事件中也形同虚设,没有起到必要的监督职能。证券业中风控部门的级别偏低,相较于贡献盈利的交易部门来说,风控部门较弱势。在很多情况下,交易部门会以“耽误交易时机”等借口,阻碍风控部门进行必要的审核,这也是此次导致此次意外发生的原因之一。
1.2.3在公司层面。一方面,公司监控系统没有发现234亿元巨额订单;另一方面,公司动用了其他部门的资金来补充所需头寸来完成订单生成和执行,或者根本没有头寸控制机制。
1.3存在问题的信息系统没有经过严格的验收和测试令人意外的是,此交易系统的开发和测试由一个人完成,缺少必要的不相容职务的分离,使得测试人员无法及时发现程序中存在缺陷。同时,公司的订单生成系统发生异常的“重下”功能和订单执行系统的额度控制功能,在很多人看来是非经常性功能,所以没有经过严格的测试就进行了实盘运行。另外,策略投资交易系统从开发完成到上线实盘操作,仅仅只有1个月的时间,导致了验收和测试流于形式,使事故在上线后的半个月不可避免地发生了。
1.4公司在乌龙事件发生后进行了不实的信息披露最后,不得不说,光大证券在系统发生故障时,没有第一时间向公众公告,而是采取了股指期货对冲风险,构成了内幕交易。而光大在下午交易刚开始的否认性反应,更是给了公众虚假的信息传导。在这点上,券商内部也应有交易异常的响应机制,发现异常及时上报,查明原因并确定止损方案,连同原因与方案进行公告,不能给投资者造成二次伤害。
2.启示与教训
通过信息系统来提升公司的交易效率,实现业务的更高盈利本是一件好事。然而,光大证券由于信息系统的使用不当,出现了如此事故,给资本市场投资者、上市公司自身以及公司管理层都带来了巨大的伤害。其实,2010年,财政部、证监会等五部委颁布的《企业内部控制应用指引》就将信息系统作为第18号指引,可见监管机构对信息系统在企业经营管理中作用的重视。“乌龙指”事件再次引发了对公司信息化管理尤其是核心业务的信息系统管理的深入思考。笔者认为,这一案例给规范公司信息系统管理带来了一些启示。
2.1重视信息系统的开发程序的参与人员管理信息系统作为涉及人工操作的工具,虽然有其强制性和严格性特点。然而,一旦程序出现错误,系统也将如常执行,无法进行智能化的暂停。因此,对信息系统的管理来说,把握好开发环节是整个系统控制是否有效的关键。信息系统开发虽然是为了满足业务的操作需求,然而不能仅将其作为业务人员和程序人员的事务,更要重视风险管理人员在程序开发中的参与。风险管理人员是为了帮助公司的信息系统开发者关注到各种重大风险,并及时在系统中进行导入和修正,防止信息系统由于过分的强调效率而忽视了必要的风控。在本案例中,在订单生成系统到达订单执行系统的过程中,不仅应具备额度校验机制,系统也应被设计为“在产生大额的订单时,有相应警报机制,在送达交易所系统之前,能对交易的数量和金额再次确认”。
2.2加强信息系统开发的验收的测试在不同具体情况的应用中,无论多成熟的系统也会出现各种各样问题。而严格的验收和足期的测试是程序错误尽量微小的重要保证。然而,现在很多企业在信息系统上线前,由于对信息系统过于自信,以及缺乏对信息系统的了解,使得很多验收流于形式,甚至很多企业根本不开展。一般来说,在验收环节,首先,要做到不相容职务的分离,特别是开发人员不得担任验收人员,以防止无法全面发现错误。其次,在开发完成后,应由业务部门、开发部门联合风控部门,对系统各个环节进行数据的模拟测试,将各个功能全部使用,保证每个功能的有效测试,并留存完整的测试记录。第三,对于新开发的功能或者交易复杂的系统,公司应在开发完成后的一段时间内,进行多人次的测试,尽量以不同人员进行测试,产生尽可能多的结果,如无明显异常,再上线实盘操作。
2.3强化风险管理部门在信息系统使用中的风险监督机制笔者认为,风控部门应在交易的评估与执行中,有一定的发言权。在交易之前,风控部门应共同参与交易部门对交易风险的评估,设定交易的风险指标;对于重大交易方案,风控部门在实际交易之前,应具有审核权限。交易下单后,风控部门应对交易的全过程进行监控,一旦意外发生,风控部门也能及时采取一定的应急措施进行处理。除了关注业务本身外,风控部门也应该提升对信息系统的关注程度,必须对核心的信息系统进行重点关注,了解其关键参数、关键数据库的设置,并组织专家对整个信息系统的操作进行定期的检查和监控。尤其是在系统上线的前期,更要强化对信息系统的功能风险的不间断评估。
2.4提升信息系统人员的风险意识再好的信息系统最终还是需要人来操作,所以企业需要持续加强对员工的风险培训和风险意识的培养。建议企业建立完整的信息系统风险管理制度和手册,来指导业务人员的操作,并通过不断的理念灌输、实际操作的检查监督来提升操作人员的责任心和风险意识。在此基础上,交易部门可针对交易员的内部级别设定交易上限,避免新手或风险意识较弱的交易员拥有过高的交易权限,引起资金风险的提高。
作者:胥翠芬单位:贵研铂业股份有限公司