• startpagina
• diensten
• samenwerking
• publicaties
• The Xpragmatic View
• archief
• Snippets of an Incomplete Mind
• auteursrecht
• wettelijke vermeldingen
• nieuws
• over xpragma
• contactinfo

BPPM2 - Een brug te ver

The Xpragmatic View #50
17 september 2002
door Marc Buyens (@mbuyens), Xpragma
marc.buyens@xpragma.be
url: http://www.xpragma.be/view50.php
Downloaden als een PDF-file

BPPM (Business Process Performance Management / Measurement / Monitoring) komt stilaan meer en meer in de belangstelling. Beheer en controle van bedrijfsprocessen is in feite een logische evolutie van de gekende EAI en BPM oplossingen. Heel wat BPPM-achtige functionaliteit is dan ook reeds beschikbaar vandaag. Echter, een aantal bedrijven hebben de reële toegevoegde waarde van BPPM onderkend en willen nog een stap verder gaan. Maar die stap verder lijkt vandaag nog een beetje té ver...

De voorbije weken was er in bepaalde discussieforums weer wat (hernieuwde) belangstelling voor een concept dat meestal wordt aangeduid met de term "BPPM" (Business Process Performance Management / Measurement / Monitoring). Zoals al gesteld, BPPM is een logische evolutie van de diverse EAI en BPM oplossingen. Maar wat is er dan zo speciaal aan BPPM?

Traditionele EAI

Zoals de naam al suggereert heeft BPPM iets te maken met het beheren, het meten en het in de gaten houden van de "performantie" van bedrijfsprocessen. Nu moeten we vaststellen dat de eerste generatie EAI oplossingen niet echt sterk waren in dit soort zaken. EAI oplossingen hielden zich vooral bezig met het op een efficiënte en veilige manier overbrengen van informatie van de ene omgeving naar de andere, een taak die op zich al moeilijk genoeg was.

Wat er bijkomend als beheersmogelijkheden werd aangeboden was meestal zeer beperkt en was volledig gericht op het in de gaten houden van de integratietaken zelf. Voor enig serieus niveau van controle moest je gaan aankloppen bij de leveranciers van gespecialiseerde management oplossingen, maar ook daar was de focus volledig gericht op de opvolging van de technische aspecten van de integratietaken.

Natuurlijk waren er toen reeds bedrijven zoals Vitria Technology, die een visie hadden van wat de verdere evolutie zou moeten zijn. Zij waren ervan overtuigd dat de uiteindelijke doelstelling van EAI niet beperkt zou blijven tot het aaneenknopen van diverse bedrijfsomgevingen, maar de basis kon geven voor een betere bedrijfsvoering. Maar ook bij dergelijke bedrijven was de initiële BPPM functionaliteit nog zeer beperkt.

Samen met het succes van EAI kwam er dan het besef dat een meer procesgerichte aanpak noodzakelijk was. En dat werd op allerlei manieren ingevuld. Het meest zichtbare daarvan was de introductie van allerlei grafische hulpmiddelen die het moesten mogelijk maken de bedrijfsprocessen en de integratietaken te visualiseren. In beperktere mate werd er ook gewerkt aan bijkomende controle en supervisie.

De realiteit bleef echter dat de actieradius van al deze bijkomende functionaliteit beperkt bleef tot die gedeelten van het bedrijfsproces die van belang waren voor de integratietaak. Men had dus nooit een zicht op het complete proces, laat staan op het functioneren van de ganse onderneming. Ook moeten we vaststellen dat de doelstelling bij de introductie van deze nieuwe hulpmiddelen niet zozeer BPPM was, maar veeleer een poging om de complexiteit van de integratietaak te verminderen door het aanbieden van een "hoger" niveau van interactie met het EAI-product.

BPM: niet echt anders

Met de nieuwere generatie van BPM (Business Process Management) oplossingen is deze situatie niet fundamenteel gewijzigd. De aspecten van beheer, controle, meting, e.d. blijven beperkt tot die gedeelten van de bedrijfsactiviteit die geautomatiseerd worden gebruik makend van de BPM oplossing. In de meeste gevallen is echter het niveau van beheer, controle en meting beduidend hoger en vollediger dan in een EAI oplossing. Men richt zich ook veel meer op echt bedrijfsgerelateerde informatie en minder op de onderliggende techniciteit.

Al deze bijkomende hulpmiddelen en beheersinstrumenten kunnen een duidelijke toegevoegde waarde bieden aan een onderneming. Voor velen zal het immers al een heel succes zijn indien ze een beter zicht kunnen krijgen op en meer controle kunnen verwerven over één enkel kritisch deel van de bedrijfsactiviteit. Anderzijds, als je dan vaststelt wat er mogelijk is voor dat ene deelgebied, dan is de vraag om dit ook te hebben voor de rest van je onderneming niet ver weg.

De belofte van BPPM

Maar tussen die wens en de realisatie ervan is er nog heel wat weg af te leggen. Een "echte" BPPM oplossing moet je immers kunnen implementeren voor om het even welk deel (of het geheel) van je bedrijfsprocessen zonder dat er de noodzaak is dat die processen zelf aan mekaar geknoopt zijn via een EAI oplossing, of dat ze BPM-geautomatiseerd zijn. Hierbij moeten we wel aanstippen dat de BPPM oplossing zelf in grote mate gebruik zal maken van EAI- en BPM-achtige technologie.

De echte waarde van BPPM schuilt daarbij in het real-time karakter. We kennen reeds sinds jaren allerlei soorten van scorecards, management consoles, knowledge databases, enz. Alhoewel al deze hulpmiddelen wel degelijk hun belang hebben, blijft het een realiteit dat de besluitvorming zich meestal moet baseren op geconsolideerde informatie die is verzameld gedurende een bepaalde periode, ook al is die periode misschien maar één dag. Het "zicht" op de bedrijfsomgeving is dus eerder "near-time" dan werkelijk real-time.

Met BPPM zou dit anders kunnen zijn. De meeste EAI en BPM technologieën zijn immers in grote mate "event based" en zij gaan dus voornamelijk (nagenoeg uitsluitend) om met real-time informatie. Managers hopen nu dat een soortgelijke real-time informatieverwerking zou kunnen doorgetrokken worden naar de hoogste niveaus van de bedrijfsvoering.

Daarom kunnen we het huidige aanbod aan BPPM oplossingen zeker niet zien als een eindpunt. Het is wat we zouden kunnen noemen "BPPM Level 1": het beheer, de controle en de supervisie van die gedeelten van de bedrijfsomgeving die reeds geautomatiseerd zijn op basis van een of andere EAI of BPM technologie. Een prachtig resultaat, misschien meer dan we gehoopt hadden, maar niet genoeg...

BPPM Level 2 (BPPM2)

Zoals we al kunnen verwachten bestaat de mission statement van BPPM2 erin een real-time end-to-end beheer (= planning, design, implementatie, uitvoering en controle) van de extended enterprise mogelijk te maken over alle bedrijfsprocessen heen. De focus is daarbij duidelijk op de echte bedrijfsactiviteit en -opportuniteit gericht en niet op het technisch beheer van de onderliggende processen.

Zoals deze paragraaf al suggereert, zullen dus nog een aantal andere beheersoplossingen het meer technische gedeelte van de controle en opvolging voor hun rekening moeten nemen. Ik weet dat de traditionele leveranciers van beheersoplossingen zullen argumenteren dat BPPM2 een natuurlijke evolutie is van hun huidige producten en dat dus één enkele oplossing uiteindelijk zal volstaan. Ik begrijp hun argumentatie, maar ik blijf een voorstander van twee duidelijk gescheiden management omgevingen.

De reden hiervoor is vrij fundamenteel. In de bedrijfswereld zal er nooit zoiets zijn als 100% flexibiliteit. Je kan het eenvoudig niet toelaten dat voor elke behoefte aan verandering de totaliteit van je bedrijfsprocessen in vraag wordt gesteld. Er moeten dus deelgebieden worden afgebakend die niet steeds weer in vraag worden gesteld, maar die voor langere tijd "vast" blijven.

In ons jargon wordt dit meestal de "architectuur" genoemd. Wat we hiermee bedoelen is: dat deel van de organisatie, de procedures, de processen, de IT-omgeving, de gebruikte standaarden, enz. dat bepaald wordt en beheerd wordt op basis van een aantal lange termijn strategische keuzes. Deze laatste vinden natuurlijk hun basis in de globale bedrijfsstrategie.

Dit betekent echter niet dat een dergelijke architectuur niet kan wijzigen. Integendeel! Ook de architectuur is verplicht continu te evolueren i.f.v. wijzigende marktomstandigheden. De algemene principes en de richtlijnen voor deze veranderingen zijn echter gebaseerd op lange termijn doelstellingen en veranderen dus minder. Bijgevolg kan en moet het beheer van de architectuur in grote mate losstaan van het beheer en de supervisie van de meer "tactische" initiatieven van de onderneming.

Het "agile" deel van de bedrijfsomgeving steunt op de mogelijkheden die aangeboden worden door deze architectuur, maar de aansturing van dit "agile" deel is gebaseerd op een volledig andere set van principes. Dit fundamentele verschil in management paradigma maakt het volgens ons onmogelijk dat beiden door hetzelfde management platform worden beheerd. Het is immers onvermijdelijk dat er situaties ontstaan die door de architectuur als foutcondities dienen geïnterpreteerd, terwijl ze voor het "agile" deel van de bedrijfsomgeving alle kenmerken vertonen van een opportuniteit.

Maar laat ons verder gaan met de BPPM Level 2 discussie.

Een basisarchitectuur

Ik denk wel dat het voor iedereen zal duidelijk zijn dat de uitwerking van een echte BPPM2 omgeving geen eenvoudige opdracht is. Toch kunnen we stellen dat de basisprincipes vrij eenvoudig zijn.

In feite willen we dus aan managers een platform aanbieden dat hun de mogelijkheid geeft om zelf de planning, de design, de implementatie, de uitvoering en de controle van de ganse onderneming aan te sturen, daarbij hun beslissingen baserend op real-time informatie.

Het makkelijkste stuk is de interface. Wat je daar verwacht is een grafische interface die de mogelijkheid biedt om processen te visualiseren en te wijzigen, bedrijfslogica te bouwen, uitzonderingen te definiëren, enz. Dit is in feite wat we reeds in grote mate in de meer recente BPM oplossingen terugvinden en de realisatie ervan kan dus niet al te moeilijk zijn.

Vervolgens heb je een runtime omgeving nodig voor de uitvoering van al deze logica. Hier wordt het al een beetje moeilijker. Alhoewel de vereiste functionaliteit sterk aanleunt bij BPM-achtige benaderingen is het toch niet te vermijden dat de onderliggende basis hier een zwaargewicht EAI-oplossing moet zijn. Er moeten immers massale hoeveelheden real-time "events" worden verwerkt, dus hier hebben we minimum het soort engine nodig dat te vinden is in een aantal moderne broker oplossingen.

Het echt moeilijke werk start wanneer we gaan bepalen welke "objecten" en welke informatie beschikbaar zullen zijn voor het gebruik in de logica die de managers zullen opbouwen. In theorie zou je natuurlijk willen dat om het even welk object hiervoor beschikbaar is, maar de werkelijkheid is natuurlijk wel even anders. Managers mogen dan wel de logica aansturen om bepaalde objecten te gebruiken, de manier waarop deze objecten interageren met de technische infrastructuur moet een verantwoordelijkheid blijven voor de architectuur jongens.

Zowel EAI- als BPM-oplossingen bieden een aantal "hooks" om de interactie met diverse omgevingen mogelijk te maken, maar het zal steeds onvoldoende zijn. Ook kan men er zich aan verwachten meerdere van dergelijke technologieën binnen hetzelfde bedrijf terug te vinden.

Toegang krijgen tot de nodige "objecten" zal dus een hele opdracht zijn, wat zich wellicht zal vertalen in een gigantisch integratieproject. Daarbij zal het van het grootste belang zijn de noodzakelijke effort duidelijk af te wegen tegen het potentiële bedrijfsvoordeel. Op zich is dit al een hele uitdaging. Persoonlijk zou ik voorstellen dit te vertalen in een aantal duidelijke richtlijnen voor de verantwoordelijken voor de architectuur om er voor te zorgen dat zij op continue wijze de nodige additionele objecten ter beschikking stellen van de "agile" bedrijfsomgeving.

Tot slot zullen de bedrijfsleiders ook logica willen bouwen die zich baseert op geconsolideerde informatie. Dit zal maken dat men een soort message of event store zal dienen op te bouwen om de uitvoering van dergelijke logica mogelijk te maken.

Wachten op Godot

De vorige opsomming geeft in feite niets meer dan een paar ruwe basisprincipes. Bijkomend zal je nog tal van andere operationele functionaliteit nodig hebben. Je zal de nodige rapportering moeten uitwerken, de aspecten van beveiliging verzorgen, enz. Een uitzonderlijke uitdaging in een dergelijke omgeving is alles wat te maken heeft met het testen van de oplossing, alsook alle aspecten van change management. Kortom, dit is niet het soort oefening die je nog even doet op het einde van een vrijdagnamiddag.

Vandaag kunnen we gerust stellen dat geen enkele technologieleverancier of systeemintegrator in staat is dit uit te werken voor een bedrijfsomgeving van enige omvang. De enige aanpak kan er dan ook enkel in bestaan geleidelijk een aantal bekwaamheden te verwerven of te versterken die een evolutie naar een dergelijke management omgeving kunnen mogelijk maken.

Hou er daarbij rekening mee dat de technische complexiteit eigenlijk nog het kleinere deel van het probleem is. Indien men immers een dergelijk platform ter beschikking heeft, dan moet men ook nog in staat zijn om deze gigantische investering op een dusdanige manier te gebruiken dat ze ook effectief de nodige return voor de onderneming realiseert. Welke bedrijfslogica geeft ons inzicht in nieuwe opportuniteiten? Welke uitzonderingen willen we definiëren? Hoe reageren we op dergelijke condities? Hebben we een organisatie die in staat is de geïdentificeerde opportuniteiten ook voldoende snel te realiseren?

Je kent de antwoorden. In een nog grotere mate dan wat reeds het geval was voor de traditionele scorecards e.d. bestaat ook hier het risico dat de bijkomende informatie die door het platform wordt aangeleverd door het management onvoldoende kan vertaald worden in gepaste acties.

Daarom zal het nog wel even duren vooraleer we de eerste echte BPPM2 realisaties zullen zien. Wat zal immers nog het excuus zijn waarachter het management zich kan verschuilen indien een BPPM2 omgeving beschikbaar is?

Deze ene keer kunnen we dus vaststellen dat management en IT voor één keer op dezelfde golflengte zitten: beiden zijn nog niet klaar voor deze job. Hoe dan ook, dit is de richting die we allen zullen uitgaan en zoals steeds is voorbereiding de betere start van elke evolutie.

Tags: business process management (BPM)

 

comments powered by Disqus