Czy jest wyjście z pułapki „zinformatyzowienia”?

Data: 2013-01-24
Autor: Sebastian Konkol
Czy jest wyjście z pułapki „zinformatyzowienia”?

Jest taka dość znana prawda ludowa: nie dyskutuj z głupcem, bo sprowadzi Cię do swojego poziomu i pokona doświadczeniem. Choć bezpośrednie „przyłożenie” tej prawdy do świata IT byłoby obraźliwe, to jednak czasami, kiedy obserwuję zachowania przedstawicieli tej profesji, nasuwa mi się na myśl ta ludowa prawda. Każde IT przecież głosi: chcemy być partnerem dla biznesu. A jednak – niezmiennie i z żelazną konsekwencją – każda inicjatywa w założeniach zbliżająca te dwa światy trafia na ten sam mechanizm „zinformatyzowienia”.

Myślę o sobie jako architekcie, choć moje dokonania częściej kojarzą się z analizą biznesową. Objawieniem roku 2002  – wtedy zacząłem się tym tematem na poważnie zajmować – była dla mnie architektura korporacyjna (Enterprise Architecture). Jej moc pozwalała ujmować „sprawy informatyczne” w sposób rzeczywiście biznesowy, zapewniający bezpośrednią komunikację z ludźmi „spoza” IT. Nie był to jeszcze ideał, bo stawiał dość wysokie wyzwania intelektualne, ale na początek wyglądało to dobrze – miało szansę być skuteczne. Co się stało przez ostatnią dekadę z architekturą korporacyjną? „Obrosła” metodami, modelami, standardami i całą resztą atrybutów absolutnie typowych dla świata IT – jednocześnie kompletnie bezużytecznych dla świata biznesu. Właśnie to nazywam „zinformatyzowieniem”. Koronnym dowodem była dla mnie zeszłoroczna dyskusja z przeszkolonego i certyfikowanego na wszystkie możliwe sposoby „architekta korporacyjnego”, który dyskusję o architekturze korporacyjnej dla programu o budżecie ponad 120 mln złotych zaczął od pytania o notację i czy będziemy opisywać „to” stosując ERD czy obiektowo. Porażka…

Nie zmieniam jednak myślenia o sobie – ja jestem architektem, choć poczynania IT coraz bardziej szkodzą mojej profesji. Nie oczekuję od żadnego przedstawiciela biznesu (finansisty, business developera, speca od marketingu), żeby znał się na IT – to moje zadanie, tak samo jak umiejętność dobrania właściwych rozwiązań do tego, czego potrzebuje jego biznes. To moja rola aby zrozumieć, gdzie rozwiązanie ma być powiązane sznurkiem i sklejone gumą do żucia, a gdzie musi być jak kopnięcie z półobrotu Chucka Norrisa. Z uporem godnym wyższej sprawy poszukuję narzędzi, które pozwalają mi na jeszcze bliższy kontakt z biznesem, bez „mieszania w to” technologii.

Ostatnio trafiła w moje ręce książka o architekturze korporacyjnej (“Enterprise Architecture As Strategy: Creating a Foundation for Business Execution”, Jeanne W. Ross, Peter Weill, David C. Robertson, Harvard Business Review Press, 2006, ISBN: 1591398398). Pierwsze moje nastawienie było ambiwalentne – przecież ta filozofia „jest już spalona”. Z każdą przeczytaną stroną było mi jednak znacznie lepiej – znalazłem kolejne narzędzie: Foundation for Execution. Jak wiadomo, każdy biznes potrzebuje kilku rodzajów „zasobów” do funkcjonowania, np.: finansów, informacji, siły roboczej czy zdolności rozwoju. Biznes będzie działał sprawnie, jeśli dostępne mu zasoby będzie wykorzystywał optymalnie, a mechanizmy zapewniające tę optymalność to właśnie Foundation for Execution. W sferze wykorzystania zasobów finansowych optymalizację zapewnia zarządzanie finansowe, w arsenale marketingu są marki i pozycjonowanie, a w sferze przetwarzania informacji taką rolę powinna odgrywać właśnie architektura korporacyjna.

Rolą architektury nie jest zdefiniowanie wszystkiego – rolą architektury jest pokazanie sposobu realizacji elastyczności rozwiązań i redukcji ograniczeń. Jeśli więc biznes nastawiony jest na dławienie kosztów, to architektura korporacyjna musi zapewniać możliwości redukcji kosztownych operacji. Jeśli rozwój biznesu polega na akwizycjach, to architektura korporacyjna musi zapewniać zdolność „przeflancowania” całości procesów firmy na nowy grunt. Jeśli natomiast model biznesowy polega na tworzeniu niezależnych business unitów, to architektura powinna zapewnić integrację danych dla zwiększenia wzajemnego wspomagania tych niezależnych działów. To jest właśnie właściwy wkład technologii informatycznych – Enterprise Architecture jako składowa Foundation for Execution. Nie wszystko musi być integrowane, automatyzowane, czy perfekcyjne – musi być takie to, co składa się i przekłada się na skuteczność biznesu.

Zabawna rzecz, bo angielskie słowo execution jest wieloznaczne – może oznaczać zarówno realizację (planu, strategii) jak i wykonanie wyroku. Praktyka stosowania architektury korporacyjnej nasuwa raczej skojarzenie z tym drugim znaczeniem. Ja jednak wierzę, że można osiągać to pierwsze. Stan Waszych Foundation for Execution wskazuje bardziej na fundament zdrowego biznesu, czy „wyroku śmierci”?

Pozostaw komentarz