In the last article, we looked at how many of the equipment manufacturers have designed their DFE offerings, and some of the included components. But if DFEs are designed to control a specific device, how do we manage and control the overall workflow that can include many DFEs and the associated devices from disparate manufacturers? And more importantly, how do you do this in a way that allows you to optimize your plant manufacturing capabilities, while ensuring that you have the flexibility to continue to change as future requirements change?

I guess the first question is; what is a workflow? Back in the mid 1990s when CTP started to proliferate, vendors started to market ‘workflow systems.’ Unfortunately, each one of them had a different view on what a workflow system really was. At that time, out of frustration and curiosity, I decided to create a base model of all of the potential tasks that a CTP workflow could include. This model, which is shown below (click to enlarge), was published in the Seybold Report in 1997.


Click to Enlarge

Subsequently, in the late 1990’s and early 2000’s we reviewed and compared most of the workflow systems available at that time against the base model and published the results in the Seybold Report. It was an important step since it provided each of the solution developers a way to begin to focus and measure their products. This model, in many respects the predecessor to the PRIMIR Transformational Workflow model highlighted earlier in the series, is broken into three sections.

  • Production Tasks, which include the granular production operations;
  • Production Management Tasks, which comprises the necessary operations to manage and control the Production Tasks; and
  • Business Management Tasks, which include the operations that are needed to bridge the business requirements with the production requirements.

Trying to include many if not most of these tasks in a solution became the goal of many of the manufacturers, and you can see some of this in the DFE and workflow offerings available today.  In many respects, they mimic the earlier CTP workflow systems. However, while this may have made sense when CTP was the core of a prepress plant workflow, today with the addition of many disparate digital print, cross-media, and other output production requirements, there is a need for a new look at how this model or a new model should be applied to product offerings and plant implementations. Ultimately the workflow needs to be the hub, not the device. 

As I alluded to in the last article on DFEs, perhaps it has to start with a reevaluation of what a DFE needs to support in the context of the broader workflow with today’s new requirements. If we were to extract the relevant operational tasks from the above model, the DFE could be something simple like this basic RIP.

 

But this really isn’t completely adequate to address all of the needs of a DFE. What about inter-process communication, and device-dependent operations like color management, preflight, trapping, imposition, VDP, etc. So perhaps it should look more like this?

 

Of course, since a DFE is by its nature a device dependent solution, some of these operations may be unnecessary, and it’s ultimate construction can and should vary based on the specific device requirements. The key here is not to include more than is necessary. Once the operations in the DFE start to expand beyond the device requirement workflow and move into the territory of the plant workflow, you could wind up with operational feature redundancy which can add cost, confusion, create production silos and inconsistencies in output from different devices, etc.

The specific designation of operations and roles between the DFE and the plant workflow are increasingly the key to successful process automation and greater plant flexibility. It’s not that you can’t create an efficient automated plant workflow with bulked up DFE systems or even some of the tightly controlled device vendor based workflow systems; it just adds an unnecessary level of waste or complexity to the final solution.

Since a workflow is really about building touch points for a series of operations, we need to look at the primary clients of those operations. There are two separate parallel, but sometimes interconnected, data streams in a production workflow: production data, and production files. There can also be a third if there is variable data involved. To achieve maximum success in building a forward- facing automated workflow, you need to have a solution that will support each of these data streams and provide for the interaction of the results with the other data streams as needed. This requires an open workflow with good inter-application communication capabilities and good, open, applications to process the data streams.

These ideal workflow and application candidates can come bundled in a comprehensive solution, or can come as separate components that you can select and build to meet your individual plant and process requirements. In the next article we will look at some representative samples of the currently available comprehensive workflow systems and some of their features.

Remember, if you have any topics you think are important and would like us to cover during the balance of this series, please let us know!