Najgorsze praktyki

Równolegle z rozwojem najlepszych praktyk - umożliwiających efektywne zarządzanie - organizacje dopracowały się równie bogatego zbioru najgorszych praktyk, których wdrożenie, zamiast optymalizacji zarządzania usługami IT, powodowało ich degradację i paraliż organizacji.

Równolegle z rozwojem najlepszych praktyk - umożliwiających efektywne zarządzanie - organizacje dopracowały się równie bogatego zbioru najgorszych praktyk, których wdrożenie, zamiast optymalizacji zarządzania usługami IT, powodowało ich degradację i paraliż organizacji.

Najsłynniejsze z - wypracowanych w ciągu kilkunastu lat - praktyk i modeli zarządzania, wsparcia, utrzymania i rozwoju usług IT to: ITIL, COBIT, CMM/CMMi, a także wiele norm ISO, pomysłów adaptacji kaizen do zarządzania IT oraz innych - mniej lub bardziej abstrakcyjnych - idei, które mają pomóc w sprawnym kierowaniu działem informatyki. Równolegle z rozwojem najlepszych praktyk efektywnego zarządzania, niejako w tle, organizacje dopracowały się równie bogatego wzoru najgorszych praktyk. Są to przypadki, w których błędne założenia, zaniedbania, niemal celowy sabotaż - zamiast optymalizować zarządzanie usługami IT - powodowały ich degradację i paraliż organizacji. O ironio, większość z nich została wypracowana w firmach z dużym doświadczeniem oraz ogromnym potencjałem środków finansowych, technologicznych i ludzkich.

Polski rynek wciąż chętnie chłonie koncepcje wspomagające wprowadzanie tzw. usługowego IT. Wynika to po części z ogólnej dynamiki rozwoju gospodarki, a także z powodu pewnych zapóźnień. Działy IT, jak również firmy usługowe IT, dopiero od kilku lat uczą się tego, co międzynarodowe korporacje wypracowywały od lat 80. XX wieku. Zdobywamy coraz więcej wiedzy o zarządzaniu IT czy reengineeringu procesów biznesowych. Jednak przy wdrażaniu popełniamy wiele błędów, które psują cały efekt związany z optymalizacją procesu świadczenia usług. Doświadczenie korporacji międzynarodowych, a także przypadki z rynku polskiego, doskonale pokazują, czego należy się wystrzegać, aby nie zepsuć procesu tak ważnego, a równocześnie tak prostego, jak optymalizacja i świadczenie usług.

Turyści i tubylcy

Jednym z poważniejszych błędów przy projektach reengineeringu procesów biznesowych w IT, a także wdrożenia modeli opartych na ITIL, jest opór wewnętrzny organizacji. Reorganizacja działów ogranicza się często do wprowadzenia tam gruntownie wykształconych menedżerów, a firma nie robi nic, aby zmienić świadomość pracowników i organizacji poniżej szczebla kierowniczego.

Menedżer - próbujący realizować zmiany w takim zespole - jest jak turysta w obcym kraju. W wielu firmach zresztą takie sformułowanie jest powszechnie używane do określania ludzi wstawionych odgórnie w organizm funkcjonujący od lat tym samym trybem. Turyści, w rozumieniu tubylców, powinni: szybko się znudzić i wyjechać, albo z czasem zasymilować się z tubylcami w ich "tumiwisizmie". Dla tubylców zmiany są synonimem pogorszenia sytuacji. Będzie więcej pracy, będą bardziej patrzeć na ręce. Nikt im nie wyjaśnił, o co tak naprawdę chodzi. Nikt też nie podjął trudu, aby ich nie spacyfikować. Dlatego zrobią wszystko, by wygonić turystów ze swojego terytorium.

Co zrobić w takiej sytuacji? Jedno nie ulega wątpliwości. Współczesny biznes to ciągle zmieniające się środowisko i warunki. Zmiany są konieczne. Obserwując rynek IT można wręcz dojść do wniosku, że żyjemy w okresie zmiany progresywnej i ciągłej. Aby jednak ich dokonać, także wewnątrz firmy, trzeba poznać argumenty obu stron. Turyści powinni mieć świadomość odmienności kulturowej tubylców. Oni są inni - mają swoje przekonania, żyją w innym świecie (np. słowa ITIL, CMMi, a nawet efektywność czy zarządzanie mogą w ich języku oznaczać obrazę przekonań), starajmy się więc im pokazać, że w naszym języku sformułowania te oznaczają rzeczy dobre.

Z drugiej strony tubylcy powinni próbować przynajmniej zrozumieć, że turyści nie naruszają naszego świętego terytorium, ale w realiach innego, zewnętrznego świata być może wręcz pomagają przetrwać. Mają środki i narzędzia, aby nie dopuścić do rozwiązań ostatecznych, np. totalnego outsourcingu usług informatycznych. Czy takie porozumienie pomiędzy turystami i tubylcami jest możliwe? W wielu firmach to się udało. Kluczem do zrozumienia osób wprowadzających zmianę i tych, których ma objąć, jest zdefiniowanie wspólnych celów, takich jak odczuwane przez klienta biznesowego zadowolenie z pracy działu IT, gwarantujące długotrwałość relacji, a więc niechęć do outsourcingu.

Gdy mamy wspólny cel, najtrudniejszym zadaniem staje się zbudowanie wspólnej świadomości, jak go realizować. Czasem oznacza to kompromisy, czasem trudne decyzje o wykluczeniu najbardziej opornych tubylców. W ten sposób z czasem uda się stworzyć odpowiedzialny i świadomy swojej rzeczywistej roli zespół. Im szybciej pojawią się efekty - takie jak zadowolenie klienta biznesowego, mniejsze obciążenie IT, optymalizacja budżetu - tym szybciej zespół zacznie wierzyć w misję menedżera i w to, że pewne rzeczy można udoskonalić.

Skąpstwo

Innym kardynalnym błędem popełnianym podczas wprowadzania w firmie najlepszych praktyk związanych z zarządzaniem jest skąpstwo. Jego objawem jest przykładowo uzależnianie premii kadry zarządzającej od oszczędności w budżecie, a nie od efektów biznesowych. Wynikiem tego jest często paraliż decyzyjny i brak rozstrzygnięć o nawet najbardziej niezbędnych wydatkach. Znam przypadki firm, które promując się na rynku jako lider projektów związanych z ITIL i certyfikacją BS15000 oszczędzały nawet na szkoleniach ITIL Foundation. Szkolenia przeszła kadra zarządzająca, dla zespołów operacyjnych okazały się one za drogie.

Jaki z tego morał? Pomimo powszechnej i zrozumiałej tendencji do cięcia kosztów warto inwestować zarówno w zasoby ludzkie, jak i niezbędne technologie czy elementy infrastruktury. Koszty zaniechania są dużo wyższe niż wydatki poniesione na zapobieganie problemom. Menedżerów zaś warto rozliczać z wyników, a nie przyniesionych oszczędności.

Za, a nawet przeciw

Kolejnym błędem bywa brak zaangażowania kluczowych decydentów i głównych dostawców, który potrafi zniweczyć nawet najbardziej ambitne projekty zmian. W przypadku międzynarodowych korporacji scenariusz najczęściej wygląda tak.

Podejmują one decyzję - wdrażamy zarządzanie procesowe, np. w oparciu o ITIL. Menedżerowie średniego szczebla boją się zmian, ale nie wystąpią przeciw decyzji korporacji. Wyznaczają więc kierownika projektu, dobierają mu zespół, albo nawet zostawiają go z problemem - dobierz sobie ludzi, ale poza tymi zaangażowanymi operacyjnie. Nie wspierają też projektu odpowiednimi decyzjami, nieoficjalnie wręcz krytykując zmiany. Blokują przy tym komunikację z korporacją i klientami biznesowymi. A wobec pierwszych niepowodzeń wycofują się mówiąc, że projekt nie spełnił zadań.

Czasem opór menedżerów wynika z obaw przed tym, co powie "góra". Pomimo jej decyzji o realizacji projektu, mimo wyraźnego dążenia do wdrożenia modeli zarządzania usługami, menedżerowie podpierają się "delikatną sytuacją polityczną", np. zależnością polskiego oddziału od centrali w Wlk. Brytanii, Francji lub innym kraju. Nie zauważają, że to właśnie centrala oczekuje zmian i zatwierdziła projekt do realizacji.

Na początku było słowo…

… a słowo brzmiało ITIL. Modele zarządzania - niezależnie od ich pochodzenia - coraz częściej stają się biblią, i to rozumianą literalnie. Tendencję do takich postaw wykazują zwłaszcza firmy doradcze. Żaden model - ITIL, kaizen, COBIT - nie nadaje się do wszystkiego. Powinny to rozumieć zwłaszcza firmy dostarczające rozwiązania IT.

Nawet teoria ITIL mówi o przyswojeniu (adopt) i dostosowaniu (adapt) filozofii, a nie o wdrożeniach "zgodnie z literą prawa". Jeśli ktoś szuka sztywnych reguł, proponuję normę ISO 20000 opartą na ITIL, ale bardziej sformalizowaną. Jeśli jednak zależy nam na rozwiązaniach odpowiadających wymaganiom klienta, warto korzystać również z innych referencji. Wybór jest spory i niemal wszystkie modele zapewniają integrację z innymi.

Zanim powiesz "tak"

Podobnie jak z małżeństwem, w zmianach obejmujących reinżynierię procesów, należy się najpierw zastanowić, na czym nam zależy. Powinni to zrobić zarówno klienci, jak i dostawcy usług. Błędy takie jak te wymienione powyżej przyczyniają się nie do optymalizacji, ale do degradacji usług i procesów. Wiem, wiem, w raportach świadczenia usług zawsze można coś naciągnąć, klientowi zawsze można opowiedzieć coś o "czynnikach zewnętrznych", klauzulach itp., a na dostawcę nałożyć karę. Tylko czy tak naprawdę chodzi nam o zaleczenie choroby, czy o szczepienie, by nie wystąpiła?

Przemysław Wysota jest menedżerem ds. zarządzania jakością IT w międzynarodowym koncernie Diebold.