Business Case: Pooling Partners
Pooling Partners is a market leader in the area of full-service pooling services. A pooling service is the collection and facilitation of the reuse of logistic means. With respect to Pooling Partners, this includes the reuse and circulation of wooden pallets and crates. This means the provision and distribution of the pallets, including the collection, cleaning, and repair work on the pallets.
Making sure that the pallets end up at the right location needs a certain amount of direction. That is why clients of Pooling Partners are obliged to register the information on the movements of the pallets through EDI messages. This information is necessary for:
- Tracking the location of assets.
- Knowing where the pallets can be collected, so the collection can be planned as quickly as possible.
- The invoicing process, based on the movement information.
The message flows within the network are aimed at the movement information of the pooling material; the ‘movements’ of the pallets within the pooling network. In order to exchange these messages, a diversity of programs was used within Pooling Partners to exchange EDI between clients and their ERP system ‘PPO’. These old programs are called the ‘legacy tools’. The legacy tools pose a risk on a number of issues:
- Loss of knowledge (built on old technology, minimal support)
- Unmanageable (black box: part of the logic is unknow and not accessible)
- Too expensive
- Continuity cannot be guaranteed, applications are unstable.
As these legacy tools had been built on old techniques, emails got lost. As a result of a certain way of processing the emails at the French location, a group of messages was picked up in one instant, of which, eventually, only one email was actually sent through to the PPO. The other messages were lost without being processed and had to be traced in the backup system. In addition, due to the fragmented use of different legacy tools, the total overview was lacking. To regain the overview, it is necessary to have all messages going through one central point. This will make it easier to track down messages, to document them, and to monitor them.
With regard to this issue, we looked a number of aspects. This analysis showed that one of the challenges Pooling Partner has to deal with, is the recognition of a large number of different types of messages which are very similar. Additionally, the messages often came through unsorted via the same channel (email box and FTP). This mostly concerns messages that are received by the sales department, and which are subsequently forwarded to the mailbox. Sorting out these messages is complicated as the sender (sales) has the same domain extension at all the locations: @poolingpartners.com. This made it impossible for them to be defined by Niklas, making it unclear which sender and which parser had to be called. The legacy tool was able to do that as the inbound channel is a separate server per company.
The received messages (such as dispatch files) are translated and checked, after which they are forwarded to PPO. Another important item is the phasing out of the legacy tools which are currently a risk for the business operation. This includes, besides the physical legacy tools and the subsequent country servers, also the X400 server of France, which ran on an old XP server. It was not possible to move this physical server. Since 29 September 2017, the X400 EDI robot has been phased out. In addition, there is the issue of ‘TIE’, which mainly receives AS2 files. Pooling Partners was looking for a total solution for the exchange of messages with its clients.
We have provided a solution by employing our Niklas integration platform for the processing of the messages. This is also supported by a Reprocessing Portal. The Reprocessing Portal is currently offering support to the internal IT department in order to be able to monitor errors in the sent messages. After the delivery of the complete version of the Reprocessing Portal, the error handling will be handed over completely to the user organisation of Pooling Partners. Messages received by Pooling Partners are first collected in Niklas. Here it is determined whether some of the messages actually need to be dealt with through the legacy tools, or whether this can be done by Niklas.
Via Niklas, the messages are transformed before they are forwarded to PPO. This is done by means of a mapping. Our integration specialists have made a number of mappings that translate the various file formats into a generic XML format. The file formats that are used: some flat file variants, EDIFACT (DESADV en INVRPT) and a diversity of different Excel formats. By means of a mapping, the generic XML file is checked on a number of points. When one of the checks does not pass the set parameters, the file will end up in the Reprocessing Portal. When all the checks are done correctly, the message will be processed by means of two mappings in the database of Pooling Partners.
Niklas was implemented on premise, which means that Pooling Partners takes care of its management. We have trained the Pooling Partners application managers, enabling them to follow-up on notifications that pop up in their system. In addition, we have created the possibility for Pooling Partners to create links themselves. These links can be made in xslt, MapForce, Smooks, or Java. When the capacity at Pooling Partners is insufficient, we can do this for them.
In the Reprocessing Portal, an overview is shown of messages which receive an error notification. Pooling Partners is able to open this message and assess whether this is indeed an incorrect message. This way, messages which may contain, for example, a client code which does not correspond with prior defined values are blocked here. Or if a movement date lies too far into the future or in the past. Accordingly, after possible data enrichment, the user can process or reject the message again. The portal is used as a safety net to prevent certain messages polluting their own system.
We also help Pooling Partners’ clients with their transfer to a message exchange system via the Niklas integration platform. After an introduction, contact is set up between us and the clients. After this, we maintain direct contact with the client and organise the processes to realise the transfer. This means, among other things, that we request all the necessary data that is needed to identify the necessary links, and that we schedule the test program and the moment of going live.
The message exchange between Pooling Partners and its clients now runs through modern technology and up-to-date message standards. Niklas is the link between the systems of Pooling Partners and its clients. The integration platform ensures that the different message formats are transformed by means of mapping and that both systems are able to communicate. In order to make this manageable, the Reprocessing Portal was created for Pooling Partners. This portal simplifies tasks via a user-friendly user interface.
The legacy tools which were used at the different locations have been replaced by a standardised work method from a central integration platform. With our integration platform, the links that were created, and the web portals, the message flows have been centralised. Through the creation of standard links and standard checks, it is also easy to connect new clients. This makes this integration solution future-proof! By discarding some of the legacy tools, the risk for what concerns maintenance and ageing of the programs is taken away and expenses are reduced.