Leveranciers van soa- en bpm-tools staan in de rij om de voordelen van business process management (bpm) en service oriented architectures (soa) aan te prijzen. Logisch, want zij hebben er commercieel baat bij. Maar gelukkig zijn zij niet de enige die zich (erg) positief uitlaten over de mogelijkheden die bpm en soa te bieden hebben. Ook analisten en wetenschappers zijn ronduit optimistisch over de winst die dit soort tools en methodieken, vaak letterlijk, te bieden hebben.
Daarom is het des te opmerkelijker dat het aantal grootschalige bpm- en soa-projecten vooralsnog relatief beperkt is. Waar ligt dat nu aan? Zit het probleem ‘m in de technologie die leveranciers aanbieden? Een paar jaar geleden zat daar misschien nog wel een kern van waarheid in, maar inmiddels is de stand van de techniek dusdanig ver, dat zelfs human-centric bpm met weldoordachte tools mogelijk is. Ligt het probleem dan wellicht aan de managementkant? Anders gezegd: is het denken over management- en sturingsmethodieken nog niet zover dat organisaties optimaal van de beschikbare tools gebruik kunnen maken? Wie de literatuur op dit vlak enigszins bijhoudt, zal die visie niet kunnen ondersteunen. Natuurlijk rennen de aanbieders wel eens wat harder dan de wetenschappers, maar ook daar zit het probleem niet.
Er lijkt een heel ander punt te spelen: politiek. Interne politiek binnen bedrijven en organisaties wel te verstaan. Kernpunt hierbij is toch weer het aloude adagium: mensen hebben moeite met veranderingen. En helaas wordt bij veel veranderingsprocessen, het invoeren van soa en bpm is een heel duidelijk voorbeeld van een ingrijpend en vaak ook complex veranderingsproces, dit niet alleen vergeten, maar wordt bovendien de onrust onnodig aangewakkerd.
De interne politiek binnen een organisatie is een kracht waarbij soa-/bpm-projecten terdege rekening moet worden gehouden. Veel voorstellen voor veranderingen worden door de direct betrokkenen als kritiek ervaren en ‘dus' gaat men in de verdediging. Het gebruik van negatief ervaren begrippen als functionele silo's (zou u het leuk vinden als uw werk van de afgelopen twaalf of achtien jaar en waar u veel tijd en energie in heeft gestoken ineens in dergelijke termen wordt afgeserveerd?) maakt het allemaal nog eens extra moeilijk.
Veel veranderingen worden door de betrokkenen op emotionele wijze ervaren. Is het niet beter om de feiten voor zich te laten spreken en de scherpe kantjes zoveel mogelijk te vermijden? Beschrijf heel duidelijk wat een proces is, hoe de processen van een afdeling of business unit nu werkelijk functioneren en presteren en voorkom te allen tijde dat iemand de schuld in de schoenen geschoven krijgt. Besef bovendien dat mensen of afdelingen die functies hebben vervuld zichzelf vaak heel goed realiseren dat hun werk conflicteert met het proces dat wordt ontworpen.
De reacties blijven vaak niet uit: hakken in het zand. En helemaal ongelijk kunnen wij hen natuurlijk ook niet geven. Wie de politieke aspecten van een veranderingsproces als het invoeren van soa en bpm niet onderkent, maakt het zichzelf onnodig lastig. Voeg daarbij nog eens fenomenen als verborgen agenda's en het zal duidelijk zijn dat de interne politiek binnen een organisatie veel soa-/bpm-trajecten flink in de wielen kan rijden. Voorkomen kunnen we dat niet altijd, maar als we ons er beter van bewust zijn, kunnen veel ongelukken toch worden vermeden.
John DesJardins
Chief Architect Benelux bij Software AG
Het gevaar van een BPM traject is dat het een proces transparant maakt. Vanuit het hoogste-management is dat uiteraard een doel, maar vanuit andere delen van een organisatie (middlemanagement en werkvloer) wordt dat vaak als een bedreiging ervaren. Transparantie laat haarscherp zien wie er eventueel de kantjes afloopt. Dit verklaart voor een deel de hakken in het zand reactie van veel medewerkers, maar dit verklaart niet waarom hoger management niet veel vaker SAO/BPM trajecten opstarten.
Het grootste probleem daar is denk ik de jarenlange moeizame relatie tussen IT en business, alleen al het feit dat er vaak een tweedeling wordt gemaakt geeft al aan dat er een groot onderling wantrouwen is. Er is in het verleden veel beloofd en niet altijd voldoende waargemaakt. Wie zegt me dat het nu wel allemaal gaat lukken met SOA/BPM ?
Mensen bedrijven politiek omdat ze daarmee macht kunnen uitoefenen en doelen kunnen verwezenlijken. In de tweede kamer zie je dat voor elke politieke overtuiging wel een tegenovergestelde overtuiging te vinden is. Zo ook in het bedrijfsleven, met als gevolg dat het SOA initiatief tot mislukken gedoemd lijkt. Maar, in tijden van rampspoed hebben zelfs de SP en de VVD 1 gezamelijk doel: de ramp afwenden.
Zet SOA dus in eerste instantie in voor een smeulend vuurtje dat later een uitslaande brand wordt. Een smeulend vuurtje op afdeling X dat nooit naar afdeling Y kan overslaan is dus geen goed vuurtje om mee te beginnen.
Zeker, een groter bewust zijn van de gevolgen van grote veranderingen voor een organisatie is absoluut goed.
Daarnaast is er ook heel veel te doen in praktische zin om de mensen in een organisatie te informeren over en deel te maken van het veranderingsproces. En vergeet niet hoe het helpt om eens echt te luisteren naar iemand als hij aangeeft waar hij issues ziet? Misschien is dit wel cruciale input.
Verder ben ik ervan overtuigd dat een ingrijpende verandering alleen dan succesvol kan worden ingevoerd als er op alle lagen van het management en door de hele organisatie heen er buy-in en commitment is.
Want veranderingen bereik je niet alleen, dat doe je samen!
Ik denk dat SOA en BPM nog te veel (met name vanuit IT) als doelen op zich worden verkocht en dat de werkelijke redenen waarom ze zouden moeten worden toegepast onderbelicht blijven. Voor een deel komt dat ook omdat de werkelijke motieven onvoldoende worden begrepen of worden overschat.
Daarnaast denk ik dat SOA en BPM te veel als alles-of-niets aanpakken worden gepositioneerd; een beetje SOA en een beetje BPM is blijkbaar niet genoeg. Ik zou daarom willen voorstellen om deze mindset om te draaien; ga voor “just-enough” SOA en BPM. Stel jezelf re?le ambities. Focus op die aspecten die de meeste toegevoegde waarde hebben. Neem kleine stappen.
De aanzet tot BPM en SOA projecten komt uit verschillende richtingen, namelijk de business wil BPM, IT wil een nette SOA architectuur. Naar mijn mening wordt de business door concurrentie en veranderingen in de markt (wet- en regelgeving, klanten) gedwongen tot stroomlijnen van processen, verlagen van de operationele kosten en dus automatiseren en beter sturen van de dagelijkse gang van zaken.
IT daarentegen probeert beheerskosten te drukken en een overzichtelijk systeemlandschap te creeeren. Deze belangen botsen. Business wil verandering en IT wil behoud van bestaande omgeving.
Volgens mij wordt het tijd dat IT ondersteunend wordt aan de initiatieven van de business. Het is momenteel nog steeds het geval dat IT intern een soort academische discussie voert over ontwerp en inrichting en daarbij de doelstellingen van de organisatie en in het bijzonder tactisch en operationeel management uit het oog verliest. Het wordt tijd dat IT een stapje terugdoet in hun hautaine houding. Natuurlijk moet je op de kosten letten bij de inrichting en uitvoering van een IT beleid, maar momenteel verzanden ze te veel in interne discussies die zo mogelijk meer kosten dan ze opleveren. Mijn devies: IT-ers wordt een wakker, hou op met praten en ga eens wat doen.
Wil je IT in beweging krijgen (en dan anders dan de hakken in het zand), maak ze dan mede verantwoordelijk van het succes van het door de business gedreven project. Beloon ze op basis hiervan en reken ze niet alleen af op de kosten voor het instandhouden van de huidige systemen.
Absoluut mee eens dat BPM/SOA trajecten niet puur als technologische innovatie gezien moet worden, maar als een verandermanagementtraject van technologie, proces en organisatie gecombineerd. Men moet een goed draagvlak cre?ren waar verschillende stakeholders zich geholpen voelen.
Dat kunnen drivers zijn waar de business meer ownership krijgt om processen zelf te kunnen veranderen, verhoogde procesflexibiliteit en time-to-market versnelling van nieuwere bedrijfsprocessen. Ook real-time monitoren van processen behoort tot de primaire voordelen dat helpt om pro-actief processen te optimaliseren en fouten sneller te herstellen. Maar er zijn ook andere voordelen die verandermanagementtrajecten helpen. Met betere end-to-end controle over processen kan men makkelijker non-primaire processtappen outsourcen naar derde partijen en focussen op de primaire (en differenti?rende) processtroom. Verhoogde operationele efficientie door repetitieve taken te automatiseren is een ander argument.
Daarnaast is het van cruciaal belang om BPM trajecten klein te beginnen en vervolgens uit te bouwen om de toegevoegde waardes incrementeel te demonstreren.
Magical Thinking? Mensen ook ICT’ers hebben een bepaalde set aan verwachtingen die men gebruikt om de resultaten van hun handelen te kunnen verklaren. Wanneer er iets verrassend gebeurt wordt niet de verwachting ter discussie gesteld maar gelooft men dat men het iets anders had moeten aanpakken.
In relatie tot BPM is een manifestatie van Magical Thinking het geloof dat als het proces niet werkt zoals bedoeld dit te wijten is aan een specifiek issue en dus opgelost kan worden. Maar staan we weleens stil bij het feit dat een proces uitgevoerd door mensen die een bedrijfsdoel nastreven helemaal niet zo procesmatig verloopt als we denken?
Zijn de verwachtingen terecht m.b.t SOA & BPM tools en verwijten we niet ten onrechte de politiek het falen?
If a spell fails to work, the magician always thinks that he must correct some small mistake, not that the spell may have no chance of working. If a spell appears to have the desired outcome, the magician does not pause to consider whether or not he can be sure that the outcome was caused by the spell.
‘There is no more delicate matter to take in hand [?], than to be a leader in the introduction of changes…’, zo betoogde Machiavelli. Veranderingen als het ‘invoeren van SOA/BPM’, zoals John DesJardins het verwoordt, wekken zeker emoties op. Ook mijns inziens moet hiermee terdege rekening gehouden worden tijdens verandertrajecten met een IT component. Dit is ook een van de leerpunten uit het ERP-tijdperk.
Ruim voor de opkomst van ERP echter beschreef John Kotter zijn acht stappen van veranderingsmanagement. Een daarvan luidt: ‘Communiceer om draagvlak en betrokkenheid te creeren’. Dat lijkt een open deur, maar er is een addertje. Heldere communicatie begint met namelijk met het beheersen van eenzelfde taal. En daar gaat het met BPM/SOA nog wel eens fout, is mijn ervaring. Ik ken overigens een aanpak die deze uitdaging adresseert en tevens de proceskant, de menskant en de technologiekant van SOA/BPM-gerelateerde veranderingen integraal benadert: ArchitectedSAP.
De invoering van SOA/BPM heeft een executive sponsoring and buy-in nodig op CEO level. De sponsoring geeft een voldoend budget vrij om operationeel het project te kunnen uitvoeren en de buy-in om de silo?s te doorbreken. Als die steun er is, in zo’n situatie, zet de slimme afdelingsmanager de eerste (strategische) stap om het project eigen te maken en daardoor een leading role te spelen. Managers die tegenwerken zullen zichzelf defensief opstellen en steeds achter lopen. SOA/BPM helpt niet alleen met de evolutie van de software architecturen maar helpt ook met de evolutie van de organisatie en eigen managers.
Met veel interesse heb ik de verschillende standpunten gelezen. Ze geven allemaal redenen waarom SOA/BPM-projecten nog niet op grote schaal worden toegepast.
De vergelijking van Freddie over de magician vind ik treffend. We doen een aantal aannames, maar vergeten na afloop te controleren of deze aannames juist waren en bedroegen aan succes. Een meer wetenschappelijke benadering zou meer voor de hand liggen. Een onderbouwing met bewijs of je stellingen en aannames kloppen.
Een belangrijk aandachtspunt in de discussie is de rol van het indivudu en de onderlinge samenwerking. In het algemeen en in deze discussie vind ik het menselijke aspect beperkt terug. Tenslotte zijn wij degene zijn die vernieuwing / innovatie starten en niet de processen, data of organisatievorm. Prof. Andre de Waal heeft onderzoek gedaan naar succesvolle organisatie. (www.andredewaal.eu) Uit zijn wetenschappelijke onderzoek komen een aantal differentierende factoren naar voren. Twee ervan (hoge kwaliteit van medewerkers en management) zijn direct terug te voeren op het menselijke aspect. Voor de factor “hoge kwaliteit van het management” vond het onderzoek van De Waal 12 kenmerken die bepalend daarin zijn. Een aantal van deze kenmerken vertonen veel overeenkomsten met het werk van Stephen Covey (The 7 Habits of Highly Effective People).
De bottom line is dat samenwerken en onderling begrip en vertrouwen de sleutels naar succes zijn.
Misschien geldt dat ook in dit verband…