Enterprise engineering draait om het “engineeren” van organisaties

Uitdaging
Vroeger was een IT applicatie een hulpmiddel om gegevens op te slaan of
berekeningen uit te voeren. Tegenwoordig helpt IT bij het verkrijgen van (realtime) overzicht in de groeiende hoeveelheid data die beschikbaar komt, bij... bij
optimalisering van processen, etc.
Veel organisaties hebben moeite om de nieuwste mogelijkheden bij te benen. Dit
blijkt wel uit het grote aantal mislukte IT projecten. Cijfers over IT projecten
verschillen per studie. Maar het aantal projecten dat binnen budget en deadline
de functionaliteit biedt die gevraagd werd zijn op een hand te tellen.
Hoe komt dat? En hoe lossen we dit op?
Huidige status
Meer taken van medewerkers kunnen worden ondersteunt met IT applicaties, en deze
applicaties worden ook steeds krachtiger. De mensen in de organisatie en IT systemen
raken dus steeds meer vervlochten.
In en rondom een organisatie zijn verschillende stakeholders met elk hun eigen
wensen: Klanten stellen hogere eisen, medewerkers op de werkvloer willen minder
gedoe, managers willen inzicht in hun afdeling en de directie wil overzicht van wat er in
het bedrijf gebeurt. En natuurlijk zijn er IT leveranciers die hun nieuwste producten en
diensten willen verkopen.
Van allerlei kanten zijn er dus krachten die meesturen in beslissingen over IT- en
organisatie inrichting. In de praktijk leiden duw- en trekwerk tot een compromis waar
niemand echt gelukkig mee is: De Business krijgt niet de functionaliteit die verwacht
werd, de IT-ers proberen een applicatie te bouwen zonder precies te weten wat nodig
is en de directie wordt geconfronteerd met gemiste deadlines en budget
overschrijdingen.
Gebrek aan overzicht en inzicht
Studies wijzen uit dat veel problemen voortkomen uit gebrekkige requirements en
specificaties. Vanuit de IT is er onvoldoende domeinkennis om zinvolle keuzes te
maken. Hoe meer beslissingen de programmeurs moeten maken des te verder staat
de functionaliteit van de applicatie af van de wensen van de opdrachtgever.
Maar ook vanuit de Business is er onvoldoende zicht op de gewenste functionaliteit.
Gedurende het project formuleren opdrachtgevers steeds nieuwe eisen en wijzigen
bestaande wensen. Dit heeft tot gevolg dat steeds een deel van het werk opnieuw
gedaan moet worden. De IT-ers schieten als het ware op een bewegend doel.
Engineering Sciences
In alle engineering sciences
gelden bepaalde wetten die het
gedrag van elementen verklaren.
Ook zijn theorieën en methoden
ontwikkeld aan de hand waarvan
ingenieurs dingen (artefacten)
kunnen bouwen.
Civiele
enginieurs
houden
bijvoorbeeld rekening met de
zwaartekracht
en
materiaal
wetten bij het bouwen van
bruggen.
Ook
hebben
ze
methodes ontwikkeld om de
zodanig bouwstenen in elkaar te
zetten dat ze niet omvallen tijdens
de bouw.
Software Engineering is een jonge
wetenschap. Er is dus nog volop
behoefte aan theorieën en
methodes om zover te komen dat
IT projecten niet meer (zo vaak)
falen en precies doen wat vooraf
beloofd is. DEMO is zo’n methode.
DEMO: Het DNA van de organisatie
“Geïntegreerde kracht van sociale wetenschappen, filosofie en
informatiekunde”
Enterprise Engineering en DEMO
Enterprise engineering draait om het “engineeren” van organisaties. DEMO is de
methode.
Gemeenschappelijke taal
Vanuit zijn eigen achtergrond heeft iedereen ook zijn eigen blik op de organisatie en
de wereld. In de hectiek van alledag is het lastig om ook alle visies van andere
stakeholders te bevatten.
Het Enterprise Engineering vakgebied omvat elementen uit organisatiekunde,
sociale wetenschappen, filosofie en informatiekunde. Het geheel biedt een
eenduidige blik op organisaties waar ook niet-techneuten? mee uit de voeten
kunnen.
Enterprise Engineering en IT Engineering
De eerste stap bij implementatie van een nieuw IT systeem is het verkrijgen van
inzicht en overzicht. Wat doen we nu precies? En hoe kan dat beter?
DEMO is een wetenschappelijk gefundeerde denkwijze. Het fundament bestaat uit
vier axioma’s. Gezamelijk biedt dat een compleet, coherent, beknopt en consistent
weergave van de essentie van de organisatie (C4E).
Transacties
In DEMO verlopen processtappen in transacties. Een proces bestaat doorgaans uit
meerdere transacties.
Voorbeeld transactie - 1
Stel: Je wil graag een bos rode
rozen hebben.
Dan ga je naar de bloemist en
vraag je om rode rozen, dit is een
verzoek. Als de bloemist rode
rozen op voorraad heeft dan zegt
hij: ”Natuurlijk meneer.” Dit is een
belofte. Vervolgens pakt hij rozen
samen in cellofaan en bindt er een
elastiekje omheen. Dit is een
productiefeit. Als de bloemist de
bloemen op de toonbank legt zegt
hij:
“Alsjeblieft.”
Daarmee
verklaart hij datgene geleverd te
hebben wat hij eerder beloofde.
Als de klant tevreden is met de
bloemen zal hij die accepteren,
meestal met een bedankje.
Onderstaande illustratie toont hoe
dit verloopt.
DEMO maakt een duidelijk onderscheid tussen enerzijds de productie van nieuwe
“dingen” en anderzijds de communicatie daarover.
In de kolom hiernaast staat een eenvoudig voorbeeld. Elk proces volgt precies
hetzelfde stramien: Een initiator verzoekt iets, een executor belooft het te zullen
doen, vervolgens produceert hij het gevraagde en biedt dit aan aan de initiator,
welke het accepteert.
Het resultaat is een overzichtelijk patroon, dat helder weergeeft waar de
verantwoordelijkheden, competenties en commitments (zouden moeten) liggen. Ook
alle alle “non-happy flows” zijn standaard meegenomen. Iedere stakeholder ziet
dezelfde organisatie.
Voor een goed overzicht is het belangrijk om naar de kern van de organisatie te
kijken.
In DEMO is de betaling van een bos
rozen overigens een aparte
transactie. Het betalingsproces
verloopt volgens precies hetzelfde
patroon, maar nu is de bloemist de
initiator en de klant de executor.
DEMO: Mensgericht en Resultaatgericht
Constructie
Een organisatie is een systeem van mensen die samen gecoördineerd een product
voor hun klant leveren. Zoals elk systeem bestaat ook een organisatie uit
DEMO: Simple & Essential
Overzicht: Onderscheid hoofd- en bijzaken
Voor een goed overzicht is het denken in transacties een eerste stap, want een
hele reeks aan mogelijke stappen wordt samengevat in een paar simpele figuurtjes.
Niet elke transactie is hetzelfde en is even belangrijk voor een goed overzicht.
DEMO onderscheidt drie niveaus in een organisatie; datalogisch, infologisch en
ontologisch. De ontologische laag geeft de kern van de business weer, welke
ondersteunt wordt met informatie die voortkomt uit data.
Diep inzicht: 4 Aspectmodellen
De essentie van de organisatie ligt op het Business-niveau. Een DEMO model
bestaat uit 4 geïntegreerde aspectmodellen.
Het Constructie Model (ook Communicatie Model genoemd) heeft het hoogste
abstractieniveau. Het toont slechts de rollen die mensen op zich nemen en de
transacties tussen hen.
Het Proces Model toont de relatie tussen verschillende transacties. Gebeuren ze
opeenvolgend of simultaan, of zijn ze compleet onafhankelijk.
Het Actie Model bevat de werkinstructies en business rules. “Als in transactie X
situatie Y zich voordat dan geldt Z.“
Het Feiten model (ook State Model genoemd) geeft de specificatie van de
toestandsruimte (State space??) van de productie kant van de organisatie. Het
beschrijft de object klassen, de feit types en de resultaat types, alsook de
existentiële relaties die van toepassing zijn. Het is vergelijkbaar met een Object
Relatonal Mapping (ORM).
In de praktijk blijkt voor veel toepassingen het Constructie Model te volstaan, maar
voor meer diepgang zijn de andere modellen nodig. Alle 4 modellen zijn met elkaar
verbonden en bieden gezamenlijk een geïntegreerd beeld..
Voorbeeld transactie - 2
Elk verzoek, belofte, verklaring
en
acceptatie
van
een
productiefeit is niet zomaar een
klein feitje. Het is een (juridisch)
commitment. Deze commitments
kunnen expliciet, maar ook
impliciet
gegeven
worden.
Bijvoorbeeld het aannemen van
de bloemen zonder iets te
zeggen is nog nog steeds een
acceptatie van die bloemen.
De illustratie op de vorige pagina
toont de “happy flow” van een
proces.
Maar wat als er geen happy flow
is?
Bij elke transactie stap is ook een
“unhappy flow” mogelijk. De
uitzonderingssituaties wanneer
een verzoek geweigderd wordt,
of herroepen omdat iemand van
inzicht verandert: “Ik wil eigenlijk
toch liever gele tulpen.” Of “Deze
bloemen zijn verwelkt, ik wil
graag andere.” Ook dit zit
standaard
in
een
DEMO
transactie. Hiervoor is een
uitgebreide figuur die te groot is
om hier weer te geven. Maar
omdat
ook
dit
allemaal
standaardpatronen zijn volstaat
het
figuurtje
van
twee
rechthoeken en een cirkel met
ruit.
Voorbeeld Constructie Model
Implementatie onafhankelijk
DEMO modellen geven pocessen weer zonder uitspraken te doen over hoe deze
geïmplementeerd zouden moeten worden.
f
DEMO als “Organisatie DNA”
In de natuur is een enorme
verscheidenheid
aan
levensvormen. Elke soort heeft zijn eigen
ontwerp, en elke individuele plant
of dier heeft zijn eigen kleine
afwijkingen, vastgelegd in het
DNA.
DNA bestaat uit 2 basenparen die
in bijna oneindig veel combinaties
geordend kunnen worden.
Op vergelijkbare manier bestaan
DEMO
transacties
uit
4
commitments tussen 2 mensen.
Een serie transacties vormt een
proces en alle processen samen
vormen de organisatie. Veel
organisaties lijken op elkaar, maar
verschillen op details. DEMO helpt
om dit inzichtelijk te maken.
DEMO samengevat
Organisatie denken vanuit DEMO:





Overzicht
Inzicht
Heldere Communicatie
Coördinatie in processen
Duidelijke
verantwoordelijkheden
Het Enterprise Engineering Consortium
De toepassing van DEMO in de praktijk neemt toe en het aantal
gecertificeerden groeit hard.
Een aantal bedrijven ziet de toegevoegde waarde van DEMO en wil dit
gezamenlijk uitdragen in de markt. Hiervoor is het Enterprise
Engineering Consortium (EEC) opgericht. Binnen het EEC is veel
ervarig met de toepassing van DEMO. De meeste leden hebben ook
actief bijgedragen aan wetenschappelijk onderzoek naar de
toepasbaarheid van DEMO in de praktijk.
Enterprise Engineering Consortium
www.ee-consortium.nl
[email protected]