2. 质量成本的本质
1) 质量成本是企业的无形成本对象
在企业整个经营过程中,资源的投入不仅产生了有形的经营成果 --- 产品,而且也培育了无形的经营成果 --- 质量水平、效率水平、人力资源水平、市场网络和增值作业水平等。这些有形和无形的经营成果,就是所谓的有形和无形成本对象。它们在地位上是平等的和成本核算上是一样地对待,不应该有 “歧视性” 的会计处理,即只核算产品成本而不核算质量成本、效率成本、人力资源成本、市场地区和作业成本等。它们都应该进行成本核算和控制。
2) 质量成本属于企业的管理不善成本
质量成本是由于存在的或潜在的质量问题而投入改善的资源消耗。因此,它属于企业的管理不善成本。所有处理质量问题的过程或工作都是非增值作业。这些非增值作业是不可能消灭的,而只能不断地减少并提高其效率水平。只有这样,企业才能从实际作业的角度控制质量成本。
3) 质量成本的会计核算问题剖析
在目前的财务损益报表中,发生在生产制造成本的质量费用被分配在当期的产品成本中,这是合乎财务会计标准的。但是,企业管理者却不能从中马上得到质量成本的信息。事实上,从企业内部管理的角度出发,有形成本对象和无形成本对象是平等的,质量成本作为独立的成本对象并不依赖产品成本对象。因此,质量成本不用分配到产品成本上去。另一方面,从会计配比原则的角度出发,由于质量成本产生不仅对当期的产品有受益或受损的影响,而且对以后会计周期的产品都会有受益或受损的影响(如质量培训对员工的素质提高是有长期意义的)。所以,如果一定要把质量成本分配到产品上的话,就应该把企业在持续经营期间中所生产的产品总产量除在此期间的总质量成本,计算结果就是单位产品的质量成本。由于质量成本是有长期意义的,因此在企业是理性经营的前提下,每年的质量成本是应该呈逐年下降的趋势的而每年的产量是不断增加的。具体如下:
Σ年质量成本m当m充分大时是有限数,Σ年产量n当n充分大时是无限数,因此单位产品的质量成本当m, n 充分大时是趋于0。所以,即使是将质量成本分配在产品成本中,所分配到单位产品的质量成本还是0。
3. 质量成本控制
质量成本控制是质量管理的重要部分。可通过以下方式达到质量成本控制:
1) 质量成本的预算和核算的差异分析;
2) 四项质量成本之间在预算和核算方面的变动比较分析;
3) 质量成本的变化趋势分析;
4) 质量管理费用的成本动因分析;
5) 质量管理作业成本和作业成本动因分析。
三.结论
以上是对质量成本的一些探索。对质量成本的准确统计和核算是指导企业的质量管理的关键。应该看到,质量成本控制只是企业总成本控制的一部分。除此之外,还需要对产品成本、效率成本、销售地区成本、人力资源成本、环保成本、作业成本和资金成本等成本进行控制。随着现代计算机软件技术的飞速发展,一系列管理工具的产生和逐渐成熟,为企业在全面成本核算和分析方面提供了有效的工具。广钢目前进行深化内部管理体制改革,正是需要与推行的信息化建设有机结合起来。在保持公司的产品品种的竞争优势的基础上,全面创造和深化公司的产品成本的竞争优势,逐步形成广钢股份公司在市场竞争中的综合竞争优势。
来自:AMT
林 俊 介绍 :澳大利亚新南威尔士大学国际会计硕士;暨南大学数学系数学专业学士;中国计算机软件工程师;中山大学岭南大学EMBA讲师;华南师范学院工商管理学院EMBA讲师;《纯粹成本哲学》的创始人;《泛系成本运筹学》的创始人;《CSS 成本体系标准》的创始人;《CSS多因多果作业成本管理软件》的著作权人;澳大利亚注册会计师公会会员。
项目管理中的(用户)需求变更控制分析
需求变更的表现形式是多方面的,如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中,变更可能来自方案服务商、客户或产品供应商等,也可能来源于项目组内部。虽然需求变更的表现形式千差万别,但究其根本不外乎以下几种原因:
1、需求变更的原因分析
(1)、范围没有圈定就开始细化
细化工作是由需求分析人员完成的,一般是根据用户提出的描述性的、总结性的短短几句话去细化的,提取其中的一个个功能,并给出描述(正常执行时的描述和意外发生时的描述)。当细化到一定程度后并开始系统设计时,范围会发生变化,那细节用例的描述可能就有很多要改动。如原来是手工添人的数据,要改成根据信息系统计算出来,而原来的一个属性的描述要变成描述一个实体等。
(2)、没有指定需求的基线
需求的基线是指是否容许需求变更的分界线。随着项目的进展,需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响,比如软件整体结构已经设计出来是不容许改变需求范围的,因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展,基线将越定越高(容许的变更将越少),其过程如下:变更请求à比较基线à变更实现。
(3)、没有良好的软件结构适应变化
组件式的软件结构就是提供了快速适应需求变化的体系结构,数据层封装了数据访间逻辑,业务层封装了业务逻辑,表示层展现用户表示逻辑。但适应变化必须遵循一些松祸合原则,各层之间还是存在一些联系的,设计要力求减少会对接口入口参数产生变化。如果业务逻辑封装好了,则表示层界面上的一些排列或减少信息的要求是很容易适应的。如果接口定义得合理,那么即使业务流程有变化,也能够快速适应变化。因此,在成本影响的容许范围内可以降低需求的基线,提高客户的满意度。
2、如何控制需求变更
按照现代项目管理的概念,一个项目的生命周期分为启动、实施、收尾三个过程。需求变更的控制不应该只是项目实施过程考虑的事情,而是要分布在整个项目生命周期的全过程。为了将项目变更的影响降低到最小,就需要采用综合变更控制方法。综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生等。
进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。为保证项目变更的规范和有效实施,通常项目实施组织会有一
1)、项目启动阶段的变更预防
对于任何项目,变更都无可避免,也无从逃避,只能积极应对,这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说,基准文件定义的范围越详细清晰,用户跟项目经理扯皮的幌子就越少。如果需求没做好,基准文件里的范围含糊不清,被客户抓住空子,往往要付出许多无谓的牺牲。如果需求做得好,文档清晰且又有客户签字,那么后期客户提出的变更就超出了合同范围,需要另外收费。这个时候千万不能手软,这并非要刻意赚取客户的钱财,而是不能让客户养成经常变更的习惯,否则后患无穷。相对于需求来说,什么WBS、风险管理、计划进度都是次要的,只要需求做好了就会一帆风顺。
(2)、项目实施阶段的需求变更
成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念——“需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。控制需求渐变需要注意以下几点:
需求一定要与投入有联系,如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。所以,在项目的开始,无论是开发方还是出资方都要明确这一条:需求变,软件开发的投人也要变。
需求的变更要经过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。
小的需求变更也要经过正规的需求管理流程,否则会积少成多。在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。但正是由于这种观念才使需求逐渐变为不可控,最终导致项目的失败。
精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细,就越能避免需求的渐变,这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的,并非需求写细了,它就不会变化了。
注意沟通的技巧。实际情况是用户、开发者都认识到了上面的几点间题,但是由于需求的变更可能来自客户方,也可能来自开发方,因此,作为需求管理者,项目经理需要采用各种沟通技巧来使项目的各方各得其所。 |