Witam ponownie! Ostatnim razem, w artykule Optymalizacja procesów w IT – dlaczego warto to robić?, wyjaśniałem, że warto optymalizować procesy, by nie zostać pożartym przez konkurencję i wolny rynek. Najwyższy czas odpowiedzieć na kolejne ważne pytanie: Jak optymalizować?

Zacznij od zidentyfikowania obszarów do optymalizacji

Oto kilka przykładów:

Każdy z tych obszarów ma specyficzne potrzeby, dlatego w każdym projekcie optymalizacyjnym trzeba stosować zindywidualizowane, skrojone na miarę podejście. Cel optymalizacji procesów powinien być jasno określony. Np. jeśli chcemy mniej wydawać na business as usual, to celem jest optymalizacja kosztów i dlatego należy już na starcie określić, o ile procent chcemy owe koszty zredukować. Dzięki jasno określonemu celowi będziemy mogli również, w dłuższej perspektywie, zbadać, czy projekt okazał się sukcesem (bo zamierzony cel został osiągnięty) czy totalną klapą.

W niektórych branżach celem może być redukcja przestoju, czyli czasu, kiedy produkt nie jest wytwarzany z różnych przyczyn: braku surowców, złej organizacji pracy, nieregularnego serwisowania maszyn czy też zmniejszenia popytu na produkt. Decydując się na jakiś cel musimy zadbać o to, żeby był on zgodny ze strategią przedsiębiorstwa. W przeciwnym wypadku osiągnięcia projektu mogą zostać zakwestionowane lub projekt jako taki nigdy nie zostanie zrealizowany.

 

Poznaj procesy w firmie

Aby osiągnąć wyznaczony cel, zespół projektowy powinien bardzo dokładnie poznać obecne procesy w przedsiębiorstwie. Dobrą praktyką jest posiadanie ich listy i opisu jeszcze przed rozpoczęciem projektu lub przeznaczenie jego pierwszego etapu na pogłębioną analizę stanu obecnego. Jest to tzw. model as is, który następnie zestawiamy z planowanym, nowym modelem, czyli – to be. Tym sposobem upieczemy dwie pieczenie na jednym ogniu: zidentyfikujemy procesy w danym przedsiębiorstwie i określimy obszary do poprawy, a zarazem damy naszym interesariuszom materiał do podjęcia kluczowych decyzji o kształcie budowanego rozwiązania.

Następny krok to określenie osoby (np. Process Ownera), która będzie miała możliwość samodzielnego akceptowania zmian w przypadku braku pełnej zgody wśród interesariuszy. Osiągnięcie takiej zgody nie zawsze jest możliwe, gdyż w projekt zaangażowanych może być wiele konkurujących ze sobą departamentów. W grę wchodzą też ambicje, cele i podejście interesariuszy do projektu.

Zatem, jeśli nie jest możliwe określenie tzw. SPOCa (ang. Single Point of Contact), należy zadbać o utworzenie komitetu sterującego, odpowiednio dostępnego dla projektu. To pozwoli uniknąć długich i stresujących negocjacji w przypadku impasu. Warto też upewnić się, w jakiej metodyce projektowej chcemy pracować – czy ma być to Agile, Lean, a może Waterfall. Na pewno musi być dostosowana do struktury i kultury organizacji oraz do dostępności zespołu, interesariuszy i szeregowych pracowników w poszczególnych okresach projektu.

 

Zdefiniuj etapy optymalizacji

Nie od razu Rzym zbudowano!

Optymalizacja to proces kolejno występujących po sobie etapów, które najpierw trzeba zdefiniować:  Co? Kiedy? W jaki sposób? Dla kogo?

  • Planowanie: wstępne opisanie procesów, przypisywanie pracowników do uczestnictwa w projekcie, zebranie zespołu projektowego, określenie celu i oczekiwanego czasu projektu, poinformowanie organizacji o możliwości kontaktu ze strony zespołu projektowego po rozpoczęciu prac.
  • Analiza: musisz zaplanować odpowiednio długą fazę analizy i pośpiech jest tu złym doradcą. Im lepsza analiza tym łatwiejszy później projekt. Celem tej fazy jest identyfikacja procesów i ich niuansów, struktury interesariuszy, potencjalnych ryzyk i szans.
  • Weryfikacja założeń: to moja autorska propozycja. Przyjmijmy, że projekt już się rozpoczął, wiemy, kto go będzie realizował, jak długo ma trwać i znamy jego zakres. Wydawałoby się, że już wszystko rozgryźliśmy. A jednak nie do końca. Aby faza analizy miała jakikolwiek sens, po jej zakończeniu należy zweryfikować cel, zakres i harmonogram projektu, a może nawet zmodyfikować listę interesariuszy lub przebudować zespół.
  • Realizacja: rozumie się samo przez się.
  • Wdrożenie: czyli udostępnienie beneficjentom projektu rozwiązania czy też procesów wypracowanych przez zespół.
  • Stabilizacja: dobrą praktyką jest zaplanowanie okresu stabilizacji rozwiązania po jego wdrożeniu. Zespół projektowy powinien jeszcze przez jakiś czas czuwać nad wynikiem swojej pracy. Dzięki temu wszelkie problemy będą mogły być rozwiązane szybciej, a interesariusze oraz użytkownicy zyskają poczucie, że nie zostali zostawieni sami sobie. Ta faza powinna trwać minimum 2 tygodnie.
  • Zamknięcie projektu: podsumowanie, czy projekt zmieścił się w określonym czasie, budżecie i zrealizował określone cele. Na to ostatnie czasem należy poczekać dłużej, np. 6 miesięcy, aby sprawdzić, czy określone na początku założenia zostały zrealizowane.

 

Na koniec kilka bardzo ważnych wskazówek

  • Wprowadź kluczowe wskaźniki wydajności (KPI) – dzięki nim dowiesz się, czy wprowadzana zmiana przyniosła zakładane korzyści.
  • Zarządzanie zmianą w organizacji (ang. Organizational Change Management, OCM) to kluczowa część procesu optymalizacyjnego. Ludzie bardzo często kwestionują proponowane zmiany. Staraj się zminimalizować negatywne opinie przez zapewnienie jak największej ilości informacji i sesji szkoleniowych od samego początku projektu. Newsletter dla użytkowników objętych zmianą również może zwiększyć świadomość w organizacji i przygotować dobry grunt pod nadchodzące zmiany.
  • Zdefiniuj kanały komunikacji i sposób realizacji. Pamiętaj o uwzględnieniu wszystkich kluczowych beneficjentów i adresatów wprowadzanej optymalizacji.
  • Słuchaj uważnie opinii i informacji zwrotnych dotyczących przeprowadzanych zmian.
  • Bądź przygotowany na odkrywanie nieznanych dotąd lądów, ale pamiętaj, że musisz się do tego odpowiednio przygotować. Nawet najlepsze projekty upadają, jeśli nie są odpowiednio zaplanowane, a beneficjenci nie byli świadomi nadchodzących zmian.

To już wszystko w tej części serii o optymalizacji! Następnym razem pochylimy się nad metodami i technikami analizy. Podzielę się również moim ulubionym “koktajlem” metod i technik.

Autor
  • Paweł Sidorowicz
  • Business and System Analyst
  • Analityk z szerokim doświadczeniem projektowym. Z branżą IT związany od 7 lat, uczestniczył w projektach dla klientów polskich i międzynarodowych, z sektorów finance, healthcare, car audio i pharma. Realizuje projekty na platformie Salesforce od blisko 3 lat. Entuzjasta projektów zwinnych i optymalizacyjnych, team player, motywator i siewca uśmiechu.

Opracowanie redakcyjne:
Ania Sawicka
Opracowanie redakcyjne
Aleksandra Pasek
Korekta językowa
Podobał Ci się mój artykuł?

Jeśli tak, zapraszam Cię do grona najlepiej poinformowanych czytelników bloga. Dołącz do naszego newslettera, a nie ominą Cię żadne nowości.