CANBERRA II GROUP ON THE MEASUREMENT OF NON-FINANCIAL ASSETS FOURTH MEETING, 1-3 SEPTEMBER 2004, LONDON, UK THE DEMARCATION BETWEEN GFCF OF SOFTWARE AND R&D Charles Aspden
THE DEMARCATION BETWEEN GFCF OF SOFTWARE AND R&D Introduction 1. Following a discussion on where the boundary lay between software product development and R&D at the Canberra II meeting in Washington, March 2004, I offered to write a paper clearly delineating the demarcation between product development and R&D ependiture. The Frascati Manual (FM) devotes a whole chapter (Chapter 2) to describing what is inside and what is outside the R&D boundary, and two pages deal eclusively with software. In the circumstances, and given my lack of epertise in this area, I have decided to simply take etracts from the FM in this paper. What is R&D? 2. The FM defines R&D thus, Research and eperimental development (R&D) comprise creative work undertaken on a systematic basis in order to increase the stock of knowledge, including knowledge of man, culture and society, and the use of this stock of knowledge to devise new applications. 3. The FM then goes on to describe the three principal forms of R&D. The term R&D covers three activities: basic research, applied research and eperimental development; these are described in detail in Chapter 4. Basic research is eperimental or theoretical work undertaken primarily to acquire new knowledge of the underlying foundation of phenomena and observable facts, without any particular application or use in view. Applied research is also original investigation undertaken in order to acquire new knowledge. It is, however, directed primarily towards a specific practical aim or objective. Eperimental development is systematic work, drawing on eisting knowledge gained from research and/or practical eperience, which is directed to producing new materials, products or devices, to installing new processes, systems and services, or to improving substantially those already produced or installed. R&D covers both formal R&D in R&D units and informal or occasional R&D in other units. 4. The FM addresses the issue of identifying R&D in software development eplicitly in Section 2.4.1, which is reproduced in the appendi. Elsewhere in Chapter 2 it discusses the problem of ecluding certain activities from R&D namely: Education and training Other related scientific and technological activities Other industrial activities Administration and other supporting activities It then goes on to describe the boundaries of R&D and sets criteria for distinguishing R&D from related activities. In a further section it discusses the problems of identifying R&D in software development, in the social sciences and in service activities and industries. Software task force recommendations 5. One of the changes made in the 1993 SNA was the recognition of software as a fied asset if it met the standard criteria. While this was a welcome development it led to problems in international comparability because countries implemented the change differently. Countries have had different concepts of what software is and what constitutes capital formation and intermediate consumption, and have adopted different approaches to measurement.
6. In October 2001 an OECD task force was set up to address the issue, and one of its first actions was to conduct a survey of member countries. The survey had several aims: a) to identify what the conceptual treatments were in countries and the rationale for them, b) to determine the different methods being used to quantify the various software flows (GFCF, trade in software, etc.) and what might constitute best practice, c) to determine how countries compiled price indees for deflating software and what might constitute best practice, and d) to quantify the differences in estimates. 7. The report showed that in some cases the differences between country practices and estimates were quite dramatic. A Eurostat task force worked in parallel, and together the two task forces developed a common set of recommendations aimed at narrowing these differences. In 2002, at the National Accounts Epert Meeting, the OECD task force presented its report see the attachment. 8. The capital formation of own account software is the principal area where R&D and software GFCF have the potential to overlap. The OECD task force survey found that own account software accounted for about a third of total software GFCF. Some countries reported that they obtained their estimates from business surveys, while others found that their survey data appeared to grossly understate GFCF and as a consequence they used macro methods to estimate own account GFCF. In the absence of reliable survey-based data, the report encourages countries to adopt a macro approach and provides a good deal of advice on how it should be done. In summary, the macro-approach values own-account software as the sum of its inputs. As R&D is not currently treated as fied capital in the SNA, ependiture on R&D is treated as an input cost, and, so, a critical feature of this approach is the implicit inclusion of software R&D in fied capital formation. It is also very likely that those countries relying on businesses to estimate their own account GFCF make no attempt to eclude ependiture on software R&D. 9. Countries following recommended best practice with respect to estimating GFCF of software are already including software R&D in their estimates of software GFCF or at least doing their best to do so. Hence the problem is not one of estimating R&D software GFCF but one of identifying the R&D component of the eisting estimates of software GFCF. This implies that the problem of delineating software R&D and software GFCF is of secondary importance, and it suggests a solution, as follows: 1) estimate R&D GFCF as well as possible (as per the FM) and subtract it from the eisting estimates of own account software GFCF; and 2) estimate the value of capital services produced by R&D fied assets and add this back to the estimates of own account software GFCF. Conclusion 10. Delineating the demarcation between R&D on software and product development is not very easy, but it is not impossible. The FM provides guidelines on how it should be done and R&D survey statisticians have been doing their best to put the guidelines into practice for some time in a significant number of countries. 11. The accuracy with which the demarcation can be achieved is not critical because R&D ependitures are probably already included in software GFCF, and if they are not the estimation
procedures could be changed to make sure they are. It is then a simple matter of replacing the R&D component of own account software GFCF with an estimate of capital services from R&D fied assets.
APPENDIX EXTRACT FROM THE FRASCATI MANUAL 2.4.1 Identifying R&D in software development 1. For a software development project to be classified as R&D, its completion must be dependent on a scientific and/or technological advance, and the aim of the project must be the systematic resolution of a scientific and/or technological uncertainty. 2. In addition to the software that is part of an overall R&D project, the R&D associated with software as an end product should also be classified as R&D. 3. The nature of software development is such as to make identifying its R&D component, if any, difficult. Software development is an integral part of many projects which in themselves have no element of R&D. The software development component of such projects, however, may be classified as R&D if it leads to an advance in the area of computer software. Such advances are generally incremental rather than revolutionary. Therefore, an upgrade, addition or change to an eisting programme or system may be classified as R&D if it embodies scientific and/or technological advances that result in an increase in the stock of knowledge. Use of software for a new application or purpose, however, does not by itself constitute an advance. 4. A scientific and/or technological advance in software may be achieved even if a project is not completed, because a failure can increase knowledge of the technology of computer software by showing, for eample, that a particular approach will not succeed. 5. Advances in other fields resulting from a software project do not determine whether an advance in computer software has occurred. 6. The following eamples illustrate the concept of R&D in software. Should be included in R&D: R&D producing new theorems and algorithms in the field of theoretical computer science. Development of information technology at the level of operating systems, programming languages, data management, communications software and software development tools. Development of Internet technology. Research into methods of designing, developing, deploying or maintaining software. Software development that produces advances in generic approaches for capturing, transmitting, storing, retrieving, manipulating or displaying information. Eperimental development aimed at filling technology knowledge gaps as necessary to develop a software programme or system. R&D on software tools or technologies in specialised areas of computing (image processing, geographic data presentation, character recognition, artificial intelligence and other areas).
7. Software-related activities of a routine nature which do not involve scientific and/or technological advances or resolution of technological uncertainties are not to be included in R&D. Eamples are: Business application software and information system development using known methods and eisting software tools. Support for eisting systems. Converting and/or translating computer languages. Adding user functionality to application programmes. Debugging of systems. Adaptation of eisting software. Preparation of user documentation. 8. In the systems software area, individual projects may not be considered as R&D but their aggregation into a larger project may qualify for inclusion. For eample, changes in file structure and user interfaces in a fourth-generation language processor may be made necessary by the introduction of relational technology. The individual changes may not be considered R&D if viewed in their own right, but the entire modification project may result in the resolution of scientific and/or technological uncertainty and thus be classified as R&D.