Den eviga frågan om du ska köpa eller bygga din programvara (James Monaghan)

Grattis. Du har ett problem, ett projekt, en budget och en deadline. Istället för att kasta kroppar på det är mjukvara lösningen men nu måste du bestämma dig för att bygga eller köpa, det är frågan. Eller är det? Jag är inte så säker på att det är ett självklart beslut längre.
Bygg användning för att hänvisa till att anställa interna programmerare för att koda vilket system som helst som var nödvändigt och köpa hänvisat till de hyllprodukter som kunde köpas och köras. Detta var vettigt när vi pratade om redovisningssystem, handelssystem, CRM, rapportering,
Utlåning, Inkasso, CLM, etc. Vi lever nu i lågkodsmiljön där att bygga något inte kräver erfarenhet av kodning. Det kan vara dra och släpp. Kombinera det med att köpa hylllösningar som i slutändan blir så anpassade att du kanske som
väl har byggt den. Så var lämnar det oss att fatta beslutet om att bygga eller köpa? Låt oss titta på vad vi faktiskt behöver.

Inget modernt system kan längre förlita sig på en enda ingångspunkt. Kundernas förväntningar dikterar att olika kanaler är nödvändiga. Personligen, via telefon direkt eller callcenter, e-post, sociala medier, SMS, webb, mobil, surfplatta – både mobilaktiverad och inbyggd
appar, alla med behovet av att vara utbytbara utan att förlora innehåll eller sammanhang. En kund som börjar i filial/butik eller personligen men måste gå för ett möte vill kunna fortsätta där de slutade när de loggar in senare samma dag online. Eller
om de börjar online men blir frustrerade och ringer efter hjälp vill de inte behöva starta processen från början. Detta gäller även interna intressenter. Informationskedjan inom en organisation måste vara lika flexibel som kunden står inför
alternativ. 

Så vad nästa för vår start var som helst datainmatningar? Tja, det finns en anledning till att vi behöver den informationen i första hand. Oavsett om en ny kund vill arbeta med organisationen, en befintlig kund vill ha en ny produkt eller tjänst, eller till och med bara vardagliga frågor, klagomål
eller informationsförfrågningar. Alla dessa bör starta definierade men flexibla processer för att slutföra begäran så effektivt och enkelt som möjligt. Processen är allmänt definierad och vanligtvis är personalen utbildad att följa en sekvens av uppgifter för att slutföra den med förutbestämda
åtgärder baserade på vissa indata. 

Varken slutkunder eller systemanvändare ska behöva knappa om information någonstans om den redan har fångats någonstans. Faktum är att om information är tillgänglig var som helst inom organisationen eller från tredje parts källor som dataleverantörer, kreditupplysningsföretag,
screeningleverantörer etc. bör den vara tillgänglig under hela processen för alla användare som behöver den. Processen är definierad men kontaktpunkterna bör vara utbytbara genomgående och insamlad data bör integreras där det är möjligt och struktureras där det är tillåtet.
Rullgardinsmenyer, uppslagsvärden, datumfält och kontrollerade fritextvärden för att säkerställa så mycket datakvalitetsfångst i förväg. Detta möjliggör mycket mer automatisering genom hela processen och mindre undantagshantering.

Nu när data är i färd med att aktivt fångas eller uppdateras kan den artificiella intelligensen tillämpas. Personalen behöver inte känna till alla detaljer och även nyare medlemmar kan arbeta med mer komplexa fall eftersom systemet använder policykodade regler
logik för att automatiskt fatta beslut som personalen tidigare behövde ha omfattande utbildning och erfarenhet för att hantera. Inga fler misstag samtidigt som det tillåter tillsyn och till och med kvalitetskontroller eller direkta undantagsköer för manuellt ingripande vid behov.

Allt detta kräver ett systematiskt tillvägagångssätt. Den gamla idén med en manillapärm som ligger i en personallåda för deras kundportfölj är föråldrad och skapar en onödig risk. Klienter som behandlas isolerat kan vara både begränsande och överflödiga
på samma gång. Om en företagskund har direktörer som sitter på flera andra kunder, varför skulle varje enskild recension ignorera den större bilden. Kommer du också att recensera samma regissör flera gånger i varje relation eller kan du
göra det en gång och återanvända den informationen i hela organisationen?

De behöver inte ens ha gemensamma närstående för att nyttan ska vara uppenbar. Liknande branscher, liknande kundkunder, vad händer om dina kundleverantörer/leverantörer också är kunder själva? Detta för oss till hur du behöver behandla informationen
och varför organisationer behöver se över hela företaget när de överväger programvara i dessa dagar. Om du ser ett problem isolerat och behandlar det som sådant, upprättar budgetar och utfärdar offertförslag för varje CRM, Fincrime, Client Outreach-komponent, kommer du att sluta
med att lägga mer resurser på att försöka integrera allt tillsammans än någon potentiell besparing som man först hoppades på. Använd det nu för varje region eller bransch som kan få separata budgetar och tillsyn och du kommer att få 8 versioner
av samma programvara som måste integreras med sig själv på grund av tung anpassning per område vilket eliminerar eventuella skalfördelar de kan uppnå.

En pärm i en byrålåda som behöver ses över årligen eller på annat sätt, med personal som behöver utbildas vad de ska göra och när de ska göra det. Hela recensionen (eller ny onboarding/ytterligare produkt/tjänst/etc) kan delas upp i sammansatta delar som kan eller
får inte hanteras av andra personer/lag. Systemet kan sedan avgöra när en uppgift är klar eller när tillräckligt mycket data har samlats in för att skickas till nästa person för inmatning. Alla dessa är strukturerade som ärenden och delfall inom. Detta sätt varje element av
ärendet kan ha sin egen deadline, eskaleringsväg, uppdragstagare och godkännare. Istället för en stor uppgift som en anställd behöver vara erfaren nog att veta hur man ska slutföra och vem man ska gå till för olika moment inom, tilldelar systemet nu arbetet
och säkerställer att det slutförs i rätt tid över hela företaget med så många uppgifter automatiserade som möjligt för att frigöra beslutsfattarna att fokusera på det som är viktigt.

Allt detta är bra ur affärsmässig synvinkel. Arbetet är känt och vad som behöver göras. Men när vi försöker bestämma oss för om vi ska köpa eller bygga programvaran själva, hur påverkar det saker och ting? Tja, låt oss anta att det finns flera källor
data över flera system. Alla moderna system förväntas vara API-drivna och ha låg kod/ingen kodkapacitet. Ett rimligt antagande för snabbare och flexibel mjukvara. Allt i dessa dagar måste behandlas som en slags mikrotjänst för att undvika
de gamla mjukvarumonoliterna. Programvara bör installeras och användas eftersom den är den bästa tillgängliga och framtidssäkrade för att anpassa sig till förändringar efter behov. Alltför många erbjudanden är förankrade och underhålls bara för att de är för svåra och tidskrävande
att ersätta. Det mesta beror på att regler är hårdkodade, förmodligen sammanflätade med själva data, data inte bara integreras utan replikeras flera gånger för varje separat mjukvara i informationskedjan och om du försöker ersätta en del,
hela systemet kan gå sönder. För mycket av den gamla tankeprocessen, om den inte är trasig så fixa den inte. Vad som verkligen behövs är att alla dessa komponentdelar ska vara mikrotjänster, ta data som behövs, tillämpa automatiserade regler eller användarinmatningar/recensioner och
skickar den vidare till nästa mikrotjänst. Data bör inte lagras på mer än en plats. Det kan vara federerat men inte replikeras utanför säkerhetskopior. Dina CRM-, Onboarding-, KYC-, Client Outreach-system, etc. ska bara komma åt den data de behöver och inte
vara dataförråd själva om du inte har valt en att vara. Att replikera samma data över flera platser och reglerna som styr det är en övning i meningslöshet eftersom varje extra system som läggs till kommer att multiplicera komplexiteten.

Detta för oss till den sista övervägandet. Oavsett om du har en enda källa till sanning/Golden Copy eller flera redundanta och konkurrerande poster och system som kan uppdatera dem, kommer du fortfarande att hamna i ett annat lager av krav baserat på rad av
verksamhet, jurisdiktion, kundtyper och produkter/tjänster. En individ behandlas annorlunda än ett företag eller förtroende och skiljer sig från konsument-/detaljhandels-, kommersiella eller företagsgrenar för krav och lämplighet. På det mest grundläggande av exempel om
vi har 10 typer av kunder (enskilda – singel, gift, etc, privat företag, offentligt företag, trust, välgörenhet, etc) och du kan verka i 10 regioner, och du kan erbjuda 10 typer av produkter/tjänster, vi finns redan på potentiellt 1000+ regler som skulle kunna
vara ansökt. Skulle det inte vara så mycket lättare att definiera regler för en region, för en bransch, för en kundtyp och produkter eller tjänster och låta systemet lösa kraven istället? Ta bort dubbletter och återanvända datapunkter som var tidigare
försedd. Detta är fördelen med att abstrahera din process och regler från ditt datalager. 

Så nu när vi överväger den gamla frågan om att köpa eller bygga mjukvara, vet vi att vi behöver omni-channel orkestrering, processautomation där det är möjligt, flexibel regellogik, ärendehantering för tillsyn och granskning, låg kod och API-driven, en abstrakt
datalager och en intelligent regelmotor som kan ärva från olika logiska lager. Teknikmarknaden är full av innovatörer som gärna tillfredsställer alla nischproblem man kan tänka sig, men vid vilken tidpunkt slutar det att vara vettigt att ha "off the shelf"
produkter som alla behöver skräddarsys och integreras med varandra istället för att bygga det själv. Lågkodsplattformar kan låta dig ha 80 % av dina krav tillgängliga och du behöver bara konfigurera delta 20 %. Det bästa av två världar är en låg
kodplattform som andra också har byggt återanvändbara komponenter för så att du kan få "hylla"-produkterna som acceleratorer för ditt företag samtidigt som du har möjligheten för din personal eller certifierade tredje part att bygga resten av de specifika kraven
till din organisation. Att köpa eller bygga? Det borde verkligen vara både och.