一、 启动阶段的准备工作
在项目的初始阶段，首先需要对项目目标作出仔细的分析，明确项目的可行性，制定出项目的总体策略，得到各有关方面的认可，通过项目的立项。
1、应用集中的本质
现在银行的大集中有两种概念，一是物理集中，二是逻辑集中，所谓逻辑集中，就是我们所说的应用集中，真正利用一套集中处理的应用系统，替代各分行原有的应用系统，来支持各分行的业务。这样，各分行在做同一项业务时，将由同一套应用系统来处理。因此，应用系统的集中，实际上就是一定程度上的业务处理的集中，在一定程度上改变了业务处理的工作流程，对业务操作和管理必定产生影响。从信息工程的角度来说，应用系统的集中，改变的是银行内部的信息结构，而信息结构的变化，必定会导致业务结构和技术结构的改变。相比之下，我们前面提到的物理集中，其实只是改变了技术结构，对企业的信息结构和业务结构的影响是比较小的。
因此，要施行银行应用系统的大集中，必须首先认识到，它不是一项单纯的技术工作，必定会涉及到全行上下许多方面的问题。因此，只有站在全行战略的高度，才能对应用大集中项目有一个比较全面的把握。
2、应用大集中项目的范围界定
在确立大集中项目之前，当然需要明确项目的范围，项目范围的确定，直接反映出项目中的总体策略，对整个大集中工作有着至关重要的影响。
（1） 明确大集中之后的信息结构
应用系统如何集中，在业内有许多争论的话题，比如是否需要全国集中，哪些应用应该集中。正是由于各银行对这些问题的看法不同，才导致了不同的集中策略。比如有的银行就认为不需要搞全国集中，到各省集中就可以了，有的银行则认为所有的业务都应该集中到全国大中心来处理，而有的银行则只将部分业务处理进行集中，另外一部分业务保持分散。不同的集中策略，反映出各行对未来业务发展模式的不同认识。
根据国内商业银行目前业务的总体情况，我认为对于集中的程度应该一分为二地看待，有的业务就应该尽可能集中处理，有的业务就应该分散处理，这和不同业务的市场特点是密切相关的，不能一概而论。因此，作为银行的决策者，就应该认真分析不同的业务处理的要求，明确哪些业务适宜分散处理，哪些业务适宜集中处理，确定出将来应用系统的总体体系结构。如果不加区分地把所有业务都集中起来，无异于作茧自缚，将来必定会成为业务发展的障碍。
（2） 明确大中心应用处理系统的策略
在明确了哪些应用系统适宜集中之后，就需要对这些系统进行评估，明确建立这些应用系统的策略。
最经济的方法，就是采用银行现有的应用系统，进行一定的修改，作为未来大中心的集中处理系统，另外有的银行则是针对大中心自行开发一套新的应用系统，还有的银行则打算采购一套现成的集中式应用处理系统。面对不同的策略，不论将来的决策结果如何，有几项基础性的工作必须要做，就是对现有的应用系统进行全面的评估，找出它们在数据逻辑、处理逻辑方面，与将来大集中处理的要求之间存在的差异。差异分析的工作极其重要，不仅能够明确现有应用系统是否能够支持大集中的需要，能够帮助制定新的应用系统的需求，更重要的是，可以对将来集中之后的信息结构，从总体上有一个初步的分析和认识，有助于明确未来系统发展的方向，为以后进一步研究业务结构和技术结构的变化，打下坚实的基础。
（3） 明确业务方面的变化
随着应用系统的大集中，业务方面也会随之发生一定的变化，主要在业务管理模式和业务处理流程两方面。
我们首先要看业务管理模式方面的影响。随着应用系统的集中，一些相应的业务管理职能，也就具备条件由原来分散管理的方式，转向集中管理的方式，比如市场分析、风险监控、客户服务等，就可以调整原来各分行在这些方面的职能，将其中的一些职能集中到更高级别的管理机构，可以大大提高业务管理的效果，降低银行成本。
应用系统集中本身所产生的变化，和由此导致的业务管理模式的变化，都会对业务处理流程产生影响。例如在银行一些需要加强风险控制的业务，随着应用系统的集中，就可以将业务处理中的风险控制的环节集中起来，提高风险控制的专业化水平，加强风险控制管理的力度，降低风险管理的成本。这样，业务处理的流程就要随之进行改变，同时也会产生出新的机构和岗位，同时一些原有的机构和岗位也可能会被撤销。所以应用系统大集中，在一定程度上，也是业务管理和业务处理的集中过程。
（4）内部IT服务体系的变化
在内部IT服务方面也同样会产生变化。在应用系统集中以后，对于系统运行管理、技术支持、应用系统的维护，都不再像以前那样在分行内部就可以得到解决，而是需要跨越多个组织边界才能解决，这就要求建立一套相应的管理机制，满足跨地域、跨机构的IT服务管理的需要。
3、落实项目的组织形式
由于应用系统大集中所涉及的方面非常多，所以必须有一个行之有效的项目管理的组织形式，明确各方面的职责分工的原则，在决策层和项目组之间，在技术部门和业务部门之间，在总行和分行之间，在银行和外部提供商之间，都要能够进行有效的沟通和协调，这往往是项目成败的关键。所以一般都会成立高层的领导小组，由总行行长任组长，在分行内部也要成立由行长挂帅的领导小组，按照总行领导小组的要求，协调分行内部的工作。在具体执行方面，总行和分行都要成立项目工作组，其中应包括技术部门和各有关的业务部门，以及后勤保障部门。这样做的目标是，在矩阵式的组织结构中，在横向的项目管理和纵向的职能管理的各个管理体系中，都要建立起沟通和协调的通路，不留空白，这样才能保证各项工作决定得到有效的贯彻执行。
4，制定整体项目计划，落实项目预算
这里所说的计划和预算，都是指整体性的，更多的是基于以往的经验的估计。为此，需要根据前面初步分析得出的结论，从整体上明确项目的工作内容，所需要投入的资源，项目周期等因素，初步制定出整体的项目计划，提出项目预算规模。

在明确目标方面，除了上述几个关键问题外，还要根据项目启动阶段所要形成的项目任务书（Project Charter）要求的内容，以适当的形式逐一落实各项内容，使项目有一个好的开端。

二、 计划阶段
1、 深入剖析工作细节
“预则立，不予则废”，好的项目计划是项目成功实施的关键，而项目范围分析，则是制定项目计划中的首要内容。
从前面的分析可以看出，应用系统大集中所涉及的内容非常庞杂，而其中的任何一个疏漏，都可能会对全局产生影响。因此，必须对项目范围进行全面、细致的分析，逐步进行分解，直到每一子任务都能够明确定义、完全具备可操作性、并能够落实到具体执行人。在工作任务分解方面，PMI的WBS Practice Standard，为我们提供了很好的指引。
一般来说，在应用系统大集中过程中，以下方面的问题都需要考虑到。
在技术方面：
（1） 中心应用系统：根据所选择的应用系统策略，开发或采购所需的应用系统，并将其中需要安装在大中心的集中处理部分，部署到大中心的系统环境中；
（2） 应用系统的前端部分：对于应用系统的前端，为了保护投资，往往都会利用原有的系统平台，但应用部分可能会有变化，因此，需要将变化的应用部署到各分支机构的前端系统中去；
（3） 外围应用系统接口：通常情况下，在各分行都应该存在一些外围的应用系统，这些系统往往和本地特殊业务需要有关，而且从应用系统架构来说，各分行也应该存在一些本地化的业务处理的外围系统，例如现在常见的中间业务系统，就需要和当地的企业、商家合作开展业务。因此，为了保证业务的延续性，就必须要充分考虑应用系统大集中时，同步调整与这些外部相关系统之间的接口。这一点非常重要，因为在实际实施过程中，银行往往是逐步集中不同的系统，并非把所有系统一次全部集中到位，这样每集中一个系统，就会面临与其它相关系统调整接口的问题。
（4） 大中心主机系统：业务处理主机、存储设备、输出设备、系统监控等的硬件和系统环境配置等；
（5） 网络系统：要保证集中后各原有机构到大中心的网络访问的环境，包括带宽、路由、网络安全控制等；
（6） 大中心的技术保障措施，包括各类管理系统和各项管理措施；
（7） 大中心基础设施：包括大中心选址、机房装修、动力系统、门禁监控系统、综合布线等；
在业务方面：
（1） 务管理模式如果发生变化，则要制定出相应的管理制度，建立必要的组织机构，制定相应的岗位职责；
（2） 业务处理流程调整：要结合集中式处理的应用系统的要求，制定出具体的业务操作规程，如果是新开发或新采购的系统，则更需要详细梳理业务的各项操作过程，制定出新的业务操作规范；
（3） 内部培训：对于所发生的各种变化，都需要对所有有关的业务人员进行培训，要培训到每一个相关的业务人员，同时要做好内部的支持准备，能够及时解决各级业务人员提出的操作问题；
（4） 如果由于更新系统对原有业务产生较大变化，以至影响到了外部客户，那么就还要提前做好宣传、解释等准备工作，同时客户服务部门要准备好迎接受理咨询和投诉的高峰；

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

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

3、 做好风险管理计划
实施这样一个大型的项目，做好风险管理计划当然是十分必要的，特别是到了项目的后期，做系统测试和向生产系统切换时，为了尽可能减少对正常营业的影响，都需要做好严密的风险管理计划。风险识别、风险评估、风险应对措施等内容，都是必不可少的。
例如在向生产系统切换时，是整个项目压力最大的时刻，切换是否成功，直接体现着整个项目前期工作的成果，而且一旦出现大的意外，对于银行来说，其后果将可能是灾难性的。为了确保向生产系统的切换万无一失，不仅在前期要做多次的模拟测试，对于最后的切换过程，也需要制定周密的风险管理计划，一般至少要包括以下这些方面：
（1） 系统环境切换：保证原来所有到旧系统的访问，都能被切换到新系统上，这不仅包括应用系统的前端，还包括各类周边的相关应用系统，必须要同时指向新的应用系统。如果这方面出现问题，则只好退回到原有系统上。通常这方面的问题在多次的测试过程中能够得到有效的解决，但在向生产系统正是切换时，也不可掉以轻心。
（2） 数据迁移：将业务数据从旧系统迁移到新的系统中，不仅要保证在数据转换过程中保持数据逻辑的一致性（如果新、旧系统的数据逻辑不同），而且在实际切换过程中，还要保证新旧系统之间数据的同步，保证在切换时刻之前新旧系统的数据是一致的，在切换时刻之后，新产生的业务数据都能反映到新的系统中，而不会有任何的遗漏。为了准备在出现意外时能够将新的业务数据转回到旧系统中，需要充分做好数据备份，做好数据从新系统向旧系统转换的准备，而且也要充分考虑到数据同步的问题。其实将新系统切换回旧系统，其面临的风险和需要解决的问题，基本上是相同的。在新旧系统之间的数据转换工作，可以在前期的测试中得到有效的解决，但新旧系统之间的数据同步，只有在实际切换时才能解决，所以一般都会受到项目管理者的高度重视，成为大家关注的焦点。
（3） 业务操作的切换：由于新旧系统在业务操作方面可能会存在较大的变化，无论对业务人员做多少前期的培训，也难以完全改变旧的操作习惯，所以在切换到新的系统之后，还可能出现人为的业务操作方面的问题，导致业务处理方面出现差错。所以在系统切换后的相当时期内，仍然需要对业务处理进行跟踪检查，及时发现由于业务操作可能导致的问题。
（4） 在风险管理中，除了计划内考虑到的可能的风险，还可能出现许多意料不到的风险，所以在风险管理计划中，不仅要有对已经识别的风险的应对措施，还要有防范其它意外的应对措施，这主要就是一种管理上的措施，一旦出现事先没有考虑到的情况，仍要能够有条不紊的应对，各种资源保持就位，随时注意发现异常情况，对于出现的问题及时报告，明确对各类问题作出判断和决策的责任归属。也就是说，要具备一套能够应对各种风险的报告、决策机制。

4、 做好沟通计划
正如前面所提到的，在应用大集中这样的项目中，涉及到银行内部许多方面的人员，总行、分行的科技部门，总行、分行的各个业务部门，在科技部门内又涉及规划管理、应用开发、网络管理、系统运行等不同的处室，在系统运行中，又会有更细的分工，还有银行外部的设备供应商、服务提供商，所有这些都应该被视为项目的成员考虑在内。所以在整个项目中，全面的沟通是至关重要的。银行在传统的业务模式下，其组织结构一般都是职能型的，或是弱矩阵型的，组织中的层级是比较多的。而在应用大集中项目中，由于会受到高层领导的高度重视，往往在项目中会表现出强矩阵的组织结构，更需要扁平的组织结构。这种组织结构的差别，使原有的思维模式、工作习惯、隶属关系、报告路线会受到冲击，会对整个项目的沟通产生直接的影响。
因此就需要提前做好沟通计划，明确各自分工，明确各类问题的沟通路线，在各种问题上尽可能得到大家的共识。在项目的执行过程中，需要定期报告，将报告汇总起来，对于项目中出现的问题，及时作出调整。为此，在沟通计划中要制定一些相对固定的报告文档模版，各种报告有时间周期或里程碑的要求，各类报告都有指定的报告对象，在电子邮件系统中应配合开设用户组，并对报告和反馈的情况进行跟踪和督促。项目组中关键成员的通讯录，当然也是必不可少的。

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

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