Process for determining what Reporting Identifiers you need (IDT)

A process for successfully determining your reporting identifiers!

In the first post on identifiers I talked about what reporting identifiers are (ways to represent a view/perspective on your data) and some initial dos and don'ts.  The question remains though, what is a process for determining what views/perspectives are needed?

Not this process, hopefully

Putting in a new system (either an ERP or a specialised tool - eg for managing safety, environment or maintenance) is generally a highly stressful and usually expensive experience.

I think the main issues are:

• Businesses don't devote the time necessary at the planning stages (ie BEFORE the request for tender goes out) to work out what they really want;
• There is a general sense of fatalism ("well, this is going to be a disaster - I used this system at xx and it was terrible") that there is no way to avoid a highly painful experience;
• The people directly liaising with the implementation consultants aren't sufficiently expert in the way YOUR business process works/is structured;
• The expense leads to a "buffet/smorgasbord" mentality - where the cost encourages businesses to try and implement waaaay too much functionality.

Against this background, most of the attention goes to business processes and how the system will impact that.  This is not a bad thing, but at the same time, getting the identifiers wrong can stuff up the best process in all sorts of hidden ways (just ask AP/purchasing teams processing large numbers of invoices or POs how much they like identifiers with alphabetical characters in them).

Further, if you leave the finalisation of identifiers to the end, it often gets rushed and you'll discover that you can't easily report information that the business wants or needs.  Also, remember that if you have historical data, you need to get that into your reports at some point!

A process that worked

It suddenly occurred to me that over the last 7 years, I have been involved in 4 ERP implementations and 3 reporting system implementations.

There was a lot of pizza involved so it didn't feel like a punishment!
Well, not ALL the time!

For what it's worth, here's the process that I've gravitated to - it seems to work well for getting the necessary business teams involved and producing identifiers.

1. Establish what each module in the system can do and the primary business area that will use it.
2. Look at ALL the reports the business produces to determine the views/perspectives used.
3. Map those views and perspectives against the business area that GENERATES the data necessary.  This will effectively allocate the reporting identifiers to system modules (assuming you actually did step 1).  Note, this can be tricky as some identifiers are system wide.  In that case, simplest thing is to look at the primary owner of the relevant report to work out who "owns" the identifiers.
4. For each system module develop the identifiers, making sure to keep the identifiers "pure" (don't mix views in a single identifier)
5. Test your new business reporting AS YOU GO.  It doesn't matter if there are only 3 transactions in "test" - if you can't get those to report properly you won't get production data out either.

It is important to start out with the understanding that you'll probably re-write your identifiers a couple of times.  Also, someone is going to need the patience of a saint to coordinate the identifiers across all the modules (and therefore business areas) so that they are "pure" and don't double up.  It is here that testing reporting as you go REALLY helps, because it is a lot easier to discuss something you can see, rather than theoretically writing stuff on a whiteboard. (Been there, done that!)

Just one more thing

I was rereading the steps, and thought a diagram would be helpful, so here it is!

If only it was always that simple!

Ok, here we go.  

Let's assume a company with one current operating mine is implementing an ERP.  The ERP has three modules, a general ledger module, HR/Payroll and a costing/projects module.

Step 1 : Establish what modules there are and who will primarily use them.

In this example, it is really easy, because the GL produces balance sheets and profit and loss accounts (ideal for Finance).  The costing module allows breakdown of cost groups, so Operations owns that one and HR gets the payroll module.

Step 2 : Look at all reports and determine the view/perspectives

The reports produced by this company are shown in green.  Against each is a dark orange scroll which shows the views used.  In this case a "Nature"view refers to "What we bought", so would contain headings like consultants, salaries, wages, rental, contractors, postage etc.  An "Activity" view refers to "Why we bought it", so would be headings like mining, processing, recruiting etc.

Step 3:  Map those views and perspectives against the business area that GENERATES the data necessary. 

The Financial Statements are clearly GL and nature related, so nature was mapped to Finance ownership.  In this case Finance is considered to Generate the data because of the transactions done re the balance sheet.

The Management Reports were primarily Activity focussed (ie reported mining costs by nature) and so Operations picked up the ownership of the Activity view.

HR obviously ended up with the Payroll reports.  Note that there is no "view" shown here - this is only for simplicity.  In practice HR often owns a primary view (that of Responsibility) and the interaction between this (represented by the org chart) and an Activity view is often the most confusing to sort out.

Step 4: For each system module develop the identifiers, making sure to keep the identifiers "pure" (don't mix views in a single identifier)

In this case, the GL codes represent the Nature view, and would be developed by finance.  Operations would come up with the Activity view, represented by cost centre codes.

PRACTICAL TIPS 

DO :

• Follow a process, ensuring that the identifiers are clearly mapped to reports AND an appropriate module.
• Test your reporting as you go.  At the start you can test your proposed identifiers by trying to map your existing identifiers to your new ones - that will generally tell you if you have missed anything important.  Then you can produce existing reports using data from the old identifiers.
• Make sure that all the business areas understand that although they own the identifier, it is SHARED.  In particular, be careful of the impact of convoluted Cost centres on purchasing data entry times.
• Review the reporting to make sure it is used, useful and relevant.
• Keep it simple.

DON'T

• Leave the identifiers and reporting to last; 
• Try and do reporting identifiers without business involvement.  It may seem faster, but it isn't.
• Forget about historical data!

What do you think?  Will the process work for you?  Let me know what has worked for you in the comments!