Grand Challenges in Discrete Event Logistics Systems

How to tackle the first challenge can be illustrated by how D-SIMSPAIR, D-SIMLAB’s flagship product for planning and optimisation of spare parts logistics networks in the aviation industry, evolved: The original intention was to develop this system using a Commercial-Off-The-Shelf (COTS) simulation package as the backbone. However, it turned out that such a simulation software comprises a lot of modelling gadgets and graphical features that are actually not required when it comes to regularly carrying out domainspecific decision support tasks but only make the simulation execution very slow. More importantly, the associated optimisation tasks turned out to be too complex to be handled by such a generic tool. With this experience, and knowing that spare parts logistics optimisation is a critical business process with sufficient potential across the entire aerospace domain, we decided to (re-)develop D-SIMSPAIR from scratch as a domain-specific decision support tool: The respective business processes were modelled with high-fidelity by gradually incorporating all relevant decision support rules (never mind, if the fidelity is too high here and there, at least we do not always have to challenge the model’s validity), and we also developed a new optimisation module, thereby making use of a considerable amount of domain-specific heuristics. The result was an ERP-kind of decision support tool – where simulations and optimisations only require model configuration but no model set-up – and which can be regularly run without the need for continuous model re-verification and revalidation. Only such a decision support tool is able to generate maintainable benefit over a long period of time. High configurability is in fact indispensable, otherwise the software would always be subject to targeted buyers’ typical reaction “Nice software, but our processes are different, therefore it is not relevant for us...”. Naturally, when developing such a system it is essential that (i) all functionality is taken over into one master version of the software, and (ii) the system is developed with input from several customers to make sure that it is not “customised to death” to the needs of one single customer.