1
Onderzoek tevredenheid van Scipio gebruikers met LRP in februari 2012 44 terugontvangen enquêteformulieren van de 112 PKN leden
Status als LRP gebruiker: Gebruikt uw gemeente LRP al? Ja 35 Alleen voor het binnenhalen van mutaties 11 Nee 9 Waarom nog niet? Zijn nog bezig met conversie 1 Nog te veel fouten in LRP 9 Heeft uw gemeente de conversie al gedaan? Ja 32 ,maar nog niet doorgevoerd in Scipio ivm de grote verschillen 4 Nee 8 Waarom nog niet? Wachten al bijna een jaar op aangevraagde en beloofde conversie Worden, ondanks fusie in 2007/8, in LRP nog apart als NH en GK gezien LRP bestand komt niet overeen met onze administratie Weet u al wanneer wel? februari 2012, echter nog niets gebeurd Als we door LRP als een gemeente worden gezien of wacht nu nog ergens op en waarop dan? Tot alle kinderziektes opgelost zijn Tot wij zelf de fouten eruit hebben gehaald, want LRP doet dat niet Op een beter pakket
2 3 1 1 2 1 1 1
Tevredenheid over LRP: Als uw gemeente LRP gebruikt hoe tevreden bent u dan? Goed 2 Redelijk 12 Slecht 17 Als u niet tevreden bent, kunt u hieronder kort beschrijven wat uw voornaamste problemen zijn? Snelheid helpdesk 13 Gebruiksvriendelijkheid 14 XML koppeling 10 Onbetrouwbaarheid 14 Conversie 7 Heeft uw gemeente financiële schade opgelopen door het gebruik van LRP. Ja 2 Nee 22 Zoals fors minder inkomsten (voorbeeld PKN Leeuwarden) Nee 12 Of inzet meer mensen/uren om de ledenadministratie up to date te houden? Ja 27 Nee 5
2
Helpdesk LRP: Wat vindt u van de deskundigheid van de LRP helpdesk? goed 11 onvoldoende 14 slecht 11 nvt 1 Wat vindt u van de telefonische bereikbaarheid van de LRP helpdesk? goed slecht 6 Wat vindt u van snelheid waarmee een vraag/probleem wordt opgelost? goed slecht 14 Bent u tevreden over de oplossingen en antwoorden die u krijgt? ja 13 nee 21 Wat vindt u van de hulpvaardigheid van de LRP helpdesk? goed 19 matig 10 slecht 6 Blijft men voldoende klantvriendelijk? Ja 29 Nee 4
Hoofdadministratie: Gebruikt u LRP als hoofdadministratie Ja, voor ledenadm. 3 Nee 41 Hebt u geprobeerd LRP als hoofdadministratie te gebruiken Ja 4 Nee 31 Is dat mislukt, waarom? Op structuur en functionaliteit 3 Grote afwijkingen in selecties tov Scipio 2 Gebruikt u Scipio als hoofdadministratie Scipio 38 Scipio Online 4 Alleen financieel 3
XML koppeling voor communicatie tussen LRP en Scipio of Scipio Online Wat zijn uw ervaringen met deze koppeling Goed Slecht Wordt nog niet gebruikt Lukt alleen met Firefox Scipio filter werkt nog onvoldoende
4 16 10 1 3
3
Opmerkingen van de ondervraagde gemeenten. (proef de woede, de teleurstelling, de wanhoop, de frustratie, het verdriet, het onvermogen mee) Het heeft heel lang (en na veel aandringen) geduurd voordat de conversie was uitgevoerd Zeer ontevreden over de conversie, zeer veel nawerk Vertrouwen in juistheid gegevens in Scipio verdwenen na gebruiken XML koppeling, gezonde Scipio is besmet met vervuilde data uit LRP Heb de laatste tijd mutaties in LRP gemuteerd en daarna zelf in Scipio verwerkt. De XLM koppeling wel opgehaald, maar daarna gedelete, dus niet doorgevoerd. Die paar mutaties zelf muteren werkt sneller dan al die anderen op te halen en zo ook bij overlijden en vertrek PE 00000000 binnen te halen. Haagsma zegt dat dit anders wordt. LRP heeft moeilijke structuur voor abonnementen enz. De mutaties worden 1 keer per week opgehaald. Vervelend is dat nog elke week ruim 100 personen als ingeschreven worden vermeld op de mutatielijst, dit zijn personen die al lang in Scipio staan. Het is mij nog niet duidelijk waarom dit is. Er zijn personen uitgevallen die wel in Scipio zijn blijven staan, maar geen ‘kerkbalansvinkje’ meer hebben. De helpdesk is niet slagvaardig. De helpdesk is erg zakelijk en afstandelijk. Het kan of het kan niet. Een tussenweg is er niet. Zeer trage behandeling/afhandeling van klachten De helpdesk verwijst vaak door naar het LRP team of naar Hagru Als helpdesk medewerkers horen dat je Scipio gebruiker bent zijn ze stug, onvriendelijk. De helpdesk medewerkers lopen tegen dezelfde problemen aan als de Scipio gebruikers, ze worden daardoor wat behulpzamer en opener. Er komt een wisselwerking op gang. LRP reageert niet op opmerkingen in fora. LRP gaat er teveel van uit dat KB’s overdag bereikbaar zijn, veel mensen werken ’s avonds De XML koppeling is uitgevoerd zonder gegeven toestemming Via XML koppeling veel onzinnige mutaties, veel werk om lokaal bestand schoon te houden Inhoudelijk zijn de mutaties via XML zeer onoverzichtelijk en moeilijk te beoordelen Er zijn /worden eindeloos veel uren besteed aan herstellen van data Er moeten twee systemen bijgehouden worden Zeer teleurgesteld dat de DO dit programma, dat nog niet klaar was voor gebruik, tegen wil en dank heeft uitgebracht. De DO verstuurd echter wel rekeningen voor extra werk dat ze daardoor moet doen. Ergernis over de nog steeds tendentieuze berichtgeving dat LRP zo goed is uitgevoerd en qua ontwikkeling zo mooi binnen de begroting is gebleven, terwijl na oplevering nog heel veel zaken in het programma uitgevoerd moesten worden. Hiervoor betalen we dan rechtstreeks of via het quotum. Waar en wanneer kunnen wij bij de DO een rekening indienen voor de door de invoering van LRP extra gemaakte uren? Sinds we mutaties van LRP in Scipio inlezen staan bij de nieuw ingekomen leden (in geval van een echtpaar) de aanschrijving op individueel. Terwijl dat in het verleden bij de man (als men beide lid is) standaard op combinatie aanschrijving stond. Erg veel onnodige mutaties van niet meer actieve leden.
4 Waarom staan sommige personen drie keer in LRP, heb ik niet gedaan. Lees ik in kostenplaatje LRP; verwijderen personen die dubbel in LRP staan, € 7,00…….., en dat voor iets waar wij echt niets aan kunnen doen, (handeling heeft tocht echt in Utrecht plaatsgevonden) Er is gebrek aan duidelijkheid over interpretatie van de kerkorde en de implementatie daarvan in LRP, bijvoorbeeld mbt blijkgever, meegeregistreerde enz. Incidenteel klantonvriendelijke medewerkers op helpdesk LRP, collega helpdeskmedewerkers wisten dan wel om welke personen het ging.….. Gemeenten die al 5 jaar gefuseerd zijn staan nog steeds apart geregistreerd in LRP, daardoor kan o.a. niet geconverteerd worden. De helpdeskmedewerkers die we aan de lijn krijgen zijn over het algemeen wel vriendelijk. Wat niet klantvriendelijk overkomt is dat uit de reacties blijkt dat de vraag niet helder is, laat staan het antwoord. De bereikbaarheid is vaak slecht, lang wachten, verbinding verbroken en niet aanwezig zijn of doorverbinden en dan blijkt er niemand te zijn. Al met al ruim onvoldoende. We hebben Scipio gebruikt bij de actie kerkbalans en zijn daar tevreden over. Als we gebruik hadden gemaakt van LRP zou de opbrengst waarschijnlijk lager zijn geweest omdat naar mijn mening de LRP bestanden niet 100 % goed zijn. Via de XML-koppeling krijgen we heel veel mutaties binnen waar we niets mee kunnen, bovendien krijgen we sommige wijzigingen meerdere keren door. Zelf ben ik al een aantal keren binnengekomen als nieuw lid, terwijl ik al vele jaren op het zelfde adres woon. De helpdesk wordt als ondeskundig ervaren en biedt geen oplossing voor onze vragen. Gemeenten in grensgebieden hebben leden met adressen in het buitenland, die komen niet door in S-O. ‘Adres-onbekend’ in LRP heeft in S-O de normale adresstatus. Er bestaat geen echt tweezijdig mutatieverkeer. Daardoor moet in beide pakketten gewerkt worden. Eigenlijk is het maar eenzijdig mutatieverkeer. Ophalen en klaarzetten voor import gaat goed, bij het verwerken heel veel moeilijk te verklaren mutaties Het is een drama Functionaliteit Scipio zeer veel beter We zijn vorig jaar helemaal opnieuw met Scipio gestart. Samen met Hagru zijn alleen de ledengegevens via een opzetbestand opnieuw ingelezen. Onvoorstelbaar wat daarvoor komt kijken als LRP leidend is. Momenteel staat Scipio op een laag pitje, als we dan zo veel moeten investeren in tijd om het allemaal lopende te krijgen en te houden: dan maar in LRP. Jammer dat van Scipio gebruikers vrijwel geen ondersteunende informatie is te vinden. De verouderde handleidingen voldoen helaas niet meer. We hebben voor 2012 weer betaald, aan het eind van het jaar zien we of we helemaal stoppen met Scipio.
5 Als gemeenteleden binnen onze gemeente verhuizen worden ze toch eerst ingevuld bij de plaatselijke Herv. Gemeente. Eerder gebeurde dat alleen bij verhuizingen van buiten de gemeente. Dat betekent veel extra werk, omdat we deze mensen in het kerkelijk register moeten opzoeken en ze weer moeten laten overschrijven. Bovendien zijn de 30 dagen bedenktijd uit onze ledenadministratie verdwenen. Als van een echtpaar iemand overlijdt, wordt de overledene losgekoppeld van de partner en krijgt PE-code 00000. Pastoraal kan het van belang zijn om ze bij elkaar te houden (op een gezinskaart bijv.) Dit kan als men na de melding in LRP de overledene weer de PE-code van de partner meegeeft. Dit moet dan wel direct gebeuren, want later is de overledene al verdwenen in het kerkelijk register. Wel wordt in de geschiedenis van de partner de overlijdensdatum nog vermeld. We moeten alle datums nu zelf via attestaties nakijken en wijzigen in LRP. Volgens de helpdesk hadden we direct na de koppeling moeten reageren. Dit heb ik herhaaldelijk geprobeerd, maar ik kreeg geen of te weinig reactie. Conversie was niet naar tevredenheid, heel veel nawerk Tip voor Scipio gebruikers: voor je het opzetbestand installeert eerst belangrijke gegevens (status, sectie, kerkbalans e.d.) vastzetten in eigen velden. Die worden niet overschreven en zo kun je ook na het ophalen van mutaties steeds even vergelijken met de situatie vóór LRP, heb ik heel veel baat bij gehad. Na eerste mutatie download weer heel veel fouten. Bijvoorbeeld zes overledenen die weer actief waren geworden. Let op: ontdekt door vergelijking met eerder ingevulde eigen velden in Scipio Het gebruik van de XML koppeling verliep in het begin nogal problematisch door het verschil in interpretatie van data in LRP en Scipio omdat Scipio gebaseerd is op de oude SMRA systematiek. LRP heeft een heel andere logica. Veel oude gegevens zijn verloren gegaan of verkeerd overgenomen. Het is qua te investeren tijd en energie ondoenlijk om uit te zoeken waar dit door Scipio of het LRP komt. De koppeling wordt wel steeds beter en corrigeert nu zelfs ook LRP onduidelijkheden. Verder is hier nog het probleem dat de verwerking van XML bestanden in Scipio zeer langzaam gaat. Naar ik begrepen heb is dat in meerdere gemeentes het geval waar Scipio op een netwerk server draait en wordt er door Hagru aan gewerkt dit probleem te verhelpen. De XML koppeling lijkt een noodoplossing. De mutaties komen wel binnen in Scipio, maar op een zeer verwarrende manier, zonder uitsplitsing van mutatiesoorten, en overbodige en al bekende mutaties vanuit LRP komen steeds weer binnen. Het verwerken van de mutaties kost veel meer tijd dan voorheen. De XML koppeling vervult het Scipio bestand is mijn indruk. Een in Scipio ingevoerd cor. adres is na het inlezen van het XML bestand weer verwijderd. Kamernummers in verzorgingstehuizen verdwijnen ook steeds weer op mysterieuze wijze. Nieuw ingekomenen komen in sectie 0 terecht, dat moet dan zowel in Scipio als in LRP gecorrigeerd worden.
6
Korte samenvatting van enquêteantwoorden en opmerkingen Uit meer dan 20 procent van de terugontvangen enquêtes blijkt dat LRP nog helemaal niet gebruikt wordt. De conversie heeft voor grote problemen in betrouwbaarheid van de gegevens gezorgd, gebruik van de XML koppeling houdt dit nog steeds in stand. Het lijkt erop dat recente conversies nog dezelfde problemen geven als die in het begin, heeft LRP de conversieproblemen dan nog niet kunnen oplossen? Tweezijdig mutatieverkeer met de XML-koppeling?, echt niet! Gemeenten zien zich gedwongen twee systemen bij te houden omdat volledig gebruik van de XML koppeling voor datavervuiling zorgt, dat kost veel meer tijd en energie. Gemeenten die LRP ‘gebruiken’ doen dat bijna allemaal alleen om de mutaties binnen te halen om ze dan handmatig te verwerken in Scipio. De LRP helpdesk scoort alleen voldoende op hulpvaardigheid en klantvriendelijkheid. LRP was niet klaar voor gebruik toen het midden 2011 werd vrijgegeven door de PKN, de helpdesk was niet voorbereid en schiet zwaar tekort in ondersteuning op niveau.
