7 fejl små virksomheder begår, når de køber skræddersyet software

De fleste små virksomheder, der brænder fingrene på et projekt med skræddersyet software, brænder dem ikke på dårlige programmører. De brænder dem uger før nogen programmering overhovedet er begyndt — på et opstartsmøde, i en mailtråd, ved et håndtryk — på en beslutning, der føltes lille dengang. Når koden endelig ankommer, er fejlen allerede bagt ind. Den gode nyhed er, at disse fejl er kedeligt gentagne, hvilket betyder, at de kan undgås, hvis man ved, hvordan de ser ud.

Jeg har set mange af disse projekter indefra, fra begge sider af bordet. Nogle blev til værktøjer, en virksomhed ikke kan forestille sig at arbejde uden. Andre blev til en halvfærdig login-skærm, en anspændt fakturastrid og en grundlægger, der sværger aldrig at gå skræddersyet igen. Det frustrerende er, hvor lidt der skilte de to udfald. Teknologien var sjældent problemet. Beslutningerne omkring teknologien var det næsten altid.

Så her er de syv fejl, jeg ser igen og igen, når en lille virksomhed bestiller skræddersyet software. Ingen af dem kræver en teknisk baggrund at undgå. De kræver blot, at du ved, de findes, før du skriver under på noget.

Fejl 1: At købe en løsning, før du forstår problemet

Den dyreste fejl sker først, og den lyder harmløs: “Vi har brug for en app, der gør X.” Når nogen siger det højt, har de som regel allerede besluttet løsningens form — et dashboard, en portal, en mobilapp — uden at nogen har skrevet det egentlige problem ned i klar tale. Bygget leverer så trofast den forkerte ting, smukt udført.

God software starter fra en problemformulering, ikke en funktionsliste. “Vores kontorteam taster hver ordre om fra mail ind i regnskabssystemet, og det tager to personer en halv dag” er et problem. “Vi har brug for et skræddersyet CRM” er et gæt på en løsning til et problem, ingen gad navngive. Det første kan løses billigt og måles. Det andet er en åben invitation til at bruge penge.

Fejl 2: At forsøge at bygge alt på én gang

Skræddersyet software føles som et køb, man kun gør én gang i et årti, så folk prøver at proppe et årtis ønsker ind i version ét. Hver afdeling tilføjer en anmodning. Hvert “mens vi er i gang” får et ja. Omfanget vokser, tidsplanen tredobles, og projektet kollapser under sin egen ambition længe før nogen får det i brug.

De virksomheder, der lykkes, gør det modsatte. De vælger den enkelt mest smertefulde skive af problemet og bygger den først — en rigtig, fungerende ting i produktion inden for et par måneder. Så lader de den faktiske brug fortælle dem, hvad der kommer næst. Det er ikke bare billigere; det er mere sikkert. Du lærer, om idéen virker, mens indsatsen stadig er lille, i stedet for at opdage efter et halvt år og en stor faktura, at du designede den forkerte ting.

Under dette ligger en hård sandhed: du ved faktisk ikke, hvad du har brug for endnu. Det gør ingen, i begyndelsen. Din forståelse af problemet ændrer sig i det øjeblik, rigtige mennesker rører ved et rigtigt værktøj. At bygge alt på forhånd låser dine tidligste, mindst informerede gæt fast. At bygge i skiver holder dig fleksibel — og holder budgettet under kontrol, mens du stadig lærer.

Fejl 3: At vælge alene på pris

Du får tre tilbud. Et er dramatisk billigere end de andre. Lettelse — du tager det. Det er en af de mest pålidelige måder at gøre et lille projekt dyrt på, for det billige tilbud betyder næsten aldrig, at arbejdet er billigere. Det betyder som regel, at de to parter forstod opgaven forskelligt.

Et lavt tal signalerer ofte én af et par ting: leverandøren undervurderede omfanget, fordi de ikke stillede nok spørgsmål, de planlægger at tjene deres margin på ændringsanmodninger senere, eller de er uerfarne og ved endnu ikke, hvad de ikke ved. Ingen af delene ender godt for dig. Overskriftsprisen er det mindst nyttige tal i tilbuddet. Det, der betyder noget, er, om leverandøren tydeligt forstår dit problem, stiller ubehagelige spørgsmål og er ærlig om, hvad der ikke er inkluderet.

Fejl 4: At glemme, at software ikke er et engangskøb

Skræddersyet software bliver ofte solgt, og købt, som et møbel: betal én gang, ej det for evigt. Sådan er det ikke. Software lever i en verden i bevægelse — styresystemer opdateres, browsere ændrer sig, sikkerhedsrettelser kommer, din forretning skifter, de værktøjer du forbinder til ændrer deres regler. Et værktøj, ingen vedligeholder, holder langsomt op med at virke og går så i stykker på det værst tænkelige tidspunkt.

Det rammer små virksomheder hårdt, fordi vedligeholdelsesomkostningen er usynlig ved underskrift. Du sammenligner to tilbud på byggeprisen og stiller aldrig det spørgsmål, der betyder mere: hvad koster det at holde dette levende og sundt hvert år? Hosting, opdateringer, små rettelser, den lejlighedsvise ændring efterhånden som din forretning udvikler sig — planlæg det som en normal, løbende post, ligesom du gør for forsikring eller bogføring. Det er som regel beskedent, men kun hvis du regner med det.

Fejl 5: At lade kravene være vage og uden ejer

“I er eksperterne, byg bare noget godt” lyder generøst. Det er faktisk sådan, projekter driver afsted. De, der forstår din forretning bedst, er dig og dit team — ikke udviklerne. Hvis du afleverer et uklart brief og forsvinder, fylder leverandøren hullerne med deres bedste gæt, og du opdager de gæt på det værst tænkelige tidspunkt: ved levering, hvor det er dyrest at ændre dem.

To roller skal udfyldes på din side, og små virksomheder undlader rutinemæssigt at udfylde nogen af dem. Den første er én enkelt beslutningstager — én person, der kan sige ja, afgøre uenigheder mellem afdelinger og ikke er for travl til at svare på spørgsmål i ugevis. Den anden er viljen til at være specifik om de dele, der betyder noget: grænsetilfældene, den mærkelige undtagelse din forretning altid har håndteret i hånden, reglen alle kender, men ingen har skrevet ned. Det er præcis det, softwaren skal have ret i.

Fejl 6: Ikke at spørge, hvem der ejer koden og dataene

Det er den stille fejl, og den, der gør mest ondt år senere. Du betaler for skræddersyet software, du går ud fra, den er din. Så surner forholdet til leverandøren, eller de hæver priserne, eller de forsvinder simpelthen — og du opdager, at du ikke kan flytte dig. Du har ikke kildekoden. Dataene ligger i et system, kun de har adgang til. Hele din drift afhænger nu af en virksomhed, du ikke længere stoler på, og du har ingen forhandlingskraft.

Intet af dette kræver en advokat at forhindre. Det kræver tre enkle spørgsmål stillet før du starter, mens du stadig har al forhandlingsmagten: Hvem ejer kildekoden, når dette er færdigt? Kan jeg eksportere alle mine data i et brugbart format, når jeg vil? Og hvis vi skilles, hvad går jeg så præcis derfra med? En seriøs partner svarer på disse uden at blinke. Tøven her er det enkeltstående største advarselstegn i hele processen.

• Få det på skrift, at du ejer kildekoden, eller har en klar, fair licens til den.
• Bekræft, at du kan eksportere dine egne data i et standardformat, på forlangende, uden tilladelse.
• Sørg for, at arbejdet er dokumenteret godt nok til, at en anden udvikler kan tage over.
• Undgå proprietær fastlåsning, hvor en enkel, velkendt teknologi ville gøre samme arbejde.
• Aftal på forhånd, hvad der sker med hosting og konti, hvis du nogensinde skifter leverandør.

Fejl 7: At behandle lanceringen som målstregen

Softwaren er leveret, den virker, alle er lettede. Projektet erklæres færdigt. Et halvt år senere er halvdelen af teamet stille gledet tilbage til det gamle regneark, og det dyre nye værktøj bruges af to personer til én ting. Bygget lykkedes. Udbredelsen mislykkedes — og de to er helt forskellige problemer.

Folk modsætter sig ikke nye værktøjer, fordi de er dumme eller stædige. De modsætter sig, fordi den nye måde er ukendt, og den gamle måde stadig virker, sådan da. At overvinde det kræver bevidst indsats, ingen budgetterede med: lidt oplæring, en klar grund til, hvorfor ændringen hjælper dem specifikt, nogen til at svare på de dumme spørgsmål uden at dømme i de første par uger, og en fast beslutning om at pensionere den gamle måde, så der ikke er noget tilbagefald at glide ned i.

1. 1
   Lancér til en lille gruppe først

   Rul værktøjet ud til nogle få villige personer før hele teamet. De finder de ru kanter og bliver dine interne fortalere.
2. 2
   Vis den personlige gevinst, ikke virksomhedsgevinsten

   “Det her sparer virksomheden penge” motiverer ingen. “Det her betyder, at du holder op med at taste adresser to gange” får folk med.
3. 3
   Udpeg en go-to-person til spørgsmål

   Den første måned ejer nogen de dumme spørgsmål. Friktion i uge ét er, hvad der dræber udbredelsen for altid.
4. 4
   Sluk faktisk for den gamle måde

   Så længe det gamle regneark findes, vil folk blive ved med at bruge det. Når det nye virker, så pensionér tilbagefaldet — blidt men tydeligt.

Sat sammen: en købers tankegang

Læs de syv igen, og en enkelt tråd løber gennem dem. Næsten ingen er tekniske. De handler om klarhed, ejerskab og tilbageholdenhed — at kende sit problem, før man handler, at bygge i små skridt, at bedømme leverandører på forståelse frem for pris, at planlægge for værktøjets levetid og ikke kun dets fødsel, at forblive involveret, at beskytte sin udvej og at behandle lanceringen som starten på det rigtige arbejde.

Skræddersyet software er virkelig en af de bedste investeringer, en lille virksomhed kan foretage, når den først er vokset fra de standardværktøjer, alle deler. Et system formet præcis efter, hvordan du arbejder, frem for at tvinge din forretning til at vride sig om en andens produkt, er en reel og varig fordel. De virksomheder, der når dertil, er ikke dem med de største budgetter. Det er dem, der undgik de syv fejl ovenfor — og det er et spørgsmål om dømmekraft, ikke penge.

Almindelige spørgsmål