Closure...

Its very interesting to me to look at how industry treats disparate disciplines in non-print/VDP/transpromo.

For many years I worked with two major local clients - a large regional bank and a large regional health insurer.  Contrasting how they handled the "prep work" for VDP type applications is revealing.

The two basic types of non-trivial VDP work we did for health care was the "provider directory".  In the olden days information about what providers (doctors, pharmacists, etc.) where in a given health plan were printed in books that you received when enrolling.  There were fairly complex format- and layout-wise but still where basically a couple of data tables that required a join in order to create the book.

The second type for the bank was "account transition" mailing which occurred when the regional bank acquired a smaller bank (this was sent out at the end of the acquisition once the rest of the "stuff" related to the merge was completed).  Basically this was a set of mailings and letters that outlined your general account information at your current bank and a table that showed your old account and new account information in the merged regional bank.

The basic process for each of these applications involved the follow general steps:

1. Construction of a design "mock up" for data-driven elements.
2. Determination of the surrounding non-data driven elements.
3. Acquisition of "test" data for testing #1.
4. Design refinement, proofing, sign-offs and approvals.
5. Receipt of the "live" data.
6. Production of the pieces.
7. Validation generated results.
8. Post production finishing and delivery.

The principle difference we are interested in here between the bank and the insurer were in the "IT" departments - specifically in how they worked, what they did, and how they did it.

The insurer was ostensibly the more "modern" of the two in that they claimed to have an "SQL database" that contained the information they wished to process.  We were never really able to get close to this database (see queries, understand the underlying structure in detail, etc.) but it was clear from our interactions that the database was in charge of the people.  There were always mysterious problems and glitches that impacted the process, i.e., changes between a "test" and "live" dump for a run, additional data always arrived "late" for the job, that sort of thing.

Jobs where always initiated by non-technical marketing people who did not have a good grasp of the the database process.  They knew what they were expecting to get from the database but really didn't understand much more than that.  You could easily tell this by the answers you got to questions regarding the data.

Insurer - "Here's the floppy for provider directory ##.  It will be broken down by A, B, C, D..."

Us - "There is no code for B, E, F, G"

Insurer - "There must be ..."  (back and forth)

Insurer - "Here's a new disk."

Us - "Okay - A, B, C, ... are all hear but providers X, Y, Z... appear in multiple categories - is this correct?"

Insurer - "Uhmmm... we'll check." ...  "Can you tell us what categories X is in?"

Us - "A & C"  (more back and forth)

Insurer - "Well do this and that to the data and let us know what categories X ends up in"

...

Insurer - "We reviewed the produced books (cost $35K) and realized there were problems that were not your fault.  They need to be destroyed.

The bank had a bunker-based IT fortress staffed with programmers with whom we could speak.  Data typically arrived on 9-track tape or floppy along with dumps.  The marketing people who ran the projects understood what was in the data and could tell when there were structural problems.  They were often able to translate between issues we had and the programmers. 

These conversations where along the following lines:

Bank - "you'll be receiving a tape of approx. n customers for conversion - ## for mailing type 1, ## for mailing type 2, ..."

Us - "we did queries and everything matched but we came up with ### instead of ## for mailing 3."

Bank - "did you include marketing code XYZZY?"

Us - "no - you didn't tell us to"

Bank - "check that"

Us - "Okay - but there are still 139 records which don't match any mailing"

Bank- "I'll check with the programmers and get back to you... Put those people into mailing 1".

...

This bank is now a national bank with an excellent track record of acquisitions.

If it not obvious what the differences are between these two then you should probably stop reading.

If there is no control over the data before you get it you have to be better than the provider at scrubbing and checking the data or their problems will become your problems.

So if you're a graphic artist its very hard to do this without extensive database training.