什么是项目管理?[@more@]什么是项目管理?
在理解什么是项目管理之前，我们首先要弄清楚项目的定义。如果不说理论上的定义，企业中的“项目”说白了就是企业中的各项有始有终的工作或事务。
企中的项目有哪些呢？如果我们把企业的经营活动进行分解，会发现企业中的各种工作基本上都可以归类为一个又一个的项目，大到：IT服务项目、工程建设项目、产品开发项目、投资项目、ERP项目、BPR项目、薪酬改革项目、市场开发项目、房地产开发项目等等，小到：一次搬迁、一次校园招聘会、一次内部培训、一次会议组织、一次新年聚会等等。
项目管理就是在有限的资源约束下运用系统的观点、方法和理论以实现项目的目标的方法。著名的美国的阿波罗登月计划，整个项目大约有40万人和20万家企业参加，耗资200多亿美元，就是项目管理成功应用的杰出典范。
计划、控制、度量——洗尽铅华的项目管理真谛
在乱花渐欲迷人眼的项目管理领域内，项目经理们总是很容易被各种理论说服，被各种模型吸引，被各种模版包围，可是，对一个具体的项目来说，什么才是最重要的呢，需要做些什么才能让项目可控，并且朝着成功的方向走近呢？
去掉繁复的理论体系和证书的包裹，项目管理的目标其实很朴素，手段其实很简单，只是为了让项目成功，做好这样三件事——计划、控制、度量。这是笔者根据多年的项目管理实践，从实用的角度出发，结合多个理论模型总结出来的一点经验和体会，希望能对各位有所启发。
正文
项目管理的理论体系很多，对项目管理的理解也各不相同，各种组织的最佳实践模型更是数不胜数。那么，我们在实际的软件开发过程中该如何选择，如何应用呢？
结合各种PM理论基础和在实际工作中积累的项目管理经验，笔者认为，对于一个具体的项目来说，项目管理的核心问题不是采用哪种理论体系，不是通过哪种认证评估，也不是选择哪个最佳实践模型，而是要做好这样三件事——计划、控制、度量。也就是说，项目启动之前，要有计划；项目进行当中，要有控制；项目结束之后，要有度量。这样才能保证项目有的放矢（依照计划执行）、有据可查（产生管理文档）并且让以后类似的项目在计划阶段有章可循（参考度量的结果）。
下面来看看我们在计划、控制和度量这三件事情上需要做些什么。
1. 计划
项目的计划阶段一般会对项目的可行性进行分析，并提出若干备选方案，然后根据组织的目标、能力和预算，挑选一个最适合的方案来执行。
选定方案之后，要根据项目范围、资源配备和预算等条件，制定出项目的进度计划、人员配置计划、预算计划、风险管理计划，以及项目管理所需的其它QA计划、CM计划、MA计划等辅助计划。
2. 控制
为了保证项目能够按计划顺利完成，在项目执行阶段，我们有很多工作要做。
项目的进度控制、质量控制和成本控制是项目管理中最关键也是最重要的三个方面，此外还有风险的识别和管理，也是影响项目成败的重要因素之一。
项目进度管理需要在每个里程碑或检查点及时检查是否按照计划要求完成了相关的工作内容和需要交付的工作产品，以保证项目进度在控制之中。
质量管理是要确保每个工作阶段的可交付产品符合项目和组织的质量标准，确保最终交付的产品是合格的，可以使用的。
成本管理是为了保证项目不超出组织的预算，对于内部的IT项目而言，员工的工作时间就是项目的主要成本。基本上，保证项目按照计划的进度和人员配置完成，就可以保证成本在可控范围之内。
风险管理主要是应对突发的、不确定的因素对项目造成的影响。需要在计划阶段就制定出风险应对计划，在执行阶段及时发现和识别风险，当风险发生时，采取正确的措施应对，尽量减少负面影响。
3. 度量
在项目执行过程中，除了要对项目的进度、范围、质量进行管理和控制，也要对项目的关键指标（工作量、里程碑、工作产品、人员配置、物理规模等）进行度量，通过各种度量指示器在项目的执行阶段持续的跟踪和记录项目进展情况，及时发现进度、成本和质量上的偏差。
除了跟踪和发现项目偏差之外，度量的更深层次的意义在于为以后的项目提供可参考的历史数据，为组织积累经验，提高组织的计划和估算能力。但是在实际的项目当中，很多项目经理认为，度量对当前项目的意义不大，不愿意花时间去做度量。其实这对组织来说是很不利的，因为如果没有历史数据的积累，即使已经做过了大量的项目，组织仍然无法为项目的规模、成本、人员等的估算和计划制定提供确切的历史数据和估算依据，组织的项目管理将仍然是粗放型的，做不到精细化管理，达不到更高的项目管理水平。
度量的意义重大，但真正知道该怎样做的人并不多，这点我将在今后的文章中专门讲述，并尽量提供详尽的参考模版。
为了更清楚的说明计划、控制和度量在项目管理中的重要作用，下面举一个买鞋的例子来详细说明。
根据项目的定义：“项目是为完成某一独特的产品、服务或任务所做的一次性努力”，某次买鞋的过程具有独特性、一次性和不可重复性的特点，是典型的项目，我们可以称之为“买鞋”项目。
在“买鞋”项目中的计划、控制和度量是怎样的呢？
l 首先是计划。在买鞋之前，我们首先要明确是否一定要购买新鞋，是否有时间去商场，然后提出几个备选的商场，这相当于可行性分析和备选方案；考虑一下自己希望与之搭配的服装，个人的气质特点，本次购买的预算，然后选择一个各方面最适合的商场，这相当于选择合适的项目方案；根据选定的方案，制定出选购活动的时间表、价格标准、鞋子款式、午餐安排等，这相当于制定项目进度计划及相关的辅助计划。
l 然后是控制。对于“买鞋”项目来说，我们要注意鞋子是否符合最初的款式要求，这相当于质量控制；我们还要把价格控制在可以接受的限度之内，这相当于成本控制；我们不想在商场花费过多的时间，因此要控制在每个专柜花费的时间不要过多，这相当于进度控制；及时提醒自己不要买计划外的物品，不要轻易听从专柜小姐的劝说购买价格过高的鞋子，这相当于风险控制。
l 最后是度量。在逛商场的过程中，经常比对一下款式、价格、时间上的计划和实际的偏差，相当于度量的跟踪和记录。把鞋子买回去之后，可以再对最终购买的鞋子的价格、款式、所花费的时间与出发前的计划进行对照和统计，分析一下估算与实际情况的偏差，总结出这次购买行动的成功经验和待改进之处，以便为以后类似的购买行为提供精确的可参考数据。
从以上的分析可以看出，计划、控制、度量这三件事是项目管理的核心和关键之所在，无论我们应用什么样的项目管理方法和模型，做好这三件事，就等于抓住了项目管理的本质，掌握了项目管理的真谛，这时，我们就可以不再为众多的理论体系所制约，可以得心应手的根据项目特点和组织需要来创造性的做好项目管理工作了。也只到有这个时候，我们的项目管理才算是真正学到家了。
项目管理系统（Project System）是ERP的一个集成解决方案，它的目的是帮助企业执行项目管理中的所有任务，因此它包括了在项目所有阶段的各种功能。ERP的项目管理涵盖了两类项目：客户项目和成本投资项目。客户项目是指以销售为目的，根据客户需求执行的项目。这类项目和销售模块有很强的联系和集成。在造船，建筑，工程，服务，军工等各种行业有广泛的应用。成本投资项目是指企业内部各种类型的项目，这些项目的成本在项目完成后或者资本化或者费用化，包括研发项目，投资项目，IT项目，设备维护项目等等。这类项目在各种行业的应用更为广泛。
项目的结构
在正式执行一个项目之前，我们必须明确地定义项目的目标并制定项目所要执行的工作的结构。明确定义的项目结构为成功的项目计划，执行和控制提供了先决条件。图一是ERP中主要的项目结构对象，以及它们之间的相互关系。
项目定义（Project Definition）
项目定义是一个总括的项目描述。项目定义为将来项目计划阶段所要创建的所有项目管理对象提供了一个框架。
工作细分结构（ Work Breakdown Structure）
工作细分结构是以层次结构的形式将完成一个项目所要执行的任务层层细分所形成的项目结构。它提供了关于项目的概览并且构筑了项目的组织结构和协调合作的基础，同时显示了项目在工作，时间和金钱上的花费，可以应用它来计划时间，成本和分配预算。
工作细分结构中的每一项任务被称为WBS元素（WBS Elements）。和别的项目结构对象一样，系统在WBS元素中维护了很多信息。比如有关于组织结构关系的信息：公司代码，业务范围，工厂（物流模块），设备或功能地点（工厂维护模块），利润中心等等。再比如在基础信息中有三个标志：<1>成本计划。如果要对这个WBS元素计划成本，我们必须指明该WBS元素是一个计划元素。<2>成本对象。如果想将实际成本和承诺记录到某个WBS元素，我们必须指明该WBS元素是一个成本对象。如果这个标志没有打开，该项目中其他能够分配成本和承诺的对象（比如内部定单，网络或采购定单）也将不可以分配给该WBS元素。<3>开票。如果想将收入确认到某个WBS元素，我们必须指明该WBS元素是一个开票元素。还有很多信息被分别组织在项目责任，控制数据，凭证，开票计划，结算规则，在建工程，资本投资计划等等视图中。
网络（Network）
和WBS不同，网络描述的是项目执行过程。网络是一种在项目进度安排，成本和资源安排的计划，分析和控制工作中很有用的技术。我们可以将网络分配给项目定义，WBS元素或者销售凭证。
构成网络的关键元素是活动（Activity）和活动之间的关系。活动具有以下特征：它们持续一定的时间；它们有明确的开始和结束；它们执行的过程不被中断（指如果有中断应定义多个分开的活动）；执行他们需要一定的资源；它们引起成本。活动如图一所示可以分配给WBS元素。
图二我们给出了各种类型的活动。ERP项目系统区分三种主要类型的活动：内部处理活动（Internally processed activities），外部处理活动（Externally processed activities）和一般成本活动（General costs activities）。我们甚至可以将活动进一步细分成活动元素（Activity Elements），如图二最右侧的活动。活动元素也可以区分成上述三种类型。
对于内部处理活动，为了计划完成它所牵涉的工作，以及提供成本计算的基础，我们需要明确如下一些问题，比如：执行该活动需完成多少工作；什么产能（如人工或机器）会用来执行这些工作；什么资格（Qualifications）是完成该活动所必须具备的；哪些人员或个别产能是完成该活动所必须提供的等等。因此我们会在内部处理活动中指明工厂，工作中心等组织机构和工作时间等信息。
对于外部处理活动，我们一般需指明负责的采购组织和采购组。在释放网络时，系统可以自动创建采购申请，由采购部门负责完成。或者我们也可以手工触发采购申请创建。我们也可以将采购信息记录记录到外部处理活动中，采购信息记录里维护了供应商，价格条款等信息。
另外我们可以将物料分配给所有的活动，如图2最左侧的活动。在项目执行的过程中，生成采购申请或计划定单，分别由采购部门或生产部门完成。
活动和活动之间在系统中可以维护四种关系：结束-开始（Finish - Start (FS) Relationship），开始-开始（Start - Start (SS) Relationship），结束-结束（Finish - Finish (FF) Relationship）和开始-结束（Start - Finish (SF) Relationship）。
里程碑（Milestones）
里程碑是项目中有特殊重要性或者会触发某些事先定义功能的一类事件。一般来说它们显示了项目各阶段或各部门间的衔接点。在ERP中里程碑可以分配给活动（Activity）和WBS元素。里程碑可以实现四种任务：<1>里程碑趋势分析（Milestone Trend Analysis /MTA）。是一种控制项目进度的简单而有效的工具。在不同报表日期，里程碑日期被用于比较分析，图形化的MTA使我们可以立刻发现项目趋势和任何的延误。<2>使用里程碑技术的实现价值分析（Earned Value Analysis）。里程碑技术是众多计算实现价值技术中的一种。每一个里程碑代表了活动或WBS元素所完成的这部分工作。<3>决定开票计划的日期。将里程碑和开票计划的日期相连。当项目进度到达某个里程碑时，里程碑的实际日期将被自动复制到开票计划中。<4>触发预定义的里程碑功能。我们可以利用里程碑触发一系列事件来处理某些特定的业务流程。
在ERP项目结构的建立中有两种可以增强工作效率的功能：<1>标准项目结构和复制功能。<2>图形功能。
项目的成本控制
ERP通过项目成本的计划和实际比较来达到控制成本的目的。项目成本控制组件和其它相关模块有紧密的集成。这些模块包括管理会计，财务会计，生产计划和控制，物料管理。
成本计划
项目成本计划在项目的不同阶段有不同的作用：在概念定义和粗略计划阶段，成本计划的作用是计算一个项目最初的成本估算；在审批阶段，成本计划是分配预算的基础；在项目执行阶段，我们使用成本计划来控制实际成本和成本差异。 ERP成本计划有如下几种方式：
1． 简便成本计划。简便成本计划的核心是成本模型（Costing Model）。对于成本结构相似且经常重复出现的任务，我们可以定义成本模型。在对WBS元素计划成本时，只要提供相关的数量和参数，就可以计算出成本计划。举例来说，假如我们的项目经常需要埋设管道。但是不同的项目，埋设管道的直径以及沟渠的长宽深各不相同。我们可以设计如下成本模型：
描述 类型 对象 数量 激活 价格
挖掘沟渠的人工成本 成本中心/作业类型 4298/1421 沟渠长度*沟渠宽度*沟渠深度/10
挖掘沟渠的机器成本 成本中心/作业类型 4298/1420 沟渠长度*沟渠宽度*沟渠深度/10
管道 工厂/物料 0001/管道-10 沟渠长度 管道=“10厘米直径”
管道 工厂/物料 0001/管道-20 沟渠长度 管道=“20厘米直径”
放置管道的人工成本 成本中心/作业类型 4298/1421 沟渠长度/5 管道=“10厘米直径”或“20厘米直径”
填平沟渠的人工成本 成本中心/作业类型 4298/1421 沟渠长度*沟渠宽度*（沟渠深度-0.1）/10 管道=“10厘米直径”
填平沟渠的机器成本 成本中心/作业类型 4298/1420 沟渠长度*沟渠宽度*（沟渠深度-0.1）/10 管道=“10厘米直径”
填平沟渠的人工成本 成本中心/作业类型 4298/1421 沟渠长度*沟渠宽度*（沟渠深度-0.2）/10 管道=“20厘米直径”
填平沟渠的机器成本 成本中心/作业类型 4298/1420 沟渠长度*沟渠宽度*（沟渠深度-0.2）/10 管道=“20厘米直径”
差旅费用 可变项目（成本要素） 420000/H 工期 固定费率
只要某个项目含有埋设管道的WBS元素，我们就可以使用这个成本模型，提供沟渠的长，宽，深以及管道类型就可以计算出成本计划。
我们可以在两种情况下很好地利用简便成本计划：<1>关注成本控制的项目管理。如果你使用项目作为成本控制的工具，对于项目成本计划的高效性，直观性和易用性特别看重，那么简便成本计划是很好的工具。<2>复杂项目的初步成本计划。如果我们使用项目系统来管理复杂的客户项目或成本投资项目，那么我们需要一个简单但高效的工具来作出初步成本计划，这种初步计划可以成为客户项目报价的基础。当项目被批准或接受定单后，我们会使用网络来做详细的成本计划。初步计划将被保留在一个分开的计划版本里作分析比较使用。
2． WBS的手工成本计划。这种计划方法是指根据项目的WBS结构，手工编制项目成本计划。具体来说又有三种形式：
<1> 层次计划（Hierarchy Planning）。这是最简单的形式，计划是不分成本要素的，也就是说对于WBS元素的成本是总数的形式，而不考虑成本的构成。计划者沿着WBS的层次结构对整个项目和会计年度编制简单的成本计划。
<2> 成本要素计划。当我们获取关于项目成本更详细的信息时，可以编制成本要素计划。这种计划涵盖初级成本要素，作业类型投入（从服务成本中心流入的次级成本要素）和统计指标的计划。
<3> 单位成本法（Unit Costing）。如果我们有资源供给的来源，数量和单价等信息，那么单位成本法是WBS手工成本计划中最为详细的一种形式。单位成本法实际上是一种电子表格，由于系统集成的缘故，这种电子表格可以调用系统存在的主数据和价格数据，比如成本中心模块的作业价格，物料的标准成本等等。和其他电子表格一样，我们可以利用单位成本法计算总计，小计和其他数学公式。 单位成本法按项目类别对成本分类，不同的项目类别需要成本编制者输入相应的内容，系统会自动查找并计算成本。比如对于内部加工成本，需要输入成本中心，作业类型和数量。系统会自动寻找作业价格，计量单位和成本要素，并计算成本。再比如对于外部加工或外包成本，需要输入采购信息记录，工厂，采购组织数量和成本要素。系统会自动寻找价格和计量单位，并计算成本。再比如对于物料成本，需要输入物料号，工厂和数量。系统会自动寻找物料成本，计量单位和成本要素，并计算成本。而对于间接费用，系统会根据成本核算单自动按比例并选取基数进行计算。
三种计划方式可以在项目的不同阶段使用，也可以同时使用。比如对于关键WBS元素用单位成本法，而其他用层次计划法。
3． 网络成本计划。上述两种计划方式，要么是在项目初期使用，要么是对那些只使用项目管理模块一部分功能（主要是作为成本核算对象）的项目使用。换句话说是对那些还没有维护详细的项目网络结构的项目使用的。回顾一下上一节和图二关于网络的介绍，一个信息完整的网络中已经包含了成本计算的所有条件。这一点我们只要和单位成本法所要输入的数据比较一下就清楚了。因此我们可以在保存网络，或者释放网络时让系统自动计算项目成本，或者手工触发项目成本的计算。这种计划的好处之一是成本计划和时间进度控制以及资源计划是集成的。因此如果网络结构或活动的时间发生变化，成本计划也会自动地做相应调整。
我们可以对活动（外部的，服务的或一般成本的）或外购的物料构件直接创建发票接收计划（Invoicing Plans）。这意味着系统可以根据发票接收计划中的日期计划成本和支付。成本将根据发票接收计划上的时间准确地计算而不是简单地分配到时间段上。在创建发票接收计划时我们可以复制一个参考发票接受计划，系统将根据实际的开始日期重新计算成本和时间。
随着项目进程的展开，相对于计划成本，实际成本将开始发生。网络实际成本通常由下列业务产生：财务会计过帐；物料管理的货物移动；内部作业分配；间接费用；确认（Confirmations）；收到发票。
4． 分配给项目的定单。如果一个WBS元素是一个成本对象，那么我们可以将不同种类的定单分配给它。这种分配意味着这些定单将在项目的架构下管理。这些定单的计划成本将以汇总的形式记录到项目中。在ERP中，我们使用定单实现不同的目的。可以分配给项目的定单包括：<1>内部定单。用于管理成本的定单。<2>设备维护定单。是设备管理模块中用来计划设备维护行为，输入和结算设备维护成本的定单。<3>生产定单。用于制造产品的定单。<4>销售定单。是一个销售组织和售达方关于以明确的价格和时间提供指定数量的商品或服务的契约协议。此外，根据定单是否消耗项目预算，可以分成消耗预算定单和独立预算定单两种。
预算和可用性控制
在成本计划阶段，我们将利用上述的工具尽可能地准确计划项目成本。这个阶段往往采取自下而上的方式，从最底层最细节的活动或WBS元素开始进行计划，层层汇总和修正，最终形成整个项目的成本计划。接下来在审批阶段，资金将以预算的形式明确和分配下来。预算分配的过程和成本计划的过程刚好相反。它是沿项目的结构自上而下分配下去的。预算和成本计划的区别在系统中是很微妙的。预算是具有束缚力的，它是管理层控制一段时间内成本发展的审批工具。当计划批准为预算后，这种束缚是体现在成本总额上的。明细的实际/计划比较是分析的工具，而不具有直接的约束力。
可用性控制在一定程度上体现了预算的束缚力。在项目的进行过程中，可使用的资金将被投入到不同的地方。承诺（指采购定单和采购请求）和实际成本相继发生。同时分配给该项目的消耗预算定单也将陆续发生各种成本。所有这些统称为“已分配资金”。当然我们可以使用“资金使用概览”等报表控制预算的使用，但是这种控制是被动的，也就是说，你必须自己去看这个报表才能知道预算使用情况，才能实施某种控制手段，比如冻结成本的发生，或通知相关人员。ERP项目管理系统还提供了主动的“可用性控制”。在执行成本相关的操作时，系统将自动计算已分配资金并和预算比较。如果超过了某个容忍水平（比如“90%预算已分配”，或“预算超过5%”等等），将触发各种系统反映（比如，警告，警告并发送电子邮件或错误信息）。我们可以在后台灵活地定义各种容忍水平和系统的反映方式。系统在计算已分配资金时会自动寻找相关的WBS元素，并自动汇总它下层的所有成本对象的已分配资金。
对于预算控制，系统还提供了各种工具：原始预算编制，预算更新，预算释放和预算结转。预算更新包括了预算增加，预算返还和预算划拨。预算释放功能使得我们可以分阶段部分地释放预算，以避免预算过早的耗尽。预算的结转是指可以将本年未使用完的项目预算结转到下一会计年度。
此外，如果我们使用ERP的投资管理模块。那么投资项目作为企业投资计划的实现工具，将被纳入整个企业投资计划的成本计划和预算控制架构中。
承诺和实际成本
和其他管理会计模块类似，项目实际成本流的来源是ERP系统的各种业务模块。除了实际成本流以外，承诺（指采购申请和采购定单这些将来的成本流）也是项目需要控制的。这些业务模块包括：<1>采购：采购申请，采购定单，收货和服务确认。<2>库存管理：物料领用。<3>财务会计：总帐过帐。<4>管理会计：间接费用法，流程成本（ABC成本法），利息计算，结算（定单），分配，分摊，作业分配。<5>项目系统管理：确认（Confirmation）。
确认（Confirmation）记录了活动或活动元素的进展情况（主要包括实际时间和预计剩余时间），从而使我们可以作出关于项目将来发展的预测。确认的动作在系统中会实现多项功能，其中包括实际成本过帐。我们可以用很多方式来完成确认：<1>单独确认，对个别网络，活动，活动元素或产能的确认。<2>汇总确认。<3>从信息系统出发，生成要求确认的工作流，发送给相关用户进行确认。<4>使用跨模块的时间表（Time Sheet）。时间表是ERP系统中记录个人工作时间及工作对象的工具。说它是跨模块的，是因为时间表的数据可以被很多模块使用，比如人力资源，项目系统，设备维护，管理会计，服务管理等等。<5>使用Internet完成单独确认，汇总确认或填写时间表。<6>通过系统接口，从PDA设备，或其他外部系统输入数据。
项目中的物料
在项目结构这一节中，我们介绍了物料构件可以分配给网络中的活动。这种分配的含义是指这些部件或原材料是在项目的这个阶段所必须的，因此需要被保留或预定。根据项目以及物料的特征，这些物料将通过触发MRP或者采购来获得。从图三我们看到项目系统这个模块从项目的角度集成了销售，采购和生产等模块。而项目中的物料是这种集成的一种重要形式。
项目中的物料是项目管理中一个复杂的组成部分。比如有些物料是直接采购的，有些物料有BOM和工艺路线，是企业内部制造的（如图三中分别指向采购和生产的箭头）。再比如有些物料是纳入库存管理的，有些则完全不纳入库存管理体系。再比如有些库存是项目专用的，而有些是企业统筹计划的。再比如有些库存是有价值的，而有些是不含价值的（或者说只管理物流而不管理价值流），诸如此类。这些都体现了ERP的高可配置性和灵活性。但是由于这个组成部分更多的涉及物流管理，因此本文中我们只选取一种常用的情景，从财务的角度来介绍项目中的物料这个功能。
我们的情景如图四所示，在项目W-100中，活动3100分配给WBS元素W-100.3。在这个活动中需要物料构件W-71600。W-71600是一种公司内部制造的部件，它的BOM包含三种原材料，分别是W-71610，W-71620和W-71630。该项目物料的库存都是项目专用库存。项目专用库存（Project Stock）和统筹库存（Collective Stock）存在以下区别：<1>项目专用库存的物料需求计划（MRP）是分项目运行的，和统筹库存是分开的。<2>项目专用库存除了本项目，不能作其他使用。（当然可以由专门的操作先将项目专用库存转作普通库存。）<3>项目专用库存的生产定单及其成本，采购定单及其承诺等物流过程都可以在项目信息系统中分项目反映。而统筹库存的物流过程是不分项目的，因此只有到最后库存被项目领用才会在项目信息系统中反映，在这之前的过程在项目中是无法反映的。<4>项目专用库存的估价和科目都可以和普通库存分开。此外，该项目的库存都是有价值的，即物流和价值流同步，物料移动会自动产生相应的财务凭证。
在本情景中，已经通过MRP生成了物料构件W-71600的生产定单以及三项原材料的采购定单。我们的介绍从采购定单开始，下文的每一步对应图四中的①-⑥：
1． 采购定单。对于项目W-100的物料需求计划（MRP）为该项目的所有物料以项目专用库存的形式作出计划。MRP的结果之一是对于W-71610，W-71620和W-71630三种原材料的采购申请。采购部门负责供应商选择并将申请转化成采购定单。图五显示了项目信息系统中一种类型的报表，在报表的左侧是项目的结构。我们可以看到由于是项目专用库存，因此生产定单也会在项目W-100的结构中出现。报表的右侧是某个具体格式的传统报表。我们在左侧选择不同的对象，右侧的报表就会显示该对象的信息。
在本步骤，当我们看WBS元素“W-100.3”的“实际/库存/承诺/计划”报表时，结果如下表所示：
成本要素 实际成本 库存 承诺 计划成本
作业成本-人工 0 0 0 0
存货（统计成本要素） 0 0 2,700 0
生产成本-材料 0 0 0 5,700
生产成本-产出 0 0 0 0
总计 0 0 2,700 5,700
在WBS元素“W-100.3”的计划成本中已经包含了物料构件W-71600的成本。同时由于采购定单而产生的承诺（将来的成本）也显示在该报表中。值得注意的是该承诺记录在“存货”这个成本要素上。我们知道存货是一项资产，传统情况下不会出现在成本流中，但是由于在项目管理中，我们需要追踪包括项目专用库存在内的项目价值流，因此我们将存货建成统计成本要素来满足这一需求。
2． 采购定单收货。对于原材料W-71610，W-71620和W-71630的采购定单在本步骤收到货物。采购收货的动作增加了项目W-100的项目专用库存，同时采购定单引起的承诺金额被减少。结果如下表所示：
成本要素 实际成本 库存 承诺 计划成本
作业成本-人工 0 0 0 0
存货（统计成本要素） 0 2,700 0 0
生产成本-材料 0 0 0 5,700
生产成本-产出 0 0 0 0
总计 0 2,700 0 5,700
3． 生产领料。对于W-71600的计划定单被生产部门转化成生产定单。如图四所示该生产定单的目标成本包含3,000元的作业成本和2,700元的原材料W-71610，W-71620，W-71630的成本。这张报表我们在《生产成本》章节已经介绍过了。在图五的报表中，物料构件W-71600和生产定单都显示在WBS元素“W-100.3”下，它们的金额在该WBS元素的报表中被加总了。当该生产定单领取三种项目专用库存W-71610，W-71620和W-71630时，实际成本被计入该生产定单。这次我们在报表左侧选定生产定单，结果如下表所示：
成本要素
实际成本 库存 承诺 计划成本
作业成本-人工 0 0 0 3,000
存货（统计成本要素） 0 0 0 0
生产成本-材料 2,700 0 0 2,700
生产成本-产出 0 0 0 5,700-
总计 2,700 0 0 0
4． 工票确认。本步骤生产定单被确认。由于生产定单实际消耗人工时超过目标，导致实际成本增加250元。作业成本增加到3,250元,总成本增加到5,950元。我们在报表左侧仍然选定生产定单，结果如下表所示：
成本要素 实际成本 库存 承诺 计划成本
作业成本-人工 3,250 0 0 3,000
存货（统计成本要素） 0 0 0 0
生产成本-材料 2,700 0 0 2,700
生产成本-产出 0 0 0 5,700-
总计 5,950 0 0 0
5． 完工入库。本步骤生产定单完成最后确认,完工部件W-71600被验收入库，成为项目专用库存。我们在报表左侧选定WBS元素，结果如下表所示：
成本要素 实际成本 库存 承诺 计划成本
作业成本-人工 3,250 0 0 3,000
存货（统计成本要素） 0 5,700 0 0
生产成本-材料 2,700 0 0 8,400
生产成本-产出 5,700- 0 0 5,700-
总计 500 5,700 0 5,700
6． 发货到项目。本步骤我们将部件W-71600发给项目W-100的活动3100使用。这将减少项目专用库存。同时该部件的实际成本计入网络活动。我们在报表左侧选定活动3100，结果如下表所示：
成本要素 实际成本 库存 承诺 计划成本
作业成本-人工 0 0 0 0
存货（统计成本要素） 0 0 0 0
生产成本-材料 5,700 0 0 5,700
生产成本-产出 0 0 0 0
总计 5,700 0 0 5,700
项目的收入和现金管理
对于客户项目，除了成本，项目还会产生收入。ERP可以通过销售模块和项目系统模块的集成自动复制销售定单至项目收入计划。同时如果销售定单应用了开票计划（Billing Plan）功能，开票的日期也将纳入计划中。收入计划同时也可以显示销售折扣，折让和其他销售扣减项目。当然，除了集成我们也可以直接手工做项目收入计划，或者直接将开票计划维护在WBS元素上。
开票计划是分次开具发票的计划。在开票计划中，我们详细维护每次开票的日期，开票的百分比和金额，是否冻结和相关的项目里程碑等等信息。里程碑开票在客户项目中被广泛采用。系统将根据项目进度的任何变化自动调整收入计划。当相关的项目里程碑被确认时，系统可以自动将开票计划中的某次开票释放。开票计划还可以包括预收款，当然预收款只影响项目收付款而不影响收入。当预收款释放后，系统可以生成预收款请求，和发票一样可以打印出来递交给客户。随后收到的预收款会指向相关的请求，并将它清帐。
我们可以结合本章已介绍的内容，设计出这样一个销售流程：客户询价（Inquiry）=> 分配和定义项目结构 => 项目成本计划 => 按成本加成法报价（Quotation）=> 销售定单 => 项目收入计划。
项目的实际收入将在销售定单实际开票时由系统自动记录到相应的项目中。比较特殊的是资源相关定价的项目（或称为成本补偿项目）。在这种项目中，客户同意付给承约商所有实际花费的成本（劳动力，原材料等等），加上一定的协商利润，而不是规定数额。对于这种项目系统提供了特殊的功能：自动计算项目成本，将成本按一定规则分类，各类成本按协商利润加成后确定销售定单的开票金额，最后开票。这个流程其实使用了和上文销售流程同样的工具，我们称为销售定单行项目的动态处理，本文不作赘述。
和收入成本一样，现金流也是我们在项目管理中关心的问题。除了手工计划项目的收付款，系统可以利用大部分收入和成本的计划工具来计划现金流，如开票计划，发票接收计划等等。在计算日期时系统会将客户和供应商的付款条款等因素考虑进去。项目现金管理也使用了《资金管理》章节中科目分层的概念。
期末结帐
项目系统管理模块的期末结帐是项目财务管理的重头戏。有些步骤和其他模块是类似的，比如流程成本分配到项目（ABC成本法），间接费用法（用成本核算单分配间接费用）等等成本流的期末结转和项目利息的计算。我们在本书的相关章节都已做过介绍。对于项目管理来说还有些有特殊性的期末结帐活动。
成本预测和进度分析（Progress Analysis）
项目开始执行后，进度和实际成本都可能和计划偏离。成本预测是在项目执行过程中不断计算和调整完成项目剩余部分预计将要发生的成本。成本预测的数据基础是：计划成本，实际成本，承诺，确认的预测完工日期和完工工作量。图八显示了计划成本，实际成本和预测成本这三者的关系。预测成本的数据在系统中保存在一个特殊的计划版本中。我们可以用这个特殊版本编制层次结构报表或成本要素报表。
从图8中，我们看到，虽然该项目的实际成本发生低于计划。但是从预测成本来看，成本暂时低于计划很有可能是项目进度拖后造成的。所以仅仅孤立地检查项目的成本，资源和进程是无法有效控制项目的。我们需要更有意义的信息来分析项目到目前为止的进展情况和健康状态。进度分析（Progress Analysis）正是实现这一目的。ERP中的进度分析使用的是项目管理理论中的实现价值分析（Earned Value Analysis）方法。
我们首先需要计算完工比率（POC，Percent of Completion）。我们可以人为估计WBS元素，活动和活动元素的POC，或者可以由系统根据已有数据自动计算。系统总共提供了九种确定POC的方法：开始/结束规则；估计；里程碑技术；时间比例法；成本比例法；数量比例法；进展程度法；次级比例法（或相关比例法）；用户出口（允许用户自定义规则的程序出口）。我们需要计算两个POC：计划POC，指在指定时间点上预计的完工比率；实际POC，指在指定时间点上实际的完工比率。随后，通过某种权数（通常是计划成本），我们可以汇总整个项目结构的所有POC，计算出整个项目的POC。
接下来，我们利用POC来计算如图九所示的一组关键指标：
BCWS：Budgeted cost of work scheduled， = 总计划成本 * 计划POC。反映的是按照计划到今天应该产生了多少成本。
BCWP：Budgeted cost of work performed，= 总计划成本 * 实际POC。反映的是根据到目前为止的项目进度，应该产生多少成本。或者说到目前为止干的活值多少，不过这个值多少仍然是成本的概念，不能和收入混淆起来。
SV：Schedule variance 进度差异，= BCWS – BCWP。反映了项目进度落后计划多少，它告诉我们我们的项目是否太慢了。
CV：Cost variance 成本差异，= 实际成本 – BCWP。反映了项目是否超支了，它告诉我们我们的项目是否太昂贵了。
通过SV和CV两个差异的分离，我们可以解释项目目前的进展情况以及项目的健康状况。
结果分析（Results Analysis）
我们在《成本流和成本对象》章节中提到，结果分析是一种类型的“由内至外的过帐”。项目管理中的结果分析解决的究竟是什么问题呢？在长期的客户项目中，日常收入和成本的的入帐都跟相关的业务处理相联系，比如开票，发票校验等等。但是这样的收入和成本数据很多情况下是不能满足会计的权责发生原则和配比原则的。因此根据实质重于形式的原则和各国关于长期项目收入和成本核算的相关准则，我们需要对项目在各会计期间的收入和成本数进行调整。结果分析就是根据事先设定的规则，自动计算相关会计期间实际应确认的项目收入和成本，并自动生成调整分录的系统功能。
新近定单（Incoming Orders）
对于某些围绕客户项目运转的公司，新签定的项目和进行中的项目对于预测公司将来的盈利前景具有重要意义，这对于以长期和超长期项目为主的公司来说由为重要。新近定单（Incoming Orders）和未完成定单（Open Orders）是这方面的两个重要指标。新近定单是考虑了定单更改，定单取消和计划更改等历史因素后的新签定和进行中定单的价值。未完成定单价值是新近定单减去已确认的收入和成本后的价值。ERP可以根据项目管理系统和销售模块的数据，自动计算出类似下表的报表：
收入 成本 利润 利润率%
新定单 -940 460 -480 51
定单更改 -280 50 -230 82
定单取消 20 -12 8 -40
计划更改 0 80 80 -50
总新近定单 -1,200 578 -622 51
已开票 -600 400 -200 33
未完成定单 -600 178 -422 70
其中计划更改是由于项目成本结构改变后引起的利润降低。
结算
项目的结算和内部定单的结算在基本概念上是一致的。只是由于项目具有复杂的结构，因此在结算时整个结构的不同部分（各WBS元素和活动）的结算规则是一个特殊的问题。首先，是结算规则的决定。WBS元素的结算规则可以通过不同的策略决定。比如对于客户项目往往会对开票的WBS元素先做结果分析。结果分析的数据包括了其下层WBS元素和活动/定单的成本和收入。因此只有开票的WBS元素被结算。结算规则只维护在开票的WBS元素上。这种结算规则很可能是根据开票WBS元素和相连的销售定单决定的市场细分。其它的对象的结算规则都定为“不结算”。再比如对于成本项目，系统可以从各WBS元素的负责成本中心或申请成本中心生成结算规则。或者还可以让下层的WBS元素继承上层WBS元素的结算规则等等。对于网络/活动，我们可以定义一个包含若干优先次序的“结算规则决定策略”。比如活动的结算规则依次<1>从其分配的WBS元素中继承。<2>从项目定义中继承。<3>按缺省规则自动生成。<4>手工维护等等。其次，从结算的顺序上，也有多层上卷后统一结算和分别直接结算两种。
软件开发项目中如何使用范围变化管理
项目管理过程不从确定项目开始，也不随着项目计划完成而告终。你必须要在项目管理过程中使用范围变化管理，如果你不善用此一技巧，那麻烦将是不可避免的。
确定并计划项目仅仅是成功的项目管理过程的第一步。在制定出计划之后，你还必须要将计划付诸实施。你必须要保证计划任务在规定的时间内完成，而且不能超出原有的预算。一旦项目开始进行，客户可能会向你提出更多的或是与原计划不同的要求。在这个时候范围变化管理就可以派上用场了。如果你不善用此一技巧，项目小组就只能尝试着在项目时间和预算不变的情况下去完成比原计划多得多并且要耗费更多成本的任务。换句话来说，就是麻烦将是不可避免的。
范围管理从范围界定开始
对项目范围进行界定恐怕是确定项目的过程当中最为重要的组成部分。事实上，如果你并不能确定项目的目标任务，也不能确定项目的范围，项目就根本不可能成功。范围管理是项目管理过程当中最为关键的组成部分之一。但是，如果不能对项目的范围作出成功的界定，想要实施范围管理也几乎是不可能的。
界定范围的目的是清楚描述项目的逻辑范围并在此问题上同有关各方达成一致。对项目范围的陈述可以让大家清楚的了解哪些工作是项目范围之内的事情，而哪些工作不属于该项目范畴。对项目范围的界定越明确，对项目就越有利。下面这些信息应该能起到一些帮助作用。
范围内和范围外的任务类型（业务需求、现状评估）
范围内和范围外的生命周期流程（分析、设计、测试）
范围内和范围外的数据类型（财务、销售、员工）
范围内和范围外的数据来源或数据库（账单、公司总帐，薪水明细）
范围内和范围外的部门（人力资源、制造商、供货商）
范围内和范围外的主要功能（决策支持、数据输入、管理报告）
制定可行的范围变化流程
项目经理和项目小组的成员都必须意识到，项目范围的变化本身并没有错。也就是说，在项目的进行过程中改变项目范围并不是一件坏事。事实上，在很多情况下，这还是一件好事。首先，客户通常都不能在项目开始之前明确所有的需求。其次，即使他们能够做到这一点，整个的商业环境也是在不断变化的，所以项目需求也可能会随之而发生变化。
如果你不能够适应变化，项目的最终价值可能会受到影响，或者可能会使项目失去价值。因此，你需要具备在项目进行的过程当中根据需要作出改变的能力。如果项目经理不能够在项目进行过程当中积极的对变化进行管理，问题可能就会随之而来。任何项目都应该有一个有效的变化管理流程。这个流程应该包括对变化的识别判断，对变化的商业价值的判断，对变化会给项目带来的冲击和影响的判断，将相应的信息提交项目投资人进行评估。项目投资人来最终决定是否将变化引入到项目当中。如果变化被引入项目，项目投资人还应该考虑变化对项目的影响程度，并且为之配备相应的额外资源，如延长时间和追加资金预算等。
企中的项目有哪些呢？如果我们把企业的经营活动进行分解，会发现企业中的各种工作基本上都可以归类为一个又一个的项目，大到：IT服务项目、工程建设项目、产品开发项目、投资项目、ERP项目、BPR项目、薪酬改革项目、市场开发项目、房地产开发项目等等，小到：一次搬迁、一次校园招聘会、一次内部培训、一次会议组织、一次新年聚会等等。
项目管理就是在有限的资源约束下运用系统的观点、方法和理论以实现项目的目标的方法。著名的美国的阿波罗登月计划，整个项目大约有40万人和20万家企业参加，耗资200多亿美元，就是项目管理成功应用的杰出典范。
计划、控制、度量——洗尽铅华的项目管理真谛
在乱花渐欲迷人眼的项目管理领域内，项目经理们总是很容易被各种理论说服，被各种模型吸引，被各种模版包围，可是，对一个具体的项目来说，什么才是最重要的呢，需要做些什么才能让项目可控，并且朝着成功的方向走近呢？
去掉繁复的理论体系和证书的包裹，项目管理的目标其实很朴素，手段其实很简单，只是为了让项目成功，做好这样三件事——计划、控制、度量。这是笔者根据多年的项目管理实践，从实用的角度出发，结合多个理论模型总结出来的一点经验和体会，希望能对各位有所启发。
正文
项目管理的理论体系很多，对项目管理的理解也各不相同，各种组织的最佳实践模型更是数不胜数。那么，我们在实际的软件开发过程中该如何选择，如何应用呢？
结合各种PM理论基础和在实际工作中积累的项目管理经验，笔者认为，对于一个具体的项目来说，项目管理的核心问题不是采用哪种理论体系，不是通过哪种认证评估，也不是选择哪个最佳实践模型，而是要做好这样三件事——计划、控制、度量。也就是说，项目启动之前，要有计划；项目进行当中，要有控制；项目结束之后，要有度量。这样才能保证项目有的放矢（依照计划执行）、有据可查（产生管理文档）并且让以后类似的项目在计划阶段有章可循（参考度量的结果）。
下面来看看我们在计划、控制和度量这三件事情上需要做些什么。
1. 计划
项目的计划阶段一般会对项目的可行性进行分析，并提出若干备选方案，然后根据组织的目标、能力和预算，挑选一个最适合的方案来执行。
选定方案之后，要根据项目范围、资源配备和预算等条件，制定出项目的进度计划、人员配置计划、预算计划、风险管理计划，以及项目管理所需的其它QA计划、CM计划、MA计划等辅助计划。
2. 控制
为了保证项目能够按计划顺利完成，在项目执行阶段，我们有很多工作要做。
项目的进度控制、质量控制和成本控制是项目管理中最关键也是最重要的三个方面，此外还有风险的识别和管理，也是影响项目成败的重要因素之一。
项目进度管理需要在每个里程碑或检查点及时检查是否按照计划要求完成了相关的工作内容和需要交付的工作产品，以保证项目进度在控制之中。
质量管理是要确保每个工作阶段的可交付产品符合项目和组织的质量标准，确保最终交付的产品是合格的，可以使用的。
成本管理是为了保证项目不超出组织的预算，对于内部的IT项目而言，员工的工作时间就是项目的主要成本。基本上，保证项目按照计划的进度和人员配置完成，就可以保证成本在可控范围之内。
风险管理主要是应对突发的、不确定的因素对项目造成的影响。需要在计划阶段就制定出风险应对计划，在执行阶段及时发现和识别风险，当风险发生时，采取正确的措施应对，尽量减少负面影响。
3. 度量
在项目执行过程中，除了要对项目的进度、范围、质量进行管理和控制，也要对项目的关键指标（工作量、里程碑、工作产品、人员配置、物理规模等）进行度量，通过各种度量指示器在项目的执行阶段持续的跟踪和记录项目进展情况，及时发现进度、成本和质量上的偏差。
除了跟踪和发现项目偏差之外，度量的更深层次的意义在于为以后的项目提供可参考的历史数据，为组织积累经验，提高组织的计划和估算能力。但是在实际的项目当中，很多项目经理认为，度量对当前项目的意义不大，不愿意花时间去做度量。其实这对组织来说是很不利的，因为如果没有历史数据的积累，即使已经做过了大量的项目，组织仍然无法为项目的规模、成本、人员等的估算和计划制定提供确切的历史数据和估算依据，组织的项目管理将仍然是粗放型的，做不到精细化管理，达不到更高的项目管理水平。
度量的意义重大，但真正知道该怎样做的人并不多，这点我将在今后的文章中专门讲述，并尽量提供详尽的参考模版。
为了更清楚的说明计划、控制和度量在项目管理中的重要作用，下面举一个买鞋的例子来详细说明。
根据项目的定义：“项目是为完成某一独特的产品、服务或任务所做的一次性努力”，某次买鞋的过程具有独特性、一次性和不可重复性的特点，是典型的项目，我们可以称之为“买鞋”项目。
在“买鞋”项目中的计划、控制和度量是怎样的呢？
l 首先是计划。在买鞋之前，我们首先要明确是否一定要购买新鞋，是否有时间去商场，然后提出几个备选的商场，这相当于可行性分析和备选方案；考虑一下自己希望与之搭配的服装，个人的气质特点，本次购买的预算，然后选择一个各方面最适合的商场，这相当于选择合适的项目方案；根据选定的方案，制定出选购活动的时间表、价格标准、鞋子款式、午餐安排等，这相当于制定项目进度计划及相关的辅助计划。
l 然后是控制。对于“买鞋”项目来说，我们要注意鞋子是否符合最初的款式要求，这相当于质量控制；我们还要把价格控制在可以接受的限度之内，这相当于成本控制；我们不想在商场花费过多的时间，因此要控制在每个专柜花费的时间不要过多，这相当于进度控制；及时提醒自己不要买计划外的物品，不要轻易听从专柜小姐的劝说购买价格过高的鞋子，这相当于风险控制。
l 最后是度量。在逛商场的过程中，经常比对一下款式、价格、时间上的计划和实际的偏差，相当于度量的跟踪和记录。把鞋子买回去之后，可以再对最终购买的鞋子的价格、款式、所花费的时间与出发前的计划进行对照和统计，分析一下估算与实际情况的偏差，总结出这次购买行动的成功经验和待改进之处，以便为以后类似的购买行为提供精确的可参考数据。
从以上的分析可以看出，计划、控制、度量这三件事是项目管理的核心和关键之所在，无论我们应用什么样的项目管理方法和模型，做好这三件事，就等于抓住了项目管理的本质，掌握了项目管理的真谛，这时，我们就可以不再为众多的理论体系所制约，可以得心应手的根据项目特点和组织需要来创造性的做好项目管理工作了。也只到有这个时候，我们的项目管理才算是真正学到家了。
项目管理系统（Project System）是ERP的一个集成解决方案，它的目的是帮助企业执行项目管理中的所有任务，因此它包括了在项目所有阶段的各种功能。ERP的项目管理涵盖了两类项目：客户项目和成本投资项目。客户项目是指以销售为目的，根据客户需求执行的项目。这类项目和销售模块有很强的联系和集成。在造船，建筑，工程，服务，军工等各种行业有广泛的应用。成本投资项目是指企业内部各种类型的项目，这些项目的成本在项目完成后或者资本化或者费用化，包括研发项目，投资项目，IT项目，设备维护项目等等。这类项目在各种行业的应用更为广泛。
项目的结构
在正式执行一个项目之前，我们必须明确地定义项目的目标并制定项目所要执行的工作的结构。明确定义的项目结构为成功的项目计划，执行和控制提供了先决条件。图一是ERP中主要的项目结构对象，以及它们之间的相互关系。
项目定义（Project Definition）
项目定义是一个总括的项目描述。项目定义为将来项目计划阶段所要创建的所有项目管理对象提供了一个框架。
工作细分结构（ Work Breakdown Structure）
工作细分结构是以层次结构的形式将完成一个项目所要执行的任务层层细分所形成的项目结构。它提供了关于项目的概览并且构筑了项目的组织结构和协调合作的基础，同时显示了项目在工作，时间和金钱上的花费，可以应用它来计划时间，成本和分配预算。
工作细分结构中的每一项任务被称为WBS元素（WBS Elements）。和别的项目结构对象一样，系统在WBS元素中维护了很多信息。比如有关于组织结构关系的信息：公司代码，业务范围，工厂（物流模块），设备或功能地点（工厂维护模块），利润中心等等。再比如在基础信息中有三个标志：<1>成本计划。如果要对这个WBS元素计划成本，我们必须指明该WBS元素是一个计划元素。<2>成本对象。如果想将实际成本和承诺记录到某个WBS元素，我们必须指明该WBS元素是一个成本对象。如果这个标志没有打开，该项目中其他能够分配成本和承诺的对象（比如内部定单，网络或采购定单）也将不可以分配给该WBS元素。<3>开票。如果想将收入确认到某个WBS元素，我们必须指明该WBS元素是一个开票元素。还有很多信息被分别组织在项目责任，控制数据，凭证，开票计划，结算规则，在建工程，资本投资计划等等视图中。
网络（Network）
和WBS不同，网络描述的是项目执行过程。网络是一种在项目进度安排，成本和资源安排的计划，分析和控制工作中很有用的技术。我们可以将网络分配给项目定义，WBS元素或者销售凭证。
构成网络的关键元素是活动（Activity）和活动之间的关系。活动具有以下特征：它们持续一定的时间；它们有明确的开始和结束；它们执行的过程不被中断（指如果有中断应定义多个分开的活动）；执行他们需要一定的资源；它们引起成本。活动如图一所示可以分配给WBS元素。
图二我们给出了各种类型的活动。ERP项目系统区分三种主要类型的活动：内部处理活动（Internally processed activities），外部处理活动（Externally processed activities）和一般成本活动（General costs activities）。我们甚至可以将活动进一步细分成活动元素（Activity Elements），如图二最右侧的活动。活动元素也可以区分成上述三种类型。
对于内部处理活动，为了计划完成它所牵涉的工作，以及提供成本计算的基础，我们需要明确如下一些问题，比如：执行该活动需完成多少工作；什么产能（如人工或机器）会用来执行这些工作；什么资格（Qualifications）是完成该活动所必须具备的；哪些人员或个别产能是完成该活动所必须提供的等等。因此我们会在内部处理活动中指明工厂，工作中心等组织机构和工作时间等信息。
对于外部处理活动，我们一般需指明负责的采购组织和采购组。在释放网络时，系统可以自动创建采购申请，由采购部门负责完成。或者我们也可以手工触发采购申请创建。我们也可以将采购信息记录记录到外部处理活动中，采购信息记录里维护了供应商，价格条款等信息。
另外我们可以将物料分配给所有的活动，如图2最左侧的活动。在项目执行的过程中，生成采购申请或计划定单，分别由采购部门或生产部门完成。
活动和活动之间在系统中可以维护四种关系：结束-开始（Finish - Start (FS) Relationship），开始-开始（Start - Start (SS) Relationship），结束-结束（Finish - Finish (FF) Relationship）和开始-结束（Start - Finish (SF) Relationship）。
里程碑（Milestones）
里程碑是项目中有特殊重要性或者会触发某些事先定义功能的一类事件。一般来说它们显示了项目各阶段或各部门间的衔接点。在ERP中里程碑可以分配给活动（Activity）和WBS元素。里程碑可以实现四种任务：<1>里程碑趋势分析（Milestone Trend Analysis /MTA）。是一种控制项目进度的简单而有效的工具。在不同报表日期，里程碑日期被用于比较分析，图形化的MTA使我们可以立刻发现项目趋势和任何的延误。<2>使用里程碑技术的实现价值分析（Earned Value Analysis）。里程碑技术是众多计算实现价值技术中的一种。每一个里程碑代表了活动或WBS元素所完成的这部分工作。<3>决定开票计划的日期。将里程碑和开票计划的日期相连。当项目进度到达某个里程碑时，里程碑的实际日期将被自动复制到开票计划中。<4>触发预定义的里程碑功能。我们可以利用里程碑触发一系列事件来处理某些特定的业务流程。
在ERP项目结构的建立中有两种可以增强工作效率的功能：<1>标准项目结构和复制功能。<2>图形功能。
项目的成本控制
ERP通过项目成本的计划和实际比较来达到控制成本的目的。项目成本控制组件和其它相关模块有紧密的集成。这些模块包括管理会计，财务会计，生产计划和控制，物料管理。
成本计划
项目成本计划在项目的不同阶段有不同的作用：在概念定义和粗略计划阶段，成本计划的作用是计算一个项目最初的成本估算；在审批阶段，成本计划是分配预算的基础；在项目执行阶段，我们使用成本计划来控制实际成本和成本差异。 ERP成本计划有如下几种方式：
1． 简便成本计划。简便成本计划的核心是成本模型（Costing Model）。对于成本结构相似且经常重复出现的任务，我们可以定义成本模型。在对WBS元素计划成本时，只要提供相关的数量和参数，就可以计算出成本计划。举例来说，假如我们的项目经常需要埋设管道。但是不同的项目，埋设管道的直径以及沟渠的长宽深各不相同。我们可以设计如下成本模型：
描述 类型 对象 数量 激活 价格
挖掘沟渠的人工成本 成本中心/作业类型 4298/1421 沟渠长度*沟渠宽度*沟渠深度/10
挖掘沟渠的机器成本 成本中心/作业类型 4298/1420 沟渠长度*沟渠宽度*沟渠深度/10
管道 工厂/物料 0001/管道-10 沟渠长度 管道=“10厘米直径”
管道 工厂/物料 0001/管道-20 沟渠长度 管道=“20厘米直径”
放置管道的人工成本 成本中心/作业类型 4298/1421 沟渠长度/5 管道=“10厘米直径”或“20厘米直径”
填平沟渠的人工成本 成本中心/作业类型 4298/1421 沟渠长度*沟渠宽度*（沟渠深度-0.1）/10 管道=“10厘米直径”
填平沟渠的机器成本 成本中心/作业类型 4298/1420 沟渠长度*沟渠宽度*（沟渠深度-0.1）/10 管道=“10厘米直径”
填平沟渠的人工成本 成本中心/作业类型 4298/1421 沟渠长度*沟渠宽度*（沟渠深度-0.2）/10 管道=“20厘米直径”
填平沟渠的机器成本 成本中心/作业类型 4298/1420 沟渠长度*沟渠宽度*（沟渠深度-0.2）/10 管道=“20厘米直径”
差旅费用 可变项目（成本要素） 420000/H 工期 固定费率
只要某个项目含有埋设管道的WBS元素，我们就可以使用这个成本模型，提供沟渠的长，宽，深以及管道类型就可以计算出成本计划。
我们可以在两种情况下很好地利用简便成本计划：<1>关注成本控制的项目管理。如果你使用项目作为成本控制的工具，对于项目成本计划的高效性，直观性和易用性特别看重，那么简便成本计划是很好的工具。<2>复杂项目的初步成本计划。如果我们使用项目系统来管理复杂的客户项目或成本投资项目，那么我们需要一个简单但高效的工具来作出初步成本计划，这种初步计划可以成为客户项目报价的基础。当项目被批准或接受定单后，我们会使用网络来做详细的成本计划。初步计划将被保留在一个分开的计划版本里作分析比较使用。
2． WBS的手工成本计划。这种计划方法是指根据项目的WBS结构，手工编制项目成本计划。具体来说又有三种形式：
<1> 层次计划（Hierarchy Planning）。这是最简单的形式，计划是不分成本要素的，也就是说对于WBS元素的成本是总数的形式，而不考虑成本的构成。计划者沿着WBS的层次结构对整个项目和会计年度编制简单的成本计划。
<2> 成本要素计划。当我们获取关于项目成本更详细的信息时，可以编制成本要素计划。这种计划涵盖初级成本要素，作业类型投入（从服务成本中心流入的次级成本要素）和统计指标的计划。
<3> 单位成本法（Unit Costing）。如果我们有资源供给的来源，数量和单价等信息，那么单位成本法是WBS手工成本计划中最为详细的一种形式。单位成本法实际上是一种电子表格，由于系统集成的缘故，这种电子表格可以调用系统存在的主数据和价格数据，比如成本中心模块的作业价格，物料的标准成本等等。和其他电子表格一样，我们可以利用单位成本法计算总计，小计和其他数学公式。 单位成本法按项目类别对成本分类，不同的项目类别需要成本编制者输入相应的内容，系统会自动查找并计算成本。比如对于内部加工成本，需要输入成本中心，作业类型和数量。系统会自动寻找作业价格，计量单位和成本要素，并计算成本。再比如对于外部加工或外包成本，需要输入采购信息记录，工厂，采购组织数量和成本要素。系统会自动寻找价格和计量单位，并计算成本。再比如对于物料成本，需要输入物料号，工厂和数量。系统会自动寻找物料成本，计量单位和成本要素，并计算成本。而对于间接费用，系统会根据成本核算单自动按比例并选取基数进行计算。
三种计划方式可以在项目的不同阶段使用，也可以同时使用。比如对于关键WBS元素用单位成本法，而其他用层次计划法。
3． 网络成本计划。上述两种计划方式，要么是在项目初期使用，要么是对那些只使用项目管理模块一部分功能（主要是作为成本核算对象）的项目使用。换句话说是对那些还没有维护详细的项目网络结构的项目使用的。回顾一下上一节和图二关于网络的介绍，一个信息完整的网络中已经包含了成本计算的所有条件。这一点我们只要和单位成本法所要输入的数据比较一下就清楚了。因此我们可以在保存网络，或者释放网络时让系统自动计算项目成本，或者手工触发项目成本的计算。这种计划的好处之一是成本计划和时间进度控制以及资源计划是集成的。因此如果网络结构或活动的时间发生变化，成本计划也会自动地做相应调整。
我们可以对活动（外部的，服务的或一般成本的）或外购的物料构件直接创建发票接收计划（Invoicing Plans）。这意味着系统可以根据发票接收计划中的日期计划成本和支付。成本将根据发票接收计划上的时间准确地计算而不是简单地分配到时间段上。在创建发票接收计划时我们可以复制一个参考发票接受计划，系统将根据实际的开始日期重新计算成本和时间。
随着项目进程的展开，相对于计划成本，实际成本将开始发生。网络实际成本通常由下列业务产生：财务会计过帐；物料管理的货物移动；内部作业分配；间接费用；确认（Confirmations）；收到发票。
4． 分配给项目的定单。如果一个WBS元素是一个成本对象，那么我们可以将不同种类的定单分配给它。这种分配意味着这些定单将在项目的架构下管理。这些定单的计划成本将以汇总的形式记录到项目中。在ERP中，我们使用定单实现不同的目的。可以分配给项目的定单包括：<1>内部定单。用于管理成本的定单。<2>设备维护定单。是设备管理模块中用来计划设备维护行为，输入和结算设备维护成本的定单。<3>生产定单。用于制造产品的定单。<4>销售定单。是一个销售组织和售达方关于以明确的价格和时间提供指定数量的商品或服务的契约协议。此外，根据定单是否消耗项目预算，可以分成消耗预算定单和独立预算定单两种。
预算和可用性控制
在成本计划阶段，我们将利用上述的工具尽可能地准确计划项目成本。这个阶段往往采取自下而上的方式，从最底层最细节的活动或WBS元素开始进行计划，层层汇总和修正，最终形成整个项目的成本计划。接下来在审批阶段，资金将以预算的形式明确和分配下来。预算分配的过程和成本计划的过程刚好相反。它是沿项目的结构自上而下分配下去的。预算和成本计划的区别在系统中是很微妙的。预算是具有束缚力的，它是管理层控制一段时间内成本发展的审批工具。当计划批准为预算后，这种束缚是体现在成本总额上的。明细的实际/计划比较是分析的工具，而不具有直接的约束力。
可用性控制在一定程度上体现了预算的束缚力。在项目的进行过程中，可使用的资金将被投入到不同的地方。承诺（指采购定单和采购请求）和实际成本相继发生。同时分配给该项目的消耗预算定单也将陆续发生各种成本。所有这些统称为“已分配资金”。当然我们可以使用“资金使用概览”等报表控制预算的使用，但是这种控制是被动的，也就是说，你必须自己去看这个报表才能知道预算使用情况，才能实施某种控制手段，比如冻结成本的发生，或通知相关人员。ERP项目管理系统还提供了主动的“可用性控制”。在执行成本相关的操作时，系统将自动计算已分配资金并和预算比较。如果超过了某个容忍水平（比如“90%预算已分配”，或“预算超过5%”等等），将触发各种系统反映（比如，警告，警告并发送电子邮件或错误信息）。我们可以在后台灵活地定义各种容忍水平和系统的反映方式。系统在计算已分配资金时会自动寻找相关的WBS元素，并自动汇总它下层的所有成本对象的已分配资金。
对于预算控制，系统还提供了各种工具：原始预算编制，预算更新，预算释放和预算结转。预算更新包括了预算增加，预算返还和预算划拨。预算释放功能使得我们可以分阶段部分地释放预算，以避免预算过早的耗尽。预算的结转是指可以将本年未使用完的项目预算结转到下一会计年度。
此外，如果我们使用ERP的投资管理模块。那么投资项目作为企业投资计划的实现工具，将被纳入整个企业投资计划的成本计划和预算控制架构中。
承诺和实际成本
和其他管理会计模块类似，项目实际成本流的来源是ERP系统的各种业务模块。除了实际成本流以外，承诺（指采购申请和采购定单这些将来的成本流）也是项目需要控制的。这些业务模块包括：<1>采购：采购申请，采购定单，收货和服务确认。<2>库存管理：物料领用。<3>财务会计：总帐过帐。<4>管理会计：间接费用法，流程成本（ABC成本法），利息计算，结算（定单），分配，分摊，作业分配。<5>项目系统管理：确认（Confirmation）。
确认（Confirmation）记录了活动或活动元素的进展情况（主要包括实际时间和预计剩余时间），从而使我们可以作出关于项目将来发展的预测。确认的动作在系统中会实现多项功能，其中包括实际成本过帐。我们可以用很多方式来完成确认：<1>单独确认，对个别网络，活动，活动元素或产能的确认。<2>汇总确认。<3>从信息系统出发，生成要求确认的工作流，发送给相关用户进行确认。<4>使用跨模块的时间表（Time Sheet）。时间表是ERP系统中记录个人工作时间及工作对象的工具。说它是跨模块的，是因为时间表的数据可以被很多模块使用，比如人力资源，项目系统，设备维护，管理会计，服务管理等等。<5>使用Internet完成单独确认，汇总确认或填写时间表。<6>通过系统接口，从PDA设备，或其他外部系统输入数据。
项目中的物料
在项目结构这一节中，我们介绍了物料构件可以分配给网络中的活动。这种分配的含义是指这些部件或原材料是在项目的这个阶段所必须的，因此需要被保留或预定。根据项目以及物料的特征，这些物料将通过触发MRP或者采购来获得。从图三我们看到项目系统这个模块从项目的角度集成了销售，采购和生产等模块。而项目中的物料是这种集成的一种重要形式。
项目中的物料是项目管理中一个复杂的组成部分。比如有些物料是直接采购的，有些物料有BOM和工艺路线，是企业内部制造的（如图三中分别指向采购和生产的箭头）。再比如有些物料是纳入库存管理的，有些则完全不纳入库存管理体系。再比如有些库存是项目专用的，而有些是企业统筹计划的。再比如有些库存是有价值的，而有些是不含价值的（或者说只管理物流而不管理价值流），诸如此类。这些都体现了ERP的高可配置性和灵活性。但是由于这个组成部分更多的涉及物流管理，因此本文中我们只选取一种常用的情景，从财务的角度来介绍项目中的物料这个功能。
我们的情景如图四所示，在项目W-100中，活动3100分配给WBS元素W-100.3。在这个活动中需要物料构件W-71600。W-71600是一种公司内部制造的部件，它的BOM包含三种原材料，分别是W-71610，W-71620和W-71630。该项目物料的库存都是项目专用库存。项目专用库存（Project Stock）和统筹库存（Collective Stock）存在以下区别：<1>项目专用库存的物料需求计划（MRP）是分项目运行的，和统筹库存是分开的。<2>项目专用库存除了本项目，不能作其他使用。（当然可以由专门的操作先将项目专用库存转作普通库存。）<3>项目专用库存的生产定单及其成本，采购定单及其承诺等物流过程都可以在项目信息系统中分项目反映。而统筹库存的物流过程是不分项目的，因此只有到最后库存被项目领用才会在项目信息系统中反映，在这之前的过程在项目中是无法反映的。<4>项目专用库存的估价和科目都可以和普通库存分开。此外，该项目的库存都是有价值的，即物流和价值流同步，物料移动会自动产生相应的财务凭证。
在本情景中，已经通过MRP生成了物料构件W-71600的生产定单以及三项原材料的采购定单。我们的介绍从采购定单开始，下文的每一步对应图四中的①-⑥：
1． 采购定单。对于项目W-100的物料需求计划（MRP）为该项目的所有物料以项目专用库存的形式作出计划。MRP的结果之一是对于W-71610，W-71620和W-71630三种原材料的采购申请。采购部门负责供应商选择并将申请转化成采购定单。图五显示了项目信息系统中一种类型的报表，在报表的左侧是项目的结构。我们可以看到由于是项目专用库存，因此生产定单也会在项目W-100的结构中出现。报表的右侧是某个具体格式的传统报表。我们在左侧选择不同的对象，右侧的报表就会显示该对象的信息。
在本步骤，当我们看WBS元素“W-100.3”的“实际/库存/承诺/计划”报表时，结果如下表所示：
成本要素 实际成本 库存 承诺 计划成本
作业成本-人工 0 0 0 0
存货（统计成本要素） 0 0 2,700 0
生产成本-材料 0 0 0 5,700
生产成本-产出 0 0 0 0
总计 0 0 2,700 5,700
在WBS元素“W-100.3”的计划成本中已经包含了物料构件W-71600的成本。同时由于采购定单而产生的承诺（将来的成本）也显示在该报表中。值得注意的是该承诺记录在“存货”这个成本要素上。我们知道存货是一项资产，传统情况下不会出现在成本流中，但是由于在项目管理中，我们需要追踪包括项目专用库存在内的项目价值流，因此我们将存货建成统计成本要素来满足这一需求。
2． 采购定单收货。对于原材料W-71610，W-71620和W-71630的采购定单在本步骤收到货物。采购收货的动作增加了项目W-100的项目专用库存，同时采购定单引起的承诺金额被减少。结果如下表所示：
成本要素 实际成本 库存 承诺 计划成本
作业成本-人工 0 0 0 0
存货（统计成本要素） 0 2,700 0 0
生产成本-材料 0 0 0 5,700
生产成本-产出 0 0 0 0
总计 0 2,700 0 5,700
3． 生产领料。对于W-71600的计划定单被生产部门转化成生产定单。如图四所示该生产定单的目标成本包含3,000元的作业成本和2,700元的原材料W-71610，W-71620，W-71630的成本。这张报表我们在《生产成本》章节已经介绍过了。在图五的报表中，物料构件W-71600和生产定单都显示在WBS元素“W-100.3”下，它们的金额在该WBS元素的报表中被加总了。当该生产定单领取三种项目专用库存W-71610，W-71620和W-71630时，实际成本被计入该生产定单。这次我们在报表左侧选定生产定单，结果如下表所示：
成本要素
实际成本 库存 承诺 计划成本
作业成本-人工 0 0 0 3,000
存货（统计成本要素） 0 0 0 0
生产成本-材料 2,700 0 0 2,700
生产成本-产出 0 0 0 5,700-
总计 2,700 0 0 0
4． 工票确认。本步骤生产定单被确认。由于生产定单实际消耗人工时超过目标，导致实际成本增加250元。作业成本增加到3,250元,总成本增加到5,950元。我们在报表左侧仍然选定生产定单，结果如下表所示：
成本要素 实际成本 库存 承诺 计划成本
作业成本-人工 3,250 0 0 3,000
存货（统计成本要素） 0 0 0 0
生产成本-材料 2,700 0 0 2,700
生产成本-产出 0 0 0 5,700-
总计 5,950 0 0 0
5． 完工入库。本步骤生产定单完成最后确认,完工部件W-71600被验收入库，成为项目专用库存。我们在报表左侧选定WBS元素，结果如下表所示：
成本要素 实际成本 库存 承诺 计划成本
作业成本-人工 3,250 0 0 3,000
存货（统计成本要素） 0 5,700 0 0
生产成本-材料 2,700 0 0 8,400
生产成本-产出 5,700- 0 0 5,700-
总计 500 5,700 0 5,700
6． 发货到项目。本步骤我们将部件W-71600发给项目W-100的活动3100使用。这将减少项目专用库存。同时该部件的实际成本计入网络活动。我们在报表左侧选定活动3100，结果如下表所示：
成本要素 实际成本 库存 承诺 计划成本
作业成本-人工 0 0 0 0
存货（统计成本要素） 0 0 0 0
生产成本-材料 5,700 0 0 5,700
生产成本-产出 0 0 0 0
总计 5,700 0 0 5,700
项目的收入和现金管理
对于客户项目，除了成本，项目还会产生收入。ERP可以通过销售模块和项目系统模块的集成自动复制销售定单至项目收入计划。同时如果销售定单应用了开票计划（Billing Plan）功能，开票的日期也将纳入计划中。收入计划同时也可以显示销售折扣，折让和其他销售扣减项目。当然，除了集成我们也可以直接手工做项目收入计划，或者直接将开票计划维护在WBS元素上。
开票计划是分次开具发票的计划。在开票计划中，我们详细维护每次开票的日期，开票的百分比和金额，是否冻结和相关的项目里程碑等等信息。里程碑开票在客户项目中被广泛采用。系统将根据项目进度的任何变化自动调整收入计划。当相关的项目里程碑被确认时，系统可以自动将开票计划中的某次开票释放。开票计划还可以包括预收款，当然预收款只影响项目收付款而不影响收入。当预收款释放后，系统可以生成预收款请求，和发票一样可以打印出来递交给客户。随后收到的预收款会指向相关的请求，并将它清帐。
我们可以结合本章已介绍的内容，设计出这样一个销售流程：客户询价（Inquiry）=> 分配和定义项目结构 => 项目成本计划 => 按成本加成法报价（Quotation）=> 销售定单 => 项目收入计划。
项目的实际收入将在销售定单实际开票时由系统自动记录到相应的项目中。比较特殊的是资源相关定价的项目（或称为成本补偿项目）。在这种项目中，客户同意付给承约商所有实际花费的成本（劳动力，原材料等等），加上一定的协商利润，而不是规定数额。对于这种项目系统提供了特殊的功能：自动计算项目成本，将成本按一定规则分类，各类成本按协商利润加成后确定销售定单的开票金额，最后开票。这个流程其实使用了和上文销售流程同样的工具，我们称为销售定单行项目的动态处理，本文不作赘述。
和收入成本一样，现金流也是我们在项目管理中关心的问题。除了手工计划项目的收付款，系统可以利用大部分收入和成本的计划工具来计划现金流，如开票计划，发票接收计划等等。在计算日期时系统会将客户和供应商的付款条款等因素考虑进去。项目现金管理也使用了《资金管理》章节中科目分层的概念。
期末结帐
项目系统管理模块的期末结帐是项目财务管理的重头戏。有些步骤和其他模块是类似的，比如流程成本分配到项目（ABC成本法），间接费用法（用成本核算单分配间接费用）等等成本流的期末结转和项目利息的计算。我们在本书的相关章节都已做过介绍。对于项目管理来说还有些有特殊性的期末结帐活动。
成本预测和进度分析（Progress Analysis）
项目开始执行后，进度和实际成本都可能和计划偏离。成本预测是在项目执行过程中不断计算和调整完成项目剩余部分预计将要发生的成本。成本预测的数据基础是：计划成本，实际成本，承诺，确认的预测完工日期和完工工作量。图八显示了计划成本，实际成本和预测成本这三者的关系。预测成本的数据在系统中保存在一个特殊的计划版本中。我们可以用这个特殊版本编制层次结构报表或成本要素报表。
从图8中，我们看到，虽然该项目的实际成本发生低于计划。但是从预测成本来看，成本暂时低于计划很有可能是项目进度拖后造成的。所以仅仅孤立地检查项目的成本，资源和进程是无法有效控制项目的。我们需要更有意义的信息来分析项目到目前为止的进展情况和健康状态。进度分析（Progress Analysis）正是实现这一目的。ERP中的进度分析使用的是项目管理理论中的实现价值分析（Earned Value Analysis）方法。
我们首先需要计算完工比率（POC，Percent of Completion）。我们可以人为估计WBS元素，活动和活动元素的POC，或者可以由系统根据已有数据自动计算。系统总共提供了九种确定POC的方法：开始/结束规则；估计；里程碑技术；时间比例法；成本比例法；数量比例法；进展程度法；次级比例法（或相关比例法）；用户出口（允许用户自定义规则的程序出口）。我们需要计算两个POC：计划POC，指在指定时间点上预计的完工比率；实际POC，指在指定时间点上实际的完工比率。随后，通过某种权数（通常是计划成本），我们可以汇总整个项目结构的所有POC，计算出整个项目的POC。
接下来，我们利用POC来计算如图九所示的一组关键指标：
BCWS：Budgeted cost of work scheduled， = 总计划成本 * 计划POC。反映的是按照计划到今天应该产生了多少成本。
BCWP：Budgeted cost of work performed，= 总计划成本 * 实际POC。反映的是根据到目前为止的项目进度，应该产生多少成本。或者说到目前为止干的活值多少，不过这个值多少仍然是成本的概念，不能和收入混淆起来。
SV：Schedule variance 进度差异，= BCWS – BCWP。反映了项目进度落后计划多少，它告诉我们我们的项目是否太慢了。
CV：Cost variance 成本差异，= 实际成本 – BCWP。反映了项目是否超支了，它告诉我们我们的项目是否太昂贵了。
通过SV和CV两个差异的分离，我们可以解释项目目前的进展情况以及项目的健康状况。
结果分析（Results Analysis）
我们在《成本流和成本对象》章节中提到，结果分析是一种类型的“由内至外的过帐”。项目管理中的结果分析解决的究竟是什么问题呢？在长期的客户项目中，日常收入和成本的的入帐都跟相关的业务处理相联系，比如开票，发票校验等等。但是这样的收入和成本数据很多情况下是不能满足会计的权责发生原则和配比原则的。因此根据实质重于形式的原则和各国关于长期项目收入和成本核算的相关准则，我们需要对项目在各会计期间的收入和成本数进行调整。结果分析就是根据事先设定的规则，自动计算相关会计期间实际应确认的项目收入和成本，并自动生成调整分录的系统功能。
新近定单（Incoming Orders）
对于某些围绕客户项目运转的公司，新签定的项目和进行中的项目对于预测公司将来的盈利前景具有重要意义，这对于以长期和超长期项目为主的公司来说由为重要。新近定单（Incoming Orders）和未完成定单（Open Orders）是这方面的两个重要指标。新近定单是考虑了定单更改，定单取消和计划更改等历史因素后的新签定和进行中定单的价值。未完成定单价值是新近定单减去已确认的收入和成本后的价值。ERP可以根据项目管理系统和销售模块的数据，自动计算出类似下表的报表：
收入 成本 利润 利润率%
新定单 -940 460 -480 51
定单更改 -280 50 -230 82
定单取消 20 -12 8 -40
计划更改 0 80 80 -50
总新近定单 -1,200 578 -622 51
已开票 -600 400 -200 33
未完成定单 -600 178 -422 70
其中计划更改是由于项目成本结构改变后引起的利润降低。
结算
项目的结算和内部定单的结算在基本概念上是一致的。只是由于项目具有复杂的结构，因此在结算时整个结构的不同部分（各WBS元素和活动）的结算规则是一个特殊的问题。首先，是结算规则的决定。WBS元素的结算规则可以通过不同的策略决定。比如对于客户项目往往会对开票的WBS元素先做结果分析。结果分析的数据包括了其下层WBS元素和活动/定单的成本和收入。因此只有开票的WBS元素被结算。结算规则只维护在开票的WBS元素上。这种结算规则很可能是根据开票WBS元素和相连的销售定单决定的市场细分。其它的对象的结算规则都定为“不结算”。再比如对于成本项目，系统可以从各WBS元素的负责成本中心或申请成本中心生成结算规则。或者还可以让下层的WBS元素继承上层WBS元素的结算规则等等。对于网络/活动，我们可以定义一个包含若干优先次序的“结算规则决定策略”。比如活动的结算规则依次<1>从其分配的WBS元素中继承。<2>从项目定义中继承。<3>按缺省规则自动生成。<4>手工维护等等。其次，从结算的顺序上，也有多层上卷后统一结算和分别直接结算两种。
软件开发项目中如何使用范围变化管理
项目管理过程不从确定项目开始，也不随着项目计划完成而告终。你必须要在项目管理过程中使用范围变化管理，如果你不善用此一技巧，那麻烦将是不可避免的。
确定并计划项目仅仅是成功的项目管理过程的第一步。在制定出计划之后，你还必须要将计划付诸实施。你必须要保证计划任务在规定的时间内完成，而且不能超出原有的预算。一旦项目开始进行，客户可能会向你提出更多的或是与原计划不同的要求。在这个时候范围变化管理就可以派上用场了。如果你不善用此一技巧，项目小组就只能尝试着在项目时间和预算不变的情况下去完成比原计划多得多并且要耗费更多成本的任务。换句话来说，就是麻烦将是不可避免的。
范围管理从范围界定开始
对项目范围进行界定恐怕是确定项目的过程当中最为重要的组成部分。事实上，如果你并不能确定项目的目标任务，也不能确定项目的范围，项目就根本不可能成功。范围管理是项目管理过程当中最为关键的组成部分之一。但是，如果不能对项目的范围作出成功的界定，想要实施范围管理也几乎是不可能的。
界定范围的目的是清楚描述项目的逻辑范围并在此问题上同有关各方达成一致。对项目范围的陈述可以让大家清楚的了解哪些工作是项目范围之内的事情，而哪些工作不属于该项目范畴。对项目范围的界定越明确，对项目就越有利。下面这些信息应该能起到一些帮助作用。
范围内和范围外的任务类型（业务需求、现状评估）
范围内和范围外的生命周期流程（分析、设计、测试）
范围内和范围外的数据类型（财务、销售、员工）
范围内和范围外的数据来源或数据库（账单、公司总帐，薪水明细）
范围内和范围外的部门（人力资源、制造商、供货商）
范围内和范围外的主要功能（决策支持、数据输入、管理报告）
制定可行的范围变化流程
项目经理和项目小组的成员都必须意识到，项目范围的变化本身并没有错。也就是说，在项目的进行过程中改变项目范围并不是一件坏事。事实上，在很多情况下，这还是一件好事。首先，客户通常都不能在项目开始之前明确所有的需求。其次，即使他们能够做到这一点，整个的商业环境也是在不断变化的，所以项目需求也可能会随之而发生变化。
如果你不能够适应变化，项目的最终价值可能会受到影响，或者可能会使项目失去价值。因此，你需要具备在项目进行的过程当中根据需要作出改变的能力。如果项目经理不能够在项目进行过程当中积极的对变化进行管理，问题可能就会随之而来。任何项目都应该有一个有效的变化管理流程。这个流程应该包括对变化的识别判断，对变化的商业价值的判断，对变化会给项目带来的冲击和影响的判断，将相应的信息提交项目投资人进行评估。项目投资人来最终决定是否将变化引入到项目当中。如果变化被引入项目，项目投资人还应该考虑变化对项目的影响程度，并且为之配备相应的额外资源，如延长时间和追加资金预算等。
范围变化管理常见问题
在范围变化管理的过程当中，项目小组可能会遇到很多常见的问题。
项目范围蔓延：很多项目经理都能够意识到大的范围变化，但是对小的范围变化就不那么细心了。因此在实际工作当中就往往有这样一种趋势，很多项目经理没有经过太多的思考就把新的工作增加到了项目当中。我们所说的项目蔓延就是指一个项目接受了很多小的变化的情况。当这些小的变化都聚合到一起的时候，项目小组才意识到他们承担了太多的超额任务，已经无法按照原有的时间和预算框架来完成项目了。
得不到投资人的批准：很多时候，项目经理会面对来自终端用户、股东或是客户经理的一系列变化要求。由于这些人都属于客户范围，所以他们的要求通常都被认为是应当被接受的。实际上这是一种错误认识。终端用户通常只能提出范围变化的要求，但却没有批准的权力。即使是客户经理也没有批准的权力。真正拥有这种权力的只有一个人，那就是这个项目的投资人（除非该资助人已经授权给了他人）。很多项目会遇到麻烦，就是因为大家都以为项目范围的变化能够得到批准，而事实上真正拥有决定权的投资人并不同意这样做。
项目小组负的责任：项目小组的成员有很多的机会同客户进行互动交流，他们所接到的范围变化要求也就最多。因此，整个项目小组都必须理解范围变化管理的重要性。所有小组成员都必须及时发现项目范围的变化并将其报告给项目经理。如果他们把所有的额外工作都自己承担，就很可能造成无法按时完成任务的结果，从而危害到整个项目。
现在开始永远不晚
如果你发现自己负责的项目正在日益偏离原有的时间和预算框架，那么赶紧找找原因。在很多情况下，你会发现问题仅仅在于你的项目小组承担了比原计划要多的任务。界定范围变化管理过程的最佳时机就是在项目开始之前（作为项目管理流程的一个组成部分）。但是，如果没有一个好的项目管理流程，也没有关系，现在开始永远都不会晚。
其实，在发现了问题之后再补救也有好的一面。因为问题已经出现了，项目小组和客户就已经明白了没有对范围进行控制会对项目产生的不利影响。那么他们就能够更好的理解范围变化管理的目的和意义，能够在今后的项目进行当中给予更多更好的配合。
随着我国IT行业的日益发展和不断进步，各个IT企业已经开始陆续引进并开始实施了“项目经理制”的管理模式，即：按照其所负责行业或业务系统的不同，成立多个事业部（如：电信事业部、金融事业部、税务事业部……），各个事业部只负责其所属行业内的项目和工程。每个事业部内部按照不同的项目成立项目组，并且会确定相应的项目经理，以对其所负责的整个项目的全过程负责。
“项目经理制”的引入，本应该促进企业项目实施和管理的标准化，以及提高企业的生产效率和项目实施质量。但是，就其目前的现状而言却并不乐观，多种不利因素限制和制约了项目管理的良性发展。
现在，就我在进行项目管理工作中，所遇到的问题，将目前项目管理的现状和问题描述如下：
1、 项目经理与项目严重脱节，导致项目实施严重失控。当前，在进行项目组组建过程中，出于多种考虑，项目经理的头衔很多时候是落在了企业的老总，或是各事业部的总经理的头上（此现象尤其是在重大项目中尤为突出）。这些老总们多数时间是在忙于其他事务，而无暇或者不能全部时间关注项目的实施和进展工作，无法真正行使项目经理的权利。并且，其他的项目组成员没有足够的权力去管理和协调项目工作。这样就导致了项目的失控，项目进展中遇到的问题无法被及时暴露和解决，最终致使项目失败。
2、 项目组无法统一目标和方针，导致项目组工作效率低下。由于多数项目的实施，要涉及的多个部门的协同配合，即项目组成员会由各个不同的部门同事组成。而项目经理没有足够的权力协调其他部门的组员的工作，而且，由于项目组是临时机构，这导致了项目组成员对项目组的无视，他们往往更加乐于按照部门负责人的安排工作，而不是项目经理。甚者会出现在项目实施期间，某部门突然将项目组中的人员抽调走，而导致项目停工或工期延误等后果。
3、 项目经理的责任过大，权力过小，导致其工作畏首畏尾。很多项目一旦确认项目经理后，项目经理就要对整个项目负全部的责任，但是与其不成正比的是，项目经理的权力却是极为有限，根本无法足以保证项目工作的正常开展。项目经理的责任和权力的失衡，严重的影响了项目工作的正常开展，使得项目经理在工作中无法发挥作用而又害怕因失误而带来的直接责任问题。由这样的项目经理领导的团队，注定其无法完成项目工作。
4、 授权模糊或没有授权，致使项目经理对其工作职权概念模糊。为了达到某种目的而创立了团队。企业可能会向项目经理"授权"。但是通常是很模糊的，即项目经理为达到既定目的可以在某种程度上采取一切必要的行动。但也可能企业没有这样授权。对此项目经理要么感觉手中无权，无法开展工作；要么就搞不清自己职权到底是什么。不管怎样，这样的团队往往是要失败的。
5、 公司没有按照项目进行利益分配，项目工作没有积极性。由于公司没有基于项目进行利润分配的模式，即企业还在吃大锅饭，项目组成员无法看到项目成功与否对自己带来的直接效益，项目经理更是无法从正常的利益方面激励项目成员的工作积极性，某种程度上还要靠项目成员发扬风格或是项目经理与项目成员的私人关系才使项目得以正常实施，这使得项目实施工作举步为艰。
形成上述现状的原因是多方面的，主要表现在以下几个方面：
· 企业制度不健全
目前国内IT企业的项目管理组织形式一般都属于弱矩阵或平衡矩阵类型的，职能部门和项目管理层还处于"磨合期", 工作效率较低下，另外，沟通复杂本身就是矩阵型组织的突出特点。看来，建立基于项目管理的现代企业制度，还有一个漫长而艰苦的过程。
· 项目经理制的在企业中没有具体切实落实
在目前IT行业企业的编制中，项目经理部仍是可有可无的，项目经理多数情况是由职能部门人员“客串”或是兼职的。在企业中，很难找到专职的项目经理。而且，目前的项目经理大都被定义为“传声筒”，一般没有真正意义上掌握人、财、物大权的项目经理。
· 项目经理自身的原因
1 项目经理缺乏项目管理方面经验；
2 项目经理不懂项目所必须技术，是个技术外行；
3 项目经理没有足够的应有的权力；
4 关键性文件没有被及时的制定、颁发，甚至项目经理制定的有些文件是错误的；
5 项目经理没有全局观念，把注意力过多地放在自己熟悉、喜欢的部门或单位。
如果要解决上述问题，最根本的途径是认清项目经理的地位和作用，重点是正确界定项目经理的责权利。
一 项目经理的地位和作用
项目管理的组织的特征是严格意义的个人负责制，个人负责制的核心人物必然是项目经理。所以项目经理是决定一个项目成败的关键人物。项目经理是项目实施的最高领导者、组织者、责任者，在项目管理中起到决定性的作用。成功的项目应该是使项目任务能够按照既定的计划和要求完成，以及项目成果能使本企业组织成员项目组中的主要成员、最终用户或委托人感觉高度满意。最终给企业创造效益。
项目经理是项目有关各方协调配合的桥梁和纽带，处在上下各方的核心地位。项目管理说到底是人的管理与协调。负责沟通、协商、解决各种矛盾、冲突、纠纷的关键人物是项目经理。他对项目行使管理权，也对项目目标的实现承担全部责任。他所扮演的角色是任何其他人不可替代的。项目经理作为企业委派在项目管理上的代表，按合同和约履约是他一切行动的最高准则，拒绝承担合同以外的其他各方强加的干预、指令、责任是他的基本权力。项目经理是项目信息沟通的发源地和控制者，在项目实施过程中，来自项目外的重要信息、指令要通过项目经理来汇总、沟通、交涉，对项目内部，项目经理是各种重要指标、决策、计划、方案、措施、制度的决策人和制定者。
二 项目经理的责、权、利
(一) 项目经理的职责
1.确保项目目标实现，保证用户的满意。这项基本职责是检查和衡量项目经理管理成败、水平高低的基本标志。
2.制定项目阶段性目标和项目总体控制计划。项目总目标一经确定，项目经理的职责之一就是将总目标分解，划分出主要工作内容和工作量，确定项目阶段性目标的实现标志如形象进度控制点等。
3.组织精干的项目管理班子。这是项目经理管好项目的基本条件，也是项目成功的组织保证。
4.及时决策。 项目经理需亲自决策的问题包括实施方案、人事任免奖惩、重大技术措施、设备采购方案、资源调配、进度计划安排、合同及设计变更等。
5.履行合同义务，监督合同执行，处理合同变更。 项目经理以合同当事人的身份，运用合同的法律约束手段，把项目各方统一到项目目标和合同条款上来。
(二) 项目经理的权力
1.指挥权 项目经理有权按项目相关合同的规定，根据项目随时出现的人、财、物等资源变化情况进行指挥调度，对于项目工程组织设计和网络计划，也有权在保证总目标不变的前提下进行优化和调整，以保证项目经理能对项目实施过程中出现的各种变化应付自如。
2.人事权 项目经理应有权对项目组的组成人员进行选择、考核、聘任和解聘，有权根据项目需要对项目组成员进行调配、指挥，并且有权根据项目组成员在项目过程中的表现进行奖励和惩罚。
3.财权 项目经理必须拥有项目范围内的财务决策权，在财务制度允许的范围内，项目经理有权安排项目费用的开支，有权对项目预算内的款项进行安排和支配，并且，在项目实施期间，项目经理应有权在工资基金范围内决定项目组内部的计酬方式、分配方法、分配原则。对风险应变费用、赶工措施费用等都有使用支配权。
4.技术决策权 主要是审查和批准重大技术措施和技术方案，以防止决策失误造成重大损失。必要时召集技术方案论证会或外请咨询专家，以防止决策失误。
5.设备、工具、材料的采购与控制权 在企业有关规定的范围内，项目经理应有权决定项目相关设备、材料的采买时间及数量，对项目相关的设备、工具、材料等有权按质量标准检验后决定是否用于本项目。但项目相关主要设备的采购权不宜授予项目经理，否则可能影响公司的效益，但由采购部门采购设备必须按时、按质、按量，否则项目经理有权拒收或采取其他措施。
（三）项目经理的利益
目前，在国内IT企业中，因项目经理的权限较小，责任较大，而且多数企业都没有对项目经理的工作绩效进行深入评测，并且与其直接利用挂钩，这使得项目经理经常是付出的多，得到的少，久而久之，工作积极性下降。要明确项目经理的利益，改隐性收入为显性收入。 企业应该对项目经理按照项目进行独立核算，改变过去那种只干不算。按照项目实施质量和最终结果，从项目利润中提取一定比例作为奖励基金，由项目经理按规定分配。
项目经理的最终利益是项目经理行使权力和承担责任的结果，也是市场经济条件下责、权、利相互统一的具体表现。项目经理除按规定标准享受企业制定的工资和奖金外，如果其负责项目的各项指标和整个项目都达到既定的要求，应该在项目终审赢余时按利润比例提成予以奖励。
如果项目经理所负责项目未按合同要求完成，可根据项目具体的情况，扣发全部项目奖金。如属个人责任，致使项目工期拖延、成本亏损或造成重大事故的，除扣发全部项目奖金外，可处以一次性罚款并下浮工资，性质严重者要按有关规定追究责任。
综上所述，项目经理是对项目管理全面负责的管理者，也是施工项目的管理中心，明确项目经理的责、权、利，并在项目管理中落到实处，是企业挖掘内部潜力;获取最大利润"的根本途径；是项目能否成功及项目管理目标、成本目标能否实现的关键。
如今，伴随了IT业技术的日新月异的发展与更新，其项目管理规范化进程也在加速发展。“项目经理”这个年轻的职业正在IT企业中发挥越来越重要的作用。当今企业的发展呼唤好的项目经理，但是更重要的是我们更加需要适合于项目经理发挥能量的舞台和能够培养更多更好的项目经理的温床。
在技改项目的项目管理、实施过程中，不仅是项目经理，与项目相关的各方面人员都越来越注意到项目进度的重要性。那么如何控制项目进度。以下是个人的一些建议，供参考：
1、项目负责人或项目经理一定要对整个项目的周期有一个清楚的了解。根据项目不同阶段的的不同特点，把任务按阶段划分。对于每一阶段的任务都要有明确的目标和成果；都要明确各项任务的责任部门以及责任人。这样，责任部门以及责任人对项目阶段各项任务和目标以及成果是明确的，对时间进度的要求也是明确的。项目经理所要做的就是：密切跟踪各项任务的进展情况，时刻与项目的总体进度进行对照。及时发现问题，及时协调与解决问题以保证项目沿着正常的轨迹运行。
2、沟通和交流。作为项目经理或项目负责人，与项目相关各部门以及有关人员沟通、交流是其最基本的工作内容。而沟通与交流也是保证项目进度得到有效控制的基本要素。许多在项目中遇到的问题，对当事者来说也许是很困难的，可是通过沟通与交流，通过相关部门的帮助，往往可以很顺利地得到解决。沟通与交流有助于及时发现问题并及时得到解决；有助于调动项目团队成员的积极性；有助于加深对项目的理解和消除误会。
3、抓重点、攻难点。每一个项目，都有其不同的特点。要有效地控制好项目的进度，找到项目的重点、难点并全过程得到有效的控制与解决是关键。项目经理在起始阶段就要对项目难点、重点有一个预判，前期做好充分的准备，做好必要的预案。在项目实施过程中，始终抓好重点、难点的管理，周密计划、认真实施。抓住了重点、解决了难点，项目的成功就是自然而然的结果了。
4、做好项目的总结。要善于在项目管理过程中以及项目完成后做好总结。及时的总结有利于发扬成功的经验；有利于及时纠正工作中的不足；有利于项目团队整体素质的提高。对于本项目来说，及时总结是纠正错误，控制进度的有力保证。对于后续项目来说，已完成项目的经验教训，对减少项目管理的出错，提高项目管理的精度具有良好的借鉴作用。
以上几点，希望对您能有所帮助。
1980年代末,美国安达信顾问公司(现改名为埃森哲Accenture)为了加强其核心IT业务,开始雇用新的专业策略顾问。这些顾问比安达信员工更有经验,而且习惯于比安达信现有IT员工享受"更有刺激性的个人业绩奖励"。
沃顿管理学教授莎拉·凯普兰(Sarah Kaplan)与麻省理工斯隆管理学院的蕾贝卡·韩德森(Rebecca Henderson)共同撰写了一篇论文:"惰性和激励:组织经济学和组织理论的相结合"(Inertia and Incentives: Bridging Organizational Economics and Organizational Theory)。
安达信与柯达的教训
论文中指出,当安达信这些新雇用的"明星员工"要求得到他们在以前公司的收入水平时,老员工就产生了抱怨。毕竟,现有的工资系统"已经通过对新雇员的大量培训和社交活动后得到了加强"。改变这一工资系统的努力,由于"安达信公司内没有人知道新的业务应该如何运作,或者怎样才能成功而变得复杂"。
安达信对现有的激励系统进行了一些变动,认为既可以满足新员工的期望,而且不会疏远老员工。同时,还试图将新员工塞进现有IT员工的架构中。但这些努力都不成功,许多新员工离开了公司。安达信建立新业务的努力出师不利。
凯普兰说,柯达在转向数码摄影的时候,遇到了类似的问题。数码摄影是一个非常不同的商品,其所要求的不仅仅是"从化学到数码的技术能力的转变",同时还需要一整套新的商业模式。但是,高级经理们并没有这样看待这一问题,他们不认为数码业务需要根本的改变,包括新的技术和经理人。相反,柯达试图发展一种混合的商业模式("以胶片为基础的数码图像"和图片光碟)。凯普兰和韩德森在她们的报告中指出,很多人认为这一策略"是失败的,而柯达最终建立了独立于传统摄影部门的数码影像部门"。
凯普兰说,这两家公司的共同点是"在对新业务前景的理解和如何给予员工报酬之间存在着矛盾冲突,以致最终无法建立起能够抓住新机会的那类组织"。
凯普兰和韩德森的研究重点是:究竟是什么原因导致这些矛盾得以产生和发展,并以激励机制为切入点。
凯普兰说,经济学家倾向于认为如果你改变了激励体系,企业也会随之改变。但事实上,改变激励体系并不是直截了当的,尤其是当企业试图对一项新技术或市场变化做出反应的时候,这种不确定性就更大了。在这些情况下,必须考虑到"经理人对市场情况的’诠释过程(interpretative processes)’,也就是他们的’认知框架(cognitive frames)’。激励体系和这些经理的诠释是紧密相连的"。
凯普兰说,人们通常将激励体系定义为"经理人让人们完成工作的东西"。在很多企业中,激励不仅仅指薪水,还包括奖金、福利、私人办公室、奖章、上级的表扬、升级以及加入重要的项目等。"从商业媒体上我了解到现在的企业试图更多地使用非薪水类的激励方法,比如股权。但是不论企业拥有怎样的激励机制,都会遇到同样的问题。比如,有些公司发现当他们为员工提供更多的股权,但减少薪水时,员工反对这一改变。在很多企业里,员工只相信旧的激励方式。"
凯普兰以她自己为例。"作为一个大学教授,除非我亲眼见到这个大学在过去的历史中有很多满足某些条件的教授得到了终身职位,否则我不会相信我会得到终身职位(tenure)。但当情况发生变化时,这类历史纪录就没有了。人们不知道是否要相信这个新的激励体系。"凯普兰说,在这类情况下,"对市场的诠释或认知框架将会很大地影响雇员如何理解他们应该做什么,以及何种激励能够鼓励这些行动"。
建立新契约的挑战
凯普兰和韩德森的论文尤其关注成功公司在试图为新的投资建立合适的激励体系时所面临的限制。她们认为,首先"激励非常有可能基于评估,而这类评估取决于如何诠释"。
两位写道,所有衡量标准"都可能非常模糊。这些标准的意义只能随着时间慢慢呈现出来"。
她们还提出在一个成功企业中,激励体系有可能"在一系列关系型契约(relational contracts)中得到实现"。关系型契约是指那些不能以书面形式记录,但企业由于担心不履行这一契约可能的后果而不得不执行的约定。这类契约的建立需要数年时间,并且是基于对契约条款的共识。而员工也能够信任企业将会遵守这些条款。
除了进行外部调查,凯普兰和韩德森还采访了企业员工,以了解他们的企业为什么在面对变化时这么困难。两位指出:"人们给了我们很多原因,比如公司选错了目标消费者,或投资了错误的技术。这些原因可能是正确的。"
凯普兰和韩德森还研究了企业为何无法应对"结构"创新。由于企业继续依赖"从以往的产品中积累的经验,例如思维模式和解决问题的策略而造成了应对创新的困难。结构创新不仅要求新的认知框架,并要求新的激励"。
有些人认为激励方式变化之所以困难是由于公平的问题。两位作者引用其他研究结果,认为企业内部规范让企业很难为一个新部门的员工提供比现有员工高出很多的激励。然而凯普兰和韩德森认为仅用公平问题不能解释"很多新分支的激励政策与其母公司这么相似。比如,通常销售部门的员工比其他员工的酬劳要高很多。这一差别引起的矛盾相对很小,因为其他员工认同了销售工作是不同的,是困难的而且不愉快,或者只是认为销售员需要不同类型的酬劳来不断鼓励他们"。
凯普兰和韩德森认为,很多人只是假定如果世界变了,"企业需要根据一套不同的主观评估进行奖励,它只需要宣布这一变化。员工们就会知道公司实行新契约是理性的,而公司也知道员工会做出相应的表现。双方可以平稳地进入新的平衡状态,而改变也将没有问题。"
但"在一个混乱的世界中的真实企业并不是这样的。当一个大变化发生时,在企业和员工之间需要建立一个新的契约(激励系统)"。
建立契约面临三个挑战。
首先,要明确员工在没有获得酬劳时可能会怎么做,或者说其真正的利益所在。这是一个复杂的过程。
第二,行动和有用的结果之间的联系存在着巨大的不确定性。在一个现代企业中,任何一项任务,即使是不太复杂的任务,管理层对这些联系的理解最多也是一个部分的,不完整的模型。这一模型是根据多年的个人经验而慢慢形成的。当面对一个完全新的商业机会时,这种模型可能根本不存在。
第三,随着情况变得越来越不稳定,越来越模糊,员工所关心的事也越来越不清楚。而公司也越来越不可能轻易获得这一信息。员工可能对所得到的奖金做出意想不到的反应……这一问题经常由于企业对如何奖励按照新要求工作的员工没有经验而加重。这使得经理及其员工没有了一个熟悉而有效的关系型契约。
企业考虑通过在新部门实行新的员工激励系统来实现这一转变。但两位作者指出,在这种情况下,虽然经理认识到彻底改变过的激励系统可能会鼓励员工追求高风险的技术改革,但他们通常会产生迟疑,而不执行新的激励系统。"因为如果这样做的话,他们将会违反与老员工之间现有的关系型契约。"这将对激励政策造成"选择性干预(selective intervention)"。这样的政策必将失败,因为整个系统不能和新的环境相匹配。
传统的升职方式
两位作者说,所有这些原因让在新环境中运作的新企业很难建立激励机制,但对于成功的公司而言,就更加困难了。现有的激励机制在很多年的实施过程中,逐步"植根于员工和雇主的认知框架以及企业的日常运作和流程中。
……我们觉得评估和奖励员工可能要比学习如何工作本身还要困难,因为努力和成果之间总存在着一定的距离"。
事实上,一个成功企业的高级经理很可能借助其从多年工作经验中获得的直觉,就可以有效地评估其下属的工作。"很多高级经理本身可能就是凭借这种能力,以及他们对工作的了解得到升职。两种能力同样重要,因为经理的基本工作就是评估和奖励他们的下属。"但这可能对预测或发现市场变化造成影响。"经理以某种特定方式看待某件事的部分原因是他们的过去以及现在的激励机制。如果随着时间的推移,经中的认知框架,那么他们就有可能拒绝接受那些可能会引起环境彻底改变的信息,并将其作为不重要的信息处理。"
由于企业家面对着一个全新的市场和全新的技术,"或者说当他们需要评估一名管理着高风险、快速增长部门的经理时,原来对于什么才算是有效投入的直觉可能就不正确了"。
另一个问题就是员工和雇主可能对新的激励政策产生不同的理解。"不同的理解可能使员工感到受了欺骗,而经理则相信他们完全在按照政策工作。"同时,经理可能会觉得因为新技术和新工作内容太复杂,还不如对新部门实施现有的激励政策比较简单。
所以,"使用主观衡量标准和默认契约鼓励企业做一件事,可能会使企业很难完成另一件事(比如进行根本的改革)。正如有些学者提出的,如果工作程序是企业内部的停战协定,而如果这些停战协定包含了某些业务认知框架以及一套鼓励以该认知框架为基础进行工作的激励机制,那么任何对框架或对激励机制的改变都将会导致停战协定的崩溃"。而这将导致错误的努力方向以及最终的失败。
建立新模型
根据以上的内容可以得出结论,"首先,无论是默认的认知、准则或程序都不仅仅是个人学习如何工作的认知过程的产物,还是每个人学习何种行为可能得到奖励的、与激励机制有关过程,都是公司的工作程序。这就是激励政策的作用——’我这样做事,因为这样对我最有利。’这一作用不能明确地与认知分离:’我这样做因为我相信应该这样做。’事实上,认知和激励两者在一个复杂的、互相作用的过程中同时形成。"
第二,当一个企业开始采用一种全新的技术时,"所面临的困难是认知的也是与激励有关的。认知困难是’我们知道这样做不行,而且我们怀疑,即使这样做了也赚不到钱’。与激励相关的困难是’就算我学了你也不会付我钱’。这是因为认知框架和激励机制在一个企业中的关系非常紧密。想改变其中一个,必定会让另一个发生变化"。
"在处理变化时,要重视认知框架和激励机制在企业中的植根深度。植根越浅,就越有可能出现不同的观点(能够更好地接受根本的技术变化的观点)。然而,一个植根很深的体系也有自己的优势,可以使决策变得方便,并能够有效执行策略。"
这个模型将"激励机制和认知框架视为一个企业中两个互相联系的部分。当认知框架和激励机制深植企业内部时,旧模式会保留下来。然而……当经理改变了两者之间的关系的时候,改变是可能的"。
在范围变化管理的过程当中，项目小组可能会遇到很多常见的问题。
项目范围蔓延：很多项目经理都能够意识到大的范围变化，但是对小的范围变化就不那么细心了。因此在实际工作当中就往往有这样一种趋势，很多项目经理没有经过太多的思考就把新的工作增加到了项目当中。我们所说的项目蔓延就是指一个项目接受了很多小的变化的情况。当这些小的变化都聚合到一起的时候，项目小组才意识到他们承担了太多的超额任务，已经无法按照原有的时间和预算框架来完成项目了。
得不到投资人的批准：很多时候，项目经理会面对来自终端用户、股东或是客户经理的一系列变化要求。由于这些人都属于客户范围，所以他们的要求通常都被认为是应当被接受的。实际上这是一种错误认识。终端用户通常只能提出范围变化的要求，但却没有批准的权力。即使是客户经理也没有批准的权力。真正拥有这种权力的只有一个人，那就是这个项目的投资人（除非该资助人已经授权给了他人）。很多项目会遇到麻烦，就是因为大家都以为项目范围的变化能够得到批准，而事实上真正拥有决定权的投资人并不同意这样做。
项目小组负的责任：项目小组的成员有很多的机会同客户进行互动交流，他们所接到的范围变化要求也就最多。因此，整个项目小组都必须理解范围变化管理的重要性。所有小组成员都必须及时发现项目范围的变化并将其报告给项目经理。如果他们把所有的额外工作都自己承担，就很可能造成无法按时完成任务的结果，从而危害到整个项目。
现在开始永远不晚
如果你发现自己负责的项目正在日益偏离原有的时间和预算框架，那么赶紧找找原因。在很多情况下，你会发现问题仅仅在于你的项目小组承担了比原计划要多的任务。界定范围变化管理过程的最佳时机就是在项目开始之前（作为项目管理流程的一个组成部分）。但是，如果没有一个好的项目管理流程，也没有关系，现在开始永远都不会晚。
其实，在发现了问题之后再补救也有好的一面。因为问题已经出现了，项目小组和客户就已经明白了没有对范围进行控制会对项目产生的不利影响。那么他们就能够更好的理解范围变化管理的目的和意义，能够在今后的项目进行当中给予更多更好的配合。
随着我国IT行业的日益发展和不断进步，各个IT企业已经开始陆续引进并开始实施了“项目经理制”的管理模式，即：按照其所负责行业或业务系统的不同，成立多个事业部（如：电信事业部、金融事业部、税务事业部……），各个事业部只负责其所属行业内的项目和工程。每个事业部内部按照不同的项目成立项目组，并且会确定相应的项目经理，以对其所负责的整个项目的全过程负责。
“项目经理制”的引入，本应该促进企业项目实施和管理的标准化，以及提高企业的生产效率和项目实施质量。但是，就其目前的现状而言却并不乐观，多种不利因素限制和制约了项目管理的良性发展。
现在，就我在进行项目管理工作中，所遇到的问题，将目前项目管理的现状和问题描述如下：
1、 项目经理与项目严重脱节，导致项目实施严重失控。当前，在进行项目组组建过程中，出于多种考虑，项目经理的头衔很多时候是落在了企业的老总，或是各事业部的总经理的头上（此现象尤其是在重大项目中尤为突出）。这些老总们多数时间是在忙于其他事务，而无暇或者不能全部时间关注项目的实施和进展工作，无法真正行使项目经理的权利。并且，其他的项目组成员没有足够的权力去管理和协调项目工作。这样就导致了项目的失控，项目进展中遇到的问题无法被及时暴露和解决，最终致使项目失败。
2、 项目组无法统一目标和方针，导致项目组工作效率低下。由于多数项目的实施，要涉及的多个部门的协同配合，即项目组成员会由各个不同的部门同事组成。而项目经理没有足够的权力协调其他部门的组员的工作，而且，由于项目组是临时机构，这导致了项目组成员对项目组的无视，他们往往更加乐于按照部门负责人的安排工作，而不是项目经理。甚者会出现在项目实施期间，某部门突然将项目组中的人员抽调走，而导致项目停工或工期延误等后果。
3、 项目经理的责任过大，权力过小，导致其工作畏首畏尾。很多项目一旦确认项目经理后，项目经理就要对整个项目负全部的责任，但是与其不成正比的是，项目经理的权力却是极为有限，根本无法足以保证项目工作的正常开展。项目经理的责任和权力的失衡，严重的影响了项目工作的正常开展，使得项目经理在工作中无法发挥作用而又害怕因失误而带来的直接责任问题。由这样的项目经理领导的团队，注定其无法完成项目工作。
4、 授权模糊或没有授权，致使项目经理对其工作职权概念模糊。为了达到某种目的而创立了团队。企业可能会向项目经理"授权"。但是通常是很模糊的，即项目经理为达到既定目的可以在某种程度上采取一切必要的行动。但也可能企业没有这样授权。对此项目经理要么感觉手中无权，无法开展工作；要么就搞不清自己职权到底是什么。不管怎样，这样的团队往往是要失败的。
5、 公司没有按照项目进行利益分配，项目工作没有积极性。由于公司没有基于项目进行利润分配的模式，即企业还在吃大锅饭，项目组成员无法看到项目成功与否对自己带来的直接效益，项目经理更是无法从正常的利益方面激励项目成员的工作积极性，某种程度上还要靠项目成员发扬风格或是项目经理与项目成员的私人关系才使项目得以正常实施，这使得项目实施工作举步为艰。
形成上述现状的原因是多方面的，主要表现在以下几个方面：
· 企业制度不健全
目前国内IT企业的项目管理组织形式一般都属于弱矩阵或平衡矩阵类型的，职能部门和项目管理层还处于"磨合期", 工作效率较低下，另外，沟通复杂本身就是矩阵型组织的突出特点。看来，建立基于项目管理的现代企业制度，还有一个漫长而艰苦的过程。
· 项目经理制的在企业中没有具体切实落实
在目前IT行业企业的编制中，项目经理部仍是可有可无的，项目经理多数情况是由职能部门人员“客串”或是兼职的。在企业中，很难找到专职的项目经理。而且，目前的项目经理大都被定义为“传声筒”，一般没有真正意义上掌握人、财、物大权的项目经理。
· 项目经理自身的原因
1 项目经理缺乏项目管理方面经验；
2 项目经理不懂项目所必须技术，是个技术外行；
3 项目经理没有足够的应有的权力；
4 关键性文件没有被及时的制定、颁发，甚至项目经理制定的有些文件是错误的；
5 项目经理没有全局观念，把注意力过多地放在自己熟悉、喜欢的部门或单位。
如果要解决上述问题，最根本的途径是认清项目经理的地位和作用，重点是正确界定项目经理的责权利。
一 项目经理的地位和作用
项目管理的组织的特征是严格意义的个人负责制，个人负责制的核心人物必然是项目经理。所以项目经理是决定一个项目成败的关键人物。项目经理是项目实施的最高领导者、组织者、责任者，在项目管理中起到决定性的作用。成功的项目应该是使项目任务能够按照既定的计划和要求完成，以及项目成果能使本企业组织成员项目组中的主要成员、最终用户或委托人感觉高度满意。最终给企业创造效益。
项目经理是项目有关各方协调配合的桥梁和纽带，处在上下各方的核心地位。项目管理说到底是人的管理与协调。负责沟通、协商、解决各种矛盾、冲突、纠纷的关键人物是项目经理。他对项目行使管理权，也对项目目标的实现承担全部责任。他所扮演的角色是任何其他人不可替代的。项目经理作为企业委派在项目管理上的代表，按合同和约履约是他一切行动的最高准则，拒绝承担合同以外的其他各方强加的干预、指令、责任是他的基本权力。项目经理是项目信息沟通的发源地和控制者，在项目实施过程中，来自项目外的重要信息、指令要通过项目经理来汇总、沟通、交涉，对项目内部，项目经理是各种重要指标、决策、计划、方案、措施、制度的决策人和制定者。
二 项目经理的责、权、利
(一) 项目经理的职责
1.确保项目目标实现，保证用户的满意。这项基本职责是检查和衡量项目经理管理成败、水平高低的基本标志。
2.制定项目阶段性目标和项目总体控制计划。项目总目标一经确定，项目经理的职责之一就是将总目标分解，划分出主要工作内容和工作量，确定项目阶段性目标的实现标志如形象进度控制点等。
3.组织精干的项目管理班子。这是项目经理管好项目的基本条件，也是项目成功的组织保证。
4.及时决策。 项目经理需亲自决策的问题包括实施方案、人事任免奖惩、重大技术措施、设备采购方案、资源调配、进度计划安排、合同及设计变更等。
5.履行合同义务，监督合同执行，处理合同变更。 项目经理以合同当事人的身份，运用合同的法律约束手段，把项目各方统一到项目目标和合同条款上来。
(二) 项目经理的权力
1.指挥权 项目经理有权按项目相关合同的规定，根据项目随时出现的人、财、物等资源变化情况进行指挥调度，对于项目工程组织设计和网络计划，也有权在保证总目标不变的前提下进行优化和调整，以保证项目经理能对项目实施过程中出现的各种变化应付自如。
2.人事权 项目经理应有权对项目组的组成人员进行选择、考核、聘任和解聘，有权根据项目需要对项目组成员进行调配、指挥，并且有权根据项目组成员在项目过程中的表现进行奖励和惩罚。
3.财权 项目经理必须拥有项目范围内的财务决策权，在财务制度允许的范围内，项目经理有权安排项目费用的开支，有权对项目预算内的款项进行安排和支配，并且，在项目实施期间，项目经理应有权在工资基金范围内决定项目组内部的计酬方式、分配方法、分配原则。对风险应变费用、赶工措施费用等都有使用支配权。
4.技术决策权 主要是审查和批准重大技术措施和技术方案，以防止决策失误造成重大损失。必要时召集技术方案论证会或外请咨询专家，以防止决策失误。
5.设备、工具、材料的采购与控制权 在企业有关规定的范围内，项目经理应有权决定项目相关设备、材料的采买时间及数量，对项目相关的设备、工具、材料等有权按质量标准检验后决定是否用于本项目。但项目相关主要设备的采购权不宜授予项目经理，否则可能影响公司的效益，但由采购部门采购设备必须按时、按质、按量，否则项目经理有权拒收或采取其他措施。
（三）项目经理的利益
目前，在国内IT企业中，因项目经理的权限较小，责任较大，而且多数企业都没有对项目经理的工作绩效进行深入评测，并且与其直接利用挂钩，这使得项目经理经常是付出的多，得到的少，久而久之，工作积极性下降。要明确项目经理的利益，改隐性收入为显性收入。 企业应该对项目经理按照项目进行独立核算，改变过去那种只干不算。按照项目实施质量和最终结果，从项目利润中提取一定比例作为奖励基金，由项目经理按规定分配。
项目经理的最终利益是项目经理行使权力和承担责任的结果，也是市场经济条件下责、权、利相互统一的具体表现。项目经理除按规定标准享受企业制定的工资和奖金外，如果其负责项目的各项指标和整个项目都达到既定的要求，应该在项目终审赢余时按利润比例提成予以奖励。
如果项目经理所负责项目未按合同要求完成，可根据项目具体的情况，扣发全部项目奖金。如属个人责任，致使项目工期拖延、成本亏损或造成重大事故的，除扣发全部项目奖金外，可处以一次性罚款并下浮工资，性质严重者要按有关规定追究责任。
综上所述，项目经理是对项目管理全面负责的管理者，也是施工项目的管理中心，明确项目经理的责、权、利，并在项目管理中落到实处，是企业挖掘内部潜力;获取最大利润"的根本途径；是项目能否成功及项目管理目标、成本目标能否实现的关键。
如今，伴随了IT业技术的日新月异的发展与更新，其项目管理规范化进程也在加速发展。“项目经理”这个年轻的职业正在IT企业中发挥越来越重要的作用。当今企业的发展呼唤好的项目经理，但是更重要的是我们更加需要适合于项目经理发挥能量的舞台和能够培养更多更好的项目经理的温床。
在技改项目的项目管理、实施过程中，不仅是项目经理，与项目相关的各方面人员都越来越注意到项目进度的重要性。那么如何控制项目进度。以下是个人的一些建议，供参考：
1、项目负责人或项目经理一定要对整个项目的周期有一个清楚的了解。根据项目不同阶段的的不同特点，把任务按阶段划分。对于每一阶段的任务都要有明确的目标和成果；都要明确各项任务的责任部门以及责任人。这样，责任部门以及责任人对项目阶段各项任务和目标以及成果是明确的，对时间进度的要求也是明确的。项目经理所要做的就是：密切跟踪各项任务的进展情况，时刻与项目的总体进度进行对照。及时发现问题，及时协调与解决问题以保证项目沿着正常的轨迹运行。
2、沟通和交流。作为项目经理或项目负责人，与项目相关各部门以及有关人员沟通、交流是其最基本的工作内容。而沟通与交流也是保证项目进度得到有效控制的基本要素。许多在项目中遇到的问题，对当事者来说也许是很困难的，可是通过沟通与交流，通过相关部门的帮助，往往可以很顺利地得到解决。沟通与交流有助于及时发现问题并及时得到解决；有助于调动项目团队成员的积极性；有助于加深对项目的理解和消除误会。
3、抓重点、攻难点。每一个项目，都有其不同的特点。要有效地控制好项目的进度，找到项目的重点、难点并全过程得到有效的控制与解决是关键。项目经理在起始阶段就要对项目难点、重点有一个预判，前期做好充分的准备，做好必要的预案。在项目实施过程中，始终抓好重点、难点的管理，周密计划、认真实施。抓住了重点、解决了难点，项目的成功就是自然而然的结果了。
4、做好项目的总结。要善于在项目管理过程中以及项目完成后做好总结。及时的总结有利于发扬成功的经验；有利于及时纠正工作中的不足；有利于项目团队整体素质的提高。对于本项目来说，及时总结是纠正错误，控制进度的有力保证。对于后续项目来说，已完成项目的经验教训，对减少项目管理的出错，提高项目管理的精度具有良好的借鉴作用。
以上几点，希望对您能有所帮助。
1980年代末,美国安达信顾问公司(现改名为埃森哲Accenture)为了加强其核心IT业务,开始雇用新的专业策略顾问。这些顾问比安达信员工更有经验,而且习惯于比安达信现有IT员工享受"更有刺激性的个人业绩奖励"。
沃顿管理学教授莎拉·凯普兰(Sarah Kaplan)与麻省理工斯隆管理学院的蕾贝卡·韩德森(Rebecca Henderson)共同撰写了一篇论文:"惰性和激励:组织经济学和组织理论的相结合"(Inertia and Incentives: Bridging Organizational Economics and Organizational Theory)。
安达信与柯达的教训
论文中指出,当安达信这些新雇用的"明星员工"要求得到他们在以前公司的收入水平时,老员工就产生了抱怨。毕竟,现有的工资系统"已经通过对新雇员的大量培训和社交活动后得到了加强"。改变这一工资系统的努力,由于"安达信公司内没有人知道新的业务应该如何运作,或者怎样才能成功而变得复杂"。
安达信对现有的激励系统进行了一些变动,认为既可以满足新员工的期望,而且不会疏远老员工。同时,还试图将新员工塞进现有IT员工的架构中。但这些努力都不成功,许多新员工离开了公司。安达信建立新业务的努力出师不利。
凯普兰说,柯达在转向数码摄影的时候,遇到了类似的问题。数码摄影是一个非常不同的商品,其所要求的不仅仅是"从化学到数码的技术能力的转变",同时还需要一整套新的商业模式。但是,高级经理们并没有这样看待这一问题,他们不认为数码业务需要根本的改变,包括新的技术和经理人。相反,柯达试图发展一种混合的商业模式("以胶片为基础的数码图像"和图片光碟)。凯普兰和韩德森在她们的报告中指出,很多人认为这一策略"是失败的,而柯达最终建立了独立于传统摄影部门的数码影像部门"。
凯普兰说,这两家公司的共同点是"在对新业务前景的理解和如何给予员工报酬之间存在着矛盾冲突,以致最终无法建立起能够抓住新机会的那类组织"。
凯普兰和韩德森的研究重点是:究竟是什么原因导致这些矛盾得以产生和发展,并以激励机制为切入点。
凯普兰说,经济学家倾向于认为如果你改变了激励体系,企业也会随之改变。但事实上,改变激励体系并不是直截了当的,尤其是当企业试图对一项新技术或市场变化做出反应的时候,这种不确定性就更大了。在这些情况下,必须考虑到"经理人对市场情况的’诠释过程(interpretative processes)’,也就是他们的’认知框架(cognitive frames)’。激励体系和这些经理的诠释是紧密相连的"。
凯普兰说,人们通常将激励体系定义为"经理人让人们完成工作的东西"。在很多企业中,激励不仅仅指薪水,还包括奖金、福利、私人办公室、奖章、上级的表扬、升级以及加入重要的项目等。"从商业媒体上我了解到现在的企业试图更多地使用非薪水类的激励方法,比如股权。但是不论企业拥有怎样的激励机制,都会遇到同样的问题。比如,有些公司发现当他们为员工提供更多的股权,但减少薪水时,员工反对这一改变。在很多企业里,员工只相信旧的激励方式。"
凯普兰以她自己为例。"作为一个大学教授,除非我亲眼见到这个大学在过去的历史中有很多满足某些条件的教授得到了终身职位,否则我不会相信我会得到终身职位(tenure)。但当情况发生变化时,这类历史纪录就没有了。人们不知道是否要相信这个新的激励体系。"凯普兰说,在这类情况下,"对市场的诠释或认知框架将会很大地影响雇员如何理解他们应该做什么,以及何种激励能够鼓励这些行动"。
建立新契约的挑战
凯普兰和韩德森的论文尤其关注成功公司在试图为新的投资建立合适的激励体系时所面临的限制。她们认为,首先"激励非常有可能基于评估,而这类评估取决于如何诠释"。
两位写道,所有衡量标准"都可能非常模糊。这些标准的意义只能随着时间慢慢呈现出来"。
她们还提出在一个成功企业中,激励体系有可能"在一系列关系型契约(relational contracts)中得到实现"。关系型契约是指那些不能以书面形式记录,但企业由于担心不履行这一契约可能的后果而不得不执行的约定。这类契约的建立需要数年时间,并且是基于对契约条款的共识。而员工也能够信任企业将会遵守这些条款。
除了进行外部调查,凯普兰和韩德森还采访了企业员工,以了解他们的企业为什么在面对变化时这么困难。两位指出:"人们给了我们很多原因,比如公司选错了目标消费者,或投资了错误的技术。这些原因可能是正确的。"
凯普兰和韩德森还研究了企业为何无法应对"结构"创新。由于企业继续依赖"从以往的产品中积累的经验,例如思维模式和解决问题的策略而造成了应对创新的困难。结构创新不仅要求新的认知框架,并要求新的激励"。
有些人认为激励方式变化之所以困难是由于公平的问题。两位作者引用其他研究结果,认为企业内部规范让企业很难为一个新部门的员工提供比现有员工高出很多的激励。然而凯普兰和韩德森认为仅用公平问题不能解释"很多新分支的激励政策与其母公司这么相似。比如,通常销售部门的员工比其他员工的酬劳要高很多。这一差别引起的矛盾相对很小,因为其他员工认同了销售工作是不同的,是困难的而且不愉快,或者只是认为销售员需要不同类型的酬劳来不断鼓励他们"。
凯普兰和韩德森认为,很多人只是假定如果世界变了,"企业需要根据一套不同的主观评估进行奖励,它只需要宣布这一变化。员工们就会知道公司实行新契约是理性的,而公司也知道员工会做出相应的表现。双方可以平稳地进入新的平衡状态,而改变也将没有问题。"
但"在一个混乱的世界中的真实企业并不是这样的。当一个大变化发生时,在企业和员工之间需要建立一个新的契约(激励系统)"。
建立契约面临三个挑战。
首先,要明确员工在没有获得酬劳时可能会怎么做,或者说其真正的利益所在。这是一个复杂的过程。
第二,行动和有用的结果之间的联系存在着巨大的不确定性。在一个现代企业中,任何一项任务,即使是不太复杂的任务,管理层对这些联系的理解最多也是一个部分的,不完整的模型。这一模型是根据多年的个人经验而慢慢形成的。当面对一个完全新的商业机会时,这种模型可能根本不存在。
第三,随着情况变得越来越不稳定,越来越模糊,员工所关心的事也越来越不清楚。而公司也越来越不可能轻易获得这一信息。员工可能对所得到的奖金做出意想不到的反应……这一问题经常由于企业对如何奖励按照新要求工作的员工没有经验而加重。这使得经理及其员工没有了一个熟悉而有效的关系型契约。
企业考虑通过在新部门实行新的员工激励系统来实现这一转变。但两位作者指出,在这种情况下,虽然经理认识到彻底改变过的激励系统可能会鼓励员工追求高风险的技术改革,但他们通常会产生迟疑,而不执行新的激励系统。"因为如果这样做的话,他们将会违反与老员工之间现有的关系型契约。"这将对激励政策造成"选择性干预(selective intervention)"。这样的政策必将失败,因为整个系统不能和新的环境相匹配。
传统的升职方式
两位作者说,所有这些原因让在新环境中运作的新企业很难建立激励机制,但对于成功的公司而言,就更加困难了。现有的激励机制在很多年的实施过程中,逐步"植根于员工和雇主的认知框架以及企业的日常运作和流程中。
……我们觉得评估和奖励员工可能要比学习如何工作本身还要困难,因为努力和成果之间总存在着一定的距离"。
事实上,一个成功企业的高级经理很可能借助其从多年工作经验中获得的直觉,就可以有效地评估其下属的工作。"很多高级经理本身可能就是凭借这种能力,以及他们对工作的了解得到升职。两种能力同样重要,因为经理的基本工作就是评估和奖励他们的下属。"但这可能对预测或发现市场变化造成影响。"经理以某种特定方式看待某件事的部分原因是他们的过去以及现在的激励机制。如果随着时间的推移,经中的认知框架,那么他们就有可能拒绝接受那些可能会引起环境彻底改变的信息,并将其作为不重要的信息处理。"
由于企业家面对着一个全新的市场和全新的技术,"或者说当他们需要评估一名管理着高风险、快速增长部门的经理时,原来对于什么才算是有效投入的直觉可能就不正确了"。
另一个问题就是员工和雇主可能对新的激励政策产生不同的理解。"不同的理解可能使员工感到受了欺骗,而经理则相信他们完全在按照政策工作。"同时,经理可能会觉得因为新技术和新工作内容太复杂,还不如对新部门实施现有的激励政策比较简单。
所以,"使用主观衡量标准和默认契约鼓励企业做一件事,可能会使企业很难完成另一件事(比如进行根本的改革)。正如有些学者提出的,如果工作程序是企业内部的停战协定,而如果这些停战协定包含了某些业务认知框架以及一套鼓励以该认知框架为基础进行工作的激励机制,那么任何对框架或对激励机制的改变都将会导致停战协定的崩溃"。而这将导致错误的努力方向以及最终的失败。
建立新模型
根据以上的内容可以得出结论,"首先,无论是默认的认知、准则或程序都不仅仅是个人学习如何工作的认知过程的产物,还是每个人学习何种行为可能得到奖励的、与激励机制有关过程,都是公司的工作程序。这就是激励政策的作用——’我这样做事,因为这样对我最有利。’这一作用不能明确地与认知分离:’我这样做因为我相信应该这样做。’事实上,认知和激励两者在一个复杂的、互相作用的过程中同时形成。"
第二,当一个企业开始采用一种全新的技术时,"所面临的困难是认知的也是与激励有关的。认知困难是’我们知道这样做不行,而且我们怀疑,即使这样做了也赚不到钱’。与激励相关的困难是’就算我学了你也不会付我钱’。这是因为认知框架和激励机制在一个企业中的关系非常紧密。想改变其中一个,必定会让另一个发生变化"。
"在处理变化时,要重视认知框架和激励机制在企业中的植根深度。植根越浅,就越有可能出现不同的观点(能够更好地接受根本的技术变化的观点)。然而,一个植根很深的体系也有自己的优势,可以使决策变得方便,并能够有效执行策略。"
这个模型将"激励机制和认知框架视为一个企业中两个互相联系的部分。当认知框架和激励机制深植企业内部时,旧模式会保留下来。然而……当经理改变了两者之间的关系的时候,改变是可能的"。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/7199667/viewspace-1010688/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
项目管理与足球比赛
下一篇：
“知识管理”——信息化的奢侈品？
请登录后发表评论
登录
全部评论
