Tag Archives: kosten besparing

Presentatie: Zarafa, van closed naar open

De onderstaande presentatie is gegeven als inleiding voor een workshop Zarafa. Hoewel de workshop “hands-on” was, is het belangrijk dat de deelnemers begrijpen wat nu precies de verschillen zijn tussen proprietary software en open source software. Deze presentatie gaat daarom in op de 5 wetmatigheden van de “digitale wereld”. Deze wetmatigheden zijn kort gezegd:

  1. Digitaal delen is vermenigvuldigen,
  2. Geen afnemend nut van kopieën,
  3. Kopiëren (of delen) tegen verwaarloosbare tijd en kosten,
  4. De economie van het delen en,
  5. Geen monopolie op de productiecapaciteit.

Daarnaast wordt ingegaan op de effecten hiervan op de muziek- en film industrie. Ook wordt uitgelegd wat het verschil is tussen producten maken, of diensten leveren en de gevolgen hiervan op de organisatie.

Deze presentatie is gehouden in september 2012, tijdens een Zarafa workshop die door Zarafa en Stone-IT is georganiseerd.

 

Business case: Zarafa vs. Microsoft Exchange

In de ict is het gebruikelijk om voor productkeuzes een business case op te stellen. Dit belicht de bedrijfsmatige en vaak financiële kant van de verschillende alternatieven. Zo kan een afgewogen en verstandige keuze gemaakt worden voor bijvoorbeeld een nieuwe applicatie.

In een business case worden zo veel mogelijk aspecten meegenomen die de kosten beïnvloeden. Hierbij kan gedacht worden aan kosten voor hardware, stroom, rackspace en licentiekosten. Ook minder voor de hand liggende aspecten zoals kosten voor implementatie, migratie en beheer moeten in de berekening worden meegenomen. Deze berekening wordt total cost of ownership (tco) genoemd. In de tco zitten alle kosten die het gebruik van een toepassing met zich meebrengt.

Veel organisaties willen financieel profiteren van de mogelijkheden die open source software hen biedt. Een van de mogelijkheden is Microsoft Exchange te vervangen door Zarafa Collaboration Platform. Beiden betreffen mail/groupware-software en kunnen naadloos met Microsoft Outlook werken. De vraag die velen bezighoudt is natuurlijk: hoeveel kan er bespaard worden? Dit artikel beschrijft de business case van Zarafa versus Microsoft Exchange. Voor beide producten is een tco-berekening gemaakt waarbij (nagenoeg) alle denkbare kosten zijn meegenomen.

Soms is het erg lastig om een goede tco-berekening te maken. Op verschillende punten zijn applicaties niet vergelijkbaar, bijvoorbeeld omdat de licentiestructuur verschillend is. Bovendien zijn er altijd aspecten die je niet kan kwantificeren. Een voorbeeld hiervan zijn de kosten van incidenten. De eerste vraag die daarvoor beantwoord moet worden, is het gemiddeld aantal incidenten van een applicatie. Hoe is dat objectief vast te stellen? Hoe kan bovendien de schade die een organisatie oploopt door downtime vastgesteld worden? Dit wordt sterk beïnvloed door het belang van de applicatie voor de betreffende organisatie.

Voor de lastig te bepalen aspecten worden aannames gedaan. Alle aannames in deze tco-berekeningen zijn aangegeven. Hierdoor kan de lezer zelf bepalen wat de invloed is als deze aannames gewijzigd worden of komen te vervallen.

De business case

In deze case wordt een fictief bedrijf met vijfhonderd medewerkers gebruikt. Deze organisatie heeft noch kennis en ervaring met Exchange, noch met Zarafa. Men wil het zelf hosten op een enkele fysieke server. De overige aannames zijn:

– De tco-berekeningen zijn gemaakt over een periode van drie jaar en zes jaar.
– Voor de licentiekosten van Exchange is met opzet niet gekozen voor de Software Assurance, dit zou de licentiekosten voor Exchange substantieel hoger maken (50 tot 75 procent hoger). In de berekening van zes jaar worden in jaar vier de licenties nogmaals gekocht omdat er dan net als bij Zarafa niet alleen updates, maar ook upgrades beschikbaar zijn. Zo zijn de alternatieven beter vergelijkbaar.
– Vijfhonderd gebruikers kunnen op een enkele server draaien.
– Voor alle softwareproducten is een versie met support genomen.
– De kosten van incidenten en schade door downtime zijn buiten de tco-berekening gehouden omdat deze niet op voorhand zijn vast te stellen.
– De implementatiekosten voor Zarafa zijn inclusief een testmigratie en fixed price.
– In de tco-berekening is ervoor gekozen de licentiekosten en subscriptiekosten in een keer te voldoen (in plaat van over drie jaar af te schrijven). Dit zal de meest voorkomende situatie zijn.
– Speciale (branche)kortingen en surfcontracten zijn buiten beschouwing gelaten.
– De prijzen voor het Microsoft Exchange-alternatief zijn door een Microsoft-partner aangeleverd.
– Er is geen sprake van een voorkeur voor één van de alternatieven, functioneel acht ik beide producten gelijk.

In de tco-berekening zijn meegenomen:

– Hardware (stelpost voor beiden gelijk gehouden).
– Spare parts (stelpost voor beiden gelijk gehouden).
– Hardware support (stelpost voor beiden gelijk gehouden).
– Stroom (stelpost voor beiden gelijk gehouden).
– Rackspace (stelpost voor beiden gelijk gehouden).
– Licenties en/of subscripties.
– Implementatiekosten (installatie en inrichting).
– Ten behoeve van de berekening van migratiekosten wordt uitgegaan van een migratie van Exchange naar een nieuwe versie van Exchange of van Exchange naar Zarafa).
– Beheerkosten (in beide gevallen kan beheer in vier uur per maand uitgevoerd worden, echter vanwege een lager beheertarief in het Microsoft Exchange-alternatief, vallen de beheerkosten daar lager uit).
– Opleidingskosten (in beide gevallen is gekozen voor certificering van zowel operating systeem als de groupware software).

Natuurlijk kunnen in een specifieke situatie of organisatie de uitgangspunten verschillen. Deze business case is zo generiek mogelijk gehouden om de significante verschillen aan het licht te brengen.

Resultaten

Zarafa vs. Microsoft Exchange

Het eerste vergelijk is over een periode van drie jaar. In dit kostenoverzicht is te zien dat het Zarafa-alternatief goedkoper is over een periode van drie jaar. Ook is te zien dat in beide gevallen de meeste investeringen in het eerste jaar vallen. Dit heeft te maken met de aanschaf van hardware, licenties/subscripties, implementatie en migratiekosten. De subscripties van Zarafa geven recht op updates en upgrades. De licenties van Microsoft geven alleen recht op updates. In deze berekening zien we een besparing van ruim 28 procent in het voordeel van Zarafa.

Zarafa vs. Microsoft Exchange

 

 

In een grafiek is een en ander als volgt voor te stellen.

 

 

 

Zarafa vs. Microsoft Exchange

Het tweede vergelijk betreft een periode van zes jaar. In dit tweede vergelijk is het verschil tussen Microsoft Exchange en Zarafa groter geworden, zowel absoluut als procentueel. Ook hier geeft de Zarafa-subscriptie recht op zowel updates als upgrades. De gekozen licenties van Microsoft geven alleen recht op updates. Om toch een eerlijk vergelijk te maken worden daarom in jaar vier de Microsoft-licenties opnieuw gekocht zodat ook een upgrade kan worden uitgevoerd. Dit verklaart de extra kosten bij Exchange in jaar vier. Indien deze strategie niet wordt gevolgd, zou na zes of zeven jaar een break even-punt bereikt kunnen worden. De consequentie is dan dat dezelfde versie zes of zeven jaar te gebruiken is, zonder te (kunnen) upgraden. In deze berekening is de besparing van het Zarafa-alternatief ruim 36 procent.

Zarafa vs. Microsoft Exchange

 

 

In een grafiek is een en ander weer als volgt af te beelden.

 

 

 

Conclusies

De tco-berekening laat zien dat deze business case aantoont dat met Zarafa kosten kunnen worden bespaard in vergelijk met Microsoft Exchange (25 procent over drie jaar en 36 procent over zes jaar). Hoewel deze verschillen procentueel klein lijken, gaat het om ruim 24.000 euro over drie jaar en ruim 53.000 euro over zes jaar. Dit zijn bedragen waarmee zinvolle dingen te doen zijn, zoals betere apparatuur aanschaffen, extra support inkopen of opleidingen volgen.

Naast de bovenstaande conclusie zijn er enkele relevante kanttekeningen te maken:

– Los van de kosten van licenties en subscripties zijn er veel open source softwaretools te vinden die het operationeel houden van Zarafa kunnen vereenvoudigen en verbeteren. Bijvoorbeeld monitoring tools (zoals Nagios of OpenNMS), deployment tools (Cobbler, Coan) of ten aanzien van configuratiemanagement (Puppet).
– Als een organisatie per se gebruik wenst te maken van een van de alternatieven, dan is een financieel vergelijk zinloos. Een duidelijke voorkeur zal bepalend zijn voor de keuze.
– In de tco-berekening is uitgegaan van gelijke (fysieke) hardware. Microsoft Exchange-experts houden als ‘vuistregel’ een maximum van vijfhonderd gebruikers per fysieke server aan. Zarafa doet met IBM samen op dit moment onderzoek naar duizend gebruikers per fysieke server.
– Verwacht wordt dat de verschillen bij een multi-servers set-up (bijvoorbeeld wanneer er meer dan vijfhonderd gebruikers zijn of wanneer er maatregelen getroffen worden voor een hoge beschikbaarheid) groter worden in het voordeel van Zarafa.
– De Zarafa-subscripties geven recht op support van Zarafa zelf. Het aantal supportverzoeken is gekoppeld aan het aantal subscripties dat wordt afgenomen. Een dergelijke support is niet standaard bij Microsoft Exchange inbegrepen.
– De kwaliteit van de alternatieven (als in het aantal incidenten, gemiddelde incidentduur en bedrijfsschade als gevolg van downtime) zijn in deze tco-berekening, zoals gezegd, buiten beschouwing gelaten. Van deze gegevens was geen data beschikbaar. Uit mijn ervaringen van weet ik dat Zarafa ook op dat punt zeker niet achterblijft.

Een goed vergelijk op basis van een tco-berekening blijft erg moeilijk. Er zijn altijd wel verschillen te benoemen die aanleiding kunnen zijn tot een discussie. In deze business case is geprobeerd een zo zuiver mogelijk vergelijk te maken en de aannames te verwoorden. In antwoord op de vraag uit de inleiding kan gesteld worden dat er aanzienlijk bespaard kan worden door over te stappen van Microsoft Exchange naar Zarafa.

Dit artikel is verschenen op de site van Computable op 22-02-2011

De rekening wordt altijd gepresenteerd

Open source software wordt steeds beter geaccepteerd. Meer bestuurders, managers en andere niet-technische mensen komen er mee in aanraking en vormen er zich een mening over. Open source software lijkt daarmee ‘business as usual’ te worden. Dat is goed nieuws voor de softwareontwikkelaars van open source software en voor de bedrijven en eindgebruikers. Het is natuurlijk ook door de ict-industrie zelf geadopteerd en zij probeert dat in een bedrijfsmatig model te gieten om het te kunnen kapitaliseren.

Regelmatig ben ik bij discussies van bestuurders en managers die ervan overtuigd zijn dat open source software niet gratis is. Er wordt dan gesteld dat de kosten altijd ergens betaald worden. Ze refereren aan commerciële open source software waarvoor abonnementen of toch licenties gekocht moeten worden. Ook de ontwikkelaars van niet-commerciële open source software moeten toch kunnen leven. Aldus de redenering, de software wordt altijd betaald, linksom of rechtsom.

De bovenstaande redenering is correct. Inderdaad zijn er een groot aantal ict-leveranciers die commerciële open source software maken. Omdat het lastig is om aan de open source software zelf te verdienen worden oplossingen bedacht met de verkoop van diensten op de software zoals support, ‘community editions’ en ‘enterprise editions’ (de eerste is een ontwikkelversie en de laatste is de versie die je graag zou willen gebruiken en waarvoor licenties gekocht moeten worden). Ook de communityontwikkelaar moet inkomsten hebben ook al draagt hij bij aan een open source softwareproject. Daar worden veelal creatieve oplossingen voor bedacht. Soms vind een ontwikkelaar zijn werkgever bereid om te betalen voor de bijdrage. Meestal omdat deze werkgever weer commercieel gebruik kan maken van de software. Soms blijft het bij het gebruik maken van vrije tijd.

Ik begrijp de redenatie maar ben het er toch niet helemaal mee eens. Je hoeft namelijk als eindgebruiker niet te betalen voor de software. Je kunt genoegen nemen met de ‘community edition’, kiezen voor niet-commerciële open source software of afzien van de diensten die middels abonnementen verkocht worden. Wie er uiteindelijk voor betaald heeft is niet van belang, deze software wordt je gratis ter beschikking gesteld. Is dit zo moeilijk om te accepteren? Blijven we vasthouden aan het idee dat ‘goedkoop’ ‘duurkoop’ is en dat de software niet goed kan zijn omdat je er niet voor moet betalen? Uit ervaring weten we dat de kwaliteit vaak juist erg goed is, niet in de minste plaats vanwege het communityontwikkelmodel.

Total cost of ownership

Deze discussies gaan daarom al snel over de andere kosten die ict met zich meebrengen. Ineens komen bijvoorbeeld de hardware-, hosting-, implementatie- en supportkosten ter tafel. En hoewel de discussie startte over licentiekosten, gaat het inmiddels over de total cost of ownership. Dus, als ik een vergelijk mag maken, je krijgt een auto cadeau, maar bent vervolgens teleurgesteld als je zelf de benzine moet betalen.

Toch verbazen mij deze discussies. Niet dat ze niet gevoerd zouden mogen worden, maar omdat ze de suggestie wekken dat het allemaal niet zo mooi is als wordt voorgesteld. De indruk ontstaat dat er in een later stadium bij het gebruik van open source software ineens een onverwachte rekening gepresenteerd wordt. Dit is niet het geval. De kosten van open source software zijn dezelfde als die van closed source software (namelijk total cost of ownership), echter dan zonder licentiekosten. Als toch gebruik gemaakt wordt van commerciële open source software, dan betaalt men licentiekosten en dat is niet anders dan bij closed source software. Open source software laten mogelijk de licentiekosten vervallen, maar natuurlijk niet de total cost of ownership.

Het idee dat de software ‘linksom of rechtsom’ betaald wordt doet naar mijn idee afbreuk aan de motivatie waarmee open source softwareontwikkelaars hun software ter beschikking stellen. Deze communityontwikkelaars vragen geen geld voor hun software. Dit is niet omdat ze een liefdadigheidsinstelling zijn, ze hebben er belang bij. Er is namelijk een goede reden om hun software vrij te geven. De communityontwikkelaars begrijpen namelijk dat digitaal delen eigenlijk vermenigvuldigen is. Want als we een fysieke taart delen, krijgt iedereen een stukje, maar een ‘digitale taart’ delen geeft iedereen de volledige taart. Het belang is dan ook dat een kleine bijdrage leidt tot een enorme opbrengst voor iedereen, mits ook iedereen maar deelt. Dit zou je ‘de economie van het delen’ kunnen noemen. Bedrijven die dit doorzien kiezen voor open source software los van licentiekosten. Mij lijkt ‘de economie van het delen’ voor bedrijven een andere belangrijke reden om open source software te gaan gebruiken.

Meerwaarde

Discussies over licentiekosten en kostenbesparingen met open source software leiden naar mijn idee af van waar het eigenlijk om zou moeten gaan, namelijk de (overige) voordelen van open source software. Communitygebaseerd softwareontwikkelen is naar mijn idee de toekomst binnen de ict. De ‘economie van het delen’, open standaarden, het voorkomen van vendor lock-in en goede dienstverlening maken het aanbod compleet. Hoe lang wil je wachten voordat je de voordelen hiervan inziet en gaat benutten?

Toch blijf ik met een paar vragen zitten. Waarom is het zo moeilijk om te begrijpen dat software zonder licentiekosten toch van goede kwaliteit kan zijn? Hoe maak ik duidelijk welke andere voordelen open source software heeft? En hoe overtuig ik mensen hiervan? Dat blijkt toch lastiger dan ik in eerste instantie dacht. En waarom houden veel mensen vast aan het idee dat ‘goedkoop is duurkoop’ is, terwijl we dagelijks overspoeld worden met vergelijkend warenonderzoek dat aantoont dat de goedkoopste jam verreweg de lekkerste is. We zouden inmiddels toch kunnen weten dat de prijs niet altijd bepalend is voor de kwaliteit. Misschien moet de consumentenbond ook software gaan onderzoeken?

Dit artikel is verschenen op de site van Computable op 18-08-2010