Mastering financial systems success

Exclusive: How Fifth Third has utilized a master data management approach to overhaul a number of its financial systems, by Bret Furtwengler.

As Vice President of Financial Systems, Bret Furtwengler is responsible for financial systems and project management at Fifth Third Bank. His financial systems responsibilities include management reporting, SEC, tax and regulatory reporting systems; general ledger administration; chart-of-accounts and internal accounts oversight; and financial hierarchy/metadata management. His finance project management support has included Sarbanes-Oxley implementation oversight, forecast/plan reengineering, acquisition/conversion support, multimillion-dollar software analysis and implementation oversight.

With 20-plus years in finance, accounting and systems, Bret possesses a unique blend of experiences across finance, accounting and technology-oriented roles. Prior to joining Fifth Third Bank, he held positions in a variety of industries including telecommunications (Broadwing/Cincinnati Bell), retail (Luxottica/LensCrafters) and systems consulting (Pricewaterhouse).

Fifth Third Bancorp is a diversified financial services company that operates 19 affiliate banks and other financial service subsidiaries principally in Ohio, Kentucky, Indiana, Michigan, Illinois, Florida, Tennessee, West Virginia, Pennsylvania and Missouri. Fifth Third provides a broad array of products and services through four primary businesses: Retail Banking, Commercial Banking, Investment Advisors and Fifth Third Processing Solutions. With over US$105 billion in assets as of year-end 2005, Fifth Third is one of the largest banks in the US by both asset size and market cap. It is headquartered in Cincinnati, Ohio.

FST. Can you give us an example of an innovative technology deployment you have been involved in that has proved particularly successful? What were the challenges and how were these overcome?

BF. We recently spent over six months reengineering our planning/forecasting processes. While the reengineering effort improved the process, the business process enhancements were insufficient to address all of our issues. This led us to consider acquiring a technology solution.

We faced a number of key business issues. For example, we had outgrown our Excel-supported process and at one point had over 1200 Excel spreadsheets. We also lacked insight as to why our ‘bottom-up’ view did not equal our ‘top-down’ view, had limited standardization and consistency across our lines-of business (LOB) templates, and had an inability to manage global assumptions and/or global changes or perform high-level scenarios. In addition, there was an ability to expand forecasting requirements (ideally we wanted LOB forecasts for every affiliate) and support multiple versions.

Once we acquired the technology (which was Hyperion Planning), we spent five months implementing our retail LOB detail plan process (eliminating the 1200 Excel spreadsheets), then spent five months implementing our forecast process. We then spent two months implementing our high-level plan process. As a result of these efforts, we successfully incorporated standardization and completeness across all affiliates and LOBs, developed bottom-up reconciliation to top-down views (which we accomplished through improved visibility into affiliates and LOBs – before we had no idea why they did not agree) and expanded the level of detail captured in the forecasting process to provide greater visibility. We’ve improved our scalability. It is a stated goal of Fifth Third to double the size of the bank by the end of the decade; however, while historical acquisition activity placed a growing burden on existing infrastructure, the anticipated future growth really raised the alarm. We’ve also realized greater transparency, and are now able to monitor the evolution of the planning process (i.e. version control); have the ability to manage global assumptions and global changes centrally as a result of the greater administrative control; and have a centrally administered process with decentralized data capture.

We identified several key lessons during the implementation effort with regards to the implementation process, project management, system administration and the role of consultants.

In terms of the implementation process, there are a number of considerations. First, it is critical to avoid scope-creep; this can best be avoided through project charters and staging documents, as well as heavy education on the project management triangle. My version of this has three sides: 1) dollars, 2) resources and 3) time, while the overall internal area is scope – because scope can affect all of the other factors.

Second, to successfully build metadata, the end-state reporting should drive the hierarchy; standardization of both metadata (dimensions and hierarchy) and reporting are important.

Third, ensure there is a proper test environment. It is always dangerous to perform maintenance and/or development in a production environment. Do not fall into the trap of buying a development environment after the production environment is established because ‘later’ may never come.

The next lesson relates to technical requirements. Develop a reasonable perspective of the potential size of your applications and double or triple it; when your user-base becomes familiar with the toolset, they are going to want more development, and you will want your application environment to be ready to scale.

Finally, data cleansing requires consistency in definition, as does the effort to obtain one version of the truth; to obtain global organizational definitions, executive buy-in is imperative. The devil is in the details with data consistency. It is critical to have repeatable processes so that data is loaded the same way every time. You should be willing to support manual feeds only during the development/prototype phase of your implementations; I recommend you also move to a ‘lights out’ process to avoid burning out your system administration.

In terms of project management, the first thing to get right is the pilot. You must have user acceptance or the applications provide no value, and pilot rollouts to selected users helps to create those power-user advocates while ensuring training is meaningful. Executive communication is also key to the ability to create change in an organization. However, time-poor executives often have a limited attention span, so create a one-page communication document to get across the key facts quickly and clearly. The reverse is true of end-user communication – it is better to over-communicate than under-communicate. Utilize your intranet to provide FAQs, calendars, rule definition documents, user guides, etc., all in support of a ‘self help’ environment.

Also, don’t underestimate system administration – if Hyperion Planning is the strategic product it should be in a BPM environment, then significant development will take place; additionally, the applications developed will most likely be heavy ‘hand-holding’ type applications because planning and forecasting tend to be very dynamic exercises.

Finally, it is more than likely that your organization will not have the internal resources required to develop these solutions. As a result, you will probably require consulting assistance. There are many BPM vendors out there, but I would recommend that you find one that has specific experience in your industry and specific experience with companies of your size and scale.

FST. You’ve also been implementing a best-in-class financial metadata management environment. Why is it so important for companies to get a handle on their financial metadata? What opportunities does it open up?

BF. A strong master data management (MDM) environment supports the creation of functionally specific applications. There is a balancing act between ease-of-administration and application functionality. Ease-of-administration drives developers to put as much as possible into one application (it minimizes metadata updates and discontinuity with other apps), but the problem with this is that serving too many masters often results in serving none well. Application functionality drives users to want only what is necessary to meet their specific needs, thus increasing performance and ease-of-use. For better usability, it is therefore important to break applications into functionally specific components – master data management provides the mechanism to support functionally specific applications while ensuring consistency across applications.

Another aspect that is supported by a strong MDM environment is standardization across multiple applications. In order to ensure comparability across the organization (and across multiple systems that provide varying levels of granularity with respect to reporting), organizational standards are required. Standardization comes in many flavors – metric definitions, calculation definitions, metadata definitions and hierarchical structures – and is desirable because it increases the usability of all systems. Users are able to traverse from one system perspective (with different data components and levels of granularity) to another (with different data extraction and/or reporting tools).

Yet another aspect that is supported by a strong master data management environment is business performance management (aka BPM or also CPM and even EPM – it has several different acronyms). BPM is the integration of operational analytics and financial analytics at a more granular level in order to provide visibility to the underlying metrics that drive performance (at least that is my definition!).

In order to bring BPM to life, it is critical to maintain a depository of granular metric and financial data. But in order for that data to be useful, it must be accessible to the user community – and in order to be accessible, it must contain meaningful context. That context is most readily identified through hierarchical structures, but for those hierarchies to have value, there must be consistency across all systems – they must all utilize a common, contextual hierarchy. MDM provides that common, contextual hierarchy.

With all three of these opportunities – the balancing act between ease of administration and application functionality driving to functionally specific applications; the effort to ensure comparability across the organization through standardization; and the challenge to provide consistency across all systems through the use of a common, contextual hierarchy – the primary reference point was to bring more usability to systems. Building the most robust data collection system in the world is meaningless if it is not coupled with usability. The systems my team manages only bring value to this organization when they are used – and used effectively.

FST. What has this implementation involved, both from a business process and a technology standpoint?

BF. Before I dive into what it took to implement our financial systems master data management environment, let me first provide my definition of MDM. Master data represents two different components: 1) standard reference data (and the word standard is a critical part of this definition) that is shared across multiple systems (both dimensions and attributes), where dimensions are a specific entity or cost center or G/L account and attributes are the information captured for each dimension that tells each system how to deal with this dimension; 2) in addition to standard reference data, master data includes the standard definition for how reference data relates to itself (or what would commonly be called a hierarchy).

But in order to have master data management, you need more than just master data. You also need a business process to manage the master data, which is why it is called master data management. This raises an interesting point: it is critical to understand that in order to have success in this area you must have more than just technology. In fact, I would be so bold as to say that technology cannot solve your master data management issues – MDM is a business issue that requires a solid business process coupled with enabling technology.

So with that as a backdrop, at 5/3 we grappled with a variety of issues in the financial reporting area. Our single financial reporting app supported too many functions (internal, external and regulatory); there was no separation between development and production environments (development actually occurred in the production application); there was no formal structure to metadata maintenance (inconsistent frequency and timing, reactive data load exception maintenance versus proactive identification, no documentation of requestor or purpose for Sarbanes-Oxley and no rollback strategy); and each system was updated manually, resulting in inconsistent application of naming conventions, no assurance of structure synchronization and no definitive system of record or audit trail.

We addressed these issues by creating a centralized master data repository (using enabling technology that we purchased from Razza Solutions (later acquired by Hyperion and renamed as Hyperion MDM) that was wrapped around by a robust business process. The ultimate goal was to create one version of the truth in regards to financial master data to ensure consistency across all systems that support financial reporting. In order to bring this business process and the associated repository to life, it took a combination of one time events and the creation of an ongoing process.

One thing that is implied here is that we took a functionally specific approach to this issue. My role at Fifth Third Bank is Financial Systems, and as a result, we focused our effort solely on financial system master data. Success with a MDM initiative is more likely to occur by staying focused, by avoiding the ‘big bang’ (just ask folks who have tried to implement an entire enterprise-wide data warehouse!). Trying to tackle the entire enterprise-wide master data would prove too lengthy, too complex and too risky.

If I boil down the keys to our success to the bare minimum, it would include the following: first, a recognition of the need for improvement by senior management; second, the focused discipline of the project team; third, the vision to create a proactive, repeatable business process; and finally, the enabling technology provided by Razza (now Hyperion).

FST. As an executive whose duties span the operations, IT and finance arenas, what are your most pressing concerns at the moment?

BF. The primary issue my organization is focusing on is access to more granular data that represents the operational drivers of financial performance. This issue encompasses both the access to the data as well as the repository itself.

Sarbanes-Oxley has caused us to review the mechanism of data transfer. As a result, we implemented new software that integrates both data transfer and validation to ensure data quality. Additionally, one of the key tenets behind Sarbanes-Oxley is documentation. A robust master data management process incorporates documentation of change requests and the development of maintenance logs.

In terms of next steps, we are considering developing a Center of Excellence around financial reporting that will support reporting from all core financial systems, the data warehouse and BPM/analytical applications.

We are also looking to extend our initial BPM implementation to create more granular data that is reconciled to the official book of records (in our case that is the general ledger). We describe this as our financial data repository – which should provide the mechanism to house operational drivers of financial performance and be the primary source for all financial reporting systems. The Financial Data Repository has the potential to support drillable analytics.

Furtwengler’s guide to MDM project success

• Gain organizational agreement on the concept. Socialize the idea of a centralized repository espousing benefits/issues resolution; it helps identify who should participate.
• Obtain executive sponsorship. In my case, the Bancorp CFO provided the sponsorship.
• Develop governance process for change requests. An ongoing process will enable you to avoid coming back to the same issue in 3-5 years. Also, the business process is critical; without it the enabling technology is irrelevant.
• Define overarching purpose of systems that utilize master data. This ensures the ongoing process is effective.
• Develop an oversight board and system administration council. You need appropriate representation from each department with a vested interest, and excellent communication with all system administrations – ultimately, this required the creation of a new organization at Fifth Third Bank.
• Extract master data from key systems – you need to create just one system of record.
• Reconcile data and determine future standards.
• Develop a master data standard definition/reference tool. We created a tool with filtering and search capabilities that is accessed through our financial systems intranet site.
• Archive history and create new version. You need version control at the central hub. This should maintain historical structures to be able to support reconstruction, if necessary, for tax audits, lawsuits, etc. It should also maintain an audit trail of transactional changes to the versions.
• Update central master data repository, with an audit trail of the updates.
• Create a maintenance log that supports Sarbanes-Oxley documentation and ensures excellent communication. Give it a place on the intranet site for easy reference/access, especially to support users whose reports might be impacted by the maintenance.
• Finally, synchronize participating systems, and utilize a common maintenance window.