Czym się zajmuje IT?

Data: 2014-01-02
Autor: Sebastian Konkol
Czym się zajmuje IT?

Choć, porównując do budownictwa lub polityki, IT jest raczej młodą dziedziną działalności cywilizacji ludzkiej, jest jednak obszarem na tyle „wiekowym”, że można pokusić się już chyba o identyfikację wzorów prowadzenia tej działalności. IT – dla przypomnienia Information Technology, czyli technologia informacji – powinna zajmować się przetwarzaniem informacji, a przynajmniej tak wynika z nazwy tej dyscypliny działalności ludzkiej.

Informacja, przedmiot działań IT, wpisuje się w coś, co teoretycy zarządzania IT (ITIL) nazwali łańcuchem poznawczym dane – informacja – wiedza – mądrość (DIKW, ITIL Service Transition). Według ich definicji dane są bezkontekstowe i nie mają przypisanego im znaczenia (dane to np. „5”, czy „wartość”). Informacja to coś, co bazuje na danych, ale odnosi je do kontekstu ich występowania (np. pytaniami Kto / Co? Kiedy? Gdzie?) – informacja daje się zrozumieć. Wiedza powstaje na bazie informacji, a zgłębiając jej kontekst (np. odpowiedziami na pytanie Jak?) pozwala na wysnuwanie wniosków z analizy informacji. Mądrość to ostateczny byt abstrakcyjny, bazujący na wiedzy, rozbudowujący zrozumienie przez dalsze pogłębianie kontekstu (odpowiedziami na pytania Dlaczego?). Odczytując to dosłownie, misją IT jest prowadzenie takiej działalności przetwarzania informacji, aby – co najmniej – wyniki budowały fundamenty wiedzy. Tyle teoria, a co mówi doświadczenie?

Praktyka podpowiada inny podział – na rzemiosło IT i funkcję IT. Rzemiosło IT to praktyka budowania systemów informatycznych. Funkcja IT to działalność przetwarzania zgromadzonej informacji pozwalająca na budowanie wiedzy – im sprawniejsze budowanie wiedzy, tym lepiej sprawowana funkcja IT. Sprawowanie funkcji IT nie jest możliwe bez posiadania sprawnie działających efektów rzemiosła IT. Ta właśnie zależność jest źródłem utrapień i zmartwień, a często poważnych konfliktów w organizacjach.

Typowy obraz realizacji przetwarzania informacji w firmach jest następujący. Rzemiosło IT jest często rozproszone, ulokowane statutowo w działach IT, a pragmatycznie (bo statutowe nie funkcjonuje jak trzeba) w działach merytorycznych (żeby nie mówić IT-slangiem, że „w biznesie”). O funkcję IT w organizacji nikt się nie troszczy (sic!). Jest ona realizowana zwykle przez działy merytoryczne, gdyż od nich wymaga się wnioskowania, budowania i wykorzystania wiedzy. Ulokowanie funkcji IT w działach IT trzeba, niestety, postrzegać na zasadzie wyjątku. Aby sprawować funkcję IT niezbędne jest stosowanie narzędzi IT (czyli przetwarzania informacji) i w ten sposób w działach merytorycznych pojawiają się – choć chyba bardziej wyrastają – rzemieślnicy IT, którzy budują systemy informatyczne niezależne od „oficjalnych”, umożliwiające przetwarzanie informacji.

Konsekwencje tej ewolucji są różnorakie, a teoria zarządzania IT jest pełna ostrzeżeń przed nimi. Jako przykład wybrałem działalność raportowania, bardzo wdzięcznego obszaru poszukiwania wzorców, gdyż historycznie (jeszcze z czasów prowadzenia pierwszych księgowości w systemach zasilanych danymi przy wykorzystaniu kart perforowanych) jest to najbardziej tradycyjny obszar działania IT. Raportowanie „dzieli się na” operacyjne (np. czy bieżące procesy przebiegają sprawnie) i analityczne (np. czy sprzedaż ma szanse zrealizować postawione cele).

Konsekwencje w raportowaniu – przykład pierwszy. Duża firma, złożone procesy operacyjne, wiele raportowania operacyjnego. Systemy obsługujące procesy operacyjne dostarczane są przez dział IT, ale raportowanie operacyjne jest realizowane przez działy obsługi klienta będące użytkownikami tych systemów. Działy te radzą sobie z raportowaniem przez tworzenie własnych systemów, „nieautoryzowanych” przez dział IT. W tak zastanych okolicznościach pojawia się konieczność zmiany w sposobie prowadzenia sprzedaży – dział IT przystępuje do wdrożenia nowego systemu obsługującego proces sprzedaży. „A co z raportowaniem?” pytają działy merytoryczne? W odpowiedzi następuje długa wypowiedź, z której przesłanie jest jasne – musicie sobie jakoś poradzić.

Konsekwencje w raportowaniu – przykład drugi. Nieco mniejsza firma, działalność w sferze finansowej, bardzo rozbudowane oczekiwania odnośnie analiz wyników finansowych i prognoz. Systemy obsługujące procesy operacyjne dostarczane są przez dział IT, ale raportowanie analityczne jest realizowane przez dział analiz finansowych nie będący nawet użytkownikiem tych systemów. Dział ten radzi sobie z analizami przez tworzenie własnego systemu klasy BI, „kontestowanego” przez dział IT. Dział analiz finansowych musi zrozumieć struktury danych systemów operacyjnych i łatać dziury w jakości tych danych, gdyż informacja analityczna musi być wiarygodna.

Obowiązujący „wzorzec” rysuje się więc następująco. Działy IT wycofują się do pozycji rzemieślników IT, gdyż tak jest dla nich bezpieczniej. Nie zastanawiają się nawet, do czego potrzebne są informacje i jak zapewnić ich jakość. W razie wpadki, dział IT nie jest przecież winien tym konsekwencjom, prawda?…

Takie „okopanie się na bezpiecznej pozycji” – choć zaskakujące jest to, że właściciele firm na to pozwalają – nie jest zwykle możliwe w innych obszarach działalności firm. Istnieją dobre wzorce dla poszczególnych z nich. Działy finansów odpowiadają zwykle za finanse firmy, a nie za księgowe piękno struktury księgi głównej. Marketing odpowiada zwykle za skuteczność kampanii a nie za jakość papieru i głębię barw na ulotce produktowej. Produkcja odpowiada za wytworzenie zgodnie z planem a nie za posiadanie planu parku maszynowego. Logistyka odpowiada za przekazywanie dóbr a nie wielkość powierzchni magazynowej. Obsługa klienta…

Na częściowe usprawiedliwienie, rzemieślnicy wcale nie mają łatwo – wyścig marketingowy w świecie rzemiosła IT sprawił, że w każdym środowisku informatycznym firmy choćby kilkudziesięcioosobowej jest zamęt, a im większa firma tym większy chaos. „Mistrzowie” w takich środowiskach doktoryzują się w różnych, modnych w danym czasie haseł, podważając wszystkie wcześniejsze. Wszystko zmierza do zachwytu technologicznego, zamiast do sprawowania funkcji, dla których firma w ogóle ponosi koszty posiadania IT – zarówno technologii jak i działów.

Nie mam ambicji zbawiania świata, ale chyba warto od czegoś zacząć. Jeśli działy IT to rzemieślnicy, niech odpowiadają za rzemiosło IT, a funkcja IT niech będzie oficjalnie ulokowana tam, gdzie rzeczywiście jest sprawowana. Dwie propozycje wydają się na miejscu. Jeśli core-business firmy to commodity i trzeba ciąć koszty, to właściwym rozwiązaniem jest ulokowanie zarówno rzemiosła IT jak i funkcji IT w strukturach podległych dyrektorowi finansowemu. Jeśli sukces biznesowy firmy zależy od customer experience, to przynajmniej funkcja IT powinna zostać oficjalnie umieszczona w strukturach podległych dyrektorowi operacyjnemu. Jeśli biznes firmy naprawdę musi być innowacyjny, ale tak naprawdę musi, to całość IT (rzemiosło i funkcja) powinny podlegać dyrektorowi strategii. Powody dla tak „drastycznych tez” wyjaśniłem we wcześniejszym wpisie.

Na swojej drodze zawodowej spotkałem pewnego urzędnika państwowego, który wygłosił bardzo znaczące zdanie: „Urzędnik nie ma załatwiać spraw – urzędnik ma urzędować”. Nie podoba mi się to skojarzenie w kontekście metody działania IT, ale jest nieodparte. Liczę, że patologia sprawowania funkcji IT w firmach nie dojdzie do takich absurdów.

Pozostaw komentarz