A year ago, I was onsite to help a large French telecom company with our solutions for their Business Objects migration.
We ran a 360Eyes and 360Bind proof of concept, where we actually run the 360Eyes/360Bind synergy use case. This involves identifying regressions with Bind and then running impact analysis with Eyes to find all documents with regressions.
At the time, the regression was a “Count(If([…]))” calculation engine change between XI3.1 SP3 and BI4.1 SP6.
The customer decided to purchase 360Eyes to streamline the migration. The team is in charge of the BI platform maintenance and they chose this tool for the following reasons:
- Gain visibility on the BI content.
- Clean the environment.
- Organize the migration by priority.
- Provide the key users on the platform information about their own BI landscape.
360Eyes is our BI on BI tool in the 360Suite that provides metadata about your Business Objects environment thanks to jobs documenting all the BI content in a metadata warehouse and a set of webi documents and universes to run analysis.
Specifics on their BI content :
- 20K+ Deski and 90K+ Webi documents (10% public, 20% inbox, 70% favorites)
- 1 large universe (7000 objects, 30% unused)
- 5000 scheduled reports
- 3000 users (90% active)
- Migration from XI3.1 SP3 and to BI4.1 SP6
Visibility
First, 360Eyes provided them with visibility on the content that allowed them to determine the personal/public ratio of the number of unused reports and universe objects.
Cleaning
Using the information in Eyes, the team was able to remove more than 40K documents, resulting in 60K remaining documents in BI4.1. This was based on one simple rule; delete all documents that haven’t been opened/refreshed/scheduled/updated since January 2016.
360Eyes combines the activity from the BOBJ Audit database with the complete list of documents to provide the list of unused documents.
Prioritize
Next, the team prioritized the testing phase.
Thanks to 360Bind, and also their knowledge of the platform, they made a list of potential regressions the key users may encounter during their tests. Based on the list, they categorized all the documents with a level of risk. Risk was determined based on whether a report contained a variable affected by a calculation engine change, a merged dimension, or a specific filter:
- Risk level #1: no regression criteria
- Risk level #2: one regression criteria
- Risk level #3: several regression criteria
And how did they identify the level of risk for each document? 360Eyes provided them with documentation on the queries in their objects and reports, variables with formulas and even blocks, graphs and cells with formulas and filters. In the end, it was a simple Webi document that listed all the BI content with an associated risk level.
Based on that list, key users could prioritize the tests their team performed, beginning with the documents with the highest level of risk.
Another way they streamlined the process was regarding report fixes.
As the end users were testing and finding regressions, the team supported them by providing them with fixes. But they didn’t want to provide a fix for every single document the end users identified. The customer decided to fix the main public documents only and then to redirect the end users to those fixed documents if they had a similar regression in their personal content.
How did they link a document with regressions to a fixed one? 360Eyes provided them with similarity ratio and links to identify cloned documents or documents with the same queries, variables or reports.
So when key users were asking for a fix, they just provided them with a similar fixed document and the users fixed the documents on their own.
Give key users platform information
The last type of cleanup they did using 360Eyes data was with scheduled jobs.
They actually decided to stop all recurring schedules and to restart them only on demand. They did that with an SDK batch program, based on the complete list of schedules retrieved with 360Eyes data. (By the way, 360Live provides the same kind of feature in bulk).
So, key users were contacting them to restart single recurring schedules.
Instead of doing that manually, they set up a simple process :
- Key user would provide the name of the scheduled job to restart.
- They would find the job in the 360Eyes data and extract technical information (ID, frequency, etc.)
- They pass the technical information to the SDK batch which restarts the scheduled job.
With that, they were able to cut in half the number of schedules, for a total of 2500 jobs, compared to the 5000 jobs they had before the migration.
To recap, these are the following use cases they performed with 360Eyes data:
- Assessed their BI landscape: 100k+ documents, 90% personal.
- Cleaned the environment: Volume reduced by 40%.
- Prioritized the migration and tests: with document complexity and similarity based on complete and lowest level metadata.
- Reduced the number of scheduled jobs by 50%.
