A címet elolvasva talán az a klasszikus vicc ugorhat be, amikor parasztbácsi az állatkertben áll a zsiráf ketrece előtt, és azt mondja: „Má’ pedig ilyen állat nincs is!”. Az autóipar a legtöbb ember számára egy merev, szabályozásokkal teli iparágat jelent, ahol alapvetően csak kis változások vannak a környezetben. Autóipar alatt most nem a különböző kényelmi és szórakoztató funkciókat ellátó ún. infotainment-rendszerekre gondolok, hanem a komolyságot megkövetelő biztonságkritikus-rendszerekre, mint a fékvezérlés, elektronikus kormányrendszer, menetstabilizátor, etc.

Tíz évvel ezelőtt ez az állítás még igaz is volt. Akkoriban alig volt az autókban pár tíz darab elektronikus vezérlőegység (ECU - Electronic Control Unit), amik ráadásul egyszerűbb hardver és szoftver architektúrával rendelkeztek. A megrendelő autógyárak (OEM – Original Equipment Manufacturer) által adott követelménycsomagok konzisztensek voltak, és minimálisan változtak a fejlesztési idő alatt. A projektek indulása előtt már betonba voltak öntve a szállítási határidők, amiken nem lehetett változtatni. Mindez hangosan kiált egy tradicionális projektmenedzsmentért, és valóban ezt is alkalmazták a beszállító cégek.

Azonban az évek során változás történt mind a beszállítói, mind a megrendelői oldalon. A beszállító cégek azzal szembesültek, hogy a feléjük leadott kezdeti követelmények már nem olyan egységesek és világosak, mint korábban. OEM oldalon folyamatosan fejlődnek az autótípusok, ami miatt nagyon gyakoriak a fejlesztés közbeni új igények, illetve a meglévő igénypontok változtatása. Az új követelményeket már nem lehet lefedni egyszerűbb rendszerekkel, szükség van a bonyolultabb, sokkal komplexebb hardver és szoftver architektúrák, mechanikai rendszerek kialakítására. Ezek kifejlesztése új terület, sok esetben amolyan előfejlesztés jellegű feladat, ami azt eredményezi, hogy nem lehet előre megtervezni a projektet úgy, mint korábban.

Megjelentek új irányzatok is, mint az önvezető autók megalkotása, ami miatt szintén rengeteg új aspektus jött be. Ez pedig az ECU-kat vezérlő szoftver rendszerekre ró extra feladatokat, ami pedig drámai komplexitásnövekedést okoz. Ennek következménye, hogy már nem lehet az alrendszerek közötti kapcsolatokat (interfészeket) hatékonyan előre definiálni, szükség van a menet közbeni folyamatos finomításokra. Szemfüles módon észrevehetjük, hogy az új helyzet elmozdult a prediktív (a projektet előre megtervezik, majd a tervek alapján folyamatosan végrehajtják, végül az elkészült terméket tesztelik) állapotból az iteratív és inkrementális (a projektet lebontják kisebb, ismétlődő fázisokra, amiknek része a tervezés, végrehajtás, tesztelés, és ezek a rövidebb ideig tartó ciklusok lépésről lépésre állítják elő a terméket) irányba.

Más frontokon is történtek változások az elmúlt időszakban. Ma már nem léteznek „local hero”-k, azaz olyan emberek, akik egyszemélyben mindent is meg tudnak oldani. Ez bizony a fentebb említett komplexitás növekedés egyik velejárója. A projektmenedzser sem képes már központosítottan, egyszemélyes hatalommal minden igényt kielégíteni, a teljes projektet egyedül irányítani. Neki is szüksége van egy vagy több jól működő, önálló csapat támogatására.

Elmondhatjuk, hogy a csapat szerepe exponenciálisan felértékelődött a projektek esetében. Már nem csak egyszerű végrehajtó szereppel bírnak, hanem egy-egy terület kapcsán döntéshozókká, felelősökké válnak. Vége annak az időnek, amikor mindenért a projektmenedzser volt a felelős, ő hozta meg a döntéseket, és viselte azok következményeit. Ez az egész menedzsment dolog már elosztott rendszerben működik. Mindenki egy célért küzd, mindenki számíthat a másik támogatására, és mindenki kiveszi a részét a munkából, felelősségből, döntésekből. Manapság egy projekt akkor tud sikeres lenni, ha rendelkezik olyan csapattal vagy csapatokkal, akik széles tudással rendelkeznek, képesek önállóan döntéseket hozni, kisebb-nagyobb feladatokat önjáró módon megoldani.

A technikai komplexitás kivitelezése sem valósítható meg már lineáris módon, szükség van az iteratív megközelítésre, ráadásul sok különböző elem fejlesztését kell összehangolni. Ezt nagyban segíti, ha rövidebb fejlesztési ciklusokban tervez a projekt. Az is egy jól megfigyelhető trend, hogy egyre kevesebb az ún. legacy felhasználás, azaz a régi és jól bevált dolgok ismételt beépítése az újabb termékekbe. Helyette egyre több a még nem látott és alkalmazott fejlesztések használata. Ezek miatt pedig szintén nem lehet hosszú távra, részletesen előre tervezni, mivel nem ismertek még az újítások hatásai, használhatóságuk és eredményességük. A végső felhasználásra is alkalmas elemek iteratív módon készülhetnek csak el.

Ha figyelmesen átbogarásszuk a fenti változásokat, akkor észrevehetjük, hogy van már olyan jól használható projektmenedzsment modell, amely segít adaptálódni a megváltozott körülményekhez. Ez pedig az agilis termékfejlesztés. Most nem célom bemutatni, hogy mit is jelent ez pontosan, akit érdekel, számos helyen utánaolvashat. A lényeg, hogy bizony az autóiparnak is észre kell vennie, hogy új szelek fújnak, és ha tartani szeretné az irányt és a sebességet, netán még rá is kapcsolna egy kicsit, akkor új vitorla után kell nézni. Szerencsére van már használható vitorla, ami képes befogni az új szelet, a kérdés, hogy időben sikerül-e lecserélni a régit.

Végezetül jó példaként álljon itt a Tesla cég, aki egy meglehetősen fiatal vállalat az autóiparban, mégis rövid időn belül igen meghatározó és vezető pozícióba került a „régi motorosokkal” szemben. A Teslánál vérbeli agilis szemlélet szerint történik a fejlesztés, és ezt nyíltan hirdeti is magáról. Mostanáig bejött nekik.

 

Forrás:

Simon Gábor (2021) Agilitás az autóiparban. IT business, Menedzsment
https://itbusiness.hu/technology/human/menedzsment_n/agilitas-az-autoiparban