Az ERP-választás egyik létfontosságú lépése a meglévő üzleti folyamatok feltérképezése. Ez mutatja meg, hogyan működik jelenleg a vállalkozás, illetve itt fogalmazódnak meg azok az irányok is, amelyek a jövőbeli folyamatokat definiálják.

Ha még az ERP-követelmények összegyűjtésekor biztosítani tudja a folyamatok teljes körű feltérképezését, az garantálja, hogy megtalálja a megfelelő rendszert, amely a megfelelő képességekkel rendelkezik a vállalkozás számára.

Kezdjük a lényeggel!

Mi is az az ERP-feltérképezés?

Az ERP-feltérképezés lépésről lépésre mutatja meg, hogyan zajlanak az üzleti folyamatok. Ez a dokumentáció folyamattérképet ad arról, hogy hogyan szeretné a műveleteket végrehajtatni – bár a jelenlegi rendszerben nem minden fut pont így. 

Miért fontos az ERP-folyamatok feltérképezése?

Azok a vállalatok, amelyek kihagyják ezt a lépést, a saját kárukra teszik.

Egy gyors Google-kereséssel rengeteg ERP-katasztrófát találni, ahol a drága ERP-rendszereket bevezető vállalatok kudarcba fulladtak. Minden ERP-rendszernek vannak erősségei és gyengeségei, és minden ERP-rendszernek vannak hiányosságai. Összességében súlyos milliókat vesztettek már a vállalatok a sikertelen ERP-bevezetések miatt.

Az ERP-rendszereket gyakran úgy tervezik, hogy egy széles közönséget szólítsanak meg, ezért jól konfigurálhatóak, de ez a rugalmasság és konfigurálás hónapokig is eltarthat – és mindez még a testreszabások és a módosítások előtt van. Folyamat-feltérképezés nélkül elképzelhető, hogy le kell mondanunk a funkcionalitásról.

A legfájóbb pontok a fejünkben gyakran azok a problémák, amikkel legutóbb kellett szembenéznünk. Rendszerint ezekre a sürgető problémákra keresünk megoldást, miközben figyelmen kívül hagyjuk a maradék 90%-nyi dolgot, ami jól működik. A jól működő dolgokat természetesnek vesszük, és ugyanezt a funkcionalitást várjuk el az új rendszertől. Néha ez az elvárás beigazolódik, máskor viszont nem.

Milyen folyamatokat érdemes feltérképezni az ERP-rendszerünkben?

Egy vállalatirányítási rendszer a leghatásosabb eszköz arra, hogy átlássa a jelenleg futó folyamatokat, azok hogyanját és miértjét. A folyamat-feltérképezés pedig lehetőséget ad arra, hogy lássa, mi az, ami nyereséget termel és pénzt takarít meg, és mi az, ami nem teszi ezt és miért.

A folyamattérképünknek meg kell vizsgálnia, hogyan szeretnénk, hogy a folyamataink a jövőben kinézzenek. A folyamat itt nem csak egyetlen egy művelet; mint például egy megrendelés felvétele. Ez egy végponttól végpontig tartó eseménysorozat, beleértve az osztályokon átívelő, például az értékesítéstől a pénzügyig tartó pénzügyi zárási folyamatot. Például:

• a rendelési szükséglet felismerése,
• a beszerzési igénylés benyújtása és jóváhagyása,
• megrendelés,
• az árufogadás lebonyolítása,
• a beszállítói számla kezelése és
• a számla kifizetése

Miben segít a folyamattérkép?

A folyamattérkép lehetővé teszi a kritikus funkciók azonosítását, ezek elengedhetetlenek. Ezeknek valós szükségleteknek kell lennie, nemcsak kívánságoknak. Ezek a funkciókövetelmények képezik majd az ERP-követelménydokumentum vagy a tender-felhívások alapjait.

A tenderkiírás tartalmazza azokat a funkcionalitásokat, amelyeknek az új ERP-rendszernek meg kell felelnie; ez nem feltétlenül a szükséges riportok listája, inkább az egyes részlegek működését és a rendszer által támogatandó üzleti folyamatok leírása. A leendő szállítóknak meg kell tudniuk adni, hogy a rendszerük hogyan képes támogatni az Ön üzleti céljait.

A tenderkiírásnak meg kell határoznia a teendőket, de azt nem, hogy hogyan kell kivitelezni őket. Sok vállalat a meglévő rendszereire alapozza a pályázati felhívásait, és gyakorlatilag a hasonlót a hasonlóra cseréli; holott ideje lenne fejleszteni a folyamataikat és növelni a produktivitást.

A vállalatoknak azt is biztosítaniuk kell, hogy a dokumentumban a fentiekben feltérképezett összes üzleti folyamatuk szerepeljen, és ne csak azok, amelyek jelenleg problémát okoznak.

Az ilyen dokumentumok megírásakor túl könnyen elfelejtjük azokat a dolgokat, amelyek jól működnek, és feltételezzük, hogy az új rendszer mindenre képes lesz, amit a régi rendszer tudott.

ISC = Infor Solution Concept

Az az általános szabály, hogy semmi nincs a helyén, amíg meg nem bizonyosodtunk róla, hogy ott van. Semmit sem lehet feltételezni vagy magától értetődőnek venni. Ezért is olyan fontos egy ERP-folyamattérkép, valamint az a dokumentáció, amit oly sokszor említettünk már, mégpedig az ISC, vagyis Infor Solution Concept.

Az ISC nem csupán egy igen terjedelmes dokumentum, amely a feltérképezés során létrejön, hanem magát a feltérképezési folyamatot is magába foglalja. Szakembereink a közös munka során először megismerik a leendő ügyfelek folyamatait, így segíteni tudnak azok dokumentálásában, illetve átalakításában is, amennyiben szükséges és igény is van rá. A figyelmünk azonban mindig jelen van, és igyekszünk ezzel a koncentrált figyelemmel fókuszálni azokra a területekre, amelyek az iparági sajátosságokból, illetve a korábbi tapasztalatainkból kérdésesek, problémásak lehetnek.

Az ERP-rendszerek kulcsfontosságúak a szervezeten belüli különböző funkciók integrálásában és optimalizálásában. Az ERP-bevezetések azonban hírhedtek arról, hogy meghaladják a költségvetést, így sok projektmenedzser és informatikai igazgató a fokozódó költségekkel és az előre nem látható kiadásokkal küzd.

Ahhoz, hogy eligazodjunk ezen a kihívásokkal teli területen, elengedhetetlen, hogy megértsük, miért lépik túl ezek a projektek a pénzügyi elvárásokat. Ma megvizsgáljuk a legfontosabb kialakító tényezőket, és stratégiai támpontokat nyújtunk a megelőzés érdekében.

8 ok, amiért a projektek túllépik a költségvetést

1. A technológia, megoldás előnyben részesítése az emberekkel szemben

Egy ERP-rendszer az alkalmazottakra, az üzleti folyamatokra és az általános vállalati kultúrára is hatással van.

Ha elhanyagoljuk a szervezeti változásmenedzsmentet, és azt csupán végfelhasználói oktatásnak tekintjük, az a dolgozók ellenállásához vezethet. Ez késleltetheti a projekt mérföldköveit, és növelheti a további képzési és menedzsment-erőforrások szükségességét, ami végül költségtúllépéshez vezet.

Gondoljunk egy közepes méretű gyártó cégre, amely úgy dönt, hogy új ERP-rendszert vezet be a készletgazdálkodás és a termelés ütemezésének javítása érdekében. A hangsúly nagymértékben a gyártási ERP-szoftver technológiai képességeire helyeződik, míg a kommunikációra és a képzésre gyakran kevés figyelmet fordítanak.

2. Az üzleti folyamatok menedzsmentjének hiánya

A fejlett ERP-funkciók bűvöletébe eső vállalatok figyelmen kívül hagyhatják a tényleges üzleti folyamatokra vonatkozó igényeiket. A szervezetek gyakran olyan ERP-rendszert választanak, amely nem felel meg maradéktalanul az igényeiknek. Ez adódhat abból, hogy nem értik teljes mértékben a jelenlegi folyamataikat és jövőbeli céljaikat, de adódhat abból is, hogy valamilyen oknál fogva nem kerül a látókörükbe az adott ERP-megoldás. Bármi is legyen az ok, a nem megfelelő rendszer bevezetése, vagy a megfelelő rendszer nem kellően átgondolt bevezetése kiterjedt és költséges testreszabásokhoz vezet.

Az üzleti folyamatok menedzsmentje magába foglalja a jelenlegi munkafolyamatok feltérképezését, a gyenge pontok azonosítását, valamint az osztályokon átívelő érdekelt felek bevonását a szervezeti igényeknek megfelelő rendszer megállapítása érdekében.

Az üzleti igények és a szervezeti célok rangsorolása jelentősen csökkentheti a drága testreszabások szükségességét, és segíthet a projekt költségvetésen belül tartásában.

3. Irreális projektelvárások

Csábító lehet karcsú költségvetésre és ütemtervre való tervezés, de reális elvárások nélkül a szoftverprojekteket az ERP-kudarc veszélye fenyegeti.

Például előfordulhat, hogy egy (kisebb, nem specifikus tevékenységgel rendelkező) szervezet agresszív hat hónapos ütemtervvel és fix költségvetéssel vág bele egy ERP-bevezetésbe, mert nyomás alatt áll, hogy a folyamatokat fokozott ütemben modernizálja és emiatt szem elől téveszti az ERP-bevezetés kiterjedtségét és összetettségét. Aztán félúton kiderül, hogy az ütemterv és a költségvetés nem elegendő, ami elsietett bevezetésekhez és az üzembe helyezés után jelentős problémákhoz vezet, amelyek megoldásához további erőforrásokra lesz szükség.

A megfelelő projekttervezés felkészíthette volna a szervezetet az előre nem látható kihívásokra, súlyos pénzeket és időt megtakarítva a vállalatnak.

4. Elégtelen vezetőségi támogatás

Az ERP-projektek nemcsak a vezetői testület kezdeti jóváhagyását igénylik; folyamatos elkötelezettségre és iránymutatásra van szükségük.

A vezetői támogatás hiánya gyakran azt eredményezi, hogy ezeket a kezdeményezéseket pusztán informatikai projekteknek tekintik, nem pedig stratégiai üzleti átalakulásnak. Ez a helytelen hozzáállás csökkentheti a projekt fontosságát és sürgősségét, ami elégtelen erőforrás-allokációhoz és a határidők elmulasztásához vezethet.

Fontos egy vezetői testület létrehozása, amely segít a projektcsapatnak a szervezet digitális stratégiájához igazodni. Ez segít abban is, hogy megalapozott döntéseket hozzanak az erőforrások elosztásáról, az ütemtervekről és a költségvetés módosításáról.
Egy nagy szervezetben például előfordulhat, hogy a vezetői csapat jóváhagyja az új ERP-rendszer költségvetését, de a végrehajtási folyamatból kimarad. A folyamatos vezetői támogatás hiánya tisztázatlan projektirányelvekhez és következetlen erőforrás-elosztáshoz vezethet.

Ezután a projekt megrekedhet, és a megvalósítás jelentősen túllépheti a költségvetést.

5. Nem megfelelő erőforrások

A projektcsapat összeállításakor a szervezetek gyakran követik el azt a hibát, hogy a rendelkezésre álló munkatársakat jelölik ki, nem pedig azokat, akik a legjobban megfelelnek az ERP-bevezetésének sajátos kihívásainak.

A megfelelő iparági tapasztalattal nem rendelkező külső tanácsadókra való támaszkodás tovább súlyosbíthatja ezt a problémát.

A projektcsapat belső és külső tagjainak megfelelő átvilágítása és kiválasztása kulcsfontosságú a késedelmek elkerülése és a projekt költségvetésének betartása szempontjából. Persze, egy kisebb vállalatnál nem könnyű kivitelezni, főleg, ahol felhős szolgáltatást vesznek igénybe, ugyanis ezekben az esetekben a megfelelő emberek finanszírozása láthatóan magas költségként jelentkezik a vállalatoknál. Ennek ellenére érdemes körültekintően kiválasztani, hogy ki vezeti a bevezetési folyamatot, még akkor is, ha ez pillanatnyilag plusz költséget generál.

6. Elégtelen végfelhasználói képzés

Elegendő képzés nélkül az alkalmazottak valószínűleg visszatérnek a megszokott munkafolyamatokhoz, ami aláássa az új rendszer előnyeit.

A hatékony képzési programoknak jóval a rendszer éles üzembe helyezése előtt kell elkezdődniük, és több fordulót kell tartalmazniuk a megtartás és a jártasság biztosítása érdekében. Ez a proaktív megközelítés elősegíti a zökkenőmentesebb átmenetet, és csökkenti a további képzésekkel és a rendszer módosításával kapcsolatos hosszú távú költségeket.

Bár vezetői szemmel nézve lehet, hogy úgy tűnhet egy egyszerűbb bevezetés esetén elégséges lehet egy rövid képzés is, a munkavállalók oldaláról, akik nem feltétlenül tudnak/akarnak döntéseket hozni, pusztán az előírásokat tartják be, okozhat gondot, ha nem eléggé járatosak az új munkafolyamatokban. Ez pedig egy számlázásnál, vagy ügyfélszolgálati területen vezethet olyan hibákhoz, amik már komolyan érintik a vállalatot.

7. Túlzott testreszabás

Bár bizonyos szintű testreszabás gyakran szükséges az egyedi üzleti igények teljesítéséhez, a túlzott módosítások jelentős költségtúllépéshez és a projekt késedelméhez vezethetnek.

A szervezeteknek törekedniük kell arra, hogy az ERP-rendszer szabványos funkcióinak minél nagyobb részét használják ki, és a testreszabást a valóban kritikus, versenyelőnyt vagy megfelelőséget biztosító területekre tartogassák.

Az erős projektirányítás kialakítása segíthet kordában tartani a testreszabást, és biztosíthatja, hogy a projekt összhangban maradjon az eredeti költségvetéssel és célokkal. Szabályként kijelenthető, hogy amennyiben alapvető funkcióinkhoz jelentős testreszabásra van szükség, akkor nem a megfelelő megoldást választottuk.

8. Helytelen adatmigráció

Az adatmigráció gondos tervezést és végrehajtást igényel. A régebbi rendszerekből az új ERP-platformra történő adatátvitel legnagyobb kihívást jelentő aspektusai az adattisztítás és az adatérvényesítés. Ezek jelentősen befolyásolhatják a projekt menetrendjét és költségvetését, ha a folyamatot nem kezdik el elég korán.

A szervezeteknek alapos tervezésbe, szakképzett személyzetbe és robusztus eszközökbe kell befektetniük, hogy hatékonyan tudják kezelni ezt a folyamatot, biztosítva az adatok épségét és a rendszer működőképességét az első naptól kezdve.

Képzeljünk el például egy e-kereskedelmi vállalatot, amely egy robusztusabb ERP-rendszerre vált. Alábecsülik az adatmigráció összetettségét. Ha a kezdeti adatátvitelt elsietik, és nem tesztelik alaposan, az új rendszerben az adatpontossággal és a rendelésfeldolgozással kapcsolatos problémákhoz vezet. Ez végül másodlagos, drága erőfeszítést igényel az adatok tisztításához, érvényesítéséhez és újbóli költöztetéséhez, ami jelentősen befolyásolja a projekt költségvetését.

Kerülje el az ERP-projekt költségtúllépését szakértők bevonásával

Bár a kérdések nagy részét a vállalatok maguknak tudják feltenni és megválaszolni, mégis rendkívül fontos és hasznos, ha olyan partner áll mellettük, aki segít felkészülni a bevezetésre, illetve a megtartandó és megváltoztatandó folyamatok kiválasztásában, koncepcionálásában. A vállalatok szerencsés esetben fennállásuk alatt ötnél bizonyosan kevesebbszer találkoznak egy ilyen átfogó bevezetési projekttel, míg egy ERP-szolgáltató több száz bevezetést tud maga mögött, így a tapasztalatból fakadó előrelátás sokat segít a vállalatoknak is. Ráadásul speciális esetben – mint egy gyártói ERP bevezetésénél – elengedhetetlen, hogy a szolgáltató ne csak a bevezetésben, hanem a gyártásban és logisztikában is tapasztalt kollégákkal támogassa a bevezetést, akik képesek megérteni a vállalat folyamatait, és érdemben tudják azokat lefordítani az ERP nyelvére, szükség esetén pedig a legkisebb impakt mellett megváltoztatni.

A felhőszolgáltatók on-premise platformjainak rövid története

Hibrid IT-világban élünk: míg a vállalatok automatizálási rendszereinek egy része a nyilvános felhőben fut, a többi még mindig helyben érhető csak el. A felhőszolgáltatók sokáig figyelmen kívül hagyták az on-premises támogatás szükségességét, mivel a trendek miatt elavult informatikának számított. Azonban a Microsoft az ügyfelei nyomására 2015-ben változást hozott az Azure Stackkel. A többi szolgáltató sokáig elhanyagolta az a on-premises rendszerek informatikai támogatását, sőt, a piacvezető AWS még azt is megkérdőjelezte, hogy egyáltalán szükség van-e ilyen lehetőségre.

Mindez megváltozott, amikor Thomas Kurian vette át a Google Cloud vezetését, és bejelentette a Google Anthos-t. Az Anthos megmutatta, hogy még mindig van igény a helyszíni számítástechnikára, hiszen a Google – az örökké kreatív harmadik helyezett a nyilvános felhő szolgáltatók között – nemcsak helybeni támogatást kínált, de az Azure és az AWS platformokon is elérhetővé tette az Anthos-t (eredetileg az Anthos 2018-ban indult, GKE on-premises néven). Az AWS sem bírta sokáig, és a 2018-as re:Inventen bejelentette az AWS Outpostsot.

A Microsofthoz hasonlóan – az ügyfelek kérésére – az Oracle is elkezdte kínálni a Cloud@Customer-t 2016-ban, de akkor még nem volt életképes nyilvános felhő opciója, ami persze mára az Oracle Cloud Infrastructure-rel (OCI) megváltozott. Az IBM 2020-ban jelentette be on-premise kínálatát az IBM Cloud Satellite-tal (ennek előfutára 2016-tól az IBM Cloud Private). Mindezeket új generációs számítástechnikai platformoknak nevezzük, mivel lehetővé teszik a vállalatok számára, hogy ugyanazokat a munkaterheket párhuzamosan futtassák helyben és a nyilvános felhőben, ami korábban nem volt lehetséges vagy elérhető.

Miért érdemes tehát helyben futtatni a felhőinfrastruktúrát?

A vállalat szempontjából három fő tényezőre vezethető vissza, hogy a vállalatok miért igénylik a munkafolyamatok helyben történő futtatását. A teljesítményigényes folyamatok esetében, amelyek helyszíni rendszerekhez kapcsolódnak (gondoljunk a gyártásra, IoT-re stb.), a felhő teljesítménye nem biztos, hogy megfelel a valós felhasználási esetnek, és a más országokban található felhőalapú adatközpontok hálózati sebessége is lassú lehet.

Az adatok elhelyezkedése szintén döntő fontosságú; a jogi követelmények arra kényszerítik a vállalkozásokat, hogy az adatokat az ország szuverenitási határain belül tartsák. Ha nem áll rendelkezésre felhőalapú adatközpont, akkor a folyamatok házon belüli üzemeltetése az egyetlen lehetőség a vállalat számára, hogy megfeleljen a jogszabályoknak. 

Végül pedig a nyilvános felhővel kapcsolatos szkepticizmus is megmaradt; számos olyan CxO (Chief Experience Officer – ügyfélélményért felelős vezető) maradt, aki nem bízik a felhőalapú működésben, és továbbra is fizikai hozzáférést és tulajdonjogot szeretne a számítástechnikai rendszeréhez.

A felhőszolgáltatók szempontjából ezek mind erős érvek, de a szolgáltatóknak maguknak is megvannak az okaik arra, hogy helybeni futtatással is kínálják felhőcsomagjaikat. Először is, ez lehetővé teszi a szolgáltatók számára, hogy korai betekintést nyerjenek a helyben végzett munkamenetekbe. A helyben végzett munkafolyamatok gyakorlatilag a felhőszolgáltatók „malacperselyei” lehetnek, mivel átalakíthatók, és potenciális jövőbeli felhőbevételeket kínálnak a méretükkel.

Másodszor, a felhőszolgáltatók újra felhasználhatják korábbi kutatásaikat és fejlesztéseiket. A technológiai infrastruktúra szempontjából létfontosságú, hogy az helyben is futtatható legyen. Azonban az ilyen ökoszisztémák összetettek, és nehéz őket létrehozni, üzemeltetni és karbantartani, és már több mint 20 éve nem készülnek olyan alkalmazások és ökoszisztémák, amelyek ezt biztosítják.

Végül, de nem utolsó sorban, ezáltal a szolgáltatók növelhetik az ügyfélelköteleződést. A felhőszolgáltatók nemcsak betekintést nyerhetnek a munkaterhelésekbe az üzlethelyiségekben, hanem korán az ökoszisztémájukba is zárhatják a vállalatokat. Ez ugyanúgy érvényes mind az architektúra, mind a kereskedelmi oldalra. Ebben az esetben az on-premise szerződés is működik, és ezért felhőkrediteket ad.

Tehát, mint láttuk, jelentős célkongruencia van a vállalatok és a felhőszolgáltatók között, ami ahhoz vezet, hogy majdnem minden felhőszolgáltató kínál on-premise elérhetőséget: ezek a következő generációs számítástechnikai ajánlatok.

A megegyezőség ural mindent

Ahhoz, hogy a következő generációs számítástechnikai platformgyártók értéket tudjanak nyújtani, lehetővé kell tenniük a munkafolyamatok mozgathatóságát a helyi és a nyilvános felhőben lévő infrastruktúrák között. Külön érték, ha a folyamatok más szolgáltatók nyilvános felhőibe is átvihetőek – vagy ha egy olyan gyártó, mint az IBM, már nem játszik a nyilvános felhőpiacon. A CxO-k szeretnék elkerülni az egy szolgáltató melletti elköteleződést, és szeretnék, ha a munkaterhelésük ott futna, ahol az üzletileg, architektúrailag és jogilag megvalósítható, valamint a legelőnyösebb a vállalkozásuk számára.

A megegyezőség elég nagy kihívást jelenthet a felhőszolgáltatók számára, mivel ugyanazokat az API-kat és technológiai stackeket kell helyben futtatniuk, mint a felhőben. Sajnos a felhőstackeket úgy tervezték, hogy a felhőben fussanak – nem pedig helyben -, ami kihívást jelent a helyben történő rendelkezésre bocsátás során.

A Microsoftnak – a kezdeményezőnek – több mint három évébe telt, mire az Azure Stack-kel általános elérhetőséget biztosított. Az Oracle megegyezősége viszont figyelemre méltó kivétel, mivel – a ”felhőtörténelem” egy különös fordulata miatt – az Oracle piacra kerülésekor még nem kínált versenyképes nyilvános felhőszolgáltatást, így az Oracle Exadata és a Cloud@Customer vált az OCI sarokkövévé. A gyakorlatban ez azt jelenti, hogy az Oracle egy on-premise rendszert ültetett át a nyilvános felhőbe – ellentétben az összes többi gyártóval, akik a nyilvános felhőtechnológiai stackjeik egyes részeit alakították át úgy, hogy azok helyben fussanak.

A megegyezőség mellett a CxO-k olyan teljes átláthatóságot szeretnének, amely lehetővé teszi számukra a munkaterhelésük felügyeletét, függetlenül attól, hogy azok hol futnak. A munkaterhelések hibrid és több felhőben történő felügyeletének, üzemeltetésének és kezelésének képessége ma kulcsfontosságú a vállalatok sikere szempontjából.

Az aktuális profilok megtekintése

Hol tartanak tehát ma ezek a nagy technológiai nevek a felhőszolgáltatások terén?

Az AWS Outposts egy helyben áll, az AWS pedig tovább nyomul. Ma az AWS Outpost kínálata az AWS Outposts rackek és az AWS Outposts szerverek között oszlik meg. Az előbbi egy teljes rack, amelyet az AWS telepít, amihez a vállalatok biztosítják az áramellátást és a hálózatot. Az utóbbi az AWS által szállított és az ügyfél vagy egy harmadik fél által telepített szerver.

Az AWS Outposts rackek több helyi szolgáltatást kínálnak, mint az AWS Outposts szerverek, ezért nagyobb megegyezőséget is kínálnak. Az elmúlt években az AWS erősen promótálta az AWS Local Zones-t is, és ezért több regionális adatközpontba fektetett be, a nagy régiók kisebb alapterületűek. Ez enyhülés hozott az AWS-ügyfelek egy nem túl jelentős részének, akiknek szükségük van az AWS Outposts lábnyomának kiterjesztésére. 

A Google bár halad, úgy tűnik, hogy most egy kis szünetet tart. A Google próbálkozásai, hogy feljebb jusson a ranglétrán, folyamatos szálkák az AWS és a Microsoft szemében. Így volt ez az Anthos bejelentésekor is – azzal, hogy képes volt a modern, konténeralapú alkalmazásokat mind helyben, mind a fő versenytárs felhőjébe portolni. Ez az AWS-t az Outposts fejlesztésére késztette, így dicséret illeti a Google Cloudot, amiért képes a piacvezetőre nyomást gyakorolni. Viszont – valószínűleg az egész iparág AI-ra való összpontosítása miatt – a Google 2022 ősze óta nem bővítette az Anthost. Eközben a CxO-k örömmel fogadták a lehetőséget, hogy az Anthost VMware-en futtassák, amely több mint egy évtizede megbízható vállalati platform. Közben az Anthos Service Mesh teszi lehetővé a Google Anthos ügyfelei számára a több felhőben való működést.

Az IBM Cloud Satellite, a vállalati technológia Svájca, egyre növekszik. Mivel az IBM elvetette saját nyilvános felhő ambícióit, és az összes nagy felhőszolgáltatóval partnerségben áll, könnyen lehet, hogy az IBM metaforikus Svájccá váljon – az összes felhővel való üzletkötés semleges terepe. A Red Hat OpenShiftet hasznosító IBM Satellite pedig kulcsfontosságú ahhoz, hogy ez létrejöhessen (és visszaszerezzen valamennyit a Red Hat csillagászati felvásárlási árából). Az IBM folyamatosan bővíti a Satellite lábnyomát: az IBM Cloud Pak, az IBM Cloud Databases és még sok más, jelenleg elérhető megoldással számos lehetőséget kínál; az IBM Cloud Catalogja pedig egyre népszerűbb hely a vállalatok számára a harmadik féltől származó alkalmazások értékelésére és beszerzésére.

A Microsoft Azure Arc továbbra is népszerű, de az utóbbi időben nem sokat fejlődött. A Microsoft a szünet előtt folyamatosan fejlesztette az Azure Arcot (korábban Azure Stack), és bővítette a szolgáltatásait. Különös erőfeszítéseket tett mind az alkalmazásfejlesztés, mind a (kiber)biztonság terén, ami jól hangzik a telepítői bázis körében. A Google-höz hasonlóan a Microsoft is a kínálatának teljes körű, mesterséges intelligenciával történő átalakításán dolgozik -valószínűleg ez áll a szünet hátterében az Azure Arcnál. A jelenlegi generatív AI-mozgalom elindítójaként a Microsoft lehet az első olyan gyártó, amely valamilyen Azure Arc-alapú generatív AI-futtatóidőt kínál. A jövő majd eldönti.

Az Oracle vezet a megegyezőségben, és lassan sokdimenziós játékossá válik. Az Oracle figyelemre méltó utat járt be az on-premise-től a nyilvános felhőn keresztül most már a többfelhős megoldásokig. A többfelhős támogatás legújabb bővítményét a 2022-es CloudWorld konferencián mutatták be az Oracle Database (és ezzel együtt az Oracle Exadata) Azure-on belüli natív provizionálásával. Mivel a mindig megegyező Exadata alapplatformra építkeznek, a kínált funkciók azonosak a platformok között, ami az iparágon belüli legnagyobb megegyezést eredményezi. Mivel az Oracle komolyan fektet a mesterséges intelligenciába, hasonlóan érdekes lesz, hogy miként fogja az Oracle hozzáadni a mesterséges intelligencia-modellek erejét a platformjaihoz.

Bonyolult, de jó hír

A vállalati informatika látképe napról napra összetettebbé válik. A felhőinfrastruktúrákban a terhelés megnövekedése már most is komoly fejfájást okozó probléma. A generatív AI nem fog javítani a helyzeten, mivel új képzési és végrehajtási, valamint új, AI-ra specializált hardverplatformok fognak megjelenni miatta.

Most az AI-modellek képzése és kivitelezése teszi szükségessé a következő generációs számítástechnikai platformokat: a vállalkozásoknak a nyilvános felhőt kell kihasználniuk nemcsak az AI-modellek oktatásához, hanem az automatizálási telepítéseikben – más felhőkben és helyben, sőt akár a peremen – történő megvalósításához is. 
Egy végső gondolatként – a felhő győzedelmeskedik, de lejön on-premise, helybe. Ez jó hír; a CxO-knak van választási lehetőségük.

Talán a legnagyobb kiberbiztonsági veszély, amely kkv-kat fenyegeti, a hamis biztonságérzet. Akik alábecsülik a kockázatokat, vagy azt feltételezik, hogy vállalkozásukat megvédi kis méretük, azok kudarcra ítélik magukat.

Kisvállalati kiberbiztonsági mítoszok

1. tévhit: A támadók csak a nagyvállalatokat veszik célba.

A kis- és középvállalkozások 51%-a nem rendelkezik kiberbiztonsági védelemmel. Közülük 59% azt állítja, hogy a vállalkozásuk túl kicsi ahhoz, hogy célponttá váljon.

A hírekben szereplő kibertámadások általában a nagy szervezeteket érik, de a kisvállalkozásoknak is folyamatosan támadásokkal kell szembenézniük. A 2023-as Verizon Data Breach Investigations Report (DBIR) szerint több olyan adatsértés és incidens történt, amely a kis- és középvállalkozásokat érintette, mint a nagy szervezeteket.

Egy átlagos kisvállalkozás alkalmazottja 350%-kal több pszichológiai manipulációs kísérletet tapasztal, mint egy nagyobb vállalkozás alkalmazottja.

2. tévhit: Nem kell aggódnom a munkatársaim miatt.

Az alkalmazottaknak nem kell rosszindulatúan cselekedniük ahhoz, hogy kárt okozzanak; elég egy téves kattintás. Az emberi tényező (hibák, jogosultsággal való visszaélés, lopott hitelesítő adatok használata vagy pszichológiai manipuláció) a minden fajtájú és méretű iparágban történő adatsértések 74%-ánál szerepet játszott.

3. tévhit: Nem kell terveznem – a rendszereink már biztonságban vannak.

A kisvállalkozások tulajdonosainak 64%-a biztos abban, hogy gyorsan meg tud oldani bármilyen kibertámadást, bár csak 28%-uk rendelkezik konkrét kibertámadási tervvel, és csak 26%-uk rendelkezik kiberbiztosítással.

A kkv-k 32%-a ingyenes biztonsági megoldásokra támaszkodik, amelyek nem biztos, hogy megfelelő védelmet nyújtanak. A rendszerbe való behatolás, a pszichológiai manipuláció és az alapvető webes alkalmazások elleni támadások a 2023-as DBIR felmérésben a kkv-kat ért támadások 92%-át tették ki.

4. tévhit: A kisvállalkozások nem engedhetik meg maguknak a kiberbiztonságot.

Úgy gondolja, hogy nem engedheti meg magának a kiberbiztonságot? Az igazság az, hogy valószínűleg nem engedheti meg magának, hogy ne rendelkezzen vele. A DBIR szerint a zsarolóvírus-incidensek átlagos költsége megduplázódott az elmúlt két évben, és a zsarolóvírus incidensek 95%-a 1 és 2,25 millió dollár közötti veszteséggel járt.

A kisvállalkozások tulajdonosainak 40%-a százaléka arra számít, hogy egy kibertámadás 1000 dollárnál kevesebbe kerülne, míg 60%-uk úgy gondolja, hogy a teljes helyreállítás három hónapnál rövidebb ideig tartana.

A kiberbiztosítási kárigények adatai azonban azt mutatják, hogy a jogsértések helyreállítási költségei általában 15 000 és 25 000 dollár között mozognak, az átlagos helyreállítási idő pedig 279 nap.

Az ERP-rendszerek már régóta a gyártók üzleti rendszereinek középpontjában állnak, segítve a gyártókat a költségek, a minőség, a nyomonkövethetőség és a megfelelőség kezelésében. Ugyanezek a szempontok sokat segítenek a gyártóknak abban, hogy elérjék saját környezetvédelmi, társadalmi és vállalatirányítási (ESG) célkitűzéseiket is, és ezzel megfeleljenek a fejlődő ESG-irányelveknek.

Az ERP-rendszerek már régóta a gyártók üzleti rendszereinek középpontjában állnak, segítve a gyártókat a költségek, a minőség, a nyomonkövethetőség és a megfelelőség kezelésében. Ugyanezek a szempontok sokat segítenek a gyártóknak abban, hogy elérjék saját környezetvédelmi, társadalmi és vállalatirányítási (ESG) célkitűzéseiket is, és ezzel megfeleljenek a fejlődő ESG-irányelveknek.

A fejlesztők egyre több eszközzel és funkcióval támogatják a vállalatokat a fenti célok elérésében, ami azért is fontos, mert azok a gyártók, akik figyelmen kívül hagyják ezeket a trendeket, lemaradhatnak a piaci versenyben a megfelelés növekvő adminisztratív terhei miatt, vagy ami még rosszabb, ha nem felelnek meg, akkor bírságokkal vagy az ügyfelek elvesztésével kell szembenézniük.

Az alapvető célok mindenkinél ugyanazok. A minőség kezelése, a hulladék minimalizálása, a készlet optimalizálása, a szabályozások betartása, a kereslet, az átmenő teljesítmény és a kínálat összehangolása, hogy csak néhányat említsünk. A tanácsadó cégek egyre gyakrabban találkoznak fenntarthatósági és az ESG-vel kapcsolatos célkitűzésekkel. Egyeseket a felmerülő jogszabályok, másokat a határokat feszegető és példamutató szervezetek vezérelnek.

A gyártók aktívan keresik a módját annak, hogy működésüket a fenntartható gyakorlatokhoz igazítsák. Az ERP-rendszerek számos módon támogathatják ezeket a célkitűzéseket. Sok esetben képesek olyan adatokat szolgáltatni, amelyek lehetővé teszik a szervezetek számára, hogy a működési folyamataikat a fenntarthatóság szemszögéből vizsgálják. A hulladékcsökkentés célja már nemcsak a költségkorlátozás, hanem a környezeti hatások csökkentésel is. Az ellátási lánc kezelése és nyomonkövethetősége már nem csak a költségekről, a biztonságról és a megfelelőségről szól, hanem támogathatja az etikus ellátási lánc menedzsmentet is. Nézzünk néhány példát:

Energiagazdálkodás és erőforrás-optimalizálás

Az ERP-rendszereket már régóta használják az erőforrás-felhasználás nyomon követésére, hogy lehetővé tegyék a tételenkénti vagy egységenkénti költségelemzést. Ez néha visszamenőleges adatgyűjtésen és alapértelmezett adatokon alapul, de sok esetben közvetlen adatkapcsolat van a MES-rendszerrel, illetve a gyártásban részt vevő gépekkel.

A gyártás digitalizálása egyre több érzékelőt, valós idejű adatot és fejlett elemzési és modellezési képességeket igényel, amelyeket néha a mesterséges intelligencia is támogat. Korábban az ilyen elemzések kizárólag a költségek csökkentésére vagy a minőség javítására összpontosítottak. Pozitív mellékhatásként azonban a szén-dioxid kibocsátás csökkentésével és a hulladék minimalizálásával visszafogta a gyártás környezetre gyakorolt hatását.

Egyre több ERP-szolgáltató bővíti az ERP-rendszerét olyan funkciókkal, modulokkal, amelyek a fenntarthatóság szemszögéből vizsgálják az adatokat és folyamatokat – modellezik a különböző gyártási tervek, folyamatirányítások és anyagfelhasználás szén-dioxid-kibocsátásra gyakorolt hatását. Ezáltal szén-dioxid-kibocsátásra vonatkozó jelentéseket is biztosít a megfelelés érdekében, a kifinomultabb példák esetében pedig olyan eszközöket is nyújtanak, amelyekkel proaktív módon lehet módosítani a termelési terveket, a folyamatok menetét, az anyagjegyzékeket és a receptúrákat a szén-dioxid-kibocsátás minimalizálása érdekében.

Az ellátási lánc átláthatósága és fenntartható beszerzés

Számos ERP-rendszer támogatja a szállítók értékelését és a beszállítók felvételét beépített folyamatokkal, valamint lehetővé teszi a jóváhagyott szállítók listájának kezelését és a beszerzési stratégiák végrehajtását. Az ilyen funkciókat már régóta használják a beszállítói bázis optimalizálására a költség és a minőség szempontjából.

A kereskedelem megfelelően tanúsított vagy akkreditált beszállítókra való korlátozása, valamint a kínálat koncentrálása vagy diverzifikálása a mennyiségi kedvezmények kihasználása érdekében, a kockázat minimalizálása és a beszállítói bázis közötti verseny fenntartása – hasonló funkciókat alkalmaznak mostanában a fenntarthatósági kritériumok beépítésére a beszállítói kiválasztási folyamatokba, és annak biztosítására, hogy az ellátási lánc partnerei osztozzanak az ESG-elvek iránti elkötelezettségben. A környezetvédelmi és etikus munkaügyi normák ellenőrzése is egyre inkább olyan súlyúvá válik, mint a nyersanyagok minőségének ellenőrzése. Az ERP által ellenőrzött beszerzési folyamatok segíthetnek biztosítani a szervezeti, szabályozási és akár fogyasztói követelményeknek való megfelelést ezen a területen.

Munkaerő-gazdálkodás

A társadalmi felelősségvállalás az ESG egyik legfontosabb szempontja. Az ERP-rendszerek számos módon támogathatják a munkaerő-gazdálkodásra vonatkozó kezdeményezéseket. A gyártók számára az ERP gyakran segít az egészségügyi és biztonsági előírásoknak való megfelelés ellenőrzésében – például annak biztosításában, hogy az üzemeltetők megfelelő képesítéssel rendelkezzenek bizonyos feladatok elvégzéséhez, az események nyomon követésében, a korrekciós és megelőző intézkedések kezelésében, a HSEQ-ellenőrzések (Egészség – Biztonság – Környezet – Minőség) támogatásában, stb. Ha egy ERP-megoldás átfogóbb munkaerő-gazdálkodási elemét alkalmazzák, az tovább bővíthető olyan kifinomult funkciókkal, amelyek támogatják a diverzitási, integrációs jelentéseket, vagy a munkavállalói jólétet szolgáló kezdeményezések megvalósítását.

Hol is kezdjük?