In the early days this was simply so that the MIS could gather information from those systems to present managers with a complete overview of how their business was running, where costs were rising or if some work was more profitable than others as well as in producing estimates.
But the development of the Job Definition Format built onto this ability to generate estimates and connect to other systems by handing MIS an important new role, turning requests for quotes into job tickets and pushing those jobs through their production processes. Consequently, most MIS have now taken on a dual role, providing feedback on the business as well as playing a central role within an automated production workflow, scheduling and routing jobs through the different processes. This requires a much deeper integration than just moving files from one hot folder to the next because the MIS will also analyse each process to assess how efficient it is.
JDF proved to be a mixed blessing for many MIS companies. On the one hand, this dual role meant that many more printers looked to integrate an MIS into their production systems. But many vendors complain that JDF didn’t go far enough, as Keith McMurtrie, managing director of Tharstern, explains: “JDF promised to be the Esperanto of print technology communication but has it delivered? It’s done so in a lot of ways but perhaps not often in the ways it set out to do. It’s like a big book of ingredients but they left out the actual recipes for how to use those ingredients and lots of vendors were left to interpret it in their own ways.”
This meant that all the vendors right across the board, from pre-press workflows through to finishing equipment, had their own ideas about how much information they would collect, how much they would share with an MIS, how frequently they would communicate their status, how they would respond to problems and so on, all requiring their own specific integration. McMurtrie adds: “But that was the technology that was available at the time and people would augment it with whatever else they had such as dropping files into hot folders.”
Naturally, if an MIS developer has completed an integration with another vendor’s software then they will look to reuse that with other customers. But most quickly discovered that although JDF envisioned every printer working in the same way, in reality every printer is different, with their own mix of customers, their own, sometimes eclectic, collection of software and machines, and their own ideas. Some, for example, will send short-run jobs to a digital press, while others will gang them together on a litho plate, all of which complicates any integration project.
Nonetheless, David Lowe, technical sales specialist for EFI, argues that printers still think in terms of JDF, saying: “We would probably first look at JDF to see if we could do it in that way. But JDF is just another form of XML.” He says that it’s impossible to keep up with all the possible integration requirements, saying: “Now we are moving to giving customers the tools to build their own integrations that work as they want.”
Lowe says that EFI favours working with XML as most printers have the skills for this, noting: “Anyone using Switch as a workflow or who has built an automated workflow with one of the common pre-press workflows, they can probably use XML, which is why we used that approach rather than a programming language.”
Most developers agree that there is still a place for JDF though Pete Horwood, project manager for Imprint Business Systems, says there is a limitation to this, observing: “With JDF, most of the systems work on a series of milestone events, which once conditions have been met will then move to the next stage of the process, feed information back, and trigger another process. Often what people want is similar but it does depend on how much information a customer wants and what level of integration is possible with the software they want to work with.”
For this reason many software developers have moved onto using application programming interfaces, or APIs. However, Horwood points out: “Most vendors do have an API but not all of them have things like a messaging structure with a definition of status and events so we can understand how to trigger things.
“There’s still an assumption and expectation that we just have to dump our code on top of their code and off it goes. But it does need to be different – that API still needs to be mapped and matched up and there needs to be an understanding of the customer’s expectations of how they use the third-party software and how that flows through their workflow. There will always be an element of someone wanting to do things in a slightly different way.”
McMurtrie believes that vendors will increasingly move towards developing proprietary connectors that are more robust and turnkey, and that this will lead to tighter partnerships between different vendors. He explains: “An API would mean that products that are connecting would have also to tell the functions of the product they are trying to interface with. So one company could accept a batch of shipments and you could call the API for that. But another shipping product might not have that level of capability so you wouldn’t try to send the same information.”
The cost of integration
In most cases, the need to automate workflows, and therefore to integrate to third-party systems, is part of the reason why printers go shopping for an MIS. Consequently the time and cost of those integrations are built into the initial quotation for the MIS.
Adrian Zesiger, EFI’s European sales director for productivity software, says that EFI always goes through a discovery process with customers looking to install an MIS to understand what the customer wants to achieve and any integration that is necessary, and to establish the time allowed for this. He adds: “After that the customer can put it under maintenance so that if there is a new version of software then we will make sure that it works. After the customer starts to work with the system, and if they want something else, then we would make the same process again and commit to that process and timing again.”
However, McMurtrie argues that it’s not always that simple because a printer’s requirements can change as they start working with a system and appreciate how they can use it and that this can sometimes lead to a more open-ended commitment. He explains: “The cost is based on time and service and what we are integrating with,” adding: “We can give you a rough idea as to where you will get a basic level of functionality but a lot of it is down to the customer owning the project.” He says that it’s relatively simple to put in a basic link to connect different bits of equipment but that it then takes time to refine that connection, to achieve the level of automation that the customer wants but also to deal with unexpected problems that might mean Tharstern having to revisit a project several times until all the kinks are ironed out to the customer’s satisfaction, adding: “So there’s no silver bullet.”
Horwood takes a slightly different approach, saying that Imprint will look to do relatively simple integrations, such as linking to an accounts program, through adding one of its existing modules. These include things such as warehouse tracking and stock control as well as estimating.
However, Lowe points out that some things are beyond the scope of an off-the-shelf module, saying that customers are asking for things such as tools to connect to other manufacturing systems so that they can call off the print product when the manufacturing line needs it.
Horwood agrees that where a customer has more complex requests then that might require a bespoke approach, explaining: “We would examine that and then work out if it has a wider application that we could apply to other customers.” He adds: “Some things we have done before so we might not charge additional money for that.” But he notes that even if Imprint had integrated to a third-party system for a previous project, the customer might have used it in a different way so there might still be further work required. He adds: “We want to be able to open up wider functionality so if you have an integration that we want to do, we might be able to add that as something additional to other customers to make ourselves more attractive to potential new customers so there is a balance there.”
Another option open to customers would be to automate processes via a do-it-yourself workflow tool such as Enfocus Switch rather than paying for an MIS integration project. But Horwood argues that this would be geared toward producing a job in a certain way, saying: “An MIS will give you a broad look at your whole system, and whether to do a job digital or litho or even to outsource it.”
In addition, McMurtrie points out that the need for an MIS goes beyond simple automation: “Printing is manufacturing so we need the requirements of a typical manufacturing business. That means management of materials and knowing when resources are required. And it has to provide management information like sales numbers, what markets are working well, what products are working well in particular markets.”
Conclusion
McMurtrie says: “I think that MIS will change a lot over the next few years. It’s a very connected world and the generation that are coming into the workplace just expect things to work so MIS will have to find links to other systems like HR.” He points out that packaging already requires integration with CAD design programs because there’s more time spent designing and refining and prototyping the packaging then actually printing it.
Other vendors say that this is already happening, with Horwood observing: “We have had a lot of enquiries from customers in this pandemic because they have time during the shut down to think about what they want to do.”
