Az örök kérdés, hogy vásárolja meg vagy készítse el a szoftvert (James Monaghan)

Gratulálunk. Van egy problémád, egy projekted, egy költségvetésed és egy határidőd. Ahelyett, hogy feldobná a fejét, a szoftver a megoldás, de most el kell döntenie, hogy épít vagy vásárol, ez a kérdés. Vagy ez? Már nem vagyok benne biztos, hogy ez egy egyértelmű döntés.
A Build kifejezés arra utal, hogy házon belüli programozókat alkalmaznak a szükséges rendszer kódolásához, a vásárlás pedig a megvásárolható és futtatható, már kapható termékekre utal. Ennek volt értelme, amikor számviteli rendszerekről, kereskedési rendszerekről, CRM-ről, jelentéskészítésről,
Kölcsönzés, gyűjtemények, CLM stb. Most alacsony kódú környezetben élünk, ahol valaminek a felépítéséhez nincs szükség kódolási tapasztalatra. Ez lehet drag and drop. Párosítsa ezt a polcról vásárolt megoldásokkal, amelyek végül annyira személyre szabottak, hogy Ön is szeretne
jól megépítették. Tehát ez hol hagy minket abban, hogy meghozzuk a döntést az építkezésről vagy a vásárlásról? Nézzük meg, mire van szükségünk valójában.

Egyetlen modern rendszer sem támaszkodhat többé egyetlen belépési pontra. Az ügyfelek elvárásai azt diktálják, hogy különféle csatornákra van szükség. Személyesen, közvetlenül telefonon vagy call centeren, e-mailen, közösségi médián, SMS-en, weben, mobilon, táblagépen – mobil kompatibilis és natív
alkalmazások, amelyek mindegyikének felcserélhetőnek kell lennie a tartalom vagy a kontextus elvesztése nélkül. Az az ügyfél, aki a fiókban/üzletben vagy személyesen indul, de időpontért kell távoznia, szeretné, ha aznap később online bejelentkezik, ahol abbahagyta. Vagy
Ha online kezdik, de csalódnak és segítséget kérnek, akkor nem akarják, hogy elölről kezdjék a folyamatot. Ez vonatkozik a belső érintettekre is. A szervezeten belüli információs láncnak ugyanolyan rugalmasnak kell lennie, mint az ügyféllel szemben
lehetőségeket. 

Tehát mi a következő lépés, ha elkezdjük az adatbevitelt? Nos, megvan az oka annak, hogy először is szükségünk van ezekre az adatokra. Mindegy, hogy egy új ügyfél szeretne a szervezettel dolgozni, egy meglévő ügyfél új terméket vagy szolgáltatást, vagy akár csak mindennapi kérdéseket, panaszokat
vagy információigénylések. Mindezeknek meghatározott, de rugalmas folyamatokat kell indítaniuk, hogy a kérést a lehető leghatékonyabban és legegyszerűbben teljesítsék. A folyamat általában meghatározott, és általában a személyzetet kiképezik arra, hogy kövesse a feladatok sorrendjét, hogy azt előre meghatározott módon teljesítse
bizonyos adatbevitelen alapuló műveletek. 

Sem a végfelhasználóknak, sem a rendszerfelhasználóknak nem kell sehol újra kulcsolniuk az információkat, ha azokat valahol már rögzítették. Valójában, ha az információ bárhol elérhető a szervezeten belül vagy külső forrásokból, például adatszolgáltatóktól, hitelirodáktól,
szűrési szolgáltatók stb., a folyamat során minden felhasználó számára elérhetőnek kell lennie, akinek szüksége van rá. A folyamat meghatározott, de a kapcsolati pontoknak mindenhol felcserélhetőnek kell lenniük, és az összegyűjtött adatokat lehetőség szerint integrálni kell, és ahol lehetséges, strukturálni kell.
Legördülő menük, keresési értékek, dátummezők és ellenőrzött szabad szöveges értékek a lehető legjobb minőségű adatrögzítés érdekében. Ez sokkal nagyobb automatizálást tesz lehetővé a folyamat során, és kevesebb kivételkezelést tesz lehetővé.

Most, hogy az adatok aktív rögzítése vagy frissítése folyamatban van, a mesterséges intelligencia alkalmazható. A személyzetnek nem kell ismernie minden részletet, és még az újabb tagok is dolgozhatnak bonyolultabb eseteken, mert a rendszer kódolt szabályokat használ
logika, hogy automatikusan hozzanak olyan döntéseket, amelyek kezeléséhez az alkalmazottaknak korábban kiterjedt képzettséggel és tapasztalattal kellett rendelkezniük. Nincs több hiba, miközben lehetővé teszi a felügyeletet és akár a minőség-ellenőrzést is, vagy szükség esetén a kézi beavatkozáshoz szükséges közvetlen kivételsorokat.

Mindez szisztematikus megközelítést igényel. A régi ötlet egy manilla mappáról, amely a munkatársak fiókjában található az ügyfélportfóliójuk számára, elavult, és szükségtelen kockázatot jelent. Az elszigetelten feldolgozott ügyfelek korlátozóak és redundánsak is lehetnek
ugyanabban az időben. Ha egy vállalati ügyfélnek olyan igazgatói vannak, akik több ügyféllel is foglalkoznak, miért hagyná figyelmen kívül az egyes vélemények a nagyobb képet. Ugyanazt a rendezőt többször is felülvizsgálja minden kapcsolatban, vagy megtenné?
csináld meg egyszer, és használd fel újra ezt az információt a szervezetben?

Még csak közös kapcsolt felekkel sem kell rendelkezniük ahhoz, hogy a haszon nyilvánvaló legyen. Hasonló iparágak, hasonló ügyfelek ügyfelek, mi van akkor, ha az Ön ügyfélszállítói/beszállítói maguk is ügyfelek? Ez elvezet minket ahhoz, hogy hogyan kell feldolgoznia az információkat
és miért kell manapság a szervezeteknek a vállalaton áttekinteni, amikor szoftvereket fontolgatnak. Ha egy problémát elszigetelten tekint, és ekként kezeli, költségvetést határoz meg és RFP-t ad ki minden egyes CRM, Fincrime, Client Outreach összetevőhöz, akkor a végén
több erőforrást költenek arra, hogy mindent integráljanak, mint az eredetileg remélt esetleges megtakarítások. Most alkalmazza ezt minden olyan régióra vagy üzletágra, amely külön költségvetést és felügyeletet kaphat, és végül 8 verziót kap.
ugyanazt a szoftvert, amelyet önmagával kell integrálni a területenkénti erős testreszabás miatt, ami kiküszöböli az általuk elérhető méretgazdaságosságot.

Egy mappa a fiókban, amelyet évente vagy más módon át kell tekinteni, és a személyzetet ki kell képezni, hogy mit és mikor kell csinálni. A teljes áttekintés (vagy új bevezetés/kiegészítő termék/szolgáltatás/stb) összetett részekre bontható, amelyek ill.
más személyek/csapatok nem kezelhetik. A rendszer ezután meg tudja határozni, hogy egy feladat mikor fejeződött be, vagy mikor van elegendő adatot rögzítve ahhoz, hogy elküldje a következő személynek. Mindezek esetekként és alesetekként vannak felszerelve. Így minden egyes eleme
az ügynek lehet saját határideje, eszkalációs útvonala, megbízottja és jóváhagyói. Egyetlen nagy feladat helyett, amelyben a munkatársnak elég tapasztaltnak kell lennie ahhoz, hogy tudja, hogyan kell elvégezni, és kihez kell fordulnia a különféle elemekhez, a rendszer most kiosztja a munkát.
és biztosítja annak időben történő befejezését az egész vállalaton belül a lehető legtöbb automatizált feladattal, hogy felszabadítsák a döntéshozókat, hogy a fontosra összpontosítsanak.

Ez mind jó és jó üzleti szempontból. Ismert a munka és a tennivaló. De amikor azt próbáljuk eldönteni, hogy magunknak vásároljuk meg vagy készítsük el a szoftvert, hogyan befolyásolja ez a dolgokat? Tegyük fel, hogy több forrás létezik
adatok több rendszerben. Minden modern rendszernek API-vezéreltnek kell lennie, és alacsony kód/kód nélküli képességekkel kell rendelkeznie. Ésszerű feltételezés a gyorsabb és rugalmas szoftverekre vonatkozóan. Manapság mindent egyfajta mikroszolgáltatásként kell kezelni, hogy elkerüljük
a régi stílusú szoftver-monolitok. A szoftvert telepíteni és használni kell, mert ez a legjobb elérhető és jövőbiztos, hogy szükség szerint alkalmazkodjon a változásokhoz. Túl sok ajánlat van beépítve, és csak azért marad fenn, mert túl nehéz és időigényes
cserélni. Ennek leginkább az az oka, hogy a szabályok kemény kódolásúak, valószínűleg magával az adatokkal fonódnak össze, az adatok nemcsak integrálódnak, hanem többször is replikálódnak az információs lánc minden egyes szoftveréhez, és ha megpróbál egy darabot kicserélni, a
az egész rendszer összeomolhat. Túl sok a régi gondolatmenet, ha nem törött el, akkor ne javítsd. Valójában arra van szükség, hogy ezek az összetevők mikroszolgáltatások legyenek, a szükséges adatokat átvegyék, automatizált szabályokat alkalmazzanak, vagy felhasználói bemeneteket/véleményeket alkalmazzanak.
továbbadja a következő mikroszolgáltatásnak. Az adatokat nem szabad egynél több helyen tárolni. Lehet egyesíteni, de nem replikálható a biztonsági mentéseken kívül. A CRM, Onboarding, KYC, Client Outreach stb. rendszereinek csak a szükséges adatokhoz kell hozzáférniük, és nem
maguk is adattárak legyenek, hacsak nem választott ki egyet. Ugyanazok az adatok több helyen történő replikálása és az erre vonatkozó szabályok hiábavaló gyakorlat, mivel minden hozzáadott extra rendszer megsokszorozza az ezzel járó bonyolultságot.

Ezzel el is érkeztünk a végső megfontoláshoz. Akár egyetlen igazságforrással/Golden Copy-val, akár több redundáns és versengő rekorddal és rendszerrel rendelkezik, amelyek frissíteni tudják őket, akkor is a követelmények egy másik rétegében találja magát, amely a következő követelményeken alapul.
üzlet, joghatóság, ügyféltípusok és termékek/szolgáltatások. Az egyént másként kezelik, mint egy vállalatot vagy tröszt, és a fogyasztói/kiskereskedelmi, kereskedelmi vagy vállalati üzletágak szerint különböznek a követelmények és az alkalmasság tekintetében. A legalapvetőbb példákban ha
10 féle ügyfelünk van (egyéni – egyedülálló, házas stb., magáncég, közvállalat, tröszt, jótékonysági szervezet stb.) és 10 régióban tevékenykedhet, és 10 féle terméket/szolgáltatást kínálhat, már itt tartunk. potenciálisan több mint 1000 szabály
alkalmazni kell. Nem lenne sokkal egyszerűbb szabályokat meghatározni egy régióra, üzletágra, ügyféltípusra és termékekre vagy szolgáltatásokra vonatkozóan, és inkább hagyni, hogy a rendszer oldja meg a követelményeket? Az ismétlődések eltávolítása és a korábban használt adatpontok újrafelhasználása
biztosítani. Ez az előnye annak, hogy a folyamatot és a szabályokat elvonja az adatrétegből. 

Tehát most, amikor figyelembe vesszük a szoftvervásárlás vagy -építés régi kérdését, tudjuk, hogy szükségünk van többcsatornás hangszerelésre, folyamatautomatizálásra, ahol lehetséges, rugalmas szabálylogikára, esetkezelésre a felügyelet és auditálhatóság érdekében, alacsony kód- és API-vezérelt, absztrakt
adatréteg és egy intelligens szabálymotor, amely különböző logikai rétegekből örökölhet. A technológiai piac tele van innovátorokkal, akik örömmel kielégítenek minden felmerülő résproblémát, de mikortól szűnik meg értelmetlen, hogy „lekerüljön a polcról”
termékek, amelyeket testre kell szabni és egymással integrálni, ahelyett, hogy saját kezűleg építenéd. Az alacsony kódú platformok lehetővé teszik, hogy a követelmények 80%-a elérhető legyen, és csak ezt a delta 20%-át kell konfigurálnia. Mindkét világ legjobbja alacsony
kódplatform, amelyhez mások is építettek újrafelhasználható komponenseket, így Ön a „polcról lekerült” termékeket gyorsítóként kaphatja meg vállalkozása számára, miközben munkatársai vagy tanúsított harmadik felei is képesek lesznek a többi követelménynek megfelelően kialakítani.
szervezetének. Vásárolni vagy építeni? Tényleg mindkettőnek kellene lennie.