Blog
Waarom je bij veel SAAS- en PAAS-providers aan de goden bent overgeleverd
Als een SAAS-applicatie zo traag is dat je medewerkers meer ergernis en verloren werktijd ervaren dan dat ze door die applicatie ondersteund worden, zijn er nauwelijks mogelijkheden om er een fatsoenlijk werkende applicatie van te maken. En SAAS-applicaties die onder de maat presteren - vaak ver onder de maat - zijn eerder regel dan uitzondering. Voor PAAS is de situatie niet veel beter, al heb je dan iets meer mogelijkheden om het euvel te verhelpen.
Als een SAAS- of PAAS-applicatie je bedrijf en je groei hinderen dan kun je klagen bij de leverancier. Vaak komen ze dan terug met een plaatje waaruit blijkt dat ze de SLA of SLA's halen, dat er dus geen probleem is. Dat het aan de gebruikers ligt. SLA's zijn leuk maar ze zeggen meestal niets over hoe snel of hoe langzaam de applicatie voor gebruikers is. Klinkt niet prettig en domdat het dat ook niet is. Maar er is wel een oplossing.
Leveranciers hebben een ander belang dan jij
SAAS- en PAAS-leveranciers lokken klanten met lagere kosten door gedeeld gebruik. Ze kunnen echt voor minder geld leveren. Maar .. hun focus ligt op het verhogen van hun omzet en winst met dezelfde of een lagere inspanning. Het is begrijpelijk dat we allemaal goed willen verdienen, maar je moet je wel realiseren dat jouw belang en hun belang niet hetzelfde zijn.
Soms word je ook gedwongen om over te stappen op SAAS omdat een nieuwe versie van een essentiële applicatie alleen nog als SAAS geleverd wordt. Die stap maakt je leverancier niet om jou geld te besparen, maar om zelf meer te verdienen. Allemaal geen schande maar de gevolgen voor jou .. die snap je wel.
Omdat de leveranciers andere belangen hebben zijn ze niet geneigd om de software structureel te verbeteren of hardware bij te plaatsen. Dat kost hen namelijk geld en levert niets op. Bijbetalen is lang niet altijd mogelijk, en als je bijbetaalt dan verlies je snel het kostenvoordeel dat je oorspronkelijk voor de SAAS-applicatie liet kiezen. Hoe groter de SAAS-leverancier, hoe kleiner de bereidheid om iets op te lossen. Dat is niet alleen onze ervaring, dit is waar dagelijks talloze bedrijven niet alleen mee te maken hebben, waar zoveel IT-managers hard tegenaan lopen.
Besparen door te delen is heel beperkt
Als het te goed klinkt om waar te zijn is het dat meestal ook. Het delen van (virtuele) hardware met anderen levert wel iets op doordat jouw pieken net iets anders vallen dan die van de andere klanten. Maar als je allemaal in dezelfde tijdzone zit dan zijn alle gebruikers gewoon om 9:00 aan het inloggen en loop je tegen dezelfde inlog en dagstartpiek aan die je on premise ook al had. En waarschijnlijk is die piek nog wat erger omdat een SAAS-leverancier bespaart op hardware ten opzichte van je oude on premise situatie. En de after lunch piek om 13:00 krijgen je medewerkers ook nog steeds voor hun kiezen. Klinkt een beetje zuur? Dat is het ook maar we staan er gewoonweg te weinig bij stil.
Afstand gaat ook een rol spelen
Een SAAS-applicatie staat op een grotere afstand van je gebruikers dan een on premise-applicatie. Die afstand zorgt voor meer vertraging - technisch heet dat latency. Die vertraging is in de cloud 10 tot 20 keer zo groot als on-premise, wanneer de applicatie in Nederland wordt gehost. Als hij in Ierland staat, kan de vertraging zelfs 40 tot 80 keer zo groot zijn. Veel SAAS applicaties zijn oude on premise-applicaties die de cloud ‘in gerommeld’ zijn. Ze zijn nooit ontworpen voor cloud-gebruik, en daarmee nooit ontworpen voor het omgaan met netwerkvertragingen. Met lange wachttijden voor je medewerkers als gevolg.
Sluit een XLA af, niet alleen een SLA
Om grip te houden op de ervaring en vertraging die je medewerkers ervaren moet je een eXperience Level Agreement (XLA) afsluiten met je leverancier, naast de SLA's. In een XLA spreek je af aan welke normen de applicatie moet voldoen aan de kant van de gebruiker. Je maakt daarmee dus afspraken hoe goed de applicatie het werk van je medewerkers gaat ondersteunen en versnellen. En dat kun je ook afdwingen. Wij kunnen je helpen om de juiste metrics en criteria in een XLA te krigen.
Bij een XLA moeten de afspraken wel nauwkeurig genoeg zijn. Als je bijvoorbeeld afspreekt dat de applicatie over het jaar gemeten 95% van de tijd moet voldoen aan de normen en er zijn geen afspraken over tijden, dan mag de applicatie ruim 2½ maand (!) niet voldoen aan de normen als alle problemen in kantoortijden vallen.
Zorg voor objectieve cijfers
Een SAAS-leverancier meet wat zijn servers leveren, maar dat is iets anders dan wat jouw gebruikers ervaren. Tussen zijn servers en jouw gebruikers zitten nog diverse netwerken die de applicatie kunnen vertragen. Een deel van wat je gebruikers ervaren wordt ook bepaald door hoe de SAAS-applicatie jouw browsers gebruikt.
Door objectief te meten wat de gebruiker ervaart, en Sciante kan je daarbij helpen, weet je pas echt hoeveel wachttijd (en vaak verborgen ergernis) je gebruiker ervaren bij je SAAS-applicaties. Met objectieve cijfers kun je aantonen dat de applicatie niet aan de normen voldoet. En dat je gebruikers niet aan het zeuren zijn, maar echt een probleem hebben, dat blijkt dan ook. En je weet het ook als je gebruikers wel aan het zeuren zijn, al is dat in onze ervaring zelden het geval. De ervaring van je medewerkers moet ook de basis van de XLA zijn, niet de responstijden van de servers van de leverancier.
Wij vinden de oorzaak, ook als de leverancier niet meewerkt
Laat ik een praktijkvoorbeeld geven. Bij een SAAS-leverancier die op geen enkele manier mee wilde werken zagen we direct dat er een aantal misconfiguraties waren die de applicatie onnodig traag maakten. Oplossen was mogelijk zonder dat deze leverancier extra in hardware moest investeren. We zagen ook direct welke functionaliteit van de applicatie onnodig traag was en voor een deel van die functionaliteit konden we ook de oorzaak van de traagheid achterhalen (het ophalen en versturen van veel te veel data). En dat allemaal zonder enige toegang tot de omgeving van de SAAS-provider. We kunnen dat allemaal vanuit de browser van de gebruiker zien.
Vanwege het volledige gebrek aan medewerking van de leverancier is onze klant overgestapt op een ander SAAS-pakket. Dat was niet hun eerste keus, maar de problemen zijn wel opgelost. De medewerkers kunnen weer snel werken, de irritaties zijn verdwenen en de nieuwe SAAS-applicatie versnelt hun werk. Uiteraard is die nieuwe applicatie natuurlijk eerst door Sciante volledig doorgelicht voordat ze overstapten.
Mijn SAAS-applicatie is ook te traag, wat nu?
Maak een vrijblijvende afspraak met mij en we bespreken wat je problemen zijn en hoe je ze oplost.
Meestal zetten we hiervoor onze Frozen Screen Scan in die razendsnel bepaalt of je objectief een probleem hebt, hoeveel geld en ergernis dat probleem je kost en of je SAAS-leverancier daar wel of niet schuldig aan is.