Oracle Business Intelligence EPM and Relational Federation – A Strategic Approach
The federation of EPM and relational data sources through Oracle Business Intelligence (OBI) seems straightforward: import the cube, federate and rename, expose it all, and create dashboards and analysis. Due to the technical simplicity of EPM and relational federation, many organizations underestimate the amount of effort needed to implement an OBI solution that properly leverages and extends the capabilities of the EPM and relational data sources. The OBI implementation process should not be an afterthought, especially if OBI is to be the primary method by which users consume organizational data. We have assembled ten “Dos and Don’ts” that cover the full lifecycle implementation to help organizations get the most out of their OBI solution.
Do – Design and develop the data sources with input from the OBI implementation team
Especially in implementations where OBI is to be the primary method of consuming data, the OBI implementation team should have been heavily involved in Dashboard and Analysis requirements and design. As such, this team will have the knowledge of what data structure is needed to support an efficient and easy-to-use analytic solution. Asking the OBI implementation team to come in after the data model has been set and create Dashboards and Analysis will often result in workarounds that are error prone, difficult to maintain, and challenging or impossible to scale.
Don’t – View OBI as a one-size-fits-all analytics and reporting tool for the organization
OBI is a powerful and versatile tool capable of addressing a slew of needs; however, it is not a magic bullet. Depending on the application and needs of the organization, Smart View, Financial Reporting, and even BI Publisher have their places in the organization. Attempting to replicate the capabilities of other analytic and reporting tools through OBI may provide the illusion of capability, but will fall short of user expectations and possibly harm adoption by the rest of the organization.
Do – Have a metadata management process in place before federating data sources
We discussed the rationale of this best practice thoroughly in the post Oracle Business Intelligence – Synchronizing Hierarchical Structures to Enable Federation. To summarize, unsynchronized hierarchical structures between data sources can result in analysis with outcomes that are irreconcilable, seemingly reorganize while drill down or up, display erroneously shared members, or simply result in errors in OBI. A centralized process for managing this metadata as well as ensuring that all relevant data sources are updated simultaneously is imperative when federating data sources.
Don’t – Treat OBI as a metadata or master data management tool
This is typically a symptom of not having the OBI implementation team involved during the design of the data models. As a result of this misalignment, clients attempt to shoehorn analysis into the data model by using the BI Administration tool (RPD) to excessively manipulate the data model. Properly leveraged, the BI Administration tool can create an agile analytics solution; however, relying on this tool to fill large gaps between the data model and analytics will result in performance and maintenance issues.
Do – Define a use case, user community, and requirements for all implementations
From proof of concept to full implementations, having the right people involved is imperative. Within your organization: Who understands the reporting and analytic needs and gaps? Who understands where the data is coming from? Who understands what capabilities are needed? Who is positioned to help user adoption? Who is asking questions that the organization is struggling to answer? Any technology implementation that is done with the intent to “throw it against a wall and hope something sticks” is destined to fail; OBI is no different.
Don’t – Expect that users will flock to OBI if EPM is the only data available
We find that when there are both EPM and relational data sources, EPM is often the first to be implemented and exposed through OBI. During these implementations, users are extensively exposed to Smart View and finance users become especially enamored with the tool and struggle to immediately see value in OBI. A Pavlovian response is to simply federate the EPM cube’s relational data source which typically provides a lower level of detail (or granularity). While this is sometimes useful to users, it is still not providing the additional insight users cannot readily get elsewhere. Federating additional data sources with EPM cubes should provide additional attributes or measures or provide a simple path to jump from one organizational view of the data to another. For instance, a financial consolidation EPM cube federated with an operational relational data source provides an easy-to-use analytical solution for managers with responsibilities that straddle both worlds. These users will quickly adopt OBI and help with future user adoption.
Do – Empower the users
Guided analysis through Dashboards, Analysis, Alerts, and Scorecards is a powerful tool; however, an organization will never address every scenario through this method. Guided analysis should be an introduction to OBI for users which should quickly be developed into self-service. Within a few months of rolling out the OBI solution, power users should be assembling ad hoc analysis and putting together their own dashboards. Within a year, most users should be answering basic questions on their own. Organizations that empower users are not only improving the ROI on OBI, but they are also more agile in addressing changing business landscapes, accelerating user adoption, and reducing the load on (often) overburdened IT organizations.
Don’t – Neglect the performance of any data sources
The demand for data is the epitome of just-in-time logistics. Especially when users are empowered, many organizations find that their data sources and caching strategies are not sufficient for how users are actually leveraging the data. EPM and relational data sources both have performance monitoring capabilities that should be frequently evaluated during the months after initial rollout and periodically evaluated thereafter and any deficiencies addressed. Failing to address performance issues will result in users abandoning and circumventing the analytic tool, resulting in loss of productivity and data quality issues.
Do – Pivot to using OBI as an analytics tool instead of simply another reporting tool
Tabular reporting is typically (and should be) the first use for OBI that clients turn to, but this should be viewed as an insertion point and not the final rally point. With capabilities such as graphs, heat matrices, treemaps, gauges, alerts, and trellis, pivoting from reporting to analytics should be the goal. Answering business-critical questions, quickly understanding the business landscape, and gaining insight is where the true value of OBI lies. Simply leveraging OBI as another reporting solution is severely handicapping the tool’s return on investment.
Don’t – Let OBI data sources become static
Analytics is one of the few tools that simultaneously changes a business in a deliberate and serendipitous manner. A well-led and strategically executed analytics program can have a lasting contribution to an organization’s goals. At the same time, users will develop new skills and capabilities as they become familiar with both the tool and the data and begin to ask new questions. As both the competitive landscape changes and organizational capabilities expand, data models should be evolving to address these new needs. OBI has the ability to easily expose, slice and dice, and visualize data to answer these questions; the challenge is to not become complacent in providing new data resources to users.
If OBI is to play a role in your organization’s analytic strategy, it should not be an afterthought. Involving implementation team members with the knowledge of OBI’s capabilities from the start can help ease implementation during the later phases, accelerate user adoption, and increase the long term ROI. Edgewater Ranzal has both the technical and functional implementation experience with OBI to help you evaluate, adjust, and execute your analytic strategy according to these ten “Dos and Don’ts.”
Jason L. Hodson is a Principal Architect with Edgewater Ranzal. He focuses on the Oracle Business Intelligence platform, with particular emphasis on the federation of EPM and relational data source, Business Intelligence Cloud Service (BICS), as well as data governance with Hyperion DRM. He has experience with clients in the insurance, public utilities, manufacturing distribution, and healthcare industries. A former U.S. Marine, Jason has an undergraduate degree in mathematics/physics from Ball State University, an MBA and MS-Information Systems from the University of Cincinnati, and a MS-Information and Knowledge Strategy from Columbia University. He currently resides in Denver, CO and enjoys hiking, snowshoeing, and the local craft beer industry.