FLEXIBEL DE BURGER BEDIENEN MET ICT

FLEXIBEL DE BURGER BEDIENEN MET ICT VKA white paper Merijn van der Zalm Christ Reniers Pim Schouten September 2007

Samenvatting In de wereld van de gemeenten, provincies en waterschappen zien wij een enorme toename van samenwerking (en fusies) tussen lokale overheden. Deze toename leidt er vaak toe dat de ambtenaren van een bepaald samenwerkingsverband vanuit verschillende fysieke plaatsen hun werk moeten kunnen doen. Dit gaat samen met de toenemende vraag naar flexibilisering van organisaties en mobiliteit van individuen. Deze flexibele organisatie is nodig om burgers en bedrijven beter te kunnen bedienen, zoals van een moderne overheid verwacht mag worden. De bestuurders van lokale overheden moeten bij fusies of samenwerking besluiten nemen over bestaande en nieuwe ondersteunende infrastructuur en dus ook over technische concepten die de gewenste organisatieontwikkeling ondersteunen. Server-based computing is één van de mogelijkheden om deze ondersteuning te versterken. SBC is een concept waarbij de applicaties die binnen een organisatie gebruikt worden op centrale servers draaien. Voor die applicaties is de functie van het werkstation gereduceerd tot die van een terminal. We beschrijven in dit white paper hoe het mogelijk is om schaalgroottevoordelen te bereiken door ICT middelen weer op één plaats te concentreren en de kwaliteit van de ICT dienstverlening te verbeteren met SBC. De kwantitatieve en kwalitatieve voordelen van SBC zijn legio, zoals vereenvoudiging van het beheer, kostenreductie en kansen voor verbetering van de beveiliging. Maar er zijn ook nadelen. Daarom is er een goede business case nodig: kosten, baten en risico's moeten integraal en in de tijd worden afgewogen om een goed besluit te kunnen nemen. Beslissers dienen zich dan ook een oordeel te vormen over de voordelen en consequenties van SBC. Want hoewel het concept van SBC eenvoudig is, kan de invoering zeer complex zijn. Om de beslissers te helpen bij besluitvorming hebben wij een model opgesteld als basis voor een business case met betrekking tot de introductie van SBC. In dit model kunnen beslisser en ICT-er een gezamenlijk referentiekader vinden om tot een bestuurlijke en inhoudelijke afweging te komen. Het is geen kant en klare template, maar een ondersteunend instrument bij de gedachtenvorming en de besluitvorming. Naast dit basismodel bevat dit white paper ook een hoofdstuk over verschillende onderwerpen waarover in de praktijk nog vaak discussie plaatsvindt. Deze onderwerpen moeten ons inziens ook worden overwogen bij de beoordeling van de waarde van SBC. Dit document geeft u en uw organisatie daarmee de kapstok om snel inzicht te krijgen in de voor- en nadelen van SBC voor uw situatie, zodat u een besluit over de toepassing ervan kunt nemen. De gemeente Heusden introduceerde in 2001 de "Heusdense Manier van Werken" (HMW): De organisatiestrategie is dynamisch, met een optimale service aan de inwoners. Onderdeel hiervan is flexwerken, wat betekent werken op elke mogelijke plek (tijd- en plaatsongebonden) met als enige voorwaarde een internetverbinding. De werkwijze van de gemeente kenmerkt zich door slagvaardigheid, betrouwbaarheid en kostenbewustzijn. Belangen worden op een duidelijke manier en in alle openheid afgewogen, burgers en bedrijven kunnen de gemeente daarop aanspreken (bron: e-overheid.nl). Copyright 2007 Verdonck, Klooster & Associates B.V. i

Inhoudsopgave 1 Inleiding 1 1.1 Context en trends: Terug naar de terminal? 1 1.2 Doel van dit white paper: een beslissingsondersteunend model aanreiken 1 1.3 Voor wie is dit white paper bedoeld? 2 1.4 Leeswijzer 2 2 Positionering van onderwerpen 3 2.1 Wat is server-based computing? 3 2.2 Hoe werkt een business case? 3 2.3 SBC bij lokale overheden 4 2.4 Voordelen en nadelen van SBC voor de lokale overheid 5 3 Opbouw van een business case 7 3.1 Introductie 7 3.2 Uitgangspunten 8 3.3 Investeringskader 11 3.4 Globaal ontwerp 13 3.5 Kosten, baten en financiële analyse 15 3.6 Risico's en maatregelen 18 3.7 Conclusies en aanbevelingen 18 3.8 Migratieplan op hoofdlijnen 19 4 Discussiepunten 21 4.1 Het SBC-concept 21 4.2 Beveiliging: is SBC veiliger? 24 4.3 Mitsen en Maren van het instrument business case voor SBC 24 A Literatuurlijst 26 B Over de auteurs 27 Copyright 2007 Verdonck, Klooster & Associates B.V. i

1 Inleiding 1.1 Context en trends: Terug naar de terminal? In het begin van het 'netwerk' was er één computer en die stond letterlijk centraal: het mainframe. Met de groei van decentrale gebruikersmogelijkheden en een nieuw ontstane klasse van goedkope computers (PC's) traden we vervolgens het client-server tijdperk binnen, waarbij afdelingen en individuen zelfvoorzienend werden op ICT-gebied, met integraal management. Dit sloot ook aan bij de prijs van bandbreedte in die tijd. Dankzij het steeds goedkoper worden van bandbreedte maakt het nu in principe niet meer uit of verwerking lokaal of centraal plaatsvindt. We beschrijven in dit white paper hoe het mogelijk is om schaalgroottevoordelen te bereiken door ICT middelen weer op één plaats te concentreren en de kwaliteit van de ICT dienstverlening te verbeteren met serverbased Computing (SBC). Dit white paper geeft antwoord op de vraag waarom u als lokale overheid SBC zou overwegen en hoe het u helpt bij het realiseren van uw bestuurlijke en ambtelijke doelstellingen. Ten eerste zien wij een enorme toename van samenwerking (en fusies) tussen lokale overheden. Deze toename leidt er vaak toe dat de ambtenaren van een bepaald samenwerkingsverband vanuit verschillende fysieke plaatsen hun werk moeten kunnen doen. Dit gaat samen met de toenemende vraag naar flexibilisering van organisaties en mobiliteit van individuen. Door de ICT-middelen te concentreren en deze via het (inter)netwerk op alle plaatsen beschikbaar te stellen wordt voorkomen dat middelen en diensten aan één plaats zijn gebonden en worden onnodige kopieerslagen, dure verhuizingen etc. vermeden. Ten tweede leidt een concentratie van middelen in veel gevallen tot kostenbesparing op beheer, bandbreedte en hardware door schaalgrootte en standaardisatie van de werkplekken, baten die vaak zeer welkom zijn in verband met de voortdurende druk op de budgetten van lokale overheden. Ten derde neemt de aandacht voor beveiliging ook bij lokale overheden enorm toe: met het concentreren van middelen is de bedrijfsvoering veel beter te beveiligen en continuïteit te garanderen dan wanneer op elke locatie allerlei componenten staan. Als vierde zien wij steeds meer mogelijkheden voor buitendienstmedewerkers met een behoefte aan mobiele toegang tot het netwerk van de organisatie. Het implementeren van server-based Computing (SBC) kan in samenhang met een verbeterslag overigens ook goed worden gebruikt als opstap naar shared services of outsourcing. Staat u voor de keuze om met SBC te gaan werken? Ons advies is: neem de tijd om met dit whitepaper aan de slag te gaan. Weeg voordelen en nadelen af en ontwikkel een goede business case. Het technisch concept van SBC is relatief eenvoudig te doorgronden, maar het succes van de implementatie zit in de zaken eromheen: de organisatie, processen en communicatie. 1.2 Doel van dit white paper: een beslissingsondersteunend model aanreiken In veel organisaties wordt nagedacht over de mogelijkheid om SBC te introduceren. SBC is een concept waarbij de applicaties die binnen een organisatie gebruikt worden op centrale servers draaien. Voor die applicaties is de functie van het werkstation gereduceerd tot die van een terminal. Het onderwerp SBC staat op de agenda van veel lokale overheden. Het initiatief voor het Copyright 2007 Verdonck, Klooster & Associates B.V. 1

introduceren van SBC komt meestal vanuit de ICT afdeling van de organisatie, of vanuit de dienstenleverancier indien de ICT is uitbesteed. Beslissers dienen zich een oordeel te vormen over de voordelen en consequenties van SBC. Want hoewel het concept van SBC eenvoudig is, kan de invoering zeer complex zijn. Om de beslissers te helpen bij besluitvorming hebben wij een model opgesteld als basis voor een business case met betrekking tot de introductie van SBC. Het is geen kant en klare template, maar een ondersteunend instrument bij de gedachtenvorming en de besluitvorming. Wij geven dus geen begroting voor een compleet project, maar willen ondersteuning bieden bij de afweging (financieel en functioneel) tussen SBC en klassieke omgevingen. Wij roepen bestuurders en managers op dit model in hun organisatie in te zetten. 1.3 Voor wie is dit white paper bedoeld? We hebben dit white paper geschreven voor zowel de beslissers als de schrijvers van de business case. Het eerste deel van dit white paper werkt met een generieke beschrijving van SBC en hoe dit ingezet zou kunnen worden bij lokale overheden zoals gemeenten, provincies en waterschappen. Dit gedeelte is bedoeld voor bestuurders en managers in deze organisaties. Het tweede deel gaat meer de diepte in en is vooral bedoeld voor degenen die de business case uitwerken. Dit kunnen medewerkers van de ICT afdeling zijn, zoals projectleiders, maar ook bijvoorbeeld adviseurs of informatieanalisten. Het discussiegedeelte kan dienen voor zowel generieke als specifieke discussies binnen en tussen de twee genoemde doelgroepen. 1.4 Leeswijzer Na deze inleiding worden in hoofdstuk 2 eerst de relevante basisbegrippen en voordelen rond SBC bij lokale overheden gepositioneerd. In hoofdstuk 3 worden de uitgangspunten van een business case voor SBC, de kwalitatieve en kwantitatieve elementen die hierbij een rol spelen en de invloed van deze elementen op de besluitvorming, meer in detail uitgewerkt. In hoofdstuk 4 wordt besloten met de uitwerking van een aantal onderwerpen van discussie die bij een implementatie van SBC relevant zijn. Deze kunnen worden gebruikt bij zowel een bestuurlijke, technische als gecombineerde discussie vóór de introductie van SBC. Copyright 2007 Verdonck, Klooster & Associates B.V. 2

2 Positionering van onderwerpen 2.1 Wat is server-based computing? Server-based computing (SBC) is een concept waarbij de applicaties die binnen een organisatie gebruikt worden op centrale servers draaien. De werkstations bevatten dus geen programma's en gegevens, maar zijn slechts een communicatiemiddel naar de servers. Deze werkstations kunnen 'lichte' computers zijn, zogenaamde 'thin clients' 1. De hoeveelheid uitgewisselde gegevens is beperkt, omdat in principe alleen de noodzakelijke in- en output voor de thin clients wordt gecommuniceerd (toetsenbordaanslagen, muisbewegingen en beeldscherminformatie). Een gemiddeld bedrijfsnetwerk met 10 of 100 Mbps LAN-aansluitingen op de werkplek zal dus al snel voldoende capaciteit bieden voor SBC. Het heeft ook een aantal nadelen, bijvoorbeeld dat niet alle applicaties probleemloos via SBC aangeboden kunnen worden. Deze voor- en nadelen worden hieronder verder uitgewerkt. 2.2 Hoe werkt een business case? Een business case is de zakelijke rechtvaardiging voor een verandering, meestal gegoten in de vorm van 1) financiering van middelen en 2) een project om deze te laten renderen middels nieuwe of veranderde processen. Een business case bestaat enerzijds uit een document met rekenexercities en verklarende tekst, anderzijds uit een (bestuurlijk) proces waarin het document tot stand komt, wordt aangepast en draagvlak van stakeholders verwerft (of niet). In een business case traject wordt concreet en expliciet gemaakt wat de huidige situatie van één of meerdere stakeholders is, welke toekomstige situatie de opstellers zich na de investering met bijbehorende verandering voorstellen en wat de transitie van huidig naar toekomstig (eenmalig en/of structureel) oplevert. Het document wordt na elke fase geüpdatet en als vertrekpunt gebruikt voor het beheersen van een volgende fase. In de meeste projectmanagementmethodieken, met name in Prince2, wordt een business case ook expliciet als stuurinstrument benoemd. Het ontwikkelen van de initiële business case, wat in principe voorafgaat 2 aan het besluit tot een daadwerkelijke investering, bestaat meestal uit de volgende fasen en processtappen: 1 Bij zogenaamd 'fat clients' draait de functionaliteit op de lokale pc 2 Ook na de initiële investering kan het nog zinvol zijn de business case te construeren, niet als legitimering achteraf, maar als sturingsmiddel voor het weer op de rails krijgen van onbeheersbare projecten. Copyright 2007 Verdonck, Klooster & Associates B.V. 3

Figuur 1: Stappen in het business case traject Het spreekt vanzelf dat deze stappen niet volgtijdelijk plaatsvinden. Immers, men heeft bij de start al een beeld van het 'ontwerp' van de nieuwe situatie, vanuit knelpunten in de huidige situatie of vanuit nieuwe eisen of mogelijkheden vanuit de omgeving. Dit is vaak ook de aanleiding voor het opstellen van een business case. Het is daarom belangrijk dat het business case document een eenduidige neerslag van dit proces geeft en gebruikt kan worden als transparante onderbouwing van de investeringsbeslissing. Dit vereist dat de hoofdstukken van het document logisch op elkaar voortbouwen, zodat de lezer via de gevolgde redeneerlijn in principe tot dezelfde conclusies als de opstellers kan komen. De transparantie in de redenering is belangrijk om beslissers inzicht te geven in de gevolgen van alternatieve beslissingen. De voorbeeldhoofdstukken voor zo'n document en hun inhoud zijn in detail uitgewerkt in hoofdstuk 3. 2.3 SBC bij lokale overheden Binnen gemeenten, provincies en waterschappen is het gebruik van SBC relatief wijdverspreid. De reden is dat de hierna uitgewerkte voordelen in deze omgeving in veel gevallen goed tot hun recht komen. Zo zijn veel gemeenten bezig met bezinning op de vraag of de ICT in eigen beheer moet worden gehouden of dat deze uitbesteed zou kunnen worden. Een SBC omgeving biedt een ideaal migratiepad naar outsourcing: de centrale servers kunnen eenvoudig worden overgenomen in het datacenter van een leverancier. Daarnaast werken gemeenten vaak op meerdere locaties. Het gemeentelijk rekencentrum bevindt zich op een centrale locatie, terwijl er zich ook werkplekken op dislocaties bevinden. Dit is nog nadrukkelijker het geval bij een gemeentelijke herindeling. Het ICT beheer op dislocaties is veel eenvoudiger met SBC. Copyright 2007 Verdonck, Klooster & Associates B.V. 4

2.4 Voordelen en nadelen van SBC voor de lokale overheid SBC kan een aantal voordelen bieden voor de organisatie. De belangrijkste voordelen zijn: Voordeel Eenvoudiger beheer Lagere beheerkosten door eenvoudiger beheer Eenvoudiger te beveiligen tegen virussen en andere 'malware' Betere fysieke beveiliging Lagere hardwarekosten Lagere bandbreedtebehoef te in het netwerk Grotere flexibiliteit en schaalbaarheid Beperken van de wildgroei van applicaties Centrale inrichting van beheer Grotere flexibiliteit werkplek Beter voor het milieu Grotere flexibiliteit fysieke organisatie Toelichting Applicaties en gegevens staan op centrale servers, zodat upgrades en versiebeheer op één plaats kan plaatsvinden in plaats van op alle werkplekken. Rationalisatie van applicaties vindt op min of meer natuurlijke wijze plaats. Bovendien draaien de applicaties in een meer gestandaardiseerde omgeving Het beheer kan zich grotendeels richten op de centrale servers in plaats van op lokale werkplekken en applicaties. Er zijn dus minder decentrale 'points of failure' in de organisatie. Beheerders zijn minder tijd kwijt met oplossen van storingen in de organisatie als gevolg van het feit dat ze hun aandacht alleen op de centrale servers hoeven te richten Gebruikers hebben geen eigen applicaties draaien en kunnen geen bestanden op een eigen computer zetten. Er hoeft maar op één plaats een up-to-date beveiliging ingericht worden (firewall, spamfilter, et cetera Door de centrale opstelling is fysieke beveiliging van applicaties en bedrijfskritische gegevens beter te realiseren en heeft de organisatie meer greep op ICT continuïteit Thin clients zijn goedkoper dan volwaardige pc's ('fat clients'). Bovendien raken ze minder snel verouderd Thin clients gebruiken minder bandbreedte op het netwerk, omdat alleen de informatie van beeldscherm, toetsenbord en muis over de lijn gaan. Er worden geen grote bestanden getransporteerd Het toevoegen van gebruikers met thin clients is snel en eenvoudig omdat (uitzonderingen daargelaten) geen werkplekspecifieke zaken moeten worden geïnstalleerd. De oplossing is schaalbaar door servers bij te plaatsen Gebruikers of afdelingen kunnen zelf geen applicaties installeren. Dit voorkomt dat er buiten systeembeheer om nieuwe applicaties of nieuwe versies worden geïnstalleerd Met dezelfde capaciteit kan veel hogere kwaliteit geleverd worden. De beheerders hoeven namelijk bijna geen werkzaamheden op andere locaties dan de centrale locatie uit te voeren Thin clients zijn niet persoonsgebonden. Dit verhoogt de flexibiliteit met betrekking tot werkplekken: thin clients ondersteunen flexplekken. Iedere werkplek is hetzelfde omdat er geen applicaties lokaal draaien en geen gegevens lokaal zijn opgeslagen. Door de introductie van SBC is ook het fenomeen flexplekken ingevoerd. Dit kan overigens gelden voor één of meerdere locaties van een organisatie Thin clients zijn kleiner en verbruiken minder energie dan fat clients. Dit is goedkoper in gebruik en beter voor het milieu SBC kan een organisatie die in beweging is de flexibiliteit bieden die nodig is. Doordat de applicaties en data centraal staan, is het relatief eenvoudig om nieuwe locaties te ontsluiten of om verhuisbewegingen te ondersteunen. Dit is met name relevant bij (gemeentelijke) samenwerkingsverbanden of herindelingen. SBC is een uitstekend middel voor organisaties die een geografische spreiding vertonen. Dit kunnen locaties zijn van één juridische eenheid of locaties van juridisch gescheiden organisaties Copyright 2007 Verdonck, Klooster & Associates B.V. 5

Vanzelfsprekend zijn er niet alleen voordelen aan het gebruik van SBC. Er kleven ook nadelen aan het gebruik ervan en in sommige situaties is het gebruik zelfs niet mogelijk. De belangrijkste nadelen zijn: Nadeel Niet goed geschikt voor zware toepassingen Kwijtraken van functionaliteit door de gebruiker Anders organiseren van printfunctionaliteit Toelichting Grafisch veeleisende en rekenintensieve applicaties zijn niet geschikt om middels SBC te ontsluiten. Binnen het domein van lagere overheden bestaan typische 'zware' applicaties waarvoor een oplossing gezocht moet worden. Hierbij kan met name gedacht worden aan CAD en GIS applicaties, die binnen gemeenten, provincies en waterschappen veel gebruikt worden. Ook streaming video is niet geschikt om via SBC ontsloten te worden. Dergelijke applicaties en content moeten op zogenaamde fat clients draaien In een situatie waarin iedere medewerker een eigen PC heeft, kan deze CD- ROM's en USB-sticks gebruiken. Verder kan de medewerker vaak zelf applicaties installeren en eigen data beheren. Met SBC raakt de medewerker deze rechten (grotendeels) kwijt. Dit levert vaak weerstand op binnen de organisatie. Medewerkers moeten op een andere manier met hun werkplek om leren gaan. Het is geen Personal Computer meer, maar een werkstation dat met anderen gedeeld kan worden. Het is rationeel goed uit te leggen dat een werkstation alleen nog maar gebruikt kan worden voor werkdoeleinden, maar het gevoel dat er rechten zijn 'afgepakt' is daarmee nog niet weggenomen. Het belang van goede printfunctionaliteiten wordt vergroot bij de introductie van SBC. Het maken van een afdruk impliceert het verzenden van grote bestanden. Het verzenden van deze bestanden, zonder tegenmaatregelen kan een negatief effect hebben op de performance van het netwerk Copyright 2007 Verdonck, Klooster & Associates B.V. 6

3 Opbouw van een business case De logisch opeenvolgende onderdelen van een business case document met een specifieke focus op het onderwerp SBC bij lokale overheden worden in dit hoofdstuk per onderdeel verder uitgewerkt. 3.1 Introductie In dit hoofdstuk wordt eerst de aanleiding of achtergrond voor het maken van de business case toegelicht. In het geval van SBC kan dit bijvoorbeeld liggen in een samenwerking van lokale overheden met dezelfde of juist verschillende desktop-eisen, in de vorming van een shared service center binnen of tussen overheden, in een gewenste nieuwe manier van werken en bijbehorende cultuur, of in herziening van de ICT-architectuur op basis van flexibiliteits- of continuïteitseisen die nieuwe technologie mogelijk maakt. Vervolgens worden de opdrachtgever of opdrachtgevers (beslissers) vermeld, en eventueel hun vertegenwoordigers. Dit zijn meestal degenen die de beslissing gaan nemen, of anders degenen die het business case document gaan gebruiken. Bijvoorbeeld de gemeentesecretaris, directeur Bedrijfsvoering of hoofd ICT. Dan worden de namen, afdelingen en functies van de opdrachtnemer(s), overige opstellers en eventuele reviewers vermeld. Bijvoorbeeld (extern) adviseur, informatieanalist, controller etc. Deze worden expliciet genoemd, omdat elke business case gebaseerd is op subjectieve oordeelsvorming en onzekere projecties. De lezer krijgt daarmee een beeld vanuit welke invalshoeken (bijv. klantkant, personeel, logistiek ICT-strategie, etc.) de business case is opgesteld. Tevens wordt kort de opdracht van opdrachtgever aan opdrachtnemer, gekoppeld aan de investeringsdoelstelling, beschreven. Het is belangrijk daarbij de business case vraagstelling (onderbouwing van een go/no-go, "wenselijkheid" of "waarom") te onderscheiden van de definitiestudie ("hoe zouden we het moeten doen") en de haalbaarheidsstudie ("is het mogelijk, kan het en/of wat belemmert ons?"). Na de positionering van aanleiding en de spelers worden het onderwerp en de context verder toegelicht. Er wordt een definitie van SBC gegeven en van wat dat betekent binnen de ontwikkelingen van de specifieke lokale overheid: wat gebeurt er in de externe (politieke) context, zoals gemeentelijke herindeling, e-overheidsinitiatieven vanuit Den Haag (65% elektronische dienstverlening, basisregistraties), begrotingsproblemen en wat gebeurt er in de interne context: van sectormodel naar directiemodel, invoering van flexwerken, 'verglazing' van het netwerk, veranderprogramma's, andere IT-projecten etc. Hier moet worden uiteengezet waarom SBC bijdraagt aan deze ontwikkelingen. Tevens moet hier de gevolgde methodiek voor de lezer(s) worden toegelicht. Afhankelijk van de omvang en indeling van het business case document kan men besluiten tot het opnemen van een managementsamenvatting en een leeswijzer. In elk geval dient in de bijlage of in het eerste hoofdstuk een bronvermelding van documenten en gesprekken te worden opgenomen. Copyright 2007 Verdonck, Klooster & Associates B.V. 7

3.2 Uitgangspunten In dit hoofdstuk wordt geformuleerd welke informatie bekend moet zijn voor zowel de huidige als de toekomstige situatie. Dit betreft de 'bouwstenen' van een business case voor SBC. Daarnaast kan voor de beeldvorming van de lezer een korte schets gegeven worden van de huidige situatie, waarin aspecten die niet wijzigen maar wel worden geraakt, uiteen worden gezet, zoals de organisatiestructuur, andere lopende projecten etc. Er moeten bij de uitgangspunten door de opdrachtgever of door materiedeskundigen uitspraken worden gedaan over de volgende onderwerpen: 1. Aantal locaties en typen locaties 2. Aantal werkplekken; 3. Typen werkplekken; 4. Netwerk en printen; 5. Beveiliging; 6. Applicaties; 7. ICT financiën. 3.2.1 Locaties De lokale overheid is vaak georganiseerd op verschillende locaties. Als de lokale overheid SBC toepast, kan elke ambtenaar zijn of haar werk doen vanaf iedere PC in het netwerk, ongeacht op welke locatie deze zich bevindt. De locaties zijn onderling verbonden door netwerkverbindingen. Omdat de benodigde bandbreedte van de netwerkverbindingen een belangrijke kostenfactor is, moet vooraf worden vastgesteld op hoeveel locaties gewerkt moet kunnen worden. Het is tevens belangrijk te benoemen of er ook 'dislocaties' zijn, in dit verband locaties die niet rechtstreeks aangesloten zijn op het netwerk en dat ook niet direct zullen worden. De dislocaties kunnen beschouwd worden als telewerklocaties die met een breedbandverbinding via internet worden aangesloten op het netwerk van de lokale overheid. Hiervoor worden vaak standaard (A)DSLverbindingen gebruikt. Voor de werkplek wordt op dislocaties vaak gebruik gemaakt van een standaard werkstation dat geschikt is voor Kantoorautomatiserings- of KA applicaties en enkele specifieke applicaties die ontsloten worden via SBC. Als iets wijzigt in het aantal dislocaties, dienen de (relatieve) kosten en opbrengsten daarvan in de business case meegenomen te worden. 3.2.2 Aantal werkplekken Per locatie moet bepaald worden hoeveel werkplekken er beschikbaar moeten zijn. Door het concept van flexibel werken is het vaak mogelijk het aantal werkplekken terug te brengen 3. Vooral mensen met een buitendienstfunctie maken beperkt gebruik van hun werkplek, waardoor er een besparing op zowel fysieke ruimte als apparatuur mogelijk is. Omdat de verdeling van kostencomponenten over desktop-, server-, netwerk- en beheerkosten voor een fat client heel anders zijn dan voor een thin client, is de afname van het aantal werkplekken niet direct te kwantificeren. Deze komt terug in de overall kostenverdeling van de ICT-functie (zie ook paragraaf 3.5). Naast de hardwarekosten van de 3 Het is aan de specifieke lokale overheid hoe ver de filosofie van flexibel werken wordt doorgevoerd in werkwijzen en cultuur, zie bijv. ook http://nl.wikipedia.org/wiki/interpolis Copyright 2007 Verdonck, Klooster & Associates B.V. 8

werkplek zelf beïnvloedt het aantal werkplekken bij SBC met name de benodigde bandbreedte en dus de netwerkkosten. 3.2.3 Typen werkplekken Voor een kostenminimalisatie is het noodzakelijk de werkplek zoveel mogelijk te standaardiseren. We onderscheiden daarbij de volgende typen werkplekken: Type werkplek Standaardwerkplek Fat client Mobiele werkplek Overige typen werkplekken Toelichting "De" standaardwerkplek bij een lokale overheid bestaat vaak uit KAapplicaties (zoals MS-Office) en vakspecifieke (burgerzaken, belastingen, ruimtelijke ordening etc.) applicaties in de backoffice. Deze standaard werkplek is vaak geschikt voor de het grootste deel van de medewerkers Er is vaak behoefte aan enkele werkplekken met een fat client inrichting vanwege de gevraagde lokale verwerkingscapaciteit of grafische mogelijkheden. Denk hierbij aan werkstations waarop CAD- en GISapplicaties draaien, of aan invoerstations voor postverwerking en andere varianten op document management. Als door deze applicaties veel bandbreedte voor uitwisseling met serverprogrammatuur en databases wordt gevraagd, verdient het aanbeveling deze zo dicht mogelijk bij de back-end onder te brengen, d.w.z. praktisch in het LAN waarop ook de serverruimte is aangesloten Lokale overheden stellen steeds meer medewerkers in de gelegenheid om een deel van hun werk buiten het eigen kantoor te verrichten. Het gaat hierbij om telewerken, werken op meerdere locaties of 'in het veld' werken. Voor deze medewerkers worden mobiele werkplekken ingericht. Voor de verbinding met het netwerk van de organisatie wordt veelal gebruik gemaakt van snelle mobiele datacommunicatietechnologie, zoals UMTS of HSDPA. Mobiele werkplekken zijn uitstekend in te vullen met behulp van SBC. De geboden bandbreedte met de genoemde technieken is ruim voldoende om SBC te kunnen bieden. Bovendien biedt SBC een extra beveiliging, waar mobiele werkplekken juist een extra risico introduceren: een laptop of ander apparaat waar data op is opgeslagen is kwetsbaarder voor verlies of diefstal. Door het gebruik van SBC kan ervoor worden gezorgd dat er geen data op het apparaat staat, waardoor er geen gevoelige informatie op straat komt te liggen. Overige 'afwijkende' typen werkplekken zijn de eerder genoemde dislocaties met remote access tot het netwerk en (draagbare) werkplekken voor ICT-beheerders Vaak zal men naast de standaardwerkplek dus zo'n vier typen werkplekken onderscheiden. De typen moeten worden uitgeschreven in detailspecificaties. De 'afwijkende' typen werkplektypen moeten als aparte, vergelijkbare kostenposten in de business case worden opgenomen om verschillende mogelijkheden vergelijkbaar te maken. Copyright 2007 Verdonck, Klooster & Associates B.V. 9

3.2.4 Netwerk & printen Bandbreedte In de business case moet voor de verschillende desktopconcepten worden aangegeven wat de benodigde bandbreedte tussen de verschillende locaties is, op basis van meetgegevens. Vaak blijkt daar enerzijds uit dat enkele Mbps voldoende is voor het grootste deel van de tijd. Maar er blijken ook pieken voor te komen van tot 25 Mbps. Extra metingen zijn dan nodig om een reële schatting te kunnen maken van de vereiste bandbreedte. Hierbij dient men rekening te houden met het feit, dat de vereiste bandbreedte voor een groot gedeelte bepaald wordt door de omvang van bestanden, die in dit concept over het netwerk worden verplaatst tussen de client en server. De omvang van de vereiste bandbreedte kan in de toekomst aanzienlijk groeien door gebruik van multimedia (combinatie van geluid en beeld) waardoor de kans groot is, dat men in de nabije toekomst tegen de grenzen van de capaciteit van de netwerkverbinding zal lopen. Indien men de bandbreedte te krap kiest, kan men klachten verwachten van de gebruikers in het bestuurcentrum, die in het algemeen weinig affiniteit hebben met techniek. Printen Daarnaast moeten er duidelijke keuzes worden gemaakt ten aanzien van printen. Het 'paperless office' is tot nu toe steeds een illusie gebleken. De grootte van printopdrachten legt bij veel gebruikers op afstand veel beslag op de lijncapaciteit die nodig is voor het SBC applicatieverkeer, zelfs indien met de netwerkleverancier wordt afgesproken het SBC-verkeer voor te laten gaan (Quality of Service). Het alternatief hiervoor is een extra lijn aan te leggen voor printverkeer. Om de impact van dit aspect te bepalen, moet onderzocht moet worden hoeveel netwerkverkeer het huidige printgedrag en het in de toekomst verwachte printgedrag zal genereren. 3.2.5 Beveiliging Gevoelige gegevens staan bij de gewone applicaties nog vaak op het werkstation van de medewerker en als de medewerker regelmatig zijn gegevens backupt ook op een netwerkschijf. Alle gegevens worden bij SBC op een centrale server opgeslagen. Omdat er op de desktop in het geval van SBC geen gegevens meer permanent aanwezig zijn, is het nog belangrijker dan anders de uitwijk van de serverdata goed te regelen. Er moet worden vastgesteld hoe uitwijk voor de kritische systemen zal plaatsvinden, met welke contracten en leveranciers dat plaatsvindt en in hoeverre dit verschilt met de huidige situatie. 3.2.6 Applicaties In principe veranderen de applicaties die de medewerkers gebruiken niet. Het is belangrijk om te bepalen of de applicaties wel via SBC te gebruiken zijn. Als dit niet zo is, dan moet er voor die applicaties een alternatief worden gezocht. Vaak is de oplossing hiervoor een extra fat client, een tweede type applicatieserver, een complexere SBC architectuur of toepassing van extra virtualisatiesoftware. In elk geval dus een duurdere oplossing. Het is dan ook handig bij de inventarisatie van de huidige situatie de volgende zaken in kaart te brengen: Applicatienaam; Versie; Clientuitvoering (fat client / plug-in in browser / ICA-clients / n.v.t.); Copyright 2007 Verdonck, Klooster & Associates B.V. 10

Platform (server /webserver / SBC / desktop); SBC mogelijk? (ja / nee); Aantal gebruikers; Toekomstige locatie. 3.2.7 ICT financiën Als uitgangspunt voor het financiële deel van de business case wordt gekeken naar de huidige kostenstructuur en kostenomvang van de ICT-functie. Er wordt daarbij meestal onderscheid gemaakt tussen de volgende terugkerende kostencomponenten: Hardware; Software; Personeel; Diensten. Vaak zijn deze componenten verder onderverdeeld naar specifiekere kostencomponenten, zoals desktops, servers, licenties, opleiding etc. De nieuwe, gewenste situatie moet financieel vergelijkbaar zijn met de huidige situatie en dus op basis van dezelfde kostenstructuur worden beoordeeld. Als de huidige ICT-kosten niet goed of niet voldoende gedetailleerd worden geadministreerd, is het lastig de gewenste situatie hiertegen af te zetten. Men moet dan afwegen hoeveel onderzoek men hiernaar wil verrichten om de kennis te verkrijgen die nodig is om de onderbouwing voor SBC te kunnen maken (cost of costing 4 ). 3.3 Investeringskader In dit hoofdstuk wordt aangegeven wat er wel en niet bij de investering in SBC behoort (scope), hoe breed er naar oplossingen wordt gezocht en hoe men tot een beslissing gaat komen. Deze onderdelen worden hieronder kort uitgewerkt. Scope Op basis van de investeringsdoelstelling, zoals het vergroten van efficiency of het introduceren van flexibel werken wordt bepaald wat er wel of niet tot de reikwijdte van de investeringen en het implementatieproject behoort. Aanpalende initiatieven of randvoorwaarden kunnen immers de resultaten van de business case beïnvloeden. Zo moet besloten worden: Wat de diepgang van het globaal ontwerp is, op basis waarvan men tot een beslissing kan komen; Of de SBC omgeving een vergelijkbare functionaliteit biedt als de huidige, of dat er tegelijkertijd nieuwe implementaties van applicaties (al dan niet SBC-compliant) plaatsvinden; Welk deel van de investeringen in en gebruik van het netwerk behoren tot de SBCimplementatie en welke tot andere initiatieven; Welk deel van meer algemene migratiekosten (bijv. migratie naar één serverruimte bij een fusie) toegerekend worden naar de SBC implementatie; 4 Zie hiervoor ook "Kosten, baten en risico's van ICT-investeringen" Copyright 2007 Verdonck, Klooster & Associates B.V. 11

Wat de financiële beschouwingstermijn is: moet de investering in 1-2 jaar terugverdiend worden, of mag dit ook langer duren vanuit het perspectief van doorslaggevende kwalitatieve baten? Oplossingenrange In theorie kunnen we onderscheid maken tussen ja/nee business cases en alternatievenanalyses. In het geval van een ja/nee business case wordt investering X alleen afgewogen tegen het nulscenario. De nadruk ligt op besluitvorming over de investering en het onderwerp an sich. Bij een alternatievenanalyse worden verschillende scenario's uitgewerkt en beoordeeld, waarbij de nadruk ligt op het implementatietraject. Bij de implementatie van SBC zullen vaak meerdere scenario's die tussen een volledige fat client variant en een volledige SBC variant in liggen, worden onderscheiden. Het aantal scenario's dient een uitvloeisel te zijn van datgene waarop de beslissers kunnen sturen (zijn scenario's met bijvoorbeeld 20% SBC, 40%SBC en zo verder wel zinvol, of kan men beter onderscheid maken tussen 100% fat clients, mixed omgeving met minimaal aantal fat clients en 100% SBC?). Beslissingscriteria In deze paragraaf wordt uitgewerkt op basis waarvan men een beslissing gaat nemen over de scenario's. In de praktijk zal dit altijd een mix van kwalitatieve en kwantitatieve aspecten betreffen. Hieronder is een praktisch en redelijk compleet voorbeeld van criteria gegeven: Kwalitatief Criterium Mate van flexibel werken (hoog/laag) Beveiliging (matig / gemiddeld / goed) Business continuity management (matig / gemiddeld / goed) Toelichting In welke mate maakt de nieuwe architectuur het werken op meerdere locaties mogelijk? In welke mate zorgt SBC ervoor dat de omgeving veilig is, doordat gevoelige informatie niet lokaal op de client kan worden opgeslagen? In welke mate zorgt de architectuur waarbij alle data centraal wordt opgeslagen (met uitwijkvoorziening inclusief een externe opslag van back-up gegevens) voor continuïteit van de bedrijfsvoering? Copyright 2007 Verdonck, Klooster & Associates B.V. 12

Kwantitatief Criterium Benodigde investering en desinvestering5 (en afschrijftermijnen) in hardware en software Benodigde investering in netwerk (bandbreedte) Benodigde investering in opleidingen Benodigde migratieinspanning (projectkosten) Verminderde (jaarlijkse) beheerinspanning Toelichting Afhankelijk van de leeftijd van het machinepark: hoeveel hardware moet er extra / nieuw worden aangeschaft en over welke periode wordt dit afgeschreven? N.B. hierbij moet goed gekeken worden naar de herbruikbaarheid van en het achterstallig onderhoud op hard- en software Hoeveel lijnen of extra bandbreedte is noodzakelijk voor SBC en wat kost dat? N.B. hierbij moet goed beoordeeld worden welke investeringen toe te rekenen zijn aan de SBC-implementatie en welke investeringen sowieso gedaan moeten worden Hoe groot is de benodigde verandering in kennis & expertise bij de beheerders en gebruikers? Hoeveel kost het migratieproject en is dit niet buiten proportie in verhouding tot de jaarlijkse beheerlasten (voor 20 werkplekken loont het de moeite waarschijnlijk niet) In welke mate vermindert het decentrale beheer van desktops (FTE)? N.B. hierbij dient alleen gekeken te worden naar de kostenposten die veranderen door de inzet van nieuwe technologie (relatieve business case), niet naar wat gelijk blijft Afhankelijk van de specifieke situatie van de lokale overheid, kunnen deze criteria aangevuld en gewogen worden toegepast. 3.4 Globaal ontwerp Afhankelijk van de keuze voor een ja/nee afweging danwel een keuze uit meerdere scenario's, worden in dit hoofdstuk één of meerdere ontwerpen voor een (mixed) SBC omgeving weergegeven. Hierin worden in elk de aantallen en functionaliteit van een desktopomgeving, server omgeving, en netwerkomgeving uitgewerkt. Desktopomgeving Hierin wordt de invulling beschreven van: Aantal werkplekken, werkplektypen en merk/typenummer per locatie; Office-pakket (e-mail, agenda, tekstverwerker, spreadsheet en presentatieprogramma) ; Applicatie om pdf-documenten te lezen; Internetbrowser; Applicatie voor het comprimeren en decomprimeren van bestanden; Anti-virus pakket; Lokaal draaiende (zware) applicaties bij fat clients; Operating system; Hardware (en aantal typen, met preferred suppliers hiervoor). N.B. Randapparatuur zoals beeldscherm, toetsenbord en muis zijn niet afhankelijk van het desktopconcept. 5 Fat clients kunnen tot het einde van hun economische (of zelfs technische) levensduur ook als thin client worden ingezet Copyright 2007 Verdonck, Klooster & Associates B.V. 13

Serveromgeving Hierin wordt de invulling beschreven van: Locatie en voorzieningen serverruimte; Aantallen en typen fileservers; Aantallen en typen database servers; Aantallen en typen webservers; Aantallen en typen Exchange servers (inclusief DC, DHCP en DNS); Aantallen en typen SBC servers (inclusief interne applicaties); Aantallen en typen midrange systemen (bijv. AS/400); DVD towers; VPN appliances voor aansluiten VPN-verbindingen naar dislocaties. Netwerkomgeving Hierin wordt de invulling beschreven van: Aansluitingen van desktops op LAN of internet ; Bandbreedte (benodigd) per verbinding: bij het bepalen hiervan moeten zowel gemiddelde waarden als piekbelastingen in overweging worden genomen; Beveiligingsmaatregelen per verbinding: dislocaties via het internet moeten apart beveiligd worden; Hoe men omgaat met printen: als een verbinding een beperkte capaciteit heeft, kan een printopdracht het werk van alle medewerkers op die locatie verstoren. Dit is te voorkomen door de bandbreedte voor het printen te beperken 6. Dit betekent dat printopdrachten veel tijd in beslag kunnen nemen. 6 Citrix heeft hiervoor een white paper opgesteld Copyright 2007 Verdonck, Klooster & Associates B.V. 14

Een samenvatting van desktop-, server- en netwerkomgeving kan worden gegeven in een afbeelding die tevens de samenhang van het ontwerp aantoont, zie Figuur 2 voor een voorbeeld van een mixed SBC concept: Figuur 2: Voorbeeld mixed SBC concept 3.5 Kosten, baten en financiële analyse Als er een ontwerp is opgesteld voor de toekomstige situatie, kunnen de verschillen met de huidige situatie financieel worden gemaakt. We onderscheiden hierbij kosten en baten. Binnen de overheid zullen baten meestal niet betekenen dat er grotere opbrengsten worden binnengehaald, maar vooral dat door te investeren (in dit geval in een specifieke technologie met alles daaromheen) er uitgavenbesparingen, gewenste functionaliteiten en kwaliteitsverbeteringen te behalen zijn. Kosten Voor een zuivere financiële beoordeling moet een onderscheid gemaakt worden tussen kosten (boekhoudkundig, achteraf) en uitgaven (werkelijke cash flow). Kosten zijn immers vastleggingen van uitgaven die achteraf zijn toegerekend aan kostenplaatsen (bijv. afdelingen). In een business case spreken we dus altijd over uitgaven (dit zijn soms extrapolaties van kosten, maar alleen te gebruiken omdat er niet meer gegevens beschikbaar zijn). Bij investeringen in de toekomst gaat het bovendien om daadwerkelijke liquide middelen die op een zeker tijdstip beschikbaar moeten zijn. Dit is in die zin voor lokale overheden relevant, dat de uitgavenplanning verwerkt moet worden als post "investeringen" in de (meerjaren)begroting. Als de investering relatief groot is, kan het zijn dat er niet Copyright 2007 Verdonck, Klooster & Associates B.V. 15

voldoende werkkapitaal is en moet er vreemd vermogen met een rentevoet ('cost of capital') worden aangetrokken 7. De kwantitatieve verbeteringen van SBC zijn in kaart te brengen door het vergelijken van de uitgaven als de huidige situatie geëxtrapoleerd wordt, met de verwachte uitgaven na realisatie van de nieuwe situatie. Het is belangrijk hierbij te kijken naar die uitgavencomponenten waarbij een verschil optreedt. Meestal wordt gebruik gemaakt van de terugkerende componenten hardware, software en personeel & diensten waarop een vermindering optreedt, alsmede de eenmalige posten opleiding en overige migratiekosten waarop een plus geboekt wordt, zie ook Figuur 3. Figuur 3: Kostenontwikkeling bij verschillende SBC scenario's N.B. Voor ICT-middelen kan men het tijdstip van de uitgaven beïnvloeden door in het vervangingsbeleid onderscheid te maken tussen de economische levensduur (afschrijvingen, dus kosten als periodiek percentage van de uitgaven) en de technische levensduur (na afschrijving geen periodieke kosten meer). Dit is voor SBC mogelijk van belang bij langer gebruik van een economisch afgeschreven fat client als thin client. Bij de inventarisatie is de bestaande apparatuur (installedbase) dan ook een belangrijke kostenbeïnvloedende factor. Baten De kwalitatieve verbeteringen maken de toegevoegde waarde van een investering inzichtelijk, door hun bijdrage aan de business drivers (doelstellingen) van de organisatie, bijvoorbeeld flexibel werken (de kwalitatieve voordelen van SBC zijn reeds uitgewerkt in hoofdstuk 1). Door het expliciet maken van de verbinding tussen veranderingen en doelstellingen, zullen investeringen breder worden gedragen en versterkt door het wederzijds begrip binnen de organisatie, zie het voorbeeld batenraamwerk in Figuur 4. Bovendien kan er beter worden gestuurd op eindresultaat en realisatie van verwachte baten. 7 Hoewel deze rentevoet voor de vergelijkbaarheid voor interne financiering ook moet worden gehanteerd, is er in de praktijk vaak sprake van een werkkapitaal waaraan geen separate aantrekkingsinspanning verbonden is (hooguit een rentederving). Copyright 2007 Verdonck, Klooster & Associates B.V. 16

Figuur 4: Voorbeeld batenraamwerk SBC De kwantitatieve baten bestaan uit de reductie van uitgaven aan ICT-middelen, personeel en diensten door de inzet van SBC. Na kwantificering kunnen deze baten financieel worden gemaakt en opgenomen worden in de financiële analyse. Dit betreft bijvoorbeeld besparingen in FTE's (mensuren x tarief / uren per jaar), hardware (aantal werkplekken x (kosten fat client -/- kosten thin client) etc. Financiële analyse Alle eenmalige en (differentiële) terugkerende uitgaven worden opgenomen in een meerjarig rekenmodel. Op basis van de 'inwaartse cashflow' (besparing ten opzichte van de baseline) en uitgaande cashflow (extra uitgaven) kan een financiële analyse worden uitgevoerd door het berekenen van ratio's als de return on investment (roi), de terugverdientijd en de netto contante waarde 8. Hiermee kan bijvoorbeeld direct duidelijk worden dat inhuur van externe partijen voor de migratie (vanwege interne capaciteitsproblemen) de business case negatief kan beïnvloeden (de 'bult' in de grafiek van Figuur 3. Ook de terugkerende netwerkkosten kunnen behoorlijk snel oplopen bij een groeiend aantal dislocaties. Tevens kan in het rekenmodel een gevoeligheidsanalyse worden ingebouwd, bijvoorbeeld: is de baseline een voortzetting van de huidige situatie of moet men de besparingen door SBC bekijken ten opzichte van een situatie waarbij veel meer dan nu gebruikt wordt gemaakt van het netwerk, functionaliteit etc. De geprojecteerde besparingen kunnen dan navenant toenemen. N.B. In het rekenmodel moet een duidelijk tabblad met aannames en uitgangspunten zijn opgenomen, zodat de projecties transparant blijven en niet werken als een doos met financiële goocheltrucs. 8 Zie voor de zin en onzin van de financiële ratio's "Kosten, baten en risico's van ICT-investeringen" Copyright 2007 Verdonck, Klooster & Associates B.V. 17

3.6 Risico's en maatregelen De risico's kunnen voor een deel financieel worden ingebouwd in het rekenmodel door de aannames dynamisch te maken. Typische risico's die de gewenste uitkomsten (negatief of positief) bedreigen en de maatregelen daartegen zijn: Onbeschikbaarheid en/of onbetrouwbaarheid van de juiste cijfers die leiden tot verkeerde aannames en uitkomsten. Dit is te ondervangen door een extra inspanning ter verrichten om deze cijfers boven tafel te krijgen. Men moet daarbij afwegen welke kosten men in de inventarisatiefase wil maken, voordat men voldoende vertrouwen heeft in de uitkomsten. Applicaties die niet ontsloten kunnen worden via SBC: als dit voor een groot aantal niet mogelijk is, komt men snel in een 'mixed' omgeving. Dit kan worden ondervangen door te starten met een proof-of-concept. Ontevredenheid bij gebruikers door slechte performance van bijvoorbeeld streaming video. Dit is te ondervangen door voldoende tijd en aandacht in te bouwen voor verwachtingsmanagement. Door de schaalvergroting worden problemen als slecht werkende servers of disfunctionerende software ook uitvergroot. Het effect is namelijk direct merkbaar voor alle gebruikers. De tegenmaatregel is een vastgestelde software en hardware architectuur met duidelijke eisen, in combinatie met voldoende tijd en aandacht voor het testen. Werkbaarheid en acceptatie bij beheerders. Dit is te ondervangen door de nieuwe, meer gedisciplineerde manier van werken vooraf goed te communiceren en te bespreken. Alle klassieke projectrisico's (beschikbaarheid, bestuurlijk commitment, kwaliteit etc.): te ondervangen door een juiste projectbesturing. 3.7 Conclusies en aanbevelingen In dit hoofdstuk van de op te stellen business case worden de verschillende scenario's voor desktopconcepten schematisch naast elkaar gepresenteerd en vergeleken aan de hand van de verschillende gestelde criteria. Hierbij worden zowel kwantitatieve als kwalitatieve uitkomsten vermeld, zodat de beslissers tot een totaalindruk en een afgewogen keuze kunnen komen, zie ook het voorbeeld in Figuur 5. Copyright 2007 Verdonck, Klooster & Associates B.V. 18

Beslissingscriteria Concept 1 Conventioneel Investering hardware en software Afschrijftermijnen clients Beheer Opleidingen beheer SBC Vereiste bandbreedte Flexibel werken Beveiliging Migratie inspanning Business Continuity Management Concept 2 SBC Bedragen in euro's Termijnen in jaren Omvang in aantallen FTE Prijs per (schaarse) FTE Bedragen in euro's Omvang in Mbps Laag/midden/hoog Slecht/matig/goed Laag/midden/hoog Slecht/matig/goed Concept 3 Mixed Totaalindruk Algemene impressie Figuur 5: Tabel keuzecriteria SBC De beste optie en de verschillen met de andere opties worden hier kort toegelicht, aangevuld met eventuele aanbevelingen. Dit zijn typisch ook de overzichten die kunnen worden opgenomen in de managementsamenvatting van de business case. 3.8 Migratieplan op hoofdlijnen De business case bevat ook een migratieplan op hoofdlijnen, zodat de beslissers een beeld hebben van de (directe) 'next steps' die volgen op een 'go'. Deze bestaat op hoofdlijnen uit de fasen inventarisatie, proof-of-concept en implementatie. In de inventarisatiefase worden de huidige omgeving gedetailleerd in kaart gebracht. Daarna (of tegelijkertijd) wordt samen met de leverancier een (vanwege zuiverheid met aanbestedingsregels betaalde) proof-of-concept fase uitgevoerd op basis van het globaal ontwerp. Deze fase omvat het inrichten van servers, netwerk, applicaties, clients en het testen en meten daarvan. Dit leidt tot een bijgestelde business case en een pakket van eisen (bestek), dat geschikt is voor een offerteaanvraag. Vervolgens vindt de implementatie plaats. Hierin worden het netwerk en de servers ingericht, worden eerst de applicaties gemigreerd, vervolgens de user en groepsdata en worden de nieuwe desktops uitgerold. Voor de beheerorganisatie zijn er ook aandachtspunten bij de implementatie van SBC. Er zullen in veel gevallen strengere procedures moeten worden ontwikkeld voor beheerprocessen als configuration management en change management. Bij bijvoorbeeld upgrades is het niet zo dat er één computer tijdelijk niet gebruikt kan worden, maar dat alle werkplekken in onderhoud zijn. Tegelijkertijd is het zo, dat bij SBC juist de mogelijkheid ontstaat om updates onmerkbaar voor de gebruikers te laten uitvoeren. De werklast van de server die wordt geüpdatet, kan immers worden overgenomen door andere servers, mits het update proces zorgvuldig is ingericht om te voorkomen dat gebruikers niet "van de server worden geschopt". Dit betekent dat er uitvoeriger moet worden Copyright 2007 Verdonck, Klooster & Associates B.V. 19

getest, gepland en gecommuniceerd. Dat is in veel gevallen een nieuwe manier van werken voor de beheerorganisatie. De introductie van deze nieuwe processen van testen en implementeren dient te worden opgenomen in de business case. N.B. De kosten van de migratie worden opgenomen in de financiële analyse van de business case. Copyright 2007 Verdonck, Klooster & Associates B.V. 20

4 Discussiepunten In dit hoofdstuk wordt een aantal onderwerpen uitgewerkt, die regelmatig tot discussie leiden bij het bespreken van SBC. We gaan hier specifiek in op de afbakening van SBC als concept, op beveiligingsaspecten en op de beperkingen van het instrument business case. 4.1 Het SBC-concept Uit het voorafgaande blijkt dat SBC een groot aantal voordelen kan bieden. Voorwaarde om hiervan te kunnen profiteren is wel dat SBC op de juiste wijze ingevoerd wordt, zowel technisch als organisatorisch. De juiste invoering begint met het goed uitwerken van de business case en het vaststellen van scope en doelstellingen. 4.1.1 SBC als breekijzer voor applicatierationalisatie? Bij het fat client concept zijn alle applicaties geïnstalleerd op het lokale werkstation. Bij een inventarisatie vooraf krijgt men overzicht van de bestaande applicaties en dan blijkt vaak dat er een groot aantal verschillende applicaties en soms ook nog verschillende versies hiervan op diverse werkstations zijn geïnstalleerd. Een deel bestaat uit de standaard applicaties die iedereen gebruikt, maar men vindt gegarandeerd bij een aantal medewerkers specifieke applicaties. Vaak is er sprake van functionele overlap, of van applicaties voor een specifieke functie die heel goed door een meer generieke applicatie kunnen worden ondersteund. Vaak kan het aantal specifieke applicaties worden gereduceerd door de wensen en eisen voor een specifieke applicatie te combineren en hiervoor een meer generieke applicatie aan te schaffen. Voordelen van deze applicatierationalisatie zijn: minder onderhoud aan verschillende applicaties en kostenreductie aan licenties. Een andere reden om de applicaties te rationaliseren is het feit dat sommige specifieke applicaties alleen gebouwd zijn voor gebruik op een werkstation en niet zonder meer toegepast kunnen worden in een SBC-omgeving. Vaak gaat het om applicaties die ontwikkeld zijn met onvoldoende aandacht voor de afhankelijkheden van de omgeving waarin de applicatie draait. Dit soort applicaties kan een specifieke versie van het operating system of database server vereisen, exclusief bepaalde resources opeisen. Een SBC-leverancier weet vaak wel welke veel gebruikte applicaties geschikt zijn voor SBC, maar voor specifieke applicaties zit er niets ander op dan dit vooraf te testen. Blijkt een applicatie in een SBC-omgeving niet te werken dan staat men voor de keuze om zo'n applicaties alsnog door de leverancier geschikt te laten maken voor SBC (soms een tijdrovend traject), virtualisatiesoftware toe te passen die binnen de SBC omgeving de applicatie de "illusie" geeft in een conventionele omgeving te draaien of een andere applicatie te kiezen die wel geschikt is voor SBC. Het is zaak dat men hiermee vooraf rekening houdt en tijd reserveert voor deze testen om vertraging bij het invoeren van SBC te voorkomen. Copyright 2007 Verdonck, Klooster & Associates B.V. 21

4.1.2 Thin client: appels en peren? Het begrip thin client zorgt soms voor verwarring. Sommigen verstaan hieronder alleen de client software, terwijl anderen de combinatie van hardware en software als client zien. Software client Iedereen kent wel het client-server concept waarbij op een werkstation een client is geïnstalleerd op het lokale werkstation en de applicatie op een server draait. Er bestaan applicaties waarbij de rekencapaciteit verdeeld is tussen client en server om het dataverkeer tussen client en server te beperken. Een voorbeeld hiervan zijn sommige GIS-applicaties. Alleen in die gevallen waarbij het gaat om een generieke (applicatie-onafhankelijke) client op het werkstation die alleen de userinterface is voor de applicatie die op de server draait, spreekt men van een SBC-omgeving. In die situatie wordt weinig rekencapaciteit gevergd van het werkstation. Verschillende leveranciers leveren thin clients. De meest gebruikte thin clients zijn de Citrix ICAclient en de Microsoft Windows Terminal Services client om een SBC-applicatie te ontsluiten. Soms kan de webbrowser ook opgevat worden als een thin client. In vergelijking met voornoemde clients geven de gewone browsers minder ondersteuning aan de soort directe reactie van de applicatie op de muisbewegingen en toetsaanslagen die gebruikers gewend zijn in de Windows omgeving. Ook is het in het algemeen nodig om een applicatie speciaal te ontwikkelen voor gebruik met een webbrowser, waar SBC omgevingen kunnen werken met gewone Windows applicaties. Een voorbeeld van browser als thin client is het gebruik van webmail. Velen beschouwen webmail ook als een SBC-applicatie. De mail is dan toegankelijk via de lokale browser op het werkstation zonder lokale mail-client. De browser is voor webmail de thin client. Echter niet voor elke applicatie is de browser een thin client! Sommige applicaties maken gebruik van zware plug-ins, ActiveX componenten of Java applets in de browser. Het gebruik van deze plug-ins en applets op het werkstation kan veel lokale rekencapaciteit vragen. In dat geval is zo'n applicatie geen vervanging meer van de user-interface en dan loopt men tegen zeer trage applicaties aan als men deze applicaties als SBC-applicatie inzet op een werkstation dat weinig rekencapaciteit heeft. Microsoft levert ook een software thin client: Windows Terminal Services Client. Dit concept kan in een aantal gevallen ook gebruikt worden voor SBC. Voor een meer complexe architectuur is Citrixclient meer geschikt. Hardware thin client Zoals al aangegeven vergen software thin clients niet veel rekencapaciteit (mits er geen zware plug-ins nodig zijn). Verschillende leveranciers leveren speciale hardware als thin client voor SBC. Bij sommige organisaties die overgaan op SBC komt dan de vraag naar boven: waarom kopen we nieuwe hardware, we hebben toch nog bestaande werkstations die weliswaar verouderd zijn, maar toch voldoende rekencapaciteit hebben om als thin client te dienen? Meestal is het duurder om nieuwe hardware aan te schaffen dan de oude geschikt te maken als thin client voor SBC en is men gauw geneigd om de oude hardware als thin client toe te passen. Alvorens deze beslissing te nemen met men zich wel de volgende vragen stellen: Hoe oud is de afgeschreven hardware en is deze dan nog betrouwbaar genoeg om voor de geplande periode te dienen als hardware platform? Copyright 2007 Verdonck, Klooster & Associates B.V. 22

Wat is de acceptatie van de medewerker voor SBC als hij of zij nog het oude werkstation krijgt (met een beeld van verouderde hardware en vrijheid blijheid met betrekking tot het installeren van allerlei applicaties). Thin client hardware is soms erg compact, de gebruiker houdt meer ruimte over op of onder het bureau. Ervaring met implementatie van SBC bij diverse organisaties geeft aan dat zuinigheid niet altijd tot een betrouwbare SBC-omgeving leidt omdat de hardware steeds vaker defect gaat en dat de medewerkers minder geneigd zijn om het SBC-concept te accepteren omdat in hun perceptie weinig veranderd is. Nieuwe hardware is niet alleen betrouwbaarder, maar geeft de medewerker wel aan dat er iets daadwerkelijk gewijzigd is in het werken met de informatiesystemen. Hierdoor accepteren de medewerkers sneller dit concept. 4.1.3 Glijdende schaal: pure SBC oplossing bij lokale overheden niet mogelijk? We leven niet in een ideale wereld. Dit geldt ook voor SBC. Binnen een organisatie zijn vrijwel altijd applicaties aanwezig die essentieel zijn voor de bedrijfsvoering, maar niet of moeilijk te ontsluiten zijn via SBC (zie ook 4.1.2). Daarnaast kan het voorkomen dat dislocaties binnen een organisatie niet eenvoudig via een snelle verbinding (> 100 Kbps) gekoppeld kunnen worden met de SBCservers. In dat geval spreekt men van een 'mixed' concept. In dit concept is het overgrote deel van de werkstations uitgevoerd als thin client met enkele uitzonderingen. Deze uitzonderingen zijn dan die werkstations die over onvoldoende bandbreedte kunnen beschikken om als SBC-client te kunnen worden ingericht of die werkstations met applicaties die heel veel netwerkverkeer veroorzaken. Om inzicht te krijgen in de gevolgen van invoering van SBC ten opzichte van de bestaande situatie met fat clients moet dan naast de SBC-variant nog een mixed concept in beschouwing worden genomen. Deze variant is dan een omgeving waarbij een optimum gezocht wordt tussen een minimum aantal fat clients met applicaties die niet geschikt zijn voor SBC en een minimale netwerkcapaciteit. Van zo'n mixed omgeving is een groot aantal varianten mogelijk, maar meestal kan men met totaal 3 of 4 varianten, waarbij de in dit white paper uitgewerkt principes (en evt. de ervaring van een vakman) kunnen helpen bij het snel maken van een keuze, zie ook Figuur 6. Figuur 6: Glijdende schaal van SBC varianten Copyright 2007 Verdonck, Klooster & Associates B.V. 23