信息技术风险案例分析

    本篇论文目录导航：

【题目】信息技术中的风险管理探究 
【第一章】信息技术风险控制研究绪论
【第二章】信息技术风险分析
【第三章】信息技术风险案例分析
【第四章】信息技术风险管理现状与模型
【第五章】信息技术风险管理的应用与挑战 
【结论/参考文献】风险管理在信息技术中的应用结论及参考文献

    第三章 信息技术风险案例

　　本章节主要研究信息技术质量和信息技术缺陷，并分析光大“8.16”事件中信息技术风险的发展过程。开发人员引入信息技术缺陷到软件系统中，在特定场景下被业务人员触发，导致业务损失，继而引发更多的违规操作。

　　一、信息技术

　　（一）信息技术质量

　　信息系统通过软件产品形式交付使用，软件过程管理中定义了质量和度量方法，如功能、效率、可靠性、可用性、可维护性和可携带性等①。度量软件系统主要是指度量最终产品、软件开发活动以及独立于开发活动的过程。软件的质量是由一组特定的品质要素组成，每个质量元素和一些措施都有对应的描述指标，质量度量贯穿于整个软件过程中②。在信息系统软件交付前的相关质量测量，主要包括功能性测试、兼容性、系统性、接口等测试；在软件交付后的质量测量主要包括客户缺陷，客户增长的需求和系统的可维护性等③。

　　软件度量是针对软件开发项目、软件开发过程及最终产品的活动。首先要进行数据类型定义、分析收集的数据、并且不间断的进行可量化的跟踪。软件度量主要包括质量度量工作和任务度量工作两大部分。度量主要是以最终发布的产品质量为目标，采用科学的方法，对软件开发过程进行监控和量化④，并通过专家组综合评估客观结果⑤。分析是一项不可或缺的专家活动，主要是采用一些模型函数处理数据，挖掘数据中的潜在问题，发现问题并且对未来有一定的预测，对软件的最终质量保证和开发过程的管理都有非同小可的意义。软件度量的目的一般在于：

　　1. 量化：量化软件功能点和需求，量化软件开发过程。

　　2. 比较：比较软件产品的周期或软件开发的实践活动完成情况。

　　3. 控制管理：根据 a 和 b 获得的量化且标准化的数据信息，及时有效地管理，采取措施控制软件开发过程中的关键。

　　4. 预测：采用科学的方法，数理统计的数学方法和历史专家知识库对未来进行合理的预测。

　　5. 回归改进：根据度量信息和科学的预测模型的结果，确定软件系统改进的过程和方法。

　　系统质量通常通过比率关系、组合关系或其它度量关系表现。项目的功能点规模、项目完成所需工作量、项目所需投入的成本、项目进度是过程改进和软件开发过程中较为基本的度量元。在研发过程中，缺陷数据及其统计分布情况是重要的度量指标。

　　因此，可以建立一个软件质量度量的性能基线活动基准，用以考核软件产品的质量，相关人员的软件测试的绩效考核和管理评价标准，系统是否通过标准。

　　缺陷评测的基准因公司或客户需求不同而不同，既要明确统一也要易于执行，最为常见的或典型的是每一万行源程序（LOC）的错误发现率。

　　（二）信息技术缺陷

　　在竞争激烈的环境下，质量已是软件开发组织的一项考核指标。要确保产品质量，测试过程中就要计算各项质量指标。此外，任何产品都会经历测量过程，都必须在测量过程中不断改进产品质量。为评估软件系统质量，本文使用最为直接的方法：缺陷度量①。

　　缺陷数据库既可以作为开发人员的激励和考核指标的部分依据，也可以作为质量度量的重要指标。本文将主要研究信息技术缺陷对应的信息技术风险。重要的是采用一系列功能点挖掘，分析缺陷密度和趋势并预测未来，并对软件质量和开发管理活动提供可靠的专家意见，改进软件开发过程。

　　软件缺陷度量②是一个定义或是量化指标。软件缺陷，一般指的是软件中的问题，可以通过各种活动测试出来，包括检查、测试和正常使用。缺陷虽然不是软件度量的全部，但是缺陷正是客户使用中产生操作风险的根本源头，所以本文将紧紧围绕缺陷，对缺陷进行分析，对系统质量进行度量。如果正确、持续不断地进行缺陷度量，那么产品质量会得到提高，因为组织可以通过有效的管理活动及时进行改进。

　　软件产品质量的缺陷度量有两个指标：已知缺陷（known defect）和尚未发现的潜在缺陷（1atency defect）。在软件开发活动中，已知缺陷可以通过评审或测试等方法发现。Myer 研究发现一个重要理论，着名非直觉原则①。缺陷密度②是度量质量的关键因素，质量高的产品缺陷密度就小。

　　软件缺陷主要可以用缺陷密度进行度量，较低的缺陷密度被作为产品质量的重要目标。从用户的视角看产品质量，客户对缺陷率并不感冒，缺陷总数更为关键。所以缺陷率难以成为他们关注的重点，对他们来说，产品应该确保缺陷总数应该持续降低。随着更新版本的发布，缺陷总数应该是降低的而不是在增长，即新增功能不能引入新的问题，对开发过程是个几乎不可完成的任务。F 定义为产品规模的大小， 定义为在软件编码阶段被发现的所有缺陷数， 为软件实施后被发现的缺陷数，D = 为发现的总缺陷数。则：

　　二、光大证券的实例分析

　　（一）光大“8.16 事件”

　　光大“8.16事件”④是由于订单生成系统缺陷被触发，并触发订单执行系统的缺陷，最终发生股市异常走高100多点的乌龙事件；事件发生后，在没有信息披露的情况下，光大证券进行了对冲操作⑤。

　　首先，我们从外部旁观者的视角来看“8.16”事件的发生经过：事件发生在当天的11点05分，半个小时后事件已经在业内传开；下午的停牌则一定程度上表明上午的事件，光大证券、上交所的否认态度最终在下午4点半被证监会表态所否认①。

　　其次，我们从光大证券内部来看“8.16”事件的过程：资深交易专家郑冬云在上午9点40分至11点02分之间持续进行成份股买入操作，但是最后一次操作未能成功。在崔运钏协助下使用新功能进行补单的情况下触发订单生成系统的缺陷，引发巨量的订单买入，上海交易所发现并向光大证券询问异常原因。光大随即做后面引起市场极具争议的补救操作-反向对冲②。

　　（二）光大“8.16 事件”分析

　　从组织内部和外部描述了“8.16”事件，接下来从技术和管理角度进行分析。

　　首先，从信息技术角度分析，其实是个前端订单生成系统③的设计阶段的错误④，并且“重下”功能是个新功能，并没有经过足够测试并具备上线的资格。新功能让信息技术投入风险损失曲线向右上角移动，所以说每一次新功能开发，在假设是同一团队，开发同等质量的前提下，是风险在增大。可以看出他们对新功能的认识的不足，新功能竟然从未实盘启用过，同时看到信息技术开发人员专业知识的不足，之前对赛安软件系统软件质量的研究中也发现同样的现象，专业知识是信息技术缺陷的瓶颈，而非信息技术本身。一般情况，订单生成系统的缺陷并不具备导致如此大量异常交易得条件。但是订单生成系统在150s没有收到响应的情况下，会无限次重新生成订单委托。这个缺陷将“重下”的功能缺陷放大了很多倍，瞬间产生了2万多的订单委托。如此巨量的订单委托通过订单执行系统的另一个缺陷直接送达交易系统。订单执行系统的默认市价委托策略进一步助推了缺陷走向交易系统并大量成交。

　　其次，从风险管理角度分析：

　　1.从风险环境上分析其组织战略。从风险管理的角度看，光大证券是典型采用风险管理寓于组织管理之中的组织结构，该组织结构的优点就是快，缺点是风险控制会被边缘化，风险控制主要靠决策者和专家团队。光大证券“8.16”事件非常典型的暴露了此组织架构的缺点。从战略决策角度看，多方面的信息表明，光大证券的自营盘业务部门的战略决策比较激进--“快”战略。要求信息系统为ETF套利服务--快速的新功能研发、高速的交易性能等。部门决策者是典型的专家型领导，致力于构建无风险套利模型，并且业绩斐然。无风险套利就需要快速的捕足套利机会。以“快”作为战略决策也合理。那么风险控制应该相应很快，然而非常不幸，这种情况绝非短期存在，而是经过相当长一段时间以至于风险控制是典型的被边缘化，是该组织架构的弊端之一。风险控制与业务本省二者就是存在一定的矛盾关系，所以二者需要达到一个平衡，在此次事件中，已经完全倾斜向了业务。光大证券选择铭创公司的重要原因是铭创公司的系统的高性能。

　　2.从风险识别的能力分析。光大证券并不是没有风险控制标准②，而是没有发挥作用。234亿元巨额订单理应被公司监控发现，这远远超出公司的风险控制指标。但是对于公司当日流动资金只有几千万元却能操作如此大单，其实都源于证券公司的自营席位特有的信用交易的功能③。由此可以发现光大的风险控制基本是在裸奔，光大证券的风险识别能力几乎没有，所以风险控制的具体实施就成了空谈。董事会在证监会询问巨额成交事件能第一时间想到自营盘的套利交易部门说明他们是了解风险所在，但是并没有去构建相关风险管理环境，实在是个遗憾。

　　3.从风险类别上看，光大证卷整个团队自研的订单生成系统发生的风险属于核心风险。策略交易系统是该团队的核心竞争力，自主研发且业务强相关，该策略交易系统的订单生成模块的缺陷是此次事件的主要因素。其次，外购于铭创公司的订单执行系统发生的风险属于关键风险。该订单提交系统属于外购业务强相关，该订单提交系统默认采用市价买入，为订单生成系统的巨量委托能够成交提供可能。光大外购的风险控制系统则是引发了重要风险，该高价买入的国外知名风险控制系统失灵了。光大证券的三个模块中核心系统模块和风险控制模块都爆出风险问题。从组织管理分类上看，此事件的风险属于违规风险。主要有风险控制没有或被绕过、研发新功能违规上线、违规对冲操作。

　　所以风险管理的首要任务是风险管理环境的构建，什么样的风险管理环境基本决定风险管理水平所能达到的高度。其次是风险识别，风险识别的能力决定认识到的风险能被控制的程度。最后一个就是沟通，沟通不止是人与人之间的沟通，也有信息技术与人之间的沟通，沟通决定风险控制的具体有效性。

　　三、小结

　　光大证券的“8.16”事件的新颖之处在于，信息技术第一次以如此重要的角色成为此次事件的焦点，与信息技术相关的研发者和使用者同信息技术一起成为此次事件的焦点。信息技术风险不仅仅是信息技术缺陷导致，且跟组织性质和结构有着重大关联，所以在研究信息技术质量章节中提到组织管理、流程管理和流程改进等。优秀的组织可以在软件开发过程中发现此技术缺陷，避免缺陷引起如此严重的信息技术风险事件。同时验证本文的另一个研究结论：开发过程更多的集中在系统可用性，在系统合规性度量缺少足够的重视和专业素质的度量人员。

　　这正是行业的现状，从事研发的人员缺乏具体业务知识和风险意识，而让开发人员精通合规性法律文本甚至是业务是不太可能，所以，金融相关创新较多且业务风险较大的机构组织的信息技术系统的部署实施的流程控制就相对复杂和严格，即使如此也没能避免光大证券此次事件的发生。

　　光大证券的“8.16”事件虽然是信息技术风险事件，而贸然使用测试系统接入交易系统是比较严重的违规，以及发现巨额损失后所做的对冲操作更是一个严重的违规操作，正是此次事件被热炒的主要原因。事件虽然过去，但事件的损失绝不局限于交易技术的风险损失，因为信息技术没能管理住违规操作，由此导致的合规性风险的损失巨大，损失更多地体现在无形资产价值上。

　　光大证券在此次事件主要暴露如下不足：

　　1. 淡薄的风险意识，无论从人员管理角度还是技术管理角度看，该企业的风险管理环境与其企业规模都不相称。

　　2. 自主研发团队与业务团队混合经营，初创组织的合作模式不应该发生具有一定规模的企业中。

　　3. 信息技术水平能力不足，对于有如此大额交易操作的团队，表现出来的信息技术能力水平不能胜任。

　　4. 企业整体的信息技术风险管理水平能力不足，企业对该团队的风险控制几乎没有。违规操作、违规上线等暴露出合规性风险的防护不足，也缺乏相应的合规培训。

　　光大“8.16”事件在非系统性风险上暴露了其管理、沟通、组织等多方面的不足；同时也反应程序化交易的多米诺骨牌式的系统性风险，程序交易的逻辑绝对依赖与人的智能差距在当前还是个不能跨越的智慧障碍。光大“8.16”事件的团队的一系列违规操作也反映出信息技术合规风险管理的难度及其高危害，接下来将进一步研究信息技术风险。