Gister las ik in Proces en Document van maart een beknopt artikel van Keller en Roovers. Het onderzoek is bijna klaar enwordt volgende week gepresenteerd. Een stukje uit dit artikel met de kop DSP roept bij mij wat vraagtekens op.

 

Quote

In een zaaksysteem worden de verschillende zaaktypen en al hun specifieke kenmerken (zoals wettelijke en streefdoorlooptijd, bewaartermijnen et cetera) opgeslagen in één centrale 'bibliotheek', de zogeheden zaakttypecatalogus.

[tot zover niets nieuws maar dan...]

Zo'n ZTC heeft weliswaar raakvlakken met een DSP, maar is niet hetzelfde; een DSP is een statische, passieve ordeningsstructuur voor (fysieke en digitale) documenten, terwijl een ZTC tevens als een 'actief' metamodel fungeert.

 

de vraagtekens:

- Als een DSP een statische passieve ordeningsstructuur is, hoe kan deze dan verbonden zijn aan midoffice-systemen?

- Een tool die ik ken voor DSP - de I-Navigator - bevat ook de ZTC en wordt gebruikt om documentstromen in goede banen te leiden. In een digitale omgeving ordenen we steeds meer aan het begin van de lyfecycle van documenten. Wat is daar nog  'statisch' aan?

- Als in een zaaksysteem ZTC en DSP samen komen, waarom zou je deze dan niet integreren?

 

Ik moet eerlijk bekennen dat ik de theorie van Keller nog niet gelezen heb, maar ben benieuwd hoe jullie tegen deze quote aankijken.

 

Weergaven: 1386

Berichten in deze discussie

Hierbij mijn visie:

 

- Als een DSP een statische passieve ordeningsstructuur is, hoe kan deze dan verbonden zijn aan midoffice-systemen?

Volgens mij is een DSP vooral verbonden aan een DMS. Deze zit steeds vaker in de midoffice. Zodoende is er een relatie, alhoewel deze beperkt is.

- Een tool die ik ken voor DSP - de I-Navigator - bevat ook de ZTC en wordt gebruikt om documentstromen in goede banen te leiden. In een digitale omgeving ordenen we steeds meer aan het begin van de lyfecycle van documenten. Wat is daar nog  'statisch' aan?

Volgens mij heb jij het hier al over een ZTC. De I-navigator is ook geen echte DSP tool meer, maar meer een ZTC tool. Met de ZTC ordenen we niet aan het begin van de lyfecycle van documenten, maar aan het begin van een proces (lees: zaak). Documenten binnen deze zaken vallen onder het archiefregime van het betreffende zaaktype.

- Als in een zaaksysteem ZTC en DSP samen komen, waarom zou je deze dan niet integreren?

Volgens mij gebeurt dit al overal. De DSP kenmerken zijn dan over het algemeen statisch (veranderen niet door de uitkomst van het proces), en de ZTC (bv. van GEMMA) zijn afhankelijk van hoe het proces verloopt (bv. het resultaattype beïnvloed de archieftermijnen)

Nog een kleine aanvulling, een DSP is organisatiebreed en procesgericht, een ZTC is vaak niet dekkend.

Het DSP was vanaf 2004 tot de nieuwe archiefregeling verplicht. Het feit dat die veelal niet werd en is aangeschaft, spreekt m.i. boekdelen. VHIC heeft met de I-navigator een product opgeleverd, dat door de combinatie DSP/ZTC wel aan de behoefte voldoet. Uiteraard kan er ook een andere keuze worden gemaakt, door b.v. de ZTC uit te bouwen.

Meer weten, lees het artikel van Frans Dondorp in het OD van april 2010, quote:


 

Het DSP komt voort uit het archiefrecht en heeft ordening als

basis. De ZTC komt voort uit dienstverlening en heeft de behandeling

van een zaak als basis. Het DSP is gericht op processen; de

ZTC op zaaktypen (processen waarvan de doorlooptijd bewaakt

moet worden en die een documentaire neerslag hebben).

6

 

Ik zie nu pas deze discussie en wil er toch even op reageren. Ik zie dat in de praktijk de termen DSP en ZTC vaak door elkaar gebruikt worden. Soms maakt men een verschil. Zo spreekt men ook wel over het ZTC als dat onderdeel van GEMMA en het DSP als de lokale invulling daarvan (al dan niet gebruik makend van het model-DSP en/of de iNavigator).

 

In de toelichting op het ZTC door KING staat een hele paragraaf over de relatie tussen het ZTC en het DSP. Ik citeer hieruit:

"Het zaaktype heeft niet alleen een functie in de midoffice, maar is tegelijk de basis voor de structuur op het gebied van digitale archivering. (...) Archiefwettelijk bezien vormt deze combinatie van zaaktype, resultaattype en VNG-bewaartermijn de basis voor het DSP (Documentair Structuur Plan). Gemeenten mogen zelf, al naar gelang hun behoefte op dit punt, nog veel meer gegevens vastleggen (trefwoorden, archiefcodes, enz.) maar dit hoeft niet. Het is ook aan gemeenten zelf om te bepalen of zij vervolgens het beheer van de aldus vastgestelde zaakmetadata, naast in een zakenmagazijn, ook nog eens in een apart metadata- beheer-instrument willen vastleggen."

Is het hier nog niemand opgevallen dat dit geheel een Keller-show is geworden? Deze discussie is volledig semantisch. Stel een lijst op met wat je softwarepakket moet kunnen en kijk wat er in de markt is. Wat maakt het uit of het ZTC of DMS heet. En al helemaal dat belachelijke idee van de midoffice (idd: Keller). Zelfs de VNG kan het niet beter determineren als 'iets tussen de front-en backoffice waar veel data in staat'. nou nou.

In de archiefwet is juist de term DSP weggehaald omdat het om het principe gaat, niet om hoe je het noemt.

Nog erger, ik heb vernomen dat gemeenten met een goed functionerend DMS een 'zaaksysteem' krijgen aangesmeerd door leveranciers, wat dat was 'echt wat anders'. Juist. Zou ik ook zeggen als leverancier.

Noem het een ZTC, DMS of Midoffice en zeg dat het de bestaande systemen aanvult.

Van de Keller-site:"Er zijn maar liefst 3 enquêtes gehouden onder meer dan honderd leveranciers".

De leveranciers (die meneers congres ook sponsoren) weten natuurlijk veel beter wat de klant wil dan de klant zelf.

Ik zou zeggen, ga om functionaliteiten vragen en stop met die belachelijke terminologie-discussie.

Volgens mij sla je de plank hier volledig mis Lourens.

 

Fora als BREED zijn er juist om samen, openbaar met gebruikers, adviseurs en leveranciers te praten over dergelijke vragen en onduidelijkheden. Prima als je een andere mening hebt, maar zelf ga je ook volledig mee in de semantiekdiscussie door een opmerking als "ga om functionaliteiten vragen...", ook dat is namelijk maar terminologie.

 

En-publiek afgeven op iets zonder iets concreets bij te dragen heeft m.i. geen toegevoegde waarde.

@Sven mij is duidelijk waar Breed voor is, ik ben niet voor niets lid geworden. Mijn advies is (dan ook) om je niet blind te staren op de terminologie, die mijns inziens de gemeenten bakken met geld kost. Dat heb ik hierboven ook duidelijk proberen te maken. De onduidelijkheden worden volgens mij door mn mensen als Wouter Keller in stand gehouden.

Nee, 'functionaliteiten' is een verwijzing naar het 'kunnen' van iets. Dat is geen semantische discussie over wat wél onder een term valt en wat precies niet. Dat is mensen vragen na te denken over wát hun softwarepakket precies moet kunnen. Dit om te voorkomen dat (zoals ik in het voorbeeld aangaf) meerdere systemen met grote overlap aan functionaliteiten worden aangeschaft omdat men het (in mijn ogen dus) semantische verschil niet begrijpt.

Ter vergelijking: iemand rijdt in een lada. Die is gekocht om van a naar b te kunnen rijden. Dan komt de verkoper van een Mercedes langs. Die verteld dat de Mercedes niet gewoon een auto is om van A naar B te rijden, maar om je in luxe van A naar B te vervoeren. Vervolgens beweert hij/zij dat het vervoeren van A naar B heel wat anders is dan van A naar B rijden. Door deze verwarring koop je uiteindelijk óók de Mercedes.

Dat jij dit geen toegevoegde waarde aan de discussie vind, vind ik jammer. Ik geef af op iets dat in mijn ogen (en hierboven uitgelegd) schade doet aan het efficient opereren van (lokale) overheden. Dat is mijn vakgebied, daar ben ik toe opgeleid. Ik hoop dat anderen daar wél hun voordeel mee doen. Vandaar mijn post hier, op een publiek forum.

@ Lourens,

 

e.e.a. is een stuk duidelijker zo. Dank voor je uitleg en inhoudelijke onderbouwing. Ben het grotendeels met je eens! Ik heb persoonlijk wel het gevoel dat de overheid zelf steeds kritischer aan het worden is en niet meer klakkeloos alles overneemt van externen, dus wat dat betreft gaat het m.i. de goede richting op!

 

Gr Sven

RSS

© 2024   Gemaakt door Marco Klerks.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden