Regionale uitvoering van het Bbz De ondersteuning van de bedrijfsvoering met ICT

Ministerie van SZW

Regionale uitvoering van het Bbz De ondersteuning van de bedrijfsvoering met ICT

juli 2002

Dit rapport heeft 17 pagina’s

Ministerie van SZW Regionale uitvoering van het Bbz juli 2002

Inhoudsopgave 1

Inleiding

1

1.1 1.2

Vraagstelling Aanpak

1 1

2

Functionele beschrijving

2

2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.3 2.3.1 2.3.2 2.3.3

Algemeen Procesondersteuning Werkbeheersing Registratie Documentafhandeling Autorisatie Financiële afhandeling Berekenen en betalen Debiteuren (Financiële) verantwoording

2 2 2 3 3 3 4 4 5 5

3

Een nieuwe applicatie

6

3.1 3.2

Ontwikkeling Vraagtekens bij haalbaarheid

6 7

4

Advies voor een scenario

9

5

Globale beschrijving aanpak

12

5.1 5.2

Uit te voeren activiteiten Voorstel projectorganisatie

12 14


1

Inleiding

1.1

Vraagstelling ICT-ondersteuning van de processen is van belang is voor het verhogen van de kwaliteit van dienstverlening van de Bbz-regio-organisatie. De ervaring leert dat de functionele ondersteuning voor het Bbz in de bestaande softwarepakketten van sociale diensten een achtergestelde positie heeft. De praktijk van uitvoering van het Bbz kent tal van ICTknelpunten met als eigenlijke oorzaak dat het softwareprogramma primair voor de betaling van uitkeringen voor het maandelijkse levensonderhoud ingezet kan worden. In het kader van de vorming van regio-organisaties voor uitvoering van het Bbz past het een informatie -analyse uit te voeren naar de benodigde functionaliteiten ter ondersteuning van de Bbz-processen. Resultaat is een scenario waarin wordt beschreven op welke wijze deze functionaliteiten kunnen worden gerealiseerd. Hierbij kan worden gedacht aan:

1.2

n

Het onderbrengen van de functionaliteit in de huidige sociale dienstsystemen;

n

Het separaat ontwikkelen van de gevraagde functionaliteit in de vorm van een eigen applicatie die door een private marktpartij wordt aangeboden en beheerd. De ontwikkeling kan onder regie van het departement plaatsvinden.

Aanpak Het project heeft inmiddels een aantal producties opgeleverd waarmee de regionale organisatie kan worden ingericht. De aansturing van de regio-organisatie op producten staat daarin centraal. Er is een productenboek, waarin alle primaire en secundaire producten zijn beschreven compleet met een beschrijving van de ambtelijke handelingen en de gewenste managementinformatie over dit product. Daarnaast is er een codeboek bij de productbegroting waarin per product staat aangegeven welke gegevens moeten worden vastgelegd. De in het productenboek voor het product gewenste managementinformatie is in het codeboek uitgewerkt in de noodzakelijke registraties. Voor alle producten apart is een standaard-procesbeschrijving opgesteld. De in de standaard-procesbeschrijving aangewezen functionarissen worden in een functieboek gepresenteerd en beschreven. De aansturing op producten is het uitgangspunt voor de formulering van de functionele eisen waaraan een applicatie moet voldoen om het Bbz-proces volledig te ondersteunen. Hoofdstuk twee bevat deze beschrijving op hoofdlijnen. In het derde hoofdstuk wordt een korte verkenning van de mogelijkheden voor een eigen applicatie van het Bbz gedaan. Hoofdstuk vier bevat het advies over het te volgen scenario, hoofdstuk vijf de vertaling van het advies in een projectaanpak.

2

1


2

Functionele beschrijving

2.1

Algemeen In dit hoofdstuk wordt beschreven aan welke eisen een applicatie zou moeten voldoen om het Bbz-proces volledig te ondersteunen. De beschrijving is op hoofdlijnen hetgeen betekent dat niet is gekeken naar technische eisen en eisen aan gebruikersvriendelijkheid en documentatie. Er wordt een onderscheid gemaakt in procesondersteuning en financiële afhandeling. Een applicatie waarin procesondersteuning en financiële afhandeling volledig zijn geïntegreerd, heeft uiteraard de voorkeur. De ervaring in de praktijk van uitvoering van nu dicteert dat een applicatie minimaal de bedrijfsprocessen goed ondersteunt.

2.2

Procesondersteuning

2.2.1

Werkbeheersing Een Bbz-applicatie moet alle aan de producten verbonden processen volledig ondersteunen. Het onderscheid in het productenboek in aanvragen, onderzoeken en betalingen/invordering moet worden nagevolgd. Werkprocessen in de applicatie kunnen handmatig, maar ook geautomatiseerd worden gestart (bijvoorbeeld aan de hand van de werksoort of op basis van een signaal). Vanuit een werkproces kan een ander werkproces worden gestart (bijvoorbeeld een volgend heronderzoek, een vordering aanleggen), zodat volledigheid van processen kan worden gewaarborgd. Het onderscheid in aanvragen, onderzoeken en betaling/invordering zorgt voor een gering aantal overdrachtsmomenten. Het vraagt van de betrokken medewerkers dat zij in staat zijn de applicatie voor de door hen te behandelen producten annex bedrijfsprocessen zonder fouten te gebruiken. Voor gegevensinvoer mag geen dossieroverdracht plaatsvinden. Een dubbele registratie van gegevens wordt zo voorkomen Vanuit een stap in een werkproces kunnen alle invoeren berekenschermen worden benaderd, documenten worden aangemaakt en andere applicaties worden gestart. Alle functionarissen kunnen worden opgenomen in het proces. Werk kan van de ene medewerker worden overgezet naar een andere medewerker. Vanzelfsprekend kan functiescheiding in het proces worden gewaarborgd. Verder wordt een medewerker waar nodig gerappelleerd op basis van zelf in te stellen termijnen. Een medewerker krijgt het onderhanden werk op overzichtelijke wijze gepresenteerd. Daarnaast is het mogelijk om werk van de ene medewerker over te boeken naar één of meer andere medewerkers (vakantie, ziekte, uit dienst).

3

2


2.2.2

Registratie In het codeboek is per product aangegeven welke gegevens tijdens het proces moeten worden vastgelegd. Al deze gegevens moeten ook worden vastgelegd in een applicatie. Deze vastlegging vindt plaats met behulp van logisch opgebouwde schermen. Waar nodig vinden verbandscontroles plaats op de invoer, zodat onmogelijke combinaties worden uitgesloten. Invoervelden zijn verplicht of optioneel. Automatisch wordt een mutatiehistorie van bepaalde (zelf te kiezen) gegevens bijgehouden. Van gegevens die bepalend zijn voor de hoogte van de verstrekking worden steeds begin- en einddatum bijgehouden. Daardoor is op elk moment inzicht in eerdere klantsituaties. Voorts moet elke denkbare managementinformatievraag die verder gaat dan de voortgang van de productie met behulp van de applicatie (of een ander hulpmiddel) worden beantwoord. De applicatie levert op elk gewenst moment op elk gewenst detailniveau informatie over de voortgang en resultaten van de processen, financiële informatie en beleidsinformatie.

2.2.3

Documentafhandeling De applicatie moet in de mogelijkheid voorzien om tijdens het proces brieven, formulieren, rapporten en beschikkingen te genereren. Deze documenten worden zelf door de Bbz-regio gedefinieerd. Om dubbele invoer (en fouten) te voorkomen worden alle gegevens uit de database in documenten opgenomen. Een medewerker wordt aan de hand van invoeren keuzeschermen door het document geleid. Een mogelijk lastig punt vormt de lay-out van documenten. Correspondentie wordt verzonden vanuit de Bbz-regio, maar namens de gemeente. De gemeente ondertekent in ieder geval altijd de beschikking. Dit betekent dat de applicatie de verschillende gemeentelijke stijlen (lay-out) moet aansturen. Dit vraagt om een oplossing bij de documentvorming of bij het printen (voorbedrukt briefpapier per gemeente of voor de regio). Een pragmatische oplossing is om voor een regionale huisstijl te kiezen met een handhaving van de herkenbaarheid van de betrokken gemeente. In de lay-out van de regio-organisatie is er een duidelijke plaats voor het gemeentelijk logo. Het betekent dat met één printlay-out kan worden gewerkt.

2.2.4

Autorisatie De medewerkers van de Bbz-regio voeren het gehele proces uit voor alle aangesloten gemeenten. Op zich levert dit geen specifieke autorisatieproblemen op. In ieder geval moet het mogelijk zijn om de diverse functies en daarbij behorende ‘autorisatierollen’ te registreren. Daarnaast is het belangrijk om per klant de gemeentecode te registreren. Op die

4

3


wijze wordt per gemeente een ‘subadministratie’1 gevoerd. De regio moet immers aan de gemeenten verantwoording afleggen en zo ook de gemeenten aan het Rijk. Autorisatie verdient extra aandacht als besloten wordt de aangesloten gemeenten in de Bbzregio de mogelijkheid te bieden gegevens te raadplegen. De klantgegevens van andere gemeenten moeten dan worden afgeschermd. Omdat het Bbz-regiokantoor het gehele proces voor haar rekening neemt, is een dergelijke inkijk-mogelijkheid niet noodzakelijk. Met een afsluiting van de mogelijkheid zijn een eigen oplossing vragende praktijkproblemen te voorkomen.

2.3

Financiële afhandeling

2.3.1

Berekenen en betalen Nadat een onderzoek is afgesloten volgt het beschikbaar stellen van een bedrijfskrediet, een bijdrage in het levensonderhoud of een herberekening met eventueel een nabetaling of een terugvordering. In de praktijk wordt deze fase door de huidige pakketten op verschillende wijzen ondersteund. De bedragen worden soms volledig handmatig of in Excel berekend en vervolgens handmatig opgevoerd in het socialedienst-systeem. Eén systeem (SZW+) ondersteunt al deze berekeningen (rente, omzetting levensonderhoud, terugwerkende kracht) volledig geautomatiseerd. Dit systeem wordt echter vanaf 1 januari 2003 niet meer ondersteund door leverancier Centric. De gebruikers zijn alle genoodzaakt over te gaan op het GWS4all pakket. Een gepaste ICT-ondersteuning van de bedrijfsprocessen presenteert de berekeningen en herberekeningen overzichtelijk op het scherm. In verband met de jaarvaststelling moeten herberekeningen kunnen worden uitgevoerd over een periode van drie jaar. De herberekeningsprogrammatuur is in staat automatisch te herkennen of klanten herberekend moeten worden. Naar aanleiding van een herberekening wordt automatisch nabetaald of een vordering aangelegd. Naast betalingen aan klanten, moet het ook mogelijk zijn betalingen te doen in het kader van bijvoorbeeld aangeboden cursussen en managementbegeleiding, of vanwege rekeningen voor door ingeschakelde externe deskundigen uitgebrachte rapporten (IMK en Laser bijvoorbeeld).

1

Een aparte database per bij de Bbz-regio aangesloten gemeente heeft niet de voorkeur. Dit betekent dat een medewerker steeds moet wisselen van administratie. Bovendien moet ook het beheer per administratie worden gevoerd. Dit kost extra tijd, maar heeft bovendien als risico dat er verschillen gaan ontstaan tussen de gemeenten.

5

4


2.3.2

Debiteuren De verstrekte bijstand voor levensonderhoud en bedrijfskapitaal heeft de vorm van een renteloze dan wel rentedragende geldlening. De applicatie moet de terugbetalingregelingen en renteberekeningen ondersteunen, alsmede een volledig geautomatiseerde incasso ervan. Jaarlijks wordt beoordeeld of de maandelijks termijnen worden omgezet in een verstrekking om niet. Ook hierin wordt de medewerker door de applicatie ondersteund. Als niet wordt betaald wordt automatisch de wettelijke rente bepaald. Incassostrategieën moeten door de Bbz-regio’s zelf worden bepaald en vervolgens met ICT-ondersteuning worden uitgevoerd. Per debiteur levert de applicatie een duidelijk overzicht van betaalde bedragen. Deze bedragen zijn gesplitst in aflossing en rente.

2.3.3

(Financiële) verantwoording De formele declaratie van de verstrekkingen aan het ministerie van SZW wordt door de gemeenten die zijn aangesloten bij de Bbz-regio, zelf opgesteld. Het gaat daarbij om een beperkt aantal gegevens die op het voorgeschreven declaratieformulier moeten worden ingevuld. Het Bbz-regiokantoor levert die benodigde gegevens aan. De deelnemende gemeenten incasseert zelf de vergoeding van de uitgaven op basis van de ingediende declaratie. Het regiokantoor spreekt met de deelnemende gemeenten af op welke wijze en met welke termijn de vergoedingen aan het regiokantoor worden uitbetaald. In deze formele structuur gaat het ook om gegevens voor het Verslag over de Uitvoering en het aanleveren van uitkeringsgegevens aan het CBS. De applicatie levert behalve de gegevens voor de declaratie ook deze gegevens. De verantwoording van de regio-organisatie aan de aangesloten gemeente zelf kent een planning en controlcyclus van drie maanden. Behalve de verantwoording van de geleverde kwaliteit van dienstverlening gaat het in deze driemaandenrapportages ook om de financiële gegevens die de aangesloten gemeente in de eigen boekhouding moet administreren (journalisering). De aanpak met behulp van de productbegroting moet ervoor borg staan dat alle daarvoor noodzakelijke gegevens zijn gedefinieerd en worden geregistreerd. Op basis van de applicatie worden tenslotte gegevens aangeleverd die gebruikt worden voor het uitvoeren van de Interne Controle. Het regiokantoor laat daarvoor een steekproef trekken uit het eigen cliëntenbestand. Het resultaat van de Interne Controle wordt volgens de afgesproken planning en controlcyclus aan de deelnemende gemeenten gerapporteerd. De deelnemende gemeenten kunnen de controleresultaten voor de eigen formele verantwoording aan het ministerie van SZW gebruiken.

6

5


3

Een nieuwe applicatie

3.1

Ontwikkeling Wat zou er mooier zijn dan het ontwikkelen van een applicatie die het Bbz-proces optimaal ondersteunt? Het systeem is ontworpen met gemeenten op basis van vooraf gedefinieerde producten en processen, te registreren gegevens, en functionele eisen. De sociale dienst Rotterdam heeft al eerder deze mogelijkheden onderzocht. Een uitgewerkt functioneel ontwerp (uit 1998) is beschikbaar. Voor een besluit om zelf een applicatie te ontwikkelen is een oordeel over de volgende drie punten noodzakelijk: n

het eigendom en beheer

n

centraal versus decentraal

n

de kosten.

Het eigendom en beheer Vanuit het initiatief om leveranciers te verzoeken een applicatie te ontwikkelen (dat kan bijvoorbeeld vanuit het procesmanagement voor het Bbz-project gedaan) komt ook de vraag wie de eigenaar van de nieuwe applicatie zal zijn en daarmee het toekomstig beheer zal voeren. Verschillende partijen kunnen daarvoor worden uitgenodigd. De gemeenten in een samenwerkingsverband, bijvoorbeeld, misschien Divosa of StimulanSZ. Het ministerie van SZW kan voor het eigendom zelfstandig of samen met de VNG een aparte rechtspersoon inrichten. Of misschien is en blijft de leverancier die de applicatie ontwikkelt, de eigenaar en behoudt ermee de beschikkingsmacht over de te bouwen applicatie. Verkoop, verhuur en lease zijn dan constructies die gebruikelijk zijn in de sector van sociale diensten.

Centraal versus decentraal Er kan worden gekozen een applicatie te ontwikkelen die per regio wordt geïnstalleerd en gebruikt. Decentrale installatie van de applicaties leidt er toe dat op elke regio applicatiebeheerders beschikbaar moeten zijn voor het onderhoud en de ondersteuning. Als het applicatiebeheer binnen de regio wordt ondergebracht bij de uitvoeringsgemeente dan betekent een decentrale installatie bovendien extra werkzaamheden. Het is tenslotte een geheel andere applicatie dan de applicatie die wordt ingezet voor de (meeste) overig sociale dienst-processen. Ook kan een applicatie centraal worden ontwikkeld met een centrale database. Ontsluiting van de gegevens van die centrale database kan dan via een (beveiligde) internetverbinding plaats vinden. Voordeel van een centrale applicatie is dat ook het beheer centraal plaats zal vinden. Het is ook de beste manier om een eenduidige manier van werken en vergelijkbaarheid tussen de regio’s te waarborgen.

7

6


De kosten De kosten moeten in verhoudin g staan tot de omvang van het gebruik van de ondersteuning, dat wil bijvoorbeeld zeggen het aantal klanten. Niet bekend is hoeveel Bbz-klanten er in Nederland zijn. De voorgestelde productbegroting biedt duidelijke definities van klanten maar is als instrument van aansturing een novum. Cijfers met betrekking tot de omvang van het Bbz betreffen alleen het totaal van uitgaven aan verstrekkingen en van ontvangsten aan aflossingen op uitgezette leningen. Vast staat dat het aantal Bbz-cliënten binnen de totale bijstandspopulatie gering van aantal is. Lastig aan met name het financiële gedeelte van de applicatie is dat het volledige traject moet worden gebouwd. Dat betekent betalingen, vorderingen, terugbetalingsregelingen, incasseren, herberekeningen, verantwoording, et cetera. Zeker op het terrein van de financiële afhandeling kan de vraag gesteld worden of de inspanning in een reële verhouding staat tot het te verwachten gebruik. Een onderdeel van de kosten is de ontwikkeltijd van de applicatie. De ontwikkeltijd moet in verhouding staan tot de duur van het project om regionale uitvoeringsorganisaties tot stand te brengen. Een aantal regio’s heeft aangegeven op 1 januari 2003 te willen starten. Het is niet te verwachten dat er dan al een volledige uitontwikkelde applicatie beschikbaar beschikbaar is. Voor de regio’s die starten zonder dat een eigen Bbz-applicatie beschikbaar is, moeten eigen oplossingen worden gevonden. Een gefaseerde aanpak is mogelijk. Dat wil zeggen dat ervoor gekozen wordt om eerst de primaire (voortraject)processen te ondersteunen. De financiële zaken zouden dan kunnen worden geregistreerd in de bestaande applicaties in de gemeenten. In de tweede fase wordt het financiële gedeelte van een eigen applicatie ontwikkeld. Een gefaseerde aanpak betekent dat er Bbz-deskundigheid binnen de gemeenten noodzakelijk blijft. In de eerste fase moet ook voldoende aandacht worden besteed aan de overdracht van gegevens naar de gemeenten. Voorts blijft het probleem van een onvoldoende ondersteuning voor het financiële gedeelte in de eerste fase bestaan.

3.2

Vraagtekens bij haalbaarheid Voor een eerste oordeel over de haalbaarheid van een eigen Bbz-applicatie is een verkenning van de in de vorige paragraaf genoemde factoren uitgevoerd. Het eerste genoemde punt, het initiatief / het eigendom en het beheer geeft al de nodige moeilijk te beantwoorden vragen. Op de voorhand dringt er zich niet een partij naar voren met voldoende zware belangen bij een eigen Bbz-applicatie om het initiatief voor de ontwikkeling ervan naar zich toe te trekken. De gewenste interesse zal het nodige overleg gaan kosten. Een ervaring van niet lang geleden is veelzeggend. In het kader van de WIK is gepoogd een applicatie te laten ontwikkelen onder regie van de gemeenten. Uiteindelijk is er toch voor ‘gekozen’ de WIKfunctionaliteit onder te brengen in de bestaande applicaties. Toendertijd zijn er geen

8

7


voorlopige afspraken gemaakt over regie, onderhoud, communicatie, etc. die nu benut kunnen worden. Dan het kostenaspect, het is bij voorbaat duidelijk dat de applicatie niet eenvoudig zal zijn en een relatief gering gebruik zal hebben. De ontwikkeling van een centrale applicatie biedt duidelijke kostenvoordelen. Het is niet bekend of gemeenten bezwaar hebben tegen het gebruik van een centrale applicatie. De beschikbaarheid van een volledig uitgeteste versie zal naar verwachting bovendien op zich laten wachten. De totstandkoming van regionale uitvoeringsinstanties zal gegeven de respons op de gepresenteerde plannen in een hoog tempo worden uitgevoerd. Dat betekent dat de te ontwikkelen applicatie pas ruimschoots na de start van een samenwerkingsverband beschikbaar is.

9

8


4

Advies voor een scenario ICT volgt proces. Daarmee is direct het ideaalplaatje geschetst. Het wil zeggen dat een in te zetten ICT-hulpmiddel volledig ondersteunend moet zijn aan het Bbz-proces. Het betekent ook dat alle processen worden uitgevoerd en dat alle vereiste gegevens worden vastgelegd. Ook veranderingen in de processen moet de ICT zonder onoverkomelijke problemen aankunnen. In de praktijk blijkt dat proces toch meestal ondergeschikt is aan de ICT. De ICT bepaalt voor een deel hoe er wordt gewerkt. Zoals aangegeven zijn er op dit moment slechts twee softwarepakketten beschikbaar waarmee het Bbz-proces kan worden uitgevoerd. Deze applicaties ondersteunen het Bbz-proces niet volledig, omdat ze vooral zijn gericht op ondersteuning van het ‘niet Bbz-gedeelte’ van de Algemene bijstandswet. Omdat het ontwikkelen van een volledig nieuwe Bbz-applicatie een duidelijke regie vraagt, veel tijd en geld kost en risico’s met zich mee brengt, luidt het advies voor een scenario om allereerst aan de slag te gaan met de bestaande applicaties. Met de inrichting van de ICTondersteuning van een regio-organisatie worden de knelpunten van de bestaande applicaties in kaart gebracht. De basis daarvoor bestaat uit de functionele eisen die worden afgeleid uit het gebruik van het productenboek, codeboek en procesbeschrijvingen. Wanneer de knelpunten zijn beschreven, komt vervolgens de vraag op of de leveranciers in staat en van plan zijn de applicatie binnen afzienbare tijd – in termen van de voortgang van het Bbz-project – aan te passen. Hiervoor is overleg met die leveranciers natuurlijk noodzakelijk. Het procesmanagement kan hiervoor het initiatief nemen. Ook het periodiek overleg dat het ministerie van SZW met de leveranciers heeft over ontwikkelingen en de consequenties voor applicaties kan daarvoor worden gebruikt. Als de leveranciers niet in staat of van plan zijn gewenste en voorgestelde aanpassingen door te voeren, moet de volgende stap worden gezet: n

Wordt de situatie geaccepteerd hetgeen betekent dat wordt gekozen voor een niet optimale ondersteuning door de bestaande applicaties of

n

Wordt de mogelijkheid onderzocht een specifieke Bbz-applicatie te ontwikkelen, door de markt onder regie van bijvoorbeeld het ministerie.

Wordt de situatie geaccepteerd dan moet de mogelijkheid van een aanvullende en structurele oplossing worden onderzocht. Wordt de mogelijkheid van een specifieke Bz-applicatie onderzocht dan speelt een vergelijkbare vraag of zolang met de bestaande mogelijkheden wordt gewerkt dan wel naar (tijdelijke) oplossingen voor leemten in het gebruik wordt gezocht. Niet mag worden verwacht dat binnen nu en een jaar een passende Bbzondersteuning beschikbaar is. Deeloplossingen moeten worden beoordeeld. Voorts moet er een bedrijf worden gevonden dat de applicatie wil ontwikkelen. Kosten en tijd spelen zo een belangrijke rol.

10 9


Alles overwegende is het advies om nu te investeren in een standaardinrichting van de bestaande applicaties. Deze standaardinrichting kan in de praktijk van uitvoering van een daarvoor uitgenodigde regio-organisatie worden vormgegeven. Vervolgens kan de standaardinrichting aan de regio’s worden aangeboden. De voorbereiding van de standaardinrichting brengt de verschillen tussen de voorgestane en de te realiseren ondersteuning in beeld. Het is verstandig om de huidige leveranciers erbij te betrekken. Ten aanzien van de gemiste ondersteuning moet overwogen worden of een al of niet tijdelijke oplossing gewenst is en zo ja, welke oplossing mogelijk is. De standaardinrichting kan voor het einde van dit jaar gerealiseerd zijn, inclusief een beschrijving van de gemiste onderdelen en mogelijke oplossingen daarvoor. De gemeente Rotterdam heeft zich bereid verklaard mee te werken aan een standaardinrichting van GWS4all. Het resultaat van het ontwikkelingstraject voor een standaardinrichting biedt goede aanknopingspunten om de vraag naar de (vooral randvoorwaardelijke) mogelijkheden voor een zelf te ontwikkelen applicatie weer op te pakken. Mogelijk leidt het traject zo uiteindelijk tot de beste ondersteuning van het Bbz-proces, mogelijk ook tot een beeld van de ondersteuning van Bbz-regio-organisaties op termijn. In schema weergegeven: Opzetten standaardinrichting

Analyse bestaande applicaties

Vooronderzoek nieuwe applicatie -regie -planning -kosten -beheer

Overzicht knelpunten en verbeterwensen

Bespreken met leveranciers

leveranciers willen aanpassen ?

nee

js

termijn acceptabel?

nee

nee

accepteren?

nee

haalbaar?

js js

Rol zoeken in ontwikkeling

Implementeren geoptimaliseerde applicatie

Zoeken tijdelijk alternatief

Zoeken naar alternatieven ter ondersteuning bestaande applicaties

Ontwikkelen nieuwe applicatie

Bestaande applicatie inzetten

11 10


Een voorstel van een traject voor een standaardinrichting voor de Rotterdamse regio ziet er als volgt uit: n

Het projectteam bestaat in ieder geval uit een vertegenwoordiger van het Bureau Zelfstandigen en Scheepvaart, een applicatiebeheerder van de afdeling sociale zaken en werkgelegenheid en een vertegenwoordiger van het procesmanagement regionale uitvoering Bbz. De agenda van te verrichten werkzaamheden wordt gezamenlijk opgesteld. De vertegenwoordiger van het procesmanagement bewaakt de voortgang van het traject;

n

Het traject gaat van start met een inhoudelijke voorbereiding van de standaardapplicatie . Zo kan de waarde van de onderzoeksrapportage van 1998 over een functioneel ontwerp als leidraad worden beoordeeld en waar nodig inhoudelijk worden geactualiseerd. Deze taken zullen vooral door de vertegenwoordiger van het Bureau Zelfstandigen en Scheepvaart samen met de vertegenwoordiger van het procesmanagement regionale uitvoering Bbz worden verricht;

n

Aan de hand van het inhoudelijke basisstuk gaat de applicatiebeheerder van de afdeling sociale zaken en werkgelegenheid aan het werk om de applicatie zoals inhoudelijk voorbereid voor de Bbz-werkzaamheden in te richten.

12 11


5

Globale beschrijving aanpak

5.1

Uit te voeren activiteiten n

voorbereiding (projectaanpak, verdieping inzicht huidige situatie)

n

installatie (nieuwe testomgeving en productieomgeving voor de regio)

n

werkbeheersing (inrichting van de werkprocessen, documenten, autorisaties)

n

financiële gedeelte (berekenen/betalen, debiteuren, verantwoording)

n

managementinformatie

n

ingebruikname (gegevens van oud naar nieuw, instructie)

Voorbereiding n Plan van aanpak n

Inrichten projectorganisatie

n

Beslissing te gebruiken omgeving (in huidige productieomgeving opnemen of aparte Bbz-omgeving creëren)

n

Beoordelen huidige inrichting werkprocessen

n

Beoordelen huidige documenten

n

Beoordelen inrichting berekenen/betalen/debiteuren

Installatie n Nieuwe productieomgeving aanmaken (afh. keuze apart of integraal) n

Nieuwe testomgeving aanmaken

n

Systeemautorisaties regelen

n

Koppeling tekstverwerking

n

Omgevingen opnemen in backup-procedure

Werkbeheersing n Bekijken mogelijkheden meergemeentefunctionaliteit n

n

Codetabellen -

Inventarisatie in te vullen tabellen

-

Inrichting tabellen (a.h.v. Bbz-productenboek, codeboek)

Werkprocessen

13 12


n

n

-

Bepalen te ontwikkelen werkprocessen (a.h.v. Bbz-productenboek)

-

Bepalen standaardopbouw werkproces

-

Ontwerpen werkprocessen (a.h.v. Bbz-processenboek)

-

Opvoeren werkprocessen

Autorisaties -

Opvoeren regiogemeenten

-

Bepalen inrichting/rollen

-

Invoeren organisatie

-

Invoeren gebruikers

-

Toewijzen autorisaties aan gebruikers

-

Opnemen autorisaties in werkprocessen

Documenten -

Beoordelen mogelijkheden

-

Omzetten brieven

-

Omzetten beschikkingen

-

Omzetten rapportages

-

Omzetten formulieren

n

Integraal testen werkprocessen

n

Bijstelle n inrichting

Financiële gedeelte n Bekijken mogelijkheden meergemeentefunctionaliteit n

Berekenen/betalen -

n

Inrichten tabellen

Debiteuren -

Inrichten tabellen

-

Onderzoeken aanmaningensystematiek

-

Onderzoeken ontvangstenadministratie

-

Documenten: ola’s

14 13


n

Verantwoording -

inrichten journalisering/grootboek per gemeente

-

CBS

-

declaraties/jaaropgaven

n

Testen meergemeentefunctionaliteit

n

Onderzoeken mogelijkheden aanvullende ondersteuning

Managementinformatie n Beoordelen huidige managementinformatie n

Bepalen gewenste managementinformatie

n

Ontwikkelen procesinformatie

n

Ontwikkelen financiële informatie (a.h.v. productenboek)

n

Ontwikkelen beleidsinformatie (a.h.v. productenboek/CBS)

Ingebruikname n Hangt af van wijze waarop klantgegevens worden overgezet n

Schaduwrun? à kan alleen bij overzetten/conversie, sowieso moet een test op de juistheid worden uitgevoerd (schaduwrun)

n

Instructie? à kleine groep, bekend met GWS4all, dus op de werkplek lijkt me

Vraagpunten n Wijze overzetten klantgegevens Bbz? Overzetten of opvoeren? n

5.2

Verantwoording? In hoeverre inrichten en aanpassen op gemeente?

Voorstel projectorganisatie Coördinatiegroep Leden:

hoofd Bureau Zelfstandigen & Scheepvaart hoofd I&A procesmanagement als secretaris

15 14


Taken:

bewaken algehele voortgang creëren randvoorwaarden wegnemen evt. knelpunten nemen van besluiten

Projectoverleg Leden:

functioneel beheerder technisch beheerder procesmanagement

Taken:

bewaken voortgang in detail uitzetten activiteiten signaleren knelpunten contacten met Centric

De functioneel beheerder is verantwoordelijk voor de inrichting van werkprocessen en financieel gedeelte en de managementinformatie, de technisch beheerder is verantwoordelijk voor installatie en organisatie van het (technisch) beheer. Bij de uitvoering van de activiteiten (met name bij het meedenken over het ontwerp en het testen) kunnen ook andere medewerkers, met name van BZ&S worden betrokken.

16 15

Regionale uitvoering van het Bbz De ondersteuning van de bedrijfsvoering met ICT

Recommend Documents