Validálás magyar módra

Kaptam egy érdekes megbízást.
Egy cég az év elején megvásárolt egy ERP rendszert, a rendszer fejlesztője elvégezte felmérést majd a felhasználókkal közösen elkészítették a módosítási terveket. Ezt a tervet kellett volna validálni. Az anyag ~1000 oldalt tett ki, folyamatábrákkal, képernyőképekkel, listaképekkel, így meggyőződésem, hogy az anyag már az induláskor készen volt, mert a felmérést követő egy-két hónap alatt ennyit nem lehet írni.
A megbízás a testreszabási fejlesztéseket megelőző validálásról szólt, de lényegében azt kellett volna megmondani, hogy a leírt anyag megfelel-e a cégnek.

Az első érdekes jel az volt, hogy a terv elfogadásának határidejét a gyár leállásának kezdetére tették, így a feladathoz szükséges idő maximum egy százaléka állt rendelkezésre, továbbá csak azokkal a munkatársakkal lehetett interjút készíteni, akik részt vettek a választásban és a módosításban. A módosítási tervek elkészítéséhez viszont nem volt igényjegyzék, azaz nincs mihez hasonlítani az elkészített anyagot.

Azért sok dolog így is értékelhető volt, pl., hogy a cég folyamatainak szervezettsége szokatlanul alacsony, egészen elemi kérdésekben is évtizedekkel van lemaradva a magyar átlaghoz képest is. Gondolok itt arra, hogy a nyilvános adatbázisokban tárolt mail címekből nem lehet megállapítani a vezérigazgató nevét és azt, hogy férfi-e vagy nő. A levelezési rendszer nem teszi lehetővé a képek, egyéb médiák továbbítását és a marketing értékű, kulturált és szép levélformátumok használatát, valamint arculat kialakítását, de magában az arculat kifejezés jelentésében is bizonytalanságot találtam.  A cég által küldött GDPR hozzájárulás kérő lap nem volt szerkeszthető, viszont ki volt töltve a cég egyik dolgozójának az adataival, aminél nagyobb GDPR incidens egyszerűen nem létezik. Nem beszélve arról, hogy a telefont nem veszik fel, a mail-re nem válaszolnak.
Az álló gyár bejárásánál úgy tűnt, hogy félrevezetnek, ezért egy trükkel bevontam egy ott bóklászó karbantartót, így valójában igen jó képet kaptam a mindennapi problémákról. A kompetens szakmai vezetéstől olyan kérdésekre nem kaptam választ, hogy hol lesznek a terminálok, milyen adatgyűjtők lesznek, a komputer vezérelt gépek hogyan lesznek bekötve az ERP rendszerbe stb. Azaz a módosítási igény jóváhagyásának pillanatában az elemi rendszertervezési feladatok sem voltak kidolgozva.

Ha nyolc nap alatt ezer oldalt kell értékelni, akkor csak arra van lehetőség, hogy betekintünk az anyagba, majd az ember kiválaszt egy területet és csak azt nézi meg alaposan.
Ez a beszerzés lett.
Egyrészt azért, mert az ERP csere is egy beszerzési folyamat, másrészt, mert egy PULL rendszerű gyártásnál ez a legkritikusabb területe a működésnek.
Magyarország a második legkorruptabb ország Európában és ne higgyük, hogy ez csak a politikusokra vonatkozik, mert egy beszerző is felmérhetetlenül nagy kárt tud okozni. Ez a pozíció ugyanis egy vagyoni értékű jog. Ha csak arról van szó, hogy jelentős túlárazást találok, attól a szemem sem rebben, mert a választás végül is jó. Nagy baj akkor van, ha némi (esetleg jelentős) kenőpénz miatt rossz a választás.  Az „átkos” negyven éve alatt kialakult klasszikus beszerzési folyamat pont erre lett kihegyezve és ezt használják a legtöbb helyen ma is. Valójában a jól felügyelt proaktív beszerzést (amelynek egyik lényege, hogy ne nagyon lehessen korrumpálni a beszerzőt) általában meg sem értik a KKV alsó-középső szintjén.
A riportok során olyan kérdésekre nem kaptam választ, hogy szervezetileg hova tartozik a beszerzés. Három kompetens (!) személytől három eltérő választ kaptam. Valójában még abban is bizonytalankodtak, hogy hányan dolgoznak a beszerzésen.
Az SzMSz kifejezés pedig zavarba hozta, az ezzel foglalkozó (bár új) munkatársat.

Miután nem kaptam hiteles információt ezért a legrosszabb (egyben a legvalószínűbb) választ fogadom el. Azaz a beszerző a termeléshez tartozik. Ez jó megoldás is lehetne, mert ilyenkor nem fenyeget az a veszély, hogy egy anyagot azért rendelünk meg máshol, vagy cserélünk le egy másikra, mert az 5 Ft-tal olcsóbb, felborítva ezzel a meglévő technológiát. Az is igaz, hogy ilyenkor előfordul, hogy a kelleténél jobb minőségű anyaggal dolgozunk, ami elemi érdeke a gyártásnak. A dolog akkor válik érdekessé, ha esetleg kiderül, hogy a beszerző egyben raktárvezető is és a beszerzési rendszerben kell megadni, azt is, hogy hova kell könyvelni a tranzakciót. A módosítási javaslatok érdekessége, hogy olyan gondosan szedtek ki minden számonkérhetőséget és áttekinthetőséget, hogy egy helyen még a beszállító is szükségesnek ítélte kiemelni, hogy a leírtak a vevő kérése volt.

„A modellezésen hozott döntés értelmében a ██████ nem fogja az igénykezelést használni (de kérésére az MMTT tartalmazza a sztenderd működés leírását). Mivel az igénykezelés nem része a folyamatnak, így a folyamatábrában nem lesz szerepeltetve.
Az MRP által tervezett beszerzési igények is rendeléssé lesznek alakítva, így az „Igény” menüpont nem lesz használva jelen megvalósítás értelmében.”

Azaz a klasszikus beszerzésből, kimarad az igények dokumentálása így nem fogjuk tudni, hogy a megrendelés milyen konkrét igény alapján keletkezett és milyen folyamat során jutottunk el a beszerzéshez!
Figyelemre méltó a beszállító megállapítása, miszerint az átadott anyagot véglegesnek tekinti. Ha nem tetszik, akkor a beépített eszközökkel módosítani lehet a képernyőképeket.
Természetesen tisztában vagyok azzal, hogy a vidéki ember eredendően becsületes, én azonban itt néhány éven belül lecserélném a Mercedesemet.

Összességében az állásfoglalásom a következő volt:
Áttekintve a kapott „Működési modell és testreszabási terv” nevű anyagokat, azt az álláspontot alakítottam ki, hogy a ██████ ERP rendszer jelen terv alapján történő üzembeállítása nem szolgálja a cég érdekeit.
A módosítási terv teljes egészében az alkalmazotti státuszú munkatársak igénye szerint készült, így kifejezetten korszerűtlen, az alkalmazottak érdekeit szolgálja és nem cégét.
Ami az üzleti folyamatokat és az IT rendszert illeti, úgy látom, hogy egy 40 évvel ezelőtti beszerzési technológia találkozik benne egy 20 évvel ezelőtti informatikai technológiával.
Bár a „Működési modell és testreszabási terv” nevű anyag – mind formájában, mind tartalmában és megoldásainak korszerűségében – komoly kivetnivalót hagy maga után, nem érdemes belekötni, mert mindenre az lesz a támadhatatlan jó válasz, hogy a megrendelő ezt kérte. Miután nem kaptam semmilyen írásos igényjegyzéket, a gyár meg állt a bejárás alatt, ez a védekezés nem is támadható.

Érdekes kérdés a rendszerválasztás is, de ezen már túl vannak.
Bár egy szavam sem lehet a választás ellen, mert az általam ajánlott választási módszertan egyike pont az, hogy nézzünk meg egy-két jól működő ugyanilyen céget, azt a rendszert válaszuk, amit ők használnak és attól a beszállítótól, aki náluk is bevezette.
És ez itt teljesült.
Azonban ezt a módszert akkor ajánlom, ha a cégkultúra olyan alacsony, hogy nem alkalmas egy ERP választásra és nem akarnak külsőst sem bevonni. Az elv az, hogy másoljuk le egy jól működő ugyanilyen cég megoldásait, a fejlődésben pedig jól fog vezetni miket az ő üzleti folyamataikat tartalmazó ERP rendszer.
Igen ám, de itt 1000 oldalon, folyamatszervezésben inkompetens munkatársak módosíttatták a rendszert.
Tehát a módszert egyszerűen kiherélték.

Beszéljünk a kiválasztott rendszerről.
A Progress adatbáziskezelő és fejlesztőkörnyezet nálam a kizáró tényezők között van. Eltekintve egy-két egészen speciális esettől – a KKV szinten a legfontosabb szempont, hogy a konfliktusokkal terhelt környezetben hány cég oktatja a rendszer használatát, hány helyen tudjuk megvásárolni, hány cég tudja karbantartani, optimalizálni, hány olyan iskola van, ahol a diákok ilyen képzést kapnak stb.
Lényegében egy ilyen hely van, azaz a kockázati kitettség megengedhetetlenül magas.
Nagyon érdekes a Progress 4GL nyelv fejlődése is. A WIKIPEDIA szerint:

„A nyelvet PROGRESS-nek vagy Progress 4GL-nek hívták a 10.0-s verzió kiadása előtt, de a PSC 2006-ban a OpenEdge Advanced Business Language-re (OpenEdge ABL) változtatta, azért, hogy leküzdjék azt az ipari feltételezést, mi szerint a 4GL-es nyelvek rosszabb képességekkel rendelkeznek, mint más nyelvek.”

Tehát nem átírták a rendszert, hanem átnevezték. Hozzátenném, hogy szerintem ez nem feltételezés volt, hanem tény.
A nyelv – erősen vitatható – előnye, hogy a végfelhasználó is tud nagyon gyorsan prototípust készíteni (erre a képességre hivatkozva utasította el fentebb, a képernyő képek javítását a fejlesztő).

A marketinganyagokat megnézve kétségkívül ez a világ legjobb rendszere. Ehhez valóban nagyon értenek. Érdemes azonban egy nyilvános szakmai beszélgetésből idézni két véleményt a magyarországi forgalmazójáról és legnagyobb fejlesztőjéről.

██████ Ildikó
██████ Zrt., az alkalmazottak szerintem 50 százaléka egyetem óta ott dolgozik (25+ éve)., pedig IT szektorban könnyen tudnak mozogni az alkalmazottak. Igen, ők sem hiszem, hogy tudják mi a lean, de tapasztalatom szerint van bizalom és homeoffice is.

 Andrea ██████
„Erre a cégre én pont az ellenkezőjét tudnám felsorolni. A bizalom és a vezetői képességek hiánya mellett pont az a hátulütője, hogy akik huszonéve ott dolgoznak azok már bebetonozódtak szakmailag is, az új gondolatok és megoldások nem fenyegetik őket. Bár tény, elfér a piacon néhány olyan cég is, akik a régi IT rendszerek támogatását tudják biztosítani, az újítás fenyegetése nélkül.”

Tehát ők oktatnak és képviselik a gyártót.

Érdekes a szóban fogó ERP rendszer fejlődése is.

• Ez a rendszer valójában az 1984 – ben kiadott MFG/PRO.
• 2007-ben az MFG/PRO termékét átnevezi „QAD Enterprise Applications”-ra.
• Felvásárolják a „FullTilt Solutions” csomagot, a „CEBOS”-t, a „DynaSys”-t.
• A DynaSys beintegrálása után átnevezik SCM rendszerré.

És megint az átnevezések.

Érdekes dolgokat találhatunk az adatbázisban is.

Mezőnév      Megszemélyesítés
wo_nbr          A gyártási megrendelés száma
wo_LOT        A gyártási megrendelés azonosítója
wo_ part        A legyártandó termék azonosítója

A megrendelés azonosítója arra utal, hogy ősidőkben ez a rendszer egy LOT-rendszerű gyártáshoz lett fejlesztve. Most éppen egy SARZS-rendszerű gyártáshoz ajánlják. Bár mióta a szoftvermérnökök gyártanak, azóta esetleges, hogy milyen kifejezést írnak, de mérget veszek rá, hogy nem tudják mi a különbség a LOT-rendszerű gyártás és a SARZS-rendszerű gyártás között.
Átnevezték.

A megvizsgált „Működési modell és testreszabási terv” (MMTT) nevű anyagban viszont egyáltalán nem találtam semmilyen SCM tulajdonságot.
Ezekre mondom, hogy a termelésirányítás átcsúszott a szoftvermérnökök kezébe.

Az MMTT meghökkentően korszerűtlen, igen alacsony színvonalú munka. Ez igaz mind az IT megoldásokra, mind a leképezett üzleti folyamatokra. A 25 éves jelenléttel és irodalommal rendelkező proaktív értékesítés meg sem érintette a rendszertervezőt, a képernyőképek silányok, a felhasználói terhelés túl nagy.
Kétségtelen azonban, hogy közös munkaként letettek 1000 oldalt az asztalra, így a fejlesztési díjak kifizetését nem lehet megtagadni. Jogilag ez egy vesztett ügy.

Meg kell említenem, hogy a céggel és az ERP rendszerrel kapcsolatban már voltam szakértő egy vesztes bírósági perben, ahol a teljes kifizetett összeget akarták visszaperelni. Egy egészen kiváló ügyvéd képviselte a vevőt, de az eladó által, abszolút profi módon megírt szerződéssel szemben tehetetlen volt.

Érdemes ebben a kérdésben is a Gartner oldalait lapozgatni:

” Contract negations were the worst I have ever encountered. They provided no flexibility and are forcing long time customers to migrate. There is little to no customization in the new platform and the migration services are using low skilled consultants that are difficult to work with.”

A szerződéskötések voltak a legrosszabbak, amivel valaha találkoztam. Nem biztosítottak rugalmasságot, és a hosszú távú ügyfeleket migrációra kényszerítik. Az új platformon alig vagy egyáltalán nincs testreszabás, és a migrációs szolgáltatások alacsonyan képzett tanácsadókat használnak, akikkel nehéz dolgozni. (gépi fordítás)

A rendszer kétségtelenül nagy és nagy cégek alkalmazzák. Pl. autógyár. Abban persze biztosak lehetünk, hogy az autógyárban nem azok a munkatársak végezték a felmérést, akik ezt az anyagot készítették. Nézzünk meg egy értékelést:

Több felmérés is van, azok sem jobbak.

Az 1. szint gyakorlatilag a felhasználásra alkalmatlan besorolás. Szintén a Gartnerre támaszkodva azt találjuk, hogy a QAD vs SAP esetén a SAP-nél, több mint tízszer ennyi minta alapján sem fordul elő 1. és 2. szint. Kifejezetten érdekes, hogy még jónak is nagyon kevesen mondták. A jó és a kiváló közötti szakadéknak az lehet a magyarázata, hogy csak azonos a helyeken tudtak kiváló eredményt elérni, ahol maguk a fejlesztő cégek üzemeltetik a rendszert. Ez viszont nagyon drága lehet.

Mi lehet a magyarázata az ennyire eltérő véleményeknek?
Úgy vélem, az általam használt besorolások közül ez a vevő számára „Túl jó rendszer” kategóriájú, amelyet egy alacsony ipari kultúrájú felhasználó sokszor elindítani sem tud. Ez persze nem jelenti azt, hogy a rendszer tényleg jó, csak azt, hogy a vevőhöz képes túl nagy. Ha ilyen rendszert veszünk, akkor ez jóeséllyel már a bevezetési fázisban megbukik. A munkatársaink sem egészében sem részletében nem fogják érteni működését, szemlélete idegen lesz számukra, az ilyen rendszer egy nem megfelelő környezetben egyszerűen használhatatlan.
Mit lehet ilyenkor csinálni?
Már nem sokat.
Általában csak nagyon nagy költséggel lehet kiszállni a szerződésből és ilyenkor a befektetett munka nagyrésze is elvész.
Az ERP rendszernek azonban vannak olyan területei, amelyeket törvények és jól kialakult szokások uralnak. Ilyen az ügyvitel, amely kiegészülhet akár kontrollinggel is.
Ezeken a területeken nem kell módosításokat kérni, pl. egy sok helyen már működő könyvelésen nincs mit fejleszteni, azt át kell venni. Bár ezeken a területeken lehet kisebb sikereket elérni, de általában az idő előtti csere a megoldás.

Térjünk vissza a proaktív beszerzéshez. Ekkor a központosítás miatt a választás a beszerzéshez tartozott volna az IT helyett. A proaktív eljárást ismerő, képzett beszerző pedig rendelkezik megfelelő tárgyalástechnikával, jogi ismeretekkel, képes értékelni a szerződéstervezeteket, gyakorlata van a jogászok bevonásában, nem okoz nekik gondot külső szakértő bevonása, képes az értéklánc elemzésére és így a cég egészének az érdekét képviselni.
A beszerzők aligha választották volna ezt a rendszert.

Budapest, 2024. szeptember 2.

________________________

                  Kupán Károly

Kupán Károly
Számítógépes tervezési, szervezési és gyártási mérnök (BME)
Fizikus (ELTE)
Katonatiszt (százados – Nyíregyházi főiskola)

Kupan.Karoly@kupan.hu
+36-20 264-75-14
http://ERPcsere.hu
http://BI-Control.hu (archívum)
http://Kupan.hu
LinkedIn (https://www.linkedin.com/in/k%C3%A1roly-kup%C3%A1n/)