系统集成项目范围管理

系统集成项目范围管理（精选6篇）

篇1：系统集成项目范围管理

论信息项目范围管理

摘要：

2011年5月，我作为项目经理，带领团队实施了XX油田生产运行管理系统建设项目。该项目投资为380万元，建设周期为一年。该油田拥有各类油水井9万余口，分别在其下属的20个采油厂所管辖的153个采油队管理，因油水井数量大，各基层单位管理模式不同，对数据建设认识程度不高，造成了油水井现场相关数据管理混乱，给生产运行管理、科研数据收集等工作带来了不便。为此，立项实施生产运行管理系统建设，将油井设备型号、每日运行状态，日生产动态数据、油田主要作业情况，进行统一建库管理，进而加强生产动态数据的统计分析，以提高生产运行管理水平。本文结合作者的实践，以XX油田生产运行管理系统建设为例，讨论信息项目的范围管理，重点论述编制范围计划、创建工作分解结构，以及范围确认、控制等工作，最后总结分析项目范围管理的成功经验，以及项目经理管理方面存在的不足以及需要努力的方向。

正文

2011年5月13日，XX油田生产运行管理系统启动建设，我有幸担任项目经理，经过为期近一年的努力，2012年5月1日系统正式上线运行，并通过验收。项目为软件开发，不涉及硬件采购集成，总投资为380万元。系统采用JSP语言开发，B/S架构，中间件为weblogic，后台数据库为ORACLE。该项目主要分为四个部分：井场设备管理子系统、采油数据管理子系统、钻井动态管理子系统、井下作业管理子系统。平台分为三个应用层级，采油队负责数据录入，采油厂负责审核数据，公司层面实现数据统计分析，用于生产运行指挥决策支持。通过系统的应用，客户方实现了9万口油水井设备型号、配件型号的电子建档管理，实现了井场设备运行情况动态监测，油井现场钻井、井下作业动态、油水井采油动态数据的入库管理，自动统计分析等功能，减少了各层级统计人员工作压力，实现了无纸化办公，大大缩短了故障响应周期，为该公司生产数据有序管理，油水井设备调拨、措施井评价等工作提供了有效支撑，提高了生产运行管理能力。

在本项目建设过程中，除了精心抓好其他管理工作外，我重点加强了范围管理，因“生产运行”概念较大，只有在项目初期，清楚甲方企业环境因素，明确对范围进行定义，形成基线，并在项目的进行过程中进行严格的控制，才能防止蔓延现象的发生，保证项目按照进度、成本和质量的要求顺利完成。项目建设过程中，我特别重视项目的范围计划编制、分解，以及范围确认和控制工作。

1、精心组织编制范围计划

明确项目范围是软件研发工作顺利实施的前提。为了更好的组织范围计划编制工作，我充分分析了甲方的企业环境因素，得知生产管理部系该公司生产运行管理的责任部门。生产管理部、采油厂生产科、采油队工作人员是该系统的主要干系人，我通过问卷调查、会议讨论等方式捕获收集业务需求。经分析，系统建设数据采集方面包括：油水井设备、配件型号信息、生产动态数据，应用方面包括：采油队、采油厂、油田公司三个层次的动态数据日报表、月报表、年报表，2、井损坏状态信息统计，3、增油措施评价，4、钻井、井下作业动态等。明确业务需求后，我带领团队从技术角度出发，转变为技术需求，继而形成软件规格需求说明书SRS，范围管理计划的编制工作就变得有章可循。

我通过参照甲方专家判断、应用历史项目的模板、表格工具，制定了范围计划，力求稳步推进详细项目范围说明书编制到创建WBS，力求使成果交付和变更事宜更加正式和流程清晰。当然，这些工作的前提是明确范围定义。

2、从全局出发做好范围定义

定义详尽的项目范围说明书对于项目的成功至关重要。从全局出发做好范围定义，可以有效防止范围蔓延。就我所管理的项目而言，甲方生产业务链条较长，其成产过程包括：钻井、录井、测试、井下作业、采油等多个环节。我采用“德尔菲法”，邀请客户高层领导、科研人员、生产管理人员，现场工作人员经过反复分析论证，确定了油水井现场钻井、井下作业（修井及措施）、采油三项生产动态监测的范围，明确了限定条件和可交付物。此工作虽然耗费了一段时间，但所有项目干系人之间形成了项目范围共识，提供了一个范围边界，对判断变更起到了边界作用。

宏观上三个业务范围已经明确，我要求团队就各业务体系纵向上加以分析，进一步明确了通过钻井、采油的监测，实现数据统计分析；通过井下作业监测，实现设备配件调拨、措施增油效果评价等应用，进而实现提高整体生产运行管理水平的总体目标。

通过宏观和纵向业务范围的定义，项目团队明确了项目目标、范围、需求、项目边界以及可交付物等信息，形成了较为详尽的范围说明书，下一步工作重点就是将其分解为更小、更易管理的工作单元。

3、科学创建工作分解结构

工作分解结构是组织项目管理工作的主要依据。将项目范围分解开来，能够使项目的概况和组成明确、清晰、透明、具体。使项目干系人都能把握和了解项目。在该项目中，我首先按照以往工作分解模板，将项目的建设过程按照生命期进行分解为：确定需求、系统设计、研发、测试、安装5个阶段，同时又将每个阶段的工作进行划分，保持项目的完整性。例如需求，我又将其划分为数据采集平台建设需求、统计需求、生产运行指挥需求等。并通过WBS字典加以描述。

在创建分解结构的同时，我将人力资源、资金、进度分解到每个单元，同时我要求各分项负责人要进一步将工作分解细化，确立子项目，将质量管理贯穿于各阶段，以便于执行和实现目标要求，保证项目建设科学、有序推进。

4、有序组织开展范围确认

范围确认是项目干系人所关注的重点，包括工作分解结构、可交付物、阶段成果和最终结果等。范围确认贯穿于项目的始终，因此，有序组织开展范围确认是必要的。在本项目每个阶段任务完成时，我都组织“检查”，例如：采油动态数据采集模块开发完成时，我组织开展了阶段审查，向客户展示了采集界面，讲解了产液量、含水率、产油量等数据采集项，及数据单位规范，提交了阶段总结，征求了需求

满意度确认信息等。同时要求团队认真对待每一个变更申请，及时确定纠正措施，并根据工作进度和变更情况，及时更新WBS和WBS字典，保证每个阶段工作经得起检查，力求每个环节都成为经得起检验的里程碑。

5、严抓范围控制

众所周知，项目建设过程中，变更是不可避免的，为防止范围蔓延，做好范围控制尤为重要。对于范围控制我从三方面严抓：一是严抓范围定义，确定边界；二是严抓变更流程，所有变更必须经CCB进行审核，三是，严谨确定是否执行纠正。接到客户的变更申请时，我要求参照项目范围说明书及阶段绩效信息，认真开展偏差分析，查找原因。例如：甲方要求采油数据应用“方”和“吨”两种单位进行量化，究其原因是各基层采油厂计量单位不统一造成的。经团队分析，此变更不会对系统架构、功能稳定性构成影响，但我方认为统一数据标准是精细化管理的重要内容之一，经协商，甲方采纳了我们的意见，数据标准通过系统应用，得以控制、统一。

经过为期一年的努力，系统建设按预期完成，并得到有效应用。实现了油水井设备运行监测、单井采油数据规范管理，生产动态实时掌握，措施评价及时、客观，为生产运行指挥、科研工作提供了及时的数据决策支撑，受到了该公司的高度评价和认可。

本项目的成功经验在于：范围定义准确，边界划分清晰，工作分解结构设置得当，并实现了有效的范围控制。不足之处有：我及我的团队没有懂石油专业的技术人员，致使范围定义有些不便，但中期通过交流和自身学习，得以改善，没有影响后续工作。这就提示我们项目经理，在今后工作中，要加强客户方企业环境因素及业务领域的学习，提高自身的综合素质，才能更好的驾驭本职工作。

篇2：系统集成项目范围管理

20xx年10月，我作为项目经理参与了**省**市人民防空办公室的指挥平台升级改造项目的建设，该项目投资约300万元人民币，建设工期3个月。通过该项目的建设，主要实现了以下几个功能：1、地上与地下指挥所通过有线通信实现音视频的互联互通；地上指挥所和机动指挥车视距通过无线短波图传，单兵4G和卫星通信（动中通）实现音视频互联互通。2、既有视频信号和新增信号源均实现数字化高清网络传输。跳出以往通过高清、标清视频矩阵的束缚，对视频信号源通过IP的形式直接通过网络处理器传输到各显示单元大屏幕上显示。3、地上指挥所、地下指挥所均可直接控制三个指挥单元的信号传输，通过分布式控制器与信令主机的通信，摆脱先前以地上指挥所为通信枢纽的模式，实现分布式控制。在本项目中范围管理尤为重要，我作为项目经理，除对其余管理领域进行恪尽职守的管理外，特别对范围管理从制定范围管理计划、范围定义、创建WBS、范围确认和范围控制五个方面进行了管理。

一、制定范围管理计划

范围管理计划，是项目管理计划的重要组成部分，防止项目在实施过程中出现范围定义不清、范围蔓延，影响项目的完成。在正式制定计划之前，我查阅了项目章程及初步范围说明书，查找了公司的组织过程资产，根据项目特点再结合以往的项目经验制定出了一份初步计划，随后召集所有项目干系人对计划进行修改和完善，最终完成了一份详细的、科学的范围管理计划。

二、范围定义

一个成功的项目，应该需要在项目前期定义一个明确的项目范围以及详细描述，形成项目详细的范围说明书。在项目的早期阶段我带领项目团队，进驻客户现场进行研讨，查看了先前的信息化集成用户说明，现场观摩指挥平台操作，然后召集了项目干系人进行业务交流收集意见需求。我用原型法将收集到的信息做成项目DEMO，以PPT形式演示系统升级后实现的功能，形成需求文件。做好文件后召集项目主要干系人对系统功能做评价，并根据客户要求不断改进系统功能，最终形成了双方认可的完整的项目范围说明书。

三、创建WBS

我根据项目的特点，利用公司整理出的WBS模板，召集公司相关领域专家和项目干系人召开会，最终决定把项目的可交付物作为WBS分解的第一层内容，形成一个树形 WBS。按照项目功能划分工作组，参照8/80小时原则，以一个较粗的粒度进行项目控制，实现无遗漏且相同层次的工作单元应有可比性且无交叉从属。有的功能实现需其它功能完成后方能实现，则需要采用滚动波式计划的方法。例如：地上指挥所、地下指挥所和机动指挥车互联互通需在综合布线、显示单元高清改造、视频信号数字化网络管理等工作完成后方能开展综合调试，所以我们将软件安装、调试作为近期完成的工作，综合测试作为远期工作。最后项目的范围说明书、WBS和WBS字典经双方确认后装订成册并形成范围基线。

四、范围确认

范围确认是一种阶段性的`验收，但又是件很困难的事。我们希望客户能尽快确认以便开展后续工作，而客户则认为什么都没看到无法确认。对此，我通过两方面沟通解决这个问题。一方面，我通过和客户方主任多次解释，虽然项目范围确认是正式的，但并不意味着项目范围一成不变，只要走标准的变更流程且审批通过，均可以变更。另一方面，我要求项目团队重点对客户的潜在操作人员多进行沟通，认真进行操作培训，详细介绍项目的实现，用他们去影响客户对项目的认知。这样消除了客户的顾虑，高效地完成项目确认。

五、范围控制

范围控制就是监控项目范围状态，管理范围基线变更的过程。因此在项目中，我定期组织召开项目状态评审会审查项目的范围，通过和范围基线的对比找出偏差。例如：在一次状态审查会上，我发现项目的某个功能模块中，实施小组正在添加一项视频信号定时轮巡的功能，但是这个在合同里根本没有，我又查了项目的系统变更日志，也未找到又类似的变更记录，于是我参照责任分配矩阵，找到相关实施人员询问原因，得知此功能是客户临时直接跟我们的程序员提出的要求，没有经过变更，不符合规定流程，于是我找到了甲方说明情况，经过商议决定将此需求作为补充走变更流程。事后我专门开会强调了范围基准，以及变更流程的重要性。

篇3：系统集成项目范围管理

项目的范围管理是指为了成功完成项目, 对项目范围的控制过程, 主要包含:范围规划、范围定义、制作工作分解结构、范围核实及范围控制。由此可见管理好项目范围对于项目管理是至关重要的一环。

二、电信渠道营销管理系统的范围管理

电信渠道营销系统作为推动电信运营企业发展的项目 (以下简称本项目) , 其项目范围管理对于渠道的建设, 尤其是对于运营商的发展起着至关重要的作用。

2.1本项目的启动

2.1.1本项目提出的动因

1.市场营销发展方向的转变。随着各大运营商的重组, 单个客户使用两家甚至多家运营商的产品的情况成了普遍现象。运营商希望通过业务打包销售、加大优惠力度等形式, 加速自己业务的渗透, 对各个运营商的存量市场分配格局都会造成重大影响。由于运营商的综合服务能力不断增强, 新型通信技术不断推广, 实际使用资费不断降低, 使客户采用单运营商全业务产品的格局日益形成。这就要求运营商必须依靠行之有效的营销方式及细分的渠道去进行市场拓展, 发展市场, 创造市场。

2.企业战略发展的需要。随着市场竞争的加剧、客户需求的细分以及以客户为中心的服务理念的建立, 电信企业发展战略已经从直销开始向直销为主渠道为辅的方向发展, 渠道的营销收入也在以每年7%-10%的速度增长。如何管理好渠道成为电信运营商的重要课题。

3.消费群体需求的改变。随着社会总体消费能力逐步增强, 信息需求的快速发展, 通信消费需求趋于多层次、多样化, 社会文化环境的变化, 引导用户对通信业务个性化、一体化的需求更为迫切。电信业务需求已经从“语音时期”转变为“综合数字服务时代”, 用户需求发生了根本的变化。

4.渠道管理的需要。目前我国电信企业渠道模式采用的是多渠道的运作模式, 不可避免存在渠道冲突, 主要表现在:渠道之间争夺相同客户。

2.1.2项目启动的结果

2.2项目的范围计划

2.2.1制定项目范围计划的工具与方法

1.业务分析。项目在启动前期进行了细致需求调研, 结合目前市场营销的状况及渠道管理现状, 对该项目大致实现的功能进行了归类总结。

2.项目方案选择。项目组成员根据实际业务需求, 就项目的功能要求及使用方式进行讨论, 形成初步需求交由软件开发厂家进行可行性分析, 形成业务需求规范书初稿。

3.专家评审。由项目组成员及软件开发厂家采取会议讨论分析方式, 共同对业务需求规范书初稿中提出的项目范围内容进行评估, 进而最终确定项目可实现的功能成果, 制定《业务需求规范书》。

2.2.2项目范围计划制定的结果

根据项目组及软件开发厂家最终讨论的结果, 制定《业务需求规范书》明确了该项目的主要交付功能和实现的目标。

2.3本项目的范围定义

2.3.1工作分解结构 (WBS)

范围定义活动的主要目的是详细而准确的界定项目的范围结构, 主要工作成果就是制定项目的工作分解结构, 根据对本项目的范围分析, 采用自上而下的方法, 根据项目的功能分解制定了工作分解结构, 具体步骤如下:

1.根据《业务需求规范书》的内容对项目的大致工作进行讨论;2.根据讨论的结果, 确定项目的工作分解结构采用自上而下的方法进行逐级分解, 在分解的过程中对需求规范书中的不明确或者新增的需求进行完善;3.项目经理根据讨论的结果按照项目的功能进行逐项分解, 并将每个子项目落实到具体负责人;4.对各任务进行历时估算、安排进度、分配负责人员, 制作项目进度表;5.描绘工作分解结构 (WBS) 层次结构表。

2.3.2范围定义的结果

1.工作分解结构 (WBS) 层次结构表形成工作分解结构文档;2.根据工作分解结构更新《业务需求规范书》。

2.4本项目的范围变更控制

2.4.1项目范围变更控制的工具与方法

项目范围变更的基本流程:1) 获取需求变更。提出变更的人员详细填写相关需求变更书, 并提交给项目组的变更控制成员。2) 需求变更评估。变更控制成员应详细了解变更需求并进行分析, 做出变更与否决定, 以书面形式告知申请人。3) 实施需求变更。对于同意变更的需求, 变更控制成员通知开发人员按小组决定进行相关内容的变更。4) 需求变更的跟踪。变更控制成员定期对变更需求的实施进行跟踪并将结果反馈给申请人。5) 需求变更登记。对于提出的书面需求变更申请, 变更控制成员都要记录该变更申请的资料, 以便为项目变更的后评估提供参考依据。

2.4.2项目范围变更控制的结果

1.范围变更文档。根据以上范围变更控制的流程形成相关的变更控制文件, 例如:《需求变更意向书》、《需求变更确认表》、《需求变更登记表》等等;2.根据变更内容对《业务需求规范书》进行修订。

三、结束语

本文通过对电信渠道营销管理系统项目范围管理在项目中的应用进行了初步研究分析, 阐述了项目范围管理对项目建设起到的积极作用, 探索项目中范围管理的成功模式, 希望为今后其它项目的开展起到一定的借鉴作用。H

参考文献

[1]项目管理协会.项目管理知识体系指南[M].3版.电子工业出版社, 2007.

篇4：IT项目范围管理和风险管理研究

关键词：IT项目；范围管理；风险管理

一、前言

近年来，我国在积极进行IT项目开发的过程中，需要面对更多的风险因素，这些风险一旦发生，将导致项目成本增加、进度减缓同时项目质量严重降低。在这种情况下，积极提升IT项目范围管理和风险管理，对于我国IT项目未来的发展具有重要意义。本文首先对IT项目范围管理进行了简要介绍，并对系统工程方法在 IT 项目范围管理中的应用进行了详细分析，同时在对 IT 项目风险管理以及FMEA进行介绍的基础上对基于 FMEA 的项目风险管理流程展开了分析，希望对提升我国IT项目质量奠定良好的基础。

二、IT项目范围管理

（一）IT项目范围管理概述

近年来，我国在积极进行经济建设的过程中，IT产业的影响力不容忽视，然而我国在开发IT项目的过程中还存在很多缺陷。具有效数据显示，现阶段我国在开发IT项目的过程中，70%以上的项目不会在预定的期限内完成开发工作，而90%的项目拥有高出预算较高的成本。在总结造成IT项目失败因素的过程中可以发现，频繁的IT项目功能要求变化以及不断扩大的IT项目规模是影响IT项目质量的两大关键。这一现象导致IT项目的范围无法得到有效的确定，同时在开发过程中将会面对更大的风险[1]。在规模不断扩大以及功能需求变化不定的背景下，IT项目范围变更频繁，IT项目范围管理重要性凸现出来。

（二）系统工程方法

以下五个步骤能够对系统工程法进行有效解释：1、分析产品需求。这一环节不具备独立性，应同产品功能的分析进行紧密的结合，从而逐渐完善产品的设计以及功能；2、分析产品功能。在一个完整的系统当中，包含多个组件、子系统以及零部件，在进行产品功能分析的过程中，应对这些子系统以及组件等的功能进行充分的分析，并在此基础上进行有效的整合，从而构建整体功能。在对以上两个环节进行充分利用的基础上，可以形成完整的产品设计规范；3、设计综合。这一环节需要同产品功能分析进行紧密的结合，通过对产品各个环节功能的掌握，对子系统以及零部件展开精心的设计，并构成完整的产品；4、验证和确认。通常情况下，在以上三个环节以后，就可以构建出一个满足使用者需求的产品，然而产品系统中通常存在微小瑕疵，如噪声以及振动等，这些因素将严重限制系统的输出。因此应及时对产品的质量以及设计进行重新的验证，对产品功能进行完善；5、分析与控制系统。这一环节是对第四环节的辅助，通常情况下包含因果图分析法、层次分析法等工具[2]。

（三）系统工程方法在 IT 项目范围管理中的应用

系统工程方法在 IT 项目范围管理中的应用通过以下环节实现：1、项目范围规划建立在项目章程基础上，构建范围管理计划，为IT 项目开发人员提供核实、记载以及控制等多项工作的范围；2、在范围规划基础上定义范围，主要以说明书的形式进行范围说明；3、对IT 项目分解结构进行制作，也就是对WBS或WBS分解进行制作。WBS及其词汇表是分解过程中的重要成果。该环节可以对上一环节产生的说明书进行变更[3]。值得注意的是，这一过程中如果相关工作没有产生于WBS当中，项目开发人员应进行忽略。从而实现项目范围的可控性；4、对项目范围进行核实，这一过程中建立在项目范围基准以及可交付成果基础上；5、控制项目范围变更。在以上环节基础上，IT 项目开发过程中需要进行一定程度的范围变更，加强对这些变更的控制，并对工作内容进行详细的划分，这一过程中不可以存在任何遗漏环节，才能够提升整个项目的功能[3]。

三、IT 项目的风险管理

（一）IT项目风险管理概述

近年来，信息技术不断进步的过程中，IT项目的结构越来越复杂，这一过程中项目开发需要耗费更高的成本，并需要面对更高的技术难度挑战。与此同时，现代社会市场经济运行的过程中，市场环境不断发展变化，导致IT项目开发过程中，需要面对更加复杂的环境，因此更多的风险存在于IT项目性能、费用以及进度等多个方面[4]。在这种情况下，要想提升IT项目的质量，积极加强项目开发过程中的风险管理效率至关重要。

（二）FMEA 简介

辅助工具是系统化工程设计中的重要因素之一，上世纪美国最早应用的复杂工具为效应分析和失效模式，通过两种工具系统能够实现产品功能以及可靠性的提升。效应分析和失效模式共同构建了FMEA可靠性分析工具。在对FMEA 进行应用的过程中，能够全面而系统的分析各种可能发生的风险，相关工作人员可以通过采取有效措施及时的对这些风险进行消除，促使产品功能以及质量得以提升，并减少产品的后期修复成本[5]。现阶段，在对FMEA 进行应用的过程中，如果能够将其融入到项目启动阶段，能够极大的提升FMEA 的防御性功能，在有效判断各个风险严重性的基础上，工作人员可以对改进措施的先后顺序进行确定，从而有效的对项目风险进行控制和管理，在提升项目开发过程中规避风险能力的过程中，能够提升产品质量降低开发成本。

（三）基于 FMEA 的项目风险管理流程

基于 FMEA 的项目风险管理流程如下：首先，构建专门负责FMEA工作的团队。这是基础性环节，团队组建过程中，由项目经理负责从各个部门工作人员中进行挑选。值得注意的是，在应用FMEA的过程中，具有动态性特点，因此该团队也应当具有动态性特点，应能够根据工程需要对构成人员进行随时调整。其次，对项目范围进行确定，在分解项目WBS的过程中，对项目管理工具进行应用。再次，对风险识别结果进行充分的分析，并对每一个风险将造成的结果以及严重程度进行科学的判断，这一过程中，分级方法是罪常用的风险描述方法。第四，在了解风险发生可能导致的严重后果、风险发生的拼读和可探测度进行充分了解的基础上，可以通过相关计算公式掌握实现风险数：实现风险数=严重度×频度×可探测度[6]。最后，在采取有效措施对相关措施进行完善以后，还应当对以上公式中的相关系数进行重新计算和分析，不断重复这一工作，指导得到最低风险数为止。

四、结论

综上所述，近年来，信息技术以日新月异的速度飞快发展，IT项目的重要性逐渐凸现出来，我国在积极进行IT项目开发的过程中，必须具备较高的风险意识，在有效构建范围管理以及风险管理方法的基础上，采取有效措施提升IT项目质量。（作者单位：联通系统集成有限公司）

参考文献：

[1] 成奋华，金敏.基于敏捷过程的IT项目范围管理的研究与应用[J].计算机技术与发展，2014，10：232-236.

[2] 夏胜权.基于综合集成研讨厅的工程项目集成风险管理研究[J].科技信息，2015，25：434-435.

[3] 吕荣胜，王建，陈磊.基于模糊评价的EPC风险管理研究——以天津伟力公司天纺节电项目为例[J].云南财经大学学报，2014，02：153-160.

[4] 黄山，宗其俊，吴小节.从全面风险管理角度构建企业的项目管理体系[J].项目管理技术，2013，04：67-72.

[5] 乌云娜.工程建设全过程项目管理策划 第十讲 项目风险及项目风险管理[J].中国工程咨询，2015，10：54-57.

篇5：项目范围管理

编制范围管理计划：

输入：项目章程；初步的范围说明书；项目管理计划，组织过程资产，环境和组织因素 输出：项目范围管理计划

工具：专家判断，模版表格和标准

范围定义：

输入：项目章程；初步的范围说明书；项目管理计划；组织过程资产；批准的变更请求 输出：详细的范围说明书；变更请求；更新得项目文档

工具：产品分析；识别多个可选方案；项目干系人分析；专家判断

创建WBS：

输入：详细的范围说明书；项目范围管理计划；批准的变更请求；组织过程资产 输出：WBS和WBS字典；范为基准；更新的项目管理计划；更新的项目范围说明书；变更请求

工具：WBS模版；分解技术；WBS工作包的格式；波式滚动计划

范围确认：

输入：项目管理范围管理计划；项目范围说明书；WBS和WBS字典；可交付物

输出：可接受得项目可交付物和工作或（已确认的范围）；变更请求；更新的WBS和WBS字典；推荐的纠正措施

工具：检查（审查，审计，产品评审，走查）

范围控制：

输入：项目范围管理计划；项目范围说明书；WBS和WBS字典；工作绩效数据；绩效报告；已批准的变更请求

输出：新的变更请求；建议的纠正措施；更新得（WBS和WBS字典，项目管理计划，范围说明书，范围基准，组织过程资产)；工作绩效

篇6：系统集成项目范围管理

营改增系统改造项目

需求范围说明书

奇瑞汽车金融股份有限公司

二〇一六年三月

1/ 19

项目要求 第一节 概述

根据国家税务总局的安排，银行业将实施“营改增”，即银行由缴营业税改缴增值税，同时为客户提供增值税税票。为配合“营改增”改革后各类应税和税务管理信息化需求，满足财政部、国税总局颁布的各类监管要求，启动营改增系统改造建设和现有系统改造。

第二节 系统方案与技术方面要求

1.1.总体目标

1.2.技术要求

技术方案需充分考虑到先进性要求，体现在以下方面但不限于以下方面：

1、开标供应商提供的功能应满足我司业务开展的要求；

2、开标供应商所提供的系统软件应符合业界相关技术标准；

3、提供系统完整的源代码，提供开发平台，至少满足我司二次开发的要求。

4、通过我司会计核算平台及核心、总账对接的方案，5、提供完整的营改增系统改造功能应用，基于营改增要求，完成我司现有系统改造功能；

6、系统支持跨平台部署等；

7、系统应充分考虑我司数据标准化的要求，能够支撑标准化和监管统计需求；

2/ 19

8、系统应采用平台化设计，支持功能性拓展；

9、系统扩充方便，设置修改灵活，操作维护简单，能够适应业务的快速变化及发展；

10、系统提供的软件产品在业务扩展、应用工具、数据库、操作系统等方面具有开放性，做到标准化、通用化；

11、系统安全、可靠，供用户进行有效的维护与使用,系统运行维护要求自动化、参数化和交易化;

12、系统严格按照软件工程要求提供详细的各类文档；

13、能够满足我司现有的开发规范，保证代码的可读性和统一性；

14、操作系统、数据库和中间件的配置符合我司技术架构要求，ip地址与目录等参数配置信息不得写在程序中；

15、基础软件，包括操作系统、数据库、中间件必须符合我司基础软件规范；

16、不允许使用RSA1024及以下强度的加密算法，建议使用国密算法；

17、在设计技术架构时需要充分利用我司现有的软硬件环境，充分考虑我司现有的软硬件环境，保证兼容性，保护我司现有投资；

18、满足我司应用架构的管理要求，充分考虑与其他系统之间的关联性。

19、系统支持负载均衡部署方式，性能不足时可以通过增加设

3/ 19

备线性扩展处理能力。

20、产品必须是行业主流产品，符合业界相关技术标准，在国内外有成功的技术实施案例，满足监管需求；

21、产品必须有后续研发系列，并有良好的发展前景；

22、可与主流厂商软件集成而不影响系统性能；

23、与系统连接的整体配置无单点故障，所有部件采用冗余设计，确保无任何单点故障，并能满足未来7×24小时的应用服务。

24、支持在线维护、更换、升级硬件部件和微码；

25、提供后续开发支持，对于人员成本单独报价。

1.3.系统技术设计原则

1、实用性和适用性

充分利用成熟的先进技术，采用性能/价格比比较高的产品。应用系统设计必须符合实际，适用于银行信息系统建设。

2、完整性

所设计需满足增值税管理所有要求，设计范围包括营改增系统改造和现有系统改造。

3、开放性、兼容性和连通性

所设计的系统在结构上真正实现开放，各种设计规范、技术指标及产品均符合国际和工业标准，包括各种广域网、局域网、计算机及数据库协议，并可提供多厂家产品的支持能力，从而为未来的业务发展奠定基础。系统中所采用的所有产品都要满足相关的国际标准和国家标准，是开放的可兼容系统，能与不同厂牌的产品兼容，4/ 19

可以有效保护投资。系统具备与各种协议计算机通行网络互连互通的特性，确保综合网公用基础设施功能充分发挥。

3、先进性

系统技术水平要保证先进性，符合当代信息技术发展形势，代表当前计算机科学的发展方向。所选择的各平台供应商应有能力对该项进行持续开发，可以保证该项技术不断地更新并可顺利升级而维持系统的先进性。提供良好的技术支持和技术服务，以满足当前的业务需求，使业务或生产系统具有较强的运作能力。

4、高可靠性和可用性

通过提供给用户高可靠的产品（硬件、软件、服务），带有系统容错性的方案(冗余、备份)，较强的管理机制和控制手段，具备事故监控和网络安全保密等技术措施，保证系统的安全可靠和高可用性。

系统建设尽量用主流产品，以保证系统的高质量和稳定性。系统应最大限度集成世界上最稳定且优秀的技术及组件，采用成熟技术以降低系统的不稳定性。对系统如硬件、操作系统、网络、数据库应设计尽可能详尽的故障处理方案，以保证系统的快速恢复。

5、灵活性和可扩充性

所设计的系统应具有良好的扩充性，能够根据管理要求，方便扩展网络覆盖范围、网络容量和网络各层节点的功能，以适应今后可能出现的较大任务符合。硬件平台具有可升级性，当需要时可以通过新的计算机设备同原有计算机设备一起工作以提高系统的5/ 19

处理能力，而保护原有的投资。在源系统改造或者前端应用的需求发生变化时，整个系统的架构和设计方法可以适应这种变化，不会对已有的平台造成影响。

6、易维护性

在系统总体设计上注意系统的维护性。尽量采用大家熟悉的易于维护系统平台。系统软件安装简单、易于操作。

7、标准化

应用软件开发符合软件开发标准的要求，方便维护和扩展。业务处理符合国家法律、法规和有关政策规定。

1.4.功能要求

系统需满足（但不限于）奇瑞汽车金融营改增系统改造系统的以下全部需求：

基于我司IT架构优化，设计现有系统改造功能，包括： 交易认定、价税分离； 会计核算； 客户信息管理； 发票回传。

需要建立统一 “营改增系统改造”实现各类应税和税务管理信息化的目标，包括以下几个功能：

实现“增值税票”的管理、打印等功能 搭建统一的税务管理平台

6/ 19

满足对外披露需求

基础功能 1 价税分离模块

1.1 价税分离原始数据导入

通过系统自动接口（手工导入作为辅助方式）方式，将涉及价税分离的各类交易数据导入营改增外挂管理平台，并支持导入数据验证校验、版本控制、导入日志记录等功能。

1.2 价税分离交易认定规则设置

提供增值税相关各类交易（包括常规贷款交易及特殊交易，如：经销商服务费摊销、贴息摊销、逾期利息转表外、期末补提利息、期初冲回等）认定规则和计税方法配置功能，形成交易明细与价税分离规则映射关系。

1.3 税率设置

提供增值税所属税目及税率信息维护功能，根据交易代码设置的税率，并作为价税分离计算参数。

1.4 价税分离计算

根据价税分离交易认定规则、税率和交易明细数据，进行价税分离计算。

1.5 会计分录生成

支持根据价税分离计算结果和银行会计科目及分录规则，自动生

7/ 19

成增值税调整及相关分录。2 销项发票管理模块

2.1空白发票管理

支持集中维护银行购买的空白发票功能，并提供总行对空白增值税专票的统一管控功能。包括请领入库，将购买的空白专票维护到营改增外挂平台中，每笔开票记录应与实物专票一一对应；专票分发，由总行或地市分行统一管理下辖所有机构空白发票的请领入库，并分发至各机构，系统上对空白发票的请领和分发进行统一管理（目前没有分支机构，但是该功能需保留）。

2.2发票盘点

支持对空白发票进行盘点，保证总分行发票打印的准确性及发票库存的准确性。其中各打印终端可按日盘点打印成功及待打印发票信息，按月盘点发票库存情况。支持生成盘点报表，并经复核人复核。

2.3发票打印

能够与金税系统开票请求接口集成，执行增值税专票打印工作。打印时，对客户资质、是否已开具发票等自动校验，防止错开或重复开票。同时，支持同一交易对手增值税发票打印的合并与拆分，拆分方式可选择平均拆分或自定义拆分。

2.4例外处理

对增值税打印过程中遇到系统异常等意外情况进行记录，并支持对例外事件后续跟进处理。例如，打印未成功需重打，但已经从待打印池中已找不到该笔发票信息；需要冲红已打印的发票再重打；打印

8/ 19

冲红发票等情况。

2.5手工开票

对于需手工开票的业务收入，若属于系统内中间业务收入，由专票打印员通过模糊查询，向交易数据的接口提交数据请求，交易系统返回交易信息和客户信息给营改增外挂管理平台，选择需要打印的任务，提交审批完成后发起打印请求；若属于系统外相关业务收入，由专票打印员手工录入专票信息，提交审批完成后发起打印请求。

2.6发票追溯

提供增值税发票的追溯功能，支持对发票各个节点操作的记录、时间、操作人进行追溯。

2.7发票遗失管理

对遗失的增值税专用发票进行登记记录，并将信息传给金税系统进行挂失处理。

2.8发票作废

当发生空白专票或已开专票作废情况时（如尚未使用的纸质专票损毁），支持相应专票作废处理流程，并进行详细记录。

2.9红字发票管理

支持红字发票开具、申请和审批流程管理功能，并进行详细记录。2.10电子税票管理

待电子发票在行业内推行之后，支持电子发票的开具与管理，并与税务局电子发票系统对接，实现发票数据的传输。3 进项发票管理模块

9/ 19

3.1认证 扫描认证

登记银行收到的各类增值税发票，记录各类进项税票银行内部审批结果，支持进项发票审批状态查询。通过金税系统扫描登记进项专票信息，提交给税务专员审核。

电子认证

对于取得的专票，能够实现与税务局电子发票系统对接，进行电子认证。

3.2进项转出

支持对涉及进项转出的数据信息录入平台，并按照预设逻辑对进项发票进行进项转出操作，并提供汇总功能。

3.3预警提示

对进项发票的认证状态进行跟踪，对于接近认证期限仍未进行认证的发票设置自动预警提示。

3.4抵扣认证

支持通过审批的进项专票上传至税务局网站进行认证，可即时联机认证或统一批量认证，认证通过后将认证信息回传至财务管理系统进行进项科目的调整。

3.5未通过认证管理

对于未通过认证发票，显示原因并记录后续跟进和处理流程。4 税务管理

4.1纳税申报管理

10/ 19

支持增值税纳税申报数据采集、计算和人工调整功能，生成纳税申报报表和相应会计分录。

4.2税务管理统计查询

支持多维度、跨组织的税务管理数据、增值税计算明细、发票信息综合查询功能，并提供税务数据分析和风险监控功能。

4.3税会差异分析

针对增值税会计口径数据、税务申报口径以及开票口径进行自动差异分析，形成税会差异分析报表。5 系统基础管理

5.1纳税主体管理

提供纳税主体基本信息维护功能。5.2用户权限和日志管理

提供基于角色授权的用户权限管理体系和详细的系统操作日志记录机制，保障系统数据信息安全。

5.3系统接口管理

提供包括金税系统、数据仓库、财务系统、业务系统等与平台相连接的数据接口管理和维护功能，接口应为开放式，对于新增业务能够及时维护，并导入数据。

5.4工作流设置

支持系统内部各类管理流程的审批工作流配置与维护。5.5 数据备份还原管理

支持平台中各类数据、信息的备份和还原功能，确保业务连续性。

11/ 19

电子发票管理

6.1电子发票数据生成

支持按预先设置的开票规则填开发票，提交税务机关后台系统生成电子发票数据，并自动分配电子发票号码同时对开票信息加密，生成防伪码和二维码，最终生成完整的电子发票。

6.2电子发票作废

当发生开票错误等情况时支持电子发票的作废处理，并进行详细记录。

6.3电子发票红冲管理

支持电子红字发票开具、申请和审批流程管理功能，并进行详细记录。

6.4电子发票查询和统计

支持在系统中查询和统计已开/未开电子发票以及已收进项电子发票的开票项目、开票金额等信息。

6.5进项电子发票认证抵扣

支持系统录入获得的进项电子发票信息，将通过审核的进项电子发票上传至税务局网站进行认证，可即时联机认证或统一批量认证，认证通过后将认证信息回传至财务管理系统进行进项科目的调整。

6.6电子发票预警

支持对电子发票开具过程中异常情况的预警，包括作废过多、红冲过多、申报异常等。营改增系统改造其他业务要求

12/ 19

7.1实现财管系统、会计核算平台、数据集市及其他相关系统的对接，与其他系统交互通过DS或文件分发平台。

1.5其他要求

一、系统测试

系统测试是项目质量的重要保证，开标供应商必须配备专业的测试人员，组建专业的测试团队，制定完善的测试方案。测试方案包括功能测试和非功能测试。

1.功能测试方案应包括如下测试内容： －测试目标 －测试范围

－参加测试人员及组织分工。－测试过程中的缺陷管理。－测试完成标准

－测试工具：测试用例管理工具、缺陷管理工具、性能测试工具、配置管理工具等。－测试数据。－测试实施计划。-测试风险分析。－测试交付物。

－测试的审核和结果认定方法。2.非功能测试方案应包括如下测试内容： －测试目的

13/ 19

－测试范围 －测试启停准则

－模型：业务模型、测试模型 －测试指标 －测试策略 －测试内容

－测试实施准备：环境准备、工具准备、数据准备、脚本准备 －测试组织结构 －测试实施计划 －测试风险分析 －测试交付物

－测试的审核和结果认定方法。

二、项目验收

验收是在项目完成开发并成功试运行的基础上进行的。试运行期不能少于两个月。测试验收由采购人组织，对应用软件进行测试验收，合格后出具合格证明。如试运行期间统计或测试数据表明系统在功能、性能指标或可靠性方面不符合要求，开标供应商有责任及时解决，应根据问题严重程度和解决时间，顺延或重新开始试运行。

成交供应商必须为每一项的测试编写测试手册。验收测试手册的内容包括：测试目的、测试环境和测试所需的设备、测试过程的描述、测试结果及分析、具体的安装、测试和验收要求以最终合同

14/ 19

签订为准。

验收需要开标供应商提交的文档至少包括：系统建设的详细工程日志、系统的需求说明书、系统的概要设计、详细设计说明书、系统的数据库设计说明书、系统的使用说明书、系统的操作说明书、系统的测试大纲、系统的测试报告。

验收需要开标供应商提交的全部源程序，提供开发工具、自有产品及开发平台，以及相应的书面说明等，并保证其合法性，由此产生的所有争议和法律问题由开标供应商负责，由此产生的全部费用由开标供应商负责。

如试运行期间统计或测试数据表明符合要求，将通过延伸，在双方签署验证证书后进入保修期。

三、技术支持及售后服务

开标供应商在邀标文件中必须书面声明充分了解并接受奇瑞汽车金融股份有限公司的技术支持及售后服务条款，即：

1、在跟踪维护期内，乙方每年必须为甲方提供2次应用系统检测和评估，并提供检测和评估报告，侦测应用系统中可能会出现的问题，以协助防范可能出现的风险；

2、在跟踪维护期内，乙方保证按照本合同约定的服务内容、服务方式和服务质量向甲方提供合格的服务，乙方保证服务质量符合甲方要求，并通过甲方验收；

3、在跟踪维护期内，乙方保证提供服务的技术人员的数量和素质满足履行本合同的要求；保证人员的稳定性，未经甲方同意不

15/ 19

得随意更换；如果甲方要求更换服务人员的，乙方应根据甲方的要求更换；

4、对于重大系统的上线、年度决算等重要时点，乙方将提供现场的技术支持服务，以协助系统的顺利运行。

5、乙方提供7x24x365的故障应急反应机制。甲方系统一旦出现重大故障，则马上启动故障应急反应程序，提供远程技术支持，并承诺采用最快的交通工具赶到现场，提供现场的技术支持和技术保障，以协助生产和运行的顺利进行。到达现场后，乙方将协助客户进行故障诊断和排除。如故障发生的原因是由乙方提供的产品或服务引起的，则乙方会调集技术人员以尽早修复，并提出书面故障分析报告；如确认故障发生的原因是由第三方提供的产品或服务引起的，则乙方向客户提供书面故障诊断分析报告，在提供书面故障诊断分析报告之前，乙方将口头报告故障原因，并协助客户与该第三方交涉，配合第三方排除故障。

6、在跟踪维护期内，乙方为甲方提供甲方工作时间的远程技术电话支持。乙方在接到甲方通过电话或电子邮件方式提出的服务请求后，应在2小时之内给予响应。如有软件故障不能通过电话解决，乙方应在24小时内提供现场技术支持。

7、服务完成后，乙方应将完整的、与所提供服务有关的技术资料，包括但不限于：系统维护纪录、系统变更记录、完整的源程序代码等装订成册提交给甲方系统管理部门；

8、乙方应提供必要的技术指导和不少于5人天的封闭式技术

16/ 19

业务培训，保证甲方能正确、安全、有效地使用及维护系统。

9、根据甲方要求对修正系统差错、改进系统性能、增加系统功能；

10、乙方保证派出人员遵守甲方有关制度、工作纪律和安全规定，乙方服务人员应在甲方规定的工作场地范围内工作。

11、在跟踪维护期内，由于乙方软件产品质量产生的问题，乙方免费提供维护。

四、项目实施

1、项目管理

开标供应商应按照项目管理的要求向我司提供开发计划、时间进度。

开标供应商应明确提出参与本项目的工作人员构成、职责、学历背景、从业背景及参与本职工作的时间。开标供应商应确保在项目实施过程中不变更奇瑞汽车金融认可的项目经理。

在技术需求应答书中，开标供应商应明确其分担职责，进行清晰的工作任务描述。

开标供应商应向买方明确提出详细的质量控制、风险控制措施，确保项目的顺利进行。

2、项目人员

a、项目经理、咨询人员

项目经理、咨询人员必须有2（含）家以上相关银行营改增系统改造完整项目实施、咨询经验。

17/ 19

b、开发人员以及测试人员

开发、测试人员必须有2年以上的开发、测试工作经验，在通过我司相关考试、审核后方能进入项目组开始项目的开发、测试工作，开发、测试人员不允许复用。

以上项目经理、咨询、开发、测试人员，中选方在驻场实施前必须提供相应的工作、学习简历，供采购方进行审核，如采购方不予认可，成交供应商必须按照采购方的要求更换人员。在项目实施阶段，如采购方认为项目经理及实施人员达不到相应要求，采购方有权要求成交供应商更换符合要求的人员，成交供应商不得以任何形式、理由进行拒绝。另，成交供应商需承诺保证实施过程中研发团队的稳定性。

3、进度

项目应在2016年5月1日前完成（包括应急方案）。

4、技术业务支撑

参与我司项目各阶段（系统调研、硬件采购、需求分析、系统设计、系统联调测试、培训、系统上线）的工作。

第三节 售后服务

开标供应商对售后服务及系统维护、数据整理和维护工作的技术责任应作明确说明，包括质保期限承诺、服务响应承诺、系统应急方案、技术支持和相应软件的升级承诺。

一、中选供应商承诺提供一年免费原厂维护。

二、在保修期内，如果软件设计厂家对用户购买的软件有了升级

18/ 19

版本，成交供应商应及时通知用户。如果用户有要求，成交供应商应向用户免费提供相同功能的相同软件升级和技术支持。成交供应商有责任在保修期内提供以下形式的技术支持服务：

详见第二节1.5项”技术支持及售后服务”部分。