The following scenario happens all too often..
SAP customer who has implemented SAP BW Integrated Planning is experiencing unsatisfactory performance. This is holding up the budgeting/ forecasting process and users are getting frustrated.
The IT Manager calls on the SI partner to perform a performance review to ascertain where the problem lays and to find a resolution.
SI partner comes in, finds the root causes of the performance “problem” and writes up their recommendations.
The report gathers dust on the IT manager’s desk and few or none of the recommendations are put in place. Result is that money has been burned and the business folk are still suffering.
So, why are those recommendations so rarely implemented in full?
Part of the answer to this is that it comes down to expectations. The IT manager is hoping that the consultants performing the review will find a “magic cookie”, a tweak that can be made during the review that will improve performance drastically. It is, sadly, rarely as simple as this. To understand why, we need to look at the sort of recommendations that often come out of these reviews.
The answer to the question “can you make it faster” is, invariably, “yes”. There is always quicker, newer hardware that can be migrated to that will make a huge impact. BW (and therefore IP) needs fewer faster CPUs in the server, rather than more slower ones but the faster the CPU the more cost. This is an easy, and not necessarily costly, fix to the problem. It’s rarely taken that way, and replacing hardware is considered to be too “difficult” or “expensive”. But the new server might cost in the region of £10,000 – convert that to consulting days and the reality is that it’s a good, cost effective option. “Difficult”? I’m reliably informed that it shouldn’t be.
There are a whole set of performance guidelines that should be followed around cube design, how to design the aggregation levels, optimal size of queries, optimal ways of implementing functions etc. The performance review might identify a number of improvements that can be made, but these will undoubtedly be invasive and, therefore, costly and difficult, because these changes need to be treated as a project in their own right, with full regression testing of the planning application. There may also be a change management angle if the user interfaces are changed.
Thirdly, patching, patching, patching
SAP is constantly improving the Netweaver environment and they do so through support and enhancement packs. If your BW system is not on EhP1 SPS6, or above, then you will not be achieving optimal performance in IP. This recommendation rarely goes down well, because there is often a reason why the BW system is so far behind in patches already. There is never a good time for the system outage and regression testing required as part of a patch upgrade, but it is an essential piece of maintenance. BW systems needn’t require the rigorous regression testing that a productive R/3 or ERP system would and, if this process is run smoothly, it needn’t place too much of a burden on those required to regression test.
Finally, magic cookies
Yes, these do exist. At one client, I turned off the comments functionality in a query and, in doing so, immediately improved performance by a factor of two. At another client, creating aggregates drastically improved performance. There IS hope.
Ultimately, it comes down to expectations. Before going down the process of looking at performance, you should ask yourself how much of a problem that performance is and, therefore, how much effort and money does it warrant throwing at it. Because performance can always be improved. Are you willing to drive through and pay for a hardware upgrade? Are you willing to contemplate a project to implement a redesign of your budgeting solution? Are you willing to commit business resources to regression testing a patch upgrade?
Or are you just banking on there being a magic cookie?