Servicemanagementapplicaties in het SaaS-concept

Uitvoering van IT-diensten Servicemanagementapplicaties in het SaaS-concept

4.7

Servicemanagementapplicaties in het SaaS-concept

263

e toepassing van het concept Software as a Service (SaaS) voor servicemanagementapplicaties biedt interessante voordelen voor kleine (MKB) en grote gebruikersorganisaties. Ron Bovee, Sander Visser en Kaspar Bosgoed beschrijven praktijktoepassingen van Saas en bespreken de vooren nadelen in vergelijking met de klassieke oplossing.

D

INLEIDING Software as a Service, afgekort als SaaS, is een vervolgstap op de trend van de Application Service Providers ofwel ASP. Steeds meer applicaties worden als dienst aangeboden aan gebruikersorganisaties, zodat de software op een kostenefficiënte en eenvoudige manier snel beschikbaar is. Niet alleen kantoorautomatiseringapplicaties, maar steeds meer enterprise-applicaties worden op deze manier aangeboden. Het SaaS-concept biedt specifieke voordelen bij organisatieoverschrijdende servicemanagementprocessen. Bijvoorbeeld het eenvoudig ondersteunen van de communicatie tussen de IT-afdeling en outsourcingpartners. Dit is de reden dat steeds meer servicemanagementapplicaties die de ITIL-werkprocessen van onder andere IT-organisaties ondersteunen in dit concept worden aangeboden. Wat zijn nu de vooren nadelen van SaaS-servicemanagementapplicaties voor een IT-organisatie? Welke consequenties heeft dit voor een IT-organisatie? Welke bredere toepasbaarheid heeft het SaaS concept voor de ITIL-procesondersteuning? Dit artikel geeft, vanuit het belang van de gebruikersorganisatie, antwoord op deze vragen.

WAT IS SAAS ? Definitie van SaaS Software as a Service wordt door Gartner als volgt omschreven:

“SaaS is software that is owned, delivered and managed remotely by one or more providers. The provider delivers an application based on a single set of common code and data definitions, which are consumed in a one-to-many model by all contracted customers, at any time, on a pay-for-use basis, or as a subscription based on usage metrics.” (Gartner,2006) Gartner geeft daarbij aan dat de nadruk ligt op dienstverleners die SaaS-diensten aan externe klanten leveren, maar dat het concept eveneens toepasbaar is voor IT-afdelingen die intern SaaS leveren aan eigen eindgebruikers. Bij het Saas-concept is het niet van belang of de applicatie intern of bij een derde partij is ondergebracht.

4

SaaS versus ASP SaaS is een opvolger van Application Service Provider (ASP). ASP-software staat bekend als een traditionele client-serverapplicatie waar later web-gebruikersschermen aan zijn toegevoegd. Deze applicaties worden gehost bij derde partijen met veel hostingkennis maar weinig applicatiekennis. Omdat deze applicaties niet specifiek voor het SaaS-concept zijn geschreven, hebben ze weinig voordelen ten opzichte van applicaties in eigen beheer. Dit heeft als gevolg dat slechts enkele ASP-aanbieders succesvol zijn gebleken. De term ASP is stapsgewijs veranderd in de term SaaS waarbij SaaS veel meer klantge-

IT Service Management, best practices, deel 4 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Kenmerk Applicatie- architectuur

ASP Traditioneel met web-frontend

Beveiligingsconcept

Besturingssysteem

Hostingpartij Focus

Hostingkennis Leveranciersgericht

264

SaaS Geschikt voor, webgebaseerd, open, one-to-manymodel Intern in de applicatie door scheiden en delen van omgevingen (datadomeinen) Hosting- en applicatiekennis Klantgericht

Tabel 1 Verschillen tussen ASP en SaaS

dreven is in plaats van leveranciergedreven. Applicaties in het SaaS-concept hebben een specifieke architectuur om geschikt te zijn voor bijvoorbeeld webgebaseerd gebruik, open toegankelijkheid en een ‘one-to-manymodel’ zodat meerdere partijen gebruik kunnen maken van een applicatie. Hiervoor heeft een SaaS-applicatie een beveiligingsconcept nodig dat is gefundeerd in de architectuur van de software, zodat de verschillende klanten zeker kunnen zijn van de integriteit van hun data. SaaS in servicemanagement Servicemanagementapplicaties worden tegenwoordig ook in het SaaS-concept aangeboden. Een servicemanagementapplicatie kan worden gebruikt door IT-afdelingen van meerdere onafhankelijke bedrijven. Dit kan als hun ITIL-processen in grote lijnen identiek zijn. Deze mogelijkheid heeft veel overeenkomsten met de vroegere ASP-invulling. Het komt veel voor dat IT-afdelingen delen van hun dienstverlening uitbesteden aan andere leveranciers. Om de volledige dienstverlening naar de eindgebruiker te waarborgen, moeten de ITIL-processen van alle betrokken partijen goed op elkaar aansluiten. Als alle betrokken partijen van één en dezelfde SaaS-servicemanagementapplicatie gebruik zouden maken in hun eigen gescheiden omgeving, kan eenvoudig delen van data de onderlinge communicatie ondersteunen. Op deze manier zijn dure interfaces niet nodig. Dit is een voorbeeld van de manier waarop organisaties een SaaS-servicemanagementapplicatie efficiënt kunnen inzetten voor specifieke behoeftes die servicemanagementprocessen met zich meebrengen.

TOEPASSINGEN VAN SAAS IN SERVICEMANAGEMENT Servicemanagementapplicaties in het SaaSconcept kunnen interessante significante voordelen opleveren. In de volgende paragrafen beschrijven we een aantal situaties uit het werkveld servicemanagement. De SaaSoplossing voor deze situaties wordt vergeleken met een klassiek opgezette servicemanagementapplicatie. Dit maakt de vooren nadelen van beide opzetten inzichtelijk. Met klassiek bedoelen we hier: een servicemanagementapplicatie die gebruikers zelf hebben gekocht en die ze implementeren en beheren op een eigen infrastructuur. Dit in tegenstelling tot een applicatie die gebruikers afnemen bij een interne of externe SaaS leverancier. Voorbeeld van opzichzelfstaande omgevingen in MKB Situatie Een IT-afdeling in het MKB heeft standaard ITIL-processen en wil voor deze processen een goedkope standaard servicemanagementapplicatie gebruiken. Klassieke oplossing De IT-afdeling koopt op basis van een selectietraject een servicemanagementapplicatie en betaalt een vast licentiebedrag en een jaarlijks supportbedrag. Vervolgens implementeert de afdeling deze applicatie op een eigen infrastructuur zoals bijvoorbeeld een server op een eigen netwerk. De IT-afdeling regelt het beheer, dat is gebaseerd op hun eigen processen.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


IT-afdeling Bedrijf A

IT-afdeling Bedrijf B

265 Server

Server Applicatie

Applicatie

Figuur 1 Klassieke inzet servicemanagementapplicatie in voorbeeld MKB

SaaS-oplossing De IT-afdeling koopt op basis van een selectietraject een servicemanagementapplicatie in het SaaS-concept en betaalt per gebruiker een prijs per maand. De applicatie is direct beschikbaar en gebruikers kunnen deze inrichten met klantspecifieke gegevens. De partijen leggen alle afspraken over beheer vast in een Service Level Agreement (SLA). Voor- en nadelen Het SaaS-concept heeft een aantal voordelen zoals een verkorte implementatietijd en het feit dat de leverancier veel zorgen over implementatie en beheer uit handen van de afdeling neemt. Daarnaast is een grote initiële investering niet nodig omdat elke gebruiker per maand betaalt en de afdeling de mogelijk-

IT-afdeling Bedrijf A

heid om naar behoefte de dienstverlening uit te breiden of in te krimpen. Ook heeft het een duidelijk financieel voordeel als de applicatie op een en dezelfde infrastructuur draait van de SaaS-leverancier. Kosten voor hardware, besturingssysteem, database en dergelijke worden per saldo lager. De operationele kosten zoals beheer en datacenterfaciliteiten worden eveneens lager waardoor de maandelijkse prijs per gebruiker in verhouding lager is dan in een klassieke situatie. Een voordeel van de klassieke oplossing is de flexibiliteit van het implementatieproject omdat deze volledig in eigen handen is. Daarnaast kunnen IT-afdelingen eventuele bedrijfspecifieke functies eenvoudiger implementeren dan in een SaaS-omgeving.

4

IT-afdeling Bedrijf B

Servicemanagementapplicatie Applicatieomgeving

Applicatieomgeving

Figuur 2 SaaS-servicemanagement in voorbeeld MKB


266

Voorbeeld van offshoring of outsourcing Situatie Een IT-afdeling heeft verschillende delen van de dienstverlening, bijvoorbeeld het netwerken werkplekbeheer, uitbesteed aan derde partijen. De IT-afdeling heeft een integrale rol en zal, waar nodig, de derde partijen aansturen. Voor het eigen deel van de dienstverlening zoeken ze een servicemanagementapplicatie die naadloos kan communiceren met de servicemanagementapplicaties van de betrokken derde partijen. De ITIL-processen van zowel de IT-afdeling als de derde partijen zijn vergelijkbaar. Klassieke oplossing De IT-afdeling schaft een eigen servicemanagementapplicatie aan en implementeert deze. Voor de communicatie met de derde partij bouwt en implementeert ze een uitgebreide interface, die de communicatie tussen

de processen van de verschillende partijen mogelijk maakt. Op deze manier kunnen de partijen incidenten wijzigingsinformatie direct uitwisselen. SaaS-oplossing Zowel de IT-afdeling als de derde partijen kiezen voor dezelfde SaaS-oplossing. Binnen de SaaS-oplossing is het mogelijk om op eenvoudige wijze informatie te delen tussen de partijen. De partijen maken afspraken over de informatie die ze willen delen en in welke fase van het proces dit mag. Op basis van de rechtenstructuur kunnen de partijen informatie inzien en uitwisselen zodat de communicatie tussen de partijen zonder ingewikkelde interfaces tot stand komt. Voor- en nadelen Naast de vooren nadelen van het MKB-voorbeeld biedt de servicemanagementapplicatie de mogelijkheid, door het geavanceerde

Derde partij

Server Applicatie IT-afdeling

Server Applicatie

Derde partij

Server Applicatie

Figuur 3 Voorbeeld van ‘klassieke’ outsourcing



IT-afdeling

267

Servicemanagementapplicatie Applicatieomgeving

Derde partij

Applicatieomgeving

Applicatieomgeving

Derde partij

Figuur 4 Outsourcing met SaaS-ondersteuning

beveiligingsmodel, om informatie te delen. Hierdoor zijn ingewikkelde, starre en dure interfaces niet meer nodig. Veranderingen in het informatiedelen, zoals de leverancier toegang geven tot configuratie data, is eenvoudig implementeerbaar. De communicatie kan snel, flexibel en voor minimale kosten uitgevoerd worden. Nadelen van het SaaSconcept zijn dat elke partij voor dezelfde servicemanagement applicaties moet kiezen en gebonden is aan dezelfde SaaS-leverancier. Voorbeeld van een serviceprovider Situatie Een IT-serviceprovider heeft verscheidende klanten waaraan IT-diensten worden verleend. Deze klanten zijn concurrenten van elkaar en eisen van de IT-serviceprovider strenge beveiliging van hun informatie. Het aanbrengen van beveiligingsvoorzieningen in de organisatiestructuur en IT-middelen zijn hierdoor noodzakelijk. De IT-provider zoekt een servicemanagementapplicatie die aan deze beveiligingseisen voldoet. Klassieke oplossing De serviceprovider heeft per klant een aparte afdeling opgezet. Deze zelfstandige afdelingen kiezen voor een eigen servicemanagementapplicatie en implementeren deze. Als de organisatie technische specialisten heeft

die onafhankelijk van de klanten opereren, zijn tussen de verschillende servicemanagementapplicaties interfaces nodig om de communicatie tussen de klantafdelingen en de technisch specialisten te faciliteren. Hiervoor zet de provider een gestandaardiseerde busstructuur in zodat ze applicaties eenvoudig kunnen aansluiten. SaaS-oplossing Als de verschillende afdelingen met standaard ITIL-processen werken kan de SaaSservicemanagementapplicatie de functionele wensen invullen. Voor de afdelingen kan de provider de SaaS-applicatie in aparte applicatieomgevingen inzetten zodat volledige scheiding van de data mogelijk is. De serviceprovider kan hierdoor beveiligingsgaranties geven aan zijn klanten. Voor de communicatie met de technisch specialisten kunnen ze klantspecifieke data beveiligen en technische data juist delen. De klant kan de SaaS-applicatie bij derden afnemen maar ook bij de interne IT-afdeling.

4

Voor- en nadelen Het grote voordeel van de SaaS-oplossing is de gestandaardiseerde omgeving waar elke afdeling afzonderlijk mee kan werken. De kosten die een omvangrijk applicatielandschap met zich meebrengt zijn enorm. De SaaS-oplossing is daarbij veel sneller te im-


Klant A

Klant B

Supportafdeling voor klant A

Supportafdeling voor klant B

268

Server

Server Applicatie

Applicatie

Server Applicatie

Specialistenafdeling

Figuur 5 Klassieke opzet van het voorbeeld over de serviceprovider

Klant A

Klant B

Supportafdeling A

Supportafdeling B

Specialistenafdeling

Servicemanagement applicatie

Applicatieomgeving

Applicatieomgeving

Applicatieomgeving

Figuur 6 Serviceprovider ondersteund door SaaS-servicemanagement



plementeren zodat de ‘time to market’ korter is. Een voorwaarde voor de SaaS-oplossing is dat de processen in de verschillende afdelingen geharmoniseerd moeten zijn en dit is vaak een moeizaam en politiek gevoelig traject.

concept gebruiken om binnen de processen een scheiding te maken op individuele tickets. Door deze scheiding kunnen alleen speciaal geautoriseerde medewerkers security-incidenten, zoals bijvoorbeeld een computerinbraakpoging, zien en afhandelen.

Voorbeeld van interne processcheiding

Voor- en nadelen Gebruikmaken van één omgeving is het grote voordeel van de SaaS-oplossing Hierdoor besparen IT-afdelingen kosten voor een aparte omgeving. Bovendien ondersteunt de functionaliteit ook de ITIL-processen. Nadelig is dat bedrijven het beheer van de SaaS-servicemanagementapplicatie alleen aan eigen mensen toe kunnen vertrouwen. Dit betekent dat het bedrijf de SaaS-applicatie alleen intern kan beheren en niet aan een derde partij kan uitbesteden.

Situatie De IT-afdeling heeft belangrijke security-aspecten toegevoegd aan de ITIL-processen. Alleen specifiek toegewezen vertrouwelijke personen mogen aan securityzaken werken. Als deze securitygevoelige informatie naar buiten komt kan dit grote imagoschade opleveren voor het bedrijf. Om dit te voorkomen wil de IT-afdeling scheiding in de processen doorvoeren: de normale incidenten scheiden van de security-incidenten, afhandeling van securitydiensten cheiden van de normale wijzigingen en informatie over de security-apparatuur scheiden in de CMDB. Klassieke oplossing De IT-afdeling zet voor de ITIL-processen een servicemanagementapplicatie in. Naast deze applicatie zet ze een aparte hoog beveiligde applicatie in voor de security-activiteiten in de ITIL-processen. SaaS oplossing De IT-afdeling kan de normale ITIL-procesinformatie en de beveiligde ITIL-procesinformatie in één applicatie onderbrengen. Ze kan de beveiligingsmogelijkheden in het SaaS-

IT-afdeling reguliere medewerkers

Server

269

CONCLUSIES UIT DE VOORBEELDEN Uit deze praktijkvoorbeelden blijkt dat afname van servicemanagementapplicaties in het SaaS-concept voordelen met zich meebrengt. Op functioneel vlak schept de scheiding en deling van gegevens veel toepassingsmogelijkheden, zo zijn ook combinaties mogelijk van de beschreven voorbeelden. Vanuit financieel oogpunt is een SaaS-servicemanagementoplossing zeer interessant door de consolidatie van applicaties op één applicatieomgeving. Voorwaarde voor de SaaS-oplossing is een fundamenteel beveiligingsconcept.

4

IT-afdeling securitymedewerkers

Server Applicatie

Applicatie

Figuur 7 Harde scheiding voor securitygevoelige informatie


IT-afdeling regulier

270

IT-afdeling security

Servicemanagementapplicatie

Applicatieomgeving

Applicatieomgeving

Figuur 8 Een beveiligde omgeving in de SaaS-servicemanagementapplicatie

Beveiliging in het SaaS-concept Een belangrijk onderdeel van SaaS is de beveiliging. Het idee dat een applicatie buiten het eigen interne netwerk aangeboden wordt is vaak geen geruststellende gedachte. Gelukkig is er tegenwoordig een grote verscheidenheid aan veiligheidsmaatregelen die de beveiliging op hetzelfde niveau waarborgen als een ‘in-houseomgeving’, of deze zelfs overtreffen. Een applicatie die de IT-leverancier via SaaS aanbiedt heeft standaard altijd een eigen beveiliging, gebruikers hebben namelijk altijd een gebruikersnaam en wachtwoord nodig om in te loggen. Daarnaast mag het niet mogelijk zijn dat klanten elkaars data benaderen. Dit geldt op applicatieniveau maar ook op een lager niveau. Rapportage-engines spreken vaak op dit lagere niveau data aan. Het verschil tussen SaaS en een standaardimplementatie is dat SaaS over het algemeen het ‘pand’ uitgaat, de IT-afdeling maakt niet uitsluitend gebruik van het eigen netwerk. Hierdoor is het noodzakelijk om goed naar de beveiliging van de verbindingen te kijken. De eisen aan deze beveiliging verschillen per organisatie, zo zijn er ook verschillende niveaus van beveiliging mogelijk.

Binnen SaaS en de verbinding van de klant naar de organisatie onderscheiden we de volgende veiligheidsniveaus: 1. standaard internetbeveiliging 2. uitgebreide beveiliging 3. zeer uitgebreide beveiliging 1. Standaard internetbeveiliging SaaS wordt in de meeste gevallen aangeboden via internet. Het internet kent een aantal beveiligingsstandaarden waar SaaS ook gebruik van kan maken. Leveranciers bieden SaaS over het algemeen alleen via een secure verbinding aan, dit zal in de praktijk vaak SSL zijn in combinatie met een veiligheidscertificaat. Deze combinatie is standaard voor de meeste applicaties die, naast het interne netwerk ook vanaf het internet bereikbaar zijn. 2. Uitgebreide beveiliging Naast het gebruik van een standaard internetverbinding zijn er ook applicaties die via een beveiligde internetverbinding worden aangeboden. Gebruikers krijgen dan toegang op de applicatie met een persoonlijke pas, die per interval een nieuwe code genereert of een code op aanvraag genereert. De IT-leverancier zet rechtstreeks een beveiligde verbinding op van de gebruiker naar de applicatie. Een applicatie als Citrix



kan werken via dit principe, dit is een extra beveiligingslaag op de standaard internetbeveiliging. 3. Zeer uitgebreide beveiliging Heel vaak spreken leveranciers over Virtual Private Network (VPN) als beveiligde verbinding. De IT-leverancier zet een VPN-tunnel op naar de applicatie, dit is een denkbeeldig netwerk via internet. Het nadeel van deze oplossing is dat internet publiek is, theoretisch heeft iedereen toegang tot de versleutelde data. Een ander nadeel is dat installatie van ‘cliëntsoftware’ nodig is en gebruikers nog een keer moeten inloggen. Tegenwoordig is het ook mogelijk om een netwerk op te zetten met privélijnen, over deze privélijn lopen dan geen andere data dan die van de eigen organisatie. Dit levert voordelen op in snelheid, beschikbaarheid en beveiliging en er zijn geen afhankelijkheden van ‘derden’. Dit is de meest ideale en veilige manier. Een nadeel van zwaardere beveiliging is dat er in de regel ook meer kosten aan zijn verbonden. Uiteindelijk zal een organisatie zelf moeten afwegen wat het beste beveiligsniveau is voor de eigen specifieke situatie. Beveiligingsaudit In de huidige markt zijn goede en betrouwbare leveranciers te vinden die de genoemde verbindingsniveaus kunnen leveren. Uiteraard is dit een belangrijk aspect in de hele configuratie, immers: de ketting is zo sterk als de zwakste schakel. U kunt de betrouwbaarheid van een leverancier meten. Een gerenommeerde methode hiervoor is een audit: een extern bedrijf licht de IT-infrastructuur, applicatie, betrokken medewerkers en de procedures door. Het is gebruikelijk dat de leverancier een certificaat of zegel ontvangt als de audit positief wordt afgerond. Dit certificaat heeft een bepaalde geldigheid, de organisatie die deze heeft uitgereikt kan bepalen of er opnieuw een audit gedaan wordt, of dat deze verlengd wordt.

CONSEQUENTIES VOOR DE GEBRUIKERSORGANISATIE Bij klassiek gebruik van servicemanagementapplicaties zal de IT-afdeling zelf de implementatie en het beheer van de applicatie uitvoeren. Hierbij laat ze wel eens na om goede serviceafspraken te maken over het beheer van de applicatie. Servicemanagementapplicaties volgens het SaaS-concept neemt de IT-afdeling bij een andere partij af. Deze andere partij kan zowel intern als extern zijn maar het principe van de serviceafspraken blijft hetzelfde. De overgang van klassiek gebruik naar een SaaS-oplossing heeft consequenties voor de contracten en ook voor de gebruikersorganisatie.

271

Servicecontracten De IT-afdeling moet zich als klant gaan gedragen en zal daarom serviceafspraken vastleggen in een Service Level Agreement (SLA). Naast standaardafspraken zoals reactie- en oplostijd van incidenten, prestaties, beschikbaarheid en groei, zijn serviceafspraken voor SaaS een specifiek aandachtsgebied. Security Afspraken over beveiliging en ook over het delen van gegevens zijn belangrijk. Goedkeuring en uitvoering van de veranderingen op de rechtenstructuur in de applicatie is van wezenlijk belang. Het mag bijvoorbeeld niet voorkomen dat organisaties data van elkaar kunnen zien omdat de beheerder een fout heeft gemaakt tijdens de invoer. Controle op en rapportage van veranderingen speelt hierbij een cruciale rol.

4

Disasterrecovery Bij het uitbesteden van de applicatie aan een derde partij moet de IT-afdeling nadenken over de continuïteit van de applicatie en de mogelijke uitwijkscenario’s. SaaS-leveranciers zullen standaardoplossingen hebben, die veelal voldoen. De IT-afdeling moet deze oplossing toetsen op de gestelde eisen. Daarnaast kan ze bijvoorbeeld afspreken dat de SaaS-leve-


rancier back-ups en software met de klantspecifieke data naar de gebruikersorganisatie stuurt zodat de IT-afdeling in noodgevallen lokaal een systeem kan opzetten. 272

Releasemanagement De SaaS-applicatie zal veel functionaliteit bevatten die niet direct nodig is voor de eindgebruikers. Via dataconfiguratie kan de gebruiker deze functionaliteit in- en uitschakelen. Bij elke upgrade moet de IT-afdeling analyseren welke functionaliteit wenselijk is voor de eindgebruikers. Bij een SaaS-applicatie kunt u een regelmatige versieverhoging verwachten. Het is voor de functionele analyse van belang dat de gebruikersorganisatie tijdig informatie krijgt over de inhoud van de release. De organisatie kan hier dan invloed op uitoefenen en zorgen dat de functionaliteit in de toekomst aansluit bij de wensen van de organisatie. Hiervoor kan ze een zogeheten ‘enhancement request’(verzoek voor applicatie-uitbreiding) gebruiken. Voor SaaS-applicaties is dit een lastig proces omdat verschillende organisaties sterk afwijkende wensen kunnen hebben. De applicatieontwikkelaar zal proberen een zo generiek mogelijke standaardfunctionaliteit te bieden. Het is belangrijk om voor Saas-applicaties afspraken vastleggen in de SLA over release-informatie en de afhandeling van ‘enhancements’.

Stap 1 Voorbereiding 2 3 4 5 Realisatie 6 7 8 9 10 11 Implementatie 12 13 14 Nazorg

Implementatie van een SaaS-servicemanagementapplicatie De implementatie van een SaaS-servicemanagementapplicatie wijkt wezenlijk niet zoveel van een klassieke implementatie af. In principe kan de IT-leverancier de SaaS-applicatie gewoon op de klassieke wijze implementeren. Uitgangspunt van de implementatie van een SaaS-applicatie is dat deze wordt geleverd door een andere interne of externe partij. De SaaS-leverancier maakt gebruik van applicatieomgevingen op de bestaande infrastructuur of draagt zelf zorg voor uitbreiding hiervan. De projectzorg voor aanschaf, installatie en beheer van hard- en software is uitbesteed (zie tabel 1). De applicatie is standaard en voorgedefinieerd zodat er minder tijd nodig is voor analyse, configuratie en testen. Deze factoren reduceren de verwachte projectduur met 30% tot 40%. Aandachtspunten bij aanschaf Bij de aanschaf van een SaaS-servicemanagementapplicatie zijn een aantal specifieke zaken van belang: Eenvoudige evaluatie Gebruikers kunnen een SaaS-applicatie voor een bepaalde periode afnemen, het is een soort leasecontract. Dit betekent dat het aantal overstapmomenten toeneemt en de

Klassieke implementatie Opstellen eisen en wensen Selectie applicatie Contract onderhandelingen Analyse functionaliteit en dataconfiguratie Aanschaf hardware, database e.d. Installeren hardware e.d. Installeren applicatie Wijzigingen toevoegen Configureren applicatie Testen Regelen beheer Training gebruikers In productie brengen Begeleiding gebruikers

SaaS-implementatie Opstellen eisen en wensen Selectie applicatie Contract en SLA onderhandelingen Toetsen functionaliteit en dataconfiguratie Is door leverancier geregeld Is door leverancier geregeld Is door leverancier geregeld Functionaliteit aan of uitschakelen Configureren applicatie Testen Is door leverancier geregeld via een SLA Training gebruikers In productie brengen Begeleiding gebruikers

Tabel 2 Stappen in de implementatie van servicemanagementapplicaties



gebruikersorganisatie minder lang gebonden is aan een leverancier. Er is een eenvoudige evaluatie van de functionaliteit nodig om tussen de verschillende SaaS-servicemanagementleveranciers te kiezen. Een demonstratie of leeromgeving is hierbij een mogelijkheid. Gebruikerseisen en functionaliteit Net als bij een klassieke servicemanagementapplicatie moeten de eisen en wensen van de gebruikersorganisatie overeenstemmen met de geboden functionaliteit. Het toevoegen van functionaliteit is in een SaaS-servicemanagementomgeving lastig, daarom is het toetsen van de functionaliteit van groter belang. Het is beter om rekening te houden met eventuele wensen in te toekomst en te kiezen voor meer functionaliteit. Gebruikers kunnen deze functionaliteit in het begin uitschakelen en als zij de extra functies nodig hebben, weer inschakelen. In de praktijk blijkt dat op een gegeven moment nieuwe functies nodig zijn. De doorlooptijd van een ‘enhancement request’ is een belangrijk aandachtspunt bij de aanschaf van de SaaS-applicatie. Duidelijkheid over het intellectueel eigendom van de ‘enhancements’ is eveneens van belang. Integraties In veel gevallen zult u de SaaS-applicatie met eigen systemen moeten integreren. In de praktijk is integratie met klantsystemen, configuratiesystemen en bewakingssystemen voor de infrastructuur wenselijk. De SaaSservicemanagementapplicatie moet deze integratie op een gestandaardiseerde manier bieden, bijvoorbeeld met webservices. Daarnaast is de kans aanwezig dat deze systemen eveneens in een SaaS-concept werken. Hierdoor zijn koppelingen tussen SaaS-applicatieleveranciers nodig en deze kunnen op organisatorisch niveau complex zijn. Configurabele aspecten van de applicatie: Naast het aan en uitzetten van functies is het van belang dat de gebruikersorganisatie de applicatie op eenvoudige wijze kan configureren. De organisatie moet aspecten zoals SLA-contracten, workflows, autorisaties en CMDB-items, eenvoudig kunnen configu-

reren en deze aspecten moeten zijn ondersteund met importfunctionaliteit. De gebruikersorganisatie moet de parametrisering en dataconfiguratie zelfstandig uit kunnen voeren.

273

Mogelijke omgevingen Om het applicatiebeheer professioneel op te zetten zijn meerdere omgevingen noodzakelijk. Naast de productieomgeving zijn test, training en pre-productieomgevingen nodig. Deze laatste omgevingen hebben geen continu karakter. Als de gebruikersorganisatie deze omgeving tijdelijk afneemt, kan zij hier eveneens kosten op besparen. Het is dus interessant om de mogelijkheden van tijdelijke applicatieomgevingen te onderzoeken. Terugdraaien van de keuze voor het SaaS-concept Als later blijkt dat het SaaS-concept niet voldoet, is het dan mogelijk om de keuze terug te draaien? Kan de gebruikersorganisatie de applicatie ook op een klassieke manier inzetten? De stappen die nodig zijn voor deze omslag, zoals de aanschaf van de software en het migreren van de data, kunnen lastig zijn. Als terugdraaien van de keuze een potentiële mogelijkheid is, dan zal de organisatie hier bij de aanschaf van SaaS-servicemanagementapplicatie rekening mee moeten houden.

4

Rapportage en analysemogelijkheden In de klassieke situatie heeft de servicemanagementapplicatie een set standaardrapportages en waar nodig creëert de beheerorganisatie ad-hocrapportages. Aan deze behoefte zal het SaaS-concept ook moeten voldoen. Een set standaardrapportages is vanzelfsprekend, daarnaast zijn ad-hocrapportages voor eindgebruikers nodig. Voor het analyseren van gegevens zijn data-exportfuncties nodig, zodat gebruikers de data zelf kunnen bewerken. Voor grotere bedrijven is een interface met het eigen datawarehouse een mogelijkheid. Compliancy met standaarden Doordat vele bedrijven gebruikmaken van de functionaliteit van een SaaS-applicatie, zal


274

de leverancier zorg dragen voor standaarden in de software. Ook standaarden na aanleiding van wet en regelgeving, bijvoorbeeld Sarbanes Oxley en Tabaksblat, zullen sneller functioneel beschikbaar zijn voor de gebruikersorganisatie. Verrekening Het principe van het SaaS-concept is een interne of externe verrekening van kosten op basis van het gebruik van de applicatie. De verrekening kan op basis zijn van een maandelijkse of jaarlijks abonnement per gebruiker. Een ander mogelijkheid is ‘ticket based pricing’, waarbij het aantal ingevoerde of afgehandelde tickets de verrekening bepaalt. Met ‘ticket based pricing’ is het gebruik daadwerkelijk de basis voor verrekening. Het verrekenmodel zal moeten aansluiten op de wensen van de gebruikersorganisatie.

PRAKTIJKCASE VAN EEN GROTE DUITSE IT-DIENSTVERLENER Een grote Duitse IT-dienstverlener ontwikkelde in het verleden voor elke grote implementatie een uniek servicemanagementsysteem. Dit hield in dat voor elk project nieuwe processen, procedures en oplossingen werden geïmplementeerd. Dit zorgde voor arbeidsintensieve, kostbare en tijdrovende werkzaamheden voor elk project (ook op onderhoudsgebied). Uiteindelijk was er een grote verscheidenheid aan systemen in gebruik waarin veel overlappende informatie werd opgeslagen. Omdat de verschillende afdelingen meerdere systemen gebruikten en het toch noodzakelijk was om informatie uit te wisselen, moest de dienstverlener dus ook een groot aantal interfaces ontwikkelen en in stand houden. De laatste jaren waren zeer succesvol, er werd een grote groei van het aantal klanten gerealiseerd. Als gevolg hierop kwamen er steeds meer servicemanagementsystemen en werd het steeds lastiger om via de verschillende servicemanagementsystemen op een transparante manier te communiceren en te rapporteren. Voorbeeld hiervan is dat het moeilijk was om kennis uit te wisselen tussen de verschillende afdelingen vanwege het gebrek aan een centrale kennisdatabase.

Vanwege de snelle groei en de grote diversiteit aan klanten werd het noodzakelijk om te komen tot een verdere professionalisering van de dienstverlening binnen de ‘System Integration-divisie’. In 2004 is de dienstverlener dan ook gestart met het ‘Service in Excellence’ (SiE) programma om te komen tot standaardisatie van de bedrijfsprocessen, dienstencatalogi en contracten. Het doel van het programma is: de ‘quality of service’ verder verhogen, een uniforme prijsstructuur voor klanten opstellen en interne kostenbesparingen. Eén van de speerpunten van het SiE-programma is het transparant maken van de processen en de daarbij behorende quality-of-servicemetingen. Met de actuele situatie waarbij geen sprake was van standaardisatie van de informatie -en meetbehoefte was dit erg lastig. Al met al waren er inmiddels binnen System Integration meer dan 60 servicemanagementsystemen in gebruik met ongeveer 3000 gebruikers. De dienstverlener besloot om een businesscase op te stellen om te onderzoeken of het nuttig was om deze 60 systemen te gaan vervangen. Na het opstellen van deze case bleek dat er grote kostenvoordelen te behalen waren met de standaardisatie van de servicemanagementprocessen en oplossingen op basis van ITIL. Vervolgens werden de eisen opgesteld en bleek dat een flexibele servicemanagementoplossing met meerdere datadomeinen noodzakelijk was om snel en efficiënt de individuele servicemanagementsystemen te migreren naar één oplossing. Voor deze organisatie was het heel belangrijk dat ze enerzijds in staat zou zijn om met de nieuwe oplossing de processen te standaardiseren, maar dat ze geen afbreuk zou hoeven doen aan beloftes van confidentialiteit, die ze aan haar klanten doet in de contracten. Na een uitgebreid selectietraject werd het SITT project opgestart om een nieuwe SaaSservicemanagementoplossing te implementeren. De nieuwe oplossing stelt het bedrijf in staat om de servicemanagementprocessen flexibel te ondersteunen voor alle projecten en overige partijen die behoefte hebben aan



tools voor hun incident-, problemen changemanagementprocessen. Elke afdeling en externe partij heeft zijn eigen afgeschermde domein, kortom een beveiligde omgeving waarin alleen de data van de klant beschikbaar zijn. Afdelingen die voor meerdere klanten werkzaamheden uitvoeren zien alleen de tickets die aan hun groep zijn toegewezen op basis van een ‘rules engine’ (te definiëren beveiligingsregels). Met deze nieuwe oplossing is de dienstverlener in staat om nieuwe projecten sneller op te leveren. De consolidatie van veel servicemanagementapplicaties in één applicatie heeft een vermindering van licentie-, hardware-, personeels- en onderhoudkosten tot gevolg. Deze verminderingen zorgen samen voor een aanzienlijke kostenbesparing. De organisatie voert de ontwikkelingen voor de aanlevering van projecten en oplossingen aan klanten uit met behulp van outsourcingpartners in India, Rusland en andere lagelonenlanden. De nieuwe SaaS-oplossing stelt dit bedrijf in staat om de toepassing ook te gebruiken bij deze outsourcingpartners en in de toekomst ook als servicemanagementoplossing bij haar klanten. De enkele database onder de nieuwe SaaSoplossing biedt de organisatie de mogelijkheid om op managementniveau te rapporteren over informatie van alle domeinen. Omdat het datamodel en de daarbij behorende informatiebehoefte is gestandaardiseerd is er nu één volledig doorzichtig proces. Ze zijn in staat om de processen continu te bewaken, gedetailleerde informatie over de prestaties te ontvangen en over kwaliteit, service en levering te rapporteren. Voor dit bedrijf, maar misschien nog wel meer voor hun klanten, brengt het gebruik van SaaS nog een groot voordeel met zich mee. Zij kunnen de softwarediensten nu factureren op basis van de aantallen incidenten, wijzigingen en problemen. De uren en middelen worden per ticket aan de klanten doorbelast.

CONCLUSIES Uit de voorbeelden kunnen we concluderen dat het aanbod van servicemanagementapplicaties in het SaaS-concept significante voordelen met zich mee kan brengen. De bedrijfsvoordelen kunnen we indelen in de volgende twee categorieën:

275

MKB-markt In eerst instantie is het voor de kleinere ITafdelingen of bedrijven interessant om servicemanagementapplicaties via het SaaSconcept af te nemen bij derden. Grote investeringen zijn niet nodig, de implementatietijd is kort en veel projectzorgen worden hun uit handen genomen. Een gestandaardiseerd ITIL-proces en passende serviceafspraken zijn voorwaarden voor succes van een SaaS-applicatie. Grote ondernemingen Grote serviceorganisaties kunnen met het SaaS-servicemanagementconcept een veel grotere uitdaging aan. De SaaS-servicemanagementapplicatie heeft de mogelijkheid om gebruikersomgevingen te scheiden maar ook weer gegevens te delen. Hiermee kunnen organisaties de communicatie tussen interne en externe afdelingen in vele varianten toepassen. De organisatie kan de applicatie aan de klanten leveren voor het eigen deel van het serviceproces. De ondersteuning van de communicatie van de klanten met de serviceorganisatie is eenvoudig, zonder lastige en dure interfaces. De interne afdelingen kunnen gescheiden van elkaar de service verlenen, zodat ze aan de beveiligingseisen voor concurrerende informatie kunnen voldoen. Daarnaast kunnen ze de technische informatie weer delen met specialistische afdelingen. Ze kunnen de applicatie ook aan derden leveren zodat ze de communicatie met deze outsource- of offshorepartijen eenvoudig tot stand kunnen brengen. Omdat voor alle afdelingen een en dezelfde applicatie wordt gebruikt, is het mogelijk om overkoepelende managementinformatie te verzamelen. Dit maakt de totale serviceketen inzichtelijk en

4


bestuurbaar. Organisaties kunnen het applicatielandschap drastisch vereenvoudigen en daarmee een flinke kostenreductie realiseren. 276

Randvoorwaarde van het SaaS-concept is dat alle partijen op een eenduidige manier de functionaliteit gebruiken. Dit houdt in dat ze de processen en informatievoorziening hiervoor moeten standaardiseren. Het gebruik van gestandaardiseerde ITIL-processen is een mogelijkheid. Bij grote ondernemingen zal de serviceorganisatie meestal zelf de SaaS-applicatie onder haar hoede nemen. De voordelen van de uitbesteding van een applicatie aan derden zijn dan niet meer relevant. De serviceorganisatie zal de verrekening met de gebruikersorganisatie wel volgens het SaaS-concept uitvoeren omdat externe partijen de applicatie gaan gebruiken. De interne IT-afdeling wordt hierbij een professionele SaaS-leverancier. Ron Bovee is manager Business Consultancy bij Mansystems Nederland B.V. en is als adviseur en projectmanager betrokken bij de SaaS-implementatie bij de grote Duitse IT-dienstverlener. Sander Visser is verantwoordelijk voor International Business bij Mansystems Nederland B.V. en is in die hoedanigheid actief bij de grote Duitse IT-dienstverlener waar de SaaS-oplossing is geïmplementeerd. Kaspar Bosgoed is consultant bij Mansystems Nederland B.V. en is projectmanager bij BosworX om SaaS-servicemanagement aan te bieden aan het MKB.

BRONNEN • Gartner (2006). Evaluating Software-asa-Service Providers:Questions to Ask Potential SaaS Providers. 18 April 2006 / ID Number: G00138777. • Gartner (2006). Key Issues for Software as a Service. 28 March 2006 / ID Number: G00138654. • Software as a service. www.wikipedia.org.


Servicemanagementapplicaties in het SaaS-concept

Recommend Documents