新闻动态

软件资产评估成本法的实现

2020-05-07 09:48:06 25

软件资产评估去引导数据的估值,我们是使用成本法进行软件估值的,而不是前面有专家提到的市场收益,因为市场收益还会涉及到企业的前景、行业分析等诸多问题。对软件成本估值,软交所已经制定了相应标准,并有所实践,在这里与大家分享。

2013年以前在信息化项目建设费用预算上就遇到了一些问题,比如信息化项目到底多大,甲乙双方对规模有没有统一的认识,在功能的实现里是不是对价格有比较大的影响,对政府来说如果进行信息化项目建设,合理预算是多少,如何招到比较合格的供应商做比较全面的系统建设,它的工期是多少,是不是合理的利润,会不会有水分存在,预算的过程是不是真实可靠,此外主观性是不是太强而客观性太少,如何解决它,这是当时对信息化项目建设费用进行评估所考虑的几个方面。

针对一些问题,重点在于解决专家法中存在的主观性评估误差,使评估结论有理有据,可核查,便于项目对照验收,形成项目闭环管理;同时易于统一管理,能够对所有评估项目保持评估方法一致性,结论也能与行业特点紧密相关,容易行业递归;第三个方面,项目流程合理、合规,避免审计风险。我们的很大一部分客户是政府和国有企业,有以上这方面的诉求,基于此,解决它是从成本法和标准实现的角度去做的。

标准有行业和地方两份去实现软件的成本度量,我们以北京市标准为例做主体介绍。这个标准里也是有一个适用范围的,有它局限性,其实对于制定数据标准也是一样。

这个标准在成本这个角度需要把项目里边的核心要素抽象出来,它的核心要素是功能性需求,因此该标准适用于以功能性需求为主的定制类的信息化项目建设,为什么提功能性定制类?对于产品类,比如office操作系统已经完全有市场机制了,这一块并不适用于成本方法去解决它,功能性是核心要素上面已经提到了。标准在成本构成上按一般分类做了结构分析,比如有直接成本还有间接成本。对于直接的人力成本是一个工作量,也是最主要的内容,非人力成本是通常我们认为的办公费用、培训费用、差旅费用等,软件行业对于间接成本是按一定的比例进行提取计算,直接成本是最难的一点,也是标准里想方设法解决的。

其技术实现是对软件部分先进行规模测算,该测算使用了国际上认可的功能点方法,这是方法核心,对于数据是不是能提出这样的核心我们接下来可以去探讨。工作量测算是基于行业基准数据以及相关的影响因素,下面还会进一步解释。费用/工期测算同样会涉及到行业基准数据,比如北京的人工费率和河北的肯定有差异,金融行业和政府行业肯定也是有差异的。

整个测算过程是递归了相应的项目样本,并进行了相应建模,既有对核心内容的国际标准使用,也考虑了可能的影响因素,还有重复性功能的存在等情况,就数据估值应该也有一定的相通性。

在工作量计算里也考虑了相关的因素,比如刚才提到的行业差异性、软件的质量要求,一般的办公系统还是具有智能分析,或有地理信息内容在里边,甚至于其开发语言是什么,在这个里面我们分成了两种大类,一种是软件因素一种是开发因素。

工期测算是递归出来的模型,结合历史数据,我们采集了几千个不同的样本,通过这个样本递归工期情况怎么样。费用测算结合不同行业不同地市的不同人工费率情况实现,从而完整再现了一个软件系统项目如何进行成本估算的过程。

这里是一个比较简单的信息系统,黄色部分就是功能性核心要素,数据也是一样,是不是可以聚焦到总体内容中的几个核心元素里。信息系统只要能以功能点为单位进行拆分,就完成了软件成本测算的很大一部分工作内容,套用模型,就能实现软件开发费用的测算。

这是一个结果情况,结果的展现更多的是从交易角度,提供给相关方进行预算或资产价值评估参考。

整个标准里实现的关键点是什么,第一是方法论,核心要素就是功能点;第二是影响因素,影响因素有这样几点,比如在整体的复用情况,建设中可能的需求变更情况,劳动生产率情况,涉及到软件因素的应用类型、质量要求、开发因素、开发团队的熟练程度等;第三是递归模型的建立,递归模型是结合历史数据形成的,不是随便造一个,我相信在数据的价值评估里也是需要结合历史的市场价格或价值产生模型。第四是行业迭代数据,这个数据是每年更新的,对于软件来说更新速度比较快,因此每年会把新的项目放到总体样本库里进行迭代,并于10月份发布新数据。(摘自网络)