在业务方面：

（1） 务管理模式如果发生变化，则要制定出相应的管理制度，建立必要的组织机构，制定相应的岗位职责；

（2） 业务处理流程调整：要结合集中式处理的应用系统的要求，制定出具体的业务操作规程，如果是新开发或新采购的系统，则更需要详细梳理业务的各项操作过程，制定出新的业务操作规范；

（3） 内部培训：对于所发生的各种变化，都需要对所有有关的业务人员进行培训，要培训到每一个相关的业务人员，同时要做好内部的支持准备，能够及时解决各级业务人员提出的操作问题；

（4） 如果由于更新系统对原有业务产生较大变化，以至影响到了外部客户，那么就还要提前做好宣传、解释等准备工作，同时客户服务部门要准备好迎接受理咨询和投诉的高峰；

以上只是应用系统大集中所涉及的非常表层的内容，实际中需要对任务进行深入地分解，要确实落实分解后的每一子任务的可行性。在分解清楚工作任务的基础上，就可以结合实际情况，列出所有行动清单（Activity List）。在这里，要特别注意避免犯的错误，就是把范围和行动混淆起来。范围分析始终是反映目的的，而行动的细化是反映手段的，在以后项目具体执行过程中，行动是可以根据情况随时调整的，而范围的调整则要受到严格的控制。

2、 制定周密的时间表

经过任务分解之后，再列出行动清单，随后的一项重要工作就是明确各项行动之间的依赖关系，估计各项行动所需的时间，从而形成项目进度时间表。这一环节对于项目实施中的工作效率影响很大。

全面、正确地识别出各项行动之间的依赖关系，合理估计各项行动所需要的时间，需要丰富的管理经验和深厚的专业功底。由于银行必须要保证对外部客户的持续服务，有些服务还要求每天24小时不能间断，所以银行在进行测试、切换等工作时，能够利用的时间窗口是极其有限的，一般都是安排在夜间进行。虽然在必要的时候也可以采取停业测试的方法，宣布对外停业1天，利用这一天的时间对系统进行全面的测试，但这种机会并不多，所以必须周密地制定出详细的计划，有时甚至需要将行动细化到1小时以内。当然，并非项目中所有的时间安排都要细化到这个程度，但在许多关键任务上，对于项目的计划能力还是要求很高的，即使在其它一些周期较长的任务上，也同样希望综合运用各种项目管理方法，合理地安排工作顺序，尽可能地提高资源的利用率，缩短项目周期。对于银行应用大集中这样涉及方面众多的项目，如何保证各个方面的工作能够协调同步地进行，确实需要项目的管理者们，以极高的责任感，充分调动各方的积极性，发挥出集体的聪明才智。同时，项目管理的许多具体方法，在这个过程当中，也都大有用武之地，由专业的项目管理者来协助制定项目时间表，是会有很大帮助的。

3、 做好风险管理计划

实施这样一个大型的项目，做好风险管理计划当然是十分必要的，特别是到了项目的后期，做系统测试和向生产系统切换时，为了尽可能减少对正常营业的影响，都需要做好严密的风险管理计划。风险识别、风险评估、风险应对措施等内容，都是必不可少的。

例如在向生产系统切换时，是整个项目压力最大的时刻，切换是否成功，直接体现着整个项目前期工作的成果，而且一旦出现大的意外，对于银行来说，其后果将可能是灾难性的。为了确保向生产系统的切换万无一失，不仅在前期要做多次的模拟测试，对于最后的切换过程，也需要制定周密的风险管理计划，一般至少要包括以下这些方面：

（1） 系统环境切换：保证原来所有到旧系统的访问，都能被切换到新系统上，这不仅包括应用系统的前端，还包括各类周边的相关应用系统，必须要同时指向新的应用系统。如果这方面出现问题，则只好退回到原有系统上。通常这方面的问题在多次的测试过程中能够得到有效的解决，但在向生产系统正是切换时，也不可掉以轻心。

（2） 数据迁移：将业务数据从旧系统迁移到新的系统中，不仅要保证在数据转换过程中保持数据逻辑的一致性（如果新、旧系统的数据逻辑不同），而且在实际切换过程中，还要保证新旧系统之间数据的同步，保证在切换时刻之前新旧系统的数据是一致的，在切换时刻之后，新产生的业务数据都能反映到新的系统中，而不会有任何的遗漏。为了准备在出现意外时能够将新的业务数据转回到旧系统中，需要充分做好数据备份，做好数据从新系统向旧系统转换的准备，而且也要充分考虑到数据同步的问题。其实将新系统切换回旧系统，其面临的风险和需要解决的问题，基本上是相同的。在新旧系统之间的数据转换工作，可以在前期的测试中得到有效的解决，但新旧系统之间的数据同步，只有在实际切换时才能解决，所以一般都会受到项目管理者的高度重视，成为大家关注的焦点。

（3） 业务操作的切换：由于新旧系统在业务操作方面可能会存在较大的变化，无论对业务人员做多少前期的培训，也难以完全改变旧的操作习惯，所以在切换到新的系统之后，还可能出现人为的业务操作方面的问题，导致业务处理方面出现差错。所以在系统切换后的相当时期内，仍然需要对业务处理进行跟踪检查，及时发现由于业务操作可能导致的问题。

（4） 在风险管理中，除了计划内考虑到的可能的风险，还可能出现许多意料不到的风险，所以在风险管理计划中，不仅要有对已经识别的风险的应对措施，还要有防范其它意外的应对措施，这主要就是一种管理上的措施，一旦出现事先没有考虑到的情况，仍要能够有条不紊的应对，各种资源保持就位，随时注意发现异常情况，对于出现的问题及时报告，明确对各类问题作出判断和决策的责任归属。也就是说，要具备一套能够应对各种风险的报告、决策机制。

4、 做好沟通计划

正如前面所提到的，在应用大集中这样的项目中，涉及到银行内部许多方面的人员，总行、分行的科技部门，总行、分行的各个业务部门，在科技部门内又涉及规划管理、应用开发、网络管理、系统运行等不同的处室，在系统运行中，又会有更细的分工，还有银行外部的设备供应商、服务提供商，所有这些都应该被视为项目的成员考虑在内。所以在整个项目中，全面的沟通是至关重要的。银行在传统的业务模式下，其组织结构一般都是职能型的，或是弱矩阵型的，组织中的层级是比较多的。而在应用大集中项目中，由于会受到高层领导的高度重视，往往在项目中会表现出强矩阵的组织结构，更需要扁平的组织结构。这种组织结构的差别，使原有的思维模式、工作习惯、隶属关系、报告路线会受到冲击，会对整个项目的沟通产生直接的影响。

因此就需要提前做好沟通计划，明确各自分工，明确各类问题的沟通路线，在各种问题上尽可能得到大家的共识。在项目的执行过程中，需要定期报告，将报告汇总起来，对于项目中出现的问题，及时作出调整。为此，在沟通计划中要制定一些相对固定的报告文档模版，各种报告有时间周期或里程碑的要求，各类报告都有指定的报告对象，在电子邮件系统中应配合开设用户组，并对报告和反馈的情况进行跟踪和督促。项目组中关键成员的通讯录，当然也是必不可少的。

5、 引入项目管理工具

我曾经看到一些银行的项目计划，都是用WORD文档格式编写的，包括进度时间表、资源安排等。因此，在这里还需要特别强调一点，就是对于这样一个复杂的大型项目，必须要引入项目管理工具。虽然从结果上表达的内容都是相同的，但由于普通文档编辑软件不能像项目管理软件那样能够理解其中的内容所代表的在项目中的含义，所以在制定计划、调整计划、项目跟踪等方面，普通文档根本不能有效地支持项目管理地需要。比如在项目管理工具中，调整某项行动的时间，就会看到其它行动所受到的影响；又如，在项目管理软件中，我们在制定出时间表之后，可以自动找到关键路径，帮助项目管理者在计划的执行和控制过程中，始终能够抓住主要矛盾。当然，在项目中的一些辅助文档，还是可以使用普通的文档的。

以上，是在银行应用系统大集中项目的启动和计划阶段中，需要特别关注的几个项目管理方面的问题，在具体环境中，需要以项目管理的方法论作为基本出发点，结合实际的工作的目标和环境特点，因地制宜地制定出最切合实际、最行之有效的项目计划，把保证项目的成功作为最终的目标。

上一页123下一页