The Objectives of the Business Intelligence Project

This is the continuation of the transcript of a Webinar hosted by InetSoft on the topic of "How To Deliver A Good BI Application." The speaker is Abhishek Gupta, product manager at InetSoft.

These are the objectives of the business intelligence project. We want to do customer profitability. We want to do revenue enhancement. We want to do product defect reduction. We want to save money. Whatever those big things are at the executive level, that’s where we start in the dialogue, and then we start to decompose the executive goals into the concept of themes.

In the case of customer profitability one theme might be lifetime value scoring, and the other might be customer retention metrics. These two different things are related to the common ethic of customer profitability, and so we may deliver one piece and then a second piece in the second iteration.

And from there we then begin to get into the heart of the agile methodology in the context of the user stories or the business which are often articulated in the forms of business questions. That’s where we begin to put some meat around what the specific information needs are to allow the themes and ethics to be fulfilled.

How These Stories Get Decomposed

Now the next thing we do from there is once we begin, and I’m going to show to you an example of how these stories get decomposed, but what we do next is we begin to decompose the stories or the questions into a set of business terms or a glossary or a data dictionary that then becomes where we move from the business value chain to the technical value chain to figure out where can I pull this data from.

If we think about business questions like how profitable are my customers and are they increasing or decreasing over time and how does it vary by geography. What we do is we’re deconstructing them. I see this term customer, or I see this term geography. I see this term revenue. I see this term profitability and we begin to build that glossary and do data storage searches and define what these words really mean and we get the standardization of terms.

Then we pass that over to the IT group to figure out where can I potentially source the data from, and then as we’re now same within the business value chain we begin to create what's called a business model which I’m going to show you some examples of. Out of that we create a working prototype. And we create a star schema which we can then build a semantic layer around and build some reports and do this through prototyping in sprint zero.

Then we can allow the technical team to work in parallel to continue to do the source systems analysis and then begin to build out ETL and the mappings. We view the ETL and data warehouse architecture layers as an independent subset because we can build a prototype without having to have actually source data. We can create dummy data sets and do prototyping for validation without spending the time and effort to do all the ETL work.

Learn about the top 10 features of embedded business intelligence.

Focus on Business Value Chains

Here is a polling question, does your organization focus on the business value chains when starting BI initiatives in the way I’ve explained it or something similar? I’m going to launch that poll, and if you could go ahead and answer the question. We will give it a few minute. I’ll give it a few more seconds. Okay, so we’re going to close that, and we’re going to share the results and what we see is that 27% say not at all. But we could do better and again this is typical of what we see all the time.

What I hope to show you, and what you can take out of today is it if you start to follow these business value chain processes and methods and adopt them within the agile framework, what you’re going to end up doing is hitting homeruns every time. You’re going to get the business requirements down to a very precise level, and you are going to get very happy business people because of the prototyping methods and what they entail and how what they bring to the table is clarity.

So, having said that if we start to look at that traditional SDLC, and we overlay the value chains, and that’s really where the agile methods and the scrum part comes in, is in that design, develop, and test. That’s really what we’re talking about is working through those in an iterative fashion and then employing spiral methods of building the little pieces, playing it back in validation, doing a little bit more and then running through the SDLC many, many times within a two week sprint and certainly many, many times within a delivery cycle.