Master Thesis - Nieuwe Media en Digitale Cultuur
Open source software en Culturele wenselijkheid Een onderzoek naar hoe bij gemeentelijke organisaties de besluitvormingsprocessen rond de aanschaf van software verlopen
Josine Vos, 0132780 Universiteit Utrecht, Faculteit der Letteren November 2005
Inhoud Inleiding...............................................................................................................................3 Stage en onderzoek .......................................................................................................3 Usability binnen een gemeentelijke organisatie..............................................................4 Methoden van onderzoek................................................................................................5 Structuur en opbouw van deze thesis.............................................................................6 1. Usability: een bruikbaar concept?....................................................................................8 1.1 Het Exended ISO- of Quint-model..............................................................................8 1.2 Negen eigenschappen van usability........................................................................10 1.3 Leerbaarheid en psychologische aspecten..............................................................11 1.4 Gebruikersvriendelijkheid en tevredenheid.............................................................12 1.5 Meetbaarheid tijdens ontwerpfase..........................................................................13 1.6 Hypothese: organisatiecultuur en usability.............................................................15 2. Open source software....................................................................................................17 2.1 Wat is open source software?..................................................................................17 2.1.1 Open source software in relatie tot free software.............................................18 2.1.2 Het project open source...................................................................................19 2.2 Waarom open source software?...............................................................................21 2.2.1 Open source software is toegankelijk en controleerbaar..................................21 2.2.2 Open source software is stabiel en veilig.........................................................22 2.2.3 Open source software is flexibel en innovatief ................................................23 2.2.4 Open source software is goedkoop...................................................................24 2.3 Gebruik en verspreiding van open source software ................................................26 2.3.1 Gebruik open source software bij Nederlandse overheid .................................26 2.3.2 Gebruik open source software in het buitenland..............................................28 3. De gemeentelijke organisatie Eindhoven.......................................................................30 3.1 Organisatiebeschrijving gemeente Eindhoven.........................................................30 3.1.1 Dienst Algemene en Publiekszaken..................................................................32 3.1.2 Dienst Maatschappelijke Ontwikkeling.............................................................33 3.1.3 Dienst Stedelijke Ontwikkeling en Beheer........................................................34 3.1.4 Dienst Werk, Zorg en Inkomen.........................................................................36 3.1.5 Facilitair Bedrijf................................................................................................37 3.2 Organisatiestructuren .............................................................................................39 3.2.1 Structuurconfiguraties.....................................................................................39 3.2.2 De structuurconfiguratie van de gemeente Eindhoven....................................42 4. Besluitvorming rond de aanschaf van software..............................................................45 4.1 IT-beheer bij de gemeente Eindhoven.....................................................................45 4.1.1 ITIL-beheermethodiek......................................................................................45
1
4.1.2 ITIL-Processen..................................................................................................47 4.2 Relevant beleid met betrekking tot de aanschaf van software................................49 4.2.1 Centralisatie ....................................................................................................50 4.2.2 Standaardisatie................................................................................................51 4.3 Softwarebesluitvorming gemeente Eindhoven........................................................54 4.3.1 De verschillende lagen in een besluitvorming..................................................55 4.3.1.1 De eindgebruikers....................................................................................55 4.3.1.2 De beslissers............................................................................................57 4.3.1.3 De organisatiecultuur...............................................................................60 4.3.2 Interne communicatieprocessen binnen de gemeente Eindhoven...................61 4.4 Vergelijking besluitvorming met andere gemeenten...............................................63 5. Open source software binnen gemeentelijke organisaties.............................................71 5.1 Gemeentelijke organisaties en open source software..............................................71 5.2 Samenwerking tussen gemeenten..........................................................................79 5.3 Hoe kiest een gemeentelijke organisatie?...............................................................82 5.3.1 Praktijkvoorbeeld: Office Migratie Project.........................................................83 5.3.2 Verloop Office Migratie Project.........................................................................84 5.4 Usability in een organisatiecultuur..........................................................................88 5.5 Uitbreiding van het concept usability......................................................................90 6. Conclusies en aanbevelingen.........................................................................................92 6.1 Krijgt open source software een eerlijke kans in besluitvormingsprocessen?..........92 6.2 Het bundelen van krachten.....................................................................................92 6.3 Usability: het complete concept..............................................................................93 6.4 Bedrijfsvoering gemeente Eindhoven......................................................................94 Bibliografie.........................................................................................................................96 Bijlage - interviews......................................................................................................100 Interviews gemeente Eindhoven.............................................................................100 Interviews andere gemeentelijke organisaties........................................................100
2
Inleiding Het gebruik van software is in de huidige gemeentelijke organisaties niet meer weg te denken.
Het
uitgeven
van
paspoorten
en
rijbewijzen,
de
verwerking
van
uitkeringsaanvragen, het bedienen van de verkeerslichten in de stad, het maken van een planologisch ontwerp voor de stad en het plannen van raadsvergaderingen zijn slechts een paar voorbeelden van fundamentele bedrijfsprocessen van een gemeentelijke organisatie, waarbij men afhankelijk is van software. Op de begroting vormt software een steeds grotere kostenpost, zo blijkt uit een gesprek met de heer Ton van Erp die medeverantwoordelijk is voor de financiële administratie van de
gemeente
Eindhoven.
Daarnaast
zijn
overheidsorganisaties
voor
cruciale
bedrijfssoftware sterk afhankelijk van leveranciers. Wanneer de leverancier geen ondersteuning meer biedt voor bepaalde software, wordt een organisatie gedwongen om de software te vernieuwen. Echter, open source software (oss) biedt mogelijkheden, die de hiervoor genoemde problemen kunnen wegnemen. Naast hoge kostenbesparingen (Open Source Software Lab; Vereniging Open Source Nederland) kan een organisatie zich namelijk ook door het van oss bevrijden uit de wurggreep van de software-leveranciers (Weber, 2004: 4). En dit zijn slechts enkele voorbeelden van vele voordelen die oss te bieden heeft. Open source software lijkt ook steeds meer de kop op te steken; naast veel particulieren, stappen ook steeds meer bedrijven en instellingen over op oss. Ook binnen gemeentelijke organisaties wordt er gebruikt gemaakt van oss. Er zijn echter ook gemeenten die juist helemaal geen gebruik maken van oss.
Stage en onderzoek Uit een bericht van 15 november 2004, dat onder andere te lezen was op de website Ososs.nl, bleek dat de gemeenteraad van Eindhoven wil dat hun gemeente serieus aan de slag gaat met open source software (Kelfkens, 2004). Dit bericht vormde voor mij de aanleiding om de gemeente Eindhoven een brief te sturen met het voorstel om onderzoek te doen naar oss, om het besluitvormingsproces van de gemeente wat betreft de overstap op andere software te bestuderen en zelf daarbij op te treden als 'open source consultant'. Dit leidde tot een onderzoeksstage, die ik in het kader van mijn afstuderen aan de Universiteit Utrecht, in de maanden april, mei, juni en juli 2005 heb uitgevoerd bij de 3
gemeentelijke organisatie van Eindhoven. Voor het uitvoeren van het onderzoek ben ik geplaatst bij het Facilitair Bedrijf (FB), op de ICT-afdeling. De heer Joop Bruurs, zelf werkzaam als ICT-adviseur bij de gemeente Eindhoven, was gedurende deze periode mijn begeleider. Mevrouw Marianne van den Boomen was mijn begeleidend docente van de Universiteit Utrecht. De onderzoeksopdracht van mijn stage bestond uit het doen van onderzoek naar de wijze waarop de besluitvorming van een gemeentelijke organisatie tot stand komt wat betreft de keuze voor bepaalde software. Ook heb ik onderzocht wat de aanleiding is om van software te veranderen, welke zaken er van belang zijn in de afweging en of er ook meerdere alternatieven met elkaar overwogen worden. Een belangrijk deel van dit onderzoek was erachter te komen in hoeverre oss mee wordt genomen als mogelijk alternatief voor de vervanging van de huidige software. Bij het ontrafelen van de complexiteit van een gemeentelijke organisatie zoals de gemeente Eindhoven heb ik studie verricht naar deze organisatie op verschillende niveaus, met betrekking tot de diverse personen die op verschillende niveaus betrokken zijn bij het maken van besluiten. In het onderzoek heb ik mij gericht op deze personen en de rol die zij vervullen bij besluitvormingsprocessen. Daarnaast heb ik onderzocht of de eindgebruikers ook een stem hebben in het geheel of dat er op een andere wijze rekening wordt gehouden met de personen die de software uiteindelijk gaan gebruiken. Daarnaast hield de onderzoeksopdracht in een vergelijkingsonderzoek te doen naar de wijze waarop andere gemeentelijke organisaties hun besluiten over de aanschaf van software nemen. Bij deze gemeenten heb ik onder andere onderzocht of zij gebruik maken van oss en om welke open source-toepassingen dit dan gaat. Ook wilde ik achterhalen wat de redenen zijn om al dan niet gebruik te maken van oss en wat hun opvattingen over oss zijn.
Usability binnen een gemeentelijke organisatie In het onderzoek naar hoe de besluitvorming van een gemeentelijke organisatie tot stand komt wat betreft de keuze voor bepaalde software, heb ik mij in mijn onderzoek ook gericht op het concept usability, dat volgens de bestaande definities voornamelijk betrekking heeft op de bruikbaarheid en gebruikersvriendelijkheid van een product. Gedurende drie maanden heb ik de gemeentelijke organisatie van Eindhoven gevolgd in het besluitvormingsproces rond de vervanging van het kantoorautomatiseringspakket 4
Office
97
en
onderzocht
op
welke
wijze
usability
een
rol
speelt
in
dit
besluitvormingsproces. Het is interessant te onderzoeken hoe een gemeentelijke organisatie haar keuzes maakt en welke zaken van belang zijn in de afweging. Daarbij heb ik onderzocht in hoeverre usability een rol speelt bij het maken van een keuze voor bepaalde software en of er nog kan worden volstaan met de huidige benaderingen van het begrip usability, als we kijken naar de context waarin er keuzes worden gemaakt voor bepaalde software. De reden dat ik de problematiek rond usability in mijn thesis aan de orde wil stellen, is omdat het mij niet is ontgaan dat er binnen de gemeentelijke organisatie van Eindhoven voor zeer prijzige oplossingen wordt gekozen op softwaregebied. Zo heeft de organisatie bijvoorbeeld het programma Acrobat Writer aangeschaft, voor het kunnen opstellen van documenten in .pdf formaat, en de digitale versie van het Van Dale woordenboek dat ook over de functionaliteit van een synoniemenlijst beschikt. Waarom kiest een organisatie zoals de gemeente Eindhoven voor deze zeer prijzige software, de 'bekende merken' onder de software, terwijl er ook andere veel goedkopere alternatieven zijn die kwalitatief minstens even goed zijn? Wordt er wel zorgvuldig gekeken naar de bruikbaarheid van andere software, zoals open source software? Heeft het met de afhankelijkheid van leveranciers te maken? De hiervoor genoemde vragen hebben deel uitgemaakt van het onderzoek, waarin ik mij primair heb gericht op de gemeente Eindhoven. Daarnaast heb ik, door middel van interviews bij andere gemeentelijke organisaties in Nederland, een vergelijkingsonderzoek gedaan. In het vergelijkingsonderzoek heb ik de gemeente Eindhoven vergeleken met andere
gemeentelijke
organisaties
in
Nederland
en
onderzocht
in
hoeverre
er
overeenkomsten en/of verschillen zijn in de besluitvormingsprocessen van de organisaties wat betreft de aanschaf van software.
Methoden van onderzoek Voor het uitvoeren van het onderzoek heb ik meerdere methoden gebruikt. Zo was er vanzelfsprekend een literatuuronderzoek nodig naar de verschillende opvattingen van usability en de achtergronden van open source software. Naast het literatuuronderzoek heb ik tevens interviews afgenomen. In de interviews heb ik methoden van Deacon e.a. (1999) toegepast. Zo heb ik onder andere de methode “Control and comparison” toegepast, door alle interviews face-to-face te laten plaatsvinden. 5
Face-to-face interviews geven je beter dan bijvoorbeeld het laten invullen van een vragenlijst de mogelijkheid om alle vragen te kunnen stellen die je wilt stellen, ook naar aanleiding van antwoorden van de respondenten (ibid.: 68). Voorafgaand aan ieder interview heb ik wel een vragenlijst opgesteld, die in ieder geval de basis van het gesprek moest vormen. Om zoveel mogelijk boven tafel te krijgen heb ik deze lijst echter niet strikt gevolgd. In dat geval zouden namelijk belangrijke onderwerpen verborgen kunnen blijven (ibid.: 69). Afhankelijk van hoe een gesprek verliep heb ik de vragen soms in een andere volgorde gesteld, vielen er vragen weg of kwamen er juist vragen bij tijdens de gesprekken. Deze methode omschrijven Deacon e.a. als “Elaboration and digression” (ibid.: 69). Om dezelfde reden zijn er geen geluidsopnames gemaakt, maar heb ik tijdens de gesprekken aantekeningen op papier gemaakt. Met een opname zou namelijk het gesprek niet alleen officiëler worden, maar zou de houding van de respondenten ook meer strategisch en voorzichtiger zijn tijdens het gesprek dat over subjectieve en gevoelige kwesties gaat. Vanzelfsprekend zijn er tijdens het interview ook algemene vragen gesteld (ibid.: 73) om inzicht te krijgen in wat er zoal aan software gebruikt wordt binnen gemeentelijke organisaties. Ook heb ik aan het begin van ieder gesprek gevraagd aan de respondenten hun functie binnen de organisatie te omschrijven en daarbij uit te leggen welke positie hij of zij inneemt binnen de organisatiestructuur.
Structuur en opbouw van deze thesis In het eerste hoofdstuk wordt ingegaan op meerdere bestaande benaderingen van het begrip usability, om te laten zien wat er zoal bestaat aan visies op dit begrip. Van daaruit formuleer ik specifieke vragen voor het onderzoek, met name naar bedrijfsculture aspecten, die afwezig blijken te zijn in de bestaande definities van usability. Het tweede hoofdstuk gaat in op de achtergronden van oss en waarom dit type software relevant is voor een gemeentelijke organisatie. Ook wordt ingegaan op toepassingen van oss bij nationale en internationale instituties. Vervolgens wordt in het derde hoofdstuk ingegaan op het primaire onderzoeksobject, namelijk de gemeente Eindhoven. Dit hoofdstuk biedt inzicht in de gemeente Eindhoven als organisatie. Zo wordt
de structuur van de organisatie beschreven, 6
waarbij
verschillende lagen en vakdiensten te onderscheiden zijn, en wordt ingegaan op de organisatiekarakteristieken van de gemeentelijke organisatie van Eindhoven. In hoofdstuk vier en vijf worden de resultaten besproken van het onderzoek naar de besluitvorming van de gemeente Eindhoven rond de aanschaf van software. Ook wordt ingegaan op de bedrijfscultuur van deze organisatie, en wordt er een terugkoppeling gemaakt naar de usability-definities. Hieruit zal blijken dat deze definities nog te beperkt zijn en moeten worden bijgesteld. Ik besluit mijn thesis met conclusies naar aanleiding van mijn bevindingen uit het onderzoek en daarnaast met de aanbevelingen die ik wil doen aan de gemeente Eindhoven, gericht op de inzet van open source software bij diverse bedrijfsprocessen. Daarnaast wil ik ook mijn ideeën voordragen voor de verbetering van de interne bedrijfsvoering van de gemeentelijke organisatie van Eindhoven, alsmede voor het verbeteren van de externe communicatie en het samenwerkingsverband met andere gemeenten om onder andere de implementatie van oss te vergemakkelijken.
7
1. Usability: een bruikbaar concept? Is usability hetzelfde als bruikbaarheid of gebruikersvriendelijkheid, of toch niet? In dit hoofdstuk zal ik ingaan op het concept usability en hoe het wordt gedefinieerd door diverse theoretici. In mijn thesis zal ik aantonen dat in de bestaande definities geen plaats is voor het aspect van organisatiecultuur, dat daarentegen wel degelijk een rol speelt in besluitvormings- en implementatieprocessen. Kan nog worden volstaan met de huidige definities? Door uitgebreid uiteen te zetten waar de huidige visies uit bestaan en door in te gaan op de diverse benaderingen van het begrip usability, wil ik de verschillen aankaarten die er te ontdekken zijn in de benaderingen. Naast het bespreken van de verschillen, wil ik ingaan op de overeenkomsten die deze definities met elkaar hebben: het ontbreken van het aspect van de organisatiecultuur.
1.1 Het Exended ISO- of Quint-model Software is geschikt voor organisaties wanneer het voldoet aan de functionaliteit die gewenst en afgesproken is. Echter, daarnaast moet software ook voldoen aan allerlei kwaliteitseisen. Omdat kwaliteit een relatief begrip is in de zin dat verschillende belanghebbenden op verschillende manieren naar software kijken en dus verschillende (soms conflicterende) eisen zullen stellen, is er een kwaliteitsmodel nodig om de gewenste kwaliteit expliciet te kunnen maken (Florijn en Greefhorst, 2001: 14). Een van de belangrijkste kwaliteitsmodellen van dit moment is het Extended ISO-model, hetgeen een uitbreiding is op het eerdere kwaliteitsmodel ISO 9126. Deze modellen zijn ontwikkeld
door
de
International
Standards
Organization
(ISO).
De
ISO
bepaalt
internationale standaarden, die over de hele wereld worden toegepast (ISO – International Organization for Standardization, 2005). Hierbij kan men onder andere
denken aan
filmrolletjes die in elke camera passen en de lichtgevoeligheid die altijd 100, 200 of 400 bedraagt. Ook worden er wereldwijd dezelfde fittingen gemaakt, zodat lampen altijd passen. ISO heeft wereldwijd 140 leden, waarvan één lid in elk land. Deze organisatie positioneert zichzelf als volgt: “The object of ISO is to promote the development of standardization and related activities in the world with a view to facilitating international exchange of goods and services, and to developing cooperation in the spheres of intellectual, scientific, technological and economic activity. The results of ISO technical work are published as International Standards” (ibid.). 8
Het Extended ISO-model bevat meer kwaliteitseigenschappen dan ISO 9126 door de toevoeging van een aantal in de praktijk gebruikte eigenschappen. Het model bestaat uit 21 kwaliteitseigenschappen van een softwareproduct. Door het project Quint (Quality in Information Technology), waarin onderzoek gedaan is naar het kwantitatief specificeren van kwaliteitseisen, zijn aan deze 21 deeleigenschappen nog 11 eigenschappen toegevoegd die in de praktijk een zinvolle aanvulling bleken te vormen. Het Extended ISO-model wordt daarom ook wel het Quint-model genoemd. In het Extended ISO- of Quint-model worden in totaal 32 kwaliteitseigenschappen van een softwareproduct gegroepeerd onder zes hoofdgebieden. Deze zes hoofdgebieden zijn: functionality, reliability, usability, efficiency, maintainability en portability. Hieronder staat het model afgebeeld, waarbij de door Quint toegevoegde eigenschappen cursief zijn weergegeven. (Florijn e.a., 2003; Florijn en Greefhorst, 2001)
Figuur 1: Extended ISO- of Quint-model (Florijn en Greefhorst, 2001; Florijn e.a., 2003)
Het Quint-model, dat dateert uit 1991, kan op diverse momenten in het ontwikkeltraject zeer goede diensten bieden (Florijn en Greefhorst, 2001: 17, 18). Zo kan het model hulp bieden bij onder andere het opstellen van specifieke eisen wanneer er onduidelijk beeld bestaat van het toekomstige systeem en bij het voorkomen van onvolledige eisen door alle belanghebbenden hierover te raadplegen (ibid.: 15). Eén van de hoofdgebieden in het Quint-model is usability. Er bestaan vele definities van dit begrip, waarvan ik er vier in dit hoofdstuk zal behandelen. Deze definities vertonen verschillen met elkaar, maar ook overeenkomsten.
9
Deze thesis handelt over het feit dat één belangrijk aspect ontbreekt, namelijk de organisatiecultuur. Merk op dat alle definities niet spreken over organisatiecultuur.
1.2 Negen eigenschappen van usability Volgens het Quint-model is het begrip usability uiteen te zetten in maar liefst negen kenmerken of eigenschappen. Usability (bruikbaarheid) is te omschrijven als “een verzameling attributen die van invloed is op de inspanning benodigd voor het gebruik, en op de individuele beoordeling van dat gebruik, door een vastgestelde of impliciete verzameling gebruikers” (Florijn e.a., 2003: 168). Het begrip usability wordt in het model opgesplitst in deelgebieden (of attributen), die verder inhoud geven aan het begrip usability:
understandability,
learnability,
operability,
explicitness,
customisability,
attractivity, clarity, helpfulness en user-friendliness (Florijn e.a., 2003; Florijn en Greefhorst, 2001). Met understandability (begrijpelijkheid) worden de eigenschappen van de software bedoeld “die van invloed zijn op de benodigde inspanning van de gebruiker om het logische concept en de toepassing daarvan te herkennen” (Florijn e.a., 2003: 170, 171). De eigenschappen van de software “die van invloed zijn op de benodigde inspanning van de gebruiker om de software te leren toepassen” (ibid.: 171) kunnen omschreven worden als de learnability (leerbaarheid) van software. Operability (gebruiksgemak) wordt gedefinieerd als de “eigenschappen van de software die van invloed zijn op de benodigde inspanning van de gebruiker om de software te gebruiken en het gebruik te beheersen” (ibid.: 171). De
begrippen
explicitness,
customisability,
attractivity,
clarity,
helpfulness
en
user-friendliness zijn de toevoegingen uit het Quint-model. Deze termen zijn als volgt gedefinieerd (ibid.: 169, 171): •
Explicitness (explicietheid): eigenschappen van de software die van invloed zijn op de duidelijkheid van de software over zijn status.
•
Customisability (aanpasbaarheid): de eigenschappen van de software die het mogelijk maken dat de software wordt aangepast door de gebruiker om de inspanning benodigd voor gebruik te verminderen en de tevredenheid met het gebruik te verhogen.
•
Attractivity (aantrekkelijkheid): eigenschappen van de software die van invloed zijn op de tevredenheid van latente gebruikersbehoeften en voorkeuren door middel van geboden diensten, gedrag en presentatie.
•
Clarity (duidelijkheid): eigenschappen van de software die van invloed zijn op de duidelijkheid waarmee de software gebruikers bewust maakt van de functies die 10
de software biedt. •
Helpfulness (behulpzaamheid): eigenschappen van de software die van invloed zijn op de beschikbaarheid van instructies voor gebruikers voor de interactie met de software.
•
User-friendliness (gebruikersvriendelijkheid): eigenschappen van de software die van invloed zijn op de gebruikerstevredenheid.
In het Quint-model worden negen eigenschappen van usability onderscheiden. Echter, tot deze negen eigenschappen behoort nog een tiende eigenschap gerekend te worden, namelijk in termen van organisatiecultuur.
1.3 Leerbaarheid en psychologische aspecten In het boek Usability Inspection Methods, een handboek voor ontwerpers van interfaces, worden methoden beschreven om usability-problemen op te kunnen sporen in een bestaand interface1 ontwerp en deze problemen op te lossen om zo de usability van het ontwerp te verbeteren. Usability “is a fairly broad concept that basically refers to how easy it is for users to learn a system, how efficiently they can use it once they have learned it, and how pleasant it is to use. Also the frequency and seriousness of user errors are normally considered to be constituent parts of usability” (Nielsen en Mack, 1994: 3). Dit houdt in dat een gebruiker problemen kan ondervinden met een interface om verschillende redenen: dat het moeilijk is om het systeem onder de knie te krijgen, het systeem te langzaam is voor de gebruiker om bepaalde taken uit te voeren, de vormgeving te lelijk is of dat het systeem op andere manieren voor ontevredenheid zorgt. Deze benadering gaat net als de benadering uit het Quint-model in op de leerbaarheid, maar gaat niet in op de andere eigenschappen uit het Quint-model. Echter, in het Quint-model maakt efficiency geen deel uit van usability, terwijl Nielsen en Mack in hun benadering van usability daar wél op ingaan. Ook worden, in tegenstelling tot de benadering uit het Quint-model, in het boek Usability Inspection Methods tevens psychologische benaderingen besproken met betrekking tot cognitieve vaardigheden, die gerelateerd zijn aan de manier waarop een systeem ontworpen moet worden. Deze benaderingen hebben onder andere betrekking op visuele aspecten als grootte en kleur van de objecten in een systeem. Ook moeten elementen als knoppen in een systeem logische namen krijgen, die goed overeenkomen met het resultaat dat volgt als de knop wordt gebruikt. Daarnaast zijn er belangrijke verschillen tussen beginners en gevorderde 1 User interface wordt gedefinieerd als de presentatie van data en instrumenten aan de gebruiker. Er bestaan zowel analoge, zoals de dashboard van een auto, als digitale user interfaces, zoals een Graphical User Interface (GUI). (Simons, 2002)
11
gebruikers, die handelingen op een verschillende manier uitvoeren. Een ontwerp kan verbeterd worden en ontwerpproblemen kunnen voorkomen worden, wanneer men op de hoogte is van hoe gebruikers denken, waarnemen en handelingen uitvoeren. (ibid.: 342-344) Nielsen en Mack betrekken de psychologische aspecten bij het begrip usability. Echter, het bedrijfspsychologische aspect ontbreekt in deze benadering volledig.
1.4 Gebruikersvriendelijkheid en tevredenheid In het Quint-model worden negen eigenschappen van usability genoemd. Echter, tot deze negen eigenschappen worden niet effectiveness en satisfaction gerekend, die Jordan (1998) wél behandelt in zijn definitie van het begrip usability. Het boek An Introduction to Usability, waarin het begrip usability uitgebreid beschreven wordt, is geschreven voor studenten die zich bezighouden met productontwikkeling. Volgens Jordan betreft de term usability in grote lijnen de gebruikersvriendelijkheid van een product. Met de gebruikersvriendelijkheid van een product wordt in grote lijnen bedoeld hoe gemakkelijk een product in gebruik is. Jordan refereert naar de ISO-definitie van usability (Internationale standaard ISO 9241-11) uit de jaren '90 van de vorige eeuw: “(...) the effectiveness, efficiency and satisfaction with which specified users can achieve specified goals in particular environments” (ibid.: 5). Volgens deze definitie komen bij usability effectiviteit, efficiency en tevredenheid kijken, waarmee gebruikers specifieke doelen kunnen bereiken. Effectiviteit refereert naar de mate waarin een doel of taak bereikt kan worden met een bepaald product (ibid.: 7, 18, 19). Het aspect tevredenheid refereert naar het niveau van het comfort dat gebruikers ervaren wanneer zij een product gebruiken en naar hoe goed de gebruikers het product vinden om er hun doel mee te bereiken. Dit laatste betreft een subjectiever aspect van usability dan effectiviteit en efficiency. (ibid.: 7) Het aspect van tevredenheid scheidt zich af van de andere aspecten en is voor een deel onafhankelijk van effectiviteit en efficiency, omdat de mate van tevredenheid dat de gebruiker ervaart tijdens het gebruik van een product niet altijd in direct verband staat met de effectiviteit en efficiency aangezien de 'look and feel' van de interface ook een belangrijke rol speelt. Als een gebruiker het bijvoorbeeld sneller lukt om de helderheid van 12
monitor A te veranderen dan van monitor B maar voorkeur geeft aan de lay-out van de menu's van monitor B, kan het zo zijn dat deze gebruiker algeheel toch meer tevreden is over het gebruik van monitor B. (ibid.: 7) Het aspect van tevredenheid wordt tevens het meest belangrijk geacht, voor de usability van een product. Immers, als gebruikers of consumenten niet tevreden zijn met een product zullen zij het ook niet gebruiken, maar zullen het product bovenal in ieder geval niet meer bij dezelfde fabrikant aanschaffen. (ibid.: 7) De tevredenheid kan gemeten worden door mensen te ondervragen hoe zij hun product ervaren. Hoe voelen de gebruikers zich tijdens het gebruik van het product: vinden zij het gemakkelijk in gebruik, hebben zij plezier in het gebruiken van het product of treedt er juist ergernis of frustratie op? Een dergelijke meting, die plaatsvindt in de ontwerpfase van een product, kan worden uitgevoerd door middel van het laten invullen van een vragenlijst. Ook kan de meting in de vorm van een interview uitgevoerd worden, waarbij de interviewer (een persoon die namens het betreffende bedrijf het interview houdt) in kan gaan op de aspecten die de gebruiker als (zeer) positief of (zeer) negatief ervaart. (ibid.: 23) Deze definitie vult het Quint-model aan door in te gaan op het aspect van tevredenheid, maar aan de andere eigenschappen die in het Quint-model genoemd worden wordt door Jordan geen aandacht besteedt. En nogmaals, ook in de definitie van Jordan ontbreekt het aspect van organisatiecultuur volledig.
1.5 Meetbaarheid tijdens ontwerpfase In
hun
boek
Human
Factors
for
Informatics
Usability,
dat
door
middel
van
wetenschappelijk onderzoek naar usability ontwerpers, software en hardware engineers bewust wil maken van het belang van usability, trachten Shackel en Richardson (1991) een eerdere definitie van usability uit 1981 van Shackel te verbeteren. De definitie die zij willen verbeteren luidt als volgt: “the capability in human functional terms to be used easily and effectively by the specified range of users, giving specified training and user support, to fulfil the specified range of tasks, within the specified range of environmental scenarios” (ibid.: 24). Shackel en Richardson menen dat deze definitie niet specificeert hoe usability te meten is. Zij stellen verschillende operationele criteria voor, die stuk voor stuk een numerieke waarde moeten krijgen: “This definition has been formulated so that the numerical values 13
can be specified during the design stage of user requirements specification” (ibid.: 25). Hieronder hun definitie van het begrip usability: Proposed Operational Definition of Usability Usability can be specified and measured by means of the operational criteria defined below. The terms should be given numerical values when the usability goals are set during the design stage of 'requirements specification'. For a system to be usable the following must be achieved: Effectiveness •
The required range of tasks must be accomplished at better than some required level of performance (e.g., in terms of speed and errors)
•
by some required percentage of the specified target range of users
•
within some required proportion of the range usage environments
Learnability •
within some specified time from commissioning and start of user training
•
based upon some specified amount of training and user support
•
and within some specified relearning time each time for intermittent users
Flexibility •
with flexibility allowing adaption to some specified percentage variation in tasks and/or environments beyond those first specified
Attitude •
and within acceptable levels of humans cost in terms of tiredness, discomfort, frustration and personal effort
•
so that satisfaction causes continued and enhanced usage of the system. Figuur 2: Definitie van usability volgens Shackel en Richardson (1991: 25)
De verschillende deelgebieden waar usability betrekking op heeft zijn volgens Shackel en Richardson learnability, effectiveness, flexibility en attitude. Deze criteria zijn zo gedefinieerd dat het ontwerp van een product aan de hand hiervan getest kan worden om zo het product te verbeteren. Het product is 'usable', wanneer het voldoet aan de criteria die horen bij de effectiveness, learnability, flexibility en attitude. (ibid.: 25, 26). Deze benadering vertoont overeenkomsten met het Quint-model door het aspect leerbaarheid erbij te betrekken. Echter, naast dat hier efficiency en effectiviteit genoemd worden die niet in de benadering van usability van het Quint-model voorkomen, vult de benadering van Shackel en Richardson die van het Quint-model aan door ook nog in te gaan op de meetbaarheid van usability in de ontwerpfase. Verder worden er door Shackel en Richardson niet meer ingegaan op andere eigenschappen uit het Quint-model en 14
wederom ontbreekt ook in deze definitie het aspect van de organisatiecultuur.
1.6 Hypothese: organisatiecultuur en usability Het begrip usability is niet hetzelfde als gebruikersvriendelijkheid of bruikbaarheid, maar deze termen vormen slechts onderdeel van het breder omvattend
begrip usability. Zo
omhelst het begrip usability onder andere ook leerbaarheid (Nielsen en Mack, 1994) en tevredenheid (Jordan,
1998).
Zoals
we gezien
hebben bestaan er verschillende
benaderingen van dit begrip, en daarbij is de ene benadering nog uitgebreider dan de ander. In het Quint-model wordt het begrip usability opgesplitst in meerdere deelgebieden dan de andere modellen cq. definities. In dat opzicht zou het het meest volledig zijn en dus de beste definitie zijn. Echter, ook het Quint-model is naar mijn mening niet volledig. Usability behoeft een nog bredere uitleg, die ik in geen van benaderingen van de verschillende theoretici ben tegen gekomen. Er zijn andere zaken naast de understandability, operability, user-friendliness, etc die van belang lijken te zijn in het maken van een keuze voor een bepaald product. Het maken van de keuze voor een bepaald product is voor een groot deel uit te leggen in termen van een organisatiecultuur (of bedrijfscultuur). Met de organisatiecultuur wordt de manier aangeduid waarop in de organisatie mensen met elkaar omgaan, de manier waarop de besluiten worden genomen en worden uitgevoerd en de houding van de medewerkers ten opzichte van hun werk, klanten, leveranciers en collega's. Het zijn de gewoonten en gebruiken die binnen ieder bedrijf bestaan en in de loop der tijd gecreëerd zijn door mensen van het bedrijf. De bedrijfscultuur ontwikkelt zich door de geschiedenis van de organisatie heen en wordt in stand gehouden door mensen van het bedrijf. Het is dan ook erg moeilijk om verandering aan te brengen in de gewoonten en gebruiken en normen en waarden van een organisatie. Bewust of onbewust wordt deze cultuur ook doorgegeven door je baas of collega's (ITSMF Nederland, 2002: 22). Het is opvallend dat in geen van de visies van het begrip usability iets over de context en bedrijfsculturen wordt gezegd, maar het wel degelijk een rol speelt in besluitvormings- en implementatieprocessen. Open source software wordt namelijk, ondanks de goede kwaliteit van dit type software op het gebied van onder andere stabiliteit en veiligheid (Klijnsma e.a., 2002; Schildermans en Zwiekhorst, 2005; Visser, 2002), nog niet volop 15
gebruikt binnen overheidsinstellingen, zoals duidelijk zal worden uit het tweede hoofdstuk van deze thesis. Wanneer de voordelen van oss niet uit blijken te maken, lijken er andere redenen te zijn die ertoe leiden dat oss nog niet door iedereen omarmd wordt. Deze hypothese ben ik gaan toetsen bij de gemeentelijke organisatie van Eindhoven, door onder andere het besluitvormingsproces rond het “Office Migratie Project” van deze organisatie op de voet te volgen, en mij daarbij te richten op de vraag op welke wijze een gemeentelijke organisatie haar keuzes maakt. In het project moest een vervanger worden gekozen voor het huidige kantoorautomatiseringspakket Microsoft Office 97, waarbij de keuze gemaakt moest worden tussen Microsoft Office 2003 en OpenOffice.org 2.0. Als naar aanleiding van criteria uit het Quint-model (en daarnaast ook de kostenbesparingen, stabiliteit en veiligheid) de keuze voor de hand ligt, maar er toch voor het andere Officepakket gekozen wordt, hier dan kennelijk andere oorzaken aan ten grondslag liggen. Deze oorzaken kunnen verklaard worden in termen van een organisatiecultuur. In paragraaf 5.4 zal ik hier verder op ingaan.
16
2. Open source software “Open source is zo langzamerhand een uitgekauwd onderwerp, maar echt doorgebeten is er nog niet” (Te Velde, 2003). Met dit citaat van Robbin te Velde zou ik dit hoofdstuk willen inleiden, dat als onderwerp open source software heeft. Wat is oss, waarom behandel ik in deze thesis oss, oftewel wat is het belang van oss en waar vinden we voorbeelden van toepassingen van dit type software?
2.1 Wat is open source software? Open source software is software waarvan de broncode met de software mee geleverd wordt. Broncode is de taal waarin de software geschreven is. Je kunt het ook uitleggen in termen van een recept: “Source sode is a list of instructions that make up the 'recipe' for a software package” (Weber, 2004: 4). Dat de broncode vrij beschikbaar is, heeft de verreikende implicaties dat iedereen niet alleen de broncode mag inzien en gebruiken, maar ook verbeteren, aanvullen en distribueren. De vrijheid van oss houdt ook in dat iedereen de software mag gebruiken voor alle toepassingen en er geen restricties worden gesteld aan doelen waarvoor het gebruikt mag worden (ibid.: 5). Dit maakt het mogelijk voor gemeentelijke organisaties om software voor bijvoorbeeld kantoorautomatisering naar eigen behoeften en wensen in te richten, omdat er nu zelf functionaliteiten aan de software kunnen worden toegevoegd. Ook zijn er geen restricties om oss op commercieel vlak in te zetten, mits de modificaties op het origineel maar terug worden gekoppeld aan de open source community (gemeenschap). Dit laatste is één van de afspraken die is vastgelegd in de GNU General Public License of kortweg GPL. Het idee achter GPL is dat omdat de licentie bepaalt dat de broncode vrij beschikbaar moet zijn, de broncode van afgeleide of gemodificeerde software ook vrij beschikbaar dient te zijn. Dit is ook van toepassing op de gedistribueerde kopieën (ibid.: 48, 49). Richard M. Stallman (1999), de man achter de softwarelicentie GPL, heeft met dit principe de betekenis van copyright (auteursrecht) omgedraaid in wat hij copyleft noemt: "all rights reversed". De commercie hanteert copyright om software te privatiseren, maar het doel van copyleft is juist privatisering tegen te houden. Hiermee profiteren alle gebruikers van de aangebrachte verbeteringen en aanvullingen in de software en worden restricties voorkomen.
17
Dit is tevens het grote verschil in de betekenis van de licenties bij oss enerzijds en closed source software (css) anderzijds. Het eigendomsprincipe bij oss, dat wordt omschreven als “(...) not only who owns what, but what it means to own something, what rights and responsibilities property confers” (Weber, 2004: 1), is opgezet rond het idee dat distributie nodig moet zijn en juist niet uitgesloten wordt, zoals bij css wél het geval is. Microsoft is een voorbeeld van een bedrijf dat de broncode van haar software niet prijsgeeft. Echter, bij oss is de broncode dus wél vrij toegankelijk en een ieder die wil mag er op wat voor manier dan ook gebruik van maken. (ibid.) Bij css worden, naast dat het verboden is om de broncode in te zien, de software te veranderen en distributies uit te geven, vaak voorwaarden voor het gebruik opgenomen, bijvoorbeeld met betrekking tot de reikwijdte van de licentie. Echter, volgens het open source-principe kan iedereen de software onbeperkt laten draaien (Verkerk, 2003: 11). Open source software moet overigens niet in verwarring gebracht worden met free software. Hoewel de gedachtegangen van beide bewegingen vrijwel identiek zijn aan elkaar, is van belang kort het onderscheid tussen oss en free software aan te geven.
2.1.1 Open source software in relatie tot free software In 1998 besloot een aantal mensen uit de free software community de term “open source software” te gebruiken in plaats van “free software”. Sommigen hadden hierbij als doel de verwarring te voorkomen van term “free software” met “gratis software”. Met “free” doelt men op de vrijheid in het gebruik van deze software. Stallman (1999) omschrijft deze vrijheid in vier punten, die tevens bekend staan als de “four freedoms”: •
“You have the freedom to run the program, for any purpose;
•
You have the freedom to modify the program to suit your needs;
•
You have the freedom to redistribute copies, either gratis or for a fee;
•
You have the freedom to distribute modified versions of the program, so that the community can benefit from your improvements”.
Ook gebruiken programmeurs, om alle onduidelijkheid over dit verschil weg te nemen, vaak de term “free speech” en niet “free beer”, of in pseudo-Frans: “software libre” niet “software gratis” (Weber, 2004: 5). Echter, er ontstonden ook andere ideeën, waardoor bepaalde mensen zich afscheidden van de free software community. Deze mensen hadden een andere zienswijze en doelen voor ogen met betrekking tot oss waarbij men zich ging richten tot de zakelijke wereld: 18
“The rhetoric of open source focuses on the potential to make high quality, powerful software, but shuns the ideas of freedom, community, and principle. The Linux magazines are a clear example of this – they are filled with advertisements for propietary software that works with GNU/Linux” (Stallman, 1999). Deze twee bewegingen moeten gezien worden als twee politieke kampen binnen de free software community, waarbij men het eens is over de praktische zaken maar een andere ideologische kijk erop nahoudt: “Free software and open source describe the same category of software, more or less, but say different things about the software, and about values. The GNU Project continues to use the term free software, to express the idea that freedom, not just technology, is important” (ibid.). Om de uitleg wat oss is compleet te maken is het van belang om, naast wat hierboven besproken is, in te gaan op de wijze waarop de ontwikkeling van oss tot stand komt. Daar zal in de komende paragraaf op worden ingegaan.
2.1.2 Het project open source “Open source software is not a piece of software, and it is not unique to a group of hackers2. Open source is a way of organizing production, of making things jointly” (Weber, 2004: 224). Dit citaat is een goede en beknopte omschrijving van de wijze waarop open source software tot stand wordt gebracht. De ontwikkeling van oss is te omschrijven als een grootschalig en georganiseerd project, waaraan mensen uit de alle delen van de wereld vrijwillig hun medewerking aan verlenen. Al deze personen bepalen zelf waaraan ze willen werken, op welk moment en hoe vaak zij hier aan werken. Ook kan men op elk gewenst moment weer uit de community stappen (Hanappe, 2005: 209; Weber, 2004: 62). Een open source project wordt gedefinieerd als: “Elke groep mensen (of een enkeling) waar software wordt ontwikkeld die aan het publiek vrij ter beschikking wordt gesteld, onder het regime van een open source licentie” (Programma OSOSS, 2004b: 4). Binnen de open source projecten wordt overigens ook gebruik gemaakt van een overlegorgaan dat beslissingen maakt, om tegemoet te komen aan de wensen van de vele eindgebruikers en om alle ontwikkelingen in de deelprojecten op elkaar af te stemmen (ibid.: 12). De samenwerking aan open source projecten komt middels het Internet tot stand 2 Met de term hackers doelt men op de ontwikkelaars die (in open samenwerkingsverbanden of alleen) programmeren aan oss, niet hackers die aanvallen uitvoeren op servers en virussen verspreiden. (Programma OSOSS, 2004b: 5)
19
(Weber, 2004: 83). De open source community is een virtuele gemeenschap die het Internet gebruikt om met elkaar te communiceren, zich te organiseren en samen te werken aan de ontwikkeling van oss. SourceForge is een grote website voor open source ontwikkeling, waar vele projecten te vinden zijn waaraan geparticipeerd kan worden en tevens de benodigde tools (zoals documentatie) te vinden zijn. Het is ook een virtual hang-out, een plek die open source ontwikkelaars regelmatig bezoeken om te kijken welke projecten vorderen en wie wat doet in de verschillende projecten (ibid.: 65, 66). Naast dat het Internet een globaal ontwikkelplatform biedt, waarmee een einde kwam aan de concentratie van open source projecten in de Verenigde Staten (Programma OSOSS, 2004b: 5), is het Internet bij uitstek het medium dat voor de ontwikkeling van oss geschikt is, omdat het geen eigenaar heeft en daarmee ook niet voorgeschreven wordt hoe het Internet gebruikt moet worden. Dit wordt omschreven als de 'neutraliteit' van het Internet, in tegenstelling tot bijvoorbeeld het telefoonnetwerk, of 'stomheid' omdat het Internet niet weet niet wat het vervoerd (Weber, 2004: 232). Dankzij de neutraliteit en toegankelijkheid voor een groot publiek kan er innovatie plaatsvinden op het gebruikersniveau: “In the Internet, power follows intelligence out to the edges. Barriers to entry are low and nondiscriminatory. The conduit becomes just a pipe that carries what people on the edge ask it to carry. The stupid network empowers people on the edge to out their innovations without having to ask permission or procure a license from the network owner” (ibid: 232). Werken in de open source community wordt niet gezien als werk, maar als hobby. Mensen leveren voor hun plezier inspanning aan de ontwikkeling van oss en hoeven niet altijd waardering voor hun werk te krijgen in de vorm van geld: “Human beings often have a passionate relationship to their creative endeavors and their work; they wish to share their creativity with others; and value inheres in things other than monetizable rewards. Each of these attitudes exists within the open source community” (ibid.: 13). De belangrijkste reden om een open source project te starten is de persoonlijke drijfveer van een ontwikkelaar (Hanappe, 2005: 212, 213; Programma OSOSS, 2004b: 7). Zo is 'ego-boosting' één van de motivaties voor open source-ontwikkelaars: “Code that simply works is a product; code that represents an elegant solution to a complex problem is a thing of beauty that in the open source setting can be shared with others” (Weber, 2004: 136). Tevens trekt het meewerken aan open source projecten zoveel ontwikkelaars aan, omdat zij op zoek zijn naar een uitdaging. Velen zijn bezig met het ontwikkelen van software voor hun werkgever waar ze of niet achter staan danwel niet uitdagend genoeg vinden. Ter compensatie en voor de erkenning zoeken zij dan hun toevlucht in open source projecten: “Bijna elke professionele ontwikkelaar - onderzoek
20
toont aan dat de zogenoemde open source hackers grotendeels een reguliere baan hebben - is op zoek naar uitdaging. Het kunnen verbinden van je eigen naam aan de ontwikkeling van een uitdagend project - auteurschap dat wordt opgenomen in de broncode - is voor vele de belangrijkste reden” (Programma OSOSS, 2004b: 14). In de open source community profiteert iedereen van elkaars werk en dat wat jij geeft aan kennis en kunde krijg je ook weer terug (Hanappe, 2005: 214; Weber, 2004: 150). Uit dit hechte samenwerkingsverband zijn onder andere succesvolle softwareprojecten als het Linux besturingssysteem en de webserversoftware Apache het resultaat: “Collaborative open source software projects such as Linux and Apache demonstrate that a large and complex system of software code can be build, maintained, developed and extended in a non-proprietary setting in which many developers work in a highy parallel, relatively unstructured way” (Weber, 2004: 128). Nu duidelijk is wat oss is en hoe de ontwikkeling van dit type software tot stand komt, is het van belang uit te leggen waarom oss relevant is voor een (gemeentelijke) organisatie.
2.2 Waarom open source software? De vraag of gemeentelijke organisaties open source software moeten inzetten, is niet met simpel “ja” of “nee” te beantwoorden. Het is echter wel de moeite waard voor organisaties om zowel open als closed source software bij de keuze voor nieuwe software te betrekken (Verkerk, 2003: 12). Open source software biedt namelijk voordelen boven css, waar ik in dit hoofdstuk op zal ingaan, te weten: toegankelijkheid en controleerbaarheid, stabiliteit en veiligheid, flexibiliteit en innovativiteit, en kostenbesparingen.
2.2.1 Open source software is toegankelijk en controleerbaar De huidige situatie belemmert de innovatie en kwaliteit (veiligheid, stabiliteit en betrouwbaarheid) van softwareproducten, zo stellen Klijnsma e.a. (2002) in hun initiatiefvoorstel, die door de gemeenteraadsfractie van de politieke partij GroenLinks in Groningen in 2002 is ingediend: “De publieke sector leunt op dit moment zwaar op de programmatuur van enkele leveranciers. Deze verkopen alleen het gebruik van de programma’s. Het zelf aanbrengen van verbeteringen is slechts zeer beperkt toegestaan. Vaak is dit niet eens mogelijk omdat niet bekend is hoe de software in elkaar zit, omdat de broncode geheim is”. Met oss is het wel mogelijk om in de broncode te kijken en verbeteringen en aanvullingen aan te brengen (Weber, 2004: 5).
21
Naast dat closed source software niet toegankelijk is, omdat je niet in de broncode kunt kijken, is het bovendien onduidelijk hoe een programma in elkaar zit en wat het precies doet. Bij oss is echter niet langer sprake van een black box waar aan de ene kant gegevens ingaan en aan de andere kant weer gegevens uitkomen, maar je kan nu uitzoeken wat daartussen met de gegevens gebeurt. (Klijnsma e.a., 2002)
2.2.2 Open source software is stabiel en veilig Klijnsma e.a. (2002) omschrijven de huidige softwaremarkt als een verkopersmarkt: “Niet de klanten maar de verkopers bepalen de voorwaarden. De machtige leveranciers hoeven niet op hun tenen te lopen om de klant te behagen”. Het gevolg van een situatie waarin de macht bij de leverancier ligt, is dat de kwaliteit van de softwareproducten die ze leveren regelmatig te wensen overlaat. Veel commerciële software is namelijk relatief instabiel en heeft veel beveiligingslekken. Dit brengt risico’s met zich mee in de omgang met privacy gevoelige gegevens, en voor gebruikers van oss zijn de stabiliteit en de veiligheid ook de belangrijkste redenen om over te stappen. In de praktijk treden er bij oss veel minder problemen op dan bij closed source software: “Op een gegeven moment waren de beveiligingsproblemen met Microsoft servers zelfs zo groot dat onderzoeksbureau Gartner haar klanten adviseerde om deze technologie fasegewijs zo snel mogelijk te verwijderen. De open software van Apache heeft inmiddels meer dan de helft van de markt in handen” (ibid.). In de journalistieke publicatie van Schildermans en Zwiekhorst (2005), waarin zij de beveiligingslekken die in het besturingssysteem Windows zitten aan de kaak stellen en oss naar voren schuiven als alternatief dat ook steeds meer in gebruik wordt genomen vanwege deze problemen, kaart men aan dat de specialisten het erover eens dat Microsoft allerlei keuzes gemaakt heeft tijdens het ontwikkelen van zijn software, die desastreus zijn vanuit beveiligingsoogpunt: “Applicaties krijgen onder Windows bijvoorbeeld vrijwel onbeperkt toegang tot het volledige geheugen en zelfs tot het besturingssysteem zelf. Verder ontbreken er allerlei controles in de software. Microsoft laat die controles weg om de software sneller op de markt te kunnen brengen en sneller te laten functioneren”. De webbrowser Internet Explorer, de e-mailprogramma's Microsoft Outlook en Outlook Express zijn voorbeelden van producten van Microsoft, die te kampen hebben met veel beveiligingsproblemen. (ibid.: 10, 11) Echter, door de gezamenlijke inspanning van de vele mensen in de open source gemeenschap worden fouten in oss snel ontdekt en verholpen, waardoor bijvoorbeeld 22
beveiligingslekken eerder in de software kunnen worden ontdekt en kunnen worden tegen gegaan (Weber, 2004: 63; Visser, 2002: 24). De kwaliteit van oss is vaak hoger, in vergelijking tot commerciële software: “Bij commerciële software is er altijd de afweging tussen nieuwe features en het oplossen van fouten binnen een budget, en open source software kent geen commerciële deadlines en budgetten. Hierdoor wordt er meer aandacht aan kwaliteit besteed” (Open Source Software Lab). De ontwikkelaars beslissen zelf waar ze hun tijd aan besteden, waardoor open source projecten niet of nauwelijks lijden van marketing stress en de kwaliteit van oss daardoor hoger is. Bovendien wordt oss niet geteisterd door release schema’s en deadlines: “De ontwikkelaars knutselen gewoon net zo lang door tot ze er tevreden mee zijn, niet gehinderd door oneigenlijke druk” (Visser, 2002: 24).
2.2.3 Open source software is flexibel en innovatief Open source software is niet gebonden aan technologie. Veel mensen denken gelijk aan Linux als ze open source horen, maar het is ook heel goed mogelijk om oss op een commercieel platform zoals Windows te maken en te gebruiken (Open Source Software Lab). Het gaat immers om de beschikbaarheid van de broncode en open source zegt iets over wat je ermee mag. Open source software is niet alleen om deze reden flexibel. Met oss ben je namelijk ook niet meer afhankelijk van leveranciers, terwijl closed source software de innovativiteit en de flexibiliteit van de organisatie juist beperkt. Voor aanpassingen kan de klant namelijk alleen maar bij de oorspronkelijk leverancier terecht, die vervolgens zijn prijs kan vragen en het tempo kan bepalen waarin de software ontwikkeld wordt (Forge, 2005: 490, 491, 493; Klijnsma e.a., 2002). Commerciële bedrijven houden de broncode het liefst voor zichzelf, enerzijds om de voorsprong op de concurrent niet te verliezen en anderzijds om de klant te binden: ”Het is commercieel gezien prettig dat de fouten in een gesloten pakket van leverancier A zodoende niet door leverancier B opgelost kunnen worden. Als afnemer zit je dus vast aan je leverancier, of je moet al kunnen leven met een knappe kapitaalvernietiging. Maar vaak is dan het enig resultaat dat je nu niet meer gebonden bent aan A, maar aan B en het hele verhaal opnieuw begint” (Klöpping, 1998). Echter, bij oss is een organisatie als gebruiker niet meer afhankelijk van haar leverancier, omdat bij oss de broncode met het programma wordt meegeleverd (Weber, 2004: 4). De gebruiker (in dit geval dus de organisatie) krijgt hierdoor de mogelijkheid om te kiezen uit leveranciers die de gewenste wijzigingen of uitbreidingen kunnen verzorgen, of als de expertise in huis is, dit zelf te verzorgen. Deze keuzemogelijkheden kunnen vervolgens 23
weer leiden tot prijsverlagingen, want des te meer aanbieders er komen des meer concurrentie dit tot gevolg heeft (Klijnsma e.a., 2002). Flexibiliteit zit ook in de makkelijke uitwisseling van gegevens tussen ICT-systemen door het gebruik van open standaarden (Klijnsma e.a., 2002; Programma OSOSS, 2004b: 9, 10). Open standaarden zijn “eisen (technische specificaties) die aan software worden gesteld en op een voor iedereen toegankelijke lijst worden vermeld. Door bij software-ontwikkeling gebruik te maken van open standaarden kunnen programma’s van verschillende ontwikkelaars en/of leveranciers elkaar 'verstaan'. Hierdoor is het mogelijk dat zij op elkaars producten kunnen voortbouwen” (Klijnsma e.a., 2002). Open standaarden worden als volgt gedefinieerd: “The minimum requirements for an open standard are that the document format is completely described in publicly accessible documents, that this description may be distributed freely and that the document format may be implemented in programs without restrictions, royalty-free, and with no legal bindings” (Wheeler, 2005). Voorbeelden van open standaarden zijn internetprotocollen en webstandaarden, zoals HTML (HyperText Mark-up Language) en XML (Extensible Markup Language). Dit zijn slechts een paar voorbeelden van standaarden die voor iedereen beschikbaar zijn om te lezen en te implementeren, in tegenstelling tot gesloten standaarden zoals het Microsoft's Word-format DOC. (Klijnsma e.a., 2002). Ook is de innovatiesnelheid waarin oss ontwikkeld is hoog, doordat binnen de open source gemeenschap regelmatig oplossingen voor problemen gepubliceerd worden en voorstellen gedaan worden voor nieuwe features. Mede dankzij dit is de open source gemeenschap een grote motor achter de ontwikkeling van nieuwe software technieken. Bovendien zijn er ook voortdurend nieuwe updates voor de software beschikbaar, die via het Internet gedistribueerd worden. (Weber, 2004: 63)
2.2.4 Open source software is goedkoop Met de inzet van open source software kan een organisatie heel wat kosten besparen. Zo is er een zeer ruim aanbod aan oss, die gratis te downloaden is van het Internet. Ook hoeft er voor de updates (aanvullingen) en upgrades (naar een nieuwe versie) die regelmatig verschijnen niets betaald te worden (Open Source Software Lab; Vereniging Open Source Nederland). Voorbeelden van gratis te verkrijgen oss is het kantoorautomatiseringspakket OpenOffice.org, de webbrowser FireFox en het webserverplatform Apache. Daarnaast is er ook commerciële oss beschikbaar, waarvoor wel betaald moet worden. Dit 24
is
oss
waar
door
bedrijven
bijvoorbeeld
een
gebruikershandleiding
of
installatieondersteuning aan is toegevoegd (Visser, 2002: 13). Echter, in tegenstelling tot closed source software hoeven er geen licentiekosten voor oss betaald te worden, want als je oss eenmaal in je bezit hebt mag er daarna onbeperkt gebruik van worden gemaakt (Verkerk, 2003: 11). Overheidsorganisaties zouden heel wat kosten kunnen besparen door de inzet van oss. Zo zal de gemeente Haarlem, één van de eerste gemeenten die gebruik is gaan maken van oss, dankzij de inzet van oss behoorlijk wat kosten besparen. Door de inzet van oss, zoals OpenOffice.org, is er een verwachte kostenbesparing van circa 1,7 miljoen in 3 jaar (Kaas, 2005b: 1). De gemeente heeft altijd gebruik gemaakt Microsoft Office 97, maar gezien de hoogte van de licentiekosten die gemeentebreed betaald moesten worden ziet men af van een nieuwere versie van Microsoft Office. Microsoft heeft daarop gereageerd: “Overigens heeft Microsoft, onder druk van invoering van OpenOffice.org, haar prijs aan Haarlem van circa 580.000 bijgesteld naar circa 350.000 per jaar” (ibid.: 1). Een ander voorbeeld is een onderzoek dat in Groningen is uitgevoerd in het kader van het Programma OSOSS (Open Standaarden en Open Source Software) van het Ministerie van Economische Zaken, dat als doel heeft overheidsorganisaties te informeren over de mogelijkheden van oss en deze organisaties te stimuleren tot het gebruik van oss en open standaarden binnen hun ICT-systemen. Bij vijf Groningse gemeenten is een onderzoek uitgevoerd naar de verwachte kosten van de vernieuwing van hun ICT, met of zonder gedeeltelijk
gebruik
van
oss.
Uit
dit
onderzoek
is
gebleken
dat
oss
leidt
tot
kostenbesparingen: “Open source software zal volgens het rapport goedkoper zijn, en wel 308 euro (per werkplek) eenmalig, en bovendien 143 euro per jaar” (Ministerie van Economische Zaken, 2004). Er zijn ook andere aanwijzingen dat oss goedkoper is. Zo refereren Klijnsma e.a. naar een studie, waar helaas verdere informatie over ontbreekt, dat de kosten over een periode van drie jaar voor Linux gebruikers 40% bedragen ten opzichte van Windows-gebruikers en 14% ten opzichte van mensen die Sun Microsystem’s Solaris gebruiken. Verder noemen zij ook de internetboekhandel Amazon.com dat 25% bespaarde op de ICT-kosten, toen het overstapte op Linux. (Klijnsma e.a., 2002) Nu alle voordelen van oss uiteengezet zijn, zal in de komende paragrafen worden ingegaan op de gebruik en verspreiding van oss in Nederland en het buitenland.
25
2.3 Gebruik en verspreiding van open source software Steeds meer gemeentelijke organisaties tonen belangstelling voor open source software. Steeds meer begint men de voordelen van deze software te ontdekken. Dit hoofdstuk zal ingaan op de mate waarin oss wordt gebruikt bij overheidsorganisaties, zowel in Nederland als in het buitenland.
2.3.1 Gebruik open source software bij Nederlandse overheid Door steeds meer gemeentelijke organisaties in Nederland wordt open source software als alternatief overwogen naast closed source software, en bij een aantal gemeenten worden toepassingen van oss ingezet. De gemeente Haarlem was de eerste gemeente met meer dan 100.000 inwoners, die op grote schaal van oss gebruik is gaan maken en heeft er in elk geval 2 miljoen Euro mee bespaard (De Vrede, 2004). Zo heeft het op 2000 werkplekken Microsoft Office ingeruild voor OpenOffice.org (Mom, 2005). Aanleiding hiervoor was toen de gemeente ontdekte dat de licentiekosten enorm hoog zouden zijn bij de aanschaf van een nieuwere versie van de huidige versie van Microsoft Office, die op dat moment in gebruik was. De aanschaf van Microsoft Office XP zou gemeentebreed namelijk jaarlijks ruim 550.000 Euro kosten en vanwege deze hoge kosten zocht de gemeente Haarlem naar alternatieven (Programma OSOSS, 2004a; Kaas, 2005b). Na de zomer van 2005 gaat de hele organisatie over op OpenOffice versie 2.0. Daarnaast is er voor de belastingen en voor het aanmaken van parkeervergunningen en -ontheffingen een open source-toepassing in testgebruik. Ook wordt er binnen de gemeente Haarlem gebruik gemaakt van Linux, namelijk als besturingssysteem voor de Thin Clients. Een Thin Client is een client system3 in een netwerkomgeving, waarbij de applicaties op een centrale server toegankelijk zijn en met zijn sterke afhankelijkheid van een server zelf over zeer weinig bronnen beschikt (Wikipedia). De gemeente Haarlem wil het gebruik van oss binnen gemeentelijke organisaties ook stimuleren. Daartoe start de gemeente voor de zomer van 2005 met de stichting Open Source Software Overheden (OSSO) (Mom, 2005). De heer Arie Sigterman en Frans 3 Een client is een programma of een complete machine, die gebruik maakt van de diensten van een machine die als server dient. Voor de eindgebruiker is het totaal transparant welk deel van het werk door de client wordt verricht en welk deel door de server. (Wikipedia)
26
Vrijmoed, beiden ICT-adviseur binnen de gemeente Haarlem, leggen in het gesprek dat ik op 2 juni 2005 met hen had uit dat deze stichting is ontstaan, nadat duidelijk is geworden dat er een behoefte uit diverse gemeenten is naar informatie voor gemeenten over onderwerpen die
betrekking
hebben
op
oss.
Binnen
deze
stichting
worden
de
overkoepelde activiteiten op het gebied van open source van de gemeente Haarlem en anderen ondergebracht. Deze stichting stelt onder andere de ontwikkelde software met bijbehorende documentatie en gebruikershandleidingen beschikbaar. Ook komt er binnenkort een website van OSSO beschikbaar, waar veel informatie op te vinden is betreffende themagroepen. Daarnaast zijn er ook fora, is er ledeninformatie te vinden, et cetera. De gemeente Terneuzen deed in 2001 de eerste ervaringen op met oss en sindsdien heeft deze gemeente het op vele plaatsen ingezet. Echter, Knubben (2005) haalt een systeembeheerder uit Terneuzen aan die zegt dat oss geen alles of niets keuze is: “Een hybride oplossing met zowel open source als gesloten software is het meest realistisch”. De ervaringen die de gemeente Terneuzen heeft met oss zijn zeer positief: “Met soms minimale middelen vallen in de praktijk prestaties te behalen die zich kunnen meten met dure commerciele producten. In de praktijk is het geen uitzondering dat servers draaiend op het Linux een zeer hoge uptime kennen en nagenoeg onderhoudsvrij zijn” (ibid.). Verder maken de gemeenten Amsterdam, Almere, Leeuwarden, Woerden en IJsselstein ook gebruik van oss. Deze gemeenten hebben oss ingezet op hun servers, maar andere gemeenten zoals de gemeentes Haarlem en Terneuzen en ook de gemeentes Grootegast, Haren, Marum, Reiderland, Vlieland en Winschoten beschikken over toepassingen van oss op hun desktop. (Verkerk, 2003: 12; Programma OSOSS) Ondanks dat hier verder geen openbare bronnen over te vinden zijn, is uit mijn gesprekken in de maanden mei en juni 2005 met medewerkers van de gemeente Arnhem, Tilburg, Breda en Rotterdam gebleken dat zij ook oss gebruiken. In Arnhem en Tilburg wordt er voor bepaalde deeltoepassingen binnen de gemeente gebruik gemaakt van oss, bijvoorbeeld voor bepaalde functionaliteiten in het Intranet. Dit gebeurt echter alleen aan de 'achterkant', niet aan de 'voorkant' op de desktops. Binnen de gemeente Breda wordt op kleine schaal gebruik gemaakt van oss. Zo vertelt de heer Jascha Gregorowitsch, die in de functie van coördinator applicatiebeheerder bij de gemeente Breda gaat over de coördinatie van het beheren van alle applicaties binnen de gemeente en verantwoordelijk is voor het niet verder laten groeien van het aantal applicaties dat binnen de gemeente Breda in gebruik is, in een gesprek dat ik met hem had in juni 2005 dat men binnen de gemeente Breda MySQL gebruikt en een open source variant van de PDF-creator. Verder is
27
alles binnen deze gemeente closed source. Ook binnen de gemeente Rotterdam wordt er beperkt gebruik gemaakt van oss. Zo verklaart de adviseur voor het ICT-beleid van de gemeente Rotterdam, de heer Cees Jan Prevo, in een gesprek dat ik met hem had op 1 juni 2005, dat binnen deze organisatie al wel Linux ingezet voor bepaalde zaken. Net zoals bij de gemeenten Arnhem en Tilburg het geval is, maakt ook de gemeente Eindhoven aan de serverkant gebruik van toepassingen van oss. De heer Pierre van den Heuvel, hoofd ICT-beheer van de gemeente Eindhoven en geplaatst bij het Facilitair Bedrijf, verklaart als volgt: “De producten waarvan de gemeentelijke organisatie momenteel onder andere gebruik van maakt zijn Apache, TomCat (een open source webserver
waarop
webapplicaties
kunnen
draaien,
die
geschreven
zijn
in
de
programmeertaal Java), en MySQL (een open source databaseserver). Ook draait het e-mailprogramma GroupWise, waar het overgrote deel van de meer dan 2000 werknemers binnen de gemeentelijke organisatie gebruik van maakt, op Linux”.
Nu in deze paragraaf een overzicht gegeven is van de verspreiding van oss in Nederland, zal
ik
in
de
volgende
paragraaf
ingaan
op
het
gebruik
van
oss
binnen
overheidsorganisaties in het buitenland.
2.3.2 Gebruik open source software in het buitenland Naast Nederland wordt er ook in de rest van Europa gebruik gemaakt van open source software. Het mooiste voorbeeld hiervan is waarschijnlijk toch wel de gemeente München. Eind
mei
2003
maakte
de
gemeente
München
bekend
dat
het
alle
14.000
overheidscomputers gaat migreren van Microsoft Windows naar Linux. Daarnaast gaat men voor de kantoorautomatisering Office van Microsoft vervangen door OpenOffice.org (Verkerk, 2003: 12). “Deze overstap van de op twee na grootste stad (1,2 miljoen inwoners) in Duitsland laat zien dat, ook voor een lokale overheid, open source software zoals Linux en OpenOffice.org een volwaardig alternatief is voor het veel duurdere Windows en Microsoft Office” (Giesberts, 2003). In 2004 werd aangekondigd dat de Franse overheid de circa 1 miljoen computers, die door haar medewerkers worden gebruikt, wil gaan voorzien van oss. De aankondiging van minister Renaud Dutreil volgt na een uitgebreide testperiode, waarin de Franse politie op zo'n 20.000 computers met oss heeft gewerkt. Men was erg enthousiast over deze testperiode dat MandrakeSoft, aanbieder van oss, al een aantal overeenkomsten heeft getekend met diverse Franse ministeries (Coumans, 2004). Ook zijn er in Frankrijk al enkele ministeries geheel overgestapt op Linux (Verkerk, 2003: 12). 28
De Engelse overheid heeft in 2003 een overeenkomst getekend met IBM, waarin is afgesproken om oss te testen op negen verschillende plaatsen binnen de Engelse overheid. (Thompson, 2003) Buiten Europa heeft het gebruik van oss ook haar intrede in overheidorganisaties gedaan. Zo heeft het Ministerie van Defensie van Singapore besloten om op in totaal 20.000 OpenOffice.org in gebruik te nemen. Het ministerie had in 2003 voor een onderzoek al OpenOffice.org geïnstalleerd op 200 computers en daar kwamen vervolgens in november 2004 nog eens 5.000 computers bij. De reden voor de overstap zijn de hoge licentiekosten van Microsoft Office. (IDA, 2004) Uit strategische overwegingen wil ook het Amerikaanse Ministerie van Defensie niet afhankelijk zijn van een software monopolist. Het ontwikkelt daarom eigen software op basis van het open source principe (Klijnsma e.a., 2002). Daarnaast is men in de staat Massachusetts beleid aan het ontwikkelen, waarbij alle documenten van de overheid verplicht in open formaten moeten worden opgeslagen. Zodoende kan er in de toekomst makkelijk gewisseld worden van leverancier (DesktopLinux.com, 2005). In Brazilië, Mexico, Argentinië en Peru zijn er voorstellen gedaan om het gebruik van oss in overheidsorganisaties verplicht te stellen. In september 2003 hebben de overheden in Japan, China en Zuid-Korea aangekondigd samen te zullen werken met een aantal bedrijven om softwareprodukten te ontwikkelen, die een alternatief vormen voor de producten van Microsoft. China gaat daarnaast nog een stapje verder: “De Chinese regering heeft in augustus 2003 zelfs verordonneerd dat alle software van Microsoft van de overheidscomputers moet verdwijnen” (Verkerk, 2003: 12). Concluderend
kan
er
gesteld
worden
dat
de
verspreiding
van
oss
binnen
overheidsdiensten in Nederland en het buitenland de laatste jaren vrij snel verloopt. Ook komen
er
steeds
meer
voorstellen
bij
uit
gigantische
markten
als
China
en
Midden-Amerika om de overstap naar oss te maken. Echter, de implementatie van oss is niet eenvoudigweg te realiseren. Het overgrote deel van de overheidsorganisaties maakt nog steeds geen gebruik van oss, of slechts in zeer beperkte mate. In de volgende hoofdstukken zal hierop worden ingegaan, waarbij primair de gemeentelijke organisatie van Eindhoven onder de loep wordt genomen.
29
3. De gemeentelijke organisatie Eindhoven Dit hoofdstuk biedt meer inzicht in de gemeente Eindhoven als organisatie. Zo wordt de structuur van de organisatie beschreven, waarbij verschillende lagen te onderscheiden zijn. Ook is de gemeente onderverdeeld in meerdere vakdiensten, die in dit hoofdstuk stuk voor stuk worden besproken. Voor het schrijven van paragraaf 3.1 heb ik primair gebruik gemaakt van informatie van de heer Joop Bruurs, ICT-adviseur bij de gemeente Eindhoven, de heer Boris Liebrand, projectleider bij het FB van de gemeente Eindhoven, en de website van deze gemeentelijke organisatie. Om tot een oordeel te komen van wat voor type organisatie de gemeente Eindhoven is, wordt in paragraaf 3.2.1 de organisatietypologie van Mintzberg (1992) besproken.
3.1 Organisatiebeschrijving gemeente Eindhoven In de gemeentelijke organisatie van Eindhoven zijn diverse lagen te onderscheiden. Aan het hoofd van een gemeente staat de Gemeenteraad, gevolgd door de Griffie, Burgemeesters en Wethouders en Commissies en Presidium. Als derde laag is er de Concerndirectie, die bestaat uit de Gemeentesecretaris (die tevens voorzitter is van de Concerndirectie), het hoofd van de Concernstaf en de directeuren van de verschillende diensten van de gemeente Eindhoven. Na deze lagen volgt de laag van de verschillende diensten, waaruit de gemeentelijke organisatie bestaat. De vier diensten waaruit gemeentelijke organisatie bestaat zijn: de dienst Algemene en Publiekszaken (APZ), de dienst Maatschappelijke Ontwikkeling (MO), de dienst Stedelijke Ontwikkeling en Beheer (SOB) en de dienst Werk, Zorg en Inkomen (WZI). Formeel gezien moeten ook de Brandweer en Crisisbeheer (BCB) en de Gezondheidsdienst (GGD) beiden tot aparte dienst van de gemeente Eindhoven gerekend worden. Het is echter zo dat de dienst BCB en vanaf 1 januari 2006 ook de GGD op ICT-gebied autonoom zijn en op regionaal gebied opereren. Om deze redenen worden BCB en GGD vaak niet tot een vakdienst gezien van de gemeentelijke organisatie van Eindhoven, maar meer als zelfstandige organisaties die ook buiten Eindhoven opereren. Om de reden dat de BCB en GGD vanaf 1 januari 2006 verantwoordelijk zijn voor hun eigen besluitvorming op het gebied van de aanschaf van software en andere ICT gerelateerde zaken, zijn zij ook verder niet betrokken bij dit onderzoek.
30
Alle lagen waaruit de gemeentelijke organisatie Eindhoven bestaat kunnen worden weergegeven in een organogram, die hieronder staat afgebeeld:
Figuur 3: Organogram gemeentelijke organisatie Eindhoven (Website gemeente Eindhoven)
Bij de gemeente Eindhoven werken meer dan 2000 mensen, waarvan er bij de dienst APZ 634 werkzaam zijn, bij de dienst MO 362, bij de dienst SOB 419 en bij de dienst WZI 387. In bovenstaande organogram is te zien dat alle diensten onder de Concernstaf vallen. De Concernstaf verzorgt onder andere het procesmanagement en voor gemeentebrede projecten het programmamanagement. Daarnaast verzorgt men de informatievoorziening, ook op ICT gebied, en stelt men samen met het Facilitair Bedrijf
de technische en
productstandaarden op voor de ICT-infrastructuur van de gemeentelijke organisatie. Netwerken, servers, besturingssystemen, werkplekken, printers en applicaties zijn allemaal onderdelen van een ICT-infrastructuur. Voor alle besluiten die in de gemeentelijke organisatie genomen worden, moet de Concernstaf verantwoording afleggen richting Burgemeester en Wethouders en het bestuur (Gemeentesecretaris en Concerndirectie). Het Decision Making Unit (DMU) is het besluitorgaan dat de besluiten controleert en formeel goedkeuring ervoor geeft. Het DMU bestaat uit: de heer Kees Langerwerf, Gemeentesecretaris, de heer Theo Stevens,
31
directeur van de dienst APZ, mevrouw Trees van Haarst, directrice van de dienst WZI, de heer Peter de Wit, hoofd Informatie & Procesmanagement (Concernstaf), de heer Klaas Rodenburg, sectorhoofd FB, en beleidsmedewerker Theo Edenburg (Facilitair Bedrijf). Het doel van een organogram is om de structuur en de hiërarchie van een organisatie helder en overzichtelijk weer te geven. Hier zijn echter volgens Mintzberg kanttekeningen bij te maken. Mintzberg (1992) beschrijft in zijn boek Organisatiestructuren dat een organogram een controversiële weergave van de structuur is: “(...) hoewel de meeste organisaties het nog steeds onmisbaar vinden, zijn veel organisatiedeskundigen van mening dat het niet juist weergeeft wat zich werkelijk afspeelt binnen de organisatie. Het is duidelijk dat in iedere organisatie belangrijke machts- en communicatierelaties bestaan die niet op papier gezet worden” (ibid.: 21). Ondanks dat uit een organogram niet duidelijk wordt welke belangrijke machts- en communicatierelaties er binnen organisaties bestaan, is Mintzberg wel van mening dat een organogram niet zonder meer van de hand gewezen mag worden: “Ook al toont het organogram de informele relaties niet, het geeft wel een nauwkeurig beeld van de arbeidsverdeling, waarbij men in één oogopslag ziet 1) welke posities er bestaan in een organisatie 2) hoe deze tot eenheden gegroepeerd zijn en 3) hoe de stroom van formeel gezag daartussen loopt” (ibid.: 21). En om deze reden heb ik er ook voor gekozen om de organogram van de organisatiestructuur en -hiërarchie van de gemeente Eindhoven op te nemen in deze thesis. Het is overigens opvallend en verbazingwekkend dat het FB niet is opgenomen in het organogram. Volgens de officiële structuur maakt het FB deel uit van de dienst APZ, maar speelt een zeer belangrijke rol in het functioneren van de gemeentelijke organisatie. Immers, het FB vervult de facilitaire dienstverlening voor de hele organisatie. Waarom heeft men ervoor gekozen deze dienst niet apart te vernoemen in het organogram? In de volgende paragrafen zal verder worden ingegaan op het FB en de verschillende diensten, waar de gemeentelijke organisatie van Eindhoven uit bestaat. Ook zal de rol beschreven worden, die de verschillende diensten vervullen binnen de gemeentelijke organisatie.
3.1.1 Dienst Algemene en Publiekszaken De dienst Algemene en Publiekszaken (APZ) is de dienst die het directe contact met de burger heeft. De dienst APZ is actief op vier sectoren, te weten de sector Publiekszaken, de sector Stadsdeelkantoren, de sector Advisering en Ondersteuning en het Facilitair Bedrijf. 32
De sector Publiekszaken verzorgt paspoorten, rijbewijzen en de burger kan hier ook terecht heeft voor de aangifte van een geboorte of het sluiten van een huwelijk, voor kapvergunningen en voor het willen organiseren van een evenement. Deze sector heeft dus met name te maken met de burgers van Eindhoven als klant. Voor bewoners, organisaties en instellingen in de stadsdelen Tongelre, Stratum, Gestel, Strijp, Woensel-Noord en Woensel-Zuid vormt het stadsdeelkantoor die in ieder stadsdeel te vinden is het eerste aanspreekpunt. De verantwoordelijkheid van de stadsdeelkantoren is het verzorgen van een goede service van de gemeente naar de burger, waarbij snel en goed op vragen en klachten van de bewoners gereageerd moet worden. Hierbij staat het verbeteren van de woon- en leefomgeving in de verschillende wijken centraal. De sector Advisering en Ondersteuning adviseert en ondersteunt het bestuur en de interne organisatie van de gemeente Eindhoven, waarbij gestreefd wordt naar het tot stand brengen van een optimale samenwerking tussen de gemeente en de burgers van Eindhoven. Vanuit de sector Advisering en Ondersteuning wordt tevens gewerkt aan de promotie van de stad en het informeren van de burgers over ontwikkelingen en activiteiten van de gemeente. Daarnaast verrichten zij onderzoek om het gemeentebeleid richting te geven, houden zich bezig met de ontwikkeling van het eigen personeel en onderhouden internationale relaties met de 'zustersteden' van Eindhoven. Tevens draagt deze sector zorg voor een veilige stad en de juridische advisering op een breed scala van gemeentelijke activiteiten. Het FB maakt ook deel uit van de dienst Algemene en Publiekszaken. Het FB is verantwoordelijk voor de levering van producten en diensten aan de totale interne organisatie van de gemeente Eindhoven op het gebied van onder andere onderhoud gebouwen, beveiliging, catering, postverzorging, receptie, inkoop, drukwerk, telefonie, personeelszaken, arbeidsvoorwaarden en technisch ICT beheer. Ook verzorgt het FB producten en diensten aan instellingen, zoals de Stadsschouwburg, waar de gemeente nauw mee verbonden is. In paragraaf 3.1.5 zal verder worden ingegaan op het FB.
3.1.2 Dienst Maatschappelijke Ontwikkeling De dienst Maatschappelijke Ontwikkeling (MO) bestaat, net als de dienst Algemene en Publiekszaken, ook uit diverse sectoren. Het betreft de sectoren Kunst en Cultuur, Onderwijs en educatie, Sport en recreatie en Welzijn. De sector Kunst en Cultuur houdt zich onder andere bezig met het beheer (financieel en 33
inhoudelijk) van de relatie met de door de gemeente Eindhoven gesubsidieerde culturele instellingen en het beheer van de regeling amateurkunst. Daarnaast houdt de sector Kunst en cultuur zich ook bezig met de uitvoering van kunsttoepassingen in de openbare ruimte, het beheer van de kunstwerken, de kunst in de wijken van Eindhoven en archeologisch onderzoek. De sector Onderwijs en Educatie bestaat uit de afdeling Integraal Gemeentelijk Onderwijsbeleid en de afdeling Financieel Materiële Onderwijszaken. De afdeling Integraal Gemeentelijk Onderwijsbeleid houdt zich met name bezig met het ontwikkelen van het lokale onderwijsbeleid, de handhaving van de leerplichtwet en het leerlingenvervoer. De taken van de afdeling Financieel Materiële Onderwijszaken zijn gericht op een integraal huisvestingsplan en onderhoudsplanningen van de onderwijsgebouwen. De sector Sport en Recreatie houdt zich naast ontwikkeling en advisering over het gemeentelijk
sport-
en
recreatiebeleid
tevens
bezig
de
uitvoering
van
diverse
sportsubsidieregelingen, de ontwikkeling van speciale sportprogramma’s en het verzorgen van promotie en voorlichting over sport. Tevens verzorgt men sportactiviteiten, speciale sportprogramma’s en arrangementen en regelt men het verhuur en onderhoud van de gemeentelijke sportaccommodaties. Verder ligt bij deze sector de verantwoordelijkheid voor
het
beheer
en
de
exploitatie
van
de
gemeentelijke
binnen-
en
buitensportaccommodaties, zwembaden en de kunstijsbaan. Tot slot bestaat de sector Welzijn van de dienst MO uit een beleidsafdeling en Bureau Halt. In de beleidsterreinen Stedelijke en Gebiedsgericht Welzijn, Kinderopvang, Vrijwilligers, Maatschappelijke en Vrouwenopvang, Verslavingszorg en Nieuwkomers en Asielzoekers houdt de beleidsafdeling zich bezig met planontwikkeling in het welzijnsveld, onderzoek en ontwikkeling, beleidscontrole en het opstellen van contracten met de instellingen. Daarnaast richt Bureau Halt zich op de aanpak en preventie van veelvoorkomende jeugdcriminaliteit in de regio Brabant-Zuidoost.
3.1.3 Dienst Stedelijke Ontwikkeling en Beheer De dienst Stedelijke Ontwikkeling en Beheer (SOB) heeft tot doel het creëren en in stand houden van een stad met een goed woon-, werk- en leefklimaat. De dienst is verantwoordelijk voor de ontwikkeling en aanpassing van de stad, waarbij onder andere ruimtelijke
ordening,
volkshuisvesting,
verkeer
en
vervoer,
riolering,
milieu,
afvalinzameling en groenvoorzieningen een belangrijke rol spelen. Tevens vallen het onderhoud en het beheer van de openbare ruimte in Eindhoven en de beoordeling van 34
bouwvergunningen onder de verantwoordelijkheid van deze dienst. Al deze taken zijn verdeeld over de sectoren Strategie, Planontwikkeling, Bouw- en Woningtoezicht en Realisatie. De sector Strategie binnen de dienst Stedelijke Ontwikkeling en Beheer houdt zich bezig met het opstellen van visies over de ontwikkeling van de stad en het maken van beleid voor de ontwikkeling en het beheer. Dit betreft over het algemeen plannen waarin de grote lijnen worden verwoord. Ook kijkt de sector Strategie naar de middelen (bijvoorbeeld financiën) die nodig zijn en de stappen die gezet moeten worden om de gewenste resultaten te bereiken. De sector Planontwikkeling heeft als taak om de, in het algemeen globale, (beleids-) visies van de sector Strategie te vertalen in concrete plannen. Hierbij gaat het bijvoorbeeld om uitwerkingen die over een specifiek gebied gaan of om meer concrete projecten. Daarnaast worden ook de initiatieven en ontwikkelingen van anderen, bijvoorbeeld projectontwikkelaars, beoordeeld en begeleid door de sector Planontwikkeling. Het is bij de planontwikkeling belangrijk dat Eindhoven zich op een goede manier ontwikkelt en daarbij is de beleving van de stad door de inwoners en andere belanghebbenden, zoals bedrijven, heel belangrijk. Ook speelt de toekomst van Eindhoven een belangrijke rol in de concrete plannen. Binnen de sector Realisatie worden de plannen van de sector Planontwikkeling omgezet in uitvoerende werkzaamheden. Tot deze werkzaamheden behoren bijvoorbeeld het laten aanleggen
van
nieuwe
infrastructuur
zoals
wegen,
riolering,
openbaar
groen,
speelvoorzieningen et cetera, maar ook het laten onderhouden of herstellen van de bestaande infrastructuur. De sector Realisatie regelt met name de voorbereidende werkzaamheden, zoals het maken van bestekken voor aannemers, het adviseren over systemen voor de waterhuishouding en het regelen van verkeersomleidingen. Tevens worden tijdens de uitvoering de werkzaamheden door de sector Realisatie begeleid en nadien gecontroleerd. Daarnaast controleert deze sector op de juiste naleving van (wettelijke) regels op het gebied van ruimtelijke ordening, bouwen en wonen en ingrepen in de openbare ruimte. Verder maakt het Parkeerbedrijf, dat onder andere gaat over de gemeentelijke parkeergarages en openbare parkeerplaatsen in de stad, ook onderdeel uit van de sector Realisatie. De sector Bouw- en Woningtoezicht binnen de gemeente Eindhoven is verantwoordelijk voor een goede architectonische, monumentale, ruimtelijke en/of duurzame kwaliteit van de gebouwen in Eindhoven. In onder andere de Woningwet, de Wet Ruimtelijke Ordening
35
en de Monumentenwet worden de regels beschreven voor het bewaken van de kwaliteit. Ook behoort het toetsen van de aanvragen voor vergunningen tot één van de taken van de sector Bouw- en Woningtoezicht. Daarnaast controleert men op het naleven van de wet- en regelgeving van de hiervoor genoemde wetten, en controleert men de bouwkundige kwaliteit, veiligheid, gezondheid, bruikbaarheid, energie-zuinigheid en de milieuaspecten van gebouwen.
3.1.4 Dienst Werk, Zorg en Inkomen De dienst Werk, Zorg en Inkomen (WZI) onderscheidt zich van de andere diensten. Waar de andere diensten beleidsdiensten zijn, noemt de heer Arend Zwaga, sectorhoofd van de bedrijfsondersteuning binnen WZI op het gebied van onder andere ICT en telefonie, de dienst WZI een productiedienst: “WZI is, in tegenstelling tot de andere diensten, eerder een fabriek te noemen. Dit vanwege de taken die WZI vervuld, zoals het begeleiden van cliënten naar betaald werk en het verwerken van aanvragen voor een bijstandsuitkering”. WZI produceert, meer nog dan de dienst APZ waar het Stadskantoor voor het aanvragen van paspoorten en rijbewijzen slechts deel vanuit maakt. De taak van de dienst WZI omvat het begeleiden van cliënten naar betaald werk, via arbeidsactivering, gesubsidieerde arbeid en werkervaringstrajecten. Ook concentreert deze dienst zich op de zorgvraag van cliënten en voert een aantal zorgregelingen uit, waaronder de Wet voorzieningen gehandicapten, de Wet Inburgering Nieuwkomers, de Wet
Reïntegratie
Arbeidsgehandicapten,
het
gemeentelijk
armoedebeleid
en
schuldhulpverlening. Daarnaast verstrekt het uitkeringen voor levensonderhoud en bijzondere kosten. Al deze werkzaamheden zijn binnen de dienst WZI verdeeld over twee sectoren, te weten de sector Werk en Inkomen en de sector Zorg en Inkomen. Bij het Centrum voor Werk & Inkomen (CWI), dat onder de sector van Werk en Inkomen valt en als samenwerkingspartner gevestigd is binnen de dienst WZI, kunnen aanvragen voor een bijstandsuitkering ingediend worden. Door consulenten van het CWI wordt dan de aanvraagprocedure gestart en wordt door de medewerkers van WZI bekeken of iemand recht heeft en houdt op een uitkering. Ook krijgen de cliënten begeleiding om (weer) aan de slag te kunnen. Verder kunnen aanvragen voor bijzondere bijstand bij de dienst WZI of bij de Stadsdeelkantoren gedaan worden. Binnen
de
sector
Zorg
en
Inkomen
wordt
door
consulenten
het
gemeentelijk
armoedebeleid uitgevoerd. Hier wordt onder andere nauw samengewerkt tussen consulenten, artsen, bouwkundigen en ergotherapeuten bij de aanvragen voor de Wet 36
Voorzieningen Gehandicapten (WVG). Ook is men binnen deze sector verantwoordelijk voor de begeleiding van nieuwe allochtone inwoners. Tevens voert deze sector controle uit en behoort onder andere het terugvorderen van teveel of onterecht ontvangen uitkeringen tot de werkzaamheden. De dienst zelf is overigens op een andere manier ingericht dan de andere diensten, onder andere op het gebied van ICT. Naast het feit dat men met de nieuwbouw van de dienst WZI bezig was, had de vorige directeur van WZI, mevrouw Ria Doedel, als motto "WZI-Eindhoven: de modernste gemeentelijke dienst van Nederland". Ze wist daarbij haar ambitie ook om te zetten in daden. Zo heeft de heer Rob Wijbenga, die als senior beleidsmedewerker verantwoordelijk is voor het organisatie- en informatiebeleid van WZI, mij rondgeleid door de vakdienst en laten zien hoe de medewerkers van de dienst WZI gebruik maken van zeer moderne IT-technologie. Opvallend is dat de medewerkers van deze vakdienst geen vaste werkplek hebben. Daar waar bij andere diensten sprake is van een ware verhuizing wanneer een medewerker wisselt van werkplek, zitten de medewerkers binnen WZI iedere dag op een andere plek en hebben zij ook vanaf iedere werkplek op een computer toegang tot hun bestanden op het netwerk. Zo zie je elke dag weer andere collega’s en zijn de bureaus aan het einde van iedere werkdag helemaal opgeruimd. Alle werkplekken zijn overigens ook op dezelfde wijze ingericht en iedereen maakt in principe gebruik van dezelfde faciliteiten. (Wijbenga, 2005). Het motief van mevrouw Doedel was dat ze directeur wilde zijn van een moderne dienst, en daarbij doelde ze niet alleen op een dienst in een mooi nieuw gebouw, met goede faciliteiten, maar met name op een dienst waar mensen op een moderne manier werken en optimaal gebruik maken van de mogelijkheden die techniek biedt. Mevrouw Doedel was echter de directeur van de dienst WZI en niet van de gemeente. Het is dus aan de directeuren van overige diensten zelf om deze plannen ook door te voeren. Men heeft echter niet besloten mevrouw Doedel hierin te volgen en is op de oude voet doorgegaan.
3.1.5 Facilitair Bedrijf Naast de diensten APZ, MO, SOB en WZI is er binnen de organisatie tevens een Facilitair Bedrijf aanwezig. Het FB verzorgt de facilitaire dienstverlening voor de gemeente Eindhoven en instellingen, zoals de Stadsschouwburg, waar de gemeente nauw mee verbonden is. De faciliteiten betreffen praktische voorzieningen, die nodig zijn ter ondersteuning van het werk. Alles op het gebied van onder andere onderhoud gebouwen, beveiliging, catering, 37
postverzorging,
receptie,
inkoop,
drukwerk,
telefonie,
personeelszaken,
arbeidsvoorwaarden en technisch ICT beheer wordt vanuit het FB geregeld. Er is voor de genoemde taken geen eigen ondersteunend personeel meer aanwezig binnen de verschillende vakdiensten, maar alle functies zijn bij het FB centraal ondergebracht. De verschillende vakdiensten van de gemeente Eindhoven worden als klanten beschouwd van het FB, die hun voorziet van alle producten en diensten op ICT gebied. Dit is overigens ook het grote verschil tussen het FB en de andere diensten. Het FB is namelijk de meest marktgerichte dienst, omdat het zich richt op wat de klant vraagt. Het is de leverancier van dienstverlening aan haar klanten, de andere diensten, op tal van vlakken zoals ICT. Binnen het FB is ook een onderverdeling te maken, die hieronder staat afgebeeld:
Figuur 4: Organogram Facilitair Bedrijf
De afdeling Inkoop gaat over de inkoop van allerlei zaken, die een organisatie zoals de gemeentelijke organisatie van Eindhoven nodig heeft om te kunnen functioneren. Het FB beschikt verder over de afdeling Management Ondersteuning, die gaat over de organisatieontwikkeling en het beleid en verantwoordelijk is voor haar bestuur. Daarnaast beschikt het FB over een Front Office en een Back Office. Bij het Front Office vindt de dienstaanvraag van de klant plaats via de balie, post, fysiek loket of het digitaal loket. In het Back Office vindt de afhandeling van de dienstaanvraag plaats en binnen dit deel van de gemeentelijke organisatie vindt geen direct contact met de klant plaats. Kort samengevat: het Front Office zet vraag van de klant om in een opdracht, waarna het Back Office de opdracht vervolgens gaat uitvoeren.
38
In het Back Office vinden we drie afdelingen: de afdeling Gebouwen & Services, de afdeling Functioneel Beheer & Ondersteuning en de ICT-afdeling. De afdeling Gebouwen & Services neemt de huishoudelijke taken op zich wat betreft de werkplekken, de bedrijfskantine, enzovoorts. De afdeling Functioneel Beheer & Ondersteuning gaat naast het functioneel beheer ook over allerlei andere zaken die met software te maken hebben, zoals op inhoudelijk vlak bepalen hoe de huisstijl eruit moet zien. De derde belangrijke afdeling in het Back Office van het FB is de ICT-afdeling. Deze afdeling beheert en onderhoudt de gemeentelijke servers, de computers, het netwerk en de applicaties van de hele gemeente. Overkoepelend aan deze drie afdelingen is er nog het Projectbureau en de afdeling Advies. In het Projectbureau worden de opdrachten vanuit het Front Office omgezet in projecten. Dit kan van alles zijn, maar meestal betreft het ICT-projecten. De heer Boris Liebrand noemt als voorbeeld van projecten waar men momenteel mee bezig is: de aanleg van glasvezel in Eindhoven en de vervanging van het huidige Office 97 pakket. Naast een ondersteunende rol vervult het FB tevens een adviserende rol, onder andere bij de aanschaf van nieuwe software. Hier gaat de afdeling Advies binnen het Back Office over. Aangezien de precieze rol van het FB bij besluitvormingsprocedures alles te maken heeft met de algemene organisatiekarakteristieken van de gemeente Eindhoven, en met het specifieke beheermodel dat het FB hanteert, zal ik de rol van het FB uitgebreider behandelen in hoofdstuk vier. Allereerst zal ik in de volgende paragraaf ingaan op de organisatiekarakteristieken die er te onderscheiden zijn.
3.2 Organisatiestructuren In de bedrijfskunde en organisatiekunde is het gebruikelijk om organisaties te typeren aan de hand van modellen die organisatiestructuren beschrijven. In deze paragraaf ga ik in op een dergelijk model dat hulp biedt bij het kunnen typeren van organisaties, om vervolgens te proberen de vinger te leggen op wat voor soort organisatie de gemeente Eindhoven nu eigenlijk is.
3.2.1 Structuurconfiguraties Er zijn meerdere structuurconfiguraties te onderscheiden, die in dit hoofdstuk beschreven zullen worden om tot een oordeel te komen van wat voor type organisatie de gemeente Eindhoven is. Volgens Mintzberg (1992) zou een beperkt aantal configuraties voldoende zijn om te verklaren waarom organisaties zo gestructureerd zijn als ze zijn (ibid.: 3). 39
De meest voorkomende structuurconfiguraties volgens Mintzberg zijn: de eenvoudige structuur, de machinebureaucratie, de professionele bureaucratie, de divisiestructuur en de adhocratie (ibid.: 24, 25). Deze configuraties verschillen onder andere allemaal wat betreft coördinatiemechanismen. Mintzberg definieert coördinatiemechanismen als volgt: “Coördinatiemechanismen verklaren de fundamentele wijzen waarop organisaties hun werkzaamheden coördineren. (...) Deze mechanismen kan men beschouwen als de meest basale elementen van een structuur, als de lijm die de organisaties bijeenhoudt” (ibid.: 4). Bij bijvoorbeeld een winkel van gemiddelde grootte kunnen we spreken van een eenvoudige
structuur.
Het
coördinatiemechanisme
dat
kenmerkend
is
voor
een
eenvoudige structuur is het directe toezicht; de belangrijke beslissingen worden over het algemeen centraal genomen door de persoon die aan de top staat. Meestal staat er één persoon aan de top, is er slechts een kleine hiërarchie van managers, is er verder weinig ondersteunend personeel aanwezig en bestaat er een losse arbeidsverdeling. Er wordt slechts minimaal gebruik gemaakt van een planning, is er weinig training en taakspecialisatie en bestaat er weinig geformaliseerd gedrag. (ibid.: 166-171) De
tweede
organisatiestructuur
is
de
machinebureaucratie.
Het
primaire
coördinatiemechanisme bij een machinebureaucratie is de standaardisatie van het werk. Binnen dergelijke organisaties bestaat sterk gespecialiseerd routinewerk, zijn er in de uitvoerende kern sterk geformaliseerde procedures en is er uitgebreide bestuurlijke structuur met daarbinnen een sterk onderscheid. In de gehele organisatie bestaan vele regels, voorschriften en is er geformaliseerde communicatie. Deze structuur zullen we aantreffen
bij
grote
bedrijven,
bijvoorbeeld
een
grote
autofabriek
of
een
luchtvaartmaatschappij. De machinebureaucratie functioneert met name in ‘volwassen’ organisaties, die groot genoeg zijn voor de hoeveelheid werk die nodig is. Het werk zelf wordt gekenmerkt door herhaling en standaardisatie. (ibid.: 172-185) Verder treffen we bij complexe, stabiele omgevingen zoals onderwijsinstellingen, sociale instellingen en universiteiten de professionele bureaucratie aan. Binnen deze structuur is er,
evenals
in
de
machinebureaucratie,
sprake
van
een
standaardisatie
van
beroepsvaardigheden. Het grote verschil is echter de herkomst van de standaardisatie. De machinebureaucratie
brengt
haar
eigen
normen
voort,
oftewel
door
iedere
machinebureaucratische organisatie zelf wordt bepaald hoe het werk uitgevoerd moet worden. Echter, bij een professionele bureaucratie ontstaan de normen grotendeels buiten de eigen structuur, bijvoorbeeld in onafhankelijke beroepsorganisaties. Zo wordt niet binnen ieder ziekenhuis zelf bepaald hoe operaties moeten worden uitgevoerd, maar worden de voorschriften door een overkoepelende organisatie opgesteld. Het betreft een
40
bureaucratische structuur, waarbij voor de coördinatie van tevoren wordt vastgelegd wat er moet gebeuren. (ibid.: 199-216) Bij de divisiestructuur is het middenkader het voornaamste deel van de organisatie. Ook bij de divisiestructuur is het primaire coördinatiemechanisme standaardisatie, maar dan niet van de werkprocessen maar van de output. De divisies krijgen de bevoegdheid om zelf eigen activiteiten te runnen en eigen beslissingen te nemen, en daarbij worden de resultaten
van
de
genomen
beslissingen
gecontroleerd
door
het
hoofdkantoor.
(ibid.: 226-244) Tot slot als vijfde voorkomende structuur de adhocratie. In tegenstelling tot de machinebureaucratie en de professionele bureaucratie die beiden prestatiestructuren zijn en niet gericht op probleemoplossing, is er binnen de adhocratie geen sprake van standaardisatie
omdat
de
werkzaamheden
innovatief
moeten
zijn.
Het
primaire
coördinatiemechanisme van de adhocratie is onderlinge aanpassing. Het werk wordt verricht in verschillende projectgroepen, waarbij de specialisten hun krachten bundelen in multidisciplinaire teams. Er is bij deze configuratie niet zozeer een concentratie van macht in de uitvoerende kern, maar eerder een gelijke verdeling van macht over alle niveaus van de organisatie. De adhocratie steunt op hoogopgeleide experts, die overal in de organisatiestructuur te vinden zijn: de ondersteunende diensten, de leidinggevende posities en de uitvoerende kern. Informatieoverdracht en besluitvormingsprocessen vinden op flexibele en informele wijze plaats, daar waar dat nodig is om innovatie mogelijk te maken. Bij onder andere bedrijven als NASA en Boeing is sprake van een adhocratie. (ibid.: 267-290) Mintzberg heeft de opzet van zijn boek afgestemd op managers, stafspecialisten en consultants, die te maken hebben met het structuren van organisaties. Het boek introduceert en bundelt de kerngedachten van het onderzoek naar wat nodig is om een, zoals Mintzberg het omschrijft, effectieve organisatie te ontwerpen (ibid.). Ik heb echter ook een kanttekening over een kwestie die ontbreekt in de typologie, die in het boek Organisatiestructuren beschreven wordt. In deze typologie wordt namelijk geen rekening gehouden met de verschillen die er zijn tussen organisaties van hetzelfde type. Organisaties van eenzelfde type worden in deze typologie gegeneraliseerd, over één kam geschoren, door ze tot één bepaalde configuratie toe te schrijven. Ik ben van mening dat niet iedere organisatie zo maar te verbinden is aan één configuratie, en dat niet alle kenmerken uit een configuratie van toepassing zijn op één organisatie. Mijn verwachting over
de
gemeentelijke
organisatie
van
Eindhoven
is
dat
het
name
een
machinebureaucratie betreft, maar echter ook over kenmerken beschikt uit andere
41
configuraties die in deze paragraaf besproken zijn. In paragraaf 3.2.2 zal ik hier verder op ingaan.
3.2.2 De structuurconfiguratie van de gemeente Eindhoven Naar aanleiding van de literatuur van Mintzberg (1992) is het moeilijk te benoemen welke van de hiervoor beschreven configuraties van toepassing is op de gemeentelijke organisatie van Eindhoven. Het is een complexe organisatie en uit meerdere configuraties zijn er kenmerken die van toepassing zijn op de gemeente Eindhoven. Daarnaast twijfelt Mintzberg zelf aan de configuraties. In het laatste hoofdstuk van zijn boek zegt hij het volgende hierover: "In zekere zin bestaan de configuraties helemaal niet. Uiteindelijk zijn het maar woorden en tekeningen op papier en niet de realiteit. Echte organisaties zijn enorm complex, veel complexer dan welk van deze papieren configuraties dan ook. Zij staan voor een theorie en elke theorie simplificeert de werkelijkeid en geeft die dus vertekend weer" (ibid.: 298). Van de configuraties die Mintzberg in zijn boek beschrijft is er niet één typerend voor de organisatie van de gemeente Eindhoven. De gemeentelijke organisatie van Eindhoven is eerder een combinatie van meerdere configuraties, namelijk de machinebureaucratie, de professionele bureaucratie en de adhocratie. Ook Mintzberg concludeert in het laatste hoofdstuk van zijn boek dat mengvormen van meerdere configuraties voorkomen: "Wij hebben gezien dat niet alle organisaties ervoor kiezen consistent te zijn bij het ontwerp van de structuur (...). Zij gebruiken hybride structuren, mengvormen die kenmerken van meerdere configuraties vertonen" (ibid.: 304). Het machinebureaucratische karakter van de gemeente Eindhoven vinden we terug in het primaire coördinatiemechanisme van deze organisatie, namelijk de standaardisatie van de werkzaamheden door het gebruik van de ITIL-beheermethodiek. In paragraaf 4.1 zal uitgelegd worden wat de ITIL-beheermethodiek precies inhoudt. Door het gebruik van de ITIL-beheermethodiek is sprake van sterk geformaliseerde procedures in de uitvoerende kern van de organisatie. Medewerkers van de gemeente Eindhoven ervaren de ITIL-beheermethodiek als bureaucratisch. In paragraaf 4.3.1.2 en 4.4 wordt ter discussie gesteld dat de standaard manier van werken met behulp van de ITIL-beheermethodiek niet altijd voor een makkelijke manier van werken zorgt door een overvloed aan regels en voorschriften. Een ander kenmerk waarin de gemeente Eindhoven als machinebureaucratie voldoet aan 42
de criteria van Mintzberg, is dat het een grote en volwassen organisatie betreft die groot genoeg is voor de hoeveelheid uitvoerend werk die nodig is voor herhaling en standaardisatie en daarnaast oud genoeg is om te hebben besloten welke normen men wil gebruiken (Mintzberg, 1992: 172, 180). Echter, de gemeente Eindhoven bepaalt natuurlijk tot op zekere hoogte de normen met betrekking tot de uitvoering van de werkzaamheden, want het betreft hier natuurlijk nog altijd een organisatie die in dienst is van de overheid. Grotendeels
worden
door het
overkoepelende
orgaan,
de
Nederlandse
regering,
voorschriften opgesteld die bepalen wat voor soort werkzaamheden uitgevoerd dienen te worden. Zo zou een gemeentelijke organisatie bijvoorbeeld nooit mogen stoppen met het uitgeven van paspoorten en rijbewijzen en het bedienen van de verkeerslichten in de stad. Kortweg bepaalt de regering wat een gemeentelijke organisatie moet doen en gaat de gemeentelijke organisatie zelf over hoe deze werkzaamheden worden uitgevoerd. De gemeentelijke organisatie van Eindhoven voldoet op dit punt aan de criteria van Mintzberg om ook een professionele bureaucratie genoemd te worden (ibid.: 201). Zoals ik al aangaf zijn er ook kenmerken van de configuratie adhocratie van toepassing op de gemeentelijke organisatie van Eindhoven. Er zijn diverse punten waarop de gemeentelijke organisatie van Eindhoven voldoet aan de criteria die Mintzberg noemt, namelijk als er in de machinebureaucratie een beslissing genomen moet worden er iemand van bovenaf een bevel geeft en het dan ook gebeurt (bijvoorbeeld aanpassingen maken in het Gemeentelijke Basis Administratie voor persoonsgegevens naar aanleiding van plannen van het Ministerie van Binnenlandse Zaken, zie paragraaf 4.3). Daarnaast is er een verdeling van de macht over meerdere niveaus van de organisatie. Binnen de gemeentelijke organisatie van Eindhoven is de bevoegdheid tot het nemen van besluiten verdeeld over managers en niet-managers op verschillende niveaus van de hiërachie. Een goed voorbeeld hiervan is het Office Migratie Project, waarbij diverse mensen (zoals de IPMers van alle afzonderlijke diensten en specialisten zoals de ICT-adviseurs) betrokken werden. Binnen de projectgroep waarin gewerkt werd voor het Office Migratie Project, een manier van werken die ook kenmerkend is voor een adhocratie, werd uiteindelijk een besluit genomen waar de gehele projectgroep zich achter kan scharen. Meer over het Office Migratie Project in paragraaf 5.3. Iets dat ook kenmerkend is voor een adhocratie en dat Mintzberg in zijn boek noemt, is de aanwezigheid van vele managers binnen de gemeentelijke organisatie van Eindhoven. Er zijn in Eindhoven projectmanagers, managers voor de verschillende ITIL-processen (procesmanagers), sectormanagers, casemanagers, etc. Toelichting op deze verschillende managers is te vinden in paragraaf 4.1.2.
43
Mintzberg stelt dat er op de adhocratie allerlei krachten inwerken "die ertoe leiden dat de organisatie met het ouder worden ook bureaucratischer wordt (ibid.: 287)". Dat de gemeentelijke organisatie van Eindhoven nu een bureaucratische organisatie is is juist, maar of het in haar jongere jaren ook een adhocratie was kan ik uiteraard moeilijk bepalen. Samenvattend is enerzijds de organisatie een adhocratie te noemen op grond van het feit dat werk verricht wordt in verschillende projectgroepen (bijvoorbeeld de projectgroep die zich bezighoudt met de aanleg van glasvezel in Eindhoven, zie paragraaf 3.1.5, en de projectgroep die in het leven is geroepen voor het Office Migratie Project, zie paragraaf 5.3) en dat de bevoegdheid tot het nemen van besluiten rond de aanschaf van software verdeeld is op verschillende niveaus van de hiërachie (de formele en niet-formele goedkeurders, zie paragraaf 4.3.1.2). Anderzijds is er binnen een adhocratie geen plaats voor standaardisatie, hetgeen echter wél het geval is binnen de gemeente Eindhoven (zie paragraaf 4.1 en 4.2) en daarmee is er dus ook sprake van een machinebureaucratie. Bovendien vertoont de organisatie meerdere kenmerken van een bureaucratie (zie ook paragraaf 4.3.1.2), waarbinnen van een adhocratie geen sprake zou mogen zijn. Tot slot is de gemeentelijke organisatie van Eindhoven ook een professionele bureaucratie te noemen, daar zij in dienst zijn van de overheid die als overkoepelend orgaan de voorschriften met betrekking tot de werkzaamheden van de organisatie voorschrijft. Concluderend kunnen we stellen dat aan de hand van de typologie van Mintzberg de gemeentelijke organisatie van de gemeente Eindhoven te beschrijven is aan de hand van kenmerken van drie verschillende configuraties en er een nieuw concept geïntroduceerd kan worden, namelijk die van een professionele adhoc bureaucratie. Bij een organisatie is sprake van deze configuratie als het een grote, volwassen organisatie betreft die groot genoeg is voor de hoeveelheid uitvoerend werk die nodig is voor herhaling en standaardisatie en daarnaast oud genoeg is om te hebben besloten welke normen men wil gebruiken. Verder is kenmerkend voor deze configuratie dat het werk in verschillende projectgroepen wordt verricht. Naast dat iemand van bovenaf bevelen geeft, is er tevens een verdeling van de macht over meerdere niveaus van de organisatie en zijn er vele managers aanwezig. Tot slot is er in de professionele adhoc bureaucratie sprake van een overkoepelend orgaan, waarvan de organisatie in kwestie onder het bestuur valt.
44
4. Besluitvorming rond de aanschaf van software In dit hoofdstuk wordt ingegaan op de wijze waarop bij gemeentelijke organisaties een besluitvormingsproces van a tot z (van aanleiding tot besluit) verloopt rond de aanschaf van software. Primair zal hier worden ingegaan op de gemeentelijke organisatie van Eindhoven en het relevante beleid van deze organisatie met betrekking tot de aanschaf van software. Er
zal
worden
ingegaan
op
de
diverse
personen
en
wat
hun
rol
is
in
de
besluitvormingsprocessen, aan de hand van de verschillende lagen die te onderscheiden zijn in de organisatiestructuur van de gemeente Eindhoven. In dit hoofdstuk wordt tevens de vraag beantwoord op welke wijze in de besluitvorming open source software wordt meegenomen als mogelijk alternatief voor de vervanging van de huidige software. Daarop volgend wordt er een vergelijking gemaakt met andere gemeenten en worden de overeenkomsten en verschillen benoemd in de wijze waarop bij hen besluiten genomen worden rond de aanschaf van software.
4.1 IT-beheer bij de gemeente Eindhoven Alvorens in te gaan op de wijze waarop een besluitvormingsproces verloopt rond de aanschaf van software, zal eerst de werkwijze van de gemeente Eindhoven beschreven worden. De werkwijze van de gemeente Eindhoven op ICT gebied heeft niet direct invloed op het nemen van besluiten, maar betreft wel de dagelijkse gang van zaken op ICT gebied en kan/mag vanwege haar prominente rol binnen de gemeente niet buiten beschouwing worden gelaten in het onderzoek. In paragraaf 4.1.1 zal de beheermethodiek besproken worden, waar de gemeentelijke organisatie van Eindhoven mee werkt. De gemeente Eindhoven heeft bewust voor deze en niet een andere beheermethodiek gekozen, omdat deze zich in de loop der tijd heeft bewezen een goede beheermethodiek te zijn.
4.1.1 ITIL-beheermethodiek De gemeente Eindhoven werkt volgens een beheermethodiek, genaamd ITIL, die de dagelijkse gang van zaken in een ICT-bedrijf in processen weergeeft. ITIL, dat staat voor Information Technology Infrastructure Library, betreft het procesgericht denken en werken binnen een ICT-organisatie en levert een gedetailleerde omschrijving van een aantal van 45
de belangrijkste practices (praktijkoplossingen) in een IT-organisatie met uitgebreide checklists, taken, procedures en verantwoordelijkheden. Deze practices zijn zoveel mogelijk in de vorm gegoten van processen. Deze processen geven de belangrijkste activiteiten van een IT-organisatie weer, die betrekking hebben op het Service Management. (ITSMF Nederland, 2002). ITIL is ontstaan naar aanleiding van een opdracht die het Office of Government Commerce (OGC), een onafhankelijk adviesbureau van de Britse schatkist die destijds Central Computer and Telecomunications Agency (CCTA) heette, kreeg om een aanpak te ontwikkelen voor een efficiënte en economische inzet van IT-middelen bij de ministeries en andere organisaties van de Britse overheid. In de jaren tachtig ontdekte men namelijk dat de kwaliteit van de IT-dienstverlening aan de Britse overheid van slecht niveau bleek te zijn. (ibid.: 9) Bij
de
ontwikkeling
van
IT-beheer
heeft
men
zich
met
name
gericht
op
hoe
dienstverlening, kwaliteit, organisatie en beleid verbeterd zouden moeten worden (ibid.: 13). Het dienstverleningsproces is een combinatie van productie en consumptie, waaraan de aanbieder en de afnemer gelijktijdig deelnemen. In dit proces is kwaliteit een belangrijk begrip en is het best te omschrijven als het geheel van eigenschappen en kenmerken van een product of dienst, die van belang zijn voor het voldoen aan de vastgelegde of vanzelfsprekende behoeften (ibid.: 14). Organisatie en beleid hebben onder andere betrekking op het hebben van een visie, het stellen van doelen en het maken van een planning (ibid.: 19-21). Uitgangspunten van de ITIL-beheermethodiek zijn een systematische aanpak van het beheer en een procesmatige benadering van de bedrijfsorganisatie. Via het beheermodel wordt een beeld van de samenhang van werkprocessen (voor met name het beheer van de infrastructuur) onderkend en wordt er een houvast aangeboden om die werkprocessen in te vullen en te optimaliseren. De procesindeling van een organisatie maakt duidelijk wat er moet gebeuren, welke resultaten verwacht worden, hoe gemeten wordt of de processen hun resultaten ook bereiken en hoe de resultaten van het ene proces die van het andere proces zullen beïnvloeden (ibid.: 26). Door uit te gaan van een procesindeling kan vaak inzichtelijk worden gemaakt dat bepaalde activiteiten in de organisatie ongecoördineerd plaatsvinden, dubbel worden uitgevoerd, helemaal niet worden uitgevoerd of eigenlijk overbodig zijn. En door de processen afzonderlijk te bekijken, kan de kwaliteit van elk proces geoptimaliseerd worden (ibid.: 27). De heer Marc Braun, die als Service Manager bij het Facilitair Bedrijf van de gemeente Eindhoven de ITIL-processen bewaakt, legt uit dat de gemeentelijke organisatie van Eindhoven voor ITIL heeft gekozen om zo “op een
46
efficiënte, effectieve en pro-actieve wijze te werk te gaan”. ITIL schrijft overigens niet voor hoe alle activiteiten precies moeten worden uitgevoerd, maar biedt een raamwerk voor het plannen van de meest voorkomende processen, rollen en activiteiten, waarbij aangegeven wordt hoe ze samenhangen en wat voor onderlinge communicatielijnen er nodig zijn (ibid.: 35). In het hoofdstuk “Processen” dat hierna volgt zullen stuk voor stuk de processen besproken
worden,
die
deel
uitmaken
van
het
Service
Support
van
de
ITIL-beheermethodiek.
4.1.2 ITIL-Processen ITIL beschrijft de praktijkoplossingen ter ondersteuning van de toegang van de klant tot de juiste dienstverlening om zijn onderneming te ondersteunen. Tot de ITIL-kern van het IT Service Management worden het Service Support (ondersteuning van IT-diensten) en Service Delivery (levering en planning van IT-diensten) gerekend. (ITSMF Nederland, 2002: 37) Het Service Support beschrijft de practices die een IT-organisatie kan aanbieden ter ondersteuning van de toegang van de klant tot de juiste dienstverlening om zijn onderneming te ondersteunen. Deze practices kunnen beschreven worden in vijf processen: Incident Management, Problem Management, Configuration Management, Change Management en Release Management (ibid.: 39, 40). Mevrouw Trea Karsies, Incidentmanager bij het Facilitair Bedrijf maakt duidelijk dat “op voorhand van de in werking stelling van de processen, de Service Desk een belangrijke rol speelt bij het registreren, afhandelen en bewaken van storingen”. De Service Desk, dat deel uitmaakt van de Front Office in het FB van de gemeente Eindhoven, neemt de meldingen op en indien de Service Desk het probleem van de klant niet direct zelf kan oplossen speelt ze het door. Deze meldingen kunnen variëren van een aanvraag voor een nieuwe pc tot het hebben van problemen met het gebruik van bepaalde software. Het Incident Management (Incidentenbeheer) is verantwoordelijk voor het verhelpen van storingen en om de diensten snel weer te herstellen (ibid.: 40, 45-47). Een melding die is binnengekomen bij het Service Desk komt dan ook als eerste bij het Incident Management terecht, die er vervolgens mee aan de slag gaat. Binnen het Incident Management worden deze
meldingen
omgezet
in
incidenten, 47
die
gedefinieerd
kunnen
worden
als
gebeurtenissen die niet tot de standaardoperatie van een service behoren en die een interruptie of een vermindering van de kwaliteit van die service kan veroorzaken (ibid.: 45). Onder incidenten verstaat ITIL naast hard- en softwarestoringen ook de zogenaamde Service Requests. Een Service Request is “een verzoek van de gebruiker om ondersteuning, levering, informatie, advies of documentatie” (ibid.: 45) en het kan daarbij gaan om bijvoorbeeld een password reset (ibid.: 45, 46). Echter, wanneer ook het Incident Management de storing niet kan verhelpen is er niet langer sprake van een incident maar een problem (bijvoorbeeld een structureel probleem), en hiermee wordt het proces van Problem Management in werking gesteld. Problem Management ondersteunt Incident Management, maar is zelf niet verantwoordelijk voor het oplossen van het incident. Problem Management doet onderzoek om oorzaken voor (potentiële) storingen in de dienstverlening te achterhalen en één van haar activiteiten omvat tevens het preventief zien te vermijden van incidenten door fouten in infrastructuur te verbeteren. Een problem komt overigens meestal voort uit meerdere incidenten. (ibid.: 40, 57-59) Ook kunnen er activiteiten plaatsvinden die in verschillende processen thuishoren, bijvoorbeeld
het
aanmelden
van
wijzigingen.
Het
Configuration
Management
is
verantwoordelijk voor het onder controle brengen en houden van de veranderende IT-infrastructuur, het identificeren van configuratieonderdelen, het verzamelen en beheren van documentatie over de IT-infrastructuur en het verschaffen van betrouwbare informatie over de objecten binnen de IT-infrastructuur aan alle overige processen. (ibid.: 40, 69-71) Het Change Management zorgt voor het gecontroleerd doorvoeren van wijzigingen in de IT-infrastructuur. Het betreft hier het efficiënt doorvoeren van goedgekeurde wijzigingen. Onder wijzigingen wordt onder andere het toevoegen of verwijderen van componenten in de IT-infrastructuur verstaan. Het doel van het proces is om door goede afstemming in de organisatie te bepalen welke wijzigingen nodig zijn. Deze wijzigingen vinden plaats in samenwerking met de statusbewaking van het Configuration Management, op verzoek van de klantorganisatie, het Problem Management en verschillende andere processen. (ibid.: 40, 87-89) Het vijfde proces betreft het Release Management. Release Management sluit nauw aan bij de activiteiten van het Configuration Management en het Change Management. De hoofdtaak van Release Management is de gecontroleerde distributie van apparatuur en programmatuur, inclusief het samenstellen, testen en de opslag (ibid.: 40, 41, 101, 104, 105). De heer Braun legt uit dat “het Release Management door de gemeente
48
Eindhoven, op de registratie van de in gebruik zijnde software en hardware na, nog niet is ingevuld. De registratie van software en hardware is voldoende om de basis van het proces probleemloos te laten draaien. Het Configuration en Change Management hebben ook voldoende aan de wijze waarop het nu is ingericht”. Er zou dus prima met het model gewerkt kunnen worden, zonder invulling van het Release Management. In hoeverre dit op waarheid berust zou interessant zijn voor nader onderzoek, maar is verder niet relevant voor mijn betoog. In
2002
is
de
gemeente
Eindhoven
begonnen
met
het
werken
volgens
de
ITIL-beheermethodiek. De inrichting van de processen, het IT-beheer, wordt binnen de gemeente Eindhoven door zeven personen gedaan, te weten: de procesmanagers (Incident, Problem, Change, Configuration en Operations/Service manager), hoofd ICT-beheer en de procescontroller van het FB. Daarbij worden zij gestuurd door het extern bedrijf Quint Wellington Redwood (kortweg Quint), een organisatieverbeteringsbureau dat zich helemaal toelegt op het oplossen van managementvraagstukken op het gebied van informatietechnologie. Mevrouw Karsies verklaart dat de gemeentelijke organisatie van Eindhoven de processen zo heeft ingericht “dat het als IT dienstverlener het beste op het gebied van de producten en diensten kan garanderen aan haar klanten”. Momenteel is Eindhoven nog groeiende en heeft daarom ook nog niet alles uitgebouwd en beschikt bijvoorbeeld nog niet over Availability Management (beschikbaarheidsbeheer), dat ter ondersteuning van een met de opdrachtgever overeengekomen beschikbaarheid van IT-diensten de juiste inzet van middelen, methoden en technieken waarborgt, en Capacity Management (Capaciteitsbeheer), dat ter ondersteuning van de afspraken met de opdrachtgever zorg draagt voor een optimale inzet van IT-middelen (ibid.: 39). De gemeente Eindhoven vindt het Service Support het belangrijkste en daarom zijn hierboven ook alleen de processen beschreven die deel uitmaken van het Service Support: “Bij de implementatie van ITIL begin je met de inrichting van de Service Support processen (Incident, Problem, Change, Configuration). Deze processen zijn het belangrijkste voor de klant, want de klant heeft er belang bij dat de meldingen en aanvragen op een gestructureerde manier worden aangepakt/opgelost. Ook voor onszelf zijn dit de processen waar we de meeste winst uit kunnen halen met betrekking tot gestructureerd werken”, aldus de heer Braun.
4.2 Relevant beleid met betrekking tot de aanschaf van software In deze paragraaf wordt ingegaan op de centralisatie, die heeft plaatsgevonden naar aanleiding van de reorganisatie binnen de gemeentelijke organisatie van Eindhoven.
49
Daarnaast wordt ingegaan op de richtlijnen met betrekking tot de aanschaf van software, waarvoor de gemeente Eindhoven standaarden heeft opgesteld.
4.2.1 Centralisatie De gemeente Eindhoven wil alle facilitaire diensten organiseren vanuit één centraal punt: het Facilitair Bedrijf. Hiertoe heeft er in het jaar 2000 een reorganisatie plaatsgevonden binnen de gemeente Eindhoven. Na deze reorganisatie is het FB opgericht waar het technisch ICT beheer van alle vakdiensten is ondergebracht. Vanuit het FB wordt alles op het gebied van onder andere onderhoud aan gebouwen, beveiliging,
catering,
postverzorging,
receptie,
inkoop,
drukwerk,
telefonie,
personeelszaken en technisch ICT-beheer geregeld, niet alleen voor de gemeentelijke organisatie zelf maar ook voor instellingen zoals de Stadsschouwburg, waar de gemeente nauw mee verbonden is. Centralisatie houdt ook in dat er geen ondersteunend personeel meer aanwezig is binnen de verschillende vakdiensten, maar alle functies centraal bij het FB zijn ondergebracht. Zo beheert en onderhoudt de ICT-afdeling binnen het FB de gemeentelijke servers, de computers, het netwerk en de applicaties van de hele gemeente en voorziet verschillende vakdiensten van alle producten en diensten die zij op ICT-gebied nodig hebben. Het FB is echter niet apart gepositioneerd, maar valt net als de andere diensten onder leiding van de Concernstaf van de gemeente. De heren Peter van Mierlo en Joop Bruurs, beiden ICT-adviseur binnen het FB van de gemeentelijke organisatie van Eindhoven, zijn overtuigd van de voordelen die de centralisatie heeft. Zo heeft men onder andere een beter overzicht, kunnen er makkelijker controles en testen uit worden uitgevoerd en kan men bovendien sneller ingrijpen wanneer er problemen optreden. Door de interne dienstverlening van het FB zouden de vakdiensten zich volledig moeten kunnen wijden aan hun primaire producten en diensten voor de burgers, bestuur, instellingen en bedrijven. Niet iedereen is echter positief over de voordelen die de centralisatie zou hebben en sommigen ervaren het juist als nadelig dat alle functies nu centraal bij het FB zijn ondergebracht en er geen ondersteunend personeel meer aanwezig is binnen de diensten. Hier zal ik in verderop in dit hoofdstuk op ingaan. Naast centralisatie is het volgens de heren Van Mierlo en Bruurs een absolute noodzaak om gebruik te maken van een gestandaardiseerde ICT-infrastructuur, om het ICT-beheer op een efficiënte wijze te kunnen uitvoeren met een zo klein mogelijke kans op 50
verstoringen. Hier zal ik in de volgende paragraaf verder op ingaan.
4.2.2 Standaardisatie Binnen de gemeentelijke organisatie van Eindhoven wordt er zoveel mogelijk gestreefd naar een standaardisatie op het gebied van hardware en software. Dit betekent dat het personeel de programmatuur dient te gebruiken die standaard wordt aangeboden. De heer Joop Bruurs legt uit wat de aanleiding is geweest voor standaardisatie: “Reden daarvoor is dat we in het verleden heel veel problemen hebben gehad met allerlei toepassingen die mensen al dan niet illegaal op hun pc's hadden geïnstalleerd. Bovendien krijgen we als iedereen dat zou doen een allegaartje van allerlei bestandsformaten die de ene wel en de andere weer niet geopend kan krijgen. De ruim 2000 mensen krijgen het nu al voor elkaar om zo'n 750 verschillende applicaties legaal bij elkaar verzonnen te krijgen, laat staan als ze allemaal ook hun eigen gang mogen gaan”. Om deze problemen tegen te gaan en het aantal applicaties niet verder te laten stijgen, wordt er nu binnen de gemeente Eindhoven gebruik gemaakt van een gestandaardiseerde omgeving voor alle in beheer zijnde platforms c.q. besturingssystemen, inclusief werkplekken en databases (Van Mierlo, 2005). Deze gestandaardiseerde omgeving vereist volgens de heer Peter van Mierlo: “een uniforme werkwijze/inrichting voor zowel nieuwe als bestaande applicaties alsmede voor werkplek en server inrichting, applicatie en database installaties” (ibid.: 6). De in beheer zijnde besturingssystemen zijn onder andere Windows 2003, Novell Netware, HP Unix en Linux (ibid.: 9). De heer Van Mierlo legt in een gesprek uit, dat ik met hem had in mei 2005, dat al deze besturingssystemen voor verschillende doelen worden ingezet. Zo wordt Windows 2003 ingezet voor de Windows-servers, en heeft men Linux in gebruik voor onder andere de databases en eService (Werkgroep Elektronische Dienstverlening, 2004), de elektronische dienstverlening richten burgers, bedrijven, instellingen en andere overheden. Ook de werkplekken zijn gestandaardiseerd en globaal houdt dit in dat op de werkplekken gebruik wordt gemaakt van het besturingssysteem Microsoft XP Professional en daarnaast wordt standaard gebruik gemaakt van het kantoorautomatiseringspakket Microsoft Office 97. Ook beschikt de gebruiker over beperkte rechten binnen het besturingssysteem en kan daardoor zelf onder andere geen software installeren (Van Mierlo, 2005: 6). Wat betreft de standaardisatie op softwaregebied zijn er alleen technische specificaties
51
opgesteld, waaraan de software moet voldoen teneinde te 'passen' binnen de ICT-infrastructuur van de gemeente Eindhoven. Dit houdt onder andere in dat de beoogde software mag worden aangeschaft op voorwaarde dat het moet kunnen draaien op het daartoe bestemde besturingssysteem, zoals dat is vastgelegd in de technische richtlijnen. De
technische
richtlijnen
hebben
puur
betrekking
op
de
inrichting
van
de
ICT-infrastructuur. In deze paragraaf zal ik verder niet ingaan op de details van de technische richtlijnen met betrekking tot de standaardisatie, aangezien dit niet van belang is voor mijn betoog. Ik zou echter wel direct over willen gaan tot het ter discussie stellen van de afwezigheid van richtlijnen binnen de gemeentelijke organisatie van Eindhoven, die voorschrijven uit welke software er een keuze gemaakt mag worden (in de vorm van bijvoorbeeld een productencatalogus, ofwel een 'menukaart') of aan welke functionaliteiten de software moet voldoen mag in aanmerking komen aangeschaft te worden. Deze informatie komt rechtstreeks uit gesprekken met de heer Van Mierlo, de heer Arend Zwaga, sectorhoofd binnen de dienst WZI, en de heer Pierre van den Heuvel, hoofd ICT-beheer. De heer Peter van Mierlo legt uit dat er niet wordt gekeken naar de verschillende mogelijkheden op softwaregebied, maar dat er vanuit de verschillende diensten bestelbonnen binnenkomen bij het FB waar direct aan moet worden voldaan. De heer Zwaga verklaart dat er geen functionele richtlijnen zijn waar de hele gemeentelijke organisatie van Eindhoven zich aan moet houden, er geen 'pakketkeuze' is, maar er dient alleen nog rekening gehouden te worden met de ICT-infrastructuur. Volgens de heer Van de Heuvel leggen mensen zich niet neer bij een 'menukaart': “Mensen zien iets in de winkel liggen en willen dat koste wat het kost hebben op hun pc op het werk”. De klant is de baas en zijn/haar wensen staan voorop. De heer Van Mierlo legt uit dat ook niemand zich geroepen voelt om deze richtlijnen op te stellen: “De Concernstaf vindt het zaak van het FB om dit te doen, en het FB is juist van mening dat dit de taak is van de Concernstaf”. Onduidelijkheid over het takenpakket (wie wat moet doen en waarvoor verantwoordelijk is) levert conflicten op die onder andere de heer Boris Liebrand, projectleider bij het FB, regelmatig ervaart en waardoor volgens sommigen ook de besluitvormingsprocessen rond de aanschaf van software traag verlopen: ”We zijn te vaak aan het ruziën met de klant over het takenpakket en we komen er maar niet uit. Het FB heeft nu een scheidsrechters positie, maar een onafhankelijke moet over dergelijke conflicten uitspraak doen en de knoop doorhakken. Echter, hiermee wordt gewacht totdat de problemen er zijn. Er is een preventief beleid nodig, ondanks dat het lastig is om deze op te stellen”.
52
Zodoende ontstaat er binnen iedere dienst een eigen manier van werken, iedereen gaat zijn eigen gang en er wordt door de verschillende diensten slecht samengewerkt als één gemeentelijke organisatie. “Er is geen beleid binnen deze gemeente: de vakdiensten schaffen in eigen beheer software aan, zonder dat er naar beleid gekeken wordt”, aldus de heer Van Mierlo. De heer Van Mierlo legt uit dat dit conflicten oplevert en er om deze reden technische richtlijnen zijn opgesteld. Echter, alleen technische richtlijnen zijn niet voldoende, want ondanks dat het personeel zelf niet meer zonder toestemming allerlei software op hun computers kan/mag installeren (Van Mierlo, 2005: 6), draait er toch software op hun computers die verder niets te maken heeft met de werkzaamheden die binnen de organisatie uitgevoerd dienen te worden. Er is meer nodig dan alleen technische richtlijnen, legt de heer Van Mierlo uit, want: “De klant bepaalt zelf wanneer er nieuwe software nodig is. Vaak gaat het dan om nieuwe versies van bepaalde software, maar de klant beslist. Richtlijnen voor een goede regie ontbreken hier, want het FB krijgt opdrachten binnen die zonder discussie verwerkt moeten worden. Er wordt niet gekeken naar verschillende mogelijkheden of beschikbare functionaliteiten”. Er bestaat overigens binnen de organisatie een voorstel voor een gemeentelijke mandaatregeling voor wat betreft de aanschaf van software. Hier wees de heer Jack Janssen, die als één van de personen bij de Concernstaf het beleid formuleert voor het personeel en de organisatie, mij op. Dit voorstel geeft schematisch een beschrijving van bevoegdheden weer, bijvoorbeeld wie binnen de organisatie bevoegd is om te bepalen of de software voldoet aan de algemeen geldende gemeentelijke kaders/standaarden. Volgens mevrouw Angela de Rijck, verantwoordelijk voor allerlei juridische zaken binnen de gemeentelijke organisatie, wordt een mandaatregeling niet echt als naslagwerk gebruikt: “De regeling leeft niet echt en zou meer toegankelijker gemaakt moeten worden. Ook wordt de regeling verstuurd naar de 'bestuurders', met de boodschap: informeer je personeel over deze regeling. Zodra er dan een opdrachtverstrekking is voor de aanschaf van nieuwe software moeten de mensen het mandaat raadplegen. Dit laatste is echter een punt van zorg, want de praktijk wijst uit dat men slecht of helemaal niet het mandaat raadpleegt”, aldus mevrouw De Rijck. Echter, het personeel is niet of nauwelijks op de hoogte van deze bestaande mandaatregeling, zo blijkt wanneer ik de heren Bruurs en Van Mierlo ernaar vraag. Dit is uiteraard ook een punt van zorg, want dergelijke regelingen worden dus wel opgesteld maar het personeel wordt er blijkbaar niet of zeer slecht over geïnformeerd, terwijl volgens mevrouw Van Rijck juist het tegenovergestelde de bedoeling is. Dat er door vakdiensten in eigen beheer software wordt aangeschaft, terwijl dit eigenlijk
53
via de ITIL-processen dient te verlopen, zorgt binnen de gemeente Eindhoven voor een spanningsveld tussen diverse partijen. Om conflicten te voorkomen moet er een beleid komen, dat ervoor zorgt dat niet iedere vakdienst zijn eigen koers bepaalt. Er zijn reeds technische richtlijnen opgesteld, die inhouden dat er alleen software mag worden aangeschaft die binnen de infrastructuur van de gemeente Eindhoven past. Echter, voor de functionele kant zijn er geen richtlijnen opgesteld. In paragraaf 4.3.1.2 zal deze discussie nogmaals worden aangehaald en er verder op worden ingegaan, aan de hand van het bespreken van de wijze waarop de softwarebesluitvorming van de gemeente Eindhoven tot stand komt.
4.3 Softwarebesluitvorming gemeente Eindhoven De aanleiding om van software te willen veranderen is heel divers. Zo wordt door de heren Eric van der Steen, Ad Steenbakkers en Harrie Smits, allen Informatie- en Procesmanager (IPM) van respectievelijk de diensten Maatschappelijke Ontwikkeling (MO), Algemene en Publiekszaken (APZ) en Stedelijke Ontwikkeling en Beheer (SOB) en verantwoordelijk voor de informatievoorziening van de betreffende dienst, aangegeven dat bijvoorbeeld veroudering van de software aanleiding is om over te stappen op een nieuwere versie. Ook voegen de heren van der Steen en Steenbakkers hieraan toe de ontevredenheid over de huidige software of de behoefte naar nieuwe functionaliteiten, waarover de huidige software nog niet beschikt. Deze wensen ontstaan bij de eindgebruikers of worden via een persoon, die een bepaalde groep binnen een vakdienst vertegenwoordigd, kenbaar gemaakt aan de 'IPMer' van de betreffende vakdienst. Wat de taak van een IPMer hier precies inhoudt, zal worden uitgelegd in paragraaf 4.3.1.2. Tot slot zijn er nog andere redenen te noemen, die de aanleiding kunnen zijn voor het aanschaf van nieuwe software. Zo kunnen gemeenten bijvoorbeeld vanuit de wetgeving, naar aanleiding van bijvoorbeeld plannen van het Ministerie van Binnenlandse Zaken, verplicht worden om aanpassingen te maken in hun Gemeentelijke Basis Administratie (GBA) voor persoonsgegevens, door de aanschaf van nieuwe, betere software, waardoor de beveiliging van gegevens van de burgers in geautomatiseerde systemen die door de gemeenten gebruikt worden verbeterd wordt. Ook kunnen gemeenten genoodzaakt zijn om andere software aan te schaffen in verband met het faillissement van de leverancier, bij wie er voorheen software werd aangeschaft. Een andere leverancier kan geen ondersteuning bieden bij broncode die gesloten is of wil meestal ook geen ondersteuning bieden aan software die niet bij hen gekocht is, en dus moet de gemeentelijke organisatie op zoek naar vervangende software bij een andere leverancier.
54
Nu uitgelegd is hoe de vraag naar software tot stand komt, zal ik in de volgende paragraaf ingaan op hoe een besluitvormingsproces rond de aanschaf van software in zijn werk gaat en welke personen hierbij zijn betrokken.
4.3.1 De verschillende lagen in een besluitvorming Om goed in kaart te kunnen brengen hoe een besluitvormingsproces in zijn werk gaat en welke personen daarbij betrokken zijn heb ik mij in mijn onderzoek gericht op diverse personen die betrokken zijn bij het proces. Deze personen zijn onder te verdelen in groepen mensen die betrokken zijn bij het besluitvormingsproces. Deze groepen kunnen vervolgens weer onderscheiden worden in verschillende lagen, namelijk de laag van de eindgebruikers, de beslissers en de laag van de organisatiecultuur. In deze paragraaf zal worden ingegaan op die verschillende lagen en beschreven worden wat de rol is van de personen die deel uitmaken van deze lagen. Aan de hand daarvan zal beschreven worden hoe een besluitvormingsproces rond de aanschaf van software in zijn werk gaat.
4.3.1.1 De eindgebruikers De eerste laag die benoemd kan worden is de laag die bestaat uit de groep eindgebruikers. De eindgebruikers zijn de personen, die uiteindelijk met de 'nieuwe' software te maken krijgen in hun werkomgeving. De eindgebruikers zijn ook vaak de personen bij wie als eerste de wens ontstaat voor de aanschaf van nieuwe software. Zo kunnen de eindgebruikers bijvoorbeeld hun ontevredenheid uiten over de huidige software en dit kenbaar maken aan anderen, waardoor een besluitvormingsproces in gang kan worden gezet. Door middel van formele enquêtes en informele steekproeven wordt er binnen de vakdiensten de mening gepeild van de eindgebruikers over software. De heer Ad Steenbakkers van de dienst APZ legt uit dat er onder een selectie van willekeurige eindgebruikers enquêtes gehouden worden. De heer Steenbakkers legt uit er onder andere enquêtes gehouden zijn tijdens het Office Migratie Project, het project rond de vervanging van Office 97: “Vanuit de Concernstaf is men benaderd en heeft een selectie van willekeurige eindgebruikers een enquête in laten vullen. Er zijn in totaal 150 enquêtes ingevuld”. Bij de dienst Stedelijke Ontwikkeling en Beheer wordt er niet door middel van een enquête 55
naar de mening van de eindgebruikers gevraagd, legt de heer Harrie Smits uit maar de mening van de eindgebruikers is zeker bekend: “Er worden geen enquêtes gehouden, maar er wordt op zeer informele wijze naar de mening van de eindgebruikers gevraagd. En de mening van de eindgebruikers binnen SOB is zeer goed bekend, aangezien men binnen deze dienst erg mondig is”. Het is opmerkelijk dat men nogal verschilt van mening in hoeverre de eindgebruikers een rol spelen bij een besluitvormingsproces. Zo worden volgens de heer Steenbakkers de eindgebruikers (iedereen of één vertegenwoordiger die optreedt namens een hele groep) gedurende het hele proces erbij betrokken. Het enige waar de eindgebruikers niet over mogen meebeslissen, zo legt de heer Steenbakkers uit, is de keuze van de (proprietary) leverancier van de software. De heer Arend Zwaga legt daarentegen uit dat de eindgebruikers alleen inhoudelijk betrokken worden bij het besluitvormingsproces, maar daarnaast geen invloed hebben op de besluiten die genomen worden. De heer Jack Janssen verklaart weer iets anders, namelijk dat de eindgebruikers juist niet of nauwelijks bij besluitvormingsprocessen betrokken worden. Hij zou dit graag veranderd willen zien en de eindgebruikers laten deelnemen aan een besluitvormingsproces in de vorm van bijvoorbeeld een gebruikerspanel. De heer Janssen pleit dat in de structuur van een pakket rekening gehouden moet worden met de eindgebruiker en dat de software getest moet worden op usability, bijvoorbeeld dat men goed en snel met de software overweg kan. Ook zegt de heer Janssen dat “alle ideeën, ook van de eindgebruikers, daarbij zorgvuldig overwogen moeten worden”. Hoe kan het zijn dat al deze personen een verschillend antwoord geven op de vraag in hoeverre de eindgebruikers betrokken worden bij een besluitvormingsproces? Waarom hebben eindgebruikers binnen de dienst APZ meer invloed dan de eindgebruikers binnen de dienst WZI? En hoe komt het dat de Concernstaf, als overkoepeld orgaan van al deze diensten, wat betreft deze situatie ook weer een ander beeld schetst? De Concernstaf formuleert het beleid voor het personeel en de hele organisatie (zie paragraaf 3.1), en gaat hier dan toch ook over de wijze waarop eindgebruikers betrokken dienen te worden bij besluitvormingsprocessen? Hoe is het dan te verklaren dat de Concernstaf hier kennelijk gebrekkig zicht op heeft? Wat ik hier bespeur, en wat ik ook opmaak uit hetgeen dat besproken is en nog aan bod zal komen in deze thesis, is een slechte samenwerking tussen de verschillende diensten,
56
waarbij er binnen de diensten verschillend te werk wordt gegaan en men (op dit terrein) niet goed van elkaar op de hoogte is door een slechte uitwisseling van gegevens. Ook de Concernstaf blijkt niet op de hoogte te zijn van hoe er binnen de verschillende diensten te werk wordt gegaan, juist diegenen die hier wél van op de hoogte zouden moeten zijn. Ook naar aanleiding van hetgeen behandeld is in paragraaf 4.2.2, waarin gesproken werd over de standaardisatie binnen de gemeentelijke organisatie van Eindhoven, kan geconcludeerd worden dat er gebrekkige regie lijkt te zijn bij de aanschaf van software. De klant bepaalt namelijk wat er komt en dat leidt tot wildgroei. Er bestaan slechts technische richtlijnen die bepalen wat er wel en wat er niet aangeschaft mag/kan worden, maar geen richtlijnen die de klant een bepaalde keuze voorlegt in de vorm van een 'menukaart' bijvoorbeeld. Er ontbreekt een scheidsrechter, iemand die ingrijpt wanneer het uit de hand dreigt te lopen en beleid voert die de hele organisatie aangaat. Er lijkt sprake te zijn van een organisatie, waarbij iedereen zijn eigen gang gaat, er niemand ingrijpt en de verantwoordelijkheid op zich neemt om dergelijke zaken goed te organiseren en beleid te formuleren. Binnen de gemeentelijke organisatie van Eindhoven ervaart men zelfs dat, ondanks dat iedereen onder de gemeente Eindhoven valt, er geen sprake is van één gemeente. De heer Eric van der Steen verklaart het volgende: “De verschillende vakdiensten hebben wel met elkaar te maken, maar aan de andere kant zijn het echt aparte diensten. Iedere dienst heeft namelijk zijn eigen manier van werken en heeft zijn eigen cultuur”. Later in deze thesis wordt hier nog op teruggekomen, zo ook in de volgende paragraaf. In de volgende paragraaf zal ik ingaan op een andere laag, die als tweede onderscheiden kan worden, namelijk de laag van de beslissers.
4.3.1.2 De beslissers Er
zijn
twee
'soorten'
personen
te
onderscheiden
die
betrokken
zijn
bij
een
besluitvormingsproces, namelijk de formele 'goedkeurders' van een besluit en de direct betrokkenen. De formele goedkeurders zijn de eindverantwoordelijke personen, die een besluit formeel moeten goedkeuren en ondertekenen. Binnen de gemeentelijke organisatie van Eindhoven is dit het Decision Making Unit (DMU). Het DMU bestaat uit de Gemeentesecretaris, directeur van de dienst APZ, directrice van de dienst WZI, hoofd Informatie & Procesmanagement van de Concernstaf, sectorhoofd van het Facilitair Bedrijf en een 57
beleidsmedewerker van het Facilitair Bedrijf. Het DMU is in het leven geroepen om misverstanden rond de gemaakte besluiten op inhoudelijk vlak te voorkomen. Er kan achteraf niet meer worden teruggekomen op de afspraken die gemaakt zijn, want een besluit dat ondertekend is door het DMU is definitief. Er zijn personen van verschillende afdelingen van de gemeente die meer direct betrokken zijn bij de besluitvormingsprocessen rond de aanschaf van software, voordat de besluiten formeel worden goedgekeurd. Hiermee bedoel ik de personen die het directe contact met de klant hebben. De klant dient namelijk zijn verzoek in bij deze personen en deze personen zijn vervolgens verantwoordelijk voor het vinden van geschikte software die aansluit bij de wensen van de klant. De personen waar het hier om draait zijn de Informatie- en Procesmanagers, ofwel de 'IPMers'. Een IPMer heeft het directe contact met de klant (lees: persoon die binnen een vakdienst een bepaalde groep vertegenwoordigd) en mits de klant zelf geen ideeën heeft, zoekt de IPMer op functioneel gebied (over welke functionaliteiten moet de software beschikken? Voor welk doel wordt de software ingezet?) samen met de klant uit welke software voldoet aan zijn/haar wensen. Wanneer er geschikte software is gevonden, gaat het Facilitaire Bedrijf vervolgens over het technische gedeelte van de software ofwel de implementatie. Wanneer
het
implementatieproces
in
werking
treedt,
treden
daarmee
ook
de
ITIL-processen (Change Management et cetera) in werking. Het opvallende hieraan is, wat ik ook in paragraaf 4.2.2 ter discussie stelde, dat de klant bepaalt welke software er komt. Uit de gesprekken met de IPMers van de diensten APZ, MO en SOB blijkt ook dat er geen (functionele) richtlijnen bestaan voor het maken van een keuze voor bepaalde software, maar dat de wens van de klant voorop staat. In andere woorden: dat wat de klant wil moet er komen. Dit gaat soms zo ver, legt de heer Van Mierlo uit, dat de klant zelf met de installatie cd-rom op de proppen komt en de mensen van het FB verzoekt de software zo snel mogelijk te installeren. Het FB is namelijk de enige marktgerichte dienst en hiermee ook de leverancier van diverse diensten aan de vakdiensten. De klant richt zich als consument tot het FB, maar niet via een tussenschakel maar direct tot de personen die over het ICT-beheer gaan. Het gevolg hiervan is dat er nu binnen de gemeentelijke organisatie van Eindhoven gebruik wordt gemaakt van een groot aantal applicaties en dit aantal blijft toenemen. De heer Van den Heuvel legt uit dat dit uit de hand loopt: “Er moet een oplossing komen door aan de klant twee of drie opties voor te leggen, waaruit een keuze gemaakt kan worden. Komt men er dan nog niet uit, dan moet de klant met zijn verzoek naar de
58
Gemeentesecretaris”. Echter, zoals besproken is in paragraaf 4.2.2 ontbreken er richtlijnen op dit gebied, en zijn er alleen nog maar technische richtlijnen opgesteld. Door het ontbreken van duidelijke richtlijnen en beleid ontstaat een situatie waarin men niet goed van elkaar weet wie wat mag doen en hoe iets gedaan moet worden, iedereen dit vervolgens op zijn eigen manier oplost omdat er ook onduidelijkheid is over de bevoegdheden binnen de organisatie, en dit alles als resultaat heeft dat de klant de baas wordt. Daarnaast is er nog een ander probleem ontstaan, want niet alleen de aanschaf en het onderhoud van applicaties kost ontzettend veel geld, maar men verliest bovendien op deze manier inzicht in de overbodigheid van bepaalde applicaties. Zo zouden er bijvoorbeeld een aantal verschillende applicaties in gebruik kunnen zijn, die op functioneel gebied allemaal ongeveer gelijk zijn aan elkaar. De heer Pierre van Heuvel benadrukt dat het de taak van de Concernstaf is om de hoeveelheid applicaties terug te dringen: “De Concernstaf moet ingrijpen, zij moeten voor dit probleem beleid opstellen en hun visie op deze kwestie uitspreken. Immers, zij zijn het overkoepelende besturingsorgaan. Zij moeten optreden als scheidsrechter, maar dat gebeurt niet”. Bovenstaande heeft overigens met name betrekking op software waar in principe meer dan één vakdienst gebruik van maakt, ofwel de 'standaard' software zoals een tekstverwerkings- of een emailprogamma, en niet de vakdienstspecifieke software zoals bijvoorbeeld de software voor de stedenbouw, het rioolbeheer, het regelen van het verkeer of software voor de archivering van de kunstverzameling van het Van Abbemuseum in Eindhoven. De heer Smits legt uit: “De dienst SOB is geen standaard dienst
en
begeeft
zich
buiten
de
standaard
productencatalogus.
Software
voor
bijvoorbeeld de stedenbouw of het regelen van het verkeer worden voor de gemeente Eindhoven ontwikkeld”. Het zou dus volgens de heer Smits moeilijk zijn om standaarden te bepalen voor producten die niet standaard zijn, want dergelijke software zou in tegenstelling
tot
andere
software
ook
niet
altijd
gemakkelijk
passen
in
de
ICT-infrastructuur van de gemeente Eindhoven. De situatie die in deze paragraaf geschetst is leidt tot conflicten, omdat men aan de ene kant toe wil naar standaardisatie door technische richtlijnen op te stellen en te werken via de ITIL-beheermethodiek, zo legt onder andere de heer Marc Braun uit, Service Manager bij het FB, maar aan de andere kant ervaart bijvoorbeeld de heer Eric van der Steen dat de samenwerking sinds de centralisatie hierdoor formeler is geworden en dat bestellingen minder snel verwerkt worden dan vroeger door allerlei administratieve rompslomp: “Voor de aanschaf van software moet nu een aanvraag worden ingediend, waarna er overleg
59
plaatsvindt binnen het BIDteam (Het team dat orders afhandelt en kijkt of het om standaard, ofwel gebruikelijke en bekende, aanvragen gaat. Wanneer dit niet het geval is sturen zij het door naar de ICT-adviseurs). De aanvraag verloopt via veel formulieren en veel mensen. Vanuit een beheersmatig oogpunt gezien is het logisch dat men hiervoor heeft gekozen, maar het is nu heel lastig gemaakt om een aanvraag te doen omdat dit via vele omwegen moet verlopen. Het duurt allemaal erg lang en het werk blijft nog langer liggen als er mensen, via wie de aanvraag moet verlopen, ziek zijn”, aldus de heer Van der Steen. De heer Boris Liebrand verklaart echter dat de mensen van de verschillende vakdiensten negatief zijn over de gevolgen van de centralisatie, omdat zij nu hun vrijheid kwijt zijn en nu minder zelf de mogelijkheid hebben om zaken te regelen dan voorheen: “Werknemers mogen niet meer zomaar 'speeltjes' aanschaffen, die niets met de werkzaamheden te maken hebben. Door het inleveren van vrijheden op dit gebied, voelen zij nu een soort van angst en bedreiging”. Echter, dit centralisatie-beleid is blijkbaar nog niet helemaal geïntegreerd, aangezien de heer Van Mierlo verklaart dat de klant zelf nog met installatie cd-roms op de proppen komt. Klanten trachten dus nog op de oude voet verder te gaan. Naar aanleiding van hetgeen in deze paragraaf besproken is leid ik daarmee ook meteen de volgende paragraaf in, aangezien de werkwijze binnen de gemeentelijke organisatie van Eindhoven te relateren is aan de derde laag die onderscheiden kan worden: de laag van de organisatiecultuur.
4.3.1.3 De organisatiecultuur Naast de laag van de eindgebruikers en de laag van beslissende personen, is het van belang nog een derde laag te onderscheiden in mijn onderzoek. Deze derde laag is niet een laag die uit personen bestaat, maar het betreft een medium (lees: tussenlaag) in de vorm van een filter waar besluiten doorheen moeten. Deze laag bevindt zich ook daadwerkelijk in het midden, dus letterlijk tussen de bovenste en onderste laag van het besluitvormingsproces. Het filter betreft de organisatiecultuur binnen de gemeente Eindhoven, waarmee de ongeschreven gewoonten en gebruiken bedoeld worden die er binnen
deze
organisatie
bestaan.
Deze
laag
beïnvloedt
dus
ook
de
besluitvormingsprocessen rond de aanschaf van software. De cultuur van een organisatie is iets dat min of meer in het dagelijks denken van de medewerkers van een bedrijf verankerd is. Het fenomeen bedrijfscultuur wordt ook wel omschreven als een “collectieve mentale programmering” of “collectieve mentale 60
dwingeland” (Hofstede, 1991). De bedrijfscultuur geeft namelijk richting aan het gedrag binnen de organisatie, dus ook hoe besluitvormingsprocessen verlopen, en is redelijk resistent tegen verandering. Zo zullen plannen gericht op vernieuwing meer kans krijgen in een flexibele cultuur zoals binnen een adhocratie, dan in een stabiele omgeving zoals een bureaucratische cultuur (Mintzberg, 1992; ITSMF Nederland, 2002: 22). Een voorbeeld van een de cultureel aspect die er de gemeentelijke organisatie van Eindhoven bestaat en waar nu na de centralisatie erg moeilijk verandering in blijkt aan te brengen, is de positie van de klant ten opzichte van het Facilitair Bedrijf. De klant bepaalt welke software er komt, waarbij de klant nota bene soms zelf met de installatie cd-rom naar het FB stapt (zie paragraaf 4.3.1.2). In paragraaf 5.4 zal ik verder ingaan op de bedrijfscultuur van de gemeentelijke organisatie van Eindhoven, door in te zoomen op het besluitvormingsproces rond de vervanging van Microsoft Office 97.
4.3.2 Interne communicatieprocessen binnen de gemeente Eindhoven Beknopt zou ik in deze thesis ook nog iets willen aankaarten dat betrekking heeft op de interne communicatie binnen de gemeentelijke organisatie van Eindhoven. In diverse gesprekken is namelijk naar voren gekomen dat de informatievoorziening met betrekking tot het inzicht geven in de besluitvormingsprocessen niet optimaal verloopt. Zo verklaart de heer Harrie Smits van de dienst SOB, dat “de wijze waarop er communicatie plaatsvindt en de frequentie waarin er berichtgeving wordt gegaan, zowel binnen de vakdiensten als tussen de verschillende vakdiensten van de gemeente Eindhoven slecht is”. De heer Eric van der Steen spreekt hier ook zijn ongenoegen over uit en verklaart dat er bijvoorbeeld heel slecht gecommuniceerd is over de reorganisatie, die er binnen het Facilitair Bedrijf heeft plaatsgevonden (zie paragraaf 4.2). Het is van belang over dergelijke zaken gemeentebreed informatie te verschaffen, omdat de reorganisatie invloed heeft op de bedrijfsprocessen van de hele gemeente. Iedereen moet op de hoogte gebracht worden van de reorganisatie en er moet vooral uitgelegd worden wat een reorganisatie voor hen betekent. De heer Marc Braun van het Facilitair Bedrijf geeft aan, dat de medewerkers binnen de gemeente Eindhoven vaak niet weten bij wie of waar ze informatie kunnen halen. Volgens de heer Boris Liebrand zouden dan ook alleen de afdelingshoofden geïnformeerd worden. Er lijkt verder niemand de rol van boodschapper te vervullen. Zodoende gaat de heer 61
Liebrand dan zelf maar de informatie halen, maar eigenlijk zou dit de andere kant op moeten plaatsvinden. De gemeentelijke organisatie van Eindhoven mist, volgens de heer Braun, een professionele communicatiedeskundige, iemand die de mensen informeert en het steeds op verschillende manieren aankondigt: “Het één keer mededelen heeft geen zin. De informatie moet diverse malen herhaald worden en dat moeten via verschillende communicatiekanalen gebeuren”. Echter, volgens de heer Ad Steenbakkers van de dienst APZ is het probleem eerder te vinden in de wijze waarop er met de huidige communicatiemiddelen binnen de organisatie wordt omgesprongen: “Er zijn voldoende communicatiemiddelen, maar deze worden alleen niet altijd goed ingezet”. In de bestudering van het Intranet van de gemeentelijke organisatie van Eindhoven, is hier een groot potentieel weggelegd waar nog niets mee gedaan wordt. Op Intranet PINO (Personeel INformatie en Organisatie) is er namelijk slechts algemene informatie te vinden, die zeer oppervlakkig ingaat op wat er zich afspeelt binnen de afzonderlijke diensten. De informatie die er te vinden is, is van huishoudelijke aard zoals de multifunctionele printers die nu binnen de dienst APZ in gebruik zijn. Ook beperkt het gemeentebrede nieuws zich tot bijvoorbeeld berichten over de beschikbaarheid van een nieuwe versie van Acrobat Reader en het nieuwe uiterlijk dat de gemeentelijke website heeft gekregen. Echter, zeer belangrijke informatie zoals de reorganisatie die destijds heeft plaatsgevonden binnen het FB en het verloop van het Office Migratie Project dat nu actueel is, wordt zeer slecht gecommuniceerd via het Intranet.
Figuur 5: Intranet PINO, gemeente Eindhoven
In de zomer van 2005 zou er een nieuw Intranet gerealiseerd worden, zo werd duidelijk uit een gesprek met de heer Riny van Deursen, hoofd afdeling Informatiebeheer binnen het FB, en de heer Paul Steehouwer, hoofd Communicatie, die zich beiden bezighouden met de implementatie van het nieuwe Intranet. Echter, ondanks dat het nieuwe Intranet
62
gelanceerd moest worden in de zomer van 2005, blijkt er eind juni 2005 nog niets uitgewerkt te zijn wat betreft de inhoudelijke inrichting van het nieuwe Intranet. De heer Steehouwer verklaart dat er wel ideeën zijn, maar dat er nog niets op papier staat. Er is nog niet duidelijk vastgelegd over wat er precies gaat veranderen in het nieuwe Intranet ten opzichte van het oude Intranet of hoe het ingezet gaat worden. Daaruit kan dus ook geconcludeerd worden dat men nog geen plannen heeft de informatievoorziening via Intranet te verbeteren. Voor de verbetering van de communicatie binnen de gemeentelijke organisatie Eindhoven zou met name het Intranet geschikt zijn, aangezien alle medewerkers van de gemeente Eindhoven hier toegang tot hebben. Berichtgeving met betrekking tot zaken die de hele organisatie aangaat moet ten alle tijden op het Intranet te raadplegen zijn. In deze berichtgeving is het van belang naast algemene informatie ook uit te leggen of een bepaald besluit gevolgen heeft voor de medewerkers en wat het voor de bedrijfsprocessen betekent. Informatie die niet voor alle ogen binnen de organisatie bedoeld is, zou in het Intranet ook eenvoudig kunnen worden afgeschermd. De mensen zien dan alleen die informatie, die zij mogen (en moeten) lezen. Zodoende is er ook geen onduidelijkheid meer over waar of bij wie informatie te verkrijgen is, maar staat alle belangrijke informatie op één plek bij elkaar en is het voor iedereen gemakkelijk bereikbaar via hun eigen pc. Hoe precies de ideeën met betrekking tot de verbetering van het Intranet tot in de details kan worden uitgewerkt, is wellicht een interessant onderwerp voor toekomstig onderzoek. Voor nu wil ik mij beperken tot dit voorstel en weer terug te keren naar de kern van mijn onderzoek.
4.4 Vergelijking besluitvorming met andere gemeenten In deze paragraaf zal ik ingaan op de verschillen die er te ontwaren zijn in de besluitvormingsprocessen rond de aanschaf van software bij de gemeentelijke organisaties in Nederland. Iedere gemeentelijke organisatie bepaalt namelijk zelf de wijze waarop besluitvormingsprocessen rond de aanschaf van software dienen te verlopen. Daarnaast treffen we bij iedere gemeente een andere organisatiestructuur aan. Hiermee doel ik op de verdeling
van
de
bevoegdheden
binnen
de
gemeente
met
betrekking
tot
de
besluitvorming rond de aanschaf van software, de verschillen in de structuur en de 63
rolverdeling die overigens niet altijd afhankelijk zijn van de grootte van een gemeente. Zo is er bijvoorbeeld een groot verschil in de rol die de ICT-afdeling bij de gemeente Haarlem vervult in besluitvormingsprocessen, als we dit vergelijken met de gemeente Eindhoven. De heren Frans Vrijmoed en Arie Sigterman, beiden ICT-adviseur binnen de gemeente Haarlem, verklaren in een gesprek, dat ik met hen had in juni 2005, dat in een besluitvormingsproces rond de aanschaf van software de ICT-afdeling een erg belangrijke rol speelt. “Of het nu gaat om dienstspecifieke software of dat het verzoek uit de raad komt, er wordt geen applicatie aangeschaft zonder dat de ICT-afdeling hierbij betrokken is. Een
verzoek
van
een
afdelingshoofd
komt
dan
ook
via
de
Informatie&Automatisering-coördinatoren (I&A-coördinatoren, qua functie vergelijkbaar met die van de Informatie- en Procesmanagers van de gemeente Eindhoven), waar iedere sector (wat de gemeente Eindhoven dienst of vakdienst noemt) binnen de gemeente Haarlem over beschikt, altijd de ICT-afdeling binnen. De I&A-coördinatoren zijn verplicht om de ICT-afdeling in te schakelen bij een softwarekeuze”, aldus de heren Vrijmoed en Sigterman. Uit voorafgaande paragrafen is duidelijk geworden dat bij de gemeente Eindhoven de ICT-afdeling niet altijd wordt ingeschakeld bij een softwarekeuze, maar het Facilitair Bedrijf lijkt met name alleen over het technische deel en de implementatie van de software te gaan. Daarnaast
leggen
de
heren
Vrijmoed
en
Sigterman
uit
dat
voor
grotere
sectoroverstijgende applicaties naast de Concernstaf en de ICT-afdeling het I&A-platform (oftewel alle I&A-coördinatoren) binnen de gemeente Haarlem een rol speelt. De ICT-afdeling is altijd eindverantwoordelijke bij het nemen van een besluit over de aanschaf van software. Het besluit dat de ICT-afdeling neemt wordt doorgespeeld naar de Concernstaf, die het besluit tot voorgenomen aanschaf vervolgens voorlegt aan de gemeenteraad van Haarlem. Ook bij het Office Migratie Project, waar ik in hoofdstuk vijf van deze thesis uitgebreid op in zal gaan, werden alle IPMers van de gemeente Eindhoven betrokken bij het maken van een besluit. Echter, niet de ICT-afdeling binnen de gemeente Eindhoven maar het DMU is altijd eindverantwoordelijke bij het nemen van een besluit over de aanschaf van software. Bij de gemeente Breda daarentegen verlopen besluitvormingsprocessen ook weer op een hele andere wijze. Hierbij wordt een overigens ook onderscheid gemaakt tussen dienstspecifieke
en
generieke
ICT-componenten.
De
heer
Jascha
Gregorowitsch,
coördinator applicatiebeheerder bij de gemeente Breda, verklaart dat wanneer het om een kleinschalige aanschaf gaat, de aanschaf van de software dan verder binnen de dienst zelf wordt geregeld. Het hoofd van de dienst bepaald of het verzoek doorgaat. Gaat het om
64
iets groters, bijvoorbeeld een gemeentebrede aanschaf van software, dan worden er diverse stappen in het besluitvormingsproces doorlopen waar verschillende partijen bij betrokken zijn. De eerste schakel in het besluitvormingsproces rond de aanschaf van software zijn naast de applicatiebeheerders van de diensten de eindgebruikers. De eindgebruikers geven namelijk vaak aanleiding tot de aanschaf van software en worden betrokken in het proces om erachter te komen wat men precies wil hebben. Momenteel is het zo georganiseerd, zo vervolgt de heer Gregorowitsch, dat een verzoek van de medewerkers
en/of
applicatiebeheerders
via
de
applicatiebeheerders
bij
de
I&A-coördinator terecht komt. De I&A-coördinatoren hebben een adviserende rol in het geheel, maar hebben verder geen beslissingsbevoegdheid. De diensten bepalen zelf wat ze
met
het
advies
gaan
doen.
De
eindverantwoordelijke
personen
in
besluitvormingsprocessen rond de aanschaf van software zitten in de directie van iedere dienst. Het is niet de afdeling automatisering die bepaalt wat er komt, zij vervullen puur een ondersteunende facilitaire rol in het geheel. De afdeling automatisering is ervoor verantwoordelijk dat alles draait en goed werkt, maar de personen met toegang tot het budget bepalen wat er komt. Deze rol die de afdeling automatisering van de gemeente Breda vervult is overigens wél vergelijkbaar met de rol van het FB van de gemeente Eindhoven. Zoals duidelijk is geworden uit gesprekken, vervult het FB momenteel ook met name een ondersteunende facilitaire rol en met name de klant nu nog bepaalt wat er komt. De heer Gregorowitsch is niet tevreden over de manier waarop een besluitvorming nu tot stand komt. Binnen de gemeente Breda wordt op ICT-gebied namelijk nog te weinig vanuit één centraal punt geregeld. De afdeling automatisering wordt wel vanuit een centrale positie georganiseerd, maar zij bieden slechts ondersteuning bij het beheren van de software. In andere woorden: zij zorgen ervoor dat alles werkt. Ook kijkt de afdeling automatisering samen met de heer Gregorowitsch naar de implementatie van software. De applicatiebeheerders werken puur vanuit de dienst zelf en op facilitair gebied wordt door de heer Gregorowitsch en de I&A coördinatoren slechts advies gegeven. Verder wordt de
heer
Gregorowitsch
alleen
betrokken
bij
het
maken
van
testplanningen
bij
gemeentebrede applicaties, de werkzaamheden rond overige testen van de applicaties worden door de applicatiebeheerders zelf ingevuld. Momenteel is men bezig met een reorganisatie binnen de gemeente Breda om dit te veranderen en de heer Gregorowitsch wil de invulling van de rol van de betrokken personen in het besluitvormingsproces veranderen. Volgens hem moet er een schakel zijn vóór de I&A-coördinatoren, iemand die de centrale rol vervuld binnen de gemeente en directe invloed kan uitoefenen op het maken van een besluit. Daarna zou er pas een
65
inkoopbeleid moeten plaatsvinden en moet het doorslaggevende besluit centraal genomen worden, dus niet meer zoals nu door de directie van de diensten zelf. “Vanuit een
centrale
positie
moet
er
meer
grip
op
het
geheel
komen”,
aldus
de
heer Gregorowitsch. Ook bij de gemeente Rotterdam wil haar ICT-beleid veranderen. Deze gemeente, die uit maar liefst 35 verschillende diensten bestaat, is momenteel bezig om een gemeentebreed ICT-beleid neer te zetten, zo verklaart de heer Cees Jan Prevo van de gemeente Rotterdam. De heer Prevo is ICT-adviseur bij de gemeente Rotterdam en maakt onderdeel uit van de bestuursdienst, de schakel in de gemeentelijke organisatie tussen het gemeentebestuur en de deelgemeenten en diensten. De heer Prevo houdt zich in zijn functie als met name bezig met het informatiebeleid van de gemeente Rotterdam op het gebied
van
ICT
en
informeert
het
bestuur
over
ICT-gerelateerde
zaken.
Het
informatiebeleid omvat de informatievoorziening met betrekking tot de ICT-huishouding van de gemeente Rotterdam, waarbij men onder andere kunt denken aan de inrichting van de ICT-infrastructuur van de gemeente, het Intranet, et cetera. Het project rond het opzetten van gemeentebreed ICT-beleid is er met name op gericht om met alle diensten samen de krachten te bundelen en te opereren als één concern. Een gemeentebreed ICT-beleid zou volgens de heer Prevo niet alleen zorgen voor de verbetering van de dienstverlening en efficiency, maar zou tevens kostenbesparend zijn en voor continuïteit binnen de organisatie zorgen. “Voorheen was er een grotere beleidsvrijheid binnen de gemeente Rotterdam. Elke dienst organiseerde zijn eigen dienstverlening, waarbij dus ook alles op ICT-gebied binnen de verschillende diensten zelf werd geregeld. Hierdoor is er een grote verscheidenheid aan applicaties en platforms in gebruik”, zo verklaart de heer Prevo. Uit een inventarisatie, die gedaan is om de veelheid aan applicaties die in gebruik zijn in kaart te brengen, is onder andere gebleken dat er slechts een beperkt aantal concernbrede applicaties zijn. De heer Prevo legt uit dat voor een betere onderlinge samenwerking men met dezelfde, op elkaar afgestemde ICT-voorzieningen zou moeten werken en structureel gebruik moeten maken van dezelfde (basis)gegevens. Door het breed toepassen van goede ideeën wordt voorkomen dat op meerdere plaatsen het wiel telkens opnieuw wordt uitgevonden. Een van de doelstellingen van de gemeente is dan ook dat het resultaat van elk ICT-project beschikbaar komt voor het concern. De resultaten van deze projecten worden daarmee 'concernstandaarden', hetgeen inhoudt dat als een andere dienst een vergelijkbaar toepassing nodig heeft van iets dat al binnen het concern aanwezig is het wordt hergebruikt. Om dit te realiseren ontwikkelt de gemeente Rotterdam een meld- en
66
analysepunt dat de kennisuitwisseling over lopende en voorgenomen projecten moet stimuleren. Hierbij worden tevens de raakvlakken tussen projecten in kaart gebracht, zodat wanneer de diensten hun plannen melden de projecten op elkaar kunnen worden afgestemd. Hiermee kan het aantal applicaties en platforms worden teruggedrongen. Een dergelijk meld- en analysepunt is niet aanwezig bij de gemeente Eindhoven, maar men tracht wel zoveel mogelijk te werken volgens een standaardisatie. Het introduceren van een gemeentebreed ICT-beleid verloopt overigens niet geheel zonder problemen, legt de heer Prevo uit. Naast dat de implementatie van het nieuwe ICT-beleid een omvangrijke opgave is en de gemeente hier nog groeiende in is, zijn niet alle diensten van de gemeente Rotterdam positief over de gevolgen van de implementatie het nieuwe ICT-beleid. De grotere diensten zijn liever zelf verantwoordelijk voor de organisatie op dit gebied. Doordat met het nieuwe beleid bepaalde bevoegdheden veranderd worden, moeten de diensten wat inleveren. Zij kunnen niet meer rechtstreeks invloed uitoefenen op het serviceniveau, wat voor de nodige spanningen kan zorgen. De kleine diensten zijn wél positief over het nieuwe ICT-beleid, omdat zij daardoor minder kwetsbaar zouden zijn. “Hoe dan ook, een grote gemeente zoals Rotterdam heeft regie nodig en daarom is het nieuwe ICT-beleid noodzakelijk”, benadrukt de heer Prevo. Ook bij de gemeente Eindhoven is niet door iedereen enthousiast gereageerd op de gevolgen van de centralisatie en men ervaart dat de huidige samenwerking binnen de organisatie formeler is geworden en dat bestellingen minder snel verwerkt worden dan vroeger door allerlei administratieve rompslomp. Men is, zoals voorheen, liever zelf binnen de dienst verantwoordelijk voor zaken op ICT-gebied. Om verder in te gaan op hoe een besluitvormingsproces bij de gemeente Rotterdam verloopt, kan allereerst gezegd worden dat er meerdere partijen bij zijn betrokken. Zoals duidelijk is uit de beschreven visie van de gemeente Rotterdam, streeft men naar een gemeenschappelijk optreden en nauwere onderlinge samenwerking. Het nieuwe ICT-beleid van de gemeente Rotterdam veronderstelt een strakke concernsturing, waarbij ook periodiek een controle wordt uitgevoerd naar de naleving van het ICT-beleid. Ook bij de gemeente Eindhoven is er een gemeenschappelijk optreden en een nauwere onderlinge samenwerking en daarbij een strakke concernsturing gewenst, zo blijkt uit diverse gesprekken. Voor software die gemeentebreed moet worden aangeschaft wordt het voorstel ingediend bij de I-stuurgroep. Dit is het adviesorgaan op ICT-gebied en doet dienst als satelliet van het concernberaad op het gebied van ICT. De I-stuurgroep treedt namens het concernberaad op als opdrachtgever van het beheer van generieke infrastructurele
67
ICT-voorzieningen, weegt ICT-voorstellen af tegen andere beleidsterreinen en adviseert het College over de besluitvorming. De besluitvorming vindt plaats door het College, en bij ingrijpende keuzes zal de Gemeenteraad erbij betrokken worden. Ook de eindgebruikers worden volgens de heer Prevo indirect betrokken bij een besluitvormingsproces rond de aanschaf van software. De eindgebruikers wordt namelijk de mogelijkheid geboden om gezamenlijk een lijstje op te stellen met de voor- en nadelen van de software die zij gebruiken. De betrokkenheid van de eindgebruikers bij de besluitvorming sluit daarmee ook aan bij het streven van de gemeente om de krachten te bundelen en de samenwerking te verbeteren. Hoever de betrokkenheid van de eindgebruikers precies gaat en of de eindgebruikers bijvoorbeeld ook toegang hebben tot informatie over lopende projecten en plannen binnen deze gemeente, is helaas niet duidelijk geworden uit het gesprek. Bij de gemeente Tilburg is men, net zoals bij de gemeente Eindhoven, ook bezig met een centralisatie. De heer Michel Blezer, ICT-adviseur bij de gemeente Tilburg, legt uit dat voorheen bij deze gemeente alles op het gebied van ICT-beheer binnen de verschillende diensten zelf georganiseerd werd, maar er nu naar wordt gestreefd om dit vanuit één centraal punt te regelen. Al het ICT-beheer vindt plaats op afstand, evenals de installatie van software. Ook het ICT-beheer bij de gemeente Eindhoven wordt georganiseerd op één centraal punt. Wat betreft de besluitvormingsprocessen rond de aanschaf van software lijken de zaken in Tilburg, net als bij de gemeente Haarlem, prima op orde te zijn. Zo verklaart de heer Blezer dat, in het kader van de standaardisatie, alles wat een keer bedacht is vastgelegd wordt. Dit is vergelijkbaar met hetgeen waar de gemeente Rotterdam ook naar streeft, namelijk dat de resultaten van ICT-projecten beschikbaar komen voor de organisatie en vervolgens als standaard gehanteerd worden binnen de gemeente. Verder legt de heer Blezer uit dat ook de werkplekken binnen de gemeentelijke organisatie van Tilburg gestandaardiseerd zijn en dat de klanten voor nieuwe software kunnen kiezen uit een beperkt aanbod, dat wordt voorgelegd door de ICT-afdeling in de vorm van een 'menukaart'. De heer Blezer geeft zelf als ICT-adviseur geen bindend advies, maar hij zet wel alle alternatieven voor de klanten op een rij waaruit zij vervolgens een keuze moeten maken. Dit is tegenovergesteld aan de situatie bij de gemeentelijke organisatie van Eindhoven, waar de klanten meer vrijheid hebben in het maken van een keuze omdat er geen beperkt aanbod aan hen wordt voorgelegd.
68
Wanneer
er
gemeentebreed
software
wordt
aangeschaft
worden
minimaal
twee
alternatieven met elkaar overwogen. De doorslaggevende keuze voor bepaalde software hangt af van de stabiliteit en prijs van de software. De ICT-afdeling binnen de gemeente Tilburg is te omschrijven als een zeer autonome afdeling: “Als men iets besluit binnen de automatisering, dan gebeurt dat ook”, aldus de heer Blezer. Ook maakt deze organisatie, in tegenstelling tot de gemeente Eindhoven, geen gebruik van Service Level Agreements (SLA's). Een SLA is een contract dat het FB afsluit met haar klanten en te omschrijven is als een lijst met afspraken die er met de klant zijn gemaakt met betrekking tot de technische dienstverlening, service beschrijving en financiële afspraken. Het is een lijst waarin terug te vinden is wie wat doet en wat er allemaal gaat gebeuren. Deze belangrijke afspraken worden door de gemeentelijke organisatie van Tilburg niet gemaakt met de klant in de vorm van contracten, maar zijn bij voorbaat al vastgelegd in samenspraak met de directie. Wat betreft het besluitvormingsproces rond de aanschaf van software bij de gemeente Arnhem, bestaan er volgens de heer Peter Karssenberg binnen deze gemeente al standaarden sinds 1999. De heer Peter Karssenberg is senior beleidsadviseur op ICT-gebied en maakt samen met twee andere adviseurs deel uit van de Concernstaf van de gemeentelijke organisatie van Arnhem. Zijn functie op ICT-gebied is beleidsmatig. Naast het verzorgen van het beleid op ICT-gebied, stellen de ICT-adviseurs onder andere de plannen op voor de werkplekken en initiëren zij daarnaast ook nieuwe ontwikkelingen op ICT-gebied. De heer Karssenberg verklaart dat hij in het algemeen tevreden is over het verloop van een besluitvormingsproces. Dankzij de standaarden die de gemeentelijke organisatie van Arnhem heeft opgesteld weet iedereen namelijk waar hij/zij aan toe is, en gezien het aantal jaar dat de standaarden al aanwezig zijn binnen deze gemeente lijkt het ook meer geaccepteerd te zijn bij dit personeel in vergelijking tot bij het personeel van de gemeente Eindhoven waar het gebruik van standaarden nog vrij nieuw is (zie paragraaf 4.2.2). Tevens is er voor het bewaken van de standaarden een Wijzigingsadviescommissie ingesteld. De opdracht van de commissie is het overzichtelijk ordenen van de gemeentelijke ICT-standaarden en deze indien nodig aan te vullen. Ook toetsen zij of de bestaande en nieuw aan te schaffen applicaties voldoen aan de gemeentelijke standaarden. “Deze commissie voorkomt versnippering op ICT-gebied en de aanvragen voor nieuwe applicaties moeten door de I&A-coördinatoren of de facilitaire ICT-afdeling altijd aan deze commissie worden voorgelegd”, aldus de heer Karssenberg. In de Wijzigingsadviescommissie zitten mensen van verschillende takken van de gemeentelijke
69
organisatie. De heer Karssenberg is erg tevreden over het instellen van deze commissie en noemt het een succesformule. Helaas is in het gesprek niet helemaal duidelijk geworden hoe een besluitvormingsproces in zijn werk gaat, wanneer er een verzoek om nieuwe software wordt gedaan waarvoor door de organisatie nog geen standaarden voor zijn opgesteld. Wanneer dit het geval is, legt de heer Karssenberg uit, heeft de eindgebruiker als eerste een belangrijke stem in het besluitvormingsproces. Ook de ICT-afdeling heeft een vinger in de pap en daarnaast heeft de inkoopafdeling zeggenschap in het geheel. De financiële unit van de gemeente gaat over
de
financiële
aspecten
rond
de
aanschaf van
software.
Daarnaast
is
de
I&A-coördinator van iedere dienst verantwoordelijk voor de toepassing van standaarden binnen de dienst. Uiteindelijk dient het hoofd van een dienst het voorstel in bij de ICT-afdeling van zijn dienst. De directeuren van iedere dienst zijn eindverantwoordelijke in een besluitvormingsproces rond de aanschaf van software en hebben wekelijks overleg waarin dergelijke zaken ook besproken worden. Dit is in grote lijnen de beschrijving van hoe een dergelijk besluitvormingsproces bij de gemeente Arnhem in zijn werk gaat. Het is dus
helaas
niet
helemaal
helder
welke
lijn
precies
doorlopen
wordt
in
een
besluitvormingsproces tussen de rol van de eindgebruiker in het begin en de rol van de directeuren van iedere dienst als eindverantwoordelijke, en hoe alle rollen precies ingevuld worden. Duidelijk is nu dat de besluitvormingsprocessen rond de aanschaf van software verschillend verlopen bij gemeentelijke organisaties. Ook zijn er grote verschillen in de verdeling van de bevoegdheden binnen de besluitvormingsprocessen. De gemeente Eindhoven zou er baat bij hebben om voor bepaalde zaken met betrekking tot de besluitvormingsprocessen voorbeeld te nemen aan hoe andere gemeentelijke organisaties dit oplossen, zoals het opstellen van een duidelijk gemeentebreed ICT-beleid en een sterk bestuurlijk optreden. Hierdoor zouden heel wat problemen en conflicten op voorhand uit de weg kunnen worden gegaan. Meer uitgebreid advies en aanbevelingen op dit punt zullen aan bod komen in hoofdstuk zes.
70
5. Open source software binnen gemeentelijke organisaties Dit hoofdstuk handelt over in hoeverre open source software wordt meegenomen in een besluitvormingsproces rond de aanschaf van software. Om inzicht te bieden in hoe dit bij de gemeentelijke organisatie van Eindhoven eraan toegaat, zal in dit hoofdstuk aandacht besteed worden aan het Office Migratie Project. Voordat ik inga op dit project, zal ik eerst de houding en het gedrag van gemeentelijke organisaties in Nederland ten opzichte van oss bespreken. Hierbij zal ook worden ingegaan op de richtlijnen die er deze organisaties bestaan om voor bepaalde software te kiezen. Na dit wat meer algemene deel over gemeentelijke organisaties en oss, zal ik mijn verhaal vervolgens verder toespitsen op de gemeentelijke organisatie van Eindhoven door in te zoomen op het Office Migratie Project en de bedrijfscultuur van deze organisatie nader te analyseren.
5.1 Gemeentelijke organisaties en open source software Open source software lijkt steeds meer bekendheid te verwerven binnen de gemeentelijke organisaties in Nederland, maar hoe staat men tegenover dit type software? Wordt in besluitvormingsprocessen rond de aanschaf van software ook oss overwogen als mogelijk alternatief? In deze paragraaf zal ik ingaan op de houding en het gedrag van de Nederlandse overheid ten opzichte van oss (en open standaarden) en welke richtlijnen er bestaan binnen een gemeentelijke organisatie om voor bepaalde software te kiezen. In het jaar 2004 is er een kwantitatief onderzoek verricht naar de houding en het gedrag van de Nederlandse overheid ten opzichte van oss en open standaarden. In één jaar zijn er twee metingen gedaan en het doel van het onderzoek was na te gaan in hoeverre de situatie in de Nederlandse overheid het afgelopen jaar op het gebied van oss en open standaarden is veranderd, en het richtte zich tot ICT-managers van 528 organisaties op gemeentelijk, provinciaal en rijksniveau. Het onderzoek is uitgevoerd in opdracht van het Programma OSOSS. (Ghosh en Glott, 2004) Uit de resultaten van dit onderzoek is onder andere naar voren gekomen dat in 2004 het aantal overheidsorganisaties dat gebruik maakt van oss met 4% is gestegen ten opzichte van het jaar 2003 (ibid.: 21) en het overgrote deel van de respondenten wil het aandeel oss binnen de organisatie uitbreiden (ibid.: 3, 27). Een voorbeeld hiervan is de gemeentelijke organisatie van Tilburg. Uit een gesprek dat ik in mei 2005 had met de heer Michel Blezer, ICT-adviseur bij de gemeente Tilburg, bleek dat deze organisatie reeds 71
gebruik maakt van oss. De organisatie is positief over oss: “Wij hebben positieve ervaringen met de oss, waar wij binnen deze organisatie gebruik van maken. Het aandeel aan oss dat binnen de organisatie gebruikt wordt zouden wij dan ook graag willen uitbreiden. Wij gaan echter niet op voorhand 'op zoek' naar oss, maar houden de ontwikkelingen op dit gebied nauwlettend in de gaten; binnen de ICT-afdeling houdt men zich hiermee bezig”. Echter, binnen de rest van deze organisatie lijkt oss niet veel draagkracht te hebben. De heer Blezer legt uit dat alle ICT-projecten die bij de gemeente Tilburg worden opgezet en waarbij het gaat om oss, een interessante naam krijgen. Het woord oss komt niet in de naam voor. Het is namelijk gebleken, zo legt de heer Blezer uit, dat het woord oss weerstand oproept: “Als de mensen in deze organisatie weten dat het om oss gaat, heeft men niet of nauwelijks interesse in het project. Er ontstaat dan weerstand en over het algemeen wil men het dan niet hebben. Echter, wanneer het project een leuke naam krijgt en verder niet expliciet genoemd wordt dat het om oss gaat, blijken dezelfde mensen het ineens wél interessant vinden”. De houding en het gedrag ten opzichte van oss is bij het horen van de naam binnen deze gemeentelijke organisatie als afwijzend te omschrijven. Het is opmerkelijk dat de houding en het gedrag tegenovergesteld zijn, zolang men niet weet dat het om oss gaat. Wat zijn toch de redenen voor de slechte reputatie die oss lijkt te hebben binnen deze organisatie, waar komt dit vandaan en hoe kan men van het tegenovergestelde dat waar is overtuigd worden? Hier is denk ik een goed voorbeeld van de organisatiecultuur van de gemeente Tilburg te ontdekken: de heer Blezer let erop dat oss door het filter van de organisatiecultuur van Tilburg heen komt. Niet binnen iedere organisatie lijkt sprake te zijn van weinig draagkracht voor oss. Zo hebben de initiatieven van de ICT-afdeling van de gemeente Haarlem om oss te gebruiken binnen de organisatie steun van de sectordirecteur van de Facilitaire Dienst (waar de ICT-afdeling ook onder valt), de Gemeentesecretaris, de wethouder en van de politieke partij SP. De heren Sigterman en Vrijmoed verklaren ook dat voor de toepassing van oss binnen een gemeente een raadsbesluit nodig is dat hieraan ten grondslag ligt en dat mensen achter jouw initiatieven moeten staan anders krijg je niets voor elkaar. Binnen de gemeente Haarlem is oss erg belangrijk in de afweging en sinds het eerste kwartaal van 2004 is deze gemeente actief op dit gebied. Het wordt altijd meegenomen als mogelijk alternatief en men wil het aandeel aan oss in de toekomst graag uitbreiden. De heren Sigterman en Vrijmoed, beiden ICT-adviseur binnen de gemeente Haarlem, verklaren dat als blijkt dat een open source variant over de gelijke, geschikte functionaliteiten beschikt waar de gemeente naar op zoek is, dan valt de keuze voor de
72
open source variant. Ook maakt de gemeente Haarlem het liefst gebruik van open standaarden, ook met het oog op toekomstige ontwikkelingen. Uit het onderzoek van Ghosh en Glott (2004) blijkt ook dat naast dat de kennis van de gemeentelijke organisaties over open standaarden duidelijk is toegenomen ten opzichte van 2003, het gebruik van open standaarden zoals HTML is gestegen. Zo zou meer dan tweederde van de respondenten die in 2003 aangaven geen gebruik te maken van oss in 2004 wél open standaarden inzetten (ibid.: 2, 27, 37). Wat betreft de richtlijnen die er binnen deze gemeente bestaan om voor bepaalde software te kiezen, leggen de heren Sigterman en Vrijmoed uit dat de ICT-architectuur grote
invloed
heeft
in
het
aankoopbeleid.
Daarbij
worden
de
applicaties
voor
gemeentebrede toepassingen in kleinere stukjes opgedeeld en niet meer door de externe leveranciers van A tot Z gemaakt. Ook heeft de gemeente Haarlem criteria opgesteld, waaraan vastgehouden dient te worden bij de aanschaf van software. En daarnaast hanteert de gemeente ook standaarden waar rekening mee dient te worden gehouden. De gemeentelijke organisatie van Haarlem streeft naar onafhankelijkheid van de leveranciers, wat mogelijk wordt door het gebruik van oss. Zo worden de leveranciers door de gemeente Haarlem verzocht om de gemeente oss te leveren, verklaren de heren Sigterman en Vrijmoed: “Wanneer een leverancier de gemeente daar niet bij kan helpen, wordt er verder gezocht naar leveranciers die dat wél kunnen”. Overigens wil de gemeente Tilburg ook minder afhankelijkheid zijn van haar leveranciers en doet dat momenteel door de leveranciers de opdracht te geven om de software, waar de gemeente Tilburg om vraagt, zodanig te bouwen dat het past binnen de ICT-infrastructuur van deze organisatie. De gemeentelijke organisatie van Rotterdam daarentegen stelt zichzelf, in tegenstelling tot bijvoorbeeld de gemeente Tilburg en Haarlem, erg afhankelijk op van haar leverancier(s). De heer Cees Jan Prevo, adviseur voor het ICT-beleid binnen de gemeente Rotterdam, geeft aan dat de leverancier Oracle (naast Centric één van de twee hoofdleveranciers van deze gemeente) het vertrekpunt is voor het maken van een keuze voor software. Dit houdt in dat men zich eerst laat adviseren door de leverancier, ofwel gaat kijken wat Oracle in huis heeft, en wanneer blijkt dat zij de gemeentelijke organisatie niet de gewenste software kunnen leveren er dan pas verder gekeken wordt, maar dan ook bij
(proprietary) leveranciers. Het is voor de gemeente Rotterdam van belang dat
processen en gegevens gestandaardiseerd worden en dat er bij de aanschaf van software rekening gehouden wordt met dat de nieuwe software binnen de infrastructuur van de gemeente past. De heer Prevo geeft aan dat de gemeente de prijs-kwaliteit verhouding
73
erg belangrijk acht en vanuit standaardisatie-oogpunt wil deze organisatie ook zoveel mogelijk van hun aankopen bij één leverancier doen. Een prijs-kwaliteit verhouding kan echter niet gemaakt worden wanneer de aankopen bij één leverancier gedaan worden, dus wat de heer Prevo hier zegt spreekt elkaar wel tegen. Wat betreft de interesse in oss binnen de gemeentelijke organisatie van Rotterdam wordt er, naast dat het al op kleine schaal wordt ingezet in deze organisatie, volgens de heer Prevo aandacht aan besteed in het nieuwe ICT-beleid. Volgens de heer Prevo wil men “waar mogelijk gebruik maken van oss”. In de folder van de Bestuursdienst is te lezen dat men op de hoogte is van goede open source applicaties. Zo oordeelt men onder andere positief of open source besturingssystemen als Linux, webservers als Apache, databases zoals MySQL en Officepakketten als OpenOffice.org, maar bijvoorbeeld OpenOffice.org wordt
níet
gebruikt
binnen
deze
organisatie.
Ook
geeft
men
aan
dat
voor
ERP-toepassingen, de Enterprise Resource Planning technologie waarbij financiële zaken rondom de ‘resources’ van het bedrijf beheerd kunnen worden in termen van personeel, planning en budget, en een GBA-systeem, een pakket voor de Gemeentelijke Basis Administratie van persoonsgegevens, er nog geen geschikt open source alternatief zou bestaan (Bestuursdienst, 2004: 34, 35). Volgens de heer Prevo hangt de keuze voor oss af van het soort applicatie. Voor de gemeente Rotterdam is het een serieuze optie indien het aan de door hun opgestelde criteria voldoet, zoals dat er wordt voldaan aan de functionele eisen, er geen binding is met een leverancier, er mogelijkheden voor koppeling zijn en de benodigde kennis aanwezig is. Er bestaat volgens de heer Prevo geen weerstand tegen oss en de interesse is zeker aanwezig, maar gezien bovenstaande criteria en de richtlijnen die binnen de gemeente Rotterdam gehanteerd worden maakt oss voorlopig ook weinig kans binnen deze gemeente. Welk criterium het gebruik van oss binnen deze organisatie dan precies tegenhoudt is onduidelijk, want bijvoorbeeld het criterium leveranciersonafhankelijkheid is één van dé kenmerken van oss (Forge, 2005; Klijnsma e.a., 2002). Als deze gemeente bovendien geen binding wil met een leverancier, zal men allereerst in ieder geval niet meer één leverancier als vertrekpunt moeten nemen voor het maken van een keuze voor software zoals men dat nu doet. Ook zou er volgens de gemeentelijke organisatie van Rotterdam nog geen GBA-systeem op basis van open source bestaan, maar zolang gemeentelijke organisaties alles van de leverancier (en in dit geval zelfs één leverancier) laat afhangen komt het er natuurlijk nooit. De situatie moet tegenovergesteld zijn, waarbij de gemeentelijke organisaties de dienst uitmaken en niet de softwareleverancier. Hierbij kan men voorbeeld nemen aan hoe
74
de gemeente Haarlem dit aanpakt, namelijk door de leverancier(s) te verzoeken om oss te leveren en dus ook bijvoorbeeld een open source GBA-pakket te ontwikkelen. Zodra de vraag van de klant sterk genoeg is, zullen softwareleveranciers wel gedwongen zijn oss aan de klant te leveren. Hetzelfde geldt overigens ook voor open standaarden: als de druk hoog genoeg is, zullen de leveranciers wel over moeten gaan tot het op de juiste wijze implementeren van open standaarden (Ghosh en Glott, 2004: 56). Ook in de besluitvormingsprocessen van de gemeentelijke organisatie van Arnhem wordt oss meegenomen als mogelijk alternatief in de overweging. De heer Peter Karssenberg, senior beleidsadviseur op ICT-gebied, legt uit dat het overwegen van oss als mogelijk alternatief echter nog niet is opgenomen in de richtlijnen, die momenteel gehanteerd worden binnen deze organisatie. Deze richtlijnen zijn in de vorm van technische standaarden vastgelegd. Naast afspraken over de techniek bestaan er tevens afspraken over de procedures, gegevens en gemeentebrede toepassingen en applicaties waarover de diensten zelf mogen beslissen. Al deze richtlijnen zijn opgeschreven in de “Blauwe Nota”. In deze nota is onder andere te lezen hoe de diensten met de aanschaf van software om mogen gaan en dat er geen dubbele aanschaf van software mag zijn. Met dit laatste wordt bedoeld dat als de software die de gemeente reeds in haar bezit heeft voldoet, het niet toegestaan is dat er iets nieuws aangeschaft wordt. Volgens de heer Karssenberg zou er op het gebied van oss nog geen sprake van zijn van proven technology, software die zich in de praktijk bewezen heeft goed te zijn, waar binnen deze gemeentelijke organisatie uitsluitend gebruik van wordt gemaakt. Ook wil deze organisatie wat betreft oss niet de trend zetten, maar wil eerst “de kat uit de boom kijken”, aldus de heer Karssenberg. Toch wordt er voor bepaalde deeltoepassingen binnen de gemeentelijke organisatie van Arnhem al wél gebruik gemaakt van oss. Beschouwt deze organisatie deze software dan wel weer als proven technology, omdat men er gebruik van maakt in een omgeving met uitsluitend proven technology en welke kat wil de gemeente Arnhem nu precies uit de boom kijken? De gemeente heeft zelf toch al ervaring met het gebruik van oss en de gemeente Haarlem heeft toch al de trend gezet door sinds het eerste kwartaal van 2004 al actief bezig te zijn op het gebied van oss? Verder zou er op het gebied van oss volgens de heer Karssenberg voldoende informatie bestaan om een verantwoorde keuze te maken, maar er is niemand binnen de gemeente Arnhem die zich bezig houdt met het volgen van de ontwikkelingen rond oss. Nota bene laat deze organisatie zich in de besluitvormingsprocesssen rond de aanschaf van software, net als de gemeentelijke organisatie van Rotterdam, informeren door leveranciers. Leveranciers zullen de gemeentelijke organisaties niet zo snel informeren over de
75
mogelijkheden van oss, daar zij graag de broncode voor zichzelf houden (Klöpping, 1998). Daar komt nog bij, zo blijkt uit het gesprek met de heer Karssenberg dat plaatsvond op 14 juni 2005, dat leveranciers de gemeente ook allerlei software probeert op te dringen waar niet om wordt gevraagd. Ook binnen de gemeentelijke organisatie van Breda wordt, ondanks dat er binnen deze gemeente op kleine schaal al gebruik wordt gemaakt van oss, oss niet afgewogen als mogelijk alternatief in besluitvormingsprocessen rond de aanschaf van software. De heer Jascha Gregorowitsch, coördinator applicatiebeheerder bij deze gemeente, geeft hiervoor meerdere redenen op. Zo legt hij uit dat er al erg veel geld is gestopt in het opleiden van het personeel in Windows en Unix4. Er is binnen de gemeente Breda geen expertise aanwezig op het gebied van oss en men wil niet snel opnieuw geld steken in het opleiden van het personeel op dit gebied. Verder geeft de heer Gregorowitsch aan dat de automatisering van de gemeente Breda momenteel zo goed op orde is, dat men de toepassing van oss binnen de gemeente meer iets voor de toekomst vindt. Het is volgens de heer Gregorowitsch nog te vroeg voor Breda om oss te omarmen, omdat er erg veel bij zou komen kijken. Daarnaast geeft de heer Gregorowitsch aan, net als de heer Karssenberg, nog niet overtuigd van oss. De heer Gregorowitsch wil eerst meer bewijzen zien van succesvolle toepassingen van oss, voordat hij het gebruik van deze software zal stimuleren binnen zijn gemeente. Het bewustzijn van de mogelijkheden van oss is volgens de heer Gregorowitsch daarentegen wél aanwezig binnen zijn gemeente en men volgt de ontwikkelingen rond oss. Zo volgt men onder andere de ontwikkelingen rond oss binnen andere gemeenten. Zij hebben geen direct contact met de gemeenten hierover (geen samenwerking op dit punt), maar verkrijgen deze informatie via het Programma OSOSS. Het zijn ook met name de 'hobbyisten' binnen de gemeente Breda die de ontwikkelingen op het gebied van oss op de voet volgen. Zij volgen overigens de ontwikkelingen op eigen initiatief, want er is verder geen team ingesteld die zich bezighoudt met ontwikkelingen rond ICT-zaken voor de toekomst. De heer Gregorowitsch benadrukt dat men bij de gemeente Breda nog geen groot belang heeft in het in gebruik nemen van oss. De mensen binnen de verschillende diensten verlangen graag naar de gewenste functionaliteiten van software en dat het naar behoren werkt; het maakt hen helemaal niet uit of zij open source of closed source software gebruiken. Er bestaat dus ook geen weerstand binnen de organisatie, maar dergelijke 4 De heer Gregorowitsch bedoelt een Unix-variant geïmplementeerd door proprietary leveranciers, want Unix zelf is alleen maar een (open) standaard die de functionaliteiten van een besturingssysteem specificeert. Linux is ook een implementatie van deze specificatie.
76
dingen komen alleen tot stand als de gemeenteraad het wenselijk/belangrijk vindt dat de gemeente zich moet gaan richten op het gebruik van oss. Ook de gemeenteraad van Eindhoven vindt het wenselijk dat de gemeentelijke organisatie van Eindhoven aan de slag gaat met oss (Kelfkens, 2004) en heeft oss als mogelijk alternatief voor de vervanging van Microsoft Office 97 overwogen in het Office Migratie Project. Echter, dit heeft er ook niet toe geleid dat er nu binnen deze gemeente gebruik wordt gemaakt van oss. In paragraaf 5.3 zal ik uitvoerig ingaan op het Office Migratie Project, hoe de uiteindelijke keuze tot stand is gekomen en daarbij de houding van deze overheidsorganisatie ten opzichte van oss. Concluderend kunnen we stellen dat ondanks dat binnen de meeste gemeentelijke organisaties oss al op kleine schaal wordt ingezet, er over het algemeen een weerstand bestaat om het aandeel aan oss in de organisatie uit te willen breiden. Open source software wordt in sommige gevallen niet eens overwogen in besluitvormingsprocesssen rond de aanschaf van software. Zeer weinig lijken zich ook bewust te zijn van mogelijkheden van oss, omdat men zich over software laat informeren en adviseren door de leveranciers en nauwelijks of niet de ontwikkelingen volgt op het gebied van oss. Het is meestal een select groepje dat zich hiermee bezig houdt en er is weinig draagkracht binnen de organisatie. Echter, uitzondering hierop is de gemeente Haarlem. Men lijkt echter wél op de hoogte te zijn van de voordelen van oss. Zo noemt de heer Blezer van de gemeente Tilburg de flexibiliteit en ontwikkelsnelheid als voordelen van oss, en daarnaast het niet hoeven betalen van licentiekosten. De heer Prevo van de gemeente Rotterdam noemt ook het ontbreken van de licentiekosten en daarnaast de vrij beschikbaarheid van de broncode. Ook de heer Karssenberg noemt de lage of geen kosten en tevens noemt hij de kennisdeling tussen organisaties een positieve filosofie. Daarnaast noemen
de
heren
Vrijmoed
en
Sigterman
van
de
gemeente
Haarlem
de
leveranciersonafhankelijkheid als voordeel van oss. Ook de heer Gregorowitsch van de gemeente Breda noemt de onafhankelijkheid van leveranciers en daarnaast de ontwikkeling van oss waaraan mensen over de hele wereld meewerken en waaruit goede producten voortkomen. Ook wordt binnen de gemeentelijke organisatie van Eindhoven, door de heren Arend Zwaga van de dienst WZI, heer Eric van der Steen van de dienst MO en de heren Joop Bruurs en Peter van Mierlo van het FB, de leveranciersonafhankelijkheid en de lagere kosten van oss vanwege het wegvallen van de licentiekosten als voordelen genoemd. Ook in het kwantitatieve onderzoek uit 2004 stond het merendeel van de ondervraagden,
77
dus het merendeel van de ICT-managers van 528 organisaties, positief tegenover oss en open standaarden en ziet voordelen zoals verbetering van de uitwisselbaarheid van data en de leveranciersonafhankelijkheid (Ghosh en Glott, 2004: 3). Echter, ondanks dat steeds meer gemeentelijke organisaties overtuigd zijn van de mogelijke voordelen, bestaan er nog altijd drempels die ervoor zorgen dat de grote potentie van oss en open standaarden slechts in beperkte mate wordt benut. Zo is de heer Gregorowitsch van de gemeente Breda van mening dat het in gebruik nemen van oss nog wat wordt overschat. Als voorbeeld hiervan noemt hij onder andere de hoogte van de kosten, die bij een migratie naar oss een verborgen risico vormen en door mensen niet wordt overzien. De heer Karssenberg van de gemeente Arnhem is onzeker over de continuïteit van oss. Volgens de heer Prevo is het gebruik van oss nadelig voor het beheer, waar hij mee bedoelt dat wanneer de organisatie ervoor kiest om gebruik te maken van oss de organisatie dan zelf meer zou moeten organiseren dan bij css. De heer Pierre van den Heuvel van de gemeente Eindhoven raadt het af om oss te gebruiken, omdat er nog te weinig support is van leveranciers. Daarnaast zou oss te traag werken binnen het netwerk van de gemeente Eindhoven, maar dit heeft alleen betrekking op het opstarten van het open source-kantoorautomatiseringspakket OpenOffice.org dat volgens de heer Van de Heuvel langzamer zou gaan dan bij Microsofft Office. De heer Van de Heuvel geeft echter ook aan dat dit te maken heeft met de ICT-infrastructuur van de gemeente Eindhoven, waarmee dus indirect wordt gezegd dat dit probleem eerder toe te schrijven is aan de inrichting van de ICT-infrastructuur dan aan OpenOffice.org. Een veel gehoord argument binnen de gemeente Eindhoven tegen het gebruiken van oss tot slot is dat het aanbod in oss voor overheidsorganisaties beperkt zou zijn. Zo zou er geen open source variant bestaan voor bijvoorbeeld het rioolbeheer of andere software, wat erg belangrijk is voor het functioneren van een gemeentelijke organisatie. Dit zou volgens velen ook één van de redenen zijn dat oss nog niet zoveel kan worden ingezet. Uit de meningen van de overheidsorganisaties kan geconcludeerd worden dat de factor die een vlugge en meer uitgebreide verspreiding van oss in de weg staan angst is, angst om geconfronteerd te worden met kosten die een migratie naar oss met zich mee zou brengen. Naast het Programma OSOSS kunnen ook praktijkvoorbeelden, ondersteund door controleerbare kostencalculaties, een effectief middel zijn om het gebruik van oss in de toekomst te verhogen (ibid.: 55, 56). Daarnaast zal naar mijn mening de onwetendheid op het terrein van open source software ervoor zorgen dat het belang van oss voor de organisatie niet goed kan worden ingezien. Zo worden belangrijke kenmerken van oss als veiligheid, stabiliteit en flexibiliteit (met
78
uitzondering van de leveranciersonafhankelijkheid) achterwegen gelaten bij het opnoemen van de voordelen van oss. Verder wordt oss traag werkende software genoemd en omschreven als niet proven technology. Ook onwetendheid met betrekking tot de mogelijkheden zal een verspreiding van oss in de weg staan. Een goed voorbeeld van dit laatste is te geven naar aanleiding van het argument dat er een beperkte aanbod zou zijn in open source varianten van softwarepakketen zoals het rioolbeheer. Het nog niet bestaan van een kant-en-klaar open source-softwarepakket voor bijvoorbeeld het rioolbeheer is geen argument voor het gebruiken van css. De gemeentelijke organisaties vergissen zich in deze opvatting, maar onderschatten bovenal de mogelijkheden van open source. Zoals al eerder in deze paragraaf als mogelijkheid naar voren geschoven is, kunnen
overheidsorganisaties
de
leveranciers
verzoeken
oss
te
leveren.
Softwareleveranciers die geen oss ondersteunen zullen zich op den duur moeten aanpassen om hun concurrentiepositie te behouden met andere leveranciers, die wél aan de vraag van klanten kunnen voldoen. Door leveranciers oss te laten ontwikkelen hoeft er slechts één keer geïnvesteerd te worden. Lukt dit niet, dan zijn er nog meer mogelijkheden waaraan vaak niet gedacht wordt. Zo kan intern of extern door bijvoorbeeld studenten van een opleiding Informatica het closed source softwarepakket worden nagemaakt in open source, waarna de organisatie de software ook naar eigen behoeften kan configureren. Voor deze laatste optie is wel meer tijd nodig, maar door tijdig na het signaleren van de behoefte dit project te organiseren moet dit zeker te realiseren zijn. Ook mislukkingen zijn te overwinnen als er geen tijdsdruk is en je nog zolang van het oude pakket gebruik kan maken. De ontwikkeling door studenten/stagiaires is immers nagenoeg gratis. De gemeentelijke organisatie van Tilburg werkt overigens al op deze wijze en vermijdt tijdsdruk: “Terwijl andere gemeenten in updates denken, denken wij aan wat we in de toekomst nodig hebben. Zodoende kunnen we lang van tevoren plannen”, aldus de heer Michel Blezer. Tot slot kan er nog een derde factor worden toegevoegd aan de oorzaken die de verspreiding van oss in de weg staan, namelijk de slechte samenwerking tussen gemeentelijke organisaties. Dit zal ik in paragraaf 5.2 ter discussie stellen.
5.2 Samenwerking tussen gemeenten “De samenwerking tussen gemeenten is cruciaal voor een succesvolle toepassing van open source software”, zo stellen de heren Arie Sigterman en Frans Vrijmoed van de gemeente Haarlem. Echter, de gemeenten zouden hier volgens heren Sigterman en Vrijmoed nog enigszins terughoudend in zijn.
79
Uit de gesprekken met de diverse gemeenten blijkt er inderdaad niet of nauwelijks sprake te zijn van samenwerking op dit gebied. Zo verklaart onder andere de heer Cees Jan Prevo van de gemeentelijke organisatie van Rotterdam, dat er niet veel communicatie plaatsvindt tussen de verschillende gemeenten. Ook zou men niet op de hoogte zijn van de ontwikkelingen binnen andere gemeenten. Dit verklaart ook de heer Joop Bruurs van de gemeente Eindhoven. Echter, deze gemeente heeft wél in het kader van het Office Migratie Project contact gehad met de gemeente Haarlem, om erachter te komen welke ervaringen zij hadden met OpenOffice.org. De heer Jascha Gregorowitsch van de gemeente Breda verklaart ook geen direct contact te hebben met andere gemeenten, maar verkrijgt informatie over ontwikkelingen op open source-gebied binnen andere gemeentelijke organisaties via het Programma OSOSS. Overigens werkt de gemeente Breda wél samen met de gemeente Roosendaal en Bergen op Zoom in de gezamenlijke aanschaf van een nieuw GBA-systeem, nadat gebleken was dat dit bij deze drie organisaties aan vervanging toe was. Helaas blijft het echter bij deze samenwerking. Verder verklaart ook de heer Michel Blezer van de gemeente Tilburg zegt dat er weinig samenwerking is tussen de verschillende gemeenten en men met name alleen voor zichzelf bezig is. Er zou volgens de heer Blezer sprake zijn van een soort concurrentiestrijd tussen de gemeentelijke organisaties, omdat iedereen er naar streeft de 'beste' gemeentelijke organisatie te zijn en daarom anderen geen inzicht geeft in de ontwikkelingen die binnen hun organisatie gaande zijn. De gemeente Tilburg wil in ieder geval graag op de hoogte blijven van de ontwikkelingen op open source-gebied en houdt dit dan ook nauwlettend in de gaten (zie ook paragraaf 5.1). Tevens gaat de heer Blezer zelf op zoek naar informatie over software en laat zich informeren, om een weloverwogen keuze voor software te kunnen maken. Er zou volgens de respondenten van de gemeente Haarlem, Eindhoven, Breda, Tilburg en Arnhem voldoende informatie over oss beschikbaar zijn, met name op het Internet. De heer Prevo van de gemeente Rotterdam is de enige die deze mening niet deelt. Echter, de respondenten van de gemeente Haarlem en Eindhoven (de heer Eric van der Steen) die vinden dat er voldoende informatie over oss te verkrijgen is, zijn wél van mening dat de informatie over oss met name technisch van aard is. Net als de gemeente Breda, verkrijgt ook de gemeente Haarlem haar informatie onder andere via het Programma OSOSS. Daarnaast is binnen de afdeling Bureau Onderzoek, Ontwikkeling, Test en Advies (BOOTA), dat tot de ICT-afdeling van de gemeente Haarlem behoort, een team van mensen samengesteld, dat de ontwikkelingen op het gebied van open source nauwlettend op de
80
voet volgt. Zo is er speciaal een themagroep voor het product OpenOffice opgericht, die zich onder andere bezighoudt met de ontwikkelingen rond dit product. De mensen die deel uitmaken van het ontwikkelteam lopen overigens ook mee bij bedrijven waar deze ontwikkelingen feitelijk plaatsvinden. De gemeente Haarlem wil het aandeel aan oss in de toekomst alleen maar uitbreiden en houdt
zich
veel
bezig
met
voorbereidingen
voor de
inzet
van
meer
oss.
De
voorbereidingen kosten echter wel veel tijd en hierbij geven de heren Sigterman en Vrijmoed aan dat gemeenten op dit punt ook meer moeten gaan samenwerken. De heren Sigterman en Vrijmoed benadrukken dat gemeenten elkaar moeten informeren over waar ze mee bezig zijn: “Communicatie (zowel intern als extern), waarbij je elkaar op de hoogte houdt, is heel belangrijk”. De gemeente Haarlem informeert veel naar de buitenwereld, onder andere via het Internet, en dat zouden andere gemeenten ook moeten doen. Er is namelijk wél gebleken dat er een duidelijke behoefte is bij ruim twintig gemeenten naar informatie over oss, die gericht is op gemeentelijke organisaties. Zoals ook is uitgelegd in paragraaf 2.3.1 start de gemeente Haarlem voor de zomer van 2005 met de stichting OSSO, naar aanleiding van deze behoefte. Ook zouden er volgens de heer Sigterman initiatieven zijn om de markt te voorzien van informatie over wie wat doet en wat gedaan heeft, zodat de gemeenten kunnen profiteren van de ontwikkelingen van andere gemeenten en niet onnodig tijd hoeft te worden gestoken in zaken waar de andere gemeenten al resultaten mee geboekt hebben. Kennisuitwisseling helpt gemeentelijke organisaties aan belangrijke informatie, waarvan zij zelf niet altijd op de hoogte zijn. Ook voorkomt het dat het wiel telkens op meerdere plaatsen opnieuw wordt uitgevonden, door gezamenlijk de oss te beheren. Als een gemeentelijke organisatie iets ontwikkelt heeft of heeft laten ontwikkelen dat ook nuttig is voor andere overheidsorganisaties, kunnen zij dankzij de open source-licenties van elkaar profiteren. De stichting OSSO, gericht op gemeentelijke organisaties, heeft als doel gezamenlijk oss te beheren. Ondanks de behoefte die er lijkt te zijn, blijken de meeste respondenten in ieder geval (nog) niet te willen overstappen. De redenen die zij daar voor aanvoeren zijn echter niet overtuigend genoeg en ook vaak van de hand te doen (zie ook paragraaf 5.1). Zo is een veel gebruikt argument voor het niet willen/kunnen gebruiken van oss de slechte support van leveranciers voor dit type software. Echter, de aanschaf van software moet niet afhangen van wat leveranciers in hun 'assortiment' hebben, maar de organisatie zelf zou moeten bepalen welke software er voor hen gemaakt moet worden en de leveranciers
81
daartoe opdracht geven. Geef de zoektocht niet op na één leverancier die geen support zou willen geven, maar ga de strijd aan met de leveranciers. Werk met andere gemeenten samen om de leveranciers naar de hand te zetten.
5.3 Hoe kiest een gemeentelijke organisatie? Eind november 2004 verscheen er een nieuwsbericht, dat onder andere te lezen was op de website Ososs.nl, waaruit bleek dat de gemeenteraad van Eindhoven wil dat hun gemeente serieus aan de slag gaat met open source software. Dit bericht verscheen naar aanleiding van de kwestie die op dat moment erg speelde binnen de gemeentelijke organisatie van Eindhoven, namelijk dat het huidige kantoorautomatiseringspakket Microsoft Office 97 toe was aan vervanging. (Kelfkens, 2004) De gemeente Eindhoven heeft het externe bedrijf M&I/PARTNERS ingehuurd, een adviesbureau op het gebied van management en informatie, om onderzoek te doen naar de vervanging van Office 97. De gemeente Eindhoven zit namelijk momenteel met het probleem dat op het nu gebruikte Officepakket geen ondersteuning meer wordt verleend en ook de koppeling met andere applicaties onmogelijk dreigt te worden (Kaas, 2005a: 3). De reden dat de gemeente Eindhoven voor verrichten van dit onderzoek een extern bedrijf heeft ingehuurd is volgens de heer Frank Kurcaba, hoofd Facilitair Bedrijf, te wijten aan het feit dat er binnen de organisatie zelf te weinig projectcapaciteit aanwezig is. Daarnaast was het volgens de heer Kurcaba noodzaak om een extern bedrijf dit onderzoek te laten verrichten, vanwege een organisatiekundig probleem: “Eindhoven accepteert moeilijk 'eigen' voorstellen”. Ook de heer Jack Janssen van de Concernstaf bevestigd dit: “Het FB, waar het Office Migratie Project in eerste instantie neergelegd is omdat daar ook het applicatiebeheer zit, kon het project niet helemaal zelf aan. Daarnaast is er intern teveel meningsverschil en om die reden heeft men er ook voor gekozen om voor dit project een extern bedrijf in te huren”. In de komende paragrafen zal ik ingaan op het besluitvormingsproces rond de vervanging van Microsoft Office 97. Het Office Migratie Project is een interessante casestudy voor mijn onderzoek, omdat het onderzoek zich goed leent om te bestuderen op welke gronden een gemeentelijke organisatie tot haar besluit komt en in de afweging open source software wordt meegenomen.
82
5.3.1 Praktijkvoorbeeld: Office Migratie Project Microsoft Office 97 is sinds 1998 bij de gemeente Eindhoven in gebruik voor de kantoorautomatisering. Het Officepakket, dat bij alle diensten van de gemeente in gebruik is, bestaat uit de onderdelen Microsoft Word, Microsoft Excel, Microsoft PowerPoint en Microsoft Access. Naast dat Office 97 op de werkplek wordt gebruikt, is het tevens verweven met het gemeentelijk huisstijlsysteem. Echter, het risico dat de vervanging van Office 97 met zich meebrengt, is dat het huidige huisstijlsysteem hoogstwaarschijnlijk aangepast, voor een deel vervangen of in zijn geheel herbouwd moet worden. (Kaas, 2005a) De gemeente Eindhoven is nog tevreden over de functionaliteit van Office 97 en dat vormt dan ook geen aanleiding om op andere software over te stappen. Er zijn echter, naast dat het huisstijlsysteem nauw verbonden is met Office 97, diverse applicaties van verschillende leveranciers zoals Centric (één van de belangrijkste leveranciers van applicaties, die gemeentebreed in Eindhoven worden ingezet) gekoppeld aan het Officepakket. Het is noodzakelijk andere software in gebruik te nemen om de ondersteuning van deze leveranciers zeker te stellen. (ibid.) Het doel van het Office Migratie Project is het selecteren van een opvolger voor het huidige Office 97 (ibid.: 9). Het externe bedrijf M&I/PARTNERS is gevraagd om de gemeente Eindhoven hierbij te helpen. Het projectteam dat namens M&I/PARTNERS is samengesteld, en bestond uit een projectleider en twee adviseurs met specifieke technische kennis, heeft de interne projectgroep van de gemeentelijke organisatie van Eindhoven ondersteund. Deze interne projectgroep bestond onder andere uit een projectleider, de heer Eric van der Steen, die namens de gemeente Eindhoven een coördinerende rol op zich heeft genomen voor het bewaken van de voortgang van het project. Bewust heeft men iemand tot interne projectleider benoemd die niet werkzaam is binnen het FB. Het Office Migratie Project is een project van de hele gemeente en zodoende is afstand genomen van de suggestie dat het Office Migratie Project een project zou
zijn
waar
alleen
het
FB
bij
betrokken
is.
Verder
waren
bij
het
project
vertegenwoordigers en plaatsvervangers van de afzonderlijke diensten van de gemeente betrokken. Deze groep van vertegenwoordigers bestond hoofdzakelijk uit de IPMers van de verschillende diensten. Voor het Office Migratie Project is door de heer Kaas van M&I/PARTNERS een plan van aanpak geschreven. In het plan van aanpak wordt beschreven op welke wijze de noodzakelijke inventarisatie, afweging en noodzakelijke testen zullen worden uitgevoerd.
83
Naast het doel van het project om een opvolger te kiezen voor het Microsoft Office 97 pakket, moet ook worden aangegeven welke consequenties de invoering van dit pakket heeft voor de organisatie en werkwijze. Het resultaat van het onderzoek is een rapport met een overzicht van de afhankelijkheden van Office 97, een beschrijving van diverse software die allen als mogelijkheid worden beschouwd voor de vervanging van het huidige Officepakket,
de
consequenties
en
mogelijkheden
voor
het
reduceren
van
de
afhankelijkheden van applicaties en het huisstijlsysteem van het te kiezen Officepakket en conclusies ten aanzien van de impact van een migratie en aanbevelingen over de nieuw te kiezen suite. (ibid.) Het project betreffende het onderzoek naar de vervanging van het Officepakket Office 97 bestond uit zes verschillende fasen. De eerste fase betrof het uitvoeren van de voorbereidende werkzaamheden voor de start van het project. In de tweede fase zijn afspraken gemaakt voor de uitvoering van het project. De derde fase stond in het teken van het inventariseren van het huidige gebruik van Office 97. Vervolgens zijn in fase vier de mogelijke alternatieven voor de Office omgeving geïnventariseerd. In de vijfde fase zijn bedrijfskritische en risicovolle Office omgevingen getest in een omgeving met de nieuwe Office producten. Tot slot heeft de laatste fase in het teken gestaan van het opleveren van een eindrapportage en het verzorgen van een presentatie van de resultaten en aanbevelingen. (ibid.: 12-19) In de volgende paragraaf wordt het verloop van het Office Migratie Project besproken, waarbij met name zal worden gegaan op de wijze waarop men tot het uiteindelijke besluit is gekomen.
5.3.2 Verloop Office Migratie Project Het doel van het Office Migratie Project is een vervanger te kiezen voor het huidige Officepakket. In de bestudering van de mogelijke alternatieven als vervanging van het huidige Officepakket zijn de knock-out criteria van toepassing. Knock-out criteria zijn de criteria die doorslaggevend zijn in de keuze voor een nieuw Officepakket en deze criteria zijn in principe functioneel van aard. Het gaat om functionaliteiten die niet meer beschikbaar zijn na de migratie, functionaliteiten die niet gemist kunnen worden en waarvoor geen haalbaar alternatief is. Een voorbeeld hiervan zijn de koppelingen met het huisstijlsysteem. (Beumer e.a., 2005: 9) Als blijkt dat een Officepakket niet aan deze criteria voldoet, dan valt het pakket direct af als mogelijke vervanger voor Microsoft Office 97. Het gebruik van de Knock-out zal leiden 84
tot een beperkte shortlist met mogelijke alternatieven waartussen gekozen dient te worden op basis van de overige criteria. Bij deze criteria valt te denken aan bijvoorbeeld de functionaliteit van het nieuwe Officepakket, dat nauwelijks afwijkt van de functionaliteit van Office 97 en het gebruiksgemak, dat niet wordt verminderd. (ibid.: 9) De alternatieven die met elkaar overwogen werden waren: OpenOffice.org 1.1.4 en 2.0, Microsoft Office 2003 en XP, Sun StarOffice 7 en 8, Corel Wordperfect Office 12 en Lotus SmartSuite 9.8 (ibid.: 4-8). Op basis van het knock-out criteria en daarnaast de voorkeur van de raad van de gemeente Eindhoven voor het gebruik van open source software is de keuze gemaakt voor OpenOffice.org 2.0 en Microsoft Office 2003, waaruit later uit de inventarisatie- en testfase (van de applicaties die samenhangen met Office 97) zal blijken wat de definitieve keuze wordt (ibid.: 10). Bij de start van het Office Migratie Project is gedefinieerd dat in principe gekozen wordt voor OpenOffice.org 2.0, tenzij de kosten van de migratie niet acceptabel zijn of dat de continuïteit van de organisatie in gevaar wordt gebracht. Daarnaast stellen de heer Beumer e.a. van M&I/PARTNERS dat “duidelijk is dat het gebruik van een standaard uitwisselingsformaat zoals bij OpenOffice.org de beste garantie is voor een toekomstvast concept. Uitwisseling met andere organisaties kan en zal in steeds grotere mate plaatsvinden door middel van PDF, HMTL en XML” (ibid.: 10). Op voorhand zou er ook geen reden zijn dat niet voor OpenOffice.org 2.0 gekozen kon worden. Zo zijn de licentiekosten voor OpenOffice.org nihil en de kosten voor opleidingen en trainingen bij OpenOffice.org vergelijkbaar met die van Microsoft Office 2003 (ibid.: 11). Bovendien biedt de keuze voor een product dat breder inzetbaar is meer mogelijkheden voor de toekomst. Microsoft Office 2003 is namelijk alleen beschikbaar voor het Windows en MacOS platform, waardoor overschakeling naar bijvoorbeeld Linux daardoor niet mogelijk is. Ook wordt vanuit de gebruikerskant een steeds grotere druk uitgeoefend om gebruik te maken van open standaarden, zodat applicaties met een andere functionaliteit of andere leveranciers eenvoudig kunnen worden aangesloten (ibid.: 12). Twee weken na het verschijnen van het rapport met het overzicht van de mogelijke alternatieven en hetgeen beschreven in de vorige alinea, is er binnen de projectgroep een notitie van M&I/PARTNERS verspreid die de stand van zaken weergaf zoals het er op dat moment voorstond. In deze notitie werden de eerste conclusies getrokken naar aanleiding van de inventarisatiefase naar de applicaties die gebruik maken van Office 97. Geconcludeerd werd dat de overgang naar OpenOffice.org lastig zou zijn, onder andere
85
vanwege het gebrek aan expertise binnen de gemeentelijke organisatie van Eindhoven, en ook meer tijd zou gaan kosten dan ervoor gepland stond (Kaas, 2005c). Er werd echter niet concreet beargumenteerd waarom er voor Microsoft Office moet worden gekozen. Al eerder werd namelijk tijdens de bijeenkomst van het Office Migratie Project op 12 april 2005 geconstateerd dat er binnen de gemeentelijke organisatie te weinig kennis bestaat over OpenOffice.org 2.0 én Microsoft Office 2003, bij zowel een migratie naar de nieuwe versie van Microsoft Office als het open source Officepakket zou het huisstijlsysteem moeten worden aangepast/herschreven en diverse applicaties en koppelingen opnieuw moeten worden geprogrammeerd. Verder werd in de notitie beweerd dat er onduidelijkheid bestaat over de kosten die een migratie naar OpenOffice.org 2.0 met zich zou meebrengen (ibid.). Echter, er wordt niet toegelicht wat de kosten zijn van de migratie naar Microsoft Office 2003, terwijl het zeker van belang hier een indicatie van te geven aangezien al eerder werd gesteld dat bijvoorbeeld de hoogte van de kosten voor opleidingen en trainingen bij beide pakketten vergelijkbaar zouden zijn (Beumer e.a., 2005: 11). Later zal namelijk ook duidelijk worden, uit een document dat dateert van 14 juni 2005, dat voor de migratie naar Microsoft Office 2003 drie verschillende soorten opleidingen nodig zijn, om onder andere de medewerkers binnen het Facilitair Bedrijf en de eindgebruikers de benodigde kennis met betrekking tot Microsoft Office 2003 bij te brengen (Van der Steen, 2005b). Op deze notitie van M&I/PARTNERS werd ook in de bijeenkomst van 22 april 2005 door leden van de projectgroep niet positief gereageerd, omdat het te weinig argumenten zou bevatten om voor Microsoft Office 2003 te kiezen en niet voor OpenOffice.org 2.0. Echter, ondanks de kritiek die de projectgroep op de notitie had, neigde men in dezelfde bijeenkomst waarin over de notitie gesproken werd te kiezen voor Microsoft Office 2003. Microsoft Office 2003 zou voor minder problemen zorgen dan OpenOffice.org 2.0, terwijl eerder tijdens deze bijeenkomst nog gesteld werd dat beide pakketten voor problemen zouden zorgen. Er bestaat angst dat applicaties niet meer zullen werken als men OpenOffice.org gebruikt, maar in de bijeenkomst op 12 april 2005 was toch al geconstateerd dat deze problemen ook zullen optreden bij het gebruik van Microsoft Office 2003? Ook waar de financiële gevolgen van een migratie eerder tijdens het Office Migratie Project een grote rol speelden voor het maken van een keuze, lijkt ook dat nu ineens niet meer in de weg te staan om voor het Officepakket van Microsoft te kiezen. De keuze was na de bijeenkomst van 22 april 2005 dus al te voorspellen, maar op 24 mei 2005 werd dan definitief de knoop doorgehakt: Microsoft Office 97 zal vervangen worden door Microsoft Office 2003. De belangrijkste conclusies in het definitieve besluit luiden als
86
volgt: “In de projectgroepvergadering van 24 mei 2005 is algemeen geconstateerd dat de resultaten van de inventarisatie op zich onvoldoende zijn om de keuze voor een van beide Office-alternatieven hard te onderbouwen. Enerzijds is geconstateerd dat een aanzienlijk deel van de gevraagde informatie niet kan worden opgeleverd. (...) Daarnaast is gebleken dat bij een aantal cijfermatige conclusies de steekproef waarop de conclusie was gebaseerd niet representatief was” (Van der Steen, 2005a). Er is gekozen voor Microsoft Office 2003 en niet OpenOffice.org 2.0, om de volgende reden: “Een groot aantal leveranciers zien OpenOffice.org tot nu toe niet als strategisch te ondersteunen platform. De verwachting is wel dat dit in de toekomst zal veranderen, maar daar hebben we nu nog niets aan” (ibid.). Bij het ontbreken van platformondersteuning door leveranciers, zou er binnen de organisatie veel kennis en vaardigheid moeten zijn om de koppelingen tussen de office-omgeving en andere applicaties tot stand te brengen. Er is echter geconstateerd dat er bij de gemeente Eindhoven weinig tot geen inzicht is in de huidige koppelingen, en daarom zou met name een migratie naar met name OpenOffice.org tot een zeer risicovolle operatie worden beschouwd. De aanleiding voor deze hele discussie en überhaupt de start met het Office Migratie Project was de houding van de leveranciers. De gemeente Eindhoven was immers nog tevreden over de functionaliteit van Microsoft Office 97 en dat vormde geen aanleiding om op andere software over te stappen. Het zijn echter de leveranciers die na 2005 geen ondersteuning meer willen bieden aan Office 97 (Kaas, 2005a). In andere woorden: de leveranciers hebben de gemeentelijke organisatie van Eindhoven ertoe gedwongen om nieuwe software aan te schaffen. De leveranciers hebben de organisatie in hun grip, want zij bepalen wanneer het tijd is om nieuwe software aan te schaffen. De gemeentelijke organisatie van Eindhoven had ook nog langer gebruik kunnen blijven maken van Office 97. Immers, zij gebruiken het al sinds 1998 en na al die jaren waarin de software uitvoerig getest is en problemen zijn verholpen, is het nu een stabiel product waar nog prima mee te werken valt en waarvoor intussen bij leveranciers niet meer aangeklopt hoefde te worden. Dus wanneer de leveranciers geld willen incasseren, zij de organisaties kennelijk zodanig in hun macht hebben, dat dit kan worden afgedwongen en het klaarblijkelijk ook nog lukt om in ieder geval al de gemeente Eindhoven in een positie te manoeuvreren waarin het onmogelijk is om nog langer gebruik te kunnen maken van het huidige Officepakket. Naast dat de leveranciers door hun houding in feite de aanzet hebben gegeven tot het Office Migratie Project, hebben zij als klap op de vuurpijl ook nog bepaald welk product de gemeentelijke organisatie van Eindhoven moest aanschaffen. Uit het onderzoek van M&I/PARTNERS (Kaas, 2005c) en de bevindingen naar aanleiding van het gesprek dat
87
M&I/PARTNERS had met de gemeente Haarlem op 10 maart 2005 (Kaas, 2005b) werd geconcludeerd dat, wil duidelijk worden of ook OpenOffice.org 2.0 in aanmerking komt als vervanging van Microsoft Office 97, er een aanzienlijke vertraging zou optreden in het project.
Informatie
over
de
werking
van
koppelingen
tussen
de
applicaties
en
OpenOffice.org 2.0 kon door leveranciers niet op kort termijn gegeven worden en ook heeft de gemeentelijke organisatie van Haarlem ervaren een lange voorbereidingstijd nodig te hebben voor de migratie naar open source software. Uitstel van een migratie tot na 2005 was echter onmogelijk, gelet op de uitspraken van leveranciers dat zij niet langer Microsoft Office 97 ondersteunen. Kortom, door tijdsdruk lieten de leveranciers de gemeentelijke organisatie van Eindhoven geen andere keuze dan te migreren naar Microsoft Office 2003. Concluderend kunnen we stellen dat de gemeentelijke organisatie van Eindhoven zich heeft laten inpalmen door de leveranciers. Zolang gemeentelijke organisaties de leveranciers de dienst laten uitmaken en zelf niet een meer strijdbare houding aannemen, zullen de leveranciers het tijdstip bepalen waarop er nieuwe software moet worden aangeschaft en welke software dit dan zal moeten zijn. Als de gemeente Eindhoven haar positie ten opzichte van de leveranciers niet verandert, zal niet alleen open source software geen eerlijke kans krijgen maar überhaupt alles wat de leveranciers niet zint.
5.4 Usability in een organisatiecultuur De keuze voor een bepaald product lijkt niet alleen af te hangen van de kwaliteiten van een product in termen van usability, zoals understandability, operability, customisability en user-friendliness (zie hoofdstuk één), maar lijkt ook beïnvloed te worden door de cultuur van de organisatie. Zoals geconcludeerd kan worden uit paragraaf 5.3 moeten alle besluiten door een filter heen, dat organisatiecultuur heet. In het geval van de gemeente Eindhoven, is er sprake van een cultuur waarin er voor het maken van besluiten met betrekking tot de aanschaf van software een zeer grote en invloedrijke rol is weggelegd voor de leveranciers en een risicomijdend gedrag dat optimaal tot zijn recht komt. Een goed voorbeeld hiervan is het Office Migratie Project. In het Office Migratie Project was er op voorhand geen reden dat niet voor OpenOffice.org 2.0 gekozen kon worden, in plaats van waar de organisatie uiteindelijk haar keuze op heeft laten vallen: Microsoft Office 2003. De licentiekosten voor OpenOffice.org zijn nihil en de kosten voor opleidingen en trainingen bij OpenOffice.org zijn vergelijkbaar met die van 88
Microsoft Office 2003 (Beumer e.a., 2005: 11). Echter, later is duidelijk geworden dat voor de migratie naar Microsoft Office 2003 drie verschillende soorten opleidingen nodig zijn (Van der Steen, 2005b). Er is dan ook nog geen duidelijkheid geschept over de kosten voor opleidingen en trainingen bij de migratie naar OpenOffice.org 2.0. Daarnaast zou Microsoft Office 2003 minder mogelijkheden bieden voor de toekomst, omdat het minder breed inzetbaar is dan OpenOffice.org 2.0. Zo kunnen ook door het gebruik van open standaarden applicaties met een andere functionaliteit of andere leveranciers eenvoudig kunnen worden aangesloten (Beumer e.a., 2005: 12). Ook diverse andere argumenten laten zien dat de keuze voor Microsoft Office 2003 niet voor de hand lag. Zo werd in de bijeenkomst van 22 april 2005 ter discussie gesteld dat zowel Microsoft Office 2003 als OpenOffice.org 2.0 voor problemen zouden zorgen bij de migratie. Zo zouden diverse applicaties die nauw verweven zijn met het oude Officepakket Microsoft Office 97, voor veel problemen zorgen en mogelijk zelfs niet meer werken als een nieuw Office pakket in gebruik wordt genomen. Op basis van de knock-out criteria voldoen zowel Microsoft Office 2003 als OpenOffice.org 2.0 aan de gestelde eisen in een nieuw te gebruiken Officepakket binnen de gemeentelijke organisatie van Eindhoven. Beide pakketten zouden qua functionaliteit nauwelijks afwijken van de functionaliteit van Office 97 en ook zou het gebruiksgemak niet verminderen bij het gebruik van één van deze twee Officepakketten (ibid.: 9). Concluderend kunnen we stellen dat Microsoft Office 2003 als OpenOffice.org 2.0 in ieder geval wél door de gemeente Eindhoven blijken te zijn getest op hun productkwaliteiten, onder andere de customisability, understandability, operability en user-friendliness. Ook is er gekeken naar andere factoren, die niet van toepassing zijn op de usability van een softwareproduct, zoals de flexibiliteit, functionaliteit en de kosten. Echter, op basis van deze testen is dan niet verklaarbaar waarom er niet voor OpenOffice.org 2.0 is gekozen. Kennelijk ligt er dan een andere reden ten grondslag aan het feit dat er uiteindelijk voor Microsoft Office 2003 is gekozen. De reden dat er voor Microsoft Office 2003 is gekozen en niet voor OpenOffice.org 2.0 blijkt helemaal niet te liggen aan de incompetentie van het open source kantoorautomatiseringspakket. Integendeel: het waren niet de kosten, de functionaliteit, de flexibiliteit of enige andere factor uit het Quint-model, maar de enige doorslaggevende factor in het Office Migratie Project was de culturele wenselijkheid (cultural desirability).
89
De culturele wenselijkheid die er binnen de gemeentelijke organisatie van Eindhoven te ontwaren is, behelst het feit dat men de neiging heeft zich te laten inpalmen door de softwareleveranciers. In besluitvormingsprocessen wordt er geen keuze gemaakt voor het product dat voor de organisatie het beste zou zijn, maar de keuze hangt af van waar de leverancier ondersteuning aan geeft. Alle argumenten voor de aanschaf van Microsoft Office 2003 in plaats van OpenOffice.org 2.0, zoals het niet kunnen uitstellen van het Office Migratie Project en het ontbreken van ondersteuning bij OpenOffice.org 2.0, waren te herleiden naar het feit dat de gemeentelijke organisatie kruipt onder de macht van de leveranciers. De situatie is binnen de gemeentelijke organisatie van Eindhoven zelfs zo extreem dat nota bene een raadsbesluit niet op kan tegen deze cultuur, aangezien de proprietary leveranciers niet alleen de aanzet hebben gegeven tot het starten van het Office Migratie Project, maar daarnaast ook de uitkomst hebben beïnvloedt door de gemeentelijke organisatie een besluit te laten nemen onder tijdsdruk (zie paragraaf 5.3.2). Cultuur blijkt dus ook de belangrijkste barrière te zijn voor organisatieverandering. Medewerkers van de gemeente Eindhoven spreken zich ook uit over de gewoonte die er lijkt te bestaan binnen deze organisatie, zoals bijvoorbeeld de heer Boris Liebrand van het Facilitair Bedrijf: “Alles wat nieuw is wordt afgeschoten”. Daarnaast verklaart de heer Jack Janssen van de Concernstaf dat allerlei zaken die onbekend zijn binnen de gemeente Eindhoven, zoals open source software, moeilijk geaccepteerd worden: “Onbekend maakt onbemind”. Het wordt dus niet ontkend, maar zijn zij zich wel in díe mate bewust van de (impact van de) cultuur die er bestaat binnen hun organisatie?
5.5 Uitbreiding van het concept usability In de bestaande visies van het concept usability wordt er geen rekening gehouden met het aspect van organisatieculturen. Aan de hand van de resultaten uit mijn onderzoek naar hoe de besluitvorming van een gemeentelijke organisatie tot stand komt wat betreft de aanschaf van software, wil ik daarom de bestaande theoretische benadering(en) van usability bijstellen. Uit de resultaten van mijn onderzoek kan geconcludeerd worden dat open source software bij vele gemeentelijke organisaties geen serieuze kans krijgt, want niemand kan echt goed uitleggen waarom oss niet geschikt zou zijn als mogelijk alternatief voor de vervanging van de huidige software (zie paragraaf 5.1 en 5.2). De argumenten die door bepaalde gemeenten hiervoor worden gegeven, worden weerlegd door bijvoorbeeld de gemeente 90
Haarlem. Open source software zou in de 'usability-termen' wellicht het meest geschikt zijn in bepaalde gevallen, maar toch wordt het nog beperkt gebruikt binnen gemeentelijke organisaties. In andere woorden: er lijkt een zeer belangrijke reden ten grondslag te liggen voor het verklaren van het feit waarom een gemeentelijke organisatie voor een bepaald softwareproduct kiest. Het is de culturele wenselijkheid die, naast de kwaliteiten van een product in termen van usability, zeer zeker een grote rol speelt in het maken van een keuze voor een bepaald product. De gemeentelijke organisatie van Eindhoven is hier een goed voorbeeld van, alhoewel hier wel sprake was van een extreme situatie. Culturele wenselijkheid ofwel cultural desirability zou ik als (nieuwe) eigenschap willen onderbrengen
binnen
het
concept
usability.
Onder
usability
zijn
alle
kwaliteitseigenschappen geschaard, die allemaal te maken hebben psychologische aspecten als aantrekkelijkheid, duidelijkheid, gebruiksgemak en gebruikersvriendelijkheid. Culturele wenselijkheid geeft verder inhoud aan het begrip usability, ook op psychologisch vlak. En dat verklaart waarom de culturele wenselijkheid deel uitmaakt van usability, naast onder andere attractivity en user-friendliness, en niet als bijvoorbeeld een nieuwe hoofdgroep
naast
functionality,
reliability,
usability,
efficiency,
maintainability
en
portability opgenomen kan worden in het Quint-model (zie paragraaf 1.1). Om een metriek te bedenken voor culturele wenselijkheid is een vervolgonderzoek van belang. Zoals we gezien hebben bij de gemeentelijke organisatie van Eindhoven kan culturele wenselijkheid een zeer grote rol spelen in een besluitvormingsproces rond de aanschaf van software en is het dus een nieuw onderdeel van het concept usability.
91
6. Conclusies en aanbevelingen De resultaten van het onderzoek laten enerzijds zien dat Nederlandse gemeentelijke organisaties de voordelen van oss wel inzien, maar anderzijds niet overtuigd zijn omdat naar voren komt dat er drempels zijn die ervoor zorgen dat de grote potentie slechts in beperkte mate wordt benut.
6.1 Krijgt open source software een eerlijke kans in besluitvormingsprocessen? De drempels die met name een vlugge en meer uitgebreide verspreiding van open source software in de weg staan, zijn voor de gemeentelijke organisaties de (opleidings)kosten en het gebrek aan ondersteuning van leveranciers. Men zegt ook liever te volgen dan de eerste te zijn met het inzetten van oss. De gemeente Haarlem heeft echter al de spits afgebeten door oss ook op de desktop in te zetten, daar waar oss door andere gemeentelijke organisaties nu met name nog op servers wordt ingezet. De gemeentelijke organisatie van Haarlem heeft positieve ervaringen met oss. Ook Microsoft ziet de bui al hangen, en doet gemeentelijke organisaties voorstellen tot enorme prijsverlagingen van hun producten. Toch heeft dit er tot dusver niet toe geleid dat andere gemeentelijke organisaties de gemeente Haarlem hierin volgen. Men lijkt ook onvoldoende op de hoogte te zijn van de mogelijkheden van oss, zoals de onafhankelijkheid van leveranciers. Vele gemeentelijke organisaties, zoals de gemeente Arnhem, Breda, Rotterdam
en
Eindhoven,
laten
hun
keuze
tot
de
aanschaf
van
een
bepaald
softwareproduct nog steeds afhangen van de grillen van de leveranciers. De proprietary leveranciers willen uiteraard niet dat de gemeentelijke organisaties onafhankelijk van hen worden door het gebruik van oss. Dus zolang gemeentelijke organisaties de softwareleveranciers de dienst laten uitmaken en ook zelf niet in eigen beheer oss ontwikkelen, zullen de leveranciers het tijdstip bepalen waarop er nieuwe software moet worden aangeschaft en welke software dit dan zal moeten zijn. Open source software zal dan binnen organisaties als de gemeente Arnhem, Breda, Rotterdam en Eindhoven geen eerlijke kans krijgen.
6.2 Het bundelen van krachten Voor een succesvolle toepassing van open source software is de samenwerking tussen gemeentelijke organisaties cruciaal. Er blijkt echter nu nog niet of nauwelijks sprake te zijn van samenwerking op dit gebied, maar er is wél duidelijk interesse bij de gemeentelijke 92
organisaties naar informatie over oss. De gemeente Haarlem is hét voorbeeld voor andere gemeentelijke organisaties dat een succesvolle toepassing van oss mogelijk is. De voorbereidingen kosten wel veel tijd, dus voor het in de toekomst willen gebruiken van oss (en om te voorkomen dat leveranciers nog misbruik kunnen maken van hun machtspositie) moeten gemeentelijke organisaties zich nu al op deze voorbereidingen richten. De voorbereidingen zijn slechts een eenmalige investering en zouden beduidend minder tijd kosten wanneer gemeenten hun krachten bundelen, om zodoende een snellere implementatie van oss binnen gemeentelijke organisaties mogelijk te maken. De stichting OSSO is een eerste, grote stap in de richting van samenwerking tussen gemeentelijke organisaties op het gebied van oss. De stichting OSSO is namelijk gericht op kennisuitwisseling tussen gemeentelijke organisaties, zodat de gemeenten kunnen profiteren van de ontwikkelingen van andere gemeenten en niet onnodig tijd hoeven te steken in zaken waar de andere gemeenten al resultaten mee geboekt hebben. Naast gezamenlijk te profiteren van de voordelen van oss en verdere ontwikkelingen op dit gebied te bevorderen in het voordeel van alle gemeentelijke organisaties, zal het gezamenlijke beheer van oss tevens de machtspositie van de leveranciers doen inkrimpen en de leveranciers naar de hand te zetten.
6.3 Usability: het complete concept Uit mijn onderzoek is gebleken dat gemeentelijke organisaties hun keuze voor een bepaald softwareproduct niet alleen laten afhangen van de kwaliteiten van het product, maar tevens de culturele wenselijkheid binnen een organisatie van invloed is op het maken van de definitieve keuze. De gemeentelijke organisaties hebben de neiging zich te laten inpalmen door de softwareleveranciers, want in het geval van de gemeente Eindhoven wordt er in besluitvormingsprocessen geen keuze gemaakt voor het product dat voor de organisatie het beste zou zijn maar hangt de keuze af van dat product waar door de leverancier ondersteuning aan wordt gegeven. In de bestaande visies van het concept usability wordt er nog geen rekening gehouden met het aspect van organisatieculturen. Met de resultaten uit mijn onderzoek naar hoe de besluitvorming van een gemeentelijke organisatie tot stand komt wat betreft de aanschaf van software heb ik aangetoond dat de culturele wenselijkheid, naast de kwaliteiten van 93
een product, zeer zeker een grote rol speelt in het maken van een keuze voor een bepaald product. Het aspect van de culturele wenselijkheid wordt geplaatst bij de andere aspecten van usability en zal daarmee een meer complete inhoud aan het begrip usability geven.
6.4 Bedrijfsvoering gemeente Eindhoven Binnen de gemeentelijke organisatie van Eindhoven ervaren werknemers dat sinds de centralisatie de samenwerking formeler is geworden en daarnaast de organisatie ook bureaucratischer is geworden. Verder zou er sprake zijn van een slechte samenwerking tussen de afzonderlijke diensten, omdat er binnen de diensten verschillend te werk wordt gegaan en men niet goed van elkaar op de hoogte is door een slechte uitwisseling van gegevens. Ook de Concernstaf blijkt niet op de hoogte te zijn van hoe er binnen de verschillende diensten te werk wordt gegaan, juist diegenen die hier wél van op de hoogte zouden moeten zijn. Binnen de gemeentelijke organisatie van Eindhoven lijkt er een gebrekkige regie te zijn bij de aanschaf van software, omdat de klant bepaalt wat er komt en dat leidt tot wildgroei. Naast technische richtlijnen moeten er ook richtlijnen komen, die de klant een bepaalde keuze voorlegt in de vorm van een 'menukaart' bijvoorbeeld. Iedereen geeft elkaar de schuld voor het mislukken en/of stroef verlopen van besluitvormingsprocessen. Dit is onder andere te wijten aan de onduidelijkheid die er bestaat bij de medewerkers over de bevoegdheden binnen de gemeentelijke organisatie van Eindhoven, en dit alles heeft als resultaat dat de klant de baas wordt. Deze onduidelijkheid over de bevoegdheden moet worden weggenomen. Er is een scheidsrechter nodig, iemand die ingrijpt wanneer het uit de hand dreigt te lopen. Daarnaast moet er een duidelijk gemeentebreed ICT-beleid komen en een sterk bestuurlijk optreden, waardoor problemen en conflicten op voorhand uit de weg kunnen worden gegaan. Dit moet een partij zijn die sterk staat, een overkoepelend besturingsorgaan, zoals de Concernstaf. Neem ook voorbeeld aan hoe andere gemeentelijke organisaties dit aanpakken, zoals de gemeente Rotterdam, Arnhem en Tilburg. In het gemeentebrede ICT-beleid van de gemeentelijke organisatie van Rotterdam werken de diensten onderling samen en opereren zij als één concern. Daarnaast veronderstelt het nieuwe ICT-beleid van de gemeente Rotterdam een strakke concernsturing, waarbij ook periodiek een controle 94
wordt uitgevoerd naar de naleving van het ICT-beleid. Binnen de gemeentelijke organisatie van Tilburg is de macht van de klant met betrekking tot de aanschaf van software beperkt, doordat de klanten een keuze moeten maken een beperkt aanbod dat wordt voorgelegd door de ICT-afdeling in de vorm van een 'menukaart'. In tegenstelling tot het gebruik van Service Level Agreements maakt deze organisatie tevens belangrijke afspraken niet met de klant in de vorm van contracten, maar zijn deze afspraken bij voorbaat al vastgelegd in samenspraak met de directie. In de gemeentelijke organisatie van Arnhem bestaan er al standaarden sinds 1999. Dankzij de standaarden die deze gemeentelijke organisatie heeft opgesteld weet iedereen waar hij/zij aan toe is, en gezien het aantal jaar dat de standaarden al aanwezig zijn binnen deze gemeente is het ook algemeen geaccepteerd. Tevens is er voor het bewaken van de standaarden een Wijzigingsadviescommissie ingesteld, die versnippering op ICT-gebied voorkomt door de bestaande en nieuw aan te schaffen applicaties te toetsen aan de gemeentelijke standaarden. De aanvragen voor nieuwe applicaties moeten altijd aan deze commissie worden voorgelegd. De medewerkers van de gemeentelijke organisatie van Eindhoven schreeuwen om hulp, ook op het gebied van de interne communicatie. De gemeente Eindhoven zou er baat bij hebben om voor bepaalde zaken met betrekking tot de besluitvormingsprocessen voorbeeld te nemen aan hoe andere gemeentelijke organisaties dit oplossen.
95
Bibliografie •
Beumer, H., P., Kossen, W. J., Kaas, D., Onderzoek vervanging Office 97. Overzicht alternatieven (Amersfoort, 1 april 2005).
•
Bestuursdienst, ICT-beleid Gemeente Rotterdam 2004-2007 (Rotterdam, 2004).
•
Coumans, W., 'Frankrijk kiest voor Open Source. Ruim 1 miljoen computers met Linux en Co', Breekpunt (21 juni 2004). http://www.breekpunt.nl/nieuwsbericht.asp?id=9188 voor het laatst geraadpleegd op 2 augustus 2005.
•
Deacon, D., e.a., Researching Communications (Oxford University Press Inc., New York, 1999) hfd. 4, 12.
•
DesktopLinux.com, Massachusetts verdict: MS Office formats out (23 september 2005). http://www.desktoplinux.com/news/NS4797716899.html voor het laatst geraadpleegd op 21 oktober 2005.
•
Florijn, G., Greefhorst, D., 'Softwareproductkwaliteit – Ervaringen en ontwikkelingen', Informatie (Ten Hagen Stam, jaargang 43, januari/februari 2001).
•
Florijn, G, e.a., Softwarearchitectuur – Overzicht en compendium (ten Hagen Stam Uitgevers, Den Haag, 2003).
•
Forge, S., 'Towards an EU Policy for Open-Source Software', How Open is the Future? Economic, Social and Cultural Scenarios (VUB Brussels University Press, Brussel, 2005) pp. 489-503. http://crosstalks.vub.ac.be/documents/howopenisthefuture_CROSSTALKSBOOK1.pdf voor het laatst geraadpleegd op 17 augustus 2005.
•
Ghosh, R. A., Glott, R., Open Standaarden en Open Source Software in Nederland. Een kwantitatief onderzoek naar houding en gedrag van de Nederlandse overheid in 2004 (Maastricht, december 2004). http://www.ososs.nl/attachment.db?17019 voor het laatst geraadpleegd op 19 april 2005.
•
Giesberts, R., Linux en OpenOffice (19 juni 2003). http://www.groenlinksutrecht.nl/nieuws.php?item=355 voor het laatst geraadpleegd op 2 augustus 2005.
•
Hanappe, P., 'Building Open Ecosystems for Collaborative Creativity', How Open is the Future? Economic, Social and Cultural Scenarios (VUB Brussels University Press, Brussel, 2005) pp. 199-229. http://crosstalks.vub.ac.be/documents/howopenisthefuture_CROSSTALKSBOOK1.pdf voor het laatst geraadpleegd op 17 augustus 2005.
•
Hofstede, G., Allemaal andersdenkenden (Uitgeverij Contact, 1991).
96
•
IDA, Singapore’s Ministry of Defence announces decision to switch to OpenOffice.org (22 oktober 2004). http://europa.eu.int/idabc/en/document/3396 voor het laatst geraadpleegd op 14 juli 2005.
•
ICTU, Van Maatwerk naar Open Source. Handreiking voor het succesvol opzetten van open source projecten (Den Haag, 25 mei 2004). http://www.ososs.nl/attachment.db?9539
voor
het
laatst
geraadpleegd
op
14
april 2005. •
Intranet Pino (Personeel INformatie en Organisatie), gemeente Eindhoven.
•
ISO – International Organization for Standardization. http://www.iso.org voor het laatst geraadpleegd op 29 augustus 2005.
•
ITSMF Nederland, IT Service Management, een introductie (van Haren publishing, Zaltbommel, september 2002).
•
Jordan, P. W., An introduction to Usability (Taylor & Francis, London, 1998).
•
Kaas, D., Onderzoek nieuwe Office omgeving. Eindhoven: Project 05.083 Migratie Microsoft Office Suite97 (Amersfoort, 2 februari 2005a).
•
Kaas, D., Verslag gesprek op donderdag 10 maart 2005 16.00 uur. Project: Office migratie Eindhoven, 104315-haarlem-100305 (16 maart 2005b).
•
Kaas, D., Notitie - Afwegingen t.b.v. het vervolg Onderzoek migratie Office 97 (16 april 2005c).
•
Kelfkens, G., ‘Eindhoven bezuinigt met open source’, Automatisering Gids (12 november 2004). http://www.automatiseringgids.nl/news/default.asp?nwsId=29485
voor
het
laatst
geraadpleegd op 25 april 2005. •
Klijnsma, H., e.a., Initiatiefvoorstel open software (Groningen, november 2002). http://www.groenlinksgroningenstad.nl/publicaties/opensourceini.shtml voor het laatst geraadpleegd op 2 augustus 2005.
•
Klöpping, H., 'Waterdichte software. Ook commerciële bedrijven werpen zich op open source', Computable (nummer 42, 16 oktober 1998) p. 33.
•
Knubben, B. S. J., Gemeente Terneuzen: “Open source is geen alles of niets keuze!” (27 januari 2005). http://www.ososs.nl/attachment.db?16009
voor
het
laatst
geraadpleegd
op
14
april 2005. •
Kwadijk, J., Wisseling van de macht (LEMMA BV, Utrecht, 2005).
•
Mierlo, P. van, Technische richtlijnen infrastructuur, gemeente Eindhoven, versie 0.3 concept (februari 2005).
97
•
Ministerie van Economische Zaken, Beantwoording vragen van het lid Van Dam (28 oktober 2004). http://www.minez.nl/content.jsp?objectid=27135 voor het laatst geraadpleegd op 15 augustus 2005.
•
Mintzberg, H., Organisatiestructuren (Academic Service, Schoonhoven, 1992).
•
Mom, P., ‘OSSO moet gemeenten aan open source helpen’, Automatisering Gids (nummer 15, 39e jaargang, 15 april 2005).
•
Nielsen, J., Mack, R. L., Usability Inspection Methods (John Wiley & Sons, Inc., New York, 1994).
•
Open Source Software Lab. http://www.ossl.nl voor het laatst geraadpleegd op 5 augustus 2005.
•
Programma OSOSS, programma Open Standaarden en Open Source Software voor de overheid http://www.ososs.nl voor het laatst geraadpleegd op 5 oktober 2005.
•
Programma OSOSS, Gemeente Haarlem naar OpenOffice.org (3 maart 2004a). http://www.ososs.nl/article.jsp?article=8703 voor het laatst geraadpleegd op 27 juli 2005.
•
Programma OSOSS, Van Maatwerk naar Open Source. Handreiking voor het succesvol opzetten van open source projecten (Den Haag, mei 2004b). http://www.ososs.nl/attachment.db?9539 voor het laatst geraadpleegd op 10 oktober 2005.
•
Schildermans, J., Zwiekhorst, J., 'Pak inzet open source pragmatisch aan. Voortdurende beveiligingsproblemen slaan barsten in Microsoft-schild', Computable (nummer 14, 38e jaargang, 8 april 2005) pp. 10-12.
•
Shackel, B., Richardson, S., Human Factors for Informatics Usability (Cambridge University Press, Cambridge, 1991).
•
Simons, J., 'Interface', Interface en cyberspace. Inleiding in de nieuwe media (Amsterdam, 2002) pp. 117-145.
•
Stallman, R., 'The GNU Operating System and the Free Software Movement', Open Sources: Voices from the open Source Revolution (1999). http://www.oreilly.com/catalog/opensources/book/stallman.html
voor
het
laatst
geraadpleegd op 1 september 2005. •
Steen, E. van der, Voorrapportage Migratie Office 97 (Eindhoven, 27 mei 2005a).
•
Steen, E. van der, Fase 2 Migratie Office 97 (Eindhoven, 14 juni 2005b).
•
Thompson, B., 'UK tests open source waters', BBC News (10 oktober 2003). http://news.bbc.co.uk/1/hi/technology/3181108.stm voor het laatst geraadpleegd op 2 augustus 2005.
98
•
Velde, R. te, Open source: een standaard rol voor de overheid? (oktober 2003). http://www.zenc.nl/publicaties/download.php?file=open_source.pdf
voor
laatst
geraadpleegd op 25 april 2005. •
Vereniging Open Source Nederland. http://www.vosn.nl voor het laatst geraadpleegd op 12 augustus 2005.
•
Verkerk, E., ‘Moeten gemeenten overstappen op open source software?’, Tijdschrift B&G (november 2003). http://www.bng.nl/bng/pdf/200311Verkerk_10-12.pdf voor het laatst geraadpleegd op 11 april 2005.
•
Visser, J., Het Open Source Fenomeen (19 november 2002). http://www.josvisser.nl/lib/wp.pdf voor het laatst geraadpleegd op 10 augustus 2005.
•
Vrede, T. de, 'Haarlem bespaart fiks met consolidatieslag', Automatisering Gids (nummer 43, 38e jaargang, oktober 2004).
•
Weber, S., The Success of Open Source (Harvard University Press, England, 2004).
•
Werkgroep Elektronische Dienstverlening, Visie op eService, ter verbetering van de kwaliteit van dienstverlening (juli 2004).
•
Website gemeente Eindhoven. http://www.eindhoven.nl voor het laatst geraadpleegd op 14 juli 2005.
•
Wheeler, D. A., Comments on Microsoft's Letter to Massachusetts (29 oktober 2005). http://www.groklaw.net/article.php?story=20051029212458555 geraadpleegd op 31 oktober 2005.
99
voor
het
laatst
Bijlage - interviews
Interviews gemeente Eindhoven •
Interview Marc Braun, Facilitair Bedrijf, 11 mei 2005.
•
Interview Riny van Deursen, Facilitair Bedrijf, 13 juni 2005.
•
Interview Ton van Erp, Facilitair Bedrijf, 25 mei 2005.
•
Interview Pierre van den Heuvel, Facilitair Bedrijf, 27 mei en 5 juli 2005.
•
Interview Jack Janssen, Concernstaf, 20 juni 2005.
•
Interview Trea Karsies, Facilitair Bedrijf, 9 mei 2005.
•
Interview Frank Kurcaba, Facilitair Bedrijf, 8 juni 2005.
•
Interview Boris Liebrand, Facilitair Bedrijf, 17 mei 2005.
•
Interview Peter van Mierlo, Facilitair Bedrijf, 9 mei 2005.
•
Interview Angela de Rijck, dienst Algemene en Publiekszaken, 23 juni 2005.
•
Interview Harrie Smits, dienst Stedelijke Ontwikkeling en Beheer, 24 mei 2005.
•
Interview Paul Steehouwer, dienst Werk, Zorg en Inkomen, 29 juni 2005.
•
Interview Eric van der Steen, dienst Maatschappelijke Ontwikkeling, 28 april en 11 mei 2005.
•
Interview Ad Steenbakkers, dienst Algemene en Publiekszaken, 23 juni 2005.
•
Interview Arend Zwaga, dienst Werk, Zorg en Inkomen, 30 juni 2005.
Interviews andere gemeentelijke organisaties •
Interview Michel Blezer, gemeente Tilburg, 26 mei 2005.
•
Interview Jascha Gregorowitsch, gemeente Breda, 9 juni 2005.
•
Interview Peter Karssenberg, gemeente Arnhem, 14 juni 2005.
•
Interview Cees Jan Prevo, gemeente Rotterdam, 1 juni 2005.
•
Interview Arie Sigterman en Frans Vrijmoed, gemeente Haarlem, 2 juni 2005.
100
