17 år tar det för en ny uppfinning att bli en innovation. Alltså från det att alla tester är gjorda och evidensen så att säga är på plats, till något som de facto används i vardagens vård, den där patienter i behov av behandling finns. Varför tar det så lång tid? Många är de utredningar som pekar på att vi behöver satsa mer på forskning, framför allt klinisk sådan, mer på kvalitetsregister och så vidare.

Det ligger en del i det, dock är det bara ett perspektiv på sakernas tillstånd och kanske inte det som brinner mest i knutarna. Kanske är så att vi inte riktigt vet vad vi ska göra. Ibland är det lite för mycket verkstad och lite för lite snack. Jag tror att vi behöver diskutera problemet från ett annat håll: med fokus på systemets mottaglighet för nya produkter, arbetssätt och metoder. Som forskare talar vi ofta om att identifiera olika hinder som kan stoppa idéerna. Där tappar vi ofta alla handlingens kvinnor och män som gärna vill ha Modellen som i ett slag ändrar på verkligheten. Vi sägs problematisera istället för att agera. Alltså: för mycket snack och för lite verkstad.

Detta har jag hört under de snart 30 år jag arbetat med att föra över empiriskt grundade teorier till den "verkliga" verkligheten. Under tiden har forskningen pekat ut detaljstyrning och överambitiöst mätande som innovationshämmande. Det är empiriskt bevisat att one size doesn't fit all, alltså att Modellen inte passar i de lokala sammanhangen, varför överdriven styrning ger nära noll i följsamhet. Eller som vi brukar säga: att styra på distans är som att leda ett barnkalas per SMS. Men det var inte förrän jag började banna min egen förmåga att kommunicera och forskarnas esoteriska sätt att skriva, som lyssnarna blev fler.

Att problematisera är en bra början på all ny kunskap. Att leta systemhinder är ett sätt att bättre förstå hur en uppfinning kan bli till en innovation.

Att problematisera är en bra början på all ny kunskap. Att leta systemhinder är ett sätt att bättre förstå hur en uppfinning kan bli till en innovation. Detta eftersom produkten/tjänsten/idéen sätts in sitt verkliga sammanhang. Ofta vill vi hellre att projekt ska gå att mäta, och då går det inte för sig att blanda in för många störande faktorer. Detta i kombination med ett ideal som säger att randomisering är detsamma som vetenskap, när Metoden så att säga blir Modellen, har gjort att ett närmast oändligt antal piloter inte blivit vardag. Då uppstår friktion och ibland rent gnäll: vi sprider inte det goda, systemet straffar ut allt nytt och så vidare.

Att istället redan från början tänka på hur implementering ska gå till inom ramen för ett existerande system med regelverk, resursfördelningsmodeller och gamla normer ökar sannolikheten för överlevnad. Tre enkla frågor kan vi då ställa oss: Kan vi? Vill vi? Duger idén? "Kan" relaterar till förutsättningarna i systemet – lagar, regler, föreskrifter, ersättningsmodeller med mera. "Vill vi"? En fråga som sällan ställs och sällan lyfts fram. De som inte vill, argumenterar hellre i banorna "så har vi aldrig gjort...hur skulle det se ut". "Duger inte" relaterar till huruvida idén håller eller inte. Den entreprenör som inte anser att just hens idé är bäst hittills finns nästan inte. Den som kan ändra sin idé för att den inte höll i verkligheten blir även företagare. Detta gäller även intraprenörer.

Alltså bör vi i mycket högre utsträckning än idag ägna oss att att förstå de sammanhang som nya idéer ska frodas i. Istället för att satsa alla investeringar på isolerade projekt och piloter för att utveckla en ny idé, borde vi satsa en del av pengarna på att förstå hur mottagligheten och anpassningsbarheten i vardagen kan ökas. Att leta hinder är i sig inget negativt. Det handlar istället om att identifiera utmaningarna vi står inför för att utveckling ska kunna ske. Då kan vi kanske lära oss att samarbeta med andra för att komma framåt. Det får inte bli en ursäkt för att klaga på alla som sätter käppar i hjulet. Då kanske det till slut kan finnas fog för att säga att vi egentligen vet vad vi ska göra – det är bara att göra det. Där är vi inte.