Bygge eller kjøpe: Valget av prosjektstyringsverktøy i KI-alderen
Kjøp som standard: De fleste ledere foretrekker å kjøpe løsninger, med mindre spesifikke utfordringer i arbeidsflyten krever at de bygger et tilpasset verktøy.
Kjernespørsmålet: Finn ut om en arbeidsflyt er avgjørende for differensiering eller utgjør grunnleggende infrastruktur, for å veilede valget mellom å kjøpe og bygge.
Når det er nødvendig å bygge: Bedrifter kan måtte bygge løsninger når det ikke finnes egnede standardløsninger for unike arbeidsflyter.
Vibekodingens betydning: KI-assisterte verktøy som vibekoding senker terskelen for at ikke-utviklere raskt kan lage funksjonell programvare.
Skjulte kostnader: Å bygge tilpasset programvare kan føre til langsiktige vedlikeholdsutfordringer, noe som ofte gjør kjøp til det tryggere alternativet.
For prosjekt- og driftsledere er det få beslutninger som får større langsiktige konsekvenser enn hvorvidt man skal bygge et egenutviklet verktøy eller kjøpe en standardløsning. Gjør dere det riktig, har teamet akkurat den infrastrukturen det trenger for å jobbe raskt og holde seg samkjørt.
Gjør dere det feil, er dere enten låst til en overlesset SaaS-stakk som ikke passer arbeidsflytene deres, eller begravd under vedlikeholdsbyrden til et egenutviklet system som ingen lenger har full oversikt over. Spørsmålet har alltid vært vanskelig. Nå som «vibecoding» gjør det enklere enn noen gang for ikke-ingeniører å sette opp funksjonell programvare, har det blitt mer komplisert – og mer interessant.
Det naturlige utgangspunktet: Kjøp, med mindre du har en grunn til å la være
De fleste erfarne driftsledere vil si at kjøp bør være standardvalget, og at bygging bare bør komme på tale når det finnes en klar og spesifikk grunn. Philip Stoelman, grunnlegger og administrerende direktør i Network Republic, sier det enkelt: «Vi tar utgangspunkt i å kjøpe, med mindre vi støter på et problem i arbeidsflyten som ingen tilgjengelige verktøy kan løse uten mange kompromisser. Det er det ærlige utgangspunktet, og jeg tror de fleste driftsledere som har holdt på lenge nok, ender opp der til slutt.»
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Vi tar utgangspunkt i å kjøpe, med mindre vi støter på et problem i arbeidsflyten som ingen tilgjengelige verktøy kan løse uten mange kompromisser.
Logikken er enkel. Standardverktøy leveres med støtte, dokumentasjon, kontinuerlige oppdateringer og en brukerbase som allerede har stresstestet produktet. Å bygge krever derimot kontinuerlige investeringer i utvikling, vedlikehold og institusjonell kunnskap. Abdullah Shoaib, administrerende direktør og grunnlegger av Energy Solutions, forklarer det slik: «Vi kjøper vanligvis når en løsning dekker et vanlig forretningsbehov og kan tas i bruk raskt. Vi vurderer å bygge bare når prosessen er et konkurransefortrinn, eller når eksisterende verktøy krever for mange omveier som skaper ineffektivitet.»
Vi kjøper vanligvis når en løsning dekker et vanlig forretningsbehov og kan tas i bruk raskt. Vi vurderer å bygge bare når prosessen er et konkurransefortrinn, eller når eksisterende verktøy krever for mange omveier.
Kjernespørsmålet: Konkurransefortrinn eller infrastruktur?
Hvis kjøp er standardvalget, hva vipper balansen i retning av bygging? For de fleste ledere handler svaret om ett enkelt diagnostisk spørsmål: Skiller denne arbeidsflyten virksomheten vår fra konkurrentene, eller er den bare infrastruktur?
Lizelle Balanco, leder for forretningssystemer i Cloudflare, beskriver filteret teamet hennes bruker: «Det første spørsmålet vårt er alltid: Er dette noe som skiller virksomheten vår fra konkurrentene, eller er det ganske enkelt noe vi trenger for å drive virksomheten? Hvis det er en unik arbeidsflyt, et konkurransefortrinn eller en prosess som eksisterende løsninger ikke håndterer godt, blir bygging en seriøs vurdering.»
Det første spørsmålet vårt er alltid: Er dette noe som skiller virksomheten vår fra konkurrentene, eller er det ganske enkelt noe vi trenger for å drive virksomheten?
Ciaran Burke, driftsdirektør og medgründer av Swoop Funding, bruker en lignende todeling: «Vi begynner med en enkel test: Er denne funksjonen sentral for hvordan vi skiller oss fra konkurrentene, eller er den grunnleggende infrastruktur? Alt som er knyttet til matchingsmotoren, långiverarbeidsflyter eller proprietære data, bygger vi selv; alt som er standardvare – CRM, supportsaksbehandling, BI, kommunikasjon – kjøper vi.»
Vi begynner med en enkel test: Er denne funksjonen sentral for hvordan vi skiller oss fra konkurrentene, eller er den grunnleggende infrastruktur?
Mønsteret blant lederne er tydelig: Standardfunksjoner hører hjemme i standardverktøy. Proprietære arbeidsflyter – de som gjenspeiler hvordan virksomheten faktisk tenker og arbeider – er det verdt å bygge selv.
Når gapet blir for stort til å ignoreres: Å bygge av nødvendighet
Noen ganger handler beslutningen om å bygge ikke så mye om et strategisk valg som om et praktisk valg. Det riktige verktøyet finnes ganske enkelt ikke, og ingen mengde konfigurering vil få et standardprodukt til å gjøre det som må gjøres.
Dixie Willard, grunnlegger og sjefstrateg for prosjekter i Poised & Plumb, kom til denne erkjennelsen da hun jobbet i interiørdesignbransjen. Da hun ble spurt om et standardverktøy kunne løse behovene hennes, var svaret kontant: «Det finnes ikke. Det finnes bare ikke. Og det finnes mange verktøy som designere kunne ha brukt, men som ganske enkelt ikke eksisterer.» Deretter har Dixie jobbet med ulike vibekodede prosjekter for å dekke dette behovet.
Det finnes mange verktøy som designere kunne ha brukt, men som ganske enkelt ikke eksisterer.
Daniel Preston, grunnlegger av LiveInCare USA, nærmer seg spørsmålet mer diagnostisk: «Det første spørsmålet jeg stiller, er om prosessen vi prøver å støtte, faktisk er unik. Hvis prosessen er vanlig, som e-postmarkedsføring, analyse, betalinger eller CRM-funksjoner, foretrekker jeg vanligvis å kjøpe en eksisterende løsning.» Implikasjonen er tydelig – når prosessen faktisk er uvanlig, slutter det å være riktig svar å kjøpe.
Aniket Ghonge, senior forsyningskjedesjef hos Amazon, møtte denne begrensningen på nært hold da eksisterende virksomhetsverktøy ikke klarte å holde tritt med de operative behovene hans: «Den nåværende CRM-teknologien jeg jobbet med, hadde ikke funksjonene jeg trengte. Jeg trengte noe som kunne hjelpe meg med å automatisere arbeidet mitt, gi meg en måte å sammenligne flere kilder på og deretter generere en endelig etterspørselsplan for våre nye avsendere.» Ghonge fortsatte med å bygge et system som løser dette nisjeproblemet, og reduserte 18 timers arbeid til 1 time.
Når vibekoding endrer regnestykket
I årevis hadde byggesiden av ligningen en betydelig inngangsbarriere: Du trengte utviklere, tid og penger. AI-assisterte utviklingsverktøy – vibekodingsplattformer som Replit, Cursor og andre – har begynt å redusere denne barrieren på meningsfulle måter. For prosjektledere og driftsledere uten teknisk bakgrunn har muligheten til å få et funksjonelt verktøy til å eksistere ved hjelp av instruksjoner introdusert et helt nytt alternativ i beslutningsrammeverket.
Michael Gold, grunnlegger og fraksjonert leveranseleder, satte nylig dette på prøve med sitt eget CRM: «Jeg bygget nettopp mitt eget CRM ved hjelp av Replit fordi jeg brukte Close, og det kostet meg 100 dollar i måneden. Jeg skal ikke lyve og si at det er bedre enn Close, men det er gratis, eller i det minste koster Replit 25 dollar i måneden.» Avveiningen Gold beskriver – mindre polert, men betydelig billigere og tilpasset akkurat behovene hans – er en avveining stadig flere fagfolk begynner å gjøre.
Jeg bygget nettopp mitt eget CRM ved hjelp av Replit fordi jeg brukte Close, og det kostet meg 100 dollar i måneden.
De skjulte kostnadene ved å bygge: Et advarende perspektiv
Tilgjengeligheten av vibekodingsverktøy eliminerer ikke risikoen ved å bygge – den senker bare terskelen i startfasen. De langsiktige kostnadene ved å eie proprietær programvare består, og erfarne konsulenter som har sett kunder gå denne veien, er raske til å påpeke dem.
Marissa Taffer, grunnlegger og president i M. Taffer Consulting, har sett organisasjoner bruke store summer på spesialbygde løsninger som aldri burde ha forlatt tegnebrettet: «Hvis jeg hadde vært involvert fra starten av, tror jeg anbefalingen min ville ha vært å kjøpe noe hyllevare og tilpasse det, i stedet for å bygge det kunden min bygget.» Når Taffer reflekterer over denne erfaringen, utdyper hun frustrasjonene: «Jeg måtte ofte gå gjennom administratoren for å få noe som helst fikset. Verktøyet ble ikke særlig godt vedlikeholdt.» Vedlikeholdsproblemet Taffer beskriver – verktøy som gradvis forfaller fordi ingen har fått tilstrekkelige ressurser til å holde dem i god stand – er en av de vanligste feilmåtene i egenutviklet programvare.
Hvis jeg hadde vært involvert helt fra starten, tror jeg anbefalingen min ville ha vært å kjøpe noe ferdig og tilpasse det i stedet for å bygge det klienten min bygde.
Vibekodingens tak: Når prototyper blir produkter
Det finnes en viktig grense som fremveksten av vibekoding har gjort det presserende å definere på nytt: grensen mellom en prototype og et produksjonssystem. Et verktøy som bygges på en ettermiddag for å validere en idé, er én ting. Et verktøy som et team på tjue personer er avhengig av hver dag, er noe helt annet – og veien fra det ene til det andre krever mer enn gode instruksjoner.
Tim Fisher, visepresident for AI i The Digital Project Manager, trekker denne grensen tydelig: «Hvis du bygger noe folk er avhengige av, må det bli mer enn bare et vibekodet prosjekt; det må overtas av folk som jobber profesjonelt med dette, og som kjenner til ting du ikke engang vet at du bør spørre om. Verdien av disse verktøyene for ikke-kodere er at de kan korte ned prosesser som å skape enighet rundt en idé, og komme forbi fasen der man spør seg: «Kommer dette til å fungere?»»
Hvis du bygger noe folk er avhengige av, må det bli mer enn bare et vibekodet prosjekt; det må overtas av folk som jobber profesjonelt med dette, og som kjenner til ting du ikke engang vet at du bør spørre om.
Fishers fremstilling er generøs overfor vibekoding – det er virkelig verdifullt for å redusere avstanden mellom idé og konseptbevis – men samtidig realistisk når det gjelder begrensningene. Prototypen er begynnelsen på samtalen om hvorvidt man skal bygge, ikke selve byggingen.
Vil du ha flere innsikter som dette? Registrer deg for en gratis DPM-konto for å høre fra flere eksperter som disse.
