Talloze pogingen om iets als 'een bpm-project' af te ronden om bedrijfsprestaties te verbeteren, hebben geleid tot een ongewenst resultaat. Hetzelfde kan ook worden gezegd over 'lean projecten' of enige andere prestatie verbetertrajecten. Wat gaat er fout? En hoe zorg je ervoor dat je organisatie wel baat heeft bij bpm? Dit artikel tracht daar een antwoord op te geven.
Om te kunnen begrijpen waarom bpm-projecten zo vaak mislukken, moeten we eerst een helder begrip hebben van wat business process management is. Hoewel… Het is vrij algemeen bekend dat de positionering van bpm al decennia een punt van heftige discussies is, tot bijna religieuze oorlogsvoering aan toe. Commerciële belangen hebben een behoorlijke bijdrage geleverd (en doen dat nog) aan het compleet maken van deze verwarring. Bpm is dus, afhankelijk van wie je het vraagt, steeds weer iets anders en dat maakt de discussie lastig om te voeren. Met het gevaar heftige reacties op gang te brengen geef ik hier toch een definitie van wat in mijn optiek bpm is (zie ook vom Brocke & Schmiedel, 2015):
Bpm is een management discipline (er zit immers een ‘m’ in het acroniem) met als doel bedrijfsprocessen te ontwerpen, uitvoeren en bewaken (beheren) om continue verbetering, innovatie en groei te borgen.
Automatisering kan nooit een doel zijn
Automatisering kan hierbij een hulpmiddel zijn, maar het blijft een middel en moet zeker niet tot doel verheven worden. En juist dit laatste komt te vaak voor.
Om bedrijfsprestaties te verbeteren, gaan we aan de haal met het optuigen van verbeterprojecten en programma’s. Variërend van de implementatie van dat nieuwe postregistratie-systeem, een lean verbeter-traject tot complete cultuur verandertrajecten. En dat is denk ik waar het probleem zit. Een postregistratie-systeem kan je namelijk projectmatig nog wel implementeren. Maar iets als bpm, lean of een cultuurverandering? Dat is een stuk lastiger, omdat we te maken hebben iets dat verweven moet worden in de manier van denken en werken.
Laat me dit verduidelijken: Om een postregistratie- systeem te kunnen implementeren dienen we natuurlijk minimaal het wanneer, wat, waarom, wie en hoe van de betrokken processen te begrijpen. Dus houden we interviews en workshops om te begrijpen hoe deze processen nu werken. We leggen alles mooi vast in sipoc’s (suppliers, inputs, process, outputs, en customers) en vsm’s (value stream map), al dan niet met hulp van (geautomatiseerde) tools. Maar, en dat is nu het kromme, als onderdeel van het postregistratie-systeem project zelf. Het nieuwe postregistratie-systeem (de technologie) is in dit geval dus de voornaamste aanleiding om de processen onder de loep te nemen! Pardon?
Hadden we niet al lang een solide beeld moeten hebben van hoe we nu werken?Is het niet heel vreemd dat het begrijpen van de manier waarop we werken een onderdeel is van de oplossing (zoals het automatiseren van een bedrijfsproces is)? En erger nog, dat we dit kennelijk steeds weer opnieuw moeten doen? Op die manier vind ik het niet gek dat mensen niet heel warm lopen voor bpm als management discipline; het wordt dan namelijk een behoorlijk kostbaar noodzakelijk kwaad dat steeds herhaald moet worden.
Over de mens, proces, informatie en technologie
Al decennia hebben mensen geprobeerd de zogenaamde kloof tussen business en it te slechten. It zou de business niet begrijpen en de business snapt weinig van it. Kloven komen ergens vandaan natuurlijk. Elke bedrijfsfunctie heeft een valide reden voor haar eigen bestaan. En uiteraard zal elke functie zijn voortbestaan willen rechtvaardigen, rechtsom of linksom. En allemaal leiden we af en toe wel eens aan beroepsdeformatie. Waarom dan steeds weer die focus op die ene kloof? Omdat we informatie verwerkers zijn! En allemaal zijn wij in toenemende mate sterk afhankelijk van de juiste informatie. In de juiste context en natuurlijk tijdig. En daar zorgt de it-afdeling voor, toch?
Juiste en tijdige informatie zou gezien moeten worden als onmisbaar middel, dat gekoesterd moet worden met juist beheer. Om beheer goed te kunnen uitvoeren heb je inzicht en dus overzicht nodig. En dat gaat verder dan wat losse procesplaatjes gecreëerd met bpm-applicaties, Powerpoint of Visio kunnen bieden. Vaak worden er professionele tools aangeschaft, maar is onvoldoende nagedacht over de basis propositie: Wat wil je er nu echt mee bereiken?
Bpm als strategische keuze
Ik zie bpm dus duidelijk niet als een van de zoveelste (technische) methoden teneinde performance verbeteringen te realiseren maar als fundament voor diverse en vaak samenhangende initiatieven in de context van de bedrijfsdoelstellingen. Anders gesteld: Op het ene moment brengen we processen in kaart om compliancy aan te tonen (een ‘kwaliteitsproject’) en een half jaar later doen we hetzelfde omwille van het upgraden van een systeem (een ‘erp-project’). Is dat niet raar? Het enige dat gewijzigd is, is immers de focus. We doen nog steeds dezelfde dingen als bedrijf, lijkt me zo.
Mijns inziens zouden organisaties daarom moeten investeren in transformatie naar een bpm ondersteunende culturele organisatie. De Universiteit van Liechtenstein heeft hier uitvoerig onderzoek naar gedaan en een tool ontwikkeld om te meten in hoeverre de aanwezige cultuur bpm ondersteund. De volgende zes factoren worden gezien als ondersteunend van een holistische benadering van bpm;
- Strategisch afstemming,
De afstemming tussen het bpm gerelateerde initiatief en de algemene strategie van de organisatie. - Governance
De vastgelegde verantwoordelijkheden betreffende proces besluitvorming. - Methoden
De technieken die op consistente wijze procesgericht werken ondersteunen en mogelijk maken zoals de balanced scorecard van Norton en Kaplan. Maar ook zoiets als lean; lean kan namelijk uitstekend profiteren van een goed bpm-fundament! - It
De technologie die bpm-gerelateerde activiteiten ondersteunt. Behalve operationele systemen (zoals operationele workflow managementsystemen of case managementsystemen) vooral ook systemen in de communicatief beschrijvende sfeer (zoals Engage, Tibco Nimbus, Adonis) of technisch beschrijvende sfeer (zoals Aris, Archimate, Bizagi). - Mensen
De proces gerelateerde deskundigheid en kennis van werknemers. - Cultuur
De collectieve waarden en normen die procesgerichte organisaties ondersteunen.
Ik zou daar graag nog één factor aan toe willen voegen: Informatie management. Dit omdat de factor it (technologie) niet hetzelfde is als informatie management. Om kennis te borgen met je namelijk informatie management goed onder controle moeten hebben.
Transformatie is moeilijk. Maar duurzame transformatie is nog veel moeilijker. Ik gooi het daarom over de volgende boeg: Door te investeren in een bpm ondersteunende culturele organisatie, bereikt een organisatie op lange termijn veel meer dan wanneer bpm slechts gezien wordt als eenmalig (technisch) onderdeel van verbeterprojecten. In een volgend artikel zal ik ingaan op hoe resultaat bereikt wordt.
Walter, laat ik beginnen met twee dingen: Solide verhaal en ik heb een voorliefde voor BPM.
Slechte nieuws is: Nobody gives a sh*t about BPM.
Ik denk als je kijkt naar het aantal reads van deze pagina ten opzichte van veel andere artikelen dan zal dit laag zijn. En hier zit subtiel wel het grootste probleem van BPM.
Het is niet sexy, mensen moeten veranderen (ze willen wel veranderen maar geen verandering) om het toe te kunnen passen en draagvlak vinden is als trekken aan een dood paard.
In mijn ogen vergt BPM een dictator. Gewoon iemand die zegt “Dit gaan we doen, en zo gaan we het doen” Uiteraard zoek je er wel wat mensen bij die het juist uit kunnen voeren. Dus iemand die de domein kennis boven water haalt en iemand die dit vertaald naar de techniek. Daarna is het gewoon er door drukken met harde hand net zo lang dat het een gewoonte geworden is.
BPM heeft in mijn ogen gewoon een top-down benadering. Ideaal is het niet, maar bottom-op zie ik het veelal falen.
Prachtig plaatje overigens! Leuk!
En nogmaals, ik draag BPM een warm hart toe maar in feite is het gericht op een productie organisatie en niet op een kennis organisatie. Goede BPM stompt ook af, laten we eerlijk zijn…
“transformatie naar een bpm ondersteunende culturele organisatie”. “performance verbeteringen te realiseren maar als fundament voor diverse en vaak samenhangende initiatieven in de context van de bedrijfsdoelstellingen.” En een holistische bena …
EEEEEEEJJJ GAAT EENS AAN HET WERK !!!!! VOOR JOU 10 ANDEREEEE
@Henri: Dank voor je reactie. Juist jouw constatering bracht mij er toe het artikel ook in een blad als Computable te plaatsen :-). En misschien is het acroniem inmiddels inderdaad dermate “versleten” dat het niet meer de lading dekt zoals mensen als Hammer ooit bedoelden.
Veel mensen trekken BPM gelijk met (geautomatiseerde) workflow (productie idd), maar ik zie dat dus echt anders. Als je niet weet wat en hoe je iets doet, wordt je mijnsinziens op een gegeven moment te veel speelbal van externe invloeden. Er is een reden voor de gemiddelde waan van de dag zeg maar.
Aan de basis een goed verhaal, vind ik, dat helaas wat wollig wordt.
Waarom “lopen” processen niet? Zijn het echt zulke slechte processen die nog volop verbeterd moeten worden?
Mijn ervaring is dat de primaire processen (want daar gaat het veelal over) op zichzelf vaak wel in orde zijn. En vaak is er ook een intrinsieke bereidheid om te zoeken naar en te werken aan verbetering. Alleen mislukt dat omdat de procesflows niet deugen. En dat komt vaak weer doordat mensen, teams of complete afdelingen op eilandjes zitten, niet naar elkaar luisteren en al helemaal geen afspraken met elkaar maken. En als dat te lang duurt gaan zaken niet goed, mislukken verbetertrajecten en krijgt Henri gelijk met zijn opmerking dat dan alleen nog een top down benadering werkt.
Belangrijkste doelen van BPM moeten in mijn optiek dan ook zijn: het op gang brengen van interne communicatie , het creëren van transparantie, inzicht in de totale flow en het maken van afspraken met betrekking tot overdrachtsmomenten (acceptatiecriteria) binnen die flow. In die zin verschilt dat in niets van de belangrijkste doelen van verbetertrajecten op het gebied van IT-beheer (ASL, ITIL, ISM), of verbetertrajecten op het gebied van informatievoorziening (BiSL, FSM).
BPM heeft dus alles te maken met de organisatie van het aansturen van business processen en is gericht op (continue verbetering van) effectiviteit en efficiëntie.
En als je dan de zaak op orde hebt kun je pas goed als opdrachtgever fungeren naar informatievoorziening voor support, die op haar beurt IT-beheer inschakelt voor het leveren en draaiende houden van de gevraagde functionaliteit (die op haar beurt externe dienstverleners aanstuurt etc.).
Een interessant artikel – goed voor stof-tot-nadenken!
Hieronder mijn vijf-centen.
Waarom BPM niet werkt?
Wel – veel (alle?) managers gaan uit van een verander traject dat maakbaar en voorspelbaar is. Daarbij wordt gewerkt met termen als “milestones” en “deadlines”. Dat alles liefst binnen een (boek)jaar zodat de daarmee samenhangende veranderkosten maar een keer op de bedrijfsresultaten drukken.
Aan de andere kant zijn daar de deskundologen rondom verander vraagstukken met enige omvang. Die geven aan dat een programma met een hoog gehalte aan gedrag/cultuur verandering zich niet laat plooien naar “milestones” met “deadlines”; zeker niet als dat alles ook nog eens binnen een boekjaar afgetikt moet worden.
Om het dan toch maakbaar en voorspelbaar te houden verschuift het zwaartepunt naar de invoering van een nieuwe tool en daarmee samenhangende “nieuwe workflow”. De “transitie” is geslaagd als (bij wijze van spreken) iedereen kan inloggen en de verplichte cursus (plus dito examen!) met goed gevolg heeft afgelegd.
De aanwezigheid op die cursus en het bijbehorend slagingspercentage wordt natuurlijk gemeten om op die manier de spreekwoordelijke stok te hebben als blijkt dat de transitie toch niet helemaal gebracht heeft wat verwacht werd. Het verzamelen van cijfers en de bijbehorende stok wordt verpakt (verkocht?) onder de noemer “transparantie”.
Een dergelijke, “transparante”, top-down benadering (met verborgen dreigementen en straffen) staat garant voor een knap staaltje window dressing. Want tja, wie wil er nu op het matje geroepen worden bij zijn baas… Met andere woorden, iedereen is netjes aanwezig en slaagt voor het examen. Om vervolgens over te gaan tot de orde van de dag…
Wanneer BPM wel werkt?
Ik ben dan ook heel benieuwd naar deel twee – vooruitlopend daarop:
Een andere invalshoek van de eerder genoemde verander deskundologen is om tijdens een dergelijk programma over 3 assen te gaan werken: top-down, bottom-up en andere processen/workflows. Alleen op die manier is er sprake van een zekere maakbaarheid en voorspelbaarheid terwijl de kans van slagen op een duurzame verandering aanzienlijk verhoogt wordt. Vanuit dat kader ben ik zeer benieuwd wat de invalshoek van deel twee gaat zijn…
🙂
@Henri:
Volgens mij ga je hier op een paar punten wat kort door de bocht.
=====
“maar in feite is het gericht op een productie organisatie en niet op een kennis organisatie”
Mag ik hieruit concluderen dat in jouw optiek het borgen en delen van kennis niet georganiseerd hoeft te worden? Met andere woorden, iets van processen en workflows, in welke vorm dan ook, dat is niet nodig binnen een kennis organisatie?
Als het antwoord “ja” is, hoe zorg je er dan voor dat mensen die nieuw binnenkomen zich kunnen inleven en inlezen in de beschikbare kennis, mensen en middelen om hun job goed te kunnen doen?
=====
“Goede BPM stompt ook af”
Das een contradictie-in-terminologie. Ik bedoel, als een vorm van BPM afstompt hoe kan het dan het predikaat “goed” krijgen?
Ik zou juist zeggen dat als een bepaalde invulling afstompt, dan is de verkeerde invulling is gekozen. Met andere woorden, ja inderdaad, voor een productie organisatie is een andere invulling nodig dan voor dan voor een kennis organisatie.
=====
Idee dat je BPM los moet zien van ICT is onzinnig, je wordt tenslotte als ouderwets beschouwd als je met een oplossing van pen & papier komt. Welk middel je kiest is natuurlijk wat anders want deze dient niet alleen proportioneel (efficiënt) te zijn maar ook onderhoudbaar (effectief) en voor wat betreft laatste zijn ‘olifantenpaadjes’ van Post-IT grappig want in elke organisatie is er naast de officiële weg minstens altijd één officieuze weg. Probleem met BPM is dan ook niet het vastleggen van de processen maar deze onderhouden, de papieren complaince werd DigiNotar tenslotte noodlottig.
@Ewout: Wat ik (o.a.) probeer te zeggen met mijn artikel is dat het juist vaak omgekeerd is; BPM wordt door behoorlijk veel mensen gezien als een van de zoveelste “verbeter-technieken door automatisering.” Het vastleggen van processen (vaak gedreven door automatisering of idd compliancy eisen) wordt dan als onderdeel gezien van juist die onderwerpen. Daardoor ontstaat een “verplicht nummer” gevoel en is er sprake van weinig tot geen draagvlak in de organisatie. Met als gevolg het grafiekje rechtsonder in mijn plaatje. Kortom en sterker nog, BPM staat -als het goed is- nergens los van, dus zeker ook niet van ICT, maar vormt (wat mij betreft) het DNA van je organisatie of zou dat moeten doen.
@Walter
Of processen het DNA vormen van de organisatie is nogal twijfelachtig, daarmee impliceer je naar mijn optiek namelijk een zekere mate van onveranderlijkheid. Processen zijn in mijn optiek dan ook eerder de spelregels waarbij je de (compliance) geschreven regels hebt en de ongeschreven (integriteit) regels. Kortom, het DNA van een organisatie zit eerder in mensen welke een gezamelijk doel nastreven waarbij processen helpen om dit doelmatig (effciënt) of doeltreffend (effectief) te doen.
Uiteraard is het handig als je inzichtelijkheid hebt in de processen, deze minitieus vastleggen leidt echter tot een vorm van micromanagement waardoor een organisatorische inertie ontstaat door een fenomeen dat de Duitsers Amtsschimmel noemen. Henri bewoordt het wat populistisch maar inderdaad stompt BPM af als het van bovenaf opgelegd wordt, het slaat elke innovatie dood als we kijken naar een bottom-up benadering middels de ideeënbus.
Kan me vergissen maar heel wat BPM zit in code die ooit eens geschreven is door iemand van de business met affiniteit voor automatisering, uiteindelijk kent niemand het proces beter dan degene die er dagelijks mee uit de voeten moet. Van bovenaf roepen dat ze onderaan harder moeten werken levert namelijk alleen maar het ‘Too many chiefs and not enough Indians’ syndroom op als we kijken naar de verdeling van het succes.