http://qiaodong.mypm.net
公 告
登 陆
日志日历
导 航
日 志
评 论
链 接
统 计
 
4.4 企业财务管理对项目管理的支持——《企业级项目管理体系建设》连载

4.4 企业财务管理对项目管理的支持


4.4.1 确定合理的项目内部预算
对于项目预算,不同各方由于所站角度不同,对项目预算的定义也不尽相同。例如在一个企业外包项目中,甲方的整个项目范围,不仅包含了外包部分的工作范围,还应包括甲方本身需要做的配套工作,外包部分的项目范围,其实只是甲方项目中的一个子项目。因此,甲方的整体项目预算,肯定会包括外包项目的预算,而且还应包含属于甲方自身工作范围对应的预算。所以通常在一个合作或外包项目中,甲方项目的预算与外包部分的预算肯定是不同的,这一点是显而易见的。
就外包项目本身而言,甲方和乙方对项目预算的定义也是不同的。对于甲方来说,外包项目中乙方报价的价格就是甲方的成本,都是甲方需要支付的,所以对于甲方来说,外包项目的价格就是甲方外包部分的项目预算。但是对于乙方来说,项目的价格通常要包含三部分内容,项目利润、通过项目分摊的管理成本(overhead)、项目的直接成本。所以甲方认为的项目预算,对于乙方来说是项目收入,其中只能有一部分成为项目的直接成本,其他部分不会直接用于项目本身。因此,企业中用于对外报价的价格标准,与企业内部项目成本核算的价格标准,应该有所区别。
在项目预算中通常都应该考虑项目风险准备(Reserve),但这部分不是项目的直接成本,正常情况下不应该成为项目经理能够运用的项目预算,而是在发生特殊风险时,作为追加的项目预算提供给项目使用。但是从企业的角度来说,当风险概率比较大的时候,应该把这部分风险准备,也视为企业的项目预算,只是暂时先不允许项目经理动用。所以,从企业财务角度看的项目预算和项目经理看到的项目预算也不一定相同。
如上所述,在承接外部项目任务的企业中,企业不可能将项目收入全部作为项目的预算交给项目经理使用,企业内需要项目组估算出直接成本,作为项目的预算。通常情况下,项目组会做出更接近实际的项目预算,只包含项目的直接成本,不应涉及企业的利润和管理成本分摊,也不应包含企业的项目风险准备,项目经理只能在这一预算内管理项目。直接用于项目的资源的成本都由项目直接成本体现,其他配合的管理部门的成本则是从项目收入中按比例先行扣除。这种管理方式下,管理成本成为企业的固定成本,可以更为明确的指出项目的直接成本的上限,更有利于项目的成本控制。
在企业内对项目成本管理进行考核时,应该以项目直接成本所对应的项目预算为依据,而不是其他的指标。当项目按照内部价格标准做出项目预算后,对项目成本的跟踪和考核,也应该使用同样的内部价格标准。
当企业内部的部门间需要相互核算时,上述问题同样存在。如果承担任务的部门属于企业的成本中心,那么就不应要求利润,其内部报价的价格标准应体现本部门的项目直接成本和本部门的管理费用分摊。如果各部门需要对项目收入(包括利润)也进行分配,那么也就需要在内部报价的价格标准中包含利润指标。因此,企业内部对各部门、项目考核的要求,也直接影响到内部报价的价格标准。项目预算的规则,与企业其他核算管理的要求必须是一致的。
举例:项目收入分解图
 

4.4.2 项目经理的财务权限
上图是项目收入分解的一个例子,并不是严格意义上的财务分解。项目经理的职责要对其中哪些部分负责,是企业中需要明确定义的。有的项目组以承包方式对利润负责,并且会从利润中提取奖金,自然就会对项目的收入、成本等加以管理;有的项目只负责控制项目成本,只要求能够在公司批准的预算内完成项目任务,不需要考虑项目利润问题;有的项目经理只负责管理少量的直接费用,比如偶尔的餐费和交通费,不需要对人力资源、设备等固定成本负责,在纯粹职能型的组织中,所谓的项目经理几乎没有任何权力,只能起到一个协调人的作用,更过的管理权力还在职能部门。项目经理不同的职责,必然导致项目经理不同的价值取向,同样也需要相应的管理权力,以及配套的绩效管理机制。因此,在企业级项目管理体系中,需要对项目中的财务问题加以分析,明确各部分的管理职责不要产生遗漏,特别是要明确项目经理在其中的责权,以便项目经理能够清楚自己的定位,并通过适当的绩效管理机制加以激励和约束。


4.4.3 核算帐户设置对项目管理的支持
1, 项目核算帐户设置的一般要求
项目作为公司的一种投资行为,要对其投入、产出进行管理,而其中更多时间是对项目的成本进行管理。
项目规模有大有小,对于一些规模不大的项目,完全可以简单的建立一个帐户来管理该项目的所有财务活动。而对于规模较大的项目,为了便于管理,不仅在财务管理方面,还要从项目范围、时间、资源、风险等方面考虑,综合多种因素,将项目目标不断进行分解,直到对其中的各个部分达到易于管理(Manageable)的程度,这种分解的结果在项目管理中称为工作分解结构(Work Breakdown Structure, WBS)。这种WBS在形式上就是一个树形结构,树根就是项目的总目标,树叶就是被分解出来最终形成的各个子目标。
例如,下图是某大型企业中IT项目的WBS

 

其中:
 根节点是企业项目,按照项目合作方式,可以将项目进一步划分成自主开发、合作开发、外包和内部项目四种类型的内容,有的项目只包含其中一种工作性质的内容,也有的项目会同时包含多种不同性质的内容。
 在产品部署工作中,可以根据部署的工作要求,进一步将部署工作分解。例如客户需要在多个下属的分支机构部署该产品,那么就可以将部署工作细分,每个分支机构的部署工作作为WBS中的一个子节点。
 在项目开发过程中,项目需求可能会涉及多个不同的产品,因此可以将开发任务按照不同产品线的进行工作分解。
 在项目的各个不同的工作内容中,如果都涉及不同产品线的配合工作,那么每个项目工作内容都可以按照产品线进行工作分解。这样,将同一产品线的不同工作归集起来,就可以看到产品线与项目之间的矩阵关系。这个矩阵图中,纵向的是项目的WBS的工作内容,横向的是各个产品线,其实也就是各个职能部门,与PMBOK中的矩阵式组织结构图的方向是不同的,但所反映的事实是一致的。
出于项目管理的需要,项目核算帐户可以设在WBS的任一层的任一节点上,既可以设置在根节点上,也可以为WBS的各个部分单独建立核算帐户。这完全取决于项目管理的需要。

2, 项目核算与合同管理
在通常情况下,企业承接项目,一般都会与合同相对应,最简单的情况就是一个合同对应一个项目,即通过一个项目完成一个对应的合同。在这种情况下,合同所产生的现金流与项目的现金流是一致的。
但是在一些比较复杂的情况中,承接的一个合同可能会在企业中被分解成为若干个项目,项目中又可能存在分包合同,这时的一个合同就不再简单的对应一个项目了,而是对应多个项目。因此,企业财务部门、商务部门在进行合同管理时,需要建立合同与项目之间的清晰的对应关系,在多数情况下,这种对应关系是一个合同对应多个项目,但有时也可能是多对多的关系。那么就需要将合同可能产生的现金流与多个项目的现金流对应起来,通过跟踪控制各个项目的现金流,来控制整个合同的现金流。另一方面,企业在对外签定合同后,合同价格通常不能直接作为对应的项目预算,不仅要扣除企业的各项税费和分摊的管理成本,还要预留利润和风险准备金。因此,从企业财务角度来说,对于一个合同收入,就需要理清收入的各项用途,明确其中哪些是属于项目成本相关的,是需要项目成本管理来考虑的,例如项目风险准备金,通常情况下是不列入项目成本的,而项目中的分包合同或采购合同,则有时会列入项目成本,作为项目成本核算的一部份,以便更有效地对项目的整体进行控制。
因此,在财务核算中,在按项目核算时,往往也会表现为按合同核算,如果一个合同对应多个项目,再细分到项目上进行核算。
但是,有时还存在这样的情况,就是当企业出于长远发展的考虑,自己投资开发产品,或者在项目合同不能补偿项目成本的情况下由企业自行追加投资,这是就只能直接对项目成本进行核算,而不能单纯用项目合同来核算了。

3, 与部门、产品线核算的结合
在一个企业中,特别是拥有自有产品的企业中,往往都会存在按产品管理的职能部门,传统的职能部门和跨部门的项目组织会形成矩阵式组织结构,因此部门核算和项目核算就成了两个相互关联但又不同的核算方法,而原始的财务数据是共同的,如下图所示:

 

从项目核算的角度来说,只有将工作分解到能够对应到部门工作的层次,即减小财务数据的粒度,才有可能同时满足项目核算和部门核算两方面的要求,所以公司的WBS也必须分解到能分清各部门或产品线的不同工作内容为止。如果项目财务数据的粒度比较粗,要从原始数据中再分拆到不同部门,会需要许多额外的工作,大大增加了财务人员的工作量。

4, 与传统会计科目的结合
企业财务需要对各项收、支按科目进行核算,在某些科目上相关法规有具体的限制要求。而这些要求如果也分解到项目或部门,在具体执行中也要加以控制,例如企业如果对业务费用、差旅、招待、市内交通、办公、加班餐等具体内容都要求在项目中分别控制,那么对项目或部门的财务数据的粒度要求就会更细,在项目工作被分解到各个部门后,其对应的财务数据还需要按照会计科目的要求进一步细分。

5, 财务数据的多维模型
随着管理的加强和细化,对财务的统计工作要求也越来越高。仅就上面提到的内容,除了必然需要的时间条件外,还涉及到按会计科目、按项目、按部门和产品线等多种不同的统计要求。从技术角度来说可以属于多维数据模型,数据粒度和维度的选择是两个基本要素。

 

财务原始数据是核心数据,其粒度应能够满足从不同维度进行统计的需要,而会计科目、项目、部门、产品、时间等属于不同维度,对应不同的统计条件,具体的要求还需要根据企业的管理需要具体设定。在这种模式下,只要原始财务数据的粒度能够支持,其属性信息(维度)明确,以后的统计工作将可以非常灵活、方便,能够很好的满足各方面管理的需要。而从总帐出发增加下级科目的做法是无法完全支持这种多维统计的需要的,也无法支持动态存在的项目核算的需要。具体实现方式需要财务部门结合公司财务系统的功能来考虑实现方式。

4.4.4 工作量管理
项目量化考核的关键,就是要有准确的项目成本数据。成本的产生就是资源的消耗。人力资源成本通常是企业的固定成本,在智力密集型企业中,人力资源成本所占比例比较高,特别是在软件服务这类项目中,主要成本就是人力资源成本,所占比例一般高达70%-80%左右。因此,项目中对人力资源成本的管理,往往会成为项目成本管理的主要内容之一。
工作量管理,通常都是对于人力资源付出的劳动量的管理,为了能够区别,我们定义一个“工程量”的概念。例如在依靠人力挖沟的工程过程中,工程量是需要挖出的土方量,单位是“立方米”,而工作量是工人付出的劳动量,单位是“人天”,两者之间的换算,简单来说就是资源的“生产效率”,其单位可以是“立方米/人天”。
工程量=资源生产效率 x 资源工作量
工程量和工作量的区别,在工程建筑类项目中比较容易区分,从工程角度对工程规模的估算,采用工程量,对于从项目管理角度对资源需求的估算,采用工作量。但是在一些软件开发项目中,这两个概念有所混淆,主要是由于在项目前期对软件本身的工程量的估算比较难,不如建筑工程那样直观,有不少软件项目中,采用工作量来表示工程量,在软件规模估算中使用工作量来做估算,在项目管理中也对人员工作量进行管理,结果造成管理概念上的混淆。这对以后的项目绩效管理和挣值分析,都会带来理解上的混乱。因此,在软件企业中和软件项目中,都要对于“工作量”一词的含义给与澄清,是对应工程量的对软件规模的估算,还是对应资源工作量的资源需求,或者寻求其他更适合的指标来表示工程量。这一问题一直以来都是软件工程中令人困扰的问题,虽然也提出了一些不同的估算方法,但对于这种智力密集型的工程过程,都难以令人满意。

人力资源主要是工时性资源,即根据工作时间计算报酬,这是人力资源成本计算的主要方法。这种情况下,计算每个资源的成本需要两个参数:单价和时间。
其中,人力资源的单价比较容易确定,即使包括了企业各项管理成本的分摊,最终总能计算出一个人力资源的单价,即每个资源或每类资源的每天或每小时的成本。
而对于资源成本所需的时间参数,则需要进行仔细分析,首先要明确概念。在项目中有三种不同的时间概念:任务工期、资源有效工时、资源工期。
 任务工期:表示项目任务的绝对时间长度,而不考虑任务中花费的资源情况,是纯粹的时间指标。任务工期往往是项目相关各方最为关注的指标,首先要保证项目能够在规定的时间内完成,此时资源的耗费程度是其次的。任务工期可由三个数据唯一确定:开始时间、已完成工期、剩余工期,开始时间是指项目任务的实际起始时间,已完成工期是在该项任务上已经花费的时间,剩余工期是对该项任务还继续需要的时间的预测。利用这三个参数,可以推算出该项任务预计的完成时间,用这种方法可以推测出整个项目的预计的实际完成时间。
 资源有效工时:是各个资源在项目任务中投入的实际有效工时,该指标反映的是各个资源在该项目任务中的有效工作量,当有效工时全部完成后,则表示该项任务已经全部完成。有效工作量需要一定的方法来衡量,在土木工程中,可以根据总工程量和施工机械的工作能力,直接计算出所需的有效工时,在软件项目中,则需要根据预估的软件规模和开发人员的平均生产率来估算所需的有效工时,在一些管理严谨的软件企业中,都有现成方法可以估算软件规模,能够给出不同类型的开发人员的平均生产效率的指标值,从而能够比较准确的计算出各项目任务中所需的各个资源的有效工时。有效工时与工期之间相互关联但是本质不同,有效工时反映的是项目任务所需的工作量,因此就可能存在工期需要3天而有效工时只有8小时的情况。
 资源工期:是各项资源在项目或项目任务中的工期,与完成任务的效果没有关系。项目资源在一段时期内会被项目占用,这期间该资源不能被用于项目以外的工作,由于各种原因通常都会导致资源的利用率难以达到100%,但其在项目中的空闲时间也要计入项目成本。这种情况在各类项目中都是普遍存在的,在企业中也是存在的。因此,资源在项目任务中花费的资源工期,一般都会大于有效工时,通常会与任务工期相同。在资源完全被项目独占时,项目工期与资源工期有对应关系,但在资源高度共享的企业中,资源在项目中的动态性更强,资源在项目中的工期与有效工时更接近,与项目任务的工期也就无法简单对应了。
因此,从项目成本管理的角度来看,所需要的资源的时间参数应该是资源工期,而不是任务工期或有效工时。
工作量通常以人时、人天、人月数来表示,当企业需要对工作量进行比较严格的管理时,还需要特别注意根据不同的管理需要选择工作量的单位。例如:
 根据项目周期长短,对于周期比较长的项目,可以分别选择人月作单位,而对于周期很短的项目,可以选择人天或人时作为单位;
 在项目初期估算项目工作量时,可以使用人月、人天作单位,但是在项目具体执行中,就可能需要用人时来跟踪每天的实际工作量;
 对于外包出去的项目,甲方只需要使用人月、人天作单位来核算乙方的工作量,而对于自己执行的项目,对内部项目人员就可能需要按人时计算工作量;
 对于面向目标管理的企业,采用项目承包方式,使用人月、人天为单位计算工作量就可以了,但对于强调过程管理的企业,按工时发加班费,就可能需要统计具体的人时数量了;
因此,企业需要根据具体项目的情况,结合项目管理的粒度要求来选用适当的项目工作量的单位。
无论采用什么单位,都应注意前后的一致性,避免出现计划中使用一种单位,在跟踪实际发生时使用另一种单位,这样会造成一定的混乱。例如在通常情况下,1人天应该等同于8人时,如果项目计划中使用人天作单位,用人员数量和工期得到计划的工作量,而在跟踪实际工作量时使用人时作单位,人员每天工作时间并不正好是8小时(例如经常出现的8小时外加班的情况),两者计算出的人天数或人时数就会存在差异。这就需要打算进行详细量化管理的企业,对于这种计算单位给与非常具体、明确的定义,对使用方法做出详尽的规定,否则很容易会给管理者混乱。

在以人力资源成本为主的企业项目中,人力资源成本的计算需要以工作量作为基础参数,所以往往工时数据就变得非常重要,是准确计算人力资源成本的重要依据。因此,在许多企业中都很重视人员的工时管理。在强调工时管理的同时,也应避免两个误区:
1. 工作量应与目标相匹配,只有在目标的约束下,对工作量的管理才有意义,才能够体现工作量的真实效率,而不是简单的记录工作量的发生情况。因此,工作量管理应从计划开始,在计划中对工作量做出合理的估算,作为项目基线的一个内容,指导项目管理,这样才能在项目过程中通过跟踪工作量来间接反映项目任务的完成情况。
2. 工作量并不等于成本,人员的不同价格水平也是成本的另一参数。在项目管理中,在人员价格既定的条件下,工作量确实可以影响成本。但站在整体的项目管理角度来看,对成本的管理才是最根本的,工作量只是影响成本的一个参数而已,有些人力资源的成本就不是按时间成比例计算的。

在项目管理过程中,工作量往往会被作为项目管理中的一个重要的参数,在项目初期的估算过程中,工作量经常被作为一个很主要的参数用于估算项目的规模。一个项目需要10个人工作1个月,工作量就是10人月,或者1个人工作10个月,工作量也是10人月,所以工作量并不与工期相对应。同时,在工作量当中没有说明资源能力,即同一项目任务,对于生产率高的资源来说,工作量就小,而对于生产率低的资源来说,工作量可能就大,不同资源由于生产率不同而价格不同,需要花费的工作量不同,但最后完成同样任务的成本可能相同,所以工作量也不与成本相对应,成本才是真实反映项目工作量的指标。特别是在软件开发这种智力密集型的项目中,更是不能用人月数通过简单的算术计算得出资源量和工期,简单的通过增加资源来缩短工期,因为在软件项目中,人员之间的沟通成本非常高,在项目中人员之间的接口数量与人数是二次方的关系,项目组中增加一个人,就会增加大量的沟通成本,人员过多,反而导致项目的效率降低,未必能够缩短工期。
有关工作量管理方面的问题,在《人月神话》一书中有着更为深入的分析。目前在一些管理技术方面的讨论中,比较强调工作量指标,对此要明确其适用范围,合理使用。

qiaodong 发表于 2009/1/6 9:47:00 阅读全文 | 回复(0) | 引用通告 | 编辑 | 收藏该日志

发表评论:

    昵称:
    密码:
    主页:
    标题: