The ERP paradox

“…strategic alignment flounders in never-ending tactics and compromises…”  Ole Hanseth et. al.  in The Control Devolution: ERP and the Side-effects of Globalization (The Database for advances in information systems, Vol. 32, pp. 34-36)

Introduction

Organisations implement Enterprise Resource Planning (ERP) systems for a number of reasons.  Some of the more  common ones are:

• To gain control over processes within the organisation.
• To make these processes more efficient.
• To reduce the portfolio of applications that the IS department has to manage.

Yet, the end result of ERP implementations is often the opposite: less control, and efficiency; and even though the number of applications may be reduced, this advantage is often offset by the cost and effort of maintaining ERP systems. In this post I explore this paradox, drawing from the paper from which the quote at the start of this post was taken. In essence, the paper discusses- via a case study – how the implementation of an ERP system can actually increase organisational drift and reduce efficiency.

Globalisation and its effect on IT strategy

Those who have lived through an ERP implementation would be well aware of the some of the difficulties associated with these. This is no longer news: there is a fair bit of research done on the problems and pitfalls of ERP system implementations (see this paper, for example). The question, however, is why ERP implementations run into problems. To answer this, the authors of the paper turn to the notion of globalisation and how ERP systems can be seen as a reaction to it.

Globalisation is essentially the interaction and integration between people of different cultures across geographical boundaries, facilitated by communication, trade and technology.  The increasing number of corporations with a global presence is one of the manifestations of globalisation. For such organisations, ERP systems are seen as a means to facilitate globalisation and control it.

There are four strategies that an organisation can choose from when establishing a global presence. These are:

• Multinational: Where individual subsidiaries are operated autonomously.  
• International: Where work practices from the parent company diffuse through the subsidiaries (in a non-formal way).  
• Global: Where local business activities are closely controlled by the parent corporation.  
• Transnational: This (ideal) model balances central control and local autonomy in a way that meets the needs of the corporation while taking into account the uniqueness of local conditions.

These four business strategies map to two corporate IT strategies:

•  Autonomous: where individual subsidiaries have their own IT strategies, loosely governed by corporate.
•   Headquarters-driven: where IT operations are tightly controlled by the parent corporation.

Neither is perfect – both have downsides that start to become evident only after a particular strategy is implemented. Given this, it is no surprise that organisations tend to cycle between the two strategies, with cycle times varying from five to ten years; a trend that corporate IT minions are all too familiar with.  Typically, though,  executive management tends to favour the centrally-driven approach since it holds the promise of higher control and reduced costs.

Another consequence of globalisation is the trend towards outsourcing IT infrastructure and services. This is particularly popular for operational IT – things like infrastructure and support. In view of this, it is no surprise that the organisation discussed in the paper chose to outsource their ERP operations to an external vendor.  Equally unsurprising, perhaps, is that the quality of service did not match expectations.

The effect of modernity

The phenomenon of modernity forms an essential part of the backdrop against which ERP systems are implemented. According to a sociological definition due to Anthony Giddens,  modernity  is “associated with (1) a certain set of attitudes towards the world, the idea of the world as open to transformation, by human intervention; (2) a complex of economic institutions, especially industrial production and a market economy; (3) a certain range of political institutions, including the nation-state and mass democracy”  

Modernity is characterised by the following three “forces” that have a direct impact on our lives:

• The separation of space and time: This refers to the ability to coordinate activities across the world – be they global supply chains or virtual project teams. The ability to coordinate work across space and time is made possible by technology. The important consequence of this ability, relevant to ERP systems,  is that it makes it possible for organisations to increase their level of surveillance and control of key business processes. 
• The development of disembedding mechanisms: As I have discussed at length in this post, organisations often “import” procedures that have worked well in organisations. The assumption underlying this practice is that the procedures can be lifted out of their original context and implemented in another one without change. This, in turn, tacitly assumes that those responsible for implementing the procedure in the new context understand the underlying cause-effect relationships completely. This world-view, where organisational processes and procedures are elevated to the status of universal “best practices”  is  an example of a disembedding mechanism at work. Disembedding mechanisms are essentially processes via which certain facts are abstracted from their context and ascribed a universal meaning. 
• The reflexivity of knowledge and practice: Reflexive phenomena are those for which cause-effect relationships are bi-directional – i.e. causes determine effects which in turn modify the causes. Such phenomena are unstable in the sense that they are continually evolving – in potentially unpredictable ways. Organisational practices (which are based on organisational knowledge) are reflexive in the sense that they are continually modified in the light of their results or effects.  This conflicts with the main rationale for ERP systems, which is to rationalise and automate organisational processes and procedures (most often in a completely inflexible manner) .

Implications for organisations

One of the main implications of globalisation and modernity is that the world is now more interconnected than ever before. This is illustrated by the global repercussions of the financial crises that have occurred in recent times. For globalised organisations this manifests itself in not-so-obvious dependencies – both on events internal to the organisation and those that take place in its business, political and social environment. The important thing to note is that these events are outside of the organisation’s control. At best they can be managed as risks –i.e. events that cannot be foreseen with certainty.

A standard response to risk is to increase control. Arguably, this may well be the single most common executive-level rationale behind many ERP implementations. Yet, paradoxically, the imposition of stringent controls can lead to less control. One of the main reasons for this is that strict controls can give rise to unanticipated side effects. A good example of this is when employees learn how to game performance metrics and service level agreements.

The gap between plan and reality

The authors use a case study to illustrate how ERP implementations can be subverted by the side effects of globalisation and modernity.  The organisation they studied was Norsk Hydro a Norwegian multinational which, at that time, was undergoing an organisation-wide consolidation of its IT infrastructure and services.  Up until then, the IT landscape within the organisation was heterogeneous, with individual business units and subsidiaries free to implement whatever systems they saw fit. The decision to implement a global ERP system (SAP R/3) was a direct consequence the drive to consolidate the IT portfolio.

To reduce risk, it was decided to develop and validate a pilot project in one site and manufacturing plant.  Problems started to emerge during the pilot validation. As the authors state:

When the pilot was installed, it took three months of extensive support to make it work properly. …The validation effort identified more than 1000 “issues,” each of them requiring changes in the system.

Understandably, business managers were not impressed:

Some managers also argued that the “final” version should be based on a complete redesign of the pilot, as the latter was not structured as well as the more complex “final” version would require.

Yet, this redesign never happened. One can only speculate why – but it is a pretty good guess that cost had something to do with it.

The SAP implementation unfolded against a backdrop of a large-scale business restructuring. One of the other sub-projects in this restructuring was a business re-engineering initiative. Quite logically, this was subsumed within the SAP project. One of the main outcomes of this was the establishment of “common” organisation-wide processes to replace myriad local processes.  These common processes were to be modelled on “best practices.” Although this made sense from a management perspective, implementation was difficult because just about every local procedure had quirks that could not be shoe-horned into standardised global processes.

Side effects

The authors list a number of unintended “side effects” of the implementation. I will describe just a couple of these, referring the reader to the original paper for others.

Homogeneity to heterogeneity

Ideally, an SAP implementation is intended to provide a single “harmonised” solution across an organisation.  In practice, however, local differences and the existence of legacy systems guarantees that this ideal will be compromised. This is exactly what happened at Norsk Hydro. In the authors’ words:

…differences in business cultures and market structures in nations and regions [had to be accounted for]. In this process locals played a key role. They, in fact, took over the design process and turned SAP into an ally helping them get control over the overall change process…the SAP solution was customised for each individual site. Slowly, but irreversibly, the SAP solution had changed from one coherent common system to a complex, heterogeneous infrastructure.

Those who have lived through an ERP implementation may recognise echoes of this in their own experiences.

Side effects of integration

Although the above example illustrates the integration was perhaps not as complete as was intended, the implementation was largely successful in rationalising the organisation’s IT landscape. For one, it  replaced several legacy systems, thus (in theory) reducing costs. However, as the authors’ point out, integration means interdependence, which can create significant maintenance problems. ERP systems are notoriously hard and expensive to maintain. Norsk Hydro’s experience was no different: SAP upgrades were horrendously expensive and time consuming. As the authors state:

Typically, SAP is subject to rapid change because the huge customer base generates lots of new requirements all the time. Moreover, as its integrated nature implies, when any module is changed, the whole system has to be modified. Thus, in spite of the fact that the number of interfaces to be maintained decreases when an organization installs SAP, their complexity and change rate increase so much that the overall maintenance costs reach very high levels.

In spite of the standard solutions applied, the upgrades of the SAP code itself are also very complex and time consuming. The last upgrade (at the time of writing) enforced the SAP application to be down for 9 days! Also here there are many explanations.

For example, when all the work processes are integrated it creates a complex production lattices. Because of many errors in the software all work processes have to be tested extensively, etc.

This side effect is, in fact, an unavoidable consequence of the complexity and interconnectedness of ERP systems

Conclusion

In closing, it is appropriate to return to the themes mentioned at the start of this post. The case study discussed by the authors highlights the fact that ERP systems can have effects that are exactly opposite to the ones intended. Specifically, they can lead to less rather than more control, less efficiency and addition of complexity to the IT portfolio. Moreover, seen in a broader context, ERP systems are a microcosm of modernity: they attempt to coordinate activities at a global scale, implement disembedding mechanisms in the form of best practices,  and  are reflexive in the sense that they change organisational practices but are also changed by them.  The  interconnectedness and uncertain cause-effect relationships lead to unanticipated side effects that can completely subvert the original intent of these systems.

The authors summarise this well in the last few lines of the paper:

ERP installations in global organizations conform pretty well to the image of the modern world as a juggernaut, i.e. a runaway engine of enormous power that, collectively as human beings, we can drive to some extent but that also threatens to rush out of our control in directions we cannot foresee, crushing those who resist it

In my opinion, those thinking of committing their organisations to implementing ERP systems would do well to read this paper in addition to vendor propaganda literature.

Lost in translation: the gap between expectation and reality of information systems

Introduction

Those involved in information systems projects will be well aware of the gap between user expectations and the actual capabilities newly rolled-out systems.  Despite change management and training initiatives, users often complain that they can’t do this or that (which the old system did so well…) or that the new system has a terrible interface and is just too hard to use.  Although such projects may not be dubbed total failures, both sides of the IS/User divide are left feeling a bit cheated.  As Jim Underwood noted in a paper entitled, Negotiating the chasm in system development: some advice from Actor Network Theory:

While academics, managers and accountants believe that many IS projects, if not total failures, are at least very expensive mistakes, the developers themselves seem to believe that they are doing as well as could be expected and are producing many highly valuable systems. For managers the gap between idea and reality is caused by inappropriate culture or lack of commitment on the part of the developers; for theoreticians the cause is a failure to use or properly adhere to an appropriate methodology.

The gap between expectations and reality is often attributed to a misunderstanding of requirements that are articulated at the start of a project. One of the key selling points of iterative/incremental approaches to development, wherein the “system reality checks” are carried out at regular intervals (at the end of each iteration), is that they allegedly reduce or eliminate this gap altogether.   However, in reality, the gaps often remain, and none of the parties involved get their own way entirely.   Unfortunately these differences are often “swept under the carpet”, only to emerge later on.  In this post, I summarise Underwood’s paper, highlighting the insights he provides that can help project professionals  negotiate this gap.

The world according to ANT

Underwood’s work is based on Actor-Network Theory (ANT) which, for the purposes of the present discussion, can be viewed as an approach to studying systems that consist of interacting social and technical elements. According to Underwood, ANT can be considered as a type of stakeholder analysis. A distinguishing feature of ANT is that it considers non-human “stakeholders”  (or actors, as they are referred to in ANT) to be on on  an equal footing to human ones.  For example, a system is an actor with its own “viewpoint” and “agenda.”  I know this sounds a bit “out there” but hopefully it will make more sense as we go on. A key point in ANT is that all stakeholders are internal to the network. Moreover they exert influence on each other, and this influence can change in time (exactly like in real life). Influence is exerted through scripts– descriptions of actions that the actors are expected to carry out.   Actors inscribe each other with scripts through communication – written, verbal or otherwise.  Others interpret (or de-scribe) scripts in order to understand the motives actions of actors.   A plan to inscribe actors with scripts with the aim of achieving a particular goal (project objectives, for example) is called a program. Programs can be countered with anti-programs, which as their name suggests, are plans that work against the program. It is important to note that the process of interpreting scripts is done within a particular set of norms and rules that are specific to a discipline.  For example, depending on the specific development methodology followed the script “gather user requirements” may be interpreted in different ways.  However, the interpretation is rarely unambiguous – different stakeholders will interpret scripts in different ways. A manager may, for instance, assume that the end product of a requirements gathering process is a comprehensive requirements document whereas a developer might be content with informal notes and mockups.

Espoused and interpreted scripts

In real life scripts change their form as they are passed on and interpreted by actors: directives, however explicit they may be, are always open to being interpreted in different ways, depending on the backgrounds of actors. So, we have two levels of scripts: the original one as intended by the author and the interpreted ones that are put into action by other actors.  Following Argyris and Schoen’s distinction between espoused and in-use theories, Underwood calls these espoused scripts and scripts- in-use.  As I see it, the collection of espoused scripts form the “official” project while the scripts-in-use make up the “actual” one.

Betrayal and ambiguity

The fact that there are two levels of scripts points to the fact that the planned project rarely coincides with the actual one. There are always deviations. The point is, a plan (an espoused script) is never unambiguous, it can be translated into many different scripts-in-use. At times these translations may be viewed as betrayals – i.e. unacceptable deviations from the original script. At others, the content of a script may be translated covertly. This often happens when the content of a script is potentially contentious or vague. A good example of the latter is the script “the system must be  scalable”, which may be translated to a specific interpretation of scalability that the system developer can achieve.

Implications for project managers

One of the key functions of a project manager is to ensure that the project is on track. In other words, it is to monitor and control the project. Indeed this is one of the process areas described in the PMBOK guide.  Underwood contends that there are essentially two ways in which project managers exert control: overt and covert. In his words:

They either take a Machiavellian view or promote superficial agreement and high sounding concepts while secretly working to their own goals, or they insist on all players subscribing to detailed design specifications expressed in the language of some dominant discourse.

Of course, they may do both, depending on what specific situations call for.  However, according to Underwood, the actor-network view suggests that project management is more about facilitation than control. With this in mind, he offers the following advice (or scripts!) to project managers.

1. Don’t be afraid of politics: In the actor-network view, political stakeholders are actors who have their own scripts. These scripts must be incorporated into the project, interpreted in ways that keep all actors on side.  This may be a difficult process that requires skilful negotiation. Ignoring politically motivated scripts may end up jeopardizing the project.
2. Keep project boundaries broad and less technical: system planners and developers tend to focus on the technical aspects of projects.  Despite rhetoric to the contrary, the technical aspects of systems are given the place of pride in project plans and schedules.   ANT focuses our attention on the fact that the non-technical aspects of systems – humans, environment and (organizational) culture  etc.  – are just as important (if not more).
3. Track scripts: Underwood suggests keeping of track of scripts through regular audits. Scripts that have been dropped (i.e.  inadvertently forgotten) are likely to turn up again later when someone asks, “What have we done about X’.  The function of the audit is to remind everyone about actions that are required and reaffirm actors’ intention to action scripts that they have committed to.
4. Don’t cover up disagreements: Disagreements (differing interpretations of scripts) are often ignored because no one wants unpleasantness.  Underwood suggests airing differences with the aim of reaching shared understanding. This does not mean that all differences will be resolved, only that they are debated openly with the aim of achieving a consensual way forward.

Of course, this advice is somewhat idealistic and difficult to implement in practice: good intentions and the need for shared understanding are often forgotten in the heat of managing messy, real-life projects.

Conclusion

The main point made in the paper is that project managers should attempt to facilitate actions rather than direct or control them. The best way to do this is by enabling stakeholders to reach a shared understanding of what the project is all about and a shared commitment to actions that will make it happen.  Dialogue mapping, which I have described in many earlier posts is an excellent way to achieve this. But in the end it isn’t about specific techniques or methodologies – it  is about taking responsibility and genuinely caring about the outcome.   As Underwood states in his conclusion,

The simplest, most important and most difficult script recommended for all actors, but particularly project managers is “let go”. Managing a project can be compared to teaching students or bringing up children. We have some ideas about what we hope to achieve, some knowledge and experience, plenty of advice to give and a few techniques (of doubtful efficacy) for influencing behaviour. We feel responsible, we care deeply about the outcome, but we should be neither surprised nor disappointed when the reality turns out quite differently from anything we might have expected…

I don’t think I can put it any better.