Bevezetés

Az 1. és a 2. rész azt mutatta be, hogyan mentették meg a helyi csapatokat rövid távon az EUC és a Kami Excel, miközben hosszú távú adóssággal terhelték meg a szervezetet. Ebben a részben a jelenre fordítjuk a figyelmet, és megvizsgáljuk a modern citizen-fejlesztési platformok fényét és árnyékát – az RPA-t, valamint a no-code/low-code eszközöket.

Ugyanazt a történetet játsszák újra, mint a Kami Excel, csak nagyobb léptékben és szorosabb bilincsekkel. A következő részben tárgyalt generatív AI megértéséhez először fel kell térképeznünk a mai eszközök természetét.

Háttér: Japánban a 2010-es évek végén a „munkastílus-reform” és a tartós túlórázás miatt az RPA lett a jelszó. Az értékesítők azt ígérték, hogy mérnöki tudás nélkül is automatizálható az adminisztráció, és a vezetők gyors megfelelési megoldást láttak benne. A társadalmi-jogi környezet miatt az ország gyorsabban – és gyakran naivabban – karolta fel az RPA-t, mint sok nyugati piaci szereplő.

A teljes sorozat

  • A citizen fejlesztés jövője – történelem, jelen, generatív AI és ami azon túl van (0/7) (magyarul még nem érhető el)
  • A citizen fejlesztés az EUC visszatérése? – Tanulságok a Kami Excelből (1/7) (magyarul még nem érhető el)
  • Kami Excel volt a valódi bűnbak? – A megmentőtől a negatív örökségig (2/7) (magyarul még nem érhető el)
  • A modern citizen-fejlesztési platformok fény- és árnyoldalai (3/7) (jelen cikk)
  • Mit ment meg, és mit hagy hátra a generatív AI? (4/7)
  • A citizen fejlesztés nem mindenható – „piszkozat-fejlesztés” (5/7)
  • Félrecsúszott nézőpontok tömegével termelik a negatív örökséget (6/7) (magyarul még nem érhető el)
  • A legacy tovább születik – mégis meg lehet zabolázni: jövőkép a citizen fejlesztésről (7/7) (magyarul még nem érhető el)

A fény – miért hódították meg a szervezeteket

Azonnali eredmények

GUI-n keresztül, kódírás nélkül lehet kisebb automatizációkat vagy alkalmazásokat összerakni. Ha napok alatt kiváltják a napi adatmásolást vagy a monoton feladatokat, az a frontvonal számára kézzelfogható könnyebbség.

A vizualizáció meggyőző ereje

Az áramlási diagramok és képernyőtervek mindenki számára könnyen értelmezhetők. A vezetők szó szerint „látják” a működő mintát, ami megnyugtatja őket, és felgyorsítja a jóváhagyást.

Az első állomás a „polgároknak”

Szűk felhasználási kör – például bevitel űrlapokon vagy könnyű munkafolyamatok – mellett valóban képesek nem mérnökök is működő megoldást építeni. Így a szervezet szélesebb körben tudja bevonni az embereket a citizen fejlesztésbe.

Árnyék (1) – a szakmai fal

Hiába az ígéret, hogy „bárki meg tudja csinálni”, komoly használatnál ugyanaz a gondolkodás kell, mint a szoftvermérnökségben.

  • A vezérlési szerkezetek elkerülhetetlenek. Ügyfélfüggő elágazásoknál feltételek kellenek; több száz rekord feldolgozásához ciklusok; az API késleltetésekhez és hibákhoz expliciten kell hibakezelést adni. A drag-and-drop elemek mögött ez mind programozás.

  • Számítanak az adatszerkezetek. JSON-t kell kibontani, hierarchikus adatot leképezni, dátumokat és számokat normalizálni. Ha valaki csak táblaszerűen gondolkodik, struktúra-ismeret nélkül összeomlik a megoldás.

  • A rendszerekkel való integráció továbbra is nehéz. Token lejárat, rendszerek közötti konzisztencia, kéréslimit – ugyanazok a klasszikus problémák, csak a felület mögé rejtve.

  • Az üzemeltetési és minőségi követelmények megmaradnak. Felügyelet, naplózás, környezetek egységesítése, visszagörgetés – ha nincs üzemeltetési terv, gyorsan káosz lesz. A logika GUI-elemekbe zárva gyakran rontja az átláthatóságot is.

Ezzel a fallal szembesülve a citizen fejlesztők ritkán tudnak önállóan termelési szintű rendszert építeni és fenntartani. A specialisták nélkülözhetetlenek maradnak, így az eredeti kapacitásprobléma nem oldódik meg.

Árnyék (2) – vendor lock-in és a migrációs fájdalom

A Kami Excel legalább fájlban élt. Az adatok exportálhatók voltak CSV-be, a képletek – bár kuszák – áttekinthetők maradtak. A modern RPA vagy no-code/low-code eszközök ezzel szemben platformspecifikus felületekben és konfigurációkban rekednek.

  • Szállítóváltáskor jellemzően mindent elölről kell építeni.
  • Egy SaaS leállása vagy módosított specifikációi kívül esnek az ügyfél kontrollján, és egy éjszaka alatt nullázhatják a felhalmozott értéket.
  • A PaaS megoldások egy adott felhő-ökoszisztémához láncolnak, más környezetbe alig vihetők át.
  • A UI-alapú logika nehezen kereshető; sokszor minden elemet meg kell nyitni, hogy kiderüljön, mit csinál.

A fájlalapú Kami Excelhez képest jóval nagyobb a függés és az adósságkockázat.

Árnyék (3) – a vizualizációs torzítás, amely elaltatja a vezetést

A mérnökök látják, hogy a „szakmai fal” elkerülhetetlen. A vezetők viszont egy GUI-folyamatot vagy képernyőmakettet nézve hajlamosak azt gondolni, hogy „ezt bárki tudja kezelni”.

Miért? Mert a rendszerek többnyire fekete dobozt jelentenek számukra. Ha nyilak és űrlapok kötik össze a lépéseket, úgy érzik, átlátják a komplexitást. A valóságban ugyanaz a vezérlési logika és hibakezelés működik a felszín alatt, és az éles használathoz ugyanúgy mérnöki tudás kell.

A vezetői optimizmus és a technikai óvatosság közötti szakadék felgyorsítja az elfogadást, miközben felpumpálja a jövőbeli adósságot.

A Kami Excel 2.0 korszaka felé

Ha mindezt összeadjuk, az RPA és a no-code/low-code eszközök ugyanazt az ívet rajzolják, mint a Kami Excel. Gyorsan megmentik a frontvonalat, látványukkal megnyugtatják a vezetést, majd fekete dobozzá válnak, amely súlyként húzza vissza a szervezetet.

A különbség a lépték. A Kami Excel fájlokban élt; a modern platformok az egész szervezetet átszövik, és platformszintű adóssággal láncolják meg a csapatokat. A lock-in még az Excelnél is erősebb – innen a „Kami Excel 2.0” elnevezés.

Összegzés

  • Az RPA és a no-code/low-code eszközök azonnali eredményeik és látványos vizualizációjuk miatt lettek népszerűek.
  • Az éles üzemhez továbbra is kell a vezérlési folyamatok, adatszerkezetek, integrációk és üzemeltetés ismerete – ezt a citizen fejlesztők nem tudják egyedül elvinni.
  • A platformspecifikus felületek megnehezítik a migrációt, és mélyítik a vendor lock-int.
  • A vezetői „vizualizációs torzítás” alábecsüli ezeket a kockázatokat, így fékezetlenül nő az adósság.

A modern citizen fejlesztés erősebb, mint a Kami Excel, de sérülékenyebb is. A következő részben azt vizsgáljuk meg, hogyan változik a kép, ha belép a generatív AI.

Következő rész: Mit ment meg, és mit hagy hátra a generatív AI? (4/7)