1.časť Poriadok v AI: Architektúra

V článku Chaos v AI: Marketing sme sa venovali tomu, aký zmätok panuje v pojmoch v oblasti umelej inteligencie, ako to zneužíva marketing technologických firiem, či médiá pre clickbait články. Tým dochádza k nevhodnému očakávaniu majiteľov firiem, keď sa vytvára ilúzia, že jedno riešenie je vhodné pre všetkých – čo nedáva absolútne žiaden zmysel. Už táto samotná myšlienka ide proti diverzite, ktorá je nevyhnutná v podnikaní kvôli existencii konkurencie.

Dnes sa pozrieme na prípadovú štúdiu stredne veľkej firmy s ohromným technologickým a talentovým dlhom. Článok bude viac zameraný na pozíciu CIO a prenositeľný je koncept uvažovania, nie samotné riešenie.

Ponúknuté myšlienky sú koncipované ako inšpirácia – použijem pojmy, ktoré nemusia byť kvôli rozsahu vysvetlené. Dôvodom je, aby neznalého čitateľa motivovali vyhľadať si k týmto pojmom ďalšie materiály. Oblasť, ktorej sa budem venovať, nie je možné zhrnúť v jedinom článku.

Česko-Slovenská digitálna realita

Mnoho firiem v našom regióne zanedbáva oblasť IT. Má to svoju logiku. IT je v podstate nákladová položka, ktorá nie je pre firmu zaujímavá do tej doby, kým sa neukáže ako potenciálny kanál pre zárobok (napr. eShop). Firmy budované v 90. rokoch, napr. tie výrobné, ktoré majú desaťročný biznis model a vyriešené distribučné kanály, si pod pojmom IT predstavovali: LAN káble, správu emailových účtov a prístup do ERP.

Na CIO (Chief Information Officer) pozíciu sa regrutovali ľudia z nižších pozícií, ktorí postupne inovovali IT infraštruktúru, ale častokrát si nevedeli s novou rolou poradiť. Chýbala skúsenosť a stimul z vedenia, keďže ani vedenie netušilo, čo od tejto pozície vyžadovať. Táto situácia spôsobuje nedostatok talentov v daných firmách. Ambiciózni ľudia, ktorí chcú pracovať s modernými technológiami, totiž v takýchto firmách nemusia vidieť budúcnosť, možnosť rastu a učenia sa. Pričom opak je častokrát pravdou, ale nepredbiehajme.

Technologická maturita firiem

Jedna z ciest, ako uvažovať o technológiách vo firme, je založená na štádiu vývoja, v ktorom sa firma nachádza. V začiatkoch budovania firmy všetci kolegovia sedia v jednej miestnosti, činnosti častokrát prebiehajú ústne. Ako firma rastie, začínajú sa formovať prvé procesy, ktoré riešia stav objednávky, výrobu a pod. Keď sa nastavia procesy, firmu začne zaujímať automatizácia, aby procesy urýchlila, alebo „spresnila“. Kým proces neexistuje, nie je prakticky možné zavádzať automatizáciu. Tu ale začína prvá výzva: ako veľmi silný proces je, tak sľubné výsledky môžeme očakávať od automatizácie. Slovami Billa Gatesa: „Ak zefektívnime blbosť, vďaka automatizácii nám firmu zaplaví množstvo blbostí.“

Pod automatizáciu spadá implementácia rôznych systémov (ERP, CRM), ich prepájanie, prípadne jednoduché workflows. Keď sa tieto možnosti saturujú, tak prichádza na rad robotizácia, kedy robot mimikuje prácu živého kolegu: či už ovládaním nejakého informačného systému tak, ako by to robil človek (RPA) alebo komunikáciou (chatboti, voiceboti a mailboti).

Systémy a roboty začnú produkovať dáta. Tieto dáta vieme ďalej používať a vyťažovať. Aplikuje sa PowerBI, trénujú sa modely na detekciu fraudov či recommendation modely. No a na záver sa implementuje svätý grál… AI.

Alebo nie?

Obrázok 1 Technologická maturita firiem – na čo sa kedy sústrediť

V podstate nie je úplne jasné, čo to AI vlastne je, a v podnikovom systéme aj kvôli zmätkom, ktoré boli popísané v predchádzajúcich článkoch, prakticky neexistuje. Ak nám niekto zautomatizuje príjem emailov pomocou „AI“, v drvivej väčšine ide o jednu z úrovní automatizácie a nachádza sa to na pyramíde nižšie.

Ak by sme pod podnikovou AI rozumeli semi-autonómiu, či dokonca „singularitu“ (stroje, ktoré sa adaptujú v prostredí), tak si načrtneme scenár, ako by to mohlo vyzerať. Pôjde však o extrémne malú skupinu technologicky vyspelých firiem. Niektoré môžu uvažovať aj o plnej autonómii (dnes už existujú príklady).

Ale teraz späť do reality. Pohľad na túto pyramídu a identifikácia toho, kde sa firma nachádza, nám umožňuje:

• vedieť, čo práve riešiť a čo neriešiť,
• identifikovať talenty potrebné pre jednotlivé štádium,
• nastaviť očakávania voči biznisu.

Ak sme v štádiu, že neexistuje proces, riešiť PowerBI nedáva jednoducho zmysel[1]. Dáta neexistujú. Načrtnutá cesta popisuje aj tzv. „low hanging fruits“ – teda quick wins s dopadom na efektivitu s nízkou cenou/náročnosťou implementácie. Ak do výroby kúpime stroj, ktorý je možné prepojiť s ERP, s minimálnou disrupciou vieme túto zmenu vykonať a dosiahneme zrejme ohromnú úsporu oproti pôvodnému stavu. Ako však na pyramíde putujeme vyššie, náročnosť na technológiu, exekutívu a manažment sa zvyšuje. Zmeny častokrát nie je možné vykonávať len technológiou, je nutné meniť procesy a niekedy reštrukturalizovať oddelenia, či meniť typ zamestnancov pre novú etapu.

Na tieto zmeny potrebujeme nielen talenty, ale aj mandát, ktorý častokrát vo firme drží len CEO. Takže pokiaľ chceme postupovať po pyramíde na vrchol, pozorný čitateľ asi tuší, že technológia bude hrať druhé husle a spomeňme si na predchádzajúce články: nie každý biznis ju bude potrebovať. Na druhej strane, náročnosť realizácie môže byť konkurenčnou výhodou, ktorá určí smerovanie firmy na ďalších 50 až 100 rokov.

Korporátna inšpirácia

Ako teda uchopiť IT v takýchto firmách?

Dobrou inšpiráciou môže byť TOGAF[2]. Nemusíme ho adoptovať celý, ale je nutné porozumieť jeho filozofii. TOGAF patrí medzi tzv. Enterprise architektúry, ktoré sa roky budujú v korporátoch. Na začiatku sa musia zadefinovať strategické obchodné ciele. Potom sa identifikujú hlavné biznisové schopnosti firmy a k ním kľúčové procesy. Nepúšťajme sa do popisu celej organizácie.

Identifikujeme tak ľudí, systémy a ich prepojenia, dáta a procesy, ktoré podporujú kľúčové činnosti podnikania[3]. Na základe obchodných cieľov sa vytvorí budúca architektúra a roadmapa sa načrtne smerom z aktuálneho stavu k tomu budúcemu.

Navrhnú sa malé projekty a táto architektúra sa v malých a stredných firmách (SME) väčšinou rozpúšťa v iných projektoch postupne.

Predtým, ako si vyhrniete rukávy, uvažujte nie len o technológii, ale aj o tom:

• aké kompetencie máte a aké si musíte dokúpiť (nie každú kompetenciu potrebujeme akvírovať, firmy častokrát jednotlivé etapy „nakupujú“, a až keď je dostatočný dopyt po tejto službe, tak sa zvažuje interná pozícia);
• či je nutné mať pod kontrolou projektové riadenie – aj keď to znie zvláštne, niektoré SME firmy majú jedného/dvoch ľudí, ktorí realizujú väčšinu operatívy firmy. Tu si treba urobiť domácu úlohu a adaptovať projektovú kanceláriu – nájsť ľudí, ktorí sú schopní riadiť čiastkové projekty popri iných činnostiach a vytvoriť celkový plán pre PPP (projekt – program – portfólio), pričom tento krok môže trvať aj roky!
• či tieto činnosti – od projektových až po technologické – je nutné premyslieť v kontexte pracovných miest. Firma bude totiž nadobúdať nové schopnosti, ktoré nesmú byť viazané na jednotlivcov. Celý proces je nutné premyslieť – a treba pamätať aj na to, že budovať niečo také na zelenej lúke môže byť pre mladé talenty nesmierne zaujímavé – a takto treba o tom celom uvažovať.

Architektúra

O architektúre uvažujeme v kontexte systémov. Je niekoľko prístupov: monolit alebo modulárna architektúra. Obe majú svoje pre a proti. Pre SME je v drvivej väčšine najvhodnejšia modulárna architektúra, pretože umožňuje priebežné škálovanie, čím sa rozložia náklady v čase.

Prípadová štúdia: Výrobná firma, ktorá nemá jasno v budúcej stratégii a vyžaduje od IT obrovskú flexibilitu – v hre je výmena ERP, rozdelenie firmy na viacero častí (a teda viacero ERP), či transformácia firmy z B2B na B2C. Strategickým cieľom je tak flexibilita. Z technologického pohľadu je vo firme zastaralý ERP s eShop-om a oddeleným výrobným modulom (MES). EShop je nutné vymeniť. Ten však komunikuje s ERP cez API, ktoré sleduje zmeny v dátach ERP a raz za minútu posiela všetky hromadné zmeny na API. EShop si z týchto zmien musí brať „čo potrebuje“. MES je na ERP napojený cez FTP komunikáciu so súbormi.

Požiadavka na nový eShop je presne ten typ projektu, ktorý umožní zmenu architektúry. Ak sa medzi eShop a staré ERP API postaví nové API, získajú sa neuveriteľné možnosti ako o tom ďalej uvažovať:

• API je skvelá príležitosť ako popísať doménu objednávania, produktov a odberateľov,
• API je síce niečo vystavené vonku, ale spôsob, akým sa navrhne, je iná vec (napr. sa pozvoľne presunieme ku architektúre riadenej udalosťami – tzv. EDA – event driven architecture).

Obrázok 2 Návrh novej architektúry pre eShop

Implementácia message busu vyrieši problémy, ktoré doteraz firma mala – výpadky ERP alebo eShopu, strácanie informácií, či manuálne hľadanie chýb. Častokrát sa takto eShop „rozhodil“. Ak sa navrhne to, že API bude implementovať klasický bus, ktorý si stráži, či už si správu niekto prečítal alebo nie, tak nenastanú už žiadne takéto výpadky: toto je prvé ušetrenie.

EShop komunikuje s ERP cez API – žiada si dáta, ale informácie, že sa niečo zmenilo, dostáva z message busu. Ďalší problém, ktorý sa takto môže vyriešiť, je nekonzistencia dát. Každý, kto riešil napojenie ERP na eShop vie, že niektoré dáta (napríklad informácie o produkte, ktoré sa replikujú pre konfigurátor na eShope), sa pri produktoch kvôli obmedzeniam ERP musia riešiť manuálne. Pri manuálnych editáciách vznikajú chyby. Ak by sme každú takúto zmenu menili na strane ERP, pri niektorých ERP ide o desiatky tisíc er (ako v prípade tohto zákazníka). Tým, že API si vytvára lokálny IT tím, ktorý je súčasťou týchto diskusií (ako upraviť ERP), vie definovať kontroly, ktoré sa presunú z ERP do API. Toto sa nazýva DQM (data quality manažment). Systém si vie „odchytávať“ jednotlivé zmeny dát a kontrolovať. Message bus funguje na tzv. „queue“ – teda rôznych frontoch s rôznymi prioritami. Táto kontrola môže teda prebiehať kľudne v nočných hodinách:

Obrázok 3 Interné škálovanie – pomoc pre IT bez prenášania zmien do I/O systémov

Toto, samozrejme, vedenie nezaujíma. Získava flexibilitu, ktorú potrebuje, ale podobným modulárnym škálovaním, preto sa o tom rozpisujeme. Napr. pripojiť iný systém – existujúci MES, ktorý už nebude používať FTP, bude len o rozšírení dát, ktoré API spracúva a vytvorení ďalšieho frontu pre MES. Takto oddeľujeme entropiu systémov. Ak napr. prebieha DDoS hackersky útok na eShop, nijak to neovplyvní ERP alebo MES, tie sú izolované (aj keď eShop nemusí práve fungovať):

Obrázok 4 Škálovanie architektúry o ďalšie systémy

Nahradenie ERP systému v tejto architektúre nemusí výrazne ovplyvniť ostatné pripojené systémy. Naučíme len staré API pracovať s novým ERP, a dokonca je možné takto fungovať istú dobu paralelne:

Obrázok 5 Zmena ERP zasahuje do komponentov, nie do systémov a architektúry

Čo ak sa firmy oddelia? Môžu existovať 2 ERP systémy. A tým, že eShop komunikuje s jediným API, vieme ho prakticky skopírovať na novú doménu a len presmerovať dáta z iného ERP:

Obrázok 6 Vnútorné rozdelenie firiem (viacero ERP)

Záver

Ako vidíme, vhodná architektúra môže vytvárať komplexnosť a stojí aj peniaze. Pretože prepojiť eShop s ERP priamo je jednoduchšie, ako tam mať medzičlánok.

O architektúre treba ale uvažovať v možnostiach, ktoré nám prináša. Umožňuje:

• pridávať stále nové systémy,
• nové systémy môžu byť vyvíjané paralelne s rôznymi inými tímami (entropia ostáva izolovaná),
• replikovať sa dajú existujúce komponenty (znova použiť ten istý eShop, napr. ako load balancer) a
• IT dostáva nástroj, ktorým môže komunikovať s viacerými dodávateľmi „štandardizovaným“ spôsobom.

Jeden dodávateľ môže dodávať eShop, iný MES a to, že všetci komunikujú s jediným systémom, nám dáva možnosti k rôznym dodávateľom pristupovať ako ku jednému. Týmto dokáže oblasť IT znižovať ceny, nevzniká vendor lock na dodávateľovi a každý nový projekt kopíruje to, čo už sa raz vymyslelo. Takto IT šetrí ohromným spôsobom do budúcna, nehovoriac o tom, že s vedením sa nerozpráva o škálovaní a dodávateľoch, ale primárne o tom, čo vedenie zadefinovalo: o flexibilite. Ak vedenie rozhodne: ideme deliť firmy, IT povie: sme pripravení! Viac riaditeľ počuť zvyčajne nechce…

A ako to všetko súvisí s AI?

Vhodná IT architektúra môže mať väčší dopad na firmu, ako zavádzanie AI. Vyplýva z vyššie spomínanej pyramídy, kde sme sa dnes držali na úrovni automatizácie s ohromným dopadom bez nutnosti zavádzať AI. Ak saturujeme možnosti automatizácie, môžeme začať pripájať roboty. Ale premyslene, nie hala-bala na každú aktivitu jeden SaaS tool, aby nevznikol chaos na úrovni robotizácie (ako vznikal bežne na úrovni automatizácie, známy ako „špagety kód“). A na to slúži práve orchestrátor, ktorý do architektúry zapadá napr. takto:

Obrázok 7 Prechod od automatizácie ku robotizácii