31
Eindrapportage Project LedenRegistratie Protestantse Kerk (LRP)
Generale Synode November 2011 AZ 11-28
20 oktober 2011 Uitgebracht door: Bestuur van de Dienstenorganisatie Protestantse Kerk
31
Pagina 3 van 31
Inhoud 1 1.1 1.2 1.3
Management notitie Resultaten van het project Doelstellingen die zijn bereikt Leeswijzer
5 5 6 6
2
Project Resultaten
8
3 3.1 3.2 3.3 3.4 3.5 3.6
Projectdefinitie Doelstellingen Aanpak en fasering Resultaten Omvang & realisatie Randvoorwaarden & beperkingen Relaties met andere projecten
9 9 9 10 11 18 19
4
Ontwikkelmethodiek
20
5
Organisatiestructuur
21
6 6.1 6.2 6.3
Projectplanning, mensen en middelen Randvoorwaarden Projectplanning Kosten
22 22 22 23
7 7.1 7.2 7.3 7.4
Vervolg op project LRP Huidige stand Versie 1v1 Versie 2v0 Nazorg en opvolging vanuit het project
25 25 25 25 25
Bijlage 1
Afkortingen en Begrippen
27
Bijlage 2
Artikel in de Automatisering gids van 18 augustus 2011
29
Inhoudsopgave
31
Pagina 5 van 31
1
Management notitie
Het bestuur van de dienstenorganisatie levert met deze eindrapportage het project LRP op. Hiermee is het project afgelopen, maar het werken met LRP wordt voortgezet. Wij blijven werken aan verbeteringen van het systeem en aan de service en dienstverlening. Het bestuur heeft met vreugde en dankbaarheid mogen constateren dat we al onze doelstellingen hebben bereikt. 1. Het ontwikkelen van een goed werkend veilig en stabiel systeem. Bijna 1.9 miljoen leden staan hierin geregistreerd, waarvan 890.000 belijdende leden. 2. Gebruikersvriendelijk. Inmiddels meer dan 8.000 gebruikers in meer dan 90% van onze gemeenten. 3. Binnen het gestelde budget en tijdsplanning gerealiseerd. 4. Een structurele besparing van tenminste € 861.000 per jaar voor de kerk en haar gemeenten. Dit project had niet gerealiseerd kunnen worden zonder de deskundigheid en grote inzet van de stuurgroep, de projectleiding, de adviescommissie, de projectboard, het LRP-team, Mendix en last but not least de vele vrijwilligers uit de gemeenten. Nu kent succes vele vaders en zijn mislukkingen vaak wees, maar het bestuur is dankbaar dat zij allemaal hun bijdrage hebben geleverd. Dit tot opbouw van de kerk en tot eer van God. Deze rapportage volgt het projectplan, zoals vastgesteld in de kleine synode van november 2009. Zowel de kleine synode als ook de generale synode zijn geïnformeerd omtrent de voortgang van het project, daarom bieden wij de eindrapportage aan de generale synode aan. Een afkortingen- en begrippenlijst is als bijlage toegevoegd. Tevens is als bijlage een artikel opgenomen dat in de Automatiserings gids van 18 augustus is verschenen.
1.1
Resultaten van het project
Het Project is uitgevoerd binnen de periode zoals beschreven in projectplan paragraaf 6.4 „Projectplanning‟, te weten van december 2009 tot juli 2011 Het project is uitgevoerd binnen de budgetkaders zoals beschreven in projectplan para. 6.6 „Kosten‟, namelijk 3,5 miljoen; dat is minder dan de begrote 3,7 miljoen Het project heeft een operationeel LRP systeem opgeleverd in januari 2011 waarna de conversie van ruim 1.500 gemeenten is uitgevoerd. Er zijn meer dan 8.000 actieve gebruikers Als onderdeel van het project zijn bijna 15.000 authenticatiesleutels verstrekt aan de gemeenten voor (potentiële) gebruikers Als onderdeel van het project zijn duizenden gebruikers getraind door tientallen vrijwilligers Als resultaat van het project is de SMRA organisatie overgegaan naar een nieuw gevormd LRP-team binnen de Dienstenorganisatie Ondersteuning van de gemeenten en het uitvoeren van betaalde dienstverlening met LRP worden door het LRP-team uitgevoerd sinds januari 2011 Aan het eind van de implementatiefase (jan-jun 2011) is een verbeterde versie (1v1) in gebruik genomen Technische systeem en applicatiebeheer zijn wel vorm gegeven, maar voor het jaar 2012 en daarna nog niet contractueel geregeld Bij de conversie van lokale software pakketten van gemeenten is een kwalitatieve verbetering van de geregistreerde kerkleden en hun gegevens bereikt. Er zijn registraties ontdubbeld, reeds uitgeschreven leden zijn alsnog verwijderd uit de registratie, belijdenis en doop gegevens die ontbraken in de landelijke registratie zijn toegevoegd, enz. Door dit alles zijn er wijzigingen ontstaan in het aantal geregistreerde belijdende en doopleden die bij sommige
Pagina 6 van 31
gemeenten meerdere tientallen bedraagt. De landelijke telling van het totaal aantal leden in LRP bedraagt op dit moment (oktober 2011) 1,88 miljoen. Dit aantal zal waarschijnlijk nog wijzigen omdat sommige gemeenten nog bezig zijn om handmatige correcties aan te brengen als nasleep van de conversie.
1.2
Doelstellingen die zijn bereikt
Het nieuwe ledenregistratie- en bijdragensysteem geeft een goede ondersteuning voor het plaatselijke en landelijke kerkenwerk voor nu en in de toekomst en vanuit allerlei situaties (thuis, op een vaste werkplek en eventueel mobiel). Dit is onder andere gerealiseerd door het systeem te baseren op internet technologie. Het systeem voldoet aan de functionele eisen en wensen zoals die door de werkgroepen zijn geformuleerd en zijn gericht op het ondersteunen van de plaatselijke gemeenten, ook als vervanging van eventuele lokale applicaties. De minimaal benodigde functionaliteiten zijn opgeleverd binnen de kaders en termijnen van het project. Het systeem heeft een zodanige gebruikersvriendelijkheid, dat vrijwel geen opleiding of training nodig is om met het systeem te kunnen werken. Het is gebleken dat een training van een of twee dagdelen voor de meeste gebruikers ruim voldoende is. Gebruikers van de bijdragenmodule blijken iets meer begeleiding nodig te hebben m.n. door de procesgerichte benadering van LRP op dat onderdeel. Het systeem is uniform opgezet en biedt qua gebruik uniformiteit. Het systeem is efficiënt te beheren en te onderhouden. Tijdigheid, volledigheid, juistheid en veiligheid van gegevens zijn goed geborgd. Dat wil zeggen dat de gegevens die worden ingevoerd in het systeem worden opgeslagen en gepresenteerd zoals ze zijn ingebracht door de gebruiker en daar ook zijn beveiligd tegen ongeautoriseerd gebruik. Bij de conversies is gebleken dat er meer verschillen waren tussen de landelijk vastgelegde gegevens en de gegevens van lokale gemeenten dan was voorzien of verwacht; binnen LRP zijn die gegevens zoveel mogelijk geautomatiseerd samen gebracht en er worden nu nog allerlei handmatige inspanningen verricht om de gegevens verder te verbeteren en te actualiseren. Het systeem is uniform over gemeenten heen, maar kan worden toegesneden op de plaatselijke situatie. Het systeem biedt bepaalde standaarden en uitgangspunten die als basis („default‟) worden gebruikt bij de automatische verwerkingen en gebruikersondersteuningen, maar waar handmatig van af geweken kan worden voor lokale situaties of uitzonderingen. Het is functioneel en technisch mogelijk om de landelijke dienstverlening met betrekking tot de ledenregistratie en bijdragen administratie door de Dienstenorganisatie te laten verzorgen middels LRP.
1.3
Leeswijzer
In het Projectplan dat de Synode vastgestelde in haar vergadering van 27 november 2009 is het project beschreven voor de realisatie van een LedenRegistratie voor de Protestantse kerk in Nederland (afgekort LRP). Dat projectplan is als referentiekader gebruikt voor deze eindrapportage. In dit projecteindrapport wordt een nadere verantwoording gedaan door het bestuur en projectmanagement over het eindresultaat van het project, met daarbij een specificatie van de openstaande en / of lopende activiteiten binnen de dienstenorganisatie die nog een directe nasleep zijn van het project LRP. Het bestuur vraagt aan de Generale Synode middels dit document om decharge voor het project LRP zodat het project ook formeel afgesloten kan worden verklaard.
31
Pagina 7 van 31
In dit projecteindrapport wordt bij een aantal producten die in het projectplan staan vermeld aangegeven dat die niet binnen het project gerealiseerd konden worden. De meeste daarvan worden in de eerste reguliere onderhoudsronde (versie 2v0) alsnog meegenomen. Onderdelen van de eindrapportage van het project De volgende onderwerpen uit het projectplan worden verantwoord qua uitvoering De projectdefinitie ▫ Doelstellingen ▫ Op te leveren producten. ▫ Aanpak. ▫ Uit te voeren activiteiten. ▫ Realisatie en bouw. ▫ Testen en acceptatie. ▫ Conversie en migratie. ▫ Aanpassen arbeidsorganisatie SMRA en Dienstenorganisatie. ▫ Communicatie, Instructie en Implementatie. ▫ Inrichting beheer, onderhoud en beveiliging. ▫ Benodigde mensen, middelen en tijd. De organisatiestructuur In de bijlagen zijn opgenomen: Een afkortingen- en begrippenlijst Een artikel dat is gepubliceerd in de Automatisering gids van 18 augustus 2011
Pagina 8 van 31
2
Project Resultaten
Zie de management samenvatting voor een verantwoording van de project resultaten.
31
Pagina 9 van 31
3
Projectdefinitie
3.1
Doelstellingen
Doel van het project was om te komen tot een systeem voor de Ledenregistratie van de Protestantse kerk. Dat doel is bereikt. Er is een systeem gerealiseerd voor de plaatselijke gemeenten en de landelijke organen van de Protestantse kerk om het kerkelijk werk te ondersteunen en de zorg voor gemeenteleden te kunnen waarborgen. De administratieve processen voor het registeren van gemeenteleden en anderen worden ondersteund met LRP en zijn te gebruiken voor mensen in de gemeente die pastorale rollen vervullen. De landelijke dienstenorganisatie helpt de gemeenten daarbij en/of kan werkzaamheden namens hen uitvoeren (betaalde dienstverlening). Ook het financiële aspect voor wat betreft fondsenwervingsonderdelen is opgeleverd. Een opsomming van de behaalde doelstellingen staat in de managementsamenvatting. Het systeem voldoet aan de criteria en eisen die de Protestantse kerk in Nederland in de kerkorde heeft vastgelegd over het landelijk, gemeenschappelijk systeem voor de ledenregistratie; het voldoet ook aan andere en reguliere eisen die aan zo‟n systeem gesteld worden (bijvoorbeeld vanwege de Wet Bescherming Persoonsgegevens en de eisen die door SILA worden gesteld).
3.2
Aanpak en fasering
Het project is uitgevoerd volgens het Prince-2 raamwerk (Prince-2 is een project methodiek, toegespitst op ICT), aangevuld met specifieke richtlijnen vanuit de ervaringen met model gedreven software ontwikkeling. Het systeem is in de vorm van concrete (deel-)producten opgeleverd. Actuele en veelvuldige rapportage over voortgang en resultaten aan stuurgroep en adviescommissie vormden de basis voor het volgen en de controle over het project. Vier functionele domeinen De LRP is opgeleverd in vier functionele domeinen, te weten kerkelijke structuur & organisatie, ledenadministratie, bijdragenadministratie en ondersteuning pastoraal en ander kerkelijk werk via dienstverlening. Deze waren verder verdeeld in kleinere functioneel gerelateerde onderdelen die samen in ontwikkelcycli (z.g. iteraties of realisatieslagen) werden opgeleverd. Ieder functioneel domein is in samenwerking met aparte werkgroepen ontworpen, gebouwd en getest. Deze opsplitsing en de snelle terugkoppeling van concrete resultaten maakte een frequente beoordeling en bijsturing mogelijk. Mensen De projectstructuur is in tact gebleven tijdens de duur van het project en heeft goed gefunctioneerd. De rollen waren duidelijk. Ook heeft de door de Synode ingestelde adviescommissie een goede rol gespeeld tijdens het project; zowel adviserend naar het project als rapporterend naar de Synode. Projectmanagement, leverancier, werkgroepleden en andere direct betrokkenen werkten nauw samen zodat de communicatielijnen kort konden blijven. Bij iedere ontwikkelcyclus waren wekelijkse bijeenkomsten gepland. De functionele domeingroepen bestonden in hoofdzaak uit vrijwilligers en toekomstige gebruikers uit de gemeenten. Deze toekomstige gebruikers en vrijwilligers uit de gemeenten hadden een cruciale rol bij de realisatie van het project, niet alleen hebben ze de functionele eisen en wensen helpen formuleren, maar ook tijdens de realisatie waren ze betrokken om terugkoppeling te geven binnen de ontwikkelcycli en voor het uitvoeren van de acceptatietesten. Op deze manier was er voldoende kennis en kunde vanuit de toekomstige gebruikers beschikbaar die de inzetbaarheid en werkbaarheid
Pagina 10 van 31
van het systeem heeft vergroot. Met dank en waardering willen we graag nogmaals attenderen op de vele vrijwilligers die een positieve bijdrage aan het project wilden leveren. Uiteraard betreft die dank en waardering ook de tientallen vrijwilligers die veel tijd en energie hebben gestoken in het opleiden en begeleiden van hun „collega‟s‟. De LRP heeft veel veranderingen gebracht voor alle direct betrokkenen zoals medewerkers binnen de DO/SMRA, kerkelijke bureaus, ambtsdragers en vrijwilligers. Daarom is veel aandacht gegeven aan de communicatie en is ook een speciale website ingericht voor dit doel. Communicatie Voor de start van het project is een gedetailleerd communicatieplan opgesteld dat ook als bijlage aan het projectplan was gevoegd. Tijdens de realisatie van het project werd dit plan bijgesteld waar nodig. Gedurende het project was er continu aandacht voor de communicatie naar de gemeenten en de toekomstige gebruikers. Er is een folder en informatie brochure gemaakt over LRP. Er zijn maandelijks tot 2-wekelijks nieuwsbrieven uitgegeven. In Kerkinformatie is een artikelserie verschenen over de ledenregistratie en haar beoogde gebruikers en toepassingen. Ook is via de VKB aandacht gegeven aan het project o.a. door aanwezigheid op haar landelijke ontmoetingsdagen. Ook bij andere gelegenheden die zich voordeden werd er acte de présence gegeven zoals op ontmoetingsdagen van kerkelijk werkers, bij de Baruch gebruikersvereniging en kerkenbeurs. Bij de communicatie is altijd veel aandacht gegeven aan het eerlijk en open zijn waarbij eerder terughoudend dan uitbundig werd gecommuniceerd over de mogelijkheden en planning, zodat de verwachtingen van de toekomstige gebruikers realistisch zouden zijn en blijven. Op elke vergadering van de kleine Synode is gerapporteerd over de voortgang van het project; tevens heeft de generale Synode een demonstratie gehad van het systeem in de proefdraaifase. De synodale adviescommissie voor het LRP project rapporteerde ook elke Synode vergadering over haar bevindingen. Ontwikkelcycli, realisatieslagen of iteraties Alle realisatieslagen startten met een bespreking over de vereiste functionaliteit en het werkproces. Hierbij werd in klein comité een vertaling gemaakt van de gewenste „wat-vraag‟ naar een mogelijke „hoe-realisatie‟. Deze werd uitgewerkt tot een concreet voorstel en aan een bredere groep (de betrokken functionele werkgroep, conceptbewaking, projectleider, enz.) ter beoordeling aangeboden. Vervolgens werd in meerdere z.g. iteratie-overleggen dit alles in breder verband besproken en beoordeeld en steeds concreter uitgewerkt in prototypes tot het eindresultaat klaar was. Testen en Wijzigingen Binnen elke ontwikkelcyclus (dus per functioneel deelgebied) werden door het team testscenario‟s vastgesteld die ook door werkgroepleden werden uitgevoerd. Iedere ontwikkelcyclus leverde een volledig werkende afgesloten software component op, waarvan de functionaliteit na afloop van de ontwikkelcyclus bevroren werd. Het integraal testen van de componenten binnen het zo groeiende systeem en binnen de relevante context was ook onderdeel van iedere ontwikkelcyclus.
3.3
Resultaten
Het project leverde als hoofdproducten: Een LedenRegistratiesysteem voor de Protestantse kerk (LRP), dat via het internet gebruikt kan worden. Het LRP omvat vier belangrijke functionele domeinen: ▫ Een leden administratie. ▫ Een bijdragen administratie. ▫ De kerkelijke structuur en organisatie.
31
Pagina 11 van 31
▫
Ondersteuning van het pastorale en andere kerkelijke werk via de dienstverleningsonderdelen zoals selecties, groeps-en gebiedsindelingen, looplijsten, gegevensexport, enz. Landelijke dienstverlening met betrekking tot de ledenregistratie en bijdragen administratie. Functionele modellen op basis waarvan de applicatie is gegenereerd. Direct benaderbare helpinstructies en een aparte omgeving voor aanvullende ondersteuning. Een centrale server omgeving voor de applicatie en database op een hiervoor geschikte infrastructuur. Dit is inclusief een „hosting‟ (een beveiligde computerruimte) omgeving, bijbehorende technische documentatie en maatregelen zoals back-up en beveiliging. Deze omgeving is tot nader besluit nog in beheer bij Mendix Conversie en migratie software en instructies om LRP te vullen vanuit het huidige LLR systeem op het mainframe. Software die de gegevens uit de lokale (Baruch en Scipio) applicaties overzet naar de centrale database. Hulpmiddelen zoals documentatie en handleidingen. Verbeteringen van de data-integriteit als onderdeel van de migratie (waar mogelijk is dat geautomatiseerd gedaan, anders betreft het handwerk door de betrokken gemeenten) Ondersteuning op allerlei gebieden en manieren ten behoeve van de implementatie van het systeem binnen de Protestantse kerk.
3.4
Omvang & realisatie
3.4.1
Bouw & Ontwerp
Algemene uitgangspunten Het LRP systeem draait op één centrale plaats en kan benaderd worden via het internet met behulp van een browser (ook genoemd webverkenner). Naast een browser is er geen andere software nodig om LRP te kunnen gebruiken. Op de computers van gebruikers van LRP worden meerdere versies van het besturingssysteem en eventuele kantoorsoftware, zoals Microsoft Office of Open of Libre Office, ondersteund, als het maar courante uitvoeringen betreft i.v.m. de HTML compatibiliteit. De incidentele gebruiker kan op een gemakkelijke en intuïtieve manier een taak uitvoeren via helpteksten en sturende schermpjes, terwijl een geroutineerde medewerker meer efficiënt een doel kan bereiken en ook meer ingewikkelde en complexe handelingen kan verrichten. LRP vergroot het gebruiksgemak o.a. door eenduidigheid in terminologie, lay-out en opmaak. Alle teksten binnen LRP zijn opgesteld in het Nederlands. Gezien de gevoeligheid van de gegevens is er veel aandacht gegeven aan de beveiliging via fysieke identificatiesleutels zoals bij internetbankieren, diverse gebruikersrollen, compartimentering via (wijk-) gemeente en secties en beveiligde verbindingen. Het was dan ook een grote opsteker voor het project dat juist op dat vlak twee onderscheidingen in ontvangst genomen mochten worden. Eén van het bedrijf Vasco voor het toegepaste concept en een internationale van de iCMG organisatie voor de beveiligingsarchitectuur. Functionele aspecten Er is uitgegaan van vier componenten om een goed functionerend ledenregistratiesysteem te ontwikkelen. Te weten in de volgorde van realisatie: Kerkelijke Structuur en Organisatie (KSO) Leden Administratie (LA) Bijdragen Administratie (BA) DienstVerlening (DV) voor het pastorale en ander kerkelijke werk De applicatie geeft volledig inzicht in de kerkelijke structuur en organisatie. Het onderhouden van de kerkelijke structuur van classes tot en met secties is mogelijk. Classicale en gemeentelijke indelingen en informatie worden beheerd door de dienstenorganisatie. De (wijk-)gemeenten kun-
Pagina 12 van 31
nen zelfstandig hun contactgegevens in interne indelingen beheren. Er is o.a. gebruikersvriendelijke en vergaand geautomatiseerde ondersteuning voor het uitvoeren van fusies, splitsingen en oprichting van (wijk)gemeentes en het onderhouden van secties. Een tweede belangrijk doel is het beheer van de leden inclusief bijbehorende gegevens zoals pastorale eenheden. Wijzigingen zoals verhuizingen, geboorte, doop, belijdenis, huwelijk, overlijden en inschrijvingen, overschrijvingen en uitschrijvingen kunnen door zowel de gemeenten als de dienstenorganisatie worden afgehandeld. Wijzigingen met betrekking tot de Gemeentelijke Basis Administratie worden automatisch verwerkt op basis van SILA berichten. De diverse rollen worden over dit soort mutaties of bijzondere gebeurtenissen geïnformeerd. Verder kunnen de financiële bijdragen worden beheerd. Belangrijke functies daarbij zijn registraties van toezeggingen, giften en abonnementen, aanmaken van acceptgiro‟s of uitvoering van incasso‟s. Er zijn overzichten en signaleringen ingebouwd. Voor het verwerken van ontvangsten zijn internet betaaloplossingen binnen de applicatie geïntegreerd. Waar mogelijk en zinvol zijn z.g. “snelle invoer” mogelijkheden gerealiseerd zodat bijvoorbeeld alleen een muisklik volstaat om een ontvangst te bevestigen. Lest best kan met de applicatie het pastoraal en ander kerkelijk werk worden ondersteund. Dit is een dienstverlening aan de gemeente vanuit het ledenregistratiesysteem. Een belangrijk onderdeel hierbij is het toepassen van selecties, of het maken van overzichten en rapportages op het ledenbestand. Personen kunnen worden ingedeeld via vrije gebiedsindelingen en/of via groepen. Een ander onderdeel van het ondersteunen van het pastoraal werk is het kunnen registreren van bezoeken alsook inzage in andere contactmomenten zoals ontvangen brieven. Voor het kerkelijk bestuur zijn diverse rapporten met statistische informatie nodig, maar die zijn niet als onderdeel van het project gerealiseerd; die zullen in een versie 2v0 (gepland voor november 2011) beschikbaar komen. Gegenereerde documenten en rapporten kunnen afhankelijk van hun onderwerp en toepassing geëxporteerd worden als PDF-, CSV- / Excel- of XML-bestanden zonder dat er lokale software of hulpmiddelen nodig zijn. Ook zal het mogelijk zijn om e-mail berichten vanuit het systeem te versturen vanaf versie 2v0. Het systeem ondersteunt de mogelijkheden om (delen van) de administratie uit te besteden naar de Dienstenorganisatie in de vorm van landelijke dienstverlening. 3.4.2
Conversie
De conversie en migratie van de huidige systemen naar LRP bleken een cruciaal en complex onderdeel van het project. Niet alle eindgebruikers konden begrip tonen voor de consequenties van het samenbrengen van gescheiden bestanden. Tijdens het project werd duidelijk dat er een grote spreiding was in verschillen qua actualiteit, maar ook de inhoud of correctheid van de gegevens in de verschillende systemen; van zo-goedals-geen-verschil bij gemeenten met twee-zijdig mutatieverkeer tot verschillen van tientallen procenten bij gemeenten die al meerdere jaren op een stand-alone basis hebben gewerkt. Het conversieproces kende de volgende onderdelen: 1 1. Conversie van gegevens uit LLR-mainframe en WebSolutions; 2. Conversie van Baruch en Scipio gegevens van lokale (wijk-)gemeenten; 3. Verhogen van de kwaliteit van de gegevens door het analyseren en combineren van deze data. Het converteren van gegevens uit lokale applicaties of systemen niet-zijnde Baruch of Scipio bleek te risicovol en arbeidsintensief in verhouding tot de weinige gevallen en is daarom niet ondersteund.
1
LLR-mainframe was het voormalige ledenregistratie systeem van de SMRA; WebSolutions is het ERP software pakket van de Dienstenorganisatie en bevat o.a. Jaarboek gegevens.
31
Pagina 13 van 31
Ook het converteren van historie en reeds gearchiveerde gegevens ouder dan 2 jaar is niet onder de vlag van het project gerealiseerd en wordt als onderdeel van de versie 2v0 meegenomen. In de implementatieperiode werd er door veel gemeenten gebruik gemaakt van de mogelijkheid om proefconversies uit te voeren. Er zijn in totaal meer dan 3.200 volautomatische proefconversies uitgevoerd. Aan de hand van een conversieverslag met een document met uitleg en adviezen konden gemeenten zich vervolgens voorbereiden voor de „echte‟ conversie door hun gegevens te actualiseren en te verbeteren. Door dat soort voorbereidingen zijn de productie conversies beter verlopen. De productieconversies zijn begeleid door een conversieteam en de inzet van een voltijdse programmeur; er zijn gaandeweg de implementatieperiode veel optimalisaties en gemeentespecifieke aanpassingen gedaan om de gegevens zo goed en compleet mogelijk aan boord te krijgen. LLR en Websolutions LLR is één op één gemigreerd en was leidend m.b.t. burgerlijke gegevens omdat die gegevens van de Gemeentelijke Basis Administratie (GBA) afkomstig zijn via SILA. De gemeentelijke data vanuit LLR is gecombineerd met de jaarboek- en de kerkelijk gegevens uit WebSolutions. Op die manier is de volledige kerkelijke structuur overgezet en samengesteld in LRP. Baruch en Scipio Nadat de LLR en WebSolutions gegevens waren gemigreerd naar LRP konden de lokale gegevens vanuit Baruch en Scipio worden overgenomen. De back-up bestanden van beide applicaties konden (en kunnen) worden aangeboden voor automatische conversie. De pre-productie werd in een daarvoor opgezette omgeving geladen; wanneer de resultaten goed (genoeg) waren werd de gemeente overgezet naar de productiedatabase. Soms moesten er eerst nog aanpassingen worden gedaan en/of was een afstemming en samenwerking met de gemeente nodig om een goed resultaat te krijgen. Overige lokale applicaties Voor het converteren van andere soorten lokale applicaties of systemen konden bij nader inzien toch geen faciliteiten worden geboden om o.a. de risico‟s die dat met zich meebracht i.v.m. de zeer diverse interpretatie en inhoud van de gegevens en aan de andere kant de onevenredige zware inspanning en relatief hoge kosten die nodig waren, terwijl het slechts een zeer beperkt aantal betrof. De gemeenten met afwijkende of papieren administraties hebben hun gegevens in LRP handmatig kunnen / moeten verrijken en aanpassen waar en wanneer nodig. Verhogen van de kwaliteit van de gegevens Mede als gevolg van het niet altijd synchroon lopen van de lokale gegevens met de administratie van de huidige LLR werden bij de migratie en gelijk er na, correcties uitgevoerd. We zagen dat met name belijdenis en doopgegevens werden toegevoegd vanuit de lokale systemen. Daarnaast waren er soms grote verschillen met betrekking tot ingeschrevenen: Landelijk meer personen doordat plaatselijk mensen waren verwijderd (uitgeschreven) zonder dat ze landelijk waren afgemeld of omdat nieuw-ingekomenen niet waren verwerkt; Plaatselijk meer doordat men mensen had toegevoegd die bij andere gemeenten hoorden of omdat ze niet waren aangemeld bij de SMRA; Andere verschillen doordat mutaties niet zijn doorgegeven of niet correct zijn verwerkt. We verwachten nog verdere verschuivingen in aantallen per gemeente omdat men nog handmatig aan het bijstellen is. Er moet rekening mee worden gehouden dat de landelijke aantallen na al deze correcties en bijstellingen zullen verschillen ten opzichte van wat de voorgaande jaren is gepubliceerd of waar mee is gerekend. Daarnaast is gebleken dat de gemeenten in hun aard en werkwijze ook her en der verschilden qua praktijk en hetgeen administratief was en is vastgelegd. Gefuseerde gemeenten die administratief nog onafhankelijk zijn, federaties die nog niet zijn geadministreerd of inmiddels al zijn
Pagina 14 van 31
overgegaan in een fusie en gemeenten die een protestantse aanmerking hebben, maar nog staan geregistreerd onder hun oude Hervormde of Gereformeerde denominatie. Als direct gevolg van het project is hier ingezet op een inhaalslag om dit gecorrigeerd te krijgen omdat men er met LRP meer “last van heeft” als het niet juist is geadministreerd dan in de oude situatie waar een gemeente lokaal een eigen administratie voerde. 3.4.3
Testen
Tijdens de realisatie en bouw van het systeem is continu getest; dat had mede te maken met de 2 keuze voor het z.g. “Agile” ontwikkelproces waarbij de eindgebruiker betrokken is bij de uitwerking van de applicatie en continu prototypes evalueert en uitprobeert als beoordeling. Daarnaast werden alle opgeleverde software modules ook in hun samenhang getest en in een breder verband. Ook de inzetbaarheid en werkbaarheid voor gebruik door de dienstenorganisatie was onderdeel van het testwerk. De conceptbewakingsrol werd ingevuld door de deelname bij de besprekingen rond de uitwerking van de functionaliteiten en door testwerkzaamheden; daarnaast waren de conceptbewakers lid van het projectteam. Gedurende de hele test- en realisatieperiode was er een testcoördinator die zorgde voor afstemming, vastlegging en structurering van de testwerkzaamheden. Daarnaast zijn er diverse meer techniek gerelateerde testen uitgevoerd rond prestaties, belasting en robuustheid. Ook is voor de productiedatum een extra zware belastingstest („stress test‟) met 10.000 gesimuleerde gebruikers en een uitwijktest (onder die volle belasting) uitgevoerd; hierover is tussentijds gerapporteerd. Aan het eind van de bouw- en realisatiefase is een acceptatiedocument opgesteld en ingevuld waarbij over alle functionele en technische onderdelen een waardering is gegeven. Ook deze resultaten zijn tussentijds aan de stuurgroep en synodale adviescommissie gerapporteerd. 3.4.4
Pilot & implementatie
In de zomer van 2010 is een tussenbalans opgemaakt m.b.t. de stand van LRP om te bepalen of het wellicht al goed genoeg zou zijn om een eerste implementatie te gaan uitvoeren. Conclusie was dat het systeem al wel redelijk compleet was maar dat er nog te weinig praktijkervaring voorhanden was; daarop is besloten om een proefdraaiperiode in te gaan met een aantal gemeenten die zich al hadden gemeld als pilot gemeente. Tot onze blijde verrassing bleek dat bijna alle pilot gemeenten zich aanmelden als proefdraaigemeente zodat er over de breedte van de kerk en met veel gebruikers getoetst kon worden hoe LRP zich gedroeg. In deze proefdraaiperiode is een schat aan ervaring opgedaan die ook gelijk gebruikt kon worden om LRP te verbeteren en te optimaliseren. Helaas was binnen de dienstenorganisatie (LRP-team) onvoldoende capaciteit beschikbaar om volop mee te draaien in deze proefdraaiperiode zodat (achteraf gezien) nog redelijk veel reparaties op dit vlak moesten worden gedaan in de eerste periode van operationeel gebruik van het systeem omdat sommige systeemdelen toen pas voor het eerst werden gebruikt in de praktijk. Aan het eind van de proefdraaiperiode is opnieuw de balans opgemaakt om te bepalen of het verantwoord zou zijn om LRP operationeel in te zetten. Daarbij is onder andere gekeken naar zaken als: Voldoet het systeem voldoende aan de gestelde functionele en technische criteria? “Is het verantwoord om het systeem in gebruik te gaan nemen?” Is het beheer van het systeem adequaat ingeregeld? Is de conversie van de data betrouwbaar en kwalitatief goed genoeg? Is de Dienstenorganisatie toegerust om de dienstverlening naar de gemeenten over te nemen van de SMRA en als LRP-team met behulp van het LRP gestalte te geven?
2
“Agile” is een flexibel, iteratief en interactief ontwikkelproces op basis van prototyping, waarbij gebruikers telkens uitgewerkte prototypes bekijken en toetsen om te bepalen of het eindproduct zal gaan voldoen.
31
Pagina 15 van 31
Heeft de Servicedesk voldoende capaciteit en deskundigheid om de gemeenten in voorziene situaties te kunnen ondersteunen? Is alles gereed om na de pilot gelijk de doorstart te maken naar de massale conversie en landelijke implementatie? De besluitvorming hieromtrent vond plaats binnen het bestuur. Het bestuur werd geadviseerd door de Adviescommissie, ProGro en Protea die dit onderbouwden met een ingevuld acceptatiedocument. Pilot Nadat in december groen licht gegeven kon worden om LRP in januari 2011 operationeel in gebruik te nemen, werden de definitieve conversies ingepland. Ruim twee weken nadat de productie conversie van het LLR-mainframe in januari was uitgevoerd, werd een eerste groep pilotgemeenten aangesloten op LRP gevolgd door een 2e groep een paar weken later. Nadat geconstateerd was dat alles stabiel functioneerde werd de landelijke implementatie in gang gezet vanaf 1 maart 2011. Deze pilotgemeenten waren een goede afspiegeling van gemeenten want het betrof verschillende typen gemeenten, verschillende gemeenten qua grootte en verschillende gemeenten qua werkwijze en ondersteuning. In totaal hebben bijna 40 gemeenten in de pilotfase een bijdrage geleverd. In deze fase werd de LLR–mainframe achter de hand gehouden voor eventuele terugval scenario‟s; met uitzondering van enkele activiteiten door de dienstenorganisatie is hier geen gebruik van gemaakt. Implementatie Parallel aan deze pilot waren de landelijke trainingen over het hele land ook begonnen als voorbereiding op de landelijke implementatie. Er werd op 4 locaties gelijktijdig getraind op in totaal 19 verschillende plaatsen verspreid over het land. Per training konden 15 personen deelnemen en elke LRP-rol werd tweemaal per week aangeboden, de ene overdag en de andere ‟s avonds en zaterdagochtend. Met dat patroon konden maximaal 4 * 2 * 15 = 120 gebruikers per rol per week worden opgeleid. De implementatiefase kon starten nadat de pilotfase was afgerond en geaccepteerd. De pilot gemeenten hadden bewezen dat het nieuwe systeem naar behoren functioneerde zodat er verder gegaan kon worden met de implementatie van de rest van de gemeenten. Geleerde lessen uit de pilot werden meegenomen. In aanloop naar de implementatie werden de gemeenten geïnformeerd en getraind over de functierijkdom van het systeem en de stappen welke doorlopen worden richting ingebruikname. Onder andere door middel van nieuwsbrieven en publicaties op een speciale website (http://LRP-netwerk.pkn.nl ) is hier invulling aan gegeven. Om toegang tot LRP op een veilige manier te autoriseren is gebruik gemaakt van fysieke, unieke en persoonlijke authenticatiesleutels die op de trainingen persoonlijk aan de lokaal beheerder van een gemeente werden overhandigd. De gebruikersnamen en wachtwoorden werden gescheiden via e-mail toegestuurd; wachtwoorden worden door het systeem gegenereerd zodat ze alleen bij de ontvanger van het email bericht bekend zijn. De lokaal beheerder kon de lokale conversie en het uiteindelijke overgangsmoment zelf inplannen op een moment dat het de gemeente het beste paste; voorafgaand konden de toekomstige gebruikers op training gaan; ook dat werd door de lokale beheerder gestuurd. Tijdens de hele periode van proefdraaien, pilotfase en converteren en implementeren werden alle bevindingen geregistreerd en geprioriteerd door het projectteam om weloverwogen keuzes te kunnen maken over eventuele noodreparaties en te nemen maatregelen. Om de conversie en implementatie beheersbaar te houden werden alle gemeenten in drie groepen ingedeeld: ▫ Gemeenten die de AKB dienstverlening van de dienstenorganisatie afnemen; zij moeten namelijk hun mutaties aanbrengen om een goede AKB verwerking mogelijk te maken en
Pagina 16 van 31
de z.g. papieren gemeenten; dat zijn gemeenten zonder een lokale conversie (met kaartregisters en/of uitbestede dienstverlening). Zij zijn automatisch gemigreerd bij de conversie van het LLR-mainframe. ▫ De 2e groep was de gemeenten met twee of meer wijkgemeenten. ▫ De 3e en laatste groep was alle overige gemeenten. Deze aanpak heeft over het geheel genomen goed gewerkt. Een uitzondering op deze indeling waren een grote groep Scipio gemeenten die wachtten met de overstap totdat de XML-koppeling van LRP naar Scipio was vrijgegeven. Dit waren zo‟n 80 (deels grotere) gemeenten die in de maand juli converteerden naar LRP. Dit was mede ingegeven door het feit dat half juli de LLR-mainframe werd ontmanteld waardoor men geen SILA mutaties meer binnen kreeg via dat kanaal. ▫ Waar nodig werden gemeenten begeleid en geholpen door vrijwilligers van ondersteunende regionale teams vaak in samenspraak met een gemeente adviseur LRP. Het werd bij nader inzien zeer wenselijk (en ook noodzakelijk) geacht de eindgebruikers een eenvoudige instructie of training op het systeem te geven. De toegezegde instructiefilmpjes bleken te zwak van kwaliteit om in te zetten, mede omdat de functionaliteiten inmiddels waren aangepast sinds het opnemen van de filmpjes. Omdat de filmpjes primair waren bedoeld om gebruikerstrainingen overbodig te maken was het geen ernstig manco tijdens de implementatie omdat er wél trainingen werden gegeven. In het systeem zijn online helpteksten aanwezig op zowel veldniveau (wat is de functie van dit veld) alsook procedureel in de vorm van handleidingen en instructies voor procedures en werkwijzen. Ook is een forum voor eindgebruikers ontwikkeld. 3.4.5
Beheer
Hosting & infrastructuur Data center Voor de plaatsing van apparatuur heeft de Protestantse kerk gekozen voor een samenwerking met de ICT dienstverlener XS4ALL. In de beveiligde computerruimte van XS4ALL in Amsterdam huurt de Protestantse kerk van de dienstverlener een afgesloten serverkastruimte, samen met de benodigde (redundante) stroomvoorziening, netwerkverbinding(en) naar het internet en beveiligde toegang tot de serverkast in het data center. Er is tevens voorzien in een redundante omgeving op een andere locatie die als uitwijk kan dienstdoen bij calamiteiten; deze omgeving fungeert tevens als beveiliging en back-up voor de gegevens omdat continue de gegevens worden gerepliceerd naar deze locatie. Hardware Voor dit project heeft de Protestantse kerk hardware aangeschaft die specifiek en alleen voor LRP wordt gebruikt. Dit voorkomt dat andere projecten en / of systemen invloed kunnen hebben op de prestaties van het systeem. Tijdens de realisatie en implementatie van het project is het systeem geanalyseerd qua verbruik en vermogen. Authenticatie & beveiliging hulpmiddelen Toegang tot LRP kan alleen worden verkregen via fysieke identificatiesleutels. Dit is vergelijkbaar met apparaten die banken gebruiken voor het beveiligen van internetbankieren. Verder wordt er gebruik gemaakt van beveiligde internet verbindingen (SSL). Voor de infrastructuur zijn vergelijkbare beveiligingsrichtlijnen toegepast als voor internetbankieren. Back-up en uitwijk Het systeem stuurt na een bepaalde hoeveelheid mutaties maar minimaal elk half uur die nieuwe gegevens als back-up naar het huidige uitwijk-datacentrum van de Protestantse kerk bij Schiphol. Toegang tot de gegevens op de back-up systemen is alleen mogelijk voor hiertoe geautoriseerd personeel. Voor mogelijke calamiteiten die zich op de centrale computerapparatuur of haar fysieke omgeving kunnen voordoen is deze extra computeromgeving ingericht als uitwijk mogelijkheid zodat beschikbaarheid blijft gegarandeerd.
31
Pagina 17 van 31
Supportorganisatie Voor het leveren van adequate support zijn er verschillende rollen / disciplines betrokken zoals servicedesk, applicatiebeheer etc. Servicedesk De servicedesk is het eerste aanspreekpunt voor de gebruiker van LRP. Het doel van de servicedesk is om vragen en klachten te registreren en de meest voorkomende problemen te kunnen verhelpen. Typische activiteiten van de servicedesk zijn: het oplossen van inlogproblemen, het beantwoorden van vragen over functionaliteit, etc. De servicedesk is een verantwoordelijkheid van het programma “Communicatie & Fondsenwerving”. LRP team Het LRP-team verzorgt de 2e lijns ondersteuning van de gebruikers (de z.g. ledendesk), uitvoering en facturatie van de betaalde dienstverlening en overige orders rond LRP, onderhoud van bovenplaatselijke gegevens en organen en het onderhoud op gemeentelijke inrichtingen (incl. het doorvoeren van fusies, federaties en aanmerkingen in LRP). Het LRP-team is een verantwoordelijkheid van het programma “Institutionele Ondersteuning”. Forum en Gebruikersvereniging Onderlinge informatie uitwisseling en ondersteuning door gebruikers onderling en met de Servicedesk worden gefaciliteerd door een web-forum. Op dit gebruikersplatform (http://LRPnetwerk.pkn.nl ) staan ook de handleidingen en worden mededelingen gedaan naar de eindgebruikers. Tevens zijn er oriënterende gesprekken geweest met een “commissie van wijze mannen” over een eventuele onafhankelijke gebruikersvereniging. Applicatie- en Functioneel beheer Applicatiebeheer heeft de verantwoordelijkheid om operationeel onderhoud van de applicatie in acceptatietest- of productieomgeving te doen. De applicatiebeheerder coördineert het uitvoeren van aanpassingen in de acceptatie- of productieomgeving van de applicatie. Functioneel beheer is verantwoordelijk voor de functionaliteit van het systeem. Dit houdt primair in het oplossen van fouten in het systeem. Hiervoor houdt functioneel beheer goede contacten aan met de software leverancier(s). Verder volgt applicatiebeheer vragen en problemen op waar de helpdesk zelf niet de expertise voor heeft of die het direct gevolg zijn van een manco in de applicatie. Daartoe heeft applicatiebeheer inhoudelijk inzicht in zowel de werking van de applicatie, als de manier waarop systemen geconfigureerd zijn, en kan de combinatie van deze kennis gebruiken om snel de oorzaak van eventuele operationele problemen te achterhalen. Typische activiteiten voor applicatiebeheer zijn: het beheren van gebruikersdocumentatie en beheren van gebruikersrechten en bijbehorende stuurtabellen, archiveren van gegevens en het analyseren van problemen om deze bij de juiste partij te beleggen en vervolgens de voortgang te bewaken. Applicatie-, functioneel en technisch beheer zijn een verantwoordelijkheid van de ICT afdeling. Technisch beheer Technisch beheer heeft de verantwoordelijkheid om de systemen en de infrastructuur waar de applicatie gebruik van maakt in te richten en te onderhouden. Deze waakt over het functioneren van de volledige hosting-omgeving, en het proactief handelen in geval van voorkomende problemen. Hierbij wordt ze geholpen door het monitoringsysteem dat continue de beschikbaarheid en prestatie van de infrastructuur meet. Deze taak wordt verzorgd door Mendix, maar zal mogelijk worden uitbesteed aan een externe partij die een partner is van Mendix. Bereikbaarheid De servicedesk is via e-mail en telefoon bereikbaar tijdens kantooruren. Er zal onderzoek worden gedaan naar de wenselijkheid en haalbaarheid of dit tijdvenster verder moet worden uitgebreid. Beschikbaarheid van het systeem Het systeem staat op een beschikbaarheid van 99,7% buiten onderhoudstijden om (dat betekent dat het systeem in totaliteit maximaal één dag per jaar buiten dienst mag zijn door storingen). Applicatiebeheer is verantwoordelijk voor het onderhoudsvenster. Uitgangspunt is om het onder-
Pagina 18 van 31
houd zoveel mogelijk te doen op momenten dat er minimaal met het systeem wordt gewerkt. In de bijlage staat een grafiekje met het gebruik over de tijden van de dag. Er worden in eerste instantie per jaar drie mogelijke onderhoudsmomenten van maximaal één werkdag of 12 uur ingeroosterd. Deze zullen alleen worden gebruikt wanneer en voor zover nodig en zullen vroegtijdig worden aangekondigd.
3.5
Randvoorwaarden & beperkingen
Deze paragraaf beschrijft de grenzen van de functionaliteit van LRP. Financiële gegevens De communicatie van financiële gegevens tussen LRP en externe systemen vindt plaats via standaard formaten. In de bijdragen administratie worden incassomachtigingen alleen gebruikt voor ClieOp03 bestanden. Acceptgiro‟s kunnen in PDF worden aangemaakt en per gebruiker kunnen de pagina marges worden ingesteld. Automatische incasso en acceptgiro zijn ondersteunde betaalwijzen binnen LRP. LRP zal in de versie 2v0 tevens worden voorzien van een koppeling voor iDeal betaalmogelijkheden welke via e-mail aan deelnemers kan worden gestuurd. Bij de versie 2v0 zal worden voorzien in een koppeling met een on-line boekhoudprogramma. De PKN heeft daarvoor een raamovereenkomst getekend met Twinfield en de KKA. Twinfield verzorgt het standaard softwarepakket met alles wat daar bij komt kijken en de KKA verzorgt de inrichting van het systeem volgens het kerkelijk model en de training en ondersteuning van de gemeenten. LRP is voorbereid op SEPA (Single European Payment Area), de nieuwe Europese standaard voor het betalingsverkeer. Invoer LRP ondersteunt het scannen van voorbedrukte formulieren met barcodes vanaf versie 2v0, bijvoorbeeld ten behoeven van een snelle verwerking van toezeggingsformulieren. Het gebruik van 3 barcodescanners wordt beperkt tot scanners die toetsenbord invoer simuleren . Deze hoeven niet met speciale software aangestuurd te worden. Het gebruik van OCR (Scanner software) om hele formulieren te “lezen” valt buiten het bereik van dit project. Andere invoer in welke vorm of formaat dan ook, wordt niet door LRP ondersteund. Er is geen geautomatiseerde functionele tweezijdige koppeling voor lokale pakketten omdat de prioriteit is gelegd bij de beveiligde web-toegankelijkheid. Er is wel voorzien in een koppeling vanuit LRP naar een lokale applicatie op basis van XML-bestanden. Dat wil zeggen dat alle aan te bieden mutaties altijd via de web-schermen van LRP moeten worden aangeboden (met de daarbij horende autorisatiecontrole van de gebruiker en de validatie van de gegevens). Hierna kan men eventueel deze wijzigingen gelijk weer uit LRP halen in de vorm van XML-bestanden om aan te bieden aan een lokale applicatie. Doordat de toegang tot LRP alleen mogelijk is middels een autorisatiesleutel is ook een mogelijk beveiligingsrisico afgevangen door geen andere toegangsmogelijkheden beschikbaar te stellen. Ook is een validatie van de gegevens mogelijk op aspecten waar een locale applicatie niet in kan voorzien, zoals personen uit andere gemeenten. Uitvoer LRP ondersteunt het geautomatiseerd aanmaken van druk, print- en verzendwerk. Het formaat dat vanuit LRP hiervoor wordt aangemaakt is PDF. Het systeem is niet verantwoordelijk voor het transport van deze documenten. De gebruiker dient dit zelf met behulp van bijvoorbeeld E-mail of
3
Toepassingsvoorbeeld: Op het toezeggingsformulier staat een barcode afgedrukt die het geregistreerdennummer bevat; de scanner leest die code en gedraagt zich naar de PC alsof iemand die cijfers heeft ingetoetst op het toetsenbord van de PC. In plaats van het intypen van het geregistreerdennummer door een persoon kan dus worden volstaan met het scannen van de barcode, dit maakt een snellere invoer mogelijk.
31
Pagina 19 van 31
FTP te doen. Aanlevering naar een eventueel landelijk gecontracteerd Print & Mail verwerkingsbedrijf is middels een secure (beveiligde) FTP-connectie gerealiseerd. Voor uitvoer van gegevens van LRP worden aanvullende formaten ondersteund. Gegevens vanuit LRP kunnen alleen in de bestandsformaten Excel / CSV of XML geëxporteerd worden. Deze bestanden kunnen vanuit de web applicatie opgehaald worden. De gebruiker is zelf verantwoordelijk voor het importeren van de gegevens in zijn lokale programma‟s, zoals een boekhoudprogramma. Systeemeisen De minimale systeemeisen voor werken met LRP zijn 1Gb intern geheugen, een Pentium 4 (of vergelijkbare CPU) en een schermresolutie van minimaal 1024 x 768; dit heeft met name te maken met de snelheid van de browser en de presentatie op het scherm. De gegarandeerd ondersteunde versies van Internet Explorer zijn 7 en 8 en van Firefox vanaf versie 2 (actuele versie is 7). Andere browsers zoals Chrome vanaf versie 3 (actuele versie is 14) of Safari van Apple worden wel ondersteund, maar zijn niet gegarandeerd. De geadviseerde minimale bandbreedte voor de internet verbinding met de centrale LRP applicatie is 1 Mbit. Dit is momenteel de bandbreedte die wordt aangeboden bij de goedkoopste ADSL of Kabel verbinding. Praktijk gebruik heeft inmiddels laten zien dat een z.g. internet “dongel” (of “dongle”) ook een werkbare prestatie geeft voor de schermafhandelingen. Voor lokale afdrukken kan gebruik worden gemaakt van alle printers die werken met A4 omdat de PDF gerelateerd zal zijn aan dat standaard formaat. Let wel dat voor het lokaal drukken van Acceptgiro‟s aan eisen van Equens moet worden voldaan. Mensen Het project heeft opleidingen verzorgd voor functie inhoudelijke aspecten. Voor het opleiden van vrijwilligers tot leden- of bijdragen administrateur bijvoorbeeld is speciaal materiaal ontwikkeld. De trainingen zijn verzorgd door een grote groep vrijwilligers.
3.6
Relaties met andere projecten
Er waren geen relaties met andere projecten voorzien, maar voor de implementatie binnen de dienstenorganisatie bleek een systeem nodig te zijn voor het administreren en factureren van de orders en ook een registratiepakket voor de servicedesk. Beide zijn gerealiseerd middels een nevenproject waarbij het CRM Dynamics pakket van Microsoft is geïntroduceerd en ingericht. Deze toepassing is binnen de reguliere begroting gerealiseerd. De aansluiting tussen LRP en het CRM pakket werd als nieuwe functionaliteit en activiteit aan het LRP project toegevoegd. Het totaalpakket om te komen tot een goede dienstverlening (organisatie, mensen en middelen, kennisopbouw, systemen, afstemming, inrichten, realiseren, testen en repareren, enz.) heeft een redelijk zware wissel getrokken op het project tijdens de implementatieperiode en is ook tot de gemeenten doorgedrongen. De gemeenten kregen namelijk niet altijd de juiste zaken of ondersteuning. Deze situatie had deels voorkomen kunnen worden wanneer in de proefdraaiperiode meer aandacht aan deze processen en het inregelen ervan was gegeven. Tegelijkertijd moet worden vastgesteld dat deze verandering een zeer fundamentele wijziging was voor de bestaande organisatie.
Pagina 20 van 31
4
Ontwikkelmethodiek
De ontwikkelactiviteiten binnen het LRP project zijn volgens de principes van model-gedreven, iteratieve, incrementele softwareontwikkeling uitgevoerd. Modellen De binnen het project ontwikkelde modellen zijn een weergave van de begrippen en werkprocessen van de Protestantse kerk voor het LRP systeem. Aangezien de modellen rechtstreeks zijn vertaald naar werkende software is de foutgevoelige tussenlaag van “het coderen” overgeslagen. Samenwerking Met de modellen als communicatiemiddel werkten gebruikers en ontwikkelaars tijdens het ontwikkeltraject samen in één team. Werkende software werd hierbij de graadmeter van voortgang. Incrementeel en iteratief De opgeleverde componenten zijn bouwstenen die bij elkaar het totale gewenste systeem vormen. Veelvuldige terugkoppeling zorgde voor goed inzicht bij zowel gebruikers als ontwikkelaars en in combinatie met modelgedreven ontwikkeling werd daardoor de flexibiliteit, productiviteit en de wendbaarheid van het ontwikkelproces verbeterd.
31
Pagina 21 van 31
5
Organisatiestructuur
De organisatiestructuur die in het projectplan was neergezet heeft goed gefunctioneerd en is alleen bijgesteld met betrekking tot het aantal en de rol van werkgroepen. Er zijn weinig tot geen aanpassingen geweest in de bemensing van het project en de aansturing ervan waardoor de continuïteit en aanwezige kennis niet in het geding is geweest. Ook kan met dankbaarheid worden vermeld dat het projectteam geen uitval door ernstige of langdurige ziekte heeft gehad. Deze continuïteit bij de bemensing heeft een heel belangrijke positieve bijdrage geleverd voor het welslagen van het project. De communicatielijnen werden kort gehouden, en er werd regelmatig en inhoudelijk gerapporteerd naar o.a. adviescommissie en synodale vergaderingen. De kleine Synode had een Adviescommissie met audit bevoegdheden in het leven geroepen van onafhankelijke ICT-deskundigen, de AdviesCommissie Ledenregistratie (ACL). Deze Adviescommissie heeft namens de kleine Synode het project van dichtbij actief gevolgd en waar nodig de bestuurder en projectmanager gevraagd en ongevraagd geadviseerd. Bij deze wil het bestuur van de Dienstenorganisatie (en het projectmanagement) graag haar dank en waardering uitspreken voor de constructieve manier waarop de adviescommissie het project met raad en adviezen heeft ondersteund. Ook haar aanwezigheid en het tonen van betrokkenheid bij bijeenkomsten met vrijwilligers is erg gewaardeerd, juist ook door die vrijwilligers. Daarbij hield de Adviescommissie tevens de vinger aan de pols, zodat zij ook in staat was om haar eigen onafhankelijke rapportage naar de kleine Synode actueel te houden. In de projectboard werd de vertegenwoordiging van de Mendix directie tegen het eind van de realisatiefase gewijzigd i.v.m. ziekte en langdurig verblijf in het buitenland. De persoonlijke betrokkenheid van de Mendix bestuurders bleef wel aanwezig en deze aanpassing heeft het project niet direct nadelig beïnvloed. Zoals genoemd zijn er kleine aanpassingen geweest in de werkgroepen, maar dit heeft geen vermeldenswaardige effecten gehad op het verloop van het project. De aanpassingen zijn gedaan bij voortschrijdend inzicht en om in te spelen op de actuele situatie. Het voert te ver om in dit eindrapport daar gedetailleerd op in te gaan, daarom wordt volstaan met deze melding. De in het projectplan geschetste werkzaamheden en taken voor de werkgroepen zijn primair van kracht gebleven.
Pagina 22 van 31
6
Projectplanning, mensen en middelen
De projectplanning geeft aan welke acties wanneer door wie worden ondernomen en wat de bijbehorende kosten zijn. De planning werd gedurende de loop van het project niet aangepast voor wat betreft de grote hoofdlijnen; wel zijn kleinere bijstellingen gedaan binnen sub-delen. Er bleek bijvoorbeeld meer doorlooptijd nodig in het KSO-deel, met name rond het fusieproces. Ook de realisatie van de functionele onderdelen van bijdragen en dienstverlening bleken iets hardnekkiger dan verwacht. Deze langere doorlooptijden hebben geen effect gehad op de totale doorlooptijd van het project omdat de realisatie van de verschillende functionele onderdelen als dakpannen over elkaar heen kon schuiven. Daardoor zaten de functionele onderdelen elkaar wel enigszins in de weg qua bemensing en tijdbeslag maar dat kon binnen de marges van het project worden opgevangen.
6.1
Randvoorwaarden
De volgende randvoorwaarden zijn door het project geraakt: In de kerkorde (Generale regelingen, art. 14 en 16) was bepaald dat de uitvoering van de ledenregistratie berust bij de stichting SMRA. De Kerkorde is op dat punt aangepast. Tevens zijn aanpassingen doorgevoerd binnen de Kerkorde rond de procedure van voorkeurleden; gemeenten kunnen nu via LRP onderling de overschrijving van voorkeurleden regelen. Ook is het nu mogelijk om personen die al of niet tijdelijk in het buitenland verblijven blijvend te registreren in LRP; zowel de mensen die vlak over de grens wonen als zij die voor langere tijd elders in de wereld verblijven. Bij vestiging van een geregistreerde in een ander kerkelijk gebied vindt altijd gelijk inschrijving plaats in een kerkelijke gemeente; in de oude situatie werd iemand eerst “tijdelijk” geplaatst. Invoering van deze verbetervoorstellen heeft tot gevolg dat er vele tientallen duizenden administratieve handelingen niet meer verricht hoeven te worden zonder dat de zorgvuldigheid en betrouwbaarheid van de registratie eronder lijdt.
6.2
Projectplanning
De planning zoals die in het projectplan was gepresenteerd is gerealiseerd met wat kleine aanpassingen; de meest opmerkelijke zijn hieronder vet gedrukt gemerkt. Omdat bij de evaluatie in e augustus 2010 was gebleken dat er nog verbeteringen nodig waren is het 2 scenario ingezet. Hierbij is het najaar van 2010 gebruikt om met het systeem te gaan proefdraaien en op meerdere terreinen verbeteringen door te voeren. Daarbij is ruim een maand eerder gestart met de productieconversie en landelijke implementatie; ook is de implementatie aan de achterkant met een maand uitgebreid waardoor de totale implementatietijd flink kon worden uitgebreid. Hieronder staan de uiteindelijke data vermeld met als referentie de oorspronkelijke geplande data.
31
Pagina 23 van 31
Bouw, Realisatie & Test Conversie Inrichten DO + gemeenten Acceptatie + Evaluatie = GO or NO GO Reparaties en verbeteringen Acceptatie + Evaluatie = GO or NO GO Voorbereiden PILOT + productie Productieconversie Pilot met gemeenten en DO Uitrol, Migratie & Implementatie LRP volledig in productie m.i.v.
6.3
Plan Einde 30-jul-10 30-jul-10 30-jul-10
Duur [wk] plan werd
Start werd
Einde werd
33 30 37
33 30 37
1-dec-09 4-jan-10 2-nov-09
30-jul-10 30-jul-10 30-jul-10
16-aug-10 20-aug-10
1
1
16-aug
20-aug
23-aug-10 11-feb-11
24
24
23-aug
11-feb
14-feb-11
18-feb-11
1
1
20-dec
23-dec
21-feb-11 25-feb-11 28-feb-11 28-mrt-11 4-jul-11
25-feb-11 28-feb-11 25-mrt-11 3-jun-11
1 0,5 4 9
2 0,5 4 17
3-jan 14-jan 31-jan 1-mrt 1-jul-2011
12-jan 16-jan 28-feb 1-jul
Plan Start
Activiteit
1-dec-09 4-jan-10 2-nov-09
Kosten
De begroting van het project was gebaseerd op calculaties die zijn gemaakt aan de hand van productbeschrijvingen en de product decompositie alsmede analyses op de data voor conversie en migratie. Uiteindelijk is gebleken dat, mede doordat we binnen de planning zijn gebleven, de uitgaven binnen de begrote kaders zijn gebleven. Hieronder staat een overzicht van de oorspronkelijk begrote bedragen voor de diverse onderdelen en de uiteindelijke uitgaven. Fase Start PoC Bouw & Ontwerp Conversie
Wat Hardware, software, training Uitvoering PoC als deelontwikkeling Algemeen en functioneel beheer, KSO, LA, BA, DV, interfaces, archivering, DO-dienstverlening LLR-mainframe, Baruch en Scipio, archief en deel historie
Testen Gebruikersdocumentatie, koppeling, 2e lijns onPilot & Impledersteuning, opleiden en instructie, overdracht, mentatie Materiaal Beheer, exploita- Autorisatiesleutels, software, gebruikersforum, intie & beveiliging cidentenmanager, helpdesk Extra helpdesk, applicatie beheer en nasleep Nazorg in 2011 conversie
Implementatie over kerkbalans heen tillen
Begroot 560.000 112.000
Uitgaven 475.852 89.250
1.024.000
888.106
519.000
364.441
36.000
25.426
574.000
1.111.873
269.000
189.764
207.000
30.821
€ 3.301.000
€ 3.175.533
464.000 € 3.765.000
352.527 € 3.528.061
Hieruit kan worden geconcludeerd dat de bouw en conversie enigszins zijn meegevallen, maar dat de implementatie meer kosten met zich heeft meegebracht dan verwacht. Dit verschil tussen begroting en geboekte kosten is hoofdzakelijk veroorzaakt doordat de kosten deels werden gemaakt en geboekt in relatie tot de fase waarin het project zich bevond. Tijdens de implementatie
Pagina 24 van 31
is veel extra aandacht gegeven aan reparaties en uitbreiding van 1v0 en van de conversiesoftware. Die extra inspanning is dus geboekt in de fase van “pilot & implementatie”, terwijl de activiteiten waren begroot als onderdeel van de bouw en conversie. Bij de nazorg lijkt ook een meevaller te zitten, maar dat komt doordat veel van de nazorg werd verzorgt door het team dat de implementatie ook verzorgde, maar dat zij hun activiteiten niet gescheiden declareerden. Door die uitgaven te combineren blijkt dat de uitgaven dicht bij de begroting zijn gebleven (2.593 en 2.583 in duizendtallen). Tevens willen wij hierbij melding maken van de structurele kosten voor de ledenregistratie en LRP en de huidige stand van zaken op het gebied van de ledenregistratie voor de landelijke kerk en haar gemeenten door een vergelijking te maken tussen het boekjaar 2006 en de begroting voor 2012. Alle bedragen in duizendtallen Rubriek m.b.t. kosten t.b.v. ledenregistratie Lasten = Personeelskosten SMRA / LRP Lasten = Apparaatskosten Lasten = Bijdrage SILA Totaal lasten Baten = Quotumbijdragen uit gemeenten Baten = Bijdragen voor dienstverlening Baten = Kosten Baruch uit gemeenten ¹) Totaal baten
Boekjaar 2006 € 1.986 € 1.770 € 504 € 4.260 € 2.672 € 1.221 € 367 € 4.260
Begroting 2012 € 918 € 1.570 € 200 € 2.688 € 2.178 € 510 €0 € 2.688
Verschil - € 1.068 - € 200 - € 304 - € 1.572 - € 494 - € 711 - € 367 - € 1.572
Personeelsformatie SMRA / LRP in FTE 33,60 17,86 - 15,74 ¹) Zonder externe commerciële pakketten of andere plaatselijke uitgaven t.b.v. ledenregistratie Opmerkelijke zaken zijn dat het benodigde personeel rond de ledenregistratie qua bezetting (en dus ook kosten) sterk is teruggebracht. De uitgaven door gemeenten aan dienstverlening zijn teruggelopen omdat gemeenten steeds meer zelf zijn gaan doen en LRP hen daartoe ook in staat stelt. Nu gemeenten kosteloos LRP kunnen gebruiken is de kostenbesparing bij de gemeenten voor de lokale applicatie (Baruch) over het geheel van de kerk inzichtelijk.
31
Pagina 25 van 31
7
Vervolg op project LRP
7.1
Huidige stand
Op het moment van schrijven zijn er ruim 1.500 gemeenten actieve gebruikers van LRP. Bij de gemeenten die (nog) niet zijn aangehaakt horen een paar Scipio gemeenten die op dit moment nog in een conversieproces zitten. Ook zijn er diverse gemeenten die om diverse redenen geen ledenregistratie systeem gebruiken, dat kan zijn omdat ze heel klein zijn (de kleinste gemeente in LRP heeft één lid, daarnaast veel met enkele tientallen tot ongeveer honderd leden), omdat er organisatorische redenen zijn (fusiegemeenten, federaties, enz.) of omdat er wel formeel een gemeente is, maar in de praktijk niet meer (opgegaan in een fusie of samengevoegde wijkgemeenten).
7.2
Versie 1v1
Gelijk na de oplevering van de productieversie van LRP in januari 2011 is gestart met het registreren en opvolgen van bevindingen die zich voordoen in de praktijk. Deze bevindingen worden geprioriteerd mede aan de hand van de (verwachte) impact. Hieruit komen zaken die met de grootste spoed gerepareerd moeten worden omdat ze blokkerend of ernstig verstorend zijn. Dit soort reparaties worden per direct of eenmaal per week aangebracht nadat ze getest zijn in een proefomgeving. Daarnaast zijn er zaken naar boven gekomen die geen noodreparatie rechtvaardigen, maar die wel in een eerstvolgende reguliere oplevering moeten worden meegenomen. Deze zaken zijn in een versie 1v1 opgeleverd die 7 juli in productie is genomen. Vanaf dat moment wordt deze registratie en opvolging weer voortgezet en ook nu worden er noodreparaties doorgevoerd wanneer noodzakelijk; de andere zaken worden doorgezet naar een volgende versie of belanden op de wensenlijst.
7.3
Versie 2v0
Zoals elders in dit document is vermeld zijn er een aantal functionele elementen uitgesteld tijdens de realisatie van het project die op dit moment alsnog worden gerealiseerd voor een versie 2v0. Deze ontwikkelingen worden bekostigd als begroot onderhoud. Het gaat om zaken zoals: Statistiek en rapportage Doelgroep gericht werven (Kerkbalans nieuwe stijl) Selecteren en exporteren van gegevens uit de bijdragen administratie iDeal gebruik voor bijdragen ontvangsten Beschikbaar stellen van en koppeling met een on-line boekhoudpakket
7.4
Nazorg en opvolging vanuit het project
Er komen nog klachten vanuit het land met betrekking tot de telefonische ondersteuning en de geboden dienstverlening. Dit zal de komende maanden moeten worden verbeterd. Tegelijkertijd zal ieder nieuw onderwerp of extra functionaliteit, opnieuw vragen voor ondersteuning oproepen. Zowel de Dienstenorganisatie als de gemeenten moeten volledig op LRP kunnen en willen vertrouwen.
Pagina 26 van 31
Er worden op dit moment nog redelijk veel denk- gebruiksfouten gemaakt in de omgang met LRP voor het onderdeel bijdragen administratie. Het is belangrijk daar op voorhand voldoende energie en aandacht aan te geven door het proefdraaien en uitproberen van de kerkbalans procedures. Daarom worden er voorzieningen getroffen: A Dat een speciale testomgeving beschikbaar wordt gesteld aan gemeenten en DO om hun fondsen en selecties te kunnen uitproberen, B Dat er mensen worden vrijgemaakt en getraind uit het LRP-team om deze toetsen uit te voeren, C Dat er mensen uit de servicedesk worden vrijgemaakt en getraind om zich het hele BA-deel eigen te maken zodat ze de gemeenten maximaal kunnen ondersteunen, D Dat er informatieavonden worden georganiseerd in het land in november en december zodat de gebruikers nogmaals en specifiek instructies krijgen voor het inrichten en uitvoeren van kerkbalans. In de reguliere en structurele begrotingen en plannen rond LRP zijn voorzieningen getroffen om het systeem te onderhouden en te beheren, maar ook om het actueel te houden met betrekking tot de eisen en wensen van gemeenten en de kerkelijke organisatie; en om het systeem mee te nemen in de nieuwe technische mogelijkheden en ontwikkelingen. Op die manier kan het systeem meegroeien met de eisen van de kerk en van de tijd.
31
Pagina 27 van 31
Bijlage 1 Afkorting / Begrip ACL BA BEB BvK C&F C&I CB ClieOp03 CRM CSV DO DO IO DV ERP FO GBA GS ICT KS KSO LLR LRP OCR OLA
ontwikkelcyclus of iteratie
P&M PC PDF PE PKN
Afkortingen en Begrippen
Omschrijving AdviesCommissie Ledenregistratie – ingesteld door de Synode Bijdragen Administratie Beheer, Exploitatie & Beveiliging Bewijs van Kunnen (ook PoC) Communicatie & Fondsenwerving (een afdeling binnen de DO) Communicatie & Instructie Concept Bewaker of Concept Bewaking Bestandsformaat voor het aanbieden van incassobestanden bij banken Customer Relation Management (standaard software om de gegevens van klanten en andere relaties te beheren en te gebruiken) Comma Seperated Value (Tekstbestand waarin elke regel data over een onderdeel vertegenwoordigd en de data van elkaar gescheiden is door een komma) DienstenOrganisatie Dienstenorganisatie – Institutionele Ondersteuning DienstVerlening Enterprise Resource Planning (pakketsoftware om een bedrijf te ondersteunen in haar bedrijfsvoering op meerdere onderdelen) Functioneel Ontwerp Gemeentelijke Basis Administratie Generale Synode Informatie en Communicatie Techniek kleine Synode Kerkelijke Structuur en Organisatie Landelijke LedenRegistratie (voormalige mainframe systeem van de SMRA) Leden Registratie Protestantse kerk Optical Character Recognition – Scannersoftware die karakters kan herkennen Optisch Leesbare Acceptgiro In het kader van dit Projectplan een bepaalde serie van handelingen die leiden tot een bepaalde afgeronde functionaliteit; de stappen zijn o.a. A. Ontwerpbespreking voor de vertaling van het “wat” naar een “hoe” B. Uitwerking van de functionaliteit in een realistisch en concreet voorstel C. Toetsing van het voorstel D. 1e iteratieoverleg voor bespreking van het voorstel en terugkoppeling E. Verwerking van de resultaten van het 1e Iteratieoverleg F. Toetsing van het Resultaat G. Volgend iteratieoverleg voor bespreking en terugkoppeling H. Verwerking van de resultaten van het Iteratieoverleg I. Acceptatie(-test) van het betrokken systeemdeel Stappen F t/m H kunnen meerdere keren doorlopen worden Print & Mail – Bedrijven die afdrukken, enveloperen en versturen Persoonlijke Computer of PostCode Portable Document Format – Een standaard om documenten over te dragen zonder dat de oorspronkelijke applicatie nodig is. Pastorale Eenheid – een aantal personen, meestal een gezin op hetzelfde adres, die gezamenlijk worden benaderd voor bijvoorbeeld bezoekwerk Protestantse Kerk in Nederland
Pagina 28 van 31
Afkorting / Begrip PL PLD PMO PoC Prince2 ProGro ProTea PvA SEPA SILA SLA SMRA SMS TO TVB WG XML
Omschrijving Projectleiding Protestants Landelijk Dienstencentrum Project Medewerkers Overleg Proof of Concept (ook BvK) PRojects IN a Controlled Environment is een gestructureerde methode voor projectmanagement met name toegespitst op ICT omgevingen Project Groep (de stuurgroep van het project LRP) Project Team Plan van Aanpak Single European Payment Area – Europese afspraken over het bancaire verkeer met consumenten en bedrijven Stichting Interkerkelijke LedenAdministratie (SILA verzorgt de koppeling vanuit de Gemeentelijke Basis Administratie (GBA) naar de aangesloten kerken) Service Level Agreement – Een set van afspraken waarin is omschreven hoe de ondersteuning en het beheer zijn geregeld Stichting Mechanische Registratie en Administratie (huidige beheerders van de landelijke ledenadministratie en dienstverleners daaromtrent, gevestigd in Utrecht, v/h Delft) Short Message Service (gebruikt om korte tekstmeldingen te sturen met mobiele telefoons) Technisch Ontwerp Taken, Verantwoordelijkheden en Bevoegdheden WerkGroep eXtensible Markup Language (een standaard voor het uitwisselen van data tussen computers)
31
Pagina 29 van 31
Bijlage 2
Artikel in de Automatisering gids van 18 augustus 2011
Pagina 30 van 31
31
Pagina 31 van 31
