JIRA kojarzona jest zwykle z ITSM, developmentem oraz z pracą biznesową na poziomie projektów i procesów, które nie opuszczają fizycznie biura. A nawet jeśli, to opuszczają też narzędzie, więc i mierzalność na jego poziomie.
Chociaż tak właśnie wykorzystuje ją większość firm, dla których tworzyłem lub rozwijałem konfiguracje przez ostatnich kilkanaście lat, nie mogę pominąć tych kilku ciekawych przypadków, które pokazują, że JIRA może mieć zastosowanie w firmie o profilu produkcyjno-dystrybucyjnym lub serwisowym, a jej wykorzystanie nie musi kończyć się na ścianie biurowca. Samodzielnie bądź z asystą narzędzi ERP, JIRA może trafić do hal produkcyjnych, magazynów, serwisów. Postaram się to opisać poniżej.
Przykład pierwszy – producent szaf transformatorowych
Dla producenta szaf transformatorowych, wiele lat temu, stworzyłem konfigurację do śledzenia etapów zamówienia. Konfiguracja powstała w Jira Core (znanej też jako Jira Business, później Jira Work Management, a obecnie po prostu jako Jira).
Całość oparta była, na życzenie klienta, na jednym długim przepływie pracy (workflow) pokrywającym kolejne etapy:
- złożenie zamówienia przez klienta końcowego (samo zamówienie odbywało się wtedy poza JIRA),
- podsumowanie zamówienia surowych materiałów od dostawców,
- status ich dostaw,
- otwarcie etapu produkcji,
- potwierdzanie kolejnych jej etapów przez mistrzów produkcji,
- kontrola jakości,
- transport i montaż produktu u klienta.
Każdy etap uzyskał osobną zakładkę z polami do wypełnienia, a te można było wypełniać jedynie, wykonując przyciskiem przejście do kolejnego etapu i przekazując zadanie kolejnej odpowiedzialnej osobie.
Co z widocznością danych? Celowo nie wszystkie dane były widoczne po wypełnieniu pól i zapisaniu zmian. Ponadto, nałożyłem maskę bezpieczeństwa, która pozwalała na wgląd do zadania tylko osobie przypisanej w danym momencie oraz kilku osobom decyzyjnym. Po przekazaniu pałeczki dalej, zadanie znikało z widoku dotychczas przypisanej osoby.
Było to rozwiązanie proste i skuteczne, stworzone podczas jednodniowej konsultacji i konfiguracji w obecności całego zespołu biurowego. Spotkanie stanowiło jednocześnie przeszkolenie z użytkowania narzędzia. Było to możliwe dzięki niewielkiemu ówcześnie rozmiarowi przedsiębiorstwa o szybkiej decyzyjności i sprawnej komunikacji wewnętrznej.
Przykład drugi – serwis części przemysłu ciężkiego
Drugim projektem jest konfiguracja dla serwisu części przemysłu ciężkiego, z ewidencjonowaniem przesyłek przychodzących i wychodzących, na podstawie drukowanych etykiet. Nie byłem jej autorem, ale częścią większego zespołu. Nie była to też realizacja tak prosta jak poprzednia.
Zespół wykorzystał do tego Jira Service Management + Assets + Automatyzacje + wtyczki do Jira. Dzięki wykorzystaniu modułu Assetów, ewidencjonowanie elementów przychodzących na serwis było znacznie ułatwione. Udało nam się zredukować poprzednio wykorzystywaną przez klienta metodę trzech etykiet z trzema różnymi kodami kreskowymi (przyjęcia do serwisu, serwisowania, wydania z serwisu do transportu zwrotnego) do jednego kodu QR, który prowadził do wszystkich niezbędnych danych zapisanych w module Assets. Dodatek firmy trzeciej umożliwiał druk tego kodu i dodatkowych danych, celem wysyłki zwrotnej elementu serwisowanego.
Przykład trzeci – przewoźnik kolejowy
W ostatnim czasie stworzyłem konfigurację dla przewoźnika kolejowego, w której warsztaty naprawcze, przez darmowy dostęp do Portalu Klienta, mogą brać aktywny udział w negocjacji terminów realizacji napraw wagonów, natomiast dane niezbędne do realizacji serwisu, są pobierane z zewnętrznego ERP.
Ta realizacja, z racji specyfiki obszaru działania firmy, była wyjątkowa w zawiłości konfiguracji i szeregu automatyzacji wymaganych do uzyskania pożądanego efektu. Narzędzia niezbędne do jej realizacji to: Jira Service Management + Customer Portal + Assets + Automation + Entra ID + ERP, z czego Entra ID oraz ERP to konfiguracje już istniejące po stronie klienta.
Ponieważ to przykład najświeższy i zdecydowanie najciekawszy, przytoczę, w uproszczeniu, jak wygląda proces, który obsłużyliśmy.
Tło
- Przewoźnik kolejowy (nazwijmy go ABC) zarządza flotą wagonów i lokomotyw. Realizuje zlecone przewozy, dba o stan sprzętu.
- Nie każdy z wagonów jest własnością firmy ABC, cześć z nich jest własnością firm trzecich – Owners.
- Każdy z obsługiwanych wagonów wykonuje przewozy dla klientów firmy ABC – Customers.
- Firma ABC współpracuje z warsztatami napraw kolejowych na terenie całego kraju.
- Firma ABC, jak wiele innych firm o podobnym profilu, korzysta z systemu ERP firmy trzeciej, dedykowanego na potrzeby branży kolejowej. Widząc ten system i stopień jego rozbudowania, lecz nie znając branży, mogę go nazwać, nieprofesjonalnie, „SAP-em na sterydach”.
Przyznaję, że musiałem zrobić z klientem konkretny wywiad, by zrozumieć, co jest ich „punktem bólu”, skoro właściwie wszystko są w stanie obsłużyć wewnątrz tamtego systemu.
Ponieważ SAP i podobne mu systemy ERP nie są częścią mojej specjalizacji, odbyłem też kilka rozmów prywatnych oraz firmowych, wewnątrz Sii, z osobami korzystającymi od lat z różnych modułów SAP, bądź będącymi konsultantami SAP.
Okazuje się, że największym problemem jest fakt, że SAP jest bardziej narzędziem stanowym, niż procesowym, w przeciwieństwie do Jira. Wiem, że tym stwierdzeniem wkładam kij w mrowisko i mogę zostać nazwany heretykiem, ale finał każdej odbytej rozmowy był podobny:
- Tak, SAP operuje na procesach i praktycznie wszystko można tam zautomatyzować seriami triggerów, listenerów i schedulerów, ale to wszystko, gdy skonfigurowane prawidłowo, dzieje się pod spodem, zatem na powierzchni operujemy na stanach.
- Z kolei Jira, na wierzchu skonfigurowana jest w oparciu o workflow – przepływ pracy i współpracy ludzi – który wspiera się danymi stanowymi pod spodem.
Dokładnie to było punktem bólu naszego klienta – brak warstwy komunikacji do obsługi procesu negocjowania terminów i realizacji napraw wagonów.
Zagadnienia kluczowe
Jak powiązać Jira z ERP firmy ABC? Jak nie dublować wszystkich informacji z ERP do Jira?
Najprościej, podążając za procesem, jaki firma ABC nam opisała.
- Awarie wagonów zgłaszane są i kategoryzowane przez maszynistów, z aplikacji mobilnej do ERP.
- Specjalista ABC informuje Ownera i Customera o wyłączeniu wagonu z ruchu, odczytuje jego lokalizację i dzwoni do najbliższego warsztatu, by ustalić termin naprawy.
- Jeśli najbliższy warsztat nie ma czasu, Specjalista negocjuje czas z innymi.
- W ustalonym terminie obsługa warsztatu zaciąga wagon do warsztatu, chyba, że nie da rady czasowo, wtedy następuje renegocjacja z innymi.
- Warsztat mailowo potwierdza Specjaliście, że naprawa została zakończona.
- Specjalista przywraca wagon do ruchu i informuje Ownera i Customera o tym fakcie.
Rozwiązanie
Dane
Postanowiliśmy, by z ERP do Jira zaimportować minimalną, choć nie małą, ilość danych, wystarczającą do komunikacji z każdą ze stron oraz do obsługi zmian serwisowych w wagonach.
W efekcie zaimportowałem do modułu Assets:
- stałą listę wagonów i ich komponentów podlegających serwisowaniu,
- stałą listę Ownerów + osoby kontaktowe,
- listę Customerów (ta z czasem może się zmieniać) + osoby kontaktowe,
- listę warsztatów współpracujących + osoby kontaktowe,
- ustandaryzowaną listę typów i kodów uszkodzeń.
Proces
Ponieważ maszyniści muszą zgłaszać awarie przez aplikację mobilną do ERP, gdzie są one wstępnie procesowane, to dopiero kolejnym krokiem jest wysłanie zgłoszenia z ERP do Jira.
Dzięki wcześniejszemu zaimportowaniu danych do modułu Assets, zminimalizowałem ilość danych przesyłanych do Jira za każdym razem, gdy należy utworzyć zgłoszenie serwisowe. Wystarczy, że ERP dostarczy numer ID wagonu oraz typ awarii, a pozostałe niezbędne dane zostaną lokalnie uzupełnione z Assets do Jira. Na podstawie tych informacji natychmiast mailowo informowani są o awarii Owner oraz Customer.
Fazy negocjacji Specjalisty i warsztatów oraz – po zakończonej negocjacji – realizacji zamówienia, przeniosłem na osobne zgłoszenie z własnym bliźniaczym procesem, by interesariusze nie musieli brać udziału w tej złożonej komunikacji.
Dopiero zakończenie procesu serwisu po stronie warsztatu zamyka zgłoszenie warsztatowe oraz zgłoszenie główne.
Co ważne – na każdym etapie realizacji zarówno Owner jak i Customer mają możliwość komunikacji ze Specjalistą ABC. Co jeszcze ważniejsze – konta Ownerów, Customerów oraz Warsztatów nie podnoszą kosztów użytkowania Jira. Jedynie Specjaliści ABC, jako obsługujący proces, posiadają płatne konta Agentów Jira Service Management.
Inne elementy konfiguracji
Nie sposób wymienić wszystkich, ale zaimplementowałem u klienta:
- dynamiczne zegary SLA,
- przypomnienia i eskalacje,
- szereg automatyzacji, uzupełniających niezbędna dane assetów i ludzi na konkretnych etapach,
- mechanizm niepozwalający na procesowanie zgłoszenia, jeśli ERP wysłał do Jira dane nowego wagonu, który nie ma przypisanego właściwego Customera (by ten nie został pominięty w komunikacji o awarii i serwisowaniu).
Inne możliwości wykorzystania konfiguracji Jira i ERP
Jira ma ogromny potencjał konfiguracyjny, czego dowodem jest jej popularność na całym świecie. Powyższe przykłady, a w szczególności ostatni, pokazują, że można ten potencjał wykorzystać jeszcze lepiej, zwłaszcza, jeśli powiązać ją z już istniejącym narzędziem ERP.
Wspominałem wcześniej o rozmowie z osobami pracującymi w SAP. Nie wspomniałem jednak o tym, że jedna z nich podsunęła mi przykładowe „punkty bólu”, z jakimi się spotkała. Oto one, wraz z moim komentarzem na temat potencjalnego rozwiązania problemu:
- Komunikacja z klientem w wielu pomieszanych wątkach mailowych i na ich podstawie ręcznie wpisywane zamówień do SAP – zamiast tego można użyć Portalu Klienta Jira Service Management i darmowych kont klientów – zebranie wymagań odbywałoby się w jednym miejscu z wykorzystaniem dynamicznych formularzy sięgających po dane do modułu Assets, co znacznie ułatwiłoby przepisanie danych do SAP (celowo nie piszę o automatycznym złożeniu zamówienia, bo o ile technicznie pchnięcie danych z Jira do SAP jest wykonalne, to procesowo zdecydowanie niedopuszczalne).
- Brak jasnego procesu prowadzenia zamówień: handlowcy robią świetne wyniki sprzedażowe, ale przez składanie ofert i zamówień w sposób nieustandaryzowany i chaotyczny, spowalniają cały proces, przez co klienci mogą mieć wydłużony czas realizacji –
tu również, można pokusić się o wykorzystanie konstrukcji Jira Service Management z omówionymi wcześniej modułami lub, zakładając potrzebę interakcji handlowców w szerszym zakresie z managementem firmy i pracy na bardziej złożonym procesie, użycie projektu biznesowego w Jira wraz z modułami Jira Product Discovery, Goals i Teams. - Klienci nie otrzymują aktualizacji o zmianie przewidywanej daty realizacji ich zamówienia –
oczywiście, że taką informację można pchnąć bezpośrednio z SAP, ale jakim kosztem wdrożenia i utrzymania, zakładając, że dane klientów, również indywidualnych, byłyby trzymane w SAP i dalej wykorzystywane w określonych transakcjach? W Jira – ponownie byłoby to realizowane minimalną ilością danych przesyłanych w ramach integracji i wysyłanie powiadomień na darmowe konta klientów, z których pierwotnie zamówienia były składane. - Użytkownicy SAP nie otrzymują automatycznie aktualizacji o cząstkowej realizacji zamówienia i przez to o opóźnieniu wysyłki – ponownie – SAP do Jira lub Jira z SAP – taki informacje można przesłać automatycznie i ubrać w powiadomienia. Alternatywnie – kosztem minimalnym, bez integracji – po prostu stworzyć automat w Jira, który informowałby Specjalistę o zbliżającym się lub przekroczonym terminie realizacji zamówienia xyz.
Podsumowanie
Jestem przekonany, że doświadczony konsultant SAP, czytając powyższe, może powiedzieć, że nie widzi żadnego problemu i wszystko to można skonfigurować w istniejącym narzędziu. Mogę się z tym jedynie zgodzić. Wiem też, że ten sam konsultant może się ze mną zgodzić, że wdrożenie takich korekt w istniejących konfiguracjach ERP będzie dużo droższe niż wykonanie prostszych integracji z Jira.
Co myślisz o takim rozwiązaniu? Jeśli widzisz tu potencjał dla usprawnienia pracy w Twojej firmie, odezwij się do nas.
Zostaw komentarz