Hem
Partner & utvecklingsprogram
Nyhetsbrev
Login (Customer / Press)
Search Hiflex:

Denna sida finns ej tillgänlig på 'Svenska'. Därför visas den engelska versionen.:
Interview: HIFLEX Pressmore info
September 12, 2005 - In speaking with printers from Canada, attending Print 05, a few spoke about a small German-based software company called HiFlex, which develops Management Information Systems (MIS). These printers suggested that HiFlex’s JDF-based software is two to three years ahead of competing systems. PrintAction spoke with HiFlex’s CEO, Stefan Reichhart, and president, Mark Anderson, to find out where this company came from and where it is heading.

Hiflex's Mark Anderson and Stefan Reichhart  

Almost every press manufacturer here at Print 05 has in some way mentioned integration with HiFlex MIS software. Why is there so much buzz around HiFlex?
Mark Anderson: There are two reasons. One is that we are very advanced in JDF and the internal architecture of that software is very closely modeled on the JDF schema. Because internally we work on the JDF model, it is very easy for us to produce JDF data to drive finishing devices, prepress devices, etc., etc. That is primary the primary reason.

Why are people suggesting that HiFlex is two or three years ahead of other MIS systems?
MA: A lot of the other MIS products on the market underlying architecture are quite old. A lot of them didn’t take JDF as a very serious technology so they waited for two or three years until it was proven before they started development and secondly they have quite old software so they had to rearchitect the internal software to be able to support JDF.

If you look at our estimating, we start with number of pages like full-page cover and 28 pages of content and then we calculate how to arrange that into folding sections, printing sheets. Most other systems, they start with, ‘Okay, I have five printing sheets’ and they do not have the high level of information so then they cannot build impositions. So the architecture of the software is one of the key reasons [why HiFlex is ahead]. Because we start at the page level, we are not starting from the sheets, it makes it very easy for us to actually send that as JDF stripping parameters to a prepress system.

Where did HiFlex come from?
Stefan Reichhart: I am the third generation of printing in my family. I am a printer, just like Thomas [cofounder of HiFlex]. Because of that our whole strategy was to make our system very technical and very near to printing production. This is the idea of Computer Integrated Manufacturing, which means to simulate the manufacturing process within the estimate. This is what we are doing.

We have been doing this same type of tree-structure visualization for 18 years now inside the software. If you look inside the CIP4 specification, you will find [our visualization structure] is very similar to the instructions inside the JDF specification. So we thought about CIM, invented this type of visualization and then 10 years later this organization called CIP4 thought about CIM and came to the same conclusion because it is obvious. This is probably why we are ahead of the competition because the basic structure is already there.

So were already into Computer Integrated Manufacturing [CIM] in the 1990s and we tried to start JDF even back then, advising companies like Komori and Heidelberg and other German-based companies – where they are based. Even before CIP4 came along.

Do you think CIP4 is a doomed organization, weighed down by its complexity?
MA: I think it works really well because they have working groups and they are very specific, whether it is soft proofing or something else. They don’t try to make a general solution for everything, the work with newspapers, packaging, advertising and commercial printing. In building solutions like that I think they are a really good organization and it is remarkable to see so many vendors working together without all of the politics.

But is it too complex for its own good?
SR: If you cannot handle the specification then, of course, you will always say that it is too complex and complain about it.

MA: Certainly a lot of the older systems are amazingly complex. You have a lot of printers who built their own MIS system to support JDF and that is a massive undertaking. I think that is why a lot of printers are starting to look at MIS systems because they have stuff they build in FileMaker and so on. And it is fine to just import an Excel spreadsheet or type in data, but when you have complex structures – outputting complex structures – you have to completely change the architecture. So for older systems it is very complex to implement, and it’s not something where you can just pick up the spec and implement it overnight. It takes many years.

Will things ever become so fine tuned as to make JDF hidden, arguably freeing up printers from this burden of complexity?
MA: At the end of the day, JDF should be hidden but unfortunately when you buy a system you can’t just look for a sticker on a box that says it is JDF compatible. Because right now there is no conformance testing.

I have an application that I wrote in Excel that output JDF and makes jobs in Prinergy. That is JDF compatible but it is not the same as this, so right now it is very, very difficult for printers to understand exactly JDF is and, most importantly, what a product supports because you could really make any product JDF compatible in 15 minutes but there is no measure of compatibility right now.

That will not happen until the CIP4-ICS testing starts sometime next spring. Even then that will only be base performance, where two systems support the MIS prepress side but one will determine more than the other so unfortunately printers have to learn a lot more about it to understand what they are buying. It shouldn’t be that way but it is.

How does HiFlex approach estimating, which appears to be very different from other MIS systems?
SR: In stitching, for example, you can define which feeder is now connecting with a certain signature. It is a function that has nothing which has nothing to do with price estimates because it doesn’t matter if the 16-page signature is on the first sheeter or the second sheeter… it doesn’t matter for the price. But it is purely technical information and we have had this information for almost 10 years in our system software.

Our estimating has always been very technical and not only worried about finding a price and then sending a quote. But rather that all of the technical information that you have inside the system so that you can use this on an actually job ticket. And for a job ticket it is important to know that you have, for example, the sequence of 16 pages on the first feeder, four pages on the second feeder, and eight pages on the third. This sequence or a different one will not change the price, but it will be valuable for steering my production.

Why do I also hear good things about your scheduling functionality?
MA: We have a fully dynamic scheduling. You can obviously schedule things manually but the technical products in our system at the prepress systems down to the sheet level, we can know when the black plate for the front of the cover is being exposed, which we can then reflect that in the scheduling. There is a direct linkage to the JDF parts ID. It’s all because of the links via JDF that we can actually be so comprehensive.

Are your partnering companies where they need to be to let your systems get out to the marketplace?
MA: Right now, the web printing side is a bit of the way behind. We just had the first worldwide installation with a web press and JDF. Prepress systems are kind of there at the moment but JDF 1.3 is just released. While we are ready to support it, I think you will probably see another six months before it’s available in most prepress systems.

We are a small company of around 60 people, and 30 of those are in the development and support so we can react very quickly to trends in the market. And also our software flexible in that we don’t have a standard JDF interface. In five minutes I can change almost any JDF field and send it to almost any device. Komori might want the press speed in one field while MAN Roland wants it in a different field.

Lately, some industry pundits have begun suggesting that maybe JDF is not heading in the right direction. It is clearly the right idea, but the argument is that it is fundamentally flawed, perhaps because of the complexity or something else, and I wonder how you would respond to such doubt?
There are some limitations. Like if I take a printing sheet and I want to mix two different jobs on it, well support for that is only coming now in [JDF version] 1.3. Support for marks so that we can send a final imposition is just coming but JDF is still a young standard: it is only two or three years old.