Re: Sales Automation Systems: Should you buy or build? Free Research Summary Paper

This is a multi-part message in MIME format. ---------------------------------4802177039952 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I thought this might of interest to the" buy or build" question. Our business is the design and contruction of "Marketing Databses". I hope you find this informative. John Tersigni MSSI ---------------------------------4802177039952 Content-Transfer-Encoding: 7bit Content-Type: text/plain 1995 Mercantile Software Systems, Inc. All rights reserved. This work may not be translated or copied in whole or in part without the express written permission of Mercantile Software Systems, Inc., except for brief excerpts in connection with reviews or scholarly analysis. Use in conjuction with any form of information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology known or hereafter developed is forbidden. IRE and Campaign! are trademarks of Mercantile Software Systems, Inc. UNIX is a registered trademark of AT&T. All other products or services mentioned in this document are identified by the trademarks of their respective companies. The use of general descriptive names, marks, etc., is not to be taken as a sign that such names may be thus freely used by anyone (per the Trademarks and Merchandise Act). Turn Data Into Profit The Decision Support System (DSS) marketplace is in a tremendous growth stage today because of the availability of affordable, UNIX based servers to house data. Businesses are in a highly competitive global marketplace; in order to compete effectively, they must be able to analyze business data and turn it to their competitive advantage FAST. Marketing windows are shrinking, so speed is of the essence. This is even more apparent in the direct marketing and retail environments. Mass marketing is expensive and returns less on investment than smarter, more focused segments. A top national ad agency recently made the statement that we are returning to the era of one to one (1:1) marketing, i.e., focus on the individual customer's needs and buying patterns. Therefore, Decision Support Systems should include not only demographic data (e.g., where do they live, what do they do, etc.), but also psychographic information, i.e., customer profiling that can be extrapolated to prospects. This need has led companies to build Marketing Warehouse (MW) databases. In the past, historic data was often ignored. The cost of keeping such information was prohibitive. But, with the explosion of less expensive hardware and the adoption of open systems, marketing organizations can now afford to retain the types of information required for a Decision Support System. In fact, it has become just about mandatory for today's businesses. How are people going about it By combining open systems UNIX platforms and inexpensive disk storage with off the shelf software tools such as: Relational Database Management Systems (RDBMS) Desktop Access Reporting Analytic Tools Statistics Charts & Numbers Graphic Presentation. How are people using this solution Decision Support Systems are heuristic in nature, that is, they stimulate investigation or research. One query raises questions to stimulate another, etc. In an operational database, such as a financial accounts receivable or order entry system, daily operational; reporting needs are fairly static. Management and users are more concerned with the format of the data rather than what-if type analyses. In the typical DSS, formatting is a subordinate issue. Instead, there is a need to discover the meaning of the data, to explore the database. This manifests itself in the requirement to drill down to regions of interest and then switch to spotting trends. For example: How many customers in the database have characteristic A Based on that answer set, how are they spread geographically? The first question is exploratory; the second question is analytic. Are there any tools available that can perform this paradigm shift To do so in SQL is a nightmare. And, even if there are off the shelf software packages capable of handling this shifting, the amount of time required is large, especially as the database grows. In SQL the two example queries are done disjointly. They are two entirely separate queries that are not leveraged, i.e., the second query does not search the answer subset from the first query, but rather re-executes against the entire database. This contributes to the basic sluggishness of decision support technology, and has often led to the failure of companies to implement large Decision Support Systems. When in discovery mode in a DSS database, response speed is critical to continuing the user's train of thought. The success of a heuristic DSS depends on the continuity of thought of the user during the drill down process. If the system is too slow, people will give up and begin to make assumptions and extrapolations based on incomplete evidence and data analysis. This tends to increase the odds of making poor decisions. There are several main factors that contribute to this problem: Large quantities of data in the database, causing enormous I/O demands to satisfy the query. These databases usually have several tables with millions of rows. EXAMPLE A direct marketer has as many as 10 million customers in a database. The database has 100 million items purchased by those customers. DSS queries slow down on difficult table joins, such as: How many customers bought Product XYZ from us? There could be millions of rows from a join between the customer and purchases tables. RDBMS databases must perform large amounts of I/O just to answer just such a simple appearing query. However, it does not stop there. Because it is heuristic, a DSS could trigger other queries in the user's mind. And, if we have asked only how many, we have not created an answer set, yet. If we next ask, Out of those customers who bought Product XYZ, how many live in New Jersey or Pennsylvania? then the new query causes a re-execution of the first database search. Another problem query for the RDBMS database is one that involves low cardinality fields (i.e., fields with a low number of possible values, such as "gender"), for example: How many customers are women? Even such a simple query with low cardinality constraints can send the RDBMS software into a tailspin. The reason is that off the shelf RDBMS packages have a one-size-fits-all strategy for indexing the balanced tree (B-tree) index. B-trees are good for on-line transaction processing (OLTP) applications; they work well when finding a small number of rows in response to a query. But, they do not work well for Decision Support/Marketing Warehouse type systems. A DSS requires answers for groups of objects, not just answers about a few objects. B-trees are an excellent choice for high cardinality fields (columns), e.g., social security number. However, the standard, out of the box RDBMS with B-tree only indexing is not enough to implement high performance marke