Eterna întrebare dacă să cumpărați sau să vă construiți software-ul (James Monaghan) PlatoBlockchain Data Intelligence. Căutare verticală. Ai.

Eterna întrebare dacă să cumpărați sau să vă construiți software-ul (James Monaghan)

Felicitări. Ai o problemă, un proiect, un buget și un termen limită. În loc să arunci cu cadavre în el, software-ul este soluția, dar acum trebuie să te decizi să construiești sau să cumperi, asta este întrebarea. Sau este? Nu mai sunt atât de sigur că este o decizie clară.
Utilizați utilizarea pentru a face referire la angajarea de programatori interni pentru a codifica orice sistem era necesar și pentru a cumpăra produse de la raft care ar putea fi achiziționate și rulate. Acest lucru a avut sens când vorbeam despre sisteme de contabilitate, sisteme de tranzacționare, CRM, raportare,
Împrumuturi, Colecții, CLM etc. Acum trăim într-un mediu low code în care construirea a ceva nu necesită experiență de codare. Poate fi drag and drop. Combinați asta cu cumpărarea de soluții de la raft care ajung să fie atât de personalizate încât ați putea
bine l-am construit. Deci, unde ne lasă asta să luăm decizia de a construi sau de a cumpăra? Să ne uităm la ce avem de fapt nevoie.

Niciun sistem modern nu se mai poate baza pe un singur punct de intrare. Așteptările clienților dictează că sunt necesare diverse canale. Persoană, prin telefon direct sau call center, e-mail, social media, SMS, web, mobil, tabletă – atât cu dispozitive mobile, cât și native
aplicații, toate cu nevoia de a fi interschimbabile fără a pierde conținut sau context. Un client care începe în sucursală/magazin sau personal, dar trebuie să plece la o programare dorește să poată relua de unde a rămas atunci când se autentifică online mai târziu în acea zi. Sau
dacă încep online, dar sunt frustrați și apelează pentru ajutor, nu vor să fie nevoiți să înceapă procesul de la început. Acest lucru se aplică și părților interesate interne. Lanțul informațional din cadrul unei organizații trebuie să fie la fel de flexibil ca și clientul
opțiuni. 

Deci, ce urmează pentru intrarea noastră de date oriunde? Ei bine, există un motiv pentru care avem nevoie de acele date în primul rând. Indiferent dacă un client nou dorește să lucreze cu organizația, un client existent dorește un nou produs sau serviciu sau chiar doar întrebări, plângeri de zi cu zi
sau cereri de informatii. Toate acestea ar trebui să înceapă procese definite, dar flexibile, pentru a finaliza solicitarea cât mai eficient și ușor posibil. Procesul este în general definit și, de obicei, personalul este instruit să urmeze o secvență de sarcini pentru a o finaliza cu o serie de sarcini predeterminate.
acțiuni bazate pe anumite intrări de date. 

Nici clienții finali, nici utilizatorii de sistem nu ar trebui să fie nevoiți să tasteze din nou informațiile, dacă acestea au fost deja capturate undeva. De fapt, dacă informațiile sunt disponibile oriunde în cadrul organizației sau din surse terțe, cum ar fi furnizorii de date, birourile de credit,
furnizorii de screening etc. ar trebui să fie accesibil pe tot parcursul procesului pentru toți utilizatorii care au nevoie de el. Procesul este definit, dar punctele de contact ar trebui să fie interschimbabile, iar datele culese ar trebui integrate acolo unde este posibil și structurate acolo unde este permis.
Meniuri drop-down, valori de căutare, câmpuri de dată și valori controlate de text liber pentru a asigura cât mai multă calitate a datelor capturate în avans. Acest lucru permite mult mai multă automatizare pe tot parcursul procesului și mai puțină gestionare a excepțiilor.

Acum că datele sunt în proces de capturare sau actualizare activă, inteligența artificială poate fi aplicată. Personalul nu trebuie să cunoască toate detaliile și chiar și membrii mai noi pot lucra la cazuri mai complexe, deoarece sistemul utilizează reguli codificate în politici.
logica de a lua automat decizii pe care personalul le trebuia anterior să aibă o pregătire extinsă și experiență pentru a le gestiona. Nu mai faceți greșeli, permițând în același timp supravegherea și chiar verificările de control al calității sau cozile de excepție pentru intervenția manuală, dacă este necesar.

Toate acestea necesită o abordare sistematică. Vechea idee a unui dosar manila care se află într-un sertar pentru membrii personalului pentru portofoliul lor de clienți este depășită și creează un risc inutil. Clienții care sunt procesați în mod izolat pot fi atât limitativi, cât și redundanți
în același timp. Dacă un client corporativ are directori care stau peste mai mulți alți clienți, de ce fiecare recenzie individuală ar ignora imaginea de ansamblu. De asemenea, ai de gând să revizuiești același regizor de mai multe ori în fiecare relație sau ai putea?
faceți-o o dată și reutilizați acele informații în întreaga organizație?

Nici măcar nu trebuie să aibă părți afiliate comune pentru ca beneficiul să fie evident. Industrii similare, clienți clienți similari, ce se întâmplă dacă vânzătorii/furnizorii clienții tăi sunt și ei înșiși clienți? Acest lucru ne aduce la modul în care trebuie să procesați informațiile
și de ce organizațiile trebuie să analizeze întreaga întreprindere atunci când iau în considerare software-ul în zilele noastre. Dacă vedeți o problemă în mod izolat și o tratați ca atare, stabilind bugete și emitând cereri de propuneri pentru fiecare componentă CRM, Fincrime, Client Outreach, veți ajunge
cheltuind mai multe resurse încercând să integreze totul împreună decât orice potențială economisire care s-a sperat inițial. Acum aplicați asta pentru fiecare regiune sau linie de activitate care ar putea primi bugete și supraveghere separate și veți ajunge la 8 versiuni
a aceluiași software care trebuie integrat cu el însuși datorită personalizării puternice pe zonă, eliminând orice economii de scară pe care le-ar putea realiza.

Un dosar într-un sertar care trebuie revizuit anual sau altfel, cu personalul care trebuie să fie instruit ce să facă și când să facă acest lucru. Întreaga revizuire (sau noul onboarding/produs/serviciu suplimentar/etc) poate fi împărțit în părți compozite care pot sau
nu poate fi gestionat de alte persoane/echipe. Sistemul poate determina atunci când o sarcină este finalizată sau când sunt capturate suficiente date pentru a fi trimise următoarei persoane pentru introducerea acesteia. Toate acestea sunt structurate ca cazuri și sub-cazuri în interior. Astfel fiecare element al
cazul poate avea propriul termen limită, cale de escaladare, cesionar și aprobatori. În loc de o sarcină mare pe care un membru al personalului trebuie să aibă suficientă experiență pentru a ști cum să o îndeplinească și la cine să se adreseze pentru diferite elemente din interior, sistemul atribuie acum munca.
și asigură finalizarea sa la timp în întreaga companie cu cât mai multe sarcini automatizate pentru a-i elibera pe factorii de decizie să se concentreze pe ceea ce este important.

Toate acestea sunt bune și bune din punct de vedere al afacerilor. Munca este cunoscută și ce trebuie făcut. Dar când încercăm să decidem dacă ar trebui să cumpărăm sau să construim noi înșine software-ul, cum intră acest lucru în lucruri? Ei bine, să presupunem că există mai multe surse
de date pe mai multe sisteme. Orice sistem modern este de așteptat să fie condus de API și să aibă capabilități de cod redus/fără cod. O presupunere rezonabilă pentru un software mai rapid și flexibil. În zilele noastre, totul trebuie tratat ca un fel de microserviciu de evitat
monoliții software în stil vechi. Software-ul ar trebui să fie instalat și utilizat, deoarece este cel mai bun disponibil și protejat în viitor pentru a se adapta la schimbări după cum este necesar. Prea multe oferte sunt înrădăcinate și menținute doar pentru că sunt prea dificile și consumatoare de timp
a inlocui. Cele mai multe dintre acestea se datorează faptului că regulile sunt codificate greu, probabil împletite cu datele în sine, datele nu sunt doar integrate, ci și replicate de mai multe ori pentru fiecare bucată separată de software din lanțul de informații și dacă încercați să înlocuiți o singură bucată,
întregul sistem s-ar putea rupe. Prea mult din vechiul proces de gândire, dacă nu este rupt, atunci nu-l repara. Ceea ce este cu adevărat necesar este ca toate acele componente să fie microservicii, luând datele necesare, aplicând reguli automate sau intrări/revizuiri ale utilizatorilor și
trecându-l la următorul microserviciu. Datele nu trebuie stocate în mai mult de o locație. Poate fi federat, dar nu poate fi replicat în afara copiilor de rezervă. Sistemele dvs. CRM, Onboarding, KYC, Client Outreach etc. ar trebui să acceseze numai datele de care au nevoie și nu
fie depozite de date în sine, cu excepția cazului în care ați ales unul care să fie. Replicarea acelorași date în mai multe locații și a regulilor care le guvernează este un exercițiu inutil, deoarece fiecare sistem suplimentar adăugat va multiplica complexitățile implicate.

Acest lucru ne duce la considerația finală. Indiferent dacă aveți o singură sursă de adevăr/Copie de aur sau mai multe înregistrări redundante și concurente și sisteme care le pot actualiza, vă veți afla în continuare într-un alt nivel de cerințe bazate pe linia de
afaceri, jurisdicție, tipuri de clienți și produse/servicii. Un individ este tratat diferit față de o companie sau un trust și diferă în funcție de consumator/retail, comercial sau corporație pentru cerințe și adecvare. La cele mai elementare exemple dacă
avem 10 tipuri de clienți (individual – singur, căsătorit, etc., companie privată, companie publică, trust, caritate etc.) și puteți opera în 10 regiuni și puteți oferi 10 tipuri de produse/servicii, suntem deja la posibil peste 1000 de reguli care ar putea
a fi aplicat. Nu ar fi mult mai ușor să definești reguli pentru o regiune, pentru o linie de afaceri, pentru un tip de client și produse sau servicii și să lași sistemul să rezolve cerințele? Eliminarea duplicatelor și reutilizarea punctelor de date care erau anterior
furnizate. Acesta este avantajul abstracției procesului și a regulilor din stratul de date. 

Așa că acum, când luăm în considerare vechea chestiune de cumpărare sau creare de software, știm că avem nevoie de orchestrare omnicanal, automatizare a proceselor acolo unde este posibil, logica flexibilă a regulilor, management de caz pentru supraveghere și auditabilitate, cod redus și bazat pe API, un abstract
strat de date și un motor de reguli inteligent care poate moșteni de la diferite straturi logice. Piața tehnologică este plină de inovatori care satisfac cu plăcere orice problemă de nișă la care se poate gândi, dar în ce moment nu mai are sens să fie „de pe raft”
produse care trebuie personalizate și integrate unele cu altele, în loc să le construiți singur. Platformele cu cod redus vă pot permite să aveți 80% din cerințele dvs. disponibile și trebuie doar să configurați acea delta de 20%. Cel mai bun din ambele lumi este un nivel scăzut
platformă de cod pentru care alții au construit componente reutilizabile, astfel încât să puteți obține produsele „de la raft” ca acceleratoare pentru afacerea dvs., având și capacitatea personalului dvs. sau terților certificati de a construi restul cerințelor specifice
către organizația dumneavoastră. A cumpăra sau a construi? Chiar ar trebui să fie ambele.

Timestamp-ul:

Mai mult de la Fintextra