Master Thesis
Enterprise Resource Planning at small
subsidiaries of a multinational beer brewer.
Author: Steven van der Scheer Studentnumber: 1273868
Rijksuniversiteit Groningen
1st Tutor: R.T.A.J. Leenders 2nd Tutor: T.L.J. Broekhuizen
Heineken
Tutor: F de Haart
2
Introduction
This research is conducted for my graduation in Business Administration at the Rijksuniversiteit Groningen (RuG). This research was conducted within Group IT of Heineken International. In this research I tried to incorporate the methods and techniques that I encountered during my education. For me it was a real learning experience to use the theory in real practice and see what Business Administration has to offer in the business world.
This research is meant for everybody who is interested in the challenge that large multinational face in providing their subsidiaries with suitable Enterprise resource Planning (ERP) systems, and especially Group IT of Heineken and the people that are involved with this research.
I would like to thank a number of people for their support and guidance during my research. Frank de Haart for giving me the opportunity to be an intern at Heineken International and doing the research. Also for his support and guidance during my research. My mentors from the RuG, Roger Leenders and Thijs Broekhuizen, for their time and effort and interest they put into mentoring me. All involved Heineken employees from Group IT and especially the Architecture, Policy & Planning department for all their help, information and effort. Finally my brother for his friendship and helping me out in times of difficulty.
3
Outline
Introduction ... 2
Outline ... 3
Summary ... 5
Chapter 1 Problem Definition ... 6
1.1 Problem description ... 6
1.2 Stakeholders ... 7
1.2.1 Group IT ... 7
1.2.2 Regional IT managers ... 7
1.2.3 Architecture, planning and policy ... 7
1.2.4 End users ... 8 1.3 Management question ... 8 1.4 Research objective ... 8 1.5 Research Questions ... 8 1.6 Design theory ... 9 1.7 Research Method ... 9
1.8 Scope of the Research (Boundaries) ... 10
Chapter 2 ERP success ... 12
2.1 Theoretical framework ... 12
2.1.1 Structure ... 12
2.1.2 Size ... 13
2.1.3: Culture ... 14
2.1.4: System functionality and organizational fit ... 14
2.2 Conceptual Model ... 15
2.3 Diagnose ... 15
2.3.1 The effect of organizational structure ... 16
2.3.2 The effect of organizational culture ... 17
2.3.3 The effect of organizational size ... 19
2.3.4 The effect of system functionality and organizational fit ... 20
2.4 Conclusion ... 20
Chapter 3 Design ... 22
3.1 Clarifying the design objectives ... 22
3.1.1: Prepare a list of design objectives ... 22
3.1.2: Expand the objectives list ... 23
3.1.3: Draw a diagrammatic tree of objectives ... 24
3.2 Establishing functions ... 24
3.2.1: Express the overall function for the design ... 25
3.2.2: Break down the overall function into sub-function ... 26
3.2.3: Draw a block diagram ... 27
3.3 Setting requirements ... 27
3.3.1: Consider the levels of generality ... 27
3.3.2: Identify the required performance attributes. ... 27
3.4 Determining characteristics ... 28
3.4.1: Identify customer requirements in terms of product attributes. ... 28
3.4.2: Determine the relative importance of the attributes. ... 29
4
Chapter 4 Change ... 33
4.1 Strategies for global information system development ... 33
4.2 Heineken development strategy ... 34
4.3 Key Success factors in ERP Implementations ... 34
4.3.1 Project champion ... 35
4.3.2 Project management ... 35
4.3.3 Business plan and vision ... 35
4.3.4 Top management support ... 35
4.3.5 Effective communication ... 35
4.3.6 ERP teamwork and composition ... 35
4.3.7 Business process reengineering (BPR) and minimum customization ... 35
4.3.8 Change management program and culture ... 36
4.3.9 Software development, testing and troubleshooting ... 36
4.3.10 Monitoring and evaluation of performance ... 36
4.4 Success factors at subsidiaries ... 37
4.5 Conclusion ... Error! Bookmark not defined. Chapter 5 Conclusion ... 39
5
Summary
Heineken is looking for a common IT solution for its small OpCos. So far no solution has been found. This research was conducted to provide Group IT of Heineken with a framework which they can use in the selection of a solution. The question that this research is answering is written below. What are the success factors of a functional design for a common ERP solution, and which scenario for small OpCos matches best with this design? In order to answer this question this research used the Diagnose, Design and Change (DDC) model. In the diagnose revealed that Heineken had difficulties in the past with implementing large complex system at small OpCos. The differences between small and large OpCos, and their different needs can be declared trough four contingency factors; structure, culture, size and functionality.
Information from the diagnose results in several requirements in the design. The to be selected scenario should have high user friendliness. Also the solution should have a low Total Cost of Ownership and should have a low implementation effort. Finally the solution should be compliant with company rules and regulations and should provide all functionality as required by the OpCos.
The results of the scenario ranking during the workshop show that the packaged solutions scores the highest. Costs and implementation effort are strong points of packaged software. Literature states little about compliancy or user friendliness of the different scenarios. Experts perceive the user friendliness and compliancy of the packaged software as higher than the current HeiCore, modified or not. These findings proved to be very important for this research.
When implementing the solution, Heineken should be aware of the success factors of ERP implementations. The 10 success factor are a solid basis for a successful ERP implementation. Finally, Heineken should be aware of its own mistakes and that from others. There are important lessons learned and they can help in making the solution successful at small OpCos.
6
Chapter 1 Problem Definition
This chapter provides an introduction to the problem that is the subject of this master thesis. A description of the problem and the stakeholders will be given. As well as the management question, research question and the design of this research. In the end of this chapter a theoretical framework will be described which is concluded with a conceptual model. Finally the problem will be diagnosed.
1.1 Problem description
This research is originated from the Architecture, policy and planning department. The IT Architecture, Policy & Planning department is responsible for the definition of the Enterprise IT Architecture. Another responsibility is the definition and assurance of IT standards & policies on infrastructure, Master Data and Information Risk Management. Architecture, Policy and planning department performs the execution of Central IT procurement and Vendor Management and is responsible for the overall ‗IT Sans Frontière‘ (ITSF) planning and control.
Heineken is building towards common systems as a result of the ITSF (‗IT Sans Frontiere Program‘) strategy. A ‗common‘ information system is one that is intended to satisfy the requirements of multiple user groups within a firm for a particular functionality (e.g. one order entry system to be used by all divisions of Heineken). Such systems are often comprised of both core (or common) software modules, as well as local modules to support regional requirements (Kirsch and Haney, 2005). In today‘s environment, more and more companies are trying to build similar common information systems (Kirsch, 2004). These systems are to be deployed globally, to support their strategic globalization strategies.
The bigger Operating Companies (OpCo) of Heineken, mainly situated in Europe, support their commercial and supply chain processes using a Common SAP solution ‗HeiCore‘. To date Heineken already has accumulated more than 15 years of experience in this enterprise resource planning (ERP) approach.
Furthermore, Heineken also has OpCos in Africa, Asia, and the Caribbean, most of which are smaller breweries or export offices, with only commercial activities in that country or region. Results from the past show that it has proven difficult to implement the HeiCore solution at these locations. Fifteen years ago, at OpCos in the Caribbean, the HeiCore was implemented. But, in 2005 plans were already initiated to replace HeiCore in the Caribbean for an alternative solution. Main reasons for this were the high total cost of ownership of HeiCore in the Caribbean and the fact that employees in this region had difficulties understanding and handling the complexity of HeiCore. Currently only the bigger Heineken OpCos use the common HeiCore solution. Until this moment, no common ERP system has been applied to the smaller OpCos. That is the problem on which this research focuses.
7
1.2 Stakeholders
The main stakeholder in this problem is Group IT, lead by the CIO. As the responsible organ in executing the ITSF strategy Group IT wants to provide all OpCos with a good working, common system. Within the Group IT, the IT managers of the regions Africa en Caribbean are large stakeholders in the problem. The main reason for this is because the majority of the small OpCos are in their regions. The department of Architecture, Planning and Policy is responsible for the Heineken IT landscape and therefore highly involved with HeiLite (the name of the solution for small OpCos). Finally the (end) users of the system to be implemented will be stakeholders in this problem. The end users will use the system and are therefore dependent on the outcome of the project.
1.2.1 Group IT
Group IT‘s main problem is the execution of the ITSF strategy. Providing every OpCo with a common IT solution at the lowest Total Costs of Ownership (TCO) possible. Right now, not every OpCo is provided with one. Attempts in the past failed at high costs. Not having common systems trough out Heineken results in higher IT costs, difficulties in reporting to Heineken HQ and is therefore a problem for Group IT.
1.2.2 Regional IT managers
The Regional IT managers are currently running different kinds of systems. In both regions a temporarily solution for the small OpCos was created in the last five years. The Caribbean adopted Exact software and the Africa region adopted Navision software to cover their ERP needs. None of them is approved by Group IT to be common. Therefore, sooner or later, the regions will have to adopt a new system provided by Group IT. This will result in a large amount of effort and FTE to be put in the project by the Regional IT managers. As a result of this they both have big interest in having their own temporarily solution to be declared common. This desire may become true when Heineken decides to use the third solution scenario.
A second problem for the Regional IT managers is reporting financial data through the system to Heineken HQ. Because their systems are not common, reporting is very difficult. Reporting should be done in a save, and standardized way. Right now many small OpCos rely on Microsoft Excel to report. This is prone for mistakes and errors.
Finally costs are a problem for the Regional IT managers. The regional managers are under pressure to keep the total costs of IT within the region as low as possible. Their aim is to keep the TCO of IT in the regions within 1.5% of the total revenue of each OpCo. Developing a solution for small OpCos might be a threat to their budgets and therefore is a potential problem.
1.2.3 Architecture, planning and policy
The Architecture, planning and policy department is responsible for the execution of the ITSF program. As stated before, the ITSF programme‘s target is to create an IT landscape within Heineken consisting of common
8 systems. As long as this is not realized, the Architecture, planning and policy department will be under pressure from the CIO to change this.
1.2.4 End users
In contrary to larger OpCos, end users in small OpCos use different kinds of ERP systems. This is not efficient and takes more training to get them used to the new system. Besides this, reporting is done in an inefficient way because the systems currently used are not compliant to Heineken‘s safety standards concerning reporting. Therefore reporting is done manually which is inefficient and unreliable.
1.3 Management question
As a result of the ITSF strategy and the lack of available templates, Group IT is planning to start a project on solutions for smaller OpCos. Currently Group IT is looking at three solution directions (scenarios). These are originated by the ITSF strategy and comply with the fundamental pillars. Because the strategy is aiming to maximize value of partnerships, the original common HeiCore solution, developed by SAP for the bigger OpCos has to be considered as a serious option. The HeiCore can be made available in two ways. The first is to implement HeiCore in its current form (developed for bigger OpCos) at the small OpCos. The second way is, if needed, to customize the HeiCore to fit the small OpCos requirements better. When neither of these options is feasible Heineken will look for an alternative packaged solution. The solution scenarios are listed below:
1. Implement the HeiCore in its current state.
2. Implement HeiCore with customization to the solution and/or implementation approach.
3. Acquire an alternative packaged solution.
Group IT is requiring a theoretical framework for this study that can be applied to the development of a common ERP system for small OpCos within the three possible scenarios. Also, Group IT wants to know how and why the needs of small OpCos differ from larger OpCos and how they should be met. This study is a starting point on the further process of design, realisation and implementation of an IT solution for small OpCos.
1.4 Research objective
From the management question the research objective can be derived. The objective of this research is to choose the best scenario for the small OpCos by providing Group IT with a functional design of a common ERP solution for small operating companies.
1.5 Research Questions
The main research question that is derived from the research objective and links to the conceptual model is defined as follows:
What are the success factors of a functional design for a common ERP solution, and which scenario for small OpCos matches best with this design?
9 The research question can be divided into several sub questions that are logically derived from the conceptual model.
1. What factors influence ERP success?
2. How does a successful design for small OpCos looks like? 3. Which scenario matches best with the created design?
1.6 Design theory
In methodological terms this research can be characterised as problem solving and design research (De Leeuw, 1996). Problem solving is what can be seen as the prototype of managerial research: there is a short distance between the researcher and the client, the problems are being mapped integrally and solutions are being provided to solve these problems. In addition, as can be seen from the research objective as formulated in the previous paragraph, the intended result is to provide a functional design with which Group IT can gain insight in the needs of the small OpCos and can choose for the right scenario. In methodological terms one can therefore speak of design research.
As a result of the characterisation of this research an appropriate approach needs to be chosen. For this research the DDC-model by De Leeuw (1996) is used. This model is suitable to conduct problem solving and design research. This model distinguishes three separate phases: diagnosis, design and change.
Diagnosis
The research starts with a first indication of a problem situation; the initial assignment or an indication of existing complaints (De Leeuw, 1996). In the diagnosis phase it is necessary to gain insight in the underlying problems. Design
In the design phase a method is developed that is able to provide a solution to the problem(s). A good design objective has to be clear, precise and complete on what has to be designed, which quality requirements shall apply on the system being designed and within which boundary conditions the design should remain (De Leeuw, 1996). By specifying the requirements in a good manner these conditions can be met. This set of goals, constraints and criteria is also mentioned by Cross (2000) as being the design brief. Recommended Change
At the end of the research a functional design is created, which will be used to choose between the three scenarios. The scenario which is chosen will be recommended to Heineken as being the best possible solution for small OpCos. This recommendation also contains recommendations considering the implementation of the solution in small OpCos.
1.7 Research Method
The problem solving and design process started with a first indication of a problem situation. This first indication has to be diagnosed. In this research this first indication concerned the objective to create a common ERP solution for small OpCos within Heineken. Several people within Heineken
10 were contacted and interviewed in the diagnosis phase (table 1.1). This gave insight in the underlying problems of the current Heineken IT at small OpCos. A literature study was performed to obtain understanding of particular subjects in this research project, including the success factors for ERP systems. This diagnosis resulted in the eventual research objective of this research. Also this resulted in answering the first research question by providing insight in the contingency factors that influence the success of ERP systems and how this reflects on the situation at Heineken.
Interviewee Role Topic Duration
Frank de Haart IT Business Consultant (Link between Business and IT)
Heineken IT in all OpCos 2x 60 min Michiel
Kamermans Manager Architecture, Planning & Policy dept. Heineken IT strategy & small OpCos 60 min M. Hogenes IT Manager Caribbean ERP in the Caribbean, past
ERP implementations in the region
90 min P. Wever IT Manager Africa & Asia ERP in Africa, experiences
in ERP implementation
60 min T. Dallenga IT Business Consultant (Link
between Business and IT) IT architecture in small and large OpCos 60 min M. Ortolo IT Specialist Africa Implementation of ERP
package in Africa at small OpCo
2x 60 min
Table 1.1: Interviewees
In the design phase a design is developed that is able to fulfil the needs and requirements of small OpCos. This is done with the rational design method of Cross (2000). The seven steps in the method will be executed to create a design that is suitable for small OpCos. Information from literature will be used along with a questionnaire conducted at small Heineken OpCos. This questionnaire was completed by 53 respondents. The data gathered in this questionnaire is used to help the experts doing the scenario analysis in the last stage of this research. At the end of the design phase the second research question can be answered by presenting an ERP design for small Heineken OpCos.
At the end of this research a functional design for a common ERP solution for small OpCos will be used to make a decision in choosing the best scenario. The way in which this will be done is by ranking the three scenarios against the created design. This will be done using the input gathered during a workshop with ERP experts and the results of literature study and the questionnaire. The implementation is not up to the researcher but has influence on ERP success. Therefore the research will recommend a best solution for the small OpCos and will highlight important implementation issues.
1.8 Scope of the Research (Boundaries)
The research is conducted within the scope of the writing of the final thesis for the Masters degree in Business Development and is conducted from within Group IT from Heineken International in Amsterdam. The intended
11 users of the design and the research is the management of the Architecture, Policy & Planning department and Group IT as a whole.
A ‗common IT solution‘ is Heineken terminology. An IT solution is regarded common by Heineken when it has the following attributes:
- A ‗common‘ information system is one that is intended to satisfy the needs of multiple user groups within a firm for a particular functionality (e.g. one order entry system to be used by all divisions of a global firm). Such systems are often comprised of both core (or common) software modules, as well as local modules to support regional requirements, (Kirsch and Haney, 2005).
- Managed and hosted centrally.
- Delivers the same functionality as HeiCore in large OpCos. - The solution must be agreed to be common by all parties.
- The security incorporated in the solution Security must be part of the Heineken reference model.
- Compliancy to Heineken reference models. (A reference model is a notion used in standard conceptual computing models. It is an abstract representation of the entities and relationships involved in a problem space, and forms the conceptual basis for the development of more concrete models of the space, and ultimately implementations, in a computing context).
This research will be using the present recommendations by The European Commission concerning definitions about company sizes:
- Medium-sized enterprises have fewer than 250 employees. Their annual turnover should not exceed EUR 40 million or their annual balance-sheet total should be less than EUR 27 million.
- Small enterprises have between 10 and 49 employees. They should have an annual turnover not exceeding EUR 7 million or an annual balance-sheet total not exceeding EUR 5 million.
- Micro-enterprises are enterprises which have fewer than 10 employees.
12
Chapter 2 ERP success
This chapter describes the theoretical factors that influence ERP success. In a conceptual model the influence is shown. At the end of this chapter the theory will be linked to the Heineken situation. Resulting in the needs that are the basis of ERP success at Heineken.
2.1 Theoretical framework
This research is aiming to design a successful ERP solution for small OpCos within Heineken. In this research ERP success is defined as: Fulfilling the ERP requirements of small OpCos, while being compliant with the requirements of Group IT. ERP success is influenced by structure, size and culture (Ifinedo, 2007). Also, ERP success is influenced by system functionality and its fit with the organization. In this paragraph, the meaning and influence of each contingency factor will be discussed.
2.1.1 Structure
Several researchers describe organizations by using structural labels. This labels provide a mean to describe the internal characteristics of organizations. Furthermore, they provide a basis for measuring and comparing different organizations. Commonly mentioned structural dimensions are: centralization, specialization, standardization, formalization and hierarchy levels. Mintzberg (1979) described five different main types of organizations using the aforementioned structural dimensions. Different types of organizations work in different ways (e.g. very formal vs. very informal). Furthermore, organizations with different characteristics within Heineken could be a result of having different organizational goals. For example: The strategic headquarter of Heineken in Amsterdam has the goal to manage the entire company, create marketing campaigns, brew beer and sell as much as possible of it within the Netherlands. While a branch office in Congo aims to sell as much beer as possible. As a result of this the structure of every OpCo within Heineken can be different. Davenport (2000) concluded that the structure is very important for ERP success, when adopting ERP systems. The research hypothesis that organizations with high levels of centralization favour ERP, in contrast to decentralized ones is supported by Ifinedo, 2007. So large, centralized OpCos, might favour ERP better than small OpCos.
Striving for ERP success may cause organization to radically change. This needs to be carefully managed. Unlike the design and development of a custom ERP system, packaged solutions especially require that it‘s implementing organization changes several of its existing business processes to fit with the embedded processes of the adapted system. Research also confirms that when an organization adapts its existing business processes to the standard business processes of ERP, other contingency factors (e.g. culture) should be changed and managed as well (Hong & Kim 2001).
13 ERP research by Gattiker and Goodhue (2000) concluded that while inter-dependences between OpCos gave better fit of an ERP system with global operational needs, differentiation among OpCos results in poor fit with ERP and local operational needs. This relates to research of Morton & Hu (2007) that states that a key contributing factor to the failure of many ERP implementations is the integrated nature of ERP systems. Organizations are forced to adopt to standardized business processes that are reflected in the design of the ERP software. This standardization and integration that is forced by most ERP systems may not be suitable for all types of OpCos. As a result, the fit with the structural dimensions of the adopting organization and the design of the standardized business processes within the ERP system has a high impact on the possibility of having ERP success or failure (Morton & Hu, 2007), as is shown in figure 2.1.
Figure 2.1: Framework for organizational fit and ERP implementation success (Morton & Hu, 2008).
2.1.2 Size
Although many researchers have described firm size differently, literature seems to agree that firm size can be assessed using employee workforce, and/or annual turnover/sales. The European Commission defines small and medium-sized companies as follows. Firms with less than 250 employees and an annual turnover of less than €50 million are medium-sized firms. Those with less than 50 employees and an annual turnover of less than €10 million are small firms. Firms not included in the foregoing classifications, and with higher values for these two factors, are labelled "large firms" (Laukkanen et al., 2005). Literature strongly indicates that firm size is associated with ERP success (figure 2.2). Laukkanen et al. (2005) clearly stated, "Company size, indeed, does matter in ERP adoption". Bernroider and Koch (2001) concluded the ERP selection process is different among firms depending on size, and that smaller firms tend to associate problems with implementation costs (Buonanno et al., 2005). The latter indicated that small OpCos work in a different way and therefore focus on different requirements while trying to achieve ERP Success. Laukkanen et al.'s (2005) findings suggest that small companies experience more knowledge constraints than larger firms during ERP adoption and exploitation. This because smaller OpCos have less resources to achieve ERP success than their larger counterparts. Mabert et al. (2003) noted that ERP success differs according to firm size, due to the availability of resources. Heineken small OpCos have far less resources than large OpCos.
Figure 2.2: Framework for organizational size and ERP success (Ifinedo, 2007).
Organization
Structure ERP success
Organizational
14
2.1.3: Culture
Hofstede (1984) assert that culture is a way things are done in the business and shared perceptions, beliefs, symbols, rites and rituals, and myths may be "taken for granted" in an organization. Following this description, the existing culture in a company may have an influence on the way how people within it work, deal with others, and adopt and use technology (Krumbholz and Maiden, 2001). ERP success is often reported as related to the issues as mentioned by Hofstede (Bingi et al., 1999; Esteves and Pastor, 2001). As written above, the significance of organizational culture in ERP studies has been described in the literature. Many researchers (e.g.. Krumbholz et al., 2000; Krumbholz and Maiden, 2001: Soh et al., 2000) have suggested that the core values in the corporate culture of firms that are working with an ERP system can cause mismatch problems (Davenport, 1998: 2000; Kappos, 2000; Jones and Price, 2001). In contrary, the overall success with ERP may also be enhanced if there is a match between the culture of the adopting firm and the underlying logic of the system (Ifinedo, 2007). This is shown in figure 2.3.
Success of an ERP system requires a fit between the product and the organization (Yen & Shue, 2004). Barriers to accomplishing this are high. Many issues of misfit can be particularly pronounced in international situations when firms adopt a Western ERP system. Business practices have been shaped by one culture while the imposed solution has been shaped by another (Liang & Boulton, 2004). Such barriers are problematic in the deployment of complex technology. Consequently, ERP systems are not universal, and their "culture of origin" may imply ways of managing data and processes as well as many administrative heritages that are nationally bounded. This makes an assumption of universal best practices for information management by ERP vendors questionable (Wang, 2006).
Figure 2.3: Framework for organizational culture and ERP success (Ifinedo, 2007).
2.1.4: System functionality and organizational fit
Several sources point out that the fit between the process and organization of a company and the ERP system is very important. Hong and Kim (2001) performed a field survey among 34 organizations and concluded that ERP success significantly depends on the organizational fit of ERP (figure 2.4). An ERP system is organizations‘ most strategic computing platform and can have a high impact on the main process. Hong and Kim (2001) find that sometimes ERP failure is jeopardizing the core operations of the implementing organization. Especially for ERP systems from commercial suppliers, Rolland and Prakash (2001) see that ―fitting those systems to customer requirements remains problematic‖. They suggest that the ERP set of requirements must match against organizational requirements.
Organizational
15
Figure 2.4: Framework for system functionality and ERP success (Rolland & Prakash, 2001).
2.2 Conceptual Model
The main concepts in this thesis are captured in the conceptual model below (figure 2.5). The arrows imply influence of one concept on another. This model will be used in this thesis. This model is states that contingency factors such as organizational size, culture and structure and functionality are influencing the success potential of a design for a common ERP solution. As shown in the conceptual model, this research will be looking at the influences of the contingency factors on an ERP design for small OpCos at Heineken. Also this research will create a design for a common IT solution for the small OpCos within Heineken. This design will be ranked and compared against the three scenario‘s which Heineken is considering. Finally the best fitting scenario for Heineken will be chosen to achieve ERP success for Heineken small OpCos.
Figure 2.5: Conceptual model
2.3 Diagnose
This paragraph describes the influence of the four contingency factors at Heineken. To achieve this, the theory will be linked to empirical data from Heineken. The empirical data was acquired during open interviews with Mr. M. Hogenes and Mr. P. Wever. They are the Regional IT managers in respectively The Caribbean and Africa. These regions contain the majority of the small OpCos affected by this research. The regional It managers form
System
Functionality ERP Success
Heineken Small OpCos
Size Culture Functionality ERP Success Organizational fit with ERP Design
Diagnosis Design Change
Structure
16 the link between the region and Group IT. They have detailed knowledge about the IT in combination with the business in their region. This makes them valuable sources of information for this research.
2.3.1 The effect of organizational structure
Morton and Hu (2008) created a framework in which they show the relationship between organizational structure and success of ERP systems. In the framework they use the organizational types as described by Mintzberg in 1979. Information from interviews with Heineken managers (Mr P. Wever and M. Hogenes) point out that the small OpCos, can best be characterized as ‗Divisionalized form‘. They differ significantly from large OpCos. Main characteristics of this type of organizations are:
Centralized headquarters
Semiautonomous, loosely joined divisions
Little interdependence or close coordination among divisions
Main goal of headquarters is to coordinate goals of divisions with that of its own without sacrificing autonomy
Standardized outputs of divisions used for coordination
Divisions are generally machine bureaucracies
Technical system separated into segments, one for each division Small OpCos have separate Regional IT managers who manage their regions (divisions) centralized. They try to give each OpCo within their region targets from their regional headquarters. In the Caribbean the technical system is largely uniform (Exact, ERP software) but in Africa the technical systems are very separated with each OpCo having its own system. Large OpCos can be characterized as ‗Machine Bureaucracies‘ and have totally different characteristics when compared their smaller counterparts.
Large OpCos have centralized decision making. Also they make use of automated and integrated technology combined with a formalized structure ad routine tasks in standardized work processes. Especially in the production units of Heineken.
In their framework, Morton and Hu (2008) suggest that different success factors may be dominant depending on the type of organizational structure in which ERP success is the goal. Heineken‘s case with the failed HeiCore in the Caribbean seems to confirm this. Also, if the design of the information system fits well with the existing structure of the organization, the power structure, responsibilities and job definitions will not have to change very much. This results in less resistance from within the adopting OpCo. The bigger the changes a new information system creates, the bigger the resistance. The greater the resistance, the less chance for ERP Success (Morton & Hu, 2008). The recommended change should take this into account. The recommended scenario should have a fit with the structure of the small OpCos.
In Africa there are several small OpCos that might use the recommended change in the future. The regional IT manager of Africa, Mr. Wever is very familiar with the structure of his business and also the design of HeiCore.
17 During an interview he indicated that the business in Africa is characterized by a chaotic way of doing business. It might be possible for example that somebody with a lorry arrives at the brewery and pays in cash for the products. This would be a very uncommon situation in European OpCos. This results in some very complex OpCos, and some less complex OpCos in his region. ―Organizations whose structures are a poor fit with ERP systems, are likely to face organizational resistance to the systems, and thus increase the chances of unsuccessful ERP‖ (Morton and Hu, 2008). When selecting a solution for the small OpCos, this fit should be carefully considered.
Organizations with low levels of business integration and with relatively non-standardized processes will encounter high levels of resistance during ERP implementations (Morton & Hu, 2008). This was also seen with Heineken in the Caribbean, where the rigid nature of HeiCore forced the organization and the employees of the small OpCo, to follow the business processes embedded in the system. This resulted in limited understanding of the system by the employees. Also there was reluctance to change the way of working to fit the new system. The new system should therefore contain transparent process that fit with the way of working of the small OpCo. The cross-functional and integrated nature of information systems has a major effect on business processes. Very often standardization of data and business processes is needed to enable the information system to handle all the transactions and data storage across the entire function of the organization that is affected by the information system (Gattiker & Goodhue, 2004). To prevent problems during and after implementation, organizations have to modify its internal processes to accommodate the processes embedded in the ERP software (Benders et al. 2006). Mr. Hogenes states that HeiCore was a ‗black box‘ for his end users in the Caribbean. The users had no clue what had to go into the system and what they had to get out of the system. Amongst users there was little to no knowledge about the underlying processes in the organization and HeiCore. Thus, people had very little awareness of what they were doing. Result of this was a high number of reporting (to HQ) issues, which made the Total Cost of Ownership of HeiCore in the Caribbean very high. Mainly due to the high support effort that had to be made. This makes clear that the recommended solution should be transparent and understandable for the people who will use it. In the past Heineken failed to achieve this, and therefore failed to achieve ERP success at small OpCos.
The effect of structure in the Heineken situation results in the need for transparent processes. Users should be able to understand what their role in the system and entire structure is to be able to work with the solution. Also, to prevent resistance and high total costs of ownership the fit between the solution and the organization should be carefully considered.
2.3.2 The effect of organizational culture
Organizational culture can be viewed from many different perspectives. According to Schein (1985) and Hofstede (1984) culture is ―a pattern of basic assumptions invented, discovered or developed by a given group as it learns
18 to cope with its problems of external adaptation and internal integration that have worked well enough to be considered valid‖. Hofstede (1984) also states that culture is ―a way things are done in the business and shared perceptions, beliefs, symbols, rites and rituals, and myths, taken for granted in an organization‖. With this description Krumbholz and Maiden (2001) concluded that the existing culture in a company has an influence on the way people work, and adopt and use technology.
Culture was mentioned as another major factor in the performance of HeiCore in the Caribbean. This confirms the findings of Krumbholz and Maiden. The way of working, combined with education and discipline in the region differs very highly from the discipline and way of working of the creators of HeiCore. HeiCore requires very strict and correct input. Without this correct input HeiCore will not function as supposed to. Therefore the lack of education, discipline and informal way of working was a big problem when working with HeiCore in the Caribbean. In fact HeiCore was providing too much functionality which did not work with the lack of process knowledge and education in the region. The facts from Heineken prove that small OpCos cannot work with large complicated systems. In that sense, they differ greatly from large OpCos, who are able to work with the complicated HeiCore system. Therefore the system should be user friendly, have an intuitive interface and should be easy to learn to work with.
On the contrary, the overall success with ERP may also be enhanced if there is a match between the culture of the adopting firm and the underlying logic of the system (Kumar and Van Hillegersberg, 2000). The IT staff's quality (i.e., knowledge of technological changes and up-to-date skills) is cited among the important factors required for IT systems success in general and for ERP success in particular. Several ERP studies have suggested that the knowledge base or expertise of the in-house IT professionals must be adequate to ensure success with ERP (Lee and Lee, 2004). The ERP and IT knowledge in small OpCos is very limited. Therefore the system should be easy to work with and easy to maintain.
The original HeiCore was designed to work in a very large brewery. This resulted in a large number of screens and steps that had to be walked trough. This made HeiCore a complex solution which was perceived as being user unfriendly in the small OpCos. In the local culture it was acceptable to leave thing as they were and ignore major problems when a person did not understand HeiCore. Resulting in major problems in the brewery as direct result of the ‗laid back‘ culture. Also, HeiCore did not provide the functionality to give warnings when people were forgetting steps in the processes. The complexity in combination with the lack of business controls resulted in many problems because in the local culture people don‘t proactive see and solve problems. If Heineken wants to achieve ERP success in small OpCos, the ERP system should be easy to work with. Also the system must be able to detect problems and alert people (business control system). Many companies around the world are following the trend toward making large investments in implementing ERP systems. In the meantime, many of
19 these companies do not conduct a formal analysis or planning effort prior to implementation (Mabert et al., 2003). The lack of proper planning will definitely harm the multinational ERP success even more due to differences between nations. This is the case with HeiCore and Heineken. A good investigation to find out about local knowledge, ERP needs, processes, etcetera, could have prevented a lot of trouble during the HeiCore implementation process. Heineken should research prior to implementation whether a system fits with local cultural circumstances. To ensure ERP success, the system should fit local cultural circumstances.
The effect of culture in the Heineken situation results in the need for a systems that is user friendly, has an intuitive interface and should be easy to master working with. During operational use the system should be easy to work with and contain a business control system.
2.3.3 The effect of organizational size
As mentioned, during 2002 HeiCore was implemented in a small OpCo in the Caribbean. Compared to their larger counterparts, small OpCos have less access to resources such as time, skills and money (Bernroider and Koch, 2000). Due to this lack of abundant resources small OpCos are more vulnerable to environmental effects and misfits. This is exactly what was the cause of a lot of problems in 2002. According to Mr. Hogenes little time was available for his employees to get to know the system and understand its underlying processes. Therefore Mr. Hogenes experienced around 400 issues after the implementation of HeiCore. This process of reacting to issues, rather than anticipating and controlling them is a prediction made by Laukanen et al. (2007) after researching the influence of size on the impact of ERP adoption by small and medium sized organizations. In order to avoid these kinds of problems the solution should come with a standardized implementation process. Such a process will reduce the number of local resources needed for the implementation and could significantly reduce implementation time.
HeiCore was designed for large OpCos. Because of this other problems became apparent. To minimize the total costs of HeiCore it was designed to reduce the total number of users, and with that the number of fee‘s that has to be paid to the vendor. This design did not work for the smaller OpCo which ended up with having a relatively high number of users and therefore high costs of use. The relative high number of users can be explained by the fact that almost every person in the small OpCo had to use the system because of its initial design. The system was designed in a way that not one person could do all the work but everybody was responsible for their (small) part of the data. Resulting in very high software fees. Buonanno et al. (2005) confirm that small companies see high implementation cost as a significant problem for achieving ERP success. Therefore the solution for the problem should be affordable for a small OpCos.
The software selection process is also different among companies of different sizes (Bernroider and Koch, 2001). This could relate to the fact that smaller companies associate problems with ERP adoption in
20 implementation costs (Buonanno et al., 2005). In 2000, Bernroider and Koch conducted research into differences in the selection process between small and large organizations. Results showed that smaller companies used a different way of staffing IT projects. They found that smaller organizations use a more centralized form of decision-making, as fewer people are involved. Also, smaller organizations use less complex models and less expensive methods of information gathering in decision-making (Bernroider and Koch, 2000). This closely relates to what happened with HeiCore being implemented at smaller OpCos in the Caribbean. Not only were the costs of implementing HeiCore very high for the small OpCos but also staffing them adequately proved to be a problem due to a lack of personnel.
Finally, the drivers of adopting ERP systems vary between companies of different sizes. Laukkanen et al. (2007) state that large companies are more outward oriented while adopting ERP systems, than their smaller counterparts. Results show large companies being more focused on strategic business development trough IT investments than small and medium-sized enterprises. This is also seen within Heineken. Large OpCos use IT systems as a way to serve their clients in the best and most efficient way. In small OpCos, IT is used as a support mechanism to structure the business in a basic way.
The effect of size in the Heineken situation results in the need for an affordable solution. Implementation should be short and standardized. The latter to reduce the implementation effort for the small OpCos in terms of resources.
2.3.4 The effect of system functionality and organizational fit
Several sources point out that the fit between the process and organization of a company and the ERP system is very important. Hong and Kim (2001) performed a field survey among 34 organizations and concluded that ERP success significantly depends on the organizational fit of ERP. Evidence from Heineken confirms that the task of the organization should match the task of the ERP solution to achieve ERP success. A perfect example is the unsuccessful implementation of HeiCore in the Caribbean. From this example we can tell that the system should match the functional requirements of the OpCo. Also the system should offer al the functionality that is required by the business, while avoiding offering to much functionality and thus increasing operational complexity. Especially for ERP systems from commercial suppliers, Rolland and Prakash (2001) see that ―fitting those systems to customer requirements remains problematic‖. They suggest that the ERP set of requirements must match against organizational requirements. Heineken should be very aware of this to avoid implementation and operational problems that occurred in the Caribbean in the past.
2.4 Conclusion
There are significant differences between small and large OpCos. These differences appear in the culture, structure, size and functionality. Small
21 OpCos do have very different requirements for their information systems then their larger counterparts. Therefore HeiCore didn‘t succeed at small OpCos in the Caribbean. The need for an information system which is specifically tailored to the requirements of small OpCos within Heineken is evident. The four contingency factors influence the needs of the small OpCos within Heineken. As a result of this the small OpCos should be provisioned with another, better fitting ERP system.
There are several main lessons learned from HeiCore in the Caribbean (derived from M. Hogenes). They state the key attributes that made HeiCore fail in this region, and should be addressed in any solution:
- Solution for small OpCos should be easy-to-use with transparent processes.
- The solution should have a fit with the organizational tasks and processes.
- Sufficient functionality, not excessive.
- High flexibility of solution to fit with culture. - Affordable total cost of ownership.
22
Chapter 3 Design
Introduction
The purpose of chapter 3 is to make a functional design of a successful ERP solution for small OpCos. A functional design is used by companies in a pre-development phase to translate all notes, concepts, and scope into a complete requirements document. To achieve this in this research, the rational design method of Nigel Cross will be used. The entire method consists out of seven steps. In this design only the first four steps will be followed. They are sufficient in creating a functional design, without getting into too many irrelevant technical details. At the end of this chapter, the functional design will be ranked against the three scenarios Heineken is considering. In step one the main objectives will be set. In the second step the overall functions of the design will be determined. The third step creates a list of requirements for the design. Finally in the fourth step the voice of the customer will complete the functional design.
3.1 Clarifying the design objectives
Clarifying the design objectives is the first step of the rational design method and consists out of three sub steps. When a client first approaches a designer with a product need, it is very unlikely that this need will be expressed very clearly. This will make the starting point of a design very often a vaguely defined problem. An important first step in designing is clarifying the design objectives. At all stages it is very helpful to have a clear idea of the objective, even though the objectives may change as the design work progresses. As an aid to controlling and managing the design process it is important to have a statement of objectives which is as clear as possible. The objectives tree method provides a good format for such a statement of objectives. To create an objective tree (step 3) it‘s important to first create a list of design objectives (step 1) which is further expanded into a high-level and low-level objectives list (step 2) (Cross, 2000).
3.1.1: Prepare a list of design objectives
During the start of the research there were a small number of design objectives. These were made clearer and further expanded in a series of interviews and group discussions with all stakeholders within Group IT of Heineken. As a result of this procedure the following design objectives where indentified:
- Functional design for an ERP solution for small OpCos. - A for small OpCos affordable solution.
- High level of user-friendliness. - Short duration of implementation.
- Low impact of implementation on OpCos.
- Solution provides all required functionality as required by small OpCos.
During interviews with Frank de Haart from Heineken, the design objectives were further expanded into key-objectives. Frank de Haart is Business
23 Consultant in the Architecture, planning & Policy department of Group IT. In that position he is the link between the global IT and the business. Therefore Mr. de Haart was able to pinpoint the needs of the small OpCos. The following key objectives were identified and taken into the design:
- User friendliness. The solution should have as limited irrelevant information shown to the end-user (no functional ‗overhead‘ so that users get lost, resulting in less/no use of the system).
- Low Complexity. The user should easily understand the business processes that he or she supports performing their daily tasks (e.g. sales order issue resolution).
- Functionality. The solution should cover all needed functionality. Not basic transactional functionality (like ERP), but also compatibility with enabling technologies like Mobile devices and/or Dynamic Route Planning.
- Smooth Roll-In. Solution should be rolled-out in a similar, common manner to ensure simplification in usage and support.
- Implementation. Solution should be implemented within a limited time frame (< 5 months). Involvement of key business people should focus on training and change management and not extensive (re-) designing the solution.
- OpCos should be supported locally (both with Super Users (knowledgeable users) from the business and with IT support on demand and on site).
- Fair Total Cost of Ownership. Fair is within a certain bandwidth of the current TCO and with similar functionality and business continuity.
3.1.2: Expand the objectives list
In this step the list is expanded with more objectives that are generated by clarifying the objectives from step one. The expanded list that is created should be ordered into sets of higher-level and lower-level objectives. The expanded list of objectives and sub-objectives was created in cooperation with all the stakeholders and is grouped roughly into hierarchical levels. The initial design objectives derived from the interviews and group discussion are high level objectives. They are supplemented with lower-level objectives. Implementation duration and impact are combined into implementation effort.
- Functional design of an ERP solution for small OpCos.
Solution should cover all needed functionality of small OpCos within Heineken.
- A for small OpCos affordable solution.
To stay under 1.5% ICT costs of OpCo revenue per year (Incl. implementation)
Assurance of good business controls (anti-fraud) - High level of user-friendliness.
Self explaining interface Intuitive interface
24 Transparent processes (user awareness of role in
organization)
Minimal visual overhead Easy to master working with - Low implementation effort
Standard implementation possible Maximum of five months
- Solution provides all required functionality as required by small OpCos.
Decoupling of organization and system (to maintain production in unexpected situations)
Functionality as described in ARIS (Company process guidance).
- Compliancy to Standard Charts Of Account (SCOA) and other company policies
3.1.3: Draw a diagrammatic tree of objectives
The tree should show hierarchical relationships and interconnections. The branches in the tree represent the relationships, which suggest means of achieving objectives (Cross, 2000). The tree starts with the main goal of creating an ERP solution for small OpCos and grows taller with the low-level objectives. Figure 3.1 shows the objective tree for the design of a common IT solution for small OpCos within Heineken. For more information on the objectives in the objectives tree, look in the previous paragraph 3.2.2.
Figure 3.1: The objectives tree
3.2 Establishing functions
The aim of the function analysis method is to establish the functions required, and the system boundary of a new design. The procedure is as
ERP solution for small OpCos Affordable User- friendly Low implementation effort Functionality Business Controls Under 1,5% of Revenue Self explaining interface intutive interface Transparent Minimal visual overhead Standard Maximal 5 months ARIS Decoupling
25 follows and consists out of 4 steps. The first step is to express the overall function for the design. Step two break‘s down the overall function into sub-functions. Step three is to draw a block diagram. In the final and fourth step there is a search for appropriate components to perform sub-functions. The purpose of this paragraph is to show the systems functionality. All the three scenarios are capable of providing enough functionality. This is know because Heineken already knows HeiCore‘s functionality (scenario 1 and 2) and has several OpCos with scenario 3 solutions that are working with the required functionality. Nevertheless, it‘s still important to know which business processes are going to be supported by the system. This paragraph will not be used in the final selection of a solution because all the tree scenarios have enough functionality.
3.2.1: Express the overall function for the design
The expression of the overall function is done in terms of the conversion of inputs into outputs. This will result in a black box (figure 3.2). The overall black box function is supposed to be broad, widening the system boundary. This to make sure that major design changes can be made.
General business input Business information
Figure 3.2: The overall black box
The overall function of the ERP system is very broad. The system as a whole has to execute several functions for the entire OpCo. Therefore it is difficult to describe one single input and output for the system. The solution in this design will be used to support the business processes in the core business (making and selling beer). The main emphasis of the solution will lie in supporting the Source to Pay (procurement), Demand to Warehouse (production) and Market to Cash (sales) processes. But as said in step one of the rational design method, the solutions also must be able to support mobile devices and have compatibility with enabling technologies.
The Picture on the next page (figure 3.3) gives insight into Heinekens core business processes. The IT solution that this research is looking for will be used to support the business processes in the core business. The main emphasis of the solution will lie in supporting the Source to Pay, Demand to Warehouse and Market to Cash processes.
26
Figure 3.3: Heineken’s core business processes
3.2.2: Break down the overall function into sub-function
As described in step 1, the main emphasis of the solution is to support the core business of the small OpCos. The core business consists out of three main processes.
- Source to Pay is the sourcing of goods. This involves the execution of sourcing, contract management and executing payments. - Demand to Warehouse is the overall demand and supply
management. Logistics and production are the two major elements in Demand to warehouse.
- Market to Cash is the process of actually selling the products. Main processes within this process are customer relation management and processing orders till they are successfully delivered and paid.
Record to Report
Strategic Management Processes
Core Processes Strategy development Risk & Compliance Management Governance Cycle
Innovate and Market
Trade Marketing Management Product development Market to Cash Enabling Processes Brand Management Demand to Warehouse Demand and Supply planning Logistics Production Demand and Supply planning Logistics Production Customer planning Customer execution Customer service Order to Cash HR Management Source to Pay Purchase to Pay Enterprise Services Execution Master Data Management Sourcing Execution Contract Mgmt Communica tion Health & Safety Trade Marketing Management Product development
27
3.2.3: Draw a block diagram
In the block diagram the main black box is made transparent to show the sub functions. Figure 3.4 shows the block diagram with its sub functions.
General Business
Business information
Input
Figure 3.4: The block diagram
The boundary of the system is very wide. The design should cover and support all business which is conducted by small OpCos. Also the design should leave room for future innovations and enabling technologies.
3.3 Setting requirements
The goal of setting requirements is to make an accurate specification of the performance required of this design solution. This is done in two steps. First the level of generality should be chosen. This clarifies the freedom in which the designer can operate. In the second step the performance attributes are identified (Cross, 2000).
3.3.1: Consider the levels of generality
The level of generality determines the freedom the designer has to alter a design. Three possible levels of generality give the designer various levels of freedom in creating a design. Within these three choices the product alternatives gives the most freedom and the product features the least. Product types is the intermediate level in between the latter.
o Product alternatives o Product types
o Products features
For this research the intermediate level of generality is best. This research is about creating a design that is intended to replace an existing product. Cross (2000) suggest that the best level of generality for such a design is product types. This means that there is enough freedom to choose between the scenarios, but there is not enough freedom for a radical new design.
3.3.2: Identify the required performance attributes.
In this step the attributes of the design are stated. They were gathered during interviews and discussions with Heineken stakeholders and experts. They are stated in terms that don‘t favour or exclude any of the three scenarios. Wherever possible they are stated in quantified terms. The performance attributes to which the design should comply are listed below:
Source to Pay Demand to Warehouse
28 - Functionality as described in ARIS (ARIS is Heineken‘s process
guidebook)
- Full support of operational processes
- Good possibilities for further development by vendor - No technical limitations to growth
- Compliancy to standard rules (IFRS, SCOA, standard account charts, business controls)
- Implementation possible within 5 months - Costs maximum of 1,5% of revenue
- Availability of a standard implementation model - Worldwide local support
- 24/7 support by vendor
- Complexity fit with maturity of organization - System reliability of 99,9%
- Limited number of screens for users - No visual overhead for users
- Intuitive look & feel of the system - Low complexity of the system
3.4 Determining characteristics
The aim of this step is to set the targets for the engineering characteristics in such a way that they satisfy customer requirements. In this design the ‗customers‘ are the small OpCos. This step consists out of two steps. The first step is to identify the ‗voice of the customer‘. The second step is to determine the relative weight of the attributes.
3.4.1: Identify customer requirements in terms of product attributes.
The voice of the customer was identified during a series of interviews and workshops all with stakeholders. First literature research was conducted into possible requirements of small OpCos. Other requirements were added during workshops with the regional directors of Arica and the Caribbean. Because the majority of the small OpCos is in their regions, they represented the customer. The final list, in random order, with the voice of the customer was created:
- Package must come from a vendor with a good vision - Good support for all functionality needed by small OpCos - Availability of support for further growth
- Compliancy with rules and regulations - High ease of customisation of package - An acceptable total implementation effort - Technology used by system must be compliant - Vendor Service & Support
- Fit with organizational maturity - Acceptable bandwidth usage - Compatibility with legacy systems - Fit with organizational structure - Low total cost of ownership - Stability of vendor
29 - High system reliability
- Good security
- Good user friendliness - Fit with local culture
- Internationality of the software - Fit with customer and supplier needs - Increased organizational flexibility
3.4.2: Determine the relative importance of the attributes.
To determine the importance of the attributes there was a questionnaire conducted within Heineken. This questionnaire was held to acquire the ‗voice of the customer‘ within Heineken. It also helped to acquire the relative importance of the attributes. In the initial stages of the research the requirements were derived by information from the interviews within Group IT and the Architecture, Policy & planning department, combined with literature. This questionnaire was sent to the IT managers of small OpCos. In total 53 managers completed the questionnaire and provided a broad and in depth view of the needs of their OpCos for a common IT solution for small OpCos. The results of the questionnaire give insight into the needs of the small OpCos. Another benefit of this questionnaire was avoiding narrowness in the scope of the research. Because the questionnaire gave actual insights into the (relative) needs of small OpCos. Before this questionnaire, the Group IT and the regional IT managers were the main source of input for the design.
Results from the questionnaire, as shown in figure 3.5 and 3.6 on the next page, show that within the small OpCos extra importance is given to:
- Costs
- System reliability
- Vendor service & support - Functionality
- User friendliness - Security
30
Figure 3.5: Results of the Questionnaire, showing the relative importance of the attributes.
Figure 3.6: Results of the Questionnaire, showing the relative importance of the attributes.
