Folyamatos termékfejlesztés¶
A folyamatos fejlesztés egy általános filozófia, amelynek célja, hogy segítse az egyéneket és szervezeteket abban, hogy folyamatosan javítsák önmagukat és az általuk előállított munkát.
Számos különböző módszertan tartozik a folyamatos fejlesztés ernyője alá. Ezek közé tartozik a kaizen, a six sigma és a lean, többek között. Bár az egyes módszerek konkrét lépései eltérőek, céljuk ugyanaz marad: egy olyan folyamat megvalósítása, amelyben a fejlesztés egy állandó cél, nem pedig egy egyszeri teljesítmény.
Az alábbi szakaszok részletezik, hogyan használható az Odoo a legnépszerűbb folyamatos fejlesztési stratégiák közös négy általános lépésének megvalósítására, a szükséges funkciók konfigurálásáról szóló dokumentációra mutató hivatkozásokkal. Az utolsó szakasz részletezi, hogyan konfigurálhat egy adott vállalat ezeket az Odoo megvalósításokat a saját szervezetén belül.
Fontos
A folyamatos fejlesztés nem egy mindenki számára megfelelő módszertan. Bár a legtöbb stratégia négy és hat lépés között tartalmaz, a megfelelő megvalósítás megköveteli egy olyan rendszer kidolgozását, amely az egyes vállalatok sajátos igényeihez igazodik.
Ez nem korlátozás, hanem inkább előny, mivel a módszertan elég rugalmas ahhoz, hogy szinte bármilyen felhasználási esethez alkalmazkodjon. Az Odoo különösen jól alkalmazkodik ehhez a rugalmassághoz, mivel konfigurálható úgy, hogy szinte bármilyen munkafolyamat igényeit kielégítse.
Ezért fontos emlékezni arra, hogy az alábbi tartalom csak példákat nyújt arra, hogyan lehet használni az Odoo-t. Ezeket inkább kiindulópontként kell tekinteni, nem pedig egy konkrét vázlatként, amelyet minden szervezetnek követnie kell.
Problémák azonosítása¶
Mielőtt a fejlesztés megkezdődhetne, szükséges meghatározni, hogy hol van szükség fejlesztésre. Itt jön képbe a problémák azonosítása. Az Odoo két legjobb alkalmazása a termékekkel vagy folyamatokkal kapcsolatos problémák azonosítására a Helpdesk és a Quality.
Ügyfélszolgálat¶
A Helpdesk alkalmazás hasznos a szervezeten kívülről érkező visszajelzések fogadására, például ügyfelektől vagy vásárlóktól. Ezt úgy érhetjük el, hogy megvalósítjuk a jegyek fogadásának egyik (vagy több) módszerét, beleértve az email aliasokat, az élő csevegéseket és a weboldal űrlapokat.
Ezeket a módszereket használva az ügyfelek visszajelzést küldhetnek a problémákról, amelyeket aztán egy helpdesk csapat tagja átnéz. Az áttekintés eredményétől függően a csapattag dönthet úgy, hogy további lépéseket tesz a probléma megoldása érdekében. Ez magában foglalhatja egy minőségi riasztás létrehozását.
Minőség¶
A Quality alkalmazás hasznos a szervezeten belüli visszajelzések fogadására, például alkalmazottaktól.
Ennek egyik módja egy minőségellenőrzési pont (QCP) beállítása. Egy QCP arra szolgál, hogy automatikusan minőségellenőrzéseket hozzon létre rendszeres időközönként, ösztönözve az alkalmazottakat a termék minőségének ellenőrzésére és megerősítésére.
Ha problémát találnak, az alkalmazott létrehozhat egy minőségi riasztást a minőségi csapat értesítésére. Minőségi riasztások létrehozhatók QCP nélkül is, abban az esetben, ha egy alkalmazott probléma felfedezésekor nem kapott ellenőrzési felszólítást. Ez nagyszerű módja annak, hogy az ügyfélszolgálati alkalmazottak értesítsék a minőségi csapatot egy ügyféljegy által felhívott problémáról.
Fejlesztések javaslata¶
Miután azonosítottuk a problémát, a következő lépés az, hogy javaslatokat tegyünk a probléma megoldására. Ahogyan a problémák azonosításánál, a Quality app itt is hasznos lehet a fejlesztési javaslatokhoz. Ezenkívül a PLM (Product Lifecycle Management) alkalmazás is használható erre a célra.
Minőség¶
Amikor egy quality alert létrehozásával hívjuk fel a minőségbiztosítási csapat figyelmét egy problémára, a Corrective Actions és a Preventive Actions fülek használhatók visszajelzés adására arról, hogyan lehet kezelni a problémát.
A Corrective Actions fül arra szolgál, hogy javaslatot tegyen az érintett tételek javítására. Például: Húzza meg szorosabbra a csavarokat, hogy az ülés a helyén maradjon.
A Preventive Actions fül arra szolgál, hogy javaslatot tegyen a probléma jövőbeni előfordulásának megelőzésére. Például: Ne húzza meg túl szorosra a csavarokat, mert elnyíródhatnak.
A minőségbiztosítási csapat, amely áttekinti a figyelmeztetést, látja ezeket a javasolt intézkedéseket, és figyelembe veheti őket a probléma kezelésének eldöntésekor.
PLM¶
A PLM alkalmazást a termék életciklusának kezelésére használják a bevezetéstől kezdve minden egyes következő verzióig. Így hasznos a termékfejlesztési ötletek tesztelésére.
A engineering change orders használatával a termékmenedzsment csapatok új iterációkat hozhatnak létre a termék BoMs-ból, szükség szerint hozzáadva vagy eltávolítva bizonyos alkatrészeket vagy műveleteket. Az ezekkel a BoMs-okkal létrehozott termékek átesnek egy felülvizsgálati folyamaton, hogy megerősítsék a változtatások hatékonyságát.
Stratégiák megvalósítása¶
A stratégiák megvalósítása magában foglalja a javasolt megoldások gyakorlati alkalmazását a fejlesztési javaslatok lépéséből. A PLM alkalmazás továbbra is hasznos ebben a lépésben, mivel konfigurálható a BoM frissítések végrehajtására. A Field Service alkalmazást bizonyos vállalatok is használhatják a már eladott termékek fejlesztésére.
PLM¶
Miután a BoM módosításai átestek a megfelelő felülvizsgálati folyamaton, jóváhagyhatók, és a frissített BoM használatba vehető. Ezt úgy érhetjük el, hogy az egyik ECO felülvizsgálati szakaszt úgy konfiguráljuk, hogy alkalmazza a változtatásokat, amelyeket a BoM-on végeztek, ekkor a frissített BoM elérhetővé válik az új MOs számára.
A termék BoM-jai továbbra is frissíthetők, amennyiben szükséges. A PLM alkalmazás verziókezelési funkciói lehetővé teszik egy adott BoM összes verziójának egyszerű kezelését.
Szerviz¶
A PLM alkalmazás nagyszerű módja a termék BoM-ok módosításának. Azonban ezek a változtatások csak az új BoM használatával gyártott termékeket érintik. Ha egy hibás terméket már eladtak egy ügyfélnek, szükség lehet annak javítására (vagy frissítésére).
Ilyen esetben a Szerviz alkalmazás használható helyszíni beavatkozások ütemezésére. Ezek a beavatkozások lehetővé teszik, hogy szerviztechnikusok (vagy más alkalmazottak) az ügyfél helyszínére menjenek, hogy megoldják a termékkel kapcsolatos problémát.
Felülvizsgálati műveletek¶
Reviewing actions is where the „continuous” part of continuous improvement comes into play, as it allows an organization to evaluate the decisions made in the previous steps. As such, this step is, essentially, returning to the beginning of the process, so that additional problems can be identified and addressed.
Ez azt jelenti, hogy a Helpdesk és Minőség alkalmazásokat ismét használni kell az ügyfél- és alkalmazotti visszajelzések fogadására. Egy másik alkalmazás, amely hasznos lehet ebben a szakaszban, a Kérdőívek alkalmazás.
Kérdőívek¶
Miután változtatásokat hajtottunk végre egy terméken vagy folyamaton, bölcs dolog lehet közvetlenül az ügyfelektől kérni visszajelzést, ahelyett, hogy megvárnánk, amíg maguktól jelentkeznek. Ez olyan visszajelzéseket hozhat felszínre, amelyeket az ügyfelek egyébként elhanyagoltak volna megosztani.
Az egyik legjobb módja ennek a Kérdőívek alkalmazás használata. Egy kérdőív létrehozása és elküldése azoknak az ügyfeleknek, akik frissített terméket kapnak, növeli annak valószínűségét, hogy releváns visszajelzést kapjunk a termékről.
Példa munkafolyamat: kabáttartó termékfejlesztés
Wood Hut egy kiváló minőségű fa termékeket gyártó vállalat. Elkötelezettek a lehető legmagasabb minőségű termékek gyártása iránt, és mindig keresik a módját, hogy javítsák az általuk értékesített termékeket, valamint az előállításukhoz használt folyamatokat.
A Wood Hut az Odoo platformot használja a gyártási, teljesítési és ügyfél-elégedettségi folyamatok minden elemének kezelésére. Kifejlesztettek egy egyedi termékfejlesztési munkafolyamatot, amely magában foglalja a Helpdesk, Quality, PLM és Manufacturing alkalmazásokat.
One of Wood Hut’s most popular products is their coat rack. It’s made entirely of oak, and customers describe it as „sleek and elegant.” However, recent customer feedback about the coat rack has brought attention to quality issues that necessitate revising the current manufacturing process.
A termékfelülvizsgálati munkafolyamat akkor kezdődik, amikor az ügyfélszolgálati csapat jegyet kap a Helpdesk alkalmazásban egy ügyféltől, aki problémát tapasztal a megvásárolt kabáttartóval. Az ügyfél, Abigail Peterson, azt találta, hogy a kabáttartó felborul, ha több mint öt kabát lóg rajta. Ez komoly probléma, mivel a kabáttartón hat kabát számára van hely.
Marc, az ügyfélszolgálati alkalmazott, akit a helpdesk jegyhez rendeltek, megnyitja a Quality alkalmazást, és létrehoz egy új minőségi riasztást. Megjelöli a Production Quality Team-et, és Julie Andresont jelöli ki a riasztásért felelős minőségi alkalmazottnak.
Julie áttekinti a riasztást, és konzultál a csapatával a legjobb cselekvési irányról. Úgy döntenek, hogy szükséges a termék BoM-jának felülvizsgálata, hogy a jövőben elkerüljék a problémát, amit Julie a minőségi riasztás Corrective Actions fülén jegyez fel.
Ezután Julie üzenetet küld a termékmérnöknek, Joe Kazannak a minőségi riasztás csevegőjében, hogy felhívja a figyelmét. Joe megnyitja a PLM alkalmazást, és létrehoz egy új ECO-t, megjegyezve a kabáttartó problémáját, és javasolva, hogy szükség lehet a termék BoM-jának módosítására.
Joe rákattint a Start Revision gombra, majd a Revision okos gombra, hogy megnyissa a kabáttartó BoM második verzióját. Ez a BoM az ECO mellett lett létrehozva, és archiválva marad, amíg jóvá nem hagyják.
Néhány tesztelés után Joe felfedezi, hogy egy fém támasztórúd hozzáadása a kabáttartóhoz megerősíti azt, lehetővé téve, hogy a tartó hat vagy több kabátot is megtartson anélkül, hogy felborulna. Frissíti a BoM-ot, hogy a támasztórúd is szerepeljen az alkatrészek között, és hozzáad egy extra műveletet annak biztosítására, hogy az a gyártási folyamat során be legyen szerelve. Végül üzenetet hagy az ECO csevegésében, hogy értesítse a menedzserét, Josét, hogy készen áll a felülvizsgálatra.
Jose felülvizsgálja a változtatásokat, és megerősíti, hogy hatékony módszerek a kabáttartó problémájának kezelésére. Az ECO-t az Approved szakaszba helyezi, ami a kabáttartó BoM második verzióját teszi az aktuális verzióvá.
Mostantól, amikor egy MO jön létre egy kabáttartó gyártására, az frissített BoM automatikusan kiválasztásra kerül. A Wood Hut megkezdi a továbbfejlesztett kabáttartó gyártását, és a vásárlói visszajelzések megerősítik, hogy az új verzió megoldotta az elődje problémáját.
Az Odoo platform használatával a Wood Hut végponttól végpontig terjedő termékfejlesztési folyamatot valósított meg. Mivel ennek a folyamatnak az alapvető elemei (vásárlói visszajelzés, minőségellenőrzés stb.) mindig működnek, újra felhasználható a termékek és folyamatok folyamatos frissítésére.