Categoriearchief: Uncategorized

Waarom effectiviteit niet alleen in het woordenboek voor efficiëntie komt

Geplaatst op door
Antwoorden

Toen ik studeerde, wilde ik daarnaast nog iets doen dat wel nuttig was en had daarom een bijbaantje als telefooncellen-schoonmaker.  Voor de millenials; dat waren groene hokjes op straat waarin een stupidphone zat vastgemaakt, die je tegen betaling kon gebruiken. Niet om te appen, snapchatten of instagrammen, alleen om te bellen.

Ik vond het prachtig. Voor dag en dauw heerlijk in m’n bedrijfsautootje door Drenthe en Overijssel om de groene hokjes te ontdoen van uitgesmeerde frikandellen speciaal en vliegenpoepjes.

Op die leeftijd was ik nog best wel gevoelig voor autoriteit, dus was nogal onder de indruk van m’n werkgever wanneer hij weer eens benadrukte dat “de route afmaken binnen een bepaalde tijd” erg belangrijk was.

Nu was het zo dat, naast de telefooncellen, ik ook nog de toiletten van telefooncentrales moest schoonmaken. Telefooncentrales zijn kleine gebouwtjes, her en der in het land verspreid, met een toilet voor de monteurs die daar heel sporadisch aanwezig zijn.

Toen ik de eerste keer met de persoon mee liep die ik zou opvolgen, zag ik dat zijn werkwijze erg efficiënt was. Chloor in de pot en wasbakje, snel een lap over de wc bril en hup, de auto weer in. In 3 minuten een toilet klaar.  Het rook fris en voor het oog zag het er schoon uit.

Dus dit is wat ik ook de eerste paar weken deed. Totdat ik een keer zelf hoge nood had en me in de positie van de klant bevond. Jemig, vanaf die kant gezien was het best vies. Ik besloot, om vanaf dat moment, elke week 1 wc grondig aan te pakken. En soms koste me dat een uur in plaats van 3 minuten. Maar het resultaat mocht er zijn.

Het zal u niet verbazen dat mijn werkgever na een paar weken opmerkte dat mijn rondes een uur langer duurden. Na verteld te hebben wat ik aan het doen was ging hij morrend akkoord. “Als je er maar geen gewoonte van maakt”. Dat heb ik toch nog even gedaan, totdat alle toiletten op het schoonheidsniveau waren waar ik als klant tevreden mee zou zijn.

Vanaf toen was het alleen nog maar het spreekwoordelijke bijhouden.

Tot op een zekere dag mijn werkgever het contract voor de telefooncellen kwijt raakte. Echter, hij mocht wel de toiletten van de telefooncentrales blijven schoonmaken en de klant had gevraagd om dat te laten doen door de persoon die verantwoordelijk was voor de toiletten op mijn route. Daarin zagen zij een groot verschil met de kwaliteit van andere toiletten.

En ja, zo was ik plots verantwoordelijk voor alle toiletten (nou ja, degene bij de telefooncentrales) in Noord Nederland. Hierbij paste ik hetzelfde principe toe. Eerst alles op het gewenste niveau brengen (effectiviteit), daarna ze met gepaste inspanning (efficiëntie) op peil houden.

En dat heb ik nog jaren gedaan. Todat ik echt aan het werk ging als trainer/consultant in Processenland om telkens in herhaling te vallen dat effectiviteit voor efficiëntie komt.

Verslag workshop Process Model Canvas

Geplaatst op door
1

Omdat we via twitter regelmatig discussiëren over processen en procesmanagement (en omdat hij wat tweets van mij gebruikt in zijn slides;-), werd ik door Marco Bijl van BPEC (www.bpec.nl) uitgenodigd om een workshop over het Process Model Canvas bij te wonen.

Aangezien ik wel een klein beetje ben geïnteresseerd in processen, was het vrijdag 27 mei zover. In een gezellig zaaltje ergens in een hotel in Noord Brabant, mocht ik meedoen met de sessie die voor Kubizz werd georganiseerd.

In dit blog wil ik graag verslag doen van deze sessie. De volgende onderwerpen zal ik daarin behandelen.

  • Wat is het Process Model Canvas?
  • Hoe werkt het Process Model Canvas?
  • Wanneer zou je het Process Model Canvas gebruiken?
  • Wat is mijn mening over de toepasbaarheid?

1. Wat is het Process Model Canvas?

Wellicht dat u bekend bent met het Business Model Canvas. Heel kort door de bocht is dat een tekenplaat dat dient als hulpmiddel om met een aantal mensen te bediscussieren hoe je als organisatie je centen wilt verdienen en hoe je dat moet regelen.

Dat “regelen” wordt in het Business Model Canvas op zeer globaal niveau beschreven met zogenaamde “kernactiviteiten”.

Omdat het werk uiteindelijk concreet op de werkvloer moet gebeuren, is er wellicht wat meer tijd en aandacht nodig om dat verder in te vullen. Het Process Model Canvas probeert daar een hulpmiddel voor te bieden.

In feite is het een hulpmiddel om duidelijker voor ogen te krijgen hoe (maar nog meer Waarom?) processen ingericht moeten worden. Dit wordt vormgegeven door het Why, What en Wow van een proces te bediscussiëren en te beschrijven.

PMC-canvas

 

Why?

Aan de linkerkant van het Process Model Canvas wordt het Why? van een proces weergegeven. Dat dwingt je, vanzelfsprekend, om over het concrete procesresultaat na te denken, maar nog meer over waarom dat resultaat zo belangrijk is.

In de workshop hebben we als voorbeeld het proces “Repareren auto” bij een autogarage uitgewerkt. Het concrete resultaat daarvan is “een gerepareerde auto”. In Jos Burgers termen zou dat een boor zijn. Het Why? gaat meer om het gat.

In ons groepje kwamen we uiteindelijk tot een Why? voor de klant in de trant van “Zelfstandig mobiel blijven”.

Ook is het de bedoeling om het Why? voor meerdere belanghebbenden van het proces te beschrijven. Dus ook voor de garage zelf, of externe partijen.

Wat zou, volgens u, een Why? (afgezien van geld verdienen) voor de garage kunnen zijn?

Wow!

Het Wow effect is wat een proces teweeg zou moeten brengen. Niet alleen bij de klant, maar ook bij medewerkers en andere betrokkenen.

In ons groepje hebben we eerste nagedacht over het Wow? voor de klant. Hierbij konden we vanzelfsprekende dingen bedenken als “snel geholpen”, “bellen als er meer aan de hand is” en “auto gewassen”  Verder dachten we dat het voor sommige klanten ook wel leuk zou zijn als ze advies kregen over onderhoud dat ze zelf kunnen doen of tips om verdere onderhoudskosten te beperken.

Voor medewerkers zou je kunnen denken aan goed gereedschap of correcte informatie.

Samengevat zou je het WOW van een proces kunnen omschrijven als redenen waarom je als klant of als werknemer een organisatie zou aanbevelen bij anderen.

What?

Het What? gedeelte van het Process Model Canvas gaat om de connectie tussen Why?en Wow. Dit is wat door de meeste mensen waarschijnlijk met het woord “proces” zal worden geassocieerd.  Als eerste vul je de grove stappen in. In ons geval:

  • Aannemen auto door receptie
  • Repareren auto door monteur
  • Afleveren gerepareerde auto door afleveraar

Verbinden door Informatie

Eén van de principes van het Process Model Canvas is dat er niet in detail beschreven wordt wat medewerkers moeten doen; dat kunnen ze best zelf bedenken. De verbinding tussen de activiteiten/subprocessen wordt weergegeven door de “informatiestroom”.

In dat geval wordt van rechts naar links gewerkt en wordt er nagedacht over (nog steeds met als voorbeeld de autoreparatie):

  • Welke informatie verwacht de klant van de afleveraar wanneer de auto wordt opgehaald?
  • Welke informatie verwacht de afleveraar van de monteur wanneer de auto gerepareerd is?
  • Welke informatie verwacht de monteur van de receptie wanneer de auto in ontvangst is genomen?
  • Welke informatie verwacht de receptie van de klant wanneer de auto wordt gebracht?

De focus in het Process Model Canvas ligt dus op de informatiestromen tussen verschillende stappen (en uitvoerenden) en niet op hoe dat exact is geregeld.

Het Process Model Canvas heeft wel een samenwerkingsverband met de procesmodelleringsoftware van Comm’ant, waarin dit in meer detail gemodelleerd kan worden.

Uiteindelijk hadden alle groepjes in de workshop het Process Model Canvas ingevuld en werd het gepresenteerd.

In een paar uurtjes hadden we hiermee een beeld van het Why? Wow! en What? van het proces “Repareren auto”. Het is dat ik zelf graag aan m’n auto knutsel, anders had ik zeker de garage van mijn groepje bezocht 😉

3. Wanneer zou je het Process Model Canvas gebruiken? 

Zoals uit bovenstaande beschrijving hopelijk naar voren is gekomen, is het Process Model Canvas met name geschikt om met diverse mensen, het proces, waarin zij een rol spelen, te bediscussiëren.

Het is daarmee dus bruikbaar in de fase die ik meestal “process discovery” noem, waarbij het doel is om het proces helder af te bakenen en voor ogen te krijgen wat iedereen van het proces verwacht.

Wanneer een organisatie “iets met processen” wil doen, zal het Process Model Canvas zijn meeste waarde dus vroeg in het traject hebben.

Het biedt een hulpmiddel voor een dialoog over of er daadwerkelijk over een zinvol proces wordt gesproken en wat elke belanghebbende van dat proces verwacht. Hierdoor wordt voorkomen dat er met processen aan de slag worden gegaan die de moeite niet waard zijn of die eigenlijk geen processen zijn (maar bijvoorbeeld slechts een subproces of activiteit)

4. Mijn mening over het Process Model Canvas en de workshop

Is het echt iets nieuws?

Ik loop al wat jaartjes mee in processenland, dus persoonlijk zie ik het Process Model Canvas als één van de vele werkvormen om de globale lijnen van een proces te bediscussiëren.  Met als doel om, later in het traject, spraakverwarring over proces en procesdoelen te voorkomen.

Het is overigens een stap die ik wel vaak vergeten zie worden. Al snel wordt de diepte ingegaan (bijvoorbeeld door een proces in kaart brengen en verbeteringen doorvoeren), zonder een helder beeld wat van een proces verwacht wordt.

Daarom bieden dit soort hulpmiddelen, naar mijn mening, een goede start als link tussen de missie van een organisatie en de daadwerkelijke implementatie van een proces.

Focus op informatie wellicht nieuw, maar niet genoeg

Het uiteindelijke resultaat van het invullen van het Process Model Canvas is, voor elke rol, de benodigde informatie om het werk uit te voeren en om op die manier de why en de wow van het proces te bewerkstelligen.

Daarmee wordt er vanuit gegaan dat de invulling van hoe? dat te regelen de verantwoordelijkheid van de medewerkers is. Dat vind ik een goed uitgangspunt, maar dan zul je ze ook moeten vertellen dat een presterend proces meer nodig heeft dan informatie.

Een presterend proces is een samenwerkingsverband tussen diverse aspecten als

  • Het werk dat moet gebeuren
  • De mensen die dat kunnen doen
  • De informatie die daarvoor nodig is
  • De hulpmiddelen die daarvoor benodigd zijn
  • De flexibiliteit voor het managen van zaken
  • De manier waarop de mensen worden aangestuurd
  • Externe factoren als wetgeving
  • ……

Dan ga je al snel naar de inrichting van een proces. En dat is waar het, naar mijn mening, uiteindelijk wel om moet gaan. Want dan kan het proces uitgevoerd worden.

Link naar uitvoering 

En dat is nog een link die ik mis in het Process Model Canvas. Ja, het is mogelijk om dieper op het proces in te gaan door de informatie van het Process Model Canvas te verwerken in een procesmodel, maar dat blijft ook praten over de werkelijkheid.

En dat is vaak prima in het begin van een traject, maar het is een feit dat veel processen momenteel al worden uitgevoerd.  Dus misschien is het wel een goed idee om “discussieer platen” als het Process Model Canvas meer te integreren in de dagelijkse praktijk. Ik heb op dit moment geen helder beeld voor ogen hoe dat precies te doen, maar wat me zo te binnen schiet zijn zaken als:

  • Regelmatig de Why? van het proces her-ijken
  • De Wow’s van klanten terugkoppelen naar medewerkers
  • Regelmatig checken of de vastgestelde informatiebehoeftes nog actueel zijn

Dus als een soort van dagelijkse praatplaat om het proces “levend” te houden. Anders blijft het bij een soort van theorie hoe je het zou willen doen.

Vervolg met behulp van Comm’ant

Hoewel het in de workshop, voor mijn gevoel, niet helemaal helder naar voren kwam, is het (ik heb even navraag gedaan) wel mogelijk om een verdiepingsslag te maken met de procesmodelleringsoftware van Comm’ant.

Zo kan er als eerste, op basis van het ingevulde Process Model Canvas, een communicatiediagram worden opgesteld, waarin de informatiestromen vastgelegd kunnen worden.

De volgende verdiepingsslag kan gemaakt worden met het zogenaamde ‘Resultaat Gericht Procesmodel’ waarin het zwaartepunt ligt bij het duidelijk maken van inputs en outputs om vervolgens overige aspecten (mensen, systemen, eisen, risico’s) toegevoegd kunnen worden.

Maar zoals vermeld, dat was me niet helemaal duidelijk geworden uit de workshop.

De workshop zelf

De workshop start met een theoretische onderbouwing van het Process Model Canvas. Persoonlijk mistte ik hierin een heldere link naar het Business Model Canvas, terwijl het Process Model Canvas toch als een vervolgstap daarop wordt gezien.

Het werken met het Process Model Canvas wordt ondersteund door post-its op het Process Model Canvas te plakken. Zelfs in een klein groepje merk je dat je dan toch al wat facilitator vaardigheden nodig hebt.

De post-its waren allemaal geel, maar omdat je, bijvoorbeeld, de Wow voor meerdere actoren moet aangeven, denk ik dat werken met meerdere kleuren beter zou werken.

Voor de rest mis ik een stap vooraf aan het Process Model Canvas waarin wordt bediscussieerd waarom een proces bij de kop wordt gepakt en daarna mis ik een stap hoe we verder gaan nadat het Process Model Canvas is ingevuld. Maar, ik besef me ook dat dat niet het doel was van de workshop (en zoals hierboven vermeld; die stap is wel mogelijk).

Maar, afgezien van bovenstaande punten, is het natuurlijk altijd leuk om met mensen een proces helder voor ogen te krijgen en het Process Model Canvas kan daar een goed hulpmiddel bij zijn.

5. Conclusie

Voor mij is het Process Model Canvas een andere werkvorm voor het “helder krijgen van een proces en zijn afbakening”.

Dit is overigens wel een stap die in veel procesprojecten wordt vergeten, dus goed dat er een nieuw hulpmiddel is om hier concreet mee aan de slag te gaan.

Ik ga er vanuit dat ook het Process Model Canvas zelf in ontwikkeling is, zodat wellicht de connectie met het Business Model en de daadwerkelijke uitvoering nog meer tot zijn recht komen.

Marco en Kubizz; bedankt dat ik deze middag mocht bijwonen.

.

Ik ga naar Portugal en dat vind ik best een beetje eng

Geplaatst op door
1

Ik mag graag met organisaties werken aan hun processen.

Ik vind het prachtig om steeds weer nieuwe dingen te leren en door te geven.

Ik vind het prachtig om me elke dag weer te verbazen over procesgerelateerde fratsen.

Ik vind het prachtig om in de zelfspotlight te staan.

Ik vind het geweldig om al het bovenstaande te vertalen naar blogjes met een knipoog.

 

En zo blog en discussieer ik, op diverse digitale plekken, regelmatig wat mee over processen. Zo ook op BPM.com waar ik regelmatig de strijd aan ga met visies als “BPM is software” of “BPM is een project”.

En het schijnt dat sommigen deze ‘doe eens normaal’ houding best wel onorthodox vinden. En dat valt blijkbaar op, want tot mijn grote verbazing ontving ik een verzoek om te komen spreken op een BPM conferentie in Portugal.

In een skype gesprek met de organisator, gaf hij aan dat mijn zienswijze werd gewaardeerd en dat dat goed zou passen op de conferentie van dit jaar.

Wat? Ik op een BPM conferentie?  Ik doe gewoon organisaties helpen met procesmanagement en schrijf over wat ik beleef. Wie zit daar nou op te wachten?

Ik zou niet weten wat voor interessant verhaal ik zou moeten vertellen. Te meer omdat het thema dit jaar Digitalisering is. Dat heeft toch niets met BPM te maken 😉

Juist deze kwinkslagen bleken gewenst te zijn. Na nog een poosje gepraat te hebben, kwamen we tot de conclusie dat een rol als panel-voorzitter wellicht beter voor mij zou zijn.

Allemaal slimme mensen die veel weten over Digitalisering en ik dan, als de grote onwetende, een beetje vragen stellen. Matthijs van Nieuwkerkje spelen, zeg maar.

Na er nog even een nachtje over wakker gelegen te hebben; dacht ik “Ach wat kan mij het schelen. Het ergste wat me kan gebeuren is dat ik voor eens en voor altijd m’n carrière naar de gallemiezen help”

Beetje gekscherend natuurlijk, maar als verlegen jongetje uit Drenthe een panel leiden met allemaal mensen die ik als goeroes, zie; dat vind ik best wel een beetje eng.

Nu maar hopen dat het mooi weer is in Lissabon.

 

 

 

 

 

 

Zijn procesmodellen wel zo handig voor procesverbeteren?

Geplaatst op door
1

Inleiding

Op twitter heb ik het regelmatig over de dynamiek in de uitvoering van processen en dat je dat niet goed ziet weergegeven in procesmodellen.

Een procesmodel kan handig zijn als werkinstructie of als ontwerp voor een uitvoeringssysteem. Maar, als je ze gebruikt in een procesverbeterproject (en daar wordt het toch best veel voor gebruikt, heb ik gehoord), denk ik dat ze vaak te ver van de werkelijkheid staan om echt te kunnen begrijpen waarom een proces niet presteert.

In dit verhaaltje ga ik proberen uit te leggen wat ik met bovenstaande bedoel. Mijn gedachten hierover werden getriggerd doordat ik de afgelopen maanden diverse gesprekken heb gehad met mensen die zich bezig houden met processen in ziekenhuizen. Daar merk je dat er veel behoefte is aan verbetering, maar op een gegeven moment kwam er een kronkel in m’n hoofd toen ik alle aspecten rondom ziekenhuisprocessen op een rijtje probeerde te krijgen.

Daar heb je namelijk te maken met:

  • Het (van te voren soms onduidelijke) proces waar de klant (patiënt) doorheen ‘stroomt’;
  • De beschikbaarheid van apparatuur, ruimtes en andere faciliteiten (de logistiek);
  • De beschikbaarheid van specialisten;
  • De planning die alles qua tijd aan elkaar moet rijgen.

Dit zijn de soort aspecten die ik bedoel als ik het heb over ‘de dynamiek van de uitvoering’.  Hoe je dat precies in procesmodellen moet krijgen, weet ik ook niet. Maar ik ga toch een poging wagen. Het is overigens niet mijn doel om te komen met een nieuw ‘manifest voor procesmodellen’ of  iets dergelijks.

Het is mijn doel  om duidelijk te maken wat ik bedoel met ‘dynamiek van de uitvoering’ en waarom de meeste procesmodellen die ik tegenkom dat niet erg duidelijk weergeven.

Om het enigszins luchtig te houden, zal ik in de voorbeeldjes geen ziekenhuis, maar een pizzeria gebruiken.

Hoe procesmodellen er vaak uit zien

De meeste procesmodellen die organisaties maken, zien er ongeveer als volgt uit.

(Ik weet het; geen formeel BPMN. Klachten naar info@procesje.nl)

Dit is een zeer begrijpelijk procesmodel (hoewel het eigenlijk alleen de werkstroom van een proces is) en kan dus heel goed dienen om aan een medewerker of een klant uit te leggen wat er gebeurt wanneer er een bestelling binnenkomt.

Ook zou dit de basis kunnen zijn voor een toekomstig proces omdat je dit de beste manier vindt om bestellingen af te handelen.

Naar mijn mening zijn procesmodellen zoals bovenstaand enkel geschikt voor:

  • Instructie/Uitleg (dit moet je doen als er een bestelling binnenkomt)
  • Inrichten van systemen/organisatie met processen “zoals ze zouden moeten lopen” (om het technisch te implementeren is vanzelfsprekend nog wel wat extra nodig).
  • Het blij maken van auditors

Maar, wanneer dit een model van het huidige proces zou zijn, heb je er niets aan om te bepalen of dit proces goed presteert. Het vertelt je niet waarom bestellingen te laat komen of pizza’s telkens aanbranden. En al helemaal niet waarom de pizzeria zulke slechte recensies krijgt op Iens.

Om dat te bereiken, moet je het procesmodel opdikken met meer informatie.  Pas dan kun je zinnige uitspraken doen over de prestaties van het proces. En op basis daarvan mogelijke verbeteringen doorvoeren.

Uitbreiding met ‘wie doet het werk?’

Om aan te geven wie het werk doet in een proces, zie je vaak dat er swimlanes worden getekend. In dat geval wordt de werkstroom ‘gematrixt’ met de functies/rollen die de stappen uitvoeren.  Voor het bovenstaande proces ziet dat er mogelijk als volgt uit:

Wat heb je hier aan als het gaat om verbeteren van dit proces? Niet zo heel veel. Je ziet wie verantwoordelijk is voor de uitvoering van een stap, maar wat je bijvoorbeeld niet ziet is:

  • Hoeveel koks zijn er op welk moment beschikbaar?
  • Hoe lang zijn de uitvoerenden bezig met deze stappen?
  • Zorgen overdrachten voor bottlenecks?

Wil je iets over de prestaties van dit proces zeggen, dan moet dat ook zichtbaar zijn in het model.  Dat ga ik straks proberen, maar een ander belangrijk aspect voor het zien of een proces goed verloopt , is het aantal gevallen dat het proces moet afhandelen.  1 pizza bestelling per week is heel wat anders dan 100 per dag, dus dat dynamische aspect moet duidelijk worden.

Process mining/Simulatietechnieken

Met behulp van processmining/simulatie hulpmiddelen kun je duidelijk maken hoeveel en hoe gevallen door het proces stromen.  De “bolletjes” (als weergave van onderhanden bestellingen) maken dit namelijk duidelijk.

Dit soort technieken geven al een indicatie van bottlenecks in een proces.  Maar bottlenecks zijn slechts symptomen, dus moet je veel dieper in het proces duiken om te achterhalen wat deze bottlenecks veroorzaakt.

In bovenstaand plaatje zie je dat er 3 bestellingen genoteerd worden, maar slechts 1 belegd, waardoor een wachtrij ontstaat. Hoe kan dat? Wanneer we naar de ziekenhuiswereld kijken, heeft dat vaak te maken met beperkte resources.

Een chirurg kan maar 1 operatie tegelijk doen. En wanneer zij aan het opereren is, kan ze geen consulten doen. Dus de doorstroom van patiënten wordt dan beperkt door het aantal medewerkers. Dat zie je niet terug in de meeste procesmodellen. Dus op één of andere manier, zou je de modellen moeten kunnen ‘opdikken’ met resource beschikbaarheid.

Resource-beschikbaarheid in een procesmodel

Wanneer je denkt aan het toevoegen van de beschikbaarheid van resources aan een procesmodel maak je eigenlijk een soort matrix van zwembaan x aantal resources  x stap.

Stel dat er 3 serveersters, 1 kok en 2 bezorgers zijn in het bezorgen pizza proces. Dan wordt het model (het is maar een zelfgeknutselde weergave, hoor) als volgt:

 

Combinatie met bolletjes

Wanneer je het bovenstaande model dan weer combineert met bolletjes (bestellingen), wordt een beetje duidelijker waarom sommige bestellingen niet doorstromen:

 

Zo zie je bijvoorbeeld dat er geen nieuwe bestellingen worden aangenomen omdat de 3 beschikbare serveersters allemaal bezig zijn met een bestelling.

Daarnaast zie je nog iets wat slecht is af te beelden in een model ; er is maar 1 kok, die 3 opéénvolgende stappen voor een bestelling moet uitvoeren. Als hij een pizza aan het verpakken is, kan hij ondertussen niets anders doen.  Hoe zou je deze afhankelijkheid kunnen afbeelden?

Misschien met kleurtjes?

Op deze manier kun je misschien duidelijk maken dat ze onderverdeeld zijn in drieën.

Een andere manier zou kunnen zijn door te zeggen dat het kokswerk een soort van blok is waar zich slechts 1 bestelling tegelijkertijd in kan bevinden:

Het is een lastig aspect van een proces om af te beelden. Maar wel een hele belangrijke om te bepalen waarom een proces niet presteert.  Het is in principe een soort van aan/uit switch tussen activiteiten; als de ene wordt uitgevoerd, ligt de ander stil.

Mensen niet de enige schaarse resource

Een grote uitdaging in een ziekenhuis is niet enkel de inzet van schaarse specialisten, maar ook de beperkte beschikbaarheid van apparatuur/operatiekamers etc.  Je kunt misschien 10 chirurgen hebben, maar als je maar 1 operatiekamer hebt, is dat de beperkende factor.

In administratieve processen kun je dan misschien denken aan systemen (of misschien beter licenties) waarvan er slechts een paar zijn.  Ook dat zou eigenlijk uit het model duidelijk moeten worden. Voor de pizzeria is dat misschien de situatie dat er maar 1 brommer is om te bezorgen. In onderstaand model is deze beperking opgenomen.

 

Om dit te begrijpen heb je eigenlijk wel weer de dynamische bolletjes nodig. Zo zie je dat een bestelling (daarom 2 halfjes) een bezorger en een brommer nodig heeft. Nu zie je dus ook dat er eigenlijk een bezorger te veel is. Of een brommer te weinig.  Kans voor bezuiniging of meer throughput.

Dit lijkt overigens wel een beetje op petrinetten zoals sommigen van jullie wellicht kennen.

En wanneer er in de pizzeria een oven heeft, waarin 3 pizza’s tegelijkertijd gebakken kunnen worden, ziet dat deel van het proces er als volgt uit:

 

Ook hier zie je weer het probleem van 1 kok. Hij kan niet tegelijkertijd een pizza in de oven stoppen en er eentje uithalen (hoewel, ik heb koks gezien…).  Daarom ontstaat het gevaar dat er allemaal pizza’s liggen aan te branden omdat de kok geen tijd heeft om pizza’s uit de oven te halen.

En daarmee kom je op een ander aspect van processen; planning en tijd

Planning en tijd

In het plaatje hierboven wordt dus het belangrijke aspect van tijd duidelijk; wanneer een pizza te lang in de oven ligt, brandt hij aan. Dit heeft dus ook weer met planning te maken.  Dat zit meer in de daadwerkelijke uitvoering van een proces, maar is wel heel belangrijk om een proces goed uit te voeren.

Daarbij zul je bijvoorbeeld ook rekening moeten houden met de beschikbaarheid van medewerkers. Op zaterdag heeft de pizzeria misschien 3 bezorgers en door de week maar 1. Dus het proces (en zijn prestaties) verschilt ook nog weer per dag.  Dit dynamische aspect zul je echt niet ontdekken d.m.v. een traditioneel procesmodel.

In het ziekenhuis heb je daar ook mee te maken. Stel dat er 2 chirurgen zijn, maar slechts 1 operatiekamer. Terwijl de ene chirurg aan het opereren is, kan de ander consulten doen. Hoe maak je dit soort planningsachtige aspecten, die belangrijk zijn voor de patiënt nu duidelijk? Even proberen…

 

Conclusie tot nu toe

Procesmodellen zoals we ze vaak zien hebben hun toepassingen, maar helpen niet altijd om inzicht te krijgen in de oorzaken van slechte procesprestaties.

Daarvoor moet je o.a. ook weten:

  • Aantal gevallen (de bolletjes)
  • Resources
  • Afhankelijkheid resources
  • Planningachtige zaken (beschikbaarheid)

Heel veel aspecten dus, maar noodzakelijk naar mijn mening. Als je dit allemaal wilt afbeelden in een model heb je een aantal dimensies (als tijd, casussen en resources) nodig.

In dit blog heb ik geprobeerd dit duidelijk te maken en in modelletjes weer te geven. En dat valt niet  altijd mee, zoals u heeft kunnen zien.

Dus is het wel de moeite waard om proberen processen te verbeteren aan de hand van procesmodellen zoals ze vaak worden gemaakt?

Of is het wellicht beter om vanuit de uitvoering het proces steeds een klein beetje beter te maken.  Want de dynamiek van de uitvoering komt toch het meeste naar voren in……….. de uitvoering.

Elk voordeel zal z’n nadeel wel hebben, dus hoe denkt u over dit soort zaken?

Procesconsultants, dat zijn pas luie varkens

Geplaatst op door
Antwoorden

031

 

De afgelopen 20 jaar heb ik heel wat werkzaamheden uitgevoerd gerelateerd aan “Managen met processen”.  Het zal u niet verbazen dat ik een groot deel van deze tijd heb besteed aan het helpen van organisaties die het idee hadden opgevat om hun processen te verbeteren.

Dat waren organisaties als gemeentes, waterschappen, banken, verzekeraars, zorginstellingen, logistieke bedrijven, onderwijsinstellingen en zelfs exotischere zaken als elektriciteitscentrales en zelfs een producent van satellieten en straaljagers.

Hoewel ik van sommige vakgebieden inhoudelijk veel geleerd heb in al die jaren, ken ik natuurlijk niet alle ins en outs van wat er gebeurt in al die organisaties.

En dat is best lastig als je van nature nogal nieuwschierig en een beetje een betwetertje bent. Ik wil weten hoe alles werkt. En, soms tot vervelens toe, hoe het beter kan.

Ik heb, soms door harde lessen, moeten leren dat dat niet altijd kan als procesconsultant.

Of eigenlijk zelfs niet moet.

Want omdat elke organisatie processen heeft, waarin de diverse principes van procesmanagement toepasbaar zijn, moet “de inhoud willen veranderen” ook niet je rol zijn als procesconsultant.

Dat zou ook wel gek zijn dat ik even zou komen vertellen hoe een satelliet gebouwd of een patient behandeld moet worden.

(Gelukkig heb ik, naast mijn werkzaamheden als procesconsultant, ook nog wel wat professionele hobbies waar ik wel zelf aan het roer mag staan 😉 )

Die organisaties waar mijn hulp gevraagd werd, weten heel goed hoe ze hun taken moeten uitvoeren, maar zijn de grip op het gehele proces een beetje kwijtgeraakt en zoeken naar hulpmiddelen om dat wel weer te krijgen. Met als doel om weer meer aandacht aan het echte werk te kunnen besteden.

Ik zie mijn rol dus altijd een beetje als procespsycholoog door opendeur vragen te stellen als “wat vind je er zelf van?”

Beetje gekheid natuurlijk, maar mijn mening is wel dat organisaties zelf hun processen moeten verbeteren. Ik kan ze daarbij wijzen op de aandachtspunten of gemene vragen stellen om de context duidelijk te krijgen.

Maar het uiteindelijk uitvoeren van procesverandering; ik laat het de klant altijd zelf doen.

Lekker lui.

 

 

Maar weer eens een blogje over procesmodellen

Geplaatst op door
Antwoorden

031

Eens in de zoveel tijd beland ik in een discussie over de zin en onzin van modellen. Hoewel er in bedrijvenland verschillende soorten modellen worden gemaakt, gaat het in mijn geval dan met name om procesmodellen.

Wij en Zij

Aan de ene kant heb je de voorstanders van modelleren. En dan het liefst volgens een bepaalde standaard. En aan de andere kant heb je het meer praktische volk dat van mening is dat je modellen alleen moet gebruiken als ze waarde toevoegen.

Vroeger was ik best wel van de eerste, maar nu veel meer van de laatste stroming. Ik heb namelijk heel wat processen gemodelleerd, maar vroeg me daarna toch regelmatig af wat er uiteindelijk mee bereikt was. “Omdat de klant het wil” is een argument waar ik niet klakkeloos meer ja op zeg 😉

Bij deze nog mijn oprechte excuses aan iedereen die ik er mee lastig heb gevallen.

Doel en Middel

Maar even serieus. Doel en middel is waar het hier om gaat. Een procesmodel is een middel, maar wat is het doel?  Zo door de jaren heen, zijn er daar heel wat van verzonnen.

In essentie gebruik je een procesmodel om het werkelijke proces te kunnen begrijpen en om er over te kunnen communiceren.

Nou zijn echte processen nogal complexe dingen met verschillende belanghebbenden en diverse aspecten (als werkstroom, informatie, mensen, besturing, hulpmiddelen) die het proces maken tot wat het is.

Een eerste vraag die ik zou stellen is; “Wie of Wat wil het proces begrijpen?” en vervolgens “Waarom wil die wie of wat het proces begrijpen”?

Misschien denkt u wat een rare vraag “Wat wil het proces begrijpen?”

De uitvoering

Daarmee kom ik gelijk op het belangrijkste van een proces; de uitvoering.  Om te doen wat u aan klanten belooft, moeten processen uitgevoerd worden. Daarvoor zijn meerdere zaken benodigd, maar veelal gebeurt dat ook met ondersteuning van ICT.

Dat kan specialistische software voor een specifieke taak zijn, maar ook steeds meer zie je een procesgerichte ondersteuning met behulp van een procesmanagement- of zaaksysteem.

Dat soort software is niet geschikt voor alle type processen, maar meestal wel voor processsen waar de werkstroom (wat moet er allemaal gebeuren voor een zaak?) redelijk te bepalen is. En dus te modelleren.

Dan kan er een model gemaakt worden van het proces, wat dan weer als ontwerp dient voor het systeem. Model wordt werkelijkheid. Lijkt me een goed doel van een procesmodel, niet?

In bovenstaande geval moet een procesmodel dus aan de software vertellen hoe het proces uitgevoerd dient te worden. Besef wel dat het dan niet alleen gaat om de werkstroom, maar ook aspecten als data, formulieren, gebruikers en business rules.

En wanneer het proces geschikt is, kunnen dergelijke systemen van grote waarde zijn voor de prestaties van een proces. Over die prestaties gesproken…

Process Mining

Wanneer procesuitvoering wordt ondersteund met software waar een “proces-smaak” aan zit, zoals bijvoorbeeld een procesmanagement- of zaaksysteem, kan de techniek van process mining gebruikt worden om te kijken hoe lekker dat proces gepresteerd heeft.

Process mining gebruikt de gelogde gegevens (wie heeft wat wanneer voor welke zaak gedaan?) om het uitgevoerde proces “te ontdekken”.

Automatisch processen in kaart brengen, zeg maar. Dus niet met een clubje in een hok kruipen om  processen op de muur plakken, maar technologie het proces laten “tekenen”.

Het mooie is dat (als de logbestanden die informatie hebben)  ook inzicht kan worden verkregen in de prestatie informatie van het proces. Dit kan vervolgens weer vergeleken worden met de gestelde doelen en indien niet blij, kan dat een aanleiding tot procesverbetering.

Let wel op dat process mining je enkel de symptomen van slechte procesprestaties laat zien. maar toch geeft het mogelijk een indicatie van waar gezocht moet worden naar oplossing.

Processen verbeteren

Processen verbeteren blijft organisaties bezig houden. Persoonlijk zie ik ook dat weer als een middel, want klanten willen graag betere procesresultaten. Of u daarvoor uw processen moet verbeteren, zal ze niet veel interesseren.

Maar, ok; om processen te verbeteren zie je binnen veel organisaties de behoefte om het bestaande proces te begrijpen. En da’s niet gek, want wellicht ligt in dat proces de oorzaak van de ongewenste procesprestaties.

En dat is het procesje waar dit blog mee begon; het PROCES begrijpen.  Volgers op twitter weten dat ik me altijd een beetje kan irriteren wannneer mensen “proces” zeggen, maar “procesmodel” bedoelen.

Een procesmodel is het middel om het proces te begrijpen. Of liever; om te begrijpen waarom het proces niet presteert zoals verwacht.

Maar een procesmodel is niet een plaatje van alleen maar blokjes en pijltjes.

Geen blokjes en pijltjes

Als je wilt begrijpen waarom een proces niet presteert, zul je je moeten beseffen dat een proces een samenwerkingsverband is tussen diverse aspecten als:

  • Het werk dat moet gebeuren (de werkstroom)
  • De mensen die dat werk uitvoeren
  • Hulpmiddelen die benodigd zijn
  • Informatievoorziening op uitvoerings- en besturingsniveas
  • De manier waarop het proces bestuurd wordt (bijv. taakgericht of doelgericht)
  • De manier waarop gecommuniceerd wordt met de klant

Laat staan de externe factoren (als wetgeving, eisen vanuit certificerende instanties) waar een proces mee te maken krijgt.

En wanneer je dan enkel een zwembaanplaatje maakt in een procesmodel (wie doet wat?) mis je, mijns inziens, toch enkele van bovengenoemde aspecten.

Processen begrijpen om te analyseren en de oorzaak van slechte prestaties te vinden  is dus nog niet zo eenvoudig. En zeker niet om dat in een model vast te leggen en dan ook nog te kunnen achterhalen welk aspect van het proces de oorzaak is.

Daarnaast is het lastig om in een procesmodel de dynamiek van de uitvoering helder te maken. Terwijl deze wel erg de prestaties van een proces bepalen.  Hierover heb ik eerder een stukje getypt op LinkedIn.

Maar ok, stel dat het u lukt om te ontdekken welke verandering nodig is om het proces beter te maken, dan kunt u die betere werkwijze vanzelfspekend heel mooi vastleggen in een To-Be procesmodel.

To-Be procesmodel 

Maar een To-Be procesmodel is nog steeds een model en nog geen nieuwe werkelijkheid. In veel procesverbeterboeken is het hoofdstuk over implementeren vaak angstvallig dun; want ga er maar aan staan; daar komt een mooi portie verandermanagement bij kijken.

Dat komt met name door, zoals eerder aangegeven, het feit dat een proces een samenwerkingsverband is tussen vele aspecten.

Wat ik me dus afvraag is of op deze “big bang” manier werken aan het verbeteren aan processen wel oplevert wat er van verwacht wordt. Ik zie toch nog regelmatig organisaties waar gedesillusioneerd naar een To-Be model wordt gestaard.

Vergelijk het met het bouwen van een huis

Ik vergelijk het even met het bouwen van een huis. Daarvoor wordt ook een model gemaakt (diverse bouwtekeningen) en dan wordt het huis gebouwd volgens dat model.

Een voordeel van een bouwtekening is dat het een kleine versie van de werkelijkheid is; op basis van het model kun je je een goede voorstelling maken van de werkelijkheid.

Bij een procesmodel is dat lastiger, want dat is niets anders dan een set van afspraken hoe bepaalde procesaspecten worden getekend. Het geeft toch wat minder gevoel voor het echte proces.

Immers; een vierkantje kan “het registreren van een order”, maar ook “het lassen van een frame” zijn.

Nieuw of bestaand?

Een ander verschil tussen een te verbeteren proces en een te bouwen huis is dat het huis nog niet bestond toen het ‘model’ werd gemaakt. Je moet vanaf nul beginnen.

Met een bestaand proces is dat natuurlijk niet zo. Dat wordt al uitgevoerd en bestuurd.

En om dat dan in één knal te veranderen is niet zo makkeliijk . Wellicht daarom dat populaire verbetermethodes als Lean de meer geleidelijke aanpak toepassen van het “continu verbeteren”

Steeds een beetje beter.

Dus niet “Tijdens de verbouwing is de winkel geopend” maar “Tijdens het winkelen verbouwen we”

Maar heb je dan nog steeds procesmodellen nodig?

Continu verbeteren en procesmodellen

Persoonlijk denk ik dat, om continu te kunnen verbeteren, je moet beginnen met het verkrijgen van een continu inzicht in de prestaties van een proces. Of te wel; good old visueel management.

Iedereen moet duidelijk voor ogen hebben wat er in je proces speelt.

Zowel op dagelijks zaakafhandelingsniveau als op procesprestatieniveau. Over deze verschillende niveaus heb ik ook een stukje getypt op LinkedIn.

En op zich is dat “Inzicht in prestaties” ook een model. Het toont modelmatig (bijvoorbeeld in een dashboard) hoe het er voor staat met de werkelijke prestaties.

Een procesmodel zoals we dat veelal zien, mist dat toch een beetje. Live process mining zou mijns inziens het ultieme hulpmiddel hiervoor zijn.

Kortom; wil je continu verbeteren, dan moet je ook continu weten “hoe het ervoor staat”.

Maar nog veel belangrijker; dit “Meten is Weten” moet ook vertaald kunnen worden naar wijzigingen van het proces.

Die wijzigingen zouden dan weer naar een procesmodel vertaald kunnen worden, maar dat klinkt toch een beetje als verkeerd om.

Wellicht dat een nieuwe werkwijze gecommuniceerd kan worden, met behulp van een procesmodel. Of zelfs kan worden ingezet als werkinstructie.

Procesmodel als werkinstructie

Ik ben het regelmatig tegengekomen; organisaties die procesmodellen als werkinstructie inzetten. Op zich geen probleem, maar “organisaties hebben processen en mensen hebben werk”

Een proces is dus meer dan een werkinstructie. Daarnaast vraag ik me af of procesmodellen echt geschikt zijn als werkinstructie.

Soms is gewoon een stukje tekst of een filmpje veel beter. Of nog beter: Augmented reality waarmee een werkinstructie op de werkelijkheid wordt gelegd.

Bezint eer gemodelleert

Weer een heel verhaal over procesmodellen. Op zich niet veel nieuws, maar ik merk toch vaak dat even nadenken voordat “wij gaan onze processen in kaart brengen” veel frustratie in het vervolg kan voorkomen.

Modelleerze!

Een documentstroom is geen proces, toch?

Geplaatst op door
Antwoorden

030

 

Degene die mij kennen, weten vast wel (bijvoorbeeld via facebook voor mensen met een stropdas) dat ik ooit werkte voor een grote Amerikaanse printerreus die via allerlei acquisities ook een Enterprise software leverancier is geworden. Inmiddels is dat door allerlei overnames allemaal al weer anders, maar ergens wordt die Software nog wel geleverd.

Veel van die software probeert oplossingen te bieden voor problemen die zich in het informatiewereldje bevinden.

Dan lijkt procesmanagement soms slechts een speldenknop te zijn binnen het geweld van documenten die gescand, geprint, rond-geworkflowed, gezocht en opgeslagen moeten worden.

En omdat veel organisaties worstelen met grip krijgen op een grote verzameling documenten vergeet men al snel dat er maar één plaats is waar die documenten nodig zijn; in processen!

Wanneer u bijvoorbeeld een lening aanvraagt bij een bank, worden er in dat proces heel wat documenten gebruikt om u, de bank en andere belanghebbenden te voorzien van de benodigde informatie voor procesuitvoering. En daarmee hebben we gelijk de 2 punten om die documentgekken om de oren te slaan.

Ze betitelen vaak de stroom van een document als een proces. Da’s een zeer beperkte kijk. Het gaat om het verstrekken van een lening, niet om het rondsturen van het aanvraagformulier. Het is de aanvraag die stroomt, niet het document.

En daarmee kom je op het punt dat een document slechts een gegevensdrager is. De aanvrager wil zijn aflossingsbedrag weten en dat hoeft niet persé op een document te staan. Het gaat om de informatie. Dat heeft een proces, naast andere enablers, nodig om te presteren. Niet de documenten.

Maar, als u dan toch documenten maakt en print, dan wel op een ******* printer (ik heb nog steeds aandelen)!

 

Processen en vliegtuigjes vouwen

Geplaatst op door
Antwoorden

Vanzelfsprekend was het afgelopen weekend paaseieren zoeken bij opa en oma in de tuin.

En na dat alle eieren waren gevonden, was het knutseltijd voor de kinderen. Eén van de neefjes had het idee opgevat om vliegtuigjes te gaan vouwen.

Nog maar net lagen de vouwblaadjes op tafel of opa toverde de Ipad te voorschijn met een app die kinderen leert vliegtuigjes te vouwen. Stap voor stap word je begeleid om elke vouw in de juiste volgorde uit te voeren.

De kinderen letten goed op en deden de handelingen exact als in de app werd uitgelegd. Trots op elke stap die was afgerond.

Ik zelf deed ook mee, maar irriteerde me met elke stap meer en meer. Waarom? Omdat ik maar wat handelingen deed, maar geen idee had waarom. Op deze manier had ik nog nooit een vliegtuigje gemaakt en begreep niet waarom ik bepaalde handelingen moest doen.

Ik had dus graag eerst het eindresultaat gezien voordat ik aan de slag ging.

Dus bij elke stap werd ik steeds geïrriteerder, terwijl de kindertjes juist steeds blijer werden ‘We hoeven nog maar 2 van de 12 stappen’

Uiteindelijk vlogen de vliegtuigjes van de kinderen de hele kamer rond, terwijl die van mij na een meter al op de grond lag.

‘Ha, ha, die oom Emiel kan echt geen vliegtuigjes maken’

Kortom, een mooie illustratie dat je ook in processen verschillende manieren van werken en dus ook verschillende type medewerkers nodig hebt.

Je hebt mensen die het gewoon fijn vinden om instructies uit te voeren en er voldoening in vinden om ‘alle stappen uit te voeren’

En je hebt mensen die ‘het doel duidelijk moeten hebben’ en dan wellicht hun eigen instructie bedenken.

Over verschillende typen procesuitvoering heb ik ook ooit op linkedin wat geschreven. 

 

 

Ik ben moe, maar ik mis een onderdeel

Geplaatst op door
Antwoorden

029

Degene die mij kennen, weten dat ik heel wat jaren heb gewerkt voor een leverancier van BPM software.  In de beginjaren waren dat allemaal losse producten waarmee je ‘iets specifieks met processen’ kon doen. Denk daarbij aan:

  • Modelleer tools om processen in kaart te brengen
  • Workflow tools om de uitvoering van goed definieerbare processen te ondersteunen
  • Case management tools om processen met meer dynamiek te ondersteunen
  • Process mining tools om ‘processen’ te ontdekken uit logbestanden van systemen

Specifieke tools dus die destijds erg goed waren in waarvoor ze waren ontwikkeld.

Maar het was ook de tijd waarin ‘holistisch BPM’ opkwam. Kijken dus naar alle aspecten die je nodig hebt om een organisatie op procesmatige manier te besturen en (continu) te verbeteren.

Qua technologie leidde dat tot de opkomst van de BPM suites.  Door de jaren heen zijn de namen wellicht veranderd in iets als ‘Smart Process Platform’ of ‘Digital Business Platform’ en ook zaaksystemen, die we veel kennen in Nederland, schaar ik er onder.

Want het idee achter deze platformen is dat de functionaliteit van eerder genoemde losse tools, worden samengevoegd en dat organisaties zelf ‘hun processen in elkaar kunnen klikken’.

Als processengek vond ik dat echt fantastisch. Volledige inspraak en controle over je eigen processen.

Lekker beginnen met een procesmodel, wat wellicht gewoon een handboek kon worden, maar ook doorontwikkeld kan worden naar een systeem waarin je je proces kunt uitvoeren. Met werkbakken, formulieren, data integratie, monitoring; kortom alles wat je onder procesuitvoering en -besturing zou kunnen verstaan.

En dat klinkt heel mooi. Zeker wanneer je vanaf scratch met een proces aan de slag wilt en de uitvoering wilt ondersteunen met BPM technologie.

Maar, in de praktijk bleek dat starten vanaf scratch soms helemaal geen wens was. En da’s logisch, want organisaties hebben al processen. Mogelijk voor verbetering vatbaar, maar ze worden al uitgevoerd.

Daarnaast zijn ook genoeg processen waarvan je je af moet vragen of het de moeite waard is om dat helemaal zelf te willen ontwerpen en de bijbehorende software te ontwikkelen.

Denk aan back office processen als ‘betalen facturen’. Heel veel organisaties willen gewoon ‘een systeem’ waarmee ze het werk kunnen doen. Gewoon best practices kopen en (misschien met een beetje configuratie) aan de slag.

En dat is eigenlijk ook wel logisch. Want ik ken maar weinig organisaties (of eigenlijk een beslismevrouw of -meneer in die organisatie) die zeggen ‘wij willen BPM’.

Ik ken wel organisaties die vergunningen verstrekken, fietsen repareren, patiënten beter maken of software ontwikkelen. Kortom; de specifieke redenen waarom die organisatie bestaat en klanten op de bel drukken.

En daarmee kom ik weer op het gouwe ouwe ‘een goed proces begint aan het eind’.

Begin met een helder beeld van de gewenste procesresultaten. En de extra post-it over ‘slapen’ geeft aan dat je bij het nadenken over procesresultaten ook moet nagaan of het nog steeds de beste manier is om uw klanten te helpen.

Vraag je vervolgens af of dat naar tevredenheid wordt geleverd.

En dat zou de reden kunnen zijn om aan de slag te gaan met het proces.

En zoals u weet is een presterend proces een samenwerkingsverband tussen diverse aspecten, waarvan ondersteunende software er één is.

Wellicht dat beginnen vanaf nul in zo’n BPM platform dan niet nodig blijkt, maar gelukkig zie je dat leveranciers dat ook begrijpen en kant en klare ‘processen’ leveren die gebouwd zijn op dat platform. U vindt ze in het afhaalmagazijn onder andere terug in de stelling  ‘smart process apps’

Maar blijf u zelf afvragen  of uw proces baat heeft bij een bouwpakket of dat een tweedehands bed op marktplaats ook prima is.

God Natt!

 

 

 

Website en blog gescheiden

Geplaatst op door
Antwoorden
Zoals eerder vermeld, wilde ik graag dit blog scheiden van mijn website www.procesje.nl
 
Daar nu een start mee gemaakt door de eerste versie van www.procesje.nl online te zetten. Niet af en zeker niet perfect, maar wat er niet is kun je niet verbeteren.
Boven dit blog vind je nu ook een link om naar de website te gaan.