如何控制软件外包的风险

一个风险评估与排序的实用模型

摘 要

本文阐述了一个基于简单数学模型的实用且简便的风险评估与排序方法

什么是风险

风险即是以下三个要素发生的机会:

威胁--事件或行为，一般来自系统外部，可能在某些地方会影响固有的弱点，造成影响

弱点--系统内部考虑之中的弱点，可能在某些地方受到威胁所利用

影响--短期与长期组织影响，威胁碰巧利用弱点

由于要求一个或更多的不预测的威胁与弱点的巧合，负面影响发生的可能性是很难确定的一个系统可能很长一段时间运行有弱点(的程序)而未受影响，直到一些实际的威胁存在或利用它在给定的时间筐架内一些威胁可能比另一些威胁更可能发生(例如:简单的键盘错误比中断更易发生)类似的，一些弱点可能只在短期内存在(如:当保安从运钞车进入金库时)而别的可能会长期存在(如:银行金库警报系统没有覆盖所有入口点)影响的变化也很大:有些可能使整个组织或系统置于严重的危险之中(如火灾)；有些可能会对整体来说无关重要

保险公司也许有能力去计算某种威胁与弱点存在的可能性并预测可能受到影响的程序，但是，这也是不严密的--或许艺术性多于科学承保人赌其涵盖了所有风险:尽管给定的事件是不可预测的，但在一定时期的多数事件发生的可能性可以很大的可信度估计，大部分是基于早期的经验尽管如此，这种手段仍存在着两个重要的问题一些极度影响事件(如你的首席行政长官遭遇雷击)是很少发生以至人类的本性倾向于忽略这类事件，因此，承保人发现很难以理想的价格去销售相应政策进一步，新的条件导入新的风险，但经验不足甚至使他们预测更困难高技术主题的电子商务变化得非常快以至IT专家也要尽力跟起而不致落后承保人在风险方面做得不比猜测多

威胁与弱点的特定组合也许仅仅偶尔存在("坏运气")，十分显然，几乎没有弱点与/或威胁的系统就不大可能长期受到影响另一方面，一个脆弱的系统，一个具有许多大的潜在影响(的系统)更有可能遭到毁坏，这是风险管理的基本点，它本身是任何一个组织完好管理中的重要元素

管理者一般通过引导通缉资源转向风险缓和的活动如设置合适的控制框架，来寻求减少弱点、威胁与影响。

一个简易风险模型的来源

管理企业远远超过无风险活动。的确，承受可接受的风险（有些可能导致破产）能取得利润。正确管理的关键是知道缓和哪种风险以及何时把握机会。这就是为什么对风险有个良好的认识的重要这所在。在这里，提供一个简单的类数学模型以助计量风险。考虑风险的性质，你将得到如下的公式:

风险=威胁+弱点+影响

表面上看，该公式意味着具有高威胁、弱点或影响的系统是高风险的系统。尽管如此，是威胁与弱点的组合造成影响的存在。而对组织的破坏的程度依赖于一个事件的发生与影响的促使。用数学语言来说，逻辑与计算需要乘积而不是和，如:

风险=威胁弱点影响

包含至少两个重要因素（如:高威胁与弱点）的组合能产生比仅具较低或中等水平因素组合更高的风险。任何一个因素降为零风险将降得更大。

计算风险

为了使用模型去计算风险，你得检查与计量各单独组成要素（威胁、弱点与影响）。

最简单的方法是将这三个要素分成高（3分），中（2分），低（1分）或零（0分）。产生的风险分值在0 至27之间。作为替代，你也许宁愿用一个持续的百分数尺。如:

0% 25% 50% 75% 100% 受雷击

+- ---------- -+- ---------- -+- ---------- -+- ---------- -+ 的威胁

人受雷击 建筑物受雷击 被静电击死

使用百分数尺能得到的最大风险计分是1,000,000（100100100）。因而能为组织确定风险提供足够的详细（情况）。不论什么量度，过程是一样的。我们比较与对比风险因素，寻求一个企业价值合理延伸。一具厌风险管理者比喜风险管理者更可能估价风险，但是价值延伸应当更广泛地比较。正是这延伸赋予模型其真实的能量，允许我们去给风险排序。

实践中应用风险模型

本模型在实践环节中有许多效用，如风险评估与审计计划程序:

这个过程有两个重要的输出:一个风险排列（对组织管理者是有用的）与相匹配的排列过的审计计划（构造内部或与外部审计师工作）。“定期涮新”提供反映变化的风险因素分值更新的机会，如内部控制环境（养活弱点）的提高或新的市场压力（增加威胁）。

这个程序的理论基础使得计划审计工作与组织风险间的联系更清楚。

类似地，项目风险也能利用该模型评估以形成基本的项目风险管理。项目威胁依靠于项目的性质，但典型的包括政治、经济、社会与技术方面（被称为PEST分析）弱点包括不合适技能，刺激机制，财务或别的资源限制等。项目失败影响一般分为:

过多成本

推迟完成

顾客满意度低

该模型也能被用来联系这些因素与风险是否重要的建议，形成一个管理活动日程。风险计算应当随着取得新信息在项目过程中更新。

建立管理机构，明确外包范围，严格审查制度，加强风险监控和激励机制建设，这些措施是商业银行IT外包风险防范的重要保障。 对外包风险的把握，直接决定着 信息技术外包的成功与否。从根本上来说，对信息技术外包风险的防范过程就是对外包活动实施全面有效的管理过程。

建立外包事务管理机构 要对外包实施全面有效的管理，必须首先建立外包事务管理机构。目前，商业银行外包过程中，仅在外包决策、外包商选择、或发生了法律纠纷时，才成立临时性机构，处理相应外包事务。管理组织的不稳定造成管理人员的频繁调动和流失，削弱对外包项目的充分理解，影响了合作双方感情的建立。人员的不稳定必将造成管理策略的不连续，削弱双方合作和信任基础，给外包项目的管理和监督带来不必要的麻烦，影响外包的服务质量和进度。

外包事务管理机构应该由银行战略规划专家、外包咨询专家、各部门熟悉本行业务信息流关系的代表、信息技术专业人员、费用预算人员、法律顾问、实施管理和协调人员组成。主要负责外包前对国内、外行业、竞争对手以及自身的信息化需求进行调查研究；识别信息技术的核心竞争能力；在收益、成本和风险之间进行平衡并进行外包决策；制定外包的建设技术标准；设计外包方案，避免重复投资与信息孤岛；评价外包商的技术等级、发展能力，选择承包商；签署外包合同；对外包服务过程进行全面监督、协调和控制；处理与现有外包商的外包关系；监督并审议通过外包商的技术决策；积累外包经验并帮助制定未来的外包决策；谈判并推行未来的外包合同；使IT整体战略与不断变化的银行的整体战略保持一致。

明确IT外包范围 哪些是构成核心竞争力的信息技术，哪些是可以外包的非核心技术，外包范围的确定是商业银行信息技术外包中面临的首要问题。 JP摩根公司通过对美国商业银行的电子化发展研究，提出M1-M2-M3层信息技术构架理论（如图1所示），M1是指计算机系统的硬件、系统软件、工具软件、网络设施和其他银行使用的专用机具；M2层主要由应用软件和人机接口组成；M3层的内容主要包括业务流程重组、策略规划、应用系统集成和现有应用系统的管理和维护。M1层的技术属于技术提供商而非银行，对于商业银行来说，M1层的竞争主要表现在合并分散的数据处理中心以追求更好的规模效益；在M2层的信息化建设上，美国商业银行走了一段曲折的道路，开始采取完全自主开发的方式，在支付巨额开发成本的同时，还要承担开发失败的风险，开发完成后发现各家银行基本雷同，是一种低水平的重复建。因此进入上世纪80年代，美国商业银行不仅共同投资建设网络，实现资源共享，而且逐渐与IT公司合作开发软件或直接使用商品化的软件。经过研究发现，美国商业银行在M1和M2层的开发投入，实际收获的只是M1和M2层的技术培训，在M1和M2层领先所产生的效益不如M3层快。 借鉴美国商业银行的电子化发展经验和摩根公司M框架理论，我国商业银行在进行信息技术外包的过程中，应将M1、M2层外包，利用外包商的规模效益，降低成本，集中力量建设M3层，才能培养核心竞争力，实现特色化经营。 建立对外包商资格审查制度 外包成功的关键因素之一是选择具有良好社会形象和信誉、相关金融行业系统实施经验丰富、能够引领或紧跟信息技术发展的外包商作为战略合作伙伴。因此，对外包商的资格审查应从技术能力、经营管理能力、发展能力这三个方面着手。 技术能力：外包商提供的信息技术产品是否具备创新性、开放性、安全性、兼容性，是否拥有较高的市场占有率，能否实现信息数据的共享；外包商是否具有信息技术方面的资格认证，如信息产业部颁发的系统集成商证书、认定的软件厂商证书等；外包商是否了解金融行业特点，能够拿出真正适合商业银行业务的解决方案；信息系统的设计方案中是否应用了稳定、成熟的信息技术，是否符合银行发展的要求，是否充分体现了银行以客户为中心的服务理念；是否具备对大型设备的运行、维护、管理经验，和多系统整合能力；是否拥有对高新技术深入理解的技术专家和项目管理人员。 经营管理能力：了解外包商的领导层结构、员工素质、客户数量、社会评价；项目管理水平，如软件工程工具、质量保证体系、成本控制、配置管理方法、管理和技术人员的老化率或流动率；是否具备能够证明其良好运营管理能力的成功案例；员工间是否具备团队合作精神，外包商客户的满意程度。 发展能力：分析外包服务商已审计的财务报告、年度报告和其他各项财务指标，了解其盈利能力；考察外包企业从事外包业务的时间、市场份额以及波动因素；考察银行的外包合同对外包服务商财务状况的重要性如何；评估外包服务商的技术费用支出以及在信息技术领域内的产品创新，确定他们在技术方面的投资水平是否能够支持银行的外包项目。 对外包实施进行风险监控 信息技术外包的目的在于通过整合信息技术合作伙伴的企业资源，快速实现服务手段和服务方式的信息化，满足客户的需要。信息技术外包中产生的任何风险都会严重影响银行的形象。因此，在信息外包的全过程中要实施风险管理。 风险管理应分为四个步骤：第一步是识别外包实施中各阶段的宏观、微观层面风险，设置监控点。宏观上密切关注信息技术、外包市场的发展，以及银行自身经营环境、竞争对手外包策略、外包商经营状况的变化，防范技术、市场风险。微观层面上，听取外包商在项目实施不同阶段的报告，评估外包商运行的信息系统和相应的控制措施（如资源安全性、完整性、保密性），定期审查外包商相关的内部控制、系统开发和维护、以及应急计划措施，以保证它们符合合同要求，并且与当前的市场和技术环境相一致；了解外包服务是否及时，服务质量、服务水平是否得到提高，防范交易和信誉风险。第二步是分析造成工作偏离预定标准的问题的实质，对产生问题的原因进行调查并做出结论；第三步是拟订解决问题的可行方案，并从中选择出最好的；实施选定的方案，使外包工作回到原定的、期望的标准上。 建立对外包商激励机制 外包商的经营目标是实现利润最大化，而银行希望以公平价格获得良好的服务，因此，商业银行应制订激励机制，将其经营绩效与外包服务要求挂钩，使合作双方目标一致。可采取以下激励措施： 优质优价：根据信息技术外包的范围，按照系统正常运转的时间、效率，制定合格、满意、优质三层标准，达到不同标准给予不同价格。标准的制定应该随着技术的发展而不断提高，如果外包商在技术方面的创新能够使银行实现某些业务盈利，应给予外包商一定的奖励。这样可以鼓励外包商使用新技术、持续改进服务。

级别管理：根据对外包商的资格审查、合作时间长短、合作过程中满意程度，制订相应的评级制度，将外包商划分为准入级、合作级、伙伴级。级别评定是能上能下的，如果外包商的服务水平下降、服务质量降低，就会被降级。级别管理是希望通过一系列连续的合同来加强银行与外包商的合作关系，提醒外包商通过优质服务建立良好声誉、获得收益的重要性。

互联网的机遇和模式转瞬即逝，当你有一个好创意好想法时，就可以把想法落地实现，而这一切都是技术作为支撑，从之前的app应用到现在的小程序。

大多数的个体或企业因为技术的受限，都会选择第三方开发公司进行小程序定制开发，不管是模板二次开发还是定制开发，在和第三方合作时都存在着一定

小程序定制开发外包风险，那么企业或个人如何规避这些风险呢，本文章将为您提供一些非技术层面的借鉴，希望对您有所帮助。

在和第三方合作时，经常出现的几个问题包括开发周期被拖长，结果验证没有达到预期，沟通不及时到位等。对这几个问题我们分开来讲。

未能满足企业需求：开发完后客户发现小程序没有实现自己要求的那样，出现此类情况可能有二：一是在合作过程中，沟通不当或很少沟通，客户没有意识到沟通的重要性，就与外包开发公司展开了合作。二客户没有对外包开发公司深入了解，外包开发公司技术能力一般，客户改变不了外包开发公司，所以在选择合作时唯有谨慎考察才行。针对沟通的问题，可以这样，客户需要对自己的需求有清晰的认知，把需求具体化、细节化，确保准确传达，最好建立需求文档进行说明。

开发周期被拖延：客户找外包开发公司时，遇到了开发周期被拖延了，主要是因为小程序开发与预期不符，需要对小程序进行修改，多次反复修改，周期就有可能被拖延，这对客户的时间来说是个不小的挑战，所以在前期开发合作时，需要对开发验收标准和节点必须有明确的说明，来掌控开发进程。

项目未完成：在定制小程序时，出现了项目摆烂的情况，客户把钱也交了，最终因为客户的需求难以实现没有完成，还不退钱等。为了防止此类情况的发生，选择一家合格的开发公司变得非常重要，如何判断外包开发公司是否靠谱呢？从了解公司的基本情况开始，考察公司的成立时间，主要业务，公司人数等，还有从公司能提供的小程序定制流程和各环节的费用考虑，案例是否足够多，案例多代表了公司被认可，口碑好，技术雄厚等特点。再了解一下公司的工作氛围，是否具备技术开发能力，从沟通中对客户提供的需求能实现多少。

所以我们在找外包开发公司合作时，不但要对公司的进行详细的考察，还要对合同中出现的验收标准，违约条款，周期延长赔付等问题进行详细的说明才行。

去百度文库，查完整内容>来自用户的内容:gzdxue软件开发项目如何进行风险管理。参与过大型软件项目的人都会意识到，很多事情都有可能出错，一旦出错，可能会给项目带来伤害、损失或其他不利影响。风险是项目中发生一系列事件或不利结果的可能性。软件开发是一项高风险的活动，在项目开发过程的任何阶段都可能存在风险。主动风险管理可以使项目过程更加稳定，获得对项目的高度跟踪和控制能力，避免和转移风险或减轻风险带来的不利影响。风险管理是识别、分析、应对和监控项目风险的过程，是项目管理中一项重要的管理活动。有效实施软件风险管理是成功完成软件项目开发的保证。风险管理的实现必须包括三个要素:一是必须在项目开发计划中制定风险管理计划；第二，项目预算必须包括解决风险所需的资金；第三，在评估风险时，风险的影响也必须包括在项目计划中。下面，我们就针对软件开发过程中经常出现的风险，谈谈我们所采取的防范措施。1要求不明确。在软件开发过程中，经常会遇到需求不明确的情况。这类问题往往表现在需求未定义、需求未定义、需求描述不清晰、需求缺失、需求矛盾等诸多方面。在软件开发过程生命周期的每个阶段，需求不明确造成的浪费是最大的，必须尽快解决。很难确定用户的需求。我们经常从以下几个方面来处理需求不明确的问题:

以上就是关于IT项目风险评估的方法全部的内容，包括:IT项目风险评估的方法、IT外包有何风险及如何防范、如何控制软件外包的风险等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！