Van ad-hoc tool naar operationele software

Misschien kent u ze wel: van die spreadsheets waarvan niemand weet hoe ze precies werken maar die wel essentieel zijn voor een bedrijfsproces. Of die medewerkster die een aantal handige scriptjes ontwikkeld heeft voor belangrijke berekeningen maar die door niemand anders gebruikt kunnen worden. Nu veel bedrijven aan het digitaliseren slaan, ontkomt men er niet aan om van dit soort tools betrouwbare operationele applicaties te maken. Maar hoe pak je zoiets aan?

Software als bedrijfsrisico

In veel bedrijven worden dagelijks allerlei berekeningen gedaan en visualisaties gemaakt. Daarbij wordt een breed scala aan tools gebruikt. Dat kunnen spreadsheets zijn, die vaak door medewerkers zelf opgezet en uitgebouwd worden. Maar het kunnen ook stukken programmatuur zijn die bijvoorbeeld door een student of een onderzoeker gemaakt zijn. Maar al te vaak zijn dat ad-hoc ontwikkelingen waarbij de gebruiker nog allerlei handmatige stappen moet verrichten.

Hoewel dit de dagelijkse praktijk is in veel bedrijven, snappen de meeste managers  dat hier serieuze risico’s aan kleven. Wat als degene die de tool ontwikkeld heeft met pensioen gaat? Wie kan de tool dan nog gebruiken? En hoe zeker weet je dat er geen fouten in zitten? Voor welke invoer is de tool geschikt en hoe merk je dat je er iets verkeerd in gestopt hebt? Allemaal vragen die je eigenlijk niet wilt hebben als het om een belangrijk bedrijfsproces gaat.

Het risico beheersbaar maken

De huidige trend naar digitalisering van werkprocessen maakt het onvermijdelijk om deze zaken aan te pakken: de tools moeten onderdeel worden van de bredere IT-voorzieningen en daarom geconsolideerd worden. Bij VORtech hebben we hier vaak mee te maken. Men schakelt ons graag in om van ad-hoc tools een operationele applicatie te maken. Vooral als de berekeningen wat complexer zijn of simulaties of optimalisatiealgoritmen bevatten.

Daarbij beginnen we meestal niet bij de tools zelf. We kijken eerst naar het proces waar een tool onderdeel van uitmaakt. Wat zijn de handmatige stappen die uitgevoerd worden? Welke uitvoer wordt in praktijk gebruikt? Hoe wordt die uitvoer beoordeeld? Hoe weet een gebruiker of het allemaal goed gegaan is? Op basis hiervan maken we een goed stroomschema dat we uitvoerig met de betrokkenen bespreken. Deze stap zorgt ervoor dat ook alle impliciete informatie van mensen op de werkvloer boven water komt. Vaak is dat informatie waar die mensen zichzelf maar nauwelijks van bewust zijn omdat het voor hen vanzelfsprekend is. Bovendien kunnen gebruikers ook allerlei ideeën en wensen kwijt zodat we daar rekening mee kunnen houden. Omgekeerd leren onze gesprekspartners ook iets van de manier waarop wij met applicatieontwikkeling bezig zijn en verhogen ze hun digitale vaardigheden, zoals dat zo mooi heet.

Zodra we gezamenlijk het gevoel hebben dat het werkproces en de stappen daarin goed begrepen zijn, implementeren we het stroomschema in een geschikte programmeertaal. Daarbij kan het voorkomen dat er stukken programmatuur in het werkproces gebruikt worden die zelf al heel complex zijn. Bijvoorbeeld als een Excel file erg ingewikkeld is, of er gebruik gemaakt wordt van grote stukken Visual Basic (VBA). Of als er een uitvoerige simulatie of optimalisatie uitgevoerd wordt, die zelf weer is geïmplementeerd in een omgeving als Matlab of Modelica.

De aanpak van spreadsheets

Als het gaat om een complexe spreadsheet dan zullen we er vrijwel altijd voor kiezen om die om te zetten naar een hogere programmeertaal, zoals bijvoorbeeld Python. De reden is dat spreadsheets notoir foutgevoelig zijn. De horrorverhalen van de European Spreadsheet Risks Interest Group laten mooi zien wat er zoal fout kan gaan. Het is veel te gemakkelijk om ergens, soms per ongeluk, een wijziging aan te brengen die niemand in de gaten heeft maar wel de uitkomsten verandert. En de relaties tussen cellen worden al heel snel onoverzichtelijk. Het feit dat spreadsheets laagdrempelig te gebruiken zijn is meteen ook de achilleshiel.

Het omzetten van een spreadsheet is een taak op zich. Ook hier beginnen we meestal met het uitschrijven van de berekeningen die in de spreadsheet vastgelegd zijn. Een extra complexiteit daarbij is dat ook de data gemodelleerd moet worden: de datastructuren zijn impliciet vastgelegd in de cel-indelingen maar moeten expliciet gemaakt worden om ze te kunnen implementeren in een andere taal. Overigens is het vrijwel gegarandeerd dat we ergens een fout tegenkomen: alleen al daarom is dit een nuttige exercitie.

Herbouw or opschonen?

Als er andere soorten programmatuur in het werkproces gebruikt worden dan zal per geval een afweging gemaakt moeten worden: kan het direct gebruikt kan worden, moet het opgeschoond worden of moet het herschreven worden. Dat hangt dan erg af van de kwaliteit van de programmatuur. Maar ook andere zaken kunnen in die keuze betrokken worden. Op dit moment zien we dat veel bedrijven graag af willen van dure Matlab licenties omdat Python grotendeels hetzelfde kan maar helemaal gratis is. Maar ook het herschrijven kost natuurlijk geld dus er zal een goede afweging gemaakt moeten worden.

De laatste stap in het consolideren van ad-hoc tooling is het inbedden in de bredere IT-voorzieningen. In de praktijk betekent dat meestal dat er een web interface gemaakt wordt. In sommige gevallen gaat het dan om een REST-API waarmee de tools door andere IT-systemen aangeroepen kunnen worden. In andere gevallen wordt er een specifieke webapplicatie gemaakt die vanaf een centrale locatie aangeboden wordt.

Acceptatie

Hoewel medewerkers in het begin soms wat afhoudend zijn als we met ‘hun’ tool aan de slag gaan, zijn ze achteraf vrijwel altijd blij dat de stappen gezet zijn. Het scheelt heel veel handwerk en het reduceert het risico van fouten. En vaak wordt de performance veel beter waardoor het werk ook nog eens sneller gebeurt. En, laten we eerlijk zijn: de basis is altijd nog gelegd door de medewerker zelf en die mag best trots zijn op wat ervan geworden is.