The cost of technology...

My previous post on the cost of transpromo is very similar to a discussion I had in past years with regard to the cost of VDP (early 2000's).  The cost structure is very similar though there was less emphasis on security (this was pre-HIPPA and pre-cyber-crime). 

At the time I was selling a plug-in for Adobe Acrobat that did markup and merging.  We had a business plan and a staff who were all about the millions of dollars that could be made in "VDP".  While I had developed this software and and good confidence in it I was starting to believe that even if you had the best software in the world for "VDP work" you still had a problem.

The problem was you needed someone who understood both data and design in order to use it effectively.  Sure you could teach just about any programmer or graphic artist to create a mail merge - but there were other, effectively free tools (like Word) that could do that just as well.  Programmers for the most part never understood the basic graphic design concepts of layout, form, color, and so forth so they used a VDP application like a club: the on-screen blue was good enough. 

The issues with graphic artists were more interesting: While they always got the design part right they had a hell of a time with the "logic" and "database" aspects.  I would have to say that, in general, they really did not understand the concept of "logic" fully.  What I mean by this is not that they couldn't make a logical decision, but rather they did not know how to use logic as a tool.

For example, there might arise a situation where the VDP application had to make decisions about coupon inclusion.  Say the database had two fields: A and B.  You would get something like this from your customer:

    Coupon                        A              B
    ------------                      ----            ----
    X                                   T              1
    X                                   T              3
    Y                                   S              1
    Y                                   S              2
    Z                                   X              4

Meaning that when A=T and B=1 use coupon X, and so on.

What was very hard for graphic artists in general to understand was that cases like A=T and B=2 were invalid.  Now, having spent decades doing this what you learn is that when presented with a table like the one above you validate the database first to ensure that the cases you are provided actually match the data - which is almost never the case. 

The reason is that the programmers have been asked by a marketing person to "find" potential customers with specific characteristics - let's say that A selects a banking product and B selects some characteristic about the frequency of use of that product.  This means that there are probably other potential values outside of those provided in the database, i.e., you are given a "dump" of the current state of affairs in the larger corporate database which itself may be inconsistent or have larger, more complicated relationships between A and B than those provided.

Now for programmers this sort of situation arises all the time in databases and there are many well-defined ways to deal with it.  For a graphic artist the concept that data is inconsistent is much more difficult.

So the problem becomes that you are asking someone who can do one task, e.g., program or design, to perform two.  Now this dichotomy is very pervasive in the "real world".  Programing is an independent job category from graphic artistry. 

Most companies (who have both) have both as separate job titles.  Graphic artists are in one department and programmers in another.

When you ask people or, more importantly companies, to bridge this gap you start to run in problems - significant problems that require skill to address - and, more importantly, problems that are very, very costly if not properly addressed.

So, for example, a hidden cost of VDP and transpromo is the cost of having someone, say an experienced graphic artist, get involved in a project that pushes the necessary database experience beyond what he or she is able to address.  (This is an example of the Peter Principle and it happens when someone in this context says "wow, so-and-so is really good at this VDP stuff, let's go find more wonderful and complex work for them to do because we'll make even more money!")

Unfortunately there isn't a siren and big red light that flashes when someone crosses the boundary from able to do to not able to do.