21

Dział IT w korpo, czyli „tego nie da się zrobić…”

dział IT
Jaką rolę ma dział IT w korporacji finansowej (+500)? Utrzymywanie systemów informatycznych, zapewnienie ich stabilności i bezawaryjności. ServiceDesk zapewnia również odpowiednie funkcjonowanie stanowisk pracy. Jednak dynamiczny rynek wymusza zmiany w procesach firmy, a co za tym idzie zmiany w systemach informatycznych. Jak wygląda rozwój oprogramowania w korporacji? Dlaczego piszę o korporacjach? Bo przy tak dużej […]

Jaką rolę ma dział IT w korporacji finansowej (+500)? Utrzymywanie systemów informatycznych, zapewnienie ich stabilności i bezawaryjności. ServiceDesk zapewnia również odpowiednie funkcjonowanie stanowisk pracy. Jednak dynamiczny rynek wymusza zmiany w procesach firmy, a co za tym idzie zmiany w systemach informatycznych. Jak wygląda rozwój oprogramowania w korporacji?

Dlaczego piszę o korporacjach? Bo przy tak dużej ilości pracowników pojawia się więcej polityki niż działań zmierzających do osiągania celów biznesowych. Jeszcze więcej polityki, uników i wprowadzania szumu informacyjnego pojawia się na tzw. „linii IT <-> Biznes”.

Dział IT rozwija systemy…

Podstawowymi departamentami w korpo są Sprzedaż i Marketing. Reszta działów ma rolę usługową najczęściej dla Sprzedaży, np.:

  • dział prawny – aby umowy generowane przez Sprzedaż nie wylądowały w sądzie,
  • dział rachunkowości – aby oferty Sprzedaży i sposoby rozliczeń nie spowodowały kar z US,
  • dział finansowania – pożyczają kasę aby Sprzedaż ofertowała klientom tę kasę po wyższej cenie,
  • dział obsługi klienta – żeby obecni klienci wracali do Sprzedaży,
  • dział windykacji – aby było na wypłaty m.in. dla Sprzedaży.

I tak można jeszcze wymienić 20 jednostek. Moim zdaniem „najbardziej” usługowym departamentem jest dział IT, który dostarcza narzędzia zwiększające efektywność zarówno procesów sprzedażowych jak i operacyjnych. Polega to głównie na ciągłym doskonaleniu narzędzi informatycznych wykorzystywanych przez pracowników. To doskonalenie przeprowadza się za pomocą dedykowanych projektów wewnątrz-firmowych. Zazwyczaj polega to na modyfikacji istniejącego systemu IT, rzadziej jest to wdrożenie nowego.

Celem tych zmian może być potrzeba poprawienia efektywności (toporny system, słaba użyteczność) albo czynniki zewnętrzne (prawne, biznesowe, kulturowe, itp.). Jedno jest pewne, zmiana i rozwój systemów IT to proces ciągły.

Tylko się nie pomyl, bo się obrazimy

Załóżmy, że zarząd określił cel zmian, zwołano zespół projektowy i zaczynamy przedsięwzięcie.

Po analizie biznesowej i określeniu założeń zaczynamy analizę systemową, powiedzmy w postaci specyfikacji wymagań (CO, jeszcze nie JAK). Na pierwszych spotkaniach z IT wszystko idzie gładko. Jednak aby nie kończyć tylko na rozmowach, PM (kierownik projektu spoza Biznesu i IT) stara się powołać osobę w roli analityka systemowego. Jego rolą będzie redagowanie specyfikacji, która będzie pomostem i „umową” pomiędzy IT a Biznesem (wszyscy muszą rozumieć dokument).

I to już pierwsze miejsce konfliktu, kto ma być tym analitykiem. IT mówi, że to nie ich kompetencje, z czym całkowicie się nie zgadzam. Analityk systemowy to osoba mająca pojęcie co w IT jest wykonalne, a więc musi mieć doświadczenie w tym dziale i dodatkowo potrafi się komunikować z nie-technicznymi ludźmi (takich brakuje). Ale informatykom zatrudnianie jakichś komunikacyjnych przyczółków jest nie na rękę. Wolą osoby o twardych umiejętnościach.

W końcu PM, aby zakończyć przepychanki, podejmuje decyzję, że na to stanowisko wybierze kogoś z Biznesu. Na kolejnych spotkaniach taki analityk połowy rzeczy nie rozumie, a IT wywraca oczami, że musi tłumaczyć takie banały. Informatycy wytykają każdą nieścisłość zamiast wspólnie szukać rozwiązań („przecież to Wy to chcecie”). W końcu się obrażają i znikają z kilku spotkań twierdząc, że biznes nie wie czego chce. 2 miesiące mamy do tyłu.

Po uniżonych prośbach na spotkaniu pojawia się Dyrektor IT, który wprowadza przyjazną atmosferę i próbuje na jednym spotkaniu wszystko wyjaśnić. Jednak spotkanie kończy się wiekopomnym zdaniem „to jeszcze to przeanalizujemy”. Kolejne 2 miesiące polegają na szukaniu Dyrektora. Pojawia się potem jego zastępca i na 3 kolejnych spotkaniach wywala połowę rzeczy do góry nogami, bo albo się „tego się nie da zrobić”, albo „po co to”, albo to przecież jest w innych systemach (biedną metodą work-around). Zmęczony Biznes i PM zapominają o celach projektu i godzą się na aktualną wersję dokumentu.

My Ci to zaprojektujemy

Następnie powstaje Projekt Zmian, czyli bardziej niskopoziomowy opis modyfikacji w systemach (nie tylko CO ale też JAK). IT z niewyjaśnionych dla Biznesu przyczyn uzurpuje sobie wyłączność do tworzenie tego dokumentu. Po prostu wywalczyli taką a nie inną listę wymagań, a teraz dodatkowo chcą to zrobić po swojemu. Jeszcze jakiemuś lamerowi zechce się jakiegoś fajnego ekranu albo ajaxa i będzie… Dostaniecie „design by developers”, czyli czcionka 10px, zielone na różowym i screenflow rodem z lat 90′.

IT z miesięcznym opóźnieniem dostarcza 200 stronicowy dokument i zaznacza, że to draft. Analityk z Biznesu połowy rzeczy w nim nie rozumie. Kiedy Zastępca mu wszystko wytłumaczy Analityk tłumaczy Biznesowi, a Biznes mówi, że ten projekt to jakieś jakieś kuriozum i nie ma nic wspólnego z założeniami. Potem 2 miesiące na kłótnie. W końcu przychodzi Prezes i mówi „po prostu to zróbmy”. Biznes spuszcza głowę, IT się uśmiecha i powstaje poczwarka (z przesunięciem terminu 130%), której nikt nie potrzebuje. To tak w skrócie.

Czasami do procesu technicznego włącza się PM, jeśli ma odpowiednią wiedzę. Ale wtedy staje się wrogiem nr 1 dla IT. Zrobią wtedy wszystko aby Twój zakres, koszt i termin posypały się względem planu. Bo każdy członek projektu jeśli będzie chciał to udupi dowolny projekt.

Poniżej podaję podsumowanie przyczyn takich patologii, także po stronie Biznesu.

Powody problemów płynące z IT

  • skupianie się tylko na twardych kompetencjach,
  • brak umiejętności komunikacji,
  • potrzeba poświęcania czasu na spłacanie własnych „długów technicznych” z przeszłości,
  • brak zainteresowania celami biznesowymi projektu (czasem nawet Dyrektor to olewa i chroni własne 4 litery), to najważniejszy problem, brak motywacji, czy „dajcie mi święty spokój i powiedzcie czego chcecie”,
  • syndrom postrzegania Biznesu jako lamerów i lajkoników,
  • brak ambicji (to co, że Outlook jest do bani, ale jak działa to kur… nie rusz),
  • rotacja kadry zarządzającej IT i zostawianie bobków następcom,
  • brak dokumentowania kodu, nawet automatami (wtedy wolą tam nic nie zmieniać przez następne 20 lat).

Powody problemów płynące z Biznesu

  • nie przemyślenie własnych wymagań, niespójność, ale często z powodu braku wsparcia przez IT wspólną analizą systemową,
  • pilne wrzutki od Biznesu i co za tym idzie stosowanie hardcodingu w kodzie (wymuszanie „długu technicznego”),
  • nastawienie na przegraną z IT (w wyniku przeszłości), a także stereotypy na temat IT.
Dział IT

Sympatyczny Biznes (źr. BrandJuniorManager)

Proaktywność

Wiadomo, że nie wszystkie korporacje są takie. Opisuję swoje doświadczenia. Wiadomo też, że kij ma dwa końce, ale w moim przypadku więcej problemów było w grupie technicznej. Jeśli jednym zdaniem miałbym coś doradzić Dyrektorom IT (którym nigdy nie byłem, ale współpracowałem z paroma) to byłoby to przestawienie się wyłącznie z roli wykonawczej do roli doradczej. Nigdy nie spotkałem się z przypadkiem, że IT samo zaproponowało jakieś istotne zmiany na lepsze (dla użytkownika) w swoich systemach. Brakuje proaktywności zamiast tylko reaktywności.

Częste jest wykorzystywanie niewiedzy Biznesu na tematy techniczne. I jedynym co IT robi na spotkaniach jest wyliczanka ryzyk związanych z kolejnymi propozycjami zmian lub „ale tego nie da się zrobić”. Ja od swoich pracowników wymagam: jeśli przychodzisz z problemem, fajnie usłyszeć od razu, w parze, propozycje jego rozwiązania. Etatowy narzekacz i bezrefleksyjny krytykant może liczyć jedynie na szybkie zwolnienie.

Wracając do korpo… Może warto potraktować się jak partnerzy, a nie lamerzy. I zamiast „pijarować” przed Prezesem, że robimy dla userów co możemy, warto zdobyć się na kilka słów szczerości, że nie macie na zasobów, albo nie wyrabiacie się z zadaniami. Jednak ta niekończąca się mikro-polityka korporacyjna spowodowała, że 2 lata temu zakończyłem swoją przygodę z korpo i teraz pracuję w mniejszej firmie. W moim zespole nie ma miejsca na gierki i aluzje.

Powodzenia dla osób z Biznesu w korpo współpracującym w projektach z działem IT. :)

Autor prowadzi bloga – http://ProductLabs.co