Business Accent

Bridging the Gap

The evaluation and implementation of an ERP application is separated by an all-important intermediary step known as Gap-Analysis.

Ipshita Basu Guha

People do a lot of discussion and brain-storming on evaluation and implementation of an ERP application. But not many are aware of a crucial step that exists between these two phases. This intermediate step is called Gap-Analysis. The output of the analysis is generally a document which elucidates the the As-Is and To-Be factors, the gap between the two and how it can be bridged. It is all encompassing and not restricted to few areas of an organisation.

An ERP application is generic in nature and is opted for when an organisation does not want custo mised application to suit its needs. It is an application which can be implemented in other organisations of the same domain and in case of Tier-1 application in diverse domains. The size of the organisation is not as important as the business. There are applications which can be implemented for a $1 million organisation as well as a $100 million one too. The processes incorporated in these applications are standardised and based on industry best practices. Organisations will have to go in for a detailed Gap-Analysis prior to commencement of the implementation phase since there is bound to be considerable gap between the present and the desired future conditions.

As-Is

As-Is as the term suggests is basically the present condition of an organisation and its systems, strategies and processes. Documenting the As-Is state helps in clearing all doubts about how things are functioning presently in each and every area of the business. The implementation of ERP is not done by all the employees. It is akin to a play in which there are few central characters who are involved in the entire plot and supporting characters who come and go during various phases. The core team comprises representative members of all the functions. These representative members may or may not know all the intra- or inter-department processes. Hence there is a need for the As-Is document.

To-Be

To-Be is the state of affairs in an organisation after the implementation of an ERP application. These applications have specific processes for various functions. These might or might not be similar to your existing processes. There are additional issues like access control which come into place where people can view data only on the basis of their roles. Generally these things are not in place during the pre-ERP days. The To-Be document details how the processes and systems should and will be. It acts as a navigator for your implementation phase. The implementers can verify whether the system is being configured as desired or not.

What is Gap-Analysis?

There is always a difference between the As-Is and To-Be states of an organisation from the strategy, structure and systems’ points of view. Gap-Analysis pertains to identification of the gaps and preferably segregating them in terms of their criticality. This is followed by analysis of the extent of the gaps and the methodology to bridge the same. Gaps can be identified through developing test cases or building scenarios to study the To-Be system. Business Process Modelling and Simulation can also be done to have a walk-through type feel of the processes. It is similar to say a flight simulator.

Extent of analysis

How do you define how much analysis is adequate? Some people have the habit of overdoing things and in the process might just go too deep into preparing the As-Is and To-Be documents. Time is a crucial factor in business and most things are best left optimised than maximised. The ERP project manager and his core team should first dwell upon identifying the Critical Success Factors of the project. Garnering top management support, user training and so on is critical for any project’s success. The important processes of the business which are typical and unique in nature should be identified and analysed. In most companies purchase, accounts and human resource are more or less standardised systems since they are governed by similar laws of the land. There is not much scope of deviation since statutory requirements will have to be complied with. Hence it is pointless to try extensive business process re-engineering or modelling for these modules. Any business should focus on the processes which are critical to the business.

The important areas are production, operation, warehouse and logistics which can give competitive advantage to any company. This is true in case of manufacturing companies. Similar parallels can be drawn from service industries too. How will you reduce the circuitous route of existing processes to simple and efficient ones? How will you handle scenarios which are not supported by your ERP application? Will you incorporate plugins, third-party software or modify your processes so that the deficiency is taken care of? These are some of the questions for which one needs to seek answers. The focus of the analysis should be on the factors which are important from the angle of strategic and competitive advantage.

Write or draw?

System analysis and design can be done by a character-based process or graphics or in a combination of both. It is said that a picture speaks a thousand words. The problem with having only written documentation is that the person who writes may not be able to clearly explain what he actually wants to say. Similarly, the person who reads the document may not understand it in the way it has been presented to him or intended to be comprehended. These are sure-shot causes of confusion and opacity. The gap that we are trying to bridge might just get widened. Hence, there is a serious need to incorporate symbols, pictures and flow charts to put across the points. A variety of tools can be employed based on the size, complexity and budget of the organisation. There are various tools available in the market to do this type of analysis. The simplest one is to use Microsoft Word to create text documents, workflows and process charts. An analyst does not need to have advanced computer skills to do so. The basic idea of auto-shapes, connectors, lines, arrows and shapes can see you through the task of creating a process flow document in Word.

Another option is to use advanced tools like Visio. I recall reading on one Web site that people normally do not use Visio because they do not know what to use it for. Visio can be used to draw process charts, organisation charts and module interactions. There are lot of in-built shapes in Microsoft Word which can be used with little difficulty. Organisations can also develop their own in-house templates for this purpose. Unified Modelling Language (UML) is also used for preparation of specification and documentation of business systems. It uses lot of graphical representation. The architecture of UML is independent and not related to any type of application. One of the most common UML design tools is Rational Rose. Rational Software came into existence in 1980-81 and was founded by Paul Levy and Mike Devlin. It was bought by IBM in 2003 and is featured along with Tivoli and WebSphere.

While modelling a system we have to show the interaction of human beings with each other to facilitate better comprehension of the system. Let us take a regular purchase process. We can simply document that a person raises a requisition in the organisation which is forwarded to a purchase function which then generates a purchase order after due vetting of various vendors and releases the same. Compare this to a diagram which says clearly ‘who’ are the persons who can raise ‘what’ type of requisitions, and ‘when’ and ‘how’ do they actually forward it to the purchase function. Do they directly send it by hand, or get an authorisation of their superiors and then send, or there is an automated workflow where the system should identify the generator of the requisition and send it to the higher authority for authorisation and confirmation that the purchase should be done.

Similarly, who receives these requisitions in the purchase function and creates the purchase order should be defined in the model. In some cases rate contracts are in place so there is no need for ‘request for quotation.’ These exceptions should also be documented. Organisations also have rules like a certain level of personnel can order items of specified value only. This information and validation should appear in the process diagram in order to verify compliance with the same at a later stage. The methodology and choice of tools vary with organisations. This modelling and documentation exercise also helps gain clarity of the implementation methodology that will be most effective. Finally we know where we are, where we want to be and how we intend to do so. The question that arises now is how do we tackle the implementation phase?

ERP implementation has various flavours like comprehensive, middle-road and vanilla (Parr and Shanks, 2000). Which one is suitable for you? That is a topic for another discussion. Let us leave it for some other day.

The author works with a pharma company as Business Systems Analyst. The views expressed here are her own and not necessarily those of her employer. She may be reached at ipbasu@rediffmail.com