Ikuinen kysymys ohjelmiston ostamisesta vai rakentamisesta (James Monaghan)

Onnittelut. Sinulla on ongelma, projekti, budjetti ja määräaika. Sen sijaan, että heittäisit vartaloa, ohjelmisto on ratkaisu, mutta nyt sinun on päätettävä rakentaa tai ostaa, se on kysymys. Vai onko se? En ole enää niin varma, että se on selvä päätös.
Rakenna käyttö viittaa talon ohjelmoijien palkkaamiseen koodaamaan mikä tahansa tarvittava järjestelmä, ja osta viittaa valmiisiin tuotteisiin, joita voitiin ostaa ja käyttää. Tämä oli järkevää, kun puhuimme kirjanpitojärjestelmistä, kaupankäyntijärjestelmistä, CRM:stä, raportoinnista,
Lainaus, kokoelmat, CLM jne. Elämme nyt matalan koodin ympäristössä, jossa jonkin rakentaminen ei vaadi koodauskokemusta. Se voidaan vetää ja pudottaa. Yhdistä se hyllyltä olevien ratkaisujen ostamiseen, jotka lopulta ovat niin räätälöityjä, että saatat haluta
hyvin ovat rakentaneet sen. Joten missä se jättää meidät tekemään päätöksen rakentaa tai ostaa? Katsotaanpa mitä todella tarvitsemme.

Mikään nykyaikainen järjestelmä ei voi enää luottaa yhteen tulopisteeseen. Asiakkaiden odotukset sanelevat, että erilaisia ​​kanavia tarvitaan. Henkilökohtaisesti, puhelimitse tai puhelinkeskuksessa, sähköpostilla, sosiaalisessa mediassa, tekstiviestillä, webissä, matkapuhelimessa, tabletissa – sekä mobiililaitteisiin että alkuperäisiin
sovelluksia, joiden kaikkien on oltava keskenään vaihdettavissa sisältöä tai kontekstia menettämättä. Asiakas, joka aloittaa konttorista/myymälästä tai henkilökohtaisesti, mutta joutuu lähtemään tapaamiseen, haluaa jatkaa siitä mihin jäi, kun kirjautuu myöhemmin samana päivänä verkkoon. Tai
Jos he aloittavat verkossa, mutta turhautuvat ja kutsuvat apua, he eivät halua aloittaa prosessia alusta. Tämä koskee myös sisäisiä sidosryhmiä. Organisaation sisäisen tietoketjun on oltava yhtä joustava kuin asiakkaan edessä
vaihtoehtoja. 

Mitä seuraavaksi aloitamme tietojen syöttämisessä missä tahansa? No, meillä on syy, miksi tarvitsemme nämä tiedot ensinnäkin. Haluaapa uusi asiakas työskennellä organisaation kanssa, olemassa oleva asiakas uuden tuotteen tai palvelun tai vaikka vain jokapäiväisiä tiedusteluja, valituksia
tai tietopyyntöjä. Kaikista näistä tulee aloittaa määritellyt mutta joustavat prosessit, jotta pyyntö voidaan suorittaa mahdollisimman tehokkaasti ja helposti. Prosessi on yleensä määritelty, ja yleensä henkilökunta on koulutettu seuraamaan tehtäväsarjaa sen suorittamiseksi ennalta määrätyllä tavalla
tiettyihin tietoihin perustuvia toimia. 

Loppukäyttäjien tai järjestelmän käyttäjien ei pitäisi joutua näppäilemään tietoja uudelleen minnekään, jos ne on jo tallennettu jonnekin. Itse asiassa, jos tietoa on saatavilla missä tahansa organisaatiossa tai kolmannen osapuolen lähteistä, kuten tiedontarjoajista, luottotoimistoista,
seulontapalvelujen tarjoajat jne. sen pitäisi olla kaikkien sitä tarvitsevien käyttäjien saatavilla koko prosessin ajan. Prosessi on määritelty, mutta kosketuspisteiden tulisi olla keskenään vaihdettavissa kaikkialla, ja kerätyt tiedot tulisi integroida mahdollisuuksien mukaan ja jäsenneltyä mahdollisuuksien mukaan.
Pudotusvalikot, hakuarvot, päivämääräkentät ja ohjatut vapaan tekstin arvot varmistavat mahdollisimman hyvän tiedonlaadun kaappaamisen etukäteen. Tämä mahdollistaa paljon enemmän automatisointia koko prosessin aikana ja vähemmän poikkeusten käsittelyä.

Nyt kun dataa kerätään tai päivitetään aktiivisesti, tekoälyä voidaan soveltaa. Henkilökunnan ei tarvitse tietää kaikkia yksityiskohtia ja jopa uudemmat jäsenet voivat käsitellä monimutkaisempia tapauksia, koska järjestelmä käyttää käytäntökoodattuja sääntöjä
logiikkaa tehdä automaattisesti päätöksiä, joiden käsittelyssä henkilöstöllä oli aiemmin oltava laaja koulutus ja kokemusta. Ei enää virheitä, mutta mahdollistaa myös valvonnan ja jopa laadunvalvontatarkastukset tai suorat poikkeusjonot tarvittaessa manuaalista toimenpiteitä varten.

Tämä kaikki vaatii systemaattista lähestymistapaa. Vanha idea manillakansiosta, joka istuu henkilökunnan laatikossa heidän asiakasportfoliolleen, on vanhentunut ja luo tarpeettoman riskin. Erikseen käsiteltävät asiakkaat voivat olla sekä rajoittavia että tarpeettomia
samaan aikaan. Jos yritysasiakkaalla on johtajia, jotka edustavat useita muita asiakkaita, miksi jokainen yksittäinen arvostelu jättäisi huomiotta kokonaiskuvan. Aiotteko myös arvioida samaa johtajaa useita kertoja kaikissa suhteissa vai voisitko?
tehdä se kerran ja käyttää tietoja uudelleen koko organisaatiossa?

Heillä ei edes tarvitse olla yhteisiä lähipiiriin, jotta hyöty olisi ilmeinen. Samanlaiset teollisuudenalat, samanlaiset asiakasasiakkaat, entä jos asiakastoimittajasi/toimittajasi ovat myös itse asiakkaita? Tämä vie meidät siihen, kuinka sinun tulee käsitellä tietoja
ja miksi organisaatioiden on nykyään tarkasteltava koko yritystä harkitessaan ohjelmistoja. Jos tarkastelet ongelmaa erillään ja käsittelet sitä sellaisenaan, määrität budjetteja ja annat tarjouspyyntöjä jokaiselle CRM-, Fincrime- tai Client Outreach -komponentille, päädyt
käyttää enemmän resursseja kaiken yhdistämiseen kuin mitä tahansa mahdollista säästöä, jota alun perin toivottiin. Käytä nyt sitä jokaiselle alueelle tai toimialalle, joka saattaa saada erilliset budjetit ja valvonnan, niin saat 8 versiota
samasta ohjelmistosta, joka on integroitava itsensä kanssa, koska aluekohtaista räätälöintiä on paljon, mikä eliminoi niillä saavutettavat mittakaavaedut.

Laatikossa oleva kansio, joka on tarkistettava vuosittain tai muuten, ja henkilökuntaa on koulutettava, mitä tehdä ja milloin. Koko arvostelu (tai uusi käyttöönotto/lisätuote/palvelu/jne.) voidaan jakaa yhdistelmäosiin, jotka voivat
muut ihmiset/ryhmät eivät saa käsitellä niitä. Järjestelmä voi sitten määrittää, milloin tehtävä on suoritettu tai milloin tarpeeksi tietoa on kerätty lähetettäväksi seuraavalle henkilölle heidän syötettäväksi. Kaikki nämä on jäsennelty tapauksiksi ja alitapauksiksi. Tällä tavalla jokainen elementti
tapauksella voi olla oma määräaika, eskalaatiopolku, toimeksiantaja ja hyväksyjät. Yhden suuren tehtävän sijaan, jonka työntekijän on oltava tarpeeksi kokenut tietääkseen, miten suorittaa ja kenen puoleen kääntyä eri elementtien suhteen, järjestelmä jakaa nyt työn.
ja varmistaa sen nopean valmistumisen koko yrityksessä mahdollisimman monilla automatisoiduilla tehtävillä vapauttaen päättäjät keskittymään olennaiseen.

Tämä on kaikki hyvin ja hyvin liiketoiminnan näkökulmasta. Työ on tiedossa ja mitä pitää tehdä. Mutta kun yritämme päättää, pitäisikö meidän ostaa vai rakentaa ohjelmisto itse, miten se vaikuttaa asioihin? Oletetaan, että lähteitä on useita
dataa useissa järjestelmissä. Kaikkien nykyaikaisten järjestelmien odotetaan olevan API-ohjattuja ja niillä on vähän koodia/ei koodia ominaisuuksia. Kohtuullinen oletus nopeammasta ja joustavasta ohjelmistosta. Kaikkea nykyään on käsiteltävä eräänlaisena mikropalveluna välttää
vanhan tyylin ohjelmistomonoliitit. Ohjelmisto tulee asentaa ja käyttää, koska se on paras saatavilla oleva ja tulevaisuuden varma mukautumaan muutokseen tarpeen mukaan. Liian monet tarjoukset ovat juurtuneet ja niitä ylläpidetään vain, koska ne ovat liian vaikeita ja aikaa vieviä
Korvata. Suurin osa tästä johtuu siitä, että säännöt on koodattu, luultavasti kietoutunut itse tietoihin, tiedot eivät ole vain integroituja, vaan myös replikoituvat useita kertoja jokaiselle tietoketjun erilliselle ohjelmistolle, ja jos yrität korvata yhden osan,
koko järjestelmä voi hajota. Liikaa vanhaa ajatusprosessia, jos se ei ole rikki, älä korjaa sitä. Se, mitä todella tarvitaan, on, että kaikki komponentit ovat mikropalveluita, jotka ottavat tarvittavat tiedot, soveltavat automaattisia sääntöjä tai käyttäjien syötteitä/arvosteluja ja
välittää sen seuraavalle mikropalvelulle. Tietoja ei saa tallentaa useampaan kuin yhteen paikkaan. Se voi olla yhdistetty, mutta ei replikoitu varmuuskopioiden ulkopuolella. CRM-, Onboarding-, KYC-, Client Outreach- jne. -järjestelmien tulisi käyttää vain tarvitsemiaan tietoja, ei
olla itse tietovarastoja, ellet ole valinnut sellaista. Saman tiedon replikointi useissa eri paikoissa ja sitä säätelevien sääntöjen mukaan on turhaa harjoitusta, sillä jokainen lisätty järjestelmä moninkertaistaa asiaan liittyvät monimutkaisuudet.

Tämä vie meidät viimeiseen harkintaan. Riippumatta siitä, onko sinulla yksi totuuden lähde/kultainen kopio tai useita redundantteja ja kilpailevia tietueita ja järjestelmiä, jotka voivat päivittää ne, löydät silti itsesi toisesta vaatimuksista, jotka perustuvat
liiketoiminta, lainkäyttöalue, asiakastyypit ja tuotteet/palvelut. Yksilöä kohdellaan eri tavalla kuin yritystä tai luottamusta, ja hän eroaa kuluttajan/vähittäiskaupan, kaupallisen tai yrityksen toimialoista vaatimusten ja soveltuvuuden suhteen. Esimerkeistä alkeellisimmillaan jos
meillä on 10 asiakastyyppiä (yksityisasiakkaita – sinkku, naimisissa jne., yksityinen yritys, julkinen yhtiö, säätiö, hyväntekeväisyysjärjestö jne.) ja voit toimia 10 alueella, ja saatat tarjota 10 erilaista tuotetta/palvelua, olemme jo osoitteessa mahdollisesti yli 1000 sääntöä
soveltaa. Eikö olisi niin paljon helpompaa määritellä säännöt alueelle, toimialalle, asiakastyypille ja tuotteille tai palveluille ja antaa järjestelmän sen sijaan ratkaista vaatimukset? Kaksoiskappaleiden poistaminen ja aikaisempien tietopisteiden uudelleenkäyttö
tarjotaan. Tämä on etu prosessin ja sääntöjen poistamisesta tietokerroksesta. 

Joten nyt kun tarkastelemme vanhaa kysymystä ohjelmistojen ostamisesta tai rakentamisesta, tiedämme, että tarvitsemme monikanavaista orkestrointia, prosessien automatisointia mahdollisuuksien mukaan, joustavaa sääntölogiikkaa, tapausten hallintaa valvontaa ja tarkastettavuutta varten, alhaista koodia ja API-pohjaista, abstraktia.
tietokerros ja älykäs sääntömoottori, joka voi periä eri logiikkakerroksista. Teknologiamarkkinat ovat täynnä innovaattoreita, jotka tyydyttävät mielellään kaikki niche-ongelmat, joita voidaan ajatella, mutta missä vaiheessa se lakkaa olemasta järkevää saada "hyllystä"
tuotteet, jotka kaikki on räätälöitävä ja integroitava toisiinsa sen sijaan, että rakentaisit ne itse. Matalakoodialustat voivat antaa sinulle 80 % vaatimuksistasi saatavilla, ja sinun tarvitsee vain määrittää tämä delta 20 %. Molempien maailmojen paras on alhainen
koodialusta, jolle muut ovat myös rakentaneet uudelleenkäytettäviä komponentteja, jotta voit saada "hyllystä" saatavia tuotteita yrityksesi kiihdyttiminä ja samalla henkilöstölläsi tai sertifioiduilla kolmansilla osapuolilla on mahdollisuus rakentaa loput vaatimukset.
organisaatiollesi. Ostaa vai rakentaa? Sen pitäisi todellakin olla molempia.