Egyedi szoftverekről őszintén

Tekintve, hogy aktívan ezzel foglalkozunk, pontosan látjuk, hogy melyek a legnagyobb problémák és egyben félelmek ügyfeleink szemében az egyedileg fejlesztett szoftver rendszerekkel kapcsolatban.

Mindössze 2 szó! Nem kipróbált. Más szóval nem lehet előre megnézni, kipróbálni, “játszani” vele és megbizonyosodni arról, hogy tényleg nem kidobott pénz és idő pazarlás lesz az egész folyamat.

Mi mindenképp azt javasoljuk, hogy 2 felé bontsuk a szerződést (és a kifizetést is). Tehát válasszuk el egymástól élesen a felmérés és a fejlesztés-bevezetés szakaszt. Így már idejekorán láthatunk egy előzetes vázat a programból és tömör leírást, amiből az is kitűnik, hogy értjük-e egymást a bevezetést végző céggel, tetszik-e a tervezett kezelőfelület, megvannak-e a főbb funkciók, amiket kötelezően elvárunk.

Ha nem, itt még szinte fájdalom mentesen hagyhatjuk abba, s ha meg igen, akkor pedig nyugodtabban alszunk, hogy jó kezekben vagyunk 🙂

Aktuális IT trendek zanzásítva

A minap az alábbi beszélgetésnek voltam fültanúja:

…oké, de az IOT már mindenütt ott van, az okos óvszertől az okos kávéfőzőig…

És vicces, mert 2 hölgy beszélgetett minderről 🙂

Egyébként igaz. A listát nagyban vezeti az IoT, ami a netre kapcsolt (valamire jó) okos eszközök gyűjtőfogalma. Itt most leginkább azon megy a harc, hogy mit lehetne még eképp okosítani, illetve lassan elgondolkodunk a (hiányzó) biztonságtechnikai odalán is a dolognak. Most hogy 2x annyi ilyen eszköz van, mint ember.

Tovább fejlődik és komolyodik a 3d nyomtatás módszere, amivel már 2 emeletes házat is lehet “nyomtatni”.

Business intelligence, ami lassan nem csak adatokat rendszerez és tényszerűen elénk tárja,hanem a következtetéseken és trendek felállításán túl, már akár stratégiai döntésekre vonatkozólag is tehet javaslatot. Sőt megindokolja a javaslatot és mindebből folyamatosan tanul is persze (ez a verzió azért még nem elterjedt).

Mesterséges intelligencia. Fülünkön jön már ki, nagyon keményen dolgozik rajta az emberiség, az biztos. A haladás és drasztikus fejlődés igen rövid távon (5 év) belül is érzékelhető lesz.

Robotok – cél, hogy minél többet vegyenek át tőlünk, s maradnak a kevésbé gépesíthető munkák nekünk embereknek még jó ideig.

Önvezető autók – ezek is csodálatosak, s bár még fogni kell a Tesla legújabb modeljében is a kormányt, nincs messze, amikor jó minőségű utakon (felfestéssel) tényleg az autóra bízhatjuk magunkat.

Felhő alapú szolgáltatásokról is sokat hallani, végre úgy néz ki Magyarországon is nő a bizalom ez irányba. Korábban 10 ügyfélből cask kettő vállalta be, most megfordulni látszik az arány, kevésbé félünk a lehallgatnak/meglopnak/megzsarolnak hármastól.

VR, AR, MR és AV. Szinte örök sláger és időről időre fel-fel bukkan. Rétegtermék, nagyon úgy tűnik, hogy egyelőre inkább a játékipar próbál profitálni belőle. Épphogy felkerült az aktuális listánkra.

IT trends 2017

2017 nyár végi aktualitások

3 érv a felhő alapú ERP-k mellett

1. A felhő alapú ERP rendszerek valóban megreformálják a céget

mert a programot amivel cégünket irányítjuk, bárhonnan elérhetjük, s mindezt különösebb technikai hozzáértés és saját IT-s részleg nélkül tehetjük meg.

2. A felhős rendszerek segítségével végre kizárólag azzal foglalkozhatunk, amihez értünk

sokunkra igaz, hogy nem igazán értünk az IT-hoz, igaz? Miért is kéne nekünk feltalálni a kereket? Foglalkozzon vele az, aki ért hozzá, s akinek ez a szakmája. Mi pedig nyugodtan tudjuk azt csinálni, amiért a céget létrehoztuk, amiben jók vagyunk.

3. A felhőnek a biztonsága kockázata igen csekély

az irányítás elvesztésétől való félelem a “legközkedveltebb” indok, amiért nem ezt a megoldást választják a cégek. Ugyanakkor gondoljunk csak bele: a cég, akinél a programunk és adataink vannak (“a felhő szolgáltató”) sokkal többet veszíthet, mint mi, hisz sokaknak szolgáltat. Ergo többet tesz a biztonságért mi mint valaha is tudnánk, vagy akarnánk.

Modern ERP a felhőben

/A Panorama Consulting Solution cikkének kivonata/

2017.06.02

ERP rendszer gyakorlati bevezetése egy élő példán keresztül

 

Sokat olvasni az ERP rendszerek előnyeiről és bevezetési hasznosságáról, de hogy valójában ez mekkora volumenű tervezést és irányítást kíván mind a szolgáltató, mint pedig a kivitelező részéről, azt már kevesen ismerik.

Ennek okán készítettük el ezt a hosszabb terjedelmű ám hiánypótló cikkünket, amely mint egy élő riport taglalja a tervezéstől a megvalósításig a folyamatokat.

Az alábbi sorokban részletesebben bemutatjuk egy ügyfelünk esetében (Kerko Hungária Zrt.), hogy hogyan is történt a saját vállalatirányítási rendszerük (ERP) bevezetése.

A KERKO Hungária Zrt. bemutatása: A Kerko Zrt. 1995 óta foglalkozik hidegburkolatok kis- és nagykereskedelmével. A vállalkozás adatait az alábbiakban lehet összefoglalni:

o Éves árbevétel: kb. 1.5 milliárd Forint.
o Alkalmazottak száma: 40 fő.
o Telephelyek száma: 5 db.

Kiskereskedelmi fürdőszoba szalonok Győrben, Miskolcon, és Tiszafüreden, nagykereskedelmi telephelyek Budapesten, Győrben, Miskolcon és Tiszafüreden találhatóak. Termékprofiljuk minden, ami fürdőszoba és hidegburkolat: fali csempe, konyha csempe, padlólap, járólap, lépcsőlap, gress lap, lábazat, homlokzati lap, klinker burkolat, mozaik. Mintaboltjaikban a kerámia burkolatok mellett megtalálhatóak szaniteráruk, csaptelepek, fürdőszobabútorok, csemperagasztók, fugázók, élvédők is. A KERKO szlovák, cseh, a lengyel, valamint a szerb gyárak áruit forgalmazza. Valamennyi forgalmazott termék É.M.I. engedéllyel rendelkezik, továbbá az ISO 9002 minőségi szabványnak is megfelel.

Riport:

A kiváltandó ERP/ügyviteli rendszer felépítése

Az alkalmazott, kiváltandó alkalmazás egy régi DOS (!) alapú program, amely a projekt indulásakor már erőteljesen lecserélésre szorult, annak ténye mellett, hogy egyszerűségénél fogva jól ellátta a feladatát. A program ismert hiányosságai:

o Szigetszerű rendszerként működött, azaz nem volt egy közös (törzs)adatbázisa, helyette minden telephelyen 1-1 önálló program futott, amelyek nem voltak egymással, és a központi adatbázissal – hálózaton keresztül – összeszinkronizálhatóak,
o A szinkronizálás manuális volt, amely a gyakorlatban azt jelentette, hogy naponta –a napi zárás után – tömörített (zip) állományok lettek a központba küldve az aznapi munka/forgalom tartalmával,
o A beépített kimutatások segítségével érdemi információk nem voltak kinyerhetőek, nehéz volt így irányítani egy erőteljesen növekvő céget,
o Programozás-technikai értelemben elavult volt, erre építeni – mint továbbfejleszthető rendszer – nem lehetett.

 Vállalatirányítási rendszer bevezetése a KERKO Hungária Zrt.-nél

Az alábbiakban az ERP rendszer fejlesztésére irányuló projekt – előkészítési, és bevezetési szakaszra osztott – leírása következik. A megvalósításhoz szükséges forrásokat a KERKO Zrt. Európai Uniós forrásból biztosította. A rendszer teljes költsége bruttó 14.738. 880 Ft.

Előkészítési szakasz

A projekt indításának menetében a célok kitűzése, és pontos definiálása – mint minden projektmenedzsment alapja – kiemelkedő fontosságú volt. El kellett fogadtatni a megrendelő

Kerko Zrt.-vel azon teljesítési paramétereket, amelyek mentén a felek közös akarattal sikeresnek nyilváníthatják az ERP bevezetésére irányuló projektjüket (másképp szólva ez azon minimum teljesítési pontok definiálását jelentette, amelyek működése esetében még elfogadható a rendszer, egy esetleges nem teljeskörű teljesítés esetében is). Az előkészítésre fordított időtartam: kb. 1 hónap (napi 8 órában, heti 40 munkaóra ráfordítás mellett).

Bevezetési szakasz

A pontosan megfogalmazott követelmények alapján előállt egy „rendszer-alrendszer-modul-funkció” alapú specifikáció, amely alapján már kiválaszthatóvá vált az Amtech Kft. által alkalmazott több különböző (fejlesztési) keretrendszer közül az a típus, amellyel a definiált követelményeket a legrugalmasabban lehetett megvalósítani.

Kiindulva a kezdeti követelményjegyzékből, az egyes mérföldköveket mindig részletes felmérés előzte meg, majd annak eredményei kerültek leprogramozásra. Egyúttal ez volt az a pont, amelytől számítottan az üzleti folyamatokat már „mélységében” kellett feltárni, amely a gyakorlatban, az adott területet képviselő kollégával folytatott interjúk sorozatát jelentette. Az adott mérföldkő felmérését követően – az alkalmazott fejlesztési módszertan, és eljárás fejezetekben részletezettek szerint – megkezdődött a fejlesztés, majd a kétszintű tesztelés, amely állt:

Belső tesztből – szállító végezte. Elemei:

o Adott mérföldkő elemeinek tesztelése,
o Regressziós teszt a rendszer egészére nézve (miután az elkészült adag beillesztésre került a nagy egészbe).

Külső tesztből – megrendelő végezte, főleg a kulcs felhasználók
A fejlesztés és kétszintű tesztelés az alkalmazott fejlesztési módszertan mentén haladt megközelítőleg 1 teljes éven át.

A fejlesztés utolsó egy harmadában természetesen igen nagy időt vett igénybe az alábbi – egyebekben egyébként az ERP rendszerek fejlesztése során szokásos – hármas feladatcsoport elvégzése. Ezek az alábbiak:

Adatmigráció – rendszerfejlesztés során általánosan ismert jelenség, hogy a megrendelő próbálja a legkevesebb adatot áttöltetni az új rendszerébe (ilyen minimum lehet például: ügyfelek/beszállítók, cikkek/termékek/szolgáltatások adatai). Jelen ERP bevezetés esetében esetben ennél jóval töbre tartott igényt a megrendelő Kerko Zrt. a példában jelzetteken felül a megrendelő az összes bizonylat – tehát az olyan bizonylatokat is, amelyek még nyitott tételként szerepeltek a kiváltandó rendszerben, és még munka van velük – adatainak migrálását rendelte meg.

A migráció időtartama: kb. 2 hónap (napi 8 órában, heti 40 munkaóra ráfordítás mellett).
Egyedi vállalatirányítási rendszer bevezetésének tapasztalatai

o Telepítés – az összes telephely, összes számítógépére felkerült a rendszer, melyet megelőzött egy géppark ellenőrzés, valamint egy szerverpark frissítés is. A projekt keretében két új nagy teljesítményű szerver került letelepítésre, és rendszerbeállításra. Ide tartozik még az is, hogy az internetsebességtől függően kellett választanunk a VPN, illetve a távoli asztali megoldás mellett. Gyakorlati tesztek alapján ez utóbbi megoldás került rendszeresítésre. A telepítés időtartama: kb. 1 hónap (napi 8 órában, heti 40 munkaóra ráfordítás mellett).

Oktatás – A Kerko Zrt.. valamennyi telephelyének alkalmazottait – közös oktatásokat tartva – be kellett tanítani az új rendszer használatára. Az oktatás alapjául ugyanakkor nem kézikönyv szolgált, hanem rövid tematikus videó anyagok készültek, amelyeket a későbbiek során a felmerült kérdéseik megválaszolására is felhasználhattak az alkalmazottak (tehát egyfajta „súgó” funkcióként is üzemel). A betanítás időtartama: az összes telephelyre vetítetten kb. 3 hónapot vett igénybe (napi 8 órában, heti 40 munkaóra ráfordítás mellett).

Tesztelés – éles üzem (pilot)

Amikor a fentebbi folyamat befejeződött, megkezdődhetett a pilot üzem. Ez jelenti azt a fázist, amikor a fejlesztés gyakorlatilag elkészült, és az éles adatokkal, és valós folyamatokkal megkezdhető a munka. Ezt az Amtech Kft. helyszíni, kihelyezett szakértői „jelenléttel” támogatta, azaz több kolléga is jelen volt az egyes telephelyeken, így bármikor segíteni tudott a Kerko Zrt. alkalmazottai részéről felmerülő kérdések megválaszolásában.

A tesztelést megelőzően meghatározásra került egy tapasztalati „hiba”, valamint „incidens súlyossági” küszöb szám, amelynek elérése (túllépése) a pilotüzem sikertelenségét jelentette. Az egyhetesre tervezett üzemidőn belül ez a szám elérésre került, ezért a felek – közös akarattal – a rendszer leállítása mellett döntöttek.

Az Amtech Kft.-nek két feladatot kellett azonnal megoldania:

o Kijavítani a felmerült hibákat,
o Ismételten migrálni a már korábban migrált adatokat.

A fentebbi feladatok elvégzését követően ismételten elindíthatóvá vált a pilotüzem, amely ezúttal sikeresnek bizonyult. Természetesen az ismételt pilotüzem során is előjöttek hibák, de ezek nem voltak a hétköznapi munkát akadályozó, a rendszer használhatóságát alapvetően megkérdőjelező problémák (tehát a felmerült hibák legalább súlyosságukat tekintve nem haladták meg az incidens súlyossági határértéket).

Cégműszerfal

A Kerko Zrt. vezetőségének kérése alapján csak a tesztelést követően került megvalósításra utolsó – és egyben legértékesebb – fázis, az új rendszerre ültetett cégműszerfal funkciócsoport lefejlesztése. A cégműszerfal lehetővé teszi:

o A működés folyamatos monitorozását
o A változások nyomonkövetését
o Statisztikák összeállítását
o Riasztások/figyelmeztetések létrehozását

A funkció keretében összesen 18 db generálható kimutatás, lista, és jelentés lefejlesztésére került sor. Ezek mind rugalmasak, átalakíthatóak és persze szűrés/keresés is értelmezve van minden mezőre.

A bevezetésre került vállalatirányítási rendszer paraméterei

A Kerko Zrt.-nél bevezetésre került vállalatirányítási rendszer paraméterei az alábbiak:

o Alkalmazás típusa: asztali rendszer,
o Operációs rendszer: Windows,
o Fejlesztői környezet:
o Rendszerszoftver: Delphi7,
o Adatbázis környezet: Oracle 10g,
o Forráskód: 138.000 sor,
o Dokumentáció: igényspecifikáció, rendszer specifikáció, adatbázisterv, kézikönyv, 12 db tematikus súgó, és 278 db. kisebb-nagyobb (elfogadott) „change request”,
o Géppark: 40 db. számítógép és 2 db. szerver,
o Összeköttetés: távoli asztali kapcsolat,
o Projekt team:

1 fő projektmanager (vezető fejlesztő),
– 1 fő tesztelő,
– 3 fő fejlesztő (2 kliens oldali, 1 alkalmazás oldali),

o Az alaprendszer bevezetésideje: 1 év és 6 hónap,
o A bevezetés teljes ideje: 2 év és 1 hónap (az összes apró fejlesztéssel együtt).
o Eltérés az eredeti keretekhez képest:

Költség: +5%-on belül
– Idő ráfordítás: kb +40%

A bevezetett vállalatirányítási rendszer SWOT analízise

SWOT – Erősségek

Bár a megrendelő Kerko Zrt. rövidebb bevezetési időre számított, összességében elfogadta ennek tényét, tekintve, hogy a bevezetett ERP rendszer maximálisan illeszkedik a Kerko Zrt. munkafolyamataihoz,  és   mivel   naprakész   alkalmazott   technológiával  készült,   ezért   a rendszer továbbfejlesztése is könnyedén megoldható, tehát nem kell ismételten egy teljesen új vállalatirányítási rendszert bevezetniük.

További – megrendelő oldali – visszajelzés, hogy az ERP előtti rendszerrel lassabb volt a munkavégzés. Az előző ERP kevésbé volt áttekinthető, és nem is fedett le minden munkafolyamatot, ezért többet kellett „nyomozni” az adatok, illetőleg az aktuális munkafolyamatok pillanatnyi státusza/állapota után.
A hatékonyabb, és gyorsabb munkavégzés miatt a Kerko Zrt. bevételei is növekedtek, amely növekményt egyértelműen az új ERP pozitív hatásának értékelt a megrendelő.

SWOT – Gyengeségek

A könyvelési modul alaprendszerbeli hiánya visszavezethető a megrendelő alaprendszerrel szemben támasztott kívánalmaira. A bevezetést követően ennek hiánya, egyúttal szükségessége rövid időn belül jelentkezett, és így pótlólagosan lefejlesztésre került.

A bevezetéskor megállapított és elfogadott hardware kapacitás a rendszer funkcionalitás bővítésének, vagy a Kerko Zrt. további növekedésének a korlátjává válhat.

SWOT – Lehetőségek

A bevezetett ERP folyamatos „ötletgyárként” szolgál a Kerko Zrt.-nek. A bevezetés óta eltelt öt évben számtalan új funkcióval bővült a rendszer. A bővítések közé tartozik például egy komplett webáruház, amely természetesen teljes mértékben integrálva van az alap ERP rendszerhez, tehát a webáruház-on keresztüli vásárlók, termékek, árak, és kedvezmények, készletek, rendelések elérhetőek, és nyomon követhetőek az ERP-ben is.

SWOT – Veszélyek

A rendszer bevezetése a tervezetthez képest végül jelentősen elhúzódott. Ez az elhúzódás valós ismétlődő veszélyként jelenhet meg a rendszer esetleges továbbfejlesztése esetében. Ennek elkerülése érdekében az alaprendszer fejlesztésekor tapasztalt időbeli elcsúszás mögöttes okainak feltárása indokolt.

A rendszer fejlesztése és bevezetése során tapasztalt nehézségek

A Kerko Zrt. számára fejlesztett egyedi vállalatirányítási rendszer fejlesztése és bevezetése során tapasztalt nehézségeket az alábbiakban lehet összefoglalni:

Megrendelő oldali projektmanager hiánya – mindkét fél részéről szükséges egy-egy kulcsfelhasználó,  aki  mindent  ért,  mindent  tud,  mindig  jelen  van  és  képviseli  a projekt,  illetve   a   megrendelő  érdekeit.   A   megrendelő  részéről  később  került kijelölésre (egyéb elfoglaltságai miatt), ezért eleinte lassabb (nehezebb) volt az előrehaladás. Ennek ténye – a projekt sikeressége szempontjából – időveszteségként jelentkezett.

Megrendelő oldali szakértők szakmai álláspontjának eltérése a vezetőség céljaitól – a megvalósítás menetében volt rá precedens, hogy az adott terület képviselője – a vezetőséggel szemben – egy adott folyamatot másképp gondolt „lekezelni”. Ebben az esetben   az   Amtech   Kft.   csak   passzív   szemlélője   volt   a   vitának,   konstruktív hozzászólási (beleszólási) joga projektben nem volt.

Ezen a ponton érdemes kiemelni, hogy – a megfogalmazott célokkal némileg szembemenve – előfordult, hogy az adott terület képviselője elfogadott bizonyos alternatív megoldásokat, vagy hozzájárult iparági szabványok alkalmazásához (a felmerült esetek körülbelül 20%-ban történt ilyen). A maradék 80%-ban viszont tényleg jól kiforrott és meghatározott gondolatok mentén történt az előrehaladás.

A   migráció   folyamatát   meg   kellett   ismételni   az   első   sikertelen   pilot   üzem következtében. A migráció sikerességéhez végül nagymértékben hozzájárult, hogy segítséget nyújtott hozzá a kiváltandó rendszer fejlesztője.

A külső tesztelés elvégzése gyakran nehézséget okozott, mivel – látszólag joggal – többször felmerült a megrendelő oldaláról azon megállapítás, hogy „ez a rész önmagában  még  nem  használható  élesben,  miért  kell  tesztelni”.  (Ezen megfogalmazott kritika alapja, hogy az alkalmazottak nem ismerhették a fejlesztési módszertani sajátosságokat.) A külső tesztelés kapcsán felmerült kritikákat később az adott elkészült modulok részben „éles” adatokkal történő feltöltésével lehetett ellensúlyozni.

Valójában a felhasználók így sem látták értelmét ennek a tevékenységnek, de végső soron nagyobb „affinitással” végeztél el az előírt minimális teszteket, ha általuk is ismert – értelmezhető – adatokat látnak, és azzal dolgozhatnak.

Alábecsült szállítói erőforrások – az Amtech Kft. oldalról jelentős hibának bizonyult, hogy az erőforrásigény megbecsülése során kisebb létszámú csapat lett nevesítve a projektre, mint azt a munka mérete eredetileg indokolta volna. Hozzávetőlegesen a projekt felénél még egy kolléga került a projektbe bevonásra. Ezzel a probléma megoldásra került, még ha a szállító oldali megtérülést némileg befolyásolta is.

Készítette: Amtech Rendszerház Kft.