The most important part of a system implementation! (SYS)

Remember that the basic processes have to work!

Not your desired action.

In every system implementation I've been involved with, one of the most time consuming processes has been in determining how the system should handle basic processes.

From an ERP perspective, basic processes includes the paying your people, processing customer invoices, the raising of purchase orders and dealing with supplier invoices.    If you analyse your transactions, you'll find only a few types.....but there will be a large number of transactions!

However, too much of the time spent was devoted to working out what to do with the exceptions (warranties, returns, partial credits, service exchange items) and (with the absolute benefit of hindsight!) not enough time was spent making sure that the hundreds (or thousands) of purchase orders, customer invoices/supplier invoices were able to be processed smoothly.

Actually, a bigger sign would be better.

Problem #1 : If you can't process basic transactions, your reports will be wrong.

I'm continually besieged with stories about system implementations where, post go-live, supplier invoices can't be raised, purchasing processes stop, supplier payments don't happen, report deadlines are missed.  I've been involved in them, and I've tried to clean up after them.  I can say with complete certainty, a very small amount of effort during the implementation would have avoided a very large amount of pain.

If a (large) portion of transactions are sitting in in-trays waiting to be processed, your reports will be wrong.  This can VERY easily lead to secondary reporting systems springing up within the business (you know, the excel spreadsheets that suddenly spring up as people try and capture the information they need themselves).

Problem #2 : Taking the rigour out of the system process.

In order to fix problem 1, the usual response (and, given rapidly piling up invoices and orders, you can see why) is to turn off a lot of the checks/controls that were painstakingly built into the process during the implementation.  

Yup, that'll do.

These checks/controls are often part of the reason the business decided a new system was needed in the first place....the desire to have a more controlled, standardised process is often a key driver.

Taking them out not only reduces the control and standardisation, but it also increases the possibility of coding errors or incorrectly processed transactions, which will impact on the accuracy of your future reports.

Practical Tip #1 : Don't build in system controls you can't support.

So, on the one hand you have the consultants who are either telling you "The system was designed to work like this and it can't be changed" or "The system is really flexible and you can change it how you want".

On the other hand, you have auditors (internal and external), the board or just the voice in the back of your head telling you that this is your perfect(last?) opportunity to improve controls.

RESIST!  The simple fact is that every control that is added to the existing process requires time - spent by the team in processing or chasing up, or by managers now having to approve everything.

This reaction is not a good thing.

For example, there is no benefit to having a senior manager approving 100 purchase orders a day.  The orders will either not get approved (worst case) or will get approved (bulk approvals for the win!).  The likelihood of the senior manager actually having the time to spend to PROPERLY consider and approve that many is miniscule.  (Also isn't it amazing how many approvals are given when the senior manager is away or tied up in meetings????)

Focus on the controls you can realistically manage with the teams (and time) you have.

Practical Tip #2 : Test, Test, Test.

Somewhere, buried in the documentation for the system implementation plan, there will be user acceptance testing or UAT (there are other meanings to UAT, but this is a family friendly blog).  When the implementation schedule slips, UAT is often one of the things that tends to get shorter.  Now, in some functions, that might be ok, but in your core functions it isn't.

Entering basic purchase orders, generating customer invoices and producing supplier payments is basic stuff.  Test it...now.  Then do another test.  

Do not accept "that will be fixed when <some other module which is marginally related> is configured".  And test it properly.  Actually print cheques (or produce electronic payments), print the orders (you'll be amazed what a 255 character limit can do to a purchase order line).

Finally, specify in the contract that UAT can't be passed until you can process AT LEAST the number of transactions you are currently processing per hour.  You're not going to have less transactions going forward.

* * * * *

Of course, every company and implementation is different.  My key point is to make sure that you can do the high volume basics first.  Exceptional transactions are just that...exceptions.  

Do I have it right?  What is the most important thing for you?