快速原型方法与软件开发中的风险管理

快速原型方法与软件开发中的风险管理
快速原型方法与软件开发中的风险管理

快速原型方法与软件开发中的风险管理

Hessen was revised in January 2021

快速原型方法与软件开发中的风险管理

软件系统往往体现一定的功能,这些功能要符合一定的使用目的。现实世界是在不断变化的,而且变化的速度是越来越快,唯一不变的就是“变化”的主题。这一现实也就直接影响到了实现实际功能的软件系统,体现在需求、技术实现手段、应用环境等多个方面,这些都直接影响到了软件系统自身的稳定性。同时,由于快速变化这一事实,人们对于以后的预测能力也越来越有限,有时根本难以明确未来的需求,只能是根据环境的变化而随时调整,因此直接导致了软件生命周期越来越短这一现实,特别是应用软件,直接与这种变化紧密相连。

但是,软件开发往往需要一定的时间,一个软件系统从需求、设计、开发到投入使用,这一周期都不会很短,即从需求产生到实际能够投入使用这段时间,其本身就已经成为应用软件自身的风险,很可能当一个软件开发完成的时候,市场需求已经发生了变化,开发出来的软件已经不适用了。软件生命周期已经缩短,特别是应用软件,随着新业务的市场窗口变窄的趋势,其自身的寿命周期也在缩短。快速投放市场已经成为软件系统的首要因素。另一方面,由于快速变化的外部环境给软件产品带来的风险,成本控制也成为软件工程管理的一个重要方面,通过对需求变化的风险的评估来重新认识软件寿命周期,以合理的成本完成软件开发,也已经成为对软件产品管理者的一个挑战。

在传统的软件工程方法中,主要使用瀑布式顺序开发方法,包括需求分析和定义、系统设计、实现和单元测试、系统集成测试、运行维护等多个阶段,这一方法的优点是全面、严

谨,但最大的缺陷,就是过程一旦启动就难以适应变化。这一方法是基于一个重要的假设前提——能够提出明确的需求。当面对快速变化、甚至是根本不明确的需求时,这种假设根本上就不成立,因此这种传统的开发方法的缺点就越来越突出,特别是应用软件的开发,由于它与市场的联系更加紧密,使用这种传统的开发方法,已经难以为继。我们需要寻找一种更加快速、成本合理的软件开发方法。

快速原型方法就是这样一种开发更加迅速、更加成本合理的开发方法。在软件开发过程中,最关键的步骤就是确切定义出需求,明确软件要实现的功能是什么,而这恰恰也是最困难的过程,因为现在许多用户在初期只有一个隐约的、大致的考虑,根本不可能提出具体明确的需求。这种情况下,使用快速原型进行反复交流、细化需求,就成为一种更加有效的方法。一个软件的原型,主要是模拟重要的功能和界面,但是一般不考虑运行效率,也不考虑系统的健壮性,出错处理也考虑不多,它的目的只是为了实际描述概念中的结构,使用户能够检测与其概念的一致性和概念的可用性。

目前主要有两种快速原型方法:

·丢弃原型(Throw-away prototyping)。其目标只是为了明确需求,使用最简单的开发方法,以最低的成本实现一个可工作的系统,该系统只关注功能,不考虑开发工具、性能、容错、未来实际运行环境等。通过反复与客户交流和修改原型,使原型的功能能够充分体现客户需求。在明确了需求之后,原型就会被丢弃。以后软件的开发将根据明确了的需求按照传统的工程化方法来开发。

·进化原型(Evolutionary prototyping)。其目标就是与客户一起工作,从一个原始的需求的轮廓开始,逐步改进,最终发展成为符合实际需要的系统。采用这种方法,就需

要考虑到软件未来的运行环境等有关要求,这就要求从一开始就要对需求有一个比较清晰的认识,不能有方向性的错误。

快速原型方法存在的主要问题是:文档容易被忽略,建立原型过程中的许多工作会被浪费,项目难以计划和管理。但是这种方法的好处更大:能够适应不明确的需求,比传统的瀑布式方法要快得多,用户的介入更多,能够及早发现问题从而降低风险。在软件开发过程中,面对快速变化的市场需求和新技术发展,最大的风险往往来自对需求的分析和技术实现手段的选择,通过原型化方法,首先以合理的成本细化需求、试验技术手段,把最主要的风险降到最低,从而在总体上降低软件开发的风险,加快软件产品的形成,降低软件开发的成本。

快速原型方法的过程,特别是进化的原型方法,与软件的版本升级有些类似。随着市场需求的变化,软件版本不断升级,每升级一次,就会增加新的功能,或者引入符合发展新趋势的技术手段。但是每一个版本都是产品化的,在产品质量方面都达到了相当的要求,这与软件原型是不同的,快速原型是一个由粗到细的过程,在最终形成产品之前,不论原型被修改了多少个版本,都还不能达到产品化的要求,不能对外发布。

使用快速原型方法的最大困难就是工程管理的问题,许多具有较强管理能力的企业对快速原型方法也感到畏惧,根本原因就是其不确定性所带来的风险。但是应该知道,快速原型的方法,正是为了针对主要风险,分解风险,尽早地、低成本地降低风险。否则,如果一味地强调软件开发必须以明确的需求为前提,采用传统的瀑布式开发方法,则会面临更大的市场风险,如果以不明确的需求采用传统的开发方法,软件开发本身也必然面临着灾难性的风险。因此,快速原型方法应该成为我们软件开发过程中降低风险的一种有效的方法。

许多企业在新的软件开发需求提出时,实际已经建立了自己的信息系统的基础架构,也已经开发了类似的软件系统,因此在新产品开发中应采用的技术手段方面,已经不存在问题,这时的风险主要存在于不明确的需求上,此时采用进化的原型方法,比丢弃的原型方法会更有效。为了加强对原型化方法的开发过程的管理,可以在整个原型化过程中把每一次对需求的细化看作是一次版本升级,在每一次升级过程中,细化了的需求是明确的(虽然还不一定是最终的),这就可以采用瀑布式开发管理方法,只是这一过程的周期会非常短,而且只要不是最终版本,成本就必须控制在最低。从另一个角度来说,如果企业的规划能力比较强,对整个产品发展、信息系统建设都有比较明确的思路,这对于降低单个软件产品的风险非常有利,限制了产品的风险,为单个软件产品的设计开发,提供了很好的基础。因此,使用快速原型方法,需要充分考虑到与企业原有的规划和基础设施的关系,并注意对它们的影响。下图是一种典型的快速原型方法的工作流程。

因此,通过提高项目管理能力,针对不同情况,在不同阶段,正确运用不同的工程方法,才能有效地控制风险,使软件开发保持强大的适应变化的能力,也就保持了软件开发者的生存能力。快速原型法为我们提供了一个很好的解决办法。

最后还需要强调一点。为了是软件工程管理能够适应这种快速变化的要求,使用相应的软件工程管理软件是十分必要的。它主要有几个方面的好处:

1,建模工具和自动代码生成工具能够大大提高开发的速度。

2,配置管理工具可以有效对对软件的变更进行管理。

3,强大的测试工具可以更加有效地覆盖测试范围,提高测试的效率。

4,强化对软件开发过程中的流程管理,加强沟通协作,提高工作效率。

5,提高项目的绩效管理水平。

越是风险高的项目,就越需要引入强有力的管理工具,提高管理力度和管理水平。加强科学管理是提高风险管理水平的唯一出路。

_软件开发项目的风险管理

_软件开发项目的风险管理 我讲的主题是:软件开发项目的风险治理,因为我认为风险治理在软件项目中专门重要,又不容易做好,因此期望通过和大伙儿讨论能够有一些思路和启发。 期望在那个地点在如下几方面展开讨论: 1.在软件项目治理中如何做好风险防范 2.软件项目中的典型风险事件是哪些 软件开发项目的风险治理 众所周知,软件开发过程可分为:需求分析、设计、编码、测试、安装及爱护等几个过程(在RUP方法中:业务建模、需求、分析设计、实施、测试、部署),实际上一个完整的软件项目前后还有其它过程,在那个地点列出的只是和软件开发有关的核心过程。 软件项目的生命周期能够分为四个时期(不同行业的项目生命周期不同),即初始时期、设计时期、实施时期、收尾时期。软件开发过程在软件项目的这四个时期中的分布情形如下(括弧里面表示RUP方法中的过程): 初始时期:大部分需求分析,少部分设计(大部分业务建模和需求,少部分分析设计)

设计时期:大部分设计,少部分编码(大部分分析设计,部分实施及测试,开始考虑部署) 实施时期:大部分编码和测试,少部分设计(大部分实施及测试,部分部署) 收尾时期:安装及爱护(大部分部署) 而项目治理则贯穿在整个生命周期的每个时期。 按照PMBOK,项目治理能够从范畴治理、时刻治理、费用治理、质量治理、人力资源治理、沟通治理、风险治理、采购治理和整体治理等9个方面考虑,关于软件项目治理来讲软件配置治理(属于整体治理)、软件质量治理、软件风险治理及开发人员治理(属于人力资源治理)等四个方面的治理尤为重要,软件开发的每个时期、每个过程都要重视这几方面的治理。 下面就以软件项目的风险治理为主题展开讨论。 软件项目治理的四个时期中,在初始时期项目成功的可能性最小,风险发生的概率也就最高,然而这时候一旦估量的风险发生了,缺失是最小的,例如:在那个时期如果某种缘故突然资金来源断了(这在需求时期是专门有可能的),以至于不能连续进行项目,不得不终止项目,那么这时候的缺失只是需求分析时期的投入。随着项目的进展项目成功的可能性变大,风险发生的概率逐步变小,风险对项目的缺失逐步变大,快到收尾时期的时候风

操作风险管理系统

操作风险管理系统 巴塞尔银行监管委员会于2004年6月发布了《巴塞尔新资本协议》,将操作风险正式纳入风险管理框架之内,并对国际银行业操作风险的度量和管理提出了更深层次的要求。 为稳步推进巴塞尔新资本协议在中国的实施,推动商业银行增强风险管理能力,提升资本监管有效性,中国银监会印发了《中国银行业实施新资本协议指导意见》,要求商业银行应实施巴塞尔新资本协议。并在近年来出台了一系列关于操作风险管理的监管规章和指引,如下图: 一、方案目标 全面的操作风险管理框架包括管理与合规性组织结构、评估工具、风险跟踪与管理和用于计算经济资本、政策和实践从而降低操作风险的风险引擎。 操作风险管理解决方案在支持新巴塞尔协议合规及监管要求的同时,能够完全符合本土金融机构管理模式,有效协助用户开展风险管理活动,并促进风险管理水平的持续提升。 东南融通公司在长期跟踪研究国内外操作风险管理理论和最佳实践的基拙上,结合国内金融机构操作风险管理建设过程中积累的经验,提出一套完整的操

作风险管理解决方案,着重帮助国内金融机构解决实施全面操作风险管理时所面临的一些迫切问题: ?帮助金融机构构建符合监管和自身管理要求的操作风险管理体系; ?构建全面满足操作风险管理体系运作要求的信息化支持系统; ?提供基于成熟方法论的操作风险管理建设全程实施与支持服务。 二、方案构成 东南融通操作风险管理解决方案围绕操作风险管理战略和策略的要求制定和实施,设计思路为既符合操作风险管理流程,又遵循银行实际操作流程和生产现状,既功能全面,又自成体系,具有相对的独立性,方案由以下几个部分组成: ?损失数据收集:收集录入内部和外部损失数据,分析发生的原因、经过、影响,对损失进行分类; ?风险识别:进行风险定义和风险映射,识别关活动,进行风险导因分析、风险因素分析,识别风险; ?风险自我评估:评估发生的概率、造成的影响、影响的时间长度、造成的损失,对风险进行评级,定义评估周期; ?关键风险指标:进行关键风险指标(KRI)的定义和量化,确定其数据来源及计算方法,确定阈值、预警值; ?风险缓释控制:确定缓释方案,制定控制计划,跟踪与行动计划管理; ?资本计量:采用基础指标法、标准法、高级计量法(内部计量法、损失分布法等)进行资本计算; ?机构风险评级:根据风险评估、KRI监控和风险计量的结果,对机构的操作风险进行整体的机构风险评级; ?监管报告:提供操作风险管理全过程的风险报告,其数据来源于对风险的数据统计、风险指标的监控情况、缓释控制方案的制定和执行效果报告等。 三、实施方法论 根据巴塞尔协议对商业银行操作风险的分类和定义,以及银监会对商业银行操作风险管理的要求,操作风险管理系统的实施可以从三个角度进行。

_软件开发项目的风险管理.doc

软件开发项目的风险管理 我讲的主题是:软件开发项目的风险管理,因为我认为风险管理在软件项目中很重要,又不容易做好,所以希望通过和大家讨论能够有一些思路和启发。 希望在这里在如下几方面展开讨论: 1.在软件项目管理中如何做好风险防范 2.软件项目中的典型风险事件是哪些 软件开发项目的风险管理 众所周知,软件开发过程可分为:需求分析、设计、编码、测试、安装及维护等几个过程(在RUP方法中:业务建模、需求、分析设计、实施、测试、部署),实际上一个完整的软件项目前后还有其它过程,在这里列出的只是和软件开发相关的核心过程。软件项目的生命周期可以分为四个阶段(不同行业的项目生命周期不同),即初始阶段、设计阶段、实施阶段、收尾阶段。软件开发过程在软件项目的这四个阶段中的分布情况如下(括弧里面表示RUP方法中的过程): 初始阶段:大部分需求分析,少部分设计(大部分业务建模和需求,少部分分析设计) 设计阶段:大部分设计,少部分编码(大部分分析设计,部分实

施及测试,开始考虑部署) 实施阶段:大部分编码和测试,少部分设计(大部分实施及测试,部分部署) 收尾阶段:安装及维护(大部分部署) 而项目管理则贯穿在整个生命周期的每个阶段。 根据PMBOK,项目管理可以从范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理等9个方面考虑,对于软件项目管理来讲软件配置管理(属于整体管理)、软件质量管理、软件风险管理及开发人员管理(属于人力资源管理)等四个方面的管理尤为重要,软件开发的每个阶段、每个过程都要重视这几方面的管理。 下面就以软件项目的风险管理为主题展开讨论。 软件项目管理的四个阶段中,在初始阶段项目成功的可能性最小,风险发生的概率也就最高,但是这时候一旦预计的风险发生了,损失是最小的,比如:在这个阶段如果某种原因突然资金来源断了(这在需求阶段是很有可能的),以至于不能继续进行项目,不得不终止项目,那么这时候的损失只是需求分析阶段的投入。随着项目的进展项目成功的可能性变大,风险发生的概率逐渐变小,风险对项目的损失逐渐变大,快到收尾阶段的时候风险对项目的损失最大,随着收尾阶段的进行风险又逐渐变小。

C16083-操作风险管理工具-多套答案汇总100分

下面三套题答案都经过纠正! 一、单项选择题 1. 以下哪项属于操作风险管理范畴:( ) A. 反洗钱监控 B. 经纪业务客户异常投资行为监控 C. 自营业务投资行为合规性监控 D. 支付系统故障,且未及时启动灾备流程,导致日终交割失败 描述:操作风险定义 您的答案:D 题目分数:10 此题得分:10.0 2. 以下不属于操作风险七大类别的是:( ) A. 内、外部舞弊行为 B. 有形资产损失 C. 执行交割和流程管理 D. 声誉损失 描述:操作风险分类 您的答案:D 题目分数:10 此题得分:10.0 3. 操作风险是指() A. 因手工操作失误导致的风险 B. 因系统故障导致的风险 C. 因员工舞弊行为导致的风险 D. 以上描述均不全面

描述:操作风险定义 您的答案:D 题目分数:10 此题得分:10.0 4. 以下属于“前瞻性”风险管理工具的有:( ) A. 内部风险损失事件分析 B. 外部风险损失事件分析 C. 关键风险指标监控 D. 新业务评估 描述:操作风险管理工具 您的答案:D 题目分数:10 此题得分:10.0 5. 以下哪项不属于操作风险范畴:( ) A. 交易系统故障导致自营交易暂停20分钟,多笔委托下单无法执行 B. 投资决策失误,导致公司自营账户亏损 C. 客户在开户及尽职调查提交的文件中伪造收入信息,骗取公司为其授信开展业务 D. 离职员工就补偿事宜向公司提起劳动仲裁,公司向其进行了赔偿 描述:操作风险定义 您的答案:B 题目分数:10 此题得分:10.0 二、多项选择题 6. 以下哪些属于瑞银23亿巨亏未授权交易案暴露的内控缺陷:( ) A. 由于系统配置错误,自动发送的“删除与修改交易”统计未能发送至新的交易团队负 责人 B. 交易员将持仓簿记/隐藏在中后台未监控的账户内,使得各类风险、损益监控数据不 完整 C. 清算人员经验不足,在跟进对账差异时轻信交易员的解释,未及时跟进多笔长期巨额 差异且未及时报告主管 D. 财务人员未深入核实因遗漏和延迟簿记导致的大额的事后损益调整 描述:操作风险管理工具应用 您的答案:D,A,C 题目分数:10

软件项目开发风险

参加过项目制作的人都知道一个项目开发过程中会遇到许多困难,很多事情都会 影响一个软件开发的失败风险是在项目中发生的一系列事件或不利结果的可能性。软 件开发是一项高风险的活动,在项目开发过程的任何一个阶段都可能存在风险。采取积 极的风险管理方式,可以使项目进程更加平稳,可以获得很高的跟踪和控制项目的能力,可以规避、转移风险,或缓解风险带来的不利影响。风险管理是对项目风险进行识别、 分析、应对和监控的过程,是项目管理中很重要的管理活动,有效的实施软件风险管理 是软件项目开发工作顺利完成的保证。风险管理的达成必须包括三个要素:首先,在项 目开发计划中必须制定风险管理计划;第二,在项目预算中必须包含解决风险所需的经费;第三,评估风险时,风险的影响也必须纳入项目计划中。 下面就软件开发过程中经常发生的风险, 2.需求不明确 需求不明确是软件开发过程中经常可能遇到的问题,这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发 过程的生命周期各阶段中,需求不明确所造成的浪费是最大的,必须尽早尽可能解决。 确定用户需求是件非常困难的事情,我们常常从以下几个方面着手处理需求不明确问题:(1) 让用户参与开发 提供一个协作开发环境,让用户参与开发过程。如果条件不允许,至少应该在每次迭代 的需求分析和系统测试阶段,让客户能够参与开发。 在选择参与开发过程的用户时,一方面,要尽可能争取精通业务或计算机技术的用户参与。另一方面,如果开发的产品要在不同规模、不同类型的企业应用,应该选择具有代 表性的用户参与。 仅仅让用户参与是不够的,应该采取一定的激励措施,提高用户参与的积极性。 (2) 开发用户界面原型 用户通常不善于精确描述自己的业务需求,系统分析员需要借助白板、白纸等沟通方式,帮助用户清楚表述需求。然后,开发一个用户界面原型,以便用户确认需求。用户界面

软件开发项目的风险分析与控制

软件开发项目的风险分析与控制 摘要:本文通过对当前软件行业的风险状况进行分析,列举软件开发项目的风险来源,并进行分析,总结各类风险产生的原因和对项目成败的影响,最后给出软件开发项目在风险管理和控制的建议。 关键词:软件开发风险风险分析风险管理与控制 一、软件开发项目的风险背景 信息产业的发展是目前发展最快的行业之一,也是对社会影响最大的一个行业,它不但为我们创造了巨大的财富,而且从各个方面改变着我们的生活,达到一个行业,小到一项服务。我们不得不承认软件是二十一世纪最不可思议的产品。 伴随着软件开发技术的不断更新、软件数量的增多、软件复杂程度不断加大、客户对产品的要求也在不断的提高,随之而来的是软件开发项目给软件开发企业和需求企业带来的巨大风险。软件开发项目的成功与否会直接影响到公司的生存。这对软件开发企业来讲应该是更大的难题。一方面是业务需求更加复杂。人们对软件质量和用途的期望大幅度提高,对业务系统的要求也越来越挑剔。另一方面是开发成本不断缩减。在此形势下,风险管理与控制已成为软件开发项目成败的关键。 软件开发项目由于其具有连续性、复杂性、少参照性,无标准规范等特点,其风险程度较高。目前国内的大多数软件开发企业还缺乏对软件开发项目的风险认识,缺少进行系统、有效的度量和评价的手段。据有调查数据显示,有15—35%的软件项目中途被取消,剩下的项目不是超期就是超出预算或是无法达到预期目标。另外,软件项目因风险控制和管理原因失败的约占90% ,可见,软件风险控制与管理在目前的软件开发项目中的重要性。 二、软件开发项目的风险来源及对项目成败的影响 软件开发项目风险是指在软件生命周期中所遇到的所有的预算、进度和控制等各方面的问题,以及由这些问题而产生的对软件项目的影响。软件项目风险经常会涉及许多方面,如:缺乏用户的参与,缺少高级管理层的支持,含糊的要求,没有计划和管理等,总体概括下来应该由五大方面。

软件开发项目的风险管理

-------------------------------------------------------------------------------------------------------------------------------------------- 软件开发项目的风险管理 原作者:李艺兰 1月27日参加了项目管理联盟组织的‘北京项目管理爱好者聚会’,我被易风邀请做了一个主题演讲,其实不是什么演讲,只是结合理论谈了自己的一些想法和工作中遇到过的经验教训,更主要的目的是给大家出一个讨论和交流的主题,希望能起个抛砖引玉的作用。 我讲的主题是:软件开发项目的风险管理,因为我认为风险管理在软件项目中很重要,又不容易做好,所以希望通过和大家讨论能够有一些思路和启发。 现在把我准备的内容整理帖出来,希望在这里继续讨论,大家在如下几方面多展开讨论:1.在软件项目管理中如何做好风险防范 2.软件项目中的典型风险事件是哪些 软件开发项目的风险管理 众所周知,软件开发过程可分为:需求分析、设计、编码、测试、安装及维护等几个过程(在RUP方法中:业务建模、需求、分析设计、实施、测试、部署),实际上一个完整的软件项目前后还有其它过程,在这里列出的只是和软件开发相关的核心过程。 软件项目的生命周期可以分为四个阶段(不同行业的项目生命周期不同),即初始阶段、设计阶段、实施阶段、收尾阶段。软件开发过程在软件项目的这四个阶段中的分布情况如下(括弧里面表示RUP方法中的过程): 初始阶段:大部分需求分析,少部分设计(大部分业务建模和需求,少部分分析设计) 设计阶段:大部分设计,少部分编码(大部分分析设计,部分实施及测试,开始考虑部署)实施阶段:大部分编码和测试,少部分设计(大部分实施及测试,部分部署) 收尾阶段:安装及维护(大部分部署) 而项目管理则贯穿在整个生命周期的每个阶段。 根据PMBOK,项目管理可以从范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理等9个方面考虑,对于软件项目管理来讲软件配置管理(属于整体管理)、软件质量管理、软件风险管理及开发人员管理(属于人力资源管理)等四个方面的管理尤为重要,软件开发的每个阶段、每个过程都要重视这几方面的管理。下面就以软件项目的风险管理为主题展开讨论。 ---------------------------------------------------------精品文档---------------------------------------------------------------------

操作风险计量

导读|实施更具有风险敏感度的操作风险高级计量法,对中国银行业是迫在眉睫的任务;而将计量成果应用于操作风险管理实践,则是一项长期任务 2014年4月,经银监会批准,交通银行成为国内首批操作风险标准法达标的商业银行,标志着其操作风险管理体系已与国际标准实践模式接轨,管理水平得到了监管机构的认可。 操作风险标准法代表着先进的操作风险管理模式 直到近一二十年才被国内外银行业作为一项专门的风险进行研究。巴塞尔委员会和银监会相关指引将其定义为“由不完善或有问题的内部程序、员工和信息科技系统,以及外部事件所造成损失的风险,包括法律风险,但不包括策略风险和声誉风险”。 基本指标法、标准法和高级计量法。其中,基本指标法要求银行按照过去三年平均总收入的15%计量操作风险资本要求。标准法允许银行将其所有业务分为八大条线,分别设置能够体现操作风险差异的资本系数,每个条线的收入分别乘以相应系数,加总后即为操作风险资本要求。高级计量法则要求银行基于内部损失数据、外部损失数据、情景分析、业务经营环境和内部控制因素,建立能充分反映本行操作风险实际情况的内部计量模型,以此来确定操作风险所需资本要求。 标准法和高级计量法作为操作风险计量的高级方法,均需要经银监会核准后才可实施。实施这两类方法,银行必须具备相应的数据处理、统计分析和模型研发管理等方面的基础。更为重要的是,银行必须在操作风险管理水平上达到资本办法所提出的基本要求。 这些要求是对国际先进银行操作风险管理实践经验的总结,代表了操作风险管理的国际标准实践水平。因此对银行而言,核准实施操作风险标准法,不仅仅代表操作风险资本计量方法的改变和资本的节约,更代表操作风险管理已达到或接近于国际银行的平均水平。 交通银行已经建成全面覆盖、规范标准的操作风险管理体系 风险治理上,构建职责明确的操作风险管理架构。董事会承担监控操作风险管理有效性的最终责任。 工具应用上,实现操作风险管理三大工具的全行推广。风险与控制自我评估(RCSA)、关键风险指标(KRI)、操作风险事件收集(LDC),是实现操作风险识别、监测、控制、缓释的循环管理的主要手段,也是国际公认的标准化管理工具。 资本管理上,实施操作风险标准法并应用于内部考核。 文化建设上,多种手段推动操作风险管理文化深入人心。 管理提升上,注重增强标准化操作风险管理工具的应用实效。交通银行始终高度重视操作风险管理体系与业务管理、内部控制的紧密结合,不断增强对业务流程优化的支持力度。 人员管控上,助力提升员工行为规范和专业人员资质。操作风险标准管理工具的应用推广,有力地支持了各业务领域的员工行为管理和专业能力培养。

操作风险管理工具应用

一、单项选择题 1. 以下哪项属于操作风险管理范畴:( ) A. 反洗钱监控 B. 经纪业务客户异常投资行为监控 C. 自营业务投资行为合规性监控 D. 支付系统故障,且未及时启动灾备流程,导致日终交 割失败 描述:操作风险定义 您的答案:D 题目分数:10 此题得分:10.0 2. 以下不属于操作风险七大类别的是:( ) A. 内、外部舞弊行为 B. 有形资产损失 C. 执行交割和流程管理 D. 声誉损失 描述:操作风险分类 您的答案:D 题目分数:10 此题得分:10.0 3. 操作风险是指() A. 因手工操作失误导致的风险 B. 因系统故障导致的风险 C. 因员工舞弊行为导致的风险 D. 以上描述均不全面 描述:操作风险定义 您的答案:D 题目分数:10 此题得分:10.0 4. 以下属于“前瞻性”风险管理工具的有:( ) A. 内部风险损失事件分析 B. 外部风险损失事件分析 C. 关键风险指标监控 D. 新业务评估

描述:操作风险管理工具 您的答案:D 题目分数:10 此题得分:10.0 5. 以下哪项不属于操作风险范畴:( ) A. 交易系统故障导致自营交易暂停20分钟,多笔委托下 单无法执行 B. 投资决策失误,导致公司自营账户亏损 C. 客户在开户及尽职调查提交的文件中伪造收入信息, 骗取公司为其授信开展业务 D. 离职员工就补偿事宜向公司提起劳动仲裁,公司向其 进行了赔偿 描述:操作风险定义 您的答案:B 题目分数:10 此题得分:10.0 二、多项选择题 6. 以下哪些属于瑞银23亿巨亏未授权交易案暴露的内控缺陷:( ) A. 由于系统配置错误,自动发送的“删除与修改交易” 统计未能发送至新的交易团队负责人 B. 交易员将持仓簿记/隐藏在中后台未监控的账户内,使 得各类风险、损益监控数据不完整 C. 清算人员经验不足,在跟进对账差异时轻信交易员的 解释,未及时跟进多笔长期巨额差异且未及时报告主管 D. 财务人员未深入核实因遗漏和延迟簿记导致的大额的 事后损益调整 描述:操作风险管理工具应用 您的答案:D,A,C 题目分数:10 此题得分:10.0 7. 以下不属于“业务中断及系统失灵”类别操作风险事件的是: ( ) A. 光大证券“乌龙指”案 B. 巴黎银行反洗钱舰空流程漏洞,被美国监管机构处以

质量风险管理常用工具的概念和模板

质量风险管理常用工具的概念和应用模板(一)预先危害分析: 1、概念: 1.1.严重性的定义和排列:严重,主要,次要,可忽略; 1.2.发生频次(可能性)的定义和排列:频繁,可能,偶尔,罕见; 1.3.风险的水平和定义: 高:此风险必须降低; 中:此风险必须适当地降低至尽可能低; 低:考虑收益和支出,降低至尽可能低; 微小:通常可以接受的风险。 xxxxxxx的质量风险管理 一、文件编号:FG-CFSS-002 二、目的: 三、组织:质量风险管理小组组长:组员: 四、法条依据:GMPxxxxxxx条。 五、管理工具:预先危害分析(PHA)。 六、风险分析表: 七、沟通: 意见书面通知总经理和设备工程部,建议召开专题研讨会。 八、审核:进行中 接受:不接受:整改后接受: 十、资料保存地点:

本资料输出二份,总经理一份,质保部一份,模板资料保存于质保部电脑软件中。 4、潜在应用领域: 4.1.当实际情况不允许使用更进一步的技术来分析现存系统或对危害源进行有限排序时,可应用PHA。 4.2.它也可被用于产品、工艺和设备的设计,也可用于评估从某一类别的产品,到某一级别的产品,直至某种产品的危害种类。 4.3.PHA最长应用于项目的早期开发阶段,此时在设计的细节以及运行程序方面的信息比较缺乏,因此,它经常成为进一步分析的基石。 (二)失败模式效果分析: 1、概念: 1.1.风险得分: 严重性×可能性×可测定性=风险得分 1.2.失效模式效果分析图: 失效模式效果分析评分(3级法) 1.3.失效模式效果分析的矩阵图:(3级法) 失效模式效果分析矩阵 2、失败模式效果分析模板: xxxxxx的质量风险管理 一、文件编号:FG-WL-01-001 二、目的:对物料管理的目的、范围、内容进行合理的规定,避免遗漏、混淆和差错。 三、组织:质量风险管理小组组长:组员: 四、法条依据:GMP 第xxx条。 五、质量风险管理工具:失效模式及影响分析(FMEA)。 六、质量管理分析表:

软件开发项目的风险管理

软件开发项目的风险管 理 文件编码(008-TTIG-UTITD-GKBTT-PUUTI-WYTUI-8256)

软件开发项目的风险管理 我讲的主题是:软件开发项目的风险管理,因为我认为风险管理在软件项目中很重要,又不容易做好,所以希望通过和大家讨论能够有一些思路和启发。 希望在这里在如下几方面展开讨论: 1.在软件项目管理中如何做好风险防范 2.软件项目中的典型风险事件是哪些 软件开发项目的风险管理 众所周知,软件开发过程可分为:需求分析、设计、编码、测试、安装及维护等几个过程(在RUP方法中:业务建模、需求、分析设计、实施、测试、部署),实际上一个完整的软件项目前后还有其它过程,在这里列出的只是和软件开发相关的核心过程。 软件项目的生命周期可以分为四个阶段(不同行业的项目生命周期不同),即初始阶段、设计阶段、实施阶段、收尾阶段。软件开发过程在软件项目的这四个阶段中的分布情况如下(括弧里面表示RUP方法中的过程): 初始阶段:大部分需求分析,少部分设计(大部分业务建模和需求,少部分分析设计) 设计阶段:大部分设计,少部分编码(大部分分析设计,部分实施及测试,开始考虑部署) 实施阶段:大部分编码和测试,少部分设计(大部分实施及测试,部分部署) 收尾阶段:安装及维护(大部分部署) 而项目管理则贯穿在整个生命周期的每个阶段。 根据PMBOK,项目管理可以从范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理等9个方面考虑,对于软件项目管理来讲软件配置管理(属于整体管理)、软件质量管理、软件风险管理及开发人员管理(属于人力资源管理)等四个方面的管理尤为重要,软件开发的每个阶段、每个过程都要重视这几方面的管理。 下面就以软件项目的风险管理为主题展开讨论。 软件项目管理的四个阶段中,在初始阶段项目成功的可能性最小,风险发生的概

风险管理方案文件.doc

风险管理策划方案 一、项目风险管理过程: 风险规划项目风险管理的计划 风险事件描述 风险识别 有哪几类风险 风险事件的后果有多大 风险估计 项目哪些部分会遭受风险 风险发生概率有多大 风险管 理过程 确定风险的先后顺序(风险坐标图) 评价风险之间的因果关系 评价风险损害的程度(风险分级:重 风险评价 大风险、一般风险、轻微风险) 评价风险转化的条件 应对风险的计划 风险应对 应对风险的措施 风险监视 风险监控 风险控制 确定循环的时机 风险规划:是在项目正式启动前或启动初期,对项目风险管理的一整套计划,主要考虑因素有:项目图表、风险管理策略、预定义的角色和职责、风险容忍度、风险管理模板和工作分 解结构图WBS等。成果是形成风险管理计划文件 风险规划目的:风险规划是一个迭代过程,包括评估、控制、监控和记录项目风险的各种活动,其结果就是风险管理计划,通过制定项目规划,实现以下目的: (1)尽可能消除风险 (2)隔离风险并使之尽量降低 (3)制定若干备选行动方案 (4)建立时间和经费储备以应付不可避免的风险

风险规划的主要内容: 1、方法 确定项目风险管理使用的方法(风险控制、财务安排)、工具和数据资源,这些内容可随项目阶段即风险评估情况做适当调整。 2、人员 明确风险管理活动中领导者、支持者及参与者的角色定位、任务分工及其个自的责任、 能力要求。(设置项目风险管理组织架构) 3、时间周期 界定项目生命周期中你那个风险管理过程的各运行阶段及过程评价、控制和变更的周期或频率。 4、类型级别及说明 定义并说明风险评估和风险量化的类型级别。 5、基准 明确定义由谁以何种方式采取风险应对行动。 6、汇报形式 规定风险管理中各过程中应汇报或沟通的内容、范围、渠道及方式。(风险管理报告)7、跟踪 规定如何以文档方式记录项目过程中风险及风险管理的过程,风险管理文档可有效用于对当前项目的管理、项目的监控、经验教训的总结及日后项目的指导等。 风险规划的过程活动 (1)设定可能出现的严重风险。(对可能导致风险发生的事件的设想) (2)制定风险应对备用方案。 (3)选择风险应对途径. (4)制定风险行动计划。(将风险应对途径、所需的资源和批准权利编为文档) (5)确定风险模板。(规定风险管理基本程序、风险的量化目标、风险告警级别、风险的控制标准等,使风管标准化、程序化、科学化) (6)确定风险数据库模式(数据库包括:数据库结构和数据文件,项目风险数据库应包含项目全周期过程所有的相关活动) 规划技术和工具 主要工具:召开风险规划会议。参加人包括项目总、负责项目风险管理团队成员(项目运 营对接人),通过会议,决定风管方法、工具、报告和跟踪形式以及具体的时间计划等。 网络计划技术、WBS、关键风险指标管理法 2、风险识别:确定何种风险可能影响项目,并将这些风险特性整理成文档,进行合理分类。风险识别特点: 全员性、系统性、信息性、综合性。 项目开发各阶段中主要风险和应对: 1、投资决策中风险 2、融资中的主要风险

软件项目风险管理研究

软件项目风险管理研究 [内容摘要]随着软件产业的迅速发展,软件的规模越来越大,复杂性也越来越高,风险变得更加难以控制,最终导致软件项目失败的结果越来越常见。如何对软件项目风险因素进行分析并有效地规避风险,从而致使项目顺利成功是进行软件风险管理的主要课题之一。只有充分地理解和学习软件风险管理的理论知识,同时在实践中不断地积累经验才能有效地进行风险防X和控制,达到减少风险的影响程度和实现利益最大化追求的目的。 本文从分析国内外软件风险管理的发展现状入手,详细地按照软件生命周期各阶段将软件项目风险进行分类,并总结对比分析了国外经典软件风险管理模型,同时介绍了软件风险管理全过程,同时基于经典软件风险管理模型,提出了改进的软件风险管理模型和方法,并根据自身经验对如今国内企业提出软件风险管理一些建议和意见。 [关键词]项目管理;软件风险;风险管理

1.研究背景 随着经济全球化的不断深入,以信息技术为依托的知识经济初见端倪,各国都在实施信息化带动工业化的发展战略,软件行业成为许多国家的支柱产业,软件业的发展程度从某种意义上体现了该国的综合国力,决定着国家未来的国际竞争地位。软件是一种特殊的逻辑产品,不具备实体的可见性,它是人经过智力劳动而产生出来、具有特殊性质的复杂事物川。一些调查表明,约的软件项目开发超出估计时间,大型项目平均超出交付时间,以上的软件项目开发费用超出预算。软件项目成功的几率要远远低于其它任何工程项目,软件行业面临着所谓的“软件危机”。在软件产品开发过程中存在着众多不确定因素,这些因素使得软件项目比其它工程项目具有更高的风险。从学科发展角度来看,软件工程的形成得益于人们用工程化思想看待软件产品的开发,软件工程的产生又使得软件项目管理学科应运而生。软件项目管理的出现使所谓的“软件危机”得到了一定程度的缓解和控制。 项目管理的目标是在有限资源标注条件下,保证项目时间进度、质量、成本达到最优化。软件项目管理的主要目标是确保软件产品能够按预期方案交付,同时还要满足用户需求。软件项目风险管理的目的是要找出导致项目需求不明晰、不能按进度计划及时交付、产品质量存在缺陷、开发费用超支等各种不良后果的风险因素,对风险因素及可能造成的后果和危害进行定性和定量分析,从而为软件项目管理人员等提供有效的风险控制方案和措施,使其对软件项目的损失或影响降到最低程度或使决策者可以接受的程度。因此,软件项目风险管

风险管理的工具有哪些

风险管理的工具有哪些 [质量] 风险管理工具HACPP 的应用流程 第一步流程:组建HACCP 小组 药厂必须确保在制定有效的HACCP 计划的时候有和指定产品相关的知识,所以必须由多部门多学科成员组成的小组,包括研发、生产、质量控制、质量保证、质量保证、微生物、工程、物流控制和其他等等。在特殊的情况下,甚至可以聘请外部的专家作为小组成员。 小组成员必须可以履行以下职责: 1、进行危害分析; 2、确认潜在危害 3、确认必须控制的危害 4、推荐控制方法和可接受标准 5、执行监控和对监控结果进行确认 6、推荐合适的整改措施来应对发生的偏差 7、确认HACCP 计划。必须定义HACCP 计划的范围,必须描述涉及的工艺环节,确认危害的种类。 第二部流程:描述产品和工艺 必须详细完整的描述产品和工艺,包括所有相关的质量信息,比如组成、物理/化学特性、结构、PH 值、温度、清洗方法,灭菌/抑菌处理方法、干燥、过筛、混合、混粉、包装和存储

的条件等等。还必须描述分销和运输的方法,特别是对于那些热敏感的产品。 第三部流程:确认用途 这里用途指的是产品的最终用户或消费者的用途。在特殊情况下,必须考虑弱势人群的情况。 第四部流程:构建流程图 HACCP 小组必须构建流程图,必须涵盖工艺中的所有操作和运作。当针对一个给定操作应用HACCP 时,必须考虑其上步和下步操作。 第五步流程:现场确认流程图 HACCP 小组必须现场确认操作的所有流程和耗时和流程图完全一致,有所的流程图变更和改进都是合适的,但是必须记录归档。 第六步流程:列出所有潜在的危害,进行危害分析,考虑测量控制确认危害的方法。 当进行危害分析的时候,必须区分对待安全和质量的考虑角度。HACCP 小组必须将生产环节的所有潜在危害都列出来。必须根据危害的特性进行分析,确认可减少或降低的分线限度。 完整的危害分析必须有有效的控制点。建议采用两部进行危害分析。在第一个阶段,小组必须审核和产品相关的物料、运作、设备、存储、分销和最终用途。潜在的危害必须指明或提出控制。必须尽可能包括:

软件开发项目风险管理的几点体会

参与过大型软件项目的人都会认识到许多事情都可能出错,一但出错就可能给项目带来危害、损失或其它不利影响。风险是在项目中发生的一系列事件或不利结果的可能性。软件开发是一项高风险的活动,在项目开发过程的任何一个阶段都可能存在风险。采取积极的风险管理方式,可以使项目进程更加平稳,可以获得很高的跟踪和控制项目的能力,可以规避、转移风险,或缓解风险带来的不利影响。风险管理是对项目风险进行识别、分析、应对和监控的过程,是项目管理中很重要的管理活动,有效的实施软件风险管理是软件项目开发工作顺利完成的保证。 风险管理的达成必须包括三个要素:首先,在项目开发计划中必须制定风险管理计划;第二,在项目预算中必须包含解决风险所需的经费;第三,评估风险时,风险的影响也必须纳入项目计划中。 下面就软件开发过程中经常发生的风险,谈谈我们采取的预防措施。 2.需求不明确 需求不明确是软件开发过程中经常可能遇到的问题,这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发过程的生命周期各阶段中,需求不明确所造成的浪费是最大的,必须尽早尽可能解决。确定用户需求是件非常困难的事情,我们常常从以下几个方面着手处理需求不明确问题: (1) 让用户参与开发 提供一个协作开发环境,让用户参与开发过程。如果条件不允许,至少应该在每次迭代的需求分析和系统测试阶段,让客户能够参与开发。

在选择参与开发过程的用户时,一方面,要尽可能争取精通业务或计算机技术的用户参与。另一方面,如果开发的产品要在不同规模、不同类型的企业应用,应该选择具有代表性的用户参与。 仅仅让用户参与是不够的,应该采取一定的激励措施,提高用户参与的积极性。 (2) 开发用户界面原型 用户通常不善于精确描述自己的业务需求,系统分析员需要借助白板、白纸等沟通方式,帮助用户清楚表述需求。然后,开发一个用户界面原型,以便用户确认需求。用户界面原型的作用仅仅是收集用户需求,不应该再作它用,也不要给用户造成系统快要实现的错觉。 (3) 需求讨论会议 对于用户分布广、用户量大的项目,要全面收集用户需求,往往很困难,通常采取需求研计会议方式进行需求确认。通过在会议前几周调查各地、各部门用户需求意见,然后集中各地或各部门的用户代表,举办一次需求研讨会,通过会议方式收集需求。本方法适合于具有一定信息系统使用经验的用户。 (4) 强化需求分析与评审 首先,需求分析是项目成功的基础,需要引起足够的重视,并分配充足的时间和人力,要让有经验的系统分析员负责,切忌让项目新手或程序员负责。其次,要进行需求评审,尽可能让用户参与需求评审,不要让需求评审流于行式。第三,也是最重要的一点,通过评审的需求规格说明书,要让用户方签字,并作为项目合同的附件,对双方都具有约束力。在公司内部要将

管理会计应用指引第 号——风险管理

附件5: 管理会计应用指引第700号——风险管理 (征求意见稿) 第一章 总 则 第一条 为了加强企业风险管理,推动相关管理会计工具方法在风险管理领域的有效应用,根据《管理会计基本指引》,制定本指引。 第二条 企业风险管理,是指企业对风险进行有效评估、预警、应对,为企业风险管理目标的实现提供合理保证的过程和方法。企业风险管理并不能替代内部控制,企业应当建立健全内部控制制度,并作为风险管理的工作基础。 企业风险,是指不确定事项对企业实现战略与经营目标产生的影响。 第三条 企业进行风险管理,一般应遵循以下原则: (一)合规性原则。企业风险管理应符合相关政策的要求和监管制度的规定。 (二)融合性原则。企业风险管理应与企业的战略设定、经营管理和业务流程相结合。 (三)全面性原则。企业风险管理应覆盖企业的所有的风险类型、业务流程、操作环节和管理层级与环节。 (四)重要性原则。企业应对风险进行评价,确定需要进行重点

管理的风险,并有针对性地实施重点风险监测,及时识别、应对。 (五)平衡性原则。企业应权衡风险与业绩和风险管理成本与风险管理收益之间的关系。 第四条 企业可根据风险的来源、影响、性质、责任主体等不同标准,建立起符合风险管理需要的,满足系统性、完整性、层次性、可操作性、可扩展性等要求的风险分类框架。 第五条 风险管理领域应用的管理会计工具方法,一般包括风险矩阵、风险清单等。 企业可结合自身的风险管理目标和实际情况,单独或综合应用不同风险管理工具方法。 第二章 应用环境 第六条 企业应强化风险管理意识,形成与本企业经营状况相适应的风险管理理念,培育和塑造良好的风险管理文化,建立风险管理培训、传达、监督和激励约束机制,将风险管理意识转化为员工的共同认识和自觉行动。 第七条 企业应根据相关法律法规的要求和风险管理的需要,建立组织架构健全、职责边界清晰的风险管理结构,明确董事会、监事会、经营管理层、业务部门、风险管理部门和内审部门在风险管理中的职责分工,建立风险管理决策、执行、监督与评价等职能既相互分离与制约又相互协调的运行机制。 第八条 企业应建立健全能够涵盖风险管理主要环节的风险管理

软件项目风险管理

软件项目风险管理 摘要:软件项目风险管理从原先被人忽视到目前的热捧,人们也从原来对它毫无作用到现在对软件的编译成功起着不容忽视的作用。为了防止骚扰软件项目以及调试的过程和产品制定的一系列规则,同时也是对软件项目、调试过程和产品有影响的风险进行评估和控制的过程。随着软件业的兴起,对软件项目风险管理研究的人也越来越多,因此关于这方面的理论也层出不穷,因此本文根据软件项目风险管理的相关理论,建立了本论文研究思路。 关键词:软件风险;风险管理;风险识别;风险分析;风险跟踪 1 风险管理的背景 1.1 风险的定义 风险定义有好几种,一是不希望事物发生变化,二是事物存在很多的,三是事件产生的影响。可以概括为“人们因对未来行为的决策及客观条件的不确定性而可能引起的后果与预定目标发生多种负偏离的综合。”公式表现为:风险f(事件,不确定性,后果)。用数学表达式则为:R=f(s,P,X),其中R表示风险,S表示时间,P表示不利事件发生的概率,X表示该事件发生的后果。 1.2 风险管理的背景 随着社会对软甲的需求增大,软件的开发技术不断更新,难度不断增大,但软件的数量却依然增加很多,同时随着社会节奏加快,软

件的供应商需要提供不间断的软件更新服务。但与此同时,各种难度的上升,给企业在开发软件的过程中加大了风险。软件项目能否开发成功,关系着一个企业的生死存亡。但矛盾的是,随着开发软件的业务增大,但对软件的质量和用途也随之提高,这对软件开发商造成了巨大的压力,在这种情况下,软件风险管理和控制成为软件开发成败的关键点。 根据有关资料调查显示,有百分之十五到百分之三十五的软件项目在开发的过程中被取消,剩下的软件项目有的是没有在预期内完成而夭折,或者又是软件开发的过程中超出了经费的预算。除此之外还有软件项目因为风险管理和控制失败的大约占百分之九十。目前国内的大多数软件开发企业还缺乏对软件开发项目的风险认识,缺少进行系统、有效的度量和评价的手段。所以能建立有效的风险识别、风险分析、风险计划、风险跟踪和风险对策的机制,是有效提高软件开发成功率的方法之一。 2 风险管理的内容 为了最大化的减少软件风险的发生,可对软件项目进行风险管理。而软件项目风险管理过程是指软件风险从认识到采取措施的过程包括风险识别、风险分析、风险计划、风险跟踪和风险对策等,从而将可控因素最大化,将不可控因素到最小,从而对未知的风险消灭,从而对风险进行回避或者缓解。 2.1 风险识别 风险识别的常用方法通常有现场观察法,财务报表法、环境分析

操作风险管理发展的三条主线

操作风险管理发展的三条主线 巴塞尔新资本协议提出对操作风险计提监管资本,勾勒出了包括市场风险、信用风险和操作风险的全面风险管理框架,标志着银行风险管理发展到了新的历史阶段。尽管将操作风险作为独立的风险范畴进行系统研究是近些年的事,但操作风险并不是一种新的风险, 它同银行的历史一样悠久,伴生于银行的各项经营活动,对操作风险的管理活动一直是银行管理的重要内容,并形成了一些重要的实践和理论成果。研究和梳理这些管理成果对深化操作风险研究具有重要的意义。笔者认为商业银行操作风险管理实践沿着公司治理、内部控制和风险管理三条主线发展演进,并最终整合形成统一的操作风险管理理论体系。 一、公司治理 公司治理(Corporate Governance)这一术语在20 世纪80 年代正式出现在英文文献中。公司治理起源于对现代企业随着所有权和经营权的分离而产生的委托代理问题的关注。公司治理是现代公司企业的必然产物,它的出现和演化与现代公司制企业的产生和发展如影相随,并受外部环境的影响。现代企业所有权和控制权相分离,由此产生了委托人(投资者、外部人)与代理人(管理者、企业家、内部人)的代理关系。一般认为,掌握控制权的管理者(经理)会采取偏离股东利益的行动。他们往往努力不够,比如在外部活动上耗费更多的资源,只是为了方便而是企业中人浮于事,忽略内部控制

等。他们可能通过构建企业帝国、享受奢侈品等来获得个人利益的满足,甚至可能通过贪污养老金、向关联方支付不恰当的转移价格、参与内部交易等手段来为个人牟取利益。这就是代理问题。委托代理问题被认为是操作风险的重要根源。因此,公司治理一开始就同防范操作风险密切相关。公司治理的每一步发展往往都是针对公司失败或者系统危机做出的反应。例如,1997年的亚洲金融危机使人们对东亚公司治理模式有了清醒的认识;2001 年以安然、世界通信事件为代表的美国会计丑闻暴露了美国公司治理模式的重大缺陷。这些治理失败 的案件往往都是因为舞弊、欺诈或者不胜任等引起,而这些事件又促进了公司治理的改进。 公司治理通过协调各相关方利益来形成有效的激励与约束,进而达到规范企业行为,防范操作风险的目的。狭义的公司治理被认为是指公司董事会的功能、结构、股东的权利等方面的制度安排。主要解决所有权与控制权的分离所产生的委托代理问题。随着公司治理认识的深化,人们认识到股东与管理者的冲突只是诸多利益相关者冲突中的一种,需要从更广阔的视野来考察公司治理。现代公司治理关注与众多利益相关者(Stakeholders) 之间的利益平衡,科克伦(Philip L.Corchran) 和沃特克(Steven L.Wa-rtick) 在1988年发表的《公司治理一一文献回顾》一文中指出:“公司治理问题包括在高级管理层、股东、董事会和其他利益相关者的相互作用中产生的具体问题。” 现代企业的一个重要的特点是其社会性不断加强,企业问题涉及众多的利益相关者。对银行来说更是这样,金融是现代经济中的核

相关文档
最新文档