Konfiguracja wartości, czyli co telekomy mają wspólnego z serwisami aukcyjnymi

Większości z nas termin „łańcucha wartości” nie powinien być obcy. Każdy też ma miej więcej jako takie wyobrażenie, co ten termin oznacza. Ale sądzę, że nie każdy wie, skąd się ten termin wziął oraz – co ważniejsze – że dla łańcucha wartości istnieją alternatywy. Jak się bowiem okazuje łańcuch wartości nie jest jedynym sposobem kreowania wartości dla klientów. Istnieją jeszcze co najmniej dwa inne.

Łańcuch wartości (ang. value chain)

Autorem konceptu jest Michael E. Porter – światowej sławy ekspert w dziedzinie strategii organizacji i konkurencji. Opracowany przezeń model łańcucha wartości określa zbiór generycznych aktywności, które przedsiębiorstwo realizuje, aby wytwarzać wartość dla swoich klientów. Wymyślony w 1985 zdominował myślenie zarówno szefów biznesowych jak i IT.

W łańcuchu wartości materiały wejściowe są przekształcane w produkty, które stają się medium (wzajemnego) transferu wartości pomiędzy firmą a klientem. Celem jest wytworzenie wartości w taki sposób tak, aby wartość końcowa dla firmy przewyższała poniesione koszty. Symbolizuje to marża pokazana po prawej stronie łańcucha.

Źródło: M. Porter, Competitive Advantage: Creating and Sustaining Superior Performance, Free Press, New York, 1985.

Model łańcucha wartości składa się z dwóch rodzajów generycznych aktywności. Aktywności główne, są bezpośrednio zaangażowane w tworzenie i dostarczanie wartości klientom. Aktywności wspierające umożliwiają działanie i/lub wpływają na efektywność aktywności głównych przez co również mają wpływ na wartość dostarczaną klientom. Przykładem firm stosujących logikę łańcucha wartości są wszelkie firmy produkcyjne.

Firmy działające w konfiguracji łańcucha wartości najczęściej koncentrują się na całkowitej efektywności aktywności łańcucha, gdyż w taki właśnie sposób te firmy tworzą wartość. Dotyczy to nawet aktywności skierowanych na klienta.

Od czasu powstania ww. koncepcji niezliczona liczba managerów stosowała model łańcucha wartości do analizy sposobów kreowania wartości i formułowania nowych, konkurencyjnych strategii. Jednak w wielu branżach, np. w konsultingu, opiece zdrowotnej, bankowości, ubezpieczeniach czy telekomunikacji model łańcucha wartości okazał się trudny do zastosowania. Dla tych branż Øystein Fjeldstad oraz Charles Stabell w 1998 zaproponowali dwie dodatkowe logiki kreowania wartości: warsztat wartości oraz sieć wartości. Wraz z łańcuchem wartości składają się na zbiór różnych, generycznych modeli konfiguracji wartości (ang. value configuration).

Warsztat wartości (ang. value shop)

Logika warsztatu wartości polega na tym, że firma kreuje wartość nie poprzez przekształcanie materiałów wejściowe w produkty ale poprzez mobilizowanie posiadanych zasobów (ludzi, wiedzy czy pieniędzy) i podejmowanie specyficznych działań w celu rozwiązywania specyficznych problemów klienta. „Problemem” może być faktyczny problem jak i również przygotowanie sztuki teatralnej czy doprowadzenie do kupna-sprzedaży nieruchomości.
Generalnie problem będzie różnica pomiędzy stanem istniejącym a stanem wymaganym danego obiektu. Rozwiązywaniem problemu kreującym wartość będzie zmiana aktualnego stanu obiektu na stan bardziej pożądany. Obiektem może być zarówno firma (która chce dokonać u siebie zmiany), człowiek (chory, który chce być zdrowy), system (który trzeba zmienić) albo wiedza (którą trzeba rozwinąć lub zdobyć).  Wybór, połączenia oraz kolejność zastosowania zasobów i działań będą się różnić w zależności od rozwiązywanego problemu.

Podobnie jak w łańcuchu wartości, konfiguracja warsztatu wartości również składa się z dwóch rodzajów generycznych aktywności. Aktywności główne, są bezpośrednio zaangażowane w tworzenie i dostarczanie wartości klientom – tutaj zaangażowane w rozwiązywanie ich problemów. Warsztat wartości również zawiera aktywności wspierające umożliwiają działanie i/lub wpływają na efektywność aktywności głównych.

Źródło: C.B. Stabell and Ø.D. Fjeldstad, Configuring value for competitive advantage: on chains, shops, and networks, Strategic Management Journal, Vol. 19, 413–437, 1998.

Firmy wytwarzające wartość wg logiki warsztatu wartości, to wszelkie firmy świadczące usługi fachowe, takie jak firmy consultingowe, lekarze, prawnicy, warsztaty samochodowe, czy firmy typu body shop dostarczające specjalistów wybranych dziedzin. To również firmy i organizacje, których głównym celem jest identyfikacja i wykorzystanie specyficznych okazji rynkowych takich wynajdowanie nowego leku, poszukiwania ropy czy projektowanie nowego samolotu wojskowego. W takim przypadku logika warsztatu wartości jest często stosowana nie dla całych firm ale dla ich części pomimo, że główną logiką danej firmy jest np. łańcuch wartości. Wtedy działalność takiej jednostki biznesowej jest najczęściej reprezentowana jako aktywność wspierająca w łańcuchu wartości.

Przy okazji: można zauważyć, że praktyka architektoniczna i usługi świadczone przez architektów doskonale pasują właśnie do modelu warsztatu wartości. Praktyka architektoniczna przenosi firmę z jednego stanu do drugiego, polega na analizie wymagań i trosk interesariuszy, projektowaniu architektur je adresujących, planowaniu drogi dojścia i nadzorowaniu realizowanych zmian.

Sieć wartości (ang. value network)

Na początek wyjaśnienie: konfiguracja sieci wartości zaproponowana przez Fjeldstada & Stabella to nie jest to samo, co „sieć wartości” rozumiana jako grupa firm, z których każda specjalizuje się w jakimś fragmencie łańcucha wartości i razem ten łańcuch tworzą dostarczając produkty i usługi.

Wg badań Fjeldstada & Stabella firmy pracujące w konfiguracji sieci wartości dostarczając wartość swoim klientom poprzez łączenie ich ze sobą lub pośrednicząc w wymianach pomiędzy nimi. Dostarczana wartość zależy od tego, z kim klient danej sieci może się skomunikować.
Firmy pracujące w konfiguracji sieci wartości:

• działają jak kluby – tworzą, monitorują i kończą bezpośrednie lub pośrednie relacje pomiędzy członkami; przyjmują tylko takich członków, którzy się wzajemnie uzupełniają,
• zwykle posiadają jakąś formę infrastruktury umożliwiającej efektywne pośredniczenie w interakcjach i wymianach pomiędzy członkami sieci,
• zwiększają wartość dla klienta poprzez powiększanie sieci – im więcej klientów jest lub może być dołączonych do sieci, tym większą wartość przedstawia dla każdego z jej klientów.

Tak jak w łańcuchu wartości, konfiguracja sieci wartości również składa się z dwóch rodzajów generycznych aktywności. Aktywności główne są tutaj zaangażowane w pośredniczenie wymian pomiędzy klientami sieci. Aktywności wspierające umożliwiają działanie i/lub wpływają na efektywność aktywności głównych.

Źródło: C.B. Stabell and Ø.D. Fjeldstad, Configuring value for competitive advantage: on chains, shops, and networks, Strategic Management Journal, Vol. 19, 413–437, 1998.

Oczywistym przykładem firmy pracującej w tej konfiguracji będzie operator telekomunikacyjny, który łączy swoich klientów bezpośrednio. Ale w `tej konfiguracji pracują również np. serwisy społecznościowe pośredniczące w wymiany treści (np. LinkedIn czy niniejszy blogspot), firmy świadczące usługi pocztowe lub logistyczne, pośredniczące w wymianie zarówno treści jak i materii a także firmy ubezpieczeniowe czy banki, które łączą klientów mających różne potrzeby finansowe. Generalnie biznes tych wszystkich firm polega na pośredniczeniu w interakcjach swoich klientów.

Rodzaj dostarczanej wartości determinuje architekturę firmy

Przedstawione 3 generyczne konfiguracje wartości, to ogólne modele umiejętności, które firmy muszą posiadać w celu dostarczania wartości klientom. Zestawy tych umiejętności wynikają z rodzaju wartości dostarczanej klientom:
•    wartość dostarczana klientom w postaci produktów (Porter)
•    wartość dostarczana klientom w postaci rozwiązywania ich problemów (Fjeldstad & Stabell)
•    wartość dostarczana klientom w postaci pośredniczenia w interakcjach i wymianach pomiędzy nimi (Fjeldstad & Stabell).

Zatem kluczem do określenia koniecznych umiejętności firmy (czyli jej architektury) jest określenie rodzaju wartości, którą dana firma chce dostarczyć swoim klientom. Firma może wybrać jeden lub więcej rodzajów z ww. rodzajów wartości. Ale im więcej rodzajów wartości wybierze, tym więcej umiejętności musi posiadać, więc jej działalność w sumie będzie droższa.

Jeśli przyjrzymy się przedstawionym generycznym konfiguracjom wartości, to zauważymy, że znane nam, referencyjne modele branżowe (np. eTOM, BIAN, ACORD, SCORE, modele APQC, …) idealnie się w nie wpasowują. Innymi słowy przedstawione konfiguracje wartości , to nic innego, jak tylko po prostu bardziej uogólnione modele referencyjne wynikające nie tyle z branży tylko z rodzaju dostarczanej wartości. W kontinuum architektonicznym TOGAF umieściłbym je pomiędzy Common Systems Architectures a architekturami branżowymi (ang. Industry Architectures).

Adaptacja na podstawie: The Open Group, TOGAF 9.1.

Konsekwencje wyboru konfiguracji wartości

Jeszcze raz podkreślę: kluczem do określenia koniecznych umiejętności firmy (czyli architektury firmy) jest określenie wartości, którą firma chce dostarczyć swoim klientom. Firma może wybrać jedną lub więcej rodzajów wartości z ww. 3 rodzajów. Im więcej rodzajów wartości wybierze, tym więcej umiejętności musi posiadać.

Wybranie podstawowej konfiguracji wartości znakomicie ułatwia podejmowanie spójnych decyzji architektonicznych i wspiera reużycie istniejących umiejętności firmy (w tym i systemów IT). Z kolei brak takiego wyboru lub wybór niedopasowany do sedna działalności firmy może prowadzić do namnożenia procesów i systemów.

Aby uzmysłowić wagę wybory rodzaju dostarczanej wartości, posłużę się przykładem dla branży telekomunikacyjnej. Przykład jest abstrakcyjny i przejaskrawiony ale pokazuje różnice w podejściu do projektowania architektury w zależności od tego, czy mamy, czy nie mamy zdefiniowanej / wybranej konfiguracji wartości.

Sensem działalności firmy telekomunikacyjnej jest pośredniczenie w interakcjach swoich klientów. Firma telekomunikacyjna świadczy w tym celu usługi telekomunikacyjne ale to są inne usługi, niż usługi firmy doradczej czy usługi zakładu naprawy obuwia. Usługi firmy doradczej czy zakładu naprawy obuwia polegają na rozwiązywaniu specyficznych problemów swoich klientów. Usługi operatora telekomunikacyjnego służą do realizacji interakcji pomiędzy jego klientami.

Wyobraźmy sobie sytuację, że nasz operator, oprócz usług telekomunikacyjnych wytwarzanych przez siebie, chce dodatkowo zaoferować swoim klientom produkt ubezpieczeniowy lub bankowy, którego sam nie wytwarza – jest to produkt od zewnętrznej firmy X.

Na pierwszy rzut oka relacja operatora z firmą X wygląda na relację dostawca - odbiorca: firma X dostarcza swój produkt a operator ten produkt odbiera i oferuje swoim klientom. Zatem zbudowanie tej relacji po stronie operatora będzie polegało na:
•    zbudowaniu / rozbudowaniu umiejętności współpracy z dostawcami
•    tę relację będą obsługiwać ludzie od współpracy z dostawcami
•    i będą do tego używać systemów do współpracy z dostawcami.

Gdybyśmy jednak sobie wcześniej przyjęli, że działalnością operatora jest pośredniczenie w interakcjach pomiędzy klientami, to firma zewnętrzna X nagle przestaje być dostawcą i staje się klientem! Takim klientem, któremu operator po prostu pomaga wymieniać wartość z innymi swoimi klientami. Konsekwencją takiego myślenia nie będzie już budowa dedykowanego interfejsu do firmy X - dostawcy. Konsekwencją takiego myślenia będzie wystawienie oferty dla firm zewnętrznych typu banki i/lub firmy ubezpieczeniowe – oferty pośrednictwa w wymianie wartości pomiędzy tymi firmami a pozostałymi klientami operatora. Interfejs z firmą zewnętrzną będzie ten sam, jak z innymi klientami typu enterprise. Relacji z bankiem nie będą obsługiwać ludzie od współpracy z dostawcami ale ludzie od współpracy z klientami. Ich pracę będą wspierać te same systemy, które służą do zarządzania relacjami z klientami.

Generalnie w pierwszym przypadku, gdy zewnętrzną firmę X operator potraktuje jako dostawcę, to musi zbudować lub rozbudować umiejętności współpracy z dostawcami. W drugi przypadku, gdy zewnętrzną firmę X operator potraktuje jako klienta (bo podstawową działalnością operatora pośredniczenie w interakcjach i wymianach pomiędzy swoimi klientami), to wtedy rozwiązanie architektoniczne współpracy z firmą X będzie polegało na wykorzystaniu tych samych umiejętności (w tym systemów IT), które służą do współpracy z klientami.

Korzyść dla architekta

Przedstawione typy konfiguracji wartości mogą być bardzo pomocne w pracy architekta: jeśli pracujesz dla branży, dla której nie istnieją żadne modele referencyjne – wybierz model referencyjny dla branży o takiej samej konfiguracji wartości, jak twoja. Na pewno będzie pasował  (z dokładnością do przedmiotu działalności, używanej nomenklatury, różnic wynikających z regulacji czy dostępnych technologii automatyzujących).

W mojej karierze zawodowej najwięcej czasu spędziłem w branży telekomunikacyjnej. Jednak miałem również okazję pracować m.in. w branży ubezpieczeniowej. Okazało się wtedy, że modele referencyjne telco, takie jak eTOM pasują również do ubezpieczeń. Różnice polegały jedynie na stopniu rozwoju poszczególnych umiejętności firmy. Np. w telco i w ubezpieczeniach przed podpisaniem kontraktu trzeba oszacować ryzyko związane z przyłączeniem danego klienta do „sieci” (telekomunikacyjnej w telco lub finansowej w ubezpieczeniach). W telco ta analiza jest dużo prostsza niż w ubezpieczenia. Ale występuje i tu i tu.

Na podobnej zasadzie, jak operatorzy telekomunikacyjni, działają również serwisy aukcyjne. I operator telco i serwis aukcyjny dostarcza wartość swoim klientom poprzez umożliwianie im interakcji i wymian. Spodziewam się więc, że modele referencyjne telco będą również pasować do serwisów aukcyjnych :-)

Bibliografia

•    C.B. Stabell and Ø.D. Fjeldstad, Configuring value for competitive advantage: on chains, shops, and networks, Strategic Management Journal, Vol. 19, 413–437, 1998.
•    M. Porter, Competitive Advantage: Creating and Sustaining Superior Performance, Free Press, New York, 1985.

Firmy inteligentne

Kiedy architektura korporacyjna jest potrzebna

W książce Klausa D. Niemanna, pt. „From Enterprise Architecture to IT Governance” trafiłem na bardzo prosty ale jednocześnie bardzo wymowny rysunek obrazujący potrzebę posiadania architektury korporacyjnej w organizacji. Generalnie im organizacja jest bardziej złożona lub im bardziej zmienna, tym potrzeba posiadania architektury korporacyjnej jest większa.

Źródło: K.D. Niemann, From Enterprise Architecture to IT Governance, Elements of Effective IT Management, Vieweg, Wiesbaden, 2006..

Brzmi to logicznie. Jeśli dana organizacja musi odpowiadać na częste zmiany na rynku, jeśli rozwija się poprzez przejęcia i fuzje, to częstość i skala dokonywanych w niej zmian będą duże. Jeśli jeszcze dodatkowo opiera swoją działalność na IT (a dziś już chyba nie ma innych firm), to częste zmiany będą dotyczyć i biznesu i IT. W takiej sytuacji architektura korporacyjna jest nieodzownym instrumentem analizy, planowania i nadzorowania spójnych zmian w organizacji, w tym w IT.

Jeśli dodatkowo dana organizacja, jest wystarczająco duża pod względem liczby zatrudnionych osób, wykonywanych funkcji czy lokalizacji, to tym bardziej potrzebuje ona architektury korporacyjnej do wprowadzania zarówno drobnych jak i dużych zmian.

Mimo to większość dzisiejszych, często zmiennych i dużych organizacji w Polsce obywa się bez architektury korporacyjnej i są one w stanie w miarę efektywnie działać jak i efektywnie dokonywać zmian. Może to oznaczać, że albo firmy stosują inne, mniej sformalizowane sposoby na dokonywanie spójnych zmian w organizacji albo prędzej czy później czeka je poważna transformacja.

Poniżej trochę moich przemyśleń na ten temat – nie popartych formalnymi badaniami ale wynikających z obserwacji i doświadczenia.

Życie bez architektury

Co zatem te przedsiębiorstwa tracą dokonując zmian bez użycia podejścia architektonicznego? Otóż stawiam tezę, że architektura korporacyjna w dużych i często zmiennych przedsiębiorstwach nie tylko ułatwiałaby (tryb ciągły) dokonywanie zmian, ale przede wszystkim chroniłaby te przedsiębiorstwa przed wylądowaniem w obszarze katastrofy architektonicznej. Obszar katastrofy architektonicznej znajduje się na poniższym rysunku w prawym górnym rogu.

Źródło: adaptacja na podstawie K.D. Niemann, From Enterprise Architecture to IT Governance, Elements of Effective IT Management, Vieweg, Wiesbaden, 2006.

W obszarze katastrofy architektonicznej efektywność bieżącej działalności oraz potencjalny przychód ze zbioru możliwych (czytaj: opłacalnych) zmian nie wystarcza na pokrycie kosztów działalności przedsiębiorstwa. W takich firmach, stojących na skraju przepaści, na architekturę korporacyjną jest już za późno. W takich firmach jedynym rozwiązaniem jest duża, szybka i bolesna transformacja typu zbudowanie firmy od nowa, wymiana całego oprogramowania na nowy stack z pudełka, itp.

Architektura korporacyjna jako transformacja ciągła

W dzisiejszych czasach, gdy rynek, technologie, możliwości i oczekiwania klientów tak szybko się zmieniają, firmy muszą nie tylko działać (RUN), nie tylko rosnąć w ramach prowadzonej działalności (GROWTH) ale również transformować sposoby  i zakres swojego działania (TRANSFORM). Dzisiaj nie wystarcza już dobre robienie swojego biznesu – trzeba go robić coraz inaczej.

Praktyka architektoniczna rozumiana jako ciągła, holistyczna analiza, planowanie i nadzorowanie dokonywania spójnych zmian w organizacji, jest sposobem na transformację ciągłą. W takim wypadku każdy projekt musi nie tylko realizować doraźne cele biznesowe, ale także przyczyniać się do rozwoju architektury przedsiębiorstwa (a przynajmniej nie szkodzić): deliver for project, build for enterprise.

Praktyka architektoniczna rozumiana jako umiejętność holistycznej analizy, planowania i nadzorowania zmian, to obok takich umiejętności (capabilities), jak Zarządzanie Relacjami z Klientami, Rozwój Ofert i Produktów czy Zarządzanie Zasobami Ludzkimi, jeszcze jedna umiejętność firmy. Z tym, że o ile ww. umiejętności dot. klientów, produktów czy zasobów ludzkich wydają się konieczne do prowadzenia biznesu, to umiejętność (capability) dokonywania zmiany już na konieczną nie wygląda.

Dług architektoniczny

W firmach kierujących się jedynie doraźnymi potrzebami lokalnymi, nie myślących o przyszłości, nie myślących o ciągłym wzmacnianiu umiejętności wielokrotnego wykorzystania, taki proces ciągłej transformacji nie zachodzi. W efekcie „dług transformacyjny” (dług architektoniczny) narasta. Z biegiem czasu taka firma płaci zarówno „odsetki” od tego długu (zmiany są coraz droższe a efektywność działania spada lub coraz trudniej ją utrzymać) oraz dodatkowo ten dług powiększa. W końcu jedynym wyjściem staje się tylko szybka transformacja o zakresie Wielkiego Wybuchu.

Transformować też jednak trzeba umieć. A ponieważ firma nie doskonaliła wcześniej praktyki architektonicznej, czyli umiejętności dokonywania spójnych zmian w organizacji, takie transformacje narażone są na dodatkowe ryzyka związane z „niekompetencją” w tym obszarze. Pomoc z zewnątrz jest wtedy nieodzowna a wykorzystanie podejścia architektonicznego – konieczne.

Do tego wszystkiego często się zdarza, że w trakcie przeprowadzania transformacji nie pamięta się o najważniejszej przyczynie konieczności jej przeprowadzenia – braku umiejętności ciągłej i spójnej adaptacji do zmian otoczenia. Wtedy po transformacji firma wraca na dawne tory i znów działa w podobny sposób, jak wcześniej. Aż do następnej transformacji.

Architektura korporacyjna jako inteligencja organizacji

Architektura korporacyjna, rozumiana jako ciągła praktyka holistycznej analizy, planowania i nadzorowania dokonywania zmian w organizacji jest sposobem na inwestowanie nie dużo, lecz mądrze. Zaryzykowałbym nawet stwierdzenie, że stanowi ona „inteligencję organizacji”. Jak mózg u człowieka pomaga mu utrzymać dyscyplinę i wytrwałość w doskonaleniu umiejętności potrzebnych mu długoterminowo, tak praktyka architektoniczna pomaga przedsiębiorstwu utrzymać dyscyplinę i sposób skoordynowany doskonalić umiejętności wielokrotnego wykorzystania.

W przypadku firmy działającej w cyklu od transformacji do transformacji, ta „inteligencja” budzi się tylko na czas kryzysu (w czasie transformacji) a zasypia pomiędzy nimi. W organizacjach z wdrożoną praktyką architektoniczną ta „inteligencja” występuje w sposób ciągły. Takie przedsiębiorstwa nazywam „firmami inteligentnymi”.

Czy taka inteligencja jest firmom potrzebna? Tak, ale tylko potrzebna i tylko do uniknięcia katastrofy. Czyli aż do momentu, kiedy staje się za późno. Może właśnie dlatego tak trudno jest uzasadniać potrzebę wdrożenia praktyki architektonicznej w organizacji - dotyczy bowiem przyszłego i bliżej nieokreślonego ryzyka utraty efektywności działania i niemożności dokonywania zmian. Trudno znaleźć chętnych do inwestowania w coś tak mglistego.

Bibliografia

• K.D. Niemann, From Enterprise Architecture to IT Governance, Elements of Effective IT Management, Vieweg, Wiesbaden, 2006.
• J.W. Ross, P. Weill, D.C. Robertson, Architektura Korporacyjna jako strategia, Wyd. Emka, 2010.
• J.W. Ross, C.B. Beath, USAA: Organizing for Innovation and Superior Customer Service, CISR WP No. 382 and MIT Sloan WP No. 4937-11, Massachusetts Institute of Technology, 2010.

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].

Złożoność EA (5) – Zmniejszanie złożoności przez partycjonowanie

W pierwszej części cyklu na temat złożoności w Architekturze Korporacyjnej przyjęliśmy, że estymatorem złożoności systemu / układu jest liczba stanów, w których może się on znaleźć. Zmniejszanie złożoności będzie więc polegało na zmniejszaniu liczby stanów systemu / układu systemów, których może się on znaleźć.
Pierwszym sposobem zmniejszania liczby stanów układu było upraszczanie. Dzisiaj napiszę o drugim ze sposobów, jakim jest partycjonowanie.

Gra w kości

Aby zrozumieć czym jest partycjonowanie i jak wpływa na złożoność, posłużymy się kostkami do gry. Weźmy układ złożony z dwóch kostek sześciościennych. Taki układ ma 36 możliwych stanów, w których może się znaleźć. Jeśli jednak jedną kostką będziemy rzucać oddzielnie od drugiej, to taki układ dwóch niezależnych od siebie układów jedno-kostkowych będzie już miał jedynie 6 + 6 = 12 możliwych stanów.
Inny przykład: dla układu 3 kostek liczba możliwych stanów, w których może się on znaleźć wynosi 216. Jednak jeśli ten układ podzielimy na 3 oddzielne i niezależne układy jedno-kostkowe, to liczba stanów takiego układu będzie wynosiła 6 + 6 + 6 = 18.

Spartycjonowanie układu 3 kostek.
Źródło: R. Sessions.

Uogólniając - dla układu B niezależnych układów kostek, z których każdy zawiera D kostek F-ściennych, liczba możliwych stanów, czyli całkowita złożoność C takiego układu układów kostek, będzie wyrażona wzorem:
C = B * F^D

Jeśli układ 12 kostek podzielimy na dwa oddzielne, niezależne układy, każdy złożony z 6. kostek, to liczba stanów takie układu układów będzie wynosiła 2 * 6^6 = 93.000 stanów. Innymi słowy podzielenie układu 12 kostek na dwa niezależne układy sześciu kostek zmniejszyło nam złożoność całego układu z ponad dwóch miliardów do około 96.000, co daje 99,99571 procentowe zmniejszenie złożoności! Podział układu 12 kostek na 3 niezależne części zmienia złożoność układu z ponad dwóch miliardów stanów do 3 * 6^4 = 3.888 stanów, co daje pod 500.000-krotne zmniejszenie złożoności.

Partycjonowanie

Podział układu kostek na niezależne podukłady zmniejsza istotnie złożoność takiego układu pod jednym ważnym założeniem - każda kostka musi się znaleźć w dokładnie jednym podukładzie (nie może występować w kilku). Istnieje w matematyce analogiczna koncepcja dzielenia przestrzeni elementów na grupy - to podział (partycja) zbioru. Podział zbioru X, to zbiór P niepustych podzbiorów zbioru X takich, że każdy element x zbioru X znajduje się w dokładnie jednym podzbiorze zbioru P . W efekcie suma elementów wszystkich takich podzbiorów powinna dawać zbiór X a dla każdej pary różnych podzbiorów ich część wspólna jest zawsze zbiorem pustym:

Przy założeniu, że układ kostek, system informatyczny oraz proces biznesowy są ze sobą homomorficzne, podział (spartycjonowanie) układu kostek, systemu informatycznego lub procesu biznesowego istotnie zmniejszy ich złożoność.

Poniższy rysunek przedstawia model zmniejszania złożoności systemów informatycznych za pomocą partycjonowania.

Model zmniejszania złożoności architektury IT za pomocą partycjonowania.
Opracowanie własne.

Po lewej stronie rysunku widać cztery systemy A, B, C i D, połączone każdy z każdym. Każdy z nich ma (średnio) po 10 istotnych stanów kontrolowanych przez jego zmienne. W takim układzie analityk podczas analizy lub tester podczas testowania widzi i analizuje lub testuje na raz, jako jedną całość, układ 4 systemów o łącznej złożoności 10^4 = 10.000 stanów.

Aby zmniejszyć złożoność takiego układu, dzielimy go na dwie części w taki sposób, aby jeden system znalazł się dokładnie w jednej z części (partycji). I tak systemy A i B trafiają do partycji AB a systemy C i D trafiają do partycji CD. W celu zachowania zależności pomiędzy systemami wchodzącymi w skład obu partycji, partycja AB wystawia partycji CD usługi niezbędne do działania systemów C i D a partycja CD wystawia partycji AB usługi niezbędne do działania systemów A i B. Te dwa zbiory usług ukrywają wewnętrzną złożoność systemów je realizujących, więc można traktować je jako prostsze systemy. W przykładzie przyjęto, że złożoność takiego zbioru usług będzie również wynosiła 10 stanów - tak, jak dla każdego innego z systemów w całym układzie. Ale dla zbioru usług ukrywających złożoność realizujących je systemów można przyjąć dowolną inną liczbę stanów mniejszą od złożoności systemów ukrywanych pod tymi usługami.

W układzie podzielonym (po prawej stronie ww. rysunku) widać dwie partycje. Partycja AB jest zbudowana z systemów A i B oraz z zestawu usług świadczonych przez partycję CD i niezbędnych do działania systemów partycji AB. Partycja CD jest zbudowana z systemów C i D oraz z zestawu usług świadczonych przez partycję AB i niezbędnych do działania systemów partycji CD. W takim układzie analityk podczas analizy lub tester podczas testowania widzi i analizuje / testuje na raz, jako jedną całość, układ 2 systemów i jednego zestawu usług o łącznej złożoności 10^3 = 1.000 stanów. A ponieważ w układzie istnieją dwie takie części do analizy lub testowania, każda o złożoności 1.000 stanów, to całkowita złożoność takiego układu będzie wynosiła 1.000 + 1.000 = 2.000 stanów. W wyniku partycjonowania zmniejszyliśmy więc złożoność układu z o 80% - z 10.000 do 2.000 stanów.

Zakończenie

Widać, że podział zbioru systemów na części pozwala na istotne zmniejszenie złożoności całego układu. Dodatkowo, im więcej części wydzielimy, tym zmniejszenie złożoności będzie większe. W przedstawionym przykładzie partycjonowania systemów, wyjściowym układem był układ czterech systemów, które podzielono na 2 partycje. Ponieważ systemy były połączone każdy z każdym, to wybór systemów do poszczególnych partycji mógł być dowolny.

W rzeczywistości jednak takie sytuacje nie zdarzają się nigdy. Dlatego zasadniczym wyzwaniem przy partycjonowaniu systemów staje się wybór takiego sposobu ich podziału, który będzie uwzględniał faktyczne istniejące zależności pomiędzy tymi systemami (dokładniej: pomiędzy funkcjonalnościami tych systemów) i będzie generował maksymalną możliwą liczbę partycji o jak największej liczbie / sile zależności między funkcjonalnościami partycji oraz o jak najmniejszej liczbie / sile zależności między funkcjonalnościami różnych partycji. Wtedy złożoność interfejsów wystawianych przez jedną partycję i używanych w innych, będzie najmniejsza a tym samym złożoność samych partycji będzie najmniejsza a tym samym złożoność całego układu będzie najmniejsza.

Z pomocą w poszukiwaniu takiego sposobu podziału funkcjonalności pomiędzy systemy, aby złożoność całości była jak najmniejsza, przychodzi relacja równoważności. Ale o tym w następnym odcinku.

Bibliografia

• Partition of a set, http://en.wikipedia.org/wiki/Partition_of_a_set, [2012-07-13].
• Sessions R., A Better Path to Enterprise Architecture, marzec 2006, ObjectWatch, http://www.objectwatch.com/whitepapers/ABetterPath-Final.pdf, [2012-08-19].
• Sessions R., Simple Architectures for Complex Enterprises, 1 edycja kindle 2010, Microsoft Press.

Złożoność EA (4) - Business case zmniejszania złożoności architektury

Zgodnie z definicją CUEC (ang. Consortium for Untangling Enterprise Complexity): złożoność, to cecha systemu, która powoduje, że jest on trudny w użyciu, w zrozumieniu, w zarządzaniu i/lub trudny do implementacji.

Za estymator złożoności systemu (lub układu systemów) przyjęliśmy liczbę znaczących stanów, w których ten system może się znaleźć. Zmniejszanie złożoności polega więc na zmniejszaniu liczby tych stanów.

Liczba stanów estymuje nam liczbę testów, które trzeba przeprowadzić, estymuje ilość linii kodu, które zawiera program oraz estymuje ilość analizy, którą trzeba przeprowadzić, aby go zrozumieć. Innymi słowy liczba stanów wpływa na koszty rozwoju systemu. W jakim stopniu?

Sessions R. twierdzi, że zależność kosztów rozwoju i utrzymania systemu od jego złożoności jest liniowa. Niestety na poparcie tej tezy nie podaje przekonującego dowodu.

Wg Garnera usunięcie zbędnej złożoności zmniejsza TCO liczone na jednego użytkownika o ok. 50%. Badania nad złożonością w przedsiębiorstwach opublikowane przez MIT CISR podają, że blisko połowa złożoności w przedsiębiorstwie to "zła" złożoność (zła, tzn przynosi więcej trudności dla firmy niż wartości dla klienta). Zestawienie tych dwóch faktów pokrywa się z tezą Session'a.

Gdyby przyjąć, że zależność kosztów rozwoju i utrzymania systemu (biznesowego i/lub informatycznego) od jego złożoności, jest liniowa (przemawia za tym teza Sessions'a oraz badania Gartnera i MIT CISR), to zmniejszenie złożoności systemu o 85% (co jest możliwe - patrz poprzedni wpis nt. złożoności) powinno nam zmniejszyć koszty rozwoju o 85%! Gra jest zatem zdecydowanie warta świeczki!

Źródła:

• Mieritz L., Frameworks that Matter: Using TCO and TVO to Identify, Develop and Drive Business and IT Improvements, 2009, Gartner, s.10.
• Sessions R., A Fundamental Metric for Predicting IT Success, ObjectWatch, Inc., 2012, http://www.objectwatch.com/whitepapers/ComplexityMetricSessions-100.pdf, [2012-07-14].
• Mocker M., Ross J.W., Rethinking Business Complexity, MIT CISR Research Brefing, Volume XIII, Number 2, February 2013, http://cisr.mit.edu/blog/documents/2013_0201_RethinkingBusinessComplexity_MockerRoss.pdf, [2013-05-22].

Złożoność EA (3) - Zmniejszanie złożoności przez upraszczanie

W pierwszej części cyklu na temat złożoności w Architekturze Korporacyjnej przyjęliśmy, że estymatorem złożoności systemu / układu jest liczba stanów, w których może się on znaleźć. Zmniejszanie złożoności będzie więc polegało na zmniejszaniu liczby stanów systemu / układu systemów, których może się on znaleźć. Dzisiaj napiszę o pierwszym ze sposobów zmniejszania liczby stanów, jakim jest upraszczanie.

Upraszczanie

Poniższy rysunek przedstawia 4 systemy A, B, C i D połączone ze są każdy z każdym. Każdy z tych systemów może się znaleźć w jednym z 6 możliwych stanów, czyli każdy z systemów ma złożoność 6.

Wyjściowy układ 4-rech systemów o całkowitej złożoności 1.296 stanów

Ponieważ systemy są od siebie mocno zależne, to cały układ 4-rech systemów ma złożoność 6 * 6 * 6 * 6 = 1.296 stanów, w których może się znaleźć (dla lepszego wyobrażenia, w miejsce systemów możemy z powodzeniem wstawić kostki do gry).

Upraszczanie takiego układu polega na likwidacji stanów, w których może się on znaleźć. Zastosowanie metody upraszczania oznaczać może np. zmniejszenie liczby stanów wybranych lub wszystkich systemów (kostek) przedstawionego układu. Jeśli dla każdego z systemów zmniejszylibyśmy liczbę jego stanów z 6 do 5 (czyli zamiast kostek sześciościennych zastosowalibyśmy kostki pięciościenne), to układ wynikowych miałby już złożoność 5 *5 * 5 * 5 = 625, czyli o blisko 50% mniejszą od złożoności układu wyjściowego.

Układ uproszczony poprzez zmniejszenie liczby stanów każdego z systemów

Dla architektury korporacyjnej oznacza to, że usunięcie nawet małej liczby zbędnych funkcjonalności / kroków procesów istotnie zmniejszy złożoność architektury, jako całości. Dla przykładu: czy funkcja windykacji koniecznie musi wysyłać cokwartalne raporty? Jeśli nie - zrezygnujemy z nich. W efekcie uzyskamy istotne zmniejszenie złożoność procesów biznesowych i systemów informatycznych firmy, co przełoży się zmniejszenie kosztów ich utrzymania i rozwoju.

Inne zastosowanie metody upraszczania może polegać na usunięcie całego jednego systemu (kostki) z układu.

Układ uproszczony poprzez usunięcie jednego z systemów

W efekcie usunięcia jednego z systemów otrzymamy układ o złożoności 6 * 6 * 6 = 216 stanów, czyli uzyskamy blisko 85% zmniejszenie złożoności.

Przechodząc do architektury korporacyjnej – usuwając całe funkcje biznesowe osiągamy istotne zmniejszenie złożoności. Przykładami działań zmniejszających złożoność architektury korporacyjnej w ten sposób mogą być outsourcing lub konsolidacja (standaryzacja) funkcji przedsiębiorstwa.

Zakończenie

Za estymator złożoności systemu (lub układu systemów) przyjęliśmy liczbę znaczących stanów, w których ten system może się znaleźć. Zmniejszanie złożoności polega więc na zmniejszaniu liczby tych stanów. Jeśli chcemy zmniejszyć złożoność danego układu, to musimy zmniejszyć liczbę znaczących stanów układu np. zmniejszając liczbę funkcji realizowanych przez systemy, konsolidując redundatne funkcjonalności systemów czy zmniejszając liczbę punktów decyzyjnych w procesie  biznesowym.

Przedstawione metody upraszczania zmniejszające liczbę znaczących stanów układu systemów są oczywiste. Jednak to co jest istotne i nie jest takie oczywiste, to to, że nawet niewielkie zmniejszenie liczby stanów pojedynczego elementu układu systemów istotnie zmniejszam nam liczbę stanów całego układu. W pierwszym przykładzie ujęcie jednego z sześciu stanu ze wszystkich systemów zmniejszyło nam liczbę istotnych stanów układu (złożoność) o blisko 50%. W przykładzie drugim usunięcie jednego z 4-rech systemów (25% układu) zmniejszyło nam liczbę istotnych stanów układu (złożoność) o 85%.

Stosowanie przedstawionych sposobów zmniejszania złożoności przez upraszczanie jest ograniczone przez liczbę koniecznych stanów układu, które muszą istnieć, aby uzyskać wymagane efekty działania tego układu. Dalsze upraszczanie powodowałoby by utratę potencjału wymaganego do realizacji funkcji przedsiębiorstwa. Złożoność układu daje się jednak zmniejszać dalej, tylko innymi metodami. Napiszę o nich w następnym artykule.

Źródła

• Sessions R., Simple Architectures for Complex Enterprises, 1 edycja kindle 2010, Microsoft Press.
• Sessions R., A Fundamental Metric for Predicting IT Success, ObjectWatch, Inc., 2012, http://www.objectwatch.com/whitepapers/ComplexityMetricSessions-100.pdf, [2012-07-14].

Rodzaje strategii a architektura korporacyjna (2)

W poprzednim artykule na temat typów strategii opisałem koncepcję value disciplines opublikowaną przez Treacy i Wiersema w 1993 roku.  Treacy i Wiersema przebadali wtedy czterdzieści firm będących liderami w swoich branżach i wyróżnili 3 rodzaje stosowanych przez te firmy strategii dostarczania wartości klientom:

Strategia doskonałości operacyjnej (ang. operational excellence)
Służy dostarczaniu wartości typu najlepszy koszt całkowity (ang. best total cost), poszukiwanej przez klientów ceniących najlepszy stosunek ceny do jakości (niekoniecznie samą cenę) oraz łatwość dokonania transakcji i późniejszej obsługi. Strategia operational excellence polega na maksymalizacji efektywności (efektywność = stosunek uzyskiwanych wyników do ponoszonych kosztów) procesów wytwarzania i dostarczania produktów klientom firmy. Dzięki temu firmy stosujących te strategie wytwarzają produkty dobrej jakości i dostarczają je klientom w sposób tani dla firmy i bezproblemowy dla klientów. W tej strategii zysk pochodzi z każdej transakcji, więc głównym kryterium sukcesu strategii tego typu jest skala sprzedaży. Firmy stosujące strategie tego rodzaju oferują zatem niewielką liczbę produktów (różnorodność jest wrogiem efektywności), stosują małe marże (aby konkurować ceną) ale realizują dużą liczbę transakcji.

Strategia bliskich stosunków z klientami (ang. customer intimacy)
Służy dostarczaniu wartości typu najlepsze rozwiązanie całościowe (ang. best total solution) klientom szukającym rozwiązania najlepszego in total m.in. za cenę utraty części niezależności. Liderzy dostarczania wartości best total solution zarabiają na szerokości i długości relacji z klientem. Realizują to poprzez oferowanie im dopasowanych produktów w dopasowany sposób. Posiadają więc w ofercie szeroki zakres customizowanych produktów i muszą potrafić budować z nich dopasowane rozwiązania całościowych problemów klienta.

Strategia przywództwa produktowego (ang. product leadership)
Służy dostarczaniu wartości typu najlepszy produkt (ang. best product) skierowanej do klientów ceniących sobie produkty najlepsze z możliwych, najmodniejsze ale przez to przeważnie droższe. Źródłem sukcesu liderów tej strategii jest zwinność: szybkość w zidentyfikowaniu nowego wynalazku lub pomysłu, szybkość wytworzenia nowego produktu oraz szybkość i głośność wprowadzenia go na rynek.

Zdolności biznesowe dla różnych typów strategii

Wg Treacy i Wiersema liderzy muszą wybrać jeden rodzaj strategii i doskonalić się w jej realizacji aż zostaną mistrzami świata w dostarczaniu jednego rodzaju wartości. Wybrać, tzn. m.in. określić i doskonalić te zdolności biznesowe, które są kluczowe w dostarczaniu wybranego rodzaju wartości. Skoro firmy wybierające różne rodzaje strategii dostarczają różne rodzaje wartości, to nie trudno się domyślić, że dla każdej ze strategii inne zdolności biznesowe będą kluczowymi zdolnościami firmy:

Zdolności biznesowe w strategii operational excellence
W strategii operational excellence strategicznymi zdolnościami decydującymi o przewadze konkurencyjnej są efektywne, zestandaryzowane procesy produkcji i dostarczania oraz sprzedaży i obsługi. Nie da się ich jednak zbudować raz na zawsze, więc obok ww. procesów ważnymi umiejętnościami firmy będą umiejętność zarządzania tymi procesami oraz umiejętność ciągłego doskonalenia ich jakości i efektywności.

Zdolności biznesowe w strategii customer intimacy
W strategii typu customer intimacy źródłem zysku jest relacja z klientem. Strategicznymi zdolnościach takich firm będą więc: pozyskiwanie klientów posiadających potencjał na długą współpracę (jednorazowy klient to kiepski klient), gromadzenie szerokiej wiedzy o kliencie, rozwój relacji z klientem, customizowanie produktów i budowanie z nich dopasowanych rozwiązań. Doskonalenie polega tutaj na customizowaniu obsługi oraz pogłębianiu doświadczenia i wiedzy firmy (ekspertyzy) w dziedzinie rozwiązywanych problemów klientów.

Zdolności biznesowe w strategii product leadership
Wreszcie dla  firmy stosującej strategię typu product leadership strategicznymi zdolnościami będą pozyskiwanie nowych pomysłów i identyfikowanie okazji (również spoza firmy), szybka i głośna komercjalizacja produktu, praca nad rynkiem: edukacja, wydarzenia, programy early adopters, R&D (ang. research and devcelopment), innowacyjność (proces biznesowy), kreatywność oraz zarządzanie ryzykiem (każde nowe przedsięwzięcie jest obarczone wysokim ryzykiem). Doskonalenie jest uzyskiwane poprzez stosowanie nowoczesnych technologii oraz skracanie czasu R&D.

Zdolności IT dla różnych typów strategii

Skoro dla firm stosujących różne typy strategii różne zdolności biznesowe mają znaczenie strategiczne (tzn. firma musi je umieć robić lepiej od konkurentów), to podobnie będzie z technologiami informatycznymi używanymi do wspierania tych zdolności. Dla firm stosujących różne typy strategii różne technologie informatyczne będą miały znaczenie strategiczne. Zanim jednak przejdę do opisywania różnic w stosowaniu IT w poszczególnych typach strategii, poklasyfikujemy sobie same technologie. B.Ballengee proponuje taką oto ciekawą klasyfikację:

gdzie:

• IT core'owe, to: CRM, ERP, Manufacturing Execution Systems (MES), Warehouse Management Systems (WMS), Human Resource Information System (HRIS)

• IT brzegowe dzieli się na 4 rodzaje:
  - visibility: portale dla pracowników, klientów, dostawców …
  - semantic integrity: integracje wewnątrz i między-firmowe EAI,FTP, SOA, web services,
  - analytics: data marts, database marketing
  - reach: wireless field sales and service, customer alerts

IT w firmach doskonałych operacyjnie
W firmach stosujących strategie typu operational excellence, głównym zadaniem IT będzie wspieranie procesów biznesowych - stosowane technologie informatyczne decydują o ich efektywności i niezawodności. Największą wartość strategiczna będzie wiec miało IT core'owe (ogolnofirmowe): wysokowolumenowe, niskokosztowe systemy transakcyjne i zestandaryzowane aplikacje (wszelka różnorodność jest wrogiem efektywności).

Przy budowie architektury IT takich firm znajdą zastosowanie rozwiązania best of breed, czyli integrowanie produktów typu COTS (ang. commercial of the shelf - produkty z półki) pochodzących od różnych dostawców lub best of suite, czyli preintegrowane zestawy COTS’ów pochodzących od jednego dostawcy. Stosowanych systemów COTS się nie customizuje, tylko dopasowuje się do nich procesy biznesowe firmy. W takich firmach zastosowanie znajdą również rozwiązania cloud'owe typu SaaS (ang. software as a service) zapewniając dostęp do procesów biznesowych światowej klasy.

Strategicznymi zadaniami stojącym przez nadzorem IT w takich firmach (którego elementem jest architektura korporacyjna) jest pilnowanie standardów, eliminowanie redundancji, maksymalizacja reużycia i finansowanie ogólnofirmowych zdolności IT.

IT w firmach o bliskich stosunkach z klientami
W firmach stosujących strategię customer intimacy głównym zadaniem technologii informatycznych będzie standaryzacja i dostęp danych o kliencie oraz integracja procesów biznesowych możliwa dzięki standaryzowaniu współdzielonych lub wymienianych danych. Największą wartość będą więc miały brzegowe technologie informatyczne stosowane i rozwijane blisko klienta, ale z zachowaniem ogólnofirmowych standardów technologicznych i standardów danych. Najważniejsze zdolności IT w takich firmach, to jeden widok klienta (ang. single view of customer), narzędzia do identyfikacji segmentów i potrzeb klientów, narzędzia do analizy wartości klienta i możliwości jej zwiększania (cross selling).

Patrząc na architekturą IT takich firm w centrum znajdziemy ogólnofirmowy system CRM do standaryzacji danych o klientach i integracji procesów a także standardowe platformy aplikacyjne i workflow’owe oraz rozwiązania cloud’owe typu PaaS (ang. platform as a service). Na brzegu, blisko klientów, aplikacje niestandardowe, często zmienne, rozwijane przez lokalne zespoły informatyków, ale koniecznie z zachowaniem standardów danych i technologicznych.

Strategicznymi zadaniami stojącym przez nadzorem IT w takich firmach (którego elementem jest architektura korporacyjna) będzie standaryzacja danych i wykorzystywanych technologii, właścicielstwo danych o kliencie, spójność w zarządzaniu i użyciu danych o klientach oraz decydowanie gdzie customizować, w jakim stopniu a gdzie nie.

IT u liderów produktowych
W firmach stosujących strategię product leadership głównymi zadaniami technologii informatycznych będzie wsparcie R&D oraz wsparcie współpracy pomiędzy ludźmi biorącymi udział w tych procesach. Więc strategiczną wartość będą miały np. narzędzia do modelowania i symulacji oraz systemy do współpracy.

Jeśli natomiast chodzi o architekturę IT: na brzegu znajdziemy aplikacje niestandardowe, pochodzące od dostawców niszowych, jak najbardziej zaawansowane natomiast standaryzacja ograniczy się do jedynie do usług infrastrukturalnych, więc zastosowania znajdą rozwiązania cloud’owe typu IaaS (ang. infrastructure as a service).

Nadzór IT w takich firmach będzie się zajmował głównie określaniem stopnia autonomii jednostek odpowiedzialnych za innowacje, decydowaniem co reużywać/standaryzować a co nie oraz decydowaniem co integrować (jaka standaryzacja danych jest potrzebna).

Podsumowanie podejść do zastosowań technologii informatycznych w przedsiębiorstwach realizujących różne typy strategii przedstawia poniższa tabela.

Zakończenie

Po 20 latach od powstania koncepcja Treacy & Wiersema klasyfikacji typów strategii biznesowych jest wciąż szeroko stosowana w literaturze biznesowej i akademickiej. Pomimo, że modele biznesowe i zastosowania technologii informatycznych znacznie się od tamtego czasu rozwinęły, to zaproponowany sposób myślenia wciąż znajduje zastosowanie.

Mnie koncepcja ta pozwala mi na lepsze zrozumienie strategii firmy, ułatwia mi identyfikowanie braków tej strategii, ukierunkowuje moje myślenie przy projektowaniu architektury strategicznej IT, pomaga w ocenie dopasowania i przy projektowaniu odpowiedniego nadzoru IT, pozwala zidentyfikować zdolności biznesowe i IT istotne strategiczne (które powinny być realizowane wewnątrz przedsiębiorstwa) i odróżnić je od zdolności wspierających (które można outsource’ować). Pozwala mi szybko ocenić, czy dany projekt, rozwiązanie jest zgodny ze strategią (typem strategii), czy jest neutralny, czy też wręcz degraduje potencjał istotny strategicznie.

Generalnie - koncepcja Treacy & Wiersema pozwala mi lepiej dopasowywać architekturę IT do długoterminowego sposobu działania firmy. Poprzez fokusowanie myślenia pozwala mi budować strategicznie dopasowaną (nie do strategii, ale do typu strategii) architekturę korporacyjną. O konkretnych zasadach fokusujących, czyli o pryncypiach architektonicznych, napiszę w następnym artykule.

Bibliografia

• Ballengee B., Enterprise Architecture: Time for IT to Break Out! [w:] Kappelman L. A. (ed), The SIM Guide to Enterprise Architecture,  Auerbach Publications, 2009.
• Treacy M., Wiersema F., Customer Intimacy and Other Value Disciplines, Harward Business Review, January-February, 1993, s.84-93.
•  Weill P., Ross J.W., IT Governance - How Top Performers Manage IT Decision Rights for Superior Results, HARVARD BUSINESS SCHOOL PRESS, MASSACHUSETTS, 2004.

Złożoność EA (2) - miary złożoności IT

Zgodnie z definicją CUEC (Consortium for Untangling Enterprise Complexity): złożoność, to cecha systemu, która powoduje, że jest on trudny w użyciu, w zrozumieniu, w zarządzaniu i/lub trudny do implementacji. Złożoność może więc dotyczyć różnych aspektów IT, np. złożoności implementacji systemu, złożoności komunikacji między ludzi w projekcie czy złożoności procesów biznesowych wspieranych przez system.

Jeśli budujemy prostą, jednostanowiskową aplikację do używania przez jednego użytkownika, wtedy prawdopodobnie nie będziemy potrzebować żadnego architekta. Jeśli jednak zamierzamy zbudować rozwiązanie o architekturze rozproszonej, używane w całej organizacji i wspierające krytyczne procesy firmy, wtedy najprawdopodobniej będziemy potrzebować architekta baz danych, architekta rozwiązań architekta infrastruktury, architekta biznesowego oraz architekta korporacyjnego.

W celu skutecznego zarządzania złożonością w IT niezbędny jest jakiś sposób jej zmierzenia. Istnieje wiele miar złożoności oprogramowania. Opierają się one głównie na badaniu struktury kodu źródłowego. W tym artykule przedstawiam dwie najbardziej znane miary złożoności oprogramowania: miarę złożoności cyklomatycznej oraz miarę złożoności Halstead'a. Jednak miary złożoności oprogramowania niestety nie nadają się do mierzenia złożoności architektury. Najczęściej cytowane w tym obszarze są wyniki prac Rogera Sessions, który zdefiniował miarę złożoności architektury IT, przedstawioną na końcu tego artykułu.

Miara złożoności cyklomatycznej

Miara złożoności cyklomatycznej oprogramowania została opracowana przez Thomasa J. McCabe’a w 1976 roku. Mierzy liczbę pełnych, niezależnych ścieżek, przez które można przejść w programie. Oryginalnie oblicza się ją przy użyciu grafu skierowanego reprezentującego przepływ sterowania w danym programie. Węzły tym grafie odpowiadają podstawowym blokom programu (niepodzielny ciąg instrukcji, jedno wejście, jedno wyjście, instrukcje wykonywane po kolei, bez skoków z i do wnętrza bloku) a skierowane krawędzie oznaczają skoki w przepływie sterowania. Dla danego grafu przepływu sterowania G, złożoność cyklomatyczna M jest zdefiniowana jako :
v(G) = E - N + 2P
gdzie:
E = liczba krawędzi w grafie
N = liczba węzłów w grafie
P = liczba oddzielnych podgrafów (połączonych komponentów mierzonego grafu)

Po uproszczeniach, złożoność cyklomatyczną CC dla danej funkcji lub metody lub całej klasy lub całego systemu złożonego z wielu takich elementów, można wyrazić następująco:
CC = d - e + 2
gdzie:
d = liczba węzłów decyzyjnych o charakterze binarnym
e = liczba wyjść z programu

Dla przykładu: jeśli program ma jedno wyjście, nie zawiera żadnej instrukcji if/else (lub innej sprawdzającej warunek) ani żadnej pętli, wtedy złożoność cyklomatyczna takiego programu będzie wynosiła 1, gdyż zawiera on tylko jedną ścieżkę przejścia. Jedna instrukcja if/else zwykle wprowadza dwie możliwe ścieżki - jedną, gdy badany warunek jest spełniony i drugą, gdy badany warunek nie jest spełniony. Złożoność cyklomatyczna programu z jednym wyjściem i jedną instrukcją if/else, nawet zawierającego wiele funkcji, będzie wynosiła 2.

Złożoność cyklomatyczna programu przekłada się na trudność jego zrozumienia, pracochłonność testowania, niezawodność, trudność utrzymania, itd . Jedną z metod zmniejszania zmniejszania złożoności cyklomatycznej jest partycjonowanie oprogramowania, czyli podział na moduły o wysokiej kohezji i słabych związkach z innymi modułami.

Miary złożoności Halstead'a

W 1977 roku Maurice Howard Halstead opracował kilka metryk oprogramowania na podstawie empirycznych doświadczeń. Jedną z nich jest miara złożoności, która określa trudność zrozumienia lub skłonność do występowania błędów. Wg Halstead'a, trudność (D) programu jest proporcjonalna do liczby unikalnych operatorów w programie. D jest również proporcjonalna do stosunku pomiędzy całkowitą liczbą wystąpień operandów, a liczbą operandów unikalnych. Zapis matematyczny :
D = (n1 / 2) * (N2 / n2)
gdzie:
n1 – liczba unikalnych (różnych) operatorów w programie
n2 – liczba unikalnych (różnych) operandów w programie
N1 – całkowita liczba wystąpień operatorów
N2 – całkowita liczba wystąpień operandów

Miara złożoności Halstead'a mówi, że jeśli te same operandy są używane w programie wielokrotnie, to błędy występują w nim częściej.

Złożoność architektury IT Sessions'a

Obie ww. miary zostały przewidziane jedynie do mierzenia złożoności oprogramowania, nie nadają się więc bezpośrednio do mierzenia złożoności architektury IT.
Na poziomie architektury IT można wyróżnić dwa aspekty złożoności: złożoność funkcjonalna i złożoność koordynacji .

Złożoność funkcjonalna
Weźmy system, które ma zaimplementowaną jedną funkcjonalność. Taki system będzie mniej złożony od systemu, który ma trzy funkcjonalności. A z kolei system z trzema funkcjonalnościami będzie mniej złożony od systemu, który ma ich dziewięć - patrz poniższy rysunek:

 

Błędne działanie systemu z jedną funkcją a będzie spowodowane błędem tylko w tej jednej funkcji a. Błędne działanie systemu z dwoma funkcjami a i b może być spowodowane błędem w funkcji a lub błędem w funkcji b lub błędem w obu funkcjach a i b. Błędne działanie systemu z trzema funkcjami a, b i c może być spowodowane błędem w: a, b, c, a+b, a+c, b+c, a+b+c.

Widać, że złożoność systemu C rośnie szybciej, niż ilość funkcjonalności F w tym systemie. W 1979 roku S. N. Woodfield przeprowadził eksperyment wykazujący empirycznie, że wzrost ilości funkcjonalności o 25% powoduje wzrost złożoności o 100%. Czyli dla funkcjonalności F=1 złożoność C wynosi 1 a dla funkcjonalności F=1.25 złożoność C wynosi 2. Ta obserwacja prowadzi do wzoru na złożoność będącą funkcją liczby N funkcjonalności systemu:
FC(N) = 10^(3.11 * log(N))

Po uproszczeniu:
FC(N) = N^3.11

Złożoność współdziałania
Złożoność danego systemu może rosnąć nie tylko z powodu wzrostu liczby funkcjonalności, ale również wraz ze wzrostu zależności tego systemu od innych systemów - patrz poniższy rysunek:

Te zależności, które składają się na złożoność danego systemu, to mogą być zarówno usługi innych systemów w sensie SOA jak i współdzielone dane, wywołania funkcji innych systemów, czy współdzielone transakcje. Każda taka zależność, to po pierwsze dodatkowa funkcjonalność w danym systemie a po drugie potencjalne źródło błędu, więc dodatkowy element do sprawdzenia podczas szukania przyczyny nie działania systemu czyli dodatkowe punkty złożoności danego systemu. Możemy więc przyjąć, że wzór na złożoność współdziałania CC wynikającą z M zależności danego systemu od innych będzie analogiczny do wzoru na złożoność wynikającą z liczby funkcjonalności :
CC(M) = M^3.11

Złożoność całkowita architektury IT
Złożoność danego systemu składa się ze złożoności wynikającej liczby funkcjonalności oraz ze złożoności wynikającej z liczby zależności danego systemu od innych. Przy założeniu, że te dwie złożoności są od siebie niezależne, wzór na całkowitą złożoność C systemu zawierającego N funkcjonalności oraz M zależności można wyrazić wzorem:
C(N, M) = N^3.11 + M^3.11

Systemy w złożonych architekturach przeważnie nie funkcjonują samodzielnie. Złożoność architektury A złożonej z X systemów będzie więc sumą złożoności poszczególnych systemów:
C(A) = SUMA( C(X) )

Zakończenie

Problem złożoności, wstępnie zidentyfikowany 25 lat temu, gdy architektura korporacyjna powstawała, dzisiaj dochodzi do punktu krytycznego. Złożoność i koszt systemów IT wzrosły wykładniczo a łatwość uzyskiwania realnej wartości z użycia tych systemów dramatycznie zmalała . Tymczasem architektura korporacyjna miała m.in. właśnie zaadresować problem rosnącej złożoności organizacji, łącznie z jej komponentami technologicznymi. Po to właśnie powstały metodologie zarządzania architekturą korporacyjną - aby zmniejszyć ryzyka i poprawić jakość efektów planowania i realizacji zmian w architekturze przedsiębiorstwa. Pomimo to żadna z dzisiejszych metodyk zarządzania architekturą korporacyjną nie definiuje, czym ta złożoność jest, jak ją można kontrolować ani jak sprawdzać, czy udało się ją zmniejszyć lub wyeliminować.

Zgodnie z zasadą, że nie da się zarządzać czymś, czego nie da się zmierzyć więc w celu poradzenia sobie ze złożonością w IT konieczny jest jakiś jej pomiar. W mniejszym artykule przedstawiłem dwie miary złożoności oprogramowania oraz jedną miarę złożoności architektury, ale jest zaledwie drobny wyimek z dostępnych metod, których istnieje około 100.

Złożoność kosztuje. Samo zmierzenie złożoności nie powoduje, że staje się ona mniejsza, ale pomaga w skupieniu się na tych działaniach, które ją zmniejszają. Metody radzenia sobie ze złożonością zastaną przedstawię w następnym artykule.

Źródła

• Standard Definitions of Common Terms, CUEC (Consortium for Untangling Enterprise Complexity), http://www.cuec.info/index.php/download_file/view/166/205/, [2013-04-27].
• McCabe T. J., A Complexity Measure, [w:] IEEE Transactions on Software Engineering, 1976, vol. 2, nr 4, s. 308-320, http://www.literateprogramming.com/mccabe.pdf, [2012-06-09].
• Halstead M. H., Elements of Software Science, Amsterdam 1977, Elsevier North-Holland, Inc.
• Sessions R., The Mathematics of IT Simplification, ObjectWatch, Inc., 2011-04-01, http://www.objectwatch.com/whitepapers/MathOfITSimplification-103.pdf, [2012-06-09].
• Sessions R., Simple Architectures for Complex Enterprises, 1 edycja kindle 2010, Microsoft Press.
• Watson A. H., McCabe T. J., Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric, Wrzesień 1996, NIST Special Publication 500-235, s. 16, http://www.mccabe.com/pdf/mccabe-nist235r.pdf, [2012-06-09].
• Woodfield S.N., An Experiment on Unit Increase in Problem Complexity, 1979, IEEE.