Een vierde weg voor kmo’s

Jarenlang had een zaakvoerder van een kmo die een tool wilde die bij zijn vak past, drie opties. Een generiek softwarepakket nemen en zijn organisatie plooien naar de schermen ervan. Maatwerkontwikkeling bestellen, lang, duur en moeilijk te laten evolueren. Of een omweg knutselen: een gedeeld rekenblad, een e-mailketen, een schrift aan de balie.

Elk van die opties heeft een verborgen kost. Generieke software legt haar manier van werken op. Maatwerk legt tijd en geld vast voor het eerste resultaat er is. De handmatige omweg steunt op één persoon die het weet, en stort in wanneer die afwezig is.

Er bestaat nu een vierde weg. U beschrijft het proces dat uw onderneming afremt, in uw eigen woorden, en AI stelt een werkende applicatie samen op een basis die al beheerst wordt. Het is geen magische belofte. Het is een methode, met stappen, controles en mensen die valideren. Dit artikel beschrijft ze zoals ze echt verloopt.

Tussen uw beschrijving en de applicatie

De nuttigste vraag is niet “kan AI dat?” maar “wat gebeurt er precies tussen mijn beschrijving en de applicatie in productie?”. Dit is het traject.

  1. U beschrijft het verwachte resultaat

    Niet de techniek, het resultaat: wat opgevolgd moet worden, wie het gebruikt, op welk terrein, met welke beperkingen. Een technicus op de werf heeft andere noden dan een assistente op kantoor.

  2. Beproefde bedrijfsblokken worden samengesteld

    De applicatie wordt niet van nul geschreven. Ze wordt opgebouwd uit objecten, schermen, regels en rollen die elders al in gebruik zijn. AI kiest, past aan en verbindt die blokken met uw beschrijving.

  3. Normale gevallen en uitzonderingen worden getest

    Het dagelijkse geval, de randgevallen, de rechten van elke rol en de mogelijkheid om terug te keren worden gecontroleerd voor iemand de applicatie opent.

  4. Uw team controleert in een validatieomgeving

    De mensen die de applicatie zullen gebruiken, testen ze met echte situaties. Ze melden wat ontbreekt en wat stoort. De aanpassingen gebeuren in deze fase.

  5. Niets gaat in productie zonder uw akkoord

    De ingebruikname is een beslissing van uw onderneming, geen automatische gebeurtenis. U keurt goed, daarna wordt de applicatie opengesteld voor de gebruikers.

  6. De applicatie wordt uitgebaat en verrijkt

    Na de ingebruikname toont het echte gebruik wat moet evolueren. De volgende vragen volgen hetzelfde traject: beschrijving, samenstelling, test, validatie.

Dat traject heeft een eenvoudig gevolg: op geen enkel moment krijgt u een tool die niemand bij u heeft zien werken.

Wat AI doet en wat uw experts behouden

De vraag komt in bijna elk gesprek met een zaakvoerder terug: vervangt AI de ontwikkelaars? Het rustige antwoord is dit. AI verlaagt de kost van standaardtaken. Invoerschermen, lijsten, statusopvolging, informatie doorgeven van de ene persoon naar de andere, meldingen: dat alles wordt snel en goedkoop om samen te stellen.

Wat in mensenhanden blijft, is niet veranderd. De context van uw vak, die niemand anders kent. De verantwoordelijkheid voor wat de applicatie doet met klanten en rekeningen. De relatie met de mensen die ze gebruiken. En de beslissingen die de onderneming binden: wat goedgekeurd wordt, door wie, boven welke drempel.

Er is nog een verschil met wat vaak een prototype genoemd wordt. Een applicatie die zo samengesteld is, is geen geïsoleerde demonstratie op een laptop. Ze leeft in hetzelfde systeem als uw klanten, uw facturen en uw tickets. Ze leest dezelfde data, past dezelfde rechten toe, laat hetzelfde spoor na. Het is een duurzame capaciteit, geen proef.

AI stelt samen wat standaard is. Uw teams behouden wat uw onderneming maakt.

Het eerste project kiezen

Het eerste project bepaalt veel. Is het te breed, dan sleept het aan. Is het te abstract, dan kan niemand zeggen of het geslaagd is. Goede eerste projecten lijken op elkaar: één proces dat u afremt, weinig betrokken mensen, een duidelijk resultaat en een handmatige omweg die al bestaat.

Die handmatige omweg is een uitstekend teken. Als een gedeeld rekenblad of een e-mailketen het werk vandaag doet, dan is de nood echt, is de woordenschat gekend en worden de regels al toegepast, ook al is dat broos. Enkele veelvoorkomende voorbeelden:

  • Interventieaanvragen: een klant meldt een probleem, iemand wijst het toe, een technicus komt langs, de klant wordt op de hoogte gehouden.
  • Goedkeuring van offertes: boven een bepaald bedrag moet een tweede persoon goedkeuren voor de verzending.
  • De onthaalchecklist voor een nieuwe klant: documenten te ontvangen, toegangen aan te maken, mensen te verwittigen, zonder iets te vergeten.
  • Het toestellenregister: wat waar geïnstalleerd is, sinds wanneer, met welk contract en welke volgende vervaldag.

Kies het proces dat de meeste tijd kost aan de persoon die het vaakst aangesproken wordt. Daar wordt het resultaat het snelst zichtbaar.

Wat u voorbereidt voor u begint

U hoeft niets technisch te schrijven. Enkele elementen maken de beschrijving wel veel preciezer, en de applicatie veel juister vanaf de eerste versie.

  • De woordenschat van uw vak: hoe u een aanvraag, een dossier, een interventie, een status noemt. De applicatie moet uw taal spreken, niet omgekeerd.
  • Een voorbeeld van een echt document: een offerte, een interventiefiche, een typische e-mail. Eén voorbeeld zegt meer dan tien uitleg.
  • De regels en de uitzonderingen: wat er normaal gebeurt, en wat er gebeurt wanneer de klant te laat is, wanneer de technicus afwezig is, wanneer het bedrag een drempel overschrijdt.
  • Wie wat valideert: de persoon die goedkeurt, wie mag wijzigen, wie alleen raadpleegt.

Hoe u die beschrijving formuleert, met voorbeelden, werkten we uit in Uw nood beschrijven aan AI zonder technicus te zijn.

Neoo Forge: het atelier dat samenstelt

Bij Neoo heet dat atelier Neoo Forge, het atelier dat uw applicaties met AI samenstelt. Het maakt deel uit van het Business OS van Neoo, het systeem dat uw hele onderneming doet draaien: verkoop, financiën, operaties en support op één plaats.

Dat verandert alles voor de applicatie die u beschrijft. Ze wordt samengesteld op dezelfde basis als uw klanten, uw facturen en uw tickets. Ze is dus verbonden vanaf de eerste dag: een interventieaanvraag kent de betrokken klant, een offertegoedkeuring ziet het echte bedrag, het toestellenregister vindt het bijbehorende contract terug. Geen dubbele invoer, geen export om over te doen.

Elke wijziging volgt hetzelfde validatietraject, en elke versie kan teruggevonden worden. We leggen dat mechanisme uit in Wijzigen, valideren, terugkeren. En wie wil begrijpen waarom die gedeelde basis aan al de rest voorafgaat, vindt het kader in Wat is een Business OS.

Om te beginnen zijn er twee wegen. Beschrijf uw idee op Hoeveel zou mijn idee kosten? en krijg een eerste raming. Of ontdek het atelier in detail op de Neoo Forge-pagina.

Veelgestelde vragen

Heb ik technische kennis nodig?

Nee. U beschrijft het proces in uw eigen woorden, zoals aan een collega. Wat telt is uw kennis van het vak: de woordenschat, de regels, de uitzonderingen en de mensen die valideren. De technische samenstelling gebeurt door AI en wordt geverifieerd via teststappen.

Kan de applicatie gewijzigd worden nadat ze gebouwd is?

Ja, en dat is van bij het begin voorzien. Het echte gebruik brengt altijd aanpassingen aan het licht. Elke wijzigingsvraag volgt hetzelfde traject: beschrijving, samenstelling, test, validatie door uw team. Vorige versies blijven beschikbaar om terug te keren als dat nodig is.

Werkt het met de tools die we al gebruiken?

De verbindingen met uw bestaande tools worden met elke klant vastgelegd en gevalideerd voor de uitrol. We bekijken samen wat verbonden moet worden, in welke richting en met welke regels, in plaats van een algemene compatibiliteit te beloven.