Gyártás

Az új termékfejlesztési folyamat a gyártásban: nyolc szakasz az ötlettől a piaci bevezetésig

Az új termékfejlesztési folyamat a szakaszok szisztematikus sorozata, amelyet egy gyártó követ, hogy egy kielégítetlen piaci lehetőséget kereskedelmileg életképes termékké alakítson a gyakorlatban. A gyártásban ez a sorozat lényegesen eltér a szoftverfejlesztéstől, mert a szerszámozás, az anyagok, a tanúsítás és a több éves átfutási idők fizikai korlátai minden döntést formálnak az út mentén. Ez az útmutató végigveszi a folyamat nyolc kanonikus szakaszát a lehetőség felfedezésétől a bevezetés utáni életciklus-kezelésig, összehasonlít három módszertant (stage-gate, Agile-Stage-Gate, Design Thinking) a folyamat irányítására, elmagyarázza, hogyan tartja össze a portfólió-nézőpont a gyártó párhuzamos projektjeit, katalogizál négy gyakori buktatót, és egy őszinte pillantással zárul arról, hol illeszkedik egy projektportfólió-rendszer, mint a FlexiProject, és hol nem.

Új termékfejlesztési csapat egy tervet vizsgál táblagépen és laptopon egy modern gyártóüzemben

Legfontosabb tudnivalók:

  • A termékfejlesztés végponttól végpontig tartó út, nem egyetlen projekt. A lehetőségtől a koncepción, terven, prototípuson, szerszámozáson és bevezetésen át az életciklusig tart.
  • A gyártói fejlesztés élesen eltér a szoftverestől. A szerszámozás százezrekbe kerül, az anyagok évekkel előre rögzülnek, a tanúsítás hosszú, az iteráció drága.
  • Az új fogyasztási cikkek kb. 80%-a megbukik a piacon (Nielsen BASES); az évi ~30 000-ből csak ~30% sikeres két éven belül, az erős termékek 15-ször valószínűbben.
  • Három módszertan uralja az irányítást. A stage-gate a szabályozott gyártás referenciája, az Agile-Stage-Gate a hardver plusz szoftverhez illik, a Design Thinking a kezdeti fázist erősíti.
  • Ez portfólióprobléma, nem egyetlen projekté. A gyártók 5-30 projektet visznek, amelyek megosztott mérnökökért versengenek; irányítás nélkül a konfliktusok csúszott bevezetésekké válnak.

Mi az új termékfejlesztési folyamat

Az új termékfejlesztési folyamat a tevékenységek strukturált sorozata, amelyet egy gyártó követ, hogy egy kielégítetlen piaci lehetőséget kereskedelmi forgalomban elérhető termékké alakítson. Jóval azelőtt kezdődik, hogy bárki megnyitna egy CAD-fájlt, és jóval az első darabok kiszállítása után is folytatódik. Minden komoly gyártó a folyamat valamely változatát működteti, akár dokumentált, akár nem, és akár így nevezik, akár nem, mert az alternatíva (az esetleges fejlesztés) megbízhatóan lassabb bevezetéseket, magasabb költségeket és alacsonyabb sikerarányt hoz, mint a strukturált út.

A fejlesztés mint végponttól végpontig tartó út

A folyamat nem egyetlen projekt meghatározott kezdő- és záródátummal. A szervezet visszatérő képessége, amely évről évre több új terméket futtat át ugyanazon a fegyelmezett folyamaton. Minden konkrét új termék szervezhető projektként a folyamaton belül, de maga a folyamat a gyártó állandó infrastruktúrája. Ez a különbség számít, mert azok a szervezetek, amelyek a fejlesztést egyszeri projektek sorozataként kezelik, minden alkalommal újra feltalálják a kereket, míg azok, amelyek állandó képességként kezelik, projekteken átívelő tanulást halmoznak fel, ciklusokon át finomítják kapuikat és sablonjaikat, és idővel javítják sikerarányukat.

Folyamat, termékmenedzsment és projektmenedzsment

Három szerep keveredik ezen a területen, és tisztázásuk sok felesleges vitát megtakarít. A termékmenedzsment azzal foglalkozik, mi történik egy adott termékkel a piaci élete során, a bevezetéstől az érettségen át a kivezetésig. A projektmenedzsment azzal foglalkozik, hogyan valósul meg egy adott kezdeményezés időben, költségvetésen belül és a hatókörnek megfelelően. A fejlesztési folyamat menedzsmentje azzal foglalkozik, hogyan hoz létre a szervezet egésze szisztematikusan új termékeket, milyen szakaszokon megy át minden termék, és hogyan működik az irányítás e szakaszok körül. Egyetlen termék mindhármat érinti: egy projektmenedzser leszállítja, egy folyamat formálja a fejlesztését, és egy termékmenedzser veszi át a felelősséget, amint bevezetik. A három szerep kiegészíti egymást, nem verseng.

Miért van szükségük a gyártóknak formális folyamatra

A formális folyamatok azért léteznek, mert az informálisak lehangolóan állandó kudarcmintákat termelnek. A Nielsen BASES megállapította, hogy az új gyorsan mozgó fogyasztási cikkek mintegy 80 %-a megbukik a piacon, és az évente bevezetett nagyjából 30 000-ből csak körülbelül 30 % ér el kereskedelmi sikert két éven belül. Ugyanez a kutatás megmutatta, hogy az erős termékteljesítményű innovációknak 15-ször nagyobb esélyük volt a sikerre, mint a gyenge teljesítményűeknek, ami aláhúzza, hogy a siker és a kudarc közötti különbség gyakran fegyelem, nem szerencse. A formális folyamat nem garantálja a sikert; kiküszöböli a legismétlődőbb kudarcokokat azzal, hogy arra kényszeríti a szervezetet, hogy validálja a piaci igényt, mielőtt mérnöki erőforrásokat kötne le, tesztelje a koncepciókat ügyfelekkel, mielőtt szerszámozásba fogna, és minden terméket az üzleti indoklásához mérjen minden kapunál, nem csak a bevezetéskor. E fegyelem nélkül a projektek elsodródnak, az elsüllyedt költségek felhalmozódnak, és a szervezetek csak akkor fedezik fel hibáikat, amikor a termék piacra kerül és nem kel el.

Miben tér el a gyártói fejlesztés a szoftveresétől

A termékfejlesztésről elérhető irodalom nagy részét szoftveres termékmenedzserek írják szoftveres termékmenedzsereknek, és nem ültethető át tisztán a gyártói környezetbe. A különbségek nem stilisztikaiak, hanem szerkezetiek, és a gyártói fejlesztést úgy kezelni, mintha szoftver lenne, drága hibákat szül. Négy dimenzió választja el határozottan a két világot.

Fizikai korlátok: szerszámozás, anyagok, tanúsítás

Egy fizikai termék olyan szerszámberuházást igényel, amelyet egy szoftvertermék nem ismer. Egy műanyag ház fröccsöntő szerszáma a bonyolultságtól függően százezer és kétmillió euró között kerül, és amint az acélt megmunkálták, a geometria megváltoztatása új szerszámot jelent, nem szoftverjavítást. A tervezés korai szakaszában hozott anyagdöntések meghatározzák az eladott áruk költségét a termék teljes életciklusára, és a késői anyagváltás a fejlesztésben hónapoknyi minősítési tesztet érvényteleníthet. Az orvostechnikai eszközök, a gyógyszeripar, az autóipar és a repülés termékeinek szabályozási tanúsítása hónapoktól évekig tart, és olyan dokumentációs nyomvonalakat követ, amelyeknek a folyamat 1. szakaszától létezniük kell, nem pedig visszamenőleg összeállítva a bevezetés előtt.

Az iteráció költsége

A szoftveres iteráció költsége nullához közeli. Egy kódmódosítás órák alatt kiadható, a frissítés terjesztésének határköltsége gyakorlatilag nulla, és ha a módosítás rossz, visszavonható. A hardveres iterációnak szinte semmi köze ehhez a költségszerkezethez. Egy új prototípusfutam hetekbe telik, és anyagokat, mérnöki időt és gépkapacitást fogyaszt. Egy szerszámváltás tízezertől százezer euróig terjed. Egy tervezésmódosítás miatti szabályozási újratanúsítás három-hat hónapig tarthat. Ez az aszimmetria azt jelenti, hogy a gyártói folyamatnak sokkal jobban előre kell terhelnie a validációt, mint a szoftveres megfelelőnek: közelebb hozni a tervet a helyeshez, mielőtt szerszámozásra köteleznénk magunkat, mert a tévedés költsége nagyságrendekkel magasabb.

Szabályozási és biztonsági követelmények

A szoftvertermékek főként az adatok körül szembesülnek szabályozással (GDPR, ISO 27001), és néha ágazatspecifikus megfeleléssel. A gyártott termékek strukturális szabályozási korlátokkal néznek szembe teljes életciklusukban. Az orvostechnikai eszközök az FDA 510(k) vagy a CE MDR felülvizsgálat alá esnek. A gyógyszerek az FDA vagy az EMA jóváhagyási folyamatai alá esnek. Az autóipari alkatrészek az IATF 16949 alá, a biztonságkritikus rendszerek pedig az ISO 26262 alá esnek. A repülés az FAA vagy az EASA tanúsítás alá esik. E rendszerek mindegyike tervezéstörténeti aktát követel, amely dokumentálja a folyamat során hozott döntéseket, és ezt az aktát utólag rekonstruálni sem nem lehetséges, sem nem elfogadható jogilag. Egy szabályozott termék folyamatának menet közben kell előállítania a dokumentációt, ami az első naptól formálja a sablonokat, az artefaktumokat és a kapukritériumokat.

Piacra kerülési horizontok

A szoftveres MVP-k érett termékszervezeteknél hat-tizenkét hét alatt kiadhatók. A gyártásnak nincs megfelelője ennek az ütemtervnek. Egy közepesen bonyolult termék működő prototípusa három-hat hónapba telik. Az első sorozatgyártási bevezetés tipikus ipari termékeknél tizennyolc-harminchat hónapba telik. Az összetett termékek, mint az autók, repülőgépek vagy orvostechnikai eszközök, három-hét évet igényelnek az ötlettől a bevezetésig. Ezek a horizontok nem hatékonytalanságok; a fizikai fejlesztés valóságát tükrözik, és a folyamatot köréjük kell tervezni, ahelyett, hogy úgy tennénk, mintha a szoftveres módszertanok tömeges átvételével összenyomhatók lennének.

Az új termékfejlesztési folyamat nyolc szakasza

Különböző források öt-nyolc szakaszban írják le a folyamatot attól függően, milyen finoman bontják a folyamot. Az alábbi nyolcszakaszos leírás a gyártói környezetben leghasznosabb változat, mert elkülöníti azokat a tevékenységeket, amelyeket a gyártók valóban külön munkacsomagként szerveznek. Egy ötszakaszos változat összevon olyan szakaszokat, amelyeket a gyártók jó működési okokból külön tartanak.

1. szakasz: Lehetőségfelfedezés és ötletgenerálás

Az első szakasz a homályos kezdeti szakasz, ahol a szervezet kielégítetlen igényeket azonosít, és jelölt ötleteket generál ezek kezelésére. Az ötletek több forrásból származnak: ügyfélkutatás interjúk, etnográfiai megfigyelés, voice-of-customer ülések és panaszelemzés révén; versenytárs-intelligencia termékbontások, szabadalmi keresések és elemzői jelentések révén; belső kutatás technológiai ütemtervek és nyílt feltárás révén; értékesítési és szervizvisszajelzés a terepről. E szakasz technikái közé tartoznak a Design Thinking workshopok, a jobs-to-be-done elemzés és a strukturált ötletelő ülések. A kimenet a jelölt ötletek halmaza, jellemzően ötven-kétszáz, amelyeket a 2. szakaszban szűrnek. E szakasz kihagyása vagy időnyomás alatti lerövidítése hamis megtakarítás: azt jelenti, hogy a későbbi szakaszok olyan ötleteken dolgoznak, amelyek soha nem voltak rendesen valós ügyféligényben lehorgonyozva.

2. szakasz: Ötletszűrés és koncepcióválasztás

A szűrési szakasz a jelölt ötletek halmazát kezelhető számú, továbbfejlesztésre érdemes koncepcióra szűkíti. A kritériumok általában négyek: stratégiai illeszkedés a gyártó irányához és portfóliójához, technikai megvalósíthatóság a jelenlegi vagy elérhető képességek mellett, piaci vonzerő méret és növekedés tekintetében, és pénzügyi életképesség a várható hozam és a várható beruházás viszonyában. A pontozási modellek és a súlyozott kritériumú értékelés csökkentik a döntés szubjektivitását. A kimenet három-tíz koncepció rövid listája, amely a fejlesztésbe lép, az 1. szakasz ötven-kétszázas halmazából. A fő kockázat itt az áttörő ötletek idő előtti kiszűrése, mert a konzervatív megvalósíthatósági kritériumokhoz képest túl ambiciózusnak tűnnek, ezért a szűrési kereteknek külön kategóriára van szükségük a magas kockázatú, magas hozamú koncepciók számára, amelyeket egyébként kiszűrnének.

3. szakasz: Koncepciófejlesztés és üzleti indoklás

A harmadik szakasz a rövid listás koncepciókat részletes javaslatokká fejleszti formális üzleti indoklásokkal. A koncepciófejlesztés magában foglalja az ötlet finomítását makettek vagy alacsony hűségű prototípusok révén, a koncepció tesztelését célügyfelekkel és az iterálást visszajelzéseik alapján. Az üzleti indoklás a szakasz nagyobb súlyú kimenete: dokumentum, amely számszerűsíti a várható piacméretet, az öt-hét éves bevételi előrejelzéseket, a fejlesztési költséget, a tervezett eladott áruk költségét, a várható árrést, a fedezeti pontot és a beruházás megtérülését. Az üzleti indoklás az a dokumentum, amelyhez az irányítóbizottság visszatér minden következő kapunál, ezért őszintének kell lennie, nem optimistának. A koncepciók ötven-nyolcvan százalékát ennél a kapunál leállítják vagy újratervezésre visszaküldik, és pontosan ez a fegyelem teszi működőképessé a folyamatot.

4. szakasz: Terméktervezés és mérnöki munka

A tervezési szakasz a jóváhagyott koncepciót teljes mérnöki csomaggá alakítja, amely készen áll a prototípuskészítésre. A CAD-modellezés részletes geometriát állít elő. A Design for Manufacturing (DFM), a Design for Assembly (DFA) és a Design for Cost elemzések ellenőrzik, hogy a terv valóban előállítható-e a cél költségen és mennyiségben. Az anyagválasztás konkrét ellátási láncokhoz, költségszerkezetekhez és szabályozási következményekhez köti a terméket. A termékbontási struktúra rendezi a tervet szerelvényekbe és alkatrészekbe, amelyek az anyagjegyzékekhez kapcsolódnak. A gyártással, minőséggel, beszerzéssel és költségmérnökséggel folytatott keresztfunkcionális felülvizsgálatok elkapják a problémákat, mielőtt drágává válnának. A kimenet olyan tervezési csomag, amely elég teljes ahhoz, hogy egy prototípuscsapat működő darabokat építsen belőle.

5. szakasz: Prototípus és validáció

A prototípuskészítés a tervezési csomagot működő darabokká alakítja. A korai prototípusok 3D-nyomtatást, megmunkálást vagy lágy szerszámozást használhatnak alfa darabok előállítására belső funkcionális teszteléshez. A későbbi prototípusok sorozatreprezentatív folyamatokat használnak béta darabok előállítására ügyfélterepi próbákhoz. A validáció lefedi a funkcionális teljesítményt, a biztonságot, a megbízhatóságot (gyakran gyorsított élettartam-tesztekkel, amelyek évek használatát szimulálják hetek alatt), a szabályozási megfelelést és a gyárthatóságot. Két-öt iterációs ciklus a tervezés és a prototípus között normális ebben a szakaszban, és minden ciklus olyan finomításokat hoz, amelyek visszakerülnek a CAD-modellekbe és a DFM-elemzésekbe. A szakasz végén a terv befagy, és a további változtatások drágává válnak, mert a szerszámok, anyagok és jóváhagyások újraminősítését váltják ki.

6. szakasz: Szerszámozás, iparosítás és pilot gyártás

A hatodik szakasz tőkét köt le a gyártószerszámokba, és validálja, hogy a terv elfogadható költséggel és minőséggel gyártható méretben. A szerszámberuházás magában foglalja a fröccsöntő szerszámokat, a betétszerszámokat, a készülékeket, a sablonokat, a tesztberendezéseket és bármely egyedi gépet. A gyártásmérnökség megtervezi a sort: munkaállomás-elrendezés, folyamatáramlás, minőségellenőrzési pontok és ütemidők. Egy száz-ezer darabos pilot futam valós gyártási körülményeket szimulál, és felszínre hoz olyan problémákat, amelyeket a laboratóriumi prototípusok nem tudtak megmutatni: a sort lassító szerelési ergonómia, a vártnál gyorsabban kopó szerszámozás, csak sorozatmennyiségnél megjelenő minőségi hibák. A felfutási terv meghatározza, hogyan skálázza a gyártó a pilotból a teljes gyártási ütemre, jellemzően három-tizenkét hónap alatt a bonyolultságtól függően.

7. szakasz: Bevezetés és kereskedelmi forgalomba hozatal

A bevezetés az, amikor a termék belép a piacra. A marketing előkészíti a pozicionálást, az árazást, a csatornastratégiát és a bevezetési kommunikációt. Az ellátási lánc megerősíti, hogy az alkatrész-beszállítók, a logisztikai szolgáltatók és a raktárkapacitás elbírja a tervezett mennyiséget. Az értékesítési csapatokat betanítják a termékre, jellemzőire, célügyfeleire és arra, hogyan szorítja ki az alternatívákat. A szervizcsapatokat betanítják a telepítésre, a javításra és a garanciára. A szabályozási jóváhagyásokat a bevezetés előtt meg kell erősíteni és dokumentálni. Maga a bevezetés lehet fázisos (regionális pilot, majd országos kiterjesztés, hogy a korai problémák a skálázás előtt kiderüljenek) vagy nagy bumm (egyidejű bevezetés minden piacon a figyelem megragadására), a fázisos bevezetések biztonságosabbak a kockázatos termékeknél, a nagy bumm pedig ott megfelelő, ahol a versenyidőzítés számít.

8. szakasz: Bevezetés utáni felülvizsgálat és életciklus-kezelés

A nyolcadik szakasz abban a pillanatban kezdődik, amikor a termék kiszállításra kerül, és piaci életén át folytatódik. A 30, 60, 90 és 180 napos formális felülvizsgálatok összevetik a tényleges teljesítményt az üzleti indoklással: a darabszám követi-e az előrejelzést, pozitív-e az ügyfél-visszajelzés, a garanciális igények a várt határok között vannak-e, az eladott áruk költsége a tervet követi-e. A terepi adatok folyamatos fejlesztést hajtanak a gyártásban, és néha termékfrissítéseket vagy újratervezéseket. A teljes ciklus tanulságai olyan tárba kerülnek, amely javítja a következő ciklus becsléseit és sablonjait. E szakasz döntései közé tartoznak a termékvonal-bővítések (variánsok a platform növelésére), az inkrementális újratervezések (a terepen talált minőségi vagy költségproblémák kezelésére) vagy a kivezetés tervezése (amikor a termék piaca továbblépett).

Próbálja ki a FlexiProjectet!

Kezelje fejlesztési portfólióját mind a nyolc szakaszon a FlexiProjectben, 30 napos ingyenes próba teljes hozzáféréssel.

FlexiProject

Három módszertan a folyamat irányítására

A nyolc szakasz leírja, mit tesz a folyamat; a módszertan leírja, hogyan irányítják. Három módszertan uralja a gyakorlatot a gyártói szervezetekben, és inkább kiegészítik egymást, mintsem versengenek. A Product Development and Management Association referenciakutatása következetesen azt mutatja, hogy a legjobban teljesítő szervezetek strukturált módszertanokat használnak, a felső kvartilis 76 % körüli sikerarányt jelent a többi nagyjából 51 %-ával szemben, és a módszertan megválasztása az egyik olyan kar, amely megnyitja ezt a szakadékot.

Stage-gate, cooper klasszikus modellje

A stage-gate a referenciakeret a folyamat irányítására, amelyet Robert G. Cooper fejlesztett ki a nyolcvanas évektől kezdve, és azóta tucatnyi tanulmányban finomítottak. A modell öt-hét szakaszra szervezi a fejlesztést, amelyeket döntési kapuk választanak el. Minden kapunál az irányítóbizottság az előző szakasz kimeneteit egy előre meghatározott listához méri, és négy döntés egyikét hozza: go (továbblépés engedélyezett erőforrásokkal), kill (a projekt leállítása), hold (szüneteltetés konkrét kérdések rendezéséig) vagy recycle (visszatérés az előző szakaszhoz átdolgozásra). A kapuőrök jellemzően egy keresztfunkcionális vezetői csapat, amely a portfóliót birtokolja, és a kritériumok minden kapunál a stratégiai illeszkedést, a piaci vonzerőt, a technikai megvalósíthatóságot és a pénzügyi hozamot kombinálják. A stage-gate kivételesen jól illik a szabályozott gyártáshoz, mert dokumentációs nyomvonala természetesen támogatja az FDA, az EMA és az ISO auditkövetelményeit.

Agile-stage-gate, a hibrid modell

Az Agile-Stage-Gate Cooper saját adaptációja a stage-gate-nek a gyorsan mozgó termékkörnyezetekhez, amelyet 2016-os munkájában formalizált. A külső szerkezet stage-gate marad ismerős kapuival és keresztfunkcionális irányításával. Minden szakaszon belül a munka két-négy hetes agilis sprintekben zajlik, iteratív ügyfél- vagy érintettfelülvizsgálatokkal. A kapuk könnyebbé válnak (agilis artefaktumokat, mint demókat és sprinteredményeket fogadnak el a klasszikus kimenetek mellett), de az irányítási fegyelem megmarad. Az Agile-Stage-Gate különösen jól illik a hardvert és szoftvert egyesítő termékekhez, mint a dolgok internete eszközök, a viselhető eszközök és a szórakoztató elektronika, ahol a fizikai részek a stage-gate fegyelemből profitálnak, míg a beágyazott szoftver az agilis iterációból. A tisztán hardveres fejlesztés kevesebbet nyer az agilis rétegből, mert iterációs ciklusai túl hosszúak az értelmes sprintekhez.

Design thinking a homályos kezdeti szakaszhoz

A Design Thinking, amelyet az IDEO-nál és a Stanford d.schooljánál fejlesztettek ki, és a kilencvenes és kétezres években tett népszerűvé, nem a stage-gate helyettesítője, hanem a kezdeti szakasz megerősítője. Öt fázisa (empatizál, definiál, ötletel, prototipizál, tesztel) az emberközpontú tervezésre és az ügyféligények felfedezésére összpontosít. A Design Thinking a folyamat 1-3. szakaszában a legerősebb, ahol a lehetőségfelfedezés, az ötletszűrés és a koncepciófejlesztés profitál az ügyfélempátia és a gyors koncepció-iteráció körüli szigorából. A 3. szakaszon túl gyengébb, mert a szerszámozás, az iparosítás és a tanúsítás nem emberközpontú tervezési problémák. Az érett gyártói szervezetekben jól működő kombináció a Design Thinking a homályos kezdeti szakaszban (1-3. szakasz), amely a 4. szakasztól átvált a stage-gate fegyelembe.

Stage-gate Agile-Stage-Gate Design Thinking
Legjobb felhasználás Szabályozott gyártás, összetett termékek Hardver plusz szoftver, szórakoztató elektronika Kezdeti innováció, koncepciófejlesztés
Erősségek Irányítás, dokumentáció, portfóliókontroll Iterációs sebesség, ügyfél-visszajelzés Ügyfélempátia, koncepció-iteráció
Gyengeségek Nehézkes lehet a gyors piacokhoz Kevésbé hatékony a tiszta hardverhez Nem szerszámozásra és iparosításra tervezték
Mikor használjuk Alapértelmezett a gyártói fejlesztéshez Ha a termék jelentős szoftvert tartalmaz Ráépülés a stage-gate 1-3. szakaszaira

A portfólió-nézőpont

Egy komoly gyártó nem egyszerre egy projektet visz. Öt-harminc párhuzamos projektből álló portfóliót visz különböző szakaszokban, amelyek megosztott mérnöki erőforrásokért és vezetői figyelemért versengenek. A Deloitte 2025-ös Smart Manufacturing felmérése 600 nagy amerikai gyártó vezetője körében megállapította, hogy 92 % az intelligens gyártást látja a következő három év versenyképességének fő hajtóerejeként, és egy koherens portfólió az egyik gyakorlati mechanizmus, amellyel a gyártók ezt az ambíciót eredményekké alakítják. Portfóliószintű irányítás nélkül a projektről projektre nézet elszalasztja azokat a kompromisszumokat, amelyek eldöntik, hogy a teljes beruházás elhozza-e a szándékolt stratégiai eredményeket.

Fejlesztés portfólióként, nem elszigetelt projektekként

A portfólió-gondolkodás más kérdést tesz fel, mint a projektgondolkodás. A projektgondolkodás azt kérdezi, hogy egy adott projektet a saját érdemei alapján engedélyezni kell-e. A portfólió-gondolkodás azt kérdezi, hogy a projektek egyensúlya tükrözi-e a gyártó stratégiai ambícióit. Egy jól kiegyensúlyozott portfólió jellemzően Cooper iránymutatását követi: körülbelül húsz százalék áttörő projekt (magas kockázat, magas hozam, iparágat változtató), negyven százalék platformprojekt (mérsékelt kockázatú innovációk, amelyek új családokat alapoznak) és negyven százalék inkrementális projekt (meglévő platformok bővítései és javításai). A tisztán inkrementális felé sodródó portfóliók túlberuháznak a rövid távba a jövőbeli pozíció rovására, míg a tisztán áttörő felé sodródók túlzott kockázatot vállalnak stabil bevétel nélkül. Ezt a sodródást csak a portfólió-nézet tárja fel; a projektnézet nem tudja.

Megosztott erőforrások a projektek között

A mérnökök, akik a gyártói fejlesztést működtetik, tervezésüknél fogva megosztott erőforrások. Egy vezető ipari tervező nyolc aktív projekthez járulhat hozzá. Egy DFM-mérnök tizenkettőben vehet részt. Egy adott anyag vagy folyamat szakértőjét bármely projektbe behúzhatják, amely az ő szakterületét érinti. A terhelés portfólió-nézete nélkül a konfliktusok három hónappal később projektcsúszásokként jelennek meg, nem ma engedélyezési kérdésekként. A portfóliószintű erőforrás-kezelés lehetővé teszi a gyártónak, hogy hónapokkal az előtt tervezzen felvételt, külső tanácsadást vagy kiszervezést, hogy a korlát egyébként harapna, ami a különbség a terv szerint futó portfólió és a határidőit tartósan túllépő között.

Irányítási döntések a portfólió egészében

Azok a bizottságok, amelyek a projekteket egyenként irányítják, elszalasztják a legfontosabb döntést, amelyet meg kellene hozniuk: melyik projektet állítsák le egy ígéretesebb finanszírozására. A portfóliószintű irányítás kompromisszumos beszélgetéseket kényszerít ki, mert a bizottság minden projektet egymás mellett lát, pontozásukkal, erőforrásigényükkel és stratégiai hozzájárulásukkal. A portfólión átívelő pontozás és rangsorolás felszínre hozza azokat a projekteket, amelyek már nem érdemlik ki helyüket, és egy projekt leállítása egy erősebb jelölt erőforrásainak felszabadítására rutindöntéssé válik, nem politikaivá. Azok a gyártók, akik a fejlesztést portfólióként és nem sorozatként viszik, magasabb leállítási arányt jelentenek a köztes kapuknál, és paradox módon ennek eredményeként magasabb bevezetési sikerarányt.

Próbálja ki a FlexiProjectet!

Egyensúlyozza az áttörő, platform- és inkrementális projekteket egyetlen portfólióban, próbálja ki a FlexiProjectet ingyen.

FlexiProject

Gyakori buktatók a folyamatban

Négy buktató magyarázza azoknak a kudarcoknak a többségét, amelyeket a fegyelem megelőzhetett volna. Inez Blackburn kutatása a Torontói Egyetemen az élelmiszer-szektor új termékeinek kudarcát 70-80 %-ra teszi, és a Nielsen gyorsan mozgó fogyasztási cikkekre vonatkozó adatai hasonló szinten állnak, de a mögöttes okok az alábbi négy minta köré csoportosulnak. Mindegyik megelőzhető, amint a szervezet megnevezi, és kifejezett ellenintézkedéseket épít az irányításába.

Hosszú fejlesztési ciklusok világos go, kill döntések nélkül

A zombiprojektek az első minta: projektek, amelyek sem határozottan nem haladnak előre, sem nem állítják le őket, hónapokon és éveken át alacsony intenzitású fejlesztésben sodródnak anélkül, hogy valaha határozott kapueredményt érnének el. A teszt egyszerű: valóban le tudja-e állítani bárki a szervezetben ezt a projektet a következő kapunál, vagy ez a kimenet gyakorlatilag kizárt, bármit mutatnak is az adatok? A zombik akkor keletkeznek, amikor a vezetői szponzoroknak érzelmi vagy politikai befektetésük van egy projektbe, és a kapufolyamatnak hiányzik a tekintélye ennek felülbírálására. A gyógymód az, hogy a kapubizottságnak valós tekintélyt adunk a projektek leállítására, és felelőssé tesszük annak gyakorlásáért, ami éppúgy kultúraváltást igényel, mint folyamatváltást.

Elsüllyedt költség tévedése a késői szakaszokban

Az elsüllyedt költség szerinti gondolkodás a második minta: az érv, hogy már annyit fektettek be, hogy a leállás most pazarlás lenne, miközben az őszinte elemzés azt mutatja, hogy a folytatás még nagyobb veszteséget termel. Ez a minta a 6. és 7. szakaszban a legkárosabb, amikor a szerszámozás le van kötve és az iparosítás folyamatban van, éppen abban a pillanatban, amikor a legnagyobb hátralévő beruházások még előttünk állnak. A fegyelem, amely ezt megelőzi, abban áll, hogy minden kapudöntés előretekintő elemzést használjon, összevetve a hátralévő beruházást a hátralévő várható hozammal, függetlenül a már elköltöttől. Az elsüllyedt költségek történelmi tények, nem döntési bemenetek.

Funkcióburjánzás és hatókör-infláció

A funkcióburjánzás a harmadik minta: a hajlam, hogy fejlesztés közben képességeket adjunk hozzá azzal az érvvel, hogy mivel a projekt úgyis fut, egy funkcióval több nem árt. Minden hozzáadás meghosszabbítja a fejlesztést, emeli az eladott áruk költségét, és bonyolultságot ad a végfelhasználónak. A ciklus egészére összesítve ezek a hozzáadások megduplázhatják a tervezett költséget, negyedévekkel késleltethetik a bevezetést, és a célpiacához túl összetett terméket eredményezhetnek. Az ellenintézkedés a számszerűsíthető üzleti hatású változáskezelés: egyetlen funkciót sem adnak hozzá anélkül, hogy dokumentálnák, hogyan változtatja meg az üzleti indoklást, és a kapubizottságnak kifejezetten jóvá kell hagynia a változást és annak ütemtervre és költségre gyakorolt hatását.

Gyenge átadás a kutatásból a gyártásba

A negyedik minta a falon átdobott tervezés problémája: a kutatás befejez egy tervet, amely minden funkcionális specifikációjának megfelel, de nem gyártható mennyiségben elfogadható költséggel, és a gyártás olyan tervet örököl, amelyet nem tud működésre bírni. A következmények bevezetési késésekként jelennek meg, miközben a gyártás a gyárthatóságra tervez át, minőségi problémákként a korai sorozatokban, és a célnál magasabb eladott áruk költségeként. Az ellenintézkedés az, hogy a gyártást, a minőséget és a költségmérnökséget a 4. szakasztól kezdve beépítjük a tervezési felülvizsgálatokba, hogy a DFM- és DFA-korlátok formálják a tervet, ahelyett, hogy a befagyasztás után fedeznék fel őket. A projekt tulajdonjoga csak a 6. szakasz pilot futama után száll át a kutatásból a gyártásba, amely megerősíti az elfogadható gyárthatóságot, nem korábban.

Hogyan támogatja a FlexiProject a folyamatot

A FlexiProject a gyártói technológiai verem projektportfólió-rétegében helyezkedik el, a működési rendszerek (CAD, PLM, MES, ERP) felett és a stratégiai réteg alatt, ahol a vezetői bizottság kijelöli az irányt. Egyik rendszert sem váltja fel; összetartja a projektek portfólióját a fázismodellekkel, az irányítási munkafolyamatokkal és a projekteken átívelő erőforrás-kezeléssel, amelyet a folyamat nagyban megkövetel.

Portfóliókezelés fázismodellekkel

A FlexiProject a projekteket dedikált portfólióba szervezi a folyamat nyolc szakaszához illeszkedő fázismodell-sablonokkal. Minden projekt közös fázisstruktúrát örököl azonos kapukritériumokkal, kimeneti ellenőrzőlistákkal és pontozási dimenziókkal, ami portfólió szinten összehasonlíthatóvá teszi a projekteket. A projektek saját projektalapító okiratokat, üzleti indoklásokat, költségvetéseket és erőforrás-hozzárendeléseket visznek, míg a portfólió-nézet összesíti a teljes beruházást, a várható hozamokat és a portfólió egyensúlyát az áttörő, platform- és inkrementális kategóriák között.

Projekt ütemterv a FlexiProject rendszer Projektportfóliók moduljában
Projekt ütemterv a FlexiProject rendszer Projektportfóliók moduljában

Stage-gate elfogadási munkafolyamatok

A stage-gate döntési pontok elfogadási munkafolyamatokként vannak megvalósítva a FlexiProjectben. Minden kapunál az irányítóbizottság az üzleti indoklásához méri a projektet, látja a projektalapító okirat verziózott előzményeit, és rögzíti a go, kill, hold vagy recycle döntést csatolt indoklással. A verziózott okirat és a döntési archívum támogatja az FDA, az EMA és az ISO rendszerek szabályozási auditkövetelményeit, amelyek bármely történelmi kapunál rekonstruálják a projekt állapotát, nem csak a jelenlegit.

Projekteken átívelő erőforrás-kezelés megosztott mérnökökhöz

A megosztott mérnöki erőforrások portfólió szinten jelennek meg, nem az egyes projektek szintjén. Egy nyolc aktív projekt között elosztott DFM-mérnök egyetlen terhelési nézetben látható, a konfliktusok pedig egy kilencedik projekt engedélyezése előtt bukkannak fel, nem három hónappal később elcsúszott mérföldkövekként. A portfólió menedzserek modellezhetik konkrét projektek hozzáadásának, késleltetésének vagy gyorsításának hatását a teljes mérnöki terhelésre, és a tényleges számokkal, nem intuícióval hozhatnak kompromisszumos döntéseket.

Amit a FlexiProject nem tesz

A FlexiProject nem végzi magát a mérnöki munkát. Nem váltja fel a CAD-et a tervezéshez, a PLM-et a termékadat-kezeléshez, a MES-t a gyártásvégrehajtáshoz vagy az ERP-t a pénzügyi tranzakciókhoz. Nem végez ügyfélkutatást és nem gyűjt voice-of-customer bemeneteket (ezek dedikált piackutató eszközökbe és ügyfél-visszajelzési platformokba tartoznak). Nem generál ötleteket (az ötletkezelés dedikált eszközökbe, mint az Ideawake, a KaiNexus vagy a HYPE Innovation, tartozik). A projektportfólió-rétegben helyezkedik el, összetartja a folyamatot a projektek között, és integrálódik a körülötte lévő működési rendszerekhez, ahelyett, hogy azokká próbálna válni.

Gyakran ismételt kérdések

Mennyi ideig tart egy tipikus gyártói folyamat?

Az ütemtervek óriási mértékben változnak a termék bonyolultságától és a szabályozási környezettől függően. Egy egyszerű, minimális szabályozási felügyeletű termék (új csomagolásterv, egy meglévő termékvonal változata) hat-tizennyolc hónap alatt befejezheti a ciklust. Egy közepesen bonyolult elektronikai termék jellemzően tizennyolc-harminchat hónapig tart az ötlettől a bevezetésig. Az orvostechnikai eszközök, a gyógyszeripar vagy az autóipar szabályozott termékei rendszeresen három-hét évet vesznek igénybe, olyan tanúsítási ciklusok miatt, amelyeket nem lehet összenyomni. Ezek a horizontok nem hatékonytalanságok; a fizikai fejlesztés és a szabályozási felügyelet valóságát tükrözik, és azok a szervezetek, amelyek mást ígérnek, jellemzően nehezen tanulják meg a korlátokat.

Mi a különbség a termékfejlesztés és a termékmenedzsment között?

A két diszciplína a termék életének különböző részeit fedi le. Az új termékfejlesztés a létrehozás folyamata, a lehetőségfelfedezéstől a bevezetésig. A termékmenedzsment a bevezetéskor veszi át, és a termék piaci életén át kezeli: árazás, pozicionálás, életciklus-ütemterv, funkciófrissítések és végül kivezetés. Sok gyártónál ugyanaz a csapat viszi a terméket a fejlesztésből a termékmenedzsmentbe, de a diszciplínák és a sikermérőszámok eltérnek: a fejlesztést a sikeres bevezetések mérik, a termékmenedzsmentet a bevétel, az árrés és a telepített bázis elégedettsége.

Mi a projektek kudarcának legnagyobb oka?

A Nielsen és más kutatók következetesen ugyanazt az elsődleges okot azonosítják: az ügyféligény félreolvasása, vagy olyan termékek bevezetése, amelyek olyan problémákat oldanak meg, amelyekkel az ügyfeleknek valójában nincs dolguk, vagy rosszabbul oldják meg, mint a meglévő alternatívák. A termékminőség rendszerint nem a fő probléma; a termék-piac illeszkedés az. Ezért számít annyira az 1. szakasz (lehetőségfelfedezés) és a 3. szakasz (koncepciófejlesztés és üzleti indoklás). Azok a szervezetek, amelyek ezeket a szakaszokat lerövidítik, hogy gyorsabban a mérnöki munkába jussanak, hajlamosak olyan termékeket bevezetni, amelyek jól működnek, de nem kelnek el, ami vitathatóan rosszabb, mint a rosszul működő termékek, mert a kudarcot nehezebb diagnosztizálni.

Szükségünk van speciális szoftverre a folyamathoz?

Magához a folyamathoz nem; sablonokkal és fegyelmezett kapumegbeszélésekkel is vihető. Amihez szoftvertámogatásra van szükség, az a projektek portfóliója, amelyet egy komoly gyártó párhuzamosan visz. A CAD és a PLM magához a terméktartalomhoz szükséges, egy projektportfólió-kezelő rendszer pedig ahhoz szükséges, hogy összetartsa a projektek portfólióját közös fázismodellekkel, kapumunkafolyamatokkal, projekteken átívelő erőforrás-kezeléssel és auditszintű dokumentációval. Egy tucat projekt portfóliójának táblázatokon és e-mailen való vitele hajlamos pontosan a buktatók szakaszában leírt kudarcmintákat termelni.

Lehet a folyamat agilis?

Teljesen agilis a szoftveres értelemben ritkán, mert a fizikai fejlesztési ciklusok túl hosszúak az értelmes sprintiterációhoz a hardveren. Agile-Stage-Gate egyre inkább, különösen a jelentős szoftver- vagy firmware-összetevővel rendelkező termékeknél. Az érett gyártóknál a pragmatikus minta a stage-gate irányítás a teljes folyamatra, agilis munkamódszerekkel a szakaszokon belül, különösen a 3. (koncepciófejlesztés) és a 4. (tervezés) szakaszban, ahol az iteráció valós értéket ad. Egy gyártói folyamat teljes agilis átalakítása gyakrabban marketingretorika, mint működési valóság.

Az új termékfejlesztési folyamat a szisztematikus sorozat, amelyet egy gyártó követ, hogy egy kielégítetlen piaci lehetőséget kereskedelmi forgalomban elérhető termékké alakítson, nyolc kanonikus szakaszon át a lehetőségfelfedezéstől a bevezetés utáni életciklus-kezelésig. A gyártói fejlesztés négy dimenzióban lényegesen eltér a szoftveresétől: a szerszámozás és az anyagok fizikai korlátai, a nulla helyett tízezrekben mért iterációs költség, a folyamatot az első naptól formáló strukturális szabályozási követelmények, és a hetek helyett években mért piacra kerülési horizontok. Három módszertan uralja a gyakorlatot: a stage-gate mint referenciakeret, az Agile-Stage-Gate mint hibrid a hardvert és szoftvert egyesítő termékekhez, és a Design Thinking mint a homályos kezdeti szakasz megerősítője. A folyamat portfólióprobléma, nem egyetlen projekt problémája, és azok a gyártók, akik következetesen felülmúlják társaik referenciaértékeit, fejlesztésüket az áttörő, platform- és inkrementális projektek kiegyensúlyozott portfóliójaként viszik, fegyelmezett kapuirányítással és őszinte, projekteken átívelő erőforrás-kezeléssel. A FlexiProject biztosítja azt a projektportfólió-réteget, amely nagyban összetartja a fejlesztési programot, fázismodell-sablonokkal, stage-gate elfogadási munkafolyamatokkal, projekteken átívelő erőforrás-kezeléssel és auditszintű dokumentációval a szabályozott termékekhez. A körülötte lévő működési rendszerekhez integrálódik, ahelyett, hogy azokká próbálna válni. Ha egy gyártó fejlesztési programja kinőtte a táblázatokat és az e-mailt, és olyan portfóliórendszerre van szüksége, amely a valódi nyolcszakaszos folyamatot modellezi, harminc nap teljes hozzáférés bankkártya nélkül gyakorlati módja az illeszkedés tesztelésének.

Miłosz Marciniak
Miłosz Marciniak
Key Account Manager​

Értékesítési és üzletfejlesztési menedzser, több mint 15 év tapasztalattal az üzleti kapcsolatok építésében hazai és nemzetközi piacokon. Go-to-market stratégiák kialakítására és nemzetközi környezetben zajló projektek irányítására szakosodott. Hatékonyan ötvözi a stratégiai és az operatív gondolkodást, az eredményekre és a hosszú távú üzleti értékre összpontosítva. A FlexiProjectnél abban támogatja az ügyfeleket, hogy a rendszert saját igényeikhez igazítsák, és a szervezeten belül hatékonyan használják. Segíti a szoftver bevezetési folyamatait és a projektmenedzsment-kultúra kialakítását egyaránt.