I项目实施与管理方案投标书.docx
《I项目实施与管理方案投标书.docx》由会员分享，可在线阅读，更多相关《I项目实施与管理方案投标书.docx（42页珍藏版）》请在冰豆网上搜索。
I项目实施与管理方案投标书
1.1工程实施与管理
1.1.1工程实施方法论
针对南京银行企业效劳总线系统工程，高伟达公司基于对客户需求、业务目标、业务能力和IT环境的理解，结合多年的软件开发和系统实施经验，将工程的实施周期划分为六个活动阶段，保证在工程生命周期内，应用合理的工程管理和控制技术。
通过专注于使客户投资回报最大化，和使客户的投资风险最小化的关键战略和战术领域，加快工程实施速度，使得工程成功地完成。
这些阶段的特性是可循环往复性，使客户可以尽快地获得新的应用系统所带来的好处。
1.1.1.1工程定义阶段
在这个阶段,所有与分期实施相关的工程活动都被明确定义,工程的"工程利益相关者"被指定，工程经理和客户工程经理的角色和职责被传达给所有的"工程利益相关者"。
管理工程所需的工程控制结构被定义,所有需要的工程规划文件被创立,客户的业务问题和被用来衡量工程成功的衡量标准被确认。
制定解决方案范围，在一个高级别上定义哪些模块将被实施，估算预期需要的客户化程度,以及勾画出在产品之外需要开发的内容和要提交的技术成果。
解决方案范围文档包括解决方案范围概述,功能范围,流程范围,客户化问题,其他风险,外部依赖条件以及假设。
这个工作为未来工程决策,统一或达成"工程利益相关者"之间就有关工程参数的共识，提供书面的文档。
它阐述以SOW为根底的业务需求，并且把它转化成产品模块实施信息。
简而言之,这个阶段组建工程团队，保证客户实施工程的成功。
公司人员与客户人员一道，组建工程团队,设定工程方法和范围，并建立工程管理控制。
主要交付的成果有，解决方案范围和工程管理控制。
制定了工程质量检查方案。
1.1.1.2需求分析阶段
在需求调研阶段,在工程管理小组的指导下,由公司和客户组成的统一的工程团队将识别并且书面记录在开始设计客户解决方案之前所必须弄清楚的，需处理的问题。
工程团队书写、提炼满足客户业务目标所需的功能和技术要求。
主要交付的技术成果为业务需求和差距分析。
专家效劳参谋将进行一个配置检查，以保证系统有精确的规格，便于购置硬件和架构部署。
在有技术客户经理参与的情况下,通过完成初始的评估,来建立部署的基准，及通过给战略，管制，用户采用,流程和技术各方面打分的评估来建立业务目标。
1.1.1.3工程设计阶段
在设计阶段,主要的目标是设计一个能够最正确地满足客户明确的业务需求的解决方案，并且为培训和系统测试做准备。
在设计〔Design〕阶段,工程团队利用应用系统屏幕流程和设计布局来映射在发现阶段确定的需求,设计解决方案的原型。
主要交付的技术成果是解决方案设计文档和测试策略。
这个策略定义测试方案和测试要求，以保证一个系统部署的成功。
主要的目的是提供一个高级的测试策略，以便使用自动化的测试工具和/或手工过程来实现功能测试,系统整合测试〔SIT〕,用户验收测试〔UAT〕和性能测试。
专家效劳参谋要执行设计检查，来评估由客户或集成商提供的书面设计文档，并且提供详细的建议清单。
设计标准包括,但不限于，应用系统性能,对升级的影响,应用系统维护,与数据模型相关的问题和常规的最正确做法。
1.1.1.4工程开发阶段
在开发阶段，工程团队将开发应用系统,提供任何需要的扩展功能和外部接口,为客户部门部署和持续支持解决方案做准备。
工程团队配置应用系统、所有需要的扩展功能和外部接口。
主要交付的技术成果有功能测试和系统测试。
这些流程整合和测试活动更好地保证介入的系统功能与客户组织的业务需求协调一致。
专家效劳参谋应该进行一个配置检查，来评估所有经过客户化改造的实施文档。
在这个检查过程中,所有这样的文件都将被评估，以使应用系统性能,应用系统升级,系统维护工作量和常规最正确实践最优。
1.1.1.5工程验证阶段
在验证阶段,将完成新系统全部功能的测试。
这个阶段分两个局部。
第一局部,工程团队进行一个对有生产数据的应用系统的全部功能进行测试。
在这个检测完成后,关键用户然后进行一个代表性的验收测试，以保证系统正确地处理用户的需求。
一旦全面的功能测试结束,将进行一个使用系统工具的，严格的性能测试。
这一阶段主要交付的技术成果为用户验收测试和性能测试结果,包括性能,容量和寿命测试。
适时的性能调整审计，可保证整个企业架构环境的性能最正确。
在这个检查中,专家效劳将主动性地识别任何性能问题,这样将减少在运行时出现问题的风险，增加系统生产切换的信心。
在有技术客户经理参与的情况下,可执行一个实施准备就绪检查，以确认系统是否可以部署了。
这个实施准备就绪检查是用来评估实施风险,技术上是否准备停当以及部署策略。
此时，应该召开管理人员定向协调研讨会，将责任转移给一线的员工，这些员工将开始支持业务流程和技术的推出。
在管理人员定向协调研讨会上,工程团队与客户的管理团队一起工作，以获得维持资助人的内部负责，并把正确的信号传达给组织的其他成员。
1.1.1.6部署上线阶段
部署上线阶段内的第一个活动是实施一个投产导航。
这个导航是被用来测试全面的生产部署,并且在客户业务环境中的一局部部门中进行的，例如一个地区或一个区域。
生产导航在机构的业务环境中局部部门里，为用户提供所有系统的特点。
来自于生产导航的反响信息指导整个的部署。
同样在这个过程中,专家效劳参谋应该进行生产准备就绪检查,通过主动地识别任何可能造成部署中断和使实施的系统解决方案的技术优点打折扣的所有问题，来协助系统的顺利推出。
此时,要召开流程实施研讨会，部署流程最优实践，来优化人,流程和技术的配合。
目的是在客户所有的一线机构中，使用变革和销售流程的最正确实践，使最初的赞助人和行政领导团队完全满意。
1.1.2工程管理方案
1.1.2.1工程管理概述
工程管理包括在工程生命周期中协调所有工程管理知识领域所涉及的过程。
它确保工程所有的组成要素在正确的时间结合在一起，以成功的完成工程。
进行工程整体管理时，必定涉及工程的范围、质量、时间和本钱管理以及人力资源、沟通、风险管理等各个环节，工程管理一个复杂的工程，在此主要针对南京银行企业效劳总线工程的工程进度管理、变更管理、沟通管理、质量管理、风险管理等相关策略进行描述。
1.1.2.2工程进度管理
通过工程进度的管理最终明确工程开发阶段的进度控制活动和关键流程。
Ø工程经理：
◆根据软件开发方案编制详细的阶段开发方案以及每项任务的边界时间，并召集过程控制人员、专题小组负责人审核该方案；
◆审核各专题小组拟订的每项任务的日程安排；
◆检查和控制工程进度；
◆制定进度变更方案；
Ø过程控制人员：
◆协助审核详细的阶段开发方案和任务边界时间；
◆监督工程进展；
Ø专题小组负责人：
◆协助审核详细的阶段开发方案和任务边界时间；
◆在听取小组成员意见的根底上，拟订每一项任务的日程安排；
◆负责检查和控制任务的进度，并填写进度控制表；
◆负责制订任务变更方案。
1.1.2.2.1.进度安排流程
Ø工程经理根据工程方案，明确该阶段的边界时间；
Ø根据工程方案中的任务PERT网络图，找出该阶段的关键任务并进一步分解、细化，在此根底上绘制更具体的阶段任务PERT网络图；
Ø拟订详细的阶段方案；
Ø确定每一关键任务的边界时间；
Ø召集各专题小组负责人审核拟订的方案，并修改；
Ø专题小组负责人确定任务的日程安排；对于大型的或时间要求严格的工程，进度安排应以天为单位；
Ø征求小组成员的意见；
Ø交由工程经理和过程管理人员审核。
1.1.2.2.2.进度控制流程
Ø工程经理和过程管理人员按照阶段PERT图，标志阶段中被跟踪的关键任务和里程碑，并将之告知专题小组负责人；
Ø专题小组负责人按照任务的日程安排，确定任务完成期间的关键时间点，并将之告知专题小组成员；
Ø专题小组负责人经常与成员沟通，了解任务进展；并定期检查，填写任务进度表和下期方案表，及时发现问题；
Ø工程经理定期组织专题小组负责人，召开工程状态会议，了解任务进展，及时发现问题；工程过程管理人员参加会议或了解会议的记录；
Ø专题小组负责人在执行中发现延迟，分析原因：
◆人员紧张：
组内调配不了的，找工程经理解决；
◆事先预估缺乏：
调整任务日程安排；假设解决不了，告知工程经理，会同过程管理人员，调整详细的阶段方案；如果阶段内消化不了的问题，那么工程经理按照?
配置管理的程序?
，变更软件开发方案。
1.1.2.3工程变更管理
针对工程变更管理组织变更控制小组，由工程组经理、工程管理部人员、工程总监、客户、客户部成员组成，考虑并授权工程的重大修改〔修改工作量超过一周的〕。
而工程经理负责工程的一般修改决策〔修改工作量在一天以上，一周以内〕。
变更管理活动包括修改请求、评估、通过、执行和跟踪。
变更管理要点如下：
Ø变更批准权限：
Ø变更控制组负责讨论和决策工程的重大修改；
Ø工程经理讨论和决策一般性修改；并报工程管理部备案；
Ø修改审批程序：
Ø根据不同地点的客户有不同的审批程序。
1.1.2.3.1.变更状态登记
变更状态登记活动记录和报告各种配置项的状态，记录在工程生命周期中的任何管理信息和历史信息。
包括：
所有变更请求表、所有变更报告单、所有变更记录。
由工程管理人员存取状态登记。
变更状态登记的目的是为了控制软件需求发生变更时的处理过程，使之按照制定的规程进行，以保证软件需求的一致性。
1.1.2.3.2.变更管理流程
Ø客户方或高伟达提出变更请求，填写变更申请表；
Ø将变更申请表交本工程组的工程经理；
Ø双方工程经理〔或工程经理授权人，必须以书面形式确认〕共同审阅，评估该需求变更的技术有效性和对本工程的影响；
Ø如果审阅批准该请求，那么双方工程经理〔或工程经理授权人，必须以书面形式确认〕签字确认，变更申请表将被贵行文档管理员登记后，转发给高伟达。
如果未获批准，其原因将反响给该需求变更发起人；
Ø高伟达在收到经审阅批准的需求变更申请后的三个工作日内，发给贵行一份书面确认书，确认其收到，并给出分析与执行变更所需时间和工作量的估算；
Ø根据请求的变更程度和复杂度，高伟达进一步进行本钱评估，假设不需本钱，那么直接执行变更工作；假设需要增加本钱，那么以书面形式通知贵行文档管理员，贵行管理员登记后，按照工程管理方法中的工程变更管理流程处理。
1.1.2.4工程沟通管理
南京银行ESB工程是一个技术与业务互动的工程，工程的成功很大程度上依赖于业务人员的参与程度及技术人员对业务需求的透彻分析，这就要求技术与业务人员保证充分的交流，制定并遵守工程内部的沟通管理方案。
1.1.2.4.1.工程沟通形式
根据本工程的组织形式及特点，我们建议采取如下多种方式的沟通形式：
序号
沟通形式
负责人
沟通对象
内容
频度
输出文档
1
领导小组与工程组的联系会议
领导小组组长
工程管理组、领导小组
工程实施状态汇报，问题报告、建议措施并要求得到回复，工程组进行问题回复和传达领导组指示
每两周1次
会议纪要
2
总体组会议
工程总监、工程经理
总体组成员
总体组内部工作分工协调、布置，分析各专业组工作情况和提出的问题决策，为与工程组的联系会议作准备
每周1次
会议纪要
3
专业组组长会议
工程总监、工程经理
各专业组组长、总体组
专业组进行进展汇报、问题汇报及建议措施；总体组部署工作安排，决策，协调，分析进度、问题等
每周1次
会议纪要*
4
专业组内部会议
专业组组长
专业组组员
专业组内部交流会议，任务布置、信息交流、问题讨论等
每2～3天1次
/
5
发动大会
总体组、领导小组
全体人员
在全体工程成员范围内宣布工程总体和阶段目标，回忆前阶段成果，鼓励士气
工程各阶段的开始
/
6
简报
工程助理
全体人员
反映工程动态，包括进展情况、问题及解决方案，本周工作成果、下周工作重点等
每周1次
简报*
7
小组工作周报
专业组组长
总体组
反映各个专业组每周实际工作情况及结果，包括根据方案的执行情况和进度偏差。
每周1次
小组工作周报*
8
个人工作周报
专业组组员
专业组组长
反映个人每周实际工作情况及结果，包括根据方案的执行情况和进度偏差。
每周1次
个人工作周报
9
电子邮件
全体人员
当事人
需讨论问题的非正式书面交流
按实际需求
电子邮件
10
日常交流
全体人员
当事人
需讨论问题的非正式口头交流
按实际需求
/
备注：
1、“负责人〞为各类沟通形式的组织者；
2、“沟通对象〞为需参与各类沟通的工程干系人；
3、“输出文档〞为各类沟通所产生的书面文件，由各类沟通的“负责人〞或其指定人员制作并派发“沟通对象〞；
4、“输出文档〞一栏中有“*〞记号的文件需由工程办公室作为工程文件进行存档。
1.1.2.4.2.会议管理制度
工程开始进行以后，要有效地控制工程，需要在各个关键时刻召开关键会议。
关键会议的主要内容是总结上一阶段的工作，分析问题、提出建议，并介绍下一阶段的主要任务和目标，使各有关人员都能做到心中有数，明确努力的方向。
关键会议也是协调各不同小组之间的人员以及工作任务的重要手段。
除关键会议外，在工程进行的全过程中，应定期召开例会，会上主要介绍工程进展情况，检查进度、是否存在问题等，会议时须做详细的会议记录并在会后报送所有工程相关人员。
主要的工程会议流程规定如下：
Ø会前准备：
◆做好准备工作，如明确会议目的和会议议程等；
◆把会议中要求讨论的材料事先下发给开会成员；
◆提前两天通知各位与会成员；
◆准备会议环境、会议用设备等；
Ø会议之中：
◆会议成员准时到会；
◆按会议议程逐项进行；
◆严格控制会议时间；
Ø会后跟踪：
◆会议决议落实和检查。
1.1.2.5工程质量管理
为保证工程顺利实施及系统质量，必须在工程管理过程和工程实施过程上加大质量管理力度。
通过高伟达公司实施的成功案例，我们深深体会到“质量是方案出来的〞这一现代质量学观点所蕴含的深刻道理，所以，我们在工程启动及工程进展的各个阶段都会仔细制定各项工作方案，严格按照审核通过的方案进行工程控制。
针对本工程，我们建议从QA及QC两方面保障工程的顺利实施，具体的质量保障措施如下：
1.1.2.5.1.质量保证
本工程将设置质量保证小组，由南京银行和高伟达公司各出一名人员担任QA的角色，其工作任务是根据工程总体组制定的质量核对单，在工程进展过程按照质量核对单逐项审核工程是否按照方案约定执行和控制，并直接向南京银行的相关领导汇报工程实施的质量状况。
1.1.2.5.2.正式评审
根据本工程的特点，本工程中将对工程方案、软件需求规格说明书、系统设计说明书、测试规格说明书、测试报告等文档，组织南京银行相关领导、专家进行正式评审，以便审核系统开发中各阶段所产生的过程文档，以保证文档内容与上一阶段所产生的软件文档内容一致，并且符合使用者的需求。
1.1.2.5.3.交叉审查
除工程要求的正式评审内容外，本工程还将对各模块软件代码实行交叉评审制度。
各模块负责人应根据总体组制定的代码质量审核清单，对所负责检查的其他模块软件代码进行仔细审查，对代码质量不能通过交叉评审的那么必须进行返工。
整体的软件代码交叉评审总量不能少于60％。
1.1.2.5.4.变更控制
为保证软件产品质量，开发过程将严格采用配置管理工具进行变更控制，其目的是保证最终软件产品能够符合业务需求的各项要求，并对开发过程进行监控、报告和提供咨询支持，它包括下面的质量属性要求：
Ø软件产品与需求、说明书和设计一致；
Ø按照说明的标准建立文档；
Ø可测试和可维护；
Ø被识别、管理、评审和测试；
Ø当变更发生时可管理。
1.1.2.6工程风险管理
任何工程开发实施过程中都会遇到各种风险，在各方面都会遇到不同规模的风险，因此需要了解工程本身的风险、技术风险、新产品的风险、工程资源风险、工程过程风险等全方位的风险因素。
通过对风险的量化提供一个方案来管理预防风险，同时对于潜在的风险也应该建立意外事件的应急方案，使其在必要时能够以可控的及有效的方式作出反响。
✓针对需求风险，南京银行应把握系统建设起点要高、标准运作为系统建设的根底工程、采用构件化技术进行应哟软件开发、采用B/S技术降低信息点维护本钱的方式躲避需求风险。
✓针对合作风险，选择一个长久的、上规模、具备成熟行业经验、工程管理标准、技术先进、员工有归属感、真正站在用户的立场上考虑问题的公司作为后盾，高伟达集团是能为您最大限度地控制合作风险。
✓针对资源风险，拥有健全的组织与管理，在防止人员流动的根底上，即使因个人原因必须离职时，高伟达公司也因其标准的、体系化的管理与产品架构而使工程根本不受影响或极少受到影响。
✓针对技术风险，高伟达的银行业务系统拥有多个成功实践经验，具备与国外接轨的理念与技术，同时拥有不断调整、更新的技术体系、以及参照标准体系指定标准质量标准并在实施过程中加强阶段评审，使因为技术原因而可能导致的风险降低到最小。
除此之外，为预防操作风险，在南京银行自身加强制度管理的根底上，高伟达还提供培训考试合格上岗及定期培训定期总结分析的模式来躲避此类风险。
1.1.2.6.1.风险管理内容
风险管理的内容如下：
Ø工程实施前和实施中对风险的发现、识别、上报、分析及风险责任人的指定；
Ø风险应对方案的制订和执行〔应对方案包括两局部，一是在如何降低风险发生机率的躲避方案；一是当风险不幸变成现实时，如何应对的应急预案〕；
Ø风险状态的监控和更新；
Ø定期对工程风险进行统计、分类和总体结构分析。
1.1.2.6.2.风险管理中的相关角色和责任
参与方
角色
职责
备注
风险识别人
工程相关的任何人
报揭发现的风险，填写风险登记表描述风险，注明风险严重度、风险发生机率和风险分类
如果是工程相关人员，提交至工程经理，如果是工程管理办公室人员，提交工程管理办公室主任
工程经理
工程内风险管理负责人
在工程进行中，管理工程内的风险并提供工程内的应对方案
对于无法在工程内解决的风险，审核风险登记表，并确认风险描述、风险发生机率、风险责任人以及风险发生后的应急预案
口头确认或书面认可上报的风险登记表,将风险登记表发往相应部门
工程管理办公室
工程整体风险管理的执行监督机构
在工程启动前，组织定义工程级别的风险登记、评估和应对方案
在工程实施阶段，对工程报送的相关风险登记表和应对方案进行审核，重点审核跨工程的风险、严重度为中或中以上的风险和发生机率为中或中以上的风险,建议整个工程的应对方案
根据对工程全社的考虑，更改工程上报风险之严重度、发生机率和风险责任人
对于无法解决、风险严重度为中或中以上的风险，负责上报工程总监
跟踪风险进展，对异常进展的风险进行预警
定期统计分析工程风险，在工程周报和月报中提交风险统计情况
工程总监
风险管理最终决策机构
对重大风险，进行决策，给出最终处理意见
风险责任人
风险躲避、应急预案执行的负责人
填写风险登记表的风险分析与行动方案
负责风险应对的执行、并汇报风险状态变化
1.1.2.6.3.风险严重程度
Ø灾难的：
会因为无法满足需求而导致任务失败，会产生错误导致进度延迟和预算严重超支；
Ø严重的：
会因为无法满足需求而导致系统性能下降，使得工程能否成功受到置疑，严重影响工程里程碑的范围、交付日期和交付质量以及会影响其它工程进展的风险；
Ø轻微的：
会因为无法满足要求而导致次要任务的退化，影响工程里程碑的范围、交付日期和交付质量以及会影响其它工程进展的但不严重的风险；
Ø可忽略的：
不影响或轻微影响工程里程碑的范围、交付日期和交付质量的风险，只是无法满足要求而导致使用不方便或不易操作。
1.1.2.6.4.风险状态
Ø已提交：
风险识别人已填写风险登记表，完成了风险号分配、风险描述并有工程经理提交；
Ø拒绝：
工程管理办公室认为风险导入人所提出的风险不属于工程风险；
Ø已完成方案：
风险责任人得到风险登记表后，对其进行分析并完成应对方案；
Ø躲避方案：
风险责任人正在根据应对方案躲避风险；
Ø风险已躲避：
风险责任人已成功躲避风险并得到工程管理办公室认可；
Ø发生进入应急方案：
风险责任人未成功躲避风险，风险发生，执行应急预案。
1.1.2.6.5.风险分类
本工程中，风险主要分为以下几类：
Ø管理类风险
工程管理没有遵循工程管理的制度、时间、岗位的要求。
出现工程的风险。
Ø资源类风险
由于人力资源、设备环境等原因产生。
例如，ATM设备没有驱动程序，无法进行程序调试。
Ø业务类风险
业务风险主要表现在业务需求不清晰，变动频繁。
Ø技术类风险
技术风险主要表达在技术架构不合理，各个子系统、效劳渠道无法进行整合。
1.1.2.6.6.风险管理流程
风险管理流程包括：
Ø工程启动前风险识别与防范流程
在各工程启动前，应当由工程管理办公室指导各个工程提交其工程风险因素识别、评估和应对措施方案；
工程管理办公室根据各工程的风险识别方案，以及其对工程风险的理解，完成工程风险因素识别、评估和躲避的工程风险躲避方案以及制订工程风险应急预案；
工程管理办公室将有关风险应对方案上报工程总监审批；
将工程总监审批过的风险应对方案提交给领导领导组审批；
审批通过的风险应对方案由工程管理办公室公布归档；
在工程实施过程中由工程经理管理风险应对方案的执行，工程管理办公室通过工程周、月报跟踪监督。
如以以下图示：
Ø工程运行中风险管理流程
在工程实施过程中，所有工程组成员均有责任报告进程中发现的风险因素，并报告工程经理；
工程经理在确定其确为风险后，定义风险发生机率和严重度并指定风险责任人，制订风险一旦发生的应急预案，并将其填写风险登记表上报工程管理办公室；
工程管理办公室审核风险发生机率、严重度和风险责任人并负责风险状态的监控；
风险责任人负责编制风险应对方案，并定期报告风险状态；
工程管理办公室负责发现跨工程的风险因素，并主持评估躲避方案和应急预案；
工程管理办公室将有关风险评估报告和躲避方案、应急预案上报工程总监审批；
所有发现的风险因素和审批通过的相应风险应对方案由工程管理办公室公布归档；
在工程实施过程中由工程经理管理风险应对方案的执行，工程管理办公室通过工程周、月报跟踪监督。
如以以下图示：
1.1.3工程实施方案
1.1.3.1.1.工程组织架构
有效的组织结构，是工程成功的有力保证。
对于一个银行效劳总线工程，除了考虑工程的有效管理，也要考虑SOA类工程的实施特点；根据本次工程的范围和要求，工程的参考组织结构如下
1.1.3.1.1.1工程管理委员会
工程管理委员会负责监督并指导工程的实施进程，定期审核工程经理就工程进展执行情况的书面报告，对工程中存在的重大问题做出决策，协调解决重大问题和突发事件，决定对工程经理的任免。
工程管理委员会由南京银行高层领导与本公司高层领导共同组成。
1.1.3.1.1.2效劳总线管理组
向工程管理委员会负责，在工程实施过程中进行效劳标准和原那么的控制，在未来工程实施完毕后，由这个组织管理和批准新的效劳发布和渠道系统的接入。
同时负责制定企业实施SOA工程的总体规划，从企业级的高度而非工程级参与工程管理。
效劳总线管理组由南京银行架构师和本公司企业架构师共同组成。
工程实施完成后职责交给客户执行。
1.1.3.1.1.3工程管理组
负责向工程管理委员会定期报告工程进展情况，就工程中存在的问题提出解决建议，对工程进行有
升级会员 