Inleiding
Een dienstverlenende publieke organisatie (verder: organisatie) streeft naar optimale dienstverlening aan cliënten, stuurt op kwaliteit, kwantiteit en effect en legt hierover verantwoording af (transparantie). In dat kader heeft deze organisatie er belang bij haar diensten zo veel mogelijk meetbaar en controleerbaar te verlenen en de realisatie te toetsen aan normen. Ze legt daartoe normgegevens vast in een drietal sjablonen:
- een voor het vastleggen van de functionaliteit afgeleid uit onde meer wet- en regelgeving. Verder te noemen: functionele specificatie (extern gericht).
- een voor de registratiegegevens voor het registreren en tellen in systemen. Verder: technische specificatie (intern gericht).
- de normering voor het ramen van de benodigde directe (mens)capaciteit en (door toevoeging minuuttarieven) directe kosten. Verder: normblad (intern gericht).
Uniforme invulling en gebruik van de gegevens over diensten binnen een organisatie:
- bevordert de onderlinge vergelijkbaarheid
- faciliteert proces- en systeemontwikkeling
- vereenvoudigt de afbakening met aanpalende statistische gegevens
- bevordert communicatie via beschikbaarstelling aan gebruikers via intranet.
Een uitvoeringsorganisatie bundelt en publiceert de norminformatie over diensten bij voorkeur in een portfolio op intranet (web-applicatie). Een deel hieruit, de cliëntgerichte informatie, correspondeert met publicaties op internet. Cliënten weten daardoor wat ze mogen verwachten en kunnen reclameren. De onderstaande figuur geeft aan waar de ex ante prestatie-informatie gebruikt wordt.
Figuur 7.1: Norminformatie en prestatieadministratie – een sluitend model
De drie specificaties bevatten alle gegevens over de eigenschappen van een dienst/interne leverantie en zijn relaties met de wet, met het betrokken bedrijfsproces en met de transactie-verwerkende en managementinformatiesystemen (financiële administratie, kostprijssysteem). In de planning en control cyclus vormen de ex ante metagegevens van diensten input voor kwantitatieve gegevens over planning en uitvoering. Voorts levert de dienstenportfolio metagegevens aan het data ware house (DWH). Elke specificatie wordt volgens een vast stramien (sjabloon) ingevuld. Ten einde de onderlinge samenhang te borgen en de stamgegevens maar één keer te hoeven vastleggen, vormen zij in opzet één sluitend model (zie figuur 18). Om de specificaties ook als zelfstandig document te kunnen lezen, wordt een aantal stamgegevens herhaald. In deze handleiding wordt het werken met de sjablonen voor de functionele specificatie, de telspecificatie en de normering toegelicht.
Functionele gegevens
1 Algemeen
In de functionele specificatie legt een organisatie de wettelijke eisen aan de dienstverlening meetbaar, extern zichtbaar vast met als doel een optimale dienstverlening aan cliënten. De functionele specificatie omvat de volgende stamgegevens en gegevensrubrieken:
- identiteitscode dienst, dienstgroep, versie, status, aanvang levering et cetera
- verkorte en volledige naam
- (finale) doelstelling en doelgroep
- korte omschrijving dienstverlening
- wettelijke basis
- wettelijke en interne kwaliteitsnorm betreffende rechtmatigheid, tijdigheid en specifieke cliëntgerichtheid
- teleenheid en -moment (functioneel) prestatiemeting
- specificatie van beoogd effect ten behoeve van effectindicator
- toelichting.
Onderstaand wordt per gegeven ingegaan op de betekenis en het waarom ervan.
2 Meta-informatie over dienst en functionele specificatie
Stamgegevens in de kop van dienst en specificatie
Elke dienst wordt beschreven met behulp van de stamgegevens in de onderstaande tabellen. De eerste tabel betreft de stamgegevens van de dienst. De tweede tabel de stamgegevens van de specificatie.
|
Naam |
|
||
| Verkorte naam | Doelgroep |
|
|
| Wet |
|
||
| Code | Dienstverlener |
|
|
| Ingangsdatum | Dienstgroep |
|
|
| Einddatum | Bedrijfsproces |
|
|
| Deeldienst(en) | Applicatie |
|
|
| Naam |
|
|||
|
|
Versie | Status | Wijzigingsdatum | Publicatiedatum |
Naam en verkorte naam
De volledige naam van een dienst valt nog wel eens lang uit. Een voorbeeld uit de sociale verzekering (sv): ‘Beslissing eerste beoordeling recht op ziekengeld werknemers zonder werkgever bij arbeids-ongeschiktheid wegens zwangerschap/bevalling of orgaandonatie en bevordering van hun re-integratie’. Voor het gemak hanteren gebruikers dan een verkorte naam. Ook de beschikbare ruimte voor een naam in een registratiesysteem is doorgaans beperkt.
Code
De code voorziet de dienst van een unieke identiteit. Wanneer een dienst wordt gesplitst, wanneer twee diensten worden samengevoegd en bij ingrijpende wijzigingen ten gevolge van wet- en regelgeving, worden nieuwe codes toegekend. Dit om, in de tijd gezien, vergelijken van capaciteit, kwaliteit en kostprijs zuiver te kunnen houden. De code van een dienst vormt ook de kern van de specificatiecodes. De dienst ao05 heeft in de dienstenportfolio de volgende specificatiecodes:
- s ao05 = de functionele specificatie
- n ao05 = normering
- r ao05 = registratie.
Ingangsdatum dienst
Het veld ‘ingangsdatum’ bevat de datum van de start van de levering. Doorgaans komt die overeen met de datum dat een wettelijke regeling van kracht is geworden. De ingangsdatum is een-op-een gekoppeld aan de code van een dienst.
Einddatum dienst
Het veld ‘einddatum’ wordt ingevuld als bekend is dat de dienstverlening wordt gestopt. Dat wil zeggen dat cliënten de dienst niet meer kunnen aanvragen. Veelal dient dan nog rekening te worden
gehouden met een uitloopperiode aangezien diensten in verschillende stadia van gereedheid kunnen voorkomen.
Deeldiensten
Het veld ‘deeldiensten’ bevat de codes van de deeldiensten en/of interne leveranties waaruit een dienst wordt samengesteld.
Doelgroep
Het veld ‘doelgroep’ bevat de naam van een cliënt- of afnemersgroep. Per cliëntgroep kan hier meer specifieke informatie worden vermeld.
Wet
Een organisatie kan een of meer wetten uitvoeren. Wanneer de wetgever de financiering per wet
geregeld heeft, worden kosten van diensten aan de betreffende wet toegerekend.
Dienstverlener (divisie/directoraat/primaire functie)
De keuzelijst in het veld ‘dienstverlener’ omvat alle dienstverleners binnen een uitvoeringsorganisatie. In het sjabloon zijn dit divisies en directoraten van de organisatie.
Dienstgroep
Een dienstenportfolio[1] bevat (specificaties van) diensten en interne leveranties. Deze kunnen vanuit verschillende gezichtspunten worden gebundeld tot groepen. Mogelijke groepen zijn:
- dienstverlener = dienstverlenende organisatie-eenheid
- doelstelling = uitkering, werk, handhaving, gegevensverstrekking et cetera
- wet = Ziektewet, Werkloosheidswet, Bijstandswet, Ouderdomswet et cetera
- doelgroep
- beïnvloedbaar door uitvoeringsorganisatie ßàextern bepaald.
In onze case-portfolio zijn de diensten primair gebundeld naar dienstverlener. De tweede ingang is gemengd van aard: naar doelstelling en wet. Het veld ‘dienstgroep’ laat de keuze uit de doelstellingen (functies):
- arbeidsbehoud
- arbeidstoeleiding
- claimafhandeling (gesplitst naar wet)
- informatieverzorging
- handhaving
- registratie
- premieverzorging.
Zie ook de paragrafen over doelstelling en effect.
Bedrijfsproces
Een dienst is steeds het eindresultaat van een bedrijfsproces. Met behulp van het gegeven in dit veld wordt de dienst gekoppeld aan een bedrijfsproces. De verantwoordelijke afdeling vult hier, zodra bekend, de naam en code van het bedrijfsproces in.
Applicatie
Een dienst wordt veelal automatisch geteld in de applicatie die het betreffende bedrijfsproces ondersteunt. In dit veld wordt de naam c.q. het acroniem van de applicatie vermeld.
Versienummer
Aanvullend ten opzichte van de paragraaf over de code van een dienst geldt dat bij geringe wijziging van een dienst de specificatie van een dienst wordt aangepast. De aangepaste specificatie wordt met een verhoogd versienummer in de portfolio opgenomen.
Status
Zoals in de procedurebeschrijving[2] is vermeld, kunnen specificaties verschillende stadia van autorisatie doorlopen. Over deze stadia worden afspraken gemaakt. Je kunt hierbij denken aan:
- concept 1: specificatie is in gebruik binnen afdeling beleid en productontwikkeling
- concept 2: specificatie is getoetst door management en financiële administratie
- definitief: specificatie is vastgesteld door directie
- vervallen: nieuwe aanvragen worden niet meer in behandeling genomen.
Specificaties worden gepubliceerd na vaststelling door de directie. Onder het tabblad ‘versiehistorie’ zijn, wanneer van toepassing, eerdere versie(s) van de specificatie opgenomen.
Wijzigingsdatum
De datum van de start van de levering volgens de gewijzigde versie. Deze datum is een-op-een
gekoppeld aan het versienummer van de functionele specificatie.
Publicatiedatum
De publicatiedatum is de datum waarop de specificatie op intranet wordt gepubliceerd. Vanaf die
datum geldt de specificatie als authentieke bron voor de uitvoering. Vanzelfsprekend is het voor een juiste en tijdige uitvoering van belang dat de publicatiedatum ruim vóór de ingangsdatum valt.
3 Informatie in de rubrieken van de specificatie
Naam specificatie
Dit veld geeft de naam van de specificatie die aan de dienst gekoppeld is. Het komt soms voor dat twee diensten één specificatie delen. In die gevallen kan de naam van de specificatie licht verschillen van die van de dienst.
Doel, doelgroep, beknopte omschrijving en wettelijke basis
Doel
Diensten zijn een middel om een (bijdrage aan een) verder liggend, maatschappelijk doel te realiseren. Om een antwoord te geven op de vraag ‘waartoe verlenen wij deze dienst?’ wordt in de specificatie de finale (maatschappelijke) doelstelling van de dienstverlening omschreven. Om, waar gewenst, het effect van de dienstverlening te kunnen meten, wordt dit in § 2.3.6 ‘Effectspecificatie’ meetbaar gespecificeerd.
Doelgroep
Aansluitend op de naam van de doelgroep in de kop van de specificatie, wordt zo veel mogelijk de doelgroep nader omschreven. De combinatie van doelgroep en dienstverlening is bepalend voor de dienst.
Omschrijving dienstverlening
Deze beknopte omschrijving geeft het ‘wat’ en ‘hoe’ weer. Wat wordt er aan de cliënt geleverd en hoe komt het binnen een uitvoeringsorganisatie tot stand.
Wettelijke basis
In aansluiting op de wetscode in de kop van de specificatie wordt hier de wettelijke basis nader toegelicht. De toelichting omvat de wetsartikelen (van materiewet en aanpalende wet- en regelgeving) die de legitimatie vormen voor de dienstverlening aan de doelgroep. Wanneer de wetgever aan een uitvoeringsorganisatie een discretionaire bevoegdheid laat, wordt een verwijzing naar het vastgelegde beleid opgenomen.
Kwaliteit
Deze rubriek bevat de kwaliteitsnorm waaraan de dienst (finale externe overdracht aan de cliënt) dient te voldoen. De norm wordt meetbaar en controleerbaar gespecificeerd. De wetgever onderscheidt kwaliteit in juistheid (rechtmatigheid), tijdigheid en overige kwaliteit.
De in deze rubriek opgenomen kwaliteitseisen zijn ‘functioneel’ gespecificeerd. De verdere detaillering hiervan tot op meet- en regelniveau vindt plaats in de telspecificatie: zie hoofdstuk 3.
Juistheid
Wanneer van toepassing wordt hier een verwijzing naar de geldende wettelijke rechtmatigheidseis opgenomen. Dit soort eisen ligt vaak vast in bijvoorbeeld ministeriële regelingen. Ook worden eisen gespecificeerd die materiewetten stellen aan overdrachten aan cliënten. Zie voor voorbeelden de specificaties in de casestudy.
Tijdigheid
Hier worden de tijdigheidseisen opgenomen volgens de beslis- en verdaagtermijnen in materiewetten en Algemene Wet Bestuursrecht (AWB). Een functioneel telmoment is doorgaans ontleend aan een in de wet genoemde beslistermijn. Een uitvoeringsorganisatie kan, met het oog op interne sturing en kwaliteit dienstverlening, binnen wettelijke termijnen, eigen telmomenten kiezen. Functionele telmomenten zijn doorgaans de ontvangstdatum van een aanvraag en de verzenddatum van een beslissing. De wetgever heeft voor een groot aantal diensten (op aanvraag) in de wet een uiterlijke verleningstermijn vastgelegd.
De ontvangst- en verzenddatum bepalen de doorlooptijd tussen het moment van ontvangst van de aanvraag van de cliënt en finale overdracht van de dienst aan de cliënt.
Zodra een uitvoeringsorgaan een aanvraag om dienstverlening ontvangt, is zij verantwoordelijk voor een juiste en tijdige afhandeling. Met de externe overdracht van de dienst stopt de verantwoordelijkheid van een uitvoeringsorgaan. Als aan een aanvraag noodzakelijke gegevens ontbreken, kan voor het completeren van de aanvraag extra tijd gerekend worden.
Overige kwaliteit
De overige aan een dienst gestelde kwaliteitseisen betreffen doorgaans de inhoud en periodiciteit van de informatievoorziening aan de cliënt. Voorts kunnen specifieke vaardighedeneisen voor behandelaars worden vastgelegd (persoonscertificering). Bijvoorbeeld: het nemen van een beslissing over ziekte vereist de inzet van een verzekeringsarts. Kwaliteitseisen die meer overkoepelend gelden voor alle diensten, zoals hoe cliënten op kantoor worden ontvangen, worden apart gespecificeerd in het overkoepelende dienstverleningsbeleid[3].
In aanvulling op de wettelijke kan een uitvoeringsorganisatie eigen kwaliteitseisen stellen. Deze worden afzonderlijk vastgelegd. Zie ook de bespreking van het begrip ‘kwaliteit’ in de begrippenlijst.
Telcriterium
Het telcriterium omvat de gekozen teleenheid en het telmoment. De teleenheid bepaalt de output (prestatie) en het telmoment de tijdigheid. Inherent aan het uitgangspunt van outputsturing geldt dat finale externe overdrachten aan de cliënt geteld worden als prestaties. Het telmoment is zo veel mogelijk het moment dat er daadwerkelijk geleverd wordt. Alleen wanneer het pertinent niet mogelijk is om finale diensten te tellen, kan een teller en telmoment gekozen worden die vóór het einde van de logistieke procesgang ligt. Het dienstenmodel hanteert als uitgangspunt ‘outputsturing’:
- om beter aan de wensen van de cliënt te kunnen voldoen
- om beter de relatie te kunnen leggen tussen de geleverde prestatie en het beoogde effect
- om een eindpunt te markeren van de logistieke procesgang
- ter legitimatie van de gemaakte kosten (audit trail).
Met de finale externe overdracht aan de cliënt wordt de dienstverlening afgesloten en is de tijdigheid bepaald.
Wanneer bij invoering van ouputsturing in een going concern situatie al bestaande productie- en registratiesystemen worden gehandhaafd, ontkomen we er niet aan vooralsnog voor een aantal teleenheden en -data de best passende eenheden en data in de systemen te kiezen. Deze meta-informatie wordt vastgelegd in de telspecificatie. Zie hieronder bij 3.
Een tweede aandachtspunt is het verschil tussen output- en statistische informatie. De definities van statistische grootheden en prestatiegrootheden zijn veelal los van elkaar en met een verschillend doel tot stand gekomen. Voor analyse is het van belang bij het detailleren van functionele telcriteria de verschillen in meetmomenten en meetperiodes in het oog te houden.
Effectspecificatie
Zoals onder het kopje ‘doelstelling’ opgemerkt, is het leveren van een dienst een middel om een doel (ook wel resultaat of effect genoemd) te bereiken. Om te kunnen vaststellen of de inspanningen van een uitvoeringsorganisatie effectief zijn, is het nodig het beoogde effect meetbaar te specificeren en vervolgens te meten of het zich voordoet.
Wetenschappelijk aantonen dat een opgetreden effect het resultaat is van een bepaalde actie van een uitvoeringsorganisatie is een weerbarstige materie en gelukkig is dit bij lang niet alle diensten aan de orde. Zo mag een uitvoeringsorganisatie aannemen dat cliënten met een rechtmatige uitkering in hun levensonderhoud kunnen voorzien. Bij dergelijke diensten kan worden volstaan met het opnemen van de standaardzin: ‘Daar het beoogde effect is gerealiseerd als de onderhavige dienst volgens de specificatie geleverd is, is nadere effectspecificatie niet van toepassing’.
Onder andere bij re-integratie- en handhavingsdiensten speelt de effectiviteitsvraag wel een belangrijke rol.
Toelichting
Deze rubriek blijft bij voorkeur leeg. De tekst in de voorgaande rubrieken dient voor zichzelf te spreken. Informatie die niet in een van de andere rubrieken lijkt te passen, kan zolang even worden ondergebracht in de toelichting. De bedoeling is dat vóór definitieve vaststelling van de specificatie een plek in een van de rubrieken is gevonden.
[1] Doorgaans een op intranet en/of internet te raadplegen digitale portfolio.
[2] De procedurebeschrijving is als bijlage 4 aan het hoofddocument toegevoegd.
[3] Een voorbeeld van overkoepelend dienstverleningsbeleid is als bijlage 5 aan het hoofddocument toegevoegd.
Registratiegegevens
1 Algemeen
De sjabloon met de registratiegegevens - ook wel technische of telspecificatie genoemd - vertaalt de grootheden uit de functionele specificatie in systeemtechnische termen. De telspecificatie toont in welke registratiesysteem c.q. -systemen diensten en de samenstellende delen gedateerd, geregis-treerd, geteld en gecategoriseerd worden. De registratiespecificatie omvat een kop met een aantal stamgegevens en voorts een aantal gegevensrubrieken.
2 Stamgegevens
In de intranetportfolio is steeds de koptabel met de stamgegevens van de betreffende dienst zichtbaar. Deze hoeven dus niet herhaald te worden in de registratiespecificatie. In de kop van de
registratiespecificatie worden aanvullend de navolgende stamgegevens vastgelegd:
Tabel 3: Registratie
| Dienstcode | Verkorte naam | Versienummer | Wijzigingsdatum |
Dienstcode en verkorte naam
Door in de registratiespecificatie de dienstcode te vermelden, is deze gekoppeld aan een dienst. De verkorte naam zorgt voor de herkenbaarheid.
Versienummer en wijzigingsdatum
De registratiespecificatie krijgt bij systeemwijzigingen van invloed op de registratie een nieuw versienummer. De wijzigingsdatum is de datum dat er volgens de gewijzigde registratie geteld wordt.
3 Rubrieken
Met de volgende metagegevens, onder meer over de wijze van registreren, worden de onderstaande rubrieken gevuld:
- functioneel
- definitie invoer
- teleenheid
- telmoment
- telsoort
- soort verrekening
- technisch
- registratie in
- definitie invoer
- teleenheid
- telmoment
- toelichting.
De nummers in de opsomming verwijzen naar toelichtende paragrafen.
De rubrieken ‘teleenheid en ‘telmoment’ komen ook voor in de functionele specificatie. De daar opgenomen formuleringen zijn gebaseerd op wet- en regelgeving. In de registratiespecificatie worden deze functionele eisen, ter wille van de zelfstandige leesbaarheid, herhaald in het functionele
gedeelte en in het technische deel vertaald in systeemspecifieke codes en handelingen.
Wanneer functionele eisen niet een-op-een omgezet kunnen worden, wordt dit in de registratie-
specificatie toegelicht. Zo veel mogelijk wordt toegelicht hoe de afwijking doorwerkt in de op te leveren stuur- en verantwoordingsinformatie.
De opdeling van de telspecificatie in een functioneel en technisch deel maakt het mogelijk (chronologisch) een dienst in meer systemen te tellen. Het technische deel wordt dan per systeem herhaald.
Definitie invoer functioneel
De rubriek ‘definitie invoer’ omvat een specificatie van eisen waaraan voldaan moet zijn om een dienst rechtmatig te tellen. In de regel is de beschikbaarheid van een functionele specificatie van de dienst vereist. Voorts vereist telling de aanwezigheid in het dossier van één of meer vastleggingen. Doorgaans zal er een aanvraag in het dossier aanwezig zijn.
Teleenheid functioneel
De functionele teleenheid is gedefinieerd in de functionele specificatie en wordt afgeleid uit wet- en regelgeving. Doorgaans zal de functionele teleenheid (ook wel: telcriterium) een verzonden beslissing op aanvraag, oordeel et cetera zijn.
Regel is dat de omschrijving van de functionele teleenheid in de registratiespecificatie identiek is aan die in de functionele specificatie en dat de technische teleenheid in het systeem specifiek hierop is afgestemd.
Wanneer wordt afgeweken van de (wettelijke) functionele teleenheid, wordt dit toegelicht.
De toelichting omvat de reden van de afwijking en ook de doorwerking op stuur- en verantwoordingsinformatie.
Definitie telmoment functioneel
Een functioneel telmoment is doorgaans ontleend aan een in de wet genoemde beslistermijn. Een uitvoeringsorganisatie kan, met het oog op interne sturing en kwaliteit dienstverlening, binnen wettelijke termijnen, eigen telmomenten kiezen.
Functionele telmomenten zijn doorgaans de ontvangstdatum van een aanvraag en de verzenddatum van een beslissing.
Telsoort
De rubriek ‘telsoort’ geeft aan of een dienst handmatig, automatisch of op beide manieren geteld wordt. Handmatig tellen komt voor wanneer het een beperkt aantal diensten per periode betreft of wanneer een proces nog niet geautomatiseerd ondersteund wordt.
Beide kunnen voorkomen per dienst wanneer bijvoorbeeld de bulk van de diensten wordt verleend op een locatie waar systeemondersteuning is en deze dienst sporadisch ook op andere locaties wordt verleend. De aantallen van de laatstgenoemde locaties worden dan handmatig in het systeem
ingevoerd.
Verrekening
In de rubriek ‘verrekening’ vermelden we de wijze van verrekening. Bij een dienst of een deeldienst zal er doorgaans sprake zijn van een externe verrekening, bij een interne leverantie doorgaans van een interne verrekening. Een deeldienst kan, afhankelijk van de afnemers, zowel intern als extern verrekend worden. Zo kan de deeldienst ‘medisch oordeel’ verrekend worden met een externe
afnemer en ook tussen divisies van een uitvoeringsorganisatie. Ook kunnen er interne leveranties en diensten ‘om niet’ zijn.
Registratie in
De rubriek ‘registratie in’ geeft aan in welk systeem (administratie) een dienst, een deeldienst of een interne leverantie geteld wordt. Wanneer één dienst in twee of meer systemen (deeladministraties) geteld wordt, worden twee of meer systemen vermeld.
Definitie invoer
Een eerder ingegeven systeemwaarde kan vereist zijn om de dienst te kunnen tellen.
Teleenheid technisch
De technische teleenheid is doorgaans een ‘code’ in een ondersteunend registratiesysteem. Bijvoorbeeld de code van de laatste handeling in een proces: verzenden beslissing aan cliënt. Door het
ingeven van de code wordt een teller ‘verzonden beslissingen’ met 1 opgehoogd.
Wanneer een systeem geen systeemcode kent die gereserveerd is voor de functionele teleenheid, dient deze bij een eerstvolgende release te worden toegevoegd. In afwachting daarvan is het van
belang een systeemcode te nemen die de functionele teleenheid zo veel mogelijk benadert. Een voorbeeld: wanneer het systeem geen code ‘verzenden beslissing’ heeft, kan de code ‘bruto-uitkering vastgesteld’ genomen worden. Zoals gezegd is het wel van belang rekening te houden met eventuele vertekening van het aantal ‘verzonden beslissingen’ in de periode. Vooral wanneer er enige tijd overheen gaat voor van de vastgestelde uitkeringen de beslissingen worden verzonden.
Wanneer één dienst (functionele teleenheid) voorkomt in twee of meer systemen, wordt per systeem de bovenstaande technische informatie in de registratiespecificatie opgenomen.
Telmoment technisch
Evenals bij de teleenheid is de regel dat de omschrijving van het functionele telmoment in de
registratiespecificatie identiek is aan die in de functionele specificatie en dat het technische telmoment in het systeem specifiek voor dit doel is opgenomen.
Wanneer een systeem het functionele telmoment, bijvoorbeeld ‘datum verzending’, niet kent, is het vastleggen van een verzenddatum niet mogelijk. In die gevallen is het van belang, in afwachting van de aanpassing van het systeem, per beslissing de in de tijd gezien naastliggende (systeem)datum die wel wordt geregistreerd te nemen.
Wanneer wordt afgeweken van het (wettelijke) functionele telmoment, wordt dit toegelicht.
De toelichting omvat de reden van de afwijking en ook de doorwerking op stuur- en verantwoordingsinformatie.
Wanneer in een registratiesysteem de doorlooptijden niet met behulp van systeemdata maar via handmatig ingebrachte ontvangst- en verzenddata worden bijgehouden, kan dit tot vertekening leiden. Wanneer bij een dienst de doorlooptijden korter zijn dan de standaardverwerkingstijden, gaat er wellicht iets fout bij de handmatige invoer. Wanneer een dienst (functioneel telmoment) in meer dan één systeem wordt geteld, wordt de bovenstaande technische informatie per systeem in de
registratiespecificatie opgenomen.
Toelichting
In de toelichting kunnen alle dienstige verduidelijkingen opgenomen worden. Het verdient de voorkeur de rubrieken voor zichzelf te laten spreken, zodat de toelichting achterwege kan blijven of minimaal kan zijn.
Normering
1 Algemeen
Het dienstenmodel hanteert voor de primaire dienstverleningsprocessen een mengvorm van activiteits- en prestatienormering. Deze mengvorm omvat:
- diensten gedefinieerd als finale externe overdrachten aan cliënten waarvan kwaliteit en kwantiteit gemeten kunnen worden
- per dienst een normblad waarin zijn vastgelegd:
- de voor de dienst te verrichten (clusters van) activiteiten
- de frequenties waarmee deze activiteiten benodigd zijn
- de type functies die de activiteiten verrichten
- de normbewerkingstijd per activiteit en per functionaris.
Doelstelling van de normering van bewerkingstijden is:
- het aantal fte’s voor een efficiënte procesinrichting (het normproces) bepalen voor het ramen van de benodigde capaciteitsinzet
- het vullen van een uitvoeringsmodel voor het doorrekenen van de gevolgen van wetswijzigingen ten behoeve van uitvoeringsadviezen aan de minister en aanpassing van processen en systemen
- het bieden van een referentiekader voor de begrotingen per regio. De normen geven de relatie tussen de fte-begrotingen van de regio’s en de voorcalculatorische kostprijzen van de diensten
- invoer voor (een abc-methodiek voor) een voorcalculatorische kostprijsbepaling
- informatie voor productieplanning en -begroting, sturing en evaluatie.
In het dienstenmodel heeft elke dienst een normblad (bijlage 3) voor de benodigde direct productieve verwerkingstijd, uitgesplitst naar de uitvoerende functies. Het gaat hierbij om alle primaire activiteiten die gericht zijn op het verlenen van diensten en die min of meer evenredig met het productievolume toe- of afnemen.
2 Opbouw normblad
In de kop van het normblad vinden we gegevens over:
- dienstcode en verkorte naam dienst
- naam (en code) bedrijfsproces
- versienummer en ingangsdatum normblad
- status autorisatie en einddatum normblad.
Het normblad omvat verder kolommen met daarin gegevens over:
- de activiteiten, op processtap- en/of werkprocesniveau, die nodig zijn om de dienst aan de cliënt te kunnen verlenen
- de uitkomsten van deze interne activiteiten in de vorm van deeldiensten en/of interne leveranties
- de frequentie waarmee activiteiten in verhouding tot het aantal diensten benodigd zijn. Voor een deel van de diensten is het doorlopen van een compleet proces niet vereist
- de functionarissen (arts, jurist, arbeidsdeskundige et cetera) benodigd om de activiteiten uit te voeren
- de standaardverwerkingstijd per activiteit in minuten, gekoppeld aan functionarissen.
Een gevuld normblad resulteert in een overzicht van de gemiddeld benodigde verwerkingscapaciteit per activiteit en per functionaliteit voor het verlenen van een dienst onder normale omstandigheden.
Onder normale omstandigheden is er sprake van een verwerkingsproces met:
- goed opgeleide, ingewerkte medewerkers
- een normaal werkaanbod
- een ingevoerd normproces.
De gemiddeld benodigde verwerkingstijd vermenigvuldigd met het aantal diensten dat in een periode verleend zal worden, levert de benodigde direct productieve bezetting op.
De globaal beschreven processtappen in de normering bij de diensten (en de meer gedetailleerde
beschrijvingen van werkprocessen) geven de activiteiten in het normproces weer.
Wanneer van functionarissen minuuttarieven bekend zijn en normtijden per (cluster van) handeling(en) zijn vastgesteld, kunnen de directe productiekosten worden berekend. Indirecte kosten worden zo veel mogelijk activity-based toegerekend aan de diensten. Wanneer dit niet mogelijk is, in
ieder geval zoveel mogelijk sleutels hanteren die de causale relaties tussen diensten en kosten
‘schaduwen’. De algemene kosten (overhead) worden in de vorm van een opslag toegerekend aan de diensten. Wijzigingen in het bedrijfsproces en/of de functiestructuur werken door in het normeringsblad.
Sjablonen
1 Sjabloon functioneel specificatieblad
| Naam | |||
| Verkorte naam | Dienstgroep | ||
| Code | Divisie/Directoraat | ||
| Ingangsdatum | Doelgroep | ||
| Einddatum | Bedrijfsproces | ||
| Deeldienst(en) | Applicatie | ||
| Versie | Status | Ingangsdatum | Publicatiedatum | Voorgaande versies | |
| Specificatie | |||||
| Normering | |||||
| Registratie |
| Naam van de specificatie |
1. Doelstelling, beknopte beschrijving en wettelijke basis
Doelstelling
Doelgroep
Beknopte beschrijving
1.4 Wettelijke basis
2. Kwaliteit
2.1 Juistheid
2.2 Tijdigheid
2.3 Overig (o.a. relationeel)
3. Telcriterium
3.1 Teleenheid
3.2 Telmoment
4. Effectspecificatie
5. Toelichting
2 Sjabloon registratieblad
| Dienstcode | Verkorte naam | ||
| Versienummer | Ingangsdatum |
1. Functioneel
1.1 Definitie invoer
1.2 Teleenheid
1.3 Telmoment
1.4 Telsoort
1.5 Soort verrekening
2. Technisch
2.1 Registratie in
2.2 Definitie invoer
2.3 Teleenheid
2.4 Telmoment
3. Toelichting
3 Sjabloon normeringsblad
Procedure
1 Inleiding
Deze (voorbeeld)procedure heeft tot doel de effectiviteit en efficiëntie van de samenwerking bij de ontwikkeling en het beheer van diensten en het normeren en het registreren ervan te ondersteunen.
De procedure is globaal beschreven. Zodra een organisatie de ontwikkeling van diensten een plaats heeft gegeven, kan die nader worden uitgewerkt aan de hand van de feitelijke taakverdeling en verantwoordelijkheidsstructuur. De procedure geldt voor zowel ontwikkeling van dienstverlening binnen de bestaande organisatie als projectmatige ontwikkeling. Voorkomen dient te worden dat onder tijdsdruk of door inhuur van externen ongewild afwijkende werkwijzen worden geïntroduceerd. Wanneer de ontwikkeling van diensten als project wordt ingericht, is het van groot belang dat kennisoverdracht naar de organisatie plaatsvindt. De functiescheiding die uit de onderstaande procedure naar voren komt, zorgt voor elkaar controlerende krachten gericht op kwaliteits- en kostenbeheersing. Aparte eenheden vertalen wet- en regelgeving in specificaties, ramen en normeren, en analyseren budgetrisico’s en geven (wanneer van toepassing) integrale kostprijzen af. Voor het up to date houden van een dienstenportfolio hanteren we een drieledige procedure:
- de initiële ontwikkeling van nieuwe diensten op basis van nieuwe of gewijzigde wetgeving
- het periodiek wijzigen/onderhouden van bestaande diensten
- het aanleveren van de meta-informatie in de afgesproken sjablonen.
De laatstgenoemde procedure is gedetailleerd en sterk afhankelijk van de feitelijke informatie- en communicatietechnologie. Deze werken we daarom niet uit. Gegeven de fiscale en administratief-technische complicaties waarmee wijzigingen in financiële dienstverlening gedurende het jaar gepaard kunnen gaan, verdient het de voorkeur nieuwe (financiële) diensten met ingang van het kalenderjaar in te voeren. Wanneer wijzigingen gedurende het jaar effectief worden, worden ze op projectbasis geadministreerd en in het jaar daaropvolgend in de reguliere administratie opgenomen.
2 Van ‘korrel tot borrel’
Figuur 7.2 geeft het ontwikkeltraject weer van ‘idee wetgever’[1] tot uitvoering. Met andere woorden: van ‘korrel tot borrel’. De ontwikkeling van een idee voor een wet tot de uitvoering ervan omvat ruwweg de volgende activiteiten:
- afstemming op strategisch niveau (informeel) over prille ideeën voor nieuwe of te wijzigen wetgeving. Binnen de uitvoeringsorganisatie vindt een globale verkenning van gevolgen plaats
- advisering over beleidsmatige en uitvoeringstechnische gevolgen
- vertaling wet naar uitvoeringsbeleid, diensten, functionele specificaties, normering, bepaling financiële gevolgen, ontwikkeling c.q. aanpassing processen voor uitvoering gespecificeerde diensten en ontwikkeling c.q. aanpassing procesondersteunende en informatiesystemen
- uitvoering en evaluatie.
Figuur 7.2: Ontwikkeltraject
Voor de stappen 2 en 3 in het traject geldt voor de uitvoering intern de procedure zoals hieronder in 3 is beschreven.
3 Ontwikkeling, onderhoud en beheer van diensten
Naast de ontwikkeling van nieuwe worden bestaande diensten ook aangepast aan wijzigingen in de uitvoeringspraktijk, kleinere wijzigingen in wetgeving en technologische ontwikkeling. De bulk van deze activiteiten wordt zo gepland dat de kwantitatieve en financiële gevolgen zo veel mogelijk meelopen in de begrotingscyclus. Figuur 20 geeft beknopt een mogelijk procedure weer, bestaande uit een aantal stappen. Bij elke stap zijn één of meer stafeenheden actief. De opsomming geeft de activiteiten achtereenvolgend weer. Ze vinden echter zo veel mogelijk parallel en dakpansgewijs plaats (iteratief). Naarmate het ontwikkeltraject vordert, neemt de hoeveelheid voor de uitvoering relevante informatie toe. Zo veel mogelijk samenwerking en kennisoverdracht tussen personen die achtereenvolgens aan het traject deelnemen versnelt het ontwikkeltraject en vermindert de inspanningen.
In stap 1 verkennen een eenheid strategie en een eenheid dienstverleningsbeleid (DVB) samen de gevolgen van nieuwe of aangepaste wetgeving voor de uitvoering. In deze fase wordt bezien of de wetgeving tot onoverkomelijke uitvoeringsproblemen kan leiden. Ook wordt met de wetgever besproken welke effecten met de wetgeving beoogd worden, in hoeverre de dienstverlening daartoe bijdraagt en hoe de wetgever effecten gaat beoordelen. Het autorisatiemoment na stap 1 richt zich op de vraag of er voldoende bekend is over inhoud dienstverlening en financiering om de uitvoering verder voor te bereiden (groen licht). Ook de relatie tussen te realiseren effecten en de financiering kan een beslispunt zijn.
In stap 2 werkt de eenheid DVB, op basis van de beschikbare informatie over een wetsontwerp, een programma van eisen voor de dienstverlening uit. De eisen waaraan de diensten voldoen, leidt DVB af uit wet- en regelgeving, het perspectief van de cliënt, het eigen dienstverleningsbeleid en de mogelijkheden van de bestaande processen en systemen. De gevolgen voor de uitvoering worden vastgelegd in een advies aan de wetgever (ook wel: uitvoeringstoets).
In stap 3a legt een eenheid DVB in samenwerking met deskundigen uit de praktijk de eisen voor de uitvoering (meta-informatie) vast in specificaties volgens het dienstenmodel. De gegevens over een dienst worden vastgelegd in een functionele specificatie en een normblad[2]. Voor elke specificatie is een sjabloon en een invulinstructie beschikbaar (zie bijlage 3 ‘Sjablonen dienstenmodel).
Bij de uitwerking van de specificaties stemt de eenheid DVB af met een eenheid planning, control en kwaliteit (PCK) over de doorwerking op de raming van de aantallen, de kosten en de kwaliteitsmeting (3b). Voorts met een eenheid financiële administratie over de (integrale[3]) kostprijs, gevolgen voor begroting en budgetrisico’s (3e). De specificaties vormen input voor eenheden werkvoorbereiding en communicatie die werkinstructies, opleidingen resp. folders, brievenboek en website aanpassen (3c). Ook gaan de specificaties naar een eenheid proces en systeembeheer (PSB). Zij werken de impact van de veranderingen op processen en systemen uit. PSB stelt op basis van de functionele specificaties ‘telspecificaties’[4] op of past bestaande aan.
Het autorisatiemoment na stap 3 omvat vooral de in te zetten kwaliteit en kwantiteit aan menscapaciteit en de kosten van de verandering in de processen en systemen. Na de autorisatie van de financiële consequenties van de voorgenomen dienstverlening en de (wijzigingen in) stuur- en verantwoordingsinformatie kunnen de noodzakelijke aanpassingen in processen en systeem worden aangebracht. Tegelijkertijd worden systeemaanpassingen ten behoeve van registreren, tellen en declareren van diensten en interne leveranties verwerkt.
In stap 4 wordt de productieplanning en de begroting aangepast. Voorts biedt DVB de definitieve specificaties aan een eenheid portfoliobeheer aan ter publicatie in de dienstenportfolio op intranet. Deze eenheid checkt onder andere consistente codering, de inpassing in het bestaande assortiment en een juiste toepassing van principes en modellen van het dienstenmodel. DVB verwerkt eventuele commentaren van PB en stuurt, na vaststelling door de directie, de definitieve specificaties aan AB voor publicatie in de intranetportfolio.
In stap 5 wordt de (aanpassing van de) dienstverlening aan de hand van de realisatie geëvalueerd.
Figuur 7.3: Intern ontwikkeltraject diensten
[1] Wanneer ideeën van de wetgever onvoldoende of niet voortvloeien uit ontwikkelingen in de maatschappij, bestaat het risico dat bij de uitvoering aanpassingen doorgevoerd worden die niet toekomstvast zijn. Het
management heeft tot taak de uitvoering af te schermen van de ‘waan van de dag’-initiatieven in de politiek.
[2] Over diensten kunnen, los van het dienstenmodel, één of meer indicatorspecificaties worden opgesteld. Deze specificaties geven aan wat gemeten dient te worden om periodiek kengetallen over de cumulatieve dienstverlening te kunnen samenstellen. Indicatorspecificaties worden wel los van de dienstenspecificaties opgenomen in een handboek ‘kengetallen’.
[3] De afdeling PCK richt zich meer op de inhoud van de dienstverlening en de eigen kosten van de primaire afdelingen. De financiële afdeling beschikt over organisatiebrede kostencijfers en rekent indirecte kosten en overhead toe.
[4] Telspecificaties of registratiebladen geven aan hoe de benodigde gegevens over diensten in systemen worden geregistreerd.
