Q&A: Basic Business Intelligence Takes Step-by-Step Approach
A consultant offers BI basics for executives, project managers, and developers.
- By Linda L. Briggs
- June 23, 2010
Basic knowledge about business intelligence is often lacking in enterprises, even as they undertake a BI project. In this interview, long-time BI consultant Christina Rouse of Incisive Analytics breaks business intelligence down for executives, project managers, and technical developers. She explains what each group needs to know and how her consulting firm works to deliver that knowledge specifically to each group. Rouse spoke recently on “Business Intelligence 101” at a TDWI Webinar.
BI This Week: When you discuss BI with executives, how do you present the information? As a consultant, what questions do you hear when you initially speak with that group of people?
Christina Rouse: We tend to hear two different messages. One usually comes from the CIO and says, “Hey, we need a BI solution. We just need it.” It’s not well-articulated as to why they need it.
On the other hand, from the [executive] business side of the house, we normally hear, “We don’t have data.” By that, they really mean, “We don’t have information to make decisions and we’re making our decision more on historical patterns or on a hunch.” In those cases, [business leaders] make many smaller decisions much more frequently, and nobody tracks the progress of those decisions.
Do executives understand the value of BI, and the value of good information, once you get to that point in the discussion?
They intuitively know that there’s value to BI, although they often can’t articulate what the value is for their organization.
In those cases, we call in our “BI 101” presentation. There’s a slide that asks about the company’s needs and desires. We encourage them to ask themselves, do we desire to understand our customer more so we can leverage our existing customers and broaden our customer base so we reduce the risk of the company folding due to lack of customer activity?
If we can narrow that down to “We want to increase our customer base by five percent,” that’s even better. Now we can present that information in a dashboard format… We often find that we have to put examples on the table in order for executives to articulate what it means for them and their organizations.
So concrete examples work well?
It’s example after example. You can call them best-practice examples, industry examples, or catalysts. People ask me what I do. I say I’m really a catalyst. I just keep poking and prodding until an idea comes up.
Once an executive sets the focus for a BI project, how do you recommend keeping that focus?
Most organizations set their focus, or cast their vision, perhaps once a year, but as the year wears on, the vision begins to become blurred. People don’t keep that vision in their mind; they lose sight of what it is they’re trying to do. One of the roles of the executive is to constantly keep that vision in focus, keep it crystal-clear.
They have to do that through recasting of the vision at every level. Say you can express the vision to the board and maybe to the executive level, but what does that vision mean to the midlevel managers and the worker bees?
We like to ask people how recently they’ve revisited their vision, and what the duration of communication about the vision has been. Success comes back to three things: recency, frequency, and duration.
When you come in to help companies that aren’t succeeding with BI, what do you tend to see right away?
A huge lack of executive leadership, a huge lack of anyone who is able to, at the table, immediately articulate what the vision is. More important, they’re not able to even find the document. They’ll talk about a little process they maybe went through, but there’s never an outcome. There’s no deliverable from that conversation.
Organizations that are highly successful in BI don’t have to go to the paper file. They know the mission right off the top -- they may not get the words exactly right, but they know it.
Let’s move on to project managers. With that group, you’ve talked about the importance of setting up a BI project as iterative rather than waterfall style. What do you mean by that?
Many traditional IT projects are waterfalls, meaning you complete a step, and then do the next step, and the next, and the next, and the next. The whole thing isn’t delivered to the business users until everything is done. You end up with one-year or two-year projects before the business user sees anything.
BI solutions should be different. They are very iterative -- you work for 60 to 90 days, and you deliver something of value. It’s not all of the data in the organization, but it is subject matter that resonates well and offers big value right out of the box.
For higher education, for example, that “big value” is typically student admissions. An institution with a selective admissions program needs to know how many students are coming in the door -- the traditional admission funnel. How many applied? How many were admitted? How many showed up at the front door? If you’re a tuition-based institution and you don’t get much state support, you need to know that because it makes a big difference in the budget.
With an iterative approach, you build an admissions BI solution first. Then you might add registration and graduation information, then alumni donations. From there, you might tackle human resources and payroll, and then add physical plant and capital funding. You begin to build concentric circles of data around your core business.
Another example comes from one of our clients, Canal Insurance -- their core business is selling insurance policies. The very first BI solution they built was around policy count, written premiums, and the producing agents -- who was producing what. The second level was claims. The third level was the loss ratio. Now [as an agent or manager,] I can track what I’ve sold in policies along with the claims that are against it, and then calculate my loss ratio. In other words, did I price that policy correctly?
It sounds like you’re also telling project managers to start with the things that are most important to the business to build excitement for the next level of the project.
There are two ways you can approach BI -- either go after the revenue line first, or go after the expense line. Most of the time, we go after the revenue line first because it’s the quickest win. People don’t have a lot of patience these days. If you go after something on the revenue line, you’re pretty much guaranteed a success. Then you can start working on the expense line on the P&L statement.
BI is very, very different from building a software application in a traditional sense in IT, in which you have to have all the requirements, you build everything, and then you have a big-bang deployment. That’s exactly the opposite of what business intelligence is.
For project managers, what about the toolset? How do you tailor your recommendations of BI products?
Our company is “platform and tool agnostic,” and we say that proudly. We also say, “But, we’re also not tool silly.” If you have a 20,000-employee company and you’re still running MySQL, that’s probably not going to work.
In terms of cost, there are some very big-name players out there -- such as IBM and Cognos -- that are in the upper price range and feature list. Are we buying a tool in that category, or are we buying a tool in the lower price range like Microsoft which could be $100,000? Now there are some even newer tools such as Tableau coming on the market that are even more cost-effective.
From the point of view of the third group, the technical developers, how do you approach the “basic BI” discussion?
The best thing a developer can do is to understand the components of the dataflow in a business intelligence solution. You typically have a transactional system in whatever database. You then need a tool to extract that data, so you have to learn about ETL tools for extraction, transformation, and loading. You need to learn about business intelligence design of the target database. There are two primary schools of thought there -- Bill Inmon and Ralph Kimball.
In my opinion, you’ll find a lot more Ralph Kimball going on now in smaller companies than Bill Inmon, because Kimball builds in concentric circles. He calls it the conformed data mart, meaning that if I build a dimension called date, date could be used in student, it could be used in accounts receivable, it could be used in payroll. It could be used in a lot of things, so why don’t we build it once and use it 15 times?
When you go into a company and talk to the technical developers, do they not have this kind of basic knowledge?
No, they do not. They do not at all. They are often taken from the transactional world, where they design software and databases to deal with one transaction at a time. Business intelligence is exactly opposite that. We don’t care about a single entry. We want to sweep thousands of [items] at once.
In higher education, for example, maybe we want all the registrations for English 101 over the past 10 years. That question calls for a different design of the database. Often, we’ll work with organizations that will give us their very best developers. We say, “That’s great, but we really want those developers who don’t know anything about your transactional systems because we can teach them the way they need to learn.”
If I had a dollar for every time I heard the phrase, “We could save this space if we just designed it this way.” My standard answer is, “Space is cheap. I want redundant data because it enables the business user to browse the data without any help from an IT person.” In a BI solution, everything we do in the design is all about the user experience in front of the data. Prime time of the day, 8 to 5 -- that’s what it’s all about. We’re trying to make that experience incredibly good, with no handcuffs on the user.
Everything we do in BI is all about that experience during the prime working hours. It’s not about doing it more cheaply or saving space. It’s about enabling someone to romp through the data with no training wheels. When we can do that, we’ve done an excellent job at a BI solution.