środa, 18 września 2013

Model operacyjny – uzupełnienie


W październiku poprzedniego roku rozpocząłem prowadzenie tego bloga od przybliżenia koncepcji modelu operacyjnego przedsiębiorstwa. Napisałem wtedy, że dobra architektura korporacyjna (modele i architektura fizycznej organizacji) powinna odzwierciedlać wymagania na standaryzację i integrację procesów stawiane przez wybrany model operacyjny.

Dla przypomnienia – model operacyjny, to  zbiór założeń/wytycznych określających wymagany do realizacji strategii biznesowej poziom integracji i standaryzacji procesów biznesowych przedsiębiorstwa. Ze złożenia tych dwóch wymiarów powstanie nam macierz opisująca 4 możliwe modele operacyjne:
  • Niski poziom standaryzacji, Niski poziom integracji – Dywersyfikacja
  • Niski poziom standaryzacji, Wysoki poziom integracji – Koordynacja
  • Wysoki poziom standaryzacji, Niski poziom integracji – Replikacja
  • Wysoki poziom standaryzacji, Wysoki poziom integracji – Unifikacja

 Powyższy rysunek przedstawia charakterystyki poszczególnych modeli operacyjnych. Jednak na podstawie samych opisów może być trudno sobie wyobrazić, jaki wpływ ma wybór modelu operacyjnego na architekturę przedsiębiorstwa.

Dzisiaj przedstawiam 4 różne wizualizacje wpływu modelu operacyjnego na architekturę przedsiębiorstwa. Wizualizacje te znalazłem we wpisie na blogu Nicka Malika.

Koordynacja

W modelu koordynacji każda z kluczowych grup klientów jest obsługiwana w sposób zintegrowany. Integracja ta jest wynikiem współdzielenia danych pomiędzy jednostkami biznesowymi w celu zaprezentowania klientom jednolitego oblicza firmy. Przykładem firmy stosującej model koordynacji jest Metlife – firmy branży finansowej, oferującej usługi finansowe. Dzięki integracji klient może w jednym miejscu nabywać różne usługi finansowe pochodzące od różnych jednostek/grup biznesowych firmy. Z kolei poszczególne jednostki / grupy biznesowe mogą posiadać różne widoki tego samego klienta, właściwe dla prowadzonego przez nie biznesu.

Wpływ modelu koordynacji na architekturę poglądowo przedstawia to poniższy rysunek.




Architektura dla modelu koordynacji

Na powyższym rysunku każdy pojedynczy szary i długi poziomy prostokąt oznacza komponent współdzielony / zunifikowany pomiędzy jednostkami biznesowymi. Małe prostokąty oznaczają komponenty właściwe dla poszczególnych jednostek biznesowych.

W przypadku modelu koordynacji firma posiada jedną, wspólną dla wszystkich strategię. Oddzielne jednostki biznesowe, zarządzane indywidualnie, współdzielą klientów i/lub partnerów, ale działają w indywidualny sposób - posiadają własne procesy biznesowe a w nich przetwarzają własne, lokalne dane.

Taka architektura biznesowa odbija się na architekturze IT – różne sposoby działania (procesy) poszczególnych jednostek biznesowych implikują wykorzystywanie przez nie różnych aplikacji. Poszczególne jednostki działają samodzielnie (autonomicznie),, co oznacza, że w ww. procesach przetwarzane są lokalne dane biznesowe. Natomiast konsekwencją współdzielenia klientów pomiędzy jednostkami (np. w celu udzielenia zniżki na ubezpieczenie samochodu w zamian za ubezpieczenie mieszkania) po stronie architektury IT objawia się budowaniem centralnych baz / widoków / analiz klienta.

Jeśli chodzi o infrastrukturę IT - poszczególne jednostki biznesowe mogą współdzielić usługi infrastrukturalne takie jak centra obliczeniowe, przestrzenie dyskowe, standardy technologiczne, komunikatory czy pocztę korporacyjną.

Unifikacja

W modelu unifikacji jednostki biznesowe są ściśle zintegrowane wokół zestandaryzowanych procesów biznesowych. Firmy, które stosują model unifikacji wybierają synergię zamiast autonomii jednostek. Maksymalizują efektywność i jakość obsługi klienta dzięki silnie zintegrowanym danym i usuwaniu wszelkiej różnorodności z procesów. Przykładem firmy stosującej model unifikacji jest Dow Chemical – meksykański producent cementu działający na skalę międzynarodową.

Wpływ modelu unifikacji na architekturę poglądowo przedstawia to poniższy rysunek.

Architektura dla modelu unifikacji

Firmy stosujące model unifikacji posiadają jedną strategię główną dla całej firmy. Poszczególne jednostki biznesowe działają jak jedno przedsiębiorstwo – są zarządzane centralnie i realizują jeden zestaw procesów biznesowych. W ten sposób jednolicie obsługują jeden zbiór klientów firmy.

Unifikacja procesów i przetwarzanych informacji dla architektury IT oznacza, że firma posiada jeden zbiór aplikacji (przeważnie są to duże systemy ogólnofirmowe) wspierający jeden zestaw procesów (zero redundancji), działających na wspólnej infrastrukturze. Decyzje w sprawach IT zapadają w centrali. Nie ma też różnicy pomiędzy danymi lokalnymi a współdzielonymi – wszystkie dane są dostępne dla wszystkich jednostek realizujących danych proces.

Replikacja

W modelu replikacji poszczególne jednostki biznesowe cieszą się dużą autonomią zarządzania ale działają wg ściśle (centralnie) określonych procesów biznesowych. W modelu replikacji sukces firmy bardziej zależy od efektywnych, powtarzalnych procesów, niż od współdzielenia między jednostkami relacji z klientem. W modelu replikacji jednostki biznesowe mają bardzo mały wpływ na projekt realizowanych przez nie procesów pomimo, że działają niezależnie od siebie. Bardzo dobrym przykładem firmy działającej w tym modelu jest McDonalds (i inne franczyzy). Inny przykład to ING-Direct, który powiela raz zdefiniowane procesy w różnych krajach.

Wpływ modelu replikacji na architekturę poglądowo przedstawia to poniższy rysunek.

Architektura dla modelu replikacji

Architektura biznesowa modelu replikacji przekłada się na architekturę IT następująco: w zreplikowanych jednostkach biznesowych stosuje się ten sam (zreplikowany) zestaw aplikacji, które jednak przetwarzają odrębne (lokalne) dane. Praktycznie żadne dane nie są współdzielone. Ewentualne analizy (BI) są realizowane w ramach jednostki biznesowej i dotyczą lokalnych danych tej jednostki. Decyzje w sprawach IT zapadają w centrali.

Dywersyfikacja

Model dywersyfikacji stosują firmy, których jednostki biznesowe mają niewielu wspólnych klientów, dostawców czy sposobów prowadzenia biznesu. Jednostki biznesowe w dywersyfikowanych firmach oferują różne produkty różnym klientom. Zdywersyfikowane firmy osiągają wzrost dzięki wzrostowi poszczególnych jednostek oraz poprzez akwizycję innych firm, często o całkiem innym profilu działalności, niż pozostałe jednostki firmy. Przykładem firmy stosującej model dywersyfikacji jest Carlson Companies – firma składającej się z m.in. z sieci hoteli Radisson Hotels, restauracji T.G.I. Friday's, Carlson Marketing Group, biura podróży Carlson Wagonlit, oraz Radisson Seven Seas Cruises.

Model dywersyfikacji poglądowo przedstawia to poniższy rysunek.

Architektura dla modelu dywersyfikacji

Widać, że w zdywersyfikowanych firmach wszystko jest oddzielne: każda jednostka biznesowa ma swoją strategię, ma własnych klientów i własne produkty. Jest autonomiczna jeśli chodzi o zarządzanie, realizuje swoje własne procesy i przetwarza w nich swoje własne dane.

Z takiej zdywersyfikowanej architektury biznesu wynika zdywersyfikowana architektura IT – każda jednostka posiada własne aplikacje i własne dane, których nie współdzieli z innymi. Jedyne co poszczególne jednostki biznesowe mogą mieć wspólne, to infrastruktura IT.

Zakończenie

We wpisie z października poprzedniego roku napisałem, że dobra architektura korporacyjna (modele i architektura fizycznej organizacji) powinna odzwierciedlać wymagania na standaryzację i integrację procesów stawiane przez wybrany model operacyjny. Przedstawione wysokopoziomowe modele architektur spełniających te wymagania pomagają zrozumieć, czym jest model operacyjny i jaki ma wpływ na architekturę. Przedstawione przykłady dotyczą najwyższego poziomu firmy, ale ten sam sposób rozumowania można stosować na niższych poziomach. Co więcej firmy mogą mieć różne modele operacyjne na różnych poziomach. Np. poszczególne jednostki biznesowe firmy stosującej model dywersyfikacji mogą wewnątrz stosować model koordynacji lub unifikacji. Przykład takiej firmy opiszę w następnym artykule nt. modelu operacyjnego.


Bibliografia

  • J.W. Ross, P. Weill, D.C. Robertson, Architektura Korporacyjna jako strategia, Wyd. Emka, 2010.
  • Nick Malik, SOA and the CISR Operating Models, 2007, http://blogs.msdn.com/b/nickmalik/archive/2007/10/12/soa-and-the-cisr-operating-models.aspx, [2013-06-04].

Brak komentarzy:

Prześlij komentarz