7 misstag små företag gör när de köper skräddarsydd programvara

De flesta små företag som bränner sig på ett projekt med skräddarsydd programvara bränner sig inte på dåliga programmerare. De bränner sig veckor innan någon programmering ens börjat — på ett uppstartsmöte, i en mejltråd, vid ett handslag — på ett beslut som kändes litet just då. När koden väl kommer är misstaget redan inbakat. Den goda nyheten är att dessa misstag är tråkigt upprepande, vilket betyder att de går att undvika om man vet hur de ser ut.

Jag har sett många sådana projekt inifrån, från båda sidor av bordet. Vissa blev verktyg som ett företag inte kan föreställa sig att jobba utan. Andra blev en halvfärdig inloggningsskärm, en spänd fakturatvist och en grundare som svär på att aldrig mer gå skräddarsytt. Det frustrerande är hur lite som skilde de två utfallen åt. Tekniken var sällan problemet. Besluten kring tekniken var det nästan alltid.

Så här är de sju misstag jag ser om och om igen när ett litet företag beställer skräddarsydd programvara. Inget av dem kräver teknisk bakgrund för att undvika. De kräver bara att du vet att de finns innan du skriver under något.

Misstag 1: Att köpa en lösning innan du förstår problemet

Det dyraste misstaget sker först, och det låter ofarligt: ”Vi behöver en app som gör X.” När någon väl säger det högt har de oftast redan bestämt lösningens form — en instrumentpanel, en portal, en mobilapp — utan att någon skrivit ner det faktiska problemet i klartext. Bygget levererar sedan troget fel sak, vackert utfört.

Bra programvara utgår från en problemformulering, inte en funktionslista. ”Vårt kontorsteam skriver om varje order från mejl in i bokföringssystemet, och det tar två personer en halv dag” är ett problem. ”Vi behöver ett skräddarsytt CRM” är en gissning på en lösning till ett problem som ingen brydde sig om att namnge. Det första kan lösas billigt och mätas. Det andra är en öppen inbjudan att spendera pengar.

Misstag 2: Att försöka bygga allt på en gång

Skräddarsydd programvara känns som ett köp man gör en gång per decennium, så folk försöker klämma in ett decenniums önskemål i version ett. Varje avdelning lägger till en begäran. Varje ”medan vi ändå håller på” får ett ja. Omfattningen sväller, tidslinjen tredubblas och projektet kollapsar under sin egen ambition långt innan någon hinner använda det.

Företagen som lyckas gör tvärtom. De väljer den enda mest smärtsamma biten av problemet och bygger den först — en verklig, fungerande sak i produktion inom ett par månader. Sedan låter de den faktiska användningen tala om vad som kommer härnäst. Detta är inte bara billigare; det är säkrare. Du lär dig om idén fungerar medan insatsen fortfarande är liten, istället för att upptäcka efter ett halvår och en stor faktura att du designade fel sak.

Under detta ligger en hård sanning: du vet faktiskt inte vad du behöver än. Ingen gör det, i början. Din förståelse av problemet kommer att förändras i samma stund som verkliga människor rör vid ett verkligt verktyg. Att bygga allt på förhand låser fast dina tidigaste, minst informerade gissningar. Att bygga i bitar håller dig flexibel — och håller budgeten under kontroll medan du fortfarande lär dig.

Misstag 3: Att välja enbart på pris

Du får tre offerter. En är dramatiskt billigare än de andra. Lättnad — du tar den. Det här är ett av de mest pålitliga sätten att förvandla ett litet projekt till ett dyrt, för den billiga offerten betyder nästan aldrig att arbetet är billigare. Den betyder oftast att de två sidorna förstod uppdraget olika.

En låg siffra signalerar ofta något av ett fåtal saker: leverantören underskattade omfattningen för att de inte ställde tillräckligt med frågor, de planerar att ta sin marginal på ändringsbeställningar senare, eller de är oerfarna och vet ännu inte vad de inte vet. Inget av det slutar väl för dig. Toppriset är den minst användbara siffran i offerten. Det som spelar roll är om leverantören tydligt förstår ditt problem, ställer obekväma frågor och är ärlig om vad som inte ingår.

Misstag 4: Att glömma att programvara inte är ett engångsköp

Skräddarsydd programvara säljs, och köps, ofta som en möbel: betala en gång, äg den för alltid. Det stämmer inte. Programvara lever i en värld i rörelse — operativsystem uppdateras, webbläsare ändras, säkerhetsuppdateringar dyker upp, din verksamhet förändras, verktygen du kopplar mot ändrar sina regler. Ett verktyg som ingen underhåller slutar sakta fungera, och går sedan sönder vid värsta tänkbara tillfälle.

Detta drabbar små företag hårt eftersom underhållskostnaden är osynlig vid signering. Du jämför två offerter på byggpriset och ställer aldrig frågan som betyder mer: vad kostar det att hålla detta levande och friskt varje år? Hosting, uppdateringar, små fixar, en och annan ändring när din verksamhet utvecklas — planera för det som en normal, löpande post, så som du gör för försäkring eller bokföring. Det är oftast blygsamt, men bara om du räknar med det.

Misstag 5: Att lämna kraven vaga och utan ägare

”Ni är experterna, bygg bara något bra” låter generöst. I själva verket är det så projekt driver iväg. De som förstår er verksamhet bäst är ni och ert team — inte utvecklarna. Om du lämnar över en luddig brief och försvinner fyller leverantören luckorna med sina bästa gissningar, och du upptäcker de gissningarna vid värsta tänkbara tillfälle: vid leverans, när det är dyrast att ändra dem.

Två roller måste fyllas på er sida, och små företag fyller rutinmässigt ingen av dem. Den första är en enda beslutsfattare — en person som kan säga ja, lösa oenigheter mellan avdelningar och inte är för upptagen för att svara på frågor i veckor. Den andra är viljan att vara specifik om de delar som spelar roll: gränsfallen, det märkliga undantaget som ert företag alltid hanterat för hand, regeln alla känner till men ingen skrivit ner. Det är precis det som programvaran måste få rätt.

Misstag 6: Att inte fråga vem som äger koden och datan

Det här är det tysta misstaget, och det som svider mest flera år senare. Du betalar för skräddarsydd programvara, du antar att den är din. Sedan surnar relationen med leverantören, eller de höjer priserna, eller de bara försvinner — och du upptäcker att du inte kan flytta dig. Du har inte källkoden. Datan ligger i ett system som bara de kommer åt. Hela din verksamhet hänger nu på ett företag du inte längre litar på, och du har ingen förhandlingsstyrka.

Inget av detta kräver en jurist för att förhindra. Det kräver tre enkla frågor ställda innan du börjar, medan du fortfarande har all förhandlingsmakt: Vem äger källkoden när detta är klart? Kan jag exportera all min data, i ett användbart format, när jag vill? Och om vi skiljs åt, vad exakt går jag därifrån med? En seriös partner svarar på dessa utan att blinka. Tvekan här är den enskilt största varningsflaggan i hela processen.

• Få det skriftligt att du äger källkoden, eller har en tydlig, rättvis licens till den.
• Bekräfta att du kan exportera din egen data i ett standardformat, på begäran, utan tillstånd.
• Se till att arbetet är dokumenterat tillräckligt väl för att en annan utvecklare ska kunna ta vid.
• Undvik proprietär inlåsning där en enkel, välkänd teknik skulle göra samma jobb.
• Kom överens i förväg om vad som händer med hosting och konton om du någonsin byter leverantör.

Misstag 7: Att behandla lanseringen som mållinjen

Programvaran är levererad, den fungerar, alla är lättade. Projektet förklaras klart. Ett halvår senare har halva teamet tyst gled tillbaka till det gamla kalkylbladet, och det dyra nya verktyget används av två personer till en sak. Bygget lyckades. Adoptionen misslyckades — och de två är helt olika problem.

Folk gör inte motstånd mot nya verktyg för att de är dumma eller envisa. De gör motstånd för att det nya sättet är obekant och det gamla sättet fortfarande fungerar, typ. Att besegra det kräver medvetet arbete som ingen budgeterade för: lite utbildning, ett tydligt skäl till varför förändringen hjälper dem specifikt, någon som svarar på de dumma frågorna utan att döma under de första veckorna, och ett bestämt beslut att pensionera det gamla sättet så att det inte finns något att glida tillbaka till.

1. 1
   Lansera till en liten grupp först

   Rulla ut verktyget till några villiga personer före hela teamet. De hittar de skrovliga kanterna och blir dina interna förespråkare.
2. 2
   Visa den personliga vinsten, inte företagsvinsten

   ”Det här sparar pengar åt företaget” motiverar ingen. ”Det här betyder att du slutar skriva adresser två gånger” får folk med på tåget.
3. 3
   Utse en go-to-person för frågor

   Under första månaden äger någon de dumma frågorna. Friktion vecka ett är vad som dödar adoptionen för alltid.
4. 4
   Stäng faktiskt av det gamla sättet

   Så länge det gamla kalkylbladet finns kvar kommer folk att fortsätta använda det. När det nya fungerar, pensionera reservutvägen — varsamt men tydligt.

Att knyta ihop det: ett köparperspektiv

Läs de sju igen och en enda tråd löper genom dem. Nästan inget är tekniskt. De handlar om klarhet, ägande och återhållsamhet — att känna sitt problem innan man handlar, att bygga i små steg, att bedöma leverantörer på förståelse snarare än pris, att planera för verktygets livslängd och inte bara dess födelse, att förbli involverad, att skydda sin utväg och att behandla lanseringen som början på det riktiga arbetet.

Skräddarsydd programvara är på riktigt en av de bästa investeringar ett litet företag kan göra när det väl vuxit ur de standardverktyg som alla delar. Ett system format exakt efter hur ni arbetar, snarare än att tvinga er verksamhet att förvridas kring någon annans produkt, är en verklig och bestående fördel. Företagen som tar sig dit är inte de med störst budgetar. Det är de som undvek de sju misstagen ovan — och det är en fråga om omdöme, inte pengar.

Vanliga frågor