Motivációk

Először nézzük meg, hogy mi motiválta a projekt létrejöttét, milyen ötletek merültek fel, és milyen kockázati tényezőkre érdemes figyelni a projekt tervezése során.

Egy probléma, egy beszélgetés, legalább két ötlet

Fontos a kapcsolattartás: csak akkor merülhetnek fel új ötletek, ha beszélgetünk az ügyféllel. Ez a projekt is innen indult el: egy telefonbeszélgetés során felmerült az, hogy "milyen jó lenne, ha képesek lennénk arra ..." - kialakul tehát egy igény a partnerben. Nem kell rögtön világmegváltó ötletekre gondolni, mert - sajnos - digitalizációs és integrációs megoldásokat tekintve a magyar ipar nem feltétlenül jár még az élen.

De térjünk vissza a beszélgetésre és a problémákra: a felmerülő igény itt hozott is magával két ötletet: "milyen jó lenne, ha a karbantartóknál rögtön kéznél lenne az a leírás, ami az elromlott berendezéshez tartozik" (1. ötlet). Egy nagy alapterületű vállalatnál ezzel időt és pénzt lehet megspórolni, hiszen nem kell ide-oda rohangálnia a karbantartónak, ha meg szeretne oldani valamilyen problémát és nincs a fejében az összes berendezés mindegyik leírása. Mennyivel egyszerűbb lenne, ha csak lenne a berendezésen egy QR kód (ez még papíron vagy matricán), amit bescannelve (QR kód olvasó már alapból van az okostelefonokban) a karbantartó rögtön megkapja a céges telefonján (táblagépén) azt a dokumentációt, ami alapján rögtön releváns információhoz juthat a berendezésről. És ennyi... elindult a projekttervezés! Az ember pedig olyan, hogy ha jön egy ilyen ötlet, akkor nem áll meg, hanem tovább fűzi, és azt gondolja, hogy "milyen jó lenne, ha nem Viber-en (vagy bármilyen egyéb chatelő programon) keresztül küldené el a gépkezelő operátor a problémáról a jelentést (képet)" (2. ötlet), hanem valamilyen jobban kezelhető, menedzselhető megoldáson keresztül, amit esetleg a későbbiekben még nyomon is lehet követni (3. ötlet: út egy többfunkciós, komplex rendszer felé...).

Ez már egy jó kiindulási helyzet, mert a potenciális partner általában nem tudja, hogy mit akar ("ha mégis azt állítja, hogy tudja mit akar, akkor még inkább nem tudja" - Fekete Attila, fws.hu), úgyhogy érdemes felkötni a felkötnivalót!

Kockázati tényezők - avagy min bukhat el a projekt...?

1. Sose becsüljük alá a dolgozók ellenállását az új rendszerekkel, szoftverekkel szemben! Ezen tud a legtöbb projekt elbukni, úgyhogy érdemes olyan rendszert kialakítani, amelynek használata nem okoz nehézséget egyetlen szereplőnek sem, például úgy, hogy letisztult, egyszerű, átlátható kezelőfelületet biztosítunk az alkalmazáshoz és mindig jelezzük a felhasználónak, hogy mi történt. Egy gyárban nem annyira fontos a csillogó-villogó kinézet, mivel az inkább csak megzavarná a felhasználóinkat.
   
2. Mindig gondolkodjunk rendszerekben! Valószínűleg nem ez lesz a legelső alkalmazás a vállalatnál, amely támogat valamilyen folyamatot (jelen esetben a karbantartás menedzselését). Integráljuk a megoldásunkat a már meglévő rendszerekhez, mert senki sem akar többször dolgozni, többször megvalósítani ugyanazt. Ennek van még egy olyan vetülete is, hogy a vállalat nem szeretne új hardveres vagy szoftveres eszközöket vásárolni, hanem "főzzünk" abból költséghatékonyan, amink van vagy ingyen elérhető.
3. Már a legelején vizsgáljuk meg, hogy a többnyelvűsítés (lokalizáció) mennyire fontos a projekt során - ha egy magyar gyárban vagyunk és azt szeretnénk, hogy az alkalmazottak "hozzá tudjanak nyúlni" (használni tudják) az elkészülő alkalmazást, akkor magyar alkalmazást kell készíteni. De végezzük ezt el úgy, hogy mellette elsőként az angol verziót csináljuk meg, csak azután a magyart, hátha a készülő alkalmazással nagyobb piacokra is ki lehet majd lépni, vagy ha egy multinacionális vállalatról van szó, akkor más országbeli leányvállalatoknál is alkalmazni lehessen majd a megoldásunkat.
4. A webes alkalmazás azért is kiváló megoldás minderre, mert nem kell telepíteni hozzá semmi extrát, csak egy okos eszközre (telefon, táblagép, laptop stb.) és a böngészőjére van szükség ahhoz, hogy használni lehessen majd. Ha asztali vagy mobil alkalmazást készítenénk, akkor azt telepíteni kellene több helyen és minden olyan eszközön karbantartani (frissíteni), amin használatban van az alkalmazás. Egy gyárban, ahol magas a munkaerő áramlás (fluktuáció) szintje elég nagy terhet jelentene mindennek menedzselése. Sokkal egyszerűbb, ha "csak" egy helyen, a webes alkalmazást futtató környezetben kell odafigyelni minderre.
   
5. Biztonság szempontjából az alkalmazásnak "házon belül" kell működnie, ezért a "deployment" (kitelepítési) folyamatot majd a vállalat eszközein (szerverein) kell lefuttatni úgy, hogy a vezeték nélküli hálózati elérést megfelelően állítjuk be.
6. ... biztos vagyok benne, hogy vannak még olyan tényezők, amire most hirtelen nem is gondoltam, de ha szívesen megosztanád velem, akkor írd meg a te véleményedet erről!

A döntéshozók, még ha ismerik is a fejlesztőt, kissé szkeptikusan állnak az új projektek, ötletek, innovációs megoldások irányába. Érdemes emiatt nem egy óriási rendszer megvalósításával kezdeni - még ha végig a távolban a szemünk előtt lebeg a legfőbb cél, hanem "csak" arra a néhány problémára adjunk hatékony megoldást, amelyek a jelenlegi, napi szintű problémáikban segíteni tudják őket.

Követelmények és funkciók leírása, elemzése

A követelmények tehát egy olyan alaprendszerről kell szóljanak, amelyek főleg a fenti két ötlethez kapcsolódnak. Alaprendszernek hívom, mert bár még nem tud majd mindent, de egy nagyon jó alapot tud képezni ahhoz, hogy a későbbiekben egy teljes értékű, akár "dobozos terméknek" is tekinthető megoldásként értékesítsük.

Az alaprendszer nem rendelkezik olyan nyilvános felülettel, amely felhasználói azonosítás nélkül lehetőséget biztosítana a rendszerhez való bármiféle hozzáférésre, így bármilyen funkció eléréséhez legelőször azonosítania kell magát a felhasználónak. Az azonosításhoz érdemes olyan paramétereket használni felhasználónévhez / e-mail címhez, amely mindenkinek van már a cégnél, nem kell majd egy újat megtanulnia senkinek sem, aki használni szeretné a rendszert. A felhasználói regisztrációt az adminisztrátorok végezhetik csak el, esetleg megkönnyítve a folyamatot egy csoportos táblázat importálási lehetőséggel. A kezdeti jelszót pedig érdemes olyanra választani mindenkinél, amire szintén igaz, hogy mindenki ismeri a sajátját, amit aztán majd esetleg az első belépés után meg kell változtatnia. Egy ilyen felhasználói hitelesítési kombináció lehet a munkahelyi e-mail cím és a törzsszám (vagy belépőkártya száma), amelyet mindenki tud magáról a cégnél és talán jó eséllyel a másik munkatárs (törzsszámát vagy kártyaszámát) nem ismerik.

Az elvárt követelményeket funkcionalitások megvalósításával teljesítsük. A funkcionalitásokat pedig már a projekt legelején érdemes aszerint megszervezni, hogy majd ki (melyik felhasználó) milyen csoportba (szerepkörbe) tartozik, és ők mit tehetnek meg a webes alkalmazáson belül.

Felhasználói csoportok, szerepkörök

Azt már említettem, hogy lesznek adminisztrátorok a rendszerben, akik a felhasználókezelést, dokumentumkezelést és a hibabejelentő munkalapokat is tudják menedzselni. A következő csoport a karbantartóké, akik már nem jogosultak arra, hogy a felhasználókat menedzseljék, viszont ők tudnak a berendezéseknél leíró dokumentumokat kezelni (és akár saját maguk is tudnak létrehozni hibabejelentő lapot). A gépkezelők legfontosabb feladata és lehetősége, hogy hibabejelentő dokumentumot tudnak generálni a karbantartóknak. Az alábbiakban részletesebben is kifejtem, hogy az egyes felhasználói csoportok szereplői milyen funkcionalitásokra lesznek képesek a rendszerben.

1. Adminisztrátor szerepkör szerinti funkcionalitások

1. Szerepkör alapú jogosultságok (karbantartó, gépkezelő) kezelése – kinek mit szabad és mire van lehetősége a rendszerben.
2. Felhasználók kezelése (létrehozás, szerkesztés, törlés, listázás, keresés, rendezés, csoportosítás).
3. A berendezéseket típusok szerint (termelő gép, elszívó, kompresszor stb.) csoportokba szervezi, így egységesebben lehet a berendezéseket kezelni.
4. Berendezések listázása, újak létrehozása, meglévők szerkesztése vagy törlése. Ezeken kívül tudjon keresni köztük, rendezni és szűrni őket.
5. A kiválasztott berendezéshez és a karbantartási dokumentumaihoz QR kóddal tudjon generálni elérési felületet, és a QR kódot rögtön ki is tudja nyomtatni.
6. A berendezés karbantartási dokumentumait szintén képes legyen menedzselni (új létrehozása, meglévő szerkesztése vagy törlése, keresés, rendezés, szűrés).
   

2. Karbantartó szerepkör szerinti funkcionalitások

1. A berendezéssel kapcsolatos dokumentumokhoz hozzáférhet és menedzselni is tudja azokat.
2. Alkalmazáson keresztüli hibabejelentés esetén értesítést kapnak a csoportba tartozó felhasználók az új hibákról.
   
3. Berendezéssel kapcsolatos probléma és a hibánál való személyes megjelenés esetén: az üzemterületeken lévő berendezéseken elhelyezett QR kóddal (annak beolvasásával) eljuttatjuk a karbantartót egy olyan oldalra, ahol a berendezéssel kapcsolatos problémákat tudja bejelenteni egy űrlap segítségével - kvázi önmagának vagy valamelyik kollégájának tud így feladatot generálni. Ezáltal a későbbiekben majd nyomon követhető marad a hiba és megjavításának "életciklusa".
   

3. Gépkezelő szerepkör szerinti funkcionalitások

1. Az üzemterületeken lévő berendezéseken QR kóddal, illetve annak beolvasásával eljuttatjuk a gépkezelőt egy olyan oldalra, ahol a berendezéssel kapcsolatos problémákat tudja bejelenteni egy űrlap segítségével.
2. A berendezéssel kapcsolatos dokumentumokhoz inkább ne biztosítsunk nekik hozzáférést, nehogy ők maguk akarják kijavítani a berendezés problémáját és ezáltal esetleg még nagyobb problémát hoznának létre.

A funkcionalitások többsége CRUD (Create-Read-Update-Delete) alapú, de vannak köztük azért komplexebb problémák is. Továbbá magának a jogosultsági rendszernek és az adattábláknak (kapcsolataik kezelésének) a kialakítása jelenthet nagyobb időigényű feladatokat.

Technikai specifikáció

Az alábbiakban összefoglalom még azokat az elvárásokat, főleg technológia és alkalmazásfejlesztés oldaláról, amelyeknek meg kell felelni a megvalósítás során.

Általános technikai elvárások specifikálása

1. Az alkalmazás kinézete egyszerű, letisztult, könnyen és kényelmesen használható lesz, a felhasználói igényeknek megfelelően.
2. Az alkalmazás úgynevezett reszponzív kinézetet vesz fel, azaz idomul (alkalmazkodik) ahhoz az eszközhöz, amelyről éppen használják: tehát nagy monitoron, táblagépen vagy telefonon is megfelelően használható lesz.
3. Belső hálózaton fut a webes alkalmazás, amely egy adatbázisban tárolja el az adatokat. Bár a felhős megoldások híve vagyok, jelen helyzetben most erre (még?) nincsen szükség.
4. A webes alkalmazáshoz a vállalat teljes területén biztosítani kell a hozzáférést wifi hálózatok, átjárók stb. megfelelő beállításával.
5. Csak olyan szoftveres eszközöket használunk, amelyek ingyenesek vagy már a vállalat rendelkezésére állnak (például Microsoft SQL Server).
6. Az alkalmazás elkészítése korszerű technológiákkal (Laravel v10, Filament v3, Chart.js) történik majd meg: legfrissebb fejlesztőkörnyezet, szerver megoldások, programcsomagok stb.
   

Karbantartás menedzsment alkalmazás funkcionális előírásai

1. A felhasználók csak a jogosultságaiknak megfelelő funkcionalitásokat érhetik el, illetve egy-egy funkción belül is történhetnek megszorítások bizonyos alfunkciók elérésére.
2. Az adatbázis tábláinak összekapcsolásával az alkalmazásban kényelmesen lehessen majd kezelni az összetartozó elemeket. Például egy berendezés szerkesztésekor rögtön hozzá lehessen majd adni a karbantartási dokumentumait is, ne kelljen átnavigálni a dokumentációs felületre és vissza.
   
3. Az alkalmazás hibabejelentési űrlapján a legtöbb esetben nem kell írni, hanem előre definiálunk választási lehetőségeket a hibák körülírásához, így tudjuk majd biztosítani, hogy ne nagyon tudja elrontani a gépkezelő, amikor a hibáról jelent.
4. A hibabejelentési űrlaphoz szükség van egy vagy több már korábban használt munkalapra, amelyek alapján elkészíthető a webes alkalmazás ezen részének megvalósítása.
5. A hibákról lehet majd fotózott képeket csatolni az űrlaphoz.
   

Továbbfejlesztés

Még el sem készült az alaprendszer, de már megvannak a további ötletek a fejlődésre, fejlesztésekre!

1. A berendezéseknél kérdés, hogy milyen szintig menjünk majd le a berendezés összetevőinek, alkatrészeinek hierarchiájában (például egy nagy gépsornak számos alkatrészével lehet probléma, amelyeket mind külön-külön lehetne nyomon követni a rendszerrel). Ezért a berendezések strukturált (fa-szerkezetű) nyilvántartására szükség lehet a későbbiekben.
2. Hibák nyomon követése a megoldásig: a későbbiekben a probléma megoldásának nyomon követését is biztosíthatjuk a rendszeren keresztül. Ebből az is látható lesz majd, hogy valahol elakadt-e a karbantartási (vagy például alkatrész beszerzési) folyamat.
3. A korábbi (rendszerünk bevezetése előtti papír alapú vagy digitálisan lefényképezett) munkalapokat felvinni a rendszerbe, hogy kialakulhasson egy-egy berendezés teljes karbantartási története. Plusz munkaerőt igényel, de ehhez akár hallgatói segítség is igénybe vehető!
   
4. Berendezések életciklusának menedzselése: automatikus karbantartási ciklusok nyomon követése (például dátum, üzemidő vagy legyártott mennyiség alapján): melyik gépet mikor kell karbantartani akkor is, ha nem érkezett róla hibajelentés.
5. Statisztikák a karbantartásokra vonatkozó: például: melyik gép romlott el a legtöbbször? Mennyi volt az átlagos karbantartási idő? Átlagosan milyen gyorsan történt meg a reagálás egy problémára? Illetve ehhez hasonló további kérdésekre, amelyek kulcsfontosságú mutatószámként jelenhetnek meg a rendszerben.
6. Az alkalmazást a jövőben érdemes lesz összekötni a vállalatnál már működő egyéb rendszerekkel is (vállalatirányítási rendszer, energiagazdálkodási rendszer stb.).
7. Ha egy berendezésnek számos leírása lenne, akkor érdemes az OpenAI integrálásának lehetőségeit áttekinteni a rendszer fejlesztésekor, mivel ezzel a dokumentumok tartalmában is gyorsan lehet keresni.
   

Természetesen, további javaslatok is felmerülhetnek még a fejlesztés során. Sőt, nem titkolt célom, hogy ha majd az idő előrehaladtával egyre több adatot gyűjtünk ezzel a rendszerrel, akkor kutatásaim során is fel tudjam őket használni, ami által a cég is optimálisabb működést lesz majd képes elérni. De ha neked van egy jó ötleted, hogy mit lehetne még belevinni a rendszerbe, oszd meg velem!

Dolgozzunk együtt: egyéni oktatás, mentorálás, fejlesztés, tanácsadás

Ha egyéni oktatás, mentorálás, vagy fejlesztési projekt kapcsán szeretnél segítséget kérni tőlem, esetleg együttműködni velem, akkor keress meg a weboldalamon található elérhetőségeken keresztül!