Chapter
Why fix the finance data supply chain?
The biggest driver is greater efficiency in data processing and reporting.
Let’s start with the why. Efficiency in data processing and reporting, along with regulatory necessity, would be the biggest driver. For example, as one controllership executive in a well-regarded New York-based global capital markets firm once said as he pulled off his glasses, closed his eyes and pinched his nose, “Why must there be reconciliations? Why can’t it just be straight-through processing?” Finance has come to accept reconciliations as a fact of life, when in fact, it is an issue brought on by inconsistent granularity, flawed operational processes, and IT and data systems that have failed to account for finance’s needs and use cases in their design. The net of those issues creates the very inefficiency finance is trying to avoid. Adding up all the hours spent performing reconciliations across a major firm at each level makes clear the insidious cost. Most would consider this unpalatable, yet every firm performs thousands, if not millions, of reconciliations each month. Ask any analyst in any finance group, “What do you spend the bulk of your time doing?” The answer had better be “working,” but further exploration into what “working” is reveals that analysts spend almost all of their time preparing data and only some of their time analyzing it. Availability of data is no longer the problem. In many cases, there is too much of it, but it is at the wrong grain, wrong hierarchy, wrong language, wrong currency, wrong format, missing values (the most common data quality issue is the “null” value in a field), or there is an abundance of seemingly the same thing and picking the “right” one takes hours of research and several phone calls to people who “own” the data, the system or the domain. If that is not enough to justify the investment in “fixing” the data supply chain, then what is? The kicker is that after all that data preparation and analysis, the consumers of this data seldom trust what it says! This increases the burden of proving where the data came from, which is challenging due to multiple hops, data manipulation and aggregation with little to no connection to the source.
The regulatory regimes want “lineage,” and SOX and CFO attestation each dictate (albeit very differently) a level of both documentation and controls that firms have either tried to patch together or simply failed to be able to deliver, resulting in heavy fines from regulators and a lack of confidence from management, boards or auditors. Obviously, the issues laid out above are just the indicative ones, but there is a gamut of reasons to address the supply chain issue head on.
Chapter
What are the challenges?
Overcoming technical, cultural and ownership challenges.
Let’s start with the one that causes consternation from the governance folks to the politicians in the group: ownership. Likely, this is the biggest single challenge organizations have, and while it is neither a technical nor a process issue, it is still a very real challenge, especially when it comes to accountability and budgets. IN the overall structure of institutions, lines are being drawn: finance vs. IT, enterprise vs. line of business, even risk vs. finance. Having a well-defined data ownership structure with a governance framework promoting quality data throughout the organization is critical. Knowing who and what function own the data is half the battle.
For finance, much of this boils down to OBOR (operational book of record) and ABOR (accounting book of record). OBOR must deal with the “event,” be it a transaction or other type of event, and ABOR deals with the financial accounting of that event and its subsequent path through to the general ledger. Operations and IT generally own the OBOR side, and finance generally owns the ABOR side. But finance has deeper needs!
While accounting and financial processes have been done for thousands of years, today’s world is all about proving the provenance of the “events” back to the systems of origin and demonstrating that linkage for the regulatory and statutory reporting. While it can be argued that this only applies to “critical business elements” or subsets of data, it is more cost-effective and organizationally efficient to establish a solid enterprise data management capability and manage all data to the strictest level.
Maintaining more than one standard as to what data is critical and how it should be managed leads to an unwarranted proliferation of data and corresponding standards. If the next accounting change (e.g., CECL (current expected credit loss)) or the next reporting need (e.g., expansion of Federal Reserve Board (FRB) reporting) could be predicted, then the data could be targeted and tailored specifically, but that is not practical. It is far better to have the data available and fit for general purpose. Finance must share the statutory and regulatory requirements that have been placed on it and, therefore, the rest of the organization, so finance can get what it needs from the IT and operational areas in terms of lineage, semantic definitions, upstream controls, data quality and fit-for-purpose usability.
Thus, finance must own its data from the report to the system of origin at least in terms of defining data sourcing criteria. IT and operations must adhere to those requirements and principles and incorporate them into their data sourcing and delivery through the supply chain. This brings us to the second major reason finance just can’t seem to get its supply chain right: the militant management of metadata — Triple M. Militant management of metadata is a core concept supporting two fundamental challenges that finance functions face today: (1) where the data or data set comes from and (2) how the data is defined.
Metadata as a concept is likely far from most finance professionals’ minds, but it is the underlying technology that is foundational to addressing the latest and most challenging regulatory and business needs.
A well-managed metadata environment can tell business and finance professionals where a given element or a data set came from and when, the path (lineage) it took to arrive in their purview, the data quality metrics associated with the element in question, the control scrutiny it faced and if it successfully passed, and finally, the definition of the data both from a technical and a business perspective. Melding the latter two provides greater context for the data elements and what its fit-for-purpose characteristics will be. It also provides the ability to identify and source specific data sets in an efficient and timely manner. For example, treasury may want to pull the balance sheet data set for its specific needs.
Sadly, most firms lack both the discipline of comprehensive metadata management and the appropriate tooling to enable it, or they have fallen in love with the shiny object (a new tool) but not paid attention to its integration throughout the supply chain. Specifically, IT on the data sourcing side may not be capturing comprehensive metadata at the outset and along the way, and the business may not be investing enough in understanding and defining the data. Additionally, lines of business may have one definition for a data element, while risk, finance or tax have another. A semantic layer underpinned by a well-managed metadata platform makes managing these multiple definitions for a single element possible, as well as enabling the concept of data domains, e.g., finance, tax or controllership; the concept of portfolios; or business lines vs. enterprise. To be clear: Without a strong focus and dedication from business lines and functions, metadata will fall short in establishing a well-defined supply chain.
Summary
Organizations that have been successful in simplifying their data supply chain and building a practical roadmap have a few things in common: executive sponsorship, organizational buy-in, clearly defined accountability and data ownership, and finally, finance taking control of its own destiny.
