Eén bron voor drie systemen
Voor InterUM - het interne detacheringsbureau van de Universiteit Maastricht — bouwden we geen enkele koppeling, maar een set. De website haalt vacatures uit Pivoton en stuurt sollicitaties terug. De roosterapplicatie ontvangt werknemers, contracten en opdrachten, en levert aan het eind van de rit de urenbriefjes weer aan.
Voor InterUM - het interne detacheringsbureau van de Universiteit Maastricht - bouwden we geen enkele koppeling, maar een set. De website haalt vacatures uit Pivoton en stuurt sollicitaties terug. De roosterapplicatie ontvangt werknemers, contracten en opdrachten, en levert aan het eind van de rit de urenbriefjes weer aan.
Pivoton blijft waar het hoort: de bron van de flexadministratie. Onze systemen halen daar op wat ze nodig hebben en geven terug wat er in de uitvoering is ontstaan. Niemand typt nog een vacature, een contract of een uurbriefje over.
InterUM detacheert medewerkers binnen de Universiteit Maastricht, onder meer voor tentamensurveillance. Het roosterproces heeft twee kanten die elkaar continu raken: de administratieve kant, waar medewerkers en contracten worden vastgelegd, en de uitvoerende kant, waar beschikbaarheid en inzet worden gepland en verloond.
Die twee kanten zaten in verschillende systemen. De administratie liep in Pivoton, de planning in onze roosterapplicatie, en de vacatures op de website. Elke mutatie aan de ene kant moest aan de andere kant opnieuw worden ingevoerd - met de bekende gevolgen: vertraging, typefouten en een planning die rekende met verouderde contractgegevens.
De opdracht was daarom niet "maak een koppeling", maar: zorg dat de drie systemen dezelfde waarheid delen, zonder dat de administratie zijn eigen systeem hoeft los te laten.
Stroom 1 · vacatures
Vacaturegegevens komen als XML-bestand uit Pivoton binnen en worden op de website geplaatst, bij de juiste vestiging en in de juiste rubriek. Sollicitaties leggen dezelfde route af in omgekeerde richting: wie via de site reageert, komt als XML terug in Pivoton, gekoppeld aan de vacature waarop is gereageerd.
De redactie plaatst daarmee geen vacature meer dubbel, en een reactie kan niet meer tussen mailbox en systeem verdwijnen.
Stroom 2 · medewerkers en opdrachten
Werknemersgegevens komen als XML binnen en worden in de roosterapplicatie aangemaakt of bijgewerkt. Dat is niet alleen een naam en een nummer: ook de contractvorm reist mee, want de planning rekent met contracturen en inzetregels. Verandert een contract, dan verandert de planning mee.
Opdracht- en contractgegevens volgen dezelfde route en worden aan de betreffende medewerker gekoppeld, zodat een surveillant alleen wordt ingezet op opdrachten waarvoor hij of zij daadwerkelijk is gecontracteerd.
Stroom 3 · urenbriefjes
Zodra een planning definitief is, stelt de applicatie de urenbriefjes op basis van het surveillantenrooster. Die gaan als XML naar Pivoton, waar de urenadministratie plaatsvindt.
Omdat de uren uit de planning zelf komen en niet uit een aparte invoer, klopt de administratie bij de bron. Handmatige overname is verdwenen - en daarmee ook de correctierondes achteraf.
Pivoton levert en accepteert gegevens als XML-bestanden, niet via een open REST-API. Dat is geen beperking die je moet omzeilen, maar een route die je goed moet inrichten: bij bestandsuitwisseling bepaalt de kwaliteit van de afhandeling of het betrouwbaar is.
Daarom is elke stroom gebouwd met dezelfde principes: een bestand wordt pas als verwerkt beschouwd als het volledig is ingelezen, onvolledige of afgekeurde bestanden worden apart gehouden in plaats van half doorgevoerd, en elke uitwisseling wordt gelogd met tijdstip, richting en resultaat. Loopt er iets mis, dan is zichtbaar welk bestand het betrof en waarom het is blijven liggen.
Die aanpak maakt de koppeling ook onderhoudbaar. Verandert Pivoton de opbouw van een bestand, dan is dat één plek in de code - niet een wirwar van aanroepen verspreid over de applicatie.
De koppelingen draaien op de server en zijn niet afhankelijk van een browser die openstaat. Bestandsuitwisseling gebeurt op vaste momenten en kan handmatig opnieuw worden gestart als dat nodig is. Fouten worden vastgehouden en later opnieuw aangeboden, zodat een tijdelijke onbereikbaarheid geen gegevens kost.
Toegang tot de bestandslocaties is beperkt tot de systemen die ze nodig hebben. Inhoud van bestanden wordt gevalideerd voordat er iets wordt aangemaakt of gewijzigd: een bestand dat niet aan de verwachte opbouw voldoet, wordt geweigerd in plaats van half verwerkt.
Na oplevering blijven we betrokken bij monitoring en onderhoud, en bij wijzigingen aan de kant van Pivoton of aan de eigen processen.
Een API-koppeling verbindt twee of meer softwarepakketten, zodat gegevens automatisch worden uitgewisseld. Zo hoeft u klant-, order- of voorraadgegevens niet meer handmatig over te typen en staan alle systemen altijd actueel.
De kosten hangen af van de complexiteit: het aantal systemen, de benodigde aanpassingen en of er een standaard-API beschikbaar is. Marktconform liggen eenvoudige koppelingen doorgaans tussen de €1.500 en €3.000; complexere integraties daarboven. Wij werken met heldere offertes met een onderverdeling per onderdeel.
Wij koppelen webshops, ERP-pakketten, CRM-systemen, boekhoudsoftware, plannings- en personeelssystemen, reserveringssystemen en dashboards. Denk aan Exact Online, AFAS, HubSpot, Carerix, Resengo of uw eigen maatwerksoftware.
Ja. Waar een moderne API ontbreekt, bouwen we een alternatieve route via bestandsuitwisseling (SFTP/XML), databases of een eigen API-laag tussen de systemen.
terug naar overzicht