Informatikai támogatás nélkül cégszerű működés ma már szinte elképzelhetetlen, de most ne foglalkozzunk azokkal, akik számára az IT eszközbázis kimerül az okostelefon, vagy az e-mail használatnál, fókuszáljunk az olyan esetekre, amikor több tíz, vagy inkább több százmilliós (esetleg sokmilliárdos) cégeknél merül fel szoftver beszerzési, vagy tágabb értelmezéssel informatikai rendszer beszerzési és/vagy fejlesztési igény. Például -csak hogy témánál maradjunk- tegyük fel, egy élelmiszer feldolgozó cég szeretne olyan megoldást, amivel gyártmányonként (azon belül akár sarzsonként) lekövetheti,
- adott termékébe beépített alapanyagok (beszéljünk zöldségfélékről) melyik beszállítója melyik hektárján termett, milyen vetőmagból, és a betakarításig mikor és milyen növényvédelmi eljárásokat alkalmaztak,
- a beszállított alapanyag (legyen az borsó, karfiol, vagy bármi) milyen minősítést kapott nyersanyagként
- a feldolgozás során milyen mért, vagy érzékszervi minősítéseket kapott, mielőtt félkész, vagy készárú lett belőle
- összetett termék (pl. egy hat komponenses zöldségkeverék) egyes elemei melyik félkész termékekből származnak (nyilván sarzs szintű pontossággal)
Mindezek természetesen legyenek visszakereshetők akkor is, ha már az árut egy vevő hozza vissza (mert problémája van vele).
Nem bontom ki mélyebben a lehetséges funkcionalitást, ezekből az egyszerű példákból (részfeladatokból) is érezhető, a feladat megoldására alkalmas informatikai rendszert nem lehet pár hónap alatt „összedobni”, ráadásul a szoftver kérdések mellet komoly IT infrastruktúra meglétét igényelheti, ami képes együtt dolgozni mérlegekkel mérő és gyártó berendezésekkel, távérzékelőkkel, stb.
Nézzük hát meg, mire kell figyelni, ha egy IT rendszer bevezetését tűztük ki célul?
Tudjuk-e pontosan, mit akarunk, és ennek a megoldására ki lesz igazán alkalmas?
Nagy cégeknél ennek a megfogalmazása az adott terület szakmailag felkészült munkatársainak a feladata, de még ők is meg szokták „kérdezni” a lehetséges szállítóikat, milyen megoldásokat kínálnak (az elsőre még nem tűpontosan meghatározott) igényeikre. Adott esetben az RFI, RFP és RFQ fogalmak mentén érdemes tájékozódni, de a „nagyok” ezt többnyire tudják, a „kicsik” meg igyekeznek „nem túlbonyolítani”, nem húzzák az időt hosszadalmas, ráadásul pénzbe kerülő előkészületekkel, hiszen képesek gyors döntésekre, főleg, ha a közvetlen ismerősi körben látszik alkalmas szállító, aki majd olcsón, ráadásul gyorsan megoldja majd a feladatot. Ezen a ponton -bár talán célszoftverről beszélünk, mégis elérkeztünk az ERP bevezetések problémájához, hiszen
- hiába választunk jó megoldást, ha nem tudjuk, mit akarunk, vagy alkalmatlan bevezetőt választottunk
- ha sikerült jó szoftvert találni, a bevezető is ért ahhoz, amit csinál, újabb csapdák várhatnak ránk, és bármelyiktől bukhat a projekt, és a bukás nem csak a totális bukás, hanem az is, ha félmegoldások születnek. Pár példa;
- Nincs meg a vevő oldali projekt szervezet, vagy a szervezet tagjainak a cég nem biztosítja a szükséges időt a bevezetéshez
- Van ugyan belsős projektmenedzser, de az adott szakterület nem az ő világa. A példánknál maradva legyen szó élelmiszeripari minőségbiztosításról és termék beépülés követésről, a helyi IT-t egyszemélyben képviselő informatika vezető eddigi feladatköre (ezzel együtt tudása is) jellemzően gépbeszerzés, üzemeltetéstámogatás, hálózatfelügyelet, vírusvédelem és adatmentés fókuszúak, ami miatt ezen a másik területen ő nem tud igazán hatékony lenni (ami nem! az ő hibája. Fogtechnikus sem végez szemműtétet, ugye, és a szemész sem szívspecialista.)
- Rossz a költségvetés, nincs, vagy túl kevés pénz van a bevezetésre, így az -esetleg drágán megvásárolt- eszközből a lehetséges tudásának csak a töredékét sikerül kihozni.
- Az esetleges gyenge vezetői elkötelezettséget kihasználva győz a változásellenes destruktívitás.
Milyen általános tanács adható ezügyben?
Ha lehet, a kiválasztáshoz, illetve a bevezetés támogatásához keressünk az adott szakterületet jól ismerő, a potenciális termékszállítóktól független projektmenedzsert, aki vevő oldali tanácsadóként képes az érdekeinket képviselni;
- segít olyan késztermék választásával, ami alapállapotában is a lehető legtöbbet tudja nyújtani, illetve viszonylag olcsón és időtállóan- bővíthető.
- támogat a kevésbé alkalmas bevezető cégek kiszűrésében.
- egyedi fejlesztési igény esetén képes a jelöltek közül kiszűrni a valós értékeket képviselő cégeket kiválasztani. (Itt a korábbi referenciák értékelése mellett a szakmaiság, szakmai, gazdasági és HR stabilitás no meg a cégkultúra is fontosak.
1. Teljesítmény
A rendszer használata során nem elég néhány tucat vagy pár ezer user kiszolgálására felkészülni. Ha a céljaink teljesülnek (márpedig erre készülünk), több tíz- sőt százezer user kiszolgálására kell képesnek lennie a megoldásnak. Első körben ugyan viszonylag egyszerű lekérdezések kielégítése a cél, de később már összetett lekérdezések megválaszolása is tervezendő. Ehhez robosztus, a gyakorlatban is már bizonyított informatikai technológia megléte szükséges. A Seacon ezzel igazoltan rendelkezik, hiszen sokkal bonyolultabb megoldásokban sok ezer user felhő alapú kiszolgálását végzi napi szinten (évek óta) reklamáció mentesen, olyan cégek számára, mint pl. a DRV, Swietelsky, vagy Eon. A Seacon képes akár olyan üzemeltetési környezetet is biztosítani, ahol az adatvesztés nem lehet nagyobb néhány másodpercnyinél, és erre több éves referenciával rendelkezik. A teljesítmény és ár természetesen szoros összefüggésben van, viszont az igényelt teljesítmény szint technikailag -a gyakorlatban már validált módon- biztosítható.
2. Információ biztonság és adatvédelem
A tárolt (kezelt) adatok védelme kiemelt jelentőségű. Tudjuk, az adatokkal való visszaélések felderítése jelenleg ~70% körül nem a tudatos védekezés, hanem a véletlenen alapuló feltárás eredményei. A Seacon az -Iso 27.001 tanúsítvánnyal is rendelkező- adatvédelem specialistája, akinek az alkalmazásait multinacionális cégek folyamatosan ellenőrzik, többek között etikus hackelési módszerekkel. E mellett GDPR megfelelőséget igazolni képes megoldásokat szállít a cég igen jó gyakorlati eredményekkel.
3. Megbízhatóság
Az egyes szoftvermegoldások megbízhatósága számtalan dologtól függ.
- Az első természetesen a jó tervezés. E nélkül a későbbi, megnövekedett teljesítményigény kielégítése komoly problémákat okoz.
- A következő a jól megtervezett rendszer szakszerű megvalósítása, biztosítva a későbbi módosítási lehetőségeket. Ebbe beletartozik az adatbázis tervezés (nem kockás papíron, hanem Case eszközzel, elkülönítve a logikai és a fizikai adatmodell szinteket), az átlátható, és dokumentált kódolás, és persze a lehetőleg kiforrott keretrendszerre alapuló standardizálás. Ide sorolható még a munkacsoportos fejlesztési tevékenységek esetében nélkülözhetetlen (a forráskódok megbízható tárolására szolgáló verziókezelő megoldás használata, valamint a dokumentált projektelőrehaladást, és projekt irányítást támogató projekt menedzsment eszköz, és az ehhez kapcsolódó projekt menedzsment módszertan megléte és napi szintű alkalmazása. Seacon napi munkája során mindezeket alkalmazza.
- Egy szoftver soha nincs kész. Ez különösen igaz egy széles felhasználói körnek szánt, funkcionalitásában folyamatosan bővíteni kívánt, kezelt adatait tekintve is folyamatosan szélesebb alapokra helyezendő megoldás esetében. Az természetesen megengedhetetlen, hogy a bármelyik területet érintő módosítások, bővítések során korábban már meglévő funkciók -a kibocsátott újabb és újabb verziókban- „meghibásodjanak”. Ennek az elkerülése érdekében -az új funkciók tesztelésén túl- brutálisan sok, a teljes rendszer egészére vonatkozó ismételt és ismételt tesztekre van szükség. Ennek a „kézi erővel” történő elvégzése irracionálisan költséges, és időigényes, ezért az egyetlen racionális megoldás a gépi (szoftver robotok alkalmazásával megvalósított) tesztelés. A Seacon a dobozos (sok ügyfél folyamatosan bővülő igényeinek a kiszolgálására képes) megoldásait folyamatos gépi tesztelésnek veti alá az új funkciók kézi tesztelése mellett. Ez a módszer a nagytömegű ügyfél folyamatosan fejlődő funkcionalitással való kiszolgálási igénye esetén egyszerűen nélkülözhetetlen.
4. Kockázatok, erősségek
Számtalan ide tartozó dolog van, ezekből csak párat emelünk ki;
- HR kockázat
Rendelkezik-e a szállító a szükséges erőforrásokkal a megvalósítandó feladat kivitelezésére, a későbbi üzemeltetéstámogatási és továbbfejlesztési feladatok ellátására? Itt nagyon fontos szempont, hogy elég sokoldalú tudás szükséges, azaz rendszerszevezői, adatbázis tervezői, kódolási, tesztelői, dokumentátori, gépi tesztelést támogató, valamint konzulensi (ami tanácsadási és „ügyfél ápolási” tudás), és természetesen a projektmenedzseri kompetenciák. Ez egy ilyen méretű projekt esetében 10-20 fős szervezet meglétét igényli, ha a helyettesítési, vagy az esetleges fluktuációs szituációkra is elfogadható megoldást akarunk. Ez természetesen nem jelenti az egész szervezet folyamatos rendelkezésre állását, de az igény szerinti háttértámogatás elengedhetetlen.
A Seacon esetében ezek a kapacitások minden szakterületen rendelkezésre állnak, de ha szükséges, a -Seacon által 2006-ban alapított, jelenleg 60+ céges tagságú- Innoskart digitális klaszter komoly erőforrás hátteret biztosít.
- Szakmai beágyazottság
A Seacon által 2006-ban létrehozott -Innoskart akreditált- klaszter szorosan együttműküdik a Mirbest és az IFood klaszterekkel, így -együtt különösen- erőteljes szakmai kompetenciákat tudnak biztosítani jelen projekt vonatkozásában.
Seacon QSTS nevű megoldása napi szinten használt megoldás a Fevita részéről. A QST jelenleg további cégeknél is bevezetés alatt áll. Az alapmegoldás Seacon tulajdona, a rá épülő applikáció Seacon, Mirbest és Nébih tulajdon lesz.
- Szoftver háttér fejlettsége
Seacon esetében egy kiforrott keretrendszer adja a felhő alapú, QST specifikus szakmai hátteret, a mobil specifikus képességek pedig a nagy sikerű Seafleet rendszerben csiszolódnak évek óta (most éppen a QSTS-ben hasznosulva). Fontos, hogy mindez a GDPR szempontok maximális figyelembevételével történik.
Gyártási folyamatok során a sarzs – mint jól meghatározott termék adag – jelentése fontos gyártási szempontot foglal magában: ezzel lehet azonosítani a termékeket, felismerni az egy időben, azonos körülmények között készült termékeket, termékadagokat. Ez különösen olyan iparágakban jelentős, ahol folyamatos termelésre van szükség: szemléletes példa erre a vegyipar vagy az állattenyésztés.
A sarzs szám elsődleges szerepe, hogy visszakövethetőséget biztosítson – erre pedig két okból van nagy szükség.
Az egyik, hogy a sarzs kulcsfontosságú a minőségszabályozási folyamatokban. Mint ismeretes, ez a fogalom azt a részét jelöli a minőségirányításnak, amely a minőségi követelések teljesülését ellenőrzi. Mindazokat az operatív módszereket és tevékenységeket foglalja magában, amelyek a fentiek teljesítését segítik elő. A sarzs jelölés ezzel átláthatóvá teszi a minőségszabályozás részét képező folyamatokat is (minőségbiztosítás, minőségellenőrzés).
A másik fő oka annak, hogy a sarzs jelentése világszinten gyorsan elterjedt és sztenderddé vált, az nem más, mint hogy esetleges népegészségügyi probléma esetén könnyen megtalálható a baj gyökere.
– BG –
