L'eterna questione se comprare o costruire il tuo software (James Monaghan)

Congratulazioni. Hai un problema, un progetto, un budget e una scadenza. Invece di buttarci sopra, il software è la soluzione, ma ora devi decidere se costruire o acquistare, questo è il problema. O è? Non sono più tanto sicuro che sia una decisione netta.
Build use per fare riferimento all'assunzione di programmatori interni per codificare qualsiasi sistema fosse necessario e acquistare riferito ai prodotti standard che potevano essere acquistati ed eseguiti. Questo aveva senso quando parlavamo di sistemi contabili, sistemi di trading, CRM, reportistica,
Prestiti, riscossioni, CLM, ecc. Ora viviamo in un ambiente a basso codice in cui costruire qualcosa non richiede esperienza di codifica. Può essere trascina e rilascia. Abbinalo all'acquisto di soluzioni standard che finiscono per essere così personalizzate che potresti desiderare
bene l'hanno costruito. Quindi dove ci lascia questo per prendere la decisione di costruire o acquistare? Diamo un'occhiata a ciò di cui abbiamo effettivamente bisogno.

Nessun sistema moderno può più contare su un singolo punto di accesso. Le aspettative dei clienti impongono che siano necessari vari canali. Di persona, tramite telefono diretto o call center, e-mail, social media, SMS, web, mobile, tablet, sia mobile che nativo
app, tutte con la necessità di essere intercambiabili senza perdere contenuto o contesto. Un cliente che inizia in filiale/negozio o di persona ma deve partire per un appuntamento vuole poter riprendere da dove si era interrotto quando accederà più tardi quel giorno online. O
se iniziano online ma si sentono frustrati e chiedono aiuto, non vogliono dover ricominciare il processo dall'inizio. Questo vale anche per gli stakeholder interni. La catena delle informazioni all'interno di un'organizzazione deve essere tanto flessibile quanto il rapporto con il cliente
opzioni. 

Quindi cosa succederà per il nostro inizio ovunque input di dati? Bene, c'è una ragione per cui abbiamo bisogno di quei dati in primo luogo. Se un nuovo cliente vuole lavorare con l'organizzazione, un cliente esistente desidera un nuovo prodotto o servizio, o anche solo domande quotidiane, reclami
o richieste di informazioni. Tutti questi dovrebbero iniziare processi definiti ma flessibili per completare la richiesta nel modo più efficiente e semplice possibile. Il processo è generalmente definito e di solito il personale è addestrato a seguire una sequenza di compiti per completarlo con predeterminato
azioni basate su determinati input di dati. 

Né i clienti finali né gli utenti del sistema dovrebbero dover reinserire le informazioni da qualche parte se sono già state acquisite da qualche parte. Infatti, se le informazioni sono disponibili ovunque all'interno dell'organizzazione o da fonti di terze parti come fornitori di dati, agenzie di credito,
fornitori di screening, ecc. dovrebbe essere accessibile durante tutto il processo per tutti gli utenti che ne hanno bisogno. Il processo è definito ma i punti di contatto dovrebbero essere intercambiabili e i dati raccolti dovrebbero essere integrati ove possibile e strutturati ove consentito.
Menu a discesa, valori di ricerca, campi data e valori di testo libero controllati per garantire in anticipo la massima acquisizione della qualità dei dati. Ciò consente una maggiore automazione durante tutto il processo e una minore gestione delle eccezioni.

Ora che i dati sono in fase di acquisizione o aggiornamento attivo, è possibile applicare l'intelligenza artificiale. Il personale non ha bisogno di conoscere tutti i dettagli e anche i nuovi membri possono lavorare su casi più complessi perché il sistema utilizza regole codificate da policy
logica per prendere automaticamente decisioni che il personale in precedenza doveva avere una vasta formazione ed esperienza per gestire. Niente più errori, consentendo anche la supervisione e persino i controlli di controllo della qualità o code di eccezioni definitive per l'intervento manuale, se necessario.

Tutto ciò richiede un approccio sistematico. La vecchia idea di una cartella manilla che si trova nel cassetto di un membro dello staff per il loro portafoglio clienti è obsoleta e crea un rischio inutile. I client elaborati in isolamento possono essere sia limitanti che ridondanti
allo stesso tempo. Se un cliente aziendale ha direttori che siedono su più altri clienti, perché ogni singola recensione dovrebbe ignorare il quadro più ampio. Rivedrai anche lo stesso regista più volte in ogni relazione o potresti
farlo una volta e riutilizzare tali informazioni in tutta l'organizzazione?

Non è nemmeno necessario che abbiano parti correlate comuni affinché il vantaggio sia evidente. Settori simili, clienti clienti simili, cosa succede se i venditori/fornitori clienti sono anche loro stessi clienti? Questo ci porta a come è necessario elaborare le informazioni
e perché le organizzazioni devono guardare all'intera azienda quando prendono in considerazione il software in questi giorni. Se consideri un problema isolatamente e lo tratti come tale, stabilendo budget ed emettendo RFP per ogni componente CRM, Fincrime, Client Outreach, finirai per
con la spesa di più risorse cercando di integrare tutto insieme rispetto a qualsiasi potenziale risparmio inizialmente sperato. Ora applicalo per ogni regione o linea di attività che potrebbe ottenere budget e supervisione separati e ti ritroverai con 8 versioni
dello stesso software che deve essere integrato con se stesso a causa della forte personalizzazione per area eliminando eventuali economie di scala che potrebbero ottenere.

Una cartella in un cassetto che deve essere rivista annualmente o meno, con il personale che deve essere formato su cosa fare e quando farlo. L'intera recensione (o nuovo onboarding/prodotto/servizio aggiuntivo/ecc.) può essere suddivisa in parti composite che possono o
non può essere gestito da altre persone/team. Il sistema può quindi determinare quando un'attività è completa o quando vengono acquisiti dati sufficienti per essere inviati alla persona successiva per il loro input. Tutti questi sono strutturati come casi e sottocasi all'interno. In questo modo ogni elemento di
il caso può avere una propria scadenza, percorso di escalation, cessionario e approvatori. Invece di un grande compito che un membro del personale deve essere abbastanza esperto da sapere come completare e a chi rivolgersi per i vari elementi all'interno, il sistema ora assegna il lavoro
e ne garantisce il completamento tempestivo in tutta l'azienda con il maggior numero di attività automatizzate possibile per consentire ai decisori di concentrarsi su ciò che è importante.

Tutto questo va bene dal punto di vista degli affari. Il lavoro è noto e ciò che deve essere fatto. Ma quando stiamo cercando di decidere se dovremmo acquistare o costruire il software da soli, come influisce questo fattore sulle cose? Bene, supponiamo che ci siano più fonti
di dati su più sistemi. Qualsiasi sistema moderno dovrebbe essere basato su API e avere funzionalità di codice basso/nessun codice. Un presupposto ragionevole per un software più veloce e flessibile. Tutto in questi giorni deve essere trattato come una sorta di microservizio da evitare
i monoliti software vecchio stile. Il software deve essere installato e utilizzato perché è il migliore disponibile ea prova di futuro per adattarsi ai cambiamenti secondo necessità. Troppe offerte sono radicate e mantenute solo perché sono troppo difficili e richiedono tempo
Rimpiazzare. La maggior parte di ciò è dovuto al fatto che le regole sono codificate, probabilmente intrecciate con i dati stessi, i dati non sono solo integrati ma replicati più volte per ogni pezzo separato di software nella catena di informazioni e se si tenta di sostituire un pezzo, il
l'intero sistema potrebbe rompersi. Troppo del vecchio processo di pensiero, se non è rotto, allora non aggiustarlo. Ciò che è veramente necessario è che tutti quei componenti siano microservizi, prendendo i dati necessari, applicando regole automatizzate o input/revisioni degli utenti e
passandolo al microservizio successivo. I dati non devono essere archiviati in più di una posizione. Può essere federato ma non replicato al di fuori dei backup. I tuoi sistemi CRM, Onboarding, KYC, Client Outreach, ecc. dovrebbero accedere solo ai dati di cui hanno bisogno e non
essere essi stessi repository di dati a meno che tu non ne abbia scelto uno. Replicare gli stessi dati su più sedi e le regole che li governano è un esercizio futile poiché ogni sistema aggiuntivo aggiunto moltiplicherà le complessità coinvolte.

Questo ci porta alla considerazione finale. Sia che tu abbia un'unica fonte di verità/copia aurea o più record e sistemi ridondanti e concorrenti che possono aggiornarli, ti ritroverai comunque in un altro livello di requisiti basato sulla linea di
attività, giurisdizione, tipi di clienti e prodotti/servizi. Un individuo è trattato in modo diverso da un'azienda o da un trust e differisce in base alle linee di attività di consumo/vendita al dettaglio, commerciale o aziendale per requisiti e idoneità. Nel più elementare degli esempi if
abbiamo 10 tipi di clienti (privati ​​- single, sposati, ecc., società private, società pubbliche, fiduciari, enti di beneficenza, ecc.) e potresti operare in 10 regioni e potresti offrire 10 tipi di prodotti/servizi, siamo già a potenzialmente oltre 1000 regole che potrebbero
essere applicato. Non sarebbe molto più semplice definire regole per una regione, per una linea di attività, per un tipo di cliente e prodotti o servizi e lasciare invece che il sistema risolva i requisiti? Rimozione di duplicati e riutilizzo di punti dati precedenti
fornito. Questo è il vantaggio di astrarre il tuo processo e le tue regole dal tuo livello dati. 

Quindi ora, quando consideriamo la vecchia questione dell'acquisto o della creazione di software, sappiamo di aver bisogno di orchestrazione omnicanale, automazione dei processi ove possibile, logica delle regole flessibile, gestione dei casi per la supervisione e la verificabilità, basso codice e API guidati, un abstract
livello dati e un motore di regole intelligente che può ereditare da diversi livelli logici. Il mercato tecnologico è pieno di innovatori che soddisfano volentieri ogni problema di nicchia che si possa pensare, ma a che punto smette di avere senso avere "pronto per l'uso"
prodotti che devono essere tutti personalizzati e integrati tra loro invece di costruirli da soli. Le piattaforme a basso codice possono farti avere l'80% dei tuoi requisiti disponibili e devi solo configurare quel delta 20%. Il meglio di entrambi i mondi è un minimo
piattaforma di codice per la quale anche altri hanno creato componenti riutilizzabili in modo da poter ottenere i prodotti "pronti all'uso" come acceleratori per la tua azienda, pur avendo la possibilità per il tuo personale o terze parti certificate di costruire il resto dei requisiti specifici
alla tua organizzazione. Comprare o costruire? Dovrebbero davvero essere entrambe le cose.