Mi történik akkor, amikor egy cég eszközei mind működnek, de a vállalkozás mégis lassúnak és bonyolultnak tűnik?
Ez az adatsziló-probléma. Akkor lép fel, amikor az információ elkülönült rendszerekben él, és nem osztozik meg tisztán velük. Az eredmény egy olyan vállalat, amely mindenhol rendelkezik adattal, sehol azonban átlátható képpel.
Kezdetben egy sziló teljesen egyszerű. Egy csapat használ egy eszközt. Egy másik csapat egy mást. Minden rendszer egy helyi szükségletet old meg, így a kialakítás gyakorlatinak tűnik. Az idő múlásával viszont éppen ez a szétválás válik problémává.
A rejtett költség nemcsak technikai jellegű. Az emberek időt pazarolnak arra, hogy ugyanazt a bejegyzést több helyen is ellenőrizzék. A jelentések összeállítása tovább tart. A csapatok vitatkoznak arról, melyik szám a helyes. Az adatokban lévő kis hézagok a bizalom nagyobb hiányába torkollnak.
Éppen ezért olyan kimerítő a rendszerek széttagoltsága. Az eszközök megvannak, de köztük a munka elakad. Egy ügyfél adata lehet, hogy egy CRM-ben, egy számlázási rendszerben, egy ügyfélszolgálati postafiókban és egy Excel-táblázatban él. Egyik sem tartalmazza a teljes történetet.
Hogyan alakult ki ez a probléma
A probléma gyökere régi, még ha az eszközök megjelenése modern is.
Az üzleti szoftverek kezdetben külön osztályokon belül terjedtek el. A pénzügy vásárolt egy rendszert. Az értékesítés egy másikat. Az operatív egység saját folyamatokat épített ki táblázatok és exportfájlok köré. Az információk leggyorsabb mozgatása gyakran kinyomtatással, másolással vagy újragépeléssel valósult meg.
Ez a szokás soha nem tűnt el teljesen. A hardver változott. A felületek változtak. Az alapvető szerkezet ugyanaz maradt. A csapatok ma is először a saját munkájukhoz választanak eszközöket, majd próbálják meg később összekapcsolni őket.
Ezt követték a központosított platformok. Ígéretük egyetlen helyet kínáltak az üzleti információknak. Ez az ígéret logikus volt. Egy közös rendszer kevesebb másolatot, kevesebb hibát és jobb áttekinthetőséget kellene jelentse.
De a nagy rendszerek gyakran új szilókká váltak. Testreszabásuk drága volt. Változtatásuk lassú. Az integrációk nehezen kivitelezhetők, és gyakran szaki támogatásra volt szükség. Nem pedig egy rendezett központot kaptak, hanem sok cég végül egy hatalmas erődítménnyel találta magát szemben.
Aztán a felhőalapú szoftverek megváltoztatták a probléma méretarányát.
A böngészőből futó eszközök megkönnyítették, hogy kisebb csapatok gyorsan fogadják be a szoftvereket. Ez lejjebb vitte a belépési küszöböt. Ugyanakkor könnyebben figyelmen kívül hagyhatóvá tette az alkalmazások robbanásszerű növekedését. Egy csapat hozzáadhatott egy eszközt a marketinghez, egyet az ügyfélszolgálathoz, egyet a jóváhagyási folyamatokhoz, egyet az elemzésekhez, és egyet az űrlapokhoz. Minden eszköz megoldott egy-egy apró fájdalmas pontot.
Eleinte ez haladásnak tűnik. A vállalat rugalmasságot kap. A csapatok gyorsabban haladnak. De amint a szoftverköteg elér több tucat alkalmazást, a kapcsolatok kezelése nehézzé válik. Minden eszköz saját formátumban tárolja az adatokat. Mindegyik saját szerkezetben „beszél”. A varratok elkezdnek szétnyílni.
Egy cég akár száz vagy több felhős alkalmazással is rendelkezhet, és már alig néhány csapat tudja pontosan, hol található a valós adatforrás. Ez nem ritka szélsőséges eset. A modern szoftverterjeszkedés normális arculata ez.
Hogyan érzi meg a széttagoltság a mindennapi munkában
A mindennapi munka általában kusza.
Egy értékesítési képviselő frissít egy potenciális ügyfelet egy rendszerben. Egy ügyfélszolgálati munkatárs egy másikban eltérő kontaktelőzményeket lát. A pénzügy manuális exportra vár a számlák egyeztetése előtt. Közben az operatív csapat fenntart egy „csak a biztos kedvéért” táblázatot, mert a többi eszköz nem elég jól illeszkedik össze.
A fájdalompont nem absztrakt. Ismétlődő munkaként mutatkozik meg. Elavult adatokként. Vagy amikor valaki azt mondja: „a rendszer nem engedi”, pedig a valódi gond az, hogy a rendszerek nem értenek egyet.
Ez a súrlódás nyomást generál a műszaki csapatokon belül is. A képzett állomány végső soron összekötő kódokat, kis szkripteket és egyszeri javításokat ír csak azért, hogy adatot juttasson egyik helyről a másikra. Ez a munka szükséges, de alacsony hatásfokú. Fenntartja a működést anélkül, hogy javítana a fő terméken.
Amikor ezek a csapatok a háttérkapcsolatok építésével vannak elfoglalva, minden más várakozik. Az új funkciók hosszabb ideig készülnek el. A belső kérések torlódásba rendeződnek. A kis hibás folyamatok maradnak hibásak, mert senkinek nincs ideje őket megfelelően kijavítani.
Egy konkrét példa segíthet megérteni ezt.
Képeljünk el egy kis online forgalmazót. A rendelések egy webshopapplikációban érkeznek. Az ügyféladatok egy CRM-ben hevernek. A kiszállítás egy külön logisztikai eszközben fut. Amikor egy ügyfél a fizetés után megváltoztatja a címét, a frissítés nem jut el zökkenőmentesen. Egy csapat látja az új címet. Egy másik a régit. Egy címke hibás adattal nyomtatódik ki, az ügyfélszolgálatnak pedig takarítania kell a baklövést.
Senki a láncban nem hanyag. A probléma a rendszer felépítésében rejlik.
Miért számít itt az automatizálás és az MI
Itt válik igazán értékessé az automatizálás.
Az automatizálási platformok összekötő szövetként szolgálhatnak a széttagolt rendszerek között. Nem törlődik el velük az eszközök közötti különbség. Csökkentik az adatok közötti mozgatásának terhét. Ahelyett, hogy minden csapat a saját kis hídját építené, egy közös folyamat kontrollált módon továbbíthatja az információt egyik rendszerről a másikra.
Ez fontos üzleti és mérnöki szempontból egyaránt.
Az üzleti csapatoknak kevesebb „forgószékes” munkát jelent. Az emberek kevesebb időt töltenek mezők kézi másolásával vagy ütköző adatok ellenőrzésével. A műszaki csapatoknak kevesebb törékeny szkriptet és sürgős javítási feladatot jelent. Nem az újdonság a lényeg. Az alacsonyabb súrlódás.
Az MI akkor adhat második segédkezési réteget, ha az adatok koszosak vagy ellentmondásosak. Besorolhatja a beérkező elemeket, kinyerhet mezőket szövegből, vagy mintázatok alapján irányíthatja a munkát. De az MI önmagában nem javítja ki a sérült architektúrát. Ha az adatterv szétszórt, az MI örökli ezt a szétszórtságot.
Tehát a mélyebb tanulság egyszerű. Az automatizálás akkor a legerősebb, ha meglévő rendszereket köt össze egyértelmű módon. A leggyengébb akkor, ha rossz struktúra betapasztására használják anélkül, hogy a struktúrát megjavítanák.
A gyakorlati modell először a fontos szilók feltérképezése. Melyik rendszer birtokolja az ügyféladatokat. Melyik a számlázást. Melyik az ügyfélszolgálatot. Melyiket kell kezelni az adott adattípusok esetén a valós adatforrásként. Amint ez egyértelmű, az integrációs réteg valós munkát végezhet a találgatás helyett.
Ez magyarázza meg, miért számít a szabályozás. Ha minden csapat a saját privát automatizálását építi, a cég létrehoz egy új típusú árnyék-IT-t. Az eszközök lehetnek modernak, de az eredmény továbbra is ellenőrizetlen szétterülés. A közös szabványok láthatóvá teszik a munkát.
Nem cél mindent egyetlen óriási rendszerbe központosítani. Az gyakran törökké válik. A jobb modell egy összekapcsolt rendszercsoport, tiszta szerepekkel, tiszta átadásokkal és kevesebb másolattal az ugyanazon tényből.
Egy vállalatnak nem kell egyetlen eszközre szüksége, amely uralja a többit. Olyan módra van szüksége, amellyel már meglévő eszközei egyetérthetnek egymással.
Ez a sziló-probléma és a széttagoltság-probléma lényege. Nem csupán a szoftverek számáról szól. Arról is szól, mennyi erőforrást költ a vállalat arra, hogy a különálló rendszerek úgy viselkedjenek, mint egyetlen egész.
Az EuroOp Insights éppen erre a gyakorlati modellre épül, lépésről lépésre, mindig egy-egy konkrét tanulsággal, abból a mérnöki valóságból merítve, amely miatt a széttagolt rendszerekkel nehéz élni, de érdemes őket megjavítani.