Digital Logistics Management Solution

The next step after the development and introduction of the cost control and analysis tool was the expansion of digitization into all aspects of the logistics department at Wellmann Kitchen. This work took most of 1996 and 1997.

I was asked to provide a proposal during the final deployment of the cost analysis solution. The work build up on the already pretty extensive data model. Again, I used Borland Delphi, though the database switched from Paradox (which I used for the initial system) to SQL Anywhere. This proved to be a difficult move, as SQLA was a rather untamed animal with lots of "undocumented features".

We used the same approach to development: initial design and data modelling, then rapid prototyping with a high level of user integration. Basically, I camped at the offices from 15:00 until End of Day each day, for more than 4 months, to develop the system to the needs of the users. Each day I returned and worked until midnight or later to generate a new build. That build was then refined the next day, tested, installed remotely and put through the wringer at 3pm.

The solution provided:

A visual route planning system, based on a digital map. This application was capable of working directly off the database, which allowed collaboration at the fringes of planning zones (Germany was divided into zones, each of which had an owner), display of changes immediately, and a high level of integration with customer service. This replaced a paper-driven system that needed cutoff at least 2 days prior to week-end to allow for data input and production planning. This time was reduced to a few hours, opening up a large window of freedom for the customers (a rather substantial competitive advantage at no additional cost). The work required to plan the routes on a paper map went from days to hours.
A customer service application to change delivery information like date, time, location etc. This give an unprecedented level of control in the hands of the customer service reps, to their delight.
A fleet management system, which knew where each load should be at the given time, and gave the operator a solid tool to understand degrees of freedom and identify problems early. There was no GPS at that time, but a hook was provided to allow for a realtime data feed that would have displayed the truck locations on the same maps used by the route planners.
A document system able to generate the necessary transport documentation and reports automatically at a nightly run.
A cost analysis tool expanding heavily on the solution already in place.
A common login solution providing security, recording, and collaboration capabilities. This was pre-Instant Messaging, the users could send chats, links to data objects and documents to each other using the system. It was also used to log the activities of the users.
A common architecture which leveraged several 3rd party components, eg. the map renderer and the route optimizer

There are a few screenshots that will show you the level of sophistication of the solution.

This screenshot shows the start page for a route planner. It shows all the stops currently in the system for the selected time frame. Stops are squared of different size and color, denoting number of cabinets and current owner of the stop.

By clicking on the square, the user could pull up additional information like customer, current planned route, owner etc. Drill-down into each and every data element was available as well.

The user could select one, several or all stops using either mouse selects or filters. He could zoom and pan.

The system allowed him to click on several stops to select them, then perform an automated optimal routing to find the shortest path. This path could be converted into a tour with one click, automatically assigning stops, commissions and orders in the right sequence to production and loading plans.

The user could also trade stops to others, request the transfer of stops, and mark stops.

This editor shows the assignment of zones to planners. You can see the planners on the right, as white buttons. The color of their text corresponds with the color of the overlay on the map.

A manager could now change those assignments on the fly to compensate for absenteism or permanently to manage work structures.

This editor gave the route planner the ability to assign a tour to a specific loading gate in a specific shift.

This assignment then drove production, as the company manufactured in the sequence of the loading of trucks (there is a lot of air in cabinets, and there is a lot of danger of damage during the loading process, which makes logistics a rather central part of an assembled furniture manufacturer).

Here you see the application used to manage single orders in the customer service department. All information about the order is displayed or can be drilled-down to.

The calendar at the top right was able to drag and drop dates. A production date could be changes as well as a delivery date (which triggered an automatic request to the planner), the date the delivery confirmation went out (which drove priting the reports and documentation) etc.

It also showed the history of the order, to help the employee work with some of the more creative customers in their versions of the truth.

Ultimately, this system was not put into production due to the inability of the internal IT department to provide reliable data replication from and to the mainframe. The system of order processing had been organically mushrooming for years. As a consequence, there was no controlled way to make changes to order information. In essence, there were thousands of little scripts and editors scattered over the mainframe that could access the order data, which was kept not in a database but in flat files. I was no longer with the project at that time, having been hired off by Whirlpool, and am often thinking whether my presence and help would have helped putting this solution into production. We were stable for 6 weeks, processing orders in a shadow system, but the two diverged every day when the replicated information came over a 24kBit line (an hour to transfer just the delta information, a full upload each day was not feasible).