Digital Oman - Connected to the Community, Wired to the World

Let's start with a simple definition: "ERP is a piece of software which has a set of integrated modules to manage the various functional (for example, finance, production, HR, etc) activities of a business or organisation."

This is how I define ERP and I am sure there are others, but I believe it's simple and clear. The reality is that ERP is usually far from simple because it tries to link and automate the various processes in a business. This means that an ERP is modelled on a view of business processes and not functions - this is important. Let me elaborate by way of a story.

In a typical business, the Stores Department is responsible for stocking items and will send purchase requests to a procurement section/department which will then raise purchase orders as required. The items are then delivered to the stores and then consumed by an end user function in the organisation. The invoice in the meantime will arrive and Finance will have to pay it. In an ideal world, all of this happens without any problems but we all know that the real world is very different.

We have all been through the experience when something is needed urgently but somebody in the chain has different priorities and your urgent need gets pushed further down their priority list. While it's being processed the supplier says he won't process all of the order unless outstanding invoices have been settled. Finance says it won't settle because there are discrepancies which need to be explained. So, you're left running from pillar to post trying to get your issue(s) addressed.

I am sure you've experienced this yourself. Each department builds up a set of controls such as extra copies of order requests, sign-offs on confirmations, or requirements for specific documents when processing certain transactions because each department doesn't want to be held responsible for any problems that occur. This means processes become more lengthy, less efficient and less effective - often functions (departments) will require substantial pre-requisites in terms of documents and information before processing because of difficulties in the past. Continuing the story:

For you - as a business unit manager - it means chasing people all over the organisation trying to get what you need for your activities. Along comes a smart chap from a software company who explains the virtues of ERP. He tells you all about the integrated nature of their ERP. He explains the ability to capture data once and make it available to all; and he also tells you about being able to track a transaction across the organisation so you know where it is and who needs to expedite matters.

Great! An ERP can save you a lot of hassle and make life easier for you and everyone else in the organisation. Indeed, an ERP has the potential to do many things, bringing substantial benefits to a company but it isn't a simple road to travel and far from painless. An ERP means that other departments/functions have to know what's happening elsewhere in the organisation. It means that if one person in the chain (business process) doesn't do something or gets it wrong the consequences can be dire. The flip side is that things generally get done once and with everybody having access to up-to-date information. It positions people better and allows them to make better informed decisions in a more timely manner. Now, getting back to the story...

You soon realise there are many good ERP software packages and you embark on selecting one - this is almost a project in itself (definitely a separate story anyway). After several months of hard work you arrive at a selected package. You agree scope of work, negotiate a contract and begin the project of implementing the system. The problem with selecting such software is always the same - what is it that you really need, this being different from what you would like, which is different from what can be implemented.

The implementation begins with a re-confirmation of requirements and then a process mapping exercise where implementation consultants pitch-up and map your business processes to the application's processes. The first set of surprises is that there is functionality which the ERP doesn't support which many people in the organisation believe to be important to the business. In addition, there's functionality you want to implement which is new but it means changing policies, procedures and the way people work. Depending on your team, you will either face a reaction of: "This is really good for us, so let's do it, and let's do it now!" (these are the go-getters) and there are those who say it can not be done "because of this, that and the other" (these are the no-wayers) and then we have the those with a reaction anywhere in between the two camps.

As the discussion on what will change and what will not continues, you will notice changes in your team's behaviour. Your colleagues will start to realise the implications of what is happening from an organisational stand-point, and you will find some people becoming entrenched in their positions, adamant that some things have to be done in a certain way.

As you look into these issues you will find that the control of resources is changing hands and that the implementation of an ERP will cause a change in the balance of political power in the organisation. People will also see that they are going to have to rely on other departments for data and information and they will no longer have direct access to certain things.

With the possibility of changes in responsibilities, people will start positioning themselves to make claims for additional staffing because of the ERP. You can see your whole idea of simpler more effective working coming crashing down around your ears with all of these demands, or maybe not?

This is the crunch point. If you have people from the top of the organisation who, with a clear vision, are going to help lead the organisational change, as well as managers who will manage the complexity of the change, then you have a chance of realising the value that comes from implementing an ERP. Otherwise, as in a lot of ERP projects, a tremendous amount of time, effort and money is spent, the project fails, then it is unceremoniously dumped.

The implementation of an ERP is an organisational change project, the only difference is that it's technology driven and that means all aspects of organisational change have to be tackled as well as those related to technology, which, thankfully, in most cases are not too complex.

To wrap up, let me give you the gist of the answer that I gave my client - an ERP isn't value in itself, but value comes from the result of using it as a tool. Like any tool it must be used in the proper manner, otherwise whatever you are trying to do will run the risk of taking longer, not being of the desired quality nor completed.

Taking this a step further, for you to measure value from an ERP you must first be clear what you seek to gain and how you will measure that benefit. ERPs can give numerous benefits but only a few are felt at the bottom line - many others have an indirect effect such as better decision-making and improved customer handling. But to achieve any benefits one must be able to implement successfully and that means managing change successfully.