Samenvatting
“Doe-het-zelf” omvat twee verschillende dingen. Bij ‘licht doe-het-zelf’ blijft de AI die je al gebruikt behouden en bouw je de onderliggende kennislaag op: ongeveer vijf maanden en € 135.000 in het eerste jaar. Bij ‘volledig doe-het-zelf’ bouw en onderhoud je de agent, de datapijplijn en de interfaces: ongeveer tien maanden en € 290.000. Chapter kost ongeveer € 22.000 in het eerste jaar, met een geschatte doorlooptijd van drie weken tot de lancering.
Het gebruik van ‘ AI ’ om informatie uit documenten op te halen is relatief eenvoudig. Het kost echter veel werk om de antwoorden correct te houden – tot op het onderdeelnummer nauwkeurig – in duizenden bestanden en technische gegevens, terwijl uw producten veranderen. Als we de volledige twaalf maanden aan exploitatiekosten na de initiële implementatie meerekenen, wordt het kostenverschil nog groter. In beide doe-het-zelfscenario’s betekenen de langere doorlooptijden ook een gemiddeld verlies van ongeveer € 28.000 aan uitgestelde voordelen door tijdwinst en een lagere ondersteuningswerkdruk.
Zelf bouwen is zinvol als je projectomvang beperkt blijft, je al over gestructureerde productkennis beschikt en de technici hebt om deze te onderhouden, of als je eisen hebt waaraan geen enkele leverancier kan voldoen. Anders biedt aankoop een snellere terugverdientijd en lagere lopende kosten, terwijl je technici zich kunnen blijven richten op je producten.
"We zouden dit zelf kunnen bouwen."
Dat is een terechte opmerking, en je zou die moeten maken voordat je bij wie dan ook geld uitgeeft. Ook bij ons, wat het schrijven van dit bericht wel een beetje ongemakkelijk maakt. Laten we dus eens kijken waar je een beslissing over neemt.
Je programmeur richt een LLM op een map met handleidingen en zorgt ervoor dat er tegen vrijdag iets werkt. Het beantwoordt vragen. Het citeert een document. In een demo ziet het er af uit.
Dus: waarom zou je een platform kopen voor iets waarvoor je binnen een week al een prototype hebt gemaakt?
Omdat een werkend prototype geen productiesysteem is. Het prototype geeft antwoord op vragen op basis van een stapel PDF’s. Het productiesysteem moet de juiste procedure voor de juiste productvariant weergeven en vermelden van welke pagina die afkomstig is. Het moet over drie jaar nog steeds kloppen, na twee productlanceringen, een overstap naar een ander koelmiddel en het vertrek van de ingenieur die het heeft gebouwd.
En dit is het moeilijkste deel. Je stelt deze vraag omdat je helpdesk onder druk staat: steeds weer dezelfde foutcodes, escalaties die slechts twee mensen in het gebouw kunnen oplossen, en de piek in de vraag in januari of juli. Juist die druk maakt een betrouwbare kennislaag zo waardevol. Het is ook de reden waarom niemand tien maanden aan ontwikkeltijd over heeft om er een goed uit te werken.
Dat is waar het echt om draait: of je team de tijd heeft om het te ontwikkelen en te onderhouden. Niet of ze het zouden kunnen.
Waarom dit voor een fabrikant moeilijker is dan voor een softwarebedrijf
In de meeste adviezen over ‘zelf bouwen of kopen’ wordt uitgegaan van een softwarebedrijf met een ondersteuningscentrum, één product en één taal. Jij bent een fabrikant van apparatuur. Er zijn vier verschillen. Alle vier brengen extra kosten met zich mee.
Met één set documenten richt je je op drie doelgroepen: je eigen aftersales- en eerstelijnsondersteuningsteam, een netwerk van installateurs die niet in dienst zijn bij je bedrijf, en eindklanten. Dezelfde handleidingen, drie kennisniveaus, drie verschillende toleranties ten aanzien van een fout antwoord. Dat is niet één assistent met een lijst met veelgestelde vragen. Het is één kennisbank met drie zorgvuldig op maat gemaakte weergaven.
Uw netwerk van installateurs is afhankelijk van uw ondersteuningsteam wanneer de handleiding geen duidelijk antwoord biedt. U hebt geen zeggenschap over hun opleiding, maar hun vragen komen toch op uw bureau terecht. Chapter heeft drie jaar lang installateurs opgeleid voordat we software voor hen gingen ontwikkelen. Die ervaring heeft ons laten zien dat er behoefte is aan ondersteuning die verder gaat dan de leszaal: hulp bij het vinden van het juiste antwoord terwijl het werk wordt uitgevoerd.
Uw documentatie is altijd enigszins verouderd. Productlanceringen, aanpassingen aan de specificaties, wijzigingen in de F-Gas-regelgeving, de overgang naar R290. Door elk van deze factoren kan een handleiding niet meer aansluiten bij een apparaat dat al bij iemand thuis is geïnstalleerd.
Je bent in verschillende landen actief en hebt te maken met seizoenspieken. Een Duitse vraag die in januari wordt beantwoord aan de hand van een Spaanse handleiding, in het Nederlands, terwijl de wachtrij het langst is en je beste technicus op vakantie is.
Dit is allemaal niet zo bijzonder. Het is gewoon een veel zwaardere omgeving dan ‘de documenten indexeren en een chatvenster toevoegen’.
Twee manieren om het zelf te bouwen
De afweging ‘zelf bouwen of kopen’ verhult iets belangrijks: ‘zelf bouwen’ verwijst naar twee heel verschillende projecten. De omvang verschilt al voordat de kosten dat doen.
%20(1).png)
Traject A — eenvoudige doe-het-zelfoplossing: houd je assistent aan, bouw de kennislaag op
Je maakt al gebruik van een assistent, of je CRM-leverancier levert er een mee. Deze verwerkt de bestelstatus, maar heeft moeite met productgegevens omdat hij deze moet afleiden uit ongestructureerde documenten.
Je bouwt dus alleen de onderliggende laag: je structureert honderden technische gegevenspunten, voegt controles in voor het ophalen en detecteren van fouten in, en houdt de gegevens up-to-date naarmate de specificaties veranderen.
Een beperktere reikwijdte, een kortere tekst. Maar dit is het niveau waarop wordt bepaald of een antwoord over een specifieke variant juist is of alleen maar goed klinkt.
≈ € 110.000 aan bouwkosten · ≈ € 45.000 per jaar aan exploitatiekosten · ≈ 5 maanden tot ingebruikname · eerste jaar ≈ € 135.000
Track B — volledig zelf te realiseren: assistent en kennissysteem, van begin tot eind
Uw team bouwt de assistent, de pijplijn en de interfaces, en is vervolgens verantwoordelijk voor het geheel. Het waarborgen van de nauwkeurigheid en het beheer vereist realistisch gezien 2–3 FTE. Het leveringsrisico blijft bij u liggen.
≈ 270.000 euro bouwkosten · ≈ 130.000 euro/jaar exploitatiekosten · ≈ 10 maanden tot stabiele bedrijfsvoering · eerste jaar ≈ 290.000 euro
Beide schattingen zijn gemiddelde waarden, gebaseerd op de totale kosten van 2 FTE voor lichte DIY en 2,5 FTE voor volledige DIY, plus gereedschap en infrastructuur. Onze cijfers, onze aannames. Vul je eigen totale kosten per ingenieur in voor een nog eerlijkere vergelijking.
Wat de ‘ demo ’ niet laat zien
Dit is het werk dat het midden houdt tussen een prototype en iets wat je aan je helpdesk, je netwerk van installateurs en je klanten zou voorleggen.
Structuur, niet alleen stukjes. Dit is wat mensen verbaast.
Het team van Claas Rühling bij Solvis stelde het na een eigen test duidelijk vast: het samenvoegen van de documenten werkte niet. De kwaliteit van de antwoorden verbeterde pas toen de gegevens gestructureerd werden.
De reden hiervoor is specifiek voor uw bedrijf. Bij vrijwel identieke productvarianten schiet generieke zoekopdrachten tekort, omdat het verkeerde antwoord er precies hetzelfde uitziet als het juiste. Om dit goed te doen, is een gevalideerde grafiek nodig met begrippen, onderdeelnummers, relaties en meertalige synoniemen. Elk knooppunt moet een betrouwbaarheidsscore hebben en worden goedgekeurd door iemand die de producten daadwerkelijk kent. Productiegrafieken kunnen tienduizenden knooppunten bevatten.
De curatietool die uw experts daadwerkelijk zullen gebruiken in plaats van een spreadsheet, is een product op zich.
Bestandsopslag die verder gaat dan je gewone SharePoint. Geen overzichtelijke map met PDF’s. Montagevideo’s, servicebulletins in Word, spreadsheets, foto’s, dezelfde handleiding die op drie sites is gedupliceerd, mappen die je volgens IT niet mag indexeren. En verwijdering waarbij ook de afgeleide gegevens worden gewist, niet alleen het bestand, zoals een verzoek tot verwijdering op grond van de AVG vereist.
Een controle die de vraagsteller ter plekke kan uitvoeren. Elk antwoord moet vergezeld gaan van een verwijzing naar het document en de pagina, zodat een technicus het kan controleren voordat hij actie onderneemt. Dat is wat een antwoord op AI van een ‘black box’ verandert in iets dat de toetsing door een ingenieur, een audit of een garantieclaim kan doorstaan.
Een manier om te achterhalen wat er mis is gegaan. Elk systeem levert wel eens verkeerde antwoorden op. De vraag is of jouw systeem elke fout in een bijgehouden wachtrij plaatst, met een verantwoordelijke en een telling van hoe vaak de vraag is gesteld.
Drie verschillende problemen vragen om drie verschillende oplossingen: de kennis ontbrak, de kennis was wel aanwezig maar de medewerker ging er verkeerd mee om, of het bewijs was te mager om een conclusie te onderbouwen. De meeste dashboards melden het eerste, bestempelen het tweede ten onrechte als het eerste en presenteren het derde als een feit.
Een testreeks voor je antwoorden, niet alleen een beoordelingsknop. Duimpjes omhoog en omlaag zijn belangrijk. Een beoordeling, en dan vooral de opmerking die iemand bij een duimpje omlaag achterlaat, is het snelste signaal dat er iets mis is. Die wordt direct in de wachtrij hierboven opgenomen. Maar beoordelingen komen pas binnen nadat het antwoord al is gepubliceerd.
Er zit dus nog een tweede laag onder. Elk bestand dat je invoert, genereert een reeks voorbeeldvragen. Die reeks fungeert tegelijkertijd als evaluatieset voor het document: bekende vragen, bekende bronpagina’s, verwachte antwoorden.
Die vragen worden omgezet in toetsen waarop punten te verdienen zijn. Is het antwoord gebaseerd op de pagina waarnaar wordt verwezen? Wordt de juiste productvariant gekozen? Wordt er niet gegokt wanneer de documentatie daar echt geen uitsluitsel over geeft? Elke doorloop wordt bijgehouden als een experiment en vergeleken met de vorige.
Dat is wat je laat zien of een wijziging in de prompt , een modelupgrade of een andere chunking-strategie de antwoorden beter heeft gemaakt in plaats van alleen maar anders. Het is ook het onderdeel dat bijna nooit voorkomt in een zelfgemaakte schatting. Zonder dit kun je niet betrouwbaar meten of een modelupgrade heeft geholpen of juist schade heeft aangericht.
Toegangsrechten voor drie doelgroepen: medewerkers, installateurs en eindklanten die allemaal uit één kennisbank putten, waarbij elk de informatie ziet die voor hem of haar bestemd is, zonder dat er drie kopieën moeten worden bijgehouden die stilletjes uit elkaar groeien.
Naleving. ISO 27001, AVG, voorbereiding op de EU-wet inzake de bescherming van de persoonlijke gegevens ( AI ), hosting binnen de EU. Als je het zelf opzet, wordt elk project jouw project, jouw audit en jouw verantwoordelijkheid.
Kostenberekening. De financiële afdeling zal uiteindelijk vragen wat een opgeloste kwestie kost.
Het patroon is bij al deze projecten hetzelfde: de laatste fase duurt langer dan alles wat eraan voorafgaat, en het grootste deel van de kosten van het systeem wordt gemaakt nadat het in gebruik is genomen, niet daarvoor.
De cijfers, naast elkaar
.png)
Hoe de totalen van het eerste jaar worden berekend
Dejaarlijkse exploitatiekosten hebben betrekking op een volledig jaar exploitatie. De totalen voor het eerste jaar omvatten de bouw- of installatiekosten plus de exploitatiekosten die voor dat eerste jaar zijn begroot: ongeveer € 25.000 voor ‘Light DIY’, € 20.000 voor ‘Full DIY’ en € 20.712 voor ‘ Chapter ’.
De DIY-totalen omvatten dus exploitatiekosten voor een deel van het jaar, terwijl het totaal van Chaptereen vergoeding voor een volledig jaar omvat. Bij de DIY-ramingen wordt uitgegaan van 2 fulltime medewerkers voor ‘Light DIY’ en 2,5 voor ‘Full DIY’, inclusief personeelskosten, plus gereedschap en infrastructuur.
Wat houdt de schatting van de ‘ Chapter ’ precies in?Een installatieteam ter ondersteuning van interne medewerkers, 50 nieuwe installateurs onboarding per jaar, ongeveer 200 actieve installateurs in het veld, 20% van de supportverzoeken die worden omgeleid, en een publieksadviseur op uw website.
Dat komt neer op ongeveer 2.950 antwoorden per maand. De eerste 1.500 zijn inbegrepen; voor de overige 1.450 wordt het standaardtarief voor extra antwoorden in rekening gebracht.
De lopende kosten worden berekend op basis van het gebruik volgens de tarieflijst. Hoe minder u gebruikt, hoe lager de kosten voor extra verbruik. Er zijn geen kosten per werkplek, dus u hoeft hier geen rekening mee te houden als uw team of installateursnetwerk groeit. Alle weergegeven kosten en tijdschema’s zijn schattingen.
Als we de initiële bouwkosten plus 12 maanden aan exploitatiekosten meerekenen, wordt het verschil in het voordeel van kopen nog groter: ongeveer € 155.000 voor ‘Light DIY’ en € 400.000 voor ‘Full DIY’, vergeleken met € 22.212 voor ‘ Chapter ’. Naast deze kosten heeft een snellere start ook zijn voordelen: hierna bekijken we wat de lanceringstijd van ongeveer 3 weken voor Chapterbetekent in vergelijking met 5 maanden voor „Light DIY“ of 10 maanden voor een stabiel „Full DIY“-systeem.
Elke maand die je besteedt aan het bouwen, is weer een maand waarin je voor het probleem betaalt
Chapter gaat over twee tot vier weken live. De ontwikkeling duurt vijf tot tien maanden. Die vertraging brengt kosten met zich mee: maandenlange efficiëntiewinst waarvan je team nu al zou kunnen profiteren.
%20(1).png)
Ons model gaat ervan uit dat, zodra een van beide opties in gebruik is, de besparing op tijd en de vermindering van de ondersteuningswerkzaamheden dezelfde waarde zal hebben: ongeveer € 53.000 per jaar, of € 4.400 per maand.
In beide doe-het-zelf-scenario’s gaat Chapter gemiddeld zo’n 6,5 maanden eerder live. Dat betekent dat de voordelen door het zelf bouwen met ongeveer € 28.000 worden uitgesteld, bovenop de bouwkosten.
Dat bedrag vind je niet terug in de projectbegroting. Je vindt het terug in de uren die je team nog steeds besteedt aan het zoeken naar antwoorden, het inwerken van installateurs en het afhandelen van support-escalaties terwijl de bouw nog in volle gang is.
Waar het risico ligt
Bij technische ondersteuning is een verkeerd antwoord niet hetzelfde als het aanbevelen van de verkeerde film. Het is meer alsof je een monteur de onderhoudshandleiding voor het verkeerde verwarmingssysteem geeft: de procedure lijkt misschien relevant, maar geldt voor een ander apparaat. Dat leidt tot een veiligheidsrisico en een garantieprobleem, niet alleen tot een slechte klantervaring. „Bijna goed genoeg” is prima voor een filmaanbeveling. Maar niet voor een monteur die in de winter aan iemands verwarmingssysteem werkt.
%20(1).png)
Door deze oplossing aan te schaffen, wordt de technische en onderhoudslast voor uw team verlicht. Chapter biedt hosting binnen de EU, ISO 27001-gecertificeerd beveiligingsbeheer en antwoorden die tot aan de bron kunnen worden getraceerd. In ons Trust Center vindt u gedetailleerde informatie over onze beveiligings-, privacy- en nalevingsmaatregelen, zodat uw team deze kan toetsen aan uw vereisten. U blijft eigenaar van uw technische inhoud, de beslissingen over de toegang en de manier waarop het systeem wordt gebruikt.
Wanneer je moet bouwen
We zien liever dat je zelf een platform bouwt dan dat je er een koopt die niet past. In sommige gevallen is zelf bouwen de juiste keuze.
- Je werkterrein is klein en zal klein blijven. Eén productfamilie, één taal, handleidingen die één keer per jaar worden bijgewerkt, en alleen vragen van je eigen technici. Veertig PDF’s en twaalf ingenieurs. Dat is prima te doen met een goed gelabelde map, totdat er een tweede taal bijkomt, een variant die op één onderdeelnummer afwijkt, of een netwerk van installateurs waarvoor je nooit training hebt gegeven.
- Je beschikt al over een kennisgrafiek. Je producten, onderdelen, synoniemen en procedures zijn gemodelleerd als gevalideerde entiteiten en relaties, die worden onderhouden door mensen die daar hun werk van maken, met een releaseproces wanneer er wijzigingen in het model worden aangebracht. Dat is het dure deel. Een opvraaglaag daarbovenop is een bescheiden project. De meeste OEM’s hebben PDF’s, geen grafiek. Als je de grafiek hebt, ga dan aan de slag.
- Je hebt de technici drie jaar tot je beschikking, niet slechts een kwartaal. Iemand voert de herziene handleidingen opnieuw in en verwijdert de oude pagina’s, werkt elk antwoord bij wanneer een productlijn naar R290 wordt verplaatst, voert de testset opnieuw uit wanneer je modelleverancier een model uit de roulatie haalt, en spoort de vragen op die vorige maand niet goed waren beantwoord, terwijl minder dan één op de tien gebruikers op een duim klikt. Als je al een modelgateway en evaluatiesysteem voor andere afdelingen beheert, is die klus een stuk goedkoper. Als die mensen er zijn en er in 2029 nog steeds zullen zijn, ga je gang.
- Je hebt een strikte eis waaraan geen enkele leverancier kan voldoen. Een locatienetwerk dat nooit verbinding maakt met de buitenwereld. Een contract dat het gebruik van externe verwerkers volledig uitsluit. Een grafiek op basis van je eigen schema waarnaar de assistent gegevens moet terugschrijven. Of het verder wel voldoet, doet er niet toe.
De wens om de assistent in je eigen installatie-app of -portaal te hebben, staat niet op deze lijst. Een API doet dat, en je bespaart jezelf drie jaar onderhoud.
Als geen van deze punten op jou van toepassing is, kan je team het nog steeds bouwen. De vraag is of je wilt dat ze de komende drie jaar besteden aan het up-to-date houden ervan in plaats van aan je producten.
Vragen die je jezelf moet stellen voordat je een verbintenis aangaat
- Wie onderhoudt dit als de ingenieur die het heeft gebouwd, vertrekt?
- Hoe gaat het om met twee varianten waarvan de handleidingen slechts één alinea van elkaar verschillen?
- Wie keurt goed dat een antwoord over een onderdeelnummer correct is, en in welke tool?
- Wat gebeurt er met een vraag die we niet kunnen beantwoorden? Wie neemt die dan over?
- Hoe weten we of een modelupgrade de antwoorden heeft verbeterd, in plaats van dat er stilletjes enkele antwoorden niet meer kloppen?
- Hoe kunnen we medewerkers, installateurs en eindklanten vanuit één bron bedienen zonder dat we drie afzonderlijke bronnen hoeven te onderhouden?
- Wie is verantwoordelijk voor ISO 27001, de naleving van de EU- AI wet en verzoeken tot gegevensverwijdering?
- Wat zijn de totale kosten in het derde jaar, niet in het eerste jaar?
- Wat zouden deze ingenieurs in plaats daarvan kunnen bouwen?
Als er meer dan drie daarvan geen eigenaar hebben, ben je bezig met het in kaart brengen van een product, niet van een project.
Hoe het aankoopproces er in de praktijk uitziet
Solvis, een Duitse fabrikant van verwarmingssystemen met 300 medewerkers, heeft inmiddels 234 bestanden in Chapter. Met behulp van die bestanden heeft het systeem duizenden technische vragen beantwoord zonder deze door te sturen naar een specialist, waardoor honderden uren zijn vrijgekomen voor veldwerk. Dat betekent minder onderbrekingen bij de technische helpdesk en meer tijd om aan verwarmingssystemen te werken. Solvis verwacht dat, naarmate het systeem verder wordt ontwikkeld, tot wel 50% van de vragen kan worden beantwoord zonder tussenkomst van een specialist.
.png)
Het praktische nut is dat een technicus de juiste procedure kan vinden, met een bron die hij kan raadplegen, zonder een specialist te hoeven storen. Het moet ook beschikbaar zijn op de plek waar het werk plaatsvindt: in het CRM terwijl de klant nog aan de lijn is, op het installateursportaal, op uw openbare website. Net als een stuk gereedschap dat binnen handbereik wordt bewaard in plaats van achter in het magazijn, moet het beschikbaar zijn op de plek waar het wordt gebruikt. Uiteindelijk is het aan u om te beslissen.
%20(1).png)
Er zijn tal van goede technische teams die een kennislaag voor hun producten zouden kunnen opzetten. De moeilijkere vraag is of jouw team de komende drie jaar zou moeten besteden aan het onderhouden ervan: het structureren van honderden of duizenden technische gegevenspunten, het apart houden van productvarianten, het opnieuw invoeren van bijgewerkte handleidingen, het opvullen van kennislacunes en het controleren of elke wijziging nog steeds betrouwbare antwoorden oplevert.
De veelgestelde vragen worden doorgaans behandeld in de handleidingen. De ingewikkelde vragen kosten je ondersteuningsteam veel tijd: het koppelen van een procedure aan het exacte model, het nagaan van de compatibiliteit tussen onderdelen of het afstemmen van een servicebulletin op een oudere installatiehandleiding. Het systeem moet die informatie met elkaar in verband brengen, de bronnen vermelden en vragen markeren die het niet op betrouwbare wijze kan beantwoorden.
Als u dit zelf opzet, moet u ervoor zorgen dat deze mogelijkheden behouden blijven naarmate uw producten en documentatie veranderen. Chapter zorgt voor die infrastructuur en onderhoudt deze, zodat uw specialisten minder tijd hoeven te besteden aan het zoeken naar en controleren van informatie, en meer tijd hebben om complexe zaken op te lossen.
Welke aanpak je ook kiest, stel jezelf eerst één vraag: aan welke zaken heeft je ondersteuningsteam vorige maand de meeste tijd besteed, en hoeveel van die tijd ging er op aan het zoeken naar en controleren van informatie voordat ze hun expertise konden inzetten?
.avif)