Dział IT w korpo, czyli "tego nie da się zrobić..."

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.

Czytaj dalej poniżej

"Stare kadry muszą wymrzeć" czyli grywalizacja w edukacji - Game Industry Trends 2012 Tomek Chojecki

Czy iPody są u schyłku swojej "kariery"? Konrad Kozłowski

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ę ", 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.

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