| 17 |
The change in software inventories is assumed to be zero, with
the result that inventory change gets swept in with the estimates
for investment. |
| 18 |
For custom software, which covers two revenue items on the 1997
and 1998 SCS (‘custom software development’ and ‘contract
programming’), systems and technical consulting as well
as training and other professional services may be included if
they are an integral part of the custom software development contract.
Regarding integrated (hardware and software) custom products/services,
the SCS asks to unbundle and include only that part of revenue
attributable to customized software. In the case of pre-packaged
software, the SCS collects information on revenue from multiple
sale, rental, license or lease. It asks to include as well any
revenue from sales of custom developed software to a client who
intends to re-market as part of a software package. It might be
considered useful to separate out revenues from software rentals
and short term (i.e. less than one year) licenses/leases and exclude
them (i.e., continue to treat them as intermediate expense, and
not investment). However, while these items are covered by the
survey, the details are not available. Moreover, at present, the
rental of software is negligible and the vast majority of software
license/lease arrangements are for terms of at least one year,
so this is not a major problem for the estimation of software
investment. Nonetheless, the technology is advancing such that
software rental may become a more common practice, and thus present
a measurement problem in the future. It would be useful to distinguish
between revenues from (payments for) the right to use software
and the right to replicate it for on-selling, enabling treatment
of the former as investment and the latter as intermediate but,
again, such details are not available on the survey (or from any
other source). For now, the adjustment for embedded software serves
to fill this data gap. |
| 19 |
This is considering only pre-packaged and custom-design software.
Most own-account software is developed outside of the computer
services industries. |
| 20 |
There are some limitations with respect to coverage of the surveys
of International Transactions in Commercial Services. First, in
the case of site licenses for software, end-users who deal with
Canadian distributors may consider the transaction to be with
a resident and thus report no import, while distributors report
only commission income, but no imports. A coverage adjustment
is made for such transactions. Second, governments and non-profit
organizations are not included in the surveys. Last, while the
surveys cover business payments made abroad for software downloaded
over the internet (in principle at least), such payments are not
identifiable from imports of other computer services and thus
not included above. |
| 21 |
In level terms this adjustment adds $50 to $60 million to software
merchandise exports, a relatively small amount compared to over
$2 billion in software service exports. |
| 22 |
The bulk of Canada’s merchandise export data are based
on US Customs data on imports from Canada, under a trade data
exchange agreement. In the case of exports of pre-packaged software,
the amounts reported in merchandise export statistics are substantially
less than receipts reported to BOP surveys. This difference was
thought to arise from an undervaluation of software in the former
(i.e., it was thought that U.S. Customs valued imports of software
at media-value). While this was partly the case, a significant
difference remained even after correction to content-valuation.
This turned out to be largely attributable to payments of license
fees, captured only in the BOP surveys. The difference between
software merchandise exports adjusted to content valuation and
BOP receipts from pre-packaged software exports is now taken as
a measure of receipts of license fees on exported software. |
| 23 |
While there is some domestic output of multi-media products
(games, reference and educational material, etc.) the SCS 1998
picked up no revenue under this category. Whatever games production
there is in Canada, it is relatively small, with little implication
for the estimates of software investment. There is a small underestimation
of software investment to the extent that some firms in the personal
entertainment business (video arcades, casinos, etc.) invest in
gaming software. |
| 24 |
With pre-packaged software, installation is almost certainly
on computers and can only (or mostly) take place in a few industries
(e.g., computer manufacturing, wholesale, retail). For customized
software, however, embedding in hardware is taking place in a
wider range of industries over a much wider range of products.
Customized software may be just a few lines of code intended to
perform very simple binary operations (switches) or it may be
a more complex program embedded on a chip monitoring all on-board
systems in an aircraft. |
| 25 |
As a result of this derivation, business investment includes
purchases of pre-packaged and custom software made by non-profit
organizations. |
| 26 |
The benchmarks here are based on 1991 and 1996 Census data for
two occupations in Statistics Canada’s Standard Occupational
Classification, 1991 (SOC), ‘computer systems analysts’
(SOC C062) and ‘computer programmers’ (SOC C063).
The former covers occupations ‘primarily concerned with
analyzing information processing or computational needs; designing
computer systems which provide solutions to these problems or
performing the needed computations; analyzing data bases; and
supervising computer programmers. Also included are specialists
in the development of computer languages and software packages.’
The latter covers occupations ‘primarily concerned with
writing computer programs by coding sets of instructions into
machine readable form. Computer programmers may specialize in
writing programs suitable for a specific application such as business,
commercial, scientific or engineering.’ The two were combined
as one occupation ‘computer programmers, systems analysts
and related’ in the previous SOC 1980 used in the 1981 and
1986 Censuses. Some software development is no doubt carried out
by persons in other occupations. For instance, ‘software
engineers’ are included with the occupation grouping for
‘computer engineers’ (SOC C047), but cannot be separately
identified (there were about 5,000 ‘computer engineers’
in Canada in 1996, compared to some 150,000 computer programmers
and systems analysts, so this is a relatively small exclusion).
Also, and as is the practice elsewhere, the programming done by
non-software professionals (e.g., economists and statisticians)
is ignored in the calculations. On the other hand, some occupations
falling within the ‘computer programmer and systems analysts’
groupings have little to do with software development, especially
in the case of systems analysts. The extent of overestimation
in this case is difficult to gauge. |
| 27 |
In addition to coverage of ‘computer programmers’
and ‘computer systems analysts’ as defined in the
SOC, there are other reasons why the own-account benchmarks exclude
the earnings of some ‘software developers’ while the
earnings of some ‘non-software developers’ are included.
Because the occupational variable on the census relates to the
job held in the reference week (the week prior to the census)
and the earnings variable relates to the reference year (the calendar
year prior to the census), the earnings of someone who becomes
employed as a programmer/systems analyst between the reference
year and the reference week are included, even if this person
had a different occupation in the reference year. Conversely,
the earnings of someone who was a programmer/systems analyst during
the reference year but who held a different occupation during
the reference week are excluded. Similar effects occur in the
case of someone with more than one job at the same time. In this
case, a person’s earnings from all jobs are included in
the own-account benchmark if the main job is as a programmer/systems
analyst, despite the fact that part of these earnings come from
other jobs which need not be in the same field. If the main job
is not as a programmer/systems analyst, no earnings are included
in the benchmark, despite the fact that part of these earnings
could stem from a second job as a programmer/systems analyst.
These cases are deemed to be largely offsetting, having little
implication for the own-account benchmarks. |
| 28 |
Benchmark estimates are based on the Census of Population question
on wage and salary income earned in the Census reference year,
selecting persons who (1) reported positive wage and salary income
in the reference year, (2) reported at least one week of employment
in the reference year and (3) who were classified as a computer
programmer or systems analyst (either in the main job held in
the reference week or, if none, in the main job held since January
of the reference year). Note that the earnings from self-employment
as a computer programmer/systems analyst are not included here,
because these are covered already under purchases of customized
software services. |
| 29 |
Anecdotal evidence suggests that computer programmers and systems
analysts are much more highly compensated in the private sector
than in the public sector. While all the censuses, 1981 through
1996, show higher annual earnings in the private sector, the gap
is relatively small, 1% to 8%, declining since 1986, and more
than explained by longer working hours. On an hourly basis, the
census shows programmers and systems analysts earning 3% to 8%
more in the public sector. The Labour Force Survey, which gives
more recent data, show a small and declining gap in hourly earnings
in favour of public sector programmers and systems analysts over
1997-2000, while (actual) weekly hours of work are about 10% higher
in the private sector. One possible explanation for the divergence
between the anecdotal evidence and the data is that stock options
are not included in census income or LFS earnings data. No adjustment
is made here for any gains on stock options, and this would seem
to be a potentially significant omission. However, the stock option
phenomenon is primarily associated with the information and communications
technology sector, and most of the earnings of programmers and
systems analysts working in this sector are excluded anyway, to
avoid double counting. |
| 30 |
This departs somewhat from the U.S. approach. The BEA determines
and applies the cap on employment of programmers and systems analysts,
not on their labour income. |
| 31 |
On the valuation of software, the SNA93 (10.92) says “software
purchases on the market is valued at purchaser’s prices,
while software developed in-house is estimated at its basic price,
or at its costs of production if it is not possible to estimate
the basic price”. The mark-up here covers occupancy costs,
utilities, property taxes, permits and licenses, materials and
supplies and intermediate business services, depreciation, insurance,
interest and bank charges, management fees, development charges
and royalties among other (non-labour) expenses. Software that
continues to be treated as intermediate is covered by the mark-up.
There is no mark-up for advertising and promotion expenses, on
the grounds that own-account software is not marketed. And while
there is a mark-up for the depreciation component of gross operating
surplus, there is none for a net profit margin. |
| 32 |
This index has several parts: the BEA price index for computers
and peripherals in private fixed investment (1981-84); an average
of the BEA hedonic price index and a matched model price index
for spreadsheets and word-processors (1985-93); the BEA matched-model
price index (bias-corrected) for selected pre-packaged software
(1994-97); and the U.S. Bureau of Labor Statistics producer price
index (bias corrected) for pre-packaged applications software
(1998 on). |
| 33 |
Hourly earnings of programmers and systems analysts are derived
from census variables on their annual wage and salary income and
their annual weeks of work (for the reference year) and their
actual weekly hours of work (for the reference week). The actual
weekly hours variable is taken as an approximation to the average
actual weekly hours of work during the reference year. |
| 34 |
SEPH data only go back to 1983. The indexes are carried back
to 1981 by linear extrapolation. |
| 35 |
The follow-up was faxed out and gathered usable information
from 72 out of 116 respondents who had reported software capital
spending to both the 1998 and 1999 CAPEX. It asked for a breakdown
of capital spending by type of software, whether and how much
software was expensed and about expected useful lives for capitalized
software. Unsolicited comments were received on rules for capitalization
of software indicating a variety of practices including varying
thresholds over and above which a software purchase would be capitalized
as well as different treatments depending upon the type of software
(e.g., custom-design would be capitalized and pre-packaged would
be expensed). Some 90% of respondents reported capital spending
on pre-packaged software, 62% reported custom-design, and 25%
reported capitalized own-account software. About two-thirds of
respondents reported both expensed and capitalized software. |
| 36 |
For pre-packaged software the fraction is 0.36. In other words,
the part of total capital spending on software reported to CAPEX
1998 attributed to pre-packaged amounted to 36% of the estimate
for pre-packaged software flowing from the commodity balancing
exercise. The ratios for custom-design and own-account software
are 0.21 and 0.18 respectively. Ideally, these ratios would have
been established by sector and even industry, but owing to the
relatively small sample this was not possible. For reference year
2000, CAPEX will gather details on capitalized software by type,
and given the larger sample, it will be possible to investigate
sector and industry variation, if any, in the propensity to capitalize.
|
| 37 |
In the 1998 CAPEX, 30% of respondents with capital spending
on software reported a three year expected useful life for software,
40% reported a five year life. In the follow-up survey, the modal
expected useful life reported for own account and custom software
was five years, and for pre-packaged, three years. |
| 38 |
Ideally, estimates of gross stocks of software and stocks of
software already capitalized, employing software price indexes
and service lives for the former and hardware price indexes and
service lives for the latter would have been calculated, although
this approach turned out to be difficult to implement. Subsequent
to the preparation of these estimates however, Investment and
Capital Stock Division (ICSD) of Statistics Canada revisited and
resolved this problem on a gross as opposed to a net basis. Their
estimates for more recent years will be incorporated into the
SNA on an on-going basis. Their estimates for the back-period
(1981-1997) will be incorporated at the earliest opportunity.
It might be noted that ICSD employed the PIM method, the same
life assumptions and the same prices as employed here. Moreover,
it prepared estimates according to three forms of depreciation,
straight-line, infinite geometric and hyperbolic. |
