ITÉlet

4,5 éve írom ezt a blogot arról, hogyan látja egy autóiparban dolgozó IT menedzser a szakmát, és mindeddig pont a lényeggel nem foglalkoztam: milyen sajátosságokkal rendelkezi a szoftverfejlesztés autóipari környezetben?

4,5 éve írom ezt a blogot arról, hogyan látja egy autóiparban dolgozó IT menedzser a szakmát, és mindeddig pont a lényeggel nem foglalkoztam: milyen sajátosságokkal rendelkezi a szoftverfejlesztés autóipari környezetben?

Megpróbálom összeszedni azt, milyen szoftvert fejleszteni autóiparban, miben különbözik a „hagyományos” szoftverfejlesztéstől, illetve mi az, amit nem tanítanak az egyetemen.

Multinacionális környezet

Az autóipar a nagy méretekről és tömeggyártásról szól, ezért aki az autóiparban van, az szükségszerűen multinacionális vállalatokkal fog dolgozni globális terepen. Az autógyárak maguk óriási multik, kisüzemi autógyártás nem létezik. Az autógyárak beszállítói maguk is multik.

Következmény: Aki az autóiparban karriert akar csinálni, barátkozzon meg a multikkal és a nagyüzemi módszerekkel.

Globalizáció

Az autóiparban az országhatárok eltűntek – sőt még a kontinensek is sokkal közelebb kerültek egymáshoz. Ma már simán lehetséges, hogy egy Németországban gyártott autóba egy afrikai munkás fogja beépíteni a Japánból szállított alkatrészt a dél-amerikai menedzser utasításai alapján, hogy aztán az autót az USA-ban adja el egy ausztrál értékesítő.

Következmény: Nyelveket kell beszélni, tudni kell más nációkkal együtt dolgozni.

Többrétegű beszállítói hálózat

A folyamatos gyártás miatt nagy kiterjedésű és stabil beszállítói hálózatra van szükség. Ezt az autógyárak úgy érik el, hogy nem közvetlenül 1-1 beszállítóval szerződnek, hanem 1. és 2. szintű beszállítói hálózatot hoznak létre, amolyan fővállalkozó-alvállalkozó csoportokat. Ezért a gyárnak nem sok kicsi, hanem kevés de nagyobb beszállítót kell menedzselnie. És természetesen minden alkatrészre több beszállító is van, hogy az egyik kiesése esetén is legyen ellátás. (Ez különösen így van a 2011-es japán földrengés után)

Következmény: A klasszikus ügyfél-vállalkozó felállás helyett a szoftverfejlesztő egy nagyobb csapat része lesz, ahol az ügyfél ügyfelével, vagy az ügyfél ügyfelének az ügyfelével fog dolgozni. Akikkel személyesen sosem találkozik. A szoftverfejlesztés egyéni műfajból csapatmunkává vált, ahol elveszíti a jelentőségét a tér és az időzóna.

Fix határidő

A határidőket a gyárt, a marketing, az értékesítés határozza meg. Tipikusan ez egy új modell indítása a cél, és ennek rendelünk alá mindent. Mivel az autógyár autóértékesítésből él, ezért különösen érzékeny minden olyan hibára, ami az értékesítés csúszását eredményezi – hiszen minden nap késés sok elveszített pénzt jelent.

Következmény: A határidőket nem az informatikus diktálják, és nincs beleszólásuk. Határidőre el KELL készülni. Aki nem készül el, azt kirúgják.

Költségérzékenység

Mivel a gyártás nagy volumenű, minden, a legapróbb kiadáscsökkentés is jelentős megtakarítást eredményez. Kis túlzással élve: ha egy új technológia alkalmazása 1 cent megtakarítást eredményez minden legyártott autón vagy alkatrészen, akkor azt a technológiát be fogják vezetni. Az autóipari döntéshozók nem értenek a szoftverfejlesztéshez, ők tipikusan csak a lap alján az összesítést nézik meg: mennyi lesz a profit.

Következmény: Tudni kell olcsón szállítani úgy, hogy az közben ugyanolyan jó mint a konkurens termék.

Minőség minden felett

A minőség az autóiparban nem játék. Egy apró szoftverhiba elég ahhoz, hogy a gyár leálljon – és ilyenkor minden leállással töltött perc is óriási veszteséget jelent a cégnek. Ha pedig a hiba a legyártott, eladott autóban jelentkezik, akkor az összes eladott autó visszahívása és kijavítása gigászi logisztikai erőfeszítést – és ezzel arányos költségeket – jelent. Itt nem lehet a felhasználókat béta tesztelőnek nézni – itt minden többszörösen letesztelt és kipróbált, mire a vásárlóhoz kerül. Az esetleges hibáért pedig a beszállító felelős, a hiba költségét könyörtelenül kiszámlázzák.

Következmény: Nemcsak jól, olcsón és határidőre, de kiváló minőségben kell agyontesztelt szoftvert szállítani. Más iparágakhoz képest a minőségbiztosítás szerepe jelentős.

Projektszerű fejlesztés

A fentiek (jól, olcsón, határidőre, kiváló minőségben) csak úgy tudnak teljesülni, hogy a szoftverfejlesztés az projektszerűen, egy üzleti projekt részeként történik. A projektszerűség azt jelenti, hogy van terv, vannak határidők, van projekt szervezet, adott módszertant kell követni, a projekt állását folyamatosan követik és ellenőrzik. És a legkisebb csúszásnak következménye van.

Következmény: Nem úgy fejlesztünk szoftvert ahogy akarunk, hanem ahogy megmondják. Határidők és ütemterv van, amiket követni és tartani kell.

Hosszú távú együttműködés

Amikor az autógyárak beszállítót keresnek, akkor az nem 1-1 alkalomra szól, hanem egy hosszútávú együttműködés kezdete. Amikor egy új szoftvert kell fejleszteni, akkor ott nem csak a fejlesztési költségekről van szó, hanem közös munkáról a következő 5-10-15 évre, ahol a szoftverfejlesztésen túl üzemeltetés, rendszerintegráció, adatkarbantartás és változáskérelmek lesznek.

Aki alkatrészt ad el egy új modellhez, annak nem csak az adott modell gyártásához kell alkatrészt biztosítania, hanem utána évekig amíg azt a modellt gyártják, és még a gyártás leállítása után is a szervízeléshez.

Következmény: Egy ilyen lehetőséget megnyerni azt jelenti, hogy a következő egy évtizedre biztosított a munkánk. (Hacsak nem szúrjuk el…)

Autóipari tapasztalat

Csak olyan szoftverfejlesztővel állnak szóba, akinek már jelentős autóipari tapasztalata van.

Következmény: A potenciális beszállítók száma kicsi, mindenki ismer mindenkit. Gyakori, hogy ugyanaz a beszállító adja el ugyanazt a szoftvert/szolgáltatást több különböző autógyárnak. Akik pont azért veszik meg, mert már bizonyított a konkurenciánál.

Mindig van konkurencia

A többrétegű beszállítói hálózat azt is jelenti, hogy bármelyik láncszem bármikor felcserélhető. Ez nem a gaz multi elnyomó természetéből fakad, hanem mert bármikor történhet nem várt esemény – háború, földrengés, logisztikai problémák, új vámtörvény – ami miatt a jól bevált szállító önhibáján kívül kiesik. És ilyenkor a gyártás nem állhat le.

Tehát minden alkatrészre legalább 2 beszállító van, és a gyár attól rendel többet, amelyikkel elégedettebb.

Következmény: Aki nem szállít határidőre és jó minőségben, az könnyen kirúgják.

Fix szerződések helyett volumen alapú keretszerződések

Az autóiparban jellemző másik módszer a tipikus „vendor lock-in” elkerülésére a volumen alapú keretszerződések megkötése, amelyek nem kötelezik semmire a megrendelőt. Például amikor szoftvert kell fejleszteni, akkor nem adott szoftver kifejlesztéséről szól a szerződés, hanem idő és költségalapú elszámolásról, ahol a keretszerződés csak az órabéreket rögzíti. A mennyiséget majd ott és akkor határozzák meg.

Szoftver vásárlás helyett inkább szoftver bérlés történik (SaaS), esetleg használat-alapú licenszdíj.

Következmény: Egy megrendelés elnyerése és a szerződés aláírása önmagában nem garantálja azt, hogy beszállító ténylegesen milliomos lesz. Folyamatosan bizonyítani kell – még a szoftver leszállítása után is – ahhoz, hogy jöjjön a következő megrendelés.

Dupla vagy semmi játék

A korábbiak alapján talán látszik, hogy elég durva világ ez. Hosszú távú és nagy volumenű szerződésekkel dolgozunk, tehát bekerülni a belső körbe óriási pénzeket jelent. Autóiparban szoftvert fejleszteni azt jelenti hogy az ember jól keres.

A másik oldalról viszont ebből a szűk körből nagyon könnyű kipottyanni: az elvárások magasak, és ott van a többi beszállító aki csak az alkalomra vár. Az aláírt hosszútávú keretszerződés sem jelenti azt, hogy tényleges megrendelés lesz. Elég egyszer nagyot hibázni, hogy az ember elveszítse az ügyfele bizalmát, és onnantól kezdve vége.

Arról nem is beszélve, hogy a kötbér kérdését és az anyagi felelősséget nagyon is komolyan veszik. (Szemben az IT hagyományos „a bug az élet része” hozzáállásával)

Következmény: A szoftverfejlesztés minden fázisában, minden aspektusában maximálisan profinak kell lenni. A „leszállítjuk ahogy sikerül és majd lesz valami” mentalitást el kell felejteni.

Felejtsd el a cutting edge technológiákat

Mi IT-sok rajongunk a legújabb technológiáért (Miért jellemző az IT-ra  hype), viszont az autóipari megrendelőket ez nem érdekli, nekik a stabilitás és a minőség az érték. Nem fognak egy jól bevált technológiát lecserélni egy másikra csak azért, mert új.

Arról nem is beszélve, hogy az autóipar tele van legacy rendszerekkel (pl ősrégi mainframe), amikhez integrálódni kell és amiket nem fognak lecserélni.

Következmény: Cutting edge helyett jól bevált technológiák ismerete és használata.

Nagy teljesítményű rendszerek

Autók és alkatrészek nagy mennyiségbe történő gyártása, a legyártott darabok logisztikájának és megrendelésének követése, az autó történetének sok-sok évre visszamenőleg történő megőrzése azt jelenti, hogy nagy teljesítményű rendszerekkel kell dolgozni, nagy adatbázisokkal.

Ehhez hozzáadódik a 21. századi ember igénye a webkettes szolgáltatások iránt: gombnyomásra minden adat elérhető legyen az autómról, a kiválasztott alkatrészről, kapjak testreszabott ajánlatokat, és az autógyártó adjon interaktív kommunikációs lehetőséget.

Következmény: Az autóipari gerinchálózatok nagy teljesítményűek, ami megköveteli az ezt kiszolgáló infrastruktúrát és szoftverfejlesztési eljárásokat.

Gyártás és értékesítés

Az autóiparnak két nagy ága van: a gyártás és az értékesítés.

Az értékesítésben az informatika célja a marketing és az értékesítés kiszolgálása. Minden értékesítés-vezérelt, azaz biztosítani kell, hogy az alkatrész és az autó eljusson az ügyfélhez, minél gyorsabban és zökkenőmentesen. Az üzleti döntéseket marketingesek és értékesítők hozzák.

A gyártásban a logisztikai rendszereken felül az informatikai mint az autó része jelen meg, vagyis az autó egyre nagyobb részben számítógép-vezérelt (lásd Software can be unsafe at any speed). Ez beágyazott rendszereket, hardver-közeli programozást jelent, igen hosszú validálási és tesztelési ciklusokkal.

Következmény: Beágyazott rendszerek fejlesztése, ipari automatizálás és „üzleti” alkalmazásfejlesztés jellemző az autóiparra.

Az intelligens autó és az elektromos autó

A jövő autója egyre nagyobb mértékben számítógép vezérelt. Ennek egyik csapásiránya az elektromos autó, ahol a számítógép vezérel és generál mindent. Extrém példa a motorzaj, amit egy mp3 lejátszó kelt – hiszen az elektromos autó motorja csendes.

A másik csapásirány az internetre csatlakozó autó, amelyik a vezetéknélküli hálózattal és az okostelefonunkkal együtt intelligens hálózatot alkot. Ez egy teljesen új dimenziót nyit meg olyan elképesztő szolgáltatásokkal, amelyeket ma még lehetetlennek tartunk.

Következmény: Az autóiparban egyre több szoftverfejlesztésre és egyre több informatikusra lesz szükség.

Agilitás

Habár korábban a kőbe vésett határidőkről, anyagi felelősségről és fix scope-ról beszéltem, azért egy új modell elindításáig nagyon sok dolog változhat. Különösen az utolsó pillanatokban. És az utolsó utána pillanatokban. Mivel egy autóipari projekt tipikusan hosszú lefutású, menet közben az üzleti körülmények és az elvárások változhatnak. Az elvárások egy része az induláskor nem is ismert.

Következmény: Bizonyos mértékű rugalmasságra mindenképpen szükség van.