Byg eller køb: Beslutningen om projektstyringsværktøjer i AI-æraen
Køb som udgangspunkt: De fleste ledere foretrækker at købe løsninger, medmindre specifikke problemer i arbejdsgangene kræver udvikling af et skræddersyet værktøj.
Det centrale spørgsmål: Afgør, om en arbejdsgang er afgørende for differentiering eller blot grundlæggende infrastruktur, for at kunne træffe beslutningen om at købe eller bygge.
Nødvendigheden af at bygge: Virksomheder kan være nødt til at bygge løsninger, når der ikke findes passende standardløsninger til unikke arbejdsgange.
Vibekodningens indvirkning: AI-assisterede værktøjer som vibekodning sænker tærsklen for, at ikke-ingeniører hurtigt kan skabe funktionel software.
Skjulte omkostninger: Udvikling af skræddersyet software kan føre til langsigtede vedligeholdelsesudfordringer, hvilket ofte gør køb til den sikrere løsning.
For projekt- og driftsledere er der få beslutninger, der har større langsigtede konsekvenser end spørgsmålet om, hvorvidt man skal udvikle et proprietært værktøj eller købe en standardløsning. Gør I det rigtigt, har jeres team præcis den infrastruktur, det har brug for, så det kan arbejde hurtigt og forblive afstemt.
Gør I det forkert, er I enten låst fast i en oppustet SaaS-stak, der ikke passer til jeres arbejdsgange, eller begravet under vedligeholdelsesbyrden ved et egenudviklet system, som ingen længere har fuldt overblik over. Spørgsmålet har altid været vanskeligt. Nu, hvor “vibecoding” gør det nemmere end nogensinde for ikke-ingeniører at skabe funktionel software, er det blevet mere komplekst – og mere interessant.
Det naturlige udgangspunkt: Køb, medmindre du har en grund til at lade være
De fleste erfarne driftsledere vil fortælle dig, at køb bør være standardpositionen, og at udvikling kun bør komme på tale, når der er en klar og specifik grund. Philip Stoelman, grundlægger og administrerende direktør for Network Republic, siger det ligeud: "Vi tager som udgangspunkt udgangspunkt i at købe, medmindre vi støder på et problem i arbejdsgangen, som intet eksisterende værktøj kan løse uden en masse kompromiser. Det er det ærlige udgangspunkt, og jeg tror, at de fleste driftsledere, der har arbejdet med dette længe nok, ender der før eller siden."
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 tager som udgangspunkt udgangspunkt i at købe, medmindre vi støder på et problem i arbejdsgangen, som intet eksisterende værktøj kan løse uden en masse kompromiser.
Logikken er enkel. Standardværktøjer leveres med support, dokumentation, løbende opdateringer og en brugerbase, der allerede har stresstestet produktet. Udvikling kræver derimod løbende investeringer i udvikling, vedligeholdelse og organisatorisk viden. Abdullah Shoaib, administrerende direktør og grundlægger af Energy Solutions, beskriver det sådan: "Vi køber typisk, når en løsning imødekommer et almindeligt forretningsbehov og kan implementeres hurtigt. Vi overvejer kun at udvikle, når processen er en konkurrencefordel, eller når eksisterende værktøjer kræver for mange omveje, der skaber ineffektivitet."
Vi køber typisk, når en løsning imødekommer et almindeligt forretningsbehov og kan implementeres hurtigt. Vi overvejer kun at udvikle, når processen er en konkurrencefordel, eller når eksisterende værktøjer kræver for mange omveje.
Det centrale spørgsmål: Differentiering eller infrastruktur?
Hvis køb er standardvalget, hvad tipper så vægtskålen til fordel for udvikling? For de fleste ledere kan svaret koges ned til ét diagnostisk spørgsmål: Adskiller denne arbejdsgang vores virksomhed fra andre, eller er den blot infrastruktur?
Lizelle Balanco, leder af forretningssystemer hos Cloudflare, beskriver det filter, hendes team anvender: "Vores første spørgsmål er altid: Er det noget, der adskiller vores virksomhed fra andre, eller er det blot noget, vi har brug for for at drive virksomheden? Hvis det er en unik arbejdsgang, en konkurrencefordel eller en proces, som eksisterende løsninger ikke håndterer godt, bliver udvikling en seriøs overvejelse."
Vores første spørgsmål er altid: Er det noget, der adskiller vores virksomhed fra andre, eller er det blot noget, vi har brug for for at drive virksomheden?
Ciaran Burke, COO og medstifter af Swoop Funding, bruger en lignende todeling: "Vi starter med en enkel test: Er denne funktion central for den måde, vi differentierer os på, eller er den blot grundlæggende infrastruktur? Alt, der er knyttet til vores matchningsmotor, långiverarbejdsgange eller proprietære data, udvikler vi selv; alt, der er standard – CRM, sagsstyring, BI, kommunikation – køber vi."
Vi starter med en enkel test: Er denne funktion central for den måde, vi differentierer os på, eller er den blot grundlæggende infrastruktur?
Mønstret blandt lederne er ensartet: Standardfunktioner hører hjemme i standardværktøjer. Proprietære arbejdsgange – dem, der afspejler, hvordan jeres virksomhed faktisk tænker og arbejder – er dem, det kan betale sig at udvikle selv.
Når kløften er for stor til at ignorere: At bygge af nødvendighed
Nogle gange er beslutningen om at bygge snarere et praktisk end et strategisk valg. Det rigtige værktøj findes ganske enkelt ikke, og ingen mængde konfiguration kan få et standardprodukt til at gøre det, der skal gøres.
Dixie Willard, grundlægger og chefprojektstrateg hos Poised & Plumb, nåede frem til denne erkendelse, da hun arbejdede i interiørdesignbranchen. Da hun blev spurgt, om et standardværktøj kunne løse hendes behov, var hendes svar kontant: "Der findes ikke noget. Der findes bare ikke noget. Og der er mange værktøjer, som designere kunne bruge, men som ganske enkelt ikke findes.” Efterfølgende har Dixie arbejdet på forskellige vibecoding-projekter for at imødekomme dette behov.
Der er mange værktøjer, som designere kunne bruge, men som ganske enkelt ikke findes.
Daniel Preston, grundlægger af LiveInCare USA, går mere diagnostisk til spørgsmålet: "Det første spørgsmål, jeg stiller, er, om den proces, vi forsøger at understøtte, faktisk er unik. Hvis processen er almindelig, f.eks. e-mailmarkedsføring, analyse, betalinger eller CRM-funktioner, foretrækker jeg normalt at købe en eksisterende løsning." Konsekvensen er klar — når processen reelt er usædvanlig, holder køb op med at være det rigtige svar.
Aniket Ghonge, seniorleder for forsyningskæden hos Amazon, stødte på denne begrænsning på egen krop, da eksisterende virksomhedsværktøjer ikke kunne følge med hans operationelle behov: "Den nuværende CRM-teknologi, som jeg arbejdede med, havde ikke de funktioner, jeg havde brug for. Jeg havde brug for noget, der kunne hjælpe mig med at automatisere mit arbejde, give mig mulighed for at sammenligne flere kilder og derefter generere en endelig efterspørgselsplan for vores nye afsendere." Ghonge fortsatte med at bygge et system, der løser dette nicheproblem, og reducerede 18 timers arbejde til 1 time.
Når vibecoding ændrer regnestykket
I årevis havde byggesiden af ligningen en betydelig adgangsbarriere: Man havde brug for udviklere, tid og penge. AI-assisterede udviklingsværktøjer — vibecoding-platforme som Replit, Cursor og andre — er begyndt at nedbryde denne barriere på meningsfulde måder. For projektledere og driftsledere uden teknisk baggrund har muligheden for at få et funktionelt værktøj til at eksistere gennem prompter introduceret en helt ny mulighed i beslutningsrammen.
Michael Gold, grundlægger og midlertidig leverancechef, satte for nylig dette på prøve med sit eget CRM: "Jeg byggede netop mit eget CRM ved hjælp af Replit, fordi jeg brugte Close, og det kostede mig 100 dollars om måneden. Jeg vil ikke lyve og sige, at det er bedre end Close, men det er gratis, eller i det mindste koster Replit 25 dollars om måneden." Den afvejning, Gold beskriver — mindre poleret, men markant billigere og tilpasset præcis hans behov — er en, som flere fagfolk begynder at foretage.
Jeg byggede netop mit eget CRM ved hjælp af Replit, fordi jeg brugte Close, og det kostede mig 100 dollars om måneden.
More Articles
De skjulte omkostninger ved at bygge: Et advarende perspektiv
Tilgængeligheden af vibecoding-værktøjer eliminerer ikke risiciene ved at bygge — den sænker blot adgangstærsklen her og nu. De langsigtede omkostninger ved at eje proprietær software består, og erfarne konsulenter, som har set kunder gå denne vej, er hurtige til at fremhæve dem.
Marissa Taffer, grundlægger og bestyrelsesformand for M. Taffer Consulting, har set organisationer bruge store beløb på specialbyggede løsninger, som aldrig burde have forladt tegnebrættet: "Hvis jeg havde været involveret fra begyndelsen, tror jeg, at min anbefaling ville have været at købe noget fra hylden og tilpasse det i stedet for at bygge det, min kunde byggede.” Med udgangspunkt i denne erfaring uddyber Taffer frustrationerne: “Jeg var ofte nødt til at gå gennem administratoren for ligesom at få noget som helst rettet. Værktøjet blev ikke vedligeholdt særlig godt." Det vedligeholdelsesproblem, Taffer beskriver — værktøjer, der langsomt forfalder, fordi ingen har fået de rette ressourcer til at holde dem sunde — er en af de mest almindelige fejltilstande i egenudviklet software.
Hvis jeg havde været involveret helt fra starten, tror jeg, min anbefaling ville have været at købe noget standardiseret og tilpasse det i stedet for at bygge det, min klient byggede.
Loftet for vibekodning: Når prototyper bliver til produkter
Der er en vigtig grænse, som vibekodningens fremmarch har gjort det mere presserende end nogensinde at definere: grænsen mellem en prototype og et produktionssystem. Et værktøj, der bygges på en eftermiddag for at validere en idé, er én ting. Et værktøj, som et team på tyve personer er afhængigt af hver dag, er noget helt andet — og vejen fra det ene til det andet kræver mere end blot at give instruktioner.
Tim Fisher, VP for AI hos The Digital Project Manager, trækker denne grænse tydeligt op: "Hvis du bygger noget, som folk er afhængige af, skal det blive til mere end blot et vibekodet projekt; det skal overtages af de mennesker, der arbejder professionelt med dette og ved ting, som du ikke engang ved, at du skal spørge om. Værdien af disse værktøjer for ikke-kodere er, at de kan give genveje til ting som at skabe enighed om en idé og komme forbi fasen 'kommer det her til at fungere?'"
Hvis du bygger noget, som folk er afhængige af, skal det blive til mere end blot et vibekodet projekt; det skal overtages af de mennesker, der arbejder professionelt med dette og ved ting, som du ikke engang ved, at du skal spørge om.
Fishers formulering er generøs over for vibekodning — den er oprigtigt værdifuld, når det handler om at mindske afstanden mellem idé og konceptafprøvning — men samtidig klarøjet omkring dens begrænsninger. Prototypen er begyndelsen på samtalen om, hvorvidt man skal bygge, ikke selve byggeriet.
Vil du have flere indsigter som disse? Tilmeld dig en gratis DPM-konto for at høre fra flere eksperter som disse.
