W pierwszym artykule naszego cyklu pokazaliśmy system zarządzania jako architekturę kierowania firmą: sposób połączenia celów, odpowiedzialności, informacji, decyzji i reakcji na odchylenia. Teraz robimy kolejny krok i stawiamy bardziej podstawowe pytanie: co właściwie sprawia, że poszczególne mechanizmy zarządzania tworzą system?
Firma może mieć strategię, strukturę organizacyjną, budżet, KPI, system ERP, dashboardy, procedury, system jakości i rozwinięte zarządzanie projektami, a mimo to nadal mieć problem z osiąganiem postawionych celów. Samo posiadanie nawet bardzo dobrych narzędzi nie oznacza bowiem, że tworzą one skuteczny system zarządzania. Kluczowe stają się relacje pomiędzy nimi oraz logika, która łączy je z celami przedsiębiorstwa.
W drugim artykule cyklu przyglądamy się dlatego systemowi zarządzania jako całości. W jego pierwszej części pokazujemy różnicę pomiędzy zestawem praktyk i narzędzi a rzeczywistym systemem zarządzania oraz wyjaśniamy, dlaczego o jego jakości decydują trzy cechy: kompletność, spójność i dopasowanie do konkretnej organizacji.
Punktem wyjścia nie jest więc pytanie: „jakiego narzędzia nam brakuje?”, lecz znacznie ważniejsze pytanie zarządcze: czy rozwiązania, które już posiadamy, rzeczywiście tworzą mechanizm pozwalający skutecznie kierować przedsiębiorstwem?
Czym naprawdę jest system zarządzania przedsiębiorstwem
Firma może mieć strategię, strukturę organizacyjną, budżet, system ERP, kluczowe wskaźniki efektywności (KPI), dashboardy, procedury, certyfikowany system jakości, mechanizmy zarządzania projektami i regularny kalendarz spotkań zarządczych. Może mieć każdy z tych elementów i nadal nie mieć skutecznego systemu zarządzania — nadal mieć problem z osiąganiem postawionych celów. W takiej sytuacji problem nie polega na braku narzędzi, lecz na braku logiki, która łączy je w mechanizm pozwalający skutecznie kierować organizacją.
System zarządzania nie jest bowiem ani zbiorem najlepszych praktyk, ani zestawem konkretnych narzędzi, których wdrożenie gwarantuje skuteczność. Jest dopasowaną do danej organizacji, kompletną i spójną architekturą mechanizmów i narzędzi zarządzania, która pozwala przełożyć cele i strategię na bieżące działanie oraz zmianę, skierować na nie ograniczone zasoby, kontrolować rezultaty i reagować na odchylenia. O jego jakości nie decyduje liczba zastosowanych rozwiązań, lecz kompletność realizowanych funkcji, jakość powiązań pomiędzy poszczególnymi elementami oraz ich dopasowanie do organizacji.
To rozróżnienie ma praktyczne znaczenie dla zarządu i właścicieli. Można przez lata rozwijać poszczególne elementy organizacji, inwestować w systemy IT, raportowanie, controlling, zarządzanie projektami czy procedury i nadal nie poprawiać proporcjonalnie sterowności przedsiębiorstwa ani nie ograniczać ryzyka właścicielskiego. Każdy element może działać poprawnie lokalnie, podczas gdy całość pozostaje niespójna i nie tworzy sprawnego systemu zarządzania.
Dla kogo i po co
Ten artykuł jest skierowany do właścicieli, zarządów, CEO, COO i CFO, którzy chcą spojrzeć na system zarządzania szerzej niż przez pryzmat pojedynczych narzędzi. Dotyczy szczególnie organizacji, które mają już rozwiniętą strukturę menedżerską i wiele formalnych mechanizmów zarządzania, ale nadal widzą problemy z przełożeniem strategii na działanie, delegacją odpowiedzialności, zarządzaniem projektami, priorytetyzacją, jakością decyzji albo wykorzystaniem zasobów.
Celem tego artykułu nie jest stworzenie kolejnej uniwersalnej definicji. Chodzi o zbudowanie praktycznej perspektywy pozwalającej zarządowi odpowiedzieć na bardziej użyteczne pytanie: czy elementy, które posiadamy, rzeczywiście tworzą spójny system, który skutecznie wspiera realizację naszych celów?
System zaczyna się tam, gdzie elementy zaczynają działać razem
Jednym z podstawowych problemów w rozmowie o systemach zarządzania jest utożsamianie ich z listą narzędzi. Jeżeli firma ma strategię, strukturę, budżet, KPI, raportowanie, system ERP, spotkania i procedury — albo nawet tylko część tych elementów — łatwo uznać, że ma również sprawny i efektywny system zarządzania. Tymczasem samo istnienie narzędzi nie mówi jeszcze nic o jakości relacji pomiędzy nimi.
Można mieć strategię, która nie wpływa na budżet. Można mieć cele strategiczne, które nie zostały przełożone na strategie funkcjonalne poszczególnych obszarów. Można mieć KPI, które nie wynikają z celów strategicznych. Można mieć raporty pokazujące odchylenia, za którymi nie idą decyzje. Można mieć projekty, które nie wynikają ze strategii i nie są priorytetyzowane względem wspólnych zasobów. Można wreszcie mieć system premiowy, który zachęca do zachowań sprzecznych z tym, czego firma oczekuje i potrzebuje.
W każdym z tych przypadków poszczególne rozwiązania istnieją, ale niekoniecznie tworzą system.
Malmi i Brown, analizując systemy kontroli zarządczej, zwracają uwagę na tę zależność w bardzo prostym zdaniu: „MCS do not operate in isolation” — systemy kontroli zarządczej nie działają w izolacji.[1] Autorzy proponują patrzeć na szerszy pakiet mechanizmów obejmujący planowanie, kontrolę cybernetyczną, nagrody i wynagrodzenia, rozwiązania administracyjne oraz mechanizmy kulturowe.
Jeszcze dalej prowadzi rozróżnienie pomiędzy pakietem praktyk a systemem. W literaturze dotyczącej systemów kontroli zarządczej zwraca się uwagę, że samo współistnienie wielu praktyk nie oznacza jeszcze ich współzależności. Z perspektywy systemowej istotne staje się to, czy poszczególne rozwiązania zostały połączone w taki sposób, aby wzajemnie się uzupełniały i wspierały realizację celów organizacji.
To ważne rozróżnienie. Firma może posiadać kilkanaście dobrych praktyk zarządczych, z których każda została profesjonalnie wdrożona, ale które powstawały w różnym czasie, z różnych powodów i były tworzone przez różne zespoły. Strategię opracowywał zarząd, budżet rozwijał controlling, ERP wdrażały finanse z IT, system jakości rozwijał dział jakości, KPI powstawały lokalnie, HR projektował system premiowy, a zespół odpowiedzialny za projekty tworzył metodykę ich prowadzenia. Poszczególne rozwiązania mogą być nawet częściowo ze sobą skoordynowane. Problem zaczyna się wtedy, gdy nikt nie zaprojektował logiki całości. To właśnie przykład pakietu praktyk zarządczych, które współistnieją w organizacji, ale nie tworzą jeszcze spójnego systemu zarządzania.
W takiej sytuacji system motywacyjny może premiować wynik lokalny, podczas gdy strategia wymaga współpracy przekrojowej. Budżet może ograniczać zasoby potrzebne do realizacji projektów wynikających z priorytetów strategicznych. Projekty mogą konkurować o tych samych ludzi bez wspólnego mechanizmu priorytetyzacji. KPI mogą mierzyć efektywność poszczególnych funkcji, ale nie pokazywać wyniku procesów przekrojowych albo wręcz kierować wysiłek organizacji w stronę sprzeczną z celami strategicznymi. ERP może utrwalać proces, który organizacja powinna wcześniej przeprojektować.
Dlatego dojrzałość systemu nie polega na maksymalizowaniu liczby elementów ani na wdrażaniu rozwiązań, które są aktualnie popularne. Polega na kompletności, spójności i dopasowaniu. Kompletność oznacza, że w logice zarządzania nie brakuje krytycznych funkcji i ogniw. Spójność oznacza, że elementy wzajemnie się wspierają, zamiast wysyłać organizacji sprzeczne sygnały. Dopasowanie oznacza, że rozwiązania odpowiadają konkretnej strategii, skali, technologii, strukturze, ludziom, kulturze i otoczeniu przedsiębiorstwa.
W tym sensie system zarządzania nie jest produktem, który można kupić i wdrożyć według gotowego wzorca. Można kupić technologię, skorzystać z metodyki, wdrożyć standard albo wykorzystać rozwiązanie sprawdzone w innej firmie. Nie można jednak bezpośrednio skopiować całej architektury zarządzania, ponieważ jej skuteczność zależy od kontekstu organizacji. Nie można też zakładać, że zakup pojedynczego narzędzia rozwiąże problem dotyczący całego systemu.
Żadne narzędzie zarządzania nie jest systemem zarządzania
Najprostszym sposobem zrozumienia systemu zarządzania jest oddzielenie go od elementów, z którymi jest najczęściej utożsamiany. Struktura organizacyjna jest potrzebna, ale nie jest systemem zarządzania. KPI są potrzebne, ale nie są systemem zarządzania. Budżet jest potrzebny, ale również nim nie jest. Podobnie ERP, dashboard, system jakości, Project Management Office (PMO), procedury czy kalendarz spotkań.
Organigram jest dobrym przykładem. Może jasno pokazywać podległość, podział funkcji i podstawową odpowiedzialność. Brak aktualnej albo jednoznacznej struktury może generować istotną nieefektywność, konflikty lub luki kompetencyjne oraz niepotrzebne eskalowanie decyzji. Nie oznacza to jednak, że projektowanie systemu zarządzania powinno zaczynać się od rysowania nowego organigramu.
Najpierw trzeba rozumieć, dokąd firma zmierza, jakie wyniki chce osiągnąć, jakie procesy i zdolności są dla tego krytyczne, jakie decyzje muszą zapadać i gdzie powinna znajdować się odpowiedzialność. Dopiero wtedy można oceniać, czy istniejąca struktura wspiera tę logikę. Organigram powinien być konsekwencją sposobu działania organizacji, a nie substytutem jego zaprojektowania.
Podobny problem dotyczy systemów jakości. Certyfikowany system zarządzania jakością może być ważnym elementem szerszego systemu przedsiębiorstwa. Standaryzuje procesy, definiuje odpowiedzialności, wprowadza mechanizmy kontroli i doskonalenia oraz wspiera budowanie kultury procesowej. Nie jest jednak automatycznie równoznaczny z kompletnym systemem zarządzania przedsiębiorstwem w znaczeniu przyjętym w tym artykule. Firma może spełniać wymagania określonego standardu, a jednocześnie mieć słabe przełożenie strategii na cele, niewłaściwą alokację zasobów czy niespójny portfel projektów. Może więc posiadać dojrzały system zarządzania jakością, a jednocześnie nie mieć sprawnego systemu zarządzania całym przedsiębiorstwem
Równie często system zarządzania jest utożsamiany z budżetem. Budżet jest jednym z najważniejszych instrumentów planowania, kontroli i alokacji zasobów, ale sam nie odpowiada na pytanie, dlaczego określone zasoby mają zostać skierowane właśnie w dane miejsce. Jeżeli nie jest powiązany z długofalowymi priorytetami, strategiami funkcjonalnymi, planowanymi projektami i potrzebami operacyjnymi, może bardzo dobrze kontrolować wykonanie planu finansowego, a jednocześnie słabo wspierać realizację strategii.
To samo dotyczy technologii. ERP może integrować dane, standaryzować transakcje, wymuszać workflow i zwiększać przejrzystość procesów. Dashboard może radykalnie poprawić dostępność informacji. System workflow może uporządkować akceptacje. Żadne z tych rozwiązań nie powinno jednak stawać się nieświadomym projektantem systemu zarządzania. Jeżeli technologia narzuca logikę, która nie wynika z potrzeb organizacji i jej procesów zarządczych, może zwiększać złożoność, generować dodatkową pracę i obniżać skuteczność zarządzania zamiast ją poprawiać.
Najpierw trzeba odpowiedzieć, jaka informacja jest potrzebna, kto jej potrzebuje, jaką decyzję ma na jej podstawie podjąć, jakie ma uprawnienia, co powinno wydarzyć się w przypadku odchylenia i w jaki sposób sprawdzimy rezultat podjętej decyzji. Dopiero potem technologia może skutecznie obsłużyć tę logikę.
Podobnie należy patrzeć na zarządzanie projektami. Funkcja zarządzania projektami występuje w każdej organizacji, ponieważ każda organizacja realizuje przedsięwzięcia wymagające skoordynowania działań, odpowiedzialności, czasu i zasobów poza samym powtarzalnym wykonywaniem bieżących procesów. Nie oznacza to, że każda firma potrzebuje PMO, rozbudowanej metodyki czy osobnej struktury projektowej. Oznacza natomiast, że sposób inicjowania, prowadzenia, monitorowania i rozliczania projektów powinien być świadomie zaprojektowaną częścią systemu zarządzania.
Samo posiadanie project managerów, kart projektów, metodyki czy PMO nie oznacza jeszcze, że organizacja dobrze zarządza projektami. Kluczowe jest to, czy potrafi przełożyć priorytety strategiczne na portfel zmian, ocenić wartość i wymagania zasobowe projektów, ustalić kolejność realizacji, pogodzić odpowiedzialność projektową z operacyjną oraz w każdej chwili uzyskać rzetelną informację o stanie portfela. Równie ważna jest zdolność do reagowania na rezultaty projektów — również wtedy, gdy oczekiwane efekty nie zostały osiągnięte.
To prowadzi do ważniejszego wniosku: nie należy najpierw decydować, jakie narzędzie zarządzania wdrożyć. Trzeba ustalić, jaką funkcję systemu trzeba zapewnić, aby był on kompletny, spójny i dopasowany. Dopiero potem należy wybierać rozwiązanie metodyczne, a następnie rozwiązanie techniczne lub cyfrowe, które tę logikę wspiera.
Cele nadają sens całemu systemowi
Każdy system zarządzania potrzebuje punktu odniesienia. Bez niego nie można racjonalnie ocenić ani struktury, ani procesów, ani KPI, ani projektów, ani jakości decyzji. Tym punktem są cele organizacji wynikające z jej roli, strategii i oczekiwań kluczowych interesariuszy.
Nie oznacza to prostego przełożenia oczekiwań interesariuszy na listę celów. Oczekiwania właścicieli, klientów, pracowników, regulatorów, partnerów czy innych grup mogą być wzajemnie sprzeczne. Wyższa rentowność, większe inwestycje, szybszy wzrost, niższe ryzyko, większa stabilność zatrudnienia, lepsza jakość i niższe ceny nie zawsze mogą być maksymalizowane jednocześnie. Rolą zarządzania jest dokonywanie wyborów.
Strategia porządkuje te wybory. Powinna określać, jakie rezultaty są dla organizacji najważniejsze i w jaki sposób przedsiębiorstwo zamierza je osiągnąć. Dopiero z tej perspektywy można sensownie projektować kolejne elementy systemu.
David Otley, konstruując ramy zarządzania wynikami organizacji, zaczyna od kluczowych celów związanych z wizją, następnie przechodzi do strategii i planów, poziomów docelowych, mechanizmów nagradzania oraz informacji potrzebnej do monitorowania wyników i uczenia się.[2] Co ważne, nie traktuje pojedynczej techniki jako wystarczającej. Pisze: „A more holistic approach is clearly appropriate” — właściwe jest podejście bardziej całościowe.[3]
Z perspektywy zarządu oznacza to, że cel strategiczny nie może pozostać na poziomie prezentacji zarządu. Musi zostać rozwinięty w organizacji.
Nie chodzi przy tym wyłącznie o mechaniczne kaskadowanie polegające na podzieleniu celu całej firmy na cele działów. Taka praktyka może prowadzić do pozornej spójności: każdy obszar otrzymuje swój wskaźnik, ale nadal nie wiadomo, w jaki sposób zamierza osiągnąć oczekiwany rezultat.
Rozwinięcie strategii powinno więc prowadzić nie tylko do kaskadowania celów, ale również do odpowiedzi na pytanie, w jaki sposób i jakimi środkami cele te zostaną osiągnięte. Jednym z mechanizmów służących do tego są strategie funkcjonalne. Sprzedaż, operacje, finanse, HR, zakupy, logistyka czy IT powinny potrafić określić, w jaki sposób przyczynią się do realizacji priorytetów całej organizacji, jakie zdolności muszą zbudować, jakie działania wykonać, jakie zmiany przeprowadzić i jakich zasobów będą potrzebować.
Te programy cząstkowe nie mogą jednak powstawać niezależnie. Powinny być wzajemnie skoordynowane, podporządkowane zatwierdzonym celom strategicznym oraz skonfrontowane z rzeczywistymi możliwościami zasobowymi organizacji.
W tym miejscu użyteczna jest logika Hoshin Kanri: cele nadrzędne nie powinny być jedynie przekazywane w dół organizacji, lecz rozwijane i uzgadniane w taki sposób, aby poszczególne części przedsiębiorstwa rozumiały swój wkład w całość, a cele były uzgadniane zarówno pionowo, jak i poziomo. Szczegółowe omówienie tego mechanizmu wymaga osobnego tekstu. Dla definicji systemu zarządzania ważny jest sam wniosek: cel strategiczny musi zostać przełożony na mechanizm wykonania, właściwie zakomunikowany i uzgodniony w organizacji.
Dopiero wtedy pojawia się właściwe miejsce dla KPI, KAI oraz projektów potrzebnych do osiągnięcia celów. Kluczowe wskaźniki efektywności — Key Performance Indicators (KPI) — powinny pokazywać istotne rezultaty. Key Activity Indicators (KAI) mogą uzupełniać tę perspektywę poprzez obserwowanie działań prowadzących do wyniku. Sam podział wskaźników nie rozwiązuje jednak problemu. Istotne jest ich miejsce w całym łańcuchu: cel → odpowiedzialność → działanie → miernik → decyzja → reakcja.
Szczególnie niebezpieczne są cele lokalne oderwane od całości. Dział może poprawić swój wynik, jednocześnie pogarszając wynik przedsiębiorstwa. Zakupy mogą obniżyć cenę jednostkową kosztem jakości lub zapasu. Produkcja może zwiększyć wykorzystanie maszyn kosztem zapasu i czasu realizacji. Sprzedaż może zwiększyć przychód kosztem marży albo warunków płatności. IT może zoptymalizować koszt utrzymania kosztem szybkości realizacji krytycznych zmian.
System zarządzania powinien więc nie tylko rozdzielać cele, ale również identyfikować i rozstrzygać konflikty między nimi, koordynować podejmowane działania oraz umożliwiać właściwą alokację ograniczonych zasobów — zarówno wewnętrznych, jak i zewnętrznych. Jego zadaniem nie jest maksymalizacja wyników poszczególnych części, lecz kierowanie całością w stronę celów organizacji.
Przypisy
[1] Teemu Malmi, David A. Brown, „Management control systems as a package—Opportunities, challenges and research directions”, Management Accounting Research, 2008, vol. 19, nr 4, s. 287–300. Cytat w oryginale: „MCS do not operate in isolation”.
[2] David Otley, „Performance management: a framework for management control systems research”, Management Accounting Research, 1999, vol. 10, s. 363–382. Autor konstruuje ramę analizy wokół celów, strategii i planów, poziomów docelowych, nagród oraz informacji zwrotnej.
[3] David Otley, „Performance management: a framework for management control systems research”, Management Accounting Research, 1999, vol. 10, s. 377. Cytat w oryginale: „A more holistic approach is clearly appropriate”.
Bibliografia
Bedford, David S., Malmi, Teemu, Sandelin, Mikko, „Management control effectiveness and strategy: An empirical analysis of packages and systems”, Accounting, Organizations and Society, 2016.
Chenhall, Robert H., „Management control systems design within its organizational context: findings from contingency-based research and directions for the future”, Accounting, Organizations and Society, 2003, vol. 28, s. 127–168.
Fama, Eugene F., Jensen, Michael C., „Separation of Ownership and Control”, Journal of Law and Economics, 1983, vol. 26, nr 2.
Kaplan, Robert S., Norton, David P., „Mastering the Management System”, Harvard Business Review, January 2008.
Malmi, Teemu, Brown, David A., „Management control systems as a package—Opportunities, challenges and research directions”, Management Accounting Research, 2008, vol. 19, nr 4, s. 287–300.
Otley, David, „Performance management: a framework for management control systems research”, Management Accounting Research, 1999, vol. 10, s. 363–382.
Stabryła, Adam, „Koncepcja wieloaspektowej analizy systemów zarządzania przedsiębiorstwem”, Zeszyty Naukowe Uniwersytetu Ekonomicznego w Krakowie, nr 871, Kraków 2011.
