Een aantal highlights uit de presentatie:

Transcriptie

1 SaaS University Jan Aleman spreekt een paar keer per jaar op SaaS University in de Verenigde Staten, aldaar spreekt hij regelmatig over de status van SaaS en Cloud in Europa, Appworks vroeg hem om voor het Nederlandse publiek een verslag te maken van SaaS in de Verenigde Staten. SaaS University is een, voor amerikaanse begrippen, kleinschalige conferentie. Een beetje een mix tussen conferentie en training; in drie dagen tijd wordt vanuit verschillende disciplines met CEO's en CTO's van software bedrijven alle aspecten van SaaS en Cloud computing bestudeerd. Van marketing, techniek tot hoe compenseer ik mijn salesmensen komt aan bod in deze conferentie. Een van de keynote presentaties werd door organisator Rick Chapman gegeven en daar wil ik in dit artikel wat meer op inzoomen. Rick presenteerde de cijfers van een SaaS onderzoek onder softwarebedrijven binnen de VS. Het gaat hier om kleine tot middelgrote software bedrijven, feitelijk de groep waar de meeste software bedrijven toe horen. Dit zijn zowel software bedrijven die verticale als horizontale applicaties ontwikkelen, deze bedrijven worden over het algemeen ISV (Independent Software Vendor) genoemd. Voor de omvang van software bedrijven wordt de bruto jaaromzet als leiddraad aangehouden. 30% van de software bedrijven valt in de categorie micro ISV's. 36% van de ISV's vallen onder de groep klein en middelgroot. 20% van de bedrijven valt onder de grote ISV's (denk aan bedrijven als Accountview, Quadrant) en 14% onder de zeer grote (denk aan de omvang van Exact, Unit4)

2 Een aantal highlights uit de presentatie:

3 Veel SaaS bedrijven maken al winst, je zou gezien SaaS een relatief nieuwe ontwikkeling is verwachten dat veel bedrijven geen winst maken maar het tegendeel is waar. Dit wordt veroorzaakt doordat veel bedrijven een installed base hebben met on premises software en SaaS ontwikkeling er initieel bij doen. Grofweg kun je ISV's in de volgende categorieen indelen: - Innovators - Defensief - Terughoudend De innovators zijn de bedrijven die het eerst voor SaaS kiezen. Ze. Innovators die zich puur op SaaS richten hebben wel een grote up-front investering nodig: van idee to geld verdienen ben je gauw een paar miljoen euro verder. Daarom kiezen ISV's er vaak voor om de SaaS ontwikkeling parallel aan hun bestaande On Premises ontwikkeling te doen om zo met het een het ander te financieren. De defensieve ISV's doen aan SaaS om hun sales en marketing afdeling tevreden te stellen maar ze zien het eigenlijk niet zitten, danwel om het feit dat ze nog geen feeling hebben met SaaS danwel om het feit dat ze niet op de investering zitten te wachten. Vaak kiezen deze ISV's ervoor om hun bestaande applicatie via Remote Desktop achtige technologie te 'Saas enablen' (Ik noem dit zelf liever nep-saas) of kiezen ze ervoor om een kleine speler over te nemen en die als separate productlijn te voeren. Terughoudende ISV's hebben het boek 'The Innovators Dilemma' (aanbevolen) niet gelezen. Ze hebben aan een aantal van hun bestaande klanten gevraagd of die op SaaS zitten te wachten: het antwoord is te verwachten, een bestaande, tevreden, klant zit meestal uberhaupt

4 niet op change te wachten. Het resultaat bij de terughoudende isv is vaak dat men te laat pas op SaaS overstapt. Concreet: als je als ISV SaaS overweegt is nu het moment om aan de slag te gaan, als je dit uit bestaande cash-flow kan financieren is dat zeer aan te bevelen. Bedrijven die SaaS producten voeren groeien fors beter dan andere software bedrijven. Sterker nog in 2009 was er vrijwel geen groei bij klassieke software bedrijven terwijl 69% van de ondervraagde bedrijven groeide! Een aantal analisten meldden inmiddels dan 70% van alle nieuw verkochtte software als SaaS gekocht wordt, de gehele installed base is nog onder de 30% maar inkomsten groei komt toch meestal uit de eerste markt en niet uit je bestaande markt. Als je als ISV serieus wilt groeien zul je een SaaS offering moeten toevoegen aan je portfolio.

5 Je zou verwachten dat de meeste bedrijven hun product per named user (zeg maar login) pricen, zoals dat ook bij bv gebeurt. Toch is dat maar in minder dan de helft van de gevallen zo. Concurrent based pricing is heel populair ook al is dat meer een vorm die toegepast wordt bij on premises software. Ook zie je een stijging in transactie gebaseerd prijzen. Bij het vaststellen van pricing modellen wordt vaak gekeken wat klanten al gewend zijn om te betalen aan software behalve als er al een concurrent in de markt is met een gelijkwaardige oplossing. Zo zie je bv dat veel crm leveranciers duidelijk naar het pricing model van SalesForce.com hebben gekeken en daar hun pricing op baseren. Het pricen op transacties is met name interessant als je bij je klanten een sterke groei verwacht in transacties en niet zo zeer in gebruikers. Bv in de UK is er een bedrijf in de gezondheidszorg dat 1 euro per patientdossier per maand rekent. De eerste maanden van gebruik verdienen ze geen geld op dit model maar zodra het systeem eenmaal goed draait en op stoom begint te komen is er een duidelijk hockeystick effect op de bruto-marge zichtbaar.

6 De meeste klanten kopen SaaS omdat de enige manier is waarop ze die software kunnen krijgen, een vrij verrassend resultaat. Je zou eerder denken dat het om pricing gaat of initiele investering (Capital expenditure [CAPEX] vs Operational Expenditure [OPEX]) maar uit deze resutaten blijkt dat klanten toch primair voor functionaliteit kiezen en pas secundair naar kosten en complexiteit kijken. Dit bevestigd maar weer dat functionaliteit en unieke eigenschappen van een software applicatie erg belangrijk zijn en blijven.

7 De meeste applicaties zijn multi-tenant dwz de data en applicatie wordt tussen verschillende huurders (tenants) gedeeld. Hierbij moet de applicatieserver ervoor zorgen dat de gebruiker alleen zijn eigen data en niet die van een andere klant te zien krijgt. Voordelen hiervan zijn betere schaalbaarheid en lagere hard en software kosten voor de leverancier. Een nadeel van multi-tenancy is dat in veel ontwikkelomgevingen (maar er zijn gelukkig al een aantal ontwikkel en deployment tools die multi-tenancy out of the box ondersteunen) deze functionaliteit niet ingebouwd zit, vaak zit het probleem zelfs al op de data-laag en is het datamodel niet voorzien van owner id's op de primaire tabellen. Het zelf programmeren van multi-tenancy features kan ook sneller tot fouten leiden: je hoeft maar 1 query te schrijven die vergeet de owner id mee te nemen en je gaat al de boot in. Dit moet tevens ook weer op de reporting laag ingebouwd worden. De niet multi-tenant applicaties zijn vaak 'ouderwetse' applicaties die met remote-video technologie (Citrix/Terminal Services) aan de klant beschikbaar worden gesteld. Hierbij zijn schaalbaarheid en kosten vaak een handicap. Men onderschat vaak de kosten van het deployen via remote-video technologie. Hieronder een real-life voorbeeld van een bedrijf die van een FoxPro omgeving die gedeployed werd via Microsoft Remote Desktop overgestapt is naar Servoy: Omgeving FoxPro/Remote Desktop Servoy Aantal gebruikers

8 Licentiekosten Windows Server Licentiekosten 5 per server 5 /maand/user (remote desktop licentiekosten) Aantal servers nodig Hosting kosten server 90 /maand 90 Totale kosten per jaar /maand/user (Servoy licentiekosten) Bovenstaande tabel kijkt alleen maar naar de licentie en hosting kosten. De daadwerkelijke besparing zijn nog een factor groter omdat er 70% minder personeelkosten zijn en de hardware kosten met 90% teruggebracht worden. Concreet remote-video oplossing zijn vrijwel altijd 2 tot 10 maal duurder dan echte multi-tenant applicaties. Dit is wel redelijk schokkend. Het leeuwendeel van de SaaS providers voorziet niet in failover, kortom als hun server uitvalt is de dienst onbereikbaar. Zeker als er voor de hosting gebruik gemaakt wordt van Cloud computing is er geen excuus om geen goede failover faciliteit te bieden. Failover kun je op een aantal manieren oplossen in je applicatie: Real-time failover

9 Bij realt-time failover gebruik je clustering om meerdere servers tot een logische server te groeperen. Bij bedrijfs applicaties is het met name van belang dat dit op database nivo gebeurt. Op applicatieserver nivo heeft dit ook toegevoegde waarde: de gebruiker kan dan vrijwel realtime doorwerken. Als je dit echt goed wilt doen moet je je cluster ook geografisch verdelen door meerdere servers op meerdere locaties te hebben, dit heeft bij het gebruik van transactionele databases wel wat haken en ogen doordat vrijwel alle transactionele databases voor clustering gebruik maken van shared-disk technologie die zeer grote bandbreedte en lage latency tussen de server en het opslagsysteem vereisen. Stand-by failover Bij stand-by failover is er een stand-by server die pas inspringt op het moment dat de primaire server het begeeft. De kosten en de complexiteit zijn een stuk lager maar de downtime tussen het switchen van de server is vaak hoger. Vaak is dit toch wel onder de paar minuten te houden en voor veel bedrijfs applicaties nog wel acceptabel. Manual failover In dit geval wordt er bij het uitvallen van een premaire server een secudaire handmatig ingezet. De kosten en complexiteit zijn hier nog lager maar de kans op fouten veel groter en de downtime meestal ook. Analytics tracking Steeds meer software paketten integreren het meten van het gebruik van de applicatie in de software zelf.

10 Maar iets minder dan de helft van de bedrijven tracked het gebruik van hun applicatie. Terwijl het niet erg moeilijk te integreren is (zeker niet voor browser gebaseerde SaaS oplossingen) en veel belangrijke data op kan leveren. Niet alleen over hoe actief gebruikers zijn maar ook hoe ze de applicatie gebruiken. Nog maar 22% van de huidige SaaS bedrijven werkt actief aan een community (zeg maar wat je vroeger gebruikersvereniging zou noemen) om zijn product. Een community kan een belangrijke hulp voor marketing zijn maar ook potentieel goede input leveren voor je Product Management om te bepalen welke features geimplementeerd, uitgebreid of verbeterd moeten worden aan je product.

11 Bij veel SaaS producten denkt men primair aan afrekenen per maand maar in de praktijk blijkt dat jaarlijks afrekenen het meest gebruikt wordt. Zelfs 14% van de klanten heeft meerjarige contracten voor de dienst. Dit kan voor beide partijen interessant zijn: de klant vergewist zich van een vaste prijs (geen onverwachtse prijsstijgingen!) en de leverancier heeft een cash-flow voordeel. OPROEP Dit onderzoek zal binnenkort ook in Europa gehouden worden. Om zoveel mogelijk bedrijven te benchmarken is het belangrijk dat zoveel mogelijk software bedrijven meedoen. Bedrijven die meedoen krijgen toegang tot een overzicht van de resultaten uit het onderzoek. Meedoen kan hier: Zodra de resultaten bekend zijn zullen we hier een artikel over publiceren, tevens kunnen we dan Europa vs de USA gaan benchmarken om te kijken wat zoal de verschillen en overeenkomsten tussen de markten zijn.