Dit is de multi-page printable view van deze sectie. Klik hier om te printen.
Welkom bij de Pronto Lectures. Op deze pagina vindt u niet alleen documentatie van Pronto maar in de toekomst ook opnames van mini-colleges van de bedenkers van Pronto.
graph LR
2005 -- Bert Noorman --> Need{"What is the essence of it all"}
1993 --Adosh van der Heijden --> Need{"What is the essence of it all"}
graph LR
2006 -- Bert and Adosh collaborate --> 2007
2006 -- Inception of Pronto --> 2007
2007 -- Pronto name adopted --> 2008
2007 -- Michael Oosterhout joins Team --> 2008
Note: Jan Dietz. Victor van Reijswoud and Hans Mulder are the founding fathers of DEMO and Enterprise Engineering
2005 Bert Noorman started the development and discovery of Pronto.
Ontstaan van de behoefte aan andere manieren van proces management, proces analyse en proces modellering.
Besef dat het houden van workshops en het maken van stroomschema’s (flow-charts, swim-lanes), procedures en werkinstructies, enz. niet vreselijk helpt.
KERNVRAAG: wat is essentieel als het om bedrijfsprocessen gaat?
Start of the Process Management Core team in Sogeti Netherlands.
Further development of the vision, content and design techniques.
Michael Oosterhout introduced the name Pronto.
Name changed from SoProAan into Pronto.
Presentation in various customer-events and conferences (BPM-Forum)
Eerste positionering t.o.v. DYA beschreven.
Start orientatie op Business Analyse.
Eerste versie whitepaper Pronto.
Opzet Kennisbank Pronto.
Bert Noorman dient gezien te worden als de grondlegger van Pronto en de eigenaar van het gedachtengoed. Bert heeft nauw samengewerkt met Adosh van der Heijden en Michael Oosterhout in de periode 2006 tot 2011 om samen Pronto uit te breiden en te verbeteren met hun gezamelijke kennis, ervaringen en kunde. Zie de Gesciedenis pagina voor meer informatie.
| Name | Current / Profile | Discription |
|---|---|---|
| Bert Noorman | … | Geestelijk vader van Pronto |
| Adosh van der Heijden | … | … |
| Michael Oosterhout | … | … |
In de periode van 2006 tot 2011 werd de ontwikkeling van Pronto actief ondersteund vanuit de business Development binnen Sogeti Nederland. In de periode na 2011 is de verantwoordelijkheid om Pronto actueel en levend te houden rond gegeven binnen de populatie van professionals.
| Name | Current / Profile | Discription |
|---|---|---|
| Pieter Veefkind | … | … |
Edzo Botjes en Ton Eusterbrock hebben zich beschikbaar gesteld om alle kennis rondom Pronto vanuit gesproken woord te vertalen naar deze website. Het doel is om de kennis en ervaring die nu opgeslagen ligt in de hoofden van de grondleggers te ontsluiten voor het brede publiek. Zodat professionals, fans en onderzoekers deze informatie kunnen vinden en raadplegen via het internet.
Het opschrijven en conserveren van de kennis voor komende generaties.
| Name | Current / Profile | Discription |
|---|---|---|
| Edzo Botjes | … | … |
| Ton Eusterbrock | … | … |
Staat voor PRoces ONTOlogie (credits: Michael Oosterhout, 2007); de naam is afgeleid van de titel van het boek ‘Enterprise Onthology’ van Jan Dietz.
Ontologie, ook wel “zijnsleer” genoemd, is een begrip uit de filosofie, vanuit de centrale vraag: “wat is (de essentie van het) zijn?”
Ofwel “De leer van het snelle begrip” (credits: Hans Mulder, 2008). Dat slaat op het doel achter Pronto: het snel kunnen begrijpen van (de essentie van) een onderneming (bedrijf, organisatie), om op basis daarvan beter te kunnen (be)sturen, besluiten en veranderen
Pronto gaat primair over accountability (en niet over responsibility).
Accountability is gekoppeld aan eindverantwoordelijkheid en eigenaarschap.
Verantwoordelijkheid vs. accountability gaat over inspanning vs resultaat of anders gezegd over het uitvoeren van taken vs de eindverantwoordelijkheid voor een goede uitvoering en een goed resultaat. Accountability omvat maatregelen vooraf (bv transacties en processen inrichten), tijdens (bv monitoring en rapportages) en achteraf (verantwoording en aanspreekbaarheid). Accountability gaat over regels maken en zaken doen, responsibility over regels volgen en dingen doen.
Een organisatorische eenheid, met een eigen ‘accountability’ (zie RACI). Accountability of eindverantwoordelijkheid (voor iets) is een centraal begrip in Pronto en wordt direct gekoppeld aan ‘ketens’ en aan eigenaarschap van o.a. transacties, processen en informatie, zie hieronder)
Een hiërarchisch boven- dan wel onderliggend domein. Een superdomein kan (spel)regels opleggen aan een subdomein, waarmee de accountability van het subdomein wordt ingekaderd (soms met maar vaker zonder aparte transactie)
graph TB;
A((Super-domein))-- regels -->B((Sub-domein))
Met een product (fysiek) of dienst (niet fysiek) wordt een klantbehoefte bevredigd. De uiteindelijke bestaansreden van een domein is, dat er klanten zijn die de aangeboden producten of diensten willen afnemen (of moeten afnemen, denk aan de overheid). Zie verder onder ‘(klant)transactie’.
De essentiële zaken in de manier waarop een onderneming (bedrijf, organisatie) haar producten en/of diensten levert aan haar klanten. Essentieel is in deze context datgene wat met en door Pronto wordt gemodelleerd: de werking en constructie van een bedrijf (onderneming).
Een transactie (eigenlijk: transactietype) is een bouwsteen van de bedrijfsvoering en een middel om het leveren van een product of dienst (aan een klant) vorm te geven. Een transactie beschrijft de samenwerking tussen 2 domeinen in termen van het op een gestructureerde manier aangaan en nakomen van wederzijdse verplichtingen (de klant heeft een eigen accountability en is in dit kader dus ook als een domein te beschouwen).
Belangrijke concepten: Een transactie heeft als basis een klant ⬄ leverancier model en is gebaseerd op het concept van prestatie / tegenprestatie. De “Pronto transactie” is een afgeleide van het begrip ‘transactie’ in het eerder genoemde boek van Jan Dietz – zie onder ‘transactiefasen’ Voor het leveren van een product of dienst bestaan in het algemeen meerdere klanttransacties naast elkaar (basispatroon, zie onder ‘klanttransactie’) elke transactie is een potentiële “eenheid van hergebruik” in verschillende ‘bedrijfsketens’ (zie ook onder ‘primair / secundair’).
Het begrip ‘klant’ is gekoppeld aan het begrip transactie (“de vragende kant”). Een klant heeft een behoefte te bevredigen (en de leverancier voorziet daar in). Een klant kan extern zijn (eindklant), maar ook intern (denk aan een transactie tussen 2 bedrijfsdomeinen). In Pronto wordt met ‘ klant’ meestal de eindklant bedoeld (zie ook ‘keten’).
Een bedrijfsproces is de procesmatige uitwerking van een transactie (1 proces = 1 transactie). Elk bedrijfsproces is (daarom) onderdeel van “de essentie”. Bij afspraak is de leverancier eigenaar van de transactie en van het bijbehorendee bedrijfsproces
Een werkproces of operationeel proces (denk b.v. ook aan een flowchart) is een meer gedetailleerde uitwerking van een (deel van een) bedrijfsproces en geen onderdeel van de “essentie” (en dus ook niet van Pronto modellering).
Bij de realisatie van een klantbehoefte spelen meestal meerdere domeinen een rol. Elke samenwerking tussen 2 domeinen heeft als basis een transactie. Er bestaat dan dus een keten van transacties, waarmee een klantbehoefte wordt ingevuld. Vergelijkbare termen: keten, waardeketen, (bedrijfs)keten, (bedrijfs)procesketen (afhankelijk van de gekozen focus).
Een klanttransactie is een transactie, die richting klant invulling geeft aan een te leveren product of dienst. Het gaat hierbij dus (vanuit het leverende domein gezien) altijd om de ‘eindklant’ (ook weer een relatief begrip!). Een klanttransactie is vanuit het domein gezien het begin van een bedrijfsketen en definieert die keten ook. Een product of dienst wordt in het algemeen vertaald in meerdere klanttransacties.
Als het product ‘schadeverzekering’ is zijn er klanttransacties (en dus ook ketens) nodig voor het afsluiten / wijzigen / beëindigen van een verzekering, het claimen van een schade en voor het afhandelen van vragen of klachten.
Een product bestaat vaak uit meerdere deelproducten of deeldiensten. Als het product van een dealer een auto is, is er normaal gesproken ook een dienst “onderhoud” en eventueel ook een “pechdienst” aan gekoppeld. Hiervoor bestaan dan ook aparte klanttransacties en ketens.
Een transactie kent 5 stappen (fasen) in een vaste volgorde (bron: ‘Enterprise Onthology’ van Jan Dietz, 2006). De verdere uitwerking/invulling van deze fasen vindt plaats in het achterliggende bedrijfsproces – zie onder ‘(hoofd)activiteiten’.
De 5 fasen zijn: Verzoek, Belofte, Uitvoering, Oplevering en Acceptatie.
sequenceDiagram
participant K as Klant
participant L as Leverancier
K-->>L: Verzoek
L-->>K: Belofte
activate L
Note right of L: Uitvoering
L-->>K: Oplevering
deactivate L
K-->>L: Acceptatie
Binnen elke fase van een transactie moeten in het bedrijfsproces de hoofdactiviteiten worden benoemd. De diepgang daarvan wordt bepaald op basis van 3 overwegingen:
Overzicht en inzicht: wat gebeurt er in dit proces en wat (dus) niet (niveau: samenwerking tussen accountable domeinen);
Bij de uitvoering van welke hoofdactiviteiten zijn andere domeinen nodig (extra schakels in de keten identificeren) en
Wat is de informatie behoefte van het proces:
Over de detaillering kan nog wel eens discussie ontstaan. Dan gelden de 3 overwegingen, daarna basisprincipe 2 (hieronder) en in laatste instantie beslist de eigenaar (vanwege acceptatie en accountability).
Bedrijfsinformatie is die informatie, die alle bedrijfsprocessen samen nodig hebben om hun werk te kunnen doen en die door of aan andere bedrijfs-processen (ook van externe partijen) geleverd moet worden. Daaronder vallen bv ook het gebruik van informatie uit de GBA of rapportages, intern of extern).
In de Pronto analyses staat centraal, dat in de informatiebehoeften van alle bedrijfsprocessen kan worden voorzien (in en uit) en dat duidelijk is wat de bron van de informatie is (die kan dus ook extern zijn).
In de Pronto modellen wordt elke informatiestroom gerepresenteerd door een “pijl” van informatieobject naar hoofdactiviteit (“inkomend”, waarmee de informatiebehoefte van een bedrijfsproces duidelijk wordt)
graph LR;
A[Informatie Object]-->B[Hoofdactiviteit];
en andersom van activiteiten naar objecten (“uitgaand”) waarmee de te leveren informatie voor andere processen duidelijk wordt.
graph RL;
A[Hoofdactiviteit]-->B[Informatie Object];
Het gaat bij een informatiestroom om de specifiek benodigde informatie (dus b.v. NAW-gegevens i.p.v. klantinformatie; geen hele objecten, maar specifieke velden)
Een informatieobject is een verzameling bedrijfsinformatie, die logisch gezien bij elkaar hoort (b.v. alle informatie over klanten) en die één eigenaar heeft (de eigenaar is vaak, maar niet noodzakelijk, het domein dat de informatie produceert of vastlegt).
Alle informatieobjecten samen worden inhoudelijk gedefinieerd door de optelsom te maken van alle “inkomende” informatiestromen (= de totale informatiebehoefte van de onderneming). Voor elk informatieobject moet vervolgens worden nagegaan: a) of alle informatie daadwerkelijk gebaseerd is op een behoefte (“lezen”) en b) of er voor alle informatievelden voldoende beheermogelijkheden (lees: bedrijfsprocessen) zijn om die informatie te creëren, te wijzigen en indien nodig te verwijderen (en zo nee, of dat ok is).
| CRUD | Nederlands | Engels |
|---|---|---|
| C | Creëren | Create |
| R | Lezen | Read |
| U | Aanpassen | Update |
| D | Verwijderen | Delete |
De term CRUD beschrijft de vier basis operaties die op informatie uitgevoerd kunnen worden. Op de engelse wikipedia staan verschillende voorbeelden van de technische vertaling van deze logische operaties.
Dit gaat over de doorvertaling naar IT (informatievoorziening i.p.v. informatiebehoeften) en hoort daarom niet bij de Pronto-modellen!
Informatie services zijn de implementatie van informatiestromen. Het is de “IT interface” voor het gebruik van / de toegang tot informatie uit informatie-objecten (objecten), dus voor het toevoegen, wijzigen en verwijderen (schrijven) of ophalen (lezen) van specifieke informatie uit een specifiek object.
De informatiestromen uit de Pronto modellen zijn een heel goede basis voor het inventariseren van de IT-requirements!
Transacties, processen, ketens en infrmatiestromen geven vorm aan samenwerking. Onderscheidt hierbij samenwerking tussen domeinen van samenwerking tussen (groepen) mensen. Het laatste gaat over “dingen doen” (responsabilities), het eerste over “zaken doen” (accountabilities). Als de samenwerking tussen domeinen duidelijk is (eigen accountability, dus zekere mate van autonomie) kan de samenwerking binnen domeinen relatief makkelijk vorm worden gegeven (en naar behoefte van medewerkers en eigenaar!). Pronto gaat over samenwerking tussen domeinen (en over zaken doen en accountabilities).
Modelleer alleen wat zinnig en nuttig is: de essentie van samenwerking. De essentie is een compleet overzicht van de bedrijfsvoering over de verschillende domeinen heen (en binnen de gekozen scope). Dat wil zeggen van alle transactie(keten)s, bedrijfsprocessen en alle benodigde informatiestromen en -objecten en als een integraal model! Houdt het model zo compact mogelijk; dat geeft het beste overzicht, betere acceptatie en vereenvoudigt analyses en onderhoudswerk. Waar onderdelen* gecombineerd kunnen worden: doen (tip bij analyses: eerst gescheiden analyseren, dan waar mogelijk en zinnig combineren). * onderdelen = producten / diensten, transacties, processen, hoofdactiviteiten, informatiestromen, etc. Niet te combineren (evt. wel te dupliceren): dingen van verschillende eigenaren!
Mate van detaillering speelt vooral bij de uitwerking van processen in hoofdactiviteiten (zie ook de omschrijving van ‘hoofdactiviteit’). Hier gelden 3 belangrijke criteria:
Modelleer elk bedrijfsproces vanuit de 5 fasen van een transactie. Gebruik waar mogelijk herkenbare patronen (voor begrip, efficiëntie, herkenbaarheid, hergebruik, overdraagbaarheid, enz.). Voorbeelden: Basis voor bedrijfsvoering / een bedrijfsmodel: er zijn altijd klanten, producten/diensten en “relaties daartussen” (CZ) Modelleren van betalingen: voorwaardelijk voor levering, achteraf, gratis, …… Productkeuzes: liever product/dienst met keuze-opties dan alles opsplitsen en aparte ketens (KPN) Van product/dienst naar klanttransacties: relatie/overeenkomst, uitnutting, klantenservice (checklist) Omgaan meet offerte, garantie, bedenktijd, etc. in een transactie (vgl ook DEMO)
In de Pronto modellen komt specifieke informatie maar op 1 plek (in één specifiek informatieobject van de onderneming) voor. In de realisatie kunnen om allerlei redenen meerdere kopieën op verschillende locaties nodig zijn.
De eerste vraag moet altijd zijn:
Van daaruit gaat het in hoofdlijnen om de volgende vragen (stappen):
Wat zijn de relevante producten en diensten, in het kader van de gekozen scope en vanuit klantperspectief? (Anders gezegd: wat is de bestaansreden van het domein?)
Welke klanttransacties (= klantketens) zijn bij die producten en diensten relevant?
Wat gebeurt er in het bedrijfsproces van een transactie (hoofdactiviteiten)?
Hoe zien de ketens achter die klanttransacties er uit? Bij welke hoofdactiviteiten van de klanttransactie is een bijdrage van andere domeinen nodig / welke domeinen moeten (via transacties of op een andere manier) welke bijdrage leveren in de keten?
…
Is de totale bedrijfsinformatiebehoefte (gegeven de gekozen scope) belegd in informatie-objecten (waarvan de eigenaren bekend zijn)? Is deze set consistent en zonder doublures? En is waar nodig in alle elementaire beheertaken voorzien (creëren, wijzigen, verwijderen en lezen)?
The collection of transaction patterns are not a model of reality someone has invented or created. The transaction patterns are the reality.
When people interact then this interaction is always in the form of a transaction pattern. The pattern contains the five steps of:
sequenceDiagram
participant K as Klant
participant L as Leverancier
K-->>L: Verzoek
L-->>K: Belofte
activate L
Note right of L: Uitvoering
L-->>K: Oplevering
deactivate L
K-->>L: Acceptatie
A person that works at a conveyor belt, has no part in the transaction pattern. In this situation this person is part of the operational execution (implementation). This person might be responsible for the execution of the job but not accountable.
A transaction pattern is always between two persons that are equal toward each other. The two actors in the pattern should both be accountable to be part of the transactions in scope of Pronto as part of the business essence.
**The rule of thumb is: **
Pronto provides insight in who is accountable for what and the transaction pattern between the accountable actors.