I've spent a lot of time talking about business and the "industry". I think there is more to life that just that and I want to relate some things about that - particularly on the "people" end.
I have a friend who I've consistently and regularly played music with for many years.
This guy makes his living playing out and has raised a couple of kids doing it - all without outside help, i.e., no food stamps, no state aid, nothing. Now, he's not Elton John or anything like that, and he plays primarily in working mans bars on weekends - so you can imagine that he is, as they say, "really good and barely getting by".
For part of that same time I've had my business and many employees - since about 1994 I figure I've had probably at least a 125 unique employees. These folks have ranged from minimum wage mailroom workers to 100K a year CEOs, consultants and marketing people. Similarly I have worked with a lot of customers and vendors over the years - everything from part time bookkeepers to Fortune 500 companies.
On thing I have seen is that, barring drug and related problems, the "working man" is a whole lot more honest and reliable than many of the expensive, high-end folks. Now don't get me wrong - I've had my share of problems with low-wage employees - but, all things being equal, even problem low wage employees are less of a problem than expensive ones. (And not to say all high payed folks cause problems either.)
On the high end I've had issues as well. When someone makes a lot of money these days there seems to be a strong sense of "entitlement" that goes with it - particularly when things go bad, i.e., in a recession. I've only gotten into real trouble trying to help out people out, i.e., when the economy goes bad by trying to keep them employed.
I think the most telling is to watch someone's company email (while you are paying their salary) and to see the only activity on it the emailing to you, the boss, telling you how busy they are.
This brings me back to my friend. He and I struck up a working relationship early on. In the last five years there an never been any kind of issue - money or otherwise. Now this guy is effectively the CEO of his own little operation and he's a damn good one.
His model is simple: agree on a price, do the work and get paid. Nothing more and nothing less. There is never an expectation of getting paid for not doing what is promised and what is promised is always what gets done.
In business I have always found this model to be best.
So what's the difference between the high end employee taking you for a ride and a guy like my friend? The answer is one word - character.
My friend knows when he is not doing his job and, when he isn't, doesn't expect to get paid for it. At the same time, based on his level of income, he is not "over committed" to a lifestyle that he cannot afford.
Thursday, September 30, 2010
Wednesday, September 29, 2010
Sit down...
I had a chance to sit down with some local print people involved in various industry groups.
Much of the discussion turned to what I will call the "future of print". This all got me thinking about what sort of "outside" pressure there is impacting print today. By this I don't mean internet, USPS price increases and web but more general cost forces, "winds of change", etc.
I came across this article at WhatTheyThink. The first sentence says "Excellus BlueCross BlueShield (Excellus BCBS) earned a first place award for its dimensional ink, full-color calendar produced on the KODAK NEXPRESS 2500 Digital Production Color Press."
Now this is pretty standard fare for this web site and its nice to see this kind of thing. But my fear is that the newly passed health care laws are going to severely impact a big use of print in health care.
For a long time, as covered in other posts, I owned a mailing company and one of my clients was a very large BCBS (Blue Cross and Blue Shield). As customers went this was a fairly good one for a couple of reasons: they printed a lot of small run materials, they had money, and they had a specific brand which they took care of.
Though they had money they were reasonably cost conscious. One of the things we did a lot of in the mid-90's was specific documentation packages for potential clients: welcome kits, here's what to do for your renewal, that sort of thing. Basically most of this was a form letter addressed to "Dear XYZ Employee:" and a bunch of warehoused materials. At the time the cost to laser print lots of "Dear Employee" letters was prohibitive so we came up with a RisoGraph to do the job. This was a thing kind of like the old mimeograph in that it etched a stencil but it was digital. You sent it a job as a PostScript - it RIPed the file, etched the stencil, and then ran 100's or 1,000's of copies very cheaply.
Of course, all this was 15 years ago now and much has changed. But my guess is that there is still a decent amount of print, mailing and such still going on in this industry (I see one of my old partners still crowing about these sorts of customers). I think that because these companies where extremely well funded (for example, some have been sued for "sitting" on billions of dollars of reserve in excess of legal requirements) they spent a lot on the types of programs I referenced above. Basically this is a market where an employer is paying an average (or minimum) of $12K a year per employee so a certain amount of cost to keep these "customers" on is expected.
With the new insurance mandates (extending coverage, limiting cost increases, etc.) these "cushions of cash" are going to quickly dwindle and one of the first victims of cost cutting will be unnecessary programs related to print. The first to go will be the nice stationary, envelopes, news letters, and such followed by anything else being printed.
On the other hand, I am sure only the silly HIPPA rules and the corresponding ridiculous paperwork that don't allow your Cobra employees to talk to their provider about their billing status will create a printing need... but that's another story.
Much of the discussion turned to what I will call the "future of print". This all got me thinking about what sort of "outside" pressure there is impacting print today. By this I don't mean internet, USPS price increases and web but more general cost forces, "winds of change", etc.
I came across this article at WhatTheyThink. The first sentence says "Excellus BlueCross BlueShield (Excellus BCBS) earned a first place award for its dimensional ink, full-color calendar produced on the KODAK NEXPRESS 2500 Digital Production Color Press."
Now this is pretty standard fare for this web site and its nice to see this kind of thing. But my fear is that the newly passed health care laws are going to severely impact a big use of print in health care.
For a long time, as covered in other posts, I owned a mailing company and one of my clients was a very large BCBS (Blue Cross and Blue Shield). As customers went this was a fairly good one for a couple of reasons: they printed a lot of small run materials, they had money, and they had a specific brand which they took care of.
Though they had money they were reasonably cost conscious. One of the things we did a lot of in the mid-90's was specific documentation packages for potential clients: welcome kits, here's what to do for your renewal, that sort of thing. Basically most of this was a form letter addressed to "Dear XYZ Employee:" and a bunch of warehoused materials. At the time the cost to laser print lots of "Dear Employee" letters was prohibitive so we came up with a RisoGraph to do the job. This was a thing kind of like the old mimeograph in that it etched a stencil but it was digital. You sent it a job as a PostScript - it RIPed the file, etched the stencil, and then ran 100's or 1,000's of copies very cheaply.
Of course, all this was 15 years ago now and much has changed. But my guess is that there is still a decent amount of print, mailing and such still going on in this industry (I see one of my old partners still crowing about these sorts of customers). I think that because these companies where extremely well funded (for example, some have been sued for "sitting" on billions of dollars of reserve in excess of legal requirements) they spent a lot on the types of programs I referenced above. Basically this is a market where an employer is paying an average (or minimum) of $12K a year per employee so a certain amount of cost to keep these "customers" on is expected.
With the new insurance mandates (extending coverage, limiting cost increases, etc.) these "cushions of cash" are going to quickly dwindle and one of the first victims of cost cutting will be unnecessary programs related to print. The first to go will be the nice stationary, envelopes, news letters, and such followed by anything else being printed.
On the other hand, I am sure only the silly HIPPA rules and the corresponding ridiculous paperwork that don't allow your Cobra employees to talk to their provider about their billing status will create a printing need... but that's another story.
Tuesday, September 28, 2010
In case you thought...
Your small printing business was safe check out this article.
While it ostensibly has something to do with cloud printing (see previous posts) the real focus is on (further) destroying the existing local printer model. With this type of technology in place and fine tuned there is little that cannot be done this way in terms of printing.
As I have said before I am in the business of printing and I don't own an output device. This will not change and as more and more people get into this market the less need there will be.
The "cloud" moniker doesn't add anything to this... its the same web-based print service that's been talked about and done on a small scale for probably a decade. The big difference here is that you now have someone like HP putting their muscle behind it.
(Interestingly HP is selling you an Indigo and then competing with you. Though this is a very old idea now it keeps popping up every few years under different guises. I suppose the real deal will be to simply license a web-connected device in your franchise area - like a Taco Bell or Subway - and then collect money whenever something comes off. I mean HP would like you to buy the device but why bother? In the long run HP is taking your business away for this...)
HubCast is just like any other demand print deal, e.g., a SnapFish. I suppose the only real difference is that its "world wide" which in this context seems to mean next day delivery anywhere in the world.
On the other hand, why even bother with this for marketing materials when you've got the web. The little discussion they have in the article talks about some semiconductor business using this instead of warehoused market literature. Where has this guy been - warehoused marketing literature is long gone - especially in something as fast-changing as semiconductor marketing.
For years I have heard about "digital paper" coming to take over the world - supposedly something like a newspaper but digital. On the other hand flexible color LCD displays are here. (You may or may not be able to follow this link to a WSJ article on flexible LCD displays).
Given all of this why on earth is this semiconductor guy bothering to print his marketing materials?
While it ostensibly has something to do with cloud printing (see previous posts) the real focus is on (further) destroying the existing local printer model. With this type of technology in place and fine tuned there is little that cannot be done this way in terms of printing.
As I have said before I am in the business of printing and I don't own an output device. This will not change and as more and more people get into this market the less need there will be.
The "cloud" moniker doesn't add anything to this... its the same web-based print service that's been talked about and done on a small scale for probably a decade. The big difference here is that you now have someone like HP putting their muscle behind it.
(Interestingly HP is selling you an Indigo and then competing with you. Though this is a very old idea now it keeps popping up every few years under different guises. I suppose the real deal will be to simply license a web-connected device in your franchise area - like a Taco Bell or Subway - and then collect money whenever something comes off. I mean HP would like you to buy the device but why bother? In the long run HP is taking your business away for this...)
HubCast is just like any other demand print deal, e.g., a SnapFish. I suppose the only real difference is that its "world wide" which in this context seems to mean next day delivery anywhere in the world.
On the other hand, why even bother with this for marketing materials when you've got the web. The little discussion they have in the article talks about some semiconductor business using this instead of warehoused market literature. Where has this guy been - warehoused marketing literature is long gone - especially in something as fast-changing as semiconductor marketing.
For years I have heard about "digital paper" coming to take over the world - supposedly something like a newspaper but digital. On the other hand flexible color LCD displays are here. (You may or may not be able to follow this link to a WSJ article on flexible LCD displays).
Given all of this why on earth is this semiconductor guy bothering to print his marketing materials?
Monday, September 27, 2010
Remote viewing...
I have been sitting on my porch debugging a software problem in Asia.
This is always an interesting experience due to language, time and cultural issues.
We have a large, complex system running as part of a cell phone billing application. It takes about 100K small PDF cell phone bills and combines them into a single PDF file in about 8 minutes.
Every nine months or so something goes wrong and I get an email.
Now there are two ways to look at the issues here. There is the micro view and the macro view.
At the micro level there are specific things in log files indicating problems of one form or another. These PDF files arrive on a network directory and wait until a JDML file arrives that tells the system how to put them together. So I can review the log files and detect errors. Some program runs and exists with a bad status, fails to load a file, that sort of thing.
While I am doing this I am also receiving interesting "out of band" data about the macro state of the system. This particular system has a client/server architecture. Both client and server have a UI that aggregates log data down to SUCCESS/FAIL. As part of this system the clients and server keeps track of who is connected as a client and so forth.
So I find out that, in addition to the bad PDF results, there are other types of errors on the system. Specifically I/O errors and client/server errors. At this point it is very hard to tell what stream of information is really telling me about the problems.
When I hear that programs that normally work are reporting I/O errors I become concerned that there are system level issues causing problems: disk errors, bad sectors, network drive issues, etc. To me these are usually better harbingers of issues that specific file issues. All of these tens of millions of PDFs are created the same way by an application that doesn't change (though that's been an issue as well). So I struggle with what to tell the customer.
Usually I have to carefully tease issues out of them - both because of language and technology. In this particular case my customer is very good at getting me reliable information about his customer (who is the ultimate user of the software) so its reasonably easy.
At the same time I have no direct control over the environment or testing. An employee installed the system 18 months ago and we have not been on site since. It runs on a Windows machine in a foreign language that we cannot read.
So basically I have to read the "body language" (macro information) as carefully as the underlying micro issues to solve the problem. In this case the software seems to work here but specific files fail on-site. Today, however, IO error reports began to arrive so I am now more suspicious that something in the environment has changed.
Particularly worrisome is that the main server is reporting additional client connections. Since this reporting can only happen if a client app attempts to make a TCP/IP connection to the server its unlikely this is happening on its own. More than likely someone is doing this - so if they are doing this what else might they be doing?
This is always an interesting experience due to language, time and cultural issues.
We have a large, complex system running as part of a cell phone billing application. It takes about 100K small PDF cell phone bills and combines them into a single PDF file in about 8 minutes.
Every nine months or so something goes wrong and I get an email.
Now there are two ways to look at the issues here. There is the micro view and the macro view.
At the micro level there are specific things in log files indicating problems of one form or another. These PDF files arrive on a network directory and wait until a JDML file arrives that tells the system how to put them together. So I can review the log files and detect errors. Some program runs and exists with a bad status, fails to load a file, that sort of thing.
While I am doing this I am also receiving interesting "out of band" data about the macro state of the system. This particular system has a client/server architecture. Both client and server have a UI that aggregates log data down to SUCCESS/FAIL. As part of this system the clients and server keeps track of who is connected as a client and so forth.
So I find out that, in addition to the bad PDF results, there are other types of errors on the system. Specifically I/O errors and client/server errors. At this point it is very hard to tell what stream of information is really telling me about the problems.
When I hear that programs that normally work are reporting I/O errors I become concerned that there are system level issues causing problems: disk errors, bad sectors, network drive issues, etc. To me these are usually better harbingers of issues that specific file issues. All of these tens of millions of PDFs are created the same way by an application that doesn't change (though that's been an issue as well). So I struggle with what to tell the customer.
Usually I have to carefully tease issues out of them - both because of language and technology. In this particular case my customer is very good at getting me reliable information about his customer (who is the ultimate user of the software) so its reasonably easy.
At the same time I have no direct control over the environment or testing. An employee installed the system 18 months ago and we have not been on site since. It runs on a Windows machine in a foreign language that we cannot read.
So basically I have to read the "body language" (macro information) as carefully as the underlying micro issues to solve the problem. In this case the software seems to work here but specific files fail on-site. Today, however, IO error reports began to arrive so I am now more suspicious that something in the environment has changed.
Particularly worrisome is that the main server is reporting additional client connections. Since this reporting can only happen if a client app attempts to make a TCP/IP connection to the server its unlikely this is happening on its own. More than likely someone is doing this - so if they are doing this what else might they be doing?
Sunday, September 26, 2010
Friday, September 24, 2010
Back to Artistry...
So my point after all the training talks is that IT skills, just like graphic arts skills, involve a certain amount of artistry. There is an artistry to mathematical logic (which is the basis for database queries and programming) just as there is to visual arts.
The lack of understanding in this regard by the print service industry is to me very interesting. No one ever says, "Wow, you were really clever with your queries to get that list of recipients cleaned up that way!"
On the other hand, I don't know of any IT-type who, when presented with a clever or stylish ad layout didn't take notice or at least didn't show some respect for the designer.
So what is the cause of this "lack of respect" for the artistry of IT?
We can start by looking here. There is a clever optical illusion and a sort of list of "left" and "right" brain "characteristics" shared by people with think with the left or right side of their brains. Now this is old ground but I think it gives you an interesting picture.
On the "right brain" side we see, among other things, "use of feeling", "imagination", "symbols and images", and "spatial perception". I guess these must be the graphic arts types. You'll notice that this list (from the link above) mostly involves visual elements - either externally in terms of images or internally in terms of imagination.
On the "left brain" side we see "logic", "detail oriented", "facts", "math and science", and "order/pattern perception". Traditionally this is the domain of science. Not nearly as much here in the area of visual perception - internal or external.
So I believe that the "right brainers" - the artsy types - really don't get the science and math elements involved in the IT aspects of the VDP/transpromo type work. Its not that they don't want to get it, its that they are not wired to get it. I believe the reason is that the IT-type work is not visual in nature - its much more focused on logic, math, and other non-image-related thinking.
The "left brainers", on the other hand, though perhaps not visual, still can have an appreciation of the visual - after all most everyone uses their eyes everyday - even if they don't use visual things to make a living.
While what I say here may or may not be true, there is a completely different take on the left-brain/right-brain issue here. This splits the thinking not in terms of visual but in terms of gender.
So while the graphic arts industry is dominated principally by "right brainers" its very unlikely that your going to get much appreciation for the IT side of things - no matter how clever.
The lack of understanding in this regard by the print service industry is to me very interesting. No one ever says, "Wow, you were really clever with your queries to get that list of recipients cleaned up that way!"
On the other hand, I don't know of any IT-type who, when presented with a clever or stylish ad layout didn't take notice or at least didn't show some respect for the designer.
So what is the cause of this "lack of respect" for the artistry of IT?
We can start by looking here. There is a clever optical illusion and a sort of list of "left" and "right" brain "characteristics" shared by people with think with the left or right side of their brains. Now this is old ground but I think it gives you an interesting picture.
On the "right brain" side we see, among other things, "use of feeling", "imagination", "symbols and images", and "spatial perception". I guess these must be the graphic arts types. You'll notice that this list (from the link above) mostly involves visual elements - either externally in terms of images or internally in terms of imagination.
On the "left brain" side we see "logic", "detail oriented", "facts", "math and science", and "order/pattern perception". Traditionally this is the domain of science. Not nearly as much here in the area of visual perception - internal or external.
So I believe that the "right brainers" - the artsy types - really don't get the science and math elements involved in the IT aspects of the VDP/transpromo type work. Its not that they don't want to get it, its that they are not wired to get it. I believe the reason is that the IT-type work is not visual in nature - its much more focused on logic, math, and other non-image-related thinking.
The "left brainers", on the other hand, though perhaps not visual, still can have an appreciation of the visual - after all most everyone uses their eyes everyday - even if they don't use visual things to make a living.
While what I say here may or may not be true, there is a completely different take on the left-brain/right-brain issue here. This splits the thinking not in terms of visual but in terms of gender.
So while the graphic arts industry is dominated principally by "right brainers" its very unlikely that your going to get much appreciation for the IT side of things - no matter how clever.
Thursday, September 23, 2010
IT Training, Bears and Wolves...
IT Training...
As I mentioned last I have never seen specific IT training for the print/VDP/transpromo industry.
Virtually everyone I know with an IT background in these industries currently came there through some round-about way, i.e., did not specifically say "this is what I want to do".
So let's open our net a bit wider and look at programmers involved in more generic print-related areas. Specifically PDF and AFP. For me a good measure of IT programmer interest in a topic is a website called Code Project. This is a good "go to"site if you need some direction on coding a specific application - if you need code for something its likely here if someone somewhere in the world coded it already.
(As an aside, most or all of the code posted at Code Project is "free for reuse" in one form or another. This means that if you follow the rules an author lists you can use their exact code in your project. Personally I do not find this useful and mostly use it as a guide to develop my own code.)
So let's take a look here for PDF and AFP proejcts. For AFP we find nothing (putting "AFP" in the search box).
So let's try PDF. This is more interesting. Lots of projects but, on closer inspection, they mostly fall into a few paradigms: forms, merge, text extraction, creation, manipulation, and many more esoteric things like Silverlight.
Unfortunately in my quick scan I did not find one project related specifically to dealing with PDF for printing (excluding any sort of Windows print driver).
While this is not scientific its certainly makes my point about PDF and print. There isn't any direct IT interest outside those professionals already in the business.
Wolves...
On a side note I ran into my first "Lone Wolf" tattoo in the wild at the Walmart checkout last night. Though I didn't snap a picture (even though I had my camera phone) it was along these lines.
Bears...
Yesterday while jogging along a fairly isolated road near my house I crossed paths with a big black bear. I was coming down a small hill. On the right is a creek-bed behind a guard rail probably 4-5 feet below the road. On the right is woods.
As I came down the hill a large black bear jumped guard rail and lumbered across the road. Probably about twenty yards in front of me. He didn't look my way and just went straight across rather quickly. Not knowing what else to do I just kept running toward him. My thinking being that A) he wasn't stupid and knew I was there and B) there was no reason to attract attention to myself by suddenly doing something new or different.
As I mentioned last I have never seen specific IT training for the print/VDP/transpromo industry.
Virtually everyone I know with an IT background in these industries currently came there through some round-about way, i.e., did not specifically say "this is what I want to do".
So let's open our net a bit wider and look at programmers involved in more generic print-related areas. Specifically PDF and AFP. For me a good measure of IT programmer interest in a topic is a website called Code Project. This is a good "go to"site if you need some direction on coding a specific application - if you need code for something its likely here if someone somewhere in the world coded it already.
(As an aside, most or all of the code posted at Code Project is "free for reuse" in one form or another. This means that if you follow the rules an author lists you can use their exact code in your project. Personally I do not find this useful and mostly use it as a guide to develop my own code.)
So let's take a look here for PDF and AFP proejcts. For AFP we find nothing (putting "AFP" in the search box).
So let's try PDF. This is more interesting. Lots of projects but, on closer inspection, they mostly fall into a few paradigms: forms, merge, text extraction, creation, manipulation, and many more esoteric things like Silverlight.
Unfortunately in my quick scan I did not find one project related specifically to dealing with PDF for printing (excluding any sort of Windows print driver).
While this is not scientific its certainly makes my point about PDF and print. There isn't any direct IT interest outside those professionals already in the business.
Wolves...
On a side note I ran into my first "Lone Wolf" tattoo in the wild at the Walmart checkout last night. Though I didn't snap a picture (even though I had my camera phone) it was along these lines.
Bears...
Yesterday while jogging along a fairly isolated road near my house I crossed paths with a big black bear. I was coming down a small hill. On the right is a creek-bed behind a guard rail probably 4-5 feet below the road. On the right is woods.
As I came down the hill a large black bear jumped guard rail and lumbered across the road. Probably about twenty yards in front of me. He didn't look my way and just went straight across rather quickly. Not knowing what else to do I just kept running toward him. My thinking being that A) he wasn't stupid and knew I was there and B) there was no reason to attract attention to myself by suddenly doing something new or different.
Wednesday, September 22, 2010
A different kind of artistry...
I have been talking about what a database/programmer does to support the concept of personalization.
As I have been saying the requirements for personalization of any sort to succeed require extensive expertise in both graphic arts and programming. You will find a lot of support for personalization on the training side if you are a graphic artist - there are courses, trade shows, vendor programs, etc. Almost all are based to some degree on systems using a graphic-arts based product as the platform, i.e., as in say a Quark or inDesign-based personalization application.
What I have never seen is any sort of technical "IT-based" programmer/database training for this skill set.
I have been in the business for two decades and in all of that time I have never seen any type of training for IT-types related to direct mail, VDP, or other personalization. I have thought about this over the years and there is really only one conclusion I can draw: The printing industry desparately needs VDP/transpromo/personalization to succeed and therefore drives training on its own side (graphic-arts based) forward. On the other hand, IT doesn't need printing, and the number of IT professionals who would define themselves as "VDP/personalization-based" folks is probably very, very small.
By and large most programmers I know have virtually no knowledge of mailing, printing, color or any other of the most important issues associated with printing. What I have experienced personally is programmers that get pushed into this sort of work.
Interestingly most follow the same sort of technical road: Virtually all modern programmers have some experience creating a graphical UI for an application whether as a web interface or a programmatic one. So their first experience with anything printing or VDP related is to treat it like programming for a computer display. This means RGB, pixel-based X,Y addressing, and some knowledge of raster images. For the most part the programming tasks of positioning items conditionally, placing images, etc. is the same - in fact web page programming can be considerably more difficult due to the ways browsers lay out pages.
These are the most common things you find in the IT world so there is no reason for a programmer to think that the world of print is any different - particularly since there is no one to tell them otherwise. So the first kinds of print applications you see from a "programmer" - whether coding it directly in some way or via some sort of tools like a Quark, etc. is RGB-based. There is no concept of "the cost to RIP". The structure of the produced output is very rigid and inflexible relative to standard graphic art practices.
All-in-all not something a printer or graphic artist would want to deal with.
As I have been saying the requirements for personalization of any sort to succeed require extensive expertise in both graphic arts and programming. You will find a lot of support for personalization on the training side if you are a graphic artist - there are courses, trade shows, vendor programs, etc. Almost all are based to some degree on systems using a graphic-arts based product as the platform, i.e., as in say a Quark or inDesign-based personalization application.
What I have never seen is any sort of technical "IT-based" programmer/database training for this skill set.
I have been in the business for two decades and in all of that time I have never seen any type of training for IT-types related to direct mail, VDP, or other personalization. I have thought about this over the years and there is really only one conclusion I can draw: The printing industry desparately needs VDP/transpromo/personalization to succeed and therefore drives training on its own side (graphic-arts based) forward. On the other hand, IT doesn't need printing, and the number of IT professionals who would define themselves as "VDP/personalization-based" folks is probably very, very small.
By and large most programmers I know have virtually no knowledge of mailing, printing, color or any other of the most important issues associated with printing. What I have experienced personally is programmers that get pushed into this sort of work.
Interestingly most follow the same sort of technical road: Virtually all modern programmers have some experience creating a graphical UI for an application whether as a web interface or a programmatic one. So their first experience with anything printing or VDP related is to treat it like programming for a computer display. This means RGB, pixel-based X,Y addressing, and some knowledge of raster images. For the most part the programming tasks of positioning items conditionally, placing images, etc. is the same - in fact web page programming can be considerably more difficult due to the ways browsers lay out pages.
These are the most common things you find in the IT world so there is no reason for a programmer to think that the world of print is any different - particularly since there is no one to tell them otherwise. So the first kinds of print applications you see from a "programmer" - whether coding it directly in some way or via some sort of tools like a Quark, etc. is RGB-based. There is no concept of "the cost to RIP". The structure of the produced output is very rigid and inflexible relative to standard graphic art practices.
All-in-all not something a printer or graphic artist would want to deal with.
Tuesday, September 21, 2010
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:
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.
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:
- Construction of a design "mock up" for data-driven elements.
- Determination of the surrounding non-data driven elements.
- Acquisition of "test" data for testing #1.
- Design refinement, proofing, sign-offs and approvals.
- Receipt of the "live" data.
- Production of the pieces.
- Validation generated results.
- Post production finishing and delivery.
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.
Monday, September 20, 2010
Mixing art and closure...
So we discussed the concept of closure relative to a simple marketing problem.
Closure as I use it here is basically a mathematical concept and not the sort of thing that you would expect a graphic artist to really grasp. For that matter, some programmers struggle with the concept.
So the real question becomes how do you manage to do something like VDP or transpromo with just artists running an application like GMC, ISIS Papyrus, PageFlex, etc.?
In the answer to this question is really a larger problem. Bottom line is that you really cannot expect this to work in an art context - you really need programmers to do this reliably and professionally.
The larger problem is this: Why does the print/graphic arts industry promote technologies like VDP and transpromo that are really well beyond 90% of the companies in the business? I've thought about this quite a bit over the years and have come up with some troubling answers.
I think one element is that the "professionals" that run the various news, trade support organizations, and equipment (software, hardware) really need the industry to be in a constant state of change in order for them to maintain their jobs. If the industry remained relatively static than there wouldn't be much to do. Now I don't mean there wouldn't be tradeshows to write about and new about people and companies changing around - but there wouldn't be much exciting going on.
When I was in the mailing business in the mid-90's the industry was very much like that. There wasn't much technologically going on at the time so the trade shows, industry groups, and such really didn't have too much to talk about. This was just before the introduction of the first Indigo and Xeikon color digital presses.
I distinctly remember these devices when they first appeared. Long, long lines at the Indigo booth to get a sample, gushing press, call that this was "the future of printing" and "the future of direct mail". But these calls weren't from the grunts in the business - these were calls from the industry and product leaders - all folks who needed this for their own success.
Now I am not trying to be cruel here or discount the value of what an industry group does for an industry. But in a technical sense no one that I recall ever published a single paper or gave a single talk on the technical resources and skills required to make these devices work effectively.
Over the last many years I have also collected a lot of anectodal supporting evidence to support this. One thing I learned is that large companies at the very top of the food chain who sell color print devices and/or software will often end up "doing the work for their customer" in order to have success. A lot of times this means installing a technical guy on-site day and and out to get the work done.
Another common practice was to sell, in this case software, a product at a very low price and provide, along with the sale, a "technician" to "do the work for the customer". This was common in the "web-to-print" software area. Often a year of work would occur and nothing would get done. The real purpose of the sale was to squeeze out the competition for a year irrespective of the fate of the actual customer.
I couple this type of evidence with the basic fact that this technology was being sold to people who were not really equipped in a technical sense to use it effectively to make my point.
I see little evidence today that things have changed. Transpromo is more complex than basic VDP yet its being "promoted" as something for printers to think about. The reality is that the only printers that can really think about it are those that are in the process of becoming another type of company (other than printing).
Closure as I use it here is basically a mathematical concept and not the sort of thing that you would expect a graphic artist to really grasp. For that matter, some programmers struggle with the concept.
So the real question becomes how do you manage to do something like VDP or transpromo with just artists running an application like GMC, ISIS Papyrus, PageFlex, etc.?
In the answer to this question is really a larger problem. Bottom line is that you really cannot expect this to work in an art context - you really need programmers to do this reliably and professionally.
The larger problem is this: Why does the print/graphic arts industry promote technologies like VDP and transpromo that are really well beyond 90% of the companies in the business? I've thought about this quite a bit over the years and have come up with some troubling answers.
I think one element is that the "professionals" that run the various news, trade support organizations, and equipment (software, hardware) really need the industry to be in a constant state of change in order for them to maintain their jobs. If the industry remained relatively static than there wouldn't be much to do. Now I don't mean there wouldn't be tradeshows to write about and new about people and companies changing around - but there wouldn't be much exciting going on.
When I was in the mailing business in the mid-90's the industry was very much like that. There wasn't much technologically going on at the time so the trade shows, industry groups, and such really didn't have too much to talk about. This was just before the introduction of the first Indigo and Xeikon color digital presses.
I distinctly remember these devices when they first appeared. Long, long lines at the Indigo booth to get a sample, gushing press, call that this was "the future of printing" and "the future of direct mail". But these calls weren't from the grunts in the business - these were calls from the industry and product leaders - all folks who needed this for their own success.
Now I am not trying to be cruel here or discount the value of what an industry group does for an industry. But in a technical sense no one that I recall ever published a single paper or gave a single talk on the technical resources and skills required to make these devices work effectively.
Over the last many years I have also collected a lot of anectodal supporting evidence to support this. One thing I learned is that large companies at the very top of the food chain who sell color print devices and/or software will often end up "doing the work for their customer" in order to have success. A lot of times this means installing a technical guy on-site day and and out to get the work done.
Another common practice was to sell, in this case software, a product at a very low price and provide, along with the sale, a "technician" to "do the work for the customer". This was common in the "web-to-print" software area. Often a year of work would occur and nothing would get done. The real purpose of the sale was to squeeze out the competition for a year irrespective of the fate of the actual customer.
I couple this type of evidence with the basic fact that this technology was being sold to people who were not really equipped in a technical sense to use it effectively to make my point.
I see little evidence today that things have changed. Transpromo is more complex than basic VDP yet its being "promoted" as something for printers to think about. The reality is that the only printers that can really think about it are those that are in the process of becoming another type of company (other than printing).
Friday, September 17, 2010
When is it "right"...
So if I have a transpromo piece that I am working on how do I know that the result is correct? And, more importantly, that my employees have done the right things to produce it.
Let's think about the messages first. One presumes that they are provided along with some sort of characterization about which ad goes with which database query type. So, in our example from last time there would be an ad for X, Y and Z. Validation of X, Y, and Z from the perspective that they are graphically correct is fairly straight forward particularly if the ads are in PDF or raster form.
If they are not its important to convert them to one or the other. The reason for this is that some formats, e.g., PostScript and EPS, can affect pages they are embedded within. There an also be problems with formats like PDF. An example of this might be an embedded spot color. Ideally there are already mechanisms in place to address these types of issues and correct them.
As to when its right you will have to RIP the pieces and check that there are no errors when they are produced. Further checking will be needed which will be discussed later...
So as you will recall our coupon criteria (which pieces get which transpromo ad) is as follows:
Coupon A B
------------ ---- ----
X T 1
X T 3
Y S 1
Y S 2
Z X 4
Now, from a database perspective let's think about what might arrive in our "raw" customer database along with mailing information. Let's assume the mailing is important and everyone must receive the information.
Account A B
------------ ---- ----
000001 T 1
000002 T 3
000042 T 4
000003 S 1
000004 3
000005 X 4
000065 X
000075 X 1
Now our customer has supposedly given us specific criteria for each coupon. So, for the moment, let's believe what they have told us an create an extraction criteria to count how many customers get each type of coupon.
(We are going to use various forms of generic query and programming language fragments to discuss the next part of this. First, its important to remember that the logic we are using can be expressed in most any database or programming language so the details do not matter. Secondly, some VDP applications allow this in the application itself, others do not so you would do them "outside" the application - again the details are not important.)
So I might say:
Count Unique (Account) where A = 'T' and (B = '1' or B = '3')
for coupon X,
Count Unique (Account) where A = 'S' and (B = '1' or B = '2')
for coupon Y, and
Count Unique (Account) where A = 'X' and B = '4'
for coupon Z. Now, this gives me a count of 2 for X, 1 for Y and 1 for Z - a total of 4.
But we received 8 records! Well, first off our queries are correct - they ask specifically for what the customer told us to look for. But our result is incorrect. The reason for this is of course that the initial database we received is not logically closed over the given queries.
In this case we use closed to mean that if we A) receive a set of customer records and B) a set of queries to extract specific groups of customer then we have closure over A and B if we add up the count of all B's queries and we match the count of records in A.
In real life we can usually assume some sort of query for "all the rest", e.g., in this case for the items that do not match, that, when added to the other queries matches the total.
In any kind of VDP and/or transpromo situation it is a really good idea to validate what you receive from your customer for logical closure. This is just as important as making sure there are no graphic problems like spot colors. If you don't do this then you are sure to create misery for yourself and your customer.
Let's think about the messages first. One presumes that they are provided along with some sort of characterization about which ad goes with which database query type. So, in our example from last time there would be an ad for X, Y and Z. Validation of X, Y, and Z from the perspective that they are graphically correct is fairly straight forward particularly if the ads are in PDF or raster form.
If they are not its important to convert them to one or the other. The reason for this is that some formats, e.g., PostScript and EPS, can affect pages they are embedded within. There an also be problems with formats like PDF. An example of this might be an embedded spot color. Ideally there are already mechanisms in place to address these types of issues and correct them.
As to when its right you will have to RIP the pieces and check that there are no errors when they are produced. Further checking will be needed which will be discussed later...
So as you will recall our coupon criteria (which pieces get which transpromo ad) is as follows:
Coupon A B
------------ ---- ----
X T 1
X T 3
Y S 1
Y S 2
Z X 4
Now, from a database perspective let's think about what might arrive in our "raw" customer database along with mailing information. Let's assume the mailing is important and everyone must receive the information.
Account A B
------------ ---- ----
000001 T 1
000002 T 3
000042 T 4
000003 S 1
000004 3
000005 X 4
000065 X
000075 X 1
Now our customer has supposedly given us specific criteria for each coupon. So, for the moment, let's believe what they have told us an create an extraction criteria to count how many customers get each type of coupon.
(We are going to use various forms of generic query and programming language fragments to discuss the next part of this. First, its important to remember that the logic we are using can be expressed in most any database or programming language so the details do not matter. Secondly, some VDP applications allow this in the application itself, others do not so you would do them "outside" the application - again the details are not important.)
So I might say:
Count Unique (Account) where A = 'T' and (B = '1' or B = '3')
for coupon X,
Count Unique (Account) where A = 'S' and (B = '1' or B = '2')
for coupon Y, and
Count Unique (Account) where A = 'X' and B = '4'
for coupon Z. Now, this gives me a count of 2 for X, 1 for Y and 1 for Z - a total of 4.
But we received 8 records! Well, first off our queries are correct - they ask specifically for what the customer told us to look for. But our result is incorrect. The reason for this is of course that the initial database we received is not logically closed over the given queries.
In this case we use closed to mean that if we A) receive a set of customer records and B) a set of queries to extract specific groups of customer then we have closure over A and B if we add up the count of all B's queries and we match the count of records in A.
In real life we can usually assume some sort of query for "all the rest", e.g., in this case for the items that do not match, that, when added to the other queries matches the total.
In any kind of VDP and/or transpromo situation it is a really good idea to validate what you receive from your customer for logical closure. This is just as important as making sure there are no graphic problems like spot colors. If you don't do this then you are sure to create misery for yourself and your customer.
Thursday, September 16, 2010
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.
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.
Wednesday, September 15, 2010
The cost of transpromo...
In the last few posts we have reviewed the skill sets and the activities associated with a transpromo project (forgetting for the moment of conducting the project without the proper skills).
An average salary for a graphic artist might be $40K depending on experience, education, etc.
Average pay for a .net programmer would be around $60K, with similar pay for an experienced database person.
An experienced USPS mail person might cost $50K.
We'll skip the AFP/PDF skills for the moment.
Finally an IT security person will probably cost around $100K.
So, all together you probably would have a payroll of around $250K per year to handle basic transpromo work. This would include a set of 4-5 people with sufficient skills to set up and process the work.
Seems reasonable, right? Except we forgot the expensive "VDP" application to drive it. Many of these cost at least $100K along with the training to use it properly.
We also forgot someone to manage all this and handle the output properly (the AFP/PDF document handling). While each of these people may be able to do their task on their own they still need someone to manage all this and certainly that can't be the sales or customer service person.
We also forgot a Q/A person. Someone who can understand the customer requirements as well as the generated output and make a determination as to whether things are working or not.
And we also need to consider a sales person qualified to sell this type of work as well as a CSR to support the sales and production efforts.
All in all you're "investment" to be able to do "transpromo" would probably be about $500K per year minimum plus another couple hundred thousand for sales and support. (This of course assumes you have the devices necessary to produce and finish the work.) Now many companies interested in transpromo may have some of these skills on staff already so the "startup" cost might be less.
Let's say, just as an example, your total annual costs with a equipment, supplies and people is $750K. Given 200 work days per year you need to make $3,750 per day. At $.01 per piece you need to process 40K pieces per day or around 8 million pieces a year.
Having done this type of work and having been involved in all the aspects described above I can say that there are very few shops, especially print shops, that have these sorts of skills. The high-end financial services providers (FIS, Fiserv, etc.) all do this today in B/W and are now moving to color. Their cost structures are not like a print/mail shop in that they already have the IT portions handled.
- Graphic arts (design).
- Programmer/IT infrastructure.
- Database.
- USPS
- AFP/PDF document handling.
- Real security.
An average salary for a graphic artist might be $40K depending on experience, education, etc.
Average pay for a .net programmer would be around $60K, with similar pay for an experienced database person.
An experienced USPS mail person might cost $50K.
We'll skip the AFP/PDF skills for the moment.
Finally an IT security person will probably cost around $100K.
So, all together you probably would have a payroll of around $250K per year to handle basic transpromo work. This would include a set of 4-5 people with sufficient skills to set up and process the work.
Seems reasonable, right? Except we forgot the expensive "VDP" application to drive it. Many of these cost at least $100K along with the training to use it properly.
We also forgot someone to manage all this and handle the output properly (the AFP/PDF document handling). While each of these people may be able to do their task on their own they still need someone to manage all this and certainly that can't be the sales or customer service person.
We also forgot a Q/A person. Someone who can understand the customer requirements as well as the generated output and make a determination as to whether things are working or not.
And we also need to consider a sales person qualified to sell this type of work as well as a CSR to support the sales and production efforts.
All in all you're "investment" to be able to do "transpromo" would probably be about $500K per year minimum plus another couple hundred thousand for sales and support. (This of course assumes you have the devices necessary to produce and finish the work.) Now many companies interested in transpromo may have some of these skills on staff already so the "startup" cost might be less.
Let's say, just as an example, your total annual costs with a equipment, supplies and people is $750K. Given 200 work days per year you need to make $3,750 per day. At $.01 per piece you need to process 40K pieces per day or around 8 million pieces a year.
Having done this type of work and having been involved in all the aspects described above I can say that there are very few shops, especially print shops, that have these sorts of skills. The high-end financial services providers (FIS, Fiserv, etc.) all do this today in B/W and are now moving to color. Their cost structures are not like a print/mail shop in that they already have the IT portions handled.
Tuesday, September 14, 2010
More transpromo...
So yesterday we discussed the skill sets needed to conduct an effective transpromo marketing production effort. By production I mean we are not attempting to decide who gets a particular message, we are not creating the specific artwork associated with that message, nor are we handling details beyond saying here is artwork A and it goes to customers with profile A', artwork B and it goes to customers with profile B', and so on.
Here are the skills again:
For #1 we typically need basic graphic arts and mail-piece design skills - more than likely there will be a base template, say a letter, onto which some messages (A, B, etc. from above) will be placed. Typical mail stream documents are not all the same some the various sub-templates within the stream will each have to have a design decision made about where to place the message, what size to make the message, etc. The messages will have to obey various USPS rules such as keeping the message "outside the window" on the envelope in order to meet USPS requirements.
For #2 we will need to have the necessary database information available, the authoring application up and running, we need to load the client database and artwork into the authoring application, etc. We will need a large amount of disk space for the output, etc.
For #3 we will need to understand the structure of the client database, how it relates to the piece and the advertisements (A, B, etc.), what setup will be required (does it need capitalization, mail presort, cleaning of any type, etc.), and so forth. This may be very simple or very complex depending on the client and application. In my experience client IT people pull data (names, etc.) along with criteria (say income, location, etc.) and the print provider must combine the two to drive the piece.
For #4 we need to ensure that the piece we produce conforms. There are three major issues - does the piece conform to the type of mailing, does the piece physically match (no extra nonsense in the window), and are we adding information, such as an account number, that might cause the USPS to reject it (typically trying to mail a piece containing account numbers as "standard").
For #5 we need to be sure that the data we deliver to the printer is organized for production, i.e., batched in the right order. Depending on what we receive from the client this may be easy or hard. In some cases we must disassemble what we receive, reprocess it for the specific application, and reassemble things for production. This also may involve impositions and other processing.
For #6 - we need to make sure that the information conforms to the clients needs, e.g., HIPPA for health care, etc. This may be part of IT infrastructure or not. There also may be mailing security issues, i.e., we must be sure we mailed all the pieces.
Individually there is nothing interesting here. But hiring a single person to do all of this may be a challenge.
(I just did a search for "transpromo" on monster.com and got one hit for the entire USA.)
Here are the skills again:
- Graphic arts (design).
- Programmer/IT infrastructure.
- Database.
- USPS
- AFP/PDF document handling.
- Real security.
For #1 we typically need basic graphic arts and mail-piece design skills - more than likely there will be a base template, say a letter, onto which some messages (A, B, etc. from above) will be placed. Typical mail stream documents are not all the same some the various sub-templates within the stream will each have to have a design decision made about where to place the message, what size to make the message, etc. The messages will have to obey various USPS rules such as keeping the message "outside the window" on the envelope in order to meet USPS requirements.
For #2 we will need to have the necessary database information available, the authoring application up and running, we need to load the client database and artwork into the authoring application, etc. We will need a large amount of disk space for the output, etc.
For #3 we will need to understand the structure of the client database, how it relates to the piece and the advertisements (A, B, etc.), what setup will be required (does it need capitalization, mail presort, cleaning of any type, etc.), and so forth. This may be very simple or very complex depending on the client and application. In my experience client IT people pull data (names, etc.) along with criteria (say income, location, etc.) and the print provider must combine the two to drive the piece.
For #4 we need to ensure that the piece we produce conforms. There are three major issues - does the piece conform to the type of mailing, does the piece physically match (no extra nonsense in the window), and are we adding information, such as an account number, that might cause the USPS to reject it (typically trying to mail a piece containing account numbers as "standard").
For #5 we need to be sure that the data we deliver to the printer is organized for production, i.e., batched in the right order. Depending on what we receive from the client this may be easy or hard. In some cases we must disassemble what we receive, reprocess it for the specific application, and reassemble things for production. This also may involve impositions and other processing.
For #6 - we need to make sure that the information conforms to the clients needs, e.g., HIPPA for health care, etc. This may be part of IT infrastructure or not. There also may be mailing security issues, i.e., we must be sure we mailed all the pieces.
Individually there is nothing interesting here. But hiring a single person to do all of this may be a challenge.
(I just did a search for "transpromo" on monster.com and got one hit for the entire USA.)
Monday, September 13, 2010
The wonder of transpromo...
I found an interesting article on the PrintCeo blog located here: PrintCeo.
It talks about transpromo applications at big print shows "...[in] hopes of attracting general commercial printers to buy the necessary software costing in the six figures and the higher speed digital print engines."
What is interesting about this is that the only ones really hoping someone spends hundreds of thousands of dollars (application software plus digital press) are the vendors. In fact, it can be done with cheap B/W printers, a PC, and a little elbow grease.
The real problem is that there is no "printer" market for transpromo unless you have the proper economic circumstances. What are the proper circumstances? Basically that you already profitably print statements with room for additional marketing messages. The role of traditional printing in this context is limited to primarily pre-printed "shells" onto which the statements are printed.
Success in transpromo typically involves having a large room full of big, fast printers, inserters, mail handling technology, IT, and so forth. Not your typical "printer" fare. So why to these blogs, and for that matter the print industry in general, wax on and on about the wonders of transpromo?
Simple - those that write the articles, build the presses and write the software need jobs, and, in fact the industry doesn't need what they are selling.
I saw this first hand ten years ago when I was inadvertently sucked into a printing "industry catastrophe". It seems a certain soon-to-be digital press vendor made some rather exciting market projections for their devices. I don't recall any specifics but when you extrapolated out they alone were selling something like several digital presses a day by 2005 or '06. At that time I had a small software company that fit right in with their technology in terms of variable data so it seemed natural that we would do well.
Long story short - about a year later I remember sitting in my office with a guy that worked for me and we worked out the projections year to year. It was clear that the market they expected was simply impossible.
Even with simple, color-based VDP applications the skill sets required to operate the systems simply do not exist. Think about it. You need a professional graphic arts person to control the design of the piece, i.e., where does the coupon look good on the piece. You need a professional programmer to write logic to control things (IF THEN ELSE). You need a database specialist to extract the right data from the customer provided data. You need a USPS expert who can tell you if the piece can go first class or standard based on the content.
Where on earth do you find such a person? You don't - at least not in a print shop. While there are a few (and I am one of them) most people you find trying to do this outside of certain industries are former graphic artists (artist being the key word) or former pressmen who now do "computers".
Now, let's add the "transpromo" skill set. First - the statements probably come from somewhere else already formatted with meta data talking about ads and mailing info. So you need someone that understands this model. Likely the pre-formatted content is in AFP. Next, its effectively banking data so you need to understand security, i.e., you can't just have data sets lying around on open FTP servers.
So to summarize - transpromo requires the following skill sets in the context of a "printer":
Next you have to consider how to get them all to work together...
It talks about transpromo applications at big print shows "...[in] hopes of attracting general commercial printers to buy the necessary software costing in the six figures and the higher speed digital print engines."
What is interesting about this is that the only ones really hoping someone spends hundreds of thousands of dollars (application software plus digital press) are the vendors. In fact, it can be done with cheap B/W printers, a PC, and a little elbow grease.
The real problem is that there is no "printer" market for transpromo unless you have the proper economic circumstances. What are the proper circumstances? Basically that you already profitably print statements with room for additional marketing messages. The role of traditional printing in this context is limited to primarily pre-printed "shells" onto which the statements are printed.
Success in transpromo typically involves having a large room full of big, fast printers, inserters, mail handling technology, IT, and so forth. Not your typical "printer" fare. So why to these blogs, and for that matter the print industry in general, wax on and on about the wonders of transpromo?
Simple - those that write the articles, build the presses and write the software need jobs, and, in fact the industry doesn't need what they are selling.
I saw this first hand ten years ago when I was inadvertently sucked into a printing "industry catastrophe". It seems a certain soon-to-be digital press vendor made some rather exciting market projections for their devices. I don't recall any specifics but when you extrapolated out they alone were selling something like several digital presses a day by 2005 or '06. At that time I had a small software company that fit right in with their technology in terms of variable data so it seemed natural that we would do well.
Long story short - about a year later I remember sitting in my office with a guy that worked for me and we worked out the projections year to year. It was clear that the market they expected was simply impossible.
Even with simple, color-based VDP applications the skill sets required to operate the systems simply do not exist. Think about it. You need a professional graphic arts person to control the design of the piece, i.e., where does the coupon look good on the piece. You need a professional programmer to write logic to control things (IF THEN ELSE). You need a database specialist to extract the right data from the customer provided data. You need a USPS expert who can tell you if the piece can go first class or standard based on the content.
Where on earth do you find such a person? You don't - at least not in a print shop. While there are a few (and I am one of them) most people you find trying to do this outside of certain industries are former graphic artists (artist being the key word) or former pressmen who now do "computers".
Now, let's add the "transpromo" skill set. First - the statements probably come from somewhere else already formatted with meta data talking about ads and mailing info. So you need someone that understands this model. Likely the pre-formatted content is in AFP. Next, its effectively banking data so you need to understand security, i.e., you can't just have data sets lying around on open FTP servers.
So to summarize - transpromo requires the following skill sets in the context of a "printer":
- Graphic arts (design).
- Programmer/IT infrastructure.
- Database.
- USPS
- AFP/PDF document handling.
- Real security.
Next you have to consider how to get them all to work together...
Friday, September 10, 2010
The Death of Offset...
Color highspeed inkjets are here to stay and it seems to me that the days of toner-based color are numbered. While these new devices are still quite expensive there is significant market penetration. I recently read that there are about 300 of these type of devices installed world wide and the number is steadily increasing.
The first machines had a variety of color and quality limitations but these have been addressed in newer systems and I would expect to see full color gloss inkjet output become the mainstay for many applications.
What does this mean for the future? For one thing there will be an aggregation of business into the largest print-providers. So something that mom and pop print shop can do today will be done elsewhere and shipped to the consumer via UPS or Fedex -just like everything else. Fifteen years ago I owned a print shop as part of a mailing business - we had several offset presses and a couple of pressmen. The purpose of all this was to get laser-ready print to the mailshop in a timely manner.
Today a giant service company can do all of that with one inkjet in one pass - of course there is still the issue of envelopes but for many applications it can be gotten around.
Now its interesting to see that even though print is declining in the sense that younger people no longer use it these devices are currently expanding into that same market. As I have said before this is based on cost - and probably cost alone.
Personally I do not use much paper anymore - and I am in the business of serving print providers. This is an interesting phenomena. I still receive two paper publications - one magazine and one newspaper - and I buy books. But, as soon as there is a slightly larger iPad screen I will be converting those. Recently I needed a reference book on data compression - I ended up purchasing it from Amazon electronically. I found this experience to be quite unpleasant because the Amazon viewer is very lame - the index did not work, you could only jump around by chapter, and the page length depended on how large the viewing window was so you could easily lose your place.
What will happen from here? The color/toner/digital press will phase out as too expensive over the next few years and the industry functions they serve will get consolidated into larger companies or moved onto highspeed inkjet devices.
The little offset printer down the street will go out of business - someone once told me they thought 25% of these companies printed for the cost of paper.
It will be easier and cheaper to buy your place mats online, have them printed and shipped to your door for less than mom and pop can do the job.
The first machines had a variety of color and quality limitations but these have been addressed in newer systems and I would expect to see full color gloss inkjet output become the mainstay for many applications.
What does this mean for the future? For one thing there will be an aggregation of business into the largest print-providers. So something that mom and pop print shop can do today will be done elsewhere and shipped to the consumer via UPS or Fedex -just like everything else. Fifteen years ago I owned a print shop as part of a mailing business - we had several offset presses and a couple of pressmen. The purpose of all this was to get laser-ready print to the mailshop in a timely manner.
Today a giant service company can do all of that with one inkjet in one pass - of course there is still the issue of envelopes but for many applications it can be gotten around.
Now its interesting to see that even though print is declining in the sense that younger people no longer use it these devices are currently expanding into that same market. As I have said before this is based on cost - and probably cost alone.
Personally I do not use much paper anymore - and I am in the business of serving print providers. This is an interesting phenomena. I still receive two paper publications - one magazine and one newspaper - and I buy books. But, as soon as there is a slightly larger iPad screen I will be converting those. Recently I needed a reference book on data compression - I ended up purchasing it from Amazon electronically. I found this experience to be quite unpleasant because the Amazon viewer is very lame - the index did not work, you could only jump around by chapter, and the page length depended on how large the viewing window was so you could easily lose your place.
What will happen from here? The color/toner/digital press will phase out as too expensive over the next few years and the industry functions they serve will get consolidated into larger companies or moved onto highspeed inkjet devices.
The little offset printer down the street will go out of business - someone once told me they thought 25% of these companies printed for the cost of paper.
It will be easier and cheaper to buy your place mats online, have them printed and shipped to your door for less than mom and pop can do the job.
Thursday, September 9, 2010
Things get more cloudy... (and why I am down on print)
So after some research I uncovered a Google blog on Chrome - their new operating system - relating to print. It talks about print and, reading the comments section, I find that I am late to the party. It looks like all this was first posted around April 15th of this year.
So, after finding this, I went off to look for the HP version. While still late to the party, I am not as late as with Google. HP's "cloud printing" statement can be found here. Now, personally, I have been to the HP printer development group headquarters and so I think these guys are probably a little more serious than Google. Print is a big part of HP and it directly affects the bottom line so I would imagine more thought has gone in to this.
HP's idea is that you give each printer an email address that's unique. Then, anyone who knows that address can send things to the printer and have them print. I suppose this would make sense around the house but certainly not at the office. Imagine the fun when snooping neighbors email pictures snapped through the bedroom window to your home printer.
HP also has an idea call "ePrintCenter" which allows you to have certain things, like news, emailed to your printer at a specific time. This idea does not have much going for it. If CNN or WSJ can email news to my printer why not just email it to my PDA or iPad? Printing news everyday on expensive paper using expensive ink seems like nothing more than a good way for HP to sell you supplies.
A while back someone asked me why I was so down on printing in general and why I was not focusing my company and its products there.
I replied "my 80 year old mother likes print - phone bills, newspapers, etc. My children who range in age from 26 to 35 use laptops - they get no newspapers, use only ebills, etc. Which do you think is a growing print market?" (Answer: neither).
Print will always have a place in the world because its part of physical things that, so far, people are unwilling to let go of, e.g., ID cards, signage, etc. due to security issues. In the long run the cost of LCD displays and computers will continue to drop and, as they do, they will continue to replace physical print.
So, after finding this, I went off to look for the HP version. While still late to the party, I am not as late as with Google. HP's "cloud printing" statement can be found here. Now, personally, I have been to the HP printer development group headquarters and so I think these guys are probably a little more serious than Google. Print is a big part of HP and it directly affects the bottom line so I would imagine more thought has gone in to this.
HP's idea is that you give each printer an email address that's unique. Then, anyone who knows that address can send things to the printer and have them print. I suppose this would make sense around the house but certainly not at the office. Imagine the fun when snooping neighbors email pictures snapped through the bedroom window to your home printer.
HP also has an idea call "ePrintCenter" which allows you to have certain things, like news, emailed to your printer at a specific time. This idea does not have much going for it. If CNN or WSJ can email news to my printer why not just email it to my PDA or iPad? Printing news everyday on expensive paper using expensive ink seems like nothing more than a good way for HP to sell you supplies.
A while back someone asked me why I was so down on printing in general and why I was not focusing my company and its products there.
I replied "my 80 year old mother likes print - phone bills, newspapers, etc. My children who range in age from 26 to 35 use laptops - they get no newspapers, use only ebills, etc. Which do you think is a growing print market?" (Answer: neither).
Print will always have a place in the world because its part of physical things that, so far, people are unwilling to let go of, e.g., ID cards, signage, etc. due to security issues. In the long run the cost of LCD displays and computers will continue to drop and, as they do, they will continue to replace physical print.
Tuesday, September 7, 2010
Cloud Printing....?
Good old What They Think has sends me an email about Google "Cloud Printing"...
What is that, you might ask? Well, according to Google, its this (from Google):
Cloud-aware Printer
"The ideal experience is for your printer to have native support for connecting to cloud print services. Under this model, the printer has no need for a PC connection of any kind or for a print driver. The printer is simply registered with one or more cloud print services and awaits print jobs. Cloud-aware printers don't exist yet, but one of our main goals in publishing this information at an early stage is to begin engaging industry leaders and the community in developing cloud-aware printers and the necessary open protocols for these printers to communicate with cloud print services. We believe cloud printing has tremendous benefits for end users and for the industry and is essential, given the rapid shift toward cloud-based applications and data storage. We also believe that the only way that the benefits of cloud printing can be realized is if the protocols are open, freely implementable, and, when possible, based on existing industry standards. We expect there to be multiple cloud print services, and users should have a choice in which services they use and which printers they can connect to a service. Stay tuned for more details. We are confident that cloud-aware printers will soon be a reality "
Where to begin with all this...
Let's start with "no need for a PC connection". About 10 years ago I bought a little Xerox printer called the N40. It produces (to this day) 40 pages a minute B/W. Remarkably this little guy sports an internal FTP server, a web print server and support for various IP-based printing protocols. The later meaning that, if I opened up my fire wall, I could print to it from anywhere in the world. Now, there are a lot of reasons why opening up my firewall might be a bad idea, but I could do it. So cross off "no need for a PC connection"
So let's think for a minute about the context in which one might say what they are saying. First, you'd have to be so stupid as to not have used (in the technical "read the manual to see what it does" sense) a modern office printer because clearly all this fancy networking capability is at least a decade old. I never had much respect for the people that work at Google but this really takes the cake. I suppose that something like causing a piece of bleached white paper to have toxic chemicals melted onto it by a power hungry, un-green, naked electrical heating element is probably not what goes on in their company offices - but, perhaps after a decade or so of operation, the need has finally arisen
Now let's think about "awaits print jobs". In today's world about the first thing you will find when you get a new email address, web site, etc. is that spam and hackery from all over the planet will immediately arrive unsolicited. So my guess is that every Russian wanna-be-your-wife (sorry to be sexist but, presuming the web to be gender neutral, at least so far no Russian men have been soliciting me) on the planet will now be able to cause her no-doubt flawlessly beautiful image to print in your office without your permission. I imagine that Google will have to invent a new protocol to ensure that these images all involve only "fully clothed" potential brides. (Imagine the office fun when the purveyors of "porn spam" or ex-significant other web sites find these printers.)
Now let's think about cost. Good old B/W is very cheap - so I suppose I really won't mind when a potential Russian bride sends my printer tens of thousands of pictures of her very best friends to print. No where do I see discussion of how those who on the printers get paid for the expense of operating them - no tracking of resources used, nothing. So I suppose that when little highschool Johnny sexts a naked picture of his under-age girl friend to mom or dad's office printer not only will there be hell to pay with the authorities but mom or dad's boss will be forced to eat the cost of the printing fun.
Looking over their site listed above we also see that Google will support PDF and PPD's.
I haven't run across PPD's in many years but its good to see clueless fools resurrect a complete disaster in the name of "open, freely implementable" protocols.
I think PPDs' will have to have their own post...
Its bad enough Google owns you email, your pictures, and everything else you wantonly stuff into its awaiting maw. So now we can add "print jobs" to the mix.
What is that, you might ask? Well, according to Google, its this (from Google):
Cloud-aware Printer
"The ideal experience is for your printer to have native support for connecting to cloud print services. Under this model, the printer has no need for a PC connection of any kind or for a print driver. The printer is simply registered with one or more cloud print services and awaits print jobs. Cloud-aware printers don't exist yet, but one of our main goals in publishing this information at an early stage is to begin engaging industry leaders and the community in developing cloud-aware printers and the necessary open protocols for these printers to communicate with cloud print services. We believe cloud printing has tremendous benefits for end users and for the industry and is essential, given the rapid shift toward cloud-based applications and data storage. We also believe that the only way that the benefits of cloud printing can be realized is if the protocols are open, freely implementable, and, when possible, based on existing industry standards. We expect there to be multiple cloud print services, and users should have a choice in which services they use and which printers they can connect to a service. Stay tuned for more details. We are confident that cloud-aware printers will soon be a reality "
Where to begin with all this...
Let's start with "no need for a PC connection". About 10 years ago I bought a little Xerox printer called the N40. It produces (to this day) 40 pages a minute B/W. Remarkably this little guy sports an internal FTP server, a web print server and support for various IP-based printing protocols. The later meaning that, if I opened up my fire wall, I could print to it from anywhere in the world. Now, there are a lot of reasons why opening up my firewall might be a bad idea, but I could do it. So cross off "no need for a PC connection"
So let's think for a minute about the context in which one might say what they are saying. First, you'd have to be so stupid as to not have used (in the technical "read the manual to see what it does" sense) a modern office printer because clearly all this fancy networking capability is at least a decade old. I never had much respect for the people that work at Google but this really takes the cake. I suppose that something like causing a piece of bleached white paper to have toxic chemicals melted onto it by a power hungry, un-green, naked electrical heating element is probably not what goes on in their company offices - but, perhaps after a decade or so of operation, the need has finally arisen
Now let's think about "awaits print jobs". In today's world about the first thing you will find when you get a new email address, web site, etc. is that spam and hackery from all over the planet will immediately arrive unsolicited. So my guess is that every Russian wanna-be-your-wife (sorry to be sexist but, presuming the web to be gender neutral, at least so far no Russian men have been soliciting me) on the planet will now be able to cause her no-doubt flawlessly beautiful image to print in your office without your permission. I imagine that Google will have to invent a new protocol to ensure that these images all involve only "fully clothed" potential brides. (Imagine the office fun when the purveyors of "porn spam" or ex-significant other web sites find these printers.)
Now let's think about cost. Good old B/W is very cheap - so I suppose I really won't mind when a potential Russian bride sends my printer tens of thousands of pictures of her very best friends to print. No where do I see discussion of how those who on the printers get paid for the expense of operating them - no tracking of resources used, nothing. So I suppose that when little highschool Johnny sexts a naked picture of his under-age girl friend to mom or dad's office printer not only will there be hell to pay with the authorities but mom or dad's boss will be forced to eat the cost of the printing fun.
Looking over their site listed above we also see that Google will support PDF and PPD's.
I haven't run across PPD's in many years but its good to see clueless fools resurrect a complete disaster in the name of "open, freely implementable" protocols.
I think PPDs' will have to have their own post...
Its bad enough Google owns you email, your pictures, and everything else you wantonly stuff into its awaiting maw. So now we can add "print jobs" to the mix.
Friday, September 3, 2010
Patent '599
I was looking over '599 today and trying to think back about the context into which it was developed.
If you take a close look at it you will see the basis for all "VDP"-type applications today. Specifically they used some sort of Quark-based front-end to design master pages and used Quark to reflow text for each variable page. The press then merged the results.
At the time this was developed Indigo had just come on the market as had the first Xeikon's. I remember in about 1997 driving down to Chicago to see AM MultiGraph, who was the initial US Xeikon distributor, to test some color variable data work for a company I owned at the time called MarketPlace Direct.
MarketPlace Direct was what I called an "information distribution" business. We did mailing, delivery, printing, all manner of non-electronic processing of data for clients to distribute to customers. The reason I was interested was that I had developed a PageMaker-based VDP system that was used by MarketPlace for all its variable data work - it was called the "Lexographic Imager" (no - it doesn't invalidate '599).
Basically this was a piece of technology that took PageMaker PostScript output and performed substitutions into it to produce a variable print stream. Some clever technology was used to significantly optimize the print speed. We used to buy some kind of HP black and white toner printers for about $5K and gang them up to create a fairly fast black and white printer. All together with about 5 of these printers and my software you could duplicate what a 150 page/minute Xerox highspeed printer could do for about 10% of the cost.
Being in the mailing business we had to be clever about preprinted forms. But, because my system was based on PageMaker, we could design the forms and the mailing job in one application. And because we used the same application and files for both the preprinting and variable alignment was guaranteed.
The reason for my interest in the time with Xeikon was that in mailing you always have "spoilage" - which are letters that get damaged in the process of printing through getting the mail out the door. Those pieces have to be reproduced and mailed. Doing this involved keeping around all the preprinted paper and matching the reprinting to the right paper forms. Managing spoilage was expensive and time consuming.
At the time I reasoned that for small jobs - even though the cost was high - as well as for spoilage - color digital press work the time and money saved more than justified the extra cost. I think the cost was around $1.00 US per page at the time. Fortunately we could charge significantly more per page for the finished work at that time.
If you take a close look at it you will see the basis for all "VDP"-type applications today. Specifically they used some sort of Quark-based front-end to design master pages and used Quark to reflow text for each variable page. The press then merged the results.
At the time this was developed Indigo had just come on the market as had the first Xeikon's. I remember in about 1997 driving down to Chicago to see AM MultiGraph, who was the initial US Xeikon distributor, to test some color variable data work for a company I owned at the time called MarketPlace Direct.
MarketPlace Direct was what I called an "information distribution" business. We did mailing, delivery, printing, all manner of non-electronic processing of data for clients to distribute to customers. The reason I was interested was that I had developed a PageMaker-based VDP system that was used by MarketPlace for all its variable data work - it was called the "Lexographic Imager" (no - it doesn't invalidate '599).
Basically this was a piece of technology that took PageMaker PostScript output and performed substitutions into it to produce a variable print stream. Some clever technology was used to significantly optimize the print speed. We used to buy some kind of HP black and white toner printers for about $5K and gang them up to create a fairly fast black and white printer. All together with about 5 of these printers and my software you could duplicate what a 150 page/minute Xerox highspeed printer could do for about 10% of the cost.
Being in the mailing business we had to be clever about preprinted forms. But, because my system was based on PageMaker, we could design the forms and the mailing job in one application. And because we used the same application and files for both the preprinting and variable alignment was guaranteed.
The reason for my interest in the time with Xeikon was that in mailing you always have "spoilage" - which are letters that get damaged in the process of printing through getting the mail out the door. Those pieces have to be reproduced and mailed. Doing this involved keeping around all the preprinted paper and matching the reprinting to the right paper forms. Managing spoilage was expensive and time consuming.
At the time I reasoned that for small jobs - even though the cost was high - as well as for spoilage - color digital press work the time and money saved more than justified the extra cost. I think the cost was around $1.00 US per page at the time. Fortunately we could charge significantly more per page for the finished work at that time.
Thursday, September 2, 2010
I was a little worried...
... about coming up with some pertinent posting material but, low and behold, HP and R.R. Donnelley have come to the rescue.
There is a new story here about two of my oldest and dearest friends: US Patent's 6,205,452 and 6,327,599.
These are usually referred to collectively as the "Warmus Patents" after James L. Warmus who is the principle author to both. Basically these patents describe modern digital-press-based template variable data printing. What's important about these patents are two things: First, I believe it is claimed by the owner that they "cover" the concept of designing and printing variable data documents - so if you're a company selling a device that can perform that type of printing you're a target. Second, the patents go back in time to before "modern VDP" - 599 is dated June 1995, 452 is dated October of 1997.
From 452:
Basically this describes a database controlling selected print elements such as graphics on a printed page, a means to design the document containing those elements, and the processing of merging the two.
From 599:
This describes a "press controller" for merging the types of elements defined in 452 using a "master page" with fixed information and a process to insert the variable information into the master page.
Now the "modern era" of VDP does not start until about 2000 or 2001 and all modern digital presses in use today have controllers that match 599 - so you can see why there might be a problem.
In the past I have done extensive professional legal research related to these patents for my self as well as for clients.
And, just for the record, in my opinion both are invalid and I believe that I have solid proof - so, council to HP, if you are out there let me know - I can save you a lot of time, money and grief.
Subscribe to:
Posts (Atom)