I am often asked what are the top-10 issues and mistakes made when using SAP BI as an Enterprise Data Warehouse (EDW). At the Information Management Conference 2010, I sat down and spent some time thinking about all the issues I have seen over the last twelve years I have been working with SAP data warehousing.
After looking at symptoms, I quickly became aware that there are really underlying causes that creates havoc on the best laid plans. Here is a short list and some observations:
Pitfall #1: Lack of Reasonable SLA with EDW Support Team
Some examples of reasonable performance include:
- 90% of all queries run under 20 seconds
- System is available 98% of the time
- Data loads are available at 8am — 99% of the time
- User support tickets are answered within 30 minutes
- User support tickets are closed within 48 hours — 95% of the time.
- System is never unavailable for more than 72 hrs — including upgrades, service packs, and disaster recovery
- Delta backups are done each 24 cycle and system backups are done every weekend
Pitfall #2: Jack-of-all-trades - Master of none….
- BI is complex with many different tools and technologies. Don’t rely on a single person with no specialized skills.
- Make each person responsible for a focused technology/task.
Pitfall #3: An army of ‘Arc
hitects’ who don’t understand SAP.
- Have one ‘architect’ – quality is more important than quantity
- Architecture is technical by nature. PowerPoints only gets you a small part of the way.
- The BI architect should know the technology better than anyone in the room and be able to design solutions.
Pitfall #4: Not separating the Support Team from the Project team
- Keeping the ‘lights-on’ is a core focus area.
- Many EDWs fail because of lack of training, production and user support, and by having nobody around to do continuous improvements.
Pitfall #5: A Firm Belief in Monolithic Data Warehouses
- Google runs on over 500,000 servers, why must your data warehouse run on one?
- Divide and concur when the performance becomes a too-large problem.
- Separate BI onto SAP BWA and use the data warehouse for data movement and data storage.
- You don’t need a monolithic castle, but storage & performance
Pitfall #6: Analysis Paralysis.
- You will never have perfect EDW requirements – get over it….
- The business will change and so will the BI system. Change is a sign of success not failures (people who care wants to make it better).
- Not moving forward and keep analyzing is a costly decision…
Pitfall #7: A Single User Interface will solve all my EDW problems..
- There are no magic bullets. Most companies need 2-3 end user tools.
- Start with OLAP (Pioneer) web, then co
ntinue with ad-hoc querying (Webi), and finalize with dashboards (Xcelcius). All other tools are great, but not a starting point.
- Remember you first crawled and walked before you ran.
Pitfall #8: Enforce EDW Standards
- Standards are not a word document buried in a file cabinet
- If you allow ‘exceptions’ the standards quickly become meaningless.
- It costs to keep your house clean, but data management and data integration will benefit greatly from it. Remember: “the road to hell is paved with good intentions” - unknown.
Pitfall #9: Keep Your EDW Support Team motivated
- The average application developer stays on the job for 47 months, the average support person is only there for 25 months!
- It is very expensive to use the support team as a training ground for technical staff and it hurts performance.
- Make the support team a ‘cool’ place to work with flexible hours and defined career paths.
Pitfall #10: Not Creating a ‘BI Technology Advisory Board’ for the EDW
- Use ad-hoc best practice advice from external experts on a periodic basis.
- If you are struggling with something, there are many others who have ‘cracked the nut’ already – leverage their experiences.
- Attend BI conferences, take good notes and leverage the many experts at the booths, the speakers and the forums.
- You are not alone, but your team needs to get ‘plugged into’ the many ASUG, BI Expert, SDN and SAP BI communities.
More ideas around Federated, Cente
ralized and De-centeralized data warehouses to come..