Bő egy éve tart a járvány, a harmadik hullám után vagyunk.
Már újra nem az a kérdés, hogyan reagálnak gyorsan a cégek a járvány okozta új ügyfélelvárásokra, hanem az, hogyan készültek fel az új, digitálisabb világra, milyen teljesítményt nyújtanak az ügyfeleik irányába? Sokszor az sem egyértelmű, hogy mi egyáltalán a kihívás, amivel szemben állnak a vállalatok. Mi következik most?
Ennyire kontrasztos és vegyes, színes, sokféle megközelítést és minden momentumot egyidejűleg tartalmazó gazdaságot még nem tapasztaltunk korábban. Ez annak is új terep, aki évtizedek óta a szakmában van. Most egy olyan környezet jött létre, ahol nincs egy dominánsan sikeres hozzáállás, módszertan, megközelítés, hanem nagyon sokféle rendszerhez, stílushoz egyszerre kell tudni alkalmazkodni, azok között tudatosan választani és ütemesen váltani.
Régen gyakran mondtuk, hogy ami nem hajlik, az törik. Ezt ma már ki kell egészíteni azzal, hogy ha túlélted, akkor figyelj oda arra, hogy ami nem hajlik, az törik.
A digitalizáció eddigi szakaszában, ha elég sok adattal rendelkeztél, jól lehetett modellezni a jövőt, és a folyamatokat ehhez igazították hozzá a vállalatok. Mindig volt egy legvalószínűbb szcenárió, amire tétet lehetett tenni és többnyire az megvalósult. Ehhez képest most nincs olyan “adatszett”, amely a Covid pandémia utáni kilábalásra és világrendre vonatkozik, az adatelemzés és azokból való döntéshozás képessége szükséges, de önmagában kevés most.
A változtatásra való képesség jelentősége viszont a korábbiakhoz képest is felértékelődött. Emellett a változások amplitúdóját is figyelni kell, mert hektikusabb, volatilisebb a világ, mint eddig és attól, hogy a kicsi hullámot túléljük, nem azt jelenti, hogy a nagyot is túl fogjuk.
Ez a fajta skálázhatóság, az IT-ban többek között a cloud native trendben megtestesül, de ezt valahogy vissza kell csempészni a szervezetbe is, a szolgáltatásokba is, a termékekbe is. Nem elegendő a rugalmasságot a technológia szintjén létrehozni, hiába lehet fel- vagy letekerni a szervereket, ki- vagy bekapcsolni szolgáltatásokat, az ember szintjén is át kell vinni a változásokat. Ez jelenti a valódi paradigmaváltást. A szervezet skálázása, átformálása egyébként évek alatt is kihívást jelentene, de a jövőben ezt meg kell tanulnunk akár hónapok vagy hetek alatt levezényelni.
Digitalizálni, újítani ma már teljesen alapelvárás, a verseny ezt kikényszeríti. A belső és külső innovációs képességek kialakításakor melyek a legfontosabb szempontok? Mennyit változott a nagyvállalati, pénzügyi szektor ezen a területen az utóbbi időben? Hol keresik az újítási lehetőségeket?
Van olyan hazai banki ügyfelünk, ahol tavaly március óta kétharmaddal nőtt a mobilalkalmazás-letöltések száma. Az aktív felhasználók száma a duplájára emelkedett, az aktív tranzakciók száma a másfélszeresére nőtt, de láttunk olyan tranzakciótípust is, ahol négyszeres a szorzó. Először találkoztunk olyan felhasználói kutatásokkal, ahol a bankok ügyfelei közül többen mondták azt, hogy nekik az online csatorna megfelelő működése fontosabb, mint a jó fióki kiszolgálás, ma már nem csak a korai befogadókat szolgáljuk ki digitálisan, hanem egyre nagyobb számban az elutasító, elzárkózó rétegeket is, akiknek a biztonságos és kiszámítható működés mégfontosabb. Ez az a pont, ahol nem szabad nem komolyan venni a digitális csatornákat.
Emellett mivel az üzleti oldalról jövő igények száma, komplexitása is folyamatosan növekszik, minden bank és talán minden nagyvállalat törekszik jelenleg arra, hogy házon belül építse ki a digitális fejlesztési kompetenciát, de ennek gyakran akadályai vannak. Ilyen akadály lehet a gyártási csúcsok kialakulása, a nem állandóan szükséges technológiák és eszközök szakértői támogatásának kihívásai, illetve általában az új tapasztalatok beépítésének nehézsége. Egy frissen felállított csapatban sok kockázat rejlik, de a legfontosabb, hogy ha egyszerre változik minden: transzformáció, kultúra, folyamatok, eszközök, akkor nehéz megítélni problémás teljesítés esetén, hogy a csapat jól működik-e vagy sem.
Ezek nem áthidalhatatlan problémák. Egyrészt ma már körül tudják venni magukat a vállalatok specializált, tapasztalt szakértői beszállítókkal, úgy hogy, a rendszerek már lehetővé teszik azt is, hogy a külsősök is teljesértékű hozzájárulók legyenek bármilyen projekthez, napi szinten együtt élve a céggel. Másrészt a módszertani igazítással is sokat lehet segíteni:
a nagy stratégiai célok lobogtatása mellett a fejlesztői munka napi szintjére is le kell vinni az üzlet legelemibb kulcsmérőszámait.
Nem mágia, néha elég, ha a csapat felett lóg a falon egy tévé és valós időben kiírjuk nekik, hogy per pillanat hogyan alakul a regisztrációk, konverziók, ügyfélakvizíciók vagy visszafordulások száma. Sokszor két hetes sprinten belül is bele tudtak nyúlni és javítani valamin, napon belül is látják, ha nem jó irányba indultak el. A tapasztalt és “betanuló” fejlesztők közös munkája és a valódi célok teljesülésének közelhozása pedig képes a tanulási folyamatokat rendkívüli módon felgyorsítani.
Az agilis transzformáció ennek ellenére sokszor halad nehezen, tudunk tipikus hibát mondani, amin akár múlhat is az ügyfélélmény alakulása?
Van egy erős kényszer új megoldások szállítására és gyakran azt tapasztaljuk, hogy a szereplők ugyan mondják, hogy ők nagyon agilisan terveznek, mégse látszik eredmény. Egy év alatt már a 20. koncepciót gyártják le, de még mindig nem elég jó az ötlet - az ügyfelek pedig egyre türelmetlenebbek és egyre elégedettlenebbek. Ha valaki sokmindent kipróbál, de nem jut előre, azt nem nevezném agilitásnak, hanem egyszerűen csak rossz tervezésnek.
Alkalmazkodásra hivatkozva tettek nélkül elfüstölni a pénzt semmilyen módszertanban nem jó.
Hiányolom az olyan technikák elterjedését, melyek a gyors próbálkozást és visszamérést együtt valósítják meg nagyvállalati környezetben. Fontos lenne úgy tekinteni, hogy minden, amit hozunk az egy hipotézis, javaslat, amit az ügyfelekkel együtt el kell kezdeni folyamatosan validálni. Én mindenkit arra biztatok, hogy merjük bátran kihasználni a digitális világ előnyeit, például a konténerizációt: gyorsan tudunk rendszereket építeni, telepíteni, újrahúzni, cserélni, szegmenseket tudunk kezelni, A-B tesztelés már alapműködés.
Az agilis gondolkodásnak része az, hogy végtelen számú ötlet közül ki tudunk választani néhányat, azokat megvalósítjuk és hajlandóak is vagyunk visszamérni, hogy az előző verzióhoz képest a kulcs mérőszámokra vetítve javult vagy romlott az eredmény. Az újat mindig meg kell birkóztatni az előző, aktuálisan működő verzióval, ha javult a helyzet, akkor megtartjuk az újat és továbbvisszük, ha romlott, akkor kidobjuk.
Ezt hívjuk validáción keresztüli előrelépésnek, ahol mindig van mozgás, haladás, de mindig meg lehet kérdőjelezni bármely részletet. Erről bővebben Eric Ries: Lean Startup című könyvében érdemes olvasni, nagyon sok feleslegesen elégetett erőforrást lehet megspórolni ezekkel a gyakorlatokkal. A gyors validációhoz pedig a mostani frontend szoftverek tökéletesen alkalmasak, egy nagyobb ügyfélbázis kisebb részein lehet nem csak startupoknak, de vállalatoknak is próbálkozni, nem véletlenül így dolgoznak a nagy amerikai bigtech cégek is.
Jellemző példa, hogy megújulnak a netbankok, mobilbankok, ügyfélkapcsolati felületek, az ügyfelek pedig a változást gyakran rossz néven veszik, az értékelések mélybe hullanak az alkalmazás áruházakban, sok a panasz. Hogyan lehet ezt elkerülni? Mitől lesz simább egy termékbevezetés? Tud ezen segíteni az agilis fejlesztés?
Az utóbbi 20 évben valóban szinte csak ilyen tapasztalatunk van: bármikor bármit változtatunk, az mindig megosztja a társadalmat, a közönséget. Lesz, aki rajongani fog érte, mert pont eltaláltuk az igényeit, de hangosabbak lesznek azok, akik alapvetően nem szeretik a változást, mert végre valahogy megtanulta, átszenvedte magát a korábbi felületeken és most nem boldog.
Erről a nappalim jut eszembe, ha azt mondja a feleségem, hogy teljesen át kellene alakítani, mindent arrébb mozgatunk, akkor valószínűleg ellenállásba ütközne nálam, megpróbálnám valahogy puhítani ezt az igényt. Viszont, ha három év alatt apránként csempészi be a változásokat, először kicserélődik a kanapé, az asztal, akkor különös ellenállás nélkül helyet cserélhet lassan minden.
Hasonlóképpen lehet eljárni szoftverekkel is, nem feltétlenül csak gigantikus változásokkal lehet jó eredményeket elérni.
Mivel az ügyfelek nagyon gyorsan tudnak szolgáltatót váltani, ha nagy mértékben nyúlunk hozzá a felületekhez, akkor az elvándorlás, lemorzsolódás esélye is magasabb lesz. A nagyon apró, folyamatos változások sokkal kevésbé fájdalmasak a végfelhasználónak. Ezt a taktikát látjuk ma már a legnagyobb szoftvergyártóknál is sok éve. Nincs új Chrome, de közben észrevette valaki, hogy már a 90. főverziónál járunk? Természetesen vannak olyan felületek, amiket már nem lehet módosítani, ezt a békát le kell nyelni, de ahol csak tudunk, érdemes folyamatos próbálgatásokkal, tesztelésekkel, validációkkal kitapasztalni, hogy mit hova helyezzünk át. Szállítóként is ez az egyik legfontosabb érték, amire törekszünk: képesnek lenni a gyors, sorozatos átalakulásra és nem egy merev rendszert “tolni” az ügyfelek felé.
A hazai bankszektornak, a sok ügyféllel rendelkező nagyvállalatoknak mindig érdemes követniük az előttük járó nemzetközi úttörőket? Hibáznak-e egyáltalán a globális szereplők vagy mindig az ő megoldásuk lesz a zsinórmérték?
Mindenféleképpen figyelni kell őket, hiszen a legtöbb meglátás és ötlet náluk landol, a nagy felhasználói szám és a végtelennek tűnő erőforrás szerepét nehéz elvitatni. Ha megnézzük, hogy a magyar bank- és biztosítói piac mennyit költ erre összesen, és mennyit egy óceánon túli szolgáltató, akkor látszik, hogy egy vagy több nagyságrenddel magasabb utóbbiak büdzséje. De ennek ellenére tudatosan kell választani az ötletek között, nem minden automatikusan jobb.
Egyszerű, de fájdalmas példa az utóbbi időben a Google arculati ráncfelvarrása, melynek során többek közt az alkalmazások ikonszettjét is kicserélték. Itt valószínűleg egy meghatározó döntéshozó nagyon szerelmes lehet ebbe a stílusba, a dizájner csapatok pedig eltűrték ezt és az összes ikont ugyanolyan stílusúvá alakították át. Eredmény? Odapillantva nem tudom megkülönböztetni a Google Mapset a Gmailtől és másodperceket veszítek minden interakción. És ez nem átmeneti, már eltelt fél év, és még mindig nem lett jobb érzésem ezzel kapcsolatban.
A másik hasonló negatív példa, hogy megjelent a Revolut új verziója egy új stílussal, ami önmagában nagyon szép, elegáns, modern, megfelel mindenféle kritériumnak, de már hetek óta nehezen tudom megtalálni a kártyát, csak akkor, ha elolvasom a gombon a szöveget, mert annyira egyformák lettek az alkalmazáson belüli felületek. Ez jó példa arra, hogy ha valamit túlzásba viszünk, az többnyire sajnos visszafelé sül el.
Mekkora szerepe van rugalmas működésben a rendszerarchitektúrának, a háttérben dolgozó IT-csapatoknak? Hogyan lehet nagy, legacy IT-rendszerek mellett is jól, gyorsan kiszolgálni online az ügyfeleket? Milyen stratégiákat követnek a vállalatok ebben?
A legacy IT nem mindig átok, hanem gyakran áldás: régi, de még mindig stabilan működő rendszerekről beszélünk, amelyeknek az eddigi sikereket köszönhetjük. Ha mégis az újabbnál újabb rendszerek is hamar haszontalanná válnak, az inkább a mi hozzáállásunk miatt van. Sokat lehet spórolni, ha tudunk javítani a folyamatokon, magunkon. A core rendszereket inkább az egyszerűség felé visszük, a változásokat pedig a köztes rétegben, egy másfajta logikával, nagy számban és gyorsan telepíthető mikroszolgáltatásokkal valósítjuk meg.
Ez egyfajta bimodális működést hoz magával, az architektúra egy részének az üzembiztonság az elsődleges szempontja, ez lassabban változik, pont azért, mert az üzembiztonságot féltve próbálják a változásokat minimalizálni. Ennek a hozzáállásnak ugyanúgy benne kell lenni egy szervezetben, egy bankban vagy egy pénzügyi intézetben, mint annak, hogy változzunk gyorsan.
Minél közelebb vagyunk a frontend felületekhez, annál gyorsabbnak kell lennie a változási képességnek. Minél beljebb vagyunk a core rendszerekben, annál óvatosabbnak és lassabbnak kell lenni, mert ott ki lehet rúgni egy olyan tartóoszlopot, amitől össze tud dőlni az egész épület. Sem az agilitás, sem egy stabilan tartott legacy IT rendszer nem jó válasz mindenre, mind a kettőre szükség van a megfelelő helyeken.
A nagyvállalati környezet is érzékeny a trendekre, előfordul, hogy elkészült az új rendszer egy kimerítő service design alapú projektben, design thinking gondolkodás mentén agilis módszertanokkal, de a bevezetés után azt tapasztalták, hogy néhány hét után ismét mindenki a régi “DOS-os” őskövületet használja. Miért? Mert sokkal gyorsabb, mint az új.
A használhatóság is egy szempont és a szépség is egy szempont és a performance is egy szempont. Ha az energia arra ég el, hogy jól nézzen ki a felület, akkor könnyen lyukra lehet futni a valódi funkció terén. Túlzás csak performance, csak UX vagy csak folyamat szinten gondolkodni. Ha mániákusan UX fókusz van, akkor valószínűleg nem fog jól működni a rendszer, de ha kizárólag mérnöki mindset kap teret, akkor funkcionálisan rendben lesz, de senki nem szereti majd használni. Holisztikusan kell nézni ezeket a területeket. A feladat akkor van készen, ha minden szempont érvényesült, de egyiket sem vittük túlzásba.
