4 minute read

A fejlesztői csapatok digitalizációs kihívásai

Napjainkban a fejlesztői részlegek zöme papírmentes, szinte minden adat elektronikusan kerül feldolgozásra. De valóban digitalizációnak nevezhetjük, ha a rajztábla helyett CAD-rendszerben végezzük a fejlesztést? Valóban ennyi is elegendő lenne a hatékony munkavégzéshez? Az elmúlt időszak részben visszajelzést adott erre a kérdésre, mert csak azok a vállalkozások képesek fenntartani távolról is a folyamatos munkavégzést, ahol nem csupán az eszközök, de a folyamatok és így a mérnökök is képesek kezelni a digitalizáció kihívásait.

Békeidőben is számos kihívást kell legyőzni ahhoz, hogy jó hatásfokkal működjön egy fejlesztési csapat. Ezért sem szerencsés, hogy így minden átmenet nélkül kellett átállni a távmunkára. Ezen azonban változtatni már nem tudunk, és hamis illúzió lenne abban bízni, hogy a régi szép idők visszatérnek. A hirtelen jött változásnak köszönhetően új nézőpontból tekinthetünk rá a tevékenységünkre. Ez a helyzet rámutat ugyanis azokra a hiányosságokra, fejlesztendő területekre, amelyekkel a korábbi működésünk tökéletesíthetjük.

Advertisement

Első kihívás: a munkamódszerek, folyamatok

Általában a szervezeti berendezkedések siló rendszerűek. Egy ilyen környezetben a mechanikai, elektromos és szoftver csapatok külön-külön sok esetben egymástól függetlenül elkészítik a terveiket és meg kell várniuk, amíg elkészül a fizikai prototípus, hogy a saját munkájukat és így az egész termék működését tesztelhessék. Ha nem működik – és elsőre nem szokott – a prototípust szétszerelik, kivizsgálják és megkeresik a probléma gyökér okát. Ezután

a mérnökök visszatérnek a saját tervező eszközükhöz, módosítják a terveket és újraépítik a prototípust. Ezt a folyamatot újra és újra megismétlik, amíg a termék a rendeltetésszerűen működik. Ebbe az iterációs folyamatba bekapcsolódnak a beszállítók is. Viszont napjainkban minden feladatot távolról kell elvégezni. A vevővel sem lehet találkozni és megmutatni neki a terméket működés közben, emiatt a termékek piacra kerülése is jelentősen csúszik. Ezért hagyományos munkamódszerekkel gyakorlatilag nem tarthatók a határidők, nem lehetünk versenyképesek.

Milyen jó lenne, ha az amúgy is rendelkezésre álló CAD modellekre támaszkodva elkészülhetne a termékünk digitális ikertestvére (Digital Twin), amelyen a virtuális térben tesztelhetnénk a működést.

Második kihívás: az eszközök

Sokan csak az eszközökre koncentrálnak anélkül, hogy rögzítésre került volna miért, és milyen célt kell szolgálnia az adott eszköznek. De

a célok rögzítéséhez egyértelmű és tiszta folyamatokra, munkamódszerekre van szükség. Napjainkban megfigyelhető egy másik trend is, amikor a mérnökök a magánéletükben használt felhő alkalmazások megbízhatóságát és egyszerűségét keresik. Ezeknél az alkalmazásoknál fel sem merül az a kérdés, hogy telepíteni és testreszabni kell-e egy speciális szoftvert, vagy milyen szerverre van szükség és honnan kerül beszerzésre a szükséges tárterületet?

Milyen jó lenne, ha a munkánk során használt eszközök is intuitív módon tanulhatók lennének, nem kellene időt pazarolni a beüzemelésre és invesztálni a hardver eszközökbe. A szoftverfrissítések pedig automatikusan, munkaidőn kívül futnának le. De a legnagyobb megváltást az eltérő eszközökben készült fejlesztési adatok egy közös platformon történő, adatvesztés nélküli integrálása jelentené.

Harmadik kihívás: a kommunikáció

Még a legfejlettebb csapatok esetében is jellemző, hogy a szereplők saját jegyzetfüzetükben rögzítik az információkat és megfelelő eszköz híján ez az információ ott is marad, láthatatlanul a többi szereplő számára. A legelterjedtebb eszköz még mindig az email, amiben aztán minden elfér. Sok esetben több feladat és azok kommentje egy komplett email-folyamon keresztül hömpölyög, ahol már a harmadik üzenet után a csapat fele elvesztette a fonalat. Milyen jó lenne, ha lenne egy olyan eszköz, amely támogatja és egyesíti a különböző, magánéletből is ismert egyszerű kommunikációs eszközök előnyeit. Lehetővé tenné az egységes, sztenderd feladatkezelést, információ megosztást és egy közös platformon való munkavégzést.

Negyedik az emberi kihívás: tényező

Csak kevesen tudunk kibújni a bőrünkből és lelkesedni a változásokért, újdonságokért még akkor is, ha azok a mindennapi életünket teszik egyszerűbbé. Egy új rendszer bevezetése vezetői elköteleződés hiányában az esetek több, mint 60%-ban pont emiatt bukik meg, mert az eszközt használók nem kerülnek bevonásra és nem hajlandók elfogadni a változásokat. Nem ritka, de a távmunka megjelenésével egyre több esetben megfigyelhető, hogy a vezetők kérésére a dolgozóknak napi, heti riportot kell készíteni arról mivel foglalkoztak munkaidejükben. Milyen jó lenne, ha lenne egy olyan rendszer, amiben minden résztvevő a munkája elvégzéséhez szükséges feladatokat végezné, dokumentálná és erre az adatra támaszkodva nyerhetnék ki a vállalat további szereplői – a vezetők is – a számukra szükséges adatokat, információkat.

Egy egy lehetséges megoldás

Amikor egy csapat kiértékel egy fizikai prototípust akkor nem beszélgetnek verziókról, fájlokról. Ha kezükbe vesznek egy terméket, alkatrészt akkor az önmagában hordozza a rá jellemző minden információt. Azok a rendszerek, amelyek modell alapú megközelítést alkalmaznak ugyanezt az elvet használják ki. (https://3dexperience.cadterv.hu/horizont/)

A cloud rendszer testreszabás nélkül használható és minden szereplő bárhonnan, bármilyen eszközről elérheti. A különböző eszközökben fejlesztett termékek 3D-s modelljeit egy egy közös platformon érik el. A platform biztosította virtuális környezetben felépíthető egy digitális prototípus (Digital Twin). A virtuális térben szimulálható a termék működése. A fejlesztők, beszállítók, partnerek kommunikációja szintén egységesen a platformon történik. Nem kell külön beszámolókat készíteni, mert az adatbázisból kinyert információk alapján minden szereplő megtalálja, amit keres. Nem utolsó sorban fizikai érintkezés nélkül akár minden szereplő távolról végezheti a munkáját és vihető végig egy fejlesztési folyamat.

Nadj István CAD-Terv Mérnöki Kft

This article is from: