lees meer - Merijn van der Zalm

FLEXIBEL DE BURGER BEDIENEN MET ICT 

De business case voor server-based computing bij lokale overheden 

VKA white paper 

Merijn van der Zalm 

Christ Reniers 

Pim Schouten 

September 2007

Samenvatting 

White paper 


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 

White paper 


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? 

White paper 


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 server- 

based 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

White paper 


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. 


2 Positionering van onderwerpen 

2.1 Wat is server-based computing? 

White paper 


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. 


White paper 


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. 


White paper 


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 Toelichting 

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 


werkplek 

Beter voor het 

milieu 


fysieke organisatie 

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 


White paper 


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 Toelichting 

Niet goed geschikt 

voor zware 

toepassingen 

Kwijtraken van 

functionaliteit door 

de gebruiker 

Anders organiseren 

van 

printfunctionaliteit 

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 


3 Opbouw van een business case 

White paper 


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. 


3.2 Uitgangspunten 

White paper 


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)DSL- 

verbindingen 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 


White paper 


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 Toelichting 

Standaardwerkplek "De" standaardwerkplek bij een lokale overheid bestaat vaak uit KA- 

applicaties (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 

Fat client 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 GIS- 

applicaties 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 

Mobiele werkplek 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 typen werkplekken 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. 


3.2.4 Netwerk & printen 

Bandbreedte 

White paper 


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.); 


• Platform (server /webserver / SBC / desktop); 

• SBC mogelijk? (ja / nee); 

• Aantal gebruikers; 

• Toekomstige locatie. 

3.2.7 ICT financiën 

White paper 


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 SBC- 

implementatie 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" 


White paper 


• 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 Toelichting 

Mate van flexibel werken (hoog/laag) In welke mate maakt de nieuwe architectuur het 

werken op meerdere locaties mogelijk? 

Beveiliging (matig / gemiddeld / goed) In welke mate zorgt SBC ervoor dat de omgeving veilig 

Business continuity management (matig / 

gemiddeld / goed) 

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? 


Kwantitatief 

Criterium Toelichting 

Benodigde investering 

en desinvestering5 (en 

afschrijftermijnen) in 

hardware en software 

Benodigde investering in 

netwerk (bandbreedte) 

Benodigde investering in 

opleidingen 

Benodigde migratie- 

inspanning 

(projectkosten) 

Verminderde (jaarlijkse) 

beheerinspanning 

White paper 


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 


Serveromgeving 


• Locatie en voorzieningen serverruimte; 

• Aantallen en typen fileservers; 

• Aantallen en typen database servers; 

• Aantallen en typen webservers; 

White paper 


• 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 


• 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 


White paper 


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: 

3.5 Kosten, baten en financiële analyse 

Figuur 2: Voorbeeld mixed SBC concept 

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 


White paper 


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 (installed- 

base) 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). 


White paper 


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" 


3.6 Risico's en maatregelen 

White paper 


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 verwachtings- 

management. 

• 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. 


Beslissingscriteria Concept 1 

Investering hardware en 

software 

Afschrijftermijnen 

clients 

Conventioneel 

White paper 


Concept 2 

Copyright © 2007 Verdonck, Klooster & Associates B.V. 19 

SBC 

Bedragen in euro's 

Termijnen in jaren 

Beheer Omvang in aantallen FTE 

Prijs per (schaarse) FTE 

Opleidingen beheer SBC Bedragen in euro's 

Vereiste bandbreedte Omvang in Mbps 

Flexibel werken Laag/midden/hoog 

Beveiliging Slecht/matig/goed 

Migratie inspanning Laag/midden/hoog 

Business Continuity 

Management 

Slecht/matig/goed 

Totaalindruk Algemene impressie 

Figuur 5: Tabel keuzecriteria SBC 

Concept 3 

Mixed 

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

White paper 


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. 


4 Discussiepunten 

White paper 


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. 


4.1.2 Thin client: appels en peren? 

White paper 


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 ICA- 

client 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 Citrix- 

client 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? 


White paper 


• 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 SBC- 

servers. 

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 


4.2 Beveiliging: is SBC veiliger? 

White paper 


In de laatste tijd verschijnen steeds meer berichten in de pers dat gevoelige informatie van 

overheidsorganisaties onbedoeld op straat is gekomen. server-based Computing zorgt voor een 

inherent veiliger omgeving, omdat gevoelige informatie niet lokaal op de client kan worden 

opgeslagen. SBC heeft tevens als voordeel dat alle data centraal wordt opgeslagen en kan worden 

geback-upt. Daarnaast hoeft men maar op één plaats patches en virusupdates aan te brengen, 

mits de browser op en centrale servers draait. Draait de browser voor het internet op de thin client, 

dan moet je net zo alert zijn op virussen op het werkstation als voorheen. 

Deze situatie kent ook kanttekeningen. De centrale aanpak heeft wel tot gevolg dat hierdoor een 

single point of failure kan ontstaan. Uitval van de centrale server kan nadelige gevolgen hebben 

voor de primaire processen van de organisatie die hiervan afhankelijk zijn. Het is dan ook zaak dat 

men aandacht schenkt aan Business Continuity Management bij invoering van SBC. Door een 

impactanalyse uit te voeren op de primaire processen van de organisatie bij uitval van de centrale 

ICT-voorzieningen krijgt men inzicht of een uitwijkvoorziening inclusief een externe opslag van 

back-upgegevens nodig is. Gemeenten hebben meestal al voor het GBA al zo'n voorziening en die 

zou dan kunnen worden uitgebreid. 

SBC biedt de mogelijkheid om vanaf verschillende locaties te werken op een centrale server. Over 

de netwerkverbindingen tussen werkstation en server wordt in een aantal gevallen gevoelige 

informatie uitgewisseld (die wordt tenslotte centraal opgeslagen bij SBC). Beveiliging van deze 

verbindingen over niet een niet vertrouwd netwerk in de vorm van een VPN is dan ook 

noodzakelijk. Indien het werkstation via een draadloze verbinding is aangesloten dient deze 

verbinding te worden vercijferd om afluisteren te voorkomen. 

4.3 Mitsen en Maren van het instrument business case voor SBC 

4.3.1 Er is meer dan financiën: ga niet blindelings voor de goedkoopste oplossing 

Een advies om een server-based Computing omgeving in te richten op louter financiële gronden 

wordt niet aanbevolen. In dit white paper is een aantal kwalitatieve voordelen van SBC benoemd. 

Deze voordelen kunnen ook voor uw organisatie van toepassing zijn maar hebben soms ook een 

keerzijde. Hieronder staan een aantal afwegingen die elke organisatie voor zich moet nemen bij de 

besluitvorming over al of niet invoeren van een SBC-omgeving. 

• Beheer clients en servers: de beheerlast voor een SBC-omgeving levert op de lange termijn 

besparingen op voor beheer. Beheer van een SBC-omgeving vereist wel andere kennis en 

vaardigheden van een beheerder dan voor een conventionele omgeving. 

• Beperken wildgroei in applicaties: in een SBC-omgeving wordt voorkomen dat verschillende 

applicaties voor een vergelijkbaar proces worden aangeschaft. In een centrale omgeving heeft 

men een beter overzicht wat al gebruikt wordt en dat levert winst op voor beheer. De keerzijde 

hiervan is het feit dat de beheerorganisatie zich formeler moet opstellen bij invoer van nieuwe 

applicaties (in verband met testen in een SBC-omgeving) en de organisatie daardoor minder 

flexibel wordt met invoeren van een nieuwe applicatie. 

• Beveiliging: server-based Computing zorgt voor een inherent veiliger omgeving, omdat 

gevoelige informatie niet lokaal op de client kan worden opgeslagen. 


White paper 


• Flexibel werken op andere locaties: met server-based Computing is het mogelijk voor de 

medewerkers op andere locaties binnen de organisatie te werken, dit biedt naast de flexibiliteit 

ook besparing aan reistijd van de medewerkers. Dit is mogelijk te kwantificeren door het aantal 

uren aan reistijd te nemen en te vermenigvuldigen met een gemiddeld uurtarief (bedenk wel 

dat dit gebaseerd is op een aanname van het aantal reisuren!). 

• Vereiste bandbreedte van de netwerkverbindingen tussen de verschillende locaties. SBC 

vereist een minimale beschikbare bandbreedte. Binnen het lokale netwerk is dit geen 

probleem. Voor dislocaties moet vaak een keuze worden gemaakt: een leased line met 

voldoende bandbreedte ten opzichte van een fat client met een VPN-verbinding over een 

internetaansluiting. 

• Migratietraject voor invoering van de nieuwe omgeving: naast een migratietraject naar één 

serverruimte en een basispakket aan applicaties, moet men bij server-based Computing 

rekening houden met een testtraject waarin onderzocht wordt of de bedrijfsapplicaties geschikt 

zijn voor SBC en het inrichten van een SBC-serverfarm om deze applicaties voor alle 

medewerkers te ontsluiten. Hierdoor heeft men vaak tijdens een migratietraject twee 

operationele omgevingen die extra aandacht van beheer vergen. 

4.3.2 Neem zelf de verantwoordelijkheid voor het opstellen van de business case 

De bestaande organisatie heeft meestal een goed inzicht in de kosten en mogelijkheden van de 

bestaande omgeving met fat clients. Het uitwerken van de eerste variant met fat clients kan 

daarmee door de organisatie zelf worden uitgevoerd, mits er voldoende capaciteit is. 

Voor het uitwerken van varianten met SBC ontbreekt vaak de kennis binnen de organisatie. Het is 

dan verleidelijk om een leverancier die ervaring heeft met SBC in te huren voor het uitwerken van 

de business case. Dit heeft nadelen. Ten eerste bestaat de kans dat zo'n leverancier de voordelen 

van SBC gaat uitvergroten. Een evenwichtige business case wordt dan lastig. Ten tweede zijn de 

kosten voor invoering van SBC meestal van zodanige omvang dat een aanbesteding verplicht is. 

Een leverancier van SBC die betrokken is bij het opstellen van een business case, kan in die 

situatie voorkennis hebben waardoor een eerlijke aanbesteding onmogelijk wordt. Daarom wordt 

aanbevolen om in het geval dat de eigen organisatie onvoldoende capaciteit of kennis heeft om een 

business case op te stellen, een onafhankelijke adviseur in te schakelen. 

4.3.3 Betrek de relevante budgethouders 

De financiële huishouding wordt door de organisatie bepaald. In kleine organisaties worden vaak 

de ICT-kosten als algemene kosten geboekt. Soms worden de ICT-kosten als overheadkosten op 

de verschillende afdelingen geboekt (al dan niet naar rato). In grotere organisaties kunnen de 

werkelijke ICT-kosten naar de verschillende afdelingen worden doorbelast. In dat laatste geval is 

een afdelingshoofd een van de stakeholders geworden bij de besluitvorming van de BC. Bij een 

mixed variant waarbij voor een aantal applicaties nog fat clients worden voorgesteld, dient het 

betreffende afdelingshoofd betrokken te worden bij de besluitvorming. Deze is tenslotte 

verantwoordelijk voor het afdelingsbudget. 


A Literatuurlijst 

White paper 


Zalm (2003) Kosten, baten en risico’s van IT-investeringen / Uitgave in de reeks: Controlling in 

de praktijk - M. van der Zalm, P.G. Noordam – Kluwer, Deventer. 

Citrix (2001) Printing Architecture Solution, Citrix Consulting Services, Citrix Systems Inc., 20 

december 2001 


B Over de auteurs 

White paper 


Drs. M. van der Zalm (Merijn) is vanaf 2005 als senior consultant organisatie- 

en procesadvies werkzaam bij Verdonck, Klooster & Associates (VKA). 

Merijn is adviseur met een brede werkervaring in verschillende sectoren en 

organisaties. Hij zet zijn kennis en ervaring in bij complexe verandertrajecten 

op het snijvlak van organisatie, processen en informatisering. Hij doet dit 

binnen, maar vooral ook tussen overheidsorganisaties, meestal in de rol van 

adviseur, business architect of programmamanager. Merijn heeft een 

bedrijfskundige achtergrond en is auteur van diverse boeken en artikelen 

over investeringsvraagstukken, shared services, standaardisatie en 

procesmanagement. E-mail: merijn,vanderzalm@vka.nl 

Ir. C. Reniers (Christ) is vanaf 2001 als senior consultant 

informatiebeveiliging werkzaam bij Verdonck, Klooster & Associates (VKA). 

Christ heeft meer dan 15 jaar ervaring met informatiebeveiliging. Hij adviseert 

de top van de Nederlandse overheid en het bedrijfsleven bij het organiseren 

en inrichten van informatiebeveiliging. Als senior consultant weet hij de eisen 

vanuit de bedrijfsprocessen te vertalen in concrete security oplossingen. Hij 

heeft ervaring met diverse relevante security standaards, zoals de ISO17799, 

ITIL Security Management, VIR, A&K-analyse, RIP, etc. Christ presenteert 

en publiceert regelmatig over informatiebeveiliging. E-mail: 

christ.reniers@vka.nl 

Ir. W.A. Schouten (Pim) is vanaf 2004 als managing consultant werkzaam bij 

Verdonck, Klooster & Associates (VKA). Daarvoor werkte hij in diverse 

functies bij KPN, onder meer als consultant en in diverse 

managementfuncties. Pim is in 1993 afgestudeerd in de Elektrotechniek 

(richting Telecommunicatie) aan de Technische Universiteit Delft. 

Pim is een breed inzetbare adviseur met als specialisaties telecommunicatie- 

toepassingen, uitbestedingen, financiering/TCO en Europese 

aanbestedingen. Als consultant heeft hij onder meer opdrachten uitgevoerd 

op het gebied van outsourcing, verwervingen en (her)contracteringen, en de 

elektronische overheid. Pim heeft diverse publicaties op zijn naam staan en 

is gastdocent geweest aan de Erasmus Universiteit Rotterdam. E-mail: 

pim.schouten@vka.nl 

Verdonck, Klooster & Associates is een onafhankelijk adviesbureau met ruime ervaring op het 

snijvlak van strategie, procesinrichting en ICT in de publieke sector. www.vka.nl 

Postbus 7360, 2701 AJ ZOETERMEER Tel 079 368 1000, Fax 079 368 1001

lees meer - Merijn van der Zalm

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?