Transformacja do Przemysłu 4.0 jako program projektów, część 2

510

W pierwszej części artykułu pokazano, dlaczego transformacja do poziomu technologicznego Industry 4.0 (I4.0) linii produkcyjnej, bądź nawet całej fabryki zostanie najskuteczniej przeprowadzona jako program projektów. Podano szereg argumentów przemawiających za wykorzystaniem którejś z kilku dostępnych w tym zakresie metodyk programów projektów, czyli wypracowanych podczas tworzenia wielkich infrastrukturalnych przekształceń, najskuteczniejszych, kompleksowych zasad postępowania prowadzących do sukcesu.

Jeśli poprzedni artykuł osiągnął zamierzony cel i została przedstawiona ogólna struktura transformacji, wraz z wyszczególnieniem zakresu i typów projektów transformacyjnych, a przede wszystkim reguły umożliwiające dostarczenie założonych korzyści, to teraz zasadnym jest przemyślenie dojścia do skutecznej strategii transformacyjnej oraz zastanowienia się nad wyborem metodyki prowadzenia poszczególnych projektów w programie. Na tym właśnie skupimy się teraz: jak przygotować najlepszą strategię transformacyjną i które metodyki prowadzenia projektów, najsprawniej ten cel zrealizują. Z powyższym pytaniem wiąże się jedno z kluczowych wyzwań dla powodzenia transformacji: jak wyzwolić w uczestnikach tego procesu chęć dzielenia się wiedzą i poczucie czynnego uczestnictwa oraz faktycznego sprawstwa?

Artykuł ten będzie więc próbą pokazania dostępnych metodyk oraz sposobów angażowania uczestników procesu transformacyjnego, dzięki którym stanie się możliwy partnerski udział wszystkich interesariuszy i pełne wykorzystanie ich doświadczenia oraz know-how. [1] Przed wprowadzeniem proponowanych pojęć warto zastanowić się nad możliwymi przeszkodami, na które uczestnicy transformacji mogą natrafić. [2]

Cele transformacji cyfrowej

Aby lepiej zrozumieć jakie ograniczenia występujące w danej fabryce mogą zaszkodzić transformacji, przypomnimy najpierw co jest jej spodziewanym efektem. Otóż dwoma, chyba najbardziej istotnymi skutkami wdrożenia RAMI4.0 (a więc I4.0) ze zdefiniowaną w modelu integracją wertykalną i horyzontalną całego ekosystemu fabrycznego będzie:

  1. Zintegrowany łańcuch wartości oparty na wdrożeniu dla każdego poziomu fabryki, od zaopatrzenia, przez produkcję, po logistykę, CPS-ów (autonomicznie działających maszyn wyposażonych w systemy eksperckie – AI, będących online dzięki IIoT) jako linia technologiczna dających cały system – CPPS, czyli zautomatyzowany, adaptatywny i zdecentralizowany system produkcyjny, którego produkt będzie również dostępny online, dzięki IoT, czyli obejmujący również używalność przedmiotu oraz jego cykl życia.
  2. Implementacja oprogramowania nadzorującego, kontrolującego, dostarczającego wiedzę, monitorującego i scalającego cały ekosystem fabryczny – systemy klasy ERP (wraz z analityką), rozproszonych (w znaczeniu wdrożenia na wielu halach produkcyjnych/liniach produkcyjnych) systemów MES oraz SCADA. Te systemy będą musiały zarazem wykorzystywać zaawansowane algorytmy przetwarzania gigantycznych strumieni danych, które ekosystem fabryczny i jego produkty aktualnie wytwarzają i już wytworzyły. [3] Takie wdrożenie wymaga ściśle współpracujących ze sobą, multidyscyplinarnych zespołów specjalistów z różnych dziedzin i obszarów (robotyka/automatyka, IT, data science, uczenie maszynowe, wdrożeniowcy systemów – zarówno IT, jak też CPS/CCPS, techników itd.). Wymaga posiadania lub wdrożenia w organizacji kultury multi-operacyjnej, w więc takiej w której informacja przepływa pomiędzy ludźmi (i pomiędzy systemami), a całość opiera się na stałej, partnerskiej wymianie informacji.

Przeciwieństwem takiego stanu rzeczy, pozytywnego zjawiska multi-operacyjności, są zjawiska występujące w wielu fabrykach, czy szerzej, w dużych organizacjach, zwłaszcza takich w których występuje struktura hierarchiczna, z mocnym poczuciem przynależności do danego działu, departamentu, ogólnie jakiejś wybranej części organizacyjnej firmy. Tym zjawiskiem jest mentalność silosowa. [4]  Równolegle mogą, choć nie muszą, występować silosy technologiczne.

Silosy technologiczne

Zatem gdzie mogą wystąpić silosy i jak się objawiają? [5]

  1. Na poziomie hali/linii produkcyjnej. Tam, gdzie wśród ogromnej liczby maszyn, automatów produkcyjnych, ich podzespołów, zarządzających nimi sterowników, kontrolujących ich stan czujników, nie występuje wymiana informacji. Po części może to wynikać z tego, że urządzenia korzystają z różnych protokołów komunikacyjnych, lub były implementowane przez różnych dostawców, z wykorzystaniem różnych technologii. Powstają w ten sposób wyizolowane technologicznie obszary, których wzajemna komunikacja jest ograniczona. [6]
  2. Silosy mogą pojawić się także na poziomie działów i pionów operacyjnych, jako skutek technologicznych braków w zakresie współdzielenia danych i dostępu do nich np. z poziomu systemów klasy ERP, czy MES. Może to wynikać z braku przepływu danych na poziomie hal produkcyjnych, lub innych jednostek organizacyjnych firmy i wynikającej stąd niedostępności danych w czasie rzeczywistym. Jest to bardziej rozbudowana forma izolacji technologicznej, opisanej w punkcie pierwszym. Dodatkowo pojawia się istotny z punktu widzenia operacyjnego i zarządczego brak przepływu kluczowych dla funkcjonowania biznesu informacji. [7]
  3. Brak przepływu informacji, wiedzy, dobrych praktyk pomiędzy poszczególnymi działami firmy. Może to wynikać np. z chęci strzeżenia swojego know-how, pilnowania tajemnicy przedsiębiorstwa, naruszania zakresu kompetencji, niechęci do dopuszczenia „laika” do wiedzy, której i tak nie zrozumie itp. Wytwarzają się wtedy zamknięte „światy” inżynierów, techników, sprzedaży, marketingu, IT, finansów, HR itd. Jeśli ten problem nie wynika z braku wspólnego repozytorium/źródła wiedzy, to jest to kwestia wprowadzenia istotnych zmian w kulturze organizacyjnej, w podejściu do zasad współpracy i ważności wykorzystania doświadczenia wszystkich uczestników życia organizacji, ostatecznie jest to istotna kwestia wyzwolenia się z mentalności zamkniętych, niezależnych silosów i przejścia na otwartą kulturę współpracy i wzajemnego szacunku. Wydaje się, że wyłącznie w taki sposób wyzwoli się potężny potencjał tkwiący w doświadczeniu i know-how wszystkich pracowników, który umożliwi współpracę oraz skuteczną transformację do I4.0.

Czy samo rozporządzenie, decyzja, że pracownicy mają ze sobą współpracować jest wystarczające do zainicjowania kultury multidyscyplinarnej wymiany i współpracy? Na pewno nie. Proces świadomego zarządzania zmianą powinien rozpocząć się już na etapie przygotowania strategii. Przez strategię należy rozumieć ogólną, długoterminową sekwencję działań, dającą jako swój wynik osiągniecie zamierzonych celów.

Formułowanie strategii

Można wskazać dwa sposoby podejścia do formułowania strategii: planistyczny i inkrementalny. Pierwszy z nich charakteryzuje się podejściem top-down. Cele biznesowe, wizja, misja są formułowane przez zarząd i wyższą kadrę menedżerską. Wynik pracy tego grona jest następnie zapisywany jako gotowy plan, który zostaje wdrożony i rozpisany na etapy projektowe w poszczególnych komórkach organizacyjnych firmy, gdzie powstają konkretne, szczegółowe taktyki działania i plany operacyjne. Wszystko zostaje w sztywny sposób podporządkowane pod zaprojektowany na długie okresy budżet, zostaje sformalizowane oraz usystematyzowane. [8] Zatem wiedza o ogólnym celu, terminie jego wykonania, ramowej koncepcji „spływa” z góry. Jest to podejście planistyczne.

Drugi sposób konstruowania strategii łączy w sobie podejście top-down z bottom-up. Z jednej strony strategia powstaje w poszczególnych jednostkach biznesowych (bottom-up), po wcześniejszym nadaniu przez zarząd ogólnych ram/wizji (top-down). Dopiero tak przygotowana strategia uzyskuje finalną akceptację zarządu i staje się planem działań długoterminowych. Strategia zostaje przygotowana w sposób zdecentralizowany, gwarantując w ten sposób zaangażowanie i wkład koncepcyjny ze strony wszystkich pracowników. Staje się ona dziełem wszystkich interesariuszy, którzy od początku są w nią wdrożeni, stając się jej współautorami. Przy czym projekty w ramach tak przygotowanej strategii oraz ona sama są cyklicznie weryfikowane oraz zmienianie, gdy tylko pojawią się lepsze opcje rozwoju. Jest to podejście inkrementalnego kreowania strategii. [9] Jest ona tworzona wspólnie, przez cały zespół: realną wartość ma wkład wiedzy i doświadczenia pochodzący od każdego członka zespołu.

Zatem tak z pozoru prosta decyzja, jak przekazanie części swoich uprawnień do budowania strategii, po części również części obszaru decyzyjnego zarządu i top managementu firmy, może wyzwolić już na początku transformacji wielką kreatywność członków zespołu i zachęcić do angażującej współpracy. Na pewno też strategia budowana inkrementalnie pozwoli uchwycić obszary, w których organizacja posiada ograniczenia, silosy technologiczne i mentalnościowe. Będzie też pierwszym krokiem do ich przezwyciężenia. [10] Pozwoli wraz z innymi narzędziami [11] analizy strategicznej w pełni wykorzystać know-how tkwiące w organizacji.

Teoria ograniczeń

Przygotowanie dobrej strategii, to dopiero początek pracy nad transformacją organizacji do I4.0.  W przypadku tak złożonego przedsięwzięcia jak program projektów złożony w rzeczywistości z wielu, nierzadko realizowanych równolegle projektów [12], bardzo istotna jest skuteczna organizacja pracy i efektywna synchronizacja zasobów, które w rzeczywistości są limitowane. Ważny jest więc dobór takiego sposobu pracy, który zagwarantuje ich skuteczne wykorzystanie. Jednym z takich rozwiązań jest teoria ograniczeń (Theory of Constrains – TOC). Zobaczymy też jak TOC [13] wraz z wdrożeniem łańcucha krytycznego może pozytywnie wpłynąć również na wykorzystanie potencjału i kreatywności zespołów.

TOC opiera się na prostej i oczywistej konstatacji: ograniczenie wpływa na pracę całego systemu i bezpośrednio przekłada się na jego wydajność. Takim ograniczeniem jest zawsze zasób niezbędny do przeprowadzenia jakiegoś elementu procesu, który jest niezastępowalny, lub trudno zastępowalny i musi zostać wykorzystany również w innym procesie, którego rozpoczęcie jest uzależnione od jego dostępności. Zatem ograniczenie jest rodzajem „wąskiego gardła”, które wpływa hamująco na możliwość wykonania danej sekwencji czynności. Na przykładzie firmy może to być liczba dostępnych specjalistów IT, inżynierów, robotyków/automatyków itd., którzy mogą wykonać w danym czasie tylko pewną ilość zadań, w zestawieniu z daleko większym zapotrzebowaniem na ich pracę, czy ilość maszyn/linii produkcyjnych które w jednym czasie mogą podlegać procesowi transformacji do I4.0 (modyfikacji, bądź wymiany), w zestawieniu z oczekiwaniem przystosowania do nowych, bardziej optymalnych zasad produkcji I4.0 większej mocy produkcyjnych w jednostce czasu. Na innym przykładzie, wziętym z życia codziennego – ograniczeniem szybkości przemieszczania się grupy piechurów, jest prędkość najwolniejszego z nich.

Wskazanie ograniczenia w danym procesie jest tylko zdroworozsądkowe. Dalsze wnioski i propozycje wynikające z TOC, czynią ją szczególnie przydatną przy dużych projektach i programach projektów. Co proponuje się zatem w jej ramach? Jest to „algorytm” działania złożony z pięciu punktów:

  1. Identyfikacja ograniczeń/wąskich gardeł.
  2. Udrożnienie, a więc takie zaplanowanie pracy w projekcie i programie projektów, aby zasób stanowiący ograniczenie pracował z maksymalną wydajnością.
  3. Podporządkowanie pracy i działania innych uczestników projektu i zasobów niekrytycznych pod rytm pracy zasobu stanowiącego ograniczenie.
  4. Wzmocnienie ograniczenia, a więc poprzez serię decyzji zarządczych i organizacyjnych, a nawet w szczególnych sytuacjach np. zatrudnienie brakującego specjalisty, przełamanie ograniczenia i zminimalizowanie jego możliwego negatywnego wpływu na projekt, lub na program projektów.
  5. Powrót do punktu pierwszego, czyli ustawiczne monitorowanie ograniczeń/wąskich gardeł, stałe usprawnienia działania całej fabryki, czy w naszym przypadku procesu transformacji do I4.0. [14] Takie podejście już na starcie transformacji, a także podczas całego jej trwania jest skoncentrowane na optymalizacji pracy, usuwaniu przeszkód i najlepszym wykorzystaniu zasobów firmy. Dodatkowo należy zwrócić uwagę, na to że w TOC preferowany jest tzw. model pracy ”zorientowany na przerób” i odejście od struktury silosowo-kosztowej. [15] W przypadku struktury silosowo-kosztowej celem projektu jest efektywność kosztowa: poprawa efektywności, lub redukcja kosztów. Również projekty wykonuje się efektywnie kosztowo, a to znaczy że zasoby w nich użytkowane są podporządkowane maksymalnie efektywnemu wykorzystaniu. Może to polegać np. na jak największym obciążeniu pracą, maksymalizacji ilości wykonywanych działań jednocześnie, czy redukcję kosztów, która może również prowadzić do redukcji etatów. Celem projektu staje się obniżenie jego kosztu oraz wykazanie dużej efektywności w konkretnym miejscu/dziale firmy, bez uwzględniania nadrzędnego interesu skuteczności całej organizacji. Jest to zarazem jedna z możliwych przyczyn powstawania silosów, skutecznych lokalnie struktur, hamujących jednak rozwój całej organizacji. Mamy tu też uczestników projektów, którzy wykonują wiele zadań, są przerzucani od zadania do zadania, zgodnie z lokalnymi potrzebami, nie mającymi faktycznie czasu na skuteczną, konstruktywną pracę.

Przeciwieństwem tego jest model proponowany przez TOC – model nastawiony na „przerób”, czyli taki w którym cała firma koncentruje się na osiągnięciu celów strategicznych, wspólnych dla wszystkich uczestników transformacji. Zatem przestają się liczyć efektywność danego działu, jednostki organizacyjnej, a liczy się wynik całości przedsiębiorstwa. Wtedy staje się możliwe np. podnoszenie kosztów w jednym miejscu (w miejscu, w którym występują ograniczenia/wąskie gardła), jeśli przekłada się to na wynik całości, realizację celów całej firmy, czyli zwiększenie „przerobu”. Takie podejście w zarządzaniu firmą i w zarządzaniu projektami (i programem projektów transformacyjnych do I4.0), powoduje transparentność całej organizacji, skuteczny przepływ know-how w całej firmie oraz generuje atmosferę współpracy. Z drugiej strony eliminuje silosy i związaną z nimi mentalność silosową.

Zarządzanie projektem i programem projektów

Kolejnym krokiem organizacyjnym który wiąże się z TOC jest zarządzanie projektem/programem projektów (czy całą założoną w organizacji transformacją do I4.0) poprzez łańcuch krytyczny. Łańcuch krytyczny jest po prostu zastosowaniem TOC do zarządzania projektami.

Jeśli weźmiemy pod uwagę, to że łańcuch krytyczny pozwala przezwyciężyć bolączki występujące w klasycznych metodykach zarządzania projektami,[16] oraz zwiększyć zaangażowanie każdego uczestnika projektu poprzez nastawienie na sukces całej organizacji, likwidację silosów i idącą za tym większą transparentność oraz otwartość organizacji na przepływ informacji, pomysłów itd., to łańcuch krytyczny staje się kolejną ważną metodą, której wdrożenie przy transformacji do I4.0 jest wysoce pożądane.

Przyjrzyjmy się, dlaczego tak jest. W łańcuchu krytycznym minimalizacji wymienionych wcześniej zagrożeń [17] dokonuje się poprzez zastosowanie następujących zasad postępowania:

  1. Wyznaczenie ścieżki krytycznej [18] dla projektu, czy jak w przypadku transformacji do I4.0 dla całego programu projektów.
  2. Redukcja czasu na wykonanie wszystkich zadań do 50% zakładanego pierwotnie, bezpiecznego czasu wykonania i następnie alokacja tak „zaoszczędzonego” czasu w buforach [19] zasilających i projektu.
  3. Bufor projektu stanowi zapas czasu dla całego łańcucha krytycznego. Zabezpiecza przedsięwzięcie przed ryzykiem opóźnienia. Odróżnia to łańcuch krytyczny od klasycznego planowania wykorzystania czasu w projekcie, gdzie rezerwy czasu umieszczane są na ścieżkach podkrytycznych i w harmonogramach indywidualnych – ten sposób planowania czasu, powoduje jego wykorzystanie na „indywidualne” cele uczestników projektu, a nie na rzecz całego przedsięwzięcia, czyli potencjalnie powoduje szkodę dla celu całej firmy.
  4. Czas alokowany w buforach zasilających zabezpiecza czynności z łańcucha krytycznego przed opóźnieniami w łańcuchu niekrytycznym. Jeśli prace w łańcuchu krytycznym kończą się wcześniej, to tak powstały zapas czasu przesuwa się do innych buforów. Premiuje się w ten sposób i zachęca do wcześniejszego kończenia zadań, projektu, a nawet całego programu projektów.
  5. Każde zadanie jest rozpoczynane tak późno jak to jest tylko możliwe. [20] Unika się w ten sposób wielozadaniowości, traktowanej jako mało wydajna i rozpraszająca forma pracy (wielozadaniowość dopuszcza się w ścieżkach podkrytycznych).
  6. Pracę w projektach wykonuje jak najszybciej i zgodnie z regułą sztafety jej wynik jest od razu przekazywany następnemu zespołowi: liczy się czas wykonania zadania, a nie kamienie milowe.
  7. Łańcuch krytyczny jest dodatkowo zabezpieczony przez bufor zasobów – zawsze wiadomo na jakim poziomie jest wykorzystany zasób krytyczny i w razie zagrożenia jest możliwe, z odpowiednim wyprzedzeniem, wdrożenie planu awaryjnego. [21]W przypadku programu projektów dodatkowo powinny być uwzględnione priorytety poszczególnych projektów, co bezpośrednio przekłada się na identyfikację zasobów krytycznych i ich wzajemnie powiązanie w całym w programie oraz optymalne ułożenie w konstrukcji łańcucha krytycznego poszczególnych projektów i ich pożądanego następstwa.

Mądre i odpowiedzialne wdrożenie łańcucha krytycznego przy transformacji przedsiębiorstwa do I4.0 pozwoli na zminimalizowanie ryzyk wnikających z wąskich gardeł. Jest to perspektywa optymalizacji i skuteczności programu, jako „wiązki” projektów, realizującej wspólny cel, opisany przez strategię. Powróćmy jednak do perspektywy pojedynczego pracownika, ponieważ to właśnie od  ludzi zależy powodzenie całego przedsięwzięcia. [22] Jeśli dzięki dotychczas zastosowanym metodom [23] udało nam się doprowadzić do zaangażowania pracowników, przełamać silosy (przynajmniej w znaczeniu mentalności silosowej), wyzwolić kreatywność i inicjatywę ludzi, a także po prostu zwiększyć komfort pracy, przez jasne ukierunkowanie na wykonanie sekwencji pojedynczych zadań następujących po sobie w dobrze zdefiniowanym porządku i w pełnym osadzeniu w celach firmy (tryb pracy jednozadaniowy vs rozpraszający wielozadaniowy), to jak utrzymać ten stan? Jak utrzymać zaangażowanie w poszczególnych projektach, w codziennej pracy w ramach procesu transformacji? Jak zachęcić do ciągłej kreatywności i dzielenia się wiedzą?

Każdy z projektów występujących w programie będzie złożonym przedsięwzięciem, wymagającym utworzenia multidyscyplinarnych zespołów złożonych z fachowców z różnych dziedzin. Zapewne pomimo tego, że docelowa architektura RAMI4.0 w której będzie działała przyszła fabryka 4.0 jest dobrze określona, to trzeba pamiętać, że jest to „tylko” model referencyjny. [24] Określa wprawdzie pewne, szczegółowe, ramy dojścia do osiągnięcia poziomu I4.0, jednak szczegóły implementacyjne są już zależne od specyfiki branży w której działa przedsiębiorstwo oraz ogromnej liczby czynników, uwarunkowań technologicznych, biznesowych i organizacyjnych samego przedsiębiorstwa, w tym choćby zależy od wyboru dostawcy systemów oraz wielkości implementacji itd.

Praktyka wdrożeniowa i zespoły projektowe

Można spróbować wyobrazić sobie jak od strony projektowej zagwarantować utrzymanie bardzo zaawansowanych norm jakościowych i technologicznych, a z drugiej zapewnić elastyczność pracy, gwarantującą rozwiązanie złożonych sytuacji projektowych.

Na pewno na początku kluczowe jest utworzenie interdyscyplinarnych zespołów projektowych. Taki zespół oprócz specjalistów, powinien posiadać w swoim składzie osoby o uniwersalnych kompetencjach, w tym biznesowych. Projekty powinny mieć dobrze określoną specyfikację produktu/funkcjonalności, która będzie rezultatem projektu. Z uwagi na złożoność i konieczność adaptacji produktu wraz z postępem pracy projektowej, specyfikacja i zarazem powstający rezultat powinien być dopasowywany do aktualnego stadium implementacji oraz problemów jakie ta implementacja wytwarza.

Dopasowanie powinno przebiegać w sposób iteracyjny. W następujących po sobie iteracjach przyrostowo oddawane byłyby kolejne funkcjonalności i etapy gotowego produktu. Każda iteracja powinna kończyć się testem, a także oceną spełnienia norm jakości i zgodności rezultatu z założoną specyfikacją. Na podstawie wytestowanych rezultatów iteracji powstawałaby dokumentacja do danej iteracji projektu. Przy czym prace w danej iteracji byłyby prowadzone zgodnie z priorytetami zawartymi w dokumencie opisującym listę prac/funkcjonalności/produktów danej iteracji, [25] która adaptacyjne ulegałaby zmianie, zgodnie z coraz lepszym dochodzeniem do wiedzy jak osiągnąć finalny produkt i samym osiąganiem finalnego rezultatu/produktu.  Zarazem tak pracujące zespoły projektowe powinny mieć też możliwość samoorganizacji. Jest to związane z tym, że trudności implementacyjne są pokonywane adaptacyjnie i ich rozwiązanie opiera się na zaawansowanym know-how uczestników projektu, więc powinni mieć oni możliwość dopasowania swojej pracy do aktualnych potrzeb w projekcie.

Z drugiej strony zespół dobrych specjalistów, jako grupa osób najbardziej kompetentnych w firmie w danej dziedzinie, wie najlepiej jak osiągnąć cel, czyli powinien się samoorganizować. Przy czym przez samoorganizację należy rozumieć odpowiedzialność za wynik, przy posiadaniu swobody w sposobie jego osiągnięcia. Zespoły w celu osiągnięcia sprawnej pracy powinny być liczebnie nieduże, [26] dzięki temu zostanie usprawniona komunikacja, a kluczowe informacje będą wymieniane szybko, zarówno w zakresie codziennych synchronizacji monitorujących aktualne problemy oraz postęp prac, jak również podczas retrospektyw i podsumowań. Jeśli pojawiłaby się potrzeba utworzenia zespołów większych niż dziesięć osób, pracujących nad jednym zagadnieniem, to praca zostałaby rozdzielona na kilka zespołów, pracujących w strukturze gronowej. [27]

Powyższy opis jest faktycznie opisem działania w metodyce zwinnej (Agile), która wprowadzi do przedsiębiorstwa zaawansowaną adaptatywność, dynamikę, elastyczność oraz interdyscyplinarność, niezbędne do sprostania tak złożonemu przedsięwzięciu, jak każda forma transformacji do I4.0. [28] Z drugiej strony zwinne zarządzanie, daje ogromne możliwości wykorzystania potencjału drzemiącego w pracownikach: to członkowie zespołu, znający cel projektu, sami organizują swoją pracę, tak żeby osiągnąć najlepsze rezultaty, stają się chwilowymi liderami, dzielą się swoim know-how. Zarazem mają poczucie, że jest to zespołowy wysiłek, na który bezpośrednio wpływają jako faktyczni kreatorzy nowego porządku w organizacji i nowych, wręcz rewolucyjnych przemian, jakimi są procesy transformacje fabryki do poziomu organizacyjnego I4.0.

Podsumowanie

W artykule pokazano szereg metod i rozwiązań organizacyjnych, które dobrze przeprowadzone oraz wdrożone w organizacji, mogą wyzwolić w uczestnikach transformacji zaangażowanie, zachęcić do dzielenia się swoim know-how i uczynić faktycznymi uczestnikami procesu przemiany. Jak starano się pokazać, jest to możliwe na każdym etapie procesu zmiany: zaczynając już od momentu przygotowania strategii (inkrementalna metoda budowania strategii), a kończąc na pracy zespołowej w grupach projektowych, opartych na metodykach zwinnych. Powinno być oczywiste, że doprowadzenie przedsiębiorstwa do standardu I4.0, który inherentnie zakłada pełną transparentność zarówno w wymiarze integracji pionowej, jak też poziomej; pełny przepływ informacji wewnątrz firmy i w całym łańcuchu wartości; wymaga też od zespołu pełnego zaangażowania, elastyczności, zwinności i adaptatywności w zakresie stosowania nowych rozwiązań. Po przełamaniu silosów technologicznych i mentalnościowych, stawia wymaganie pełnego otwarcia się na współpracę i współdzielenia wiedzą oraz doświadczeniem. W tym znaczeniu, artykuł (pierwsza i druga część) zarysował możliwe sposoby dotarcia do takiego poziomu organizacyjnego, poprzez przybliżenie kilku narzędzi, które ułatwią osiągnięcie tego celu.

Zobacz również

Transformacja do Przemysłu 4.0 jako program projektów

Przypisy

[1]     Zestaw narzędzi proponowany w artykule nie ma ambicji do wyczerpania możliwych wariantów i typów stosowanych środków do najlepszego wykorzystania know-how interesariuszy. Celem jest tutaj wariantowa prezentacja możliwości i symulacja skutecznego rozwiązania w tym zakresie.

[2]     Skupiamy się tutaj wyłącznie na dwóch elementach, mogących mieć szczególnie istotny wpływ na rozważane zagadnienie – nie bierzemy pod uwagę innych ważnych aspektów procesu zmiany, takich jak problemy ekonomiczne otoczenia zewnętrznego i wewnętrznego (np. pozyskanie środków finansowych na przeprowadzenie transformacji), transformację wielu obszarów firmy: księgowych, finansowych, marketingowych, produkcyjnych, łańcucha dostaw i ich „orkiestrację” w skalowalnych, dobrze opisanych procesach wewnętrznych, zaimplementowanych w infrastrukturze IT. Dobrym przykładem zebrania tych zagadnień jest  artykuł wskazujący główne grupy obszarów, które powinny zostać perfekcyjnie zdefiniowane przy wdrażaniu I4.0, lub artykuł ujmujący problem z perspektywy barier na które może natrafić organizacja przy implementacji I4.0 – nawiązując do terminologii ze wspomnianego artykułu, w naszym tekście pokazane są dwa typy barier, tj. mentalna (tu: mentalność silosowa) oraz technologiczna (tu: silosy technologiczne).

[3]     Wszystkie pojęcia użyte powyżej, tj. RAMI4.0, CPS, CCPS, AI, IIoT, IoT, ERP, MES, SCADA zostały zdefiniowane w pierwszej części artykułu.

[4]     O mentalności silosowej więcej informacji poniżej, w punkcie 3.

[5]     Przykłady silosów na podstawie publikacji, dostęp 22.04.2021.

[6]     Tu jednym z rozwiązań byłyby wspólne protokoły transmisji danych; jednak rozwiązanie tego problemu jest daleko bardziej złożone i zapewne stałoby się jednym z istotnych elementów pracy zespołów projektowych zarządzających zmianą, ryzykiem oraz obszarem IT, wskazanych w poprzednim artykule.

[7]     Problem w dużym stopniu rozwiązuje współdzielenie danych i nowe rozwiązania klasy ERP, rozproszony MES. Zapewne istotne zmiany zostaną wymuszone przez konieczne przemodelowanie infrastruktury IT w zakresie gromadzenia danych, jak choćby wykorzystanie rozwiązań chmurowych i otwarty dostęp do danych (z uwzględnieniem zasad cyberbezpieczeństwa i przydziału ról systemowych), które narzucą nowe, oparte na współpracy sposoby pracy w organizacji.

[8]     Ewa Sońta-Drączkowska, Zarządzanie wieloma projektami, PWE, Warszawa 2012, s. 31–33.

[9]     Ibidem, s. 31–33.

[10]   Proces ten, jak zresztą wszystkie pozostałe związane z zaangażowaniem i wykorzystaniem potencjału tkwiącego w zespole, nie mogą być pozostawione bez kontroli oraz zarządzania. Zapewne taka transformacja jak wprowadzenie I4.0 w organizacji będzie wspierana przez np. zespół zarządzania zmianą, który będzie stosował, którąś ze skutecznych, sprawdzonych metodyk zarządzania zmianą, taką jak np. ADKAR (akronim od Awareness,  Desire, Knowledge, Ability, Reinforcement), gdzie już w samej nazwie metodyki jako kluczowe pojawiają się świadomość istotności zmiany wykształcona w zespole oraz chęć jej wprowadzenia przez zespół – antycypujące fakt, że bez ludzi, ich czynnej postawy, proces wdrażania zmiany będzie zagrożony. W tym artykule, celem jest pokazanie transformacji z perspektywy programu projektów oraz narzędzi projektowych, więc temat zarządzania zmianą zostaje pominięty.

[11]   Na pewno do takich podstawowych narzędzi, których wykorzystanie jest zasadne w przypadku każdej transformacji do I4.0 należy analiza SWOT (skrót od czterech obszarów analizy: silne strony – strenghts, słabe strony – weaknesses, szanse – opportunities, zagrożenia – threats) oraz np. analiza PEST, czyli metoda makroekonomicznego badania otoczenia firmy (obejmująca czynniki: polityczne – political, ekonomiczne – economic, społeczno-kulturowe – social, technologiczne – technological). Analiza SWOT powinna objąć oddzielnie całą firmę jako jeden „organizm” oraz poszczególne komórki organizacyjne. Te dwa typy analizy, powinny zostać uzupełnienie analizą zasobów oraz analizą scenariuszy, która jest metodą tworzenia różnych schematów zdarzeń, wraz z prawdopodobieństwem ich wystąpienia. Z pewnością narzędzi wspierających budowanie strategii, które mogą być wykorzystane jest znacznie więcej i powinny być dostosowane do szczegółowych potrzeb transformowanej organizacji. Przykładowa lista 42 metod analizy/zarządzania strategicznego znajduje się tutaj, jednak z pewnością nie wyczerpuje tego ciekawego zagadnienia.

[12]   W pierwszej części artykułu pokazano możliwą listę projektów w programie.

[13]   TOC w podstawowej wersji odnosi się do procesów produkcyjnych i dystrybucyjnych. Została również skutecznie zaadoptowana w pracy w środowisku wieloprojektowym i ta wersja teorii ograniczeń jest opisana w tym artykule.

[14]   Opis pięciu punktów TOC za Ewa Sońta-Drączkowska, Zarządzanie wieloma projektami, op. cit, s. 89 oraz publikacją “Teoria ograniczeń”, dostęp 27.04.2021.

[15]   Porównanie dwóch modeli („nastawiony na przerób” i siloswo-kosztowy za: Ewa Sońta-Drączkowska, Zarządzanie wieloma projektami, op. cit, s. 89 – 91.

[16]   Takich jak PMBok, czy Prince2, w których występuje np. zjawisko odkładania zadań na ostatnią możliwą chwilę wykonania (syndrom studenta, czy wykonywanie pracy w całym przewidzianym na nią czasie, nigdy krócej (prawo Parkinsona). Ponadto uczestnicy projektów zarządzanych w tych metodykach, zawsze czekają na swój termin, czyli działają zgodnie z harmonogramem i kamieniami milowymi. Jest to skutek tego, że nie jest tu premiowane szybsze zakończenie projektu, czy etapu projektu. Te niewątpliwe bolączki usuwa metoda łańcucha krytycznego i TOC. Artykuł ze względu na swoją mocno ograniczoną wielkość nie pozwala wprowadzić szczegółów dotyczących PMBoka i PRINCE2. Jednak na stronach twórców tych metodyk znajduje się wyczerpujący zasób informacji. Również bardzo dobrym wprowadzeniem w tematykę metodologii projektowej i metodyk projektów jest książka: Metodyki i standardy zarządzania projektami (2017), praca zbiorowa pod redakcją naukową M. Trockiego, PWE, Warszawa, gdzie PMBok jest opisany na stronach 99-144, PRINCE2 s. 145-168.

Zarówno PMBok jak też PRINCE2 są metodykami przygotowanymi w oparciu o tzw. model kaskadowy (Waterfall) prowadzenia projektów, który charakteryzuje się tym że: 1. projekt ma zawsze precyzyjnie określoną ilość etapów, zgodnie z przygotowaną wcześniej specyfikacją, 2. każdy etap musi się zakończyć określonym produktem, 3. przejście do następnego etapu odbywa się po zakończeniu wcześniejszego etapu, po uprzednim potwierdzeniu zgodności produktu ze specyfikacją, 4. nie ma sprzężenia zwrotnego pomiędzy etapami, 5. wyniki projektu są zgodne ze specyfikacją przygotowaną na starcie projektu (Ibidem, s. 81).

Innym popularnym modelem prowadzenia projektu jest model iteracyjny (przyrostowy, ewolucyjny). Ten model charakteryzuje się podobnie jak waterfall sekwencyjnością realizacji projektu. Jednak różnice w modelach są istotne. 1. W modelu iteracyjnym są dopuszczalne zmiany w planie/specyfikacji na etapie realizacji (gdy w m. kaskadowym są niepożądane). Zmiana na lepsze rozwiązanie jest niejako wpisana w normalny tryb pracy w m. iteracyjnym; 2. Dopuszcza się cofanie do wcześniejszych etapów i modyfikacje już gotowego produktu; 3. Postęp pracy odbywa się w iteracjach, osiąganie wyników w sekwencjach, (np. kilka iteracji sekwencji: specyfikacja, realizacja, integracja); 4. W każdej iteracji osiąga się lepszy produkt, coraz większą wiedzę o nim i coraz większą zgodność z oczekiwaniami zleceniodawcy; 5. Finalna dokumentacja projektowa powstaje na bazie wypracowanego w kolejnych iteracjach produktu; 6. Dopuszczalna jest wariantowość, aż do chwili znalezienia najlepszego rozwiązania (Ibidem s. 88-89). Na modelu iteracyjnym opierają się metodyki zwinne (Agile), np. Scrum, Kanban, Scrumban, Iterative Development. O metodykach zwinnych mówimy w dalszej części artykułu.

[17]   Brak komunikacji, silosy, wielozadaniowość (jednoczesne przeciążenie zbyt wielką ilością zadań zasobu krytycznego), czekanie na ostatnią chwilę z wykonaniem zadania itd.

[18]   Ścieżka krytyczna jest najdłuższą w projekcie listą zadań, ułożonych w ten sposób, że następne może się rozpocząć dopiero po zakończeniu poprzedniego. Jest to zatem najkrótszy czas trwania projektu. Opis na bazie publikacji, dostęp 27.04.2021.

[19]   TOC dla systemów produkcyjnych jest opisywana przez bufor (buffer), werbel (drum) oraz linę (rope). Werbel, czyli zasoby krytyczne (wąskie gardła) nadaje rytm pracy, bufor to zapas materiałów, natomiast lina jest najbardziej efektywnym sposobem dostarczania zbuforowanych materiałów, wyznaczanym przez rytm ”werbla”.

[20]   Stosowana jest więc zasada ALAP (as late as possible), inaczej niż w klasycznym zarządzaniu projektami, gdzie obowiązuje ASAP (as soon as possible).

[21]   Zasady łańcucha krytycznego przedstawione na bazie: Nowoczesne zarządzanie projektami (2012), praca zbiorowa pod redakcją naukową M. Trockiego, PWE, Warszawa, s. 186-188.

[22]   Rzecz jasna przy założeniu, że są spełnione inne kryteria o których była mowa w tym artykule i poprzednim, takie jak np.: zapewnienie źródeł finansowania transformacji, zaplecze i rozbudowana świadomość technologicznej firmy, know-how w zakresie automatyki/robotyki, IT (ERP, MES SCADA itd.), AI, ML (machine learning) itd.

[23]   Nie zakładamy, że są to jedyne metody oraz że muszą wystąpić w każdej organizacji w takim układzie jak opisany w artykule. Raczej należy traktować je jako rekomendacje, sugestie natury zarządczej, które, jeśli zostaną poprawnie wdrożone, z pewnością przyniosą opisane efekty.

[24]   Widać to choćby na przykładzie norm wskazanych w RAMI4.0. Np. IEC 62264  (International Electrotechnical Commission) zawierające skuteczne oraz przydatne know-how pokazujące jak zrealizować pionową integrację i transparentność przepływu danych w przedsiębiorstwie. O tym mówi już wstęp do IEC 62264-1: celem normy jest „to increase uniformity and consistency of interface terminology and reduce the risk, cost, and errors associated with implementing these interfaces. The standard can be used to reduce the effort associated with implementing new product offerings. The goal is to have enterprise systems and control systems that inter-operate and easily integrate.” – publikacja na tej stronie, dostęp 28.04.2021. Z modelu, który zawiera norma dowiemy się jak powinien przebiegać proces wymiany informacji np. pomiędzy systemami SCADA, MES i ERP, jednak szczegółowa implementacja, będzie już specyficzna dla danej fabryki.

[25]   A więc odpowiednik „backlogu” danej iteracji. Lista prac iteracji (backlog) powinna być w pełni powiązana z łańcuchem krytycznym programu. Sposobem dostosowania rezultatów i czasu wytwarzania rezultatów w poszczególnych iteracjach do łańcuchakrytycznego byłaby zmiana wielkości poszczególnych buforów.

[26]   Praktyka metodyki Scrum wskazuje, że najlepsze są zespoły dziesięcioosobowe, lub mniejsze. Dostęp 28.04.2021.

[27]   Za Metodyki i standardy zarządzania projektami (2017), op. cit., s. 231-232.

[28]   Należy wziąć pod uwagę, że obecne status quo projektowe w wielu fabrykach, to dominacja metodyk prowadzenia projektów w modelu kaskadowym. Zapewne jest tak, że do wielu projektów takie metodyki są wystarczające, a koszt wdrożenia, którejś z metodyk zwinnych może wydawać się nieuzasadniony, lub bariera wejścia w postaci braku wiedzy, zbyt przytłaczająca. Powyższy wątek wprowadza jednak temat wykraczający poza cel niniejszego artykułu, tzn. problematykę zwinnego zarządzania projektami w dużych przedsiębiorstwach. Istnieje tutaj kilka gotowych rozwiązań, sprowadzających się do skalowania zwinności (elastyczności i adaptacyjności) do poziomu całej organizacji. Celem tych technik jest wyeliminowanie tworzenia się „wysp”, odizolowanych małych obszarów zwinności (zespoły zwinne, przypomnijmy są małe, maksymalnie dziesięcioosobowe, aby spełnić wymaganie samoorganizacji oraz swobodnej komunikacji) i budowanie zwinności w całym przedsiębiorstwie – zwinne przedsiębiorstwo. Takie techniki/frameworki to np. Scaled Agile Framework, Large Scale Scrum, Disciplined Agile Delivery, LeadingAgile, Scrum Lean in Motion. Ich opis można znaleźć np. w: Zwinne zarządzanie projektami w dużych organizacjach (2020), praca zbiorowa pod redakcją naukową Pawła Wyrozębskiego, SGH Oficyna Wydawnicza, Warszawa, s. 27-77. Z uwagi na to, że wdrożenie zwinności na poziomie całej organizacji jest procesem trudnym, powstają również metodyki przekształcające i wdrażające zwinność w przedsiębiorstwie: np. Ibidem s. 89-96, gdzie zaprezentowany jest „autorski model metodyki transformacji” opierający się na następujących elementach: 1. badanie potencjału organizacji, 2. kreowanie umiejętności zwinnych, 3. wybór metodyki zwinnej w pilotażu, 4. wybór frameworku do przeprowadzenia transformacji, 5. faktyczne wdrożenie zmian w strukturze organizacyjnej, 6. transformacja IT, 7. roll-out w pozostałych obszarach.