Zarówno działy biurowe Toyoty, jak i produkcyjne wspierające produkcję, wykorzystują różne rozwiązania informatyczne do usprawniania swojej pracy. Część aplikacji jest szyta na miarę, realizując specyficzne potrzeby fabryki. Zdecydowana większość takich aplikacji jest dostarczana przez współpracujące firmy programistyczne.
Dodatkowo od 2020, w ramach wewnętrznych struktur działa grupa Digital Champions, czyli grupa pracowników z różnych działów, którzy dobrze radzą sobie z narzędziami informatycznymi, oraz są w stanie używać ich do tworzenia automatyzacji pracy w swoich działach. Dzięki temu zaangażowaniu zasobów wewnętrznych, mniejsze rozwiązania są realizowane przez znających specyfikę Toyoty specjalistów, z wykorzystaniem narzędzi pakietu Microsoft 365, szczególnie: Power Apps, Power Automate i Power BI. W ten sposób powstają małe automatyzacje (w myśl filozofii Kaizen), usprawniające między innymi obieg dokumentacji wewnątrz firmy.
Fabryki Toyoty w Polsce
W październiku 1999 r. w Wałbrzychu została założona firma Toyota Motor Manufacturing Poland sp. z o.o. (TMMP), a produkcja została uruchomiona w kwietniu 2002 r. Pierwsze produkty to manualne i półautomatyczne skrzynie biegów oraz silniki spalinowe do samochodów osobowych Toyota.
W marcu 2005 produkcję rozpoczęła druga fabryka TMMP, oddział Jelcz-Laskowice, produkująca silniki. Obecnie łącznie oba zakłady zatrudniają 3000 osób i produkują silniki i skrzynie biegów do około pół miliona pojazdów Toyoty rocznie (Corolla, C-HR, Yaris, Yaris Cross, Aygo, Aygo X), w większości do wersji hybrydowych.
Fabryki są częścią koncernu Toyota, więc kultywuje się w nich tradycję i filozofię koncernu, znaną między innymi z takich koncepcji jak Toyota Way, TPS (Toyota Production System), Lean Manufacturing, PDCA, Kaizen, Kanban.
Scrum w TMMP
Od 2016 r. Toyota Motor Europe, pod którą podlega TMMP, wskazała Scrum jako główny zbiór ram postępowania w projektach informatycznych. Promocja Scrum rozpoczęła się od spotkania z jednym z dwóch autorów The Scrum Guide, Jeffem Sutherlandem, który przedstawiał jak wiele wspólnego ma Scrum z filozofią oraz metodami pracy Toyoty.
Prace grup Digital Champions oparte są o zasady Scrum, z której najważniejszą jest wskazywanie Product Ownera w każdej z inicjatyw. Zgodnie z wytycznymi The Scrum Guide, wspomniany Product Owner (PO) między innymi ponosi odpowiedzialność za definiowanie wymagań oraz maksymalizowanie wartości powstającego produktu. Oznacza to, że osoba pełniąca rolę Product Ownera musi być zaangażowana w projekt, określać swoje wymagania, oraz uporządkować kolejność wykonywanych prac. Nasi Product Ownerzy to osoby, które nadal mają swoje codzienne obowiązki do wykonania, takie jak:
- zarządzanie swoim zespołem,
- realizacja planu produkcyjnego,
- zapewnienie wykonania planów rocznych (firmowych, działowych i indywidualnych),
- udział w spotkaniach.
Jest to więc bardziej dodatkowa rola niż nowe stanowisko.
Zaangażowanie Product Ownera
Jednym ze wydarzeń scrumowych jest Sprint Retrospective, czyli spotkanie mające na celu podnoszenie jakości pracy zespołu, poprzez analizę występujących problemów i szukanie sposobów ich unikania w następnych sprintach. Podczas takich spotkań, dla projektów grupy Digital Champions najczęściej pojawiały się problemy wynikające ze zbyt słabego zaangażowania się PO w projekt, wynikające na przykład z braku:
- czasu na współpracę,
- precyzowania swoich oczekiwań,
- jasnej wizji produktu,
- rozpatrzenia różnych przypadków,
- wzięcia odpowiedzialności.
Analiza powyższych braków zaangażowania Product Ownera w projekt pozwoliła zidentyfikować główne przyczyny źródłowe. Zaliczono do nich:
- brak czasu na działania związane z dodatkowym projektem,
- inne priorytety,
- brak przekonania do projektu,
- praca zmianowa i trudności w ustaleniu wspólnego czasu z resztą zespołu.
Fot. TMMP shopfloorNieudane próby
Podejmowano różne próby wzmocnienia zaangażowania Product Ownera w przypisane do nich projekty. Zespół developerski zadeklarował zmianę formy komunikacji z PO. Zamiast wysłać maila i czekać na jego lub jej reakcję, zaczęto praktykować rozmowę (najlepiej face to face). Zauważono lekką poprawę, która jednak widoczna była tylko wtedy kiedy komunikacja była bardziej indywidualna. Kolejny raz więc podjęto próbę określenia, po czyjej stronie jest piłka, poprzez ustawianie projektom statusu „oczekuje na reakcję PO”. W dużym uproszczeniu przypomina to system Andon znany z TPS, mający na celu lepszą kontrolę procesu. Niestety to rozwiązanie również nie przyniosło zadowalających rezultatów. Kolejne działania były próbą eskalacji. Pierwszym jej elementem stało się wysyłanie informacji do PO oraz jego przełożonego. Nie działały również tzw. przypominajki i ostatecznie to rozwiązanie również nie zakończyło się sukcesem. Z drugiej strony, podejmowane były próby pozytywnej zachęty, na przykład poprzez nagrody dla najbardziej zaangażowanego PO. Pomysł jednak spalił na panewce, ponieważ nie udało się określić jasnych kryteriów wyznaczania tego najbardziej zaangażowanego. Poza tym, zwyczajnie okazało się, że w grupie po prostu jest kilkoro zaangażowanych i kilkoro niezaangażowanych w tę funkcję osób. Nagrody niczego tutaj nie zmieniały.
Przepis na wzmocnienie zaangażowania PO
Ostatecznie udało się znaleźć rozwiązania systemowe, które przyniosły pożądany efekt, czyli wysokie zaangażowanie PO w projekt. Zadziałano na podstawowy zgłaszany problem, czyli brak czasu. Sposobem na to zostało zapewnienie czasu na realizację projektu poprzez wpisanie go w indywidualne i działowe cele roczne. Takie jasne umiejscowienie projektu pozwala na nadanie mu wysokiego priorytetu, dzięki czemu zyskuje on przewagę (lub choćby równowagę) w odniesieniu do innych celów rocznych. Stopień ich realizacji jest regularnie raportowany przełożonym, co umożliwia dodatkową szansę wykazania się dobrym planowaniem i realizacją priorytetowych prac. Co więcej, stopień realizacji celów rocznych wpływa na indywidualną coroczną podwyżkę pracownika oraz przyznawaną wysokość premii.
Drugim poważnym problemem był brak jasnej wizji dla prowadzonego projektu. Problem ten został wyeliminowany poprzez wprowadzenie dodatkowych obowiązkowych pól w formularzu zgłoszenia projektu (między innymi oczekiwane wymierne korzyści dzięki dostarczeniu projektu). Wykreowało to sytuację, w której projekty bez jasno określonych korzyści nie są realizowane, a wszystkie pozostałe są tymi, w których realizację PO chce się angażować, bo rozumie płynące z nich korzyści.
Ukończył studia informatyczne, medyczne i teologiczne. Od 2006 związany z aplikacjami dla branży Automotive. Początkowo jako programista, potem administrator systemów IT. Obecnie Project Manager i zagorzały promotor Scrum. Ambasador Toyoty w mediach społecznościowych. Potrafi łączyć różne światy: dostawców oprogramowania, przedstawicieli linii produkcyjnej czy działów finansowych.
W wolnym czasie pielęgnuje relacje, ogród oraz próbuje sił na rynku self publishing.