F.A.Q

Bespreek je vraagstuk eens met ons. Binnen een dag of twee geven we je een dieper inzicht in je vraag en een richting om verder te denken.

Sinds 1998 maken we dossiersystemen voor financieel dienstverleners, zoals intermediair Van Lanschot Chabot. De DEMO methodiek is erg breed toepasbaar, maar wij richten ons op het spanningsveld tussen Business en IT.

DEMO modellering hebben we bijvoorbeeld toegepast om voor een grote multinational de gaten in hun fucntionele requirements voor een nieuw IT systeem boven tafel te krijgen.

Voor een energienetbeheerder hebben we het dossiersysteem voor aanvragen van nieuwe gas- en elektra aansluitingen gebouwd, inclusief CIAO workflow voor de procesondersteuning. Voorbeelden en cases staan op de branche pagina’s voor verzekeringen en GWW/Infra.

We hebben jarenlange ervaring met het ontsluiten van data uit ERP pakketten, webplatforms, (polis)administratiesystemen, projectondersteunings applicaties, DMS-en, etc. Zolang standaard API’s en goede do

Enterprise Engineering is een nieuw ingenieursvakgebied, met vergelijkbare (wetenschappelijk onderbouwde) fundamenten en onderliggende principes als andere ingenieursvakgebieden.

Zoals de zwaartekracht een belangrijke natuurwet is in de civiele en luchtvaart-techniek, zo is het universele communicatie patroon de ‘natuurwet’ die enterprise engineers toepassen.

Andere ‘Best Practice’ methodes (TOGAF, BPMN) voor organisatie ontwerp missen het solide wiskundig fundament. Hierdoor worden in een organisatie-ontwerp fase al fouten ‘ingebakken’ die zich pas in IT-implementatie fase manifesteren.

Dit is een belangrijke oorzaak voor het hoge aantal mislukkingen in organisatie (her)ontwerp vraagstukken zoals IT implementaties.

Flowcharts of stroomdiagrammen zijn een goede manier om processen te illustreren. Want ze zijn intuïtief en geven de procesanalist volop vrijheid om zijn eigen draai aan de procesweergave te geven.

Maar wanneer je processen wil implementeren in applicaties is diep inzicht nodig, met een duidelijk afgebakend begrippenkader en ‘grammaticaregels’ over hoe je zaken weergeeft.

DEMO is de methodiek die software ontwikkelaars en business/werkvloer een gemeenschappelijke ‘procestaal’ geeft zodat iedereen elkaar begrijpt.

DEMO: Design & Engineering Methodology for Organizations.

Enterprise Engineering is het vakgebied, en DEMO is de methdologie, om organisatie modellen te maken.

DEMO is gebaseerd op solide wetenschappelijke fundamenten uit de sociologie, (communicatie-) filosofie en informatiekunde. DEMO is hiermee een brug tussen de menselijke kant van de organisatie en de IT implementatie. Het belangrijkste axioma in de DEMO theorie is het universele communicatie patroon.

DEMO is sinds begin jaren ’90 ontwikkeld door Prof. dr. ir. Jan Dietz aan de TU Delft. Sindsdien hebben veel researchers, waaronder Dr. ir. Steven van Kervel en Marek Skotnica Msc van Formetis, bijgedragen aan de methodiek en het Enterprise Engineering vakgebied in het CIAO! research netwerk.

Mensen die met elkaar samenwerken communiceren volgens een universeel patroon. In eenvoudigste vorm verloopt dit zo:

1-Een klant verzoekt de leverancier een taak uit te voeren,

2-de leverancier belooft en voert de taak uit,

3-vervolgens verklaart de leverancier dat hij zijn taak heeft uitgevoerd,

4- Tot slot accepteert de klant het resultaat van de taak.

De taak (of product) kan varieren van het brengen van een kop koffie tot het bouwen van een brug. Vaak zien we dat complexe taken (‘bouw een brug’) bestaan uit sub-taken (‘maak een ontwerp voor een brug’) die allemaal volgens hetzelfde patroon verlopen.

Vervolgens kijken we naar de ‘unhappy flow’, dit zijn de processtappen waar iets mis gaat of ging. Bijvoorbeeld als de leverancier zijn taak heeft uitgevoerd, maar de klant niet tevreden is over het resultaat. Wie doet dan wat?

In de praktijk zien we talloze voorbeelden van processen waarin essentiele communicatie stappen zijn vergeten in de proces modelleerfase. In IT implementatie is het dan niet mogelijk de betreffende stap consistent en efficient te zetten.  

Stel dat je een verzoek aan een collega doet, en hij belooft niet de taak op te pakken. Hoe weet je dan of hij je gaat helpen, of dat je beter een een andere kunt collega kunt vragen?

Stel dat je niet terugkoppelt aan je collega dat je je taak hebt uitgevoerd, hoe weet hij dan dat je klaar bent en dat hij zelf weer de volgende stap kan zetten?

Happy flow is hoe het proces idealiter verloopt. Er zijn verschillen per sector, maar grofweg 90% van de processen kent een happy flow verloop.

De andere 10% zijn de unhappy flows, hier gaat dus ergens iets fout. Denk aan foutjes in een taak, opdrachten die worden vergeten, mensen die van gedachten veranderen.

Wij kennen organisaties waar 40% van de werkzaamheden bestaat uit het herstellen van fouten die elders in het proces zijn gemaakt. Als je naast de happy flow ook inzicht hebt in de unhappy flow kun je dus deze 40% verspilling aanpakken.

Workflow is geautomatiseerde procesondersteuning. De medewerker wordt begeleid in de processtappen. Workflow helpt vooral bij complexere processen om te zorgen dat het proces gestructureerd, correct, efficient en transparant verloopt.

Met de standaard workflow is er inderdaad een risico dat een star procesverloop ontstaat. Hiermee kom je van de regen in de drup, want dan zoeken medewerkers zelf weer oplossingen buiten het systeem om die uiteindelijk inefficienter en duurder zijn. De mate van starheid van het procesverloop ligt aan de beperkingen van de procesmodelleermethodiek, de competentie van de procesmodelleur en de functionaliteit van de betreffende workflow engine.

Met de DEMO methodiek en de CIAO workflow is het mogelijk om processen precies zo ‘strak’ af te stellen dat verplichte stappen correct en compliant afgedwongen worden en de medewerker tegelijk de vrijheid heeft om andere stappen naar eigen inzicht uit te voeren.

Om te beginnen bevat een DEMO model het complete procesverloop, dus inclusief alle mogelijke ‘unhappy flows’.

Daarnaast is een DEMO model een veel preciezere procesbeschrijving, het heeft de eigenschappen van een wiskundige taal zoals Java of C#. Een DEMO model is hierdoor direct executeerbaar in in de CIAO workflow engine. BPMN modellen daarentegen zijn slechts een notatie, dus een verzameling symbolen. Deze notatie moet vervolgens nog vertaald worden naar BPEL, en van daaruit ingevoerd in een BPMN/BPEL workflow engine. Door de extra tussenstap kunnen ‘vertaalfouten’ optreden die leiden tot een incorrect procesverloop.

Tot slot heeft een DEMO model een consistente heldere relatie met de objecten- en datawereld. Hierdoor spoort de modelleur al in de modelleerfase misverstanden tussen business en IT op, die anders pas in implementatiefase (tegen veel hogere kosten) zouden zijn rechtgezet.

RED is the standaard aanpak voor organisatie (her)ontwerp. De 5 basisstappen zijn:

1. In één of enkele workshops wordt de noodzaak voor organisatie herontwerp geïdentificeerd. Het vraagstuk wordt weergegeven in een gemeenschappelijke taal (DEMO model) die voor alle stakeholder begrijpelijk is zodat een discussie zonder spraakverwarring mogelijk wordt.

2 Door interviews and overleg wordt de huidige situatie (IST) verder uitgediept.

3 Verbetervoorstellen (SOLL) worden voorgelegd en aan de hand van .

4 Na bespreking en simulatie van de alternatieven kiezen de stakeholders de beste oplossing.

5 Indien noodzakelijk implementeert ForMetis het best passende DEMO model in de CIAO workflow engine en/of Slimdossier systeem.

Omdat alle processtappen netjes gelogd worden is er volop data beschikbaar om proces analyses op uit te voeren. Er zijn verschillende manieren waarop deze data gevisualiseerd kan worden.