Has Christmas come early? It has for our outgoing goods department!

At peak times, our busy bees at the central warehouse in Wohlen process up to 27,000 orders per day. It is vital that the orders are packaged efficiently, to make sure we keep our next-day-delivery promise. As our manual packaging stations are reaching their physical capacity limit and a partial automation is the only way of fully using the limited space, we decided to invest in packaging machines. In a first phase, a «CW1000»-type packaging machine by the company CMC will help take away some of the pressure. The machine we lovingly refer to as «Packy McPackface» will soon be joined by a further one.

The desired outcome is to help out our employees in the outgoing goods department and allow them to focus their skills on packing fragile, large or bulky articles. Integrating «Packy» into our existing logistics software was an exciting challenge that kept us on our toes until its productive introduction was completed.

How it works

«Packy» is the dream of every fan of the educational German children’s series «Die Sendung mit der Maus» and will also have adults amazed. It’s fascinating to watch ordered articles turn into ready-to-ship packages – from being swallowed by the machine to getting the postage label stuck to their box. While the articles are transported into the machine on a conveyor belt, the machine measures their dimensions in a matter of seconds. It then custom-cuts pieces of cardboard for the articles, thereby significantly minimising the amount of packaging material used. The articles are then sent to their made-to-measure packaging. If required, documents, such as delivery notes or brochures, can then be added to the delivery before the bits of cardboard are folded into sturdy boxes and sealed. The packaging process is completed with the addition of a label that includs all the required shipping information for the post. This process repeats itself about 700 times per hour.

In order for «Packy» to know what needs to go in a package and what needs to be printed on a label, we feed him with data from our very own ERP system that was developed in-house. The main challenge our development team Phoenix faced was to intregrate «Packy» into our existing ERP packaging process. This also meant a technical integration into our system.

Concept phase (PoC)

At Digitec Galaxus AG, we increasingly apply Cloud computing. So for this project, we were able to realise an interface between ERP and «Packy» in a designated module in the Cloud. «Packy» communicates via a classic TCP socket – a form of communication we had not yet used at that point. As a result, we needed to define who would be playing which role in this scenario. In other words, who would be the server and who would be the client. We decided that «Packy» would be the client and our Cloud module its counterpart, the server. «Packy» is a simple creature and is happy with data in the form of a string. The strings can be considered as events: They are requests and responses between «Packy» and the server.

Our decision to implement the server module into the Cloud meant that we were entering new territory for our logistics software solution. So all developer teams involved had to come up with some groundbreaking ideas. We chose a Kubernetes cluster as an enivornment for our server module in the Cloud. We decided to go for this Kubernetes cluster because it is extremely slim, fast to deploy, easily scalable and uses very little resources. As innovative as this decision may have been, it also caused a lot of head scratching during development. For example, a stable and fast communication between the server and the ERP system proved to be difficult right at the start. We also used an Azure Service Bus to funnel data back and forth between ERP and server module via message queues. This was done because «Packy» needs information from our ERP system before it can make a package. Afterwards, «Packy» needs to tell the ERP system that the articles were successfully packaged so that the respective data is updated and the package can be marked as «shipped». Therefore, in addition to the Cloud module, we had to build a new message receiver module so that the ERP system can process messages.

Process

The above-described communication between «Packy» and the server module is an important part of the integration. Another equally important part is the integration of «Packy» into our packaging workflow in ERP. After all, without correct data preparation in ERP, «Packy» would not know what to do with the articles he receives for packaging. To achieve this, the modularised packaging workflow in ERP was modified as follows:

Our employees identify the articles for shipment by means of a barcode and, if required, bundle them with the help of a banderoling machine. At the same time, a small label with a QR code is printed off and stuck on the articles. ERP simultaneously sends the package data «Packy» needs to our Cloud module (server). That’s where the ZPL code for the label printer is located. The code contains the label’s details such as the package number.

The article that needs to be packed is then placed on a conveyor belt and transported to «Packy». A barcode reader automatically scans the QR code. This triggers a request for all article information that is sent to the server. «Packy» then checks the dimensions of the articles that need to be wrapped up before he gets to work preparing and cutting the cardboard to size. While the article chugs through the machine, the server and client («Packy») constantly exchange events. The result: We always know the current whereabouts of the package. In addition, it allows us to provide «Packy» with any extra data he might need to carry out the next step. This kind of data might include information on whether a delivery note has been added to the article or if the product has been manually removed from the machine in the meantime.

In a final step, «Packy» sticks an address label on the folded and sealed package. He then scans the barcode printed on the package to make sure it matches the barcode that was transmitted by us at the very start. «Packy» does this to ensure the package is delivered to the right address. If everything is in order in this last step, the Cloud module gives our ERP system the green light to modify the data and mark the package as «packaged».

We all make mistakes: There is a risk of overfeeding «Packy» – by accidentally giving him very large articles, for example. If this happens, the machine spits out the articles after their dimensions have been checked. We then have the possibility to either automatically repackage the tricky articles or manually stick them in a box. Each time an error occurs, this is logged into our Azur portal, where we’ve created a neat dashboard that makes it easy for us to monitor things. The dashboard is displayed on a large TV located by the delevopers’ desks. We use Azure for automated notifications (alerts) and dashboards. This way, we are constantly informed about errors and are able to react promptly and adequately in the event of an emergency.

The lowdown

Integrating «Packy» into our system was a very interesting and challenging project that enouraged us to look at new technologies and helped us gain a lot of know-how. Using new technologies is always a challenge that goes hand in hand with unforeseeable obstacles: Prime head-scratching moments were caused by e.g. the Cloud services or setting up an encrypted communication channel between «Packy» and the Cloud module. By using packaging machines and made-to-measure packaging, we are steering towards a drastic reduction of packaging material and protective filling – a great development, both economically and ecologically speaking.

Interested?

Fancy joining our team? Browse our vacancies and find a position that is right for you.