综合上述三点，信息部门应该能在业务和技术两者之间权衡一个平衡点，因此在判断项目范围的环节上能站在一个比较中立的立场上给出客观的判断。

　　三、项目范围控制要素分析：

　　1.项目范围定义的依据

　　1.1关键业务需求

　　企业在定义其项目实施范围时，要注意紧紧围绕着企业的战略目标以及核心业务，以内部价值链为主线，而非全部业务，一应俱全。实施信息系统的目的是提高企业的竞争力和内部管理效率，因此我们要定位在能够为企业的效益和效率产生最大价值的方面，而不是涵盖企业的全部业务。要避免出现主次不分，胡子眉毛一把抓的现象。

　　2.项目范围控制要素

　　一般来说，在启动项目初期，业主就应该提出一个比较稳定的项目范围，为项目的实施提供一个牢固的前提和框架，同时也是为后期的项目管理划出一个明晰的“圈”，所有项目活动的开展，包括项目成本、质量和时间的控制也应该在此范围内进行。但是，在实际的操作过程中，这个“圈”的边界有可能会出现模糊、扩大的现象，甚至这些扩大和模糊的部分给项目带来风险。

　　2.1内部价值链

　　我们先看看以下一个企业的内部价值链示例：

　　项目预算——项目拆分及概算分摊——项目合同——订单——采购——库存——材料发放——合同支付——成本归集

　　可以看出价值链中的每个环节构成了企业内部的核心业务，因此，我们在定义项目范围的时候就可以贯穿着这个价值链，把价值链中的每个环节定义成具体的项目需求和范围，并且遵循一个闭环的原则来进行描述，如下述对项目预算范围定义中，从预算编制开始到预算回归分析，接着又进行预算编制，形成一个完整的闭环。

　　通过上述的定义，我们就可以为价值链定义出多个闭环，而每个闭环将构成一个整体的闭环，同时也构成项目范围的边界。

　　2.2内部管理成本

　　业主在实施项目过程中，对超出了原项目范围内定义的需求我们可以用以下的标准来作出判断。

　　2.2.1是否对关键业务构成关键的影响

　　项目实施中，在对业务部门进行详细需求调研的阶段，业务部门不可避免地会提出很多与其业务相关联的业务，或者是一些新的想法，当遇到这种情况的时候，业主方的信息部门要作出一个合适的判断，是否可以包含在项目范围内。

　　首先，这个业务需求是否在关键业务描述中已经涵盖，或者说这个需求是否对关键的业务构成足够的影响力。如果不是，建议可以不纳入项目的范围内，或者暂时不纳入本次的项目范围内，而作为日后一个扩展的功能。

　　其次，如果此需求对关键业务构成必要的影响，那么信息部门应该进一步作以下分析：

　　(1) 目前系统功能是否可以解决这个需求?如果可以，实现难度如何?

　　(2) 如果实现难度不大，可以纳入项目范围。如果实现难度大，那么进行成本分析。

　　2.2.2项目成本分析

　　(1) 内部资源是否足够应付新需求的实现?包括业务部门人员、技术人员、软硬件支撑。

　　(2) 在整体项目计划当中是否允许作这样的调整?能否在项目计划时间内完成?

　　(3) 是否能保证项目的质量?会不会对其他功能造成影响?

　　如果上述成本分析回答都是肯定的，那么就可以把需求纳入实施范围，如果全为否，建议就不把其纳入本项目范围。但是由于该项需求是一个关键业务需求，可以考虑把此项目作为扩展功能在以后实现，目前可以采用其他灵活的方式处理。如果上述的回答中有肯定也有否定的，那么我认为首先要以内部资源的问题作为重点，如果此条件不能满足，即使勉强把其纳入项目范围内也只会造成项目的延迟，还不如干脆等条件满足的情况下再实施，目前先采取其他灵活的方式处理，这样既保证当前项目在原既定范围内完成，新需求在新的项目中实现。如果内部资源条件满足

上一页  [1] [2] [3] 下一页