lip
19

Model dostarczania wartości EA (cz. I)

Źródło: Andrzej Sobczak
Print Friendly

Jedną z podstawowych trudności przy inicjowaniu prac nad architekturą korporacyjną jest przekonanie decydentów do tego pomysłu. Bardzo często pojawiają się pytania z ich strony na temat korzyści, jakie może ta koncepcja dostarczyć organizacji i jakie są z tym związane koszty.
Oczywiście decydenci chcieliby poznać „twarde liczby”, a przynajmniej procentowe wartości (na przykład: dzięki wdrożeniu architektury korporacyjnej budowa rozwiązań IT będzie tańsza o X% i będzie to kosztować Y tyś złotych). W istniejących ramach architektonicznych (np. TOGAF) podkreśla się konieczność zdefiniowania propozycji wartości (value proposition), ale nie jest określone jak do tego podejść. Z rozmów jakie prowadzę wśród uczestników kursów, szkoleń, prezentacji wskazywane jest to jako duża słabość tych wzorców metodycznych.

Na bazie dotychczasowych prac badawczych i doświadczeń praktycznych chciałbym zaproponować autorskie podejście do opracowania modelu dostarczania wartości z wdrożenia podejścia architektonicznego w organizacji.

Punktem wyjścia do dalszych rozważań będzie przyjęcie dwóch założeń. Po pierwsze: architektura korporacyjna nie jest celem samym w sobie, lecz pełni funkcję usługową do pozostałych działań/funkcji w organizacji (przyjęcie tego założenia determinuje sposób definiowania wdrożenia podejścia architektonicznego). Po drugie: wdrożenie koncepcji architektury korporacyjnej w dowolnej organizacji może przybrać jedną z dwóch form:

  • Zbudowanie stałej (ciągłej) praktyki architektonicznej – obejmującej całą organizację, lub dobrze wydzielony jej fragment (enterprise); praktyka architektoniczna staje się wówczas elementem kultury organizacyjnej i w jej „polu rażenia” są wszystkie realizowane przedsięwzięcia w ramach całej organizacji (lub jej wcześniej określonego fragmentu).
  • Punktowe (czasowe) wykorzystanie podejścia architektonicznego – na potrzeby tymczasowego przedsięwzięcia, jakim jest program transformacji lub portfel projektów; podejście architektoniczne może po zakończeniu takiego przedsięwzięcia być wbudowane na stałe do organizacji (przybrać postać praktyki architektonicznej), ale równie dobrze może nie być dalej wykorzystywane – będzie do zależeć od decyzji zarządu/kierownictwa organizacji.

Wprowadzenie takiego podziału powoduje, że rozpatrywane będą dwie ścieżki opracowania modelu dostarczania wartości z wdrożenia podejścia architektonicznego. Obydwa będą jednak bazowały na tym samym pomyśle – jakim jest wykorzystanie odpowiednio zaadaptowanej koncepcji modelu biznesowego.

W chwili obecnej można spotkać w literaturze przedmiotu bardzo różne definicje, jak należy rozumieć model biznesowy. Jedną z nich (bazującą na pracach M. Portera) przytaczam poniżej: jest to opis, na bardzo wysokim poziomie ogólności, sposobu działalności organizacji (tj. kto, co, komu, w jaki sposób, jakim kosztem i za jaka cenę), dzięki któremu kreowana jest wartość w organizacji i dostarczana do jej klientów.

W tej chwili najbardziej popularne ujęcie modelu biznesowego zostało zaproponowane przez A. Osterwaldera. Opracował on proste narzędzie metodyczne, które nazwał kanwy modelu biznesowego (Business Model Canvas), które następnie opisał w książce Business Model Generation (w tym roku wydanej w języku polskim przez Wydawnictwo Helion).

Poniżej przedstawiono strukturę klasycznego „Business Model Canvas” Osterwaldera:

Rysunek 1. Business Model Canvas A. Osterwaldera

Zgodnie z w/w rysunkiem, struktura modelu biznesowego zaproponowana przez A. Osterwaldera zbudowana jest jako suma zasobów i czynności, które firma organizuje i realizuje celem dostarczenia konkretnej wartości dla konkretnego klienta. Centralną częścią modelu A. Osterwaldera jest propozycja wartości (value proposition). To właśnie wokół niej, dla konkretnych grup klientów, budowana jest część przychodowa i część kosztowa biznesu, która uporządkowana została przez A. Osterwaldera wokół kilku kluczowych elementów, takich jak: kanały dystrybucji i komunikacji, sposoby na budowę relacji, kluczowe czynności, kluczowe zasoby, kluczowi partnerzy, strumienie przychodów i struktura kosztów.

W tym miejscu należy odnieść się do artykułu „Business Model Canvas 2.0” R. Kołodzieja, który zauważył, że warto rozważyć rozszerzenie Business Model Canvas A. Osterwaldera o kilka elementów (na potrzeby niniejszego artykułu przedstawię dwa rozszerzenia zaproponowane przez R. Kołodzieja):

  • „Praca do wykonania przez klienta” (Job To Be Done) – R. Kołodziej twierdzi, że „źródłem wszelkich proponowanych klientom rozwiązań jest praca, którą ma on do wykonania; praca ta określa działanie, dla których produkt lub usługa jest nabywana lub może zostać nabyta”. Ponadto zauważa on, że: „ponieważ praca określa działania, ze względu na które produkt czy usługa może zostać zakupiona, jej określenie zawsze powinno zawierać (1) czasownik, określający to działanie oraz (2) rzeczownik, jako obiekt tego działania”.
  • „Rezultat, który ma zostać osiągnięty” (Outcome to be Achieved) – R. Kołodziej podkreśla, że „każda praca oczekiwana przez klienta (Job To Be Done) musi przynieść konkretny rezultat; rezultat jest miarą, którą klient używa do określenia jakości wykonania konkretnej pracy na jego rzecz – w ten sposób rezultat jest ściśle powiązany z wykonaną pracą; prosta praca oczekiwana przez klienta może mieć jeden rezultat, ale skomplikowana, angażująca wiele elementów i składająca się z wielu kroków, może przynieść szereg różnych rezultatów”. R. Kołodziej zauważa także, że „ze względu na fakt, że rezultat jest miarą sukcesu, powinien zawierać (1) kierunek poprawy, (2) jednostkę miary tej poprawy oraz (3) specyficzny, konkretny cel kontroli, określający, co tak naprawdę było poddane pomiarowi przez klienta”.

Rysunek 2. Zmodyfikowany przez R. Kołodzieja Business Model Canvas A. Osterwaldera

Poniżej chciałbym zaprezentować sposób opracowania modelu dostarczania wartości z wdrożenia podejścia architektonicznego dla sytuacji, kiedy myślimy o zbudowaniu stałej praktyki architektonicznej (sposób opracowania modelu dostarczania wartości z wdrożenia podejścia architektonicznego dla punktowego wykorzystania będzie przedstawiony w kolejnym artykule). Sposób ten będzie wykorzystywał, zaadoptowany do problematyki architektury korporacyjnej, model opracowany przez A. Osterwaldera, rozszerzony o prace R. Kołodzieja.

Model dostarczania wartości z wdrożenia podejścia architektonicznego dla sytuacji, kiedy myślimy o zbudowaniu stałej praktyki architektonicznej składa się z 14 komponentów (2 zewnętrznych w stosunku do budowy praktyki architektonicznej oraz 12 wchodzących w skład budowy praktyki architektonicznej), które należy wypełnić zawartością (treścią) w określonej kolejności – oznaczonej na poniższym rysunku cyframi. Przy czym kolejność ta jest tylko referencyjna – można dostosować ją do specyfiki danej organizacji. Ponadto zakłada się tutaj podejście iteracyjne – zarówno na etapie wypełniania treścią tego modelu, jak również na etapie późniejszym. Zalecane są wręcz okresowe przeglądy i aktualizacje wypełnionego modelu. Odnosząc się do ram architektonicznych TOGAF, model ten powinien być wypełniony podczas fazy wstępnej (Preliminary Phase) cyklu ADM, zaś systematyczny jego przegląd powinien następować po zamknięciu danej iteracji ADM.

 Rysunek 3. Model dostarczania wartości z wdrożenia podejścia architektonicznego

Za powstanie takiego modelu odpowiedzialny jest Główny Architekt (lub osoba, która przymierza się do tej roli), a zatwierdzić ten dokument powinien zarząd / kierownictwo organizacji.

Poniżej przedstawiono skróconą charakterystykę poszczególnych komponentów modelu:

1. Odbiorcy produktów / usług architektonicznych – należy zidentyfikować role, które (potencjalnie) będą korzystały z produktów / usług świadczonych przez zespół architektoniczny – może to być np. dyrektor ds. IT, ale i szef działu zajmującego się optymalizacją biznesową.

2. Prace do wykonania przez Odbiorców produktów / usług architektonicznych – należy zidentyfikować jakie główne zadania mają wykonać potencjalni użytkownicy produktów / usług architektonicznych. Przykładem takich prac może być „zmniejszenie wydatków na IT” – dla dyrektora ds. IT; dla szefa działu zajmującego się optymalizacją biznesową – „automatyzacja procesów biznesowych”.

3. Rezultat, który ma być osiągnięty przez Odbiorców 
produktów / usług architektonicznych – należy zidentyfikować, jakie rezultaty końcowe mają osiągnąć odbiorcy produktów/usług architektonicznych – np. „minimalizacja kosztów integracji nowych systemów informatycznych wprowadzanych do istniejącego środowiska IT”.

4. Kluczowe ograniczenia dla praktyki architektonicznej – należy zidentyfikować, jakie są kluczowe ograniczenia dla tworzonej praktyki architektonicznej – np. długoletnie umowy outsourcingowe, ograniczenia narzucane przez przepisy prawne (np. w przypadku organizacji sektora publicznego) lub wytyczne uzyskiwane od zagranicznego właściciela (w przypadku np. międzynarodowych grup kapitałowych).

Uwaga: Kluczowa, z punktu widzenia powodzenia opracowania dostarczania wartości z wdrożenia podejścia architektonicznego, jest właściwie przeprowadzona analiza dla komponentów 1-4 (a zwłaszcza 2-3). Od tego momentu wszystkie poniższe punkty są pochodną informacji określonych dla wcześniejszych komponentów.

5. Korzyści z wdrożenia a podejścia architektonicznego – centralny punkt modelu – jest to obietnica, którą składa zespół architektoniczny, że dzięki „wbudowaniu” w organizację podejścia architektonicznego, będzie można osiągnąć określone korzyści. Może to być np. obietnica uproszczenia integracji systemów, poprzez dysponowanie uporządkowaną i skodyfikowaną wiedzą nt. ich powiązań.

6. Kluczowi partnerzy praktyki architektonicznej – należy zidentyfikować, kto będzie partnerem (wsparciem) przy budowie praktyki architektonicznej; może to być np. firma dostarczająca narzędzia informatyczne (repozytorium architektoniczne); wewnętrznym partnerem może być np. dział IT odpowiedzialny za funkcjonowanie sieci LAN/WAN – który będzie konfigurował sieciowe aspekty funkcjonowania repozytorium architektonicznego.

7. KPI dla praktyki architektonicznej – należy określić kluczowe wskaźniki efektywności praktyki architektonicznej; w przypadku integracji systemów – może to być % systemów co do których wykorzystano informację o ich interfejsach przy łączeniu ich z innymi systemami.

8. Kluczowe produkty/usługi architektoniczne – należy określić jakie produkty i usługi będą dostarczane przez zespół architektoniczny. Może to być np. mapa systemów z opisanymi interfejsami (na poziomie logicznym i fizycznym).

9. Model
 operacyjny 
praktyki 
architektonicznej – należy określić, jak będzie wyglądał model operacyjny praktyki architektonicznej – tj. czy procesy architektoniczne będą scentralizowane czy rozproszone wewnątrz organizacji, czy wymiana informacji pomiędzy poszczególnymi zespołami architektonicznymi będzie ścisła, czy raczej nie będzie występować; punkt ten ma znaczenie w przypadku wdrażania podejścia architektonicznego w dużych organizacjach o charakterze federacyjnym, lub w przypadku kiedy praktyka architektoniczna jest implementowana w kilku krajach.

10. Kanały komunikacji i dostarczania produktów / usług 
architektonicznych – należy określić w jaki sposób będą dostarczane produkty / usługi architektoniczne. Może to być np. serwis wiki, prezentacje w Power Poincie itp.

11. Kluczowe działania w ramach praktyki architektonicznej – należy określić, na wysokim poziomie ogólności, najważniejsze procesy/procedury architektoniczne – np. przykładem procesu architektonicznego może być badanie zgodności nowych systemów na zgodność z przyjętymi w organizacji standardami.

12. Kluczowe ciała, role i ich odpowiedzialności związane z praktyką architektoniczną – należy zdefiniować kluczowe ciała i role związane z praktyką architektoniczną i przypisać im określone odpowiedzialności (w tym celu można posłużyć się techniką RACI). Przykładową rolą jest Główny Architekt, a jego odpowiedzialnością jest utworzenie (R) raportu z przeglądu architektonicznego.

13. Kluczowe
 ryzyka związane z praktyką architektoniczną – należy stworzyć rejestr ryzyk związany z praktyką architektoniczną. Jednym z przykładowych ryzyk będzie np. brak kompetencji architektonicznych po stronie organizacji.

14. Struktura kosztów związanych z praktyką 
architektoniczną – dysponując wiedzą nt. komponentów opisanych w punktach 1-13 możliwe jest ustalenie struktury kosztów związanych z wdrożeniem praktyki architektonicznej, a w niektórych przypadkach dokonanie pierwszych szacunków. Jednym ze składowych struktury kosztów będą np. szkolenia zespołu architektonicznego.

Podejście zaprezentowane w niniejszym artykule ma charakter roboczy. Z tego względu będę wdzięczny za wszystkie Państwa uwagi. Obecnie przygotowuję jego drugą część poświęconą budowie modelu wartości z wdrożenia podejścia architektonicznego na potrzeby tymczasowego przedsięwzięcia (takiego jak program przy portfelu projektów). Postaram się wówczas zawrzeć w nim szersze podsumowanie rozpoczętych tutaj rozważań.

W niniejszym artykule wykorzystałem przemyślenia zawarte w następujących opracowaniach:

  • R. Kołodziej, Business Model Canvas czy Lean Canvas?, 31.01.2012 (dostęp 15.07.2012)
  • R. Kołodziej, Business Model Canvas 2.0, 10.02.2012 (dostęp 15.07.2012)
  • A. Osterwaldera, Y. Pigneur, A. Smith, Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers, Wiley; 1 Edycja, 2010.

 

Andrzej Sobczak

Profesor, kierownik Zakładu Zarządzania Informatyką w Instytucie Informatyki i Gospodarki Cyfrowej SGH. Ma ponad 8 letnie doświadczenie we wdrażaniu koncepcji architektury IT i architektury korporacyjnej. Posiada certyfikaty TOGAF 8/9, ArchiMate 2.0, ITIL, MSP.

Polecane wpisy

TAGI DLA WPISU

Dodaj komentarz

W celu wzięcia udziału w dyskusji jako zalogowany użytkownik możesz zalogować się poprzez jeden z poniższych serwisów.

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Captcha Captcha Reload

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>