woensdag 15 februari 2012

Pas op met SAAS in the cloud

SAAS: Pas op met SAAS in the cloud, en let op mogelijke valkuilen

Met SAAS (Software As A Service) heb je als klein bedrijf de beschikking over software die tot voor kort alleen voor grote bedrijven beschikbaar was. Je hebt geen eigen infrastructuur nodig, en ook geen beheer, en de kosten zijn lager.
Maar is dat echt zo?


Cloud: Geen baas over eigen data
Allereerst: Wees terughoudend met SAAS in the cloud. Je weet niet waar de bedrijfsgegevens blijven, en welke wetgeving op die data van toepassing is. In de V.S. is de regelgeving met betrekking tot databescherming min of meer op "laissez faire" basis, en sterker nog: De Patriot Act geeft instanties het recht om uw data te bekijken en te interpreteren. Eenmaal op een zwarte lijst bij overheden - al of niet terecht - is meestal fataal voor het voortbestaan van het bedrijf. Het is maar dat u het weet.

Afscheid van maatwerk
Het verdienmodel van SAAS aanbieders is gebaseerd op het feit dat iedereen hetzelfde krijgt aangeboden. Maatwerk past dan ook niet in het verdienmodel, en wordt uiteindelijk ook niet aangeboden. Uiteindelijk. Het zal niet het eerste selectietraject zijn waarbij het selectieteam de perceptie heeft dat "alles configureerbaar" is. Eenmaal geimplementeerd worden de beperkingen pijnlijk zichtbaar: De koppeling met het andere systeem dat niet te realiseren is, het niet kunnen afbeelden van het volledige organisatiemodel in de inrichting. In tegenstelling tot een systeem in eigen beheer of een systeem op ASP basis kunt u geen aanpassing laten doorvoeren, maar mag u een wens doen. Of en wanneer de wens wordt ingevuld - hangt volledig van de leverancier af. Wie weet wordt de wens niet gerealiseerd. Dan resten twee dingen: accepteren, of de omringende systemen en processen aanpassen.

SAAS of klatergoud?
Er zijn leveranciers die proberen een ASP oplossing als SAAS oplossing voor te spiegelen. Ik refereer aan de propositie van een van de grootste aanbieders van ERP software voor het MKB. Per klant is dedicated hardware vereist, schaalbaarheid wordt geslachtofferd. Met ASP ervaart men zelf de lasten van releases, en mag er - als er geen eigen applicatiebeheerder voorhanden is - veelal op nacalculatie beheercapaciteit bij de aanbieder worden afgenomen om bijvoorbeeld conversiewerk en inrichtingen uit te voeren. Achteraansluiten graag.

De harde praktijk
Bij een aanbieder die wel SAAS aanbiedt, zijn een aantal praktijkervaringen de volgende:

- Een relatief hoog releasetempo (eens per maand) noopt tot het frequent doorlezen van releasenotes die vaak op de dag zelf nog worden aangepast. Dit geeft met regelmaat aanleiding tot storingen en de vraag is of gebruikers dit verandertempo apprecieren.

- Veel SAAS diensten zijn gebaseerd op een gecompliceerd applicatielandschap. Integratie is dan een issue, het aantal incidenten is soms tot wel een factor 10 hoger dan bij de saaie standaard software die twee tot vier keer per jaar een nieuwe release kent. En fouten vereisen vaak complexe "root cause" analyses. Afwijkende inrichtingen vormen vaak een bron van fouten. En natuurlijk bent u de enige die de afwijkende inrichting gebruikt, en dus de enige die dit probleem ervaart - volgens de leverancier. U zal de eerste niet zijn die dure consultancy uren betaalt aan een leverancier om haar eigen fouten op te lossen.

- Let er op dat de SLA concrete prestatie en performancecriteria vermeldt. Bent u een klein bedrijf: jammer. Bent u een groot bedrijf: hanteer het principe dat er niet zoiets bestaat als een standaard SLA. Performance is vaak een probleem, let erop dat de leverancier rapportages levert en een servicemanager in dienst heeft. En omdat de dienst over het publieke internet wordt benaderd: de performance is vaak slechter dan een in-house oplossing.

Bij SAAS oplossingen bespaart men duidelijk op kosten van infrastructuur en technisch beheer. Het is maar de vraag of er bespaard wordt op applicatiebeheer. Evenmin is het op voorhand duidelijk of de performance van de SAAS toepassing dusdanig is dat de processen die van de toepassing gebruik maken wel zo efficient blijven als voorheen. Sommige leveranciers hanteren een uitermate onoorzichtig kostenmodel met tellers op moeilijk in te schatten meetpunten, zoals bijvoorbeeld de gegenereerde bestandsomvang, het aantal opgevraagde uitvoerproducten, etcetera.

Wat is dus de marsroute als er overwogen wordt een SAAS toepassing te implementeren? Naast de klassieke selectieprocessen is er een gouden regel: Start een proeftuin, en laat een kleine vestiging of een afdeling met echte klanten de toepassing gebruiken. Meet de effectiviteit door middel van het meten van de productie versus de bestede tijd vastgelegd in een tijdschrijf systeem. Leer de leverancier kennen, inclusief de support processen. Zwicht niet voor de interne druk om snelheid te maken door een paar weekjes te testen.

Geen opmerkingen:

Een reactie posten