Optymalizacja czasu zadań (crashing)
| Optymalizacja czasu zadań (crashing) |
|---|
| Polecane artykuły |
Crashing- jedna z metod kompresji harmonogramu zadań w projekcie. Polega na przyspieszeniu realizacji zadań w projekcie poprzez uzupełnienie zasobów.
Istota crashingu
Zastosowanie tej metody wpływa na kompresję harmonogramu projektu, który jest zależną czasu realizacji całego projektu. Crashing poprzedzony jest dokładną analizą wszystkich możliwych rozwiązań minimalizujących czas trwania projektu. Zanim skorzystamy z tej metody skracania czasu zadań w projekcie powinniśmy zastanowić się czy metoda jest opłacalna. Alternatywą do Crashingu może być szybka ścieżka realizacji (fast tracking), czyli równoległe wykonywanie działań, które normalnie realizowano by sekwencyjne. Jednak przy Fast Trackingu świadomie ponosi się ryzyko błędnych rozwiązań.
Skrócenie czasu realizacji projektu praktycznie zawsze wiąże się z poniesieniem dodatkowych kosztów. Wynika to zwykle z:
- podwyższonych stawek za nadgodziny pracownicze
- opłatę dodatkową dla podwykonawców za ekspresowe działanie
- zastosowania bardziej i zaawansowanej tym samym droższej technologii wykonania poszczególnych zadań w ramach projektu.
Analiza kosztów przy skracaniu czasu trwania projektu skupia się na zadaniach, które leżą na ścieżce krytycznej projektu, ponieważ tylko wtedy jesteśmy w stanie realnie przyspieszyć realizację projektu. Przyśpieszanie zadań nie znajdujących się na ścieżce krytycznej jest bezcelowe z ekonomicznego punktu widzenia. W ramach ścieżki krytycznej najefektywniejsze jest przyśpieszanie kolejno tych zadań, których optymalizacja jest najmniej kosztowna.
Aktualizacja harmonogramu
Opracowywany na etapie planowania projektu harmonogram zazwyczaj nie służy tylko do ustalenia przewidywanych wartości takich jak termin zakończenia prac czy koszt ich realizacji, lecz również stanowi podstawę do zarządzania i kontroli wykonania planowanego projektu. Jest rzeczą naturalną i trudną do uniknięcia, że w trakcie realizacji projektu zachodzą mniejsze lub większe rozbieżności między planowanymi terminami a faktyczną ich realizacją. Odstępstwa od planu mogą powstać między innymi na skutek:
- problemów kadrowych
- zmiennych warunków atmosferycznych jeśli jest to np. projekt budowlany
- awaryjności maszyn i urządzeń potrzebnych do realizacji projektu
- zmian wielkości planowanych dostępności zasobów
- nieterminowości dostaw materiałów
- brak odpowiednich rezerw finansowych
- zmiany zakresu planowanych prac
- koniecznością wykonania prac poprawkowych
- zmiany warunków wykonywanych prac
- błędów w przygotowanym wcześniej planie prac
- złej dyscypliny pracy
Każde opóźnienie prac powoduje potrzebę zaangażowania dodatkowych środków do ich dokończenia, a to z kolei uniemożliwi rozpoczęcie następnych prac. W takiej sytuacji, chcąc przywrócić pełne pokrycie czasowe, należy zweryfikować przyjęte w planie dane i ponowić analizy a sporządzony na etapie planowania harmonogram stanowi do tego dobry punkt wyjścia.
Potrzeba weryfikacji pojawia się najczęściej w następujących przypadkach:
- konieczność przyspieszenia terminu realizacji całości przedsięwzięcia
- wystąpienie opóźnienia (lub przyśpieszenia) realizacji poszczególnych procesów
- wykrycie usterek w pierwotnej konstrukcji sieci zależności
- błędne określenie czasów wykonania zadań
- zmiana planowanych poziomów dostępności zasobów w trakcie wykonywania prac
- zmiana planowanego zapotrzebowania na zasoby dla poszczególnych prac
- konieczność zmian przyjętych rozwiązań technologiczno-organizacyjnych
W zależności od tego, czy w harmonogramie uwzględniamy analizę zasobów, termin zakończenia poszczególnych procesów może wynikać ze ścieżki krytycznej, lub z ciągu zadań nazywanego łańcuchem krytycznym i ukształtowanego przez ograniczoną dostępność jednego lub kilku zasobów używanych przy realizacji planowanych zadań. W sytuacji, gdy wszystkie poziomy dostępności zasobów zapewniają możliwość realizacji zadań w terminach wynikających z analizy czasu, łańcuch krytyczny i ścieżka krytyczna pokrywają się ze sobą. Jeżeli jednak termin zakończenia przedsięwzięcia po analizie zasobów jest dłuższy od terminu uzyskanego w analizie czasu, oznacza to, że chcąc skrócić taki harmonogram należy najpierw zidentyfikować łańcuch krytyczny i zasoby które stanowią „wąskie gardło”i wydłużają termin zakończenia prac projektowych.
Zastosowanie
{{#ev:youtube|nkvfK8loGH0|480|right|Karta projektu (Sławomir Wawak)|frame}} Kluczem do efektywnego zastosowania Crashingu w projekcie jest maksymalna redukcja prac harmonogramu poszczególnych zadań przy zastosowaniu minimalnej ilości dodatkowych zasobów potrzebnych do optymalizacji tych zadań. Analogicznie jeśli zastosowanie metody staje się nieopłacalne powinniśmy zaprzestać tej praktyki.
Poprawne zastosowanie Crashingu wymaga:
- Stosowania metody dla zadań znajdujących wyłącznie na ścieżce krytycznej
- Stosowania metody w pierwszej kolejności dla zadań, których koszt optymalizacji jest najmniejszy, a następnie dla zadań bardziej kosztownych.
Nie należy kontynuować procesu:
- Jeśli określone zadanie zredukowane zostało do maksimum.
- Jeśli zastosowanie metody jest bardziej kosztowne niż jej niezastosowanie
Bibliografia
- Project Management Institute (2008) Project Management Body of Knowledge 4th edition
- Piotr Zaskórski (2012) Ewaluacja Projektów, Warszawska Wyższa Szkoła Informatyki, Warszawa
- Nita Bartłomiej (2012) Planowanie sieciowe w zarządzaniu kosztami i czasem projektu,"PRACE NAUKOWE UNIWERSYTETU EKONOMICZNEGO WE WROCŁAWIU" Wydawnictwo Uniwersytetu Ekonomicznego we Wrocławiu, Wrocław
- Kozioł Leszek (2000) Determinanty wykorzystania czasu pracy w przedsiębiorstwie Zeszyty Naukowe / Akademia Ekonomiczna w Krakowie, nr 544, s. 19-33, bibliogr. 28 poz.
- Najib Georges, Nabil Semaan, and Joe Rizk (2007), CRASH: AN AUTOMATED TOOL FOR SCHEDULE CRASHING International Journal of Science, Environment and Technology, Vol. 3, No 2,2014,374 – 394
- Komesh Sahu, Meenu Sahu (2014) Cost & Time and Also Minimum Project Duration Using Alternative Method, International Review of Applied Engineering Research. Volume 4, Number 5, pp. 403-412
Autor: Patryk Chęć
