Last week I concentrated on getting some basic material available for download for those who may be interested in following this project. Today I would like to provide some insight into my thought process and philosophy regarding model design.

User Communities

 I believe that it is very important to understand the groups of users who are, or should be, involved in financial reporting . In my experience there are 5 roles which need to be considered when planning a financial application:

·         Model Implementation and Infrastructure management

·         Model Administration

·         Report Authors

·         Report Consumers

·         Data Contributors

It is interesting to observe how in many large companies financial reporting has remained an island separate from IT and controlled by the finance department. Where this is not the case you will often find a separate and quite autonomous department within IT that handles financial reporting and other “MIS”.  Understanding the factors that cause this split is essential to success in delivering a solution. I believe that the reason this separation from mainstream IT exists is and can be summarised in the following 2 statements:

·         Financial reporting is reactive and requires dedicated, in-house, resource who can respond without delay.

·         IT departments are project driven with formal procedures to allocating resource during project conception and manage change after implementation.

These requirements are in conflict. It is difficult for an IT department to allocate reactive resource without a clear definition of the ongoing requirement. Most change control procedures are, quite intentionally, designed to limit the amount of change introduced into any system and are time consuming to enact. It is difficult for finance departments to deliver the information demanded by management under the restrictions of these typical change control processes. Compliance legislation is putting pressure on organisations to demonstrate proper governance of their data assets and is putting further pressure on managing these requirements.

By splitting the roles of “Model Implementation and Infrastructure management” from “Model Administration” I am trying to address this divide.

Model Implementation and Infrastructure Management

In order to meet requirements for corporate governance it is essential that the basic infrastructure of any financial solution is based on sound enterprise technology and is integrated into the organisations hardware, backup and general data integration infrastructure. The provision of an implementation technology and a technical infrastructure should therefore be provided as a primary IT responsibility.

Model Administration

Model administration is the place where the reactive requirement impacts the process. It is important that model ownership is held by dedicated staff who have an understanding of the business requirements. It is quite likely that this person will not come from an IT background but will rather have primary qualifications in a finance discipline. Model ownership will include the ability to change database schemas as new business requirements are presented. This can be a significant bone of contention in larger organisations where the ownership and management of database schemas is held by the dba community and therefore under the formal change control procedure that I have already identified as a  potential problem.

The challenge is therefore to provide model administrators with tools that enable them to rapidly modify and extend an initial model  without losing control of the data governance.

Report Authors

Model Administrators are likely to also produce reports on behalf of others and in some organisations may be the only people who need to be able to interpret the structure of the model. In an ideal world however there will be a number of people distributed through the organisation who create reports.

Report Authors should be able to interact with the model without any need to understand the technology with which it is delivered. What do I mean by this? Report authors should be able to:

·         Interpret the data provided by the model using business terminology only without the need for specific “systems” training.

·         Accessed commonly used analysis such as year to date calculations without needing to create “local” calculated members.

·         Access historical data and create “prior period” reports in the knowledge that all analysis will be correctly re-calculated for the requested period.

This approach concentrates on the end user experience prioritising model functionality above performance.

Report Consumers

Report consumers will be presented with information created by the report authors. Most report consumers should be assumed to be completely non-technical. The delivery mechanism should therefore be very simple and only expose functionality such as the ability to interact with the data if the author considers this to be appropriate. In the simplest case it should be possible to present a static report which has no “options” attached to it.

Data Contributors

Data contributors such as budget stakeholders are likely to be line managers who are neither IT literate nor formally trained in finance. The requirements for these people are similar to those for report authors (in fact in many cases they will be the same people) but with the additional conditions that the tools and models presented to these people should have sufficient flexibility that they can create local sub-models that represent their part of the business whilst remaining within the overall data model. This is the most challenging group of people to satisfy.

The Olap Warehouse Toolkit approach

If you choose to work with the toolkit you will see that it is designed with a high priority on end-user experience. In other words the design is aimed at making life easy for non-technical or business users rather than efficient from a technical perspective. 10 or even 5 years ago this was not possible. The combination of hardware and software simply could not deliver an easy-to-use model that provided adequate performance. Now with laptop computers that contain 2Gb of RAM and 64bit server technology becoming affordable the barriers to creating great Olap models are being lifted. I now believe that it should be possible to design an Olap financial solution that is genuinely easy to use, provides extremely high levels of functionality and which performs adequately in large corporate environments.