Production planning is all about organizing a production process for a product or a service as efficiently as possible. It’s about waging your clients’ needs with your business’. A shorter delivery time (for your client) vs. lower production costs (simultaneous production); making sure the bus leaves on time (good punctuality) vs. waiting for a passenger that needs to catch the bus (customer relationships).
It does not make a lot of difference if we are talking about vehicle journeys or producing car carpets. If you look at the two from a distance, they are pretty similar. Schedules are uploaded to TMWalker from an external source and one can monitor if the execution is according to plan. The monitoring is possible through event logs that TMWalker imports and merges from several sources. We use this information during and after execution in our analyses. Call it business intelligence, or just production according to plan.
Manufacturing car carpets
We created a link with the ERP system which receives all the sales orders through EDI. These orders are made, changed, and, during COVID, sometimes also withdrawn on a daily basis. These sales orders are translated into work orders for manufacturing. Changes in those (work)orders are synchronized with TMWalker every five minutes.
Work orders follow an average throughput time of a couple of days and their housing containers travel through the factory by a route. The operations that are executed subsequently start with cutting the big carpets and end with packaging and sending off large containers with sets of car carpets.
For every activity, we log the start and end times, who executed it, and on which machine; the events. Depending on the machine TMWalker might know more details, such as when there’s an automatic connection to a barcode scanner.
The events are what lies at the base of reconstructing the actual process, afterward or during the execution. We can follow (see its location in the production halls) each work order in a real-time fashion in TMWalker and replay its route afterward. The events are also what is used in calculating ‘what-if’ scenario’s in simulation software such as Plant Simulation. E.g. what happens with bottlenecks/throughput/costs in the process when we add a machine or employee?
Public Transport
Timetables are created in a special application, usually Hastus. We import timetables for public transport that are valid during a period of time. It’s possible that this is the public KV1/NeTEx/Google format, or a format specific for that carrier. Again, depending on the format TMWalker can show more details.
One can look at the vehicle journey as a ‘work order’ of its driver, with two main activities; driving and making stops. These journeys need to be done according to a premade route, comparable to the routing of a work order. The driver needs to stop at the right time and on the right stop, and perform his stopping activity. Which, in this case, is letting passengers get on or off the bus. And again, we log the start and end events of these driving and stopping activities. This information is available to us through vehicle tracking systems or KV6 imports. We are able to connect this with the identity of the driver, his/her shift, and which passengers were in the vehicle.
Just as in the production halls, TMWalker can show the real-time data of every PT vehicle and allows for replaying these journeys – including all available context information. These events are, also in PT, the base for calculating the ‘what-if’ scenarios in simulation software.
Contradicting to a conditioned factory, PT is very dependent on the context. There are all kinds of agreements and culpable (or not) factors that determine if a journey is done properly. E.g. a bus is too late at its stop due to an unforeseen traffic jam or due to snow. It might mean that this vehicle cannot start the upcoming journey on time or a different vehicle is delayed as it’s obligated to wait for that connection.
Is that journey representative/relevant for the next timetable? One could use the 80 percentile, under the assumption that these incidents are covered by outliers. But what if you would know more about the circumstances? You would be able to create a better representative selection of journeys, that fit the upcoming circumstances and you might be able to use the 90 or even 95 percentile.
Or, one could create a ‘BI’ model and feed it with the data of those journeys and their context and play with the ‘what-if’ scenarios. E.g. what will be the effect of snow in the new timetable? Or, what would happen with the bottlenecks/driving times/costs if you add or take away a vehicle/stop?
TMWalker holds a lot of context information. Next to an extensive exemptions module to determine the liability of the PT company, there is the addition of all kinds of extra external information. This is the reason that VANL acquired shares of the eXtractorONE company.