BPM moet probleem oplossen, niet veroorzaken

Colin Earl, CEO van BPM-leverancier EnterpriseWizard, adviseert om eerst te beginnen met het automatiseren van een enkel bedrijfsproces.
Volgens mij moet je eerst het process bekijken of het wel geautomatiseerd moet worden, of gesaneerd of met duct tape of ...
En dan is er een kans dat BPM de tool kan zijn. En dan kun je kijken welke BPM tool en dan automatiseren

Laten we de software installeren en daarna een project zoeken die het ondersteunt'.”

Klinkt als oplossing zoekt probleem.
Heb al een paar keer zo iets zien mislukken, omdat de ict-afd er niet achterstaat, behalve de manager. vervolgens wordt het niet projectmatig uitgevoerd, om maar niet te spreken van ontbrekende gebruikers wensen.
De ict-afd staat er niet achter omdat zij zien dat het heel veel geld kost terwijl er zo veel andere problemen zijn op te lossen, waarvan de manager weer niet kan bevatten wat voor impact dat allemaal wel niet heeft, terwijl de manager weer zegt dat zijn ictérs geen overview hebben om de noodzaak te kunnen bevatten.
Of te wel deze speeltjes software ligt te dicht bij de board en als het door de board wordt geïnitieerd dan is het zowiezo onzin ;-)

Business Process Management (BPM) wordt ingezet om de flexibiliteit van de bedrijfsvoering te vergroten.
ICT == auto-matisering

Let op het woordje 'auto'; het vervangt een bestaand bedrijfsproces. Als dit niet goed werkt zonder automatisering, dan zal het zeker niet werken met automatisering, en daarbovenop zal het ook niet flexibeler worden.

Helaas is de werkelijkheid een stuk genuanceerder en gecompliceerder dan Watson ons wil doen geloven.
De tijd is echt allang voorbij dat BPM als een puur automatiseringstool wordt gezien. Dat geldt wellicht nog wel voor de SOA-adepten die denken dat BPM en orchestration hetzelfde zijn (Oracle bijvoorbeeld), maar in onze praktijk wordt geen licentie meer verkocht zonder een sluitende business case.
Helaas is BPM ook nog niet zo volwassen als Watson ons wil doen geloven. Er is veel onduidelijkheid over wat BPM nu eigenlijk precies is, en momenteel slaat de markt door in de onrealistische gedachte dat BPM zo simpel is dat je geen ICT afdeling meer nodig hebt. Niets is minder waar. Een goed BPM project is nog steeds een automatiseringsproject, met als groot verschil dat de business niet alleen bij de DEFINITIE en de INVOERING van een BPM systeem een leidende rol speelt, maar juist ook in het GEBRUIK en CONFIGURATIE ervan. En met name dat laatste staat bij veel producten nog in de kinderschoenen.
Verder hebben we heel veel projecten zien slagen in een pilot, zonder dat er binnen de betrokken organisaties daarna bedrijfsbreed is uitgerold. Dit heeft alles te maken met de door Earl gepropageerde aanpak. Eerst maar eens een projectje doen om te bewijzen dat het werkt en dan verkoopt het zich vanzelf. Welnu, niets is minder waar. Ik heb veel succesvolle pilots hier zien stranden.
Serieuze invoering van BPM is een meerjarenprogramma dat niet alleen gaat om het implementeren van software, maar de business een middel in handen geeft waarmee zij hun processen kunnen besturen en continue verbeteren. Dat vereist een lange termijn visie en bijbehorende aandacht.
Dan nog een opmerking over standaarden:
Er zijn er eigenlijk maar twee waarover momenteel veel gesproken wordt: BPEL en BPMN. De eerste is eigenlijk al afgeserveerd omdat dit nu juist geen standaard is geworden en BPEL ook geen enkele garantie voor uitwisselbaarheid geeft, maar bovendien volstrekt tekort schiet voor processen met veel menselijke interactie. De tweede is beter geland, maar is alleen een notatiewijze om processen te beschrijven, die geen enkele garantie geeft over de automatisering van processen. Versie 2 belooft beter te worden, maar is nog zeker niet breed geaccepteerd. Ook hier is echter nog geen enkele garantie over uitwisselbaarheid. Extra complicatie daarbij is nog dat BPMN en BPEL niet echt goed samengaan, ondanks claims die dit suggereren.