Berichten in deze discussie

Permalink Antwoord van Saskia Giesbers op 9 Augustus 2010 op 11.29

"We willen binnen onze informatiesysteem een toegangspoort tot alle informatie hebben. Binnen ons zaaksysteem moet een zoekmachine komen die zowel in het DMS als in het Zaaksysteem gaat zoeken." Hebben jullie overwogen om met een portal te werken? Zo ja, wat waren de afwegingen om niet met een portal te gaan werken?

In reactie op de manieren die jullie hebben bekeken:
1. Het is handig is om onderscheid te maken in initiëren en verantwoorden van projecten dat onder planning en control valt enerzijds en uitvoering van het project anderzijds, omdat hierbij verschillende functionarissen betrokken zijn. Een eerste idee kan bovendien leiden tot één of meerdere of helemaal géén project.

2. De organisatie en aard van het project bepaalt de behoefte ten aanzien van een (voor externen toegankelijke) samenwerkingsomgeving. Het is prima mogelijk om een standaard projectstructuur aan te reiken, waarbinnen de projectleider naar behoefte nader kan specificeren (bijv. naar producten of perioden). Regel archivering van het project tijdens en na afloop/beëindiging van het project. Er zijn organisaties die voor de creatieve processen een ander DMS gebruiken dan voor gestructureerde processen.

3. Hier kies je voor de metadata-oplossing, door het projectkenmerk aan documenten toe te kennen, gaan ze deeluitmaken van het (dynamisch gecreëerde) projectdossier.

Een uitdaging die je hier niet noemt, is relatie tussen projecten. Relaties op basis van verwante resultaten (bijv. betreffende ontwikkeling in hetzelfde dorp, ten behoeve van dezelfde doelstelling), op basis van aanspraak op dezelfde resources (belangrijk voor capaciteitsplanning) etc.

Permalink Antwoord van Marco Klerks op 9 Augustus 2010 op 19.31

Ik merk dat je al diep, diep in de materie zit. ;-)

Optie 1 is het snelst en eenvoudigst te realiseren, maar tijdens een project komt er vaak zo veel correspondentie kijken, dat het al gauw een onoverzichtelijk geheel wordt.

Optie 2 is een heel waardevol gezichtspunt, omdat je hier niet alleen kijkt naar de archivering van het project, maar ook (de ondersteuning van) het uitvoeren van het project. Je biedt niet alleen een omgeving waarin documenten opgeslagen en geraadpleegd kunnen worden, maar ook een omgeving waarin medewerkers kunnen (samen-)werken.

Optie 3 let weer vooral op de archivering. Heb je in de gaten dat je het hier hebt over de hoofdzaak "het uitvoeren van een project" met daaronder diverse deelzaken, bijvoorbeeld "het uitvoeren van een aanbesteding", "het aanvragen van een subsidie bij derden" en "het opstellen van beleid"? Werp eens een blik op het voor gemeenten opgestelde RGBZ om te zien hoe ze daar vorm hebben gegeven aan deelzaken. Deze oplossing biedt als voordeel dat bijvoorbeeld een aanbesteding altijd op gelijke, betrouwbare wijze wordt uitgevoerd en gearchiveerd, of het nu deel uitmaakt van een project of niet.

Persoonlijk zie ik wel iets in een collaboratieomgeving, waarin aan de projectleider of -secretaris functionaliteit wordt geboden om informatie op te slaan in een omgeving à la optie 3.

Permalink Antwoord van Saskia Giesbers op 10 Augustus 2010 op 7.41

Dat klopt. De genoemde deelzaken hebben wel elk een andere relatie met het project. Het "beleid" is het resultaat van het project. Het "aanvragen van een subsidie bij derden" is een sub-actie binnen regelen financiering van het project. En "uitvoeren van een aanbesteding" is een vorm van inkoop waarmee goederen of diensten worden verkregen die het mogelijk maken het project tot een goed einde te brengen (kan ook leiden tot mantelovereenkomsten die voor meerdere projecten/processen relevant zijn). De laatste twee gaan over het invullen van randvoorwaarden. Of je dit nu in de informatiesystemen organiseert als deelzaken of als verwante zaken maakt m.i. niet uit.

Marco Klerks zei:

Heb je in de gaten dat je het hier hebt over de hoofdzaak "het uitvoeren van een project" met daaronder diverse deelzaken, bijvoorbeeld "het uitvoeren van een aanbesteding", "het aanvragen van een subsidie bij derden" en "het opstellen van beleid"? Werp eens een blik op het voor gemeenten opgestelde RGBZ om te zien hoe ze daar vorm hebben gegeven aan deelzaken. Deze oplossing biedt als voordeel dat bijvoorbeeld een aanbesteding altijd op gelijke, betrouwbare wijze wordt uitgevoerd en gearchiveerd, of het nu deel uitmaakt van een project of niet.

Permalink Antwoord van Rob van der Velde op 10 Augustus 2010 op 9.06

@marco en @Saskia

Dank voor jullie meedenken. Ik zie bij jullie ook worstelingen over wat nu de beste weg is. En waarschijnlijk is er dus nog niet een manier die zich heeft bewezen. Het blijft dus theoretisch praten over wat zou kunnen werken.

Ik heb nog wel een vraag over hoe jullie optie 3 in de praktijk zien. Daarin wordt gesproken over deelzaken. Even voor mijn begrip. Deelzaken zijn ook "gewone" zaken. Dat betekent dat ze een voorkomen zijn van een zaaktype. Zoals opstellen van beleid kan zowel als hoofdzaak, maar ook als deelzaak voorkomen. Geldt dat voor alle deelzaken? Ik denk het niet, advies van de ene afdeling aan de andere afdeling kan mijns inziens niet voorkomen als hoofdzaak. Dat betekent dat je heel goed moet kijken naar hoe je de verschillende zaaktypen gaat beschrijven, anders loop je het gevaar dat er duizenden zaaktypen gaan ontstaan. Dat is voor het registreren, maar ook voor de historicus over 75 jaar niet echt behulpzaam. Hoe kijken jullie tegen dit probleem aan? Zijn er alleen maar "lijn"zaaktypen of zijn er ook "project"zaaktypen. En wie is eigenaar van dat zaaktypen.

Wat ik met optie 3 voor ogen heb is het volgende. Er zijn binnen een organisatie 600 werkprocessen bijvoorbeeld het uitvoeren van een aanbesteding. Dit is een werkproces dat bijvoorbeeld bij de afdeling Facilitaire Zaken. Binnen het project wordt om een aanbesteding gevraagd en dan levert dat een zaak op binnen het zaaktype Uitvoeren Aanbesteding waarvan FZ proceseigenaar is. Dit heeft zoals Marco terecht aangaf als voordeel dat elke aanbesteding op gelijke wijze gearchiveerd wordt, over de uitvoering zegt een zaaktype in mijn idee veel minder, omdat de ambtenaar verantwoordelijk is HOE hij dit uitvoert, in tegenstelling tot verder uitgewerkte workflow methodes.
Deze zaak moet als kenmerk dan Project Z krijgen. Het nadeel daarvan is dat daardoor het projectdossier alleen bij de gratie van een zoekvraag bestaat. In optie 2 heb je nog het idee van een projectdossier dat je kan bevatten, namelijk in de collaboratieomgeving. Mijn vraag is wat binnen de overheid beter zou voldoen?

@Saskia
Relaties tussen projecten kan je heel best leggen door gebruik te maken van basis- en kernregistraties zoals gemeentenaam, thema's uit het Provinciaal Omgevingsplan etc.. De interpretatie van die gegevens die zou ik niet aan het zaaksysteem overlaten dat is zoveel logica dat daar betere backofficeapplicaties voor zijn.

Waar ik jullie nog niet over gehoord heb is er voor elk project een afzonderlijk zaaktype of is er een zaaktype project waar elk project een zaak onder is.

Permalink Antwoord van Marco Klerks op 10 Augustus 2010 op 9.20

Saskia Giesbers zei:

Het "beleid" is het resultaat van het project.

Ah, een fout die m.i. vaak gemaakt wordt. Het doel van een project is nooit het vormen van beleid. Althans, dat zou het doel niet mogen zijn. Niemand zit immers te wachten op nog meer regeltjes. Nee, je wilt de werkeloosheid omlaag brengen, het veiligheidsgevoel vergroten, de dienstverlening verbeteren (sneller, betrouwbaarder, etc.), meer culturele activiteiten in je gemeente, etc. Het vormen van beleid is één van de activiteiten die je dan mogelijk moet doen. Het beleid is het resultaat van die activiteit, maar niet het resultaat van het project.

Saskia Giesbers zei:

Of je dit nu in de informatiesystemen organiseert als deelzaken of als verwante zaken maakt m.i. niet uit.

Ja, ik worstel er ook mee wanneer een zaak nu een deelzaak moet zijn of juist een verwante zaak. Het is m.i. iets in de trant van "de zaak X is een deelzaak van zaak Y als het resultaat van zaak X voorwaardelijk is voor het afronden van zaak Y". Deze definitie voelt echter ook nog wat wrang, dus ik zit er nog op te broeden.

Het verschil in relaties (deelzaak of verwant) kan relevant zijn voor je ordening en waardering. Wat het concrete onderscheid is, is ook iets waar ik nog op zit te broeden.

Permalink Antwoord van Marco Klerks op 10 Augustus 2010 op 10.03

Rob van der Velde zei:

Geldt dat voor alle deelzaken? Ik denk het niet, advies van de ene afdeling aan de andere afdeling kan mijns inziens niet voorkomen als hoofdzaak.

Een proces, welke ten grondslag ligt aan een zaaktype, kan afdelingsoverstijgend zijn. Een advies kun je dus zowel als een afzonderlijk zaaktype modelleren of als een fase in een bestaand zaaktype. Beide opties hebben zo z'n voordelen en z'n nadelen. Als je meer informatie wilt over afdelingsoverstijgende processen, dan wil ik hier best wat uitgebreider op ingaan.

Rob van der Velde zei:

Het nadeel daarvan is dat daardoor het projectdossier alleen bij de gratie van een zoekvraag bestaat.

Ik zie optie 3 als volgt. Ik ga naar het DMS en zoek het zaakdossier op van het zaaktype "het uitvoeren van een project". Mijn scherm wordt in drie vlakken gedeeld:
- Eén vlak met metadata van het zaakdossier,
- Eén vlak met documenten die opgenomen zijn in het zaakdossier (projectplan, notulen, e.d.)
- Eén vlak met zaken welke een deelzaak-relatie hebben met het zaakdossier. Dergelijke deelzaken kan ik uitvouwen om te zien of daar nog documenten in zijn opgenomen (of zelfs deeldeelzaken).

Andere interfaces zijn denkbaar, maar ik hoop dat het duidelijk is wat ik bedoel.

Rob van der Velde zei:

Waar ik jullie nog niet over gehoord heb is er voor elk project een afzonderlijk zaaktype of is er een zaaktype project waar elk project een zaak onder is.

In principe is er één zaaktype "het uitvoeren van een project", waaronder ieder project een afzonderlijke zaak is. Het is echter denkbaar dat je een aantal verschillende zaaktypen neemt om beter aan te sluiten op de diverse projectmanagement-methodes, bijvoorbeeld "het uitvoeren van een PRINCE2-project", "het uitvoeren van een IPMA-project" en "het uitvoeren van een PMW-project".

Permalink Antwoord van Rob van der Velde op 10 Augustus 2010 op 11.06

Marco Klerks zei:

Saskia Giesbers zei:

Het "beleid" is het resultaat van het project.

Ah, een fout die m.i. vaak gemaakt wordt. Het doel van een project is nooit het vormen van beleid. Althans, dat zou het doel niet mogen zijn. Niemand zit immers te wachten op nog meer regeltjes. Nee, je wilt de werkeloosheid omlaag brengen, het veiligheidsgevoel vergroten, de dienstverlening verbeteren (sneller, betrouwbaarder, etc.), meer culturele activiteiten in je gemeente, etc. Het vormen van beleid is één van de activiteiten die je dan mogelijk moet doen. Het beleid is het resultaat van die activiteit, maar niet het resultaat van het project.

Euh beetje de weg kwijt. Wat is het verschil tussen activiteit en project als we het hebben over zaakgericht werken. Dan zoeken we zaaktypen en dat zijn, tenminste bij ons, werkprocessen en dat zijn producten en diensten en dan is beleid wel degelijk een dienst. En niet het veiligheidsgevoel vergroten. Dat kan een thema of trefwoord zijn.

Wat wij gezegd hebben hier is inderdaad dat een deelzaak voorwaardelijk is voor de afronding van de hoofdzaak. Dat hebben wij in onze domeinarchitectuur vastgelegd.

En eens dat een proces afdelingsoverstijgend zijn, er is echter een verantwoordelijke zaaktype-eigenaar. Die komt nu vaak voort uit een afdeling, maar dat is niet noodzakelijk inderdaad. Vanuit oude structuren houden we dat nu echter nog wel even vast.

En dan tot slot 1 zaaktype is leuk, maar wat zegt dat over de kenmerken van de onderliggende zaken wat is daar overeenkomstig. De doorlooptijden zijn niet gelijk, de trefwoorden zijn niet gelijk, de behandelaren zijn niet gelijk. Al die gegevens waarvoor je zaaktypen gebruikt (overeenkomstige kenmerken van de onderliggende zaken) gelden, mijns inziens, veel minder voor projecten.
Projecten worden opgestart als:

het probleem een uniek en éénmalig karakter heeft;
er alleen een globaal omschreven einddoel is;
er veel onzekere factoren zijn, zoals tijdsduur en de kosten;
bijdragen nodig zijn van verschillende afdelingen en/of externe partijen

Ik zie de toegevoegde waarde van Zaaktypen voor projecten nog steeds niet. Hopelijk kan iemand hier zijn licht over laten schijnen.

Permalink Antwoord van Saskia Giesbers op 10 Augustus 2010 op 13.02

Een project is een vorm van sturing: je gaat iets projectmatig uitvoeren. De genoemde methoden PRINCE2, IPMA en PMW helpen daarbij. Een project wordt gestart wanneer sprake is van de dingen die Rob noemt.

Een project realiseert een bepaald resultaat. Dat kan beleid zijn. Ook complexe vergunning-trajecten kunnen projectmatig worden uitgevoerd. Enzovoort. Wanneer meerdere projecten noodzakelijke stukjes realiseren die nodig zijn om een bepaald doel te realiseren, wordt het geheel veelal aangestuurd via een programma.

Het project is geen doel op zich. Niemand vraagt om een project te gaan uitvoeren. Volgt daar niet uit dat het vreemd is om een zaaktype voor projecten te hebben?

Permalink Antwoord van Marco Klerks op 10 Augustus 2010 op 23.30

Ik moet toegeven dat ik het onderscheid tussen wat een project is en wat een programma is, lastig vind. Ik wil dit jaar een cursus of twee hierover volgen, dus daar wordt aan gewerkt. ;-)

Is een project een zaak? De "zaak" wordt gedefinieerd als een reeks handelingen waarvan je de kwaliteit en doorlooptijd wilt bewaken. Dit lijkt mij zeker ook van toepassing op projecten.

Het zaakgericht werken is o.m. uitgevonden om de uniformiteit in al die (gemeentelijke) activiteiten op te zoeken. Door alle activiteiten volgens eenzelfde dogma vorm te geven, wordt het eenvoudiger om generieke voorzieningen en koppelingen te realiseren. Door projecten in een zaak-jasje te steken, kun je gebruik maken van de functionaliteiten en koppelingen die in en met het zaaksysteem reeds gerealiseerd zijn. Denk daarbij bijvoorbeeld aan koppelingen met de frontoffice, de backoffice en de basisregistraties.

Concreet, stel dat je in MS Word een knop hebt "opslaan in zaakdossier". Wil je daarnaast nog een knop hebben "opslaan in projectdossier"?

Je zou in de backoffice een collaboration-omgeving kunnen plaatsen, die functionaliteiten biedt die alleen nodig zijn voor het proces "het uitvoeren van een project". Wanneer in deze omgeving een nieuw project wordt gestart, wordt in het zaaksysteem (midoffice) een zaak aangemaakt. Statuswijzigingen en informatie worden uitgewisseld. De zaak is vervolgens toegankelijk voor de hele organisatie, zodat iedereen kan informeren naar het verloop en de voortgang van het project (interne transparantie) en wel op dezelfde wijze waarop ook het verloop en de voortgang van andere zaken geraadpleegd kan worden.

Bovendien kunnen eenvoudige deelzaken uitgevoerd worden met de standaardfunctionaliteiten die reeds in het zaaksysteem voorhanden zijn. Een update van een deelzaak wordt gelijk doorgegeven aan de collaboration-omgeving. Sterker nog, een deelzaak kan zelfs behandeld worden in een andere backoffice-applicatie die ook aan het zaaksysteem is gekoppeld. Je hoeft bijvoorbeeld je financieel pakket alleen aan je zaaksysteem te koppelen en niet óók aan de collaboration-omgeving.

Helpt dit, Rob?

Permalink Antwoord van Jules Lauwerier op 26 Oktober 2010 op 11.34

Een project is een Zaak van het Zaaktype "(ruimtelijk) project" of "(beleidsvoorbereidend) project". Als er binnen het project andere Zaken lopen is dat gewoon een (sub)Zaak van het betreffende Zaaktype. Waar zit het probleem ?

Permalink Antwoord van Marco Klerks op 26 Oktober 2010 op 20.38

@Jules Een project is in de praktijk meer dan een samenraapsel van deelzaken. Bijvoorbeeld:
- Binnen een project vindt bijzonder veel schriftelijke en mondelinge communicatie plaats. Hoe leg je dit zodanig vast dat je enerzijds verantwoording kunt afleggen (reconstrueren van het proces) en anderzijds niet verzuipt in de hoeveelheid informatie (e-mails, e.d.)
- Binnen projecten is er een zeer sterke behoefte aan het verzamelen van informatie. Daar komt veel documentatie bij kijken. Vanuit het verantwoordings-belang en het cultuur-historisch belang is dit vaak niet archiefwaardig, maar wel bij het ondersteunen van het werkproces
- Het verloop van projecten verschilt per keer. Hoe houd je je systeem flexibel genoeg?
- Projecten kennen meer dan één behandelaar. Alle projectdeelnemers kennen verschillende rollen, die ze gelijktijdig vervullen. Hoe ga je daar mee om?
- Hoe kunnen medewerkers samenwerken aan documenten (collaboratie)?
- Projectdeelnemers kunnen ook van buiten de organisatie komen, bijv. leveranciers. Hoe ga je daar mee om?

En dit is wat ik even snel bij elkaar kan verzinnen.

Maar goed, ik denk dat in menige organisatie het al een mooie stap vooruit zou zijn als er digitale documenten in een digitaal dossier geplaatst kunnen worden. Begin klein en groei verder.

Permalink Antwoord van André Plat op 26 Oktober 2010 op 22.01

Tsja, veel gedoe en oplossingsrichtingen. Onderstaand mijn vlugschrift

Een zaak is bijvoorbeeld het bereiken van een maatschappelijk effect of de aanleg van een wegtracee (bijvoorbeeld Betuwelijn). De aanpak, bijvoorbeeld projectmatig of een programma is een werkvorm. Daarin komen fases zoals : opdracht, idee, wat, hoe te doen, voorbereiden, uitvoeren en afronden/overdracht aan beheer voor. Je kunt er het beste voor kiezen de zaak (het effect of het tracee) als zaak te zien. Het project vervolgens apart, waarbij volledigheid het beste gerealiseerd wordt als dynamisch, statisch direct digitaal plaatsvind. Social media zijn daar inmiddels (gezien externe partijen) geschikter voor dan dms/rma. Het archiveren van wat in de 'workspace' gebeurt en wat wel/niet op een willekeurig moment hierover gepubliceerd is: dat moet je dan goed regelen. Bijvoorbeeld door opname in dms, publicatie naar cms daarvan uit of andersom archiveren wat in het cms is gedaan.

Als je dsp gebruikt dan krijg je handvatten om vaststelling, uitvoering en beheer van een maatschappelijk effect als deelzaken op te nemen. Evenals de levering van diensten waarin je uitbestede werken kunt wegzetten.

Kern van zaakgericht werken is dat je werkt met het 4model:
1. subject (van, aan of over wie of welke instelling),
2. proces (met metadata, b/v termijnen, (3.)documenttypen) en
4. objecten (locatie aanduiding).
Je kunt in de dms een voorziening vragen om indien deze 3 metadata gelijk zijn in een bepaalde periode te wijzen op mogelijke lopende zaken waarbij de documenten moeten worden gevoegd.

De kunst is om zaken (en documenten) die bij elkaar horen ook bij elkaar te houden. Dat doen we niet meer door eenduidige processen (alle aanbestedingen, projectopdrachten, inlichtingenverzoeken bijelkaar) in verzamelmappen te proppen maar door het dossierstelsel wat we in 1950 introduceerden en waarvoor we met enkelvoudige dossiers zijn opgeleid toe te passen. In les 6 (SOD-1) betreffende ordeningsplannen is al onderkend dat vergaderstukken, projecten bijzondere groepen documenten zijn waarover je afspraken kunt maken. In het digitale tijdperk is het gemakkelijker geworden omdat je documenten aan meer zaken, processen, vergaderen en (iemand noemde het al) projecten kan toekennen. Wat je niet zoekt is dat je dit ook bij elk document steeds weer moet doen: dus overerven is handig als je al in een bepaalde zaak zit, en om die zaak als geheel langs een vergadering wilt laten gaan: of een hele cyclus vergaderingen, zoals college, presidium, commissie en raad.
Onze local hero pakketten bieden hier aanzetten tot oplossingen. Echter voor zover ik kan overzien hebben zowel Decos, Corsa als CircleSoftware deze materie nog niet stevig en lenig in onze dms-en zitten.
De leverancier die dit inricht en maakt, loopt de kans briljante parels voor (eindgebruikers en div) de zwijnen te maken. Wat natuurlijk wel helpt is als de visie van een pakket op zaakgericht werken goed in een fact-sheet wordt verwerkt en als we dan een standaard pakket 'plug-en-play' kunnen gebruiken op deze manier.

Op verzoek ben ik bereid hier met gebruikers en leveranciers over door te spreken.

• ‹ Vorige
• 1
• 2
• Volgende ›
• Pagina