NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER
Digital Display heeft een gratis te downloaden whitepaper gepubliceerd onder de titel: Zaakgewijs werken: Opvattingen en Misvattingen.
Inhoudsomschrijving
Zaakgewijs werken (of zoals u wilt zaakgericht werken: wij zien geen verschil in betekenis) is populair, vooral door het simpele principe ervan, namelijk dat alle werkzaamheden van de organisatie worden opgehangen aan ‘de zaak’. De invoering is vaak weerbarstiger en zijn er nogal wat onderwerpen waarvoor een nader te maken keuze nodig is. Dit whitepaper biedt een samenvatting van veel gehoorde discussies, dilemma’s en misvattingen. Ben de Jong, werkzaam als adviseur bij Digital display, onderdeel van de Digital groep, schetst zijn opvattingen en geeft advies.
Inhoudsopgave
A. Wat wil de burger: dienstverlening en/of een efficiënte organisatie?
Tags:
Hier moet ik natuurlijk op reageren! Het is denk ik een bijzondere 'whitepaper' waarbij nog steeds erg veel ruimte is voor discussie. Ik geloof ook niet dat je dit kan voorkomen. Eén ding is zeker, het is goede informatie en een schitterende bron voor discussies. Mijn reacties:
Intro
- Zaakgericht werken kan ook analoog, maar voordeel behaal je pas bij digitaal
- Een zaak hoeft niet persé te beginnen met een document. Een zaak kan ook documentloos behandeld worden of pas tijdens het proces een document krijgen (vb. interne zaak "beamer reserveren" heeft geen document nodig).
A - grotendeels wel mee eens, alhoewel ik sommige zinnen niet helemaal kan volgen.
B - Volledig eens met de stelling van DD. Ik denk alleen niet dat de stelling van DD overeenkomt met het advies van KING.
C - Eens, dit is de ultieme optimale vorm van ZgW. Elke organisatie moet echter denk ik zelf bepalen waar de toegevoegde waarde ligt en of dit de investering waard is.
D - Ik zie nog steeds niet de toegevoegde waarde van ZgW bij een beleidsproces. Wellicht dat de uniformiteit die je creëert over alle processen een toegevoegde waarde heeft, maar ik blijf het gezocht vinden. Misschien als alle andere processen optimaal zaakgericht zijn ingericht kan je er als organisatie eens naar gaan kijken.
E - Volledig eens, Zaaksysteem, DMS en zelf KCS bij voorkeur zoveel mogelijk één systeem. De term zakenmagazijn is dan niet eens meer relevant. De term KCS lijkt überhaupt een commercieel idee, want vaak is dit niet veel meer dan een portal met een view op het zaaksysteem/magazijn, de PDC, FAQ, etc.
F - Koppelen of kloppelen? Per situatie kijken wat handig is, bij veelvuldig gebruik waarschijnlijk een koppeling, vaker veel goedkoper om met de hand te doen. Klein businesscaseje maken per systeem geeft helderheid.
G - Ik denk dat de investeringen rondom een los zaaksysteem en DMS vele male hoger zijn dan het direct uitfaseren van het huidige DMS. Dus zelfs als tijdelijke situatie onwenselijk en erg duur.
H en I - Voorkeur om zoveel mogelijk metadata vast te leggen op zaakniveau. Optimaal zou zijn als metadata die automatisch toegekend kan worden wel standaard op documentniveau onderwater wordt vastgelegd. Dit in combinatie met de mogelijkheid van full-tekst search moet alle informatie in context terugvindbaar maken.
J - Ik zie geen toegevoegde waarde om DIV alle zaken te laten starten. Een medewerker kan zelf prima bepalen dat er een nieuw proces / zaak gestart moet worden. Ik denk zelfs dat het irritant is als de medewerker hiervoor elke keer naar DIV moeten (zie hoe vaak nu een U-nummer voor uitgaande brieven niet wordt gevraagd bij DIV).
Daarnaast vind ik het niet logisch dat DIV nog als aparte identiteit wordt gezien voor het postkanaal. Het KCC is verantwoordelijk voor elk klantcontact; balie, telefoon, web en dus ook post. De benodigde kennis is namelijk m.i. voor elke kanaal nagenoeg hetzelde , waardoor een functiescheiding niet efficient is.
K - Afhankelijk van proces en doorlooptijd van de zaak.
L - Eens, BAC als aanvullende metadata automatisch vanuit de ZTC? Moet je doen als je dat prettig vindt.
M - Eens, hoe heftig ook, weerstand en tegengas komt er toch wel, met een Big Bang is dit slechts eenmalig!
Marco ik kan het ook niet later om een reactie te plaatsen. Enkele items verdienen extra aandacht.
E. Zaaksysteem/DMS/JKCS zie ik bij voorkeur als eensysteem. Zelf spreek ik ldan van een Zaakinformatiesysteem. Met de invoering van een ZIS bezit ik geen DMS. Een document in welke vorm dan ook (sms, voicebericht, brief, webformulier ..... etc) is altijd gekoppeld aan een zaak. Zoals Sven dat stelt een zaak kan ook uitsluitend bestaan uit een zaakomschrijving, Bij voorkeur zie ik het KCS volledig geintegreerd in het ZIS. Bij voorkeur van dezelfde leverancier. Dit laatste voorkomt ook een hoofdpijndossier koppelin g KCS.
Architectonisch zie je wel twee gescheiden onderdelen DMS en Zaaksysteem. ICT wil uit beheersoogpunt die nog wel eens los kunnen koppelen. Bezit onvoldoende kennis over nut en noodzaak van dit laatste.
J. De huidige positie van DIV bij de zaakregistratie zal verdwijnen en zal worden overgenomen door de frontoffice. Mijn verwachting is dat de hoeveelheid analoge post binnen 10 jaar sterk is verminderd mits het E-loket zich doorontwikkeld. De registratie vanuit het e-loket zal nagenoeg in zijn geheel door de techniek worden uitgevoerd, Eventeueel met controle. De frontoffice zal de overgebleven binnenkomende zaken direct registreren. DIV zal op termijn niet meer bestaan in de huidige vorm. Mijn vraag is dan in hoeverre de backoffice nog een binnengekomen zaak moet kunnen registreren. waarschijnlijk afhankelijk van de organisatie frontoffice/backoffice. De opmerking van Sven: DIV registratienummers verstrekt voor uitgaande brieven, bestaat toch niet meer? Mijn gedachten is dat een gebruiker zo veel mogelijk zelfstandig moet kunnen werken. Dus incl. registratie van zaken. Het nieuwe werken is anders ook niet mogelijk. Nieuw DIV zal uitsluitend nog, indien noodzakelijk een controlerende en beheers functie bezitten.
L. Het toevoegen van de BAC bezit geen toegevoegde waarde. De gebruiker kent de BAC niet en zal ook nimmer op de BAC zoeken. De Div medewerker zoekt digitaal ook niet meer op de BAC code. Is de BAC ook niet opgesteld voor de ordening van de analoge dossiers. Het toekennen van voldoende metadata is essentieel voor het terugvinden. Ons zaaksysteem bezit niet eens een veld voor de BAC, wel de dossiers. Voor een digitale zaak vorm je ook geen dossier meer. De gebruiker zoekt altijd op zaakniveau.
De kwaliteit van de zaakomschrijving is wat mij betreft nog steeds een onderwerp die onvoldoende aandacht krijgt.
Interessante discussiepunten die bij mij toch ook enige verbazing oproept.
Naar mijn gevoel kan je die twee moeilijk scheiden. Een slechte dienstverlening kan voor de burger moeilijk als een effectieve organisatie worden beleefd.
C. Welk begrip: Zaakgewijs werken of digitaal werken of..?
Volgens mij staan deze begrippen los van elkaar. Zaaksgewijs werken is niets anders een methode van procesafhandeling. Qua workflow kan je dat digitaal met zowel analoge als digitale documenten.
D. Dienstverlening gericht op ‘producten’ of op alle processen?
Dienstverlening ten aanzien van de burger neem ik aan? Die wil volgens mij alleen maar zijn vergunning, subsidie, whatever. Die zal het een zorg zijn of je het werkproces dat je daarvoor moet doorlopen definieert als een product of proces.
E. Zakenmagazijn of leidend zaaksysteem?
G. Leidend zaaksysteem en DMS verschillend?
Misschien moeten we gewoon uitgaan van functionaliteiten ipv applicatievormen. De naam van het beestje heeft geen betekenis. Op naam kan je niet beoordelen/toetsen, op functionaliteiten wel.
H. Zoeken en vinden: zaak- of documentgewijs?
Hangt helemaal af van gebruiker en fase. Een document zonder context (zaak-/dossieromgeving) lijkt mij niet tot nauwelijks op waarde te interpreteren zonder de andere dossierdocumenten. Belangrijk hierbij is welke gebruiker je voor ogen hebt. De proceseigenaar tijdens het dynamisch proces? Of de burger na pakweg 5 jaar (geldt dan ook weer voor die proceseigenaar).
J. Wie start de zaak?
Volgens mij altijd de burger/buitenwereld of proceseigenaar. Om dit te structureren en te archiveren maken we gebruik van DIV kennis. Los van waar je die dan organiseert. In een afdeling, bij de gebruiker of automatisch digitaal. De formele trigger zal (mag ik hopen) altijd op een authentieke en duurzaam beheerbare vorm zijn.
L. Wel of niet alsnog de Basisarchiefcode vastleggen?
Misschien is dat niet de vraag. De vraag is of je al die zaken/dossiers (vele honderden) onderling in een ongestructureerde digitale omgeving wil gaan beheren. Wil je kunnen zoeken op verwante zaken/dossiers zal je daar gemeenschappelijke metadata voor moeten meegeven. Nog los van het feit dat de huidige wetgeving nog steeds aggregatieniveaus verplicht stelt. De vraag is dan meer of iedereen dan weer zijn eigen structuur voor de gemeentelijke vierkante km gaat uitvinden of dat we gebruik willen maken van al breed (landelijk) gebruikte ordeningsstructuren. Over standaardisatie gesproken. Overigens is de BAC afgeleid van kennisveld 3.5 van de UDC (Paul Otlet en Henri La Fontaine). De UDC omvat kennisvelden en is helemaal niet specifiek ontwikkeld voor fysieke archiefvorming. De UDC classificeert alle soorten informatie in elk type medium, dus zowel boeken als beeldmateriaal, films, geluid, voorwerpen, internetsites en zelfs ideeën. Het systeem is zo opgezet dat er plek is voor nieuwe vakgebieden, dus het groeit met de uitdijende kennis mee. Het vernuftige van de UDC is dat er ook mogelijkheden zijn om verbanden aan te brengen tussen documenten. Daardoor kun je, als je op zoek bent naar bepaalde informatie, ook sporen vinden naar andere belangrijke categorieën. De UDC wordt bijgehouden en jaarlijks uitgebreid onder verantwoordelijkheid van het UDC Consortium, dat zetelt in Den Haag.
Een publicatie van Digital Display noopt altijd tot lezen en kennisvermeerdering. We hebben de zaken X en Y gehad en ook het handboek vervanging was een goede publicatie. Mijn verwachtingen waren dan ook hoog toen ik afgelopen weekend de tijd nam om het document van Ben de Jong door te nemen.
Het is in het kort een synopsis van kernpunten van de gang van zaken op dit moment. Daar is echt behoefte aan en Ben de Jong doet dat goed. Daarbij wordt af en toe stelling genomen in zaken zoals over de functie van een DMS/RMA versus zaaksysteem en wel of geen big bang, die m.i. nog niet helemaal zijn uitgekristalliseerd. Zo is de big bang in Dordrecht niet geheel zonder problemen verlopen, heb ik me laten vertellen en VHIC pleitte onlangs nog voor een langzamer scenario.
Specifiek heb ik de volgende feedback
Mooie reacties! Uiteraard wil ik ook zelf nog even een duit in het zakje doen:
Intro
Een duidelijk standpunt tegen het "oude wijn in nieuwe zakken"-standpunt! Hoe het ook zij, wat ik bijzonder vind aan het zaakgericht werken, is niet het letterlijk zaakgericht werken waarbij de zaak centraal staat. Ik vind de kracht achter deze ontwikkelingen dat bij de invoering wordt gelet op het perspectief van de burger, de behandelaar, de manager en de DIV'er. Door met alle vier de groepen SAMEN processen en de informatiehuishouding daaromheen in te richten, kunnen we een win-win-win-win situatie opleveren!
Nou ja, de burger wordt feitelijk nauwelijks betrokken, maar je snapt wat ik bedoel.
A.
Mee eens. Ik koop zelden tot nooit iets bij BOL. Toch verwacht ik dat, wanneer ik iets bestel, zij mijn bestelling op een klantvriendelijke en efficiënte manier behandelen. Dus als ik die ene keer iets van de gemeente vraag...
D.
Ik ben groot voorstander van de inzet van ZGW voor interne processen. Het enige verschil is dat de klant geen burger is, maar een medewerker. Er is echter wel nog steeds sprake van een "klant". Wat dat betreft vind ik het jammer dat KING zich beperkt tot de "extern-gerichte" processen, bijvoorbeeld in haar ZTC.
F.
Gevalletje business case. Wat kost koppelen en wat levert het op? Overstijgen de kosten de baten, dan ligt kloppelen voor de hand.
H.
Zoeken op zaak of document? Beide, al zal zoeken op zaak - verwacht ik - het meest praktische zoekresultaat opleveren.
J.
Een hoop zaaktypes zijn eenvoudig te herkennen en kunnen zo gestart worden. Maar er is ook een verzameling documenten, waarbij het bijbehorend zaaktype niet zo duidelijk is of waarbij het niet duidelijk is of er al een zaak over bestaat. Je kunt dan wel als DIV'er wel moeilijk doen, maar waarschijnlijk is het een eitje voor de behandelende afdeling. Stuur wat mij betreft dan het document door en laat ze zelf een zaak aanmaken o.i.d. Pak als nieuwe DIV dan wel je controlerende taak op!
L.
Afschaffen die BAC.
M.
Verschilt per organisatie. Het nadeel van de Big Bang is dat je geen leercurve doormaakt. Bij een gespreide invoering kun je tussentijdse evaluaties houden. Bijvoorbeeld, je implementeert ZGW bij afdeling X. Je maakt ongetwijfeld fouten. Daar leer je van. Die ervaring kun je meenemen naar de invoering van ZGW bij afdeling Y.
Nog een nadeel. Bij de invoering van een systeem doemen er altijd problemen op (hopelijk klein). Ook hebben diverse gebruikers vragen. Dit duurt enkele dagen en neemt geleidelijk af. Hoeveel DIV'ers, ICT'ers, etc. heb je nodig om dit te ondersteunen? En je kunt ze misschien wel inhuren, maar zorg je voor de nodige afstemming tussen de ondersteuners?
En wat waren je doelstellingen? Als alles via kloppelingen is gerealiseerd, dan kan een Big Bang misschien. Als er echter ook allerlei koppelingen gelegd zijn, dan is de kans op problemen groter. Heb je genoeg ondersteuners?
Inderdaad hele interessante en zinvolle discussies. Het nog eens gelezen te hebben vraag ik mij af of er ook DIV-ers zijn die zich door het voorbeeld van een misvatting in de inleiding van de Whitepaper aangesproken voelen of herkennen. Mij lijkt dat juist in dit voorbeeld al misvattingen besloten liggen. Voor het gemak neem ik deze hieronder integraal over.
Een voorbeeld van een misvatting:
DIV-ers vinden vaak dat er eigenlijk weinig verandert met de introductie van zaakgewijs werken. ‘Jazeker, want wij koppelen al jaren de uitgaande brief aan het inkomende stuk met DocMan!’
Ons antwoord daarop is: Zaakgewijs werken kan alleen maar gedijen in een digitale omgeving: zaakgewijs werken veronderstelt digitaal werken, waarbij archiefvorming ten tijde van de behandeling plaatsvindt en begint zodra een eerste document (telefoonnotitie, webformulier of binnenkomende post) de zaak heeft opgestart. Niet na afloop van het afhandelproces. Dus ook al is in het analoge dossier de uitgaande brief terug te vinden bij de aanvraag, dan is er nog geen sprake van zaakgewijs werken!
De DV-er
Graag wil ik een lans breken voor de DIV-er. Natuurlijk heb je DIV-ers met een wellicht wat eenvoudige blik op hun vakgebied. Maar hier wordt de DIV-er naar mijn gevoel wel in een karikatuur gezet die niet representatief is voor De DIV-ver in het algemeen. Maar in de kern van de zaak heeft deze DIV-er meer gelijk dan ons misschien lief is.
Zij pogen immers al jaren om zaken/dossiers volgens een logisch procesverloop te archiveren. Evenredig de regierol en menskracht waarover DIV beschikte was en is DIV in staat hun dossiervorming naar de voorkant van het proces te trekken. Zij waren alleen afhankelijk van de mate waarin organisaties en proceseigenaren hun processen in relatie met de documentneerslag organiseerde. Veel proceseigenaren hielden er zo hun eigen manier van werken op na en lieten zich niet makkelijk leiden door tips of adviezen van die DIV-er met wel degelijk een genuanceerde blik op het vakgebied. En het management vond het vaak wel goed zo. Maar een DIV-er kan zijn/haar werk pas goed doen wanneer de proceseigenaar in staat is de documentneerslag van haar eigen processen goed weer te geven. In de praktijk blijkt daar nogal veel aan te mankeren. Het komt regelmatig voor dat proceseigenaren zelf afwijkende ideeën over hun dossiervorming hebben en zelfs niet eens een eenduidig beeld kunnen schetsen van hun eigen dossierneerslag. Wanneer een dossier dan niet volledig was had die DIV-er het natuurlijk weer gedaan.
Het antwoord
Dat zaaksgewijs werken beter kan gedijen in een digitale omgeving betekent nog niet dat je dan pas van zaaksgewijs werken mag spreken. Daarmee heeft die DIV-er wel degelijk een punt wanneer hij/zij zegt dat archivistisch gezien de essentie van zaaksgewijs werken niets nieuws is, procesmatig veel meer. Dat dit om standaardisatie en eenduidige inrichting van de procesgang vraagt spreekt voor zich. Evenals dat de implementatie daarvan complex is, maar maakt daarmee het concept niet nieuw. Door het concept ook als nieuw te presenteren maakt dit de implementatie hiervan alleen maar onnodig ingewikkelder. Men probeert dan een concept te doorgronden waarvan men denkt dan het nieuwe is terwijl zij zich later realiseren dat zij het concept allang kennen. Niet zelden een paar congressen en hele tijd later.
D. Dienstverlening gericht op ‘producten’ of op alle processen?
Laatste alinea. Zaaksgewijs werken lijkt mij niet de tegenpool van analoog werken. Ook analoog kan je het concept van zaaksgewijs werken toepassen. Evenals de veronderstelling dat zaaksgewijs werken kennelijk per definitie niet documentgericht en analoog werken wel documentgericht zou zijn. Naar mijn gevoel is deze veronderstelling onjuist en veroorzaakt op zichzelf onnodige verwarring. Wanneer zaaksgewijs werken geheel digitaal verloopt kan je anders met het documentniveau omgaan, maar zullen dan ook volgens een zaak/statusstructuur hun plek moeten krijgen. Analoog werk je fysiek met afzonderlijk documenten maar denkt de DIV-er vaak al in het dossierconcept (de procesuitvoerder overigens ook). Dat moet ie ook wel anders kan het analoge dossier (zelfs achteraf) niet gevormd worden.
L. Wel of niet alsnog de Basisarchiefcode vastleggen?
In mij eerdere reactie al genoeg over gezegd. Maar, wat mij tot nu toe is opgevallen aan de ZTC is dat deze structuur mist. Het is een bak met een onwillekeurige opsomming van zaaktypen. En daar waar context relevant wordt valt mij op dat daar nu juist de onderwerptitels van de BAC worden gebruikt. Ik sluit niet uit dat hier wellicht onbewust de toegevoegde waarde als contextinformatie voor een zaaktype wordt erkend. Alleen een zaaktype met een BAC titel (natuurlijke taal) zonder zijn aggregatiestructuur (kunstmatige taal) biedt geen oplossing. Ben alleen wel benieuwd hoe er wordt gedacht over een eenduidig en gestandaardiseerde ordeningsstructuur van de ZTC.
@Marco
Met afschaffen heb ik op zich geen enkel probleem, maar welke eenduidige en liefst gestandaardiseerde structuur ga je je ZTC dan meegeven? Er zal iets meer duurzaams boven of onder moeten hangen om te voorkomen dat je afhankelijk wordt van allerlei subjectieve niet duurzame tags of een lappendeken van evenzo subjectieve structuursWil je een hierarchische ordening in de zaaktypen / DSP-processen? Ik vraag me af of dat nodig is, maar ik houd je niet tegen. Ik denk dat je door het gebruik van de juiste kenmerken (metadata) op zaaktype-niveau voldoende mogelijkheid hebt om de juiste zaaktypen en bijbehorende zaakdossiers bijeen te rapen.
Ik vind een hierarchische ordening ouderwets t.o.v. een netwerk-gebaseerde ordening. Informatie in een digitale omgeving kan in een boomstructuur geordend worden (bijv. mappenstructuur), maar kan ook een soort spinnenweb vormen (bijv. database). Misschien moet ik dat eens in een afzonderlijke blog ter discussie werpen...
Marius Jansen zei:
@Marco
Met afschaffen heb ik op zich geen enkel probleem, maar welke eenduidige en liefst gestandaardiseerde structuur ga je je ZTC dan meegeven? Er zal iets meer duurzaams boven of onder moeten hangen om te voorkomen dat je afhankelijk wordt van allerlei subjectieve niet duurzame tags of een lappendeken van evenzo subjectieve structuurs
Ik wil niets, en een hiërarchische structuur is ook geen doel op zichzelf, behalve dat het contextlagen biedt en daar is wel behoefte aan. Het gaat mij ook niet om de bac. Wanneer er een eenduidige mappenstructuur, spinnenweb of welke structuur dan ook wordt ontwikkeld die dezelfde contextlagen in zich heeft en net zo (landelijk?) breed kan worden ingezet juich ik dat juist toe. Heb alleen nog geen alternatief gezien dat daaraan voldoet. Maar de bac voldoet wel precies aan het kenmerk (functionaliteit) dat je zelf oppert: "Ik denk dat je door het gebruik van de juiste kenmerken (metadata) op zaaktype-niveau voldoende mogelijkheid hebt om de juiste zaaktypen en bijbehorende zaakdossiers bijeen te rapen". Dat is nou precies wat ie doet en wat in het huidge ztc ontbreekt. Bovendien is het wat mij betreft niet of/of maar en/en. Dat is nu het mooie van digitale ontsluiting, dat je niet meer afhankelijk hoeft te zijn van één structuur.
Marco Klerks zei:
Wil je een hierarchische ordening in de zaaktypen / DSP-processen? Ik vraag me af of dat nodig is, maar ik houd je niet tegen. Ik denk dat je door het gebruik van de juiste kenmerken (metadata) op zaaktype-niveau voldoende mogelijkheid hebt om de juiste zaaktypen en bijbehorende zaakdossiers bijeen te rapen.
Ik vind een hierarchische ordening ouderwets t.o.v. een netwerk-gebaseerde ordening. Informatie in een digitale omgeving kan in een boomstructuur geordend worden (bijv. mappenstructuur), maar kan ook een soort spinnenweb vormen (bijv. database). Misschien moet ik dat eens in een afzonderlijke blog ter discussie werpen...
Marius Jansen zei:@Marco
Met afschaffen heb ik op zich geen enkel probleem, maar welke eenduidige en liefst gestandaardiseerde structuur ga je je ZTC dan meegeven? Er zal iets meer duurzaams boven of onder moeten hangen om te voorkomen dat je afhankelijk wordt van allerlei subjectieve niet duurzame tags of een lappendeken van evenzo subjectieve structuurs
© 2024 Gemaakt door Marco Klerks. Verzorgd door