“I’m sorry, I know you need this customer profile report, but it requires adding a new data source. The marketing database design specs were frozen in order to make the system delivery date. If we add this new requirement, the system will be delayed for 2 more months. You want to explain that to the boss?”
How many of us have heard these words?
The majority of companies implementing a new marketing database system will end up doing a major redesign, sometimes called “Phase 2”, within the first 12 months… and they are the lucky ones, many other companies cannot afford the budget or staff time to do a “Phase 2” causing their marketers have to live with the system as-is. In defense of the system implementers, there comes a time when you have to stop building requirements and start building the system if you are to going to meet your target date.
Sometimes the problem is that the development schedule did not include sufficient time to collect end user requirements and reconcile them into a comprehensive set of system requirements. But, most of the time the problem is that the marketing and implementation teams have an insufficient base of experience to draw upon.
In short, they don’t fully understand what type of data is available, how that data would be combined and updated, what new kinds of marketing programs the data would support, how they would go about implementing those new marketing programs and how best to track and evaluate results. In this situation, defining requirements is much more of a process than an event. The more that new capabilities are considered, the more new opportunities are seen… and this never happens all at once.
In implementing marketing databases, there is usually a push by senior management to get the database running A.S.A.P. so that the system can start generating a return on its investment. As a result, many, companies fall victim to the old problem where there is not enough time to do it right the first time, but there is enough time to do it twice. Shifting to a two step strategy where a prototype database is built before the final system can help alleviate many of these issues.
A prototype database is essentially a “throw away” system that is built quickly, supports most of the required database functions, doesn’t have to worry about being efficient and represents a short term (not a long term) investment. A prototype database provides immediate operational benefits while helping to build a base of knowledge to use in defining requirements for the final system. This system can also be used to develop “proof of concept” information to support the decision to fund a marketing database system.
Depending on available data sources, a prototype database can immediately provide information to support strategic planning through demographic profiles, purchase activity profiles, customer value, customer segments, etc. The system can also be used tactically to implement promotions, track promotion history, track promotion results and do backend responder analysis. A prototype database offers many significant advantages.
Fast startup. Since the goal is to get a quick “80% solution”, not to implement a complete, efficient long term production system, the prototype database does not need all of the same operational processes as the final system.
Flexible implementation. Prototype databases use a large number of ad-hoc processes to make them flexible, since efficiency is not a key issue. Therefore, it is much easier to include new sources of data, add new calculated fields, process new list selection instructions, produce new reports, etc.
Hands-on experience with the data. Building the prototype database gives a preview of which data is available from which internal and external sources and how it can be combined. This involves investigating file matching criteria (customer number, telephone number, name and address, etc.), determining how data fields from different sources should be combined or reconciled against each other and understanding how each field is coded and what the codes mean. During this process, each data field is profiled to review data formats, identify data errors and define options for resolving errors.
Experience using a marketing database system.
Besides the production-oriented issues identified above, the end users in the marketing department will start gaining hands-on experience of a different nature. Once the database is built, the marketing staff will start understanding what types of data are available.
They will also gain considerable experience with using the data effectively to run their business. Very often, the new range of possibilities will force a re-thinking of how marketing does its job, ie: the business process. Through a combination of planning and trial & error, new customer segmentations will be created, new list selection criteria will be implemented, new reports will be created and marketing program success will be defined differently.
We have to recall that the speed and flexibility of implementing prototype databases comes at a price. These systems rely on a number of ad-hoc processes, manual intervention and outside services. Prototype databases often are based on batch processing and having an experienced IT staff member write programs for each update step, list selection and requested report. This results in slower than desired turnaround times.
Depending on the type of software used to implement the prototype database, the system may or may not support direct access by end users along with the ability to directly use marketing-oriented software tools. Finally, depending on the ease of gaining access to data sources, the prototype database may not include all of the data that is desired by the marketing staff.