BY MARK SMITH
Technology Editor
There were no mysterious bulges, but maybe the occasional exacerbated expression and a testy moment or two during "The Great Debate: JDF—Reality or Hype?" session at Executive Outlook 2004 in Chicago. This "debate" between Frank Romano, industry consultant and Professor Emeritus at Rochester Institute of Technology, and James Harvey, executive director of CIP4, actually started with an exchange of opinion pieces published by OnDemandJournal.com.
As entertaining as these exchanges have been, Harvey says he's not interested in repeating the debate since the questions have been asked and answered. He sees more value in the industry moving on to discussing real-world implementation stories and lessons learned by the pioneers.
The problem is, much about JDF (Job Definition Format) is still a work in progress and the experiences of early adopters are only starting to trickle out. This ties into the session's title and one of the concerns raised by Romano—that proponents of JDF often don't clearly distinguish between the reality of what is practical today versus the potential of the technology. He also believes the concept of CIM is being incorrectly equated with JDF implementation.
The term computer-integrated manufacturing (CIM) has been borrowed from other industries because of the notoriety it gained as a business philosophy. In some ways, it doesn't project the right connotation for process automation in the printing process, though.
In broad terms, the automation concept being debated starts with job information captured electronically up front so it can be passed along the workflow as digital data that is used to direct production steps. JDF-enabled workflow components (hardware and software) can also generate process data—such as start/stop times, counts, operating speeds or, in the case of prepress systems/RIPs, color information for ink-key presetting—for consumption, most often by MIS applications.
JDF provides a standardized language and framework for communicating job information and defining process operations.
Romano sums up the current state of affairs by saying "JDF is a good idea that is presented badly. I am not anti-JDF, but there are real impediments to its successful implementation in multi-supplier (print production) environments, which is most of them." JDF is not plug-and-play, and this industry doesn't have an encouraging track record when it comes to implementing standards, he adds.
The real payoff, Romano says, is in the broader concept of CIM, which the industry already has been adapting variations of for years—without JDF.
"Competitive workflows, such as CIP3/PPF, already work. True, they do not do all of what JDF promises, but they automate a major part of the production workflow and provide a tangible benefit," he argues. "A digital printer with online binding can take a file and produce a finished product in one automated system, and can do that without JDF."
JDF Will be Everywhere
And yet, the industry pundit says he is not suggesting printers pursue CIM without JDF going forward. "It will be in everything," he acknowledges. "However, just because every system will be JDF-enabled does not mean that they will (automatically) talk to one another.
"If you acquire a complete prepress/press/postpress system from Heidelberg today, JDF works like a charm. It is the only company that makes every part (of the workflow). If you acquire a MAN Roland press, Agfa prepress system and other PrintCity components, that system will also work very well," Romano says.
"But most printers have older prepress, press and postpress equipment. Printers also have older MIS and shop-floor systems. It may be that some legacy equipment will never be integrated," he asserts.
There are additional fine points to Romano's argument that will be covered later.
One of the main points Harvey has made in response to this assessment is that JDF implementation is not an all-or-nothing proposition. Pioneering printers are analyzing their workflows to identify inefficiencies while also checking the JDF readiness of current components of their production infrastructures, he says. They are finding that even limited applications can pay worthwhile dividends and lay the groundwork for future end-to-end JDF integration, the CIP4 exec reports.
"It's a disservice to the industry to pretend there isn't any answer (for process integration) just because there isn't a single and universal answer that fits all workflows," Harvey argues.
He freely acknowledges that CIM existed before the advent of JDF and says the specification should be viewed as a tool that facilitates process automation. Having a standardized framework makes integration more affordable and achievable by lowering the barrier to implementation.
Harvey contends that significant progress already has been made toward delivering on JDF's promise. "More than 400 pairings of products have been successfully tested at CIP4 interoperability events and NGP Partners advertises 150 successful pairings," he points out. "As of October 2004, there are 161 products and services listed in the CIP4 'JDF Marketplace' (reference guide). In addition to those listed, CIP4 is aware of at least 25 other companies providing JDF solutions, most of which are smaller MIS and software companies.
"JDF is for multi-vendor environments," the CIP4 director adds. "That's the whole point of JDF."
Solutions are also being developed to address the issue of legacy equipment, Harvey says. For machines that already have electronic controls, one option is "bridge software" or JDF controllers that can act as translators between the JDF workflow and an existing proprietary control system. DMIs (direct machine interfaces), including solutions from third-party vendors, can also tap into these controls to capture performance data.
Off-line shop floor data collection units can be a fall-back solution for any workflow component, even manual labor, to enable a level of digital integration. Such units could display the electronic job ticket and enable the operator to key in job data, such as start/stop times, final counts, waste numbers, etc.
Going Back to Go Forward
Since JDF grew out of the CIP3/PPF initiative, it's reasonable to expect solutions for backward compatibility and/or upgrading to JDF support from vendors that implemented the earlier technology. Backward compatibility with the current level of functionality should also be maintainable as the JDF specification is refined with future version releases.
All of this should be possible from a technical standpoint, but Romano also suggests the possibility of true openness conflicting with a vendor's marketing objectives. He's right in saying the industry has a questionable record when it comes to "standards"—formal or de facto. There is reason to hope for a better outcome this time, however.
At its heart, JDF is simply an open, XML-based data format. It facilitates the transfer of actionable information between workflow components. The specification does allow for custom tagging, but still within the JDF/XML standard structure. This works against any vendor trying to make its implementation a pseudo proprietary solution, since translation should still be possible—if one wants to put in the effort.
The specification is flexible by design to give vendors and users the opportunity to optimize its implementation for their particular needs. It does not, as a consequence, provide automatic plug-and-play connectivity, which Romano points out. However, efforts are under way to establish a baseline of plug-and-play functionality.
When coordination is required between vendors, JDF provides a common framework and language that should greatly simplify the process. In addition, work done to link prepress system A with a press from manufacturer B, for example, can be leveraged to link with presses from manufacturers C, D and so on. The converse also holds true.
The most efficient solution, in this case, would be for all prepress systems to write the same data in the same manner so each press manufacturer would only have to work out one translation for the data structure. That's the idea behind Interoperability Conformance Specifications (ICS). ICS documents are subsets of the broader JDF specification that define a standard "how-to" method for connecting workflow components. They define a set of data to be written and read by corresponding components in order for them to be judged "JDF-compliant."
CIP4 has already published a "Base ICS," which sets minimum requirements for all JDF-enabled equipment and software, and the "MIS ICS," which defines interoperability requirements for communication between MIS solutions and all stages of production equipment. Higher level ICS interfaces are being developed for specific process steps, such as MIS to prepress, conventional printing-sheetfed, binding and digital printing.
In addition, the Graphic Arts Technical Foundation (GATF) has been charged with developing and administering JDF-enabled applications and product testing under a certification program. The program is to be based on ICS documents and will allow certified products to be marked with an official logo.
While it may not be completely analogous, one way to think of the interoperability question is akin to Web publishing and its data formats. Much—but admittedly not all—of the Internet is based around open data formats, including XML or its predecessor, SGML. Yet, one's user experience can vary dramatically depending on the browser (Internet Explorer, Netscape Navigator, Apple Safari, etc.) and computer platform (Windows or Mac). Certain pages may not display properly or at all, and can even crash a browser.
It is possible to achieve an acceptable user experience across all platforms, but it takes work and repeat testing. In some cases, tradeoffs may be required between site functionality and compatibility.
One of the other issues raised by Romano is the assertion that no one has shown a real ROI for JDF workflows. In the case studies that have been cited, JDF has been implemented as part of a larger workflow overhaul that generally has included going computer-to-plate (CTP). And that's were the savings were realized, he argues.
"They say that JDF will cut paperwork, save time and make workflows more efficient. Existing workflows already provide much of this," Romano adds.
Harvey counters that the reports of savings are coming directly from early adopters—the printers themselves. He adds that the way individual printers calculate an ROI, as well as address other issues such as legacy systems, will vary depending on the particulars of their operations.
The JDF proponent likens the case for its adoption to printers calculating an ROI for moving into digital printing. Variables that may figure into the latter equation include markets served, existing production environment, demand for customization/personalization, etc. "There is no single, universal answer," Harvey asserts.
Where Does the Line Fall?
Adoption of CTP may be an even better model for JDF's future, although the line between the two does sometimes get blurred, as Romano points out. Just a few short years ago, debate raged about the ROI for digital platemaking and how it should be calculated. Claims were made about ill-defined gains from implementing a digital workflow.
Today, CTP is the accepted norm, even though a fair percentage of shops have yet to make the investment.
Romano makes a very valid point. Care should be taken in determining the amount of return that should be credited rightfully and strictly to JDF. At the same time, however, it's also important to have a clear understanding of the "investment" part of the equation before dismissing ROI claims.
To use the industry pundit's own words, "You cannot buy JDF. You buy products that apply JDF."
As an enabler of process automation, JDF/JMF (Job Messaging Format) support becomes an integral capability in workflow components, be they hardware or software. Vendors obviously stand to gain financially from implementing JDF as an optional (extra cost) add-on module, but competitive pressure may dictate that connectivity to come standard. Even if it is offered as an add-on, what difference is there in buying ink-key presetting, for example, enabled by JDF versus earlier technology (most likely CIP3/PPF) on a new press?
Harvey contends vendors can reap other benefits from implementing JDF beyond the cynical notion of just gaining "something new to sell." By providing a language that all developers can share, "they can use JDF over the long haul to lower the cost of customer support, system maintenance and upgrades, training, installation and so on. And if they can lower their costs, they too can improve net profits, even if pricing and sales were to remain flat," he explains.
The industry needs a clear picture of what the costs will be in implementing a JDF-enabled workflow before any conclusions can be drawn about an ROI.
"I've heard of seven figure company-wide initiatives, but I've also heard of JDF-enabled implementations completed for as little as $50,000," Harvey reports. "What I haven't heard from any printer or prepress shop is that the investment wasn't recovered." Most report achieving a breakeven on JDF-related investments in anywhere from six to 18 months, he says.
Yet another way to think about the ROI is in terms of tracking costs. Printing operations are broadly stereotyped as not having a clear picture of their costs. For this reason, the financial case for JDF ties into the ROI for implementing a comprehensive computer management system/MIS. A central advantage of JDF is the ability of process components to report back performance data, but a company has to be in a position to capitalize on the data that it captures.
With industry margins being so tight, it won't take much of a cost savings for JDF to have a noticeable impact on the bottom line. Accurately judging those savings requires first getting a good accounting of costs.
The concept of production being driven by digital data raises two more concerns, Romano says. The first is the need to accurately capture proper job information, or meta-data, before a job moves into production. "There is dispute as to who will do this—the creative person, planner, estimator, salesperson or customer service rep." Most customers don't have a good track record with even just providing print-ready applications or PDF files, he adds.
Romano is also troubled by the talk of "lights out" manufacturing being the ultimate extension of CIM. The more automated the printing process becomes, the less differentiation—or value add—print buyers will perceive in individual shops, he believes.
Process automation is not synonymous with process or product standardization, Harvey counters. JDF merely provides data that printers can act upon as they see fit.
"Still, it is true that nearly every printer using JDF that I have talked to includes reduced labor cost among the top benefits they've realized. It's not 'lights out' manufacturing, but printers seem to be putting a priority on reducing the cost of labor," Harvey says.
The answer to how job data is initially captured ties in with Romano's point about customer-supplied files. There has been similar debate about the merits of having customers provide PDF versus native application files.
Regardless of how the job data is captured, it makes sense to include a job review, or quality control check, before production is initiated. At that point (but preferably before then), there's nothing stopping a printer from suggesting production alternatives. Job data can always be adjusted even if it is received automatically.
Some printers are already envisioning new opportunities for software programs to automatically generate alternatives based on parameters such as a plant's capabilities, paper stock inventories, etc. Adjustments that optimize a piece for production or optional upgrades could be suggested in a fashion not unlike how online airline reservation systems offer ticketing options based on number of connections, departure times, carrier, etc.
Every facet of the digital revolution has redefined the print buyer/supplier relationship to some extent. Opportunities to add value on the front end (premedia) have continually migrated further upstream as customers have taken on more "production" responsibilities. Consultative selling has become an abused term, but printers do need to think beyond process-centric terms in how they position and differentiate their companies.
CIM/JDF doesn't inherently make print any more of a commodity than it already is. It simply provides an opportunity for printers to boost efficiency and improve communications.
As a final thought, Romano says the industry still needs more education and training on JDF. Unfortunately, the evangelists are more intent on selling the concept than enabling people to reach their own conclusions, he contends.
A growing wealth of resources is being offered to all segments of the industry interested in learning more about JDF, Harvey asserts. CIP4's Website (www.cip4.org) serves as JDF central, offering background information, white papers, the "JDF Marketplace" product catalog and ICS documents as downloads, along with versions of the specification itself.
In addition, the organization has teamed up with IPA, the Association of Graphic Solutions Providers, to offer the "JDF Expert Certificate" training program. This program is comprised of 13 separate training modules and concludes with a final examination for participants interested in earning a certificate.
The bottom line: JDF is not a magic cure for all that ails the printing industry. Nor is it a conspiracy designed to drive printers to buy all new equipment for their plants.
- Places:
- Chicago