Toegang is de vertraging, niet het bouwen

Op de offerte van een koppeling staat een bouwtijd van twee tot drie weken. De koppeling gaat twee maanden later live. Dat verschil is meestal geen slecht werk. Het is wachttijd, en hij zit bijna helemaal aan de kant van de opdrachtgever en van derden: de beheerder die een app moet goedkeuren, de leverancier die een koppelvlak moet openzetten, de accountant die de boekingsgang wil zien. Werkritme schrijft op de vragenpagina dat toegang tot de systemen in de praktijk vaker de vertragende factor is dan het bouwen. Hieronder staat wat die zin in dagen betekent, uitgesplitst voor één typisch project. Het project is samengesteld, de dagen zijn rekenaannames, en het totaal is een berekende indicatie.

Het project

Een handelsbedrijf met vijftien mensen krijgt zijn orders binnen via een bestelportaal van een branchepartij. Iemand typt die orders over in Exact Online, en daarna nog eens in het planningspakket van de eigen chauffeurs. De koppeling moet orders uit het portaal lezen, als verkooporder in Exact Online zetten en de rit in het planningspakket aanmaken. Dat is werk in de categorie Standaard van de aanpak: twee tot vier weken tot livegang, gerekend vanaf het moment dat de toegang er is. Hier is elf werkdagen bouwen, testen en livezetten aangenomen.

De tabel

Werkdagen, niet kalenderdagen. Bouwdagen zijn dagen waarop de bouwer aan het werk is. Wachtdagen zijn dagen waarop niemand aan het project werkt omdat een sleutel, een omgeving of een akkoord ontbreekt. De aanname per regel staat eronder.

Elf bouwdagen tegenover 32 wachtdagen. Opgeteld 43 werkdagen, bijna negen weken. Zo erg wordt het zelden, omdat wachttijden overlappen; daarover verderop. Maar in dit rekenvoorbeeld is de verhouding: van elke vier werkdagen die het project inneemt, wordt er op ongeveer één gebouwd.

Waarom elke wachtregel bij een ander ligt

Exact Online, drie dagen. Een koppeling met Exact Online werkt via OAuth met een app die bij Exact is geregistreerd. De registratie zelf is een formulier in het App Center van Exact; de documentatie van de Python-bibliotheek exactonline beschrijft het als inloggen in het App Center, naar "Apps beheren", een app aanmaken en de client id en client secret overnemen. Daarna moet iemand met voldoende rechten in de administratie van de klant de app toestemming geven, en dat per administratie. Die iemand is niet de bouwer. Het is de eigenaar of de kantoormedewerker met beheerrechten, en die heeft er die week ook nog een bedrijf bij te runnen. Drie werkdagen is een aanname voor een bedrijf waar de beheerder in huis zit; loopt het via het accountantskantoor dat de administratie beheert, reken dan langer.

Het bestelportaal, tien dagen. In dit voorbeeld heeft de branchepartij een koppelvlak, maar niet standaard open. Een verzoek gaat naar een servicedesk, die een ticket aanmaakt, die het doorzet naar iemand die over toegang gaat. Tien werkdagen is een aanname voor een partij die wel wil maar geen haast heeft.

Het planningspakket, zeven dagen. In dit rekenvoorbeeld hangt de API-toegang aan een aparte module van de leverancier. Het verzoek om toegang wordt daarmee een commercieel gesprek, en dat gesprek voert de eigenaar, niet de bouwer. Zeven dagen is de aanname voor offerte, akkoord en het aanzetten van de module.

De testomgeving, vier dagen. Testen op de echte administratie is riskant, en testen zonder echte orders zegt weinig. In de praktijk wordt er een aparte testadministratie ingericht of een set echte orders van vorige maand geanonimiseerd. Wie dat doet, is de klant, want de bouwer kent de administratie niet. Vier dagen.

De accountant, vijf dagen. Zodra een koppeling boekingen aanmaakt, wil de accountant doorgaans weten op welke grootboekrekening, met welke btw-code en wat er gebeurt met een order die niet klopt. Terecht, maar de vraag komt binnen op een kantoor dat die week ook aangiftes verzorgt; vijf werkdagen is aan de gunstige kant.

Testen, drie wachtdagen. De bouwer levert op donderdag; de medewerker die moet testen heeft er vrijdag geen tijd voor, en maandag en dinsdag ook niet. Het is werk dat naast het gewone werk komt. Dit is dezelfde wachttijd die in Negen dagen onderweg voor drie uur werk een offerte vier dagen in drie mailboxen liet liggen: niet de handeling is traag, de wachtrij ervoor is lang.

Als AFAS het pakket was geweest

De regel voor Exact Online ziet er bij AFAS anders uit, en in dit rekenvoorbeeld langer. Bij AFAS maakt de klant zelf een app-connector aan in Profit. Volgens de documentatie van AFAS regelt die app-connector de toegang: er hangt een gebruikersgroep aan, alleen gebruikers uit die groep mogen de service aanroepen, en de connector geeft alleen toegang tot de GetConnectoren en UpdateConnectoren die eraan gekoppeld zijn. Daarna volgt een token. Dat gaat volgens de tokenpagina via een activatiecode die per e-mail naar de gebruiker gaat, wat vereist dat de e-mailserver in de omgeving is ingesteld en dat de gebruiker een geldig e-mailadres heeft en lid is van die gebruikersgroep. Elk van die voorwaarden is een extra rondje met de AFAS-beheerder, zeker als dat een externe partij is. Als aanname voor de tabel: acht wachtdagen in plaats van drie, de GetConnectoren die de klant zelf aanmaakt niet meegerekend. Wat AFAS precies van de klant vraagt, staat op de AFAS-koppelingenpagina.

Wat er gebeurt als de wachttijden overlappen

De 32 wachtdagen staan in de tabel na elkaar, en zo hoeft het niet. De aanvraag bij de branchepartij, het gesprek met de leverancier van het planningspakket en de app-registratie in Exact Online kunnen alle drie op dag drie de deur uit. De vraag aan de accountant kan met het ontwerp mee, voordat er één regel is gebouwd. Dan blijft er ongeveer dit over: twee dagen ontwerp, tien dagen wachten op de traagste toegang, zes dagen bouwen, vijf dagen testen inclusief het wachten op de tester, één dag live. Vierentwintig werkdagen, bijna vijf weken. Meer dan het dubbele van de bouwtijd, maar geen negen weken.

Het verschil tussen negen en vijf weken zit dus niet bij de bouwer. Het zit in de vraag of iemand op dag één alle toegangsverzoeken tegelijk de deur uit doet, of ze één voor één laat komen zodra de bouwer erom vraagt.

Wat de eigenaar vooraf kan regelen

Alles wat hierboven wacht, wacht op een verzoek dat te laat is verstuurd. De lijst van elk systeem dat de koppeling aanraakt, met per systeem wie de beheerrechten heeft en of dat iemand in huis is, kan de eigenaar maken voordat er een bouwer in beeld is. Met die lijst gaan de verzoeken aan leveranciers de deur uit op de dag dat de opdracht wordt gegeven, en niet op de dag dat de bouwer meldt dat hij iets nodig heeft. De accountant hoort in diezelfde week de vraag hoe de boekingen eruit moeten zien, zodat het akkoord achteraf een controle is en geen ontwerpvraag. Wie zonder bouwer wil weten hoe zijn eigen tabel eruitziet, vult hem in met wat nu bekend is; voor elke regel waar het antwoord "geen idee wie" luidt, is een week wachten een redelijke aanname.

Waar de rekensom niet opgaat

De tabel gaat uit van partijen die een koppelvlak hebben en het willen openzetten. Heeft het bestelportaal geen koppelvlak, dan is dat geen wachtregel van tien dagen maar een ander project: export, inlezen, of een afspraak met de branchepartij waarvan de duur niet te ramen is. En bij een bedrijf waar de eigenaar zelf beheerder van alle systemen is en de accountant vooraf meekijkt, verdampen de meeste wachtregels; dan klopt de bouwtijd op de offerte gewoon. Dat is het geval waarin twee weken ook echt twee weken zijn, en dat is een bedrijf van vijf eerder dan een bedrijf van vijftig.

Wat een koppeling per pakket van de klant vraagt, aan registraties, rechten en sleutels, staat per pakket op de koppelingenpagina.