Enterprise Information Systems

Tags: KC OB

Understanding Enterprise Information Systems (ERP, PLM, IS, …)

In the course of their work the GHR Consortium have come to gain in depth insight into the area of Enterprise Information Systems (like Enterprise Resource Planning, Product Lifecycle Management, …).

This text reflects onto this experience in order to provide input for people considering launching such projects. In this text we use the term ERP generically for all current approaches to Enterprise Information Systems, for example ERP systems, PLMs, CRMs,  …

When talking about ERP many aspects are often concerned ranging from software to hardware through organisation and change. As we'll see below this is in fact the consequence of historical development and is the source of many problems.

As we'll discuss, imposing unwanted and unsuited change over the organisation at prohibitive costs isn't the only path to follow for ERP.

However, as this is the forced path for ERP vendors (as we'll explain further), and they have gained high influence on the market today, it is the path usually followed, resulting in the well known high failure ratio of ERP projects.

We'll conclude by showing that Enterprise Information Systems aren't doomed to this failure, as long as they break free from ERP vendors' methods and constraints, and consequently break free from ERP vendors all together.

After reading the below elements you should be able to draw the same conclusions and therefore take initiative for your own Enterprise Information System projects, giving yourself more insight and better options.

The "ERP vendor method"

The reasons for the high failure ratio ERP projects are a subject of many statistics, reports, articles and debates. When discussing with organisations which have experienced ERP deployment, it commonly appears that the reasons for failure are quite the same. These reasons in fact lie in the very core of ERP paradigms and concepts.

To understand what happens, here is an overview of the procedure which is usually followed when initiating an ERP project. We'll take the average client who follows the usual "best practices" promoted by ERP consultants and aims at optimising ROI for the client and starts by benchmarking the available offers and products.

For this, people mostly tend to benchmark different offers based on how much it will cost (usually Total Cost of Ownership on three years) and how long it will take in order to deploy a system which will provide the maximum functionality (best potential for supporting the organisation). This is used for evaluating the ROI parameters.

To gain confidence (and still following "best practices"), the clients will often actually ask the ERP vendors to illustrate their claims by demonstrating the offer on a very restricted sample of functionalities.

But in fact, when looking closely, two important errors are done already at this point:

  • The first is that the impressive offered functionality (usually very broad, with things like CRM, SCM, PRM, PLM, POS, B2B, B2C, …) blurs the fact that it isn't usually really suited to the needs and will in practice require extensive adaptations which are largely underestimated and masked by the vendor during the benchmarking/commercial/marketing phase. This makes the real cost and delays explode out of the initial budgets.
  • The second is that this procedure totally misses the point that the most important is not how fast and how much the system will offer but how much of it will actually be accepted, adopted and used by the organisation's employees. This second point has to do with change management. Much has been written on this subject, but in the field of ERP one must notice that little has been done. In fact, the whole ERP concept is badly suited as far as change is concerned, and this alone explains many failures.

Before going further, let's investigate why this is the case.

One primary cause of this situation is that ERP vendors are forever pushed forwards by competition to increase the functional coverage of their systems, because they know that this is classically an important selection factor for their clients. This has two effects:

First it increases the complexity of the systems making them more and more difficult to manage, deploy and adapt. This explains the first point above, because in order to satisfy the broadest possible range of potential clients the system tries to offer "everything" making it totally unusable as is for a specific organisation. Therefore large parameterisation and customisation work is performed to remove useless functions, adapt existing functions and add missing functions.

In reality the cost of this alone (initial product cost and adaptation costs) will quickly approach that of a specific development done by experienced teams (both of the domain and the information technologies). It is a common reflex in the field to totally discard the idea of using a specific developments (done by a service company) usually without in depth evaluation (specific developments frighten people because it clearly requires experienced teams when talking about Enterprise Information Systems, and purchase personnel are more accustomed to buying products than services).

So, in order to reduce the effects of this, and to justify the choice of their overweight products, vendors try to spread the idea that in addition to adapting the product to the organisation the organisation should also be adapted to the product. They enforce this by suggesting that this will allow bigger improvements as the organisation required by the product is meant to be optimal. Of course, this doesn't mean no adaptations of the software will be needed, far from that. Additionally work will now be necessary for tasks such as organisational improvements and reengineering.

At this point (of the ERP vendor's offer) the organisation encounters its biggest difficulty (and the ERP project starts to hit failure, after being already over budget because of the above unplanned issues) because the abrupt level of change imposed by the product (mostly to protect the vendors interests) faces the reality of human organisations. The project is usually already in a bad status by then (late, over budget, unpopular, …) and it is in fact going to hit its biggest obstacle. In many cases, it won't make it (or it will be strongly redefined), and will come and increase the statistics of ERP project failures.

Enterprise Information Systems made possible

As explained above, the current situation is the result of the historical development of ERP vendors and in particular their race to functional coverage for benchmark scoring. As discussed, this situation isn't well suited to the real requirements of Enterprise Information Systems. ERP therefore fails because the solution doesn't fit the problem.

Our concern is now to try to step away from this dilemma and create a new approach to Enterprise Wide Application which doesn't fall into the same traps.

For example, a simple idea (and not so bad if you evaluate correctly) could be: Just use specific development and get a competent team (external or internal) to develop our systems over 1 or 2 years. This system would be specified to perfectly fit our company and support its evolutions. Using software development best practices (Agile Methods, iterative and incremental, …) this should be efficient.

This could be a solution but we don't believe it is the best, although it appears that in quite a few cases it is better suited than the classic ERP approach (GHR Consortium members are personally aware of some such cases). But it has some major defaults which are for example: cost of starting from scratch, rely too strongly on the team's competencies, how does it address change, what about long term, …

The GHR Consortium therefore defined an offer which addresses these issues which has been adopted by GHR Software and is proposed by them under the name SEIS Offer.

This offer is characterised as follows:

  • Avoid main ERP issues, namely: Impose needless, costly and risky organisational and business changes. Explode budgeted costs and delays.
  • Organisation/habit/human change must be spontaneous (see KCard "Magical Change") rather than imposed. That is, the change won't be pushed by the IT teams but by the business employees. Creating this isn't a simple matter and requires in depth thought and design of the offer (improvising here isn't a possibility), with both psychological, management and technical expertise.
  • No unnecessary changes will be done. In particular the system should fit the organisation and not the other way around! This doesn't mean that no organisational changes should be done, it means that they must be motivated by true business criteria and not IT constraints.
  • The solution's agility is more important than its initial capabilities, because whatever the latter are these will soon be outweighed by the former. Enterprise Information Systems are made to last and therefore they must adapt to business changes (and once again, not the other way around). The initial version is only one in many. A system which fits the needs but is too tedious to adapt to change is pointless.