IT应用系统全生命周期的风险管理
信息化进程中企业的运营越来越多依靠各种IT应用系统,应用系统可以给企业带来管理上的提高和竞争力的改善,但我们也应该看到,信息化之路上充满风险,更多的应用系统规划、实施和运行过程充满了的各种艰难和实施效果的差强人意,甚至是失败等惨痛教训。据麦肯锡公司最近公布的一项研究报告称,在最近10多年,美国经济确实得到了提高,但促成这一转变的能量主要来自少数几个商业领域,与人们普遍预料的相反,对IT行业的高额投资并不是创造美国生产力增长"神话"的主要力量。在我国也面临着这样的困境:信息化已经发展了近20年,给人更多的感受是政府和企业热度很高,但最终实施各类应用系统的企业并没有体验到很多成功的喜悦,达到预期目标的更是寥寥无几。
信息化之路上充满风险,这些风险包括哪些方面?有什么方法可以有效地管理这些风险,使企业能预先将风险尽可能降低?
1 IT应用系统中的风险
所谓风险,是事件发生的不确定性及其后果的综合。这可能是一个希望出现的事情,一个具有潜在的积极影响的机会,或是一个不希望出现的事情或具有潜在消极结果的威胁。一般来说,更需要引起注意的是后者。应用系统的风险主要是指由于各种因素导致应用系统没有达到预期效果的各种情形。
IT应用系统中的风险有各种不同的分类方法,可以分为不同类型,例如技术风险和管理风险等,目前应用系统中主要面临和经常可能发生的风险主要有:
缺乏规划或规划不合理;
项目预准备不充分,如硬件及软件选型错误、合作伙伴能力不足等;
设计流程缺乏有效的控制环节;
系统内各个子系统之间不能很好衔接;
实施计划不完善,过程控制不严格,阶段成果未达标;
新系统和组织内其它系统有冲突;
实施效果未做评估或评估不合理;
系统安全设计不完善;
灾难防范措施不当或不完整,容易造成系统崩溃;
系统退役后的处理不当引起的泄密等。
2 将风险管理集成到应用系统生命周期中的好处
虽然可以在任何时刻制定风险管理计划,但人们往往着重于对系统运行中风险的管理和维护,往往忽视系统启动前,开发和退出后的潜在风险,在系统生命周期的开始阶段制定计划是一个值得推荐的做法。风险管理与系统的其它方面一样,在整个系统生命周期各阶段都进行计划是最好的管理方式。计算机界长期以来认同的原则就是,系统设计完成后在其中增加特性比在系统初始的设计阶段包含该特性要多花费十倍的时间和费用。在系统规划初期尽早进行风险管理部署主要是因为后期部署更困难(通常成本会更高),而且还很可能影响系统的持续运行。风险管理也需要融入到系统生命周期的后期,以协助确保系统能适应环境、技术、规程和人员的变化。
进行全生命周期的风险管理除了帮助确保管理活动在所有阶段都充分考虑到各种风险问题以外,还可以帮助记录应对风险的相关决策。这种记录文档对于系统管理人员以及督察和独立审计人员是有用的。系统管理人员将文档用于自我检查和决策理由的提示,这样就可以更容易地对系统和环境更改的影响进行评估。督察和独立审计人员在检查中可以使用文档来验证系统管理工作的充分性,并用来突出风险可能被忽视的领域。
3 应用系统生命周期概述
和其他产品、系统一样, IT应用系统生命周期可以分为以下5个阶段:
起始 :在起始阶段,表述系统的需要并记录应用系统的目的。
开发/采购: 在这个阶段对应用系统进行设计、购买、编程、开发、测试或其它形式的构建。这个阶段经常包含所定义的其它周期,如应用系统开发或采购、测试等。
实施: 在经过初期的系统测试后,系统被安装到位。
运行和维护: 在这个阶段应用系统执行其工作。几乎总是要对应用系统进行修改,增加硬件、软件或发生其它变更等。
退出与废弃: 向新应用系统转移的工作完成后,原有的应用系统被废弃。每个应用系统又可以分为若干子系统,也有自己的生命周期。
4 在IT应用系统的全生命周期中管理风险
随着系统所处生存阶段的变化,应用风险的种类也会改变,对其管理也有不同的要求。
4.1 起始阶段
在确定新的应用系统概念和早期设计过程中,风险管理的目标是保证业务和信息技术应用系统的一致性,避免在项目启动初期出现不合理的行为导致返工。
制定计划——区分系统各部分交付的优先次序,了解其内部的相互依赖关系,明确交付系统的能力、容量和可能的制约因素,按照优先级次序启动不同流程;[NextPage]
确认系统方案的可行性——对系统方案交付选项进行有效的评估,保证业务和IT在理念上的一致性,确认真正的需求范围和交付内容,保证预算在各个子目标之间的合理分配,利用原型法把模拟的应用转换为实际的应用;
系统影响分析——考虑新的应用系统对组织现有系统、流程和利益相关者的影响;
考虑所有可能的方案——权衡是购买还是进行自己开发系统,考虑每种选择所包含的风险并进行分析;
4.2 开发/采购
对于大多数应用系统来说,开发/采购阶段比起始阶段更复杂,可以分为以下三个子阶段。
4.2.1 需求和方案设计
在开发/采购阶段的初期,系统计划者定义系统的需求,风险管理的需求也应该与此同时制定,风险管理的目标是保证在系统解决方案开始构建之前,明确方案的优缺点,避免返工。方案架构设计过程应该坚持对方案进行严格的质量评估,同时要积极管理合作伙伴合同和技术采购上可能出现的风险。
确定需求的优先级——在整个系统方案范围内,评估并确认需求的优先顺序和组织的能力,哪些是必须做的,哪些是可以完成的,哪些是可能完成的,哪些是可能完不成的;
定义接口——如果多个团队必须同步开展系统开发,应该为最终集成在一起的多个子系统定义清晰的接口;
选择技术组件——挑选需要采购、改造、修改的技术组件,确认其来源的可靠性、质量和持续支持的能力;
4.2.2 系统构建(开发/采购)
如果系统要自行开发,编码工作此时已经开始启动,对采购软件,则需要同步开始进行裁剪和配置工作,这个阶段需要避免的风险主要和系统各个组成部分自身携带的缺陷有关,这些组件集成到整个系统中,也可能引入新的缺陷。
应用系统分割和合并——系统设计一般都是分开进行,这样便于多个团队并行工作,提高效率,最终要把这些工作集成到一起。尤其是需要多次发布的软件,分割和合并的工作更为复杂。
4.2.3 系统测试
系统测试阶段主要的风险管理目标是通过测试识别不可接受的缺陷,并确认每个缺陷都得到了解决。
确认系统的正确性和完整性——依照系统规范和业务需求,按部就班地对系统实施“肯定性”和“否定性”测试,必须保证系统能够正常运作;
增强信心——对重要的业务流程,必须从端到端的角度来验证系统具备正确的功能;
获得用户认可——提供证据来证明来自交付伙伴的方案组件和整体系统在业务上都是可以接受的;
4.3 实施
在实施阶段,应用系统主要的风险管理目标是保持业务的持续运行,避免业务中断。
预演——在系统投产前,组织用户代表进行技术演练,使用户对系统在时间、次序和可能造成的影响等方面都有一个清晰的了解;
投产——动员实施队伍,按照计划进行应用实施,并验证系统实施是否取得成功;
回退——制定一套可以让业务退回原有状态的B计划,并在实施前进行演练;
4.4 运行和维护
由于系统的复杂性和资源限制,测试阶段很难对IT应用系统进行穷尽测试,系统在运行中总会出现新的缺陷,同时业务的发展变化也会对系统提出变更和改进要求,此时风险管理的目标是把系统从故障状态中恢复正常运行,避免系统改进造成新的故障:
变更管理——对必要的系统变更进行系统管理;
定期安全检查——认识系统安全的重要性,完善安全策略,定期进行检查审核;
灾难恢复计划更新——系统发生变更后及时更新灾难恢复计划,并定期进行演练;
4.5 退出与废弃
应用系统生命周期的退出和废弃阶段涉及到信息、硬件和软件的处置。在理想情况下,旧应用系统退出计划应该作为新应用系统实施和切换的一部分。
信息——可以转移到其它系统、存档、丢弃或销毁。对信息存档时应该考虑未来能够取回信息的方法;
硬件和软件——硬件和软件可以被销毁,出售,赠送或丢弃。对包含保密信息的存储介质必须进行销毁,对软件的处置应遵循许可证和其它与开发商的协议。
费用——用来清除一个过时的应用系统的资金一般很难得到保证,因为系统的退出不能为组织带来明显的经济利益,要采取有效措施防止因处置费用不足而引起的各种风险。
即使采用了全生命周期的管理,也不能保证完全去除应用系统中所有的风险,但引入全生命周期的风险管理方法为我们提供了很有益的一套流程,结合理解实际应用系统发展中的每一个步骤,可以帮助我们把注意力集中在如何应对系统中的问题上,并采取相应的补救措施。
信息化之路上充满风险,这些风险包括哪些方面?有什么方法可以有效地管理这些风险,使企业能预先将风险尽可能降低?
1 IT应用系统中的风险
所谓风险,是事件发生的不确定性及其后果的综合。这可能是一个希望出现的事情,一个具有潜在的积极影响的机会,或是一个不希望出现的事情或具有潜在消极结果的威胁。一般来说,更需要引起注意的是后者。应用系统的风险主要是指由于各种因素导致应用系统没有达到预期效果的各种情形。
IT应用系统中的风险有各种不同的分类方法,可以分为不同类型,例如技术风险和管理风险等,目前应用系统中主要面临和经常可能发生的风险主要有:
缺乏规划或规划不合理;
项目预准备不充分,如硬件及软件选型错误、合作伙伴能力不足等;
设计流程缺乏有效的控制环节;
系统内各个子系统之间不能很好衔接;
实施计划不完善,过程控制不严格,阶段成果未达标;
新系统和组织内其它系统有冲突;
实施效果未做评估或评估不合理;
系统安全设计不完善;
灾难防范措施不当或不完整,容易造成系统崩溃;
系统退役后的处理不当引起的泄密等。
2 将风险管理集成到应用系统生命周期中的好处
虽然可以在任何时刻制定风险管理计划,但人们往往着重于对系统运行中风险的管理和维护,往往忽视系统启动前,开发和退出后的潜在风险,在系统生命周期的开始阶段制定计划是一个值得推荐的做法。风险管理与系统的其它方面一样,在整个系统生命周期各阶段都进行计划是最好的管理方式。计算机界长期以来认同的原则就是,系统设计完成后在其中增加特性比在系统初始的设计阶段包含该特性要多花费十倍的时间和费用。在系统规划初期尽早进行风险管理部署主要是因为后期部署更困难(通常成本会更高),而且还很可能影响系统的持续运行。风险管理也需要融入到系统生命周期的后期,以协助确保系统能适应环境、技术、规程和人员的变化。
进行全生命周期的风险管理除了帮助确保管理活动在所有阶段都充分考虑到各种风险问题以外,还可以帮助记录应对风险的相关决策。这种记录文档对于系统管理人员以及督察和独立审计人员是有用的。系统管理人员将文档用于自我检查和决策理由的提示,这样就可以更容易地对系统和环境更改的影响进行评估。督察和独立审计人员在检查中可以使用文档来验证系统管理工作的充分性,并用来突出风险可能被忽视的领域。
3 应用系统生命周期概述
和其他产品、系统一样, IT应用系统生命周期可以分为以下5个阶段:
起始 :在起始阶段,表述系统的需要并记录应用系统的目的。
开发/采购: 在这个阶段对应用系统进行设计、购买、编程、开发、测试或其它形式的构建。这个阶段经常包含所定义的其它周期,如应用系统开发或采购、测试等。
实施: 在经过初期的系统测试后,系统被安装到位。
运行和维护: 在这个阶段应用系统执行其工作。几乎总是要对应用系统进行修改,增加硬件、软件或发生其它变更等。
退出与废弃: 向新应用系统转移的工作完成后,原有的应用系统被废弃。每个应用系统又可以分为若干子系统,也有自己的生命周期。
4 在IT应用系统的全生命周期中管理风险
随着系统所处生存阶段的变化,应用风险的种类也会改变,对其管理也有不同的要求。
4.1 起始阶段
在确定新的应用系统概念和早期设计过程中,风险管理的目标是保证业务和信息技术应用系统的一致性,避免在项目启动初期出现不合理的行为导致返工。
制定计划——区分系统各部分交付的优先次序,了解其内部的相互依赖关系,明确交付系统的能力、容量和可能的制约因素,按照优先级次序启动不同流程;[NextPage]
确认系统方案的可行性——对系统方案交付选项进行有效的评估,保证业务和IT在理念上的一致性,确认真正的需求范围和交付内容,保证预算在各个子目标之间的合理分配,利用原型法把模拟的应用转换为实际的应用;
系统影响分析——考虑新的应用系统对组织现有系统、流程和利益相关者的影响;
考虑所有可能的方案——权衡是购买还是进行自己开发系统,考虑每种选择所包含的风险并进行分析;
4.2 开发/采购
对于大多数应用系统来说,开发/采购阶段比起始阶段更复杂,可以分为以下三个子阶段。
4.2.1 需求和方案设计
在开发/采购阶段的初期,系统计划者定义系统的需求,风险管理的需求也应该与此同时制定,风险管理的目标是保证在系统解决方案开始构建之前,明确方案的优缺点,避免返工。方案架构设计过程应该坚持对方案进行严格的质量评估,同时要积极管理合作伙伴合同和技术采购上可能出现的风险。
确定需求的优先级——在整个系统方案范围内,评估并确认需求的优先顺序和组织的能力,哪些是必须做的,哪些是可以完成的,哪些是可能完成的,哪些是可能完不成的;
定义接口——如果多个团队必须同步开展系统开发,应该为最终集成在一起的多个子系统定义清晰的接口;
选择技术组件——挑选需要采购、改造、修改的技术组件,确认其来源的可靠性、质量和持续支持的能力;
4.2.2 系统构建(开发/采购)
如果系统要自行开发,编码工作此时已经开始启动,对采购软件,则需要同步开始进行裁剪和配置工作,这个阶段需要避免的风险主要和系统各个组成部分自身携带的缺陷有关,这些组件集成到整个系统中,也可能引入新的缺陷。
应用系统分割和合并——系统设计一般都是分开进行,这样便于多个团队并行工作,提高效率,最终要把这些工作集成到一起。尤其是需要多次发布的软件,分割和合并的工作更为复杂。
4.2.3 系统测试
系统测试阶段主要的风险管理目标是通过测试识别不可接受的缺陷,并确认每个缺陷都得到了解决。
确认系统的正确性和完整性——依照系统规范和业务需求,按部就班地对系统实施“肯定性”和“否定性”测试,必须保证系统能够正常运作;
增强信心——对重要的业务流程,必须从端到端的角度来验证系统具备正确的功能;
获得用户认可——提供证据来证明来自交付伙伴的方案组件和整体系统在业务上都是可以接受的;
4.3 实施
在实施阶段,应用系统主要的风险管理目标是保持业务的持续运行,避免业务中断。
预演——在系统投产前,组织用户代表进行技术演练,使用户对系统在时间、次序和可能造成的影响等方面都有一个清晰的了解;
投产——动员实施队伍,按照计划进行应用实施,并验证系统实施是否取得成功;
回退——制定一套可以让业务退回原有状态的B计划,并在实施前进行演练;
4.4 运行和维护
由于系统的复杂性和资源限制,测试阶段很难对IT应用系统进行穷尽测试,系统在运行中总会出现新的缺陷,同时业务的发展变化也会对系统提出变更和改进要求,此时风险管理的目标是把系统从故障状态中恢复正常运行,避免系统改进造成新的故障:
变更管理——对必要的系统变更进行系统管理;
定期安全检查——认识系统安全的重要性,完善安全策略,定期进行检查审核;
灾难恢复计划更新——系统发生变更后及时更新灾难恢复计划,并定期进行演练;
4.5 退出与废弃
应用系统生命周期的退出和废弃阶段涉及到信息、硬件和软件的处置。在理想情况下,旧应用系统退出计划应该作为新应用系统实施和切换的一部分。
信息——可以转移到其它系统、存档、丢弃或销毁。对信息存档时应该考虑未来能够取回信息的方法;
硬件和软件——硬件和软件可以被销毁,出售,赠送或丢弃。对包含保密信息的存储介质必须进行销毁,对软件的处置应遵循许可证和其它与开发商的协议。
费用——用来清除一个过时的应用系统的资金一般很难得到保证,因为系统的退出不能为组织带来明显的经济利益,要采取有效措施防止因处置费用不足而引起的各种风险。
即使采用了全生命周期的管理,也不能保证完全去除应用系统中所有的风险,但引入全生命周期的风险管理方法为我们提供了很有益的一套流程,结合理解实际应用系统发展中的每一个步骤,可以帮助我们把注意力集中在如何应对系统中的问题上,并采取相应的补救措施。
本文标签:IT应用系统全生命周期的风险管理
* 由于无法获得联系方式等原因,本网使用的文字及图片的作品报酬未能及时支付,在此深表歉意,请《IT应用系统全生命周期的风险管理》相关权利人与机电之家网取得联系。