Ad hoc reporting, the tools

This post follows up on my previous post in which ad hoc reporting was defined. To wrap things up, the most important features were:

1. Iterative processing of the entire BI-development cycle
2. Performed by end-users
3. On a mix of data sources
4. With some kind of manual intervention, somewhere in the process

Now that we know what we’re talking about, we can much better define the requirements for supporting technology (finally we get to the tools!). Rephrasing the features into requirements results in the following list:

1. Support for the entire process (from ETL to reporting building and distribution)
2. Ease of use: the end-user is the designated user of a BI-solution, not an experience software engineer!
3. Statistics & usage monitoring: some sort of monitoring by IT-staff / BICC is necessary to keep an eye on what’s going on.
4. Security and authorization, e.g. to define roles who’s allowed to map new data sources.
5. Level of integration with the core BI-platform that is used within the enterprise for bulk reporting, pre-defined OLAP-cubes etc.

(Obvious requirements like maintainability etc. are left out-of-scope here).

Probably the most difficult requirement is the last one, level of integration. Let me explain this one. Most mature BI-organizations have consolidated their BI-stack and most of the time chosen for one particular vendor (BO, Cognos, whatever). Current platforms are able to cover a broad range of capabilities, like plain reporting, dashboarding, OLAP etc. The set-up of such an environment is done in the metadata where data sources are mapped to objects that can be used in BI-applications (in SAS these are the information maps, in BO the universe, in MicroStrategy the schema objects to name a few examples). Now here’s the key: this mapping of data sources to (common) objects, is nearly always done based on requirements, design and specifications and done by a BI-developer. Creating accurately defined meta data objects is a key activity to realize a common BI environment with shared definitions.

In the case of ad hoc, ideally the end-user is both able to reuse common metadata that is centrally defined and governed and add new data sources at will which he wants to use for analysis purposes. From a technological point-of-view, the end-user should be equipped with specific functionality designed for his purposes and context and not with the full installation of the client software which is often used by the BICC or BI-developer (apart from license issues). I know this is a difficult one, I hope you can follow me here.

OK, now we get to the vendors! Until recently, to my knowledge SAS’ Enterprise Guide was the only one the market that was able to fulfill this requirement. Fortunately, there’s been a lot of movement lately and some new alternatives seem to be on the horizon. One is MicroSoft’s Gemini solution (see Jorgen’s comment on this one), the other is the announcement this week of MicroStrategy 9 which includes a multi-source option and better self-service capabilities.  Please let me know if any of you have seen these products and whether they are able to fulfill the requirements for ad hoc reporting.

Ad hoc reporting defined

In the September issue of Database Magazine an article was published written by a former colleague of mine and myself about ad hoc reporting. Our aim was to define this type of BI and get around all kinds of fuzzy definitions and wordings used by the industry. Ask any BI-professional to define, and you’ll probably end-up with as many definitions. So to come around this problem, we took the initiative to dive into this kind of use and see if we could find any pattern. The findings of this study are briefly presented here (the’re the same as in the article, which was written in Dutch).

To come up with a description and eventually a definition, we first sat with the actual users who we’re involved in this kind of work. Step by step we walked through their daily practice to see and analyze what they were doing. Typical users were analists, researchers and controllers: people who’s daily work consists of working with data, often using Excel to support it. This case research yielded the following characteristics:

1. For ad hoc analysis & reporting (this is the term we used to denote this process),  the entire BI-development cycle is walked through: gathering data from diverse sources, integrating and preparing the data, conducting analysis, generating a report with the analysis results, distributing it to relevant stakeholders and providing follow-up analysis and consultancy upon the results.
2. It is the end user who does this by himself; there’s hardly any involvement from an IT-department or BICC.
3. A mix of data sources is used: data warehouse and operational, internal and external, formal and informal, structured and unstructured
4. There’s a degree a manual intervention involved. In at least one of the cycle-steps, the user applies specific knowledge or skills he or she posesses.
5. The cycle is iterative. Often, multiple iterations are involved to produce the desired output.

The obvious next question is why the ad hoc process is used in the first place and exhibits the characteristics described above. We have identified the following reasons:

1. To answer one-off or low-frequent management questions
2. To prototype new BI-reports
3. Time to market: answering questions on a very short notice
4. To periodically produce frequently requested information: this kind of use was encountered in small BI-environments, where the ad hoc process may be the only way to deliver output.

With the definition given here, a much better assessment can be made how and where to use ad hoc reporting in your organization and select the appropriate tooling to support it.

BI 2.0.1.34

This is just to have a little fun. He’re some additional topics for the BI fairy tale book Ronald and I are writing. Boy, we should publish a series, like Tolkien did.

• Dynamic BI
• Democratization of BI
• Event driven BI
• BI-for-the-masses
• Creative intelligence
• Reflex BI
• Operational BI
• Enterprise BI
• Cool BI
• Real-time BI
• Self-service BI
• Role-based BI

First gonna call Gartner!

How does BI add business value?

This simple question should be easily answered by any professional in the field. Unfortunately, it often causes a lot of debate when this question pops around. Consider for example the discussion around the business case for BI on the Computable blog (in Dutch). Although some good points were made, there is in my opinion still a lot of misunderstanding. I will try to shed some light and add some system in addressing this issue.

First of all, added value in financial terms translates into a (positive) discounted cashflow. Cash is something different than costs (or expenses). For example, the investment of a logistics company in a new truck of € 10.000,-, results in a one-time cash-outflow of the same amount (provided that it is paid for in one-term). The company needs to pay the truck dealer, to put it simple. However, the cost of the truck is not the same, but the amount the company choses to depreciate. If the truck is depreciated to 0 evenly during 5 years, the cost of that truck in the same year is € 2.000,-. Just looking by the numbers, that paints an entire different picture.

Financially, a business case should be based on cashflow. So when making a business case for BI, what results in a net positive cashflow? Analyst’s and controller’s time that is freed up because their reports are generated by BI instead of having them to make the reports in Excel, does not result in positive cashflow, unless personnel is laid of. Reduced licence fees because of BI-platform consolidation, does result in positive cashflow effects, because it directly affects annual licence payments. When the investment (cash outflow) to migrate old applications to the new platform are less than the savings, you have a positive net effect. Of course, this is a somewhat simplified example but it just serves to illustrate the principle.

So from a financial point-of-view (which is primarily what a business case is), there is no reason not to deploy a BI-initiative that generates positive net cash-flow just by reducing licence-fees. Maybe not sexy, but certainly financially healthy.

Now, let’s look at the benefits side. There’s often a lot discussion that the benefits of BI cannot be quantified and can only be expressed qualitatively. First of all, one needs to distinghuish between benefits that:

1. By definition cannot be quantified, for example the even distribution of wealth in a society, and
2. Benefits that are hard, but not impossible(!) to quantify , like improved company image - or quantified benefits that still have a lot of uncertainty.

In my opinion we’re dealing with the 2nd category, not the 1st. So, we ’shouldn’t hide but work harder and digg deeper. The key to do this is, is to establish a causal and logical relationship between the solution (BI) and ultimately financial results. Put simply, this entails asking a lot of consecutive ‘So what?’ questions: “A new BI-solution will improve the quality of sales information”, “So what?”. A similar point was also brought forward in the 2003 article in Business Intelligence Journal by Steve Williams and Nancy Williams about the business value of BI. They stressed the need to link BI to management processes that impact operational processes or to link to operational processes directly. For example, segmenting customers is useless unless it is used to treat customers accordingly. In other words, to operationally act upon it. Currently, we’re working at Capgemini on enhancing a technique that supports in finding and establishing these relationships. I hope to publish the ins and outs on short notice.

NB: the contents of this post is based on the Business Case methodology developed by Capgemini

“Welcome to the real world”

said Morpheus to Neo when he entered The Matrix. Recognise the situation? I’m currently in the Matrix myself and just had my own piece of guerilla warfare (courtesy RvdG) in trying to get a BI-initiative in a large government organization on the right track. Once again, I experienced the huge difficulties and challenges in getting the story right, negotiating with stakeholders and convincing management on how to act and why. Not only does this case illustrates the difference that exists between the real world and the Powerpoint-world at seminars and conferences, I also felt I still wasn’t fully equipped to do my job.

Again, and I don’t want to become a whiner, I urge everybody to grab those day-to-day problems and start creating solutions for them, instead of explaining that Neuro BI is the next thing around the corner. Dismiss all the fairy tales (checkRonald’s blogpost for some hilarious examples) and start working on the basics that some of us still don’t understand. Consider for example Lidwine van As’ excellent criticism (in Dutch) on an article that completely misinterpretes the Data Vault. As long as we see this amateurism, we still have a lot to do.

So, for me it’s also time to put the money where my mouth is. Therefore, I will try to blog a little more often and address and discuss the diverse challenges we have to deal with day to day! My next post will be about identifying the business value of BI.

Best of breed or integrated?

Time for some bloggin’ again! I was initially triggered to post this blog when Gartner published its Magiq Quadrant for BI 2008. I was disappointed by the position of MicroStrategy, just inside the leaders quadrant. Gartner explicitly favours vendors who adopt an integrated approach and support the entire stack of functionality. But do these platforms like SAP / Cognos or Oracle (with Hyperion) deliver upon their promise? And what should or must be the benefits of such an integrated approach?

I particularly know MicroStrategy and SAS and have seen and worked with both products. Although SAS has a broad platform with all the major BI functionalities and uses a central metadata server, I am rather disappointed by its front-end capabilities. Its core analytic functionality is strong, no doubt, but when it comes to reporting one needs to work with multiple components to get some straightforward functionality, like a look-up prompt or an outline (expand / collapse) report. Compare that to the way MicroStrategy works, a world of difference.

So what should be the advantages of an integrated platform?

1. Costs: fewer platforms / vendor solutions are needed
2. Integrated metadata: but what does this really mean? In SAS, for some parts it seems to imply that all the metadata objects are maintained in the same metadata server but the objects itself are less integrated. Also granularity of metadata is rather high.
3. Lineage: trackin’and tracing your data from the source to target and vice versa
4. Leverage: functionality may be reused for other purposes, e.g. using ETL-functionality for front-end / end-user purposes like a periodic data export or something like that.

So next question: do all these integrated platforms deliver on their promise. My impression – but I don’t know the other platforms / vendors – is that they are still a long way from true integration.

Final question: what is the optimum sourcing strategy? integrated platform or best-of-breed. I know, if market consolidation continues there isn’t much to choose, but I’m curious: what are your thoughts on this topic? Hope to hear from ya!

wouter

Hot from the press: BI meets business processes!

Quite coincidentally, both in the Dutch professional journal ‘Automatiseringgids’ as well as in DM Review, several articles appeared about the convergence of BPM and BI. These observations were based on IDS Scheer’s ProcessWorld-conference in Orlando and the BI Summit in Amsterdam. The main message was that BI needed to be much more incorporated into business processes, BI is there to support running and managing your business processes.

I was stunned by this amazing new insight…. NOT!!! On the contrary, I started to cry out loud and colleagues asked me if I was doing OK.

My fellow BI-professionals, you’re making it easier anytime for me to bring forward my statement you should know by now. The articles I am referring to here, prove and support some recurring observations:

1. We deceive ourselves by our TLA’s which we don’t understand: OBI, BI, CPM, BPM (performance or process management) to name a few. If dicussion stalls, we invent a new TLA or an adjective to it (e.g. ‘pervasive’, ‘enterprise’, ‘operational’, ‘agile’) to pump it up.
2. Arguments and statements are technology centric, not business centric: “BI and BPM-suites (i.e. technology) need to merge, in order to achieve ‘embedded BI’”, whatever that may be.
3. Incompetence and poor analysis: effects and benefits are interpreted wrongly but nevertheless applied to the BI-space. The resulting statements are simply BS.

These examples illustrate to me the fundamental lack of what design science calls kernel theories. Kernel theories stem from natural or social sciences and govern both design requirements as well as the design process itself. Note that ‘design’ in this context encompasses the entire chain from conception to implementation.

So, obvious next question, what are the relevant kernel theories for BI? For example,

1. Systems theory and cybernetics
2. General management theories
3. Decision making

Systems theory introduces the concept of a system and a higher-level system that controls it. Applied to organizations, it describes operational processes and management processes. General management theory introduces concepts like strategy, management & control, and management accounting to name a few. Decision making looks into decision strategies, context effects and cognitive style to name a few.

If you take these fundamental theories into account, it becomes clear that BI and managing business processes (to use our own language) were 2 sides of the same coin, from the very first beginning. So be critical, teach it right and don’t get caught in the bandwagon.

wouter

The industry teaches it wrongly, part II

My first blog with this title gained a lot of attention and I have been following many other discussions through this lens subsequently. As some of you may know by now, I’m rather critical about all kinds of new concepts, theories, products, solutions etc. Let me tell you a small story to illustrate why.

I teach class in the part-time MSc programme in Business Administration at VU University, Amsterdam. Fundamentals of information systems management comprises the main content and success rates of IT-investments are often discussed. One of the students questioned why the industry seems to get away with low success rates, or rather failure rates (sometimes up to 70%) that are frequently quoted. In any other sector, a company would be out of business if its products or services failed 70% of the time. I had a difficult time answering this simple question. THIS is my motivation for being critical.

Obviously, the example above can be countered with numerous other examples and arguments. Also, I’m certainly not suggesting that every IT-investment has a 70% chance of ending up in disaster.  But, in the end it illustrates for me the challenges we face in being truly succesful in adding value. Too often, the emphasis is on the technology and not on contextual factors that seem to me much more important. Consider the following quote: “..most managers receive much more data (if not information) than they can possibly absorb [..]. Hence they suffer from an information overload”. Question: when do you think this was published? Answer: 1967, in Russell Ackoff’s seminal article “Management Misinformation Systems” published in Management Science. Did technology solve this problem in the last 40 years? I would say, partly, but technology also increased this problem. So this is the second reason that I tend to be critical.

Again, with critical I do not mean conservative and I’m certainly not opposing innovation or new points of view. But when they do not help us understand and solve the challenges we face today, I tend to lay back.

So, this brings me to the point where I will introduce some ideas and thoughts how to cope with these challenges. As some of you may know also, I also have a keen academic interest and motivation to use scientific insight for this goal. The concepts I like to bring forward are based on the findings from design science research. Since this blog has already become quite lengthy, I will start an introduction in my next blog. Stay tuned.

wouter

Happy new year!

First of all, a happy new year to you all! Been a bit quiet lately, because of work but also had a few days off during x-mas. A lot has been going on: acquisitions in the BI-marketplace, rumours about Wipro taking over Capgemini (after earlier rumours about Infosys intending the same), many developments in my current client assignment to name a few. X-mas is always a welcome break to both look back and to focus on the future. So the plans have been made! As for this blog, apart from commenting on developments in the BI-ecosystem, I hope to publish some ideas about design science research. Whereas behavioral science intends to describe and explain organizational behaviour, design science is aimed at creating artifacts. Typically in IS and also in BI, our job as professionals is mostly aimed at designing solutions. Scientific research that has been done in this field provides some challenging guidelines that is of use in creating BI-solutions for our clients. Stay tuned!

wouter 

Common language, universal problems

Last week I made a reference visit to the BI & DWH-practice of a large UK government agency. It was nice and informative to exchange knowledge and experience, since I’m running a project for the same kind of agency in the Netherlands. Although maybe not surprisingly, I was amazed by the ease with which we came to terms and were able to discuss our field of profession. Concepts like staging area, data mart, data cleansing and all other stuff provides us with a common language to discuss our work. Again, maybe not surprisingly. But to read it in a white paper is one thing, to experience this ‘life’ and especially abroad is another (at least obviously for me it was).

The good thing, or maybe the bad thing depending on your point of view, is that we also share the same problems. How to create a common view of the business, how do we engage the business stakeholders and encourage them to support strategic solutions instead of short-term solutions and data stewardship are just some of the challenges that are also universal. So we haven’t answered those questions yet but it’s good to know there’s a large community that can both help in creating those answers and benefit from it.

wouter