Zmiany w relacjach między biznesem i IT – warto podjąć wyzwanie

Przeformułowanie relacji między IT i biznesem przynosi ogromne korzyści. Wprowadzenie nowej formuły wiąże się jednak z wprowadzeniem poważnych zmian, a często także z pokonaniem mentalnych barier.

Innowacyjność firm buduje się na dobrej współpracy i solidnych relacjach pomiędzy IT a biznesem. Realizacja celów biznesowych w dzisiejszej rzeczywistości nie jest możliwa bez bezpośredniej współpracy pomiędzy jednostkami biznesowymi, jednostkami operacyjnymi i IT. Ta współpraca musi być oparta na partnerskich i równoprawnych relacjach. Jednak stworzenie takiej sytuacji w wielu organizacjach wymaga silnej determinacji, ponieważ rzeczywistość znacznie odbiega od ideału. Biznes nie rozumie IT, co utrudnia prowadzenie projektów informatycznych i może prowadzić do rozminięcia się z założonymi celami. Dlatego warto przyjrzeć się kilku firmom, które podjęły ryzyko i obecnie odcinają kupony od wprowadzonych zmian.

Zwinność projektów

Ewa Hadasz, dyrektor Departamentu Aplikacji Korporacyjnych i Strategicznych w ING Banku ŚląskimKliknij, aby powiększyćEwa Hadasz, dyrektor Departamentu Aplikacji Korporacyjnych i Strategicznych w ING Banku ŚląskimCiekawym przykładem udanej zmiany relacji między biznesem a informatyką jest spółka PayU, w której projekty IT są obecnie realizowane zgodnie z założeniami metodologii Agile. „Ponad 1,5 roku temu IT w PayU przeszło proces transformacji na Scrum jako metodę prowadzenia projektów. Nie chcę rozwodzić się nad rolą Product Ownera, jako stałego członka zespołu Scrum. Jednak zaletą takiego układu, w którym biznes jest nie tylko stroną podpisującą kontrakt, ale ma swojego przedstawiciela w zespole, jest szybsza pętla zwrotna co do implementowanych zmian” – mówi Ewa Hołodnik-Matysek, Head of IT Operations w PayU. „Kolejną zaletą jest wspólna realizacja celów, z którymi biznes się identyfikuje. Dotyczy to również strategicznych celów technologicznych. Ponadto biznes ponosi odpowiedzialność za porażki na poziomie projektu, a nie tylko produktu wdrożonego produkcyjnie”.

Zobacz również:



Przejście z używanej wcześniej metody kaskadowej wiązało się z wprowadzeniem istotnych zmian organizacyjnych w PayU. Nastąpiła również ewolucja mentalna po stronie biznesu. Przed wprowadzeniem Agile działy biznesowe bardzo często przyjmowały roszczeniową postawę, miały skłonność do wywierania presji na IT i błędnie oceniały pracochłonność, co wynikało z braku wiedzy technologicznej. „W projektach kaskadowych, w których interfejsem jest kierownik projektu, w sposób naturalny buduje się bariera pomiędzy koncepcją a realizacją i bardzo często wynik różni się od zamierzonego efektu” – dodaje Ewa Hołodnik – Matysek. Im większa separacja biznesu od IT, tym gorsza komunikacja między tymi stronami i słabsze zarządzanie biznesem. Reorganizacja była dla pracowników PayU trudnym doświadczeniem w zakresie pozbywania się starych nawyków, narzutów biurokratycznych i mitów. Zanim powstało nowe, lepsze środowisko pracy, popełniono wiele błędów. Jednak finalnie podjęcie tego wyzwania przyniosło szerokie korzyści. Bez próby wprowadzenia zmian firma nie rozwijałaby się tak, jak może to robić obecnie.

Andrzej Kaczmarczyk, dyrektor Biura Informatyki i Telekomunikacji w spółce Operator Logistyczny Paliw PłynnychKliknij, aby powiększyćAndrzej Kaczmarczyk, dyrektor Biura Informatyki i Telekomunikacji w spółce Operator Logistyczny Paliw PłynnychDzięki większemu zaangażowaniu biznesu w projekty informatyczne poprawiło się zrozumienie specyfiki IT po stronie nietechnicznych działów. To przełożyło się m.in. na lepsze rozpoznanie kosztów związanych z rozwojem IT oraz łatwiejszą akceptację koniecznych nakładów inwestycyjnych. Ponadto w kontaktach z zarządem dyrektor IT przestał był jedyną osobą reprezentującą IT. Dołączyli do niego tzw. Product Ownerzy.

Wysiłek podjęty przez PayU przyniósł wymierne efekty. Przykładem jest bardziej precyzyjne określanie czasochłonności prac. „Przed wprowadzeniem zmian dwa lata temu, gdy wchodziliśmy w jeden z naszych największych projektów z klientem zagranicznym, rozpiętość ocen czasochłonności prac wahała się od 3 miesięcy do 1 roku. Przy takim szacowaniu zarówno biznes, jak i klient nie są w stanie przewidzieć ani zagwarantować żadnych terminów dostawy produktu” – mówi Ewa Hołodnik-Matysek.

W tym przypadku zarząd podjął decyzję o rozwiązaniu działu menedżerów projektu i zbudowaniu zespołów Scrum z Product Ownerami jako kluczowymi postaciami. Dzięki zmianie metody wyeliminowano nadmierną presję ze strony biznesu i projekty są wdrażane w założonym terminie. Dzięki wsparciu biznesu w obszarze technologicznym firma może zapewniać wysoki poziom dostępności usług. Doprowadzono do sytuacji, w której biznes rozumie specyfikę pracy programistów i nie jest wrogo nastawiony do refaktoryzacji kodu czy używania narzędzi do wsparcia monitoringu.

Wyraźny zakres obowiązków

Najważniejsze w budowie dobrych relacji między IT i biznesem jest znalezienie wspólnego języka, a to można osiągnąć tylko poprzez bezpośrednią współpracę. „W firmie, w której pracuję, istotne było imienne wyznaczenie osób i przypisanie im odpowiedzialności za technologie i aplikacje zarówno po stronie biznesu – administrator merytoryczny – jak i stronie IT – administrator techniczny” – mówi Andrzej Kaczmarczyk, dyrektor Biura Informatyki i Telekomunikacji w spółce Operator Logistyczny Paliw Płynnych. „W każdej dwójce czołową rolę otrzymał przedstawiciel biznesu. Żeby powstały wzajemne relacje oraz każdy ‘nauczył się’ drugiej strony, każda dwójka dostała za zadanie przygotować kartę systemu, w której szczegółowo opisano m.in. umiejscowienie systemu w organizacji, role i uprawnienia użytkowników, wymogi techniczne oraz systemy zasilające i odbierających dane”. Efektem wzajemnego zacieśnienia relacji były: redukcja sytuacji stresowych po obu stronach biznes-IT, skrócenie czasu realizacji projektów, uporządkowanie pracy biznesu oraz IT i finalnie pozyskiwanie najcenniejszej „waluty”, tj. zadowolenia klienta.