BI of gewoon productieplanning?
Productieplanning gaat over het organiseren van een zo efficiënt mogelijk proces voor een bepaald product of dienst. Hier worden de belangen van de klant en van de eigen organisatie tegen elkaar afgewogen. Een korte levertijd (fijn voor de klant) versus lage productiekosten (simultaan produceren); de bus op tijd laten vertrekken (goede punctualiteit) versus wachten op de reiziger die komt aanlopen (klantvriendelijk). Hoe bepaal je wat zwaarder weegt? Valt te voorspellen wat de beste uitkomst zal geven?
Het maakt niet uit of het nou het rijden van busritten is of het produceren van automatten. Als je het van een afstandje bekijkt, lijkt het best veel op elkaar. Planningen komen in TMWalker vanuit een externe bron en er wordt gemonitord of de uitvoering volgens plan verloopt. Het monitoren gebeurt aan de hand van gebeurtenissen die TMWalker binnen krijgt vanuit diverse bronnen en dan samenvoegt. Tijdens de uitvoering en naderhand doen we daar nuttige dingen mee. Noem het business intelligence of gewoon productie volgens plan.
Fabricage van automatten
Voor fabricage hebben we een koppeling naar het ERP-systeem waar de orders van de klanten in komen via EDI. Dagelijks worden orders door klanten ingeschoten, gewijzigd en in Corona-tijd ook wel eens afgeschoten. Deze verkooporders worden omgezet naar werkorders voor productie. Wijzigingen in de (werk)orders worden iedere vijf minuten gesynchroniseerd met TMWalker.
Werkorders hebben een gemiddelde doorlooptijd van enkele dagen en volgen in een rolcontainer een route door de fabriek. De bewerkingen die achtereenvolgens uitgevoerd worden, beginnen met het snijden van het tapijt en eindigen met het inpakken en verzendklaar maken van grote dozen waar de setjes matten in zitten. Van iedere activiteit wordt in TMWalker minstens de start en het einde gemeld, maar ook welke medewerker op welke machine het werk heeft verricht: de events. Afhankelijk van de machine weten we in TMWalker meer of minder details, b.v. als er een geautomatiseerde koppeling naar barcode-scanners is.
De events zijn de basis voor de reconstructie van wat er daadwerkelijk gebeurt of gebeurd is. We kunnen in TMWalker real-time zien waar iedere werkorder zich bevindt en (de route van de) werkorders naderhand naspelen. De events zijn ook de basis voor het doorrekenen van what-if scenario’s in simulatie pakketten zoals Plant Simulation van Siemens. B.v. wat gebeurt er met de bottlenecks/doorlooptijd/kosten in het proces als er een machine of medewerker toegevoegd wordt.
Openbaar Vervoer
Dienstregelingen worden in een speciale applicatie gemaakt, meestal Hastus. Voor openbaar vervoer lezen we dienstregelingen in die gedurende een bepaalde periode geldig zijn. Dit kan zijn in een eigen formaat van de vervoerder of in het openbare KV1/NeTEx/Google formaat. Afhankelijk van het formaat weten we in TMWalker meer of minder details.
De voertuigrit kun je zien als de “werkorder” van de bestuurder, met twee belangrijke soorten activiteiten: rijden en halteren. De ritten moeten gereden worden volgens de afgesproken route, vergelijkbaar met de route van de werkorder door de fabriek. De bestuurder moet met het voertuig op afgesproken tijden op afgesproken haltes zijn en daar zijn “halteer-activiteit” doen. In dit geval reizigers laten in- en uitstappen.
Van iedere rij- en halteeractiviteit wordt in TMWalker minstens het start en het einde gemeld: de events. Deze informatie halen we uit het eigen voertuigvolgsysteem van de vervoerder of uit openbare KV6 informatie. Afhankelijk van de bron weten we in TMWalker meer of minder details. Bijvoorbeeld wie de bestuurder was, welke personeelsdienst hij/zij had en welke reizigers in het voertuig zaten.
TMWalker ziet real-time waar ieder OV-voertuig zich bevindt en de (route van de) ritten kunnen naderhand nagespeeld worden, inclusief alle context-kennis. De events zijn ook bij OV de basis voor het doorrekenen van what-if scenario’s in simulatie pakketten.
In tegenstelling tot een geconditioneerde fabriek, is bij OV de context van grote invloed. Er zijn allerlei afspraken en wel/niet verwijtbare factoren die bepalen of een rit goed uitgevoerd kan worden. B.v. een bus komt te laat op een halte omdat hij in de file heeft gestaan bij een aanrijding of omdat er sneeuw ligt. Misschien kan het voertuig hierdoor niet op tijd aan zijn volgende rit beginnen of wordt een andere bus vertraagd omdat die verplicht moet wachten op aansluiting. Is zo’n rit representatief voor een volgende dienstregeling?
Je kunt dan de 80 percentiel nemen in de veronderstelling dat incidenten in de uitbijters zitten. Maar wat als je meer weet over de omstandigheden? Dan kun je een beter representatieve selectie van ritten nemen, die passen bij de toekomstige omstandigheden en dan misschien wel 90 of 95 percentiel nemen.
Of je kunt een “BI” model voeden met deze ritten (met context) en daar what-if scenario’s mee doorrekenen. B.v. wat zal de invloed van sneeuw zijn in de nieuwe dienstregeling of wat gebeurt er met de bottlenecks/rijtijden/kosten in het vervoernetwerk als er een voertuig of halte toegevoegd / afgehaald wordt.
TMWalker4 bevat veel context. Naast een uitgebreide ontheffingenmodule om de aansprakelijkheid van het ov-bedrijf zuiver te bepalen is er veel informatie beschikbaar van allerlei externe bronnen. VANL heeft speciaal voor dit doel een aandeel genomen in het bedrijf eXtractorONE.
0 reacties