Feil er det eneste alternativet
Jeg kan rett ut fortelle deg at BPM-implementeringen din kommer til å mislykkes, og jeg vil ha rett 9 av 10 ganger. Er dette skummelt?
Forskning har vist at selv blant IT-prosjekter fullfører bare 20 % av dem i tide. På BPM-prosjekter er feilprosenten enda høyere på grunn av umodenhet i teknologien og omfanget av implementeringen. Hvis du implementerer et BPM-prosjekt med de gjeldende verktøyene og bruker de gjeldende standardene som fortsatt er i endring, er du på forkant med teknologien. Så feilraten din er enda høyere.
I denne artikkelen vil vi diskutere noen av de viktigste årsakene til feil. Når du forstår en årsak, er løsningen for den enkel å finne ut. Implementering av reparasjonen er imidlertid det største problemet. For eksempel er en viktig årsak til feil mangel på kommunikasjon. Løsningen er enkel – trenger å fremme mer kommunikasjon. Imidlertid er det lettere sagt enn gjort å implementere "bedre kommunikasjon".
Et trossprang
Bortsett fra at BPM-implementeringen er banebrytende, har den en annen fasett som gjør den forskjellig fra et "vanlig" IT-prosjekt. Det spenner over flere siled avdelinger. I kraft av å være en forretningsprosess vet vi at den må spenne over hele organisasjonen. Den svakeste delen av en prosess er i grensesnittet mellom avdelingene, når overleveringen ikke fungerer bra.
Tidligere gikk hver avdeling ut og kjøpte "best-of-breed"-applikasjonen for sine spesielle behov. Det ble imidlertid ikke tatt mye hensyn til behovene til den generelle forretningsprosessen. Noe av grunnen til det var mangelen på en "prosessansvarlig" som ville ha identifisert optimaliseringsparametere på tvers av prosessen.
Hva feiler?
Kommunikasjon – Vi kom inn på det faktum at kommunikasjon eller mangel på sådan kan føre til at prosjektet mislykkes. Kommunikasjon må nå legges til rette ikke bare innenfor avdelingen, men også på tvers av avdelingsgrenser. Enten du liker det eller ikke, jo større organisasjonen er, jo større er sjansene for politikk og len. Å komme til enighet om enkle ting kan ta enorme mengder tid.
Suksess på dette området må tilrettelegges av en prosjektleder som jobber i samarbeid med prosesslederen. Murene til len må brytes ned – og dette kan bare oppnås med støtte fra utøvende myndigheter. På et tidspunkt, hvis en konsensusbasert tilnærming ikke fungerer, kan en diktatorisk tilnærming være de eneste alternativene. Den sponsorsjefen må kanskje gi en frist "Nå en konklusjon om X dager, ellers må du leve med den jeg foreslår."
Arkitektur – I mange av BPM-prosjektene jeg har sett mislykkes, var arkitekturen svak. Dette var enten fordi teamene ikke ville være i stand til å komme til enighet eller fordi det ikke var en enkelt arkitekt som hadde ansvaret for forretningsprosessen. Selv med en Service Oriented Architecture (SOA)-tilnærming er det ikke nok for de forskjellige applikasjonene å publisere grensesnittene sine og forvente at forbrukeren tilpasser seg det grensesnittet. Ofte blir en arkitekt som forstår ett forretningsdomene flyttet inn i posisjonen med høyere ansvar. Han eller hun kan da ha et skjevt syn på løsningene.
Løsningen ville være å nominere en sterk arkitekt som forstår det generelle forretningsproblemet og prosessen for å overvåke alle grensesnittdefinisjoner på tvers av avdelinger. Hvis slik domenekunnskap ikke er tilgjengelig med en enkelt arkitekt, er et arkitektteam et godt kompromiss. Det andre alternativet ville være lederstøtte for en enkelt arkitekt som kan jobbe på tvers av avdelingsgrenser uten å bli mobbet.
Lederstøtte – Som du legger merke til, er lederstøtten et tilbakevendende tema som er avgjørende for suksessen til BPM-implementeringen på grunn av at prosjektets natur er at det spenner over avdelingsgrenser. Den forretningsmessige begrunnelsen for BPM-implementeringen må komme fra toppen, med full støtte hele veien frem til utrulling. Toppledelsen må være spesielt aktiv i å avbryte politikk og len og samtidig opprettholde et sunt miljø. Dette kan være svært vanskelig å gjøre.
En tilnærming vil være å tvinge avdelingslederne til å møtes oftere i en ikke-truende atmosfære for å bidra til å bygge tillit og for å forklare hvordan implementeringen vil komme alle involverte til gode. Hver avdeling bør ha spesielle fordeler, ellers vil implementeringen mislykkes.
Business IT-feiljustering – Hvis BPM-prosjektet startes med stor fanfare, men senere "kastes over veggen" for IT å implementere, vil IT mest sannsynlig bli fanget opp i lokket med å bruke den nyeste teknologien i stedet for å ta tak i forretningsproblemet på hånd, som det er førsteprioritet. Dette er rett og slett naturen til de tekniske menneskene. Det som driver dem er teknologien og noen ganger som kan overvinne forretningsbehovet, hvis det ikke overvåkes ordentlig.
Løsningen for dette ville være at ledelsen kontinuerlig overvåker fremdriften gjennom flere moduser. For eksempel bør ledelsen insistere på regelmessige møter og oppdateringer, og kanskje til og med en måte å "se på" implementeringen i sanntid – kanskje ved å se på rapporter om feilene eller insistere på at et system skal være tilgjengelig kontinuerlig for å vise frem funksjonene som har blitt implementert så langt.
Integrasjon – Det er et velkjent faktum at integrasjon er blant de vanskeligste delene av en IT-implementering, men den får ikke den oppmerksomheten den fortjener på forhånd. Hvis to grupper bygger en bro fra hver side, bør vi være 100 % sikre på at de kommer til å møtes på midten.
En av BPM-arkitektens ansvar er å sikre rene og konsistente grensesnitt. Eventuelle endringer i slike grensesnitt bør gjennomgås og godkjennes minimalt av berørte parter, men aller helst av alle arkitektene involverer for å sikre at det ikke gir ringvirkninger andre steder.
Testing - Mange selskaper spiller leppeservice til testing. Realiteten er at bedriften mener at de har tildelt nok tid til testing, men implementeringsteamet bestemmer seg for å presse ut testingen til slu*tten. Når slu*tten nærmer seg og funksjonaliteten ennå ikke er fullført, og likevel tidsfristen forblir den samme, blir testingen kompromittert. I noen ekstreme tilfeller «håper» implementeringsteamet bare at systemet vil fungere som planlagt. Uunngåelig gjør det ikke.
For å redusere denne risikoen, må ledelsen insistere på at testsykluser starter fra de tidligere fasene av prosjektet. De trenger også å få innsyn i testprosessen og planlegger å sikre at testingen fortsetter som planlagt og ikke kompromitteres for andre funksjoner. Ledelsen bør også håndheve en tankegang om at "testing er like kritisk som implementering" og bør heller presse ut leveringsdatoen i stedet for å gi ut et delvis testet system.
For å konkludere
I denne artikkelen dekket vi noen av hovedårsakene til BPM-implementeringsfeil. Nøkkelen for å unngå disse dyre feilene er å hele tiden overvåke og korrigere for det – mye av dette krever sunn fornuftshåndteringsteknikker. Utførelse er nøkkelen.
Raj Ramesh, Ph.D., er president for TopSigma, et BPM-konsulentfirma som jobber med kunder for å sikre vellykket implementering. Som foredragsholder og konsulent er han en talsmann for seniorledelsens deltakelse i bedriftens BPM-initiativer. Han kan kontaktes på raj@topsigma.com.
