Key observations 4 months into an SAP BI 4.0 implementation

来源于网络

It is difficult to overstate the amount of hype that surrounded the launch of SAP's latest Business Intelligence product offering, SAP BusinessObjects BI4.0.  It was probably only surpassed by the hype levels surrounding SAP HANA.  What it also shares with SAP HANA is an unfortunate gap between the vision presented about the product and the reality of the value (and pain) that customers are deriving from it today.  Please don't misunderstand me - both of these products are enormous strides ahead for SAP and do potentially offer great value over their predecessors .  However, the SAP Marketing machine did such a brilliant job of setting expectations incredibly high that some measure of disillusionment for early adopters was inevitable.

Over the last few months I've been involved in firstly a PoC and then a pilot SAP BI 4.0 project that included a wall-to-wall assessment of all the tools and features in light of the client's reporting needs.  This blog contains some of my observations and suggestions coming out of this ongoing process.

1) Forget about a grand enterprise-wide roll-out - start with a single "killer" use-case

Although SAP BI 4.0 is a suite of tools that conceivably offers all the features you require to meet every single BI need in your business, the best approach is not to attempt to design this grand strategy on day 1.  In fact, the opposite is true.  The most effective approach in achieving early ROI is to be ruthlessly focused.  Find an area in your business that is experiencing some real pain and then match that need to the sweet spot of one of the tools in the suite. (By the way, this sounds easier than it actually is - see 2.). Next, make sure you fully exploit the capabilities of the chosen tool to build something outstanding.  The outcome may be that you only roll out one tool initially and only to a small group of users, but that's not important.  What's important is that you've quickly and effectively solved a pressing business problem, which will delight your users and create plenty of positive momentum that will support achieving the longer term grand strategy.

If you can't find a "killer" use case, then you might be better off delaying the implementation until one appears.

2) Too much choice can be a bad thing

One of the biggest challenges in an SAP BI 4.0 implementation is tool selection.  It may initially seem like each tool in the suite has a distinct purpose and positioning, but in reality there is significant overlap in what they offer and the lines are far more blurred than we expected.  In fact, the best way to distinguish them is to define them by what they cannot do rather than what they can. 

To make matters worse, there are some significant enhancements in the pipeline for many of the tools, which could change their relative positioning again. One example is the planned introduction of Analysis Application Design (flagged as a replacement for BEx Web Application Designer) that will allow you to build custom web applications, which could of course include dashboards. According to roadmap information, this tool will render the output in HTML5 and will be supported on mobile devices.  However, SAP have indicated that Dashboard Designer will render output in HTML5 by the end of 2012 too.  Once these features are in place you will have 4 tools that can produce dashboards of some sort on a mobile device - Webi, Explorer, Dashboard Design and Analysis Application Design.  See the problem?

Then there is also the tension between using the best tool for the job and limiting the number tools you need to develop in, support and train people on, which brings me nicely onto my next point.

3) Don't underestimate the learning curve

SAP BI 4.0 has many components and applications and while the final product can often be a very intuitive report, there is still a difference between a Web Intelligence report, an Analysis Workspace and an Explorer Information Space.  This difference affects the users, the developers and the support team who all have to come to grips with the nuances, tips and tricks and bugs of each application before you're really getting the most out of your investment. This will take time and if you bite off too much at a time can result in a disappointing and frustrating experience for all involved.

The learning curve is another reason to support point 1.  Sticking to fewer tools initially will give you a better chance of doing it properly.

4) Be ready to patch

As can be expected the newer tools in the suite are less stable than the more established ones like Web Intelligence and Crystal.  So if they form the core of your roll-out you should prepare yourself for a steady stream of bugs appearing and applying regular patches.  The good news is that the patches come out pretty frequently so you never have to wait too long for something to get addressed.  Also, while they tend to fix what was broken they don't tend to introduce new bugs, which means so far we haven't regretted upgrading to a more recent patch once.

The down side is that applying patches - even if they are stable and beneficial - is still a disruptive process and consumes effort that you would rather have spent developing new solutions, so there is a balance to be struck here.

It's also worth pointing out that Analysis Office is on a different patch cycle and version numbering than the rest of the suite, which may cause some confusion and means even more careful planning of upgrades is required.

5) Not everything you need to know is documented - you must PoC

The main aspect I have in mind here is the limitations of each of the tools.  So often with IT solutions the devil is in the detail and unfortunately not every nuance of every possible feature in each tool is documented.  For this reason it is beneficial to do a Proof of Concept exercise before launching into a full project.  This will allow you to uncover any hidden surprises or behaviour within the tools and also more importantly validate your tool selection.  You want to be confident you are going to nail the "killer" use case  and a robust PoC is the only sure way of achieving this confidence.

To conclude

The SAP BI 4.0 journey has been an interesting one so far and the product certainly offers some exciting and compelling capabilities.  However, in many ways it is very much still a typical ".0" version and I often find myself thinking this is going to be a fantastic product… in 12 month's time.  Am I suggesting that you should rather wait than consider implementing now?  Not necessarily.  There may be too much value in your "killer" use-cases today to leave this until next year, but be sure to factor the above caveats into your business case before making a decision.