4 在IT应用系统的全生命周期中管理风险
随着系统所处生存阶段的变化，应用风险的种类也会改变，对其管理也有不同的要求。
4.1 起始阶段
在确定新的应用系统概念和早期设计过程中，风险管理的目标是保证业务和信息技术应用系统的一致性，避免在项目启动初期出现不合理的行为导致返工。
- 制定计划——区分系统各部分交付的优先次序，了解其内部的相互依赖关系，明确交付系统的能力、容量和可能的制约因素，按照优先级次序启动不同流程；
- 确认系统方案的可行性——对系统方案交付选项进行有效的评估，保证业务和IT在理念上的一致性，确认真正的需求范围和交付内容，保证预算在各个子目标之间的合理分配，利用原型法把模拟的应用转换为实际的应用；
- 系统影响分析——考虑新的应用系统对组织现有系统、流程和利益相关者的影响；
- 考虑所有可能的方案——权衡是购买还是进行自己开发系统，考虑每种选择所包含的风险并进行分析；
4.2 开发/采购
对于大多数应用系统来说，开发/采购阶段比起始阶段更复杂，可以分为以下三个子阶段。
4.2.1 需求和方案设计
在开发/采购阶段的初期，系统计划者定义系统的需求，风险管理的需求也应该与此同时制定，风险管理的目标是保证在系统解决方案开始构建之前，明确方案的优缺点，避免返工。方案架构设计过程应该坚持对方案进行严格的质量评估，同时要积极管理合作伙伴合同和技术采购上可能出现的风险
- 确定需求的优先级——在整个系统方案范围内，评估并确认需求的优先顺序和组织的能力，哪些是必须做的，哪些是可以完成的，哪些是可能完成的，哪些是可能完不成的；
- 定义接口——如果多个团队必须同步开展系统开发，应该为最终集成在一起的多个子系统定义清晰的接口；
- 选择技术组件——挑选需要采购、改造、修改的技术组件，确认其来源的可靠性、质量和持续支持的能力；
4.2.2 系统构建（开发/采购）
如果系统要自行开发，编码工作此时已经开始启动，对采购软件，则需要同步开始进行裁剪和配置工作，这个阶段需要避免的风险主要和系统各个组成部分自身携带的缺陷有关，这些组件集成到整个系统中，也可能引入新的缺陷。
- 应用系统分割和合并——系统设计一般都是分开进行，这样便于多个团队并行工作，提高效率，最终要把这些工作集成到一起。尤其是需要多次发布的软件，分割和合并的工作更为复杂。
4.2.3 系统测试
系统测试阶段主要的风险管理目标是通过测试识别不可接受的缺陷，并确认每个缺陷都得到了解决。
- 确认系统的正确性和完整性——依照系统规范和业务需求，按部就班地对系统实施“肯定性”和“否定性”测试，必须保证系统能够正常运作；
- 增强信心——对重要的业务流程，必须从端到端的角度来验证系统具备正确的功能；
- 获得用户认可——提供证据来证明来自交付伙伴的方案组件和整体系统在业务上都是可以接受的；
4.3 实施
在实施阶段，应用系统主要的风险管理目标是保持业务的持续运行，避免业务中断。
- 预演——在系统投产前，组织用户代表进行技术演练，使用户对系统在时间、次序和可能造成的影响等方面都有一个清晰的了解；
- 投产——动员实施队伍，按照计划进行应用实施，并验证系统实施是否取得成功；
- 回退——制定一套可以让业务退回原有状态的B计划，并在实施前进行演练；
4.4 运行和维护
由于系统的复杂性和资源限制，测试阶段很难对IT应用系统进行穷尽测试，系统在运行中总会出现新的缺陷，同时业务的发展变化也会对系统提出变更和改进要求，此时风险管理的目标是把系统从故障状态中恢复正常运行，避免系统改进造成新的故障：
- 变更管理——对必要的系统变更进行系统管理；
- 定期安全检查——认识系统安全的重要性，完善安全策略，定期进行检查审核；
- 灾难恢复计划更新——系统发生变更后及时更新灾难恢复计划，并定期进行演练；
4.5 退出与废弃
应用系统生命周期的退出和废弃阶段涉及到信息、硬件和软件的处置。在理想情况下，旧应用系统退出计划应该作为新应用系统实施和切换的一部分。
- 信息——可以转移到其它系统、存档、丢弃或销毁。对信息存档时应该考虑未来能够取回信息的方法；
- 硬件和软件——硬件和软件可以被销毁，出售，赠送或丢弃。对包含保密信息的存储介质必须进行销毁，对软件的处置应遵循许可证和其它与开发商的协议。
- 费用——用来清除一个过时的应用系统的资金一般很难得到保证，因为系统的退出不能为组织带来明显的经济利益，要采取有效措施防止因处置费用不足而引起的各种风险。
即使采用了全生命周期的管理，也不能保证完全去除应用系统中所有的风险，但引入全生命周期的风险管理方法为我们提供了很有益的一套流程，结合理解实际应用系统发展中的每一个步骤，可以帮助我们把注意力集中在如何应对系统中的问题上，并采取相应的补救措施。
