Muodostettavan pankkitoiminnan saaminen toimimaan

Kun aloitin urani pankkitekniikan parissa 80-luvulla, työskentelin aluksi keskustietokoneiden parissa.

Siihen aikaan meillä oli "pääkonttorin yrityskäyttäjien" ryhmiä, jotka määrittelivät vaatimuksiamme. Nämä olivat välittäjiä, jotka edustivat järjestelmän todellisia käyttäjiä. Meillä ei ollut suoraa yhteyttä varsinaisiin käyttäjiin.

Muutamaa vuotta myöhemmin pankki halusi kokeilla sitä, mitä nykyään kutsutaan ketteräksi, mutta tuolloin se oli Rapid Application Development. Tavoitteena oli nopeuttaa ratkaisujemme toimittamista. Olimme ensimmäiset IT-alalla aseistetut kannettavilla tietokoneilla ja jopa matkapuhelimilla. Meidät vietiin ulos IT-toimistosta ja annettiin toimisto johonkin liiketoimintayksikköön.

Samaan aikaan saimme työskennellä kotoa käsin tai siellä, missä tunsimme voivamme olla tuottavia. Aikatauluni oli tyypillisesti herätä kello 6 ja koodi klo 2 asti, sitten tauko lounaalle ja iltapäivällä. Olin takaisin pöytäni ääressä noin kello 6 ja koodasin yleensä keskiyöhön asti. Tämä toimi minulle.

Tämän lisäksi suurin muutos oli itse asiassa vaatimusten saaminen loppukäyttäjiltä konttoreissa. Tämä vaikutti valtavasti ratkaisun käytettävyyden ja toimintojen saamiseen oikein.

Kelataan 30 vuotta eteenpäin ja tämä on nyt normi. Viimeisten 30 vuoden aikana yrityskäyttäjien ja IT:n integraatio on lisääntynyt. Jopa ohjelmistotoimittajat ovat siirtyneet kohti mallia, jossa asiakkaat ovat syvästi mukana uusissa tuotteissa.

Kuitenkin yleensä yrityskohtaisia ​​vaatimuksia varten analyytikko dokumentoi ne ja kehittäjä kirjoittaa koodin. Tämä on ollut malli jo vuosikymmeniä.

Tätä on yritetty muuttaa, antaa yrityskäyttäjille mahdollisuus kirjoittaa omia ratkaisujaan käyttämällä low-code- tai ei-code-ratkaisuja. Itse asiassa viimeinen yritykseni, edgeIPK, oli edelläkävijä koodittoman alustan luomisessa verkko-/mobiilisovellusten kehittämiseen. Gartner kutsuu tällaisten työkalujen käyttäjiä "kansalaiskehittäjiksi". Tämä vähensi vaatimusten ja kehitystyön eroa, mutta uskallan sanoa, että se synnytti paljon ratkaisuja, joita oli vaikea ylläpitää ja joiden uudelleenkäyttö oli vähäistä. Tällaisia ​​työkaluja ei siis ole juuri käytetty yritystasolla kriittisiin ratkaisuihin.

Tämä saattaa kuitenkin muuttua koottavassa pankkitoiminnassa, jossa painopiste on kehittää, julkaista ja kuluttaa rakennuspalikoita markkinapaikalta ja antaa sitten jonkun muun "kompota" nämä lohkot kokonaiseksi ratkaisuksi. Mutta se ei selvästikään ole niin yksinkertaista. Yefim Natis, Gartnerin arvostettu vara-analyytikko ja tutkija, määrittelee seuraavat viisi roolia yhdistettävässä pankkitoiminnassa:

1. Yritysarkkitehti (EA): henkilö, joka hallitsee kokonaisratkaisua korkealla tasolla varmistaen maksimaalisen uudelleenkäytön ja johdonmukaisuuden. BIAN-arkkitehtuuri on hyvä esimerkki jostakin, mitä EA voi luoda. BIAN tarjoaa erinomaisen mallin komponoitavien "rakennuspalikoiden" soveltamiseen täydelliseen pankkiarkkitehtuuriin.
2. Tekijät: kehittäjät, jotka luovat ja julkaisevat yksittäisen laskennan, toiminnallisuuden tai liiketoimintakyvyn rakennuspalikoita.
3. Kuraattorit: tehtävänä on hallita rakennuspalikoiden "kirjastoa" tai kauppapaikkaa. Tämän kirjaston tulisi sisältää myös kaikki omat tai kolmannen osapuolen hankkimat ratkaisut.
4. Säveltäjät: tiimit, jotka muodostavat ratkaisun rakennuspalikoista käyttämällä sovelluskokoonpanoalustoja ja työkaluja, mutta eivät välttämättä.
5. Kuluttajat: sovelluksen todelliset käyttäjät.

Katso lisätietoja Yefimin äskettäisestä webinaarista "Kompotettavuuden ydinperiaatteet: menesty liiketoiminnan muutoksen kautta".

Sanon vain, että "koostettava pankkitoiminta" ei ole vain IT-kysymys, vaan se koskee myös yrityskäyttäjiä. Se ei ole vain standardikehitystä uudelleenkäyttökirjaston kanssa, se on organisaatiomuutos, ja yrityksillä on vaikeuksia nähdä kaikki hyödyt ilman tätä muutosta.

Aiemmin yritysarkkitehdin rooli oli äärimmäisen vaikea, koska se edellytti vahvaa tietämystä liiketoiminnasta ja teknologiasta, jotta pystyi seulomaan satoja ellei tuhansia järjestelmiä ja laatimaan suunnitelman paremmalle maisemalle. BIAN on helpottanut tätä valtavasti, vaikka olemassa olevien järjestelmien kartoitus ei ole vieläkään niin helppoa.

Kuten olen korostanut aiemmat viestit, koottava pankkitoiminta voi ratkaista useita pankkien ongelmia, mutta se vaatii organisaatiomuutosta ja sitä tulisi tukea strategialla kouluttaa ja omaksua uusi toimintatapa uusien roolien tukemana. Kuten aina, työkalut ja teoria ovat helposti saatavilla, paholainen on yksityiskohdissa. On olemassa vahvoja esimerkkejä organisaatioista, jotka tekevät tämän, ja toivon kirjoittavani niistä pian.

Kirjailijasta

Dharmesh Mistry on ollut pankkialalla yli 30 vuotta ja on ollut pankkiteknologian ja innovaatioiden eturintamassa. Aivan ensimmäisistä internet- ja mobiilipankkisovelluksista tekoälyyn (AI) ja virtuaalitodellisuuteen (VR).

Hän on ollut molemmin puolin aitaa ja hän ei uskalla jakaa mielipiteitään.

Hän on yhtiön toimitusjohtaja KysyKoti, joka keskittyy kotitalouksien kokemuksiin sekä sijoittajaksi ja mentoriksi proptech- ja fintech-palveluihin.

Seuraa Dharmeshia Twitterissä @helsinki ja LinkedIn.

Lue kaikki hänen sanonsa vain tätä.