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!
a my pomożemy Ci wdrożyć najnowsze rozwiązania!
Podobne wpisy:
Cloud Culture i migracja do Chmury we właściwy sposób
Która chmura obliczeniowa jest najlepsza?
Czym jest Mobile Cloud Computing?
Czy chmury są nieuniknione? Jak wygląda przyszłość cloud computingu?