If you've got a few tangible, documented business requirements to tackle and you're reasonably sure that a new data mart will do the trick, you may be asking yourself how to strategically integrate the new data mart into your organization. Even though (as usual) the answer depends on the specifics of your situation, you'll probably end up with a data mart that resembles one of two proven types DSS application data mart or departmental data mart and the integration that goes with it. The definitions may help you understand the differences between these two types of marts.
Departmental Data Marts: The definition of a departmental data mart is a decision support database that solely belongs to a particular department or division within your organization. For example, the sales department may wish to create a decision support database containing sales data specifically. These data marts are fairly generic in functionality and serve as repositories of historical data for use by that department's personnel only. The design must be fairly generic as well, not focused on any particular functionality or process.
DSS Application Data Marts: DSS application data marts have a very different focus. They concentrate on a particular decision support process such as risk management, campaign analysis, head count analysis, etc., rather than generic utilization. Because of their universal appeal in the company, they also are seen as an enterprise resource. They can be used by anyone within the organization with a need for its analytical capability.
Each of these types of data marts results from the answers to three basic questions: what does it do, who is it for and who is paying for it?
What does it do? First and foremost, the answer to this question should be that it efficiently solves the tangible, documented business requirement. In addition, if the nature/scope of the requirement is clearly comprehensive, then a DSS application data mart is in order. If the nature/scope is limited, then a departmental data mart is probably better.
Tip 1: For departmental data marts, don't forget to determine whether other departments have the same requirement, i.e., would be interested in sharing the benefits and the costs. This may lead you to change the scope of the mart.
Tip 2: For either data mart type, manage user expectations. Make sure that they understand what the data mart will and won't do. Famous last words: "Our new data mart will answer all our questions."
Who is it for? Although the roster of users who access the data mart is important, this question goes to the politics of the situation and performance-based compensation. The real question is who will ultimately benefit the most from the data mart's success. If the answer is the business analysts and executives of a single department, then the data mart should be departmental. If the answer is the folks at many levels throughout the organization, then make it a DSS application data mart.
Tip 3: Once you've identified whom it's for, invite them to be the project sponsor(s). If you can't sell them on the role, then consider delaying the implementation until you can; because if they won't fight for the project at the start, they may fight against it later.
Who is paying for it? Although budgeting practices differ widely and IT departments often function under their own budgets, you should maximize the association between costs and benefits. If only one department is willing to cover the costs, a departmental data mart is needed. If the budget sponsor(s) have overall or inclusive responsibilities or include many departments, then a DSS application data mart is the right one to build.
Tip 4: If the senior project sponsors don't have budget authority, consider whether the ultimate benefactor is actually higher up in the food chain.
Once you've answered the three questions, you should compare the answers to the inherent features of each type and evaluate which approach is needed. Keep in mind that there are pluses and minuses for each type of mart (see Figure 1). Go into the project knowing the shortfalls of each type.
| |||||||||
Departmental data marts usually satisfy departmental requirements for the departments that pay for them. DSS application data marts usually satisfy requirements for multiple departments or the organization as a whole and are funded within enterprise-level budgets. Neither type of data mart is necessarily better than the other, although each has its own ramifications. Each organization has its own unique cultural, political, technological, budgetary and human resource issues. In practice, you may end up with a combination of both types of marts because you need to tailor your solution to your situation.
Claudia Imhoff, Ph.D., is the president and founder of Intelligent Solutions, a leading consultancy on CRM and business intelligence technologies and strategies. She is a popular speaker and internationally recognized expert and serves as an advisor to many corporations, universities and leading technology companies. She has coauthored five books and more than 50 articles on these topics. Imhoff may be reached at cimhoff@intelsols.com.
Be the first to comment on this post using the section below.