Build or buy?

Bør man bygge sine egne digitale løsninger eller betale sig fra det? Skal man være first mover, der løber den store risiko, men får det, som man vil have det. Eller skal man være smart second mover, som accepterer en testet men generisk løsning? Build or buy diskussionen er central for enhver virksomhed i den digitale transformation, og den ophører nok aldrig. Men måske findes der et kompromis? Vi ser nærmere på, man skal være opmærksom på, når man er på udkig efter nye legaltech-løsninger.

Build or buy dilemmaet er hverken nyt eller begrænset til advokatbranchen. Tværtimod er det del af en gammel strid mellem to forskellige forretningsstrategier. På den ene side er der fortalerne for outsourcing og et stramt fokus på kerneopgaver. På den anden er der dem, som mener, at en virksomhed skal være så selvkørende og uafhængig som muligt.

I løbet af de senere år har tendensen været at frasælge og udlicitere alt, som ikke direkte er en virksomheds kerneopgave. I Bain & Companys feterede rapport The Firm of the Future beskriver de eksempelvis, at outsourcing kan gøre en virksomhed mere fleksibel og agil i verden, som kræver ekstrem omstillingsparathed. Når vi så alligevel har en diskussion, skyldes det, at der også er glimrende argumenter for selv at udvikle sine legal tech-løsninger, hvis man har råd. Derfor har Kammeradvokaten eksempelvis kunne præsentere 11 selvudviklede legaltech-løsninger.

‍
DIY-legaltech

Hovedargumentet for at bygge sine egne teknologier er, at man kan skræddersy dem til sin forretning. Man kan lave et produkt, der er tilpasset det konkrete setup og kun betale for de funktioner, man har brug for. Man har så at sige magt over produktet og kan konstant levere input til programmørerne, hvormed man sørger for, at teknologiens funktioner udvikles efter ens egne ønsker.

Derudover kan man differentiere sig fra konkurrenterne ved at udvikle eksklusive løsninger. Lykkes det at skabe en legal-tech løsning, der er bedre end standarden, vil man have vundet en væsentlig fordel over ens konkurrenter. Det gælder både interne løsninger, som øger produktiviteten eller eksterne løsninger, der bevirker, at klienterne bliver mere loyale mod ens rådgivning.

Af og til vil man desuden erfare, at det produkt man efterspørger, endnu ikke findes på markedet. Der giver det sig selv, at man ikke har andet valg end at udvikle det selv.

‍

Køb eller forsvind! 

Skomager bliv ved din læst! Advokater er hverken programmører og designere, og det bliver de heller ikke. Vi skal ikke hænge nogen ud, men der mangler ikke eksempler på advokatselskaber, som har brugt millioner på at udvikle et nyt digitalt produkt og skrevet en flot pressemeddelse, hvorefter det så aldrig brugt det igen, fordi det er upraktisk, fejlbehæftet og dårligt designet.

At bygge et godt digitalt produkt kræver ikke kun indsigt i egen praksis. Det kræver viden om æstetik, adfærdsdesign, IT-sikkerhed og en masse andet, som advokater ikke aner noget som helst om. Derfor er det typisk en bedre idé at lade andre definere, hvad der er bedste praksis. Ofte er de mest succesfulde digitale produkter dem, der ikke lyttede til forbrugernes ønsker, men i stedet formede et produkt, forbrugerne ikke havde forestillingsevne til at vide, at de manglede. Jævnfør eksempelvis den klassiske historie om Nokia vs. Apple.

Dertil kommer, at det er både dyrt og tidskrævende at udvikle software. Ifølge en rapport fra Mckinsey går 45 % af alle softwares over budget, 7 % overskrider tidsplanen og 56 % af produkterne levere mindre værdi end forudset. Det er ikke bare dyrt at investere i noget, man ikke ved, om vil genere værdi. Det er også dyrt at vedligeholde det. Et digitalt produkt er ligesom et fysisk produkt noget, som kan forfalde og forældes. Derfor kræver det konstant arbejde at facilitere.

Mange af de store og traditionelle systemer, kan også være dyre og besværlige at implementere, fordi det kræver store on-boarding fees og ofte omfatter lange opsigelsesperioder. Der er dog tendens til, at flere løsninger fungerer efter en moderne SaaS-model. Her vil man typisk betale et fast beløb i abonnement per måned, hvormed udgifterne vil være forudsete, kontrollerbare og nemme at skalere efter faktisk brug. SaaS-modellen har vundet frem de senere år, netop på grund af dens fleksibilitet og pålidelighed. Man behøver ikke at investere det store for at teste produktet, og man slipper man for at vedligeholde softwaren og udvikle nye features.

I dag går der konstant kortere tid mellem, at digitale produkt bliver uddateret; enten på grund af nye teknologier eller fordi konkurrerende softwares forbedrer sig. Det taler yderligere for SaaS-modellen. Læs denne blog for en udvidet argumentation.

Build or buy or...

‍Tidligere på året konstaterede Law360 ganske rigtigt konstaterede, at buy or build ikke udgør de eneste to valgmuligheder, for der er naturligvis kompromisløsninger. Man kan bygge sit eget værktøj som en udvidelse af et eksisterende, eller man kan investere i et selvstændigt tech-firma til at udvikle de produkter, man efterspørger.

Et samarbejde mellem den juridiske branche og de digitale udbydere er klart at foretrække. I de senere år har tech-industrien haft succes med en model, hvor man producerer prototyper og beta-versioner, inden man lancerer det færdige produkt. Dermed kan man indsamle feedback og finde svage såvel som stærke punkter. Ved et samarbejde vil advokater og jurister netop kunne være en evalueringsgruppe, som kan kalibrere det arbejde, tech-leverandørerne udvikler.  

Tech-industrien er selv ved at blive mere fleksibel. Der er flere legaltech, som tilbyder white label-løsninger, hvor man kan benytte sig eget brand og ændre detaljer, så man kan tilpasse et ellers generisk produkt. Dagene hvor store leverandører leverer store systemer til flere millioner og skyhøje ekstra fees, er ovre. Den kunde-centriske bevægelse vil nemlig også kræve, at tech-firmarne selv levere bedre kundeoplysninger og mere fleksibilitet.

Man gør desuden klogt i at vælge legaltech-værktøjer, som tilbyder API-løsninger, hvormed man typisk kan lave et sammensat produkt. En API (application program interface) er en grænseflade mellem to programmer, som tillader dem at interagere og udveksle data. På den måde kan man enten udvikle sin en mindre software, der kan samarbejde med en større software - eller man kan forbinde to softwares for at lave et setup, der skræddersyet specifikt til ens arbejdsgang og dermed kan bruges til differentiere sig fra konkurrenterne. API-implementeringen bliver hele tiden mere effektiv, eksempelvis med et produkt som Zapier, der strømliner integrationen mellem forskellige softwares og har mere end 7000 forskellige programmer i porteføljen.

Det kan altså være en god idé at undersøge, om et digitalt produkt har nemt ved at kommunikere og samarbejde med andre produkter. Dermed gør man sig tilmed også klar til en tid med kunstig intelligens og maskinlæring, der kræver, at man har et strømlinet dataflow.