SaaS, 2007 hype or (h)(n)ot?

SaaS, 2007 hype or (h)(n)ot?

SaaS, 2007 hype or (h)(n)ot? SaaS lijkt uit te groeien tot de hype van 2007. De meningen over een hype of een permanente andere beleving van software lopen nogal uit een. 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 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 wat de grootste problemen waren met de uitrol van dergelijke software. Ook is 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 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 bedrijfkritische 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 in dit verband het maar niet hebben over de niet-gevorderde gebruikers, die krijgen een dergelijke retail applicatie in het geheel niet geïnstalleerd. Samengevat is het aantal handelingen dat uitgevoerd moet worden vrij groot en zal je (tenzij je Microsoft heet) nooit grote aantallen gaan realiseren wanneer er op traditionele wijze wordt gedistribueerd. Potentiële gebruikers tonen op een zeker moment interesse, die interesse wordt echter heel snel gereduceerd wanneer de installatie te veel werk omvat.

SaaS Vóór 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 architectuur oplossing. SaaS staat meer voor een concept waarop omgegaan wordt met software. De afkorting staat voor ‘Software as a service’. De tijd waarin veel geld betaald werd voor de eenmalige aanschaf van software lijkt voorbij. Gebruikers geven 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 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 andere organisatie. Kenmerkend is dat de klant zelf geen installatie hoeft uit te voeren op eigen systemen. Een logisch gevolg is dat er 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.

1

Maart 2007 auteur: Mark Vroom, technisch directeur NedFox BV


Sommige leveranciers rekenen wel eenmalige setup kosten, maar dat moet gezien worden als vergoeding van de kosten om een account aan te maken en wellicht additionele zaken zoals veiligheidscertificaten. Een ander voordeel 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 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 zich meer gaat integreren 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 steeds meer gebruik gemaakt van standaard databases zodat de gegevens via OLEDB of ODBC opgevraagd kunnen worden. Maar het muteren van gegevens 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 een applicatie word gepositioneerd als service applicatie in een groter geheel, dan is het gevolg dat de applicatie gegevens buiten de GUI om benaderd moeten worden, zowel voor lezen als schrijven. Dat maakt een eind aan ‘eiland automatisering’.

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 in het verleden betaald werden:

Onderhoud aan software (updates) Maken van backups Leveren en onderhoud infrastructuur Support

Onderhoudsbijdrage Ja Nee Nee

Service fee Ja Ja Ja

Vaak wel

Vaak optioneel

Vooral de support is een opvallende in dit overzicht. Support is vaak een onderdeel van de onderhoudsbijdrage en is nodig omdat gebruikers de software op eigen systemen installeren en gebruiken. Er ontstaan nogal eens vragen die niet van toepassing zouden zijn als de software leverancier 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 met een applicatie, mits er voldoende help informatie 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 wordt meestal verleend als 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 back-ups. De service provider wordt dus ook verantwoordelijk voor de continuïteit van alle aangesloten gebruikers.

2



Een lastig onderdeel is het bepalen van de hoogte van de service fee. 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 jarenlang een vaste fee betalen. Alleen door de jaarlijkse prijsindexering kan die fee 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 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 van dien.

Omzet derving Veel softwarebedrijven vragen een onderhoudsbijdrage variërend tussen 15 en 20% van de aanschafwaarde van de software. Door introductie van SaaS valt de aanschafwaarde echter weg, een voor software leveranciers zeer belangrijk onderdeel! Daar komt de service fee voor terug, waarin ook de hosting infrastructuur moet worden berekend. De service fee zal derhalve behoorlijk hoger liggen dan de onderhoudsbijdrage die in het verleden berekend werd. Daar komt bij dat de service provider (vaak de software leverancier zelf) een flinke investering moet doen in het aanbieden van een betrouwbare infrastructuur. Door het aanbieden van SaaS gaat de liquiditeit van een software leverancier een heel ander beeld geven. Op lange termijn is het gunstig om regelmatig terugkerende fee’s te ontvangen, op korte termijn is dat 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 aanzienlijk, en wanneer 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 software industrie 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 voorop te lopen.

Escrow Veel gebruikers kijken 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 als 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, het pand voorzien van brandbeveiliging, de toegang tot alle ruimtes is elektronisch geregeld etc. Om maar niet te spreken over de inbreker die de server uit het kantoor 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 op een eigen kantoor. Back-ups 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 waar niemand naar om kijkt. En andere bedrijven waar men na een jaar ontdekt dat het wisselen van de tape een zinloze bezigheid was omdat de back-up 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 van dien.

3



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 software bedrijven failliet. Als een service provider failliet zou gaan met jouw kostbare data, dan kan dat rampzalig zijn voor de continuïteit van de onderneming. Er zijn constructies denkbaar dat de data op regelmatige basis opgestuurd wordt, maar als bedrijf gekozen heeft voor een specifieke applicatie die aansluit bij het bedrijfsproces, dan zit men 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 worden 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 ‘continuïteit’. Deze stichting krijgt de opdracht tot het beheer van de infrastructuur en krijgt voor een vaste periode de bijbehorende gelden vooruit betaald. De stichting staat los van de software onderneming 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 bedrijven die zich bezig houden met escrow contracten willen deze rol op zich nemen.

Nieuwbouw Het is al even gemeld in dit artikel: wil je meedoen aan SaaS, dan zal je in veel gevallen de software volledig moeten gaan herschrijven. Er zijn verschillende software producenten die nu snel mee willen doen aan de SaaS ‘hype’. Zij breken hun software open door een aantal ingangen te bouwen in de business laag en stellen dan dat ze ‘SaaS-compliant’ zijn. 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 verderop terug, ik ga nu 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 software leverancier 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, door niet zelf via ‘achterdeurtjes’ direct te communiceren 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 kan meedoen aan SaaS. Een applicatie kan 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 niet direct 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 direct gebruik kunnen maken van alle functionaliteiten van Retail3000. Beide applicaties zijn ontwikkeld in Visual Studio 2005 in de taal C#.

4



Na enig onderzoek is gebleken dat het aantal bedrijven wat software uitbrengt met een volledig open interface nog niet bijzonder groot is. Dat moet deels te maken hebben met de hoge kosten van volledige nieuwbouw. Twinfield is hierin een positieve uitzondering. Twinfield is al een 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. Een service applicatie met webservices maakt nog steeds geen SaaS.

Organisatorische veranderingen De invoering van RetailVista resulteerde in een andere manier van werken in de organisatie. Men zal zich moeten realiseren dat SaaS diep ingrijpt op de organisatie.

Commercieel Commercieel wordt van klanten meer zelfredzaamheid verwacht. Waar voorheen een bezoek aan de klant werd gebracht, 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 voorheen een release naar een selecte groep van klanten werd uitgerold, gaat een versie in dit geval live voor een heel grote groep van gebruikers tegelijkertijd. Onopgemerkte bugs die dan aanwezig zijn als gevolg van niet zorgvuldig ontwikkelen en testen, resulteren in een grote druk op de supportafdeling. Bovendien kosten dergelijke storingen 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 kassa systemen die in het land staan, hebben permanent verbinding met Retail3000. Deze kassa systemen moeten automatisch worden voorzien van nieuwe software versies bij een update van de Retail3000 omgeving. Het verloop van dergelijke updates loopt via een versie beheer systeem waarin groepen van klanten kunnen worden gedefinieerd en kan per groep de laatst beschikbare versie worden aangegeven. Uiteindelijk melden alle kassa’s update notificaties terug dat een bepaalde update succesvol geïnstalleerd is. Centraal is bekend welke versies bij welke klanten actief zijn gedurende welke periode.

5



Financiële & licentie administratie De financiële administratie kon tot nu toe op jaarbasis van onderhoudsbijdragen factureren. 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 licentie administratie van RetailVista. Voor klanten die over een te lange periode de service fee niet voldoen, worden automatisch maatregelen genomen. RetailVista wordt in sommige situaties gehost bij service providers. Alle licenties van een extern gehost systeem moeten 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 licentie administratie bij NedFox deels open gemaakt moest worden zodat RetailVista systemen zelf licentie updates kunnen aanvragen.

Marktbenadering Om van een dergelijke SaaS oplossing een succes maken, moeten grote aantallen verkocht gaan worden. Op eigen kracht is dat mogelijk, maar het heeft veel tijd nodig. NedFox heeft gekozen voor een dealer netwerk 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.

Supportafdeling De supportafdeling krijgt met de introductie van RetailVista te maken met een veel grotere verscheidenheid aan klanten, die al dan niet gebruik maken van de telefonische ondersteuning. 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 veranderd: 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 support tickets aan te maken via een website en moest de communicatie via e-mail via een centraal support systeem 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 veel belangrijker is het structureel georganiseerd onderhoud. Dat onderhoud valt uiteen 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 de 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 acuut een probleem voordoet moet bijzonder snel een analyse worden gemaakt 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 back-up co-locatie. Dit alles vergt een heel andere benadering en kennisniveau dan tot nu toe nodig was.

6



eServices, eSocrates Alle organisatorische veranderingen zoals hierboven beschreven hebben geresulteerd in de bouw van eServices als servicelaag, voor de backoffice administratie rondom SaaS applicaties (in dit geval RetailVista). Ook delen van Retail3000, de servicelaag van RetailVista, worden intern gebruikt voor de eigen administratie, waaronder de facturering en het relatiebeheer. Van de eServices-laag en Retail3000 wordt intern gebruik gemaakt door een Win32 smartcliënt 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 zijn een aantal modules ontwikkeld waar klanten gebruik van kunnen maken voor support tickets, licentie mutaties, een kennisbank, etcetera. eServices is intern gekoppeld aan de telefooncentrale, zodat bij telefonische oproepen geregistreerd wordt welke klant belt. Wanneer een klant herkend wordt, worden direct de relevante gegevens van die klant getoond. De komende tijd zal eServices gekoppeld worden 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 praktijk case, wat de voordelen voor een organisatie zijn door alle software beschikbaar te hebben in de vorm van SaaS.

7



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 is inzage te geven in de belangrijkste veranderingsprocessen. De genoemde aspecten als gevolg van de overstap op SaaS, als software producent, zijn geen blauwdruk. Bepaalde zaken hangen sterk af van hoe de organisatie wordt ingericht. 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. Ik hoop 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 worden. Dat de term ‘SaaS’ binnen afzienbare tijd wel weer vervangen zal worden door een ander modewoord is te verwachten. Maar de gedachte erachter houdt volgens mij veel langer stand.

Mark Vroom is technisch directeur NedFox B.V. en heeft daar het Retail3000 en RetailVista concept geïntroduceerd. Sinds begin 2007 is de eerste versie van RetailVista beschikbaar. NedFox is ISV en gespecialiseerd in de productie van retail software. Reacties op dit artikel kunnen per e-mail naar [email protected].

8


SaaS, 2007 hype or (h)(n)ot?

Recommend Documents