Problemen tussen business en IT zijn niet nieuw, bijna elk bedrijf heeft er in één of andere vorm mee te maken. De verhalen in de verschillende bedrijven zijn redelijk gelijklopend. De business klaagt erover dat IT hen niet (meer) kan volgen, dat zij een te technische taal spreken en bovendien voor de business niet begrijpbare diagrammen produceren. Aan de andere kant meent IT dat de business niet in staat is om haar behoeften (duidelijk) te formuleren en dat de betrokken business personen zelfs niet de eenvoudigste modellen kunnen lezen.

Het heeft dus vooral met verschillende vormen van communicatie te maken. Ook al zijn er personen (langs beide kanten) die de uitgesproken mening hebben dat het alleen de schuld van de ander is. Laten we eerlijk zijn: de waarheid ligt meestal ergens in het midden. Zonder dat beide "kampen" een stap naar elkaar zetten, zal er geen verandering in komen. Het gaat er niet om wie gelijk heeft, of wie meer gelijk heeft dan de andere ("gelijk hebben" is immers vrij relatief), het gaat erom de kloof tussen business en IT (communicatie) te dichten. Dit gaat trouwens beter door het als een uitdaging of opportuniteit te zien in plaats van als een (onoverkomelijk) probleem dat tussen de twee groepen staat (kwestie van perceptie, en hoe je het bij je medewerkers overbrengt).

Ikzelf heb tot nu toe het grotere deel van mijn carrière aan de IT zijde doorgebracht, werk echter de laatste jaren meer en meer voor de business (BPM is voor mij vooral iets waarover de business zich moet ontfermen). Graag zou ik dan ook willen benadrukken dat het niet mijn bedoeling is om de ene groep of de andere met de vinger te wijzen.

Aan de basis van de problemen ligt dat business en IT vaak gewoon helemaal niet samen overleggen. Er worden documenten heen en weer gestuurd (leve het e-mail tijdperk!), en zelfs het beantwoorden van vragen en het valideren van specificaties gebeurd vaak via e-mail. De reden hiervoor is zogezegd tijdsgebrek (meestal van de business), of gewoon "omdat het altijd al zo gedaan werd". Tijdsgebrek is voor mij echter geen geldige reden, het is immers algemeen bekend dat er meer tijd verloren gaat door misverstanden en fouten die achteraf rechtgezet moeten worden.

Ik ben ervan overtuigd dat samenwerking de enige manier is om elkaars communicatie beter te begrijpen. Maar in welk bedrijf worden bijvoorbeeld business proces modellen gemeenschappelijk uitgewerkt? Ik heb er nog niet veel gezien. Ofwel is dit de taak van de business (juist: business processen zijn van de business), ofwel neemt een IT analist of functioneel architect deze taak over en worden de proces modellen in het beste geval achteraf aan de business overgedragen. Meestal blijft echter IT de eigenaar ervan.

Zouden business en IT elkaar niet beter begrijpen, mochten ze samen in een workshop processen uittekenen? Dit kan nuttig zijn, indien er legacy systemen zijn waarbij veel business logica in de software code staat die alleen IT nog kan achterhalen. Het kan evenzeer nuttig zijn met het oog op eventuele (gedeeltelijke) toekomstige automatisering. Na dit soort workshops nemen de aanwezige IT’ers waardevolle business informatie mee, niet alleen over de processen, maar ook over de specifieke business terminologie en business regels.

Uiteindelijk zal IT de taal van de business moeten begrijpen (en niet omgekeerd). Sommige bedrijven hebben dit erkend en reorganiseren hun IT organisatie (weer) om zich beter op de business te aligneren (ipv competentie groepen te vormen).

Op dezelfde manier, namelijk via workshops met business en IT, kunnen de behoeften van de business verduidelijkt worden. Gemeenschappelijk ontwikkelde proces modellen zijn hiervoor een uitstekend uitgangspunt, aangezien ten eerste de business termen reeds verduidelijkt zijn en ten tweede de behoeften aan de hand van proces modellen duidelijk in de juiste context geplaatst kunnen worden.

Een organisatie moet weliswaar leren om dit soort workshops goed door te voeren, maar naar mijn ervaring laten positieve resultaten en enthousiaste deelnemers niet lang op zich wachten. Waarom zo u zich daar ook niet eens aan wagen?

Dr. Friederike Schröder-Pander is werkzaam bij Pro-ActIT

Klik hier voor het gehele artikel uit Business Process Magazine 6, van de hand van Roeland Loggen.

Ik hoor de twee kampen al hun messen slijpen om hun overtuigingen te verdedigen. Bij de twee kampen gaat het meestal niet om BPMN en EPC, maar eerder om “voor BPMN” en “tegen BPMN”. In het laatste kamp werken de meesten wel met EPC of gewoon met “rechthoeken en pijltjes” (een samenvatting van de groep die probeert met zo weinig mogelijk symbolen te modelleren). Er zijn veel artikels geschreven en talloze internet fora waarin de twee kampen elkaar te lijf gaan – gelukkig tot nog toe enkel maar met woorden, maar toch: bestaat er dan maar één enkele waarheid? Ik denk het niet.

Zonder de bovengenoemde “literatuur” op het web rond deze kwestie te willen herhalen, wil ik het toch even hebben over wat me hiervan bijblijft: de BPMN voorstanders benadrukken dat BPMN de enige erkende standaard voor het modelleren van business processen is en dat de processen achteraf ook uitvoerbaar zijn. BPMN tegenstanders zeggen dan weer dat BPMN niet begrijpbaar is voor de business – in tegenstelling tot EPC of rechthoeken en pijltjes, en dat maar een kleine minderheid van organisaties al aan procesuitvoering toe is. Bovendien hoeft niemand meer ARIS te kopen om EPC modellen te maken, dat gaat nu ook met bv. ArisExpress dat gratis op het web te vinden is.

De eerste discussie rond BPM met de professor uit Ljubljana (die met haar team ook consultancy opdrachten voor organisaties uitvoert) ging precies over – u raad het al – dit onderwerp. Ik was erg geïnteresseerd in hun ervaringen, aangezien we het over dit onderwerp vroeger nog nooit gehad hadden. Zij hadden eerder slechte ervaringen met EPC: het is volgens hen niet overzichtelijk, omdat een EPC model te veel “events” en “assignments”gebruikt. De business heeft daardoor moeilijkheden om doorheen alle bomen het bos nog te zien. In BPMN krijg je bv. met het “collaboration diagram” een veel beter overzicht over de interacties tussen verschillende processen. Een andere professor uit Kroatië had wel goede ervaringen met EPC gehad; vandaar ook dat deze professor in de BPM Summerschool EPC in haar voorbeelden gebruikte. De groep rond de Sloveense professor gebruikt BPMN, weliswaar niet alle symbolen, maar enkel een subset waardoor ze strikt genomen af en toe tegen de modelleerregels van BPMN ingaat.

En hier zijn we aan de tweede potentiële discussie belandt: als je een BPMN-subset gebruikt, is het dan nog wel BPMN dat je gebruikt, ook al volg je soms (noodgedwongen) de regels niet voor 100%? Eerlijk gezegd vind ik deze discussie naast de kwestie, het draait hier enkel om een definitie: mogen we het ook nog BPMN noemen of niet? De belangrijkste vragen die een organisatie zich moet stellen zijn: “Waarom modelleer ik mijn processen? Wat is het doel dat ik daardoor wil bereiken?” en “Wie zijn de stakeholders van mijn modellen? Wie moet ze kunnen verstaan en gebruiken?".

Er zijn (grote) organisaties die zowel BPMN als ook EPC modellen (ofwel andere varianten) toelaten, omdat er goede argumenten voor en tegen beide technieken zijn, en omdat het ook van de ervaring, achtergrond en specifieke situatie van een (deel van een) organisatie afhangt waar hun voorkeur naar uitgaat. Wat ook de keuze moge zijn – het is in de eerste plaats de verantwoordelijkheid van diegene die modelleert om ervoor te zorgen dat de modellen ook leesbaar blijven voor de business.

Dr. Friederike Schröder-Pander is werkzaam bij Pro-ActIT

Niet alleen de belangstelling voor BPM is gedurende de laatste twee decennia sterk toegenomen, maar ook de belangstelling voor Enterprise-architectuur (EA) (ik verkies om over "Enterprise-architectuur" te spreken i.p.v. "bedrijfsarchitectuur" om de link met de Engelstalige term te behouden). Er zijn meer en meer organisaties die zowel een BPM aanpak implementeren alsook een EA raamwerk gebruiken. Bij sommige van deze organisaties zijn BPM en EA nauw met elkaar verbonden, bij anderen hebben BPM en EA dan weer niets met elkaar te maken. Raar toch, ze claimen toch allebei met de "enterprise"-gedachte bezig te zijn. Om dit fenomeen te kunnen verklaren, moeten we kijken waar EA vandaan komt en wat eronder verstaan wordt:
 

Het gebied Enterprise-architectuur is eind jaren tachtig ontstaan (de meeste zullen het Zachman framework wel kennen of er tenminste van gehoord hebben), initieel om het probleem van de steeds complexer wordende IT systemen het hoofd te kunnen bieden. Het gevolg was immers dat organisaties ook steeds grotere bedragen voor de ontwikkeling van hun IT systemen uitgaven en de ontwikkelingstijd almaar langer werd, met als resultaat dat het voor organisaties steeds moeilijker werd om met hun complexe IT systemen gealigneerd te blijven met de business. Opmerkelijk is dat dit probleem initieel slecht "business alignment" genoemd werd, het was dus uitsluitend een probleem van het IT departement dat niet in staat was zich aan de business noden aan te passen. Niet verwonderlijk dat EA dus aan de IT kant ontstaan was en aanvankelijk zelfs "Information Systems Architecture" genoemd werd.

Verschillende methoden en technieken worden bij EA gebruikt om de structuur, de onderlinge relaties en de dynamiek van een organisatie met behulp van modellen van verschillende granulariteit te documenteren en te begrijpen. Het verduidelijken en blootleggen van de (complexiteit van de) operaties moet het makkelijker maken om de werking van de organisatie in al haar aspecten te verbeteren. Vaak wordt een Enterprise-architectuur in vier verschillende domeinen ingedeeld: business, informatie (of data), applicaties, technologie.

 
Ook al maakt het voorvoegsel "enterprise" van de huidige naam meteen duidelijk dat het om veel meer dan alleen IT gaat, toch wordt het initiatief voor een Enterprise-architectuur meestal door het IT departement genomen en blijft daar (helaas!) ook vaak hangen. De business vindt nog steeds dat EA iets van IT is. Eén reden hiervoor kan van historische aard zijn, aangezien EA in het IT departement ontstaan is. Een andere mogelijke reden is het ogenschijnlijke overwicht van IT met betrekking tot Enterprise-architectuur: van de vier verschillende domeinen is er immers maar één voor de business zelf, redeneert de business. Dat het business luik de basis is voor de drie andere, wordt vaak niet beseft. Bovendien wordt het informatie (of data) luik nog al te vaak (en geheel onterecht!) aanzien als iets wat uitsluitend IT toebehoort. 
 

Ook al spreken organisaties tegenwoordig van Business-IT alignment (en niet meer van "business alignment" alleen) en wordt EA vaak als middel hiervoor ingezet, beseffen nog te veel organisaties niet dat het een grote impact op hun business heeft, als IT niet snel genoeg op de steeds sneller veranderende noden van de business kan reageren. Een Enterprise-architectuur is – zoals de naam ook zegt – wel degelijk van belang voor de volledige organisatie. 
 

"BPM is van de business, EA is van IT". Dat verklaart waarom in veel organisaties de BPM implementatie en het EA initiatief niets met elkaar te maken hebben. Organisaties die de twee wel combineren, positioneren BPM vaak als de centrale methodologie in het business luik van EA. Ook al komt het initiatief voor een Enterprise-architectuur in de meeste gevallen van IT, bevordert een gecombineerde aanpak de communicatie tussen business en IT en daarmee ook een goede Business-IT alignment.

Dr. Friederike Schröder-Pander is werkzaam bij Pro-ActIT

Voor het BPM-Forum is dat niet alleen maar een theoretisch verhaal. Tijdens dezelfde conferentie hebben we als bestuur van het forum de resultaten van een onderzoek naar onze eigen positionering en ons eigen businessmodel gepresenteerd.
Dat was best even slikken. Want uit interviews met onze stakeholders blijkt dat ‘het merk’ BPM-Forum heel verschillende associaties oproept. De aanduidingen ‘straathond’ en ‘pantoffeldiertje’ waren daarbij nog niet eens de minst vlijende …

Tijd om weer eens goed te kijken naar het ‘waarom’ van het BPM-Forum. Bij de oprichting was dat ‘het stimuleren van de toepassing van het BPM-gedachtegoed’ door:
- kennis te delen over ervaringen rond toepassing van BPM;
- professionals op BPM-gebied samen te brengen in een kwalitatief hoogstaand netwerk;
- contacten te onderhouden met andere organisaties die een bijdrage kunnen leveren aan deze doelstelling en waar zinvol in samenwerking met deze organisaties initiatieven te nemen die bijdragen aan het behalen van de doelstelling.

Dat stimuleren is ook nu, acht jaar later, nog steeds zinvol. Want de potentie van BPM wordt nog lang niet ten volle benut. Maar we kunnen ons wel de vraag stellen of het kennis delen tussen professionals onderling daar nog wel het beste middel voor is. Moeten we als BPM-Forum niet veel meer een rol gaan spelen richting beslissers en bestuurders, mensen die zichzelf niet als BPM-professional beschouwen? Moeten we meer de nadruk gaan leggen op kennis opbouwen en kennisplatform zijn dan op het uitwisselen van kennis en ervaringen? Is het nog wel logisch dat we zoveel energie stoppen in het organiseren van events gebaseerd op case presentaties? Volop vragen dus waarover het bestuur in de komende periode gaat nadenken. Uiteraard met nauwe betrokkenheid van individuele en corporate leden.

Voor wie medelijden met ons mocht krijgen: het congres bracht ook volop lichtpuntjes. Zoals Johan Nelis, medeoprichter van het forum die al een jaar of zeven in Australië woont. Hij verzekerde ons dat het Nederlandse BPM-Forum door BPM-professionals in de rest van de wereld als hét voorbeeld gezien wordt. Daarnaast veel interessante sessies, een levendige informatiemarkt en heel veel goede contacten onderling. Dat maakt dat we geloven dat een ander beeld dat uit het positioneringsonderzoek naar voren is gekomen, namelijk het beeld van een slapende leeuw, het BPM-Forum misschien wel het beste typeert: krachtig, met veel potentie, maar hij kan wat meer in beweging komen.
 

Aty Boers is bestuurslid van BPM-Forum Nederland.

Deze column verscheen eerder in Business Process Magazine 4-2011
 

Zoals vaak bij buzzwords worden er meteen nogal wat verschillende betekenissen aan verbonden. Een veelgehoorde definitie is: “het inzetten van social media voor het ontwikkelen en verbeteren van processen”.
Uit voorbeelden van Social BPM op internet lijkt het dan alsof het zonder social media niet mogelijk was om mensen die geen ontwerpers of projectmedewerkers zijn intensief te betrekken bij het vastleggen en verbeteren van processen. Onzin natuurlijk. Behalve als Social BPM zou betekenen dat BPM’ers eindelijk (?) zullen socialiseren dankzij social media.

Ook veel BPM-tools en -suites worden inmiddels aangeduid als ‘social’. Dat betekent dat er koppelingen zijn naar bijvoorbeeld Twitter en Facebook. Of dat proces-Wiki’s, Mashups of BAAS (BPM-as-a-Service)-functionaliteiten zijn toegevoegd. De verwachting is dat dit nieuwe impulsen geeft aan het door de business zelf vastleggen van processen en het coördineren daarvan zonder dat daarvoor een centrale BPM- of IT-afdeling nodig is.

Interessanter nog is het gebruik van de term ‘social’ in de executiefase van de ‘BPM cycle’.
Dan gaat het er om dat er ‘real-time’ rijke contextinformatie wordt toegevoegd aan procesinformatie. Niet alleen gestructureerde gegevens maar ook bijvoorbeeld meningen over de case die onder handen is of ‘social’ informatie over betrokkenen bij het proces. Meningen en inzichten gaan dan een rol spelen bij de afhandeling en klantinteractie wordt op andere manieren mogelijk. Men heeft het dan wel over Adaptive Case Management, ofwel Dynamic Case Management, een term die in Nederland meer lijkt aan te slaan (zie bijvoorbeeld het interview met Ronald Maas, het nieuwe bestuurslid van het BPM-Forum op de site van Business Process Magazine).

Social BPM hangt nauw samen met andere trends en buzzwords zoals ECM, collaborative Business Process Management, human centric BPM en S-BPM ofwel subject-oriented BPM (stakeholders georiënteerde procesbenadering).

Voor procesontwerpers betekent Social BPM dat het ontwerpen van processen meer dan ooit begint vanuit het perspectief van de klant. Wat zijn de momenten in het proces waarop interactie ontstaat of kan ontstaan? Welke ervaringen zou de klant op dat moment idealiter moeten hebben? De interne workflow en procesafhandeling zijn daar afgeleiden van.
Dit kan leiden tot verrassende inzichten. Bijvoorbeeld dat het goed zou zijn meer contactmomenten met de klant in te bouwen, terwijl lang het adagium was dat het aantal klantcontacten minimaal moet zijn.

En er zijn meer effecten te verwachten van Social BPM. Waar ‘social informatie’ afkomstig is van andere afdelingen of specialisten van binnen de organisatie kan Social BPM ook een enabler zijn voor meer transparantie en betere samenwerking binnen organisaties. En zo bijdragen aan het doorbreken van de organisatiesilo’s die zo’n grote belemmering vormen voor het succes van BPM.
 
Boeiende ontwikkelingen dus inderdaad. Al blijft het natuurlijk raar dat toevoeging van het woord ‘sociaal’ te maken heeft met techniek. Want wat is een proces anders dan een manier waarop mensen – sociale wezens tenslotte – samenwerken? Process management is per definitie sociaal omdat het zich bezig houdt met de vraag hoe mensen optimaal kunnen samenwerken bij het behalen van gezamenlijke doelen.

Aty Boers is bestuurslid van BPM-Forum Nederland.

Deze column verscheen eerder in Business Process Magazine 3-2011