Je hebt al developers, maar de wachtrij is lang en automatisering is niet hun specialisme. Hoe een externe partij naast een bestaand team werkt zonder dubbel werk.
Bedrijven met een eigen IT-team huren ons niet in omdat hun mensen het niet kunnen. Ze huren ons in omdat de wachtrij lang is en automatisering niet is waar hun team goed in is geworden. Dat is een andere samenwerking dan bij een bedrijf zonder technische mensen, en die vraagt om andere afspraken.
Een intern team heeft doorgaans een duidelijke prioriteit: het product, de kernapplicatie, de dingen waar klanten direct voor betalen. Automatisering van interne processen staat op dezelfde lijst, maar altijd eronder. Niet uit onwil, maar omdat het zelden urgent is tot het dat wel is.
Daar komt bij dat het ander werk is. Koppelingen bouwen tussen tien systemen die niemand heeft ontworpen om samen te werken, is een specialisme met eigen gereedschap. Een team dat gewend is aan een eigen codebase moet daarvoor een nieuwe manier van werken aanleren, en dat kost tijd die er niet is.
Die grens is het belangrijkste onderdeel. Zonder duidelijke afspraak eindigt elke wijziging in een discussie over wie hem had moeten opvangen, en dat kost meer dan het werk zelf.
Drie dingen. Ten eerste: welke systemen mogen wij benaderen en met welke rechten. Leesrechten waar het kan, schrijfrechten alleen waar het moet. Dat beperkt de schade als er iets misgaat en het maakt het makkelijker uit te leggen aan wie erover gaat.
Ten tweede: wat gebeurt er bij een storing en wie krijgt de melding. Ligt de fout in onze koppeling of in hun systeem? Zonder afspraak wordt dat een middag heen en weer terwijl het proces stilstaat. Wij bouwen daarom altijd meldingen in die zeggen welke stap faalde en waarom, zie pipeline-architectuur.
Ten derde: hoe wordt er overgedragen. Als jullie team het over een jaar zelf wil beheren, hoort dat vanaf dag één het uitgangspunt te zijn. Dat betekent documentatie die voor developers leesbaar is en geen constructies die alleen wij begrijpen.
Het gevoeligste punt is niet techniek maar positie. Een extern bureau dat binnenkomt kan overkomen als een oordeel over het interne team, zeker als het management het zo brengt. Dat is een slechte start en het is te voorkomen door de rolverdeling expliciet te maken: wij doen het werk waar zij geen tijd voor hebben, niet het werk dat zij niet kunnen.
Praktisch helpt het als de eerste opdracht iets is waar het interne team zelf ook van baalt. Een rapportage die iemand elke maandag met de hand maakt, een koppeling die al twee jaar op de lijst staat. Dan is de externe partij meteen nuttig in plaats van bedreigend.
Als het werk diep in de kernapplicatie zit, hoort het bij het interne team. Wij kennen dat systeem niet, en de tijd die het kost om het te leren kennen is bijna altijd meer dan de tijd die de wijziging kost. Dan is de nuttigste bijdrage die wij kunnen leveren de randen leeghalen, zodat er intern ruimte ontstaat.
Ook als er een duidelijke technische standaard is waar alles aan moet voldoen, is meebouwen op die standaard vaak verstandiger dan een parallel spoor. Dat kan: dan werken we in hun omgeving en met hun gereedschap. Zie ook uitbesteden of zelf doen.
Een externe partij die drie maanden bouwt en dan vertrekt, laat een systeem achter dat niemand kent. Dat is niet in het belang van jouw team en op termijn ook niet in het onze, want het eerste wat er dan gebeurt is dat er omheen wordt gebouwd.
Wat wel werkt is meekijken tijdens de bouw. Niet als opleiding met een programma, maar gewoon door de opzet een keer door te nemen en de belangrijke keuzes uit te leggen. Een uur per onderdeel is genoeg, en het verandert de overdracht van een document in iets wat mensen daadwerkelijk begrijpen.
Het tweede dat helpt is de eenvoudige aanpassingen expliciet bij het interne team leggen. Teksten, ontvangers, drempelwaarden en schema's horen in een tabel of een instelling te staan en niet in code. Dan kan jullie team het aanpassen zonder ons, en dat is precies de verdeling die op de lange duur het goedkoopst is.
Dat kan. Sommige klanten willen alles in hun eigen repositories en op hun eigen servers, andere laten ons de automatiseringslaag apart draaien. Beide werkt, mits de keuze vooraf gemaakt is.
Alleen als het niet anders kan en dan zo beperkt mogelijk. Voor het bouwen zelf is een testomgeving of een geanonimiseerde set meestal genoeg.
Door de grens vast te leggen en één contactpersoon aan elke kant aan te wijzen. Dat klinkt licht, maar het is het verschil tussen soepel en rommelig.
Ja, en dat is het uitgangspunt. Documentatie en broncode horen bij de oplevering, en we bouwen niets waar alleen wij mee overweg kunnen.
Voor afgebakende onderdelen wel. Wat we niet doen is detachering waarbij iemand van ons maandenlang in jullie team zit, want dat is een ander vak.
Staat er een lijst met dingen die al lang blijven liggen, dan is dat het beste startpunt voor een gesprek. Plan een gesprek of lees hoe wij systemen ordenen in van losse tools naar één AI-systeem.
dGEN Productions, AI agency en business-automation partner uit Eindhoven. info@dgenproductions.nl · 06-87413056