The Right StuffThe Right Stuff

Business intelligence applications are moving upward and outward. Corporate executives, business unit managers, customer representatives, and now customers themselves expect quality, timely information. A roundtable discussion reveals what's top of mind in the user community.

information Staff, Contributor

September 7, 2004

19 Min Read
information logo in a gray background | information

What's the current state of business intelligence? The answer is best told through the experiences and observations of those who bring it to life by leveraging an increasing array of data warehouses and application databases. To highlight our 5th Annual BI Special Issue, Intelligent Enterprise is proud to feature this cross-section of BI users in a roundtable discussion.

A key aspect of BI is that first word: "business." More than any other technology, BI succeeds when the business side is intimately involved in determining what will constitute the "intelligence" that IT can produce — especially when it comes to the great "real time" debate.

James E. Cates is VP, Information Technology and CIO at Brocade, a leading provider of storage infrastructure solutions. Cates draws on more than 30 years of IT leadership, and is the author of the influential "Ladder of Business Intelligence" methodology. Louis-Robert (Bob) Denis is CIO and VP at Trimble Navigation, a maker of navigation systems and software based on the global positioning system satellite network. He brings more than 20 years of expertise to the design and implementation of information systems, applications, and supporting infrastructure.

Rhonda Kirkpatrick is project manager with the State of Iowa Dept. of Revenue. She is joined here by Les Arnold, solutions architect; and Richard J. Puhl, Jr., lead data warehouse architect and Teradata V2R5 Certified Master. Steve Tracy is assistant director of Information Delivery and Applications Strategy at The Hartford Life Insurance. He has built production data warehouses in the healthcare, retail, and environmental engineering industries. (Note: Stuart Robbins, Executive Director of the CIO Collective, joined this discussion; see Strategic Knowledge.)

We thank the roundtable participants for their insights and commentary.

IE: How would you describe the contributions of business intelligence (BI) and data warehousing projects to organizations?

Rhonda Kirkpatrick: I would say that BI and data warehousing have brought strong return on investment. Tax revenues due to the State of Iowa were going uncollected until we had the tools and technology to identify likely areas for investigation of underreporting taxpayers. BI and data warehousing have given business users more information, resulting in higher ability to do their jobs and higher morale. Also, we've found that providing more consistent measurements, visions, and strategic planning across the organization has resulted from higher data quality and users' ability to work off the same data in the same manner. The BI and data warehousing system enables our users to perform "what if" statements to find out the fiscal impact of, for example, changing one of the line items on a tax return document.

Steve Tracy: All along, our most basic focus has been simply on increasing the speed of information. This has required getting information coming from systems scattered throughout the organization co-located in the data warehouse. We've been able to cut down on turnaround time, with our users now much more confident of being able to answer customer questions or analyze a case quickly.

Today, the focus is evolving toward alignment with business goals, expressed from the top down: basically, from our mission statement on down to departmental goals. This would fall under the guise of "performance management," which I define as basically how you measure how well your business is doing. We're moving from, in some cases, institutionalized, scheduled reports to more interactive analysis that fits with our performance management goals.

Jim Cates: In our world, we have a very structured process that's actually driven by business processes. I'm also the Corporate Process Officer. We have a Corporate Effectiveness and Efficiency Team (CEET), which meets to lay out key processes on a roadmap, and then we drive our BI initiatives around that. We have all the basics that everyone mentions: an extract, transform and load (ETL) tool, a couple of OLAP tools, a data warehouse, and even business activity monitoring (BAM) tools. All of this is driven by what I would call "cycle time to information by business role."

Departments at our company that have really embraced the processes and know what metrics they want are doing very well. Others that don't have stable processes aren't doing as well. My position is that I really don't want to come in and do a lot of technology investment until a business unit or department has really nailed its processes. We have a methodology to help the departments define processes. So, we spend a lot of nontechnical time with the business units to try to get a process and business rule model in place before we put the technology in. I haven't found the challenge to be the technology; the big challenge is being disciplined with the processes and getting people to think about what they want to do.

IE: Do you think a weakness of BI and data warehousing has been a "build it, and they will come" approach, something that the process orientation you're describing could help solve?

Cates: I think so. This is my fifth company, so I've seen it myself. You put databases, data warehouses, and ERP systems in, without considering that they may not answer the question.

Les Arnold: We can definitely relate to that at the State of Iowa. When we came in, one of the first things we did was to start off with a business discovery process, rather than talk about the IT or BI architecture. We addressed only the key success factors from a business side. We focused on business rules, objectives, and questions right up front. We didn't worry about the technology that we'd implement for the processes. We did business discovery for almost a year in front of the BI technology implementation.

Bob Denis: I would certainly agree with that based on my experience. It's almost like you need the technology to pilot an easy win, to reach the low-hanging fruit for the business folks to realize the potential. Then you get the flurry of questions: "Can you do this? Can you do that?" And then you push it back and say, "Well, hang on a minute. What's your process? What are the key milestones and metrics you need to make decisions and move things to the next phase of the process?"

You need that pilot phase, even though some of the vendors don't encourage that. They want you to either buy or not buy their tool — and then try to get involved with the entire set of projects that you may have. The vendor may succeed in getting IT's backing, but we're really looking at a business initiative. The pilot must sell me on the technology's value to the business, not the value of the tool itself. And then it all comes right back into what we've been talking about in emphasizing business process management and identifying what's key to move decision-making forward at a faster speed.

IE: Does some of the difficulty in moving users to new tools and methods stem from loyalty to their own processes and tools, such as spreadsheets? Can business users conceive of how technology can support business change?

Denis: Interestingly enough, in our company — well, let me characterize what we're doing for 10 seconds. Our company's organizational architecture will soon be made up of several smaller companies in the $50 million to $150 million in revenue range. Each one will be a fully autonomous subsidiary, rather than business areas, product lines, or product families. So, in that context, we'll need to enable some views in common and implement some triggers for all the subsidiaries. Integration is going to be the critical issue. The CFO will still need to talk about the inventory position of the company and its total revenues. How does that information come together, without having to drill down to it all the time? That would be the "static" aspect of our architecture.

The "active" aspect is about the hockey stick: that is, the last two weeks and last two hours of the quarter that I'm sure everyone is familiar with. During the quarter, we need information at a rate of maybe once a day, or even once a week in some cases. But when you get to the last two hours, we actually want to be able to trigger the production line to stop. This is an example of where you want active BI; you want the system to communicate that "I've met my revenues and I don't want to pull anything more for this quarter." And that's got to happen on a dime.

We need some intelligence to come from within the ERP system — and not just database triggers. To operate a real-time enterprise in just that last few weeks of the quarter, we need something beyond the trigger approach. We're talking about something that could spell the difference between your company losing half its stock value or gaining a significant percentage. That's how much one or two orders can cost you if you miss your numbers.

IE: To deal with the communications issues and to unify business and IT support for technology acquisitions and direction, many companies are creating joint steering committees. These include business and IT people within their organizations. Is this an approach that you would favor?

Kirkpatrick: I'm the project manager leading the design and development of the data warehouse and BI tools, the automation of data movement, and use of the warehouse to further automate processes. But as project manager, I'm actually on the business side; I'm a business user. You could probably consider our project team a steering committee for our organization. We've had IT involvement on the team and on planning, but business users really drove the technology deployment and development. Our whole goal has been to get the data, understand the need for it, and deliver it to business users so that we can do better with our administrative processes.

Our alignment has worked out very well. Our team asked: What do we need BI for? What are our business questions? What will our measurements be? And what kind of management reports will we produce with these tools? Business users drove how we answered those questions.

We went back to the data warehouse — and Rich could speak about this — to improve queries and response times. Now, we're supporting the BI tool within the data warehouse by building logical data marts that have already performed queries and can build tables and refresh them in daily increments. We use our enterprise data warehouse (EDW) to get the data and pull it together for quicker BI tool response times.

Richard Puhl: The key here is that the business users must know what they want and be able to communicate this to the technology side, so that we can create those views into the data warehouse and help them get answers faster. Often, what they're asking for, in a real-time environment, just isn't feasible because of the amount of data we must move and the time it would take. However, if they're able to tell us what they need to see, perhaps it doesn't need to be refreshed on a second-by-second basis. Someone might need to see something just once a day: for example, what yesterday's sales were like, how many orders each person was able to process, or the amount of revenue generated that day. Or, we could roll up and store certain numbers in the data warehouse for historical purposes, if that's what the business users need. The more you can address things at a foundational level, the more you can optimize the tools at the top.

Cates: I agree. IT organizations have to make some fundamental decisions. If you happen to work for a startup company it might be a little easier, but most of us work for companies that have legacy systems. IT must decide first if it can build the EDW solution or not: and there, the concept of a common data model is very important. If you can't build it, then you have to have a virtual "enterprise data warehouse" or else you will get back into the stovepipe world, which means that you'll never get any real information.

I've found that very little information really has to be real time. When business units say they want real time, I respond by saying, "ok, let's forget about the time limits of the data. Tell me the business question that we're trying to answer." When we really go through it, except for some aspects of our supply chain, manufacturing, and operational units, very few business units really use this data in real time. Even if we gave it to them, few business units could really use real-time data in a way that would impact business decision-making.

Denis: I think what you're saying is quite true for 80 to 90 percent of the unfortunate quarter system we're stuck with, but as you progress toward a situation — in this case, the close — the real-time requirements do change. And they change not only the way I look at data in my enterprise, but also out into the channel. The tools and common language that we are talking about in this conversation: Well, they must extend into the supply chain for things I may have to pull up, and all the way into my distribution channel to understand what the heck I've got sitting out there that I can push.

IE: As BI moves out to serve a much wider user population, do you see the notion of a "guided" or role-based BI experience gaining traction?

Denis: Well it's an interesting angle. To get a full set of roles might take a while because some enterprises might use some roles but not necessarily the full suite that another enterprise might use. Of course we all have some of the same basic roles, but when you look out globally, even how people in those roles do their jobs and access data can be different.

In some ways, what you're suggesting is a RosettaNet for business and IT to use to communicate. Everyone who's had these kinds of problems has formed committees and tried to come up with a standard language that they can exchange and reform. We're suffering from the lack of such a language right now as we try to move up the intelligence ladder.

Tracy: At Hartford Life, we've had a strong requirement from the business units to adapt to roles for a claims processor, for example. We need to track Processor Activity over time, as their role may change. New roles may be introduced, too. Source systems don't always have a place to capture the role at the business grain — that is, there's a subrole at a team level not in any system, one they wish to perform analysis by.

We've been able to create very flexible XML schemas for roles. We can change them. I don't have to go in and rework a dimensional data model to accommodate one person changing from doing one and only one thing to doing something different. This application is actually owned by the business.

Role-based information is a big boost to customer service and processing. The key point is that you can have fundamental roles, but the system has to remain flexible and capable of keeping up with change.

IE: Where are the bottlenecks right now in BI and DW?

Puhl: At the State of Iowa, I'm finding that the bottlenecks are more on the business side. The key one is finding the time to sit down with businesspeople and work out the questions that they need answered. And then, we need to determine whether what we currently have fits the bill for them or whether we need to go to new sources. The business side has the knowledge, the questions, the background, and the insight for me to then be able to retrieve the information from the data warehouse. So, the biggest bottleneck is just time. I'm not the only one pulling at their strings.

Cates: I agree. In my world, and probably in most of our worlds, we've created this new business role, if you will, called "business systems analyst." Sometimes this role lives in the IT world, sometimes in the business world. I would call it a hybrid role, occupied by someone who understands both IT and business and can create business requirements. And sometimes this works, sometimes it doesn't.

I'm finding that if I have just an hour with some of our business directors and VPs to get agreement on the five to 10 questions, I can further clarify them with the business systems analyst and will have achieved a higher degree of accuracy with what I do later on. But that communication — bringing that business intelligence into the IT world — is the key bottleneck.

Tracy: One thing we need is BI tools with very robust metadata. However, the only way you can accurately represent that metadata is through communication with the business users. The number of business analysts or business systems analysts required to really do this communication right has doubled in the five-year period I've been working with this particular line of business and company.

Denis: Well, suppose we do get to set a full process, a naming convention, and so on in place. If that's written in cement, and you get a new leader at the top of the company who wants to change and reorganize, merge and divest, and all the other stuff which is part of business growth, we're creating our own grave. It can't be that every time we need to unbolt something it causes us a great deal of pain. So, there's a flexibility that we need to keep.

IE: Are Web services and new technology for enterprise information integration going to make it easier to move up to a higher abstraction layer?

Cates: I just talked to a startup the other day. This company is focused on higher-level integration by employing an algorithm that looks at the data — let's say customer data — in all the databases. It looks for probabilities and patterns and can then predict what the common data model should be. This is really an innovative idea. I just have to see if it works; however, it could provide an automated way of helping us build common data models.

Tracy: That would offer a whole level above where we currently are using Web services for BI. The initial effort has been to simply get across platforms with a messaging architecture. We found that you can reuse reports for multiple audiences; you just need to restate what I guess would be called the parameters of the report request. However, that's really tough to do without a lot of coding unless you've got an intermediate messaging layer.

I don't think Web services have nailed the BI data integration issues as well as operational application integration. Operational system wrappers have been a fantastic success. For some reason, there are only a handful of vendors that are doing a good job with BI integration and are making it a useful, cost-saving option.

That said, I still think it's an order of magnitude better when it comes to cost savings, particularly when you look at license savings and reduced server-based product expenses. I've had to work through this somewhat in the dark, responding to various in-my-face requirements to create something for less money. The only way we could do that is to reuse, reuse, and reuse with a messaging layer.

IE: What's high on your lists as you head into 2005, whether it's specific kinds of tools, integration software, or other directions?

Cates: I'm looking at two things: process management and business activity monitoring (BAM). I'm also looking at new data acquisition technology along the lines of what I just mentioned, to help me build common data models out of my disparate data systems for certain key types of data, like customer. I'm interested in how I can change the labor-intensive nature of this task today.

Kirkpatrick: We're measuring the results of compliance initiatives and are looking to use BI tools to evaluate result data and provide analysis so that we can take action, such as through a CRM application. We want to understand where noncompliance exists. Is it geographical? Is it a particular line item on tax returns? We need to understand the reasons for noncompliance so that we can better serve our customers and improve our processes.

Denis: This year, our main driver has been operational excellence. We're completing in phases a move from an old set of MRP products to more of an ERP approach. So, in 2005 our top priority is to complete that transition and add a layer of intelligence on top that will supply five business units with good information. The BI is going to be complex; I want to bring back a set of views for those top five questions. Of course, as our VP of operations recently told me, "I have five questions, but then I'll have a different five questions during the last two weeks of the quarter. I just want you to answer five questions, and then once I know the three actions that I want to take with those answers, I want you to automatically trigger those three actions." So, the challenge is to try to keep things simple and flexible, rather than try to boil the ocean. We're just going to try a little cup of soup around some basic things. However, we're going to focus on active, rather than static intelligence, and focus on operations.

Tracy: A key focus will be along the lines of what Jim mentioned in terms of data integration, or I should say more of a disparate information challenge regarding data collection and how it's represented and stored. We want to keep this level extremely flexible and allow users to look at what they need to see.

We're going to be trying to do a lot more for the business side and customer side for either slightly more or less money. It's about efficiency and reuse of things you've already invested in, which ultimately contributes to the financial health of your company. Whether it's through process management, performance management, BAM, or even just simple scheduling of alert mechanisms, we want to get BI pervasively out into the business, particularly on the service side: that is, the people who deal most directly with our customers.

David Stodder is the editorial director and editor-in-chief of Intelligent Enterprise.

Read more about:

20042004
Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights