Simacan Control Tower API-integratie laten bouwen
Een control tower laat zien waar uw ritten zijn en of ze op tijd komen, ook wanneer ze door verschillende vervoerders worden gereden. Het geeft u zicht dat u zelf niet kunt bouwen. Maar het levert alleen iets op als de geplande rit die u erin stopt klopt, en als er iemand is die met een afwijking iets doet.
Wat een control tower wel en niet oplost
Het probleem dat een control tower adresseert is versnippering. Uw goederen rijden bij meerdere vervoerders, elk met een eigen systeem en een eigen manier van statusmelden. De ontvangende locatie, of dat nu een winkel, een distributiecentrum of een klant is, wil één antwoord op één vraag: hoe laat komt het. Dat antwoord kan geen van uw vervoerders alleen geven.
Een control tower brengt de geplande ritten en de werkelijke posities samen en rekent daar een verwachte aankomsttijd uit. Dat is waardevol, en het is ook precies waar de verwachting scheefloopt: de kwaliteit van die verwachting hangt af van wat u erin stopt. Een planning waarin de stops in de verkeerde volgorde staan of waarin laad- en lostijden een aanname zijn, levert een nauwkeurig ogende ETA op die er structureel naast zit.
Het tweede punt is wat er met een afwijking gebeurt. Een melding dat een rit twintig minuten uitloopt, is informatie; pas als iemand daarop een winkel belt, een tijdvak verzet of een volgorde omgooit, wordt het waarde. Bij de meeste koppelingen die wij tegenkomen is de techniek niet het knelpunt maar de vraag wie de meldingen leest en wat hij mag beslissen. Wat er bij vervoersgegevens speelt rond persoonsgegevens, staat bij de Autoriteit Persoonsgegevens.
Hoe wij dit bouwen
Het vertrekpunt is de rit zoals hij bij u ontstaat, en de vraag wie er straks op een afwijking reageert. Zonder dat tweede antwoord bouwt u een dashboard.
Waar komt de planning vandaan, hoe compleet is zij, en wat is er aanname: stopvolgorde, laad- en lostijden, tijdvakken bij de ontvanger. Dat bepaalt de kwaliteit van alles wat erna komt.
Wie ziet een melding, wat mag hij beslissen en wie informeert de ontvangende locatie. Dat is een organisatievraag en die beantwoorden we voordat we bouwen, niet erna.
Elke sprint eindigt met iets dat u zelf kunt narekenen, en we beginnen bij het aanleveren van geplande ritten en het terughalen van status. De doorvertaling naar uw eigen systemen komt daarna.
We vergelijken de voorspelde aankomsttijden met de werkelijke gedurende een echte week. Waar het structureel afwijkt, ligt de oorzaak vrijwel altijd in de planning en niet in de voorspelling.
Wat de koppeling concreet doet
De uitwisseling van ritten en statussen is de basis. Wat u daarna met een afwijking doet, bepaalt of de rest waarde heeft.
Geplande ritten aanleveren
Ritten met stops, volgorde en tijdvakken vanuit uw eigen planning of TMS, in de vorm die de control tower verwacht. Wat er precies uitwisselbaar is, stellen we vast in de verkenning; wij beloven geen koppeling voordat we het koppelvlak hebben gezien.
Voortgang en verwachte aankomst terug
Status per stop en een verwachte aankomsttijd terug in uw eigen systemen, zodat uw klantenservice en uw locaties niet in een tweede scherm hoeven te kijken.
Afwijkingen met een eigenaar
Een uitloop of een gemiste stop wordt een melding met een verantwoordelijke en een verwachte reactie, niet een regel in een overzicht. Zonder die stap blijft het een dashboard dat na drie weken niemand meer opent.
Doorvertaling naar de ontvangende locatie
Een winkel of klant wil geen ritinformatie maar een tijd. Die vertaling, inclusief wat u wel en niet communiceert bij een vertraging, is een keuze die u maakt en die wij vastleggen.
Terugkoppeling naar de planning
Structurele afwijkingen per stop of per locatie zichtbaar maken, zodat laad- en lostijden worden bijgesteld op wat er echt gebeurt. Dat is waar de nauwkeurigheid op termijn vandaan komt.
Historie per rit bewaard
Wat was gepland, wat gebeurde er en wanneer is wie geïnformeerd. Bij een discussie met een vervoerder of een klant is dat de enige bruikbare bron.
Voor wie wij bouwen
Uw positie bepaalt of u de planning in de hand heeft of hem krijgt aangeleverd. Vier situaties.
Retail met eigen distributie
Vaste winkelroutes met krappe ontvangsttijdvakken en personeel dat op de levering staat te wachten. Hier levert een betrouwbare aankomsttijd direct arbeidsuren op. Rijdt u ook zelf de laatste kilometers, zie dan last-mile-bezorgsoftware.
Verladers met meerdere vervoerders
Uw goederen rijden bij verschillende partijen met verschillende systemen. Het samenbrengen is de hele waarde, en het is precies wat u zelf niet wilt bouwen. De planning zelf loopt vaak via een WMS of uw ERP.
Producenten met inkomende stromen
Niet alleen uitgaand maar ook aankomend: wanneer staat de grondstof aan de poort. Loopt er ook een weegbrug of terreintoegang mee, dan hoort dat in dezelfde stroom; zie toegangscontrole en weegbrug.
Vervoerders die aan verladers rapporteren
U levert de gegevens aan en wordt erop afgerekend. Uw belang is dat wat u doorgeeft klopt met wat uw eigen systemen zeggen, want anders discussieert u over cijfers in plaats van over prestaties.
Technologie en koppelingen
Positiegegevens komen doorlopend binnen, dus dit is een stroom en geen dagelijkse batch. Daarbij gaan de gegevens over voertuigen die door mensen worden gereden, wat de privacykant zwaarder maakt dan bij een gewone integratie.
Waarom Appfront
De voorspelling is zo goed als uw planning
Een nauwkeurig ogende aankomsttijd op een verkeerde stopvolgorde is misleidend. Wij beginnen bij de kwaliteit van wat u aanlevert.
Een melding zonder eigenaar is een dashboard
Zicht levert pas iets op als iemand mag ingrijpen. Die vraag beantwoorden we vóór de bouw.
De ontvanger wil een tijd, geen rit
Wat u intern ziet is niet wat een winkel of klant nodig heeft. De doorvertaling is een eigen ontwerpkeuze en geen bijproduct.
Eerlijk over wat wij niet weten
Er is geen partnerrelatie met de leverancier. Wat via het koppelvlak mogelijk is, stellen we vast in de verkenning, en wij beloven niets wat wij niet hebben gezien.
Security en privacy
Ritgegevens lijken zakelijk en zijn dat niet helemaal. Een voertuig wordt gereden door een chauffeur, en doorlopende positiegegevens zeggen daarmee ook iets over waar die persoon is, hoe lang hij ergens stilstaat en hoe hij rijdt. Dat maakt het persoonsgegevens, ook als dat niet uw doel is. Wij scheiden daarom de operationele weergave van alles wat naar individueel gedrag te herleiden is, en houden de bewaartermijn voor ruwe posities kort.
Werkt u met een ondernemingsraad of met chauffeurs in loondienst, dan is invoering iets om vooraf te bespreken, want volgsystemen raken aan controle op werknemers. Bij ingehuurde vervoerders komt daar de vertrouwelijkheid tussen partijen bij: een vervoerder mag niet zien hoe een concurrent op dezelfde route presteert. Scheiding per partij is daarom een ontwerpeis. Verder bewaren we per rit wat gepland was, wat er gebeurde en wanneer wie is geïnformeerd, want bij een geschil over een gemiste levering is dat de enige bruikbare bron. Hoe wij zelf met beveiliging omgaan staat in ons informatiebeveiligingsbeleid; meldingen van buitenaf lopen via ons CVD-beleid.
Veelgestelde vragen over een control tower-koppeling
Uw TMS kent uw eigen planning; een control tower brengt ritten van meerdere vervoerders samen en rekent daar één aankomstverwachting uit. Rijdt alles bij één vervoerder in één systeem, dan is de toegevoegde waarde beperkt. Rijden uw goederen bij vier partijen die elk anders melden, dan is het samenbrengen precies wat u zelf niet wilt bouwen.
Meestal niet door de voorspelling maar door de invoer. Een stopvolgorde die in werkelijkheid anders is, of laad- en lostijden die een aanname zijn in plaats van een meting, geven een nauwkeurig ogende tijd die er structureel naast zit. Daarom bouwen wij de terugkoppeling: werkelijke tijden per locatie voeden de planning.
Dat hangt af van het koppelvlak dat beschikbaar is voor uw situatie en uw contract. Wij zijn geen partner van de leverancier en beloven geen koppeling voordat we hebben vastgesteld wat er kan. Die inventarisatie is de eerste stap; het contact daarover loopt via u, omdat u het contract heeft.
Dat is de belangrijkste vraag en hij is organisatorisch, niet technisch. Een afwijking die niemand leest, verandert niets. Wij bouwen meldingen daarom met een eigenaar en een verwachte reactie, en beleggen vooraf wie de ontvangende locatie informeert. Zonder dat wordt het een dashboard dat na drie weken niemand meer opent.
Ja, maar niet in dezelfde vorm. Een winkel wil een tijd en geen ritinformatie. De doorvertaling is een eigen ontwerpkeuze: wat communiceert u bij een vertraging, vanaf welke afwijking, en wat houdt u intern. Die keuzes bepalen of het vertrouwen oplevert of juist meer telefoontjes.
Doorlopende positiegegevens zijn persoonsgegevens, ook als het u om de zending gaat. Wij scheiden de operationele weergave van wat naar individueel rijgedrag te herleiden is en houden de bewaartermijn voor ruwe posities kort. Bij chauffeurs in loondienst is dit bovendien een onderwerp voor uw ondernemingsraad.
Dan valt die stroom uit uw beeld en heeft u een gedeeltelijk overzicht, wat soms slechter is dan geen. Dit is een inkoopgesprek en geen technisch probleem: aanlevering van ritgegevens hoort in uw vervoersovereenkomsten. Wij maken wel zichtbaar welk deel van uw volume wel en niet in beeld is, zodat u weet waar u blind bent.
Dat hangt af van het aantal vervoerders, de kwaliteit van uw planning en of de doorvertaling naar winkels of klanten meemoet. De uitwisseling van ritten en statussen is doorgaans het kleinste deel; de terugkoppeling naar de planning en de klantcommunicatie kosten meer. Wij geven een onderbouwde inschatting na de verkenning. De aansluiting op uw TMS loopt via koppelingen.
Een control tower-koppeling laten bouwen?
Vertel bij hoeveel vervoerders uw goederen rijden en wie er nu belt als een levering te laat is. In dat tweede antwoord zit meestal het echte project. Wij bouwen dit als onderdeel van een breder traject maatwerk software of via slimme API-integraties.