After the initial hurly-burly of the business intelligence (BI) project implementation, you and your business sponsors are likely to sit down and take a well-earned breather, preferably in the nearest pub. But pretty soon, you’ll both be asking: “OK, what next?”

Consider the following: Many of your users may not have seen a BI system before and may not have known what they were in for. It is likely that your initial requirements gathering sessions reflected this. Their ambitions were probably limited to a list of reports or to the analysis of metrics in summary. Once you have delivered some OLAP functionality and the toolset to analyse it, they may be getting the idea that there is more to this project than a few dusty old reports. User expectation is likely to have increased by an order of magnitude. It’s time to strike again…

In short, you should visit representatives from your entire existing (and possible future) user-base and ask them for (a) feedback on the system you have just delivered to them, and (b) their “blue-sky” thinking on what they want next.

This may seem a large and daunting task, especially since you have essentially done this already; however, now that they have seen a living, breathing BI system for real, it is an extremely productive and rewarding one. The answers may surprise you.

The first pleasant surprise comes when your users ask for things which you have already provided – metrics, dimensions, reports, cubes and functionality that are already sat on your servers just waiting to be discovered, understood and used. This happens when the “new” requirement has been previously requested by another team or department, or by someone in the same team but not to the knowledge of the representative with which you are dealing. Or, maybe it is the documentation that is deficient, or you chucked it in as a favour or possibly took the opportunity to develop it during the initial project build because it seemed like a good idea at the time. Whatever the reason, they are asking for it and you are able to pass on the good news that the requirement is already fulfilled.

The second surprise comes when you realise that you have loaded the data they require into the data warehouse, but you have not made it available in the “presentation layer,” for example, as a dimension (or attribute thereof) in a Business Objects universe, or in an OLAP cube, or in a Microsoft Report Builder report model. You may very well find that the data is surprisingly close at hand and merely requires a small change to your reporting toolset’s view of the data. A word of warning though: avoid the temptation of advising the users to build their own metric from the component parts available to them. A loss ratio, for instance, is easily constructed in a report by dividing a claims amount by a premium. But as we have previously discussed, there are many claims amounts and many premiums. The chances of all of your users creating the same loss ratio by combining the same two figures is slim. The answer is to agree on one formula, document it and use it to provide the metric centrally in the warehouse, via the presentation layer.

The third surprise is how very sky-high the expectations of these troublesome users have now flown since they were presented with an information system of their very own. Gone are the days when a request for a report must be justified, prioritised, and have a cost/benefit carried out, before the whole process enters a tortuous development life cycle, after which the report is finally released to the now oblivious requestor many months later. With BI system users, that dog won’t hunt. They want their data and they want it yesterday. Anything keyed, messaged, scanned or otherwise input to their operational systems may be demanded in an ad hoc report. Fortunately for you, at this stage in the project you have already made significant inroads into the data-harvesting from major operational systems. The solution (albeit somewhat oversimplified) is to widen the information pipe from the systems from which you already extract data and snuggle it in alongside the existing data in your rapidly maturing data warehouse. As you have already been “into” these systems before, you’ll generally find that your admin and analysis overheads are now much lower – another relatively cheap win.

So much for the low-hanging fruit. Once this harvest is safely gathered in, the pleasant surprises rapidly start to run out and the requests you receive are along more standard data warehouse and business intelligence lines – collect and combine data from new, yet-to-be-plundered systems, implement new reporting and analysis technologies, grab some external, market-wide data and, potentially the most eye-watering of all, gimme some data that doesn’t actually exist yet. This could be a request for a complex metric, long wished-for by the finance department, or even a simple unitary data item that isn’t entered into any operational system in the organisation. It is at least going to need a change to the underwriter’s business processes just to make sure that this data is available at the time of data entry.

For example, a request for the mileage of each vehicle in a fleet at the time the cover starts may be of (perceived) benefit to the motor underwriting department, but the task of capturing that data goes right back to the customer, via the ever-cooperative broker, and must be communicated back down to the underwriter assistant who will enter it into a specially adapted version of the operational system. In this way we see that seemingly innocuous requests take on a life and a cost of their own.

Those for whom the white heat of new technology presents no significant threat may consider that requests for dashboarding, balanced scorecards, portals and whatever else the users have read about on The Register or Slashdot are also a pleasant surprise. They can certainly add weight to the CV.

The feedback section of this series of meetings will also give you a few quick wins – requests for further training and demonstrations, or the location of system documentation, or merely explanations and clarifications on aspects of the system are all easy to supply. Also, this approach genuinely helps to boost user confidence and increase their productivity very quickly. In this way, the twin demons of ignorance and mistrust which appear to a greater or lesser extent around any new system are pushed a little further back into the shadows. And the earlier that happens, the better the prognosis for the long-term success of the project.

Recent articles by Richard Brayshaw

• Using the Data Warehouse to Determine the Profitability of the Insurance Company
• Structuring the Unstructured
• Pick a Number, But Not Just Any Number
• The Language of Insurance Business Intelligence