IT项目实施与管理方案-投标书06600.docx

《IT项目实施与管理方案-投标书06600.docx》由会员分享，可在线阅读，更多相关《IT项目实施与管理方案-投标书06600.docx（19页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1.1项目实施与管理111项目实施方法论针对南京银行企业服务总线系统项目，高伟达公司基于对客户需求、业务目 标、业务能力和|丁环境的理解，结合多年的软件开发和系统实施经验，将项目 的实施周期划分为六个活动阶段，保证在项目生命周期内，应用合理的项目管理 和控制技术。通过专注于使客户投资回报最大化，和使客户的投资风险最小化的 关键战略和战术领域，加快项目实施速度，使得项目成功地完成。这些阶段的特 性是可循环往复性，使客户可以尽快地获得新的应用系统所带来的好处。111.1项目定义阶段在这个阶段，所有与分期实施相关的项目活动都被明确定义，项目的项目利 益相关者被指定，项目经理和客户项目经理的角色和职责

2、被传达给所有的项目 利益相关者。管理项目所需的项目控制结构被定义,所有需要的项目规划文件被 创建，客户的业务问题和被用来衡量项目成功的衡量标准被确认。制定解决方案范围，在一个高级别上定义哪些模块将被实施，估算预期需要 的客户化程度，以及勾画出在产品之外需要开发的内容和要提交的技术成果。解 决方案范围文档包括解决方案范围概述，功能范围，流程范围，客户化问题，其 他风险，外部依赖条件以及假设。这个工作为未来项目决策，统一或达成项目利 益相关者之间就有关项目参数的共识，提供书面的文档。它阐述以sow为基础 的业务需求，并且把它转化成产品模块实施信息。序号沟通形式负责人沟通对象内容频度输出文 档9电子

3、邮件全体人员当事人需讨论问题的非正式 书面交流按实际 需求电子邮件10日常交流全体人员当事人需讨论问题的非正式口头交流按实际 需求/备注：1、“负责人”为各类沟通形式的组织者；2、“沟通对象”为需参与各类沟通的项目干系人；3、“输出文档”为各类沟通所产生的书面文件，由各类沟通的“负责人”或其指定人员 制作并派发“沟通对象”；4、“输出文档” 一栏中有记号的文件需由项目办公室作为项目文件进行存档。1.1242会议管理制度项目开始进行以后，要有效地控制项目，需要在各个关键时刻召开关键会议。 关键会议的主要内容是总结上一阶段的工作，分析问题、提出建议，并介绍下一 阶段的主要任务和目标，使各有关人员都

4、能做到心中有数，明确努力的方向。关 键会议也是协调各不同小组之间的人员以及工作任务的重要手段。除关键会议外，在项目进行的全过程中，应定期召开例会，会上主要介绍项 目进展情况，检查进度、是否存在问题等，会议时须做详细的会议记录并在会后 报送所有项目相关人员。主要的项目会议流程规定如下：会前准备：做好准备工作，如明确会议目的和会议议程等；把会议中要求讨论的材料事先下发给开会成员；提前两天通知各位与会成员；准备会议环境、会议用设备等；会议之中：会议成员准时到会；按会议议程逐项进行;严格控制会议时间；会后跟踪：会议决议落实和检查。1.125项目质量管理为保证项目顺利实施及系统质量，必须在项目管理过程和

5、项目实施过程上加 大质量管理力度。通过高伟达公司实施的成功案例，我们深深体会到“质量是计 划出来的”这一现代质量学观点所蕴含的深刻道理，所以，我们在项目启动及项 目进展的各个阶段都会仔细制定各项工作计划，严格按照审核通过的计划进行项 目控制。针对本项目，我们建议从QA及QC两方面保障项目的顺利实施，具体的质 量保障措施如下：1.1.2.5.1, 质量保证本项目将设置质量保证小组，由南京银行和高伟达公司各出一名人员担任 QA的角色，其工作任务是根据项目总体组制定的质量核对单，在项目进展过程 按照质量核对单逐项审核项目是否按照计划约定执行和控制，并直接向南京银行 的相关领导汇报项目实施的质量状况。

6、1.1.2.5.2, 正式评审根据本项目的特点，本项目中将对项目计划、软件需求规格说明书、系统设 计说明书、测试规格说明书、测试报告等文档，组织南京银行相关领导、专家进 行正式评审，以便审核系统开发中各阶段所产生的过程文档，以保证文档内容与上一阶段所产生的软件文档内容一致，并且符合使用者的需求。1.1.2.53 .交叉审查除项目要求的正式评审内容外，本项目还将对各模块软件代码实行交叉评审 制度。各模块负责人应根据总体组制定的代码质量审核清单，对所负责检查的其 他模块软件代码进行仔细审查，对代码质量不能通过交叉评审的则必须进行返 工。整体的软件代码交叉评审总量不能少于60%。1.1.2.54 变

7、更控制为保证软件产品质量，开发过程将严格采用配置管理工具进行变更控制，其 目的是保证最终软件产品能够符合业务需求的各项要求，并对开发过程进行监 控、报告和提供咨询支持，它包括下面的质量属性要求：软件产品与需求、说明书和设计一致；按照说明的标准建立文档；可测试和可维护；被识别、管理、评审和测试；当变更发生时可管理。1.1.2.55 险管理任何项目开发实施过程中都会遇到各种风险，在各方面都会遇到不同规模的 风险，因此需要了解工程本身的风险、技术风险、新产品的风险、工程资源风 险、工程过程风险等全方位的风险因素。通过对风险的量化提供一个计划来管理 预防风险，同时对于潜在的风险也应该建立意外事件的应急

8、计划，使其在必要时 能够以可控的及有效的方式作出反应。针对需求风险，南京银行应把握系统建设起点要高、规范运作为系统建设的 基础工程、采用构件化技术进行应哟软件开发、采用B/5技术降低信息点维护成本的方式规避需求风险。针对合作风险，选择一个长久的、上规模、具备成熟行业经验、项目管理规 范、技术先进、员工有归属感、真正站在用户的立场上考虑问题的公司作为 后盾，高伟达集团是能为您最大限度地控制合作风险。针对资源风险，拥有健全的组织与管理，在避免人员流动的基础上，即使因 个人原因必须离职时，高伟达公司也因其规范的、体系化的管理与产品架构 而使项目基本不受影响或极少受到影响。针对技术风险，高伟达的银行业

9、务系统拥有多个成功实践经验，具备与国外 接轨的理念与技术，同时拥有不断调整、更新的技术体系、以及参照标准体 系指定规范质量标准并在实施过程中加强阶段评审，使因为技术原因而可能 导致的风险降低到最小。除此之外，为预防操作风险，在南京银行自身加强制度管理的基础上，高伟 达还提供培训考试合格上岗及定期培训定期总结分析的模式来规避此类风险。1.1.2.6.1, 风险管理内容风险管理的内容如下：项目实施前和实施中对风险的发现、识别、上报、分析及风险责任人的 指定；风险应对计划的制订和执行（应对计划包括两部分，一是在如何降低风 险发生机率的规避计划；一是当风险不幸变成现实时，如何应对的应急 预案）；风险状

10、态的监控和更新；定期对项目风险进行统计、分类和总体结构分析。1.1.2.6.2, 风险管理中的相关角色和责任参与方角色职责备注参与方角色职责备注风险识别项目相关人的任何人责人项目管理办公室项目整体 风险管理 的执行监 督机构报告发现的风险，填写风险登记表描述风险，注明风险严重度、风险发生机率和风险分类如果是项目相关人员，提交至项目经理，如果是项目管理办公室人员，提交项目管理办公室 主任项目经理 项目内风 在项目进行中，管理项目内的风险并提供项目 险管理负内的应对计划对于无法在项目内解决的风险，审核风险登记 表，并确认风险描述、风险发生机率、风险责 任人以及风险发生后的应急预案口头确认或书面认可

11、上报的风险登记表,将风险登记表发往相应部门在项目启动前，组织定义项目级别的风险登记、 评估和应对计划在项目实施阶段，对项目报送的相关风险登记 表和应对计划进行审核，重点审核跨项目的风 险、严重度为中或中以上的风险和发生机率为 中或中以上的风险，建议整个项目的应对计划根据对项目全社的考虑，更改项目上报风险之 严重度、发生机率和风险责任人对于无法解决、风险严重度为中或中以上的风 险，负责上报项目总监跟踪风险进展，对异常进展的风险进行预警 定期统计分析项目风险，在项目周报和月报中 提交风险统计情况参与方角色职责备注项目总监风险管理最终决策机构对重大风险，进行决策，给出最终处理意见风险责任人风险规 避

12、、应急 预案执行 的负责人填写风险登记表的风险分析与行动计划负责风险应对的执行、并汇报风险状态变化风险严重程度灾难的：会因为无法满足需求而导致任务失败，会产生错误导致进度延 迟和预算严重超支；严重的：会因为无法满足需求而导致系统性能下降，使得项目能否成功 受到置疑，严重影响项目里程碑的范围、交付日期和交付质量以及会影 响其它项目进展的风险；轻微的：会因为无法满足要求而导致次要任务的退化，影响项目里程碑 的范围、交付日期和交付质量以及会影响其它项目进展的但不严重的风 险；可忽略的：不影响或轻微影响项目里程碑的范围、交付日期和交付质量 的风险，只是无法满足要求而导致使用不方便或不易操作。1.1.2

13、.6.4, 风险状态已提交：风险识别人已填写风险登记表，完成了风险号分配、风险描述 并有项目经理提交；拒绝：项目管理办公室认为风险导入人所提出的风险不属于项目风险； 已完成计划：风险责任人得到风险登记表后，对其进行分析并完成应对 计划;规避计划：风险责任人正在根据应对计划规避风险；风险已规避：风险责任人已成功规避风险并得到项目管理办公室认可；发生进入应急计划：风险责任人未成功规避风险，风险发生，执行应急 预案。1.1.2.6.5, 风险分类本项目中，风险主要分为以下几类：管理类风险项目管理没有遵循项目管理的制度、时间、岗位的要求。出现项目的风 险。资源类风险由于人力资源、设备环境等原因产生。例

14、如，ATM设备没有驱动程序，无法进行程序调试。业务类风险业务风险主要表现在业务需求不清晰，变动频繁。技术类风险技术风险主要体现在技术架构不合理，各个子系统、服务渠道无法进行整 合。1.1.2.6.6, 风险管理流程风险管理流程包括：项目启动前风险识别与防范流程在各项目启动前，应当由项目管理办公室指导各个项目提交其项目风险因素 识别、评估和应对措施计划；项目管理办公室根据各项目的风险识别计划，以及其对项目风险的理解，完成项目风险因素识别、评估和规避的项目风险规避计划以及制订项目风险应急预 案；项目管理办公室将有关风险应对计划上报项目总监审批；将项目总监审批过的风险应对计划提交给领导领导组审批；审

15、批通过的风险应对计划由项目管理办公室公布归档；在项目实施过程中由项目经理管理风险应对计划的执行，项目管理办公室通 过项目周、月报跟踪监督。如下图示：项目启动前风险识别与防范流程项目领导组审核并批准组织进行项目级 风险识别评估分析风险发生概 率和严重性，并 指定风险责任人汇总、分析所有 对项目群有重要 影响的风险卷标典皿旨项目运行中风险管理流程在项目实施过程中，所有项目组成员均有责任报告进程中发现的风险因素, 并报告项目经理；项目经理在确定其确为风险后，定义风险发生机率和严重度并指定风险责任 人，制订风险一旦发生的应急预案，并将其填写风险登记表上报项目管理办公室;项目管理办公室审核风险发生机率、

16、严重度和风险责任人并负责风险状态的监 控；风险责任人负责编制风险应对计划，并定期报告风险状态；项目管理办公室负责发现跨项目的风险因素，并主持评估规避计划和应急预 案；项目管理办公室将有关风险评估报告和规避计划、应急预案上报项目总监审 批；所有发现的风险因素和审批通过的相应风险应对计划由项目管理办公室公布归 档；在项目实施过程中由项目经理管理风险应对计划的执行，项目管理办公室通 过项目周、月报跟踪监督。如下图示：简而言之，这个阶段组建项目团队，保证客户实施项目的成功。公司人员与 客户人员一道，组建项目团队，设定项目方法和范围，并建立项目管理控制。主 要交付的成果有，解决方案范围和项目管理控制。制

17、定了项目质量检查计划。需求分析阶段在需求调研阶段，在项目管理小组的指导下，由公司和客户组成的统一的项 目团队将识别并且书面记录在开始设计客户解决方案之前所必须弄清楚的，需处 理的问题。项目团队书写、提炼满足客户业务目标所需的功能和技术要求。主要 交付的技术成果为业务需求和差距分析。专家服务顾问将进行一个配置检查，以保证系统有精确的规格，便于购买硬 件和架构部署。在有技术客户经理参与的情况下，通过完成初始的评估，来建立 部署的基准，及通过给战略，管制，用户采用，流程和技术各方面打分的评估来 建立业务目标。111.3项目设计阶段在设计阶段，主要的目标是设计一个能够最佳地满足客户明确的业务需求的 解

18、决方案，并且为培训和系统测试做准备。在设计（Design）阶段，项目团队利用应用系统屏幕流程和设计布局来映射在 发现阶段确定的需求，设计解决方案的原型。主要交付的技术成果是解决方案设计文档和测试策略。这个策略定义测试计 划和测试要求，以保证一个系统部署的成功。主要的目的是提供一个高级的测试 策略，以便使用自力化的测试工具和/或手工过程来实现功能测试,系统整合测试 （51丁）,用户验收测试（UAT）和性能测试。专家服务顾问要执行设计检查，来评估由客户或集成商提供的书面设计文档，并且提供详细的建议清单。设计标准包括，但不限于，应用系统性能，对升级 的影响，应用系统维护，与数据模型相关的问题和常规的

19、最佳做法。1.114项目开发阶段在开发阶段，项目团队将开发应用系统，提供任何需要的扩展功能和外部接 口，为客户部门部署和持续支持解决方案做准备。项目团队配置应用系统、所有 需要的扩展功能和外部接口。主要交付的技术成果有功能测试和系统测试。这些 流程整合和测试活动更好地保证介入的系统功能与客户组织的业务需求协调一 致。专家服务顾问应该进行一个配置检查，来评估所有经过客户化改造的实施文 档。在这个检查过程中，所有这样的文件都将被评估，以使应用系统性能，应用系 统升级，系统维护工作量和常规最佳实践最优。111.5项目验证阶段在验证阶段，将完成新系统全部功能的测试。这个阶段分两个部分。第一部 分，项目

20、团队进行一个对有生产数据的应用系统的全部功能进行测试。在这个检 测完成后，关键用户然后进行一个代表性的验收测试，以保证系统正确地处理用 户的需求。一旦全面的功能测试结束，将进行一个使用系统工具的，严格的性能 测试。这一阶段主要交付的技术成果为用户验收测试和性能测试结果，包括性能, 容量和寿命测试。适时的性能调整审计，可保证整个企业架构环境的性能最佳。在这个检查中, 专家服务将主动性地识别任何性能问题，这样将减少在运行时出现问题的风险， 增加系统生产切换的信心。在有技术客户经理参与的情况下，可执行一个实施准 备就绪检查，以确认系统是否可以部署了。这个实施准备就绪检查是用来评估实施风险，技术上是否

21、准备停当以及部署策略。此时，应该召开管理人员定向协调研讨会，将责任转移给一线的员工，这些 员工将开始支持业务流程和技术的推出。在管理人员定向协调研讨会上，项目团 队与客户的管理团队一起工作，以获得维持资助人的内部负责，并把正确的信号 传达给组织的其他成员。部署上线阶段部署上线阶段内的第一个活动是实施一个投产导航。这个导航是被用来测试 全面的生产部署，并且在客户业务环境中的一部分部门中进行的，例如一个地区 或一个区域。生产导航在机构的业务环境中部分部门里，为用户提供所有系统的 特点。来自于生产导航的反馈信息指导整个的部署。同样在这个过程中，专家服务顾问应该进行生产准备就绪检查，通过主动地 识别任

22、何可能造成部署中断和使实施的系统解决方案的技术优点打折扣的所有 问题，来协助系统的顺利推出。此时，要召开流程实施研讨会，部署流程最优实践，来优化人，流程和技术的 配合。目的是在客户所有的一线机构中，使用变革和销售流程的最佳实践，使最 初的赞助人和行政领导团队完全满意。112项目管理方案1.121 项目管理概述项目管理包括在项目生命周期中协调所有项目管理知识领域所涉及的过程。 它确保项目所有的组成要素在正确的时间结合在一起，以成功的完成项目。进行 项目整体管理时，必定涉及项目的范围、质量、时间和成本管理以及人力资源、 沟通、风险管理等各个环节，项目管理一个复杂的工程，在此主要针对南京银行 企业服

23、务总线项目的项目进度管理、变更管理、沟通管理、质量管理、风险管理等相关策略进行描述。1.122 项目进度管理通过项目进度的管理最终明确项目开发阶段的进度控制活动和关键流程。项目经理：根据软件开发计划编制详细的阶段开发计划以及每项任务的边界时 间，并召集过程控制人员、专题小组负责人审核该计划； 审核各专题小组拟订的每项任务的日程安排；检查和控制项目进度；制定进度变更计划；过程控制人员：协助审核详细的阶段开发计划和任务边界时间；监督项目进展；专题小组负责人：协助审核详细的阶段开发计划和任务边界时间；在听取小组成员意见的基础上，拟订每一项任务的日程安排；负责检查和控制任务的进度，并填写进度控制表；负

24、责制订任务变更计划。1.1.2.2.1,进度安排流程项目经理根据项目计划，明确该阶段的边界时间；根据项目计划中的任务PERT网络图，找出该阶段的关键任务并进一步分解、细化，在此基础上绘制更具体的阶段任务PERT网络图；拟订详细的阶段计划；确定每一关键任务的边界时间；召集各专题小组负责人审核拟订的计划，并修改；专题小组负责人确定任务的日程安排；对于大型的或时间要求严格的项 目，进度安排应以天为单位；征求小组成员的意见；交由项目经理和过程管理人员审核。1.1.222.进度控制流程项目经理和过程管理人员按照阶段PERT图，标志阶段中被跟踪的关键 任务和里程碑，并将之告知专题小组负责人；专题小组负责人

25、按照任务的日程安排，确定任务完成期间的关键时间点, 并将之告知专题小组成员；专题小组负责人经常与成员沟通，了解任务进展；并定期检查，填写任 务进度表和下期计划表，及时发现问题；项目经理定期组织专题小组负责人，召开项目状态会议，了解任务进展, 及时发现问题；项目过程管理人员参加会议或了解会议的记录； 专题小组负责人在执行中发现延迟，分析原因：人员紧张：组内调配不了的，找项目经理解决；事先预估不足：调整任务日程安排；若解决不了，告知项目经理， 会同过程管理人员，调整详细的阶段计划；如果阶段内消化不了的 问题，则项目经理按照配置管理的程序，变更软件开发计划。1.123项目变更管理针对项目变更管理组织

26、变更控制小组，由项目组经理、项目管理部人员、项 目总监、客户、客户部成员组成，考虑并授权项目的重大修改（修改工作量超过 一周的）。而项目经理负责项目的一般修改决策（修改工作量在一天以上，一周 以内）。变更管理活动包括修改请求、评估、通过、执行和跟踪。变更管理要点如下:变更批准权限:变更控制组负责讨论和决策项目的重大修改；项目经理讨论和决策一般性修改；并报项目管理部备案；修改审批程序：根据不同地点的客户有不同的审批程序。1.1.2.3.1.变更状态登记变更状态登记活动记录和报告各种配置项的状态，记录在项目生命周期中的 任何管理信息和历史信息。包括：所有变更请求表、所有变更报告单、所有变更 记录。

27、由项目管理人员存取状态登记。变更状态登记的目的是为了控制软件需求发生变更时的处理过程，使之按照 制定的规程进行，以保证软件需求的一致性。1.1.232.变更管理流程客户方或高伟达提出变更请求，填写变更申请表；将变更申请表交本项目组的项目经理；双方项目经理（或项目经理授权人，必须以书面形式确认）共同审阅， 评估该需求变更的技术有效性和对本项目的影响；如果审阅批准该请求，则双方项目经理（或项目经理授权人，必须以书 面形式确认）签字确认，变更申请表将被贵行文档管理员登记后，转发 给高伟达。如果未获批准，其原因将反馈给该需求变更发起人；高伟达在收到经审阅批准的需求变更申请后的三个工作日内，发给贵行 一

28、份书面确认书，确认其收到，并给出分析与执行变更所需时间和工作 量的估算；根据请求的变更程度和复杂度，高伟达进一步进行成本评估，若不需成本，则直接执行变更工作；若需要增加成本，则以书面形式通知贵行文 档管理员，贵行管理员登记后，按照项目管理办法中的项目变更管理流 程处理。112.4项目沟通管理南京银行E5B项目是一个技术与业务互动的项目，项目的成功很大程度上 依赖于业务人员的参与程度及技术人员对业务需求的透彻分析，这就要求技术与 业务人员保证充分的交流，制定并遵守项目内部的沟通管理计划。112.41项目沟通形式根据本项目的组织形式及特点，我们建议采取如下多种方式的沟通形式:序号沟通形式负责人沟通

29、对象内容频度输出文 档1领导小组与项目组的联系会议领导小组组长项目管理组、领导小组项目实施状态汇报， 问题报告、建议措施 并要求得到回复，项 目组进行问题回复和传达领导组指示每两周1 次会议纪要2总体组会议项目总监、项目经理总体组成 员总体组内部工作分工 协调、布置，分析各 专业组工作情况和提 出的问题决策，为与 项目组的联系会议作 准备每周1次会议纪要3专业组组长项目总各专业组专业组进行进展汇每周1次会议纪序号沟通形式负责人沟通对象内容频度输出文 档会议监、项目经理组长、总体组报、问题汇报及建议 措施；总体组部署工 作安排，决策，协调， 分析进度、问题等要*4专业组内部会议专业组 组长专业组组员专业组内部交流会 议，任务布置、信息 交流、问题讨论等每23天1次/5动员大会总体组、领导小组全体人员在全体项目成员范围 内宣布项目总体和阶 段目标，回顾前阶段 成果，激励士气项目各 阶段的 开始/6简报项目助理全体人员反映项目动态，包括 进展情况、问题及解 决方案，本周工作成 果、下周工作重点等每周1次简报*7小组工作周 报专业组 组长总体组反映各个专业组每周 实际工作情况及结 果，包括根据计划的 执行情况和进度偏 差。每周1次小组工作周报*8个人工作周 报专业组 组员专业组组 长反映个人每周实际工 作情况及结果，包括 根据计划的执行情况 和进度偏差。每周1次个人工作周报