4 min

Varför standardlösningar sällan löser rätt problem

Om faran med out-of-the-box-tänkande. När anpassning till verktyget dödar anpassning till behovet.

Michael Hansson

“Vi tar den här plattformen.”

“Den har allt vi behöver.”

“Vi anpassar oss till den.”

Jag hör det ofta.

Och varje gång tänker jag:

“Ni kommer ångra det.”

Out-of-the-box betyder inte klart

Standardlösningar marknadsförs som enkla.

“Allt du behöver. Direkt.”

Men vad de inte säger är:

“Allt vi tror att folk behöver. I genomsnitt.”

Och genomsnitt passar sällan någon.

För er verksamhet är inte genomsnitt.

Den har sina quirks. Sina sätt att jobba. Sina processer som ni byggt under år.

Och när ni trycker in dem i en standardlösning - börjar det skava.

Vad som händer när ni anpassar er till verktyget istället för tvärtom

Steg 1: Ni väljer plattformen

Den ser bra ut. Demot funkar perfekt. Säljaren lovar att “allt går att konfigurera”.

Ni skriver på.

Steg 2: Ni börjar bygga

Och upptäcker att det ni gör inte riktigt matchar hur plattformen fungerar.

Men ni tänker:

“Vi anpassar oss. Det är väl bra att standardisera.”

Steg 3: Folk börjar klaga

“Det tar längre tid nu.” “Vi måste klicka fem gånger för att göra det vi förut gjorde i en.” “Systemet förstår inte hur vi jobbar.”

Men ni säger:

“Ni vänjer er.”

Steg 4: Folk hittar workarounds

De bygger Excel-filer vid sidan av. De skippar systemet för vissa saker. De dubbelregistrerar.

För systemet funkar inte för dem.

Steg 5: Ni betalar för något ni inte använder

Hälften av funktionerna används aldrig. Halva teamet har hittat sina egna lösningar.

Men ni betalar fortfarande för plattformen.

Problemet är inte verktyget - det är matchningen

Standardlösningar är inte dåliga.

De är bra - för dem de är byggda för.

Men de är inte byggda för er.

De är byggda för “företag i er storlek i er bransch”.

Och det är ett genomsnitt.

Och genomsnitt passar sällan verkligheten.

När standardlösningar funkar

Det finns tillfällen när de är rätt val:

1. Ni gör något helt standardiserat

Bokföring. Tidrapportering. E-postutskick.

Om processen är densamma överallt - använd en standardlösning.

2. Ni är villiga att förändra er process

Om er nuvarande sätt att jobba inte är heligt - och ni vill förändra - kan en standardlösning tvinga fram det.

Men då måste ni vara medvetna om det.

3. Ni har inte resurser att bygga själva

Ibland är “bra nog” bättre än “perfekt men vi har inte råd”.

Men då måste ni acceptera kompromissen.

När ni ska bygga själva istället

1. Er process är er konkurrensfördel

Om det sätt ni jobbar på är det som gör er unika - bygg inte bort det.

Behåll det. Förstärk det.

2. Standarden tvingar er att jobba sämre

Om ni måste göra fler steg, dubbelregistrera, eller bygga workarounds - är det inte en förenkling.

Det är en förvärring.

3. Kostnaden för att anpassa är högre än att bygga

Om ni måste betala konsulter 500 000 kronor för att anpassa en standardlösning - kanske det är billigare att bygga rätt från början.

Frågor att ställa innan ni väljer standardlösning

1. Vad är vårt faktiska problem?

Inte “vi behöver ett CRM”.

Utan: “Vi tappar koll på kunder och missar uppföljningar.”

Lös problemet. Inte kategorin.

2. Kan vi ändra vårt sätt att jobba för att passa verktyget?

Och vill vi det?

Om svaret är nej - välj inte verktyget.

3. Vad händer om vi inte kan göra X i systemet?

Hur kritiskt är det?

Kan vi leva utan det - eller blir det ett showstopper?

4. Vad kostar det att komma ur avtalet om det inte funkar?

Lock-in är verkligt.

Om ni inte kan lämna - är ni fångade.

På måndag

Om ni är mitt i ett val av standardlösning - gör det här:

1. Lista era tre viktigaste processer

De som verksamheten inte kan leva utan.

2. Testa om plattformen klarar dem - utan workarounds

Om ni måste “lösa det sen” - funkar det inte.

3. Fråga användarna

Inte chefer. Inte IT.

De som ska använda det varje dag.

Om de säger “det här kommer bli jobbigt” - lyssna.

Standardlösningar är inte dåliga.

Men de löser standardproblem.

Och om ert problem inte är standard - kommer lösningen inte passa.