Fazy zasady Pareto i metodologia w harmonogramowaniu produkcji

Jak zostało wspomniane wcześniej, znać problem, a wiedzieć, jak go rozwiązać, to dwie różne kwestie. Bazując na wieloletnim doświadczeniu, moja firma opracowała proces, który nazywamy „80/20”. Choć nie ma wątpliwości, że sama instalacja systemu APS przynosi wiele korzyści firmom produkcyjnym, to jednak nie na tym rzecz polega. To tak jakby zakupić nowe Maserati Quattroporte, aby jeździć nim do sklepu na rogu na zakupy, a na dłuższe trasy korzystać ze starego Forda, starając się dojechać jak najszybciej. Korzyści z integracji systemu APS z codzienną działalnością operacyjną firmy są tak ogromne, że nie ma sensu, aby działać w jakikolwiek inny sposób. I tutaj przydadzą się odpowiednie umiejętności. Proces 80/20 ewoluował z naszego głębokiego przekonania do zasady „80/20”, zwanej często Zasadą Pareto. Dla wszystkich tych, którzy jej nie znają, istotna może być informacją, ze reguła ta może być stosowana w wielu przypadkach, jednak w naszym przypadku zakłada ona, że firma osiąga 80% swoich wyników z 20% wysiłku. Przyjęcie tej zasady na każdym poziomie naszego procesu będzie miało ogromny wpływ na ogólny sukces naszych klientów.

Jednakże przed zastosowaniem zasady „80/20” należy pamiętać o jednym etapie. Jest to proces, który określa dokładnie, co mamy osiągnąć. Proces zmusza nas do przemyślenia sytuacji i jasnego udokumentowania problemu biznesowego, który staramy się rozwiązać, a także do wymienienia wszystkich korzyści, które zostaną osiągnięte w przypadku osiągnięcia sukcesu. Nazywam to fazą oceny. Właściwa realizacja tej fazy, pozwoli na osiągnięcie korzyści, które będą mieć wpływ na strategiczny sukces firmy w stosunkowo krótkim czasie.

Po zdefiniowaniu problemu, zadaniem fazy oceny jest stworzenie klarownej wizji idealnego, długoterminowego rozwiązania. W większości przypadków pozwala popodzielić rozwiązanie na kilka mniejszych faz, zwanych blokami. Pierwszy blok powinien nie tylko dostarczać 80% korzyści, ale również ustanowić infrastrukturę, na której firma zbuduje idealne rozwiązanie.

Pierwszy blok powinien dostarczyć 80% idealnego rozwiązania, choć w rzeczywistości może to być 70% lub nawet 85%. Tak więc przed dostarczeniem pierwszego bloku należy zidentyfikować wszystkie pozostałe bloki. Kiedy w procesie pojawią się nowe problemy lub „możliwości”, zostaną one dopasowane do odpowiedniego bloku, co pozwoli na lepszą kontrolę.

Skontaktuj się z naszym ekspertem

Fazy zasady Pareto

Metodologia „80/20” posiada szereg odrębnych faz:

• Faza oceny
• Faza projektowania
• Faza rozwoju prototypu
• Faza testowania
• Faza wdrażania
• Przegląd powdrożeniowy

Oczywiście nie musisz podążać zgodnie z tym procesem, ale jeśli dysponujesz odrobiną czasu, aby przeczytać kilka następnych rozdziałów, to mam nadzieję, że przekonam cię, że każda faza posiada swój konkretny cel i jest sprawdzonym sposobem na dostarczenie bardzo udanych rozwiązań.

Faza oceny

Każdy pens wydany na fazę oceny zwróci się tysiąckrotnie. W każdym nowym projekcie zawsze bardzo rekomenduję, aby przed rozpoczęciem jakichkolwiek prac klient spędził co najmniej dwa dni, analizując wspólnie z nami, w którym miejscu się znajduje, z jakimi problemami ma do czynienia oraz jakie są jego cele. Przyjmowanie jakichkolwiek założeń na tym etapie może mieć katastrofalne skutki, dlatego ważne jest, aby skonsultować się z kimś, kto wie, jakie pytania zadawać i jakie informacje są istotne. Istnieje ogromna pokusa, aby rozpoczynać prace na bazie założeń oraz nieprzemyślanych rozwiązań, lecz doświadczenie uczy nas, że w harmonogramowaniu nie istnieją całkowicie uniwersalne rozwiązania. A nawet jeśli istnieją, to nigdy nie miałem z nimi do czynienia. Proponowanie rozwiązań, nie znając specyfiki firmy, jej określonych metod pracy, a także problemów biznesowych byłoby absurdalne.

Mój znajomy przypomniał mi ostatnio, że wdrożenie systemu harmonogramowania bez wcześniejszego uzgodnienia celów biznesowych jest skazane na porażkę. Ucieszyło mnie to, że ta opinia nie pochodzi tylko ode mnie i to tylko utwierdziło mnie w przekonaniu, że jest to fundament całkowitego sukcesu projektu i nie ma powodu, aby iść dalej, zanim zagadnienia te nie zostaną ustalone i udokumentowane.

Idealnie byłoby również pomóc zidentyfikować wskaźniki efektywności, które mierzą dany problem i pozwalają na śledzenie jego naprawy.

Po uzgodnieniu celów ogólnych, należy opisać ścieżkę, jaka ma do-prowadzić firmę z miejsca, w którym jest, do miejsca, w które chce do-trzeć. Dokument taki powinien szczegółowo charakteryzować działanie obecnego systemu z wyraźnym opisem jego ograniczeń.

Powyższe informacje pozwolą rozpocząć dyskusję na temat wielu możliwych rozwiązań. Mam tu na myśli taką formułę, że słuchamy i dzielimy się wiedzą o tym, jak inne firmy były w stanie rozwiązań podobne problemy. Zrozumienie tego, co jest realne, wykonalne i prawdopodobne, pomoże obu stronom owocnie przejść przez proces i stworzyć realistyczny plan działania. Chciałbym jeszcze raz podkreślić, że współpraca z partnerem pomoże zaoszczędzić ogromną ilość czasu, wysiłku i frustracji.

Po zbadaniu możliwości, powstałe pomysły zapoczątkują proces krystalizacji klarownej wizji jak będzie wyglądać rozwiązanie biznesowe przeznaczone dla danej firmy.

Rozwiązania powinny być ZAWSZE dopracowane bardzo kompleksowo. Problem biznesowy powinien zaprowadzić nas do wizji tego, jak powinien wyglądać nowy proces.

Wyniki z twojej oceny będą dokumentem, który ogólnie nakreśla cele biznesowe oraz przybliżony zakres proponowanego rozwiązania.

Faza projektowania

Po zakończeniu fazy oceny i podjęciu decyzji o kontynuacji projektu, następnym krokiem jest stworzenie dokumentu opisującego bardziej szczegółowo planowane prace, a także koszty związane z wdrożeniem rozwiązania. Zauważyłem, że wielu klientów szuka rozwiązań z zamkniętym budżetem, które możliwe jest tylko pod pewnymi warunkami.

Po identyfikacji procesów biznesowych konsultant musi określić dane potrzebne do ich wspierania i funkcjonalności wymaganych przez rozwiązanie APS. Ponownie należy podkreślić, że konsultanci powinni po-siadać szczegółową wiedzę na temat mocnych stron i ograniczeń systemu APS, aby mogli jasno określić modyfikacje niezbędne do zapewnienia oczekiwanych wyników.

Na tym etapie, konsultant przygotowuje szczegółowe specyfikacje zmian. Są to dokumenty, który zawierają schemat nowego procesu oraz szczegółowy wykaz wymaganych danych. Idealnie byłoby, aby każdy zestaw danych przechowywany był tylko i wyłącznie w jednym miejscu, dzięki czemu dokument mógłby wskazać źródło danych, osobę odpowiedzialną za utrzymanie źródła oraz, jeśli jest to konieczne, opis algorytmu ich przygotowania.

Schemat powinien klarownie ilustrować sposób przepływu danych między różnymi systemami i metody wymiany danych. Obejmuje to dane, jakie mają być przesyłane z systemu APS do innych systemów, ta-kich jak system ERP lub system sterowania produkcją. Większość prac integracyjnych wymaganych dla działania nowego systemie APS będzie przeprowadzona wokół trzech punktów styku wskazanych na poniższym rysunku.

Oprócz dokumentów specyfikacji zmian mocno polecam opracowanie Mapy Drogowej Harmonogramowania (czasami zwaną też Białą Księgą Harmonogramowania).

Mapa Drogowa Harmonogramowania ogólnie wyjaśnia, w jaki sposób nowy system harmonogramowania wpłynie na każdy z funkcjonalnych obszarów, które współdziałają z systemem harmonogramowania. Jest to bardzo ważne i nie należy pomijać tego punktu, ponieważ sukces systemu zależy od zmiany sposobu wewnętrznej współpracy w firmach. Pominięcie powyższej czynności pozbawi firmę wielkich korzyści płynących z nowego systemu APS.

Mapa Drogowa Harmonogramowania powinna wyjaśniać, w jaki sposób nowy system wpłynie na każdy obszar funkcjonalny, jakie nowe in-formacje będą dostępne dla obszaru i za co obszar będzie ponosił odpowiedzialność. Rzeczywistość jest taka, że większość ludzi boi się zmian, a każda grupa obawia się utraty swojej tożsamości, dlatego konieczne jest ciągłe szkolenie i pomoc, aby w pełni zrozumieć, że korzyści z systemu znacznie przewyższają ryzyko zmian.

Proces tworzenia Mapy Drogowej Harmonogramowania daje każdemu możliwość przedstawienia propozycji i stania się częścią rozwiązania. W ten sposób można uniknąć sprzeciwu, który często się pojawia, gdy kierownictwo po prostu zarządza zmiany. Prawda jest taka, że naj-ważniejszym powodem, przez który systemy harmonogramowania nie sprawdzają się, jest to, że ci, którzy mogą odnieść największe korzyści, nie potrafią zrozumieć potrzeby zmian. Nie rozumieją, co będą z tego mieli, jak to pomoże firmie, dlatego też mają tendencję do robienia rzeczy starymi metodami.

Skontaktuj się z naszym ekspertem

Zadaniem konsultanta jest zapoznanie klienta zarówno ze specyfikacjami zmian, a także z Mapą Drogową Harmonogramowania. I mimo że przejście do fazy rozwoju bez akceptacji wszystkich kluczowych osób jest pozbawione sensu, to może jednak pojawić się konieczność zbudowania prototypu rozwiązania przed zamknięciem etapu analizy wymagań. Jest to lepsza opcja niż „paraliż przez analizę”, który może się pojawić, kiedy ludzie są nie są pewni opcji, jakie mają do dyspozycji. Prototyp ten pozwoli na lepsze zrozumienie tego, w jaki sposób ma działać nowy system.

Projekt systemu musi odzwierciedlać decyzje podjęte w fazie oceny i obok tej właśnie fazy jest to drugi najważniejszy etap projektu. W fazie projektowania klient często naciska, aby zwiększyć funkcjonalność systemu. Pomijając sytuacje wyjątkowe, dodanie większej funkcjonalności powinno być ograniczane, ponieważ zwiększa ryzyko niepowodzenia w projekcie.

Faza rozwoju/prototypowania

Faza rozwoju/prototypowania polega na zaprojektowaniu wstępnego, roboczego modelu nowego systemu z wykorzystaniem zestawu danych testowych. Większość z tych prac wykonywana jest zdalnie i opiera się na specyfikacjach opracowanych w fazie projektowania. Powodem jak najszybszego stworzenia roboczego modelu systemu jest to, że w większości przypadków użytkownicy mają trudności ze zrozumieniem nowego systemu, dopóki nie zaczną z nim pracować. Oznacza to, że użytkownicy nie są w stanie zrozumieć możliwości, jakie mają do dyspozycji, oraz przewidywać potencjalnych problemów, zanim ich nie będą mogli zobaczyć i doświadczyć. Z oczywistych względów rozwiązanie to nie jest idealne, ale jest częścią rzeczywistości związanej z wprowadzaniem zmian. To nie znaczy, że faza projektowania ma być przeprowadzana niestarannie. Jeżeli to możliwe, to każde podejście do wykonania prototypu musi być zrealizowane dobrze za pierwszym razem. Jeśli jednak są problemy, które nie mogą być łatwo rozwiązane, to wymagane może być wykonanie prac programistycznych po to, by przygotować działający prototyp tak szybko, jak to jest możliwe. Tak czy inaczej podobnie jak fazy oceny i projektowania, faza rozwoju powinna być realizowana zgodnie z zasadą „80/20” z naciskiem osiągnięcia podstawowej właściwej funkcjonalności, bez martwienia się o resztę.

Faza testowania

Na ten temat można napisać całą książkę, ale najważniejsze jest, by zrozumieć, że muszą być dwa poziomy testowania. Testowanie jednostkowe zaprojektowane jest do weryfikowania pod-stawowych funkcji oprogramowania. Idealnie byłoby, gdyby testy jednostkowe były zidentyfikowane w specyfikacji projektu. Testowanie zintegrowane przeznaczone jest do testowania funkcjonalności zintegrowanego systemu i wymaga od testera utworzenia udokumentowanego skryptu dla każdego możliwego scenariusza biznesowego, np. co dzieje się z nowym zleceniem, zmodyfikowanym zleceniem oraz z usuniętym zleceniem. Zaleca się, aby użytkownicy byli odpowiedzialni za tworzenie własnych skryptów testowych, ponieważ jest to świetny sposób, aby dowiedzieli się, jak korzystać z nowego systemu i najlepszy sposób na poznanie wszelkich błędów i zapętleń w nowym procesie biznesowym. Każda chwila spędzona na testach CRP (Conference Room Pilot) zwiększą poziom komfortu, a przejście do nowego systemu będzie mniej stresujące. Każdy skrypt powinien określać dane źródłowe, listę czynności do wykonania i oczekiwane wyniki. Testy zintegrowane są zwykle wykonywane w testach CRP. Polega to na tym, że testy systemu są wykonywane w jednym pokoju przez wszystkich użytkowników systemu, gdzie mogą komunikować się ze sobą przez określony czas. Testy CRP trwają zazwyczaj od trzech do pięciu dni. Zalecam, żeby dokumenty skryptów trzymać w luźnych kartkach spiętych w skoroszyt i aby użytkownicy potwierdzali poprawne wykonanie testu i aby udokumentowali problem, kiedy test będzie miał wynik negatywny.

Wynikiem testów CRP jest dokładne określenie tego, co działa popraw-nie, a co wymaga poprawy. Jeśli niektóre problemy nie mogą być rozwiązane w trakcie testu CRP, należy przeprowadzić więcej takich symulacji.

Faza wdrażania

Faza wdrażania rozpoczyna się od planu uruchomienia systemu, na który to plan składają się wszystkie działania, które muszą zostać spełnione, aby wyłączyć z użytkowania stary system i uruchomić nowy. Jeśli jest to możliwe, zaleca się, aby przez jakiś czas używać obu systemów równolegle. Pozwala to na porównanie wyników danych przetwarzanych w nowym systemie z tymi samymi przetwarzanymi w starym. Zazwyczaj podczas fazy wdrażania pojawiają się jeszcze problemy, które nie zostały zidentyfikowane i omówione podczas testów CRP, dlatego ważne jest, aby w pierwszych dniach wdrażania nowego systemu, była do dyspozycji na miejscu osoba, która będzie mogła dopracować system. Tak jak w przypadku testów CRP, plan uruchomienia systemu powinien zostać udokumentowany w postaci szeregu testów lub raportów stwierdzających poprawność działania nowego systemu. Nawet jeśli wszystkie testy zostały przeprowadzone i uważa się, że system został wdrożony, to w dalszym ciągu zaleca się, aby był dostępny konsultant potrafiący obsłużyć zaistniałe problemy, które mogą pojawiać się jeszcze w ciągu najbliższych kilku miesięcy.

Zazwyczaj klient przygotowuje listę problemów, aby śledzić status każdego z nich. Lista zgłoszeń powinna zawierać daty zgłoszenia, nadawane priorytety, przypisane osoby odpowiedzialne oraz status każdego zgłoszenia. Praktyka obsługi zgłoszeń wymaga przeglądania listy co najmniej raz w tygodniu, aż do momentu rozwiązania problemów. Kiedy użytkownicy zapoznają się już z możliwościami nowego systemu, następuje często przypływ twórczych pomysłów związanych z jego wykorzystaniem. Pojawia się natychmiast wielka pokusa dodania nowych funkcjonalności do systemu. Chciałbym jednak przypomnieć o zasadzie „80/20”, która jest ważna w tym miejscu. Najważniejszym priorytetem powinna być koncentracja na stabilności systemu, ponieważ nic tak nie niszczy zaufania do nowego systemu jak niekończący się strumień błędów i problemów. Jeśli jest to możliwe, wszystkie nowe oczekiwania, co do funkcjonalności nowego systemu, powinny zostać zapisane w dokumencie przeznaczonym dla „Fazy 2”. Jest to istotne z dwóch ważnych powodów, po pierwsze każdy ze zgłoszonych przez użytkowników pomysł jest doceniony i uznany za ważny oraz pozwala na analizę postępu procesu wdrożenia. W pewnym momencie konsultant wspólnie z klientem decyduje, czy istnieje potrzeba realizacji „Fazy 2”. Jeśli producent zadecyduje o wdrażaniu „Fazy 2”, należy uzgodnić priorytety zgłoszonych dodatkowych funkcjonalności. Konsultant powinien pomóc stworzyć szczegółowy opis dla każdej modyfikacji systemu, stosując standardowe formaty dokumentów. Format ten określa problem biznesowy, korzyści biznesowe, rozwiązanie, nakład pracy oraz koszty.

W efekcie proces „80/20” rozpoczyna się na nowo. Należy przeprowadzać go systematycznie, aby nie zatrzymać bieżących postępów w pracy.

Autor:  Mike Liddell. Polskie tłumaczenie i prawa autorskie DSR S.A.

Skontaktuj się z naszym ekspertem

Przeczytaj także:

Dlaczego harmonogramowanie jest tak krytyczne?

Siła tworzenia sekwencji

Czy potrzebujemy planowania przy produkcji na zamówienie?