Detailed knowledge of customer’s processes takes often years to gain, but without this knowledge, it is almost impossible to really optimize the processes and to develop effective tools for the end-customers. The key to the learning process is to identify the different stakeholders and their needs, understanding that an operator and a board member have different needs and different perspectives on problems. The purpose of management is to provide services as cost-effectively as possible, to obtain the shortest possible payback period for investments, and to strive to create a good working atmosphere. I don’t think the goals at floor level are very different, their perspective is just different. The operators want to do their job efficiently and flawlessly, get positive feedback, and enjoy the workplace. When I look at this from the supplier’s perspective, the transaction is conditional on a short payback period. User-friendliness and consideration of the needs of the operators make the work smooth and pleasant.

The best developer does not get the best results by staring at the terminal and optimizing the performance of the software. The user is ultimately the person who influences how efficient and usable the systems are. Therefore, I see that it is good for developers to see in production as a whole how the users use the system, only then they will be able to react and develop the systems to be user-friendly. However, the supplier must be able to critically evaluate development ideas, which is usually possible only in close collaboration. It is in everyone’s interest not to develop anything in vain, but to develop features that support the processes.

Not everything can be simulated

An analyst cannot always predict how people will behave in production and what challenges it will pose to do in practice. Therefore, the data collected from production, combined with material flows and self-making, gives an idea of ​​how the process can be optimized with modern tools.

The importance of work management is growing in optimizing processes. In manual work, labor costs represent the largest cost item and without proper tools, efficiency will be difficult to measure. One must also remember that measuring tools can be both, a threat and an opportunity! Properly calibrated production measuring tool raises motivation

and a sense of working together through which the employee feels valued and successful.

The collaboration is rewarding

The jointly developed system serves the entire chain, with process optimization and its measured benefits deepening the customer relationship. It is obvious that success brings a sense of well-being. When the whole chain is involved in the development, the feeling of success is enjoyed by the operators, the management, the procurement, and the technical team as well as the top management.

Based on my experience in customer projects I have found out the following three key points to be true:

• – Customer testing in production can be a happy customer
• – No matter what development and testing practices you use, the production brings out the truth
• – I get to know the customer so when we do another project, later on, we all know each other and things get easier

Let’s just take a few steps back to look at this in detail.

Label Applicator Line in production

There is a saying in Finland which directly translates as “The customer will test in production”, used jokingly by companies that do not practice testing systematically (or at all). This is of course the topic of many, many heated internet discussions where testing puritans… Oops, sorry. I got a bit carried away…

Twenty years ago, there was a great movement towards Test Driven Development. TDD was seen as the golden standard for software development. There were some who even said that if you do not do TDD, you do not appreciate your customers. So, it became a dogma and as with all dogmas, people start to practice it blindly, locking themselves into this certain mindset and never wonder why I’m doing this.

Despite all these testing best practices and guidelines, the customer still tests in production to some extent. And now I will explain why this happens.

At this point I have to add a disclaimer: This is my personal view of the matter. My view does not necessarily be that of my employer, my colleagues, or even other programmers in the world. I base my views on the experience I have from working in the software industry for over 20 years.

Recently I was working on our new product, the Label Applicator Line. It is an automated machine that captures images of mail items running on a conveyor belt, reads their address and possible barcode labels, adds a new barcode label if needed, and registers them for sorting at later stages. This machine has a high throughput of 6000 mail items per hour. It is 10 meters long, 5 meters wide and 2,5 meters tall. The OCR recognition rate is high.

How does one test it at the office?

I desktop tested all the software I wrote for it, of course. I unit tested every component except the camera imaging software, which needs an actual camera to operate. The camera’s imaging software was tested at the same time when I did the integration tests on the machine. I sat for days in our lab with the machine. I even let the machine run through the weekend and checked the logs on Monday to get a good understanding of the events.

But my tests were aimed at ensuring that the software on the machine will not crash the moment the client takes it in use. I could test how it performs under a heavy load. However, the problem was my limited test material. The client, a big postal operator, has tens of thousands of unique shipments every day. I, on the other hand, had just a dozen unique shipments.

Now, one could argue that the client needs a separate test/lab environment that runs parallel to the production line. And while this is true, one has to keep in mind the costs, the volume of test material (actual mail items), and the floor space that the extra machines will occupy. In a perfect world, with an unlimited budget, space, and time, the client could have built two postal centers; one for production, one for testing, and hire twice the amount of people needed. But in this world, that is not an option.

So, the client tests new equipment in the production environment. Of course, the client has to run production at the same time and have a backup system to be used when the equipment under testing fails. It will fail at the first run(s), you can count on that. There is no way to avoid it since I, the developer, does not have a postal center and a gazillion amount of test material. This is the unfortunate truth, no matter which way one puts it.

And a lot of times even the development phase must be done in production. Luckily, it can be done in iterations to ease the pain. Real problems start in integration. Those will be solved too, of course.

But. When a product has been tested with gazillion packages, with quite an amount of workforce and a couple of weeks of time, it will work. It will be tweaked like a customer wants. Many observations are being made during testing and those are used in optimizing the software, for example, camera settings can be changed to match the production environment (ambient light changes from place to place). And what is best, the workforce gets to know the machine from the start. Human mind has great capability to work around little quirks which existence developers do not even know about!

So, all-in-all, a) customer testing in production can be a happy customer, b) no matter what development and testing practices you use, the production brings out the truth and c) at the same time I get to know the customer so when we do another project later on, we all know each other and things get easier.

When building a house, a strong and solid foundation is an essential part of the construction project. No matter how stylish the window frames or how beautiful the decorations, the most important thing is that the base is well built and can support the whole structure.

Ergonomically designed mSorters for Far East e-commerce parcel sorting are a joy to use

The same applies to postal systems – a strong base is required. Integrations are needed for various existing information systems, various sorting equipment must also be supported, and a lot of data for track and trace systems as well as statistics must be provided as well.

At Posti Group Finland, the Mailroom Manager back-end from Mailroom Solutions has been integrated with the existing information systems to enable OCR-based restmail sorting, which will then merge the machined and manual mailflow, registration of e-commerce parcels and later also barcode-based manual mail sorting.

The Mailroom Manager back-end allows the customer to select a suitable toolkit for various postal processes based on budget and required features. Posti Group wanted to be able to handle Far East e-commerce parcels conveniently with a single touch and automatically select the most cost-effective delivery methods. Mailroom Solutions was able to offer an OCR-based solution that combined up to five separate processes into a single process. “We expect this solution to bring us 50% cost savings in our e-commerce parcel process,” says Jukka Nevalainen, process manager at Posti Group Finland.

Posti Group has been working with printing house partners for years and most of the print products today contain a valid barcode that can be used for identifying the delivery address. Therefore, the post also needed a fast, manual solution for sorting barcoded oversized mailpieces based on sorting machine sort plans. In this case, the mSorter Code Mini was the ultimate solution; it is low cost, easy to integrate and requires just 10 minutes of operator training. With integration to the existing manual sorting furniture, Posti was also able to extend the lifespan of the existing hardware. Because it already had the Mailroom Manager back-end in production, the deployment of the barcode-based sorting solution was very straightforward.

Development manager Hannu Kolmonen from Posti Group and Janne Eteläaho, Mailroom Solutions CEO, are happy with the smooth collaboration

“Cooperation with the Mailroom Solutions team has been both smooth and convenient. We were surprised by their comprehensive knowledge of our business needs,” says Hannu Kolmonen, development manager at Posti Group Finland.

In addition to the main projects, dozens of smaller life-easing functionalities have been introduced with the help of a flexible and robust back end.

“The cooperation with Posti Group has taught us a lot about the importance of the open interfaces and the need for easy integration. We often need to merge data from several sources to make the enriched data available in the desired format,” says Janne Eteläaho, CEO of Mailroom Solutions.

While planning the renovation of the postal processes, it is essential to make sure that the selected back-end solution is able to support future needs as well. The solution must lay on open architecture and enable:

• Flexible interfaces and easy integration to upstream and downstream;
• Easy vertical and horizontal scalability;
• Wide range of sortation solutions to cover the whole business area.

In addition to this, observation of the process productivity is important. This makes it possible to proactively adjust the process and immediately correct possible bottlenecks. It is also essential for the floor level managers to access the statistics for every process during the work shift.

Monitoring tools from Mailroom Solutions make it easy to quickly observe the process performance

A postal process renovation is just like any other IT project. The more careful specification and sharp definition of requirements there is, the more likely the project is to succeed. Furthermore, the experts need to be involved in the early phase of the project to ensure its overall success.