Model Greiner w IT

W poprzednim poście napisałem kilka słów o modelu Greinera wzrostu organizacji. Teraz pora na aplikację tego do IT. Zastanówmy się nad dwoma fazami modelu:

• faza 2 (wzrost przez wytyczne),
• faza 3 (wzrost przez delegowanie).

Intuicyjnie można by utożsamić fazę 2 ze działami IT średniej wielkości (30-90 pracowników). Zgodnie z modelem Greinera wzrastają one przez ustalanie procedur i wytycznych oraz tworzenie odpowiednio zaprojektowanych struktur funkcjonalnych. Zwykle struktury tworzy się intuicyjnie na podstawie własnych warunków, nie zawsze jednak taka metoda daje najlepsze rezultaty. Warto w tym miejscu wykorzystać wiedzę o najlepszych praktykach zarządzania IT: ITIL. Część wersji 3 tej biblioteki: Eksploatacja usług dużo miejsca poświęca funkcjom koniecznym do wprowadzenia w ramach organizacji IT. Przykładowo znajomość pojęcia Service Desk może zaowocować wczesnym powołaniem takiej struktury w dziale IT i uniknięciem wielu organizacyjnych kłopotów. Pomocniczo można wykorzystać również procesy opisane w tej i innych częściach książki, będą one jednak grały drugoplanową rolę (poszczególnym stanowiskom funkcjonalnym będą przypisywane role wynikające z procesów).

Opisana wyżej organizacja przechodzi naturalny kryzys autonomii polegający braku delegacji uprawnień przez Zarząd (właścicieli) kadrze menedżerskiej. Można by zaryzykować hipotezę, że zachodzi to w dużych organizacjach IT liczących od 90 do 250 pracowników. Zarząd (a właściwie CIO) może czuć opór przed delegacją uprawnień bojąc się utraty kontroli. Tutaj z pomocą przychodzi znów ITIL. Niezbędnym mechanizmem organizacyjnym w tak dużej organizacji są procesy i ich menedżerowie, którzy umożliwiają sprawowanie kontroli menedżerskiej najwyższej kadrze zarządzającej.

Temat drugi jest wałkowany przez wiele firm konsultingowych szukających okazji do wdrożenia narzędzi z gatunku ITSM, natomiast pierwszy wydaje mi się równie ciekawy do rozwinięcia w bardziej naukowy sposób - metody projektowania funkcjonalnego średnich organizacji IT z wykorzystaniem biblioteki ITIL.

Model Greiner czy cykl Greinera?

W teorii organizacji i zarządzania funkcjonuje model Greinera opisujący kolejne fazy rozwoju organizacji. Krótko przypomnę, że każda faza składa się ze wzrostu oraz kryzysu, po którym organizacja przebudowuje swoje metody organizacyjne i przechodzi do następnej fazy.

Ciekawe jest, że Greiner nie opisał piątej fazy i następującego w niej kryzysu. Czy dlatego, że nie było tak dużych organizacji, na podstawie których można by tworzyć ogólne modele?

Przyczyna może być inna: model Greinera w swej istocie może być cyklem. Organizacja, która przeszła kryzys biurokratyczny i wzrasta przez współprace nie jest już jednolitym organizmem możliwym do koordynowania centralnie. Jest to w rzeczywistości grupa organizacji współpracujących ze sobą, a każdy kryzys (nazwijmy go "zaufania") prowadzi do rozpadu tej organizacji na mniejsze, które kontynuują wzrost w jednej z faz opisanych przez Greinera.

Takie podejście tłumaczy spektakularne upadki imperiów i korporacji, (a nawet dinozaurów ;)), które poprzez nadmierny wzrost stały się niezdolne do centralnej koordynacji. Jaki z tego morał dla najwyższej kadry zarządzającej (również polityków, jako rządzących państwami)? Nie można kontynuować wzrostu w nieskończoność. Kiedyś przychodzi konieczność podziału imperium na mniejsze zdolne do samodzielnego działania. Jak dzielić imperium - przypuszczam, że najlepiej jest wydzielać w pełni autonomiczne organizacje zachowując udział właścicielski, ale o charakterze wyłącznie inwestycji finansowej, a nie typowego właścicielstwa ingerującego w merytorykę.

Czas taktu w usługach

Jak napisał Rob Worth na swoim blogu przeniesienie czasu taktu z systemów produkcyjnych do usługowych nie jest ani trywialne, ani oczywiste. Różnica tkwi w charakterze popytu - w usługach mamy do czynienia z popytem zmieniającym się z godziny na godzinę, a często z minuty na minutę. Z kolei w szczupłej produkcji popyt zmienia się w cyklach tygodniowych, miesięcznych i rocznych. Dlatego czas taktu rzędu godziny nie wpływa na jakość obsługi. Analogicznie w usługach czas taktu powinien być rzędu pojedynczych minut, a czasem nawet sekund - wtedy wewnętrzna synchronizacja procesów nie będzie kolidować ze zgłoszeniami.

Powstaje poważne pytanie - jak synchronizować procesy usługowe z dokładnością do minut? Po za problemem znalezienia odpowiedniego narzędzia powstaje problem dostosowania ludzi do takiej pracy. W produkcji istotnym problemem jest przestawienie się pracowników z pracy na "górze zapasów" na pracę na przesuwanej taktem taśmie z produktami. Analogicznie od pracowników usług będzie to wymagało reakcji i działań liczonych w minutach, a nie w godzinach.

Znalazłem metodę, która może pomóc w przystosowaniu pracowników organizacji usługowych do pracy ciągłej (zamiast na kolejce zadań). Jest to amerykański system organizacji działań osobistych znany jako Sztuka bezstresowej efektywności albo Getting Things Done Davida Allena. Jedna z jej koncepcji to natychmiastowe wykonywanie zadań, na które nie trzeba więcej czasu niż 2 minuty. To wydaje się być właśnie czasem taktu w usługach. Ciekawe, że David sugeruje, że ten czas można regulować. Zatem mogą być organizacje, czy osoby, które mogą sobie pozwolić na czas taktu rzędu nawet 15 minut - wszystko zależy od popytu!

Na koniec zwrócę uwagę na jeszcze jedną ważną rzecz - jako narzędzie do rozwiązywania tego typu problemów Rob wskazuje System Thinking. Rzecz ważna rozpoznania!

Coraz więcej szczupłej informatyki

Idea zastosowania Lean Thinking w IT rozprzestrzenia się. Mamy kolejne materiały do czytania:
stronę w Wikipedii,
raport firmy badawczej Forrester, niestety płatny jakieś kosmiczne pieniądze,
krótki objaśnienie z wartościowymi linkami.
Zalecam lekturę!

ITIL w Polsce? Szybciej!

Dwie instytucje przeprowadziły w tym roku badania polskich organizacji wsparcia: portal ITLife oraz Zakład Zarządzania Technologiami Informatycznymi PG. Pierwsze badanie jest dostępne na portalu po zalogowaniu, omówienie drugiego można przeczytać w Computerworld nr 26-27.

Osobiście brakło mi w obu raportach głębszych analiz korelacji. Przykładowo czy istnieje zależność stosowania ITIL i zarządzania procesami od wielkości działu IT? Być może jest to oczywiste, że ok 36% dużych organizacji (>1000 osób) ma działy IT powyżej 100 pracowników (20%) , które:

• stosują ITIL od dłuższego czasu (38%)
  
• mierzą i optymalizują procesy (20%) albo przynajmniej je mają wdrożone (25%)
• obsługują powyżej 500 zgłoszeń dziennie (?)
  

Podobnie jest bardzo ciekawa grupa organizacji MŚP, która mają 100-1000 pracowników (37%), stosunkowo nieduże działy IT (10-100 osób - 42%). W tych firmach dopiero się rozpoczyna lub planuje wykorzystanie ITIL-a, a procesy są tylko udokumentowane lub planuje się ich dokumentacji. Obciążenie Service Desku w takich organizacjach powinno się wahać w granicach 50-500 zgłoszeń dziennie.

W badaniu ZZTI próbka była symboliczna (52 organizacje), z kolei w badaniu ITLife przeważyło podejście marketingowe: "jest lepiej, będzie jeszcze lepiej".

Mimo to można dowiedzieć się kilku ciekawych metod:

1. istnieje jeszcze spora grupa organizacji nie znających ITIL-a (20%) lub znających go ogólnie (18%) - szkoleniowcy do dzieła!
2. dominującą metodą ITIL-a wykorzystywaną w organizacji jest Service Desk i zarządzanie incydentami, stosuje się również obsługę wniosków i zdarzeń, choć uważam, że wpływ ITIL V3 niewielki, wbrew temu co piszą autorzy badań (łączenie incydentów, wniosków i zdarzeń jest po prostu intuicyjne)
3. jeśli istnieje już Service Desk można się spodziewać z dużym prawdowpodobieństem zastosowania zarządzania zmianą, problemami i poziomem usług
4. oprócz ITIL najczęściej stosuje się Prince2, ISO 9000, ISO 27001

PmBOK przegrał znacząco z Prince2, przy czym może to być wina dużego udziału IT i Telekomunikacji - znów brakuje analizy korelacji. Z badania ZZTI dowiadujemy się, że ISO 20 000 (w zasadzie standaryzacja i okrojenie ITIL-a) ma duży "elektorat" negatywny i rzeczywiście w badaniu ITLife jest dopiero na 6-ty miejscu. Potwierdza to niechęć środowisk informatycznych do ISO, przy czym duża popularność ISO 9000 potwierdza regułę: IT stosuje w tym wypadku ISO bo musi!

Na koniec bardzo ważna obserwacja - właściwie kwintesencja całości: wśrod czynników zastosowania ITIL-a jest na pierwszym miejscu presja biznesu na szybkie wprowadzanie zmian (43%), a dopiero na drugim miejscu oszczędności kosztowe (25%).

Pierwsze wrażenie informatyki

Mówi się często, że najważniejsze jest pierwsze wrażenie. Co więcej badania naukowe dowodzą, że decyduje ono o ocenie drugiej osoby i powstaje w przeciągu pierwszych kilku minut kontaktu. Tak jest zbudowany nasz mózg emocjonalny, gdyż kiedyś taka umiejętność decydowała o być albo nie być osobnika.

Patty Azzarello, była menedżer HP, aktualnie właścicielka AzzarelloGroup napisała w artykule dla CIO Update, że w 90% na ocenę zespołu ds. informatyki wpływa praca punktu pierwszego kontaktu inaczej zwanego help deskiem (rzadziej service deskiem). Podstawowym warunkiem skutecznej pracy help desku jest wyznaczenie właściwej orientacji jego pracowników. Są tutaj dwie możliwości:

• orientacja na rozwiązywanie problemów,
• orientacja na przestrzeganie procedur i kontrolę kosztów.

Oczywistym jest, że tylko w pierwszym przypadku możemy osiągnąć wartościowy rezultat, czyli dobre pierwsze wrażenie informatyki. Orientacja na rozwiązywanie problemów wymaga empatycznych, kreatywnych, ale również biegłych technicznie pracowników help desku. Muszą oni być uprawnieni do działania, w tym również ponoszenia kosztów rozwiązania problemów. Ciekawym problemem jest rozliczenie pracowników z rozwiązanych problemów (być może "tickety" powinień zamykać klient?). W każdym razie nie należy koncetrować się wyłącznie na statystykach "zamkniętych ticketów" lub "długości kolejki".

Patty mocno podkreśla rolę first hand experience, czyli bezpośredniej obserwacji miejsca pracy podległych pracowników przez szefa, jak również wejście szefa w rolę klienta help desku. Nawiązując do LeanIT nie jest to nic innego jak genchi genbutsu (osobiste zaangażowanie dla zrozumienia sytuacji) Toyoty i wycieczki do gemba (miejsca dodawania wartości). Historia lubi się powtarzać ...

Zasada nieoznaczoności w IT

Artykuł na temat Dynamiki Systemów nasunął mi pewien pomysł na opis złożonych organizacji, jakimi niewątpliwie są duże działy informatyczne. Sugeruje on, aby do opisu organizacji wykorzystać oprócz metod statycznych (BPM, Lean, TOC) metody dynamiczne (Dynamikę Systemów - SD ang. Systems Dynamics). Co ma to wspólnego z zasadą nieoznaczoności? Przypomnę za Wikipedią, że w fizyce istnieją wielkości kanonicznie sprzężone, których nie da się równocześnie zmierzyć z dowolną dokładnością.

Analogicznie w IT nie powinno się dać jednocześnie opisać statycznie i dynamicznie działania organizacji z dowolną dokładnością. Jednocześnie uwzględnienie obu tych opisów w pewnym przybliżeniu daje dokładną informację o systemie.

Co to oznacza dla architektów organizacji? Do modelowania zachowania zespołów ludzkich powinniśmy używać jednocześnie dwóch opisów - modelu procesowego - czyli jak organizacja działa operacyjnie i modelu dynamicznego - czyli jak organizacja reaguje na bodźce. Konsekwencją zasady nieoznaczoności jest ograniczenie dokładności modelu - nie należy zbyt dokładnie modelować organizacji oboma sposobami naraz. Również ograniczenie modelowania tylko do statycznej strony lub dynamicznej upośledza pracę.

Najlepsze podejście według mnie to modelowanie statyczno-dynamiczne - od ogółu do szczegółu. Najpierw opisujemy podstawowe procesy organizacji, potem zgodnie z zasadą Pareto wybieramy 20% najważniejszych (zwykle 1-2), te modelujemy szczegółowo. Potem opisujemy organizację metodą dynamiczną. Tu niestety moja wiedza się kończy....