Hur något som egentligen är så självklart kan komma som en aha-upplevelse är en gåta – även för mig som jobbar med det dagligen. För ett litet tag sedan höll jag en utbildning i upphandling och kravställning, “Certifierad Agil Beställare”, efter utbildningen sa en av deltagare att den största aha-upplevelsen var insikten att vi ska göra en bra “behovsställan” i stället för kravställan för att lyckas med upphandlingen och inte styra in på detaljerade lösningar. Det var ju så självklart! Att jag inte har sett det förut?
I den stunden myntades ett nytt begrepp – “behovsställan”.
Insikten hade hon fått genom att vi hade gjort övningar i att gemensamt definiera målgrupper med gemensamma behov, och sedan titta på vilka dom behoven var genom att göra user journeys. Insikten att vi definierar befintliga beteenden och hittar problem som utgångspunkt i upphandlingen gjorde stor skillnad i att förstå att en lyckad upphandling måste vara en upphandling som utgår från behov och löser riktiga problem för riktiga användare.
Ett skifte som många behöver göra
Ofta när jag jobbar på produktföretag, oavsett storlek, så ser jag att just detta är är ett skifte som behöver göras. Många företag fokuserar direkt på vad lösningen är genom att beskriva en detaljerad lösning, i stället för att först titta på VARFÖR och för VEM, vad är behovet och vilka problem ska vi lösa? Har vi inte förstått vad problemet är och för vem, så kan vi inte heller hitta den rätta lösningen. Det faktiska utförandet av lösningen bör ligga i teamet, och inte hos beställaren, det är dom som har kunskapen och verktygen att bygga lösningen på rätt sätt, beställaren bör fokusera på att man bygger rätt sak.
De vanligaste upplevda problemen för upphandlare
När jag frågar de som gör upphandlingar av digitala tjänster och produkter så brukar de största upplevda problemen vara att det är svårt:
– Att i förväg definiera alla “kraven” rätt.
– Att få med “allt” i upphandlingsunderlaget.
– Att få leverantören att leverera något som fungerar.
Allt detta löser man om man upphandlar utifrån behov och effekt, i stället för att upphandla utifrån en fix lösning – som man sedan oundvikligen kommer att upptäcka var fel lösning.
Endast en bråkdel av systemen används av användarna
På grund av att upphandligar ofta görs så att man fixerar lösningen från början och inte tillåter sig upptäcka vilka behoven och lösningarna är, så ser vi i dag i de flesta system att endast 20% av systemets funktioner används ofta, och ytterligare 20% som används sällan. Hela 60% av funktionerna i de flesta system används ALDRIG! Det här är självklart en katastrof både för beställaren som betalar för något helt i onödan, får ett system som är onödigt dyrt att underhålla,får en senare leverans än nödvändigt, och även användaren så klart, som drabbas av gränssnitt som är oanvändarvänliga på grund av dålig struktur, för många val och information och funktioner som ligger ivägen för det man egentligen vill göra. Tänk vilken skillnad det skulle göra inom verksamheter som tex ett sjukhus om man hade IT-system var byggt efetr behov, som gav rätt stöd till läkare och sjuksystrar, som inte krävde att man lade in samma information 4 gånger i 4 olika system för att hantera ett litet ärende. Och tänk vilken ekonomisk skillnad det skulle göra för Landstingen.
Lösningen ligger delvis i att vända på upphandlingsförfarandet och “behovsställa” i stället för “kravställa”. Jag hoppas det blir den nya standarden, och att fler drabbas av samma aha-upplevelse som både jag och min kursdeltagare.
Agila kontrakt – den röda tråden som löper från behovställan till användande och skapar effekt
Ett sätt att få behoven i fokus hela vägen till leverans och implementation är genom att använda Agila kontrakt. Agila kontrakt möjliggör behovsställning, och ger beställaren möjlighet att sätta effekter som mål och tillåter en lärande process tillsammans med leverantören genom att man får byta ut “krav” om man upptäcker att dom är felaktiga. Du kan läsa mer om agila kontrakt och se lyckade case på den dedikerade webbplats som jag har skapat tillsammans med min kollega Mattias Skarin.
