How to implement JDF

Human aspects

People often focus on the technical aspects of JDF, forgetting that technology also has an impact on people and that people’s reaction to this can make or break the project. Vendors and JDF-adopters often overlook this aspect in the initial project phase and learn the hard way that if users are against a particular project, they can be very creative in making sure that the project does not get very far.

Fear for unemployment

Automation is often about reducing labor costs. With JDF it is no different. If management leaves it in the open what the actual purpose of implementing JDF is, people will logically assume that it is all about making them redundant. In some cases, they may be right but in other cases, the goal is to be able to take on more work or free resources to move into other markets. If this is not communicated clearly, people’s resistance to the project may kill it in its very infancy. Every little glitch or missing function (and there will be glitches and oversights) becomes an excuse to stick to the old way of doing things.

Responsibility shift

In essence, JDF is about communicating job-related information downstream: from the service that initiated the job to others who handle the next phase. This means that part of the responsibility for the job moves upstream. For example: previously someone in prepress would define in the prepress workflow which spot colors get printed and which get converted to CMYK. In a JDF enabled workflow, this information is provided by the MIS system, based on the job definition from the sales rep or someone in the order processing department.
People often dislike and object to this shift in responsibility. Prepress is afraid of losing control. Sales do not want to carry any responsibility for job processing.

Resistance to change

While some people seem to thrive on changing work conditions and new challenges, a lot of people simply resist change, no matter how much of an improvement it may be for them and/or for the company.

Involvement

Nothing gets some people so keyed up as the idea that something is being planned above their head without any involvement from them. It is a good idea to get people involved in those parts of the projects for which they have the expertise. This gives you internal ‘buy-in’ for the automation project.

Information overload

Giving people too much data is as bad as providing not enough information to get the job done. With JDF it is so easy to distribute detailed job data at any point in time that it is tempting to always do this. This can lead to confusion and lost productivity. A typical example: if an MIS system is configured to send job-related data to all other systems in the company, the guys in the press room all of a sudden also get to see the jobs that are still in the initial design phase and that they may not get in their hands for the next two months. This has no benefit for them and may make it more difficult for them to manage their system and monitor the actual jobs that are running. A good scheduler needs to withhold the job data and JDF until these are actually needed in the pressroom.