Managing a fleet of ‘reports’ is the bane of any organization. This is the story of how the fictional organization, AGOV, managed to eliminate two-thirds of its inventory prior to an upgrade.

Overview of Mount OBI

This blog series is about a public sector organization ‘AGOV’; a fictional mash up of recent experience, past knowledge, and research. I like to blog to remember, and a good memory device is to tell a story. A story always works better with sympathetic characters, such as AGOV.

Reporting Flotsam. AGOV has a good story as it managed to eliminate two-thirds of its OBI fleet prior to leaving the technology and upgrading to a new technology. AGOV is not alone in its accumulation of reporting-flotsam which makes some of its lessons learned relevant to most organizations. Additionally, this is ultimately a story about People, Process, and Change Management – enduring themes.

Camping on Mount OBI. AGOV’s efforts to reduce its fleet of OBI reports involved six phases. This blog provides the context to these steps and introduces two optional side trips. If you don’t get past this first blog, you will have the highlights. Need more information, click and read on!

1. Understanding Mount OBI [this blog]
   • Death of Mount OBI [Optional blog, history and context of OBI]
   • Tagging [Optional blog, inventorying an Organization’s Reporting Fleet]
2. Prepare the Environment and Data [TECHNOLOGY]
3. Measuring Mount OBI: How Will the Objects be Evaluated? [PROCESS]
4. Initiate Communications and Change Management [PEOPLE]
5. Conduct Increasingly Focused Passes with sign off [PROCESS]
6. Integrate into an overarching Data Governance Framework [GOVERNANCE]
7. Note: the above blogs can be downloaded as a single PDF: AGOV Tackles Mount OBI.

Base Camp Briefing. Now that you know what is involved in Climbing Mount OBI, let’s get started on the base camp briefing.

• When Climbing Mount OBI, Bring Your Caveats
• AGOV, A Buffet, A Hoarder, A Crisis, and A De-Supported Technology
• A Proto-Report Catalog
• Inventorying the Hoard
• Not Three-Peating The Problem

When Climbing Mount OBI, Bring Your Caveats

Bean-Counter in the Land of Propeller Heads. Let me start with my standard caveat of ‘I am not a techie; I am an accountant’. In the context of this story, this is the right philosophy to have. Vendors have tried to make reporting a self-service affair with the techies dealing with the complex stuff or answer business questions.

Decade of OBI. With this philosophy in mind, AGOV implemented Oracle Business Intelligence (OBI or OBIEE) for reporting out of its Oracle eBusiness Suite ERP (eBS) implementation. Fast forward more than a decade, and OBI can be described as a success story for AGOV (but with a dirty secret, stay-tuned).

OBI Buffet. This success is partly due to both technical and business users in AGOV creating ‘OBI-Objects’. An OBI-Objects can be a dashboard, a page on a dashboard, or ‘thing’ such as a table, graph, prompt, link, etc. OBI works a bit like a buffet table. You can load up your plate (pages) from different areas of the buffet to make a meal as big or small as you like (dashboard).

Magic Buffet. The buffet table is a bit magical because the same item can appear on more than one diner’s plate at the same time; analogy: a page can be referenced on 1+ dashboards. An ODI folder holds like ODI-Objects in the same place. Folders help with access and can be organized by business area (Finance, HR, Sales, etc.), security (everyone, some security, or ‘nope – you are not on the list’ level).

Ledge of Direct Usage (or Eating the Deviled Eggs). An object (graph, table, etc.) can be re-used across numerous pages or the object can be run directly from the OBI Application. This is like standing at the buffet table and eating the deviled eggs directly of the serving tray.

AGOV, A Buffet, A Hoarder, A Crisis, and A De-Supported Technology

Reporting and Chicken Bones. The numbers reference on the above graphic are the count of the respective OBI-Objects within AGOV. They are a mashup of organizations and are representative of what happens when a buffet table does not have a hostess keeping an eye on the patrons (and the devil eggs). Self-service is great until no one cleans up after themselves, leaves their chicken bones on the heating tray, or picks up the deviled eggs with their dirty fingers.

Reporting and Social Norms. Sorry for twisting the metaphor but you get the point. Self-service has to come with social norms if not outright rules. AGOV had trouble with its reporting-governance. Naming standards were strong suggestions, cleaning up after yourself was optional and when in doubt – create a new report!

Hoarders at Heart is an apt description for most organizations. The initial reaction to cleaning up OBI-Objects is – keep everything, just in case. Given the precious time, talent, and treasure invested, this perspective is understandable.  As well, Public Sector organizations have a hard time saying no. When the Minister or Secretary General says “I need…” organizations deliver.

A Hoarder’s Worst Nightmare. Getting rid of old things is VERY HARD because the status quo has become the norm. The problem has grown so large and is seemingly owned by no one. Besides, who would agree to delay their priority project so the techies can work on a clean-up activity? Well, until a hoarder’s worst nightmare happens – moving to a new home.

OBI is De-Supported

OBI was state of the art, for about 2010 [1]. Another optional side trip, Death of Mount OBI, provides additional details. The key point being that Oracle has focused on developing its cloud offerings and OBI will be de-supported in 2025. While a Cloud application has lots going for it, it is also a ‘Take it or Leave Affair’ – follow our methods or don’t use the tool.

A Proto-Report Catalog

Defining What to Move. If you have ever had to move house, having a list of WHAT to move is a good idea. Migrating reports also needs such a list and it is sometimes known as a report catalog. There are varying definitions, but AGOV settled on this one:

… A report catalog is a repository that describes how a business owned tool (dashboard, report, etc.) meets a pre-defined or emerging business requirement to provide timely, complete, comprehensive, and accurate information to a defined end consumer.

You Have to Proto Before You Can Run (Reports). See the further reading section if your organization is ready to build a full-fledged report catalog, or even better, a data hub. For AGOV, this project settled on delivering a proto-Report Catalog. This tool only considered OBI-Objects and asked a very narrow range of questions about these. Still, this was a leap forward for this organization as it captured quantitative, qualitative, and status attributes for each OBI-Report.

Inventorying the Hoard

The project to deliver a proto-catalog and then cull-reports had six phases:

1. Understanding/Introducing Mount OBI [This blog]
2. Prepare the Environment and Data [TECHNOLOGY]
3. Measuring Mount OBI: How Will the Objects be Evaluated? [PROCESS]
4. Initiate Communications and Change Management (Talking to AGOV) [PEOPLE]
5. Conduct Increasingly Focused Passes with sign off [PROCESS]
6. Integrate into an overarching Data Governance Framework [GOVERNANCE]

Not Three-Peating The Problem

A way to look at the reporting issue is through the Quality Management lens of the “Three-P’s”: People, Process, and Product + Governance. In 2013 I added the concept of time and governance to this familiar heuristic in the blog Three P’s and a G over T Collaboration Framework.

The above model requires a small tweak in which Product are the reporting outputs rather than a saleable product or service. Not a perfect fit but still a serviceable way to think of AGOV’s problem and where to focus attention at a point in time.

Spoiler Alert!

This is the end of the overview and subsequent blogs will look at each step in more detail. Flipping to the last page of the story, was AGOV able to reduce the number of OBI reports?

Two-Thirds of the Dashboards within AGOV were eligible for deletion with a corresponding number of pages and objects. In the end, AGOV decided to hide the ~150 Dashboards for six months rather than delete them for the following reasons:

• Grace Period of six months ensured none of the dashboards were in fact needed. Unhiding takes seconds, recovering a deleted dashboard potentially hours.
• Technical-Entanglements meant that the deletion process was a complex activity requiring detailed review of the OBI-Objects. For example, a folder may seem to contain one dashboard but the underlying objects may be used in other critical dashboards. Thus, the deletion process is tedious but must also be thorough.
• Abandonment as an Upgrade Strategy. Finally, a proof of concept was underway to move OBI to a cloud environment. This may have involved a ‘lift and shift’ from OBI to the cloud (best case) or necessitated the recreation of the OBI Dashboard individually (worse case). If the latter, then abandoning the ‘junk’ in situ would make the most sense. If the former, a cleanup effort would be required at some point (either pre- or post-migration).

Results, Notes and References

1. OBI had a ten year run under Oracle after which it was increasingly starved in lieu of a cloud offering. See the Wikipedia article for competitors to OBI: Oracle Business Intelligence Suite Enterprise Edition – Wikipedia.

Further Reading

• An internet search will yield a good number of hits for the concept of ‘Report Catalog’. Other search terms to consider are: ‘Data Governance’ and ‘Data Management’.