Business Case ‘Open Softwarestrategie Gemeente Amsterdam’
Opdrachtgever: Bestuursdienst Gemeente Amsterdam Auteur: Drs. S.D. Wildeboer - DCE Consultants B.V.
Datum: 27 oktober 2006 Versie: 1.0 Externe versie
Historie/Distributie business case Wijzigingshistorie
Datum
Auteur
Versie
Omschrijving
30-08 01-09 15-09 21-09 27-09
S.D. Wildeboer S.D. Wildeboer S.D. Wildeboer S.D. Wildeboer/M. Chen M. Chen
0.2 0.3 0.5 0.8 0.9
16-10 18-10
S.D. Wildeboer/M. Chen M. Chen
0.11 1.0
Tegenlezen Bart Prehn Versie voor de toetsingscommissie Versie voor het projectteam – 1e toetsing Versie voor klankbordgroep Informatievoorziening Versie voor Staf Wethouder ICT en Stuurgroep Informatievoorziening Versie voor Commissie Informatievoorziening Definitieve versie
Distributie
Versie
Gremium
Leden
0.3
Toetsingscommissie1
0.5
Projectteam
0.8
Klankbordgroep Informatievoorziening
Herman Marres, Ron Blankers, Ja-Willem Broekema, Maurice van Erven, Peter Mol ,Rob Hofman, Jo Lahaye, Dirk van Roode Manou Chen, Bart Prehn, Ronald Schaap, Diana Hoogeveen Irene Verschuur, Raymond van Erkel, André van der Valk, André Verbart, Bas de Melker, Frans van Weeghel, Geert Wind, Josine van de Voort, Martijn Verhoef, Marcel Tieman, Menno Gmelig Meijling, Peter van Leeuwen, Priscylla Beentjes, Ruud Klunder, Stephan van Wijk, Soraya Kluft.
0.9
0.11 1.0
1
Toetsingscommissie1 Staf Wethouder ICT
Maarten van Poelgeest, Sebastiaan Jacobs, Jan Schans, Dries Bartelink, Jos Vermeulen-Windsant, André van der Valk Stuurgroep Informatievoorziening Eric ten Hulsen, Sjaak Karsten, Rienk Hoff, Coen van de Louw, Kees Hegt, Klaas de Boer, Ans Rietstra, Antoon Duijnker, Peter Mol, Paul Menting, Geert Wind, André Verbart. Commissie Informatievoorziening Maarten van Poelgeest, Tjeerd Herrema, R. Post, E.J. de Vries, Erik Gerritsen, Eric ten Hulsen, Sjaak Karsten, Klaas de Boer, Antoon Duijnker. College van B&W, Commissie ROW, Gemeenteraad
Zie Bijlage 4 voor de organisaties en functies van de leden van de toetsingscommissie.
Versie 1.0 Extern
2/72
27 oktober 2006
Inhoudsopgave HISTORIE/DISTRIBUTIE BUSINESS CASE....................................................................................... 2 INHOUDSOPGAVE.............................................................................................................................. 3 0 LEESWIJZER..................................................................................................................................... 5 1 MANAGEMENTSAMENVATTING..................................................................................................... 6 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9
AANLEIDING...................................................................................................................................................... 6 DOELSTELLINGEN................................................................................................................................................6 OPEN STANDAARDEN EN OPEN SOURCE SOFTWARE.................................................................................................... 6 OMGEVING.........................................................................................................................................................7 AANPAK: VAN SOFTWARESTRATEGIE NAAR BEOOGDE EINDSITUATIE............................................................................ 8 TOETSING VAN DE BEOOGDE EINDSITUATIE ............................................................................................................. 8 RESULTAAT .....................................................................................................................................................10 VOORLOPIG ADVIES RAAMCONTRACT MICROSOFT...................................................................................................10 BESLISPUNTEN..................................................................................................................................................11
2 NOODZAAK & DOELSTELLINGEN VAN DE BUSINESS CASE................................................... 12 2.1 ACHTERGROND................................................................................................................................................. 12 2.2 OPEN STANDAARDEN EN OPEN SOURCE SOFTWARE.................................................................................................. 13 2.3 LANDELIJKE EN INTERNATIONALE ONTWIKKELINGEN............................................................................................... 14 2.4 DOELSTELLING VAN DE BUSINESS CASE.................................................................................................................19 2.5 PROJECTOPDRACHT............................................................................................................................................19 2.6 AFBAKENING VAN DE BUSINESS CASE................................................................................................................... 20 2.6.1 Projectomgeving................................................................................................................................... 20 2.6.2 Tijdsbestek en mijlpalen........................................................................................................................20 2.6.3 Werkgebied .......................................................................................................................................... 21 2.6.4 Randvoorwaarden.................................................................................................................................21 3 VAN SOFTWARESTRATEGIE NAAR BEOOGDE EINDSITUATIE................................................ 26 3.1 INLEIDING BIJ STRATEGISCHE SOFTWAREDOELSTELLINGEN........................................................................................ 26 3.2 STRATEGISCHE SOFTWAREDOELSTELLINGEN GEMEENTE AMSTERDAM........................................................................ 26 3.2.1 Markt en Economie............................................................................................................................... 27 3.2.2 Financiën.............................................................................................................................................. 28 3.2.3 Kwaliteit en interoperabiliteit...............................................................................................................28 3.2.4 Gehanteerde strategische doelstellingen ............................................................................................. 29 3.3 TECHNISCHE EINDSITUATIES EN SCENARIO’S.......................................................................................................... 30 3.3.1 Mogelijke eindsituaties......................................................................................................................... 30 3.3.2 Vaststellen van de eindsituatie om uit te werken in de business case ..................................................35 4 TOETSING VAN BEOOGDE EINDSITUATIE EN MIGRATIESCENARIO...................................... 37 4.1 AFBAKENEN VAN HET ONDERZOEKSGEBIED............................................................................................................37 4.1.1 Onderzoeksgebied organiek..................................................................................................................37 4.1.2 Onderzoeksgebied functioneel.............................................................................................................. 37 4.2 KWALITATIEVE ASPECTEN VAN DE UITVOERING VAN HET SCENARIO........................................................................... 37 4.2.1 Leveranciersonafhankelijkheid ............................................................................................................ 38 4.2.2 Interoperabiliteit .................................................................................................................................. 39 4.2.3 Bedrijfscontinuïteit................................................................................................................................41 4.2.4 Shared Services concept (efficiency en schaalvoordelen).................................................................... 42 4.2.5 Politieke wensen....................................................................................................................................44 4.2.6 Digitale duurzaamheid..........................................................................................................................45 4.2.7 Imago Amsterdam-ICT Stad van Nederland ........................................................................................46 4.2.8 Aansprakelijkheid................................................................................................................................. 46 4.2.9 Intellectueel Eigendom..........................................................................................................................48 4.3 KWANTITATIEVE KOSTEN/BATEN VAN DE UITVOERING VAN HET VOORKEURSSCENARIO.................................................. 49
Versie 1.0 Extern
3/72
27 oktober 2006
4.3.1 Onderdelen van het TCO onderzoek.....................................................................................................50 4.3.2 Uitgangspunten en aannames bij de financiële analyse....................................................................... 51 4.4 CONCLUSIES KWANTITATIEVE KOSTEN EN BATEN.................................................................................................... 53 5 OUTLINE PROJECTVOORSTEL BOSS: VAN HUIDIGE NAAR BEOOGDE SITUATIE................ 55 5.1 AANBIEDER: SERVICEHUIS ICT.......................................................................................................................... 55 5.2 STARTLOCATIE: DIENST WONEN......................................................................................................................... 55 5.3 FINANCIERING VAN HET PROJECT......................................................................................................................... 56 5.4 AANPAK ......................................................................................................................................................... 57 5.4.1 Globale aanpak project BOSS.............................................................................................................. 57 5.5 BENODIGDE INITIËLE INVESTERING VOOR FASE A................................................................................................ 58 5.5.1 Niet meegenomen in de initiële kosten..................................................................................................59 5.5.2 Herinvestering van baten......................................................................................................................60 6 RISICO’S EN MAATREGELEN....................................................................................................... 61 6.1 RISICO’S INDIEN DE BUSINESS CASE NIET WORDT UITGEVOERD.................................................................................. 61 6.2 ALGEMENE KNELPUNTEN UITVOERING BUSINESS CASE............................................................................................. 61 6.3 RISICO’S BIJ UITVOERING VAN DE BUSINESS CASE................................................................................................... 61 6.3.1 Algemene risico’s..................................................................................................................................62 6.3.2 Risico’s tijdens de realisatie van het project........................................................................................ 62 6.3.3 Risico’s tijdens het beschikbaar stellen van werkplekken.................................................................... 63 6.4 HERZIENING ICT-AANBESTEDINGSMODEL IN RELATIE TOT HET SCENARIO...................................................................64 6.5 SOFTWARE INKOOPPROCEDURES IN RELATIE TOT HET SCENARIO.................................................................................64 6.6 LICENTIEBEHEER IN RELATIE TOT HET SCENARIO.....................................................................................................64 7 VOORLOPIG ADVIES INZAKE HET RAAMCONTRACT MET MICROSOFT................................ 65 BIJLAGE 1 VOLLEDIGE MATRIX EINDSITUATIES VS. CRITERIA................................................ 66 BIJLAGE 2 UITWERKING FINANCIËLE ONDERBOUWING........................................................... 67 NIET GESCHIKT VOOR EXTERNE PUBLICATIE................................................................................................................ 67 BIJLAGE 3 ACTIVITEITEN EN VOORLOPIGE PLANNING PROJECT BOSS................................ 68 BIJLAGE 4 SAMENSTELLING TOETSINGSCOMMISSIE............................................................... 69 BIJLAGE 5 STANDPUNT SERVICEHUIS ICT.................................................................................. 70 BIJLAGE 6 DEFINITIES EN BEGRIPPEN........................................................................................ 71
Versie 1.0 Extern
4/72
27 oktober 2006
0 Leeswijzer De business case is zodanig gestructureerd dat hij op drie niveaus is te lezen. De managementsamenvatting in het eerste hoofdstuk bevat alle kernelementen uit de business case zonder uitgebreide onderbouwing maar met de te nemen beslissingen. In de overige hoofdstukken zijn de doelstellingen, aanpak, het kiezen van het voorkeurscenario, de consequenties van de uitvoering van het scenario, projectvoorstel en de risico’s en maatregelen opgenomen. Gezien de omvang van het document is gekozen om een extra niveau toe te voegen. Bij bijna elke paragraaf zijn de kernpunten in een ‘blauw blok’ opgenomen. De lezer kan door het volgen van deze blauwe blokken bij elk onderwerp meteen de conclusies lezen zonder verdere onderbouwing. De onderbouwing van de punten in de blauwe blokken volgt direct daarna. Het lezen van deze blauwe blokken stelt u in staat snel tot de kern te komen van de gehele business case.
Versie 1.0 Extern
5/72
27 oktober 2006
1 Managementsamenvatting Voor u ligt de business case Open Softwarestrategie Gemeente Amsterdam, het antwoord op de stellingen die op 1 maart 2006 in de Gemeenteraad in een amendement zijn aangenomen van het toenmalige Raadslid Marres (PvdA)2 naar aanleiding van de evaluatie en afronding van de Open Source pilots en de verlenging van het raamcontract met Microsoft.
1.1 Aanleiding De Gemeenteraad is van mening dat een actieve en participerende opstelling richting Open Source ontwikkelingen past bij Amsterdam als “ICT stad van Nederland”. In het amendement wordt aan het College van B&W gevraagd een business case te presenteren voor de begroting van 2007, waarin beschreven wordt hoe om te gaan met het beëindigende contract met Microsoft voor kantoorautomatisering (per oktober 2008). Aan het College is gevraagd om bij alle diensten en stadsdelen een analyse te (laten) maken van de werkplekken, de functionaliteit en de af te spreken standaarden. Voorafgaand aan het amendement gaat de Motie Versterking kostenbesparingen op ICT-beheer en innovatie binnen het concern Gemeente Amsterdam (2002, nr. 848) die in de ogen van de Raad niet naar behoren is opgepakt. Ook belangrijk voor de achtergrond van voorliggend amendement is de Motie die bekend is geworden als de motie Burger Koning (2002, nr. 704). Deze motie beoogt de dienstverlening van de gemeente te verbeteren door één voorkant te creëren voor de burger: het stadsdeel. De uitvoering van deze motie vereiste onder meer reorganisatie van de gemeente, centralisatie en standaardisatie rond basisautomatisering (efficiencywinst) en decentralisatie van het contact met de burger (dicht bij de burger). Tevens dient het amendement bezien te worden tegen het licht van de landelijke ontwikkelingen rondom open standaarden en Open Source software. De Tweede Kamer heeft zich in 2002 uitgesproken voor de motie Vendrik waarin de regering werd gevraagd concentraties in de softwaremarkt tegen te gaan en ervoor te zorgen dat in 2006 alle door de publieke sector gebruikte software aan open standaarden voldoet. Kortweg, open standaarden moeten. Dit houdt in dat voor de Gemeente Amsterdam de keuze voor software gelimiteerd is tot software die gebaseerd is op open standaarden.
1.2 Doelstellingen Voorstel voor de strategische softwaredoelstellingen van de Gemeente Amsterdam: • Het verbeteren van de dienstverlening aan burgers en bedrijven, door verhoogde interoperabiliteit 3; • Het vergroten van de leveranciersonafhankelijkheid voor kantoorautomatisering; • Continuïteit van de bedrijfsvoering; • Kostenneutraliteit en realiseerbare investeringsbedragen.
Deze business case heeft als doel om, conform het amendement Marres, inzichtelijk te maken onder welke condities het mogelijk is om als Gemeente Amsterdam een leveranciersonafhankelijke keuze voor software te hebben bij het beëindigen van het huidige contract met Microsoft op 1 oktober 2008. De belangrijkste doelstellingen zijn, tot zover deze niet rechtstreeks uit het amendement zijn te herleiden, door het projectteam en het Wethouder ICT opgedaan tijdens een expertmeeting die op 20 juni jl. is georganiseerd voor Raadsleden van centrale stad en stadsdelen.
1.3 Open standaarden en open source software In deze business case zijn open standaarden en open source software slechts middelen om de strategische softwaredoelstellingen te realiseren. Daarbij, zo zal blijken, zijn open standaarden altijd nodig en open source software in bepaalde gevallen. 2
2006, nr. 171
3
De Wikipedia definitie: Interoperabiliteit laat de uitwisseling toe van gegevens en diensten tussen menselijke en technische, en gedeelde systemen. Technische interoperabiliteit is bedoeld om de technische problematiek veroorzaakt door de complexiteit die inherent is aan het verbinden van informatiesystemen en de services die deze informatie verstrekken, op te lossen. Deze interoperabiliteit bepaalt de normen inzake voorstelling, vergaring, uitwisseling, bewerking, beveiliging en transport
Versie 1.0 Extern
6/72
27 oktober 2006
Centraal staat de vraag wat er met de inzet van software wordt bereikt. Het gebruiken van software is immers niet een doel op zich. Zoals in deze business case wordt onderbouwd is het gebruik van open standaarden noodzakelijk om de doelstellingen: • het verbeteren van de dienstverlening aan burgers en bedrijven, door verhoogde interoperabiliteit; • Het vergroten van de leveranciersonafhankelijkheid voor kantoorautomatisering te realiseren. De eindsituatie die in deze business case wordt geopperd en getoetst gaat uit van het verplichte gebruik van open standaarden (overigens al staand beleid binnen de Gemeente). Open source software komt om de hoek kijken omdat: • sommige open standaarden niet worden ondersteund door closed source software; • Open source software qua aard minder snel leidt tot leverancierafhankelijkheid. Uitgaande van het verplichte gebruik van open standaarden is open source software soms dus een optie en soms een vereiste. De premisse in deze business case luidt: Wereldwijd zal de digitale werkplek van de toekomst (vanaf 2010) een open werkplek zijn, dat wil zeggen volledig op basis van open standaarden en grotendeels op basis van open source.
1.4 Omgeving Met de externe projectomgeving die gecreëerd is ten behoeve van deze business case, wordt voldaan aan een expliciet verzoek uit het amendement van Marres: ‘[Dat] Het college in voorkomende gevallen richting open source actief moet samenwerken met andere gemeentes, de Rijksoverheid en open source Strategie Platformen van de verschillende overheden en aangeboden advies uit het bedrijfsleven serieus te nemen en de raad daar 2 maal per jaar over te rapporteren.’
Bestuurlijk opdrachtgever voor de Business case is de Wethouder Ruimtelijke Ordening, Grondzaken, Waterbeheer en ICT, die deze opdracht geeft op verzoek van de Gemeenteraad. De Directie Concern Organisatie binnen de Bestuursdienst Gemeente Amsterdam is opdrachtnemer en tevens ambtelijk opdrachtgever. De business case is binnen de Directie Concern Organisatie opgesteld door de Afdeling Informatiebeleid, de ambtelijke opdrachtnemer. Het amendement heeft in elk geval betrekking op de Centrale Stad4. In het amendement worden ook de stadsdelen genoemd5. Het onderwerp van het amendement valt echter binnen de eigen bevoegdheid van de stadsdelen. De Wethouder ICT van de Centrale Stad heeft de voorzitters van de stadsdelen gevraagd om gezamenlijk deel te nemen aan dit project. Op het moment van schrijven hebben de stadsdelen geen gezamenlijk standpunt bepaald. Intergemeentelijk is een netwerk ontstaan rond open software strategieën op het initiatief van de Gemeente Amsterdam. Dit netwerk wordt ondersteund door het Bureau OSSOS van ICTU. In het netwerk bestaat naast Amsterdam thans uit de volgende gemeentes: • Almere • Assen • Den Haag • Eindhoven • Groningen • Haarlem • Nijmegen • Utrecht 4
zonder GVB 10334 fte / 10643 medewerkers (eind 2005)
5
6015 fte / 6093 medewerkers (eind 2005)
Versie 1.0 Extern
7/72
27 oktober 2006
1.5 Aanpak: Van softwarestrategie naar beoogde eindsituatie De eerste uitdaging bij de uitvoering van het amendement was het achterhalen van de achterliggende doelstellingen. Zonder te redeneren vanuit de strategische doelstellingen kan niet worden bepaald welke mix van open standaarden en open source software zinvol is in te zetten als strategie. Het projectteam kon (minimaal) zeventien technische eindsituaties bedenken, (op basis van alle mogelijke combinaties van gesloten of open, back-end of front-end en applicaties of besturingsysteem), die in zekere mate tegemoet komen aan het amendement. Op basis van de voorgestelde strategische doelstellingen is het mogelijk af te leiden welke eindsituatie en bijbehorend scenario verder moeten worden onderzocht. Deze eindsituatie laat zich typeren als ‘Alles zo veel mogelijk ‘open’ is in een aparte omgeving’ en heeft de volgende kenmerken: • Volledig op basis van open standaarden en waar nuttig of nodig op basis van open source software; • Een aparte ‘open’ (werkplek)omgeving, er wordt niet aan de huidige werkplekken gesleuteld. De problematiek die samenhangt met hybride omgevingen wordt zo vermeden; • Expansie (uitbreiding van het aantal werkplekken) via een instapmodel en niet door een (gedwongen) big bang; • Zowel back-end als front-end (en van achter naar voren ontwikkelen). De eindsituatie noemen we de Standaard Open Werkplek. Aanpalend dient het volgende te worden geregeld: • Een duidelijke kosten- en batenstructuur per functionaliteit; • Nieuwe selectie- en wegingcriteria voor software getoetst aan de strategische softwaredoelstellingen. Logische aanbieder voor de Standaard Open Werkplek is het Servicehuis ICT. Bovengenoemde zaken waren al op hoofdlijnen beschreven in het Plan van Aanpak dat op 11 oktober is besproken in de Raadscommissie ROW.
1.6 Toetsing van de beoogde eindsituatie Het model voor de Standaard Open Werkplek is in deze business case getoetst op de strategische softwaredoelstellingen. Hiervoor is in de business case de volgende analyse uitgevoerd: • inventarisatie en kwalificatie van de huidige situatie (werkplekken, functionaliteit, prijs etc.) • inventarisatie en kwalificatie van alternatieven (op aangeven van een drietal leveranciers) • vergelijkende data-analyse van de huidige situatie en de toekomstige situatie • inschatting kosten en inspanningen voor migratie.
Versie 1.0 Extern
8/72
27 oktober 2006
Toetsing beoogde eindsituatie op leveranciersonafhankelijkheid Voordelen Keuzevrijheid in softwareleveranciers door kennis en beschikbaarheid van alternatief Keuzevrijheid in softwareleveranciers door beschikbaarheid van software broncode Minder afhankelijkheid van leveranciersstandaarden Nadelen Migratie naar andere systemen kan nodig zijn De Gemeente dient een actieve en participerende houding dient te ontwikkelen ten opzichte van de software en standaarden waarop zij invloed wil hebben Neutraal Leveranciersafhankelijkheid kan verschuiven van pakketleverancier naar leverancier open werkplek, leveranciersonafhankelijkheid moet vooral worden afgedwongen door smart buyership
Toetsing beoogde eindsituatie op interoperabiliteit Voordelen Verhoogde interoperabiliteit bevorderd de interne en interbestuurlijke gegevensuitwisseling ten behoeve van verbeterde dienstverlening en handhaving Verhoogde interoperabiliteit bevorderd gegevensuitwisseling tussen de Gemeente en burgers en bedrijven Verhoogde interoperabiliteit bevorderd ketenintegratie en basisregistraties Aanbieden Standaard Open Werkplek via Shared Service Concept maakt controle op decentraal gebruik van open standaarden nog maar beperkt nodig Nadelen Actieve participatie van de Gemeente vereist voor het adapteren en mede-vaststellen van open standaarden Migratie naar andere systemen kan nodig zijn
Toetsing beoogde eindsituatie en migratiescenario op bedrijfscontinuïteit Voordelen Meer standaardisatie en Shared service concept (óók voor niet BRI-diensten) biedt de mogelijkheid tot meer stabiliteit Biedt de mogelijkheid beheer duurzaam in te richten los van release, update en supportbeleid van softwareleverancier Nadelen • Migratie naar de beoogde situatie vormt een grotere psychologische drempel dan een migratie naar nieuwe versies van MS Software Neutraal/Onbekend • Het valt niet aan te tonen dat de beoogde situatie stabieler/ minder stabiel, veiliger/minder veilig is dan de huidige situatie • Het valt niet aan te tonen dat een migratie naar de beoogde situatie een grotere bedreiging vormt voor de bedrijfscontinuïteit dan een migratie naar toekomstige versies van MS software
Versie 1.0 Extern
9/72
27 oktober 2006
Toetsing beoogde eindsituatie en migratiescenario op kostenneutraliteit en realiseerbare investeringsbedragen Voordelen • Zelfs in de meest conservatieve berekening worden de investeringen in de standaard open werkplek in 4 á 5 jaar terugverdiend • De standaard werkplek wordt aangeboden via het shared services concept waardoor de terugverdientijd nog kan worden verkort Nadelen • De terugverdientijd is gebaseerd op het behalen van voldoende volume. Het aantal gemigreerde standaard open werkplekken, dat nodig is om de initiële investering van €300.000 (zie paragraaf 1.9 beslispunt 3) terug te verdienen in 5 jaar, is 700.6 • Voor een volwaardig alternatief voor Microsoft dienen, bij een terugverdientijd van 5 jaar, 9500 werkplekken (waarvan 30% basis, 60% functioneel en 10% specialistisch) te worden gemigreerd.8 Neutraal • De berekening is gedaan op basis van de opgaaf van 3 leveranciers en moet in de praktijk op een aantal punten getoetst worden (zie 1.8) • Hoewel uitspraken gedaan kunnen worden over kostenneutraliteit zijn er te veel onbekenden om uitspraken te kunnen doen over het de financiële planning, hiervoor ontbreekt met name het totaaloverzicht over de softwarecontracten en het verloop van de volumegroei
1.7 Resultaat Het resultaat van deze business case is de uitvoering van het amendement Marres, uitgesplitst naar de volgende producten: •
Het onderbouwde voorstel voor om strategische software doelstellingen voor de Gemeente Amsterdam vast te stellen, te weten: verhoogde interoperabiliteit, verhoogde leveranciersonafhankelijkheid, continuïteit van de bedrijfsvoering, kostenneutraliteit en realiseerbare investeringsbedragen Het bewijs dat het mogelijk is om voor de Gemeente Amsterdam een software strategie uit te voeren die leidt tot een eindsituatie waarbij beter dan nu aan de voorgestelde strategische doelstellingen (waarbij de laatste twee randvoorwaardelijk zijn) wordt voldaan Het onderbouwde voorstel om te starten met het project (BOSS) dat moet gaan leiden tot de gefaseerde realisatie van de beoogde eindsituatie en waarbij in de eerste fase (A) een praktijktoets op de analyse in deze business case zal plaatsvinden, vooral op de volgende punten: • Feitelijke vaststelling van de voorspelde beheerskosten • Versmalling van de voorspelde bandbreedte voor migratiekosten • Vaststelling van het realiseerbare volume (in eerste instantie in een situatie op basis van vrijwilligheid) • Vaststelling van de financiële planning op basis bovengenoemde punten aangevuld met een inventarisatie van bestaande contractvoorwaarden • Juridische haalbaarheid Een voorlopig advies hoe per 1 oktober 2008 om te gaan met het dan beëindigend contract met Microsoft (zie 1.8) Een intergemeentelijk open standaarden en open source platform
De genoemde praktijktoets kan plaatsvinden in de vorm van een implementatie bij de Dienst Wonen.
1.8 Voorlopig advies raamcontract Microsoft De business case geeft zicht op een eindsituatie waarbij het niet opnieuw aanbesteden van een contract voor kantoorautomatisering onder dezelfde condities en voor dezelfde omvang (zowel qua werkplekken, als functionaliteit) een reële optie is. Er dient echter gebruik te worden gemaakt van de evaluatiemomenten die zijn ingebouwd in het voorgestelde project (BOSS) om hierover tot een nader oordeel te komen. Belangrijk is het besef dat de definitieve besluitvorming (voorjaar 2008) niet kan gaan over de vraag wel of geen Microsoft, maar over de vraag voor welke functionaliteit Microsoft producten als best uit de bus komen (op basis van pure functionaliteit en op basis van de strategische softwaredoelstellingen). 6
Indien er minder werkplekken beschikbaar komen om deze business case uit te voeren dan betekend het niet dat de business case niet haalbaar is, maar dat de termijn waarop er wordt terugverdiend langer wordt.
Versie 1.0 Extern
10/72
27 oktober 2006
Voor de onderdelen waarvoor Microsoft het best scoort kan vervolgens worden bepaald wat voor soort contract de grootste inkoopvoordelen voor de Gemeente oplevert en welk moment opportuun is om dit af te sluiten. Dit alles uiteraard in de vorm van openbare aanbesteding. Hoe dan ook zal uitvoering van het in deze business case voorgestelde scenario geen alles of niets keuze opleveren ten aanzien van het gebruik van Microsoft producten. Wel is zeker dat het niet uitvoeren van het scenario neerkomt op alles.
1.9 Beslispunten In deze business case is geen rekening gehouden met de (on)beschikbaarheid van middelen die nodig zijn voor de uitvoering van het projectvoorstel. In de bestuurlijke notities die deze business case begeleiden zal dat dit zijn geadresseerd. U wordt gevraagd: 1. In te stemmen met de volgende strategische softwaredoelstellingen van de Gemeente Amsterdam als uitgangspunt en toetsingscriteria voor deze businesscase: a. het bevorderen van de interoperabiliteit en duurzame opslag van gestructureerde en ongestructureerde informatie door middel van het gebruik van open standaarden voor ICT systemen; b. de vergroting van de leveranciersonafhankelijkheid; c. het behoud van de bedrijfscontinuïteit; d. het kostenneutraal plaatsvinden van de realisatie van de doelstellingen a t/m c op basis van realistische investeringsbedragen in verhouding met het totale budgettaire kader van de Gemeente. 2. In te stemmen met de conclusie uit de business case dat de beoogde eindsituatie en het bijbehorende scenario optimaal bijdragen aan genoemde strategische softwaredoelstellingen en uitzicht bieden op een leveranciersonafhankelijke keuze bij het al dan niet opnieuw aanbesteden van een raamcontract voor kantoorautomatiseringsoftware in 2008. 3. Opdracht te geven aan de bestuurlijk/ambtelijke Commissie Informatievoorziening voor de uitvoering van Fase A van het project BOSS en hiervoor een budget van € 300.000 beschikbaar te stellen. 4. In te stemmen met de aanwijzing van het Servicehuis ICT als aanbieder van de Standaard Open Werkplek en van de Dienst Wonen als ontwikkelomgeving én eerste afnemer van de Standaard Open Werkplek. 5. Opdracht te geven aan de bestuurlijk/ambtelijke Commissie Informatievoorziening te laten inventariseren of in het geval van een positieve praktijktoets op de business case, op vrijwillige basis voor diensten en stadsdelen voldoende volume gecreëerd kan worden om de ontwikkeling van het volwaardige alternatief, de standaard open werkplek, te financieren. 6. Opdracht te geven verplichtende maatregelen uit te werken en aan het College voor te leggen, wanneer ondanks een positieve praktijktoets,blijkt dat op vrijwillige basis onvoldoende volume wordt behaald. 7. De genomen besluiten en de business case voor te leggen aan de Gemeenteraad als antwoord op amendement nr. 171, 2006.
Versie 1.0 Extern
11/72
27 oktober 2006
2 Noodzaak & doelstellingen van de business case 2.1 Achtergrond Op 1 maart 2006 heeft de Gemeenteraad een amendement aangenomen van het toenmalige Raadslid Marres (PvdA) naar aanleiding van de evaluatie en afronding Open Source pilots en de verlening van het raamcontract met Microsoft. De belangrijkste onderliggende doelstellingen van het amendement zijn: • het verbeteren van de dienstverlening aan burgers en bedrijven, door verhoogde interoperabiliteit; • Het vergroten van de leveranciersonafhankelijkheid voor kantoorautomatisering. De belangrijkste voorwaarden bij het uitvoeren van het amendement zijn. • Continuïteit van de bedrijfsvoering; • Kostenneutraliteit en realiseerbare investeringsbedragen. Tezamen opperen we deze vier uitgangspunten als de Strategische Softwaredoelstellingen van de Gemeente Amsterdam.
Op 1 maart 2006 heeft de Gemeenteraad een amendement aangenomen van het toenmalige Raadslid Marres (PvdA)7 naar aanleiding van de evaluatie en afronding Open Source pilots. De Raad is van mening dat een actieve en participerende opstelling richting open source ontwikkelingen past bij Amsterdam als “ICT stad van Nederland”. In het amendement wordt het College van B&W gevraagd vóór de begroting 2007 met een business case te komen over hoe per 1 oktober 2008 om te gaan met het dan beëindigend contract met Microsoft voor kantoorautomatisering. Aan het College is gevraagd om bij alle diensten en stadsdelen een analyse te (laten) maken van de werkplekken, de functionaliteit en de af te spreken standaarden. Voorafgaand aan het amendement gaat de Motie Versterking kostenbesparingen op ICT-beheer en innovatie binnen het concern Gemeente Amsterdam (2002, nr. 848) die in de ogen van de Raad niet naar behoren is opgepakt. Ook belangrijk voor de achtergrond van voorliggend amendement is de Motie die bekend is geworden als de motie Burger Koning (2002, nr. 704). Deze motie beoogt de dienstverlening van de gemeente te verbeteren door één voorkant te creëren voor de burger: het stadsdeel. De uitvoering van deze motie vereiste onder meer reorganisatie van de gemeente, centralisatie en standaardisatie rond basisautomatisering (efficiencywinst) en decentralisatie van het contact met de burger (dicht bij de burger). Motie 848 zal formeel worden afgerond en de uitvoering van Motie Burger Koning zal verder versterkt worden door de uitvoering van huidig amendement. Gegeven deze achtergrond dient de aanpak bij de uitvoering van het amendement zich niet te richten op de keuze tussen Microsoft enerzijds en Open Source software anderzijds, maar op het migreren naar een situatie waarbij de Gemeente Amsterdam software kiest die haar het best in staat stelt de doelstellingen, met name op het gebied van dienstverlening aan de burger, te realiseren. Doelstellingen van het Amendement Marres Gezien de voorgeschiedenis van het amendement en overige ontwikkelingen binnen de Gemeente stelt het projectteam dat verantwoordelijk is voor voorliggend business case dat naast de leveranciers onafhankelijkheid de belangrijkste onderliggende doelstelling van het amendement gelegen is in het verbeteren van de dienstverlening aan burgers en bedrijven, door verhoogde interoperabiliteit. Dit beeld is nog eens bevestigd tijdens een expertmeeting die op 20 juni jl. is georganiseerd voor Raadsleden van centrale stad en stadsdelen. Uit de expertmeeting kwam een tweetal additionele strategische randvoorwaarden naar voren voor de uitvoering van het amendement: • De continuïteit van de bedrijfsvoering van de Gemeente mag niet in gevaar komen gedurende en na een migratie naar de gewenste situatie; • Het geheel van materiële en immateriële baten moet opwegen tegen het geheel van materiële en immateriële kosten. Ook moet een eventueel negatief verschil tussen de materiële baten en lasten van aanvaardbare omvang zijn (= het mag niet teveel kosten);
7
2006, nr. 171
Versie 1.0 Extern
12/72
27 oktober 2006
Goed beschouwd gaat het dus om twee strategische doelstellingen, aangevuld met twee strategische randvoorwaarden. Verderop in dit hoofdstuk (2.6.4) worden echter ook een aantal, meer operationele, randvoorwaarden voor succes beschreven. Om verwarring te voorkomen worden de strategische doelstellingen en randvoorwaarden in de businesscase alle vier gezamenlijk omschreven als de Strategische Softwaredoelstellingen van de Gemeente Amsterdam.
2.2 Open standaarden en open source software In deze business case zijn open standaarden en open source software slechts middelen om de strategische softwaredoelstellingen te realiseren. Daarbij, zo zal blijken, zijn open standaarden altijd nodig en open source software in bepaalde gevallen.
In deze business case zijn open standaarden en open source software slechts middelen om de strategische softwaredoelstellingen te realiseren. De titel van de Business Case: ‘Open Software Strategie Amsterdam duidt dus op een strategie die gebruik maakt van open standaarden en open source software en niet op een strategie die géricht is op open standaarden of open source software. Een strategie moet gericht zijn op een (of meerdere) doel(en) en niet op de middelen die er voor worden ingezet. Het onderscheid tussen open standaarden en open source software is in bijlage 6 uiteengezet en is van belang om twee redenen: 1. Te bepalen in welke mate open standaarden respectievelijk open source bij kunnen dragen aan de strategische software doelstellingen. 2. Te bepalen welke nadelen er kleven aan het gebruik van open standaarden respectievelijk het gebruik van open source software. Ad 1. Zoals in deze business case wordt onderbouwd is het gebruik van open standaarden noodzakelijk om de doelstellingen: • het verbeteren van de dienstverlening aan burgers en bedrijven, door verhoogde interoperabiliteit; • Het vergroten van de leveranciersonafhankelijkheid voor kantoorautomatisering te realiseren. De eindsituatie die in deze business case wordt geopperd en getoetst gaat uit van het verplichte gebruik van open standaarden (overigens al staand beleid binnen de Gemeente). Open source software komt om de hoek kijken omdat: • Sommige open standaarden niet worden ondersteund door closed software; • Open source software qua aard minder snel leidt tot leverancierafhankelijkheid. Uitgaande van het verplichte gebruik van open standaarden is open source software soms dus een optie en soms een vereiste. Ad 2. Het gebruik van open standaarden heeft geen nadelen. Over de nadelen van open source software ten opzichte van closed software vallen geen eenvoudige uitspraken te doen. De relevante voor- en nadelen worden uitgebreid behandeld in hoofdstuk vier.
Versie 1.0 Extern
13/72
27 oktober 2006
2.3 Landelijke en internationale ontwikkelingen Het amendement dient ook bezien te worden tegen het licht van de landelijke en internationale ontwikkelingen rondom open standaarden en open source software. De Tweede Kamer heeft zich in 2002 unaniem uitgesproken voor de motie Vendrik waarin de regering werd gevraagd concentraties in de softwaremarkt tegen te gaan en ervoor te zorgen dat in 2006 alle door de publieke sector gebruikte software aan open standaarden voldoet. Kortweg, open standaarden moeten. Dit houdt in dat voor de Gemeente Amsterdam de keuze voor software gelimiteerd is tot software die gebaseerd is op open standaarden.
De tekst van de Motie Vendrik
Op het gebied van Open source software was de motie terughoudender, maar verzocht wel de publieke sector een actieve rol te spelen in het verspreiden en ontwikkelen van software waarvan de bron beschikbaar was. Dat de voornemens van de Tweede Kamer nu, in 2006, nog niet zijn gehaald, is duidelijk. Voor veel organisaties is het niet eenvoudig over te stappen naar open standaarden omdat de standaarden die gebruikt worden dikwijls gekoppeld zijn aan de software die wordt gebruikt (denk alleen al aan MS Word en de .doc .xls en .ppt formaten). Vele overheden (en bedrijven) zijn daarom opzoek naar software die de invoering van open standaarden beter ondersteunt dan de software die thans de facto standaard is. Deze software mag qua broncode open of gesloten zijn. De zoektocht naar alternatieven is echter niet eenvoudig. Niet om dat ze er niet zijn, maar om dat het implementeren hiervan in de organisatie stuit op feitelijke én vermeende obstakels. Dat de obstakels om te migreren wellicht meer zeggen over de huidige vendor lock-in waarin veel organisaties zich bevinden dan aan tekortkomingen van alternatieven maakt de obstakels niet minder groot. Deze business case is niet in splendid isolation tot stand gekomen. Er is veel gesproken met experts uit de ICT-markt en met collega-gemeenten. Wie alleen al de persberichten van de afgelopen maand volgt leert de noodzaak van open standaarden vrijwel onomstreden is:
Versie 1.0 Extern
14/72
27 oktober 2006
Persvoorlichting Belgische Overheid, 2006-06-23 Belgische Overheid kiest voor Open standaarden Gebruik open standaarden voor de uitwisseling van kantoordocumenten De Ministerraad heeft de nota voor het gebruik van open standaarden voor de aanmaak en uitwisseling van kantoordocumenten goedgekeurd. Minister Vanvelthoven: "De aanmaak en uitwisseling van kantoordocumenten zoals tekstdocumenten en spreadsheets is vandaag gebaseerd op verschillende populaire kantoorsuites zoals Microsoft Office, Corel WordPerfect Office,OpenOffice... Tot voor kort was het niet gemakkelijk voor de gebruikers van één van deze soorten van software om documenten uit te wisselen met gebruikers van andere software. Maar er is een belangrijk werk van normalisatie verricht de laatste jaren. Dit heeft geleid tot het definiëren van een nieuwe standaard. XML is een erkende standaard voor het definiëren, uitwisselen en interpreteren van informatie. ODF (Open Document Format) is een XML formaat voor kantoorsuites voor het creëren en opslaan van documenten. Het is een openstandaard die goed op weg is om goedgekeurd te worden door ISO (International Standard Organisation).
Webwereld, donderdag 6 juli 2006 Microsoft integreert ODF-ondersteuning in Office Microsoft heeft woensdag het Open XML Translator-project aangekondigd, waarmee de Officetoepassingen ondersteuning gaan bieden voor het ODF-formaat. De beslissing is ingegeven door verzoeken van overheden die graag willen dat Microsoft-producten ODF ondersteunen, zoals de Belgische en Deense nationale overheid en de autoriteiten van de Amerikaanse staat Massachusetts. Microsoft meldt dat Office 2007, dat begin volgend jaar verwacht wordt, menuopties zal bevatten voor XML, ODF en Adobe's PDF-formaat. De ODF-ondersteuning is aanwezig in Word, Excel en Powerpoint, de meest gebruikte Office-applicaties. Het aantal meldingen van successen, mislukkingen en grootse plannen met open source ontloopt elkaar niet veel: News forges August 22, 2006 Croatian government adopts open source software policy Last month the Croatian government adopted an open source software policy and issued guidelines for developing and using open source software in the government institutions. The Croatian government is concerned that proprietary software leads to too much dependence on the software suppliers. Open source software will make the government's work more transparent, according to the government's document, entitled "Open Source Software Policy."
Computerworld Norse (Norway) 05/09/2006 2nd largest Norwegian city puts Linux plan on hold Two years ago the City of Bergen in Norway caught the attention of the IT world when it decided to go for a fully-fledged Linux strategy, with plans to install Suse Linux on all of the client PCs the city
Versie 1.0 Extern
15/72
27 oktober 2006
provides for. Fifteen thousand civil servants and 36,000 teachers and students were to switch from Microsoft Windows to open-source software. Although the city will continue to run Linux on its servers, the plan to migrate the clients has now been put on hold. Director of Competition and development Lars Tveit said the City of Bergen will only use Linux where it makes sense. "An exaggerated belief in Linux can make you lose your focus and might harm other important tasks," he said. Microsoft Corp. products will continue to live a healthy life within the city boundaries. "We use Microsoft and we have no plans to throw it out. It will be too costly to train all our users in a new system" Tveit said.
ZDNet, 26 september 2006 München stapt eindelijk over op Linux Eerste migraties van de 14.000 pc's een feit Het gemeentebestuur van de Duitse stad München is eindelijk begonnen met de overstap naar Linux. Dat is een jaar later dan gepland. In totaal gaat het om zo'n 14.000 pc's. De gemeente zei in 2003 al te willen migreren van Windows naar Linux. Volgens de planning zouden in 2005 de eerste pc's onder Linux moeten draaien. Het project, genaamd LiMux, liep echter diverse vertragingen op. Zo waren er twijfels of de openbronsoftware niet bepaalde softwarepatenten zou schenden. Ook duurden de contractuele onderhandelingen over de implementatie langer dan verwacht en moest de testfase met twaalf maanden worden verlengd.
Telegraaf, woensdag 30 augustus 2006 Den Haag overweegt overstap op OpenOffice.org De gemeente Den Haag start een onderzoek naar de mogelijkheden om te werken met de kantoorsoftware OpenOffice.org. Dat antwoordt burgemeester Wim Deetman op vragen van drie raadsleden. De gemeente heeft het contract met Microsoft voor Office-software, toen het in februari van dit jaar afliep, niet verlengd. Reden hiervoor is dat volgend jaar de Office 2007 verschijnt en Microsoft nog twee jaar na die introductie updates uitbrengt voor Office 2003, waar de gemeente op dit moment mee werkt. De gemeente zal daarom in 2008 of 2009 een nieuw contract afsluiten voor kantoorsoftware op de 4941 werkplekken binnen de gemeente. Het gebruik van Microsoft Office kostte de gemeente 314 euro per werkplek. De gemeente hoopt met de overstap naar open-sourcesoftware kosten te besparen. De burgemeester laat weten dat een overstap op Linux niet gewenst is. "Ook is een overgang naar een volledig op OSOSS (programma Open Standaarden en Open Source Software voor de overheid) gebaseerde werkplek op korte en middenlange termijn niet haalbaar."
Webwereld donderdag 20 juli 2006 Gemeente Groningen stapt over op Openoffice.org De gemeente Groningen is woensdag akkoord gegaan met een voorstel om over te stappen van Microsoft Office op het gratis Openoffice-pakket.
Versie 1.0 Extern
16/72
27 oktober 2006
Door het lopende contract met Microsoft voor het gebruik van Office niet te verlengen, bespaart de gemeente 330.000 euro per jaar. Dit is gebaseerd op een licentie voor de 3650 pc's, die de gemeente drie jaar geleden bij het afsluiten van het contract gebruikte. Groningen wil geleidelijk overstappen op open-sourcesoftware. Het contract met Microsoft voor het gebruik van Windows zal wel verlengd worden, omdat een overstap naar Linux volgens de raad 'nog niet opportuun is'. Feit is dat vrijwel alle informatie intensieve organisatie bezig zijn met het vraagstuk en dat zeker in dat een tendens richting Open Source duidelijk zichtbaar is: 28 juni 2006 | door Redactie Computable Open Source lijkt aan de winnende hand Nederlandse organisaties maken steeds vaker gebruik van Open Source (os). Dit staat haaks op de situatie in Amerika waar het gebrek aan zakelijkheid van os-programmeurs de acceptatie nog altijd in de weg staat. Steeds meer Nederlandse organisaties maken gebruik van open source software. Volgens Jan Willem Broekema van Ossos, de organisatie die open source en open standaarden bij de overheid stimuleert, is het gebruik bij overheden de afgelopen jaren 'met tientallen procenten toegenomen'. "En vaker dan overheden zelf denken. Dan melden ze: 'We doen niets aan open source.' Dan blijken er toch servers op Apache of Linux te draaien." Broekema verwacht ook dat particulieren en het MKB de komende jaren steeds vaker over zullen stappen op OpenOffice.org als gevolg van de toegenomen jacht op illegale software.
Forrester, September 11, 2006 Open Source Becoming Mission-Critical In North America and Europe Although fewer than half of the large enterprises in Europe and North America are actively using or piloting open source software, a majority of those are using it for mission-critical applications and infrastructure. While overall use is higher in Europe, North American companies are more likely to have embraced open source for mission-critical use. Media and entertainment and utilities and telecommunications lead other sectors in open source use in both geographies. Sceptics remain in most sectors, but application development professionals should view these results as an indication that companies are finding open source suitable for certain types of critical business applications. Bron: Forrester Open Office Use in Public Sector, Bron: Wikipedia Country
Customer/User
Industry/Vertical
Number of Seats
Status
Links to Public Information
US/Global
Sun Microsystems
IT
> 30,000
Completed
Singapore
Ministry of Defense
Government
5,000
Completed [1]
UK
Bristol City Council
Government
5,000
Completed [2]
France
Gendarmerie Nationale
Government
70,000
Started
[3]
France
Tax Agency
Government
80,000
Started
[4]
France
Ministry of Equipment
Government
55,000
Started
[5]
France
Ministry of Interior
Government
50,000
Started
Adullact
Versie 1.0 Extern
17/72
27 oktober 2006
France
Ministry of Finance
Government
8,000
Done
France
French Customs
Government
16,000
Started
Spain / Extremadura
Education, Health Service, Public Libraries and Public Governement, Administration of Education Extremadura
70,000
Started
Spain / Andalucía
Education, Guadalinfo Centers, Public Libraries
Governement, Education
255,000
Started
Spain / Catalunya
Public Schools
Education
60,000
Started
Denmark
HK Handel
Trade Union
1,200
Planned
[6]
Netherlands
City of Haarlem
Government
2,000
Started
[7]
Netherlands
City of Vaals
Government
90
Started
[8]
Belgium
Department of Justice
Government
4,000
Started
[9] [10]
Germany
City of Munich
Government
15,000
Planned
[11]
Germany
Stuttgarter Versicherung
Finance
900
Completed [12]
Germany
LVM
Finance
7,700
Completed [13]
Austria
City of Vienna
Government
18,000
Started
[14]
Brazil
Banco do Brasil
Finance
35,000
Started
[15] [16] [17]
Republic of Macedonia
Ministry of Finance
Government
> 150
Completed
Adullact
16 August 2006, Computable Open source heads for global domination Most important software trend in decades, says IDC. The open source software phenomenon has spread far beyond Linux and is gaining "enormous momentum", according to a report from IDC. A new study from the analyst firm claimed that developers worldwide are rapidly increasing their use of open source software. Analysis of surveys from over 5,000 developers in 116 countries found that open source software represents the "most significant all-encompassing and long-term trend that the software industry has seen since the early 1980s". IDC believes that open source will eventually play a role in the life-cycle of every major software category, and will fundamentally change the value proposition of packaged software for customers. De opstellers van deze business case durven op basis bovenstaande en soortgelijke berichten als mede op basis van hun eigen waarnemen de volgende stelling aan: Wereldwijd zal de digitale werkplek van de toekomst (vanaf 2010) een open werkplek zijn, dat wil zeggen volledig op basis van open standaarden en grotendeels op basis van Open Source.
De open werkplek zal er komen, het is alleen de vraag hoe en wanneer de Gemeente Amsterdam migreert.
Versie 1.0 Extern
18/72
27 oktober 2006
2.4 Doelstelling van de business case Deze business case heeft als doel om, conform het amendement Marres, inzichtelijk te maken onder welke condities het mogelijk is om als Gemeente Amsterdam een leveranciersonafhankelijke keuze voor software voor kantoorautomatisering te hebben bij het beëindigen van het huidige contract met Microsoft op 1 oktober 2008. Daarbij dient tevens te worden voldaan aan de drie overige strategische softwaredoelstellingen.
Onderhavige business case is een uitwerking van het ‘Plan van Aanpak ten behoeve van de business case ‘Open Softwarestrategie Amsterdam’’ versie 1.0 die op 11 oktober jl. in de Raadscommissie ROW is besproken. In het plan van aanpak wordt beschreven op welke wijze getracht wordt de benodigde maatregelen en consequenties van een leveranciersonafhankelijke keuze voor te bereiden en welke randvoorwaarden er verbonden zijn aan de keuze voor mogelijke alternatieven. Hiertoe is een vooronderzoek uitgevoerd dat heeft geleid tot een aanpak die via het vaststellen van strategische softwaredoelstellingen leidt tot het maken van een weloverwogen keuze voor een leveranciersonafhankelijk scenario (zie ook het volgende hoofdstuk 3). Doelstelling Business Case Deze business case heeft als doel om, conform het amendement Marres, inzichtelijk te maken onder welke condities het mogelijk is om als Gemeente Amsterdam een leveranciersonafhankelijke keuze voor software te hebben bij het beëindigen van het huidige contract met Microsoft op 1 oktober 2008. Daarbij dient tevens te worden voldaan aan de drie overige strategische softwaredoelstellingen. In de business case wordt aangetoond dat de strategische softwaredoelstellingen behaald kunnen worden door een breder gebruik van open standaarden en/of Open Source software, al dan niet in combinatie met closed source software. Het gaat daarbij in eerste instantie uitsluitend om software ten behoeve van de kantoorautomatisering. De afgeleide doelstelling van de business case is daarom een concrete kwalitatieve en kwantitatieve onderbouwing op te leveren voor een eindsituatie (en scenario) waarbij (een deel van) de Gemeente Amsterdam gebruik maakt van wat we de open standaard werkplek.
2.5 Projectopdracht De opdrachtinterpretatie van de opdrachtnemer is het onderzoeken van de haalbaarheid en wenselijkheid (in kwalitatieve en kwantitatieve zin) in een business case, van een scenario dat leidt tot een leveranciersonafhankelijke keuze voor software ten behoeve van de kantoorautomatisering. De volgende onderdelen dienen in deze business case gerealiseerd te worden: • Het onderbouwen van een scenario dat de input levert voor de beslissing in 2008 over het opnieuw aanbesteden van een raamcontract voor de kantoorautomatisering (de huidige enterprise agreement met Microsoft); • Het onderzoeken van de haalbaarheid van één of meer alternatieven voor de functionaliteit die thans wordt geleverd door Microsoft. Het (laten) vastleggen van de randvoorwaarden die gelden bij een dergelijke keuze: • Strategische softwaredoelstellingen van de Gemeente Amsterdam; • Voorwaarden bij inkoop van ICT faciliteiten; • De beperkingen voortkomende uit de bestaande ICT infrastructuur; • De beschikbare middelen. Het creëren van voldoende kennis en draagvlak binnen de gemeente: • Ambtelijk opdat de verantwoordelijke ambtenaren de voorstellen kritisch kunnen toetsen; • Bestuurlijk opdat bij de bestuurders helder is waarvoor zij kiezen.
Versie 1.0 Extern
19/72
27 oktober 2006
2.6 Afbakening van de business case 2.6.1
Projectomgeving
Met de externe projectomgeving die gecreëerd is naar aanleiding van deze business case wordt voldaan aan een expliciet verzoek uit het amendement van Marres: ‘[Dat] Het college in voorkomende gevallen richting Open Source actief moet samenwerken met andere gemeentes, de rijksoverheid en Open Source Strategie Platformen van de verschillende overheden en aangeboden advies uit het bedrijfsleven serieus te nemen en de raad daar 2 maal per jaar over te rapporteren.’
Bestuurlijk opdrachtgever voor de Business case is de Wethouder Ruimtelijke Ordening, Grondzaken, Waterbeheer en ICT, die deze opdracht geeft op verzoek van de Gemeenteraad. De Directie Concern Organisatie binnen de Bestuursdienst Gemeente Amsterdam is opdrachtnemer en tevens ambtelijk opdrachtgever. De business case is binnen de Directie Concern Organisatie opgesteld door de Afdeling Informatiebeleid, de ambtelijke opdrachtnemer. De Gemeentelijke Stuurgroep en Commissie Informatievoorziening leveren een advies bij deze business case. Een toetsingscommissie is samengesteld uit interne en externe deskundigen om vanuit de verschillende invalshoeken een (gezamenlijk) advies op te stellen over de business case (samenstelling in bijlage 4). Een kennisgroep is ontstaan uit het Platform-ICT met als doel kennis en ervaringen over Open Source en open standaarden uit te wisselen. Intergemeentelijk is een netwerk ontstaan rond open software strategieën op het initiatief van de Gemeente Amsterdam. Dit netwerk wordt ondersteund door het Bureau OSSOS van ICTU. In het netwerk bestaat naast Amsterdam thans uit de volgende gemeentes: • Almere • Assen • Den Haag • Eindhoven • Groningen • Haarlem • Nijmegen • Utrecht Met de externe projectomgeving die gecreëerd is naar aanleiding van deze business case, wordt voldaan aan een expliciet verzoek uit het amendement van Marres: ‘[Dat] Het college in voorkomende gevallen richting Open Source actief moet samenwerken met andere gemeentes, de Rijksoverheid en Open Source Strategie Platformen van de verschillende overheden en aangeboden advies uit het bedrijfsleven serieus te nemen en de raad daar 2 maal per jaar hierover te rapporteren.’
2.6.2
Tijdsbestek en mijlpalen
Hoewel het totale project (het vooronderzoek, plan van aanpak, het opstellen van de business case en het daaropvolgende project BOSS) zich uitstrekt over een langere periode zijn er een aantal mijlpalen aan te geven: • Juni 2006 – Voorgenomen aanpak besproken in de Commissie.ROW. • Juni 2006 - Expertmeeting voor Raadsleden. • September 2006 – 2x bespreking business case (versie 0.3 en 0.7) in de Toetsingscommissie (samenstelling in bijlage 4). • Oktober 2006 – Bespreking Plan van Aanpak (met daarin voorschot op strategische software doelstellingen en mogelijke eindsituatie) in de Commissie ROW. • Oktober 2006 – Advisering Stuurgroep Informatievoorziening en bestuurlijk/ambtelijke Commissie Informatievoorziening (dit is geen raadscommissie) over de businesscase. • November 2006 – Besluitvorming College van B&W
Versie 1.0 Extern
20/72
27 oktober 2006
• • •
November 2006 – Besluitvorming over de businesscase in de Commissie ROW en de Gemeenteraad. Januari 2007 tot december 2007 – Voorbereiden leveranciersonafhankelijke keuze op basis van een getoetste business case. Medio 2008 – Keuze over het al dan niet opnieuw aanbesteden van een raamcontract voor kantoorautomatiseringsoftware (huidige Enterprise Agreement Microsoft).
De verwachting is dat voorliggende business case op 29 november 2006 in Gemeenteraad wordt besproken.
2.6.3
Werkgebied
Onder het werkgebied wordt verstaan het gebied waarvoor het amendement en dus de business case consequenties kunnen hebben. Het moet niet verward worden met het onderzoeksgebied (paragraaf 4.1) waarmee geduid wordt op het gebied dat in het onderzoek ten behoeve van de business case betrokken is (als populatie).
2.6.3.1 Werkgebied organiek: Het werkgebied bevat in elk geval de Centrale Stad8. In het amendement worden ook de stadsdelen genoemd9. Het onderwerp van het amendement valt echter binnen de eigen bevoegdheid van de Stadsdelen. De Wethouder ICT van de Centrale Stad heeft de voorzitters van de stadsdelen gevraagd om gezamenlijk mee te doen met de uitvoering van het amendement. Op het moment van schrijven hebben de stadsdelen nog geen gezamenlijk standpunt bepaald.
2.6.3.2 Werkgebied functioneel: Het betreft de vraag welk type software bij de uitvoering van het amendement wordt betrokken. Het amendement spitst zich vooral toe op Microsoft. Indien echter gedacht wordt vanuit de strategische softwaredoelstellingen van de Gemeente Amsterdam is een focus op uitsluitend software die thans door Microsoft wordt geleverd niet logisch (zie ook paragraaf 4.2.3) . Ex ante is daarom bij de uitvoering van het amendement geen beperking gemaakt voor het type software. De aanpak van de business case leidt niet zo zeer tot een afbakening als wel tot een logisch startpunt voor wat betreft het type software waar bij de uitvoering van het amendement van wordt uitgegaan: we moeten ergens beginnen. Dit startpunt is de ICT die nodig is om een volledige werkplek aan de gebruiker aan te bieden. Hiermee wordt bedoeld: 1)
2)
3) 4) 5)
De front-end van de werkplekken - hardware (desktop en laptop) en de software (het besturingssysteem,) generieke kantoorapplicaties (zoals e-mail, agenda, tekstverwerken, rekenen, presenteren en beveiligen etc.). De back-end – hardware (servers die nodig zijn om alle functionaliteit aan te bieden) en de software die benodigd is voor het managen van netwerken, domeinen, file- en print, role based applicatie management, beveiliging etc. Op het gebied van beheer wordt zowel het technisch als functioneel beheer en de managementkosten in kaart gebracht. Specifieke softwaretoepassingen zoals bedrijfsvoeringapplicaties worden buiten beschouwing gelaten, alleen het realiseren van toegang tot deze applicaties is inbegrepen. Randapparatuur zoals printers, faxen en pda’s worden buiten beschouwing gelaten. Daar waar de gebruikte applicaties voorwaarden stellen aan de werkplek of het netwerk infrastructuur zullen deze kosten meegenomen worden.
2.6.4
Randvoorwaarden
Voor het slagen van de uitvoering van deze business case zijn de volgende randvoorwaarden van belang: 8
zonder GVB 10334 fte / 10643 medewerkers (eind 2005)
9
6015 fte / 6093 medewerkers (eind 2005)
Versie 1.0 Extern
21/72
27 oktober 2006
2.6.4.1 Randvoorwaarde 1 ‘De Gemeente Amsterdam maakt voor haar ICT diensten gebruik van open standaarden’.
Open standaarden zijn ICT-standaarden ten behoeve van de interoperabiliteit van informatiesystemen (ofwel het vermogen tot het doen van gegevensuitwisseling tussen ICT-systemen). Onder een 'open standaard' verstaan we een standaard die voldoet aan de volgende eisen: 1. De standaard is goedgekeurd en zal worden gehandhaafd door een not-for-profit organisatie, en de lopende ontwikkeling gebeurt op basis van een open besluitvormingsprocedure die toegankelijk is voor alle belanghebbende partijen (consensus of meerderheidsbeschikking enz.); 2. De standaard is gepubliceerd en over het specificatie document van de standaard kan vrijelijk worden beschikt of het is te verkrijgen tegen een nominale bijdrage. Het moet voor een ieder mogelijk zijn om het te kopiëren, beschikbaar te stellen en te gebruiken om niet of tegen een nominale prijs; 3. Het intellectuele eigendom - m.b.t. mogelijk aanwezige patenten - van (delen van) de standaard is onherroepelijk ter beschikking gesteld op een royalty-free basis; 4. Er zijn geen beperkingen betreffende het hergebruik van de standaard.10 Risico als er niet in de randvoorwaarde wordt voorzien: Eerder is in dit kader al verwezen naar de Motie Vendrik. Deze randvoorwaarde staat al als grondslag genoemd in het concepthandboek Architectuur dat zich thans in de consultatiefase bevindt. Het projectteam durft te stellen dat het zwaarder inzetten op open standaarden tot weinig controverse leidt. Echter, zonder deze intentie kan het amendement van Marres niet uitgevoerd worden. Maatregelen om risico’s te reduceren: Dit betekent dat, in de business case, software die veel gebruik maakt van open standaarden de voorkeur heeft boven software waarbij dat minder het geval is. Het praktiseren van dit uitgangspunt zou kunnen zijn dat naar mogelijk druk op leveranciers (van software of hosting) wordt uitgeoefend om meer open standaarden toe te passen.
2.6.4.2 Randvoorwaarde 2 ‘De business case mag uitgaan van keuzes die buiten de reeds gedefinieerde ICT standaards binnen de Gemeente Amsterdam vallen mits wordt voldaan aan de randvoorwaarden en doelstellingen uit de ICT-standaardisatienota’.
De Gemeente Amsterdam heeft in 2004 een tiental punten gedefinieerd op basis waarvan ICTstandaardisatie plaatsvindt. Hierin worden een aantal softwarepakketten genoemd dat als standaard geldt voor de hele Gemeente. Ook wordt er gesteld dat “Voor zover niet elders al expliciet (beperkend) geregeld, voor elke ICT-oplossing dat deze tot “de standaard” behoort, indien deze in 5 of meer gemeentelijke organisaties in gebruik is.”11 Deze standaarden zullen binnenkort, samen met een veelheid andere (de facto) standaarden worden ondergebracht in het nog vast te stellen Handboek Architectuur. Risico als er niet in de randvoorwaarde wordt voorzien: Als niet buiten de al gedefinieerde ICTstandaarden kan worden gezocht naar alternatieven is het niet mogelijk een business case op te stellen voor een leveranciersonafhankelijke keuze voor software. Maatregelen om risico’s te reduceren: Bij de uitvoering van de business kan mogen nieuwe standaarden worden geïntroduceerd. Hierbij blijven de doelstellingen en randvoorwaarden op basis waarvan de ICT-standaardisatienota is opgesteld onverminderd van kracht, namelijk:
10
http://www.ososs.nl/index.jsp?alias=watisos
11
ICT-standaardisatienota (oktober 2004)
Versie 1.0 Extern
22/72
27 oktober 2006
De randvoorwaarden waarbinnen de ICT-standaards nageleefd moeten worden, zijn: • de decentrale verantwoordelijkheden blijven intact;
• •
desinvesteringen moeten vermeden worden; de omgekeerde bewijslast geldt: gemeentelijke organisaties mogen afwijken van een aangewezen standaard, mits zij dit plausibel motiveren.
Doelstellingen ICT-standaards dienen bij te dragen aan één of meerdere van navolgende doelen: • het kunnen bereiken van inkoopvoordelen;
• • •
het verbeteren van de mogelijkheden tot onderlinge gegevensuitwisseling; het onderling kunnen delen van kennis en capaciteit; het oplossen van knelpunten en belemmeringen voor de onderlinge samenwerking. 12
De open standaarden die bij de mogelijke uitvoering van deze business case zullen worden voorgesteld zullen gemeentelijk moeten worden vastgesteld. Hoewel er nog geen procedure is vastgesteld voor het vaststellen van standaarden ligt het voor de hand dat de Adviesgroep Architectuur hierbij een centrale rol gaat vervullen.
2.6.4.3 Randvoorwaarde 3 ‘De Gemeente Amsterdam kiest voor software op basis van vooraf vastgestelde strategische doelstellingen (criteria)’.
Het beeld dat in de loop der jaren is ontstaan over open source, vooral in discussies op het internet is dat er een strijd gaande is tussen twee kampen. Het ene kamp is tegen en het andere kamp is vóór open source. Open source software is software met twee kenmerken: 1. De broncode van de software is vrij beschikbaar. 2. In het licentiemodel is het intellectueel eigendom en het (her)gebruik van de software en bijbehorende broncode dusdanig geregeld dat de licentienemer de broncode mag inzien, gebruiken, verbeteren, aanvullen en distribueren.13 Risico als er niet in de randvoorwaarde wordt voorzien: Als niet aan deze randvoorwaarde wordt voldaan is het risico dat de Gemeente Amsterdam zich laat afleiden door zinloze discussies en dat keuzes gebaseerd worden op vooroordelen (zoals ‘alle open source software is onbetrouwbaar en onbeheersbaar) of sentiment (zoals: ‘Microsoft deugt niet’). Maatregelen om risico’s te reduceren: Voorgesteld wordt dat de gemeente bewust kiest voor software op basis van haar eigen criteria en de gezamenlijke belangen van de Nederlandse Overheid (zie ook uitgangspunt 1). Hiervoor dient de Gemeente zich te baseren op de objectief te bepalen eigenschappen van software. Open Source en closed source software hebben globaal gezien verschillende eigenschappen, maar binnen beiden type software bestaan pakketten met een goede en een slechte prijs-kwaliteitverhouding en bestaan er goede en slechte leveranciers.
2.6.4.4 Randvoorwaarde 4 ‘De kosten en baten (materieel of immaterieel) van een operatie voortvloeiend uit deze business case worden eerlijk verdeeld over de deelnemende diensten en stadsdelen en de centrale kas (= de belasting betaler)’.
In de eindsituatie die deze business case wordt onderzocht en die, zoals als verderop in deze business case zal blijken, zowel materiele als immateriële netto baten zal opleveren zullen de baten 12
ICT-standaardisatienota (oktober 2004)
13
http://www.ososs.nl/index.jsp?alias=watisoss
Versie 1.0 Extern
23/72
27 oktober 2006
en de kosten eerlijk verdeeld moeten worden onder de deelnemende organisaties. Een herverdeling is nodig omdat de plek waar de kosten worden gemaakt niet altijd de plek is waar de baten neerstrijken. Risico als er niet in de randvoorwaarde wordt voorzien: Als niet aan deze voorwaarde wordt voldaan is het risico dat onvoldoende draagvlak breed draagvlak binnen de gemeente zal zijn om de business case uit te voeren. Maatregelen om risico’s te reduceren: Het is nodig een rechtvaardig financieel model te ontwikkelen waarvan zonodig een herverdelingsmechanisme onderdeel uitmaakt. Aangezien een van de strategische doelstellingen luidt dat een eventuele operatie niet teveel mag kosten, geldt dat alle projectkosten uiteindelijk terugvloeien naar de centrale kas, zodat de burgers en bedrijven niet alleen immateriële baten ontvangen van de operatie (verbeterde dienstverlening), maar ook de materiële.
2.6.4.5 Randvoorwaarde 5 ‘De bereidheid om ICT juridische-, inkoop- en aanbestedingsbeleid aan te passen als onderdeel van de softwarestrategie dan wel ten behoeve van de softwarestrategie’.
De aanleiding voor het opstellen van de business case is de vraag ‘over hoe per 1 oktober 2008 om te gaan met het dan beëindigend contract met Microsoft voor kantoorautomatisering’. Dit impliceert de zoektocht naar alternatieven. Alternatieven kunnen worden gevonden en in een business case worden onderbouwd. Het Gemeentelijk inkoopbeleid rondom ICT vormt de schakel tussen dat wat gewenst is en dat wat wordt aangekocht. De wijze waarop de markt wordt benaderd (mantelcontracten, raamcontracten, enterprise agreements, openbare of Europese aanbestedingen, licentievormen en hun (juridische) consequenties) is van grote invloed op de mate waarin de in deze business case geformuleerde strategische doelstellingen kunnen worden gerealiseerd. Het kan nodig zijn om bestaande contracten, contractvormen en eisen aan licenties in lijn te brengen met de doelstellingen. Een zeer belangrijke randvoorwaarde van dit project is daarom de mogelijkheid en de bereidheid om het juridische- en inkoopbeleid evenals de aanbestedingsrichtlijnen voor software van de Gemeente Amsterdam ter discussie te stellen. Alleen dan kunnen de randvoorwaarden worden geschept waarmee alle mogelijkheden in de markt kunnen worden benut. Via een natuurlijk proces, bij de aanschaf van nieuwe software kan de afnemer worden gedwongen zich te richten op de strategische doelstellingen van de gemeente . Risico als er niet in de randvoorwaarde wordt voorzien: indien het juridische- inkoop- en aanbestedingsbeleid van de Gemeente Amsterdam op het gebied van software niet ter discussie mag worden gesteld, dan zijn de randvoorwaarden niet aanwezig om ook de voordelen van Open Source software te kunnen benutten. Er kan wel een business case worden uitgewerkt, maar die zal niet optimaal geïmplementeerd kunnen worden. Maatregelen om risico’s te reduceren: de bereidheid om ICT juridische-, inkoop- en aanbestedingsbeleid aan te passen als onderdeel van de softwarestrategie dan wel ten behoeve van de softwarestrategie.
Versie 1.0 Extern
24/72
27 oktober 2006
2.6.4.6 Randvoorwaarde 6 ‘Commitment van de Raad en B&W om strategische softwaredoelstellingen daadwerkelijk na te streven en langere termijn steun te geven’.
Commitment van de politiek vertaald zich ten eerste naar heldere en uitvoerbare opdrachten voor het gehele ambtelijk apparaat waarop de business case betrekking heeft. Commitment vertaalt zich ook in betrokkenheid en daadkracht. Risico als er niet in de randvoorwaarde wordt voorzien: zonder de uitdrukkelijke wens van de Raad en B&W om strategische softwaredoelstellingen daadwerkelijk na te streven en langere termijn steun te geven, zal het traject mogelijk op beperkte medewerking of zelfs weerstand stuiten van organisaties binnen de Gemeente Amsterdam. Dit zal belemmerend werken bij het uitvoeren de business case, vooral waar het gaat om het inwinnen van de benodigde informatie en de steun van gemeentelijke organisaties. Maatregel om risico te reduceren: een belangrijke rol zal zijn weggelegd voor de bestuurlijk/ambtelijke Commissie Informatievoorziening die onlangs voor het eerst bijeen is gekomen.
2.6.4.7 Randvoorwaarde 7 ‘Het is van belang dat bij beslissers voldoende kennis aanwezig is om onderscheid te kunnen maken tussen interne en externe doelstellingen en tussen bewezen en theoretische mechanismen die zouden kunnen leiden tot het realiseren van deze doelstellingen’.
Vooronderzoek door het projectteam toont aan dat een softwarestrategie vele doelen kan dienen. De opbrengsten zijn vaak echter immaterieel en moeilijk kwantificeerbaar. Het is van belang dat bij beslissers voldoende kennis aanwezig is om onderscheid te kunnen maken tussen interne en externe doelstellingen en tussen bewezen en theoretische mechanismen die zouden kunnen leiden tot het realiseren van de doelstellingen. Risico als er niet in de randvoorwaarde wordt voorzien: De softwarestrategie (zie hoofdstuk 3) wordt gebaseerd op oneigenlijke of tegenstrijdige doelstellingen of de softwarestrategie leidt niet tot het realiseren van gestelde doelstellingen. Maatregel om risico te reduceren: Voorlichting maar vooral discussie over de doelstellingen van de softwarestrategie van de gemeente. Een belangrijke activiteit was de expertmeeting die op 20 juni is georganiseerd voor Raadsleden van de centrale stad en de stadsdelen. Een van de twee actielijnen bij de uitvoering van het amendement, naast het opstellen van de business case, is juist bewustwording over de doelstellingen van de softwarestrategie.
2.6.4.8 Randvoorwaarde 8 ‘Voldoende praktische kennis van open standaarden en open source software is nodig om de business case te beoordelen en uit te voeren’.
Vooronderzoek door het projectteam heeft ook aangetoond dat wanneer organisaties op grote schaal gebruik willen gaan maken van open standaarden en open source software (die een belangrijke rol zullen gaan spelen in elke softwarestrategie) een kritische succesvoorwaarde is dat binnen de organisatie voldoende kennis hiervan aanwezig is. Risico als er niet in de randvoorwaarde wordt voorzien: te weinig interne kennis om de business case te beoordelen en uit te voeren. Maatregel om risico te reduceren: ervaring leert dat kennis van open source vaak wel aanwezig is, maar verstrooid is en ongericht. Het starten van een kennisgroep binnen de Gemeente Amsterdam moet hier verandering in brengen en zal ook het draagvlak voor een uiteindelijk besluit over de business case ten goede komen.
Versie 1.0 Extern
25/72
27 oktober 2006
3 Van softwarestrategie naar beoogde eindsituatie In dit hoofdstuk wordt het theoretische kader geschetst dat de rode draad vormt voor deze business case. De eerste uitdaging bij de uitvoering van het amendement was het bepalen van een beoogde eindsituatie voor de Gemeente Amsterdam. Zonder te redeneren vanuit de strategische doelstellingen die beoogd worden in deze business case kon het projectteam 17 technische eindsituaties bedenken. Deze 17 eindsituaties betreffen alle combinaties van gesloten of open, back-end of front-end en applicaties of besturingsystemen. Alle 17 mogelijke eindsituaties zijn uitvoerig beschreven in paragraaf 3.3. Via prioriteitstelling tussen de mogelijke strategische softwaredoelstellingen en een kwalitatieve waardering van de mogelijke technische eindsituaties is afgeleid welk scenario de voorkeur heeft om verder te onderzoeken. De mogelijke strategische doelstellingen zijn beschreven in paragraaf 3.2. Aan het eind van deze paragraaf wordt een keuze gemaakt voor de strategische softwaredoelstellingen die worden beoogd met deze businesscase. De aandachtige lezer zal deze herkennen als dezelfde strategische doelstellingen die in paragraaf 2.2. zijn toegekend aan het amendement van Marres. Het is niet meer dan logisch dat dit dezelfde zijn.
3.1 Inleiding bij strategische softwaredoelstellingen Bij het vooronderzoek werd de volgende gedachtegang gevolgd. Het amendement laat veel ruimte voor interpretatie als het gaat om de vraag hoe een softwarestrategie eruit zou moeten zien. Tussen de eindsituatie alles open source en de eindsituatie zoveel mogelijk op open standaarden liggen legio mogelijkheden; minimaal 17 mogelijke eindbeelden, zo heeft het projectteam onderzocht. Elk scenario leidend naar deze 17 eindsituaties kan worden uitwerkt in een business case. De inspanning die hiermee gemoeid is leidt echter tot een traject waarbij de natuurlijke deadline van oktober 2008, het moment waarop het verlengde contract met Microsoft verloopt, niet gehaald wordt. Gelukkig valt het grootste deel; 12 van de 17 scenario’s, bij voorbaat af omdat deze om praktische en technische redenen niet uitvoerbaar zijn. Om een voorkeursscenario/eindsituatie te selecteren uit de resterende 5 is het van belang te redeneren vanuit de voornaamste doelstellingen die de Gemeente Amsterdam wil realiseren met haar softwarestrategie. In de volgende paragraaf worden 3 typen doelstellingen toegelicht die met een softwarestrategie gerealiseerd kunnen worden. In de paragraaf daarna worden de 17 mogelijke eindsituaties geschetst, waaruit, op basis van de gewogen strategische doelstellingen, één eindsituatie en scenario resulteert dat uitgebreid is getoetst in de business case.
3.2 Strategische softwaredoelstellingen Gemeente Amsterdam In deze business case wordt geredeneerd vanuit strategische softwaredoelstellingen. Op deze wijze wordt uitgesloten dat het onderzoek zich richt op de invoering van open source en dat zo objectief mogelijk getoetst wordt of een alternatief voor Microsoft beter past bij strategische doelstellingen van de Gemeente Amsterdam. Via prioriteitstelling tussen de mogelijke doelstellingen van de softwarestrategie kan worden afgeleid welk scenario de voorkeur verdient. Niet elk scenario bedient namelijk elke doelstelling even goed.
In deze business case wordt geredeneerd vanuit strategische softwaredoelstellingen. Deze doelstellingen dienen er voor te zorgen dat de keuze die wordt gemaakt tussen de vele mogelijke scenario’s gebaseerd is op weloverwogen algemene doelstellingen van Amsterdam ‘ICT Stad van Nederland’ met software. Het gaat dus niet uitsluitend om het vraagstuk: wel of niet toepassen van open source. Centraal staat wat er met de inzet van software wordt bereikt en aan welke voorwaarden die software dan dient te voldoen. Het gebruiken van software is immers niet een doel op zich. Bij veel organisaties zowel in binnen- als buitenland ligt de nadruk bij het formuleren van een softwarestrategie op de tegenstelling open source versus closed source. Dit leidt vaak tot felle discussies over de (vaak vermeende) kenmerken van beide type software. Het gaat dan om de beheersbaarheid, kwaliteit, prijs (TCO) en de aanwezigheid van verborgen kosten of niet. Het amendement Marres vraagt om een leveranciersonafhankelijk alternatief voor de Enterprise Agreement met Microsoft die in 2008 afloopt. Deze business case tracht de haalbaarheid hiervan te
Versie 1.0 Extern
26/72
27 oktober 2006
achterhalen en de achterliggende discussie te objectiveren door te redeneren vanuit strategische softwaredoelstellingen. Op deze wijze wordt uitgesloten dat het onderzoek zich richt op de invoering van open source en wordt geborgd dat zo objectief mogelijk getoetst wordt of een alternatief voor Microsoft software beter past bij de strategische doelstellingen van de Gemeente Amsterdam. Via prioriteitstelling tussen de mogelijke doelstellingen van de softwarestrategie kan worden afgeleid welk scenario (zie paragraaf 3.3.1) de voorkeur verdient. Niet elk scenario bedient namelijk elke doelstelling even goed. Hieronder worden de mogelijke doelstellingen van de softwarestrategie van de Gemeente Amsterdam kort uiteengezet. De tien doelstellingen zijn gemakshalve ondergebracht in 3 groepen, markt en economie, financiën en kwalitatieve doelstellingen.
3.2.1
Markt en Economie
1) Economisch: stimuleren lokale ICT-Sector Het doel van de Gemeente Amsterdam is kansen te bieden aan de lokale ICT-sector door voor de ondersteuning van de eigen bedrijfsvoering niet alleen in zee te gaan met de grote bekende multinationale softwarehuizen. Hierdoor kan een economische impuls gegeven worden aan een bredere groep (lokale) ICT dienstverleners. Als een van de grootste vier gemeenten van Nederland hebben de uitgaven van de Gemeente Amsterdam op het gebied van ICT een positieve stimulerende werking op de lokale en Nederlandse economie. Bijvoorbeeld: Amsterdam kiest na een strenge pakketselectie voor haar kantoorautomatisering het Office pakket OpenOffice.org in plaats van de huidige MS Office. Hoewel het pakket misschien niet alle features heeft van een MS Office pakket voldoet OpenOffice in 80% van de gevallen voor de kantoorautomatisering. Amsterdam investeert het geld dat anders aan licenties voor MS Office was betaald in het (laten) doorontwikkelen van het OpenOffice.org pakket door Nederlandse of Amsterdamse bedrijven (stimuleren lokale en Nederlandse economie). De verbeteringen aan het Open Source pakket worden door de Gemeente Amsterdam teruggegeven aan de OpenOffice.org community. Het verbeterde office pakket wordt daardoor, net als bij voorbeeld verbeterde openbare wegen of riolering, kosteloos ter beschikking gesteld aan de burger. Die hoeft op zijn beurt niet een MS Office pakket aan te schaffen, maar heeft daardoor een volwaardig kosteloos alternatief. In de huidige situatie, bij de aanschaf van het MS Office pakket, vloeit de miljoeneninvestering in licenties door de Gemeente Amsterdam niet terug de Nederlandse economie in en al zeker niet naar de Nederlandse of Amsterdamse burger. Het Nederlandse belastinggeld gaat naar een bedrijf in de Verenigde Staten. 2) Marktwerking: bevorderen van concurrentie De Gemeente Amsterdam heeft als doel om de marktwerking binnen de ICT sector te bevorderen. Een goed werkende markt vereist gezonde concurrentie. Een concurrerende omgeving stimuleert innovatie en geeft een impuls aan de concurrentiekracht van het bedrijfsleven. Bovendien draagt concurrentie bij aan de optimalisering van de prijs-kwaliteitverhouding van goederen en diensten alsook aan een efficiënte aanwending van (productie)middelen, die weer ten goede komt aan de consument.14 Als grote ICT afnemer, met publieke gelden, heeft de Gemeente Amsterdam als doel gezonde concurrentie te stimuleren om zo een goed werkende markt te bevorderen, zowel lokaal als nationaal. Via haar inkoopbeleid en haar vermogen innovaties op het gebied van ICT te stimuleren wenst de gemeente meer diversiteit in het aanbod van goederen en diensten te creëren. Bijvoorbeeld: In plaats van voor de kantoorautomatisering directe onderhandelingen in te moeten gaan met Microsoft kunnen, door de keuzemogelijkheden in software te verbreden meerdere leveranciers om een prijsopgave gevraagd worden voor de te leveren functionaliteit. 3) Imago: ‘Amsterdam ICT-stad van Nederland’ De Gemeente Amsterdam wenst, door middel van slim gebruik van haar software, kennis en infrastructuur, haar leidende rol als ICT stad van Nederland te behouden en op innovatieve wijze uit te bouwen. Amsterdam heeft de pretentie en de ambitie om ICT-hoofdstad van Nederland te zijn. Andere (grote) steden zitten bepaald niet stil. Rotterdam, Den Haag, Groningen hebben allen zeer innovatieve programma’s lopen die nauw aansluiten bij de grote ICT innovaties binnen de Nederlandse overheid. Men is geen leider als er geen volgers zijn. Amsterdam heeft als doel haar ICT kennis en software te delen met andere gemeenten. Bijvoorbeeld: De leidende rol van Amsterdam binnen het gemeentelijk ICT bestek kan alleen ten volle 14
http://www.nmanet.nl
Versie 1.0 Extern
27/72
27 oktober 2006
worden benut door andere (kleinere) gemeenten als de ontwikkelingen die de Gemeente Amsterdam doormaakt ook op relatief eenvoudige wijze gedeeld kunnen worden. Zo komen ontwikkelingen die plaats vinden binnen de gemeente ook ten gunste van andere gemeenten.
3.2.2
Financiën
4) Financieel: kostenbesparing op software De Gemeente Amsterdam heeft als doel software tegen een zo gunstig mogelijk tarief in te kopen en te (laten) beheren. Maatwerk aan software dient eveneens tegen een zo gunstig mogelijk tarief te worden uitbesteed. Dit betekent besparingen op de kosten van ICT uitvoering, beheer en inkoop/ licentiebeheer en dat de gemeente voor maatwerkopdrachten niet afhankelijk is van een enkele leverancier. Kostenbesparingen worden gerealiseerd zonder achteruitgang in dienstverlening en kwaliteit van de software. Ook wordt gericht gekeken naar software met een langere levensduur. 5) Financieel: kostenbesparing op hardware De gemeente heeft als doel voorkeur te geven aan software die minder veeleisend is voor hardware (PC, geheugen, processoren etc.). Dit kan eventueel kostenbesparing opleveren door de afschrijvingstermijnen van hardware te verlengen. Bijvoorbeeld: De toenemende eis aan processorcapaciteit van het Windows besturingssysteem leidt tot gedwongen aanschaf van nieuwe PC’s die deze software aan kunnen. Invoering van besturingssystemen die minder capaciteit vergen leidt tot kostenreductie mits de afschrijvingstermijn verlengd wordt. 6) Onderhandelingspositie: leveranciersonafhankelijkheid De Gemeente Amsterdam wenst in haar onderhandelingen met leveranciers van software een optimale onderhandelingspositie te creëren door middel van meer keuzevrijheid. Nederlandse gemeenten in het algemeen en Amsterdam in het bijzonder zijn afhankelijk van een klein aantal leveranciers voor hun primaire en secundaire ICT behoeften. Deze afhankelijkheid zorgt regelmatig voor dwangaankopen van ICT-middelen die gepaard gaan met koppelverkoop van aanverwante software. Bijvoorbeeld, bepaalde backoffice applicaties in combinatie met bepaalde databases zorgen voor gedwongen upgrades.
3.2.3
Kwaliteit en interoperabiliteit
7) Toename interoperabiliteit Steeds meer taken van de Gemeente Amsterdam, al dan niet gebaseerd op wettelijke regelingen worden in ketens uitgevoerd en in ketens geautomatiseerd. Aan het eind (en/of het begin) van elke keten staan burgers en/of bedrijven. De Gemeente Amsterdam streeft er naar om ten behoeve van de eigen bedrijfsvoering en die van de ketenpartners, maar vooral ten behoeve van burgers en bedrijven gebruik te maken van standaarden die de uitwisseling van gegevens zo efficiënt mogelijk laat verlopen, zonder dat ketenpartners elkaar, maar vooral burgers en bedrijven, impliciet verplichten om dezelfde software te gebruiken. Daarnaast streeft de gemeente ernaar haar burgers niet meer dan één keer gegevens te laten verstrekken. Bijvoorbeeld: Bij de modernisering van de GBA wordt het centrale deel (GBA Verstrekkingen) ontwikkeld op basis van Open Source software en Open Standaarden. Aangezien de software bij 450+ gemeenten geïnstalleerd dient te worden is dit een verstandige keuze. Zo wordt niet elke gemeente verplicht om licenties voor de software aan te schaffen en de open standaarden zorgen voor een toename in interoperabiliteit van systemen zodat alle gegevens landelijk beschikbaar kunnen worden gesteld. Onduidelijk is nog of de aanvullende modulen (die de gemeenten zelf moeten aanschaffen) ook in Open Source gebouwd gaan worden. 8) Kwaliteit en functionaliteit: verbetering van software De Gemeente Amsterdam heeft als doel om zelf (meer) invloed uit te oefenen op de samenstelling en levering van software. Het toevoegen van verbeteringen en gemeentespecifieke functionaliteit aan software om tegemoet te komen aan de dienstverleningseisen van de burger. Bijvoorbeeld: Pakket X wordt geleverd en dient aangepast te worden. Nu is men afhankelijk van de leverancier van de software voor verbeteringen. Als de software Open Source is kan een keuze gemaakt worden uit meerdere leveranciers die het meerwerk kunnen verrichten. 9) Digitale duurzaamheid De Gemeente Amsterdam streeft naar Digitale Duurzaamheid. Dit betekent: het op zodanige wijze
Versie 1.0 Extern
28/72
27 oktober 2006
vastleggen, bewaren, beheren en beschikbaar stellen van digitale documenten en bestanden dat deze ook na verloop van tijd raadpleegbaar, toegankelijk en authentiek zijn. Een officieel digitaal document moet digitaal bewaard worden, omdat anders informatie verloren gaat. Voorbeeld van buiten de gemeente: Terugvinden en hergebruiken van digitale informatie stond centraal bij de kwestie over de ESF-gelden. Een uitvoeringsorganisatie moest aantonen hoe deze gelden gebruikt waren om werklozen aan het werk te helpen. Het heeft miljoenen gekost om de verloren of onvindbare gegevens weer te reconstrueren. 10) Bedrijfscontinuïteit: zekerheid in bedrijfsvoering Doel van Gemeente Amsterdam met softwarestrategie is de borging van de bedrijfcontinuïteit en de beheersing van de bedrijfsvoering. Dit betekent enerzijds dat de gemeente zich concentreert op de invoering van breed gedragen ICT-standaards, zodat de gemeente er geen exotische ICThuishouding op na houdt die slechts door een handjevol specialisten in stand gehouden kan worden Anderzijds gaat de Gemeente Amsterdam geen onzekere avonturen aan: te ambitieuze ICTprojecten met grote risico’s voor bedrijfskritische processen. Bijvoorbeeld: De gemeente kiest voor de registratie van haar belastinginning voor een pakket van een kleine leverancier. De leverancier gaat na 5 jaar failliet en er gaat iets mis met het pakket. De bron van het pakket kan echter pas na lange juridische procedures verkregen worden via een ESCROW regeling. In die tijd mag geen andere leverancier wijzigingen aanbrengen in het pakket en loopt de bedrijfscontinuïteit van de gemeente gevaar. Gezien de voorgeschiedenis van het amendement en overige ontwikkelingen binnen de Gemeente kan worden gesteld dat doelstellingen op het gebied van kwaliteit en interoperabiliteit het zwaarst wegen, met dien verstanden dat de financiën en de continuïteit van de bedrijfvoering een randvoorwaardelijke rol spelen. Dit beeld is bevestigd tijdens de Expertmeeting met Raadsleden op 20 juni jl.
3.2.4
Gehanteerde strategische doelstellingen
De vier gekozen strategische doelstellingen zijn: 1) 2) 3)
4)
Leveranciersonafhankelijkheid (uit het amendement) Continuïteit in de bedrijfsvoering Kwaliteit en interoperabiliteit dienen bevorderd te worden Materiele en immateriële baten dienen op te wegen de lasten en de benodigde investeringsbedragen dienen realiseerbaar te zijn.
Het amendement stelt dat “Dat er met gemengde gevoelens kennis genomen wordt van het raamcontract met Microsoft. Het college vanaf heden altijd, vóór datum van ondertekening, - een vergelijkbaar contract met een software leverancier - aan de raad dient voor te leggen.” De kerngedachte achter het amendement is dus dat er een gestreefd dient te worden om eind 2008 (wanneer het Raamcontract met Microsoft afloopt) een zekere mate van leveranciersonafhankelijkheid te hebben bereikt. Eerder is aangegeven (in paragraaf 2.4) dat het projectteam heeft geobserveerd dat daarnaast een belangrijke onderliggende doelstelling van het amendement gelegen is om door middel van verhoogde interoperabiliteit van systemen, de dienstverlening aan burgers en bedrijven te verbeteren. Dit beeld is in de ogen van het projectteam en de Wethouder ICT nog eens bevestigd tijdens een expertmeeting die op 20 juni jl. is georganiseerd voor Raadsleden van centrale stad en stadsdelen. Uit de expertmeeting kwam tevens naar voren welke randvoorwaarden het meest belangrijk worden geacht bij de uitvoering van het amendement: 1. De continuïteit van de bedrijfsvoering van de Gemeente mag niet in gevaar komen gedurende en na een migratie naar de gewenste situatie; 2. Het geheel van materiële en immateriële baten moet opwegen tegen het geheel van materiële en immateriële kosten. Ook moet een eventueel negatief verschil tussen de materiële baten en lasten van aanvaardbare omvang zijn (= het mag niet teveel kosten); Deze randvoorwaarden moeten niet verward worden met de projectrandvoorwaarden uit het vorige hoofdstuk. De strategische randvoorwaarden stellen eisen aan het eindresultaat en/of het traject
Versie 1.0 Extern
29/72
27 oktober 2006
daarheen (het scenario). De projectrandvoorwaarden stellen eisen aan de omgeving, zodat het scenario uitgevoerd kan worden. Om verwarring te voorkomen voegen we ook de strategische randvoorwaarden onder de noemer Strategische softwaredoelstellingen voor de Gemeente Amsterdam. Totaal is er in deze businesscase dus uitgegaan van vier strategische softwaredoelstellingen
3.3 Technische eindsituaties en scenario’s Er is gekozen is om te werken met gewenste eindsituaties die de strategische doelstellingen zo veel mogelijk ondersteunen. De haalbaarheid moet getoetst worden voordat het College en de Gemeenteraad een beslissing moet nemen bij het aflopen van het huidige Microsoft contract in 2008.
Hieronder volgt een analyse van de mogelijke eindsituaties waartoe de Softwarestrategie van de Gemeente Amsterdamse kan leiden. De volgende parameters leiden tot 17 combinaties: - Open source, closed source software of beiden; - Applicaties, besturingssystemen of beiden; - inzet van beiden op de desktop, aan de achterkant in de server omgeving of beiden. Ten behoeve van de overzichtelijkheid zijn de 17 mogelijkheden geclusterd tot eindsituaties. Deze situaties en de clustering zijn hieronder beschreven.
17 mogelijke eindsituaties softwarestrategie Gemeente Amsterdam
3.3.1
Mogelijke eindsituaties
Het streven is dat de eindsituatie zo veel mogelijk invulling geeft aan de strategische softwaredoelstellingen die hierboven zijn benoemd. Eindsituaties 1,5,7,8,9,10,14 en 15 vallen, voornamelijk om technische redenen, af. Eindsituatie 17 wordt aan het spectrum toegevoegd, er wordt een aparte omgeving geïmplementeerd die volledig is gebaseerd op de Amsterdamse keuze voor de ‘beste’ software. Men heeft hier wel te maken met het inrichten van een ‘extra’ omgeving, wat ten koste gaat van de efficiency, bijvoorbeeld omdat er extra beheer nodig is. Deze (tijdelijke) efficiency achteruitgang zorgt er wel voor dat er geen grootschalig migratietraject plaats vindt van de huidige omgevingen.
Alle eindsituaties gaan uit van de wijze waarop wordt omgegaan met standaarden en software in de nieuwe situatie. Het streven is dat de eindsituatie zo veel mogelijk invulling geeft aan de strategische softwaredoelstellingen die hierboven zijn benoemd. Na een eerste schifting in mogelijke eindsituaties vallen er een aantal mogelijkheden af met de volgende, veelal technische, redenen:
Versie 1.0 Extern
30/72
27 oktober 2006
•
•
•
Eindsituatie 1: Deze situatie is de huidige situatie, dit betekent ‘niets doen’. Momenteel wordt binnen de Gemeente Amsterdam closed software gebruikt voor zowel de desktop als de server zijde op het gebied van applicaties en besturingssystemen. Het amendement Marres pleit voor het mogelijk maken van een leveranciersonafhankelijke keuze. Kiezen voor eindsituatie 1 betekent kiezen om niet te veranderen en daardoor ook geen van de doelstellingen te behalen. Eindsituaties 5,8,9,10: Het gebruik van uitsluitend closed software op een open source besturingssysteem in de front-end levert, als uitgangspunt voor een eindsituatie, onnodig veel comptabiliteitsproblemen op. Veel closed software wordt geproduceerd om te werken met de besturingssystemen van Microsoft en niet voor andere platformen. Veel applicaties zullen alleen via technische ingewikkelde oplossingen als een terminal server, virtual machine of emulator (bijvoorbeeld WINE) op de desktop gebruikt kunnen worden. Bij deze eindsituaties zal het gebruiksgemak van alledaagse applicaties, ongeacht de functionaliteit, zodanig verminderen dat er voor gekozen is deze opties niet mee te nemen in de overweging voor een eindsituatie. Eindsituaties 7,14,15: Deze situaties houden in dat er naar gestreefd wordt een volledige Open Source desktop omgeving in te richten met alle benodigde functionaliteit, maar dat een deel van de back end niet toegankelijk is voor veranderingen. Het invoeren van een Open Source desktop is alleen haalbaar als er geen beperkingen zijn om ook wijzigingen aan te brengen in de back end. De ervaring leert bij meerdere pogingen die zijn ondernomen door andere overheidsorganisaties, zoals de Belastingdienst, dat de mogelijkheden om bijvoorbeeld een Linux desktop te implementeren zonder verandering aan te brengen in de back end nog te beperkt zijn. De beperkingen liggen vooral in de interoperabiliteit tussen applicaties op de desktop (bijvoorbeeld mail) en de voorzieningen aan de achterkant (bijvoorbeeld MS Exchange). Er zijn wel mogelijkheden om integratie te bewerkstelligen, maar die zijn arbeidsintensief en/ of onderhoudsgevoelig. Om deze reden is ervoor gekozen om deze opties af te laten vallen.
De 9 eindsituaties die na de eerste schifting overblijven zijn: 2,3,4,6,11,12,13,16 en 17. De tweede stap om selectie mogelijk te maken is het samenvoegen van de resterende eindsituaties in de volgende vijf clusters: Cluster 1: (Windows met Open Source desktop (6)): OSS op een bestaande MS Windows omgeving. Bijvoorbeeld een KA omgeving gebaseerd op het MS Windows besturingssysteem met daarop de Open Source office suite OpenOffice.org de browser FireFox en andere applicaties die op het besturingssysteem opereren. Ook wordt hier het zogenaamde verwebben van applicaties in meegenomen. Inspanningen die verricht worden zullen te maken hebben met het omzetten van bestaande macro’s naar OpenOffice.org en het w3c compliant maken van webapplicaties. De zichtbaarheid van een dergelijk traject is hoog, de desktop wordt immers beïnvloed, de impact op de ICT organisatie is middelmatig want er verandert weinig aan de back-end systemen, maar er dient wel te worden ontwikkeld om bestaande webapplicaties w3c compliant te maken zodat ze functioneren in FireFox. De impact op de gebruiker is eveneens middelmatig, zij krijgen wel nieuwe desktop applicaties, maar die zijn bewezen weinig te verschillen van de huidige software. Hierbij worden vooral de doelstellingen betreffende het zichtbaar gebruikmaken van Open Source deels gehaald. Doelstellingen die worden gehaald: Men heeft hierbij de kans om enige besparingen te realiseren op de ingezette software, maar het verwebben van applicaties vergt ook tijd en inspanning die de besparingen in eerste instantie waarschijnlijk teniet doen.
Versie 1.0 Extern
31/72
27 oktober 2006
Cluster 2: (alleen migratie van de back end naar Open Source in gradaties (eindsituatie 2,3,4)): Er verandert niets aan de front-end en dus ook niet voor de gebruiker. In de back end wordt eerst getracht gesloten applicaties op een Linux besturingssysteem beschikbaar te stellen, bijvoorbeeld Oracle of Sap op Linux (eindsituatie 2), of Open Source applicaties in gebruik te nemen op gesloten besturingssystemen, vervangen van een Active Directory + MS Exchange omgeving met een Samba & OpenLDAP combinatie draaiende op een Linux server, spamassasin, virusscanning etc. (eindsituatie 3). Hoewel dit goede migratiescenario’s zijn om naar een gewenste eindsituatie te komen worden er te weinig van de bepaalde strategische doelstellingen gehaald om deze als uitgangspunt te nemen. Eindsituatie 4 kan in dit geval dienen als mogelijke eindsituatie waarbij fasen 2 en 3 worden doorlopen. Het streven is dan om zonder de gebruiker er iets van te laten merken een goede mix te vinden van closed en open source software. De afhankelijkheid van sommige applicaties (denk aan de backoffice systemen) van closed source software is vaak te groot om volledig over te gaan. Doelstellingen die worden gehaald: Bredere inzet van open standaarden en software en een sterkere onderhandelingspositie ten opzichte van leveranciers. Er is sprake van een toename in interoperabiliteit, maar omdat niet alle backoffice systemen kunnen worden aangesloten is deze toename beperkt tot secundaire systemen. Migratiekosten zijn hoog en de inspanning groot waardoor de eerste jaren waarschijnlijk nog geen vruchten geplukt kunnen worden van de besparingen op harden software. Cluster 3: (het gebruik van Open Source applicaties op de desktop en een migratie van de back end naar Open Source in gradaties (11, 12, 13 samen)): Bij deze eindsituaties geldt, net als bij cluster 2, dat de back end evolutionair wordt gemigreerd naar Open Source en de juiste mix gevonden dient te worden tussen open en closed software. Eindsituaties 4 (zie cluster 3) en 13 lijken in dit geval veel op elkaar met het verschil dat voor de zichtbaarheid aan de desktop kant wel wordt begonnen met het gebruiken van Open Source software op de desktop. De inspanning is groter dan bij punt 2 omdat er ook gekeken moet worden naar verwebbing en w3c compliancy van applicaties en het herprogrammeren van macro’s voor de invoering van OpenOffice.org. Hoewel er wel meer strategische doelstellingen worden gehaald is de inspanning die verricht moet worden ook groter. Doelstellingen die worden gehaald: een combinatie van de twee voorgaande clusters waarbij significante besparingen gehaald kunnen worden die waarschijnlijk de eerste jaren worden teniet gedaan door de migratiekosten. Wel een forse toename in interoperabiliteit en meer mogelijkheden om leveranciers uit de Nederlandse markt te betrekken. Onderhandelingspositie wordt fors verbeterd, maar de afhankelijkheid van gesloten systemen en hun leveranciers is nog wel aanwezig. Cluster 4: (alles Open Source (16)): Deze eindsituatie gaat uit van het streven om zowel de desktop als de back end volledig op Open Source te laten functioneren. Dit betekent dat gewerkt wordt aan de migratie van de bestaande omgeving naar Open Source. Men krijgt dan bijvoorbeeld een Open Source besturingssysteem (Linux) met daarop de Open Source office suite OpenOffice.org. De applicaties die in 1, 2 en 3 gebruikt worden zullen waarschijnlijk ook beschikbaar zijn onder dit
Versie 1.0 Extern
32/72
27 oktober 2006
besturingssysteem. Linux biedt echter meer mogelijkheden als we zoeken naar functioneel gelijke open. source alternatieven. Doelstellingen die worden gehaald: Hoewel alle strategische doelstellingen gehaald worden is de impact van het migreren van een KA omgeving erg groot. Er zal begonnen moeten worden met lage impact oplossingen aan de back end, evoluerend naar vervanging van applicaties aan de back end die meer raakvlakken Voorbeeld van een migratiescenario hebben met de desktop. Naar mate de back end meer geschikt is voor koppelingen met een Open Source front end kan ook op de desktop worden begonnen met Open Source applicaties en daarna het besturingsysteem. De praktijk laat zien (München, Wenen) dat dit vaak lange trajecten zijn met vele hobbels en tegenslagen, de verandering in de IT organisatie is erg groot, temeer omdat er wordt gestreefd naar volledige omwenteling en daarbij ook alle medewerkers mee dienen te veranderen. Dit geeft een grote extra druk op de IT organisatie, terwijl met andere eindsituaties er nog een optie is voor medewerkers om (deels) bij het oude te blijven. Naar aanleiding van de ‘Open Source’ pilots die al bij de Gemeente Amsterdam hebben plaatsgevonden en de problemen die zich bij andere complexe organisaties voordoen zien we dat de migratie vaak de ‘bottleneck’ is. De (vaak verborgen) hoge kosten, inspanningen en risico’s van een migratie leiden ertoe dat de eerste jaren vaak weinig doelstellingen worden gehaald. Daarom is de volgende eindsituatie er op gericht het migratieproces iteratief en facultatief te laten plaatsvinden. Dit laatste alternatief heeft als einddoel, het creëren van een omgeving naast de huidige (historisch ontstane) omgevingen waarin getracht wordt alleen software wordt gebruikt die voldoet aan de ‘open’ sofware strategische doelstellingen van de Gemeente Amsterdam. Daar waar dit lukt, geeft deze eindsituatie de mogelijkheid te ‘mixen’. Het gebruik van functionaliteit uit de ‘open’ omgeving is mogelijk in aanvulling of ter vervanging van de functionaliteit uit de huidige omgevingen. Cluster 5: (alles zo veel mogelijk ‘open’ in een aparte omgeving (17)): In deze omgeving wordt gebruik gemaakt van software die volgens de nieuwe randvoorwaarden is getoetst en daardoor voldoen aan de strategische softwaredoelstellingen van de gemeente. Er wordt een aparte omgeving geïmplementeerd die volledig is gebaseerd op de Amsterdamse keuze voor de ‘beste’ software, zo veel mogelijk open. Wat het beste is voor Amsterdam, wordt bepaald door de strategische softwaredoelstellingen.
Versie 1.0 Extern
33/72
27 oktober 2006
Cluster 5/eindsituatie 17: Een aparte Open Source omgeving
Tevens voorkomt het een grootscheeps migratietraject. Deze omgeving zal functionaliteit gaan bieden binnen het gestelde werk- en ICT-gebied met als randvoorwaarden de softwaredoelstellingen. De opbouw volgt het implementatiescenario dat hierboven is geschetst, van back end naar front end. Dit voorkomt een lang migratietraject en geeft de mogelijkheid om per opgeleverde en afgenomen functionaliteit een duidelijke kosten- en batenstructuur aan te brengen. Doelstellingen die worden gehaald: Alle strategische doelstellingen worden bij het volledig uitvoeren van deze eindsituatie gehaald. Het is echter niet realistisch om een volledige kopie van de huidige productieomgeving in één keer te realiseren, daarom dient er wel een fasering in aangebracht te worden. Dit geschied op basis van drie typen werkplekken. Afhankelijk van de behoefte aan functionaliteit van de gebruiker wordt de Open Source omgeving aangeboden. Men heeft hier te maken met het inrichten van een ‘extra’ omgeving, wat ten koste gaat van de efficiency, bijvoorbeeld omdat er extra beheer nodig is. Deze (tijdelijke) efficiency achteruitgang zorgt er wel voor dat er een minder grootschalig migratietraject plaats vindt van de huidige omgevingen, maar dat de migratie met name plaats vindt op het gebied van data- en gebruikersmigratie van de huidige omgeving naar de nieuwe omgeving in plaats van meer risicovolle migratie van de huidige systemen. Als er nieuwe functionaliteit is gerealiseerd in de nieuwe omgeving, bijvoorbeeld ‘mail functionaliteit’, dan kunnen de andere omgevingen daartoe overschakelen. Wel dient er voor gezorgd te worden dat er beleid wordt geformuleerd op de (gedwongen) afname van de nieuwe functionaliteit door de huidige omgevingen. De voordelen en strategische doelstellingen zijn namelijk alleen te halen als ook de huidige omgevingen gebruik gaan maken van de functionaliteit uit de ‘open’ omgeving.
Versie 1.0 Extern
34/72
27 oktober 2006
3.3.2
Vaststellen van de eindsituatie om uit te werken in de business case
De conclusie is dat de eindsituaties in cluster vier (eindsituatie 16) en cluster vijf (eindsituatie 17) het hoogst scoren waar het de strategische doelstellingen van de Gemeente Amsterdam betreft. De eindsituatie 16 brengt echter meer onzekerheden met zich mee op de punten bedrijfscontinuïteit en kostenbeheersing. Het gaat hier om een migratie van systemen. Eindsituatie 17 geniet de voorkeur omdat de nieuwe omgeving los zal staan van de huidige waardoor de bedrijfscontinuïteit minder in gevaar komt en de kosten binnen een dergelijke omgeving beter te managen zijn.
Voordat we in deze paragraaf vaststellen welk eindsituatie de voorkeur verdient om in deze business case verder te toetsen, is een kort resumé van de aanpak hier op zijn plek: uit het vooronderzoek is gebleken dat er zeer veel mogelijke varianten zijn voor een eindsituatie, maar liefst 17. Daarbij is nog niet meegerekend dat er tijdens migraties nog veel meer tijdelijke hybride situaties (combinaties van verschillende besturingsystemen en software aan de front- en back-end) kunnen ontstaan. Getracht is een overzicht te genereren van 5 (6 inclusief ´Verder gaan met Microsoft´) clusters van de meest voor de hand liggende opties. De 17 mogelijke eindsituaties zijn geschoond van opties die niet logisch zijn of te complex zijn om uit te voeren (zie paragraaf 3.3.1). Het is niet haalbaar om voor elk van deze 17 eindsituaties, geclusterd of niet, een business case op te stellen. Daarom dient er een keuze gemaakt te worden voor één, logische, haalbare situatie die het best tegemoet komt aan de strategische softwaredoelstellingen van de gemeente Amsterdam. Hoe deze keuze te maken? Hiernaast worden alle eindsituaties die in de vorige paragraaf zijn ingedeeld in 5 clusters, op verschillende aspecten gescoord. De schaal loopt van 0 t/m 5, waarbij 0 betekent dat met dat scenario geheel niet voldaan wordt aan het criterium en 5 volledig wordt voldaan. De scoring heeft plaatsgevonden door directe betrokkenen bij het project en is getoetst tijdens een bijeenkomst van experts in de toetsingscommissie. Deze scores zijn daarna gemiddeld. In de volledige matrix met OSS doelstellingen in Bijlage 1 is te zien hoe alle doelstellingen scoren. Opvallend is dat alle 2,7 3,3 2,3 4,0 37 clusters redelijk dicht bij elkaar zitten, behalve cluster 5. Om leveranciersonafhankelijkheid te realiseren is het noodzakelijk om zowel de 2,7 2,0 2,7 2,7 30 front- als de back-end te wijzigen (clusters 4 en 5) aangezien de afhankelijkheid van Microsoft op beide gebieden groot is. OSS Doelstellingen
Cluster 2 BE migratie (gradaties)
Cluster 3 FE OSS op Windows BE migratie (gradaties)
Kostenbeheersing (SD)
OSS op Windows
Interoperabiliteit (SD)
Cluster 1
Bedrijfscontinuiteit (SD)
Scenario
Leveranciersonafhankelijk (AM)
Criteria
3,3 2,3 3,0 2,0 32
De overige clusters lossen dit probleem maar deels op. De scores betreffende Alles OSS (Migratie) bedrijfscontinuïteit en kostenbeheersing 5,0 1,0 5,0 2,0 39 bepalen daarna dat migratie een groter risico Cluster 5 met zich mee brengt voor het uitvallen van Alles OSS (Greenfield) systemen en het maken van onvoorziene 5,0 4,3 5,0 5,0 58 kosten, dan bijvoorbeeld bij cluster 5 waarin er Cluster 6 wordt uitgegaan van een aparte omgeving. Aan Verder gaan met Microsoft de interoperabiliteitseis kan alleen voldaan 0,0 4,3 1,3 3,3 27 worden als alle systemen aan de randvoorwaarde van open standaarden Matrix eindsituatie / Open Softwarestrategie (deel voldoen. Opvallend daarbij is dat cluster 6 daar hoofddoelstellingen, volledige matrix in bijlage 1) laag scoort. Doorgaan met Microsoft zorgt ervoor dat systemen en data alleen interoperabel zijn als de andere systemen ook van het zelfde bedrijf afkomstig zijn. De Gemeente bevindt zich daarnaast in een keten met andere overheidspartijen die niet allen aan deze systeemeisen kunnen of willen voldoen (ook open standaarden moeten). Daarnaast is een belangrijk gegeven dat in communicatie met de burger de Gemeente niet mag eisen dat deze een Microsoft pakket bezit, tenzij deze door de gemeente geleverd wordt. Cluster 4
Versie 1.0 Extern
35/72
27 oktober 2006
De conclusie is dat cluster 4 en cluster 5 het hoogst scoren waar het de strategische doelstellingen van de Gemeente Amsterdam betreft. Cluster 4 (eindsituatie 16) brengt echter meer onzekerheden met zich mee op de punten bedrijfscontinuïteit en kostenbeheersing omdat het hier gaat om een migratie van in productie zijnde systemen. Cluster 4 richt zich op het volledig overschakelen open source software. Dit is niet reëel aangezien er voor sommige closed source pakketten geen goed open alternatief is. Cluster 5 (eindsituatie 17) geniet de voorkeur omdat de nieuwe omgeving los zal staan van de huidige waardoor de bedrijfscontinuïteit minder in gevaar komt en de kosten binnen een dergelijke omgeving beter te managen zijn. Denk bijvoorbeeld aan het feit dat een project leidend naar eindsituatie 17 ook stopgezet kan worden met minder afbreukrisico, terwijl een project voor een migratie moeilijk halverwege kan worden beëindigd zonder dat hierdoor ander systemen worden beïnvloed. In zijn geheel is eindsituatie 17 snel te realiseren waardoor er snel resultaten en inzichten verkregen kunnen worden.
Versie 1.0 Extern
36/72
27 oktober 2006
4 Toetsing van beoogde eindsituatie en migratiescenario In hoofdstuk 3 is uit zeventien mogelijke eindsituaties degene gekozen die het best voldoet aan de strategische softwaredoelstellingen van het amendement en de business case. In dit hoofdstuk vindt een meer uitgebreide kwalitatieve en kwantitatieve toetsing plaats aan de hand van dezelfde strategische doelstellingen. Deze toetsing moet uitwijzen of deze eindsituatie en bijbehorend migratiescenario wenselijk en haalbaar zijn.
4.1 Afbakenen van het onderzoeksgebied Voor het onderzoek zijn gegevens gebruikt van twee diensten die onlangs hun portfolio hebben overgedragen aan het Servicehuis ICT (SHI), te weten de Dienst Belastingen en de Dienst Werk en Inkomen . Daarnaast zijn gegevens gebruikt uit het document ‘Financiële Startpositie SSC ICT 1 januari 2006’ waarin de geconsolideerde gegevens zijn opgenomen van de 7 diensten die deelnemen aan het SHI. Functioneel gezien concentreert de realisatie van het alternatief zich op het realiseren van werkplekken met de benodigde ondersteuning aan de achterkant en toegang tot de applicaties.
Het onderzoeksgebied waaruit de gegevens worden getrokken ten behoeve van de toetsing kan in dezelfde twee categorieën worden ingedeeld als het werkgebied (paragraaf 2.6.3). Het werkgebied bakent het terrein af waarop de business case effect kan hebben. Vanwege praktische beperkingen kunnen beiden gebieden niet volledig overeenkomen.
4.1.1
Onderzoeksgebied organiek
Besloten is om gezien de beschikbare tijd het onderzoek voor (met name de financiële) onderbouwing van de huidige situatie voor deze business case te baseren op een populatie waaruit kwalitatief de meest volledige en recente gegevens voorhanden zijn. Voor het onderzoek zijn gegevens gebruikt van twee diensten die onlangs hun portfolio hebben overgedragen aan het Servicehuis ICT, te weten de Dienst Belastingen15 en de Dienst Werk en Inkomen16. Daarnaast zijn gegevens gebruikt uit het document ‘Financiële Startpositie SSC ICT 1 januari 2006’17 waarin de geconsolideerde gegevens zijn opgenomen van de 7 diensten die deelnemen aan het SHI. Ook van de Bestuursdienst Amsterdam (BDA) zijn gegevens gebruikt.18 De BDA heeft onlangs een aanbesteding gedaan voor het beheer van 500 werkplekken waarvoor het programma van eisen waardevolle informatie bood. Het totale aantal werkplekken, dat binnen het onderzoeksgebied valt komt daarmee op 4.356, ongeveer 30% van het totale aantal werkplekken bij de Gemeente Amsterdam.
4.1.2
Onderzoeksgebied functioneel
Het functionele onderzoeksgebied is gelijk aan het functionele werkgebied zoals beschreven in paragraaf 2.6.3.
4.2 Kwalitatieve aspecten van de uitvoering van het scenario Hieronder worden alle kwalitatieve aspecten van de beoogde eindsituatie en bijbehorend migratiescenario onderbouwd. De uitkomst van de toetsing op elk aspect wordt geclassificeerd als voordeel, nadeel of neutraal/onbekend. Het gaat hierbij in feite om een toetsing van eindsituatie 17 uit het vorige hoofdstuk ten opzicht van eindsituatie 1: ‘niets doen’ De eerste drie aspecten zijn direct afgeleid van de strategische doelstellingen en wegen daarom het zwaarst voor deze business case. De overige aspecten vallen onder de categorie neveneffecten. Ze wegen niet mee in de business case, maar kunnen wel van invloed zijn op de politieke besluitvorming over de business case.
15
‘Eindrapport DBGA Financiële Uitwerking transitie 1e tranche (onderdeel van het programma Shared Service Center ICT)’ –
dd. 23 mei 2006. 16
‘Eindrapport Financiële Uitwerking 1e tranche 2006 DWI (onderdeel van het programma Shared Service Center ICT)’ – dd. 24 mei 2006. 17 ‘Financiële Startpositie SSC ICT 1 januari 2006 (onderdeel van het programma Shared Service Center ICT)’ – dd. 31 juli 2006 – versie 3.0 (def). 18 ‘Programma van eisen ‘Beheer IT-faciliteiten’ Bestuursdienst Amsterdam’ – 29 november 2005.
Versie 1.0 Extern
37/72
27 oktober 2006
4.2.1
Leveranciersonafhankelijkheid
Voordelen Keuzevrijheid in softwareleveranciers door kennis en beschikbaarheid van alternatief Keuzevrijheid in softwareleveranciers door beschikbaarheid van broncode Minder afhankelijkheid van leveranciersstandaarden Nadelen Migratie naar andere systemen kan nodig zijn De Gemeente dient een actieve en participerende houding dient te ontwikkelen ten opzichte van de software en standaarden waarop zij invloed wil hebben Neutraal Leveranciersonafhankelijkheid kan verschuiven van pakketleverancier naar leverancier open werkplek. Leveranciersonafhankelijkheid moet vooral worden afgedwongen door smart buyership.
Huidige situatie Zoals eerder is aangegeven stelt het amendement dat er in 2008 een zekere mate van keuzevrijheid dient te zijn bij het afwegen van contracten met leveranciers voor kantoorautomatiseringsoftware. In de huidige situatie wordt veelal gewerkt met software waarvoor betaalde licenties gelden die het gebruiksrecht voor een bepaalde of onbepaalde periode op de software verlenen. In de meeste gevallen wordt de broncode van de programmatuur niet ter beschikking van de Gemeente gesteld. Voor aanpassingen aan de software naar gemeentespecifieke wensen en eisen is men gebonden aan de leverancier van de software. Daarnaast is het zo dat in de meeste gevallen dit soort software niet op basis van open standaarden is ontwikkeld, maar de leverancier hanteert vaak een eigen standaard die alleen communiceert of te lezen is door programmatuur die is gemaakt door die zelfde leverancier. Afname van dergelijke pakketten leidt ertoe dat het overstappen naar andere leveranciers zeer kostbaar is. Dit noemt men ‘vendor (leverancier) lock-in’ of gedwongen winkelnering genoemd. Beoogde eindsituatie De doelstellingen van het amendement en het scenario zijn een verandering uit te voeren die deze afhankelijkheid doorbreekt. Via een softwarestrategie kan de eis opgelegd worden aan de inkopers van software dat de broncode beschikbaar wordt gesteld aan de Gemeente en/of dat de software in ieder geval voldoet aan open standaarden. Bij ontevredenheid over een leverancier kan de (door-) ontwikkeling of beheer (hoewel het niet altijd eenvoudig is, is de mogelijkheid er wel) overgenomen worden door een andere leverancier. Op deze wijze kan de gemeente er in verre mate voor zorgen dat haar systemen voor ontwikkeling en beheer overdraagbaar zijn aan andere leveranciers en dat zij te allen tijde kunnen communiceren met andere open systemen en data opslaan in een duurzaam formaat. Hoewel open software vanwege zijn aard wellicht minder snel tot een vendor lock-in leidt bestaat het risico dat de leveranciersafhankelijkheid verschuift van de pakketleverancier naar leverancier van de open werkplek. Leveranciersonafhankelijkheid moet daarom vooral ook afdwongen worden door smart buyership. De focus dient te liggen op hoe wordt ingekocht, hoe met leveranciers wordt omgegaan en hoe geborgd wordt dat we van de leverancier af kunnen. Wat het projectteam als misschien wel belangrijkste winst van het voorgestelde scenario ziet, is dat kennis en ervaring opgebouwd wordt van een werkend open source alternatief naast de huidige gesloten werkplekken. Zo kan een zuivere vergelijking gemaakt worden op bijvoorbeeld de volgende punten: • kwaliteit, een stelling in deze business case is dat software die volledig werkt met open standaarden beter is dan software die dat minder doet, terwijl open source software in principe dezelfde functionaliteit voor kantoorautomatisering biedt als closed source software. In specifieke gevallen zullen er weldegelijk verschillen zijn. • beheerskosten, een stelling in deze business case is dat software die volledig werkt met open standaarden eenvoudiger (en dus goedkoper is) in het beheer dan software die dat minder doet, terwijl open source software in principe even eenvoudig/ingewikkeld is om te beheren als closed source software. Afhankelijk van de situatie zullen er ook op dit terrein in de praktijk weldegelijk verschillen zijn. • hardwarekosten, deze business case gaat niet op voorhand uit van de premisse dat door meer gebruik van open standaarden en open source software de kosten op hardware kunnen worden
Versie 1.0 Extern
38/72
27 oktober 2006
verminderd. Doorat in het beoogde scenario een deel van de Gemeente met alternatieve software werkt wordt het mogelijk vergelijkingen te trekken. De kwalitatieve winst is dus het inzicht in de mogelijkheden en onmogelijkheden. Zo wordt ‘een actieve en participerende opstelling richting open source ontwikkelingen’ in de praktijk vorm gegeven.
4.2.2
Interoperabiliteit
Voordelen Verhoogde interoperabiliteit bevorderd de interne en interbestuurlijke gegevensuitwisseling ten behoeve van verbeterde dienstverlening en handhaving Verhoogde interoperabiliteit bevorderd gegevensuitwisseling tussen de Gemeente en burgers en bedrijven Verhoogde interoperabiliteit bevorderd ketenintegratie en basisregistraties Aanbieden Standaard Open Werkplek via shared service concept maakt controle op decentraal gebruik van open standaarden nog maar beperkt nodig Nadelen Actieve participatie van de Gemeente vereist voor het adapteren en medevaststellend van open standaarden Migratie naar andere systemen kan nodig zijn
Huidige situatie Het officiële standpunt van de Nederlandse Overheid is dat het gebruik van open standaarden moet. De Gemeente Amsterdam heeft hiertoe beleid geformuleerd (zie paragraaf 2.6.4.2). Dit beleid wordt echter nog niet actief gehandhaafd. Open standaarden verhogen de ‘interoperabiliteit van systemen’ en in het verlengde daarvan interoperabiliteit van bestanden. Het gaat hier zowel om de uitwisseling van gegevens binnen de gemeente, tussen gemeentes en andere overheden als tussen de gemeente en burgers en bedrijven. De volgende ambities zijn kunnen bijvoorbeeld niet worden gerealiseerd zonder open standaarden: • Eén-loket gedachte, met meerdere kanalen naar klant en vice versa, doch met één gezicht vanuit het perspectief van dienstverlening; • Eenmalige informatieaanlevering, met de mogelijkheid van regie van de eigen persoonsgegevens;
• Eenmalige registratie; authentieke registraties/stroomlijning basisgegevens; • Eenmalige aanmelding en authenticiteit bij communicatie met de overheid. De software van Microsoft, dat expliciet genoemd staat in het amendement Marres, maakt niet op alle gebieden gebruik van open standaarden. Zo blijft de Gemeente gebonden aan specifieke Microsoft standaarden (.doc, .xls, .ppt etc.) en haar communicatie protocollen. Ook het gebruik van de Microsoft Internet Explorer Browser zorgt ervoor dat er nog steeds applicaties worden ontwikkeld (Andreas), en ingekocht (SAP) die niet conform open W3C (web) standaarden zijn ontwikkeld, terwijl de Nederlandse Overheid expliciet vraagt hier rekening mee te houden: “Bij het ontwikkelen van overheidswebsites is uitwisselbaarheid van informatie van belang. Het gebruik van open standaarden zorgt voor verbeterde communicatie tussen de zender en ontvanger van informatie. Voor overheidsites is het aan te raden om zoveel gebruik te maken van open standaarden ter bevordering van de uitwisselbaarheid van informatie.”19 Daarnaast bevindt de Gemeente zich niet op een eiland. Veelvuldige interactie met andere overheden, burgers en bedrijven is gewenst. In de communicatie en uitwisseling van bestanden mag de Gemeente haar partners: overheden, burgers en bedrijven niet op kosten jagen door het gebruik van gesloten standaarden. Als een burger of bedrijf bijvoorbeeld bepaalde gegevens alleen in een .doc bestand van de website kan downloaden, dan dient de gemeente daarbij ook het pakket te verschaffen waarmee dit bestand te lezen is, namelijk Microsoft Office. Als de gemeente gebruik maakt van open standaarden voor berichten verkeer zijn de communicatiepartners van de Gemeente vrij in hun keuze van software om berichten te openen en op te slaan.
19
http://webrichtlijnen.overheid.nl/handleiding/ontwikkeling/productie/open-standaarden/
Versie 1.0 Extern
39/72
27 oktober 2006
Beoogde eindsituatie In de beoogde eindsituatie bestaat er een omgeving voor de kantoorautomatisering te creëren die volledig is gebaseerd op open standaarden voor communicatie en opslag van gegevens. Dit betekend dat het bestaande beleid binnen de Gemeente voortaan actief zal worden gehandhaafd. Gewerkt zal worden met de open standaarden die in Nederland zijn erkend. Deze standaarden zijn te vinden in CANOS, de Catalogus Nederlandse Open Standaarden.20 Dit betekend niet dat er uitsluitend gebruik gemaakt kan worden van open source software, de één verplicht niet het gebruik van de ander. Er is veel closed software die ook gebruik maakt van open standaarden. De procedures rondom gemeentebrede standaardisatie zijn binnen de gemeente nog niet vormgegeven, ook waar het thans nog gesloten standaarden betreft. Voor open standaarden geldt additioneel dat de Gemeente zich naar buiten actief moet opstellen voor wat betreft het adapteren en mede vaststellen van standaarden. Naarmate meer diensten en stadsdelen gebruik gaan maken van de Standaard Open Werkplek hoeft controle op de naleving van het gebruik van open standaarden overigens alleen nog plaats te vinden buiten het domein van de kantoorautomatisering. Kantoorautomatisering en interoperabiliteit Het is van belang om hier kort terug te komen op de functionele afbakening die is gemaakt in paragraaf 2.6.4. De relevante vraag luidt: is het wel logisch om de kantoorautomatisering te gebruiken als startpunt, waneer een van de belangrijkste doelstelling interoperabiliteit is. Zouden we ons niet beter kunnen richten op back-end systemen? Het antwoord is dat de kantoorautomatisering niet persé een onlogisch startpunt is: Door de kantoorautomatisering te baseren op open standaarden worden een aantal effecten bereikt: - Het leidt tot verhoogde interoperabiliteit bij documenten uitwisseling - het dwingt leveranciers van backoffice systemen open standaarden te ondersteunen (dwingt ook tot leveren / ondersteunen standaard interfaces) - het maakt leveranciers onafhankelijke keus van backoffice (deel) systemen mogelijk - het maakt mogelijk verschillende backoffice systemen te combineren. - (kantoorautomatisering interfaces kunnen ook gebruikt worden door andere backoffice oplossingen).
20
http://www.canos.nl
Versie 1.0 Extern
40/72
27 oktober 2006
4.2.3
Bedrijfscontinuïteit
Voordelen Meer standaardisatie en Shared service concept (óók voor niet-BRI-diensten) biedt de mogelijkheid tot meer stabiliteit. Open source biedt de mogelijkheid beheer duurzaam in te richten los van release, update en supportbeleid van softwareleverancier. Nadelen • Migratie naar de beoogde situatie vormt een grotere psychologische drempel dan een migratie naar nieuwe versies van MS Software. Neutraal/Onbekend • Het valt niet aan te tonen dat de beoogde situatie stabieler/minder stabiel, veiliger/minder veilig is dan de huidige situatie. • Het valt niet aan te tonen dat een migratie naar de beoogde situatie een grotere bedreiging vormt voor de bedrijfscontinuïteit dan een de migratie naar toekomstige versies van MS software.
Huidige situatie Bedrijfscontinuïteit geldt zowel als een baat en als een randvoorwaarde. De randvoorwaarde is dat de Gemeente geen onzekere avonturen aan gaat: te ambitieuze ICT-projecten met grote risico’s voor bedrijfskritische processen. De baat doelt op de mogelijkheid dat in de beoogde situatie minder uitval plaatsvindt en betere informatiebeveiliging. De huidige situatie rondom de kantoorautomatisering van de Gemeente is weliswaar weinig gestandaardiseerd, maar wordt als voldoende stabiel ervaren. Problematiek rondom informatiebeveiliging bij de Gemeente heeft thans meer te maken met werkprocedures en toegangbeveiliging dat met dan met lekken in de software zelf. Standaardisatie van werkplekken vindt voor de BRI-diensten (ca. 5.500 werkplekken) thans plaats in het Servicehuis ICT. De transformatie in het Servicehuis evenals het inrichten en aansluiten op de basisregistraties vergen veel van met name de BRI-diensten. Het maximale absorptie vermogen is volgens velen bereikt. Voor de deelnemende partijen aan het Enterprise Agreement met Microsoft geldt dat de huidige versies van Office en Windows nog een jaar na de releases van de opvolgers; Office 2007 en Vista, beide verwacht in 2007, onderhouden zullen worden. Beoogde eindsituatie De migratie voor een dienst of stadsdeel naar de Standaard Open Werkplek werpt vooralsnog een grotere mentale drempel op dan de migratie naar Vista en Office 2007 die op den duur gemaakt zal moeten worden. Onderzoek door het projectteam toont aan dat de migratie naar deze pakketten veel ingrijpender zal zijn dan de overstap tussen eerdere releases van Microsoft (zie ook hoofdstuk 8). Het valt momenteel niet aan te tonen dat een migratie naar de beoogde situatie een grotere bedreiging vormt voor de bedrijfscontinuïteit dan een de migratie naar toekomstige versies van MS software. Ook durft het projectteam geen stelling te nemen in de discussie of een werkplek op basis van open source stabieler of minder stabiel, veiliger of minder veilig is dan een MS werkplek. Voorstanders van open source stellen dat door het ontwikkelen van open source in wereldwijde communities beveiligingslekken veel eerder aan het licht komen. Tegenstanders geven aan dat deze stelling er van uitgaat dat iedereen in de community goed gezind is. De laatste groep vindt dat een open broncode juist de mogelijkheid biedt om de zwakke plekken van softwarepakketten op te sporen en uit te buiten. Het volgende krantenbericht bewijst nog eens dat de discussie over de veiligheid van open source versus closed source nog niet beslecht is: Webwereld, maandag 14 augustus 2006 'Openoffice.org even onveilig als MS Office' De Franse overheid haalt in een rapport hard uit naar Openoffice.org. Volgens het rapport is de beveiliging van het office-pakket onder de maat.
Versie 1.0 Extern
41/72
27 oktober 2006
"De beveiliging van Openoffice.org is onvoldoende", zo schrijven de onderzoekers van het Franse ministerie van Defensie in hun rapport genaamd 'In-depth analysis of the viral threats with Openoffice.org documents'. "Het pakket is nog steeds vatbaar voor vele potentiële malwareaanvallen." In het onderzoeksrapport beschrijven de onderzoekers vier proof-of-concept virussen die illustreren hoe macro's en templates kunnen worden misbruikt om een systeem binnen te dringen. De onderzoekers concluderen dan ook dat Openoffice.org niets veiliger is dan het veelbekritiseerde Office-pakket van Microsoft.
Een voordeel van de eindsituatie is dat deze uitgaat van een standaardisatieslag. Deze slag zal ook gemaakt worden in het Servicehuis ICT, maar voorlopig alleen voor de acht BRI diensten. Daarnaast kan men door de eis van het open karakter van de broncode in principe tot aan het einde der tijden gebruik maken van de software. Men is minder of niet afhankelijk van de beslissingen van een leverancier die besluit een bepaalde software applicatie (versie) niet meer te ondersteunen of door te ontwikkelen. Tevens is men gevrijwaard van het ergste geval dat een leverancier failliet gaat en de gemeente (bij voorbeeld via een ESCROW regeling) beschikking moet gaan krijgen over de bron van belangrijke software. Die bron is immers met open source software al in het bezit. Een gebruiker die beschikking heeft over de broncode van de software is voor de bedrijfscontinuïteit niet afhankelijk van een leverancier (zie ook het vorige punt). Indien men niet tevreden is met de diensten van een software leverancier, kan men de code oppakken en deze door een andere partij door laten ontwikkelen of beheren. Het zelfde geldt voor open standaarden. Steeds meer ontwikkelingen binnen de overheid op het gebied van ketenintegratie en basisregistraties maken gebruik van open standaarden. Het niet kunnen of willen voldoen aan open standaarden kan leiden tot isolatie en daardoor een risico zijn voor de bedrijfscontinuïteit.
4.2.4
Shared Services concept (efficiency en schaalvoordelen)
Voordelen De nieuwe omgeving realiseert mogelijk extra besparingen doordat niet-BRI-diensten versneld volgens het Shared Services concept werkplekken kunnen af nemen Wordt voldaan aan het uitgangspunt dat standaarden die in het SHI worden gebruikt voor de hele Gemeente gelden. Nadelen Transitie en transformatie naar Shared Services Concept is niet eenvoudig, (maar wel eenvoudiger dan tranche 1 in het huidige SHI) . Inspanning vanuit het SHI is vereist om te bewaken dat de Standaard Open Werkplek volgens hetzelfde aanbieding- en financieringsmodel wordt aangeboden als de standaard werkplek voor de startgroep.
Huidige situatie De Gemeente Amsterdam heeft gekozen voor het Shared Service Concept om besparingen te realiseren die op al deze gebieden betrekking hebben. Uit de Business Case SSC ICT21 is te lezen dat het SHI denkt een besparing van ongeveer 23% te kunnen realiseren tussen 2006 en 2009. De besparingen vinden plaats op de volgende gebieden:
21
Business Case SSC ICT – Onderdeel van het programma Shared Service Center ICT (zie blz.47).
Versie 1.0 Extern
42/72
27 oktober 2006
Hardware
Software
Datacomm unicatie
Eigen medewerk ers
Inhuur en uitbestedi ng
Schaalgrootte voordelen in servers, opslag en bandbreedte Schaalgrootte voordelen servicedesks Contractmangement voor licenties, uitbesteding en services Standaardisatie en uniformering van wekplekken, servers en andere hard- en software Éénmalige selectiekosten voor aanschaf van hardware en software Concentratie huisvestingskosten van servers e.d. voor zover niet uitbesteed Door concentratie van kennis minder inhuur Reductie complexiteit
ICT-architectuur
Rationalisatie van de ICT-processen Potentiële bronnen van besparingen ui de Business Case SSC ICT
Het SHI zal op grond van efficiency en beheersbaarheid argumenten in eerste instantie standaardiseren op producten van Microsoft. Dit standpunt is onderbouwd in een aparte brief van het SHI, die is bijgevoegd in bijlage 5. Op dit moment is het SHI volop bezig met de inrichting van de ondersteuning van de werkplekken voor de diensten BDA, DBGA, DMO, DPG, DWI, FBA en DAB. In deze fase van de ontwikkeling is het SHI nog niet gereed om andere diensten of stadsdelen te bedienen. Beoogde eindsituatie In de beoogde eindsituatie wordt de Standaard Open Werkplek op dezelfde wijze aangeboden als de ‘gesloten’ standaard werkplek binnenkort aan de BRI-diensten De beoogde eindsituatie biedt de nietBRI diensten en de stadsdelen de mogelijkheid om werkplekken af te nemen volgens het Shared Service Concept van het SHI, waardoor dezelfde type besparingen gerealiseerd kunnen worden.22 Overeenkomstig het SHI kunnen met de Standaard Open Werkplek consolidatieslagen worden gemaakt in de diversiteit van pakketten (kantoorautomatisering bestaat immers uit meer dan alleen Microsoft). Dit zal een grote besparingsbron zijn, die in paragraaf 4.3 zijn gekwantificeerd. In hoofdstuk 5 wordt voorgesteld om de ontwikkeling van de Standaard Open Werkplek op een andere locatie te doen plaatsvinden dan bij het SHI. Hoewel het SHI een belangrijke regisserende zal moeten spelen, moet in de ontwikkelfase ook de financiering gescheiden zijn van tranche 1 (en de Transformatie Concern Organisaties). In de constructie kan het SHI zich voorlopig blijven concentreren op de transformatie in het kader van tranche I. Wel is enige inspanning vanuit het SHI-management nodig om te bewaken dat de Standaard Open Werkplek volgens hetzelfde aanbieding- en financieringsmodel wordt aangeboden als de standaard werkplek voor de startgroep. Op deze wijze wordt de overname door het SHI van de nieuwe omgeving nadat deze zich in de praktijk bewezen heeft, aanzienlijk vereenvoudigd.
22
In de financiële onderbouwing in deze business case zal dan ook worden gerekend op basis van de huidige situatie met betrekking tot de kosten voor werkplekken binnen het SHI met aftrek van de 23% besparingen die beoogd worden door middel van de realisatie. Dit voordeel voor het beoogde scenario wordt hier als kwalitatieve baat neergezet omdat het een kwalitatief voordeel is dat het scenario de zelfde koers bewandeld als het SHI.
Versie 1.0 Extern
43/72
27 oktober 2006
De transformatie van tranche 1 van het Servicehuis toont aan dat het omschakelen naar een Shared services concept niet eenvoudig is. Het betreft per migrerende dienst of stadsdeel naast een technische migratie ook een reorganisatie en optimalisatie. De Standaard Open Werkplek heeft echter een aantal zaken voor op het huidige SHI: - de Standaard Open Werkplek is qua reikwijdte minder omvangrijk dan tranche 1; - de Standaard Open Werkplek wordt ontwikkeld onder regie van een bestaand servicehuis dat inmiddels belangrijke ervaring heeft opgedaan met het shared services concept; - bij de Standaard Open Werkplek wordt per dienst of stadsdeel gemigreerd op basis van een individuele kosten/baten-analyse en niet met meerdere diensten tegelijk; - bij de Standaard Open Werplek wordt eerst de standaard vastgesteld en vinden daarna migraties plaats in plaats van andersom.
4.2.5
Politieke wensen
Voordelen De beoogde eindsituatie komt tegemoet aan de uitgangspunten uit het amendement van Marres en de moties 2002, nr. 704 en nr. 848. De beoogde eindsituatie is een uitwerking van het Collegestandpunt (‘in de notitie Van ongeduld naar Actie’) dat het Servicehuis de standaard is of zal leveren voor de centrale stad en dat stadsdelen worden uitgenodigd zich aan te sluiten. Er wordt voldaan aan de richtlijnen van de Nederlandse Overheid (motie Vendrik) Nadelen De uitvoeringsrisico’s voor een omvangrijk en risicovol project met vele externe belangen vormt een groot politiek risico De benodigde investeringsbedragen verdringen uitgaven aan maatschappelijke urgente problematiek.
Huidige situatie Feitelijk is met de aanbieding van deze business case door het College van B&W aan de Raad het Amendement Marres op de letter uitgevoerd. Duidelijk mag echter zijn dat achterliggende wens van de Gemeente raad pas vervult is wanneer de in deze business case beoogde situatie ook daadwerkelijk is gerealiseerd. Onvrede van de Gemeenteraad met de huidige situatie was immers voldoende aanleiding om het amendement Marres unaniem aan te nemen. Bij het niet uitvoeren van het projectvoorstel in deze business case zal deze onvrede blijven bestaan. Daarnaast geldt dat de wens die het College heeft uitgesproken om alle diensten en stadsdelen aansluiten bij het SHI, bij het huidige tempo, niet op korte termijn ingelost kan worden. Beoogde situatie In de beoogde situatie vindt uitbreiding van het shared service concept versneld plaats, een wens die is geuit in het Collegestuk ‘Van ongeduld naar Actie: voorstellen voor versnelling’. Bovendien wordt tegemoet gekomen aan de uitgangspunten uit het amendement Marres en moties (2002, nr. 704 en nr. 848). Het project dat leidt naar deze situatie is echter niet zonder bestuurlijke risico’s. Zoals uit de persberichten in hoofdstuk twee was af te lezen, staan open source en open standaarden volop in de belangstelling. De marktbelangen zijn enorm en er wordt nauw gevolgd wat de Gemeente Amsterdam gaat doen. Daarbij komt dat de Gemeente geen onverdeeld positieve historie heeft als het gaat om de uitvoering van grote ICT projecten. Dit maakt dat het mislukken van een project als in deze business case wordt voorgesteld, een groot politiek risico in zich draagt. Daarbij geldt ook dat hoewel het projectvoorstel in deze business case (minimaal) kostenneutraal kan worden uitgevoerd, er aanzienlijke bedragen investeringbedragen nodig zijn. Deze zullen welliswaar worden terugverdiend, toch verdringen zij op korte termijn de uitgaven aan maatschappelijk urgente problematiek. Op langere termijn snijdt een overheid die niet durft te investeren in de efficiëntere bedrijfsvoering echter altijd in eigen vlees.
Versie 1.0 Extern
44/72
27 oktober 2006
4.2.6
Digitale duurzaamheid
Voordelen De kosten en inspanning voor het terughalen van gesloten digitale bestanden kunnen in de toekomst worden geminimaliseerd door het gebruik van de nieuwe omgeving waarvoor uitsluitend open standaarden gelden Nadelen Geen
Huidige situatie In de Archiefwet23 staat dat ‘Overheidsorganisaties moeten voldoen aan een aantal wettelijke verplichtingen ten aanzien van hun archiefvorming en -beheer. Ook digitale informatie valt onder de werking van deze regels.’, daarnaast wordt er vermeld dat ‘Er wordt beweerd dat het laatste decennium het slechtst gedocumenteerde tijdperk van de twintigste eeuw zal zijn. Informatie wordt steeds vaker digitaal vastgelegd. Hierbij zijn geen goede methoden voorhanden om deze informatie langdurig te bewaren. Het is dan ook nog maar de vraag of latere generaties kunnen nagaan wat in onze tijd is gebeurd. Het belangrijkste probleem bij het bewaren van authentieke digitale bestanden is dat van de technologische veroudering.’ Bij het hanteren van een lange bewaartermijn die wettelijk is vastgesteld doen zich vele problemen voor. Enerzijds is de achterwaartse comptabiliteit een belangrijk element (bestanden die met Word 95 zijn gemaakt kunnen in Word 2002 niet meer worden gelezen of oude e-mail in gesloten (Microsoft) formaten kunnen nu niet meer worden geopend door de huidige email programma’s, de vraag rijst vervolgens, hoe kunnen we digitale bestanden die we nu creëren in de toekomst nog openen? Dit probleem is de afgelopen jaren enorm toegenomen. Er zijn mogelijkheden zijn om onze digitale gegevens weer te lezen, maar deze zijn zeer kostbaar. Om voorbereid te zijn op de toekomst, dient er voor de opslag van gegevens gebruik gemaakt te worden van duurzame open formaten voor bestanden, e-mail, spreadsheets en nog belangrijker data die zich bevindt in databases. De huidige situatie binnen de Gemeente Amsterdam is op dit gebied zorgelijk te noemen. Het gebruik van closed software (met name Microsoft software) heeft geleid en leidt nog steeds tot een dagelijkse toename van digitale bestanden die in de toekomst maar met veel pijn en moeite geopend kunnen worden. Voor meer informatie over dit zeer actuele onderwerp zie de website van het Programma Digitale duurzaamheid op http://www.digitaleduurzaamheid.nl/. Beoogde eindsituatie In de beoogde eindsituatie zijn Open Standaarden verplicht. Zo wordt geborgd dat documenten te allen tijde geopend kunnen worden. Bij voorbeeld opslag van documenten in *.odf (Open Document Format) in plaats van in *.doc. De opslag van e-mail in XML in plaats van *.msg (Outlook Message Format). Zie ook paragraaf 4.2.2 over de interoperabiliteit van gegevens.
23
http://www.nationaalarchief.nl/archiefbeheer/archiefzorg/archiefwet/
Versie 1.0 Extern
45/72
27 oktober 2006
4.2.7
Imago Amsterdam-ICT Stad van Nederland
Voordelen Nauwe samenwerking met andere Gemeenten Geen dubbele ontwikkeling van software nodig voor andere overheden Belastinggelden vloeien via deze ontwikkelmethodiek terug naar de burgers in de vorm van software Ontwikkelingen worden uitgevoerd door Amsterdamse of Nederlandse bedrijven, belastinggeld blijft in Nederland Nadelen Samenwerking vereist extra inspanning
Huidige situatie Uit de verkenning van het projectteam is gebleken dat diverse grotere gemeenten (Groningen, Den Haag, Nijmegen, Haarlem) momenteel onderzoeken of het mogelijk is om op verschillende onderdelen te migreren naar software die voldoet aan het predicaat ‘open’. De aanpak verschilt per Gemeente, maar op vele aspecten kan van elkaar worden geleerd. Het projectteam heeft samen met het programma OSOSS (ICTU) een samenwerkingsverband tussen deze gemeenten geïnitieerd om ervaring te kunnen delen. Amsterdam heeft hierbij een bijzondere rol. Niet alleen is Amsterdam de grootste Gemeente van Nederland, tevens is Amsterdam op diverse gebieden van de elektronische overheid toonaangevend. Denk bijvoorbeeld aan Antwoord en www.amsterdam.nl). Hierdoor wordt er door veel gemeenten, maar ook door open source platformen en het bedrijfsleven, vol verwachting uitgekeken naar de softwarestrategie de Gemeente Amsterdam zal volgen. Amsterdam heeft zich als doel gesteld ICT Stad van Nederland te zijn. Met dit doel voor ogen kan de Gemeente een vooraanstaande rol vervullen in Nederland wanneer zij tot uitvoering over gaat van deze business case. De ervaringen en ontwikkelingen uit Amsterdam zullen zeer waardevol zijn voor andere gemeenten om te volgen. Beoogde eindsituatie Als in de toekomst maatwerk wordt ontwikkeld voor de Gemeente Amsterdam en deze voldoet aan de gestelde strategische software doelstellingen, dan zal deze software kenmerken hebben waardoor ze eenvoudig gedeeld kan worden met andere gemeenten, bedrijven en burgers. Zo heeft de Gemeente Den Haag vorig jaar de zogenaamde DigID gateway laten ontwikkelen die momenteel beschikbaar is voor iedereen op het uitwisselplatform.24 Dit stelt iedere Gemeente in staat om hun elektronische dienstverlening te koppelen aan de landelijke authenticatie voor burgers DigID zonder opnieuw kosten te hoeven maken voor deze module. Ook de Gemeente Amsterdam heeft al een dergelijk voorbeeld (Web-in-a-box WIAB), maar zou als ICT Stad van Nederland hier meer het initiatief in kunnen nemen.
4.2.8
Aansprakelijkheid
Voordelen • geen Nadelen • geen Neutraal • Er is geen verschil in de mate van aansprakelijkheid tussen open of closed source software. Het is altijd aan de Gemeente zelf om afspraken te maken over aansprakelijkheid met de dienstverlener die de software installeert, onderhoudt of beheert. Pogingen om wel bij de leverancier van software schade te verhalen beperken zich tot de wetgeving van het land waarin het geval zich afspeelt.
Een van de meest besproken aspecten met betrekking tot het gebruik van software is de aansprakelijkheid. In alle gevallen waar software wordt verkregen wordt aansprakelijkheid voor verlies uitgesloten door de leverancier. Een veel gehoord argument om alleen closed source software te gebruiken is dat er een leverancier aansprakelijk kan worden gesteld op het moment dat er iets mis gaat met de software. Dit is niet het geval. Een voorbeeld uit de ‘EULA’ End-User Licence Agreement van Microsoft “18. EXCLUSION OF INCIDENTAL, CONSEQUENTIAL AND CERTAIN OTHER DAMAGES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, PUNITIVE, INDIRECT, OR 24
http://www.uitwisselplatfrom.nl
Versie 1.0 Extern
46/72
27 oktober 2006
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF PROFITS OR CONFIDENTIAL OR OTHER INFORMATION, FOR BUSINESS INTERRUPTION, FOR PERSONAL INJURY, FOR LOSS OF PRIVACY, FOR FAILURE TO MEET ANY DUTY INCLUDING OF GOOD FAITH OR OF REASONABLE CARE, FOR NEGLIGENCE, AND FOR ANY OTHER PECUNIARY OR OTHER LOSS WHATSOEVER) ARISING OUT OF OR IN ANY WAY RELATED TO THE USE OF OR INABILITY TO USE THE SOFTWARE, THE PROVISION OF OR FAILURE TO PROVIDE SUPPORT OR OTHER SERVICES, INFORMATON, SOFTWARE, AND RELATED CONTENT THROUGH THE SOFTWARE OR OTHERWISE ARISING OUT OF THE USE OF THE SOFTWARE, OR OTHERWISE UNDER OR IN CONNECTION WITH ANY PROVISION OF THIS EULA, EVEN IN THE EVENT OF THE FAULT, TORT (INCLUDING NEGLIGENCE), MISREPRESENTATION, STRICT LIABILITY, BREACH OF CONTRACT OR BREACH OF WARRANTY OF MICROSOFT OR ANY SUPPLIER, AND EVEN IF MICROSOFT OR ANY SUPPLIER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.”25 Het is daarom een schijnzekerheid om uit te gaan van het verhalen van geleden schade door het gebruik van software zonder lange juridische procedures. Ook bij Open Source software is de aansprakelijkheid uitgesloten – uit de GPL (GNU General Public Licence) een van de meest gebruikte licenties voor Open Source software. “11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.”26 Er is daarom geen verschil in de mate van aansprakelijkheid tussen open of closed source software. Het is altijd aan de Gemeente zelf om afspraken te maken over aansprakelijkheid met de dienstverlener die de software installeert, onderhoudt of beheerd.
25
End-user Licence Agreement for Microsoft Software
26
GNU General Public Licence
Versie 1.0 Extern
47/72
27 oktober 2006
4.2.9
Intellectueel Eigendom
Voordelen: • De beoogde situatie biedt de Gemeente Amsterdam bepaalde rechten die vaak ten grondslag liggen aan de behoefte om het intellectueel eigendom in handen te krijgen. Zo mag men in de meeste gevallen zelf wijzigingen in de software aanbrengen. Neutraal: • Ook in de beoogde situatie zal de Gemeente Amsterdam niet het intellectueel eigendom van software verwerven.
Huidige situatie In de ICT inkoopvoorwaarden van de Gemeente Amsterdam staat het volgende over intellectueel eigendom (IE): “6.1 De IE-rechten berusten bij Opdrachtgever. Opdrachtnemer draagt, voor zover nodig, deze IErechten per de datum van het ontstaan ervan over aan Opdrachtgever. Opdrachtnemer zal, op eerste verzoek, steeds meewerken aan een nadere effectuering van de bedoelde overdracht. 6.2 Opdrachtnemer erkent dat door de in het eerste lid bedoelde overdracht, Opdrachtgever uitsluitend en volledige rechthebbende is geworden c.q. zal worden op de IE-rechten. De IE-rechten dienen onbezwaard te zijn. Voor zover (enig deel van) de IE-rechten niet zou(den) kunnen worden overgedragen, doet Opdrachtnemer hierbij afstand van het recht dit/deze in te roepen jegens Opdrachtgever. Opdrachtnemer is niet gerechtigd om (zelfstandig) gebruik te maken van de IErechten zonder voorafgaande schriftelijke toestemming van Opdrachtgever.” In de praktijk komt dit voor gelicentieërde software niet of nauwelijks voor. De Gemeente Amsterdam krijgt het intellectueel eigendom hooguit voor applicaties of maatwerk aan applicaties die zij zelf laat ontwikkelen. Beoogde situatie Op basis van het intellectuele eigendomsrecht, in het bijzonder het auteursrecht, kan de rechthebbende aan de licentienemer bepaalde rechten met betrekking tot de software verstrekken. Open source licenties
, zoals de GPL en BSD, geven de licentienemer in essentie het recht om de software aan te passen, te kopiëren en verder te verspreiden. Er kan bij Open Source licenties onderscheid worden gemaakt tussen zogenaamde copyleft en noncopyleft licenties. Copyleft licenties, zoals de GPL, bepalen dat de licentienemer verplicht is de broncode van de originele software en van aanpassingen mee te leveren als hij deze verder verspreidt. Indien verbeteringen aan de software worden verspreid, dan moeten deze dus ook weer “open” zijn. De voorwaarde kan worden beschouwd als een tegenprestatie voor de geboden vrijheden. Noncopyleft licenties, zoals de BSD- en Apachelicentie, verlangen deze tegenprestatie niet. Zij geven de licentienemer de vrijheid om zelf te bepalen onder welke voorwaarden hij de software en eventuele aanpassingen verder verspreidt. Daarom kan BSD-software relatief gemakkelijk worden opgenomen in closed software, zoals Mac OSX, maar ook worden geïntegreerd in GPL-software, zoals Linux. Closed source software Het intellectuele eigendomsrecht behoort in vrijwel alle gevallen tot de auteur van de software. In tegenstelling tot open source wordt echter het recht om aanpassingen aan de software door te voeren uitgesloten. De gebruiker van de software krijgt slechts het ‘gebruiksrecht’. Daarnaast is de mogelijkheid om aanpassingen aan de software door te voeren uitgesloten of voorbehouden aan de leverancier van de software. In het geval van closed software zorgt het intellectuele eigendomsrecht er voor dat men gebonden wordt aan de leverancier van de software. Als randvoorwaarde voor het beoogde scenario is opgenomen dat de software die wordt gebruikt het toelaat dat er wijzigingen plaats kunnen vinden op de broncode. Het intellectueel eigendom van deze aanpassingen komen, conform de ICT Inkoopvoorwaarden te liggen bij de Gemeente Amsterdam. De
Versie 1.0 Extern
48/72
27 oktober 2006
Gemeente dient voor de software die in de nieuwe omgeving gebruikt wordt vrij te zijn om elke leverancier te kiezen die zij wil om aanpassingen door te voeren.
4.3 Kwantitatieve kosten/baten van de uitvoering van het voorkeursscenario Aan 4 ICT-leveranciers is gevraagd een opgave te geven van de kosten voor een volwaardig alternatief voor Microsoft. Hierbij is als eis opgenomen dat de aangeboden software en het aanbiedingsconcept moet voldoen aan de 4 strategische softwaredoelstellingen, vertaald in de volgende concrete eisen: beschikbaarheid en overdraagbaarheid van de broncode en open standaarden. 3 van de 4 leveranciers hebben gereageerd.
Om te kunnen bepalen welke kwantitatieve kosten en baten zijn verbonden aan de uitvoering van het voorkeursscenario is in de markt een informatievraag uitgezet. De vraag is uitgezet bij twee huidige raamcontractanten (voor ICT-dienstverlening) van de Gemeente Amsterdam en twee overige leveranciers. 3 van de 4 leveranciers heeft informatie aangeleverd. De leveranciers blijven in dit stuk anoniem en zullen aangeduid worden als Leverancier I t/m III. Op basis van de functionaliteit en kostenposten die voor de huidige situatie is geïnventariseerd, is de leveranciers gevraagd hun prijzen op te geven. Zo is het mogelijk een vergelijking te maken. De kostenposten en functionaliteit zijn in een spreadsheet verwerkt die naar de 4 leveranciers is verzonden. De vraag aan de leveranciers werd als volgt geformuleerd: De Vraag Gelet op de achtergrond van het project en de bijgeleverde randvoorwaarden zoals besproken tijdens onze bijeenkomst en tevens samengevat in de informatie hierna, verzoek ik u de bijgeleverde spreadsheet zo volledig mogelijk in te vullen en daar waar nodig te voorzien van toelichting. De prijzen en aantallen die u hanteert mogen wel kortingen bevatten, die ontstaan door de levering van grotere hoeveelheden producten (graag wel nader specificeren door middel van een staffel), maar dienen ontdaan te worden van eventuele ‘extra’ aanbiedingen die u de Gemeente Amsterdam zou willen doen. De extra randvoorwaarden waaraan de informatie diende te voldoen zorgde ervoor dat de kosten opgaaf werd gedaan op basis van eisen die voortvloeien uit de strategische softwaredoelstellingen van de Gemeente Amsterdam: Randvoorwaarden waaraan gevraagde producten en diensten dienen te voldoen Voor de producten waarvan u een prijsopgave doet is een aantal aanvullende randvoorwaarden opgesteld. Deze betreffen naast de standaard ICT Inkoopvoorwaarden van de Gemeente Amsterdam (zie bijlage) een aantal aanvullende randvoorwaarden dat is opgesteld om te voorkomen dat uw aanbod het zelfde is als de huidige omgeving, maar dan voor een andere prijs. Aangezien het hier een alternatief voor de Microsoft omgeving betreft (zoals gespecificeerd in het amendement Marres) gelden de volgende aanvullende randvoorwaarden. In dien u afwijkt van de Amsterdamse ICT Inkoopvoorwaarden of de onderstaande extra randvoorwaarden vernemen wij graag op welke punten en wat de reden daarvoor is. De eisen hieronder zijn vrij strikt gesteld, maar zijn belangrijk voor de keuze van producten en de invulling van prijzen. (1) Open Standaarden: interoperabiliteit van systemen is één van de strategische doelstellingen op het gebied van software. Alle aangeboden software dient aan open standaarden te voldoen. Voor een definitie van Open Standaarden zie http://www.ososs.nl/index.jsp?alias=watisos Indien u hiervan afwijkt, dient u dit aan te geven. (2) Beschikbaarheid en overdraagbaarheid van broncode: eventueel in ESCROW (zie Inkoopvoorwaarden Artikel 6 lid 7). Leveranciersonafhankelijkheid staat in de business case voorop aangezien het amendement Marres hier om gaat, daarnaast is het gebruik van Open Source software door de Gemeente Amsterdam een belangrijk onderdeel van deze verkenning naar een alternatief platform voor werkplekken. Alle producten die u levert dienen daarom te voldoen aan het predicaat ‘Open Source’ en geleverd worden onder een van de
Versie 1.0 Extern
49/72
27 oktober 2006
goedgekeurde Open Source licenties (http://www.opensource.org). Indien om enige reden niet voldaan kan worden aan deze randvoorwaarde dient u te voldoen aan het bovengenoemde artikel of aan te geven onder welke condities het product wordt aangeboden (bijvoorbeeld, Adobe Acrobat, verschillende codecs en java). Op basis van een vergelijking van de huidige situatie en de kosteninformatie die van (3 van de 4) leveranciers is verkregen zijn dezelfde TCO berekeningen gemaakt als voor de huidige situatie. De analyse die in de volgende paragrafen volgt is gebaseerd op de cijfers die uit deze inventarisatie
4.3.1
Onderdelen van het TCO onderzoek
Werkgebied In paragraaf 2.6.3.2 is het werkgebied voor de business case afgebakend. Het functioneel/technische werkgebied ofwel het ICT domein betreft uitsluitend de desktop omgeving met daarbij de noodzakelijke toegang tot de applicaties. In deze berekening wordt bijvoorbeeld niet meegenomen: Netwerk aanschaf, aanleg en beheer. Hardware, software, upgrades en beheer benodigd voor primaire applicaties. Kosten voor stroom e.d. Werkplekkosten huidige situatie
Niet geschikt voor publicatie Werkplekkosten toekomstige situatie: Wij hebben 4 leveranciers gevraagd om de onderstaande informatie aan te leveren. 3 van de 4 leveranciers hebben gereageerd. De volgende categorieën zijn in de vraag opgenomen (1) Software: Deze categorie heeft betrekking op de aanschafkosten van software. In het geval van closed source software zijn dit voornamelijk de kosten welke verbonden zijn aan licenties voor het gebruik van de software. Binnen deze kostencategorie vallen ook de kosten die zijn verbonden aan updates (aanvullingen), upgrades (naar een nieuwe versie) en andersoortige uitbreidingen van de software. Benodigde software is gesplitst in aantallen en prijzen voor de client omgeving en voor de server omgeving. De Gemeente Amsterdam kent 3 typen werkplekken: a. Standaardwerkplek – dit betreft de basis werkplek die nodig is om werkzaamheden binnen de gemeente uit te voeren b. Functionele werkplek- een basiswerkplek aangevuld met pakketten die nodig zijn om een specifieke functie uit te oefenen c. Specialistische werkplek- een basiswerkplek met specialistische software die mogelijk andere eisen aan de hardware stelt De Gemeente Amsterdam heeft voor elk type werkplek een lijst met noodzakelijke functionaliteit opgesteld. N.B. We maken geen onderscheid in versies (bijvoorbeeld 8 versies van de zelfde software levert 1 functie op met een totaal in aantal en prijs van de 8 versies) Wij hebben de leveranciers gevraagd om een advies te geven over een geschikt open source alternatief voor elk van de genoemde functies. Daarnaast wilden we weten wat de jaarlijkse kosten zijn van de genoemde software. Wij hebben dezelfde vragen gesteld over de software die nodig is voor verschillende soorten servers: a. De basis server b. De servers voor kantoorautomatisering c. De servers voor de beheeromgeving d. De servers die nodig zijn voor toegang tot de specialistische software omgeving (2) Hardware: We willen in kaart brengen of de bestaande configuraties ook voldoen in een open source omgeving. Daarom werd geïnventariseerd welke configuraties de Gemeente Amsterdam nodig heeft en wat de aanschafprijs daarvan is. Uit dit onderzoek bleek dat de huidige hardware configuraties voldoen. Alleen bij leverancier I bleken investeringen
Versie 1.0 Extern
50/72
27 oktober 2006
noodzakelijk in extra zware servers. De kapitaalkosten van deze hardware investering zijn in de financiële business case opgenomen. De informatie die wij van de leveranciers ontvingen leverde geen nadere informatie op over een eventuele verlenging van de afschrijvingstermijn. Daarom hebben wij deze baten niet gekwantificeerd. Het is echter denkbaar dat tijden de toepassing van de Open Softwarestrategie lijkt dat het goed mogelijk is om de afschrijvingstermijn te verlengen en daarmee extra baten te realiseren. (3) Operationeel beheer: Hiervoor worden de kosten voor incident en probleem management geïnventariseerd zoals deze door ITIL worden gehanteerd bij een toenemend aantal werkplekken van 400, 2000, 8000, en 16000. De Gemeente Amsterdam wil graag in kaart brengen hoe de kosten voor operationeel beheer in een open source omgeving, zich verhouden tot deze kosten in de huidige omgeving. De Gemeente Amsterdam heeft aan drie leveranciers gevraagd om een inschatting te maken van de beheerskosten. De inschattingen van de leveranciers lopen sterk uiteen. Dit is ook opgenomen in de spreadsheet. Bovendien wijken de inschattingen van de leveranciers sterk af van de doelstelling van het SHI ten aanzien van het gewenste niveau van beheerskosten. Uit studies over het al dan niet verminderen van de beheerslasten door het gebruik van andere besturingssystemen wordt men niet wijzer. De studies zijn veelal gefinancierd door leveranciers van software en beweren altijd dat hun eigen systemen de minste beheerslast heeft. Er zijn daarnaast zo veel variabelen om rekening mee te houden dat elk bewijs eenvoudig weerlegd kan worden. Het projectteam heeft daarom besloten om geen besparingen op beheerskosten op te voeren als baat van de open softwarestrategie. Ook is er geen enkele aanleiding om aan te nemen dat de beheerskosten hoger moeten worden ingeschat dan thans het geval.27
4.3.2
Uitgangspunten en aannames bij de financiële analyse28
De volgende aannames zijn gedaan ten behoeve van de berekening van de financiële kosten en baten van de Open Softwarestrategie van de Gemeente Amsterdam De Gemeente Amsterdam hanteert het volgende rentepercentage en afschrijvingstermijn: Rentepercentage Afschrijvingstermijn in jaren
3,50% 3
27
Voorbeelden zijn ´Linux vs. Windows Total Cost of Ownership Comparison - An examination of the purchase and total operational costs of running an enterprise on Linux and Open Source software incomparison to Microsoft's Windows computer system platforms´ door Cybersource Pty. Ltd in 2002 in opdracht van de Australische staat Victoria pleit voor Linux. Een ander voorbeeld is ´ The Costs And Risks Of Open Source´ door Forrester Research (i.o.v. Microsoft) – waarin het tegendeel wordt beweerd. 28
Door: Dr. Diana Hoogeveen, Verdonck Klooster & Associates. 13 september 2006.
Versie 1.0 Extern
51/72
27 oktober 2006
Binnen de Gemeente Amsterdam is het totaal aantal werkplekken als volgt verdeeld over de standaard, functionele en specialistische werkplekken: Percentage standaard werkplekken Percentage functionele werkplekken Percentage specialistische werkplekken Totaal
30% 60% 10% 100%
Deze verdeling is tot stand gekomen aan de hand van een inschatting op basis van het aantal uitgegeven licenties voor respectievelijk – standaard, functionele en specialistische software. Het projectteam heeft de door leveranciers aangeleverde informatie op juistheid en volledigheid gecontroleerd en heeft toestemming gegeven om deze te gebruiken in de berekeningen in deze spreadsheet. De cijfers over de huidige situatie zijn aangeleverd door de Gemeente Amsterdam en zijn ontleend uit het document "Financiële Startpositie SSC ICT 1 januari 2006."
Aannames en vereenvoudigingen •
Geabstraheerd van beheerskosten
Passage niet geschikt voor publicatie • Onderhoudskosten In deze financiële business case wordt een tijdshorizon van 5 jaar bekeken. In deze business case bekijken we de invloed van de Open Softwarestrategie op de werkplekkosten. Dit betekent dat mogelijke extra onderhoudskosten aan de primaire applicaties, als gevolg van wijzigingen aan standaard softwarepakketten, niet zijn meegenomen in de berekeningen. Tijdens de migratie zal een inventarisatie moeten plaatsvinden van de noodzakelijke aanpassingen aan de primaire applicaties. Deze aanpassingen zijn afhankelijk van de gekozen technische oplossing. Op dat moment kan een raming gedaan worden van de mogelijke extra onderhoudskosten. • Migratiekosten De 4 leveranciers is gevraagd een inschatting te geven van de beheerslasten en migratiekosten die hun oplossing met zich meebrengt. De 3 responderende leveranciers konden geen concrete cijfers leveren over de migratiekosten omdat er te veel onbekende variabelen waren waarmee rekening gehouden dient te worden. Uit internationale studies over migraties naar open omgevingen is vrijwel onmogelijk om conclusies te trekken voor de migratiekosten die gepaard gaan met het in deze business case beoogde scenario. De meeste studies richten zich op de besparingen en niet op de kosten. Als de migratiekosten al in kaart zijn gebracht betreft het veelal situaties waarbij slechts enkele systemen of alleen de backend wordt gemigreerd. Geen van de studies geeft een beeld over het realiseren van het in deze business voorgestelde scenario waarbij een aparte omgeving wordt gerealiseerd. De vraag welke kosten in zo’n geval zijn verbonden aan de migratie van data, het testen en de opleidingen van gebruikers blijft onbeantwoord. Omdat de migratie kosten een – weliswaar eenmalig – maar toch aanzienlijke financiële factor zullen zijn, wordt in deze business case een extreme aanname gedaan: alle netto-opbrengsten die binnen de tijdshorizon van vijf jaar resteren, worden ingezet om de migratiekosten te dekken.
Passage niet geschikt voor publicatie Overige berekeningen en data
Versie 1.0 Extern
52/72
27 oktober 2006
De individuele berekeningen van de leveranciers zijn opgenomen in bijlage 2. Op basis daarvan zijn, eveneens in de bijlage opgenomen uitgebreide berekeningen gemaakt van: 1. Berekening van de jaarlijkse besparing op de werkplekkosten nadat 4800 basiswerkplekken zijn uitgerold. 2. Berekening van de jaarlijkse besparing nadat 4800 basiswerkplekken en 9600 functionele werkplekken zijn uitgerold en 3. Berekening van de jaarlijkse besparing op de werkplekkosten nadat 16.000 werkplekken zijn uitgerold in de OS omgeving.
4.4 Conclusies kwantitatieve kosten en baten Voordelen • Zelfs in de meest conservatieve berekening worden de investeringen in de standaard open werkplek in 4 á 5 jaar terugverdiend • De standaard werkplek wordt aangeboden via het shared services concept waardoor de terugverdientijd nog kan worden verkort Nadelen • De terugverdientijd is gebaseerd op het behalen van voldoende volume. Het aantal gemigreerde open basis werkplekken, dat nodig is om de investering van €300.000 (zie paragraaf 1.9 beslispunt 3) terug te verdienen in 5 jaar, is 700.29 • Voor een volwaardig alternatief voor Microsoft dienen, voor een terugverdientijd van 5 jaar, 9500 werkplekken (waarvan 30% basis, 60% functioneel en 10% specialistisch) te worden gemigreerd.8 • Als men naast basiswerkplekken ook functionele werkplekken (meest voorkomend) wil ontwikkelen is voor een terugverdientijd van 5 jaar een volumeopbouw van 4.800 basis werkplekken nodig over dezelfde periode Neutraal • De berekening is gedaan op basis van de opgaaf van 3 leveranciers en moet in de praktijk op een aantal punten getoetst worden. • Hoewel uitspraken gedaan kunnen worden over kostenneutraliteit zijn er te veel onbekende om uitspraken te kunnen doen over het de financiële planning, hiervoor ontbreekt met name het totaaloverzicht over de softwarecontracten en het verloop van de volumegroei
Bij de kwantitatieve opbrengsten van de invoering van het voorgestelde scenario kunnen horen de volgende opmerkingen: 1. Er is in deze business case ingestoken op een conservatieve berekening. Er is gerekend met de getallen die zijn geprognosticeerd door het SHI in 2009, namelijk met aftrek van 23% besparingen die het SHI denkt te gaan realiseren door de invoering van het shared service concept. 2. De beheerslasten voor deze analyse zijn gelijkgetrokken met de beheerslasten van het SHI in de toekomstige situatie, dus met aftrek van de voorgenoemde 23%. Hoewel twee van de drie leveranciers forse besparingen lieten zien op de beheerslasten en personele kosten, werden deze door het projectteam onvoldoende aannemelijk bevonden. 3. Een mogelijke besparing op de hardwarekosten als gevolg van een verlengde afschrijvingstermijn is niet opgenomen in de business case omdat deze moeilijk te kwantificeren is en niet hard gemaakt kan worden dat de afschrijvingstermijn voor hardware, die nu vast ligt op 3 jaar, daadwerkelijk verlengd kan worden. Benodigde aantal werkplekken om het gevraagde budget terug te verdienen in 5 jaar De volledige onderbouwing van alle berekeningen is opgenomen in bijlage 2. Op basis van deze aannames en berekeningen wordt hieronder een tweetal conclusies getrokken. De eerste conclusie richt zich op het terugverdienen van de gevraagde investering van €300.000 die gevraagd wordt als initiële investering voor de uitvoering van deze business case uitgaande van een terugverdientijd van 5 jaar. Hoe veel werkplekken dienen er dan omgezet te worden naar de open omgeving om deze business case terug te verdienen?
29
Indien er minder werkplekken beschikbaar komen om deze business case uit te voeren dan betekend het niet dat de business case niet haalbaar is, maar dat de termijn waarop er wordt terugverdiend langer wordt.
Versie 1.0 Extern
53/72
27 oktober 2006
Benodigd aantal werkplekken om de gevraagde investering van €300.000 (zie hoofdstuk 5) in deze business case terug te verdienen: 1. Het aantal gemigreerde open basis werkplekken, dat nodig is om de investering van €300.000 terug te verdienen in 5 jaar, is 700. De baten gaan pas in werking treden in het jaar nadat de werkplek is geïnstalleerd. 2. Na deze periode van vijf jaar wordt op basis van deze 700 werkplekken er jaarlijks ongeveer €140.000 bespaard. Mochten de migratiekosten hoger uitvallen dan zal de terugverdientijd langer worden. 3. Indien er minder werkplekken beschikbaar komen om deze business case uit te voeren dan betekend het niet dat de business case niet haalbaar is, maar dat de termijn waarop er wordt terugverdiend langer wordt.
Onderbouwing niet geschikt voor publicatie
Versie 1.0 Extern
54/72
27 oktober 2006
5 Outline Projectvoorstel BOSS: van huidige naar beoogde situatie Onderstaand projectvoorstel is een globaal voorstel en dient verder gedetailleerd te worden in een plan van aanpak voor de start van het project.
5.1 Aanbieder: Servicehuis ICT Zoals in paragraaf 4.1 is aangegeven is het de bedoeling de Standaard Open Werkplek aan te bieden onder de vlag van het SHI. Een voorwaarde hierbij is dat het SHI hiervoor de benodigde capaciteit krijgt. Momenteel is men immers volop bezig met de transformatie in tranche 1 en is focus geboden. Het SHI zal op grond van efficiency en beheersbaarheid argumenten in eerste instantie standaardiseren op producten van Microsoft. Dit standpunt is onderbouwd in een aparte brief van het SHI, die is bijgevoegd in bijlage 5. De Standaard Open Werkplek wordt als een aparte omgeving aangeboden vanaf één fysieke locatie met centraal beheer, eenmalige selectie van hard- en software, centraal contractmanagement, concentratie van kennis, centralisatie van servicedesk etc. De ontwikkeling en wellicht ook de aanvankelijke beheersomgeving van de Standaard Open Werkplek zal een andere startlocatie kennen dan het SHI. Dit hangt samen met de focus die het SHI momenteel moet leggen bij de transformatie in het kader van tranche 1 en met de kennis, kunde en bereidheid met betrekking met open omgevingen die momenteel op andere locaties sterker aanwezig is dan bij het SHI. Management aandacht is nodig vanuit het SHI om te bewaken dat de Standaard Open Werkplek vanuit de startlocatie wel volgens hetzelfde aanbieding- en financieringsmodel wordt aangeboden als de standaard werkplek voor de startgroep (de acht BRI diensten). Dit is nodig om de overname door het SHI van de Standaard Open Werkplek, bij gebleken geschiktheid, zo eenvoudig mogelijk te maken. Uiteindelijk is het vanuit efficiency en beheersoverwegingen logisch dat er één omgeving resulteert. Tot die tijd biedt het in deze business case beschreven scenario de niet-BRI diensten en de stadsdelen in elk geval de mogelijkheid om werkplekken af te nemen volgens het shared services concept van het SHI, waardoor dezelfde type besparingen gerealiseerd kunnen worden als thans beoogd voor de BRI-diensten.
5.2 Startlocatie: Dienst Wonen Hierboven is beargumenteerd waarom een andere startlocatie voor de Standaard Open Werkplek voor de hand ligt. Een meer positief argument is dat veel meters gemaakt kunnen worden waneer beheerders worden ingeschakeld die al ervaring hebben met open source software in een productieomgeving. Er is een mogelijkheid voor een alternatieve startlocatie gevonden die op meerdere terreinen een zogenaamde ‘win-win’ situatie oplevert. In onderling overleg is de mogelijkheid ontstaan om een project uit te voeren (hierna te noemen project BOSS Businesscase Open Softwarestrategie) om de voorgestelde omgeving voor de toekomstige situatie (zie paragraaf 3.3.1) fysiek en functioneel in te richten bij de Dienst Wonen. Dit betekent dat er onder regie van het SHI (en CO/IB) wordt gewerkt aan een omgeving die als eerste bij de Dienst Wonen wordt gerealiseerd. Hiervoor zal een aparte omgeving worden ingericht (een zogenaamde ‘greenfield’ omgeving). Als bijlage bij deze business case is een overeenkomst opgenomen tussen de Bestuursdienst en de Dienst Wonen waarin uitgegaan wordt van deze Dienst als de startlocatie voor het project gaat dienen. Deze Dienst is benaderd omdat zij al zeer veel ervaring op hebben gedaan met hetgeen door dit project als mogelijk alternatief wordt gezien voor Microsoft in hun huidige kantoorautomatiseringomgeving. De Dienst Wonen heeft momenteel alleen nog op de werkplekken zelf Microsoft software draaien en incidenteel aan de achterkant.
Versie 1.0 Extern
55/72
27 oktober 2006
Door gebruik te maken van de ervaring van deze Dienst en de beoogde aparte omgeving daar te implementeren hoopt het project BOSS een aantal voordelen te behalen, namelijk: Voordelen - Vanaf de start van de ‘open’ omgeving voor de Gemeente Amsterdam is er een gegarandeerde afzet is voor de open omgeving (ongeveer 300-400 werkplekken), gelijk aan het aantal werkplekken van de Dienst Wonen. - Er is een fysieke omgeving waarop de ‘open’ omgeving kan draaien. Het SHI heeft voorlopig nog geen datacentrum, wat betekend dat de e.e.a. bij externen gehost moet worden. - Er hoeft aanvankelijk niet of slechts beperkt te worden geworven voor beheerders die de ‘open’ omgeving gaan beheren. Er kan gebruik worden gemaakt van reeds aanwezige kennis bij de Dienst Wonen. - De ‘open’ omgeving komt aanvankelijk los te staan van het SHI en het afzetgebied hoeft niet hetzelfde afzetgebied te hebben als het SHI. Voor de open omgeving kunnen eigen criteria gehanteerd worden voor toetreders. - De ontwikkeling van de open omgeving leidt het SHI niet af van alle zaken die nog moeten gebeuren in het kader van tranche-I. Nadelen - De ontwikkelingen die plaats vinden in het kader van het project BOSS bij dienst Wonen dienen op termijn opgenomen te worden in het SHI om aangeboden te kunnen worden aan alle Diensten en Stadsdelen. - Afstemming met de Dienst Wonen vergt extra inspanning, daarbij gaat het niet alleen om de waardevolle input de Dienst Wonen kan leveren vanuit de eigen praktijksituatie, expertise die anders moet worden ingehuurd, maar ook over afstemming over het moment en de wijze waarop de open werkplek op een moment in de toekomst gedistribueerd kan worden aan andere diensten en stadsdelen in de stad. - De kosten voor de migratie van de Dienst Wonen naar de ‘open’ front-end, zullen voor een deel door het project worden gedragen.
5.3 Financiering van het project Een belangrijk onderdeel van de voortgang en uitvoerbaarheid van het project is de wijze van financiering. In Fase A (zie de volgende paragraaf) zal gestart worden met de praktijktoets van de bevindingen uit deze business case. Gedurende deze fase zal nader worden uitgewerkt hoe het project gefinancierd gaat worden. Door een beter inzicht te krijgen in de looptijden van bestaande contracten zal achterhaald worden vanaf wanneer een gemigreerde werkplek daadwerkelijk rendement op gaat leveren. Ook zal onderzocht worden hoe decentrale opbrengsten (door bijvoorbeeld de werkplek bij een dient of stadsdeel uit te rollen) terug kunnen vloeien naar het project. Zoals eerder is aangegeven is het behalen van voldoende volume aan gemigreerde werkplekken een cruciaal onderdeel van de uitvoerbaarheid van de business case. Met oog op de Amsterdamse cultuur en het feit dat door lopende ICT-operaties in de stad het maximale absorptievermogen van een aantal diensten bereikt is, is het verstandig om in eerste instantie op vrijwillige basis te peilen of het vereiste volume voor de realisatie van de beoogde eindsituatie kan worden bereikt. Er zijn echter, bij gebrek aan benodigd volume, een aantal middelen beschikbaar om het volume te beïnvloeden, namelijk: - het opnemen van extra eisen en randvoorwaarden in de ICT Inkoopvoorwaarden van de Gemeente en deze verplicht stellen om na te leven - het verplicht stellen van de open werkplek, hierbij zijn twee varianten denkbaar: met of zonder verplichte datum, in het laatste geval mag een dienst of stadsdeel zelf bepalen waneer ze gebruik gaat maken van de standaard open werkplek. - dit kan in combinatie met en een positieve of negatieve financiële prikkel.
Versie 1.0 Extern
56/72
27 oktober 2006
• •
Negatief: het opzeggen van het Raamcontract met Microsoft zodat men geen gebruik kan maken van lagere prijzen voor gesloten software. Positief: een bijdrage leveren aan het verlagen van de kosten voor ICT op het moment dat de open werkplek wordt gekozen (prijssubsidiëring).
In fase A van het project zullen deze instrumenten nader worden onderzocht en uitgewerkt zodat, wanneer blijkt dat op basis van vrijwilligheid onvoldoende volume wordt gegeneerd, het College een aantal concrete maatregelen kan worden gepresenteerd.
5.4 Aanpak In de volgende paragrafen worden de contouren van het project BOSS verder uitgezet. De budgetaanvraag in deze business case dient als investering in het project BOSS en is daarom direct gerelateerd aan de kosten van dit project (zie paragraaf 5.5).
5.4.1
Globale aanpak project BOSS
Globale fasering, migratiekoeten en opbrengsten van het project BOSS
De fasering voor het project BOSS wordt voorgesteld in drie fases waarvan de eerste twee gerealiseerd worden tot oktober 2008, wanneer de Gemeenteraad een besluit neemt op basis van de aanwezigheid van een alternatief over het Raamcontract met Microsoft. Grofweg zal in FASE A tot de zomer van 2007 gewerkt worden aan de realisatie van de generieke omgeving waarin als eerste de Basis Werkplek wordt gerealiseerd. 1. Er dient een generieke inrichting te komen voor de drie typen werkplekken met een beheeromgeving. De drie werkplekken zijn als volgt gedefinieerd; a. Standaard - e-mail, kalender (agenda) en tekstverwerkingssuite, het creëren van pdf bestanden en aansluiting met printers en het netwerk met dataopslag. Ook dient er op het netwerk ingelogd te kunnen worden om bestanden van anderen te openen. Daarnaast dient met een browser de benodigde intranet en internet pagina’s bekeken kunnen worden. b. Functioneel - de standaard werkplek aangevuld met software of toegang tot applicaties die nodig zijn om een specifieke functie uit te kunnen voeren. Het gaat hier om functionaliteit als projectmanagement software, teken pakketten, HTML editors, beeld manipulatie of cd’s branden en systemen zoals Andreas, e-learning omgevingen e verschillende primaire systemen.
Versie 1.0 Extern
57/72
27 oktober 2006
c.
2.
3.
4. 5.
6.
Specialistisch – een werkplek waarop software beschikbaar is of toegang verleend wordt tot pakketten die afwijkende hardware eisen met zich meebrengen (grotere schermen of meer processor capaciteit), denk bijvoorbeeld aan grote teken pakketten. Voorgesteld wordt om deze drie werkplekken eerst voor de Dienst Wonen te realiseren met de bijbehorende backend om vanaf één fysieke locatie het beheer en distributie werkzaamheden uit te kunnen voeren. De initiële inrichting van de werkplekken staat los van de huidige omgeving. Na de installatie van de werkplekken en het inrichten van het beheer, dient de basis werkplek gerealiseerd te worden. Hierbij worden nauwlettend de geldende randvoorwaarden getoetst. Dit is het eerste deel van het ontwikkel en onderzoekstraject dat nodig is om een helder beeld te krijgen of het alternatief voor Microsoft ook daadwerkelijk mogelijk is. Bij de Dienst Wonen wordt een inventarisatie gedaan van de functionaliteit die wordt gebruikt door elke medewerker. De medewerkers worden ingedeeld naar het type werkplek dat zij nodig hebben, een standaard, functionele of specialistische werkplek. De verwachting is dat een deel van de medewerkers zijn of haar werkzaamheden kan verrichten met de standaard werkplek en dat een deel van de medewerkers die in aanmerking komen voor een functionele werkplek ook meteen met de standaard werkplek kunnen werken aangevuld met software die standaard beschikbaar is, mits deze voldoen aan de eisen. Veel functionele software is immers al in een ‘open’ variant beschikbaar. Bij gebleken geschiktheid per type werkplek kunnen medewerkers van de Dienst Wonen als eerste vanuit hun huidige omgeving gemigreerd worden naar de nieuwe omgeving. Het geschikt maken van de (infrastructuur onder de ‘open werkplek’ voor distributie in de stad via een Shared services concept). Dit betekent dat het beheer, de hardware en de netwerktoegang (incl. beveiliging) geschikt gemaakt moet worden voor het bedienen van een veelvoud van werkplekken dan dat van de Dienst Wonen. Het geschikt maken van de organisatie voor distributie van de ‘open werkplek’ via een Shared services concept. Het leveren van werkplekken aan een groot deel van de gemeente zal nooit een kerntaak worden van de Dienst Wonen, de vraag is dus hoe en vooral waar de ‘open werkplek’ wordt beheerd, zodra andere diensten hiervan gebruik willen maken.
Voor een opsomming en planning van de activiteiten zie Bijlage 3
5.5 Benodigde initiële investering voor FASE A Uitgaande van een positief besluit over de businesscase “Open Softwarestrategie Amsterdam” zal in 2007 vormgegeven moeten worden aan een omgeving waardoor een zekere mate van leveranciersonafhankelijke softwarekeuze mogelijk wordt en waarmee aan de doelstellingen: budget neutraal, bedrijfscontinuïteit en interoperabiliteit voldaan wordt. De kosten voor deze omgeving zijn in €: Projectkosten 160.000 Inrichting en omgeving 30.000 Apparatuur 30.000 Programmatuur 5.000 Extra capaciteit 75.000 Nadere specificatie van de initiële kosten FASE A Hardware - kosten € 30.000 De minimaal benodigde open omgeving zal bestaan uit een 3 tal die gezamenlijk de KA-Backoffice taken afhandelen: • File opslag / printen / anti malware • Unified messaging / e-mail • Communicatie & toegang / firewall / spamfilter / anti malware / vpn En een aantal desktop systemen voor generieke inrichting: • Systeembeheer console • Bouw / test image basis systeem
Versie 1.0 Extern
58/72
27 oktober 2006
• • • • •
Tonen basis systeem Bouw / test image functioneel systeem Tonen functioneel systeem Bouw / test specialistisch systeem Tonen specialistisch systeem
Inrichting omgeving - kosten € 30.000 Dit geheel moet gehuisvest, ingericht, aangesloten en toegankelijk worden gemaakt. Dit vereist ruimte en toegang tot een systeemruimte voor de servers, gemeubileerde kamer(s) om de desktop systemen te kunnen plaatsen en de bijbehorende infrastructurele voorzieningen. Programmatuur - kosten € 5.000 Hoewel de te gebruiken software Open Source is en daar dus geen licentiekosten aan verbonden zijn, zullen we zeker in het begin wanneer nog niet alle benodigde kennis aanwezig is, gebruik moeten maken van al ingerichte voorgeconfigureerde programmatuur waarbij het up-to-date houden van die programmatuur uitbesteed wordt. Vandaar dat er ook voor programmatuur nog kosten zijn opgenomen. Extra capaciteit - kosten € 75.000 Daarnaast is er een inschatting gemaakt van de benodigde extra capaciteit van medewerkers om het geheel te kunnen opbouwen, inrichten en te beheren. Deze medewerkers worden gaande weg opgeleid en kunnen hun opgedane kennis en ervaring delen met anderen. Project - kosten €160.000 Ten slotte de projectkosten. Vooral in het begin zal externe inhuur (kennis en vaardigheden) noodzakelijk zijn. Het gaat hier met name om inhuur van expertise op het gebied van Open Source software en open standaarden, evenals de financiële expertise die nodig is om de geldstromen tussen het project en de deelnemende organisaties te managen. Daarnaast dient ook de business case bewaakt en verder aangescherpt te worden in het kader van de het aanstaande Raadsbesluit in 2008. De besparing die met dit project worden beoogd dienen niet weg te vloeien naar extra werkzaamheden. Ten slotte dient er tijd en daarom budget gereserveerd te wordt voor het opstellen en uitzetten van de aanbesteding die mogelijkerwijs nodig is om de benodigde dienstverlening uit de markt te kunnen betrekken. Als de huidige raamcontractanten van de Gemeente onvoldoende kunnen leveren, dan is het misschien noodzakelijk om een aanbesteding te doen. Gaande weg zal de kennis overgedragen worden en kan deze inhuur geminimaliseerd worden. Totale kosten - € 300.000
5.5.1
Niet meegenomen in de initiële kosten
Geschat wordt dat met deze middelen voorzien kan worden in een minimale inrichting van de aparte omgeving voor de realisatie van de drie typen desktops met de benodigde functionaliteit. In deze kosten zijn niet meegenomen: • De kosten voor het inventariseren van systemen waartoe toegang geboden dient te worden. Deze systemen vallen uiteen in 3 categorieën: (a) systemen waar via een browser direct toegang kan worden verleend en die W3C compliant zijn dus opereren in een Firefox Browser (b) systemen waartoe toegang kan worden geboden via andere technische wegen, bijvoorbeeld een terminal server (c) systemen waar wijzigingen aan dienen te worden verricht alvorens zij aangeboden kunnen worden via de nieuwe omgeving • De kosten voor extra hard- en software die nodig zijn voor het bieden van toegang tot systemen die in categorie (b) vallen. • De kosten voor wijzigingen aan systemen die in categorie (c) vallen
Versie 1.0 Extern
59/72
27 oktober 2006
• • • • •
5.5.2
De kosten voor de inventarisatie van functionaliteit per gebruiker (om te bepalen hoeveel een welke gebruikers met een basis, functionele of specialistische werkplek uitgerust kunnen worden) De kosten voor de daadwerkelijke migratie van gebruikers naar de nieuwe omgeving datamigratie De kosten voor gebruikerstesten en gebruikersopleidingen De kosten voor advies van externen over de verdere invulling en berekening van deze business case ten behoeve van de het advies aan de Gemeenteraad inzake het Raamcontract met Microsoft Inventariseren op welke wijze de migratie plaats gaat vinden voor de hele Gemeente en welke kosten daarmee gemoeid zijn
Herinvestering van baten
Het is algemeen bekend dat de kosten voor de baten uit gaan. Het project BOSS zal een initiële investering nodig hebben van rond de € 300.000, -. De enige manier om deze kostenneutraliteit te bereiken is om de mogelijkheid te creëren gerealiseerde besparingen terug te laten vloeien naar het project. Op die manier kunnen de initiële kosten worden terugverdiend en nieuwe ontwikkelingen in gang worden gezet (bijvoorbeeld migratie van gebruikers naar de nieuwe omgeving of het verlenen van toegang tot complexe gesloten applicaties en bestaande legacy systemen). Zie ook randvoorwaarden en uitgangspunten in hoofdstuk 2.
Versie 1.0 Extern
60/72
27 oktober 2006
6 Risico’s en maatregelen 6.1 Risico’s indien de business case niet wordt uitgevoerd Van onderstaande risico’s is de maatregel veelal het uitvoeren van de Business Case: Geen alternatief in 2008 Indien de business case niet wordt uitgevoerd is het niet mogelijk om in 2008 een onderbouwde keuze voor een alternatief voor te leggen aan de Gemeenteraad. Getracht is om in dit document aan te geven dat de kwalitatieve baten voor de Gemeente Amsterdam voldoende aanwezig zijn om verdere stappen te zetten met het project BOSS. De mogelijke besparingen die worden voorzien – zelfs met alle kantekeningen en aannames die hierbij zijn geplaatst – zorgen ervoor dat het waardevol is om het project BOSS uit te voeren en de mogelijkheden voor een alternatief verder te onderbouwen. Niet uitvoeren betekent geen uitvoering geven aan de Motie Vendrik Uitvoering geven aan de motie Vendrik (zie ook hoofdstuk 2) wordt verder naar achteren geschoven door de Gemeente Amsterdam, temeer omdat zij een voorbeeldfunctie kan hebben richting andere gemeenten als ICT Stad van Nederland op dit gebied. Er wordt dan geen gehoor gegeven aan het eigen- en overheidsbeleid op het gebied van open standaarden en de mogelijkheden van Open Source software als alternatief worden niet onderzocht. Slechts beperkte leveranciersonafhankelijke keuze voor software mogelijk Door de uitvoering van de business case wordt voor één omgeving de hoogst haalbare randvoorwaarden voor de selectie van software van toepassing. Randvoorwaarden die er voor zorgen dat de meerdere leveranciers aan wensen en eisen van de Gemeenten met betrekking tot die software kunnen voldoen – niet alleen de ontwikkelaar van de software. Concurrentie in de markt komt zowel de prijs als de kwaliteit van software ten goede. Op dit moment is het alleen mogelijk om een keuze te maken tussen verschillende leveranciersgebonden pakketten. Op het moment dat de keuze is gemaakt gaan de voordelen van concurrentie verloren.
6.2 Algemene knelpunten uitvoering business case Knelpunten hinderen of blokkeren de voortgang van de realisatie en/of de uitvoering. Thans zijn de volgende potentiële knelpunten geïdentificeerd: o Terughouding vanwege negatieve ervaringen met grootschalige automatiseringsimplementaties en/of gecentraliseerde serviceverlening; o Twijfels over de functionaliteit van de software en/of de beheersbaarheid resp. realiseerbaarheid van het ingrijpende veranderingsproces. o Twijfels over het absorptievermogen van de organisatie Met deze knelpunten moet rekening worden gehouden tijdens de realisatie van de werkplek en de uitrol bij de eerste dienst(en).
6.3 Risico’s bij uitvoering van de business case Gezien het feit dat de inrichting van een Open Softwarestrategische omgeving binnen het SHI concept zeer veel lijkt op de inrichting van het SHI zelf is ervoor gekozen de risico’s en maatregelen parallel te laten lopen met de Business Case SSC ICT. De maatregelen die zijn getroffen om deze risico’s aanvaardbaar te maken komen overeen, maar dan gerelateerd aan de nieuwe omgeving. Toegevoegd aan de knelpunten en risico’s is het element dat er misschien twijfels bestaan over, of onvoldoende kennis is van Open Software. Weggenomen zijn de twijfels of risico’s met betrekking tot het Shared Service Concept, gezien het feit dat deze worden gemanaged door het SHI. Risico’s vormen een bedreiging voor het veranderingsproces en/of voor het beoogde eindresultaat. Er zijn vier soorten risico’s te onderscheiden: algemene bedrijfsrisico’s, bestuurlijke risico’s, projectrisico’s en inhoudelijke risico’s. Het algemene risico: discontinuïteit van de dienstverlening. De ICT is een vitaal onderdeel van de
Versie 1.0 Extern
61/72
27 oktober 2006
bedrijfsvoering. Zo kan een slecht functionerende werkplek verregaande gevolgen hebben voor de Gemeente Amsterdam. Het bestuurlijke risico: onvoldoende slagkracht (daadkracht & vastberadenheid) om vlot tot besluitvorming te komen, het ontbreken van de bereidheid om in openheid naar oplossingen te zoeken, sterke sturing op individuele agenda’s. Het projectrisico: inadequaat projectmanagement (planning, kwaliteit van de projectmedewerkers, projectervaring etc.). De beschikbaarheid van voldoende expertise op het gebied van de gekozen software is een belangrijke factor voor het succes van de werkplek en het halen van de beoogde planningen. Het inhoudelijke risico: onvoldoende inhoudelijkheid (bijvoorbeeld: architectuurkeuzen, technologiekeuzen, ervaring met de werkwijze etc.) Vanuit deze vier invalshoeken zijn onderstaande risico’s geïdentificeerd.
6.3.1
Algemene risico’s
ID
Risico
Kans
Impact
Maatregel
Verantwoordelijkheid
1.
Te grote ambities: teveel tegelijk, te hoog tempo
Med
Groot
Geen wijzigingen van scope en tijdsplanning gedurende de uitvoering van het project
Stuurgroep deelnemende dienst(en), Projectgroep BOSS
2.
Oplopende onrust
Med
Groot
Planning van de communicatie / Open communicatie
Stuurgroep deelnemende dienst(en), Projectgroep BOSS, Projectleiding
Vroegtijdige en intensieve contacten met betrokken medewerkers Temporiseren van de verandering 3.
4.
5.
6.3.2
Onvoldoende vermogen c.q. bereidheid tot samenwerking
Med
Onvoldoende kennis op het gebied van open software
Med
Teveel ICTdienstverleners en ICTconsultancy met divergerende belangen.
Med
Med
Uitdragen van visie Business Case
College en directeuren deelnemende diensten
Zonodig escaleren. Groot
Voldoende marge inbouwen voor eventuele externe inhuur
Stuurgroep deelnemende dienst(en), Projectgroep BOSS
Training en borging van kennis in de organisatie Med
Zoveel mogelijk gebruik maken van Raamcontracten. Bewaking op het project in 1 hand
Stuurgroep deelnemende dienst(en), projectgroep BOSS en projectmanagement
Risico’s tijdens de realisatie van het project
ID
Risico
Kans
Impact
Maatregel
Verantwoordelijkheid
6.
Onvoldoende bereidheid tot accepteren nieuwe software en functionaliteit
Med
Groot
Haalbare en logische eisen opstellen.
Commissie en SG IV
Juiste aansturing van de I&A verantwoordelijken in de deelnemende diensten. Second opinions. In het uiterste geval escaleren.
Versie 1.0 Extern
62/72
27 oktober 2006
ID
Risico
Kans
Impact
Maatregel
Verantwoordelijkheid
9.
Trage besluitvorming
Med
Groot
Vroegtijdig vragen om besluiten. Vooraankondigingen te verwachten beslissingsmomenten.
College, Commissie en Stuurgroep IV
10 .
Onvoldoende programma- en projectmanagementcapaciteit (kwalitatief en kwantitatief)
Med
Groot
Voldoende marge inbouwen voor eventuele externe inhuur Hoge prioriteit stellen met controle op uitvoering.
Commissie en Stuurgroep IV, projectgroep, RvD SHI en projectleiding BOSS
Goede en transparante voortgangsrapportages. Project-audits.
11 .
Vroegtijdig vertrek van sleutelfunctionarissen bij de deelnemende organisaties
Klein
Med
Open communicatie. Vroegtijdig mogelijke weerstanden opsporen. Actief terugkoppeling vragen aan deze functionarissen.
Commissie en Stuurgroep IV, Projectleiding BOSS
Anticiperende preselectie.
6.3.3
Risico’s tijdens het beschikbaar stellen van werkplekken
ID
Risico
Kans
Impact
Maatregel
Verantwoordelijkheid
13 .
Aansluiting op de ICTarchitectuur van de Gemeente Amsterdam is niet goed ingericht
Med
Groot
Gericht onderdeel van het project is het aansluiten op de ICT Architectuur van het SHI
Projectleiding, Directie SHI, Adviesgroep Architectuur
14 .
Netwerkcapaciteit is onvoldoende
Klein
Med
Vroegtijdig berekenen van de benodigde netwerkcapaciteit en tijdig eventuele extra capaciteit bestellen bij de interne (E-net) en externe leveranciers.
Projectgroep BOSS, Projectleiding, Directie SHI
15 .
‘Verdamping’ van verwachte besparingen als gevolg van het niet terug laten vloeien van de baten in het project
Med
Med
Financiële component in het project beleggen uitgaven en besparingen inboeken
Projectgroep BOSS
Essentieel is de nauwe betrokkenheid en frequente toetsing door de Adviesgroep Architectuur
Zorgvuldige planning en geen uitbreiding van de scope Zorgvuldige screening volgende lichtingen
17 .
Onvoldoende aandacht voor de interne besturing
Med
Groot
Ervaren en bedreven management aantrekken
Projectgroep BOSS
18 .
Budgetoverschrijdingen en als gevolg daarvan teruglopende besparingen
Klein
Med
Heldere financiële afspraken vooraf en een goede rapportage structuur inrichten.
Stuurgroep deelnemers, Projectgroep BOSS
Besparingen tijdig terug laten vloeien in het project BOSS Strikte financial control resp. financial audits.
Versie 1.0 Extern
63/72
27 oktober 2006
ID
Risico
Kans
Impact
Maatregel
Verantwoordelijkheid
Duidelijke grenzen stellen voor de uitgave van middelen en gerealiseerde besparingen 19 .
Onvoldoende invulling van het relatiemanagement
Med
Groot
Service management beleggen zoals dit in de huidige SHI wordt gedaan
Projectgroep BOSS
Tussentijdse evaluaties (toetsing klanttevredenheid) 20 .
Onvoldoende alerte en open communicatie met afnemers/gebruikers
Med
Groot
Communicatie duidelijk beleggen in het project
Projectgroep BOSS, directeuren van deelnemende organisaties
6.4 Herziening ICT-aanbestedingsmodel in relatie tot het scenario In overleg met de afdeling Concern Inkoop en de Afdeling Juridische Zaken is besloten vooralsnog geen herziening te doen van het ICT-aanbestedingsmodel, temeer omdat de Gemeente Amsterdam nu ook al gebruik maakt van dienstverleners die open standaarden en open source producten ondersteunen. De herziening zou vooral gericht zijn op het toelaten van kleinere partijen tot de aanbestedingen voor raamcontracten of de mogelijkheden tot het vormen van consortia van kleinen bedrijven. Dit is momenteel mogelijk binnen de Gemeente Amsterdam.
6.5 Software inkoopprocedures in relatie tot het scenario Op het gebied van inkoop van software verandert er weinig, behalve dat er zoveel molgelijk naar gestreefd zal worden aan de geldende eisen met betrekking tot open standaarden te gaan voldoen. De ICT inkoopvoorwaarden blijven onverminderd van kracht echter met betrekking tot het intellectuele eigendomsrecht zal bekeken dienen te worden hoe de Gemeente hiermee om wenst te gaan. Artikel 6 spreekt van het IE-recht dat berust bij de Gemeente, wat in de meeste gevallen (inclusief de huidige inkoop van software) niet mogelijk is omdat men de IE-rechten op de code niet weggeeft.
6.6 Licentiebeheer in relatie tot het scenario Verwacht wordt dat op het gebied van licentiebeheer wel besparingen gerealiseerd kan worden, maar dat dit teniet wordt gedaan door de nieuwe omgeving onder te brengen bij het Servicehuis ICT. Een van de voordelen die wordt genoemd in de business case SSC ICT (zie ook paragraaf 4.2.4) is de consolidatie van contractmanagement en licentiebeheer. Hoewel het licentiebeheer voor open software aanzienlijk minder is (men mag de software immers zo veel en zo vaak men wil gebruiken zonder dat hier kosten aan zijn verbonden) zal er op het gebied van contracten met leveranciers weinig veranderen. De Gemeente gaat immers niet zelf de software onderhouden, maar zal daarvoor altijd een dienstverlener benaderen of dit nu via een dienstverleningsraamcontract is of een openbare of Europese aanbesteding. Door de nieuwe omgeving onder te brengen in het SHI kan gebruik gemaakt worden van de expertise daar om contracten te beheren, maar zullen er geen extra besparingen worden gerealiseerd.
Versie 1.0 Extern
64/72
27 oktober 2006
7 Voorlopig advies inzake het Raamcontract met Microsoft De business case geeft zicht op een eindsituatie waarbij het niet opnieuw aanbesteden van een contract voor kantoorautomatisering een reële optie is. Er dient echter gebruik te worden gemaakt van de evaluatiemomenten die zijn ingebouwd in het Project BOSS om hierover tot een nader oordeel te komen. Definitieve besluitvorming moet medio 2008 plaatsvinden.
Onderbouwing niet geschikt voor externe publicatie.
Versie 1.0 Extern
65/72
27 oktober 2006
Bijlage 1 Volledige Matrix Eindsituaties vs. Criteria Nevendoelstellingen en effecten Weinig Opleidingen
Past binnen SHI concept
Weing Impact huidige org.
Weinig Impact huidige ICT
Snel 1e resultaat (QW)
Toekomstvastheid
Weinig Ontwikkelinsp.
Weinig migratie insp. (€)
Consolidatie verschil. software
Voldoet als alternatief
Kostenreductie SW
Kostenreductie HW
Digitale duurzaamheid
Beter Imago A'dam-ICT Stad
Pos. Marktwerkingseffect
Stimulans lokale ICT
Kostenbeheersing (SD)
Interoperabiliteit (SD)
Bedrijfscontinuiteit (SD)
Eindsituatie
Overige OSS Doelstellingen
Leveranciersonafhankelijk (AM)
Criteria
OSS Doelstellingen
Totaal
Eindsituatie 1 OSS op Window s
2,7 3,3 2,3 4,0 37 2,0 2,0 3,0 3,7 0,7 3,0 29 2,7 2,7 3,0 3,3 3,7 5,0 3,3 3,0 3,7 2,7
98,67
2,7 2,0 2,7 2,7 30 2,3 2,3 2,3 3,0 2,3 2,3 29 2,3 2,3 2,7 2,3 3,0 2,3 3,0 3,0 2,7 3,0
86,00
3,3 2,3 3,0 2,0 32 3,3 2,3 3,0 3,3 2,3 2,0 33 3,3 3,0 1,3 1,0 3,0 0,7 2,0 2,3 2,7 2,3
86,33
5,0 1,0 5,0 2,0 39 4,3 4,0 4,3 5,0 4,0 4,3 52 4,7 4,7 0,3 2,0 5,0 2,0 1,7 1,3 2,7 2,0
117,33
5,0 4,3 5,0 5,0 58 4,0 4,0 5,0 5,0 4,7 5,0 55 5,0 5,0 4,0 4,3 5,0 4,7 4,0 4,3 4,7 2,0
156,33
Eindsituatie 2 BE migratie (gradaties)
Eindsituatie 3 FE OSS op Window s BE migratie (gradaties)
Eindsituatie 4 Alles OSS (Migratie)
Eindsituatie 5 Alles OSS (Greenfield)
Eindsituatie 6 Verder gaan met Microsoft
0,0 4,3 1,3 3,3 27 0,7 0,3 0,0 1,7 0,0 1,0 We gingsfactore n
Versie 1.0 Extern
3
2
66/72
7 1,7 0,7 4,7 4,7 4,3 3,3 4,7 4,7 5,0 4,3
72,33
1
27 oktober 2006
Bijlage 2 Uitwerking financiële onderbouwing Niet geschikt voor externe publicatie.
Versie 1.0 Extern
67/72
27 oktober 2006
Bijlage 3 Activiteiten en voorlopige planning project BOSS Actuele planning in Projectplan Open Amsterdam.
Versie 1.0 Extern
68/72
27 oktober 2006
Bijlage 4 Samenstelling toetsingscommissie Leden van de toetsingscommissie Naam
Functie
Herman Marres Ron Blankers Jan Willem Broekema Maurice van Erven Peter Mol Rob Hofman Jo a Haye Dirk van Roode
Oud Raadslid, indiener amendement (extern) Adjunct directeur Servicehuis ICT (intern) Hoofd OSOSS (extern) Vertegenwoordiger EZ (intern) Stadsdeelsecretaris Oost-Watergraafsmeer (intern) Hoofd Afdeling O&I, Gemeente Utrecht (extern) Voorzitter Holland Open (extern)30 ICT-office (extern)31
30
Stichting Holland Open werpt zich op als belangenbehartiger van het open gedachtegoed.
31
Branchevereniging van IT-, Telecom-, Office- en Internetbedrijven in Nederland
Versie 0.9 concept
69/72
27 september 2006
Bijlage 5 Standpunt Servicehuis ICT Niet geschikt voor externe publicatie.
Versie 1.0 Extern
70/72
27 oktober 2006
Bijlage 6 Definities en begrippen Wat zijn open standaarden? (bron: www.ossos.nl) Open ICT-standaarden dienen de interoperabiliteit van informatiesystemen (ofwel het vermogen tot gegevensuitwisseling tussen ICT-systemen). Standaarden kunnen 'open' zijn of 'gesloten'. Onder een 'open standaard' verstaan we een standaard die voldoet aan de volgende eisen: a) De standaard is goedgekeurd en zal worden gehandhaafd door een not-for-profit organisatie b) De standaard is gepubliceerd en over het specificatie document van de standaard kan vrijelijk worden beschikt of het is te verkrijgen tegen een nominale bijdrage. c) Het intellectuele eigendom - m.b.t. mogelijk aanwezige patenten - van (delen van) de standaard is onherroepelijk ter beschikking gesteld op een royalty-free basis; d) Er zijn geen beperkingen over het hergebruik van de standaard; Open standaarden kunnen leiden tot: • Het verhogen van de kwaliteit van overheidsinformatiesystemen op het gebied van de toegankelijkheid van informatie, transparantie van handelen, veiligheid en toekomstvastheid. • Het verlagen van de kosten (total cost of ownership). • Betere gegevensuitwisseling tussen overheidsonderdelen. Wat is Open Source Software? (bron: www.ossos.nl) Open stuurse software is software met twee kenmerken: a) De broncode van de software is vrij beschikbaar. b) In het licentiemodel is het intellectueel eigendom en het (her)gebruik van de software en bijbehorende broncode dusdanig geregeld dat de licentienemer de broncode mag inzien, gebruiken, verbeteren, aanvullen en distribueren. Een open source licentie dwingt vaak af dat de broncode van het product vrij beschikbaar moet zijn. Tevens dwingen veel open source licenties af dat software die afgeleid is van open source software of software die een gemodificeerde vorm is van open source software, zelf ook beschikbaar gemaakt moet worden onder dezelfde open source licentie. Open source software kan leiden tot: • Het verminderen van de afhankelijkheid van externe softwareleveranciers zodat de keuzemogelijkheden vergroot worden. • Het tegengaan van monopolyposities op de softwaremarkt om misbruik van dergelijke economische machtsposities te voorkomen. • Het verhogen van de kwaliteit van overheidsinformatiesystemen op het gebied van de toegankelijkheid van informatie, transparantie van handelen, veiligheid en toekomstvastheid. • Het verlagen van de kosten (total cost of ownership). Enterprise agreement = standaard contract tussen Microsoft en grote organisaties over het gebruik van standaard software beschikbaar gesteld door Microsoft. Het contract beperkt zich tot de voorwaarden voor gebruik waarbij beperkt maatwerk mogelijk is. Bijbehorend (en vaak meegerekend tot) is een contract waarin de commerciële voorwaarden geregeld zijn, waarbij kenmerkend is dat achteraf afgerekend wordt op basis van het feitelijke gebruik van de licenties. Back-end = dat deel van de software configuratie waar de gebruiker geen direct contact mee heeft en slechts via de front end software gebruikt kan worden. (b.v. de e-mail server) Front-end = dat deel van een software configuratie waar de gebruiker direct mee in contact komt (b.v. het e-mail pakket op de desktop).
Versie 0.9 concept
71/72
27 september 2006
Hybride = gemengd. Hybride in de biologie is een kruising tussen twee soorten. Hybride in software omgevingen is daar waar systemen met verschillende architecturen door elkaar worden gebruikt. Ook vaak genoemd als “best of breed”. TCO = Total Cost of Operation = een overzicht van alle kosten die gemaakt moeten worden om een systeem neer te zetten, in te richten, goed te laten functioneren en up-to-date te houden. Interoperabiliteit = interoperabiliteit staat voor de uitwisseling van informatie tussen administraties, tussen een administratie en de burger of een onderneming, zonder van hen specifieke inspanningen te verlangen. Interoperabiliteit beoogt eveneens de duurzaamheid van de gegevens en hun toegankelijkheid in de toekomst veilig te stellen. De facto standaard = een standaard die niet formeel is vastgelegd, maar ontstaat doordat vrijwel iedereen voor de betreffende taak hetzelfde systeem c.q. software gebruikt. Vendor lock-in = de situatie dat de afhankelijkheid van een leverancier zo hoog is geworden dat de klant feitelijk niet meer kan wisselen van leverancier. In splendid isolation = gegeven de omstandigheden het beste kiezen voor de eigen situatie zonder rekening te houden met de belangen van anderen. Role based application management = een beheersstructuur voor applicaties waarbij de rechten en plichten van gebruikers worden bepaald door de rol die ze hebben. Dit in tegenstelling tot User based application management (een beheersstructuur waarbij voor iedere gebruiker apart zijn rechten en plichten geregeld moeten worden.) IE-Rechten of Intellectueel Eigendom = Intellectueel eigendom is een verzamelnaam voor een aantal rechten die we terug vinden in verschillende nationale- en internationale wetten. Het komt er op neer dat de bedenker van een werk beschermd wordt; een ander mag zijn werk niet zomaar namaken. De bedenker heeft het 'intellectuele eigendomsrecht'.
Versie 1.0 Extern
72/72
27 oktober 2006
