Vanmorgen hebben we een discussie gehad waar de projectgroep niet uit kwam.

 

Het gaat om het volgende. Er zijn werkzaamheden die we zaakgericht willen afhandelen, maar waar op zaaktypeniveau geen doorlooptijden bebben. Hiermee bedoelen we bijvoorbeeld projecten. Niet elk project heeft een doorlooptijd van 9 weken, 1 jaar of iets dergelijks. Op zaakniveau (het echte project Verwerving gronden Langestraat 2011) worden wel afspraken omtrent de doorlooptijd gemaakt. Dit geldt echter voor elke instantie van een ZAAK van het ZAAKTYPE projecten. Er zijn geen overkoepelende zaaktypedoorlooptijden te beschrijven. Het is dan ook lastig om een doorlooptijd of kwaliteit van dit soort werkzaamheden te bepalen. Hetzelfde geldt voor die processen die geen doorlooptijd, maar een uiterste aanleverdatum hebben, te denken valt aan het organiseren van verkiezingen of het aanleveren van stukken voor een vergadering. De vergadering of verkiezing is bijvoorbeeld op 13 maart en het maakt uit wanneer de werkzaamheden starten, dat bepaalt de doorlooptijd niet het "proces". Ik ben benieuwd of er organisaties zijn die deze problematiek succesvol hebben aangepakt en hoe het gedaan is?

Weergaven: 789

Berichten in deze discussie

De afhandeltermijn / doorlooptijd van projecten (en een aantal andere processen) kan dus niet vooraf op zaaktype-niveau geregeld worden. Bij ieder project zal handmatig de doorlooptijd ingevuld of aangepast moeten worden. De vraag is even wie dat zou moeten kunnen.

 

Mag iedere gebruiker dat? Of mag iedere gebruiker, die geautoriseerd is voor het maken/muteren van zaken van het zaaktype "het voeren van een project", dat? Of mag de projectleider (= behandelaar?) van de zaak dat? Of mag alleen de (D)IV-er dat? Ik heb het hier dus over authorisaties. Hoeveel complexiteit in de authorisatie-structuur kan het systeem aan en hoe complex wil je het voor jezelf en je collega's maken?

 

Ik twijfel even tussen "de projectleider" en "alleen (D)IV". Bij de optie "de projectleider" leg je de mogelijkheid en de verantwoordelijkheid voor de juistheid van de afhandeltermijn van iedere (project-)zaak bij de projectleider. Dat klinkt prima! Maar misschien is dit alleen te realiseren door bij alle zaaktypen deze rechten open te stellen voor de (huidige) behandelaar. Is dat te veel vertrouwen en vrijheid?

 

Ja, ook "alleen (D)IV" is wat mij betreft een optie. Het inrichten van een project-dossier is geen eenvoudige klus. sterker nog, de inrichting kan van project-dossier tot project-dossier sterk verschillen. Kun je het zaaktype "project" zodanig flexibel inrichten, zodat het ieder denkbaar project - groot of klein - optimaal kan ondersteunen? Of streef je er liever naar dat bij ieder nieuw project een "nieuwe DIV-er" op de interne klant afstapt om voor hem of haar een project-zaak geheel op maat te maken? In hoeverre kan het systeem bij een zaak afwijken van het zaaktype?

De vraag over autorisatiestructuur is een hele leuke, ligt heel erg aan de organisatiekant om dat goed in te richten. En wat mij betreft doe het zo centraal mogelijk. En dat mag een DIV-er zijn, maar het kan ook een secretaris van het project zijn die belast is met de archivering. De autorisatiestructuur raakt ook aan de discussie over beveiliging mogen alle projectleden alle documenten binnen het project kunnen raadplegen en zelfs muteren? Dus niet alleen de doorlooptijd bepalen.

 

Ander punt waar ik mee worstel is wat is de meerwaarde van Zaakgericht Werken voor projecten. Is het voor projecten, ook gezien het antwoord van Marco, niet veel meer noodzakelijk dat de juiste documenten en zaken bij elkaar te krijgen zodat een overzicht geboden kan worden? Daar kan DIV inderdaad een mooie rol in spelen.


De vraag in hoeverre een zaak van het zaaktype kan afwijken of wat zijn nog de overeenkomsten van alle zaken zodat je een zaaktype kan definieren. Wat is het zaaktype project?  Marco krijgen jullie ook een zaaktype project en wat gaan jullie hiermee doen?


Marco Klerks zei:

De afhandeltermijn / doorlooptijd van projecten (en een aantal andere processen) kan dus niet vooraf op zaaktype-niveau geregeld worden. Bij ieder project zal handmatig de doorlooptijd ingevuld of aangepast moeten worden. De vraag is even wie dat zou moeten kunnen.

 

 

Er zijn in Den Bosch nog geen harde knopen doorgehakt over de relatie tussen projecten en zaakgericht werken.

 

Wat volgens mij de crux is in de ontwikkeling die "zaakgericht werken" heet, is dat je een match maakt tussen het proces en de informatievoorziening, waarbij je rekening houdt met de belangen van de burger, de behandelaar, de manager en de informatieverzorger (DIV'er).

 

Zaakgericht werken wordt ook wel "oude wijn in nieuwe zakken" genoemd. Projecten zijn de oude wijn. Die zullen blijven lopen zoals ze lopen. Het zaakgericht werken zijn de nieuwe zakken. Het zaakgericht werken biedt een verzameling aan termen, platen en concepten, die de betrokken partijen kunnen hanteren om de bovengenoemde doelstelling te bereiken.

 

Door ieder project als een zaak te benoemen en datgene wat alle projecten generiek hebben te benoemen als zaaktype, kun je hier eenzelfde aanpak ter verbetering en samenwerking hanteren als bij bijvoorbeeld subsidie-verstrekkingen of vergunning-verleningen. "Zaakgericht werken" is wat mij betreft niet zo zeer een manier van werken, als wel een manier om over het werken te praten en het te organiseren. Dat geldt dus ook voor de uitvoering van projecten.

 

Hoe die termen, platen en concepten zich concreet vertalen in het systeem, verschilt van systeem tot systeem.

Blijkbaar wordt ook bij de ontwikkeling van de Baseline DIV gezocht naar de relatie tussen project-uitvoering en zaakgericht werken: http://twitter.com/#!/RJE_Alexander/status/83502539114422272

Een project zou je volgens mij kunnen beschouwen volgens de zelfde methodiek (meta-model) als de omgevingsvergunning, evenmentenvergunning en andere "productclusters".

Deze (manier van kijken) bevat ook deel- en vervolgzaken. In jouw geval Rob is het "project" de hoofdzaak. De gemeente Heerhugowaard bijvoorbeeld (ingenieursbureau) heeft een aantal soorten (ook wel typen) projecten gedefinieerd met elk een vast aantal faseringen. Annaloog feitelijk aan de statussen van een zaaktype. Elk projectfase (deelzaak met concreet zaaktype) kan een voorgedefinieerde doorlooptijd of (nader in te vullen) deadline hebben. Op deze manier hanteer je hetzelfde model als bij de omgevingsvergunning en andere meervoudige zaken (lees: zaaktypes).  Ook handig dat je één metamodel hanteert met eigenschappen voor zaaktype-, project en processtructuren.

Daarbij is het van belang om in een projectomgeving inzicht te (ver)krijgen in de KPI´s prestatie indicatoren in dit geval op zaaktypes. Net zoals de BPM (procesmanagement) wereld deze hanteert. Deze prestatieindicatoren zijn een kenmerk van een proces en/of project c.q. zaaktype. En die kenmerken die wij eigenschappen noemen voegen we toe aan de geintegreerde ZTC/DSP/procesebeheer omgeving die wij I-Controler noemen.

 

Overigens is het wel van belang dat we op onze woorden letten. Projecten (meervoud) of project (enkelvoud) zijn echt twee verschillende namen van zaaktypes. Zoeken en vinden wordt een beetje lastig als je geen taalconventies hanteert.

 

P.s. Bovenstaande beheren is overigens in mijn ogen de taak van de centrale informatie- en procesmanager. Hij/zij modelleert niet alleen de (template) processen, niet alleen de eenduidigheid van informatie (metadata en zaaktypes etc) maar doet dat geintegreerd in de I-Controler. Eén model, één methode, één centrale beheeromgeving over alle applicaties heen en niet meer verzuild per applicatie(beheerder).

RSS

© 2024   Gemaakt door Marco Klerks.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden