Some people see things simply – a hot air balloon will get off the ground. Others revel in the detail – a Saturn V rocket will also get you off the ground. Of course, there is a place for both. Designing and controlling optimal data capture structures to support the right levels of reporting can be a real challenge for the Controller. How do you avoid drowning in detail?
For one piece of data to find its way into a report, it needs at least ten activities, for example, definition, approval, capture, isolation, protection, traceability, pointing, storage, retrieval and some level of reconcilability. These activities need to be maintained throughout the lifecycle of the data. Accordingly, because data complexities drive costs into the business, there needs to be upfront consideration as to why the item needs to be captured:
· Is it actually new?
· Is it a statutory requirement or does it facilitate obtaining a statutory benefit?
· Will the business be managed better with such an object?
· Is it a permanent feature or a temporary requirement?
· Is it likely to make a material impact?
· Precisely, what is this object?
· Is it an enterprise level object or a business unit object?
· What will the object be used for?
· Can another means achieve the same result more economically?
· What is the proposed object’s impact on the eight remaining activities?
· Does the proposed object keep the data structure simple?
· How would the object be summarized and consolidated?
· What physical driver(s) align with this proposed object?
· Does the object need to be held in the General Ledger?
If a proposed object cannot be sensibly defined and considered in these terms, it cannot sensibly qualify as a reporting object.
Ultimately, beware of the cost of a Saturn V rocket.