Produced By INKISH

We’re a company that produces photo products, like books, wall décor, calendars, cards, that customers can buy online. They can customize it and we print it, ship it, all around the world.

I’m working for Albelli for 3 years now, and we are doing basically all kinds of stuff to make it happen. To produce photo books, and calendars, and canvases and all other products. We have many different types of machines and we do integrate them into single workflow. So it starts from the PDF being available to be printed, and then it’s being impositioned for different types of printers, and then the product can be cut or bound if that’s a photobook or calendar. Then it’s being packed and shipped to the end customer.

We use HP presses like Indigo 12000, 50000, recently installed here at the plant. Yeah, that’s correct. We started at the beginning of this year with the whole project and it was installed in April. We did a lot of preparations to get it live. First production was started around June/July.

It’s quite a challenge because we have many different types of products that we produce. And the more types we have, then the more different alternative routes we have to build into your software. And also different procedures for the operators, and to support all of that, that of course increases complexity.

Well it was quite new for us because we used to print on either a sheet or one roll of paper. And of course we still print on one roll of paper, but in the end we split it into two or three lanes. And that was a challenge because we haven’t done that before. Our software, which we developed in house was able to position everything on one lane, but we haven’t done it with two or three lanes. So that was the biggest challenge, to have it as efficient as possible and positioned on two or three lanes.

We got experience from HP, with different companies. We invited them, had conversations and in the end picked one.

We had an initial meeting where they gave us some sample files, some sample photo books and we were able to show what we’re doing with Phoenix. It was actually interesting timing for us because we are developing a lane-based ganging for commercial. So it’s good timing to actually work with a customer to figure out together, to have them give us input into what we’re building.

We want to imposition as efficient as possible, that’s for sure. We have different kind of products and it all needs to be able to be impositioned different formats, different positions. And also it should fit within the rest of our software environment.

Yeah, of course, because we have to imposition many books onto huge single PDF, so we can easily make 20 gigabyte PDF with a single job.

The books are quite heavy, and the samples that we got from them I think were over 20 gigs just in the first demo alone. The input we got from them was that our PDF processing was 15 or so times faster than what the other technologies that they were looking at.

Well we ended up choosing Phoenix to do the second layer of impositioning, because we do impose books into batches. And then Phoenix does impose those batches to lanes for printing. Because the idea was the 50 thousand printer, it’s a wide format printer, so the idea was that it will print in two or three lanes that can be finished on the other equipment. So the previous generation printers, they print on a narrow roll, like 24 centimeters or 33 centimeters and we have all the equipment that can finish those rolls. So the idea was that we’ll print on the wide roll on the 50 thousand, but we’ll cut it into a three lanes and then those rolls can be finished on the other equipment without any further changes. So that was the idea how to integrate the printer into our workload in the easiest possible way.

We have implemented it exactly in this way, it was the few lanes on the wide roll. That basically worked as expected. We did have some complications that we haven’t foreseen. Like the near-line finishing. Our current equipment is finishing roll in line, which means the paper gets cut as it comes out of the printer, while with the 50 thousand it gets printed then being wound on the roll, and then that roll being taking to the finishing equipment and being unwound. Which mean there is a complexity, you have to remember that what gets printed first, gets finished last.

Obviously the imposition part has to keep up with the DFV and the throughput of the press. Phoenix is able to do that, both on the importing of these heavy files and then the optimization stage which was seconds for us to the actual creating the imposed file PDFs that are sent to the DFV. So the key there is that your software is not a bottleneck and that you can maximize the throughput on a press. The 50000 is a very fast press.

Performance-wise, Phoenix is more performant than our in house imposition too. I think it can churn like 10 gigabytes of PDFs per minute, which is quite fascinating. So far we have been happy with the performance of Phoenix.

Phoenix allows them to maximize the throughput on the 50000, and to get the efficiencies out of that press that are possible. And a big part of that is that the speed of processing and the optimization of lanes. The PDF processing isn’t fast enough to feed the press, that’s obviously a problem. But outside of that they have to make decisions about the number of batches that they’re producing and balancing those across lanes. And Phoenix is able to do that very quickly. So they can in fact try a certain number of batches, and then if the efficiency isn’t good enough to wait for something else to come in, if no more batches come in after a certain period of time they can send that to the press as well. So that’s another aspect that makes Phoenix unique, I think, is we have a completely open API and the combination of the speed of the processing and the flexibility so they can create business rules in their application that’s unique to Albelli. To make decisions about when things go to the press while still making sure that that press is always running.

When we were looking for the solution we were not interested into UI based solution. We wanted an API based system because here at Albelli we automate things as much as possible. So the API first approach was critical for us and we’re happy that Phoenix does it the right way. There are certain things that we still have to do in the UI but that’s improving. Basically in the API you can do like 95 percent of things. And I think in the next few months that will be 100 percent.

A few years ago when we were beginning development in automation, we decided right away to create an open API. So we have a rest-based web service that is quite extensive. In fact most of what you can do in the desktop you can also do in that API. One of our main goals at the beginning was to integrate with MIS and work flow vendors. We’ve seen especially in the last year or so more and more printers adapting this API. And using it in ways that we didn’t even expect. So that’s exactly what happened at Albelli, they were able to use our API out of the box and customize it however they want by just using the tools available in Phoenix and using the power of Phoenix.

We have ideas how to use Phoenix in all the types, for all the printers and that will reduce the number of vendors we use at Albelli. From the start up solution time that was a big benefit. If we would have built it ourselves, that would have taken a few months longer. And of course business wanted this printer to be operating in one month after they had bought it.

Yeah I think that it has speeded up the process of implementation. Doing it ourselves would be quite intensive way of working and I think that it’s nice that we were able to find some common ground and develop from there as well. Because Tilia Labs was open for our way of working and adapt to that.

We like the way the collaboration and communication with Tilia Labs. They’re very responsive and willing to accommodate our requests and very helpful, so that’s great.