Discussion

By Erik Nikkanen on Oct 23, 2008

I am not surprised that JDF has not been successful. It is quite normal that attempts at making all encompassing approaches do not work. Especially when done by committees that do not understand the fundamental problems.

The problem is that there is an idea that massive programming can some how overcome poor fundamentals. To obtain effective automation requires capable systems. It requires knowledge of what is physically required. Incapable systems can not be corrected with software.

CIP3/4 as an example, has for a very long time been involved with ink key presetting for presses. It is very good to have a standard method to send information to a press but it is not required. Sending presetting info to presses has already been done for over twenty five years. Presetting industrial equipment has been done very successfully with out the need for a complicated industry standard. It is done every day in manufacturing plants everywhere.

What is critical for automation with respect to setting the press is the accuracy of the presetting information, which the CIP3/4 group has had no interest at all in understanding. Most algorithms now for ink key presetting have errors that can be as high as 40%.

Getting information to the press is not the problem. The problem with respect to automation is the accuracy of the information and the capability of the equipment to utilize it predictably and consistently. These are the areas that need to be addressed.

The same kinds of incapability problems exist in prepress and if never addressed properly, full automation will not happen. More inadequate standards trying to deal with faulty concepts won't be fully successful. Kind of frustrating.

It is normal in the printing industry to shun the physics and embrace the hype. I suspect that JDF was always more hype than substance.

 

By Andy McCourt on Oct 24, 2008

Erik,
Very shrewd observations. JDF = good idea but has attempted to go beyond its limitations into the 'fuzzy' areas where unknown unknowns lurk eh? Bindery for example. Similar to early ICC..."but the numbers match so the colours must be the same!" even when what you saw on one sample was pink and the other was orange. It took them a while to appreciate metamersim, spectral distribution etc.
I think 'dead' is too strong a word for JDF but 'maturing' might be better.
Good debate to have, Rick.

 

By Ralf Schlozer on Oct 24, 2008

Apart from finding videocasts a bit tedious (do you also find yourself googling or checking the weather forecast in a separate browser window while "watching"?) I take it is more a provocative statement than real prediction.

Why should vendors talk about JDF? Do we talk about TCP/IP when we talk about web applications? In the end all we (rather the print service providers) need to know is that they can seamlessly integrate devices, software, processes and stakeholders. JDF/JMF can be that common interface to make the pieces talk to each other. It may not be perfect but I do not see anything else taking its place. The alternative might be proprietary systems, but I hope we should be over that by now.

Ink-presetting is a relatively trivial sub-component of the JDF/JMF concept. We need to move away from a narrow hardware view. The saving potential of seamless integration of all systems (inc. customers) are several times the magnitude of savings you can get on a press. And the market will soon weed out any solution which cannot interface.

 

By Andrew Tribute on Oct 24, 2008

Ralf is absolutely 100% correct on this. This whole ink presetting is something certain people harp on about but in most cases it is not a problem. JDF is enabled in a vast number of systems solutions in various ways, but nobody sees it. JDF has always been about connectivity and communication. It is not something a user buys. It is an enabling technology for the systems suppliers. JDF is alive, very well and a key to most of what you will see at GraphExpo. Rick is doing a good "wind-up" to get attention, which is surprising because he is normally such a quiet and mild person!

 

By Michael Mittelhaus on Oct 24, 2008

I decided not to look at the Video itself, but to rely on what my predecessors said, and by the way: If I want to look at a Video, I might go to MyTube, if I want to have information,I prefer to read it.
Now to the actual point: To ask, wether JDF is dead is a thorough misunderstanding of the concept and the reality. JDF is nothing but the proposal for a common interface for all departments in a print shop. It enables automatic, fast and comprehensive information to go from the CSR and management to prepress, press and postpress and vice versa.
This has little to do with CIP3 data, but much with the passing of actual order information, job preparation, production planning, production feedback, shop floor data collection, post calculation iof jobs and many items more.
The problem: The print shop has to rethink and to reformulate it´s complete workflow, which is a very extensive task. This does take a lot of time and needs qualified people, which are rare , and these people are mostly burdened with a lot of other tasks.
That is the reason why JDF seems to get on relatively slow.
Finally; The fact, that a North-American User Group has recently been setup, shows that JDF is quite alive and progressing

 

By Gary George on Oct 24, 2008

Guys, Rick is not winding anything up, merely stating the facts that are published!

I believe that JDF/JMF is a great enabler as Andrew has stated, but the problem has been in the marketing of the technology, it was sold to us all that it would save us all and provide mass benefits, what it failed to do was show us how and where we could achieve this with the systems we already had in place.

Now this could also be down to the tech support of the companies we bought our software from in not knowing how or where we could benefit or where to enable it in our workflows in order to gain true automation.

The fact remains that it is a communication vehicle so if what it is communicating is wrong or invalid then are we any better off?

There is always a risk in automating every step of a process, yes it has benefits in the cost of staff, but do we then really provide the same level of service, and who then is to blame when it does go horribly wrong.?!

 

By Michael Josefowicz on Oct 24, 2008

I remember going to a presentation on "XML" back in the early 90's. It was hosted by editors involved in SGML - standard graphic mark up language.

Standards are not imposed from on high. They sink roots and then grow from the ground.

It helps make sense of the overnight success that was twenty years in the making. Early adopters, critical mass, competitive advantage, tipping points.

 

By Greg at GMG Consulting on Oct 24, 2008

Ok it is Friday... and Rick video rant on his way to Graph Expo does raise some good points. However those points are aimed at the vendors of hardware and software of product to the industry. It seems to me that automation and integration from a vendor with CIP3..4.or whatever perspective... is too high level and being pushed by vendors rather than pulled by the print providers.

This integration CAPABILITY is really at the print providers level. Like Rick points out there are countless products and processes in the workflow of a print provider. The automation need come at the print provider's level for JDF to succeed. Sooner or later the print provider will stop looking to the technology providers who have been leading them like sheep or as another blogger has posted getting them hooked like addicts. The sooner print providers take control of their own automation and intergration between their disparate manufacturing systems and make it a part of their core competancies the sooner they can reap the benefits of a JDF workflow. Yes that means the print provider MUST become jdf, xml integration experts themselves and stop looking to the "dealers" of technology for all of the answers. Yes that means print providers must have IT people in place to make it happen. They are the ones that should be making the demands to their vendor. Not the other way around.

The problem is that JDF is being pushed by vendors onto the print community. The very same print provider who is struggling with excess capacity and shrinking profit margins. This target audience has not had the vision, IT and financial resources to realize THEY are the ones who must take the responsibilities to integrate these systems with xml/jdf being the glue to put it all together.

So enjoy the show and before you start asking questions of the vendors if the product is JDF/CIP4 compatible. Make sure you have your strategy together so you (the print provider) can tell them what you expect from their product and not the other way around.

 

By Chuck Gehman on Oct 24, 2008

Many good comments.

Rick apparently still thinks JDF is about the hype of a few years ago, when it in fact has evolved into an unbelievably useful and important part of printing technology that pretty much everyone building equipment and software uses today.

JDF no longer needs marketing, nor does it need particularly to be "embraced" by printers because they will get the benefits of the functionality it provides when they buy new hardware and software.

Chuck

 

By Peter Doyle on Oct 24, 2008

The analogy of JDF popularity to the amount of JDF certified products is a poor one. The JDF certification process is expense (I have heard that the cost to the company requesting certification is over $10,000 per product) and more of a marketing gimmick then a technical verification that a product will integrate within a printer’s workflow. Example: wouldn’t it be better for a printer wanting to buy a JDF capable saddle stitcher to obtain a JDF file and then ask the saddle stitcher manufacturers to use the JDF file to automatically set-up the feeders, trimmer and stacker? Shouldn’t the printer also call the manufacturers references for other JDF/JMF integration projects? At the end of the day what does certification prove?

JDF workflows have been slow to be adopted. I am shocked that printers don’t use JDF files to program their flatbed cutters. This should be an easily attained first step. But remember, print has resisted nearly every innovation since Gutenberg including offset, the web press, DTP, CTP, eCommerce, etc. I believe we are dealing with both a cultural and educational challenge.

JDF will be adopted. Integration will occur. Automation will be the solution.

 

By Todd Mason on Oct 24, 2008

Are any of you guys actually printers who have have used JDF systems? If so, how did your company integrate JDF into you work flow?

Todd

 

By Peter Doyle on Oct 24, 2008

Todd,
We used Kodak UpFront to export JDF pre-press, cutting, folding and saddle stitching files. We used these files to automatically set-up a Polar cutter, MBO folder and Muller Martini saddle stitcher.

This process eliminated the need for our pre-press employees to paginate jobs. The labor savings on the machines was also significant. The company (Action Printing)won a CIPPI award in 2003 for this integration.

 

By Rick Littrell on Oct 24, 2008

Great conversation, which is exactly what I wanted. JDF CAN be a great tool and SHOULD be used more extensively. The reality is there are around 27,000 printers in the USA and very few have any significant implementation beyond ink key setting. Many of the posts have so far been from consultants, vendors or past vendor reps (which I am as many of you know), so they are waving the JDF flag for "Motherhood and Apple Pie"...but, the market has not fully embraced the advantages of the automation that JDF can offer. Someone prove it to me beyond a flag raising ceremony. As a point of reference, I have been to about 10 printers within the last 3 months to discuss working with them on some marketing projects that we are involved with, and NONE were willing to promote or implement JDF. None could provide me reasons why they were going to implement. Most said it was too expensive (not sure that is an arguement unless their plan was to throw everything out and start from scratch) or too complex. I always ask them their thoughts about this, just to keep track of implementation and the preception that is in the market. That told me something. They were all small to medium size offset and/or digital shops (<$20,000,000 gross revenue). I know that the number using it out there is larger than ZERO, but it damn sure is not a significant number of implementations in the market. I think it should be, but SOMETHING is holding it back. Many of the reasons have been stated above. What else could that be? Inquiring minds want to know.

 

By Michael Josefowicz on Oct 24, 2008

I'm not familiar with the business model for JDF certification. My impression was that it was an open standard.

At any rate, I think it unreasonable to expect integration to be easy for printers. Even with XML and TCP/IP getting computer systems to talk to each other is still far from a trivial problem.

Meanwhile, does it make sense to expect a significant number of printers to support a specialized JDF integrators on staff. Almost every shop has someone - often from prep - that can get up to conversational knowledge. But specialist integration expertise? Not likely.

Does anyone know of specialized firms - not connected with one vendor - who will work with a Printer's internal expertise to lead integration projects?

Just a thought about the slow rate of adoption: If a printer has unused capacity, why would he/she invest the time/money to increase capacity?

Automation scales to solve high class problems- not enough capacity. Until Printers get to that point, the idea of automating to reduce head count will probably not get traction.

There are some printers who have the capacity problem. But that's the smart and lucky few. And they are probably already are on the automation bandwagon.

 

By Todd Mason on Oct 24, 2008

JDF is a great theory but in reality how much savings will we see? Presetting ink keys is nice. We have presets programed on our presses for automatic sheet size changes already. New binders and folders come with programmable presets. Why would you need a JDF work flow for these?
The only area we see as being applicable is the cutting and ink key setting. Do we need a complicated system for this or do we wait for the technology to mature so that it becomes more user friendly and cheaper to implement?
We are a shop running 600 jobs per month, so we understand the importance of automation and it's role in terms of profitability.

 

By Aaron Hanson on Oct 24, 2008

Speaking from the perspective of someone researching what it would take to implement JDF on any scale, the information publicly available on the practical nuts and bolts of JDF is negligible.

My company is six weeks into the process of getting an associate membership from the CIP4 organization that will allow us to log in to the members' website and theoretically see actual examples.

We are also working with one of our equipment vendors to be allowed access to their JDF SDK to communicate with their software (because their implementation is "unique" and won't work with just any JDF instance). That has been another month-plus process and still no closer to completion.

Maybe it's the print industry in general, but the information and discussions around JDF that can be found online are rather top-heavy with CTOs, CMOs and the like, but completely lacking in the geeks who are excited about making the most out of the latest innovation.

To make a long story short (too late), an "open standard" that no one uses "openly" does not lend itself to widespread adoption by companies unable to devote the manpower and/and funds to a full-scale implementation.

 

By Adam Dewitz on Oct 24, 2008

@Erik as other have already said, ink key presetting is a only a small subset of what JDF can do and what it should be used for. If you're only using JSF to preset ink keys you're missing out on opportunities to streamline business processes and do detailed analysis of operational data. Measurement drives behavior. Automated data collection is an important key to understanding what happens during the production of printed products.

@Ralf I don't think comparing JDF to TCP/IP is appropriate. TCP/IP is a set of very low level standardized communication protocols (RFC 1122). A more appropriate comparison in Web application development might be XML applications, JSON (JavaScript Object Notation) or other data-interchange formats. I agree with your premise with all JDF implementers need to know "is that they can seamlessly integrate devices, software, processes and stakeholders. JDF/JMF can be that common interface to make the pieces talk to each other." (BTW you need to have your IT department set up with a bigger monitor or dual monitors so you can watch video, google AND get some work done ;)

@Andrew I agree that JDF is crucial to systems suppliers. It's also crucial to workflow engineers within printing companies. Some of the most successful companies to implement Web-enabled workflows have built their own Web applications. Printing companies that to do this need need data exchange standards and specifications like JDF. See Greg's comment.

@Greg at GMG Consulting 1++. Agree 100%.

@Chuck Gehman You're right about the marketing hype. Vendors should be promoting and spending their marketing efforts on show interoperability between disparate systems. Maybe during or after Graph Expo we can talk about how Mimeo is using JDF in its workflow. I'm sure your team has some great examples that the industry could benefit from.

@Peter Doyle I think the JDF certification process was a way to move JDF away from the hype we saw at the 04/05 trade shows. With the Interoperability Conformance Specifications CIP4 developed I see certification as an added bonus. If I was purchasing workflow technology I would ask about a products adherence to the Interoperability Conformance Specifications.

@Michael Josefowicz JDF is an open specification (CIP4 calls it an industry standard) managed by CIP4, a not-for-profit association of industry vendors, integrators and print service providers. Certification is administered by PIA/GATF and is based on passing parts of the Interoperability Conformance Specifications developed by CIP4. There is a fee associated with having a product certified.

You're right that most printing companies don't need or can't afford to have specialized JDF integrators on staff. But they should have at least one person on staff that is technology savvy, has at least a basic understanding of emerging technologies. I was talking to Kevin Keane a couple weeks ago about the grasp of emerging technologies in this industry and the broader communications industry. While their is no evidence to support this, we both agree that the most successful companies in this industry are those that have someone on staff that job to be technologist - be the person that watches emerging technologies - to be the one person skunk works. (BTW these are the most important people to have at Graph Expo next week.)

@Todd Mason You bring point. Shops that have constrained their product offerings to a catalog of products can probably get by with using programmable presets. Many shops still operate as job shops - they will produce anything that comes in the door and that probably increasing in this economy. Programmable presets don't work when you have a moving target. In both scenarios JDF-enabled MIS and production equipment will benefit from having more data which can be used to make better business decisions.

 

By Erik Nikkanen on Oct 24, 2008

Is JDF for automation or only for communication of data?

The idea that ink key setting is trivial in terms of JDF automation is a strange comment. Well I guess that after all this time, it has not worked. A loose definition of automation for ink setting would be a system that does not require the operator to adjust the inks after the preset. Since the operators still do, one can not call what exists as being automated.

I have heard this for twenty five years. People say that something in printing is good enough. The real point is that they have no idea what is required to make it better and have no passion to make it better. Would one want a consultant who thinks that what you have is good enough? Not getting to colour right away is trivial and don't worry about it.

It is always interesting to hear the "Big Picture" view points from people who have little interest in addressing the "small picture" problems that prevent true automation being obtained daily in printing plants.

There are specific problems that prevent obtaining the desired automated performance and if not addressed in specific ways, they will always be a constraint and a road block to any improvement in a process. But they are all trivial so don't worry.

With any high level automation the requirement is that the low level actions must be very very consistent and predictable. Folders and cutters are more relatively consistent and therefore presetting of any kind would help. The fact that presetting helps is not due to JDF but due to the predictability of these process when set to specific settings.

Printing presses could be made much more predictable but that is considered as trivial. Face the fact. If one is not interested in getting the press predictable and consistent, then it is a cruel joke to let people think that automation in the pressroom will be obtained by JDF.

 

By Michael Josefowicz on Oct 24, 2008

@Adam,
Nice responses.

You mention"workflow engineers." I wonder how many printing companies have someone on their staff who sees themselves that way? I bet not many.

The problem is that whoever does that job is usually paid to get today's work out the door. They don't have the time or the incentives to take a view from 30,000 feet.

A crtical function that is often overlooked is the process to acquire new customers. Once that work flow is defined, it's possible to measure customer acquisition costs and life time customer value. The measure, then manage principle then comes into play.

If you can manage customer acquisition, you can solve the over capacity problem. When you solve the over capacity problem, most of the other solutions tend to fall into place.

 

By Michael Josefowicz on Oct 24, 2008

@Erick,

I'm no expert in presses, but the points you make make some sense to me.

If the underlying process is not stable and requires constant feedback and adjustment to keep it under control, the choice is either to make the process stable or build feedback loops that make corrections in real time. My sense is that most of the focus has been on the second.

In that context,it seems to me that JDF, so far, is about communication. Automation needs predictable actions based on incoming information and a feedback loop to ensure the outcome stays within tolerances.

It's why, except through a web interface, that customer acquisition can not be automated. But standards, clear process and real time feedback loops can still yield significant improvements, even without automation.

 

By Erik Nikkanen on Oct 25, 2008

Michael,

Yes, one can make improvements but the goal has been stated as automating the process.

One does not need feedback to automate. This is a misconception regarding automation. One needs predictability and consistency. This can be done and is done all the time without feedback systems. Stepping or servo motors can drive mechanical systems to accurately position components. Feedbacks are not always needed because the precision of movement is already built into the stepping motor, etc. Feedback might be added for confirmation or for very critical needs but it really depends on the application.

The problem in the press is that one can accurately set the position of the ink key but the position of the ink key does not represent the actual amount of ink that is being fed into the roller train. Even on modern offset presses, there is NO mechanical component that can be set that is directly related to the amount of ink being fed. Without this direct relationship, you can not automate without an expensive feedback system.

A feedback system is not the desired choice because it has its own problems, is slow to respond and is expensive.

An ink key is quite good at metering ink onto the ink fountain roller but only about a 1/4 of the ink metered onto the ink fountain roller actually goes into the press. The point of greatest ink feed variation is at the transfer point of ink by the ductor. The ink transferred at this point is affected by changes in water setting, press speed, temperature, etc. Fix the transfer problem and then the system becomes much more capable of being automated by having a direct relationship between ink key position and ink feed.

The other important point is that ink feed does not have to be really accurate to stay within the tolerance required. For commercial print, if one says that the tolerance is +/- 0.05 density points, that represents about a +/- 8% of ink feed rate. A total range of 16% of ink feed.

This quite large operating window means that with a reasonably capable ink feed such as the existing ink fountain and a positive ink transfer method, in tolerance control can be ensured without the need for feedback systems.

Add on top of that capability, an accurate presetting algorithm, then one has basically a keyless system since there would be no need to adjust the ink keys at the start and during the run. The press would start and go directly and very quickly to the preset density targets.

Automating the printing process can be done. It is not trivial. It is crucial.

 

By Michael Josefowicz on Oct 25, 2008

Erik-
Good explanation of the issues in the printing process.

If you are correct, sooner or later someone is going to use your insights to make much better, faster, cheaper presses for the bottom of the pyramid and emerging markets. In the mature markets, I think the legacy physical and business infrastructure is not going to change any time soon.

It would be great to be able to have this kind of discussion about the full process of the business of print - from customer acquisition to to printed product to money in the bank.

From that perspective print manufacturing itself is actually remarkably under control. In US/Europe/Japan mature markets, the greatest improvements are going to be finding and fixing inefficiencies in the business processes.

IMHO, Standards based, efficient communication between machines is easy compared to standards based, efficient communication between people. It's only when you have the latter that you can profitably implement the former.

 

By Erik Nikkanen on Oct 26, 2008

Michael,

Besides the technical issues with obtaining a more automated presetting and consistent print density capability is the affect that has on the business of printing.

When one can eliminate the variation of print density in the process and make it predictable this requires less skill on the part of the operator. There may not be a labour shortage in the industry but there is probably a skill shortage. Controlling density on press is one of the most difficult problems an operator must face. Designing that problem out of the process reduces the requirement for expensive skilled and talented operators. Just good operators will do.

Much of the waste in printing is due to transients in colour, which can overshoot the target, as the operator makes educated guesses on how much to adjust. With a press that has accurate presetting and a capable ink delivery system, the print will converge directly to the target densities with minimum time and scrap. This affects capacity and cost of scrap. This directly affect the bottom line margin.

Consistency and predictability in print is one measure of quality. Quality that customers can see.

When one corrects the low level automation problems, the higher level systems (JDF) will more likely meet their potential.

My influence has come from the Japanese manufacturing concepts. The Japanese were never that much interested in high level computerized systems but tried to do very much at the low levels of the process. Great effort to make processes predictable and consistent and with manufacturing instructions simple and visual. Surprisingly low tech. This is what Lean is working towards.

 

By Ralf Schlozer on Oct 27, 2008

Erik, you are right about the problems on getting the colour right & stable on a press - and offset is an especially bad example of a process which is not completely understood in its details and difficult to handle. There is a R&D association in Germany sponsored by all manufacturers (Forschungsgesellschaft Druckmaschinen - FGD) and you might get in contact with them. But that is a different discussion.
JDF however is only partially about ink-preset. You are right that CIP3 started mainly as a means to preset inks. However JDF (CIP4) is about communication as prerequisite to automate - and to automate all/most/many processes within and around a printing company.

I am not sure if asking printers whether they use JDF helps. They might be using JDF without knowing it. Talking to printers I find very few which have any dedicated IT specialists. I just talked to a guy setting up MIS systems for printers and usually he spends the first day(s) sorting out the network and updating Windows on the boss' PC.
For the majority of shops I do not see them getting too IT savvy. Few are and they can differentiate and reap the benefits.
For the sake of the other 95% I believe that printers should not be required to get into the nitty gritty of JDF. If they need to, the software providers did not do their homework. Again, I do not care what is under the hood of my browser as long I can get the post up the WTT with a click. (non-automated way would be typing this, printing & mailing it and having somebody retype and put it up the message board).

 

By Michael Josefowicz on Oct 27, 2008

Ralf-
It's been said that there are no bad users, only bad software.

I think much of the discussion about JDF is similar to the way the industry talks about "VDP" or "Transpromo". These are words that make sense to the people who are selling, but not the people who are buying.

The reaction of sellers is often to "educate" the buyer. That's ok for experts and early adopters. But "education" does not work for an innovation to scale. It's a little like trying to solve a "product problem" with advertising/marketing.

As you point out, the issue for most people is not what JDF/VDP/Transpromo is, but how can it help the user do what they already want to do. . but easier and faster.

My bet is that as printers see how JDF could give them real time information of exactly what is happening in their shop, they might find it much more compelling.

It could make it easy to answer questions like" how much time does it take to do X? how much does Y pressman produce vs Z pressman? what kinds of jobs are produced more quickly than others?

As we've seen from Web 2.0, the new value created by communication systems is not merely the ability to make top down communication easier,(tell machines what to do.) The new thing is to get information from the interactions the system enables (get real time information about what the machines are doing.)

 

By Todd Mason on Oct 27, 2008

Guys, With all due respect none of you have convinced me that a JDF work flow will make our company more productive. . You spent a lot of time talking about ink presets. JDF is not necessary for this. As for the moving target and automated set up, again, we run 600 jobs a month. Every job is a moving target .It is my job as manager to direct those as profitably as possible. I don't do this by sitting behind my desk looking at my JDF work flow to determine what job to run next or who is faster. I do this by interacting with the work flow and the people who are doing the work. on the floor at that time. There is no automation that can replace this interaction and attention.
As for who is faster, better etc., as a manager it is my job to know my employees. If I need a "SYSTEM" to tell me how they are doing, then I am not doing my job. Some times we rely on a system to do the nasty work for us, such as to discipline an employee or let some one go who is not the right fit for the position. It can easily become crutch to enable a weak manager to keep their job. I understand that numbers and statistics don't lie. However, they don't always tell the whole truth either.
On the color shift issue, we have two HP Indigo presses and they also show color drift. The pressman occasionally needs to color adjust this automated system.
There will alway need to be operator intervention and expertise. Maybe someday he or she will only be there to fix the machine when it breaks.
On the other hand, a JDF work flow may help Administration track costs more efficiently and help determine where and how to invest, place pricing and increase profitability. Again, do we really need an all out JDF work flow to do this, or just a good management information system and people (who understand the printing process) to correlate the information into profit?
Todd

 

By Ralf Schlozer on Oct 27, 2008

Todd,
that is the point. You are not buying "JDF" (it is a specification, not a product) nor a JDF workflow.
You want the information on who is performing well in the company, what job is profitable, where the waste is ,...
A workflow should be there to free up the time for you to speak to people - a good workflow should help spend less time at the desk.
That is what you should ask software vendors for - not JDF inside.

Now the circus of devices, software pieces, web, MIS, ... is getting ever more complex. No vendor can cover all, so lots of systems need to comunicate. JDF is what might drive that integration - but this is a discussion for geeks. If vendors get this point I am happy when noone talks about JDF.

 

By Michael Josefowicz on Oct 27, 2008

Todd-
I think you hit the nail on the head, when you say

"On the other hand, a JDF work flow may help Administration track costs more efficiently and help determine where and how to invest, place pricing and increase profitability.

Again, do we really need an all out JDF work flow to do this, or just a good management information system and people (who understand the printing process) to correlate the information into profit?"

I vote for 1. people to turn information into good decisions and 2. a good enough MIS system. No further tech necessary. Unless it makes it faster and better today.

If JDF helps, great. If not, most people don't need it. IMHO

 

By Michael Josefowicz on Oct 27, 2008

So, the value prop for thinking about whether JDF is important to you might be:

Use these standards, using this no install software, to get the information you need fast enough to make the best decisions that will make your business more profitable tomorrow.

Or...
get the data you need, in a simple to see, usable form to easily move from "seat of the pants" to evidence based decision making.

 

By Erik Nikkanen on Oct 27, 2008

Michael, Ralf and Todd,

The basic problem with MIS or any information or data gathering system is that the information might not be of value unless one has some knowledge about what to do with it. Actually if one had the knowledge then one does not need a lot of data. Just enough to start with and then to confirm an improvement effort. IMO data gathering is over rated.

I understand the basic problem of density control and I understand it much better than the FGD. I know how to analyse it and I know how to correct it.

There is a timely article on WTT about an effort by Quad Graphics to have Goss retrofit one Sunday press with Digital Inkers. The link to this article is below.

http://members.whattheythink.com/news/newslink.cfm?id=34323

The retrofit will be the replacement of the open ink fountains for the Digirail digital inkers developed by Goss. These inkers are positive ink feed devices. The hope Quad Graphics has is that these accurate ink feed devices will make improvements to presetting and have quicker response to colour control.

I have knowledge on how this system will work even if I don't have the data from their tests that they will run in 2009. I have a very good idea because I have developed the science to analyse these problems, have done testing and have done a lot of thinking about it.

What I expect will be the results of the testing will be that the response to changes in colour will be much slower with the digital inker than with the open ink fountains that Quad has now. This is because open ink fountains have a quite fast response while digital inkers, that dispense ink on the ink fountain roller, have a very slow response. I have referred to this problem in my 1997 TAGA paper and Goss has also described this problem in, I think, a 1998 TAGA paper.

Quad will probably find that the presetting is actually a bit more off with the digital inkers than with the open ink fountain design. This is a bit too complicated to explain why here but it is basically that a positive ink feed accurately delivers the errors in the ink key presetting algorithm while the open ink fountain/ductor combination does not. Although a big advantage of the digital inkers is the inherent zero setting capability.

Of course the Digirail is expensive but my simple Ink Transfer Blade (ITB) does basically what the digital inker does. It delivers a positive volumetric feed of ink to the roller train. The only difference is that the ITB would be a fraction of the cost, can be used on web or sheetfed presses which have high viscosity ink, will respond faster than the digital inker as it is configured now and will be more independent of changes in temperature, and water settings. Actually the ITB would improve the performance of the digital inker if use in conjunction with it.

Goss and other press manufacturers were never interested in the ITB. Quad and other printers were never interested in the ITB. At this time the ITB is not a product since it is my view that a press manufacturer would have to be interested in developing it. I am not a manufacturer.

Quad Graphics does not think that presetting and density control is trivial, since they are going to the great effort and cost to replace their existing open ink fountains. They will only be partially satisfied. The Digirails system will give them more consistency on the run but it will not meet their expectations of getting to colour extremely quickly. Maybe marginally better than what they have but certainly not as good as it could be.

But Quad could have reached their full expectations many years ago, if they would have been more responsive to my efforts to interest them, over the last seven years, in density control knowledge and technical approaches.

I hope one can see that the trend, as slow as it is, is to positive ink feeds. That will be the only route to true automation. What has been lacking is the knowledge of what is possible. It is very difficult to see what is possible in data alone.

 

By Michael Josefowicz on Oct 28, 2008

Very, very Nice point.

Data without a hypothesis is mostly noise. It's almost impossible to earn new knowledge from noise. The trick is an appropriate signal to noise ratio for incoming data.

Your post is great because you have used your science to create a hypothesis that can be proved or disproved by evidence.

It would great if someone from WTT could follow up with Quad to see if your predictions turn out to be accurate. If they are, then we might be on the road to creating some new useful knowledge for all of us.

I agree with your comment that
"Actually if one had the knowledge then one does not need a lot of data. Just enough to start with and then to confirm an improvement effort."

One doesn't need a lot of data. But one does need the right data, that either proves or disproves a carefully constructed hypothesis.

That's the core of the scientific method. Then using that data to make small, inexpensive improvements that create significant positive changes in outcome is at the core of the engineering method.

My little soapbox is that the sales process is also amenable to an engineering approach based on the science of communication.

 

By Rick Littrell on Oct 30, 2008

great discussion and points made by all. After returning from Graph Expo and reflecting on what I saw, I determined that JDF is not dead, just confused. The issues it appears is that few have clearly identified AND demonstrated the value. I know it is there, but you have to work very hard to uncover it. Additionally, I think by CIP4 organization says that they are now using "code word" for JDF, will further confuse the issue. We need the interfacing of different systems to be based on standards and not require custom development. I know that JDF is not an official standard, but it is as close as we have to this integration requirement that our industry has. I have some further thoughts that I shared on my latest blog at http://www.magicomm.biz/blog/jdf-is-kinda-not-dead

 

By George Alexander on Oct 30, 2008

Having just gotten back from GraphExpo, and having seen quite a bit of JDF activity there, I conclude that JDF is not dead. But it does need some serious PR help.

Still, JDF is the only real hope for automating the majority of printers—and printers must automate in order to survive. If they don’t automate, they will be underpriced by more efficient printers (mostly larger ones) that do automate.

If there are readers who are interested in more on this topic, I posted an editorial about it at Beyond-Print.net:
http://www.beyond-print.de/site/content/en/channel_news/news_0566.html

 

By Chris Heric on Nov 04, 2008

I think JDF and it's status is really more dependent upon the nature of how people purchase hardware and software solutions. Many print facilities in the times of budget cutting are not able to commit to replacing or updating numerous key hardware modules in order to attain a JDF workflow.

Making a JDF solution that only talks between two JDF enabled production roles often does not make sense, so many people are more playing a "Wait and See" attitude, and will wait until their old non-JDF capable equipment dies a slow death before they look at replacing it just for JDF benefits.

So, is JDF pervasive? Not yet.
Is JDF ready? I think so, and it is being improved upon every day.
Is JDF dead just because people have not replaced non-JDF capable devices yet? No. (grin)

In reality, I see the growth and development of JDF as something that will happen when the time is right. When people begin to replace their older equipment with new, they will almost unknowingly add JDF capabilities to more production roles in their facilities. Eventually, they will have enough pieces of their equipment JDF enabled to stitch together a real run at JDF without breaking the bank.

Having to replace 10 pieces of hardware or software in your facility is a difficult ROI pill to swallow at one time, and hence people just do not.

Waking up one morning however, and seeing "Hey, I have 8 JDF enabled devices now... how did that happen over the past few years?" is where I think we will begin to see the real adoption wave hit the industry.

My 2¢ and I am sticking to it! (grin)

Chris

 

By Henk Gianotten on Nov 06, 2008

I enjoyed reading all those comments on JDF. JDF is extremely important and needed by our industry. Process optimization can only be done if international standards are used. PDF is such a standard and well known because our customers need to provide those PDF's. W2P is only possible if we agree on standards. JDF is (for most customers) unknown. But not dead. Not at all.
One observation on the 2 video's from the show:
Could you hear what they said? In this case I prefer a transcript.

 

By Scott Marienthal on Nov 12, 2008

Great thread guys!

I see one recurring point for those who have either given up on the promise of JDF/JMF entirely or remain in the ‘case not proven’ camp. And that point is – ACCURACY or lack thereof. The variability of ink key settings, the persistent need for operators to overrule the JDF supplied data etc etc.

This is a classic case of shooting the messenger.

What we’ve found in 100’s of JDF implementations around the world is that true automation exposes the weaknesses of a printing business in stark terms and can shine a very bright light on any knowledge gaps that exist in their commercial departments. Some printers simply do not want to know that for years they may have been working with inaccurate data and I understand how unsettling that would be.

A well implemented MIS will fix that problem forever but most MIS’s in use today have NOT been well implemented. They are no more than glorified administration systems, producing documentation and carrying out some basic arithmetical tasks and analysis.

That is NOT a Management Information System.

The MIS is the natural birthplace of JDF and the obvious place to store the JMF feedback but this means that the estimate must be accurate right from the outset, even before you win the job, and that dramatically increases the responsibility of the estimator to get it right.

If you’ve got a team of good estimators then you’re OK. If you don’t or if you want to involve other staff and even customers in the estimating process, you have to rethink how you operate in this most crucial phase of your workflow.

At Graph Expo 08, we were swamped by printers who understand this and recognize that true automation has to be built upon a solid foundation.

 

By Michael Josefowicz on Nov 12, 2008

Scott-
I think you've hit the nail on the head. One problem is the branding and perception of MIS as the technical solution to an organizational problem.

If a process manager(in a printing company?) doesn't have a crystal clear view of the process, more technology is just "paving over cow paths".

IMHO, your focus on estimating is also exactly right. That's the place where production steps and costs have to be measured. Unfortunately in many printing firms, that is left to rule of thumb and outdated price lists. In legacy workflows, often most of the energy is invested in a "discussion" between a saleperson and an owner about "what can we get for this?"