Er is een API, en toch typt iemand de uren over
Je klant zegt dat zijn kloksysteem een API heeft. Waarom de uren dan nog met de hand worden overgenomen, en vijf vragen die je vooraf stelt.
Je vraagt je klant of zijn kloksysteem te koppelen is. Het antwoord is ja, er is een API. Drie maanden later maakt iemand bij jou nog steeds elke week dezelfde export en typt de uitkomst over.
Dat is geen onwil, aan geen van beide kanten. Tussen "er is een API" en "de uren komen goed binnen" zitten een paar vragen die aan het begin bijna nooit gesteld worden.
In het ankerartikel over urencorrecties staat dat de keten zijn betrouwbaarheid verliest op de overdrachten. Dit is de eerste overdracht, en de duurste.
Wat open in de praktijk betekent
Dat er een koppeling bestaat, zegt nog niets over vier dingen.
Het niveau. Geeft de koppeling ruwe kloktikken, of alleen uren die de klant al heeft goedgekeurd? Goedgekeurde uren zijn een uitkomst, geen registratie. Wat er onderweg is afgerond, samengevoegd of stilzwijgend rechtgezet, zie je niet meer terug.
Het ritme. Een batch per nacht is prima. Een batch per week wordt een probleem zodra jouw verloning eerder draait dan de goedkeuring bij de klant. Dan kloppen de uren wel, maar te laat, en corrigeer je alsnog een periode terug.
Het kenmerk. Komt een medewerker terug met een vast nummer, of met een naam en een afdeling? Op naam matchen werkt tot de eerste dubbele achternaam of de eerste roepnaam in het veld. Bij honderd plaatsingen valt dat op. Bij duizend is het een structurele foutbron.
De toeslagen. Het kloksysteem weet dat er na zes uur is doorgewerkt. Jouw cao weet welk loonbestanddeel daarbij hoort. Die vertaling zit nergens in, tenzij iemand hem bouwt en bijhoudt.
Elke klant heeft zijn eigen systeem
In gesprekken met uitzenders en detacheerders komt dit in dezelfde vorm terug: de uren komen uit de systemen van tientallen klanten, elk met een eigen pakket, een eigen versie en een eigen indeling. Waar jij per plaatsing en per opdracht denkt, denkt de klant per kostenplaats of per werkorder.
Die vertaalslag is het echte werk. De technische verbinding ligt er meestal in een week; twee administraties in elkaar laten passen kost langer. Daarom is "we koppelen systeem X" de verkeerde eenheid van werk. De eenheid is een klant, van geregistreerd uur tot goedgekeurde factuur.
De koppeling ligt tussen twee organisaties
Dat heeft twee gevolgen die vaak pas later opvallen.
Het eerste is dat de IT-afdeling van je klant eigen prioriteiten heeft. Jouw doorlooptijd is daar geen doel. Zet wat je nodig hebt daarom in de afspraken met de klant zelf, en niet alleen in een technische bijlage.
Het tweede is dat het onderhoud makkelijk bij een persoon belandt. In diezelfde gesprekken kwam dat terug: kennis en support van de koppelingen zitten bij een medewerker. Zolang die er is, werkt het. Daarna is het een zwarte doos, precies op het moment dat de klant zijn systeem update.
En uren zijn persoonsgegevens. Daar horen afspraken over bij tussen jou en je klant. Regel die aan het begin, niet bij de oplevering.
Vijf vragen voordat je bouwt
- Wat geeft de koppeling terug: kloktikken of goedgekeurde uren?
- Hoe vaak, en hoe komt een correctie na goedkeuring alsnog bij jou binnen?
- Welk kenmerk identificeert de medewerker en de plaatsing, en blijft dat kenmerk gelijk?
- Wie vertaalt de toeslagcodes van de klant naar jouw loonbestanddelen, en waar staat die tabel?
- Wie belt wie als de klant zijn systeem gaat updaten?
Blijven vier van de vijf onbeantwoord, dan heb je geen koppeling. Dan heb je een intentie.
Wat je wel kunt bouwen
Zorg dat de koppeling zichtbaar is. Een laag die binnenhaalt wat het systeem van je klant wel geeft, die vastlegt wat het niet geeft (toeslagen, uitzonderingen, afwijkende afspraken), en die bij elke urenregel bewaart waar hij vandaan komt en wie hem heeft aangepast.
Dan is een correctie te volgen. En dan zie je na twee periodes bij welke klant en op welke stap de correcties ontstaan, in plaats van alleen dat het totaal niet klopt.
Begin met een klant, bij voorkeur degene met de meeste correcties of het meeste volume, want daar is het effect het snelst te meten. Een keten die van begin tot eind klopt levert meer op dan een inventarisatie van veertig systemen. Zo pakken wij het ook aan: eerst een keten af, dan de volgende.
Volgende keer: hoe je aantoonbaar maakt wat er is afgesproken en wat er is uitbetaald, zonder dat het elke maand handwerk is.
Meer weten over dit onderwerp?
Plan een Discovery-sessie en bespreek hoe dit past bij jouw situatie.