These days, everyone is talking about TOM. Who is this TOM guy anyways, why is he so popular, and what does he mean to business leaders and administrators alike? TOM changes, TOM moves, TOM can be challenging to deal with, and most importantly, TOM is never sure if he wants to play nicely with your Oracle-Hyperion applications. If you are reading this and are unsure who TOM is and what he means to business leaders and administrators, please see the previous blog post in this series called: “Target Operating Model: Your Go-To Business Strategy to Maximize Your People, Processes & Technology” before reading further.
When you are faced with a fussy TOM, it can feel like you are dealing with a very angry bag of cats. In this blog, you will learn how to turn TOM into a bag of ponies, perhaps even a serene field of galloping ponies… instead of a bag of cats. As business leaders and Oracle-Hyperion administrators, you may be wondering if you should face TOM alone or if you should call in reinforcements.
In this blog, we will address key considerations around data flow infrastructure and you will also learn the benefit of approaching TOM with a trusted friend. An Oracle-Hyperion solution that leverages system allocation logic that could be applied to closed consolidation or forecast/budgeting solutions will be one of your closest allies in your quest to save the universe from TOM.
Along the way, please do not lose sight of the most important consideration when working with TOM in any way:
Common Challenges and Key Observations
Many companies, large and small, turn to implementing Target Operating Models (TOM), either due to the failure of a previous operating structure that does not support the organization strategy, or due to a significant structural change such as a large merger or acquisition. Working in the Oracle-Hyperion space, we have recently seen many of our clients embracing TOM and running more efficiently as a result. When we see clients moving from a Traditional Management (profit/cost center) approach to a TOM approach, they are largely looking to streamline financial processes and retire manual error prone processes.
Some common challenges our clients have been experiencing while implementing/updating a TOM are:
In the below sections, we will discuss the considerations for streamlining financial reporting in a new or existing Oracle-Hyperion system for an organization with a TOM model that commands different management reporting and legal reporting views. To do this, we will briefly analyze the role that data flow and system allocations can play in setting up your applications for success with TOM:
High-Level Dataflow
Typical data flows we see at our clients usually consist of Data Ware Houses/Lakes, Enterprise Resource Planning (ERP) systems, FDMEE, and normally end at an Oracle-Hyperion application (either Closed Consolidation or Forecasting/Budgeting). Data flow is important to the ability of the application to function properly. Data flows that are too complex or consist of too many moving parts can cause data integrity and integration issues. Please see the below diagrams for additional details:
Simple Data Flow
Limiting the number of source systems makes it easier to handle integrations into your Oracle-Hyperion applications. Specifically, limiting the number of source systems will decrease the amount of changes that need to occur in a source system or target application upon the inevitable change of your TOM. The diagram below shows a simple data flow that will likely decrease the amount of complexity required to achieve the desired TOM reporting results.
Complex Data Flow
As more source systems are added to the infrastructure landscape, there is a greater probability that your applications will experience data quality issues, especially as your TOM changes and grows. Mergers and Acquisitions activity is one of the key contributors to the addition of multiple source systems to infrastructure layouts. At many clients, we often see numerous legacy ERP systems remaining from recent acquisitions that may have different levels of detail or may have been designed in a completely different way than the main ERP system(s). This may prove to be a challenge for your organization to get the same level of data quality from the legacy acquisition ERP systems as opposed to the main ERP system(s). The diagram below shows a more complex data flow that will likely increase the amount of complexity required in your financial applications to achieve desired TOM reporting results.
Allocation Definitions
As shown in the Complex Data Flow diagram above, one of the most common challenges we see our clients facing is that the data being integrated into their Oracle-Hyperion applications from local ERP systems or Data Warehouses/Lakes does not align with how the organization would like to review, use, and report on the data. To get even more specific, we have seen instances where data coming into the system is appropriate for Legal or Management reporting, individually as defined by the TOM, but not both. As a result, many organizations have resorted to using manual excel reports to collect and analyze key data sets. Historically, these Excel models have been difficult to maintain and error prone. Offline Excel Models = fussy TOM!
One solution we commonly recommend to our clients to avoid having data in their system that is not conducive to TOM. More specifically, data that TOM cannot use in its business defined, system-driven allocations that move data into specific reporting buckets that benefit TOM. In the past, we have seen these allocations based on a wide array of items, including legal entity, strategic business unit, or department level of detail. Some models have been based on sales, hours, or any other key driver/data point that is relevant to the organization implementing the solution.
In the Complex Data Flow diagram above, the sample organization does not get the full details it needs from Acquisition ERP #2 for management reporting around department level of detail to make TOM happy. The best course of action here would be to correct the data at the source by overhauling the current ERP system or integrating that acquisition into the Main ERP for the organization. However, those are both time consuming and complicated changes, which again make TOM fussy! Based on that, we would like to propose an alternative approach using allocations as discussed above. The example below is only for illustration purposes and may not be directly applicable to your current organizational structure. But, we would like to provide you with the building blocks to begin formulating an allocation plan.
Allocation Example
The high level assumption in this example is that Acquisition ERP #2 does not differentiate between which department is responsible for which costs, so they would just be loaded to “No department detail” through the FDMEE integration. This is a big problem for TOM, as these details are required to determine the appropriate costs by department for management reporting. In the diagram below, we show a sample way to allocate the total costs of $2,500,000 coming from Acquisition ERP #2 across department, based on the headcount (FTE equivalent) in the HR, Finance, Marketing, and Sales departments.
Data Flow after Allocation Logic
One benefit of designing processes like this into the system is that they are repeatable and will likely be applicable to other scenarios in the future. It is likely that your organization will make more acquisitions or change in ways that are not supported by TOM and you must adapt accordingly. As a result, we recommend that your organization put a plan in place to address change within without causing undue disruption to TOM. Please keep in mind that solutions like the one outlined above can be implemented in either Oracle-Hyperion Planning/PBCS/EPBCS or Hyperion Financial Management and are a trending approach for effective management reporting. To learn more about implementing systematic changes and design/strategic implications related to data flow and allocations, please contact us for further details.
Up Next
Please stay tuned for future posts related to harnessing the force within Financial Data Quality Management Enterprise Edition (FDMEE) and Financial Reporting Studio (FR)/Enterprise Performance Reporting Cloud (EPRC) to enable your organization to stay flexible and meet the requirements of TOM.
