.png){kind=spacer}
Stel, je bent een groeiende organisatie en het schuurt alleen tijdje tussen je primaire proces en de Applicatie die dat proces ondersteunt. Het gevoel begint te ontstaan dat een andere applicatie zou helpen om een mooie ontwikkelstap te maken als organisatie. Het idee is zelfs al geopperd om dan maar een applicatie te laten bouwen dan wel zelf te bouwen. Andere geluiden in de organisatie zeggen dat maatwerk een te grote stap is.
En dan? Hoe verder? Weinig zaken binnen ICT hebben zo’n vreemde reputatie als maatwerk; sommige bedrijven zweren erbij, andere vervloeken het. In deze blog kijken we naar de kenmerken van maatwerk, proberen we de vreemde positie van maatwerk te duiden en geven we een paar tips voor organisaties die proberen te besluiten over maatwerk.
Eerst maar weer een definitie; onder maatwerk verstaan we (ICT)middelen die specifiek voor jouw organisatie gemaakt is en onderhouden wordt. Het kan betrekking hebben op alles dat je besteld ( zoals een pak) maar hier spitsen we ons toe op software. Maatwerk is geen zwart wit onderscheid/begrip. Elke dienst of product dat je aanschaft bevat iets van maatwerk. Het verschil zit ‘m in de verhouding standaard versus aangepast. Vroeger was dit een redelijk binair verhaal; je kocht een suite of je liet iets bouwen. Met de komst van Saas en Low code platforms is dit een meer gradueel begrip geworden.
Bij Low code is het resultaat in principe maatwerk (er wordt een proces-ondersteunende applicatie gecreëerd die nog niet bestond) maar doordat er voornamelijk geconfigureerd wordt onderhoudt de leverancier geensoftware specifiek voor jou. Contractueel gezien is het dus niet meer maat werk dan configuratie van cloud software.
Dit is een duidelijke; de gedachte achter maatwerk is dat jouw organisatie uniek is en de software die dat ondersteunt dus ook uniek moet zijn.
De voordelen van maatwerk zijn dus dat je het helemaal aan je wensen aan kunt passen. Je kunt er dus voor zorgen dat je het, volgens jou, ideale proces kunt vormgeven.
Hierdoor kun je in theorie businessdoelen halen die anders onmogelijk zijn.
Lees verderop meer over de randvoorwaarden waar je rekening mee moet houden om die voordelen te pakken.
Bij de nadelen zullen kosten op nummer één staan. Als een bedrijf iets maakt dat ze maar één keer aan één klant kunnen leveren zal dat duurder zijn dan iets dat ze één keer maken en vervolgens oneindig vaak aan oneindig veel verschillende klanten kunnen leveren. (Schilderij versus downloadbaar-boek). Die kosten zijn uiteraard geen probleem als de potentiële opbrengsten( ten opzichte van niet-maatwerk) hoger liggen dan de extra kosten.
Dit impliceert wel dat je zelf een heel goed beeld hebt van wat je nodig hebt én hoe je dat moet (laten) bouwen. De praktijk laat volgens mij zien dat het juist daar stokt.
Daar kom je later op terug maar misschien goed om dat hier al aan te kondigen.
Om maatwerk tot een succes te maken moeten in onze optiek aaneen paar randvoorwaarden voldaan zijn.
Dit is veruit de belangrijkste voorwaarde: is er echt geenoplossing op de markt voor dit probleem of voor deze doelstelling? Zoals hierboven aangegeven is maatwerk altijd duurder dan niet maatwerk. Als er dus een pakket op de markt is dat ( een groot genoeg deel van) de gevraagde functionaliteiten aanbiedt is het verstandig aanschaf daarvan sterk te overwegen en niet te bouwen.
Stel dat je droom of visie helemaal gebouwd wordt en functioneert; maakt dat dan dat jouw organisatie een andere positie in de markt krijgt? Als je proces of de applicatie die het proces niet de onderscheidende factor gaat zijn moet je je serieus afvragen of het handig is om aan een maatwerk traject te beginnen, de kostenwegen dan niet op tegen de voordelen.
Je wilt zeker weten dat de visie of droom breed binnen de organisatie gedeeld wordt. Uit de eerste twee punten is af te leiden dat je maatwerk in wil zetten op strategische onderwerpen, op onderwerpen die je wilt doen en niet op onderwerpen die je moet doen. Op onderwerpen die maken dat jullie organisatie echt gaaf wordt. Dat zijn per definitie onderwerpen waarvoor je backing van C level nodig hebt en liefst waarvan je weet dat het beeld dat ze invullen ook door de rest van de organisatie gedragen wordt, anders is de kans groot dat er weinig energie zal ontstaan bij livegang.
Maatwerksoftware is als een huisdier, die heb je ook na de eerste twee weken nog. Anders gezegd, maatwerk vereist niet enkel behoorlijk wat energie tijdens het bouwen maar vereist ook energie en tijd om actueel te houden en door te ontwikkelen, er is immers geen leverancier die het voor je doet.
Als je tot nu toe enkel functioneel beheerders had die tegenapplicatiebeheer aanleunden en dus geen functionele consultants zijn is dat een uitdaging. Je kunt immers wel mensen binnenhalen die de competenties hebben, maar die missen dan weer de kennis van je visie. Deze persoon moet ook affiniteit hebben met softwareontwikkeling en als je voor plan was het agile te doen, van agile software ontwikkeling.
Om maatwerksoftware gebouwd, draaiend en actueel te houden moeten de technische applicatiebeheer en beheer- en software ontwikkeling- lagen ook gedekt zijn voor alle componenten ( applicatie, database, opslag, virtualisatie, back-up, informatiebeveiliging). Je hoeft het niet zelf te doen en niet bij alle technieken zijn alle lagen even nodig maar de lagen moeten wel gedekt zijn. Als niet met eigen mensen dan wel met leveranciers met ervaring. Als je een deel van de lagen met externen gaat doen zul je ook een regie rollen in moeten richten, de regie op dit soort leveranciers is namelijk een stuk intensiever dan die op suite leveranciers.
Om de Experts moet ook een wolk zijn van ge-engageerde gebruikers, hoe je ze ook noemt. Als je een suite afneemt regelt de leverancier dit namelijk voor je. Als je tot nu toe een top-down-push benadering hebt gehad kan het zijn dat je deze laag ook nog moet ontwikkelen.
Als laatste moet de optelsom van alle bovenstaande zakenpositief zijn dus:
(Potentiële baten door onderscheidend vermogen) – ( kostenmaatwerk -kosten suite) = positief.
Lijkt triviaal maar als je deze som niet in kunt vullen ben je er waarschijnlijk niet klaar voor.
Er zullen vast nog meer punten zijn maar bovenstaande zal je op weg helpen om de keuze tussen maatwerk en suites op gang te helpen binnen je organisatie.
Kijk, als je dat wat je zoekt in suites niet kunt vinden, eerst eens naar de verschillende low-code platforms. De wereld van Low code is de afgelopen jaren veel volwassener geworden en combineert een hoop van de voordelen van de cloud/suite wereld met die van de maatwerk wereld. Er zullen nog steeds zaken zijn die je moet regelen maar wel veel minder.
.png)