Value Proposition
A value proposition is a promise of value to be delivered and a belief from the customer that value will be experienced. A value proposition can apply to an entire organization, or parts thereof, or customer accounts, or products or services.
Creating a value proposition is a part of business strategy. Kaplan and Norton say "Strategy is based on a differentiated customer value proposition. Satisfying customers is the source of sustainable value creation."
Developing a value proposition is based on a review and analysis of the benefits, costs and value that an organization can deliver to its customers, prospective customers, and other constituent groups within and outside the organization. It is also a positioning of value, where Value = Benefits - Cost (cost includes risk).
The process of data warehouse justification has changed over the years, but some things are still true. Return on investment (ROI) is difficult to measure due to the complex workings of business responsibilities and the shifting-sand nature of the competitive landscape. However, justification in the form of ROI is still requested. Adherence to a few key principles can greatly assist companies attempting to prove the value of their programs. First, a review of how we got here.
Stage 1: Failure (early 1990s). There used to be more of what I will call "data warehouse projects." Data warehouses were seen as standalone projects requiring a multimillion dollar investment. They were often built without a measurable goal in mind. After all, they were strategic. Due to this lack of focus and the way business changed during the lengthy duration of these projects, many failed.
Stage 2: Successful data warehouse projects (mid-to-late 1990s). As key success stories highlighted specific values of some data warehouse projects, other projects began to target the same rewards. This focus bundled the data warehouse ROI with the returns from the business project. Often, this proved the value of data warehousing itself to the enterprise.
Stage 3: The data warehouse program (late 1990s – present). Some companies have gone beyond the one-project mind-set and have begun to leverage the investment in the architecture, tools, processes and people toward a more enterprise orientation. Multiple business projects use the data warehouse, creating "The Data Warehouse Program." The program serves as an information factory for the enterprise.
The threat of nonintegrated independent data marts is ever present. The need to deliver quick and controllable business results must continually be balanced with the longer-term ROI from a scalable, integrated architecture.
Today, this threat is becoming ever more prevalent as numerous valuable CRM and e-commerce applications are making inroads into organizations. While data warehousing is an accepted approach for most terabyte-size decision support data needs, what about for 100GB applications? Has the data warehouse program proven its value to include these as well?
Justification of a data warehouse must begin with a definition of terms. There are three things that may need to be justified:
- A data warehouse program which will store decision support data for several business projects.
- A business project which will use a data warehouse to store decision support data.
- The inclusion of new projects into an existing data warehouse program.
If justifying a business project with ROI, the project can be reduced to its anticipated bottom-line cash flow to the company to generate the data warehouse ROI (which is really a misnomer in this context). The project needs to deliver returns in order to be the catalyst for an efficient data warehouse program. Usual killer applications for the data warehouse include targeted and one-to- one marketing, e-mail marketing, supply chain management, category management, procurement management and sales analysis.
If justifying a data warehouse program beginning or extension, the question to be answered is: Why architect the new business project(s) into the data warehouse program/ architecture instead of using independent data mart(s)? These projects need data and probably a new database if one isn't bundled with the application already, but why interact with the data warehouse? The ROI answer is "softer" than the ROI for a business project. You will find the answer in any or all of these five components:
Operational Systems Extract Overload: Operational systems can easily get maximized and become unable to deliver any more decision support feeds. A data warehouse program asks for efficient, multi-use extracts from an operational system. This component can add the ROI of any business projects that cannot be done due to this restriction to the program ROI.
Enterprise Version of Subject Areas: This sounds like the old "single version of the truth." Well, it is. Enterprise-adjudicated versions of subject areas, built once for multiple uses, create enormous efficiencies of operation. This is the ROI component that will be the highest in most cases and will take the most time to generate. For example, independent views of the customer mean that the profitability analysis application will have a different view of customer than the targeted marketing application. If targeted marketing has already proven to increase sales by $5K per quarter and it reduces marketing expenses by $10K per quarter, it is delivering returns of $15K per quarter. Adding customer profitability to the equation should be able to further target the market. Picking up on the established trend, perhaps it could add another $5K per quarter of bottom-line value. Test marketing could be done to refine this estimate.
Enterprise subject areas also deliver internal efficiencies of operation and the ability to react to market conditions faster due to less internal focus on data gathering and reconciling.
There are as many pockets of this kind of opportunity in an unarchitected environment as there are applications needing decision support subject areas times the number of subject areas they need. Expanding this to the enterprise should yield an impressive value equation for a data warehouse program.
META Group reports that "solid architecture" is a key to success in data warehousing. The key here is architected and not necessarily the enterprise data warehouse architecture. A true federated architecture can deliver this enterprise subject area value for chosen subject areas and not necessarily every subject area in the business.
Data Warehousing Competence: With one data warehouse program as opposed to many, fewer resources with competencies of data warehouse architecture, data modeling, database administration, systems administration, project management, etc., need to be supported in an enterprise.
Data Warehouse Tool Standards: While enterprise data warehouse tool standards are not a requirement for a data warehouse program, they do mobilize the learning curve for tool support and usage. With standards, bulk purchasing power is leveraged and fewer corporate resources need to be dedicated to learning numerous data warehouse tools. Without use of the program approach, an organization may have multiple data warehouse tools delivering similar functionality. There is also a possible ROI implication in the inability to get bulk purchase discounts.
Consolidating Expense Streams for Decision Support Data Storage: The worst case is a company bypassing the organizational overhead to adjudicate a subject area that takes 1TB or more of storage and carries it redundantly. This requires two large boxes rather than one – a potential cost of millions of dollars, as well as the inefficiencies associated with lack of enterprise subject areas.
Support data warehousing in your organization by determining what needs to be justified, ensuring that it leads to a data warehouse program and supporting the program by generating enough value to pass the ROI test. Your internal customers will appreciate the ability to leverage operational systems data due to efficient extracts, and the fact that multiple departments have agreed to the data that the architecture contains – and the savings (in the head counts, tools and expenses) generated by the program.
It includes the following topics -