Veel organisaties maken bij het berekenen van hun softwarekosten dezelfde fout als bij de kosten van een auto. Ze kijken primair naar de aanschafprijs en brandstofkosten, maar zaken als wegenbelasting, verzekeringen, onderhoud en afschrijving worden voor het gemak vergeten. Traditionele bedrijfssoftware brengt ook diverse verborgen kosten met zich mee. Welke dat zijn en hoe je die kunt elimineren, wil ik hier graag toelichten.
Bij het budgetteren van it-projecten worden vaak alleen de kosten voor de aanschaf van de software en extern advies meegenomen. De werkelijke kosten zijn vrijwel altijd hoger. Zo worden interne uren voor de implementatie, de jaarlijkse onderhoudskosten, afschrijvingskosten en faalkosten gemakshalve niet meegerekend. Dit zou geen groot probleem zijn als die extra kosten relatief laag waren. Dat is helaas niet het geval. De onderhoudskosten voor traditionele bedrijfssoftware zijn bijvoorbeeld vaak vele malen hoger dan de aanschafkosten. En daar ziet een organisatie bar weinig van terug. Maar dat is slechts het topje van de ijsberg.
Risico’s van pakketsoftware
De meeste organisaties gaan voor zekerheid en veiligheid als het gaat om bedrijfssoftware. Ze kiezen voor standaard softwarepakketten van bekende leveranciers, zonder zich te oriënteren op wat er nog meer op de markt beschikbaar is. Ze laten zich leiden door de geoliede salesmachines van deze partijen, die ze complexe softwarepakketten aansmeren, die eigenlijk niet aansluiten op de werkwijze van hun organisatie. Vervolgens worden ze meegenomen in eindeloze implementatietrajecten van software die uiteindelijk toch niet doet wat het moet doen. Bovendien verliezen deze pakketten na de initiële implementatie veel van hun flexibiliteit en vereisen daarna kostbaar onderhoud door de vele bedrijfsspecifieke configuraties, vaak honderden randapplicaties en maatwerk.
En vervolgens komen nieuwe, aanvullende softwarekosten om de hoek kijken. Want inflexibele software bij organisaties leidt tot stagnerende innovatie, inefficiënte processen en kan uiteindelijk resulteren in het verlies van de concurrentiepositie.
Hoe ontsnap je nu uit de vicieuze cirkel van duur softwareonderhoud en stagnerende innovatie? Om te beginnen is het van belang om verder te kijken dan de geijkte ‘standaard’ softwareoplossingen. Die waren nooit een echt alternatief. Traditioneel maatwerk is geen optie en je pakket met een ander pakket vervangen, levert je hoogstwaarschijnlijk dezelfde ellende op. Laat je daarom goed informeren en kijk verder dan de ‘veilige’ keuze. Er zijn zoveel nieuwe ontwikkelingen op het gebied van enterprise software, en traditionele pakketleveranciers lopen hierbij zelden voorop.
Zij hebben dertig jaar geleden gekozen voor een technologie waar ze aan vast zitten, maar de gewenste functionaliteit wordt in de loop der jaren steeds complexer. Dit maakt het lastig om nieuwe functionaliteit toe te voegen en aanpassingen aan het datamodel te doen. Het resultaat dat ze voor hun klanten opleveren is daardoor zelden optimaal. Laat daarom alle partijen bij een softwareselectie hun meerwaarde aantoonbaar bewijzen, en zet alle risico’s en verborgen kosten van de verschillende oplossingen op een rij.
Wees in elk geval niet bang voor het onbekende. Kijk naar de inhoud en laat je niet leiden door uiterlijke schijn en gladde marketingpraatjes. In het dagelijks leven experimenteren we er ook op los met nieuwe technologie, apps en gadgets, dus waarom zijn we zo conservatief op zakelijk niveau? De meeste bedrijfssoftware is nog veel te complex en inflexibel. Dit moet anders.
De toekomst van enterprise software
Waar je als moderne organisatie eigenlijk naar zou moeten streven, is bedrijfssoftware die probleemloos meebeweegt met nieuwe technologie en die altijd zijn flexibiliteit behoudt. Software die je modelleert in plaats van programmeert, die los staat van de onderliggende technologie en waaraan je eenvoudig nieuwe functionaliteit als kunstmatige intelligentie toevoegt. Enterprise low-code development biedt hier het ideale platform voor. Hierin kan een organisatie al zijn unieke werkwijzen en processen vastleggen en vervolgens precies de zakelijke applicaties bouwen, die het nodig heeft. Zonder zich in het keurslijf van een softwarepakket te wringen en zonder zijn gedachtegoed te grabbel te gooien voor externe consultants.
Low-code development vereist wel inspanning. Een organisatie moet investeren in deze modelgedreven manier van software bouwen, waarbij de processen – en het continu optimaliseren ervan – centraal staan. Maar die investering betaalt zich uiteindelijk dubbel en dwars terug. Met een enterprise low-code platform kun je de verborgen kosten van traditionele bedrijfssoftware namelijk volledig elimineren. Hierdoor wordt je it-budget niet langer opgeslokt door het onderhoud aan verouderde en rigide bedrijfssoftware, maar kan eindelijk tegemoetkomen aan optimalisatie en innovatie. Met low-code investeer je in de toekomst van je organisatie, en niet meer in het verleden. Door nog één keer een diepte-investering te doen, kan je voor altijd afrekenen met legacy en investeren in innovatie in plaats van onderhoud. Ik zeg: doen!
Je kunt ook op open source zetten. Geen dure licenties maar zelf wat geld steken in een verdere ontwikkeling. Wellicht met “low code”.
En hoe uitwisselbaar zijn de enterprise low code omgevingen?
Als ik mijn bedrijfsprocessen gemodelleerd heb voor leverancier A, en ik wil overstappen naar leverancier B……
Misschien toch maar investeren in beter budgeteren en tool-selectie?
Wij van WC-eend, adviseren WC-eend want om nog één keer een diepte-investering te doen om af te rekenen met de legacy is onzin. Mijn ‘oude liefde’ van AS/400 is al 32 jaar voor veel organisaties het werkpaard zoals Cobol nog steeds een veel gebruikte taal is. Bedrijven zijn afhankelijk van software die min of meer al 30 jaar ongewijzigd is en zonder problemen nog 20 jaar ongewijzigd mee kan omdat de primaire bedrijfsprocessen niet zo veranderlijk zijn. Op dit moment mislukken dan ook 6 van de 10 projecten die deze legacy proberen te migreren om het simpele feit dat de ‘bedrijfslogica’ van enterprise oplossingen gebaseerd is op technologie die erg betrouwbaar blijkt te zijn als het om een bedrijfsasset zoals data gaat.
“Software die los staat van de onderliggende technologie.”
Ik daag de schrijver van dit artikel bij deze uit om deze bewering te staven.
Als low-code platformen zo goed werken zou je verwachten deze zeer veel tegen te komen….
Naast vendor lock-in heb ik twijfels bij de UX of de migraties van v1 van een proces naar v2. Ofwel de onderhoudbaarheid en veranderingsmanagement.
Ook is mijn ervaring dat als je 80% van het probleem tackelt de overige 20% het voordeel van de 80% teniet doet. Vaak krijg je hele kromme constructies om de missende 20% te compenseren.
Daarnaast lijkt er een wetmatigheid te zijn op het volgende: Een generieke oplossing versus een “hard coded” oplossing verplaatst de complexiteit naar allemaal vreemde plekken. Het maken van rapportages wordt lastiger of het beheersbaar houden of het veranderen.
De eerste vraag die je jezelf moet stellen is: Welk probleem los ik op?
Low code… je ziet mij twijfelen..
@Robert van der Linden
“Veel organisaties maken bij het berekenen van hun softwarekosten dezelfde fout als bij de kosten van een auto. Ze kijken primair naar de aanschafprijs en brandstofkosten, maar zaken als wegenbelasting, verzekeringen, onderhoud en afschrijving worden voor het gemak vergeten.”
Slechte analogie! Je hebt mensen die kijken alleen naar het merk, of de motor (meer pk’s is beter) of de kleur, maar de meeste mensen wegen meerdere zaken mee bij het kopen van een auto. Leasemaatschappijen nemen alles mee uit jouw opsomming, en een aanzienlijk deel van het Nederlandse wagenpark is geleased.
Als iets al 30 jaar werkt, dan is het misschien gewoon goed. Overigens is (het gebrek aan) kwaliteit van alle tijden: zowel vroeger in Cobol / C++ als nu in de cloud of met low code tools kun je goede en slechte software schrijven. Als data, business logic en presentatie goed gescheiden zijn, dan kun je met willekeurig welke tool zo een applicatie maken in bv de presentatielaag die geen gevolgen heeft voor de consistentie van de data in de datalaag.