The initial step of having business users and I.T. people at the same table writing down business objectives for a data warehouse project is crucial, says Norwalk, Connecticut-based data warehouse consultant Richard Creeth, president of Creeth, Richman & Associates [http://www.creethrichman.com]. Since “the user knows the business issue, but the I.T. person knows what’s technically feasible, I.T. may therefore may be able to refine the business problem.”
Often the process serves to enlighten business users as to what is technically feasible, Creeth says. “I call it ‘The Horizon Syndrome.’ If the user’s not technologically savvy, he may not be aware that he can get more than he thinks. Once he gets to the next horizon he can see it, but by then it may be too late.”
This puts the I.T. professional squarely in the business flow. “The challenge for I.T. is to help the user see the horizon. Identify a phase one deliverable you can get quickly, and once you give users something, they will have a clearer idea of how much more is possible.”
For example, Creeth said, most business users are not aware of the capability of software agents that can alert business users to unusual developments in the data: “If production in one area falls ten percent unexpectedly, the system sends out an e-mail.”
Also, Creeth finds, “most business users don’t know what data mining can do for them. Take customer retention. You can identify, using data mining, that segment of customers most likely to cause churn, and concentrate marketing to maximize retention and reduce churn. Anyone with a large individual customer base can use this — credit card companies, telephone companies, banks.” He said one major credit card company, as a service to its banks, can identify people as much as twelve months before they go into bankruptcy.
“There’s so much technology business users are completely unaware of. I.T. needs to draw out business objectives so they can identify other needs that may be met through ways the user’s not even aware of. This balances keeping the user’s expectations in check,” he comments.
One of the biggest mistakes businesses make when starting a data warehouse project is “treating it as a tech issue,” Creeth says. “They give undue importance to technical architecture, and don’t look at the business problems it’s supposed to solve.”
Start with determining objectives for application, Creeth advises. “Only then can you decide what data needs to be included, what analytical tools should be considered, and whether you’re to build you own, or buy off the shelf.” And when sitting down to determine what those application objectives are, “I like to see a project team with heavy user community representation. Without that you risk not meeting users’ needs.”
The first step, “and it sounds stupid to say it, but many forget,” Creeth says, “is to simply write down what the objective is. What is the business need it will service? Should it allow product managers to analyze sales by product, by salesperson, by region?” This is important, he says, since “the issue then becomes how much data goes in. Left to I.T. all data would go in, and that would doom the project to failure. Define the business application, identify the data required to provide the analysis, and identify the tools you can use to provide that data to users.”
Richard Creeth is a featured speaker at DCI’s Data Warehouse World.
