In the last article, we looked at the evolution of workflow systems from their origins as plant-centric CTP front ends to the device-centric DFEs of today. While software solutions in our industry are always in a state of evolution, many of these workflow software systems are currently going through significant changes to address the many new market requirements. In addition to the need to support many new service offerings, these requirements include the need for managing a complete plant workflow of disparate equipment from many vendors, and also include the need for much quicker turnarounds, better bi-directional client communication, remote access, cloud services integration, and tools to address increasing cost pressures.

In the market today, you will find three general classes of workflow systems: those that started as plant centric CTF/CTP front ends and ‘may’ have been enhanced to support other devices; those that were developed specifically for a print output device (not CTP); and finally, hybrid component systems that can be built from an assortment of best fit, best of breed solutions including packaged systems and can address a wide range of disparate output devices and process requirements. Additionally, there are individual solutions that support specific applications that will be examined in future articles.

In the first class of packaged workflow systems offerings include Agfa :Apogee, DALiM Twist, Esko Automation Engine, Fujifilm XMF, Heidelberg Prinect Prepress, Kodak Prinergy, and Screen Equios. These workflow systems have many things in common. At the core, they all have an Interpreter that processes incoming page description files into pixels for imaging on a device, as well most of the other functions we discussed in the previous DFE article. In addition to those functions, most of them offer preflight normalization, varied levels of trapping and imposition, and some offer PDF editing capabilities. Most of them have a modular design that allows for the addition of new workflow components as desired or offered. Early examples would include the addition of the now ubiquitous InSite portal module for Kodak Prinergy which enables a client workflow bridge, and more recently the addition of Heidelberg Prinect Smart Automation to the Heidelberg Prinect Prepress system, adding workflow automation.

Another area of development for many of these systems has been the addition of functionality that supports disparate output devices. While most of them have been able to process files and then output TIFF files to disparate CTP devices, many are now adding varied support for digital printers from a variety of vendors. This has ben proven to be more of a challenge for them, and the level of support for digital printers from these workflow systems is spotty at best, due to the many differences among printing devices. Part of the problem is that there is no standard way to ‘register’ a new device with the system in order to enable newly connected device features. However, most offer the ability to export normalized or processed PDF or rendered files that can be dropped into an incoming hot folder for consumption by the digital press DFE. In a future article, we will explore how you can use this method as a way to harmonize all of your print output for offset and digital presses.

The second class of system, which is designed specifically for digital printers, adds device-specific or process-specific functionality on top of the functionality offered by the previously discussed systems. Since this class can include many different types of print devices from sheetfed up to high volume continuous feed, there are many potential applications for them, and a wide range of corresponding workflow functions to support them. These systems include EFI Fiery Workflow Suite, HP SmartStream, Océ Prisma, Ricoh Total Flow, and Xerox FreeFlow. Since many of these are readying new releases for Print 13, I will cover them in more detail after the event.

If we look at the types of added functionality these support, it includes varied web-to-print functions, multiple print engines, finishing devices, variable data processing, packaging and label support, and more. In many cases, this class of system has also been designed to work with third-party solutions including products from Esko, GMC, RSA, Solimar, XMPie and others that address specific application process requirements. However, reaching the same level of integration when adding a third-party manufacturer’s solutions is not always easy or as fully featured as adding one of their own solutions is likely to be. Connecting application specific solutions within and between the packaged workflow systems and the same manufacturer’s hardware and software allows them to create enhanced task and process communication. However, if a third-party developer offers a similar solution, the use of the third-party solution isn’t always as tightly integrated in to the packaged system. So in some cases there can be some trade-offs, and they need to be evaluated as you face them.

While there has been a great deal of development in all of these systems in both classes, the most recent efforts have been focused on workflow automation to enable service providers to maximize their equipment utilization, and to reduce costs and turnaround time. Each of these systems has always had a basic level of automation through the use of a configurable print queue, but that only addresses a small segment of the plant workflow process. Some of these systems support APIs (Application Programming Interfaces) for interconnectivity with other solutions, but this is not necessarily a desirable approach for the mainstream service provider. End users typically need something more visual that doesn’t require programming skills for general task automation. Thus, many workflow developers have started to implement a variety of ‘visual’ plant workflow automation support models, either as a part of the basic packaged system or as a separate add-on module.

These system automation implementations take different forms. However most of them are primarily focused on automating the workflow around their own tasks, modules and products, and have been focused on the systems I identified as Class I above, although there has been a lot of recent activity in the Class II systems as well.

Most of the automation solutions in these classes of products offer, or are starting to offer, task connection and automation. In these cases, a specific workflow task can be connected to another task based on predetermined rules to create a desired action. These can be chained together in a variety of configurations to support different process requirements. In Kodak Prinergy, one of the earlier workflow automation entrants with its RBA (Rules Based Automation), there is support for automation of almost all of the core objects of the Prinergy application as well as extending to some of their other modules such as InSite. In some of the others, just the broader tasks are connected.

So as you can see, more complete workflow functionality and automation are starting to become a standard offering in many of these packaged workflow systems, but what about connecting disparate systems, or extending your workflow beyond these systems to other processes, or to your customer? In the next article we will look at the third class of workflow system, the hybrid system and discuss whether this type of solution address these issues.

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!

You can contact David via email at [email protected].