DEMO®

1                Introductie

DEMO (Design and Engineering Methodology for Organizations) is een methodiek in het vakgebied Enterprise Engineering [Dietz, 2006] en wordt ontwikkeld binnen een internationaal netwerk van universiteiten en onderzoeksinstituten, het zogeheten CIAO! Network1. De methode heeft een wetenschappelijk fundament. Ten opzichte van Systems Engineering worden met de ontwikkeling van het vakgebied Enterprise Engineering drie verbeteringen bereikt. Ten eerste wordt de scope verbreed van IT naar enterprise. IT is allang niet meer het probleem, het is slechts een implementatie- technologie. Ten tweede wordt een brug geslagen tussen business en IT. Ten derde wordt het vakgebied gepositioneerd als een serieuze ontwerpdiscipline. De methodologische pijlers van Enterprise Engineering zijn: Enterprise Ontology, Enterprise Architecture, Enterprise Design en Enterprise Governance. Deze begrippen worden hierna kort toegelicht.

Enterprise Ontology [Dietz, 2006] is het op de Performance in Social Interaction theorie, kortweg PSI-theorie, gebaseerde begrip van de essentie van een organisatie, geheel onafhankelijk van de manier waarop de organisatie is gerealiseerd en geïmplementeerd. De PSI-theorie wordt in de volgende paragraaf toegelicht. Het zogeheten essentiële enterprisemodel biedt inzicht in de constructie en werking van organisaties door die te ontdoen van een forse hoeveelheid complexiteit en overbodige functies.

Enterprise architectuur [Dietz, 2008; Hoogervorst, 2009] is de bewuste beperking van de ontwerpvrijheid. Als bij een verandering met alle wensen rekening is gehouden, blijft er altijd een zekere ontwerpvrijheid over. Enterprise-architectuur legt aan deze vrijheid beperkingen op in de vorm van ontwerpprincipes. Dit biedt de mogelijkheid om algemene, vaak strategische, doelstellingen in de veranderingen na te streven door deze om te zetten in concrete, consistente en coherente ontwerpprincipes, en met deze ontwerpprincipes de geboden ontwerpvrijheid nuttig te gebruiken. Dat is overigens de kern van het begrip architectuur in alle ontwerpdisciplines.

Enterprise Design [Dietz, 2008] is het systematisch tot stand brengen van bedachte veranderingen. Binnen dit proces van het (her)ontwerpen en (her)inrichten van een organisatie, inclusief de ondersteunende IT-systemen, hebben Enterprise Ontology en Enterprise Architecture een prominente plaats.

Enterprise Governance [Hoogervorst, 2009] is de organisatorische capaciteit om na te denken ‘over morgen’, in tegenstelling tot Enterprise Management, dat beoogt de organisatie, zoals die is ontworpen, te laten functioneren. Het werkgebied van Enterprise Governance omvat zowel het bedenken van gewenste veranderingen als het initiëren en sturen van de verwezenlijking ervan.

Enterprise Engineering [Dietz, 2012] streeft drie algemene doeleinden na bij het (her) ontwerpen en (her)inrichten van organisaties, namelijk: intellectual manageability, organizational concinnity en social devotion. Deze vormen  de  antwoorden  op drie hedendaagse problemen. Het probleem dat aangepakt wordt met intellectual manageability is dat een enigszins substantiële verandering van een organisatie, al dan niet met inbegrip van IT, met de bestaande aanpakken niet meer te overzien is. Voorbeelden van ’dergelijke veranderingen zijn de fusie van bedrijven, de opschoning van een applicatieportfolio van enkele duizenden applicaties en het ingrijpend veranderen van bedrijfsprocessen. De sleutel tot intellectual manageability is Enterprise Ontology. Het probleem dat aangepakt wordt met organizational concinnity is dat organisaties vrijwel altijd een onsamenhangend geheel zijn van nijvere mensen, verdeeld in dysfunctionele groepen (werkeenheden, afdelingen, business units enzovoort), die vanwege de onderlinge, onbedoelde, tegenwerkingen maar moeizaam in staat zijn de functies van de enterprise voor zijn stakeholders te realiseren. Volgens DEMO zijn zo’n 90% van alle fouten in organisaties niet te wijten aan fout menselijk handelen, maar aan het verkeerd ontworpen zijn van de organisatie. De sleutel tot de broodnodige organizational concinnity is Enterprise Architecture. Het probleem dat aangepakt wordt met social devotion is de onvrede die veel werknemers hebben ten aanzien van de zingeving van hun werk; deze wordt vaak als laag ervaren. Moderne, veelal hoogopgeleide, werknemers willen de bevoegdheid en verantwoordelijkheid die past bij hun competenties. De nog steeds overheersende Tayloriaanse wijze van organiseren en managen past daar niet meer bij. Met het ideële doel social devotion beoogt Enterprise Engineering passende antwoorden te vinden op deze problematiek. Voor een deel zijn die al besloten in het begrip Enterprise Ontology, voor het overige zullen het expliciete keuzes zijn, vast te leggen in Enterprise Architecture.

2                Beschrijving

DEMO is een methodiek voor het (her)ontwerpen en (her)inrichten van organisaties en van netwerken van organisaties, die voortdurend in ontwikkeling zijn. Daarmee bestrijkt DEMO een steeds groter gebied binnen Enterprise Engineering. Tot op heden heeft de nadruk gelegen op het praktisch bruikbaar maken van het begrip Enterprise Ontology, waarvoor de PSI-theorie het belangrijkste theoretische fundament is. PSI staat voor Performance in Social Interaction, het fundamentele werkingsprincipe van organisaties. De PSI-theorie is zelf weer geworteld in de theorie van het communicatieve handelen van Habermas, de conversatietheorie van Winograd en Flores, de ontologische systeemtheorie van Bunge en de feitenlogica van Wittgenstein.

De werking van elke organisatie bestaat er uit dat actoren transacties uitvoeren. Bij elke transactie zijn twee actorrollen betrokken: de initiator en de executor. De initiator doet het verzoek om een nieuw productiefeit tot stand te brengen en zal uiteindelijk het resultaat accepteren. De executor belooft het gevraagde tot stand te brengen en zal dat ook doen. Een actorrol kan het best worden opgevat als het nodig hebben van bekwaamheden om bevoegd en verantwoordelijk te zijn voor het uitvoeren van de overeengekomen waardecreatie.

De PSI-theorie kent vier axioma’s:

1. Het Operation Axiom stelt dat de actoren in een organisatie twee soorten acties verrichten: coördinatieacties en Het effect van een productieactie is de creatie van een nieuw feit, zoals het fabriceren van een materieel goed, het leveren van een dienst, het nemen van een besluit of het vellen van een oordeel. Het effect van een coördinatieactie is het aangaan van een ‘commitment’ betreffende een productieactie, zoals het verzoeken om een dienst en het beloven die te leveren. Een belangrijke praktische waarde van het operatieaxioma is dat actoren een duidelijke bevoegdheid en verantwoordelijkheid hebben, verworven op basis van hun competenties.
2. Het Transaction Axiom stelt dat coördinatieacties en productieacties steeds voorkomen in een universeel patroon, de transactie geheten. Het complete transactie- patroon omvat een twintigtal coördinatieacties rondom één productieactie. Elke operationele activiteit in elke enterprise kan op deze manier worden begrepen. Een belangrijke praktische waarde van het transactieaxioma is dat het stilzwijgende coördinatieacties onderkent; die zijn een voorname oorzaak van het falen van
3. Het Composition Axiom stelt dat het constructiemodel van een organisatie een netwerk is van actorrollen en transactiesoorten. Elk transactiesoort heeft precies één actorrol als executor (die verricht de productieactie) en een of meer actor-rollen als initiator. Omgekeerd is elke actorrol de executor van slechts één transactiesoort, maar kan die van meerdere transactiesoorten de initiator zijn. Een belangrijke praktische waarde van het compositieaxioma is dat het laat zien dat elk bedrijfsproces een boomstructuur van actoren en transacties
4. Het Distinction Axiom stelt dat mensen drie verschillende kwaliteiten gebruiken bij het verrichten van coördinatieacties en productieacties: de performa-, de informa- en de forma-kwaliteit (zie figuur 1).

DEMO maakt in de Enterprise Ontology onderscheid tussen de constructie en de functie van een onderneming of systeem in het algemeen. Dit onderscheid is van fundamenteel belang [Dietz, 2008]. Constructie is een objectief begrip: een systeem ‘is’ zijn constructie, kan men zeggen. Functie is een subjectief begrip, het is een relatie tussen de constructie en een belanghebbende (stakeholder). Deze vaststelling heeft twee belangrijke consequenties. De eerste is dat men niet kan spreken van dé functie van een systeem; elk systeem kan minstens zo veel functies hebben als er belanghebbenden zijn. Dit laat onverlet dat een ontworpen systeem een beoogde functie heeft voor een groep belanghebbenden. De tweede consequentie is dat de waarde van functionele modellen slechts het beter begrijpen van de functie(s) van een systeem is, en dat discussie over de juistheid ervan geen zin heeft; functie is immers een subjectief begrip. In het Generic System Development Process (GSDP, zie figuur 2) wordt het onderscheid tussen functie en constructie zichtbaar, alsmede de rol van ontologie, architectuur, en technologie.

Op de vier axioma’s van de PSI-theorie is het Organization Theorem gedefinieerd. Dat stelt dat een organisatie een integraal geheel is van drie aspectorganisaties: de B- organisatie (B van business), de I-organisatie (I van informatie) en de D-organisatie (D van data en document). De D-organisatie ondersteunt de I-organisatie en de I- organisatie ondersteunt de B-organisatie. Het verband ertussen moet men als volgt begrijpen. De functie van de D-organisatie ondersteunt de constructie van de I-organisatie, en de functie van de I-organisatie ondersteunt de constructie van de B-organisatie. De functie van de B-organisatie is het ondersteunen van de belanghebbenden in de omgeving van de enterprise, zoals de klanten. Elk van de aspectorganisaties kan geheel of gedeeltelijk worden vervangen door IT-applicaties. In DEMO spreekt men van B-applicaties, I-applicaties en D-applicaties (zie figuur 3). Volgens de PSI- theorie kunnen B-actoren nooit worden vervangen, maar wel verregaand worden ondersteund door B-applicaties. De combinatie van het organisatietheorema en het GSDP (en nog wat zaken) levert de BEEM op (Basic Enterprise Engineering Map) [Dipten, 2011].

DEMO Modellen

Het ontologische model van een organisatie in DEMO bestaat uit vier samenhangen- de deelmodellen, die elk een view zijn op het integrale model en samen de constructie en de werking van de organisatie voorstellen: Construction Model, Process Model, Fact Model en Action Model.

Construction Model

In het constructiemodel wordt vastgelegd welke actorrollen er zijn en welke transactiesoorten door deze actorrollen worden uitgevoerd. Bovendien wordt aangegeven tot welke transactiebanken de actorrollen toegang moeten en mogen hebben. Omdat alle (productie)feiten het resultaat zijn van een transactie, zijn deze bronnen één op één gekoppeld aan transactiesoorten. Met de term ‘transactiebank’ wordt de toestandsinterpretatie van een transactie bedoeld, in tegenstelling tot de procesinter- pretatie.

Process Model

Het procesmodel toont hoe transacties onderling samenhangen, ofwel hoe ze zijn ver- bonden in boomstructuren. Er zijn twee relaties mogelijk tussen transacties: causale en conditionele. Een causale relatie geeft aan dat een transactie wordt geïnitieerd vanuit een andere. Een conditionele relatie geeft aan dat een transactie moet wachten met zijn verdere afwikkeling op de voortgang van een andere transactie.

Fact Model

Het feitenmodel toont de toestandsruimte en de transitieruimte van de productie- wereld. Anders gezegd, het laat de business objects, de business facts en de business laws zien. Een business law is een declaratieve business rule. Een voorbeeld daarvan is: iemand mag maar één auto tegelijkertijd huren.

Action Model

In het actiemodel worden de van toepassing zijnde (imperatieve) business rules vastgelegd. Een business rule is de operationele tegenhanger van een business law. Een voorbeeld: als iemand een auto wil huren en hij of zij heeft geen geldig rijbewijs, dan gaat de nieuwe huur niet door.

3                Positionering

Denkwijze

DEMO is stevig geworteld in de theoretische fundamenten van Enterprise Engineering. De belangrijkste theorie is de hierboven besproken PSI-theorie, beschreven door Dietz [Dietz, 2006; Dietz, 2011]. DEMO is sterk gericht op het ontwerpen van de enterprise en besteedt ook aandacht aan het verwezenlijken van de beoogde veranderingen. Het besturen van de architectuurfunctie maakt geen onderdeel uit van de methode.

Beheer- en exploitatiewijze eigenaar

De DEMO-methodiek wordt beheerd door het Enterprise Engineering Institute2, voorheen het DEMO Kenniscentrum. DEMO-1 heeft vanaf 1996 tot 2006 bestaan. De huidige versie is DEMO-2; die is volledig beschreven in [Dietz, 2006]. In het na- jaar van 2012 is DEMO-3 van kracht geworden. De inleiding in DEMO-3 bestaat uit [Dietz, 2011] en [Perinforma, 2012].

Tot de doelstellingen van het Enterprise Engineering Institute behoren:

• Het verbreiden van de kennis over en de toepassing van
• Het beheren van DEMO als open
• Het stimuleren van opleidingen in
• Het vaststellen van opleidingsniveaus; momenteel zijn dat DEMO Professional en DEMO
• Het afnemen van examens DEMO Professional en DEMO
• Het bijhouden van een register van DEMO Professionals en DEMO
• Het organiseren van bijeenkomsten voor personen die gebruik (willen) maken van DEMO.

Anno 2012 zijn er 400 DEMO Professionals en 20 DEMO Masters. De opleiding DEMO Professional is o.a. gelicenseerd aan Sapio bv, de VIA Groep en Capgemini Academy, aan de universiteiten van Delft, Antwerpen en Lissabon, en aan het NOVI.

Beheer- en exploitatiewijze gebruiker

Er bestaat geen voorgeschreven beheer- en exploitatiewijze voor de gebruikers van DEMO.

Werkwijze

DEMO omvat een gestructureerde werkwijze om de essentie van een organisatie te modelleren. Die is beschreven in [Dietz, 2006 en Perinforma, 2012].

Representatie- en modelleerwijze

De modelleer- en representatiewijze van DEMO is te vinden in [Dietz, 2006] (DEMO-2) en [Perinforma, 2012] (DEMO-3).

Ondersteuningswijze

Veel DEMO-publicaties en casestudies zijn gratis te downloaden (www.ee-institute. com). Daar kan men ook vinden welke softwaretools er beschikbaar zijn.

Bruikbaarheid

DEMO houdt niet expliciet rekening met het implementeren van architectuur en de architectuurvolwassenheid van de organisatie. Het gangbare pad in de praktijk is dat enkele medewerkers van een bedrijf de cursus DEMO Professional volgen; die vormen vervolgens de kern waar vanuit de toepassing en de verbreiding plaatsvindt.

4                Conclusie

DEMO scoort als een relatief complete methode. Aangezien DEMO vooral een denkwijze is, scoort de methode middelmatig op de aspecten werkwijze en bruikbaarheid. Er bestaat een voorgestelde werkwijze voor DEMO, maar deze is niet verplicht. Een ieder kan zelf een werkwijze kiezen zolang de denkwijze maar toegepast wordt. DEMO is gericht op het opstellen van implementatieonafhankelijke modellen, die de essentie van de organisatie weergeven, op basis waarvan deze (her)ontworpen en (her)ingericht kunnen worden. Hiervoor kent DEMO een eigen representatiewijze.

DEMO is een methode in het veld van enterprise-engineering. Binnen dit veld is architectuur gedefinieerd als een set ontwerpprincipes om de ontwerpvrijheid rond functie en constructie in te perken. Deze definitie wijkt af van veel andere methoden. Omdat DEMO zich richt op bedrijfsmodellen is DEMO vooral bruikbaar voor het definiëren en ontwerpen van organisatieveranderingen of het in kaart brengen van de processen die IT-systemen moeten ondersteunen.