De eeuwige vraag of u uw software moet kopen of bouwen (James Monaghan)

Gefeliciteerd. Je hebt een probleem, een project, een budget en een deadline. In plaats van er lichamen tegenaan te gooien, is software de oplossing, maar nu moet je beslissen om te bouwen of te kopen, dat is de vraag. Of is het? Ik ben er niet meer zo zeker van dat het een duidelijke beslissing is.
Met Build wordt verwezen naar het inhuren van interne programmeurs om welk systeem dan ook te coderen dat nodig is, en met kopen wordt verwezen naar kant-en-klare producten die kunnen worden gekocht en uitgevoerd. Dit was logisch toen we het hadden over boekhoudsystemen, handelssystemen, CRM, rapportage,
Uitlenen, collecties, CLM, enz. We leven nu in een low-code-omgeving waar het bouwen van iets geen codeerervaring vereist. Het kan slepen en neerzetten zijn. Combineer dat met het kopen van kant-en-klare oplossingen die uiteindelijk zo op maat gemaakt zijn dat u dat ook zou kunnen doen
goed, heb het gebouwd. Dus waar moeten we de beslissing nemen om te bouwen of te kopen? Laten we eens kijken naar wat we eigenlijk nodig hebben.

Geen enkel modern systeem kan meer vertrouwen op één enkel toegangspunt. De verwachtingen van de klant schrijven voor dat er verschillende kanalen nodig zijn. Persoonlijk, via de telefoon of via een callcenter, e-mail, sociale media, sms, internet, mobiel, tablet – zowel mobiel als native
apps, allemaal met de noodzaak om uitwisselbaar te zijn zonder inhoud of context te verliezen. Een klant die in een filiaal/winkel of persoonlijk begint maar voor een afspraak moet vertrekken, wil later die dag online kunnen verdergaan waar hij was gebleven. Of
Als ze online beginnen maar gefrustreerd raken en hulp inroepen, willen ze het proces niet vanaf het begin moeten beginnen. Dit geldt ook voor interne stakeholders. De informatieketen binnen een organisatie moet net zo flexibel zijn als de klant
opties. 

Dus wat nu voor onze start overal gegevensinvoer? Er is een reden waarom we die gegevens überhaupt nodig hebben. Of een nieuwe klant bij de organisatie wil werken, een bestaande klant een nieuw product of dienst wil, of gewoon alledaagse vragen, klachten
of informatieverzoeken. Al deze moeten beginnen met gedefinieerde maar flexibele processen om het verzoek zo efficiënt en gemakkelijk mogelijk te voltooien. Het proces is over het algemeen gedefinieerd en meestal wordt het personeel getraind om een ​​reeks taken te volgen om deze met vooraf bepaalde taken te voltooien
acties op basis van bepaalde gegevensinvoer. 

Noch eindklanten, noch systeemgebruikers zouden informatie ergens opnieuw moeten intoetsen als deze al ergens is vastgelegd. Als informatie overal binnen de organisatie beschikbaar is of via bronnen van derden, zoals gegevensproviders, kredietbureaus,
screeningaanbieders, etc. het moet gedurende het hele proces toegankelijk zijn voor alle gebruikers die het nodig hebben. Het proces is gedefinieerd, maar de contactpunten moeten overal uitwisselbaar zijn en de verzamelde gegevens moeten waar mogelijk worden geïntegreerd en waar toegestaan ​​worden gestructureerd.
Vervolgkeuzemenu's, opzoekwaarden, datumvelden en gecontroleerde vrije tekstwaarden om vooraf een zo hoog mogelijke gegevenskwaliteit te garanderen. Dit zorgt voor veel meer automatisering gedurende het hele proces en minder afhandeling van uitzonderingen.

Nu gegevens actief worden vastgelegd of bijgewerkt, kan de kunstmatige intelligentie worden toegepast. Het personeel hoeft niet alle details te kennen en zelfs nieuwere leden kunnen aan complexere zaken werken omdat het systeem gebruikmaakt van beleidsgecodeerde regels
logica om automatisch beslissingen te nemen waarvoor het personeel voorheen uitgebreide training en ervaring moest hebben. Geen fouten meer, terwijl ook toezicht en zelfs kwaliteitscontroles of regelrechte uitzonderingswachtrijen mogelijk zijn voor handmatige interventie indien nodig.

Dit alles vereist een systematische aanpak. Het oude idee van een manillamap die in de lade van een medewerker ligt voor hun klantenportefeuille is achterhaald en brengt een onnodig risico met zich mee. Clients die afzonderlijk worden verwerkt, kunnen zowel beperkend als overbodig zijn
tegelijkertijd. Als een zakelijke klant directeuren heeft die tegenover meerdere andere klanten zitten, waarom zou elke individuele recensie dan het grotere geheel negeren? Ga je dezelfde regisseur ook meerdere keren beoordelen in elke relatie of zou je dat kunnen?
één keer doen en die informatie in de hele organisatie hergebruiken?

Ze hoeven niet eens gemeenschappelijke verbonden partijen te hebben om het voordeel duidelijk te maken. Vergelijkbare sectoren, vergelijkbare klanten, wat als de leveranciers/leveranciers van uw klanten zelf ook klanten zijn? Dit brengt ons bij de manier waarop u de informatie moet verwerken
en waarom organisaties tegenwoordig naar de hele onderneming moeten kijken als ze software overwegen. Als je een probleem op zichzelf bekijkt en het als zodanig behandelt, budgetten opstelt en RFP’s uitbrengt voor elke CRM-, Fincrime- en Client Outreach-component, kom je uiteindelijk uit op
met het uitgeven van meer middelen om alles met elkaar te integreren dan enige potentiële besparing waarop aanvankelijk werd gehoopt. Pas dat nu toe voor elke regio of branche die mogelijk aparte budgetten en toezicht krijgt, en je krijgt uiteindelijk 8 versies
van dezelfde software die met zichzelf moet worden geïntegreerd vanwege de zware aanpassingen per gebied, waardoor eventuele schaalvoordelen worden geëlimineerd.

Een map in een lade die al dan niet jaarlijks moet worden herzien, waarbij het personeel moet worden opgeleid wat ze moeten doen en wanneer ze dat moeten doen. De gehele review (of nieuwe onboarding/aanvullend product/dienst/enz.) kan worden opgesplitst in samengestelde delen die al dan niet
mogen niet door andere mensen/teams worden afgehandeld. Het systeem kan vervolgens bepalen wanneer een taak is voltooid of wanneer er voldoende gegevens zijn vastgelegd om naar de volgende persoon te worden gestuurd voor invoer. Al deze zijn gestructureerd als cases en sub-cases binnenin. Op deze manier wordt elk element van
de case kan een eigen deadline, escalatiepad, verantwoordelijke persoon en goedkeurders hebben. In plaats van één grote taak waarbij een medewerker voldoende ervaring moet hebben om te weten hoe hij deze moet voltooien en bij wie hij terecht kan voor de verschillende elementen binnen het systeem, wijst het systeem nu het werk toe
en zorgt voor een tijdige voltooiing ervan in het hele bedrijf, waarbij zoveel mogelijk taken worden geautomatiseerd, zodat de besluitvormers zich kunnen concentreren op wat belangrijk is.

Vanuit zakelijk oogpunt is dit allemaal goed en wel. De werkzaamheden zijn bekend en wat er gedaan moet worden. Maar als we proberen te beslissen of we de software zelf moeten kopen of bouwen, hoe speelt dat dan een rol? Laten we aannemen dat er meerdere bronnen zijn
van gegevens over meerdere systemen. Van elk modern systeem wordt verwacht dat het API-gestuurd is en low-code/no-code-mogelijkheden heeft. Een redelijke aanname voor snellere en flexibele software. Alles moet tegenwoordig worden behandeld als een soort microservice die je moet vermijden
de oude stijl softwaremonolieten. Software moet worden geïnstalleerd en gebruikt omdat deze het beste beschikbaar is en toekomstbestendig is om zich aan te passen aan veranderingen als dat nodig is. Te veel aanbiedingen zijn verankerd en worden alleen onderhouden omdat ze te moeilijk en tijdrovend zijn
vervangen. Het grootste deel hiervan komt doordat de regels hardgecodeerd zijn, waarschijnlijk verweven met de data zelf. Data worden niet alleen geïntegreerd, maar worden meerdere keren gerepliceerd voor elk afzonderlijk stukje software in de informatieketen. Als je één stukje software probeert te vervangen, verandert de
het hele systeem zou kapot kunnen gaan. Te veel van het oude denkproces; als het niet kapot is, repareer het dan niet. Wat echt nodig is, is dat al deze onderdelen microservices zijn, waarbij de benodigde gegevens worden verzameld, geautomatiseerde regels of gebruikersinvoer/beoordelingen worden toegepast en
het doorgeven aan de volgende microservice. Gegevens mogen niet op meer dan één locatie worden opgeslagen. Het kan federatief zijn, maar mag niet buiten back-ups worden gerepliceerd. Uw CRM-, Onboarding-, KYC-, Client Outreach-, enz.-systemen mogen alleen toegang krijgen tot de gegevens die ze nodig hebben en niet
zelf gegevensopslagplaatsen zijn, tenzij u er een heeft uitgekozen. Het repliceren van dezelfde gegevens over meerdere locaties en de regels die daarop van toepassing zijn, is een oefening in nutteloosheid, aangezien elk extra systeem dat wordt toegevoegd de complexiteit ervan zal vergroten.

Dit brengt ons bij de laatste overweging. Of u nu één enkele bron van waarheid/Golden Copy heeft of meerdere redundante en concurrerende documenten en systemen die deze kunnen bijwerken, u zult nog steeds in een andere laag van eisen terechtkomen, gebaseerd op de lijn van eisen.
bedrijf, jurisdictie, klanttypes en producten/diensten. Een individu wordt anders behandeld dan een bedrijf of trust en verschilt per consumenten-/detailhandel, commerciële of zakelijke branche wat betreft vereisten en geschiktheid. In de meest elementaire voorbeelden als
we hebben 10 soorten klanten (individu – alleenstaand, getrouwd, enz., privébedrijf, naamloze vennootschap, trust, liefdadigheidsinstelling, enz.) en u kunt in 10 regio’s actief zijn, en u kunt 10 soorten producten/diensten aanbieden, we zijn al op potentieel meer dan 1000 regels die dat zouden kunnen
worden toegepast. Zou het niet zoveel eenvoudiger zijn om regels te definiëren voor een regio, voor een branche, voor een klanttype en producten of diensten en het systeem de vereisten te laten oplossen? Het verwijderen van duplicaten en het hergebruiken van datapunten die voorheen aanwezig waren
mits. Dit is het voordeel van het abstraheren van uw proces en regels uit uw gegevenslaag. 

Dus als we nu nadenken over de oude kwestie van het kopen of bouwen van software, weten we dat we omni-channel orkestratie nodig hebben, procesautomatisering waar mogelijk, flexibele regellogica, case management voor overzicht en controleerbaarheid, low-code en API-gestuurd, een abstract
datalaag en een intelligente regelengine die kan erven van verschillende logische lagen. De technologiemarkt zit vol met innovators die graag elk nicheprobleem bevredigen dat maar kan worden bedacht, maar op welk punt is het niet langer zinvol om ‘van de plank’ te hebben?
producten die allemaal op maat gemaakt en met elkaar geïntegreerd moeten worden in plaats van ze zelf te bouwen. Met low-code platforms kunt u 80% van uw vereisten beschikbaar hebben en hoeft u die delta slechts 20% te configureren. Het beste van beide werelden is een dieptepunt
codeplatform waar anderen ook herbruikbare componenten voor hebben gebouwd, zodat u kant-en-klare producten als versnellers voor uw bedrijf kunt krijgen, terwijl uw personeel of gecertificeerde derde partijen ook de mogelijkheid hebben om de rest van de vereisten specifiek te bouwen
aan uw organisatie. Kopen of bouwen? Het zou eigenlijk allebei moeten zijn.