ERP választási szempontrendszer

Ez az összefoglaló anyag elsősorban a KKV szektor számára készült, ahol meghatározó tényező az idő és az anyagi korlát, így a kiválasztást nem előzheti meg több éves tervezés és előkészítés. Itt gyors (néhány hónap!), és olcsó eljárásra van szükség.
A megfelelő ERP rendszer kiválasztása hosszadalmas és összetett munka, mert a kiválasztás alatt végső soron egy speciális minősítést végzünk.
Minden rendszer több nézőpontból is vizsgálható, amelyek lényegesen eltérő eredményekre is vezethetnek. Egy ERP rendszer vizsgálható a gyártó szemszögéből, a bevezető szemszögéből, a beruházó és végfelhasználó,  valamit a szakma szemszögéből. Meg kell értenünk, hogy a gyártó/fejlesztő minősítése nem lehet releváns, ha egy kiválasztásra vagy végfelhasználói minőségre vagyunk kíváncsiak. Ugyancsak nem célszerű a szakmai minősítés használta sem, hiszen az egy sokkal összetettebb szempontrendszer szerint értékel, amire a végfelhasználónak általában nincs is szüksége. Neki általában a sorrend a fontos.

A kiválasztásnál tehát a végfelhasználói igényekhez kell illeszteni a minősítési szempontokat. Az első lépés mindig magának a hierarchikus szempontrendszernek az összeállítása. A hierarchikus szempontrendszer – a követelményjegyzék – azért szükséges, mert 15-20 szemponttól már az értékelési feladat átláthatatlanná válik.
A szempontrendszer összeállítása általában a szempontok kiválasztását, a számszerűsítés módszerét és súlyozását jelenti. A kiválasztott szempontokat mindig szakmai teljességgel kell megvizsgálni, de azt, hogy egy-egy szempont mennyire fontos a felhasználónak, azt egy súllyal célszerű figyelembe venni. Most egy ilyen szempontrendszert mutatunk be, amely azonban végfelhasználói szinten tetszőlegesen alakítható és súlyozható.

A módszerhez tartozó lépések:

• kizáró szempontok összeállítása,
• a minősítési szempontok összeállítása,
• a szempontok súlyának meghatározása,
• szakterületi minősítések stratégiájának meghatározása,
• a szakterületi minősítések skáláinak kialakítása,
• szakterületi minősítések megszervezése és lebonyolítása,
• az adatok összesítése.

Meg kell említeni a számszerűsítés problémáját. A számszerűsítés skálák felállításából áll. Beszélhetünk névleges (nominális) skáláról, sorrendi (ordinális), intervallum (különbségi) vagy arány (kardinális) skáláról. Az esetek többségében csak sorrendre vagyunk kíváncsiak, így elegendő lehet egy sorrendi skála felállítása és használata. Ennek előnye, hogy egyértelműen besorolható a vizsgált mennyiség, hátránya viszont, hogy a fokozat határokat nem mindig egyszerű megadni, de a skála finomításával javul az eredmény.
A kizáró szempontok nominális skála szerint kerül megadásra (igen, nem), az értékelésben ugyanis már egy nem teljesített szempont esetén sem vesz részt az ajánlat.

A skála kialakítás mindig a szempontrendszer kialakítását követi.

A következő tisztázandó kérdés az ajánlatok begyűjtésének módja. Annak ellenére, hogy a potenciális beszállítók adataihoz ma már könnyedén hozzá lehet jutni, viszonylag ritkán történik meg a teljes körű ajánlatadásra való felkérés. Az egyfordulós pályáztatás az ERP választás esetében nem tanácsos, mert a személyes kapcsolat kialakítás elengedhetetlen. A versenyeztetés esetében a megrendelő és a jelöltek közötti kommunikáció fontossá válik, mert az idő és források hiányában általában nem csak ERP rendszert, hanem beszállítót is választ a megrendelő. A KKV-k esetében nem javasolható az előminősítés kihagyása és általában a kétszintű tenderezés hozza meg a megfelelő eredményt (ugyanis ebben a szektorban ritka az igények pontos megfogalmazása).

A kiválasztás legfontosabb ökölszabálya az, hogy a beszállítók előadásainak meghallgatásával, megbízhatóan nem választható ki ERP rendszer!
Az alább bemutatott szempontrendszer csak gondolatébresztő, végfelhasználói szinten tetszőlegesen alakítható és súlyozható.
Indulásként foglalkozzunk néhány olyan kérdéssel, amelyet nem szoktunk számszerűsíteni ugyanakkor a siker szempontjából rendkívül fontosak lehetnek.

ERP rendszer kiválasztása

Az ERP rendszerek szellemisége

Az ERP rendszer a cég valóságos működésének egyfajta modellje. Minden cég – egy adott gazdasági és társadalmi környezetben lévő emberek közössége, így a maga teljességében hihetetlenül bonyolult a működése. A kezelhetőséget az biztosítja, hogy a működésének leírásából rengeteg folyamatot kihagyunk, a maradék folyamatokat pedig önálló egységekre osztjuk.
A szakterületekre és /vagy a folyamatokra való bontás tehát elkerülhetetlen a feladat összetettsége miatt, de ezzel elvesztettük azt az információt, amely a teljes rendszert – a maga egészében – jellemzi. Nevezhetjük ezt az ERP rendszer szellemiségének. Ez a szakterületi minősítések minden pontján jelen van ugyan, de közvetlenül nem része a számszerűsített eredménynek. Azért jelenik meg mégis a minősítésben, mert maga a követelményjegyzék is hordoz egy szemléletet, mégpedig a beruházó szemléletét. Az ERP rendszerek szellemisége megdöbbentően eltérő lehet, holott magát az alapfeladatot ettől még tökéletesen elláthatják. Van például kifejezetten technikai szemléletű rendszer, van határozottan könyvelő szemléletű rendszer, van projekt szemléletű rendszer és így tovább.

Az ERP rendszerek szemlélete a cég hosszú távú fejlődését befolyásolhatja. Amit szemléletnek nevezünk az nem egyéb, mint az egyenszilárdság sérülése a modulok között és a modulokon belül. Ilyenkor a rendszerben vannak kiemelt fontosságú, így pontosabban modellezett üzleti folyamatok és vannak elhanyagoltabb üzleti folyamatok. (Az egyenszilárdság súlyos megsértése elsősorban a kis létszámú fejlesztőközösségek esetén észlelhető, amikor egy-egy vezéregyéniség kényszeríti rá a fejlesztésre az elképzeléseit.) Talán a legrosszabb az az eset, amikor az ERP rendszerben az informatikus szemlélet uralkodik. Ezekben a rendszerekben a technikai elemek dominálnak, gépkönyveik nehezen érthetőek (nem informatikusok számára esetleg érhetetlenek), és a rendszer általában tele van gazdaságilag értékelhetetlen csicsamicsákkal. A következő legrosszabb eset a könyvelői szemléletű ERP rendszer. Ezek igen jónak tekinthetőek abban az esetben, ha a cél az, hogy a NAV gyorsan és hatékonyan tudja megbüntetni a cégünket, de pl. tökéletesen alkalmatlanok gazdaságelemzésre, teljesítménymérésre vagy tervezésre, amiket viszont a legfontosabb üzleti folyamatoknak tekintek. Itt a veszély az, hogy ezek a rendszerek gyorsan kinőhetőek és ekkor le kell cserélni őket. A gondot az okozza, hogy a csere felmerülése és lebonyolítása között évek telhetnek el, ami a cég számára elveszett idő. Tipikusan ilyen rendszert választanak azok a cégek, ahol a könyvelőknek vagy az informatikusoknak túl nagy a befolyásuk.

Ezt a veszélyt úgy kerülhetjük el, hogy gondosan ügyelünk arra, hogy a döntőbizottságban minden terület azonos érdekérvényesítő képességgel rendelkezzen.

A cégek információ igénye és a Maslow elv.

A másik érdekes kérdés a cégek információs igénye és innovációs képessége. A Maslow elv (1943, szociológus) azt mondja ki, hogy az emberi igények hierarchikus rendben helyezkednek el. Egy magasabb szintű igény csak akkor jelenik meg, ha az alacsonyabb szintű már kielégítésre került.

Ez az elv kiterjeszthető a szervezetek információs igényére is. Az információs szükséglet ekkor is jól ábrázolható a Maslow piramissal.
Az ERP rendszerek kiemelten fontos jellemzője, hogy milyen kérdésre milyen választ tudnak adni. Minél fejlettebb egy rendszer annál bonyolultabb kérdésre tud feleletet adni. Az ERP rendszer sikeres működéséhez az kell, hogy az ERP rendszer képessége összhangban legyen a cég információs szükségletével.

(ERP: Enterprise Resource Planning; BI: Business Intelligence; OLAP: On-Line Analytical Processing)

A szervezetek információigényének a szintjei

Első szint. Az információs igény legalsó szintje az egységes és integrált adatbázis létrehozása és üzemeltetése. Ez mindenképpen egy megfelelő üzembiztonságú és kapacitású hardverrendszert igényel. Ha az adatok szintjén bizonytalanság van, akkor a rendszer egészét megbízhatatlannak fogja a felhasználó ítélni és minden következtetés is a bizonytalanságot fogja hordozni. Ekkor a rendszer gyakorlatilag használhatatlan. Ha sikerül kialakítani az összefüggő, robosztus és megbízható adathalmazt, akkor automatikusan megjelenik a jól használható, a mindennapi munkát segítő beszámolói rendszer iránti igény.

Második szint. Az integrált rendszer megteremti a lehetőségét a működési beszámolók bevezetésének. A működési beszámolók iránti igény először a felső, majd a középvezetés, végül a végrehajtás szintjén jelenik meg, ugyanis minden tevékenységet könnyebbé tesz. Itt nem magukról a beszámolókról van szó (hiszen ezek a rendszerrel együtt érkeznek), hanem a használatuk iránti igényről. A beszámolókat az ERP rendszerek hagyományos technikákkal kezelik. Ez a szint elsősorban a végrehajtási és a középvezetési szinten lévő operatív igényeket  elégíti ki.

Harmadik szint. Ha a cégnél már megszokták a működési beszámolók használatát, akkor ezt követően megjelennek az ad-hoc beszámolók iránti igények, mert a történésekre a működési beszámolókból nem kapunk választ. Most nem arra kell gondolni, hogy megjelennek új beszámolók iránti igény, amelyet ki kell fejleszteni, hanem kifejezetten arra, hogy a felhasználók maguk akarják összeállítani – elsősorban elemzési célokra – az új kimutatásokat. A tetszőlegesen összeállítható beszámolók lehetőséget teremtenek a vizsgálódásra és így választ adhatunk arra kérdésre, hogy ami történt, miért történt. Ilyen elemzéseket elsősorban a középvezetői szinten kell végezni. Az érdekesség kedvéért megjegyzem, hogy ha a felhasználók több száz beszámolót kértek már az üzemeltetéstől, az nem az ad-hoc beszámolók iránti igény megjelenését jelenti, hanem azt, hogy még nem alakult ki a működési beszámolók iránti igény sem.

Negyedik szint. A következő szint már a felsővezetői döntéseket meghozatalát támogatja. Ezek már az üzleti intelligencia eszközrendszerére épül, amely nagy rendszerekben már beépítve található. Ez olyan mértékű szabadságot biztosít, amely lehetővé teszi, hogy az áttekintő elemzéstől néhány kattintással juthassunk el az alapadatok elemzéséig. Ezt „Drill Down” technikának nevezzük. Ezen a szinten a cég működése döntés előkészítési igénnyel elemezhető, amelyet tipikusan pénzügyi és szakterületi kontrollerek végeznek.

Ötödik szint. Efölött már a stratégiai kérdések megválaszolásához szükséges információs szükséglet és eszközrendszer található. Eszköze tipikusan az on-line analízis, az előrejelzési technikák és az adatbányászat, amikor a meglévő adatokban explicit nem szereplő információkat keresünk. Bár ez a szint komoly versenyelőnyt biztosít, a KKV szektorban a költségei következtében nem szokás ezt a szintet implementálni.

A Maslow elv szervezetek információs igényére történő kiterjeszthetősége alkalmat ad néhány következtetésre:

• A fejlettebb rendszer iránti igény akkor fog megjelenni, ha a fejletlenebb szint igényeit már kielégítettük.
• Ha egy szint igényeit kielégítettük, akkor a következő szint iránti igény automatikusan megjelenik.
• Egy igényszint átlépésének bukás lesz a következménye.
• Ha az új ERP rendszer nem elégíti ki a következő szint információs igényeit, akkor annak bukás a következménye.

Számolni kell azzal is, hogy a szervezeti egységek innovatív képessége és információs igényének a szintje nem azonos, ezért olyan ERP rendszert célszerű választani, amely egyszerre képes – egymástól függetlenül – több szintet is kiszolgálni. Ha az ERP rendszer kiválasztása és bevezetése jól sikerült, akkor a cég üzleti folyamatai is fejlődni fognak. Ez új elvárásokat ébreszt, amire a rendszernek reagálnia kell. Ezért olyan ERP-t (sokkal inkább fejlesztő közösséget) kell választani, amely képes az igények követésére.

A jelenlegi helyzet elemzése

Az új ERP rendszer telepítése előtt fontos lenne meggyőződni, hogy a rendszer cseréjéhez valós igény tartozik-e. Ez ellenőrizhető úgy, a cég munkatársainak feltesszük azt a kérdést, hogy az új ERP bevezetése mennyivel növeli majd a nyereséget és miért? A kapott válaszokból eldönthető, hogy kik a védnökök, ügyfelek, célpontok és szószólók. Tehát látni fogjuk, kik lesznek a húzó munkatársak és hol kell veszélyre számítani.
Az új rendszer iránti igény felkeltésének egyik módszere, hogy a jelenlegi rendszer alapján végzünk egy gazdaság elemzést és rámutatunk, hogy hol, mit veszít a cég. Meg kell keresni és bizonyítani kell, hogy hol vannak korszerűtlen, esetleg hibás üzleti folyamatok és meg kell mutatni, hogy azok kijavítása az új rendszer segítségével milyen előnyöket jelent cég és az egyén szintjén. Az elemzésbe és az elvi szinten történő újratervezésbe be kell vonni a cég munkatársait.  Ha ez nem sikerül, akkor a projekt veszélyeztetetté válik.

Ennél egy sokkal hatékonyabb módszert alkalmaztak a rendszerváltás után ide települt multik, mert nekik nem volt idejük megvárni, hogy az új ipari kultúra iránti igény természetes módon kiépüljön. Az idő valóban őket igazolta, ugyanis a  magyar cégek zöménél a mai napig sem alakult ki pl. a tervezés és az elemzés iránti igény. Ezért ők azt a módszert alkalmazták, hogy Európa fejlettebb régióiból ide telepítettek olyan munkatársakat, akikben az információs igény már eleve megvolt, ezért ők el sem tudták képzelni, hogy az itteni viszonyok mellett hogyan lehet egyáltalán céget vezetni.  Amikor az ilyen munkatársak száma átlépte a kritikus tömeget, akkor már a hátukon elvitték az új rendszert.

A felmérés módszertana

A módszerek elvi alapját az adja, hogy minden folyamatnak van valamilyen nyoma, ami lehet:

– papíralapú,
– humán alapú,
– digitális.

A papír alapú felmérés eszköze a dokumentumáramlás elemzése, ehhez létre kell hozni a bizonylatalbumot, amely a cégnél használt az összes bizonylatot tartalmazza, legyen az kézzel vagy az ERP rendszerrel létrehozva. Ezek alapján kell elkészíteni az érdekesebb folyamatok dokumentumáramlását, ami történhet saját jelölésrendszerrel vagy valamelyik (a munkatársak által nehezebben értelmezhető) professzionális eljárással. Az album az új rendszer bevezetésénél és konfigurálásánál is hasznos segédeszköz.

A humán alapúé felmérés eszköze a mély interjú. A módszer legnagyobb problémája, hogy a munkatársaknak nem érdeke az évek alatt felhalmozott – és így értéket jelentő – tudásának átadása. Technikai nehézséget okoz a jegyzetelés, ill. a dokumentálás. Az interjút mindig visszakereshetően kell rögzíteni és általában az ismeretanyag kiteljesedése után meg kell ismételni.

A folyamatok digitális nyoma az adatbázisban található. Azt mondhatjuk, hogy a meglévő ERP rendszer által támogatott folyamatnak pontos lenyomatát találjuk az adatbázisban. Ennek elemzése gyors és hatékony, eszköze általában valamilyen BI rendszer (pl.: az SQL szerver részét képező SSAS). Az adatbázis gondos elemzése az üzleti eredményeken túl tartalmaz információt a cégen belüli szokásokról, a munkavégzés pontosságáról és sok minden más adottságról is. Különösen hasznos a működési hibák feltárása.

Ritkán fordul elő, hogy elegendő egyetlen módszer használata, tehát az adatbázis elemzés esetben is biztosan sor kerül írott dokumentumok vizsgálatára és interjúra is.

Vannak olyan üzleti területek, ahol elengedhetetlen a személyes gyakorlat megszerzése, a napi munkában való közvetlen részvétel. Ilyen pl. a termelésirányítás.

A tesztüzem és párhuzamos üzemeltetés

A siker fontos kritériuma a tesztüzem időtartalmának szakszerű megválasztása és a tesztüzem lebonyolítása. A tesztüzemet követően célszerű még egy ideig együtt üzemeltetni a régi és az új rendszert. Ezeknek a folyamatoknak a támogatását általában nem várják el a bevezetőtől, annak ellenére, hogy közvetlenül befolyásolja a költségeket és a sikert. Ezen túlmenően mindig számolni kell a párhuzamos üzem okozta túlterheléssel.

Meg kell említenem, hogy több bevezető is kifejezetten ellenzi a párhuzamos üzemet. A párhuzamos üzemnek kétségtelenül van hátránya, de mielőtt elhagyjuk, gondoljuk át, hogy a javasolt megoldás mögött nincs-e hátsó szándék. A párhuzamos működtetés ugyanis összehasonlításra ad alkalmat.

A régi rendszer üzemben tartása

Sok esetben (szinte mindig) szükség van arra, hogy a régi rendszer még üzemben maradjon, miután az új rendszer csak ritkán van feltöltve a régi adatokkal. Ugyanakkor az év zárásánál, nyitásánál, speciális kérdéseknél, elemzéseknél vissza kell nyúlnunk a régi adatokhoz. Ügyelni kell arra, hogy a régi rendszer üzemben tartási költsége szerepeljen az új rendszer tulajdonlási költségei között.
Ezeket a problémát megoldhatja egy olyan üzleti intelligencián alapuló elemzőrendszer, amely egyszerre és konszolidálva képes kezelni eltérő ERP adatbázisokat. Ilyenkor ugyanaz az eszköz elemzi a régi és az új rendszer adatait, a régi rendszer üzemben tartására nincs is szükség, hiszen az elemzéshez csak az adatbázis szükséges.

Most térjünk át a szempontrendszerre

Kizáró szempontok összeállítása

A kizáró szempontok olyan alapkövetelmények, amelyeket a kiválasztott információs rendszernek mindenképpen teljesíteni kell. Rendkívül fontos a követelmények lehető legprecízebb megfogalmazása. Ha egy ERP rendszer a kizáró szempontok valamelyikét nem teljesíti, akkor már a kiválasztás folyamatában, a minősítésben sem vehet részt.

A kizáró szempontok sokrétűek lehetnek (pl.):

• legyen grafikus felhasználói felület,
• a konzulensek beszéljenek magyarul,
• legyen magyar nyelvű gépkönyv és online help,
• legyen nyitott architektúra,
• adott operációs rendszeren működjék,
• adott alkalmazás integrálható legyen,
• legyen kliens/szerver architektúrájú,
• legyen jogszabálykövetés hozzá,
• az ára essen adott tartományba,
• Legyen felhasználói szinten is telepíthető,
• legyen felhőben futó verziója,
• stabil mentési rendszer megléte,
• képes legyen több nyelv kezelésére,
• képes legyen több pénznem kezelésére.

A válaszok nominális skálán helyezhetőek el (Tudja / nem tudja). Annak ellenére hogy egy rendszer belefut egy kizáró szempontba, érdemes a kérdőív kitöltését folytatni. Részint később szóba jöhet egy kompromisszumos megoldás, ráfejlesztés, stb.

Funkcionális teljesség

 A funkcionális teljesség valószínűleg mindenhol a legfontosabb szempont, tehát magas súlyértéket célszerű neki adni. Ennek keretében azt kell megvizsgálni, hogy a kínált rendszer mennyire felel meg a beruházó szakmai elvárásának. A funkcionális teljesség vizsgálatánál határozottan meg kell különböztetni a valódi megoldásokat a helyettesítő megoldásoktól és a teljességi igény megállapításánál sohasem a pillanatnyi elvárást célszerű alapul venni, mert az ERP beruházások legfontosabb eredménye általában az, hogy ennek mentén újra lehet szervezni a cég üzleti folyamatait. A funkcionális teljességet tehát már az újraszervezés utáni helyzethez kell viszonyítani.
A funkcionális teljesség megvizsgálása azonban egyáltalán nem egy egyszerű feladat.
Két szélsőséges módszer célszerű megemlíteni.

A tervezett rendszer fő folyamatainak felmérése

A fő folyamatok felmérésének és rögzítésének az a célja, hogy vezesse az üzleti folyamatok újratervezését és közvetítse az igényeket az ERP beszállítója felé. A folyamatokat célszerűen folyamatábrákkal kell megjeleníteni. Jelölésrendszere lehet egyéni, de ekkor a felméréshez az értelmezést és a jelölési rendszer magyarázatát mellékelni kell. Egy példa:

Ezeken az ábrákon sorrendet és eseményt is lehet ábrázolni. Meg kell határozni azt is, hogy milyen adatok kezelését és tárolását várjuk el az ERP rendszertől. Ez manapság különösen fontos lehet, hiszen az üzleti intelligencia (BI) rendszerek már elszakadtak az ERP rendszerektől, azoktól függetlenül, azok adatbázisán működnek.

Ez szintén készülhet belső jelölésrendszer alapján, de ekkor a jelölési rendszert dokumentálni kell. Az alábbi ábra például egy pénztár adatbázis legfontosabb kapcsolatait mutatja be.

Továbbá el kell készíteni egy igényjegyzéket, amely az elvárásokat rögzíti. Ez történhet konyhanyelven, de a nem meghatározott részleteknél a bevezetőnek (esetleg a fejlesztőnek) ezzel szabad kezet adtunk.

Példa a konyhanyelven megfogalmazott igényjegyzékre:

• Az utalványozó a nevének kiválasztásával (aláírásával) zárolja a bizonylat tételeket. A tételek mindaddig nem módosíthatóak, ameddig a bizonylaton szerepel az utalványozó aláírása. Ha az utalványozó az aláírását visszavonta (törölte a nevét a mezőből), akkor a bizonylat módosíthatóvá válik.
• Az utalványozó az aláírását akkor vonhatja vissza, ha a bizonylaton nincs rajta a főkönyvelő vagy az ellenőr aláírása.
• Az utalványozó neve belépéskor automatikusan megjelenik, ha benne van az Utalványozók felhasználói csoportban.
• Az utalványozónak csak ahhoz van joga, hogy a nevének kiválasztásával aláírja a bizonylatot.
• stb., stb.

Ebben az eljárásban az elkészült anyagot át lehet adni a beszállítónak, aki kötbér terhe mellett nyilatkozik, hogy képes-e a feltételek kielégítésére, ill. a kért megoldások helyett milyen megoldásokat ajánlana.

Ez az eljárás igen munkaigényes, de nagyon megbízható, és gyakorlatilag nélkülözhetetlen, ha az ERP beruházást az üzleti folyamatok újratervezésével kötjük egybe.
Az lenne igazán szép, ha maga az ERP rendszer biztosítaná a működésének folyamatábráit.
Erre ne számítsunk.

Demó rendszer használata

A funkcionális teljesség vizsgálható egy demo rendszer üzembeállításával is. Természetesen ez esetben is szükség van arra, hogy pontosan tudjuk, hogy mit várunk el az új ERP rendszertől, de ekkor saját magunk akarunk meggyőződni arról, hogy a rendszer teljesíti-e a fő funkciókban az elvárásainkat.
A módszer igen nagy hátránya, hogy sok ERP rendszer oktatás nélkül szinte kezelhetetlen, viszont kétségtelen előnye, hogy azokban az esetekben, amikor nem forrott ki teljesen az elvárás, a lehetőségek bemutatásával sokat segíthet. A demó rendszer üzembeállítása mindig megtérül, azonban, ha csak ezzel a módszerrel dolgozunk, akkor igen rossz döntéseket is lehet hozni.
Nyugodtan várjuk el, hogy az ajánlattevő saját eszközparkjával biztosítsa az üzemképes, tesztadatokat tartalmazó rendszert. Azt viszont nem várhatjuk, hogy ezt ingyen tegye meg.

A mindennapi gyakorlat

A mindennapi gyakorlat mindezek ellenére az, hogy a funkcionális teljesség kérdésében közvetett információk alapján dönt a beruházó. Miután egy néhány (4-8) órás bemutató alatt képtelenség megtudni, hogy valójában mit is kapunk, ezért ilyenkor a tényleges döntés alapja nem az ERP rendszer, hanem valami más. Ilyen lehet a bemutató szakember személyes varázsa, megjelenése, magbiztossága, a referenciák értékelése, stb. Nagyon hasznos háttér információ, hogy a legnagyobb konkurencia milyen rendszerrel dolgozik, és mekkora referenciája van a rendszernek az iparágunkban.

De ekkor nem az ERP rendszert minősítettük!

Ami tilos

Tilos döntést hozni a fejlesztő / beszállító prezentációja alapján.

A beszállító üzleti stabilitása és megítélése

A beszállító üzleti stabilitása alapvető fontosságú kérdés. A legtöbb rendszer a beszállítói/fejlesztői háttér nélkül nem képes működni, mert minden céget folyamatosan érnek olyan hatások, amelyre a szervezetnek reagálni kell és a hatásokra válaszokat kell kimunkálnia. A szervezet működését modellező informatikai rendszernek pontosan ezért szintén folyamatosan fejlődnie kell. Ha a beszállító tönkremegy vagy üzletágat változtat, akkor az ERP beruházás csak a veszteségek rovatokat fogja növelni.

Ennél a pontnál tekintetbe lehet venni azt, hogy a nagy példányszámban eladott szoftverek esetén igen hamar keletkezik egy (de általában több) olyan új cég, amely átveszi a kiesett cég szerepét, ha másért nem, akkor a piaci részesedés megszerzéséért. Nagy jelentőségű rendszerek esetén ezért ennek a szempontnak a súlya csekély. Kisrendszerek általában nyom nélkül tűnnek el, viszont ilyenkor kicsi az anyagi és erkölcsi veszteség is. Ha belefutunk ebbe a helyzetbe, akkor döntő fontosságú, hogy időben keressünk új partnert, ill. kezdjük el az átállás egy újabb (és mindenképen) fejlettebb rendszerre.
A beszállítók üzleti stabilitását erre specializálódott cégek vizsgálják, szükség esetén hozzájuk is fordulhatunk.

Szállító általános megítélése

A megítélést alapozhatjuk a referenciákra, az auditált minőségirányítási és biztonsági rendszerek meglétére, a szakma által elfogadott fejlesztési módszertanok használatára, a szállító szervezeti tagságaira, szakembergárda nagyságára, végzettségére és tapasztaltságára, az alvállalkozói háttérre, publikus pénzügyi adataira (mérleg, eredmény, mérleg-főösszeg, alaptőke), stb.
Minősíteni kell a szállítási és üzembe helyezési határidőket, a szavatosságot, a jótállást, a termékfelelősséget, és biztosításokat, a bevezetési projektmódszertant, betanítást, a tanterveket és oktató anyagokat, az adatfeltöltés eszközrendszerét, a tesztállomány meglétét és minőségét.
Ne feledjük el azt sem, hogy egy ERP rendszer bevezetése és üzembentartása nem IT feladat, ezért kockázatos olyan beszállító választása, ahol az informatikusok vannak túlsúlyban és előnyös olyan cégek választása, ahol a könyvelők, könyvvizsgálók vagy gyártási szakemberek dominálnak.
A szupport kérdését önálló pontban elemezzük.

Üzemeltethetőség

Kulcskérdés, mely több oldalról is vizsgálandó.

A rendszerrel szembeni igények teljesíthetősége

Némelyik nagy-rendszer meglepően nagy erőforrás igénnyel tud fellépni. Tekintsünk meg egy példát egy nagy ERP rendszer indulási terhelésére.

Ebben az öt percben, ha az informatikai rendszer csak egy kiszolgálót (egy magot, ill. egy mag használható) tartalmaz, akkor minden állni fog, a teljes rendszer gyakorlatilag erre az időre lefagy (kezdve az internettől, a nyomtatásig bezárólag). Ez persze egy ritka folyamat, de például egy számla lezárása már nem az. Az alábbi példán egy 15 tételes számlát fogunk lezárni, mégpedig egy kifejezetten jó gépen (2 processzor, 8 mag, 8 GB memória).

Itt is jelentős ideig áll minden szolgáltatás.

Ezen több megoldással lehet segíteni.

1. Több processzoros és/vagy több magos gépet állítunk üzembe. A következő ábrán egy olyan megoldást mutatunk be, ahol a lezárásokat végző gép részére önálló magot biztosítottunk, az operációs rendszer és az SQL szerver a 0-ás magon, az ERP az egyes magon fut. Vegyük észre, hogy az SQL szerver könnyedén kiszolgálja az igényeket, így a lezárást végző gép nem akadályozza a rendszer többi elemének a munkáját. Mindazonáltal célszerű ennél sokkal jobb gépet használni.

Terhelés – ERP rendszer kiválasztása

2. A másik megoldás, hogy az erőforrás igényes műveletek éjszaka fussanak. Ez akkor jöhet szóba, ha a rendszer biztosítani tudja az erőforrás igényes műveletek batch-ben történő elvégzését és a felhasználás olyan, hogy ez üzletileg is elfogadható. Mindkét megoldáshoz tehát az kell, hogy az ERP rendszer képes legyen a fenti folyamatokra. Bár számos üzleti folyamat és elemzés végezhető éjszaka, ennek ellenére kevés rendszer áll ezzel a lehetőséggel.

3. Az igazán jó megoldás azonban a jól megválasztott hardver és a jól kiválasztott szoftver. A mai hardverárak mellett egy komoly ERP rendszer alá semmi esetre se tegyünk gyenge gépet. Sajnos az ERP szoftverek esetén rosszabb a helyzet. Itt ellenőrizni kell, hogy az ERP rendszer képes-e önállóan futtatni szálakat.

Az igényjegyzékben tehát mindig meg kell fogalmazni a válaszidőkkel szembeni elvárásunkat. Ennél azonban nagyon körültekintően kell eljárni, mert egy túlzott igény könnyen jelenhet egy nullát a kiszolgálók árának a végén.
A rendszerrel szembeni igények egy speciális területe a billentyűhasználat ergonómiája. Mindaddig, amíg napi 15-20 bizonylatot kell kiállítani  tökéletesen megfelel az egér és billentyűzet párhuzamos használta. Egy olyan helyen azonban, ahol több száz tételt rögzítenek egy menetben, ott csak olyan rendszer jöhet szóba, ahol nem kell egeret használni. Ezeken a munkahelyeken kiemelten fontos szempont a beviteli eszközök használatának tanulmányozása és minősítése. Az egér használata a felhasználói terhelést jelentősen növeli, amivel a rendszer használhatóságát radikálisan képes csökkenteni.

Felhőben történő üzemeltetés igényei

Ha a rendszer felhőben üzemel, akkor kulcsfontosságú az internetkapcsolat sebessége, de még ennél is sokkal fontosabb a rendelkezésre állása. Sajnos ez Magyarországon nem tekinthető egy erősségnek. Már jóval a döntés előtt vizsgálni kell az internetkapcsolatot és be kell szerezni egy mérésre alkalmas eszközt. Az eszköz azt dokumentálja, hogy mikor milyen minőségű kapcsolat áll rendelkezésre.  A stabil működés érdekében elkerülhetetlen, hogy azonnal SMS-t kapjunk, ha a rendelkezésre állás nem megfelelő.
Vizsgálni kell a back-up kapcsolat lehetőségét is. Szükség van továbbá egy megfelelő minőségű routerre/tűzfalra és a lokális hálózat elemeinek és teljesítményének is megfelelőnek kell lenni.

Rendszergazdával/alkalmazásgazdával szembeni elvárás

Önálló szempontként kezelhető, hogy az ERP rendszer milyen követelményeket állít a rendszergazdával szemben. A rendszergazda képes-e önállóan a rendszer működtetésre vagy minden kérdéssel a bevezető céghez kell fordulni. Meg kell vizsgálni a beszállító által nyújtott rendszergazda képzés feltételeit, teljesíthetőségét és költségeit is. Fontos kérdés az is, hogy a rendszer mennyire képes nélkülözni a rendszergazdát és mennyi ideig képes felügyelet nélkül működni. Gondoljunk például a szabadságok alatti helyettesítés kérdésére.
Vannak rendszerek, amelyek rendkívül komoly követelményt támasztanak a rendszergazdákkal szemben. Az alábbi ábra egy jól ismert rendszer felhasználói kézikönyvéből való:

Ez pedig egy másfajta szemléletű rendszer gépkönyvéből való:

Ebben a nagyon népszerű rendszerben a – fenti mentegetőzés ellenére – a legelvadultabb kifejezés talán a „mátixnyomtató” volt.
Nyilvánvaló tehát, hogy a rendszergazdával szembeni elvárás is nagyon különbözik a két rendszerben.
Sokszor a feladatokat meg is osztják és külön van rendszergazda és van az ERP rendszert üzemeltető alkalmazásgazda, miután a két feladat eltérő képzettséget igényel.

Felhasználókkal szembeni elvárás

Minden rendszer terheli a felhasználókat, de nem mindegy, hogy mennyire. Ebben a pontban azt kell megvizsgálni, hogy a rendszer milyen követelményeket támaszt a felhasználókkal szemben. Elegendő lesz-e egy képzés vagy szükség lesz felhasználók cseréjére is. Kérdés továbbá, hogy a munkatársak felvételénél szükség lesz-e speciális szempontok figyelembevételére. Elemezni kell a felhasználói oktatás felépítését, gyakoriságát és költségeit, ellenőrizni kell, hogy egy munkatárs távozásakor a cég saját erejéből képes lesz-e az új munkatárs betanítására vagy minden cseréhez egy oktatás költsége is járul-e, mindez mennyi időt vesz igénybe és a kezdeti szakaszban mekkora hiba aránnyal fog dolgozni az új munkatárs.
Egy egyszerű vizsgálati módszer lehet például az, hogy a végfelhasználók kezébe adjuk a felhasználói leírást és egy valós feladat kapcsán kiértékeljük az eredményt.
A felhasználó terhelés másik oldalát a referencia látogatás eredménye adja.
Az éles üzembeállítást mindenképpen előzze meg a munkatársak vizsgáztatása és ezt sohase az oktató menedzselje.

Garancia

Még a drága ERP rendszerek esetén is jelképes a garancia. A gyártók és beszállítók is azt szokták mondani, hogy a szoftver olyan-amilyen. Tény, hogy nagyon nehéz a szoftverek valamely tulajdonságára azt mondani, hogy ez hiba. Mondhatjuk, hogy én jobbszeretném, ha így működne vagy azt, hogy én másképpen oldottam volna meg. De azt, hogy hiba, még akkor is nehéz bizonyítani, ha a teljes adatbázisom elveszett.  (Az évek során számos ilyen szakértői munkám volt és többször kellett bíróság előtt is véleményt nyilvánítanom. Minden esetben az a probléma, hogy minden komolyabb kár esetén kimutatható mindkét fél hibája.)
Véleményem szerint a jelenség mögött a fejlesztési szemlélet megváltozása áll. Egy emberöltő előtt a fejlesztés még valahogy így nézett ki:

A termék 100%-os készültségi állapotban – egy nullszéria vagy tesztszakasz után – került a piacra és a marketing is csak a teljes készültség elérése után indult be.
Ma ez valahogy így néz ki:

Szinte az ötlet pillanatában elindul a marketingkampány, a termék pedig már akkor a piacra kerül, amikor csak az alapfunkciókat tudja nyújtani és csak az u.n. SP-k sorozata után éri el a tervezett szolgáltatási szintet.
A módszer hatalmas előnye, hogy ebben a formában a termékfejlesztési költségek zömét maguk a vásárlók menet közben finanszírozzák meg.
Persze felmerül a kérdés, hogy mi felhasználók, miért nem támadjuk meg ezt a fejlesztési módszert?
Azért mert eszünk ágában sincs az SP1 előtt felhasználni a rendszert. Megvesszük, mert maradéktalanul bízunk abban, hogy az első néhány SP után egy jól használható termékünk lesz, addig meg van elég időnk megtanulni az új szolgáltatásokat, rákészülni az esetleges újraszervezésekre és végezetül bevezetni az új rendszert.
Ez egyben azt is jelenti, hogy mindig kalkulálnunk kell a követési szolgáltatással.

Értékelni annyit kell, hogy – a követés címén – hány év után fizetjük ki még egyszer a teljes rendszert, ill. azt kell ellenőrizni, hogy minden frissítést automatikusan megkapunk-e. Az 5 év feletti teljes rendszercsere elfogadható érték.
Van azonban egy olyan eset, amikor egyértelműen garanciális hibáról beszélünk, éspedig ha a gépkönyv nem követi a szoftver működését, ill. fordítva. Kőkeményen kell érvényesíteni a garanciát abban az esetben, ha saját fejlesztésű modulokról beszélünk. Ekkor is tisztázni kell, hogy a SP-k érintik-e majd a saját fejlesztésű modult.

Az üzemeltetés költségei

Egy ERP rendszer működtetésének vannak induló költségei és vannak rendszeres fix ill., eseti költségei. Ilyen fix költség lehet a szoftverkövetés, de ide kell sorolni a rendszer folyamatos működtetéséhez szükséges hardver és szoftver költségeket is.  Ezek rendszer-felügyeleti költségek formájában jelennek meg akár belső erőből oldjuk meg, akár kihelyezéssel. Jelentős tétel a védelmi rendszerek (Vírus, SPAM, behatolás védelem) rendszeres fix költsége, és készülni kell a tartalék alkatrészek költségeire is.
Ezek a költségek erősen ERP függőek, feltétlenül kalkulálni kell velük és még a beruházás előtt pontosan meg kell határozni az ERP rendszer teljes körű tulajdonlási költséget, tisztázva, hogy hosszútávon vállalható-e.

A felhasználói leírások, gépkönyvek, on-line help

Több szempontból is ellenőrizni kell az elektronikus és nyomtatott anyagokat, a legfontosabbak a:

• formai követelmények,
• szerkesztési követelmények,
• tartalmi követelmények,
• gyakorlati használhatóság.

A felhasználói leírások és a hibaüzenetek alapjaiban határozzák meg a felhasználás sikerét és hatékonyságát. Ha a felhasználói leírások nem jó minőségűek, akkor azon túlmenően, hogy nem támogatják a napi munkát és a betanulást, azzal is jár, hogy sokkal gyakrabban kell a bevezetőhöz fordulni, amelynek jelentős anyagi kihatása is lehet.

A gépkönyvek és a help nyelve

Az idősebb korosztály idegen nyelv ismerete általában nem kielégítő ezért körültekintő döntést kell hozni, hogy vállalható-e egy olyan rendszer üzembeállítása, amelynek nyelve kizárólag angol (vagy egyéb nyelv). Arra számolhatunk, hogy az új generációk nyelvismerete már megfelelő egy angol nyelvű ERP rendszer használatához. A kérdés körültekintő döntést igényel.

Videó gépkönyv

Több fejlesztő cég is rátért már a videó gépkönyvek használatára. Kétségtelen, hogy az idősebb korosztály számára ez egy meglehetősen szokatlan és nehezen kezelhető megoldás. Tudomásul kell azonban venni, hogy új generációk legfőbb ismeretszerzési eszköze már a multimédia, számukra a videó gépkönyv egy természetes és hatékony eszköz. Abban az esetben, ha hagyományos gépkönyv már egyáltalán nincs, minden cégnek egyénileg kell eldönteni, hogy vállalja-e az írott gépkönyvvel nem rendelkező rendszer üzembeállítását.

Vevői elégedettség

A vevői elégedettség csak a hasonló nagyságrendű cégek tapasztalatainak begyűjtésével határozható meg, ugyanakkor a napi működés szempontjából fontos ismérve az ERP rendszernek. Felhasználói szempontból a több éves tapasztalat igen fontos lehet. Van olyan ERP megoldás, amely első pillanatban meglehetősen kényelmetlen, esetleg már-már hibásnak is tűnik, de még az ilyen esetekben is csak a hosszú idejű tapasztalat tudja megbízhatóan megmutatni, hogy a megoldás valóban rossz-e vagy csak szokatlan. Persze jobban szeretjük, ha a rendszerek illeszkednek a napi gyakorlathoz, de ennek megsértése nem biztos, hogy igazi hátrány. Ugyancsak a tapasztalat képes arra rávilágítani, hogy egy adott gép és egy adott ERP rendszer teljesítménye hosszútávon milyen végfelhasználói terhelést jelent.
Kissé kellemetlen, hogy minket leginkább a konkurensek tapasztalatai érdekelnek.
A felhasználói referenciákat mindig a szállító/bevezető nélkül látogassuk.

Ár, ár/teljesítmény

Bármennyire furcsa, ez nem igazán fontos mérőszám. Ne feledjük már kiestek az előírt ártartományon kívüli rendszerek. Egy ERP rendszer sikeres bevezetése sokkal nagyobb előnyökkel jár, mint amibe kerül, ugyanígy a sikertelenség esetén a vételár elvesztése valószínűleg a kár legkisebb tétele. Az ár vizsgálatánál azt célszerű elemezni, hogy csak olyan tételeket tartalmaz-e, amelyet a végfelhasználó valóban használ is és ellenőrizni kell, hogy a rendszer megvásárlása után nem jelennek-e meg újabb, korábban nem kalkulált tételek. Gondosan ellenőrizni kell, hogy a költségek nem tolódtak-e el az alkalmazói szoftver irányába és a megajánlott hardver, alapszoftver, kapcsolódó szolgáltatások  és a környezeti feltételek kialakításának a költségei pontosan jelennek-e meg a költségvetésben.
Elemezni kell a fizetési feltételeket, a határidőket, az esetleges kötbéreket, az ajánlott ár érvényességét, árengedményeket, ezek valódiságát, fizetési ütemezést, és a várható áremelések mértékét. Figyelembe kell venni az esetleges bérleti díjakat, a karbantartási díjakat, tartalékeszközök árát, a védelmi szoftverek árát és frissítési díjait, követési és tanácsadási díjakat, stb.
Törekedni kell olyan szerződés megkötésére, ahol a rendszer üzembeállítása után kell fizetni. Elemezni kell a lízing és bérleti lehetőséget, mert a  konstrukció által nyújtott biztonság lehet, hogy ellensúlyozza a magasabb árat.

Licence stratégia

A licence szám alapjaiban befolyásolja a beruházás költségét, ezért gondot kell fordítani a pontos licence szám meghatározására. Az igény megadásakor inkább alacsonyabbat kell mondani, mert növelni sokkal egyszerűbb, mint csökkenteni, de pontosan tudni kell, hogy licence szám növelésével átlépünk-e mennyiségi határokat és váltásnál hogyan változik a beszállító licence stratégiája.
Az optimális licence szám meghatározásánál vegyük figyelembe, hogy a legtöbb esetben van helye az alutervezésnek, azaz az ERP rendszernél is meg lehet csinálni, hogy kevesebb licence legyen, mint ahány ERP felhasználó van. Bár elvben jól mérhető a statisztikailag elegendő licencek száma, a gyakorlatban általában adathiány miatt nincs mód a mérésre.
Ha tehetjük, ne számoljunk olyan megoldással, amely hardverkulcsot alkalmaz. A beszállító nem korlátozhatja a felhasználót abban, hogy a cég mely gépéről akarja futtatni az ERP rendszert.

Nem számolunk olyan szoftverekkel sem, amelyek kizárólagos (dedikált) licencezést alkalmaznak.  A KKV szektorban a humán erőforrás az egyik legszűkebb erőforrás. Elkerülhetetlen, hogy egy munkatársat, több szerepkörben is megjelenjenek és az is, hogy egy szerepkörhöz több munkatárs is tartozzék. Ez azt jelenti, hogy ugyanazt az ERP funkciót, hol az egyik, hol a másik szerepkör használja, de – erőforrás hiány okán – mindig csak egy munkatárs fér hozzá a rendszerhez. Megengedhetetlen hogy olyankor, amikor a standard működésből következően egymást kizárva két munkatárs használ egy modult, a normál működéshez két önálló licencet kelljen megvásárolni. Ugyanez a helyzet a délelőtti és délutáni munkarend esetén. A modullal kizárólag egy ember tud dolgozni, de vagy csak délelőtt vagy csak délután. Indokolatlan a két licence megvásárlása. Minőségbiztonsági szempontból pedig elfogadhatatlan az a megoldás, hogy közös felhasználónevet használjanak a munkatársak.

Tisztázni kell, hogy a licence kötődik-e a szoftverkövetési szolgáltatáshoz.

Szoftver követés

Az ár megítélésénél figyelembe kell venni a szoftver követési szolgáltatást és díjtételeit, miután a teljes fenntartási költség jelentős hányadát képezi. Szerződéses szinten kell pontosítani, hogy a követés mit tartalmaz és milyen mértékben. Összege általában úgy van megállapítva, hogy a vételárat 5-8 év alatt kell még egyszer kifizetni. Ettől jelentősen eltérő díj óvatosságra int. Rendkívül barátságtalan üzenet, ha egy szoftvert csak a követési szolgáltatással együtt lehet megvenni. Ez azt sugallja, hogy a fejlesztő / beszállító nélkül a rendszer tartós üzemre képtelen.

A felhasználónak az lenne előnyös, ha a beszállítók többféle, önállóan megrendelhető követési szolgáltatással rendelkeznének.

Törvényi változások követése. A törvényi változások bekövetkezése sem a vevőn sem az eladón nem múlik. Megegyezés kérdése, hogy a követéshez szükséges ráfordítás kit terhel. A józan ész szerint a törvényhozást kellene terhelnie, de ettől még nagyon távol vagyunk. Minden esetre szükség van egy olyan szolgáltatásra, amely a törvényi változások követését attól függetlenül biztosítja, hogy van-e általános követési szolgáltatás.

Hibák javítása. A programhibák javítása önálló tevékenység nem függhet attól, hogy van követési szolgáltatás vagy sem. A problémát az okozza, hogy rendkívül nehéz annak megállapítása és bizonyítása, hogy valóban programhibával állunk-e szemben.

Frissítések. Frissítések alatt olyan fejlesztéseket értünk, amelyet nem a vevő rendel meg. Ezek a rendszer szolgáltatásait bővíthetik, kényelmi megoldásokat biztosíthatnak, esetleg új funkciók jelenhetnek meg. Ezeknél a frissítéseknél a vevő döntheti el, hogy igényt tart-e rá vagy sem. Ez nagyon fontos. Egy-egy belenyúlás, ha nem tartozik hozzá részletes oktatás vagy testreszabás egy jól működő környezetben sokkal nagyobb zavarokat okozhat, mint amekkora előnnyel jár.

Verzióváltás. Sok cég a frissítéseket verziókban adja ki. Ugyanaz érvényes rá, mint a frissítésre. Elvárható, hogy a verzióváltás költsége függjön attól, hogy mely verzióról váltunk a legfrissebb verzióra.

Adott nagyságú fejlesztés. Sok cég beépít a követési szolgáltatásba adott óraszámú fejlesztést. Ez nagyon előnyös, különösen akkor, ha kumulálható a fejlesztési idő.

Help-desk szolgáltatás. Sok beszállító a help-desk szolgáltatást a követés keretében végzi. Tisztázni kell.

Egyéb szolgáltatás. Ide tartozhat adott nagyságú oktatás, tanácsadás, tanfolyamok, adatbázis műveletek. speciális utility-k biztosítása, stb.

Fontos kérdés a válaszadási idő nagysága és hogy valóban releváns válaszokat kapunk-e a feltett kérdésre. Ellenőrizni kel azt is, hogy a szoftverkövetés nem vezet-e olyan helyzetre, hogy cserélni kelljen az operációs rendszert vagy az adatbázis-kezelőt.

A részletek tisztázásakor több szempontot is célszerű vizsgálni, pl.:

– frissítési rendszer,
– hibabejelentő rendszer,
– szoftverkövetés,
– hibaelhárítás,
– utólagos igények kielégítése,
– tanácsadás,
– együttműködési készség és képesség,
– változásmenedzsment rendszere,
– ügyfélszolgálat,
– hírlevél,
– közösségi portál,
– felhasználói találkozók, konferenciák szervezése
– saját oktató terem megléte,
– oktatási tananyag megléte,
– bevezetési segédlet,
– megrendelhető-e a régi rendszer működésének az elemzése,
– megrendelhető-e az üzleti folyamatok elemzése,
– kérhető-e tanácsadás az üzleti folyamatok újraszervezésében,
– menedzselik-e az üzleti folyamatok újraszervezését,
– menedzselik-e a próbaüzemet,
– menedzselik-e a párhuzamos üzemet,
– tudnak-e biztosítani kisegítő munkaerőt,
– stb.

Ma már nyugodtan várjuk el, hogy az ERP rendszer ismerje fel, hogy új frissítés található a fejlesztő Update szerverén, ahonnan akár automatikusan le is tölti a frissítést. A hibabejelentő rendszertől elvárjuk, hogy naplózza bejelentésünket, adjon számunkra egy esemény azonosítót és nyomon tudjuk követni a történéseket. A szakmailag felkészült ügyfélszolgálat minimum feltétel. Elvárhatjuk a távmenedzselési szolgáltatás és a Skype-on történő tanácsadást. A közösségi események (hírlevél, portál, konferenciák, stb.) szervezése egy nagyon fontos háttér információ lehet, mert ezek szervezése és fenntartása nagyon munkaigényes és kockázatos dolog. Aki erre vállalkozni mer az biztos a rendszerében és kellő súlyt helyez a felhasználóinak a kiszolgálására. Az oktatóterem kialakítása, a publikus oktatási anyag és a tesztadatok megléte szintén olyan magabiztosságot jelent, amit feltétlen értékelni kell.
Ezekből az adatokból elsősorban arra lehet következtetni, hogy a fejlesztő/bevezető cég mennyire gondoskodik az ügyfeleiről.

Szoftverminőség

Nem igazán meghatározó szempont. Annak ellenére nem érdemes túlzottan nagy erőt fordítani a szoftver minőségének meghatározására, hogy ez egy nagyon jól kidolgozott terület. A szoftverminőséggel összefüggő legtöbb kérdés megjelenik az üzemeltethetőségben, ugyanakkor a végfelhasználót nem maga szoftver minősége, hanem annak a felhasználásra gyakorolt hatása érdekli.
Amit szoftver oldalról vizsgálni érdemes az a mentési rendszer stabilitása, a telepítési eljárás, az ergonómiai szempontok teljesülése, a hibaüzenetek érthetősége, minősége és kulturáltsága, az on-line help megvalósítása és használhatósága, jogosultsági rendszer használhatósága, több nyelv és valuta együttes használhatósága, az egér és billentyűhasználat, a „szoftverintelligencia”, stb.

A fejlesztőeszköz

A szoftver minőségét alapjaiban meghatározza a fejlesztő eszköz és a fejlesztési környezet. Itt is érvényes a minőségbiztosítás alapelve: nem a végterméket, hanem a végterméket létrehozó szerszámot kell ellenőrizni. Ennek megfelelően a fejlesztőeszköz meghatározza, hogy bizonyos hibák nem fordulhatnak elő, és azt is, hogy milyen problémákra lehet számolni továbbá alapjaiban meghatározza, hogy milyen szolgáltatásokkal és kezelési elvekkel rendelkezik a rendszer. Minél korszerűbb eszközzel történt a fejlesztés, annál jobb termékre lehet számítani. Sajnos számolnunk kell azzal, hogy a piacon nagy számban találhatunk olyan rendszert, amely nagyon korszerűtlen eszközökkel lett fejlesztve. Ezektől óvakodni kell.
Több olyan rendszer is van, amelyik saját fejlesztőeszközzel, sőt olyan is amely saját nyelvvel rendelkezik. Ezek között van abszolút profi eszköz is és nagyon amatőr is. Legyük gondosak a megítélésnél.

A telepítési rendszer

Alapvető elvárás az egyszerű, jól kezelhető telepítési megoldás megléte. Ha ilyen nincs, vagy egy közepes felkészültségű rendszergazda nem tudja a gépkönyv és az egységes telepítő anyag alapján magától értetődő módon feltelepíteni a rendszert, akkor kétszer is gondoljuk meg, hogy szükségünk van-e rá. A kényelmetlen (nem létező) telepítési megoldás azt mutatja, hogy a fejlesztő / forgalmazó / bevezető maga sem ítéli a rendszert készterméknek. Ha a rendszer felhőben üzemel, akkor ez nem szempont (0 súlyú).

Mentési rendszer

Hatalmas különbség van aközött, hogy a mentési rendszer része-e a terméknek vagy önálló (az operációs rendszerhez tartozó) mentést kell használni. Az egyik esetben a sikeres mentést a fejlesztő / bevezető garantálja a másik esetben a felhasználó. Ellenőrizni kell azt is, hogy a bevezetésnek része-e a mentési rendszer paraméterezése, hogy a mentéshez tartozó gépkönyv kellően részletes-e.
Tévedni emberi dolog, de igazán nagy gazságot csak a visszatöltésnél tudunk elkövetni. Ez a legkritikusabb üzemeltetési feladat, így kiemelt figyelmet kell rá fordítani.
Akkor járunk el leghelyesebben, ha a kész és beparaméterezett rendszer átvételének utolsó lépésében elegánsan kiadjuk a FORMAT C: utasítást.
Ugyancsak ellenőrizni kell azt is, hogy a beszállítónak van-e lehetősége a mentések teszt célú visszatöltésére. Ez azért lényeges, mert mindig akkor derül ki, hogy a mentési adathordozó nem használható, amikor összeomlott a rendszer. Ha a rendszer felhőben üzemel, akkor azt kell ellenőrizni, hogy milyen garanciákat biztosít a szállító az adatvesztés ellen és pontosan rögzíti-e a szerződés a kötbér kérdését.

Tesztadatok

Azt szeretjük, ha a beszállító rendelkezik tesztadatokkal. Nyugodtan várjunk el négy-öt évnyi tesztadatot, ahol egy év adatmennyisége a mi adatmennyiségünk közelében van. A rendszer valódi viselkedése csak ebben a környezetben vizsgálható. Ilyen tesztadatbázissal sajnos csak kevés cég rendelkezik.

Az adatbázis

A legfontosabb kérdés azonban az adatbázis fajtája és minősége. A hosszú távú felhasználás szempontjából döntő fontosságú az adatbázis dokumentáltsága. Ha az adatbázis szerkezetéhez nem lehet hozzáférni az egy nagyon barátságtalan üzenet.
További ökölszabályként fogadhatjuk el, hogy csak olyan ERP rendszer szabad üzembe állítani, amely SQL adatbázist használ. (Az már szinte mindegy, hogy melyik SQL adatbázis kezelővel dolgozunk, de célszerű az MS SQL és az Oracle közül választani. Ne feledjük, hogy ezeknek van ingyenes verziója is!)
Ma már általánosnak mondható, hogy valamilyen külső eszközzel elemezzük az ERP rendszer adatait és ennek kimenete szinte mindig Excel vagy Excel szerűség. Ezek az eszközök pedig általában az SQL adatbázis kezelésére vannak kihegyezve.
Semmi esetre se vegyünk meg olyan rendszert, amelynek az adatbázisát már nem supportálja a gyártó (pl. FoxPro).

Érdekes kérdés, hogy szabad-e használni nyílt forráskódú adatbázis-kezelőt (pl.: PostgreSQL-t).  Kisebb rendszerek esetén elfogadható ez a megoldás is, de több tízmilliós rendszerek esetén szükség lehet az adatbázis-kezelőhöz tartozó professzionális háttértámogatásra. Ilyenkor nem célszerű kockáztatni.

Lebonyolítás

A lebonyolítás lényegesen eltérő akkor, ha több ERP közül szeretnénk választani, és ha egy adott ERP rendszer használhatóságát szeretnénk igazolni. Általánosságban mindössze annyi mondható, hogy a minősítés mindenképpen szakterületenként és folyamatonként történjen és kiemelt fontosságú, hogy a szakterületek képviselői lehetőleg azonos felkészültségűek és azonos érdekérvényesítő képességű munkatársak legyenek.
A rendszer kiválasztáshoz általában egy üzleti folyamatleírás, egy írott követelményjegyzék és egy kérdőív tartozik. Az ajánlatkérés fázisban ezeket az anyagokat kell kiküldeni a pályázóknak. A pályázatokat pedig azonos módszertan mellett kell értékelni.
Ajánlott külső szakértő bevonása.

Az értékelés

Az értékelést minden rendszer esetén ugyanaz a szempontrendszer alapján kell elvégezni. Az értékelés tiszta és világos elrendezésben történjék, eszköze általában egy Excel tábla.
Célszerű egy kétfázisú értékelést kidolgozni. Az első fázisban a pályázó a kérdőív alapján egy önértékelést ad, ami elegendő a sorrend kialakítására. A kérdőív valójában arra szolgál, hogy a rendszer bemutatása ne a pályázó marketing technikáján alapuljon, hanem kifejezetten a vevői igényekre épüljön.
A második lépésben történik a pályázó meghallgatása, a kompromisszumok megkötése és a pályázat végleges minősítése. A végleges minősítés egy független kérdőív alapján történik, amely már hozzá van igazítva a kínálathoz. Ebben a menetben előfordulhat, hogy ismételten meg kell hallgatni korábbi pályázókat is.
A döntést követően történik meg a szerződéskötés.
Számoljunk azzal, hogy az értékelést a pályázó meg szeretnék majd nézni.

Szerződéskötés

 Az esetek többségében csak egy formális szerződés készül, amely egyik fél jogait és kötelességeit sem szabályozza kellő pontossággal. Ez sajnálatos módon azon a rossz beidegződésen alapul, hogy mindkét fél arra számít, hogy a felületesen megírt szerződés neki fog kedvezni. A nehézséget az okozza, hogy egy jól megírt szerződés több száz oldal lenne, a jogászok pedig a szerződések műszaki, informatikai, vállalatirányítási és gazdálkodási tartalmához általában egyáltalán nem értenek.

Sokat javíthat a helyzeten, ha az ERP rendszer bemutatásakor és a későbbi – a szerződéskötést megelőző – pontosítás során az elhangzó követelményeket és ígéreteket olyan pontossággal jegyzőkönyvezik a felek, amely a szerződés tartalmi mellékletét képezheti.

---

Kupán Károly (@2015)                     ERP rendszer kiválasztása v 1.07