当前位置:文档之家› COBIT

COBIT

COBIT
COBIT

银行信息平台的建设是一个长期、大投入的过程,银行管理层应在过程中给予不断的关注与投入。在软件项目生命过程的实施方法论中,银行管理层应当建立项目委员会,在项目启动前深入讨论,仔细研究,具体可以参考COBIT(Control Objectives Management Guidelines Maturity )和 (CMMI)标准执行。

COBIT 由成立于1998年的 IT 治理学院 ITGI(it Governance Institute) 编制。目的在于采用先进的国际思维与标准,并以次引导和控制企业的信息技术管理。使用有效的IT治理方法可以帮助银行确定商业目标,并进一步优化企业信息技术。同时COBIT可以帮助银行管理信息技术相关的风险并掌握相关机遇。ITGI对企业管理者和董事会提供一手的研发资料、电子档案资源和学习案例。

COBIT为项目整体和项目处理框架提供了很好的实践案例,同时为项目公司提供了积极的,可管理的逻辑结构。COBIT 不同于其他软件成熟度模型,主要强调项目和项目管理人员的控制而不是管理,其主要作为在于优化IT成本、提高软件产品交付并提供了项目危机时刻的风险度量方法。

COBIT框架主要能帮助解决:

1.IT解决方案与商业需求的有效链接

2.对IT处理过程给予有效组织,并使之成为共同接受的处理模型

3.诊断主要IT资源,并给予有效放大

4.确定管理控制目标

图表 1

信息管理项目或信息管理项目群的实施,在很大程度上都是需求、资源和处理过程(交付管理)的协调问题。信息项目的成功与否都取决与信息技术治理委员会对此三项的前瞻能力和项目管理办公室(PMO)的协调能力。COBIT作为IT治理的标准,对以上三项内容进行了合理编排。COBIT 认为,在项目的初期,一切均由业务需求驱动。IT资源的调配与管理均视业务需求的范围而定,用户需求范围较小,时间较为宽裕,优先级较低,则IT仅提供有限的项目,反之,如项目范围较大,时间有限,优先级高,则IT治理委员会应当给予很高的重视,对此类项目应投入最好的人力资源和管理,并在软硬件资源上进行优先调配。各项目在得到合理的资源支持和计划后,就能遵循软件成熟度模型进行从单一到复制到有效管理和自我完善的管理、控制过程。

COBIT 的主要框架:

在明确定义需求、资源和交付处理的过程后,COBIT尚无法将理论与实际的治理方案相接轨。因为在实际的实施过程中,项目管理人员仍须对IT资源管理和IT交付处理过程进行细化。为此,

COBIT框架将整个IT项目的运维过程分为2个目标,2个要素和4个模块。2个目标包括业务目标、治理目标。2个要素包括信息和IT资源。4个模块包括:计划与组织、并购与实施、交付与支持、监控与评估。

2个目标明确了项目启动立项的目的和根源,在一般的银行项目中,项目立项和启动源于业务目标,并由业务目标转换为治理目标。

2个要素是项目控制的基本要点。项目委员会从驾驶仪表板或其他统计系统中得到项目运行的情况,并根据不同的信息调动IT资源,包括系统应用变更、信息资源、基础架构和人力资源。

4个主要模块代表了COBIT治理周期过程中的4个要点:

1.计划与组织:在此过程中定义了IT战略计划、信息架构、技术方向、IT处理过程、组

织和组织间关系、IT投资管理、通信管理、人力资源规划、质量管理、IT 风险评估与管理和项目管理。

2.并购与实施:此过程定义了自动化解决方案的斟选、应用软件的获取与维护、技术架构

的获取与维护、操作的投产与使用、IT资源采购、变更管理和应用安装。

3.交付与支持:定义管理服务范畴、管理第三方服务、管理系统性能与容量,确保业务可

持续性、确保系统安全、确定成本、用户培训、建立服务与故障管理、配置管理、问题管理、数据管理、物理环境管理和操作管理。

4.监控与评估:IT资源性能管理与评估、内部控制的监控与评估、确保系统的合规性,提

供IT治理。

图表 2

通过COBIT对业务需求和IT交付物的详细定义,金融机构IT管理部门已经形成了基本的治理、

管理框架。对于 IT交付过程,COBIT通过定义软件成熟度模型(Software Maturity Models),对项目管理和项目过程管理进行了定义。COBIT将软件成熟度分为5个阶段:

图表3

0.Non-existent(无管理阶段):没有任何意识的管理一过程,企业尚未意识到具体的问题所

在。

1.Initial(临时性诊断阶段) :企业有能力获知已存在的问题,但尚无处理标准。

2.Repeatable(有常规模式的管理阶段) : 企业对处理相同任务的不同人群已经产生了一定

的流程,但缺乏书面的沟通与培训。

3.Defined(有书面存档和有效管理的阶段) : 企业已建立了相关标准并予以制度化,同时

企业内部已经通过沟通对实施人员进行了有效培训。

4.Managed(可监控与可度量的管理阶段) :企业可通过制度监控和度量相关问题,并对此采

取行动。企业通过自动化的管理工具进行有效的管理。

5.Optimized(实现良好的管理阶段并能够自我完善的管理阶段) :处理过程基于其他优秀企

业的成熟度模型,已经过优化、提炼,可以得到持续不断的改进。

COBIT在定义了IT治理和IT项目管理过程后,针对项目启动时的一系列难题,诸如人员组织、项目计划、风险报告等均做了步骤安排和角色分配。

COBIT定义 IT处理过程、组织和关系。在大型项目的组织过程中,尤其是项目启动前的筹备阶段,企业组织中的各项高层与管理部门应被编入项目委员会内,并根据矩阵职能确定负责的范围,包括 1.负责 2.参与3.咨询 4.参考。以下5项任务的确认与分配在很大程度上影响到项目的成功与失败。

1.建立 IT组织架构,并尽量将股东与供应商包括到变更委员会或相应组织机构内

2.设计 IT 处理框架,并有效分配职能。

3.确定系统主管者(有别于最终用户)。

4.确定数据主管者(有别于最终用户)。

5.确定项目事实角色与责任,包括条线主管并明确权责分工,将责任落实到人。

大型项目的治理过程中,在人员角色分工等一系列角色分配妥当后,项目都应按项目计划有序展开。项目计划的实施还需要获得一系列的保障,包括项目过程中的监控、质量和风险的度量等。COBIT为项目计划的指定和后继管理提供了执行矩阵:

1.定义IT投资综合管理框架

2.建立和维护项目管理框架

3.建立和维护项目监控、度量和管理体系

4.建立项目章则、计划、质量控制计划、预算、交流方式和风险管理计划

5.确保高层管理人员的参与

6.确保项目的有效控制和变更控制

7.制定并确保项目实施,同时指定项目回顾机制。

COBIT在项目治理和管理上提供了很好的理论基础,在整合信用管理框架的项目实施过程中还需要根据实际情况进行部署。

整合风险管理系统架构

整合风险管理项目计划

商业银行信用风险管理的制约因素

1.实施理论基础

西方银行自上世纪70年代,布雷顿森林体系瓦解后便开始寻求自由利率、自由汇率、自由兑换等问题带来的金融风险。西方银行在经历了XXXX风险、97金融风暴、2001电子商务泡沫、2008金融危机后,逐渐建立起信用风险评级、度量和对冲的概念。

而与西方商业银行相比,我国金融行业的整体起步时间较晚。计划经济、央行信贷政策、金融业开放程度对金融机构的信用风险意识的逐步形成有非常强烈的主导作用。在这些客观因素的作用下,实施整合信用存在整体认识和主观理解上的意识阻碍。

在长期的计划经济体制影响下,我国商业银行习惯按照国家政策和央行信贷主导当年的信用计划,同时,央行为顾及到商业银行的保底收入,在每次调整利息时均会对存贷款利率保持固定息差。在央行统筹放款的大背景下,各商业银行对市场风险的顾忌相对交弱。另一方面,在20xx年以前,资本充足率并不是商业银行必须关注的主要经营指标,在缺少资本充足率的监管约束下,各商业银行对各自的坏帐恢复率缺少主动关注。

在尚未加入世界贸易组织WTO前,我国商业银行的资产业务主要集中在公司信贷业务上,发生坏帐就进行资产减值或资产处置,导致商业银行普遍缺乏主动产品组合、风险度量和风险对冲的意识。在加入WTO后,随着我国逐渐开放衍生品市场、放松汇率管制、加快外资法人银行的成立、鼓励国内银行开立海外分行后,我国开始逐步推广巴塞尔协议,并逐渐重视整合信用风险管理。

就总体而言,我国信用风险管理的理论基础尚待提高,实践环境仍需时日进行逐步建设。

2.实施范围

整合风险管理实施牵涉到前、中、后台三方的所有产品范围。这些产品的操作流程、业务规则、客户合同、计算机系统等改造都会成为影响整合信用风险框架的实施。这些情况在传统的老银行中尤其值得注意。这些银行计算机应用较早、系统架构规划较为欠缺、同时因为我国地域广大,计算机系统的分布较为零散,在缺乏数据大集中的情况下很难根据整合信用风险管理的原则对基础数据制定统一标准。

在实施计划上,主导部门应采取1. 整体规划、分期实施 2. 业务改造优先3.计算机系统同步改进的原则对业务和配套管理进行逐步改造。同时,在业务规划上宜使用1.前台系统逐一改进 2. 中台系统统一标准3. 后台系统统筹兼顾的思路。

3.组织架构

整合风险管理框架的实施首先需要组织架构的支持。在组织架构上应理清2个方面的问题:1. 必须明确框架中指定职责的负责部门。2. 商业银行尚未成立框架中的的特定部门。

我国商业银行在成立之初受到计划经济的影响,通常未设置风险管理部门,信贷方面的管理一般都由信贷部门一并统筹。风险管理部门有其一定的专业性,而筹建风险管理部门、招募风险管理团队、建立风险管理体系需要一定的时间和费用。

4.系统架构

我国幅员辽阔,地域广泛,各商业银行在计算机自动化的过程中经历了单机、分散和大集中等多个阶段。商业银行通常在不同省份使用不同的系统,系统内部通常错综复杂,跨平台、跨系统的应用众多。在实施整合信用风险框架前必须按照框架要求重新部署系统架构、整合所有数据,这显然对各家银行带来了诸多挑战,同时也延长了整合信用风险框架的实施周期。

我国商业银行信用风险管理的业务流程

我国商业银行的产品组合大多基于贷款产品,所以贷款产品基本通过如下流程进行操作:

1.业务受理:信贷员接受客户申请,准备向分行或总行申请材料。

2.市场调查:信贷员根据客户申请按照市场情况,对客户情况进行摸底,同时确定该

客户的行业利率。

3.风险评价:信贷员根据客户的情况按照经验为客户评分。

4.审查审批:信贷员向分行行长或总行信贷委员会提交报告。

5.签定协议:在得到信贷委员会批复后,信贷管理员与客户签定合约,约定放款。

6.审核发放:客户存入保证金或抵押品后由放款操作人员发放贷款。

7.贷后管理:在贷款发放后收取客户还款,或应客户违约进行不良贷款减值处理,或

直接进入抵质押资产处理阶段。

从以上的流程可以看到,我国的贷款产品生命周期非常简单,在流程中存在着诸多缺点与漏洞。

1.业务流程在很大程度上由信贷员包办,客户信息由信贷员一手掌握,并通过其对客

户和客户所属行业的主观判断对客户平分,缺少客观风险度量方式和有效组织的监

督。同时,信贷员可以对通过夸大客户抵质押产品的净现值,引导分行多放贷、放

长贷。

2.由信贷员对客户和市场进行调查。由于信贷员急于完成业务指标,存在在主观上夸

大客户和行业的赢利能力,主观降低银行所面临的风险。

3.信用评价使用信贷员或行业人员的主观评价,缺少评级模型的客观行业评价和对此

行业的风险评价。在贷前没有对客户的违约概率、违约损失和预期损失进行客观估

算,造成风险资本的计算错误,为事后计提与恢复带来了很大的困难。

4.缺乏通过贷款评级转移矩阵的使用,仅依靠信贷员的主观报告,不注重贷后的客观

评级管理与降级处理。

5.缺少按时对整体风险的重估和度量,很少使用压力测试对原有评级与预期损失进行

校正,过分依赖坏帐后的资产处理。

6.不注重风险对冲的手段,缺少事前对冲金融工具的应用,在一旦出现客观坏帐后只

能对抵押品进行处理。

总体而言,我国商业银行风险管理流程在贷前、贷中和贷后存在诸多主观因素,通

常因为理论和科学技术的问题不注重评级、度量与对冲等客观的事前的避险手段、

属于原始的、粗放型的管理方式。

贷款申请

信用评级

征信审查

产品定价

申请审批

签定合同

额度建立

抵质押品存入

开户放款

定期还款

抵质押产品重估

拖欠催收

不良贷款减值

抵债资产管理

贷款销户

抵质押品释放

整合风险管理信息系统框架的概念

相关主题
文本预览
相关文档 最新文档