Chapter 5: Strategic Courses of Action for Small and Micro Enterprises Regarding the Use of Information Technology

This article series contains my master’s thesis “Outsourcing the IT Strategy Development Process in Austrian Small and Micro Enterprises”, which I wrote as part of the university program Management in Information and Business Technologies at the Alpen-Adria-Universität Klagenfurt.

Chapter: Introduction
Chapter: Definitions
Chapter: Relevant Environments of Small and Micro Enterprises in Austria
Chapter: Strategic Goals and Critical Success Factors of an IT Strategy
Chapter: Strategic Courses of Action for Small and Micro Enterprises Regarding the Use of Information Technology
Chapter: IT Controlling in Small and Micro Businesses
Chapter: Summary and Outlook

5. Strategic Courses of Action for Small and Micro Enterprises Regarding the Use of Information Technology

5.1. Linking Strategic Goals with Courses of Action

For the goals set during strategy development and the projects resulting from them, measures or courses of action for achieving the goals are defined. The link is made via a cause-and-effect chain, as shown as an example in Figure 9. Every course of action must contribute value to achieving one or more strategic goals.

An IT strategy has to be developed individually for every company. This results in a large number of possible courses of action, whose complete description would go beyond the scope of this thesis. For this reason, the coming section deals only by way of example with nine fields of action that should be addressed in nearly all companies - regardless of industry and size - as part of implementing an IT strategy.

5.2. Requirements and Procurement Management

Every purchase of hardware, software or IT services causes monetary or personnel effort. Reducing the volume and complexity of procurement transactions and steering the procurement process is the task of procurement management. Managing contracts such as framework, individual and maintenance contracts and optimizing them¹ (price, volume, license models), as well as deciding between in-house production and external sourcing (“make or buy”), also fall within the remit of procurement management.²

The procurement process consists of the requirements process, the ordering process, the delivery process and further sub-processes, as shown as an example in Figure 12:³

Figure 12: Main and sub-processes of the procurement process.⁴

In the requirements process, requests are collected, categorized and evaluated. Based on the data from application management (see chapter 5.3), platform management (see chapter 5.5) and lifecycle management (see chapter 5.4), the optimal solution that fits the IT strategy can be selected for the need.⁵ The exact requirements must already be defined at this point or be defined here before approval is issued. Requirements management additionally serves as the central point of contact for all requests and can thereby prevent parallel orders and ensure that agreed purchasing conditions are used across the company.⁶ The requirements process ends with approval and ordering.

The ordering process deals with handling the orders and complying with the purchasing and contract conditions. It is important to ensure legal compliance (see chapter 3.3), for example correct licensing of software, already during the ordering process.

The last step of the procurement process is handling the delivery. This includes receiving and assigning (which order does the delivered item belong to?), checking (was the ordered item delivered completely and undamaged?) and filing and archiving (for example of license documents).⁷ These sub-processes can vary depending on the company’s situation.

In practice, requirements and procurement management in small and micro enterprises is mostly a very manageable area, handled in the best case by a single department or a single person. Handling the ordering and delivery process should be a standard process in these companies as well. A service provider can therefore mainly take part in a supporting role in the requirements process, for example by aligning the requirements specification with the IT strategy and by selecting the vendor. In addition, it can take on an advisory function for compliance topics.

5.3. Application Management

As part of application management, the IT application systems used in the company are documented, evaluated and regularly checked for effectiveness and relevance within the given IT architecture.⁸

Countless applications exist in every company, from the company-wide ERP system to a single Excel macro⁹ for calculating a specific key figure. The task of application management is to capture this multitude of applications, evaluate their contribution to the company and, based on that evaluation, either include the application in the company standard, consolidate it into an existing standard application or retire it.¹⁰ For this purpose, a list of all standard applications in use is created and assigned to the business processes. If an application cannot be assigned to a business process, it makes no contribution to the company and is retired.

The application documentation helps to clean up the application and system landscape. A key advantage is that duplicate or no longer used applications are easy to spot. It also makes it possible to unify applications for comparable business processes.¹¹ The relationships and dependencies between business processes and applications (and thus the application systems) also become obvious through the documentation.¹² This information makes it easier to estimate the effects of modifications to standard systems and serves as valuable input for platform management.

In practice, keeping the application documentation in a simple table has proven useful for small businesses. The assignment of applications to business processes can be mapped and evaluated in a matrix. This documentation should be updated and reviewed at least once a year.

Figure 13 shows an example of installed applications being surveyed and assigned to business processes. Applications that are not assigned to any process can thus be identified at a glance:¹³

Figure 13: Example of application documentation in small and micro enterprises.¹⁴

Maintaining the application documentation is rarely a core competence in small and micro enterprises, so application management can be handed over completely to a service provider. The annual review of the application documentation takes place between the management or the department head and the service provider, while the latter can carry out all application maintenance, updating and administration.

5.4. Lifecycle Management

Lifecycle management regulates the creation, operation and replacement of IT systems. Application lifecycle management in particular deals with the IT application landscape and was one of the top 5 topics in Capgemini’s IT Trends 2012.¹⁵ Technology lifecycles in IT are very short. Moore’s law, for example, describes a doubling of the transistors built into a processor every 18 months.¹⁶ The lifecycles of operating systems and user software are also getting shorter. A good example of this development is the popular web browser “Mozilla Firefox” with a lifecycle of only 12 months and a monthly release cycle.¹⁷ To master this abundance of new and updated technologies, every company needs a comprehensive and forward-looking strategy.¹⁸

While new technologies bring many advantages, including higher performance, more energy efficiency and better support for business processes, every upgrade also carries risks. Besides the costs of an upgrade, that is, investing in new hardware and software, migrating to the new system and training the users, compatibility with all connected systems must be ensured.

Besides installation and regular maintenance, lifecycle management also covers the planned decommissioning and disposal of replaced IT systems. This includes, for example, terminating maintenance and license contracts, proper data erasure and disposal of hardware.¹⁹

For small and micro enterprises, a simple list of the systems and applications in use with basic lifecycle data (warranty period, license term, update period) makes sense. Based on this list, the following questions are answered in an annual review and measures taken where necessary:

Does the system fulfill its purpose and run economically?
How much longer can the system be used economically? When does it have to be replaced?
Can the system be repaired or replaced in case of failure? What effort is involved?
Which systems are connected to it? What effort results from a failure?

Figure 14 shows as an example how the basic lifecycle data of a micro enterprise’s IT systems can be presented in a simple table. Colored symbols highlight acute and imminent need for action:

Figure 14: Example IT lifecycle table of a micro enterprise.²⁰

For small and micro businesses, it is in most cases more economical to hand planning and updating of the lifecycle data, commissioning of new systems and disposal of old ones, and documentation of the dependencies over to an outsourcing partner.²¹ Only the annual review of the need for action has to be done by the management or the department head.

5.5. Platform Management

Platform management deals with the questions of which hardware and software components are used in the company and sets the guidelines for future procurement. The goal is to achieve a high degree of standardization and automation by reducing the number of different components.²² If the same hardware components are used throughout the company, the availability of replacement devices and spare parts implicitly increases. Training costs for users and technical staff also decrease.²³

In small and micro enterprises, for example, it is often common to use consumer hardware. While the purchase costs of these devices are lower than for business models, consumer models in most cases have to be sent to the manufacturer’s repair center for repair. Since sensitive company data could be viewed by third parties in the process, this is often too risky even for small companies. Repair by an on-site technician is therefore the preferred solution in nearly all cases, but it comes with additional costs. A cost analysis as part of platform management could have revealed the hidden follow-up costs in advance.

By developing company-wide and department-wide platform standards, the maintenance and training effort of existing systems can be reduced even further, while additional systems for new employees can be provided more quickly.

Since developing a platform standard is very easy with technology support, but the knowledge to implement it is hardly available in small and micro enterprises, support from an IT service provider is a good option.²⁴ The provider can support the development and further development of the standard in all phases - from design to implementation and maintenance.

5.6. Innovation Management

Innovation management is an independent management discipline not tied to IT, especially in larger companies.²⁵ In this thesis, however, only the aspects of innovation management directly related to IT are covered. In the following, the term “innovation management” is therefore equated with “IT innovation management”.

Innovation is one of the core elements of information technology and, through the dual role of IT, can bring a company competitive advantages or enable new business areas.²⁶ Innovation, however, quite often requires a change of processes and therefore also carries risks. No other industry produces as many innovations in as short a time as IT itself. Not all of them have reached a sufficient maturity level to meet the demands of business reality, though.²⁷ Innovation must therefore be steered by IT innovation management.

The basis for the innovation process is the 10 most important “key business drivers”, which vary with the company’s reality.²⁸ Aligning and evaluating the innovation projects between the “key business drivers” and the IT strategy is the main task of innovation management.²⁹ Innovation approaches are continuously supplied in large numbers from the most varied sources - above all customers, suppliers, competitors and the company’s own employees. They must, however, be recognized as such, documented and evaluated.

In small and micro enterprises, this is easiest to achieve through a suggestion system or, later, through idea management.³⁰ Innovation approaches coming from the customer and supplier side are often hidden behind complaints or criticism and are therefore hard to recognize.³¹ Combining innovation management with complaint and feedback management is therefore conceivable.

Once an innovation approach has been assessed as consistent with the “key business drivers” and the IT strategy, carrying out a feasibility analysis is recommended. For extensive innovations, a profitability calculation is also recommended. In small and micro enterprises whose focus is not on IT, a service provider can support the innovation manager with the alignment with the IT strategy and the feasibility analysis and supply input for the profitability calculation.

When implementing the innovation, the technical aspects (such as adapting and upgrading the affected IT systems) can be carried out by a service provider.

The organizational aspects - that is, adapting company processes - require steering by the innovation manager or the management or department head even in small companies. They cannot be realized by a service provider alone.³²

5.7. Risk Management

The starting points of risk management are identifying the hazards, their causes and effects, and then analyzing and evaluating the possible risks.³³ Identified hazards are categorized by probability of occurrence and impact and mapped in a risk graph.³⁴ Table 3 shows an example risk graph with the axes “probability of occurrence” and “impact” and helps to classify the risks into priority levels 1 (red 🟥, “high priority”), 2 (yellow 🟨, “normal priority”) and 3 (green 🟩, “low priority”).

Impact Probability of occurrence	insignificant	minor	noticeable	critical	catastrophic
frequent	🟨 2	🟨 2	🟥 1	🟥 1	🟥 1
possible	🟨 2	🟨 2	🟨 2	🟥 1	🟥 1
rare	🟩 3	🟨 2	🟨 2	🟨 2	🟥 1
very rare	🟩 3	🟩 3	🟨 2	🟨 2	🟨 2
improbable	🟩 3	🟩 3	🟩 3	🟨 2	🟨 2

Table 3: Example of a risk graph.³⁵

In its simplest form, the hazards are collected in a list and sorted by the priority calculated via the risk graph, as shown as an example in Table 4:

Hazard	Probability	Impact	Priority
Fire	rare	catastrophic	🟥 1
Power outage	possible	critical	🟥 1
Water, liquids	rare	critical	🟨 2
Earthquake	improbable	critical	🟨 2
Internet connection outage	possible	minor	🟨 2
Loss of key personnel	possible	noticeable	🟨 2
Vandalism	very rare	minor	🟩 3

Table 4: Example - hazards prioritized using a risk graph.³⁶

Regardless of priority, every risk must be evaluated and treated. A known risk can either be avoided or reduced or limited through personnel, technical or organizational measures.³⁷ If a risk cannot be avoided, reduced or limited, it can be insured if applicable; otherwise it must be accepted and borne by the company itself, and counts as “residual risk” together with the risks that cannot be identified. In any case, it is necessary to keep track of how the risks develop and to take measures where necessary.

Figure 15: Risk assessment.³⁸

In small and micro enterprises, the total of possible IT risks stays within a manageable range, depending on the company form and orientation. For a first analysis, the Austrian Federal Economic Chamber’s (WKO) federal division “Information and Consulting” provides a risk analysis tool for small and medium-sized enterprises (SMEs) in the form of a Microsoft Excel spreadsheet.³⁹ The analysis can be carried out independently or with the support of a service provider. Experts should be consulted when working out measures.

5.8. Data Management

Every company produces large amounts of data every day. Emails, text documents, presentations, evaluations, program code and calculations, but also phone calls and personal meetings, create data that has to be evaluated, processed and stored or discarded. Capture is either automated or manual, with the latter being much more error-prone. The basic principle of data management is to know which data sets exist in the company and to make sure a responsible owner with concrete rights and duties is defined for all data.⁴⁰

Tiemeyer describes the need not to lose the overview of company data as part of IT architecture management:

The data needed to realize business processes must be identified and documented and described with their relationships in a data architecture. The description should be made in a model and a form of presentation that reproduces the entirety of the data completely, understandably and consistently for all actors involved in information system development processes.⁴¹

One of the most important points in data management is data protection. Business-critical, confidential and personal data have a higher need for protection against unauthorized access, modification, deletion or disclosure. The main basic threats in data management concern the availability, integrity and confidentiality of the data:⁴²

Data is only considered available if all programs, hardware and other means needed for processing are available as well.
The integrity of the data is only given if it is correct and unaltered.
Confidentiality means that data can only be read or edited by authorized persons. This applies both to stored data and to data transmission.

The first step is to classify data by confidentiality, sensitivity, availability and integrity.⁴³ For small and micro enterprises, classification into the three levels “confidential”, “internal” and “open” has proven useful in practice:

Confidentiality	Description
Class V “confidential”	Class “V” applies if the information is protected by criminal-law secrecy, if its disclosure would also create the risk of harming the company’s interests, or if keeping it secret is in the company’s particular interest.
Class I “internal”	Class “I” applies if unauthorized disclosure would run counter to the company’s interests. (e.g.: internal correspondence, internal phone directories, organization charts, all unclassified information)
Class O “open”	For information that has been expressly released for publication. (e.g.: laws, regulations, press releases)

Table 5: Confidentiality classes.⁴⁴

Classification by sensitivity follows the Austrian Data Protection Act (DSG) §§8-9:⁴⁵

Sensitivity	Description
Class N	Class N “non-personal information”: All information that does not fall under §§8 and 9 DSG.
Class P	Class P “personal, non-sensitive data”: All information that falls under §8 para. 1 - 3.
Class ST	Class ST “personal data with criminal-law content”: All information that falls under §8 para. 4 DSG.
Class S	Class S “sensitive personal data”: All information that falls under §9 DSG.

Table 6: Sensitivity classes.⁴⁶

To be able to express the availability requirements of IT applications and the associated data, defining the following availability classes has proven useful for small businesses:

Availability	Description
Class 1	No precautions / uncritical. No special precautions are taken for the IT application. Data loss or failure of the IT application for an indefinite time is conceivable. This does not hinder the affected organizational units in performing their tasks, or only to an acceptable extent. The risk of data loss and of the effort required to reconstruct the data is accepted.
Class 2	Data backup. Common backup measures are provided for the IT application; data loss is ruled out. In case of technical problems, the IT application can only be put back into operation on the original production system after they have been fixed. The backup is stored off-site.
Class 3	Redundant infrastructure. The infrastructure for the IT application is designed so that, thanks to redundancy, operation can continue without interruption if an IT component fails. The data is additionally backed up.

Table 7: Availability classes.⁴⁷

A company’s data should always be available with the highest possible integrity. Technical and organizational measures (data backup, protection against viruses and malware, digital signatures) are to be used for this.⁴⁸ For small organizations, using two integrity classes with different protection needs is recommended:

Integrity	Description
Class U “uncritical”	Applies if no consequences at all are to be expected for the company from a loss of integrity.
Class K “critical”	Applies if significant consequences, both financial and/or loss of image, are to be expected for the company from a loss of integrity.

Table 8: Integrity classes.⁴⁹

Ensuring data quality is always the author’s responsibility, as is classification by confidentiality and sensitivity. This implicitly means that every employee must be familiar with the rules for handling data and the classification guidelines.

In the broadest sense, this also applies to external consultants and service providers, provided they get access to company data.⁵⁰ In addition, to maintain a consistent data state, measures should be taken to capture data only once where possible and store it in a central place.

In practice, it is often forgotten that data is also subject to a lifecycle. A regular review of the data protection criteria described is therefore indispensable. Availability, for example, is checked by performing a restore test of the data backup.

5.9. Quality Management

In most companies, quality management in IT projects is not practiced or only as a side issue, as the Standish Group studies regularly show.⁵¹ The reasons usually given are the high effort for quality measures and low acceptance among employees.⁵² At the same time, it is hardly possible to measure the costs (losses) caused by insufficient quality without first investing in quality management.⁵³ The prerequisite for successful quality management is therefore full management commitment. Since quality management has already been covered extensively in the literature, this thesis only touches on points critical for small and micro enterprises.

In IT, quality mostly means fulfilling the requirements previously defined by the client.⁵⁴ The basis for this is to formulate and understand the requirements completely. In addition, even the wishes that are not explicitly voiced must be met to deliver quality in the client’s eyes. These mostly concern industry-standard and application-specific standards as well as legal regulations. Quality can therefore only be achieved if all explicit and implicit requirements and expectations are understood and met. There are two approaches for the successful development of IT projects:⁵⁵

Sequential development, for example following the waterfall or V-model.
Iterative development, such as following RUP (Rational Unified Process) or - for software development projects - agile programming with Scrum.

Sequential development focuses on specifying the requirements exactly as early as possible. This reduces the risk of technical errors - that is, the risk of developing the product wrongly. In return, requirements that the client defined wrongly or the contractor didn’t understand increase the risk of functional errors, that is, developing the wrong product.⁵⁶

The iterative approach is based on implementing the known requirements in short cycles with subsequent feedback. Thanks to the quick feedback cycles, the client can define their requirements more precisely in all project phases with little effort. Since many requirements are not yet defined at the start of the project, iterative development carries a higher risk of developing the product wrongly because of early, wrong design decisions.⁵⁷

Figure 16 contrasts the different flows of sequential and iterative development schematically:

Figure 16: Sequential development versus iterative development.⁵⁸

The question of which approach is preferable for developing IT projects in small organizations cannot be answered definitively. It depends much more on the project’s framework conditions. The iterative approach does help to reduce the documentation and administration effort in small, manageable projects and can speed up these projects without increasing the risks. Especially for the internal projects handled to implement the IT strategy, which are the focus of this thesis, the iterative approach also helps to close the gap between theory and practice.⁵⁹

5.10. Knowledge Management

The term “knowledge management” covers all of a company’s activities in dealing with knowledge. It has become an important topic in many companies in recent years, as it was increasingly recognized that a large part of a company’s value depends on the ability to create and manage knowledge.⁶⁰ Especially in small organizations, it is essential to spread existing knowledge across several people so it isn’t lost in the event of a short-term absence or an employee leaving. A basic distinction is made between explicit and implicit knowledge. Formally documented knowledge is called explicit knowledge, while implicit knowledge exists only in employees’ heads. The first goal of knowledge management is to document employees’ implicit knowledge and thus transform it into explicit knowledge. Going further, the knowledge of individual employees is to be mobilized and condensed at the organizational level in cooperative processes, in order to work out solutions to complex problems, for example by combining knowledge carriers. This process should include not only the knowledge of the company’s own employees but also that of customers, suppliers and service providers.

The success of knowledge management depends heavily on acceptance by the employees. The still common “knowledge is power” attitude prevents knowledge from being passed on to colleagues. In addition, knowledge management activities are often laborious for the individual and the benefit is hard to measure.⁶¹

IT support in this phase ranges from word processing and presentation software to audio and video editing. The generated documents should then be entered into a knowledge base.

Knowledge management is a corporate discipline that is not limited to IT and that IT can support very well. The technical aids range from word processing and presentation software through audio and video editing to training and knowledge databases. Successful knowledge management, however, is based mainly on the right organizational processes:

Effective knowledge management means 80% support by management and organization and 20% technology.⁶²

A company therefore cannot outsource its knowledge management to a service provider; it has to lay the foundation for it itself. A service provider can, however, act in an advisory role in the implementation and take over providing and maintaining the necessary tools. In addition, service providers can and should supply content for knowledge management, such as documentation, manuals and guides for the IT systems they look after.

Cf. (Groll, 2011, p. 384), (Resch, Brenner, & Schulz, 2009, p. 169f). ↩
Cf. (Mödritscher, Rausch, & Mussnig, 2007, p. 439f), (Resch, Brenner, & Schulz, 2009, p. 173). ↩
Cf. (Groll, 2011, p. 384). ↩
Source: (Groll, 2011, p. 384) (slightly modified). ↩
Cf. (Resch, Brenner, & Schulz, 2009, p. 172). ↩
Cf. (Groll, 2011, p. 385). ↩
Cf. (Groll, 2011, p. 384). ↩
Cf. (Schmid, Management von Anwendungssystemen, 2007, p. 175). ↩
Microsoft Excel is very often used as an all-purpose tool in all areas of the company in small businesses. ↩
Cf. (Tiemeyer, Enterprise Architecture Management: IT-Architekturen erfolgreich planen und steuern, 2011, p. 102), (Rüter & Schröder, 2006, p. 108). ↩
Cf. (Tiemeyer, Enterprise Architecture Management: IT-Architekturen erfolgreich planen und steuern, 2011, p. 128). ↩
Cf. (Schmid, Management von Anwendungssystemen, 2007, pp. 175 and 178f). ↩
The matrix shows the assignment in a fictitious company and serves general understanding. ↩
Source: author. ↩
Cf. (Capgemini, 2012, p. 33). ↩
Cf. (Resch, Brenner, & Schulz, 2009, p. 213). ↩
Cf. (The Mozilla Foundation, 2013, n.p.). ↩
Cf. (Schmid, Management von Anwendungssystemen, 2007, pp. 204, 217f and 223), (Rüter & Schröder, 2006, p. 213). ↩
Cf. (Groll, 2011, p. 384), (Schmid, Management von Anwendungssystemen, 2007, p. 212ff). ↩
Source: author. ↩
Cf. (Schmid, Management von Anwendungssystemen, 2007, p. 207). ↩
Cf. (Tiemeyer, Enterprise Architecture Management: IT-Architekturen erfolgreich planen und steuern, 2011, p. 86). ↩
Cf. (Resch, Brenner, & Schulz, 2009, p. 131). ↩
Cf. (Schmid, Management von Anwendungssystemen, 2007, p. 207). ↩
Cf. (Walter, 2005, p. 274f). ↩
Cf. (Ward & Peppard, 2005, p. 51), (Wintersteiger & Tiemeyer, 2011, p. 65). ↩
Cf. (Arenz, 2003, p. 117), (Resch, Brenner, & Schulz, 2009, p. 213f). ↩
Cf. (Arenz, 2003, p. 124). ↩
Cf. (Resch, Brenner, & Schulz, 2009, p. 222), (Arenz, 2003, p. 127). ↩
Cf. (Walter, 2005, p. 163). ↩
Cf. (Walter, 2005, p. 284). ↩
Cf. (Walter, 2005, p. 278). ↩
Cf. (Königs, 2006, pp. 1 and 30f), (Bergmann & Tiemeyer, 2011, p. 485f), (Schmid K. , 2011, p. 547). ↩
In the literature also called “risk matrix”. Cf. (Königs, 2006, p. 168f), (Ketterer, 2009, p. 9), (Schmid K. , 2011, p. 562ff). ↩
Source: adapted from (Ketterer, 2009, p. 9). ↩
Source: author. ↩
Cf. (Schmid K. , 2011, p. 573ff). ↩
Source: adapted from (Ketterer, 2009, p. 10). ↩
Cf. (WKO, 2010, n.p.). ↩
Cf. (Wintersteiger & Tiemeyer, 2011, p. 67). ↩
(Tiemeyer, Enterprise Architecture Management: IT-Architekturen erfolgreich planen und steuern, 2011, p. 104). ↩
Cf. (Walchshofer, 2010, p. 28), (A-SIT Zentrum für sichere Informationstechnologie - Austria, 2013, p. 135ff). ↩
Cf. (Schmid K. , IT-Security-Management, 2011, p. 531f). ↩
Source: adapted from (A-SIT Zentrum für sichere Informationstechnologie - Austria, 2013, p. 136). ↩
Cf. (Bundeskanzleramt der Republik Österreich, 2010). ↩
Source: adapted from (A-SIT Zentrum für sichere Informationstechnologie - Austria, 2013, p. 137). ↩
Source: adapted from (A-SIT Zentrum für sichere Informationstechnologie - Austria, 2013, p. 545). ↩
Cf. (Schmid K. , IT-Security-Management, 2011, p. 533), (A-SIT Zentrum für sichere Informationstechnologie - Austria, 2013, pp. 38, 47f and 60). ↩
Source: author. ↩
Cf. (Schmid K. , IT-Security-Management, 2011, p. 542f). ↩
Cf. (The Standish Group International, Inc., 2012), (Nehfort, 2011, p. 403). ↩
Cf. (Nehfort, 2011, p. 405). ↩
Cf. (Nehfort, 2011, p. 406). ↩
Cf. (Walter, 2005, p. 190f). ↩
Cf. (Nehfort, 2011, p. 413ff). ↩
Cf. (Nehfort, 2011, p. 414). ↩
Cf. (Nehfort, 2011, p. 417f). ↩
Source: (Bittner, 2006, n.p.). ↩
Cf. (Nehfort, 2011, p. 420). ↩
Cf. (Laudon, Laudon, & Schoder, 2010, p. 661). ↩
Cf. (Laudon, Laudon, & Schoder, 2010, p. 667). ↩
(Laudon, Laudon, & Schoder, 2010, p. 671). ↩