7 feil små bedrifter gjør når de kjøper skreddersydd programvare

De fleste små bedrifter som brenner seg på et prosjekt med skreddersydd programvare, brenner seg ikke på dårlige programmerere. De brenner seg uker før noen programmering i det hele tatt er begynt — på et oppstartsmøte, i en e-posttråd, ved et håndtrykk — på en beslutning som føltes liten der og da. Når koden endelig kommer, er feilen allerede bakt inn. Den gode nyheten er at disse feilene er kjedelig gjentakende, noe som betyr at de kan unngås hvis man vet hvordan de ser ut.

Jeg har sett mange av disse prosjektene innenfra, fra begge sider av bordet. Noen ble til verktøy en bedrift ikke kan tenke seg å jobbe uten. Andre ble til en halvferdig innloggingsskjerm, en anspent fakturatvist og en gründer som sverger på aldri å gå skreddersydd igjen. Det frustrerende er hvor lite som skilte de to utfallene. Teknologien var sjelden problemet. Beslutningene rundt teknologien var det nesten alltid.

Så her er de sju feilene jeg ser igjen og igjen når en liten bedrift bestiller skreddersydd programvare. Ingen av dem krever teknisk bakgrunn for å unngå. De krever bare at du vet at de finnes før du signerer noe.

Feil 1: Å kjøpe en løsning før du forstår problemet

Den dyreste feilen skjer først, og den høres harmløs ut: «Vi trenger en app som gjør X.» Når noen sier det høyt, har de som regel allerede bestemt løsningens form — et dashbord, en portal, en mobilapp — uten at noen har skrevet ned det faktiske problemet i klartekst. Byggingen leverer da trofast feil ting, vakkert utført.

God programvare starter fra en problemformulering, ikke en funksjonsliste. «Kontorteamet vårt taster om hver ordre fra e-post inn i regnskapssystemet, og det tar to personer en halv dag» er et problem. «Vi trenger et skreddersydd CRM» er en gjetning på en løsning til et problem ingen gadd å navngi. Det første kan løses billig og måles. Det andre er en åpen invitasjon til å bruke penger.

Feil 2: Å prøve å bygge alt på én gang

Skreddersydd programvare føles som et kjøp man gjør én gang i tiåret, så folk prøver å presse et tiårs ønsker inn i versjon én. Hver avdeling legger til en forespørsel. Hvert «mens vi først holder på» får et ja. Omfanget vokser, tidsplanen tredobles, og prosjektet kollapser under sin egen ambisjon lenge før noen får tatt det i bruk.

Bedriftene som lykkes gjør det motsatte. De velger den enkelt mest smertefulle biten av problemet og bygger den først — en ekte, fungerende ting i produksjon innen et par måneder. Så lar de den faktiske bruken fortelle dem hva som kommer videre. Dette er ikke bare billigere; det er tryggere. Du lærer om idéen fungerer mens innsatsen fortsatt er liten, i stedet for å oppdage etter et halvt år og en stor faktura at du designet feil ting.

Under dette ligger en hard sannhet: du vet faktisk ikke hva du trenger ennå. Det gjør ingen, i begynnelsen. Forståelsen din av problemet vil endre seg i det øyeblikket ekte mennesker tar på et ekte verktøy. Å bygge alt på forhånd låser fast dine tidligste, minst informerte gjetninger. Å bygge i biter holder deg fleksibel — og holder budsjettet under kontroll mens du fortsatt lærer.

Feil 3: Å velge utelukkende på pris

Du får tre tilbud. Ett er dramatisk billigere enn de andre. Lettelse — du tar det. Dette er en av de mest pålitelige måtene å gjøre et lite prosjekt dyrt på, for det billige tilbudet betyr nesten aldri at arbeidet er billigere. Det betyr som regel at de to sidene forsto oppgaven forskjellig.

Et lavt tall signaliserer ofte én av noen få ting: leverandøren undervurderte omfanget fordi de ikke stilte nok spørsmål, de planlegger å tjene marginen sin på endringsforespørsler senere, eller de er uerfarne og vet ennå ikke hva de ikke vet. Ingen av delene ender godt for deg. Overskriftsprisen er det minst nyttige tallet i tilbudet. Det som betyr noe, er om leverandøren tydelig forstår problemet ditt, stiller ubehagelige spørsmål og er ærlig om hva som ikke er inkludert.

Feil 4: Å glemme at programvare ikke er et engangskjøp

Skreddersydd programvare blir ofte solgt, og kjøpt, som et møbel: betal én gang, eie det for alltid. Slik er det ikke. Programvare lever i en verden i bevegelse — operativsystemer oppdateres, nettlesere endrer seg, sikkerhetsoppdateringer kommer, virksomheten din skifter, verktøyene du kobler til endrer reglene sine. Et verktøy ingen vedlikeholder slutter sakte å virke, og går så i stykker på det verst tenkelige tidspunktet.

Dette rammer små bedrifter hardt fordi vedlikeholdskostnaden er usynlig ved signering. Du sammenligner to tilbud på byggeprisen og stiller aldri spørsmålet som betyr mer: hva koster det å holde dette levende og friskt hvert år? Hosting, oppdateringer, små rettelser, den enkelte endringen etter hvert som virksomheten utvikler seg — planlegg for det som en normal, løpende post, slik du gjør for forsikring eller regnskap. Det er som regel beskjedent, men bare hvis du regner med det.

Feil 5: Å la kravene være vage og uten eier

«Dere er ekspertene, bare bygg noe bra» høres sjenerøst ut. Det er faktisk slik prosjekter driver av gårde. De som forstår virksomheten din best er dere og teamet ditt — ikke utviklerne. Hvis du leverer en uklar brief og forsvinner, fyller leverandøren hullene med sine beste gjetninger, og du oppdager de gjetningene på det verst tenkelige tidspunktet: ved levering, når det er dyrest å endre dem.

To roller må fylles på din side, og små bedrifter unnlater rutinemessig å fylle noen av dem. Den første er én enkelt beslutningstaker — én person som kan si ja, avgjøre uenigheter mellom avdelinger og ikke er for opptatt til å svare på spørsmål i ukevis. Den andre er viljen til å være spesifikk om delene som betyr noe: grensetilfellene, det rare unntaket virksomheten din alltid har håndtert for hånd, regelen alle kjenner til men ingen har skrevet ned. Det er nøyaktig det programvaren må få rett.

Feil 6: Å ikke spørre hvem som eier koden og dataene

Dette er den stille feilen, og den som gjør mest vondt år senere. Du betaler for skreddersydd programvare, du antar at den er din. Så surner forholdet til leverandøren, eller de hever prisene, eller de bare forsvinner — og du oppdager at du ikke kan flytte deg. Du har ikke kildekoden. Dataene bor i et system bare de har tilgang til. Hele driften din avhenger nå av en bedrift du ikke lenger stoler på, og du har ingen forhandlingskraft.

Ingenting av dette krever en advokat for å forhindre. Det krever tre enkle spørsmål stilt før du starter, mens du fortsatt har all forhandlingsmakten: Hvem eier kildekoden når dette er ferdig? Kan jeg eksportere alle dataene mine, i et brukbart format, når jeg vil? Og hvis vi skiller lag, hva går jeg da nøyaktig derfra med? En seriøs partner svarer på disse uten å blunke. Nøling her er det enkeltstående største varselsignalet i hele prosessen.

• Få det skriftlig at du eier kildekoden, eller har en klar, rettferdig lisens til den.
• Bekreft at du kan eksportere dine egne data i et standardformat, på forespørsel, uten tillatelse.
• Sørg for at arbeidet er dokumentert godt nok til at en annen utvikler kan ta over.
• Unngå proprietær innlåsing der en enkel, velkjent teknologi ville gjort samme jobben.
• Avtal på forhånd hva som skjer med hosting og kontoer hvis du noen gang bytter leverandør.

Feil 7: Å behandle lanseringen som målstreken

Programvaren er levert, den virker, alle er lettet. Prosjektet erklæres ferdig. Et halvt år senere har halve teamet stille glidd tilbake til det gamle regnearket, og det dyre nye verktøyet brukes av to personer til én ting. Byggingen lyktes. Bruken mislyktes — og de to er helt forskjellige problemer.

Folk motsetter seg ikke nye verktøy fordi de er dumme eller sta. De motsetter seg fordi den nye måten er ukjent, og den gamle måten fortsatt virker, sånn passe. Å vinne over det krever bevisst innsats som ingen budsjetterte for: litt opplæring, en klar grunn til hvorfor endringen hjelper dem spesifikt, noen til å svare på de dumme spørsmålene uten å dømme de første ukene, og en fast beslutning om å pensjonere den gamle måten slik at det ikke finnes noe tilbakefall å gli ned i.

1. 1
   Lanser til en liten gruppe først

   Rull verktøyet ut til noen få villige personer før hele teamet. De finner de røffe kantene og blir dine interne forkjempere.
2. 2
   Vis den personlige gevinsten, ikke bedriftsgevinsten

   «Dette sparer bedriften penger» motiverer ingen. «Dette betyr at du slutter å taste adresser to ganger» får folk med.
3. 3
   Utpek en kontaktperson for spørsmål

   Den første måneden eier noen de dumme spørsmålene. Friksjon i uke én er det som dreper bruken for alltid.
4. 4
   Skru faktisk av den gamle måten

   Så lenge det gamle regnearket finnes, vil folk fortsette å bruke det. Når det nye virker, pensjoner tilbakefallet — varsomt, men tydelig.

Å sette det sammen: en kjøpers tankesett

Les de sju på nytt, og en enkelt tråd løper gjennom dem. Nesten ingen er tekniske. De handler om klarhet, eierskap og tilbakeholdenhet — å kjenne problemet sitt før man handler, å bygge i små steg, å vurdere leverandører på forståelse fremfor pris, å planlegge for verktøyets levetid og ikke bare fødselen, å forbli involvert, å beskytte utveien sin og å behandle lanseringen som starten på det virkelige arbeidet.

Skreddersydd programvare er virkelig en av de beste investeringene en liten bedrift kan gjøre når den først har vokst fra standardverktøyene alle deler. Et system formet nøyaktig etter hvordan dere jobber, fremfor å tvinge virksomheten til å vri seg rundt en annens produkt, er en reell og varig fordel. Bedriftene som kommer dit er ikke de med størst budsjetter. Det er de som unngikk de sju feilene over — og det er et spørsmål om dømmekraft, ikke penger.

Vanlige spørsmål