Je huurt geen los project in om je board tevreden te houden. Je huurt iemand in om een probleem op te lossen dat volgend kwartaal terugkomt. Dat is het verschil tussen een opdracht en een samenwerking, en het is geen semantiek. Het bepaalt of de kennis die opgebouwd wordt, bij jou blijft of vertrekt.
Wat een los project je eigenlijk kost
Een sprint van zes weken levert een rapport op, een dashboard, een korte overdracht. Daarna is het klaar. De consultant vertrekt met de kennis die tijdens die zes weken is opgebouwd. Welke velden in je CRM onbetrouwbaar zijn, waar attributie breekt tussen marketing en sales, welke uitzonderingen je forecast stil ondermijnen. Die kennis stond nooit op papier. Ze zat in het hoofd van iemand die nu een ander project draait.
Zes maanden later stokt de pijplijn opnieuw, of verandert je stack, of komt er een nieuwe AI-tool bij die je attributiemodel opnieuw door elkaar gooit. Je board vraagt wat er is veranderd sinds de vorige keer. Het antwoord is: niets structureels, want de vorige keer eindigde met een overdracht in plaats van met een doorlopend proces. Je huurt opnieuw iemand in. Die begint weer bij nul, want hij heeft de context van de vorige inhuur niet. Je betaalt twee keer voor dezelfde inwerkperiode, en de tweede keer met minder geduld van je board.
Er bestaat geen betrouwbare, citeerbare statistiek over hoeveel dit een scaleup structureel kost. Dat gat benoem ik liever eerlijk dan dat ik het opvul met een los percentage. Wat wel met zekerheid te zeggen is: elke overdracht is een reset, en elke reset kost tijd die je concurrent niet kwijt is.
Kennisverlies is geen mensenprobleem, het is een procesprobleem
Het makkelijke antwoord is: leg alles vast in documentatie, dan overleeft de kennis de overdracht wel. In de praktijk werkt dat niet, en wel om een precieze reden. De kennis die het meeste waard is, is nooit het proces zelf. Het is de reden waarom het proces zo is ingericht. Waarom deze uitzondering wel geautomatiseerd wordt en die andere niet. Waarom dit attributiemodel gekozen is boven het alternatief, en welke data-afspraak met welke afdeling gemaakt is.
Die redenen veranderen elk kwartaal een beetje, omdat je markt, je team en je stack veranderen. Een document dat die redenen vastlegt, is verouderd voordat het gelezen wordt. Wat wel werkt, is iemand die erbij blijft terwijl die redenen verschuiven, en die elke aanpassing aan het vorige kwartaal koppelt in plaats van aan een schone lei.
Dat is precies waarom ik geen sprints verkoop. Een doorlopende samenwerking betekent dat de context die in maand een is opgebouwd, in maand twaalf nog steeds werkt. Niet omdat ik het onthoud, maar omdat het proces zelf zo is ingericht dat elke stap voortbouwt op de vorige, met dezelfde attributielogica en dezelfde datastructuur.
Continuïteit in attributie en data-architectuur
Attributie is het duidelijkste voorbeeld van waarom een los project schade aanricht in plaats van waarde. Stel dat een eerste consultant een attributiemodel opzet dat leads koppelt aan campagnes op basis van UTM-parameters. Werkt. Zes maanden later huur je een tweede partij in voor een ander vraagstuk, en die partij voegt een tool toe die dezelfde leads via een ander model meet. Nu heb je twee cijfers voor dezelfde pijplijn, en niemand kan zeggen welke klopt. Je board krijgt een rapport waar de trend in ontbreekt, want de trend was al gebroken op het moment dat het model wisselde.
Data-architectuur werkt hetzelfde. Elke keer dat een nieuwe partij een nieuwe structuur voorstelt zonder de vorige te kennen, betaal je met een migratie die niemand had gepland. De structuur zelf wordt nooit het probleem. Het is de opeenstapeling van structuren die nooit met elkaar spraken.
Een doorlopende samenwerking voorkomt dat niet door perfectie te beloven. Ze voorkomt het doordat één partij verantwoordelijk blijft voor de continuïteit van het model, kwartaal na kwartaal. Elke aanpassing koppelt expliciet aan de vorige, in plaats van een nieuwe start te maken. Dat is minder spectaculair dan een nieuw dashboard, en precies daarom onderschat het je board.
Wat dit in de praktijk betekent
De samenwerking start met een doorlichting van je huidige attributie en data-architectuur. Waar het model klopt, waar het al stilzwijgend gebroken is, en welke aannames niemand meer kan onderbouwen. Daarna volgt geen einddatum, maar een ritme: meten, bijsturen, scherpstellen, elk kwartaal gekoppeld aan het vorige. Als je stack verandert, verandert het model mee zonder dat de geschiedenis verloren gaat. Als een medewerker vertrekt die het proces kende, blijft de kennis zitten in het lopende systeem, niet in zijn hoofd.
Dat vraagt om een andere houding dan een projectinkoop. Je koopt geen resultaat op een deadline. Je investeert in een partij die volgend kwartaal al kent voordat het begint, omdat ze erbij was toen dit kwartaal werd ingericht.
Mijn positie hierin
Ik geef oprecht om het resultaat op de lange termijn, niet om het volgende factuurmoment. Daarom kies ik zelf voor doorlopende relaties boven losse projecten, en zeg ik dat ook hardop tegen elke nieuwe klant. Op /visie/jouw-voordeel lees je hoe ik dat voordeel voor jouw organisatie concreet maak, los van deze pagina over waarom continuïteit zelf al waarde is. Verandert je stack door een nieuwe LLM-generatie, dan verschuift ook de samenwerking zelf: lees op /relaties/llm-veranderingen hoe. Het uitgangspunt achter die keuze staat op de homepage: relaties boven projecten, in alles wat ik doe.
Ik wil weten waar jouw attributie nu al stilzwijgend breekt, en wat een reset je de vorige keer heeft gekost. Dat gesprek voer ik liever voordat we beginnen dan achteraf, als het rapport al klaar is. Plan een gesprek en ik breng een eerste doorlichting van je attributie- en datastructuur mee, zodat je precies ziet waar de continuïteit nu ontbreekt.