Ixenit blog

Betekintés az Oracle Fusion cloud ERP bevezetési módszereibe

2021-01-26T15:12:40Z

Egyre több magyar vállalatnál felmerül, hogy a továbbiakban felhő alapú vállalatirányítási rendszerrel szeretnének dolgozni. A piacon jelenlévő versenyzők pedig igyekeznek izgalmas marketing és sales anyagokkal bemutatni, mit is tudnak a termékeik.

Azonban ezekben az anyagokban a használt divatos hívószavakat nem magyarázzák túl, hiszen úgyis mindenki találkozott már velük. De ha találkoztunk is velük, biztos ugyanazt értjük alattuk? A következő leírásban néhány ilyen hívószó mögötti gyakorlatot igyekszünk leírni, hogy könnyebben el lehessen képzelni, milyen lesz például a bevezetési időszak, vagy később a support. Példaként az Oracle Fusion rendszerét tudjuk használni, hiszen ezzel kapcsolatban vannak gyakorlati tapasztalataink.

Vízesés vs agilis vs hibrid

Aki részt vett vagy hallott már vállalatirányítási rendszerek bevezetéséről, biztosan a vízesés (Waterfall) modellt látta benne visszaköszönni. Vagyis hosszas előkészületek és több tesztkör után a teljes rendszert egyszerre vezették be. Ez a megoldás teljessége szempontjából mindenképpen előnyös, de a sokszor 1-2 éves bevezetési ciklus alatt bekövetkezett környezeti változásokhoz ez a modell nehezen tud alkalmazkodni. Az agilis fejlesztési módszertanok ez utóbbi területen tudnak sokkal jobb eredményeket felmutatni. Azonban egy felhős vállalatirányítási rendszert nem lehet teljesen agilis módszerekkel bevezetni, mert az kifejezetten a fejlesztésekre lett kitalálva, nem pedig egy már létező rendszer adaptálására. Hogyan lehet tehát ebből a két módszerből egy működő hibridet varázsolni?

Először is tudni kell, hogy melyik módszert melyik terméknél vagy termékcsoportnál érdemes használni. A pénzügyi modulok (Fusion Financials) bevezetésénél például ajánlott a Vízesés módszer, de a tervezési modulok (Fusion EPM) esetén haladhatunk agilisen. A felhőhöz kapcsolódó integrációk esetén is jobb az agilis módszer, hisz kifejezetten fejlesztésekről van ekkor szó. A hibriditás pontos fokát tehát mindig az adott vállalat és bevezetni kívánt termékek mixe határozza meg.

Másrészről agilisabbá tehető a projektünk, ha több termék és termékcsoport bevezetésénél ezeket megbontjuk folyamatok szerint, és fokozatosan indítjuk el őket. Egyes termékek már önmagukban bevezetve hatékonyságnövelést fognak elérni, még akkor is, ha az integrációk, vagy több kapcsolódó folyamat csak később kerül át a felhőbe. Továbbra is megfelelő megoldás lehet a bevezetés egyes országok, országcsoportok szerinti megbontása is. Minden vállalat és vállalatcsoport egyedi, így más és más módszertan és ütemezés fog nekik megfelelni. Ne sajnáljuk az időt a tervezésre és előkészületekre.

Végül, de nem utolsó sorban Fusion előfizetőként az Oracle agilis váltását is megtapasztalhatjuk, hisz az Oracle felhős termékek a nagy verzióváltások helyett áttértek a kisebb, negyedéves (vagy más periodicitású) frissítésekre, ahol az ügyfelek folyamatosan megkapják az agilis fejlesztések eredményeit.

Fusion vs Spotify/Netflix/stb

A magán fogyasztásaink során már több felhős platformmal is megismerkedhettünk. A felhős vállalatirányítás is sok ponton hasonlít ezekhez, egy lényeges különbségre azonban felhívnám a figyelmet. A magánszemélyek számára készített felhős szolgáltatásokra egyöntetűen jellemző, hogy a regisztráció (=szerződéskötés) után rögtön aktiváljuk is a szolgáltatást és fizetnünk kell az előfizetési díjakat (a becsalogató ingyenes időszak is határozott időtartamra szól és azonnal elkezdődik). Az Oracle Fusion felhős termékcsaládja esetében ez nincs így! A szerződéskötés után nem kötelező azonnal aktiválni a szolgáltatást, várhatunk pár hetet-hónapot, ami alatt elkezdhetjük a belső folyamatok átalakítását vagy kiválaszthatjuk a bevezető csapatot, vagy bármilyen olyan előkészítő tevékenységet végezhetünk, amihez nem szükséges maga a Fusion termék. Vagyis nem kell egy olyan időszak alatt is előfizetési díjat fizetnünk, amikor még nem nyúlunk hozzá a rendszerhez/szolgáltatáshoz.

Ahogy szoktuk vs Best practice

A magán fogyasztásaink során megszoktuk, hogy az egyes felhő alapú szolgáltatásokat úgy vesszük igénybe, ahogy kapjuk őket. Minimális beállítási lehetőségeink mindig vannak, de a használt folyamatokat, az elérhető funkciókat nem mi határozzuk meg, hanem a szolgáltató cég. Vállalatirányítási rendszerek tekintetében azonban ugyanez a modell (felhő) már sokkal inkább ijesztő lehet. Ezt az ijedtséget pedig informálódással lehet csillapítani. Például ismerjük meg a felhős vállalatirányítási rendszerek beállítási lehetőségeit - mert sokkal több van belőlük, mint a magánfogyasztásra szánt felhős szolgáltatásokban. A Fusion termékeiben például best practice folyamatokat lehet használni, valamint az ezekhez kapcsolódó beállítási lehetőségeket. A best practice azt takarja, hogy az Oracle az on-premise termékeivel szerzett tapasztalatai alapján kiszűrte, hogy mely folyamatokat hogyan használják a legtöbben, és a felhős ERP-t már ennek alapján optimalizálva hozta létre. Tehát előfordulhat, hogy adott folyamatra a korábban használt 1000 verzióból a felhőben beállításokkal csak 500 valósítható meg, de erre még mindig nem mondhatjuk azt, hogy drasztikusan leszűkült volna a mozgásterünk. Ugyanezeket a best practice folyamatokat pedig felhasználhatjuk arra is, hogy megvizsgáljuk, jelenleg tényleg a legoptimálisabban szervezzük-e a folyamatainkat. A cégek életében korábban meghozott döntések idővel túlhaladottá válhatnak, így érdemes egy ERP-váltást arra is felhasználni, hogy az új helyzethez jobban illő folyamatokat alakítsunk ki.

Eszköz váltása vs üzleti folyamat módosítása

A vállalatirányítási rendszerek nagyobbak annál, minthogy eszközváltásnak nevezhessük, amikor bevezetünk egyet vagy az egyikről áttérünk a másikra. Ilyenkor mindig elő kell kerülnie az üzleti folyamatok esetleges módosításának is, és a változásmenedzsment eszközeivel végig kell kísérni a folyamatot. Fontos, hogy ne a mindennapi munka egyes lépéseit akarjuk ilyenkor rekreálni, hanem fogalmazzunk meg olyan célokat, amik mérhetőek és elérhetőek - például mennyi ideig tartson egy adott folyamatlépés, egy adott esemény bekövetkeztéről ki kapjon azonnal értesítést, stb - és ezeket kérjük számon a friss rendszeren / a bevezető csapaton.

IT-vezérelt vs Business-vezérelt

Az elmúlt évtizedekben több példát láttunk arra itthon is, hogy egy ERP bevezetése alapvetően nem üzleti, hanem IT-döntés volt, az üzleti felhasználók nem kaptak beleszólást a rendszer kiválasztásába, és a bevezetést is inkább elszenvedték, mint aktívan részt vettek volna benne. Ezt részben magyarázta csak, hogy az on-premise vállalatirányítási rendszerek esetén a költségek és a bevezetési munka nagy része az IT-ban csapódott le (hardverek, szoftverek, integrációk). Így sajnos láttunk olyan meghiúsult bevezetést is, ami az üzleti felhasználók és döntéshozók ellenállásán bukott meg.

Mivel a felhős megoldások terén már sokkal kiegyenlítettebb az IT és az üzlet részvétele, sőt bizonyos esetekben át is billenhet a hangsúly az üzlet oldalára, így még a korábbinál is fontosabbá vált, hogy az üzleti döntéshozók részt vegyenek a döntésben, és a véleményvezérek az új megoldás mellé álljanak. Mivel a felhős megoldások best practice megoldásokkal dolgoznak, így várható, hogy bizonyos üzleti folyamatok meg fognak változni. A változás pedig mindig ellenállást vált ki, amit információmegosztással, változásmenedzsmenttel kezelni kell. Akár ezek a belső folyamatok is elkezdhetőek a korábban említett időszakban a szerződéskötés és az aktiválás között.

Hardverek kezelése vs felhős szolgáltatások

Amikor egy cég az on-premise rendszeréről térne át a felhős megoldásra, nagy változásra kell számítani az IT szakemberek feladatában is. Ez a korábbi gyakorlathoz képest jelenthet több vagy kevesebb feladatot, de mindenképpen jelennek meg új feladatok és tűnnek el régiek. A korábbi vállalatirányítási rendszer alatt futó hardvereket például a továbbiakban már nem kell karbantartani (hacsak egyéb célra nem), de szorosabb kapcsolatot kell kialakítani az Oracle Support szervezetével, ahol a Fusion hardvereit kezelik. A Fusion adatbázisában található adatokat már csak közvetlen módon lehet elérni, így a korábbi beépített fejlesztéseket felváltják az integrációs fejlesztések.

Ügyviteli rendszer automatizálása, elektronikus feldolgozás

2021-01-13T14:03:55Z

Mindannyian tapasztaltuk az elmúlt évben, hogy az ügyviteli folyamatainkban az online megoldások elengedhetetlenül szükségesek az üzleti folyamatok biztonságos működése érdekében. Az online megoldások használata óhatatlanul generálja az automatizáció igényét, hiszen használat közben jól látható, hogy sokkal több információ áll(hat) a rendelkezésünkre annál, mint amit a napi munkavégzés során felhasználunk. Ezt még inkább erősíti az, hogy az Adóhatóság az elmúlt évek fejlesztései során elektronikus módon minden számlainformációt bekér, és - nagy szerencsénkre - ezeket a rendelkezésünkre is bocsátja (ahogy erről korábban a „Hogyan könnyítheti meg a NAV online a vállalati adminisztrációt?” című blogban már írtam). Ennek köszönhetően egy jó ügyviteli rendszerrel, és a megfelelő információk felhasználásával minimalizálhatjuk a manuális munkavégzést, miközben a bizonylataink és egyéb dokumentumaink papíralapú tárolását is elfelejthetjük, ami sem tárolási, sem visszakereshetőségi szempontból nem mindegy.

Hogy is épül fel egy ilyen jó ügyviteli rendszer? Ezt nehéz lenne egy blogban megírni, ezért most nagy vonalakban fogom összefoglalni, és majd későbbi blogjainkban kitérünk az egyes komponensek részletesebb szakmai kidolgozására.

Kezdjük az iktatással, aminek nem szabad túl komplikáltnak lennie, legalábbis a kezelés szempontjából. Kapjon a digitalizált dokumentum iktatószámot, ami lehet szám/vonalkód/QR kód; lehessen ezeket a dokumentumokat tipizálni, és típusonként lehessen rájuk különböző worflow-kat definiálni (jóváhagyási, értesítési stb.). Az sem árt, ha ezekről e-mail értesítést is kapnak az egyes lépések felelősei.

Az iktatást értelemszerűen megelőzi a kimenő számla kiállítás. Egy jól kitalált számlázórendszerben lehetőség van ERP rendszer nélküli önálló számlázásra is. Egy ilyen rendszernek képesnek kell lennie papír alapú számla, elektronikus formában készített számla (elektronikusan továbbított, de nem e-számla) és hitelesített e-számla kiállítására is. Az utóbbi két esetben fontos funkció lehet ebben a jól kitalált számlázórendszerben a vevő oldali ügyfélfiók, ahova a kiállított számlák kerülnek, és ahonnan a vevők naplózottan tudják ezeket a számlákat letölteni, így biztosítva a számla átvételét bizonyító „tértivevényt”.

A fiókot mindhárom számlakiállítási típus esetén össze kell tudni kötni a NAV online rendszerével, ahova a rendszer feltölti azokat az aktuális törvényi előírásoknak megfelelően, és a visszakapott NAV értesítést lekérdezi és tárolja.

ERP szinkronizálás esetén a használt ERP rendszerből fogadhatjuk az ott elkészült számlákat/számla adatokat (PDF és XML) és továbbíthatjuk azt a vevők felé.

Szükséges továbbá kimenő számlák elkészítésekor a teljesítést igazoló dokumentumok csatolásának és a számlával együtt történő tárolásának lehetősége is.

Az ügyviteli rendszerben az iktatást követő komponens a beérkező számla fogadása. A szállítói számlák kezelésére többlépcsős workflow vezérelt folyamat létrehozása a célravezető. Ennek keretében lehet fogadni és azonosítani a számlákat. Ezt követően érdemes ellenőrizni a partner és számla adatokat, majd a NAV online lekérdezéssel letölteni a számla információkat (fej és tétel adatok). A számla tartalmát egy számlafeldolgozón keresztül egyeztethetjük a megrendeléssel, majd ezt követően következhet az iktatás és az egyes dokumentum típusokra felépített jóváhagyási workflow. Amennyiben nem szeretnénk bajlódni a továbbiakban a papírszámla tárolásával, akkor a digitalizált papír alapú és az elektronikus formában kapott számlát, elektronikus aláírással hitelesíteni kell, és innentől kezdve a számlának hitelesített elektronikus másolata van a birtokunkban. Így a papír alapú számla megsemmisíthető, illetve az elektronikus formában kapott számlát nem szükséges kinyomtatnunk. Az eleve hitelesítetten kapott e-számla esetén ezzel természetesen nincs teendőnk. Végül feladhatjuk azt (akár a könyvelési információkkal kiegészítve) az ERP rendszer felé.

A jól kidolgozott folyamatban csak akkor van szükség emberi beavatkozásra, ha nem találja a rendszer a NAV online rendszerben a számlát, illetve akkor, ha a megrendelés egyeztetésekor nem egyező adatokat találunk.

Az ügyviteli rendszer persze nem csak számlázásra használható. A jól definiált dokumentum típusok és a hozzájuk kapcsolt workflow-k képessé tehetnek egy ilyen rendszert többek között szerződés nyilvántartásra, aminek kapcsán beépíthetünk interakciókat, értesítések kezelését, és figyelmeztethetünk a szerződés lejáratára vagy mérföldkövek közeledtére, illetve nem „csak” nyilvántarthatjuk, hanem a szerződések előkészítésére, valamint jóváhagyására testreszabott folyamatokat alakíthatunk ki. Akár a workflow vezérelt feladat nyilvántartásra is van lehetőség egyedi feladat támogatásra alkalmas workflow vezérelt munkafolyamat kialakításával, ahol tájékoztató jelleggel vagy jóváhagyási céllal küldhetünk információkat, illetve csatolmányként a feladatot támogató dokumentumokat mellékelhetünk a folyamat bármely fázisában.

Jól látszik, hogy egy megfelelően felépített ügyviteli rendszerben rengeteg olyan információ van, melynek átgondolt felhasználásával tovább könnyíthetjük a napi munkavégzést. Képzeljük el, hogy a rendszer által kezelt dokumentumok milyen mennyiségű és értékű adatot tartalmaznak, ami ráadásul egy helyen áll rendelkezésre. A kimenő/bejövő számlákon és egyéb dokumentumokon szereplő információk nagyon értékesek a szervezet számára, és sokrétűen (újra)felhasználhatóak. Lehetőség nyílik például az olyan NAV adatszolgáltatások elkészítésére is, mint az A60-as vagy az M65-ös bevallás. Ugyanúgy fel tudjuk használni ezeket az adatokat egyéb külső adatszolgáltatásokra, valamint belső célokra is. Jó alapot jelenthetnek egy adattárház, vagy bármilyen BI rendszer kiszolgálására, de a keretrendszer segítségével szintén kifejleszthetőek intelligens riportok magán az ügyviteli rendszeren belül is. Így nemcsak a számla és egyéb dokumentum feldolgozásban résztvevők, hanem a kontrollerek, vezetők, döntéshozók is profitálhatnak a folyamatok elektronikus útra tereléséből.

Végezetül az elektronikus úton történő ügyvitelszervezés lehetőséget biztosít a dokumentumok hosszú távú, jogilag is elfogadott, költséghatékony tárolására, ahol az egyes dokumentumok kigyűjtése rendkívül rövid időt vesz igénybe. Erre akkor van lehetőségünk, ha az ügyviteli rendszer lehetőséget biztosít a bejövő/kimenő számlák és egyéb dokumentumok archiválására is. Ez annyit jelent, hogy átemelhetőek a dokumentumok és metaadataik egy archiváló modulba, ahol néhány plusz információ megadásával, valamint egy elektronikus aláírás használatával hosszú távra el tudjuk tárolni őket. A megadandó információk segítenek a dokumentumok kategorizálásában, csoportosításában, valamint a könnyű visszakereshetőség elérésben. Természetesen lehetőség van a szervezetnél lévő egyéb dokumentumok, mint például szerződések, szállítólevelek, levelezések egyedi vagy csoportos feltöltésére is. Az archiválás folyamatát egy workflow motor vezérli, ami könnyen testre szabható, plusz lépésekkel bővíthető. A rendszernek meg kell felelnie az erre vonatkozó törvényeknek, tehát az archiválás után a papír alapú dokumentumok megsemmisíthetőek, nincs szükség raktározásra, ezáltal jelentős költségmegtakarítás érhető el mind tárolóhely, mind emberi erőforrás tekintetében.

Fentiek megvalósításával nagy lépést tehetünk a tényleges papírmentes iroda kialakítása felé.

ChatBot, az új kommunikációs "chatorna"

2020-11-17T14:08:38Z

Az utóbbi időben, a különböző bankok és lakossági szolgáltatók weboldalain újabb kommunikációs csatorna tűnt fel. A telefonos ügyfélszolgálat, az email küldő űrlapok és az email címek után lehetőség van az új “párbeszéd interface”, vagyis a ChatBot használatára. De mi is az a ChatBot?

A ChatBot-okat leggyakrabban az ügyfélszolgálatok munkájának segítésére használják, de felhasználásuk széles körű: segíthet a látogatónak elnavigálni a kiállítások között egy múzeumban, vagy például cégek belső folyamatait is támogathatja. Be tudnak jelentkezni felületekre, küldhetnek email-t, SMS-t, kereshetnek adatbázisokban, sőt RPA robotokat is képesek elindítani.

A ChatBot egy új felületet nyit a számítógépekkel való kommunikálásban. Felválthatja az eddig használt terminálokat és grafikus interface-eket és mindezt úgynevezett természetes nyelven teszi, mint az angol, vagy a magyar. Használatához nincs szükség programozói nyelvre, a kommunikáció pedig történhet írásban vagy akár szóban is.

Hogyan működnek?

A ChatBot-ok általában három fő elemből épülnek fel:

felhasználói felület,
tudástár és logika,
mesterséges intelligencia / NLP

Felhasználói felület

Az első elem a felhasználói felület, amivel a felhasználó találkozik. Ez határozza meg a ChatBot kinézetét, itt láthatóak a vizuális elemek, az üdvözlés, a kezdő üzenet. Lényegében ezen a “front end” felületen történik a kommunikáció a felhasználó és a ChatBot között.

Tudástár és logika

A második elem a ChatBot tudástára és logikája. A tudástár azoknak a kérdéseknek a variációját tartalmazza, amiket a felhasználó kérdezhet. Minél több variációt tartalmaz a tudástár, annál valószínűbb, hogy a ChatBot válaszolni tud.

Itt található a ChatBot logikája is, ez határozza meg, hogy milyen kérdésre, milyen választ adjon. Persze előfordulhat, hogy nem tud válaszolni, mert egy banki ChatBot-tól nem elvárás, hogy tájékoztatást adjon az időjárásról. Ilyenkor a ChatBot jelzi, hogy nem érti a kérdést, és szeretné, ha megismételnénk más szavakkal, vagy egyszerűbb kifejezésekkel.

Mesterséges intelligencia és NLP

Végül, de nem utolsó sorban a harmadik elem az NLP (Natural Language Processing) mely lehetővé teszi, hogy a ChatBot felismerje az adott szöveget és össze tudja hasonlítani a tudástárában lévő variációkkal, akkor is, ha két szöveg nem egyezik pontosan.

Dióhéjban, az NLP a mesterséges intelligencia technológia része, mely lehetővé teszi a ChatBot számára, hogy megtanulja és értse a természetes nyelveket.

Kép: A különböző ChatBot elemek együttműködése

További tulajdonságok

Csatornák

A ChatBot-ok sokféle csatornán képesek kommunikálni. A legáltalánosabb, amikor valamilyen web felületre csatlakozik és az oldal megnyitásakor elindul a ChatBot is. De csatlakoztatható a ChatBot Microsoft Teams-hez, Facebook Messenger-hez, Whatsapp-hoz is.

Kép: ChatBot az Erste Bank webes felületén

Kép: a BioHair ChatBot-ja Facebook Messenger-en

Fejlődés

A ChatBot-ok el tudják menteni a felhasználókkal folytatott beszélgetéseket. A beszélgetésekből kiderül, hogy mik azok a kérdések, amikre a ChatBot nem tudott válaszolni. Ezek a kérdéseket be lehet tenni a tudástárba, így a ChatBot tovább fejlődhet.

Végezetül…

A ChatBot-ok segítségével tehát természetes nyelven kommunikálhatunk a számítógépekkel, mintha emberek volnának, anélkül, hogy programok kulcsszavait használnánk, vagy menükben klikkelgetnénk. Ez az új mesterséges intelligencián alapuló kommunikációs csatorna lehetőséget ad a felhasználóknak, hogy speciális tartalmakat keressenek egyszerűen és azonnali, személyre szabott választ kapjanak.

Ám a ChatBot-ok is csak akkor működnek megfelelően, ha jól megtervezett interakciókkal, alaposan kiépített tudástárral, és a helyes csatornán keresztül bocsájtják őket a felhasználók rendelkezésére.

Webinár összefoglaló: RPA automatizáció ERP rendszeren

2020-10-20T11:48:00Z

Az Ixenit csapata múlt héten tartotta első automatizációval kapcsolatos webinárját, melyről szeretnénk összefoglalót adni azoknak is, akik nem tudtak részt venni az előadásokon.

A webinárra elsősorban olyan IT szakembereket vártunk, akik RPA-val foglalkoznak, vagy tervezik, hogy belekóstoljanak a robotizált folyamatautomatizálás világába.

Szakmai előadóink kétféle RPA platformmal is dolgoztak, egy-egy use case-t mutattak be a két piacvezető - a UiPath és az Automation Anywhere - eszközeivel.

A résztvevőknek lehetőségük nyílt közelebbről is megismerni a két platform sajátosságait, betekintést nyerhettek a különböző felületekbe.

A use case-ek bemutatása során látható volt, hogy az RPA milyen jól együtt tud működni különböző szoftverekkel, illetve kiderült, hogy a meglévő hardver és szoftver infrastruktúra jelentős módosítására sincsen szükség, elég volt csak robot felhasználókat létrehozni.

Az RPA kiemelkedő előnye, hogy gyorsan implementálható, kis komplexitású automatizációk akár 1 hét alatt éles üzembe tehetők, ez igaz volt a bemutatott példákra is.

Nem lehet eléggé hangsúlyozni a folyamatautomatizáció legfontosabb kritériumát, miszerint akkor lehet és érdemes automatizálni egy folyamatot, ha az gyakran fordul elő és standard, azaz mindig közel azonosak a folyamat során végrehajtott lépések.

Mindkét use case esetében ilyen folyamatok automatizálása történt, illetve mindkét esetben elektronikusan olvasható, strukturált input adatokkal dolgoztak a szoftverrobotok.

Oracle Fusion-ben kiállított kimenő számla feltöltése NAV XML készítő rendszerbe UiPath RPA-vel

Az elsőként bemutatott automatizációs példában a szoftverrobotnak az Oracle Fusion felhő alapú vállalatirányítási rendszerben kiállított számlák tartalmát kellett letöltenie, majd feltöltenie az eSzámlacentrum rendszerébe, hogy az a megfelelő NAV XML file-ok létrehozása után továbbítsa a számlák tartalmát a NAV felé, ezzel teljesítve az online adatszolgáltatási kötelezettséget.

A megoldás során a robot először belép az Oracle Fusion ERP rendszerbe, ott megadott paraméterek alapján riportot kérdez le a számlákról, majd a riport formázása után letölti a megfelelő számlaképeket. A letöltést követően feltölti azokat az eSzámlacentrum rendszerébe, mely rendszer létrehozza a megfelelő NAV XML file-okat és egy integráción keresztül továbbítja a NAV rendszerébe.

Az RPA folyamat ellenőrzi a számlakép feldolgozásának és a NAV-nak való továbbításának sikerességét.

A fejlesztő elmondása alapján a fejlesztés egyik legnagyobb kihívása az volt, hogy a számlaképeket különböző időintervallum alatt dolgozza fel az eSzámlacentrum, így a folyamatnak bizonytalan ideig kellett várnia. A bizonytalanságot a megfelelő aktivitásokkal (Find Element, Element Exists) és paraméterezéssel (Wait Before, Wait After) lehetett kiküszöbölni.

Ez az automatizáció UiPath RPA platformmal valósult meg.

Napi árfolyam betöltés Oracle Fusion rendszerbe, Automation Anywhere RPA rendszer segítségével

A második példában egy igazán valós igényt kiszolgáló megoldást mutattunk be: napi deviza árfolyamok betöltését egy vállalatirányítási rendszerbe.

Az automatizáció során a robot segítségével lekértük a friss árfolyamokat az MNB oldaláról, majd betöltöttük azokat az Oracle felhő alapú vállalatirányítási rendszerébe.

Ebben a mintapéldában azt a jellemző import folyamatot mutattuk be, amikor az Oracle Fusion ERP rendszerbe kívülről szeretnénk adatokat bevinni, de arra REST API-n keresztül nincsen mód. Ehelyett egy Excel sablont kellett használni, mely egy add-in-nel kapcsolódik a Fusion rendszerhez és egy adott táblába (a példánkban a napi árfolyamok táblázatába) szúr be új sorokat.

A fejlesztő szerint a példafeladat kihívásai elsősorban az add-in helyes kezelése, valamint a precíz navigáció megvalósítása volt a Fusion böngészős felületén.

A webinár teljes felvétele, s ezzel az előadások anyaga YouTube csatornánkon érhető el.

Az RPA-ról még több információ megtalálható az rpa.ixenit.com-on!

A jövőben is szeretnénk hasonló, online előadásokat tartani mind a szakmai, mind pedig az üzleti közönségnek. Szívesen vesszük a témajavaslatokat!

Ha a körülmények is engedik, tavasszal pedig már személyesen, a Graphisoft parkban található irodánkban is várjuk majd az érdeklődőket.

Automatizálási tanácsok és tippek, nem csak nagyvállalatoknak

2020-10-14T08:48:14Z

Mielőtt egy vállalkozás az automatizáció bevezetését tervezni kezdi, fontos, hogy megértse, pontosan mire használható, milyen területeken adhat hatékony megoldást. Így reális célokat lehet kitűzni és az elvárt eredmény sem marad el. Nekik szeretnék hasznos tanácsokkal szolgálni ebben a blogbejegyzésben, illetve eloszlatni néhány tévhitet. Gyakori, hogy a szoftverrobotokra csak mint desktop automatizáció tekintenek, míg ennek sokkal szerteágazóbb a felhasználási módja, amely biztosítja a stabil és folytonos üzletmenetet.

I. Jó tanácsok az automatizációval kapcsolatosan:

A legfontosabb kérdés az, hogy milyen területeken lehet sikeres és eredményes az RPA automatizáció használata: azok a folyamatok, vagy komplex folyamatok részei, amelyek rendszeresen, nagy számban ismétlődnek és viszonylag standardok. Ha nincs standard vagy ismétlődő folyamatunk, nem tudunk automatizálni!

Mindig kis lépésekben haladjunk, nem kell rögtön ágyúval verébre lőni! Legyenek az első automatizálandó folyamataink minél egyszerűbbek, mert ha túl komplexet választunk elsőre, könnyen elmehet a kedvünk az egésztől.
Ha az adott folyamat nem eléggé standardizált, kezdjünk el szabályokat kialakítani és figyeljük meg, ezen szabályok működőképességét!
Legyenek dokumentálva a folyamataink, melyeket automatizálni szeretnénk!
Figyeljük meg a konkurenciát – amennyiben van olyan konkurensünk, aki automatizált már valamilyen folyamatot –, ők hogyan csinálják! Tanulni sosem szégyen, nemde? Mástól tanulni mindig kifizetődőbb!
Válasszunk megfelelő szoftvert, platformot! Tegyük fel magunknak az alábbi kérdéseket: biztonságos, stabil, árban kifizetődő?

II. Három tény a szoftverrobotokról:

1. Ma már szinte minden cég használ valamilyen automatizált folyamatot. Lehet ez például a fizetésemlékeztető e-mailek kiküldése, ezzel kiváltva a kellemetlen telefonhívásokat, vagy a bankszámlára érkező ki- és befizetésekről szóló értesítések. Az RPA több, mint egy API vagy egy precízen elkészített excel makró, mivel bármilyen alkalmazást képes használni és alkalmazások között is működik. Ennek az értéke nem csak anyagiakban mérhető, de presztízs szempontjából sem elhanyagolható!

2. Azok automatizálnak, akik növekedni, fennmaradni akarnak és mindezt hatékonyan tervezik nem csak most, de a jövőben is. Az automatizáció nem arról szól, hogy megszabaduljunk a meglévő munkaerőtől, hanem arról, hogy tehermentesítsük őket és ezáltal a túlterhelt munkatárs megbízhatóbb, minőségibb munkát végezzen.

3. Egy üzleti folyamatot akkor éri meg automatizálni, amikor az adott részleg munkatársai és a tevékenységükhöz kapcsolódó eszközök nagyobb költséggel járnak, mintha a feladatokat szoftverrobotokkal végeztetnénk el. Azt ki kell emelnem, hogy ezt egy felmérés előzi meg, melyet pontos dokumentálás és adatgyűjtés foglal magában!

III. Milyen előnyökkel jár az automatizálás a vállalkozások számára?

A, Alacsonyabb költségek: Közel 30%-os költségcsökkentést lehet elérni bizonyos feladatok automatizálásával, sőt ez a szám a folyamatok méretével, komplexitásával elérheti az 50%-ot is! Nézzünk picit a számok mögé, a szoftverek futtatásának költségei alacsonyabbak lehetnek, mint a teljes munkaidőben foglalkoztatottaké.

B, Folyamatos rendelkezésre állás: Bizony, ezek a szoftverrobotok nem betegednek meg, este is dolgoznak, nem bosszantanak kérdésekkel, csak teszik amire utasítottuk őket és hozzák a várt eredményeket. Nyilván kávézni, ebédelni nem velük megy el az ember, ők megcsinálják a munkánk unalmas részét, addig pedig plusz időhöz jutunk, ami valljuk be, néha igazán jól jön!

C, Hibázási lehetőségek csökkenése: Igen, emberek vagyunk és hibázunk! Mi ebből tanulunk és jobb esetben fejlődünk. Sok tényező zavarhati a teljesítményünket, ez lehet stressz, fáradtság, ismeretek hiánya. Ebben az esetben a szoftverrobot biztosítja az operatív kockázatok alacsonyabb szinten tartását.

D, A meglévő folyamatainkat hatékonyabbá válnak: Napjaink legforróbb témái a mesterséges intelligencia és az automatizálás. Ezek kiaknázása már nem csak filmekben létező dolog, de mindennapjainkban is jelen vannak. Itt most nem a Skynetre kell gondolni! A standardizálásnak köszönhetően - visszautalva a korábban elmondottakra és annak jelentőségére - elmondható, hogy az automatizáció bevezetése segíti a vállalkozásokat a jobb termelékenység és a gyors skálázhatóság elérésében.

E, Az RPA miatt nem kell a már meglévő informatikai rendszereinket lecserélni: Ezek a kis szoftverrobotok nagyon ügyesen alkalmazkodnak a különböző informatikai felületekhez. Nekünk volt szerencsénk belefutni egy-két igen érdekes user interface problémába, kevésbé populáris szoftverrel kapcsolatosan. Az ügyfél egyrészt nem engedhette meg magának a jelenlegi helyzetben, hogy a rendszert lecserélje egy költségesebb megoldásra, másrészt viszont a szoftver használata elengedhetetlen volt a vállalkozás életében.

Végül talán a leghasznosabb tipp és a fentieket is összegzi, hogy ne úgy tekintsünk az RPA-ra, mint világmegváltó megoldás. Mégis ajánlott és érdemes foglalkozni a szoftverrobotokkal, mivel ez egy kiváló eszköz arra, hogy át tudjuk hidalni nagyobb informatikai rendszerek továbbfejlesztési idejét, annak tanulási és integrálási ideje alatt biztosítja a folytonos működést.

Másik, nem elhanyagolható szempont, hogy a munka monoton, manuális részét kiváltva egy jobb vállalati stabilitást biztosít. Egy biztos, az automatizáció még csak most bontogatja igazán a szárnyait és a mesterséges intelligencia fejlődésével egyre több területen érdemes elgondolkozni a szoftverrobotok bevezetésén.

Segítség, a felhőbe költöztetnek!

2020-09-29T12:59:46Z

Fiktív történet egy cég IT munkatársáról, aki egy felhős ERP rendszer bevezetése előtt áll.

A történet szereplői kitalált figurák, a valósággal való bármilyen egyezés (nem) csak a véletlen műve!

Március:

Eljött a vég. A CÉG eldöntötte, hogy a jelenlegi belsőleg telepített és karbantartott ERP rendszert lecserélik egy felhő alapú dobozosra. Elviszik alólam az összes VASat, amivel eddig foglalkoztam, pedig hogy összenőttünk már! Már annyira megszoktam a rendszeres feladataimat, de a VAS azért mindig gondoskodott valami meglepőről, hogy ne unatkozzak. Vajon mik lesznek az új feladataim? Egyáltalán, lesznek nekem feladataim? Vagy ez is olyan robotizáció-féle csere lesz, ami után már semmi szükség nem lesz a munkámra? Megyek, és kipuhatolom a főnöknél…

Március, egy nappal később:

Remek. Részt kell vennem a régi rendszer szétbombázásában. Persze nem így fogalmaztak, a segítségemet kérték az új rendszer kialakításában, de a kettő egy és ugyanaz. Miért kell egyáltalán hozzányúlni valamihez, ami már évek óta működik? Amikor meg éppen nem működik, akkor itt vagyok én, és segítek nekik. 24 óránál többet még egyik problémánál sem kellett várniuk, csak ha külső forrást is igénybe kellett vennünk. Mindenesetre én biztosan nem fogom megkönnyíteni a dolgukat, hiszen csak akkor van értelme lecserélni a rendszert, ha legalább annyit, de inkább többet tud, mint a mostani, nem?

Április:

Hát, ezek az új rendszerek többet nem tudnak, az biztos, sőt van amelyik érezhetően kevesebbet. Nem lehet majd közvetlenül belenyúlni az adatokba! Persze, rengeteg lekérdezés, meg API-k, meg interfészek, meg adatbiztonság. Ja igen, ez az egyik varázsszó. Úgy pufogtatták mindkét oldalon, mintha legalábbis tüzijátékot lehetne vele csiholni. Pedig a múltkor is milyen jól kiszúrtam azt a zsaroló emailt, csak egy szerver esett ki miatta. És attól a hálátlan kollégától is viszonylag olcsón vissza lehetett szerezni a céges adatokat. A másik ilyen varázsszavuk a rendszerbiztonság. Még a főnök is azt visszhangozta, hogy mi lenne velük, ha engem elütne a busz? Hát mi lenne, a kórházból telefonon magyaráznám a többieknek, hogy mit kell csinálni. De a legnagyobb hátbatámadás a rendszerdokumentáció hiányának felemlegetése volt. Csak egy félmondatban hangzott el, de a főnök egyenesen rám nézett, pedig mondtam már neki többször, hogy ennyi munka mellett nincs időm írogatni. De azért jól belekérdeztem mindegyik demóba. Engem nem mindenhol tudtak megnyugtatni, de a főnökség kitart a döntése mellett. Na, majd meglátjuk, mi lesz ebből…

Április, két nappal később:

Behívott a főnök. Újfent megkért, hogy segítsem az új rendszer bevezetését, mert a demókon azt érezték, hogy ellenállást tanúsítok. Nem értettem, miért nem látják, hogy az ő érdekük is az, hogy az új rendszer ugyanazt tudja, mint a régi. De kijavított, hogy nem ugyanazt kell tudnia, hanem ugyanazokat (vagy jobb) végkimeneteket kell biztosítania, még ha nem is ugyanazon az úton, mint eddig. Egyrészt értem és elfogadom, amit mondd, de azért még nem győzött meg teljesen. Aztán előhúzott két adu ászt is a mellényzsebéből. Az első ász (célprémium sikeres bevezetés esetén) tűnt ott helyben a nagyobb számnak, de mióta kijöttem az irodából, a másik ászon jár az agyam: felajánlották, hogy annyi kapcsolódó képzésre mehetek el az új rendszerrel kapcsolatban, amennyit nem szégyellek, és én választhatom ki az új rendszerrel kapcsolatban a szerepemet és feladataimat. Ez utóbbi persze még eléggé homályos, de végre nem munkaidőn kívül kell informálódnom az újdonságokról vagy néznem az online szakmai képzéseket. Van, amiről még papírt is kaphatok sikeres vizsga után. Na, a vizsgázás azért nem vonz, de a papír növeli a munkaerőpiaci értékemet. Ezt a párom szokta mantrázni, amikor ő is online tanul épp valamit. Nem mintha itt akarnám hagyni őket, de manapság az ember rendelkezzen B, C, D, sőt ZS tervvel is.

Május:

Kiválasztották az új rendszert. A jelenlegi rendszeren már nem lehet új fejlesztéseket elkezdeni, csak a jelenlegieket befejezni, és a működést fenntartani. Ezzel felszabadult némi időnk, de rögtön be is táblázták, mert elkezdődtek az egyeztetések. Nekem egyenlőre kevés feladatom van, csak néhány adatbázis lekérdezés a törzsadatokban, utána ennek átnézése és tisztítása a többi kolléga feladata. Nem irigylem őket, de én aztán biztos nem tudom azt megmondani, hogy az általuk bevitt vevői adatok jók és frissek-e. Plusz megkaptam azokat az online tréningeket, amiket a beszállító ajánlott. Arról eddig nem volt szó, hogy a szakmai tudásom mellett az angol tudásomat is pallérozni fogják!?

Július:

Kezdem látni, mi mindent kell majd másképp csinálnunk a felhőben. Nem mindegyik tetszik, meg kell hogy valljam. Az adatbázishoz továbbra sem lehet hozzáférni, ez valamennyire még bosszant, de még nem találtam olyan adatot, amit az API-kon és interfészeken keresztül ne tudtam volna kinyerni a rendszerből. A riportok készítése nem nagy kihívás, de még nem látjuk, hogy a felhasználók hajlandók lesznek-e megtanulni a használatát és átveszik a riportálási feladatokat, vagy megmarad IT berkeken belül.

Sokkal izgalmasabbnak tűnnek az integrációs feladatok és lehetőségek. Mivel így is maradt több terület, amit az ERP rendszer nem fed le (megnézem azt a nem-magyar fejlesztésű ERP-t, aki hajlandó a magyar bérszámfejtési gyakorlatot leprogramozni!), így ezekkel továbbra is foglalkoznunk kell majd. Ezt izgalmas kihívás lesz majd megtervezni, és már most látok olyan pontokat, amiket a projektbe nem vettek bele, de ezekkel az eszközökkel meg lehetne próbálni megoldani. Merthogy kapunk (vettünk) eszközöket is. Még tanuljuk a használatukat. Vannak korlátaik, de új dimenziókat is nyitnak. Mivel nem csak az ERP-vel kapcsolatosan lehet ezeket az eszközöket használni, így a többi rendszerünk közötti összekötést és kommunikációt is meg lehet velük oldani.

A környezetmenedzsment nagyon át fog alakulni. Effektív munka sokkal kevesebb lesz benne, hiszen a felhőben valahol máshol, mások tartják karban a vasat, cserébe sokkal több időt kell szánni a felhasználási elemzésekre, és a változtatások megtervezésére - hiszen bármit is szeretnénk kérni, 1-4 hetes átfutási időkkel kell számolnunk. Nincs több 'Légyszi, másold le a rendszert holnapra, mert kell egy új teszt'! Apropó tesztelés, úgy tűnik, ez egy teljesen új feladat- és szerepkör lesz. Mivel a felhőben rendszeresen végeznek kisebb-nagyobb változtatásokat, így nekünk is rendszeresen kell ezeket tesztelni, és rögtön szólni, ha valamelyik folyamatunk 'eltörne' a változtatások következményeképpen. És bár kisebb az ilyen irányú módosítás esélye, de az integrációkat is minden egyes alkalommal tesztelni kell, és szükség esetén módosítani.

A felhasználók első körös támogatását is megtarthatjuk cégen belül, ha úgy döntünk, a változás annyi lesz, hogy a következő támogatói kör már a globális support, annak minden jellemzőjével. De ha az éles üzem alatt is olyan gyorsan reagálnak, mint a tesztelések alatt, akkor csak megszokjuk mi is.

Augusztus:

Beszéltem a főnökkel, megegyeztünk, hogy mik lesznek a feladataim. Már gyakorlom is őket a tesztrendszeren, és várom az éles átállást. Kispadról nézem az oktatásokat, és ahogy a felhasználók egy része próbál ellenállni a változásnak, pedig ez már egy lefutott meccs. Aki megkérdez, annak elmondom, hogy használja ki az új helyzet adta lehetőségeket, legyen az tanulási lehetőség, vagy a folyamatok alakítása. Mert ők is jobban járnak, ha meglovagolják a változás áramlatát, mint ha ellenállnak neki.

Október:

Egy hónapja elindult az éles rendszer. Egyenlőre csak a legáltalánosabb folyamatokkal, és a legfontosabb integrációkkal, de a kivételkezeléseken és a többi integráción továbbra is dolgozunk a bevezető csapattal. Két hete teljesen átadták a support és környezetmenedzsment feladatokat a jelenlegi funkciókon nekünk, azóta mi figyeljük ezeket. Azt kell mondjam, hogy nagyobb gikszer még nem volt. A felhasználókkal is csak az első héten kellett intenzíven foglalkozni, amikor még az oktatás ellenére is kicsit ismeretlen és ijesztő volt a rendszer, de azt még a bevezető csapat intézte. De azóta már felbátorodtak, email-en intézik a jóváhagyásokat, sőt a riporting eszközről is egyre többet kérdezgetnek tőlünk. Lezajlott az első hónapzárás, ott azért voltak bizonytalankodások, de a bevezető csapattal karöltve megoldottuk ezeket is. Most épp készülünk az első ütemezett update-re, ismerkedünk az újdonságokkal, és tervezzük, előkészítjük a tesztelést. Nem mondom, egy napig oda kell tolni magunkat a tesztelés során, de ha minden flottul megy, akkor negyedévente ennyi belefér.

Mozgalmas félév van mögöttünk, és még mindig vannak mozgásban lévő dolgok. A második és harmadik fázisba betervezett funkciók és integrációk még folyamatban vannak, mi belsőleg pedig elkezdtük tervezni, hogy az integrációs eszközt hogyan tudnánk a többi rendszerrel kapcsolatban munkába állítani. Azt kell mondjam, hogy tényleg érdemes volt ezt a váltást meglépni, sok újat tanultunk, és a felhasználók is el tudják végezni a munkájukat, csak kicsit másképp.

De a VASat még nem selejteztük le. Jó lesz tartaléknak!

Üzleti folyamatok automatizálása Automation Anywhere eszközökkel

2020-09-15T08:34:55Z

Az Ixenit Kft. a 2020. év folyamán megbízást kapott a budapesti ZETA Kft-től üzleti folyamatainak felmérésére és az automatizációra alkalmas folyamatok azonosítására a cég üzleti és működési prioritásai alapján.

A megbízó egy kötőelemek és rögzítéstechnikai elemek kiskereskedelmével és technológiai tanácsadással foglalkozó vállalkozás, mely az adminisztratív és készletgazdálkodási feladatait elsősorban irodai alkalmazások, valamint egy magyar fejlesztésű ügyviteli rendszer használatával oldja meg.

A folyamatok priorizálása, komplexitásuk, valamint az automatizáció megvalósíthatóságának és az automatizáció várható megtérülésének elemzése alapján a megbízóval közösen a „Nem teljesíthető vevői megrendelések feldolgozása” elnevezésű folyamatot választottuk automatizálásra első körben.

A kiválasztott folyamat célja: a vevő egy konkrét gyártó konkrét termékére ad le rendelést, de amennyiben attól a gyártótól nem áll rendelkezésre raktárkészlet a cikkből, másik gyártó ugyanolyan típusú, készleten lévő termékét kell ajánlani, figyelembe véve, hogy az adott vevő máskor is elfogadott helyettesítő terméket. Erről az ügyintéző e-mail értesítést kap, így teljesíteni tudja a megrendelést.

A folyamat automatizálásával a megbízó napi 1,5 órányi, részben manuális munkát takarít meg a feladatot korábban végző munkatárs számára.

Az automatizációt Automation Anywhere A2019 Community Edition segítségével valósítottuk meg. Ez egy bot fejlesztő és egyben futtató regisztrációt jelent, melyet a megrendelő virtuális gépére telepítettük. A virtuális gépen az Open Office csomag Calc programja, illetve Notepad program volt elérhető.

Az ügyviteli rendszer egy Windows operációs rendszeren futtatott szoftver, mely több sokfunkciós felületi elemmel rendelkezik (vagyis többször ugyanarra az elemre kattintva más funkciók válnak elérhetővé). Ennek ismeretében (továbbá mivel sem fő menüpontokat, sem a táblázatcellákat nem tudta az A2019 megkülönböztetni, csupán egyetlen nagy objektumként azonosította) a fejlesztés során kiemelt szerephez jutottak a billentyűkombinációk és a koordináta alapú kattintások.

Az alábbi videóban mutatjuk be a szoftverrobot működését.

A blogbejegyzés társszerzője: Hlacs Emese

Hogyan könnyítheti meg a NAV online a vállalati adminisztrációt?

2020-08-25T11:28:20Z

Köztudott, hogy 2020 július 1-től kötelező az adatszolgáltatás az ÁFA tartalom mértékétől függetlenül a NAV felé minden, nem magánszemélyeknek kibocsátott számla teljes tartalmáról. Ez azok számára, akik a számlázó rendszerükből elektronikus úton készítik el a számlájukat, nem jelent különösebb plusz feladatot, mert a számlázó rendszernek (optimális esetben) fel kell készülnie a törvényi előírás szerinti NAV adatszolgáltatásra. A kézi számlák kiállítóinak viszont naprakész adatfeltöltési kötelezettség van előírva.

A NAV a megkapott számlainformációkat egy úgynevezett NAV XML-ben dolgozza fel, melyet minden számlára külön-külön készít el. Ez első ránézésre a NAV számára könnyíti és gyorsítja meg a számlák ellenőrzését, de ez a fajta adatszolgáltatás magában rejt egy olyan lehetőséget is, mely azoknak a munkáját segítheti, akik részére a számlát kiállítják.

Mutatjuk hogyan...

Az e-Zóna NAV online kommunikációval lehetősége van a vevőknek arra, hogy a részükre kiállított számlák alapján készült NAV XML-t meghatározott időközönként letöltsék. Az így megkapott számlainformációk sok esetben már a számla megérkezése előtt a vevők rendelkezésére állhatnak.

A beérkezett számlákat a digitalizálás (papíralapú számlák), vagy a megkapott pdf formátum (elektronikus formában küldött számlák) után az e-Iktatóba betöltve, a megfelelő sablon alapján be lehet azonosítani, össze lehet párosítani a megfelelő NAV XML-lel. A folyamat eredménye egy olyan „csomag”, amelyben rendelkezésünkre áll a digitális számlakép, és a hozzá tartozó összes számlainformáció, melyet szükség esetén a megfelelő kontírkódokkal kiegészítve akár automatikusan is beemelhetünk az ERP-be.

Ezzel a megoldással a teljes szállító számla könyvelési folyamat automatizálható, így csökkentve az adminisztrációs terheket, és minimalizálva a hibázási lehetőséget.
A módszernek köszönhetően gyors és pontos adatokhoz juthatunk. A számlaadatok begyűjtéséhez pedig nincs szükség OCR használatra. Nézzük az egyszerűsített folyamatot:

Előnyök összefoglalva:

- Teljes szállító számla könyvelési folyamat automatizálása

- Gyors információszerzés

- Pontos – NAV-nyilvántartással egyező adatok

- Hibázási lehetőség minimalizálása

- OCR használatának szükségtelensége

Gyakori kérdések

Mi is az az e-Zóna NAV online kommunikáció?

A kötelező NAV adatszolgáltatáshoz használt, saját fejlesztésű alkalmazás, mely eddig a felküldendő számlákkal kapcsolatos kétirányú kommunikációt végezte. Az új - bejövő számla kezelés funkció is ezzel a kommunikációs modullal történik, mely folyamatos kapcsolatban van a NAV online-nal.

Hogyan tudom igénybe venni, ha nem e-Zóna számlázóprogramot használok?

Az e-Zóna NAV online kommunikációt úgy készítettük el, hogy a helyi sajátosságokat figyelembe véve (Proxi, Middlware, stb) bármilyen ERP-vel, vagy számlázó rendszerrel összekapcsolható legyen. Ennek köszönhetően akár a kimenő, akár a bejövő számla kezelés modul integrálható bármilyen rendszerhez.

Az e-Iktató szükséges-e a használathoz?

Az e-Zóna Iktató modulja nem szükséges a bejövő számla feldolgozáshoz, bármilyen meglévő iktató rendszerrel integrálható, vagy annak hiányában lehetőség van az e-Iktató szükséges funkcióinak a beépítésére a teljeskörű megoldás érdekében.

Amennyiben szeretné a szolgáltatást igénybe venni, vagy további kérdései merültek fel, keressen minket bizalommal a sales@ixenit.com-on!

Vállalati tervezés és elemzés Oracle EPM támogatással

2020-08-12T12:03:40Z

Mi az EPM Cloud?

Az Oracle Enterprise Performance Management Cloud (EPM Cloud) olyan teljeskörű üzleti folyamatokat kínál, melyek a legtöbb vállalat által támasztott követelményekhez rugalmasan hozzáigazíthatók és a vállalat hatékonyabb működését, a változásokra adott agilisebb reakciókat segítik elő. Előfizetéssel két verziója érhető el: az EPM Standard és az EPM Enterprise Cloud Service. Az Enterprise előfizetés a Standardhoz képest néhány olyan további üzleti folyamatot, illetve funkcionalitást tartalmaz, melyek kifejezetten nagyvállalatokat céloznak, tehát a megkülönböztetés a vállalati méreten alapul.

Az elérhető üzleti folyamatok:

Planning
Account Reconciliation
Financial Consolidation and Close
Narrative Reporting
Enterprise Data Management
Profitability and Cost Management
Tax Reporting

Utóbbi három üzleti folyamat az, amely csak az Enterprise verzióra előfizetők számára érhető el, bár a Data Management ha nem is teljes egészében, olyan mértékben azért jelen van az EPM Standard Cloudban is, hogy az adatforrásokat integrálni tudjuk. Ezen felül pedig a Standard szolgáltatáshoz is jár a Smart View, ami egy Microsoft Office interfész és az EPM Automate, ami egy parancssoros interfész egyes ismétlődő feladatok automatizálására (pl. fájlok feltöltése, törlése, dimenziók vagy adatok betöltése a forrás rendszerekből stb.).

Ha a mindkét verzióban elérhető üzleti folyamatokat nézzük, ezeken belül is vannak olyan funkciók, melyek csak az Enterprise kivitelben használhatók. Ezek jellemzően a még jobb egyedivé szabhatóságot vagy a még magasabb fokú automatizációt biztosító funkciók.

Vegyük sorra az EPM Cloud által támogatott üzleti folyamatokat és ezek főbb jellemzőit!

1. Planning

A tervezésnél öt modul érhető el: pénzügyi, munkaerő-, projekt-, tőketervezés és stratégiai modellalkotás.

A pénzügyi tervezés során bevétel- vagy költségvezérelt jövedelemkimutatás, mérleg és cash flow kimutatások tervezésére, elemzésére van lehetőségünk. A tervek és előrejelzések grafikusan is megjeleníthetők.

A munkaerő tervezése esetén a létszámot és a juttatásokat tervezhetjük, továbbá ezeket hozhatjuk a pénzügyi terveinkkel összhangba. A jövőbeli létszámot a tervek természetesen minden személyi jellegű ráfordítással, bérekkel, juttatásokkal, adókkal, egészségügyi kiadásokkal, bónuszokkal stb. együtt képesek számításba venni, továbbá a szolgáltatás az egyes részlegek együttműködésére is lehetőséget kínál, így terveinkben az emberi erőforrások, részlegek közötti átcsoportosításával is számolhatunk.

Modellezhető a jövőbeli létszám a kapcsolódó költségekkel. Könnyedén hozzáadhatunk új alkalmazottakat különböző feltételezésekkel, amelyek befolyásolják a bér, juttatások, adók stb. számítását. Hasonlóan a tervezés a jelenlegi munkavállalókra is elvégezhető a munkakörök változtatásával vagy a részlegek közötti mozgásokkal. (Kép forrása: oracle.com)

A projekttervezés a klasszikus projektterveket segít összhangba hozni a rövid- és hosszútávú pénzügyi tervekkel. A modul különböző projekttípusokra van felkészítve, legyen az belső, nem bevételtermelő projekt (pl. IT, marketing, kutatás fejlesztés), szerződéses projekt vagy befektetési projekt.

A tőketervezés a befektetett eszközök pénzügyi tervre vonatkozó hosszútávú hatásait segít megtervezni. Lehetővé teszi a jelenlegi és a jövőben beszerezni kívánt eszközök nyomon követését, ezek eredménykimutatásra gyakorolt hatásait, továbbá lízingelt eszközök kezelését és nyilvántartását, valamint az értékcsökkenés követését is.

Tervezhetjük például a meglévő eszközeink pénzügyi hatásait különböző forgatókönyvek szerint (pl. átmozgatás, selejtezés, felújítás) és a kapcsolódó költségek (pl. biztosítás) figyelembe vételével. (Kép forrása: oracle.com)

A stratégiai modellalkotás során pénzügyi előrejelzések és modellezési eszközök elemezhetők különböző forgatókönyvek szerint, ezzel támogatva a hosszútávú stratégiatervezést.

Az Oracle EPM Enterprise Cloud Service a fenti öt modult három további funkcióval is felvértezi. A fenti modulalapú tervezés során ún. dimenziókat hozunk létre, melyek előre adottak és egyesek kötelezően használandóak is az egyes modulokban (pl. pénzügyi tervezéskor létre kell hozni egy főkönyvi szám dimenziót), majd a terveket ezen dimenziók mentén állíthatjuk össze. Az Enterprise ügyfeleknek lehetőségük van “free form” tervezésre, mely esetén nincsenek ilyen jellegű megszorítások a dimenziók kialakításakor. Készíthetünk saját folyamatokon alapuló egyedi terveket, végül a Groovy leíró nyelv révén különböző egyedi üzleti szabályok hozhatók létre a tervezési folyamatok során.

2. Account Reconciliation

A főkönyvi számlák egyeztetése biztosítja, hogy az egyenlegek a valóságnak megfelelőek. Ez az üzleti folyamat segíti a számlaegyeztetési folyamatot, a mérleg egyeztetését, a konszolidációs rendszerek összeegyeztetését, illetve bármely egyéb számlaegyeztetési folyamatot is. Az egyeztetések bármely, a vállalat számára megfelelő szinten történhetnek. Szabályok definiálásával társíthatjuk a számlaegyenlegeket az egyeztetésekhez. Az Enterprise verzióban a tranzakciókkal való automatizált összepárosításra is van lehetőség, ami a folyamatot nagy mértékben képes felgyorsítani és nagy tranzakciószám esetén jelentős munkaerő ráfordítás takarítható meg.

A számlaegyeztetések során vizuálisan is jól láthatóak az eltérések. A fenti képen például a főkönyv és az analitika közötti akadt különbség. A példában szereplő felhasználó így a kollégáitól kér segítséget az eltérés okának kiderítésére. Természetesen ez az alkalmazáson belül megoldható. (Kép forrása: oracle.com)

Saját magunk számára alakítható összefoglaló képernyőkön a teljes egyeztetési folyamatról is áttekintést kaphatunk és a határidők betart(at)ását is segíti a rendszer. (Kép forrása: oracle.com)

3. Financial Consolidation and Close

Ez az üzleti folyamat előre definiált és saját magunk által létrehozott kalkulációkkal, illetve automatizált lépésekkel segíti a pénzügyi konszolidációt. Kezeli az eltérő tulajdonlási arányokat és az üzleti egységek különböző, sokszor bonyolult struktúráit is.

A pénzügyi zárási folyamathoz sablonok definiálhatók, melyekkel időzített feladatokat kezelhetünk, tevékenységeket importálhatunk, változásokat tehetünk közzé és periódusokat nyithatunk meg.

Könnyedén áttekinthetők a záráshoz hátralevő lépések a függőségeikkel együtt. A feladatok könnyen beállíthatók és igény esetén további lépésekkel is kiegészíthetők. (Kép forrása: oracle.com)

A lépések akár felhasználókra lebontva is megtekinthetők. (Kép forrása: oracle.com)

4. Narrative Reporting

Az Oracle EPM Cloud egy biztonságos, kollaboratív, folyamatvezérelt megközelítést nyújtó hátteret biztosít a vállalati kimutatások, beszámolók elkészítésére, melyben a dokumentumok létrehozásán túl azok ellenőrzésére, jóváhagyására és megvitatására is teret enged, az Enterprise verzió esetén pedig a közzététel is könnyedén az EPM Cloudon belül valósítható meg (pl. kormányzati szervek, adóhatóság részére). A Smart View segítségével a jól ismert Microsoft Word és PowerPoint felületein és ezek funkcióinak használatával készülhetnek riportok, éves jelentések, beszámolók, az ezekhez szükséges táblázatokat, grafikonokat pedig a kiinduló adatokból Excel segítségével hozhatjuk létre.

A Report Center felületen láthatók az egyes riport csomagok előrehaladása. Itt egy riport csomag szerkesztési fázisa már elkészült, minden dokumentum hozzá lett adva, viszont az átnézés késésben van. Pár hozzászólás is még megválaszolásra vár. Ha mindenki elkészül, kezdődhet az aláírási fázis. (Kép forrása: oracle.com)

A dokumentumok szerkesztése és átnézése közben is lehetőség van az együttműködésre. (Kép forrása: oracle.com)

5. Enterprise Data Management

Az EDM egy modern, agilis adat menedzsment eszköz, mely képes összehangolni a vállalati alkalmazásokat, elvégezni az ehhez szükséges adatkonverziókat és felgyorsíthatja a felhőalapú technológiákra való átállást.

Minden alkalmazás, melynek adatait az EDM-ben kezeljük, regisztráljuk és importáljuk az alkalmazásba. (Kép forrása: oracle.com)

Ezt követően az adatok láthatók és módosíthatók. A fenti képen egy új érték felvételének folyamata éppen jóváhagyási fázisba került. (Kép forrása: oracle.com)

A változtatások pedig a beépített szolgáltatás segítségével a kapcsolódó rendszerek számára átadható, így biztosítható, hogy az adatok konzisztensek maradnak a vállalat minden rendszerében. (Kép forrása: oracle.com)

6. Profitability and Cost Management

Ez az üzleti folyamat kezeli a bevétel- és költségallokációt, ami az üzleti egységek nyereségességének kalkulációjához használható fel. A tényleges tervezés és döntéstámogatás érdekében a nyereség kimutatására költségfelosztást, felhasználás alapú árkalkulációt és forgatókönyveket használhatunk.

A Dashboard gyors áttekintést ad a vállalat teljesítményéről. Természetesen mélyebben is betekintést nyerhetünk az adatokba. (Kép forrása: oracle.com)

A Smart View segítségével számszerűen is jól átláthatók például a szabályok szerinti költségfelosztások. (Kép forrása: oracle.com)

7. Tax Reporting

A Tax Reporting üzleti folyamat a GAAP vagy IFRS standardok szerint riportáló nemzetközi vállalatok számára nyújt átfogó megoldást az adó megállapításra, magába foglalva a társasági adómegállapítás folyamatának minden elemét.

Az adók megoszlása itt országok és adónemek szerint is látható. (Kép forrása: oracle.com)

Az EPM Cloud használatba vétele

Az Oracle EPM Cloud szolgáltatás üzleti folyamatai számos ponton tudják támogatni a vállalatok döntéshozatali folyamatait a hatékony tervezés, előrejelzés, riportálás és a vállalat teljesítményének mérése révén. A szolgáltatások előfizetéses rendszerben érhetők el. Az EPM Cloud Service landing page-ről választhatja ki a Service Administrator, hogy melyik üzleti folyamatra szeretnénk létrehozni az alkalmazást. Minden előfizetéssel két alkalmazás hozható létre: egy teszt és egy éles környezet. Amennyiben több üzleti folyamatot is igénybe szeretnénk venni az EPM Cloud által kínált lehetőségek közül, újabb alkalmazások igénylésével tehetjük meg. Az alkalmazás létrehozásához néhány alap információt, beállítást kell megadnunk, majd a létrehozás gombra kattintva néhány percen belül elkészül a környezet. Az alkalmazásokat demo adatokkal is létrehozhatjuk, mely segítséget jelenthet az alkalmazás funkcióinak megismerésében. Miután a tesztrendszeren elkészültünk az alkalmazásunk beállításaival, használatra készek az adataink, pillanatfelvételt készíthetünk róla, amit exportálhatunk és például az éles környezetre importálhatunk, így az éles környezet beállítása már gyorsan és egyszerűen elvégezhető.

Kalandozás az Oracle felhőben

2020-07-22T12:04:06Z

1. rész: Elmélet

Mi az az OCI?

Az Oracle az elmúlt években gőzerővel dolgozott azon, hogy a felhős szolgáltatásokban is szintre hozza a képességeit, sőt innovatív megoldásokkal meg is előzhesse főbb versenytársait, akik ezen a területen az Amazon AWS, Microsoft Azure és Google Cloud. Az IaaS (Infrastructure-as-a-Service) és PaaS (Platform-as-a-Service) szegmensben is olyan arzenált vonultat fel az Oracle 2. generációs (Gen2) felhője, amely árban és minőségben is felveszi a kesztyűt.

Leegyszerűsítve: a felhő szolgáltatók számítókapacitást és szoftvert adnak bérbe ügyfeleiknek úgy, hogy az üzemeltetés egy részét vagy akár egészét a szolgáltató végzi. Az alapján különböztetjük meg az IaaS, PaaS és SaaS szegmenseket, hogy az erőforrásoknak mekkora részét menedzseli a szolgáltató. Természetesen a csomag részét képezi az is, hogy a távoli szervereken futó erőforrásainkat összehangoltan kezelni, skálázni és felügyelni tudjuk, beleértve ebbe a költségek kordában tartását is.

A továbbiakban az Oracle Cloud Infrastructure világát járjuk körbe, és ezen belül is elsősorban az IaaS területhez tartozó elemeket. Megjegyzendő, hogy az IaaS / PaaS határvonalak időnként kissé összemosódnak. A szolgáltatók ezzel is egy egységes, koherens platform képét próbálják sugallani, és ténylegesen egyetlen Oracle accounton keresztül hozzáférhetünk az IaaS, PaaS, SaaS kínálat teljes skálájához. Amiről most nem lesz szó bővebben: az OCI keretében elérhető PaaS szolgáltatások, elsősorban fejlesztői és integrációs eszközök, mint a Java Cloud, a Visual Builder vagy az Oracle Integration.

A felhővel való ismerkedést kezdhetjük lépésről lépésre, koncentrálva az általunk fontosnak és érdekesnek vélt részekre. De azért nem árt előre tudni, hogy mibe vágunk bele. A sok idegenül hangzó szakkifejezés, szolgáltatásnév és menüpont elsőre nagyon riasztó lehet. Ha az alapokat átlátjuk, könnyebb lesz eligazodni, és megérteni, hogy pontosan mi történik a második, gyakorlati részben.

A fogalmak tisztázásakor többnyire a hivatalos magyar fordításokat használom, mivel az OCI Console (azaz a webes kezelőfelület) magyar nyelven is elérhető. Néhány magyarítás szerintem elég furán hangzik, a biztonság kedvéért feltüntetem az angol változatot is zárójelben.

Fizikai tagoltság

Ha felhőről beszélünk, hajlamosak vagyunk valami elvont, megfoghatatlan dologra gondolni, amiből felhasználóként nagyjából csak egy webes felületet érzékelünk. A valóságban persze minden felhős szolgáltatás valós fizikai hardvereken fut egy adatközpontban. Az Oracle esetében az Exadata szervereket kifejezetten úgy tervezték, hogy az Oracle adatbázissal minél hatékonyabban együttműködjön. Ebből a csúcstechnológiából hasíthatunk ki mi is egy apró (vagy akár nagyobbacska) szeletet az OCI-on keresztül.

Régiók

Amikor regisztrálunk egy Oracle Cloud accountot, meg kell jelölnünk, hogy a „bérleményünk” (tenancy) melyik régióban leleddzen (home region). Európában jelenleg Frankfurt, Amsterdam, London és Zürich közül választhatunk, de világszerte minden földrészen van több választható régió, és persze folyamatosan bővül a választék. A kormányzati szektor ügyfelei számára elkülönített régiók vannak dedikálva. Célszerű minél közelebbi régiót választani, hogy minimálisra csökkentsük a hálózati várakozási időt (latency). Az viszont fontos, hogy nem vagyunk egy régióra korlátozva. Ugyanazzal az accounttal egyszerre több régióban is használhatunk erőforrásokat, ezeket virtuális hálózatokkal összekapcsolhatjuk. Így a magas rendelkezésre állás és katasztrófavédelem (HA/DR) legszigorúbb elvárásait is teljesíteni lehet.

Hibatűrés régión belül

Egy régión belül lehet több „rendelkezésre állási tartomány” (Availability Domain), melyek fizikailag elkülönített, de földrajzilag egymáshoz közel levő adatközpontokat jelentenek. Ezen túl minden AD három különálló „tartalék tartományra” (Fault Domain) van bontva. A különböző FD-k önálló hardver csoportokat jelentenek, amelyek között nincsen átfedés, és külön áramellátásuk is van. Tehát az egyikben beálló váratlan műszaki hiba vagy áramkimaradás nincsen kihatással a többire. Az erőforrások, például virtuális gépek létrehozásakor az AD és FD is szabadon választható. Ezáltal biztosíthatunk egy régión belül is megfelelő hibatűrő képességet a hálózati infrastruktúránknak.

Az erőforrások logikai szervezése

Rekeszek és címkék

A bérleményen (tenancy) belül minden OCI erőforrást (virtuális gépet, adatbázist, tárhelyet, stb.) egy konkrét logikai egység, úgynevezett „útvonalválasztási szegmens” (compartment) alatt hozhatunk létre. A tömörség végett ezeket a továbbiakban rekesznek fogom hívni, mert itt a magyarítást elhibázottnak éreztem. A rekeszek hierarchikusan egymásba ágyazhatók. A bérleménnyel együtt automatikusan létrejön egy gyökér (root) rekesz, ami a bérlemény nevét viseli, ezen belül hozhatjuk létre a többi rekeszt. A rekeszekhez rendelhetünk hozzáférési szabályokat, amelyeket a rekeszben levő összes erőforrás és alrekesz megörököl. Emiatt célszerű külön rekeszbe tenni a teszteléshez, fejlesztéshez használt (sandbox) és az élesben futó (production) erőforrásainkat, de ennek kialakítása teljességgel rajtunk múlik. Erőforrást másik rekeszbe mozgatni nem lehet, de rekeszek közötti hozzáférést lehet engedélyezni. A rekeszek átívelnek az AD-kon és a régiókon is, a különböző fizikai helyen levő erőforrásokat közös csoportba foghatják össze.

Az OCI-ban használt dolgainkat emellett címkékkel (tag) is elláthatjuk. Minden címke egy kulcsból és egy értékből áll. Kétfajta címkét használhatunk: kötetlen (free-form), illetve előre definiált, ahol a címke névtéren belül a kulcsokat határozzuk meg előre, és opcionálisan megadhatunk előre rögzített értéklistát is. A címkék alapján kereshetünk, és használhatjuk szűrőfeltételként a konzolban elérhető költségelemzés (cost analysis) riporton belül. Ez elősegíti a felhős költések tervezését és felügyeletét.

Hozzáférési rendszer

A felhős jogosultságok kezelésére az Identity and Access Management (IAM) nevű keretrendszer szolgál. Ebben hozhatunk létre új felhasználókat (user), akiket csoportokhoz (group) rendelhetünk. Az „alapszabályok” (policy) határozzák meg, hogy melyik csoport, melyik rekesznek milyen típusú erőforrásain milyen műveleteket végezhet. A szabályokat egy viszonylag közérthető, angol-szerű leíró nyelven kell megfogalmazni, például az alapértelmezett Tenant Admin Policy így néz ki:

ALLOW GROUP Administrators to manage all-resources IN TENANCY

Virtuális hálózat

Hálózati topológiánk kialakítására a „felhőalapú virtuális hálózatokat” (virtual cloud network, VCN) használhatjuk. Itt határozzuk meg, hogy az egymással kommunikáló hálózati elemek milyen portokon keresztül érintkezhetnek, és hogy a publikus internetről érkező forgalmat hova irányítjuk. Létrehozhatunk zárt (private) vagy nyilvános (public) alhálózatokat (subnet). A virtuális hálózatok a rekeszekhez hasonlóan átívelhetnek régiókon is.

Elérhető szolgáltatások

Aki már találkozott más felhő szolgáltató kínálatával (pl. Azure, AWS), az találhat ismerős tételeket a következő listában. Az OCI központi eleme és húzóterméke mindenképpen az adatbázis, de az infrastruktúra szolgáltatás kikerekítéséhez számos open source technológiát is beépített az Oracle, és ez a hordozhatóság szempontjából előnyösnek tekinthető.

Először vegyük sorra az ingyenesen elérhető és használható elemeket:

Adatbázis
- Az Oracle világszínvonalú és innovatív adatbázis szolgáltatásának kétféle változata van: Autonomous Transaction Processing (ATP) és Autonomous Data Warehouse (ADW). Ez a kettő valójában ugyanaz a termék, csak a paraméterezésben (tárolási mód, lekérdezési sebesség) különbözik. Az ATP általános üzleti alkalmazásokhoz való, az ADW pedig adattárház és analitikus célokra.
- Az autonóm adatbázisokba számos, mesterséges intelligenciával is támogatott automatizmus van építve, amelyek segítségével a rendszer önmagát optimalizálja, felügyeli és karbantartja, DBA beavatkozásra szinte csak a monitoring területén lehet szükség.
- A relációs adatmodell mellett támogatja a JSON, key-value, blockchain, geolokációs és gráf adattípusokat is (lásd: konvergens adatbázis), ezáltal minden elképzelhető adatbázis-igényre megoldást kínál egyetlen mindentudó termékben.
- Az adatbázisnak része az APEX, ami egy low-code fejlesztőeszköz adatcentrikus alkalmazásokhoz.
- A gépi tanulás (machine learning) munkafolyamatokat beépített Apache Zeppelin munkafüzetek, és az adatbázisból közvetlenül hívható, PL/SQL alapú statisztikai és ML függvények támogatják.
Virtuális gépek
- A számítókapacitást (compute) virtuális gépek (virtual machine instance) formájában bérelhetjük, amelyek előre meghatározott vagy rugalmasan skálázható processzor- és tárkapacitással, előre telepített oprendszerrel igényelhetők (többféle választható Linux, vagy akár Windows Server).
- Az összehasonlíthatóság végett az Oracle az OCPU/hour mértékegységet használja, ez egy processzor egy órán át tartó használatát jelenti, és ez képezi leggyakrabban az árazás és számlázás alapját is.
- Az igényelt virtuális gépeket tetszés szerint leállíthatjuk és újraindíthatjuk. Terminálon keresztül SSH használatával tudunk bejelentkezni, és bármit telepíthetünk rá.
- Másik fajta compute opció a bare metal, amely egy virtualizáció nélküli dedikált hardverkörnyezetet jelent, egy kicsit borsosabb áron.
Tárhely
- A „blokkalapú köteg” (block storage) egy VM-hez csatlakoztatható extra tárterületet jelent, amit adatok mozgatásához vagy biztonsági mentéshez is használhatunk.
- Az objektumtár (object storage) egy nagyon hasznos koncepció, nem strukturált objektumok ideiglenes vagy tartós tárolására alkalmas. Keresztül lehet folyatni rajta logokat, IoT adatokat, illetve lehet feltölteni tetszőleges fájlokat, és megosztani publikusan vagy kulcs ellenében, meghatározott érvényességi ideig.

További ingyenesen használható kiegészítők:

Terheléselosztó (load balancer)
- A beérkező adatforgalom szétterítése több kiszolgáló között a virtuális hálózaton belül.
Rendszerfigyelés (monitoring) és riasztások (alarms)
- Az általunk konfigurálható metrikák, KPI-ok segítségével követhetjük nyomon a felhőnk egészségi állapotát és teljesítményét
Értesítések (notifications)
- Ezeket kiválthatja egy rendszeresemény (bármely akció vagy történés, amely az OCI tevékenységei között logolásra kerül), vagy egy rendszerfigyelő, vagy külső alkalmazás REST API-n keresztül. Az értesítés történhet emailben, HTTP protokollon keresztül (API hívás), vagy egy függvény hívásán keresztül.
Erőforrás-kezelő (resource manager)
- A Terraform open-source alkalmazás segítségével megvalósul az „Infrastructure-as-code” koncepció: komplett hardver és szoftver környezeteket, hálózati konfigurációkat írhatunk le egy adatfájlban, és élesíthetjük egy gombnyomással a hozzájuk tartozó OCI erőforrásokat. Ez nagymértékben megkönnyítheti a rendszer-adminisztrátori feladatok automatizálását.

Fizetős fiókkal elérhető elemek:

API átjáró (API gateway)
- API végpontok egyszerű publikálását teszi lehetővé a felhős hálózatunkon belülre és kívülre.
- Az autentikáció az IAM szabályrendszerével integráltan működik.
Függvények (functions)
- Az Fn Project nevű, nyílt forráskódú megoldásra épülő szolgáltatás.
- Serverless web szolgáltatások, minialkalmazások és API-k futtatása konténeres környezetben.
Események (events)
- Meghatározott metrikák alapján az OCI erőforrásokon bekövetkezett változások figyelése
- Automatizált válaszként értesítések vagy funkció hívások kezdeményezése.
Adatfolyamok (streams)
- Apache Kafka-hoz hasonló, publish/subscribe rendszerű üzenetsor (message queue) szolgáltatás.
- Nagy mennyiségű adat (pl. logok) valós idejű feldolgozására alkalmas.
Tárolófürtök (Oracle Container Engine for Kubernetes, OKE)
- Kubernetes fürtök (cluster) telepítésére és menedzselésére alkalmas eszköz az OCI erőforrásait felhasználva.

Always Free

Korábban már írtunk az Oracle Always Free szolgáltatásának beharangozásáról. Ez nem más, mint az Oracle felhő ingyenes kipróbálási lehetősége. A regisztrációval két dologra tehetünk szert:

egy hónapon keresztül 300 USD keretet kapunk arra, hogy az Oracle Cloud Infrastructure bármely fizetős részét teszteljük, kipróbáljuk;
és ezen túl időlimit nélkül szabadon használhatjuk a Mindig ingyenes címkével megjelölt erőforrásokat, a megadott szolgáltatási korlátokon belül (például legfeljebb 2 adatbázis, legfeljebb 2 virtuális gép a legkisebb 1 OCPU mérettel).

A regisztrációnál meg kell adni egy valós hitelkártyát, viszont amíg szándékosan, explicit nem állunk át fizetős fiókra, addig az Oracle garantáltan semmit nem fog számlázni. A 30 nap próbaidő után, ha maradunk Mindig ingyenes státuszban, akkor az Oracle lekapcsolja, illetve automatikusan törli azokat a próbaidő alatt kiosztott erőforrásokat, melyekre nem vonatkozik az ingyenes ajánlat. Erre figyelmeztető üzenetet is kapunk, tehát érdemes jó előre gondolkodni, hogy elkerüljük az adatvesztést.

Személyesen én azt javaslom minden rendszergazdának, DBA-nak, programozónak, hogy ha van rá lehetősége és ideje, akkor barangoljon a felhőben, ismerkedjen az IaaS és PaaS szolgáltatásokkal, az árazási modellekkel, a fejlesztő, kezelő és felügyelő eszközökkel. Érdemes a többi szolgáltató kínálatát is megnézni, hogy legyen összehasonlítási alap. Nem árt tisztában lenni a legfrissebb technológiákkal, amelyek a következő évek IT trendjeit meg fogják határozni, és a jelenlegi IT iparágban megszokott feladatköröket és munkaerőpiaci állapotokat gyökeresen felforgatják. Készüljünk fel a jövőre, tanuljunk és tájékozódjunk. Ha rászánjuk magunkat, hogy regisztrálunk egy Oracle Always Free accountot, akkor érdemes már előzetesen utánanézni a lehetőségeknek, és kész tervvel nekimenni az első 30 napnak, hogy minél több dolgot legyen mód kipróbálni és átlátni ebből a hatalmas, összetett, izgalmas világból. Ne feledjük: egy olyan eszköz lesz a kezünkben, ami képes a legmodernebb technológiákkal a legnagyobb világcégek IT igényeit is lefedni. Ehhez mérten be kell látni, hogy a rendszer teljes komplexitását is lehetetlen 30 nap alatt befogadni.

2. rész: Gyakorlat

Egy mini esettanulmányon keresztül szeretném bemutatni, hogy nekem, aki hivatásosan sem fejlesztő, sem rendszergazda nem vagyok, hogyan sikerül a saját kis félkész hobbiprojektemet feltölteni az Oracle felhőbe. Egy Vaadin keretrendszerben íródó, még félkész Java web alkalmazásról van szó, amit előre becsomagoltam egy Docker konténerbe.

Egyébként az alábbi leíráshoz hasonló, fejlesztőknek szóló recepteket találhatunk az Oracle dokumentációi és az Always Free kipróbálását népszerűsítő hivatalos blogok között is.

Regisztráció és bejelentkezés

Keressük fel a https://www.oracle.com/cloud/free/ címet, és a Start for free gombbal máris elkezdhetjük a regisztrációt. Csak minimális adatot kell megadnunk első körben: ország, email cím, az account neve és típusa (céges vagy személyes), a saját régió, végül a hitelkártya adatai. Az fontos, hogy egy email címet és egy hitelkártyát nem használhatunk fel egynél többször. Az account nevét meg lehet változtatni később, ha nagyon muszáj.

Rövidesen érkezik egy megerősítő emailt (ha mégsem, akkor ellenőrizzük a spam között is). Nagyjából 20 perc alatt az új account teljesen elkészül, és használatba vehető a tenancy.

Az illusztrációkkal most ugrok egy kicsit az időben, mert az én próbaidőm már lejárt, és a menürendszeremben a tételek többsége szürkének látszik, csak az ingyenes opciók vannak kiemelve. Viszont így azt is be tudom mutatni, hogy ennek ellenére az Always Free erőforrásokkal továbbra is lehet használni a rendszert.

Az emailben kapott linken keresztül jelentkezhetünk be a Console-nak nevezett vezérlő képernyőre. A jobb felső sarokban levő földgömb ikonnal lehet nyelvet váltani.

Új rekesz

Létrehozok egy rekeszt, hogy abban tárolhassam a tesztelésre szánt erőforrásokat. Ez a menürendszerben az Identitás / Útvonalválasztási szegmens alatt található, de a menüben bolyongás helyett használhatjuk a lap tetején levő keresőmezőt is. Válasszuk ki az account névvel megegyező gyökér rekeszt, és ezen belül készítsük el a sandbox nevű új rekeszt.

Virtuális hálózat beállítása

Minden compute erőforrást egy VCN-en belül kell létrehozni. Opcionálisan arra is van lehetőség, hogy a VM példány készítésekor ezt rábízzuk a rendszerre default beállításokkal, de most külön lépésben fogom megtenni. A menüben a Hálózatkezelés / Felhőalapú virtuális hálózatok pontot kell keresni. A bal oldali almenü alatt módosítani kell a Lista hatókörét és kijelölni a sandbox-ot mint Útvonalválasztási szegmens. Így a hálózatot már ezen a rekeszen belül fogom létrehozni.

A VCN varázsló elindítása gomb megnyomása után, a VCN internetkapcsolattal opcióval lépek tovább.

A következő képernyőn megadom a VCN nevét (sandbox), a többi beállítást pedig alapértelmezetten hagyom. Az áttekintő képernyőn a Létrehozás gombbal indul a folyamat.

Néhány pillanat múlva el is készül a VCN, és látható az eredmény. Egy dolgot még fontos beállítani: a Nyilvános alhálózat alatt engedélyezni kell egy portot a külső internet felől, amin keresztül az alkalmazásomat el lehet majd érni. Tehát az újdonsült sandbox VCN-ben megnyitom a Nyilvános alhálózat - sandbox nevű alhálózatot (public subnet), ezen belül a Default Security List for sandbox nevű biztonsági listát (security list). A TCP protokoll számára egyedül a 22-es port van nyitva, ez azt jelenti, hogy SSH-n keresztül terminállal be lehet csatlakozni a virtuális hálózatra. Itt hozzáadok egy új bemeneti szabályt (ingress rule), amelyben megnyitom a 8090-es portot bármely külső kliens számára (ezt jelenti a 0.0.0.0/0 forrás CIDR). Azért pont ezt a portot használom, mert így állítottam be a Docker konténerben futó appot. Egy átlagos weblaphoz a 80-as, HTTPS protokollhoz a 443-as portot kell engedélyezni.

Az első virtuális gép

A következő lépés most már a virtuális gép létrehozása, a Compute / Példányok menüből. Megint figyelni kell, hogy a sandbox rekesz (compartment) legyen aktív. VM létrehozás képernyőn a következő opciókat kell megadni:

Név: nem kell túlzásokba esni, ne felejtsük, hogy címkékkel is el lehet látni az erőforrásokat, ha később be akarjuk azonosítani őket. Én maradok a test-webapp névnél.
Útvonalválasztási szegmens: sandbox
Lemezkép kiválasztása: mindenképp a „Mindig ingyenes jogosultság” címkével ellátott képek közül kell választani. Én kipróbálom az Oracle Linux 7.8 opciót, ami a Red Hat alapjaira épített disztro.
Elképzelhető, hogy a választott image nem hozható létre abban a rendelkezésre állási tartományban (availability domain), amelyiket elsőre felkínálja a rendszer. Ilyenkor le kell nyitni „A kialakítás, a hálózat és a tároló beállításainak megjelenítése” szekciót, és másik AD-t választani.
Hálózatkezelésnél is a sandbox VCN-t használjuk, és az alapbeállításnak megfelelően szükségem lesz nyilvános IP címre.
A lap alján az SSH-kulcsok hozzáadása fontos lépés, hogy távvezérléssel rá tudjak csatlakozni a virtuális gépre. Két kulcs van: egy nyilvános (public) és egy titkos (private). A felhőben a nyilvános kulcsot kell a VM-hez társítani, nekem pedig a titkos kulcsra van szükségem a saját gépemen ahhoz, hogy terminálon becsatlakozzak. A Generate SSH keys opció lehetővé teszi, hogy letöltsek egy frissen létrehozott kulcs párt. Utána a nyilvános kulcs (pub) tartalmát az SSH-kulcsok beillesztése opció alatt másoljuk be. Ezt kritikus itt és most megcsinálni, mert utólag sokkal bonyolultabb lenne.

Ezek után elindítom a példány létrehozását, és néhány perc múlva már kész is az új virtuális gép. A nyilvános IP címet fel kell jegyezni a következő lépéshez! A Példányhozzáférés alatt látható.

Szükség esetén, kulcsgenerálás manuálisan terminálban az ssh-keygen paranccsal történhet:

ssh-keygen -t rsa -b 2048 -C "sandbox-webapp-key" -f .\sandbox-webapp-key

Terminál és az app telepítése

Ha a VM már futó állapotban van, akkor elővehetjük a kedvenc terminál programunkat (ssh, putty, openssh…), és csatlakozhatunk a virtuális géphez a nyilvános IP cím és a titkos kulcs használatával. A felhasználói név opc.

ssh opc@158.101.175.118 -i .\sandbox-webapp-key

Egy üres Linux VM áll rendelkezésünkre, amiben először a Dockert telepítem az alábbi parancsokkal:

sudo yum-config-manager --enable ol7_addons

sudo yum install docker-engine -y

sudo systemctl start docker

sudo systemctl enable docker

Engedélyezem a Docker futtatását nem root user számára, ezzel biztonságosabbá tehetem a konténer futtató környezetet:

sudo groupadd docker

sudo service docker restart

sudo usermod -a -G docker opc

Utána ki kell jelentkezni SSH-ból, majd újra belépni. Ezt követően már az alapértelmezett opc felhasználó is futtathat Docker konténert, sudo nélkül.

Most már elindíthatom a Docker Hub-ra publikált konténeremet az alábbi paranccsal:

docker run -d --restart always -p 8090:8080 --name enni maquirag/enni:1.0

A végeredmény: a web app projektem egy web böngészőben, a felhőn kívülről elérhető a publikus IP címen és a megnyitott porton keresztül.

Hogyan működhet az RPA a kis- és középvállalkozásoknál?

2020-07-07T09:11:34Z

Az RPA (robotizált folyamat automatizáció) a nagyvállalatok sikertörténete mindeddig, sok esettanulmány és elégedett licensz-vásárló ügyfél tartozik ebbe a körbe. KKV-k számára azonban sokkal nehezebb olyan eredményeket felmutatni rövid időn belül, amelyért nekik is megérheti belevágni az átalakításba. Ebben a blog bejegyzésben azokat a szempontokat és pozitívumokat gyűjtöttük össze, amik egy kísérletező kedvű vállalat és az Ixenit közös projektjén születtek.

Globális gondolkodás

Az RPA bevezetés egyik legfontosabb eleme a megfelelő folyamatok kiválasztása, amelyekre gyorsan és egyszerűen tudunk jól működő robotokat alkalmazni. Ezek a folyamatok kiszámítható és változatlan kiindulási adatból, kevés szabállyal hoznak létre újakat vagy indítanak el új folyamatokat. Az első automatizált folyamat kiválasztásához az egyik legfontosabb feltétel az, hogy megrendelői oldalról olyan féllel tárgyaljunk, aki a vállalat folyamatait mélységében ismeri és helyesen méri fel azok logikai komplexitását.

Az RPA elterjedésének egyik legnagyobb akadálya, hogy az átlagember nem ismeri az RPA képességeit és határait, ezért mikor folyamatok között kell válogatni automatizálás céljából, minél több folyamatot érdemes egyidejűleg átlátni. Ez sokszor egyszerűbb egy KKV-nál, ahol a szervezeti működés szerepkörei nem elszigetelten működnek, hanem egy globális egészként.

Kísérletezésre késztetés

Manapság szinte az összes piacvezető RPA szoftverszolgáltatónál elérhető ingyenes verzió, kimondottan KKV-k számára. Egyes demó verziók, például a Blue Prism egy hónapos trial verziója, legfeljebb kipróbálásra lehet elegendő. Azonban mind az Automation Anywhere, mind a UiPath rendelkezik olyan csomaggal, mely inkább az alkalmazási helyek száma (vagyis hány számítógépen futtatunk robotokat) és a vállalat mérete szerint korlátoz, időkorlát nélkül. Ez már egy jobb lehetőséget ad kísérleti projektek megvalósítására, valamint arra, hogy a vállalat megismerkedjen az RPA-val.

A másik fontos motiváló tényező, ha az automatizáló szoftverrel könnyen lehet robotokat létrehozni. Egy olyan sok alapbeállítással, egyszerű telepítéssel működő eszköz, mint az Automation Anywhere felhő alapú, böngészőből futtatható programja sokat segít abban, hogy a vállalat belső szakértőket képezzen ki, akik rövid időn belül megtanulják a robot készítését. Ez egyébként a nagyvállalatok stratégiája is, akik belső szakértői csapatot hoznak létre, amely az RPA kiterjesztésével foglalkozik a vállalaton belül, de vállalati területtől függetlenül segít az intuitív, könnyen felfedezhető programfelület és a kész műveleti építőkockák, melyekből a robotok összeállíthatók.

Tanácsadói szerep

Mindez persze csak egy szép elgondolás, amíg az ügyfél ezt nem látja működés közben. Egy sikeres pilot projekt meggyőzőbb lehet, mint bármilyen érvelés és színes bemutató. Esetünkben egy kis, jól leírható folyamatot választottunk, amely egy előkészítő lépés megrendelésekhez, vagyis sok repetitív adategyeztető lépéssel jár, valós napi szintű feladatot jelent és nem okoz problémát, ha a fejlesztés és kísérletezés közben a robot átmenetileg nem működik.

Az elkészült robot egyfelől bizonyítja, hogy egy ilyen folyamat működhet a megrendelő saját, személyre szabott rendszereivel, ugyanakkor egy mintát is szolgáltat, hogy miként építhetünk fel egy automatizáló robotot. Mint szinte minden, a gyakorlatban ez is összetettebb, mint elsőre talán gondolnánk, hiszen sok, ritkábban előforduló esetre is fel kell készítenünk a robotot, hogy minél több helyzetben tudjon az helyesen tovább haladni.

Hogyan tovább?

Az RPA kulcsa, hogy jó folyamatot automatizáljunk. Minél jobban ismerjük az RPA-t a gyakorlatban, minél több kis projektet hozunk létre, annál inkább rááll a gondolkodásunk, hogy észrevegyük ezeket a folyamatokat, és hogy az RPA-hoz igazítsuk, ha még nincsenek optimalizálva. Ahogy a vállalat is növekedhet idővel, úgy az RPA aránya is megnőhet a digitális feladatok megoldásában. Nem utolsó sorban pedig ezek a robot-fejlesztő programok is folyamatosan fejlődnek és újabb funkciókkal bővülnek, ezért érdemes szemmel tartani a legújabb változásokat.

RPA esettanulmányok a gyógyszergyártás és egészségügyi szolgáltatások területéről

2020-06-10T11:22:05Z

Az előző blogbejegyzésemben általánosságban írtam az RPA megoldásoknak az élettudományokhoz kapcsolódó vállalkozások üzleti és szakmai folyamataira való adaptálásának lehetőségeiről. Jelen írásomban a szektor tőkeigény és bevétel tekintetében legerősebb ágazata, a gyógyszerfejlesztés, valamint az egészségügyi szolgáltatások területén végrehajtott projektek rövid összefoglalójával illusztrálom a folyamatautomatizálás létjogosultságát, előnyeit, lehetőségeit.

Amint azt az előző részben kifejtettem, az élettudományokkal - és különösképpen az emberi egészség védelmével - kapcsolatos tevékenységeknek két alapvető, szigorú követelménynek kell megfelelniük, ráadásul egyszerre: a gyorsaság és a pontosság. Ugyanakkor napjainkban a területen működő cégeknek számos komplex elvárást is teljesíteniük kell mind üzleti, mind a kutatás-fejlesztési funkcióik tekintetében. Ezek a funciók a következőképpen csoportosíthatók:

Kutatás-fejlesztési tevékenységekhez kapcsolódó feladatok tervezése, szervezése
Kísérleti, kutatási adatok kezelése, feldolgozása, elemzése
Szabályozóknak való megfelelés, hatósági adatszolgáltatás, engedélyeztetés
Panasz- és bejelentéskezelés, ügyfél- és partnerkapcsolatok
Ellátási lánc, logisztika, készletgazdálkodás
Termelés: termékelőállítás, üzemeltetés, karbantartás
Általános üzleti tevékenységek, folyamatok: könyvelés, HR, értékesítés, marketing stb.

A felsorolt funkciócsoportokra egyenként is jellemző az adatok, információk, dokumentumok bevitelét, feldolgozását és tárolását végző rendszerek sokfélesége, a folyamatok magas komplexitása és gyakran az ismétlődő manuális, illetve papír alapú munkavégzés nagy aránya. A különböző funkciók kapcsolódási pontjain pedig kifejezetten felmerül az integráció igénye. Ezek alapján előre jelezhető a megfelelően kivitelezett automatizációs megoldások magas megtérülése.

A következőkben három, a gyógyszerfejlesztés és egészségügyi szolgáltatások terén, az Automation Anywhere (AA) által kínált eszközökkel megvalósult automatizációs projektet mutatok be.

Eli Lilly Japan K. K.

Az Eli Lilly and Company egy 1876-ban alapított amerikai biotechnológiai cég, melynek kutatás-orientált gyógyszerfejlesztési és előállítási tevékenységét olyan eredmények fémjelzik, mint a Jonas Salk által felfedezett polió-vakcina tömeggyártása vagy az első rekombináns DNS-technológiával előállított inzulin termelése. A cég 18 országban működő leányvállalatai közül az egyik az Eli Lilly Japan K. K.

Az utóbbi években a cég működésében az egyik legfontosabb kihívás az ügyfelekkel – betegekkel és egészségügyi intézményekkel – való kapcsolattartás, az igényeik megismerése és elvárásaik minél magasabb szintű kiszolgálása volt. A vállalat 2200 értékesítőjének támogatása, az adminisztrációs terheik csökkentése szintén fontos cél volt, melynek elérésétől az értékesítési tevékenység hatékonyságának növekedését várták. Leányvállalatként a cég részese az Eli Lilly and Company digitális transzformációra irányuló globális törekvéseinek.

2018 júniusától kezdődően az Eli Lilly Japan számos folyamat automatizálását végezte el Automation Anywhere RPA megoldásaival HR, értékesítés, marketing és klinikai kutatási funkciók tekintetében, például:

értékesítők jutalékelszámolásra vonatkozó személyre szóló értesítéseinek előállítása és kiküldése
orvoslátogatók támogatása, a látogatásokra vonatkozó javaslatok generálása
gyógyszerbiztonsági jelentések, biztonsági adatlapok összeállítása

A projekt eredményeként a cég 5 teljes folyamat 30 feladatát automatizálta, 7500 emberi munkaórát és 1.75 millió dollárt megtakarítva ezzel. A változások mind az értékesítők, mind az ügyfelek körében pozitív fogadtatásra leltek.

A jövőre vonatkozóan az Eli Lilly Japan további folyamatok automatizálását tervezi a farmakovigilancia (biztonságos gyógyszeralkalmazás érdekében kifejtett tevékenységek), auditálás és számlafeldolgozás területein.

Forrás: https://cdn.featuredcustomers.com/CustomerCaseStudy.document/Casestudy-Eli_Lilly_9.pdf

Boston Scientific

A Boston Scientific Corporation az orvosi, diagnosztikai és terápiás eszközök széles körét gyártó, amerikai vállalat.

Az automatizáció igénye először a pénzügyi és adóügyi csoportok munkájával kapcsolatban merült fel. A területen dolgozók a repetitív, standard szabályokon alapuló feladatok tömkelegét végezték manuálisan, ami sok időt és energiát emésztett fel. Ez különösen a zárások, csúcsidőszakok környékén rengeteg túlórában nyilvánult meg. A helyzetet nyilvánvalóan tovább rontotta, hogy a fáradt, motivációját vesztett dolgozók többet hibáztak, a hibakeresés pedig tovább növelte az időigényt munkaidőn belül és azon túl. Mindezek következtében a munkavállalók tudásának és készségeinek fejlesztése is elmaradt, ami a cég működésére és fejlődésére is egyre nagyobb hatással bírt.

Az automatizálandó folyamatok feltérképezése után a megvalósításhoz Automation Anywhere szoftvereket használtak.

Az automatizációs projekt fő lépései voltak

A területen zajló üzleti folyamatok feltérképezése, a potenciálisan automatizálható folyamatok kiválasztása és priorizálása az alábbi szempontok alapján:
- automatizálástól várható, számszerűsíthető eredmények: manuális munkaórák csökkentése, hibák számának csökkenése, költségcsökkenés, folyamat időigényének csökkenése (gyorsaság)
- megvalósíthatóság: a folyamatok elvégzéséhez használt meglévő technológiák egyedisége, diverzitása, adatok tárolására és továbbítására szolgáló technológiák jellemzői: papíralapú adatok mennyisége, digitális érettség
- komplexitás: az automatizálandó folyamatok bonyolultsága, erőforrás-igénye, szabályszerűsége, szabályozottsága, szervezettségének szintje
- megtérülés: az automatizációs megoldások fejlesztésére fordítandó erőforrások befektetésével elérhető eredmények, előnyök és megnyíló lehetőségek
Az előkészítő elemzések után elkezdődhetett a kiválasztott folyamatok automatizálása: a folyamatot alkotó feladatokat elvégző botok fejlesztése, rendszerbe szervezése, tesztelése. Először csak pár folyamat átalakítása történt meg egy pilot projekt keretében, melynek során a botok fejlesztése mellett sor került az ügyfél részéről a projektben közvetlenül résztvevők, valamint a jövőben az automatizációs megoldásokat használó, üzemeltető kollégák képzésére, betanítására is.
A pilot projekt eredményeként az abban automatizált folyamatok kiváltották a korábban manuálisan végzett tevékenységek 85%-át. Ezek alapján a cég további pénzügyi folyamatok automatizálása mellett döntött. Az automatizációs projekt vállalati, stratégiai szintűvé bővítéséhez a cég létrehozott egy RPA Kiválósági Központot (RPA Center of Excellence).

A projekt során eddig 20 komplex pénzügyi és adóügyi folyamatot automatizáltak, melyek 10-féle meglévő rendszert érintenek, ezáltal évente 3900 emberi munkaórát takarítanak meg (ebből 1100 munkaórát a csúcsidőszakokban) és a manuális tevékenységek 85%-át váltották ki. Nagy mértékben csökkentették a területen dolgozók terheit, sokkal kevesebb túlóra keletkezik a csúcsidőszakokban is, mindez a hibák nagyarányú csökkenéséhez, pontosabb munkavégzéshez, magasabb minőséghez vezetett.

A cég természetesen folytatja és bővíti a folyamatautomatizációs terveit, más tevékenységi körökre is kiterjesztve azt, mely a cég vállalati szintű digitalizációs stratégiájának szerves része lett.

Forrás:

https://www.pwc.com/us/en/library/case-studies/boston-scientific-boosts-efficiency-with-rpa.html

Cerner Corporation

A 40 éves múltra visszatekintő Cerner egészségügyi informatikai szoftvereket és eszközöket szállít világszerte. Mai napig több, mint 27000 intézmény használta már a termékeiket.

A termékeik és szolgáltatásaik folyamatos fejlesztése révén igyekeznek megfelelni a kor kihívásainak és az ügyfelek elvárásainak. Az orvostudomány és információtechnológia párhuzamos és sok ponton kapcsolódó fejlődése az egészségügyi adatok és adatforrások nagyfokú diverzitását és komplexitását is eredményezte. A különböző rendszerekből és eszközöktől származó érzékeny egészségügyi, diagnosztikai adatok feldolgozásához, a szükséges információtartalom kinyeréséhez azokat egy közös alkalmazásban kell rögzíteni, integrálni és tárolni. Ez a feladat hagyományos módon végezve sok elemében igényel manuális adatbeviteli vagy másolási munkát. Mindeközben az adatok legmagasabb szintű biztonságát is garantálni kell.

A cég több automatizációs eszköz kipróbálása után döntött az Automation Anywhere megoldásai mellett.

A projektet egyetlen licensz felhasználásával indították, egyetlen rendszermérnök 3 hónapos munkával egy 15 komponensből álló automatizációs modellt dolgozott ki. Ezek után egy nagyobb csapat elkezdte a projekt szélesítését, a folyamatok feltérképezését, priorizálását és az automatizáció előkészítését.

Az Automation Anywhere eszközök használatával a Cerner automatizálta több fejlesztési és tesztelési folyamatát, melynek következtében:

60%-kal nőtt a fejlesztők hatékonysága: a korábban 2-3 órás feladatok elvégzéséhez szükséges idő 30-40 percre csökkent. A cég 5 további fejlesztő alkalmazását kerülte így el.
Az átfutási idők rövidültek: a gyorsabb fejlesztői munka az ügyfélprojektek gyorsabb megvalósítását, nagyobb ügyfél-elégedettséget eredményezett.
A befektetés fél év alatt megtérült és éves szinten 628%-os megtérülést eredményezett.
Évente 130 000 dollár megtakarítása vált lehetővé.

Forrás: https://resources.automationanywhere.com/case-studies/cerner

A fentiekben bemutatott példák jól mutatják, milyen rendkívüli lehetőségeket rejt a folyamatautomatizáció az egészségügyi, kutatási tevékenységet folytató vállalkozások számára is.

További esettanulmányok elérhetők az Automation Anywhere virtuális könyvtárában

https://www.automationanywhere.com/resources/customer-stories ,

valamint az alábbi linken:

https://www.featuredcustomers.com/vendor/automationanywhere/case-studies

Folyamatautomatizálás az élettudományokhoz kapcsolódó vállalkozásoknál

2020-05-12T12:55:45Z

Az élettudományokhoz kapcsolódó szektorok fejlődése

Az élettudományok, vagyis az élet jelenségeinek és folyamatainak kutatása a XX. századtól kezdődően olyan eredményekkel szolgálnak a világ számára, melyek egyfelől új termelő és szolgáltató funkciókat hoznak létre, másrészt átalakítják a már meglévőket. A molekuláris biológia, biokémia és biotechnológia felfedezései új alapokra a helyezték a növénytermesztés és állattenyésztés, a gyógyszerfejlesztés és számos más iparág működését és a bennük érintett cégek piaci pozícióját. Ugyanakkor ez a fejlődés, illetve a fejlődés kereteit és korlátait megadó szabályozások soha nem látott adatmennyiség kezelését és feldolgozását teszik szükségessé.

Az informatika és adattudomány hasonlóan erőteljes fellendülése és térnyerése lehetővé teszi az előbb említett ágazatokban felmerülő adatfeldolgozási igényeknek való megfelelést. A haladás és a verseny nem áll meg, napjainkban egyre összetettebb elvárásokra kell reagálniuk az élettudományok területén működő cégeknek.

Ezek az elvárások az alábbi fő területeken jelentkeznek:

Kutatás-fejlesztési tevékenységek tervezése
Kísérleti, kutatási adatok kezelése, feldolgozása, elemzése
Szabályozóknak való megfelelés, hatósági adatszolgáltatás, engedélyeztetés
Panasz- és bejelentéskezelés, ügyfél- és partnerkapcsolatok
Ellátási lánc, logisztika, készletgazdálkodás
Általános üzleti tevékenységek, folyamatok

Bármelyik területet vizsgáljuk az élettudományokkal kapcsolatos tevékenységeket két alapvető, szigorú paraméter jellemzi: a gyorsaság és a pontosság. Egy olyan speciális helyzet, mint a jelenlegi koronavírus-járvány mindenki számára egyértelművé teszi ezek jelentőségét és minden más szektortól megkülönbözető jellegét.

Túl a vészhelyzeteken, az élettudományok és az informatika összefonódó és egymást inspiráló fejlődése közvetlen módon generált igényeket és keresletet új termékekre, technológiákra, szolgáltatásokra és a versenyt is szélsőséges mértékig fokozza. Példa erre az orvostudomány fejlődése, a személyre szabott orvoslás lehetőségének valósággá válása és ahogyan ez a betegek gondolkodását és az egészségügyi ellátással szembeni elvárásait átalakította. Olykor ezek az elvárások nem is tudatosak, nem fogalmazódnak meg kimondva, de a fejlett országokban élők már természetesnek veszik, hogy az orvostudomány minden betegségre megoldást nyújtson, biztonságosan, azonnal, elérhető áron.

Az élettudományok területén kifejlesztett technológiák korábban nem látott távlatokat nyitottak a növekvő emberi populáció megfelelő minőségű élelemmel való ellátásában, energiatermelésben, hulladékfeldolgozásban is. Ugyanakkor ezek a technológiák veszélyeket is hordoznak magukban, ezért az adatoknak pontosnak, a feldolgozásnak hibamentesnek kell lenniük. Ezen adott esetben életek múlhatnak.

Az RPA alkalmazásának lehetőségei

Előbbi bevezetőnk után tekintsük át, hogyan segítheti az informatika és rendszerszervezés legújabb eszköze, a folyamatautomatizáció (Robotic Process Automation) a felvázolt kihívásokra való reagálást.

Az innováció támogatása

Bármely tevékenységi területről beszélünk, az adatok feldolgozásának gyorsítása, a folyamatok automatizációja és optimalizációja az adminisztratív teendők csökkentésével időt szabadít fel a munkavállalók számára, ezt a felszabaduló időt, energiát a valódi fejlesztő munkára, kreatív képességeik kibontakoztatására tudják fordítani. Ez javítja a tevékenység eredményeit, valamint a munkavállalók hangulatát, morálját.

Az szinte minden ágazatra igaz a gyógyszerfejlesztéstől az élelmiszertermelésig, hogy mind a tervezési-fejlesztési, mint az üzleti folyamatok gyorsabbá, hatékonyabbá és átláthatóvá tételével az RPA támogatja a termékek gyorsabb piacra jutását és elérhetővé válását, a költségek csökkentése, de a minőségbiztosítás és ügyfélkiszolgálás szintjének emelése mellett. A kiélezett versenyben ezek a tényezők meghatározó innovációs elemek a vállalkozások piaci helyzetének alakulásában.

Példaként említhetjük a gyógyszerfejlesztéshez szükséges klinikai vizsgálati helyszínek kiválasztásának támogatását, a klinikai vizsgálatok és betegadatok pontosabb és alaposabb összehasonlításával, a különböző adatforrásokból származó adatok integrációjával.

Az orvostudomány és gyógyszeripar a generikus gyógyszerektől és terápiás módszerektől a személyre szabott orvoslás felé fejlődik, ami még több adatot jelent. Hasonló tendenciát láthatunk a mezőgazdaságban is, ahol a konvencionális technológiákat a precíziós mezőgazdaság váltja fel. Az összegyűlt adatmennyiség azonban önmagában nem válik értékké, azok megfelelő színvonalú feldolgozása és interpretálása teszi őket a fejlődést megalapozó információvá.

Előírásoknak való megfelelés, adatszolgáltatás

A termékekkel és módszerekkel szembeni hatékonysági és biztonságossági követelmények teljesítése érdekében az élettudományokhoz kapcsolódó iparágak tevékenységét számtalan szigorú előírás szabályozza. A kötelező teendőkön túl a cégek maguk vállalta minőségbiztosítási rendszerei is további adminisztratív terheket jelentenek.

A gyógyszeriparban ez a farmakovigilancia fejlesztését jelenti: az hibamentes, gyors adatfeldolgozás a megfelelő színvonalú termékfejlesztés alapja.

Napjaink járványhelyzetében nem kérdéses, hogy a közegészségügyi feladatok ellátásához, döntéshozatalhoz és intézkedések elrendeléséhez szükséges információk azonnali elérése és publikálása nélkülözhetetlen.

Az előbbi példákból is következik, hogy az adatszolgáltatás legtöbbször többféle adatforrásból történik, az integrációhoz pedig sokszor egy, a használt rendszerektől, adatbázisoktól független, externális eszközre van szükség. Erre az RPA szoftverek, botok egyszerű, könnyen kivitelezhető és kezelhető, transzparens megoldást nyújtanak.

Hatóanyagtól a termékig

Dolgozhatunk a legkiválóbb elmékkel, a legújabb berendezésekkel és gépekkel, a legmodernebb technológiákkal akár a laborban, akár a szántóföldön, ha a szükséges anyagok nem állnak rendelkezésre a szükséges helyen és időben. Ezen sorok írója is ismeri azt a “hógolyó-effektust”, amikor egyetlen reagens hiánya egyetlen kísérletet egyetlen nappal késleltet. Az egynapos késés a kísérletsorozatban már több napos késéssé duzzad, az egész kutatás szempontjából kritikus csúszást idézhet elő. A kukoricabogár megjelenésekor hiányzó növényvédőszer utáni kapkodás sem tartozik a legszebb emlékek közé. Egy kutatólaborban sem kívánatos az anyaghiány miatti késlekedés, piacra történő termelésnél megengedhetetlen. Az anyag- és készletgazdálkodás színvonala ezekben az ágazatokban az igények felmerülésének dinamizmusa és a szükséges anyagok magas költségei miatt meghatározóak a siker és eredményesség szempontjából. Az intelligens automatizált készletgazdálkodás lehet a kulcs a sikerhez, tovább tehermentesítve úgy a kutatás-fejlesztésben, mint a termelésben dolgozókat.

Közvetlen kapcsolat a felhasználókkal, partnerekkel

Az internet és a digitalizáció olyan információk közvetlen elérését nyitotta meg a cégek számára, amelyekhez korábban alig, vagy egyáltalán nem jutottak hozzá. Az ügyfelek, felhasználók, partnerek felől érkező bejelentésekre, panaszokra, visszajelzésekre már nem pusztán, mint elintézendő ügyekre tekintenek, hanem mint erőforrásra. Ezek az ügyfélelégedettség növelése, a piackutatás és marketing, minőségbiztosítás számára alapvető fontosságú információforrások lehetnek. Ugyanakkor hasznosságuk nagyban függ a mennyiségtől és a feldolgozás minőségétől. Ahhoz, hogy reprezentatív, széles bázison alapuljanak az elemzések, biztosítani kell a megfelelő csatornákat a nagy mennyiségű információ beáramlásához. Ezek lehetnek weboldalakon elérhető űrlapok is, de egyre több cég alkalmazza a különböző interaktív eszközöket, üzenetküldő rendszereket, chat-botokat, általuk is megjelenítve az ügyfelek, partnerek iránti elköteleződést. A következő lépés a nagy mennyiségű, többnyire szabad formátumú, nem strukturált információkból a releváns adatok kinyerése, tisztítása, elemzése. Mindezeket a lépéseket az intelligens, kognitív automatizációs eljárások magas színvonalon hajtják végre, minimális emberi beavatkozás szükségességével.

Az üzlet az üzlet

Természetesen az élettudományos területen működő vállalkozások általános üzleti folyamataik (könyvelés, pénzügy, HR, stb.) automatizálására is kiváló módszereket nyújt az RPA. Ezekre a szoftverek sokszor már beépített botokat is biztosítanak, illetve pár egyszerű, “drag and drop” lépéssel összeállíthatók időigényes, repetitív adminisztratív feladatokat végrehajtó eljárások. Mivel ezeknek a folyamatoknak az automatizálásában halmozódott fel a legtöbb tapasztalat és tudás, a teljes end-to-end automatizáció is megoldható a legtöbb esetben. Az élettudományok magas kitettségű, dinamikus környezetében bizonyos szakma-függő folyamatok automatizációja egyelőre korlátozott lehet, ezért a szektor vállalkozásainak talán még más szektorokhoz képest is fontosabb az a költség- és időráfordítás csökkenés, amit ilyen módon biztosan elérhetnek.

Az automatizáció szintjei és adaptálás lehetőségei

Az automatizáció ma már nem újdonság a biotechnológiában, gyógyszerfejlesztésben, ugyanakkor a cégek eltérő mértékű digitalizációja szerint különböző szintű automatizációs megoldásokat valósítanak meg.

„Attended” vagy „Assisted” RPA:

Emberi döntést nem igénylő, alacsony komplexitású (strukturált adatok, standart formátumban, kevés, könnyen elérhető forrásból) folyamatok automatizációja, mely a hosszabb távon változatlan szabályok mentén ismétlődő feladatok emberi munkaerő általi elvégzését váltja ki. A robotok futtatását még ember kezdeményezi, felügyeli és menedzseli lokálisan, jellemzően desktopokon. Az egyszerűbb, általános adminisztratív feladatok elvégzésére alkalmasak. Egyszerűsége ellenére jelentős idő- és emberi munka megtakarítást biztosítanak akár az általános, akár szakma-specifikus folyamatok során, mindenhol, ahol nagy mennyiségű adat bevitelére, keresésére, összegyűjtésére, integrációjára, szűrésére van szükség.

„Unattended” vagy „Unassisted” RPA:

Az attended RPA-hoz képest ezek a botok emberi kezdeményezés nélkül, időzítve vagy triggerek hatására lefutnak, ezáltal komplexebb folyamatok end-to-end automatizálását is lehetővé tévő megoldások. Ugyanakkor szükség lehet emberi beavatozásra, mert a kivételeket, szabályoktól való eltérést nem tudják kezelni. Többnyire még mindig Desktop környezetben, lokálisan futtatott botokat jelent, amelyeket viszont már lehetséges egy központi kezelőfelületről (dashboard) menedzselni (Szerver–kliens architektúra). Nem strukturált adatokat önmagában nem tud értelmezni, a természetes szöveg feldolgozási (NLP) képességei korlátozottak.

Autonomous RPA:

Az end-to-end automatizációt felhő-alapú SaaS (software as a service) szolgáltatásként nyújtja, az erősforrásgazdálkodás, terhelés-elosztás dinamikus és automatikus. Széleskörű előre definiált, beépített botok gyűjteménye elérhető az adott szolgáltatás keretében. A nem-strukturált információk feldolgozása még korlátozott, de már használhat mesterséges intelligencia technológiákat, mint a gépi tanulás, gépi látás, kognitív automatizáció.

Cognitive RPA (RPA + AI), avagy intelligens automatizáció:

Az automatizáláshoz integrált mesterséges intelligencia eszközöket használ, mint a gépi tanulás, gépi látás, optikai karakter felismerés (OCR), természetes nyelv feldolgozás (NLP), szövegértelmezés és elemzés, képes strukturálatlan információk feldolgozására. Ezekkel a technológiákkal felvértezve már alkalmas összegyűjtött információk értékelésén alapuló döntéshozatalt igénylő folyamat végrehajtására. A robotok menedzselése gyakorlatilag teljesen automatikus lehet, felhő alapú SaaS szolgáltatáson keresztül. Zökkenőmentesen és biztonságosan kapcsol össze cégen belüli és kívüli rendszereket, adatbázisokat, akár IoT-t. Használhat interaktív eszközöket, mint a virtuális asszisztensek, chatbotok.

Az AI segítségével a struktúrálatlan információkból lehetségessé válik az érdemi és létfontosságú információk kivonása, melyeket azután automatizált folyamatok dolgoznak fel. Ezek a technológiák együtt képesek például a klinikai adatok gyors és pontos feldolgozására, miközben megfelelnek a szakmai előírásoknak. Az AI segítheti az esetleírások és tudományos információforrások rendszerezését, szűrését, adatok kinyerését.

Kockázatok az intelligens automatizáció adoptációja során

Az élettudományok töretlen fejlődése minden tekintetben gyorsan változó környezetet jelent a hozzájuk kötődő vállakozások számára. Ezért az új rendszerek bevezetése hordoz magában kockázatokat. Ezek a kockázatok szakértő change management-tel, projekt-előkészítéssel, az érintettek felkészítésével és képzésével csökkenthetők vagy akár teljesen kiküszöbölhetők.

A folyamatok sokfélék, fragmentáltak, helyenként nem standardok.
A felhasználók (folyamatok eredményének tekintetében) sokfélék: például betegek, egészségügyi dolgozók, érdekvédők, non-profit szervezetek, hatóságok, partnerek, termelők, beszállítók, stb.
Különösen az erős tradíciókkal bíró ágazatokban előfordulhat, hogy a munkavállalók belső ellenállásába, kockázatkerülő hozzáállásába ütközik a projekt.
A tevékenységeket szabályozó előírások változnak, a nekik való megfelelés a rendszerek gyors adaptációját igényli.
A jogszabályi és hatósági előírásokon túl az iparágak szakmai elveinek és céljainak is hasonlóképpen meg kell felelni.

Use cases

Végezetül néhány nemzetközi példa sikeres automatizációs projektekre:

Az USA Élelmiszer- és Gyógyszerbiztonsági Hivatala, az FDA mesterséges intelligenciával integrált automatizáció segítségével jelentősen csökkenteni tudta használ gyógyszerek forgalomba hozatalának korábban több, mint 10 év hosszúságú folyamatát.
Az Eli Lilly Japánban az ügyfélkiszolgálás színvonalának jelentős emelését érte el különbözős sales, marketing és klinikai funkciók automatizálásával.
Az Amgen beszédfelismerő botot használ a kutatók labormunkájának segítésére, így nem kell gépelni, jegyzetelni a mérési adataikat és a feljegyzéseiket. Ezzel akár napi 3 óra adminisztratív munkára fordított időt szabadítanak fel az innovatív tevékenységeik számára.
A Boston Scientific 50 folyamatot automatizált, ebből 20 beavatkozást nem igénylő end-to-end automatizáció. Az előregisztrációs űrlapok feldolgozása, számlafeldolgozás, regionális raktárak kezelése és készletgazdálkodás terén évi 240 000 USD megtakarítást és teljes hibaredukciót értek el.
A Becton Dickinson több, mint 220 botot telepített HR, R&D és ellátási-lánc feladatok automatizálására

Források:

https://www.automationanywhere.com/in/solutions/lifesciences

https://www.automationanywhere.com/company/press-room/everest-group-names-automation-anywhere-a-leader-in-rpa-peak-matrix-assessment

https://www.automationanywhere.com/blog/product-insights/five-ways-rpa-and-ai-innovate-life-sciences

https://www.automationanywhere.com/blog/company-news/intelligent-automation-unlocking-value-for-life-sciences

https://www.automationanywhere.com/blog/product-insights/life-sciences-moving-innovation-forward-to-change-lives-with-cognitive-automation

https://www.automationanywhere.com/products/iq-bot/life-science

https://www.automationanywhere.com/blog/product-insights/how-automation-is-igniting-innovation-in-life-sciences

https://www.automationanywhere.com/solutions/pharmaceutical/eli-lilly

https://www.automationanywhere.com/solutions/lifesciences/boston-scientific

https://resources.automationanywhere.com/watch/how-becton-dickinson-uses-rpa-as-part-of-its-digital-transformation-strategy

Webinar-ok:

https://www.automationanywhere.com/lp/webinar/life-sciences-ai-powered-automation

https://www.automationanywhere.com/lp/webinar/ai-driven-life-sciences

Hogyan segíti az RPA a pénzügyi szektort a COVID-19 során felmerült kihívások megoldásában

2020-04-23T11:42:49Z

A COVID-19 globális terjedése az üzleti szereplőket és közösségeket mind gazdasági, mind humanitárius hatásokkal szembesíti, amelyek próbára teszik az infrastruktúrát, az erőforrásokat és az eddig jól működő gazdasági modelleket. A gazdasági szereplők egyfelől a vírus terjedése elleni védekezésre, másfelől a vírusnak az üzletmenetre gyakorolt hosszútávú negatív hatásának csökkentésére keresnek megoldásokat.

Az Automation Anywhere által kínált szoftver megoldások segíthetik a gazdasági szereplőket az előre nem látható globális megrázkódtatások és az üzletmenet zavarainak kezelésében, ideértve a COVID-19 hatását is.

A globális egészségügyi válságban a gazdasági szereplők közül a bankszektor helytállása alapvető fontosságú, az ő esetükben az üzletmenet folytonosságának fenntartása nemzetgazdasági jelentőségű.

Védje meg vállalkozását és dolgozóit

A válság és a kihívások idején a világ gyorsan változik, az RPA nyújtotta lehetőségek kihasználása azonban segíthet a stabilitás fenntartásában ebben a bizonytalan időszakban is. A digitális munkaerő segítségével megőrizhető az üzletmenet folytonossága, valamint a felügyeletet nem igénylő ügyfélszolgálati tevékenység is fenntartható az automatizálás révén. A különböző rendszerek távolról is elérhetőek, akár otthonról is.

Ahogyan a cég működése alkalmazkodik az új kihívásokhoz, az RPA úgy alkalmazkodik a felmerülő igényekhez.

A Bot Insight segítségével az üzleti folyamatok átláthatósága fenntartható, miközben az Enterprise RPA csomag segít gyorsan és hatékonyan automatizálni a folyamatokat.

Intelligens automatizálás

Az üzleti automatizálás révén emberi erőforrás szabadul fel, nő a kapacitás, így a globális kihívások gyorsan és hatékonyan kezelhetőek, több idő és energia fordítható az operatív működési problémák megoldására.

A Mesterséges Intelligencia (MI) segítségével valós idejű elemzéseket végezhetünk, így biztosítva a gyors döntéshozatalt és reagálást.

Hitelfelvételi folyamat támogatása

A jelzáloghitel refinanszírozási kérelmek számának növekedésével szükségessé válik a hitelezésfelvételi folyamat gyorsítása. Az intelligens automatizálás segítségével a teljes jelzálog hitel-igénylés időtartama a negyedére csökkenthető, és kevesebb, mint 30 perc alatt lebonyolítható. Az ügyfélazonosítók és az alkalmazások adatainak összegyűjtése és a hiteligénylési rendszerbe való felvitele után teljes kockázatvállalási képet kaphatunk. Ezáltal a ciklusidő és a manuális folyamat 80 százalékkal csökkenhet, a hibázás lehetősége pedig teljes egészében kiiktatható.

Ügyfélszolgálati tevékenység

A megnövekedett hívásmennyiség és az munkaerő kapacitásában történt változás szükségessé teszi az ügyfélszolgálati kérelmek feldolgozásának fejlesztését. Az ügyfelek tájékoztatása érdekében automatizálhatjuk a velük való kommunikációt. A rutin feladatok, mint az ügyfelektől beérkező kérelmek vagy az adataik CRM rendszerbe történő felvitele, módosítása az automatizálásnak köszönhetően enyhítheti a csökkentett ügyfélszolgálati létszám okozta problémákat.

Ezen felül az Automation Anywhere megoldása képes ellenőrizni a kérelmek helyességét, a kinyert adatokat a meghatározott űrlapok alapján adatbázisokhoz rendelni és – nem utolsó sorban – az ügyfelek számlanyitás iránti kérelmeit is automatizálni.

IT rendszer frissítése

Az egyszerű rendszerfrissítések elvégzése a jelenlegi helyzetben szintén kihívást jelenthet. Az Automation Anywhere RPA platformján épített botok képesek összegyűjti a rendszerfrissítési kérelmeket, majd a frissítéseket elvégezni.

Oracle Fusion ERP magyarországi környezetben

2020-04-07T11:20:29Z

Milyen elvárásokat támasztunk egy modern ügyviteli, illetve vállalatirányítási rendszerrel szemben? Mely kritériumoknak kell megfelelnie ahhoz, hogy Magyarországon használható legyen? Ezúttal a lokalizáció témáját járjuk körbe.

ERP a felhőben

Korábbi cikkünkben bemutattuk az ERP rendszerek körében tapasztalható legfrissebb trendeket. A felhő alapú szoftverek sokféle szempontból alapjaiban változtatják meg a vállalati IT működését. A hardver infrastruktúra szerepe elhanyagolhatóvá válik, az előfizetéses modellek miatt egyszeri nagyberuházások helyett könnyebben tervezhető operatív költségekkel kell számolni. A cégek előtt megnyílik a lehetőség, hogy különösebb erőfeszítés nélkül mindig a legfrissebb, legmodernebb szoftvert használják. Az integrált platformokon a riportálás és adatgazdálkodás is leegyszerűsödik. A folyamatos alkalmazkodást, új informatikai igények megvalósítását megkönnyítik a low-code és no-code megoldások, amelyekkel a fejlesztői feladatok egy részét átvehetik az üzleti felhasználók.

A vezető ERP szoftverek képesek globális nagyvállalatok komplex szükségleteit is lefedni, viszont a felhős technológia lehetővé teszi ezeknek a szolgáltatásoknak a skálázását nem csak felfelé, hanem lefelé is. Ezáltal akár a kis- és középvállalatok számára is elérhetővé, megfizethetővé válhatnak - pont ugyanolyan tartalommal és minőséggel, mint amit a piacvezető nagy cégek is megkaphatnak.

Globális rendszerek lokális igényekre

Nos, itt szeretnénk rátérni a fő témákra, miszerint érdemes-e egy magyar cégnek felhős ERP rendszerben gondolkodni. A szóban forgó ERP szoftverek funkcionalitását úgy alakítják ki a szolgáltatók, hogy a vállalati folyamatok széles körét lefedje, és viszonylag nagy rugalmasságot kínálnak a konfiguráción keresztül. Viszont a szabályozási környezet országonként eltérő, ami többek között a számviteli előírásokban, az adózási szabályokban, a hatóságokkal való kapcsolattartásban (pl. kötelező adatszolgáltatás) mutatkozik meg. Ráadásul ezek a speciális követelmények nem statikusak: mint tudjuk, egyes országokban roppant gyorsan változhat a jogi környezet, és a cégek kötelesek a rájuk vonatkozó jogszabályokat maradéktalanul betartani, az új igényekhez alkalmazkodni. Ennek teljesítése a vállalatirányítási rendszerekkel szemben is fontos elvárás.

Ezeket a képességeket az ERP szoftverek tipikusan úgynevezett “lokalizációs” csomagokon keresztül biztosítják. Visszatekintve az Oracle E-Business Suite-ban kialakított gyakorlatra, az Oracle többféleképpen közelítette meg ezt a kérdést. Léteztek konkrét országhoz kötődő lokalizációk, jellemzően a speciális számviteli vagy adózási előírások teljesítéséhez. Egyes követelmények, amelyek több országban is felmerültek, ki lettek emelve a “regionális lokalizációk” körébe, például az áfa riportálás általános kezelése. Néhány esetben pedig standard funkcióvá léptek elő a korábban lokálisnak tekintett igények, mint pl. a forrásadó kezelése, vagy az Intrastat riportálás. A lokalizációs megoldások túlnyomó többsége a pénzügy / számvitel területét érinti.

Az Oracle Fusion ERP (azon belül pedig a Financials) nem sokat változtatott ezen a képleten. Az egyedi helyi (ország-specifikus) igényeket a felhőben előre telepített lokalizációs funkciókkal lehet lefedni. Ezek “opt-in” elven működnek, azaz alapesetben ki vannak kapcsolva, de igény esetén szabadon lehet őket aktiválni. Az E-Business Suite-ban bevált legjobb gyakorlatok alapján a fontosabb piacok (országok) számára szükséges lokalizációkat átemelték a felhőbe is, szinte egy az egyben. Néhány országra azonban ez még nem történt meg, és sajnos jelenleg ezek között van Magyarország is.

Magyar specialitások

Vegyük sorra azokat a témákat, amelyeket az Oracle ERP rendszere nem feltétlenül tud standard, beépített funkciókkal támogatni, és lokalizáció fejlesztését teheti szükségessé. Ezeket főként a magyar számviteli törvényre és áfatörvényre lehet visszavezetni, amelyek többlet követelményeket támasztanak az ERP által biztosított alapfunkciókon és az egyéb, regionális lokalizációban meg nem valósított funkciókon felül.

Vevőszámla kötelező tartalmi elemei. Itt alapvetően egy “prototípus” számlasablonról van szó, amely csupán szemlélteti a számviteli törvény által megszabott előírások egy lehetséges implementációját. A tényleges nyomtatott (vagy PDF) számlakép jellemzően az ügyfél saját fejlesztésű, testreszabott megoldása lesz, amelyet lehet a lokalizációs mintából származtatni.
NAV adatszolgáltatás, azaz bizonyos kiállított vevőszámlák kötelező adatbeküldése a NAV Online Számla rendszerébe.
NAV adatexport, azaz ad-hoc ellenőrzés céljára készített elektronikus adatállomány a kibocsátott számlák meghatározott köréről.
Áfa bevallással összefüggő riportálás.

Vannak olyan követelmények, amelyekhez nincs szükség lokalizáció fejlesztésre, hanem nagy valószínűséggel lefedhetők a rendszerbeállítások jól átgondolt megválasztásával. Ezek közé tartoznak:

Devizaszámlák kezelése. A számviteli törvény által előírt napi árfolyamok használatát lehetővé teszi a rendszer. Kényelmi funkcióként az MNB árfolyamok automatizált betöltése egy opcionális lokalizációs elem lehet.
Áfa kezelése: az E-Business Tax modul használatával komplex, szabályokon alapuló automatikus adókalkuláció valósítható meg, amely képes lehet lefedni az összes felmerülő esetet. Az optimális beállításhoz az üzleti működés alapos feltérképezésére, és a törzsadatok (pl. vevő, szállító, terméktörzs) összehangolására is szükség van.
Tárgyi eszközök kezelése: itt több témával is foglalkozni kell, mint az eszközök nyilvántartása egyszerre több értékcsökkenési mód alkalmazásával (számviteli, illetve társasági adó szempontból), kivezetések elkülönített könyvelése kivezetés típusa szerint, és speciális riportok előállítása.
Európai Uniós értékesítéssel és háromszög-ügyletekkel összefüggő riportok (ezek nem szükségszerűen ország-specifikusak, az EU tagállamaira azonos feltételek vonatkoznak).
Banki interfészek: a Készpénz-gazdálkodás, szállítói számlák elektronikus kifizetése, az automatikus egyeztetés, és a vevői befolyások rögzítése a pénzügyi műveletek végrehajtását nagymértékben automatizálhatja, és ehhez az Oracle ERP rendszere is biztosítja az alap infrastruktúrát. Azonban az egyes bankokkal történő tényleges integráció kiépítése már egyedi technikai feladat, amelyet nem lehet lokalizáció keretében általánosan megvalósítani.

Út a megvalósításhoz

A magyar lokalizáció létezése egy olyan kritikus tényező az Oracle Fusion Cloud ERP-ben, amely elengedhetetlenül szükséges ahhoz, hogy Magyarországon működő cégek használhassák ezt a rendszert és élvezhessék az általa kínált előnyöket. Előbb-utóbb valószínűleg az Oracle is elkészítené ezt, viszont nem látszik tisztán, hogy mikor.

Az Ixenitnél azt látjuk, hogy egyre nagyobb az érdeklődés az Oracle ERP legújabb, felhős verziója iránt, azonban a lokalizáció hiánya komolyan hátráltatja az új bevezetéseket. Ezért úgy döntöttünk, hogy mi magunk készítjük el azokat a kiegészítéseket, amelyekkel a Fusion Cloud magyar viszonyok között is használhatóvá válik, és elérhetővé tesszük ezeket ügyfeleink számára. Bizonyos szempontból ez jó lehetőség arra is, hogy a korábban az EBS-ben létező megoldásokat alaposan átgondoljuk, újratervezzük. Hiszen – az új kritériumok mellett – az elmúlt 20-30 évben számos igény alaposan megváltozott, bizonyos követelmények megszűntek, átalakultak, vagy sokkal egyszerűbb standard megoldásokkal és konfigurációval lefedni őket. A cél mindenképpen az, hogy egy áramvonalas, könnyen kezelhető, és minél nagyobb mértékben automatizálható megoldás szülessen, amely a lokalizációs igények túlnyomó részét le tudja fedni.

Terveink szerint a második negyedév végéig elkészülnek a legkritikusabb komponensek, év végére pedig a teljes csomag. A jogszabályi környezetben bekövetkező változásokat a jövőben is követni fogjuk, és lokalizációs megoldásunkat folyamatosan a legfrissebb követelményekhez igazítjuk.

Az IT szerepe a koronavírus okozta károk enyhítésében

2020-03-26T14:50:48Z

A távolságtartás, a személyes kontaktus hiánya új kihívások elé állítja az embereket és a cégeket egyaránt. Ami eddig természetes volt, attól most hirtelen megfosztott minket egy nem várt biológiai veszély.

Szerencsére az informatikai eszközök révén fizikailag elszigetelve is kapcsolatban tudunk maradni barátainkkal, családunkkal és munkatársainkkal. Az olyan informatikai megoldások, mint a Teams vagy a Zoom lehetővé teszik, hogy a meetingek és tárgyalások, a mostani „karantén” idején is megtarthatók legyenek, igaz a virtuális térben. A cégeknek viszont olyan megoldásokra is szükségük lehet, amivel a kieső munkaerőt pótolni tudják, vagy a fogyasztás hektikussá válásából (pl. pánikszerű felhalmozás) eredő, megnövekedett munka terhelést ellensúlyozni tudják. Ilyen technológiai megoldás a szoftverrobotok használata.

Az IT szerepe a válság kezelésében

A COVID-19 vírus járvány hatása megmutatkozik a legtöbb makrogazdasági mutatóban, a gazdasági szervezetek tevékenységében és az egyén mindennapjaiban. Ez a válság viszont más természetű (reál gazdasági), mint a 2008-as (pénzügyi) volt és így a negatív hatások csökkentésére is más eszközöket lehet és kell bevetni.

Egy például háború okozta gazdasági válsággal ellentétben a kibocsájtás és fogyasztás szintjének visszaállása a megelőző időszak szintjére várhatóan jóval gyorsabban fog megtörténni, hiszen – elég csak annyi – hogy az erőforrásokban és termelő kapacitásokban nem történt – és ha az állam elvégzi rendfenntartó és egészségügyi szolgáltató funkcióját – nem is történhet jelentős kár. Persze strukturális (akár piaci) átrendeződésre a gazdasági alrendszerekben már most is láthatunk példát, elég csak az offline és online kereskedelem megoszlásának átrendeződésére gondolni.

A gazdasági szervezeteknek tehát egy ilyen helyzetben szükséges a rövid-, közép- és hosszútávú célkitűzéseit felülvizsgálni, a szükséges változtatásokra akcióterveket kidolgozni.

Rövid távon talán a legfontosabb cél a fogyasztói piacok megtartása, a mag és támogató funkciók fenntartása távoli munkavégzéssel, illetve a kieső emberi kapacitás pótlásával.

Közép távon több fogyasztói piacon átrendeződéssel lehet számolni, ezért fontos a piaci történések fokozott figyelemmel kísérése és az adaptációt segítő IT és egyéb eszközök implementációja.

Hosszú távon talán a legfontosabb cél a felkészülés a „business as usual” tevékenység folyamatosságának biztosítása járványok esetén is. Ennek eszköztára gazdag, de kiemelkedő a digitális transzformáció, aminek keretében a gazdasági folyamatok működéséhez szükséges információ digitálisan, földrajzi helytől függetlenül elérhető. Innen már csak egy lépés, hogy a gazdasági folyamat által felhasznált adat strukturált legyen, a folyamat lépései standardok és jól dokumentáltak, aminek hozományaként a formalizált feladatokat végző emberi és egyéb erőforrás könnyebben helyettesíthető, kiváltható akár szoftverrobotokkal is repetitív, manuális, nagy volumenű feladatok esetében.

A robotizált folyamat automatizálás (RPA) szerepe a válság kezelésében

RPA botok használatával biztosított a folyamatos munkavégzés, minimális ellenőrzést igényelve, hatékonyan követik a munkafolyamatot és segítik az emberek munkáját minden körülmény között. A bot folyamatosan dolgozik az irodai vagy virtuális számítógépen és távoli elérésen keresztül felügyelhető.

Habár mi is látjuk, hogy a járvány kapcsán sajnos történnek elbocsátások, az itt vázolt RPA megoldások egyáltalán nem az ilyen intézkedéseket segítik elő, épp ellenkezőleg, az RPA a megnövekedett feladatigény kezelésére ad jól méretezhető, rugalmas és könnyen használható megoldást a szolgáltatási szint fenntartása érdekében.

Egészségügy

Az egészségügyben az idő jelentőségét most értjük meg igazán, amikor minden perc számít, amit az egészségügyi dolgozók az adminisztráció helyett a betegek ellátására fordíthatnak.

Az RPA bot segítséget tud nyújtani a megnövekedett adminisztrációs terhek enyhítésében, úgy, hogy az ember helyett vagy az emberrel együttműködve végez el adminisztrációs feladatokat.

Az RPA bot el tudja végezni a fekvőbetegek kartonjainak és leleteinek digitális rendezését, a labor vizsgálatok eredményeinek gyorsabb kiértékelését, ezáltal felhívva a normálistól eltérő értékekre a kezelőorvos figyelmét, aki így hamarabb tudja a diagnózist felállítani és a kezelést elkezdeni.

Pénzügyi szolgáltatók

A pénzügyi szolgáltatóknak, azon belül is elsődlegesen a bankoknak, hitelintézeteknek a hiteltörlesztési moratóriummal kapcsolatos igényekre, változtatásokra rövid távon fel kell készülniük. Ez jelentős kapacitás átcsoportosítással jár és kihívást jelent akkor, amikor a személyes ügyintézés és kapcsolattartás korlátozott.

Erre szintén megoldást tud biztosításani az automatizálás és az RPA, hiszen így a kialakított új folyamatokra nem kell minden humán erőforrást felhasználni, hanem digitális dolgozók is hadba vethetők, akik a már rutinszerű monoton munkákat elvégzik és az adatokat hibamentesen továbbítják a megfelelő társosztályoknak. Ezalatt az idő alatt a dedikált kapcsolattartó pedig több időt tud az ügyfeleire szánni és megfelelő, folyamatos tájékoztatást biztosítani.

Az iparági szakértők szerint a hitelezést már digitálisan végző bankok versenyelőnyben lesznek azokkal szemben, akik ezt a fejlesztést még nem végezték el, vagy elhalasztották.

A jelenlegi üzleti folyamatok modernizálásával/optimalizálásával és az RPA adta előnyökkel hatékonyabban lehet kezelni a nem várt eseményeket, például a fogyasztási hitelek és a várható gazdasági válság, recesszió során kialakulni látszó pénzügyi étvágy által generált megnövekedett fogyasztói keresletet.

HR folyamatok

Mivel a vírus gazdasági értelemben az emberi erőforrás feladatvégző képességét befolyásolja, ezért jelentős terheket ró a vállalatok HR funkciójára, jellemzően megnövelve a HR adminisztrációs feladatok erőforrásigényét. Elég csak arra gondolnunk, hogy egy munkaszerződés tartalmának változása milyen adminisztratív terheket jelent egy olyan időszakban, amikor nehéz döntéseket kell meghozni és felelősségteljesen kell kifelé és befelé is kommunikálni.

Az RPA bot komplex döntésekkel nem boldogul, a vállalati HR kommunikációban sem erős, de hiba nélkül adminisztrál 0-24.

Képes például nagy mennyiségű, különböző formátumú elektronikus CVk kulcsszavak szerinti csoportosítására és mozgatására. Belső HR rendszerben lévő munka pozíció leírás alapján külső állásközvetítő rendszerbe álláshirdetést feladni. Megtanítható, hogy valamilyen trigger hatására vagy ütemezésre az általános HR rendszerben lévő releváns bért érintő változásokat átvigye a bérszámfejtő rendszerbe.

Az Ixenit szerepe a válság kezelésében

Az Ixenit sikeressége szervesen összefügg partnereinek sikerességével, így érdekünk, hogy partnereink is megismerjék az RPA nyújtotta lehetőségeket a válságkezelésben.

Hiszünk abban, hogy bizonyos új kihívásokra az RPA jó és költséghatékony megoldást nyújt.

Azon vagyunk, hogy folyamatosan bemutassuk az Ixenit facebook és linkedin oldalán azokat az RPA felhasználási eseteket, amiket az Automation Anywhere felhasználók bevezettek vagy terveznek bevezetni a válság hatásának enyhítésére.

Tanácsadóink és fejlesztőink készen állnak, hogy jelenlegi és új partnerinkkel közösen gondolkodva megtaláljuk azokat az üzleti folyamatokat, feladatokat, ahol az RPA lehetséges és gyorsan kivitelezhető.

Örömmel jelenthetjük, hogy bevezettük az „RPA Discovery” ingyenes szolgáltatásunkat, aminek keretében vállalatra szabott konzultációt biztosítunk az RPA felhasználási területek felderítésére és értékelésére.

Mindezekkel próbálunk hozzájárulni ahhoz, hogy partnereink sikere révén előbb kilábaljon a nemzet- és világgazdaság a válságból és visszaálljon a növekedés.

ERP rendszerek jövője

2020-03-10T11:12:53Z

A vállalkozások nagyobb része használ valamilyen ERP rendszert. Ezek lehetnek egészen egyszerű dobozos termékek, amelyek csak a kimenő és bejövő számlák kezelésére alkalmasak, vagy házon belül fejlesztett egyszerűbbnek induló, majd organikusan fejlődő, egyre komplexebbé váló megoldások, valamint a nagyobb vállalatok számára készült robusztus, skálázható moduláris rendszerek.

Amennyiben az ERP rendszerek jövőjét szeretnénk egy kicsit vizsgálni, akkor célszerű ez utóbbiakat szemügyre venni, mivel ezek a megoldások a legteljesebbek és az utóbbi idők piaci trendjei alapján elérhetők már az SME-k számára is.

A tradicionális, nagy ERP fejlesztő szoftvercégek közül szinte az összes egy átállási folyamaton megy éppen keresztül, aminek a végeredménye egy olyan megoldás csomag lehet, amivel mind a gyártó, mind a felhasználó egyaránt nyer.

A következőkben azt járnánk körül, hogy a modern ERP rendszerek területén milyen folyamatok zajlanak jelenleg, milyen trendek, változások várhatók, és ezek hogyan hatnak a felhasználókra és a piacra.

Cloud alapú ERP-k

A cloud alapú ERP-k elterjedésének a folyamata amilyen lassan indult, annyira felgyorsult az elmúlt pár évben. A gondolat, hogy a jelenleg használt rendszereket egy vállalat lecserélje valamilyen felhő alapú megoldásra, már kezd általános gyakorlattá válni. Ezek a rendszerek eleinte egy-egy területre fókuszáló és így könnyebben, kisebb kockázattal bevezethető rendszerek voltak, mint például a SalesForce, a Taleo és egyéb HR megoldások. Jelenleg pedig már az összes nagy klasszikus ERP szállító áthelyezte a fejlesztéseinek a fókuszát a cloud alapú ERP-k irányába. Ennek a főbb okai viszonylag könnyen megérthetők:

A rendszerek bevezetése nem igényel egyszeri nagy befektetést tárgyi eszközként a cégek részéről, hanem operatív költségként lehet vele tervezni és a megtérülésük is könnyebben kalkulálható.
Skálázhatósági oldalról csak a felhasználói létszámot kell az előfizetésekben lekövetni, nem igényel külön beruházást hardver oldalon az esetlegesen szükséges nagyobb szerver vagy tároló egység.
Az új modulok bevezetése esetén nem kell telepítéssel foglalkozni, ezek használatra készen megjelennek az új előfizetésekkel.
A licenszekkel kapcsolatos kérdések - mivel az üzemeltetés a szoftver gyártónál van - sokkal tisztábbak, egy-egy audit során nem érhetik meglepetések a felhasználókat.
Nincs verzióhoz és üzemeltetési környezethez kötöttség, mint az on-premise verzióknál, ahol egy-egy verzióváltás gyakran hosszú előkészítést, tervezést igényel, illetve a kivitelezés is meglehetősen költség- és erőforrás igényes lehet. Ennek következtében sok felhasználó inkább marad régebbi verzióknál, így megfosztva magát az új funkcióktól és az ezekkel járó versenyelőnyöktől. A verzióváltás elmaradása miatt többen használnak már a gyártó által nem támogatott és biztonsági szempontból is kockázatos, elavult verziókat.
A fentiek miatt az IT költségek mind hardver-, mind üzemeltetési oldalon jelentősen csökkennek, a rendszerekkel kapcsolatos kiadások kiszámíthatóbbak és egyenletesebb terhelést jelentenek a cégek számára.
A hardver és üzemeltetési környezet kiesésével a robusztusabb megoldások elérhetővé váltak az SME-k számára is, ami a piac folyamatos bővülését hozza magával.

Folyamat alapon szerveződő rendszerek

Az ERP piac átalakulása nem csak az értékesítési és üzemeltetési oldalon indult meg. A nagy szoftvergyártók rájöttek arra, hogy az on-premise rendszereik finomítgatása és fejlesztése közben rendkívül sok olyan piaci megoldás született, amelyek a változó gazdasági és szociális folyamatok következtében kialakuló niche piacok betöltésére törekednek. A monolit rendszerek csiszolgatása mellett ezekre az új folyamatokra nem maradt idő reagálni, így a hagyományos ERP rendszerek fejlődésben bekövetkezett egy kis megtorpanás. Az erre adott válaszlépés a kisebb rendszereknek a felvásárlása és integrálása, amely jelenleg is zajlik a piacon. Azon lehet vitatkozni, hogy ez a lépés mennyire helyes vagy nem helyes, de az kimondható, hogy egy-egy piacképes megoldás jobb helyen van egy tőkeerősebb, nagy vállalat kezében, valamilyen csomagba integrálva, mint egy olyan fejlesztőcég kezében, aki ezt a megoldást önálló termékként tudná szállítani. A modern ERP rendszereknél gyakoribbak az új verziók, így egyenletesebb a fejlődés.

A belső fejlesztések és a felvásárlások következtében a nagy gyártók ERP rendszereinek kínálata már rendkívül sok modult tartalmaz. Az áttekinthetőség érdekében a gyártók már nem is annyira modul, hanem megoldás alapon értékesítenek, és a licensz csomagok a gazdasági folyamatok/területek lefedésére irányulnak.

Az így kialakult egységes platformon futó nagy rendszerek - mivel lefednek minden területet - külső rendszerek nélkül is kínálhatnak komplett informatikai megoldást a gazdaság szereplőinek, amivel a következő előnyök járnak:

Adatbiztonsági oldalról: zárt rendszerek jönnek létre, ezért csökken annak a lehetősége, hogy valamilyen integrációs pontnál sérülhetnek a biztonsági követelmények.
A folyamatok egy egységes rendszeren belül zajlanak, így nem kell az integrációval és annak következményeivel, karbantartásával foglalkozni.
Az integrált rendszer miatt könnyű, átfogó, egységes, akár azonnali elemzéseket lehet kapni a vállalatról.
A törzsadat kezelés lényegesen egyszerűsödik, mivel nincs szükség a rendszerek közötti szinkronizálásra.
A gazdasági fejlődés által igényelt új funkcióknak megfelelően a vállalat alkalmazás csomagja könnyen bővíthető és nem kell az integrációs, üzemeltetési kérdésekkel IT oldalon foglalkozni.

A cégek nagy többségénél természetesen lehetnek olyan egyedi folyamatok, szakmai rendszerek, amelyekre nincs megoldás a portfóliókban. Ezeket javasolt inkább megtartani és a folyamatok újra tervezésével az integrációs pontok egyszerűsítésére törekedni. Egy bevezetési projekten a kényszermegoldások létrehozása egyik félnek sem lehet érdeke.

Bevezetési és használati kérdések

A modern ERP rendszerek nagy rugalmasságot kínálnak a folyamatok lekövetésében, de azért nem nyújtanak minden kialakult vállalati gyakorlatra megoldást. Ezek a rendszerek sok-sok év folyamatos fejlesztésével és rengeteg ügyfél tapasztalata alapján készültek, így az általuk támogatott folyamatok nagyon kifinomultak és a legjobb gyakorlati használaton alapulnak.

A bevezetés során javasolt az ügyfeleknek nyitottan hozzáállni a felkínált megoldásokhoz és az ERP rendszer kínálta folyamatokhoz, mivel ezek gyakran jelenthetnek akár versenyelőnyt is. Ehhez mindenféleképp változtatásokra nyitott vezetőségre van szükség, akik képesek támogatni a folyamatok átalakítását és folyamatos változás követéssel kezelik a projektet. Természetesen a management hozzáállás mellett fontos olyan felhasználókat is találni a projektszervezetben, akikben megvan a rugalmasság és az elkötelezettség, amik elengedhetetlenek a sikeres bevezetéshez.

A modern ERP rendszerek bevezetése során az alapfolyamatok viszonylag gyorsan beállíthatók, viszont a mindennapi használat és a folyamatok jelentősen eltérhetnek az ügyfelek által addig megszokottaktól, ezért nem célszerű a hagyományos vízesés modellt követni a projekt során. A javasolt módszertan valahol a hagyományos modell és az agilis módszertanok (pl. SCRUM) között helyezkedik el. A projekt keretein belül a bevezető cég több iterációban mutatja be a felhasználónak a megoldást és ennek során közelednek egy olyan eredmény felé, ami találkozik a projekt elején meghatározott felhasználói célokkal. Az iterációs körökben bemutatott verziók egyre pontosabban teljesítik ezeket a célokat, míg a folyamat végén elő nem áll egy olyan változat, ami már az ügyfél szerint végfelhasználói tesztre bocsátható. A modern beállítási lehetőségeknek és a kezdetektől együtt kialakított folyamatoknak köszönhetően a bevezetés - kellően nyitott hozzáállással - lényegesen gyorsabb, mint a hagyományos ERP rendszerek esetében.

A modern ERP rendszerek egyik fő sajátossága, hogy rendszeres és meghatározott ciklusokban frissülnek. Ezek a frissítések a szokásos hibajavítások mellett jellemzően új funkciókat is jelentenek. Az állandó változás az ügyfél oldaláról is megköveteli, hogy minden frissítés esetén egy előzetes teszttel meggyőződjön arról, hogy a rendszerben bevezetett folyamatok az új verzióban is ugyanúgy működnek. Amiatt is fontos az új verziók előzetes tesztelése, mert ezek hozhatnak új megoldásokat vagy kezelhetnek már meglévő problémákat.

A modern ERP rendszerek egyik fő sajátossága, hogy az adatkinyerésre rengeteg opciót kínálnak. Ezek a funkciók felhasználóbarátok, a legtöbbje minimális technikai tudással kezelhető és új riportok, lekérdezések, grafikai megjelenítések hozhatók létre. A fejlődés nem csak riporting, hanem integrációs, rendszerbővítési oldalon is tapasztalható, mivel sok olyan megoldás született, amelyek low-code szemléletűek, és tényleges programozói tudás nélkül is sok mindent meg lehet oldani bennük grafikus felületeken keresztül.

A hab a tortán

A fentiekben részletezett előnyökön kívül a modern ERP rendszerekre történő átállás azért is javasolt, mert a legtöbb gyártó már ezekbe fektet csak energiát és az újabb fejlesztések is csak itt lesznek elérhetők. A rendszeres frissítéseknek köszönhetően az új gazdasági trendekre adott informatikai fejlesztések egyből elérhetők lesznek a felhasználók számára. Emellett van több fejlődési irány, amelyek komoly versenyelőnyt jelenthetnek minden vállalkozás számára:

Teljeskörű mobil alkalmazás integráció. Ezekre már az on-premise rendszerek zömében is voltak megoldások, de a modernebb ERP rendszereknél ez már alapkövetelmény.
AI, Machine Learning megjelenése a vállalati folyamatokban. Ezeknek az előnye nyilvánvaló lehet minden felhasználó számára, mivel ezekkel a megoldásokkal a folyamatok jelentősen felgyorsulhatnak, illetve a döntés előkészítés is egyszerűsödhet (pl. egy optimális út megjelölésével).
Webshop-ok megjelenése: A modern ERP-k elválaszthatatlan része a webshop, ahol a felhasználók rákereshetnek megoldásokra, amelyek egy-egy adott problémához (pl. hiányzó funkcióhoz tartozó alkalmazás kiterjesztés, integrációs megoldás) tartoznak és ha valaki korábban ezt a problémát már megoldotta és elérhetővé tette, akkor innen telepíthető - néha akár extra költség nélkül is.
Közösségi szemlélet: A modern ERP-k egyik nagy erőssége, hogy a releváns területek (HR, marketing, értékesítés) alapból integrálhatók a modern social platformokkal. Az előzőek mellett a közösségi szemléletet támogatják olyan felhasználói, szakértői csoportokkal is, amelyek az ERP-k köré épülnek és segítik a felhasználókat a mindennapi használatban.
Modern technológiai megoldások megjelenése az ERP-kben. A mai trendek közül mindenhol megjelent már az IOT integráció, a blockchain használatának a lehetősége. A modern ERP-k folyamatos fejlődésére tekintettel a vállalatok biztosak lehetnek benne, hogy egy ilyen megoldás választásával folyamatosan lehetőségük lesz elérni a legmodernebb, aktuális trendeknek megfelelő megoldásokat.

GDPR 2020 – feladatok, kihívások és megoldások

2020-02-26T18:39:43Z

Sokan felkészültek a GDPR elvárásaira és még mindig legalább annyian vannak, akik nem, vagy csak részlegesen. Az elmúlt két év tapasztalata - Sándor Zsolt a Gill & Murry Kft. vezető adatvédelmi szakértője szerint – az, hogy elsősorban a legtöbben csak a tájékoztatás területén oldották meg a GDPR feladatokat. Az ezen felüli tevekénységek sok esetben nincsenek megoldva vagy hiányosak. Ide tartoznak az adatkezelői és adatfeldolgozói nyilvántartások, a kockázatelemzés, a hatásvizsgálat és az érdek mérlegelések dokumentálása, amit vagy a GDPR rendelet egyértelműen előír vagy a Hatósági gyakorlatból következik.

Mi is sokat változtattunk a felkészítés lépésein, mert nem az az érdekes, hogy 2018 januárjában ki és hogyan értelmezte a GDPR rendeletet, hanem az, hogy az Adatvédelmi Hatóságnak ma milyen a gyakorlata nem csak Magyarországon, hanem szerte egész Európában. A Hatóságok egységes működésre törekszenek, átveszik egymás határozatait és azt alkalmazzák is. A Gill & Murry ezeket folyamatosan nyomonköveti és jelzi ügyfeleinek, ha szükséges változtatni a korábbi szabályozáson.

További hiányterület az alvállalkozók kezelése, túlnyomó többségben csak szerződések mentén kezelik ezt, de sajnos a legtöbben még így sem. A GDPR rendelet értelmében – hívja fel a figyelmet Sándor Zsolt - az Adatkezelő a felelős minden általa alkalmazott alvállalkozóért, adatfeldolgozóért, aki a nevében adatot kezel, azaz valamilyen tevékenységet végez az adatkezelőre bízott személyes adatokkal. Ehhez nem elég szerződést kötni, ennél jóval több kell a biztonsághoz. Az Adatkezelőnek egyrészt alkalmazni kell a saját szabályzatában megfogalmazott szabályokat, továbbá valamilyen módon ellenőrizni, kontrollálni kell az alvállalkozók adatkezelési tevekénységét. Ezt tartjuk az egyik nagy GDPR kockázatnak 2020-ban és talán a következő 2-3 évben.

Komoly probléma továbbá az, hogy az Adatkezelők nem ismerik az általuk kezelt személyes adatokat, nem tudják hol van, és hogy mit kell velük tenni egy Érintetti igény esetén.

Az elmúlt két év tapasztalata az, hogy azoknál a felelősen gondolkodó vállalatoknál, akik elkészítették a GDPR-nak megfelelő Adatvédelmi szabályzatukat, és próbálják alkalmazni is azt, a legnagyobb és legnehezebben megoldható feladatot a GDPR-ral kapcsolatos adminisztráció jelenti, hiszen problémát jelent az informatikai rendszer megfelelősége, a határidők betartása, a megfelelés az érintetti jogoknak, és a bizonyítékok megfelelő tárolása.

Mivel az informatika lényegében már minden vállalkozás legalapvetőbb tartozéka, ezért egyáltalán nem elhanyagolható az a tény, hogy akkor, ha az informatikai rendszerben nem kezelhetők külön a Cél – Jogalap párok, akkor csak egy Cél - Jogalap párt kezelhetünk, mert az az informatikai rendszer csak ezt képes támogatni. Legyünk őszinték, az egy darab Cél-Jogalap pár nem életszerű a legkisebb, működő vállalkozás esetében sem. És sajnos azt látjuk, hogy a legtöbb informatikai rendszer nem képes egynél többet kezelni ebből.

És akkor még nem beszéltünk arról, hogy hogyan hangoljuk össze azt, ha a személyes adatokat több informatikai rendszerben is tároljuk, és arról, hogy hogyan tudunk így eleget tenni az érintetti jogoknak (helyesbítés, korlátozás, végleges törlés, adatkezelési célonkénti működés, tájékoztatás a tárolt adatokról, adatátadás gépi formátumban).

A fentieknek történő megfelelés még egy jól átgondolt folyamatszabályzás mellett is nehézségekbe ütközhet, és komoly (emberi) erőforrás igénye van már néhány ezer kezelt adat esetében is.

Összefoglalva Sándor Zsolttal egyetértettünk abban, hogy Magyarországon a GDPR-ral kapcsolatban jelenleg két nagy feladattal állunk szemben. Az egyik a még el nem készített GDPR felkészítések elkészítése, a másik, nem kisebb feladat a már elkészült szabályzatok alkalmazása és ezek megfelelő informatikai támogatása.

Rövidítések az üzleti folyamat automatizáció világában

2020-02-26T11:07:52Z

Munkám során gyakran találkozom emberekkel, akik akkor ismerkednek az RPA fogalmával és értelmezést segítő kérdéseket tesznek fel. Ezek sokszor olyan válaszokat szülnek, amikre magától nem is gondolna az ember.

Gyakran kérdezik meg, hogy ezt úgy kell-e elképzelni, mint egy Excel makrót. Az analógia nem rossz, de az RPA nem csak Excelben működik, hanem bármilyen olyan alkalmazásban, aminek van felhasználói felülete (Vagy API-ja, de az szűkebb halmaz.)

Az is sokszor fel szokott merülni, hogy miben más ez, mint egy „Workflow” szoftver. Helyben is vagyunk! Itt érdemes kicsit körüljárni, hogy mit értenek ma a vállalati szoftver piacon BPM, BPMS, BPA és RPA alatt. 

Business Process Automation (BPA)

BPA alatt általában olyan módszereket értenek, aminek célja az üzleti folyamatok áramvonalasítása, hatékonyabbá tétele automatizációval. A módszerek tulajdonképpen változatos IT alkalmazások (pl. Oracle Integration Cloud, Microsoft Power Automate, Monday, Webcon) és eszközök (pl. Visual Basic for Applications), amiknek segítségével az üzleti folyamatok hatékonyságát, eredményességét, agilitását vagy megfelelőségét (compliance) javítani lehet.

Business Process Management (BPM)

A BPM alapvetően egy menedzsment megközelítés, aminek kulcsa a folyamatos üzleti folyamat fejlesztés az Előrelátás-Tervezés-Modellezés-Végrehajtás-Monitorozás-Opltimalizáció-Újratervezés lépéseken keresztül. Az eszköztár bőséges, vannak modellező szabványok (pl. BPMN, UML), folyamat fejlesztési módszertanok (pl. 6sigma) és rengeteg IT eszköz (BPM Systems - BPMS) érhető el a piacon. (A szoftvereket egyébként csak simán BPM-nek szokták hívni.)

Ma egy magára valamit is adó BPM szoftver no-code és low-code UX-et követel meg, mivel az üzlet használja fel. Ha minden iterációba be kell vonni az IT-t, akkor az pont az olyan nagyobb vállalatokat gátolja a szemlélet és a szoftver nyújtotta lehetőségek kiaknázásában, akik a legtöbbet nyerhetnének rajta. Általában egy BPM szoftver funkcionalitásába tartozik:

Business Process Modelling
Form Builder

Workflow Engine
Access Control
Reporting and Analytics

Az olyan szoftver óriások, mint az Oracle, Microsoft, SAP rendelkeznek saját megoldással, ami ellátja egy BPM szoftver funkcióját, és nagyon jól működik együtt az ökoszisztéma más szoftvereivel. Az Oracle Integration Cloudja például magát Modern BPM-nek mondja (MBPM? ), igyekszik a workflow-t átvinni az egész SaaS kínálatán, és sok konnektora van third-party szoftverekhez, köztük RPA szoftverekhez is. Nem véletlenül.

Robotic Process Automation (RPA)

2020-ban a vezető RPA platformok (Automation Anywhere, UiPath) rendelkeznek saját vezénylő (orchestration) komponenssel, hiszen a platform része a központi irányító egység, ahol a bot-ok teljes életciklusát a fejlesztéstől, a deploy-on át a futásig irányítani és monitorozni lehet. Ezeken a platformokon felépíthetők olyan folyamat automatizálási megoldások, amik megfelelnek a BPM elveinek.

De – hogy ne vegyük el a Webcon és társai kenyerét – azt el kell ismerni, hogy egy tradicionális BPM szoftver által nyújtott vezénylet (orchestration) nagyon jól kiegészíthető az RPA nyújtotta manuális adatmozgatással és adatátalakítással.

Vegyünk egy egyszerű, általánosabb példát. Az üzleti egység használ valamilyen Microsoft SharePoint-ba (hogy ne csak Oracle-ről beszéljünk) integrált BPM szoftvert. Ebben a szoftverben leképeztek egy üzleti folyamatot, például egy új hitel termék elbírálásának komplex folyamatát. Elkészítették a folyamat modelljét (lépések, döntési pontok, státuszok stb.), elkészítették a formokat, ahova a döntéshez szükséges adatokat gyűjti össze egy vagy több kolléga. Na már most, ezt a form-ot egy RPA bot is kitöltheti. A megfelelő rendszerekből (BAR, Takarnet, stb.) a bot el tudja érni a szükséges adatot, az adaton el tudja végezni a szükséges adattranszformációt (pl. viszonyszámokat képez), majd az így előálló információt be tudja vinni a form-ba. A trigger ugyanaz, mint amikor a SharePoint értesítést küld a munkatársnak, hogy szedje össze az adatokat, csak RPA-val nem egy munkatársat, hanem egy bot-ot értesít. A legnagyobb különbség pedig az, hogy az RPA bot ezt a feladatot lényegesen gyorsabban és lényegesen kevesebb hibával teljesíti, mint az ember.

Összefoglalva, egy vezető RPA platform funkcionalitása – mint amilyen az Automation Anywhere Enterprise RPA Platform – ki tudja váltani egy BPM szoftver funkcionalitását, de az is működőképes megoldás, ha az RPA és BPM szoftvereket egymást kiegészítve használjuk azzal a céllal, hogy end-to-end automatizáljunk üzleti folyamatokat.

A Java jövője

2020-01-16T12:27:25Z

A Java nagyjából 20 éve folyamatosan a legnépszerűbb programozási nyelv. 1996-os publikálásakor elsősorban a C/C++ nyelvek vetélytársának szánták, tervezésekor a legfontosabb szempontok a hordozhatóság, a biztonság és az egyszerűség voltak. Vajon mennyire tartható ez a sikeresség hosszú távon? Van-e esélye a Javának a megújulásra az egyre szorosabbá váló technológiai versenyben?

Java a mindennapokban

A Java általános célú programnyelv. Előnyös tulajdonságai révén hamar megvetette a lábát a vállalati szektorban. Számtalan felhasználási területe közül néhány:

asztali (desktop) alkalmazások
web alkalmazások, interfészek
Android alkalmazások
hálózatok, elosztott rendszerek
beágyazott rendszerek, IoT
adatbázisok

A siker titka

A Javát objektum-orientált felépítése és könnyű kezelhetősége alkalmassá tette arra, hogy vetélytársainál gyorsabban, produktívabban fejlesszenek vele komplex és biztonságos alkalmazásokat. Az egyszerűség fontos tényező az időtállóság miatt: mivel a szoftvert megírása után akár évekig vagy évtizedekig karban is kell tartani, nagyon fontos a forráskód könnyű olvashatósága, értelmezhetősége. Ezáltal egy nagyobb céghez újonnan felvett fejlesztőnek is felgyorsul a betanulási folyamata.

„A Java egy relatíve egyszerűen tanulható programnyelv. Előnye mindenképp, hogy sok helyen használatos, így a felmerülő problémák nagy részére némi kereséssel nagy eséllyel található kész megoldás. Az eddigi Java EE önmagában is használható komplett rendszerekhez, egyéb nyelvek teljes kihagyásával: a backend Java alapú, adatbázis kezeléséhez a JPA megfelelő, frontendre a JSF talán kicsit butuska, de néhány addonnal pofás is lehet. A garbage collector többé-kevésbé általában jól működik, így a memória kezelést az SE és EE szintjén is el lehet felejteni.”

– K. Zs., technikai konzultáns, Ixenit

A Java Virtuális Gép (JVM, Java Virtual Machine) is a fő sikertényezők között van: ez garantálja, hogy a Java programok bármilyen operációs rendszeren ugyanúgy lefussanak. A Java nyelven megírt forráskódot a fordítóprogram (compiler) egy „bájtkóddá” alakítja, amely már nagyon közel áll ahhoz a gépi kódhoz, amit a számítógép közvetlenül megért. A bájtkód hordozható, azaz platform-független, és a virtuális gép feladata a bájtkód optimalizált értelmezése (interpreter), azaz végrehajtása a konkrét hardverkörnyezetben. Emellett a JVM végzi futtatás közben az automatikus memóriakezelést (garbage collection), így a fejlesztőnek ezzel nem kell foglalkoznia. JVM futhat nagyteljesítményű szuperszámítógépeken, asztali PC-ken, mobiltelefonokon, de akár egészen szűkös erőforrásokkal rendelkező beágyazott rendszereken is (pl. hálózati eszközök, ATM-ek, IoT eszközök).

A Java amúgy is gazdag saját eszköztára (Core API) gyorsan bővült olyan nyilvános „könyvtárakkal”, keretrendszerekkel, amelyeket a fejlesztők szabadon felhasználhatnak, beépíthetnek programjaikba. Ezek fejlesztésében élen jár például az Apache Foundation és Eclipse Foundation. Még a közkedvelt Java fejlesztőeszközök (IDE, Integrated Development Environment) többsége is Java nyelven íródott.

Egy kis open source történelem

A Javát kifejlesztő Sun Microsystem szoros kapcsolatot ápolt az open source világgal (lásd: Unix, OpenOffice, OpenSolaris, MySQL). A nyelv fejlődési irányát a kezdetektől egy vállalati és egyéni tagokból álló testület határozza meg, amelyhez bárki csatlakozhat. A Sun 2006-ban publikálta GNU licensz keretében a Java nyelvet, itt kezdődött az OpenJDK fejlesztése, amely a Java SE (Standard Edition) funkcionalitását valósítja meg nyílt forráskóddal.

Az Oracle Corporation 2010-ben felvásárolta a Sun-t, ezáltal a Java is az Oracle tulajdonába került. Az akvizíció fő stratégiai célja a Sun hardware üzletágának megszerzése volt, de maga a Java is fontos volt az Oracle-nek, mivel számos szoftver terméke (middleware) nagyrészt Java technológiára épült. Ezáltal különösen érdekelt volt a nyelv fejlesztésében.

Maga az Oracle vs Google per már 10 éve húzódik. A tét nem csupán az a néhány milliárd dollárnyi kártérítési igény, ami mindkét cégnél aprópénznek számít. A több bírói fórumon átesett ügyben olyan kérdéseket próbáltak megválaszolni a döntéshozók, hogy érvényesíthető-e szerzői jog egy nyilvános API specifikációra, és méltányos használatnak számít-e ennek a lemásolása és újraimplementálása (konkrétan a Google az Android API-ban használta fel a Java API-kat).

A végszót az USA legfelsőbb bírósága mondhatja ki várhatóan 2020 nyarán. Egy Oracle számára kedvező döntés egyesek szerint akár az egész szoftveripart káoszba és bizonytalanságba taszíthatja. Feszülten várjuk a fejleményeket!

Az első időkben az Oracle meglehetősen elidegenítette, időnként ellehetetlenítette az open source közösséget, amely korábban a Sun termékein és a Java platformon ténykedett. Számos volt Sun alkalmazott távozott más cégekhez, több projektet beszüntettek. A légkört tovább rontotta, hogy az Oracle beperelte a Google-t, az Android API kapcsán felmerülő licensz kérdések miatt.

Feltámadás

A Java fejlesztése az utóbbi években kezdett újra felpörögni, mert látszott, hogy az Oracle által tervezett 3 éves release ciklusok már a vállalati szférában is túl hosszúak. A programnyelv sokat veszít a vonzerejéből, ha tartósan nincs benne semmi innováció, míg más trendi programnyelvek folyamatosan állnak elő okosabb, hatékonyabb, szebb, gyorsabb megoldásokkal. Újabb, JVM alatt futó nyelvek is születtek, hogy megkerüljék a Java hiányosságait és ódivatúságát, mint a Scala, Groovy, Clojure és Kotlin – ezek mindegyikének van valamilyen konkrét alkalmazási területe, amelyben ideálisabb választás lehet, mint a Java, mindemellett a közös JVM gyökerek miatt viszonylag könnyen együtt is tudnak működni a standard Java könyvtárakkal és Java programokkal. Konkurenciát jelent a C# is, amely a Microsoft által fejlesztett, Javához nagyon hasonló programnyelv. A Python nyelv egyszerű szintaxisa miatt, és főként a mesterséges intelligencia területén meglévő képességei révén válik egyre kedveltebb opcióvá.

Égető szükség volt egy komoly megújulásra. Ezért 2018 óta évente két új stabil verziót publikálnak a Java nyelvből, amelyből 3 évente jelölnek ki egy hosszabb távon támogatott (LTS, long-term support) verziót. Ez jelenleg a Java 11. Ahogy a korábbiakban, úgy a jövőben is fokozottan ügyelnek a régebbi verziókkal való kompatibilitás megőrzésére, hogy a régi forráskódok lehetőleg ne törjenek el egy verzióváltáskor. Mindegyik release tartalmaz jó néhány feature-t, amelyeket a nyelv fejlesztését felügyelő bizottság választ ki. Ezek közül vannak kísérleti (preview) feature-ok, amelyeknek még nincs meg a végleges specifikációja, és a visszajelzések alapján még finomítanak rajta vagy akár vissza is vonhatják a jövőben. Az eddigi tapasztalatok alapján a patchek többsége hatékonyság-javító (pl. a JVM vagy a GC teljesítményét tuningoló) fejlesztés, vagy létező API-k újraimplementálása (pl. Socket), és akad néhány új nyelvi elem, ami a fejlesztők kényelmét szolgálja (pl. switch expressions, record).

Ezzel párhuzamosan az Oracle licenszelési modelljén is változtatott, és az OpenJDK új verzióira már csak a fizető ügyfeleinek biztosít supportot. A forráskódok megnyitásával azonban mások előtt is megnyílt a lehetőség, hogy saját JDK implementációt (és saját virtuális gépet) fejlesszenek. Így az Oracle JDK és az OpenJDK mellett már sokféle Javából válogathatunk, eltérő licensz és support feltételekkel: AdoptOpenJDK (Red Hat, IBM), Zulu (Azul), Corretto (Amazon), SapMachine (SAP), Liberica (BellSoft). Az Oracle által szállított HotSpot virtuális gép helyett szintén vannak más opciók, mint OpenJ9 (IBM) és GraalVM (Oracle Labs).

“A cloud-native fejlesztés kapcsán nagy problémának érzem, hogy a Java-ból a mai napig hiányzik a dedikált Developer Mode (mint pl. az Angular-ban). Egy cloud-native fejlesztést jól támogató stack, Developer Mode-ban - tipikusan alacsonyabb teljesítmény mellett - de támogatja az iteratív fejlesztést (kicsit belenyúlok a kódba, kipróbálom stb). Ehhez kellene tudja natívan a megváltozott osztályok dinamikus újraolvasását, amire most csak gyenge minőségű ingyenes (Spring Loaded, DCEVM / HotswapAgent), vagy drága fizetős megoldás van (JRebel). Ennek hiánya miatt az iteratív fejlesztés nagyon lassú körbefordulású a Javascript, Python, Ruby alapú versenytársakhoz képest.

Ez alól egyes JVM alapú framework-ök kivételek (pl: Grails), amik adnak legalább valamilyen szintű Developer Mode-ot, de ennek a JVM szintjén kellene megoldva lennie, jó minőségben.”

– S. A., senior fejlesztő, DevOps mérnök, Ixenit

A modern szoftverfejlesztés kihívásai

A felhős szolgáltatások világában nem csak a szoftver fogyasztásának módja változott meg, hanem a szoftverfejlesztés és telepítés (deployment) módszertana is. Ha programjainkat felhőben hostoljuk IaaS / PaaS alapon, jellemzően az infrastruktúráért a felhasznált processzoridő, sávszélesség, memória alapján fizethetünk a szolgáltatónak. Ezért nagyon nem mindegy szoftvereink „lábnyoma”: mérete és teljesítménye. A felhős architektúra jellemzője az is, hogy rugalmasan skálázható elosztott rendszerekkel dolgozunk. A cloud-native fejlesztés a monolitikus alkalmazások helyett mikroszolgáltatások lazán összekapcsolt halmazából építkezik, amelyek mindegyike önállóan is skálázható (felfelé és lefelé is) a terhelésnek / igényeknek megfelelően. Ezt a konténer technológia teszi lehetővé.

A Java legfrissebb újdonságai között számos olyat találunk, amely ezeknek a követelményeknek próbál megfelelni. A korábbi Java EE (Enterprise Edition) azokat a könyvtárakat fogta össze, amelyek a vállalati szoftverek fejlesztéséhez szükségesek. Ennek a nyílt forráskódú utóda, a Jakarta EE most az Eclipse Foundation gondozásában folytatja útját, és a célkitűzése éppen az, hogy a Java nyelvet minél inkább alkalmassá tegye arra, hogy megfeleljen a felhős szoftverfejlesztés kihívásainak.

Emellett jónéhány open-source fejlesztés igyekszik valós alternatívákat és használható eszközöket kínálni a Java programozók számára. A GraalVM virtuális gép például a „native image” technológiával lényegesen csökkenti a lefordított java állományok méretét, és az AOT (ahead-of-time) compiler használatával a programok indításának idejét is lényegesen lerövidíti. A Quarkus keretrendszer, akár a GraalVM-el együttműködve, a forráskódok fordítás előtti optimalizálásával tud jelentős időt megtakarítani komplex programok esetén. A MicroProfile egy mikroszolgáltatások implementálására szolgáló keretrendszer.

Végszó

Számos kritika érheti a Java nyelvet, de tagadhatatlan tény, hogy napjainkban a legtöbbet használt programozási nyelvek egyike. Egyedi vállalati szoftvereken kívül rengeteg olyan open source megoldás is készül Javában, amelyeknek kulcsszerepe van a manapság fontos üzleti területeken is, mint amilyen a Big Data (Apache Hadoop) vagy az IoT (Apache Kafka). Maga a nyelv, és az azt körülvevő aktív fejlesztői közösség akkor tud releváns maradni, ha folyamatos innovációval és megújulással meg tud felelni a modern kor elvárásainak, és hatékonyan tudja támogatni a szoftverfejlesztést. A jelek szerint erre jó esélyek vannak, és Java fejlesztőkre még nagyon hosszú ideig igény lesz.