De eerste versie is een vertrekpunt

Wanneer AI een applicatie samenstelt op basis van uw beschrijving, komt de eerste versie snel. Ze zit vaak dicht bij wat u wilde, zelden exact. Een veld ontbreekt, een label is verwarrend, een regel geldt een dag te vroeg. Dat is geen mislukking. Het is het normale vertrekpunt van een fase van bijsturen.

Het echte risico ligt elders. Een eerste fout is zichtbaar en wordt gecorrigeerd. Wat duur uitvalt, is een aanpassing die stilletjes iets breekt dat werkte: een scherm dat niemand nog opent, een berekening die verandert zonder dat iemand het merkt, een toegangsrecht dat per ongeluk verruimd wordt. De controle houden betekent zich zo organiseren dat die neveneffecten niet voorkomen, of gezien worden voor ze uw team bereiken.

Vraag gerichte aanpassingen

Na een eerste versie is de verleiding groot om alles opnieuw te beschrijven. Dat is de beste manier om een tweede versie te krijgen die anders is, niet beter. AI werkt het best wanneer u het exacte element aanwijst: dit veld, dit scherm, deze regel. De rest blijft staan.

Drie gewoonten maken een aanpassingsvraag doeltreffend. Benoem de precieze plaats. Vraag één ding tegelijk. Zeg wat u zag en wat u in de plaats verwachtte. Het zijn dezelfde gewoonten als in Uw behoefte beschrijven aan de AI, toegepast op een applicatie die al bestaat.

  • Goede vraag: “Op het scherm Offertes aanvaardt het veld Korting negatieve waarden. Het zou elk bedrag onder nul moeten weigeren.” Vage vraag: “De offertemodule werkt niet goed.”
  • Goede vraag: “Voeg in de lijst van interventies een kolom Technicus toe, net na de kolom Klant.” Vage vraag: “Er ontbreekt informatie in de lijsten.”
  • Goede vraag: “De regel die een factuur zonder bestelbon blokkeert, moet ook gelden voor creditnota’s.” Vage vraag: “Bekijk alle facturatieregels opnieuw.”
  • Goede vraag: “Wanneer ik op Valideren klik, sluit de fiche zonder boodschap. Ik verwachtte een bevestiging.” Vage vraag: “Het loopt vast als we valideren.”

Een precieze vraag heeft nog een voordeel: ze is controleerbaar. U weet exact waar u in de volgende versie naar moet kijken, en u ziet meteen of er iets anders bewogen is.

Wanneer iets misloopt

Een aanpassing geeft soms een onverwacht resultaat. De nuttige reactie is niet meteen een nieuwe correctie vragen. Wel beschrijven wat er gebeurd is, zoals u dat aan een collega zou doen: welk scherm, welke actie, welk resultaat. “Op de klantenfiche verdwijnt het btw-nummer wanneer ik op Opslaan klik.”

Laat de AI daarna de oorzaak uitleggen voor ze iets corrigeert. Een duidelijke uitleg zegt u of het probleem komt van de gevraagde aanpassing, van een oudere regel of van een misverstand over de behoefte. Corrigeren zonder te begrijpen is pleisters stapelen: elke correctie roept een volgende op, en al snel weet niemand nog wat de applicatie doet.

Eén correctie tegelijk, gecontroleerd voor de volgende. Duiken er twee problemen op, pak dan het belangrijkste aan, controleer, en ga daarna naar het tweede. De schijnbare traagheid is een echte besparing.

Versies en terugdraaien

Een door AI samengestelde applicatie moet elke versie bewaren. Niet alleen de laatste: alle versies die eraan voorafgingen. Dat geheugen maakt aanpassingen veilig. U kunt twee toestanden vergelijken, de nieuwe bekijken voor u ze aanneemt, en naar de vorige terugkeren als het resultaat niet bevalt.

Het principe is eenvoudig: een aanpassing die u niet overtuigt, wordt niet behouden. Ze heeft niets gebroken, ze heeft niets achtergelaten. U krijgt de toestand van daarvoor terug, exact.

  1. Bekijken

    Open de nieuwe versie in een testruimte, met de schermen en de demonstratiegegevens die uw team gebruikt. Voor de gebruikers is er nog niets veranderd.

  2. Vergelijken

    Zet de vorige versie en de nieuwe naast elkaar. Kijk eerst naar het aangepaste element, daarna naar de aangrenzende schermen: daar verbergen neveneffecten zich.

  3. Beslissen

    Komt het resultaat overeen met de vraag en is er verder niets bewogen? U keurt goed. Blijft er twijfel? U vraagt een uitleg of een correctie voor u verder gaat.

  4. Publiceren of terugdraaien

    U publiceert de goedgekeurde versie, of u keert in één handeling terug naar de vorige. In beide gevallen bewaart de geschiedenis het spoor van wat geprobeerd werd en van de genomen beslissing.

Die omkeerbaarheid verandert de manier van werken. U durft te proberen, omdat proberen niets definitiefs kost.

Valideren voor de productie

Tussen de versie die u goedkeurde en het dagelijkse werk van uw team blijft één stap over: de validatie. Ze gebeurt in een aparte omgeving, gescheiden van de productie, waar de mensen die de applicatie zullen gebruiken ze echt testen. Eerst de normale gevallen: een offerte aanmaken, een interventie plannen, een dossier afsluiten. Dan de uitzonderingen: een klant zonder adres, een geannuleerde factuur, een datum in het verleden.

Het is ook het moment om de rechten opnieuw te controleren. Een aanpassing kan, zonder dat het de bedoeling is, een scherm openzetten voor een rol die het niet mocht zien, of een nodige toegang wegnemen. Voor elke publicatie wordt de vraag uitdrukkelijk gesteld: wie ziet wat, wie mag wat wijzigen. Het antwoord moet hetzelfde zijn als voordien, tenzij u een wijziging gevraagd hebt.

Niets gaat naar productie zonder het akkoord van uw team. En dat akkoord laat een spoor na: wie welke versie goedkeurde, wanneer, en op welke basis. Het is dezelfde logica als in Automatiseer zonder menselijk oordeel weg te nemen voor automatiseringen: een drempel, een goedkeuring, een spoor. Een applicatie evolueert volgens dezelfde regels als een geautomatiseerde actie.

Een versie is niet klaar wanneer de AI klaar is. Ze is klaar wanneer uw team ze goedgekeurd heeft.

In Neoo: elke evolutie behoudt een duidelijk contract

In Neoo gebeurt dit werk met Neoo Forge, het atelier dat uw applicaties met AI samenstelt. U beschrijft uw vak, Forge stelt de schermen, regels en automatiseringen samen, verbonden met uw bestaande gegevens. En vooral: Forge controleert elke evolutie voor ze gepubliceerd wordt.

Die controle slaat op vijf punten: de afhankelijkheden tussen de applicatie en de rest van uw systeem, de toegangsrechten, de beveiliging, de tests en de mogelijkheid om terug te draaien. De compiler van Forge is een controlepoort, geen formaliteit. Een aanpassing die deze controles niet doorstaat, wordt niet gepubliceerd, en u weet waarom.

Elke capaciteit die Forge samenstelt, heeft een verantwoordelijke, een versie, rechten en tests. Zo behouden evoluties een duidelijk contract: u weet wat elk element doet, wie ervoor instaat en wat er verandert van de ene versie naar de andere. Het vertrekpunt blijft dat van Een bedrijfsapplicatie maken zonder te coderen: uw beschrijving, uw woorden, uw goedkeuring.

U ziet hoe Forge werkt op de Neoo Forge-pagina, of u bespreekt het met ons tijdens een demonstratie.

Veelgestelde vragen

Wat als een aanpassing iets breekt dat werkte?

U keert in één handeling terug naar de vorige versie. Elke versie wordt bewaard, en de betrokken aanpassing blijft zichtbaar in de geschiedenis. U kunt ze daarna opnieuw opnemen, met de uitleg van wat er gebeurd is, zonder druk op het dagelijkse werk van het team.

Wie mag een publicatie goedkeuren?

De personen die u aanduidt, volgens hun rol. Dat kan de verantwoordelijke van de betrokken dienst zijn, de bedrijfsleider of een duo. De goedkeuring wordt geregistreerd met de versie, de datum en de naam van wie gevalideerd heeft.

Kunnen we testen met echte gegevens voor we live gaan?

Ja, in een validatieomgeving die gescheiden is van de productie. Uw team kiest welke gegevens daar gebruikt worden, en de toegangsrechten worden er gerespecteerd zoals overal elders. Wie bepaalde informatie niet ziet in productie, ziet ze ook niet in validatie.