CHAPTER 2 LITERATURE REVIEW
2.2 S OFTWARE I NDUSTRY
2.2.1 Characteristics of the Software Industry
2.2.1 Characteristics of the Software Industry
The software industry includes business for development, maintenance, and publication of software that are using different business models, mainly either “license/maintenance based”
(on-premises) or “Cloud based” (such as SaaS [Software-as-a-Service], PaaS [Platform-as-a-Service], IaaS [Infrastructure-as-a-[Platform-as-a-Service], etc.). The industry also includes software services, such as training, documentation, and consulting.
In the early 1960s, the software industry expanded almost immediately after computer were first sold in mass-produced qualities. Universities, government, and business customers created a demand of software. Many of these programs were written in-house by full-time staff programmers. The industry expanded greatly with the rise of personal computer (PC) in the mid-1970s, which brought computing to the desktop of the office worker. In the following years, it also created a growing market for games, applications, and utilities (Software Industry, 2012).
Company X rose in that era, particularly embraced a boom in information security domain after when internet tide swept across the whole world since mid-90s.
In the early years of the 21st century, the other successful business model has arisen for hosted software, named software-as-a-service (SaaS). From the point of view of producers of some proprietary software, SaaS reduces the concerns about unauthorized copying, since it can only be accessed through the web, and by definition no client software is loaded onto the end user’s PC (Software Industry, 2012).
Software industry belongs to a typical knowledge economy, and even network economy with explosive increase of Internet in 1990s. With blooming of Internet, software industry benefits from network effect, because software can be shared instantly and inexpensively on a global scale. Commerce is being accelerated by the digital and network revolutions and the role of commerce is to both exploit and absorb these shocks (Brand, 1999). In a network economy, the value is created and shared by all members of a network rather than by individual companies and that economics of scale stem from the size of the network – not the enterprise (Kelly, 1998).
Similarly, because value flows from connectivity, an open system is preferable to a close system because the former typically have more nodes. It also indicates that such networks are blurring the boundaries between a company and its environment (Boyett & Boyett, 2001). The larger the network, the greater its value and desirability. In a networked economy, success begets more
‧
success. Under an opened and global environment without boundaries, malicious threats through Internet connection becomes a super emerging market – all digital citizens are threatened by it in every format, such as computer virus infection, hacker attacking, and so on.
Company X was hence growing rapidly in the surroundings.
In the late 1990s, the computer software industry expands dramatically by following to the dot-com business models with blooming of the Internet technology. These firms operated under the belief that when a new market comes into being which contains strong network effects, firms should care more about growing their market share than about becoming profitable. This was believed because market share will determine which firm can set technical and marketing standards and thus determine the basis of future competition.
Contemporary software industry is obviously a combination of economics of knowledge and network: It is not of scarcity, but rather of abundance. Information and knowledge can be shared, and grow through application. Human capital – competencies – are a key component of value in a software house, yet few companies report competency levels in annual reports. In contrast, downsizing is often seen as a positive "cost cutting" measure. The entire cost to run a software house is relative lower than manufactures millions times is a well-known fact, especially interlocking with driving forces of network economy, such globalization achieved by the Internet connection and IT. The production and distribution of software which in turn, results in collective intelligence. Software becomes much easier to access or apply as a result of networked databases. Moreover, with computer networking and connectivity, developments such as the Internet bring the “global village” ever nearer. Crowdsourcing through the Internet concept is popular today to develop software and effectively lower down the cost. As a result, software goods and services can be developed, bought, sold, and in many cases even delivered over electronic networks with low cost (mainly is one-time human intelligence) but creates huge returns over connected media rapidly.
2.2.2 Role of Research and Development (R&D) in Software Company
Knowledge economy stage today has been marked by the upheavals in technological innovations and the globally competitive need for innovation with new products and processes that develop from the research community (e.g. R&D factors, universities, labs, educational institutes). In the knowledge economy, the specialized labour force in characterized as computer literate and well-trained in handling data, developing algorithms and simulated models, and
‧
國立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
innovating on processes and systems. Today’s economy is far more dynamic and that comparative advantage is less relevant than competitive advantage which rests on “making more productive use of inputs, which requires continual innovation” (Porter, 1998).
Because of the nature of software and the rapidity of technical development, continual R&D investment is critical. In the most of time, R&D plays the most critical role to grow in software industry by developing innovative products or services with systematically project management methodologies. In software development, regardless waterfall or agile model used, the cycle to develop a software product always consist of at least 3 stages – (1) Design:
including both the business and technical specification, (2) Coding: the development itself, and (3) Testing: the quality management. The Unified Modelling Language (UML) sequence diagram of interaction between different parties in R&D group of the software industry
Figure 2.5 General interaction between software R & D
(Wikipedia, 2007)
Basically, not all software R&D cost are categorized as expense. “Does software represent an asset and should that asset be on the balance sheet (i.e. expensed)?” has been a core question in software accounting domain since 1980s. For example, within six-phase hardware and software development process in Company Y, certain activities are expensed or capitalized and not the entire process. In the phase – planning, architecture, specifications, and design implementation are expensed and implementation and support are capitalized. Company Y sees
‧
software development as a process and holds that feasibility phases of the process should be expensed (Pridemore, 1983). It is quite understandable the accounting recognition of Company Y does because of its core business is IT consulting services today. For the rest of software houses, it may be contrary to Company Y totally since the software development is the core business, such as Microsoft or SAP. Regardless what software products or services are provided, expense is definitely brought during software R&D in most of company from either business or accounting perspective.
R&D in software houses are delivering products or services through effective project management in most cases. “Project management” as defined in this study includes the activities of screening, selecting, evaluating, budgeting, scheduling, and controlling R&D projects. This emphasis was not unfounded, since most R&D organizations, regardless of their structure and motivation, conduct many resource allocation and related management activities for the achievement of specific goals on a project-by-project basis (Liberatore & Titus, 1983).
In order words, we can assume to have good visibility to understand the expenses of R&D in software houses as long as understanding what cost generated from every R&D projects.
Firms usually do not specify fixed R&D budget size, but decide on projects one at a time.
One research investigated the R&D evaluation and control procedures used in British industry and found: (1) nearly all organizations use at least one standard financial method for project evaluation; (2) about one-third used mathematical models, and/or weighted checklists or project ranking indices as part of their project assessment procedure; and (3) only few of them did not use any scheduling techniques. It also found several organizations expressed dissatisfaction with available resource allocation and scheduling procedures, and discontinued their use (Allen, 1970).
The other empirical study was conduct to study the R&D evaluation, selection and control procedures used in US industrial forms. Heavy use of financial methods for project evaluation;
however, formal quantitative methods for selecting projects were not widely used. Since 1970s, the growth in available quantitative methods was coupled with the advances in computer technology for data acquisition, retrieval and analysis (Liberatore & Titus, 1983). With aid of computer technology, R&D projects are able to be controlled and managed in systematic but efficient manner, especially Multi-national Corporation with distributed R&D departments.
Simple and interactive systems for resource allocation and multi-project tracking and control is welcomed by R&D project stakeholders. It does underscore the need for such a system to have
‧
國立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
up-to-date data, and the ability to obtain information concerning project costs and milestone progress with a modicum of computer-related experience and effort.
The research also discovered any formalized budgeting system which evaluate the cost and benefit trade-offs over the set of available projects is not utilized. Many use the standard project control sheets. These documents are used to help justify the proposed budget and allow tracking of costs and milestones. Because of the diversity of project types, resources and criteria within the budgeting unit, math programming or financial model are generally not used of the budgeting and resource allocation process. Gantt charts are principally used for project control, and techniques and methods develop have made some inroads into R&D project management, such as Program Evaluation Review Technique/Critical Path Method (PERT/CRM) (Liberatore
& Titus, 1983). With evolution of IT technology, sophisticated R&D project management becomes achievable. Company X hence implemented a completed planning and controlling system to manage project management. It will be described in the later section in detail with impacts to R&D projects, seen as core drivers to grow of Company X business.
2.2.3 Driver-Based Budget Planning
As mentioned in previous sessions, in the majority of organizations, the budget is the most important tool used to control performance. Executives might have spent time off-site working at clarifying their strategies. The resulting strategies might be very sound and take account of all the likely external and internal issues that impact the organization’s financial performance both in the short term and in the foreseeable future. It might have been translated into a success map with appropriate measures and targets being cascaded down to individual managers. It is the budgeting process that takes precedent. Figure 2.6 shows detailed enterprise-wide budget planning process by different layers and components.
‧
國立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Figure 2.6 Enterprise Budget Planning Model
(Trend Micro Inc. & Deloitte Touche Tohmatsu Ltd., 2011)
However, the budgeting process has received an increasing amount of criticism in recent years. It takes too long and therefore costs too much. Because of the rate of change in many markets, the annual budget is out of date almost before it is completed. That is why the ability to re-forecast more frequently is of such importance. Organizations need to routinely reassess the future and realign their operational plan and resources accordingly.
With the rise of “management by objectives (MBO)” and individual accountability, accounting results such as income, return on capital employed and return on investment cam to be used as targets for everyone from board members right down to departmental managers. This led to the budget becoming a critical determinant of many people’s benefit. Linking rewards to relative measures such as improvements over the previous year or outperforming industry peers will encourage organizations to become more dynamic and responsive to internal and exchange changes and to continually seek out opportunities that create value. However, unless the integration of planning and budgeting into a seamless process, organization are unlikely to be able to re-forecast with the frequency they desire, no matter how they want to reward their staff.
The traditional budgeting process is hierarchical and focuses on collecting and consolidating individual contributions to produce the enterprise profit and loss account. But when managers generate their departmental budgets, they are modelling the operational drivers
‧
and causal relationships that run horizontally across an organization. When asked to produce a budget or a re-forecast, the managers’ first concern is that the department upstream of them provides them with a reliable forecast of future demand. In fact, until they have received this, they cannot start their own departmental planning.
Driver-based budgeting uses both non-financial and financial driver data to model line item expense. Drivers will differ by industry and even by company. It is a piece of non-financial or financial data which when changed directly impacts either revenues or expenses, ultimately changing the forecast profit and loss account, cash flow and balance sheet.
The term “driver” is used for assigning expenses to activities costs to cost objects in Activity-based cost (ABC). Many of the drivers an organization would use for planning and budgeting are identical to those they use for cost assignments in ABC. Many drivers would also be important metrics to monitor in CPM. Since the definition limits drivers to those things, which directly impact either revenues or expense, they can be included in a rule formula that will directly calculate either a revenue figure or a line item expense.
There are many different types of drivers that are used in planning and budgeting. These including the following:
Quantitative measures of demand: including both the forecast level of demand for the products or services sold customers and the level of demand faced by individual departments. For example: Market size and market share, the number of sales units of a product, the number of inbound telephone calls, the number of active customers, etc.
Consumption rates, productivity rates or cycle times: measuring the amount of resource required to satisfy demand or produce a unit of output. For example: the average duration of a call; the amount of space needed by each full-time equivalent, etc.
Unit resource cost: the average cost of a unit of resource during a period. For example:
the cost of a litre of fuel, the average salary cost of a particular grade of staff, etc.
Unit selling prices: the average selling price of a product or service. For example: the average premium of a particular type of insurance policy, the anticipated fee for each consulting engagement, the anticipated selling price for a particular product, etc.
Some drivers are only important in one department. For instance, the drivers involved in
‧
國立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
forecasting staffing requirements and salary expenses in a contact centre are only important to the department manager and their superior. In a driver-based budgeting model, this will be a simple rule that restricted to this department, but applies to all periods and versions.
Many drivers run horizontally across organizations, spanning departments just like the business processes they are part of. The output of one department become the input of other departments downstream from them. In certain instances, this may be a one-to-one relationship.
In other instances, such as when a new sales forecast is produced, it will be a one-to-many relationship with virtually every department needing to re-forecast. The following figure 2.7 takes technical support service cost as an example and shows an inter-departmental driver-based planning process to a software house.
Figure 2.7 Driver-based Planning Process in a Software House
(Trend Micro Inc. & Deloitte Touche Tohmatsu Ltd., 2011)
The rule needed to do this is no more complex than that needed for an intra-department rule. It is just that the output of the rule becomes the input for a number of other departments.
What is important is that these downstream departments are quickly alerted that they need to re-forecast themselves and that they have immediate access to the new data.
Most driver-based planning and budgeting models start from some measure of demand. In consumer markets, this might be a market-based model with market size, market growth and
‧
國立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
market share being the drivers of sales volumes and demand across the entire model.
Organization competing in business-to-business markets might start by using the amount of sales and marketing activity as the primary driver of demand for their model. However, in certain manufacturing and supply industries, plant and assets have to be in continuous use around the clock if the organization is to be commercially viable. In such situations, production capacity has to be the primary input any driver-based model with most other resources being driven by the need to produce and sell the output for the highest possible price. Most will have iteratively worked out the way their business works and will already be using an appropriate methodology to model revenues and resource requirements. All finance need to do is integrate these models into the budgeting process.
Figure 2.8 Types of Driver-based planning and budgeting model
(Barrett, 2007)
Knowing that the expenses for a responsibility centre are above or below plan is incomplete information. Until we know more we cannot take any action. However, if we have access to information about the level of demand facing that responsibility centre during the
‧
國立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
period, the amount of resource required to satisfy that level of demand and the amount of resource actually provided, we know exactly what action to take. We can immediately see where excess capacity exists and take action to bring it into line with what is actually provided, we know exactly what action to take. We can immediately see where excess capacity exists and take action to bring it into line with what is actually required. At a time when profitable revenue growth is increasingly difficult to achieve, keeping resources tightly aligned with trading is a problem common to many sectors. Sometimes called “consumption-based” planning and budgeting or “resource consumption analysis”, the above approach demonstrates the key characteristics of driver-based planning and budgeting: it is all about building a dynamic budget where drivers are used to model revenues and line item expenses within the planning and budgeting application (Barrett, 2007). The following figure 2.9 shows a high-level planning model overview for the software industry in common practice.
Figure 2.9 Planning Model Overview of Software Industry
(Trend Micro Inc. & Deloitte Touche Tohmatsu Ltd., 2011)
‧
Much organization theory argues that efficiency requires bureaucracy, that bureaucracy impedes flexibility, and that organizations therefore confront a trade-off between efficiency and flexibility. Managers must choose between organization designs suited to routine, repetitive tasks and those suited to nonroutine, innovative tasks. However, all forms of flexibility present a common challenges: efficiency requires a bureaucratic form of organization with high levels of standardization, formalization, specialization, hierarchy, and staffs, but these features of bureaucracy impede the fluid process of mutual adjustment required for flexibility; and organizations therefore confront a trade-off between efficiency and flexibility (Knott, 1996) (Kurke, 1988). Specifically, organizations should adopt a mechanistic form if their task is simple and stable and their goal is efficiency, and they should adopt an organic form if their task is complex and changing and their goal is therefore flexibility (Burns & Stalker, 1961).
Much organization theory argues that efficiency requires bureaucracy, that bureaucracy impedes flexibility, and that organizations therefore confront a trade-off between efficiency and flexibility. Managers must choose between organization designs suited to routine, repetitive tasks and those suited to nonroutine, innovative tasks. However, all forms of flexibility present a common challenges: efficiency requires a bureaucratic form of organization with high levels of standardization, formalization, specialization, hierarchy, and staffs, but these features of bureaucracy impede the fluid process of mutual adjustment required for flexibility; and organizations therefore confront a trade-off between efficiency and flexibility (Knott, 1996) (Kurke, 1988). Specifically, organizations should adopt a mechanistic form if their task is simple and stable and their goal is efficiency, and they should adopt an organic form if their task is complex and changing and their goal is therefore flexibility (Burns & Stalker, 1961).