Saas, 2007 hype or hot/not?

Saas lijkt uit te groeien tot de hype van 2007. De meningen over een hype of een permanente andere beleving van software lopen nogal uiteen. In dit artikel geeft Mark Vroom, technisch directeur bij NedFox, een weergave van waar NedFox als organisatie mee te maken kreeg vanaf het moment dat het idee ontstond om Saas te gaan introduceren tot het moment van werkelijk live gaan van de eerste klant.

Het idee

NedFox is de producent van onder andere POS4All, een in Visual FoxPro ontwikkelde retail applicatie. Na honderden installaties van POS4All te hebben uitgevoerd, is op een zeker moment geanalyseerd naar het verleden wat de grootste problemen waren met de uitrol van dergelijke software. Ook is destijds een POS4All Lite concept uitgeprobeerd, waarbij gebruikers zich konden registreren en vervolgens direct de beschikking kregen over de software. In feite was dit een voorloper van het on-demand concept wat tegenwoordig steeds meer de overhand krijgt. POS4All Lite kwam echter niet geheel van de grond, in tegenstelling tot de eigen verwachtingen.

Uitrol van software

Hoe mooi je het ook regelt, de uitrol van traditionele software is en blijft een lastig punt. Gevorderde gebruikers krijgen eenvoudige software nog wel aan het werk, maar een complexe retail applicatie die een bedrijfskritische rol moet gaan vervullen, is een heel ander verhaal. Problemen die je daarbij tegenkomt variëren van het instellen van vereiste rechten tot het inrichten van de applicatie en vervolgens beschikbaar stellen aan de overige gebruikers. Laten we het in dit verband maar niet hebben over de niet-gevorderde gebruikers … die krijgen een dergelijke retail applicatie in het geheel niet geïnstalleerd.

Je zult, tenzij je Microsoft heet, nooit grote aantallen gaan realiseren

Samengevat is het aantal handelingen dat uitgevoerd moet worden vrij groot en zul je (tenzij je Microsoft heet) nooit grote aantallen kunnen realiseren wanneer er op traditionele wijze gedistribueerd blijft worden. Potentiële gebruikers tonen op een zeker moment interesse, maar die interesse wordt echter heel snel gereduceerd wanneer de installatie te veel werk omvat.

Saas

Alvorens in te gaan op de inhoudelijke kant van de door NedFox gekozen oplossing, ligt het voor de hand om Saas te beschrijven. Saas moet niet gezien worden als een architectuuroplossing. Saas staat meer voor een concept voor de manier waarop omgegaan wordt met software. De afkorting staat voor ‘Software as a service’. De periode waarin veel geld betaald werd voor de eenmalige aanschaf van software lijkt zijn langste tijd gehad te hebben. Gebruikers geven steeds meer aan dat ze gebruik willen maken van software in de vorm van een dienst. Nieuwe software moet eenvoudig en met een lage drempel te starten zijn, het moet er vervolgens zijn als je het nodig hebt, en als je bepaalde software niet langer wenst te gebruiken, moet je daar zonder al te veel problemen afscheid van kunnen nemen. Het Saas concept voorziet hierin: software wordt beschikbaar gesteld en moet gezien worden als een service, een vorm van dienstverlening. De dienstverlener kan in dit geval een ISV (Independent Software Vendor) zijn, maar ook een ISP (Internet Service Provider), of eigenlijk iedere andere organisatie. Kenmerkend is dat de klant zelf geen installatie hoeft uit te voeren op eigen systemen.

Een logisch gevolg van deze benadering is dat er over het algemeen geen aanschafkosten in rekening gebracht worden. De applicatie wordt immers geen bezit van een eindgebruiker. De eindgebruiker maakt gebruik van een reeds functionerende omgeving en betaalt daarvoor een periodieke vergoeding. Dat heeft verschillende voordelen: zou blijken dat een software toepassing niet bevalt, dan kan men daar zonder desinvestering afscheid van nemen. Er is immers geen investering gedaan bij het in gebruik nemen ervan. Sommige leveranciers rekenen wel eenmalige setup kosten, maar dat moet dan meer gezien worden als vergoeding in de kosten die gemaakt worden om een account aan te maken en wellicht additionele zaken zoals veiligheidscertificaten.

Een ander voordeel van het achterwege blijven van een eenmalige investering is dat de drempel sterk verlaagd wordt. We hebben de economisch moeilijke jaren inmiddels weer enigszins achter de rug, maar in het MKB was de mogelijkheid en/of bereidwilligheid tot het doen van investeringen minimaal. Voor een maandelijkse bijdrage hoeft echter geen investering gedaan te worden; zelfs bij (al dan niet tijdelijk) slecht lopende ondernemingen kunnen dergelijke onkosten uit de cashflow worden voldaan.

Behalve het financiële aspect bestaat ook de wens dat software meer geïntegreerd gaat worden in bedrijfsprocessen. Afgesloten software die uitsluitend benaderbaar is via de (mee)geleverde GUI laat zich vaak amper of niet inpassen in bestaande bedrijfsprocessen. De gegevens zijn van buitenaf niet benaderbaar. Er wordt wel steeds meer gebruik gemaakt van standaard databases, zodat de gegevens via OLEDB of ODBC opgevraagd kunnen worden. Maar het muteren van gegevens via diezelfde route wordt onmogelijk gemaakt of sterk afgeraden, omdat de business laag van de betreffende applicatie volledig gepasseerd wordt. Het risico bestaat dat de applicatie problemen zou kunnen geven, omdat zich ongeldige informatie in de database bevindt.

Als je een applicatie wenst te positioneren als service-applicatie in een groter geheel, dan is het gevolg daarvan dat de applicatiegegevens buiten de GUI om benaderd moeten kunnen worden, zowel voor lezen als voor schrijven. Dat maakt een eind aan de zo gehate ‘eilandautomatisering’.

Service fee

De maandelijkse vergoeding voor het gebruik van software wordt in dit verband een service fee genoemd. Er zijn een aantal kenmerkende verschillen tussen de service fee en de traditionele onderhoudskosten die voor een applicatie betaald worden/werden:

Vooral support is een opvallend item in dit overzicht. Als onderdeel van de onderhoudsbijdrage wordt meestal support geleverd, omdat gebruikers de software op eigen systemen installeren en gebruiken. Daarbij ontstaan nogal eens vragen die niet van toepassing geweest zouden zijn als de softwareleverancier de applicatie in eigen beheer zou hebben. Denk aan de installatie van de software, de uitrol van updates en het dagelijks gebruik met alle mogelijke problemen.

Als onderdeel van de service fee wordt support meestal uitgesloten, of gereduceerd tot e-mail support. De reden hiervoor is begrijpelijk: een belangrijk onderdeel van het concept van Saas is dat de gebruiker betaalt voor het gebruik. Wij signaleren de tendens dat de gebruikers die kiezen voor Saas over het algemeen goed bekend zijn met de voordelen en het gebruik van Internet. Dit type ondernemer is zelfstandig en redt zichzelf over het algemeen uitstekend met een applicatie, mits er voldoende helpinformatie beschikbaar is. Aangezien de service fee een doorlopend terugkerende bijdrage is, wordt deze door de service provider bewust zo laag mogelijk aangeboden, uiteraard rekening houdend met marktomstandigheden.

Telefonische support is een grote kostenpost en kan in veel gevallen slechts worden verkregen wanneer de gebruiker daar een extra bijdrage voor betaalt. In dat geval betaalt de gebruiker voor het gebruik van deze extra dienst.

Uit het overzicht blijkt verder dat de service fee ook een component bevat voor de levering en het onderhoud van de infrastructuur, inclusief het maken van de backups. De service provider gaat dus opeens ook verantwoordelijk worden voor een deel van de continuïteit van de bedrijven van de aangesloten gebruikers.

Een lastig onderdeel van de service fee is het bepalen van de hoogte ervan. Het is bijzonder moeilijk om het maximum aantal gebruikers per server te berekenen, terwijl bij een scherpe prijsstelling de hoeveelheid benodigde hardware een belangrijk onderdeel vormt van die prijs.

Gebruikers sluiten een contract af waarbij ze in theorie tot in lente van jaren een vaste fee betalen. Behalve de jaarlijkse prijsindexering kan die fee niet aanvullend worden verhoogd. Gebruikers zouden nooit akkoord gaan met het in gebruik nemen van bedrijfskritische software waarvan de prijs in de toekomst onbepaald is. De prijs die geldt op moment van aangaan van een service level agreement is de prijs die een gebruiker gedurende lange tijd zal blijven betalen. Mocht de overeengekomen prijs zich bij nader inzien onder de kostprijs bevinden, dan kunnen de financiële gevolgen daarvan tot in lengte van jaren zichtbaar blijven. Wordt de service fee te hoog vastgesteld, dan is deze niet concurrerend, met alle gevolgen vandien.

Omzetderving

Veel softwarebedrijven vragen een onderhoudsbijdrage variërend tussen 15 en 20% van de aanschafwaarde van de software. Door de introductie van Saas valt de aanschafwaarde echter weg, een voor softwareleveranciers zeer belangrijk onderdeel! Daar komt de service fee voor terug, waar bovendien ook de hosting infrastructuur in meegenomen moet worden. De service fee zal derhalve behoorlijk hoger liggen dan de onderhoudsbijdrage die in het verleden berekend werd. Daar komt dan nog bij dat de service provider (vaak de softwareleverancier zelf) ook nog een flinke investering moet doen in het aanbieden van een betrouwbare infrastructuur.

In feite kannibaliseer je als softwareproducent je eigen inkomsten

Door het aanbieden van Saas gaat de liquiditeit van een softwareleverancier een heel ander beeld geven. Op lange termijn is het zonder meer gunstig om regelmatige terugkerende fees te ontvangen, maar op korte termijn is het een grote investering. Wil je het goed doen, dan moet er een nieuwe applicatie worden ontwikkeld, gebaseerd op de gedachten achter Saas. Die investering is al aanzienlijk, en wanneer vervolgens de verkoop (verhuur) start, komen de inkomsten verhoudingsgewijs slechts langzaam op gang. In feite kannibaliseer je als software producent je eigen inkomsten. Maar hier geldt wat ons betreft het credo ‘regeren is vooruitzien’. Er vindt een onomkeerbare wending in de softwareindustrie plaats als gevolg van de wens om tegen lagere kosten gebruik te kunnen maken van software. De vraag is of je mee doet aan deze slag, of achterblijft. Wij hebben gekozen om daarin voorop te gaan lopen.

Escrow

Veel gebruikers kijken nu nog erg huiverig aan tegen het plaatsen van data buiten hun eigen kantoor, deels gevoelsmatig, deels vanwege valide continuïteitsredenen. Bij de gevoelsmatige kant spelen argumenten mee zoals het feit dat men een server liever fysiek in de hoek van het eigen kantoor ziet staan. Dat voelt veiliger dan dat een server zich bevindt in een goed beveiligd datacentrum als bijvoorbeeld RedBus. Daar zit 24 uur per dag een medewerker die de beveiliging voor zijn rekening neemt, is het pand voorzien van brandbeveiliging, is de toegang tot alle ruimtes elektronisch geregeld, etc. Om nog maar niet te spreken over de inbreker die de server uit het kantoor eenvoudigweg losknipt en meeneemt.

Het gevoelsmatige argument is een kwestie van tijd. Wellicht is je software en kostbare data in betere handen als dat uitbesteed wordt dan wanneer het op een eigen kantoor blijft. Backups maken? Uiteraard, maar ik ken teveel klanten waarbij alle tapes op de server zelf liggen, waar al 3 weken een lampje op de streamer knippert en niemand naar om kijkt, waar men na een jaar ontdekt dat het wisselen van de tape een zinloze bezigheid was omdat de backup job niet meer functioneerde.

We hebben dezelfde koudwatervrees gezien met het inbellen naar banken voor telebankieren. Later is dat overgegaan naar online telebankieren en inmiddels zijn de eerste bedrijven gestart met online boekhouden. Ook andere software zal online beschikbaar komen en bedrijven zullen gaan wennen aan de gedachte dat software meer als een service gezien moet worden, met alle bijbehorende positieve gevolgen vandien.

Het andere argument dat gebruikers weerhoudt om hun software en data buiten hun eigen kantoor te plaatsen, heeft te maken met de continuïteit van de service provider. Na het instorten van de Internet hype eind jaren 90 gingen vele softwarebedrijven failliet. Als een service provider failliet gaat met jouw kostbare data, dan kan dat rampzalig zijn voor de continuïteit van de eigen onderneming. Er zijn constructies denkbaar dat de data op regelmatige basis opgestuurd wordt, maar als je als bedrijf gekozen hebt voor een specifieke applicatie die aansluit bij jouw bedrijfsproces, dan zit je niet te wachten op een ZIP bestand met ‘uw bedrijfsgegevens’. Het bedrijfsproces moet verder kunnen gaan, en dat gaat niet zonder geschikte software.

Een mogelijke oplossing is het aangaan van een escrow-contract met klanten. In een traditioneel escrow-contract werden vooral afspraken gemaakt over de overdracht van sources in geval van een faillissement. In een Saas omgeving is een uitbreiding op het escrow-contract het aangaan van een stichting ‘continuiteit’. Deze stichting krijgt de opdracht tot het beheer van de infrastructuur en krijgt voor een vaste periode de bijbehorende gelden vooruitbetaald. De stichting staat los van de softwareonderneming zelf en zal dus in geval van faillissement blijven bestaan en voldoende middelen in kas hebben om de infrastructuur gedurende een contractueel aantal maanden in stand te doen houden. In de stichting neemt een afvaardiging van het gebruikersplatform zitting om toe te zien op het correct verlopen van ontvangst van de benodigde gelden. Wanneer er geen gebruikersplatform bestaat, of er kan niemand van de gebruikers bereid gevonden worden om deze taak op zich te nemen, dan kan bijvoorbeeld een notaris of accountant gevraagd worden deze functie te vervullen. Ook een aantal bedrijven dat zich bezig houdt met escrow-contracten wil deze rol graag op zich nemen.

Nieuwbouw

Het is al even gemeld in dit artikel: wil je meedoen aan Saas, dan zul je in veel gevallen de software volledig moeten herschrijven. Er zijn verschillende softwareproducenten die nu snel mee willen doen aan de Saas ‘hype’. Zij breken hun software open door een aantal ingangen te bouwen in de businesslaag en stellen dan dat ze ‘Saas-compliant’ zijn. Nog afgezien van het feit dat Saas meer betekent dan een opengebroken applicatie, is dit natuurlijk niet de manier. Op de invulling rond Saas kom ik straks nog terug, ik ga nu alleen even in op het technische aspect met betrekking tot openheid.

Het maken van een aantal ingangen in de software moet eigenlijk gevolgd worden door het als softwareleverancier gebruiken van die ingangen voor de productie van de user interface. Alleen op die manier weet je zeker dat de ingangen correct werken, omdat ze immers gebruikt worden voor de eigen GUI. Ideaal is dat de GUI uitsluitend gebruik maakt van deze openheid, en niet zelf via ‘achterdeurtjes’ direct communiceert met de business laag en/of database. Je kan dan met recht stellen dat alles wat een gebruiker ziet in de geleverde GUI ook zelf te bouwen is.  Alle functionaliteit van de GUI maakt dan immers gebruik van de open interface.

De conclusie die ik hier zou willen trekken is dat men (technisch gezien) in de meeste gevallen slechts door nieuwbouw serieus mee kan gaan doen aan Saas. Een applicatie kan dan vanaf de grond af aan worden gebouwd met een duidelijke scheiding tussen de service-applicatie die volledig open is, gevolgd door een separate GUI. Die GUI zou vervolgens net zo goed Win32 als web kunnen zijn, dat is een keuze die in mindere mate met techniek te maken heeft maar meer met klantbeleving.

NedFox is begin 2005 gestart met de ontwikkeling van RetailVista en Retail3000. Retail3000 is de service applicatie met een volledig open interface op basis van webservices. RetailVista is de GUI in de vorm van een website waar gebruikers zich kunnen registreren en daarna direct gebruik kunnen maken van alle functionaliteit van Retail3000. Beide applicaties zijn ontwikkeld in Visual Studio 2005 in de taal C#.

Na enig onderzoek is gebleken dat het aantal bedrijven dat software uitbrengt met een volledig open interface, nog niet bijzonder groot is. Dat moet deels te maken hebben met de hoge kosten waar een softwareleverancier mee geconfronteerd wordt als gevolg van volledige nieuwbouw. Twinfield is hierin een positieve uitzondering. Twinfield is al een flink aantal jaren actief met een financiële administratie, en dat systeem is ook benaderbaar middels webservices. Dat geeft de mogelijkheid om Twinfield op te nemen voor het financiële gedeelte in een grotere totaalomgeving.

Saas is echter veel meer dan uitsluitend een technische oplossing

Saas is echter veel meer dan uitsluitend een technische oplossing. Een service-applicatie met webservices maakt nog steeds geen Saas.

Organisatorische veranderingen

De invoering van RetailVista resulteerde in een andere manier van werken op diverse gebieden in de organisatie. Het is goed je vooraf te realiseren dat Saas diep ingrijpt op de organisatie, en wel om verschillende redenen.

Commercieel

Commercieel wordt van klanten voor deze applicatie meer zelfredzaamheid verwacht. Waar je voorheen nog wel eens naar een klant toe kon rijden voor een bespreking, moet een klant in dit geval zijn informatie van de website verkrijgen en zelf een account en licenties aanmaken door zich te registreren.

Productontwikkeling

Op de afdeling productontwikkeling is de kwaliteitscontrole op een veel hoger niveau komen te liggen. Waar je voorheen een release naar een selecte groep van klanten kon uitrollen, gaat een versie in dit geval live voor een heel grote groep van gebruikers tegelijkertijd. Onopgemerkte bugs die dan aanwezig blijken te zijn als gevolg van niet zorgvuldig ontwikkelen en testen, resulteren dan in grote druk op de supportafdeling. Bovendien kosten dergelijke storingen je binnen de kortste keren je goede naam. Als eindcontrole wordt een RetailVista omgeving permanent intern gecontroleerd op fouten (deze worden afgevangen en verstuurd naar een centrale exception repository). De externe controle van RetailVista en haar infrastructuur vindt plaats door een combinatie van hardware en software monitoring.

De kassasystemen die in het land staan, hebben permanent verbinding met Retail3000. Deze kassasystemen moeten automatisch worden voorzien van nieuwe softwareversies bij een update van de Retail3000 omgeving. Het verloop van dergelijke updates loopt via een versiebeheersysteem waarin groepen van klanten kunnen worden gedefinieerd waarbij per groep de laatst beschikbare versie kan worden aangegeven. Uiteindelijk melden alle kassa’s update-notificaties terug dat een bepaalde update succesvol geïnstalleerd is. Centraal is derhalve bekend welke versies bij welke klanten actief zijn gedurende welke periode.

Financiële - & licentieadministratie

De financiële administratie kon tot voorheen toe met het factureren op jaarbasis van de onderhoudsbijdragen. RetailVista kent een concept waarbij een gebruiker elke maand kan opzeggen. Het gevolg hiervan is dat er elke maand gefactureerd wordt. De bedragen zijn echter dermate klein dat het sturen van een factuur en eventuele herinneringen te duur is. Er moest worden overgestapt naar facturatie per e-mail en een bijbehorende incasso-opdracht. De terugkoppeling van ontvangen bijdragen (en eventuele storneringen als gevolg van mislukte incasso’s) moest worden doorgezet naar de licentieadministratie van RetailVista. Voor klanten die over een te lange periode de service fee niet voldoen, worden automatisch administratieve maatregelen genomen.

RetailVista wordt in sommige situaties gehost bij service providers. Alle licenties van een extern gehost systeem moeten echter wel elke maand automatisch worden verlengd. Tevens mag een gebruiker er weinig tot niets van merken dat een licentie elke maand stilzwijgend verlengd wordt. Dit hield in dat de licentieadministratie bij NedFox ook deels open gemaakt moest worden, zodat RetailVista systemen zelf licentie-updates kunnen aanvragen.

Marktbenadering

Wil een dergelijke Saas-oplossing een succes worden, dan moeten er grote aantallen van verkocht worden. Op eigen kracht is dat mogelijk, maar dat heeft wel veel tijd nodig. Binnen NedFox is gekozen voor een dealernetwerk en value added resellers (VAR’s). De VAR’s zijn over het algemeen branchespecialisten en kunnen RetailVista naar eigen inzicht uitbreiden  met branchespecifieke functionaliteit. Tevens krijgen zij de mogelijkheid om hun klanten die gebruik maken van RetailVista, aangevuld met specifieke functionaliteit, zelf te factureren. NedFox factureert in dat geval de VAR, de VAR bepaalt zelf de opslag en factureert haar eigen klanten.

Supportdesk

De supportdesk krijgt met de introductie van RetailVista te maken met een veel grotere verscheidenheid aan klanten, die al dan niet gebruik maken van de optionele mogelijkheid tot telefonische support. Die klanten moeten in staat zijn om zelfstandig hun problemen op te lossen. Dat houdt in dat de aanwezige knowledgebase beschikbaar moet worden gesteld op Internet. Ook het niveau van de vragen verandert: waar voorheen uitsluitend een GUI bestond, ontstaan nu ook meer technisch inhoudelijke vragen over het gebruik van bijvoorbeeld webservices. Aangezien de standaard support uitsluitend per mail verleend wordt, moesten klanten in staat gesteld worden om supporttickets aan te maken via een website en moest de communicatie via e-mail toch via een centraal supportsysteem geregeld worden.

Systeembeheer

De afdeling systeembeheer, die zich voorheen uitsluitend bezig hield met de interne automatisering en in sommige gevallen incidenteel beheer bij klanten, moet nu op een professionele manier de infrastructuur van de Saas-applicatie gaan verzorgen. Dat begint bij een correcte installatie van het geheel, maar een veel belangrijker deel ligt in structureel georganiseerd onderhoud. Dat onderhoud valt te splitsen in preventief en reactief onderhoud. De gehele infrastructuur moet doorlopend elektronisch worden gemonitord en preventief worden beheerd. Veel problemen zijn te voorspellen door te letten op signalen uit de monitoring. Denk aan het simpelweg vollopen van harddisks of warnings in het eventlog die naar verloop van tijd overgaan in serieuze error-meldingen.

Het reactieve deel is een situatie die zoveel mogelijk voorkomen moet worden, maar op moment dat zich een acuut probleem voordoet, moet bijzonder snel een analyse gemaakt kunnen worden van de oorzaak van de storing en vervolgens het verhelpen ervan. Door systemen volledig redundant uit te voeren kan in een aantal situaties de druk weggenomen worden door gebruikers te redigeren naar een backup-colocatie. Dit alles vergt echter een heel andere benadering en een ander kennisniveau dan wat tot dusver benodigd was.

eServices, eSocrates

Alle organisatorische veranderingen zoals hierboven beschreven hebben geresulteerd in de bouw van eServices als service laag voor de backoffice-administratie rondom Saas-applicaties (in dit geval RetailVista). Ook delen van Retail3000, de service-laag van RetailVista, worden intern gebruikt voor de eigen administratie, waaronder de facturering en relatiebeheer.

Van de eServices laag en Retail3000 wordt intern gebruik gemaakt door een Win32 smartclient eSocrates (gebaseerd op ClickOnce technologie). eSocrates is zuiver maatwerk, afgestemd op de interne werkwijze van NedFox. Een medewerker bij NedFox kent slechts 1 applicatie, terwijl er in de achterkant van eSocrates wordt gewerkt in eServices, Retail3000 en straks ook in Twinfield.

Van buitenaf wordt van de eServices laag gebruik gemaakt door verschillende systemen waaronder RetailVista zelf en de support-website van NedFox. De website is gebaseerd op DotNetNuke en derhalve modulair. Hierin is een aantal modules ontwikkeld waar klanten gebruik van kunnen maken voor supporttickets, licentiemutaties, een kennisbank, enz. eServices is intern gekoppeld aan de telefooncentrale, zodat bij telefonische oproepen geregistreerd wordt welke klant belt. Wanneer een klant herkend wordt, dan worden direct de relevante gegevens van die klant getoond.

De komende tijd zal nog worden geregeld dat eServices gekoppeld wordt aan Twinfield, zodat delen van de financiële administratie beschikbaar zijn in eSocrates. Dat is vooral handig bij de afwikkeling van de incasso-administratie.

De manier waarop eSocrates wordt toegepast is in onze ogen een schoolvoorbeeld van de voordelen van Saas-gebaseerde oplossingen. Het gaat hier dus niet per definitie om eSocrates, maar om een praktijkcase wat de voordelen voor een organisatie zijn door alle software beschikbaar te hebben in de vorm van Saas.

Samenvatting

In dit artikel zijn de belangrijkste onderdelen geschetst waar je als software leverancier mee te maken zou kunnen krijgen bij de invoering van Saas. Het artikel heeft niet de intentie om alle details op te sommen, de bedoeling was inzage te geven in de belangrijkste veranderingsprocessen.

De in dit artikel genoemde aspecten als gevolg van de overstap op Saas als softwareproducent zijn geen blauwdruk. Bepaalde zaken hangen sterk af hoe de organisatie ingericht wordt. Systeembeheer kan bijvoorbeeld worden uitbesteed, maar ook in dat geval krijg je te maken met afstemmingsproblemen waar je als leverancier voorheen nooit mee te maken had.

Wel hoop ik duidelijk gemaakt te hebben dat Saas  meer is dan uitsluitend een technologische oplossing. Om die reden is mijn inschatting dan ook dat Saas geen hype is, maar een blijvende ommekeer in de manier waarop met software omgegaan zal gaan worden. Dat de term ‘Saas’ binnen afzienbare tijd wel weer vervangen zal worden door een ander modewoord is te verwachten, maar de gedachte er achter houdt volgens mij veel langer stand.