10 Components Of A Successful BI Strategy Plan

Defining a successful BI strategy is a lot more than gathering requirements and selecting a vendor. While it’s been a subject of many books, I know few of you have time to read them, so here’s a short version.

  1. First defining what BI is and what it is not. Is it just reporting, analytics and dashboards? Or does it involve ETL, DW, portal, MDM, etc., as well?
  2. If the former, you then need to define linkages, dependencies, overlaps and integration with all of the latter (including - very importantly - integration and coordination with the higher level enterprise architecture efforts). If latter, it’s a whole different subject. You then really do need to read a few thick books.
  3. Ensure senior business executive commitment and top down mandate. If you cannot get that, do not proceed until you do. Two ways to “sell BI” to them (even though that’s not a good position to be in):
  4. Establish BI PMO, BICC, BI governance, etc.
  5. Document the current state of your BI environment
  6. Envision and propose a target state for the BI environment that includes identifying:
    • Requirements for all:
      • styles of BI (reporting, ad hoc querying, OLAP, dashboards, etc.)
      • people and roles: all stakeholders that will be affected
      • business vs. IT roles
      • decision types (strategic vs. operational) *
      • end user BI self service requirements *
      • agility, flexibility requirements *
      • process requirements
      • regional requirements (dealing with multiple currencies and cross border tax issues, for example)
      • post closing adjustments reporting requirements *
      • BI on BI requirements *
    • Dependencies, constraints (standards, other projects, initiatives, etc.)
    • Architecture
      • Technical
      • Metadata *
      • Security
      • Data
      • Integration (with other apps, processes, portals, etc.) architecture
      • Information delivery (desktop, portal, mobile, disconnected *, etc.)
    • Operational, training, support requirements
  7. Based on the target state requirements, build a vendor/technology shortlist, considering potential multiple vendor co-existence scenarios. This is where you consider buy vs. build vs. oursource vs. SaaS
  8. Identify gaps between the current state and the target state
  9. Design a road map to close the gaps and achieve the target state with:
    • Priorities and dependencies
    • Strategic and tactical steps (including proofs of concept and prototypes *)
    • Top-down vs. bottom-up design approaches (or a mix) *
    • Plans, such as:
    • Now that all the plans and details are in place, you can proceed with building a detailed BI business case.

10. Select software vendor(s) and (if necessary) systems integrator

 * Steps typically mised in a traditional BI strategy excercise.

I am sure I missed something, so, comments?

Comments

Don't forget EA

Hi,
thank you for excellent shortlist of BI Strategy components.
I'd like to involve more EA/IA type staff into process, since building another silo called "BI" is not very long lasting trend. And sometimes companies have already all components in place, they just need to sharpen their strategy:)
br,simo

Yes, agree, integration with EA efforts is key

Excellent point. I added a short statement re the need to coordinate/integration with EA.

The design part

I'd add to the target state:
"Select, design, prototype and validate with prospective users possible key indicators / views on the data and their visualisations".

Even hand-drawn paper prototypes and a few co-design sessions can help tremendously to get an idea of a possible good design.

proofs of concept and prototypes

Agree. POCs and prototypes are critical.

The Design Part, But First...

Regarding Milan's comment about good design...

I totally agree with iterative design sessions with users, but before spending time or money designing a solution, should an organization take a hard look at how unique/proprietary their BI stack is or will be? I've seen a fair share of companies invest in the manual design and development of BI stacks that aren't much different from others in their industry. In these cases, turn-key BI applications should be considered (with pre-built data integration, data warehouse and dashboards). They can be implemented faster (by and large) and then iteratively evolved/customized.

Consider a supply chain BI stack implementation at a manufacturing company. If they took an outside-in view, they might see how similar their supply chain BI stack would end up being to others in their industry--same source systems (SAP/Oracle/et al), similar data warehouse data models & similar end-user information requirements. The same often goes for sales and profitability analysis, and customer analytics. In these cases, rolling your own BI stack to support these analyses should make no more sense than building your own ERP--it's undifferentiated and unnecessary.

It seems prudent to perform this analysis and consider turn-key BI application stacks, either on-premise solutions like SAP BW ( http://www.sap.com ) or hosted, on-demand SaaS BI solutions like Oco or Birst, etc. ( http://www.oco-inc.com http://www.birst.com ). This isn't to say do-it-yourself (DIY) BI and turn-key are mutually exclusive--it probably makes economic sense for companies to run both in some cases; I believe DIY and turn-key stacks can be integrated if necessary.

Thanks Boris, I look forward to hearing your thoughts.

vendor selection

Yep, these are some of the details behind steps/components #7 and #10.

I was not talking about

I was not talking about technical implementation of a custom BI stack. What I mean by design is related to a good User Experience. That involves
- talking to your future users (a lot)
- choosing good metrics
- choosing good display media
- deciding what goes on a report page, dashboard or alert
- making prototypes of possible outcomes
- testing these prototypes with the prospective users
- checking for feasibility and then
- implementing that.

No IT design involved! (Except for the feasibility part)
That should be done regardless of using a readymade product or a customised solution.

I have yet to see a company where some vendor templates really deliver the information people need.

Hi Martin, I got the sense

Hi Martin,
I got the sense you were talking about user experience analysis/design and not necessarily DBMS design.

What I think we both agree on is that the BI strategy should be driven by a concrete business user need.

A couple of reactions/questions though...

#1 - I wasn't saying there are readymade BI stacks for all cases. For certain combinations of industry/analytic domain/source systems/scope, there may or may not be. If there aren't, then your list makes excellent sense.

If there ARE readymade solutions available, much of your list still makes sense, but I'd suggest looking at readymade solutions, with your users, early on in the process. Here's why:

Users don't always know what metrics they need, and won't know them until you start delivering answers (...answer 1 question and it raises a bunch more, you know?). Have a few meetings to get a rough idea of user requirements, then why not bring in some of the readymade solution vendors to show users what's possible? While they might not be an exact fit, many of the solutions include very well developed sets of metrics based on many customer implementations. Even if you decide to build your own, there's lots you and your users can learn from the ready-made guys. 1 good vendor demo can probably save you weeks of paper prototyping and requirements analysis.

#2--Regarding your comment about having "yet to see vendor templates really deliver what people need."

Maybe it's just a semantic nit, but referring to SAP BW or Oco, Birst, Pivotlink, et al as "templates" is like calling Salesforce.com a "CRM template." These are live BI stacks, with ETL, Data Warehouses, Dashboards. There are lots of cases where these are in use (esp. SAP BW) and all require customization as part of the activation/set up process. I agree that early on (5-10 years ago??) the readymade solutions, especially those from the BI/reporting tool companies were lightweight, but the SaaS BI solutions, especially, have matured a lot and are worth a look.

Thanks Martin,
Andy

Design rationale

I think I get your point Andy. The build versus buy and custom versus standard thing is an old issue, however I think we should make the case for design work in any BI project. Some thoughts on this:

1- what defines a "BI stack" for you? If it is a collection of possible KPIs and views on the data, I totaly agree - there are many cases where you don't need to customise because the data is already there, you just have to centre on its quality. But when it comes to selecting and visualising the information in a way that speaks directly to the addressees, I think that is something what you have to do anyway - see next point.

2- Just installing and maintaining readymade solutions is exactly what makes IT today a commodity in the eyes of business people (not only in the BI context, CRM qualifies here too), instead of being something seen as a potential business differentiator. Use the SAP-BW standard dashboard for sales, all you competitors have that too. Use your own brain and design a dashboard adapted to the individual unique business problem and execution of your strategy, that could make a difference for your business.

3- To your point that users don't know what they need - that is a very common problem in the UX domain and the reason why there are designers in the first place. If users knew what they needed, you could just let them design their stuff themselves. But to quote Henry Ford once more, "If I had asked people what they wanted, they would have said faster horses."

Milan