[
]
ITIL RSS Feed ADDTHIS
 
ITIL 2011 Books ITIL v4
ITIL and Business Intelligence
Introduction
 
I hate the word 'holistic', it conjures up images of questionable medical techniques involving scented candles and crystals.
 
But when it comes to describing how Business Intelligence implementation should be approached, holistic fits the bill perfectly.
 
An overall strategy for a company's wellbeing is the desired result after all.
 
How much of your Business Intelligence is wrong?
 
So far Business Intelligence has had a free ride due to being the new kid in class.  Companies are mainly just grateful for any insight into their data that quality can be less than perfect and people are still happy.
 
Due to unstructured BI implementation, it is normally approached in a haphazard manner which leaves room for mistakes.  This room is literally space, the space between the requirements for specific reports which are needed to meet particular business plans.
 
This reactive, patchwork approach to BI development is great in the short term and can create real immediate benefits.
 
The long term problems however, can outweigh the initial gains.
 
The Risks to Business
 
I think everyone knows the story about the business which went bankrupt due to an end user's mistake on an accounting spreadsheet....I don't even know if the story is true but think the warning is a valid one regardless.
 
So can a Business Intelligence report create such destruction?
 
It depends on how pivotal the report is to business decision making.  But many BI reports measure services by third party suppliers and mis-measurement can cost.
 
Another risk is that if a team (3rd party or otherwise) realises certain work is not measured it can lead to a lackadaisical attitude in this area.  A prime candidate for this scenario is when a team is not measured on how quickly they respond to jobs assigned incorrectly to them.
 
Incorrect measuring of work volumes can lead to unneeded redundancies followed by overworked remaining staff.
At the very least, managers who have little or no faith in the information BI is providing will not take it into account in their decision making....which is pretty much the whole point of Business Intelligence.
 
Timing is Everything
 
One of the most common mistakes with BI reporting results from date ranges being used in a contradictory manner.
 
One of the most common errors in this area of reporting is to filter on all closed jobs which were opened in a certain time period.
 
At first glance it appears a reasonable request, but if the report is run weekly for the previous week it will only display jobs which were opened and closed in the same week and so will miss:
 
1.  Jobs created before that week, which were closed during the week.
 
2. Jobs created within the week but not closed when the report is run.
 
Both of these cause information to be missed from reporting, and usually the worst slice of data.  The shorter the job, the more likely it is to appear in the report and any job taking over a week is guaranteed to never appear.
 
The second of these two issues is arguably the worst, as the report has the potential to change every time it is run, depending on how many jobs were closed since the last it was refreshed.
 
Conflicting Logic
 
No matter what reporting software is used, it is all based on SQL and the manner in which this logic is applied can lead to holes in the BI solutions.  And these holes, however small, can allow large amount of data to stream through.
 
A good BI expert knows how to work around these limitations, but the less experienced may not even notice anything is wrong.
 
As well as the SQL issue, all reporting software has its own quirks and oddities which can cause it to provide results which are different to those expected.
 
Changing Requirements
 
Businesses change over time and these changes are often reflected in the data stored.  Keeping reports up to date can be a real challenge, especially when those responsible for the BI solution are not kept in the loop.
 
In many cases the changes to a company's procedures and data can happen piecemeal as part of the natural evolution of business.  This can be something as subtle as a single data inputter.
 
The Bigger They Are The Harder They Fail
 
The truth of the matter is that the bigger the organisation, the bigger the scope of the BI implementation the more likely information is going to be lost.
 
If a sole trader wanted analysis on everything they had ever done the report would be all encompassing.  Once the sole trader acquires a partner and the work is split between them, a crack appears.  Some jobs may belong to one of them, some to both.  Without proper care the shared owner jobs can vanish from reporting...or be counted twice, which can equally skew the results.
 
Now the two businessmen want to know how much work each have completed this month.  So now jobs which were started before the month and closed in it can vanish, alongside the jobs which both worked on.
 
Extrapolate this up to a multi-national company with thousands of teams and employees and the potential for missed information becomes shocking.
 
Technical Shortfalls
 
Unlike most software creation, BI is usually undertaken by solo developers.  Even with larger teams, individual reports are written by separate developers.
 
Because of this the technical abilities of the developer can have a huge impact on the quality of the BI reports produced.
 
It is not unheard of for team with no BI expertise (either technical or methodological) to create reports to monitor their own performance.  It is unfair on the team and the results are often erroneous.
 
On a personal note: because of the lack of formalised training and the newness of Business Intelligence as a discipline, some horrendously low quality reporting solutions are implemented. 
 
As a specialist in Crystal Reports I used to get annoyed by constantly hearing "the software can't do it".  This has since been replaced by a greater nuisance, namely, partial development (usually dictated by the ability of the developer) which are touted as complete solutions.
 
Service to Operational
 
Service Level Agreements (SLA) are easy!  You measure when something starts, when it finishes and compare that to agreed target.
 
Operational Level Agreements (OLA) have more holes than a sieve for the data to escape through!  When measuring an OLA the whole point is to cover all aspects of the work done by a team or individual during a certain time period.
 
It is easy for things to get lost.
 
Consider this checklist:
  • Jobs opened before the time period and closed within the period.
  • Jobs opened during the period but not closed until after.
  • Jobs worked on during the period, but passed to different team for completion.
  • Jobs worked on during the period which were opened before the period and not closed until after.
  • Jobs started and completed within the period.
  • All different types of job undertaken by the team in the period (eg: replying to phone enquiries as well as doing the actual work this generates).
  • Jobs started (or closed) outside of agreed working hours.
  • Cancelled jobs.
To miss any of these is to do the team in question a disservice and discount the hard work they do.
 
Putting Things Right
 
Expertise has to be the first step, whether through in-house training or hiring an established professional.
 
A little knowledge goes a long way and having an expert eye cast over an existing Business Intelligence solution can identify and correct a multitude of smaller scale issues in record time.
 
Plugging the Gaps
 
That last section sounds like a lot of work, right?  It probably is not practical for many businesses to totally overhaul their BI reporting solution.
 
The quickest route to identifying the gaps in reporting is reference existing reports and look for the opposite conditions.
 
For example, if a report criterion shows all jobs handled by a team between 09:00 until 17:00, is the work done outside these hours captured?  Is the team member who gets in at 08:30 and leaves at 16:30 not being measured on their work before 09:00?
 
There may be a report which captures this information, but often there is not.
 
By applying this same logic across the entire reporting library it is possible to build a full picture of what is recorded and what is lost.  Whenever possible, someone with extensive knowledge of the reporting library should be used.
 
Summary
 
Business Intelligence can be the most valuable software tool for businesses, but when done correctly.
 
BI is still in it's infancy but that is no excuse for its first steps to be shaky ones.
 
With a 'holistic' and consistent view to how data is analysed we can really put the Intelligence back into Business.
 
About the Author
 
Jason Dove has specialised as a Business Intelligence consultant for over a decade and is the mastermind behind  www.scry-business-intelligence.com a company dedicated to making your company more efficient.
 
 
You may also be interested in this article: > What is Service Reporting from an ITIL perspective?
 
Be the first to leave a comment about the above article...
Please submit any comments you have about this article.

Your feedback will help add value to the content for other ITILnews.com visitors and help us develop the content for the benefit of all.

You will need to provide and verify your e-mail address but your personal information will not be published or passed on to others. To identify each post we take the part of your email address before the @ sign and use that as the identifier, so if you are john.smith@itilnews.com your post will be marked "by john.smith".

NB: We respond personally to every post, if it calls for it.


Characters remaining:

Click the REVIEW button below to preview your comments.


 
 
Tags; Business Intelligence,Valuable Information,Falling Through the Gaps,Service Level Agreements,Operational Level Agreements,Crystal Reports
 
This article has been viewed 4089 times.
 
NB: This page is © Copyright ITILnews.com and / or the relevant publishing author. You may copy this article only in it's entirety, including any author bio and / or credits, and you must link back to www.itilnews.com.