Sharing IT Best Practices with youSharing IT Best Practices with you
Mislukken SaaS
In dit artikel onderzoeken we waarom veel SaaS projecten mislukken als gevolg van systeemselectie of implementatiefouten – en we geven enkele tips om dit goed te doen.
Het is een zeer triest feit dat veel SaaS-implementaties mislukken. De kans van slagen is ongeveer 50%. Dit lijkt misschien bemoedigend, maar het betekent nog steeds dat de helft van onze projecten mislukt!
“Mislukken” definiëren we vaak als het feit dat het project is stopgezet of nooit is uitgevoerd.
Maar in dit artikel rekenen we daar ook projecten bij die meer hebben gekost dan verwacht, langer duurden dan verwacht of niet aan alle functionele doelstellingen voldeden. Dus in termen van het al dan niet bereiken van de doelstellingen, is het beeld ongetwijfeld iets gunstiger.
Een SaaS project kent twee kritieke momenten die bepalend zijn voor het mislukken of slagen van het project.
De implementatie van een SaaS-systeem vergt de nodige aandacht van de organisatie en zal zowel in tijd als in geld kostbaar zijn. We kunnen het ons niet veroorloven om het fout te doen! Het kiezen van het verkeerde systeem komt meestal neer op een van de vier dingen, namelijk:
Er is een verbijsterende hoeveelheid SaaS applicaties beschikbaar en er is behoorlijk wat onderzoek nodig om potentiële SaaS oplossingen voor onze specifieke organisatie te vinden. Het gaat daarbij niet alleen over kennis van de software en de eigen bedrijfsprocessen, maar ook over kennis over de leveranciers. Wat is hun financiële positie? Eén van de grootste gevaren van SaaS is dat de leverancier failliet gaat.
De industrie wemelt van de verhalen van organisaties waar niet het personeel, maar een trustee, een directeur of een consultant het systeem selecteerde. Medewerkers die het systeem dagelijks gebruiken, moeten echter vanaf het begin tot aan de selectie en implementatie bij het hele proces worden betrokken. Zij zijn namelijk degenen die echt weten wat er nodig is. Soms hebben ze wat hulp van experts nodig om het proces te begeleiden en hen bewust te maken van de mogelijkheden die SaaS biedt. Zij zijn echter de enigen die kunnen beoordelen of een functie nuttig zal zijn of niet. Een organisatie kan een formeel selectieproces doorlopen waarbij alle medewerkers betrokken zijn. Als de algemeen directeur echter de uiteindelijke keuze maakt slaan we de plak mis. Het personeel is het daar namelijk niet mee eens en het systeem raakt dan vrijwel onmiddellijk in onbruik. Overeenstemming is essentieel.
Er zijn veel verschillende manieren om een SaaS oplossing te selecteren en de verschillende methodieken bespreken we hier niet. Het volstaat te zeggen dat we wel een formele methode moeten volgen. Als we voor een selectieproces kiezen, moeten we daar rigoureus in zijn. Veel SaaS toepassingen kennen een gratis proefperiode van 30 dagen na het selectieproces. Als we echter al na 2 dagen tot de conclusie komen dat de software voor ons niet gaat werken is er iets misgegaan. Dit soort problemen moeten we eigenlijk al oppikken tijdens de product-demo.
We kunnen geen systeem implementeren zonder gedetailleerde requirements. Zo kunnen we ook geen SaaS oplossing selecteren zonder vooraf de requirements in detail te specificeren. Leveranciers kunnen immers op vage eisen oprecht ja antwoorden. Als we denken aan COTS applicaties dan hebben we die vaak gehoord: “Ik dacht dat het X en Y zou doen, maar dat doet het niet”. Maar hebben ze wel aangegeven dat ze wilden dat het X en Y deed?
Enkele gouden regels om niet te mislukken zijn:
Als de software eenmaal is aangeschaft, beginnen de echte problemen zich voor te doen. SaaS implementaties zijn nooit eenvoudig. Sommige redenen zullen niet prettig zijn om te lezen, maar alle beschreven redenen zijn reëel en de gegeven voorbeelden zijn ontleend aan de praktijk. Nieuwe SaaS implementaties zijn complex, verwarrend en pijnlijk. We sommen de belangrijkste redenen op waarom projecten mislukken; Politiek, Arrogantie, Incompetentie, Bijziendheid, Angst, Onbekendheid en Lethargie.
Interne bedrijfspolitiek, onderlinge strijd en het opbouwen van een imperium zijn verantwoordelijk voor veel systeemfouten. Sommige mensen zijn het er nooit mee eens, ze beschermen hun eigen territorium fel (“mijn” klanten, “mijn” data). Ze willen hun status niet verliezen of hun personeelsbestand verminderen. Ze willen niet dat andere mensen krijgen wat ze hebben.
Een voorbeeld is dat we een SaaS-systeem implementeren om dringende problemen op een bepaalde afdeling op te lossen. Als we het dan verder uitrollen naar andere afdelingen blijkt dat de hele database structuur niet geschikt is voor de rest van de organisatie. De eerste afdeling roept echter het hardst en krijgt als eerste de beschikking over de software.
Er zijn bepaalde mensen die denken dat ze het het beste weten en/of de rest van het personeel pesten om hun mening te accepteren. De helft van de medewerkers zal weigeren om het systeem te gebruiken. Een voorbeeld is de Chief Executive die een SaaS oplossing koos voor zijn medewerkers. Deze software had echter niet veel van de functionaliteit die de medewerkers nodig hadden. Toen ze hem op hun zorgen wezen, was zijn reactie: “Het is een goed systeem, laat het werken”. Dat deden ze niet, ze creëerden tijdelijke oplossingen in Access en Excel.
Er zijn voorbeelden in overvloed van organisaties die enorme fouten maken bij de selectie, vooral maar ook bij de invoering. Bij incompetente medewerkers mislukken vaak meerdere SaaS implementaties achtereen. Deze medewerkers hebben weinig of geen kennis van IT en weinig of geen kennis van de dagelijkse bedrijfsprocessen. Het gaat hierbij vaak om systemen die gewoon niet werken of essentiële functionaliteit missen.
Voor een succesvolle implementatie kunnen we het beste een een echte opdrachtgever inzetten die al het gedetailleerde werk over laat aan de gebruikers en onafhankelijke adviseurs.
En wat te denken van de directeur die zijn SaaS-leverancier wil aanklagen omdat het systeem te laat was, het budget overschreed en niet alle functionaliteit had die hij had verwacht. Helaas heeft hij vooraf geen gedetailleerde requirements opgesteld en heeft hij dus juridisch geen poot om op te staan.
Een SaaS (ERP) implementatie is een organisatiebreed project. De meeste mensen kijken alleen naar het effect ervan op hun eigen kleine bedrijfsonderdeel en zien het ‘grote geheel’ niet. Daarom doen ze dingen zoals alleen het invoeren van data die hun afdeling nodig heeft en het negeren van andere informatie die ze mogelijk bezitten en die van belang kan zijn voor anderen in de organisatie.
Een voorbeeld van bijziendheid betreft afdelingen die ontdekken dat het SaaS-systeem veel omslachtiger en langzamer werkt dan hun spreadsheet, dus blijven ze hun spreadsheet gebruiken. Het resultaat kan zijn dat koppelingen naar andere afdelingen niet werken en bijvoorbeeld facturen niet compleet zijn. Afdelingen kunnen weigeren om hun werkwijze te wijzigen en huurden daarom extra personeel in om de ‘extra’ werkdruk die het systeem hen oplegde aan te pakken. In feite zijn deze afdelingen bezig met het printen en archiveren van documenten die niemand meer zal bekijken.
Angst voor verandering is een groot probleem dat zich over het algemeen manifesteert in de volgende gedragingen:
Er wordt hen gevraagd iets te doen en ze doen het met tegenzin of halfslachtig of helemaal niet. In extreme gevallen zijn de medewerkers zo paranoïde bij de gedachte aan veranderingen, dat ze aandringen op aanpassingen aan het systeem. Dat kan de organisatie uiteindelijk veel geld kosten.
Er zijn twee aspecten aan onbekendheid. Een daarvan is de overgang van een systeem dat we al vele jaren gebruiken naar iets dat nieuw en anders is. Dit hangt samen met Angst hierboven. De tweede is niet bekend zijn met de volledige functionaliteit van het te nieuwe systeem. Er zijn talloze consultants die worden gevraagd om een organisatie te helpen bij het kiezen van een nieuw systeem “omdat het X niet doet of Y niet”. Tijdens het onderzoek ontdekken ze echter dat het wel X en Y doet. Men was niet van op de hoogte of ze hadden de laatste updates van hun software niet geactiveerd.
Lethargie kan desastreuze gevolgen hebben voor de testinspanningen omdat deze problemen zich vaak pas manifesteren tijdens de live-gang. Medewerkers moeten echter op de een of andere manier tijd vinden om hun projectverantwoordelijkheden uit te voeren, anders zal het project mislukken. We kunnen medewerkers voorbeeld vragen een maand lang één uur per dag te testen. Maar als ze in plaats daarvan de projectmanager vragen om het voor hen te doen, gaat het fout. Het resultaat zal zijn dat het systeem niet aan hun verwachtingen voldoet en uiteindelijk mislukt.
Het selecteren en implementeren van SaaS-oplossingen is een enorm complexe taak die in elke fase uitdagingen met zich meebrengt. Het duurt langer langer dan we verwachten en het kost altijd meer dan we budgetteren. Hopelijk vergroot het vermijden van enkele van de fouten die door anderen zijn gemaakt, zoals hierboven beschreven, onze kansen op succes.
Dit artikel is geïnspireerd door een artikel op ictknowledgebase.org.uk. “Why Do Most CRM Implementations Fail” van Peter Flory. Dr. Peter Flory is een onafhankelijke IT-consultant voor de vrijwilligerssector en een research fellow aan de Brunel University. Hij is bereikbaar op 0118 986 6623 of e-mail: [email protected]
Discussieer mee op LinkedIn. 
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.