Igavene küsimus, kas osta või ehitada oma tarkvara (James Monaghan)

Palju õnne. Teil on probleem, projekt, eelarve ja tähtaeg. Selle asemel, et loopida, on tarkvara lahendus, kuid nüüd peate otsustama, kas ehitada või osta, see on küsimus. Või on? Ma pole enam nii kindel, et see on selge otsus.
Ehitamine viitab maja programmeerijate palkamisele, et kodeerida mis tahes vajalik süsteem, ja ostmine viitab müügil olevatele toodetele, mida saab osta ja käivitada. See oli mõistlik, kui me rääkisime raamatupidamissüsteemidest, kauplemissüsteemidest, CRM-ist, aruandlusest,
Laenamine, kogud, CLM jne. Elame nüüd madala koodiga keskkonnas, kus millegi loomine ei nõua kodeerimiskogemust. Seda saab lohistada. Ühendage see riiulilt ostetud lahendustega, mis on lõpuks nii kohandatud, et võite seda teha
hästi ehitanud. Niisiis, kus see jätab meid otsustama, kas ehitada või osta? Vaatame, mida me tegelikult vajame.

Ükski kaasaegne süsteem ei saa enam tugineda ühele sisenemispunktile. Klientide ootused nõuavad erinevate kanalite olemasolu. Isiklikult, otse telefoni või kõnekeskuse kaudu, e-posti teel, sotsiaalmeedias, SMS-is, veebis, mobiilis, tahvelarvutis – nii mobiilsidetoega kui ka nn.
rakendused, mis kõik peavad olema sisu või konteksti kaotamata vahetatavad. Klient, kes alustab esindusest/poest või isiklikult, kuid peab lahkuma kohtumise ajaks, soovib hiljem samal päeval veebis sisse logides jätkata sealt, kus pooleli jäi. Või
Kui nad alustavad veebis, kuid on pettunud ja kutsuvad abi, ei taha nad protsessi algusest alustada. See kehtib ka sisemiste sidusrühmade kohta. Organisatsioonisisene teabeahel peab olema sama paindlik kui klient, kellega silmitsi seisab
võimalusi. 

Mis siis edasi, kui alustame andmete sisestamist kõikjal? Noh, meil on põhjus, miks me vajame neid andmeid esiteks. Ükskõik, kas uus klient soovib organisatsiooniga koostööd teha, olemasolev klient soovib uut toodet või teenust või isegi lihtsalt igapäevaseid päringuid, kaebusi
või teabepäringud. Kõik need peaksid algama määratletud, kuid paindlike protsessidega, et taotlus võimalikult tõhusalt ja hõlpsalt täita. Protsess on üldiselt määratletud ja tavaliselt koolitatakse töötajaid järgima ülesannete jada, et see etteantud ajaga lõpule viia
teatud andmesisenditel põhinevad toimingud. 

Ei lõpptarbijad ega süsteemikasutajad ei peaks kuskilt teavet uuesti sisestama, kui see on juba kuskilt jäädvustatud. Tegelikult, kui teave on saadaval kõikjal organisatsiooni sees või kolmandatest osapooltest, nagu andmepakkujad, krediidibürood,
sõeluuringu pakkujad jne. see peaks olema kogu protsessi vältel kättesaadav kõigile seda vajavatele kasutajatele. Protsess on määratletud, kuid puutepunktid peaksid olema kogu ulatuses omavahel asendatavad ning kogutud andmed tuleks võimaluse korral integreerida ja võimaluse korral struktureerida.
Rippmenüüd, otsinguväärtused, kuupäevaväljad ja kontrollitud vabateksti väärtused tagavad võimalikult suure andmekvaliteedi. See võimaldab palju rohkem automatiseerimist kogu protsessi vältel ja vähem erandite käsitlemist.

Nüüd, kui andmeid aktiivselt kogutakse või värskendatakse, saab tehisintellekti rakendada. Töötajad ei pea teadma kõiki üksikasju ja isegi uuemad liikmed saavad töötada keerukamate juhtumitega, kuna süsteem kasutab poliitikaga kodeeritud reegleid
loogika, et teha automaatselt otsuseid, mille käsitlemiseks töötajatel pidi varem olema ulatuslik koolitus ja kogemus. Pole enam vigu, võimaldades samal ajal järelevalvet ja isegi kvaliteedikontrolli kontrolle või otseseid erandeid, et vajadusel käsitsi sekkuda.

See kõik nõuab süstemaatilist lähenemist. Vana idee manilla kaustast, mis istub nende kliendiportfelli töötajate sahtlis, on aegunud ja tekitab tarbetut riski. Eraldi töödeldavad kliendid võivad olla nii piiravad kui ka üleliigsed
samal ajal. Kui ärikliendil on direktorid, kes istuvad mitmete teiste klientidega, miks peaks iga individuaalne ülevaade laiemat pilti ignoreerima. Kas vaatate sama direktorit iga suhte kohta mitu korda üle või võiksite seda teha
teha seda üks kord ja kasutada seda teavet kogu organisatsioonis uuesti?

Neil ei pea isegi olema ühiseid seotud osapooli, et kasu oleks ilmne. Sarnased tööstusharud, sarnased kliendid, mis siis, kui teie kliendimüüjad/tarnijad on ka ise kliendid? See viib meid selleni, kuidas peate teavet töötlema
ja miks peavad organisatsioonid tänapäeval tarkvara kaalumisel vaatama kogu ettevõttele. Kui vaatate probleemi eraldi ja käsitlete seda sellisena, koostades eelarved ja väljastades RFP-d iga CRM-i, Fincrime'i ja Client Outreachi komponendi jaoks,
kulutades rohkem ressursse, et kõike integreerida, kui algselt loodetud potentsiaalset kokkuhoidu. Nüüd rakendage seda iga piirkonna või ärivaldkonna jaoks, millel võib olla eraldi eelarve ja järelevalve, ja saate lõpuks 8 versiooni
samast tarkvarast, mis tuleb integreerida iseendaga, kuna piirkonna kohta on palju kohandatud, välistades võimaliku mastaabisäästu.

Sahtlis olev kaust, mis tuleb igal aastal või muul viisil üle vaadata, kus töötajaid tuleb koolitada, mida ja millal teha. Kogu ülevaate (või uue liitumise/lisatoote/teenuse/jne) saab jagada liitosadeks, mis võivad
seda ei tohi käsitleda teised inimesed/meeskonnad. Süsteem saab seejärel määrata, millal ülesanne on lõpule viidud või millal on kogutud piisavalt andmeid, et need saata järgmisele inimesele nende sisestamiseks. Kõik need on struktureeritud juhtumiteks ja alamjuhtumiteks. Sel viisil iga elemendi
juhtumil võib olla oma tähtaeg, eskalatsioonitee, volitaja ja kinnitajad. Selle asemel, et teha üks suur tööülesanne, mida töötajal peab olema piisavalt kogemusi, et teada, kuidas seda täita ja kelle juurde erinevate elementide jaoks pöörduda, määrab süsteem nüüd töö.
ja tagab selle õigeaegse lõpuleviimise kogu ettevõttes võimalikult paljude ülesannete automatiseerimisega, et vabastada otsustajad keskenduma olulisele.

See kõik on ärilisest seisukohast hea. Töö on teada ja mida on vaja teha. Aga kui me proovime otsustada, kas peaksime tarkvara ise ostma või ehitama, siis kuidas see mõjutab asju? Oletame, et allikaid on mitu
andmeid mitmes süsteemis. Eeldatakse, et kõik kaasaegsed süsteemid on API-põhised ja neil on vähe koodi/koodita võimalusi. Mõistlik eeldus kiirema ja paindliku tarkvara jaoks. Tänapäeval tuleb kõike vältida kui mikroteenust
vana stiili tarkvara monoliitid. Tarkvara tuleks installida ja kasutada, sest see on parim saadaolev ja tulevikukindel, et kohaneda vastavalt vajadusele muutustega. Liiga palju pakkumisi on juurdunud ja neid säilitatakse ainult seetõttu, et need on liiga keerulised ja aeganõudvad
asendada. Suurem osa sellest on tingitud sellest, et reeglid on kõvasti kodeeritud, tõenäoliselt põimunud andmete endaga, andmeid mitte ainult ei integreerita, vaid ka paljundatakse mitu korda teabeahela iga eraldiseisva tarkvaraosa jaoks ning kui proovite ühte osa asendada,
kogu süsteem võib puruneda. Liiga palju vanast mõttekäigust, kui see pole katki, siis ärge parandage seda. Tegelikult on vaja, et kõik need komponendid oleksid mikroteenused, mis võtaksid vajalikke andmeid, rakendaksid automatiseeritud reegleid või kasutajate sisestusi/ülevaateid ja
edastades selle järgmisele mikroteenusele. Andmeid ei tohiks salvestada rohkem kui ühes kohas. See võib olla ühendatud, kuid mitte kopeerida väljaspool varukoopiaid. Teie CRM-i, sisselülitamise, KYC-i, Client Outreachi jne süsteemid peaksid juurde pääsema ainult neile vajalikele andmetele, mitte aga
olla ise andmehoidlad, kui te pole seda valinud. Samade andmete ja seda reguleerivate reeglite kordamine mitmes kohas on mõttetu harjutus, kuna iga lisatav süsteem suurendab sellega seotud keerukust.

See viib meid viimase kaalutluseni. Olenemata sellest, kas teil on üks tõeallikas/kuldne koopia või mitu üleliigset ja konkureerivat kirjet ja süsteemi, mis suudavad neid värskendada, leiate end ikkagi teisest nõuetest, mis põhinevad
äri, jurisdiktsioon, klienditüübid ja tooted/teenused. Üksikisikut koheldakse erinevalt ettevõttest või usaldusühingust ning ta erineb tarbija-/jaemüügi-, äri- või ettevõtte ärivaldkonna nõuete ja sobivuse poolest. Kõige elementaarsem näide, kui
Meil on 10 tüüpi kliente (üksikisikud – vallalised, abielus jne, eraettevõte, aktsiaselts, usaldus, heategevus jne) ja te võite tegutseda 10 piirkonnas ja võite pakkuda 10 tüüpi tooteid/teenuseid, oleme juba potentsiaalselt 1000+ reeglit
kohaldada. Kas poleks nii palju lihtsam määratleda reeglid piirkonna, tegevusala, klienditüübi ja toodete või teenuste jaoks ning lasta süsteemil selle asemel nõuded lahendada? Duplikaatide eemaldamine ja varasemate andmepunktide taaskasutamine
ette nähtud. See on eelis, kui võtate oma protsessi ja reeglid andmekihist välja. 

Nüüd, kui me mõtleme tarkvara ostmise või loomise vanale küsimusele, teame, et vajame mitmekanalilist orkestreerimist, võimaluse korral protsesside automatiseerimist, paindlikku reegliloogikat, juhtumihaldust järelevalve ja auditeeritavuse tagamiseks, madala koodi ja API-põhist, abstraktset.
andmekiht ja intelligentne reeglite mootor, mis võib pärida erinevatest loogikakihtidest. Tehnoloogiaturg on täis uuendajaid, kes rahuldavad hea meelega iga nišiprobleemi, millele mõeldakse, kuid millal ei ole enam mõtet, et neid n-ö riiulilt maha võtta
tooteid, mida tuleb ise ehitamise asemel kohandada ja üksteisega integreerida. Madala koodiga platvormid võimaldavad teil saada 80% teie vajadustest ja teil on vaja konfigureerida ainult see delta 20%. Mõlema maailma parim on madal
koodiplatvorm, mille jaoks on ka teised loonud korduvkasutatavad komponendid, et saaksite oma ettevõtte jaoks kiirenditena valmistooteid hankida, samal ajal kui teie töötajad või sertifitseeritud kolmandad osapooled saaksid koostada ülejäänud nõuded.
teie organisatsioonile. Kas osta või ehitada? See peaks tõesti olema mõlemad.