Russell Beech, Author at BI System Builders

Posted on April 3, 2011March 29, 2019 by Russell Beech — Leave a comment

SAP BusinessObjects Explorer (aka Polestar)

SAP BusinessObjects Explorer is an exciting Business Intelligence data discovery tool. We’ve created a short live demo video entitled Fast Executive Data with SAP BusinessObjects Explorer. The Explorer tool is excellent for non-technical business managers that want to gain insight into their data. The data made available for analysis is provided via a SAP BusinessObjects universe. The universe can be based on SAP BW or relational data platforms such as MS SQLServer. Features include Google style key word searches on your BI data and data slicing.

SAP BusinessObjects Explorer is currently available in two flavours. The first is as an add-on to SAP BusinessObjects Enterprise and the second is packaged with BWA on a blade.

The pre-requisite for analysis is for a Space Creator to set up an Information Space based on a SAP BusinessObjects universe and then index the data. This is not a complex task. Once this is done the business user can immediately find data insights. We made a live demo video demo which you can watch on the BI System Builders YouTube channel.

Posted on April 2, 2011March 29, 2019 by Russell Beech — Leave a comment

Benefits of Bespoke Business Intelligence Training

This article relates to the use of bespoke BI training for the SAP BusinessObjects toolset.

Training has become commoditised. This approach can bring benefits to both the supplier and the customer. Once training materials have been standardised they can be maintained at a guaranteed quality. The customer’s expectation can be set and a single version of the training truth, so to speak, is established. After set up costs the supplier only needs to maintain the materials. The materials can then be replicated and sold for profit. They are now a product in their own right, a valuable commodity to the supplier.

However, key benefits of bespoke training are that it can be based on the organisation’s own data and be geared to help the organisation address its specific challenges. If the customer is an investment bank why provide training using data based on fashion clothing or white goods such as washing machines? You may laugh but this practice has happened in the past.

The benefit of using the organisation’s data is that the training has more meaning and value to those attending the course. Attendees get to watch and use the SAP BusinessObjects toolset in a way that is directly relevant to them. They are working with data from their own business process area. The SAP BusinessObjects universe that they interact with contains objects relevant to their daily work. This makes the application of the toolset directly relevant. Delegates complete the training with insight and ideas on how to directly apply SAP Business Objects tools to address their immediate business pains.
To achieve the bespoke training it is best to ring fence a dedicated BI environment. If budget exists install SAP BusinessObjects Enterprise on its own machine. Then take a cut of BI data, a snapshot in time. The data should be frozen and should not be overly complex. Overly large and complex data sets can be confusing to beginners becoming familiar with new BI tools.

If there is no budget for a separate environment it’s possible to do some clever things with Enterprise security to effectively section off a training environment on a machine being used for other purposes. The best environment for this is usually QA. If the QA environment is used, care should be taken when scheduling activities so that training and testing do not impact on each other.

Regardless of which environment is used the training will still need use of a dedicated snapshot of frozen data. Attempting to undergo training on live or changing data can easily wrong foot both the trainer and delegates. The training materials, for example a delegate workbook, should contain diagrams and screenprints based on the frozen data set so that both the written training materials and training practice match.
Bespoke training does not need to be prohibitive due to cost. BI System Builders maintain a core of BI knowhow that they then customise to a specific customer. It is not necessary to re-invent the wheel, just to adapt.

During 2009/10 Russell Beech adapted his core know how to design, author and deliver bespoke Business Intelligence training through BI System Builders to members of the UK Volkswagen Group. The training was based on SAP BusinessObjects InfoView and Web Intelligence using Volkswagen BI data.
Bespoke training can go way beyond commoditised training as it is geared to meet the specific requirements of the end users. At Volkswagen the advanced training course included a crash course in dimensional modelling and SQL. It also included workshops on how to practically apply advanced query building techniques to Volkswagen’s real life challenges using relevant data and data warehouse tables.

Posted on January 21, 2011March 29, 2019 by Russell Beech — Leave a comment

Avoid BI Breakpoints With Cornerstone Solutions

BI System Builders in their End to End BI philosophy refer to the concept of BI breakpoints. The application of our Cornerstone Solutions^® will help you avoid BI breakpoints, but what are they?

Here’s an example of a small breakpoint in a BI system with relational tables that illustrates the escalating effort and associated cost. It starts with a poorly defined report specification. In this example no one identifies the specification as being problematic. So the report is developed according to the specification. However, when the report reaches User Acceptance Testing (UAT) it fails. After consultation with the end user that carried out the UAT it is understood that two important report columns are missing, so the report specification is changed. However, the new data columns are not supported by the dimensional model, so this also must be changed requiring modelling and DBA work. This consequence in turn means that the universe and the ETL packages must be changed and so on and so forth. You can see here the interdependence and knock on effect between the components leading to escalating effort and cost.

However, if you know what to look for you can pre-empt where the BI breakpoints might occur and put quality gates in place. Here are some examples of where BI breakpoints might occur in the dimensional model design of a relational database:

The use of a data warehouse generated artificial primary key rather a composite primary key on a fact table
Snowflaking in a relational model (not SAP OLAP)
A table in which its nature is not made explicit though clear naming convention
Table joins leading to chasms or fan traps
Fact to fact joins (there are exceptions)

Now a dimensional model design can be tricky to fully evaluate while it remains purely on paper or a computer screen but it is possible at this point to put a quality gate in place to minimise the risk of future BI breakpoints. Firstly, it can be checked for best practice design principles to avoid the types of things listed in the bullet points above. Another quality gate can occur after the physical model has been generated. This quality gate is to execute business questions against the tables using Structured Query Language (SQL) and to validate that they can be answered. To choose the business questions to be executed via SQL refer to the report specifications or consult the business users.

It is better to write pure SQL statements using a SQL tool than to use SAP BusinessObjects to generate the business questions in queries. It’s a false economy to wait for Web Intelligence reports to be designed to test the physical model. The reason for this is that the design should be validated as soon as possible, and before the universe is generated. To achieve this some test data must be loaded into the tables but it is far more efficient to identify a design weakness at this stage than later on where changes to the physical model will have a knock on effect on the universe design and any dependent reports.

If it becomes apparent in the quality gate that overly complex SQL has to be generated to answer a business question then the design should be revisited and optimized. The business questions should be focussed around any fact to fact joins, snowflaking or bridging tables as these are potential BI Breakpoints. Their existence can lead to very poor performance, miscalculations due to chasms and fan traps, and the prevention of drill across.

To minimise the risk of BI breakpoints occurring the BI Architect should introduce best practice principles along with quality gates early on. Here’s an example of the best practice principle of designing aggregates. The use of aggregates upfront can address three breakpoint areas before they occur:

Slow query response times
Report rendering times
Overly complex reports

It is of course vital to select the correct aggregate type to support the end user requirement. There are several different types of aggregates for example invisible aggregates (roll ups), new facts (ETL pre-calculated fields), pre-joined aggregates and accumulating snapshots etc. Aggregates allow the processing effort to be pushed way from the report and into the database engine and ETL program where it can be more efficiently executed. However, the use of specific aggregates should not be decided upon until the detailed report specifications are available. Choosing the most appropriate aggregates to support the reports requires skill and experience and is not a menial task.

Aggregate tables can significantly reduce the size of the row set returned to the BI reporting tool. As a rule of thumb it is always better for BI reporting tools to work with smaller row sets. It is always best to force as much processing effort as possible back to the ‘gorilla’ of the BI system – the server itself. It can be even better when processing effort and calculations are forced back into the ETL program. However, care should be taken to educate end users when the effort is pushed back into the ETL program for calculated facts, so called ‘New Facts’, because the facts may be semi-additive or not additive at all.

The downside of using aggregate tables is the increased maintenance e.g. administering ten tables instead of five and the ETL effort required to support them. However, their benefits outweigh their cost.

BI breakpoints can manifest in far more areas than just relational tables, they may be seemingly invisible, and costly when they occur because of the independencies of the BI system. However, applying governance to the BI system around breakpoint areas is not always the most popular notion at implementation. This is because it requires the effort to think clever and to apply hard work, rigour, and discipline upfront to pre-empt problems that are almost invisible. We may be tempted to take short cuts, but, it’s better to apply the extra early effort. Entering into small skirmishes and battles in the early stages to iron out BI breakpoints is much better than allowing them to go unchecked and develop into big fire fights later. Regardless of whether your BI system relies on SAP OLAP cubes and queries or relational tables BI breakpoints are a real threat.