Rodzaje strategii a architektura korporacyjna (1)

W literaturze poświęconej architekturze korporacyjnej można znaleźć stwierdzenie, że w idealnej sytuacji architektura korporacyjna powinna wynikać ze strategii biznesowej oraz strategii informatyzacji a dopiero z niej powinny wynikać wszelkie realizowane projekty. Na pierwszy rzut oka takie podejście ma sens – wydaje się, że architektura korporacyjna będzie najlepsza wtedy, gdy (m.in.) będzie dobrze dopasowana do strategii.

Strategia biznesowa jednak dotyczy rynków, na których firma konkuruje, produktów, którymi chce konkurować, pozycji, jaką firma ma zdobyć, czy umiejętności, jakie ma doskonalić. Jednak co najważniejsze - strategia może ulegać zmianie w reakcji na posunięcia konkurentów czy w celu wykorzystania nowych możliwości (np. technologicznych).

Niektóre z tych zmian mogą być przez architekturę korporacyjną absorbowane bez większych problemów (nawet jeśli są drogie) a niektóre mogą powodować znaczne konsekwencje. Czym różnią się zmiany istotnie zmieniające architekturę korporacyjną od tych mających na nią mniejszy wpływ? Albo ogólniej – jaka architektura korporacyjna (w ujęciu atrybutowym) będzie dla firmy dobra a jaka nie? W odpowiedzi na to pytanie może nam pomóc określenie rodzaju strategii firmy (ang. value discipline).

Rodzaje strategii (ang. value disciplines)

Po raz pierwszy koncepcja ta została opublikowana w Harvard Business Review przez Treacy i Wiersema w artykule Customer Intimacy and Other Value Disciplines. Później została opisana dokładniej w książce z roku 1995 pt. The Discipline of Market Leaders. Model value disciplines pomaga określić, w jaki sposób firma chce dostarczać swoim klientom wartości, za którą Ci klienci będą płacić. W polskiej literaturze poszczególne value disciplines są nazywane rodzajami strategii. Są to:

• doskonałość operacyjna (ang. operational excellence) – efektywność procesów
• bliskie stosunki z klientami (ang. customer intimacy) – fokus na klienta i jego potrzeby
• przywództwo produktowe (bądź usługowe) (ang. product leadership) – fokus na produkty

U podstaw ww. koncepcji leży obserwacja, że klienci nie kupują produktów lecz wartość będącą sumą ponoszonych przez nich kosztów i uzyskiwanych dzięki nim korzyści. Zakres ponoszonych kosztów i uzyskiwanych korzyści przedstawia poglądowo poniższy rysunek.

Koszty i korzyści klienta

Treacy i Wiersema zidentyfikowali następujące rodzaje wartości kupowanych przez klientów:

• najlepszy koszt całkowity (ang. best total cost) - wartość dla klientów ceniących najlepszy stosunek ceny do jakości (niekoniecznie cenę) oraz łatwość dokonania transakcji i późniejszej obsługi
• najlepsze rozwiązanie całościowe (ang. best total solution) - dla klientów szukających rozwiązania najlepszego in total m.in. za cenę utraty części niezależności - rozwiązania poprawiającego ich performance
• najlepszy produkt (ang. best product) - wartość dla klientów ceniących produkty najlepsze, najmodniejsze, przeważnie droższe

Poniższy rysunek podsumowuje rodzaje wartości oraz charakterystykę klientów je wybierających. Przy czym należy pamiętać, że dany klient może wybierać różne rodzaje wartości w różnych dziedzinach swojego życia i pracy: np. stereotypowy informatyk w dziedzinie elektroniki mógłby cenić wartość best  product a w dziedzinie ubiorów – best total cost :-)

Rodzaje wartości kupowane przez klientów

Treacy, Wiersema w swoich pracach stawiają tezę, że jeśli firma chce zostać liderem, to musi wybrać i zostać „mistrzem świata” w dostarczaniu jednego rodzaju wartości zachowując przy tym minimalną konieczną efektywność w dostarczaniu pozostałych dwóch. Wytwarzaniu ww. rodzajów wartości służą właśnie wspomniane rodzaje strategii:

• wartość best total cost - do dostarczania tego rodzaju wartości służy strategia typu doskonałość operacyjna
• wartość best total solution - do dostarczania tego rodzaju wartości służy strategia typu bliskie stosunki z klientami
• wartość best product - do dostarczania tego rodzaju wartości służy strategia typu przywództwo produktowe

Doskonałość operacyjna (ang. operational excellence)

Firma stosująca ten rodzaj strategii dostarcza wszystkim swoim klientom niewielką liczbę produktów po konkurencyjnych cenach i w sposób dla tych klientów jak najłatwiejszy. W strategiach tego rodzaju najważniejsza jest skuteczność i niezawodność procesów realizowanych na wielką skalę oraz łatwość dokonania transakcji. Źródłem zysku jest tutaj przychód/strata z każdej transakcji, niekoniecznie z tymi samymi klientami.

Dla klienta szukającego wartości best total cost liczy się nie tylko koszt produktu ale też koszt/łatwość dokonania jednorazowej transakcji (klient tego rodzaju nie szuka długoterminowej relacji). Dlatego firmy realizujące strategie typu operational excellence przede wszystkim minimalizują koszty ogólne i usprawniają procesy dostarczania i obsługi klientów, np. starają się usprawniać łańcuch dostaw usuwając zeń maksymalną liczbę kroków pośrednich. Czyli zamiast koncentrować się na produkcie, czy na kliencie, firma koncentruje się na optymalizacji swoich kluczowych procesów.

Wg badań MIT CISR z firmy stosujące strategie typu operational excellence osiągają większy zwrot z posiadanego majątku (ROA – return on asset).

Przykłady firm: Dell, Wal-Mart, UPS, MeadWestvaco, BIC Graphic Europe, ING Direct.

Bliskie stosunki z klientami (ang. customer intimacy)

Firmy stosujące ten rodzaj strategii skupiają się na przede wszystkim eksploatacji relacji z poszczególnymi klientami w ciągu całego okresu trwania tej relacji. Oferują wszystkie swoje produkty wybranym przez siebie klientom. Zysk/strata wynika tutaj nie z pojedynczej transakcji, ale ze wszystkich transakcji z jednym klientem – liczy się zysk/strata z szerokości (liczba różnych produktów sprzedana klientowi, np. TV, telefon stacjonarny, internet), głębokości (liczba produktów tego samego rodzaju sprzedana klientowi, np. liczba kart SIM) i czasu trwania relacji (im dłużej, tym lepiej). Dlatego takie firmy koncentrują się na budowaniu relacji z pojedynczym klientem poprzez jak największą responsywność i zwinność w odpowiadaniu na prawie wszystkie jego potrzeby, w tym potrzeby dobrej obsługi w relacji 1 do 1, wsparcia po sprzedaży i informacji dodatkowych.

Klienci się od siebie różnią, więc firmy budujące przewagę konkurencyjną wg tego modelu dzielą rynek na wąskie fragmenty a następnie w podobny sposób dywersyfikują i dopasowują doń swoją ofertę, merchandising/marketing, reklamę oraz procesy operacyjne tak, aby dokładnie odpowiadały potrzebom danej grupy klientów.

Aby tak działać, firmy muszą posiadać głęboką wiedzę o różnych klientach i ich różnych potrzebach oraz posiadać zdolność do szybkiego dopasowywania swoich produktów, procesów oraz reklamy i marketingu do oczekiwań różnych klientów. Dzięki temu uzyskują długoterminową lojalność swoich klientów, która jest podstawą zyskowności w tym rodzaju strategii.

Wg Treacy i Wiersema ten typ strategii jest drogi, ale pozwala firmie uzyskać większą zyskowność. Jednak badania MIT CISR nie potwierdzają tej tezy. Stwierdzają, że w strategiach typu customer intimacy firmy uzyskują mniejszą marżę.

Przykłady firm: Nordstrom, IBM w swoich najlepszych czasach, Home Depot, Federal Express, USAA, Capital One, Panalpina.

Przywództwo produktowe (bądź usługowe) (ang. product leadership)

Przywództwo produktowe (bądź usługowe) oznacza po pierwsze skupienie się na ciągłym, innowacyjnym  rozwoju produktów (wieczny eksperyment), po drugie na zbudowaniu zdolności do maksymalnie szybkiej komercjalizacji nowego produktu a po trzecie na konsekwentnym powodowaniu, że produkty poprzedniej generacji (zarówno konkurentów jak i swoje!) stają się przestarzałe lub niemodne. Liderzy produktowi są swoimi największymi konkurentami.

Centrum działalności liderów produktowych nie jest cena, czy klient, ale produkt. Dlatego firmy realizujące taką strategię decentralizują swoją działalność i skupiają ją przede wszystkim na ciągłym wymyślaniu i usprawnianiu nowych produktów, na maksymalnie szybkiej komercjalizacji, której wynikiem organizowanie działalności operacyjnej wokół linii produktowych. Liderzy produktowi tworzą w swoich firmach atmosferę zachęcającą pracowników do przynoszenia pomysłów do firmy i co więcej – słuchają tych pomysłów i je wykorzystują. Takie firmy unikają biurokracji, gdyż spowalnia ona komercjalizację nowych rozwiązań.

Wg badań MIT CIST firmy stosujące strategie typu product leadership uzyskują większą kapitalizację i wzrost przychodu, za to osiągają mniejszy zwrot z inwestycji (ROI) i mniejszy zwrot z majątku (ROA).

Przykłady firm: Apple, Ferrari, Nike, BMW a ostatnio Samsung.

Podsumowanie cech poszczególnych typów strategii przedstawia poniższa tabela.

Ile typów strategii firma może realizować na raz?

W literaturze akademickiej można znaleźć wiele zapisów stwierdzających, że w celu osiągnięcia sukcesu firmy powinny fokusować swoje strategie i działania na tym aspekcie działalności, dzięki któremu chcę osiągnąć przewagę konkurencyjną. Wg Portera skupienie pomaga firmom tworzyć unikalne połączenie wartości, która sprawia, że różnią się od swoich konkurentów (1979). Twierdzi on, że całą istotą strategii jest zarówno wybór tego co należy robić, jak również decyzja, czego robić nie należy (1996). Im więcej dana organizacja ma dyscypliny w fokusowaniu swojej działalności, tym więcej będzie miała możliwości wzrostu (Collins, 2001).

Tracey i Wiersema również twierdzą, że aby firma mogła konkurować na rynku z innymi przedsiębiorstwami, musi wykazywać się wystarczającą efektywnością we wszystkich trzech rodzajach strategii na raz. Jednak aby być liderem, firma musi się doskonalić dokładniej w jednej z nich zachowując minimalną konieczną efektywność w pozostałych dwóch (istnieją firmy, które stały się mistrzami dwóch, ale to są wyjątki).

Brak wyboru jednego z typu strategii powoduje, że powstają bardziej złożone modele biznesowe będące hybrydą wszystkich trzech typów strategii, które kosztują więcej, mają więcej wewnętrznych konfliktów i w żadnej dziedzinie nie są liderem. Porterowe stuck in the middle.

Wymiary przewagi konkurencyjnej

Tak więc firma, która chce być liderem, musi się doskonalić w jednej z wymienionych dziedzin. Doskonalić, tzn. wciąż polepszać dopasowanie modelu działania (kulturę, procesy, systemy) do tego jednego, wybranego typu strategii. Tzn. dokonywać trudnych wyborów, np.:

• sprzymierzyć się z konkurentem w celu obniżenia kosztów (operational excellence)
• oferować usługę ze stratą ale z nadzieją na długą relację (customer intimacy)
• kanibalizować własne, starsze produkty za pomocą nowych - konkurować z samym sobą (product leadership)

Treacy i Wiersema stawiają też tezę, że firmy chcę być najlepsze we wszystkim nigdy nie będą liderami. Powody: nikt nie może być najlepszy we wszystkim, bo każdy z rodzajów strategii wymaga innych, sprzecznych ze sobą zasad postępowania, zarządzania, nadzoru. Wymaga innego wsparcia IT, kultury, struktur organizacyjnych – generalnie innych umiejętności (business capabilities). Np. firma sfokusowana na strategiach typu operational excellence powinna mieć małą liczbę, prostych produktów w niskich cenach oraz łatwy dla klienta sposób zawarcia pojedynczej transakcji. Z kolei firma realizująca strategię typu customer intimacy będzie raczej dążyła do posiadania szerokiego wachlarza, customizowanych produktów, adresowanych do różnych grup klientów, czasami w różny sposób i oprócz łatwości pierwszego zakupu zaoferuje swoim klientom dokupowanie lub upgrade’owanie zakupionych produktów później, dzięki czemu w sumie będzie dla niego taniej, niż gdyby kupował poszczególne produkty oddzielnie.

Poniższy rysunek przestawia typ strategii lidera doskonałości operacyjnej.

Strategia typu doskonałość operacyjna

Rodzaje strategii a architektura korporacyjna

Firmy o podobnych typach strategii pracują w podobny sposób. Wyobrażam sobie, że pracownik firmy Apple po przejściu do firmy Nike (product leadership) lub BMW (również product leadership) na podobne stanowisko pracy, bardzo szybko odnalazłby się w nowej sytuacji pomimo, że produkty tych firm są całkowicie inne. Z kolei firmy posiadające różne typy strategii będą działać w różny sposób. Pracownik zmieniwszy pracę z BMW (product leadership) na Toyota (kilka lat temu operational excellence) poczułby, że trafił do całkiem innego świata pomimo, że obie firmy robią samochody.

Co to oznacza dla architektury korporacyjnej? Co wynika z tego, że firmy działają inaczej w zależności od typu strategii, który realizują? Oznacza to, że w zależności od typu tej strategii firmy budują różne zdolności (ang. capabilities) tudzież takie same zdolności rozwijają w różny sposób lub w różnym stopniu. Jeśli firma realizuje strategie typu operational excellence, to architektura korporacyjna takiej firmy będzie bardziej zestandaryzowana, zunifikowana. Jeśli firma realizuje strategię typu customer intimacy, to można się spodziewać, że swoje kluczowe zdolności będzie organizować wokół grup klientów. Wreszcie jeśli firma realizuje strategię typu product leadership, to swoje kluczowe zdolności będzie organizować wokół produktów.

Podsumowując: sądzę, że architektura korporacyjna powinna przede wszystkim uchwycić to, co w firmie niezmienne, dając strategiom ramy, w których powinny się poruszać. A to co niezmienne wynika właśnie z typu realizowanej strategii. Architekci korporacyjni powinni więc dopasowywać architekturę korporacyjną swojej firmy bardziej do typu realizowanej strategii a mniej skupiać się na jej dopasowywaniu do aktualnej strategii. Dzięki temu unikną tworzenia skomplikowanych planów dla nietrwałych strategii.

To typ strategii powinien determinować zdolności, które firma powinna posiadać i ciągle doskonalić, aby stać się liderem w swojej branży. To typ strategii powinien determinować jej architekturę korporacyjną. Jak – o tym w następnym artykule.

Źródła:

• J.C. Collins, Good to Great: Why Some Companies Make the Leap... and Others Don't, HarperCollins Publishers Inc., 2001.
• M.Treacy, F.Wiersema, Customer Intimacy and Other Value Disciplines, Harward Business Review, January-February 1993, s. 84-93. 
• M.E. Porter, How Competitive Forces Shape Strategy, Harvard Business Review; March/April 1979, s.137-145.
• M.E. Porter, What is Strategy, Harvard Business Review, November/December 1996, s.61-78.

IMPAKT 2013-03 – Enterprise Architecture defined!

W ramach Katedry Informatyki Gospodarczej SGH został uruchomiony cykl konwersatoriów dotyczących architektury korporacyjnej IMPAKT  – „Interdyscyplinarne i metodyczne problemy architektury korporacyjne”. Zgodnie z informacją na stronach portalu architekturakorporacyjna.pl, tematyką spotkań mają być szeroko rozumiane zagadnienia architektury korporacyjnej dot. jej kontekstu, zastosowań czy stosowanych metod. Spotkania mają odbywać się na terenie kampusu SGH.

5 marca 2013 odbyło się pierwsze konwersatorium z cyklu IMPAKT, w którym miałem przyjemność uczestniczyć. Spotkanie było poświęcone jakości architektury korporacyjnej: „Czym jest jakość architektury korporacyjnej i jak ją oceniać”. Poprowadził je Prof. SGH, dr hab. Andrzej Sobczak.

Formuła spotkania polegała na wykładzie prowadzonym przez Prof. Sobczaka, z możliwością przerywania, wyrażania opinii na przedstawiane tematy oraz zadawania pytań. Odpowiedzi udzielał Prof. Sobczak i/lub uczestnicy spotkania. Bardzo ważną zasadą (pryncypium :-) spotkania było to, że „nie zawsze musimy mieć takie same poglądy i nie zawsze musimy się zgadzać”. To umożliwiało pozostawienie danego tematu jako nierozwiązanego.

Prof. Sobczak postawił podczas spotkania tezę, że korzyścią z posiadania dobrej jakości architektury korporacyjnej (w ujęciu atrybutowym, czyli dot. cech samej organizacji, która daną architekturę posiada) jest potencjał biznesowy, czyli „zdolność do realizacji wiązki celów strategicznych lub do długoterminowego dostarczania wartości dla interesariuszy”. Stwierdził również, że poszczególne cechy architektury są od siebie zależne nieliniowo a optymalna jakość architektury korporacyjnej, to taki układ złożoności, elastyczności i spójności, przy którym potencjał biznesowy jest największy przy zadanych ograniczeniach.

---

Bardzo spodobało mi się postawienie przed architekturą korporacyjną jednego jasnego i prostego celu, jakim jest maksymalizacja potencjału biznesowego. W literaturze przedmiotu można spotkać bardzo dużo definicji, czym architektura korporacyjna jest. Na forach można również spotkać wiele gorących dyskusji na ten temat, przy czym konsensusu raczej brak. Zdefiniowanie architektury korporacyjnej przez jej przeznaczenie te dyskusje znakomicie ucina. Jeśli dwie osoby zgadzają się co do celu architektury, nie muszą już się spierać, co do jej definicji. Podczas dalszej pracy można się już wtedy tylko zastanawiać, jak ten cel osiągać.

W literaturze przedmiotu spotkałem się już z podejściem zdefiniowania architektury korporacyjnej przez jej cel. W książce recrEAtion Chris Potts określa cel architektury korporacyjnej jako „Enhancing Enterprise Performance With Structural Innovations”, gdzie Enterprise Performance miałoby być mierzone przychodem na jeden dolar kosztu operacyjnego oraz zysk na jedną, zakończoną transakcję. Jednak określenie celu architektury korporacyjnej jako Enhancing Enterprise Performance ogranicza ją jedynie do ciągłej optymalizacji działania przedsiębiorstwa, co na pewno leży w jej zakresie, ale nie wyczerpuje zadań przed nią stawianych. Dlatego zdecydowanie bardziej podoba mi się pojemniejsze pojęcie zwiększania potencjału biznesowego.

Z wartością takiego celu dla przedsiębiorstwa też trudno się nie zgodzić, co może znakomicie ułatwić rozmowy z Biznesem. Czy chcesz, aby firma zwiększała swój potencjał biznesowy? Ależ oczywiście. Czy wiemy, jak to robić? Wiemy - za pomocą architektury korporacyjnej.

Potencjał biznesowy kojarzy mi się również z czymś uzyskiwanym nie za darmo (jak energia potencjalna przedmiotu lub energia elektryczna w ogniwie) i z czymś, z czego można korzystać długo i wielokrotnie w przyszłości (a nie w jednym projekcie o określonym NPV). Budowanie potencjału oddaje znakomicie charakter działalności architektonicznej: pracujemy teraz ale pracujemy na przyszłość.

Zdefiniowanie architektury korporacyjnej poprzez postawienie celu, któremu służy, przypomniało mi jeszcze jedną rzecz. Pamiętamy jeszcze trylogię Matrix? W Matrix Reloaded, w jednej z końcowych scen, Agent Smith mówi do Neo: „There's no escaping reason, no denying purpose, because as we both know, without purpose, we would not exist.”. Definiując cel architektury korporacyjnej znakomicie uzasadniamy jej istnienie nawet bez dokładnego definiowania, czym ona jest.

Prawo Conway’a

W 1968 Melvin Conway, wtedy programista, postawił następującą tezę: „...organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations.”. W wolnym tłumaczeniu: organizacje które projektują systemy, budują rozwiązania, które są kopiami struktur komunikacyjnych tych organizacji. Albo inaczej – architektura budowanego rozwiązania będzie izomorficzna do struktury zespołu projektowego. Prawo to jest oparte na obserwacji, że – aby dwa moduły mogły się ze sobą komunikować to – ich projektanci i programiści muszą się ze sobą skomunikować. Dlatego struktura interfejsów systemu będzie odpowiadała strukturze komunikacji pomiędzy ludźmi, którzy te interfejsy projektują i implementują.

Przykłady

Załóżmy, że firma chce zbudować duży system S. Firma zatrudnia dostawcę X, aby jej ten system zbudował. Załóżmy, że dostawca X posiada 3 zespoły inżynierów E1, E2 i E3, która biorą udział w projekcie. Prawo Conway’a sugeruje, że zbudowane rozwiązanie będzie się składało z trzech podsystemów, każdy zbudowany przez jeden zespół inżynierów. A co istotniejsze, zbudowane interfejsy pomiędzy podsystemami (S1-S2, S1-S3, itd.) będą odzwierciedlać jakość i charakter komunikacji pomiędzy poszczególnymi grupami inżynierów.

Inny przykład: rozważmy dwu-osobowy zespół inżynierów IT, A i B. Powiedzmy, że A zaprojektował i zakodował klasę X. Później zespół odkrywa, że klasa X potrzebuje nowych funkcji. Jeśli nowe funkcjonalności będzie projektował i implementował inżynier A, to A najprawdopodobniej rozszerzy klasę X o te funkcje. Jeśli natomiast nowe funkcje będzie dodawał inżynier B, to B może się obawiać, że coś w klasie X zepsuje, więc zamiast zmieniać klasę X, utworzy nową klasę pochodną X2, w której B umieści nowe funkcje i która odziedziczy funkcje klasy X. W tym przykładzie ostateczny projekt zależy od tego, kto projektuje i implementuje rozwiązanie.

Wnioski

Wnioski wynikające z prawa Conway’a można zastosować w praktyce. Np. jeśli struktura organizacji projektu nie odzwierciedla ściśle architektury budowanego rozwiązania albo jeśli relacje pomiędzy elementami budowanego rozwiązania nie odzwierciedlają ściśle relacji pomiędzy częściami rozwiązania, to projekt najprawdopodobniej znajdzie się w kłopotach. Wniosek: w każdym projekcie należy się upewnić, że organizacja projektu jest kompatybilna / izomorficzna do architektury budowanego rozwiązania. Przykład z życia: Orbiter NASA Mars Climate rozbił się, że ponieważ jeden zespół (z USA) wykorzystywał swoje jednostki miary (np., cale, stopy i funty), podczas gdy innych zespół (z Europy) stosował jednostki metryczne.

Prawo Conway’a doczekało się różnych wersji. Jedną z bardziej znanych jest wersja Eric S Raymond’a, propagatora open source’u, współzałożyciela Open Source Initiative. Raymond powiedział, że organizacja oprogramowania i organizacja zespołu programistów będą przystające. Dla przykładu: jeśli masz cztery zespoły pracujące nad kompilatorem, otrzymasz kompilator 4-ro przebiegowy.

Podsumowanie

Z prawa Conway’a wynika, że struktura zespołu projektowego wpływa na architekturę rozwiązania. W organizacji tightly-coupled (np. wyspecjalizowane zespoły zatrudnione przez jedno przedsiębiorstwo, znajdujące się w jednym miejscu realizują projekt) problemy są rozwiązywane przez interakcje face-to-face. Deweloperzy jednego modułu mają informację o konstrukcji innych modułów. Teraz, nawet jeśli nie jest to wyraźna decyzja projektowa, to moduły stają się wyraźne bardziej tightly-coupled. W organizacji loosely-copled (np. zespoły realizujące projekt są rozproszone) komunikacja face-to-face jest rzadka. Większość programistów nigdy się nie spotyka. Ograniczenia w komunikacji pomiędzy deweloperami dają w efekcie mniej połączeń pomiędzy modułami a architektura rozwiązania jest bardziej modularna.

Jeśli zależy nam na takiej lub innej architekturze danego rozwiązania lub całego środowiska, wtedy przede wszystkim należy skonstruować izomorficzną do tej architektury organizację pracy w zespołach projektujących i implementujących rozwiązanie. Wtedy (najprawdopodobniej) osiągniemy zamierzony rezultat architektoniczny. Innymi słowy możemy wpływać na projektowaną architekturę poprzez konstruowanie struktury organizacyjnej projektującego ją zespołu/zespołów.

Należy jeszcze dodatkowo pamiętać, że architektura rozwiązania powstaje na początku projektu a później może się zmienić. Prawo Conway’a mówi nam, że w takiej sytuacji powinniśmy również zmienić strukturę organizacji projektu.

Źródła:

• M.E. Conway, How do Committees Invent?, 1969, http://www.melconway.com/research/committees.html
• A. MacCormack, J. Rusnak, C. Baldwin, Exploring the Duality between Product and Organizational Architectures: A Test of the ‘Mirroring’ Hypothesis, 2007, http://www.hbs.edu/research/pdf/08-039.pdf
• N. Nagappan, B. Murphy, V. Basili, The Influence of Organizational Structure On Software Quality: An Empirical Case Study, 2008, http://research.microsoft.com/pubs/70535/tr-2008-11.pdf

Poziomy dojrzałości architektury korporacyjnej

Wg badań MIT CISR (http://cisr.mit.edu/), każde przedsiębiorstwo informatyzujące swoje procesy biznesowe i chcące coraz lepiej obsługiwać klientów oraz obniżać koszty IT, przechodzi przez cztery poziomy dojrzałości architektonicznej. Poziomy tej dojrzałości zostały zidentyfikowane na podstawie wzorców inwestycyjnych oraz praktyk zarządczych różnych na każdym z czterech poziomów.

Wg ww. badań firmy osiągające wyższy poziom dojrzałości architektury korporacyjnej raportowały niższe koszty IT, krótsze czasy rozwoju systemów IT, wyższą dyscyplinę procesów biznesowych i więcej korzyści strategicznych osiąganych dzięki IT. Te cztery poziomy dojrzałości architektury korporacyjnej, to:

1. Architektura Silosów Biznesowych: firma dba o optymalizację zaspokojenia potrzeb poszczególnych jednostek biznesowych.
2. Architektura Standaryzacji Technologii: zapewnia skuteczność IT poprzez standaryzację i centralizację zarządzania wykorzystywanymi technologiami.
3. Architektura Optymalizacji Działalności Podstawowej: zapewnia dopasowaną do modelu operacyjnego standaryzację procesów i systemów w firmie.
4. Architektura Modularności Biznesu: firma posiada i może na różne sposoby wykorzystywać luźno ze sobą powiązane komponenty procesów biznesowych, które istnieją dzięki IT. W ten sposób firma stosuje globalne standardy a jednocześnie może uwzględniać lokalne różnice.

Poziom 1: Architektura Silosów Biznesowych

Na tym poziomie inwestycje w IT są realizowane w celu rozwiązywania problemów i wspieraniu działań definiowanych lokalnie. Nie są stosowane standardy technologiczne ani nie powstają systemy ogólnofirmowe. Architektura Silosów Biznesowych nie narzuca ani działalności gospodarczej, ani rozwojowi IT, żadnych ograniczeń, więc budowane na tym poziomie aplikacje są bardzo dobrze dopasowane do lokalnych potrzeb jednostek biznesowych. Na tym poziomie uzasadnieniem inwestycji w IT jest głównie redukcja kosztów operacyjnych przedsiębiorstwa, które są przewidywalne i łatwo mierzalne.

Jednak takie „jedyne w swoim rodzaju„ aplikacje często powielają swoje funkcjonalności i nie potrafią ze sobą współpracować. A jeśli muszą - buduje się integracje punkt-punkt. Skutki takiego podejścia łatwo przewidzieć – po pewnym czasie powstaje spaghetti integracyjne i wprowadzenie nawet najdrobniejszej zmiany staje się kosztowne i czasochłonne.

Na tym poziomie dojrzałości architektury korporacyjnej redukcja kosztów jest ważniejsza niż frustracja powodowaną niekompatybilnością systemów i technologii. Jednak z czasem potrzeba zmniejszania kosztów i wydajności technologii IT zmusza firmę do przejścia na poziom Architektury Standaryzacji Technologii.

Poziom 2: Architektura Standaryzacji Technologii

Na tym poziomie firmy przyjmują standardy technologiczne, aby ograniczać liczbę platform, którymi dysponują. Ale mniej platform i konieczność zachowania standardów, to mniejsze pole manewru przy budowie rozwiązań informatycznych. Zmienia się podejście do realizacji wymagań: zamiast najpierw określać rozwiązanie a później szukać technologii, firma próbuje wypracować najlepsze rozwiązanie w ramach posiadanych platform technologicznych.

Zatem standaryzacja technologii ogranicza elastyczność, ale prowadzi do redukcji ryzyka, poprawy obsługi użytkowników w zakresie wsparcia, konserwacji i zaopatrzenia, poprawia bezpieczeństwo i niezawodność technologii. To wszystko obniża nakłady na zakup i utrzymanie infrastruktury IT w przedsiębiorstwie.

Standaryzacja technologii nie rozwiązuje jednak wywodzącego się z poziomu Architektury Silosów Biznesowych problemu niekompatybilności i rozproszenia danych osadzonych w różnych aplikacjach. Dalszy rozwój działalności gospodarczej wymusza na przedsiębiorstwach znajdujących się na tym poziomie ewolucję w kierunku poziomu Optymalizacji Działalności Podstawowej, na którym praktyki standaryzacji zaczynają obejmować również ogólnofirmowe dane i procesy biznesowe.

Poziom 3: Optymalizacja Działalności Podstawowej

Na tym poziomie firmy starają się integrować systemy tak, aby wspierały procesy end-2-end, wydobywają dane z systemów lokalnych i udostępniają je stosownym procesom, eliminują redundancję w danych i funkcjonalnościach, wdrażają systemy zintegrowane klasy ERP. Inwestycje w IT są więc czynione nie z myślą o lokalnych aplikacjach i współdzielonej infrastrukturze, lecz o ogólnofirmowych systemach i współdzielonych danych.

Firmy na tym poziomie pracują nad komputeryzacją swoich podstawowych procesów biznesowych. Powoduje to, że zmiana tych procesów lub struktury danych sprawia więcej trudności, ale dzięki reużyciu danych i procesów opracowywanie nowych produktów i usług odbywa się szybciej.

Optymalizacja podstawowych procesów, to ogromne wyzwanie zarówno pod względem technicznym ale również organizacyjnym. Firma musi określić swój model operacyjny na różnych poziomach organizacji i konsekwentnie go stosować, co ogranicza wpływ menadżerów lokalnych jednostek biznesowych na kształt realizowanych przez nich procesów a tym samym na kształt budowanych rozwiązań IT.

Następny poziom dojrzałości architektury korporacyjnej, to architektura modułowa.

Poziom 4: Architektura Modularności Biznesu

Architektura Modularności Biznesu poprawia zwinność przedsiębiorstwa dzięki zindywidualizowanym ale jednocześnie wielokrotnie wykorzystywanym modułom. Na poziomie czwartym firma wprowadza modularność procesów, które na poziomie trzecim podlegały komputeryzacji. Cechą charakterystyczną wyłanianych modułów (biznesowych) są dobrze określone interfejsy (biznesowe). Natomiast wewnątrz tych modułów stosuje się rozwiązania, które najlepiej pasują do realizowanych wewnątrz funkcji biznesowych. Modularność nie osłabia potrzeby standaryzacji – wciąż znajdują zastosowanie zarówno standardy technologiczne jak i standardy danych i procesów. Pozwala jednak na ich lokalne modyfikacje ale z zachowaniem standardowych interfejsów.

Dzięki reużywalnym modułom biznesowym działalność staje się bardziej spójna, umożliwia osiąganie lepszej wydajności i jednocześnie nie przeszkadza w lokalnej indywidualizacji procesów.

Porównanie czterech poziomów dojrzałości

Poniższy diagram obrazuje strukturę nakładów na IT na poszczególnych poziomach dojrzałości architektury korporacyjnej. Wynika z niego m.in., że przechodzenie firmy na kolejne poziomy dojrzałości architektury korporacyjnej zmniejsza nakłady na IT ale tylko do poziomu 3. Zaskakuje jednak, że poziom 4 okazuje się kosztować o 20 drożej, niż poziom 1. Taki wzrost kosztów autorzy diagramu tłumaczą np. tym, że koszty ukryte poprzednio w działalności gospodarczej zostały przeniesione do IT. Ponad to niewiele jest obecnie przedsiębiorstw znajdujących się na poziomie 4, więc mogą one ponosić wyższe koszty z racji bycia pionierami. Ale za najważniejszy powód autorzy diagramu uważają fakt, że przy modularności biznesu firmy mogą inwestować i inwestują w awangardowe innowacje.

Poniżej tabela porównuje przedstawione 4 poziomy dojrzałości. Widać, że wspinanie się po poszczególnych poziomach dojrzałości, to przechodzenie od optymalizacji w skali lokalnej do optymalizacji w skali globalnej.

Zasady wspinania się na poszczególne stopnie dojrzałości architektonicznej

Badacze z MIT CISR zidentyfikowali zasady, które umożliwiają skuteczne przechodzenie pomiędzy poszczególnymi poziomami dojrzałości architektury firmy. Oto najważniejsze z nich:

• Rozwój architektury przedsiębiorstwa należy ukierunkowywać na procesy strategiczne
  - wszystkiego nie da się opisać
  - żadna firma nie pozbędzie się silosów biznesowych
• Należy przyjąć do wiadomości, że złożone organizacje na różnych swoich szczeblach mają osobną architekturę i mogą znajdować się na różnych poziomach dojrzałości
• Trzeba posuwać się na przód stopniowo
  - nauka dyscypliny wymaga czasu
  - więcej jest korzyści z drobnych usprawnień niż z ryzykownego, przedwczesnego przejścia na wyższy poziom (np. próba wdrożenia SAP’a w firmie na poziomie pierwszym)
• Budowa architektury, to wewnętrzna sprawa firmy
  - pomoc z zewnątrz może się przydać
  - ale dopasowanie IT do Biznesu wymaga wewnętrznego dialogu między IT i Biznesem
  - decyzji w tych kwestiach nie powinien podejmować nikt z zewnątrz
• Należy dążyć do modularności biznesu (z wyjątkiem modelu Dywersyfikacji)
  - z badań MIT CISR wynika, że im wyższy poziom dojrzałości, tym większe sukcesy w osiąganiu strategicznych celów à większe średnie ROI
  - elastyczność oferowana przez Modularność Biznesu przynosi pożytek

Piąty poziom dojrzałości architektonicznej: Dynamiczne Przedsięwzięcie

Oprócz ww. 4. poziomów dojrzałości dotyczących danej firmy Badacze z MIT CISR zidentyfikowali również poziom piąty, który nazwali Dynamicznym Przedsięwzięcie i który dotyczy całych łańcuchów dostaw, w których bierze udział dane przedsiębiorstwo.

Charakterystyka:

• Moduły biznesowe różnych firm będą mogły łączyć się automatycznie w celu obsłużenia okazji rynkowe
• Aby było to możliwe, standaryzacji będą podlegać interfejsy biznesowe firm
• Efekty:(+) Poprawa elastyczności i zwinności budowy całego łańcucha dostaw

Zapowiedzią dynamicznych przedsięwzięć mogą być:

• interfejsy do usług UPS wbudowane w SAP
• market place’y Apple’a, Androida i Amazon'a
• usługi Telco 2.0 – standaryzacja interfejsu do klientów usług telco
• platforma freeconet.pl telefonii VoIP, gdzie realizator każdego połączenia telefonicznego jest wybierany dynamicznie.

Poniżej porównanie wszystkich pięciu poziomów dojrzałości architektury przedsiębiorstwa:

Źródła:

• J.W. Ross, P. Weil, D.C. Robertson, Architektura Korporacyjna jako strategia, 2010.
• MIT CISR, Maturity Matters: How Firms Generate Value from Enterprise Architekture, 2004.

Model operacyjny

W literaturze dot. architektury korporacyjnej możemy przeczytać, że architektura korporacyjna wypełnia lukę między zarządzaniem strategicznym a realizacją projektów i programów służących realizacji strategii biznesowej. Luka ta wynika z braku jasnych wytycznych, jak strategię biznesową należy realizować.

Jednak sama architektura korporacyjna, czyli uporządkowanie procesów biznesowych i infrastruktury technologii informatycznych, nie będzie wystarczające, jeśli nie będziemy wiedzieć, jakie uporządkowanie tych procesów i infrastruktury można uznać za właściwe. Np. podczas realizacji programów i projektów, których celem miałoby być realizowanie strategii biznesowej, można by, w sposób równouprawniony, dążyć zarówno do standaryzacji procesów biznesowych (poprzez wdrażanie tych samych rozwiązań IT w różnych miejscach firmy) jak i do integracji tych procesów poprzez ich wspieranie za pomocą różnych rozwiązań plus integracji tych rozwiązań

Wymagania na "dobroć" architektury korporacyjnej

Czy takim wyznacznikiem słuszności architektury może być jej zgodność ze strategią biznesową? Otóż nie - bezpośrednie dopasowanie strategii IT do strategii biznesowej, to cel ulotny. Strategia biznesowa mówi nam bowiem, JAKIE strategicznych cele biznesowe firma zamierza osiągnąć, ale nie mówi nic o tym, JAK je zamierza osiągnąć. Czyli nie opisuje taktyki realizacji celów strategicznych, nie opisuje sposobu organizacji pracy w przedsiębiorstwie, który to sposób jest bezpośrednio wspierany przez systemy informatyczne. I tutaj z pomocą przychodzi nam Model Operacyjny przedsiębiorstwa, czyli zbiór założeń/wytycznych określających wymagany do realizacji strategii biznesowej poziom integracji i standaryzacji procesów biznesowych przedsiębiorstwa.

Integracja procesów polega na tym, że pomiędzy jednostkami działającymi w ramach firmy odbywa się wymiana danych. Może ona dotyczyć poszczególnych podprocesów i prowadzić do płynnej realizacji procesu end-2-end albo może dotyczyć procesów równorzędnych pozwalając ukazywać klientowi jednolite oblicze. Integracja prowadzi do podejmowania lepszych decyzji dzięki dostępowi do informacji z różnych procesów. Jednak wymaga normalizacji formatów komunikacji oraz uzgadniania definicji używanych pojęć. Takie decyzje bywają trudne i pochłaniają wiele czasu.
Standaryzacja procesów oznacza dokładne zdefiniowanie, w jaki sposób proces ma być realizowany niezależnie od tego, kto i gdzie go realizuje.

Standaryzacja procesów wnosi przewidywalność i poprawia efektywność działań. Ale zmniejsza elastyczność i innowacyjność.

Architektura korporacyjna będzie dobra (skutecznie wypełni nam lukę pomiędzy zarządzaniem strategicznym a realizacją projektów i programów służących realizacji strategii biznesowej) wtedy, gdy:

• zostanie określony Model Operacyjny mówiący, jak dana firma zamierza strategię biznesową realizować,
• architektura korporacyjna będzie zgodna z tym Modelem Operacyjnym,
• osiągnięcie określonego Modelu Operacyjnego będzie faktycznym celem taktycznym przedsiębiorstwa a nie tylko papierem, do którego nie będą przystawać zgłaszane wymagania biznesowe.

Dobra architektura korporacyjna, to uporządkowanie procesów biznesowych i infrastruktury technologii informatycznych, uwzględniające stawiane przez Model Operacyjny wymogi względem integracji i standaryzacji firmy.

Typy Modeli Operacyjnych

Model Operacyjny przedsiębiorstwa, to zbiór założeń/wytycznych określających wymagany do realizacji strategii biznesowej poziom integracji i standaryzacji istotnych procesów biznesowych przedsiębiorstwa. Można by się więc domyślić, że jeśli dla tych dwóch wymiarów określimy po dwie wartości „Wysoki” oraz „Niski”, to wszystkich kombinacji będzie cztery:

1. Niski poziom standaryzacji, Niski poziom integracji – Dywersyfikacja
2. Niski poziom standaryzacji, Wysoki poziom integracji – Koordynacja
3. Wysoki poziom standaryzacji, Niski poziom integracji – Replikacja
4. Wysoki poziom standaryzacji, Wysoki poziom integracji – Unifikacja

Poniższy rysunek przedstawia charakterystyki poszczególnych modeli operacyjnych.

Decyzja w sprawie modelu operacyjnego wpływa istotnie na wykorzystanie technologii informatycznych w przedsiębiorstwie. I tak:

• w modelu dywersyfikacji możliwe jest praktycznie jedynie współdzielenie technologii infrastrukturalnych (sieci komputerowe, serwery pocztowe, przestrzenie dyskowe, itp.)
• w modelu koordynacji standaryzacji podlegają współdzielone lub przesyłane dane; aplikacje wspiejące poszczególne procesy mogą być inne
• w modelu replikacji standaryzowane są aplikacje i dane, choć te ostatnie nie podlegają współdzieleniu ani wymianie
• wreszcie w modelu koordynacji całe przedsiębiorstwo działa jako jeden organizm dzięki temu, że zbiór systemów ogólnofirmowych wspiera zestandaryzowane megaprocesy.

Ważność decyzji w sprawie modelu operacyjnego

Model Operacyjny przedstawia ogólną wizję, w jaki sposób firma zamierza realizować strategie biznesowe. Jest to jasna deklaracja dyrekcji przedsiębiorstwa, które procesy będą wyróżniać firmę na tle konkurencji i jak powinny być realizowane. Od wybranego typu Modelu Operacyjnego zależy, którą okazję strategiczną firma powinna rozwinąć a której poniechać.

Decyzja w sprawie modelu operacyjnego (lub jej brak) ma kolosalny wpływ na działanie firmy a w tym na budowę systemów IT wspierających procesy firmy. Podjęcie decyzji co do modelu operacyjnego powoduje, że firma realizuje tylko inicjatywy zgodne z modelem operacyjnym a innych nie. Firma nie skupia się na strategiach, tylko doskonali kluczowe umiejętności wdrażające wybrany model operacyjny. W IT objawia się to w ten sposób, że architektury rozwiązań IT są zgodne z modelem operacyjnym i dzięki temu rozwiązania IT wspierają wymagany sposób działania przedsiębiorstwa.

Jednak raz wdrożone i wciąż doskonalone procesy biznesowe trudno zmienić na inne. Więc raz powzięty model operacyjny nie powinien się zmieniać lub należy liczyć się z tym, że jego zmiana będzie bardzo kosztowna. A po stronie IT: raz zbudowane systemy informatyczne trudno zmienić na inne. Więc Raz powzięty model operacyjny, do którego IT będzie konsekwentnie dopasowywać całą architekturę IT, nie powinien się zmieniać lub należy liczyć się z tym, że jego zmiana będzie bardzo kosztowna.

Nietrafny wybór Modelu Operacyjnego (nieprzystosowany do rynku) może prowadzić do przykrych konsekwencji. Lecz równie niebezpieczne może być poniechanie jego określenia. Jeśli Model Operacyjny nie jest jasno sprecyzowany, firma łapie się raz jednej okazji, raz innej i nie jest w stanie rozwijać i doskonalić umiejętności, które uważa za kluczowe. Za taką zmienną taktyką podąża (bo musi) architektura systemów IT, przez co zamienia się konglomerat problemów: w którą stronę nie spróbujemy je później rozwijać, zawsze natrafimy na problem poważnie to utrudniający lub nawet uniemożliwiający.

Mówi się, że to co jest w naszych czasach niezmienne, to to, że wszystko ciągle się zmienia. Zasadniczo jest to prawdą. Ale w przypadku architektury IT przygotowanie się na zmianę wszystkiego w każdym kierunku albo wygeneruje niededykowane rozwiązania do wszystkiego (np. Excel) albo pochłonie ogromne koszty, żeby każdy możliwy sposób pracy dało się w nim szybko implementować. Ustalenie ram tych zmian za pomocą Modelu Operacyjnego znacznie je zmniejszy, choć spowoduje spadek elastyczności.

Model operacyjny a architektura korporacyjna

W zależności od wybranego typu Modelu Operacyjnego należy zastosować inną architekturę korporacyjną, która dla każdego z modeli jest specyficzna. Od wybranego typu Modelu Operacyjnego zależy, jak powinny być realizować wymagania na wspieranie procesów biznesowych przedsiębiorstwa, a nawet które z nich powinny być realizowane a które nie, gdyż nie pasują do przyjętego Modelu Operacyjnego a więc nie pasują do przyjętej architektury korporacyjnej.

Poniższy rysunek przedstawia relacje pomiędzy modele operacyjnym architekturą korporacyjną a strategią.

Model operacyjny definiuje wymogi architekturze korproacyjnej. Ta precyzuje ograniczenia dla strategii i inicjatyw strategicznych a także definiuje umiejętności firmy, których budowa i rozwój jest realizowana w ramach modelu współpracy z IT (IT Governance a w tym realizacja projektów z elementami IT). W efekcie zaplanowane w architekturze korporacyjnej zdolności przedsiębiorstwa (fundament przedsiębiorstwa) są implementowane a nauka z ich realizacji wpływa na nowe strategie.

Wielką niewiadomą (na razie) jest komponent oznaczony na rysunku symbolem "???", który jest źródłem wymagań dla modelu operacyjnego. Co decyduje/determinuje taki a nie inny model operacyjny przedsiębiorstwa? O tym kiedy indziej.

Zakończenie

Dobra architektura korporacyjna, to uporządkowanie procesów biznesowych i infrastruktury technologii informatycznych, uwzględniające stawiane przez Model Operacyjny wymogi względem integracji i standaryzacji firmy. Czyli dobra architektura korporacyjna, to taka architektura IT, która wymusza standaryzację działań biznesowych tam, gdzie taką standaryzację założono w Modelu Operacyjnym oraz wprowadza integrację procesów tam, gdzie w Modelu Operacyjnym przewidziano integrację procesów biznesowych.

Zarówno model operacyjny jak i architektura korporacyjna sprowadzają się co najmniej do tych dwóch spraw - integracji i integracji procesów przedsiębiorstwa. Model operacyjny, to wizja sposobu działania firmy. Architektura korporacyjna przekłada tę wizję w rzeczywistość. Dobra architektura korporacyjna, to uporządkowanie procesów biznesowych i infrastruktury technologii informatycznych, uwzględniające stawiane przez Model Operacyjny wymogi względem integracji i standaryzacji firmy.

Kontynuacja tematu modelu operacyjnego: tutaj.

Bibliografia

• J.W. Ross, P. Weill, D.C. Robertson, Architektura Korporacyjna jako strategia, Wyd. Emka, 2010.