BREED - over de grenzen van informatie
NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER
Projectmatig werken - Zaakgericht werken
Bij de gemeente Hillegom is de vraag ontstaan hoe om te gaan met projectmatig werken en daarbij zaakgericht werken. Bestaat een project uit meerdere zaken of moet dit worden gezien als 1 zaak. In mijn beleving is een project meerdere zaken omdat je ook met verschillende werkprocessen te doen hebt. De zaken link je aan de projectrtegistratie. Hoe denken jullie daar over?
Berichten in deze discussie
-
Permalink Antwoord van Bart van Oerle op
-
Het blijft lastig om dat op een goede, voor de eindgebruiker werkbare manier in een zaaksysteem op te slaan.
Maar volgens mij heb je helemaal gelijk! De beste manier is (als het systeem het toelaat) een projectregistratie maken en daaraan verschillende project gerelateerde zaken koppelen.
-
Permalink Antwoord van Marloes Gutteling op
-
In Helmond hebben wij voor Verseon de projectmodule aangeschaft. Dit is een kleine uitbreiding op Verseon waarbinnen je gemakkelijk projecten kunt registreren en daaraan zaken kunt koppelen. Wanneer je een zaak koppelt aan een project maak je tevens de keuze voor een bepaalde categorie (bijv. fase van het project). Hierdoor ontstaat in je werkvoorraad een duidelijk overzicht van het project, de fases en de zaken binnen elke fase.
Wij werken ook met het principe dat aan een project meerdere zaken gekoppeld kunnen worden.
-
Permalink Antwoord van Marco Klerks op
-
In Den Bosch hebben wij ervoor gekozen om juist niet met de projectenmodule van Verseon aan de slag te gaan. Een hoop toeters en bellen, die net niet doen wat je precies wilt en die zoveel veldjes en knoppen omvatten dat het voor de gebruiker niet makkelijker wordt. Ook voor het applicatiebeheer zijn die modules ronduit vervelend, want alle documentatie moet aangepast worden, het change- en testmanagement wordt complexer, de verwachtingen van de gebruiker rijzen de pan uit (maatwerk) en het systeem kan er alleen maar instabieler van worden.
Wij houden het liever simpel. Een projectleider kan een zaak aanmaken en kan daarin documenten opslaan. Bij een complex project kunnen er deelzaken worden gekoppeld. De hoofdzaak heeft dan projectdocumenten als de business case, planning, etc. Als het project klaar is, sluit je de zaak.
Wij hebben overigens dit besluit genomen samen met de projectleiders van de ruimtelijke projecten. Kritisch volk met doorgaans hoge verwachtingen. Aanvankelijk hoopten zij op uitgebreide functionaliteiten, maar na enige discussie bleek dat iedereen iets anders nodig had of wilde, snapten ze het zelf ook niet meer en wilden ook zij terug naar de basis.
Tip: Wij gaan wel werken met verschillende project-zaaktypen. Zo kunnen wij verschillen maken in bewaartermijnen, sjablonen, proces-eigenaar, etc. Denk aan bijvoorbeeld: ruimtelijke projecten, ICT-projecten, sociale projecten, etc. We hebben hier nog geen lijstje van.
-
Permalink Antwoord van Martin Jansen op
-
Als ik een en ander zo lees lijkt me de werkwijze van @Marco heel geschikt. Is een project niet gewoon een (joekel van een) zaak? Een hoofdzaak met meerdere deelzaken, vervolgzaken ed? Zelfs de verslagen van projectgroep (deelgroepen) zou je toch als een (permanent te bewaren) zaak kunnen zien? Een beetje flexibel met zaakgericht werken omgaan (en niet elke weer op die definitie terugvallen van een zaak, dat is een van tevoren gedefinieerde etc. etc. ) en dat is toch als zodanig in te richten? Eén standaard voor projectgewijs werken? Met een standaard fasering daarvan? En daar dan de archivering op afstemmen? Daar waar die standaard er wel is en er ook in de dagelijkse praktijk op die wijze gewerkt wordt: Chapeau! Vooralsnog geloof ik in het flexibel omgaan met projecten binnen het ZGW en het daar op afgestemde archiveren. Is een project -vaak- niet gewoon het (tijdelijk, buiten de staande organisatie om, met een aparte pot geld) 'aansturen' van 1 of meerdere zaken. Waarbij de verantwoording netjes vastgelegd wordt en bewaard blijft; in een 'verantwoordingszaak'? Zo zou ik het trachten te regelen ....
-
Permalink Antwoord van Rob Haans op
-
Projecten zijn een wijze van uitvoeren van werk en zijn net zo breed als zaken. Sterker nog, iedere zaak kan als een project uitgevoerd worden. Een projecttype als het aanleggen van wegen is gewoon een publiekrechtelijke taak met een fysiek product (de weg) ipv een besluit en die zin gewoon een zaaktype. Dit laatste geval is vaak wel erg groot qua aantallen documenten, waardoor vele deelzaaktypen kunnen ontstaan, die vaak privaatrechtelijk van aard zijn (bijv. aangaan van een contract, maar soms ook publiekrechtelijk (bijv. Onteigenen).
Mijn advies: Maak een overzicht van projecttypen die je wil onderscheiden, zoals Marco al doet en voeg die gewoon als zaaktype toe (als er al niet een toepasselijk zaaktype bestaat).
-
Permalink Antwoord van Hans Donck op
-
Projecten en zaken zijn verschillende dingen, als je kijkt naar de definities van 'zaak' en 'project'.
Het is natuurlijk mogelijk je ondersteunende zaaksysteem (want daar gaat het waarschijnlijk hier om) zo in te richten dat je er ook een project in kunt vangen. De verschillende mogelijkheden zijn al door anderen genoemd.
Het is wel nodig om de beperkingen van een zaaksysteem te kennen en functionele of technische oplossingen te zoeken voor je projectbeheer. Zonder plan vooraf hoe je projectonderdelen in je zaaksysteem gaat plaatsen gaat het geheid mis:
- ad hoc zoeken gebruikers hun eigen oplossing;
- gebruikers raken gefrustreerd, omdat ze niet kunnen wat ze willen;
- het beheer van de ad hoc-oplossingen kost veel menskracht;
- het is na een aantal jaren onmogelijk te achterhalen wat een ad hoc-oplossing geweest is, of wat een bepaalde manier van registreren betekende. Je hebt dan iets, maar weet niet wat je hebt.
Dus: bezint eer ge begint!
-
-
Definitie van een zaak: ‘een hoeveelheid werk met een welgedefinieerde aanleiding en een welgedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden’
De term project kan op verschillende wijze worden gedefinieerd (wikipedia):
- Een onderneming waarbij de inzet van mensen, materiaal en financiële middelen opnieuw is georganiseerd met als doel om een bepaalde hoeveelheid werk, of een specifieke opdracht te realiseren, begrensd door tijd of geld, en die leidt tot een in kwalitatief of kwantitatief opzicht gunstige verandering.[1]
- Een project is een tijdelijke managementomgeving die is gevormd met als doel om één of meer businessproducten voor een specifieke business case te leveren.[2]
- Een project is een unieke opgave, begrensd in tijd en middelen en afgesloten met een projectresultaat.
- Een project is een tijdelijke inspanning met als doel het creëren van een uniek product of een unieke service.[3]
- Een project is een geheel van activiteiten om in een tijdelijke organisatie binnen gestelde condities een vooraf gedefinieerd resultaat te bereiken.[4]
Een "project" wordt ook gebruikt om de organisatie om een uitvoering van werk te beschrijven, dat zorgt voor verschil in definitie. Maar voor de rest is een project een geheel van activiteiten gericht op de uitvoering van een van tevoren gedefineerd resultaat. En dus weinig anders dan een zaak.
-
-
Ik had niet moeten verwijzen naar de definities, maar naar de praktijk.
Een zaak is één proces, waarin één vastgelegd pad doorlopen wordt - meestal ook met een vastgestelde tijdsduur. Zaaksystemen kunnen dat prima aan en geven meerwaarde door standaardisatie van het proces, behandelaars/afdelingen en doorlooptijden.
Een project waaiert vaak uit in allerlei deelprojecten, van tevoren is niet altijd te zeggen welke behandelaars/afdelingen op enig moment betrokken zijn, de tijdsduur heeft een grotere bandbreedte enz.
Een project kan best in een zaaksysteem gemanaged worden. Maar niet ieder project kan zonder meer in een zaaksysteem gezet worden. Van tevoren moet duidelijk zijn wat en hoe handelingen en stappen vastgelegd worden.
Want de centrale vraag is: waarom wil je een project in een zaaksysteem vastleggen?
-
-
Je hebt gelijk dat veel projecten maar in beperkte mate te ondersteunen zijn met een zaaksysteem, maar dat geldt in mijn ogen ook voor veel zaken. Afhankelijk van de gestructureerdheid van de zaak/project (een project kan ook heel erg gestructureerd verlopen, zie bijv. prince2) kies je de mate van structurering van de ondersteuning ervan met een zaaksysteem. Een zaaktype dat in de organisatie (bewust) flexibel/grillig/ad hoc uitgevoerd wordt, moet je niet met 6 statusovergangen en allerlei standaard documenttypen gaan "ondersteunen".
Hans Donck zei:Ik had niet moeten verwijzen naar de definities, maar naar de praktijk.
Een zaak is één proces, waarin één vastgelegd pad doorlopen wordt - meestal ook met een vastgestelde tijdsduur. Zaaksystemen kunnen dat prima aan en geven meerwaarde door standaardisatie van het proces, behandelaars/afdelingen en doorlooptijden.
Een project waaiert vaak uit in allerlei deelprojecten, van tevoren is niet altijd te zeggen welke behandelaars/afdelingen op enig moment betrokken zijn, de tijdsduur heeft een grotere bandbreedte enz.
Een project kan best in een zaaksysteem gemanaged worden. Maar niet ieder project kan zonder meer in een zaaksysteem gezet worden. Van tevoren moet duidelijk zijn wat en hoe handelingen en stappen vastgelegd worden.
Want de centrale vraag is: waarom wil je een project in een zaaksysteem vastleggen?
-
-
De centrale vraag die Hans stelt is terecht. De vraag van deze discussie is hoe zaken en projecten aan elkaar gerelateerd dienen te worden, wat de verhouding is tussen zaken en projecten. Daarvoor moet je inderdaad afvragen wat de scope is van zaakgericht werken binnen je gemeente. Je kúnt zaakgericht werken "oprekken" en zo ook projectmatig werken er onder laten vallen, want in essentie zijn het vergelijkbare begrippen. Maar of je dat wil doen is een eigen keuze en afhankelijk van de manier waarop projectmatig en zaakgericht werken ingevuld wordt binnen je organisatie.
-
-
Er zijn hier heel zinnige opmerkingen gemaakt. Ter illustratie uit de praktijk over de archivering en terugvindbaarheid van documenten:
De organisatie waar ik werk maakt de keuze projecten in teamsites (Sharepoint) te beheren, en daarnaast een dms-rma oplossing te nemen (ook Sharepoint) voor beleidsprocessen.
Projectbeheer in teamsites geeft de gebruikers maximale vrijheid.
Registratie van beleid in een dms-rma geeft de beleidsondersteunende afdelingen maximale beheersmogelijkheden.
Het verplaatsen van documenten van de projectomgeving naar de dms-rma omgeving is eenvoudig.
Het belangrijkste issue op dit moment is de identificatie van te bewaren documenten in de projectomgeving. Ik denk aan criteria als: definitieve documenten; bepaalde mappen of kenmerken; een knop waarmee gebruikers ana kunnen geven dat het een belangrijk document is, .... De overige documenten worden na afloop van het project (of na X jaar) vernietigd.
Als de criteria in een richtlijn aan gebruikers gecommuniceerd worden, hoop ik dat bij het projecteinde de projectleider een bruikbare selectie van belangrijke/te bewaren documenten uit de projecteamsite zal leveren. HIer hebben we nog geen ervaring mee.
-
Permalink Antwoord van Alex Van Heugten op
-
Weliswaar een ouder topic, maar de laatste oplossing klinkt als iets dat we hier eveneens zouden willen.
@Hans; Is dit delen van docs via teamsites en het DMS iets dat binnen jullie organisatie is ingericht?
- ‹ Vorige
- 1
- 2
- Volgende ›
Partner(s)
Sponsor(s)
Direct naar...
© 2024 Gemaakt door Marco Klerks.
Verzorgd door
