Temat: Modelowanie czy rysowanie
Marku, mógłby Pan odesłać mnie do tej Pańskiej opinii o ITIL? Ciekawi mnie.
Pomysł na Kaizen dla IT właściwie zasugerowali mi znajomi dyrektorzy IT, zmęczeni lawinami różnych "przełomowych koncepcji" o obowiązkowo dziwnie brzmiących nazwach i chronicznie nie zasługujących na zaufanie. Skorzystali, że mają życzliwego inżyniera przemysłowego (znaczy mnie :)) i poprosili o powrót do podstaw i do prawd elementarnych o zarządzaniu.
(Na przykład kiedyś dyrektor z IBM na konferencji zawile opisywał narzędzia, wyglądające na nader złożone, do czegoś, co nazwano "Asset management". Zorientowałem się, że na sali nikt go nie rozumie, więc zaproponowałem, aby nazwać te rzeczy tak, jak się to nazywa w normalnym przemyśle, czyli "karta/paszport urządzenia" i "karta pracy maszyny". Wszyscy się ucieszyli, łącznie z wykładowcą, bo nagle cała rzecz stała się jasna i zrozumiała. No i z takich właśnie zdarzeń wyrosła ta ich prośba o powrót do podstaw.)
W tym samym czasie jeszcze przypomnieli mi serię kilkunastu artykułów na ten temat w Computerworld (1998) - no i już nie było zmiłuj się, więc zrobiłem ten Kaizen w postaci 3 warsztatów.
Opracowując ten temat nie zamierzałem tworzyć jakiejś alternatywy dla ITIL-u, zwłaszcza że z historii wiadomo, iż koncepcje z pozoru alternatywne raczej się nawarstwiają, niż nawzajem wykluczają. Ale jakoś tak wyszło od początku, od mojej tyrady w sprawie TPM (Total Productive Maintenance) na spotkaniu Klubu CIO (nie mogę tego znaleźć w Internecie). Potem jeszcze Bartosz Górczyński zaprosił mnie na spotkanie ITIL-owców praktyków, na którym wyszło trochę kontrowersyjnych tez...
Tyle pokrótce z historii tematu.
A merytorycznie? To po prostu propozycja, aby menedżerowie IT i projektów IT, tzw. architekci i inni specjaliści skorzystali ze sprawdzonych, chociaż starych i nie tak pięknie brzmiących metod i koncepcji, które Japończycy wzięli od całego świata, a teraz cały świat bierze od nich. W programie także BPI (Business Process Improvement).
Postarałem się dobrać podejścia i techniki pod kątem problemów, na jakie natrafiają Słuchacze, dużo słuchałem. Obawiałem się, że mając tysiące przykładów z procesów produkcyjnych nie trafię do wyobraźni ludzi z IT, ale jest OK. Okazuje się bowiem, że tu jest tak, jak wszędzie - to nie technologia sprawia główne problemy, lecz normalne 'miękkie' czynniki. I dlatego te podejścia z Kaizen okazują się atrakcyjne dla Kolegów z IT.
пропозиції роботи
