Hoe past product in Dienstverlening & Output

[DieterDePaepe]

Product is een term gebruikt binnen AIV. Dienstverlening en Output staan in het model en zijn afkomstig van CPSV.

Sommige producten zouden echter niet duidelijk hierin passen. Sommige producten kunnen meermaals geconsumeerd worden, terwijl dienstverlening kan gestart worden zonder dat er een Output bekend is. Er moeten enkele voorbeelden hiervan gezocht worden. Er moet een goede beschrijving komen van elk van de termen.

[HenkV]

Bij een dienst is er in principe altijd een interactie met een externe factor, een klant (kan intern of extern zijn) en bij een dienst vallen als het ware de consumptie en de productie samen. Een dienst kan leiden tot een product, maar het kan ook zijn dat er uiteindelijk geen product geleverd wordt (= geen resultaat). Ik vind het dan ook handig om van output te spreken (zoals bij CPSV), omdat men dit flexibel kan invullen. Output is dus een vrij generieke klasse, ook de invulling door CPSV is zeer ruim. Dienst en product zou men kunnen zien als specialisaties van output. Hierbij een poging om het verschil tussen dienstverlening, output, dienst en product te duiden op basis van enkele voorbeelden.

Dienstverlening (volgens definitie CPSV) Output (CPSV: Outputs can be any resource - document, artefact – anything produced by the Public Service.)

Voorbeeld 1 Dienstverlening --> Geo Informatie aanleveren
Output --> Een product de webservice GeoInformatie. Het is een product omdat de consumptie x maal kan plaatsvinden nadat de webservice in productie komt.

Voorbeeld 2 Dienstverlening -->Aanvraag voor financiële ondersteuning Output --> Opstarten van een dienst waarbij in overleg met de burger gekeken wordt wat de mogelijkheden zijn. Het resultaat van deze dienst kan zijn dat de burger recht heeft op bv. 2 producten: een financiële ondersteuning voor de huur van een woning en een studietoelage voor de kinderen. De output van de dienst is dus een document met de beschrijving van de rechten waarop de burger op basis van zijn gegevens recht heeft. Beide producten moeten (apart) aangevraagd worden. (In some cases, the Output of one Public Service will be used as evidence to fulfil a criterion requirement of another Public Service. Such relationships should be described in the associated Rule(s).)

Voorbeeld 3 Dienstverlening --> Aanvraag vergunning x Output -->Product: vergunning x

[dhaeneth]

Wil dat dan zeggen dat je in vb2 de dienst as such niet concreet opneemt? Je heb de dienstverlening (PS) 'Aanvragen financiële tegemoetkoming' (vb gesprek bij OCMW). Output is dan enkel dat document met rechten (dat in een ideale situatie volstaat als bewijsstuk voor x #PS'en).

[HenkV]

De ‘public service’ (dat is de dienstverlening naar buiten toe) triggert in dit geval het opstarten van een (interne) dienst die zorgt voor de behandeling van de vraag van de burger en zorgt voor de output, in dit voorbeeld een document. De dienst, moeten we wel ergens registreren, alsook de interne diensten die niet publiekelijk getriggerd worden. De relatie tussen dienst en publieke dienst ontbreekt nog, alsook de relatie tussen product en output. Ik denk dat men de ‘public service’ als een specialisatie kan zien van een algemene klasse ‘service’ (dienst).

[dhaeneth]

En dan praten we op dat moment over een verschillend applicatieprofiel - waar CPSV-AP zich enkel focust op het 'generieke naar buiten toe' (de catalogus-functie) zetten we hier de stap naar de afname van een concreet aanbod van actor (vb. ocmw). Dat zijn dus drie zaken : het generieke aanbod (à la IPDC), het concrete aanbod (niveau OCMW - nog niet gemodelleerd) en de afname.

De 'dienst' waar je het hier over hebt, hoort thuis in het concrete aanbod, evenals het Product.

De concrete afname is dan eigenlijk het niveau van transactie (waar bvb. DOSIS kan gepositioneerd worden).

(nvdr. De ideeën gaan vandaag naar een holistische benadering van die drie in de vorm van het Dienstverleningsregister).

De 'interne diensten' waar je naar verwijst, zijn het domein van het procesgebeuren.

[HenkV]

dhaenth schreef: "De 'dienst' waar je het hier over hebt, hoort thuis in het concrete aanbod, evenals het Product." --> De dienst kan naast het concrete aanbod kan ook een dienst zijn die bijvoorbeeld ondersteunend is zonder output naar buiten. Daarom kan men niet zomaar spreken van 'het concrete aanbod'.

Algemeen: we zijn nu bezig met een applicatieprofiel die zich focust naar het 'generieke naar buiten toe', zonder eerst het hele plaatje in beeld gebracht te hebben. Normaal moet men toch eerst een core voacabulary opstellen voor het geheel en dan voor de verschillende bereiken/applicaties een applicatieprofiel opstellen. We moeten toch eerst die basisconcepten goed krijgen!

[DieterDePaepe]

Ik heb wat moeite om deze discussie te interpreteren, wellicht door gebrek aan kennis over het verloop van diensten bij de overheid en de termen die overal worden opgeplakt.

@HenkV: ik vermoed dat je het onderscheid tussen het concept PubliekeDienstverlening (een beschrijving van de mogelijkheid om de dienst aan te vragen) nog wat aan het verwarren bent met specifieke instanties ervan (een aangevraagde dienst waar een werkproces voor in gang is gezet). Bij het eerste zal er altijd dezelfde output zijn, als aanduiding dat dit een mogelijke output is. Bij het tweede zal het resultaat van de dienst (ik vermijd nu de term output) afhangen van het verloop ervan.

Natuurlijk zijn er ook diensten die niet PubliekeDienstverlening zijn, is je voorstel om deze ook mee te nemen in het model? Het triggeren van deze (publieke) diensten is wel buiten scope van het huidige project, maar hoort in het proces model dat Thomas reeds vermeldde.

Ik weet ook niet of een webservice hoort gezien te worden als dienstverlening. Het lijkt wel in de definitie te passen, maar de gelinkte entiteiten houden veel minder steek vind ik.

[jensscheerlinck]

Intussen is er ook werk verricht aan een model om de "afname/consumptie" van publieke dienstverlening door een specifieke consument (burger, ondernemer, publieke organisaties) te modelleren: OSLO Dienst Transactiemodel.

Deze issue wordt bijgevolg gesloten.