Het beschrijven van processen binnen bedrijven heeft de afgelopen 20 jaar een reeks grote veranderingen doorgemaakt. Vroeger werden processen decentraal en meestal op papier vastgelegd. Tegenwoordig hebben organisaties steeds meer keuze uit modelleringstools waarmee de bestaande processen kunnen worden beschreven en de gewenste processen kunnen worden gedefinieerd. Een onderscheid kan worden gemaakt tussen tekenpakketen als Flowcharter en MS-VISIO en case tools als ARIS, Bwise of Protos waarmee complexe informatiesystemen kunnen worden gemodelleerd, gesimuleerd en met behulp van webpublicaties worden gepresenteerd op bijvoorbeeld een aanwezig intranet.
Dit artikel zal globaal een vorm van procesmodellering beschrijven, Corporate Modelling genoemd, die mogelijk is geworden door de beschikba...
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
boezemt is natuurlijk met een 't'.
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.
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
marcheert deze discussie thans nog of wat?