As is Business Analysis

As the second post of our series, I thought it would be useful to deal with what can be one of the most challenging aspects of a successful ERP implementation.

All too often, there is a decision made by senior management that “a new system” is needed to help solve any number of problems that are evident within a business. At this point, the task is usually given to someone to “find” a system that is suitable and more often than not, “the system” needs to slot right in!

This is a good point to STOP!

There’s obviously a need for some improvements, and chances are they may well include some new software to streamline things, but until you can ascertain exactly where the problems are, and look at other options to alleviate the business problems then just simply going an buying some expensive software can exasperate the existing business problems.

So, how do you find the problems? The answer is to perform an “As-is” business analysis exercise, which depending on the complexity of the business and it’s functions can take anything from 2-3 months upwards.

There would be those who would be tempted to skip this, and move straight to the vendor evaluation, but to do this would be a mistake – how do you know exactly that the vendor you are looking for will fix the problems you are experiencing if you don’t know exactly what those problems are, and how they impact the business. This is exactly what Business Analysis is for – to find out exactly how you are operating as a business.

Talk and Listen

The best way to understand a business, is to live it – sit with staff, interview and talk with them, listen. This will allow you to build up an understanding of not only how they operate, but also the pains and pressures they are experiencing.

It will also put you in the unique position of having an overview of all the business and how it currently operates – usually using processes that have developed haphazardly over the years. As this understanding of the business develops, it’s important to document it – there’s a whole methodology for the documentation of business processes, but essentially they document:

  • Roles &┬áResposibilities
  • Management Processes (e.g. for strategic management decisions)
  • Operational Processes (e.g. Purchasing, Sales, Design and Manufacture)
  • Support Processes (e.g. Accounting and Technical Support)

Once you have documented the major business processes and roles, you can begin to document gaps or problems with the current processes – these are what will be your “shopping list” for vendors to illustrate how their particular solution would fix them. Of course, the business problems may be able to be solved by none technical means – changing the process slightly or introducing alternative processes that better suite the current environment – this is known as Business Process Re-Engineering.

Our particular client took around 2 months to fully analyse the business. This was time well spent as it gave senior management the confidence that when we evaluated the software, it’s capabilities would be measured against set criteria.

Next we’ll look at the software that was evaluated, and the decisions that were made in choosing the preferred ERP / MRP Software.