Összeállítható banki működés

Amikor a 80-as években elkezdtem pályafutásomat a banktechnológiában, kezdetben nagyszámítógépekkel dolgoztam.

Akkoriban voltak „központi üzleti felhasználókból” álló csapataink, amelyek meghatározták követelményeinket. Ezek közvetítők voltak, akik a rendszer tényleges felhasználóit képviselték. Nem volt közvetlen kapcsolatunk a tényleges felhasználókkal.

Néhány évvel később a bank ki akarta próbálni azt, amit ma agilisnak neveznek, de akkoriban a Rapid Application Development volt. A cél az volt, hogy felgyorsítsuk megoldásaink megvalósítását. Mi voltunk az elsők az informatikában, akiket laptopokkal, sőt mobiltelefonokkal is felvérteztünk. Kivittek minket az informatikai irodából, és az egyik üzletágban kaptunk egy irodát.

Ugyanakkor megengedték, hogy otthonról dolgozhassunk, vagy bárhol, ahol úgy éreztük, hogy eredményesek lehetünk. A programom általában az volt, hogy reggel 6-kor ébredek, és 2:6-ig kódolok, majd szünetet ebédelek és egy délutáni evést. Körülbelül 7:XNUMX körül ültem az asztalomnál, és általában éjfélig kódoltam. Ez működött nekem.

Ettől eltekintve, a legnagyobb változás valójában az volt, hogy a végfelhasználók igényeit a fióktelepeken keresztül teljesítették. Ez óriási változást hozott a megoldás használhatóságának és funkcióinak megfelelő kialakításában.

Gyorsan előre 30 évet, és most ez a norma. Az elmúlt 30 évben az üzleti felhasználók és az IT egyre növekvő integrációját tapasztaltuk. Még a szoftverszolgáltatók is elmozdultak egy olyan modell felé, amelyben az ügyfelek mélyen bevonják az új termékeket.

Általában azonban az üzletspecifikus követelményekhez egy elemző dokumentálja, és egy fejlesztő írja meg a kódot. Évtizedek óta ez a modell.

Történtek kísérletek ezen változtatni, hogy az üzleti felhasználókat arra kényszerítsék, hogy saját megoldásaikat alacsony kódú vagy kód nélküli megoldásokkal írják meg. Valójában az utolsó cégem, az edgeIPK úttörő volt egy kód nélküli platform létrehozásában webes/mobilalkalmazások fejlesztésére. A Gartner az ilyen eszközök felhasználóit „polgári fejlesztőknek” nevezi. Ez csökkentette a követelmények és a fejlesztés szétválasztását, de azt merem állítani, hogy sok olyan megoldást generált, amelyek nehezen karbantarthatók és kevés újrafelhasználást eredményeztek. Ezért az ilyen eszközöket vállalati szinten nem igazán használták kritikus fontosságú megoldásokhoz.

Ez azonban megváltozhat az összeállítható banki szolgáltatásokkal, ahol a hangsúly az építőkockák piacról történő fejlesztésén, közzétételén és felhasználásán van, majd lehetővé teszi, hogy valaki más „komponálja” ezeket a blokkokat egy teljes megoldássá. De nyilvánvaló, hogy ez nem ilyen egyszerű. Yefim Natis, a Gartner kiemelkedő alelnöke és kutató munkatársa a következő öt szerepet definiálja az összeállítható banki tevékenységben:

1. Vállalati építész (EA): valaki, aki magas szinten irányítja az általános megoldást, biztosítva a maximális újrahasználatot és a következetességet. A BIAN architektúra jó példa arra, amit egy EA létrehozhat. A BIAN nagyszerű modellt nyújt komponálható „építőelemek” alkalmazásához egy teljes bankarchitektúrához.
2. Alkotók: olyan fejlesztők, akik létrehozzák és közzéteszik az egyéni számítások, funkcionalitás vagy üzleti képesség építőköveit.
3. Kurátorok: az építőelemek „könyvtárának” vagy piacterének menedzselése. Ennek a könyvtárnak tartalmaznia kell minden védett vagy harmadik féltől beszerzett megoldást is.
4. Zeneszerzők: olyan csapatok, amelyek építőkockákból állítanak össze megoldást, alkalmazáskompozíciós platformokat és eszközöket használnak, de nem feltétlenül.
5. Fogyasztók: az alkalmazás tényleges felhasználói.

További részletekért lásd Yefim legutóbbi webináriumát, „A kompozíció alapelvei: Thrive Through Business Change” címmel.

Csak azt mondom, hogy a „komponálható banki tevékenység” nem csak informatikai kérdés, hanem az üzleti felhasználókat is érinti. Ez nem csak szabványos fejlesztés az újrafelhasználási könyvtárral, hanem szervezeti változás, és a cégek küzdeni fognak azért, hogy e váltás nélkül a teljes hasznot lássák.

A múltban a vállalati építész szerepe rendkívül nehéz volt, mivel az üzleti és technológiai alapos ismeretekre volt szükség ahhoz, hogy több száz, ha nem több ezer rendszeren át tudjon szitálni, és egy jobb tájkép tervrajzát tudjon adni. A BIAN ezt rendkívül megkönnyítette, bár a meglévő rendszerek feltérképezése még mindig nem olyan egyszerű.

Amint azt ben kiemeltem előző bejegyzések, az összeállítható banki tevékenység számos problémát megoldhat a bankok számára, de ehhez szervezeti változásra lesz szükség, és egy olyan stratégiával kell támogatni, amely az új szerepkörök által támogatott új munkamódszert oktat és elfogad. Mint mindig, az eszközök és az elmélet készen áll, az ördög a részletekben rejlik. Vannak jó példák arra, hogy szervezetek dolgoznak ezzel, és remélem, hamarosan írok róluk.

A szerzőről

A Dharmesh Mistry több mint 30 éve foglalkozik banki tevékenységgel, és a banki technológia és innováció élvonalába tartozik. A legelső internetes és mobilbanki alkalmazásoktól a mesterséges intelligenciáig (AI) és a virtuális valóságig (VR).

A kerítés mindkét oldalán ott volt, és nem fél megosztani a véleményét.

vezérigazgatója AskHomey, amely a háztartások tapasztalataira összpontosít, valamint befektető és mentor a proptech és fintech területén.

Kövesse Dharmesh-t a Twitteren @dharmeshmistry és a LinkedIn.

Olvassa el az összes „csak azt mondom” töprengését itt.