!

!

THESIS MSC. SUPPLY CHAIN MANAGEMENT

FACULTY OF ECONOMICS AND BUSINESS: DEPT. OF OPERATIONS MANAGEMENT

UNIVERSITY OF GRONINGEN

ERP SYSTEM IMPLEMENTATIONS:

THE IMPACT OF

EXTERNAL CONSULTANTS

AUTHOR: Niels Arends SUPERVISORS: Prof. Dr. J. de Vries

MSc. N. Ziengs DATE: June 22, 2015 VERSION: Final version

Abstract

This research examines the role of external consultants in ERP system implementations.

More specific, the research assesses how professional skills of ERP consultants contribute to

the success of an ERP system implementation within large and private sector organizations.

By means of extensive literature analysis and several expert interviews the research found a

set of dominant consultancy competencies contributing to successful ERP implementations.

Those competencies include communication skills, time management skills, ability to work

under pressure, assertiveness, business knowledge and savvy and technical competency.

These characteristics are found to specially benefit ERP implementations in large private

sector organizations. On the contrary, no indications were found that SME’s and/or public

organizations will benefit these characteristics differently. At last, the study proposes several

suggestions for future research.

Keywords: ERP consultancy; ERP implementations; consultancy characteristics,

competencies and professional skills.

Table of content

Abstract

1. Introduction 1

2. Literature Review 3 2.1 ERP systems 3 2.2 External ERP consultancy 6 2.3 Client firm 8 2.4 Research framework 11 2.5 Schematic literature review 16

3. Methodology 18 3.1 Research process, philosophy, approach and design 18 3.2 Data collection methods 21 3.3 Data analysis 23

4. Research Findings 24 4.1 Literature analysis finding 24 4.2 Primary data findings 29

5. Discussion and Analysis 32 5.1 Important skills and roles for external ERP consultants 32 5.2 Differences between private and public sector organizations: impact on ERP implementation 33 5.3 Effects of enterprise size on ERP implementation 34 5.4 The enhancement of professional skills in ERP implementations 35 5.5 Conclusions 36

6. Conclusion 38 6.1 Sub conclusions 38 6.2 Managerial implications 39 6.3 Limitations of the study 40 6.4 Scope for the future research 40

7. References 42

8. Appendices 54

Table and figure index Table 1: Role distinctions 6!Table 2: Consultation role 13!Table 3: Consultant characteristics 14!Table 4: Client firms’ characteristics 14!Table 5: ERP system literature 16!Table 6: Project management literature 17!Table 7: External consultancy literature 17!Table 8: External ERP consultancy literature 17!Table 9: Keywords 21!Table 10: Major themes within ERP literature 24!Table 11: ERP implementation CSF's 26!Table 12: Key players in ERP implementations 27!Table 13: Skills important for external consultants 27!Table 14: Main differences between public and private sector organizations 28!Table 15: Interviewee details 61!

Figure 1: Research framework (adopted from Jang and Lee (1998)) 12 Figure 2: Success matrix 15

1

1. Introduction

The last two decades companies have spent billions of dollars for the purpose of

implementing Enterprise Resource Planning (ERP) systems, however only a small part of

these implementations succeed (Wang and Chen, 2006). An EPR system is a comprehensive

business software package, functioning to integrate all of the businesses its functions and

processes, seeking to provide a holistic overview of the business from a single IT

architecture (Klaus, Roseman and Gable, 2000). ERP systems promise to deliver seamless

integration of information flows (Davenport, 1998) and business processes (Mabert, Soni

and Venkataramanan, 2003) and therefore leading to operational efficiency gains (Law and

Ngai, 2007) and ultimately to competitive advantages (Dazdar and Ainin, 2011). Although

ERP systems promise major operational improvements, its implementations have to date

been encircled with failed projects (Amid, Moalagh and Ravasan, 2012). A major 2013

survey (Panorama consultancy, 2015) showed that today still 54% of ERP projects are cost

overrun; 72% time overrun and 66% of ERP system-implementing firms perceived less than

half of the anticipated measurable benefits. In order to increase ERP implementation success,

last decade research has primarily focused on factors that would contribute to successful

ERP implementations. Under the name of ‘critical success factors’ (CSF’s) numerous studies

have examined what variables lead to a constructive ERP deployment (Thong, Yap and

Raman, 1996; Wang and Chen, 2006; Sumner, 2000; Somers and Nelson, 2001). Among the

results, the CSF of ‘bringing in external expertise’ is a recurrent variable. In accordance,

ERP consultancy is considered the most dominant a form of such ‘external expertise’ (Ko,

Kirsch and King, 2005). Besides the fact that ERP consultancy is mentioned as a critical

success factor for ERP system implementations, the role ERP consultancy has hardly been

studied. However, examining the impact of ERP consultancy on an ERP system

implementation could yield valuable information. If the consultation process becomes more

effective, this will have impact on the success rate of ERP implementations. Thus, more

effective consultation will lead to more effective ERP implementations. The nature of

information this study intends to find is about how professional skills of external consultants

affect ERP implementations (Appelbaum and Steed, 2005; Schein, 1990; Nees and Grenier,

1986). This information can then serve ERP consultancy firms to optimize their consultancy

processes. Likewise client firms can benefit from this information since they can beforehand

consider what specific type of consultant to hire. Practical relevance of this study therefore is

found within a deeper understanding of how a consultant (positively) affects ERP

implementation projects, and enables them to closer align objectives with the actual results.

Academic literature will benefit from this research because as more understanding of how to

engage in an ERP system implementation is available, more accurate and applicable

2

implementation models can be developed, with as ultimate goal, to decrease ERP system

implementation failure rates.

In accordance to above discussed relevance, the following research question, and

accompanying sub-research questions were constructed:

“How do professional characteristics of external ERP consultants affect ERP system

implementations in large, private sector business organizations?”

The research question specifically focuses on large and private sector businesses. The

literature review will further elaborate on these variables and the motivations for adopting

those. The accompanying sub-research questions are:

• What are the most important skills to be possessed, and roles to be taken on by

external ERP consultants for an effective ERP system implementation?

• What are the main differences between private and public sector organizations and

what are the implications of these differences on ERP system implementation?

• What are the main differences between SME’s and large enterprises and what are the

implications of these differences on ERP system implementation?

• What are the ways of enhancing personality skills of external ERP consultants to

increase the effectiveness of ERP system implementation in private sector?

For the remainder of the paper, first a literature review will be executed in order to set the

boundaries of the research. Subsequently, with the obtained findings of the literature review,

a conceptual model is presented. Thereafter, in the first place, literature analyses are

conducted. Besides, a small empirical research is executed. The methodological justification

will be presented in chapter 3. The findings and discussion of both the literature analysis as

of the empirical research are then presented in chapter 4 and 5 respectively. At last, the

chapter 6 will present conclusions, managerial implications and suggestions for future

research.

3

2. Literature Review

This chapter will review most important literature following logically from the research

questions. First literature about ERP systems, their effectiveness, its implementation, its key

players and its implications will be reviewed. Subsequently the roles and competencies of

the consultant are considered. Thereafter, firm size and sector and their capacity to obtain

knowledge will be discussed. At last, the research framework, and a schematic overview of

all regarded articles will be presented.

2.1 ERP systems

ERP systems originate from the in the 1950’s developed: Material Requirement Planning

(MRP) software. This software was created to more efficiently order required materials for a

production process (Klaus et al., 2000). Through further development of the MRP software,

first MRP II and later the ERP systems were introduced. The new software entailed new

functionalities like sales planning, human resource management, finance and distribution.

Nowadays total integrated business software programs have been introduced (Klaus et al.,

2000). Basically, all company data is saved the moment it is generated, centrally stored and

updated real time. Taken together, the company-wide application facilitates governance of

the firm; comprehensive information where to managers can base their business decisions

upon (Hendricks, Singhal and Stratmann, 2007). Markus and Tanis (2000) state that the

integration of Supply Chain Management data, Human Resource Management data,

Customer Relation Management data and Financial Management data into a single storage,

that can be assessed in order to “enhance business performance, financial predictability,

productivity and decision making” (Kähkönen, Maglyas and Smolander, 2014: p.1) can be

considered an ERP system.

Benefits

ERP systems benefit (both small and large) organizations in different ways (for an

enumeration see: Markus and Tanis, 2000). Generally, because of its integrative character,

ERP systems often replace several mutually operating and sometimes even overlapping

interfaces. As a results to this, the flow of information within organizations improves, to wit

for example order cycle times reduce (Cotteleer, 2002; McAfee, 2002), automated financial

transactions reduce accounts payable, and less efforts have to be made to reconcile financial

overviews (Mabert et al., 2000; 2003; McAfee, 1999; Stratman, 2001; Hendricks et al.,

2007). Increased efficiency, productivity and quality of business processes is the aim (Gable,

Sedera and Chan, 2003). After implementation, ERP systems support tactical and strategic

directions of an organization as well as create a competitive advantage by enabling

4

innovative operational practices (Al-Mashari, Al-Maimigh and Zairi, 2003; Chen, Law and

Yang, 2009). Many authors, in accordance researched whether (and to what extent) ERP

implementations actually contribute to the organizations’ performance. Hitt, Wu and Zhou

(2002) for example conducted a research assessing multi-year implementation and financial

data (consisting of 24’000 firm-years). This research clearly confirmed that “ERP adopters

are consistently higher in performance across a wide variety of measures than non-adopters”

(p. 93). With Hitt et al., (2002) many more research shows evidence for the increase in

operational performance (Cottelleer, 2006; Mabert et al., 2000; McAfee, 2002; Poston and

Grabski, 2001). Hendricks et al. (2007) likewise assess the impact of an ERP implementation

on the organizations performance. They however are less positive regarding ERP’s after-

implementation performance gains, as they could not find statistical evidence to attribute

performance improvement to ERP implementations. Scientific literature delved deeper into

this imparity and Madapusi and D’Souza (2012) suggest that this imparity is caused by the

variable statuses of an ERP implementation. As mentioned in the introduction, because of a

wide variety of reasons (e.g.: Pan, Newel, Huang and Cheung, 2001), many organizations

today still fail to successfully implement an ERP system (Chen, Law and Yang, 2009;

Panorama, 2015), and this research considers an ERP implementation failed when the system

does not provide a proportional potential of its promised improvement (Davenport, 1998;

Umble, Haft and Umble, 2003).

When reviewing ERP literature, quite an extensive part of ERP system implementation

literature comprises of CSF’s. Holland and Light (1999) were among the first to identify

certain critical success factors. This research direction kept on growing, whereas a wide

variety of different perspectives on ERP system implementations were developed: success

drivers (Ehie and Madson, 2005), the business process management perspectives (Jarrar, Al-

Mudimigh & Zairi, 2000), project management perspectives (Motwani, Mirchandani, Madan

& Gunasekaran, 2003), the application of the technology acceptance model on ERP systems

(Amoako-Gyampah and Salam, 2004). Furthermore the role of different players within the

implementation process is has been examined extensively (e.g.: Ke and Wei, 2008;

Akkermans and Van Helden).

5

Key players

There are three main stakeholders within an ERP implementation process: 1) the client firm,

2) the ERP vendor, and 3) the external consultant (Fui-Hoon Nah, Lee-Shang Lau and

Kuang, 2001; Hossain and Sakir, 2001; Gable, Scott and Davenport, 1998). The client firm is

the organization into where the ERP system is going to be implemented. Basically

organizations in all segments of the market are subject of an ERP implementation, whereas

the vendor is the firm that develops the ERP software. The vendor therefore has much

expertise of the product (Klaus et al., 2000). Examples of major ERP vendors are SAP,

Oracle, Sage and Microsoft (Pang, Dharmasthira, Eschinger, Motoyoshi and Brant, 2012).

The total ERP system vendor market consisted of $20 billion (US) revenues in 2000,

whereas the forecasted revenues for 2016 are about $33 billion (US) (Statista, 2015). As

Sumner (2000) states: (For the implementation of an ERP system) “it is often critical to

acquire external expertise, including vendor support, to successfully implement (p.320).

Therefore external consultancy firms are often brought in as a third party, by the ERP

implementing firm (Helo, Anussornnitisarn and Phusavat, 2008). This consultancy process is

complex whereas their consultants need to be knowledgeable about the software they work

with (Kansal, 2007). Some authors stress the need for external consultants (Finney and

Corbett, 2007), whereas others note that consultants are not so important (Akkermans and

Van Helden, 2001). Anyhow, there are many major consultancy firms that specialize in ERP

implementations. The consultants’ task is to help the client firm to successfully implement

their newly acquired ERP system. This external consultant can, through taking on different

roles and activities, contribute to this main task.

6

2.2 External ERP consultancy

IT consulting now yields the largest revenue stream of all management consultancies areas

(O’Mahoney and Markham, 2013). Other than the name ‘IT consultancy’ implies, advisory

is focused on the business because the main reason for ERP implementations to fail is

because of business related issues. “They fail to specify and control what they (: client firm)

want” (O’Mahoney and Markham, 2013, p. 62).

Roles

Within consultancy projects, consultants take on different roles. Both professional as

scientific literature about the role of an ERP consultant will be examined. O’Mahoney and

Markham (2013) describe seven different IT consultancy roles. They hereby mention that it

is likely and desirable to simultaneously adopt various roles. Nees and Greiner (1986)

similarly discussed different consultancy roles. The segmentation they present however

emphasizes on general consultants within project management. Since our research clearly

considers the interaction between consultancy and ERP implementations from a consultants’

perspective, rather than from an ERP implementing firm, and since consultants will thus lead

the implementation project, this framework seems appropriate to discuss and adopt. In

addition, professional literature likewise distinguished several consultancy roles. Microsoft

Dynamics, an ERP system developer distinguishes five different consultancy roles, within

their “sure step methodology” and can be used as a guideline towards a successful

‘Dynamics’ implementation (Mircosoft Dynamics, 2006). Because the three segmentations

presented above originate from three different but all relevant areas of research (academic

consultancy, academic ERP implementation and professional literature) they complement

each other. The three role distributions have been analyzed and as adequate, and appropriate

as possible been merged. The merge of these roles lead to a widely applicable distinction.

Each specific interpretation can be found within appendix 1.

O’Mahoney & Markham (2013) Nees & Greiner (1986) MS Dynamics (2006)

Business owner/product man. Mental Adventurer Project Manager

Project Manager Strategic Navigator Engagement Manager

Business Analyst Management Physician Application Consultant

System Analyst System Architect Development Consultant

Technical Architect Friendly Co-Pilot Technology Consultant

System Architect

Coder

Table 1: Role distinctions

7

Competencies

Technical and operational knowledge is what makes consultants highly wanted in ERP

implementations (Chang, Wang, Jiang and Klein, 2013). Furthermore, as ERP consultants

have experience with ERP implementations, whereas clients have not, it is likely that ERP

consultants will more effectively implement an ERP system. Metrejean and Stocks (2011)

conducted a research with the use of surveys, in order to gain more insights in what

characteristics of an ERP consultants are considered valuable and enhance effectiveness.

First a list of valuable consultancy features was constructed from literature. Thereafter an

analysis of what and when those characteristics are most effective was done. The results of

this study correspond to Chang et al., (2013) and showed that ERP consultants are

considered most effective because of their technical skills, followed by their experience,

consulting skills and commitment. Concerning the phase of the implementation, ERP

consultants are rated most effective and necessary in the configuration and integration phase

of an ERP implementation (Metrejean and Stocks, 2011). Others (Djavanshir and Agresti,

2007) found that it is the communicative skill that is crucial. The ability to clearly

communicate is essential to transfer knowledge that will ultimately lead to achieving

objectives (Monge, Bachman, Dillard and Eisenberg, 1982). Liebowitz, Agresti and

Djavanshir (2005: in Djavanshir and Agresti, 2007) list several arguments to underpin their

statement. Proactive communication leads to avoidance of potential setbacks and

disappointments and thus keeping customers satisfied throughout the service process.

Furthermore through clear communication expectations of the customer are unlikely to be

too high. If this skill is not so well developed, clients might be disappointed. In accordance,

Wang and Chen (2006) found that consultants, through communicating enhance conflict

resolution, which in turn leads to better ERP system implementation. ERP consultants

furthermore must possess the skill to exactly understand the clients’ organization processes.

This leads towards a good understanding of what an ERP-implementing organization its

needs are and likewise what they expect the ERP system to do. Ultimately this understanding

leads towards alignment of the organization and its consultants’ objectives (Reich and

Benbasat, 2000). In other worlds: the ‘external’ must clearly understand the business

practices to then build a suitable solution. A lack of consultant understanding may

subsequently lead to inappropriate recommendations and a failing systems (Ford, 1985). As

an outcome of understanding businesses Basselier and Benbasat (2004) found that this

‘business knowledge’ significantly influences the intentions of ERP consultants to develop

the relationship with its client (p. 673). ‘Business knowledge’ in this article is knowledge

that is not focused on the IT-aspects of the business. It is considered knowledge in the

general, interpersonal and management domain. In other words: knowledge of business

practices outside their field of expertise: information technology. By understanding a client’s

8

needs – their whole system – IT professionals can act as “problem solvers” by using both

their business skills as their IT-capabilities (Basselier & Benbasat, 2004). Last mentioned

skill is not necessarily an initial requirement to successfully implement. However this skill

emphasizes on the consultants’ ability to ‘along the way’, make adjustments and redirect the

implementations.

2.3 Client firm

The research question entails a specific orientation to the type of organization in which this

study will look for answers. Large and private sector businesses are a focus of our research.

Furthermore, as client firms and ERP implementations are inextricable, this paragraph

presents an overview of client characteristics affecting ERP implementations.

Firm size

ERP systems have widely proven their importance as a strategic tool (Davies and Garcia-

Sierra, 1999; Soliman and Janz, 2004). For example, CRM tools embedded in ERP software

facilitate excellent tracking information over customers (Zheng et al., 2002), which in turn

enhances the firms’ capability to serve its customers more effectively. However, the

implementation of ERP systems is expensive because of adjustments of protocols, standards

and hardware, and costs regarding external advisory and switching costs (Soliman and Janz,

2004). Small organizations typically have “negligible buying power, limited access to

resources and information, compromised in-house IT experience, and a short-range

perspectives” (Burpitt and Rondinelli, 2000; Davies and Garcia-Sierra, 1999 in: Levenburg,

2005, p.95). Besides, it is argued that because of limited access to formal sources of external

finance, SME’s are constrained to growth (Beck and Demirguc-Kunt, 2006). Much research

has been done in order to identify specific differences between SME’s and large

organizations regarding IT adoption, integration and ERP benefits (Daniel and Grimshaw,

2002; Esteves, 2009; Turner, Ledwith and Kelly, 2009). Furthermore Hsin and Ching-Fang

(2005) conclude that generously available IS integration literature regarding large enterprises

cannot be generalized for SME’s due their different nature and characteristics. Therefore our

research distinguishes large organizations and SME’s.

According to Burpitt and Rondinelli (2000) and Davies and Garcia-Sierra (1999) small firms

are not likely to benefit by an ERP system implementation mainly because of their limited

resources. Therefore in this respect, it is appropriate to distinguish firm sizes according to its

resources (Dean, Brown and Bamford, 1998). Because the definition of the European

Commission is easy to operationalize, and likewise considers the organizations’ resources

(revenues and employees) the EC’s definition is considered applicable and therefore applied

9

to this research. The definition considers small enterprises to have fifty or less employees

whereas their turnover will not exceed EUR 10 million (OECD, 2005). On the contrary, this

research considers all businesses larger, in terms of turnover or employees as ‘large’.

Sector: Private and public

Furthermore this research focuses on private company organizations. Namely, the fact that

culture of public and private organizations greatly differs from each other has certain

implications for its ERP implementation process (Wagner and Antonucci, 2004). Among

others, political structures, the values that are internally identified as rewarding and

organizational commitment, is very different for the two types of organization (Lyons,

Duxbury and Higgins, 2006; Van der Wal, De Graaf and Lasthuizen, 2008; Blick et al.,

2000; Houston, 2000; Perry and Rainey, 1988; Rainey and Bozeman, 2000). “The public

sector project team composition, tends to be quite different in order to accommodate

representation from the many departments and divisions” (Wagner and Antonucci, 2004,

p.4). Therefore it is appropriate distinguish those two types of organization. This research

chooses to focus on private organizations because of their more dominant market

positioning, thereby contributing to the practical relevance of this research.

Knowledge transfer

Following from client firm characteristics that influence a consultancy project, Wang and

Chen (2006) argue that information and knowledge sharing between sender (consultant) and

recipient (client) is paramount for ERP implementations. Through sharing of information

and knowledge a more solid and therefore more valuable relationship between a consultant

and its client can be build. Hereupon, the implementation project in a later phase can fall

back (Ford, 1985). Basically, initially a knowledge-gap between two the parties exists (Ko,

2014), whereas the transfer of knowledge is the main objective. Ko et al. (2005) extensively

researched competencies enabling effective knowledge transfer. Since this research was

published it is considered leading within the Knowledge Transfer literature. In his research,

knowledge transfer is defined as: “the communication of knowledge from a source so that it

is learned and applied by a recipient” (Ko et al., 2005, p.62).

The study found several antecedents for effective communication within the four main

groups of influencing factors; communicational factors, knowledge factors and motivational

factors. The first (communicational) factor is ‘source credibility’, “the extent to which a

recipient perceives a source to be trustworthy and an expert” (p.66). In other words, the

knowledge provided is by the client perceived to be useful (Mizerski et al., 1979). The

second (knowledge) factor is called ‘absorptive capacity’ that is defined as “the ability of a

10

recipient to recognize the importance and value of externally sources knowledge, assimilate

it, and apply it” (Ko et al., 2005, p.64; Cohen and Levinthal, 1990). This is considered a

function of the knowledge of the recipient prior to the consultancy process. Third factor is

‘motivational’ and is considered the amount of ‘shared understanding’ between consultant

and client. It is defined as “the extent to which the work values, norms, philosophy, problem

solving approaches, and prior work experience of a dyad are similar” (Ko et al., 2005, p.64;

Gerwin and Moffat, 1997; Nelson and Cooprider, 1996). Because such shared understand

diminishes barriers to understanding and acceptance between a consultant and client (Krauss

and Fussell, 1990) it contributes to an effective transfer of knowledge. Within the third main

group of influencing factors; ‘motivational factors’, both the recipient and source intrinsic

motivation to respectively receive and transfer knowledge positively influences the

transferring of knowledge. In this context, intrinsic motivation is a form of motivation

triggered by a person that will be directly satisfied by that action. Intrinsic motivations

appears when “an activity is valued for its own sake and appears to be self-sustained”

(Calder and Staw, 1975, p.599). In conclusion, the factors discussed here above positively

influence the flow of knowledge transfer between a source and a recipient (Ko et al., 2005).

This relationship entails a consultant-client relationship (Ko et al, 2005) and therefore will be

used to complement the constructs in a later presented conceptual model.

Success-implementations

All the above-discussed variables of consultancy interferences, are all supposed to contribute

to a successful ERP system implementation. A successful implementation can be considered

in different ways. As a consultancy process concerns the human engagement of activities

within a set time frame, it is considered a project (Reiss, 1993). Project management in

addition, is considered a combination of (external) management, planning and management

of change (Atkinson, 1999). As all these aspects apply to an ERP implementation practice,

and because an explicit ERP implementation definition for success lacks, this research

adopts a project management perspective. It is clear what is meant with project management,

and that ERP implementations are considered to be projects that need to be managed.

Defining ‘project management success’ however is difficult (Ika, 2009). The main aim here

is to derive an operational and measurable definition of ‘ERP implementation success’.

Bellout (1998) argues that project management success corresponds with effectiveness and

efficiency. Other authors (e.g.: Oisen, 1971) emphasize an organizations’ ability to stay

within the beforehand-agreed boundaries concerning costs and time. This is also referred to

as the ‘Iron Triangle’ (Atkinson, 1999; Westerveld, 2003). However, more recent literature

takes more variables into consideration, before drawing conclusions whether or not a project

succeeded. Because there are plenty examples of projects that exceeded time or/and costs but

11

are still considered a success (and vice versa), other criteria of success were introduced in

project management theory (Shenhar, Dvir, Guth, Lechler, Panatakul and Poli, 2005). Those

criteria are: ‘client satisfaction’, ‘realization of client’s strategic objectives’, ‘satisfaction of

end-users’ and ‘satisfaction of other stakeholders’ (Ika, 2009).

2.4 Research framework

In order to capture all variables and later examine how they will have an influence on ERP

implementation success, a model is adopted. This model will serve as research framework in

which all operationalized variables will be presented.

In research of Jang and Lee (1998), misalignment and misunderstanding between external

management consultants and their clients within project management was identified. Clients

asserted that consultants lack specific knowledge, objectivity and fail to meet the client’s

expectations. Consultants in turn claimed that they do not receive support of top

management while they are engaging the company (Zeira and Avedisian, 1989). The

misunderstanding between both parties led Jang and Lee (1998) to conclude that “this

situation points out the lack of knowledge by both the client and the consultant about what it

takes to implement successfully their work in a complex environment” (p. 67). Their study

therefore aims to identify how consultancy services contribute to project management

success.

Original model

As our study likewise aims to explore how external ERP consultants contribute to successful

ERP implementation, Jang and Lee’s model will be adopted to answer the research question.

Moreover, the model is appropriate because emphasize in both researches is on the

consultants’ perspective in a management consultancy project. By means of the conducted

literature review, we somewhat adjusted the variables with variable that throughout literature

concurrently have been put forward. These variables have shown, both individually as in

combination with each other, to be positive contributors to an ERP implementation.

However, their new practice is yet to be researched. The below presented research

framework displays the adopted model. As a side note to the model, Jang and Lee’s (1998)

assume that 1) consultants adopt a solitary advisory role, whereas the clients’ management

team executes and implements the project changes and 2) only external (rather than internal)

consultants are engaging in the implementation project. Clearly, this research does not adopt

the first assumption, as is it among the main objectives to examine how consultancy roles

contribute to management consultancy success. The second assumption on the contrary will

be adopted. Only the role of external consultants will be examined.

12

The model applied to the ‘ERP implementation’ practice is here presented. The two patterns

behind the ‘ERP implementation success’ variable stand for large and private sector

organizations. The research continues by shortly explaining all four variables.

Figure 1: Research framework (adopted from Jang and Lee (1998))

ERP!implementation!success!Consultants’!competencies!

Client!firms’!characteristics!!

Consultation!role!

13

Consultation role

The mode in which a consultant executes a project depends on the project specifics. Certain

projects require other ‘consultants’ than other projects. However, other implementation

projects require all roles at the same time. A consultant is therefore able to take on different

roles, depending on what is needed. However, not all consultancy firms, and therefore

consultants can bring all different types of required consultancy roles. At one point a

decision must be made whereupon the emphasize will be placed (Nees and Greiner, 1986).

The merged role distribution is here presented. The different roles will be examined in order

to see how, to what extent they contribute to a successful ERP implementation. The

appendix may be consulted to see how the roles were merged in order to come to the

following segmentation.

Consultants’ competencies

The earlier presented consultancy skills and competencies will now be summarized in order

to complement the study’s research framework.

At first, technical skills with ERP consultants have broadly been identified as a great

contributor to successful ERP implementations. Technical consultancy skills will be defined

as follows: “knowledge of a variety of technologies, including ERP systems” (Metrejean and

Stocks, 2011, p.8). Subsequently experience with ERP implementations was identified as an

enabler of ERP implementation-project success, whereas experience will be defined as:

“whether the consultants has been involved in ERP implementations and similarity of

previous implementations” (Metrejean and Stocks, 2011, p.8). Consequently, for several

reasons a consultants’ communicative skill is put forward as positively contributing to an

ERP implementation project’s success. Communicative skill in this context is defined as:

“being able to anticipate concerns and respond sensitively to needs and expectations” of the

client (Djavanshir and Agresti, 2007, p.46). At last, a consultants’ skill to identify

complications and along the way modify and adjust the implementation activities is called

‘understanding, sense and adjustability’ and will be defined as: “the language needed to

Consultation role Description Business analyst Planning the project; keeping overview over the different sub-processes; consultations

with client to identify goals and objectives and directs the implementation process. Project manager Communicate supportive and administrative activities to clients; be the link between

consultant and client throughout the process. System architect Design and write the technology solution, furthermore they adjust configurations and

integration of business processes. Technology consultant Controls high-level system-design and project mapping, ensuring the implementation is

indeed light, logical and efficient. Furthermore he assesses whether the project has met the objectives/requirements and if the software was rightly installed.

Table 2: Consultation role

14

communicate with and understand their clients” (Basselier & Benbasat, 2004, p.674).

Thereby IT consultants enable participation in important organizations decision-making

processes (Basselier & Benbasat, 2004). In conclusion, the variable ‘competence of

consultants’ consists of the following constructs.

Client firms’ characteristics

By means of the earlier identified factors enhancing knowledge transfer, the variables will

here be constructed and presented. Regarding communicational factors Ko et al. (2005)

found that the more a recipient finds its source reliable, the more transfer of knowledge will

occur. Translating this to a client-perspective characteristic enhancing transfer of knowledge,

the ‘clients trustfulness’ positively affects knowledge transfer. Regarding knowledge

factors, the absorptive capacity of a client positively contributes to extent knowledge is

effectively transferred and therefore, a ‘clients’ absorptive capacity’ enhances this process.

Likewise ‘shared understanding’ of work principles enhances knowledge transfer.

Converting this to a clients’ perspective, we derive ‘understanding of a consultants’ work

values, norms, philosophy, problem solving approaches, and prior work experience’ as

positively influencing knowledge transfer. At last, among the motivational factors, Ko et al.

(2005) identified ‘intrinsic motivation of the recipient’ positively contributes knowledge

transfer. We therefore adopt this as the final construct. In conclusion, the variable ‘Client

firms’ Characteristics’ consists of the following constructs.

Skills Description Technical skills The extent to which the consultant has extensive knowledge and deep understanding of

the workings of a variety of technologies of the potential ERP system. Level of experience The extent to which the consultant has been involved in ERP implementations before and

the similarity of these previous implementations. Communication skills The extent to which the consultant is able to anticipate concerns, proactively discusses

those, and to which he responds sensitively to needs and expectations of the client. Understanding, sense and adjustability

The extent to which the consultant speaks the language needed to communicate, is congenial, and understands its clients.

Table 3: Consultant competencies

Client firms’ characteristics

Description

Clients trustfulness The extent to which a recipient perceives a source to be trustworthy and an expert

Client’s absorptive capacity

The ability of a recipient to recognize the importance and value of externally sources knowledge, assimilate it, and apply it.

Understanding of a consultants

The extent to which the work values, norms, philosophy, problem solving approaches, and prior work experience of the dyad are similar.

Intrinsic motivation of the recipient

The implementation activity is valued for its own sake and appears to be self-sustained.

Table 4: Client firms’ characteristics

15

A side note to the abovementioned variable ‘Client firms’ characteristics’ and accompanying

constructs, this research assumes that the transferal of knowledge from consultants to the

client always positively contributes to the implementations’ success.

ERP implementation success

The authors adopt the measures that were identified as being an appropriate measures for

success. Therefore this research defines management consultancy success at five

dimensions: 1) the extent to which objective concerning time and 2) costs have been

exceeded or achieved, 3) end-user and 4) stakeholder satisfaction has been realized and the

extent to which 5) strategic objectives have been realized (figure 2).

Realization!of!strategic!objectives!

Time!

Costs!

Sat

isfactio

n!of!

end>user!

Satisfaction!of!

other!stakeholders!

Figure 2: Success matrix

16

2.5 Schematic literature review

The following table is presented in order to create a reference point. The table schematically

presents all considered literature. The literature consists of 100 articles total, of which 52

ERP systems related articles, 17 client-firm related articles, 26 consultancy articles and at

last, 5 project management related articles. Moreover, analysis of this literature, in

combination with the expert interviews is used to establish the research findings.

Table 5: ERP system literature

Topic Sub-topic Author Journal

ERP systems

CSF's Akkermans & Van Helden (2002) European Jrnl of Information System

Al-Mashari, Al-Mudimigh, & Zairi (2003) European Jrnl of operational research Bingi, Sharma, & Godla (1999) IS Management Ehie & Madsen (2005) Computers in Industry Finney & Corbett (2007) Business Process Management Jrnl Fui-Hoon Nah, Lee-Shang Lau & Kuang, (2001) Business process management Jrnl Holland & Light (1999) IEEE software Jarrar, Al-Mudimigh & Zairi (2000) European Centre for Total Quality Management Nah, Zuckweiler & Lee-Shang Lau (2003) Int Jrnl of Human-Computer Interaction Ram, Corkindale, & Wu (2013) Int Jrnl of Production Economics Somers & Nelson (2001) Proceedings of the 34th Annual Hawaii Int Conf*** Umble, Haft & Umble (2003) European Jrnl of operational research

Implemen-tation

Aladwani (2001) Business Process management Jrnl Amid, Moalagh & Ravasan (2012) Information Systems Amoako-Gyampah & Salam (2004) Information and Management Benjamin & Levinson (1993) Sloan Management Review Boonstra (2006) Int Jrnl of Project Management Chen, Law & Yang (2009) IEEE Transactions Hossain & Shakir (2001) Jrnl of Decision Systems Kansal (2007) Contemporary management research Law & Ngai (2007) Information & Management Mabert, Soni & Venkataramanan (2003) European Jrnl of operational research Markus & Tanis (2000)

Framing the domains of IT research: Glimpsing the future through the past*

Motwani, Mirchandani, Madan & Gunasekaran (2003) Int Jrnl of Production Economics Reich & Benbasat (2000) MIS quarterly Sumner (2000) Jrnl of Information technology Thong, Yap & Raman (1996) Information Systems Research

Characteristics, effect and implica-tions

Aladwani (1998) Proceedings of the 9th IRMA Conf*** Aladwani (1999) Industrial Management & Data Systems Cotteleer (2002) Harvard Business School Working Knowledge Davenport (1998) Harvard business review Gable, Scott & Davenport (1998) 9th Australasian Conf on Information Systems*** Gable, Sedera & Chan (2003) ICIS 2003 Proceedings*** Helo, Anussornnitisarn & Phusavat (2008) Industrial Management and Data Systems Hendricks, Singhal & Stratman (2007) Jrnl of Operations Management Hitt, Wu & Zhou (2002) Jrnl of Management Information Systems Kähkönen, Maglyas & Smolander (2014) Enterprise Information Systems Klaus, Rosemann & Gable (2000) Information systems frontiers Madapusi & D'Souza (2012) Int Jrnl of Information Management McAfee (1999) Presentation at Wharton Supply Chain Conf*** McAfee (2002) Production and operations management Pan, Newel, Huang & Cheung (2001) Twenty Second Int Conf on Information Systems Poston & Grabski (2001) Int Jrnl of Accounting Information Systems Wang & Chen (2006) Decision Support Systems

Others Bajwa, Rai & Brennan (1998) Decision Support Systems Dezdar & Ainin (2011) Management Decision Ke & Wei (2008) Decision Support Systems Mabert, Soni & Venkataramanan (2000) Production and Inventory Management Jrnl Nelson & Cooprider (1996) MIS quarterly Pang, Dharmasthira, Eschinger & Motoyoshi (2012) Forbes magazine*** Panorama Consultancy (2015) ERP report 2015*** Soliman & Janz (2004) Information & Management

17

Table 6: Project management literature

Project manage-ment

Success criteria

Atkinson (1999) Int Jrnl of project management Ika (2009) Project Management Jrnl Jang & Lee (1998) Int Jrnl of Project Management Oisen (1971) Project Management Quarterly Westerveld (2003) Int Jrnl of Project Management

Table 7: External consultancy literature

Table 8: External ERP consultancy literature

Table 8: Client firm literature

External ERP con-sultancy

Roles Chang, Wang, Jiang & Klein (2013) Jrnl of Systems and Software Metrejean & Stocks (2011) Academy of Information and Management Sciences Jrnl Microsoft Dynamics (2009) Official Microsoft Website ** Nees & Greiner (1986) Organizational Dynamics O'Mahoney & Markham (2013) Management consultancy* Zeira & Avedisian (1989) Organizational Dynamics

Compe-tences

Bassellier & Benbasat (2004) MIS quarterly Appelbaum & Steed (2005) Jrnl of management development Basselier & Benbasat (2004) MIS quarterly Djavanshir & Agresti (2007) IT professional Monge, Bachman, Dillard & Eisenberg (1982) Communication yearbook Schwartz (1998) Beyond computing Shenhar, Dvir, Guth, Lechler, Panatakul, Poli (2005) Project strategy: The missing link

Client-Consultant relationship

Ford (1985) Clients and Consultants: Meeting and Exceeding Expectations *

Liebowitz, Agresti & Djavanshir (2005) Communicating as IT professionals* Ko (2014) Information & Management

Knowledge transfer

Baum & Ingram (1998) Management Science Gerwin & Moffat (1997) Management Science Ko, Kirsch & King (2005) MIS quarterly Krauss & Fussell (1990) Intellectual teamwork: Social and technological foundations

of cooperative work* Mizerski, Golden & Kernan (1979) Jrnl of Consumer Research

Others Calder & Staw (1975) Jrnl of personality and social psychology Cohen & Levinthal (1990) Administrative science quarterly Drucker (1964) Managing for Results * Mitchell, Agle & Wood (1997) Academy of management review Schein (1990) Organizational culture *

Client firm characteristics

Size Beck & Demirguc-Kunt (2006) Jrnl of Banking & Finance Burpitt & Rondinelli (2000) Jrnl of Small Business Management Daniel & Grimshaw (2002) Jrnl of Information Technology Davies & Garcia-Sierra (1999) BT Technology Jrnl Dean, Brown & Bamford (1998) Strategic Management Jrnl Esteves (2009) Jrnl of Enterprise Information Management Hsin & Ching-Fang (2005) Proceedings of the 5th Int Conf on Electronic Business, Hong-

Kong *** Levenburg (2005) Electronic markets OECD (2005) OECD SME And Entrepreneurship Outlook** Turner, Ledwith & Kelly (2010) Int Jrnl of Project Management

Sector Blick, Gulledge & Sommer (2000) European Conf of Information Systems 2000*** Houston (2000) Jrnl of public administration research and theory Lyons, Duxbury & Higgins (2006) Public administration review Perry & Rainey (1988) Academy of management review Rainey & Bozeman (2000) Jrnl of public administration research and theory Van der Wal, De Graaf & Lasthuizen (2008) Public administration Wagner & Antonucci (2004) 37th Annual Hawaii Int Conf ***

18

3. Methodology

The main aim of this chapter is to explain how and why the adopted research method ideally

suits to answer the research question. In accordance with Saunders, Lewis and Thornhill

(2009), this chapter is structured as follows. First the research process, philosophy, approach

and design will be elaborated. Thereafter the actual data collection will be considered.

Eventually the data analysis process will be discussed.

3.1 Research process, philosophy, approach and design

In order to find a suitable and interesting research topic, a preliminary study was executed in

which most important literature was examined. Later an orientating interview with an expert

in the field of EPR system implementations was arranged. Thereafter the research questions

were constructed.

Saunders et al. (2009) emphasizes that first the research philosophy and research approach

should be identified before actual practical research decisions are to be made. The research

philosophy contains assumptions that underpin the research strategy and chosen research

methods as a part of this research strategy (Saunders et al., 2009, p.108). The philosophy of

this research can best be described as a pragmatic. The time span of the research is set, and

therefore the research adopted a research philosophy that is dynamic and entails a variable

time span. The research question aims to answer the ‘how’ question regarding the interplay

of certain variables. These questions will be answered using mainly theoretical research

techniques (literature analysis), and partially using practical research (expert interview

research). The pragmatic philosophy furthermore offers the opportunity to use multiple data

collection methods. In addition, values will play a large role in interpreting results because

the research will adopt both objective- as subjective points of view (Saunders et al., 2009,

p.119). These subjective views comprise the opinion of experts and will be discussed in the

result chapter. Objective views will be derived from the literature analysis.

Research approach

Constructing a research approach enables the researcher to take more informed decisions

about the research configurations, data gathering, its analysis and the interpretation of this

analysis (Saunders et al., 2009, p.126; Easterby-Smith, Thorpe and Jackson, 2008). The

deductive research is able to draw from a wealth of research literature; inductive research

cannot and therefore focuses on the building of new theory. However, a research can entail

both approaches whereas Saunders et al. (2009) argues that it is often advantageous to do so.

19

The researches’ literature analysis clearly takes on a deductive research approach because

this phase entails a theoretical examination of a predefined conceptual model. Robson (2002)

argues that testing relationships between two (or more) variables is a stage that a deductive

study goes through. The combination of two (inductive and deductive) approaches can be

justified by emphasizing on the lack of theory available about the research’ specific research

topic. Therefore an inductive perspective has been build into this research aswel.

Research design

The research design consists of the research strategy, research choices and quality issues.

Addressing these topics will transfer a research question into a research project (Robson,

2002). As this research adopts two research approaches it thereby uses two research

collection methods. This is ideally appropriate to answer the research objective: gain

understanding of a topic within a well-considered field of research, but with less discovered

sub areas that are believed to have an influence on that field of research. In other words,

much literature on the research topic of ‘ERP implementation success’ is available, and the

research strived to find answers by extensively examining this literature. However, much

less theory is available on the proposed variables that are believed to influence the outcome

variable. Therefore, because extant literature only very limited considers the research’ input

variables, a theory building perspective had likewise to be built into this research. Thus as

existing theory only partially considers the research focus, examining the extensive amount

of existing theory on the research’ variables on the one hand and complementing literature

with some newly build theory on the other hand, is considered as a rigorous and

comprehensive research method and therefore as ideally suitable. The type of data analysis,

wherein both primary and secondary data is considered, becomes increasingly supported in

business-research, whereas combining quantitative and qualitative data collection techniques

is defined as mixed-method research (Curran and Blackburn, 2001 in: Saunders et al., 2009,

p.151).

The literature analysis-phase aims to provide the author with enough relevant knowledge

regarding the four subtopics derived from the sub-research questions. In this respect, chapter

four has been organized according to the different sub-research questions. Subsequently, the

combination of implications from literature and the results derived from the expert-

interviews lead to the discussion of the main research question.

The empirical research-phase aims to come up with descriptive and explanatory answers to

how certain events are influenced (Oates, 2005). In accordance with explanatory research, a

qualitative research is most appropriate. Through qualitative research, more rich information

20

is gathered which allows the researchers to better understand and study the variables and

their relation in more detail (Oates, 2005).

In order to guarantee the research quality, the research takes into account certain criteria. At

first, construct validity, which is considered the extent to which the operationalized variables

actually measure what is being studied (Vos, Tsikriktsis and Frohlichh, 2002, p.221). Within

this research, attention to construct validity is paid through triangulation. Triangulation

stands for collecting evidence from multiple sources. The different sources of evidence

should confirm that the operationalized variables indeed measure the constructs of the

adopted model. This triangulation was accounted for by consulting scientific literature, the

execution of an extensive literature review and referring to the actual EPR consultants’

interviews. Thereafter internal validity, especially important for explanatory research (Yin,

2003, p.42), is considered the extent to which a causal relationship can be established.

Certain conditions, for example ‘professional skills of an external ERP consultants’, lead to

other conditions (Yin, 1994, p.35; in: Vos et al., 2002, p.221). In this research internal

validity is established though explanation building. Explanation building can be regarded as

a logically, good, successful, satisfactory, adequate, or acceptable explanation of an event

(Kidder and Judd, 1986). Working towards the research objective, a legitimate line of

reasoning will be build. This will lead not only to answering the main research question, but

will likewise contribute to the research’ its internal validity. The external validity is the

extent to which results derived can be generalized to a broader industry perspective (Vos et

al., 2002, p.221; Yin, 2003, p.43). The empirical research results of this study are somewhat

generalizable in the sense that its sample size was dynamic and to some extent corresponds

to the point of data saturation (Guest, Bunce and Johnson, 2006). Romney, Batchelder and

Weller (1986) found that experts tend to agree more with each other (within their field of

expertise), whereas a mathematical case showed them that “a small sample of experts can be

quite sufficient in providing complete and accurate information within a particular cultural

context, as long as the participants possess a certain degree of expertise about the domain of

inquiry” (Romney et al., 1986, p.74). Therefore to a certain extent this research takes

generalizability into account. However, tests with more generalizability should examine and

proof the results in order to appropriately generalize. Reliability is considered the extent to

which the research will derive same results if it was to be repeated, aiming to minimize

errors and bias (Yin, 1994, p.36; Vos et al., 2002, p.221). Reliability is covered by means of

the following actions: the establishment of an interview protocol and an interview database

(appendix 7 and 8). The extent to which research actions can be repeated herewith increased

intensely, which in turn ensured confidence in the research. Furthermore, rigor is another

important characteristic ensuring a research to maintain reliability (Mays and Pope, 1995).

21

Maintaining meticulous records of interviews and documentation is the way to reach

reliability. In addition, reliability is enhanced by a second, independent assessment of the

derived results, executed by another academic researcher. Organizing such a secondary

assessment will minimize the interpretability of the gathered results. This ultimately will

lead to better-substantiated conclusions (Mays and Pope, 1995).

3.2 Data collection methods

Article selection

The considered literature was selected by using Google Scholars search engine. The

following keywords (table 9; the keywords from the first row were combined with the

keywords of the second row,) were used to find literature. A short evaluation of the articles’

abstracts determined whether the articles were relevant and appropriate to use.

Keywords

‘Enterprise Resource Planning Implementation’

‘ERP System Implementation’

‘Implementation’

Combined with: ‘Management

consultancy’

‘Consultants’ ‘External

consultants’

‘Success criteria’ ‘Characteristics’ ‘Roles’

Table 9: Keywords

Expert interviews

In order to obtain adequate answers to the eminently specialist research questions, an expert-

interview method, using semi-structured interviews, was chosen to develop discussions and

explanations. Kvale and Brinkmann (2009) state that elite-interviews are interviews that are

conducted with experts or leaders within a to be analyzed population that allows a researcher

to obtain their opinion and a deeper understanding of the analyzed situation. By directly

face-to-face communication with your respondent (expert), more detailed and underlying

mechanisms can be questioned (Dorussen, Lenz and Blavoukos, 2005). In addition, by

executing interviews in a semi-structured fashion, the interviewer is able to directly respond

and tempt the interviewee to provide a better answer. This ensures the researchers every

interview generates answers that have the same level of depth and perspective and thus allow

to be analyzed in a corresponding manner (Kvale and Brinkmann, 2009). Another reason for

its applicability is that both interviewee and interviewer are able to talk freely and non-

directive which enables the interview to include unexpected events, behavior and believes

about the topic (Saunders et al., 2009; Cooper and Schindler, 2008; Voss, Tsikriktsis and

Frohlich, 2002).

22

Interviewee selection

In order to determine an appropriate sample technique Patton (2002) argues that this should

depend on the research question, research objectives, what techniques have credibility and at

last, what can be done within the researchers’ capability. Especially regarding data collection

from interviews, emphasize of the sample size is on the point of data saturation (Guest,

Bunce and Johnson, 2006). In addition, a non-probability snowball sampling technique was

adopted. Because experts within this field were difficult to find, a snowball sampling was

considered most suitable (Saunders et al., 2009).

A definition to ‘elite’ or ‘expert’ within the considered industry has to be provided in order

to identify and approach potential interviewee’s. Experts are people who are particularly

competent as authorities on a certain matter of facts (Beeke, 1995, pp. 7-8; in Flick, 2009).

Experts therefore can be considered as staff members with a specific function or knowledge

(Flick, 2009). Borger and Menz (2002), frequently cited specialists in this field, define

experts as: “Persons having technical process oriented and interpretive knowledge referring

to their specific professional sphere of activity. Thus, expert knowledge does not only

consist of systematized and reflexively accessible specialist knowledge, but it has the

character of practical knowledge in big parts. Because of the practical knowledge the authors

incorporate in their definition, which is valuable for this research, this research defines

experts alike. To ensure that indeed all interviewees match a minimum level of expertise,

criteria were set.

The criteria were set regarding experience, responsibility and diversity.

• A minimum period of time that the interviewee has been active in the field ERP

consulting is required. Since the fact that an average ERP implementation project

takes 14.3 month (Panorama consulting, 2015) and as we assume that after three

implementations a consultant has adequate experience, we set this period at (3 x

14.3, rounded up), 5 years.

• We assume that more responsibilities come with good performance. Therefore, as

this research requires experts that have performed well in their previous projects, we

look for consultants with responsibilities. As a level of responsibility is hard

measure, we set the criteria to at least have the responsibility over two other

consultants.

• The third criterion is on the one hand assuring that different practices are evaluated

in the study, and likewise it accounts for the study’s generalizability. This criterion

says that all interviewee’s must work in at least different departments.

23

Ultimately the respondents cooperated by assigning an interview, are presented in table 15,

in appendix 6. Their names have been ammonized.

After having constructed the interview protocol (appendix 7) first a pilot interview was

executed. This pilot interview was held with a former IT consultant that is no longer working

within that specific sector, however still has a lot of experience and industry knowledge. The

pilot interview pointed out the unclear questions and wrong emphasizes within some

questions. These questions were adjusted so that in every occasion of the interview it is clear

what was meant. Another aspect that was taken into consideration before executing the

expert interviews is the level of expertise that an expert expects its interviewer to have

(Flick, 2009). Because the expert is about to explain the workings and defects of complex

mechanisms, an interviewer must be very knowledgeable within its topic. If the expert does

not notice the interviewee’s knowledge, he/she might depreciate the interview that in turn

could lead too less reliable and valuable data. This research refers to that aspect since the

researcher has extensively studied literature about ERP implementations and the role of

consultancy, and therefore may be considered knowledgeable in this field.

3.3 Data analysis

Analysis of literature was conducted by means of thorough reading. After the literature

review was constructed, all articles were bundled by their main research topic (tables 5 to 8).

All bundled articles were analyzed by careful reading, with a particular focus on the themes

of the four sub-research questions: firm size, firm sector, effective consultancy skills and

their enhancement. This analysis eventually, in combination with the interview analysis, led

to the results chapter of this research. Furthermore all interviews were recorded and

transcribed ad verbatim (appendix 8) and analyzed. At first, all answers related to the

specific variables of the conceptual framework were categorized. By coloring-coding

answers concerning the same ‘domain’ a file with interview-answers, categorized by

variable, emerged (appendix 2 to 5). A domain here is defined as: “A theme that is an

abstract entity that brings meaning and identity to a recurrent experience and its variant

manifestations” (DeSantis and Ugarriza, 2000, p. 362). Doing this allowed the research to

quickly consider all answers to similar questions. Then, the research looked for unambiguous

and prevailing answering in order to be able to extract results from the interviews. According

to Saldana (2012) processing interviews like this is called “Theming the Data” and can be

considered as “an extended phrase that identifies what a unit of data is about and/or what it

means” (p.175). Furthermore this type of coding is adopted because it is appropriate for the

assessment of phenomena exploring a participant’ beliefs and experiences about a certain

topic (Saldana, 2012).

24

4. Research Findings

This chapter presents the research findings, which later will be subjected to critical analysis.

The findings chapter can be devided into two parts. The first paragraph presents the findings

of the literature analysis. These findings mainly focus on sub-research questions two and

three and appoint the difference in organizational characteristics (i.e.; size and sector).

Furthermore, the literature analysis could support findings of the interview results.

Moreover, the analysis serves to summarize most important literature within the field of

“ERP implementations”. The second paragraph of this chapter is devoted to the presentation

of the interview findings. This section focuses on the presentation of the interviews findings.

The interviews were designed to answer the sub-research question one and four, which

appoint the topics of roles, skills and their enhancement. The most noteworthy patterns

among responses of sample groups are presented here in a logical manner.

4.1 Literature analysis finding

The literature analysis has found evident answers to the sub-research questions on the topic

of the organizations’ sector and size. Literature analysis findings further indicate that major

themes in the research area include discussions about the essence of ERP and need for ERP

in organizations, CSF’s associated with ERP implementation, outcome of ERP

implementation initiatives and others. Table 10 below illustrates authors covering some of

these themes and their findings in a chronological order. More detailed discussions of the

most noteworthy aspects of findings are provided further below.

Theme in research area Author(s) Findings Essence of ERP Davenport (1998) • Platform for seamless integration for information

flow

Klaus et al. (2000) • Comprehensive business software package that integrates all business functions and processes

Jarrar et al. (2000) • Integrated multi-dimensional system

Need for ERP Parr and Shanks (2000) • Business restructuring • Decision making improvement

Al-Mashari et al. (2003) • Platform to enable innovative operational practices

Law and Ngai (2007) • Operational efficiency gains

Dezdar and Ainin (2011) • Source of competitive advantage

Outcome of ERP implementation

Hitt et al. (2002) • ERP adopters perform better than non-adopters

Amid et al. (2012) • Many case studies for failed ERP implementation

Table 10: Major themes within ERP literature

25

Essence of ERP systems and their importance for large organizations

Although there are many definitions of ERP, there are no vast differences between the

definitions and there is a consensus among authors that ERP deals with streamlining

information needs of enterprises. Accordingly, ERP system has been accepted as a

comprehensive business software package, functioning to integrate all of the businesses its

functions and processes, seeking to provide a holistic overview of the business from a single

IT architecture (Klaus et al., 2000, Mabert et al., 2003). There is a consensus among business

scholars and practitioners about increasing importance of ERP systems in terms of increasing

operational effectiveness through an efficient use of timely information. Specific factors

increasing the importance of ERP systems include but not limited to intensifying level of

competition in all industries, increasing complexity associated with running a business and

emerging role of information and utilization of information technology as a competitive

advantage for the business and others. It has to be clarified that literature review has found

confirmation for both, positive, as well as, negative outcomes for ERP implementation

initiatives. Specific nature of the outcome in each specific case is found to depend on the

impact of CSF’s discussed below.

Factors impacting the outcome of ERP implementation

Findings of the literature analysis indicate CSF’s associated with ERP implementation.

Figure 11 below illustrates these CSF’s, presented in order of frequency of being mentioned

in the literature.

26

Critical Success Factor Author(s) Management support Holland and Light (1999); Jarrar et al. (2000); Akkermans and Helden

(2002); Mabert et al. (2003); Ehie and Madsen (2005); Finney and Corbett (2007); Halo et al. (2008)

Effective change management Atkinson (1999); Jarrar et al. (2000); Akkermans and Helden (2002); Motwani et al. (2002); Mabert et al. (2003)

Finney and Corbett (2007); Halo et al. (2008)

Communication with stakeholders

Holland and Light (1999); Mabert et al. (2003); Finney and Corbett (2007)

Staying within deadline Oisen (1971); Holland and Light (1999); Finney and Corbett (2007)

Knowledge transfer and sharing Pan et al. (2001); Motwani et al. (2002); Wang and Chen (2006)

Staying within budget Oisen (1971); Ehie and Madsen (2005)

Training on ERP system Amoako-Gyampah and Salam (2004); Ehie and Madsen (2005)

Visioning and planning Holland and Light (1999); Finney and Corbett (2007)

IT infrastructure Jarrar et al. (2000); Mabert et al. (2003)

Shared belief in the benefit Amoako-Gyampah and Salam (2004)

Alignment between consultant and client

Jang and Lee (1998)

Feasibility evaluation Ehie and Madsen (2005)

Competence of project team Akkermans and Helden (2002)

Clarity of aims and objectives Akkermans and Helden (2002)

Vendor support Akkermans and Helden (2002)

Employee motivation Finney and Corbett (2007)

Consultant selection and relationship

Finney and Corbett (2007)

ERP strategy Holland and Light (1999)

Table 11: ERP implementation CSF's

Researchers such as Ke and Wei (2008) warn that although countless scientific papers have

been devoted to the analysis of CSF’s related to ERP implementation, there is a lack of

studies about the nature of impact of these CSF’s on the outcome of the project. In other

words, knowledge of CSF’s may not suffice to ensure successful outcome of the project due

to the presence of a wide range of company-specific and other factors that need to be taken

into account in each individual case.

Stakeholders and their role in ERP implementation

Research findings indicate that both types of organizational stakeholders, i.e. internal and

external stakeholders do impact implementation and the outcome of ERP systems to varying

extents. According to literature review findings, although internal and external stakeholders

can have effects on the pattern of implementation and the outcome of ERP systems, three

key players – the client firm, the vendor and external consultant, reserve the highest impact.

Table 12 below is constructed on the basis of works of amongst others, Klaus et al. (2000),

Boonstra (2006), Kansal (2007) and it illustrates the roles, critical success factors and

challenges associated with each key player.

27

Key player

Role Critical success factors Challenges

Client firm • Specifies needs and preferences unambiguously

• Provides necessary information to external consultant

• Closely cooperates with vendor and external consultant

• Technical knowledge and competence of senior level management

• Knowledge management practices

• Employee commitment to cooperate

• Lack of cooperation from middle and operational level employees

• Financial issues

Vendor • Adjusts its ERP system to meet client’s unique needs

• Closely cooperates with external consultant

• Business strategy • Years of operations • Commitment to quality

• Conflicts with external consultant

• Quality issues

External consultant

• Assesses needs of client firm and determines ERP system requirements

• Assumes intermediary role between vendor and client firm

• Addresses expectation and concerns of client firm

• Experience and expertise • Communication and

interpersonal skills • Level of technical

knowledge

• Lack of work experience

• Lack of comprehension of client’s ERP system requirements

Table 12: Key players in ERP implementations

The competencies of external consultants on implementation success of ERP systems

Findings of the literature review shed a light into important skills that can help external

consultants to perform their job duties with an increased level of effectiveness. Table 13

below illustrates these findings by specifying relevant characteristic to author(s).

External consultant characteristics Author(s) Communication skills Monge et al. (1982)

Djavanshir and Agresti (2007)

Halo et al. (2008)

Metrejean and Stocks (2011)

Technical and operational knowledge Chang et al. (2013)

Comprehension skills Reich and Besabas (2000)

Business savvy Basselier and Benbasat (2004)

Conflict resolution Halo et al. (2008)

Table 13: Competencies important for external consultants

ERP in private and public sector organizations and the impact of size on ERP

implementations

Findings of the secondary research indicate that the main differences between private and

public sector organizations relate to the primary objective of the organization, formalization

and bureaucracy (Rainey and Bozeman, 2000), organizational values (Wal et al., 2008) and

employee commitment (Lyons et al., 2006). Moreover, ownership (Perry and Rainey, 1988)

28

and employee motivation (Houston, 2000) have been found as the main distinctive points

between private and public sector organizations. Table 14 below summarizes research

findings about the main differences between public and private sector organizations.

Point of difference Private Sector Organization Public Sector Organization Primary objective Profit maximization Social objectives

Ownership Owned by individuals or groups of individuals. Ownership can be transferred

Owned by government. Ownership cannot be transferred

Level of bureaucracy Less bureaucracy More bureaucracy

Employee motivation Focus on extrinsic motivational tools such as income and tangible benefits

Focus on intrinsic motivational tools such as sense of contribution and accomplishment

Values 1. Profitability

2. Accountability

3. Expertise

1. Accountability

2. Effectiveness

3. Incorruptibility

Employee commitment Greater level of employee commitment to organization

Lesser level of employee commitment to organization

Table 14: Main differences between public and private sector organizations

Enterprise size has been found as a factor that determines the patterns and outcome of

implementing new IT systems such as ERP. For example, e-commerce emerges as an

internet-related IT system that attracts small and large-sized businesses for different reasons.

Specifically, large companies use e-commerce as an opportunity for simplifying the

complexity of internal processes, whereas smaller sized enterprises adapt similar systems

mainly to increase the volume of sales (Daniel and Grimshaw, 2002).

Lack of access to the formal sources of external finance has been found to be a significant

barrier in terms of achieving growth for small enterprises (Beck and Demirguc-Kunt, 2006).

Therefore, the probability for SMEs to face financial issues in their attempt to develop and

implement ERP systems can be assessed as significant. On the other hand, research findings

indicate to factors that can increase the probability of positive outcome for SMEs in

managing projects such as ERP implementation. The list of such factors has been found to

contain efficient client consultation, resource allocation, risk management and support from

senior management (Turner et al., 2009). Moreover, research findings indicate that strategies

used by SMEs to derive increased benefits from ERP usage include adoption of a long-term

vision towards the initiative and appreciating interconnected nature of ERP benefits

realization (Esteves, 2009).

Research findings indicate that differences between small and large organizations also relate

to the nature of problems faced during the adoption processes of integration technologies

29

such as ERP systems (Hsin and Ching-Fang, 2005). It has been found that while technical

issues due to the lack of experience, financial problems and managerial issues represent

major technology integration challenges for SMEs, large organizations have to deal with

strategic issues, change management and managerial problems.

4.2 Primary data findings

Semi-structured in-depth expert interviews have shed a light into the important variables of

the research framework. Interview questions addressed skills and roles that played an

important role in successful consultancy practices in the area of ERP implementation.

Communication

All experts mentioned the role of communication skills as a critical success factor impacting

the process and outcome of ERP system implementation. It has been found that both means

of communication, verbal and written is important for external consultants to transmit their

ideas to their client in a clear and unambiguous manner. Moreover, non-verbal

communication channels such as body language and gestures were mentioned during

interviews and interviewees recommend ERP consultants to master the skills of non-verbal

communication. According to interviewees, advanced communication skills are likewise

important for external consultants in terms of being able to capture unique aspects of the

organization and address them within the scope of the ERP implementation. The following

comment made during primary data collection method captures the essence of this idea.

“Are you capable of both communicating your own ideas, as well as extracting the exact,

specific and accurate business specific information? You should be able to obtain all

information that concerns and contributes the implementation.”

Functional business knowledge

Some interviewees stress the role of functional business knowledge for external consultants

engaged in projects with private sector organizations. It has been stressed that functional

business knowledge assists consultants in terms of developing and implementing ERP

systems in cost-effective manners, thus indirectly contributing to the client’s primary

objective of profit maximization. Moreover, according to interview findings a clear

distinction needs to be made between functional and interpersonal set of skills to be

possessed by external consultants. It has to be stressed that, interpersonal skills are found to

be more important than functional skills. This is because interpersonal skills are closely

associated with personal identity of consultants and therefore, they are more difficult to be

acquired and changed compared to the functional set of skills.

30

Experience

Experience emerges to be an important factor that directly affects the process of ERP

implementation, as well as, its outcome. It has been noted that experience allows consultants

to become more adept in dealing with a wide range of technical and other issues during

various stages of ERP implementations. The following comment of an interviewee can be

referred to in order to justify this point:

“It all starts with the consultant bringing experience to a project. This experience reduces

the change of making the same mistakes again.”

Additionally, timeframe available to complete the project and the budget of the project are

specified by interviewees as important factors and potential problem areas when developing

and implementing ERP systems. This can be interpreted as an indication to the immense role

of time management, multitasking and working under pressure as skills to be possessed by

external consultants.

Clients’ value judgement of the project

According to interview findings an important factor that affects effectiveness of ERP system

implementation and the outcome relates to the attitude of client firm’s workforce in general

and senior level management in particular. An interviewee, an experienced ERP consultant

stated that:

“For us it is absolutely essential that the client firms identify this project as strategic.

Therewith, a board member should take place in the ERP implementing control-group.”

In other words, it has to be ensured that employees of a client firm approach ERP with a due

level of importance appreciating its potential contribution to profit maximization and ERP is

not dealt with simply as a compulsory chore. External consultants can achieve this by

communicating the potential contribution of ERP systems to the achievement of

organizational objectives, thus potential benefits of ERP systems for each member of the

workforce.

Roles within the consultation process

Concerning the division of roles an ambiguous result was found. Experts stress that the

‘business analysist’ and ‘system architect’ are most important roles within ERP

implementation initiatives. These two roles are considered most important due to the fact

31

that both roles entail to in an early stage, clearly delineate and define the scope of the

project. Therefore these consultants are required to have both specific business knowledge

and software knowledge, and they need to be able to determine and monitor the scope of the

project remains achievable. In addition, it is important to take most important decisions in

the earliest stages of the implementation. The contributing competencies of these roles can

best be described as assertive and knowledgeable in an early stage of the implementation

initiative.

Assertiveness

ERP experts interviewed as a part of this study offer specific recommendations to external

consultants in terms of enhancing personal skills with positive implications on the level of

their professional competency. Previously mentioned, consultants are recommended to be

politely assertive when representatives of client firm aim to reduce costs at the expense of

ERP system functionality and overall quality. It is important to clarify that client intervention

to achieve cost reduction is usually results from lack of technical competence about ERP

systems, thus, ERP consultants are recommended to stay committed to functionality and

quality, deferring management attempts that threaten these priorities. The following quote

from interview transcript justifies this argument:

“Within ERP implementations, the client does not come first. Because this means that the

consultants does not provide the organizations with advice while that should be its main

function. You must set the boundaries of projects in order to make sure project (sizes) stay

achievable. You (read: the consultant) can see the consequences of certain decisions

whereas your client can not.”

Furthermore, the interviews shed a light into a set of challenges faced by external consultants

in ERP system development and implementation. These challenges are found to include

rules and regulations that restrict communication with other stakeholders, challenging

deadlines for ERP systems implementations and necessity to deliver advanced ERP system

staying within the allocated budget.

In the following chapter, the above-presented findings will be discussed. By merging the

literature analysis findings and interview findings we aim to create a constructive and

cohesive discussion answering all four research questions.

32

5. Discussion and Analysis

This chapter contains discussions and analyses of primary and secondary research findings in

an integrated manner. The chapter is divided into five parts whereas the first four paragraphs

are devoted to the discussion and analysis of an individual research sub-question. The last

paragraph presents conclusions on the first four paragraphs.

5.1 Important skills and roles for external ERP consultants

Primary and secondary research findings shed a light into that skills that are considered to be

important to be possessed by external ERP consultants. This study has confirmed the

importance of distinguishing between functional and interpersonal set of skills (e.g.:

O’Mahoney and Markham, 2013). It was found that functional skills and competencies relate

to technical knowledge, which can be acquired via learning, whereas interpersonal skills are

closely associated with personal identity. At the same time, interpersonal skills are found to

be more important compared to technical ones.

Communication

Communication skills emerge as one of the most important skills that external ERP

consultants need to possess. Results of primary and secondary research findings both

confirm communication skills as critically important for external consultants. ERP is usually

a new phenomenon for the majority of private sector organizations that employ external

consultants whereas a consultant is partially assigned with the responsibility of

communicating importance and use of ERP systems to employees at all levels. Moreover,

external consultants need to be able to comprehend unique aspects of client organization in

general and ERP system needs in particular. Research findings indicate that achievement of

this task without advanced written and verbal communication skills is overly difficult. The

role of non-verbal communication skills via body language has been found paramount as

well.

Assertiveness

Likewise, an important competence is the external consultants’ assertiveness. This point can

be explained by referring to the need for balance between cost considerations and ERP

functionality. This skill plays an instrumental role in assisting employees of client firms to

form realistic expectations about functionalities and limitations of ERP systems. In other

words, external ERP consultants have to deal with cost effectiveness vs. functionality debate

with senior management in a regular manner and consultants need to be assertive not to

compromise ERP system quality due to cost-saving priority.

33

Business savvy

Business knowledge in general and business savvy in particular has been found as another

important set of skills that external ERP consultants need to possess. Consultants need to

appreciate profit maximization primary purpose of private sector organizations and it has to

be ensured that ERP system contributes to the achievement of this objective in a substantial

way. Moreover, time management and working under pressure emerge as important personal

skills that need to be mentioned along these lines due to the necessity to complete projects

according to agreed deadline. Additional set of professional skills that are found to be

important for ERP consultants are found to include conflict resolution skills and technical

and operational knowledge.

Roles

The literature review conducted in chapter two has shed a light into different roles that could

be assumed by ERP consultants. The in chapter two constructed major roles of consultants

consist of business analyst, project manager, system architect and technology consultant. The

extent of need for each of these roles depends on a wide range of project-specific factors. In

other words, while research findings confirm the relevance of each of these roles for ERP

consultants in general, the importance of each role for a specific project depends on a set of

factors that can be unique for the given project. A competent ERP consultant has to be

comfortable with each of these roles from a professional point of view and perform in each

role according to circumstances surrounding the project they are dealing with. Taking into

account the nature of ERP systems and the dynamics of development in this area, it can be

argued that the roles of ‘system architect’ and ‘business analyst’ are more important for ERP

consultants compared to remaining roles. Accordingly, it is critically important for ERP

consultants to focus on developing personal and professional skills and competencies that are

required to exercise the roles of system architect and business analyst in an effective manner.

5.2 Differences between private and public sector organizations: impact on ERP implementation

Major differences between private and public sector organizations have been found to relate

to primary objective of the organization, formalization and bureaucracy, organizational

values, employee commitment, ownership and employee motivation and the nature of

differences were illustrated in Table 14 in the previous chapter. These differences between

private and public sector organizations have direct and significant implications on ERP

implementation procedures, as well as, on the outcome of relevant initiatives. These

implications are the following.

34

Firstly, it may take less time to implement ERP initiatives in private sector organizations

compared to organizations operating in public sector. Research findings indicate that due to

the concentrated ownership and less level of bureaucracy, decisions about ERP

implementation can be taken in a shorter period of time in private sector organizations

compared to organizations operating in the public sector. This is because private sector

organizations are guided by the main purpose of profit maximization and cost-benefit

analysis may represent the only criteria used to make a decision upon the implementation of

ERP systems. In public sector organizations, on the other hand, objectives to be achieved

tend to be multi-dimensional and decisions related to new system implementation may have

to be subjected to certain procedures resulting in slower processes of decision-making.

Secondly, ERP systems can be changed more quickly in private sector organizations. Due to

the differences between private and public sector organizations in terms of bureaucracy

levels as evidenced by research findings, change management can be implemented in private

sector organizations in shorter time as opposed to public sector organizations. It can be

argued that ERP systems need to be dynamic reflecting changes in internal and external

environments in a timely manner and private sector organizations are better positioned to

meet this demand compared to public sector organizations due to a higher level of flexibility.

Moreover, as evidenced by the work of Houston (2000), private sector employees are mainly

motivated by extrinsic motivational tools such as money and tangible benefits, whereas

intrinsic motivational tools such as personal perception of contribution and accomplishment

are effective when motivating public sector employees. Accordingly, once convinced about

potential contribution of implementing and using ERP systems to the bottom line, private

sector employees can become enthusiastic towards the initiative.

Thirdly, employees in private sector organizations may express greater commitment towards

the adoption and use of ERP systems. According to research findings, employees have a

greater loyalty and commitment towards organizations in private sector compared to the

public sector. Greater level of loyalty and commitment in private sector organizations may

prove to have positive effects on usage patterns of ERP systems. In other words, it can be

argued that private sector employees will exhibit enhanced cooperation and greater

commitment towards ERP system because they perceive the system as a tool they will have

to deal with in a long-term perspective.

5.3 Effects of enterprise size on ERP implementation

Research findings indicate to the presence of a linkage between size of an enterprise and

implementation of a wide range of new systems and procedures such as ERP systems. It has

35

been found that size of an enterprise impacts ERP implementation in the following ways:

Firstly, there is a greater need for ERP systems in large enterprises compared to small

enterprises. Due to a greater range and scale of processes and operations taking place in large

organizations, the need to streamline vast information related to these processes and

operations is greater as well, with implications for external consultants. Specifically, it might

be easier for individual ERP external consultants and ERP consultancy firms to market their

services to large organizations compared to SMEs via communicating potential benefits of

systems to the former types of organizations. Secondly, large enterprises have greater

opportunity to implement ERP systems compared to SMEs due to their financial position

and access to the external sources of finance. Secondary data findings indicate that

successful ERP implementation may be associated with substantial financial investments.

Thanks to their solid financial positions in most cases and greater excess to the external

sources of finance, large sized organizations are in the better position to afford a

sophisticated ERP system from a financial point of view compared to SMEs. This situation

creates greater opportunities for competitive advantage for large organizations via

streamlining all information into a single system to increase the efficiency of decision-

making. Thirdly, major challenges faced by organizations during the adoption of ERP

systems vary according to the size of the organization. Specifically, while large

organizations have to deal with strategic issues, managerial problems and change

management when adopting ERP systems, main problems faced by small organizations

during the same stage include technical issues related to system usage and financial issues.

Generally, the study has found that large enterprises are in the better position to benefit from

the development and implementation of ERP systems compared to enterprises of small sizes.

5.4 The enhancement of professional skills in ERP implementations

As it has been discussed above, a set of personal skills have been found to play a critical role

in terms of enabling external ERP system consultants to increase success chances of ERP

implementation initiatives. These skills have been found to include communication and time-

management skills, ability to work under pressure, assertiveness, business savvy and

technical competence. Findings of this study found that no real strategies have been

identified, nor are in place, to enhance the professional ERP implementation skills. Besides

very obvious training-days there is not much atentions for the enhancement of professional

skills. A reason for this lack of results might be found within the search procedure in which

set keywords were used to find scientific articles. Furthermore, literature of this type is

probably of a more professional nature whereas this study focused on academic literature.

36

5.5 Conclusions

Findings of this paper have certain similarities, as well as differences with previously

published works. The main similarities in findings relate to the increasing importance of

ERP systems and the continuation of this tendency for the foreseeable future, immense role

of communication and interpersonal skills for ERP consultants, and the need to take into

account organization-specific factors when engaging in ERP implementation. At the same

time, there are few differences between findings of this research and findings of other

literature previously published. Specifically, while previous works do not fully appreciate

the impact of organizational sector, private or public, on ERP implementation practices, this

study has found the impact of this factor to be significant. Moreover, unlike findings of

previous works, this study has found size of organizations to be a major factor affecting ERP

implementation and usage patterns. To summarize literature review findings, ERP is an

important platform for integration of information flows in a seamless manner and the need

for ERP is associated with gaining competitive advantage via operational efficiency.

Moreover, there is a range of technical and interpersonal skills to be possessed by external

ERP consultants in order to increase the level of their professional efficiency. Interview

findings confirm the most parts of the literature review findings, at the same time expanding

the current pool of knowledge in the research area. For example, it has been found that

differences between private and public sector organizations have certain implications on

ERP implementation and maintenance. These implications include less time to implement

ERP initiatives in private sector organizations compared to organizations operating in public

sector, greater flexibility of ERP systems in private sector organizations, and the opportunity

for greater commitment in public sector organizations towards the adoption and use of ERP

systems. Furthermore, interview findings shed a light into the impact of organizational size

on ERP implementation practices and the impact relates to a greater need for ERP systems in

large enterprises, greater opportunity for larger organizations to implement ERP systems

compared to SMEs due to finical variables and size-related challenges faced by

organizations during the adoption of ERP.

On the basis of discussions and analyses above, answer to the main research question can be

worded on the following manner. There is a range of skills to be possessed by external ERP

consultants that can have positive implications on ERP system implementations in private

sector organizations of large sizes. These skills include communication skills, time

management skills, ability to work under pressure, assertiveness, business knowledge and

savvy and technical competency.

37

It is important to note that while professional skills listed above can prove to be effective for

external ERP consultants in dealing with all types of projects, positive impact of these skills

are found to be even greater for large-sized private sector organizations. Research findings

indicate that organizations of large sizes operating in private sectors are better positioned to

gain maximum benefits compared to public sector organizations and/or organizations

operating in public sector due to the reasons discussed above. Accordingly, it can be argued

that important skills of external ERP consultants listed above are going to make the most

positive impact in private sector organizations of large sizes.

38

6. Conclusion

This is the last chapter of the work and it contains the summary of the study by revisiting the

research question and summarizing answers to each research sub-question. The chapter also

contains discussion of shortcoming of the study. The research is completed by identifying

scope for future studies on the basis of findings of this work.

This study has made a noteworthy contribution to the development of the research area.

Specifically, as it has been discussed in the literature review chapter, the majority of studies

conducted up to date were mainly devoted to the explanation of essence of ERP, discussions

of the need for ERP systems and analysis of the outcome of ERP implementation systems

using specific case studies. At the same time, there was no recent study that evaluated the

impact of personal characteristics of external ERP consultants on ERP systems

implementation in large, private sector business organizations. In specific, separate aspects

of the research problem such as skills and competencies to be possessed by ERP specialists

in general, implications of differences between private and public sector organizations and

ways of increasing the efficiency of ERP professionals have somewhat been covered in a

range of previous studies individually. However, there was no recent work that combined

these separate issues within the scope of a single study employing primary data collection

and analysis.

6.1 Sub conclusions

It is important for external ERP consultants to possess two types of competencies – technical

and interpersonal – in order to maximize the success of the project. The most important

professional skills that external ERP consultants need to possess in order to maximize the

impact of ERP implementation initiatives are found to include communication skills, time-

management skills, assertiveness and working under pressure. Functional type of skills that

external ERP consultants need to possess, on the other hand, are found to include general

work experience, business savvy and technological competence.

Concerning the main differences between private and public sector organizations, this

research has found that primary objectives of the organizations, formalization and

bureaucracy, organizational values, employee commitment, ownership and employee

motivation as greatest and most impactful differences. Implications of these differences on

ERP system implementations involve less time needed to implement the system and

opportunities to introduce modifications to the system faster in private sector organizations

compared to organizations in public sector. Moreover, this research has confirmed that there

39

is a greater commitment towards ERP systems implementation in private sector

organizations compared to public sector organization due to the greater level of employee

commitment in private sector in general.

Regarding the major points of differences between large and SMEs, include the level of

flexibility, financial strength and access to external sources of finance and the scope of their

operations. Due to these differences large enterprises have greater need for ERP systems

compared to SMEs and they face different set of challenges during the implementation

process. Likewise, the outcome of ERP implementation tends to differ for SMEs and large

organizations with organizations of large sizes deriving greater benefit with less effort.

Findings of the research have yet identified unambiguous strategies used by external ERP

consultants in order to enhance their professional skills with positive implications on the

level of effectiveness of ERP system implementation initiatives. This study has confirmed

the importance for ERP consultants to be able to assume different roles in a simultaneous

manner. Particularly, the roles of business analyst and system architect emerge as a critically

important for a successful ERP consultation practice. Moreover, emphasize is on effective

characteristics; professional skills, competencies and roles, however little is said about how

to enhance these traits. The discussion section comes with several propositions backed by

literature.

Answers to four research sub-questions lead to answer to the main research question about

the manners in which professional skills of external ERP consultants affect ERP system

implementations in organizations of large sizes and private sector business organizations. A

set of skills such as communication skills, time management skills, ability to work under

pressure, assertiveness, business knowledge and savvy and technical competency can assist

external ERP consultants to maximize the impact of their consulting efforts. This impact

tends to be greater for private sector organizations and organizations of large sizes because

these types of organizations are in a better position to gain more benefits from ERP system

implementation for the reasons discussed in previous chapters.

6.2 Managerial implications

As concluded, little emphasize within consultancy literature is about how to enhance

effective professional skills. However, taking into account globalization of businesses and

increasing cultural diversity in workplaces, investing in improving those effective

professional skills, and thereby likewise paying attention to a level of cross-cultural

awareness, this might be beneficial for enhancing consultancy effectiveness. Furthermore a

40

clear distinction between functional and interpersonal values and skills that should be

possessed by external consultants is to be made. In accordance, the client firm should

beforehand mainly pay attention to whether the potential consultancy firm developed its

interpersonal skills and whether values match those of their own in order to become effective

partners. At last, clients in cooperation with their consultant should be extremely thorough,

particularly right at the start of an implementation initiative. This is when most important

decisions are to be taken and therefore essential for an effective implementation.

6.3 Limitations of the study

Several shortcomings that relate to this study need to be fully acknowledged. Sample group

of only six respondents for semi-structured in-depth expert-interviews can be rightly

criticized as too small for generating research findings that can be referred to in other

studies. Ideally, sample group for this research needed to comprise at least 20 respondents

across greater range of industries and sectors so that greater depth and scope of discussions

and analysis could be achieved via comparing answers. Moreover, the quality of discussions

and depth of analysis of this paper might be compromised due to the fact that author of this

paper is not a seasoned researcher and this work is the first substantial research experience

that involves primary data collection and data analysis for the author. In other words, while

the author has applied uncompromised commitment to the quality of the work, the lack of

previous experience in primary data collection and analysis may be visible in quality of

discussions. Last but not least, an additional primary data collection method such as

questionnaire or focus group could be used in this research in order to obtain more

comprehensive primary data related to the research problem. In order to compensate, for the

little primary research emphasize was placed on secondary literature analysis.

6.4 Scope for the future research

Findings of this study indicate to the scope for future studies in the following directions.

Firstly, the same research problem needs to be further explored with the participation of

client company representatives as sources of primary data. This study has explored the role

of professional skills of external ERP consultants on the outcome of ERP system

implementation initiative interviewing ERP experts, thus approaching the issue for the

perspective of ERP consultants. The research omits the viewpoint of consultancy service

receiver i.e. client firm and this gap needs to be eliminated via conducting another study.

Comparison of results of the present and the proposed research can provide a greater insight

into the research problem. Secondly, a study needs to be conducted to evaluate implications

of cross-cultural differences on patterns of ERP implementation and usage. A comprehensive

literature review conducted for this study has found only one research (Shanks et al., 2000)

41

that assesses effects of cross-cultural differences on patterns of ERP implementation and

usage despite proven impact of culture on a wide range of other organizational processes and

practices. This gap in the literature needs to be eliminated via empirical study with an

application of a cross-country online survey. Specifically, employees representing diverse

cultural backgrounds need to answer questionnaire questions related to their attitude towards

ERP systems, as well, as their usage patterns of ERP systems.

42

7. References

Akkermans, H. & Van Helden, K. (2002). Vicious and virtuous cycles in ERP

implementation: a case study of interrelations between critical success factors.

European Journal of Information System, 11 35-46

Al-Mashari, M., Al-Mudimigh, A., & Zairi, M. (2003). Enterprise resource planning: A

taxonomy of critical factors. European journal of operational research, 146(2), 352-

364.

Aladwani, A. M. (1998). Coping with users resistance to new technology implementation: an

interdisciplinary perspective. Proceedings of the 9th IRMA Conference, Boston, MA,

17-20, 54-9.

Aladwani, A. M. (1999). Implications of some of the recent improvement philosophies for

the management of the information systems organization. Industrial Management &

Data Systems, 99(1), 33-39.

Aladwani, A. M. (2001). Change management strategies for successful ERP implementation.

Business Process management journal, 7(3), 266-275.

Amid, A., Moalagh, M., & Ravasan, A. Z. (2012). Identification and classification of ERP

critical failure factors in Iranian industries. Information Systems, 37(3), 227-237.

Amoako-Gyampah, K. & Salam, A.F. (2004). An extension of the technology acceptance

model in an ERP implementation environment. Information and Management 41, 731-

745

Appelbaum, S. H., & Steed, A. J. (2005). The critical success factors in the client-consulting

relationship. Journal of management development, 24(1), 68-93.

Atkinson, R. (1999). Project management: cost, time and quality, two best guesses and a

phenomenon, it’s time to accept other success criteria. International journal of project

management, 17(6), 337-342.

Bajwa, D., Rai, A. and Brennan, I. (1998), “Key antecedents of executive information

system success: a path analytic approach”. Decision Support Systems, 22(1), 31-43.

43

Basselier, G. and Benbasat, I. (2004). Business Competence of Information Technology

Professionals: Conceptual Development and Influence on Business-IT Partnerships.

MIS Quarterly, 28(4), 673-694.

Bassellier, G., & Benbasat, I. (2004). Business competence of information technology

professionals: conceptual development and influence on IT-business partnerships. MIS

quarterly, 673-694.

Baum, J. A., & Ingram, P. (1998). Survival-enhancing learning in the Manhattan hotel

industry, 1898–1980. Management Science, 44(7), 996-1016.

Beck, T., & Demirguc-Kunt, A. (2006). Small and medium-size enterprises: Access to

finance as a growth constraint. Journal of Banking & Finance, 30(11), 2931-2943.

Benjamin, R. I., & Levinson, E. (1993). A framework for managing IT-enabled change.

Sloan Management Review, 34(4), 23-33.

Bingi, P., Sharma, M. K., & Godla, J. K. (1999). Critical issues affecting an ERP

implementation. IS Management, 16(3), 7-14.

Blick, G., Gulledge, T., & Sommer, R. (2000). Defining business process requirements for

large scale public sector ERP implementations: A case study. ECIS 2000 Proceedings,

157.

Bogner, A. and Menz,W. (2002). "Das theoriegenerierende Experteninterview -

Erkenntnisinteresse, Wissensform, Interaktion," in A. Bogner, B. Littig, and W. Menz

(eds.), Das Experteninterview - Theorie, Methode, Anwendung. Opladen: Leske &

Budrich, 33—70

Boonstra, A. (2006). Interpreting an ERP-implementation project from a stakeholder

perspective. International Journal of Project Management, 24(1), 38-52.

Burpitt, W. J., & Rondinelli, D. A. (2000). Small firms' motivations for exporting: to earn

and learn?. Journal of Small Business Management, 38(4), 1.

Calder, B. J., & Staw, B. M. (1975). Self-perception of intrinsic and extrinsic

motivation. Journal of personality and social psychology, 31(4), 599.

44

Chang, J. Y., Wang, E. T., Jiang, J. J., & Klein, G. (2013). Controlling ERP consultants:

Client and provider practices. Journal of Systems and Software,86(5), 1453-1461.

Chen, C. C., Law, C., & Yang, S. C. (2009). Managing ERP implementation failure: a

project management perspective. Engineering Management, IEEE

Transactions, 56(1), 157-170.

Cohen, W. M., & Levinthal, D. A. (1990). Absorptive capacity: a new perspective on

learning and innovation. Administrative science quarterly, 128-152.

Cooper, D. R., & Schindler, P. S. (2008). International Edition: Business Research Methods

(10th edn). New York, NY :McGraw-Hill Irwin

Cotteleer, M. J. (2002). ERP: payoffs and pitfalls. Harvard Business School Working

Knowledge.

Creswell, J. (2002). Research Design: Quantitative and Qualitative Approaches (2nd edn).

Thousand Oaks, CA: Sage.

Curran, J. and Blackburn, R.A. (2001). Researching the Small Enterprise. London: Sage.

Daniel, E. M., & Grimshaw, D. J. (2002). An exploratory comparison of electronic

commerce adoption in large and small enterprises. Journal of Information

Technology, 17(3), 133-147.

Davenport, T. H. (1998). Putting the enterprise into the enterprise system. Harvard business

review, (76), 121-31.

Davies, A. J., & Garcia-Sierra, A. J. (1999). Implementing electronic commerce in SMEs—

three case studies. BT Technology Journal, 17(3), 97-111.

Dean, T. J., Brown, R. L., & Bamford, C. E. (1998). Differences in large and small firm

responses to environmental context: Strategic implications from a comparative

analysis of business formations. Strategic Management Journal, 19(8), 709-728.

DeSantis, L., & Ugarriza, D. N. (2000). The concept of theme as used in qualitative nursing

research. Western Journal of Nursing Research, 22(3), 351-372.

45

Dezdar, S., & Ainin, S. (2011). The influence of organizational factors on successful ERP

implementation. Management Decision, 49(6), 911-926.

Djavanshir, G. R., & Agresti, W. W. (2007). It consulting: Communication skills are key. IT

professional, 9(1), 46-46.

Dorussen, H., Lenz, H., & Blavoukos, S. (2005). Assessing the reliability and validity of

expert interviews. European Union Politics, 6(3), 315-337.

Drucker, P. (1964). Managing for Results, Harper Collins, New York, NY.

Easterby-Smith, M., Thorpe, R., & Jackson, P. R. (2008). Management research. 4th edition

Sage Publications London.

Ehie, I.C. & Madsen, M. (2005). Identifying critical issues in enterprise resource planning

(ERP) implementation. Computers in Industry, 56, 545-557.

Esteves, J. (2009). A benefits realisation road-map framework for ERP usage in small and

medium-sized enterprises. Journal of Enterprise Information Management, 22(1/2),

25-35.

Finney, S. & Corbett, M. (2007). ERP implementation: a compilation and analysis of critical

success factors. Business Process Management Journal, 13(3), 329-347

Flick, U. (2009). An introduction to qualitative research (4th edn). London: Sage

Publications.

Ford, C.H. (1985). Developing a successful client-consulting relationship, in: C.R. Bell,

L.N. Nadler (Eds.), Clients and Consultants: Meeting and Exceeding Expectations,

Gulf Publishing Company, Houston, TX

Fui-Hoon Nah, F., Lee-Shang Lau, J., & Kuang, J. (2001). Critical factors for successful

implementation of enterprise systems. Business process management journal, 7(3),

285-296.

Gable, G. G., Scott, J. E., & Davenport, T. D. (1998). Cooperative ERP life-cycle knowledge

management. In Edmundson, Bob & Wilson, David (Eds.) 9th Australasian

Conference on Information Systems, 29 September - 2 October, Sydney.

46

Gable, G., Sedera, D., & Chan, T. (2003). Enterprise systems success: a measurement

model. ICIS 2003 Proceedings, 48.

Gerwin, D., & Moffat, L. (1997). Withdrawal of team autonomy during concurrent

engineering. Management Science, 43(9), 1275-1287.

Gill, J., & Johnson, O. (2002). Research Methods for Managers. (3rd edn). London: Sage

Publications.

Guest, G., Bunce, A. and Johnson, L. (2006). ‘How many interviews are enough? An

experiment with data saturation and validity’, Field Methods, 18(1), 59–82.

Helo, P., Anussornnitisarn, P. & Phusavat, K. (2008). Expectation and reality in ERP

implementation: consultant and solution provider perspective. Industrial Management

and Data Systems, 108(8), 1045-1059

Hendricks, K. B., Singhal, V. R., & Stratman, J. K. (2007). The impact of enterprise systems

on corporate performance: A study of ERP, SCM, and CRM system

implementations. Journal of Operations Management, 25(1), 65-82.

Hitt, L. M., & DJ Wu, X. Z. (2002). Investment in enterprise resource planning: Business

impact and productivity measures. Journal of Management Information

Systems, 19(1), 71-98.

Holland, C. P., & Light, B. (1999). A critical success factors model for ERP implementation.

IEEE software, (3), 30-36

Hossain, L., & Shakir, M. (2001). Stakeholder involvement framework for understanding the

decision making process of ERP selection in New Zealand. Journal of Decision

Systems, 10(1), 11-27.

Houston, D. J. (2000). Public-service motivation: A multivariate test. Journal of public

administration research and theory, 10(4), 713-728.

Hsin, C. & Ching-Fang (2005). A comparative analysis between SMEs and large enterprises

in relation to integration technologies adoption, Proceedings of the Fifth International

Conference on Electronic Business, Hong-Kong, 839-848

47

Ika, L. A. (2009). Project success as a topic in project management journals. Project

Management Journal, 40(4), 6-19.

Jang, Y., & Lee, J. (1998). Factors influencing the success of management consulting

projects. International Journal of Project Management, 16(2), 67-72.

Jarrar, Y.F., Al-Mudimigh, A. & Zairi, M. (2000). ERP implementation critical success

factors – the role and impact of business process management. European Centre for

Total Quality Management, University of Bradford

Kähkönen, T., Maglyas, A., & Smolander, K. (2014). What do we know about ERP

integration?. In Enterprise Information Systems,(190), 51-67.

Kansal, V. (2007). Systemic analysis for inter-relation of identified critical success factors in

enterprise systems projects. Contemporary management research, 3(4).

Ke, W. & Wei, K.K. (2008). Organizational Culture and Leadership in ERP Implementation.

Decision Support Systems, 45(2) 208-218

Kidder, L. H., & Judd, C. M. (1986). Research methods in social relations. New York: Holt,

Rinehart & Winston.

Klaus, H., Rosemann, M., & Gable, G. G. (2000). What is ERP?. Information systems

frontiers, 2(2), 141-162.

Ko, D. G. (2014). The mediating role of knowledge transfer and the effects of client-

consultant mutual trust on the performance of enterprise implementation projects.

Information & Management, 51(5), 541-550.

Ko, D. G., Kirsch, L. J., & King, W. R. (2005). Antecedents of knowledge transfer from

consultants to clients in enterprise system implementations. MIS quarterly, 59-85.

Krauss, R. M., & Fussell, S. R. (1990). Mutual knowledge and communicative

effectiveness. Intellectual teamwork: Social and technological foundations of

cooperative work, 111-146.

Kvale, S., & Brinkmann, S. (2009). Interviews: Learning the craft of qualitative research

interviewing. Sage.

48

Law, C. C., & Ngai, E. W. (2007). ERP systems adoption: An exploratory study of the

organizational factors and impacts of ERP success. Information & Management,

44(4), 418-432.

Levenburg, N. M. (2005). Does size matter? Small firms' use of e!business tools in the

supply chain. Electronic markets, 15(2), 94-105.

Liebowitz, J., Agresti, W., & Djavanshir, G. R. (2005). Communicating as IT professionals.

Prentice-Hall, Inc.

Lyons, S. T., Duxbury, L. E., & Higgins, C. A. (2006). A comparison of the values and

commitment of private sector, public sector, and parapublic sector employees. Public

administration review, 605-618.

Mabert, V. A., Soni, A., & Venkataramanan, M. A. (2000). Enterprise resource planning

survey of US manufacturing firms. Production and Inventory Management

Journal, 41(2), 52.

Mabert, V. A., Soni, A., & Venkataramanan, M. A. (2003). Enterprise resource planning:

Managing the implementation process. European journal of operational research,

146(2), 302-314.

Madapusi, A., & D'Souza, D. (2012). The influence of ERP system implementation on the

operational performance of an organization. International Journal of Information

Management, 32(1), 24-34.

Markus, M.L. and Tanis, C. (2000), The Enterprise systems experience – from adoption to

success, Framing the Domains of IT Research: Glimpsing the Future through the Past,

RW Zmud, ed. Inc., Cincinnati, OH: Pinnaflex Educational Resources (2000).

Marshall, C., & Rossman, G. B. (2010). Designing qualitative research. Sage publications.

Mays, N., & Pope, C. (1995). Qualitative research: rigour and qualitative research. British

mediacal Journal, 311(6997), 109-112.

McAfee, A. (2002). The impact of enterprise information technology adoption on

operational performance: An empirical investigation. Production and operations

management, 11(1), 33-53.

49

McAfee, A., (1999). The impact of enterprise resource planning systems on company

performance. Unpublished presentation at Wharton Supply Chain Conference.

Metrejean, E., & Stocks, M. H. (2011). The role of consultants in the implementation of

Enterprise Resource Planning systems. Academy of Information and Management

Sciences Journal, 14(1), 1-25.

Microsoft (2009). Microsoft Sure Step Methodology. http://www.advantage.co.uk/wp-

content/uploads/2012/02/Microsoft_Dynamics_Sure_Step_Methodology.pdf

Mitchell, R. K., Agle, B. R., & Wood, D. J. (1997). Toward a theory of stakeholder

identification and salience: Defining the principle of who and what really counts.

Academy of management review, 22(4), 853-886.

Mizerski, R. W., Golden, L. L., & Kernan, J. B. (1979). The attribution process in consumer

decision making. Journal of Consumer Research, 123-140.

Monge, P. R., Bachman, S. G., Dillard, J. P., & Eisenberg, E. M. (1982). Communicator

competence in the workplace: Model testing and scale development. Communication

yearbook, 5(505), 27.

Motwani, J., Mirchandani, D., Madan, M. & Gunasekaran, A. (2003). Successful

implementation of ERP projects: Evidence of two case studies. International Journal

of Production Economics, 75, 83-96

Nah, F. F. H., Zuckweiler, K. M., & Lee-Shang Lau, J. (2003). ERP implementation: chief

information officers' perceptions of critical success factors. International Journal of

Human-Computer Interaction, 16(1), 5-22.

Nees, D. B., & Greiner, L. E. (1986). Seeing behind the look-alike management

consultants. Organizational Dynamics, 13(3), 68-79.

Nelson, K. M., & Cooprider, J. G. (1996). The contribution of shared knowledge to IS group

performance. MIS quarterly, 409-432.

O'Mahoney, J., & Markham, C. (2013). Management consultancy. Oxford University Press.

Oates, B. J. (2006). Researching Information Systems and Computing. London: Sage, p.341.

50

OECD (2005). OECD SME And Entrepreneurship Outlook: 2005, OECD Paris, Page 17.

Oisen, RP. (1971). Can project management be defined?. Project Management Quarterly,

1971, 2(1), 12-14.

Huang, J. C., Newell, S., & Pan, S. L. (2001). The process of global knowledge integration:

a case study of a multinational investment bank's Y2K program. European Journal of

Information Systems, 10(3), 161-174

Pang, C., Dharmasthira, Y,. Eschinger, C., and Motoyoshi, K. (2012). Market Share

Analysis: ERP Software Worldwide. Forbes magazine.

Panorama Consultancy. (2015). ERP report 2015.

Parr A.N. & Shanks, G. (2000). A taxonomy of ERP implementation approaches.

Proceedings of 33rd Hawaii International Conference on System Sciences

Patton, M.Q. (2002). Qualitative Research and Evaluation Methods (3rd edn). Thousand

Oaks, CA: Sage.

Perry, J. L., & Rainey, H. G. (1988). The public-private distinction in organization theory: A

critique and research strategy. Academy of management review, 13(2), 182-201.

Poston, R., & Grabski, S. (2001). Financial impacts of enterprise resource planning

implementations. International Journal of Accounting Information Systems, 2(4), 271-

294.

Rainey, H. G. & Bozeman, B. (2000). Comparing public and private organizations:

Empirical research and the power of a priory. Journal of Public Administration

Research and Theory, 10(2), 447-469.

Ram, J., Corkindale, D., & Wu, M. L. (2013). Implementation critical success factors

(CSF’s) for ERP: Do they contribute to implementation success and post-

implementation performance?. International Journal of Production Economics,

144(1), 157-174.

Reich, B. H., & Benbasat, I. (2000). Factors that influence the social dimension of alignment

between business and information technology objectives. MIS quarterly, 81-113.

51

Reiss B. (1993). Project Management Demystified (1st edition). Taylor & Francis, London.

Robson, C. (2002). Real World Research (2nd edn). Oxford: Blackwell.

Romney, A., Batchelder, W., and Weller, S. (1986). Culture as consensus: A theory of

culture and informant accuracy. American anthropologist, 88, 313–38.

Saldaña, J. (2012). The coding manual for qualitative researchers (14th edn). Sage.

Saunders, M. N., Lewis, P., & Thornhill, A. (2011). Research methods for business students,

5/e. Pearson Education India.

Schein, E. H. (1990). Organizational culture (Vol. 45, No. 2, 109). American Psychological

Association.

Schwartz, K. (1998). Putting Consultants on Your Team. Beyond computing, 7(6).

Shanks, G., Parr, A., Hu, B., Corbitt, B., Thanasankit, T., & Seddon, P. (2000). Differences

in critical success factors in ERP systems implementation in Australia and China: a

cultural analysis. ECIS 2000 Proceedings, 53.

Shenhar, A., Dvir, D., Guth, W., Lechler, T., Panatakul, P., Poli, M. (2005). Project strategy:

The missing link. Paper accepted to Academy of Management Annual Meeting,

Honolulu, Hawaii, USA.

Soliman, K. S., & Janz, B. D. (2004). An exploratory study to identify the critical factors

affecting the decision to establish Internet-based inter-organizational information

systems. Information & Management, 41(6), 697-706.

Somers, T. M., & Nelson, K. (2001). The impact of critical success factors across the stages

of enterprise resource planning implementations. In System Sciences, 2001.

Proceedings of the 34th Annual Hawaii International Conference on (pp. 10-pp).

IEEE.

Statista (2015). Global enterprise resource planning software revenue in 2011 and 2016.

http://www.statista.com/statistics/247557/global-erp-software-revenue/

Sumner, M. (2000). Risk factors in enterprise-wide/ERP projects. Journal of information

technology, 15(4), 317-327.

52

Thong, J.Y.L., Yap, C.S. and Raman, K.S. (1996). Top management support, external

expertise and information systems implementation in small business. Information

Systems Research, 248-67.

Turner, J., R., Ledwith, A., & Kelly, J. (2010). Project management in small to medium-

sized enterprises: Matching processes to the nature of the firm. International Journal

of Project Management, 28(8), 744-755.

Umble, E. J., Haft, R. R., & Umble, M. M. (2003). Enterprise resource planning:

Implementation procedures and critical success factors. European journal of

operational research, 146(2), 241-257.

Van der Wal, Z., De Graaf, G., & Lasthuizen, K. (2008). What’s valued most? Similarities

and differences between the organizational values of the public and private

sector. Public administration, 86(2), 465-482.

Voss, C., Tsikriktsis, N., & Frohlich, M. (2002). Case research in operations

management. International journal of operations & production management,22(2),

195-219.

Wagner, W., & Antonucci, Y. L. (2004). An analysis of the imagine PA public sector ERP

project. System Sciences, 2004. Proceedings of the 37th Annual Hawaii International

Conference on (pp. 8-pp). IEEE.

Wang, E. T., & Chen, J. H. (2006). Effects of internal support and consultant quality on the

consulting process and ERP system quality. Decision Support Systems, 42(2), 1029-

1041.

Westerveld, E. (2003). The project excellence model: Linking success criteria and critical

success factors. International Journal of Project Management, 21, 411–418.

Yin, R. K. (2013). Case study research: Design and methods. Sage publications.

Yin, R., (1994) Case study research, Beverly Hills, USA: Sage Publications.

Zeira, Y., & Avedisian, J. (1989). Organizational planned change: Assessing the chances for

success. Organizational Dynamics, 17(4), 31-45.

53

54

8. Appendices

8.1 Appendix 1

Role distinction: O'Mahoney & Markham (2013)

Business Owner /

Product Manager:

Ensure the business is satisfied with the delivered products: services and

functionality. Besides he controls the costs.

Project Manager: Responsible for planning of the project. Therewith he plans the resources

(including people) in order to at best supervise the ERP project. Major

difference in involvement of this role: sometimes he is a leading figure while

sometimes this role comes down to supportive and administrative tasks.

Business Analyst: Examines what needs an implementation project has. Discussing with various

stakeholders what is considered a success and what requirements they set the to

the new system, he will communicate, manage and prioritize these requirements

in order to function as a bridge between the business and the consultancy-

organization.

System Analyst: Then the system analyst will ensure that the business requirements meet the

actual technology implementation in an effective and efficient way.

Furthermore he ensures that integration, data-flows and structures are clear to

the client-business.

Technical Architect: This role actually designs and works the ERP system in order to align the

business requirements to the technology implementation.

System Architect: Focus is on the high-level system-design, project mapping and ensuring this

implementation is indeed light, logical and efficient.

(Coders): Write the program/built the system/product. Not common a consultancy role.

Role distinction: Nees and Greiner (1986)

Mental Adventurer: Scientific educated researchers that aim to provide creative answers to particular

issues in the client-firm.

Strategic Navigator: Economically skilled business planner who is able to identify and subsequently

define business goals and objectives.

Management Physician:

He initially identifies the clients’ problems and is the project manager that leads

the operation and implementation.

System Architect: This technologist/engineer is responsible for the design of the solution that is later

going to be implemented.

Friendly Co-Pilot: This is the experienced business advisor that functions as a sounding board for the

consultants and takes care of professional needs regarding the project.

55

Role distinction: Microsoft Dynamics (2009)

Project Manager: Manages the project, possibly in consultation with a client project manager.

Engagement Manager:

Supportive roles that facilitates communication with client throughout the

implementation project, manages client engagement and customer relations.

Application Consultant:

Analyses client-business processes, thereby describes what requirements the client

has, facilitates gap/fit analysis and tests and if needed adjusts the ERP

configurations.

Development Consultant: This role participates in the design and modification of the ERP systems. Thereby

he tests the functionality.

Technology Consultant: Analyses existing infrastructure, estimates required infrastructure, sets up

environments, installs software, optimizes performance, and performs upgrades. In

short it is the technician assessing the implementation of the ERP system.

Eight distinct consultant competencies, adopted from Metrejean and Stock (2011)

The roles that have been marked with the same color have been merged. O’Mahoney & Markham (2013) Nees & Greiner (1986) MS Dynamics (2006)

Business owner/product man. Mental Adventurer Project Manager

Project Manager Strategic Navigator Engagement Manager

Business Analyst Management Physician Application Consultant

System Analyst System Architect Development Consultant

Technical Architect Friendly Co-Pilot Technology Consultant

System Architect

Code

1. Technical skills and knowledge

2. Human interaction and communication skills 3. Business context skills

4. Consulting skills and knowledge 5. Objectivity

6. Experience with ERP implementations

7. Commitment to quality

8. Ability to manage ERP implementations

56

8.2 Appendix 2

Variable: consultation roles

Who Translated and summarized quote

General feedback consultation roles

Resp001 Distinction between lead and functional consultants. Lead controls ERP system wide. Functional controls specific departments.

Resp003 Work with standard MS Dynamics methods

Business analyst Resp002 Business analyst is the one that translates business processes into software design. "What does a client need?"

Resp005 Plays a very important role and is a great contributor to success as he often adds experience to a project, has the capability to understand the client and can translate these demands into best-practices and therewith software designs. He should have both business- and software oriented knowledge. Analysis phase, most important phase.

Project manager Resp005 No very specific skills needed to execute this task well. Experience and business specific knowledge is an advantage, however not required.

System architect Resp001 System architects are most wanted consultants. Within our company they can make decisions on board-level.

Resp002 He makes the blueprints of the structure. He makes sure every system is in convenient and logically positioned. A system architect is there to tell a customer what he can expect of his new system, and why it might be better to change business processes rather than the systems. We therefore distinguish a solution- and requirement-driven approach. The system architect often works through a requirement driven approach, whereas he says: "I will build this for you". A solution-driven approach works through: "This is what the solution supports, change your business into a solution-appropriate design". He furthermore does not configure systems

Resp004 Architecture is a difficult task. Often clients have already thought about how they want to have their architecture. The architecture should be a consequence and extension of the business strategy. Those two should match.

Technology consultant

Resp001 Must be extremely competent within their field. Further it is an advantage if they have affinity with the implementation. However, no requirement.

Resp002 Within ERP systems there is (hardly) no programming. Many software is standard. Therefore you nowadays do not need a programmer anymore. The art is within minimalizing the amount of custom-made software.

Resp003 They handle the communication between the business and their cloud driven applications and memory.

Resp005 With ERP systems, not important anymore. Very easy to mobilize one the moment you really need him. No standard role.

Most important Resp001 All of them, it has to be a good team. People from the team should be able to think cross-functional.

Resp002 The one cannot work without the other. So it is the team that makes the difference. Every role and their responsibility cannot be missed.

Resp005 It begins with the basis. The motivation, the atmosphere, cooperation and knowledge. Thereafter it is about the interplay between consultants and client. However, the analysis is absolute most important for the subsequent process steps.

Others Resp002 Infrastructural consultants, the people who connect the different modules with each other. If the infrastructure does not work, nothing works.

Resp004 An advisory role towards the board in order to thoroughly educate and create urgency and awareness for the change.

Resp005 Can be overlap between the roles. Especially between the system architect and business-analyst.

57

8.3 Appendix 3

Variable: Consultants competencies

Who Translated and summarized quote

General feedback consultants competencies

Resp001 I recognize many named consultancy competencies.

Resp002 I miss functional business knowledge. This is the through how one can just ask that one specific, relevant and important question. This is through which you understand what a client needs.

Technical skills Resp001 Technical skills are not as important as they can be learned throughout a career. Especially when compared to soft-skills that relatively harder to be learned. You use and deploy your resources as adequate and appropriate as possible. So if there is an urgent problem, do not send someone that is not too dexterous.

Resp002 Technical skills are not important for ERP system implementations. You do not want to write customized software, as 99.9% is standard-software. It is to their best interest and mine too have as little customization as possible.

Resp004 You don’t need technical skills. "In the land of the blind, the one-eyed is king". You know enough to convince your clients.

Level of experience Resp002 I have been working with my correct employer for twenty years now of which seven abroad. This enables me to understand and assess certain situations and consequences of particular decisions and likewise it makes me a valuable for multi-national companies. For me it is the difference between a tool-installer and a advisory consultant. It enables me to ask the right questions. Besides, my functional back group helps me with formulating these right and in depth questions in order to later choose the right set of software packages. for this specific companies.

Resp004 It all starts with the consultant bringing experience to a project. This experience reduces the changes of making the same mistakes again.

Communication skills Resp001 80% of your time, you are counseling your clients. Pedagogical worker. I see my work as a pure 'people-working' job. This job starts at in the coffee corner. Talking. Listening, more talking and more listening.

Resp002 It is important to communicate in a two-way fashion. You must be able to clearly make yourself understood. However, it is just as important to understand your client in order to provide them with suitable advice in the first place.

Understanding, sense and adjustability

Resp001 80% of your time, you are counseling your clients. Pedagogical worker. I see my work as a pure 'people-working' job. This job starts at in the coffee corner. Talking. Listening, more talking and more listening.

Resp002 You must and look for your 'new-best-friend'. Mostly this is a super-user that is to become your partner in crime, in order to share responsibility and mandate. Also workshops are given to develop understanding.

Resp005 These skills are about pushing but likewise about listening. Especially in the analyses phase you must be able to clearly and precisely extract what your client needs. This is done though listening, delving deeper and rephrase questions. After this phase, these skills become less important.

Most important Resp001 Modify your work force in order to account for different situations.

Resp004 Experience is most important because this provides you with knowledge about what can all go wrong and thus avoid those things from going wrong.

Others Resp001 Always considering problems from the clients’ perspective.

Resp002 Managing and adjust expectations in order to make sure that businesses do not have to high hopes of their 'new company'. It is not uncommon that companies think of new ERP systems as the holy grail for their business. Further business specific knowledge in order to select the right package that indeed rightfully support the business is very important.

58

Resp004 Are you capable of extracting the right information of your clients. This could be an fifth variable.

8.4 Appendix 4

Variable: Client organizational characteristics

Who Translated and summarized quote

General feedback on client organizational characteristics

Resp001 My most successful projects were with client-parties that had interest in the project. The information, feedback and explanations has to be processed and adopted because without, the project will fail inevitably.

Resp002 Within ERP implementations, the client does not come first. Because this means that the consultants does not provide the organizations with advise while that should be its main function. You must set the boundaries of projects in order to make sure project sizes stay achievable because you can see the consequences of certain decisions and your client cannot.

Resp003 For us it is absolutely essential that the client firms identify this project as strategic. Therewith, a board member should take place in the ERP implementing control-group.

Clients’ trustfulness Resp002 You have to earn trust through constructive advisory. And lets be honest, this happens at the coffee machine

Resp003 In an ERP project the success is made through creating a partnership. Strategic partnership wherein we together develop new software modules. We agree upon a roadmap for the length of five years, and as a trusted-advisor we work together to reach the goals. Very different being just a software supplier.

Resp004 The bigger companies most often do the big projects. This is because at those big companies there is a believe that a certain accountability is apparent which in turn leads to more trust. In reality this is complete non-sense, as most of the direct colleagues do not even know what their colleague is working on.

Clients’ absorptive capacity

Resp003 We work with reference-visits in order to make our clients more eager to familiarize them with the new package. Furthermore, we give workshops and instruction courses to the key-users. These key users have to transfer the knowledge to their internal staff.

Resp005 Very different from client to client. Change management is a great enabler to create this client-mind-set

Understanding of a consultant

Resp002 I cannot change the client; I can only change our self. This means that the 'understanding of an consultant' its responsibility is with the consultants rather than with the client firm. This leads us to the communication skills of the same consultants that enable him to clearly explain all. So the client has a certain level of communicating and the consultant should adjust himself to that level. So the locus of responsibility is wrong in this.

Intrinsic motivation of the recipient

Resp001 This is indeed a very important characteristic of the client; whether they like the project or not. This especially holds for our key-user. The moment this person is not skilled we tend to immediately swop this person who is skilled and enthusiastic. Otherwise the project will never become a success of which we get judged on.

Resp002 This is about the level of commitment at the clients' firm. The moment that the resistance is not dealt with internally, because the firm is not committed, there is a big problem. I cannot change the client organization and that is the responsibility of the client. This directly means that when a decision to implement an ERP system is taken, the whole internal organization has to believe and carry out this decision. A consultant you can try to do this but this will never be as effective.

Resp003 This is a very important client characteristic, especially at top-level commitment is very important. When the highest board is not involved in the ERP project we get very anxious. The board should emit that this change is critical, and that is where a successful project starts. This emits that every employee should contribute a successful implementation.

59

Resp004 There is a difference between management motivation and employee motivation for the implementation project. You get implementations where a manager wants the change but the employees are not motivated to change at all.

Resp005 In general the people that are involved with the project get enthusiastic. The challenge is to get the rest of the organization enthusiastic about the project. --- This responsibility is really with the client. The consultant will help to get everyone motivated. --- The consultant should very much look for a good personal connection with the key-users. Concrete we do not take action to look for this person. We just get appointed to a key-user. It could be beneficial for the process to vice-versa also select a key-user.

Most important Resp003 Besides a participating board, a personal match between the consultants and their firms is most important for the entire implementation. The interpersonal aspect of ERP implementations makes a personal match essential and indispensable.

Other Resp001 Client firms should internally always back up their own people. The moment all decisions that have been taken by other are to be decided over and over again, the process will suffer from great delays and therewith lose momentum.

Resp002 I make sure that the two-unit of the internal key-user and me are responsible and accountable for the project. This internal key-user should be 'one of them' and therefore the internal company is willing to work hard towards a success, as they do not want their key-user to fail. Furthermore the key-user are well-capable of explaining the changes to their own people. This still means that the change should be emitted from top-level,--- Furthermore, ERP implementations are about internal honesty. The reason for the ERP implementation and the big-picture and the strategic reasons behind the ERP project should be clearly explained. Even if this means that people will get laid off.

Resp003 We point towards the responsibility of the client. Especially the responsibility and ownership, which a board should take towards the project. The most successful clients have always had a board member in their project team. Another important factor is whether a firm is self-reliant. This enables them to again take responsibility and be directive when that is needed.

Resp004 A variable that I think is important is the extent to which an organization in like-minded. The extent of common purpose within a company. Especially regarding the ERP implementation.

Resp005 Client firms should internally always back up their own people. The moment all decisions that have been taken by other are to be decided over and over again, the process will suffer from great delays and therewith lose momentum. Furthermore, these persons will probably feel less respected.

8.5 Appendix 5

Variable: Success Who Translated and summarized quote

General feedback on success

Resp001 Success is a smooth GO-LIVE period. Furthermore whether or not a client refers you to others companies.

Resp002 Difficult question. We work with a quality-performance system OTAS. Previous to the project, the expectations and success criteria of the customer will be agreed upon and afterwards they will be assessed. This results in an average performance score. Furthermore the extent to which we have to develop and deliver customized software. This results in more satisfied clients. And at last, some emotional factors play a role. The way in which you afterwards shake hands and look back at the project is likewise a performance indicator.

Resp003 We have several main-themes that get defined previous to the project. Mostly after the analysis and diagnose phase those main-theses get defined. Those main-themes roll out into sometimes over three hundred points of functionality. Afterwards you just check whether those criteria have been met The moment we check whether these criteria have been is typically two month after the GO-LIVE, as at this point in time the company moved n the business-as-usual. Then you can ask: "are u satisfied?".

Resp004 I am not really often still involved at the project the moment it is finished. They more than once consider me as the scapegoat. They lay me off the moment they are able to finalize the project themselves.

Resp005 Normally after two to four month after GO-LIVE we assess the quality of the implementation. That is the moment when business gets back to normal and

60

thus can ask for a well-considered conclusion. However, it is not like we very specifically assess all before agreed upon criteria. This hardly ever happens in my business. In the end, an ERP system is a transactional system. It does not necessarily change your business processes and if they do, these improvements only get visible after a lot longer.

Time & Costs Resp001 Yes, especially important for the client.

Resp002 Not necessarily, but the client can and often does adopt these criteria.

Resp003 This is something you agree upon before and during the project.

Resp005 This is a criterion that is considered, it creates a certain pressure to the project.

Satisfaction of end-user

<None>

Realization of strategic objectives

<None>

Satisfaction of other stakeholders

Resp002 This is something we want to take into account. However, it does happen quite a lot that we are not allowed to talk with suppliers or other stakeholders to the company. In order to answer to the stakeholder question we try to work with industry standards that we throughout years enhance.

Resp003 Never.

Most important Resp001 Whether we agree with a client to afterwards do their maintenance and support. Resp003 Whether we agree with a client to afterwards do their maintenance and support.

Because we have a special after-implementation-support center§, we almost always get their maintenance-activities, and this is one our big differentiators.

Resp005 This is a difficult question. This phase you are mainly working to correct mistakes and errors. The most important matters at that time are those urgent ones.

Other Resp001 There is a big force field between the amounts of work you beforehand tender and the actual, more realistic workload. Furthermore what we perceive as an important factor is whether a client is self-reliant. Whether these is much work to be taken care of after the GO LIVE. And than there is the difference between soft and hard success criteria. There is a difference between the software you delivered and the emotion you feel after carrying out the project.

Resp002 Whether after a project the telephone keeps ringing as a matter of course. It is about the way to leave (or don't) each other after such an implementation. It is about the chemistry between the two parties.

Resp004 Not able to comment as I am always gone to moment the assessment starts.

Resp005 Another criteria are whether the implementation has given the client-firm a reasonable amount of improvement. In my opinion it is not per sé about what the customer expects me to deliver, as I use my own intuition to assess whether the improvements we have implemented were reasonable.

61

8.6 Appendix 6

Month Interview Type Interviewee Duration Location

1 April ‘15 One-to-one (rec’d) Resp001 50 Office canteen

2 May ‘15 One-to-one (rec’d) Resp002 50 Office canteen

3 May ‘15 One-to-one (rec’d) Resp003 60 Home kitchen

4 May ‘15 One-to-one (rec’d) Resp004 50 Business center

5 May ‘15 One-to-one (rec’d) Resp005 50 Office canteen

6 June ‘15 One-to-one (rec’d) Resp006 50 Office canteen

Table 15: Interviewee details

8.7 Appendix 7

Interview Protocol Thesis: “ERP Implementations, the Role of External Consultants”. Institutions: _____________________________________________________ Interviewee: ____________________________________________________ Interviewer: ____________________________________________________ Topics Discussed:________________________________________________ Documents Obtained:_____________________________________________ Post Interview Comments or Leads: _________________________________ Teaching, Learning, and Assessment Interviews Introductory Protocol To facilitate our note taking, we would like to audio tape our conversations today. Please sign the release form. For your information, only researchers on the project will be privy to the tapes, which will be eventually destroyed after they are transcribed. In addition, you must sign a form devised to meet our human subject requirements. Essentially, this document states that: (1) all information will be held confidential, (2) your participation is voluntary and you may stop at any time if you feel uncomfortable, and (3) we do not intend to inflict any harm. Thank you for your agreeing to participate. We have planned this interview to last no longer than one hour. During this time, we have several questions that we would like to cover. If time begins to run short, it may be necessary to interrupt you in order to push ahead and complete this line of questioning. Introduction You have been selected to speak with us today because you have been identified as someone who has a great deal to share about advisory and consulting practices within ERP implementations. Our research project as a whole focuses on the improvement of

62

implementation and applications of ERP systems, with particular interest in understanding how consultancy practices contribute to successful projects. Our study does not aim to evaluate your techniques or experiences. Rather, we are trying to learn more about ERP system implementation projects, and hopefully learn about practices that help improve the until now high ERP failure rate.

A. Interviewee Background How long have you been in your present position? Interesting background information on interviewee: What is your highest degree? What is your field of study? The model presented here below is the core of my research.

1. How have you got involved with ERP advisory? Consultation roles

• Business analyst • Project manager • System architect • Technology consultant

2. Within a consultant-client relationship, a consultant can take on different roles. We

have identified 4 roles. 3. Do you recognize all of the mentioned roles and how do you think each role

Consultation!modes!

Competence!of!consultant!

Clients’!characteristics!

ERP!

implement>tation!!success!

63

contributes to a successful ERP project. 4. What of the above-discussed roles do you thinks adds most value to the

implementation project? 5. What is your typical role within an implementation project? 6. How would you accord that role with the mentioned roles?

Competence of consultants

• Consultants’ technical skills • Consultants’ level of experience • Consultants’ communication skills • Consultants’ understanding, sense and adjustability

7. We have identified four important client characteristics that affect the success of a

project. 8. Within a consultants-client relationship, you agreed that certain consultant skills

indeed contribute to the success of an implementation process. a. What skills would you consider as most important? b. Among these skills, which one you think are most important? c. Why are they most important d. Moreover, why and how do you think this skill contributes to project

success? 9. Which specific characteristic do you believe you make a difference with? 10. How do those characteristics add to project? Please be as concrete and specific as

possible. You might want to explain using examples. 11. What is so unique and characteristic about this competence?

Clients’ characteristics

• Clients trustfulness • Client’s absorptive capacity • Understanding of a consultants • Intrinsic motivation of the recipient

12. We have identified four characteristics of the client organization that contribute to

project success. Do you recognize and agree with these? 13. Could you please briefly describe how those 4 contribute? Please be as concrete and

specific as possible. You might want to explain using examples. 14. In what way are the four characteristics interdependent cq. Appear without the other. 15. Do you focus on adjusting the clients’ characteristics in order to be more likely reach

success? ERP implementation success

16. How do you measure success? 17. When do you measure success?

64

18. Is the stakeholder involved in assessing the projects’ success? 19. Do you make a distinction between long-term and short-term success? And further

so: long-term and short-term clients? What are the main take always? I want to thank you very much for your time.

8.8 Appendix 8

Herewith are all interviews transcribed ad verbatim: Transcript interviewee 1 NA: Interviewer MH: Interviewee (Interview is in Dutch) NA: : Ik heb hier voor u het model dat ik heb aangenomen vanuit de literatuur. Om te beginnen de rollen:

" de business analist " de project manager " systeem architech " technology consultant (programmeur)

MH: Wij maken onderscheid tussen een lead-consultant die meer dan alleen zijn eigen

proces beheert. Je hebt verschillende specialisaties binnen erp systemen, finance, manufacturing, omdat het toch allemaal best breed is en een lead consultant is iemand die over het geheel kan kijken. Dus je hebt functionele consultants die dus alleen voor hun eigen specialisatie werken. De lead consultants zorgt ervoor dat de verschillende divisies met elkaar kunnen blijven communiceren. System architech is typisch een term die in de Dymanics AX wereld een hot titel aan het worden is. Iedereen wil de system architecht zijn want dat verdient het meest. Het is degene die bepaald voor welk vraagstuk, we welk deel van Microsoft software we gaan inzetten. Welk stukje zetten we voor welk bedrijfsproces in? Ze hebben namelijk een heel palet aan software en zij kiezen welke software er gekozen gaat worden. Een business analysis binnen XXX praat op directie niveau.

NA: Welke van de rollen zoals u die net beschrijft dragen het meeste bij aan het

uiteindelijke succes van een ERP project? MH: Allemaal. Het moet een team zijn. Het liefst heb ik mensen die cross-functional

kunnen functioneren. Wanneer mensen perfect in hun rol blijven, is het een slecht team. Je kan het beste mensen hebben die heel duidelijk een basis rol hebben, maar

65

daarnaast ook een eind komen binnen een andere rol. Dat kan binnen deze vier functies zijn, maar dat kan natuurlijk ook binnen de verschillende divisies cross-functional zijn: finance en distributie. Een pure finance consultant kan tot op het autistische aan toe blijven roepen dat hij een systeem op een bepaalde manier wilt hebben, maar als hij juist mee kan kijken in die processen begrijpt hij ook waarom zijn wil misschien niet kan.

NA: een zo breed mogelijke oriëntatie dus? MH: in die zin, wel een basis. En voor en technologie consultant geldt natuurlijk dat die

helemaal in hun materie moeten zitten. Maar wel met affiniteit voor andere aspecten en kleuren van het palet. Ik het er nog nooit een gevonden die alles kan. Maar er moet heel duidelijk wel een mutual understanding zijn vanuit waar men kan communiceren met elkaar.

NA: Wat is jou rol binnen een ERP implementatie? MH: Ik ben de manager van de ERP implementaties. Ik lever de mensen voor

verschillende projecten. Verder moet ik ervoor zorgen dat het team goed samenwerkt.

MH: Het is wel heel duidelijk dat we op zoek gaan naar een team dat elkaar aanvult. Ik

heb verder ook alle rollen die we zojuist besproken hebben, gedaan. En wat ik ook altijd heel sterk opmerk is dat het ook heel erg van belang is dat je de business goed kent. Je dient specifiek de business te kennen. Het is niet zozeer de software die het verschil maakt. Echter het gaat op de specifieke toepassing waarin de organisatie het zal gaan gebruiken. Als voorbeeld: ik die nu een project in Zweden waarin ik adviseer in wat voor software en adviesbureau ze erbij moeten kiezen. Daar zijn momenteel nog twee partijen in de runnen. Wij implementeren dezelfde software die daar nog in de running is, alleen omdat wij geen enkele kennis hebben van die markt is het voor ons totaal onmogelijk om deze klus binnen te halen. Die mensen spreken als het ware dezelfde taal. Ze spreken, zoals is dat graag noem, de vocabulaire van de markt.

NA: Dat is interessant want dat leidt mij tot mijn volgende variabele. Namelijk de

karakteristieken en vaardigheden die consultants dienen te hebben en welke het beste invloed hebben op ERP project succes. Daarbij heb ik de volgende variabele geïdentificeerd.

MH: Ja ik herken heel veel van deze variabele als in eerste instantie positieve variabele.

En wat betreft die rollen, consultants zijn de mensen die als eerste de ‘scope creep’ ervaren. Wat is de scope van wat wij uiteindelijk aanbieden. De mensen die in eerste instantie afspreken wat het project en de rol van de consultant allemaal omhelst zullen niet de mensen zijn die uiteindelijk het systeem moet en zullen gaan gebruiken. Vervolgens gaat het project over naar de project leider en die gaan het uitvoeren met de consultants. Degene die bezig zijn met het project gaan afspreken met de afdelingshoofden en dergelijke waardoor vooral hun eigen ideeën in het project te stoppen. Ideeën die in eerste instantie helemaal niet binnen de scope vielen. Ervaring van een consultant kan bijdrage aan het managen van verwachtingen en dat jij als externe niet zomaar belofte mag gaan doen.

NA: Ik begrijp dat de consultant bewust moet zijn van het feit dat hij niet zomaar

toezeggingen over de scope van het project mag doen.

66

MH: Wat betreft communicatievaardigheden zeg ik vaak tegen jonge consultants dat ze denken dat hun technische vaardigheden het meest belangrijk zijn. Dat is helemaal niet zo. 80% van de tijd ben je mensen aan het begeleiden. Sociaalpedagogisch werker. Verandermanager. Het is namelijk meer dat alleen een nieuw software pakket, het is een verandering van hoe de processen in zijn werk gaan.

MH: De vier genoemde karakteristieken die je daar genoemd hebt vallen eigenlijk

allemaal samen met elkaar. NA: Begrijp ik dan goed dat eigenlijk de eerste twee eigenschappen makkelijker aan te

leren zijn dan de laatste twee? MH: . Nou de kunst is als ik iemand aan neem om natuurlijk te zoeken naar mensen die

het kunnen. Ik heb er nu een rondlopen en die is ideaal. Die doet t allemaal goed. Maar hoeveel heb ik er aangenomen die niet goed waren, althans die niet op alle vlakken zo excelleren als hij. Zowel technisch heel vaardig. Het is een bedrijfskundige. Hij heeft heel veel technische vaardigheden ook met programmeren als het moet. Hij kan in data denken. Maar hij heeft ook een bepaalde dienstbaarheid naar de klant. Dat weet hij dan wel weer zo te doen dat hij met een vriendelijk gezicht kan vertellen dat we dat niet gaan doen want dat hoort niet bij de opdracht. Tot slot is een sterke eigenschap van hem dat hij altijd vanuit de klants’ perspectief zaken bekijkt. Dat moet je wel kunnen. Sommige zijn wel eens arrogant, maar die denken direct dat ze de wijsheid in pacht hebben. Je moet wel een luisterend oor hebben

NA: Begrijp ik dan ook dat technische vaardigheden in veel mindere mate belangrijk zijn

omdat ze in een werkverband altijd nog wel aan te leren zijn, en dat het vooral de moeilijk aan te leren karaktereigenschappen als communicatieve en gevoelsmatige eigenschappen zijn die belangrijk zijn.

MH: Nou dit kan je zo stellen. Echter je gaat je consultants ook benutten naar hun

inzetbaarheid en hun sterke punten, begrijp je. Als ik een acuut probleem heb stuur is andere mannen dat op het moment dat ik een langzame klus heb neem ik de meer gesloten en slimmere programmeurs. Kortom afwisseling en een flexibele inzetbaarheid houdt je werkforce.

NA: Dit brengt mij bij de volgende variabele en dat is de mate waarin en hoe dan, het

samenspel tussen de klant en de consultant bepalend is voor de mate van succes. MH: Als ik kijk naar de meest succesvolle projecten die ik zelf als consultant of

projectleider heb gedaan hangt dat eigenlijk altijd af van de klant. Kijk consultants zullen altijd wel hun best doen maar als er aan de andere kant niemand zit die dit oppakt en opneemt, dan zal er niets gebeuren. Als je aan de andere kant mensen hebt zitten die het ten eerste leuk vinden, en ten tweede die de tijd krijgen van de organisatie om zich te verdiepen en het nieuwe systeem eigen te maken en dus eigenlijk zelf bijna consultant zouden kunnen zijn wellicht. Kijk het werkt een beetje zo dat je als klant-werknemer op een gegeven moment in een dergelijke implementatie rolt, je op pad gaat naar andere bedrijven, je komt nog eens ergens, want je gaat bedrijven afreizen. Alle vestigingen van je bedrijf, je werkt hard en soms wat minder. Dat is allemaal verslavend, en dan is de vraag, trek je nog terug naar je normale patroon.

MH: Ik zit dan nu ook bij dat bedrijf in Barendrecht en die heb ik op voorhand heel

duidelijk verteld: het project zal pas kans van slagen hebben als jullie achter jullie mensen blijven staan. Het succes hangt op staat bij dat je duidelijk zijn van wat je

67

van ze verwacht en wat de doelstellingen zijn, en vervolgens moet je ze dus ook het mandaat geven om besluiten te nemen s de directie die we met elkaar hebben afgeschrikt. Mits je de mensen het mandaat geeft, de ruimte geeft, ook om fouten te maken, want je moet wel leren, zal het succes van een dergelijk project aanzienlijk toenemen. Je wilt als consultant niet telkens over 4 schijven doorverbonden te willen worden alvorens een beslissing mag doorgevoerd worden.

Interesse is daarnaast ook een hele belangrijke eigenschap van een klant, of hij het

project leuk vind of niet zeg maar. Alleen het probleem is dat ik als externe deze persoon niet voor het uitkiezen heb. Ik heb wel geleerd dat ik niet zomaar mensen moet accepteren. Aan de klant-kant zeg maar. Wij zeggen tegenwoordig ook gewoon tegen de klant als er op het project een totale prutser zit te werken, dat hij moet worden ingewisseld want anders gaat het gewoon echt niet werken. Dit doen wij want als het project achteraf niet slaagt is dat altijd onze schuld, altijd. Maar wij durven die dat niet altijd maar te zeggen tegen de klant, sterker nog want het wordt bijna nooit gezegd.

NA: Inderdaad, ik heb vaker gehoord dat mensen gewoon geen tijd hebben om hun

normale, day-to-day activiteiten te combineren met werkzaamheden die gepaard gaan met een implementatie. Daar wordt nog wel eens iemand speciaal helemaal voor vrij gemaakt correct?

MH: Hier ligt dus een krachten veld. Namelijk ga jij aan je klanten vertellen dat als je

mijn product neemt, waarvoor ik vijfhonderd dagen moet besteden, jij daar minstens vijftienhonderd dagen voor moet vrijhouden, want zo ligt het wel. Dat is namelijk gewoon heel eerlijk wat de verhoudingen zijn. En we hebben daar dus gezien dat daar door andere consultants vijfhonderd tot duizend uren worden inbegroot. En vooral degene die zegt vijfhonderd uren, dat is gewoon volkomen irreëel. En degene die het hoogste aantal uren begroot, en dus het duurst is, zit waarschijnlijk het dichts bij de realiteit.

MH: De eisen die wij als consultant aan de klant stellen gaan nog wel verder.

Bijvoorbeeld bij een implementatie van MS A/X, hiervoor moeten bedrijven bij ons minimaal een eigen IT software organisatie hebben. Waarom?: dat is een buffer naar ons toe. Dat betekent dat je een bepaalde volwassenheid hebt. Intergamma is een klant van ons en dat is zalig om mee te werken. Die hebben een bepaalde omvang waar ze gewent zijn dat dingen moeite kosten. Als ik daarentegen geen geld voor een eigen IT afdeling. Dat snap ik ook wel. Maar een A/X implementatie werkt daarom daar ook niet. Ik heb bijna met die bedrijven te doen alleen zijn de pakketten gewoon te groot.

NA: Begrijp ik dan ook dan de bedrijven die een eigen IT afdeling per saldo minder tijd

besteden aan een EPR implementatie dan bedrijven zonder. MH: Ze zijn minder afhankelijk van ons. Ze kunnen heel veel zelf. Eigenlijk is dat het

beste wat je als consultant kan bereiken om na twee weken de deur achter je dicht te trekken en een goed service contract af te sluiten. Kijk je moet samen willen werken. Zodra je een wij en zij krijgt gaan projecten nooit goed. Daarnaast is het ook heel erg belangrijk, he nogmaals dat alles aan informatie, doelstellingen en wensen wordt overgedragen aan de consultant. Hierbij is het van uitermate groot belang dat alles en alle informatie omtrent de markt wordt verteld aan de consultant zodat er niet laat in een traject nog iets volledig hoeft te worden aangepast. Daarom als je werkt met mensen die de business kennen, is die kans veel kleiner dat er iets elementairs over het hoofd wordt gezien.

68

MH: Om deze samenspraak en de bereiken, en om begrip van de situatie te creëren organiseren wij, als klant ook wel eens een dag dat onze software leveranciers komen kijken om te zien of ze de handel begrijpen en of ze zo een inschattingen kunnen maken of ze de klus überhaupt aankan.

NA: Duidelijk. Vervolgens komen we uit de bij evaluatie. Hoe definieert u succes? En

hoe doen jullie dat? MH: Succes voor mij is een relatief rimpelloze GO-LIVE ten eerste, en ten tweede dat de

klant jou als referentie ziet is een zeer goede meeting van succes. In verdere mate dat een klant con-collega’s naar jou doorverwijst. En misschien gebeurt dat wel meer niet dan dat dat wel gebeurt. Toevallig moet ik volgende week naar een klant toe die naar ons is toegewezen.

NA: En zijn er ook meer harde succescriteria? MH: Ja, die zijn echter voornamelijk voor een klant relevant. Ik ben daar zelf niet zo van

gecharmeerd maar inderdaad geld en tijd. Er kan een bepaalde druk zijn om LIVE te gaan. Budgetten vindt ik belangrijk. Ik hou zelf maar van marges. Wat ik altijd zeg, maar is minder goed te meten, in hoeverre de klant zelf zijn broek in de lucht kan houden. Heeft hij na de GO LIVE nog begeleiding nodig de ja of de nee. Dat vind ik ook heel belangrijk. Dat is misschien op korte termijn, zakelijk gezien niet zo. Want als hij nog veel begeleiding en ondersteuning nodig heeft zal hij vaker bij je terug komen waardoor je uren kunt schrijven. Echter op de lange termijn zal hij naar een concurrent gaan voor zijn business.

NA: Nu spreken we eigenlijk alleen de situatie tot een GO LIVE. Zijn daarna ook nog

meetmomenten? MH: Een klant moet na dat ze met ons LIVE zijn gegaan met ons een service contract

willen afsluiten. Waarin we bepaalde dingen met elkaar overeenkomen. Wij garanderen service tot neger uur s avonds. Of veel uitgebreidere contracten waarin wij delen van jouw applicatiebeheer mogen uitvoeren.

NA: In zekere mate is dit ook zeker een criteria voor succes? MH: Dat is weldegelijk waar. Als en klant geen service contract met ons wil afsluiten

hebben wij blijkbaar geen goed werk geleverd. NA: En in hoeverre is een klant überhaupt in de mogelijkheid om na een implementatie

nog voor een andere service provider te kiezen gelet op de hoeveelheid maatwerk dat jullie hebben geleverd voor de initiële implementatie?

MH: Je zit op een bepaald moment toch gebonden aan een vendor-lockin. Veel vendors

hebben op deze standaard ERP pakketten een eigen gemaakt laagje waardoor dit pakket fantastisch wordt voor jou business. Dat is dan een vendor lockin. Daarnaast als je veel maatwerk hebt gekregen zit je inderdaad al snel met een vendor lockin waardoor je niet naar een andere software partner kan.

MH: Over maatwerk gesproken daar geloof ik zelf helemaal niet in. Dit maakt je systeem

alleen maar log en moeilijk te updaten. En in het verleden is heel veel maatwerk geleverd. Dit komt door een aantal redenen. Een omdat de consultant niet creatief genoeg was om de processen zo aan te passen dat de applicatie maar aagepast diende te worden. Dat is dan jammer. Maar het belangrijkste is dat maatwerk zorgt ervoor

69

dat je niet meer mee kunt updaten. En daarnaast heb je als consultant niet kunnen afraden om software in zulke hoge mate te personaliseren.

NA: Is dit niet juist het krachtenveld waarin een consultant/klant leven? MH: Ja. Inderdaad dat is ook wel zo. Maar in hoeverre is dat niet naïef van de klant? Bij

alle dingen die je doet in het leven, als je echt met maatwerk aan de gang gaat wordt het gewoon duur. Maar iedereen begrijpt dat de tijd exponentieel toeneemt om een dergelijke systeem toe te passen op een bedrijfssituatie.

NA: Begrijp ik dan ook goed dat jullie streven naar zo min mogelijk maatwerk. MH: Ja. Dat klopt. Hoe moeilijk het ook is om daar je geldt te verdienen. Je moet

namelijk met een vrij sobere boodschap naar een potentiele klant toestappen. Namelijk: hou je systeem zo somber en kaal en gestandaardiseerd mogelijk om zo achteraf moeilijkheden en legacy problemen te voorkomen. Op de vraag van een klant in hoeverre we ‘dit’, ‘dit’ en ‘dit’ kunnen veranderen, kunnen we allemaal ja zeggen. Echter wordt de implementatie en het systeem op die manier onbetaalbaar. Is het verstandig om te doen; nee. En daar komt bij dat een directie nog wel zo streng en sober mogelijk een ERP pakket wil implementeren, maar vervolgens zie je die directie nooit meer omdat ze zich er nooit meer mee bemoeien. En dan kom je bij de afdelingsbaasjes en die willen dan weer voornamelijk hun eigen belang dienen. Het is vooral op het lagere niveau waar er wordt besloten om toch maatwerk te implementeren. Onder het mom van “doe maar, het moet wel goed werken”.

NA: Wanneer komt er een succes-meetmoment? MH: Dat is twee maanden na de GO LIVE. Dat is ook een heel formeel moment. Dan

kom je bij de stuurgroep bij elkaar en worden er handtekeningen gezet en ben je als het ware van elkaar af.

NA: Is het dan niet heel vaak een discrepantie tussen wat er reeds op tafel ligt en tussen

wat er al daadwerkelijk is geleverd? MH: Nou er is een verschil tussen wat ik ben beloofd je te leveren en wat je krijgt dus en

aan de andere kant wat jij dacht dat je ermee ging doen. Als jij denk dat je omzet keer twee zou gaan, daar heb ik geen boodschap aan. Ik verkoop de tool, en dan vertel je hoe die tool eruit ziet.

NA: Er is dus weldegelijk een verschil tussen harde en zachte criteria MH: Nou er bestaat wel een verschil tussen wat ik zeg dat je met je software allemaal kunt

doen. Bijvoorbeeld een huidig project wil na zijn implementatie met tien procent minder personeel gaan doen. Dat staat natuurlijk nergens maar het zou wel kunnen lukken.

NA: Ik denk dat het allemaal veel informatie was, maar voor nu ga ik eerst het interview

uitwerken. Ik wil u bedanken voor uw tijd. MH: Dankjewel, geen probleem.

70

Transcript interviewee 2 NA: Interviewer HV: Interviewee (Interview is in Dutch) NA: Mijn scriptie gaat over de rollen van externe consultants, en hoe deze bijdrage aan

het succes van een ERP implementatie project. Ik heb hiervoor een model, vanuit de literatuur onderbouwt, gemaakt die ik aan de hand van interviews in meer detail de werking van wil uitzoeken.

In dit model heb ik gekeken naar ten eerste rollen; ten tweede naar de vaardigheden

die een consultant dient te bezitten alvorens een succesvolle implementatie gerealiseerd kan worden, en tot slot heb ik gekeken naar het tussenspel tussen consultants en klantorganisaties. Alle drie deze variabele leidde zoals hier te zien tot consultancy succes en ik ben op zoek naar de vraag hoe deze variabele leiden tot zulks succes.

HV: Dat is goed. Je kunt me alles vragen, ik zal daarentegen wellicht niet overal een

antwoord op hebben maar ga gerust je gang. NA: Ok. Om te beginnen heb ik vier verschillende dimensies/rollen onderscheidde

waarbinnen ik heb gesteld dat een business analist de project leider is. HV: Nee. Als het goed is is een business analist nooit een project leider. Een business

analist gaat modeleren en achterhalen hoe de werkprocessen van een klantorganisatie eruit zien. In andere woorden is hij in ondubbelzinnige termen aan het uitschrijven wat een klant nodig heeft om effectief op de markt te opereren. Dat is wat een business analist doet. Een project leider daarentegen is in beginsel iemand die het organogram doet, dagelijks management van het team doet wat is het project zit. Of dit nu klantwedewerkers of consultants zijn, of een mix daarvan, is daarin eigenlijk om het even. Die heeft dus een hele andere doelstelling. Een projectleider gaat om een heel belangrijk deel ook om de relatie te beheren, de tijdlijn te bewaken maar stiekem toch ook om de kosten te bewaken. “Ben je wel met de goede dingen bezig?”. Maar gaat daarom doorgaans niet over de inhoud. Ik vind dat je dat onderscheid wel heel duidelijk moet maken. Er zijn wel mensen die dit werk verenigen, dus dan heb je een analist die ook project leider is. Maar het zijn wel twee verschillende petten die men dan op heeft. Daarom moet je ook wel dit onderscheid maken.

NA: [Begrijp ik goed dat de project leider dus in mindere mate ook technische kennis

dient te hebben.] HV: Ja, correct. Het helpt wel, maar het is geen noodzaak. NA: Daarnaast heb ik de systeem architect als rol geïdentificeerd. Dit is een soort

programmeur eigenlijk. HV: Nee, nee. NA: Nee? Herken je de termen wel. HV: Ja ik herken de termen wel alleen het moment dat je er invulling aan geeft denk ik:

“Nee dit is niet het zelfde”. Kijk een architect is iemand die de kaart tekent.

71

Hetzelfde is dat met een gebouw. De architect ontwerpt het geheel. Die zorgt ervoor dat de consistentie compleet is, dat alle functionaliteiten benoemd zijn, door bijvoorbeeld door de analist, dat die een plek hebben gekregen op een logische plek, dat heb je het meer over ketens en hiërarchieën. Wat een architect niet doet is zelf de troffel ter handen nemen. Wat hij dus niet gaat doen is zelf bouwen. Dan moet je nog een onderscheid maken dat ERP doorgaans gaat over grootte delen vooraf gedefinieerde procesketen. Dat betekend dat een systeem architect met ERP termen, rekening moet houden met de standaard functionaliteit van de applicaties. Daar waar een klassieke systeem architect zegt: “Vertel me je droom en ik maak het voor je”, is wat ik zie als een applicatiearchitect is iemand die zegt: “vertel me je dromen, en ik ga je vertellen waarom je het op een hele andere manier gaat krijgen. Wat je nodig hebt, en waarom je het nodig hebt. Ik ga je vertellen hoe je dit gaat krijgen”. Dat is een hele andere invalshoek. Daarin onderscheid ik dus twee soorten aanpakken: een “solution driven approach en een requirement driven approach”. Een requirement driven approach is van wat heb je nodig en ik ga het voor je bouwen. Dat is wat een systeem architecht vaak doet. Dan heb je een solution driven approach die veel meer uitgaat van: “Dit is het pakket, dit zijn daarbij de bedrijfsfunctionaliteiten die daarbij worden ondersteund. En als je het zo gaat gebruiken vertel me dan ook waar het niet gaat passen want dan gaan we vervolgens kijken hoe het wel gaat passen. Dat laten passen zit dus op twee assen. Enerzijds het aanpassen van het bedrijfsproces en anderzijds aan het aanpassen van het systeem. Beide brengen kosten aspecten met zich mee. Dat is wat een solution architect dus doen.

NA: Ok. Heel duidelijk dus een taak die hij vooraf doet. HV: Absoluut. NA: Klopt het dat in steeds meerdere maten een solution driven approach wordt

gehanteerd? HV: Dat hangt hel erg af van de plaats waar het systeem zijn intrede zal maken maar over

zijn algemeen is dat afsloot een trend. Ik werk nu negentien jaar bij XXX en toen ik destijds begon was alles in het begin maatwerk. Ja er waren wel pakketten maar die werden vaak gezien, vanwege de beperkte rijkheid in die oplossing, wat als een voornamelijk deel als een bodemplaat voor maatwerk wordt gezien. 40% van alle punitiviteit moet je zelf bouwen was destijds de gedachte. Dat is door de jaren heen wel veranderd. Nu zie je dat 90% van de functionaliteit standaard is en kijk je of en hoe je dit dan gaan aanvullen. Het hangt ook af van welk deel in het bedrijfsproces je zit te werken. Bij een primair proces, dus dat waar je jezelf echt onderscheid van je concurrent, waar je dus het geld mee verdient, daar zijn de requirements dus heeft belangrijk voor. Als je kijkt naar het secundaire proces, bijvoorbeeld zoals boekhouden, kijk er zijn maar weinig mensen die echt hun geld verdienen met boekhouden. Dat zorgt wel voor het verschil. Je ziet tijdens grotere implementaties meerdere dimensies ontstaat waarbij dus verschillende oplossingen naast elkaar ziet, waar het secundaire proces, bijvoorbeeld het boekhoudkundige, wordt afgedekt. En het primaire proces iets met een hoge mate van configuratie of zelfs maatwerk. En dan heb je de solution architect die beide moet afdekken. En dan heb je een applicatie architect die op de standaard applicatie zit. En een systeem architect als je m zo wilt noemen die gaat over het systeem. Dan heb je daarnaast nog eens een infra architect die zorgt dat alles met elkaar blijft praten.

NA: Technisch gesproken? HV: Ja technische gesproken. Want als de infrastructuur het niet doet, doet niets het.

72

NA: In hoeverre worden deze rollen door een fysiek persoon verenigd? HV: Het word wel een verenigd in dezelfde persoon maar dat is absoluut geen gegeven.

Het zijn namelijk ook gewoon verschillende disciplines. Het vergt een andere manier van de wereld bekijken. Wat je wel ziet is dat mensen vaak beginnen bij een van de twee delen. Dus solution-, of recuirement driven, en dan vervolgens vanuit daar doorgroeien, of naar boven of naar beneden.

NA: Welke rol, of welke persoon draagt in jou ogen het meeste bij aan een succesvol

implementatie project. HV: De klant. NA: Ok. En afgezien van de klant? HV: Dat kan ik niet zeggen. De een kan niet zonder de ander. Je hebt ze alle vier nodig.

Als je deze vier als voorbeeld neemt dan. Ik kan niet zeggen dat. Noem maar eens een voorbeeld. Als de infrastructuur het niet doet, doet niets het. Als de recruirements-analyse niet goed is, wat ga je dan neerzetten. Dan heb je een oplossing die niet past bij de behoefte. Als de architectuur niet klopt, de volgorde of logische samenhang is er niet, nou dan werkt het ook niet. Je kan slecht beginnen met een dak beginnen zonder dat er muren staan. De architectuur moet ook kloppen. De een kan niet zonder de ander. Los van het feit of ik het eens ben met het lijstje.

NA: Hoe zou jij het lijstje invullen? HV: Als je het hebt over ERP implementaties zit je inderdaad wel met een business

analyst. Project manager snap ik ook nog wel. Systeem architect zou ik als solution architect zien. Want die til je dan een iets groter veld in dan alleen maar het systeem. Want je moet hem zien in de brede context, in samenspraak met klenten. Dan heb je ook nog een technology consultant. Ja wat is dat?

NA: Ja… een programmeur. HV: Ja maar in ERP, wat ik probeer te vertellen, programmeer je in beginsel helemaal

niet. Je configureerd vooral veel, want je werkt vanuit het standaard pakket. En dan moet je gewoon heel goed snappen wat de mogelijkheden zijn van het pakket. Hoe de bedrijfsprocessen dienen te worden ondersteunt met het pakket. En hoe je met configuraties en het aanpassen daarvan om moet gaan. En vanuit daar tot een optimale ondersteuning over te gaan. Dan heb je het dus ook echt over hele tool-speciafieke kennis.

HV: Je hebt dus geen programmeur meer. Deze komt alleen in beeld als het echt niet

anders kan en er maatwerk nodig is. En er is altijd maatwerk nodig. En de kunst is, die ligt dus bij de rollen oals je die nu hebt benoemt. De kunst van die vier rollen is eigenlijk om het maatwerk te minimaliseren. Want dan heb je de optimale ondersteuning van het bedrijfsproces met het optimale gebruik van de mogelijkheden van het standaard pakket.

NA: Waarbij achteraf wellicht ook minder hulp voor support of upgading hoeft

ingeschakeld te worden bij jullie? HV: Nou, wij doen het natuurlijk allemaal. Wij doen die hele stapel. Maar als je een

oplossing neerzet, die moet ook beheerd worden. En een heel groot deel van de kosten zitten in het project, maar er zitten nog veel meer kosten in het beheer en alles

73

wat er achteraan komt. En alles wat je met het standaard pakket kunt afdekken wordt ook een in beginsel ook door standaard software updates onderhouden. Dus je kunt jaren door met updates rondom veiligheid en nieuwe toepassingen vanuit de leverancier. Maar maatwerk kan dat niet. Dat betekend dus elke kaar dat als ik een update krijg op hetzelfde pakket, dat maatwerk groeit niet meer. Dus daar moet ik wat mee: onderhouden. Dat kost dus allemaal weer tijd en dus kosten. Het is daarom van belang dat de klant een optimale balans kan vinden tussen standaard configuraties en maatwerk ook met het oog op het beheer van de oplossing.

Ik zie graag dat een klant tevreden is met het geheel. Niet alleen nu, maar ook over

tien jaar. Want dat is wel de life-span van heel veel applicaties. NA: OK. Duidelijk. Vervolgens wil ik het graag hebben over de vaardigheden van de

consultants. Daar vanuit heb ik de vier belangrijkste karakteristieken onderscheiden. Die heb ik op deze manier geëxtraheerd als belangrijk. Daarbij hebben we het over de mate van ervaring van een consultant; de mate van technische vaardigheden van een consultant; in hoeverre kan hij zijn kennis overbrengen; spreek hij dezelfde taal als de klant-organisatie.

HV: Ik mis er eentje. Dat is bedrijfsproceskennis. Die zou ik hier grag willen terugzien als

vijfde punt. Waarom begin ik ermee. Wat je ziet is dat heel veel organisaties hebben een bedrijfsproces vraag, bijvoorbeeld boekhouden. Als je dan vervolgens niet weet wat boekhouden is, hoe ga je een klant dan helpen met het verbeteren van deze processen. Hoe snap je wat de klant nou werkelijk nodig heeft. Hoe stel je nou net even die vraag, waarin je begrijpt op welke manier de klant de informatie die ze vraag ook daadwerkelijk gebruiken gaat. Dan kan je namelijk met suggesties en alternatieven komen. Dan kan je ook voorgaan stellen hoe hij zijn bedrijfsprocessen gaat aanpassen om optimaal nut te halen uit het pakket. Terwijl zijn bedrijfsproces doelstellingen wel gehaald worden. Dan moet je wel snappen wat die doelstellingen dan betekenen.

NA: Begrijp ik dan goed dat we het hier hebben over business specifieke kennis is.

Bijvoorbeeld voor een bepaalde tak van handel zoals staal oid? HV: Dat kan. Dan komen we weer terug op van waar gaat ERP je ondersteunen. Heel

zwart-wit gezegd, boekhouden is boekhouden. Eigenlijk branche onafhankelijk. Maar bij staal bijvoorbeeld moet je je afvragen of een standaard ERP implementatie wel bruikbaar is. Bij staal, is dat zo specifiek dat een algemene oplossing waarschijnlijk niet de specifieke onderdelen van de branche zullen ondersteunen. Dan helpt het dus als je het snapt. Als je in logistieke organisaties zit, dan helpt het absoluut als je snapt wat de consequenties zijn van logistieke processen, omdat optimaal te kunnen ondersteunen. Er is een moment dat je niet meer vanuit de ERP pakket, om het daar even op te plotten, kunt redden. Dan krijg je een switch, gedreven vanuit de business analisten rol die jij net hebt benoemd, waarbij dus van een pakketspecialist met business analist pet, een omslag gaat krijgen naar een business analist die specifiek is voor die branche maar wel snapt wat het pakket betekent. En daar ligt ergens een omslagpunt.

Het begrip van wat de klant moet bereiken, en wat het betekend voor een klant

organisatie vind ik een essentiële eigenschap om consultancy te bedrijven. Dat maakt het verschil tussen ben je nou een ‘toolie’, een metselaar die maar gewoon doet wat hem gezegd wordt. Leg die steen daar neer, niet vragen waarom, dat snap je toch niet. Tot en met, beste consultant ik heb een muur nodig, hoe gaan we die bouwen? Dat is een hele andere vraag.

74

Ik denk dat als je een groot complex project heb, dat je t allebei nodig hebt. Ik denk, als ik kijk naar het overige lijstje. Technical skills, dus programmeren is in een pakket implementatie eigenlijk niet aan de orde. Bij een ERP implemetatie wil je in beginsel niet programmeren. Want als het goed is, en je hebt je pakket selectie goed gedaan heb je 99% van alle functies komt uit je standaard pakket: dan wil je niet programmeren. Ik zie het als mijn meest nobele streven om het programmeren tot het absolute minimum te beperken. En toch de bedrijfsprocessen goed te ondersteunen. Niet programmeren, maar wel productkennis/tool-specifieke kennis gebruiken. Als je kijkt naar Oracle, snap je dan wat de mogelijkheden van het pakket, wat een vinkje op punt a betekend, en wat een vinkje op punt b betekend. Je moet kunnen uitleggen wat de consequenties zijn van ‘een vinkje’. En dat zou ik dan als technical skills omschrijven, in feiten.

NA: Draagt ervaring ook bij aan een succesvolle implementatie? HV: Als ik naar mezelf kijk, ik werk inmiddels al twintig jaar bij XXX waarvan de

afgelopen vijftien jaar binnen Oracle EBS. Het feit dat ik toch de nodige klanten, organisaties, fouten, successen heb gezien, veel mensen heb gesproken en de kennis die ik heb meegenomen van de ene klanten organisatie naar de andere klanten organisatie. Daarbij heb ik zeven jaar in het buitenland gewerkt. Ik snap nu dus echt wel wat een aantal consequenties zijn van over de grens werken. Zeker bij multinationals is dat een waardevolle ervaring waar zeker voor geldt hoe kan ik mijn klantenorganisatie de consequenties uitleggen van bepaalde keuzes. En dan kunnen we met z’n alle denken dat je dat uit een boekje haat en bij elkaar leest, maar dat is niet zo. Ik vind het absoluut een toegevoegde waar maar ook daarvoor geldt; het is het verschil tussen een tool-specialist of een consultant. Als je je wilt specialiseren moet je ervaring hebben.

HV: De volgende beschouwend: communicatie skills, ook waar, absoluut. Communicatie

het woord zegt het ook al. Het is een combinatie. Kan ik oppikken wat een klant nodig heeft. Heel veel organisaties weten zelf niet wat ze bedoelen he. Heel veel organisaties hebben ook tradities. Waarvan ze zelf niet meer weten waarom ze die hebben. Kan ik vervolgens achterhalen waarom ze die activiteiten nodig hebben. Ik moet snappen wat ze nodig hebben, om überhaupt te kunnen adviseren.

NA: Dat draag dan ook weer bij aan jou product kennis, en aan het adviserende gedeelte.

Dat je dus niet zegt van: “Dit doen jullie zo, dit wil je hebben”. Nee, meer: “Dit hebben jullie eigenlijk nodig om al jullie bedrijfsprocessen nog te kunnen ondersteunen”.

HV: Inderdaad. Op mijn manier kan je met minder kosten, en een lagere impact precies

bereiken wat je nodig hebt. En ik biedt jou de volgende mogelijkheden om ook op de lange termijn door te kunnen groeien. Ik kan niet alleen kijken naar nu, maar ook over tien jaar, om op deze manier door te kunnen groeien. Ik moet ook kijken of ik geen deuren sluit die groei over twee jaar wellicht in de weg zullen gaan staan.

NA: Puur uit interesse, maar hoe doorgrond je zo een doorgrondig proces? Hoe begin je

ermee om erachter te komen hoe de huidige manier van werken in elkaar steekt? HV: Dankzij de ervaring die ik heb, ik ben bedrijfseconoom van achtergrond, begrijp ik

wat boekhouden betekend, ik snap wat bedrijfsprocessen inzicht hebben. Dus dat betekend dat als ik bij een organisatie binnen kom, ga ik vragen stellen. Doordat ik dit kan plotten op de dingen die ik al heb gezien kan ik slimmere vragen stellen. Op een gegeven moment stel ik helemaal geen vragen meer die ik nodig heb voor een antwoord maar ik vraag alleen maar vragen die voor de klant van toepassing zijn. Ik

75

ben dan bezig met het zichtbaar maken voor de klant van zichzelf. Waar zijn uitdagingen zitten. Ik wil dat de klant een aantal dingen ook ziet die ik al gezien heb. Dat klinkt heel arrogant maar dat is wel hoe het werkt. Dankzij mijn achtergrond en de dingen die ik al gezien heb komt dat snel binnen. En als ik bij een klant binnenkom, dan begin ik heel ordinaire aan de koffie automaat. Koffieautomaat is gewoon de belangrijkste plek. Ik zie mijn rol als puur mensen werk. Praten. Luisteren. Nog meer praten en luisteren.

NA: Is een onderdeel hiervan ook het bestellen van verwachtingen? HV: Ja. Continue. Dit is verwachtingsmanagement. Als een klant een pakket heeft

gekocht, doorgaans met heel veel sales gewerkt vanuit de software leveranciers. Alles is daar bigger, stronger, faster, alles kan daar. Ja wacht even. Het kan allemaal tot op het moment dat je de volgende keuze hebt gemaakt en dan kan dit allemaal al niet meer. Flexibiliteit totdat je het vastzet. En je moet het een keer vastzetten. Dus je bent continue bezig met verwachtingen bijzetten. Ontwikkelen ook; wat mag een klant wel en niet verwachten? Wat is echt een utopie?

NA: Hoelang duurt een proces waarbij je de organisatie doorgrond? HV: Dat wisselt heel erg. Hangt af van de organisatie, van haar ontwikkelingsfase, van

welk team je mee werkt, de vraag die ik mee krijg. Het kan zo een half jaar duren. NA: Alvorens er eerste afspraken worden gemaakt over bepaalde doelstellingen etc? HV: Absoluut. En dan ben ik niet alleen. Dat doen we met een team. Daar gaat veel tijd

overheen. Hoe je dat meestal doet is om op zoek te gaan naar je beste vriendje. Dit is een super-user waar mee je vervolgens een partner in crime wordt. Aanvullende work-shops doen; het begrip ontwikkelen.

NA: En is dat iemand uit de klant-organisatie? HV: Ja bij voorkeur zeker. Kijk zij zijn de eigenaar van hun requirements. Als externe

kan je nooit eigenaar zijn van de behoefte van de klant. Dat betekent dat degene die de behoefte heeft ook vertegenwoordigd moet worden door iemand van die organisatie. Je moet toegelaten worden tot het interne netwerk van de klant. Wie heb je nodig voor een bepaald antwoord.

NA: Is dat aanspreekpunt bij voorkeur iemand hoog in de directie? HV: Ik roep altijd ‘iemand zonder secretaresse’. Maar het wisselt. Ikzelf heb het liefste

iemand zonder secretaresse. Iemand die daadwerkelijk zelf het werk uitvoert, die dus snapt wat het betekend. Want die maakt het dagelijks mee.

NA: Een gebruiker dus? HV: Nee, niet zomaar een gebruiker… Een zware gebruiker. Bijvoorbeeld een team-lead

van een gebruiker. Een meewerkend voorman van een gebruikersgroep. Degene die als voorman voor een team van de echte gebruikers staat. Iemand die ook het overzicht heeft over het waarom, en niet iemand die alleen maar doet wat heb verteld wordt. Maar ook snapt waarom en hoe zijn bedrijfsproces een bijdrage levert aan de organisatie. En dat is meestal iemand die bij zijn volgende promotie een secretaresse krijgt.

NA: Ik begrijp op welk niveau je zit te denken.

76

(pt. two) HV: Ik zou daar dus die vijfde heel graag aan toegevoegd zien worden. Dus

bedrijfsproceskennis. Bedrijfsproceskennis. NA: Ja. Ok. Ten derde wil ik graag het samenspel tussen klant en consultant belichten.

Zoals je net ook al aangaf is de klant in vele gevallen degene die bepaald of het een succes wordt of niet.

HV: Ja, dat klinkt misschien een beetje flauw. De klant is niet koning. NA: Maar die achteraf bepaald wel of het een succes is of niet. HV: Ja inderdaad maar dat betekend niet dat de klant koning is he. Kijk wat je vaak ziet is

dat het fout gaat op het moment dat je precies doet wat de klant wil. Dat betekent dan ook dat je geen consultancy durft te bedrijven. Ik vind het op het moment dat je weerwoord durft te geven tegen te klant, dan ben je bezig de grenzen van een project neer te zetten. Op het moment dat een organisatie onze hulp inroepen hebben ze vaak een probleem. En dat probleem bestaat voor een groot deel doordat ze zelf niet weten hoe of de mogelijkheid hebben dat probleem op te lossen. Dat betekent direct dat je daar als consultant moet binnenkomen en eigendom moet nemen van een deel van dat probleem. Of op zijn minst de oplossing voor dat probleem levende. Dat moet je vooral doen door te adviseren. Momenteel zit ik in het buitenland voor een klant. Mijn counterpart zei daar op het moment dat ik daar binnenkwam: “dont tell me want we want to hear. Tell us what we need to hear”. De mindset is heel belangrijk. Klant is geen koning. Je doet niet blind wat de klant zegt. Adviseren. Weerwoorden geven. Uitduiden wat consequenties zijn van iets. De klant bepaald wat succes is, ergens onderweg ook. Zonder klant heb je geen bestaansrecht. En daarmee is de klant het belangrijkste en de bepalende factor van succes.

NA: In hoeverre neemt een klant het advies op. Is hij bereid te veranderen. Kan hij

luisteren. Vertrouwd een klant jou. HV; Vertrouwen moet je verdienen. NA: Door? HV: Actief deelnemen. Constructief adviseren. En dat gebeurt ook bij de koffieautomaat.

Laten we eerlijk wezen. NA: De understanding van de consultant. Dit heb ik gedefinieerd als dat de twee partijen

dezelfde taal spreken. Ik kan me namelijk voorstellen dat hier een compleet andere bedrijfscultuur hangt dat in de staalindustrie.

HV: Ik denk dat je die op de verkeerde plek hebt gehangen. Ik kan de klant namelijk niet

veranderen. Ik kan wel ons veranderen. Dat betekend dat het begrip van de consultant voor een heel belangrijk deel bij de consultant ligt. Dan kom je bij de comunicatie skills uit. Kan ik mijn boodschap uitleggen op een dusdanige manier dat de klant het snapt.

NA: Het is dus niet zozeer een klant specifieke eigenschap, als meer een consultancy

skill? HV: Ja. De klant heeft een communicatieniveau en dat is een gegeven. Hij staat er wel

maar ik vind dat de verantwoordelijkheid verkeerd ligt. Het is niet hun

77

verandwoorlijkheid om de consultant te snappen. Het is de verantwoordelijkheid van de consultant om de klant te snappen.

NA: Dit zou dus beter passen tussen te communicatieve vaardigheden van een consultant.

Verder ligt er bij de klant wel een verantwoordelijkheid om de motivatie naar een verandering te voeden. Bijvoorbeeld iemand bovenin het bedrijf kan wel bepalen dat er nieuwe software nodig is en dat dat er moet komen en dat alles gestroomlijnder moet. Maar er zijn vaak mensen die een paar lagen daar onder zitten, de gebruiker zijn en het allemaal wel best vinden de manier waarop het nu gaat. Hierdoor ontbreekt vaak de motivatie om te veranderen. Klopt dit en hoe beïnvloed dit management consultancy succes.

HV: Klopt. Veranderen doet pijn. Dit heeft een sterke invloed. Absoluut. Er is wel

moeilijk een maat aan te geven maar.. Het gaat over het commitment aan de verandering van de klantorganisatie. Op het moment dat die weerstand die jij beschrijft op operationeel niveau door de klant niet als verantwoordelijkheid wordt genomen, dan heb je een probleem, want dat kan ik als consultant niet veranderen. Ik kan de organisatie nogmaals niet veranderen. Dat is een verantwoordelijkheid van de klant organisatie en dat betekent tegelijkertijd ook dat de keuze die op een hoog niveau wordt genomen, dat die intern uitgedragen en getrokken wordt. Als een externe consultant kan je het wel proberen maar dat zal niet goed gaan.

NA: Heb je daar concreet methodes om die bereidheid en motivatie te beïnvloeden en te

versterken? HV: Ja. Dat gaat over organizational change management. Dat gaat over uitleggen.

Communiceren. De voordelen uiteenzetten. Uitduidelijk van wat heb je er als gebruiker aan. Eerlijk gezegd

NA: Maar concreet gesproken. HV: Wat ik doe is dat ik bij organisaties laat zijn hoe de applicatie zich ontwikkeld. Daar

zijn conference pilots voor. Product demonstraties. Met een aantal stakeholder, eigenlijk de beste vriendjes die ik net noem, medeplichtig maak aan het succes van de oplossing. Dat betekent dat zij, als je het werk goed doet is het dus de consultant en die bedrijfsproces vertegenwoordiger is een twee-eenheid waar die persoon ook verantwoordelijk is, of zich voelt voor het succes en de manier waarop het wordt uitgedragen intern in de organisatie. En daarom heb ik dus ook die vent nodig zonder secretaresse. Dat is namelijk een van de mensen van de werkvloer. Die snapt waar het over gaat en ook hoe hij het moet uitleggen.

NA: Aha, duidelijk. En dat is dan ook ‘one of the team’. HV: Ja. Maar dat laat onverlet dat als het van boven niet ondersteunt wordt. Niet

uitgelegd wordt waarom een bepaalde verandering plaats gaat vinden. Waarom de grotere verandering, in het grote perspectief goed is voor de organisatie. Wat je in de toekomst dus wel kan, maar in het verleden niet meer. Maar ook andersom, dus de plussen en de minnen. Ik bedoel dit gaat over een heel belangrijk deel over eerlijkheid. Dit gaat over het vertrouwen dat je niet alleen als consultant moet verdienen maar ook het vertrouwen wat je als project moet verdienen. Dat kan je alleen maar doet dooreerlijk en open te communiceren. En vooral ook geen minpunten te verhullen.

NA: Begrijp ik dan goed dat daar ook in jou ogen een hele grote verantwoordelijkheid ligt

bij het bedrijf en in veel mindere mate bij de consultant?

78

HV: Absoluut. Absoluut. Ik kan de klant niet veranderen. Als zou ik het willen. Al zou

ik het kunnen zou ik het niet willen. Dat is een verantwoordelijkheid van die organisatie.

NA: Maar heeft weldegelijk een uitwerking op jullie bedrijfsvoering. HV: Uiteraard. HA: Als vierde variabele, de mate van succes. Het project is klaar. HV: Hoe meet je succes. Uitstekende vraag. Dat is ook een hele moeilijke. Laat ik hem

omdraaien. Wij hebben een kwaliteitsmanagement systeem dat heeft DOTAS. Dat staat voor on-time management, and customer expectation. Aan het begin van een prject vragen we aan de klant noem de criteria op waar je ons op gaat toetsen achteraf. Wij spreken in beginsel, aan het begin van een project met de klant af wat die succes criteria zijn. En dat betekend dat op verschillende momenten tijdens, en ook aan het einde van het project, vragen wij score ons maar. Dit waren de criteria die we hebben afgesproken, hoe scoren we hier op. Moeten we nog bijsturen. Wat kunnen wij nog veranderen als we tekort schieten. Aan het einde van de rit vragen we: “we hebben het er verschillende keren over gehad. Wat is het eindoordeel?”. Dat is de officiële lezing. En dat is een kwantitatieve manier van succesmeeting. Kwantitatief in de zin van, hoe scoren wij op de schaal van een tot tien. Daar komt gewoon een rapport cijfer uit. Dat maakt het kwantitatief.

Daarnaast zijn er nog een aantal andere meetingen. Ik meet mijn succes over het minimaliseren van maatwerk. Wat ik eerder zei. Ik geloof er absoluut in dat als je maatwerk erbuiten weet te houden heb je op de lange termijn een meer tevreden klant. De kosten zijn lager, de risico’s zijn lager, en de mate waarin het pakket beheersbaar is en upgadebaar is, is veel hoger. Dat is er eentje.

De tweede. Dat is nog een hele andere. En dat is een stukje emotie. Sta je aan het einde van het project als dikke vrienden boven op het project tevreden terug te kijken, te genieten op de go-live borrel. Van dit hebben we toch samen gedaan. Zit er vervolg business in. Hoe gaat die relatie zich ontwikkelen. Ik vind een implementatie is een ding. Maar beheer, onderhoud, nieuwbouw, aanbouw, uitbreiden. Met een life-cylce van pak en beet tien jaar. Ja daar in die vervolg relatie die je hebt dat bepaald of je succesvol bent geweest.

NA: Of ze weer voor jou gaan. HV: Ja. Dat op een hele natuurlijke manier gewoon de telefoon gewoon blijft gaan, van:

“He hoestie nou, oh btw ik heb nog een vraag kan je me even helpen.” Kijk dan weet je dat je punten hebt gescoord. Dan ben je weer terug bij, je wilde dikke vrienden zijn, en is dat gelukt. Dat klinkt heel manipulatief, dat is het niet. Kijk ergens anders had je ook staan dat gaat over de chemie tussen de consultant en een klantorganisatie. Niet iedereen past gewoon overal. Laten we eerlijk wezen. Nou kan je de juiste mensen op de juiste plek op de juiste plek inzetten. Kan je die chemie creëren en ontwikkelen.

NA: Is de mate waarin de klantorganisatie op een gegeven moment weer support nodig

heeft, omdat zaken niet naar behoren draaien. Hoe minder een klant daar behoefte aan heeft, hoe minder ze achteraf voor support moeten vragen, is dat ook een meting van succes.

79

HV: Ik zou dat graag als criterium zien maar is gelijke tijd wel weer heel afhankelijk van in hoeverre hebben we een vanilla cq. op maat gemaakte oplossing geleverd. Het hangt af van de complexiteit van de oplossing. Ik wou dat ik kon zeggen dat zero-support altijd de realiteit is maar dat is gewoon niet zo . Beheer heeft een reden.

Als je het hebt over fouten, en constatering van fouten, dat is absoluut een criteria voor succes. Maar dan ga je die fout ook zeker tegenkomen in dat OTAS, dat ik zojuist benoemde. Zijn de blij met het project, of rammelt het aan alle kanten.

NA: Wanneer wordt een OTAS evaluatie ingevuld? HV: Twee maanden na een go-live. Als je bijvoorbeeld kijkt naar een boekhoudkundig

proces. Wat ik altijd interessant vind is de tweede maandafsluiting. Dat is het moeilijkst dat alle cijfers bij elkaar worden gesprokkeld. De eerste keer is minder representatief. De tweede wel want dan is er weer een grote mate van business-as-usual. Dan moet je vragen: “Ben je echt tevreden?”.

NA: Begrijp ik dan goed dat in een OTAS dat daar vaak kosten en tijd criteria een rol

spelen? HV: Dat kan. Dat hoeft niet, maar dat is maar net of de klant dat wil. In veel gevallen

komt dat zeker aan bod. Dan gaat het over de budget overschrijding. NA: Waarschijnlijk worden toeleveranciers van de klantorganisatie ook beïnvloed door

een nieuw ERP systeem. In hoeverre wordt de mening of tevredenheid meegenomen in jullie succesmeting?

HV: Veel. Maar dat heeft ook te maken met hoe ga je je scoping afbakenen. Het komt

namelijk ook redelijk vaak voor dat wij niet eens met toeleveranciers mogen praten, punt. Als het anderzijds bijvoorbeeld gaat over interfaces van bijvoorbeeld digitale facturen, dat is kennis die wij absoluut meenemen. Wij proberen dat naar standaarden toe te trekken. Omdat we bij andere organisaties hebben gezien hoe de mensen dat graag willen.

NA: Ik denk dat we alles besproken hebben. Alles is heel duidelijk. HV: Ik ben heel nieuwsgierig naar je resultaat. Transcript interviewee 3 NA: Interviewer RM: Interviewee (Interview is in Dutch) NA: Dit is het model dat ik vanuit de literatuur heb ontwikkeld. Drie variabele heb ik

opgedeeld. Consultation role: de verschillende rollen die er binnen een implementatie project spelen. Competence of the consultants: vaardigheden, skills die een consultant heeft. En als derde karakteristieken van de klant organisatie die

80

ook wel hun uitwerking hebben op het proces van de consultant. Uiteindelijk leidde deze variabele tot succes.

Vanuit die consultation role heb ik vier rollen opgetekend: business analyst, project

manager, systeem architect en een technology consultant. Waarbij de business analist het overzicht houdt en die plant en project. De project manager is in deze beschrijving meer een soort ondersteunende administratieve functie en de schakel tussen de klant en de consultancy bedrijf. De systeem architect is degene die een schets maakt van hoe het systeem er uiteindelijk uit moet komen te zien. De technology consultant wordt ook wel de code krasser.

RM: Ja. Dat laatste doe ik niet. NA: Deze vier rollen dus en daarbij vroeg ik me af of u deze rollen kent en welke

ontbreken er? RM: Ja, op zich ik heb het denk ik een keer of zeven of acht keer gedaan, een bedrijf

breed systeem invoeren zeg maar. Dan ontkom je niet aan het feit de rol van projectmanager op je te nemen. Meestal ook nog wel de consultant die moet vertellen hoe het moet gaan gebeuren. De architectuur is lastiger. Vaak merk je daar al een heleboel over is nagedacht en dat je binnen dat raamwerk moet opereren.

NA: De klant heeft daar al over nagedacht dus? RM: Ja, inderdaad. Sommige hebben al heel duidelijk een eisenlijstje opgesteld en een

hele architectuur al bepaald. Daar moet dit dan binnenvallen en beseffen dan eigenlijk niet dat zo’n architectuur, zeker bij een standaard ERP systeem, je de architectuur moet aanpassen het systeem. Ja, dan gaat t in ieder geval makkelijker. Of het goed is voor je bedrijf is een tweede hoor. Ik ben eigenlijk überhaupt helemaal geen grote fan van zo’n systeem. Als we allemaal SAP installeren en allemaal in China onze spullen laten maken, waar gaan we dan concurreren. De service aan de klant komt vaak uit zo’n systeem en dat zal dan voor iedereen gelijk zijn. En de kwaliteit van de spullen die allemaal uit China komen is nagenoeg gelijk. Als je kijkt naar bedrijven die nu heel succesvol zijn geven toch vaak een compleet eigen invullen aan hun informatie systemen. En daardoor een concurrerende positie kijken. Snap je. Maar goed je had t over rollen. Dus ja wat ik eraan mis in feiten is de adviseren aan het bestuur zeg maar. Aan de hoogste directie. Je moet ontzettend lobbyen en die mensen veel beter uitleggen als dat ze dachten dat ze het moesten weten, mee gaan leven, en zodat ze het gaan omarmen. Echt iedereen moet top-down hier helemaal voor gaan. Daarnaast moeten ze beseffen wat het is wat ze doen. Ik heb nog nooit een SAP invoering gedaan maar wel een vergelijkbaar systeem bij telefoonwinkels en ja als de directie daar niet vol achter staat. Ik heb meegemaakt dat dus de IT manager en de operations manager helemaal enthousiast waren en de algemeen directeur het helemaal niets vond.

NA: Van wie kwam dan het initiële idee? RM: Dit was voor de phonehouse in België en die waren overgenomen door Belgacom en

die zei dit moet. NA: Conformeren naar hun systeem? RM: Nou niet conformeren naar hun systeem want in feiten hadden ze al die Phone house

winkels overgenomen van de Engelse eigenaar en de mededingingsautoriteit in België heeft toen gezegd van dat mogen geen Belgacom winkels worden. Dat moet

81

een eigen winkels blijven. En daarom moesten ze andere systemen aanhouden. Die kochten vervolgens een standaard pakket van een ander bedrijf, Datacom in Tilburg en die hebben mij ingehuurd dat daar te implementeren. Ik had al een keer iets gedaan voor hun in een ander bedrijf. Ja een hele rare situatie van een directeur die het eigenlijk niet wil maar het toch maar laat gebeuren. De andere zijn enthousiast, maar daaronder niet. Die politieke strijd die zich aan afspeelt is een drama.

Ik heb wel heel wat nachtjes daar geslapen om het een en ander aan lobbywerk op te

knappen. Tegelijkertijd moest het maar met de helft van de winkels. En dat ene gedeelte wilde eigenlijk alleen maar concurreren op de prijs van het nieuwe systeem. Zij hebben destijds gewacht tot de laatste dag van het aanbod om een magazijnbeheersoftware te kiezen. Maar ze zijn uiteindelijk ook gewoon failliet gegaan. Dat zat er wel aan te komen want dat was echt…

NA: Daar was gewoon geen motivatie? RM: Ja wel motivatie om geld te verdienen maar elke euro die aan het IT systeem werd

uitgegeven vonden ze zonde. Er werd daar constant en alleen maar onderhandeld over de prijs, wilde niets meer betalen dus werd er ook niets meer gemaakt. Toen die winkel eindelijk live ging hadden ze zozeer schulden dat het gewoon niet verkocht kon worden.

NA: Maar is het zo dat de verantwoordelijkheid van het bedrijf en niet zozeer van een

invoerende partner. RM: Nee dan kom je natuurlijk op de vraag wat is de consultancy deel van de specialist,

van mij. Ja ik voel het wel als mijn plicht om mijn kennis en ervaring mee te brengen. Kijk ik heb het eerder gedaan en zo gaat het niet.

RM: Architectuur doe ik er. In België werd er gekozen voor een architectuur die ik wel

goed kende. Ik heb een klant gehad, WSW, die had een architectuur, wilde een standaardsysteem invoeren, is op z’n bek gegaan en mij ingehuurd dat weer recht te zetten. Daar had ik de vrijheden om de architectuur aan te passen.

NA: Naar de oude situatie? RM: Nee, nee, naar nog een andere nieuwe situatie. We zijn op weg naar een op

webserver georiënteerd systeem. SAO he, hebben we daar ingevoerd. Twee standaard pakketten gekocht en die met een workflow aan elkaar geknoopt. Dat moest dan wederom ook weer voor weinig want dat geld was allang uitgegeven. Daar ben ik constant met de architectuur begin geweest. Dan moet je dus ook zeker weten dat alle communicatie en alles wat er met elkaar besproken wordt via de Unibus wordt geprogrammeerd. Ik heb dus graag de architectuur erbij. Die hebben vaak een aparte architect. Die hebben besloten zo zit de wereld in mekaar en weten dus zo mocht het wel en zo niet. Dus daar zou je je aan moeten houden.

NA: Heeft u dat opgevat als prettig of onprettig? RM: Een architectuur, het is natuurlijk beter om met een architectuur te werken dan

zonder. Alleen als je met elkaar afspreekt van als die architectuur gekoppeld is en dat wordt wel zo te zijn, aan de business en deze business aan de strategie. Een voorbeeld van strategy is de volgende: He ga met mijn architectuur alle kanten op want de strategy van het bedrijf is ook dat het zo’n flexibel bedrijf moet zijn. Dan moet ik zorgen dat alles zo goedkoop mogelijk op te lossen moet zijn. He dus je moet dat aanpassen en in dat kader is het goed dit aan elkaar te matchen.

82

NA: Maar de architectuur is toch gewoon een gevolg van de bedrijfsstrategie? RM: Ja, als het goed is wel. Ik geef er les in. Architectuur is een kader scheppen, grote

lijnen aangeven van hoe moeten onze systemen eruit zien en hoe moeten communiceren met elkaar? En de enige reden waarom je dat überhaupt moet doen is om de business te ondersteunen. De business bepaald welke systemen je nodig hebt en dat wordt weer gedaan door de strategie. Ik moet daarbij wel vermelden dat ik vanuit mijn ervaring heb gemerkt dat ongeveer maar dertig procent van alle bedrijven het zo doet. Vaak zie je dat bedrijven hun eigen IT afdeling hun eigen architectuur zelf verzinnen en de rest van het bedrijf zegt dan al snel: “ok”. Want ja wat heb je daar nou mee? Stel je nou voor dat jij sales manager bent van een bedrijf en ze zeggen tegen jou: “OK, we hebben een nieuw pand laten neerzetten, welke architectuur wil je?” Nou toon maar een plaatje, het ziet er goed uit. En als je later dan zegt we hebben het pand zo bedacht dat mensen snel van verdieping kunnen wisselen en veel ramen zodat men makkelijk naar elkaar toe stapt dan kan je achteraf niet meer zeggen dat had ik anders gewild. Architectuur is goed. Een ERP systeem is in feiten altijd de vervanging van alles. Als je dan vasthoud aan je architectuur, is dat eigenlijk onhandig. Afspraken over hoe het gebouw eruit moet blijven zien, maar we gaan naar een nieuw gebouw. Moet je dan niet zeggen; all bets are on, we gaan kijken naar nieuwe manieren en eisen die we aan zo’n architectuur kunnen stellen. Vaak doen we dat dus niet, zeker niet als we die architectuur in die ivorentoren is bedacht. Want dan ben je de pineut want dan moet je je daar aan houden en raak je in een enorme spagaat komt er een leverancier en die zegt dit is mijn standaard pakket en dan ga jij kijken hoe kan ik dat in die architectuur voegen.

NA: Dus eigenlijk zou dat in constante samenspraak moeten worden gedaan? RM: Moet sowieso altijd met een standaard architectuur moet je kunnen zeggen deze even

niet. NA: Zou dit ook de volgorde van belangrijkheid zijn die u zou aanhouden? RM: Ja. Het begint met de consultant die de ervaring en kennis meeneemt uit vorige

klussen. Iemand moet ooit begonnen zijn. Ik zou het bedrijf nog willen zien die het alleen gaan doen, zou ik heel stom vinden. Die gaan fouten weer opnieuw maken. En dat gebeurt natuurlijk ook constant. Dat staat ook overal in de krant. Laatst ook weer een bedrijf die gingen SAP invoeren, acht ton. Nou doen maar eens drie komma acht miljoen. Eerder ben je echt niet klaar. Dat is mijn ervaring. Licenties zijn vijf ton en zij denken dat ze het in drie ton kunnen invoeren. Factor tien is een meer reële en veiligere gok. Tenminste als je het goed doet. Andersom werkt het natuurlijk ook he, als iemand mij om een offerte vraagt zou ik het zelfde toen anders is er altijd weer iemand die het voor minder doet en dan mis ik die klus. De grootste optimist heeft de opdracht en die kan achteraf altijd nog een uitleggen waarom hij toch een drie keer zo duur is geworden.

NA: Dat is een beetje een krachtenveld ook natuurlijk RM: Ja zo houden we elkaar lekker in dromenland in ieder geval. NA: Duidelijk. Vervolgens heb ik inderdaad de vaardigheden/karakteristieken proberen te

omschrijven en dat zijn de volgende geworden. Technische vaardigheden, mate van ervaring, communicatieve vaardigheden en zakelijk gevoel en aanpassingsvermogen. Zo werd het omschrijven in de literatuur.

83

RM: Ja. Die laatste heb je ontzettend hard nodig. Dat zakelijke gevoel zeg maar je moet altijd voor ogen houden waar je doel zit.

NA: Wat ik daar ook heel duidelijk mee bedoel is de bedrijfstak specifieke kennis die een

consultant dient te hebben. Dus in hoeverre is het nodig dat iemand van een logistieke achtergrond bij een logistieke partij ook aan de gang gaat.

RM: Ja. Ik zou in principe, als je kijkt naar SAP heb je voor elk onderdeel van een hebben

ze wel aparte specialisten rondlopen. Het bedrijf kan ook niet helemaal zeggen ik gooi al mijn bedrijfsvoering om voor dit pakket, dan zou SAP moeten bedenken hoe zou jij nou voortaan je werk doen. Gebeurt wel eens maar dat is meestal geen succes. Zo’n bedrijf is meestal in een plak zijn identiteit kwijt en de reden waarom die bestond en dan is niet zo handig maar iemand die jou generiek van zaken weet, ja dat is wel een gevaar. Want die herkent natuurlijk niet de dingen die voor jou bedrijf nou juist de competitive edge maken voor t bedrijf. Misschien ben je wel heel goed in logistiek, ik weet het niet maar het zijn vaak de bedrijven hun doelen die in hun strategieën staan wat ze nog niet zijn. En de aanschaf van systemen is ook bedoeld om daar waar e nog niet zijn te komen. En tegelijkertijd gaat iedereen ervan uit dat het systeem dat je invoert alles dat je al wel bent en waar je goed in bent, dat je dat kunt behouden. En dus de focus is helemaal weg. Meer flexibel, betere klantenservice et cetera. En als je niet uitkijkt is alles waarom je in eerste instantie die klanten had verdwenen. Dus moet je allebei. En vaak is het dan wel handig om te zeggen ik heb een persoon uit het bedrijf, een goede super-user die de oude systemen tot een haar van een gort kende en vanuit de business gebruikte en iemand die naar de nieuwe dingen kijkt en die moeten wel vriendjes zijn van elkaar…

NA: Een externe. RM: Ja, een externe voor de nieuwigheid. Want die key-user is daar want verandering is

weerstand, krijg je altijd weerstand op en meestal zijn interne mensen daar dus niet blij mee. Dus om dan te bedenken dat je te dicht blijft van waar je vandaan komt, dat is gevaarlijk. Dus neem je een buitenstaander, en als die het goed met elkaar kunnen vinden en allebei gelukkig zijn en de ene zegt nou wat we deden doen we nog steeds goed en de andere houd een oog op wat de doelen zijn, dan heb je iets moois te pakken. Een mix is ideaal op dat gebied.

NA: Op deze manier kan je ook een bepaalde communicatieve vaardigheid, mandaat

uitdragen omdat je met iemand van intern naar het bedrijf toe spreekt? RM: Nou, communicatief denk ik dat je vooral in het bezit moet zijn van empathisch

vermogen. Snappen wat de beweegredenen zijn van de andere. Zelf beschouw ik mijzelf als een lichtelijk manipulatief persoon die zaken lichtelijk naar zijn hand zet. Probeer de koppen mijn kant op te krijgen. Maar dan doe ik alleen maar omdat ik weet wat de mensen willen en wat ze eruit proberen te halen, wat zij verwachten. En meestal de echte gebruikers van de systemen, ja die doen dat werk al tien jaar en zijn als de dood dat ze het na de implementatie niet meer kunnen. Die angst moet je vooral wegnemen dat doe je door te communiceren, door prototypes te laten zien en ze het systeem te alten snappen. Op die manier worden ze minder bang en hebben ze het idee dat het werk alleen maar leuker wordt. Al die mensen zitten constant te denken hoe ze het beste de boot af kunnen houden en zorgen dat het niet gaat gebeuren. Dus dat is maximale weerstand. Je voelhorens uit, goed luisteren, in kunnen leven en zeggen ok ik snap dat die een probleem heeft, dat hij als de dood is, we kunnen ons nog wel een keertje herinneren. Toen dacht ik dat ik iedereen mee had, ook de afdelingshoofden van de dames die het meeste met het nieuwe systeem gingen werken en toen kwam ik haar toevallig tegen op de concert van Blof. Toen

84

liet ze zich bij de eerste koffie al ontvallen dat ze gewoon helemaal als de dood was van wat er stond te gebeuren. En dat we alle koppen dezelfde kant op hadden. Nou deze nog niet dus. Heleboel aandacht moeten geven maar als ik dat van te voren niet geweten had, had het er allemaal wellicht heel anders uit hebben gezien.

NA: En hoe ziet zulke aandacht er dan concreet uit? RM: Erachter zien te komen wat de angsten dan precies zijn, en waar komen die uit voort.

En dan het goede manier van maatregelen eigenlijk. Als ze zegt ik kan het niet moet je een prototype van het nieuwe systeem laten zien, en laten merken dat het eigenlijk alleen maar makkelijker wordt. Als het is dat ze denkt dat ze haar baan kwijt raakt dan heb je liever dat de baas haar verteld dat er ontslagen gaan maar dat hij voor iedereen een rolletje heeft bedacht. En anders laat hun er dan maar gewoon eerlijk over zijn.

NA: Dan begrijp ik ook dat u het ziet als een verantwoordelijkheid van u dat iedereen in

de organisatie meewerkt? RM: Ja, verantwoordelijkheid. Ik zou makkelijk kunnen denken dat iemand anders dat

maar moet doen maar realiteit is alleen dat ik uiteindelijk degene ben die met de gebakken peren blijf zitten omdat ik geen succesvolle invoering heb gedaan. Dus dan kan ik zeggen: ‘ah, dat is mooi mijn schuld niet’, of ik kan zeggen: ‘ik ga mu olie overal in gieten en zorg dat het gaat werken bewijzen van spreken. Het is dus meer een stukje realisme in plaats van dat het echt plichtsbesef is of iets.

NA: Ik merk dat deze verantwoordelijkheid wel verschillende wordt gedragen en ervaren

door de verschillende geïnterviewde. De een zegt ook bijvoorbeeld ik kan de klant niet veranderen.

RM: Ik wil de klant wel veranderen hoor. Ik moet de klant veranderen. Consultant en ik

zeg het maar elke keer. Ik heb het ook in de klas gezegd: een consultant veranderd altijd. Zelfs als ik niets verander. Stel je bijvoorbeeld voor dat ik een onderzoek doe en daar komt uit dat je niet in die nieuwe markt kunt stappen, dan heb ik iets veranderd want nu weet je dat je niet in die markt kan stappen. En alle mensen hebben hebben een hekel aan verandering. Ik doe dit de hele dag voor me werk maar als ik dan thuis kom en me vrouw heeft de bank verschoven baal ik. Dat vind ik dan niets. Dus er is altijd verandering. Dus ik zou het ver raar vinden als je de gevolgen van die verandering niet draagt. Daar geloof ik niet in. Er zijn ook bedrijven die zijn verandermanagers inhuren, dat is puur praten praten praten. Die kunnen dat wat subtieler, meestal met een psychologische opleiding. Maar is kleinere implementaties heb je die luxe gewoon niet dus moet je het zelf doen.

NA: Ok. En Uitgaande van de tijd, hoe zou u deze vier eigenschappen in volgorde zetten? RM: Hebben we het over de lead-consultant? NA: Ja. RM: Ervaring is het belangrijkste, om een paar keer op je bek te zijn gegaan is denk ik

wel erg handig om te weten waar het allemaal mis kan gaan. Dan communicatieve vaardigheden. Je bent het vooral aan elkaar aan het praten, en iedereen meekrijgen. Goed als je communicatieve vaardigheden hebt dan is je zakelijke gevoel en aanpassingsvermogen ook wel voor elkaar natuurlijk.

NA: Softskills

85

RM: Ja die zijn denk ik wel het meest belangrijk. Je moet het uit kunnen leggen ook.

Soms heb je daar wel wat technisch skills voor nodig maar dat valt eigenlijk wel mee. Dus op dat gebied ben je meestal met een oog koning in et land der blinden. Jij weet genoeg om hun te kunnen overtuigen.

NA: Dit is inderdaad iets wat vaker voorkomt inderdaad. RM: Zo werkt het. NA: Even kijken en dan als vierde waar we het over hadden, die samenspraak, de klant

zelf en haar impact op… Daar heb ik gezegd in hoeverre vertrouwd de klant de externe.

RM: Ja, dat is een lastige. Die grote clubs daar kiezen ze toch vaker voor een minder ervaren persoon omdat hij bij Accenture werkt of CooperLiamond, omdat men toch denkt daar zit nog een baas achter die ook verantwoordelijk is. Eigenlijk merk je dus dat men het vertrouwen nog makkelijker vind te geven aan een consultant als er nog een gerenommeerd bedrijf achterstaat. In de werkelijkheid maakt dit natuurlijk niets uit want dat bedrijf weet bij god niet wat die consultant doet. Iedereen in dat bedrijf is namelijk minder goed in het geen dat die consultant doet, en zelfs collega’s zullen nauwelijks op de hoogte zijn van wat hij doet. Als hij tegen een boom zou rijden zou je een nieuwe daar naar toe moeten sturen, wat met een ZZP’er ook zou moeten. Maar je merkt toch wel dat met grote projecten de echte vijf tien miljoen projecten die krijg ik niet. Want die bedrijven vinden dat te eng om dat op te hangen aan een een persoonszaakje. Vanwege continuïteit en dat ze denken die grote firma kan ik nog aanklagen als het me te veel geld kost en een zo’n persoon kan ik helemaal niets meer mee. Ik denk ik de realiteit dat idee dat je toch iets extra’s achter de hand hebt wel waar is. Ik heb wel een gehad dat ik een concurrent had voor dit project en ik dacht die haalt het niet bij mij maar die is toen toch verkozen boven mij omdat…

NA: Vanwege een bepaalde reputatie? RM: Ja er stond Accenture op zijn loonstrook en op die van mij staat gewoon mijn eigen

firma. Dus ik kan me daar nog wel iets bij voorstellen. Ik denk dat jij je nieuwe auto ook bij een dealer haalt ij dat merk in plaats van dat er iemand langskomt die zegt goh bij mij min drieduizend. Dan denk je: “he wat zit daar achter”, weet je wel. En voor die paar centen ga je toch naar die dealer toe.

NA: En soms voelt het natuurlijk ook fijner om meer te betalen he? RM: Nou… zo ben ik niet. Maar je gaat je wel afvragen ok wat zijn mijn risico’s. En die

kan je niet inschatten. Die risico’s zijn voor nog geen dertig procent te behappen. NA: Hebben die grote partijen aansprakelijkheid? RM: Nee, die is volledig teruggezet. Hun inzet in volledig op een inspanningsverplichting,

dus nee. Nou ja, je merkt toch ook wel de overheid toch ook een paar keer XXX aangeklaagd maar dat hebben ze nooit echt tot een rechtszaak doorgevoerd maar ik neem aan dat ze daarna projecten voor een half miljoen minder hebben gekregen. Zo’n bedrijf denkt dan ook, we zijn stout geweest dus gaan ze wat terug geven. Ik heb daar niet eens de capaciteit voor, laat staan de wil.

NA: Duidelijk. Daarnaast ook de mate waarin de klant informatie opneemt en daarnaast

ook wil opnemen, dus gemotiveerd is om te veranderen.

86

RM: Ja om daar ook bewust aan mee te doen. Er zijn zat management teams die denken

oké we gaan veranderen maar de werknemers denken: “en wij gaan lekker door zoals we dat altijd deden.”. Nee zij moeten nog het meeste veranderen. Dat is de bedoeling niet. Vooral bij banken is dat heel erg. Daar heeft iedereen jaren lang ja en amen en goed meneer tegen hun baas gezegd want ze weten op een gegeven moment groei ik door naar die plek en mag ik mijn zakken vullen. Dan is het mijn beurt en ondertussen zijn we al die Ocly en Sharbains aan het invoeren die zorgen dat dat zakkenvullen ophoudt, letterlijk. Ja iedereen in dat management want mijn beurt komt nog. En ik heb er krom voor gelegen, te weinig betaald gekregen en ik heb me laten uitschelden omdat mijn beurt nog komt, daarom heb ik dat allemaal gepikt. En nu moeten ze elf gaan deelnemen aan het afschieten ervan. Dat is een hele lastige. Daarom zeg ik vooraf al ik ga niet bij een bank aan de slag. Dan kun je beter een naam van een bedrijf achter je hebben staan want dat heb je nodig. Ja daar gebeuren rare dingen op dat gebeid maar ja het is hoe zal ik het zeggen de motivatie van management is er dus. Uiteraard wel op papier maar in de werkelijkheid is het vaak het tegenover gestelde. Als men dat bewust doet kan je ook niet bijsturen en manipuleren en zorgen dat het beter wordt. Dan gaat het gewoon nooit gebeuren. Ik zat bij een bedrijf met meer dan twintig duizend werknemers waar gewon een van de IT’ers zei ik mag die vent niet voor wie we het doen, dus we doen het gewoon niet. Een medewerker van de eigen IT afdeling. Maar hoog genoeg in de toren dat zijn manager zei: “als hij het tegenhoudt ga ik het niet een proberen”. Dus ze deden het gewoon niet, en waarom omdat hij die kerel niet mocht. Een persoonlijke vete wordt dan gewoon een belangrijke verandering gestopt.

NA: Dus die motivatie kan op individueel niveau zelfs al bepalen… RM: Ja, niet eens alleen slecht maar saboterend zijn. Zo heb ik ook wel eens een project

meegemaakt dat was voor de gemeente Rotterdam, lang genoeg geleden want die mensen werken er allemaal niet meer waarbij dus het afdelingshoofd waar ik een nieuw systeem voor maakte tegen de baas zei ik wil afgekeurd worden. Hij was een keer van zijn fiets gereden door de tram en dacht dat hij afgekeurd zou worden, arbeidsongeschikt zodat hij lekker thuis kon blijven. Maar dat was niet gebeurt dus in die tijd had de werkgever daar nog een boel over te zeggen. Tegenwoordig valt dat buiten zijn gebied. Dus hij zegt tegen zijn baas ik wil afgekeurd worden en als dat niet gebeurt gaat dat systeem nooit een succes worden. Waarbij de baas zegt: “dan stoppen we met het systeem”. Ik geloof dat ik toen al iets van vier ton had uitgegeven.

NA: Heel apart zeg. RM: Nou zo apart is het niet hoor. Het is een mensen business en ja mensen komen soms

in machtsposities en macht corrumpeert het. Dat is altijd zo. Iedereen die in eens denkt ik kan alles, ik kan helemaal kiezen hoe is dit doe. Er zijn maar weinig die dat kunnen weerstaan hoor. En nou, ja op dit niveau als je in die bedrijven komt wat je vaak die macht onderuit halen of je gaat ontdekken wat ze hebben stout gedaan. Je hebt allerlei manieren kom je daar op zo’n hoog niveau binnen dat ook zei het als bedreiging zien. Nou dan mag je hopen dat je medewerking krijgt. Zelfs van degene die jou de opdracht geeft. Ja, maar ja.

NA: Het is een jungle. RM: Ik heb zelf altijd als regel gehanteerd, bijt niet in de hand die mij voedt. Dus degene

die mij uitbetaald die mijn betaling goedkeurt die is de baas. En als hij zegt het moet langzamer of het hoeft niet helemaal succesvol te gaan nou dan zeg ik oké. Ja ik

87

moet toch ergens de lijn trekken. In plaats van weer naar de hoogste directie te stappen en zeggen nou hij doet t niet goed. Ik heb een keer in een heel zware … gestaan, ik heb het toen toch niet gedaan en uiteindelijk denk ik nog steeds van he goh hoe was dat afgelopen, als ik naar de hoogste baas was gegaan en gezegd: besef je je wel wat daar allemaal afspeelt.

NA: Want in hoeverre worden projecten gedaan waar u medewerking aan hebt verleent,

die niet op het hoogste niveau begeleiding krijgen? RM: Dat is vooral afhankelijk van de grote van het bedrijf. Een middenbedrijf en zeker

een klein bedrijf daar gaat dit steeds om zulke bedrijven dat het altijs de aandacht heeft van de directie. Alleen bij de hele grote jongens, tienduizend man of meer ofzo, misschien vijf zes duizend man al, daar is ook een ERP systeem nog niet echt zo’n grote uitgave. Gaat het ook meestal niet door alle divisies heen. Dan is het alweer een op de vijf divisies waar het gebeurt dus ook een vijfde van het belang van de directie dan kun je de aandacht van de hoofddirectie missen.

NA: Wordt die aandacht gemist of kan hij gemist worden? RM: Nee ik vind niet dat hij gemist kan worden, dan mis je hem echt pijnlijk zeg maar.

Nee dat zeker niet, maar dat zie je wel. Bij Nuon bijvoorbeeld de Raad van Bestuur. Die hadden er geen oren naar en die investeerde het niet. En het kan natuurlijk ook andersom, dat wij zeiden ik heb hier een architectuur een nieuwe manier bedacht om de processen te doen, systeem ingevoerd, en daar is een afdeling die zegt dat deze architectuur niet past in de grote plannen en de richting die wij op gaan. Dus het mag niet. Nou, naar buiten toe zeggen we jammer. En intern zeggen ze we hebben toch nog drie miljoen daar kopen we wel onze eigen systemen en computers voor. Daar hebben ze gewoon de hele mikmak in een kamer geïnstalleerd, in hun eigen gebouw in feiten. En pas anderhalf jaar later gaat dat ding stuk. En dan zit daar iemand en die denkt daar hebben we een helpdesk nummer voor en die belt de algemene helpdesk van de Nuon en die zegt hij doet het niet. Die ander zegt wat is het type nummer, waarop die ander reageert met: “die hebben we helemaal niet”. Nou wat gebeurt er dan, dan zegt die IT baas wat zijn dat voor een ploerten en die staat daar bij de afdelingschef en die zegt van stout geweest en die afdeling zegt: “ik zou zoveel miljoen nieuw verkopen en daar zijn we goed mee onderweg maar dankzij dit systeem. Wil je door of wil stoppen?” Dan zegt de directie neem hem maar gewoon in onderhoud.

NA: Zou dit opgelost kunnen worden door vanaf moment een iemand op de hoogste

niveau te betrekken bij dergelijke projecten? RM: Ja, ik bedoel, had men op dat moment gezegd: waarom is dit systeem zo goed voor

jou, wat zijn daarvan de dingen die jij zo hard nodig hebt en kunnen wij dan niet met een ander pakket of zelfgemaakt binnen de architectuur de reële eisen toekomen? Maar goed dat was wel typisch van de ivorentoren van IT bij Nuon. Zij waren niet dienstbaar.

NA: Maar dat is dan eigenlijk nog een soort vijfde variabele. De interne gelijk

stemmigheid? RM: Ja, de common purpose van een bedrijf zeg maar. Maar goed die is er bij dat soort

bedrijven ook gewoon niet. Als jij bij shell benzine stations en bij shell de olieboringen vraagt van joh wat zijn jullie doelstellingen dan krijg je een totaal ander verhaal. Ziggo doet kabeltelevisie maar ook mobiele telefoons tegenwoordig. Dat is overgenomen en zijn bij elkaar gekomen met totaal andere doelen. De directie kan

88

dan nog wel totaal nieuwe doelstellingen schrijven maar daar hebben ze niets mee te maken weet je wel. Als je die visies hebt heb je meestal de zaken niet zonder reden opgedeeld en moet je dus ook een beetje toestaan dat die divisies binnen een… Neem KPN als beleid voor de hele firma eggen ze KPN verbind. Dat is natuurlijk een makkelijke term en elke divisie kan dan bedenken hoe ze daar invulling aan geven. Zeg maar en daar dan best wel uiteenlopende doelstelling voor nemen. Aan de ene kant kan je zeggen dat hoort niet maar ik vind daarvoor deel je een bedrijf in divisies op. Omdat ze te verschillend zijn.

NA: Maar daardoor gaan bedrijfs-brede projecten wel meestal de mist in. RM: Zeker als bedrijfs-brede projecten weer over divisies heen dienen te functioneren.

Als die architectuur anders moet zijn voor andere divisies. Vaak is het daarom dan ook vaak beter een deel van je IT op te delen naar de divisies toe en dat zie je ook wel veel gebeuren.

NA: Is dat waar u ook op doelde met uw opmerking aan het begin van dit gesprek: dat

ERP niet de beste oplossing is? RM: Nee, weet je ook SAP hoef je niet in zijn geheel in te voeren. Maar dat zullen de

verkopers je van te voren niet vertellen. Ook al is dat nog wel eens een punt dat ik meestal wordt ingehuurd als het pakket al gekocht is. Dus oké, we hebben besloten voor SAP en vervolgens moeten we even zorgen voor een team die het in gaat voeren. Maarja, dan zit je dus al met een eventuele verkeerde keuze want die handtekening is al gezet. En dan is het ook vaak in izjn geheel gekocht met alle modules die voor het bedrijf van toepassing zijn. Laat dat maar aan die accountmanagers over, SAP heeft zo’n beetje de beste op de wereld rondlopen want die krijgen een commissie dat wil je niet weten. Dus dan hebben ze alles en dan zeg je ik zou misschien de SAP boekhouding, de SAP planning willen hebben, maar ik zou misschien wel PeopleSoftWare HRM willen hebben want jullie doen bijzondere dingen met het cafetaria systeem, of ik zou voor de sales wel iets anders willen hebben, want die zijn vreemd ingedeeld over de wereld enzovoorts en dan hebben we tegenwoordig de enterprise servicebus; de digitaal postsysteem waar al die pakketten met elkaar moeten kunnen praten en gegevens kunnen opvragen. Dus ik kan nu veel makkelijker veel merken systemen aan elkaar koppelen. Dat zou dan veel slimmer zijn. Qua architectuur alles moet praten met zo’n servicebus en alle software pakketten die we kopen die kunnen we met alle andere koppelen want die zijn standaard voorgeschreven en vervolgens kunnen we dan per divisie, per afdeling of wat dan ook kijken van wat is nu voor jullie het beste. Wel binnen de grenzen dat de pakketten die je dan bekijkt dat die dan moeten kunnen werken met die service bussen. Dan heb je de voordelen van alles gekoppeld en de gegevens allemaal maar een keer, maar je omzeild de nadelen van het hele keurslijf van een groot systeem waar alles statisch dient ingevoerd moet worden. Goed voorbeeld vind ik altijd Sisqo die op zich wel SAP gebruikt maar die zeiden vooral uitblinken op het gebied uitblinken in customer service, bij de verkoop. Daar hebben ze zo’n systeem voor gemaakt dat de klant zijn eigen orders kan verschuiven in de planning maar daar moet hij dan wel punten voor inzetten en alles wat hij koopt krijgt hij punten voor. Dus als hij nou een keer denkt: “jeutje ik moet een netwerk uitbreiding hebben, maar normaal is er een grote levertijd voor die apparatuur. Ik was even vergeten dat ik dat nodig had, of de groei gaat heel snel en daar hadden we niet op gerekend.”. Als je dan weet dat je de afgelopen drie jaar alles bij Sisqo hebt besteld, ik heb bergen punten dan kan ik er zo voor zorgen dat ik het volgende week al hebt. Daar is Sisqo als nieuwe starter, in tien jaar tijd marktleider in geworden. Niet dat iedereen zei ik heb die punten ook echt nodig, maar het is wel heel erg fijn ze te hebben. Wat internet kwam, en alles ging zo hard dat niemandmeer wist wat die markt ging doen.

89

En denk eens aan netflix ofzo. De ene dag hebben ze een website. Goh Netflix Nederland komt eraan en de volgende dag dan zijn er zestigduizend man lid geworden en staan te downloaden. Er zijn zoveel opportunities en zo veel netwerk apparatuur voor in gebruik hebt. Daar zijn dat soort bedrijven heel slim in geworden. Ze hebben dus wel SAP geïnstalleerd maar ook een hele hoop erom heen.

NA: Komt dat ook omdat ze van te voren heel duidelijk wisten wat en hoe ze dat proces

willen zien. U wordt vaak betrokken op het moment dat er al een pakket gekozen is, dat traject daarvoor hoe werkt dat.

RM: Daarvoor is heel komisch. Daar zitten meestal de echt top-consultancy bedrijven

voor binnen gehaald. Accenture en Berenschot, McKinsey, KPMG. Weet je de hele dure jongens, de driehonderd euro per uur jongens en die komen dan kijken wat er moet gebeuren en die zetten dan de grotere lijnen neer. Er zijn bedrijven die het nooit implementeren. Dat staat ook op hun website: wij doen geen implementaties alleen analyses. Zo zullen ze dus ook nog nooit ervaring opdoen over of iets succesvol is of niet. Ik blijf weer voorop staan, dat voorstukje doen. En elke keer als het mis gaat zeggen ze ja dje hebt het ook niet goed doorgevoerd. En ja dat blijft een vreemde wisselwerking.

NA: Ik begrijp dat er dus ook redelijk vaak sprake is van een mismatch tussen software en

bedrijf? RM: Dat weet je niet. Ik ben ook een keertje met CWI, een projectleider voor Werk.nl.

Toen heeft Berenschot gezegd zo moet het. En wij keken er een keer naar en zeiden we zo kan het niet. En de directie zei ja inderdaad je hebt gelijk. Dat kan niet. Nou die man van Berenschot nog eens laten komen: Ja ja inderdaad. We zitten een beetje te knoeien in de marge eigenlijk en zo begint ons plan. En dan denk ik van ja hallo. Jullie hebben gezegd van zo zou het moeten gebeuren en dan blijkt dat het aan alle kanten op losse schrijven staat. Nou dan maak je er wel wat van. Gek genoeg denk je: “die Berenschot zijn hartstikke stout geweest, die hebben geen goed plan opgeleverd”, maar die hebben het nog beter voor elkaar dan de ander want ze kunnen achteraf nooit meer bekijken of het plan succesvol was. Omdat het door hun bedachte plan nooit is uitgekomen. Dus. Rare dingen. Vaak worden die deals toch gemaakt op de golfbaan. De directie, dat had ik bij CWI ook. Ik stelde voor alles te laten testen en een audit te doen voor Sogiti en de directeur zegt ik heb al met KPMG afgesproken om het te testen. Uiteindelijk werd het Sogiti die alles ging testen en KPMG ging kijken of Sogiti alles wel goed had gedaan. Je moet goed politiek kunnen bedrijven.

NA: Nou goed, op een gegeven moment is het project klaar. Je geeft elkaar de hand en

dan: hoe wordt succes gemeten? RM: Allereerst maak ik dat moment eigenlijk niet mee. In feiten, ik ben een dure dus

meestal willen ze wel van je af op het moment dat ze wel denken dat ze van je afkunnen. En je hebt een hele verandering doorgevoerd en daarom heb je wel wat vijanden. Dan denken ze laten we die zondebok eruit gooien en dan kunnen zeggen laten we het nu leuk met elkaar oplossen. Dus dat is een soort standaard baan voor de consultant. Hij zet alle harde veranderingen door en omdat hij maar wordt ingehuurd en weer weggaat kan hij dat ook makkelijker doen. Dus dat hoor bij de rol. Dat maakt wel dat ik projecten niet helemaal tot het einde meemaak.

NA: Komt dat ook doordat u op het begin pas in een latere fase, na dat er een pakket is

gekozen. Dus dat je meer een soort tijdelijke doctor bent.

90

RM: Ja, en als ze dan gaan meten ben je er niet eens meer. Dat maakt dat ik later nog wel eens terug wil gaan en overleggen van he hoe succesvol was het nou allemaal. Maar dat ja daar wordt in feiten geen uitspraak over gedaan. Neem werk.nl, acht jaar later kwam er in de krant dat er iets mis ging en dat men niet zo tevreden was maar die tussentijd, ik heb geen idee. Je kan kijken hoe veel werkelozen je hebt. Maar dat ik niet aan het systeem, maar aan de conjunctuur. Net zo goed met elk bedrijf. Is het door het systeem? Door je niet zo’n goede product? Je reputatie heeft een klap opgelopen? Komt dat dan weer door het systeem. He de kleinere systemen, ik ga mijn systemen beter marketen maar als jij een systeem hebt wat je totale bedrijf opnieuw doet, wat ga je dan meten. Dan ben je al blij als het bedrijf op dezelfde manier door kan draaien. Door veranderingen door te maken doet het toch altijd wel pijn en nu is het even minder. Maar ik moet het bedrijf nog zien die zegt: “we doen dit omdat we weet ik veel dertig procent meer willen groeien. En hebben we dat dan ook gehaald.” Die groei haal je niet uit het systeem. Het systeem ondersteunt die handeling beter dat die die groei kan maken weet je. Het is een ondersteuning van een business die de groet moet maken. Dus het enige wat je echt kunt meten is hoeveel tijd heb je aan die implementatie besteed en hoelang duurt het oordat de juiste informatie bij de juiste persoon is. Operationele gegevens kunnen dus sneller. Transacties, en hoe snel kan je je er over rapporteren.

NA: Dat gaat echter wel meer over het succes dat het bedrijf ervaart van een nieuw

systeem. RM: Bij een ERP systeem gaat daar toch wel een beetje over hoe het succes is. Ik bedoel

wat heb je voor je. Een ERP systeem en een verkoopsysteem en een personeelszaken systeem en als een verkoper een nieuwe klant heeft typt hij hem in zijn nieuwe CRM pakket nou dan heeft hij een nieuwe klant als het dan een order wordt dan moet de boekhouding een klantnummer intypen, en als je dan wilt weten voor welk deel van de omzet is die klant nou verantwoordelijk, dan moeten die klanten gematched worden. Nou voer je SAP in dan heb je het in een klanten bestand. En die gegevens heb je binnen een druk op de knop. Je bent dan dus veel sneller. Je hebt ook betere integriteit van de cijfers die je daarmee oplevert. Ja. Wat is dat waard. Ik was niet te lang geleden op een grote scheepswerf in Schiedam. Die bouwen boorinstallaties voor op een schip. Huijsman. Grote tent, prachtig. Die man zegt ik krijg uit mijn systeem een cijfer en die zegt hoeveel dagen ik er over doe om een offerte te maken. Maar als ik op de druk ni het systeem krijg ik een cijfer van min zeventienhonderd dertig dagen. Dat klopt niet. Dat is dan geen ERP pakket maar allemaal losse systemen die aan elkaar zijn geknoopt. Daar heb ik dus geen zak aan en bedenk ik het zelf. Daardoor kan hij dus trager reageren op klanten wat weer business kost.

Transcript interviewee 4 NA: Interviewer FT: Interviewee (Interview is in Dutch) NA: Wat is uw specialiteit? Ik zal op Linked-In wat staan, niet al te uitgebreid. FT: Mijn specialiteit? Kan je mijn profile überhaupt zien op Linked-In? NA: Ja uw naam en JD Edwards specialiteit was zichtbaar.

91

FT: Ja inderdaad, dat is mijn specialiteit. Ik ben een Oracle JD Edwards senior

consultant. NA: Ok. FT: Mijn specialisme ligt in de logistiek en in de productie. NA: In die functionele omgeving ben u gespecialiseerd dus. FT: Ja inderdaad, NA: En bent u zelf ook werkzaam geweest binnen deze sector? FT: Ja daar kom ik wel vandaan. Ik ben niet begonnen in de IT. Ik ben er op een gegeven

moment mobiles manager geweest bij een bedrijf, ik heb me bezig gehouden met de planning daar ook van. Van de inkoop en van de productie en zo ben ik er ingerold. Op een gegeven moment kwam er en project langs, en ERP project. Dat ging om een selectietraject en implementatie project en toen het project was afgelopen liepen er en hoop mensen weg, waaronder Marcel. Het werk ben ik blijven doen. Ik ben toen overgestapt naar toentertijd Getronics en ik heb me bezig gehouden met implementaties en projecten.

NA: Ok. En Marcel komt ook daar vandaan? FT: Ja die komt van dezelfde club. NA: Ok dit is het model. Vanuit literatuur heb ik dit model gebouwd. Er zitten drie

variabelen in; consultation role, competence of consultant en client-organizational characteristics die alle drie bijdragen aan het management consultancy succes. Met de eerste variabele bedoel ik de rollen die een consultancy bureau aan kan nemen. Daarbij heb ik vier verschillende rollen onderscheidde: Business analist; houd overzicht, planning, de meest hooggeplaatste in de hiërarchie. Daarnaast een project manager; die ik als administratieve schakel tussen de consultant en de klant organisatie is.

FT: Ik ben het daar helemaal mee eens. Zelf denken zee r anders over maar ik ben het

hier mee eens. Het is grappig om dit zo te zien. Hij speelt wel een hele belangrijke rol en bijdrage aan het succes. Maar de business analyst zou ik inderdaad bovenaan zetten qua belang voor het succes uiteindelijk van het project.

NA: Omdat hij een wat meer technische achtergrond heeft? FT: Ja. De business analyst niet zo zeer, niet alleen technisch maar die legt in mijn optiek

en ervaring legt, is die in staat om te denken en te begrijpen wat de klant zijn business processen zijn. En te begrijpen wat de mogelijkheden en best-practises zijn van de software. Als het goed is heeft hij beide competenties in zijn mars. De business competencies als de kennis van de software. Het ERP systeem. [Waar je als project manager, gechargeerd gezegd, iedereen kan zijn als die maar een tijdlijn kan beheren. ] Ja. Als die maar een beetje met MS Project om kan gaan, en een beetje met mensen kan omgaan, hoewel het in mijn ervaring in ik denk een SAP project heb ik nooit gedaan maar daar zal het ietsje anders zijn dan JD Edwards. In mijn ervaring is het wel zo dat een project manager met verstand van software zelf, is wel een plus als succesfactor. Je kan toch wel beter zaken afwegen en weet beter de juiste beslissingen te nemen. [Dat is dan een vaardigheid die een project manager…] Helpt

92

wel. Helpt wel. Ik heb wel eens voor een wat groter consultancy bedrijf gewerkt. Die werken met j project managers die uit een centrale pot van projectmanagers, je krijgt er eentje toegewezen. Maar het ene project is het andere project niet. Een grote ERP implementatie in de food0industry is echt iets heel anders als een technische implementatie bij een middenstandsbedrijf.

NA: [Daarnaast heb ik de systeem architect en technische consultant onderscheidde waar

ik de systeem architect aanschrijf als iemand die de vereiste van het systeem bekijkt en vervolgens daar software modules aanhangt en die match en een technologie consultant een programmeur eigenlijk. Iemand die wat meer schrijft, de codekrassers. Hoe zou je deze verdeling beoordelen en zijn er nog rollen die absoluut ontbreken?

FT: Als je het hebt over een ERP systeem, dan heb je het eigenlijk voornamelijk over

configureren. Dat kost ook het meeste werk en meeste tijd. Gaat wel zitten in de customazations die toch nodig zijn. Maar ik zou zeggen er kan wel het een en ander aan overlap zijn. Een business naalyst zal misschien ook wel systeem architect zijn. Hij zal ook wel functional designs maken voor customazations. En de technology consultants is meestal wel een eigen wereld. Dat zijn wel vaak mensen die de software heel goed kennen enn die in staat zijn zelf te codering en eigen functional designs te schrijven. Project manager is ook wel een helder beroep. Systeem architect kan overlappen.

NA: Het kan dus fysiek dezelfde persoon zijn waar taken nog wel eens in melkaar

overlopen? FT: Ja. NA: Ok duidelijk. Vervolgens is er ook een rol binnen een ERP implementatie die

duidelijk het belangrijkst of minst belangrijk is. FT: Voor mij is duidelijk, dat de grootste moeilijkheden niet zo zeer het configureren van

de softweare, maar die anaylse van welke processen hebben jullie nou. En hoe past nou die standaard JD Edwards functionaliteit in jullie business processen, en welke modules ga je gebruiken, hoe ga je ze inzetten en waar ga je customazations maken? Dat is het moeilijkste. Als je hieromtrent de goede beslissingen neemt Dan krijg je een succesvol project. Maar dat is heel moeilijk want je hebt als externe heb je kennis van die software als het goed is. Je hebt enigszins kennis van business proces in het algemeen maar je hebt niet de kennis in huis van de bedrijfsspecifieke processen en het is heel, afhankelijk van de klant, de een snapt, zijn veel beter op de hoogte van hun eigen processen dan de andere maar het kan heel lastig en moeilijk zijn om daar de waarheid boven tafel te krijgen.

NA: Is het dan een combinatie tussen de snelheid en vaardigheid van de business analist

tussen de processen van haar klant opslaat en kent in combinatie met de mate van bewust. De mate waarin een klantorganisatie bewust is van haar processen. En die vertaling naar ERP.

FT: Ja. Dat de juiste mensen daar met elkaar aan tafel komen we te zitten. De juiste

kennis, de juiste motivatie, juiste samenwerking, juiste atmosfeer zodat de basisgoed gelegd kan worden. Want zij zijn er zes jaar me bezig. En die analyse kan een consultant nooit in zijn eentje. En andersom ook niet. De kwaliteit van beide bepaald heel erg de kwaliteit van het project. Want alle problemen liggen in mijn ervaring altijd op die customazations.

93

NA: Of die op de juiste plek zitten? FT: Ja.. Of die inderdaad het systeem ondersteunen zoals dat nodig is. NA: Begrijp ik daar ook uit dat de technology consultant die we zoeven al benoemde,

minder belangrijk is. FT: Ja. Vooral bij ERP systemen veel minder belangrijk. Dat is er inderdaad eentje die je

uit een pool kunt trekken. Dat werk kan je goed in India of Zuid-Afrika laten doen. De analyse dat is waar de fouten of de goede dingen ontstaan.

NA: Duidelijk. Vervolgens heb ik vaardigheden van externe op een rij gezet en eigenlijk

kwam ik met vier vaardigheden die ik als belangrijk achtte. De mate van technische vaardigheden. Daarin bedoel ik eigenlijk productkennis van de verschillende ERP modules. Mate van ervaring die een consultant heeft, dus in hoeverre heeft hij meerdere projecten gedraaid ja of nee. Communicatieve vaardigheden. Daar bedoel ik mee, vaardigheden rondom bedrijfsspecifieke communicatie Zoals we net al zeiden, jij bent dan van een logistieke productie achtergrond en je spreekt daardoor enigszins dezelfde taal als… En dan als vierde eigenlijk soft skills. In hoeverre ben je in staat goed met mensen om te gaan.

FT: Ja. Ben je in staat jou ideeën over te brengen, ben je in staat om een informatie uit

mensen te krijgen. Om alles boven tafel te krijgen. Dan zijn echte soft skills. NA: Aha, in mijn ogen zou dit ‘bevragen van’ zou nog wel als vijfde variabele kunnen

gelden. FT: Ja die soft skills zitten nog wel wat dimensies aan he. Daar zit in het pushen, maar

daar zit ook van het luistern ook. Het is vaak gezegd maar als consultant moet je niet alleen maar kunnen vertellen. En in de analyse fase moet je juist ook goed kunnen luisteren. Je moet ook vaak echt wel doorvragen. Er zijn geen enkele vragen die je zomaar met ja of nee beantwoord. Je moet echt op zoek gaan, graven, doorgraven, op een andere manier vragen, je moet aan andere groepen van mensen vragen om uiteindelijk de waarheid boven tafel te krijgen. Ik beschouw dat wel als een softskill. Het is echter wel een andere als je eenmaal een bepaald idee hebt. Vervolgens moet je de ideeen die je hebt vernomen aan de hand van goed te luisteren weer terugpushen over de bune krijgen zodat mensen dat ook gaan volgen.

NA: Ik zou dat zeker als twee verschillende variabele willen aanmerken. FT: Ja, dat zou heel goed kunnen maar beide zijn binnen die analyse fase net zo

belangrijk. NA: En de mate van productkennis, is dat ook belangrijk? Als we een rijtje zouden maken

van deze vier a vijf variabelen, welke zou er in belangrijkheid dan boven aanstaan? En waarom juist die bovenaan.

FT: Ja. Ik kijk naar mijn eigen verhaal en ik heb wel werkt met de business consultants

van XXX of Accenture en dan zat ik daar als pakket-specialist. Als pakketboer zeg maar oneerbiedig. Dus zij hadden de kennis van de business processen maar geen enkele kennis van de applicaties. Van in mijn geval dan JD Edwards, en ik zat er als JD Edwards man. Ik moest me mond houden over business processen. Ik heb een aantal van dit soort projecten wel meegemaakt en dat waren over het algemeen geen succesvolle projecten. In mijn wereld, met mijn projecten en mijn ervaring zegt mij dat de sterkste eigenschap is dat je over elkaars muren kunt kijken, dat je kennis hebt

94

van zowel de software, dat je weet hoe dat ding in elkaar zit, dat je iets meer weet dan een volgelezer, en dat je de businessprocessen kent. Voor mij is juist die combinatie in een analyse fase essentieel.

NA: Ik hoor ook dat de analyse fase cruciaal is. FT: Voor mij is dat absoluut de fase dat als je daar goede beslissingen neemt, dat je een

goed project in gaat. Dan ga je het halen. NA: Onder het mom: een goed begin is het halve werkt. FT: [Onder het mom: een goed begin is het halve werkt?] Ja echt wel, echt wel. Dat is

echt het fundament en is daarna een kwestie van invullen. Een goede project manager kiezen een mooie gant-chart maken enzovoorts. Als die analyse fase fout is kom je er pas veel later in het project erachter en dan kost het veel meer tijd en inspanning.

NA: En dat zal dan wellicht ook meer weerstand oproepen als verkeerde software op

verkeerde afdelingen wordt geplakt? FT: Ja, op een gegeven moment kom je erachter dat je aan een dood paard aan het

trekken bent. Daar gaat dan heel veel inspanning in zitten. … FT: Als je vraag welke fase het meest belangrijk is geen ik absoluut de analyse fase.

Kwaliteit daarvan is bepalend. Daar moet je niet bezuinigen op tijd en consultants. NA: Heel duidelijk. Vervolgens omdat het toch een tweestrijd is tussen klant en adviseur.

Daarom zijn er ook karakteristieken van de klant die al dan niet bijdrage aan de het al dan niet succes. Ik heb de volgende vier eigenschappen geïdentificeerd. In hoeverre is een klant vertrouwd met haar externe? Heeft ze er een goed gevoel bij.

FT: De relatie is heel belangrijk he. NA: Ja en ook of er een persoonlijk klik is tussen de consultant. FT: Ja. Ik heb een collega ook wel eens horen zeggen dat voor zijn functie het

allerbelangrijkste is de relatie die hij met zijn, niet eens zozeer met de klants managers, maar gewoon met de key-users onderhoud. Op het moment dat hij dat goed heeft, dan gaat het lukken. Als dat niet voor elkaar komt, dan wordt het heel erg lastig. En die key-users hebben over het algemeen het vertrouwen van de managers. Daarnaast als het goed is, als het goede mensen zijn, hebben ze een bepaalde goodwill binnen het bedrijf. Als je je daarbij niet goed aansluit, als daar geen vertrouwen is, dan gaat het bij de process-owners ook niet goed.

NA: In hoeverre, is ook zeg maar intern mandaat van belang? Ik heb wel gelezen dat je

vaak ziet dat er bij de key-users veel bereidheid is om te veranderen, echter in de directiekamer wordt het project niet aangemerkt als strategisch.

FT: Ja zeker. Inderdaad als de key users, degene die de hele dag in het project

meedraaien en die mee doen met alle beslissingen. Je begint zon project in een analyse fase en dan komt er een mooi document die zegt zo gaan we het doen. Daarna gaan we dan de implementatie doen. Maar dan zijn er nog een heleboel kleinere of niet zo veel kleinere beslissingen die genomen moeten worden. Als de

95

mensen die in het project zitten daar niet aan mee kunnen doen, als die om de havenklap terug gefloten kunnen worden door managers op hogere niveaus dan haal je de vaart uit zo’n project, en ik heb het ook wel meegemaakt maar dan kan zo’n project zomaar exploderen. Zomaar drie keer zolang als dat er eigenlijk nodig zou zijn.

NA: Met terugfluiten bedoel je dat ze geen tijd krijgen? FT: Nee daar bedoel ik mee dat beslissingen die zij nemen worden teruggedraaid. Dit

gaan we niet zo doen op deze manier. Want op het moment als je bezig bent met zo’n project. Die neem je en die moet je snel nemen, want je hebt niet altijd de tijd om alles af te wegen en ruggenspraak te houden. Dus je moet die beslissingen nemen. En op basis van die beslissingen worden weer andere beslissingen over genomen. En daardoor wordt misschien ook wel customazation uitgevoerd op basis van die beslissingen. Ja als je dan vervolgens ergens met terugwerkende kracht besluit om het toch anders te doen. Dan betekent dat je moet gaan her-bedenken wat er allemaal op basis van die beslissingen in gebeurt.

NA: Heel simpel, je staat t werk gewoon twee keer te doen en ten tweede het aanzien van

het project zal dalen? FT: Nou ja zeker, het aanzien komt onder druk te staan. Dat is in beweging. Dus zodra

we bepaalde beslissingen genomen moeten worden, gaan andere op die beslissing weer hun inrichtingen doen of customazations et cetera. Dus inderdaad dat mandaat wat je doet, dat is killing als je een situatie hebt waarbij je werkt met mensen die geen mandaat hebben.

NA: En doe je dan ook daar, wederom gechargeerd gezegd, als je het idee hebt dat er

vooraf niet genoeg aandacht voor is. Dus dat er vanboven af simpelweg niet genoeg aandacht voor het project is.

FT: Als consultant probeer je meer aandacht te krijgen. Dat lukt niet altijd. Dan hangt het

er toch een beetje van af van hoe de contracten liggen, hoe is het project aangevlogen. Als het een fixed-price afspraak is zal er meer druk zijn vanuit de consultancy hoek. Het kan natuurlijk ook altijd pas later duidelijk worden dat er te weinig mandaat is.

NA: Want het zou nog wel eens voordelig kunnen zijn om het project een beetje door te

laten sukkelen. FT: Ja, zo wil ik het niet zeggen maar.. NA: Dat er minder urgentie is? FT: Ja. Dat is andersom natuurlijk ook, bij een fixed price heeft de klant veel minder

urgentie om hier snel wat aan de gaan doen. NA: Ja. FT: In dat opzicht werkt het twee kanten op. NA: Duidelijk. Vervolgens de manier waarop een klant naja haar toch een nieuwe

werkwijze oppakt. En haar absorberende capaciteit. FT: Veranderd nog wel eens. Change management, heel natuurlijk een hele grote rol.

96

NA: En dit sluit ook aan bij de motivatie. FT: Ja. In hoeverre willen ze. Over het algemeen de mensen die in het project zitten die

raken wel enthousiast. Maar het is wel een uitdagen om dat enthousiasme op de rest van de organisatie over te brengen.

NA: Ligt die verantwoordelijkheid bij de klant of bij de adviseur. FT: De verantwoordelijkheid moet toch altijd wel bij de klant liggen. Dat is toch wel echt

een hele andere tak van consultancy dan waar ik in zit. Natuurlijk kan je proberen het uit te besteedde maar dat zit dichter bij de klant. Verantwoordelijkheid ja. Wij kunnen er natuurlijk wel een rol in spelen he.

NA: Uiteindelijk worden de adviseurs natuurlijk ook wel afgerekend op hetgeen... FT: Ja het is dus ook in ons belang om dat wel voor elkaar te krijgen. NA: En vooraf wordt het aangestipt als verantwoordelijkheid van de klant. FT: Ja, over het algemeen wel. NA: Dit is eigenlijk het zelfde. In hoeverre begrijp de klantorganisatie de consultant. Is er

een klik. Is er een persoonlijk verbond? FT: Ja, bij voorkeur wel. Het is zeker iets waar je altijd naar moet streven als consultant,

het is niet iets wat altijd lukt. NA: En onderneem je daar concreet acties voor? Ga je op zoek naar een persoon met een

bepaald profiel, die meestal… Ik kan me voorstellen dat je altijd op zoek gaat naar iemand op die positie met zo’n uitstraling zeg maar.

FT: Nee. Ik hoop wel dat het wel zo gebeurt maar het is meestal het bedrijf zelf dat komt

met zijn key-users en process owners. En persoonlijk zou ik eigenlijk zeggen als je een project binnengaat dan is het vaak zo dat de klant zegt van he die wil de consultants ook zien, en beslissen van wel of niet. En eigenlijk zou het andersom ook moeten. Eigenlijk zouden we wat meer, maar dat gebeurt niet zo in mijn ervaring. De consultants worden alleen maar doorgelicht, maar niet andersom. Je hebt wel eens projecten waar er wel een soort waardering komt. Dan krijg je maandelijks of tweemaandelijks de vraag wat vin d je van de performance van de key-user.

NA: Vragen of je mede/tegenstander bij de klant. FT: Ja. Maar dat werkt natuurlijk niet he. Dan zeg je dat het een waardeloze vent is en

vervolgens moet je nog anderhalf jaar samenwerken met hem. Dat is gewoon verspilde energie.

NA: Vervolgens, aan het einde van het project geef je elkaar de hand, bij een GO-LIVE. FT: Ja GO-LIVE en dan nog een stressvolle periode met de support van de after go live

problemen. NA: Wanneer is typisch het moment dat er geëvalueerd en beoordeeld wordt?

97

FT: Dat is normaal gesproken tussen de twee en vier maanden na een GO LIVE. Dat is het moment van het stof van de kwaliteit van de oplevering begint te dalen en men begint zicht te krijgen op het systeem en waar mensen vaak de controle in handen hebben.

NA: En hoe bepaal je de mate waarin je succesvol bent geweest tijdens een project? FT: Dat is geen makkelijke vraag. Omdat je zo geleefd wordt, in die fase ben je alleen

maar met problemen bezig. Onvoorziene fouten. Dan komen de problemen boven. Dit zijn altijd de urgente problemen aangezien het in een live omgeving plaatsvind. Hoe bepaal je of het succesvol was?

NA: Gebeurt dan wellicht op basis van harde kerncijfers, of gebeurt dat eigenlijk niet? FT: Eigenlijk zou dat moeten he. Voordat je zo’n project ingaat zou je een aantal

kerncijfers moeten vaststellen en daar wil ik op meten en wat zou het moeten zijn. Maar in de praktijk zie ik dat toch vaak niet. Ik ben het er volkomen mee eens maar ik zie het in de praktijk toch vaak niet. Weet je een ERP systeem is uiteindelijk gewoon een transactie systeem. Het verbetert niet altijd je processen. Het verbeterd de eenduidigheid, het verbeterd het inzicht, financieel heb je een beter inzicht met ERP. Er zijn wel een aantal zaken die beter worden. De maandrapportage zou waarschijnlijk sneller kunnen, dat kan je waarschijnlijk wel makkelijk meten. Maar het is niet zoiets als een ‘advanced scheduling systeem’ waarbij je zegt mijn voorraden gaan met 40% omlaag, en me service gaat met zoveel procent omhoog. Als je dat al doet zijn dat cijfers niet vaak toch niet de eerste maanden na zo’n ERP implementatie zichtbaar worden. Dat laar zich echt pas later zien.

NA: En wat betreft persoonlijk gevoel? Ik kan me voorstellen dat je elkaar na een project

een hand geeft maar dat wel eens op andere manieren gebeurt dan tijdens andere projecten.

FT: Tot nu toe zijn mijn projecten eigenlijk altijd wel in een goede verstandhouding

geweest. Ik heb mijn persoonlijke mening of over een prject geslaagd is. Dat komt er eigenlijk op neer of wat we hebben opgeleverd of dat past bij het type organisatie. Die Organisatie kende ik voorheen natuurlijk niet. Die kende ik pas achteraf. Je kan niet vanuit het stenentijdperk naar de eenentwintigste eeuw. Een bedrijf moet een oplossing hebben die een of twee ptappen verder brengt. Maar je moet niet proberen wat de boekhouding doet op de achterkant van een sigarenkistje, naar een volledig geautomatiseerde functionaliteit transformeren. Want dat krijg je toch niet voor elkaar. Vaak worden projecten ingegaan met enige positivisme. Als je daaraan wilt afmeten valt het wel eens tegen.

NA: Vanuit een bedrijfsperspectief? FT: Vanuit een bedrijfsperspectief valt het wel eens tegen. Als je het bekijkt vanuit een

oogpunt waar het bedrijf stond, dat vind ik een eerlijkere… persoonlijk is dat he. Dat is niet waar ik het bedrijf van kan overtuigen.

NA: Beste raar eigenlijk nietwaar? FT: Ja, je gaat toch projecten in waarvan de klant bepaalde verwachtingen hebt. Je kent

vast wel zo’n plaatje van een boom en een schommel. Een beeld van wat een klant voor ogen had en een plaatje van wat het uiteindelijk is geworden. De verwachtingen zijn soms wat hooggespannen.

98

NA: Is het daarom ook niet min of meer een bewuste keuze om achteraf niet te scoren met elkaar. Te bepalen wat de score van de implementatie was, omdat het toch altijd wel tegenvalt.

FT: Ik zeg niet altijd he. Wij leveren ook wel op wat er van ons verwacht wordt. Mijn

voorlaatste project werd uiteindelijk door de klant beschouwd als een absoluut succes. Waarom? Omdat we de functionaliteit hadden geleverd, binnen de tijd waarin het moest gebeuren. En dat klopt ook wel met mijn mening, maar de verwachtingen waren ook reëel. Reële verwachtingen. Geen onrealistische verwachtingen. Een ander project heb ik onlangs gedaan, waar de verwachtingen ridicuul waren, ik wist dit niet voordat ik er aan begon. Maar toen kende ik de organisatie nog niet zoals ik die nu ken. En die hebben verreweg niet gehaald wat ze hebben verwacht. Maar ze zijn wel een of twee stappen verder gekomen. Persoonlijk zeg ik nu, veel meer dan ze nu hebben gekregen hadden ze niet gekregen. Dus bij mij leefde wel enige tevredenheid.

NA: Speelt geld ook nog een rol eigenlijk dan? In de zin van na de OG LIVE moet nog

heel veel aangepast worden. Heel veel fouten die uit het systeem gehaald moeten worden. Dat zijn uren die betaald moeten worden.

FT: Ook een spanningsveld he. Als dat het geval is dat er vrij veel geld mee gemoeid

gaat dan komt daar wat druk op. De klant wil dat niet betalen, de leverancier consultancy ook niet, dan wordt er over het algemeen wat onderhandeld. En als er een goede relatie is moeten ze daar wel uitkomen.

NA: En de nazorg contracten, beheer eigenlijk. In hoeverre kunnen klanten deze

beheercontracten ook bij andere partijen afnemen of maak je ze afhankelijk van jou organisatie.

FT: Het kan wel, alleen als het heel goed gedocumenteerd wordt allemaal. Alleen dan

kan je naar een andere partij. Een goede documentatie is nog niet zo eenvoudig. Wie gaat die maken bijvoorbeeld, de klant of de consultant? Maar een goede documentatie is daar wel een belangrijke factor is.

NA: Eigenlijk is het een beland van de consultant om die documentatie niet te verzorgen

zodat ze achteraf… FT: Zo zou je dat kunnen zeggen maar zo ben ik dat niet tegengekomen. NA: Dat zou vervolgens ook geen afbreuk doen aan de kwaliteit van het pakket. FT: Documentatie, scoofies kwadrantie. Je hebt belangrijke zaken en urgente zaken en

documentatie is wel ook belangrijk maar nooit urgent. En dus komt het vaak in het, ja het wordt steeds achteruit geschoven. Ik denk dat dat meer een rol speelt in de afwezigheid van documentatie dan echt bewust niet opstellen van documenten. Nee dat denk ik niet want het versterk ook niet je positie. Als je geen goede documentatie oplevert heb je je werk ook gewoon niet gedaan.

NA: Ok, en mocht er nadien een contract komen waarin jullie het beheer voor je rekening

mag nemen betekent dat dat er goed is gehandeld en is dus een criteria vor succes? FT: Ja dat zou ik wel zeggen. Ik vind goede documentatie wel belangrijk. En als je het

dan makkelijk kunt uitbesteedde betekend dat je het gewoon goed hebt gedocumenteerd.

99

NA: Ja, ja. Als je het dus kunt overgeven naar een andere partij, en die reden kan zijn dat ze geen positieve ervaring hebben gehad in het eerste huren daar. Of is het meer andersom?

FT: Er is wel een verschil tussen bedrijven. NA: Duidelijk. Ik denk dat we het meeste wel hebben besproken. FT: Ik hoop dat je er iets aan hebt. Ik doe het nu al een aardig tijdje. Ik werk hier nu

vijftien jaar hier en ik denk dat ik het nog tien jaar ga doen. NA: Dank u wel. Transcript interviewee 5 NA: Interviewer HB: Interviewee (Interview is in Dutch) NA: Ik wil het model dat ik aan het onderzoeken ben nalopen en jou over elke van de vier

variabelen individueel nog eens langsgaan en u bevragen hoe deze bijdrage aan management consultancy succes.

Om te beginnen wil ik ingaan op consultantion modes waarmee ik de verschillende specifieke rollen van een ERP consultancy organisatie mee bedoel. Vanuit de literatuur heb ik de in mijn ogen vier belangrijkste consultancy rollen geïdentificeerd. Deze staan hier opgesomd en ik wil je vragen of je deze herkent en hoe jullie daar invullen aan geven.

HB: Wij werken met de MS surestep aanpak. Dus dat is de implementatiemethodologie

die MS bedacht heeft. Wij hebben daar wel een paar varianten op gemaakt. Maar dat is even de basis waarop wij projecten aanvliegen.

NA: Die hebben heel duidelijk zeven rollen geïdentificeerd correct? HB: Ja, ik kan ze wel even opzoeken. Ehm, maar daar zit een hele duidelijke analyse fase

in. Wij hebben zoals wij dat noemen een A&D fase. Analyse en design. Daarbij hoort eerst de diagnose fase zeg maar. En op een gegeven moment het met elkaar eens bent van nou dit willen we hebben. Zeg maar de vraag die zij hebben matchen aan wat er in het systeem zit. Dan kom je op een design. Dan gaan we zeggen zo zou het volgens ons moeten werken, klopt dat? En dan ga je over naar de development fase. Dus dan gaan we echt het systeem inrichten, configureren en maatwerk maken als dat echt nodig is. Dus dat zijn de.. Ik kan het wel even naar je toesturen sowieso maar dat is de opzet van de aanpak.

NA: Is deze methode, aangezien jullie een partner zijn van MS ook opgelegd of… HB: Nee. Nee wij hebben eigenlijk jarenlang onze eigen aanpak gehad maar in onze… NA: Horen bij de rollen zoals hier beschreven ook fysieke personen of HB: Hier is het een beetje te klein allemaal. Even zoeken op een grotere afbeelding.

100

Je ziet hier de rollen. Die hebben wij voor een heel groot deel ook. Hier de project manager, die hebben wij ook. De engagement manager, die hebben wij niet echt. Je ziet nog wel eens dat de overdracht van een prject bij ons door een project manager gedaan. Applicatie consultant. Wij hebben de technische consultants en ontwikkelaars, en development consultants noemen zij dat hier. Dat zijn de verschillende rollen die wij hanteren.

NA: Die zitten ook allemaal op verschillende mensen? HB: Ja dat klopt. Dus je hebt functionele mensen, technische mensen. Je hebt ook

grensvlakken. Development mensen zijn echt de code krassers, de mensen die echt maatwerk maken of hele specifieke functionaliteit ontwikkelen. En je hebt technische consultants en die zitten vaak op performance, sizing tuning.

NA: Die schrijven niet zo zeer nieuwe software. HB: Nee, die zorgen ervoor dat hoe moet je communiceren met de cloud. Je hebt een

applicatielandschap en een CRM systeem en dat werkt in de cloud en je hebt een ERP systeem en dat staat bij jzelf in huis. Op premisses noemen ze dat. Ja hoe ga je dan met elkaar praten.

NA: Bij XXX noemen ze zo iemand een infra-consultant. HB: Ja. Bij ons heet dat een technische consultant. Infrastructurele vraagstukken hoe ga je

daar nou mee om. NA: Ok. HB: De rollen die je hebt benoemd komen grotendeels overeen. NA: Ja inderdaad. Ik heb voor het samenstellen van mijn rolverdeling ook gebruik

gemaakt van de MS ‘surestep’ methode. HB: Bijvoorbeeld boven een project manager kan ook nog wel eens een programma

manager zitten als je echt hele grote projecten hebt. Ja voor de rest komt het inderdaad sterk overeen.

NA: Duidelijk. Welke rol draagt in jou ogen het meeste bij aan succes uiteindelijk? HB: De project manager. We hebben nu een aantal hele grote projecten en als je daar

gewoon geen goede projectmanager hebt, dat is wel de cruciale sturende factor in zon hele. Je kunt een goede functionele consultant hebben die ook een goede kartrekker is. Die kan het er functioneel wel doorheen slapen maar een project manager is wel echt cruciaal.

NA: Ja. Ok. Er moet dus een juiste project manager zitten. HB: Het hangt van de omvang van een prject af maar bij ERP projecten, dat zijn grote

complexe projecten. We doen ook CRM projecten en daar kan je mee gecombineerde rollen hebben. Bijvoorbeeld een lead consultant die ook een prject erbij pakt. Maar in grootschalige ERP rollen dan heb je absoluut een goede project leider nodig.

NA: Welke eigenschap moet deze project manager hebben die hem juist zo onmisbaar

maakt?

101

HB: Een project manager moet op de juiste momenten ‘nee’ durven zeggen. En ook op

twee kanten, bij onze eigenconsultants draagvlak creëren en ook bij de klant. Dat is en heel erg belangrijke rol. Hij moet ook gewoon tegendruk richting die klant durven te geven. Dus heel veel klanten komen bij ons en zeggen nou dit is wat we allemaal hebben en het systeem moet daarin precies het zelfde zijn als tien jaar geleden alleen nu met nieuwe technologie. Nou wij zijn heel erg klant gericht en die gaan we dan zo goed mogelijk proberen te helpen en dan zegt die waarom moet ik daar nou driehonderd uren voor betalen. Dus de afweging tussen wat laat je leidend laat zijn. Als je zegt ik wil zo standaard mogelijk moet je continu naar de scope kijken van nou dit past binnen de standaard software misschien moet die klant wel een klein beetje zijn standaard processen aanpassen. Dus daar zit continu, een gevecht bijna, waarin die klant zegt ik wil me standaard software volgen of ik wil me proces heilig maken. Ja dat betekend dat je soms maatwerk nodig hebt. En heel goed die verwachting managen als je de beslissing neemt van nou we gaan nu maatwerk maken dat de klant ook honderd procent zeker weet van nou daar moe tik dan vijftig dagen extra voor betalen.

NA: Ja precies, heel reëel. Begrijp ik dan ook goed dat de project manager voornamelijk

degene is die met de klant contact heeft, of zijn dat ook mannen meer onderaan het project.

HB: He rolt op he. Vaak heb je werkgroepen. Die werkgroepen hebben hun eigen

functionele gebied waarvan ze vaak een lijst langslopen met van nou wat zijn nou de gaps die in het systeem zitten wat… wat moet er extraontwikkeld worden. Dat is een soort vinklijstje. Dan krijg je een issuelijst. Een issuelijst kan soms wel drieduizend punten zijn. He dus als er kleinere implementaties zijn dit er minder maar bij grote zijn dit zomaar drieduizend punten. Die drieduizend punten moeten we langslopen en bepalen van nou wat gaan we hiermee doen. Bij een serves bedrijf moet die service-bus liggen of moet die vanuit het centrale distributiecentrum komen. Dat soort beslissingen wat voor impact hebben die dan op de software.

NA: Worden die beslissingen via de project manager genomen? HB: Dat bepalen die issuelijsten. Die worden per projectteam. We hebben een aantal

functionele consultants, en die leidde zon werkgroep. Die bepalen voor elkaar voor logistiek hebben we deze issues, en die rolt dan op naar de stuurgroep. In die stuurgroep zit bijvoorbeeld de directeur van het klantenbedrijf, daar zit een project manager, daar zit van ons soms een directielid bij. En daar wordt bepaald bij het voorbeeld wat ik net gaf, als ze daar niet uitkomen op werkgroep niveau, gaan we hier nou dertig dagen maatwerk van maken of niet. Die klant vind dit dat die zegt nou dat gaan we doen en zo rolt dat project dan zeg maar.

NA: Ok. Duidelijk.

De volgende variabele is zeg maar de competence of the consultant. Daarmee bedoel ik vaardigheden skills, die zaken. Deze vier zaken heb ik opgetekend. Techinsche skills; productkennis van de verschillende modules. Ervaring; hoelang zit men in het vak. Daarbij understanding, sense en adjustability.

HB: Softskills NA: Ja inderdaad soft skills. En tot slot communication skills die daar min of meer bij

aansluiten. Kan je je in deze eigenschappen vinden en daarbij denk je dat er nog eigenschappen ontbreken?

102

HB: Die laatste zijn echt soft skills, die hangen bij ons eigenlijk samen met

communication skills. Het aantal jaar ervaring, technische kennis. Dat zijn wel de belangrijkste denk ik. Die onderste is wel het meest lastig te definiëren. En ook het meest lastige aan te leren. Dat leer je op basis van praktijk ervaring. Wat een consultant heel goed moet kunnen is de juiste vragen stellen. Communicatie is een ding, maar het goed achterhalen van nou. Je kan wel een vraag stellen maar krijg je daarbij ook het antwoord dat je zoekt. Dus echt leren doorvragen is, dat kan je onder communicatie-skills plaatsen maar dat is wel echt een aparte soort vaardigheid.

NA: Gaat het hierbij niet ook vaak om intuitie, wat doorgaans lastiger is aan te leren? HB: Dat is inderdaad lastig aan te leren ja. Dus en dat is op basis van praktijkervaring.

Mensen die dat al lang doen maken dat natuurlijk mee en die leren ok van andere consultants. Van he die vragen dat op die manier. Maar dat is dan nog wel een nuancering binnen communication skills.

NA: Ja. Ok. Weer, wat zou je als je een rijtje moeten geven van belangrijk naar onbelangrijk, wat

zou je als meest belangrijk aanstippen. Welke eigenschap zou je als eerst naar op zoek gaan? Begrijp je me vraag?

HB: Ik denk dat zich dat een op een op een met elkaar verhoud. Die eerste drie.

Technisch, aantal jaren ervaring, communication skills/soft skills is eigenlijk een driehoekje. Zonder die drie dingen… T is een driehoek dat als die uit balans is als je ze niet alle drie hebt. Aantal jaren ervaring is voor ons wel een hele belangrijke. Wij hebben voornamelijk seniors en we zijn dit jaar ook begonnen met een opleidingstraject waarin we junioren opleiden. Maar de kartrekkers zijn seniors.

NA: Ja. Ok. Eigenlijk evenveel dus. “They add up” HB: Ja. Equal. NA: En hoe denk je dat technische skills uiteindelijk bijdrage aan een succesvolle

implementatie. Bijvoorbeeld ik kan me voorstellen, als de consultant niet bekend is met een formule, dan kan hij het ook minder goed verkopen en minder goed inpassen in een praktijk.

HB: Ja dat is precies wat er gebeurt. Als je consultants hebt die niet voldoende technische

bagage hebben die gaan maatwerk adviseren. Waarbij als je een klein beetje conceptueel naar de situatie kijkt, je gewoon binnen de standaard software kan blijven. Een goede business consultants kijkt constant naar functionaliteit. En om een mooi voorbeeld te geven. We hebben een machinefabrikant als klant, maken grote afvalverwerkingsmachines en die kwam afgelopen jaar op een eventement. Nationale voorraad-dag die wij elk jaar organiseren met een aantal partijen. Daar was een presentatie vanuit de Retail hoek. Maar de productstructurr aan de engineeringskant lijkt heel erg op hoe een retailer zin assortiment ook wilt indelen. Terwijl die consultant die daar zat vanuit een traditionele ERP gedachte productie-lijsten aan het inrichten was, maar eigenlijk als we dat op deze manier vanuit een Retail gedachten hadden gedaan, wat dat veel flexibeler geweest. Minder maatwerk maar flexibeler ook in de zin dat ze makkelijker van assortiment kunnen wisselen en dat ze ook producten kunnen wisselen. Even een voorbeeldje waarbij als je op een conceptuele manier kijkt naar de situatie en een breed overzicht heb…

103

NA: Maar je moet er ook al mee gewerkt hebben… HB: Ook dat maar uiteindelijk gaat het ook wel om een stukje technische achtergrond om

er wat mee te kunnen zeg maar. NA: Dan zou je daar nooit zeg maar zelf aan denken. HB: Maar als je er vanuit een helikopter view naar kan kijken dat is wel… NA: Ja. Ja. Ja. Ok. Duidelijk. Nouja. Vanuit een stuk constante wisselwerking tussen jullie en de klantorganisatie.

En dat is dan ook mijn derde variabele. Er zijn een aantal karakteristieken die vanuit de klantorganisatie van belang zijn.

HB: Heb je de presentatie van Patrick gezien trouwens? NA: Heeft hij daar zijn eigen organisatie als voorbeeld genomen. HB: Ja. Dat is vanuit BlueCielo naar gekeken. HB: Dus daar heeft hij al vanaf nou ja bij een ERP implementatie, wat komt daar nou bij

kijken en wat is belangrijk. He dus zoals zorg voor de juiste mensen. Commitment vanuit de directie vooral ook. Dat is een hele belangrijke vanuit klant karakteristieken. Als er een stuurgroep is waar geen directielid bij zit. Dat is voor ons een rode vlag om voor ons te diskwalificeren. Ook vooraf al. We gaan niet met een klant in behandeling op het moment dat we niet serieus genoeg worden genomen. Dus commitment vanuit de directie dat dit een strategisch project is, een ERP implementatietraject, is mega belangrijk. Hier ook weer, even terug naar je vorige.

NA: Zij hadden daar een Ier of een Engelsman die heel belangrijk was? HB: Ja. NA: Ja en die freelancers, dat was ook heel duidelijk een trend die hij dacht te herkennen. HB: Ja, dat is wel Renee. Die komt vanuit een grote organisatie Balast Nedam en die

waren gewent alles met freelancers te doen. Dan moet je dus wel een competence centre hebben waarop je kunt terug vallen. Doordat Renee en een goed projectmanager en nog een paar mensen zijn ze heel erg zelfredzaam. Dat is vor hun uiteindelijk heel goed. Zij hebben ons ingeschakeld voor het initiële project en nu voor deelprojecten en voor de rest hebben ze zelf het overzicht. Ik durf wel te beweren dat dat een boel geld bespaard voor hun. Dat is best wel een slimme manier om dat te doen. Maar dan moet je ook de mensen voor hebben. Het is een soort inscourcing strategie he. Zij hebben zelf gewoon vier a vijf man op IT zitten waarbij iedereen zegt van ik wil alles in de cloud en zo weinig mogelijk IT hebben, zij doen het juist precies andersom. De vaag is even wat er goedkoper is.

NA: Wat wordt bedoeld met ‘if it looks and sounds like a pig..’ HB: Dan is het ook een varken. Als je bepaalde verwachtingen hebt van een bepaalde

module of… Laat je dan niet door een consultancy bedrijf of software leverancier te mooi voorspiegelen zeg maar. Je moet er gewoon realistisch naar kijken.

NA: Ok. Ik begrijp het nog niet.

104

HB: Hij zegt van ja, hij bedoelt met name rondom standaard software of niet. He dat je

zegt van nou als je heel veel dingen. Een leverancier beloofd nogal wat, en als je denkt van nou dit kan niet. Als je denkt dat het een varken is, check dat even heel zeker want vaak is dat ook zo.

NA: De klant moet ook een bepaalde, ik heb het hier absoptive capacity genoemd. De

klant moet dus ook bepaalde kennis willen en kunnen opnemen. En ook willen opnemen. Hebben jullie methodes om dit te ontwikkelen bij die klanten. Ik kan me voorstellen dat je ze een keer meeneemt naar een ander bedrijf waar een implementatie is gelukt. Of dat je product presentaties houdt.

HB: Wij hebben vaak trainingen en ook wel klanten in het voortraject bij elkaar op

bezoek laten gaan, referentie bezoeken inderdaad komen vaak voor. Er zitten in de module ook

NA: Zijn deze bezoeken en activiteiten vooraf of tijdens het implementatie traject? HB: Meestal tijdens ja. NA: Dus dat is meer met het oog op de order binnenhalen? HB: We organiseren ook regelmatig thema ochtenden om klanten bij te praten over

bepaalde dingen. Bijvoorbeeld zit er in AX een nieuwe warehouse management module. Nou dan organiseren wij een themaochtend om die klant een beetje op het zelfde niveau te krijgen.

NA: Klanten die bij jullie maintenace contracten hebben afgesloten dus? HB: Ja. NA: Maar tijdens de implementatie is het voor HSO die het werk doet en achteraf word

de nieuwe werkwijze uitgelegd aan het personeel. HB: Ja, dus er worden werkinstructies gegeven. Je hebt key-users die zeg maar heel veel

van het systeem afweten en ook een rol willen hebben waarbij zij samen met onze consultants uitleggen hoe het systeem werkt. Een zij hebben dan de rol om het naar de eindgebruikers uit te leggen. Dus zij doen eigenlijk de interne kennisoverdracht naar hun eigen mensen.

NA: En zij zijn opgeleid door jullie? HB: Ja, wij trainen meestal de key-users, of dat doen we samen met een externe

trainingspartij want dat is wel een speciale business. Dat doen we eigenlijk niet zelf. Daar huren we meestal andere mensen voor. Dan trainen wij die key-users en zij maken dan werk instructies zeg maar. Dus als je je voorraad moet registreren hoe dat dan werkt stap voor stap.

NA: [Ok. Duidelijk. En dan in hoeverre denk je dat er een kwestie moet zijn van een

persoonlijke match tussen de klant en de adviserende organisatie?] HB: Absoluut. Mega belangrijke. Dat is misschien wel de, even los van de directie die

plaatsneemt in de stuurgroep. De tweede belangrijkste is de culturele fit. Wij zijn een no-nonsense bedrijf. Als wij bij een heel ambtelijk bedrijf rond zouden moeten lopen denk ik dat onze mensen daar helemaal op zouden afbranden. Wij zoeken ook

105

klanten die daarbij passen. Wij zijn groot geworden in de groothandel. Dat zijn handelaren, niet lullen maar poetsen. Dat is hier ook, daarom past het goed bij elkaar. En ook in zon traject weet je dat je ups en downs gaan krijgen. Dan is het gewoon een robbetje met elkaar vechten, om de tafel, af en toe in de stuurgroep maar daarna is het ook weer: “hee jongens schouders eronder, we maken er wat van”. En daar moet je ook de klant uitzoeken.

NA: Mocht er op een gegeven moment en nieuwe klant voordoen en er is een onderbuik

gevoel doe zegt dat dit toch niet helemaal gelijk is met de waarde die wij voeren. HB: Het is wel moeilijk om dan nee te zeggen hoor. Maar je ziet vaak dat het in zulke

situaties n het voortraject al misloopt. Dat wij dan .. NA: Omdat zij dan ook met andere partijen bezig zijn? HB: Ja precies in een offertetraject merk je al, nou het is een hele afstandelijke club. Ja

dan gat bij ons de rode vlag al uit. Soms ga je dan een stapje verder, van nou we hebben een hele goede oplossen, dus laten we dan toch kijken, en dan keert het soms ook ten goede he dat je wel aan tafel komt en dan alsnog een succesvol project kan maken maar heel vaak is dat al het eerste signaal – dit is een heel afstandelijke club, die klant leveranciersverhouding heel belangrijk vinden. Ja en bij een ERP traject het succes wordt bepaald doordat het een partnership is. Bij Auping zijn me net begonnen. Daar hebben we een strategisch partnership waarin wij bij hun bepaalde modules ontwikkelen die we later ook in de markt gaan zetten. Op heel veel gebieden gaan we echt samenwerken in plaats van als een leverancier die een IT systeem komt implementeren. Maar samen een roadmap, waarop we voor de komende vijf jaar ideeën hebben opgeschreven gaan we als een trusted-advisor gaan we hun door de transformatie heen helpen. Dat is heel iets anders want ik heb hier een eisen en wensenlijstje en dat moet je voor dat bedrag maken.

NA: Voor mijn idee, is er veel werk? HB: Ja, we zitten nu tot september/oktober vol. Als er nu proejcten komen kunnen we ze

eigenlijk niet staffen. NA: Je kan projecten kiezen dus? HB: Ja. NA: Is dat over de gehele markt of geldt dat alleen voor jullie, voor zover jij weet? HB: Ja, ik denk wel dat wij een van de uitzonderingen zijn. Hoewel de algemene

dynamics markt wel aan trekt. En waar vijf jaar geleden twintig leveranciers waren van onze omvang, zijn daar nu nog maar vier of vijf. Wij zijn denk ik de grootste in Nederland op ons vakgebied. Ja. Dat er vijf of zes partijen zijn en dan houdt het op. Je ziet sterke schaalvergroting. Toen ik hier kwam werken vijf jaar geleden daar hadden we nog niet eens veel man. En nu tweehonderdvijftig. Het kan snel gaan.

NA: Duidelijk. En naast de culturele fit, dit kwam ook al terug in je vorige antwoord dat

je echt een soort van strategic partnership dient aan te gaan maar de motivatie van de klant, en niet alleen op directieniveau maar ook bij de key-users, is dat net zo belangrijk of kan een directie dat wel opleggen?

106

HB: Het begint bij de directie. Op het moment dat zij uitstralen dat we in een transformatieproject zitten, dit is voor ons mega belangrijk, dit moet een succes worden: cruciaal. Dat straalt dat ook uit op de mensen die dat uiteindelijk moeten gaan doen. En op het moment dat dat zeg maar kerngebruiker bij een stuurgroep en de directeur is lekker op vakantie en die zie of hoor je er nooit over of die zegt van jongens het is een IT project, dat is killing.

NA: Identificeren jullie dat nog wel als een soort van verantwoordelijkheid om te

proberen om deze motivatie te verkrijgen, of zien jullie dit heel duidelijk als een verantwoordelijkheid van de klantorganisatie?

HB: Wij wijzen de klant heel sterk op de verantwoordelijkheid dat wil hij een project

laten slagen is het mega belangrijk dat ze communiceren en dat er vanuit de directie eigenaarschap voor is. Onze meest succesvolle klanten hebben echt vanuit de direct iemand in de stuurgroep zitten en nemen zelf verantwoordelijkheid. Een ander succeselement, wat Renee zelfredzaamheid noemt, dat taken die je gewoon bij ons neer kunt leggen, maar daar zelf ook verantwoordelijkheid voor nemen. Het maken van rapporten, documenten ja dat kan je aan de leverancier vragen maar daar mag je zo weer tweehonderd dagen voor vragen. Als je het allemaal op maat wilt hebben.

NA: Dat snap ik niet helemaal. HB: Nou bepaalde rapporten zitten natuurlijk in een standaard ERP systeem, maar als je

dat aangepast wilt hebben, en alle andere rapportages speciafiek wilt hebben, ga je dat zelf configureren en huur je een junior in en zeg je veel plezier ermee, of zeg je tegen ons, ik wil dat jullie dat doen. Dat kost dan veel geld.

NA: Gaat dat buiten het ERP systeem om. HB: Nee het is binnen dat systeem. De data komt in ieder geval vanuit het systeem. En de

discussie waar het altijd op neer komt is van nou volgen we de standaard of volgens we de processen van het bedrijf. En als je een directielid heb die goed kan overzien en zegt dit vind ik echt megabelangrijk en is voor ons onderscheidend vermogen en levert ons concurrentievoordeel op, en dit niet. Die kan ook richting ons zeg maar zeggen van nou: “wat is nou echt belangrijk, wat is de top vijf top tien dingen die wij in onze methodiek anders doen, welke vijf of tien dingen wil je nou bereiken met de implementatie van de software”. Die is vaak afgeleid vanuit je bedrijfsstrategie. Bijvoorbeeld Auping wil een retailers worden. Ze zijn nu slechts een leveranciers. Ze moeten dus eigen winkels openen. Ze hebben nu twintig flagstores en dat willen ze komende jaren verdubbelen. Dat is voor hun een business driver waarom ze dit willen doen, als je dat dan verder afpelt die strategie, daar moet een multi-channel strategie moeten worden geïmplementeerd. Daar heb ik een software systeem voor nodig waar je bedden kan configureren via het web, maar ook waar je via verschillende winkels kan bestellen maar ook met mobiele ondersteuning, allemaal verschillende kanalen. Dan zeggen wij dus in de eerste oplevering van de software moet in ieder geval de vijf of tien dingen die het meest kritisch zijn, moeten erin zitten. Zo hou je met elkaar ook focus op de strategie.

NA: Dit past toch ook wel in de standaard Dynamics modules? HB: Nou…. Dat past wel maar de aanpak dat wij met meerdere releases werken dat doen

niet veel partijen. Dus veel partijen zeggen: rope maar wat je wilt hebben. Die gaan heel lang in een hok zitten met drieduizendpunten en dan gaan ze dat maken. Dan krijg je een soort big-bang scenario. En wat wij zeggen ook voor draagvlak bij onze klanten. Welke vijf of tien zaken zijn nu het aller belangrijkste, en in het begin is

107

daar veel discussie over, maar dit zijn de vijf top prioriteiten die we nu moeten gaan doen. En zo’n multi-channel strategie, dat moet gewoon werken in de eerste opleveringen. Want scope is ook een belangrijke, dit is voor ons de scope. En ik zie dat ook echt als een van de succesfactoren. Dus je zegt van dit gaan we voor je leveren. En als dat vervolgens is geleverd creëer je ook draagvlak in de rest van de organisatie. Waar gaan de grootschalige softwareprojecten op mis, op uiteindelijk ook draagvlak dat ze zeggen van: “Ja het gaat toch niet werken, ik heb nog niets gezien, ik geloof er niet meer in”.

NA: Dus het ophakken in kleinere stukjes is dus ook belangrijk begrijp ik? HB: Ja het heel duidelijk ‘scopen’ van je projecten is erg belangrijk. NA: De vierde variable; is hoe meet je achteraf succes. Ik hoor dat jullie niet zo zeer over

achteraf praten. HB: Business release één, business release twee, business release drie. Dingen die het

meest kritisch zijn. NA: Op het voorbeeld zei je dat je er vijf jaar een partnership aanging. Heb je het dan

over drie business releases? HB: Bij Auping heb je het ook over een CRM implementatie. We hebben daar een road-

map van allerlei veranderingen. Maar als je naar een ERP systeem kijkt is het vaak opgedeeld in drie business releases. De eerste, zo meten we dat dus ook, die klant tekent pas af als we met mekaar kunnen zeggen, deze dingen zitten erin. Dat hebben we vooraf afgesproken. Dan zetten we de optimalisatiefase is. Dan heb je vaak daarna nog een fase.

NA: Ok, na fase een gaan we een lijst af. Hoe wordt die lijst samengesteld? HB: We hebben die vijf, of tien, dat wisselt, hoofdthema’s die we dan als scope hebben

gedefinieerd. Daar staat bijvoorbeeld voor Auping dat hele multichannel-verhaal moet kunnen werken en multichannel ondersteuning valt weer uit te splitsen in een aantal recuirements. We moeten over onze klanten ook op hun mobiel de voorraad van een bepaald bed in een bepaalde winkel kunnen laten zien. En voordat we de ontwikkelfase ingaan. Als we die analyse en diagnose fase gehad hebben vragen we wat alle recuirements zijn. En die recruirements rollen weer op naar die vijf of tien hoofdthema’s. En dat kan maar zo eens een lijst van driehonderd punten zijn. Maar uiteindelijk hangt die wel aan die vijf of tien punten. En ja die check je gewoon met elkaar, en die loop je langs.

NA: Als het goed is ga je door, en als het niet goed is? HB: Dan ga je de discussie aan. En bij vaste-prijs projecten moeten wijer gewoon voor

zorgen dat het gemaakt word. NA: In hoeverre wordt ook nog het idee van de toeleverancier betrokken in jullie

succesmeeting? HB: Nee. NA: Is dat meer iets dat Auping zelf moet doorgeven aan jullie? Jullie praten niet met de

toeleveranciers.

108

HB: Nee, heel af en toe wel eens maar echt sporadisch. NA: En in hoeverre spelen tijd en geld dan nog een rol bij de succesmeting. We hebben

het nu vooral over inhoud maar en zijn natuurlijk ook voorwaarde waarbinnen een project moet worden gedaan. Ik neem aan dat die een rol spelen maar hoe verhouden die criteria zich tegenover recuirement lijsten? Stel dat je een project heb wat voldoet aan alle eisen. Alle functionaliteiten zijn honderdprocent goed geleverd. Echter is er tijdens het traject tweehonderdvijftig procent van het budget overschreden. Hoe verhouden die twee succescriteria zich tegenover elkaar?

HB: Op het moment dat je met elkaar in de analysefase heb gedaan, zeggen je van nou

wij denken tweehonderd dagen nodig te hebben om dit te maken om aan jullie requirements te voldoen.

NA: Offerte? HB: Nou dit is al verder. Het is vaak een proof of concept. We gaan aan de slag, we gaan

kijken wat jullie nodig hebben, we gaan een analyse doen. Dan komt er een punt, dat is vaak een go/no-go punt, dat we zeggen van nou gaan we verder, en wij zeggen dan voor vijfhonderd dagen implementatietijd gaan we dit voor je opleveren. Bent u het daarmee eens. Dan zegt de klant gedurende het project: “nou, eigenlijk moeten we ook Frankrijk bij de implementatie betrekken, want we hebben net een bedrijf overgenomen in Frankrijk.” Wij kijken altijd naar die scope, dat is onze kijk van de werkelijkheid. Ok, wat kost dat dan qua dorlooptijd en geld om Frankrijk er toch bij te betrekken? Nou dat kost je vijftig dagen extra. Ok nou hup, we doen Frankrijk erbij. Of met het voorbeeld van dat service bedrijf weer. We zijn met een andere leverancier gaan samenwerken en we gaan nu nachtritten rijden om ons distributiecentrum te beleveren. Wij moeten in AX dan net even andere configuraties opnemen als dat we hadden afgesproken. Nou, Dan maken we een changeorder. We hebben gekeken naar de impact van die wijziging, nou… Dus je werkt met change orders om dat op te lossen. Gedurende het traject.

NA: Ok. Nou het project is gedaan, je geeft elkaar een hand en dan mag je nog eens die

systemen ondersteunen en beheren en meer van dat. Zie je dat ook als, is dat ook een goede graadmeter van ik heb het goed gedaan. Of je dus achteraf het pakket wel of niet mag beheren, of mag dat altijd?

HB: Wat uniek is aan HSO wij hebben al een jaar of vier vijf geleden, ons bedrijf is twee

verschillende entiteiten gesplitst. We hebben daarbij een business tak waarbij de implementatie van de software wordt gedaan en we hebben een tak wat wij noemen, customerservice. Wat je bij heel veel traditionele ERP leverancier ziet: dat is een projectenfabriek zeg maar. Stel bij Auping, daar zitten vijftien man heel hard te werken en te rennen en dan op een gegeven moment: “pffiew, we zijn klaar”. En dan begint de volgende sprint weer. He dus ze gaan met z’n alle naar een ander bedrijf toe. Maar ja Auping heeft nog wel wat after-live support nodig. En sterker nog, ook die optimalisaties die zien allemaal mogelijkheden, die klanten hebben zo’n systeem en hebben het gevoel dat ze pas net begonnen zijn en die willen dat system optimaliseren en dan ja is het wel lastig dat een consultant die verstand heeft van jou business, bij een andere klant zit en die kan je niet bereiken en die reageert slecht. Daar knappen klanten op af. Wat wij hebben gezegd is we hebben de initiële implementatie, we hebben bedrijf a, dan zorgen we voor een hele goede overdracht. We stellen de klant voor aan onze customer serviceorganisatie.

NA: Is die afdeling dan ook veel groter dan de implementatie afdeling?

109

HB: Inmiddels wel. In Nederland hebben we daar nu 70 mensen zitten en 50 bij enterprise solutions. En dit is voor ons absoluut een differientiator is de mark. Omdat wij dat warm bad gevoel absoluut… Vaak is een initieel project lastig en moeilijk en staat onder druk en dan hebben ze het gevoel: “nou we worden echt geholpen”.

NA: Ok. Worden die projecten dan intern overgedragen? HB: Ja dat is een heel strak omlijnt proces. Waarbij ook mensen uit het initiële project

nog een tijdje meedraaien voor de goede overdracht en nog bereikbaar zijn als backup voor onze eigen consultants. Dus daar zitten wel goede afspraken onder. Dat verloopt over het algemeen redelijk geruisloos.

NA: Dat is dus iets waar je je sterk mee onderscheid? HB: Ja absoluut! En er zijn nog maar weinig mensen die dat wiel ook hebben

uitgevonden. Een mooie differientiator. En in onze customer service tak wordt er ook constant gewerkt om meer diensten die we aanbieden uit te breiden.

NA: Ok, hartelijk bedankt. Alles is duidelijk. Transcript interviewee 6 NA: Interviewer HV: Interviewee (Interview is in Dutch) NA: Mijn scriptie gaat over de rollen van externe consultants, en hoe deze bijdrage aan

het succes van een ERP implementatie project. Ik heb hiervoor een model, vanuit de literatuur onderbouwt, gemaakt die ik aan de hand van interviews in meer detail de werking van wil uitzoeken.

In dit model heb ik gekeken naar ten eerste rollen; ten tweede naar de vaardigheden

die een consultant dient te bezitten alvorens een succesvolle implementatie gerealiseerd kan worden, en tot slot heb ik gekeken naar het tussenspel tussen consultants en klantorganisaties. Alle drie deze variabele leidde zoals hier te zien tot consultancy succes en ik ben op zoek naar de vraag hoe deze variabele leiden tot zulks succes.

HV: Dat is goed. Je kunt me alles vragen, ik zal daarentegen wellicht niet overal een

antwoord op hebben maar ga gerust je gang. NA: Ok. Om te beginnen heb ik vier verschillende dimensies/rollen onderscheidde

waarbinnen ik heb gesteld dat een business analist de project leider is. HV: Nee. Als het goed is, is een business analist nooit een project leider. Een business

analist gaat modeleren en achterhalen hoe de werkprocessen van een klantorganisatie eruit zien. In andere woorden is hij in ondubbelzinnige termen aan het uitschrijven wat een klant nodig heeft om effectief op de markt te opereren. Dat is wat een business analist doet. Een project leider daarentegen is in beginsel iemand die het organogram doet, dagelijks management van het team doet wat is het project zit. Of dit nu klantwedewerkers of consultants zijn, of een mix daarvan, is daarin eigenlijk om het even. Die heeft dus een hele andere doelstelling. Een projectleider gaat om een heel belangrijk deel ook om de relatie te beheren, de tijdlijn te bewaken maar

110

stiekem toch ook om de kosten te bewaken. “Ben je wel met de goede dingen bezig?”. Maar gaat daarom doorgaans niet over de inhoud. Ik vind dat je dat onderscheid wel heel duidelijk moet maken. Er zijn wel mensen die dit werk verenigen, dus dan heb je een analist die ook project leider is. Maar het zijn wel twee verschillende petten die men dan op heeft. Daarom moet je ook wel dit onderscheid maken.

NA: [Begrijp ik goed dat de project leider dus in mindere mate ook technische kennis

dient te hebben.] HV: Ja, correct. Het helpt wel, maar het is geen noodzaak. NA: Daarnaast heb ik de systeem architect als rol geïdentificeerd. Dit is een soort

programmeur eigenlijk. HV: Nee, nee. NA: Nee? Herken je de termen wel. HV: Ja ik herken de termen wel alleen het moment dat je er invulling aan geeft denk ik:

“Nee dit is niet het zelfde”. Kijk een architect is iemand die de kaart tekent. Hetzelfde is dat met een gebouw. De architect ontwerpt het geheel. Die zorgt ervoor dat de consistentie compleet is, dat alle functionaliteiten benoemd zijn, door bijvoorbeeld door de analist, dat die een plek hebben gekregen op een logische plek, dat heb je het meer over ketens en hiërarchieën. Wat een architect niet doet is zelf de troffel ter handen nemen. Wat hij dus niet gaat doen is zelf bouwen. Dan moet je nog een onderscheid maken dat ERP doorgaans gaat over grootte delen vooraf gedefinieerde procesketen. Dat betekend dat een systeem architect met ERP termen, rekening moet houden met de standaard functionaliteit van de applicaties. Daar waar een klassieke systeem architect zegt: “Vertel me je droom en ik maak het voor je”, is wat ik zie als een applicatiearchitect is iemand die zegt: “vertel me je dromen, en ik ga je vertellen waarom je het op een hele andere manier gaat krijgen. Wat je nodig hebt, en waarom je het nodig hebt. Ik ga je vertellen hoe je dit gaat krijgen”. Dat is een hele andere invalshoek. Daarin onderscheid ik dus twee soorten aanpakken: een “solution driven approach en een requirement driven approach”. Een requirement driven approach is van wat heb je nodig en ik ga het voor je bouwen. Dat is wat een systeem architect vaak doet. Dan heb je een solution driven approach die veel meer uitgaat van: “Dit is het pakket, dit zijn daarbij de bedrijfsfunctionaliteiten die daarbij worden ondersteund. En als je het zo gaat gebruiken vertel me dan ook waar het niet gaat passen want dan gaan we vervolgens kijken hoe het wel gaat passen. Dat laten passen zit dus op twee assen. Enerzijds het aanpassen van het bedrijfsproces en anderzijds aan het aanpassen van het systeem. Beide brengen kosten aspecten met zich mee. Dat is wat een solution architect dus doen.

NA: Ok. Heel duidelijk dus een taak die hij vooraf doet. HV: Absoluut. NA: Klopt het dat in steeds meerdere maten een solution driven approach wordt

gehanteerd? HV: Dat hangt hel erg af van de plaats waar het systeem zijn intrede zal maken maar over

zijn algemeen is dat absoluut een trend. Ik werk nu negentien jaar bij XXX en toen ik destijds begon was alles in het begin maatwerk. Ja er waren wel pakketten maar die werden vaak gezien, vanwege de beperkte rijkheid in die oplossing, wat als een

111

voornamelijk deel als een bodemplaat voor maatwerk wordt gezien. 40% van alle functiviteit moet je zelf bouwen was destijds de gedachte. Dat is door de jaren heen wel veranderd. Nu zie je dat 90% van de functionaliteit standaard is en kijk je of en hoe je dit dan gaan aanvullen. Het hangt ook af van welk deel in het bedrijfsproces je zit te werken. Bij een primair proces, dus dat waar je jezelf echt onderscheid van je concurrent, waar je dus het geld mee verdient, daar zijn de requirements dus heeft belangrijk voor. Als je kijkt naar het secundaire proces, bijvoorbeeld zoals boekhouden, kijk er zijn maar weinig mensen die echt hun geld verdienen met boekhouden. Dat zorgt wel voor het verschil. Je ziet tijdens grotere implementaties meerdere dimensies ontstaat waarbij dus verschillende oplossingen naast elkaar ziet, waar het secundaire proces, bijvoorbeeld het boekhoudkundige, wordt afgedekt. En het primaire proces iets met een hoge mate van configuratie of zelfs maatwerk. En dan heb je de solution architect die beide moet afdekken. En dan heb je een applicatie architect die op de standaard applicatie zit. En een systeem architect als je m zo wilt noemen die gaat over het systeem. Dan heb je daarnaast nog eens een infra architect die zorgt dat alles met elkaar blijft praten.

NA: Technisch gesproken? HV: Ja technische gesproken. Want als de infrastructuur het niet doet, doet niets het. NA: In hoeverre worden deze rollen door een fysiek persoon verenigd? HV: Het word wel een verenigd in dezelfde persoon maar dat is absoluut geen gegeven.

Het zijn namelijk ook gewoon verschillende disciplines. Het vergt een andere manier van de wereld bekijken. Wat je wel ziet is dat mensen vaak beginnen bij een van de twee delen. Dus solution-, of recuirement driven, en dan vervolgens vanuit daar doorgroeien, of naar boven of naar beneden.

NA: Welke rol, of welke persoon draagt in jou ogen het meeste bij aan een succesvol

implementatie project. HV: De klant. NA: Ok. En afgezien van de klant? HV: Dat kan ik niet zeggen. De een kan niet zonder de ander. Je hebt ze alle vier nodig.

Als je deze vier als voorbeeld neemt dan. Ik kan niet zeggen dat. Noem maar eens een voorbeeld. Als de infrastructuur het niet doet, doet niets het. Als de recruirements-analise niet goed is, wat ga je dan neerzetten. Dan heb je een oplossing die niet past bij de behoefte. Als de architectuur niet klopt, de volgorde of logische samenhang is er niet, nou dan werkt het ook niet. Je kan slecht beginnen met een dak beginnen zonder dat er muren staan. De architechtuur moet ook kloppen. De een kan niet zonder de ander. Los van het feit of ik het eesn ben met het lijstje.

NA: Hoe zou jij het lijstje invullen? HV: Als je het hebt over ERP implementaties zit je inderdaad wel met een business

analyst. Project manager snap ik ook nog wel. Systeem architect zou ik als solution architect zien. Want die til je dan een iets groter veld in dan alleen maar het systeem. Want je moet hem zien in de brede context, in samenspraak met klanten. Dan heb je ook nog een technology consultant. Ja wat is dat?

NA: Ja… een programmeur.

112

HV: Ja maar in ERP, wat ik probeer te vertellen, programmeer je in beginsel helemaal

niet. Je configureert vooral veel, want je werkt vanuit het standaard pakket. En dan moet je gewoon heel goed snappen wat de mogelijkheden zijn van het pakket. Hoe de bedrijfsprocessen dienen te worden ondersteunt met het pakket. En hoe je met configuraties en het aanpassen daarvan om moet gaan. En vanuit daar tot een optimale ondersteuning over te gaan. Dan heb je het dus ook echt over hele tool-specifieke kennis.

HV: Je hebt dus geen programmeur meer. Deze komt alleen in beeld als het echt niet

anders kan en er maatwerk nodig is. En er is altijd maatwerk nodig. En de kunst is, die ligt dus bij de rollen zoals je die nu hebt benoemt. De kunst van die vier rollen is eigenlijk om het maatwerk te minimaliseren. Want dan heb je de optimale ondersteuning van het bedrijfsproces met het optimale gebruik van de mogelijkheden van het standaard pakket.

NA: Waarbij achteraf wellicht ook minder hulp voor support of upgading hoeft

ingeschakeld te worden bij jullie? HV: Nou, wij doe nhet natuurlijk allemaal. Wij doen die hele stapel. Maar als je een

oplossing neerzet, die moet ook beheerd worden. En een heel groot deel van de kosten zitten in het project, maar er zitten nog veel meer kosten in het beheer en alles wat er achteraan komt. En alles wat je met het standaard pakket kunt afdekken wordt ook een in beginsel ook door standaard software updates onderhouden. Dus je kunt jaren door met updates rondom veiligheid en nieuwe toepassingen vanuit de leverancier. Maar maatwerk kan dat niet. Dat betekend dus elke kaar dat als ik een update krijg op hetzelfde pakket, dat maatwerk groeit niet meer. Dus daar moet ik wat mee: onderhouden. Dat kost dus allemaal weer tijd en dus kosten. Het is daarom van belang dat de klant een optimale balans kan vinden tussen standaard configuraties en maatwerk ook met het oog op het beheer van de oplossing.

Ik zie graag dat een klant tevreden is met het geheel. Niet alleen nu, maar ook over

tien jaar. Want dat is wel de life-span van heel veel applicaties. NA: OK. Duidelijk. Vervolgens wil ik het graag hebben over de vaardigheden van de

consultants. Daar vanuit heb ik de vier belangrijkste karakteristieken onderscheiden. Die heb ik op deze manier geëxtraheerd als belangrijk. Daarbij hebben we het over de mate van ervaring van een consultant; de mate van technische vaardigheden van een consultant; in hoeverre kan hij zijn kennis overbrengen; spreek hij dezelfde taal als de klant-organisatie.

HV: Ik mis er eentje. Dat is bedrijfsproceskennis. Die zou ik hier grag willen terugzien als

vijfde punt. Waarom begin ik ermee. Wat je ziet is dat heel veel organisaties hebben een bedrijfsproces vraag, bijvoorbeeld boekhouden. Als je dan vervolgens niet weet wat boekhouden is, hoe ga je een klant dan helpen met het verbeteren van deze processen. Hoe snap je wat de klant nou werkelijk nodig heeft. Hoe stel je nou net even die vraag, waarin je begrijpt op welke manier de klant de informatie die ze vraag ook daadwerkelijk gebruiken gaat. Dan kan je namelijk met suggesties en alternatieven komen. Dan kan je ook voorgaan stellen hoe hij zijn bedrijfsprocessen gaat aanpassen om optimaal nut te halen uit het pakket. Terwijl zijn bedrijfsproces doelstellingen wel gehaald worden. Dan moet je wel snappen wat die doelstellingen dan betekenen.

NA: Begrijp ik dan goed dat we het hier hebben over business specifieke kennis is.

Bijvoorbeeld voor een bepaalde tak van handel zoals staal oid?

113

HV: Dat kan. Dan komen we weer terug op van waar gaat ERP je ondersteunen. Heel

zwart-wit gezegd, boekhouden is boekhouden. Eigenlijk branche onafhankelijk. Maar bij staal bijvoorbeeld moet je je afvragen of een standaard ERP implementatie wel bruikbaar is. Bij staal, is dat zo specifiek dat een algemene oplossing waarschijnlijk niet de specifieke onderdelen van de branche zullen ondersteunen. Dan helpt het dus als je het snapt. Als je in logistieke organisaties zit, dan helpt het absoluut als je snapt wat de consequenties zijn van logistieke processen, omdat optimaal te kunnen ondersteunen. Er is een moment dat je niet meer vanuit de ERP pakket, om het daar even op te plotten, kunt redden. Dan krijg je een switch, gedreven vanuit de business analisten rol die jij net hebt benoemd, waarbij dus van een pakketspecialist met business analist pet, een omslag gaat krijgen naar een business analist die specifiek is voor die branche maar wel snapt wat het pakket betekent. En daar ligt ergens een omslagpunt.

Het begrip van wat de klant moet bereiken, en wat het betekend voor een klant

organisatie vind ik een essentiële eigenschap om consultancy te bedrijven. Dat maakt het verschil tussen ben je nou een ‘toolie’, een metselaar die maar gewoon doet wat hem gezegd wordt. Leg die steen daar neer, niet vragen waarom, dat snap je toch niet. Tot en met, beste consultant ik heb een muur nodig, hoe gaan we die bouwen? Dat is een hele andere vraag.

Ik denk dat als je een groot complex project heb, dat je t allebei nodig hebt. Ik denk,

als ik kijk naar het overige lijstje. Technical skills, dus programmeren is in een pakket implementatie eigenlijk niet aan de orde. Bij een ERP implementatie wil je in beginsel niet programmeren. Want als het goed is, en je hebt je pakket selectie goed gedaan heb je 99% van alle functies komt uit je standaard pakket: dan wil je niet programmeren. Ik zie het als mijn meest nobele streven om het programmeren tot het absolute minimum te beperken. En toch de bedrijfsprocessen goed te ondersteunen. Niet programmeren, maar wel productkennis/tool-specifieke kennis gebruiken. Als je kijkt naar Oracle, snap je dan wat de mogelijkheden van het pakket, wat een vinkje op punt a betekend, en wat een vinkje op punt b betekend. Je moet kunnen uitleggen wat de consequenties zijn van ‘een vinkje’. En dat zou ik dan als technical skills omschrijven, in feiten.

NA: Draagt ervaring ook bij aan een succesvolle implementatie? HV: Als ik naar mezelf kijk, ik werk inmiddels al twintig jaar bij XXX waarvan de

afgelopen vijftien jaar binnen Oracle EBS. Het feit dat ik toch de nodige klanten, organisaties, fouten, successen heb gezien, veel mensen heb gesproken en de kennis die ik heb meegenomen van de ene klanten organisatie naar de andere klanten organisatie. Daarbij heb ik zeven jaar in het buitenland gewerkt. Ik snap nu dus echt wel wat een aantal consequenties zijn van over de grens werken. Zeker bij multinationals is dat een waardevolle ervaring waar zeker voor geldt hoe kan ik mijn klantenorganisatie de consequenties uitleggen van bepaalde keuzes. En dan kunnen we met z’n alle denken dat je dat uit een boekje haat en bij elkaar leest, maar dat is niet zo. Ik vind het absoluut een toegevoegde waar maar ook daarvoor geldt; het is het verschil tussen een tool-specialist of een consultant. Als je je wilt specialiseren moet je ervaring hebben.

HV: De volgende beschouwend: communicatie skills, ook waar, absoluut. Communicatie

het woord zegt het ook al. Het is een combinatie. Kan ik oppikken wat een klant nodig heeft. Heel veel organisaties weten zelf niet wat ze bedoelen he. Heel veel organisaties hebben ook tradities. Waarvan ze zelf niet meer weten waarom ze die

114

hebben. Kan ik vervolgens achterhalen waarom ze die activiteiten nodig hebben. Ik moet snappen wat ze nodig hebben, om überhaupt te kunnen adviseren.

NA: Dat draag dan ook weer bij aan jou product kennis, en aan het adviserende gedeelte.

Dat je dus niet zegt van: “Dit doen jullie zo, dit wil je hebben”. Nee, meer: “Dit hebben jullie eigenlijk nodig om al jullie bedrijfsprocessen nog te kunnen ondersteunen”.

HV: Inderdaad. Op mijn manier kan je met minder kosten, en een lagere impact precies

bereiken wat je nodig hebt. En ik biedt jou de volgende mogelijkheden om ook op de lange termijn door te kunnen groeien. Ik kan niet alleen kijken naar nu, maar ook over tien jaar, om op deze manier door te kunnen groeien. Ik moet ook kijken of ik geen deuren sluit die groei over twee jaar wellicht in de weg zullen gaan staan.

NA: Puur uit interesse, maar hoe doorgrond je zo een doorgrondig proces? Hoe begin je

ermee om erachter te komen hoe de huidige manier van werken in elkaar steekt? HV: Dankzij de ervaring die ik heb, ik ben bedrijfseconoom van achtergrond, begrijp ik

wat boekhouden betekend, ik snap wat bedrijfsprocessen inzicht hebben. Dus dat betekend dat als ik bij een organisatie binnen kom, ga ik vragen stellen. Doordat ik dit kan plotten op de dingen die ik al heb gezien kan ik slimmere vragen stellen. Op een gegeven moment stel ik helemaal geen vragen meer die ik nodig heb voor een antwoord maar ik vraag alleen maar vragen die voor de klant van toepassing zijn. Ik ben dan bezig met het zichtbaar maken voor de klant van zichzelf. Waar zijn uitdagingen zitten. Ik wil dat de klant een aantal dingen ook ziet die ik al gezien heb. Dat klinkt heel arrogant maar dat is wel hoe het werkt. Dankzij mijn achtergrond en de dingen die ik al gezien heb komt dat snel binnen. En als ik bij een klant binnenkom, dan begin ik heel ordinaire aan de koffie automaat. Koffieautomaat is gewoon de belangrijkste plek. Ik zie mijn rol als puur mensen werk. Praten. Luisteren. Nog meer praten en luisteren.

NA: Is een onderdeel hiervan ook het bestellen van verwachtingen? HV: Ja. Continue. Dit is verwachtingsmanagement. Als een klant een pakket heeft

gekocht, doorgaans met heel veel sales gewerkt vanuit de software leveranciers. Alles is daar bigger, stronger, faster, alles kan daar. Ja wacht even. Het kan allemaal tot op het moment dat je de volgende keuze hebt gemaakt en dan kan dit allemaal al niet meer. Flexibiliteit totdat je het vastzet. En je moet het een keer vastzetten. Dus je bent continue bezig met verwachtingen bijzetten. Ontwikkelen ook; wat mag een klant wel en niet verwachten? Wat is echt een utopie?

NA: Hoelang duurt een proces waarbij je de organisatie doorgrond? HV: Dat wisselt heel erg. Hangt af van de organisatie, van haar ontwikkelingsfase, van

welk team je mee werkt, de vraag die ik mee krijg. Het kan zo een half jaar duren. NA: Alvorens er eerste afspraken worden gemaakt over bepaalde doelstellingen etc? HV: Absoluut. En dan ben ik niet alleen. Dat doen we met een team. Daar gaat veel tijd

overheen. Hoe je dat meestal doet is om op zoek te gaan naar je beste vriendje. Dit is een super-user waar mee je vervolgens een partner in crime wordt. Aanvullende work-shops doen; het begrip ontwikkelen.

NA: En is dat iemand uit de klant-organisatie?

115

HV: Ja bij voorkeur zeker. Kijk zij zijn de eigenaar van hun recruirements. Als externe kan je nooit eigenaar zijn van de behoefte van de klant. Dat betekent dat degene die de behoefte heeft ook vertegenwoordigd moet worden door iemand van die organisatie. Je moet toegelaten worden tot het interne netwerk van de klant. Wie heb je nodig voor een bepaald antwoord.

NA: Is dat aanspreekpunt bij voorkeur iemand hoog in de directie? HV: Ik roep altijd ‘iemand zonder secretaresse’. Maar het wisselt. Ikzelf heb het liefste

iemand zonder secretaresse. Iemand die daadwerkelijk zelf het werk uitvoert, die dus snapt wat het betekend. Want die maakt het dagelijks mee.

NA: Een gebruiker dus? HV: Nee, niet zomaar een gebruiker… Een zware gebruiker. Bijvoorbeeld een team-lead

van een gebruiker. Een meewerkend voorman van een gebruikersgroep. Degene die als voorman voor een team van de echte gebruikers staat. Iemand die ook het overzicht heeft over het waarom, en niet iemand die alleen maar doet wat hem verteld wordt. Maar ook snapt waarom en hoe zijn bedrijfsproces een bijdrage levert aan de organisatie. En dat is meestal iemand die bij zijn volgende promotie een secretaresse krijgt.

NA: Ik begrijp op welk niveau je zit te denken. (pt. two) HV: Ik zou daar dus die vijfde heel graag aan toegevoegd zien worden. Dus

bedrijfsproceskennis. Bedrijfsproceskennis. NA: Ja. Ok. Ten derde wil ik graag het samenspel tussen klant en consultant belichten.

Zoals je net ook al aangaf is de klant in vele gevallen degene die bepaald of het een succes wordt of niet.

HV: Ja, dat klinkt misschien een beetje flauw. De klant is niet koning. NA: Maar die achteraf bepaald wel of het een succes is of niet. HV: Ja inderdaad maar dat betekend niet dat de klant koning is he. Kijk wat je vaak ziet is

dat het fout gaat op het moment dat je precies doet wat de klant wil. Dat betekent dan ook dat je geen consultancy durft te bedrijven. Ik vind het op het moment dat je weerwoord durft te geven tegen te klant, dan ben je bezig de grenzen van een project neer te zetten. Op het moment dat een organisatie onze hulp inroepen hebben ze vaak een probleem. En dat probleem bestaat voor een groot deel doordat ze zelf niet weten hoe of de mogelijkheid hebben dat probleem op te lossen. Dat betekent direct dat je daar als consultant moet binnenkomen en eigendom moet nemen van een deel van dat probleem. Of op zijn minst de oplossing voor dat probleem levende. Dat moet je vooral doen door te adviseren. Momenteel zit ik in het buitenland voor een klant. Mijn counterpart zei daar op het moment dat ik daar binnenkwam: “dont tell me want we want to hear. Tell us what we need to hear”. De mindset is heel belangrijk. Klant is geen koning. Je doet niet blind wat de klant zegt. Adviseren. Weerwoorden geven. Uitduiden wat consequenties zijn van iets. De klant bepaald wat succes is, ergens onderweg ook. Zonder klant heb je geen bestaansrecht. En daarmee is de klant het belangrijkste en de bepalende factor van succes.

NA: In hoeverre neemt een klant het advies op. Is hij bereid te veranderen. Kan hij

luisteren. Vertrouwd een klant jou.

116

HV; Vertrouwen moet je verdienen. NA: Door? HV: Actief deelnemen. Constructief adviseren. En dat gebeurt ook bij de koffieautomaat.

Laten we eerlijk wezen. NA: De understanding van de consultant. Dit heb ik gedefinieerd als dat de twee partijen

dezelfde taal spreken. Ik kan me namelijk voorstellen dat hier een compleet andere bedrijfscultuur hangt dat in de staalindustrie.

HV: Ik denk dat je die op de verkeerde plek hebt gehangen. Ik kan de klant namelijk niet

veranderen. Ik kan wel ons veranderen. Dat betekend dat het begrip van de consultant voor een heel belangrijk deel bij de consultant ligt. Dan kom je bij de communicatie skills uit. Kan ik mijn boodschap uitleggen op een dusdanige manier dat de klant het snapt.

NA: Het is dus niet zozeer een klant specifieke eigenschap, als meer een consultancy

skill? HV: Ja. De klant heeft een communicatieniveau en dat is een gegeven. Hij staat er wel

maar ik vind dat de verantwoordelijkheid verkeerd ligt. Het is niet hun verantwoordelijkheid om de consultant te snappen. Het is de verantwoordelijkheid van de consultant om de klant te snappen.

NA: Dit zou dus beter passen tussen te communicatieve vaardigheden van een consultant.

Verder ligt er bij de klant wel een verantwoordelijkheid om de motivatie naar een verandering te voeden. Bijvoorbeeld iemand bovenin het bedrijf kan wel bepalen dat er nieuwe software nodig is en dat dat er moet komen en dat alles gestroomlijnder moet. Maar er zijn vaak mensen die een paar lagen daar onder zitten, de gebruiker zijn en het allemaal wel best vinden de manier waarop het nu gaat. Hierdoor ontbreekt vaak de motivatie om te veranderen. Klopt dit en hoe beïnvloed dit management consultancy succes.

HV: Klopt. Veranderen doet pijn. Dit heeft een sterke invloed. Absoluut. Er is wel

moeilijk een maat aan te geven maar.. Het gaat over het commitment aan de verandering van de klantorganisatie. Op het moment dat die weerstand die jij beschrijft op operationeel niveau door de klant niet als verantwoordelijkheid wordt genomen, dan heb je een probleem, want dat kan ik als consultant niet veranderen. Ik kan de organisatie nogmaals niet veranderen. Dat is een verantwoordelijkheid van de klant organisatie en dat betekent tegelijkertijd ook dat de keuze die op een hoog niveau wordt genomen, dat die intern uitgedragen en getrokken wordt. Als een externe consultant kan je het wel proberen maar dat zal niet goed gaan.

NA: Heb je daar concreet methodes om die bereidheid en motivatie te beïnvloeden en te

versterken? HV: Ja. Dat gaat over organizational change management. Dat gaat over uitleggen.

Communiceren. De voordelen uiteenzetten. Uitduidelijk van wat heb je er als gebruiker aan. Eerlijk gezegd

NA: Maar concreet gesproken.

117

HV: Wat ik doe is dat ik bij organisaties laat zijn hoe de applicatie zich ontwikkeld. Daar zijn conference pilots voor. Product demonstraties. Met een aantal stakeholder, eigenlijk de beste vriendjes die ik net noem, medeplichtig maak aan het succes van de oplossing. Dat betekent dat zij, als je het werk goed doet is het dus de consultant en die bedrijfsproces vertegenwoordiger is een twee-eenheid waar die persoon ook verantwoordelijk is, of zich voelt voor het succes en de manier waarop het wordt uitgedragen intern in de organisatie. En daarom heb ik dus ook die vent nodig zonder secretaresse. Dat is namelijk een van de mensen van de werkvloer. Die snapt waar het over gaat en ook hoe hij het moet uitleggen.

NA: Aha, duidelijk. En dat is dan ook ‘one of the team’. HV: Ja. Maar dat laat onverlet dat als het van boven niet ondersteunt wordt. Niet

uitgelegd wordt waarom een bepaalde verandering plaats gaat vinden. Waarom de grotere verandering, in het grote perspectief goed is voor de organisatie. Wat je in de toekomst dus wel kan, maar in het verleden niet meer. Maar ook andersom, dus de plussen en de minnen. Ik bedoel dit gaat over een heel belangrijk deel over eerlijkheid. Dit gaat over het vertrouwen dat je niet alleen als consultant moet verdienen maar ook het vertrouwen wat je als project moet verdienen. Dat kan je alleen maar doet dooreerlijk en open te communiceren. En vooral ook geen minpunten te verhullen.

NA: Begrijp ik dan goed dat daar ook in jou ogen een hele grote verantwoordelijkheid ligt

bij het bedrijf en in veel mindere mate bij de consultant? HV: Absoluut. Absoluut. Ik kan de klant niet veranderen. Als zou ik het willen. Al zou

ik het kunnen zou ik het niet willen. Dat is een verantwoordelijkheid van die organisatie.

NA: Maar heeft weldegelijk een uitwerking op jullie bedrijfsvoering. HV: Uiteraard. HA: Als vierde variabele, de mate van succes. Het project is klaar. HV: Hoe meet je succes. Uitstekende vraag. Dat is ook een hele moeilijke. Laat ik hem

omdraaien. Wij hebben een kwaliteitsmanagement systeem dat heeft DOTAS. Dat staat voor on-time management, and customer expectation. Aan het begin van een project vragen we aan de klant noem de criteria op waar je ons op gaat toetsen achteraf. Wij spreken in beginsel, aan het begin van een project met de klant af wat die succes criteria zijn. En dat betekend dat op verschillende momenten tijdens, en ook aan het einde van het project, vragen wij score ons maar. Dit waren de criteria die we hebben afgesproken, hoe scoren we hier op. Moeten we nog bijsturen. Wat kunnen wij nog veranderen als we tekort schieten. Aan het einde van de rit vragen we: “we hebben het er verschillende keren over gehad. Wat is het eindoordeel?”. Dat is de officiële lezing. En dat is een kwantitatieve manier van succesmeeting. Kwantitatief in de zin van, hoe scoren wij op de schaal van een tot tien. Daar komt gewoon een rapport cijfer uit. Dat maakt het kwantitatief.

Daarnaast zijn er nog een aantal andere meetingen. Ik meet mijn succes over het minimaliseren van maatwerk. Wat ik eerder zei. Ik geloof er absoluut in dat als je maatwerk erbuiten weet te houden heb je op de lange termijn een meer tevreden klant. De kosten zijn lager, de risicos zijn lager, en de mate waarin het pakket beheerbaar is en upgadebaar is is veel hoger. Dat is er eentje.

118

De tweede. Dat is nog een hele andere. En dat is een stukje emotie. Sta je aan het einde van het project als dikke vrienden boven op het project tevreden terug te kijken, te genieten op de go-live borrel. Van dit hebben we toch samen gedaan. Zit er vervolg business in. Hoe gaat die relatie zich ontwikkelen. Ik vind een implementatie is een ding. Maar beheer, onderhoud, nieuwbouw, aanbouw, uitbreiden. Met een life-cylce van pak en beet tien jaar. Ja daar in die vervolg relatie die je hebt dat bepaald of je succesvol bent geweest.

NA: Of ze weer voor jou gaan. HV: Ja. Dat op een hele natuurlijke manier gewoon de telefoon gewoon blijft gaan,

vanne: “He hoestie nou, oh btw ik heb nog een vraag kan je me even helpen.” Kijk dan weet je dat je punten hebt gescoord. Dan ben je weer terug bij, je wilde dikke vrienden zijn, en is dat gelukt. Dat klint heel manipulatief, dat is het niet. Kijk ergens anders had je ook staan dat gaat over de chemie tussen de consultant en een klantorganisatie. Niet iedereen past gewoon overal. Laten we eerlijk wezen. Nou kan je de juiste mensen op de juiste plek op de juiste plek inzetten. Kan je die chemie creeren en ontwikkelen.

NA: Is de mate waarin de klantorganisatie op een gegeven moment weer support nodig

heeft, omdat zaken niet naar behoren draaien. Hoe minder een klant daar behoefte aan heeft, hoe minder ze achteraf voor support moeten vragen, is dat ook een meting van succes.

HV: Ik zou dat graag als criterium zien maar is gelijkertijd wel weer heel afhakelijk van

in hoeverre hebben we een vanilla cq. op maat gemaakte oplossing geleverd. Het hangt af van de complexiteit van de oplossing. Ik wou dat ik kon zeggen dat zero-support altijd de realiteit is maar dat is gewoon niet zo . Beheer heeft een reden.

Als je het hebt over fouten, en constaterening van fouten, dat is absoluut een criteria voor succes. Maar dan ga je die fout ook zeker tegenkomen in dat OTAS, dat ik zojuist benoemde. Zijn de blij met het project, of rammeld het aan alle kanten.

NA: Wanneer wordt een OTAS evalutatie ingevuld? HV: Twee maanden na een go-live. Als je bijvoorbeeld kijkt naar een boekhoudkundig

proces. Wat ik altijd interessant vind is de tweede maandafsluiting. Dat is het moenet dat alle cijfers bij elkaar worden gesprokeld. De eerste keer is minder representatief. De tweede wel want dan is er weer een grote mate van business-as-usual. Dan moet je vragen: “Ben je echt tevreden?”.

NA: Begrijp ik dan goed dat in een OTAS dat daar vaak kosten en tijd criteria een rol

spelen? HV: Dat kan. Dat hoeft niet, maar dat is maar net of de klant dat wil. In veel gevallen

komt dat zeker aan bod. Dan gaat het over de budget overschrijding. NA: Waarschijnlijk worden toeleveranciers van de klantorganisatie ook beïnvloed door

een nieuw ERP systeem. In hoeverre wordt de mening of tevredenheid meegenomen in jullie succesmeting?

HV: Veel. Maar dat heeft ook te maken met hoe ga je je scoping afbakenen. Het komt

namelijk ook redelijk vaak voor dat wij niet eens met toeleveranciers mogen praten, punt. Als het anderzijds bijvoorbeeld gaat over interfaces van bijvoorbeeld digitale facturen, dat is kennis die wij absoluut meenemen. Wij proberen dat naar

119

standaarden toe te trekken. Omdat we bij andere organisaties hebben gezien hoe de mensen dat graag willen.

NA: Ik denk dat we alles besproken hebben. Alles is heel duidelijk. HV: Ik ben heel nieuwsgierig naar je resultaat.