Aby systemy informatyczne były efektywnie wykorzystywane, muszą być wdrażane przez biznes - stwierdza Marek Szelągowski, dyrektor Biura Informatyki w Budimex SA, w rozmowie z Robertem Jesionkiem.

Kim według Ciebie jest polski CIO?

Marek Szelągowski: Przez ostatnie lata CIO niewątpliwie stał się pełnoprawnym członkiem zespołu zarządzającego przedsiębiorstwem. Nie jest już tylko "specem od komputerów", chociażby dlatego, że same komputery nie stanowią już o przewadze, jaką przedsiębiorstwo może osiągnąć dzięki wykorzystaniu informatyki. Musi więc dbać o śledzenie i nadążanie za rozwojem IT, a równocześnie, jak każdy menedżer, powinien zarządzać powierzonym mu majątkiem. I nie są to serwery czy stacje robocze ani nawet aplikacje lub bazy danych. W gospodarce wiedzy są to ludzie należący do zespołu IT. Dlatego analizując obowiązki i zakres działań CIO, zawsze powinniśmy brać pod uwagę dwa aspekty jego pracy: zarządzanie wykorzystaniem technologii informatycznych oraz zarządzanie zespołem IT. W Grupie Budimex, w której mam przyjemność pracować, powoduje to istotną różnicę między misją Biura Informatyki - "Wspieranie i stymulowanie biznesu poprzez ciągły rozwój świadczonych usług oraz utrzymanie eksploatacji na jak najwyższym poziomie" - a misją dyrektora Biura Informatyki - "Wspieranie i stymulowanie zespołu do ciągłego rozwoju, biznesu do ciągłego wymuszania wzrostu nowoczesności i niezawodności świadczonych usług oraz ciągłe obniżanie kosztów".

Zobacz również:

• 9 cech wielkich liderów IT
• CIO "bumerangi": liderzy IT awansują, powracając
• 6 znaków ostrzegawczych, na które CIO powinni zwrócić uwagę w 2024 roku

Jak widać z tego przykładu, tylko część obowiązków CIO jest widoczna dla reszty organizacji. Znaczna część jego pracy pozostaje dla innych pracowników niewidoczna, i przez to zazwyczaj jest ona po prostu niedoceniana. Tak się jednak składa, że jest to część podstawowa, bez której trudno mówić o wiarygodnym i stabilnie rozwijającym się zespole IT. Pozwala to określić 4 zakresy pracy CIO.

Jakie to obszary?

- Po pierwsze, technologia. Jest to obszar, który wymaga uporządkowania i systematycznego rozwoju zgodnie z rozwojem dostępnych technologii oraz z możliwościami zespołu IT. Pierwszymi krokami podjętymi w tym obszarze w czasie budowy Biura Informatyki Budimex było uproszczenie i standaryzacja środowiska informatycznego, poprzez:

1. korporacyjną standaryzację

2. unifikację, centralizację, wewnętrzną integrację i jednolitą politykę bezpieczeństwa. Zostały więc ujednolicone zasady zakupu komputerów, serwerów, urządzeń aktywnych itp., tak aby zminimalizować liczbę urządzeń zapasowych, dostawców i firm serwisowych. Równocześnie pozwoliło to znacznie ograniczyć różnorodność potrzebnych szkoleń, a także zmaksymalizować wymienność kadr.

A w kwestii zarządzania zespołem IT?

Szybkość wchodzenia w nowe technologie czy zakresy prac musi odpowiadać rozwojowi zespołu, jego umiejętnościom profesjonalnym, ale także wewnętrznemu zgraniu. W podnoszeniu umiejętności profesjonalnych podstawowym elementem było połączenie doświadczenia i wiedzy ogólnej oraz dzielenia się wiedzą w celu jak najszybszego praktycznego jej wykorzystania i umożliwienia zdobycia kolejnych doświadczeń. Jest to chyba najbardziej skuteczny sposób uczenia się nie tylko pojedynczych osób, ale przede wszystkim zespołów. (W Biurze Informatyki Budimex w ostatnim roku trzy osoby skończyły studia, a siedem osób studiuje na różnych poziomach nauczania). Z naszego doświadczenia wydaje się, że wewnętrzne porozumienie w zespole IT, uznawanie tych samych zasad jest często nawet ważniejsze niż umiejętności profesjonalne. Zespół IT w Grupie Budimex powstawał poprzez integrację 7 czy 8 komórek informatyki w poszczególnych spółkach Grupy. Główne problemy w fazie tworzenia zespołu związane były nie z brakiem umiejętności profesjonalnych, ale właśnie z ogromnymi różnicami w kulturze pracy, którą poszczególne osoby wyniosły z poprzednich miejsc zatrudnienia. W tej chwili, po 4 latach wspólnej pracy, podstawowe zasady, takie jak dzielenie się wiedzą, mówienie o złych rzeczach od razu, karanie za bierność, wydają się proste i naturalne. Ale przez pierwszy rok głównymi problemami były: niechęć do dzielenia się wiedzą ("jak przekażę, co wiem, to mnie zwolnią"), ukrywanie problemów ("może się nie wyda, a może ktoś inny w to wdepnie"), strach przed okazaniem niewiedzy ("nikt się nie zorientuje, że tego nie wiem"), unikanie poszukiwań rozwiązań ("lepiej nie robić, bo jeszcze się coś zepsuje") lub po prostu bierność ("nie było rozkazu, to nie robię"). Były to więc wyraźnie problemy nietechniczne. Udało się je rozwiązać tylko dlatego, że ludzie wchodzący w skład zespołu "chcieli chcieć". Niewątpliwie prawdziwa jest więc teza Alvina Tofflera, której pierwszą część można sparafrazować: "Mając dobry zespół, a złą infrastrukturę można odnieść sukces". Jestem głęboko przekonany co do prawdziwości także jej drugiej części: "Mając doskonałą infrastrukturę, a zły zespół można być pewnym porażki". Dopóki zbiorowisko informatyków nie stanie się zespołem, w zasadzie trudno mówić o stabilnym wsparciu biznesu. W każdej chwili grozi bowiem katastrofa wynikająca z innego przyzwyczajenia albo podejścia do obowiązków przez różne osoby. W takiej sytuacji, tak jak i w przypadku braku odpowiednich umiejętności profesjonalnych, bezpieczniejszy jest nawet czasowy outsourcing, dający czas niezbędny do budowy i okrzepnięcia zespołu.

Na czym polega specyfika wsparcia biznesu przez IT w firmie Budimex?

To usługi IT widoczne dla reszty organizacji. Bardzo często wpływają one znacząco na biznes. To na podstawie ich poziomu oraz dostępności zazwyczaj oceniany jest CIO i cały zespół IT. To do nich odnoszą się wszystkie COBIT-y, ITIL-e itp. podobne koncepcje zarządzania tak chętnie sprzedawane przez liczne firmy konsultingowe. Nie znając jednak celów i procesów przedsiębiorstwa, łatwo może dojść do sytuacji, w jakiej zapewniamy wyśmienite SLA, mamy doskonałą dokumentację, czy też utrzymujemy system zawierający bardzo ciekawe dane, które nie są nikomu tak naprawdę potrzebne. Jeżeli IT ma być "centrum zysku", czyli zapewnić rzeczywiste wsparcie biznesu, niezbędne jest poznanie jego podstawowych procesów. Tylko poprzez nakierowanie na proces podstawowy możliwe jest usprawnianie procesów wspieranych przez IT, bez niebezpieczeństwa suboptymalizacji, czyli takiej optymalizacji, która dla procesu podstawowego może oznaczać zmniejszenie wydajności. Tylko poprzez bezpośrednią współpracę z działami i zespołami bezpośrednio realizującymi proces podstawowy IT jest w stanie uniknąć pułapki wspierania biurokracji ograniczającej i hamującej biznes. Dlatego oparliśmy wsparcie dla biznesu o uzgodnioną w ramach Budimeksu mapę procesów, z wyraźnym podkreśleniem procesu podstawowego, który decyduje o wynikach przedsiębiorstwa. Podejmując tę pracę 2 lata temu, nie przeszkadzał nam brak znajomości SOA, web services itp. Już z samej mapy procesów wynikała konieczność integracji aplikacji wokół procesu podstawowego, a co za tym idzie, ścisłej współpracy z działami biznesowymi Budimeksu. Problem zarządzania informacją pojawił się natychmiast po zidentyfikowaniu silosów informacyjnych, dzielących proces podstawowy na odizolowane i niekomunikujące się fragmenty. Po ustaleniu potrzeb informacyjnych poszczególnych procesów nasi koledzy z biznesu chyba zaczęli wierzyć, że rzeczywiście wspólnie możemy poprawić sytuację. Podstawą porozumienia między biznesem a IT nie była żadna z nowoczesnych metod zarządzania, ale uznanie, że pracujemy w jednym zespole. Wsparcie biznesu, a w zasadzie współpraca i wzajemna stymulacja biznesu i IT, nie opiera się na technologiach czy hardware, ale na zwykłym codziennym zaufaniu, którego nie wolno zawieść.

O czym powinien pamiętać CIO chcący realizować biznes swojej firmy?

Że IT nie powinno być centrum kosztów, ale centrum zysku, czy może raczej "centrum wspierającym wzrost zysku". Za wszelką cenę należy więc unikać usprawniania i optymalizowania liczenia strat. Nie ma sensu wdrażanie projektów, które nie wspierają procesu podstawowego, ale np. pozwalają na szybsze zebranie danych, których nikt nie analizuje lub których analiza nie ma wpływu na biznes. Równocześnie zespół IT powinien cały czas pamiętać, że to nieinformatycy wdrażają systemy. Systemy, ażeby były efektywnie wykorzystywane, muszą być wdrażane przez biznes. Dlatego zespół IT, dbając, aby był postrzegany jako część biznesu, a nie tzw. dyrekcji, powinien formalnie, a także nieformalnie realizować kilka zadań: pozyskiwać wiedzę o biznesie i jego potrzebach, oswajać biznes z nowymi możliwościami, jakie daje rozwój informatyki, aktywnie reagować na nieformalne pomysły wykorzystania IT, nawet te na pozór idące zbyt daleko, stymulować podnoszenie wymagań biznesu, wskazywać nowe obszary wykorzystania informatyki.

Z naszych doświadczeń wynika, że znacznie skuteczniejsze są kontakty i grupy nieformalne, takie jak np. działający w firmie Budimex community of practice zarządzania wiedzą. Pozwalają one w sposób miękki wspierać, a nawet stymulować kierunki wykorzystania IT bez obawy sformalizowanej biurokracji, planów, harmonogramów i całej niejednokrotnie paraliżującej odpowiedzialności. Wymaga to od obu stron chęci do poszukiwania często niekonwencjonalnych rozwiązań, a niejednokrotnie szacowania ryzyka i podejmowania wdrożeń pilotażowych czasami kończących się porażkami. Jeżeli ich zakres jest ograniczony, to i straty są zazwyczaj niewielkie. Natomiast w przypadku sukcesu niezbędne jest jak najszybsze znaczne rozszerzanie wykorzystywania wypracowanych rozwiązań. Jest to najtrudniejszy, ale i najbardziej efektywny sposób pracy zespołu IT.

Realizujesz obecnie projekt zarządzania procesowego w firmie Budimex. Na czym to polega?

Projekt ten rozpoczął się od budowy mapy procesów oraz uzgodnienia propozycji głównych mierników ich efektywności. Aby wyraźnie zaakcentować wagę mierników pozafinansowych, a równocześnie podkreślić źródła sukcesu finansowego, zbudowano mierniki dla wszystkich 4 płaszczyzn zrównoważonej karty wyników. Pozwoliło to z jednej strony dostrzec konieczność integracji aplikacji wokół procesu podstawowego. Z drugiej, uczuliło zespół projektowy na mierniki pozafinansowe, które mogłyby zostać niezauważone, mimo że to one obrazują rzeczywiste przyczyny wyników finansowych. W drugim kroku przygotowano wspólnie z biznesem pierwsze 2 procesy. Rozpoczęte wdrożenie pilotażowe pokazało 2 podstawowe grupy problemów. Po pierwsze, elementy kulturowe - niechęć do wymiany wiedzy i obawę przed zmianami. Użytkownicy systemu procesowego nadal myśleli kategoriami odrębnych aplikacji. Nie czuli potrzeby korzystania z zawartej w bazach procesowych wiedzy, więc tym bardziej nie chcieli z nikim dzielić się posiadaną wiedzą. Wdrożenie zaczęło grozić powstaniem teoretycznie niemożliwych "procesowych silosów informacyjnych". Po drugie, elementy technologiczne - zbyt małe możliwości integracyjne oraz zbyt mała elastyczność wybranego narzędzia. Wprowadzenie żądanych przez biznes zmian wymagało często poprawienia modelu procesu, a dopiero po jego uzgodnieniu przeprogramowania aplikacji wykonawczej. Zajmowało to tyle czasu, że nie było możliwości nadążenia z realizacją kolejnych zmian, a cóż dopiero z wdrożeniem delegowania uprawnień do indywidualizacji procesów.

I jak wybrnęliście z tej sytuacji?

Chłodna i uczciwa analiza wyraźnie wskazywała na konieczność jak najszybszej zmiany narzędzia i koncepcji wdrożenia. Oczywiście możliwe było kontynuowanie wdrożenia na zasadzie "idzie źle, ale zgodnie z procedurami", ale tę ewentualność wspólnie z kierującym wdrożeniem ze strony IT Pawłem Tecławem odrzuciliśmy od razu. Było to po prostu niezgodne z kulturą zespołu IT, którą współtworzyliśmy. Jak się okazało w czasie spotkania z Komitetem Sterującym IT, również jego członkowie uznali, że lepiej natychmiast naprawić błąd, niż brnąć w niesprawdzające się rozwiązanie. Po oficjalnym wybraniu Ultimus jako nowego narzędzia klasy BPM, przepisano w nim proces "Realizacja umowy z dostawcą" oraz zintegrowano w relacyjnych bazach danych wszystkie istniejące bazy wiedzy, oczywiście cały czas ściśle współpracując z Pionem Produkcji i Biurem Zakupów Centralnych. O ile w poprzednim narzędziu po 9 miesiącach pracy system z wielkim trudem wdrożony był na 8 budowach, to po zmianach w ciągu 6 miesięcy system działał już na 65 budowach oraz w całym Pionie Ekonomicznym Produkcji. Równocześnie zgodnie z koncepcją dynamicznego zarządzania procesami biznesowymi możliwe było znaczne przyspieszenie wdrożenia (dzięki uniknięciu paraliżu analitycznego związanego z koniecznością wstępnej szczegółowej identyfikacji procesów), intensyfikacja dzielenia się wiedzą (proces podstawowy jest podstawowym darmowym źródłem wiedzy), większe nakierowanie wspólnych działań na proces podstawowy (odejście od wertykalnych podziałów organizacji), bieżące śledzenie realizacji pracy, możliwość osiągnięcia "korzyści różnorodności" na skutek delegacji uprawnień i odpowiedzialności, przy zachowaniu kontroli (indywidualizacji procesów biznesowych), delegacja zarządzania do miejsca realizacji pracy, czyli możliwości i odpowiedzialności.