InetSoft Webinar: BI Data Analysts Interviewing Subject Matter Experts

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.

Business modeling is what I am talking about with that business value chain and deconstruction. Here is an example of what that might look like. So we have our Business Intelligence or Business Analyst, a BI or BA. They are interviewing subject matter experts, the business users, the business sponsors, and they are trying to get the requirements in the form of a question or a goal statement as opposed to a paragraph or something or data model.

We’re just simply trying to get the business to articulate what they are trying to do. So if we look at an example, and this is an actual example. I have hidden some of the terms, but this was a BI application for cross selling across two business units. One had acquired the other, and they were looking at lost opportunities between the two business units in terms of common customers.

So the business question was how many deals did we lose, and that was defined as close lost status. What was the contract value of those deals by time, by business unit, by customer type, that were joint customers by our business segment? Look at them by customer name and by product category and by industry, and as you can see that was the articulation of the need. That story got created in the business values.

Premium Paid on BI

Now I will tell you the BI or BA is something that we pay some premium on. It is a skill set that can be learned, but it's not something that you typically do in a application requirements definition. There is an art and a science to the BI or BA to work with the businesses and being able to draw these types of questions out of the business. So if we look at that question, the next step of the process is to decompose the question into a set of business terms to create the data dictionary. From there we allocate the different business terms to their object type. So we say, oh this is a dimension. This is a measure. This is an attribute that kind of stuff.

So if we look at back to this question, and we begin to deconstruct it, what we were able to do through looking at the question itself, and then in further follow up with the business people is we start to see these things called lost deal count and start to see these things like customer name, and as we clarified with them, oh we’d also like to know their address and their customer number.

We’d like to know their industry and the territory so we can look at the different types of managers. We saw this thing called hierarchy. We saw the deal status, and then we asked, what are the different values it can take? Getting the simple questions on a story card, we in the IT Group and the BI/BA and the data modelers were able to deconstruct this interviewing and modeling technique into the specific set of data needs that will allow us to pull the data into the warehouse and build the analytics around it to answer that specific business question.

And notice that nowhere did we talk to the business in terms of data models or star schemas or relational models or any slowly changing events. We had none of those words for you. This is simply a dialogue with the business which then the IT group and the business analyst take back to the desk and begin to do the deconstruction and the modeling.

Read what InetSoft customers and partners have said about their selection of Style Scope for their solution for dashboard reporting.

Do Some Prototype Dashboards

From there then we – once these have been built and built inside of a business model we can then generate the star schema and create the prototype and then begin to do some prototype dashboards and do some prototype queries. We put the business question next to the prototype and allow the business to play with it and see if they can answer the question.

That's really the idea of what we are doing here and then obviously we may do the business model two or three or five or ten times. The first time we bring it back we say this is what we heard, and the business says, yeah but that hierarchy just doesn’t look right. Or, I forget that this field is important to me. Or, that really I don’t need. We’re getting this clarity through this modeling exercise and prototyping exercise.

Once we get to the end of the prototype and say that's what I want, now we have really locked down the business requirements to a very high degree of precision. And again we haven’t spent a lot of time, a lot of money. We have not taken on a lot of risk because we have done no data integration to this point. So at this point it’s in sprint zero. It’s about requirements and prototyping the clarity.