/ We know how

Problemy w firmie: od obserwacji do interpretacji i naprawy

Symptomy firmowych problemów z procesami i technologią wymagają pogłębionej interpretacji, aby ustalić ich rzeczywiste przyczyny i zaplanować działania naprawcze. Służy do tego projekt typu Discovery. 

 

Regularne przeglądy – co działa, co nie działa – powinny w każdej firmie być elementem procesu ciągłego doskonalenia. Niestety, firmy rzadko mają dostępne czas i zasoby. Tymczasem zebrane i uporządkowane informacje o symptomach problemów mogą posłużyć do dalszych analiz i ustalenia ich prawdziwych przyczyn. Stąd prosta droga do stworzenia planu naprawczego, który pozwoli usunąć błędy.

 

 

Wola i zdolność naprawy

 

Cykl obserwacji, badania, diagnozy i leczenia organizacji można rozpisać na role, aktorów i etapy.

  • Ważne, aby to firma własnymi siłami była w stanie dokonać wstępnego opisu problemów. Efektem takiego opisu sytuacji powinno być ustalenie, gdzie brakuje procesów, procedur i schematów działania.

W toku autodiagnozy można także określić, gdzie brakuje wiedzy. Trzeba podsumować, co zewnętrzni dostawcy robią dla nas i za nas. Określa to, w jakim stopniu jesteśmy w stanie zweryfikować jakość ich usług.

Tak przeprowadzona autodiagnoza jest już dobrym punktem wyjścia do naprawy błędów. Bazuje ona na postawie proaktywnej (nastawienie rokuje z pewnością na  wynik “leczenia”), na wewnętrznej wiedzy o firmie, wreszcie na dojrzałości i świadomości koniecznej poprawy.

 

  • Następnym krokiem powinna być jednak pogłębiona diagnoza ekspercka. Warto, aby przeprowadził ją zewnętrzny partner dysponujący odpowiednią wiedzą i metodyką. Dodatkową zaletą będzie zdystansowanie do uwarunkowań, utartych schematów i wewnętrznych relacji w firmie. Jednocześnie partner będzie mógł uwzględnić oczekiwania firmy dotyczące zakresu programu naprawczego. Może być on przecież nakierowany na fundamenty – a kiedy indziej na poprawę doraźnych wskaźników.

 

  • Synteza ustaleń obu etapów stworzy możliwość wspólnego zbudowania programu naprawczego. Jeśli interpretacja przyczyn problemów była dobra – jest szansa na ich usunięcie.

 

 

Od obserwacji do interpretacji

 

Interesujący przykład działania takiego schematu – od autodiagnozy przez interpretację i diagnozę rzeczywistych przyczyn problemów i rekomendacje działania – zrealizowaliśmy we współpracy z klientem. Klient to globalny podmiot branży edukacyjnej i mediowej. Firma przeżywa ekspansję, potrzebuje integrować przejmowane spółki w ramach trzech głównych jednostek, z centralną jednostką odpowiedzialną za dostarczanie technologii. W tym –  technologii chmury obliczeniowej, kluczowej dla firmowej architektury.

 

Nasz klient zdiagnozował u siebie całą listę problemów z efektywnością środowiska, m.in.:

  • niewystarczająca wiedza o wykorzystywanym ekosystemie chmury publicznej,
  • brak jednolitych definicji i spójności ról oraz odpowiedzialności w organizacji,
  • brak ustandaryzowanych procesów, podejście adhokratyczne.

 

Wzięliśmy listę uchwyconych oznak problemu na warsztat, aby odkryć ich źródła. Posłużył temu cykl indywidualnych wywiadów z interesariuszami oraz warsztatów grupowych w oparciu o dopasowany do sytuacji firmy zestaw metodyk.

 

Nieco szerzej o metodyce projektu typu Discovery – obejmującej fazę przygotowawczą, analizę inside-out oraz outside-in piszemy w case study tego klienta (link).

 

Oto przykład, jak zaobserwowane symptomy problemów, zyskały w toku projektu Discovery  interpretację, podpowiadającą możliwe działania naprawcze:

 

  • niewystarczająca wiedza o wykorzystywanym ekosystemie chmury publicznej;

wynik badania: problem nasilał się wraz z rozwojem firmy i obciążeniem jednostki centralnej, z czasem zabrakło osób kompetentnych technicznie; brak wewnętrznego Cloud Center of Excellence powodował, że jednostka nie była w stanie ocenić efektywności usług i sposobu ich dostarczania; brak struktury oraz procesów utrwalania i dzielenia się wiedzą, powodował, że kolejne implementacje, nawet tej samej usługi, dokonują się bez uwzględnienia nabytego już doświadczenia;

 

  • brak jednolitych definicji i spójności ról oraz odpowiedzialności wskroś organizacji;

wynik badania: problem dotyczył nie tylko relacji pomiędzy jednostkami, ale istniał także w ich obrębie; dana rola mogła zawierać zupełnie inne obowiązki w zależności od jednostki organizacyjnej, a wiedza o tym była różna – od pełnej do całkowitego jej braku;

 

  • brak ustandaryzowanych procesów, zarządzanie adhokratyczne

 

wynik badania: rozwój procesów i struktury oraz schematu zarządzania (governance) nie nadążały za tempem rozwoju firmy – powoduje to faktyczne problemy, na przykład brak globalnej strategii zarządzania architekturą, brak centralnego zarządzania usługami chmurowymi i brak wiedzy na temat elementów warstwy aplikacyjnej.

Rezultatem projektu Discavery w tym konkretnym przypadku jest rekomendacja kilkudziesięciu inicjatyw, ułożonych w harmonogram i podzielonych według priorytetów. Ten plan powstał we współpracy z klientem, uwzględnia jego założenia i cele – zarówno zadeklarowane na wstępie, jak i ujawnione w toku projektu.

Porozmawiajmy!

    Wypełnij formularz,
    a my pomożemy Ci wdrożyć najnowsze rozwiązania!