« August 2009 | Main | October 2009 »

September 2009 Archives

September 9, 2009

The Curious Case of Financial Consolidation

One of the goals of a data warehouse is to provide a single source of the truth, as the basis of management information across the organization. Data is collected from various transactional systems, is integrated and aggregated, and made available through business intelligence tools and performance management applications. According to analyst firm Gartner, performance management comprises financial consolidation, financial reporting, scorecards, planning and budgeting, and profitability management.
However, many finance professionals question the need for a data warehouse as the source for their financial consolidation process, instead of linking financial consolidation directly to their general ledgers. They are right. I'll discuss why, from an architectural, procedural and practical perspective.

Architecture
Although financial consolidation is generally accepted to be an important, if not crucial, part of performance management, financial consolidation has some characteristics fundamentally different from other a management processes. In fact, as a management process it looks more like transactional process. Most management processes, such as plan-to-act or analyze-to-adjust are iterative of nature, and very hands-on. Users take an explorative view on the data, where one question leads to another. Financial consolidation, as part of record-to-report, in contrast, behaves more like transactional process, such as order-to-cash or procure-to-pay. Financial consolidation should be linear of nature, and as hands-off as possible. The level of automation and standardization should be as high as possible, to secure a reliable, auditable and repeatable process. As a consequence, for financial consolidation purposes there is no added value for adding the data warehouse as an intermediate storage stage in a further transactional process.


Procedural

Financial data has specific requirements regarding the chain of custody. It needs to be 100% accounted for, auditable and every step needs to be retraceable. Based on Sarbanex-Oxley regulations both the CFO and CEO need to personally sign for the accuracy of the information. Routing the financial data from the general ledger through the data warehouse before feeding it to the financial consolidation system is not only an unnecessary step, but it endangers the chain of custody. It introduces governance issues, as the data warehouse processes and houses many types of information owned by multiple business domains.

Practical
Due to US GAAP and IFRS regulations, financial data transformations are highly standardized. Although the ETL (extract-transform-load) or data integration tool used by the data warehouse may functionally be able to deal with the complexity of financial data transformation and integration, there is no point in reinventing the wheel, if this logic exists prebuilt in standard financial consolidation packages. Best-of-breed prebuilt functionality allows finance professionals to make allows finance professionals to make ledger-to-headquarters mapping decisions directly, and see the impact on the balance sheet balances, financial ratios and accounts. These requirements, particularly in multiledger environments, can live at odds with IT-managed complex ETL processes that should be focused on maximum control and stability.

Does this mean that the Finance department should be excluded from the data warehouse? Not at all. The majority of finance run processes, and a large part of finance-related information are managerial of nature. Operational management needs to have insight in the financial consequences of their operational decisions, and require financial management information. Financial management, in return, needs to be able to access operational management information, to gain insight in the business' value drivers, and as such improve and maintain financial predictability. Also from a planning perspective, operations and finance need to be integrated. Financial and operational information both belong in the data warehouse, in an integrated manner.
Once it is understood that financial consolidation is fundamentally not a management process, but an operational process, the architectural issue disappears. The financial consolidation system, like any other transactional system, should be seen as a source to the data warehouse. This might raise the issue of timeliness. Financial consolidation takes time, and other types of data might be routed into the data warehouse sooner or with a higher periodicity. That problem can be solved like with any other source system; distinguishing between preliminary and final data loads.

Keeping financial consolidation outside the data warehouse architecture is not an 'exception to the rule', but a matter of architectural soundness, combined with an understanding of governance issues and simply a practical solution. Key to keeping the architecture 'clean' is the understanding that financial consolidation is not a management process, but transactional of nature.

September 28, 2009

That Time of the Year Again

(*) Warning. Contains Irony.

It's that time of the year again. Running season. Every year I write in my blog on my jogging efforts. Yesterday I ran the "Singel loop" in the City of Utrecht ("Singel loop" does not translate as "single loop"! Loop = Run, Singel = a canal surrounding a city), a 10km run.

Last year in my blog I used this run as an example of how measurement can tell you anything you want. Last year:
• I improved my personal record for the 10K (great!)
• ... as no. 570 I came in last anyway (hmmm... not so great)
• ... but the system didn't register the people who gave up and never finished (at least I did!)
• I started front row, and came in last, so I must have seen every single runner (social indicator?)

While running yesterday, I found some other examples in running that help understand the subjectiveness of measurement. (Yes, measurement is far from objective!)

Everything is relative
KPIs are used to express one measure of success against a certain base, like revenue per employee. A great way to fluff up your performance. In my case, if I correct my time of 1 hour 16 minutes (1:16) with my overweight, it compares to running 10k in about 1 hour, which is really not bad! Also, it was hot. Does that count for something, comparing performance to other occassions in better circumstances?

Measurement system
I use the Nike+ system that counts every step and sends the data to my iPod. Distance, speed, etc. is based on the average step-size. I reckon the system has about a 7.5% margin of error. So when my measurement system said I did run 10km, I still had 750 meters to go. According my definition of 10 kilometer, I did that in about 1:11, which is nicely on target of what I usually run. And as long as that is the only system of measurement, it is fine as long as the margin of error is consistent. One measures improvement (or not), even if the basis is wrong. So in a sense I did make my target of 1:11, as it was based on a different system of measurement.

Measurement tells you about the person measuring
Measuring a subject itself already causes a change in behavior of the subject. Also, any measurement system shows the hand of the person measuring. Choice of metrics (objectives), or relative position (from where was something measured). For instance, I measured that in the beginning of the run I was mostly overtaken by men. Later on, I measured I was mostly overtaken by women. What does that tell? That on average men run faster than women. But it also tells you something about me. I don't run terribly fast (in fact, I was amongst the last to finish).

Rhythm helps driving performance
I have been writing many times about how quarterly closings are a completely artificial event, that should not impact discounts, etc. The shoemaker charges the same price for fixing your shoes, whether it is March 31st, or April 1st. However, I have noticed there is something to be said for a periodic pace of business. A rhythm helps. I noticed that one song particularly (Eminem - Lose Yourself) kept me going. The rhythm was perfect, it gave me energy and the beat really drove me forward.

Synergy
My time this year was worse than last year, when I ran the race in 1:14. Then again, I didn't train that much, as I have spent most evening and weekend hours on writing on my new book. Ironically enough, the book is on dilemmas. So is this a dilemma? Spending time on writing versus time on training? The book actually argues it is important to find the and/and situation. How can you do both at the same time? Being so energized working on the book that I automatically run more as well? Alas, practice turned out to be different. Time truly has proven to be a constraint. Then again, synergy was achieved, I did come up with the content for this blog while running...

Lastly, measurement is about learning, closing the loop. That means this blog is about learning how to learn, which in terms of Argyris and Schoen is called 'double loop' learning. Another reason why "singelloop" doesn't translate as "single loop"...

frank

About September 2009

This page contains all entries posted to Frank Buytendijk Blog in September 2009. They are listed from oldest to newest.

August 2009 is the previous archive.

October 2009 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type and Oracle