Management Information Systems
The bigger an organisation becomes, the more important is management accounting and the information systems it relies on. Financial accounting tells you how well the organisation as a whole is performing and that’s fine for small companies but problems arrive when a company starts to grow in size and complexity.
What financial accounts can’t tell you is how well the different parts of your business are doing. It might be geographical territories, product and service categories, each subsidiary in your group, components in your supply chain of more detailed elements such as performance of individual sales personnel. For this you need a management information system.
A Giant Data Cube
Conceptually, a management information system is like a giant data cube that allows you to slice and dice the financial results for the whole company in any configuration you want. In the example below you might want the trading performance of ladieswear across the whole company, or you might need a breakdown of sales in the North East across all categories or you might simply be interested in the trading results for ladieswear in the North East. If correctly designed, a management information system will allow you to pull out these data easily.
Building a management information systems involves two important activities; one human, the other computing. The human activity is designing the management accounting rules which determine what information is available and how it is structured. The computing activity is implementing the software used to store, interrogate and present the data. Both can go horribly wrong if you don’t put enough thought into how these will work together.
Design
There’s some fundamental questions that need to be asked when designing a management information system. Your answers will influence technical aspects of the software but, more importantly, affect the way your business looks at itself in the future.
In the illustration above, Menswear and Ladieswear are reported separately and with equal status as Household and Food. An alternative would be to provide instead a total for all ‘Clothing’. If that is interesting to managers, do you provide a sub-total as well as each component or simply the total along with the facility to drill down if required? A similar question arises on whether there is sufficient detail for managers running the business. They might, for instance, need to break it down into sub-categories of products, such as ‘Ready Meals’ in Food. Some managers may want information on each product line right down to stock-keeping unit. A related question would consider customer profitability. In the example above it is not possible to show customer profitability, even if you could drill down on the territory line. Some customers might have locations across several territories. These would need to be manually added together to discover the profitability of that customer.
The next question is how far down the profit and loss account do you go? In the example above overheads have been allocated across products and territories. On what basis were they allocated and might it not have been better to stop at Gross Profit and avoid this step entirely? And how was Cost of Sales calculated? If the company wants information at the product level it might hold standard costs for each product. If that’s so, how does it handle changes in price from suppliers? How does it account for price variances? If it is a manufacturer, on what production volumes did it base its standard costs and how does it allocate factory overhead? The answers to these questions are not just technical accounting issues. Get it wrong and a business unit might get closed that should have stayed open, and vice versa. The outcome affects the way management views its business.
Amid this blizzard of difficult questions, it is easy to panic and decide to gather the lowest possible level of detail thinking you’ll be able to answer any question fired at you. Be careful of trapping yourself into creating a monster: a database that needs constant feeding and yet is rarely interrogated in anything like the detail expected. How then do you make all these design decisions? It’s easy. Ask yourself and your colleagues what decisions they are likely to make with the data being considered. If they answer with credible examples of action they might take, then there is a strong case. If their answer sounds like it’s an ‘insurance policy’ of interesting information that might be needed ‘just in case’, then the case is weak.
Systems
Imagine the data cube illustrated above with extra dimensions of data such as subsidiary, customer, and brand. Then consider time-based data such as month, year-to-date and previous year. Finally think about additional financial data such as ‘actual’, ‘budget’ and ‘forecast’. The geometry of database quickly goes far beyond a cube. It is possible to mimic this multi-dimensional ‘cube’ using a function in Excel called Pivot Tables. For many small and medium-sized organisations this is cost-effective but spreadsheets are not an appropriate tool for management information systems. They are hopelessly vulnerable to the data in a cell being deleted by mistake. In the jargon, their data integrity is vulnerable. If you can afford it, use a system such as SAP’s Business Objects, IBM’s Cognos or Oracle’s Hyperion. These products use clever software to avoid creating massive, slow and unwieldy databases. They are designed to be easily interrogated and have powerful reporting capabilities, along with some bolt-on features such as financial modelling, budgeting and forecasting.
I’ve worked with systems such as these since the early nineties. They rely on getting the design of the data right first time. Recently however there is a completely different philosophy that has emerged. Based on how we use Google, the idea is to use free text to describe the information you want and then let the user decide pick out and follow up on the information that interests them. I recently witnessed these two design architectures go head to head during a discussion of an assets database. One chap was advocating the structured approach, which he had been working on for a long time. The other chap (who was dressed as a Goth) was advocating this Google-style approach which he had thrown together in no time. I’m inclined to believe the Google approach is the direction we’ll go in the future.
For the moment, however there are still lots of horrible systems that dump a load of transactional data into spreadsheets and muck about with Pivot Tables. I’ve even seen this being used by a management accountant who had access to a full-fat version of Oracle v11. There is therefore lots of scope to improve our management information system if only we trained our young accountants not to be so reliant in this sort of ‘craft computing’ solution.
Whatever management information system you select you shall need your IT people to connect it up, so to speak, with your transactional systems. This means your financial accounts system and your front-office transactional systems, if these aren’t already integrated. This is where those earlier design decisions come home to roost. The more detail you require, the greater the potential that interfaces have to be written and the more work has to be done keeping the integrity of the data up to scratch, or input manually in the first place. All this means greater scope for error and instability.
Reporting
The aim of your management information system is to be boring. Not that the information it reports should be boring. Rather, the system that produces the reports should be boring. The format of reports must not change. The day and the hour when the information is available must not change. Only by blending into the background and becoming entirely reliable and predicable, like an elevator, will the information stand the best chance of being used.
Where there are changes of style, data presented in different ways this confuses managers and creates a barrier that only the persistent or highly motivated bother to break through. Business is constantly changing and this presents the management accounting function with a great deal of challenges in keeping the data consistent (for instance handling previous year’s data from a newly acquired business unit). Managers find finance complicated enough; they need the financial reports to be as stable as possible. In other words, your routine reporting must strive to be exactly that: routine.
Decisions
The test of any management information system is whether a company’s management use it to make meaningful changes in their business. It is a stern test. Frankly, it’s one most management information systems fail. Mostly that’s because managers prefer the human touch. Rather than having to interrogate financial information themselves, they’d prefer a briefing from a member of their finance team. Don’t commit the cardinal error of implementing a whizz-bang new information system and thinking that non finance managers will suddenly become enthusiastic about using it for themselves. The people that will use it most are your own management accountants.
Words of Warning
The great danger of management information systems is duplication. More specifically, it is that a new system is introduced but people keep doing manual interrogations from the underlying transactional systems, or continue relying on spreadsheets as they did before. There’s an IT equivalent of this and that’s the management information system holds so much data at such a detailed level it almost becomes a second transactional system, but slower because it’s not designed for that purpose.
Summary
A management information system that is boring and reliable is a necessary condition of good decision-making.