Slachtoffer van z’n eigen succes: het gevaar van fantastische proefprojecten

Een proefproject maakt snel duidelijk of een nieuwe technologie relevant is voor je bedrijf. Er loert echter gevaar om onverwachtse hoek: een te succesvol project heeft meer na- dan voordelen.

Is AI iets voor jouw bedrijf? Of overweeg je al je data op een andere manier te beheren? Misschien is het wel tijd om voor meer automatisering te zorgen via low-code en no-code? Wat het plan ook is, niemand wil graag blind in het diepe springen. Na een veelbelovend idee volgt een eerste kleinschalig project: het Proof of Concept (PoC).

PoC

Zo’n PoC toont aan hoe realistisch de technologische implementatie van een nieuw concept is. Een bedrijf gaat al dan niet samen met partners op zoek naar een duidelijk afgebakend project waarin de nieuwe technologie zich kan bewijzen. Er wordt niet gericht op ingrijpende verandering van de bedrijfsprocessen in deze fase.

Een organisatie zou bijvoorbeeld een stuk van de interne technische ondersteuning door een chatbot kunnen vervangen. Zo kan de onderneming de mogelijkheden aftasten zonder het experiment meteen bloot te stellen aan het grote publiek. Een handvol accountants kan ook toegang krijgen tot enkele automatiseringstools om zo een bepaald terugkomend aspect van de facturatie te vereenvoudigen. Voor data kan een PoC inhouden om bepaalde gegevens naar de cloud te halen en die daar te correleren met andere data.

Resultaat in twee weken

Wie dat laatste doet, kan Joris Van den Borre tegen het lijf lopen. Hij is oprichter van Tropos.io en werkt onder andere als partner van Snowflake aan implementaties bij bedrijven. Het datacloud-concept van Snowflake is hip en wint ook bij ons veel tractie. Wie met Snowflake in zee gaat, ontsluit data in de cloud waar ze volgens een Zero-Copy-principe beschikbaar zijn voor mensen en applicaties, niet alleen intern maar indien gewenst ook extern.

lees ook

Wat is Zero-Copy, en wat kan je leren van de Canadese standaard voor data-integratie?

“Een succesverhaal kan op twee weken al op poten staan”, weet Van den Borre. “Het kan zijn dat het grootste probleem is dat je probleem té succesvol wordt.” Dat klinkt als stoeferij maar is het allesbehalve. Bovendien geldt het niet alleen voor Snowflake.

Instapvriendelijk

Er zijn twee grote valkuilen bij PoC’s van nieuwe technologie: het feit dat de nieuwe oplossing vaker wel dan niet cloudgebaseerd zal zijn, en doordacht beheer. Laten we eerst even naar het cloudaspect kijken.

De cloud laat ondernemingen toe om een PoC op te zetten in weken of wie weet zelfs dagen. Het resultaat kan bovendien meteen heel bruikbaar zijn. Die lage instapgrens en hoge schaalbaarheid is immers één van de grootste troeven. Je betaalt natuurlijk voor het gebruik, en eigen aan een PoC is de beperkte schaal. In principe is er geen immens budget voorzien om met het proefproject meteen de hele onderneming te bedienen.

Jij vraagt, de cloud draait

Daar kan het wel eens verkeerd lopen. Misschien zijn de inzichten die het proefproject oplevert, zo relevant dat andere departementen er ook meteen mee aan de slag willen gaan. Of misschien wordt meteen duidelijk dat een chatbot heel wat relevante informatie van over het hele bedrijf naar boven kan brengen. Sta je toe dat in die PoC-fase het gebruik escaleert, omdat iedereen zo snel mogelijk de spannende nieuwe capaciteiten in handen wil krijgen, dan krijg je de rekening later (letterlijk) gepresenteerd.

Een eigen server heeft fysieke beperkingen, maar die zijn er niet in de cloud.

Joris Van den Borre, oprichter & MD Tropos.io

“Snowflake kan leveren wat je vraagt, zolang je het vraagt”, duidt Van den Borre. “Een eigen server heeft fysieke beperkingen, maar die zijn er niet in de cloud. Dat vraagt discipline. Wie gedisciplineerd van capaciteiten gebruik maakt, krijgt veel voor weinig geld.” De keerzijde is duidelijk: wie de remmen losgooit, kan heel eenvoudig boven z’n stand consumeren. Een PoC wordt zo een geldgat.

Cultuurverandering

Opschalen is natuurlijk het uiteindelijke doel van ieder project, maar eer het zover is, moet de bedrijfscultuur mee veranderen. Het consumptiemodel vraagt dat je goed nadenkt over wie waartoe toegang krijgt, en voor welke reden. Alles kan in de cloud, maar daarmee is alles niet meteen wenselijk.

Ook voor projecten die lokaal draaien, kan te snel en te veel problemen geven. Denk bijvoorbeeld nog eens aan low-code en no-code automatiseringen. Die zijn handig, maar moeten ook beheerd worden. Idealiter zijn beheerders klaar om een veelvoud aan apps veilig te laten draaien, maar dat is geen gegeven. Als iedereen plots z’n eigen automatiseringen gaat maken, ontstaat er een rommel waarin het moeilijk is om wegwijs te raken. Dat brengt dan weer beveiligings- en compatibiliteitsproblemen met zich mee.

Beter traag en goed

Ga niet te snel, baken doelen af, en houd je daaraan. Ja, het nieuwe project staat er binnen twee weken en kan het hele bedrijf bedienen binnen drie, maar dat loopt niet goed af. De nodige culturele aanpassingen zijn nodig, discipline is noodzakelijk en tegenover het geplande gebruik moet een budget staan. Dan pas is opschalen aan de orde.

nieuwsbrief

Abonneer je gratis op ITdaily !

  • This field is for validation purposes and should be left unchanged.