Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
In this blog I will attempt to boil down experiences of several BW migration and replacement projects to a short guide digesting the options presenting themselves to most CIO’s today. What should be your path forward with BW Business Intelligence?

Should you replace BW with a new Native Data Warehouse system? Should you migrate to BW/4HANA now?  Should you first upgrade to 7.5 on Hana and go to BW4 later?

If you migrate what kind of migration path should you choose?

Starting Point

 Starting in the early years of the previous decade many companies utilized SAP BW to separate their data warehousing from their transactional SAP systems. Before that reporting typically originated withing the transactional systems themselves often causing performance issues.

Over the years a multitude of internal teams and consulting companies evolved the BW implementation into a large complicated and often redundant BI solution.

New Business requirements would come up causing the re-design of already built solutions further complicating the spider web of data flows. Custom programming in many places would create short cuts to overcome BW internal restrictions. Nothing was ever phased out or cleaned up when business did not use a feature.

Much development was not at all or poorly documented. Teams did not touch old legacy solutions out of fear to break existing data flows. Instead of redesign new data islands would be created duplicating data and creating additional landscape complexities.

At this point, the data loads are working fine, and the reports are provided withing SLA’s with 12 to 24 hours old data. Business Object solutions were built over the years to provide reporting.  Some reports are slow and started to be pre-calculated and often send out by mail to Business Analysts.

Large, crowded Dashboards have never gone through any UI adjustments and are not following modern reporting design principals. The solution is reporting on the past and may do some forecasting into the future.

This is the starting point for most of our customers. Nothing is broken but the situation could be better.

At the same time the industry is going through a paradigm switch for both BI reporting best practices and available technologies.

In this blog I am assuming you have made the decision to stay withing the SAP world. Options provided outside of the SAP universe are not being discussed even though they do exist.

Building a vision for the future

 Business Intelligence in the past was about reporting on the past. Most BW systems today are still set up to support a look backwards. When you build a vision keep these trends in mind

 

  • Operational reporting needs to be real time.

  • Historical data and publicly available third-party data need to be merged and analyzed to make solid predictions.

  • Predictive analytics is using SAP delivered statistical algorithms to predict business behavior.

  • We are going from “What did we do?” to “What should we be doing?”

  • BI is not just reporting but also giving advice.

  • End users are more empowered to control their reporting service through self-service features.

  • Big data is used for archiving and additional external insight.

  • Time to market reporting development cycles speed up with direct data modelling.


Do not get too far behind your competitors in your BI infrastructure.

All these things are the future. How much of it do you really need?

A couple of questions can help to solve this

  • Are my business counter parts curious about data? Are many of them dumping data into excel for further analysis? Do they show interest in new reporting tools, prediction, and real time data?

  • What is my budget this year?

  • Does my corporate culture support quick change?

  • Do I want to keep control within the IT department or am I willing to set rules and let loose?

  • What skill set does my team have?


The answers to these questions will determine the path you should follow.

 Team experience?

 We have had customers who had a team that was comfortable in non-SAP BW reporting environments.

These teams had:

  • Used traditional data modelling techniques in the past and are comfortable with building joins and building data models using SQL or graphical Data Modeling tools

  • They have worked with non-SAP job scheduling products

  • They have worked with non-SAP software life cycle management and versioning tools

  • Understand to build authorization solutions


The question is how quickly could your team adjust to a non-BW world?

And is your team happy with BW as a tool?

  

Business users’ expectations

In some companies Business Analyst are driving the IT team. The users want new data horizons and more predictive analytics. Analysts are coming up with new questions often and are not satisfied with the answers they are getting from BW. Users are starting to take reporting into their own hands by loading data into self-build excel solutions. These users want real-time operational data and high value dash boards and interactive board room reporting.  Many users want to see their data on their mobile devises.

In other business the users are not curious. They want reports to be send to them via email. They go to meetings after printing out these reports and making copies of them. They hardly ever ask a question or have a suggestion for a new report. They are happy with looking at day old data.

 

Cutting edge or Conservative Strategy?

Technical infrastructure decisions also are impacted by the prevailing business atmosphere of a company. Do you want to ride in front of the wave with the newest development or do you want to sit back, letting others test the application for SAP? The customer who is cautious can come on board once it all works better and is more reliable and documented. Is your business demanding the newest now and will not be satisfied with old, tested solutions?

 

Option 1:

Replacement of BW with a Native Hana data Warehouse

One of our customers decided to replace their existing BW system with a Greenfield native Hana Data Warehouse. The client did not like BW as a solution and did not want to continue with BW/4HANA. This was not a big bang implementation but rather a multiyear effort to re-map their business needs into a Hana data model.

The result would be to de-commission the BW system at the end of the project.

 

 


 

 

 

The realization in detail required the replacement of:

  •  Master Data Info Objects with Master Data Hana views

  • BW Master Data Star schema with Native Hana Star Schema

  • SAP provided Transactional Data sources with SLT (or SDI) table replication and data models

  • Data flows with Hana Joins and Unions

  • Bex Queries restricted and calculated key figure with Hana Restricted or calculated columns

  • BW Process Chains job scheduling with Hana XS Scheduler

  • Data flow logic for persistent data with Stored procedure and Custom Hana tables

  • The client was able to replace some of BW authorization features with non-BW tools available in Hana XS.


Lessons learned

  • The build out takes a long time.

  • Make sure to build re-usable information blocks and have rigorous change management in place

  • Data quality testing needs to be more detailed because native data modelling can create bad data

  • Your team needs to be comfortable outside of a typical BW environment. SQL scripting, stored procedure programming and solid data modelling experience are needed in house.


Advantages

  • The system Landscape is very simple with no additional BW application layer between the report and the in this case ECC system.

  • Native Hana Development is providing you with unparalleled flexibility

  • The build out of real time solutions is much easier then in a pure BW environment that is designed more for persistent data.


Disadvantages.

  • It will not be easy to adjust once the ECC system is being replaced with S4. In S4 many tables have changed. In a traditional BW architecture, the data sources will provide the same data also after an ECC to S4 migration.

  • Building Out the Star Schema in Hana is cumbersome and takes longer than when using Open ODS views or Composite Providers in the BW landscape.

  • Hana Authorization is not as robust as BW authorization. It is a larger effort to build a robust authorization environment within a native Hana solution. Most functionalities you find in BW you will also find in Hana with restrictions.


Option 2:

Immediate Migration of BW to BW/4HANA

One of our customers decided to migrate their BW on SQL Server solution to BW/4HANA in a Big Bang project. Simultaneously old BO Webi solutions were replaced with SAP SAC.

The migration took 10 months start to finish. The BW4 migration of a complex large and mature BW 730 system is a large project. This is not an upgrade. The new system is based on an entirely new framework. Months of prep work are needed to re-build the existing system to a migratable standard.

The migration itself is working well but is currently badly documented by SAP prompting many Customer Notes and direct costly SAP involvement.

Here are some (but not all the prep steps)

  • Fix all Multi-provider Compounding Issues

  • Replace all Virtual Info Cubes

  • Replace 3x Queries with “Calculation before Aggregation” setting to Exception aggregation

  • Clean up of all remaining 3.x data flows.

  • Rebuilding of APD’s

  • Complex code analysis and rework of non-compliant code

  • Clean up Process chains and remove unsupported steps

  • Convert all data sources to ODP


 

A direct migration to BW4 will be successful even for complex non prepped BW systems. In this path the client will need their implementation partners help throughout the prep and migration process. Having the implementation partner doing the prep will of course make this option more expensive than the more gradual approach of first going to BW 7.5 on Hana.

There are several different variations of the Migration but in all cases the company will have a BW4 System that will open the path for a very solid development platform for modern Business Intelligence solutions.

These solutions will often merge real time data from ECC/S4 and third-party data sources with historical and freshly loaded persistent data. New Predictive Analytics algorithms will allow the user to not only report on the past but instead getting an insight of the future.

Option 3:

 3 Step approach leading towards BW/4HANA

We have several customers who decided on the more cautious Step by Step approach to the path to BW/4HANA.

In this path the first activity is an Upgrade with DMO from either BW 7.3 or BW7.4 on any DB to BW 7.5 on Hana. This Upgrade will take about 3 month.

BW 7.5 on Hana is a step you can remain on for the next couple of years. Nearly all functionality BW4 will give you is also available under BW 7.5.  Obviously at one point the migration to BW4 will have to happen but going step by step will allow the customer to perform all the necessary migration prep steps by themselves.

Having a 7.5 system that is fully prepped will make the actual BW4 migration much easier. Also waiting on the migration will allow SAP to catch up on documenting the migration process and providing a better cookbook.

A better cookbook in turn will allow the implementation partner to conduct the whole migration with little SAP support further reducing the project cost and timeline.

 


 

 Doing Nothing

Staying on your BW 7.4/7.3 system on a non-Hana Data base will stop you from taking advantage of the greater speed of the Hana db, using the features developed for a modern Business Intelligence system and future SAP support. Its not a viable option if the client wants to stay within the SAP.

SAP Support for BW will be given until December 2024

After that window you would need to either move forward with or away from SAP BI .

BW with and without Enterprise License

BW 7.5 on Hana and BW/4HANA both can be implemented with or without an enterprise license. Without the enterprise license you can only use the Hana database as a DB for your BW system. Only the enterprise license will allow you to build native Hana data models. These Hana models are the preferable approach to build real time solutions. The joins in native Hana can avoid unnecessary data flows or hard to build composite providers within the BW4 system. BW4 is best suited for persistent data modeling while native Hana views are best for real time scenarios. With BW4/ BW 7.5 and the enterprise license you can use a mixed approach of both BW and Native Hana given you the most complete tools set to build BI solutions.

 


 

 

 

 

Decision Flow

 

 

My Favored:

 I saw many customers going into many directions and most have been happy with their choices. My favored approach is the following.

3 Step greenfield approach with parallel landscape

1:         Upgrade old system to BW 7.5 on Hana

2:         Build out parallel Landscape with virgin BW4HANA system.

3:         Clone Delta Queue from S4 / or ECC

4:         Over time build out of new mixed approach solutions in the new BW/4HANA system.

Some flows can be migrated from old 7.5 system to new BW4 system via Shell conversion.

 

 

Conclusion:

 If you are happy with BW stick to it. If you go to 7.5 on Hana or BW/4 HANA make sure to obtain an Enterprise License with it. The best way to go forward is to take your time and allow your team to adjust to the new Platform by following the 3 Step migration approach.

In a follow up Blog, I will discuss a couple of different ways to implement the 3 Step Approach.

It is important to communicate that all these options only change the underlying “plumbing” of your BI solution. The users do not see much change unless you decide to build out a new Greenfield solution. This has caused disappointment with sponsors who hoped to have better reporting after the completion of a multi month project.

Therefore, the migration needs to be followed up with an immediate Optimization Project using all the newly available functionalities.

Keep in mind that this initiative gives you a great opportunity for a fresh start. If you can afford it do not just migrate all of your old flows but rather build a new system that only migrates what you love about your old system and replace flows that have not been perfect.
7 Comments
Labels in this area