Ostorcsapás effektus, angolul bullwhip effect: „Az ellátási láncban felfelé haladva a kereslet egyre jelentősebb kilengéseket mutat, azaz az ellátási láncban a korábbi bizonytalanságok a lánc végén lévő partnereknél kumulálódnak”.
Ostorcsapás effektus, angolul bullwhip effect: „Az ellátási láncban felfelé haladva a kereslet egyre jelentősebb kilengéseket mutat, azaz az ellátási láncban a korábbi bizonytalanságok a lánc végén lévő partnereknél kumulálódnak”.
Logisztikusoknak az egyetemen tanítják. Meglehet, hogy informatikai menedzsereknek is kellene, hiszen a jelenség az IT-ban is előfordul. Talán nem véletlenül, a jelenség nem a gyártóipar, hanem az ellátási lánc sajátossága – és hosszú ellátási láncot az IT-ban is lehet építeni.
Mondok egy példát.
Tegyük fel, hogy a bevezetésre álló szoftvert a nagyvállalat megmutatja néhány kereskedőnek. A kereskedők elégedettek a szoftverrel, annyit tesznek csak hozzá, hogy a User Interface-en a gombok lehetnének mondjuk kerekek. Nem azért, mert ne tudnának szögletes gombra kattintani, de hát most ez jutott eszükbe.
A menedzsment elé a report-ba az kerül, hogy a test user-ek csoportja elégedett volt mindennel, annyi megjegyzésük volt hogy a gombokat meg lehetne változtatni. A menedzsment a projekt vezetőjét megkérdezi, hogy mi erről a véleménye, a projekt vezetője megígéri, hogy foglalkozik a gomb kérdéssel és a következő találkozón jelenti az eredményt.
A projekt vezető ezután beszél a vállalkozóval aki a szoftvert fejleszti (naná, hiszen a multi miért fejlesztene szoftvert saját maga, outsourcing vagy mifene), és megmondja neki, hogy a gombokat meg kell változtatni, ez a vezetőség kérése, adjon becslést/határidőt mikor lesz kész. De jó lenne ha a következő release-be már belekerülne, mert akkor a vezetőség látja, hogy itt az emberek nagyon gyorsan ugranak minden feladatra és a projekt jó kézben van tartva.
A vállalkozó felhívja az alvállakozóját (hiába na, elég nagy a projekt, sok a munka, nem lehet mindent házon belül megcsinálni) és leszidja, hogy már megint a gombokkal van baj, de ezúttal már a vezetőségnek is szemet szúrt a dolog, lesz szíves azonnal ugrani és megcsinálni, mert különben.
Az alvállalkozó ijedten összehívja a fejlesztőit: vészhelyzet van, elégedetlen az ügyfél, most neki kell feküdni de bármi áron megcsinálni. A fejlesztők pedig jelentős túlórával, de leszállítják a változtatást.
Mi történt itt?
1) Mindenki a meglévő tervhez képest dolgozott, ehhez képest beesett egy nem tervezett és nem várt igény, ami ugyan apró és jelentéktelen volt de végül jelentős kavarodást okozott.
2) A láncban mindenki – vezetőség, PM, fővállalkozó – ráhagyással dolgozik, tehát mindent amit szerinte meg kell csinálni egy picit fontosabbnak állítja be, és rövidebbre veszi a szállítási határidőt.
3) Az igények „csak úgy” esnek be, nem pedig folyamatosan. Amikor meeting van a vezetőséggel vagy a kereskedőkkel akkor sok munka esik be, egyébként pedig kevés.
4) Mivel a vezetőségtől vagy az ügyféltől bármikor jöhet egy újabb igény, ezért mindig kell lennie szabad kapacitásnak – minden szinten több erőforrást kérnek az alattuk lévőtől, mint amennyire szükség lenne normális esetben.
5) A hektikus igények miatt az alvállalkozó kénytelen sok fejlesztetőt tartani, akik néha a lábukat lógatják, néha pedig megszakadnak a munkától.
6) Emiatt a projekt költsége is tervezhetetlen.
7) A tervezhetetlenség és a lehetséges „nem várt igények” miatt minden szinten jelentős tartalékot kell képezni időben és költségkeretben.
Mi lehet a megoldás?
1) Információ áramlás és transzparencia
Ez tűnik a legegyszerűbbnek, de ez a legnehezebb.
Én mindig ügyelek arra, hogy a dolgaimról egy, és csakis egy report/beszámoló/prezentáció legyen. Ugyanazt a report-ot mutatom meg a vezetőségnek, a főnökömnek, a beosztottaimnak illetve az alattam lévő szintnek. Mindenki ugyanazt az információt kapja, ugyanazt az információt látja. (Kivéve persze az érzékeny információkat)
(Single voice of truth)
Egy és csakis egy hibakezelő rendszer van, egy és csakis egy helyen követjük az új fejlesztési igényeket.
Ezáltal mindenki tisztában lesz vele, hogyan állunk. Nem fordulhat elő, hogy mondjuk a fejlesztők lazsálnak, de a vezetőség szerint rosszul halad a projekt.
2) Agilis fejlesztés
Ha tervek helyett az ügyfél igényeire figyelünk, akkor az ostorcsapás effektus eltűnik. Valaki azt is mondta, hogy nagy projekteket csakis agilisan lehet csinálni – na pont ezért.
3) Rövid ciklusidő
Az agilis fejlesztés egyben rövid ciklusidőt is jelent, de azért ezt a pontot külön kiemelném. Nem kell feltétlenül eldobni a tervezést, de a ciklusidő legyen rövid. Egy iteratív fejlesztés tervezhető is, és a beeső „nem várt” igények elhelyezhetőek anélkül, hogy plusz erőforrásra lenne szükség.
4) Erősebb projektvezetés
A fenti hatásokat jelentősen tudja csökkenteni, ha egy erős kezű és tapasztalt projektvezető áll a projekt élén, aki nemet tud mondani. Aki nem áldozza fel a projektjét a vezetőségnek való megfelelés oltárán. Aki behúzza a féket ha váratlan igények jönnek, de aki arra is ügyel, hogy az alvállalkozóknak folyamatosan legyen mit csinálni.
(A válságokat nem tolja le a következő szintre hanem megoldja)
5) Ügyfél igény alapú tervezés helyett erőforrás alapú tervezés
Ezt én még sosem csináltam, de másoknál láttam és működött. Az autógyárak is használják ezt a módszert. Tehát a gyár termelési tervét nem az aktuális igényekhez igazítják, hanem azt mondják, hogy ennyi emberrel és ennyi műszakkal ennyi autót tudunk gyártani.
IT-ban ez úgy tud kinézni, hogy kiszámoljuk, a fejlesztő csapat az adott körülmények között havonta átlagosan hány kérést tud fejleszteni, és azt mondjuk, hogy a havi keret 20, ennyit fogadunk, ennyivel tessék tervezni. Előre ki lehet tölteni, hogy mi az a 20, ha beesik valami váratlan akkor ki lehet cserélni a listában valamivel, de az a lényeg hogy a lista sosem több mint 20 elemű. (Nyilván komplexitással is kell számolni, de most egyszerűsítettem)
Ha pedig az ügyfélnek rendszeresen 20-nál több kérése van, akkor azt ő is látni fogja és át tudja gondolni a helyzetet. (Például többet fizet hogy több fejlesztő legyen)
(Megjegyzés: talán nem véletlenül, de ez nagyon hasonlít ahhoz, hogy az ügyfélnek nem feature-öket hanem story point-okat adunk el.)
Utolsó kommentek