Consultant David Carter
Share this content

Management pack: Are you a player or a spectator?

24th Jun 2006
Kashflow logo

Reading the recent articles on management report packs, David Carter objects that most of this stuff is ancient history. Too many accountants think their role is to sit on the touchline as a spectator and add up the score after the game is over. Not good enough: it's time for them to take part in the game itself.

Recently we've had a series of articles discussing what top managers would like to see in their monthly management report packs. And a very worthy discussion it is too. Don't get me wrong: obviously it's important that the top brass have the information for their monthly board meeting. But board meetings are simply an exercise in back seat driving. By the time they get to the boardroom the events under discussion may have happened over a month ago. Meanwhile, the people out in the field are grappling with today's problems.

Forgetting for a moment your services to top management, what help do you as an accountant give to your customer-facing staff, to the people who actually do the work? Are you the typical accountant who sits out the game on the touchline? Then, after the game is over, you add up the score and say who won? Or do you make a point of getting out there onto the pitch where the action is, getting your hands dirty, part of the team?

How to help customer-facing staff
How can you help the customer-facing staff? Let's take an example: suppose your company has a sales manager with a monthly sales target to meet.

In your score-keeping role you might wait till the month is over, then produce a P&L that tells how she failed to make her budgeted sales this month.

But in your team-player role you might write a Daily Sales Report which shows her the value of sales invoiced so far this month. And if, seven days before month-end, it's clear she's going to miss her target, you give her an Outstanding Orders report in due date order. She has a quick look, sees there are a couple of orders due for delivery early next month, gets the customers' agreement to bring delivery forward, and successfully makes her target.

Please Login or Register to read the full article

The full article is available to registered AccountingWEB.co.uk members only. To read the rest of this article you’ll need to login or register. Registration is FREE and allows you to view all content, ask questions, comment and much more.

Replies (5)

Please login or register to join the discussion.

avatar
By Anonymous
21st Oct 2005 10:19

Start the ball rolling ....
Appologies for not having responded earlier - am currently writing a End-User Report Generator (desktop based) in conjuction with this topic. The resulting reports will be stored in a SqlServer Db (BLOB) and deliverable over the internet, which in itself raises issues, however ...

When addressing Standard Reports we need to regard some areas as a 'given'; these include:
- ability to have user defined reports (report generator)
- adequate security model (internet solutions)

The critical area is surely the data made available to end-user and how it is used
- selction criteria
- sort criteria
Because of the potential complexity of the underlying data in most accounting systems, we need to have wrappers around the data to ensure the user only gets meaningful information to select. These wrappers can take the form of a Query in Access, View in SqlServer etc.; but will bind all the constituent tables into a single entity

The broad areas to be considered are (what standard reports are required)
- Financial (i.e. PL, BS, TB)
- Nominal (i.e. Budgets, Activity, Day Books)
- Customers (i.e. Debtors, Activity, Name/Address, Statements, Standard Letters)
- Suppliers (possibly same as Customers)
- Bank (i.e. Reconciled/Unreconciled, Customer/Supplier Receipts/Payments, Bank Receipts/Payments)

The results needs to be a number generic model data structures which can be adopted either in whole or part by software producers with
- standard naming conventions
- suggested data fields
- suggested sort fields
- suggested selection fields

David Carter started to put something together but unfortunately I cannot find it again on the site

It would be useful at the AccountingWeb end if you could set up a specific area (thread) on the site containing this topic. Unfortunately it is a complete nightmare having to trawl through different areas trying to find things - also by grouping everything in one place it would encourage greater participation. At the moment there are a considerable number of people accessing the site but only a 'hard-core' actually engaging by making a contribution (encouraging spectators to become players)

Thanks (0)
John Stokdyk, AccountingWEB head of insight
By John Stokdyk
07th Oct 2005 13:15

A management reporting "standard"
JC - Your comments struck home here at AccountingWEB.

We will continue to feature pivot table coverage from David because of the huge level of interest and demand for material on this subject.

But we do also recognise some of the inadequacies that lurk within software systems and organisations about the real information needs of management.

It may be an ambitious undertaking, but we are quite interested in working towards some kind of community standard for management reporting. We will continue to address this objective in articles over the next month or two and welcome input from all our community members.

Your comments have helped to guide us so far and we look forward to expanding the debate further - and hopefully reaching a point where we can publish some principles and ideas that will provide practical assitance to AccountingWEB members.

What are the main points or principles you would include in such a standard?

John Stokdyk
Technology editor
AccountingWEB.co.uk

Thanks (0)
avatar
By dahowlett
03rd Oct 2005 12:56

Over simplification
David is right to say the front office is where the business action takes place but his remarks are an over-simplification.

In the real world, departments operate independent of one another - what I call silo based and work out of different mindsets. That's where the rot starts.

It is extraordinarily difficult to connect front and back office systems - even those that are built for the SME. Front office systems tend to be dynamic and were never built to integrate to other, static systems like accounting applications. This is important because in theory at least, front office activity has a bearing on back office results.

There's also the issue of relevance. You might for example notice that Widget A is selling very well and there's a risk of stock out. Is this a matter for the FD? Perhaps but what can he/she do about it? Probably nothing. That's a matter for both the supply and demand side of the house.

Where the FD can play a role is in modelling the impact of shifting supply on profit. Widget A may be a great seller but it's no use if it doesn't contribute to margin.

This is a highly complex and contentious issue that cannot be sloughed off by FDs poking their noses in because it seems like a good idea. However, there are important areas where it makes sense.

For instance, there's no point in distributing Widgets to bad payers. Often, that's exactly what happens. That's a clear operational issue where FDs can have direct impact.

But without those oh so critical integrations, then you might as well forget it.

Final note: I doubt if too many board members would take kindly to the idea they're 'back seat drivers.'

Thanks (0)
avatar
By Anonymous
03rd Oct 2005 17:14

Does this mean re-visiting reporting standards ...
Unfortunately the more mundane issue such as reporting standards seem to take second place to the exciting Excel Pivot table articles. However, the real crux of the matter is that if reporting standards were in place then the need for endless Excel manipulation would be simplified - but it probably boils down to the lack of fun factor'

Dennis is quite right about it being potentially difficult in practice to connect front & back systems. Although the question has to be why is this the case.

If one is talking multiple vendor solutions then this disparity between front/back office is understandable, however, in a single vendor scenario there should not really be any excuse for the two to be out of step.

After all both front/back office should be using the same Db and are essentially different 'Windows' on the same data.

The real problem arises when those involved don't actually know what they want to see; which from a development perspective means one has to cater for everything on the off chance that something is of use. To this end report generators and tools such as Excel come into their own and are used to compensate for the requirements shortfall.

This is an incredibly inefficient approach which inevitably increases costs to all concerned. We are not talking 'leading edge' stuff here, just standards for basic reporting requirements. Accounting systems have been around for a while and almost every 'special' report will already have been thought of (and implemented) by someone else.

The question has to be - why does there still remain a 'black hole' surrounding reporting standards and requirements. This subject really does need the profession to engage and show the way forward.

Thanks (0)
avatar
By AnonymousUser
04th Oct 2005 14:57

My vote is with David
Communication must be the accountant's primary role. And that means communication to operational staff, at all levels. Designing structures which provide useful detail in a way front end staff can use is challenging - and far more beneficial to the business than preparing yet another set of statutory accounts.

Is there resistance from operational departments? Of course there is - at first. But I've never failed to make the breakthrough. In fact I've experienced more resistance from finance departments who are reluctant to let ops staff see the data in their own language.

Thanks (0)