TL;DR Większość ludzi, pracujących w tak zwanym “enterprise IT”, zmaga się z mniejszą lub większą inercją organizacji i chaosem. Przeważnie większą. To nieprawda, że nie da się z tym nic zrobić. Wystarczy zacząć myśleć i działać. 

Większość swojego zawodowego życia spędziłem wokół czegoś, co można nazwać jako zagadnienie “enterprise IT“. Niekoniecznie oznacza to IT w wielkiej organizacji. Organizacja może być średnia. Technologia jest jednym z elementów wspierających działanie firmy. Przynajmniej w teorii.

Mam nadzieję, że nikt nie weźmie tego do siebie – nie taki jest cel i to, co napiszę nie odnosi się do żadnej konkretnej firmy, osoby lub sytuacji. Tym samym wszelkie podobieństwa możemy uznać za przypadkowe.

Krew, pot i enteprise IT

Tak zwane enterprise IT to często krew, pot i łzy, zmarnowany potencjał, nieskończone projekty i działania pozorne. Podejście do planowania, zmiany i zarządzania nią dobrze obrazuje poniższy rysunek (który w końcu zainspirował mnie do napisania tych kilku słów).

 

czefffexcaapraz

Śmieszne!? Jak oni tam żyją – prawdaż? Może ty też żyjesz i pracujesz w takim środowisku. Może dostarczasz usług lub kodujesz dla takiej firmy.

Zaczynacie kolejny projekt i już wiesz, jak on się skończy? Kolejna inicjatywa, a wy wiecie, że za chwilę wiatr powieje w drugą stronę, więc na wszelki wypadek już odpuszczacie. W końcu wiecie jak się to skończy…

Pracujesz jako konsultant u klienta? Przychodzą do ciebie z problemem, a ty jak zwykle uruchamiasz wielką machinę i planujesz projekt tak, jak robiłeś to przez ostatnie 10 lat? W końcu zawsze tak działało…

Może to wszystko tak się toczy właśnie dlatego, że wszyscy zapędziliśmy się w kozi róg i robimy rzeczy tak, jak zawsze!!!

Organizacje nie do końca są odpowiedzialne za taki stan rzeczy. W końcu prowadzenie IT nie jest ich głównym biznesem (najczęściej), a jedynie ma dostarczyć środków i metod wspierających prowadzenia głównej działalności.

Dlatego firmy zatrudniają zewnętrznych konsultantów, firmy doradcze, analizują wymagania i wykonują masę podobnych działań. W czym tkwi problem? Polega on na tym, że w większości te firmy, które zatrudniają – wyrosły i przyzwyczaiły się do pracy w trybie “enterprise IT“. Nie potrafią do tego podejść inaczej.

Ostatnio akurat miałem przykład rozmowy o projekcie. Dałoby się go wykonać szybko, sprawnie, podejść do problemu i zaadresować go (nie jest to projekt w chmurze). Jest kilka wyzwań, ale może nie trzeba trzymać się ścieżki, która była obrana wcześniej, tylko pomyśleć jak podejść z drugiej strony.

Tak się nie stanie. Na końcu firmy, które już pracują w projekcie okopały się w swoich typowych “enterprise” szańcach.  Napiszemy dokumenty, opracujemy CR (dla tych co nie są z tego świata – zgłoszenie zmiany). Przedyskutujemy i w końcu coś tam zrobimy.

To nie jest tak, że to nie jest potrzebne. W dużej organizacji warto prowadzić rzeczy w uporządkowany sposób. Problem zaczyna się, gdy ten uporządkowany sposób powoduje, że wszystko trwa lata, kosztuje miliony, a na końcu i tak użytkownik nie jest zadowolony. Ale żyje z tym co dostanie.

Dlaczego?

Dlatego, że tak nauczyło go podejście “enteprise IT”.

Start-up nation

Fajnie by było pracować w startupie, prawda? Elastycznie, szybko, nowe technologie, ciekawe projekty.
Twoja firma może być startupem. Twój dział może być startupem. Twoja usługa, którą zajmujesz się może być startupem. Wystarczy, że spróbujesz za każdym razem robić rzeczy trochę inaczej.

-Procedury, procesy – nie możemy robić tego w ten sposób!
-Możecie!
-Ale za każdym razem idziemy tak jak mówią nam procedury i procesy.
-Dlaczego?
-Zawsze tak robiliśmy i działało.
Tak naprawdę to dlatego, że minimalizuje to ryzyko. Nie, nie ryzyko porażki w projekcie.

Ryzyko tego, że zrobimy coś, co zagrozi naszemu status quo w organizacji.

nobody-gets-fired-for-buying-ibm

Czasami rozmawiamy o projektach, które mogłyby być wykonane szybko, tanio i sprawnie. Gdyby tylko ktoś zdecydował się wyjść poza standardowe ścieżki działania, spróbować czegoś innego. Gdyby ktoś przeszedł się po organizacji i zapytał:

“Czy ktoś już takie coś budował?”

“Jakie błędy popełniliście?”

“A może macie już takie coś zrobione?”

Przykładem może być działka, w której spędziłem ostatnie kilka lat – zarządzanie dostępem. Typowa sytuacja: firma ma wdrożone kilka narzędzi typu IAM. Dlaczego? Dział IT wdrożył swoje, dział bezpieczeństwa wdrożył swoje, a dodatkowo jeszcze jest grupowa inicjatywa, która ma to zunifikować pod jeszcze innym narzędziem.

(Przy okazji – tytuł tego fragmentu pochodzi z bardzo dobrej książki o Izraelu jako państwie i ich podejściu do rozwoju. Polecam!)

Stop!

Powinienem się z tego cieszyć? Prawda! To generuje przychody dla mojej firmy. Może i tak, ale nie cieszy mnie to. Wolę zrobić projekt, który ma realny wpływ i poprawia coś. Wolę pomóc komuś zrobić jedną fajną rzecz. Więc zawsze będę proponował: “a może by zrobić to inaczej”, gdy widzę taką okazję. Niestety często robimy to tak jak zawsze.

Enterprise IT może być ciekawe. I jest! Firmy mają zdolnych ludzi na pokładzie (czasami trafia się na osoby, przy których nasza konsultancka wiedza jest mała). Muszą tylko pomóc rozwinąć im skrzydła!

Musimy przestać krzywdzić samych siebie. To zdanie to kalka z artykułu – “Stopping Self Harm in Corporate IT”. Musicie go przeczytać. Długi, trzeba pomyśleć nad nim. Ale warto!

 

Główne zdjęcie: MT Falldog via Visual Hunt / CC BY-NC-ND

About Author

2 Comments

  1. Pozwolę sobie odpisać tutaj, a nie na FB żeby zachować powiedzmy sobie “anonimowość” 😉
    Na szczęście (albo i nie) nie pracowałem w Enterprise IT, ale mam doświadczenie z małymi firmami (od 10 do ok. 100 użyszkodników) zarówno od strony pracownika/informatyka jak i firmy zewnętrznej…
    Nie wiem jak to wygląda w stolicy, ale gdzieś w typowych małych polskich firmach, które nie są zarządzane zgodnie z zachodnimi standardami z reguły wygląda to tak, że fiirma szuka jakiegoś rozwiązania swojego “problemu”, ale w większości przypadków nie potrafi określić swoich dokładnych potrzeb.
    Gdy w końcu uda się określić potrzeby, dokona się analizy procesów biznesowych i zrobi dokument, który opisuje przebieg procesów to robi się poszukiwania producenta/produktu. I teraz dwie opcje:
    1) znajdujemy firmę, która to zrobi pod nasze wymagania – okazuje się, że jest to opcja droższa, dłuższa terminami i wymagająca więcej współpracy z obu stron
    2) znajdujemy program, który już istnieje na rynku i w jakimś stopniu spełnia wymagania – da radę go “scustomizować” 😉 – okazuje się, że jest to opcja tańsza niż 1, ale ma wady wynikające z późniejszego dopasowywania do potrzeb.
    Oczywiście to biznes (zarząd, prezes, właściciel) decyduje o wyborze oferty i jak ma wyglądać IT u nich w firmie.
    Wszystkie firmy z którymi współpracowałem wybrały opcję 2.
    Firma w której już nie pracuję wybrała opcję 1, ale jak rozmawiałem z ludźmi, którzy tam są, to skończyło się tak, że parafrazując Twoje słowa “wszystko trwało lata, kosztowało miliony, a na końcu i tak użytkownik nie jest do końca zadowolony. Ale żyje z tym co dostał.”

    Niestety tak to jest poza Enterprise IT w tych polskich firemkach – kasa i “szybko zrobione” to podstawowa waga dla Klienta. Producent czy firma zewnętrzna z reguły chce sporo zarobić na temacie, podczas gdy “biznes” chciałby mieć rozwiązanie szybko, tanio i sprawnie… gdzieś trzeba się spotkać i tego jestem ciekaw, jak takie tematy są rozwiązywane w firmie predica 😉

    Pozdrawiam

    • Tomasz Onyszko on

      Hej, dzięki za komentarz – ze względów osobistych odpowiedź trochę spóźniona.

      Na początek jedna uwaga taka z boku. Napisałeś “użyszkodników” i chociaż zdaję sobię sprawę że to miało być ironicznie, to pamiętaj – wszystko zaczyna się od słów. Oni nazywają nas swetrami :). Warto o użytkownikach myśleć jak o klientach własnej firmy – wtedy wszystko idzie lepiej.

      A teraz to już po koleji;

      W typowych dużych przedsiębiorstwach jest tak samo – to znaczy wiadomo, że potrzeba jakiegoś rozwiązania ale określenie potrzeb … o żesz psia mać. Ale których i dlaczego moja potrzeba jest ważniejsza od twojej potrzeby. A z tego wychodzi zło ostateczne – RFP!!! Jeżeli o mnie chodzi to RFP powinno się zakazać. Albo inaczej – proces wypuszczenia RFP powinien być normalną usługą gdzie ktoś robi projekt zdefiniowania tych potrzeb i opisania w sensowny sposób. Sensowny znaczy się taki, który uwzględnia oczekiwany wynik i realia czasów i kostów. ROI z takiego projektu gwarantowany – części projektów by się nawet nie uruchamiałi.

      Co do wyboru aplikacji itp – to wygląda podobnie, z tym że:
      1. W większości każdy klient mówi że jest specyficzny i chce coś pod siebie. Jeżeli by wykonał wcześniej analizę tych “specyficznych” wymagań to by może doszedł do wniosku że jednak nie są takie specyficzne albo da sie je zrobić tracąc tylko 5-10% nie kluczowych wymagań. Szczerze – większość rozmów zaczynamy od “my jesteśmy wyjątkowi i u nas to działa inaczej” a w 80% przypadków wdraża sie podobne rozwiązania.
      2. W tej chwili to się zmienia ponieważ wchodzi SaaS. Masz do wyboru wziąć gotowe rozwiązanie, które uruchomisz w 1 dzień i spełni 30% twoich wymagań, gotowe rozwiązanie, które będziesz dostosowywał 3 miesiące i spełni 40% twoich wymagań albo firmę która po roku obiecuje spełnienie 80% twoich wymagań. Co wybierasz?

      Jak to jest rozwiązywane u nas – głównie przez to że niekoniecznie musimy robić projekt w który nie wierzymy. A jeżeli nie wierzymy to musimy spróbować wytłumaczyć klientowi dlaczego to co chce zrobić może nie jest takim dobrym pomysłem. Pamiętam takie spotkanie w jednym banku, gdzie poszliśmy porozmawiać o aplikacji. W zasadzie mieliśmy ją już pisać, była oferta itp ale nie pasowało nam to wszystko do siebie.

      Po 2 godzinach rozmowy i kilku pytaniach z naszej strony klienta sam doszedł do wniosku że bez sensu jest tworzenie tej aplikacji :). I tak wyszliśmy bez projektu ale tego nie żałujemy :).

Leave A Reply

Share This

Share This

Share this post with your friends!