Breaking free from BI (or BW)

Sooo, have you thought about buying HANA? Ha-ha, just kidding! No, folks, this is not another sales pitch for HANA or some expensive “solution”, but a simple customer experience story about how we at Undisclosed Company were able to break free from the BI (*) system with no external cost while keeping our users report-happy. Mind you, this adventure is certainly not for every SAP customer (more on that below), so YMMV. The blame, err… credit for this blog goes to Julien Delvat who carelessly suggested that there might be some interest in the SAP community for this kind of information.

It might be time to part with your BI system if…

… every time you innocently suggest to the users “have you checked if this information is available in BI?” their eyes roll, faces turn red and/or they mumble incoherently what sounds like an ancient curse.

… you suspect very few users actually use the BI system.

… your have a huge pile of tickets demanding an explanation why report so-and-so in BI doesn’t match report so-and-so in SAP.

… your whole BI team quit.

… the bill for BI maintenance from your hosting provider is due and you can think of at least 10 better things to do with that money.

What went into our strategic decision

• Tangible cost to run BI. Considering number of active users and value, we were not getting our money’s worth.
• Relatively small database size. The Undisclosed Company is by no means a small mom-and-pop shop but due to the nature of our business we are fortunate to have not as many records as, say, a big retail company might have.
• Reports already available in SAP. For example, it just happened that few months before the “BI talk” even started our financial team already made a plea for just one revenue report in SAP that they could actually rely on. Fortunately, we were able to give them all the information in (gasp!) one SQ01 query.
• No emotional attachment to BI. As far as change management goes, we had the work cut out for us (see the eye rolling and curse-mumbling observation above). The users already hated BI and SAP team didn’t want anything to do with it either.

We’re doing it!

Personally I have suggested that we simply shut down BI and see who screams, but for some reason this wasn’t taken by the management with as much excitement as I was expecting.

Instead we took a list of the users who logged into BI in the past few months (turned out to be a rather small group) and our heroic Service Delivery manager approached all of them to find out what reports they’re actually using in BI and how did they feel about it. Very soon we had an interesting matrix of the users and reporting requirements, which our SAP team began to analyze. Surprisingly, out of the vast BI universe the users actually cared about less than 15 reports.

For every item we identified a potential replacement option: an existing report in SAP (either custom or standard), a new query (little time to develop), a new custom ABAP report (more time to develop). With this we were able to come up with a projected date for when we could have those replacements ready in SAP and therefore could begin the BI shutdown. It was an important step because having a specific cut-off date puts fear into the users’ minds. Otherwise if you come asking them for the input or testing and no specific due date we all know it’s going to drag forever (there seems to be always “end of month” somewhere!).

Drum roll, please

So what did 15 BI reports come down to in ECC? We actually ended up with just 2 custom ABAP reports and 2 new queries, everything else was covered by standard SAP reports and just a couple of existing custom reports. Interestingly, we discovered that there were sometimes 3 different versions of essentially the same report delivered as 3 different reports in BI. In those cases we combined all the data into one report/query and trained the users on how to use the ALV layouts.

The affected functional areas were Sales, Finances and QM (some manufacturing reports were and are provided by our external MES system). There was very little moaning and groaning from the user side – it was definitely the easiest migration project I’ve ever worked on. Breaking free from BI felt like a breeze of fresh air.

Are you thinking what I’m thinking?

If you’ve already had doubts in the BI value for your organization or this blog just got you thinking “hmm”, here are some of our “lessons learned” and just random related observations and suggestions. (Note – HANA would likely make many of these points obsolete but we have yet to get there.)

• If you feel you don’t get adequate value from your BI system it is likely because you didn’t really need it in the first place.
• If you are already experiencing performance issues in the “core” SAP system, you might want to hold on to your BI for a bit longer (unless it’s BI extraction that is causing the issues). Adding more reporting workload to the already strained system is not a good idea.
• Find the right words. If we just told our business folks that we’re shutting down BI the hell would break lose (“evil IT is taking away our reports!!!”). But when you start conversation with “how would you like to get a better report directly from SAP?” it’s a different story. And don’t forget to mention that they will still be able to download reports into Excel. Everybody loves Excel!
• Always think ahead about your reporting needs. I can’t stress this point enough. For example, in our scenario one of the reporting key figures is originally located in the sales order variant configuration. If you’ve never dealt with VC, let me tell you – good luck pulling this data into a custom report. (The same problem with the texts, by the way – makes me shiver when some “expert” suggests on SCN to store any important data there). So our key VC value was simply copied to a custom sales order (VBAP table) field in a user exit. Just a few lines of code, but now we can easily do any kinds of sales reports with it. It only took a couple of hours of effort but if you don’t do it in the beginning, down the line you’ll end up with tons of data that you cannot report on easily.
• Know your SAP tables. Many times custom SAP reports get a bad rep because they are simply not using the best data sources. E.g. going after the accounting documents in BSEG is unnecessary when you can use index tables like BSAD/BSID and in SD you can cut down on the amount of data significantly if you use status tables (VBUK/VBUP) and index tables like VAKMA/VAKPA. I’m sure there are many examples like that in every module – search for them on SCN and ask around!
• Queries (SQ01) are awesome! (And we have heaps of material on SCN for them – see below.) If you have not been using them much, I’d strongly encourage you to check out this functionality. You can do authorization checks in them and even some custom code. And building the query itself takes just a few button clicks with no nail-biting decisions whether to use procedural or OO development. SAP does everything for you – finally! 🙂
• Logistics Info System (LIS)  – not so much. Even though I wouldn’t completely discount it as an option for reporting (yet), it is usually plagued by the same problems as BI – inconsistent updates and “why this report different from that report” wild goose chase.
• When it comes to reports – “think medium”. You’ve probably noticed that in our case number of reports reduced greatly in SAP compared to BI. Why was that? Turned out that we had many reports that essentially used the same data but were presenting it slightly differently. There is no need to break up the reports when display customization can be easily achieved by using the ALV layouts, for example. And on the other side of the spectrum are the “jumbo reports” that include data from 4 different modules because someone requested the report 10 years ago and thought it was good, so he/she told other users about it and other users liked it too BUT they needed to add “just these two fields” to make it perfect, then more and more users joined this “circle” and everyone kept asking for “just these two fields” but nothing was getting removed because the first guy left the company years ago and now no one even remembers what the original requirement was. So you end up with the ugly Leviathan of a report that has to be sent to the farm upstate eventually. Try to avoid those.
• Be creative. If a “jumbo report” cannot be avoided (ugh!), you might want to consider creating a “micro data warehouse” in a custom table that can be populated in a background job daily (or more frequently, if needed). Such reports usually do not require up to the second information and we can get the best of both worlds – minimize impact on performance by pre-processing the data and allow the users to run the reports on their own. Another tip – if a report is used by different groups of users and includes certain fields that are more time-consuming than others, you can add an option to selection screen to exclude those fields when they’re not needed. Also simple training the users on ALV functionality can be very helpful. For example, we noticed that some users ran a report for one customer, then went back to the selection screen and ran it for another. But running the report for two customers and then using ALV filter would actually be more efficient.
• Don’t let the big picture intimidate you. The big goal of taking down a large (as we thought!) productive system seemed pretty scary in the beginning, but, as you could see, we broke it down into pieces and just got it down one by one. And this was done by the team of just 5 people in 3.5 months while supporting two productive SAP systems and handling other small projects as well. If we did it, so can you!

Useful links

Next Generation ABAP Runtime Analysis (SAT) – How to analyze performance – great blog series on the SAT tool. My weapon of choice is still good old ST05, but in some cases it might be not enough.

There are many SCN posts regarding ABAP performance tuning, although quality of the posts varies greatly. This wiki page could be a good start, use Google to find more. Look for the newer/updated posts from the reputable SCN members. (Hint – I follow them! 🙂 )

Some tips on ABAP query – this is Query 101 with step by step guide, great for the beginners.

10 Useful Tips for Infoset Queries – good collection of miscellaneous tips and tricks

Query Report Tips Part 2 – Mandatory Selection Field And Authorization Check – great tip on adding a simple authority check to a query.

(*) or BW? – I’m utterly confused at this point but had the picture already drawn so let’s just stick with BI