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....

Lean Storage

Praktyczny przykład oszczędności na powierzchni dyskowej z firmy Apptio. Będę pisał "storage" bo tak krócej - a więc dzielimy Storage firmowy na trzy poziomy:

• on-line, wysokiej wydajności i dostępności, ok. 20% wielkości danych
• slow, w postaci wolnych macierzy dyskowych, może być RAID5 dla danych rzadko, ale używanych
• taśma lub inne wolne rozwiązanie dla backupów, archiwów i innych danych trzymanych "na wszelki wypadek"

Odpowiednie zarządzanie danymi pomiędzy tymi poziomami może przynieść od 25 do 50% redukcji kosztów "storage".

Zamiast dość kłopotliwych napędów taśmowych można eksperymentować z modnym ostatnio "cloud computing" i "cloud storage".

Ciekawym zagadnieniem jest również deduplikacja danych - polega na usuwaniu zdublowanych plików, całych katalogów, a w zaawansowanych rozwiązaniach również fragmentów danych. Może przynieść od 30% do 70% redukcji "storage".

Kindle znaczy śmierć książek?

Artykuł na temat czytników książek elektronicznych nasunął mi pewną filozoficzno-informatyczną refleksję. Otóż w czasie bańki internetowej wieszczono koniec tradycyjnych gazet, później w miarę wzrostu przepustowości wieszczono koniec radia na rzecz radia internetowego, koniec TV na rzecz IPTV. Nic takiego się nie stało. Telewizja nie wyparła radia, Internet gazet, tym bardziej Kindle i inne tego typu zjawiska nie spowodują śmierci rynku wydawniczego. Pokuszę się w tym miejscu na kilka prognoz:

1. należy się spodziewać spadku cen tradycyjnych książek pod wpływem powszechności użycia e-booków, być może książki będą wzbogacane w atrakcyjne dodatki (tak jak teraz gazety), aby zapewnić opłacalny poziom sprzedaży,
   
2. e-booki wyprą książki z tych obszarów, gdzie używa się książki jako referencji, encyklopedii - łatwiej jest przecież wziąć ze sobą czytnik niż plecak książek - z pewnością wykorzysta to biznes (przykładowo administratorzy będą nosić ze sobą wszystkie potrzebne i niepotrzebne instrukcje, manuale, podręczniki)
3. e-booki zwiększą radykalnie zwiększą dostępność wiedzy - człowiek wyposażony w czytnik będzie dysponował dużo większym potencjałem informacji niż aktualnie

Pozostaje pytanie czy czytniki upowszechnią się tak jak notebooki? Zaryzykuję twierdzenie, że nie. Przykład: palmtopy - nie uzyskały wielkiej popularności mimo, że znacząco potrafią usprawnić życie. Ludzie korzystają z papierowych lub notebookowych organizerów. Podobnie będzie z czytnikami - w pewnych zastosowaniach się sprawdzą, ale większość ludzi będzie używać własnych notebooków jako czytników.

Konferencja BPM

Zaległe kilka słów na temat konferencji BPM - link na mojej stronie www. Dwóch prelegentów godnych polecenia:

• dr. Wojciech Cieśliński dotknął istoty modelowania procesów i innych zabaw z zarządzaniem i organizacją - wszelkie metody, plany, procedury mają wartość, jeśli polepszają posługiwanie się narzędziami (oprogramowanie, sprzęt i inne).
• Waldemar Wasiuk z BMGI - zaprezentował koncepcje Lean w niezwykle atrakcyjny sposób.

Konkludując - wszelkie zabawy z procedurami, organizacją muszą mieć jasno postawiony cel - co i dlaczego mają zmienić. Jeżeli organizacja dobrze czuje się z chaosem organizacyjnym to po co zmieniać? A tak przy okazji - GE Money wychodzi na lidera Lean Six Sigma - co ciekawe to nie IT wymyśliło L6s, ale biznes...

Szkolenia IT

Jeszcze jedna ważna obserwacja z V Forum HDI. Lech Rychliński z Gratka.pl stwierdził, że 70% szkoleń dla informatyków to szkolenia "miękkie" - asertywność, motywacja, praca zespołowa, zarządzanie czasem itp...

W pełni się z tym zgadzam, nawet rozszerzyłbym to do kilku fundamentalnych zasad (mini polityka szkoleń IT):

1. Budżet szkoleń IT w większości (60-70%) przeznaczamy na szkolenia "miękkie", gdyż z natury pracy i predyspozycji informatycy mają największe zaległości w tym zakresie. Nie trzeba tu sięgać po "best-of-breed" - już średniej jakości szkolenie zapewnia spory postęp.
   
2. Motywujemy pracowników do samodzielnego poszerzania zagadnień potrzebnych im pracy poprzez zakup książek, kursów e-learningowych itd. Organizujemy cykliczne szkolenia wewnętrzne, na których bardziej doświadczeni pracownicy dzielą się praktyką i wskazują dobre źródła wiedzy. Wskazane jest przeznaczyć część budżetu na premie dla najlepszych "szkoleniowców".
   
3. Pracowników doświadczonych i biegłych w konkretnej dziedzinie wysyłamy na drogie konferencje lub szkolenia zagraniczne (ma to również aspekt motywacyjny) - wysyłanie na szkolenia średniej klasy techniczne w Polsce nie ma sensu - zdarzało mi się, że pracownicy wracali ze szkolenia z wnioskiem, że mogliby szkolić trenera!

I po konferencji!

Jak już wcześniej ogłaszałem w zeszłym tygodniu odbyła się Konferencja V Forum Wsparcia HDI, na której miałem przyjemność wygłosić wykład Lean ITIL. Mimo konkurencji dyrektora IT PepsiColi udało mi się przyciągnąć spore grono słuchaczy - pojawiły się nawet pytania. Ważniejsze jest jednak to, że zgodnie z moją hipotezą z wykładu metody wypracowane w Toyocie mają odbicie w IT. Potwierdziły to wystąpienia innych prelegentów:

• Pan Radosław Klicki z Atos Origin przedstawił Service Desk, w którym: eliminuje się aktywności nie przynoszące korzyści (Muda!), standaryzuje się dobre praktyki, redukuje się różnorodności (wyrównywanie pracy - heijunka!) itd...
• Pan Michał Bosowski z COIG z kolei opisał system żółtych i czerwonych kartek (wizualizacja!) oraz umieszczenie 2-giej i pierwszej linii wsparcia na jednej sali (dokładnie to przedstawiłem w koncepcji Lean Service Desk Room)...

Postawię pytanie bez odpowiedzi: czy dobre praktyki w IT analogiczne do Lean zgrupują się w postać metodyki "Lean IT"? Czas pokaże...

Oprócz Service Desku był miły, ale konkurencyjny koncept w zarządzaniu projektami. Firma kosultingowa Mandarine Partners przedstawiła nowe podejście do zarządzania projektami (metda łańcucha krytycznego) wykorzystujące Teorię Ograniczeń Goldratta - polecam i mam w planie się przyjrzeć. W skrócie powiem tylko tyle, że metoda łańcucha krytycznego pozwala realizować projekty o czasie i w budżecie co jak wiemy jest ekstremalnie trudne!

ITSM w małej organizacji

Niezawodny Rob England streścił ideę Small ITIL. Warto doczytać do końca artykułu i przeglądnąć literaturę - ciekawe jest to, że zarządzanie IT w SME jest tak dokładnie rozpracowywane.

Szczupłe IT w Fujitsu

Tak przynajmniej twierdzi Harvard Business Review:

http://www.fujitsu.com/uk/news/insights/s4b/21-leanthinking.html

Więcej ciekawych rzeczy o Lean jest na blogu Sunita Prakasha.

Czym jest właściwie priorytetyzacja?

Za słownikiem Kopalińskiego: pierwszeństwo; przywilej od łac. prior '(po)przedni; wcześniejszy; pierwszy; starszy. A więc priorytet określa kolejność realizacji w grupie zadań, projektów. Te z wyższym realizujemy najpierw bo są najważniejsze, te z niższym później.

W rzeczywistości występuje jeszcze czynnik czasu - zwykle zadania czy projekty powinny kończyć zgodnie z planowaną datą. Niestety często są one opóźnione i aby zapewnić ich jak najszybszą realizację "podnosi się ich priorytet" opóźniając inne zadania. Prowadzi to do coraz większego chaosu, stanu permanentnych opóźnień i kryzysów.

Wtedy dochodzi do najgorszego - powszechne zastosowania słowa "deadline". Deadlinem określa się każdy wymagany termin, co prowadzi do dewaluacji jego znaczenia. Przypomnijmy zatem co znaczy słówko "deadline": nieprzekraczalny termin, po którym wykonanie zadania traci sens. To tak jakby wysłać życzenia Świąteczne po Nowym Roku...

Zasada 1 - planuj jawne bufory na końcu grupy zadań (projektu) - dzięki temu zadania mogą się opóźnić i nie ma presji na ich wcześniejsze ukończenie,

Zasada 2 - jeśli zadanie, projekt już się opóźniło, myśl jak je wykonać w mniejszym zakresie, kosztem nadgodzin lub wynegocjuj przesunięcie terminu,

Zasada 3 - nigdy nie bierz zasobów z innych projektów, bo popadniesz w błędne koło opóźnień - lepiej usuń jakiś projekt/zadanie o NAJNIŻSZYM priorytecie i jego zasoby przeznacz na likwidację opóźnień

Zasada 4 - nie poprawiaj nieudanych projektów - odstaw je na koniec kolejki bo zawalisz cały program

Zasada 5 - nadciągające kryzysy likwiduj niezwłocznie - pamiętaj kryzys to zadanie pilne (deadline może być przekroczony) i jednocześnie ważne (na przykład poważna awaria)

Priorytetyzacja nie ma nic wspólnego z terminowością - określa ważność projektów/zadań w skali globalnej i pozwala przypisać odpowiednie zasoby i zaplanować w odpowiedniej kolejności.

Więcej na blogu Core ITSM:

• Prioritisation
• Prioritisation 2

Uwaga niebezpieczeństwo! Pragmatyczne podejście do koncepcji Lean IT

No właśnie. Pragmatyczne podejście aż do bólu. Bardzo ładny przykład wykorzystania idei do promocji własnych produktów i usług. Firma CA pod płaszczykiem terminu "Lean IT", którego notabene nie wyjaśniła reklamuje:

CA Wily Application Performance Management - tuning systemów?
CA Service Catalog - coś do ITSM?
CA Clarity™ PPM On Demand - coś jak MS Project?
CA Workload Automation - load balancer?
CA ARCserve® Backup i CA XOsoft - backupy
CA Enterprise Log Manager - logi
CA Data Loss Prevention - dostęp

Oczywiście na siłę można podciągnąć wszystko po Lean - wystarczy załączyć słówko "proces":

Komputer w firmie
Twoja firma
eGospodarka
Bankier.pl

ISO 20 000 nie tylko dla dużych

Dopiero co napisałem artykuł i już się ukazał. Jak poprzednio - Computerworld. Jestem pod wrażeniem. Nie spodziewałem się, że pójdzie tak łatwo.

Zarządzanie IT w Polsce

Zarządzanie IT to już całkiem obszerna dziedzina wiedzy. ITSM, Project Management, BPM itd. itp. - przykładów można mnożyć. Niestety nie uczą tego na studiach dziennych. Pojawiły się natomiast ciekawe propozycje podyplomowe - SGH i Politechnika Warszawska rywalizują projektami studiów "Zarządzanie IT" z mniej więcej zbliżonym programem (BSC, COBIT/ITIL, projekty, procesy, BPM, Value IT i inne). Studia na SGH są bardziej biznesowe, więcej jest fachowców spoza uczelni, również popularnych praktyków. Mam wrażenie, że są celowane w korporacje. Z kolei Politechnika częściowo powtarza program, ale wprowadza ciekawe alternatywy - COBIT zamiast ITIL, nowe techniki projektowe (RUP, XP, SCRUM), więcej jest o jakości i standardach, wykładowcy w przeważającej części z uczelni, więc pewnie więcej teorii. Koszt i organizacja praktycznie takie same. Warto zerknąć również do Koźmińskiego - jest tam MBA IT, czyli MBA z dodanym semestrem na temat zarządzania IT. Nie jest to jednak alternatywa dla poprzednich dwóch - temat zarządzania IT potraktowany jest bardziej ogólnie, no i koszt trzykrotnie większy. Odradzałbym eksperymenty w stylu Zachodniopomorskiej Szkoły Biznesu - studia tanie bo dofinansowane z UE, ale program bardzo ogólny i nie zawiera żadnych konkretów. Mam wrażenie, że to pomysł ad hoc na fali wykorzystania funduszy szkoleniowych z UE.

Dziwne, że reszta kraju milczy - wykładowcy z Wrocławia, Gdańska jeżdżą na wykłady do Warszawy? Ciekawostką jest Zakład Zarządzania Technologiami Informatycznymi - jedyna chyba w Polsce placówka zajmująca się profesjonalnie badaniami i dydaktyką w zakresie zarządzania IT. Dlaczego jeszcze nie zorganizowała studium podyplomowego?

A Kraków? - ewidentnie potencjał tkwi w Uniwersytecie Ekonomicznym - zaczynają się dwa nowe kierunki MBA (in e-Biznes i in Technology), ale może to być powtórka z Koźmińskiego. Śpi Wydział Zarządzania AGH. Coś zaczyna się dziać w Krakowskiej Szkole Wyższej im. Frycza Modrzewskiego (studia podyplomowe z bezpieczeństwa i audytu oraz studia II stopnia z informatyki zarządczej).

Lean ITIL inaczej

Oto majstersztyk reklamy. Hank Marquis wyjaśnia w artykule Justifying ITIL jak za pomocą ITIL sprytnie zredukować koszty. Przykłady ciekawe - zaczepnięte z praktyki. Choć w ITILu nie chodzi chyba o to, aby redukować koszty, ale o to, aby automatyzować operacje. Ale cóż - w ciężkich dla kosultantów czasach trzeba sobie jakoś radzić.

Lean in Services

Witam,

dziś skończyłem analizować Internet pod kątem zastosowania praktyk Lean w przedsiębiorstwach usługowych, a w szczególności IT. Na mojej stronie jest eksport z MindMapy z najważniejszymi hasłami i linkami. Jakie wnioski?

Koncepcje Lean in Service, często ograniczane do Lean in Office pojawiają się na początku tego stulecia po krachu bańki internetowej. W obecnej chwili istnieje bogata literatura na ten temat, zajmują się tym Uniwersytety (Cardiff - UK i Harvard - USA) a także sporo firm konsultingowych. Można powiedzieć, że jest to faza intensywnego wzrostu. W Polsce temat został zauważony i pojawiło się kilka szkoleń na ten temat.

Lean in IT pojawia się w komentarzach, udało mi się znaleźć 2 książki na ten temat, niemniej jednak prawdziwa popularność i rozwój nastąpi dopiero w najbliższych latach. Zainteresowanie można kojarzyć z krachem finansowym. Ciekawym zagadnieniem jest ruch Agile, który rozwijał się równolegle z Lean in Service, ma bardzo zbliżone założenia do Lean, aczkolwiek prawdopodobnie powstanie Agile nie było inspirowane Lean. W Polsce jest 1-dno szkolenie z tego tematu "Kaizen IT" i kilka osób zajmujących się tym w dużych korporacjach.

Można by się pokusić o prognozę rozwoju tych koncepcji.

• Lean in Service (Office) niewątpliwie będzie się rozwijać intensywnie w Polsce w okresie najbliższych dwóch lat. Potem może nastąpić nasycenie rynku.
• Lean in IT w Polsce to raczej perspektywa kilku lat (5-6), choć najbardziej innowacyjne firmy będą eksperymentować w najbliższych latach.
• Lean in ITSM należy traktować jako swego rodzaju wyróżnik wśród konkurencji, sam w sobie prawdopodobnie nie stworzy samodzielnego rynku zarządzania.

Interesującą spekulacją może jaki termin zdobędzie większą popularność: Agile czy Lean? Czyli jaka będzie informatyka: zwinna czy szczupła. Za Agile przemawia zakorzenienie w środowisku. Za Lean presja zewnętrznego środowiska biznesowego.

Zły język czy złe zastosowanie?

Spotkaliśmy się wczoraj o Cafe Dynia i dyskutowaliśmy o wzbogaceniu serwisu w treści społecznościowe (blogi, artykuły). Co rusz jakieś stwierdzenie uczestników prowokowało dyskusję.

Już widziałem rozpalone twarze młodych informatyków spierających się o to czy Java jest zła. Mnie osobiście (jako, że nigdy nie programowałem profesjonalnie) takie podejście przypomina dyskusję o wyższości Świąt Bożego Narodzenia nad Wielkanocą. Zaryzykuję stwierdzenie, że każdy język programowania został stworzony do rozwiązania jakiegoś problemu i jeśli się sprawdził, to stał się popularny. Kłopot zaczyna się wtedy, gdy język programowania (albo jakieś inne narzędzie) staje się na tyle popularne, że stosujemy je nie kierując się racjonalnymi przesłankami, ale emocjonalnymi. Krótko mówiąc: bo taka moda, bo kolega mi doradził, bo szefowie się to podoba. Może tego powinno się uczyć na uczelni: co i do czego stosować, a nie co jest fajne, a co nie.. Co Wy na to?

A propos spotkania - prowadzący panował nad sytuacją i temperatura nie podniosła się ponad niekontrolowany poziom.

Grupy i networking

Witam dziś jeszcze raz,

ewentualnym zainteresowanym polecam grupy na serwisach networkingowych: Plaxo, LinkedIn i GoldenLine. Linki i nazwy na mojej stronie www w sekcji "O mnie".

Konferencja!

Kolejny sukces: już mogę oficjalnie zaprosić na konferencję V Forum Wsparcia IT, gdzie będę prezentował Lean ITIL!

Korzyści i bariery

Zachęcił mnie tytuł "ITIL benefits and barriers to success" i przeczytałem wstęp do raportu Computer Economics na temat przeszkód i korzyści z ITIL-a. Tabelka ładna, ale moim zdaniem wśród korzyści z ITIL-a pozostawiłbym dwie fundamentalne:

• łatwiej się "sprzedaje" informatykę
• organizacja procesowa i usługowa jest "przyjaźniejsza" dla zmian, które są koniecznością biznesową.

Warto zacytować klasyka jakości Williama E.Deminga

It is not necessary to change. Survival is not mandatory.

oraz znanego wszystkim Karola Darwina

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.

Odnosząc to do informatyki - przetrwa i odniesie sukces ta organizacja IT, która potrafi zmieniać się zgodnie ze zmianami środowiska biznesowego. Pod pojęciem organizacji mieści się tu konkretny zespół ludzki z konkretnym liderem. Nieprzypadkowo Barack Obama wstawił do swojej kampanii "Change".

PS. Analogicznie dochodzimy do sedna problemów z wdrożeniem ITIL-a - odporność organizacji na zmiany.

ISO 20 000

Uff! Nareszcie skończyłem męczyć normę. Tradycyjnie wyciąg najważniejszych rzeczy jest tu. Skończyłem pisać artykuł, więc niebawem pojawi się w jakiejś formie w sieci. Może kiedyś się skuszę na uzyskanie tytułu audytora wewnętrznego? Ciekawe, że szwagier, który z usługami nie miał nic do czynienia ma ten tytuł - wystarczyły studia podyplomowe zarządzanie jakością :)!

Toyota Production System

W tym tygodniu skończyłem wreszcie lekturę obowiązkową menedżera: Jeffrey K. Liker "Droga Toyoty". To na co zwróciłem uwagę zamieściłem w postaci konspektu. Czytając inne publikacje na ten temat odnajduję wciąż pytanie: co takiego fenomenalnego jest w stylu zarządzania Toyoty (TPS - Toyota Production System), co jest podstawą? Ja osobiście wyróżniłbym następujące sprawy:

1. Szacunek do ludzi, którzy pracują - ciekawostką jest odwrócona hierachia służbowa - pracownik wykonuje pracę, a każdy koleny stopień zarządania pomaga mu ją wykonać.
2. Idea dodawania wartości - Lean Thinking - produkt czy usługa jest efektem dodania wartości pracę do surowców, watość zmniejszają błędy, opóźnienia i innego rodzaju straty. Ich eliminacja pozwala zapewnić najwyższą możliwą produktywność.
3. Dążenie do doskonałości - zakłada się, że każdą pracę można wykonać lepiej i zawsze istnieją błędy, które można wyeliminować. Temu służy nieustanny proces doskonalenia (kaizen).

Jednak to nie jest sedno sprawy moim zdaniem. Siła TPS wynika z tego, że powyższe zasady stosuje każdy pracownik (samopodobieństwo organizacji) i czuje się on odpowiedzialny za własne postępowanie (samoświadomość). Efektem tego jest skoordynowane działanie wielkiego zespołu jakim jest cała firma na rzecz klienta.

Sukces!

Oto pierwszy mój artykuł. Nigdy nie myślałem, że będę publikował. Polecam lekturę - oceńcie sami.

Świadomość ITIL-a

Wczoraj uczestniczyłem w prezentacji ITIL-a zorganizowanej przez krakowski SPIN (reklamowała to inicjatywa ITwKrakowie). Wystąpił Pan Ireneusz Górniok współpracujący z CTPartners. Oprócz wyjaśnienia istoty ITIL-a (z dowcipnym odniesieniem geograficznym) usłyszałem dlaczego należy stosować ITIL (a właściwie ITSM). Otóż jak stwierdził prelegent "po co wymyślać koło?". W tym miejscu całkowicie się z nim zgodzę - przeczytanie nawet skróconego opisu procesów ułatwia menedżerowi IT zarządzanie infrastrukturą - wszystko jakby staje się naturalne i oczywiste. Jest jeszcze drugi powód - również wspomniany w prezentacji: pieniądze. Dzięki ITIL-owi menedżerowi IT łatwiej jest sprzedać swoje usługi, względnie uzasadnić wydatki na sprzęt i oprogramowanie. Mało tego - dzięki podejściu usługowemu studzi się szkodliwe emocje pod tytułem: "kupimy nowy serwer, od razu się poprawi" - usługa wymaga zaplanowania, wdrożenia i ustabilizowania się w utrzymaniu... Przejście infrastruktura-usługa jest analogiczna jak aplikacja-projekt. Biznes zaakceptował już potrzebę istnienia projektów, zaakceptuje więc istnienie usług.

Pytałem Pana Ireneusza czy spotkał się z praktyką, że Dział Programistyczny (Developmentu) wdraża usługę? Nie potrafił podać takiego przykładu. I tu moim zdaniem tkwi sedno kłopotów z wprowadzaniem ITIL-a. Dopóki cały dział IT nie zacznie myśleć usługowo nie będzie pełnego sukcesu z wprowadzenia zarządzania usługami. Trzeba w tym miejscu zaznaczyć, że zmiana świadomości developerów jest trudna, choć możliwa i konieczna. Analogiczne opory mentalne mają administratorzy przy zaakceptowaniu wagi projektów i zarządzania projektami.

Jak jednak zmienić świadomość całego działu IT? Po pierwsze nie rozdzielać Project Management od Service Management. Sprytny menedżer infrastruktury IT powie tak: "OK będziemy wspierać projekty z ponadprzeciętnym zaangażowaniem, ale jest jeden warunek: to muszą być projekty usług!" Po drugie zamieniać się rolami - niech programista trochę posiedzi w Service Desku, a administrator niech poużera się z biznesem przy projektach...

Na koniec podam kilka wartościowych linków, które udostępnił Pan Ireneusz:

• sporo materiałów na blogu dot. ITSM
• kolejna społeczność ITIL-owców
• o ITIL-u w formie Wiki

10 warunków na udane wprowadzenie ITIL

Polecam dobry tekst! Hank Marquis opisuje jakie cechy powinna mieć organizacja, która z sukcesem wprowadzić ITIL (lub ITSM):

1. Cała organizacja IT musi zaangażować się we wprowadzanie ITIL-a, a nie tylko Dział Infrastruktury, Operacji czy jak go tam zwał (analogicznie ma się rzecz z metodyką projektową)
2. Wprowadzenie ITIL-a to sprawa IT, a nie biznesu, tak jak inwestujemy w sprzęt, aby lepiej działało, w kompetencje pracowników tak należy zainwestować w organizację pracy!
3. Bez zgody najwyższego kierownictwa i zaangażowania większości menedżerów ani rusz
4. Dobra rada dla konsultantów: wprowadzenie ITIL-a trzeba zaplanować z uwagą na "quick wins" - biznes i Top Management musi szybko widzieć pozytywne rezultaty, z czasem można rzadziej planować "quick wins", jeśli zwiększy się cierpliwość w/w
5. Wprowadzenie ITIL-a to program trwający 1-3 lat, trzeba podzielić zagadnienie na krótkie projekty, które ewolucyjnie przekształcają organizację. Rewolucja zajdzie w sposobie myślenia, rozmawiania i zarządzania.
6. ITIL wymusza myślenie procesowe: role i przepływy.
7. ITIL wymaga ciągłego usprawniania, a więc podejścia jakościowego (CSIP, PMF, QMS, kaizen)
8. Wprowadzenie ITIL-a musi podlegać rygorom Project Managementu, z wszystkimi tego konsekwencjami - budżet, czas, efekty.
9. Największym ryzykiem jest niechęć pracowników do zmian. Jak tego uniknąć - osobiście ich zaangażować w poprawę.
10. ITIL-a nie zrobią za organizację doradcy, trenerzy czy sprzedawcy oprogramowania. ITIL-a kierownictwo musi chcieć ("change desire") i włożyć niemały wysiłek w naukę, zmianę i jej utrwalenie. Doradcy, trenerzy jedynie pomagają w konkretnych trudniejszych kwestiach z uwagi na ich doświadczenie oraz moderują nasze wysiłki, aby nie wejść w przysłowiowe "maliny".

Ja bym to skrócił do następujących kwestii:

1. Właściwe nastawienie kierownictwa (#1, #3, #9, #10)
2. Odpowiednie podejście (#4, #5, #8)
3. Adekwatne cele (#6, #7, #2)
   

Lektura na wolne wieczory (o ile jeszcze istnieją;))

Dziś wpadł mi w oko króciutki artykuł o obowiązkowych lekturach dla menedżera. Ja wybrałbym trzy:

• "The 7 Habits of Highly Effective People" by Stephen Covey, about improving your (working) life
• "To do, Doing, Done" by G. Lynne Snead and Joyce Wycoff, on project management and organization
• "Managing in turbulent times" by Peter F. Drucker

ITIL dla MŚP

Dziś jeszcze coś dla MŚP. Malcolm Wheatley przytacza 3 przypadki wprowadzenia ITIL do małych organizacji IT (6, 10 i 43 osobowych). Najważniejsze według niego to zacząć od procesu, który nam najbardziej doskwiera (może to być Change Management, którego brak może powodować do 80% incydentów). W większości przypadku jest to jednak Incident Management, dalej wybiera się kolejne procesy i praktyki, ale zawsze wedle klucza "które nam pasują", czyli ITIL-owe "adopt and adapt". Niecierpliwym trzeba przypomnieć, że ITIL to nie jednorazowa akcja, ale ciągłe doskonalenie działalności małymi krokami (kaizen!). Sama "zgodność" z ITIL, czy certyfikacja ISO jest sprawą przydatną, ale niekonieczną.

The four big questions ITIL

Dziś przyglądnę się "czterem wielkim pytaniom ITIL" Roba Englanda.

Pierwsze pytanie: "Should We do ITIL?", czyli po polsku Czy powinniśmy zajmować się ITIL-em?.
Z punktu widzenia społeczności ITIL odpowiedź jest oczywista: Tak, w końcu to uznane praktyki, a po za tym napędzi to nam biznes... . Jeśli jednak przypomnimy sobie, że ITIL to tylko jeden ze schematów zarządzania usługami (ITSM), odpowiedź już nie jest taka prosta: Być może, ale na pewno powinniśmy robić zarządzanie usługami. Kwestia wyboru schematu zarządzania to temat na co najmniej pracę magisterską, jeśli nie doktorat, punkty startowe znajdziemy u Roba i tu.

Drugie pytanie: "To what level should we do it?".
Załóżmy, że chcemy robić ITSM i wybraliśmy ITIL. To w końcu kilkanaście tomów dobrych praktyk? Wszystko zaimplementować? Myślę, że powinniśmy się tu kierować racjami ekonomicznym: wprowadzanie praktyk ITIL to swego rodzaju inwestycja w organizację - musi się zwrócić. Jeśli zyski z wymyślenia, przećwiczenia i sformalizowania pewnych procedur są niezauważalne (n.p. bo Availability Request występuje raz na miesiąc) to po co się wysilać? Tylko po to, aby nakleić nalepkę "100% ITIL compliant!".

Trzecie pytanie: "How do you do it?"
Zanim jednak odpowiem na pytanie trzeba się zastanowić co będziemy "robić". Czy ITSM czy ITIL? Jeśli ITSM - to moim zdaniem sprawa jest prosta - trzeba "jedynie" dopasować IT do biznesu, a więc:
1) "przemalowujemy" tak interfejsy systemów IT, aby użytkownik widział "Service Architecture", a nie Configuration Items,
2) wprowadzamy User Friendly Service Support, a więc Service Desk (jako SPOC - Single Point of Contact), a zgłoszenia obsługujemy wedle Service Catalogue,
3) wprowadzamy Service Delivery i Level Agreements (SLA/OLA) najlepiej poprzez specjalnego "oficera łącznikowego biznes-IT",
4) wprowadzamy Service Development i Decommisioning, aby się samo kręciło.
Jeśli zaś chcemy "zrobić" ITIL - sprawa jest trudniejsza: trzeba skonstruować coś w rodzaju mapy implementacji procesów i żmudnie krok po kroku zgodnie z cyklem Deminga planować, wypróbowywać, weryfikować i formalizować. Niestety sprawa wydaje się być niekończącą się opowieścią, gdyż biblioteka puchnie, praktyk przybywa, a proces wprowadzania praktyk jest nader uciążliwy i wolny.

Czwarte pytanie: "How do we show we did it?"
Analogicznie do trzeciego pytania w przypadku ITSM sprawa jest prosta - pokazujemy Architekturę Usług (Service Architecture), Katalog Usług (Service Catalogue). Potem oprowadzamy po Stanowisku Obsługi Zgłoszeń (Service Desk) i przedstawiamy osobę odpowiedzialną za kontakty biznes-IT, która pokazuje Uzgodnienia poziomu usług (Level Agreements). Na koniec jeszcze możemy pokazać metodykę wdrażania usług i ich wycofywania.
W przypadku ITIL-a będzie trudniej - trzeba omawiać proces po procesie i uważać, żeby ktoś nie powiedział "to jest niezgodnie z biblioteką, patrz strona XX, wers YY, książka ZZ" :(.

Zapoznałem się pobieżnie ze standardem ISO 20000. I jakie wnioski?
Odradzam kupowanie obu standardów (przeszło 160 zł). Moim zdaniem w zupełności wystarczy przeczytanie (20% ceny - 12 zł) w serwisie eNormy części pierwszej (ISO/IEC 20000-1:2007). Jest to specyfikacja, a więc to co potencjalnie będą wymagać audytorzy. Można też zapoznać się z prezentacją audytora wiodącego ten normy, Pana Marcina Majdeckiego z DNV. Wartościowe są też komentarze "dyżurnego sceptyka IT", Roba Englanda.
Norma na pierwszy rzut oka wydaje się być mocno niedopracowana. Tłumaczenie jest miejscami dziwaczne, można porównać ze świetnym słownikiem ITIL opracowanym przez itSMF Polska. Ponadto część 2 ma stanowić rozwinięcie części 1 o dobre praktyki, ale jakoś obie części nie przystają do siebie (na przykład część o systemie zarządzania). Spaprany został opis cyklu Deminga - o ile wyjaśnienie trzech pierwszych literek (PDC) ma sens, o tyle A (ang. Act) jest określone jako "ciągłe doskonalenie (działaj)". Tymczasem w oryginalnej koncepcji Deminga A oznaczało "Zastosuj" w sensie ustawodawczym (notabene angielskie ustawy nazywają się właśnie "Act"). Właściwe znaczenie całkowicie się zagubiło. Na usprawiedliwienie twórców normy można podać przykład książki OGC "Introduction to ITIL", gdzie Act znaczy tyle co "adjust plan" i też nie mogłem tego zrozumieć.
Ponadto widać znaczące uproszczenia w stosunku do ITIL (na przykład w rozdziale dotyczącym incydentów klient (!) zgłasza incydenty, żądania usługi oraz dostaje powiadomienia o obniżeniu poziomu usług). Jest to jednak zrozumiałe - trudno byłoby zestandaryzować cały zasób wiedzy ITIL - taka norma byłaby zupełnie nieużyteczna.
Mimo wszystko uważam, że pierwsza część (ISO/IEC 20000-1:2007) powinna być obowiązkową lekturą dla każdego ITSM-owca (ITIL-owca ;)). Wprowadza pewien punkt odniesienia co do tego, co znaczy "wdrożyć zarządzanie usługami". Przeczytam i z niecierpliwością będę czekał na wersję poprawioną.
A tak zupełnie na marginesie to przyszedł mi pomysł na nowy temat do analizy: czym jest tak naprawdę ITIL, ITSM, ISO 20000?

PS. Dla fanatyków jest fachowe porównanie normy i biblioteki, jak również draft 3-ciej części normy. Zabawne: wczoraj draft o numerze N3934 jeszcze był w sieci, a dziś już nie mogę go znaleźć. Dobrze, że mam kopię w PDF...

Dziś pierwszy dzień blogowania, właśnie powstaje koncepcja "Szczupłego" zarządzania infrastrukturą