|
1. Introduction
There are two schools of thought
concerning the origins of ERP software (Adam and Sammon, 2004). One
route to ERP came from engineering and the desire to control inventory,
the other from finance and the desire to control expenditure. Closer
attention to excess inventory and efficient use of raw materials led to
the Material Requirements Planning (MRP) approach to planning, promoted
strongly by the American Production and Inventory Control Society (APICS)
during the 70’s. Orlicky (1975) has described how managers and
researchers came to realise that a computer enabled the detailed
application of the MRP technique by actors on the factory floor. MRP
software was developed as a computerised approach for the planning of
materials acquisition and production. As the use of these applications
became more widespread, the software was extended allow the planning
module to be updated with feedback from the execution cycle (closed loop
MRP). So closed loop MRP, together with some financial modules,
developed into an integrated approach to the management of manufacturing
resources, termed Manufacturing Resource Planning (MRP II).
In parallel, companies had been
looking at methods to standardise and consolidate financial information
to produce monthly operating statements and balance sheets. The reason
that Finance is considered as the “first point of entry” for information
systems is that this function is already standardised in terms of its
data collection and analysis methods (Muller,1992).
Indeed, Besson (1999) discusses how
ERP implementations affect the value system in an organisation such that
industrial experience, such as product knowledge, manufacturing know-how
etc. is usurped by the obsession with low-level operational cost data
required by “Finance’s Trojan Horse”.
2. ERP systems defined
From a technical point of view, ERP
systems are based on a client / server architecture providing support to
integrated business processes across organisational functions. Stefanou
(2000) defines ERP software as a set of customisable and highly
integrative real time business application software modules sharing a
common database, which support core business, production and
administrative functions, such as logistics, manufacturing, sales,
distribution, finance and accounting. Another definition was proposed by
Sammon and Adam (2000) who have said:
“ERP systems are integrated
enterprise-wide software packages that use a modular structure to
support a broad spectrum of key operational areas of the organization”.
ERPs provide a transactional
backbone to the organization that allows the capture of basic cost and
revenue related movements of inventory. In so doing, ERP systems afford
better access to management information concerning business activity,
showing actual sales and cost of sales in a real-time fashion. Kalakota
and Robinson (1999) stress that the popularity of ERP systems has
stemmed from the fact that they appear to solve the challenges posed by
portfolios of “disconnected, uncoordinated applications that have
outlived their usefulness”. Holland et al. (1999a) agree, stating that
one of the major reasons for the shift towards ERP packages is the need
to deal with legacy systems.
ERPs are designed for multi-site,
multi-national companies, which require the ability to integrate
business information, manage resources, accommodate diverse business
practices and processes across the entire organization. Wood and Caldas
(1999) found in their survey of 40 organisations having implemented ERP
that the main reason to implement ERP was the need to “integrate the
organizations processes and information”.
Davenport (1998) stated that large
companies collect, generate and store vast quantities of data which is
“spread across dozens or even hundreds of separate computer systems,
each housed in an individual function, business unit, region, factory or
office”. These localized legacy systems have a huge impact on business
productivity due to the workload of re-keying, reformatting, updating,
debugging, etc. When management is relying on information from
incompatible systems to make decisions, instinct becomes more important
than sound business rationale.
More generally, the growth in
popularity of ERP systems can also be linked to an increasing business
trend towards globalization, mergers and acquisitions. To be successful,
a global company must be able to control and co-ordinate their various
remote operating units. Accurate, real-time information provided by an
ERP system has the ability to integrate the more remote subsidiaries
into corporate practice because an ERP system allows the sharing of
information in standard format across departments, currencies, languages
and national borders. Thus, ERP systems can be used to provide a “common
language” between units (Bingi et al., 1999; Horwitt, 1998).
Some of the benefits achieved by
companies looking to harness the tight global co-ordination afforded by
ERP systems are :
§ Streamlining global
financial and administrative processes
§ Global lean production
model
§ Rapid shifting of
sourcing, manufacturing, and distribution functions worldwide in
response to changing patterns in supply and demand or to changing local
cost bases
§ Minimise excess
manufacturing capacity
§ Reduce component and
finished goods inventory
Davenport (1998) describes how
Owens Corning, for example, adopted ES to replace 211 legacy systems.
For the company to grow internationally, it was critical to co-ordinate
order-management, financial reporting, and supply chain processes across
the world. Having implemented the system and established a new global
procurement organisation, the company is now able to enter into larger
more advantageous international contracts for supplies. Finished goods
inventory can be tracked daily, both in company warehouses and in the
distribution channel, and spare parts inventory has been reduced by 50%.
The company expects to save $65 million as a result of the adoption of
these globally coordinated processes.
3. Difficulties in implementing ERP
In order to achieve the integration
of all the basic units of the business transaction, ERP systems rely on
large central relational databases. This architecture represents a
return to the centralised control model of the 60’s and 70’s, where
access to computing resources and data was very much controlled by
centralised IT departments. Therefore, ERP implementations are an
inherent part of a general phenomenon of centralisation of control of
large businesses back to a central corporate focal point.
The resulting standardisation in
business processes allows companies to treat demand and supply from a
global perspective, consolidate corporate information resources under
one roof, shorten execution time, lower costs in supply chains, reduce
stock levels, improve on-time delivery and improve visibility of product
assortment with respect to customer demand.
The technical risk associated with
the ERP implementation is lower than that experienced in the development
of bespoke systems (Holland et al., 1999b; Martin, 1998), but critical
business-related difficulties remain (Davenport, 1998). The main
implementation risks associated with ERP projects are related to change
management and the business reengineering that results from switching to
the ERP software’s underlying business model (Holland et al., 1999b).
Unsurprisingly, the main benefits of ERP implementation are derived from
solving these business problems.
Thus, although sometimes seen as
large information systems projects, ERP projects are in fact change
management projects where basic business practice will change to align
with the “best practice” as defined in the ERP business processes.
Staehr, Shanks & Seddon (2004) highlight the danger of not critically
examining existing business processes, quoting a logisitcs manager
involved in a SAP implementation as saying “if the process was wrong,
all that SAP enabled us to do is do the wrong things quicker”.
On the other hand, adapting
business processes to a global template does not necessarily yield the
same benefits across the local subsidiaries of a multinational. Butler
(2004) quotes a case where the global visibility of demand as afforded
by a single instance ERP system does not take into account fluctuations
in local demand (eg. high levels of inventory maintained due to local
agreement with customers). Hence some plants might not compare
favourably with others serving different customer groupings.
ERP systems are also frequently
vaunted by over-zealous vendors for contributing to competitive
advantage, company performance and even shareholder value. Fundamentally
however, ERP systems are simply the tools for recording and managing all
costs and revenue items within the enterprise, be they associated with
product, people or cash. With a structure in place to record this level
of detail for an enterprise, ERP systems when implemented are
notoriously weak in providing reporting adapted to the needs of the
business managers. This is frequently due to the fact that the huge
effort required in implementing the basic functionality left little room
to look at the post go-live reporting requirements. Also, although the
core system contains all the transactional information required to
manage the business activity, managers can’t run reports off the live
system as they impact on core system performance and therefore slow down
response times for other users. Secondly, information hungry ERP systems
require more data than non-integrated legacy applications, therefore
extra resource is required to manage data (a process engineer complained
that there was no IS support available 18 months after go-live because
they were occupied with data maintenance tasks).
So business managers, having
implemented an ERP system to help understand the company’s cost base,
margins and profitability, are still short on reports and information
that will help them to measure and interpret company value. In short,
they have the tools in place to manage the data generated by the
different tasks and processes that make up organisational activity. This
is a pre-requisite for being able to answer the question “are we doing
things efficiently”. What ERP systems cannot answer, however, is “are we
doing things effectively”. One of the fundamental questions in this
research is whether changing the organisation to incorporate “best
practice” as epitomised in ERP processes does actually impact the
effectiveness or value of the business.
Thus, for many organisations, the
real challenge of ERP implementations is not the introduction of new
systems, but the fact that they imply “instilling discipline into
undisciplined organisations” (Ross, 1998). In that study, one of the
firm’s Vice Presidents is quoted as saying:
It is very hard for people to
change from things they know well and are good at. We find that people
who were most effective in the old environment were those who knew how
to “beat the system”. With SAP beating the system is not good; what’s
good now is discipline. These people have a lot of unlearning to do and
it’s painful.
Because they are modular, ERP
systems allow some degree of customization (ie. selection of modules
best suited to the business’s activities). However the system’s
complexity makes major modifications impracticable. The very integration
afforded by the interdependencies of data within the different modules
of the system mean that changes in configuration can have huge knock-on
affects throughout the system. Vendors would insist that the more
customized an enterprise system becomes, apart from the time and cost
impact to the project, the less able it will be to communicate
seamlessly with the systems of suppliers and customers.
A configuration table enables a
company to tailor a particular aspect of the system to the way it
chooses to do business. An organization can select, for example, the
functional currency for a particular operating unit or whether it wants
to recognize product revenue by geographic unit, product line or
distribution channel. SAP’s R/3, for example, has more than 3,000
configuration tables. The set-up of the Accounts Receivable module of
Oracle involves over 50 configuration screens. This complexity often
results in extravagant costs in making any modification to the software,
however minor the change may seem.
4. Impacts of ERP on the organisation
Much of today’s research in the
area of organisational learning and knowledge management deals with the
difficulties of creating and harnessing the value inherent in employees
know-how and ways of doing business. This begs the question as to why so
many companies are willing to throw out what they have learned in favour
of practices they know nothing about. And, when they do so, what
evidence is there to suggest that companies do achieve their stated aims
of improved efficiency by adopting these industry best practices?
Indeed, no organisation plans to “brutalise” its personnel by
implementing a Big Brother style control systems that don’t let a single
expenditure go unnoticed. However, it is clear that there is little to
prepare employees for the changes in the organisation of their day to
day work and sources of support.
Davenport (1998) showed the
paradoxical impact of ERP on companys’ organisation and culture. On the
one hand, by providing universal, real-time access to operating and
financial data, ERPs allow companies to streamline their management
structures, creating flatter, more flexible, and more democratic
organisations. On the other hand they also involve the centralisation of
control over information and the standardisation of processes, which are
qualities more consistent with hierarchical, command and control
organisations with uniform cultures.
From a business perspective,
information that was tracked manually or not at all will now have to be
recorded religiously in the system in order for automatic triggers to
process transactions and move on to the next stage in the process. A
de-humanising element is present where information demands now come from
the system rather than a colleague. The give and take of corporate
relationships is replaced by the all ungrateful and information hungry
system.
Davenport (1998) asks, for a
multinational, how much uniformity should exist in the way it does
business in different regions or countries? For most companies,
differences in regional markets remain so profound that strict process
uniformity may actually be counterproductive. Companies must remain
flexible and allow regional units to tailor their operations to local
customer requirements and regulatory structures. Davenport recommends a
type of federalist systems where different versions of the same system
are rolled out to each regional unit, e.g. Monsanto, Hewlett-Packard and
Nescafe have found this approach successful. This raises its own
problems for the company, i.e. deciding on what aspects of the system
need to uniform and what aspects can be allowed to vary (Horwitt 1998).
In Europe, ERP projects are more
complex than in North America, because of diverse national cultures,
which influence organisational culture and make successful
implementations of multinational ERP solutions difficult. Thus, failure
to adapt packages to fit the national culture leads to projects, which
are expensive and late (Krumbholz 2001). Also, users can no longer hide
behind their mistakes (Staehr, Shanks, Seddon, 2004), forcing new
visibility and accountability.
Thus, multi-nationals face a choice
between using their ERP as a standardisation tool or preserving (rather
tolerating) some degree of local independence in software terms
(Davenport, 1998). Most local subsidiaries do not have a say in the
decision to implement ERP, so it is usual that the global solution lacks
some capability to deal with the local requirements. This notion of
global vs. local requirements is a recurring theme in the research. Our
study seeks to understand the essential trade-off of centralised control
against local autonomy, and what this means for the competitive
advantage of the local organisation.
Ward & Griffiths (1996) look at the
models that have been used to present these conflicting forces of
control and flexibility (in the context of IS planning), and within
which organisations must attempt to steer the best path. They discuss
various approaches to IT planning, including the Infusion / Diffusion
model proposed by Sullivan (1985). Using this model, which was intended
to demonstrate the different approaches to IT planning, we can depict
the evolution of the use of information systems in the organisation. In
particular, ERP systems may be depicted as a function of the drive to
integrate ever greater business functionality and the drive to control
the means of delivery of this functionality.
Figure 1: Environments of IS / IT planning (Sullivan, 1985) in Ward &
Griffiths (1996)
Firstly, infusion is the degree to
which an organisation becomes dependent on IS/IT to carry out its core
operations and manage the business. Diffusion, on the other hand, is
defined as the degree to which IT has become dispersed throughout the
organisation and decisions concerning its use are decentralised. These
axes reflect the “opposing” forces of automation in industry :
1. creating advantage from
tools by working with them close to the point of application (possibly
inventing new and unforeseen uses of tools depending on immediate
business need) : this emphasises the notion of effectiveness
2. keeping control of
resources and skills so that the benefits of automation can be shared
throughout the organisation : this emphasises the notion of efficiency
ERP is considered low diffusion
because it is by nature a centralising force in the organisation, often
chosen to consolidate disparate legacy systems and standardise across
variations in business practice. It is high infusion because it has the
effect of spreading the threads of integration across the business
functions.
The model is useful as it allows us
to portray the balance between the 2 elements of any business process
automation, the organisation (real) and the information (virtual).
Humphries & Jimenez (2003) adds to this a third dimension, which is how
real-time the information needs to be, arguing that the requirement to
operate the virtual enterprise at, or near, real-time will continue to
grow.
5. Research design
The objective of this research is
to examine the positive and negative effects of ERP implementations on
multi-national subsidiaries, and how organisations can plan to protect
local competitive advantage from the “steam-rolling” effect of adopting
standard business processes.
The first question concerns gaining
an understanding of how multi-national subsidiaries see themselves in
the corporate context, and how they formulate and defend their own
unique competitive advantages in the global organisation. The second
question concerns the impact that ERP implementations have on this
unique competitive advantage. The third question looks at the impact of
ERP implementations on the local organisation. ERP systems change the
tools people use to do their jobs, their responsibilities and the
relationships with colleagues. This study seeks to demonstrate the
longer term effect of implementing ERP on the company.
Following the concept of
“purposeful selection” as described by Patton (1990), we selected a
number of “information rich” cases for in-depth study. Our sample was
based on satisfaction of a certain number of criteria, including:
access, size, organisation of IT, nature of activity, multi-national,
stage in ERP implementation process and penetration of ERP modules. Thus
the organisations we studied are multi-national companies in
manufacturing sectors. As it turned out, all have implemented or are in
the process of implementing SAP. As subsidiaries of major
multi-nationals they have local IS departments who are responsible for
the maintenance, delivery and support of non-ERP applications and
interfaces. They also have overall responsibility for local
infrastructure and desktop issues.
Shang and Seddon (2000) argue that
it is not meaningful to talk of benefits of IT systems without
identifying the stakeholder group in whose interest the benefits are
being judged. In this study we focused on the end-user in a local
subsidiary, be they at the transaction level (operational) or at the
reporting level (management).
The resulting research questions
can be summarised as follows:
•How do multinational subsidiaries
identify and cultivate unique competitive advantage (value) in a global
organisation?
•What impact (negative or positive)
has the implementation of a global single instance enterprise solution
on the value of the local subsidiary?
•How has the implementation and day
to day running of an ERP system changed the local company’s
organisation, its way of working and the relationships (both local and
with other parts of the global organisation)?Our research was based on 4
case studies carried out in manufacturing companies at different stages
in their ERP implementation lifecycles :
§ a leading pharmaceutical
company engaged in primary manufacturing (active ingredients
manufactured and shipped to “secondary” tabletting customers), at the
pre-implementation stage with a global SAP project
§ an international
subsidiary of a leading high-tech manufacturer of computer equipment
(one of 3 manufacturing plants worldwide, with responsibility for
financial services for all countries outside the US), 2 years after
go-live on a global Oracle system
§ a manufacturing
subsidiary of a leading pharmaceutical company, still in the process of
adding functionality to a mature SAP implementation
§ the Irish site of a US
based supplier of electronic devices
6. Findings
6.1 Longitudinal case
study
In the first of the case studies
quoted above, an interpretive / longitudinal case study approach was
taken. Information was gathered via questionnaires and face-to-face
interviews with the project team. The first questionnaire (concerning
the objectives, benefits and project team organisation) was distributed
to all team members during April 2003. Because our access to this site
was excellent, in this case study, we were able to ask key Project
personnel some questions on the expected level of impact on the
business. The results are presented in Table 1.
Taking the same basic format, but
using some of the information gathered during the first survey, the
second questionnaire was distributed to team leaders during May 2003.
Questions centred on the key outstanding issues as the design was being
locked down. Known or proposed workarounds for these outstanding issues
were discussed. Areas where SAP functionality would improve the business
process were also highlighted. This stage also involved interviews with
the local Information Systems team.
The researchers also attended Gap
analysis workshops facilitated by the global roll-out team, where the
team formally presented perceived gaps and impacts to the business.
Workshops for Planning, Production and IS were attended.
Table 1: Impact Matrix for ERP
project in the first of our sites
In addition to these
questionnaires, one-to-one interviews were carried out with business
process leads during the design phases of the project from May through
to July. These interviews were aimed at gaining an understanding of
outstanding issues in each of the process areas.
A key observation on the results in
Table 1 is the spread across positive / negative attitudes, one could
have expected more consensus. There may be good reasons for this
divergence. Different processes are subject to different levels of
change in a large integration project of this sort.
In this ERP project, there was a
subtle change in the team’s motivation (which coincided with the first
chance to get some hands-on experience with the application modules),
moving from an attitude of this being a “necessary evil” to one where
team members begin to feel “this isn’t so bad, in fact there’s some good
functionality here”. It is vital for the team to make this transition,
the risk being that if they don’t, users out in the organisation, with
much less exposure to the new functionality than the global roll-out
team, will not make it either. As “ambassadors” for the new system,
their own commitment will directly influence that of the business in
general.
6.2 Post-implementation
study
The other three case studies, both
post-implementation, were interview based. Key personnel in the
manufacturing, finance and information systems functions were
interviewed to solicit feedback on the impacts of the move to a global
single instance ERP system. Face to face interviews and questionnaires
were used.
Based on our observations,
subsidiaries of multi-national companies that are implementing a global
ERP solution frequently find themselves in a position where the changes
are imposed rather than designed. There are specific changes to the
local business functions (steep learning curve on new business
processes, more dependent on corporate resources, less authority to
introduce local process changes, loss of ownership of data). There are
equally quite dramatic changes to the role of the local information
systems support function, who have usually lost control of the hardware
and software resources used in satisfying user demand. Furthermore, they
have often seen their responsibilities dramatically narrowed down to
data maintenance and desktop support duties.
The following sections contain a
catalogue of the problems we have observed at the sites we visited.
6.2.1 Problems with data entry
into the ERP package
One of the first changes to the
organisation imposed by integrated ERP systems is that they push the
responsibility for data correctness and completeness back to the point
of entry. A sales rep taking an order on behalf of a customer is driven
by the desire to see the order processed as quickly as possible so that
the revenue can be recognised and commission payments made. This can
represent a significant cultural change in organisations where the sales
function is used to much more freedom in the manner in which orders are
recorded, often with a sales administration function doing the clean-up
of the order behind the scenes.
The net effect can be a sudden
increase in data entry for the sales function. A multi-national
high-tech manufacturer admitted from the start of their implementation
project that they were going to suffer a 10% increase in workload in the
Sales Admin function. Given the goal of making processes more efficient,
it may be difficult to convince sales of the benefit to them of
providing more accurate information at the outset, which ostensibly only
benefits others further along the revenue cycle.
In the high-tech manufacturing site
we visited, one of the driving forces in implementing an ERP solution
was the ability to execute customer orders as the business grew
(scalability). However, use of the new sales order functionality implied
a heavier workload on Order Entry (more screens, each with more fields)
than previously on legacy systems. Therefore a change to the
organisation would be required before any net benefit could be derived.
In the Pharmaceutical subsidiary,
extra data entry staff are required to input Purchase Orders (created in
SAP) into the Fixed Assets module of SAP. The presumed goal of
integration was not achieved in this case and this does not seem to have
been anticipated until it was time to go live.
6.2.2 Loss of Productivity
The biggest single concern of
management at another pharmaceutical manufacturing site we visited was
how to maintain its hard won reputation for excellence and efficiency (eg.
number of shop-floor technicians employed per compound manufactured) in
the face of expected changes to the organisation due to a corporate ERP
implementation. This organization rates its customer responsiveness as
its top core competence, proud of its ability to deliver 98% of customer
orders within pre-set lead times. It achieves this today in some cases
by being able to “express” deliver unplanned orders from customers, even
to the extent of turning around an order within one working day.
Managers’ concerns arise from the news of a sister site in the previous
stage of the global roll out, which went live at the beginning of 2003
and is still (9 months later) struggling to recover from the drastic
reduction in its on-time customer delivery rate from 92% to 64%.
In the procurement cycle, pushing
the responsibility for correctness of data and approval back to its
source (any creating or approving a purchase) also has significant
organisational impact, and one that no amount of training can prepare
the company for. In another company we visited, managers baulked when
the head of international finance, responsible for several billion
dollars worth of revenue, was inundated with hundreds of purchase
requisitions after go-live. The team in charge of the purchase approval
hierarchy, which had spent months trying to get the users to co-operate
in configuring approval levels, suddenly got a lot of close co-operation
when it was too late to make substantial changes without reworks to the
software configuration.
6.2.3 Aiming ERP at a moving
target
A high-tech company implementing a
single instance global Oracle system found that the business needs (or
core value) of fast execution changed during the 24 months it took to
implement. Initially chosen because of its “scalability”, that is its
ability to grow and expand with the rapidly growing demand for products,
the ERP solution was replacing creaking legacy systems which were barely
able to cope with each new quarter end. By the time the system was going
live, the demand for products had dropped dramatically, and the business
value was no longer geared towards execution of orders, rather it was
getting the orders in the first place. Thus, ERP projects can also fail
because they try to match the stable and monolithic functionality of the
ERP package to the moving target of the challenges facing the
organisation.
6.2.4 Changes to routinised
processes towards less flexibility
The discipline imposed by the
system can again introduce strain in processes where there may have been
greater flexibility in the past. Staff shipping product are not
responsible for the accuracy of the configurations in finished goods
compared to the sales orders to be fulfilled, but they will feel the
pressure most acutely if the system is preventing them from shipping
product with what they would feel to be marginal differences with the
sales order.
Even the simple fact of working off
a single global customer database can create problems for subsidiaries
with different local practices. Global customers may have complex legal
structures with different legal entities in different countries, albeit
rolling up under the one parent company from a financial perspective.
What is an acceptable bill-to address for a customer in the US may not
be acceptable in Japan. One manufacturing company found 40 occurrences
of the same customer name in their legacy systems. While this was
acceptable as long as each country knew from experience which customer
number corresponded to the active one, this is not transferable to a
global system, which will change all customer codes and refuse
duplicates. Certainly an ERP system will impose discipline in terms of
working with global data sources, but this discipline is often perceived
as a loss of flexibility and lack of adaptability.
Many ERP systems require that all
inventory movements on the floor be associated with work orders, such
that inventory gets consumed as the work progresses. In the high tech
manufacturing company we visited, the in-house production model didn’t
match this concept for 2 main reasons:
§ The starts plan for
products are not work orders in that they do not yet relate to a
specific sales order. Instead they are a best guess for finished goods
requirements at quarter end. This is a build to stock scenario.
§ Components that are
“consumed” at the beginning of testing may well be returned to inventory
when a product is “de-configured” for allocation to a specific sales
order
For this reason, a workaround
involving the definition of Standard Starts Configurations (as work
orders) was created. These standard configurations allowed inventory to
be consumed / returned, but do not form the basis of a match with a
sales order.
6.2.5 Customisation
The multinational high-tech company
we visited was quoted a $1m modification budget for a customization to
the system to allow lines to be shipped from a sales order independently
of each other. In some cases, these small, but prohibitively expensive
changes matter a lot for the proper operation of the firm. A
pharmaceutical site we visited found that the automatic determination of
batches from the warehouse to satisfy process orders precludes them from
making any changes to batch weights as the process orders progress
through manufacturing, a simple facility of their legacy system that
they had been using routinely for years.
Most ERP systems operate user
representation groups (eg. Oracle Application User Group, Saphire group
for SAP users) so that required modifications and enhancements can be
channeled back into the application in new releases and “patches”. These
enhancements are released on an irregular basis, and are subject to the
vendors view of the “marketability” of the updates. This means that a
company with an unusual process requirement may not be able to generate
any interest in their customization because few other users have he same
requirement.
The same is doubly true for a local
subsidiary of a multi-national relying on centralised IS support for
systems modifications. An Italian subsidiary of a high-tech
multi-national, for example, had to wait 18 months before the IS
department would look at a VAT report (the report took a matter of days
to develop, test and implement), simply because the requirement was not
perceived as global.
So ERP customers can end-up caught
in a quandary of :
§ no choice in the
selection of the software solution (based on global requirements)
§ huge commitment to the
ERP project in terms of power users, training and cutover (particularly
in smaller subsidiaries where fewer users handle more tasks)
§ implementation support
which rarely takes into account local user constraints (eg. language)
§ no capacity for
customizing the software (only vanilla ERP functionality used)
§ no support for local
reporting requirements if they do not benefit the global organization
§ no local support as the
solution has been built, designed and is run by a centralized core team
§ no support for
interfacing from the ERP solution to local systems
The typical scenario in these
instances is that the local user falls back to downloading information
from the ERP system, and uses local applications to solve transactional
or reporting needs (severely damaging the integrity of the entire
solution).
In the Italian subsidiary of a
high-tech manufacturer, the ability to produce invoices dated with the
customer delivery date (instead of the product ship date) was taken away
by the implementation of the ERP system, and no alternative proposed.
Although from a corporate perspective the stated objective of
implementing ERP to shorten the financial close period to 2 days has
been achieved, for at least one subsidiary this has meant the loss of
the ability to automatically invoice customers. The workaround has been
to put a hold on the invoice generated by the system, make the date
change modification to the system generated output, and then release it.
This example illustrates the
situation where the further users are (physically or hierarchically)
from the central solution, the less likely they are to derive benefit
from the application. A Financial Director for the same company,
referring to the fact that modification requests tend to be met with a
barrage of bureaucracy, except if they came from the headquarters
themselves, said “It’s still a question of location, location,
location”.
7. Conclusion
The research study presented in
this paper is on-going and we are only able to put forward preliminary
findings at this stage. However, the observations we made in the four
sites we visited lead us to believe that there is a great need for
multi-national companies to be more cautious before they embark on
multi-million, multi-year, multi-phase roll out implementation of
enterprise-wide software packages.
The positive arguments of the
vendors are well known and well understood. However, it is not certain
whether the reality of ERP implementations that steam-rolled local
knowledge and local practices has yielded such tangible business
benefits in real terms. Affording the illusion of greater control over
large corporations to managers at head quarters can come at a high price
if it dissolves the fragile fabric of an organisation’s competitive
advantage in the process.
The typical scenario of the
roll-out, whereby all sites are asked to implement the common template
within a prescribed time frame, may be appealing to managers in head
office, but it is actually a nightmare for local managers. Typically,
long hours have gone into fine-tuning their local knowledge and building
this experience into their way of doing business. Applying the template
may mean steamrolling these unique processes and jeopardise efficiency
gains accumulated over time.
An even more perverse effect of
such implementation stems from the perception of many local managers in
multinationals that they are not competing against other firms, either
in the area or abroad, but against sister sites of their own firm who
are engaged in the same activities. This perception is often well
founded, in the case of one of the companies researched, where 20 or 30
manufacturing sites were reduced to less than 10 key sites worldwide
over a period of a few years. In this game of local survival, it is the
performance and productivity of each site that enables managers to make
a case for their site’s unique contribution. The roll-out of ERP wreaks
havoc in local organisations and may, at least in the medium term,
change the balance of power between sites. From our point of view as
researchers, it is difficult to see how this upheaval can be beneficial
to either local sites or the global corporation.
As we complete our case studies, we
will be able to make specific suggestions for the development of more
reliable models for creating the global implementation template for
large scale ERP projects. This can be used both to guide further
research in enterprise-wide systems and to inform the practice of
implementing such systems in multi-national firms.
References
-
Adam and Sammon
(2004) “Towards a Model for Investigating Non-Decision Making” in The
Enterprise Resource Planning Era: Lessons Learned and Issues for the
Future, Chapter XI, Idea Publishing Group, Hershey, PA USA.
-
Bingi, P.,
Sharma, M. and Godla, J. (1999) Critical Issues Affecting an ERP
Implementation, Information Systems Management, Summer 1999, 7-14.
-
Besson, P.
(1999) Les ERP a l’epreuve de l’organisation, Systemes d’Information
et de Management, No. 4, Vol 4.
-
Butler, T.
(2004) Examining the influence of ERP systems on firm-specific
knowledge assets and capabilities, in Adam and Sammon (Eds) The
Enterprise Resource Planning Decade: Lessons Learned And Issues For
The Future, IPG, Hershey: PA.
-
Davenport, T.
(1998) Putting the Enterprise into the Enterprise System, Harvard
Business Review, July/August, 121-131.
-
Holland, CP,
Light, B and Gibson, N, (1999 - a), “A Critical Success Factors Model
for Enterprise Resource Planning Implementation”, Proceedings of the
7th European Conference on Information Systems, Copenhagen Business
School, 273-287.
-
Holland, C.,
Light, B. and Kawalek, (1999 - b) P. “Beyond ERP Systems: innovative
strategies fro competitive advantage, Proceedings of the 7th European
Conference on Information Systems, Copenhagen, Denmark.
-
Horwitt, E
(1998) Enduring a global rollout - and living to tell about it,
Computerworld, March 1998.
-
Humphries T,
and Jimenez M, 2003. ERP Scenario. In proceedings of Software
Infrastructure track at Gartner Symposium ITXPO, Florence, Italy.
10-12 March.
-
Kalatoka, R.
and Robinson,M., (1999) “E-Business – Roadmap to Success”,
Addison-Wesley, Reading, MA.
-
Krumbholz, M.,
Galliers, J., Coulianos, N. and Maiden, N.A.M. (2000), Implementing
Enterprise Resource Planning packages in different corporate and
national cultures, Journal of Information Technology, 15, pp.267-279.
-
Martin, M.
[1998] Smart Managing, Fortune, Feb 2nd, 1998.
-
Muller, A.
1992, L’informatique dans les entreprises, Collection Que sais-je?,
Presses Universitaires de France, Paris.
-
Ross, JW,
(1998) “The ERP Revolution: Surviving Versus Thriving”, Working paper,
Center for Information Systems Research, Sloan School of Management,
MIT.
-
Sammon, D. and
Adam, F., 2000 "Towards a Model of ERP Software Selection - Widening
the Debate", Proceedings of the 10th Annual BIT Conference, November
1-2 2000, Manchester UK.
-
Shang, S. and
Seddon, P. (2000) “A Comprehensive Framework for Classifying the
Benefits of ERP Systems”, Proceedings of the 6th Americas Conference
on Information Systems, August 10-13 2000, Long Beach California, USA,
pp1005-1014.
-
Staehr, L.
Shanks, G. and Seddon, P. (2004) Understanding the Business
Consequences of ERP Systems , in Adam and Sammon (Eds) The Enterprise
Resource Planning Decade: Lessons Learned And Issues For The Future,
IPG, Hershey: PA.
-
Stefanou, C.,
(2000) “The Selection Process of Enterprise Resource Planning, ERP,
Systems”, Proceedings of the 6th Americas Conference on Information
Systems, August 10-13 2000, Long Beach California, 988-991.
-
Sullivan, C.H.,
(1985) “Systems Planning in the Information Age” from Sloan Managament
Review 1985, Winter.
-
Ward J., Griffiths P. (1996), Strategic Planning for
Information Systems, 2nd edition, , John Wiley & Sons
|
