Introducere

În primele două episoade am confirmat cum EUC și Kami Excel au salvat temporar echipele operaționale, lăsând însă organizațiilor o moștenire negativă pe termen lung. În acest articol mutăm perspectiva în prezent și analizăm lumina și umbra platformelor moderne de dezvoltare cetățenească, precum RPA și soluțiile no-code/low-code.

Aceste instrumente repetă scenariul Kami Excel, dar cu o anvergură și o dependență mult mai mari. Pentru a înțelege impactul pe care îl va aduce inteligența artificială generativă, trebuie mai întâi să le înțelegem natura.

Întreaga serie

  • Intuirea viitorului dezvoltării cetățenești — istorie, prezent, IA generativă și ce urmează 0/7 (indisponibil încă în română)
  • Este dezvoltarea cetățenească revenirea EUC? — Lecțiile istorice ale lui Kami Excel 1/7 (indisponibil încă în română)
  • Kami Excel a fost cu adevărat „negativul”? — De la salvator la moștenire nocivă 2/7 (indisponibil încă în română)
  • Lumina și umbra platformelor moderne de dezvoltare cetățenească 3/7 (această parte)
  • Impactul IA generative asupra dezvoltării cetățenești 4/7
  • Cum evităm moștenirile negative și protejăm guvernanța 5/7
  • Perspectivele decalate produc pe bandă moșteniri negative 6/7 (indisponibil încă în română)
  • Legacy-ul continuă să se nască, dar poate fi îmblânzit — Viziunea viitorului dezvoltării cetățenești 7/7 (indisponibil încă în română)

Lumina — de ce au fost adoptate

Rezultate imediate

Fără a scrie cod, câteva operații în interfața grafică sunt suficiente pentru a finaliza o automatizare simplă sau o aplicație. Posibilitatea de a înlocui în doar câteva zile copieri zilnice sau procese repetitive este enormă pentru oamenii din linia întâi.

Puterea de convingere a „vizualizării”

Fluxurile și ecranele pot fi transpuse în diagrame ușor de înțeles, chiar și pentru cei fără cunoștințe tehnice. Pentru conducere, faptul că poate vedea un „rezultat care se mișcă” aduce o liniște considerabilă și de multe ori devine factorul decisiv pentru a aproba implementarea.

Primul pas făcut de „cetățeni”

Atunci când scopul este limitat — formulare de intrare sau fluxuri simple — și persoanele fără pregătire de inginerie își pot construi propriile soluții. La acest nivel chiar se simte că „oricine poate”, iar organizația își lărgește baza de participanți la dezvoltarea cetățenească.

Umbra (1) — „peretele profesional” care apare în practică

La suprafață pare că „oricine poate lucra cu ele”, dar în momentul în care vrei să le folosești serios, reiese că este nevoie de aceeași gândire ca în programare și de o perspectivă de proiectare specifică inginerilor de sisteme.

  • Inevitabilitatea structurilor de control Pentru a separa procesele în funcție de condițiile clientului ai nevoie de ramificări (If/Else). Pentru a trata sute de înregistrări ai nevoie de bucle (ForEach). Pentru a te pregăti de întârzieri sau erori ale sistemelor externe sunt indispensabile tratamentele de excepții (Try/Catch). Faptul că elementele sunt aranjate din GUI nu schimbă esența: este tot programare.

  • Înțelegerea structurilor de date Desfacerea JSON-urilor și a listelor, maparea ierarhiilor, uniformizarea formatelor de dată și număr — toate sunt indispensabile în integrarea operațiunilor. Nu este suficient să înlocuiești un tabel; dacă nu înțelegi structura datelor, totul se prăbușește.

  • Complexitatea integrării între sisteme Gestionarea valabilității autentificării API, asigurarea consistenței când traversezi mai multe sisteme, evitarea limitelor de rată — exact aceleași provocări ca în ingineria software tradițională apar și aici. GUI-ul doar le ascunde; dificultatea este chiar mai mare.

  • Exigențele de operare și calitate Dacă lipsesc concepte precum monitorizare, colectarea logurilor, diferențierea între medii de test și producție sau planuri de revenire la versiunea anterioară, haosul se instalează rapid. Cum nu există cod de gestionat, observabilitatea scade ușor.

În fața acestor bariere, este dificil ca un dezvoltator cetățean să construiască și să întrețină singur un sistem ce rezistă în producție, astfel încât dependența de specialiști devine inevitabilă. Totuși, problema capacității echipei tehnice rămâne nerezolvată.

Umbra (2) — blocarea la furnizor și migrarea dificilă

Kami Excel oferea încă o plasă de siguranță: totul era într-un singur fișier. Datele tabelare puteau fi exportate CSV, funcțiile și macro-urile erau legate de Excel, dar exista măcar o compatibilitate parțială cu alte aplicații de calcul tabelar, iar logica putea fi citită. În schimb, rezultatele realizate cu RPA sau no-code/low-code sunt aproape întotdeauna capturate în UI-uri și fișiere de configurare specifice unei platforme.

  • Migrarea către alt produs înseamnă practic „rescrierea de la zero”.
  • Închiderea unui serviciu SaaS sau schimbarea unilaterală a specificațiilor nu pot fi controlate de utilizator, iar activele acumulate se pot evapora peste noapte.
  • Dacă soluția a fost construită pe un PaaS, ești legat de ecosistemul acelei platforme cloud, iar mutarea în altă parte devine extrem de dificilă.
  • Definirea logicii prin UI în loc de cod face dificilă căutarea și identificarea zonelor cu probleme.
  • În funcție de designul instrumentului, există chiar componente a căror logică nu poate fi văzută fără dublu clic, ceea ce reduce și mai mult lizibilitatea.

Astfel, comparativ cu fișierele limitate la nivel de tabel din Kami Excel, riscul de dependență și de acumulare a datoriei este incomparabil mai mare.

Umbra (3) — „biasul vizualizării” care îi induce în eroare pe executivi

Din perspectiva tehnicienilor este evident că vei lovi rapid de „peretele profesional” descris mai sus. Dar conducerea, atunci când vede fluxuri și ecrane desenate într-un GUI, ajunge ușor la concluzia că „oricine poate folosi așa ceva”.

De ce? Pentru că, în mod obișnuit, sistemele sunt o cutie neagră pentru management, iar când procesele operaționale și formularele de intrare apar conectate cu săgeți, au impresia că au înțeles complexitatea internă. În realitate, în spate există aceeași logică de control și același tratament al erorilor ca într-un program, iar pentru a transforma aceste soluții în mecanisme robuste este indispensabilă expertiza de inginerie.

Acest decalaj între „senzația de siguranță” a conducerii și „îngrijorarea” tehnicienilor accelerează implementarea, dar amplifică în același timp datoria tehnică viitoare.

Era „Kami Excel 2.0”

Privite în ansamblu, RPA și platformele no-code/low-code urmează același tipar ca Kami Excel. Oferă rezultate rapide pentru linia operațională, conving conducerea prin vizualizări și, în cele din urmă, devin o povară prin opacitate și dependență de persoane cheie.

Diferența decisivă stă însă în amploare. Dacă Kami Excel se limita la un fișier, dezvoltarea cetățenească modernă se încastrează în cloud și în întregi procese critice, devenind o datorie care poate lega organizația la nivel sistemic. Pe deasupra, platformele actuale au un mecanism de lock-in și mai puternic decât Excel. Aceasta este situația pe care am putea-o numi fără rețineri „Kami Excel 2.0”.

Concluzii

  • RPA și platformele no-code/low-code au fost acceptate atât de oamenii din teren, cât și de conducere datorită rezultatelor imediate și forței de convingere a vizualizării.
  • Pentru a rezista în producție sunt indispensabile cunoștințe de inginerie software: structuri de control, structuri de date, integrarea între sisteme și proiectarea operațională. Dezvoltatorii cetățeni nu pot susține singuri aceste cerințe.
  • UI-urile specifice platformelor fac ca migrarea să fie foarte dificilă și întăresc blocarea la furnizor.
  • „Biasul vizualizării” îi determină pe executivi să subestimeze aceste riscuri.

În esență, dezvoltarea cetățenească modernă este mai puternică decât Kami Excel, dar și mai periculoasă. În episodul următor analizăm ce se întâmplă când în această ecuație intră inteligența artificială generativă.

Partea următoare: Impactul IA generative asupra dezvoltării cetățenești 4/7