admin

Het Angelsaksische woord “intelligence” heeft een dubbele betekenis. Het kan slaan op de wijze van informatieverwerking en op de informatie zelf. In beide gevallen gaat het om het bepalen van de relevantie. Dit vereist intelligentie in de derde betekenis van het woord.

Er zijn veel verschillende theorieën over wat intelligentie is maar vooralsnog is er geen overeenstemming. Toch wordt dit begrip in de praktijk veel gebruikt, er wordt zelfs gesproken over kunstmatige intelligentie. Ook wordt onderscheid gemaakt in meer of minder intelligente ondernemingen maar ook hier ontbreekt de overeenstemming.

In de context van het Nederlandse bedrijfsleven werd met “Business Intelligence” doorgaans managementinformatie bedoeld: de informatie die nodig is om een bedrijf te managen. Zowel de aard als de hoeveelheid managementinformatie en de mogelijkheden die te verwerken zijn echter aanzienlijk uitgebreid. Ook de snelheid waarmee managementinformatie kan worden verwerkt ligt veel hoger. In die zin is er natuurlijk wel wat veranderd.

Of je het managementinformatie of Business Intelligence noemt, de vraag blijft: Wat is relevant? Beantwoording van die vraag is lastig en vereist intelligentie, bedrijfsintelligentie.

Er is weliswaar geen test voor het meten van bedrijfsintelligentie maar er zijn wel verschillende indicatoren.  Duidelijk is dat ICT een belangrijke rol wordt toebedacht; zo wordt de volwassenheid van een organisatie soms afgemeten aan de mate waarin, en de manier waarop, gebruik wordt gemaakt van ICT; ICT wordt dan gelijk geschakeld aan volwassenheid. Hierbij zijn natuurlijk wel wat kanttekeningen te maken.

ICT wordt ook genoemd als middel om de wendbaarheid te vergroten. Wendbaarheid is natuurlijk belangrijk maar dit begrip betekent in de mijnbouw wat anders dan in de detailhandel, m.a.w. wendbaarheid is een relatief begrip. Wendbaarheid verdraagt zich overigens i.h.a.  niet goed met ICT.  ICT is namelijk nogal rigide en aan het minder rigide maken van ICT kleeft een prijskaartje, wendbaarheid moet immers wel ingebouwd worden.

Business Intelligence heeft in ieder geval te maken met leiding geven, risicobeheersing en compliance d.w.z. met Governance, Risk management en Compliance (GRC). Oftewel: welke koers wordt gevolgd, wat kan er gebeuren en welke maatregelen moeten dan worden genomen en welke eisen worden gesteld en voldoen we hieraan?

Ieder bedrijf heeft tegenwoordig een missie, visie en misschien zelfs een aantal Kritische Prestatie Indicatoren (KPI’en). Niks mis mee natuurlijk, maar daar blijft het meestal bij. Wat dan ontbreekt is de vertaling van deze toch vrij abstracte begrippen in wat meer concrete handvaten waar iedereen wat aan heeft. Iedereen geeft immers leiding en om te beoordelen wat wel of niet relevant is worden verschillende criteria gebruikt. Natuurlijk is eenheid van opvatting belangrijk maar die samenhang ontstaat niet vanzelf.

Er wordt doorgaans veel waarde gehecht aan financiële indicatoren. Veel aspecten / delen van een bedrijf kunnen immers financieel worden gemaakt. Dat hoeft echter niet te betekenen dat deze aspecten / delen van het bedrijf ook financieel bepaald zijn. Een financiële insteek kan weliswaar gebruikt worden om bepaalde stakeholders over de streep te trekken maar kan ook een redenering die op drijfzand is gebouwd acceptabel doen lijken.

Doorgaans zijn er meerdere producten en dus ook meerdere markten en productieketens. Je kunt wel het een en ander standaardiseren maar je kunt niet alles dichtregelen. Het gebruik van zgn. bedrijfsregels is een populaire benadering om de werking van een bedrijf te analyseren. Er zit doorgaans echter een groot verschil tussen hoe het zou moeten werken (de normen), hoe gedacht wordt dat het werkt (de aannames) en hoe daadwerkelijk wordt gewerkt (de feiten).

Bedrijfskennis is verdeeld over medewerkers. Die moet je voldoende ruimte geven om hun werkwijze te ontwikkelen. Hoeveel vrijheid hebben medewerkers? Als medewerkers strikt volgens regels (welke regels en van wie?) zouden moeten werken dan zou het misschien wel snel afgelopen zijn met het bedrijf.

Dit betekent dat er een zekere bereidheid moet zijn tot het nemen van risico’s. Ondernemen is (markt)risico nemen maar ondernemen is ook (productie)risico’s vermijden. Het is zaak om risico’s tijdig te onderkennen om passende maatregelen te kunnen nemen. Maar wat is “tijdig” en wat is “passend” (en wie bepaalt / bepalen dat)?

Contractuele verplichtingen zijn er veel, bijvoorbeeld jegens de klant, jegens de leveranciers, jegens de medewerkers en jegens de klanten. Feitelijk is een bedrijf een contractuele eenheid (rechtspersoon) opgebouwd uit belanghebbenden die zich op enigerlei wijze contractueel hebben verbonden. Met compliance worden doorgaans de maatschappelijke verplichtingen bedoeld d.w.z. de eisen van publieke wet- en regelgeving. Soms zijn dit minder grijpbare zaken zoals maatschappelijk verantwoord ondernemen. Deze zijn vaak moeilijk meetbaar te maken.

In principe kan er veel worden geregistreerd (big data) en geanalyseerd (AI). Maar de vraag is steeds wat relevant is. In zijn algemeenheid is de vraag naar de relevantie niet te beantwoorden. Ieder bedrijf is immers anders. Je moet weten wat bedrijfsmatig relevant is. Je hoeft geen techneut te zijn om dit te bepalen. Natuurlijk heeft niemand alle kennis in huis. Dit betekent dat niet alleen tussen bedrijfsmensen en techneuten, maar ook tussen bedrijfsmensen onderling, de nodige afstemming moet plaatsvinden (business alignment).

In een vorige bijdrage is gepleit voor het opsplitsen van het management van ICT-projecten in afzonderlijke projecten, te weten: analyse, ontwikkeling en implementatie.  De doelstellingen, deelnemers en werkwijzen, en daarmee de risico’s en doorlooptijden van deze activiteiten, kunnen namelijk nogal uiteenlopen. In dat geval is het beter ze onder te brengen in afzonderlijke projecten. Zelfs als een kort-cyclische iteratieve methodiek wordt gevolgd. In deze bijdrage staat het management van de implementatie-activiteiten centraal.

De invoering van ICT gaat altijd gepaard met wijzigingen. Voor het merendeel zal het hierbij gaan om geplande wijzigingen (met soms onverwachte gevolgen). Het moment van overgaan is kritiek. Wanneer is het projectresultaat klaar voor implementatie. Hoe omvangrijk / ingrijpend is de verandering? Wie wordt of worden geraakt door de invoering? Wat verandert er?

Uitgangspunt bij implementatie is dat de ontwikkeling van de software is afgesloten. Vaak is dat niet het geval, bijvoorbeeld als gekozen is voor een iteratieve ontwikkelbenadering met de gebruiker “in the loop”. Eigenlijk is ontwikkeling nooit klaar zoals ook een bedrijf nooit af is. Het is in ieder geval niet verstandig het ontwikkelteam na oplevering van het projectresultaat helemaal op te heffen. Het is aan te raden een zekere ontwikkelcapaciteit achter de hand te houden.

Zeker als je open wilt blijven tijdens verbouwing kan het voorkomen dat de bestaande en de nieuwe ICT een tijd lang samen worden gebruikt; de bestaande ICT kan bijvoorbeeld als terugval-optie in stand worden gehouden. Het zal duidelijk zijn dat dergelijke situaties specifieke maatregelen vereisen. Aan het in de lucht houden van de bestaande software kleeft trouwens wel een risico: gebruikers gaan de nieuwe software / werkwijze mogelijk vergelijken met de bestaande en die vergelijking valt vaak uit ten gunste van de meest vertrouwde, d.w.z. de bestaande.

Het tempo en de volgorde van implementatie is afhankelijk van het bedrijfsbelang (en dus niet een keuze tussen een zgn. “big bang” of een meer geleidelijke aanpak). Het is van belang je niet uitsluitend te laten leiden door wat vanuit ICT-perspectief belangrijk is maar ook door wat bedrijfsmatig belangrijk is.

Iedere implementatie vergt zowel technische als organisatorische aanpassingen. Soms gaat het om wijzigingen “onder de motorkap”. Meestal zijn dit puur technische wijzigingen die weinig of geen gevolgen hebben voor de medewerkers / gebruikers die betrokken zijn bij de primaire bedrijfsprocessen (zie Het management van ICT-projecten: analyse); maar wel voor bijvoorbeeld medewerkers / gebruikers die betrokken zijn bij het beheer en onderhoud van de ICT. Veel wijzigingen hebben echter, direct dan wel indirect, meer gevolgen, niet alleen technisch maar ook organisatorisch dan wel rechtspositioneel.

Geen enkele applicatie is vrij van fouten. Hoeveel er ook is geanalyseerd en getest. De impact van fouten en storingen in een bedrijfsomgeving (productie) kan veel groter zijn dan in een relatief veilige testomgeving. Ook als aan alle eisen wordt voldaan is het mogelijk dat er aanpassingen nodig zijn. Afgezien van onvoorziene afwijkingen in het gebruik, kunnen ook opschalingsproblemen op de loer liggen, bijvoorbeeld vanwege een veel groter aantal gelijktijdige gebruikers.

Vaak moeten er als onderdeel van de implementatie ook gegevens worden overgezet. Dit vereist een aanpak die zorgvuldig moet worden voorbereid. Gegevens zijn immers vaak het kapitaal van een bedrijf. Dit is niet altijd eenvoudig. Ook hier moet een keuze worden gemaakt tussen een zgn. “big bang” of een meer incrementele, fasegewijze aanpak. In veel gevallen wordt de migratie van gegevens gecoördineerd met de implementatie van de overige ICT.

Implementatie vereist aandacht voor de gebruiker. “De” gebruiker bestaat niet, iedere gebruiker is uniek en meestal zullen meerdere gebruikers betrokken zijn, mogelijk met verschillende rollen. Gebruikers zijn niet altijd betrokken geweest bij de ontwikkeling. Wijzigingen van de rol dan wel de rolverdeling kunnen ingrijpend zijn. Het is belangrijk hier alert op te zijn. Het is niet altijd te voorzien hoe medewerkers reageren / omgaan met veranderingen. Soms bestaat de neiging om de bestaande situatie als uitgangspunt te nemen. Vaak geldt dan: je weet wat je hebt maar je weet niet wat je krijgt. Niet altijd is duidelijk welke veranderingen er (nodig) zijn. Dit geeft veel onzekerheid.

Het is mogelijk dat benutting van de software een andere werkwijze vereist. Het kan moeite en tijd kosten om deze eigen te maken. Het is daarom van belang niet te laat te beginnen met scholing maar ook niet te vroeg. Kennis en vaardigheden zijn anders al weer vergeten tegen de tijd dat ze nodig zijn.

Hoe dan ook, een goede ondersteuning van gebruikers is essentieel. Niet alleen bij de voorbereiding maar ook tijdens de invoering en bij het gebruik. Beheer en onderhoud moeten goed ingeregeld en toegankelijk zijn.

Implementatie kan lang duren en de kans is daarom groot dat er, tijdens de implementatie, substantiële wijzigingen plaatsvinden. De wereld staat niet stil: het bedrijf verandert, technologie wordt verder ontwikkeld, wet- en regelgeving veranderen, er zijn “updates” of “upgrades”, et cetera. Veel van deze wijzigingen zijn niet te voorzien maar kunnen een behoorlijke invloed hebben.

Documentatie en onderhoud zijn vaak niet, of slecht, geregeld. Veel wijzigingen gaan ook sluipend. Medewerkers passen hun werkwijze aan aan de ICT want het kost doorgaans meer moeite / tijd om ICT aan te passen. Dit kan dan leiden tot “work arounds”. Ook worden veel wijzigingen van de ICT niet of niet goed gedocumenteerd (met name het waarom wordt vaak niet vastgelegd. Veel kleine aanpassingen kunnen tot behoorlijke veranderingen leiden. Deze worden pas opgemerkt als er aanpassingen noodzakelijk zijn of als er problemen (dreigen te) ontstaan. Het is dan ook raadzaam om de afstemming tussen medewerkers en de software die ze gebruiken boven tafel te houden: bijvoorbeeld door het op te nemen als agendapunt in het werkoverleg. Het is zaak dit overleg op gebruikersniveau te houden. Het is belangrijk om bedrijfsfocus te houden. Dit sluit beter aan bij de beleving. Technologie verandert snel. De kans is groot dat de technologie sneller verandert dan de bedrijfsvoering. Het documenteren van bedrijfsprocessen is daarom vaak relevanter dan het documenteren van de technologie.

Evaluatie is niet populair (gedane zaken nemen geen keer en de kosten zijn al gemaakt) maar wel leerzaam (wat kan beter). Het nalopen van het traject (hoe is het gegaan) en het tegen het licht houden van het resultaat (wat heeft het opgeleverd) kunnen erg nuttig zijn.

Uiteraard is er tijd nodig om veranderingen te laten indalen. Dit kan lang duren en vaak zijn er dusdanig veel veranderingen dat een nieuw evenwicht niet wordt bereikt.

In een vorige bijdrage is gepleit voor het opsplitsen van het management van ICT-projecten in afzonderlijke projecten, te weten: analyse, ontwikkeling en implementatie.  De doelstellingen, deelnemers en werkwijzen, en daarmee de risico’s en doorlooptijden van deze activiteiten, kunnen namelijk nogal uiteenlopen. In dat geval is het beter ze onder te brengen in afzonderlijke projecten. Zelfs als een kortcyclische iteratieve methodiek wordt gevolgd

In deze bijdrage staat het management van ontwikkelactiviteiten centraal. Hierbij draait het om het omzetten van specificaties in code. Dat kan door selectie of door eigen ontwikkeling. Feitelijk gaat het vrijwel altijd om een combinatie: iedere selectie vereist enige aanpassing en ook in geval van ontwikkeling moeten er keuzes worden gemaakt (bijvoorbeeld: welke technologie wordt gebruikt).

Software is maatwerk, dat geldt zeker voor bedrijfssoftware. Deze constatering legt meteen de vinger op de zere plek: moet de ICT het bedrijf volgen of het bedrijf de ICT? De praktijk is natuurlijk niet zo zwart – wit. Vaak is er al een behoorlijk aantal applicaties aanwezig en gaat het meer om aanpassingen en / of uitbreidingen. Het komt ook voor dat een of meerdere applicaties (moeten) worden vervangen. Met andere woorden: er kunnen veel verschillende redenen zijn om ICT te ontwikkelen.

ICT moet meestal worden ingepast in een bestaande omgeving. Dit betekent dat ook die delen of aspecten van de omgeving die relevant zijn voor het goed functioneren van de in te passen ICT in kaart moeten worden gebracht. Deze eisen worden onder de zgn. niet-functionele eisen geschaard. Deze eisen worden nogal eens vergeten. Ook kunnen architectuureisen van toepassing zijn.

Vaak omvat de reeds aanwezige ICT verschillende technologieën, generaties of licenties / leveranciers. Deze moeten ook in kaart worden gebracht. Vaak ontbreekt het overzicht en vergt dit een (niet altijd voorziene) inspanning.

Maatwerk kan problemen geven bij upgrades en updates (versiebeheer). Het niet volgen van releases kan leiden tot beperkingen in de functionaliteit en / of tot beveiligingsrisico’s. Het aanpassen van  de (product-)standaard(en) kan echter ook leiden tot problemen; niet alleen technisch maar ook qua ondersteuning (beheer en onderhoud) en qua scholing.

Het is raadzaam om bij de keuze van bedrijfssoftware de Total Costs of Ownership (TCO) als kostenpost te nemen en niet alleen te kijken naar de investeringskosten. Een vuistregel is dat de TCO circa 3x de investeringskosten bedragen. Als je dit afzet tegen de verwachte baten dan kunnen business cases er soms heel anders uit zien. Het kan voordelig zijn om deze kosten op enigerlei wijze te delen met anderen (partners of leveranciers). Dan ziet het plaatje er natuurlijk weer anders uit.

Stel dat je weet wat je eisen zijn en ook welke randvoorwaarden van toepassing zijn. Hoe maak je dan de beste keuze? ICT is een zeer uitgebreid, gefragmenteerd en specialistisch terrein, niet alleen technisch maar ook commercieel. Bovendien zijn er hypes en ontwikkelingen gaan soms snel.

Een goed uitgangspunt is om geen software te ontwikkelen die al bestaat. Het gaat hierbij niet alleen om applicaties maar ook om bouwstenen en tools. Maar hoe weet je wat beschikbaar of nodig is? Welke producten en diensten zijn beschikbaar en wat kosten die? Wat is de noodzaak, c.q. wat zijn de mogelijkheden, tot aanpassing / ontwikkeling? Wat betekent dit voor het beheer en onderhoud? Beantwoording van deze, en veel andere, vragen vereist veel kennis van de software-markt.

Een ander uitgangspunt is om geen “early adopter” te zijn en alleen bewezen technologie te gebruiken. Ook het hanteren van dit uitgangspunt vereist enige kennis van de software-markt.

Veel bedrijven hebben gegevens en / of processen die in eigen beheer moeten blijven. Deze vormen een deel van het kapitaal van het bedrijf. Ook zijn veel bedrijfsprocessen afhankelijk van ICT. Hoeveel downtime is acceptabel en hoe ga je hiermee om? Je kunt bijvoorbeeld wel boetebedingen opnemen in een Service Level Agreement (SLA) maar is daarmee het bedrijfsrisico afgedekt? Vaak zijn er ook externe regels waar een bedrijf aan gehouden is (compliance). Ook zijn er vragen m.b.t. leveranciers. Bijvoorbeeld: welke leveranciers zijn betrouwbaar? Wat als een leverancier wordt overgenomen of failliet gaat of als leveranciers hun krachten bundelen?

ICT is een zeer specialistisch terrein maar is voor de meeste bedrijven doorgaans geen “core business” maar hooguit een “enabler”. Bovengenoemde algemene overwegingen / valkuilen m.b.t. uitbesteden of zelf doen komen vaak nu pas boven de kim. Door portfolio’s van succesvolle projecten te bekijken, referenties te vragen en anderszins kennis te nemen van ervaringen van anderen kan worden voorkomen met de verkeerde partijen in zee te gaan. Ook het laten uitvoeren van test-opdrachten c.q. -projecten kan soms handig zijn.

De meeste mensen realiseren zich niet hoeveel details er nodig zijn om een computer iets te laten doen wat bedrijfsmatig nuttig is. Computers zijn buitengewoon simpel en kunnen alleen een beperkt aantal expliciete instructies uitvoeren. Dat kunnen ze echter zo snel dat wat er “onder de motorkap” gebeurt, “onder de motorkap” blijft en een gebruiker alleen het eindresultaat ziet. Bij de vertaling van gebruik naar uitvoering wordt echter een enorme hoeveelheid standaarden en stappen gebruikt. Veel hiervan is al gestandaardiseerd en vereenvoudigd. Desalniettemin zijn voor de ontwikkeling van ICT een groot aantal specialisten nodig die in teamverband tot een resultaat moeten komen.

Kenmerkend voor de ontwikkeling van bedrijfssoftware is dat het grootste deel van de instructies onzichtbaar is en het resultaat pas waarneembaar is op het koppelvlak tussen mens en machine. Als dan blijkt dat het resultaat niet voldoet dan kan het een hele puzzel zijn om te achterhalen waarom dat zo is.

Een grote uitdaging bij het managen van ICT ontwikkeling is hoe je verschillende specialisten laat samenwerken. Omdat de meeste ICT projectgewijs wordt ontwikkeld gaat het meestal om projectteams. Deze teams worden naar behoefte samengesteld en kort na oplevering ontbonden, m.a.w. ontwikkelteams zijn gelegenheidsteams. Professionals kun je het best aansturen op basis van resultaten. Deelresultaten moet je dus ook smart maken zodat er op gestuurd kan worden (door ze bijvoorbeeld te koppelen aan testresultaten).

De hoeveelheid details en de onzichtbaarheid van veel coderingen maakt het managen van ontwikkel-projecten niet eenvoudig en maken duidelijk waarom er tijdens de ontwikkeling veel wordt getest. Er zijn veel verschillende soorten testen en test-technieken en -strategieën (ook het testen van software is een specialisme). Zo zijn er bijvoorbeeld unittesten, ketentesten, regressietesten, conversietesten en integratietesten. Uiteraard stelt dit hoge eisen aan het versiebeheer en de documentatie.

Vanuit gebruiksperspectief zijn met name de integratietesten interessant. Deze bieden niet alleen de mogelijkheid te demonstreren (hoe ver is men, wat is er mogelijk) maar ook om toekomstige gebruikers te scholen.

De ontwikkeling kan worden afgesloten als het resultaat door de gebruikers wordt geaccepteerd (vast te stellen door het afnemen van een acceptatie- of oplevertest). De vraag is dan natuurlijk wanneer is het voldoende en wie bepaald dat (wie zijn de gebruikers)?

In een vorige bijdrage is gepleit voor het opsplitsen van het management van ICT-projecten in afzonderlijke projecten, te weten: analyse, ontwikkeling en implementatie.  De doelstellingen, deelnemers en werkwijzen, en daarmee de risico’s en doorlooptijden van deze activiteiten, kunnen namelijk nogal uiteenlopen. In dat geval is het beter ze onder te brengen in afzonderlijke projecten. Zelfs als een kort-cyclische iteratieve methodiek wordt gevolgd. Onderbrenging in afzonderlijke projecten sluit iteratie natuurlijk niet uit.

De keuze voor een iteratieve of een meer sequentiële aanpak is dus geen principekwestie, en  zou dat ook niet moeten zijn. Zuivere vormen bestaan alleen in theorie maar niet in de praktijk, het is meer een kwestie van gradatie. Het beeld van waterval als een strikt sequentiële aanpak zonder terugkoppeling is een karikatuur, een strikt iteratieve aanpak is dat ook. Het gaat erom wat nodig is.

In geval van analyse gaat het in eerste instantie om de vertaling van wensen in eisen. Dit is een bedrijfsmatige stap waarbij de wat- en waaromvragen centraal staan. De vertaling van eisen in specificaties, het vervolg, staat meer in het teken van ontwerp. Dit vervolg is meer technisch waarbij de hoe- en waarmee-vragen de foci zijn. De stap van analyse naar ontwerp is groot. Een veel voorkomende valkuil is te snel de details in te duiken. Dit is met name bij kort-cyclische aanpakken een risico.

Analyse- en ontwerp-activiteiten lopen vaak door elkaar. Veel van wat onder analyse wordt geschaard is feitelijk verkapt wensdenken d.w.z. het denken in oplossingen. Veel business cases lijken soms doelredeneringen (vaak financieel gemaakt om ook twijfelaars, c.q. de CFO, over de streep te trekken).

Een ander onderscheid dat vaak niet, of onvoldoende, wordt gemaakt is tussen ontwerp en constructie. De beschrijving van een object (grafisch en / of linguïstisch) is niet hetzelfde als de constructie m.a.w. ook dit zijn heel verschillende activiteiten (en vereisen verschillende vaardigheden); het werk van een ontwerper / architect is heel anders dan het werk van een constructeur / bouwvakker.

Het onderscheid tussen analyse, ontwerp en constructie wordt, zoals hierboven aangegeven, soms helemaal niet gemaakt. Gebruikerseisen worden dan direct omgezet  / vertaald in (software)code. Hierdoor kunnen veel misverstanden ontstaan. Het vertalen van wensen in code is bovendien erg duur, het is immers veel makkelijker (en veel goedkoper) een stroomdiagram te veranderen of aan te passen dan software.

De vertaling van wensen in code is geen eenrichtingsverkeer De praktijk is dat er ook vanuit de code naar de wensen wordt gekeken. Het kostenplaatje is hierbij natuurlijk van belang (wat is nodig en wat is “”nice to have” en wie bepaalt / bepalen dat?).

Helaas is informatieanalyse in de bedrijfspraktijk niet of nauwelijks onderzocht. We moeten het doen met vuistregels gebaseerd op extrapolaties uit de wetenschappelijke literatuur en veel schade en schande (lessons learned). Veel “lessons learned” worden niet gepubliceerd. Zgn. “benchmarks” en “best practices” kunnen helpen. Maar welke richtlijnen of leidraden ook worden gekozen, de vraag blijft natuurlijk wat in een bepaald geval relevant is. In deze bijdrage kunnen alleen enkele algemene overwegingen en valkuilen worden genoemd.

Bedrijfsfocus is het belangrijkst, met name de manier waarop activiteiten zijn georganiseerd en de manier waarop het toezicht op hun uitvoering is geregeld. Hoe dan ook: het aanbrengen van focus en afbakening is belangrijk. Het is lastig om te blijven denken in bedrijfstermen en niet alleen rekening te houden met nu en straks maar ook met binnen en buiten. Ook als het gaat om lokale veranderingen kan het nuttig zijn vanuit een bredere (bedrijfs)focus te kijken. Dit geeft namelijk niet alleen perspectief maar kan ook helpen lokale aanpassingen in de juiste context te blijven zien.

Vaak wordt gezocht naar een quick fix, ook, of met name, door externe consultants. Die zijn soms geneigd te denken vanuit de gekozen oplossing en minder of niet vanuit het bedrijf. Doorgaans hebben externen (consultants, ontwikkelaars) minder begrip van, en belang bij, zaken die relevant zijn voor het bedrijf. Bovendien kunnen zaken die vanzelfsprekend worden gevonden, door externen maar ook door bedrijfsmensen, onbenoemd blijven. Dit kan aanleiding geven tot fouten dan wel misverstanden.

Een populaire werkwijze bij het specificeren van eisen is het iteratief doorlopen van vinklijsten (checklists). Dit lijkt voor de hand liggend en is makkelijk maar het kan een valkuil zijn. Het risico is namelijk dat, door het klakkeloos gebruiken van vinklijsten, het denken wordt uitgeschakeld. Dit kan een gevaar zijn, net als het blindelings volgen van benchmarks en best practices. Vinklijsten, benchmarks en best practices kunnen bruikbaar zijn als inspiratiebron of als vergelijkingsmateriaal maar niet als sjabloon. Dit is ook het gevaar van het kritiekloos volgen van methodieken en IT-modellen. Het zijn richtlijnen en geen voorschriften.

Het is niet altijd verstandig te kapitaliseren op de mening van één persoon of de overtuiging van een kleine groep. Bedrijfsbrede consensus is meestal niet haalbaar. Toch is het raadzaam enige “business alignment” na te streven. Dit geeft niet alleen meer draagvlak maar het is ook voor het management van het project belangrijk.

Een veel gemaakte fout is te veel nadruk te leggen op geld en tijd. Geld en tijd zijn weliswaar belangrijke randvoorwaarden maar zijn nooit het doel. Toch wordt het succes en falen van (project)activiteiten vaak eenzijdig uitgedrukt in de beschikbaar gestelde project-tijd en -geld. Belangrijk is echter om ook het eindpunt, d.w.z. het bedrijfsbelang, scherp te hebben. Dit is minder eenvoudig dan het lijkt.

Een manier om doelen concreter te maken is om ze SMART te maken. SMART is een afkorting die staat voor Specifiek, Meetbaar, Attractief (of Acceptabel), Realistisch en Tijdgebonden. In de context van een bedrijf zullen doelen meestal producten (goederen en / of diensten) zijn. Ook kan het helpen een levenscylusbenadering te volgen. Een dergelijke benadering is ook, of misschien wel met name, nuttig als een iteratieve benadering wordt gevolgd (zodat, ook in geval van veel iteraties, de weg naar het doel zichtbaar blijft).

Informatieanalyse wordt bij voorkeur vanuit verschillende perspectieven uitgevoerd, bijvoorbeeld mensen, processen en gegevens. Eigenlijk is dit een soort triangulatie, d.w.z. een gebruik van meerdere perspectieven.

Mensen. Voor wat betreft organisatie  worden in de literatuur weliswaar een aantal basisstructuren onderscheiden maar die zijn nogal beperkt en in de praktijk heb je hier niet veel aan. Toch is het organogram of “de hark” bij het begin van informatieanalyse een nuttig startpunt. Het geeft in ieder geval een indruk van hoe de taken, verantwoordelijkheden en bevoegdheden globaal zijn verdeeld. Let wel: dit zijn de formele lijnen, informeel kan het heel anders gaan.

Het denken in “stakeholders” of belanghebbenden is ook een handig startpunt, met name door niet alleen naar de interne stakeholders maar ook naar de (relaties met) externe stakeholders te kijken. Zo’n netwerk-benadering is soms vruchtbaarder. Ook dynamiek is belangrijk. Hierbij wordt niet alleen gekeken naar het bestaande netwerk maar ook naar het effect dat veranderingen kunnen hebben op stakeholders en hun onderlinge relaties.

Het in kaart brengen van organisatiestructuren en stakeholders kan ook van pas komen bij het verdelen van zgn. autorisaties.

Processen. Populaire startpunten bij het denken in termen van processen zijn waardeketens en bedrijfsmodellen.

In geval van waardeketens is de vraag wat er moet gebeuren om van input (ingrediënten) naar output (doelen) te komen. Ook in dit geval is iteratie belangrijk. In geval van ketens wordt vaak gesproken over “forward chaining” en “backward chaining”.

Bedrijfsmodellen zijn ook een populair vertrekpunt bij het in kaart brengen van bedrijfsprocessen. Ook in dit geval is het perspectief nog tamelijk globaal.

Bij het meer gedetailleerd modelleren van processen wordt vaak een onderscheid gemaakt in primaire, secundaire en tertiaire processen. Primaire processen zijn dan de processen die nodig zijn om inputs om te zetten in outputs en secundaire processen zijn die processen die nodig zijn om de primaire processen uit te kunnen voeren. Deze (bedrijfsvoerings)processen worden vaak aangeduid met de afkortingen PIOFACH of COPAFIJTH. Primaire processen zijn vaak het meest onderscheidend en worden vaak gemodelleerd door eerst de zgn. “happy flow” in kaart te brengen en daarna de uitzonderingen (exceptions).

Ook in geval van processen is iteratie / validatie belangrijk. Dit gebeurt vaak in de vorm van zgn. “talk throughs” of “walk throughs”. Ook wordt vaak gebruik gemaakt van meer geformaliseerde notaties zoals “use cases”  (UML), BPMN of EPC. Het zal duidelijk zijn dat het werken met user stories, use cases e.d. op een veel hoger detailniveau plaatsvindt.

Gegevens. Een andere insteek is om niet de processen maar de gegevens als vertrekpunt te gebruiken. Een dergelijke insteek kan beginnen met het definiëren van veel gebruikte termen. Dit lijkt nogal triviaal maar het is soms verrassend te ervaren hoe, binnen één en hetzelfde bedrijf, veel gebruikte begrippen (zoals bijvoorbeeld “klant”) heel verschillend opgevat blijken te worden. Ook kunnen hierbij afkortingen in kaart worden gebracht.

Termen verwijzen vaak naar objecten en eigenschappen. Objecten kunnen worden gemodelleerd in de vorm van tabellen waarbij de kolommen de eigenschappen voorstellen en de rijen de afzonderlijke items. De relaties tussen de tabellen kunnen worden gemodelleerd in de vorm van diagrammen en zgn. bedrijfsregels. Dergelijke formaliseringen maken analyse en kwaliteitscontrole mogelijk. M.b.t. gegevensmodellen wordt vaak een onderscheid gemaakt in conceptuele, logische en fysische modellen (in toenemende mate van concreetheid). In het laatste geval spreekt men ook wel van een gegevensbank of “database”.

Gegevensmodellen vormen o.a. ook het kader voor de migratie van data en voor het ontwerpen van zgn. “dashboards”, weergaven van geschoonde en gecondenseerde gegevens die door managers kunnen worden gebruikt om processen te beheersen c.q. het bedrijf te besturen.

Mensen, processen en gegevens. De uitwerking van de relaties tussen mensen, processen en gegevens is afhankelijk van de benodigde granulariteit. Dit betekent niet dat hun analyse c.q. modellering altijd op hetzelfde detailniveau moeten zijn. Het is heel goed mogelijk om aspecten ten dele te detailleren dan wel een aspect te detailleren en andere minder. Dit zal afhankelijk zijn van de relevantie.

Het uitwerken van de relaties en het vasthouden van de samenhang is niet alleen belangrijk bij het modelleren van de bedrijfsvoering t.b.v. het managen van ICT-projecten maar kan ook helpen andere bedrijfskwesties te verhelderen, Het kan ook de re-organisatie dan wel de (her- of om-)scholing van medewerkers ondersteunen.

Het is belangrijk te waken voor te lang doorgaan met analyseren. Er wordt vaak gewaarschuwd voor “analysis paralysis”: het eindeloos doorgaan met analyseren c.q. het uitstellen van implementatie. Door overzicht te houden, te itereren en de relevantie in het oog te houden kan worden voorkomen dat dit gebeurt.

Meestal zullen niet alle details bij de start van de ontwikkeling bekend zijn. Niet alles is te voorzien en voortschrijdend inzicht en nieuwe ontwikkelingen maken herijkingen onontkoombaar. Het is dan wel zaak te waken voor “target drift” en “scope creep”. Het kan helpen te beseffen dat iedere oplossing eigenlijk een tussenoplossing is. De vraag blijft steeds: wat is relevant.

Duidelijk moge zijn dat analyse- en ontwerp-activiteiten een eigen dynamiek hebben die onderbrenging in een afzonderlijk project rechtvaardigt. Ontwikkeling vergt een heel andere aanpak.

ICT-projecten hebben geen beste reputatie m.b.t. het op tijd en binnen budget opleveren van resultaten. Dat geldt niet alleen voor projecten binnen de overheid maar ook voor projecten daarbuiten, al zal dat in het laatste geval niet altijd wereldkundig worden gemaakt. Ondanks alle maatregelen blijkt het vaak lastig om hier verandering in te brengen.

Voor een groot deel zijn de factoren die het succes en falen van ICT-projecten bepalen inherent aan de beheersing van veel technische projecten. Vaak zijn de kosten hoog, is de planningshorizon lang en staan er grote belangen op het spel. Ook het feit dat de realisatie van dergelijke projecten veel schaarse (dure) expertise vereist en veel aandacht voor detail vraagt (en dus moeilijk te plannen is) maakt ze risicovol.

Een bijkomende factor specifiek voor ICT-projecten is dat de uitvoering wordt bepaald door veel details die onzichtbaar zijn. Er zijn weliswaar verschillende metrieken en methoden bedacht om de zichtbaarheid te vergroten, maar het meten van de voortgang blijft problematisch. Software is ook relatief eenvoudig te veranderen maar de gevolgen kunnen vaak groot zijn en zijn niet altijd te voorzien. Veel details zijn bovendien sterk met elkaar verbonden, niet alleen onderling maar ook via externe koppelingen / interfaces.  Het is dan ook niet overdreven te stellen dat de helft van de ontwikkeltijd testtijd is.

De vele eisen / wensen en afhankelijkheden die er zijn, zijn bovendien ook nogal veranderlijk. Ontwikkelingen staan niet stil en vaak is sprake van voortschrijdend inzichten. Het grote aantal verschillende stakeholders is dan ook een factor om rekening mee te houden. Met name in geval van ICT kunnen stakeholders zeer divers zijn (veel bedrijfssoftware is bedoeld om uiteenlopende taken te coördineren) en elke stakeholder heeft weer specifieke eisen. Het is niet eenvoudig om deze op te lijnen, te harmoniseren en ze zo te houden. Ook deze  veranderlijkheid kan het management van ICT-projecten tot een uitdaging maken.

Het voorgaande betekent natuurlijk niet dat ICT-projecten dan maar niet moeten worden uitgevoerd. Daarvoor wegen de vele substantiële voordelen niet op tegen de kosten en de risico’s. Het is wel zaak je bewust te zijn van enkele valkuilen.

De belangrijkste valkuil is misschien wel de ontwikkeling, c.q. de implementatie, van bedrijfssoftware te beschouwen als een voornamelijk technische exercitie die volgens een bepaalde systeemaanpak of -methode kan worden uitgevoerd. Een organisatie (en een bedrijf is een organisatie) kun je weliswaar op enig moment beschouwen (‘bevriezen’) alsof het een relatief statisch systeem is maar dat is het natuurlijk niet. Een bedrijf is een tijdelijk en wisselend verband van mensen / groeperingen (stakeholders) met verschillende belangen (stakes) die zich, veelal op basis van opportunistische overwegingen,  contractueel hebben gecommitteerd aan het realiseren van een product of producten (goederen en / of diensten). Een groei-model is in veel gevallen bruikbaarder dan een ontwerp-model.

Het is dan ook niet verwonderlijk dat de ontwikkeling en implementatie van veel bedrijfssoftware worden gedomineerd door iteratieve benaderingen zoals agile en devops. Helaas worden dergelijke concepten vaak tamelijk rigide toegepast. Ook ontbreekt soms een duidelijke kop en staart en wordt er bijvoorbeeld te lang door geïtereerd.

Het is zaak om ook bij de keuze voor een iteratieve of sequentiële benadering niet al te dogmatisch te werk te gaan maar deze te laten afhangen van het doel van het project. Als bijvoorbeeld het doel is om bedrijfssoftware te ontwikkelen c.q. te implementeren die direct op bedrijfskritisch niveau moet kunnen functioneren dan kan een sequentiële benadering, zoals bijvoorbeeld waterval, toch de voorkeur hebben en misschien wel de enige optie zijn; bijvoorbeeld als de kosten van falen (extreem) hoog zijn. Als het functioneren van de te ontwikkelen of te implementeren bedrijfssoftware minder kritisch zijn dan wel als de eisen niet, of (nog) niet volledig, zijn uitgekristalliseerd of geharmoniseerd, dan heeft een meer iteratieve / tentatieve aanpak wellicht de voorkeur. Bijvoorbeeld in geval van veel verschillende (gebruikers)eisen en / of afhankelijkheden tussen proces stappen (in geval van gewijzigde of nieuwe werkwijzen).

Een andere valkuil is de ontwikkeling c.q. implementatie van bedrijfssoftware te beschouwen als één integraal project. Gegeven de verschillen in doelstellingen, deelnemers en werkwijzen is een scheiding in afzonderlijke projecten vaak te verkiezen; bijvoorbeeld in een analyse-, een ontwikkelings-, en een implementatie-project.

In geval van analyse gaat het erom te komen tot een nadere detaillering en modellering van bedrijfsprocessen. Hiertoe moet vaak uit verschillende informatiebronnen worden geput en vaak zijn hier verschillende bedrijfsexpertises / deelnemers voor nodig.

Ontwikkeling is meer een technische exercitie hoewel ook hier de betrokkenheid van bedrijfsmensen vereist kan zijn; bijvoorbeeld bij sommige testen (dat zijn dan vaak weer andere mensen dan diegenen die betrokken zijn bij de analyse).

Ook ten aanzien van implementatie kan een goede mix van bedrijfsmensen en meer technische georiënteerde mensen nuttig zijn. Maar vaak zijn bij de uitrol, opschaling en gebruikersondersteuning weer andere mensen nodig dan diegenen die betrokken zijn bij de analyse of bij de ontwikkeling.

Kortom, de doelstellingen, de deelnemers en de werkwijzen, en daarmee de risico’s en de doorlooptijden van deze activiteiten, kunnen nogal uiteenlopen. In dat geval is het beter ze onder te brengen in afzonderlijke projecten.

De lijst van mogelijke valkuilen is helaas nog langer, maar veel valkuilen zijn specifiek voor een bedrijfstak, bedrijf of zelfs project. De slechte reputatie van ICT-projecten is misschien ook deels te wijten aan een over-generalisatie of -simplificatie van de oorzaken (en de doelen: wat is “ICT” en wat maakt een project tot een “ICT-project”?). Er zijn weinig gemeenschappelijke factoren die het succes en falen van ICT-projecten bepalen: om met Brooks te spreken: er is geen “silver bullet”. Het management van ICT-projecten is en blijft maat- en mensenwerk.

Bedrijfsregels zijn handig. Medewerkers kunnen handelingen uitvoeren die ze niet hoeven te begrijpen maar die toch tot bedrijfsresultaten leiden. Als je de uitvoering van bedrijfsregels kunt automatiseren dan kan die uitvoering soms nog sneller, nauwkeuriger en, last but not least,  goedkoper. De vraag is welke bedrijfsregels nodig zijn om bedrijfsresultaten te bereiken. De geautomatiseerde uitvoering volgens bedrijfsregels stelt ook eisen aan de middelen en de omgeving waarbinnen die uitvoering moet plaatsvinden. Zowel de formulering van bedrijfsregels als hun toepassing vereisen maatwerk.

Er zijn heel veel verschillende manieren om bedrijfsregels te formuleren. Je kunt proberen ze af te leiden uit de bedrijfspraktijk. Je kunt proberen ze af te leiden uit de theorie. Nog een andere manier is de formulering van bedrijfsregels te automatiseren. Ook dat kan op veel verschillende manieren. Met name AI staat hierbij in de belangstelling.

AI heeft een lange geschiedenis en omvat een grote variëteit aan methoden en technieken. De meesten zijn een mengeling van theorie en praktijk. In essentie draait het om het zoeken naar een bepaalde aanpak waarmee resultaten kunnen worden bereikt die als intelligent worden beschouwd, bijvoorbeeld schaken. Gebleken is dat dit niet eenvoudig is. Het vereist, bijvoorbeeld in geval van schaken, niet alleen een groot arsenaal aan verschillende geavanceerde methoden en technieken, maar ook een enorme hoeveelheid gegevens en heel veel expertise, capaciteit en tijd. Dit heeft niettemin geleid tot enkele nuttige toepassingen (maar niet tot een grote doorbraak).

Een techniek die binnen de AI veel in de belangstelling staat is die van machine learning, in het bijzonder die van neurale netwerken (NN). NN is een verzameling technieken die met name sinds de tachtiger jaren van de vorige eeuw in de belangstelling staat. NN zijn bepaalde configuraties van software elementen die kunnen worden “getraind”.  Dit trainen vereist enorme hoeveelheden gegevens en dito bewerkingen. Door deze training kunnen, uit deze big data en door middel van deze bewerkingen, regels (algoritmen) worden geoogst die geautomatiseerd kunnen worden uitgevoerd. Dit vereist natuurlijk wel een groot aantal keuzes (bijvoorbeeld: welke criteria, welke NN-configuratie, welke gegevens, hoeveel gegevens, hoeveel bewerkingen). Binnen de grenzen van deze keuzes kunnen voor sommige toepassingen vaak verrassend goede resultaten worden geboekt.

Door de beschikbaarheid van grote hoeveelheden gegevens (big data, internet) gecombineerd met verbeteringen in de software en de techniek is de toepassing van NN (en verwante methoden en technieken) in een stroomversnelling gekomen. In de media wordt aan deze toepassingen gerefereerd met de term “AI”. AI heeft door een aantal succesvolle toepassingen terecht veel aandacht gekregen maar de (bedrijfsmatige) bruikbaarheid is waarschijnlijk beperkter dan verwacht. De identificatie en formulering van bedrijfsregels blijft, net als AI, maat- en mensenwerk. Dat geldt ook voor de implementatie en voor de uitvoering.

“.. .  want tussen droom en daad

staan wetten in de weg en praktische bezwaren, ..”[1]

Digitalisering / IT biedt veel mogelijkheden om (de uitvoering van) processen efficiënter te laten verlopen. Deze mogelijkheden moeten wel bedacht, beschreven en vertaald worden (dit geldt voor alle IT, ook voor de minder intelligente). Het bedenken en beschrijven van wat er (anders) moet gebeuren is veruit het lastigst. Niet alleen omdat het lastig is om bedrijfsprocessen op uitvoeringsniveau te beschrijven maar ook omdat het lastig is om hierover overeenstemming te bereiken (en te houden). Het vervolgens vertalen van procesbeschrijvingen in werkende IT vereist ook een enorme detaillering. Het detailleren van bedrijfsideeën en -processen in instructies die door digitale componenten, d.w.z. geautomatiseerd, kunnen worden uitgevoerd is niet eenvoudig. Natuurlijk zijn er bench marks, best practices en producten die hierbij kunnen helpen maar ieder bedrijf is uniek en vereist maatwerk.  En wie kent en kiest die bench marks, best practices en producten?

Het zal duidelijk zijn dat het bedenken, beschrijven en vertalen van die mogelijkheden veel tijd en geld kosten en ook niet zonder risico’s zijn. In deze bijdrage worden enkele praktische overwegingen en bezwaren genoemd die tussen “droom en daad” kunnen staan.

Als bekend is hoe het efficiënter kan waarom gebeurt het nu dan niet? En waarom lukt het straks met IT dan wel? Deze vragen worden vaak niet gesteld maar de antwoorden kunnen zeer verhelderend en ontnuchterend werken. Ze kunnen helpen de hype van de werkelijkheid te scheiden.

Een vraag die ook weinig wordt gesteld is of het succes van een bedrijfsconcept c.q. business case afhangt van een andere denk- of werkwijze of van de manier waarop die is geïmplementeerd? Een slecht bedrijfsconcept blijft in ieder geval een slecht bedrijfsconcept ook al is de IT goed (maar slechte IT kan een goed bedrijfsconcept om zeep helpen).

Het is belangrijk een onderscheid te maken tussen hoe het zou moeten werken (de regels), hoe gedacht wordt dat het werkt (de aannames) en hoe het werkt (de feiten). Deze kunnen ver uit elkaar liggen, bovendien: van wie zijn, c.q. wie bepaalt, die regels, aannames en feiten?

Een bedrijf kun je beschouwen als een systeem maar het is wel een dynamisch systeem. Een bedrijf is geen machine. Een dynamisch systeem interacteert met een omgeving en heeft ook grenzen, en ook die zijn dynamisch. Een bedrijf ontwikkelt zich en ook de omgeving staat niet stil, er treden veranderingen op, sommige zijn gepland maar niet alles is te voorzien. Wat eerst een hulpmiddel was, kan een obstakel worden. Zo wordt in geval van IT bijvoorbeeld gesproken over Legacy IT (sommigen zeggen: de IT van nu is de Legacy van de toekomst).

De invoering van IT vereist veranderingen maar leidt ook tot veranderingen. Veel veranderingen blijven onder de radar en / of worden niet gedocumenteerd en komen pas aan het licht als er (weer) veranderd moet worden (Legacy). Veranderingen die wèl worden onderkend zijn niet altijd gepland, voorzien dan wel bedoeld.

Software is relatief eenvoudig aan te passen maar de gevolgen van die aanpassingen zijn lastig in te schatten, ook door programmeurs. Er zijn dan ook veel verschillende tests en test strategieën. Het is niet overdreven te stellen dat de helft van de ontwikkeltijd besteed wordt aan testen. Dan nog is veel software verre van foutloos en worden veel fouten pas tijdens het gebruik zichtbaar. Kleine fouten kunnen grote gevolgen hebben en kunnen hardnekkig zijn.

Een groot voordeel van IT is dat het integratie mogelijk maakt. Maar integratie schept ook afhankelijkheden en maakt kwetsbaar (voor opzettelijke dan wel onopzettelijke storingen). Geconstateerde fouten en kwetsbaarheden kunnen gecorrigeerd worden. Bijvoorbeeld in de vorm van zgn. “releases”. Het zal duidelijk zijn dat hier ook voorwaarden en kosten aan zijn verbonden.

IT is een zeer uitgebreid en specialistisch domein. Het is daarom niet altijd duidelijk welke expertise nodig is om bepaalde oplossingen te kiezen, te ontwikkelen en / of te implementeren. Het gaat hierbij niet alleen om technische expertise maar ook om bedrijfsexpertise. Beiden zijn schaars, en dus duur. Ook is meestal veel teamwerk nodig om tot een goed werkende oplossing te komen. Ook dat kost geld (en heel veel tijd).

Het zal duidelijk zijn dat het belangrijk is genuanceerd en met een bedrijfsbril naar IT te kijken. Medewerkers zijn flexibel maar minder snel en nauwkeurig. De inzet van IT kan leiden tot een snellere en meer nauwkeurige uitvoering maar is beperkt en niet zo flexibel (ook de inzet van BI en AI vereist veel regels, aannames en feiten, en, nogmaals, van wie?).

Tenslotte: besluiten m.b.t. de inzet van IT worden vaak onderbouwd door bezuinigingen op personeel. Wat dan vaak vergeten wordt is dat personeelskosten een groot deel van de kosten van IT vormen. Ook IT is mensenwerk.

 

 

 

[1] Uit het gedicht “Het Huwelijk” van Willem Elsschot.

Artikelen t.a.v. de ontwikkeling en inzet van software, ook van bedrijfssoftware, zijn meestal nogal technisch georiënteerd (en lang). Als tegenwicht tegen deze overvloed volgt hieronder een meer toepassingsgericht artikel; de meeste principes die hierin worden genoemd zijn feitelijk “lessons learned” die zich in de praktijk al hebben bewezen.

1. De bedrijfsvoering is leidend, software is immers een bedrijfsmiddel. Beoordeel technologie daarom eerst en vooral vanuit het perspectief van het bedrijf. Dit is ook de beste insteek om investeerders te overtuigen. Zij hebben immers gekozen voor het bedrijf (en niet voor de software).
2. Maak niet alleen de meerwaarde voor het bedrijf duidelijk maar ook de gevolgen die de inzet van software heeft voor de betrokken medewerkers. Hierbij kan gedacht worden aan gevolgen voor taken, verantwoordelijkheden, bevoegdheden, werkomstandigheden (technisch, sociaal), opleiding en training en, last but not least, beloning en loopbaanperspectief.
3. Software is een bedrijfsmiddel maar zorg ook voor voldoende draagvlak. Dit hoeft elkaar niet te bijten. Behandel software-gerelateerde zaken als onderdeel van het reguliere overleg. Dit geeft niet alleen de nodige bedrijfsfocus en -context maar voorkomt ook misalignment / techtalk. Dit kan bijvoorbeeld door het op de agenda te zetten. Het handigst is het als degenen die verantwoordelijk zijn voor de software ook aan tafel zitten. Eventuele software gerelateerde zaken kunnen dan nl. meteen worden afgehandeld.
4. Overleg ook regelmatig met externe ketenpartners (bijvoorbeeld leveranciers) en gebruik zoveel mogelijk dezelfde standaarden. Vergeet ook de klanten niet en de eigen medewerkers (BYOD).
5. Geef alle medewerkers een stem. Ook al kun je niet alle wensen honoreren, c.q. alle bezwaren wegnemen, de mogelijkheid om deze te bespreken c.q. te prioriteren (MoSCoW) kan medewerking faciliteren dan wel weerstanden wegnemen.
6. Weten wat er al in huis is, is niet alleen belangrijk om de uitgangspositie te bepalen maar ook om er achter te komen wat er met de reeds beschikbare middelen eventueel aan meerwaarde kan worden gerealiseerd. Misschien volstaat een reorganisatie. Kortom: weet wat er al is.
7. Zet meerdere alternatieven (die zijn er altijd) naast elkaar, inclusief de zgn. nul optie, d.w.z. niets doen (alle waarde is immers relatief / is meerwaarde).
8. Een ander goed uitgangspunt is niets te ontwikkelen dat er al is. Er is al heel veel (maar je moet w l weten wat er te koop is). Verder: kopen (en een beetje aanpassen) is meestal goedkoper dan ontwikkelen. Als je koopt, gebruik dan alleen bewezen technologie (geen kinderziektes) en wees geen early adopter (een bedrijf is geen proeftuin).
9. Als er toch wordt gekozen voor ontwikkelen doe dit dan stapsgewijs (incrementeel ontwikkelen). Zorg eerst voor een werkende basisfunctionaliteit (de “happy flow”) en bouw deze uit (de “exceptions”). Plan in ieder geval haalbare stappen. Door kleinere stappen te zetten kan hun effect nl. beter worden bijgehouden, en kunnen veranderingen die negatieve gevolgen hebben, worden bijgestuurd of teruggedraaid. Zorg wel dat er voldoende expertise en capaciteit is (intern dan wel extern) om eventuele tegenvallers op te vangen c.q. meevallers te benutten.
10. Plan voldoende evaluatiemomenten in. Evaluaties zijn niet alleen een manier om goede ideeën op te doen (soms is er ook sprake van voortschrijdend inzicht), en te versnellen, maar kunnen ook mogelijkheden bieden om met weerstand om te gaan.
11. Hanteer een levensduurbenadering. Dus niet blind staren op de aanschafkosten maar ook kijken naar de kosten van beheer en onderhoud, upgrades e.d. Deze kosten zijn vaak een veelvoud van de initiële kosten.
12. Voer een risicoanalyse uit. Het gebruik van software kan leiden tot meer afhankelijkheden. Het is ook geen overbodige luxe eventuele kwetsbaarheden vooraf in kaart te brengen; bijvoorbeeld door het laten uitvoeren van een zgn. penetratie-test (pen-test). Geen enkele beveiliging is waterdicht en het kan helpen van tevoren te bedenken hoe om te gaan met lekken. Het is ook verstandig dergelijke tests regelmatig uit te voeren (ontwikkelingen staan immers niet stil). Tenslotte: alles kan uitvallen; een back-up is essentieel.

IT biedt bedrijven veel mogelijkheden hun bedrijfsvoering effectiever en efficiënter te organiseren. Elke toepassing van IT is natuurlijk maatwerk maar in zijn algemeenheid is hier wel wat over te zeggen. Dat geldt ook voor de valkuilen. Beiden komen in deze bijdrage aan bod.

IT biedt veel mogelijkheden om bedrijfsprocessen anders te organiseren en te versnellen. Ook de grotere volledigheid, nauwkeurigheid en beschikbaarheid spelen een belangrijke rol bij de keuze voor de zakelijke toepassing van IT.

De focus is vaak gericht op afzonderlijke processen. Dit kan leiden tot detail- en deel-automatisering. Dit is vooral een gevaar als de aandacht uitgaat naar één, of een beperkt aantal, ”high-impact” proces(sen). Het realiseren van veel voordelen vereist vaak een bredere blik die meer is gericht op de samenhang en de coördinatie van processen c.q. procesketenen.

De voordelen van de toepassing van IT beginnen al bij de analyse van bedrijfsprocessen. Zo zijn er veel tools beschikbaar voor de analyse en het ontwerp van bedrijfsprocessen. Met name in combinatie met mogelijkheden tot simulatie bieden deze veel mogelijkheden om betrekkelijk goedkoop verschillende alternatieve structuren en werkwijzen op hun merites te beoordelen.

Ook zijn er veel concepten en tools beschikbaar om het management te ondersteunen. Niet alleen m.b.t. de governance / besluitvorming maar ook m.b.t. de planning van, en het toezicht op, de uitvoering en m.b.t. de administratie en rapportage van de bedrijfsresultaten (bijvoorbeeld in het kader van compliance).

In zijn algemeenheid kan worden gesteld dat veel voordelen onbenut blijven omdat vast gehouden wordt aan bestaande structuren / werkwijzen. Dit kan leiden tot functionele silo’s en eilandautomatisering.

Het loslaten van bestaande structuren en werkwijzen vereist de nodige flexibiliteit. Benchmarking, best practices en ordinair gluren-bij-de-buren kunnen dan helpen. Soms is ook een blik van buiten nodig om de vastgeroeste denk- en werkwijzen te doorbreken.  Dit geldt ook voor de relaties met andere organisaties, inclusief  (met name) de relaties met leveranciers en met afnemers / klanten. Ook in deze gevallen is een bredere, meer ketengerichte, benadering vaak nuttig.

Bij veel IT-projecten ligt het accent op kostenreductie. Dit is op zich wel begrijpelijk. Het is een quick win en kosten zijn doorgaans eenvoudiger te kwantificeren dan baten. Maar het is ook eenzijdig en bovendien: door te investeren (feitelijk door de kosten te verhogen) kunnen mogelijk veel hogere baten worden gegenereerd. Ook kan kostenreductie als primaire business case, weerstand oproepen bij het personeel; met name als de kostenreductie (deels) door personeelsreductie wordt gerealiseerd. Kostenreductie door tijdbesparing heeft vergelijkbare beperkingen en ook in dit geval zijn de bestaande structuren en werkwijzen vaak het uitgangspunt.

Uiteraard moet je naar de uitgangssituatie kijken en is het doel om zakelijke, en dat betekent meestal financiële, verbeteringen te realiseren maar in veel gevallen is een bredere kijk productiever. Hoe dan ook, op voorhand is het vaak lastig aan te geven wat wel of niet werkt.

De drempel om te automatiseren ligt inmiddels wel een stuk lager dan voorheen. Niet alleen zijn er veel krachtigere (goedkopere) producten van de plank verkrijgbaar en is de (agile) aanpassing van IT aan gebruikerswensen sterk verbeterd, maar ook zijn er veel meer (relatief eenvoudige) mogelijkheden om als gebruiker veel routinematige handelingen te automatiseren (in de vorm van low- en no-code oplossingen).

Toch blijft gelden dat automatisering een zekere mate van standaardisering vereist. Standaardisering is nodig om schaalvoordelen te realiseren anders is automatisering niet altijd rendabel. Standaardisering is trouwens ook een belangrijk kwaliteitsaspect; zo kunnen (lever)betrouwbaarheid en nauwkeurigheid, belangrijke “selling points” zijn.

Een van de belangrijkste en meest genoemde voordelen van IT zijn onafhankelijkheid van tijd en plaats. Met name de mogelijkheden die de cloud in dit opzicht biedt (anytime, anywhere) zijn ongeëvenaard.

Parallellisering van processen die traditioneel sequentieel werden uitgevoerd levert natuurlijk tijdwinst op. Ook minder koppelvlakken kunnen leiden tot tijdwinst en een meer efficiënte (snellere) uitwisseling van informatie (en minder kans op fouten).

IT kan meer transparantie bieden (in welk stadium bevindt zich het voortbrengingsproces) maar kan ook tot het aanhouden van geen of kleinere voorraden / buffers (on demand, just-in-time) leiden (en dus tot kostenbesparingen). Transparantie kan ook de nodige gemoedsrust geven (of juist niet); niet alleen aan degenen die betrokken zijn bij de productie maar ook aan afnemers / klanten. De grotere nauwkeurigheid die IT kan bieden vermindert de kans op fouten en daarmee ook de kosten van rework.

Andere logistieke voordelen van IT toepassing zijn differentiatie van workflows (het onderscheiden van processen die vaak, minder vaak of zelden voorkomen) en locatiekeuze (het uitvoeren van processen waar dat het beste kan c.q. waar dat het voordeligst is). Voor wat betreft de externe coördinatie kan het verschuiven van processen naar de leverancier(s) en / of de afnemer(s) / klant(en) voordelen bieden. Dit verschuiven hoeft geen afschuiven te zijn want het kan alle partijen voordelen opleveren. Het creëert natuurlijk wel afhankelijkheden.

Zoals gezegd, valkuilen zijn er ook. Zoals de term “digitale transformatie” al aangeeft zijn organisatorische en personele aanpassingen vaak onontkoombaar. Ook de bestaande (legacy) IT kan tot hoofdbrekens leiden. Wat eveneens vaak vergeten wordt is dat er tijdens de levensduur nogal wat beheer en onderhoud nodig is om alles goed te laten functioneren (en dat dit niet altijd kan worden uitbesteed).

Misschien wel de grootste belemmering in het realiseren van de voordelen is de bereidheid van het management om de teugels te vieren / losser te laten. Dit is meer een psychologische dan een technologische kwestie.

Een goede zakelijke balans tussen mogelijkheden en beperkingen is een vereiste. Het realiseren en vasthouden van een dergelijke balans is een doorlopende, geen eenmalige, bedrijfsactiviteit. IT biedt veel mogelijkheden maar elke toepassing vereist maatwerk.