Lassoing Eels – Building a Coordinated Oracle Reporting Strategy

Why is it so hard to pull all the Oracle reporting (and non-Oracle) tools together and use them in a coordinated way across all user and organisational requirements?
I would suggest there are four competing forces challenging the IT department, as it tries to unscramble reporting.
• Visual/people requirements
• Business Architecture
• Technology options
• Investment model

Competing forces

These forces then lead to the following disconnects.

• Can’t ask for investment without understanding what is possible
• Can’t deliver trust without a common understanding
• Can’t get a common understanding with pictures alone
• Must involve the users for buy-in but they need to understand context
• Hard to build a POC and a strategic platform

Your CIO has just had a visit from Oracle and says that we must implement Exalytics and BI Applications and that he has been told it’s a simple installation. How much is it going to cost and when can we be live?

Key users in the strategic planning office have just seen a demo of Tableau and know this is the right solution. They’ve told us we just need a server and we can be up and running. When can we have a server?

We have so many reporting solutions, no one knows which answers to believe! We really need to get a grip!

We’ve spent how much on that DW? You are just going to have to do what you can with this money, otherwise we will need to make some IT staff redundant to pay for this.

It’s key to understand the momentum in your organisation before seeking funds to start a new work package.

Business Architecture – some of you will have come across TOGAF an appallingly named approach to business design that is really pretty useful – our EAs (if we have them) are busy modelling the business and info architectures of the organisation – how do we align what we are doing with their perspectives – can two projects run in parallel – imperial made a start.

And Oracle doesn’t make it easy either.

Complex choices

Given you will have a number of Oracle and partner salespeople on your doorstep selling you the virtues of each, where do you begin? Should you invest a significant sum for prebuilt content, or can you install Endeca and be up and running in a few hours?

And then there are all the non-Oracle products like EIS and Insightsoftware, Qlikview and Tableau.

Visual/people requirements – users want reports in minutes – they have seem the demos from Tableau, so they know its ‘really easy’ – they want them on mobile devices - different users want exactly what they had before that they trust and don’t need to do any work to (no filters and slicing – just give me the numbers I need in a Spreadsheet – a 3rd group wants to play with data, from both inside and outside the org – they’re often a bit technical but they certainly want to uncover interesting new insights – they may be used to complicated predictive modelling or forecasting cubes – should we force them all down one route for consistency and to cut down on the excel cottage industry or is there a way we can retain some control and governance, yet still give them what they need to do their jobs?

Technology options – I’ve already listed a myriad of Oracle reporting options and then add in all those non-Oracle options that are used or liked by your people and you can see where the title evolved from – how can we control the deployment of the many technology options – how can we visually demonstrate the possible, so people can be inspired, while at the same time managing expectations?

Understand where everything fits together – research the actual (not perceived costs) including implementation, configuration, training and skills transfer.

Where does Cloud Analytics fit? New to market but looks like a good way to start, without the fuss of installations and management. Doesn’t include certain elements like BIP, Maps, Essbase and Smartview (Excel) but definitely includes Mobile.

Discoverer is in the departure lounge. Beware the O/S. Look at options for migrating to OBI – it may not be as hard or expensive as you think.

Engineered systems don’t really fit within a user dimension (aside from being fast – always good).

Sometimes the only option you have is to mix and match your reporting tools, usually because you already have some tools in use. Work with what you have; build a coordinated strategy; know strengths and weaknesses; create a timeline to move to a consistent and coordinated environment. 
Investment model – most (perhaps all) organisations say they want better reporting – but it can be very hard persuading a FD of the value of a new investment – most of this is down to past failures, where reporting projects promised so much and delivered so little – some of it is down to the constant demand for data, which means there is no time left to think about the data. What can we do to break the cycle and encourage appropriate investment?

“The need for analytics does not match most organisations’ skill requirements; vendor hype for cloud-based BI is not reflected in revenue and customer adoption; and there is a struggle between centralised and decentralised organisational models of BI delivery.”
Gartner 2012
What I am suggesting here is not a formal methodology, rather an accumulation of experience and slightly left field thinking. I recently heard that a thought leader sometime needs to dance on his (or her own) for a long time before people join in. Maybe I’m dancing now?

There is no getting away from the need for a solid information architecture. Anyone who has heard me speak in the last couple of years will know this as my mantra. I do not believe it is possible to deliver a good analytics solution without understanding not only what the business data means, but also where is owned stored and manipulated. EAs are often accused of delivering only pictures, and there is a danger, hence we need to build a plan that includes the other 3 dimensions.

Determining the distinct end user communities and speaking to them about their visualisation requirements at a high level will help to formulate a visualisation reqs plan.

Understanding the technology options may be the next step – definitely before asking for the users detailed reqs - so a series of demonstrations of what might be possible with different options to different user communities and it is worth explaining the different economic scales for instance between OBI and BI Applications. For the prebuilt bi apps, don’t demo out of the box – demonstrate against your data – it will make a big difference to the users – your partner should be able to do this with around 5 days investment, so not a big ask in the scheme of things

Next, you need to drill into more detail with the business users about their reqs, now they have seen the software options – this will determine the scope of their needs and will in turn inform the business case on build versus buy.

Taking the case to the decision-makers is the next step and it is vital to show them what they are getting, with options and phasing. Also important to show them what happens if they don’t go down the strategic route. Will be teaching some of you grannies, but surprising how often reporting does not get to the top table

You could take two routes from here.

My preferred route would be to build and deploy near-vanilla prebuilt apps, perhaps including Hyperion - as this is the fastest way to business value. If you are brave, and have the executive buy-in buy the Oracle prebuilt apps across the board, so that you have a strong, fully supported and growing platform (with Oracle’s own investment) across your entire org spectrum – even if you don’t have Oracle apps in some areas, it’s much easier to repurpose ETL from a non-Oracle source app than to build a bi app from scratch. IF the scope warrants that. Remember that the cost to build out a reasonably thorough ETL DW from Oracle (or non-Oracle) apps could be significant. One university I have worked with has taken around 2 years to deploy a reasonably simple custom obi solution and that’s not down to the skills of the developers.

Get the users using the solution and find out from them, as a phase 2 activity, what bits they would like to extend. You won’t be able to retire all old reports until p2 has been completed. This is the approach NR took.

An alternative approach, should the business bens of prebuilt analytics not stack up would be to design from scratch. To do this DON’T start by designing a data warehouse. Make sure you already have an info arch and then model that as a DW. This will ensure you have full traceability back to the end users. Then you can unleash the DW specialists who can work with vanilla OBI to build out a structured DW with a solid presentation layer.

Either way, you get as fast as practical to a part-complete BI solution, with prioritised reqs and timeboxed agile delivery.

Where there is no natural fit between the end users needs and the OBI outputs, for instance with information discovery or predictive analytics, consider the ‘edge’ BI products in the Oracle stack or indeed non-Oracle products. Where you already have for instance tableau licences, don’t necessarily throw it away - instead point it at the dw, rather than the individual datasets it would currently use. That way the users keep their beloved tool, but the org can still implement a strategic platform.

How easy is that? Not very – clearly – get some advice form people who understand projects, not just technology. Don’t underestimate change management – get users involved as early as you can – manage expectations – train frequently whether in classrooms or with easy to use self-study such as upk – test how people are using the solution continually and keep evolving – as soon as the investment dries up, the solution is bound to fall over time into disrepair. But if you’re happy to throw investment into managing your source systems, why not into your reporting systems,

Conclusion
• Deploy under the radar and then ask – ‘what can’t you do?’
• Get an understanding - in context - of any prebuilt content – 5 days POC
• Don’t believe all the hype – see for yourself
• Build for ‘perpetual beta’ – productionise with a business case
• Drive for strategy; deploy in stages