Sommige bedrijven zien it nog steeds vooral als een kostenpost. Want als je maandelijks vele duizenden euro’s aan je it-oplossingen besteedt, verwacht je een efficiënt bedrijfsproces en tevreden gebruikers. Toch is dat zelden de realiteit. Het geld gaat vaak op aan het in stand houden van slecht geïntegreerde software. Het resultaat? Inefficiëntie, ontevredenheid en hoge verborgen it-kosten.
Ik denk dat iedereen wel eens gefrustreerd is geweest over de it-faciliteiten van zijn werkgever. De gebruikte software voldoet niet aan de eisen, moderne cloudoplossingen zijn niet toegestaan, en de negatieve spiraal is compleet als er geen budget is om te moderniseren. In zo’n situatie loopt de zogeheten ‘technologieschuld’ steeds hoger op. Je geeft namelijk handenvol geld uit aan het in stand houden van een it-landschap waar niemand tevreden mee is, en dat bovendien een ontzettend arbeidsintensief en inefficiënt bedrijfsproces oplevert. Kortom: het it-budget wordt verspild en er blijft niets over voor modernisering en innovatie. Verandering is dan een absolute must, want je wordt hierdoor als bedrijf onherroepelijk door de concurrentie ingehaald. Voor 2015 stelde Gartner vast dat de technologieschuld van bedrijven wereldwijd maar liefst een biljoen dollar bedroeg. Een enorm bedrag dat illustreert hoe groot dit probleem is.
Ontsnap aan Excel en Access
Bij bedrijven die geen initiatief nemen om hun it te moderniseren, nemen werknemers veelal het heft in eigen handen. Om te compenseren voor de slecht (of niet) geïntegreerde systemen gaan zij aan de slag met Excel, Access of allerlei randapplicaties, en ontwikkelen vervolgens hun eigen noodoplossingen. Empirische studies tonen aan dat tussen 50 en 80 procent van alle bedrijven wereldwijd nog steeds gebruik maken van ‘op zichzelf-staande’ spreadsheets voor bedrijfskritische toepassingen. Die zelfgebouwde oplossingen brengen allerlei problemen en beperkingen met zich mee. En daarnaast vereisen ze dat de gegevens uit de bronsystemen geëxporteerd moeten worden en in het juiste formaat in Excel, Access of andere randapplicatie gezet moeten worden.
Dit is een grotendeels handmatig proces, wat veel tijd kost, voor fouten zorgt, en de gegevens moeten bovendien vaak meerdere keren ingevoerd worden. Dit leidt vaak tot data-inconsistentie en corrupte data. Het is daarnaast onveilig om op deze manier met bedrijfsgegevens om te gaan. Door deze noodoplossingen wordt het proces weliswaar iets verbeterd, maar er komen tegelijk weer nieuwe problemen bij. Zo is er meer handwerk nodig, er ontstaan kopieën van gegevens, en de complexiteit en de foutgevoeligheid van het proces nemen toe. De enige manier om uit deze situatie te ontsnappen is door volledig in te zetten op het integreren van de bedrijfsprocessen. Maar hoe doet u dat zo efficiënt mogelijk?
Low-code fundament
Volgens mij kan de technologieschuld van bedrijven het beste opgelost worden door afstand te nemen van legacy-software en te investeren in een modern low-code softwareplatform. Dit is een duurzame oplossing die zowel technologisch als functioneel niet veroudert. Met zo’n fundament is het mogelijk om bedrijfsapplicaties op maat te bouwen, zonder dat er veel geprogrammeerd hoeft te worden. Verder is het met low-code niet nodig om in één groot big bang-project het volledige bedrijfsproces onder handen te nemen. Het is zelfs beter om klein te beginnen. Bijvoorbeeld met een specifiek proces, waar voor de organisatie de grootste pijn/inefficiëntie zit.
Het moet dan vrij eenvoudig zijn om een valide businesscase te maken voor de investering in een low-code platform. En als dat eerste proces is aangepakt, kunnen in de loop der tijd steeds meer processen en applicaties in het low-code platform gemodelleerd worden. Zo kun je de bedrijfsapplicaties stapsgewijs op een beheersbare en efficiënte manier re-engineeren en moderniseren, met een lage impact op de organisatie. Het grote voordeel is bovendien dat alle applicaties in een geïntegreerde omgeving tot stand komen, waardoor je per definitie de inefficiëntie van de oude situatie vermijdt. Zo kan de bedrijfssoftware probleemloos meegroeien met het bedrijf.
Deze slimme manier van bedrijfssoftware realiseren zorgt ook voor flexibiliteit. Want let op: veel bedrijfssoftware lijkt heel flexibel, maar is dat in werkelijkheid niet. Dit geldt zowel voor traditioneel maatwerk als pakketsoftware. Ook het integreren van nieuwe technologie in een low-code platform, aanpassingen in je bedrijfsproces of voldoen aan nieuwe wet- en regelgeving wordt in deze nieuwe situatie ineens een haalbare kaart. Met low-code software ben je niet alleen in staat om je technologieschuld in te lossen, maar ben je volgens mij daadwerkelijk klaar voor de toekomst.
Er is geen enkele reden om aan te nemen dat een low code platform niet veroudert of voor een lock-in zorgt. Bedenk daarbij dat een low code platform vermoedelijk vaak met een moderne ontwikkelmethodiek (scrum) wordt ontwikkeld, dus zonder documentatie, en de rapen zijn over een paar jaar weer gaar.
Het probleem van legacy is zeer reëel, ik denk alleen niet dat we er al een oplossing voor hebben.
@JeroenNL: deels mee eens. Al meer dan 25 jaar wordt low-code als oplossing gezien voor het programmeren-in-een-algemene-programeertaal. Goed te begrijpen. Ontwikkelingen in hardware en besturingssystemen gaan veel sneller dan in ontwikkelomgevingen. Genereren van software, rule-based systemen, allemaal gericht op dicht bij de business te blijven en de afhankelijkheid van de onderste systeemlagen te verminderen.
Dit kan wel degelijk goed helpen, als de documentatie en architectuur van de gebruikte systemen maar wel op orde is. Ik denk dat het in een beperkte serie toepassingen goed kan werken. Zodra snelheid of aanpassing aan specifieke gebruikers-eisen belangrijker wordt val je soms toch terug op legacy, gewoon omdat het beter past bij de gebruikers-eisen. Lock-in? Absoluut, of regel dat goed vooraf.
En overigens: big-bang introductie van nieuw systeem? Meestal helemaal niet nodig. Er zijn voldoende architectuur-technische oplossingen voor. Staat los van legacy of low-code.
Johan Cruyff wist het al: ‘je ziet maar wat je begrijpt’. Iedereen ‘maakt een kaart van een gebied’. En zoekt een beste match. Naarmate meer Google-invloed, je niet meer verdiepen, je vindt wel een antwoord, maar dan ken je het niet. Dan maar vluchten in een illusie van het moment, zelf maar wat knutselen in Excel . Tot de volgende stap. Zonder inleving in het geintegreerde probleem, is men geneigd een symptoom met een symptoom op te lossen, en dwaalt nog verder af.
Volgens mij draait de auteur de werkelijkheid om, hij verkoopt technologie als ‘Haarlemmerolie’ voor een organisatorisch probleem. Wetten en maatschappelijke normen veranderen veel minder snel en compliance is vaak een probleem als er geen (enterprise) architectuur visie is met een strikt governance model. Gartner onderkent dan ook dat er bimodal IT is want de Systems of Record (SoR) die de bedrijfprocessen ondersteunen zijn minder veranderlijk dat de Systems of Engagement die de gebruikers ondersteunen.
De Systems of Record gaan vaak om oplossingen die de wettelijke verplichte ‘bewijslast’ van een proces vastleggen. Het gaat hier om een administratie die specifieke eisen kent vanuit de wet en de efficiëntie hierin wordt bepaald door policies die arbeidsinspanningen in het bedrijfsproces verlagen.
De Systems of Engagement zijn meer gericht op de gebruiker die een zeker mate van autonomie heeft in het proces. Het is de spreekwoordelijke kruiwagen met kikkers als het gaat om integratie omdat elke afdeling zijn eigen visie heeft. En doordat het wiel telkens opnieuw uitgevonden wordt zal de arbeidsinspanning toenemen.
Oja, Gartner erkent dat er bimodal IT is en zal blijven omdat het uiteindelijk niet om de code maar het karakter van de systemen gaat. De onderhoudbaarheid van de code is wel een dingetje want het ‘Too many chiefs and not enough Indians syndroom’ breekt niet alleen de overheid op.
Security, citizen-developers, analyse-skills, documentatie, software onderhoud van de applicatie stacks, integratie, scalability, beheer ..
Zowat de hele ict sector “verkoopt technologie als ‘Haarlemmerolie’ voor een organisatorisch probleem.”
BusOps zegmaar, laat zich nu eenmaal moeilijk specificeren en is dus lastig te implementeren. Wie wil daar nu verantwoordelijk voor zijn ? Wellicht iets met blockchain technology dan maar. Klinkt heel veilig en is niet legacy 😛
Low code platform …. klinkt altijd goed en makkelijk, maar achter die low code omgeving zit uiteraard nog een engine die de low code moet vertalen naar iets uitvoerbaars op de systemen.
Wat ik ook in dit artikel weer proef is dat er vanuit gegaan wordt dat die engine al jouw bedrijfsprocessen en integraties ondersteunt. Op het moment dat je speciale wensen/eisen hebt moet de engine uitgebreid gaan worden, en kom je toch snel weer uit op customizations en hoge kosten
Dit zijn typische problemen die Analysten dienen op te lossen. Ondanks de filosofische en methodologische evoluties in softwareontwikkeling is men blijven vasthouden aan het werken op basis van de vraag van de business, aan de visie van Analyst als brug tussen business en IT, als Analyst als UML-ist (BPMN-ist, …) of als Requirements Manager. Dit is een de-professionalisering van de rol van Analyst. Is het niet tijd dat men deze rol weer ernstig opneemt? Misschien dat dan al deze problemen eindelijk opgelost geraken.
Na 35 ERP implementaties, en maatwerkprojecten hanteer ik graag deze metafoor:
Een organisatie, waar iedereen aan ‘zijn kaart’ vast houdt, en geen water in de wijn wil om zo zijn denkbeeldig ideaal zoekt te laten realiseren, zal snel vaststellen wat dit wordt bij dit voorbeeld: de meesten zullen wel een mechanische klok van nabij gezien hebben, anders maar even Googlen, zo een klok is een assemblage van tandwielen, op gang gebracht door een mechanisme, of met een opgewonden veer, of een gewicht aan een ketting. Bij geen bereidheid tot integraal overleg, en het mechanisme op gang houden, en ‘water in de wijn’ te doen, dan is dat te vergelijken dat ieder zijn eigen tandwiel laat maken. Kan je dan denken hoe goed je mag rekenen op een correcte, dus bruikbare tijdsaanduiding?
Analyse is inderdaad ‘een vak’ dat je niet even leert door wat Googlen. Het vraagt kennis, inzicht en ervaring door ’te doen’ en feedback. Met na-apen en cliches achterna lopen kom je er niet.