BREED - over de grenzen van informatie
NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER
Relatie ZTC, PDC en UPL
Zomaar iets dat in mij opkwam. Onderstaande formuleringen uit het document van KING 'Gemma Zaaktypecatalogus 2.0' in ogenschouw nemende, vraag ik me af wat nog de meerwaarde is van een PDC of de in ontwikkeling zijnde landelijke UPL (Uniforme Producten Lijst). En in het verlengde daarvan: waarom de leverancier van een DSP nog streeft naar integratie (van ZTC) met PDC?
Citaat:
...en kan hiermee de ZTC worden gedefinieerd als “een lijst van gemeentelijke producten, die als 'zaken' worden afgehandeld met de relevante verbindingen, objecttypes en attribuutsoorten ten behoeve van besturing en monitorring van het proces en bewaren en beheren van de zaak”.
Op middenlange termijn zal de zaaktypecatalogus een bepalende functie hebben ten behoeve van de DSP en de PDC. Dit wil zeggen dat de gemeenten kunnen uitgaan van één leidende catalogus om structuur en validatie aan te brengen in de zaaktypes die men aanbiedt aan burgers, bezoekers en/of bedrijven/instellingen. De gemeenten hebben hierdoor de mogelijkheid om de gevalideerde lijst aan te bieden aan de leveranciers van een PDC en/of een DSP, waardoor de standaard hoeveelheid juiste zaaktypes gebruikt worden ten behoeve van de dienstverlening.
Berichten in deze discussie
-
Permalink Antwoord van Yvonne Welings op
-
Dag Oliver, er zou inderdaad veel behoefte zijn aan een dergelijke aansluiting. Vooral gemeenten die voor de alleen voor ZTC kiezen lopen daar tegen aan.
-
Permalink Antwoord van Oliver Labatzki op
-
Je hebt gelijk, Yvonne. Zolang KING, wellicht terecht, het standpunt bezigt dat andere partijen zoals leveranciers van PDC en UPL beter zijn toegerust om de content te leveren en structureel te beheren zal een echte samensmelting van PDC, ZTC en UPL wel niet tot stand komen. Toch lijkt het vanuit het oogpunt van beheersbaarheid en consistentie onverstandig om aan drie product(referentie)lijsten vast te houden.
-
Permalink Antwoord van Remco van Beek op
-
Ik sluit me aan bij jouw opmerking, Oliver. Het lijkt erop dat wat wordt beoogd met de GEMMA catalogus (in dit geval het component van standaardisatie, al is het bovenliggende doel natuurlijk dienstverlening), bij KING zelf met andere programma's nog niet goed vlot. Dit kan niet worden geschaard onder het mom van content, want het zijn drie verschillende aspecten. Waarom levert eenzelfde instantie dan nog een losse UPL?
Bovendien zijn ze complementair, door een focus intern (ZTC is landelijk vastgesteld en benoemt zaaktypen en parameters voor interne afhandeling) en extern (PDC komt bij leveranciers vandaan en richt zich op een beschrijving van de dienst aan de klant). Door de verrijking van de ZTC zie je - mits goed toegepast en ingebed - dat een DSP kan komen te vervallen of in ieder geval niet meer hoeft te worden afgenomen. Een rijk, extern onderhouden DSP zoals van Sdu kan meerwaarde bieden door deze de ZTC te laten voeden. Het lijkt me dan ook goed dat vanuit Samenwerkende Catalogi de GEMMA lijst wordt omarmt.
-
Permalink Antwoord van Rudy Kaptein op
-
Ik denk dat bovenstaand citaat binnen het juiste perspectief moet worden geplaatst . Waar het in het kader van de ZTC 2.0 feitelijk om gaat is een lijst van benamingen voor alle dienstverlenende zaaktypen, maar ook niet meer dan dat, dus niet de attributen die bij elk zaaktype horen, of, in PDC termen, de teksten die je per product beschikbaar wilt hebben. Op het moment dat die lijst kwalititatief goed is, heeft deze uiteraard een bepalende functie voor PDC en DSP, omdat het een goede beschrijving biedt van de dienstverlenende werkprocessen / producten die er zijn. Maar dan blijft het punt dat de bijbehorende teksten en DSP/ZTC attributen nog bepaald moeten worden.De UPL is in dat opzicht niet meer dan een lijst met voorkeurstermen voor (gemeentelijke) producten en diensten, terwijl nu door de verschillende leveranciers van PDC's en in zelf ontwikkelde PDC's verschillende termen worden gebruikt. Idealiter is deze lijst met benamingen makkelijk te vertalen / over te nemen voor de uniforme benamingen van zaaktypen.Een aandachtspuntspunt is natuurlijk wel de vertaling van product naar zaaktype, want is die verbinding altijd 1-op-1 te maken? Wanneer ik bijvoorbeeld in de UPL kijk dan zie ik daar het product Hondenbelasting. Kijk ik vervolgens in de zaaktypencatalogus dan kom ik daar de zaaktypen Aanmelding hond en Afmelding hond tegen. De verbinding tussen producten/diensten en zaaktypen hoeft dus niet altijd een-op-een te zijn, dus daar moet rekening mee worden gehouden.Het is dus niet zo dat met de oplevering van de Gemma ZTC 2.0 de integratie van PDC en ZTC zomaar gerealiseerd is, bovendien zal er altijd sprake kunnen zijn van lokale keuzes tav producten en zaaktypes (bijvoorbeeld de vraag: 1 product/zaaktype voor voor WMO voorzieningen, of meerdere, opgesplitst naar soort voorziening. Of op de website 1 product hiervoor, maar intern meerdere zaaktypes omdat de wijze van afhandeling sterk kan verschillen)Hoe dan ook, vanuit het model-DSP / i-Navigator en de VIND PDC zijn wij bezig om de onderlinge afstemming te realiseren tussen beide producten. In eerste instantie op bescheiden schaal, door in de i-Navigator per werkproces/zaaktype aan te geven met welk(e) product(en) hierop van toepassing zijn en in de VIND pdc de bijbehorende werkprocessen/zaaktypes te benoemen. Ook zijn we op dit moment al bezig met de integratie met de PDC van een andere leverancier. In de toekomst willen we komen tot een geintegreerde beheeromgeving, waarin alle content van DSP/ZTC/PDC in samenhang kan worden beheerd en waarbij updates van de modelmatig beheerde content in model-DSP of VIND volledig op elkaar zijn afgestemd.De UPL gaat in elk geval ook in het model-DSP / i-Navigator verwerkt worden, waarbij de keuze aan de gemeente gelaten wordt om de UPL naam als centrale kernomschrijving voor het werkproces/zaaktype over te nemen, of als referentiebenaming naast de al bestaande benaming van het werkproces. Intergemeentelijke standaardisatie is tenslotte een goede ontwikkeling en is ook altijd het uitgangspunt van het model-DSP geweest.
-
Permalink Antwoord van Mart Mommers op
-
@Rudy waarom moeten PDC en UPL nog naast elkaar blijven bestaan als ze elkaar grotendeels overlappen? Wat is jouw mening? Bovendien: volgens het concept ZTC 2.0 presenteert de ZTC zich als een lijst van gemeentelijke producten waarmee het totaal van het aantal productenlijsten op drie (of vier) komt (ZTC, PDC, UPL en misschien zelfs VIND). Is dit niet een beetje veel van alles? Lijkt toch een stuk efficiënter te kunnen? Ik zie daar bovendien ook, of misschien zelfs met name, een rol weggelegd voor GEMMA!
-
-
De UPL is een lijst met voorkeursbenamingen van gemeentelijke producten en diensten, zonder aanvullende gegevens. In een PDC wordt veel meer informatie vastgelegd met beleidende teksten, omschrijvingen, verwijzingen etc..Op eenzelfde manier is de ZTC 2.0 ook niet meer dan een lijst met benamingen van zaaktypen (in het citaat staat dit inderdaad benoemd als een lijst van gemeentelijke producten, maar ik zou het toch echt zaaktypen willen blijven noemen om de verwarring te voorkomen) en een instructie van welke metagegevens vervolgens over/bij deze zaaktypen zou moeten worden vastgelegd. En ook de ZTC 2.0 maakt gebruikt van de voorkeursbenamingen uit de UPL. Maar zoals gezegd, een PDC lijst komt over het algemeen niet 1-op-1 overeen met een lijst dienstverlenende zaaktypen, daartussen is een verbinding nodig. Mogelijk gaan de lijsten verder naar elkaar toe groeien, maar omdat het doel van een pdc (overzichtelijke informatieverstrekking richting klant) duidelijk anders is dan een zaaktypecatalogus (inrichting zaaksysteem) denk ik dat dit niet volledig gaat gebeuren.Ik had overigens even gemist dat de UPL definitief is geworden, maar hier is versie 1.0 te vinden:
-
-
Jouw uitleg is helder, toch blijft het gevoel, en je bevestigt dat ook min of meer (lijsten gaan naar elkaar toe groeien) dat lijsten geïntegreerd kunnen worden.
-
Permalink Antwoord van Rob Haans op
-
Het is goed te zien dat het ZTC nog niet geheel geïntegreerd is in het model-DSP: de procesinformatie staat los van de zaaktype, de GEMMA procesarchitectuur wordt genoemd onder Zaaktype en niet onder werkprocesinformatie, resultaattypen staan genoemd onder archivering, terwijl m.i. dit juist samenhangt met het zaaktype, etc. Het ZTC is nu teveel een apart tabje binnen het model-PDC.
-
-
Volgens mij valt het eigenlijk wel mee: centraal uitgangspunt is dat de zaaktypen hetzelfde object zijn als de model-DSP werkprocessen, waardoor de vraag op welk tabblad de verschillende ZTC en DSP gegevens staan niet zo heel belangrijk meer is (afgezien van het oogpunt van usability). Wat we wel gedaan hebben is alle gegevens die vanuit de Gemma ZTC zijn overgenomen opgenomen zijn op het tabblad zaaktype.
-
-
Ik ben ook een logica-freak: de tabjes moeten in mijn ogen logisch zijn en een correcte samenhang geven aan metagegevens en niet omdat er iets van Gemma overgenomen is. Dat gaat verder dan usability.
Rudy Kaptein zei:Volgens mij valt het eigenlijk wel mee: centraal uitgangspunt is dat de zaaktypen hetzelfde object zijn als de model-DSP werkprocessen, waardoor de vraag op welk tabblad de verschillende ZTC en DSP gegevens staan niet zo heel belangrijk meer is (afgezien van het oogpunt van usability). Wat we wel gedaan hebben is alle gegevens die vanuit de Gemma ZTC zijn overgenomen opgenomen zijn op het tabblad zaaktype.
Partner(s)
Sponsor(s)
Direct naar...
© 2024 Gemaakt door Marco Klerks.
Verzorgd door
