Approach to migration of web-based reports SAP BI

There are a number of different aspects that we need to understand around this process and the success of a migration is not only due to the system process but also relies on the business and political environment at each company. You will have to do a complete duediligence process initially so that you will not fall into any of the potholes embedded in the business culture. This due diligence requires a round or two of meetings with all the different groups that will be affected by the migration. You should very carefully pull together a hierarchical list of the critical issues and challenges that you might encounter during a migration process. The migration process can be overwhelming without a list of items that you can check off as you complete them.

A good first step in the migration process is to clean up business users’ Favorites folders. Business users tend to assign frequently used reports and other objects to their Favorites folders but fail to get them changed over to standard reports. The issue is that nothing in the Favorites folder is migrated. So, you need to find out which of these reports and objects lurking in the Favorites folders of each department, group, and team need to be moved over to a folder within a specific role so that they can be migrated. You also need to come up with a strategy for moving them, including the variants associated with them. You’ll need to explain to business users which reports are candidates for being moved. For example, if a business user has 75 reports in their Favorites folder, you need to instruct them to identify and list the reports that are essential to performing their job. Then, you need to follow the company process for moving them to the appropriate role and folder. Getting business users to give up less than all their favorites is not as easy as it may seem, but with a little nudging and some time limits (always put a time limit on this task), everyone will come up with a list.

Great, you have completed your first task in the migration process. Now, you need to decide on which approach to use to do the migration. Following are some questions to consider:

  • Go with a big bang approach and migrate everything in one session, or migrate the reports in phases?
  • Migrate the reports of each department based on need or requirements, or start with the group that has the smallest list of reports and go from top to bottom via that approach?
  • Start with the group that needs the most help with VBA or customized reports with numerous custom APIs or lots of broadcasting, or do this group last? Whichever approach to migration you choose, make sure you establish some justification for it so that you have answers ready when users begin to question your timing.

What I try to do is understand the client’s needs and timeline and then look at several aspects that would make or break the client’s project, and then I make the choice based on those criteria. There is not a strict rule for which approach to take, so it is more of an art than a science.

You need to make sure that you minimize complications in whichever approach you take; in other words, make the process as easy and as straightforward as possible. Avoid a migration where 50 percent of the reports for a department are migrated and the other 50 percent are still using the 3.x toolset for reporting. The user is bound to get frustrated and use the wrong toolset, creating even more issues. Take a step-by-step approach so that everyone can understand and feel comfortable with the migration process. Importantly, you must inform business users about the migration process beforehand. Conduct learning sessions, both formal and informal, where you demonstrate the functionality of the system so that the business users are comfortable with the change. Demonstrate the newer functions of BI 7.0 reporting, such as the additional flexibility of the Information Broadcaster, the use of calculations within the frontend of the Web report, or the numerous new functions in the Web template and what’s behind each of the buttons on the screen—exceptions, conditions, all the key figure attributes, and so forth. In my experience, the more I demonstrate functionality and talk to the business users, the lower the total number of defects I have to deal with and the more directly I can work with business users to resolve problems.

If you have 100 business users who are migrating reports that they’ve been working with for years, you really need to train them on the new reporting functions thoroughly. This will definitely reduce the complications when going live and eliminate much of the lower-level complaints about the new reporting tools. You will definitely reduce the number of comments like “this reporting toolset doesn’t work the same as my former frontend” or “this reporting component doesn’t do everything that the other frontend did.” If you demonstrate the functionality that has changed, you can avoid issues down the road. For example, there is a significant change to the process of inserting a query into a workbook. The 3.x version has a command on the context menu—Insert Query. In the 7.0 version, that option is gone and you have to follow specific steps to insert a query into a workbook. The reason for this is the use of the two different support stacks—ABAP and Java. In this case, demonstrate the multiple steps required. Following are some of the other changes you might consider demonstrating:

  • In the BEx workbook, the use of the Insert Query function has been replaced with the use of the “design mode” toolbar to assign the different objects from the query into the workbook (for example, navigation pane, analysis grid, and information). A one-step process has changed to a six-step process.
  • In the BEx query, the entire view has changed because the basic template has changed from a tab-based view to a button-based view.
  • In the WAD template process, the Role Menu Web item has been eliminated and the Map Web item is only available in the WAD and not the BEx Web Query.
  • The navigation process within the BEx Analyzer and the BEx Web Analyzer has changed. Training material will be needed to make the transition to the BI 7.0 environment consistent and straightforward.

To avoid confusion during the migration, make sure everyone in the company knows well beforehand when it is going to occur. This boils down to administrative activities mostly and all very critical. As you start to move closer to the go live date, make sure all users are aware of the timeline, and give them updates if anything is going to change. Also, in terms of planning the migration itself, try to make the reporting shift during a time when the business users have an opportunity to make sure they have everything they need to do their jobs. Try to do the migration over a weekend or during a slow time of the period. Avoid doing the migration right before a period closing or some other very important or critical activity. This will avoid confusion and make everyone proactive in their approach to the migration.

Another area to be aware of is compatibility issues or accidental migrations. Avoiding any additional concerns around these two aspects of the migration is important. In one instance, a project that I was involved with was going through a migration and for some reason the customer didn’t realize that the new BI 7.0 system needed all of the functionality of the Java stack to be available and thought that the BI 7.0 system worked on the same or similar platform as the 3.x system did. So, there was little or no support for the Java stack issues and concerns. The BI portal was not set up appropriately for the migration and to accept the 7.0 IViews for the reports to be attached to the portal. You can avoid all these issues that deal with overall system capabilities by communicating with the client in the planning stage. For example, make sure that everyone has the appropriate version of Excel uploaded to their laptops so that there’s no problems debugging any issues and you don’t have to worry about inconsistencies in the basic Excel versioning.

Don’t look to try and overkill the migration, meaning don’t try to migrate all of your WAD templates, Web reports and all queries at once. There are very good reasons why you don’t migrate some reports such as those that have large amounts of VBA or the business user is fine with what they have—3.x version, or the resources needed to deal with all of the fixes required for the migration are not available on a 100 percent basis but can only devote 50 percent of their time to the migration.

To summarize this section, make sure that you have a very good plan! This is the key to a successful migration. Make sure that you keep it simple and make everything as clear as possible to business users. Remember, your customers are the business users and management of the corporation, not the IT department. Their needs are quite different from an IT person who isn’t concerned if they’re looking at a list of information or a dynamic report. If you phase in the migration, you should be able to build on wins as each phase is rolled out. Ensuring that the initial phases are a success is very important so that word gets around how much more flexible and user friendly the newer system is for the business user. This will definitely make the remainder of your migration process easier and less stressful.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

SAP BI Topics