Det evige spørsmålet om du skal kjøpe eller bygge programvaren din (James Monaghan)

Gratulerer. Du har et problem, et prosjekt, et budsjett og en deadline. I stedet for å kaste kropper på det, er programvare løsningen, men nå må du bestemme deg for å bygge eller kjøpe, det er spørsmålet. Eller er det? Jeg er ikke så sikker på at det er en klar avgjørelse lenger.
Bygg bruk for å referere til å ansette interne programmerere for å kode det systemet som var nødvendig og kjøpe referert til hyllevareprodukter som kan kjøpes og kjøres. Dette var fornuftig når vi snakket om regnskapssystemer, handelssystemer, CRM, rapportering,
Utlån, Samlinger, CLM osv. Vi lever nå i lavkodemiljøet der det å bygge noe ikke krever erfaring med koding. Det kan være dra og slipp. Kombiner det med å kjøpe hylleløsninger som ender opp med å bli så tilpasset at du kanskje som
vel har bygget den. Så hvor gjør det at vi kan ta avgjørelsen om å bygge eller kjøpe? La oss se på hva vi faktisk trenger.

Ingen moderne system kan stole på ett enkelt inngangspunkt lenger. Kundens forventninger tilsier at ulike kanaler er nødvendige. Personlig, over telefon direkte eller telefonsenter, e-post, sosiale medier, SMS, web, mobil, nettbrett – både mobilaktivert og native
apper, alle med behovet for å være utskiftbare uten å miste innhold eller kontekst. En kunde som starter i filial/butikk eller personlig, men må reise for en avtale, ønsker å kunne fortsette der de slapp når de logger på senere samme dag på nett. Eller
hvis de starter på nett, men blir frustrerte og ringer inn for å få hjelp, vil de ikke måtte starte prosessen fra begynnelsen. Dette gjelder også interne interessenter. Informasjonskjeden i en organisasjon må være like fleksibel som kunden står overfor
alternativer. 

Så hva neste for vår start hvor som helst datainndata? Vel, det er en grunn til at vi trenger disse dataene i utgangspunktet. Enten en ny kunde ønsker å jobbe med organisasjonen, en eksisterende kunde ønsker et nytt produkt eller tjeneste, eller til og med bare hverdagslige spørsmål, klager
eller informasjonsforespørsler. Alle disse bør starte definerte, men fleksible prosesser for å fullføre forespørselen så effektivt og enkelt som mulig. Prosessen er generelt definert og vanligvis er personalet opplært til å følge en sekvens av oppgaver for å fullføre den med forhåndsbestemt
handlinger basert på visse datainndata. 

Verken sluttkunder eller systembrukere skal måtte taste inn informasjon på nytt noe sted hvis den allerede er fanget opp et sted. Faktisk, hvis informasjon er tilgjengelig hvor som helst i organisasjonen eller fra tredjepartskilder som dataleverandører, kredittbyråer,
screeningleverandører osv. bør være tilgjengelig gjennom hele prosessen for alle brukere som trenger det. Prosessen er definert, men kontaktpunktene bør være utskiftbare hele veien, og data som samles inn bør integreres der det er mulig og struktureres der det er tillatt.
Rullegardinmenyer, oppslagsverdier, datofelt og kontrollerte fritekstverdier for å sikre mest mulig datakvalitet på forhånd. Dette gir mye mer automatisering gjennom hele prosessen og mindre unntakshåndtering.

Nå som data er i ferd med å bli aktivt fanget eller oppdatert, kan den kunstige intelligensen brukes. Personalet trenger ikke å vite alle detaljene, og enda nyere medlemmer kan jobbe med mer komplekse saker fordi systemet bruker policykodede regler
logikk for automatisk å ta beslutninger som personalet tidligere måtte ha omfattende opplæring og erfaring for å håndtere. Ikke flere feil samtidig som det tillater overvåking og til og med kvalitetskontroller eller direkte unntakskøer for manuell intervensjon om nødvendig.

Alt dette krever en systematisk tilnærming. Den gamle ideen om en manilla-mappe som ligger i en medarbeiderskuff for kundeporteføljen deres er utdatert og skaper en unødvendig risiko. Klienter som behandles isolert kan være både begrensende og overflødige
samtidig. Hvis en bedriftskunde har direktører som sitter på tvers av flere andre kunder, hvorfor skulle hver enkelt anmeldelse ignorere det større bildet. Kommer du også til å anmelde den samme regissøren flere ganger på tvers av hvert forhold eller kan du
gjøre det én gang og gjenbruke den informasjonen på tvers av organisasjonen?

De trenger ikke engang å ha vanlige nærstående parter for at fordelen skal være åpenbar. Lignende bransjer, lignende klientkunder, hva om dine klientleverandører/leverandører også er klienter selv? Dette bringer oss til hvordan du trenger å behandle informasjonen
og hvorfor organisasjoner trenger å se på tvers av bedriften når de vurderer programvare i disse dager. Hvis du ser på et problem isolert og behandler det som sådan, ved å etablere budsjetter og utstede RFPer for hver CRM-, Fincrime-, Client Outreach-komponent, vil du ende opp med
med å bruke mer ressurser på å prøve å integrere alt sammen enn noen potensiell besparelse man i utgangspunktet håpet på. Bruk det nå for hver region eller bransje som kan få separate budsjetter og tilsyn, og du vil ende opp med 8 versjoner
av den samme programvaren som må integreres med seg selv på grunn av tung tilpasning per område som eliminerer eventuelle stordriftsfordeler de kan oppnå.

En mappe i en skuff som må gjennomgås årlig eller på annen måte, med ansatte som trenger å få opplæring i hva de skal gjøre og når de skal gjøre det. Hele anmeldelsen (eller ny onboarding/tilleggsprodukt/tjeneste/osv) kan brytes ned i sammensatte deler som kan eller
kan ikke håndteres av andre personer/lag. Systemet kan deretter bestemme når en oppgave er fullført eller når nok data er fanget til å sendes til neste person for deres input. Alle disse er strukturert som saker og undersaker innenfor. På denne måten hvert element av
saken kan ha egen frist, opptrappingsvei, oppdragstaker og godkjennere. I stedet for én stor oppgave som en medarbeider trenger å være erfaren nok til å vite hvordan han skal fullføre og hvem man skal gå til for ulike elementer innenfor, tildeler systemet nå arbeidet
og sikrer rettidig gjennomføring på tvers av hele selskapet med så mange oppgaver automatisert som mulig for å frigjøre beslutningstakerne til å fokusere på det som er viktig.

Dette er vel og bra fra et forretningsmessig ståsted. Arbeidet er kjent og hva som må gjøres. Men når vi prøver å bestemme om vi skal kjøpe eller bygge programvaren selv, hvordan påvirker det ting? Vel, la oss anta at det er flere kilder
av data på tvers av flere systemer. Ethvert moderne system forventes å være API-drevet og ha lav kode/ingen kodefunksjoner. En rimelig antagelse for raskere og fleksibel programvare. Alt i disse dager må behandles som en slags mikrotjeneste for å unngå
programvaremonolittene i gammel stil. Programvare bør installeres og brukes fordi den er den beste tilgjengelige og fremtidssikret for å tilpasse seg endringer etter behov. For mange tilbud er forankret og bare vedlikeholdt fordi de er for vanskelige og tidkrevende
å erstatte. Mesteparten av dette er fordi regler er hardkodet, sannsynligvis sammenvevd med selve dataene, data blir ikke bare integrert, men replikert flere ganger for hvert separat stykke programvare i informasjonskjeden, og hvis du prøver å erstatte en del,
hele systemet kan gå i stykker. For mye av den gamle tankeprosessen, hvis den ikke er ødelagt, så ikke fiks den. Det som virkelig trengs er at alle disse komponentdelene skal være mikrotjenester, ta data som trengs, bruke automatiserte regler eller brukerinndata/anmeldelser og
sender den videre til neste mikrotjeneste. Data bør ikke lagres på mer enn ett sted. Det kan være forent, men ikke replikert utenfor sikkerhetskopier. Systemene dine for CRM, Onboarding, KYC, Client Outreach osv. skal bare få tilgang til dataene de trenger og ikke
være datalagre selv med mindre du har valgt en å være. Å replikere de samme dataene på tvers av flere lokasjoner og reglene som styrer det er en øvelse i nytteløshet ettersom hvert ekstra system som legges til vil multiplisere kompleksiteten involvert.

Dette bringer oss til den endelige vurderingen. Enten du har en enkelt kilde til sannhet/Golden Copy eller flere overflødige og konkurrerende poster og systemer som kan oppdatere dem, vil du fortsatt finne deg selv i et annet lag med krav basert på linje med
virksomhet, jurisdiksjon, kundetyper og produkter/tjenester. En person behandles forskjellig fra et selskap eller en trust og er forskjellig fra forbruker/detaljhandel, kommersielle eller bedriftsområder for krav og egnethet. På det mest grunnleggende av eksempler hvis
vi har 10 typer kunder (enkelte – enslige, gifte osv., privat selskap, offentlig selskap, trust, veldedighet osv.) og du kan operere i 10 regioner, og du kan tilby 10 typer produkter/tjenester, vi er allerede på potensielt 1000+ regler som kunne
anvendes. Ville det ikke vært så mye enklere å definere regler for en region, for en bransje, for en kundetype og produkter eller tjenester og la systemet løse kravene i stedet? Fjerning av duplikater og gjenbruk av datapunkter som var tidligere
sørget for. Dette er fordelen med å abstrahere prosessen og reglene fra datalaget. 

Så nå når vi vurderer det gamle spørsmålet om å kjøpe eller bygge programvare, vet vi at vi trenger omni-channel orkestrering, prosessautomatisering der det er mulig, fleksibel regellogikk, saksbehandling for tilsyn og reviderbarhet, lav kode og API-drevet, et abstrakt
datalag og en intelligent regelmotor som kan arve fra forskjellige logiske lag. Teknologimarkedet er fullt av innovatører som gjerne tilfredsstiller ethvert nisjeproblem som kan tenkes, men på hvilket tidspunkt slutter det å være fornuftig å ha "hyllevare"
produkter som alle må tilpasses og integreres med hverandre i stedet for å bygge det selv. Lavkodeplattformer kan la deg ha 80 % av kravene dine tilgjengelige, og du trenger bare å konfigurere delta 20 %. Det beste fra begge verdener er et lavmål
kodeplattform som andre også har bygget gjenbrukbare komponenter for, slik at du kan få "hyllevare"-produktene som akseleratorer for virksomheten din, samtidig som du har muligheten for ansatte eller sertifiserte tredjeparter til å bygge resten av kravene spesifikke
til organisasjonen din. Å kjøpe eller bygge? Det burde egentlig være begge deler.