A year ago, we started developing software for marine logistics because we found the need to develop cloud-based solutions to common problems in maritime terminals. We launched a pilot project at one of the cargo terminals in Riga.
A feature of our solution is the presence of a visual warehouse map. Unlike standard storage systems, where it is necessary to understand which shelf the product is on, how to find it and to transfer it, in our system for bulk and general cargo it was important for the client to understand in which area of the warehouse this or that cargo is, how much it is stored and who is cargo owner. Bulk cargo (for example, grain or oilseed rape) is stored mainly in closed warehouses and in separate piles. General cargo arrives at the warehouse in the form of pallets and is stored in special open areas.
Before we start the development of our system, the terminal did not have any sort of systematic map of the terminal with all possible places for storing pallets. Therefore, we had to mark up and draw the terminal ourselves almost from scratch.
This is how our interface looks:
Technically, we implemented:
- Interface for terminal operator
- Interface for Shipper
- Control gate point employee Interface
- Interface for the terminal worker
- API for interacting with an external client’s system
All this is implemented in Golang and graphQL. For quick front-end implementation, we used HTML-templates and JS for working with the map. To work with the system does not require additional installation, allocation of server capacity or a whole staff of technical support. We provide all this.
The solution completely satisfied the customer. But at the stage of trial operation of the system, new problems were revealed that the terminal is facing and which are not solved by the basic process of our Warehouse Management System (WMS).
For example, we realized that at the entrance to the terminal there is a traffic jam from trucks that arrive for unloading and loading. Congestion also occurs on the territory of the terminal, because trucks with different cargoes are unloaded or loaded into various warehouses, they need to go through weighing, which, by the way, is also not automated and was done manually in a special journal. Drivers bring with them a huge stack of documentation, which is interrupted by hands in accounting programs or in an ordinary Excel, and copies are stored in archives. And all these processes did not concern work with state institutions. Thus, we realized that our solution showed only new problems on the terminal that we had to deal with.
One of these problems was truck traffic jams both at the terminal and at the entrance to it. And in order not to complicate our current solution with additional functionality, we began to develop separate modules — solutions that could be used both with and without the warehouse system.
The first product that helped get rid of congestion at the entrance to the terminal is the electronic queue of trucks (Queue Management System) — Qline. This solution is an analog of the electronic queue in banks and other institutions. In our solution for queues, the same principle is used: the forwarder pre-selects the time slot in which the truck will arrive at the terminal indicates the data of the truck and driver. Thus, the date and time of arrival are known in advance, several trucks cannot be recorded at the same time, which significantly reduces the number of a truck waiting for their unloading and loading.
The electronic queue uses the same programming languages as the warehouse system. It is already installed on several terminals in the Baltic states.
System Interfaces:
For example, a truck with grain arrived at the terminal. After entering the terminal, he needs to drive onto the scales to weigh the entire loaded truck. Then he must come to the laboratory to check the quality of grain and compare it with those indicated in the documents. After that, he must unload the grain in a predetermined warehouse. At the same time, if the grain quality does not match those indicated in the documents, another warehouse may be assigned to it. After unloading, he needs to go to the scales again in order to get the weight of an empty truck and, accordingly, calculate the weight of the cargo. After all this, he can either go pick up some other cargo from the terminal or leave the terminal.
The process and movement within the terminal looks pretty simple at first glance. But it seems so when it comes to one truck. And if 10, 15, 20 or 100 trucks are moving along the terminal at the same time, then this is more like Brownian movement. And systematization is indispensable here.
Things are slightly simpler with weights. Almost all terminals have scales, from which it is possible to take data electronically. If this is not possible, and there is no desire to enter numbers into the form by hand, it is possible to install a camera above them so that it recognizes the numbers and transfers them to the electronic weighing journal. Now, this product is in the development of exchange methods with weighing equipment, but the interfaces are ready and they also transmit data to the warehouse and accounting systems.
Our weight system is rather a universal API with a web-interface, which allows you to integrate with various weighing systems or devices, for example, cameras for taking numbers. And the data is displayed on the web-interface, aggregating various weights on one screen.
Now this solution is at the trial operation stage at one of the terminals in Riga.
There remains one more problem that we have to deal with — large volumes of unstructured information on the paper documents. Initially, it seemed to us that to solve this problem would be the easiest, because it can be solved using OCR, since almost all documents in logistics have a standard look. But in practice, it turned out that even with the standard template, many documents are filled out in different languages, and many are handwritten. Handwriting is difficult to distinguish between the various OCRs on the market, even as large as the Adobe OCR. Therefore, now we are trying to teach the neural network in different languages, but we have not yet found a solution to the problem of handwritten text.
So far this is all that we are developing, but this whole set of products does not solve even half of the terminal’s problems. The logistics industry is one of the most non-automated in the world, where everything rests on parole, and problems are solved by calls and personal communication.
The plans also include automation of container lines, work with the ship (loading, planning), a KPI system for employees of work crews.
As you may have noticed, all of our products can be used either individually or in conjunction with each other — they are integrated into a solution of the TOS (Terminal Operating System) class. Thus, to meet the needs of the industry, we have developed the functionality of the basic warehouse management system (WMS) to a modular TOS with a set of technological tools that accelerate the accounting processes and the business process of the cargo terminal as a whole, reducing the risk of error and providing new competitive advantages for terminal customers.
Source: medium.com
