Businesses that start building, purchasing or customizing business intelligence applications without thoroughly understanding the range of users who will utilize the data are making a critical mistake in their business intelligence strategy that will quickly come to light through poor adoption, experts and practitioners say.
Instead, project leaders need to classify users and define their needs at the outset, then continue to engage and train them throughout the lifecycle of the application. Most organizations miss this critical step when developing a business intelligence strategy, said Boris Evelson, an analyst at Forrester Research Inc. in Cambridge, Mass. He stresses that buying a business intelligence (BI) application should not even be one of the first 10 steps in creating a business intelligence strategy.
"I can't tell you how many BI RFPs I see every year, and front and center are multiple tech and operational requirements, line after line of them, and there is only one line item for user types," Evelson said.
CIOs need to define business users and acknowledge that individuals, groups and business units cannot be lumped into one line item called "user requirements." "A front-line information worker, a strategic decision maker that needs large data sets and complex charts, and an operations decision maker that looks across a lot of different aspects of the business … those data models can't live together. You need different BI tool sets for different sets of users," he said.
Once a tool is chosen, a common mistake is asking sets of users to write down or verbally describe the types of data they want to see and the reports they need from the business intelligence application. The prob...
To continue reading for free, register below or login
To read more you must become a member of SearchCIO-Midmarket.com
lem with text is that it often doesn't give the development team a specific direction or format, such that users later say, "That's not what I meant or wanted," when they see the idea in graph or report format, said Rob Fosnaugh, BI lead at Brotherhood Mutual Insurance Co. in Fort Wayne, Ind.
Instead, whenever users want new features or reports, the BI team needs to push them to formulate their needs in the format of the BI tool.
At Brotherhood Mutual, it took two months of back and forth over this before a new claims department dashboard was put into production. In the first meeting, the needs of the group were discussed and each member -- the vice president of operations and three managers in charge of workers compensation, properties and claims -- was given an assignment for the next meeting: graph their needs on a single sheet of paper, no text allowed.
"You need to get users to start thinking in terms of graph formats because a bunch of text, or verbal exchanges, will not jibe with the [overall dashboard ] development process and drawing everything out forces them to clarify their needs," Fosnaugh said. For example, the vice president of operations drew three main graphs in boxes representing dashboards at the top of the page. Each drilled down into specific production areas he wanted to see reports on, including parameters such as trend lines.
These meetings often help identify power users as well. They are the ones who will push usage in their group, act as a liaison to the application development team and train other users, lessening the burden on IT, he said.
As part of Fosnaugh's BI training process, the BI team has an open-door policy every Tuesday, when anyone from the company of 250 employees can carry over a laptop and learn how to develop a report or dashboard based on an idea. The power users are often involved in these sessions as well. And the constant brainstorming between IT and group power users often leads to useful report formats that weren't even thought of before.
For example, when the company went to develop a customer service dashboard, it became apparent that it did not have enough data to track the representatives' performance. After looking at a year's worth of call times for problem resolution, the team realized there were no identifiable trends, so it set up a training day between managers and representatives. The reps' performance that day was used to start a trend line moving forward.
"The trend line showed where performance dipped and rose so a manager could step in and train a call center worker on particular claims transactions, since the trend line drilled down to specific transactions," he said.
How user feedback on business intelligence applications adds value
User input also helps change and evolve a BI strategy as user needs change. Input from the business side is also a handy training tool for IT. At Carmel, Ind.-based Dealer Services Corp., a finance provider to car dealerships, all employees see the same company performance information because, as CIO Chris Brady said, if you keep information bottled up in silos, employees will not be efficient or as effective when helping customers -- and isn't that a big promise of BI, to get more sales and improve customer relations?
Brady also continuously asks for BI feedback from all 450 employees in 60 branches, just as she did when developing the company's BI strategy and evaluating new tools. The BI efforts so far include a metrics dashboard that tracks accounts receivable and overdue loans and a cohesive report generation dashboard, viewed through a Google-like interface.
"I receive emails from all ranks and files --directly from the users -- because I want to hear their pains directly and not from a manager who might filter a suggestion or not pass along a question because they think it's stupid," Brady said. She then shares the email feedback with her IT team, in particular the application development team, which also holds weekly meetings with department heads.
Let us know what you think about the story; email: Christina Torode, Senior News Writer
