Best practice eller less practice?

Allt oftare tillämpas begreppet best practice när det gäller uppsättning och implementering av IT-system. Med uttrycket menas att kunden ska kunna dra fördel av många andra tidigare kunders erfarenheter och erhålla en systemuppsättning som bygger på ”optimalt” utformade verksamhetsprocesser. Dessutom ska implementeringen kunna genomföras på kort tid då mycket av uppsättningen är förkonfigurerat. Allt detta låter ju ganska bra, men hur väl stämmer det med verkligheten? Faktiskt inte särskilt väl. Problemet är att det finns flera inbyggda konflikter i begreppet.

Till att börja med bygger antagandet om best practice på tesen att verksamhetsprocesser är så pass lika mellan företag att de går att applicera på en mångfald av verksamheter, samt att leverantörens grundläggande ”mall” för systemkonfigurationen ständigt uppdateras och förbättras. Det förstnämnda stämmer delvis om man håller sig till en relativt smal industrigren där det finns en stor volym av organisationer, men inte i de fall där antalet företag är begränsat. Det sistnämnda stämmer inte alls då det finns få exempel på leverantörer som kontinuerligt uppdaterar och förbättrar sina malluppsättningar. Istället visar erfarenheten att leverantörens mall ofta bygger på en enda eller väldigt få genomförda projekt och därmed enbart kan kallas för ”leverantörens mall” istället för best practice.

Vidare är det faktiskt få organisationer som verkligen vill kopiera vad den ”stora massan” gör när man börjar diskutera verksamhetens mål och ambitioner. Det skulle innebära att man i praktiken säger att det vi gör är inget speciellt, utan vi är som alla andra. Och om detta vore fallet har man sannolikt tagit steget mot sin egen undergång. Istället framkommer det i merparten av alla strategiutredningar att de flesta verksamheter strävar efter att bli unika för att därmed skaffa sig konkurrensfördelar. Man kan klara rätt länge på att erbjuda unika produkter, men i längden blir alltid konkurrensen så svår att det är andra parametrar som krävs för att behålla sin särställning på marknaden och då är verksamhetens processer en avgörande faktor.

Till detta ska läggas att processutveckling aldrig kan särskiljas från det vi vanligtvis kallar ”ledning/styrning” som inkluderar verksamhetens historik, dess kultur och värdegrunder. Och att över en natt förändra modellen för ledning/styrning är väsentligen svårare än att förändra en verksamhetsprocess. Och ledning/styrning präglas dessutom starkt av ägarnas krav på verksamheten och dess ledning. Ovanstående lista över invändningar/konflikter mot begreppet best practice kan göras väsentligen längre.

Märk väl – det finns inget som helst fel i önskan att vilja dra fördel av erfarenheten från många andra organisationer och kanske till och med få influenser som kan bidra till ett nytänk. Problemet är snarare att det vi ofta kallar best practice inom systemvärlden aldrig bygger på ”branschstandard” utformad av ett kvalitetssäkrande branschorgan. Istället visar det sig att 10 olika leverantörer av verksamhetssystem riktade mot samma bransch uppvisar 10 relativt olika modeller för vad som är best practice och enbart bygger på den enskilde leverantörens erfarenheter från en eller få genomförda projekt. Och till detta kommer att varje enskild sk best practice är utformad utifrån det aktuella affärssystemets enskilda styrkor och brister.

Rådet till en kund i begrepp att upphandla och införa ett nytt systemstöd är att inta en ifrågasättande attityd mot leverantören när begreppet best practice kommer på tal. Kräv att få se hur väl denna modell är dokumenterad samt kräv att få se bevis för att berörda konsulter är certifierade i denna best practice samt att help desk är upplärda på modellen. Vidare ska leverantören tydligt kunna redogöra för hur just denna specifika best practice skiljer sig mot övriga industrivertikalers best practice. Väldigt ofta visar det sig att begreppet innehåller mer luft än beprövad kvalitet.