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