There is a growing body of research showing the problems associated with using spreadsheets within the finance department. That may be well and good, spreadsheets may not be the best system to use within the finance department. However, a satisfactory alternative has not been presented for the use of spreadsheets, and as such the research into the use of spreadsheets is of little practical value to the finance world at large. The question still remains:

"Can other Technologies replace Spreadsheets within the Finance Department?"

Why are Spreadsheets used?

Quite simply, because they can be. Finance professionals with very little knowledge of computer software development, programming or application design are able to develop complex models that can be used to manage the finance function. Also, spreadsheets are widely used and available within the enterprise and the majority of information users have access to and knowledge of how to use spreadsheets.

So, what is the problem with spreadsheets anyway?

A study by Coopers and Lybrand showed that 90% of all spreadsheets with 150 rows had errors. Another study by KPMG showed 92% of spreadsheets dealing with tax issues had significant errors and 75% had accounting errors.

In general, the problems associated with spreadsheets can be split into two main areas:

Design, Development, Flexibility and transparency of internal processes

It is precisely because most Finance people, who are responsible for developing and maintained the models, are NOT trained in the design and development of spreadsheet models that there is an issue. No Financial or IT Director would allow an unqualified and/or inexperienced database administrator to develop and maintain the vast and complex transactional databases that now run Businesses. Yet, when it comes to the design and development of Management Reporting, Budgeting and Planning systems, which are relied upon to manage multinational businesses, this practice is commonplace. The issue here is not that the Finance Department is not financially astute, they are. The issue is that they are not technically trained in the use of Spreadsheets.

Spreadsheets are inherently inflexible to changes in the design of the models they map. This is due to the method spreadsheets use to link data, which is on a cell-by-cell basis. The internal formula structures written into spreadsheet models are not dynamic, so if there is a change to the NATURE of a formula in one sheet, it is not automatically replicated in all the subsequent sheets or workbooks. Every model change, no matter how small, has to be manually replicated in each affected sheet and/or workbook.

Further, it is not possible to follow what methodology is being used to drive the model within a spreadsheet. This is because all the formulas that are used to connect and manipulate the data within the model are hidden. There is a severe lack of transparency of the underlying formulae and therefore the methodology being used to drive the models.

Data Integrity

Even though there are issues as described above, these issues are more about the length of time required to develop, maintain and change Spreadsheet Models. If the resources are available, then these issues relate to the efficient use of resource. Of more concern is the integrity of the data being reported.

Data within Spreadsheets tends to be held in separate workbooks that are distributed and worked on by a variety of users in remote locations. These workbooks are then linked by formula to each other. These links, however, break up the entire model. If you change data in one workbook, there is no way of knowing whether these changes have been included in the entire model. This, for the finance department is the largest single downfall of Spreadsheets.

As described above, because the formulas within spreadsheets are hidden, it is not possible to establish the correctness of these formulas without a large amount of manual reviewing. Also, as each workbook is a separate entity, just because one workbook is correct dose not means that all the other workbooks used in the model are correct. Errors within Spreadsheets are an accepted drawback for most finance departments, yet this fact is seldom communicated to users.

OLAP, an alternative technology

OLAP, or Online Analytical Processing is a technology that was termed as such in 1993 by Dr. Codd who invented the relational database model. OLAP was used originally as a buzzword to differentiate it from OLTP (On-Line Transaction Processing). T was replaced by A to emphasize the Analytical capabilities of the new technology as opposed to the transactional capabilities of the relational database technology. Today, OLAP is used as an umbrella term for various technologies that used to fall under the terms decision support, business intelligence and executive information systems among others.

OLAP uses Dimensions to map the underlying fundamentals of the business. For instance, in a typical Global FMCG the Dimensions used would be:

Business Unit: which would map the underlying structure of the enterprise, both statutorily form a legal entity point of view used for financial reporting purposes and managerially for monthly reporting purposes that may be from a responsibilities point of view. With spreadsheets, one view is all that can be achieved with one model.

Product: which would map the logical make up of the product offering. This would include Brands, Sub Brands, SKU, Pack Size, Colour and the like. Again, this depth of analysis would require a large and complex spreadsheet model.

Geography: This dimension would map the physical geography of the world. It could be used to comply with Segmental Reporting requirements for Financial Reporting. It could also be used to identify the currency being used to report.

Customer: This dimension is of primary importance in the Sales and Debtors cycle and would map the Customers who buy products.

Measures: This is the main dimension where data is stored and would usually contain the primary ledger accounts. Also within this dimension would be summary measures for say, Total Sales, GP and GP%. Non-financial data could be stored in this dimension such as head count. It is possible to use calculations within this dimension that rival those available in spreadsheets.

Period: This dimension would map all the periodical requirements for reporting. Month, Quarters, Half's and Years.

Dimensions, a functional concept

A key function of OLAP is its use of Dimensions that are used to model the underlying fundamentals of the enterprise. The relationships within these dimensions are represented and manipulated graphically. It is easy to determine what makes up 'Total sales' for example, or what geographical regions have been included in 'Region 3' See Figure 1.

Figure 1 ? Graphical OLAP Interface

Also, these relationships are easily manipulated. If, for instance, the group restructured so that Italy now falls into Region 3 instead of Region 1 as shown in Figure 1, it is a matter of dragging and dropping this country into region 3. See Figure 2. This makes managing the models developed using OLAP relativity simple and intuitive as compared to spreadsheets. Also, changes made are applied to all the relevant data held within OLAP database. The spreadsheet models would have to be individually changed.

Figure 2 ? Ease of Managing Models

Often, there is more than one way of representing a relationship. For instance, Gross Profit in the above model is driven by both internal and external trade. It is possible to model the different ways of deriving Gross Profit as shown in Figure 3. There can also be different relationships that are driven by business fundamentals. The 'alternative relationships' are easily modelled. For instance, countries in the geographical dimension can be part of a region as well as a zone. See figure 3.

Contrast this with the situation if spreadsheets were used to drive this model. It would not be possible to consider all these dimensions simultaneously. Most likely, the data would come in as a hierarchy of linked spreadsheets with each higher level consolidating and summarizing the information in the lower level spreadsheets. The sheets lower down in the hierarchy would store information of smaller geographic regions while the higher level spreadsheets would contain consolidated information of larger and larger regions until the top spreadsheet would consolidate and summarize the complete data for the whole region in which the organization was operating.

The spreadsheets would be disconnected, lack transparency of the whole model and be very difficult to remodel within an acceptable time frame. The ability to visually map and manipulate hierarchies, as well as represent different views of relationships between items within dimensions is a clear advantage of OLAP.

Fast, Fast, Fast

This is the tenet of most decision makers today. However, access to data and information required to make decisions tends to be held in transactional systems which the decision maker either dose not have access to or does not understand. This requires the decision maker to request information to be prepared by the finance department. There is an obvious time delay in the turn around of these requests.

OLAP is a technology that can be distributed to many users using a variety of platforms. As there is a single store of data held within the OLAP 'Cube', data and information can be accessed by many users simultaneously regardless of their location.

As the dimensionality and hierarchies map the fundamentals of the business, analysing data is an intuitive process. It is not necessary to understand the underlying sources of data and as such information becomes understandable and accessible to a larger population of the enterprise. Managers can answer their own data analysis questions without formal requests to the Finance Department.

Fixed Format Reporting versus Drillable Reports

Spreadsheet reports are fixed format reports. They cannot represent the data held within them in any other way. If further analysis is required, this analysis is not available within the spreadsheet report. Any further analysis will require a new report that will usually require a new model to be developed. Ad Hoc report requests for further analysis and investigation are difficult to achieve in a spreadsheet environment. With OLAP, as both the underlying business fundamentals and the data are stored in a single data store, the ability to analyse data in an Ad Hoc manner is inherent in the technology. Data in the OLAP Cube is stored in an efficient manner specifically tailored to analysis. It is therefore possible to analyses data within reports on the fly, 'Drilling Down' or 'Up' to the underlying data which makes up the reported figure. The ability to drill through reported data is even possible to the transactional level, the last level of analysis.

The real time data dream

As soon as an extract of data is done from the various ERP systems used within the enterprise, the data is out of date, as it may have changed since the extraction. The majority of time spent on the reporting, budgeting and planning process results from extraction of and subsequent checking of data extracted. Spreadsheets do not lend themselves to real time data extraction and any ability for a spreadsheet to extract data is specific to a particular data source. Various ERP systems have the functionality of extracting data into spreadsheets but this means that the enterprises flexibility in developing its internal systems is reduced. There is a self perpetuating cycle, because the ERP system can extract data to spreadsheets, spreadsheets are used. Because spreadsheets extract data from a particular ERP, that ERP has to be used.

The nature of the global business market requires real time data, a requirement that spreadsheets fail to live up to. However, as OLAP is a core database technology, it is able to communicate with other databases seamlessly which enables data to be extracted from source systems on demand. The real time data dream is no longer a dream. It is now possible to report weekly, daily, even hourly with accurate, meaningful information accessible by a wide range of users with little or no understanding of the structures of the underlying data sources.

Conclusions

There remains with out a doubt a place for spreadsheets within the finance department. The use of spreadsheets as a tool for driving the Reporting, Planning and Budgeting functions of the enterprise are however, questionable. It is clear that there are other technologies available which suit this function better.

There are two main reasons why spreadsheets are still used today and why alternative technologies uptake in the finance department has been poor.

Firstly, there is a lack of understanding within the finance department of the alternative technologies available to provide solutions to problems encountered. There is also a lack of understanding within the IT department of the problems being encountered within the finance department. One department does not understand the problem, the other department does not understand the solution.

Secondly, justifications of spend. Acquiring and implementing new technologies requires funding and the benefits are not easily quantifiable in financial terms nor are they immediately felt. Most projects require hard number paybacks within the year in order to justify the expenditure. With data accuracy, ease of analysis and use as well as timeliness as the main advantages of OLAP, it is often difficult to justify the spend.

The majority of world class enterprises today have embraced OLAP as a key technology in delivering information to decision makers. The main question that should be asked is not if spreadsheets should remain the main platform for Reporting, Budgeting and Forecasting. Instead, enterprises should ask themselves how much competitive advantage they are prepared to lose through the use of inaccurate, out of date and inflexible information before alternative technologies are investigated.

Shaun Stoltz is the Managing Director of Data C Ltd, a Finance Systems Strategy Consultancy. He can be contacted at shaun@data-c.com or shaun@data-c.com.

shaun@data-c.com
shaun@data-c.com
shaun@data-c.com

About The Author

Having served his Articles in Business Assurance with PricewaterhouseCoopers, Shaun was identified and trained as a Computerised Information Systems Auditor where he started his knowledge journey in Technology. Throughout his career, Shaun has had a keen interest in Technology and the solutions and drawbacks that abound in this field, in the process learning such diverse technologies as Nerual Netwroking and Artificail Inteligence Techniques to remote managment of Networks using PXE protocols; shaun@data-c.com