projectinitiatiedocument implementatie mid-office · projectinitiatiedocument implementatie...

Auteur : Martijn de Groot Opdrachtgever/ budgethouder :

Ton van Vlimmeren

Datum : 11 maart 2008 Titel: PID Implementatie mid-office Auteur: Martijn de Groot 1 - 24Versie: V1.0 Datum: 11 maart 2008 Project: Implementatie mid-office Bestandsnaam: 20080311-PID Implementatie Mid-Office-zoalsbijondertekening

Projectinitiatiedocument Implementatie mid-office

Gemeente Utrecht in samenwerking met:

PROJECTINITIATIEDOCUMENT Implementatie mid-office

Titel: PID Implementatie mid-office Auteur: Martijn de Groot 2 - 24Versie: v1.0 Datum: 11 maart 2008 Project: Implementatie mid-office Bestandsnaam: 20080311-PID Implementatie Mid-Office-zoalsbijondertekening

MANAGEMENTSAMENVATTING

Het project implementatie mid-office (IMO) is ontstaan uit het pilot-project WW+, waarbij de gemeente Utrecht voor het eerst experimenteerde met het inzetten van complexe elektronische dienstverlening. Het project is, net als het de voorgaande initiatieven, ondergebracht onder het programma Innovatie met ICT. Uit het pilot-project WW+ bleek dat de efficiency en het niveau van dienstverlening aanzienlijk beter worden wanneer (de afhandeling van) elektronische formulieren worden gevoed en ondersteund door de back-office. Om de technisch complexe en soms verouderde back-office applicaties veilig en betrouwbaar in te kunnen zetten in het front-office is een mid-office oplossing noodzakelijk. De ervaringen uit WW+ hebben de gemeente Utrecht doen besluiten om daadwerkelijk over te gaan tot implementatie van een mid-office, welke via het landelijke aanbestedingstraject Andez2 is geselecteerd. Het mid-office is onderdeel van het gemeentebrede servicebus concept dat in verschillende projecten binnen de gemeente wordt uitgewerkt. Het mid-office is de belangrijkste component in deze service georiënteerde architectuur (sga of soa). Doelstellingen - eMAXX mid-office oplossing beschikbaar stellen in de gemeente Utrecht

De daadwerkelijke implementatie van het mid-office is het primaire doel van dit project.

- Zien hoe het werkt (ervaring opdoen) De ervaringen in het eerste, eenvoudige proces helpen ons in de toekomst complexere processen te kunnen modelleren.

- Identificeren en ontwikkelen generieke functies (standaarden) Het creëren van generieke functies maakt doorontwikkelen van dienstverlening en gegevensuitwisseling tussen systemen eenvoudiger.

Projectresultaten - Implementeren technologie van Bull/Emaxx

(servers en software); - Inrichten basisvoorzieningen (DigiD prefill eFormulieren, Betalingen via internet) voor

verdere digitalisering e-dienstverlening; - Volledig werkend inrichten 2 dienstverleningsprocessen

(uittreksel GBA en wijziging naamgebruik); - Inrichten zakenmagazijn t.b.v. 2 genoemde dienstverleningsprocessen; - Inrichten gegevensmagazijn t.b.v. 2 genoemde dienstverleningsprocessen; - Opleveren van de omgeving aan de beheerorganisatie

(opleiding, documentatie en overdracht) Planning Het project zal worden uitgevoerd in de periode tussen maart en september 2008. Een detail planning is opgenomen in dit document.



INHOUDSOPGAVE

1 INLEIDING EN ACHTERGROND PROJECT ........................................................................................ 4

2 PROJECTDEFINITIE ................................................................................................................................. 7 2.1 DOELSTELLINGEN .................................................................................................................................... 7 2.2 AANPAK EN FASERING ............................................................................................................................. 7 2.3 RESULTATEN............................................................................................................................................ 8 2.4 UITSLUITINGEN........................................................................................................................................ 9 2.5 RANDVOORWAARDEN, UITGANGSPUNTEN & BEPERKINGEN .................................................................. 10 2.6 RELATIES MET ANDERE PROJECTEN ....................................................................................................... 10

3 INITIËLE BUSINESS CASE..................................................................................................................... 12 3.1 BEDRIJFSSTRATEGIE .............................................................................................................................. 12 3.2 KEUZE VAN DE OPLOSSING..................................................................................................................... 12 3.3 TOEGEVOEGDE WAARDE........................................................................................................................ 13 3.4 KOSTEN ................................................................................................................................................. 13 3.5 BATEN ................................................................................................................................................... 13

4 ORGANISATIESTRUCTUUR.................................................................................................................. 14

5 INITIËLE PROJECTPLANNING............................................................................................................ 16 5.1 EXTERNE AFHANKELIJKHEDEN .............................................................................................................. 16 5.2 PRODUCTDECOMPOSITIE ........................................................................................................................ 16 5.3 PLANNING AANNAMES ........................................................................................................................... 17 5.4 PROJECTPLANNING ................................................................................................................................ 18

6 BEHEERSINGSMECHANISMEN........................................................................................................... 19 6.1 TOLERANTIES ........................................................................................................................................ 19 6.2 VOORTGANGSRAPPORTAGE ................................................................................................................... 19 6.3 TIJD- EN KOSTENRAPPORTAGES ............................................................................................................. 19 6.4 KWALITEITSRAPPORTAGES .................................................................................................................... 20 6.5 UITZONDERINGSPROCEDURE (‘MANAGEMENT BY EXCEPTION’)............................................................ 20

7 PROJECTRISICO’S .................................................................................................................................. 21

8 ACTIVITEITENOVERZICHT................................................................................................................. 23 8.1 AANVULLENDE RANDVOORWAARDEN ROND DE PROCESIMPLEMENTATIE.............................................. 23

BIJLAGE 1: PRIJSSJABLOON GEMEENTE UTRECHT........................................................................... 24



1 INLEIDING EN ACHTERGROND PROJECT

Het project implementatie mid-office (IMO) is ontstaan uit het pilot-project WW+, waarbij de gemeente Utrecht voor het eerst experimenteerde met het inzetten van complexe elektronische dienstverlening. Het project is, net als het de voorgaande initiatieven, ondergebracht onder het programma Innovatie met ICT. Uit het pilot-project WW+ bleek dat de efficiency en het niveau van dienstverlening aanzienlijk beter worden wanneer (de afhandeling van) elektronische formulieren worden gevoed en ondersteund door de back-office. Om de technisch complexe en soms verouderde back-office applicaties veilig en betrouwbaar in te kunnen zetten in het front-office is een mid-office oplossing noodzakelijk. De ervaringen uit WW+ hebben de gemeente Utrecht doen besluiten om daadwerkelijk over te gaan tot implementatie van een mid-office, welke via het landelijke aanbestedingstraject Andez2 is geselecteerd. Het mid-office is onderdeel van het gemeentebrede servicebus concept dat in verschillende projecten binnen de gemeente wordt uitgewerkt. Het mid-office is de belangrijkste component in deze service georiënteerde architectuur (sga of soa). De gemeentelijke service bus bestaat grofweg uit drie elementen. 1. Broker

De broker is een applicatie die in staat is om gegevens uit verschillende bronnen (oude systemen, back-office systemen, elektronische formulieren, databases, enzovoorts) in te lezen. Een broker kent vele mogelijkheden om te koppelen met andere systemen en is in staat om tijdens de uitwisseling van gegevens controles uit te voeren en gegevens op basis van inhoud te routeren. De broker is het technische hart van de service bus oplossing.

2. Mid-office Zodra we de functionaliteit van de broker gaan inzetten voor elektronische dienstverlening, dan hebben we aan alleen een broker niet voldoende. Er is op dat moment behoefte aan een aantal aanvullende componenten. De belangrijkste aanvullende componenten zijn het gegevensmagazijn en het zakenmagazijn. Het gegevensmagazijn maakt het mogelijk om 24 uur per dag, 7 dagen per week gegevens die nodig zijn tijdens de elektronische aanvraag via de broker te leveren aan de formulierenomgeving. Dit kan het bronsysteem van deze informatie vaak niet, omdat dit een administratieve applicatie is die niet is ontworpen voor deze hoge beschikbaarheid en voor de hoge belasting die internet kan opleveren. Met name back-ups en onderhoudswerkzaamheden zorgen voor een lagere beschikbaarheid dan gewenst. Het zakenmagazijn is een database die gegevens opslaat over de diensten die een burger afneemt bij de gemeente. Hierdoor kunnen lopende dossiers inzichtelijk worden gemaakt en kan worden voorkomen dat een burger meerdere malen dezelfde gegevens moet opgeven aan de gemeente. Om al deze functies mogelijk te maken bestaat een mid-office naast de broker dus uit extra databases Voor gegevensmagazijn en zakenmagazijn en uit een ontwikkel en beheeromgeving voor procesmodellering.



3. Service bus De service bus is eigenlijk een verzamelnaam voor diensten die binnen de gemeentelijke architectuur als een service worden aangeboden. Een goed voorbeeld hiervan is het geo-datawarehouse. Dit is een los functionerende technische omgeving, die haar informatie aan kan bieden via webservices. Verschillende applicaties (waaronder het mid-office) kunnen gebruik maken van deze services. Voor het gebruik van deze services zijn beheerafspraken gemaakt binnen een aantal SLA’s tussen de eigenaren van de systemen. Op deze manier ontstaat een web van services en afspraken omtrent deze services. Dit wordt de service bus genoemd.

4. Flexibiliteit door SOA De match tussen kernactiviteiten en IT is in de praktijk lastig te maken. Management moet op basis van inzicht in informatie kunnen sturen. IT zou volgend aan de vraag moeten zijn maar kan dat niet altijd, door starheid in de applicatie of architectuur.

Door gebruik te maken van SOA technologie kan nu op flexibele wijze aan beide behoeften worden voldaan. De Utrechtse servicebus is de technische implementatie van de Service Oriented Architecture in gemeente Utrecht. De plaats van de service bus in onze architectuur is overeenkomstig de eerder in de gemeente Utrecht ontwikkelde visie die tot uitdrukking komt in de onderstaande afbeelding. Hierbij is de service bus de centrale speler bij het koppelen van de verschillende systemen van de gemeente Utrecht en haar ketenpartners.



2 PROJECTDEFINITIE

2.1 Doelstellingen

Het project implementatie mid-office draagt bij aan het realiseren van de doelstellingen van het programma Innovatie met ICT, met in het bijzonder: - Verbeteren van de publieksdienstverlening - Verbeteren van de bedrijfsvoering. Het project kent de volgende doelstellingen: - eMAXX mid-office oplossing beschikbaar stellen in de gemeente Utrecht

De daadwerkelijke implementatie van het mid-office is het primaire doel van dit project.

- Zien hoe het werkt (ervaring opdoen) De ervaringen in het eerste, eenvoudige proces helpen ons in de toekomst complexere processen te kunnen modelleren.

- Identificeren en ontwikkelen generieke functies (standaarden) Het creëren van generieke functies maakt doorontwikkelen van dienstverlening en gegevensuitwisseling tussen systemen eenvoudiger.

2.2 Aanpak en fasering

2.2.1 Aanpak

Om de hierboven gestelde doelen te bereiken zullen in het project de volgende activiteiten worden uitgevoerd: - Implementeren technologie van Bull/Emaxx

(servers en software); - Inrichten basisvoorzieningen (DigiD prefill eFormulieren, Betalingen via internet) voor

verdere digitalisering e-dienstverlening; - Volledig werkend inrichten 2 dienstverleningsprocessen

(uittreksel GBA en wijziging naamgebruik); - Inrichten zakenmagazijn t.b.v. 2 genoemde dienstverleningsprocessen; - Inrichten gegevensmagazijn t.b.v. 2 genoemde dienstverleningsprocessen; - Opleveren van de omgeving aan de beheerorganisatie

(opleiding, documentatie en overdracht) De technische inrichting wordt volledig uitgevoerd door Bull/eMAXX. Het plaatsen en de basisinstallatie (OS) van de servers wordt conform installatie specificaties van eMAXX door het Automatiseringsbedrijf van de gemeente Utrecht (ABU) verzorgd. Inhoudelijk participeren de betrokken diensten, O&I en Functioneel Beheer Utrecht.nl in het project.



2.2.2 Fasering

Het project wordt aangepakt volgens de Prince2 methodiek en bestaat uit de volgende fasen: Infrastructuur/applicatie gerelateerde fasen:

1. Site Survey Vastgesteld wordt wat aan Software en Hardware resources (servers/storage) beschikbaar en/of nodig is voor de MidOffice omgeving.

2. Infrastructuur De vereiste infrastructuur wordt opgebouwd of beschikbaar gesteld.

3. Generieke voorzieningen In deze fase worden de generieke voorzieningen (eFormulieren, SAP, PIV, koppelvlakken, DigiD en Ogone) ten behoeve van de testomgevingen opgeleverd of beschikbaar gesteld.

4. Inrichting Acceptatie- en productieomgeving Inrichting eMAXX midoffice, BPEL engine, Zakenmagazijn en Gegevensmagazijn

5. MidOffice Koppelingen Realiseren koppelingen: Prefill eFormulieren, Ogone (internet betalingen), Piv4All (Key2BZ) en SAP (financieel systeem)

6. Processen Ontwerp, test, bouw en oplevering van de processen “Uittreksel aanvraag GBA” en “Wijziging naamgebruik” op de “Acceptatie omgeving”.

Overige

7. Documentatie Van de betreffende omgeving zal een technische installatiehandleiding opgeleverd worden

8. Opleiding Applicatiebeheer en Systeembeheer De opleidingen “Basis training eMAXX midoffice” en “Basis training BPEL engine” zullen gevolgd worden.

2.3 Resultaten

Het project levert de volgende hoofdproducten op, die elk nader gespecificeerd kunnen worden: − Infrastructuur advies (infracheck op hardware en netwerk-infrastructuur t.b.v.

implementatie Midoffice); • Vaststelling van de delta’s tussen bestaande hardware en benodigde hardware op

basis van beschikbaarheids eisen en specificaties van Leveranciers. • Benodigde Licenties

− Functioneel ontwerp voor de volgende processen: • Uittreksel aanvraag GBA • Wijziging naamgebruik

− Geïmplementeerde en geaccepteerde processen conform geaccepteerde Functionele ontwerpen:



• Uittreksel aanvraag GBA • Wijziging naamgebruik

− Geimplementeerd gegevensmagazijn. • Datamapping document DDS/PIV naar model eMAXX gegevensmagazijn. • ETL tooling voor vulling gegevensmagazijn conform datamapping document.

− Geïmplementeerde koppelingen. • Midoffice koppeling naar Piv4All (Key2BZ) • Midoffice koppeling naar SAP (financieel systeem) • Midoffice koppeling naar Ogone (internet betalingen) • Koppeling t.b.v. Prefill op eFormulieren conform specificaties van eFormulieren.

− Generieke voorzieningen • betalen via Ogone, • verwerken betalingen in SAP • aanmelden via DigiD.

− acceptatie- en productieomgeving (OTAP) welke zijn ingericht met de volgende software componenten; • eMAXX midoffice • BPEL engine • eMAXX Gegevensmagazijn • eMAXX Zakenmagazijn

− Documentatie van de betreffende technische installatie en implementatie: • Installatie handleidingen voor:

o eMAXX midoffice o BPEL engine o eMAXX Gegevensmagazijn o eMAXX Zakenmagazijn

• Functioneel Inrchtingsdocument voor de processen o Uittreksel aanvraag GBA o Wijziging naamgebruik

− Applicatiebeheer en Systeembeheer hebben de volgende opleidingen van “Exellence” (eMAXX) gevolgd: • Basis training eMAXX midoffice • Basis training BPEL engine

De opleidingen worden eenmalig gegeven voor maximaal 7 personen. − Een door de gemeente op te stellen aansluitvoorwaarden-document dat kan worden

gebruikt bij het aanbesteden van software dat moet aansluiten op het midoffice; − Bull/eMAXX heeft maximaal 3 mandag(en) consultancy geleverd om advies te geven

bij het bepalen van het nieuwe beveiligingsbeleid van de gemeente Utrecht, deze uren vallen in het prijssjabloon onder infrastructuur advies. *;

− Bull/eMAXX heeft maximaal 3 mandag(en) consultancy geleverd om advies te geven t.b.v. haalbaarheid studie invoering van Op Afspraak duidelijk krijgen. *

2.4 Uitsluitingen

Zaken die niet binnen het project worden uitgevoerd zijn: - Het ontwikkelen van elektronische formulieren

Dit wordt verzorgd door het project “65%”. - Investeringen in back-office koppelvlakken

Hiervoor dragen de deelnemende diensten zelf de zorg of wordt gebruik gemaakt van bestaande afspraken met het programma of het concern.

* Additionele consultancy op nacalculatie volgens tarief in prijssjabloon.



2.5 Randvoorwaarden, uitgangspunten & beperkingen

2.5.1 Randvoorwaarden

Aan de volgende randvoorwaarden moet worden voldaan: - Alle bestaande randvoorwaarden uit de Andez2 aanbesteding zijn van kracht op het

project; - De infrastructuur voldoet aan de uitkomsten van de infra check. - De opdrachtgever levert de acceptatiecriteria en het mastertestplan op basis van de

vastgestelde functioneel ontwerpen. - Er is altijd een ter zake kundig aanspreekpunt bij Gemeente Utrecht die informatie

kan geven omtrent aspecten die voor dit project van belang zijn; - De aan het project toegewezen vertegenwoordiger van Gemeente Utrecht heeft

voldoende mandaat om beslissingen te mogen nemen; - De bij het project betrokken personen van partijen worden afdoende vrijgemaakt om

volwaardig en effectief deel te kunnen nemen aan dit project. Indien dit niet tot de mogelijkheden behoort, dan dient een gelijkwaardige vervanging beschikbaar te zijn;

2.5.2 Uitgangspunten

- Alle bestaande uitgangspunten uit de Andez2 aanbesteding zijn van kracht op het project;

- Authenticatie wordt in de e-loket afgehandeld met gebruikmaking van DigiD; - Betalingen worden vanuit de Mid Office met Ogone afgehandeld; - Alle koppelingen die vanuit dit project met back office systemen worden geleverd

worden via Midoffice gelegd; - Gemeente Utrecht stelt een VPN verbinding beschikbaar, zodat de Midoffice server

voor installatie en support werkzaamheden bereikbaar is vanaf eMAXX locatie Hengelo.

- Voordat aangevangen kan worden met de bouw van de Midoffice processen en koppelvlakken dienen de koppelvlakken van de gegevens verwerkende systemen (of backoffice systemen) geïnstalleerd en geconfigureerd beschikbaar te zijn.

2.5.3 Beperkingen

- Alleen een technische bijdrage leveren aan het realiseren van de organisatiedoelen.

2.6 Relaties met andere projecten

In deze paragraaf worden de afhankelijkheden met andere projecten en omstandigheden beschreven, die van invloed zijn op dit project. Eén van de afhankelijkheden is de invloed van het bedrijfsproces op het project (beschikbaarheid medewerkers, invloed op werkzaamheden van medewerkers) en de afhankelijkheid van de organisatie van de einddatum van het project. Projecten die het hier beschreven project beïnvloeden zijn: - Ontwikkeling van eFormulieren en beschikbaar komen van definities

E-formulieren heeft een nieuw koppelvlak gerealiseerd voor het mogelijk maken van voorinvullen van formulieren en het beveiligd verzenden van de formulierdata naar gemeente Utrecht. Omdat dit koppelvlak pas enkele weken beschikbaar is en de



documentatie nog niet volledig, is het project erg afhankelijk van de voortgang van het ICTU.

- Aanpassing architectuur catharijnenet 3 ABU heeft een traject ingezet om een aantal zaken in de gemeentelijke architectuur te wijzigen om zodoende dit en andere projecten beter te kunnen faciliteren. Het tempo van deze aanpassingen is sterk van invloed op het project.

- Implementatie van het geo-datawarehouse Het geo-datawarehouse van de gemeente Utrecht is tevens een component in de Utrechtse servicebus architectuur. Vanuit het huidige project is er geen directe relatie, maar de ontwikkelingen moeten uiteindelijk wel aansluiten.

- Regulier onderhoud aan ICT infrastructuur van Gemeente Utrecht (ITIL Change Management proces) Regulieren onderhoudswerkzaamheden aan applicaties en aan Catharijnenet worden gepland in een onderhoudskalender bij het ABU. Deze moet worden gevolgd om te voorkomen dat andere projecten binnen het ABU dit project verstoren.



3 INITIËLE BUSINESS CASE

Het project dient bij te dragen aan de bedrijfsdoelstellingen van Programma Innovatie met ICT 2010. Hierna wordt deze toegevoegde waarde voor de bedrijfsdoelstellingen aangetoond.

3.1 Bedrijfsstrategie

Het project implementatie mid-office draagt bij aan het realiseren van een aantal concerndoelstellingen, te weten: - Verbeteren publieksdienstverlening - Verbeteren handhaving - Bijdragen aan administratieve lastenvermindering

3.2 Keuze van de oplossing

Er zijn twee alternatieven voor het inzetten van een mid-office 1 - Maatwerk koppelingen tussen FO en BO Tot op heden werden koppelingen tussen het front-office en de back-office rechtstreeks gelegd. Deze koppelingen waren allen maatwerk en werden door verschillende partijen onderhouden. Dit levert grote problemen op bij beheer, beveiliging en ontwikkeling. Deze situatie is alleen houdbaar bij een zeer beperkt aantal koppelingen. Omdat de roep om koppelingen en gegevensuitwisseling, onder andere door de druk vanuit de Rijksoverheid, steeds verder toeneemt, is gezocht naar een alternatieve, beheersbare methodiek. 2 - Implementeren “dik” mid-office (lees: uitfaseren back-office) Bij deze oplossing worden de belangrijkste back-office processen volledig opnieuw ingericht in het mid-office. Hierdoor vervallen back-office processen en werkt zowel de burger als de ambtenaar in ‘hetzelfde’ systeem. Het probleem bij deze oplossing is dat het herschrijven van alle back-office functionaliteit ondoenlijk is qua kosten en inspanning. De gemeente Utecht kan dat, door het grote aantal processen, niet zelfstandig uitvoeren. Voordelen van de mid-office oplossing De gekozen oplossing zorgt ervoor dat een wir-war van los te beheren directe koppelingen tussen het front-office en het back-office beheersbaar en herbruikbaar worden gemaakt. Door het mid-office in te zetten als tussenstation, kunnen beheers- en beveiligingsvraagstukken gestructureerd worden opgelost. De gekozen oplossing maakt daarnaast zo veel als mogelijk gebruik van bestaande functionaliteit en bestaande organisatie-inrichting op het gebied van gegevens- en systeembeheer. Er wordt geen functionaliteit dat al naar tevredenheid beschikbaar is in de back-office herbouwd in het mid-office, zoals bij alternatief 2. Er wordt juist zo veel mogelijk gebruik gemaakt van de mogelijkheden die onze back-office toepassingen bieden. Het mid-office wordt alleen daar ingezet waar de bestaande front-office en back-office applicaties niet kunnen voldoen aan de functionele wensen.



3.3 Toegevoegde waarde

Het project voorziet in een technische oplossing voor het realiseren van de genoemde strategische doelen. De diensten die aan de slag gaan met het realiseren van deze doelen komen op een zeker moment op het punt dat technologie moet worden ingezet. Op dat moment kunnen zij gebruik gaan maken van de technische voorzieningen die dit project voor hen heeft gerealiseerd. Zonder deze technische voorziening zullen bepaalde doelstelling niet haalbaar zijn of zal het beheer, gezien de variatie in oplossingen, zeer complex worden.

3.4 Kosten

De kosten die door de leverancier worden gefactureerd zijn uitgebreid beschreven in het prijssjabloon behorende bij de aanbesteding. Het prijssjabloon is opgenomen als bijlage bij dit document. Naast deze direct kosten van de leverancier maakt de gemeente Utrecht interne kosten door het inzetten van capaciteit. Details over deze kosten zijn opgenomen in en bekend bij het programma Innovatie met ICT.

3.5 Baten

De te verwachten baten van het project zijn op dit moment niet te berekenen. De verwachting is dat door het verminderen van processtappen waarbij ambtenaren betrokken zijn, personeelskosten kunnen worden bespaard. Tevens zorgt de mogelijkheid van het elektronisch aanvragen van gemeentelijke diensten voor een grote maatschappelijke besparing. Immers, burgers hoeven geen tijd te spenderen voor een bezoek aan de balie.



4 ORGANISATIESTRUCTUUR

Voor de duur van het project wordt een tijdelijke organisatie opgezet:

Bedrijfs- ofProgrammamanagement

Stuurgroep

Project-manager

Project-team(s)

Projectbureau

Project-borging

Hierna worden de verantwoordelijkheden van de diverse betrokken groepen algemeen toegelicht. Programmamanagement Naam Rol Ton van Vlimmeren Opdrachtgever/Budgethouder

Bedrijfs- of programmamanagement is verantwoordelijk voor de optimale inpassing van het project in het programma en aansluiting bij de bedrijfsdoelstellingen. Stuurgroep Na(a)m(en) Rol Bijdrage Peter van Tienhoven Executive Stuurt op realisatie projectdoelstellingen Henk van Dijkhuizen Senior user Stuurt op kwaliteit/inzetbaarheid oplossing Henk van Nieuwamerongen

Senior supplier infrastructuur

Stuurt op technische kwaliteit en aansluiting infrastructuur

Lex de Weille Senior supplier mid-office oplossing

Stuurt op bijdrage leverancier (Bull/Emaxx)

De Stuurgroep is eindverantwoordelijk voor het overall eindresultaat van het project en voor het ter beschikking stellen van mensen en middelen. De Stuurgroep komt formeel alleen bij elkaar voor het bespreken van faseplanningen, sturingsvragen en uitzonderingsrapportages. De Stuurgroep rapporteert aan bedrijfs- of programmamanagement.



Projectmanager en projectteam Na(a)m(en) Rol Martijn de Groot Projectmanager Michiel van Turnhout Projectleider Bull/eMAXX Roger van Eijk Projectleider ABU Thomas Krüse Adviseur Peter van Beerendonk Adviseur programma

Het projectteam is verantwoordelijk voor het bereiken van de doelstellingen van dit project en voor het (doen) uitvoeren van het projectplan. Het PMT komt op regulier op tweewekelijkse basis bijeen om voortgang en acties met elkaar te bespreken. De Projectverantwoordelijke van Gemeente Utrecht is verantwoordelijk voor het zeker stellen van de randvoorwaarden die voor het project gelden en coördineert bij het beschikbaar stellen van gemeente medewerkers en middelen. Hij is het directe aanspreekpunt voor de Projectleiders van Bull en andere Leveranciers. Hij is tevens verantwoordelijk voor de optimale inpassing van het project in de operationele situatie en aansluiting bij de bedrijfsdoelstellingen. De Projectverantwoordelijke van Gemeente Utrecht is verder verantwoordelijk voor het monitoren van de kwaliteitsaspecten van het project en de op te leveren producten. Hij vergewist zich ervan dat het project conform de afspraken wordt beheerst en uitgevoerd. De Projectleider Bull rapporteert aan de projectverantwoordelijke van Gemeente Utrecht en de lijnmanager van de Business Unit van Bull die verantwoordelijk is voor realisatie.



5 INITIËLE PROJECTPLANNING

De projectplanning geeft aan welke acties wanneer door wie worden ondernomen en wat de bijbehorende kosten zijn. De planning kan gedurende de loop van het project aangepast worden op basis van ervaringen in het project en / of nieuwe gegevens. In geval van een wijzigende scope is er sprake van een wijzigingsverzoek.

5.1 Externe afhankelijkheden

De voortgang van het project is afhankelijk van de volgende externe (buiten project gedefinieerde) factoren: - Beschikbaarheid van overige operationele systemen (back-office) via het LAN; - Beschikbaarheid van netwerkverbindingen (VPN) voor installatie en support.

5.2 Productdecompositie

Site Survey • Onderzoek en analyse bestaande infrastructuur (Servers/Storage) t.o.v. vereisten

MidOffice omgeving • Rapport met beschrijving vereiste omgeving

Functioneel ontwerpen:

• Functioneel ontwerp Uittreksel aanvraag GBA • Functioneel Ontwerp Wijziging naamgebruik

Geïmplementeerde en geaccepteerde processen conform geaccepteerde Functionele ontwerpen:

• Uittreksel aanvraag GBA • Wijziging naamgebruik

Geïmplementeerde koppelingen:

• Midoffice koppeling naar Piv4All (Key2BZ) • Midoffice koppeling naar SAP (financieel systeem) • Midoffice koppeling naar Ogone (internet betalingen) • Koppeling voor Prefill van eFormulieren

Generieke voorzieningen:

• betalen via Ogone, • verwerken betalingen in SAP • aanmelden via DigiD

Ontwikkel-, test-, acceptatie- en productieomgeving (OTAP) welke zijn ingericht met de volgende software componenten:

• eMAXX midoffice • BPEL engine • Gegevensmagazijn • Zakenmagazijn

Documentatie van de betreffende technische installatie en implementatie:

• Installatie handleidingen voor: o eMAXX midoffice



o BPEL engine o Gegevensmagazijn o Zakenmagazijn

• Functioneel Inrchtingsdocument voor de processen o Uittreksel aanvraag GBA o Wijziging naamgebruik

Applicatiebeheer en Systeembeheer hebben de volgende opleidingen van exellence (eMAXX) gevolgt:

o Basis training eMAXX midoffice o Basis training BPEL engine

Een aansluitvoorwaarden-document dat kan worden gebruikt bij het aanbesteden van software dat moet aansluiten op het midoffice

5.3 Planning aannames

De planning gaat van de volgende aannames uit: - Het implementatieplan / projectplan is goedgekeurd; - Randvoorwaarden zijn ingevuld.



5.4 Projectplanning



6 BEHEERSINGSMECHANISMEN

Hierna wordt aangegeven welke mechanismen worden toegepast om te waarborgen dat het project beheersbaar blijft.

6.1 Toleranties

6.1.1 Beperkingen

Tijdens de uitvoering van het project controleert de Project Manager regelmatig de voortgang. Indien de afwijking van de plannen naar verwachting groter is dan de afgesproken tolerantie, wordt daarover apart gerapporteerd in het Project team. De tolerantie op totale project doorlooptijd is als volgt gedefinieerd: Doorlooptijd plus of min 10%;

6.1.2 Afwijkende functionaliteit

In dit geval gaat het om functionaliteit, die niet in het functioneel ontwerp is opgenomen. Per fase kunnen afwijkende toleranties worden opgenomen in de faseplanningen, afhankelijk van de omvang en impact van risico’s.

6.2 Voortgangsrapportage

Er zijn drie soorten voortgangsrapportages van de Projectmanager aan de Stuurgroep:

− Hoofdlijnenrapport (reguliere voortgangsrapportage, kwalitatief en kwantitatief); − Afwijkingsrapport (rapportage indien de tolerantiegrenzen van het project of de fase in

tijd, geld en/of kwaliteit dreigen te worden overschreden); − Fase-eindrapport (terugblik op afgelopen fase (evaluatie) en vooruitblik op

eerstkomende fase (faseplanning). Daarnaast rapporteren de Projectleider ABU en de Projectleider Bull/eMAXX aan de Projectmanager:

− Voortgangsrapport (reguliere voortgangsrapportage, kwalitatief en kwantitatief). De te gebruiken documentensjablonen zijn als bijlage bijgesloten en bij de gemeente Utrecht beschikbaar.

6.3 Tijd- en kostenrapportages

Om de Projectmanager te voorzien van stuurinformatie en in staat te stellen voortgangsrapportages op te stellen is het noodzakelijk dat projectmedewerkers regelmatig de bestede tijd, de nog te besteden tijd en de verwachte opleverdatum van de diverse producten rapporteren. Daarnaast dienen degenen die verantwoordelijk zijn voor extern in te kopen (deel-) producten, voorziene afwijkingen van geplande kosten en definitieve kosten direct te melden aan de Projectmanager.



6.4 Kwaliteitsrapportages

De verantwoordelijken voor kwaliteitscontrole rapporteren regelmatig aan de Project Manager over de voortgang en resultaten van kwaliteitscontroles. De kwaliteitsverwachting van de eindproducten (webdiensten) worden mede in de acceptatiecriteria concreet gemaakt en de testrapportages kunnen vanuit dat perspectief ook als kwaliteitsrapportages worden aangemerkt.

6.5 Uitzonderingsprocedure (‘Management by Exception’)

De uitzonderingsprocedure treedt in werking als van een fase of van het project verwacht wordt dat het niet binnen de afgesproken tolerantiegrenzen blijft. Zodra de Project Manager dit op basis van aangeleverde informatie verwacht, meldt de Project Manager dit in het projectteam. In onderling overleg wordt de aanleiding en oorzaak besproken. Daarna wordt besloten tot één van de volgende situaties: - het projectteam treft maatregelen ter voorkoming/opheffing van de aanleiding; - het projectteam besluit geen actie te nemen, omdat het denkt dat de overschrijding

van de tolerantie niet plaats zal vinden; - de toleranties voor de fase worden verruimd; - er worden concessies gedaan ten aanzien van tijd, geld, kwaliteit of omvang van het

op te leveren resultaat (bereik). Met nadruk wordt gewezen op het gegeven dat het bovenstaande slechts in uitzonderingsgevallen op kan treden. Bull gaat uit van een resultaatverplichting en zal bovenstaande procedure volgen indien de activiteiten zich buiten de projectscope dreigen te begeven of als een mismatch blijkt ten aanzien van de uitgangspunten en randvoorwaarden.



7 PROJECTRISICO’S

De volgende tabel geeft een overzicht van de tot nu toe onderkende bedreigingen ten aanzien van het project met voorgestelde tegenmaatregelen, de kans van optreden en de mate van negatief effect op het project (aangegeven op een schaal van 1tot 51). De laatste kolom geeft het risico aan (kans*effect). Op deze wijze kan gefundeerd worden afgewogen welke bedreigingen de meeste aandacht of hulpbronnen verdienen. Tijdens het project wordt deze lijst voortdurend bijgehouden in een Risicologboek, met een uitgebreidere beschrijving van de risico’s. Toevoeging van bedreigingen of andere wijzigingen worden vermeld in het eerstvolgende Hoofdlijnenrapport. Bedreiging Tegenmaatregel Kans Effect Risico

Ontwikkeling eFormulieren: beschikbaar komen definities

De nu specificaties worden getoetst door eMAXX. Bij onvoldoende kwaliteit spoedig melden bij ICTU

3 5 15

Negatieve gevolgen aanpassingen architectuur Catharijnenet 3

Betrokken blijven en bijdragen aan dit ABU project

1 4 4

Beschikbaarheid resources en kennis

Duidelijke afspraken en planning bij aanvang project. Strakke bewaking planning en parallel uitvoeren activiteiten.

4 4 16

Te weinig draagvlak in de organisatie

Communicatie naar de organisatie, draagvlak bij stakeholders creëren

2 3 6

Leemte in de communicatie binnen het project

Strak management, ondermeer door de projectmanagement mechanismen (actie- en besluitenregister, opleverdatums). Alert zijn op het commitment van alle projectmedewerkers.

3 5 15

Vertraagde levering hardware/software

Bewaking van levertijd, gebruik alternatieve hard/software, wijziging volgorde van activiteiten

3 4 12

Late invulling van randvoorwaarden door gemeente

Escalatieprocedure opstarten, alternatief kiezen of planning bijstellen

4 4 16

Gebrek aan testresources Ultimatum van acceptatieperiode met automatische acceptatie na verstrijken van de tijd

2 3 6

Hinder door vakantie-afspraken

Tijdige bekendmaking van geplande vakanties. Consequenties in doorlooptijd aangeven aan belanghebbenden

1 3 3

Onduidelijke acceptatiecriteria

Vroegtijdige vaststelling van criteria, mate van urgentie of impact bepalen, gedeeltelijke acceptatie met defectenlijst voorbereiden.

4 3 12

Late besluitvorming door de organisatie

Escalatieprocedure opstarten, alternatief kiezen of planning bijstellen

2 3 6

verbinding met systemen t.b.v. support, en

Tijdig de voorwaarde creëren waaronder de citrix verbinding gerealiseerd kan worden.

1 3 3

1 1 = kleine kans of gering effect, 5 = grote kans of groot effect



Bedreiging Tegenmaatregel Kans Effect Risico

onderhoud

VPN verbinding met test-backoffice systemen is niet beschikbaar

Tijdig de voorwaarde creëren waaronder deze VPN wel gerealiseerd kan worden.

3 3 9

Koppelvlak backoffice systeem niet beschikbaar

Tijdig inventariseren welke koppelingen nodig zijn, en betrekken van de backoffice leverancier bij het project.

5 4 20

Backoffice inconsistent Onderzoek en maatregelen om backoffice consistentie te garanderen.

2 5 10

Regulier onderhoud aan ICT infrastructuur van Gemeente Utrecht

Goed volgen onderhoudskalender ABU ter voorkoming van overlappende of verstorende werkzaamheden

3 3 9



8 ACTIVITEITENOVERZICHT

8.1 Aanvullende randvoorwaarden rond de procesimplementatie

Voor het realiseren van de processen gaat Bull ervan uit dat aan de volgende randvoorwaarden wordt voldaan. - Elk werkproces wordt zoveel mogelijk geautomatiseerd ondersteund, mits de huidige

back-office applicaties over de relevante functionaliteiten beschikken; - De proceseigenaren zijn beschikbaar voor eventuele aanvullende vragen over de

betreffende processen; - Gemeente Utrecht stelt alle relevante functionele en technische informatie over de

systemen beschikbaar. Dit geldt ook voor alle informatie met betrekking tot de ICT-infrastructuur (IP-nummers, databaseversies, et cetera).

- Alle informatie over externe diensten (accountgegevens Ogone, accountgegevens DigiD, SSL certificaten) zijn voorafgaand aan de bouw bekend;

- Koppelingen met DigiD en de Ogone Internet Kassa worden zover mogelijk getest aan de hand van de door Gemeente Utrecht aangeleverde accountgegevens. Hiervoor wordt bij eMAXX een testomgeving opgezet;

- De basisinstallatie wordt door eMAXX on-site uitgevoerd. De installatie van proces specifieke functionaliteit en updates geschiedt voornamelijk op afstand.

- Voorafgaand aan de installatie zijn de aanwezige firewalls en routers correct geconfigureerd op basis van de eerder door eMAXX in het ICT infrastructuur document aangegeven configuratieregels. Het ICT infrastructuur document is gebaseerd op de resultaten van de infracheck.

- Tijdens de installatie van diverse onderdelen is ondersteuning aanwezig vanuit de ICT afdeling van Gemeente Utrecht om waar nodig te assisteren bij de installatie en configuratie;

- De Gemeente Utrecht stelt een acceptatieomgeving beschikbaar (Hardware+basis OS, netwerk infrastructuur en licenties). Hierop kan de ontwikkelde software aan de integratietest (in de installatiefase) en de functionele test (in de testfase) onderworpen worden alvorens in de productieomgeving geïnstalleerd te worden;

- De Gemeente Utrecht levert tijdig de acceptatie criteria en testcases aan. Deze kunnen uit de vastgestelde Functioneel ontwerpen worden opgesteld.

- De Gemeente Utrecht formeert tijdig een testgroep voor het uitvoeren van de functionele test aan de hand van het opgestelde testplan;

- Bugs welke vanuit de testcases worden gevonden worden in het bugtracker systeem van eMAXX gemeld. Details over gebruik worden bij het vaststellen van de testcases en acceptatiecriteria gecommuniceerd.

- Alle overdraagbare kennis zal worden overgebracht via de tijdens het project opgestelde documenten (functionele en technische ontwerpen, rapporten, et cetera). Hierbij wordt in ieder geval alle kennis die noodzakelijk is voor de reproductie van de installatie, configuratie en procesmodellering gedocumenteerd.



BIJLAGE 1: PRIJSSJABLOON GEMEENTE UTRECHT

Het prijssjabloon geeft een weergave van de verschillende kosten in het project Implementatie mid-office.

projectinitiatiedocument implementatie mid-office · projectinitiatiedocument implementatie...

Documents