Autor ANDRZEJ BOGUSZ
Czy pracujemy w matrixie?
Jak pogodzić naszą potrzebę stabilizacji ze zmiennością projektów i przebiegającą w poprzek struktur działów naturą realizowanych procesów? W jakich strukturach pracujemy? Czy te struktury bardziej pomagają, czy przeszkadzają? Coś wyjaśniają, czy przeciwnie — komplikują?
Jestem pewien, że dla większości osób czytających te słowa (a więc polskojęzycznych) tytuł najpierw wywołał skojarzenia z filmem Wachowskich. I z wykreowaną tam wizją wirtualnej rzeczywistości, tytułowym Matrixem, programem symulującym w umysłach podłączonych do niego ludzi poczucie życia w innym czasie i miejscu niż jest to faktycznie, a ponadto wysysającego z nich energię dla zasilania całego systemu. Dopiero drugim skojarzeniem (i to wyłącznie dla władających językiem angielskim) jest odniesienie do słowa „macierz”, oznaczającego kiedyś matkę, ojczyznę, a współcześnie — matrycę, formę, zaś w matematyce — wielowymiarową tablicę danych, a więc coś dobrze uporządkowanego.
Jest to zatem pewna prowokacja, zmierzająca do pytania: czy pracujemy w matrixie? A jeżeli tak, to w którym: tym, który poprzez wielkość i skomplikowanie uniemożliwia jego zrozumienie (i może wysysać z nas co się da…) , czy też w idealnie poukładanym, gdzie każdy ma swoje właściwe miejsce i zadania? A może obydwa matrixy wiele się od siebie nie różnią?
Tradycyjna struktura organizacyjna
Najprostsza i, wydawałoby się, najbardziej oczywista rzecz pod słońcem: prezes — zarząd — dyrektorzy — kierownicy — liderzy — specjaliści. I odpowiednio kierowane przez nich komórki: zespoły, działy, departamenty, piony — skupiające ludzi o podobnych bądź powiązanych kompetencjach, zadaniach i celach. Nazwy mogą się różnić pomiędzy poszczególnymi organizacjami, ale zasada pozostaje ta sama. I bardzo często, bez zadawania zbędnych pytań natury filozoficznej, działa z sukcesem.
Każdy wie, kim jest, komu podlega, co ma robić. Również jeśli chodzi o sposób zgłaszania problemów, droga służbowa jest wyraźna i oczywista. Niestety, tak jest do czasu. Gdy organizacja zaczyna się rozrastać i pojawiają się problemy — zarówno komunikacyjne (pomiędzy poszczególnymi elementami układanki), jak również efektywnościowe — organizacja coraz słabiej realizuje swoje zadania. Pojawiają się zakresy obowiązków, procedury, zasady komunikacji, coraz więcej spotkań (nie zawsze efektywnych), systemy motywacyjne. Czasem to pomaga, a czasem nie.
W mojej praktyce zawodowej zdarzyło mi się, że w organizacji formalnie dobrze poukładanej trzeba było znaleźć drogę eskalacji problemu związanego z brakiem komunikacji pomiędzy dwoma zespołami IT realizującymi zazębiające się projekty. Pech chciał, że inicjatorzy tych projektów (sponsorzy) byli z różnych linii biznesowych. Udało się, ale dojście do wspólnego dla tych zespołów szczebla zarządczego wymagało przejścia z jednej strony siedmiu (sic!), a z drugiej ośmiu (sic!) szczebli struktury organizacyjnej korporacji.
Dotted lines
Jednym z podstawowych sposobów radzenia sobie ze zbyt dużą głębokością struktury organizacyjnej są dotted lines, „linie przerywane” podległości funkcjonalnej. „Mam swojego szefa, ale muszę również raportować do CIO grupy”. Najczęściej pojawiają się przy dużym wzroście firmy i/lub rozproszeniu terytorialnym. W pierwszym przypadku dotyczą funkcji wsparcia lub kontroli: każdy wydział ma swojego IT-mana, ale są oni dodatkowo szkoleni i „pilnowani” centralnie, audyt i ryzyko wymagają regularnego raportowania określonych wskaźników od wszystkich działów, PMO zbiera syntetyczną informację o statusie projektów, a dodatkowo zapewnia wsparcie dla poszczególnych wydziałów. W sytuacji wielu podmiotów każdy zakład, będący nierzadko odrębną spółką, jest zobowiązany do raportowania i współpracy ze wskazanymi managerami centrali przez odpowiednich swoich kierowników i specjalistów. Dyrektorzy produkcji oprócz podległości swojemu zarządowi są „pilnowani” przez centralnego COO, zaopatrzeniowcy z całego kraju co miesiąc mają spotkanie z naczelnym planistą grupy (i — ku własnemu zdziwieniu — zaczynają tworzyć zespół), każda wdrażana zmiana w systemach musi być zgłaszana do centralnego IT. A wykonanie zaleceń audytu jest oczywiście zgłaszane do audytu grupy (jest to nawet ważniejsze niż zgłoszenie do własnego zarządu, zainteresowanego częściej tym, czy zalecenia zostały wykonane, „odhaczone” niż tym, jak to zostało zrobione…).
Dotted lines mają oczywiście swoje zalety, bo uszczelniają system organizacyjny tam, gdzie struktura tradycyjna sobie nie radzi, zapewniając (czy tez umożliwiając) spójność, monitorowanie, wsparcie i rozwój w zakresie wykraczającym poza kompetencje i możliwości danej komórki, ale z drugiej strony mają istotne wady i przeciwników. Przede wszystkim wymagają każdorazowo ich definiowania (kto komu), określania zakresu (co i jak) i sposobu realizacji (co się stanie, jeśli ktoś to zignoruje, jaki wpływ jest na bezpośredniego przełożonego itd.). Przeciwnikami są zarówno zwykli pracownicy („to komu teraz podlegam?”— poczucie chaosu) i managerowie (ktoś ogranicza moją władzę, moi ludzie teraz ciągle będą zasłaniać raportowaniem komuś z centrali). Jest też klasyczny opór przed zmianą (nie bo nie, „żadnych kropeczek, wszystko ma być normalnie!”). Z pewnością zbyt wiele dotted lines nie będzie pomagać, a wręcz przeciwnie.
Struktura projektowa i macierzowa
W klasycznej definicji projekt jest wydzieloną, tymczasową organizacją, powołana w celu wytworzenia unikatowego rezultatu. Oznacza to, że z całościowej mapy firmy „wyjmujemy” wybrane klocki (nieważne, czy w całości, czy w części ich etatów) i z nich formujemy strukturę projektu. W organizacjach zarządzających wieloma projektami często mówi się o „strukturze macierzowej”, w której poprzecznie do tradycyjnej struktury organizacyjnej, obrazującej teraz również zbiory różnych zasobów kompetencyjnych, pojawiają się kolejne projekty. Te zaś czerpią z poszczególnych komórek zasoby (w zależności od zapotrzebowania na nie), które w ramach tychże projektów pracują i raportują do poszczególnych kierowników projektów. A kierownicy komórek są zobowiązani do zapewnienia dostępności dych zasobów dla projektów (oprócz realizacji bieżącej pracy firmy).
Matrix procesowy
Struktura macierzowa koncentruje się zazwyczaj na realizowanych projektach, przeciwstawiając kierowników liniowych kierownikom projektów. Być może bierze się to stąd, że zazwyczaj pojawia się w kontekście organizacji IT, gdzie praca projektowa jest dominująca formą. Trochę niesłusznie (moim zdaniem) mniej mówi o obszarze business-as-usual, czyli codziennej realizacji zadań operacyjnych organizacji.
O ile prawidłowo zrealizowana macierzowa struktura projektowa jest efektywna, to pozostawienie struktury tradycyjnej w głównym obszarze działania prowadzi do budowy „silosów”, księstw i królestw wewnętrznych, realizujących swoje cele i polityki w oderwaniu od innych „twierdz”. „Ja i moi ludzie zrobiliśmy dobrze swoją robotę, źródeł problemów szukajcie nie u nas”. Trudno jest zauważyć wtedy, że moje działania, choć pozornie prawidłowe, powodują często przestoje w kolejnym obszarze. Wykonaliśmy 130 proc. normy (premia się należy), a to, że kolejny dział z powodów problemów technicznych był w stanie zrealizować tylko 80 proc., mało nas obchodzi. Tylko, że końcowy efekt firmy to dalej 80 proc., a nasze 50 proc. nadwyżki ponad to poszło w straty. Kto zawinił?
Tymczasem prawidłowe zdefiniowanie architektury procesowej, spojrzenie na działalność firmy poprzez procesy, przynosi niemalże same korzyści: oprócz świadomości „co mam robić” pojawia się również rozumienie „dlaczego”. Cele całego zespołu pracującego w danym procesie są wspólne. A że przebiega to poprzecznie do powiązań w strukturze?
W tym przypadku to z żaden sposób nie jest wadą, bo cele kierowników wynikają z celów ich podwładnych, a więc znowu z efektów realizacji procesów. Następuje — dzięki świadomemu współdziałaniu — poprawa komunikacji pomiędzy działami. Można zarządzać i doskonalić nie fragmentarycznie, ale całościowo, patrząc na dostarczane wyniki. Owszem, pojawia się swoisty nowy dotted line — jest nią zależność od osób odpowiedzialnych całościowo za realizację procesów, w których biorę udział, czyli właścicieli/managerów procesów. Ale tego typu zależność staje się normą w organizacji, a nie wyjątkiem: każdy pracownik w zakresie rozwoju kompetencyjnego i całościowej realizacji zadań podlega swojemu przełożonemu, natomiast w ramach realizacji konkretnych zadań — właścicielowi procesu, w którym dane zadanie jest wykonywane. Nie jest to więc uzupełnienie struktury klasycznej przez dodatkowe zależności, ale kompleksowe jej wypełnienie. Ponadto, w odróżnieniu od struktury macierzowej projektowej, z natury rzeczy tymczasowej, macierzowa struktura procesowa jest stała, nie podlega ciągłym zmianom przypisania do funkcji. Natomiast struktura projektowa stanowi jej dobre uzupełnienie w obszarach działań jednorazowych. Jest to obraz trochę idealistyczny, ale z pewnością nie nierealny.
Zaczynamy więc pracować w matrixie, mającym wymiar zarówno struktury tradycyjnej (pionowy), jak i procesowo-projektowy (poziomy). Co więcej, ten matrix nie powoduje oderwania od rzeczywistości i niejasności, ale może skutecznie wprowadzać ład i porządek. I wcale nie ma na celu wyssania z nas całej naszej energii.
Autor: Andrzej Bogusz
Artykuły tego Autora
