Configureren, kopen, integreren of bouwen?

Het oordeel in één zin. Configureer eerst wat je al hebt, koop als een pakket het hele gat dekt, integreer als het gat tussen systemen zit, en bouw alleen wat overblijft. Drie veelvoorkomende versies van deze keuze hebben een eigen pagina: deductiesoftware of een herontwerp, een ordercapture-tool of een herontwerp van de orderflow en de AI van je CDE of een verbonden dossier.

Als een operatie vastloopt, grijpen de meeste organisaties naar een tool. Dat is de verkeerde eerste stap. De betere eerste vraag gaat over de herkomst van de oplossing: welke delen van dit proces kun je afdekken met wat je al hebt, welke met iets wat je kunt kopen, welke moeten worden aangesloten op je bronsystemen, en wat is een echte leemte die maatwerk rechtvaardigt?

Dit artikel geeft een CIO, een securityverantwoordelijke en een proceseigenaar een manier om die vraag voor één operationeel proces te beantwoorden. Het gaat over waar de capaciteit vandaan komt en wie er daarna eigenaar van is. Het beslist niet welke stappen AI nodig hebben en welke gewoon regels zijn; die logicakeuze staat in AI of deterministische automatisering: een beslismatrix.

Vijf opties, scherp gedefinieerd

Discussies over bouwen of kopen lopen vaak vast omdat “bouwen” en “kopen” losjes worden gebruikt. In dit artikel gebruiken we ze zo.

De opties sluiten elkaar niet uit. De richtlijn van Microsoft over deze vraag beschrijft een spectrum: begin met een kant-en-klare tool, breid uit met low-code en schuif op naar maatwerk als de behoefte groeit. Ze zegt ook dat de benaderingen elkaar niet uitsluiten. Dat is een richtlijn van een leverancier, geschreven door een bedrijf dat op elk punt van het spectrum producten verkoopt. Gebruik ze dus als bruikbare woordenschat, niet als neutraal bewijs over welke route wint.

Begin bij het operationele probleem

Een keuze over de herkomst van de oplossing voordat je het proces begrijpt, is een gok met een inkooporder eraan vast. Leg dit vast voordat je opties vergelijkt:

1. Uitkomst en nulmeting. Wat is nu traag, fout of duur, hoe gemeten en over welke periode? Als je dat niet kunt zeggen, kun je ook niet vaststellen of een optie heeft geholpen.
2. Het pad. Wat komt binnen, wie beslist, welk systeem is leidend, waar wacht werk en wat gebeurt er als de normale route faalt?
3. De beslisrechten. Welke beslissingen zijn zo ingrijpend dat een benoemd persoon ze moet goedkeuren, ongeacht de tooling?
4. De randvoorwaarden. Datalocatie, rechten, auditplichten, regelgevende blootstelling, lopende contracten en beschikbare vaardigheden.

De AI-strategierichtlijn van Microsoft zegt voor het eigen publiek iets vergelijkbaars: begin bij bedrijfsproblemen en bij de activiteit en het resultaat die je verwacht, en kies daarna pas de technologie. Ze noemt ook vier factoren om een oplossing af te wegen: capaciteiten, benodigde data, vereiste vaardigheden en kosten. Die zijn bruikbaar bij elke leverancier, niet alleen bij Microsoft.

Een beslismatrix die je zelf kunt invullen

Beoordeel per stap van het proces hoe goed elke optie past. Het gaat niet om een totaalscore, maar om zichtbaar maken waar de echte meningsverschillen zitten.

De strategiepagina van Microsoft beschrijft dezelfde afweging in eigen termen: van kant-en-klare opties naar infrastructuur krijg je meer controle en lever je snelheid in, en elke stap vraagt meer technische vaardigheid en operationeel eigenaarschap. De matrix hierboven generaliseert dat voorbij één leverancier, maar de beoordelingen zijn inschattingen, geen meetdata. Vervang ze door je eigen bewijs.

Vragen die je van kolom laten wisselen

Loop ze in volgorde door. Stop bij het eerste “ja” dat een stap beslist.

1. Dekt een tool waarvoor we al betalen deze stap, op echte data en met echte rechten? Zo ja, configureer en meet. Test met je eigen documenten, uitzonderingen en randgevallen, niet met de demo van de leverancier.
2. Zo niet, dekt een pakketproduct het hele pad, inclusief uitzonderingen? Vraag het foutpad te zien, niet het ideale pad. Zo ja, koop, maar reken integratie en eigenaarschap mee, niet alleen de licentie.
3. Heeft de stap data of acties nodig uit bronsystemen? Dan integreer je, welke optie je hierboven ook koos. Bepaal het leidende systeem, gebruik ondersteunde interfaces, geef service-identiteiten minimale rechten, begrens wat automatisering mag schrijven en houd een goedkeuringspunt voor ingrijpende acties.
4. Blijft er een leemte die zowel materieel als onderscheidend is? Bouw dan alleen dat, als afgebakend onderdeel met tests, documentatie en een benoemde onderhouder. Bouw geen platform voor één enkele stap.
5. Is het echte probleem een beslisrecht, een overdracht of slechte gegevensinvoer? Dan is het antwoord eerst een procesaanpassing.

Wat een CIO of securityreviewer van elke optie mag vragen

Welke kolom ook wint, de due-diligencevragen lijken op elkaar. Het NIST-profiel voor generatieve AI (een vrijwillige richtlijn, geen certificering) beveelt onder meer aan om de due diligence bij het verwerven van generatieve AI te actualiseren, derden met toegang tot organisatie-inhoud te inventariseren, te bepalen wie eigenaar is van incidentrespons bij technologie van derden en incidentrespons en reactietijden in leveranciersovereenkomsten te regelen. Vertaald naar vragen over de herkomst van de oplossing:

• Inventaris: welke derden, modellen en datastores raken dit proces, en wie beheert die lijst?
• Rechten: wat kan elk onderdeel lezen en schrijven, en kan dat per actie worden beperkt?
• Falen en herstel: wat gebeurt er als een onderdeel niet beschikbaar, fout of gewijzigd is? Wie wordt gebeld en wat wordt teruggedraaid?
• Audit: kun je reconstrueren wie of wat heeft beslist, op welk bewijs en met welk gevolg?
• Eigenaarschap: wie beheert monitoring, wijzigingsbeheer, incidentrespons en het contract?
• Uitstap: kun je je data en configuratie exporteren, en wat zou vervanging inhouden?

Kan een optie dit niet schriftelijk beantwoorden, dan is dat een bevinding, hoe de demo er ook uitzag.

Een synthetisch voorbeeld

Het volgende is illustratief en verzonnen; het beschrijft geen klant.

Het financeteam van een middelgrote distributeur besteedt uren aan het afletteren van betalingsberichten op openstaande facturen. Er zijn vier routes.

• Het ERP-systeem heeft al een regelgebaseerde matchfunctie. Configureer die eerst voor exacte matches en bekende referentieformaten van klanten.
• Een pakket voor het toewijzen van betalingen kan de overige matches misschien aan, maar de proefversie gaat slecht om met deelbetalingen met deducties. Kopen blijft geparkeerd totdat het uitzonderingspad op de echte betaalbestanden van het bedrijf is getest.
• Niet-gematchte posten vragen bankdata, ERP-gegevens en klantcorrespondentie. Dat is een integratievraag: welke interfaces worden ondersteund, welke identiteiten mogen wat lezen en waar keurt een mens een afboeking goed.
• Een maatwerkonderdeel voor ongebruikelijke betaalformaten kan gerechtvaardigd zijn, maar pas nadat de eerste drie zijn getest. Bouwen blijft beperkt tot die ene leemte, met een benoemde onderhouder.

Het resultaat is een gemengd antwoord, wat normaal is. Verschillende stappen komen op verschillende manieren tot stand en het beslisdossier noemt per stap een eigenaar, een test en een uitstapweg.

Faalwijzen om tegen te ontwerpen

Wat dit niet bewijst

Dit artikel biedt criteria en woordenschat. Het laat niet zien dat een optie in het algemeen goedkoper, sneller of veiliger is; het aangehaalde materiaal bestaat uit richtlijnen van een leverancier en een vrijwillige standaard, en het voorbeeld is synthetisch. Het zegt niets over welke producten nu welke integraties ondersteunen, en zulke feiten moet je aan actuele documentatie toetsen voordat je erop vertrouwt. De uitkomst van zo’n keuze hangt af van je systemen, contracten, vaardigheden en risicobereidheid, en een beslisdossier is maar zo goed als de tests erachter.

Waar Sembium past

Sembium werkt aan hele operationele processen: analyse, herontwerp, integratie, adoptie en meting, met deterministische regels voor bekende paden, begrensde AI waar interpretatie helpt en verantwoordelijke mensen voor ingrijpende beslissingen. In die context is de herkomstkeuze één ontwerpbeslissing binnen een programma, genomen na de nulmeting en vóór de bouw. Zie de aanpak voor hoe een programma is opgebouwd, en wat een agentic operating layer is voor wat over deze keuzes heen ligt zodra je ze hebt gemaakt.

Heb je een knelpunt dat je $1M of meer kost en dat je opgelost wilt hebben? Plan het gesprek van 30 minuten. Neem één proces mee. Je krijgt één praktische aanbeveling en een helder antwoord of het past.