The case for agile EBS reporting

Losing a critical business asset is always hard. It shouldn’t happen.

Recently, when discussing our favorite topic, “Oracle EBS Reporting”, an organization confided that they suffered a serious loss. One of their KPI reports was missing. It was a complex SQL script that gathered data from several application modules, generating statistics and calculating KPI’s that were an important part of their annual reporting.

The analyst had executed the script the previous year from their laptop using SQL Developer. Unfortunately, the laptop suffered a hard disk failure several months ago – and it was not backed up.

Their recovery options were:

1. Check the EBS databases’ automated workload repository (AWR) – Due to the limited usage of script, the retention period had expired long ago.
2. Assign their developer, affecting the deadlines of other high priority tasks.
3. Engage an external consultant, requiring considerable time defining the specification, then developing, testing and validating the new report.

They opted for #3 and engaged one of their trusted consultants. It was an expensive and time-consuming process.

The transition from ad-hoc to mission-critical reporting

We’ve worked with many Oracle EBS users and generating mission-critical data from SQL scripts using SQL Developer or other tools is not a unique experience. In fact, it’s a common practice and often leads to similar results. What starts as a simple, one-time script evolves to become a mission-critical part of an organization’s business process.

The root cause is two-fold: the complexity of using the default Oracle EBS reporting tool, BI Publisher, and the convenience and simplicity of using developer tools and SQL scripts.

Complexity

Developing reports with BI publisher is a complex, multi-step process requiring a developer to be skilled in several tools and technologies. To become competent in developing reports in BI Publisher requires special training, and to become a skilled professional requires practice and experience. As a general rule, it can take 24 – 36 man-hours for a skilled developer to complete the analysis, development, deployment, and documentation process for a single report. This combination of high skill and time commitment means IT management must carefully allocate the developer resources. Completing the development of a new report or changes to an existing one can be a multi-week or months-long process.

Convenience

Contrast this with the convenience of a SQL script.

A business analyst needs some information for an upcoming leadership meeting. They have read-only access to the production database and regularly create SQL and run scripts.  To get the information they need, they build and run a script, collect the data and deliver the report.

Their report is well received by the leadership team, helping them reach important decisions. A few changes and enhancements are requested for the next meeting and this cycle continues for each subsequent meeting. Without anyone recognizing what has happened, a one-time SQL script, designed to satisfy a single business analyst reporting needs, has now evolved into a report that has become critical to the leadership team’s decision process.

Convenience over complexity. It is simply more convenient to get answers with a simple script and there generally a failure to recognize the risk that the value of the answers produced has become a critical part of the organization’s business process. The recovery from loss can be time consuming and expensive.

Agile reporting development is the solution

How can you avoid this dilemma of convenience over complexity?

A great starting point is implementing a reporting solution designed around the principles of “Agile Development”. A solution that encourages rapid iteration of the specification, development, testing, deploy lifecycle and allows fast deployment to the business user.

The following are a few important points to consider in your evaluation that will help move you toward rapid, agile EBS reporting:

• The immediacy and speed of SQL – SQL is the underlying language of all database reporting tools. Unfortunately, many reporting solutions “hide” the underlying SQL in the name of “ease of use”, In most cases, this simply adds a layer of complexity.
• Sophisticated Parameter – A robust, flexible parameter system is an important part of giving the business users the ability to filter the output data to get the answers they are looking for. Carefully thought out parameter values means a single report can be used for different purposes, by different users, simply by changing the values.
• Direct to Excel – Reports delivered in Excel is the #1 output choices for business users. Comma-Separated Values (CSV) is a common output file format for EBS extracts. To get this information into Excel requires additional steps to “clean-up” the imported data.
• Integration with EBS –Many solutions purport to be “integrated” with EBS, but on closer inspection, they are simply “interfaced”. They access the database, but the user and the reporting functionality is entirely outside the EBS experience.
• Version Control – Development and deployment is an iterative part of the creative process. Most reports developed over time, evolving over multiple versions. When a mistake or bug is introduced and the business-users want to roll back to the original, how easy is to roll-back and recover?
• Change Management – All organizations have a change management solution, using work orders or tickets to track requests, allocate resources and resolutions. But how do you record the relevant information for each change within a report and how is this change information related to a specific version?

• Securing sensitive information – Can you leverage the existing EBS security structure, or must you reproduce it externally? Can you use virtual private databases to ensure confidential information so it is inaccessible to unauthorized users?

• Development, Test and Production – Development by nature runs through several iterations from DEV, to UAT and finally to Production. How easy is it to move from one environment to another? What are the additional resources that are required?

• Migration from other reporting solutions – In the past few years, many older reporting tools have been replaced with new solutions with no automated migration path.

• • How can you keep your investment in those systems?
  • How do you know which of these older reports are valuable business tools, and which are redundant or obsolete?

• Ongoing service and support – Are you confident the solution provider has a deep understanding of Oracle EBS? Is Oracle EBS reporting their primary focus or is it just one of the solutions they offer?
  • Many solutions providers have moved towards “Analytics” and it is a very crowded market. In fact, Oracle offers one of the leading analytics solutions in this category, so there is a lot of competition.
  • Oracle offers the outstanding Enterprise Command Center (ECC) free for EBS users on 12.2.4 and above. They are investing heavily in ECC for their user base – and it’s free. No licensing costs.

Get Started

If you need to simplify your Oracle EBS reporting, centralize the random SQL scripts that have mysteriously transformed into required business reports, or you simply wish to take gain control of all of your corporate SQL assets, we’d love to learn more about your organization and direction.

Learn more – request a meeting

Of course, if you would like to get started with Blitz Report we’d like to help. We’d recommend a Proof of Concept implementation in your EBS environment and working through your most challenging problems and use cases. We know you’ll be impressed.

We know you’ll be impressed, and we look forward to helping you!