Det evige spørgsmål om, hvorvidt du skal købe eller bygge din software (James Monaghan)

Tillykke. Du har et problem, et projekt, et budget og en deadline. I stedet for at kaste kroppe efter det, er software løsningen, men nu skal du beslutte dig for at bygge eller købe, det er spørgsmålet. Eller er det? Jeg er ikke så sikker på, at det er en klar beslutning længere.
Byg brug for at henvise til ansættelse af interne programmører til at kode det system, der var nødvendigt, og køb henvist til de hyldevarer, der kunne købes og køres. Dette gav mening, da vi talte om regnskabssystemer, handelssystemer, CRM, rapportering,
Udlån, Indsamlinger, CLM osv. Vi lever nu i lavkodemiljøet, hvor det at bygge noget ikke kræver kodningserfaring. Det kan være træk og slip. Kombiner det med at købe hyldeløsninger, der ender med at blive så tilpassede, at du måske som
godt har bygget det. Så hvor efterlader det os til at træffe beslutningen om at bygge eller købe? Lad os se på, hvad vi rent faktisk har brug for.

Intet moderne system kan længere stole på et enkelt indgangssted. Kundens forventninger tilsiger, at forskellige kanaler er nødvendige. Personligt, over telefon direkte eller callcenter, e-mail, sociale medier, SMS, web, mobil, tablet – både mobilaktiveret og native
apps, alle med behovet for at være udskiftelige uden at miste indhold eller kontekst. En kunde, der starter i filial/butik eller personligt, men skal af sted til en aftale, ønsker at kunne fortsætte, hvor de slap, når de senere samme dag logger på online. Eller
hvis de starter online, men bliver frustrerede og ringer efter hjælp, ønsker de ikke at skulle starte processen fra begyndelsen. Det gælder også interne interessenter. Informationskæden i en organisation skal være lige så fleksibel som kunden står overfor
valgmuligheder. 

Så hvad næste for vores start hvor som helst datainput? Der er en grund til, at vi har brug for disse data i første omgang. Uanset om en ny kunde ønsker at arbejde med organisationen, en eksisterende kunde vil have et nyt produkt eller en ny service, eller endda bare hverdagens forespørgsler, klager
eller anmodninger om oplysninger. Alle disse bør begynde definerede, men fleksible processer for at fuldføre anmodningen så effektivt og nemt som muligt. Processen er generelt defineret, og normalt er personalet uddannet til at følge en række opgaver for at fuldføre det med forudbestemt
handlinger baseret på visse datainput. 

Hverken slutkunder eller systembrugere bør skulle gentaste information nogen steder, hvis den allerede er blevet fanget et sted. Faktisk, hvis information er tilgængelig overalt i organisationen eller fra tredjepartskilder som dataudbydere, kreditbureauer,
screeningsudbydere osv. bør det være tilgængeligt gennem hele processen for alle brugere, der har brug for det. Processen er defineret, men kontaktpunkterne bør være udskiftelige hele vejen igennem, og de indsamlede data bør integreres, hvor det er muligt og struktureres, hvor det er tilladt.
Rullemenuer, opslagsværdier, datofelter og kontrollerede fritekstværdier for at sikre så meget datakvalitet som muligt på forhånd. Dette giver mulighed for meget mere automatisering gennem hele processen og mindre undtagelseshåndtering.

Nu hvor data er i gang med at blive aktivt fanget eller opdateret, kan den kunstige intelligens anvendes. Personalet behøver ikke at kende alle detaljerne, og selv nyere medlemmer kan arbejde på mere komplekse sager, fordi systemet bruger politikkodede regler
logik til automatisk at træffe beslutninger, som personalet tidligere skulle have omfattende uddannelse og erfaring til at håndtere. Ikke flere fejl, samtidig med at det tillader tilsyn og endda kvalitetskontrol eller direkte undtagelseskøer til manuel indgriben, hvis det er nødvendigt.

Alt dette kræver en systematisk tilgang. Den gamle idé med en manillamappe, der ligger i en medarbejders skuffe til deres kundeportefølje, er forældet og skaber en unødvendig risiko. Klienter, der behandles isoleret, kan være både begrænsende og overflødige
på samme tid. Hvis en virksomhedskunde har direktører, der sidder på tværs af flere andre kunder, hvorfor skulle hver enkelt anmeldelse ignorere det større billede. Skal du også anmelde den samme instruktør flere gange på tværs af hvert forhold eller kunne du
gøre det én gang og genbruge den information på tværs af organisationen?

De behøver ikke engang at have fælles nærtstående parter, for at fordelen er åbenbar. Lignende brancher, lignende kundekunder, hvad nu hvis dine kundeleverandører/leverandører også selv er kunder? Dette bringer os til, hvordan du skal behandle oplysningerne
og hvorfor organisationer skal se på tværs af virksomheden, når de overvejer software i disse dage. Hvis du ser et problem isoleret og behandler det som sådan, opstiller budgetter og udsteder RFP'er for hver CRM-, Fincrime-, Client Outreach-komponent, vil du ende med at
med at bruge flere ressourcer på at forsøge at integrere alt sammen end nogen potentiel besparelse, som man oprindeligt håbede på. Anvend det nu for hver region eller branche, der kan få separate budgetter og tilsyn, og du vil ende med 8 versioner
af den samme software, der skal integreres med sig selv på grund af omfattende tilpasning pr. område, hvilket eliminerer enhver stordriftsfordele, de kunne opnå.

En mappe i en skuffe, der skal gennemgås årligt eller på anden måde, hvor personalet skal oplæres i, hvad de skal gøre, og hvornår de skal gøre det. Hele anmeldelsen (eller ny onboarding/yderligere produkt/service/osv) kan opdeles i sammensatte dele, der evt.
må ikke håndteres af andre personer/hold. Systemet kan derefter bestemme, hvornår en opgave er fuldført, eller hvornår der er indsamlet nok data til at blive sendt til den næste person til deres input. Alle disse er struktureret som sager og undersager inden for. På denne måde hvert element af
sagen kan have sin egen deadline, eskaleringsvej, befuldmægtiget og godkendere. I stedet for én stor opgave, som en medarbejder skal være erfaren nok til at vide, hvordan man udfører, og hvem man skal gå til for forskellige elementer inden for, tildeler systemet nu arbejdet
og sikrer dens rettidig afslutning på tværs af hele virksomheden med så mange opgaver automatiseret som muligt for at frigøre beslutningstagerne til at fokusere på det, der er vigtigt.

Det er alt sammen godt og vel fra et forretningsmæssigt synspunkt. Arbejdet er kendt, og hvad der skal til. Men når vi prøver at beslutte, om vi skal købe eller bygge softwaren selv, hvordan spiller det så ind i tingene? Lad os antage, at der er flere kilder
af data på tværs af flere systemer. Ethvert moderne system forventes at være API-drevet og have lav kode/ingen kodefunktioner. En rimelig antagelse for hurtigere og fleksibel software. Alt i disse dage skal behandles som en slags mikroservice for at undgå
den gamle stil software monolitter. Software bør installeres og bruges, fordi det er den bedst tilgængelige og fremtidssikrede til at tilpasse sig ændringer efter behov. For mange tilbud er forankret og kun vedligeholdt, fordi de er for svære og tidskrævende
at erstatte. Det meste af dette skyldes, at regler er hårdkodede, sandsynligvis sammenflettet med selve dataene, data er ikke kun integreret, men replikeres flere gange for hvert separat stykke software i informationskæden, og hvis du forsøger at erstatte et stykke,
hele systemet kan gå i stykker. For meget af den gamle tankeproces, hvis den ikke er brudt, så lad være med at reparere den. Det, der virkelig er brug for, er, at alle disse komponentdele skal være mikrotjenester, tage data, der er nødvendige, anvende automatiserede regler eller brugerinput/anmeldelser og
videregive den til den næste mikrotjeneste. Data bør ikke opbevares mere end ét sted. Det kan være fødereret, men ikke replikeret uden for sikkerhedskopier. Dine CRM-, Onboarding-, KYC-, Client Outreach-systemer osv. bør kun få adgang til de data, de har brug for og ikke
være datalagre selv, medmindre du har valgt et til at være. At replikere de samme data på tværs af flere lokationer og reglerne, der styrer det, er en øvelse i nytteløshed, da hvert ekstra system, der tilføjes, vil mangedoble de involverede kompleksiteter.

Dette bringer os til den endelige betragtning. Uanset om du har en enkelt kilde til sandhed/Golden Copy eller flere redundante og konkurrerende registreringer og systemer, der kan opdatere dem, vil du stadig finde dig selv i et andet lag af krav baseret på linje af
forretning, jurisdiktion, kundetyper og produkter/tjenester. En person behandles forskelligt fra en virksomhed eller trust og adskiller sig fra forbruger/detail, kommercielle eller virksomhedsbrancher med hensyn til krav og egnethed. På de mest grundlæggende eksempler hvis
vi har 10 typer kunder (individuelle – single, gift osv., privat virksomhed, offentlig virksomhed, trust, velgørenhed osv.), og du kan operere i 10 regioner, og du tilbyder måske 10 typer produkter/tjenester, vi er allerede på potentielt 1000+ regler, der kunne
blive anvendt. Ville det ikke være så meget nemmere at definere regler for en region, for en branche, for en kundetype og produkter eller tjenester og lade systemet løse kravene i stedet? Fjernelse af dubletter og genbrug af datapunkter, der var tidligere
stillet til rådighed. Dette er fordelen ved at abstrahere din proces og regler fra dit datalag. 

Så nu, når vi overvejer det gamle spørgsmål om at købe eller bygge software, ved vi, at vi har brug for omni-channel orkestrering, procesautomatisering, hvor det er muligt, fleksibel regellogik, sagshåndtering for tilsyn og auditabilitet, lav kode og API-drevet, et abstrakt
datalag og en intelligent regelmotor, der kan arve fra forskellige logiske lag. Teknologimarkedet er fyldt med innovatører, der med glæde tilfredsstiller ethvert nicheproblem, der kan tænkes, men på hvilket tidspunkt holder det op med at give mening at have 'fra hylden'
produkter, der alle skal tilpasses og integreres med hinanden i stedet for at bygge det selv. Lavkodeplatforme kan lade dig have 80 % af dine krav til rådighed, og du behøver kun at konfigurere de 20 % delta. Det bedste fra begge verdener er et lavpunkt
kodeplatform, som andre også har bygget genanvendelige komponenter til, så du kan få 'hyldevare'-produkterne som acceleratorer til din virksomhed, mens du også har mulighed for, at dit personale eller certificerede tredjeparter kan bygge resten af ​​de specifikke krav
til din organisation. At købe eller bygge? Det burde virkelig være begge dele.