Getting reporting identifiers right!! (IDT)

Reporting Identifiers - spend the time to get them right!

What's the problem?

In my experience, the difficulty of preparing any report is directly linked to how good the identifiers for the underlying data are.  

As a simple example, consider any report you have to produce where you have to summarise some detail into groups.  Simple examples are grouping detailed info into a summary (eg all your individual cash accounts into the "Cash at bank heading", safety performance by location (or type of incident), environmental surveys by type etc etc).  

If you are grouping, having all the detailed info in group order makes it easy (so all the detailed info is neatly lined up together).  If you have a long list and it is all mixed up (think a list of safety incidents which you have to sort by site), then it is not so easy.  

If we want to get total interest for example?

Worse - think about where you have had to split a single account into several categories (airfares by department anyone?).  That can take hours!

Having the right identifiers is CRITICAL to making the reporting process easier.

The thing is, it is really tricky to predict all the future reports that someone is going to ask for (think what happens when there is a change to a manager, GM or CEO, or a takeover, or cash squeeze....)

What are identifiers?

The best way I've found is to think of an identifier as a view(perspective) of your business data. 

So, from a financial perspective, if you want to see your financial data from different perspectives, you need to have different identifiers.

Let's look at producing information for the financial statements P&L as an example.

Simple, 2 perspective example

In the above diagram, you have your business data in the green box - in this case, financial transactions, but it could equally be environmental survey data, or safety incidents.

The orange boxes represent your view/perspective of the data.  In this case a "nature" view of the transactions (so, looking at the data in terms of "what did we buy") and a "functional" view ("why did we buy it?").  

These perspectives are identified by two identifiers - in this case I've called them "GL" and "Cost Centre".  So, to produce the financial statements, I prepare two different sub reports -one for Nature and one for Function- with a different perspective, each one based on a different identifier.  I then combine them into my target report, the Financial Statements.

All good, because I have identifiers which specifically represent that view or perspective. Assuming I haven't fallen into any of the traps (see below!) I should be able to run a report for each perspective (or directly link my financial statements to that perspective). 

Also, with only two perspectives, life is good, mostly.

It's a Trap!

You just knew that was coming, didn't you.

Identifiers then, represent a perspective or view of the business data.  Having the right identifiers means that you can easily get a report tailored for that particular view.  So, what's the trap?

Not so simple anymore

The main traps with identifiers are:

• Having too many.  It is really, really easy to end up with multiple views that are almost the same thing - I have often seen this with functional vs responsibility views - in many organisations these are very close together (when you start at least!).
• System doesn't have enough identifier fields.  and so, we convert them into multipurpose fields, with multiple identifiers in a single field.
• They aren't "Pure". It is really important that you don't mix and match views inside a single identifier.  For example it is really common to see "admin expenses" in a Gl Chart of Accounts.   Generally, this is a problem because the GL is (usually) a "Nature" analysis, and admin expenses is not something you buy.
• They mean different things to different people.  When you are having discussions about this, are you both on the same page?  I had a discussion recently about "Cost Centres"....and this term is probably one of the worst.  I meant "the activity that the costs were incurred achieving" and the other person meant "the department doing the work".  Historical experience can deeply embed a certain meaning for commonly used terms (like "profit centre" or "cost centre").
  
  
• Having the wrong ones.  It is really, really important that identifiers are considered against the substance of your business and not simply what "the report we currently have" shows.  Remember that these identifiers are what the team on the ground have to work with in managing the day to day activities.  Get this wrong and it makes their life harder....EVERY DAY.
• Putting them in the wrong system or module.  From bitter experience, I can assure you that identifiers do NOT all need to be in the GL or Costing subledgers.  If you have an appropriately rigorous subsystem - have identifiers in there and just a control account in the GL/Costing.

Practical Tips

Ok, there is a lot of traps, so what can you do to manage them?

DO

• Take the time to discuss internally what information you want to get out and how it should be seen (this is your views/perspectives).
• Write down what information you want to keep and how you want it reported.  Make sure the consultant understands the reporting requirements.
• Keep identifiers to a minimum - there really aren't that many ways to view a single business.
• Keep the identifiers pure!  Most reporting systems (especially EXCEL) will let you mix and match later.
• Be very specific with your implementation consultant.  They don't know your business, so don't assume they know what you mean.
• Remember that you will probably be reporting in Excel (because most applications can't format the way you want it)...don't sweat the small stuff in the reports in the system.
• Make sure the identifiers enable the team on the ground to get the information they need.  They generally need more detailed information - it is FAR easier to summarise detail than to break up a summary.

DON'T

• Let the consultant give you your master data.  Sure, take the template and modify it, but don't just upload it!
• Believe the consultant when they say "you can't use that field/module for that".  Computers don't speak English.  They store a series of 1s and 0s.  As long as the module has the functionality you need, use it.
• Create multiple level, highly complicated IDs.  Simple is better.
• Skimp on the time taken to get these right.  You'll regret it later.

So, what do you say?  Let me know in the comments if I've got it wrong or you have a different opinion.

Are your identifiers making life easy for you?