DIGITAL MOTIONS INZICHT
Kiezen we voor SaaS of on-premise?
De vraag klinkt logisch, maar komt vaak te vroeg in selectietrajecten. De belangrijkste vraag is niet waar de software draait, maar of de applicatie de gewenste bedrijfsprocessen ondersteunt en welke verantwoordelijkheden de organisatie zelf wil dragen. Een SaaS-oplossing kan veel beheer uit handen nemen. Wanneer noodzakelijke processen echter onvoldoende worden ondersteund, kan een beheerde applicatieomgeving meer passend zijn.
De locatie van software bepaalt niet de beste keuze
• Kies niet automatisch voor SaaS omdat cloud de norm lijkt; beoordeel eerst of de oplossing de processen voldoende ondersteunt
• Maak onderscheid tussen on-premise, hosting en SaaS: deze modellen verdelen beheer, beveiliging en veranderverantwoordelijkheid anders
• Meer vrijheid in inrichting betekent meestal ook meer verantwoordelijkheid voor updates, continuïteit, integraties en specialistische kennis
• Een hybride applicatielandschap kan goed functioneren, mits identiteit, data, integraties en eigenaarschap samenhangend worden ingericht
WAAROM DIT INZICHT ERTOE DOET
Het voeren van de discussie over techniek te vroeg in een softwareselectie is vooral riskant bij organisaties met processen die afwijken van de standaard. Denk aan productspecifieke kwaliteitscontroles, afwijkende orderstromen, klantspecifieke prijsafspraken, complexe stuklijsten of een planning waarin machines, mensen en materiaal gelijktijdig moeten worden afgestemd. Een SaaS-pakket kan op hoofdlijnen geschikt lijken, maar belangrijke uitzonderingen onvoldoende ondersteunen.
Wanneer beperkingen pas tijdens de inrichting zichtbaar worden, ontstaan noodoplossingen. Medewerkers houden aanvullende spreadsheets bij, gegevens worden handmatig overgenomen of processen worden aangepast aan de software zonder dat hierover bewust is besloten. De organisatie heeft dan wel een moderne applicatie, maar niet vanzelfsprekend een beter bestuurbaar proces.
Bij SaaS gebruikt de organisatie een kant-en-klare applicatie waarvan een groot deel van de technische omgeving door de leverancier wordt beheerd. Bij een applicatie die op eigen servers draait, blijft vrijwel de volledige technische verantwoordelijkheid bij de organisatie. Hosting op Microsoft Azure zit daar vaak tussenin: de fysieke infrastructuur wordt door Microsoft verzorgd, maar afhankelijk van de gekozen dienst blijven het besturingssysteem, de applicatie, configuraties en beveiligingsmaatregelen de verantwoordelijkheid van de klant of applicatieleverancier.
Daarom moet een directie niet alleen vragen welke oplossing functioneel het beste past. Zij moet ook bepalen wie verantwoordelijk wordt voor beschikbaarheid, updates, gegevensbescherming, toegangsbeheer, integraties, herstel bij storingen en toekomstige aanpassingen. Juist die verdeling bepaalt of een oplossing op langere termijn beheersbaar blijft.
WAAROM DIT INZICHT ERTOE DOET
Procesdekking is meer dan een lijst met functies
Een softwareselectie begint vaak met een uitgebreide wensenlijst. Het ene pakket voldoet aan 85 procent, het andere aan 90 procent. Zulke scores lijken objectief, maar zeggen weinig wanneer niet duidelijk is welke eisen werkelijk onderscheidend zijn.
Niet iedere afwijking is even belangrijk. Een rapport dat anders is vormgegeven, hoeft geen doorslaggevend bezwaar te zijn. Een applicatie die de primaire productieplanning, traceerbaarheid of serviceafhandeling niet ondersteunt, raakt direct de bedrijfsvoering. De directie moet daarom eerst vaststellen welke processen standaardiseerbaar zijn en welke processen bepalend zijn voor leverbetrouwbaarheid, marge, kwaliteit of onderscheidend vermogen.
Daarbij hoort ook een kritische vraag: ontbreekt de functionaliteit werkelijk, of probeert de organisatie een historisch gegroeide werkwijze te behouden? Maatwerk kan legitiem zijn, maar niet iedere bestaande uitzondering verdient een plaats in het nieuwe systeem. Eerst moeten de huidige processen expliciet worden gemaakt. Daarna kan bewust worden besloten wat gestandaardiseerd, verbeterd of behouden moet worden.
Pas dan ontstaat een eerlijke vergelijking. SaaS is passend wanneer de standaardprocessen voldoende aansluiten en de organisatie bereid is binnen de kaders van het platform te werken. Een zelf beheerde of specifiek gehoste oplossing kan beter passen wanneer essentiële procesondersteuning, integratiemogelijkheden of veranderbaarheid aantoonbaar ontbreken.
Hosting maakt een applicatie nog geen SaaS
De termen cloud, SaaS, hosting en on-premise worden in gesprekken regelmatig door elkaar gebruikt. Dat vertroebelt de besluitvorming.
Bij on-premise draait de omgeving daadwerkelijk op infrastructuur op de eigen locatie of in een eigen datacenter. Wanneer een traditionele applicatie op virtuele servers van een IT leverancier of in Microsoft Azure wordt geplaatst, is er sprake van hosting. De organisatie verplaatst dan de infrastructuur naar de cloud, maar behoudt veel verantwoordelijkheden die bij de applicatie en het technisch beheer horen. SaaS gaat verder: de leverancier levert en beheert de applicatie als complete dienst. De verschillende modellen zijn dus geen varianten van dezelfde technische locatie, maar verschillende verdelingen van controle en verantwoordelijkheid.
Hosting in Azure kan wel degelijk voordelen bieden. De organisatie hoeft geen eigen fysieke servers te onderhouden en kan gebruikmaken van cloudvoorzieningen voor beschikbaarheid, beveiliging en schaalbaarheid. Ook kan een bestaande bedrijfsapplicatie worden gekoppeld aan Microsoft Entra ID, zodat gebruikers op een vergelijkbare manier toegang krijgen tot Microsoft 365, SaaS-oplossingen en bepaalde intern beheerde applicaties. Microsoft beschrijft hiervoor onder meer mogelijkheden voor eenmalige aanmelding, meervoudige verificatie en centraal toegangsbeheer.
Die technische mogelijkheid is echter geen garantie voor een eenvoudige integratie. Koppelingen met Outlook, Teams, SharePoint, Power BI of andere Microsoft-diensten moeten functioneel en technisch worden ontworpen. De gebruikte applicatie moet deze koppelingen ondersteunen en er moeten duidelijke afspraken zijn over gegevens, autorisaties, beheer en wijzigingen.
Bepaal welke verantwoordelijkheid u werkelijk kunt dragen
Meer vrijheid klinkt aantrekkelijk. Een eigen omgeving kan ruimte bieden voor maatwerk, een eigen releaseplanning en specifieke integraties. Maar iedere extra vrijheid vraagt beheer. Wie controle houdt over de applicatie, moet ook organiseren dat patches worden uitgevoerd, kwetsbaarheden worden opgevolgd, back-ups worden getest en kennis beschikbaar blijft.
Voor veel middelgrote bedrijven is niet de technologie, maar de beschikbare capaciteit de beperkende factor. Eén interne applicatiebeheerder kan veel functionele kennis hebben, maar niet automatisch alle expertise leveren voor infrastructuur, databases, beveiliging, integraties en continuïteit. Wanneer cruciale kennis bij één medewerker of leverancier ligt, ontstaat een bedrijfsrisico.
Breng daarom vóór de keuze in kaart welke rollen nodig zijn. Wie is eigenaar van het proces? Wie besluit over wijzigingen? Wie beheert gebruikers en autorisaties? Wie bewaakt de technische omgeving? Wie handelt bij een storing? En wie beoordeelt of aanpassingen nog passen bij de architectuur en bedrijfsdoelen?
De uitkomst hoeft geen principiële keuze voor één model te zijn. Een organisatie kan Microsoft 365 en verschillende standaardapplicaties als SaaS gebruiken, terwijl een bedrijfskritische productie- of logistieke applicatie in een afzonderlijk beheerde Azure-omgeving draait. Zo’n hybride landschap is verdedigbaar, zolang het een bewuste inrichting is en geen verzameling losse uitzonderingen.
UIT DE PRAKTIJK
Een herkenbaar praktijkpatroon laat zien waar de werkelijke afweging ligt.
De standaard paste, behalve waar het telde
Een productiebedrijf vergelijkt verschillende SaaS-oplossingen voor de ondersteuning van verkoop, planning en productie. De demonstraties zien er overtuigend uit. De leveranciers bieden regelmatige updates, voorspelbare abonnementskosten en weinig technisch beheer. Toch blijkt tijdens de procesanalyse dat een bepalende stap in de productieplanning niet goed wordt ondersteund.
De eerste reactie is om het proces aan het SaaS-pakket aan te passen. Nadere analyse laat echter zien dat deze werkwijze direct samenhangt met korte levertijden en het combineren van verschillende productieruns. Het betreft dus geen willekeurige historische uitzondering, maar een proceskeuze met bedrijfseconomische betekenis.
De organisatie kiest daarom niet onmiddellijk voor SaaS of voor eigen beheer. Eerst wordt het gewenste proces ontworpen en worden de kritieke beslisregels vastgelegd. Vervolgens worden de oplossingen opnieuw beoordeeld op procesdekking, integratiemogelijkheden en beheerlast. Daardoor wordt duidelijk waar standaardisatie verstandig is en waar aanvullende vrijheid werkelijk waarde toevoegt. De hostingvorm volgt uit die afweging, in plaats van andersom.
CONCLUSIE
Kies SaaS, hosting of on-premise pas nadat duidelijk is welke processen leidend zijn en welke technische en organisatorische verantwoordelijkheden de organisatie duurzaam kan dragen.
MEER INZICHTEN
