As data flows downstream, it consumes a lot of resources; both storage and processing.
Optimising the data flow requires that you understand the type of objects involved, their features and the system they exist within.
The system itself must be considered when optimising the data flow. There are many different aspects which impact the efficiency of data flow:
- Network latency;
- Geo-located servers;
- Slow DNS servers versus direct IP configuration;
- Firewalls, proxies and packet prioritisation;
- Uncompressed HTTP/S traffic.
- Database binary files are too small;
- Irregular database maintenance and optimisation;
- Database storage engine in use;
- Database cache size for ‘practical use’;
- File systems allocation tables node size;
- Operating system cache block size;
- Use a 64bit operating system and drivers;
- Updated SAP Kernel configuration to latest best practice;
- Regular SAP cache tweaking to match usage;
- Day/night mode for process slots;
- Load balanced application servers;
- Etc, etc, etc.
Unfortunately the above list of topics is very diverse and can be quite time consuming to prove the realised benefits. This is usually why most BW systems are under utilised in comparison to the lean and efficient beast they could be. The main culprit in all this inefficiency is not the desire or capability of the respective specialists who can do the fine tuning, but more the business question “What is my return on investment (ROI)?”.
[Urgghhh] This is a great question as it does have a lot of valid weight and focuses the question back into the realm of practical accounting. “If I spend X dollars the business benefits I get are Y & Z”.
Unfortunately this discussion also does not get very far when it is followed up with “So, tell me exactly what the realised performance improvement will be; before I commit your time to do it?”. Another great question, as there are usually too many variables that even a veteran specialist can not predict with absolute certainty the true benefits. Why?
The process of system performance optimisation is cyclical and based upon rigorous testing; specifically ‘before versus after’ statistics. While these statistics do answer the above question, it is a chicken and egg scenario; you have to put the time and effort in (which is money) to identify the return on investment. Sounds a bit like two-up on ANZAC day; you can only win if you play.
Now add on top of this any kind of time-and-materials arrangement the IT department has with the BW Administrators. The cash flow out the door increases with no guarantee that you will get any return or that the return will be worth it. This lowers the appeal to take any action towards improving the BW system.
If your first response is that you are already paying the service provider to do this then … wake up. Have you asked for or even seen the individual reports that state clearly the individual activities with their before and after statistics specifically to do with general BW system performance improvements. I’m going to go with no, you are probably not paying attention to the achieved results that directly reflect your current time-for-money business model.
This should not be confused with the other types of activities that usually occur as a time-and-materials arrangement:
- Daily support of bug fixes;
- Minor enhancements to align with evolving business processes;
- Planned enhancements (mini projects).
These are services in addition to BW system improvement activities.
Your enterprise most likely has a ticketing system to track daily incidents; it is possibly used to track minor enhancements with a blurry line identifying the planned enhancements.
Major projects are a completely different animal and require a more rigorous, controlled and proven methodology due to the amount of money, people and activity involved.
A lot of managers are snowed in under the weight, frequency and diversity of daily activities driven by the ticketing system. As this happens with very little time to take a step back, breath and survey the overall state of affairs, the only time left for the topic of BW system improvement is “No. Its not broken. Shouldn’t you be working on that high priority activity?”.
So the BW person who has a great idea, a high level plan to implement and a rough guess at the benefit it will achieve; will walk away dis-heartened and the gap between those who drive and those who steer gets a little wider. When this happens too often, the main group of people who suffer are the business users; you know, the people who are the real customers of the IT department.
Congratulations. The business process of needing a rock solid answer to the BW system improvement ROI has itself created an environment that is guaranteed to make the BW reporting solution fail; it is only a question of how bad does it get for the business user community before the CIO starts asking questions like “When are we going to replace that piece of *&#@ reporting solution?”.
All of this suffering could have been avoided, if each team within IT had permission to complete at least 1 BW system improvement activity a month. No complaining, no pressure, no up front proof; all with full support from management to achieve the agreed objective. This is in addition to the regular ticketing system activities.
Given the diversity of the teams needed for different BW system improvements (network, OS, basis and BW) some time doing knowledge sharing on the specific activity will be required.
For Example: Understanding how the inherent relationship between process slots and parallel execution can allow your BW Development system to break the BW Production system during go-live. [Yes, really!]
“once a BW system is embedded in the business,
‘Whats my ROI?’ is no longer a primary question”
All of this ultimately fits under the wider business objectives of ‘Customer Satisfaction’ and ‘Risk Mitigation’. Two topics that are often dis-respected until a system fails terminally or the lawyers get involved.
Each BW system improvement activity is part of these larger business objectives. While the need to have up-front proof for the ROI is good for business accounting; it in fact guarantees a slow and painful withdrawal of the user community as they seek other systems to achieve their reporting needs.
Congratulations. The business user community now spends more time gathering and manipulating data instead of analysing it to make better business decisions. This in turn dramatically increases the human effort and payroll costs to the enterprises bottom line. Visibility of this hidden cost is often overlooked and only shows itself as a lot of complaining about the IT systems.
To make matters worse, when business users are left to their own effort to gather the raw data into a report, their focus is usually quite narrow. Their goal is to have the data ready for their manager, yesterday. This by passes the additional activities that a BI team member goes through to ensure the wider principles of data warehousing are honoured.
Topics like a single consistent definitions, data field integrity, dataset integration and security are just a few that get ignored when the business user is forced (or chooses) to do their own thing because the BW system just doesn’t give them what they truly need.
All of this additional overhead that the business is now doing, could have been avoided if the IT department was able to devote a balanced focus on the daily ticketing and the system improvements, together. This involves a clear and distinct difference between minor enhancements that are driven by the business versus the minor enhancements that are driven by the IT department that are often not visible to the business.
We need both to be implemented side-by-side to successfully reduce system risks and reduce the degradation of customer satisfaction (the business departments within the enterprise and externally the enterprises customers).
When an enterprise requires absolute up-front proof of benefits to the question ‘Whats my ROI? before approval to commence the work is given; the only thing you are truly achieving is an increase and transfer of the ‘Technical Debt’ from the IT department over to the business departments. The real looser in this equation is the enterprises bottom line accompanied by a more frustrated business user community.
What can we do to raise awareness at all levels of the enterprise that ‘Whats my ROI? is not a primary question for driving business decisions on systems that are already in place. This question should only be a primary driver during the business process to decide which enterprise solution are you going to implement. Once the system is in place and being used, the ROI question is counter productive as a primary driver.
Once a system is in place and actively used by the business user community across the enterprise; the answers to the ROI question should be measure against the wider business objectives of ‘Improving Customer Satisfaction’ and ‘Better Risk Mitigation’. You could say the ROI question is no longer the large fish in a small pond but now a small fish in a larger lake.
Give us your feedback: Completely Anonymous, Private & Secure as we value your opinion …
Question: What else can we do to raise awareness that system improvement activities that do not appear to have a direct and immediate ROI, are in fact an investment in the overall health of the entire enterprise? [Yes, this includes the more intangible benefits like employee satisfaction].