Deze werkwijze boezemd mij angst in. Ik
vermoed namelijk dat het onzekerheidsprincipe
van Heisenberg op de hierboven beschreven
werkwijze van toepassing is dier voege dat het
'meten' dat onderdeel is van corporate modelling
hetgeen gemeten wordt beinvloed. Is hier al onderzoek naar verricht?
Voorts ben ik van mening dat processen
in een organisatie van een dusdanige complexiteit
zijn, dat zij nauwelijks te modelleren zijn. Als
dit wel het geval zou zijn zou een perfecte
simulatie van een bedrijf de werkelijke processen
- en daarmee wellicht het gehele bedrijf -
overbodig maken.
Voor wat betreft het door u genoemde
voorbeeld voor het in kaart brengen van
de 'huidige en toekomstige werkwijze' van
het implementeren van informatiesystemen,
verwacht ik weerstand van de softwareontwikkelaars.


Justus de Broeckenaere

Foei, Vader!

boezemt is natuurlijk met een 't'.

Geachte heer De Broeckenaere,

Het is natuurlijk alijd zo dat een gemeten eenheid of entiteit een afwijkend gedrag vertoond wanneer deze wordt gemeten. Echter met behulp van diverse methoden die al jaren in de traditionele arbeidskunde worden toegepast kan het zogenoemde meeteffect worden gereduceerd tot nagenoeg nul (en ja hier is erg veel onderzoek naar gedaan). Daarnaast is het zo dat de infomatie over de te modelleren processen voornamelijk wordt vergaard door middel van het interviewen van de betrokkenen. Bovenal kan het natuurlijk niet zo zijn dat niet meten beter zou zijn dan meten met een vooraf te definieren foutkans. Hoe is het anders mogelijk om processen te beheersen en additioneel te optimaliseren.

Omtrent u opmerking inzake de onmogelijkheden van het in kaart brengen, en dus het beheersen, van complexe processen kan ik kort zijn. Deze methodiek geeft als vrijwel alle andere methodieken een vereenvoudigd beeld van de werkelijkheid. Voornamelijk wordt een keuze gemaakt uit juist die processen die kritisch zijn voor het behalen van bedrijfsdoelstellingen met als doel deze processen dermate te beheersen dat op basis van rationele overwegingen de uitkomsten van deze processen kunnen worden gereguleerd.

Uw opmerking inzake de weerstand van software-ontwikkelaars vind ik dubieus. Als de weerstand van software-ontwikkelaars een bedrijf ervan weerhoudt om het inzicht in de eigen organisatie in eigen hand te nemen dan stelt dat bedrijf zich erg onderdanig op. De te ontwikkelen software is namelijk primair ondersteunend aan de – als het goed is door de organisatie – gedefinieerde processen. Het is tevens ook nog altijd zo dat een te grote vrijheid van software-ontwikkelaars leidt tot een kloof tussen het gewenste resultaat en de opgeleverde software.

Om een model op te kunnen stellen zullen er regels moeten zijn die beschrijven hoe de werkelijkheid moet worden omgezet in een model. Deze regels kunnen wij zien als een taal. Een natuurlijke taal kent een grammatica. Ook een modelleringsmethode kent een grammatica. Hiernaast kent een taal een alfabet en eventueeel een vocabulair. Een model dient ook een alfabet te hebben. Dit alfabet beschrijft - in het geval van een model - de bouwstenen die gebruikt kunnen worden voor het opstellen van het model (bijvoorbeeld bolletjes en pijltjes, lijsten van gebeurtenissen, cijfers etc.)
Aangezien u met corporate modelling modellen maakt van 'processen die kritisch zijn voor het behalen van bedrijfsdoelstellingen met als doel deze processen dermate te beheersen dat op basis van rationele overwegingen de uitkomsten van deze processen kunnen worden gereguleerd', zullen de regels waar deze modelleringsmethode op gebaseerd zeer strikt moeten zijn en een - zij het vereenvoudigde - correcte weergave van de werkelijkheid moeten zijn. U pleit er immers voor te sturen op basis van een model en dit is slechts acceptabel als het model goed inelkaar zit.
Om hieraan te voldoen moet de taal van het model goed gedefinieerd zijn. Immers, als twee verschillende personenen een en hetzelfde proces gaan modelleren, dan zouden er twee exact dezelfde modellen uit moeten komen, ofwel; de sturinginsacties op basis van beide modellen zouden tot gelijke resultaten moeten leiden.
Ik zit vraagtekens bij de mate waarin de regels voor corportate modelling wel goed zijn beschreven. U spreekt namelijk over 'relevante aspecten van processen', maar hoe wordt bepaald wat relevant is en op basis van welke regels?
U stelt: 'Corporate Modelling met een goede case tool biedt geïntegreerd en up-to- date inzicht in de aspecten van de processen binnen de totale organisatie.' Waarin wordt corporate modelling geintegreerd? Het lijkt mij niet goed om een modellering te integreren in wat dan ook. Een model is immers een beschrijving van het een of ander en een beschrijving dient geen onderdeel te zijn van datgene wat het beschrijft. Of wordt het in iets anders geintegreerd zien?
Voor wat betreft de weerstand van de software-ontwikkelaars kan u het volgende zeggen. Software-ontwikkelaars zijn opgeleide modelleerders. Zij dienen de werkelijkeheid om te zetten in door machines uit te voeren instructies (op basis van een model). Als er iets aan het model niet klopt, werkt de software niet. Zo simpel is het. Zij worden dus gedwongen gebruik te maken van modelleringsmethoden en talen die strenge regels kennen. Elke afwijking van de regels leidt tot bugs in de opgeleverde software.
"Corporate Models zullen leiden tot bugs in de organisatie", zullen de software-ontwikkelaars terecht zeggen, want zij hebben nooit specificaties van de modelleringsmethode gezien. Zonder die specificaties zal het gebruik van de methode worden afgedaan als zinloos.
Of zijn die specificaties wel beschikbaar?


Justus de Broeckenaere

1 2 3 test?
marcheert deze discussie thans nog of wat?