Ministerie van Sociale Zaken en Werkgelegenheid
Postbus 90801 2509 LV Den Haag Anna van Hannoverstraat 4 Telefoon 070 333 5750 Telefax 070 333 4085 http://gemeenteloket.minszw.nl
Het cliëntvolgsysteem (CVS) in de praktijk: meerdere systemen beschikbaar, zorgvuldige keuze vereist!
Een overzicht en analyse van de medio 2002 in de markt beschikbare CVS'en en een handreiking voor het opstellen van de eisen die door een WIZ-dienst aan een CVS kunnen worden gesteld, alsmede een opzet voor de selectie en implementatie daarvan.
Inhoud Voorwoord: waarom deze handreiking lezen?
5
Inleiding Handreiking cliëntvolgsysteem ontbreekt nog De hoofdstructuur: marktverkenning en handreiking
7 7 7
Deel 1: De markt in beeld
9
1 SUWI: ingrijpende gevolgen voor de bedrijfsvoering Sluitende Aanpak in perspectief De keten als uitgangspunt Casemanagement als 'motor' voor de Sluitende Aanpak De strategie- en regiefunctie moet worden vormgegeven SUWI & ICT: vele aanpassingen noodzakelijk De koppeling aan de voorkant: het CWI De koppeling aan de achterkant: het Inlichtingenbureau Stelselmaatregelen De Sluitende Aanpak vraagt om een CVS binnen WIZ-diensten Doelstelling CVS: de casemanager centraal! Processen zijn leidend en moeten in kaart worden gebracht Vertaling referentiekader naar generieke eisen CVS
11 11 12 13 13 14 14 15 16 17 17 17 17
2 De marktverkenning van cliëntvolgsystemen Zes leveranciers bieden een pakket aan Baas & Roost Advies/Imwin voor Windows Centric Public Sector Solutions/GWS4all-module reïntegratie Horlings & Eerbeek/EBB-Trajecten PinkRoccade Civility/Traject-Assistent Stratech/Masterlink Transfer Solutions/MVS Type leverancier: pakketaanbieder of dienstverlener Gehanteerde werkwijze: zoek de verschillen Toetsingskader als basis voor vergelijking
19 19 19 20 20 21 21 22 22 23 23
3 Analyse van de aangeboden pakketten Ondersteunde regelingen: alleen regie Abw of ook additionele arbeid Relatie met inkoop: geen of volledige ondersteuning van inkoop Flexibiliteit van de inrichting: vast ingesteld of volledig inrichtbaar Procesondersteuning: afwezig of compleet Flexibiliteit van gegevensmodellering: geen of alle gegevens te veranderen Koppelingen met uitkeringssystemen: geen of volledige integratie Rapportages: standaard in of volledig buiten het pakket Gebruikersgroepen: individuele benadering of gebruikersgroep Fase ontwikkeling van product: ideestadium of reeds jaren in productie Organisatie leverancier: kleinschalig of grootschalig Prijs van het product: gratis of een groot kapitaal Flexibiliteit technische architectuur: wel of niet inpasbaar
25 25 25 26 27 28 30 31 31 32 33 34 36
3
Deel 2: De gemeenten aan zet
39
4 Nadenken is de eerste stap De casemanager: keuze maken rond de rol en positie Nieuwe vaardigheden voor de casemanager noodzakelijk De casemanager doet het niet alleen Processen moeten worden (her)ingericht De inrichting van de strategie- en regiefunctie nzet ICT adequaat voorbereiden Conclusie: belangrijkste (beleids)keuzes vooraf maken
41 41 41 42 43 43 44 45
5 Proces van selectie en aanschaf zorgvuldig doorlopen Een goed Programma van Eisen maakt de selectie makkelijker Achtergrondinformatie geeft ook de leverancier extra inzicht Onderdelen van een Programma van Eisen Vervat functionele eisen in elementaire gesloten (ja/nee) vragen Zorg voor een gebalanceerde weging van de onderdelen Stel open vragen voor extra inzicht Maak de kosten van de verschillende pakketten vergelijkbaar Europese aanbesteding noodzaak? Ondertekening contract is het sluitstuk
47 47 47 47 47 48 49 49 51 51
6 Implementatieplan is een kritieke succesfactor De aandachtsgebieden van een implementatie: bedrijfsvoering leidend Bedrijfsvoering: kaal of niet kaal Documenten: wie wat wanneer? Installatie: is de machinerie op orde? Conversie: een schone lei Acceptatie: doet-ie het of doet-ie het niet? Een projectmatige aanpak van de implementatie is noodzakelijk Beschouw zowel de eenmalige als de structurele kosten
53 53 54 54 54 55 55 55 57
Nawoord
59
A Voorbeeld Programma van Eisen
61
B Gebruikte afkortingen
67
4
Voorwoord: waarom deze handreiking lezen? Hoe selecteer ik een goed cliëntvolgsysteem? Met die vraag worstelt menige gemeente. Sinds de invoering van de wet SUWI (Samenwerking Uitvoering Werk & Inkomen) is er veel veranderd. Gemeenten zijn verantwoordelijk geworden voor de regie van het reïntegratieproces van cliënten. Een geautomatiseerde ondersteuning van de bedrijfsprocessen helpt hierbij. Waarschijnlijk weet u dat er verschillende leveranciers een aanbod hebben op dit gebied. Aan u de taak om de beste toepassing voor uw gemeente te zoeken. Hoe? Deze handreiking kan u daarbij helpen. In deze handreiking vindt u een toetsingskader dat u kunt gebruiken bij de selectie van een cliëntvolgsysteem. We hebben ook de eisen op een rijtje gezet die de wet SUWI stelt aan een dergelijk systeem en de gevolgen die dat heeft voor de vastlegging en koppeling van gegevens. Verder vindt u in deze handreiking een marktverkenning. We hebben namelijk zes pakketten van verschillende leveranciers bij verschillende gemeenten met elkaar vergeleken en de ervaringen hiermee beschreven. Kortom, we hopen dat de selectie en implementatie van een cliëntvolgsysteem voor u hiermee makkelijker wordt. Heeft u nog vragen, neem dan contact op met het Steunpunt Suwi Gemeenten of met StimulanSZ.
Jos Kok directeur Uitvoering Werk en Inkomen Met dank aan de gemeenten Amsterdam, 's Hertogenbosch, Horst aan de Maas, Leeuwarden, Nijmegen en Zaanstad voor hun bijdrage.
5
Inleiding De invoering en implementatie van SUWI (Samenwerking Uitvoering Werk & Inkomen) en in het verlengde daarvan de Sluitende Aanpak en de Agenda voor de Toekomst, hebben grote gevolgen voor de WIZ-diensten1) op vele terreinen van hun bedrijfsvoering. Om deze gevolgen in kaart te brengen zijn door zowel het Steunpunt SUWI gemeenten, StimulanSZ als Divosa inmiddels diverse handreikingen verschenen, waardoor de WIZ-diensten gebruik kunnen maken van ervaringen die reeds elders zijn opgedaan (zodat het wiel niet telkens opnieuw hoeft te worden uitgevonden).
Handreiking cliëntvolgsysteem ontbreekt nog Een van de gevolgen voor de bedrijfsvoering van WIZ-diensten is de noodzaak om een cliëntvolgsysteem (CVS) te selecteren en te implementeren voor de eigen organisatie, zodat de registratie van de reïntegratieactiviteiten van cliënten (richting werk, additionele arbeid of zorg) adequaat kan worden vormgegeven2). In algemene termen gesteld is dit niet alleen van belang voor de sturing en beheersing van de relevante processen, maar ook voor de verantwoording die in het kader van de Agenda van de Toekomst en anderszins moet worden afgelegd. Tegen deze achtergrond is een marktverkenning uitgevoerd naar een aantal CVS'en, die momenteel op de markt verkrijgbaar zijn. Het zijn er vele, in een verschillend stadium van ontwikkeling. Teneinde het aanbod en de marktverkenning enigszins te beperken (en overzichtelijk te houden) is daarbij als 'selectiemaatstaf' voor deelname van leveranciers 'het hebben van een WIZ-dienst als klant' gehanteerd. Impliciet werd daarmee aangegeven dat de geselecteerde CVS'en van waarde zijn voor WIZ-diensten (ten minste één dienst heeft hiervoor reeds gekozen), anderzijds werd het daardoor mogelijk de ervaringen van de klanten (de WIZ-diensten) bij de marktverkenning te betrekken.
De hoofdstructuur: marktverkenning en handreiking Bij de opzet van dit boekje is gekozen voor een tweedeling, namelijk een marktverkenning enerzijds en een handreiking voor WIZ-diensten anderzijds. In afbeelding 1 is deze hoofdstructuur weergegeven.
Afbeelding 1: de hoofdstructuur
1) In dit boekje zal consequent de benaming "Werk, Inkomen, Zorg - diensten" worden gehanteerd, in plaats van de traditionele benaming Gemeentelijke Sociale Diensten (GSD). WIZ-diensten doen meer dan het verstrekken van uitkeringen alleen! 2) WIZ-diensten kunnen dit zelf implementeren, dan wel in (regionaal) samenwerkingsverband.
7
Deel 1 van dit boekje geeft, naast een algemeen overzicht van de gevolgen van SUWI voor de WIZdiensten, een beeld van de uitgevoerde marktverkenning naar CVS'en. Deel 2 geeft een handreiking voor de implementatie van een CVS: de noodzakelijke keuzes binnen de eigen organisatie, de aanpak van de selectie van een CVS en ten slotte de implementatie daarvan.
Op deze plaats willen wij zowel de leveranciers van CVS'en als de deelnemende WIZ-diensten bedanken voor hun bijdrage aan de marktverkenning.
8
DEEL 1: DE MARKT IN BEELD In het eerste deel van dit boekje wordt een beeld geschetst van zowel de algemene ontwikkelingen en gevolgen van SUWI, alsook van de uitgevoerde marktverkenning van CVS'en. Dit deel kunt u beschouwen als het referentiekader, op basis waarvan u zelf binnen uw eigen organisatie aan het werk kunt gaan: (a) de algemene ontwikkelingen rond SUWI geven de vraagstukken aan die van belang zijn en vervolgens een vertaling vragen naar uw eigen organisatie (wat betreft processen, functies en inzet van ICT); (b) de marktverkenning van de CVS'en schetst een beeld van de beoordeelde systemen en de verschillen die daartussen bestaan, gericht op diverse (belangrijke) items. Op basis van de keuzes vanuit uw eigen organisatie en de lokale situatie dient u zelf te bepalen welke eisen vanuit uw eigen organisatie relevant zijn voor een CVS. Met dit referentiekader in het achterhoofd, kunt u de (noodzakelijke) koers en keuzes voor uw eigen organisatie bepalen. In het tweede deel van dit boekje zal daarvoor een handreiking worden geboden, onderstaand is een samenvatting opgenomen van het eerste deel. Vanuit het SUWI-perspectief kunnen diverse gevolgen worden vastgesteld, die in twee hoofdgroepen kunnen worden onderscheiden. Deze komen in hoofdstuk 1 aan de orde. Allereerst heeft SUWI gevolgen voor de WIZ-processen rond diverse aspecten, zoals de aanpassing van de intake (samenwerking met het CWI), de invoering van casemanagement, de vormgeving van de regiefunctie rond inkoop en de inrichting van het bedrijfsverzamelgebouw. Met name de invoering van casemanagement is een belangrijke (en complexe) stap, aangezien daarmee uiting wordt gegeven aan een nieuwe werkwijze en een nieuw dienstverlenings-concept. Ten tweede heeft SUWI (ingrijpende) gevolgen voor de inzet van ICT binnen de WIZ-diensten. Hierbij gaat het zowel om de registratie van reïntegratieactiviteiten door middel van een cliëntvolgsysteem als om de landelijke ICT-ontwikkelingen rond de koppeling aan de 'voorkant' (met het CWI) en de koppeling aan de 'achterkant' (met het Inlichtingenbureau). Andere implicaties zijn de noodzaak om aan te sluiten op een aantal 'technische' aspecten van SUWI (sectorloket, SUWInet en gegevensstandaardisering) en de vraag in hoeverre een koppeling met reïntegratiebedrijven (RIB's) aan de orde is. Voor de ondersteuning van de Sluitende Aanpak in brede zin, dus zowel het volgen van de reïntegratieactiviteiten van de cliënten, de inkoop van trajecten als de noodzakelijke rapportages, is de invoering van een cliëntvolgsysteem voor de WIZ-diensten onontkoombaar. Teneinde de WIZ-diensten bij de keuze en selectie van een dergelijk systeem te ondersteunen, is een marktverkenning uitgevoerd naar een aantal van deze systemen (zes in totaal). Deze marktverkenning is, wat betreft de aanpak, opgenomen in hoofdstuk 2. Er zijn ongetwijfeld nog meer systemen op de markt beschikbaar, maar de nu geselecteerde en beoordeelde systemen worden alle bij minimaal één WIZ-dienst gebruikt, zodat van de ervaringen van die WIZdiensten gebruik kon worden gemaakt. De beoordeling van de CVS'en heeft plaatsgevonden aan de hand van een zogenoemd 'toetsingskader', waarin de belangrijkste eisen die aan een dergelijk systeem kunnen worden gesteld, zijn vastgelegd. Daarnaast heeft voor elk van de systemen een 'demo- en interviewdag' plaatsgevonden, waarin naast het bekijken van de werking van het systeem zelf, interviews hebben plaatsgevonden met de belangrijkste spelers binnen de WIZ-diensten (eindgebruikers, de applicatiebeheerder, de technisch beheerder, de I&A-manager, de eindverantwoordelijke lijnmanager en de softwareleverancier). Deze interviews dienden de door de leveranciers op papier aangegeven functionaliteiten van de systemen te bevestigen. De resultaten van de beoordeling van de CVS'en (hoofdstuk 3) laten zien, dat er diverse overeenkomsten tussen de beschikbare systemen zijn, doch ook vele (majeure) verschillen. Deze verschillen hebben betrekking op alle onderscheiden hoofdeisen, die aan de systemen kunnen worden gesteld, dat wil zeggen:
9
(a) functionele eisen: realisatie van MoSA en SUWI-gegevensset, ondersteuning van inhoudelijke regelingen, ondersteuning van het inkoopproces, de geboden procesondersteuning, koppeling naar uitkeringssystemen; (b) technische eisen: flexibiliteit van de inrichting, flexibiliteit van de gegevensmodellering, de rapportagemogelijkheden en de flexibiliteit van de technische architectuur; (c) gebruikerseisen: rol van de gebruikers bij de (verdere) ontwikkeling; (d) leverancierseisen: fase van de ontwikkeling van het product, de organisatie van de leverancier en de prijs. Uit deze beoordeling komt niet naar voren of de systemen 'goed of slecht' zijn, integendeel. De verschillen tussen de diverse aangeboden systemen zijn inzichtelijk gemaakt en het is aan de WIZ-diensten om te bepalen welke eisen men aan een CVS wenst te stellen en hoe men de geconstateerde verschillen wil beoordelen. Dit zal afhankelijk zijn van vele (lokale) omstandigheden.
10
1 SUWI: ingrijpende gevolgen voor de bedrijfsvoering Met de invoering per 1 januari 2002 van SUWI (Samenwerking Uitvoering Werk & Inkomen) als institutioneel kader en in het verlengde daarvan de afspraken rond de Sluitende Aanpak en de Agenda voor de Toekomst, zal er voor gemeenten veel gaan veranderen c.q. zullen reeds lopende veranderingen binnen de WIZ-diensten in een stroomversnelling geraken. Deze veranderingen hebben betrekking op de WIZprocessen enerzijds en op de inzet van ICT binnen de WIZ-diensten anderzijds. In afbeelding 2 zijn de belangrijkste wijzigingen na SUWI schematisch opgenomen.
Afbeelding 2: de gevolgen van SUWI voor de WIZ-diensten
In dit hoofdstuk zullen de gevolgen van SUWI voor de WIZ-diensten in hoofdlijnen worden beschreven, als achtergrond en basis voor de inhoud en positionering van een toekomstig cliëntvolgsysteem (CVS) binnen de (eigen) organisatie. De verdere uitwerking in termen van processen, functies en inzet van ICT binnen de eigen WIZ-dienst zal in hoofdstuk 4 aan de orde komen. Sluitende Aanpak in perspectief De WIZ-diensten zullen zich verder gaan ontwikkelen van een verstrekker van uitkeringen tot een regisseur op het terrein van reïntegratie van cliënten. De minister van Sociale Zaken en Werkgelegenheid (SZW) heeft de gemeenten verantwoordelijk gemaakt voor het realiseren van een Sluitende Aanpak van alle uitkeringsgerechtigden. Dit wil zeggen dat iedere uitkerings-gerechtigde binnen één jaar een passend aanbod moet krijgen van de gemeente om weer deel te nemen aan het maatschappelijk verkeer door werk, gesubsidieerd werk of sociale activering. Daarbij dient overigens te worden opgemerkt dat ook niet uitkeringsgerechtigden (NUG'ers) en de ANW'ers (Algemene Nabestaanden Wet) met ingang van 1 januari 2002 tot de verantwoordelijkheid van de gemeente behoren. Deze Sluitende Aanpak van cliënten vraagt om ingrijpende aanpassingen: (a) allereerst zal aansluiting gezocht moeten worden bij de partners in de 'keten', zowel aan de 'voorkant' bij het Centrum voor Werk en Inkomen (CWI) en de af te sluiten Service Niveau Overeenkomst (SNO), als aan de 'achterkant' bij de reïntegratie-bedrijven; 11
(b) ten tweede zal casemanagement geïntroduceerd moeten worden, primair als uiting van een gewenste andere benadering van de cliënt en de daarbij behorende dienstverlenende cultuur; (c) tot slot dient de zogenoemde 'strategie- en regiefunctie' (kortweg de inkoop) richting de reïntegratiebedrijven en zorgtrajecten vorm te worden gegeven. Het moge duidelijk zijn dat bovenstaande ontwikkelingen grote gevolgen (zullen) hebben voor de cliënten, de medewerkers en het management van de WIZ-diensten, alsmede voor de bedrijfsvoering van deze diensten. De keten als uitgangspunt De uitgangpunten van SUWI zullen moeten worden vertaald in een dienstverleningsconcept, waarbij de gehele keten van werk en/of zorg alsmede inkomen de basis is. Kernthema's daarbij zijn dicht bij de burgers wat betreft dienstverlening, werk boven inkomen als principe en een Sluitende Aanpak als resultaat. Daarmee kan de regie op de keten (en de Sluitende Aanpak) vorm worden gegeven, waarbij in elk geval de volgende vragen beantwoord dienen te worden: (a) hoe kan aan de (nieuwe) dienstverlening op de terreinen werk, zorg en inkomen vorm worden gegeven? (b) wat is de rol van de gemeenten (WIZ-diensten) in deze keten in relatie tot de overige partners? (c) van welke principes gaat de ketendienstverlening uit: bijvoorbeeld de cliënt als maat voor de dienstverlening, één aanspreekpunt voor de cliënt? Zijn deze vragen beantwoord, dan kan de vertaling plaatsvinden van de Sluitende Aanpak naar een hanteerbaar werkproces voor de WIZ-dienst en kan bepaald worden hoe iedere cliënt (uitkeringsgerechtigd of niet) een traject richting werk en/of zorg aangeboden kan worden en vervolgens dit proces gestuurd en beheerst kan worden. Het referentiemodel dat StimulanSZ 3) aanbiedt, verdeelt dit proces in drie stappen: (a) het CWI-proces (de start voor nieuwe cliënten); (b) het gemeentelijk proces van de sluitende aanpak, bestaande uit: (i) het vaststellen van het recht op uitkering en het opstellen van een trajectplan, met een link naar de ondersteunende processen (bijvoorbeeld de inkoop); (ii) casemanagement: het starten, volgen en het bijstellen van het trajectplan; (iii) heronderzoeken naar de rechtmatigheid; (iv) beëindiging van de uitkering en nazorg; (c) de externe processen: reïntegratie, zorg en andere gemeentelijke processen. In afbeelding 3 is schematisch een voorbeeldproces opgenomen.
Afbeelding 3: een voorbeeldproces Sluitende Aanpak 3) Het werkproces naar een sluitende aanpak, een referentiemodel voor alle gemeenten. Stichting StimulanSZ, Den Haag (www.stimulansz.nl).
12
Casemanagement als 'motor' voor de Sluitende Aanpak Bij de Sluitende Aanpak wordt de invoering van casemanagement als het sleutelbegrip gezien. Het algemene uitgangspunt ten aanzien van casemanagement is dat: "de casemanager hét aanspreekpunt voor de cliënt zal zijn voor de uitkeringsverstrekking (inkomen) en trajecten richting werk en/of zorg. De casemanager beziet de onderlinge samenhang tussen werk, inkomen en zorg en is daarmee de regisseur van het traject". Uit bovenstaande 'definitie' blijkt de hoe de rol van de (huidige) consulent zal veranderen in die van casemanager4). Tot voor kort was de WIZ-dienst en daarmee de consulent met name het aanspreekpunt voor de cliënt wat betreft de uitkeringsverstrekking. In de nieuwe rol zal de casemanager in het algemeen de spin in het web zijn voor de cliënt, zowel intern binnen de eigen organisatie (naar andere functionarissen) als extern voor het CWI en de zorg- en reïntegratiebedrijven. In de praktijk blijkt dat casemanagement verschillende verschijningsvormen kent. De lokale invulling is onder andere afhankelijk van de doelstellingen rond de bestuurlijke, financiële en personele situatie in de gemeente. Op grond van onderzoek5) zijn de volgende vier hoofdmodellen te onderscheiden: (a) het integrale model: de casemanagers zijn voor een vast deel van het cliëntenbestand verantwoordelijk voor de rechtmatige en doelmatige verstrekking van de uitkering. De casemanager managed het activerings- en/of reïntegratietraject; (b) het brugmodel: de casemanagers zijn, voor een vaste groep cliënten die toegeleid kunnen worden naar instrumenten die reïntegratie bevorderen, verantwoordelijk voor het trajectplan, het opdracht geven tot uitvoering daarvan en de bewaking op de naleving door de cliënt en de uitvoerende organisatie. In dit model handelt de uitkeringsconsulent de aanvraag af; (c) het specialistenmodel: evenals in het brugmodel is de casemanager verantwoordelijk voor de toeleiding van een vaste groep cliënten naar instrumenten die de reïntegratie bevorderen. Er wordt echter een specialisatie aangebracht tussen werk en zorg. Er zijn 'casemanagers werk', voor klanten die op middellange termijn kunnen uitstromen naar werk. Daarnaast zijn er 'casemanagers zorg', die intensieve dienstverlening aanbieden aan cliënten die op lange termijn wellicht kunnen uitstromen; (d) het netwerkmodel: het netwerkmodel volgt de ontwikkelingen rond SUWI en de bedrijfsverzamelgebouwen. De casemanager krijgt de gegevensset van het CWI en stelt het recht op uitkering vast. De casemanager voert daarnaast de regie over het traject dat bij het reïntegratiebedrijf word ingekocht. De casemanager toetst daarbij de inspanningen/ vordering van zowel de cliënt, als die van het reïntegratiebedrijf. Hoewel er dus vele verschijningsvormen in het land worden aangetroffen, wordt in ieder geval onderkend dat casemanagement niet alleen betrekking heeft op alle aspecten die van belang zijn voor het opstellen en monitoren van trajecten van cliënten, maar dat ook een nadrukkelijke koppeling moet worden gelegd met de aspecten van de uitkeringenverstrekking. Niet zozeer het te hanteren model, maar het dienstverleningsconcept dient het uitgangspunt bij de invulling van de functie van de casemanager te zijn6). De strategie- en regiefunctie moet worden vormgegeven De strategie- en regiefunctie neemt binnen de WIZ-diensten een steeds dominantere rol in, enerzijds vanwege de verschillende partners waarmee wordt samengewerkt en anderzijds vanwege de omvangrijke geldstromen en het toenemende belang van uitbesteed werk.
4) Daarbij hoeft niet persé sprake te zijn van een 'transformatie' van de consulent naar casemanager. Dit zal afhankelijk zijn van de concrete invulling van de rol van de casemanager en de daarmee samenhangende (gewenste) vaardigheden. Deze kunnen vervolgens worden afgezet tegen de huidige situatie. 5) Casemanagement in de praktijk. Een beschrijving van casemanagement praktijken bij drie GSD-en, A. du Pree-van der Slik, Utrecht, juni 2000. 6) In het vervolg op deze vier basismodellen voor casemanagement heeft inmiddels een verdere uitwerking en detaillering plaatsgevonden van casemanagement, gekoppeld aan het mogelijke dienstverleningsconcept van de WIZ-dienst en vertaald in een profiel (rollen) en competenties voor de casemanager. Deze handreiking komt binnenkort beschikbaar: "Maatwerk in klantmanagement, dienstverleningsconcept, profiel en ontwikkeling", StimulanSZ, juni 2002.
13
Een goed uitgewerkte visie op deze strategie- en regiefunctie is van groot belang om efficiënt en effectief te kunnen opereren op het terrein van de reïntegratiemarkt in relatie tot casemanagement. In afbeelding 4 is de strategie- en regiefunctie schematisch weergegeven. Uitgaande van dit model zijn de volgende functies te onderscheiden: (a) de strategiefunctie richt zich op het 'macro-proces' van de Sluitende Aanpak, namelijk het bepalen van het 'wat'. De door de gemeente te ontwikkelen visie zal moeten worden vertaald in producten (welke producten en hoeveelheden), uitmondend in een op te stellen Programma van Eisen (het bestek) voor de in te kopen trajecten; (b) de inkoopfunctie: de daadwerkelijke inkoop en het afsluiten van contracten op basis van het opgestelde Programma van Eisen.
Afbeelding 4: de strategie- en regiefunctie
(c) de planning- en controlfunctie voor de control, planning en voortgang van de ingekochte producten. Deze is zowel intern gericht (hoe staan we er als WIZ-dienst voor?), als extern richting de bedrijven/instellingen (wordt ook daadwerkelijk geleverd wat er is ingekocht?). Daarnaast is de planning en controlfunctie van belang als het gaat om de verantwoording wat betreft het ministerie (te denken valt hierbij aan Monitor Scholing en Activering en de Agenda van de Toekomst, maar ook de verantwoording als het gaat om de rapportages rond de gesubsidieerde arbeid). SUWI & ICT: vele aanpassingen noodzakelijk De implementatie van SUWI zal, wat betreft de inzet van ICT, op drie fronten consequenties hebben voor de WIZ-diensten, namelijk de 'koppeling aan de voorkant' (CWI), de 'koppeling aan de achterkant' (Inlichtingenbureau) en een aantal stelselmaatregelen die nodig zijn om het stelsel te laten functioneren. De koppeling aan de voorkant: het CWI De zogenoemde 'koppeling aan de voorkant' heeft betrekking op de koppeling tussen de intake in het CWI en de WIZ-dienst, alsmede het mogelijk maken van het 'inkijken' (door het CWI) in gegevens van de WIZ-dienst. In afbeelding 5 is dit inzichtelijk gemaakt.
14
Afbeelding 5: de koppeling 'aan de voorkant'
Bij deze koppeling spelen zowel inhoudelijke als organisatorische vraagstukken een rol. De inhoudelijke vragen hebben vooral betrekking op de uitkeringsintake, die door het CWI wordt verricht: om welke gegevens gaat het, worden deze alleen verzameld of ook geverifieerd, hoe komen deze naar de WIZ-diensten, dient op basis van deze gegevens nog aanvullende actie te worden ondernomen of kan direct worden overgegaan tot de claimbeoordeling? De beantwoording van deze vragen zal mede afhankelijk zijn van de afspraken, die in de SNO zijn gemaakt. De (digitale) koppeling tussen de intake van het CWI en het WIZ-systeem is een aangelegenheid die landelijk zal worden vormgegeven. De organisatorische vragen hebben betrekking op de positionering van het CWI en de WIZ-dienst (of delen daarvan): komt er een Bedrijfsverzamelgebouw, welke onderdelen van de WIZ-dienst worden daarin ondergebracht, hoe dient de aansluiting plaats te vinden op de midoffice en de backoffice van de WIZ-dienst, enzovoorts. Deze vragen moeten worden beantwoord, wil een adequate invulling worden gegeven aan de uit te voeren sluitende aanpak (doelmatigheid). De koppeling aan de achterkant: het Inlichtingenbureau Ook de 'koppeling aan de achterkant', gericht op de rechtmatigheid van het uitkeringsproces, heeft grote gevolgen voor WIZ-diensten, zowel in technische zin als in organisatorische zin. Het Inlichtingenbureau (IB) zal voor alle WIZ-diensten bij derden gegevens verzamelen, waarmee de rechtmatigheid van de verstrekte uitkeringen op een effectievere en efficiëntere wijze kan worden gecontroleerd en vastgesteld. In afbeelding 6 is dit schematisch weergegeven.
15
Afbeelding 6: de 'koppeling aan de achterkant'
Vanuit inhoudelijk perspectief komt vooral de vraag aan de orde welke organisatorische consequenties de implementatie van het IB heeft voor de WIZ-diensten. Momenteel worden deze effecten in pilots (het 'LAT-project' in Leeuwarden, Apeldoorn en Tilburg) bezien. In technische zin zal de aansluiting op het Inlichtingenbureau (IB) moeten worden geregeld, waarvoor de Stichting Inlichtingenbureau de verantwoordelijkheid heeft. Naar verwachting zullen de (traditionele) heronderzoeken naar rechtmatigheid op termijn vervallen, evenals de inkomstenbriefjes en de belastingsignalen. Mutatieverwerking, ingepast in een hoogwaardig handhavingsbeleid, zal de toekomst zijn. Stelselmaatregelen Voor de werking van het ICT-stelsel van SUWI zijn een aantal aanvullende ontwikkelingen noodzakelijk: (a) allereerst zal er een landelijke aansturing moeten worden ingevoerd om het nieuwe ICTstelsel te laten werken. Het SUWI-stelsel is gebaseerd op een hoge mate van gegevensuitwisseling tussen de (autonome) kolommen (CWI's, UWV en WIZ-diensten), hetgeen impliceert dat een aantal informatiekundige afspraken moet worden gemaakt voor de onderlinge afstemming. Daarvoor is inmiddels het 'Bureau Keteninformatisering Werk & Inkomen' (BKWI) opgericht; (b) deze onderlinge afstemming komt met name naar voren bij de definiëring van de uit te wisselen gegevens. De gezamenlijke gegevens dienen eenduidig benoemd en gespecificeerd te worden in termen van syntax (schrijfwijze), semantiek (betekenis) en geldigheidsduur. Inmiddels zijn deze vastgelegd in het zogenoemde 'SUWI-gegevensregister'. Dit wordt ook wel 'raakvlakstandaardisering' genoemd. Naast de gegevens zelf zullen zogenoemde 'gegevenssets' moeten worden benoemd, teneinde het berichtenverkeer tussen de kolommen eenduidig te benoemen; (c) om berichten te kunnen ontvangen in het stelsel, dan wel cliënten binnen de sociale zekerheid te kunnen identificeren, dient elke kolom te beschikken over een zogenoemd 'sectorloket' als aanspreekpunt voor de kolom. Dit is een technisch loket, dat als doorgeefluik kan fungeren, maar tevens zal bijhouden 'wie bij welke kolom in het stelsel cliënt is'. Inmiddels is besloten dat het Inlichtingenbureau deze functie gaat vervullen voor de gemeenten.
16
De Sluitende Aanpak vraagt om een CVS binnen WIZ-diensten Tegen de achtergrond van de hierboven geschetste ontwikkelingen in het kader van de Sluitende Aanpak in brede zin mag het duidelijk zijn dat de cliënt van de WIZ-dienst goed gevolgd moet kunnen worden. Het volgen van de cliënt beslaat het gehele proces: van intake tot mogelijke uitstroom en alles wat daar 'tussen in zit' (en dat geldt zowel voor nieuwe cliënten als voor bestaande cliënten). Doelstelling CVS: de casemanager centraal! Ondanks de verschillende verschijningsvormen van casemanagement en de daadwerkelijke invulling van de strategie- en regiefunctie, kan in het licht van de Sluitende Aanpak de volgende centrale doelstelling voor een CVS worden weergegeven:
“Het ondersteunen van de regiefunctie van de casemanager, bij het motiveren en activeren van cliënten (doelmatigheid) en het bewaken van de uitkeringsverstrekking (rechtmatigheid) door het maken en bewaken van afspraken met de cliënt en externe partners”
Processen zijn leidend en moeten in kaart worden gebracht Gegeven de doelstelling van de Sluitende Aanpak zullen de processen binnen de WIZdiensten in kaart gebracht moeten worden. Het gaat hierbij om de zogenoemde primaire en de secundaire processen die samenhangen met casemanagement. In afbeelding 7 zijn deze processen benoemd.
Primaire processen casemanagement 1. Ondersteunen van het motiveren en activeren van cliënten ('op traject zetten') 2. Onderhouden van relatie met uitkeringsverstrekking (via uitkeringensysteem) 3. Monitoren van cliëntactiviteiten (wat gebeurt er door/met een cliënt in het kader van de uitkering en de activering) Secundaire processen casemanagement 4. Onderhouden van relatie met inkoop en contractbeheer (incl. facturering) 5. Bewaken van declarabiliteit (met name richting WIW, ESF en FWI) 6. Creëren van managementinformatie (t.b.v. procesbesturing), beleidsinformatie (t.b.v. inkoop, CBS, bestandsanalyses) en verantwoordingsinformatie (MoSA en Agenda van de Toekomst). Afbeelding 7: de primaire en secundaire processen van casemanagement
Vertaling referentiekader naar generieke eisen CVS Het geschetste algemene referentiekader rond SUWI en de benoemde primaire en secundaire processen voor casemanagement, kunnen nu worden vertaald in een aantal generieke eisen, die aan een CVS kunnen worden gesteld7). De hoofdstructuur van deze eisen is opgenomen in afbeelding 8.
7) Bewust wordt hier gesproken over generieke eisen. Iedere WIZ-dienst zal, afhankelijk van de lokale invulling van de Sluitende Aanpak en casemanagement, alsmede de eigen organisatiekenmerken (bijvoorbeeld de besturingsfilosofie en de huidige inzet van ICT) zelf een gedetailleerd Programma van Eisen moeten opstellen voor een CVS. In het tweede deel van dit boekje zal hierop worden teruggekomen.
17
Afbeelding 8: hoofdstructuur eisen voor een CVS
Gekoppeld aan deze hoofdstructuur kunnen de volgende mogelijke eisen worden benoemd: (a) generieke WIZ-eisen: (i) de mogelijkheid van koppeling met de intake van het CWI (ii) voldoen aan de wettelijke verplichtingen, zoals het gebruik maken van de SUWIgegevensset en het genereren van MoSA (b)functionele eisen: (i) ondersteuning van het primaire en secundaire proces casemanagement (wat betreft de inhoudelijke regelingen) (ii) adequate procesondersteuning voor de casemanager (iii) ondersteuning van de inkoopfunctie (iv) het kunnen genereren van noodzakelijke managementinformatie (sturings-, beleidsen verantwoordingsinformatie) (v) een mogelijke koppeling met het uitkeringensysteem (c) gebruikerseisen: (i) een gebruiksvriendelijk systeem als adequate ondersteuning van de casemanager (d)technische eisen: (i) een 'open' systeem, waardoor koppelingen en gegevensuitwisselingen mogelijk zijn (binnen de eigen WIZ-dienst of in de keten) (ii) een architectuur die gebruik maakt van (wereld)standaarden (e)leverancierseisen: (i) aspecten rond de (organisatie van de) leverancier zelf, het stadium van de ontwikkeling van het pakket en de prijs. Deze generieke eisen zijn, ten behoeve van de marktverkenning, vertaald in een uitgewerkt Programma van Eisen (bijlage A). Voor de eigen situatie zullen deze generieke eisen moeten worden vertaald in een gedetailleerd Programma van Eisen. Afhankelijk van de lokale invulling van de Sluitende Aanpak zullen ook de eisen, die aan een CVS worden gesteld, kunnen verschillen. Het is dan ook cruciaal voor de keuze van een CVS om de eigen inrichting van de Sluitende Aanpak en casemanagement expliciet in beeld te brengen en vervolgens de prioriteiten ten aanzien van de gewenste functionaliteiten te bepalen. Op die manier wordt 'automatisch' rekening gehouden met de lokale verschillen, alsmede met het verschil tussen grote, middelgrote en kleinere gemeenten! 18
2 De marktverkenning van cliëntvolgsystemen Diverse leveranciers zijn snel ingesprongen op de vraag naar geautomatiseerde ondersteuning voor de (primaire en secundaire) processen die moeten worden uitgevoerd in het kader van de Sluitende Aanpak binnen de WIZ-diensten. Dit hoofdstuk geeft een schets van de markt voor cliëntvolgsystemen en typeert de betrokken leveranciers. Er zijn veel cliëntvolgsystemen die ondersteuning bieden bij het uitvoeren van een breed spectrum aan reïntegratietaken. Organisaties die gebruik maken van deze applicaties zijn te vinden in zowel het publieke als private domein. Behalve WIZ-diensten zijn stichtingen voor de uitvoering van de WIW ca., reïntegratiebedrijven en WSW-bedrijven eveneens afnemer. In de context van deze marktverkenning zijn pakketten van zes leveranciers in ogenschouw genomen. De vergelijking tussen de pakketten is gemaakt op basis van een toetsingskader, dat vooraf aan de betrokken leveranciers is verstrekt. Een belangrijk resultaat van deze audit is een overzicht van overeenkomsten en verschillen tussen de aangeboden pakketten (zie hoofdstuk 3). Zes leveranciers bieden een pakket aan Geautomatiseerde oplossingen voor het volgen van cliënten worden verzorgd door een aantal aanbieders. Bij de selectie van leveranciers voor deze marktverkenning zijn alleen die leveranciers gevraagd te participeren, die hun pakket reeds bij één of meerdere WIZdiensten hebben geïmplementeerd of in pilot hebben. Impliciet wordt daarmee aangegeven dat de geselecteerde CVS'en van waarde zijn voor de WIZ-diensten (minimaal één dienst heeft hiervoor reeds gekozen), anderzijds werd het daardoor mogelijk de ervaringen van de klanten (de WIZ-diensten) bij de marktverkenning te betrekken. Aan deze marktverkenning hebben zoals gezegd zes leveranciers deelgenomen. Dit zijn dus niet de enige leveranciers, maar de selectie geeft een goed beeld van de markt. In onderstaande tabel wordt voor elk van de leveranciers aangegeven welk softwarepakket zij aanbieden en welke organisatie eigenaar is van het pakket. Leverancier Baas & Roost Advies Centric PSS Horlings & Eerbeek PinkRoccade Civility Stratech Transfer Solutions
Pakket Imwin voor Windows GWS4all (module Reïntegratie) EBB-Trajecten Traject-Assistent Masterlink MVS
Eigenaar Baas & Roost Advies Centric PSS Horlings & Eerbeek PinkRoccade Civility Stratech Gemeente Amsterdam
De kenmerken van de leveranciers, hun pakketten en hun visie worden hierna, in alfabetische volgorde, in hoofdlijnen verwoord. Baas & Roost Advies/Imwin voor Windows Baas & Roost Advies verleent diensten op het gebied van organisatieadvies en implementatie van in eigen beheer ontwikkelde softwareoplossingen en oplossingen van andere leveranciers. De markten die bediend worden zijn hoofdzakelijk die van de sociale zekerheid, de lokale overheid en het onderwijs waarbij met name wordt ingezet op voortgezet onderwijs en Regionale OpleidingsCentra's (ROC's). Baas & Roost Advies heeft 80 fte aan medewerkers in dienst en is tevens in Duitsland actief. Imwin voor Windows bestaat sinds 1997 en er zijn sindsdien 159 implementaties van het pakket gerealiseerd. Met name WIZ-diensten, WIW-instellingen, WSW-bedrijven en 19
reïntegratiebedrijven gebruiken het pakket. Van de 159 implementaties hebben er 95 plaats gevonden bij WIZ-diensten. Het pakket is primair bedoeld voor regievoering èn uitvoering van alle voorkomende reïntegratiemogelijkheden. Het levert daarbij de wettelijk vereiste verantwoordingsinformatie (statistieken en declaraties) voor de WIW, WSW, I/D-banen, REA, regie Abwcliënten (inclusief MoSA) en WIN. In de huidige vorm wordt het pakket door de leverancier ondersteund tot 1 januari 2004. Na de zomer van 2002 introduceert Baas & Roost Advies reeds de opvolger iw3 in de markt. Vanaf dat moment zullen bestaande klanten gaan migreren naar iw3 en kunnen nieuwe implementaties plaatsvinden. Imwin voor Windows is een client-servertoepassing bestemd voor het Windowsplatform. De opvolger iw_ is webbased, opgebouwd volgens een meer lagenarchitectuur en ondersteunt onder meer de databases Microsoft SQL-server en Oracle. Het nieuwe pakket is volledig gericht op de toekomstige reïntegratiemarkt en kent nog uitgebreidere workflowmanagement ondersteuning dan diens voorganger. Centric Public Sector Solutions/GWS4all-module reïntegratie Centric PSS is een grote leverancier van software voor lokale overheden met ca. 3000 fte aan medewerkers. Centric is actief in Nederland, Duitsland en België op het gebied van kantoorautomatisering, opleidingen en softwareoplossingen. GWS4all is het strategische product van Centric voor WIZ-diensten. GWS4all is op dit moment operationeel bij 130 WIZ-diensten in Nederland. Bij circa 65 WIZ-diensten loopt op dit moment een implementatieproject voor GWS4all (versie 3 release 1) en dit jaar komen daar naar schatting nog 70 WIZ-diensten bij. Aan personeel is direct 90 fte betrokken bij het product. Onderwerp van deze audit is de module reïntegratie van het pakket. Deze module is (operationeel) beschikbaar sinds 1 mei 2002 (GWS4all bestaat sinds medio juli 2000). Centric geeft aan dat de module inmiddels door 49 gemeenten is besteld en dat de implementaties op dit moment plaats vinden. Het pakket GWS4all van Centric biedt een geïntegreerde oplossing voor uitkeringenverstrekking én reïntegratie. Het pakket is geschikt voor zowel grote als kleine gemeenten. Centric heeft als doelstelling om het totale (lokale) proces van werk, zorg en inkomen te ondersteunen. In de huidige release wordt het lokale proces van werk en inkomen ondersteund. De functionaliteit op dit gebied zal in de volgende versie verder worden uitgebreid. GWS4all biedt op dit moment volledige ondersteuning van berichtenverkeer op basis van XML/SOAP. In de toekomst zal ook de gegevensuitwisseling tussen de SUWI-partijen (via SUWI-ML) worden ondersteund. Sinds versie 3 is het mogelijk binnen GWS4all te werken met een elektronisch dossier, hiermee is het mogelijk om alle documenten digitaal op te slaan en te ontsluiten op alle werkplekken. Horlings & Eerbeek/EBB-Trajecten Horlings & Eerbeek Automatisering B.V. is een jonge, innovatieve organisatie die zich gespecialiseerd heeft in de ontwikkeling van gebruiksvriendelijke, eenvoudig en snel te implementeren applicaties voor de kleine en middelgrote gemeenten. Veel applicaties worden ontwikkeld in samenwerking met gemeenten of publieke instellingen. EBB-Trajecten is ontwikkeld in samenwerking met de gemeente Horst aan de Maas. Het is een "to the point" applicatie waarbij het gegevensmodel van de applicatie vrijwel volledig is gebaseerd op het SUWI-gegevensregister. De applicatie is een client-server toepassing, primair gericht op het volgen van cliënten binnen de WIZ-diensten. EBB-Trajecten komt
20
vanaf 1 september 2002 officieel op de markt. De uitvoering van de WIN is in ontwikkeling als aparte module, maar zal niet beschikbaar zijn in september. PinkRoccade Civility/Traject-Assistent PinkRoccade Civility maakt onderdeel uit van de PinkRoccade holding (9439 fte) en is een grote leverancier van verschillende softwareoplossingen voor onder meer lokale overheden. CiVision Welzijn is de nieuwe strategische productlijn van PinkRoccade Civility voor WIZ-diensten. Traject-Assistent en CiVision Welzijn maken onderdeel uit van de functionele architectuur van PinkRoccade Civility. Bewust is niet gekozen voor een geïntegreerde monolithische applicatie, maar voor een aparte applicatie ter ondersteuning van het casemanagement. CiVision Welzijn en Traject-Assitent wisselen gegevens uit, zodat deze maar eenmalig behoeven te worden vastgelegd. PinkRoccade Civility heeft ca. 750 mensen in dienst waarvan ongeveer 20 fte betrokken is bij het pakket Traject-Assistent. Hoewel Traject-Assistent reeds in 2001 verscheen (en wordt gebruikt bij BGZ-wegvervoer), is de aanpassing van het product voor WIZ-diensten onlangs afgerond. Traject-Assistent is een webtoepassing waarbij gebruik wordt gemaakt intelligente werkstroombesturing en gegevenssets. Bij de ontwikkeling is uitgegaan van een procesoriëntatie in plaats van gegevensoriëntatie. De applicatie werkt op basis van een elektronisch cliëntendossier dat in overleg met de opdrachtgever geparameteriseerd kan worden samengesteld. Het gegevensdossier is, door het view-mechanisme, toegankelijk of niet toegankelijk, afhankelijk van de rol die partijen in de procesketen vervullen. Door het toepassen van Webtechnologie wordt een integraal reïntegratiedossier door de keten-partners opgebouwd. Hierdoor wordt voorkomen dat gegevensadministraties moeten worden uitgewisseld c.q. opnieuw moet worden geadministreerd met alle kans op fouten en efficiëntienadelen. Bovendien wordt langs deze weg op een transparate wijze een integraal reïntegratiedossier opgebouwd dat door stakeholders benaderbaar is. De filosofie is dat er geen sprake is van een geïntegreerd omvangrijk monolithisch systeem, maar een op basis van XML koppelbare applicatie. Dit past volledig in de filosofie van ketenintegratie op basis van gekoppelde systemen. De koppeling van Traject-Assistent naar bijvoorbeeld CiVision Welzijn ten behoeve van de uitkeringenadministratie is voorzien. Stratech/Masterlink De dienstverlening van Stratech reikt van verkoop en implementatie van standaardsoftware tot en met training en nazorg. De productgroep Sociale Zekerheid van Stratech richt zich name op de gemeentelijke- en reïntegratiemarkt. Stratech heeft een personeelsbestand van ca. 48 fte, waarvan 14 fte direct betrokken is bij Masterlink. Masterlink is een van de strategische producten voor Stratech. Op dit moment is het pakket bij 51 WIZ-diensten geïmplementeerd. Daarnaast wordt het pakket veelvuldig gebruikt door reïntegratiebedrijven. Het MASTERLINK concept werd reeds in 1995 als DOS applicatie gelanceerd. De huidige Windows versie bestaat sinds 1998. Voor de technische opbouw is gekozen MASTERLINK conform de "three tier architecture" te ontwikkelen. Hierdoor is MASTERLINK goed schaalbaar en database onafhankelijk. Het pakket is primair gericht op doelmatigheid en reïntegratie taken. Masterlink biedt ondersteuning bij de uitvoering van casemanagement en de MoSA. Daarnaast ondersteunt het een diversiteit aan inhoudelijke regelingen (regie Abw-cliënten, WIW, I/D-banen, REA en WIN). De rol van gemeenten op het gebied van arbeidstoeleiding zal de komende jaren veranderen. De klant zal steeds meer vraaggerichte zorg- en dienstverlening afdwingen en door de wet SUWI is de marktwerking van reïntegratiebedrijven bevorderd. Casemanagement
21
moet de dienstverlening aan de cliënt vergemakkelijken. Het juiste cliëntvolgsysteem is hierbij onmisbaar. Een belangrijke toepassing hierin zal zijn de gegevensuitwisseling met externe partners. Gegevensuitwisseling via bijvoorbeeld internet vraagt om platformonafhankelijke applicaties. Stratech heeft ervoor gekozen deze uitwisseling door middel van XML (SuwiML) en internet portaal technieken (elektronische formulieren) te laten plaatsvinden. Transfer Solutions/MVS Transfer Solutions is een softwarebedrijf dat gespecialiseerd is in Oracle-systemen. Het bedrijf richt zich op de Nederlandse ICT-markt en levert Oracle-technologie aan verschillende organisaties. Transfer Solutions heeft 90 fte aan personeel waarvan 10 tot 15 fte betrokken is bij MVS. Het pakket MVS is in 2001 in opdracht van de gemeente Amsterdam (Sociale Dienst Amsterdam en Maatwerk) ontwikkeld door Transfer Solutions. MVS (in een aangepaste vorm) wordt gebruikt op de Megabanenmarkt van de Sociale Dienst Amsterdam en door de Stichting Maatwerk, die het casemanagement voor de regio Oost van de Sociale Dienst uitvoert. De gemeente Amsterdam is eigenaar van het pakket, Transfer Solutions treedt daarbij op als leverancier. MVS is een op Oracle technologie gebaseerde client-servertoepassing voor het Windows-platform. Het pakket is operationeel in een Citrix-omgeving. MVS is primair bedoeld voor reïntegratiedoeleinden en gebouwd voor de Amsterdamse situatie (qua proces en terminologie). MVS is geschikt om snel in te kunnen haken op wijzigingen daarin door zijn opzet met programmageneratoren. In opdracht van de huidige klanten (Maatwerk en de Sociale Dienst Amsterdam) worden gedurende 2002 nieuwe functionaliteiten gebouwd, waaronder koppelmogelijkheden gebaseerd op XML. Hiernaast bestaat de mogelijkheid het MVS bij voldoende interesse ook als internettoepassing aan te bieden, volgens het ASP (Application Service Provider) concept. Type leverancier: pakketaanbieder of dienstverlener Sommige van de hierboven genoemde leveranciers leveren diensten, andere leveren een pakket. Hieronder worden eerst kort de termen pakketaanbieder en dienstverlener omschreven, waarna de leveranciers getypeerd worden. Een pakketaanbieder levert een pakket. Dit houdt in dat een pakketaanbieder vooraf op basis van onderzoek bepaalt wat de markt wil en vooraf investeert in (en een ondernemers-risico neemt bij) de ontwikkeling van het pakket. Vervolgens wordt het pakket in de markt gezet volgens een bepaalde prijsstelling. Op het moment dat het pakket voor een WIZ-dienst verkrijgbaar is, is het pakket gereed en bruikbaar voor de doelgroep. Elk jaar komen er een aantal nieuwe versies van het pakket uit. De inhoud van deze versies wordt, met of zonder de inbreng van de gebruikers, bepaald door de pakketaanbieder. Deze pakket-aanbieder heeft de regie en is eigenaar van het aangeboden pakket. Daarnaast worden rondom dit pakket diverse diensten aangeboden, zoals ondersteuning bij implementaties en een helpdesk. Een dienstverlener levert diensten, geen pakket. Dit houdt in dat een dienstverlener werkt in opdracht van een klant en diens wensen implementeert in de vorm van een op maat gemaakt pakket. Dit in tegenstelling tot een pakketleverancier die eerst een pakket ontwikkelt en vervolgens aan klanten aanbiedt. De eerste klant is eigenaar van het geïmplementeerde pakket en betaalt derhalve de ontwikkelkosten, eventueel volgens een verdeelsleutel met de dienstverlener. Het pakket wordt op maat gemaakt voor de klant. De dienstverlener biedt kennis en capaciteit op het gebied van softwareontwikkeling en eventueel additionele diensten, zoals beheer, opleidingen en ondersteuning op de werkplek.
22
Bij een volgende klant treedt de dienstverlener op als bemiddelaar. Er wordt overeengekomen dat de volgende klant het pakket tegen betaling mag gebruiken. De eigenaar van het pakket (vorige klanten en/of dienstverlener) ontvangt royalty's. Indien deze volgende klant extra functionaliteit wenst, wordt deze op zijn verzoek in het pakket gebouwd. De bouw van de extra functionaliteit (door de dienstverlener) wordt betaald door deze volgende klant. Deze klant kan vervolgens eigenaar worden van de uitbreidingen. Ook kan in overleg het eigenaarschap van de uitbreiding bij andere (eerdere) klanten belegd worden. De inhoud van een op deze manier ontwikkeld pakket wordt geleid door de op dat moment betalende klant(en), de regie op de functionaliteit wordt geregeld door de dienstverlener in overleg met de (mogelijk meerdere) eigenaar klanten. Van de in dit hoofdstuk omschreven leveranciers zijn Baas & Roost Advies, Centric, Horlings en Eerbeek, Pink Roccade Civility en Stratech pakketleveranciers. Transfer Solutions treedt op als dienstverlener. Gehanteerde werkwijze: zoek de verschillen Zoals eerder aangegeven zijn er verschillende cliëntvolgsystemen die ondersteuning bieden bij het uitvoeren van een breed spectrum aan reïntegratietaken. De pakketten van de betrokken leveranciers worden gebruikt bij organisaties die te vinden zijn in zowel het publieke als private domein. Afgezien van WIZ-diensten zijn Stichtingen voor de uitvoering van de WIW, reïntegratiebedrijven en WSW-bedrijven eveneens afnemer. De bedrijfsprocessen van deze organisaties hebben veelal betrekking op deeltaken bij de reïntegratie van dezelfde cliëntpopulatie. Ze nemen een andere plek in binnen de gehele keten van reïntegratie. Het zou daarom een misvatting zijn om te denken dat de verschillende typen organisaties dezelfde eisen stellen aan een cliëntvolgsysteem. De eisen die een WIZ-dienst stelt aan een cliëntvolgsysteem (onafhankelijk van het gekozen casemanagementmodel) zijn wezenlijk anders dan de eisen van een reïntegratiebedrijf. Dit laat onverlet dat er overlap is en een pakket beide type klanten kan ondersteunen. Tegen deze achtergrond is het interessant te bezien op welke gebieden de leveranciers en hun pakketten zich van elkaar onderscheiden. Immers, als een WIZ-dienst weet wat de sterke en zwakke punten zijn van een pakket in relatie tot de overige pakketten, dan is zij beter in staat het pakket te kiezen, waarvan de sterke punten het beste overeenkomen met de eisen en wensen van de eigen dienst. Tenslotte, elke WIZ-dienst zal, gegeven de eigen invulling van de Sluitende Aanpak en de eigen lokale situatie, zelf moeten bepalen welke eisen en wensen er bestaan ten aanzien van een CVS. De verschillen geven dus de meest interessante informatie voor een selectie- en keuzetraject. Toetsingskader als basis voor vergelijking Ten behoeve van de analyse en beoordeling van de verschillende CVS'en op toepasbaarheid bij WIZ-diensten is een zogenoemd 'toetsingskader' opgesteld. Dit toetsingskader biedt hulp bij de beantwoording van de volgende vragen: (a) welke functionaliteiten (waaronder processen en gegevens) dienen in een CVS te worden opgenomen, wil er sprake zijn van een adequate ondersteuning van het gehele proces van de Sluitende Aanpak? (b) aan welke voorwaarden dient een dergelijk CVS te voldoen volgens de wettelijke kaders (vooral met betrekking tot de vast te leggen gegevens)? (c) welke andere eisen (op het gebied van techniek, gebruikers, leverancier) kunnen aan een dergelijk CVS worden gesteld? (d) hoe verhouden deze wensen en eisen (de onderdelen (a) t/m (c)) zich tot het huidige aanbod van CVS'en, ofwel welke applicaties voldoen aan welke eisen? Het toetsingskader bestaat uit een Programma van Eisen (zie bijlage A) dat de nadere detaillering van deze vragen geeft.
23
Dit toetsingskader is ingevuld door de leveranciers en de gebruikers van de pakketten. Vervolgens is een 'demo- en interviewdag' voor elk pakket georganiseerd, waarin enerzijds de werking van het pakket is beoordeeld (visuele beoordeling) en anderzijds door middel van interviews met de direct betrokkenen (eindgebruikers, applicatiebeheerder, technisch beheerder, I&A-manager, eindverantwoordelijke manager en de leverancier) het ingevulde toetsingskader nader is besproken op juistheid en compleetheid. Het toetsingskader is daarmee de basis voor een effectieve vergelijking van de verschillende pakketten. Voor de volledigheid zijn in onderstaande tabel de WIZ-diensten opgenomen die als gebruiker of pilot-gebruiker aan deze audit hebben meegedaan; tevens is de status van de pakketten aangegeven. Pakket Imwin voor Windows GWS4all (module Reïntegratie) EBB-Trajecten Traject-Assistent Masterlink MVS
WIZ-dienst Dienst SZ Nijmegen Sector SZ Leeuwarden Afdeling SZ Horst aan de Maas Dienst AMSZ Den Bosch Sector SZ Zaanstad GSD Amsterdam
Status Operationeel Pilot Pilot Pilot Operationeel Operationeel
Tenslotte zij nogmaals benadrukt dat er geen uitputtende analyse van de betrokken pakketten heeft plaatsgevonden, maar een globale marktverkenning, waarbij is gezocht naar de belangrijkste verschillen tussen de aangeboden pakketten. De WIZ-diensten zullen, op basis van de eigen inrichting van de Sluitende Aanpak en andere (lokale) omstandigheden, hun eigen eisen en wensen rond een CVS moeten formuleren (in een Programma van Eisen) en op basis daarvan de selectie moeten uitvoeren.
24
3 Analyse van de aangeboden pakketten De in het vorige hoofdstuk omschreven systemen worden in dit hoofdstuk met elkaar vergeleken. Hier worden de onderscheidende kenmerken van de pakketten op een rijtje gezet. Van elk onderscheidend kenmerk wordt eerst kort uitgelegd wat ermee bedoeld wordt, waarna het kenmerk voor de verschillende pakketten beschreven wordt. Er wordt geen uitspraak gedaan over de vraag of een pakket op een van de kenmerken 'beter of slechter' is. Het beter of slechter zijn van een bepaald kenmerk (en pakket) hangt voor een groot deel af van de waarde die de WIZ-dienst aan het betreffende kenmerk hecht. Alle gepresenteerde onderlinge vergelijkingen zijn van relatieve aard. Ondersteunde regelingen: alleen regie Abw of ook additionele arbeid De inhoudelijke ondersteuning die door de diverse pakketten wordt geboden, varieert van de regie op de Abw-cliënten (en de registratie van de relevante aspecten) tot een volledige geautomatiseerde ondersteuning van de regelingen rond additionele arbeid (inclusief declaraties en verantwoordingen), zoals de WIW, I/D-banen en REA. Daarnaast kan ook de uitvoering van de Nieuwkomers (WIN) worden ondersteund. In afbeelding 9 zijn de gegevens opgenomen.
Regie Abw-klanten Registratie NUG'ers (Niet UitkeringsGerechtigden ) Registratie ANW'ers (Algemene Nabestaanden Wet) Uitvoering WIW (registratie, declaratie, verantwoording) Uitvoering REA (registratie, declaratie, verantwoording) Uitvoering I/D-banen (registratie, declaratie, verantwoording) Uitvoering WIN (Wet Inburgering Nieuwkomers)
a aa a a a a aa a a a aa a a aa aa aa aa
Afbeelding 9: door de pakketten geboden inhoudelijke ondersteuning
Elke WIZ-dienst kan ten aanzien van deze inhoudelijkheid zelf bepalen welke ondersteuning gewenst is, afhankelijk van wie de uitvoering van deze regelingen voor zijn rekening neemt. In vele gemeenten is bijvoorbeeld de uitvoering van de additionele arbeid uitbesteed aan (gemeentelijke) stichtingen of regionale samenwerkingsverbanden. De uitvoering van de WIN gebeurt op zeer diverse manieren (WIZ-dienst, dienst Welzijn/Maatschappelijke Ontwikkeling, externe partij). Relatie met inkoop: geen of volledige ondersteuning van inkoop Alle pakketten bieden een geautomatiseerde ondersteuning van het aan casemanagement gerelateerde inkoopproces. Bij de ondersteuning van de inkoop kunnen vervolgens de volgende werkzaamheden onderscheiden worden: • bijhouden van de contractpartijen, de met deze partijen gesloten contracten, de inhoud van de contracten (soort en aantal instrumenten)
25
• bewaken van het verbruik van de contracten (aantallen verbruikt door welke cliënten en het aantal nog resterende in te zetten instrumenten per contract) • vastleggen van financieringsbron per contract • bijhouden van kwaliteitskenmerken en ervaringen per contract. De mate waarin de pakketten dit proces geautomatiseerd ondersteunen verschilt. Afbeelding 10 geeft de pakketten relatief ten opzichte van elkaar weer. Het minimum van de geschetste lijn is het bieden van geen enkele geautomatiseerde ondersteuning voor de ondersteuning van inkoop. Het maximum is een volledige geautomatiseerde ondersteuning.
Afbeelding 10: ondersteuning van het inkoopproces
Als toelichting op bovenstaande afbeelding het volgende: • Imwin voor Windows, Masterlink en MVS bieden een uitgebreide ondersteuning van het inkoopproces. • EBB-Trajecten biedt lijsten met organisaties, met daaraan gekoppeld de lijsten met in te zetten instrumenten en de bewaking van de uitnutting. • GWS4all biedt een basis voor de inkoopondersteuning, verdere structurele uitbreidingen van de module Reïntegratie zijn door Centric gepland voor de volgende versie. • Traject-Assistent biedt met de productselector de mogelijkheid instrumenten (producten) te selecteren en in te zetten bij een cliënt. Tevens wordt de inkoopondersteuning met betrekking tot leveranciers en de uitnutting van de verschillende budgetten geboden. Tijdens de demo was de productselector nog niet operationeel, maar bij de uiteindelijke oplevering zal de pijl in bovenstaande figuur waarschijnlijk net na EBB-Trajecten terecht komen. Flexibiliteit van de inrichting: vast ingesteld of volledig inrichtbaar De pakketten verschillen in de mate waarin ze instelbaar (parameteriseerbaar) of in te richten zijn. Het ene uiterste is een pakket waar één (vooraf bedachte) inrichting, de standaardinrichting, mogelijk is. Daar kan niets aan veranderd worden. Het andere uiterste is een volledig te veranderen pakket. In afbeelding 11 is een overzicht opgenomen van de verschillen tussen de pakketten op het gebied van de flexibiliteit van de inrichting.
26
Afbeelding 11: flexibiliteit van de inrichting
Als toelichting op bovenstaande afbeelding het volgende: • Het pakket Traject-Assistent biedt de meeste vrijheidsgraden wat betreft de inrichting. Zowel de procesgang, alsook de geregistreerde gegevens kunnen geparameteriseerd worden. • De pakketten Imwin voor Windows, Masterlink en GWS4all liggen qua inrichtingsvrijheden dicht bij elkaar. Bij Masterlink ligt de nadruk meer op de opbouw van het trajectplan en de gerelateerde stappen. Imwin biedt diverse vrij in te vullen tabbladen en bij GWS4all ligt de nadruk meer op de werkstroom-besturing. • In MVS zijn gegevens, die onder meer betrekking hebben op fasering en trajectplannen, opgenomen in stamtabellen en kunnen door de functioneel beheerder worden gewijzigd. Daarbij moet worden opgemerkt dat bij de aanschaf van MVS de specificaties, het ontwerp en de programmatuurcode bijgeleverd worden en de WIZ-dienst daarmee het pakket verder kan uitbouwen. • EBB-Trajecten biedt de minste vrijheidsgraden qua aanpassingen. Dit is ook de filosofie achter het pakket. Procesondersteuning: afwezig of compleet De pakketten onderscheiden zich ook in de mate waarin het werkproces ondersteund wordt. Mogelijke manieren van ondersteuning zijn: • Signalen per cliënt. Voorbeelden van signalen zijn: op te nemen contacten met de cliënt, afronding van een opleiding, etc. • Signalen op het scherm, geordend per cliënt. • Werkvoorraad per medewerker, met alle in behandeling zijnde werkzaamheden. In de werkvoorraad komen tevens de signalen. • (Dwingend) leiden van de medewerker door de volgorde van procesactiviteiten. In afbeelding 12 worden de pakketten op bovenstaande kenmerken met elkaar vergeleken. Als toelichting op afbeelding het volgende: • GWS4all biedt de meest uitgebreide procesondersteuning. Zowel de signalering van afspraken die 'verlopen' als een werkstroombesturing zijn in het pakket aanwezig. • Traject-Assistent biedt een uitgebreide werkstroombesturing en geeft een signaal als in het proces ingestelde doorlooptijden, ook in relatie tot afspraken, verstrijken. Dit pakket biedt buiten de in het proces gedefinieerde signalen geen mogelijkheid extra signalen te genereren (bijvoorbeeld een seintje als herinnering dat de cliënt volgende week gebeld moet worden).
27
Afbeelding 12: werkprocesondersteuning
• Masterlink, Imwin voor Windows, MVS en EBB-Trajecten bieden de generatie van verschillende soorten signalen. • Masterlink, MVS en Imwin voor Windows bieden de mogelijkheid de mogelijke signalen vrij te definiëren. • Bij EBB-Trajecten was het afhandelen van signalen tijdens de demonstratie nog niet in productie. Flexibiliteit van gegevensmodellering: geen of alle gegevens te veranderen De wijze waarop de gegevensopslag is georganiseerd bepaalt in belangrijke mate de flexibiliteit van een toepassing. Twee invalshoeken zijn in dit verband van belang bij het onderwerp flexibiliteit van gegevensmodellering: (a) Het conformeren aan standaards voor gegevensregistratie en uitwisseling. Twee standaards zijn van speciale betekenis voor het volgen van cliënten: het onlangs vrijgekomen SUWI-gegevensregister en de specificatie van de MoSA. De pakketten onderscheiden zich in de wijze waarop zij zich conformeren aan deze standaards. (b) De mate waarin een pakket voorziet in mogelijkheden om extra cliëntspecifieke gegevens te registreren. Pakketten kunnen dit onmogelijk maken, beperkt mogelijk maken middels bijvoorbeeld tabbladen met vrije gebruikersvelden, of bijna alles toestaan. De genoemde kenmerken sluiten elkaar niet uit. Het is mogelijk dat een pakket een standaard strikt hanteert en tevens mogelijkheden biedt om aanvullende gegevens te registreren. Het nut van standaardisatie komt vooral tot uiting op het moment dat gegevens moeten worden uitgewisseld met derden. Het SUWI-gegevensregister is een recent voorbeeld van zo'n standaard. Het zal de toekomstige elektronische uitwisseling van gegevens met het CWI mogelijk moeten maken. Deze standaard is nog redelijk jong (versie 1.0); de nu gekozen inhoud zal zich in de praktijk nog moeten bewijzen. In afbeelding 13 worden de verschillende pakketten op bovenstaande kenmerken met elkaar vergeleken.
28
Standaard aanwezige SUWI gegevens (procenten)100737475440 Af te dekken SUWI gegevens met extra velden (proc)0026250100 Totaal door pakket afgedekte SUWI gegevens (proc)1007310010044100 Genereren van de MoSA Mogelijkheden voor 'vrije velden/tabbladen
a aa aaa aa a a
Afbeelding 13: flexibiliteit gegevensmodellering
In het kader van de marktverkenning zijn voor de vergelijking van de pakketten alleen die gegevens (uit het SUWI-gegevensregister) meegenomen welke direct relevant zijn voor activering en gebruikt worden bij de zogenoemde "intake Abw". Naast de stamgegevens gaat het dan om arbeidsgegevens, arbeidstoeleidingsgegevens, arbeidsmarktkwalificatiegegevens en SUWI-gegevens. Uitkeringengegevens worden buiten beschouwing gelaten, daar de registratie daarvan primair de verantwoordelijkheid is van een uitkeringensysteem. Een uitzondering is gemaakt voor de velden die betrekking hebben op de wet REA. De resulterende gegevenslijst is door de leveranciers ingevuld. De eerste drie regels van bovenstaande tabel geven aan in welke mate de pakketten het hiervoor genoemde deel van de SUWI-gegevensverzameling in zich hebben. Hierbij wordt voor elke gegeven uit de SUWI-gegevensverzameling onderscheid gemaakt tussen de volgende drie mogelijkheden: • Een gegeven is standaard in het pakket aanwezig. • Een gegeven kan tijdens de installatie en inrichting toegevoegd worden door bijvoorbeeld vrije velden en tabbladen. • Een gegeven is niet aanwezig. De eerste regel in de tabel geeft het percentage gegevens dat standaard in het pakket aanwezig is zonder extra inrichting en de tweede regel van de tabel geeft het percentage gegevens weer dat in het pakket aanwezig kan zijn na gebruikmaking van de vrije velden en tabbladen. Per pakket is de dekking: • Traject-Assisent is op gegevensniveau volledig in te stellen. Dit houdt in dat standaard geen gegevens in het systeem aanwezig zijn, maar alles er in gezet kan worden. De leverancier is overigens wel van plan een standaard inrichting met gegevens beschikbaar te stellen. Deze was echter tijdens de marktverkenning nog niet voorhanden. • EBB-Trajecten heeft als uitgangspunt voor de ontwikkeling het SUWI-gegevens-register gebruikt. Vandaar de standaard score van 100%. • GWS4all biedt een 73% dekking van de SUWI-gegevensverzameling. In GWS4all is het mogelijk om in een werkproces vrije velden te definiëren. Het is tevens mogelijk om die velden in het werkproces verplicht te stellen. • Imwin voor Windows en Masterlink bieden naast de standaard aanwezige gegevens de mogelijkheid vrije velden of tabbladen toe te voegen, waarmee de percentages van respectievelijk 74% en 75% aangevuld kunnen worden naar 100%, zonder dat de programmatuur aangepast behoeft te worden. • MVS dekt 44% van de gehanteerde gegevensverzameling af.
29
De levering van de MoSA kan met alle pakketten. Met betrekking tot het accommoderen van mogelijkheden voor de opslag van gegevens die specifiek zijn voor een WIZ-dienst (denk aan cliëntkenmerken als belemmeringen) bieden Traject-Assistent, GWS4all, Imwin voor Windows en Masterlink mogelijkheden om extra gegevens op te nemen voor registratie van aanvullende cliëntgegevens. Voor zowel MVS als EBB-Trajecten vergt opname van gemeentespecifieke informatie aanpassingen aan de programmatuur. Koppelingen met uitkeringssystemen: geen of volledige integratie De relatie met een uitkeringensysteem is voor een cliëntvolgsysteem belangrijk. In het uitkeringssysteem is een groot deel van de cliëntpopulatie van de WIZ-dienst aanwezig met bijbehorende stamgegevens. Om meervoudige registratie van gegevens (dubbel werk) te voorkomen en de cliëntgegevens consistent te houden, is een koppeling met het uitkeringssysteem noodzakelijk. Bij slechts een klein aantal cliënten is de noodzaak tot koppeling er minder. Onder koppeling wordt hier verstaan een eenzijdige koppeling, waarbij de basis cliëntgegevens (minimaal naam, adres en woonplaats) vanuit het uitkeringensysteem in het cliëntvolgsysteem geplaatst worden en daar gebruikt worden, maar niet gemuteerd kunnen worden. De volgende vormen van koppeling kunnen onderscheiden worden: • Geen: het pakket heeft geen koppeling met de op de markt verkrijgbare uitkeringensystemen. De koppeling is onderdeel van het zelf te bekostigen maatwerk. • Koppelingen worden gemaakt, zijn nog niet in productie, maar wel onderdeel van het pakket. • Koppelingen bestaan en worden sinds enige tijd gebruikt. • Het pakket is geïntegreerd: een koppeling met het uitkeringensysteem is niet nodig, het cliëntvolgsysteem is immers onderdeel van het systeem. In afbeelding 14 worden de pakketten op het gebied van koppelingen met elkaar vergeleken.
Afbeelding 14: koppeling met het uitkeringensysteem
Als toelichting op bovenstaande afbeelding het volgende: • MVS biedt geen koppelingen met de op de markt aanwezige uitkeringensystemen. Bij de aanschaf is het maken van deze koppelingen maatwerk en voor rekening van de kopende WIZ-dienst. Wel heeft MVS bewezen te kunnen koppelen met een uitkeringensysteem, namelijk met het NUS-systeem van de Sociale Dienst Amsterdam. • Bij Traject-Assistent en EBB-Trajecten zijn de koppelingen in de maak en zijn deze bij de verkoop van het pakket, in september 2002, gereed. • Masterlink en Imwin voor Windows bieden al geruime tijd koppelingen met de standaard uitkeringensystemen.
30
• GWS4all is een volledig geïntegreerd pakket, waarbij de module Reïntegratie niet buiten het uitkeringensysteem (de basis) geplaatst kan worden. Deze integratie is de leidende filosofie van het pakket. Rapportages: standaard in of volledig buiten het pakket Op het gebied van rapportagefaciliteiten verschillen de pakketten. De leverancier kan ervoor kiezen om standaardrapportages (voorgedefinieerde lijsten) mee te leveren en/of een rapportgenerator te integreren in het pakket. Een andere mogelijkheid is om ervoor te kiezen dit juist niet te doen en ervan uit te gaan dat een WIZ-dienst met een eigen rapportagetool (bijvoorbeeld Cognos Impromptu of Business Objects) de database benadert en zelf rapporten (laat) ontwikkelen. Het eerste uitgangspunt is niet noodzakelijk beter dan het tweede. Een leverancier die geen of weinig energie stopt in de ontwikkeling van standaardrapportages en een rapportgenerator is doorgaans geneigd meer middelen voor het ontwikkelen van nieuwe functionaliteiten beschikbaar te stellen. Echter, een WIZ-dienst zal dan over expertise moeten beschikken om zelf rapporten te (laten) bouwen en te onderhouden. Overigens moet men zich wel realiseren dat altijd bij standaardrapporten moet worden bekeken of deze passen binnen de gedefinieerde informatiebehoeften van de WIZ-dienst en dat rapporten maken met een geïntegreerde rapportagetool weliswaar vaak eenvoudiger is dan met een externe tool, maar dat dit ook extra inspanning vergt. In afbeelding 15 worden de verschillende pakketten op bovenstaande kenmerken met elkaar vergeleken.
a
a aaa a a a aa aa a
Standaardrapporten Geïntegreerde rapportgenerator Koppelbaar met externe rapportage tool Afbeelding 15: rapportages
In deze afbeelding is te zien dat alle pakketten mogelijkheden bieden om te koppelen met een rapportagetool. Daarnaast beschikken Masterlink en Traject-Assistent over een geïntegreerde rapportgenerator. Traject-Assistent kent echter een zeer eenvoudige rapportgenerator, die met name dient voor de oplevering van extracten die verder bewerkt moeten worden in Excel of met een andere tool. Opgemerkt moet worden dat de geleverde standaardrapportages niet op inhoud vergeleken zijn. Gebruikersgroepen: individuele benadering of gebruikersgroep Een volgend onderscheidend kenmerk is de aanwezigheid van een gebruikersgroep voor het pakket. In een gebruikersgroep zijn de gebruikers verenigd en voeren collectief overleg met de leverancier. Bij de afwezigheid van een gebruikersgroep voeren de gebruikers van het pakket individueel overleg met de leverancier. Afbeelding 16 toont de pakketten in relatie tot de aanwezigheid van een gebruikersgroep.
31
Afbeelding 16: gebruikersgroepen
Als toelichting op bovenstaande afbeelding het volgende: • GWS4all, Imwin voor Windows en Traject-Assistent bieden een gebruikersgroep. Traject-Assistent is ondergebracht binnen de gebruikersgroep CiVision Welzijn van PinkRoccade Civility. • Masterlink heeft individuele klantbenadering in combinatie met klankbordsessies. • EBB-Trajecten en MVS zijn nieuw in de markt en hebben één (pilot-) klant en daarmee vooralsnog een individuele klantbenadering; een gebruikersgroep bestaat nog niet. EBBTrajecten heeft aangegeven bij het beschikbaar komen van het product in september 2002 ook een gebruikersgroep voor het product op te richten. Fase ontwikkeling van product: ideestadium of reeds jaren in productie De levensloop van een softwarepakket kent verschillende in elkaar overlopende stadia: • ideevorming • ontwerp en ontwikkeling eerste versie • eerste versie van het pakket in productie • aantal jaren in productie en een aantal opeenvolgende versies. Bij de eerste versie van een pakket zijn over het algemeen de kinderziektes nog niet allemaal overwonnen. Een pakket dat reeds jaren in productie is, heeft zich reeds bewezen. De fase van ontwikkeling zegt dus iets over de stabiliteit van het pakket. Aan de andere kant moet worden opgemerkt dat een nieuw pakket (in eerste versie) natuurlijk niet op voorhand slecht is. Bovendien zijn in een nieuw pakket mogelijk de nieuwste inzichten verwerkt, waar een reeds bestaand pakket meer moeite mee heeft om deze te incorporeren. Afbeelding 17 geeft een overzicht van de verschillende fasen waarin de pakketten verkeren.
Afbeelding 17: ontwikkelingsfase pakketten
32
Als toelichting op bovenstaande afbeelding het volgende: • MVS wordt ongeveer een jaar gebruikt in Amsterdam. Het is specifiek voor de Sociale Dienst Amsterdam ontwikkeld, qua proces en terminologie. Er zal daarom nog het nodige gedaan moeten worden om het geschikt te maken voor een andere WIZ-dienst. Deze aanpassingen zijn voor rekening van de kopende gemeente. • Traject-Assistent is sinds vorig jaar operationeel bij Arbo-diensten en Brancheorganisaties, maar is op de gemeentemarkt een nieuw pakket. De toespitsing ten behoeve van het gebruik door WIZ-diensten is inmiddels afgerond. PinkRoccade Civility verwacht na de zomer, in september 2002, een verkoopbare versie te hebben. • EBB-Trajecten is op de markt een nieuw pakket, waarvan de ontwikkeling van de eerste versie in de afrondende fase verkeert. De leverancier verwacht na de zomer, in september 2002, een verkoopbare versie te hebben. • Het pakket GWS4all is niet nieuw, maar de module Reïntegratie van GWS4all is dat feitelijk wel (hoewel er een eerdere ITB-module bestond). Deze module is in april 2002 gereed gekomen en sinds 1 mei 2002 op de markt. • Masterlink en Imwin voor Windows zijn al langere tijd in productie. De leverancier van Imwin voor Windows, Baas & Roost Advies, levert na de zomer van 2002 de opvolger iw3 uit. Weliswaar is iw3 nog niet meegenomen in dit onderzoek, maar inmiddels is de eerste klantpilot van iw3 reeds gestart. Organisatie leverancier: kleinschalig of grootschalig Ook de organisatie van de leverancier is een onderscheidend kenmerk. Afbeelding 18 geeft een combinatieoverzicht van een aantal organisatorische kenmerken van de verschillende leveranciers in relatie tot het pakket. Het ene uiterste van de lijn is het inzetten van weinig resources en het andere uiterste is het inzetten van veel resources. Deze resources zijn opgebouwd uit enerzijds fte's die aan het product werken en anderzijds de investering per jaar.
Afbeelding 18: organisatie leverancier
Als toelichting op bovenstaande afbeelding het volgende: • Bij Baas & Roost Advies werken 80 fte die zich bezig houden met het CVS. De initiële investering in iw3 is meer dan 1.000.000. Naar verwachting zal er vervolgens jaarlijks minimaal 800.000 tot 1.000.000 worden geïnvesteerd. • Transfer Solutions investeert zelf niet in het product MVS (is een diensten-aanbieder), de afnemers van het product betalen de verdere ontwikkeling. De gemeente Amsterdam is de eerste klant en daarmee de eerste investeerder. • Horlings en Eerbeek heeft 2 fte die zich bezig houden met het product EBB-Trajecten. De jaarlijkse investeringen zijn nog niet bepaald. • Stratech heeft 14 fte die zich bezig houden met het CVS en voorzien een jaarlijkse investering in het product Masterlink tussen de 300.000 en 400.000.
33
• PinkRoccade Civility heeft 80 fte die zich bezighouden met CiVision Welzijn en daarnaast 20 fte die zich bezig houden met het product Traject-Assistent, met een jaarlijkse investering van 1.800.000. Traject-Assistent wordt niet alleen gebruikt bij WIZdiensten, maar wordt onder andere ook gebruikt door Arbo-diensten en Brancheorganisaties. • Centric heeft 90 fte die zich bezig houden met het GWS4all-product, waar de module Reïntegratie onderdeel van is. Hieronder vallen zowel de werkzaamheden in het kader van de ontwikkeling, als ook de invoering bij en ondersteuning van WIZ-diensten. Centric investeert circa 1,13 miljoen in de module Reïntegratie (ontwikkeling, support, etc) per versie van deze module. Prijs van het product: gratis of een groot kapitaal Alles heeft een prijs, ook cliëntvolgsystemen. De verschillende pakketten zijn onderscheidend wat betreft prijsstelling. Afbeelding 19 geeft een relatief overzicht van de prijzen, daarna worden de details van de prijzen8) besproken.
Afbeelding 19: de prijs van de pakketten
De prijs van de GWS4all is afhankelijk van het aantal inwoners dat een gemeente heeft. De module Reïntegratie van GWS4all kan niet los functioneren van de GWS4all-basis. De prijs van de basis is 1,82 per inwoner en de prijs van de module Reïntegratie is 0,12 per inwoner. Voor WIZ-diensten die reeds GWS4all in huis hebben, is GWS4allreïntegratie de goedkoopste oplossing. Om een indicatie van de prijs te geven, volgen hier een paar uitgerekende voorbeelden: • 25.000 inwoners: 3.000 (reïntegratie), 45.500 (basis) • 75.000 inwoners: 9.000 (reïntegratie), 136.500 (basis) • 150.000 inwoners: 18.000 (reïntegratie), ¤ 273.000 (basis). GWS4all basis bestaat uit contactregistratie, uitkeringen, periodieke controles, debiteuren, crediteuren, voorschotten, werkbeheersing, module documentvorming, management informatie en applicatiebeheer. Voor het pakket EBB-Trajecten is de prijs afhankelijk van het aantal inwoners. Het pakket maakt geen onderscheid in modules. De aangegeven prijs is daarmee de totaalprijs voor alle functionaliteit: • 0 tot 15.000 inwoners: 9.077 • 15.000 tot 30.000 inwoners: 11.799 • 30.000 tot 45.000 inwoners: 13.840 • 45.000 inwoners en hoger: in overleg, is in eerste aanleg niet de doelgroep • onderhoud: 15% van het aanschafbedrag per jaar.
8) Alle genoemde prijzen zijn exclusief BTW, prijspeil juni 2002.
34
Het pakket Masterlink van Stratech is volledig modulair opgebouwd. Modules kunnen dan ook los aangeschaft worden. De prijs van het pakket is afhankelijk van het aantal gelijktijdige gebruikers. Naar aanleiding van een vrijblijvende demo zal gezamenlijk met de klant de configuratie worden samengesteld. Voor de belangrijkste modules is de prijs bij het gebruik met één gebruiker tegelijk: • Basissysteem (voorwaardelijk voor de rest): 5.427 • Projecten: 916 • Instrumenten: 811 • Banen: 1.147 • Eventverwerking: 926 • Rapportgenerator: 1.132 • Uitgebreide toegangsbeveiliging: 1.077 • MoSA - Monitor Scholing en Activering: 1.100 • Kosten en budgetten: 1.452 • Inleenvergoedingen: 974 • Contractbeheer: 1.182 • WIW - Wet Inschakeling Werkzoekenden: 3.909 • WIN - Wet Inburgering Nieuwkomers: 2.709 • I/D-banen - In- en Doorstroombanen: 3.179 • Export Module: 1.132 • Data Connectivity Module: 2.056 • Koppeling PTT Postcodetabel: 996 • Integratie met Word: 748 • onderhoud: rond de 15% van de aanschafprijs per jaar. De door Transfer Solutions afgegeven prijs van het MVS is tussen de 0,50 en 1,00 per inwoner. De kosten van het onderhoud zijn 22% van de aanschafprijs per jaar. Omdat MVS specifiek Amsterdams is, zal er na aanschaf doorontwikkeld moeten worden. De hieraan verbonden kosten zijn voor rekening van de koper. Transfer Solutions biedt dit aan voor 800 per dag. Imwin voor Windows is modulair opgebouwd. Modules kunnen los aangeschaft worden. De prijs van Imwin voor Windows is afhankelijk van het aantal gelijktijdige gebruikers. De prijsstructuur van Imwin voor Windows is gebaseerd op een basisprijs per module voor één gelijktijdig gebruiker plus een extra bedrag per extra gelijktijdige gebruiker. Hieronder staan de modules die voor gemeenten van belang kunnen zijn. Voor de overige modules kan men contact opnemen met Baas & Roost Advies. Onderhoud van Imwin voor Windows is 20% van de licentieprijs per jaar. Voor de opvolger iw3 geldt een analoge opbouw. Prijzen worden jaarlijks geïndexeerd op basis van gewijzigde prijs- en loonindex cijfers.
35
Naam module Basismodule Imwin voor Windows, incl. • Uitgebreide toegangsbeveiliging en autorisatiemogelijkheden • Koppeling tekstverwerker • Trajectregistratie, inclusief instrumenten zoals kinderopvang • Koppeling query-tool • Relatiebeheer • Standaardoverzichten • Kosten en Budgetten Module Sluitende Aanpak, incl. • Contractbeheer • Scholing & Activering Monitor • Urenverantwoording Module I-/D- Banen, incl. • Bevoorschotting • NEI-statistiek • Declaraties Module WIN, incl. • Oudkomers Module WIW, incl. • Dienstbetrekkingen • Werkervaringsplaatsen • Inleenvergoedingen • Declaraties en Statistiek Module koppeling uitkeringsadministratie • SDMS/GWS4all • Globit VTS/NTS • WBS-Social • SZW+
Basisprijs 3980,-
Prijs per extra gebruiker 970,-
1215,-
245,-
1215,-
245,-
1215,-
245,-
2455,-
475,-
975,-
100,-
De invoering van de Traject-Assistent is van veel factoren afhankelijk, zoals het al dan niet gebruik maken van CiVision Welzijn, het inrichten van de applicatie op het werkproces van de gemeente, eventueel benodigde licenties voor middleware en dergelijke. PinkRoccade Civility verstrekt hier dan ook geen overzicht van de prijsstelling van de Traject-Assistent. Op verzoek kan voor een individuele gemeente een offerte op maat gemaakt worden. Flexibiliteit technische architectuur: wel of niet inpasbaar De inpasbaarheid van de pakketten in de technische infrastructuur van een WIZ-dienst is eveneens een onderscheidend kenmerk. Onder inpasbaarheid wordt het volgende verstaan: • schaalbaarheid ofwel de mate waarin een pakket geschikt is voor grootschalig gebruik; • de impact die de technische eisen van het pakket heeft op de technische infrastructuur van de WIZ-dienst. Het gemak waarmee een pakket kan worden ingevoerd verschilt per situatie. Het spreekt voor zich dat voor een grote WIZ-dienst schaalbaarheid een belangrijk aandachtspunt is. Voorts zijn de technische eisen belangrijk om in ogenschouw te nemen. Indien de automatiseringsafdeling van een WIZ-dienst (of concern) bijvoorbeeld beschikt over een serverpark met Unix-servers, ligt het voor de hand om geen pakket te kiezen dat alleen onder Windows NT draait.
36
Een belangrijke factor voor het beheer van het systeem is voorts de inspanning die nodig is om de client-applicatie te onderhouden. Traditionele windowsapplicaties zijn relatief beheerintensief, alle werkstations moeten bij installatie van software worden voorzien. Dit beheer wordt vergemakkelijkt door toepassing van het thinclient-concept. Dit kan worden bereikt door gebruik te maken van webapplicaties (browserapplicaties) of door te kiezen voor terminalapplicaties (Citrix, MS Terminal Server, etc.). Het is zinvol om ook de toekomstvisie van de I&A-afdeling van de WIZ-dienst (of het concern) ten aanzien van deze onderwerpen in de beoordeling te betrekken. Teneinde grip te krijgen op deze onderwerpen zijn enige technische kenmerken geïdentificeerd waarin de pakketten verschillen. In onderstaande afbeelding worden de belangrijkste kenmerken samengevat. Versie-informatie is omwille van leesbaarheid niet weergegeven in deze tabel (combinaties van sommige versies zijn niet mogelijk, bijvoorbeeld Oracle 8 is niet beschikbaar voor HP UX versie 10). Alle pakketten, met uitzondering van EBB-Trajecten, zijn beschikbaar voor de gangbare Windowsservers. MVS, Traject-Assistent en GWS4all worden ook uitgeleverd onder Unix. De pakketten MVS, Traject-Assistent en GWS4all bieden de beste faciliteiten voor toepassing op grote schaal door gebruik te maken van een Oracle-database. Er zijn echter nauwelijks ervaringen bekend met grootschalige toepassing van een cliëntvolgsysteem (waarbij de database niet is opgesplitst naar locatie). Dit hoeft echter voor kleinere en middelgrote WIZ-diensten niet tot problemen te leiden. Traject-Assistent is het enige pakket dat in een browser draait. De leveranciers van de overige pakketten, met uitzondering van EBB-Trajecten, geven aan dat het mogelijk is om het pakket aan te bieden als webapplicatie. De extra inspanning die dit vereist wisselt. Alle leveranciers geven aan dat hun pakket in principe beschikbaar gesteld kan worden als Citrix thin-client.
Server: operating systeem Server: Overig Server: RDBMS
Type cliënt Terminalserver mogelijkheden
Windows 98
9)
10)
MS SQLserver
Oracle
Foxpro
Windowscliënt Citrix
Windowscliënt Citrix, MS Terminal server
Windowscliënt 12) Citrix, MS Terminal server
Afbeelding 20: technische kenmerken pakketten
9) Diverse platforms: Win NT, Win2000, Unix-varianten, afhankelijk van support Oracle 10) Diverse windows platforms: Win NT, Win 2000, Win95, Win98 11) Diverse platforms: Win NT, Win2000, Unix-varianten, afhankelijk van support IBM (Websphere). 12) Het toekomstige IW3 maakt gebruik van een browserinterface.
37
10
9
11)
Websphere Interbase Oracle DB2, Oracle, (standaard) MS SQL Oracle MS-SQL Windows- WindowsWebcliënt cliënt applicatie Citrix Citrix Citrix
DEEL 2: DE GEMEENTEN AAN ZET In het eerste deel van dit boekje is het referentiekader geschetst, namelijk: (a) enerzijds de algemene ontwikkelingen en gevolgen rond SUWI en een eerste vertaling daarvan in generieke eisen, die aan een CVS kunnen worden gesteld; (b) anderzijds een marktverkenning van de CVS'en, gericht op de belangrijkste verschillen die tussen de pakketten bestaan. Daarmee heeft u de 'basisbagage' op zak en kan de volgende stap worden gezet: de concrete vertaling naar uw eigen organisatie! In dit tweede deel is voor deze vertaling naar de eigen organisatie een handreiking opgenomen, die schematisch is weergegeven in onderstaande afbeelding.
Afbeelding 21: handreiking keuze, selectie en implementatie CVS
De vertaling naar de eigen organisatie bestaat uit drie stappen, te weten: (a) het maken van de (beleids)keuzes voor de eigen organisatie rond de wijze waarop de Sluitende Aanpak en casemanagement zullen worden ingezet; (b) het opstellen van een gedetailleerd Programma van Eisen (PvE) voor een CVS (op basis van de eigen keuzes), het bepalen van de prioriteiten en de aanbesteding; (c) de daadwerkelijke implementatie van het pakket. Onderstaand volgt een samenvatting van het tweede deel. Alvorens zelfs maar nagedacht kan gaan worden over de aanschaf van een CVS en de eisen die daaraan moeten worden gesteld, dienen binnen de eigen WIZ-organisatie eerst een aantal fundamentele (beleids)keuzes te worden gemaakt over de wijze waarop SUWI en de Sluitende Aanpak binnen de eigen organisatie zal worden ingevoerd (hoofdstuk 4). Deze vraagstukken hebben vooral betrekking op de gevolgen van de invoering van casemanagement voor de bedrijfsprocessen en de functies, de wijze waarop de inkoopfunctie praktisch zal worden vormgegeven en de wijze waarop de inzet van ICT (lees een CVS) binnen de organisatie moet worden gepositioneerd. Zijn deze vragen beantwoord, dan kan de volgende stap worden gezet. De selectie van een CVS vereist een zorgvuldig te doorlopen proces (hoofdstuk 5). Allereerst dient een (gedetailleerd) Programma van Eisen (PvE) te worden opgesteld, waaraan een te selecteren CVS dient te kunnen voldoen. Dit PvE dient betrekking te hebben op alle relevante eisen, dus zowel de functionele eisen, de technische eisen, de gebruikerseisen en de leverancierseisen. Vervolgens dient te worden bepaald welke waarde aan de verschillende eisen moet worden toegekend (de wegingsmatrix). Daarbij kan een 39
onderscheid worden gemaakt tussen 'knock-out eisen' (op basis waarvan een CVS geheel kan afvallen), eisen en wensen. Op basis hiervan kan een keuze worden gemaakt, al dan niet door middel van een Europese aanbesteding. Het te sluiten contract met de leverancier rondt deze fase af. Ten slotte dient het CVS binnen de organisatie geïmplementeerd te worden (hoofdstuk 6). Dit zijn ingrijpende en complexe processen, waarin zowel organisatieaspecten (bijvoorbeeld de gewijzigde processen, nieuwe documenten, opleidingen e.d.) een rol spelen, als diverse technische aspecten (installatie van het pakket, het testen, het uitvoeren van een conversie en de acceptatie van het systeem). Daarvoor is een planmatige aanpak een absolute voorwaarde. Een goed voorbereide implementatie is het halve werk! In bijlage A is een voorbeeld opgenomen van een Programma van Eisen voor een CVS, dat als basis kan worden gebruikt binnen de eigen organisatie.
40
4 Nadenken is de eerste stap Alvorens kan worden gestart met de selectie en implementatie van een cliëntvolgsysteem (CVS) dient eerst te worden nagedacht over de consequenties van de Sluitende Aanpak voor de eigen organisatie. In dit hoofdstuk zullen een aantal te overwegen aspecten worden beschreven, namelijk de rol en positie van de casemanager, de gevolgen voor de processen, de concrete vormgeving van de strategie- en regiefunctie en de inbedding van het CVS binnen de ICT-structuur van de organisatie. De casemanager: keuze maken rond de rol en positie Eerder is de introductie van casemanagement benoemd als de motor van de sluitende aanpak. Daarbij zijn een aantal modellen van casemanagement beschreven; de uiteindelijke keuze zal voornamelijk afhangen van het te kiezen dienstverleningsconcept13). Nieuwe vaardigheden voor de casemanager noodzakelijk De functie van de casemanager zal, ongeacht het te kiezen model, vragen om andere en nieuwe vaardigheden. Het gaat hierbij om de volgende zaken: (a) Het beheren van een vaste caseload van cliënten (voor alle relevante aspecten) en het fungeren als één aanspreekpunt voor die cliënten, hetgeen vraagt om vaardigheden als klantbenadering, planning en 'marketing'. (b) Het beheren van de relaties met de andere (ondersteunende) functies binnen de eigen organisatie en instellingen buiten de eigen organisatie (zie ook hieronder). Deze relaties zijn intensief en complex en stellen eisen aan de communicatieve vaardigheden van de casemanager. (c) Het dragen van een eigen verantwoordelijkheid. Dit vraagt aan de ene kant om verantwoordelijkheid voor het eigen resultaat, maar heeft ook gevolgen voor de managers binnen de dienst. De managers zullen meer op afstand moeten gaan 'sturen' en zullen meer op resultaat gaan 'afrekenen'. Dit vraagt ook van managers om andere vaardigheden! De (nieuwe) gewenste vaardigheden van casemanagers worden in afbeelding 22 in beeld gebracht14).
Afbeelding 22: vaardigheden van de casemanager 13)Zie voor een uitgebreide beschrijving: "Maatwerk in klantmanagement, dienstverleningsconcept, profiel en ontwikkeling", StimulanSZ, juni 2002. 14) Casemanagement in de praktijk. Een beschrijving van casemanagement praktijken bij drie GSD-en, A. du Pree-van der Slik, Utrecht, juni 2000.
41
Deze nieuwe vaardigheden zijn absoluut noodzakelijk voor het uitvoeren van de regiefunctie en vragen om additionele opleidingen voor de (nieuwe) casemanager, aangezien deze (echt) anders zijn dan die van de huidige consulenten. De casemanager doet het niet alleen Regievoeren is niet alleen een vak apart, maar vraagt ook om een duidelijke positionering van de casemanager binnen de organisatie en een afbakening van zijn/haar rol naar de andere functies binnen de organisatie. In afbeelding 23 is een voorbeeld van een concrete invulling opgenomen.
Afbeelding 23: de positionering van de casemanager
De rol en positie van de casemanager dient te worden afgebakend ten aanzien van: (a) de andere functies binnen de eigen organisatie: (i) de afdeling beleid (inkoop van trajecten): welke rol speelt de casemanager hierin, mag de casemanager zelf trajecten inkopen (of wordt gewerkt met raamcontracten)? (ii) de medewerkers die de uitkeringen administratief afhandelen: wie doet wat, welke eisen worden gesteld aan de overdracht, wie voort de klantcontacten? (iii) de administratieve ondersteuning: wie doet wat, hoe verloopt de opbouw van de dossiers? (iv) specialismen (bijvoorbeeld terugvordering & verhaal, sociale recherche): wanneer vindt overdracht plaats, wie voert de klantcontacten? (b) buiten de eigen organisatie: (i) naar reïntegratiebedrijven: hoe vinden aanmeldingen plaats, hoe verloopt de terugkoppeling, wie verwerkt de signalen, wie voert overleg (en waarover)? (ii) naar zorginstellingen: hoe vinden aanmeldingen plaats, hoe verloopt de terugkoppeling, wie verwerkt de signalen, wie voert overleg (en waarover)? Het gaat dus niet alleen om een specifieke functie (bijvoorbeeld die van casemanager), maar om een totaalvisie op de implementatie van de sluitende aanpak en de gevolgen ervan voor de organisatie en voor de casemanager in het bijzonder.
42
Processen moeten worden (her)ingericht Zowel als gevolg van de invoering van het CWI en de sluitende aanpak als van de komst van het Inlichtingenbureau zullen de huidige processen binnen de WIZ-dienst gaan veranderen. Daarbij zullen keuzes moeten worden gemaakt rond de eerder onderscheiden primaire en secundaire processen van casemanagement, namelijk: (a) rond de primaire processen: (i) de start van het aanvraagproces verschuift naar het CWI wat betreft de werkintake en (een deel van) de uitkeringsintake: welke afspraken worden daarbij gemaakt (SNO), hoe vindt de aansluiting plaats op het referentiewerkproces van het CWI, wie gaat binnen de WIZ-dienst de claimbeoordeling uitvoeren, is een trajectplan voor de cliënt onderdeel van het aanvraagproces of start dit direct na de claimbeoordeling? (ii) de concrete invulling van het reïntegratieproces, dat wil zeggen hoe komt het trajectplan tot stand (zelf doen of uitbesteden), hoe wordt invulling gegeven aan het monitoren van de trajecten (wat is dat precies, hoe verlopen de contacten en terugmeldingen)? (iii) voor reeds bestaande cliënten: wanneer en door wie wordt de sluitende aanpak voor deze groep opgestart, wie speelt daarin een rol? (iv) voert de casemanager ook de regie op de uitkeringenverstrekking en wie doet wat in dat verband (bijvoorbeeld rond bijzondere bijstand gerelateerd aan de trajecten)? (b) rond de secundaire processen: (i) hoe wordt de inkoop georganiseerd binnen de WIZ-dienst? (hierop wordt nog teruggekomen) (ii) wie is verantwoordelijk voor het bewaken van alle declaraties en hoe worden de gegevens, die daarvoor noodzakelijk zijn, vastgelegd? (iii) welke managementinformatie is noodzakelijk, wat betreft de sturing en beheersing van de processen, de beleidsinformatie voor de eigen organisatie en de verantwoordingsinformatie voor het ministerie (MoSA, Agenda van de Toekomst)? Parallel aan deze keuzes loopt, zeker in 2002, de aansluiting van de WIZ-diensten op het Inlichtingenbureau, hetgeen eveneens consequenties met zich meebrengt voor de werkprocessen. Tegen die achtergrond is het gewenst deze ineens te verwerken. Tenslotte gaat het niet alleen om de beschrijving en implementatie van de nieuwe processen, maar dienen ook diverse gerelateerde activiteiten vorm te worden gegeven, zoals: (a) de aanpassing (en ontwikkeling) van relevante rapportages, formulieren en beschikkingen rond de nieuwe processen; (b) controle van de telefonische bereikbaarheid van de eigen organisatie (als de casemanager hét aanspreekpunt voor de cliënt is, moet deze wel bereikbaar zijn!); (c) beschikbaarheid van adequate informatie rond de ingekochte reïntegratie- en zorgtrajecten: een verwijsgids met doelgroep, soort traject/instrument, procedures voor doorverwijzing e.d. De inrichting van de strategie- en regiefunctie De inrichting van de strategie- en regiefunctie (kortweg de inkoop van trajecten) vraagt om een procesmatige benadering, waarin diverse stappen kunnen worden onderscheiden. In afbeelding 24 is een voorbeeldproces opgenomen.
43
Afbeelding 24: proces en taken rond de inkoop van trajecten
Op grond van ervaringen bij WIZ-diensten blijkt dat dit proces en de daarin onderscheiden taken verschillend worden uitgevoerd. Deze verschillen vinden hun oorsprong en ervaring in: (a) De omvang van de WIZ-dienst: (i) grote WIZ-diensten hebben de onderscheiden taken en functies (ook fysiek) gesplitst over diverse afdelingen; (ii) bij kleinere WIZ-diensten is er vaak sprake van vermenging. Voorbeeld: de beleidsmedewerker formuleert de vraag (op grond van de visie), maar koopt ook zelf in. (b) De eigen visie van de WIZ-dienst op de 'diepgang en de verschijningsvorm' van casemanagement: welke ruimte krijgt de casemanager om zelf in te kopen, of gebeurt dit centraal in de organisatie door middel van raamcontracten? Het belangrijkste is dat deze onderscheiden taken binnen het proces adequaat belegd worden, zodat deze allen aan bod komen. Bij de verdere uitwerking en invulling kan gebruik worden gemaakt van de handreikingen die op dit terrein al verschenen zijn.15) Inzet ICT adequaat voorbereiden Gezien de vele onderlinge relaties en afhankelijkheden dienen de te maken keuzes rond de inzet van ICT als gevolg van de Sluitende Aanpak adequaat te worden voorbereid. Samengevat zal de volgende inzet van ICT als gevolg van de sluitende aanpak noodzakelijk zijn: (a) De koppeling van het uitkeringensysteem (en/of het CVS) met de intakemodule van het CWI voor het overhalen van de werk- en uitkeringsgegevens. (b) De selectie en implementatie van een CVS, gericht op de ondersteuning van de primaire en secundaire processen van casemanagement. (c) De koppeling met het Inlichtingenbureau (gekoppeld aan het uitkeringensysteem en/of het fraudesysteem). (d) Inzet van ondersteunende ICT ten behoeve van de casemanager, gericht op planningsinstrumenten (afsprakenplanning, procesondersteuning, caseloadbeheer e.d.). Deze kunnen zowel onderdeel zijn van het uitkeringensysteem als van het CVS. 15) Stichting StimulanSZ: Een kader voor de inkoop van trajecten, Den Haag, september 2001. Stichting StimulanSZ: Model regie en prestaties, Den Haag, september 2001
44
Daarbij dienen, in onderlinge samenhang, keuzes te worden gemaakt rond de inzet van de diverse systemen en hun onderlinge afhankelijkheid en koppelbaarheid. Tenslotte moeten deze keuzes passen binnen de technische infrastructuur van de WIZ-dienst en de gemeente. Conclusie: belangrijkste (beleids)keuzes vooraf maken De in dit hoofdstuk beschreven onderwerpen (rol en positie van de casemanager, de gevolgen voor de processen, de inrichting van de strategie- en regiefunctie en de inzet van ICT) vragen om een aantal (beleidsmatige) keuzes van de WIZ-dienst. Deze keuzes dienen eerst te worden gemaakt, zodat op basis daarvan kan worden gestart met de selectie van een CVS. De gemaakte keuzes zijn dan de input voor het op te stellen Programma van Eisen, zodat een op de organisatie passende selectie van een CVS kan worden gemaakt.
45
5 Proces van selectie en aanschaf zorgvuldig doorlopen Nadat de basiskeuzes binnen de eigen organisatie zijn gemaakt en vervolgens de principekeuze voor de aanschaf van een nieuw pakket (CVS) gemaakt is, zal een pakket geselecteerd en aangeschaft moeten worden. In dit hoofdstuk wordt stilgestaan bij het opstellen van het Programma van Eisen en het selectieproces. In het volgende hoofdstuk komt de implementatie aan de orde. In bijlage A is een voorbeeld Programma van Eisen (PvE) opgenomen, dat als basis gebruikt kan worden voor het opstellen van een op maat gesneden PvE. Een detailleringslag is daarbij noodzakelijk. De unieke kenmerken van de gemeentespecifieke werkwijze en situatie moeten extra benadrukt worden. Een goed Programma van Eisen maakt de selectie makkelijker Het opstellen van een goed Programma van Eisen kost veel tijd. Deze tijd wordt echter terugverdiend bij de vergelijking van de alternatieve pakketten. Een kwalitatief slecht Programma van Eisen kan als resultaat hebben dat het de pakketten niet onderscheidend genoeg van elkaar maakt en dat de uiteindelijke keuze niet eenduidig met het Programma van Eisen te maken is. Het opstellen van het PvE is dan zonde van de inspanning geweest. Een aantal onderwerpen die om aandacht vragen bij het opstellen van een kwalitatief goed Programma van Eisen komen hieronder aan de orde: (a) het geven van achtergrondinformatie (b) relevante onderdelen van een Programma van Eisen (c) het maken van elementaire gesloten (ja/nee) vragen (d) de weging van de afzonderlijke onderdelen (e) het stellen van open vragen (f) het vergelijkbaar maken van de kosten. Achtergrondinformatie geeft ook de leverancier extra inzicht De opsteller van het Programma van Eisen heeft alles scherp op het netvlies: de huidige werkwijze, de kenmerken van de beoogde werkwijze, de doelstellingen voor een nieuw systeem en belangrijkste eigenschappen van een nieuw systeem. Deze informatie is ook belangrijk voor het Programma van Eisen. Het is aanvullend op de gestelde eisen en wensen en geeft meer omschrijvend weer wat het nieuwe systeem moet gaan doen. Het opnemen van aanvullende achtergrondinformatie heeft twee doelen. Ten eerste maakt het voor de leverancier inzichtelijk waar het om gaat en zal deze beter in staat zijn een op maat gesneden aanbod te doen. Ten tweede is er een intern doel: door het opnemen van de extra informatie in het Programma van Eisen, wordt dit document ook een intern communicatiemiddel, zodat bijvoorbeeld het management ook in hoofdlijnen bekend is met dat wat beoogd wordt met het nieuwe systeem. Onderdelen van een Programma van Eisen In een Programma van Eisen komen alle relevante eisen aan de orde, niet alleen ten aanzien van de functionaliteiten zelf van het gewenste systeem, maar ook de gebruikerseisen, de technische eisen en de leverancierseisen. Daarnaast kunnen generieke WIZ-eisen worden toegevoegd (bijvoorbeeld het voldoen aan de SUWI-gegevensset, MoSA e.d.) In hoofdstuk n1 is dit reeds inzichtelijk gemaakt. De opstelling van deze eisen, naar alle invalshoeken, zal zorgvuldig en gedetailleerd moeten plaatsvinden. Vervat functionele eisen in elementaire gesloten (ja/nee) vragen In een Programma van Eisen voor de selectie van een documentmanagementsysteem kwam de volgende eis voor: 47
Tijdens scanning niet automatisch verwerkte documenten, die in de wachtrij worden geplaatst, dienen afzonderlijk te kunnen worden opgevraagd en getoond op beeldscherm t.b.v. handmatige controle, verdere afhandeling (documentflow) dan wel aanvulling van kenmerken en indexering. In deze eis wordt veel tegelijk gevraagd, zoals: (a) niet automatisch herkende documenten moeten in een wachtrij geplaatst worden (b) de wachtrij moet op het scherm getoond kunnen worden (c) vanuit de wachtrij kunnen de niet herkende documenten bekeken worden (d) vanuit de wachtrij kunnen de documenten gerouteerd worden naar een medewerker (e) etc. Deze eis is in feite een zogenoemde samengestelde eis: hij bevat meerdere eisen tegelijk. De leverancier kan zo'n samengestelde eis niet eenduidig beantwoorden: enkel 'ja' of 'nee' is onmogelijk. Indien een leverancier gedeeltelijk aan de gestelde eis voldoet (bijvoorbeeld wel een wachtrij van niet herkende documenten, maar geen mogelijkheid om deze door te routeren naar een andere medewerker), voldoet hij gedeeltelijk aan de eis. Maar als alle leveranciers aangeven dat gedeeltelijk aan een eis voldaan wordt, zijn de antwoorden niet meer onderling vergelijkbaar. Het opstellen van het Programma van Eisen is dan dus zonde van de inspanning geweest. Door de eisen als elementaire vragen (die niet meer te splitsen zijn in meerdere vragen) te formuleren, worden de antwoorden van de leveranciers onderscheidend en kan een goede selectie gemaakt worden. Niet alle eisen en wensen zijn even belangrijk. Er is een klasse eisen die onvoorwaardelijk zijn: als een pakket niet aan deze eisen voldoet is het kopen niet meer aan de orde. Een dergelijke eis wordt ook wel een knock-outeis genoemd. Een voorbeeld hiervan is de gebruikte taal: over het algemeen is de eis dat het pakket geheel in het Nederlands moet zijn een knock-outeis. In het Programma van Eisen dient aangegeven te worden welke eisen de knock-outeisen zijn. Het is aan te raden een invulinstructie op te nemen in het Programma van Eisen. Zo zullen knock-outeisen meestal alleen met 'ja' of 'nee' beantwoord mogen worden, maar mag bijvoorbeeld bij andere eisen aangegeven worden dat de invulling ervan met maatwerk geboden wordt. Zorg voor een gebalanceerde weging van de onderdelen Een Programma van Eisen bestaat uit meerdere onderdelen: 'functioneel', 'techniek en beheer', 'open vragen', 'financieel'. In de vergelijking van de verschillende pakketten hoeven deze onderdelen natuurlijk niet allemaal hetzelfde gewicht te hebben. Bovendien wegen eisen zwaarder dan wensen. Hieronder is in een voorbeeld uitgewerkt hoe deze verschillende wegingen vormgegeven kunnen worden. Voor de beoordeling van de het ingevulde Programma van Eisen kan de volgende puntentelling gehanteerd worden voor de verschillende eisen en wensen. • E1-eisen zijn knock-out eisen. Indien hier niet aan voldaan kan worden, wordt de offerte niet verder in behandeling genomen. • E2-eisen: elke beantwoording van een E2-eis met 'ja' levert 10 punten op en elke beantwoording van een E2-eis met 'maatwerk' levert 5 punten op; • W(ens): elke beantwoording van een wens (W) met 'ja' levert 3 punten op. Een beantwoording van een W met 'maatwerk' levert 1 punt op. Het is belangrijk om bij elke met 'maatwerk' beantwoorde eis een exacte kostenspecificatie te vragen. Deze specificatie moet dan door de leverancier opgedeeld worden in kosten voor de initiële ontwikkeling en structurele kosten (onder andere onderhoud). Verderop in dit hoofdstuk zal hier nog uitgebreider bij worden stilgestaan. 48
Open vragen zijn ook een onderdeel van het Programma van Eisen. Voor elke open vraag kan tussen de 1 en de 10 punten gehaald worden. De score per open vraag wordt bepaald aan de hand van vooraf opgestelde modelantwoorden. De cijfers van alle antwoorden zullen bij elkaar worden opgeteld, en vervolgens per leverancier worden uitgedrukt in een percentage van het maximaal te verdelen aantal punten. In afbeelding 25 is een tabel opgenomen die aangeeft hoe de verschillende onderdelen ten opzichte van elkaar gewogen kunnen worden in de berekening van de eindscore. Dit heet een wegingsmatrix. Onderdeel Prijsstelling E1, E2, W • Algemeen • Functioneel • Techniek en beheer Open vragen
Subpercentage
Percentage 25% 60%
10% 60% 30% 15%
Afbeelding 25: voorbeeld van een wegingsmatrix
Stel open vragen voor extra inzicht Er zijn altijd vragen die niet of moeilijk elementair en gesloten (als ja/nee-vraag) gesteld kunnen worden, maar wel degelijk extra inzicht over het pakket en de leverancier op kunnen leveren. Dergelijke vragen kunnen dan gesteld worden in het onderdeel 'open vragen'. Een aantal voorbeelden van open vragen worden hieronder gegeven. Open vraag 1:
Wat zijn de onderscheidende verschillen tussen uw pakket en die van andere aanbieders? Met andere woorden: waarom zou voor uw pakket gekozen moeten worden?
Open vraag 2:
Wat is uw visie met betrekking tot onderhoud, helpdesk en nazorg? Waaruit blijkt deze in u aanbieding?
Open vraag 3:
Kunt u de toekomstvastheid van uw systeem garanderen? Welke zakelijke feiten dienen daarvoor als bewijs? Welke kwaliteitsborgingen, methode van projectmanagement en implementatiestrategie gebruikt u om een efficiënte en toekomstvaste implementatie te garanderen?
Open vraag 4:
Kunt u het strategisch belang aangeven van uw pakket voor uw eigen organisatie, bijvoorbeeld blijkend uit een met bewijs omkleed percentage Research & Development dat u hieraan (heeft) besteedt?
Maak de kosten van de verschillende pakketten vergelijkbaar De kosten van een pakket kunnen door de leverancier op duizend en één manieren weergeven worden. De resulterende kosten per leverancier kunnen niet zo maar met elkaar vergeleken worden. Om de kosten van de pakketten vergelijkbaar te krijgen, kan in het Programma van Eisen een standaardindeling voorgeschreven worden waarin de leverancier de verschillende kosten van het pakket moet gieten. Ter illustratie wordt hieronder een dergelijke standaard-indeling uitgewerkt. In afbeelding 26 is een bruikbare overzichtstabel opgenomen voor het verkrijgen van inzicht in de kosten, met daarin de totalen en uiteindelijk de totaalprijs van de offerte. Elke regel in de overzichttabel moet door de leverancier onderbouwd worden met een detailomschrijving.
49
Investeringskosten Omschrijving º
Bedrag
Structurele kosten (voor 1 jaar) Omschrijving Bedrag
Software Hardware Menskracht Overige kosten
Onderhoudscontract Supportcontract Overige kosten
Subtotaal
Subtotaal
Kortingspercentage
Kortingspercentage
Totaal van de offerte
Structurele lasten
Afbeelding 26: kostentabel
Elke regel van de tabel, zowel bij de investeringskosten als bij de structurele kosten, moet door de leverancier ingevuld en toegelicht worden. Hieronder volgt een voorbeeld van hoe de toelichting van de leverancier eruit zou kunnen zien. De toelichting investeringskosten software kan de volgende kostencomponenten specificeren: (a) Aanschafkosten van de benodigde standaardmodules van het pakket. Per benodigde module moet gespecificeerd worden wat de prijs is. (b) Ontwikkelkosten maatwerk: per genummerde eis/wens waar maatwerk aangegeven is, moet aangegeven worden wat de prijs is voor de realisatie van het maatwerk. Dit moet onderbouwd worden per genummerde eis. Voor elke eis moet worden aangegeven hoeveel uren benodigd zijn en derhalve (vermenigvuldigd met het uurtarief) wat de prijs is. De ontwikkeling van koppelingen is onderdeel van deze kosten. De toelichting investeringskosten hardware kan de volgende kostencomponenten specificeren: (a) Aanschafkosten van de hardwareconfiguratie en de systeemsoftware licenties (operatingsysteem, middleware, database) van de configuratie waarbij de gewenste beschikbaarheid van 99,8% gehaald wordt en waarbij geen data verloren gaat. De specificatie moet onderscheid maken tussen de verschillende hardwarecomponenten (servers, pc's, tapedevices, etc.) en tussen de verschillende softwarecomponenten. De toelichting investeringskosten menskracht kan de volgende kostencomponenten specificeren: (a) Benodigde menskracht (van de aanbieder) voor de installatie en inrichting van het systeem en het schrijven van het implementatieplan en ondersteuning tijdens de implementatie. De verschillende componenten zoals hiervoor genoemd moeten afzonderlijk gespecificeerd worden met een onderbouwing van uren * tarief. (b) benodigde menskracht van de aanbieder voor het verzorgen van opleidingen. Dit dient onderbouwd te worden met uren * tarief. In de toelichting structurele kosten kunnen de volgende kostencomponenten gespecificeerd worden (in euro's per jaar, inclusief B.T.W.): (a) Licentiekosten van de aangeschafte standaardsoftwarecomponenten, gespecificeerd per component. Aangegeven moet worden welke rechten verworven worden bij betaling van de licentiekosten (aantal releases e.d.). (b) Onderhoudskosten geleverde maatwerk. Aangegeven moet worden hoeveel uren onderhoud (fouten, e.d.) aan het geleverde maatwerk verwacht worden en wat het tarief is voor het onderhoud. In de toelichting structurele kosten support kunnen de volgende kostencomponenten gespecificeerd worden (in euro's per jaar, inclusief B.T.W.): (a) kosten van de helpdesk tijdens kantooruren; (b) kosten van de ondersteuning op locatie tijdens kantooruren.
50
Europese aanbesteding noodzaak? De procedure voor de Europese aanbesteding kent zo zijn eigen regels en stappen. Als algemene regel geldt dat de inkoop van diensten/leveringen boven een bedrag van 250.000 euro dient te worden aanbesteed. Daarbij gaat het niet alleen om de software zelf, maar ook de gerelateerde hardware, diensten van de leverancier en tevens het onderhoudsbedrag voor de komende drie jaar. De basis voor de Europese aanbesteding is het zogenaamde bestek, ofwel het eerder besproken Programma van Eisen. Dit Programma van Eisen heeft dan niet alleen betrekking op de software zelf, maar moet ook de af te nemen diensten, zoals installatie en te geven opleidingen, omschrijven. Belangrijke aandachtspunten bij het volgen van een Europese aanbestedingsprocedure zijn: (a) Alle leveranciers die meedingen moeten dezelfde informatie krijgen. (b) alleen dat wat in het bestek omschreven is, kan de basis zijn voor de selectie. Met andere woorden: grote zorgvuldigheid is noodzakelijk bij het opstellen van het Programma van Eisen voor een Europese aanbesteding. Op functionaliteiten die niet meegenomen zijn, kan later niet beoordeeld worden. (c) De verschillende wegingen en tellingen moeten exact omschreven worden. Ondertekening contract is het sluitstuk Is de keuze voor de leverancier en het pakket eenmaal gemaakt en door formele (bestuurlijke) besluitvorming afgedekt, dan kan het contract voor de aankoop en onderhoud van de hardware en software opgesteld en ondertekend worden. In het bestek voor de Europese aanbesteding kan ook een standaardcontract als voorbeeld meegenomen worden. Hiermee wordt aan de leverancier duidelijk gemaakt dat het contract van de leverancier met bijbehorende algemene voorwaarden niet geaccepteerd zal worden en dat het eigen voorbeeld contract van de gemeente de basis zal zijn. Het is aan te bevelen het plan van aanpak voor de invoering van het nieuwe pakket, zoals dat met de leverancier zal worden opgesteld, onderdeel te maken van het contract. Daarmee worden alle afspraken rond de implementatie en eventuele toezeggingen formeel bevestigd. De juridische aspecten van Europese aanbesteding zijn van een hoog specialistisch gehalte. Bij de uitvoering en afronding van de Europese aanbesteding kan juridische ondersteuning gewenst zijn.
51
6 Implementatieplan is een kritieke succesfactor Het pakket is geselecteerd en het contract is ondertekend. De invoering van het nieuwe pakket 16) kan nu starten. Een goede invoering van een nieuw pakket valt of staat met de voorbereiding. De vraag is echter welke aspecten allemaal een rol spelen bij een dergelijke voorbereiding en hoe de implementatie georganiseerd kan worden. In dit hoofdstuk wordt eerst stilgestaan bij de verschillende aandachtsgebieden van een dergelijke implementatie, waarna ook ingegaan wordt op de organisatie van de implementatie. Achtereenvolgens komen aan de orde: (a) de aandachtsgebieden van de implementatie; (b)de (project) organisatie van de implementatie; (c) de kosten van de implementatie. De aandachtsgebieden van een implementatie: bedrijfsvoering leidend De belangrijkste aandachtsgebieden bij een implementatie worden aan de hand van de volgende figuur (afbeelding 27) toegelicht. Een implementatietraject van een nieuw systeem heeft altijd ruwweg twee invalshoeken: enerzijds de organisatorische, anderzijds de technische informatiserings- en automatiserings (I&A-) kanten. Op het organisatorische vlak wordt bepaald hoe het werk gedaan moet worden, of hoe het werkproces (bijvoorbeeld het werkproces van casemanagement) eruit moet zien en welke managementinformatie noodzakelijk is.
Afbeelding 27: aandachtsgebieden van het invoeringstraject 16)In deze handreiking wordt consequent gesproken over de invoering van een nieuw pakket, ervan uitgaande dat nog geen CVS in gebruik is. Mocht dit wel aan de orde zijn, dan zal het implementatieproces nagenoeg gelijk verlopen, met dien verstande dat de gegevens zullen moeten worden geconverteerd van het oude pakket naar het nieuwe pakket.
53
De technische aspecten volgen steeds uit wat in de organisatie bedacht wordt. Wel zijn er altijd (technische en functionele) grenzen aan de mogelijkheden van een pakket. Vaak biedt de leverancier van het pakket een mogelijkheid middels maatwerksoftware om deze grenzen wat te verleggen. Het is echter belangrijk om in het achterhoofd te houden dat het (laten) ontwikkelen van maatwerk zeer kostbaar is en dat de kosten exponentieel groeien bij een kleine toename van het maatwerk. Het aanpassen van het werkproces aan de mogelijkheden en onmogelijkheden van het pakket is dan het overwegen meer dan waard. Een aantal deelaspecten worden hieronder afzonderlijk behandeld. Hierbij staat steeds één kernvraag centraal. Bedrijfsvoering: kaal of niet kaal Als wordt vastgesteld hoe het nieuwe pakket ingeregeld moet worden zijn globaal de volgende twee uitersten te onderscheiden: (a) Het nieuwe pakket wordt ingeregeld aan de hand van de huidige manier van werken. Dit is de zogenaamde kale overgang: bij de invoering van het nieuwe systeem verandert er dan in het werkproces niets. (b) De invoering van het nieuwe pakket wordt aangegrepen om (reeds lang geplande) verbeteringen in het werkproces door te voeren, mede op basis van de uitgebreidere mogelijkheden van het nieuwe pakket. Bij deze werkwijze verandert het werkproces en daarmee de manier van werken wel: de overgang wordt hiermee niet kaal. De laatste, niet kale variant heeft over het algemeen de voorkeur (en lijkt met de Sluitende Aanpak en casemanagement onontkoombaar!). Het verbeteren van de kwaliteit van de bedrijfsvoering is en blijft een belangrijke doelstelling. Er is echter niet altijd de tijd uitgebreid na te denken over de manier waarop met het nieuwe systeem gewerkt moet worden, anders dan door voortbouwen op de huidige vertrouwde werkwijze. Er kan dan gekozen worden voor het maken van een kale overgang met op een later tijdstip een extra verbeteringsslag. Welke keuze gemaakt wordt, hangt vaak af van de betrokkenen. In een overgang die gedomineerd wordt door betrokkenen met een technische achtergrond (zoals beheerders) valt de keuze meestal uit op de kale variant. De nadruk van de overgang ligt dan immers op de I&A-aspecten in plaats van de organisatorische aspecten. Documenten: wie wat wanneer? Voordat het systeem ingericht wordt, zal door de bedrijfsvoering bepaald moeten worden welke documenten het systeem moet aanmaken. Er zijn daarbij twee soorten documenten: (a) brieven en dergelijke die tijdens het werk door de gebruiker aangemaakt worden; (b) rapportages voor het management. Het motto 'in de beperking toont zich de meester' is hierbij zeker aan de orde. De druk om meer en meer brieven en managementrapportages te maken is continu aanwezig. De noodzaak van elke extra brief of rapportage moet zorgvuldig gewogen worden. Een mogelijk en bruikbaar uitgangspunt is: dat wat minimaal noodzakelijk is voor de uitvoering van het werk is dat wat maximaal gemaakt wordt. Installatie: is de machinerie op orde? Een nieuw systeem stelt eisen aan de gehele ICT-infrastructuur. Van alle onderdelen van de infrastructuur moet bepaald worden of ze aan de eisen van het nieuwe systeem kunnen voldoen: (a) werkplek PC's en besturingssysteem: bezitten de werkplek PC's voldoende geheugen en snelheid of moeten ze vervangen worden? Is het gebruikte besturingssysteem (bijvoorbeeld Windows 95) geschikt of moet overgestapt worden naar een nieuwere versie? (b) netwerkbekabeling en componenten: is er voldoende netwerkcapaciteit beschikbaar om het nieuwe systeem te kunnen ondersteunen of is uitbreiding noodzakelijk? (c) servermachines, besturingssysteem en database: welke componenten moeten gekocht worden? 54
Na de aanschaf van de verschillende benodigde infrastructuuronderdelen moeten deze ook beheerd worden. Dit houdt in dat de vraag door wie de nieuwe onderdelen aangelegd en onderhouden moeten worden al tijdens de voorbereiding van de overgang beantwoord moet worden. Conversie: een schone lei Bij de overgang naar een nieuw systeem bestaat er over het algemeen reeds een oud systeem. Dit oude systeem bevat natuurlijk een groot aantal gegevens over bijvoorbeeld cliënten en gevolgde opleidingen. De gegevens van een oud systeem zijn vaak vervuild: wijzigingen zijn bijvoorbeeld niet consequent doorgevoerd en naar andere gemeenten verhuisde of overleden cliënten zijn nog in het systeem aanwezig. Het meenemen van de vervuiling naar het nieuwe systeem is natuurlijk mogelijk, maar niet verstandig. Bij een verhuizing naar een nieuw huis wordt immers oude rommel ook niet ingepakt en in het nieuwe huis weer uitgepakt: een verhuizing is vaak de aanleiding om eens goed de bezem door alle in de loop van de tijd verzamelde rommel te halen. Zo ook bij de overgang naar een nieuw systeem. Het opruimen van vervuilde gegevens is echter geen triviale bezigheid. Van elk geregistreerde gegeven moet bekeken worden of het meegenomen moet worden naar het nieuwe systeem. Meestal zijn gegevens in het nieuwe systeem anders geregistreerd. Bijvoorbeeld: het oude systeem heeft één veld voor de gehele naam en het nieuwe systeem heeft één veld voor de eerste voornaam, één veld voor de voorletters, één veld voor de tussenvoegsels en één veld voor de achternaam van een cliënt. Voor elke geregistreerde gegeven moet voor de conversie dan ook bekeken worden wat de verschillen tussen het oude en het nieuwe systeem zijn. De uitvoering van de conversie kan handmatig uitgevoerd worden. De gegevens worden dan in het nieuwe systeem opnieuw ingevoerd tegelijk met het opschonen. Voor grote aantallen cliënten is dit veel werk. Ook een geautomatiseerde conversie kan overwogen worden. Het opschonen moet dan vooraf in het oude systeem gebeuren. Geautomatiseerd converteren heeft beperkingen: een deel zal altijd handmatig moeten. De hoeveelheid handmatig conversiewerk hangt af van de verschillen tussen het oude en het nieuwe systeem. Bij grote verschillen zal handmatige conversie onoverkomelijk zijn. Acceptatie: doet-ie het of doet-ie het niet? Het nieuwe systeem is volledig geïnstalleerd en ingeregeld en de leverancier zegt dat het in productie kan. Dat doet u natuurlijk niet voordat u zeker weet dat alles werkt. En dat kunt u alleen zeker weten door zelf een aantal tests uit te voeren. Het argument dat het bij andere, ook grotere, gemeenten reeds goed werkt, snijdt geen hout. Immers het systeem is ingeregeld op de unieke kenmerken van de gekozen werkwijze. Mogelijk is het de eerste keer dat het systeem op deze wijze gebruikt wordt. Bepalen of het systeem werkt, kan aan de hand van testcases. Wanneer bepaald wordt hoe het systeem ingeregeld moet worden, kunnen deze testcases opgesteld en gedocumenteerd worden. Deze testcases moeten gebaseerd zijn op realistische voorbeelden uit de dagelijkse praktijk en een goede afspiegeling vormen van dat wat met het nieuwe systeem gedaan zal gaan worden. Nadat de testcases succesvol doorlopen zijn, kan het systeem formeel geaccepteerd en in productie genomen worden. In het contract met de leverancier kunnen afspraken gemaakt worden over de betaling, gerelateerd aan de formele acceptatie. Een systeem dat niet door de testcases komt, voldoet niet aan de gestelde eisen. Een projectmatige aanpak van de implementatie is noodzakelijk De verschillende aspecten zoals hiervoor behandeld moeten in hun onderlinge samenhang gemanaged worden. Er zijn verschillende afhankelijkheden tussen de verschillende deelgebieden. Een projectmatige aanpak met een in een projectplan uitgewerkte afbakening, planning en kostenraming is een belangrijk stuurmiddel.
55
In afbeelding 28 is een mogelijke projectorganisatie opgenomen. Afhankelijk van de omvang van het project kunnen meerdere functies in dezelfde persoon gecombineerd worden. Hierbij moeten echter wel de organisatorische aspecten en de technische I&A-aspecten gescheiden blijven: deze zijn niet verenigbaar in één persoon.
Afbeelding 28: voorbeeld van een projectorganisatie
Doel van het deelproject 'bedrijfsvoering' is op eenduidige wijze de gewenste werkwijze en inrichting van het nieuwe systeem te omschrijven. Als bijvoorbeeld in het nieuwe pakket de mogelijkheid bestaat van een werkstroombesturing in te regelen, dan zal dit deelproject moeten bepalen op welke wijze en tot welk niveau dit gedaan moet worden om de bedrijfsvoering optimaal te kunnen ondersteunen. De uiteindelijke installatie van de software en de inrichting aan de hand van de werkwijze die in het deelproject 'bedrijfsvoering' bepaald is, behoren tot de werkzaamheden van het deelproject 'installatie, inrichting en formele acceptatie'. Het doel van het deelproject 'conversie' is het (waar nodig) overzetten en mogelijk opschonen van de registreerde gegevens van het oude naar het nieuwe systeem. Het doel van het deelproject 'koppelingen en maatwerk' is de realisatie van de mogelijk gewenste koppelingen tussen het nieuwe systeem en bijvoorbeeld een financieel systeem. Daarnaast heeft dit deeltraject als doel het op dit moment aanwezige maatwerk te inventariseren en zoveel als mogelijk te reduceren. Door het deelproject 'koppelingen en maatwerk' zal beargumenteerd een lijst met onoverkomelijk maatwerk opgesteld worden, die ter formele accordering en besluitvorming aan het MT voorgelegd zal worden. Het deelproject 'technische randvoorwaarden' heeft tot doel een beheerde technische infrastructuur neer te zetten welke voldoet aan de randvoorwaarden zoals die door het nieuwe systeem gesteld worden, rekening houdend met groeiverwachtingen en de gebruik name van toekomstige modules. 56
Activiteiten die uitgevoerd moeten worden in het kader van opleidingen worden uitgevoerd door het deelproject 'opleidingen'. Het doel is de medewerkers op te leiden zodat ze gebruik kunnen maken van de functionaliteiten zoals het nieuwe systeem ingeregeld wordt. Het deelproject 'managementinformatie' heeft als taak het waarborgen dat de benodigde managementinformatie in het nieuwe systeem beschikbaar is. Beschouw zowel de eenmalige als de structurele kosten De implementatie van een nieuw pakket kost geld. Zowel de eenmalige kosten voor het uitvoeren van de implementatie zelf (kosten projectorganisatie, kosten compensatie productieverlies in verband met opleidingen en gewenning aan het nieuwe systeem), als ook de jaarlijks terugkerende structurele kosten zoals die van hardwareonderhoud en softwarelicenties. Afbeelding 29 geeft een totaaloverzicht van de bij een implementatie aanwezige kosten.
Afbeelding 29: kosten van de implementatie
57
Nawoord De implementatie van een CVS is een majeure operatie, die alleen mogelijk is wanneer het gehele traject van voorbereiding in de organisatie, selectie en implementatie van het systeem wordt doorlopen. Daarbij dienen vele keuzes te worden gemaakt, zullen aanpassingen in de organisatie moeten plaatsvinden (conform de invoering van de sluitende aanpak) en zullen aanzienlijke kosten moeten worden gemaakt. Uiteindelijk komt echter wel een structurele oplossing ter beschikking, als vervanger van de huidige handmatige, gedeeltelijke handmatige of geen registraties. Dat de ontwikkeling van een CVS niet van de ene op de andere dag kan plaatsvinden, tonen de onderzochte systemen aan. De meeste systemen zijn nieuw op de markt en maken daarbij overigens dankbaar gebruik van de recente voorschriften rond gegevensstandaardisering (SUWI-gegevensset) en MoSA. Dat een (adequaat) geautomatiseerd systeem vele voordelen kent voor de registratie, de sturing en beheersing en de verantwoording rond de nieuwe processen van casemanagement is evident. Anderzijds, niet aan alle eisen en wensen van de nu gevraagde verantwoordingsinformatie is geautomatiseerd te voldoen. Dit heeft niets te maken met 'onwil' aan de kant van de WIZ-diensten of de leveranciers, maar alles met de afstemming tussen de gegevensdefinities die in de diverse monitoren worden gehanteerd. Opmerkelijk is en blijft dat de gegevensdefinities tussen de MoSA, Agenda van de Toekomst, monitor Nieuwkomers & Oudkomers niet voor 100% op elkaar aansluiten. Dit leidt opnieuw tot handmatige registraties, dan wel extra registraties, die door afstemming voorkomen hadden kunnen worden!
59
A Voorbeeld Programma van Eisen Het Programma van Eisen (PvE) is opgebouwd uit vier delen, namelijk: (a) de functionele eisen voor de applicatie (b) de gebruikerseisen (gericht op de eindgebruikers) (c) de technische eisen (gegevens, techniek en beheer) (d) de leverancierseisen. Functionele eisen In onderstaande tabel zijn de relevante functionele eisen voor een CVS opgenomen. Daarbij dient te worden uitgegaan van een eenduidig begrippenkader, namelijk: (a) Vastleggen betekent in dit geval zowel het registeren als het kunnen wijzigen, verwijderen en raadplegen. (b) Trajectact iviteit is hier een specifiek instrument dat voor een specifieke cliënt is ingezet (bijvoorbeeld deelname van de heer Jansen aan de cursus 'Nederlands voor Nederlandstaligen' op donderdagmiddagen van 13.30 - 16.30 via de Stichting Leer Nederlands!, van 15 maart tot 19 juli 2002). (c) Product is hier een instrument dat door een specifieke leverancier kan worden geleverd (cursus 'Nederlands voor Nederlandstaligen', te leveren door de Stichting Leer Nederlands!). (d) Contract is hier de verzameling afspraken rond (een verzameling) producten van een specifieke leverancier (onder meer prijs, hoeveelheid, kwaliteit). Functionele eisen Primair Proces Casemanagement I
Ondersteunen van het motiveren en activeren cliënten ('op traject zetten')
Registreren (kwalificerende) persoonsgegevens 1.1 Verifiëren en (vervolgens, eventueel gewijzigd) overnemen aangeleverde gegevens (bv. CWI, PGI, uitkeringensysteem) • Cliëntgegevens • Inschrijvingsgegevens • Gegevens over werkervaring en opleiding • Faseringsgegevens • Arbeidsmarktkwalificaties 1.2 Vastleggen aanvullende (kwalificerende) informatie (enkele voorbeelden, zie gegevensmodel) • Belemmeringen • Motivatie • Vaardigheden 1.3 Vastleggen cliëntspecificaties, bijvoorbeeld: • cliëntgroep (NUGger, uitkeringsgerechtigde, etc.), • status (actief, uitgestroomd naar werk, etc.) • casemanager Raadplegen (kwalificerende) persoonsgegevens 1.4 Presenteren overzicht cliëntbeeld op één scherm Registreren trajectplan 1.5 Selecteren van een voorgedefinieerd trajectplan (sociale activering, arbeidsactivering, zorg, rust) 1.6 Vastleggen van een vrij in te richten trajectplan 1.7 Vastleggen trajectplangegevens (doelstelling, duur, soort trajectplan etc) 1.8 Selecteren uit (stedelijk/regionaal/contractgebonden) aanbod producten (mogelijke producten van externe partijen voor sociale activering, arbeidstoeleiding en flankerend beleid) 1.9 Mogelijkheid gebruik digitale kaart aanbod producten 1.10 Vastleggen van incidentele nieuwe producten (conform basis gegevensset producten/contract) 61
1.11
Vastleggen van de planning van trajectactiviteiten (startdatum, einddatum, verwachte resultaat, kosten, financieringsbron (voor te definiëren per product en te wijzigen per ingezette activiteit) 1.12 Verifiëren en (vervolgens, eventueel gewijzigd) overnemen aangeleverde gegevens betreffende trajectplan (indien (deels) uitbesteed) Registreren trajectvoortgang 1.12 Vastleggen van afspraken (data) met cliënten 1.13 Vastleggen status trajectplan (volgens voorgedefinieerde statussen goedkeuringsprocedure en procesverloop) 1.14 Vastleggen aanmelding voor een product 1.15 Vastleggen planning en daadwerkelijke realisatie 1.16 Verifiëren en (vervolgens) overnemen aangeleverde gegevens betreffende trajectvoortgang (indien (deels) uitbesteed) Registeren trajectresultaten 1.17 Vastleggen inhoudelijke afspraken met cliënten 1.18 Vastleggen resultaten van ingezette trajectactiviteiten 1.19 Vastleggen resultaat trajectplan 1.20 Vastleggen financiële aspecten 1.21 Verifiëren en (vervolgens, eventueel gewijzigd) overnemen aangeleverde gegevens betreffende trajectresultaten (indien (deels) uitbesteed) Genereren/opslaan/raadplegen/printen van brieven/documenten 1.22 Documenten betreffende cliëntcontact (uitnodiging, afspraken notitie, 'beschikking doelmatigheid', etc) 1.23 Document 'trajectplan' 1.24 Aanmelding voor een product 1.25 Wat is de visie op de koppeling tussen het CVS en tekstverwerkingssystemen? 1.26 Wat is de visie op de koppeling tussen het CVS en de opslag van documenten? Procesondersteuning (zie ook monitoring) 1.27 Ondersteunen van het plannen van afspraken 1.28 Plannen/signaleren van acties met datum 1.29 Wat is de visie op de koppeling tussen het CVS en (spreekkamer)planningssystemen? 1.30 Ondersteuning van de werkstroom door de organisatie • De werkstroom is voorgedefinieerd in het systeem • De werkstroom is zelfstandig aan te maken/muteren Bewaren van historie 1.31 Bewaren van historie van (kwalificerende) persoonsgegevens, trajectplangegevens, voortgang etc. II 2.1
Onderhouden uitkeringsverstrekking Wat is de visie op de wijze waarop de relatie met het uitkeringensysteem (bv. voor aanvragen uitkering, opleggen boete, aanvragen bijzondere bijstand, verstrekken premies) wordt onderhouden?
III 3.1
Monitoren cliëntactiviteiten Op het scherm presenteren van het statusoverzicht 'wat gebeurt er door wie met de cliënt' in het kader van • uitkeringverstrekking • activering Signaleren van niet nagekomen afspraken cliënt Signaleren van afwijkingen verwacht resultaat trajectactiviteiten Signaleren van afwijkingen verwachte planning trajectactiviteiten Tonen uitgevoerde en geplande trajectactiviteiten in één scherm
3.2 3.3 3.4 3.5
Secundair process Casemanagement IV
Onderhouden relatie inkoop- en contractbeheer 62
4.1 4.2 4.3 4.4 4.5 4.6 V 5.1 5.2
5.3 VI 6.1 6.2 6.3 6.4
6.5
6.6 6.7
Vastleggen gegevens contractpartij/contracten Vastleggen begin- en einddata, verwacht resultaat en financieringsbron product Vastleggen resultaten product(stadium) (terugkoppeling RIB) Accorderen geleverde contractprestaties (is het product geleverd door de externe partij conform afspraak) Bewaken beschikbare aantal deelnames per product Mogelijke opname kwaliteitskenmerken/ervaringen met trajectinstrumenten Bewaken declarabiliteit Onderhouden instrumentenlijst (= gecategoriseerd aanbod van producten van externe partijen voor cliënten en bijbehorende financieringsbron) Behandelen aanvraag individueel product • contractgegevens vastleggen • productspecificatie vastleggen • financieringsbron aangeven Wat is de visie op de relatie tussen het CVS en financiële systemen? Management-/Beleidsinformatie/Externe gegevensverstrekking Rapporteren via standaard rapportage overzichten Ad hoc combineren vastgelegde gegevens en verwerken in een rapportage (overzichten op niveau van cliëntcriteria, casemanager, product/contract) Raadplegen financiële aspecten van trajectactiviteiten per cliënt en per casemanager Samenvatten planning versus realiteit voor trajectactiviteiten • Doorlooptijd • Kosten Overzicht gemaakte afspraken (o.a. naar cliënt, naar periode) • In de toekomst • In het verleden Genereren MoSA-gegevensset Exporteren gegevenssets vanuit de database naar extern bestandsformaat (bv. .xls, .txt, .doc)
Gebruikerseisen Door de eindgebruikers van de applicatie (degenen die er dus dagelijks mee werken) kunnen diverse eisen en wensen worden geformuleerd. In onderstaande tabel zijn de belangrijkste opgenomen. Gebruikerseisen 1. User interface is grafisch (GUI) 2. Afsluiten van een scherm is alleen maar mogelijk zodra de noodzakelijke verplichte invoervelden gevuld zijn 3. Invoer van gegevens vindt consistent plaats, zo mogelijk met de keuze muisgestuurd of door middel van toetscombinaties 4. Op een invoerscherm kunnen niet gebruikte velden afgeschermd worden 5. De schermen zijn aanpasbaar (bv. bulkschermen zonder overtollige velden moeten samengesteld kunnen worden). 6. Indien van toepassing wordt per veld de keuzemogelijkheden voor invoer weergegeven 7. In de helpschermen bestaat een on-line koppeling met de (digitale) gebruikershandleiding 8. Indien een bewerking niet mogelijk is, verschijnt een begrijpelijke foutmelding met de uitleg van de fout 9. Springen van veld naar veld zonder muis (o.a. bij gegevensinvoer) is mogelijk 10. De inhoud van velden kan naar andere applicaties (bv. Kantoorautomatisering) worden gekopieerd 11. Helptekst is context gevoelig Technische eisen De technische eisen die aan een applicatie kunnen worden gesteld, worden in dit PvE onderscheiden in drie delen, namelijk rond: 63
(a) de informatierelatie en de gebruikte gegevens (b) het functionele beheer (c) de technische infrastructuur. Informatierelatie & gegevensmodel De informatierelatie tussen het CVS en andere systemen, gericht op het hergebruik van reeds aanwezige gegevens, richt zich primair op de aanwezige uitkeringensystemen. Daarnaast is het van belang dat het CVS, wat betreft de definitie van gegevens, aansluit op de landelijke standaarden, dat wil zeggen de gegevensset Abw (ontleend aan het SUWI-gegevensregister, versie 1.0) en de MoSA-verantwoording. In onderstaande tabel zijn de relevante vragen hieromtrent opgenomen. Informatierelaties & gegevensmodel 1. Kan uw applicatie functioneren met de gegevens uit het uitkeringensysteem en welke voorwaarden worden hieraan gesteld ? 2. Met welke uitkeringensystemen kan uw applicatie worden gekoppeld? 3. Kunnen wij in het kader van dit onderzoek beschikken over een lijst met gegevens die in uw applicatie worden gebruikt/vastgelegd ? 4. Wordt in het gegevensmodel van uw applicatie rekening gehouden met de gegevensdefinities/ de gegevensstructuur van de SUWI-gegevensset en de MoSA? 5. Wordt in uw applicatie rekening gehouden met het BinnenGemeentelijke standaarduitwisselingsformaat (STUF BG) ? Functioneel beheer Vanuit beheersperspectief is het van belang vast te stellen, welke eisen worden gesteld aan het functionele beheer van de applicatie enerzijds en de mogelijkheden (vrijheden) van de applicatie anderzijds. In onderstaande tabel zijn de relevante vragen opgenomen. Functioneel beheer 1. Het is mogelijk om zelf (onafhankelijk van de leverancier) invoer- en raadpleegschermen samen te stellen 2. Het is mogelijk om zelf diverse tabellen in te richten (en te beheren) voor gemeentespecifieke zaken, zoals bijvoorbeeld de ingekochte producten (trajecten), de instelling van waarden in tabellen e.d. 3. Het is mogelijk om zelf de procesinrichting (AO) in het systeem in te stellen, afhankelijk van de gekozen invulling van casemanagement 4. Opschonen van historische gegevens is mogelijk 5. Het beheer over de programma's van het systeem via een beheerfunctie (bv. Functioneel beheer/applicatiebeheer) is mogelijk. 6. Het pakket biedt minimaal de autorisatie op menu, functie (in menu) en veld 7. Het muteren van gebruikers met bijbehorende autorisatie kan via een aparte functie 8. De autorisatie kan via rollen/profielen aan personen/groepen van personen/functies worden gekoppeld 9. Uitloggen is niet mogelijk bij niet afgemaakte bewerkingen 10. Er is een herstelprocedure aanwezig bij uitval van het systeem 11. Real-time en batchverwerking is mogelijk 12. Bij elke aanpassing van het pakket wordt niet alleen de documentatie geactualiseerd, maar ook de wijzigingen t.o.v. de voorgaande aangegeven 13. Bewerking op meerdere plekken tegelijkertijd door meerdere gebruikers zelfs in eenzelfde programma(onderdeel) is mogelijk 14. Bestandsbeveiliging dient zodanig te zijn, dat bij calamiteiten lopende procedures zonder gevolg worden stopgezet en nadien voortgezet c.q. opnieuw kunnen worden uitgevoerd (back up van de bestanden terugzetten en vervolgens de verrichte handelingen reconstrueren) 15. Bij levering van aanpassingen in het programma en/of de bestandsstructuur bestaan er waarborgen voor de continuïteit van de werking van de applicatie (audit door leverancier) 16. Teksten van helpschermen zijn door de functioneel beheerder aanpasbaar en dus uitbreidbaar 17. Het is traceerbaar wie op een bepaald moment met welk programma werkzaam is 18. Het systeem laat bij elke ingevoerde codering de omschrijving zien 64
De technische infrastructuur In onderstaande tabel zijn de relevante items opgenomen, die betrekking hebben op de eisen die de applicatie (het CVS) stelt aan de technische infrastructuur van een GSD/gemeente. Aangezien bij dit onderdeel sprake is van een omgekeerde relatie (de applicatie stelt eisen), zijn de eisen in vragende vorm geformuleerd. Vragen technische infrastructuur Antwoord 1. Omschrijf de architectuur (client/server, thin client, etc)? Centrale infrastructuur 2. Op welke hardwareplatforms wordt het systeem uitgeleverd? Onder welk besturingssysteem? Welke versies? 3. Welke RDBMS-en worden ondersteund? Welke versies? 4. Welk harddisk en geheugenbeslag wordt er gelegd? 5. Welke additionele licenties zijn vereist op de server? Koppelingen 6. Wordt de mogelijkheid geboden basiscliëntgegevens op regelmatige basis over te nemen uit een ander systeem? 7. M.b.t. databaseconnectiviteit: Is het mogelijk om de database te benaderen over een native of ODBC-koppeling (met het oog op gebruik van reporting tools als Cognos en business objects) 8. Welke visie heeft de leverancier op (technische) koppelingen met andere systemen? • Uitkeringensysteem • Workflowpakketten • Tekstverwerkings/rapportagesystemen • Systemen van Reïntegratiebedrijven • Managementrapportage tools 9. Met welke systemen is uw applicatie daadwerkelijk te koppelen (in de praktijk gerealiseerd)? Transport infrastructuur 10. Welke netwerkprotocollen worden ondersteund (novell ipx, netbios, tcp/ip, sna etc.) ? 11. Welke bandbreedte is minimaal noodzakelijk per gebruiker die muteert (uitgaande van voldoende servercapaciteit)? (in Kbps) 12. Welke bandbreedte is minimaal noodzakelijk per gebruiker die raadpleegt (uitgaande van voldoende servercapaciteit)? (in Kbps) Client 13. Wat is de minimale hardwareconfiguratie? • Geheugen (in Mb's) • Processorsnelheid (in MHz) • Harddiskgrootte (in Mb's) • Minimale videoresolutie (aantal pixels, kleurendiepte) 14. Welke operating systemen worden ondersteund? Welke versies? 15. Welke additionele licenties zijn vereist op de client? 16. Welke software pakketten voor tekstverwerking worden ondersteund ? 17. Kan de client-applicatie draaien in een terminalserveromgeving (bv. Citrix)? 18. Kan de client-applicatie beschikbaar worden gesteld via een browserinterface (internet explorer)? 19. Kan de applicatie onder een ander workflow pakket gehangen worden? Zo ja: Is dit al eerder gedaan en met welk workflowpakket?
65
Leverancierseisen De leverancierseisen geven enerzijds een beeld van de leverancier zelf wat betreft marktpositie, organisatie en toekomstige ontwikkelingen en anderzijds een beeld van de ondersteuning rondom de applicatie. Ook hier geldt dat de relevante items in de vorm van vragen zijn opgenomen. Leverancierseisen Vraag Antwoord 1. Kunt u een indruk geven van het aantal implementaties van uw product binnen de GSD'en? 2. Wat is de jaarlijkse omzet van uw organisatie? (orde van grootte) 3. Wat is de jaarlijkse omzet van uw organisatie voor het CVS? (orde van grootte) 4. Hoeveel personeel (in fte) heeft uw organisatie in totaal? 5. Hoeveel personeel (in fte) van uw organisatie houdt zich bezig met het CVS? 7. Wat is de hoogte van de jaarlijkse investeringen in productontwikkeling voor het CVS? 8. Op welke wijze zijn de continuïteit en stabiliteit van uw organisatie en het CVS nu en in de toekomst gegarandeerd? 9. Productontwikkeling: • Wanneer is het CVS voor het eerst op de markt gekomen? • Om welke versie van CVS gaat het? • Hoeveel releases van CVS worden per jaar voorzien? • Hoeveel releases en patches zijn er in de afgelopen 2 jaar uitgebracht? • Welke concrete releases staan er op korte termijn op de planning? • Welke functionaliteit wordt daarin voorzien? • Welke strategische aanpassingen aan het CVS staan in de planning? En wanneer? • Wat (welke) is het unieke 'selling-point' van uw applicatie? Vraag
Ja/Nee
Eventuele Toelichting Welke producten/informatie stelt u naast de 'kale' levering van het pakket ter beschikking : (graag ja/nee vragen hierna beantwoorden) 1. Bij aanschaf van het systeem wordt door de leverancier Ja/Nee een gebruikershandleiding ter beschikking gesteld (hierin staan de werking van de programmaonderdelen en de betekenis van de menu's); het gegevensmodel en de datadictionary 2. Handleidingen eindgebruiker zijn beschikbaar Ja/Nee 3. De gebruikershandleiding, zowel op schrift als digitaal, is in de Nederlandse taal gesteld Ja/Nee 4. De schermen, helpteksten en aanvullende gebruikersdocumentatie zijn in het Nederlands. Ja/Nee 5. Handleidingen beheerder zijn beschikbaar Ja/Nee 6. Opleidingen worden geboden Ja/Nee 7. Functionele beschrijving/ontwerpen zijn beschikbaar Ja/Nee 8. Er bestaat een door de leverancier geïnitieerde Ja/Nee gebruikersgroep 9. Er wordt een helpdesk aangeboden. Ja/Nee 10. De leverancier beschikt over een ESCROW of vergelijkbare Ja/Nee regeling
66
B Gebruikte afkortingen Abw ANW AO ASP BKWI CBS CVS CWI ESF FWI GSD GUI I&A IB ICT I/D-baan MoSA NUG'er PvE RDBMS REA RIB ROC SNO STUF BG SUWI SUWI-ML SQL SZW UWV WIN WIW WIZ-dienst WSW XML
Algemene Bijstandswet Algemene Nabestaandenwet Administratieve Organisatie Application Service Providing Bureau Keteninformatisering Werk & Inkomen Centraal Bureau voor de Statistiek Cliëntvolgsysteem Centrum voor Werk en Inkomen Europees Sociaal Fonds Fonds Werk en Inkomen Gemeentelijke Sociale Dienst Grafische Userinterface Informatie & Automatisering Inlichtingenbureau Informatie en Communicatietechnologie In- en doorstroombaan Monitor Scholing en Activering Niet uitkeringsgerechtigde Programma van Eisen Relationeel Database Managementsysteem Wet op de Reïntegratie van Arbeidsgehandicapten Reïntegratiebedrijf Regionaal Opleidingscentrum Service Niveau Overeenkomst Standaard Uitwisselingsformaat Binnengemeentelijk Samenwerking Uitvoering Werk en Inkomen XML-extensies bestemd voor gegevensuitwisseling binnen het SUWI-domein Structured Query Language Ministerie van Sociale Zaken en Werkgelegenheid Uitvoeringsinstelling Werknemersverzekeringen Wet Inburgering Nieuwkomers Wet Inschakeling Werkzoekenden Werk, Inkomen, Zorg-dienst Wet Sociale Werkvoorziening eXtensible Markup Language
67
Colofon Opdrachtgever Ministerie van Sociale Zaken en Werkgelegenheid Steunpunt Suwi Gemeenten Postbus 90801 2509 LV Den Haag telefoon: 333 57 50 e-mail:
[email protected] Uitgave Steunpunt Suwi Gemeenten Basistekst StimulanSZ in samenwerking met PWC Consulting Vormgeving en Productie Facilitair Bedrijf Postale, Grafische & Multimedia Aangelegenheden-73W746 Met dank aan De gemeenten Amsterdam, 's Hertogenbosch, Horst aan de Maas, Leeuwarden, Nijmegen en Zaanstad. 1e druk augustus 2002