Model operacyjny przedsiębiorstwa i jego znaczenie dla firmy, w tym IT

Transkrypt

1 III Spotkanie Zawodowe WEiTI PW R.ZAŁ Model operacyjny przedsiębiorstwa i jego znaczenie dla firmy, w tym IT Sposób na budowę trwałego potencjału firmy Bogdan Głuszkowski Wszelkie prawa zastrzeŝone

2 Bogdan Głuszkowski obecnie 2011 Architekt Korporacyjny w Orange Polska wcześniej m.in: Analityk / Architekt Rozwiązań / PM w PTC (T-Mobile) członek AEA (Association of Enterprise Architects) oraz CUEC (Consortium for Untangling Enterprise Complexity) doświadczenie w IT: 20 lat; w IT dla telco: 14 lat absolwent Informatyki na Wydziale Elektroniki Politechniki Warszawskiej absolwent Podyplomowego Studium Efektywnego Zarządzania IT w Przedsiębiorstwie na SGH w Orange Polska zajmuje się m.in. modelem operacyjnym Orange Polska oraz zmniejszeniem złoŝoności architektury korporacyjnej IT Grupy kontakt: bgluszkowski@gmail.com tel.:

3 Agenda Trudne pytania w projektach IT Architektura korporacyjna Model operacyjny WdraŜanie modelu operacyjnego Poziomy dojrzałości architektonicznej Zakończenie Strategia Dane Aplikacje Platformy 3

4 TRUDNE PYTANIA W PROJEKTACH IT 4

5 Winchester House (1/2) Sarah Winchester Winchester House 5

6 Winchester House (2/2) 6

7 Trudne pytania w projektach IT bez jednoznacznych odpowiedzi Środowiska IT w duŝych przedsiębiorstwach o długiej historii, to: - róŝnorodny zlepek systemów - 50 lub więcej baz danych - setki programów instalowanych przez dekady - integrowanych w sposób przypadkowy - i słabo udokumentowany źródło: C. Retting, The Trouble With Enterprise Software, 2007, MIT Sloan Management Review, vol. 49 no. 1. 7

8 Trudne pytania w projektach IT bez jednoznacznych odpowiedzi Środowiska IT w duŝych przedsiębiorstwach o długiej historii, to: - róŝnorodny zlepek systemów - 50 lub więcej baz danych - setki programów instalowanych przez dekady - integrowanych w sposób przypadkowy - i słabo udokumentowany źródło: C. Retting, The Trouble With Enterprise Software, 2007, MIT Sloan Management Review, vol. 49 no. 1. W projektach IT prowadzonych w takich środowiskach pojawiają się pytania, bez oczywistych odpowiedzi: - zbudować nową aplikację, czy wykorzystać istniejącą? - jeśli wykorzystać, to którą? - jeśli wykorzystać, to przerobić istniejące funkcjonalności, czy zbudować nowe? - dane: rozbudować istniejącą bazę, czy zbudować nową? - jeśli rozbudować, to rozszerzyć istniejące struktury, czy dobudować nowe? - co robić ze sprzecznymi wymaganiami? Jeśli decyzje w takich sprawach podejmuje się niezaleŝnie w kaŝdym projekcie to nie zawsze są one spójne a ich podejmowanie zabiera duŝo czasu 8

9 Przyczyna: informatyzacja oparta bezpośrednio na strategii biznesowej W wielu przedsiębiorstwach, procedura informatyzacji jest oparta na strategii: Rozwiązania IT Strategia, Inicjatywy strategiczne Budowa rozwiązań IT Dane Aplikacje Platformy 9

10 Przyczyna: informatyzacja oparta bezpośrednio na strategii biznesowej W wielu przedsiębiorstwach, procedura informatyzacji jest oparta na strategii: Rozwiązania IT Strategia, Inicjatywy strategiczne Budowa rozwiązań IT Dane Aplikacje Platformy Taka procedura ma co najmniej trzy słabe strony (z punktu widzenia IT): - (1) strategia nie zawsze jest jasna rozwiązania doraźne - (2) potrzeby jednostek nie zawsze są spójne rozwiązania niespójne - (3) strategia się zmienia rozwiązania stają się nieaktualne 10

11 Przyczyna: informatyzacja oparta bezpośrednio na strategii biznesowej W wielu przedsiębiorstwach, procedura informatyzacji jest oparta na strategii: Strategia, Inicjatywy strategiczne Budowa rozwiązań IT Taka procedura ma co najmniej trzy słabe strony (z punktu widzenia IT): - (1) strategia nie zawsze jest jasna rozwiązania doraźne - (2) potrzeby jednostek nie zawsze są spójne rozwiązania niespójne - (3) strategia się zmienia rozwiązania stają się nieaktualne Rozwiązania IT Dane Aplikacje Platformy To cud, Ŝe to działa! Efekt - silosy biznesowe: - kaŝde z rozwiązań sprawdza się - wspólnie utrudniają koordynację procesów - dane są nieaktualne, niekompletne i podatne na błędy Bezpośrednie dopasowanie IT do strategii biznesowej, to cel ulotny 11

12 Symptomy nieefektywności obserwowane od strony IT Jedynym źródłem wymagań co do konstruowania rozwiązań są wymagania Biznesowe w projekcie, regulacje oraz problemy techniczne do rozwiązania Wymuszanie budowy nowych funkcjonalności pomimo potencjału reuŝycia istniejących Wymagania róŝnych stron biznesu czasami są ze sobą niespójne a wtedy wygrywa biznes silniejszy politycznie Długie dyskusje, czy coś zrobić w jednym systemie lub w drugim, czy teŝ zbudować całkiem nowy obok istniejących Wydaje się, Ŝe złoŝoność architektury rośnie szybciej, niŝ to wydaje się to konieczne Przedsięwzięcia typu zmiana stawki VAT (reakcja na drobną zmianę przepisów) kosztują duŝo, trwają długo i są obarczone duŝym ryzykiem IT jest zaskakiwane podejmowanymi poza nim decyzjami o wyłączeniu jakiegoś systemu lub o zakupie jakiejś technologii / rozwiązania źródło: opracowanie własne 12

13 Gdzie szukać odpowiedzi na pytania IT? Pytania dotyczą wymaganego stopnia reuŝycia funkcjonalności i współdzielenia danych Wymaganego, tzn. najlepszego dla firmy Gdzie szukać takich wymagań ogólnofirmowych? 13

14 Gdzie szukać odpowiedzi na pytania IT? Pytania dotyczą wymaganego stopnia reuŝycia funkcjonalności i współdzielenia danych Wymaganego, tzn. najlepszego dla firmy Gdzie szukać takich wymagań ogólnofirmowych? WaŜnych problemów, z którymi się borykamy, nie moŝna rozwiązywać na tym samym poziomie myślenia, na którym powstały Albert Einstein Odpowiedzi na pytania IT dotyczące najlepszego stopnia reuŝycia funkcjonalności i współdzielenia danych nie znajdziemy w IT 14

15 Dlaczego odpowiedzi znajdziemy w strategii przedsiębiorstwa? Pytania IT o najlepszy dla firmy stopień reuŝycia funkcjonalności i współdzielenia danych wynikają ze strategicznych wymagań na standaryzację i integrację procesów Strategia biznesowa dotyczy: - rynków, na których firma konkuruje - produktów, którymi chce konkurować - pozycji, jaką ma zdobyć - umiejętności, jakie ma doskonalić Strategia moŝe ulegać zmianie w reakcji na: - posunięcia konkurentów - w celu wykorzystania nowych moŝliwości (np. technologicznych) Generalnie strategia mówi CO i dla KOGO całą firma będzie wytwarzać IT potrzebuje informacji, JAK CAŁA FIRMA chce to robić 15

16 Co robić? Na potrzeby IT strategię trzeba przetłumaczyć: - na spójny opis wymaganego sposobu działania firmy - w języku zrozumiałym przez IT Do efektywnego działania, IT potrzebuje spójnego opisu wymaganego sposobu działania firmy, określonego na poziomie ogólnofirmowym: ARCHITEKTURY KORPORACYJNEJ AK spójnie odpowiada na pytanie, JAK firma chce realizować swoje strategie Rozwiązania dopasowane do architektury korporacyjnej będą dopasowane do wymaganego sposobu działania firmy 16

17 ARCHITEKTURA KORPORACYJNA 17

18 Architektura korporacyjna (1/3) Architektura korporacyjna, to opis struktur i funkcji komponentów korporacji, wzajemnych relacji pomiędzy nimi oraz pryncypia zarządzające ich tworzeniem i rozwojem w czasie źródło: M.Lankhorst, Enterprise Architecture at Work: Modelling, Communication and Analysis Architektura korporacyjna powstała 25 lat temu (Zachman) 18

19 Architektura korporacyjna (2/3) Domeny architektury korporacyjnej: Architektura korporacyjna traktuje całe przedsiębiorstwo jak system źródło: The Open Group, ArchiMate 2.0 Specification 19

20 Architektura korporacyjna (3/3) Architektura korporacyjna zawiera opis stanu obecnego (AS-IS), stanu docelowego (TO-BE) oraz stanów przejściowych 20

21 Umiejscowienie architektury korporacyjnej Architektura korporacyjna, to opis strategicznych umiejętności niezbędnych do realizowania zgodnych z nią strategii AK wyznacza ramy inicjatyw moŝliwych do realizowania Ułatwia realizację inicjatyw zgodnych Nie jest w stanie pomóc inicjatywom do niej niepasującym Strategia, Inicjatywy strategiczne (CO) Architektura korporacyjna (JAK) Budowa rozwiązań IT (JAK) Dane Aplikacje Infrastruktura określa ramy 21

22 Umiejscowienie architektury korporacyjnej Architektura korporacyjna, to opis strategicznych umiejętności niezbędnych do realizowania zgodnych z nią strategii AK wyznacza ramy inicjatyw moŝliwych do realizowania Ułatwia realizację inicjatyw zgodnych Nie jest w stanie pomóc inicjatywom do niej niepasującym Strategia, Inicjatywy strategiczne (CO) Architektura korporacyjna (JAK) Budowa rozwiązań IT (JAK) Dane Aplikacje Infrastruktura określa ramy Korzyść ze stosowania architektury korporacyjnej: - zamiast tworzyć odrębne rozwiązania adresujące odrębne inicjatywy strategiczne - budujemy i rozwijamy zdolności wielokrotnego wykorzystania - maksymalizując korzyści z raz wdroŝonych procesów i systemów Gdy firma doskonali sposób działania opisany w AK, wdraŝanie zgodnych z nią strategii staje sie tańsze i szybsze dzięki wielokrotnemu wykorzystaniu tych samych procesów i systemów 22

23 Architektura korporacyjna moŝe być trudna do zrozumienia dla managerów źródło: A.Sobczak 23

24 Rozwiązanie - diagram podstawowy architektury korporacyjnej Jednokartkowy diagram podstawowy powinien oddawać sedno architektury korporacyjnej Strategia, Inicjatywy strategiczne (CO) Diagram podstawowy Architektura korporacyjna Budowa rozwiązań IT (JAK) Dane Aplikacje Infrastruktura określa ramy Diagram podstawowy architektury korporacyjnej zawiera: - kluczowych klientów, partnerów dostawców - kluczowe procesy biznesowe - wymieniane / współdzielone informacje - najwaŝniejsze rozwiązania automatyzujące i/lub technologie integrujące 24

25 Przykład diagramu podstawowego architektury korporacyjnej (1/2) źródło: J.W.Ross, Enterprise Architecture as Strategy, Chief Architects Forum,

26 Przykład diagramu podstawowego architektury korporacyjnej (2/2) źródło: J.W.Ross, Enterprise Architecture as Strategy, Chief Architects Forum,

27 Jaka architektura korporacyjna jest dla firmy najlepsza? Architektura korporacyjna - perspektywa długoterminowej Odpowiada na pytanie, JAK firma chce realizować swoje strategie Projekty nie tylko rozwiązują problemy doraźne, ale budują potencjał firmy Jednak problem z przetłumaczeniem strategii na sposób działania firmy pozostaje: jaka architektura korporacyjna będzie dla firmy najlepsza? 27

28 Jaka architektura korporacyjna jest dla firmy najlepsza? Architektura korporacyjna - perspektywa długoterminowa Odpowiada na pytanie, JAK firma chce realizować swoje strategie Projekty nie tylko rozwiązują problemy doraźne, ale budują potencjał firmy Jednak problem z przetłumaczeniem strategii na sposób działania firmy pozostaje: jaka architektura korporacyjna będzie dla firmy najlepsza? Dobra architektura korporacyjna powinna spełniać wymagania przedsiębiorstwa na integrację i standaryzację najwaŝniejszych procesów firmy Gdzie szukać takich ogólnofirmowych wymagań? 28

29 MODEL OPERACYJNY Przedstawione tutaj koncepcje wywodzą się z badań przeprowadzonych przez MIT CISR - MIT Sloan School of Management Center for Information Systems Research ( Badania zostały przeprowadzone w latach i polegały na analizie architektury ponad 200 przedsiębiorstw w ponad 20 krajach w USA i Europie 29

30 Rozwiązanie - model operacyjny Model operacyjny - wymagany poziom integracji i standaryzacji procesów przedsiębiorstwa, potrzebny dla dostarczania klientom produktów i usług Architektura korporacyjna stanowi jego uszczegółowienie, które adresuje aktualną strategię i wyznacza ramy strategii przyszłych Architektura korporacyjna to opis struktur i funkcji komponentów korporacji, wzajemnych relacji pomiędzy nimi oraz pryncypia zarządzające ich tworzeniem i rozwojem w czasie Dobra architektura korporacyjna odzwierciedla ogólnofirmowe wymagania na integrację i standaryzację wynikające z modelu operacyjnego firmy Model operacyjny (JAK) Strategia, Inicjatywy strategiczne (CO) Architektura korporacyjna (JAK) Budowa rozwiązań IT (JAK) Dane Aplikacje Infrastruktura określa ramy 30

31 Kluczowe aspekty modelu operacyjnego Model operacyjny, to wymagany poziom integracji i standaryzacji procesów przedsiębiorstwa, potrzebny dla dostarczania klientom produktów i usług Model operacyjny sprowadza się do dwóch spraw: standaryzacji i integracji najwaŝniejszych procesów biznesowych przedsiębiorstwa Standaryzacja procesów Charakterystyka: dany proces jest realizowany zawsze tak samo Korzyści: redukcja niejednorodności, wzrost wydajności Cena: spada elastyczność lokalna Wpływ na IT: rozwiązanie IT moŝe być uŝywane przez wielu wykonawców procesu taniej (reuŝycie obniŝa koszty) Integracja procesów Charakterystyka: wymiana informacji pomiędzy procesami w celu: - współdzielenia informacji przez wiele procesów - realizacji procesu end-2-end (transakcji) - podejmowania działań w wielu miejscach firmy w reakcji na jedno zdarzenie Korzyści: lepsza koordynacja i zwinność przedsiębiorstwa Cena: konieczność uzgodnienie interfejsów między procesami Wpływ na IT: więcej systemów/funkcjonalności i integracji droŝej (róŝnorodność kosztuje) 31

32 Typy modeli operacyjnych Model operacyjny, to wymagany poziom integracji i standaryzacji procesów przedsiębiorstwa, potrzebny dla dostarczania klientom produktów i usług 32

33 Typy modeli operacyjnych Model operacyjny, to wymagany poziom integracji i standaryzacji procesów przedsiębiorstwa, potrzebny dla dostarczania klientom produktów i usług Poziom integracji procesów NISKI WYSOKI Koordynacja Dywersyfikacja Unifikacja Replikacja NISKI WYSOKI Poziom standaryzacji procesów Źródło: J.W.Ross, P.Weil, D.C.Robertson, Architektura Korporacyjna jako strategia, 2010, wyd. Studio Emka 33

34 INTEGRACJA STANDARYZACJA Dywersyfikacja Charakterystyka: - mało lub brak wspólnych klientów i dostawców - niezaleŝne transakcje jednostek - zindywidualizowana działalność jednostek - autonomiczne zarządzanie działalnością jednostek - projektowanie procesów pod kontrolą jednostek - decyzje w sprawach IT zapadają w jednostkach Cele: - niezaleŝność działania - wzmacnianie marki - budowanie sukcesu grupy przez niezaleŝne sukcesy jednostek - moŝna reuŝywać infrastrukturę IT w celu wykorzystania ekonomii skali Przykłady: - Wirtualna Polska i Telekomunikacja Polska w ramach grupy Orange Polska Podejście do projektowania architektury korporacyjnej: - (1) Współdzielone technologie 34

35 INTEGRACJA STANDARYZACJA Koordynacja - bezproblemowy dostęp do wspólnych danych Charakterystyka: - wspólne dane o wspólnych klientach, produktach lub dostawcach - wpływ na transakcje innych jednostek - zindywidualizowana działalność jednostek - autonomiczne zarządzanie działalnością jednostek - projektowanie procesów pod kontrolą jednostek - decyzje w sprawach IT zapadają w jednostkach Cele: - nie chodzi obniŝanie kosztów - chodzi o zintegrowaną obsługa klientów - chodzi o moŝliwość oferowania klientowi dodatkowych produktów Przykłady: - TP i PTK w ramach Orange Polska - dwie firmy miejscami działające inaczej, są w stanie swoim klientom oferować usługi z drugiej firmy Podejście do projektowania architektury korporacyjnej: - (1) Kluczowi klienci, partnerzy, dostawcy - (2) Współdzielone informacje - (3) NajwaŜniejsze procesy i ich połączenia - (4) Aplikacje automatyzujące i technologie integracji 35

36 INTEGRACJA STANDARYZACJA Unifikacja - procesy zestandaryzowane i zintegrowane Charakterystyka - globalne procesy wspierane przez systemy ogólnofirmowe - jednostki prowadzą taką samą działalność - centralne kierownictwo narzuca wzorce funkcjonowania - centralni właściciele procesów - centralne bazy danych - decyzje w sprawach IT zapadają w centrali Cele: - obniŝanie kosztów - podnoszenie jakości - identyczna obsługa wspólnych klientów - wykorzystanie ekonomii skali w realizacji procesów Przykłady: - oddziały banku realizujące procesy globalne przy uŝyciu centralnych narzędzi Podejście do projektowania architektury korporacyjnej: - (1) Kluczowi klienci, partnerzy, dostawcy - (2) Zestandaryzowane podstawowe procesy i ich połączenia - (3) Współdzielone / wymieniane informacje - (4) Aplikacje automatyzujące i technologie integracji 36

37 INTEGRACJA STANDARYZACJA Replikacja - zestandaryzowana niezaleŝność Charakterystyka: - mało lub brak wspólnych klientów i dostawców - standardowe definicje danych gromadzonych lokalnie - niezaleŝne transakcje jednostek - taka sama lub podobna działalność jednostek - autonomiczni liderzy jednostek o małym wpływie na procesy - centralni właściciele procesów - decyzje w sprawach IT zapadają w centrali Cele: - wykorzystanie ekonomii skali w realizacji procesów - obniŝanie kosztów - podnoszenie jakości Przykłady: - McDonald s Podejście do projektowania architektury korporacyjnej: - (1) Zestandaryzowane procesy - (2) Aplikacje automatyzujące 37

38 Przykład modelu operacyjnego (1/2) źródło: J.Ross, Enterprise Architecture as Strategy, Chief Architects Forum,

39 Przykład modelu operacyjnego (2/2) źródło: J.Ross, Enterprise Architecture as Strategy, Chief Architects Forum,

40 Do jakiego modelu dąŝą firmy Poziom integracji procesów NISKI WYSOKI Model operacyjny, to wymagany poziom integracji i standaryzacji procesów przedsiębiorstwa, potrzebny dla dostarczania klientom produktów i usług Koordynacja: wspólni klienci, dostawcy lub wspólne produkty wpływ na transakcje innych jednostek zindywidualizowana działalność jednostek autonomiczne zarządzanie działalnością jednostek Dywersyfikacja: mało lub brak wspólnych klientów i dostawców niezaleŝne transakcje jednostek zindywidualizowana działalność jednostek autonomiczne zarządzanie działalnością jednostek projektowanie procesów pod kontrolą jednostek decyzje w sprawach IT zapadają w jednostkach Unifikacja: globalne procesy wspierane przez systemy ogólnofirmowe jednostki prowadzą podobna lub taką samą działalność centralne kierownictwo narzuca wzorce funkcjonowania centralni właściciele procesów 16% 57% projektowanie procesów pod kontrolą jednostek wspólne dane o klientach/produktach/dostawcach uzgodnione procesy budowy rozwiązań IT decyzje w sprawach IT zapadają w jednostkach centralne bazy danych decyzje w sprawach IT zapadają w centrali Replikacja: mało lub brak wspólnych klientów i dostawców niezaleŝne transakcje jednostek taka sama lub podobna działalność jednostek 16% 11% autonomiczni liderzy jednostek o małym wpływie na procesy jednostek centralni właściciele procesów standardowe definicje danych gromadzonych lokalnie decyzje w sprawach IT zapadają w centrali NISKI Poziom standaryzacji procesów WYSOKI źródło: A.Sobczak 40

41 WaŜność decyzji w sprawie modelu operacyjnego (1/2) Model operacyjny, to wymagany poziom integracji i standaryzacji procesów przedsiębiorstwa, potrzebny dla dostarczania klientom produktów i usług 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 Brak decyzji co modelu operacyjneg o powoduje, Ŝe: Biznes: - Firma łapie się raz jednej szansy raz drugiej - Firma nie jest w stanie doskonalić umiejętności, które w przyszłości mogłaby wykorzystać ponownie IT: - Decyzje co do strategicznie najlepszej architektury IT podejmuje na ślepo, lokalnie w kaŝdym projekcie - Efekt: zbędny wzrost złoŝoności i dryfowanie architektury IT w kierunku będącym wypadkową takich decyzji 41

42 WaŜność decyzji w sprawie modelu operacyjnego (2/2) Model operacyjny, to wymagany poziom integracji i standaryzacji procesów przedsiębiorstwa, potrzebny dla dostarczania klientom produktów i usług 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: Biznes: - Firma realizuje tylko inicjatywy zgodne z modelem operacyjnym, innych nie - Firma nie skupia się na strategiach, tylko doskonali kluczowe umiejętności IT: - Architektury rozwiązań IT muszą być zgodne z modelem operacyjnym - Rozwiązania IT wspierają wymagany sposób działania przedsiębiorstwa 42

43 WaŜność decyzji w sprawie modelu operacyjnego (2/2) Model operacyjny, to wymagany poziom integracji i standaryzacji procesów przedsiębiorstwa, potrzebny dla dostarczania klientom produktów i usług 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: Biznes: - Firma realizuje tylko inicjatywy zgodne z modelem operacyjnym, innych nie - Firma nie skupia się na strategiach, tylko doskonali kluczowe umiejętności IT: - Architektury rozwiązań IT muszą być zgodne z modelem operacyjnym - Rozwiązania IT wspierają wymagany sposób działania przedsiębiorstwa ale Biznes: - Raz wdroŝone i wciąŝ doskonalone procesy biznesowe trudno zmienić na inne - Raz powzięty model operacyjny nie powinien się zmieniać lub naleŝy liczyć się z tym, Ŝe jego zmiana będzie bardzo kosztowna IT: - Raz zbudowane systemy informatyczne trudno zmienić na inne - 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 43

44 Model operacyjny - podsumowanie Model operacyjny, to wymagany poziom integracji i standaryzacji procesów przedsiębiorstwa, potrzebny dla dostarczania klientom produktów i usług Jest bardziej praktyczny i bardziej stabilny, niŝ strategie Określa wymagania na sposób, w jaki firma realizuje swoje strategie Tak jak wymagania do rozwiązania determinują konstrukcję rozwiązania, tak model operacyjny determinuje kształt architektury korporacyjnej Model operacyjny (JAK) Strategia, Inicjatywy strategiczne (CO) Architektura korporacyjna (JAK) Budowa rozwiązań IT (JAK) Dane Aplikacje Infrastruktura określa ramy Model operacyjny, to wizja sposobu działania firmy Architektura korporacyjna przekłada tę wizję w rzeczywistość WdraŜając model operacyjny za pomocą AK firma skupia się bardziej na doskonaleniu procesów opisanych w AK niŝ na samych strategiach 44

45 WDRAśANIE MODELU OPERACYJNEGO ZA POMOCĄ ARCHITEKTURY KORPORACYJNEJ Przedstawione tutaj koncepcje wywodzą się z badań przeprowadzonych przez MIT CISR - MIT Sloan School of Management Center for Information Systems Research ( Badania zostały przeprowadzone w latach i polegały na analizie architektury ponad 200 przedsiębiorstw w ponad 20 krajach w USA i Europie 45

46 Podejście do wdraŝania modelu operacyjnego za pomocą AK Podejścia do wdraŝania modelu operacyjnego - Wielki Wybuch - wdraŝanie projekt po projekcie Wielki Wybuch - uzasadniony w czasach kryzysu lub burzliwych przemian - szybka transformacja w celu zapewnienia przetrwania 46

47 Podejście do wdraŝania modelu operacyjnego za pomocą AK Podejścia do wdraŝania modelu operacyjnego - Wielki Wybuch - wdraŝanie projekt po projekcie Wielki Wybuch - uzasadniony w czasach kryzysu lub burzliwych przemian - szybka transformacja w celu zapewnienia przetrwania WdraŜanie projekt po projekcie: - kaŝdy projekt realizuje doraźne wymagania biznesowe - oraz rozwija umiejętności opisane w architekturze korporacyjnej - np. w proporcji 50 / 50 W ten sposób: - wdraŝanie modelu operacyjnego rozkładamy na wiele drobniejszych projektów - obniŝamy koszty i ryzyko wdraŝania modelu 47

48 WdraŜanie modelu operacyjnego projekt po projekcie Samo zdefiniowanie modelu operacyjnego oraz architektury korporacyjnej nie spowoduje, Ŝe wszyscy w firmie będą codziennie wiosłować w jednym kierunku Niezbędne jest wdroŝenie dodatkowych mechanizmów zapewniających stosowanie architektury korporacyjnej w kaŝdym projekcie tak: - aby kaŝdy projekt biznesowy polepszał dopasowanie aktualnego sposobu działania firmy do wymagań AK - aby kaŝdy projekt IT polepszał dopasowanie istniejące architektury IT do wymagań architektury korporacyjnej Model operacyjny (JAK) Strategia, Inicjatywy strategiczne (CO) określa ramy Architektura korporacyjna (JAK) Mechanizmy zapewniające dopasowanie do AK Procesy Dane Aplikacje Infrastruktura Zdolności firmy 48

49 Rozwiązanie: model współpracy z IT Model współpracy IT, to system mechanizmów nadzoru, który zapewnia, Ŝe projekty technologiczne i biznesowe realizują zarówno cele lokalne jak i ogólnofirmowe Bez modelu współpracy z IT: - liderzy projektów wybierają rozwiązania zaspokajające lokalne potrzeby - ignorują ogólnofirmowy cel integracji i standaryzacji działań przedsiębiorstwa 49

50 Rozwiązanie: model współpracy z IT Model współpracy IT, to system mechanizmów nadzoru, który zapewnia, Ŝe projekty technologiczne i biznesowe realizują zarówno cele lokalne jak i ogólnofirmowe Bez modelu współpracy z IT: - liderzy projektów wybierają rozwiązania zaspokajające lokalne potrzeby - ignorują ogólnofirmowy cel integracji i standaryzacji działań przedsiębiorstwa Na model współpracy z IT składają się: - ogólnofirmowy ład informatyczny: - struktura odpowiedzialności i uprawnień co do decyzji w sprawach inwestycji i wykorzystania IT - mechanizmy scalające: - procesy i gremia decyzyjne, które porządkują inicjatywy i scalają działania na poziomie projektu z ogólnym ładem informatycznym - zarządzanie projektami: - formalna metodyka realizacji projektów z wymogami i kontrolą 50

51 Model współpracy z IT: ład informatyczny Ład informatyczny, to struktura odpowiedzialności i uprawnień do decyzji w sprawach inwestycji i wykorzystania IT Wywodzi się z ładu korporacyjnego 51

52 Model współpracy z IT: ład informatyczny Ład informatyczny, to struktura odpowiedzialności i uprawnień do decyzji w sprawach inwestycji i wykorzystania IT Wywodzi się z ładu korporacyjnego Składa się z pięciu obszarów podejmowania decyzji w sprawach IT: - Decyzje co do zasad IT - jaką rolę technologia informatyczna będzie odrywać w strategii biznesowej - Decyzje co do architektury korporacyjnej przedsiębiorstwa - jakie będzie zorganizowanie procesów biznesowych i technologii IT - Decyzje co do infrastruktury IT - jakie będą centralnie koordynowane, współdzielone usługi technologiczne - Decyzje co do potrzeb aplikacji biznesowych (wymagania) - jakie będą wymagania stawiane aplikacjom biznesowym - Decyzje co do inwestycji i ich priorytetów - ile i w co inwestować Przedsiębiorstwa ze skutecznym ładem informatycznym osiągają zyski 20% wyŝsze od innych, realizujących podobne strategie 52

53 Model współpracy z IT: zarządzanie projektami Zarządzanie projektami: formalna metodyka realizacji projektów, stawiająca projektom jasne wymagania i stosująca regularne kontrole ich spełnienia Dobra metodyka zawiera sprecyzowane kroki oraz kryteria, których spełnianie podlega kontroli Celem jest zapewnienie, aby kaŝdy projekt w zaplanowanym czasie i budŝecie dostarczał zaplanowane wyniki lub został przerwany, jeśli nie jest w stanie tego zrobić 53

54 Model współpracy z IT: mechanizmy scalające Mechanizmy scalające łączą ogólnofirmowy ład informatyczny z projektami Dzięki nim projekty udoskonalają wymagane umiejętności firmy opisane w architekturze korporacyjnej wdraŝając wymagany model operacyjny 54

55 Model współpracy z IT: mechanizmy scalające Mechanizmy scalające łączą ogólnofirmowy ład informatyczny z projektami Dzięki nim projekty udoskonalają wymagane umiejętności firmy opisane w architekturze korporacyjnej wdraŝając wymagany model operacyjny Biznesowe mechanizmy scalające dbają, aby cele projektu zgadzały się z celami biznesowymi równieŝ w zakresie standaryzacji i integracji procesów Architektoniczne mechanizmy scalające odpowiadają za standardy architektoniczne i oceniają projekty na zgodność z nimi Uzgadniające mechanizmy scalające zapewniają komunikację pomiędzy Biznesem a IT źródło: J.W.Ross, P.Weil, D.C.Robertson, Architektura Korporacyjna jako strategia, 2010, wyd. Studio Emka 55

56 Model współpracy z IT: przykłady mechanizmów scalających Biznesowe mechanizmy scalające: - typowanie projektów priorytetowych - rozwijających architekturę - biznesowi sponsorzy projektów - zaangaŝowanie na wczesnych etapach ludzi dbających o cele ogólnofirmowe, równieŝ dot. integracji i standaryzacji procesów - regularne oceny projektów prowadzone z poziomu centralnego, równieŝ dot. integracji i standaryzacji procesów - powdroŝeniowa ocena zgodności z celami, równieŝ dot. integracji i standaryzacji procesów - premie i bodźce motywacyjne powiązane z celami firmy, równieŝ dot. integracji i standaryzacji procesów - właściciele procesów 56

57 Model współpracy z IT: przykłady mechanizmów scalających Biznesowe mechanizmy scalające: - typowanie projektów priorytetowych - rozwijających architekturę - biznesowi sponsorzy projektów - zaangaŝowanie na wczesnych etapach ludzi dbających o cele ogólnofirmowe, równieŝ dot. integracji i standaryzacji procesów - regularne oceny projektów prowadzone z poziomu centralnego, równieŝ dot. integracji i standaryzacji procesów - powdroŝeniowa ocena zgodności z celami, równieŝ dot. integracji i standaryzacji procesów - premie i bodźce motywacyjne powiązane z celami firmy, równieŝ dot. integracji i standaryzacji procesów - właściciele procesów Architektoniczne mechanizmy scalające: - architekcie zespołach realizujących projekty - zarządzanie wyjątkami w architekturze - szkolenia architektów - finansowanie i realizacja zaleŝna od zgodności z architekturą korporacyjną 57

58 Model współpracy z IT: przykłady mechanizmów scalających Biznesowe mechanizmy scalające: - typowanie projektów priorytetowych - rozwijających architekturę - biznesowi sponsorzy projektów - zaangaŝowanie na wczesnych etapach ludzi dbających o cele ogólnofirmowe, równieŝ dot. integracji i standaryzacji procesów - regularne oceny projektów prowadzone z poziomu centralnego, równieŝ dot. integracji i standaryzacji procesów - powdroŝeniowa ocena zgodności z celami, równieŝ dot. integracji i standaryzacji procesów - premie i bodźce motywacyjne powiązane z celami firmy, równieŝ dot. integracji i standaryzacji procesów - właściciele procesów Uzgadniające mechanizmy scalające: - menedŝerowi relacji IT - Biznes - biuro zarządzania projektami - szkolenia menedŝerów projektów Architektoniczne mechanizmy scalające: - architekcie zespołach realizujących projekty - zarządzanie wyjątkami w architekturze - szkolenia architektów - finansowanie i realizacja zaleŝna od zgodności z architekturą korporacyjną 58

59 Tak powinna wyglądać ciągła budowa fundamentu działalności firmy JAK CO Model operacyjny definiuje wymogi precyzuje ograniczenia Architektura korporacyjna Strategia, Inicjatywy strategiczne definiuje umiejętności uaktualnia i zmienia architekturę ustala priorytety WdroŜony model współpracy z IT ład informatyczny, zarz. projektami, mech. scalające nauka i wykorzystywanie buduje umiejętności Procesy Dane Aplikacje Infrastruktura FUNDAMENT DZIAŁALNOŚCI FIRMY Chodzi o inwestowanie nie duŝo, lecz mądrze = z poŝytkiem dla całej firmy 59

60 POZIOMY DOJRZAŁOŚCI WYKORZYSTYWANIA ARCHITEKTURY KORPORACYJNEJ Przedstawione tutaj koncepcje wywodzą się z badań przeprowadzonych przez MIT CISR - MIT Sloan School of Management Center for Information Systems Research ( Badania zostały przeprowadzone w latach i polegały na analizie architektury ponad 200 przedsiębiorstw w ponad 20 krajach w USA i Europie 60

61 Poziomy dojrzałości architektury przedsiębiorstwa Wg badań MIT CISR: KaŜde rozwijające się przedsiębiorstwo przechodzi przez cztery poziomy dojrzałości architektonicznej: - Architektura Silosów Biznesowych - Architektura Standaryzacji Technologii - Architektura Optymalizacji Działalności Podstawowej - Architektura Modularności Biznesu Korzyści ze wzrostu dojrzałości: - niŝsze nakłady na technologie IT - krótsze czasy rozwoju systemów IT - więcej korzyści strategicznych osiąganych dzięki IT 61

62 Poziom 1: Architektura Silosów Biznesowych Charakterystyka: - Standaryzacja: brak - Inwestowanie w IT: rozwiązywanie problemów i wspieraniu działań definiowanych lokalnie - Uzasadnienie inwestycji w IT: przewidywalna i mierzalna redukcja lokalnych kosztów operacyjnych przedsiębiorstwa Pion A Pion B Pion C Pion D Infrastruktura sieciowa Dane Aplikacje Platformy technolog. źródło: J.W.Ross, P.Weil, D.C.Robertson Efekty: - (+) Budowane aplikacje są bardzo dobrze dopasowane do lokalnych potrzeb - (-) NamnoŜenie technologii - (-) NamnoŜenie aplikacji często powielających swoje funkcjonalności - (-) Aplikacje nie potrafią ze sobą współpracować - (-) Buduje się integracje punkt-punkt powstaje spaghetti integracyjne i wprowadzenie nawet najdrobniejszej zmiany staje się kosztowne i czasochłonne Uwagi: - 100% władzy nad decyzjami biznesowymi i technologicznymi w jednostkach lokalnych - Redukcja lokalnych kosztów operacyjnych jest waŝniejsza niŝ problem niekompatybilności systemów i technologii 62

63 Poziom 2: Architektura Standaryzacji Technologii Charakterystyka: - Standaryzacja: wykorzystywane technologie - Inwestowanie w IT: najlepsze rozwiązania w ramach posiadanych platform technologicznych - Uzasadnienie inwestycji w IT: redukcja nakładów na IT Pion A Pion B Pion C Pion D Standardowe platformy technologiczne Infrastruktura sieciowa Efekty: - (+) Redukcja ryzyka technologicznego, - (+) Poprawa obsługi uŝytkowników technologii, - (+) Poprawa bezpieczeństwa i niezawodności technologii - (+) ObniŜenie nakładów na zakup i utrzymanie infrastruktury IT w przedsiębiorstwie - (-) Ograniczenie elastyczności budowy systemów w obszarze wykorzystywanych technologii źródło: opracowanie własne Uwagi: - 80% władzy nad decyzjami biznesowymi i technologicznymi w jednostkach lokalnych - Nie jest rozwiązany problem niekompatybilności i rozproszenia danych w aplikacjach Dane Aplikacje Platformy technolog. 63

64 Poziom 3: Optymalizacja Działalności Podstawowej Charakterystyka: - Standaryzacja: procesów i systemów firmy - Inwestowanie w IT: - Eliminacja redundancji - Ogólnofirmowe systemy współdzielące dane - Uzasadnienie inwestycji w IT: obniŝanie kosztów operacyjnych i podnoszenie jakości działań Pion A Pion B Pion C Pion D Standardowe platformy technologiczne Infrastruktura sieciowa Dane Aplikacje Platformy technolog. źródło: opracowanie własne Efekty: - (+) Komputeryzacja podstawowych procesów biznesowych - (+) ReuŜycie danych i procesów szybsze wdraŝanie nowych produktów i usług - (-) Zmiana tych procesów lub struktur danych sprawia duŝe trudności - (-) Mała elastyczność lokalna - rozwiązania lokalnie lepsze przegrywają ze standardowymi Uwagi: - Optymalizacja procesów podstawowych, to ogromne wyzwanie - Trzeba określić model operacyjny na róŝnych poziomach i konsekwentnie go stosować - Ogranicza to wpływ menadŝerów lokalnych jednostek biznesowych na: - kształt procesów - kształt budowanych rozwiązań IT - Tylko 10% władzy nad decyzjami biznesowymi i technolog. w jednostkach lokalnych 64

65 Poziom 4: Architektura Modularności Biznesu Charakterystyka: - Standaryzacja: interfejsów modułów biznesowych - Inwestowanie w IT: - skomputeryzowane procesy dzielone na moduły - moduły biznesowe luźno powiązane - moduły łatwo reuŝywalne - moduły mogą być indywidualizowane w ramach standardów technologicznych i procesowych - Uzasadnienie inwestycji w IT: zwinność firmy Efekty: - (+) Poprawa elastyczności lokalnej oraz globalnej - (+) Poprawa zwinności całego przedsiębiorstwa Orkiestracja Infrastruktura sieciowa źródło: opracowanie własne Uwagi: - Działalność staje się bardziej spójna - UmoŜliwia osiąganie lepszej wydajności - Nie przeszkadza w lokalnej indywidualizacji procesów 65

66 Poziomy dojrzałości architektoniczej przedsiębiorstwa Poziom dojrzałości architektonicznej 1. Silosy Biznesowe 2. Standaryzacja Technologii 3. Optymalizacja Działalności Podstawowej 4. Modularność Biznesu Charakterystyka Optymalizacja i zaspokajanie lokalnych potrzeb jednostek biznesowych ReuŜycie technologii ReuŜycie procesów biznesowych i aplikacji Luźno ze sobą powiązane, reuŝywalne komponenty procesów biznesowych Standaryzacja Brak Standardów technologicznych Procesów biznesowych, danych i aplikacji Interfejsów modułów biznesowych Cele gospodarcze Zmniejszenie lokalnych kosztów operacyjnych Redukcja kosztów na IT ObniŜanie kosztów operacyjnych i podnoszenie jakości działań Zwinność firmy Priorytety inwestycji w IT Lokalne aplikacje Wspólne usługi infrastruktury Aplikacje ogólnofirmowe Komponenty wielokrotnego uŝytku Wyzwania zarządcze Zarządzanie zmianami moŝliwymi dzięki IT Projektowanie standardów, finansowanie wspólnej obsługi Definiowanie i pomiar najwaŝniejszych procesów firmy Zarządzanie reuŝywalnymi procesami biznesowymi Wyzwania przez Governance em IT Pomiar i przedstawienie wartości dodanej Określenie i stosowanie standardów technologicznych Dopasowywanie priorytetów projektów do architektury firmy Definiowanie i konsolidowanie modułów biznesowych źródło: J.W.Ross, P.Weil, D.C.Robertson, Architektura Korporacyjna jako strategia, wyd. Studio Emka, 2010 Wzrost dojrzałości architektury przedsiębiorstwa = przechodzenie od optymalizacji w skali lokalnej do optymalizacji w skali globalnej 66

67 Zmiany w elastyczności organizacji na poszczególnych poziomach dojrzałości architektury przedsiębiorstwa Stopień zwinności NISKI WYSOKI Elastyczność na szczeblu globalnym Elastyczność na szczeblu lokalnym źródło: J.W.Ross, Forget Strategy: Focus IT on Your Operating Model,

68 Korzyści ze wzrostu dojrzałości architektonicznej (1/2) Redukcja nakładów na technologie IT - zmniejszenie kosztów operacyjnych świadczenia a w tym utrzymania usług IT - zmniejszenie kosztów i czasu wprowadzania zmian w aplikacjach Całkowite koszty na IT w organizacji maleją dzięki inwestowaniu we współdzielone moŝliwości IT wielokrotnego uŝytku - wzrost budŝetu centralnego równowaŝą spadki wydatków lokalnych Powody: niektóre koszty działalności operacyjnej przeniesione do IT wyŝsze koszty z racji pionierstwa firmy mogą inwestować i inwestują w awangardowe innowacje źródło: J.W.Ross, Forget Strategy: Focus IT on Your Operating Model,

69 Korzyści ze wzrostu dojrzałości architektonicznej (2/2) Wzrost zdolności reagowania IT (skrócenie czasu) - pojawia się na drugim poziomie dojrzałości dzięki reuŝyciu technologii - na poziomie trzecim słabo obserwowalny - IT tworzy i rozwija duŝe aplikacje ogólnofirmowe - poprawia się ponownie na poziomie czwartym dzięki wielokrotnemu wykorzystaniu mniejszych modułów (średnio o 37%) Poprawa zarządzania ryzykiem - poprawa zabezpieczeń przed wirusami i nieuprawnionym dostępem do danych (poziom 2) - poprawa ryzyka gospodarczego w obszarach, w których poprawia się spójność i niezawodność systemów (poziom 3) - podniesienie tolerancji na kryzysy gospodarcze i katastrofy naturalne Wzrost satysfakcji z IT kierownictwa nie związanego z IT - satysfakcja - uczucie subiektywne - ma wpływ na zaangaŝowanie w doskonalenie architektury przedsiębiorstwa - miara satysfakcji = na ile dyrektorzy nie związani z IT wierzą w zdolność IT do tworzenia wartości gospodarczej W sytuacji idealnej zanika podział pomiędzy sprawami biznesu a IT Poprawa strategicznych wyników gospodarczych osiągana dzięki ułatwianiu realizacji celów strategicznych - poprawa sprawności organizacyjnej: niŝsze koszty, przewidywalność działań (poziom 2) - poprawa pozycji produktów dzięki szybszemu wchodzeniu na rynek (poziom 2, 3) - zacieśnienie relacji z klientami dzięki lepszej wiedzy o nich a przez to lepszej ich obsługi (poziom 3) - poprawa zwinność przy realizacji strategii - zdolność do szybkiego reagowania na inicjatywy konkurentów i okazje rynkowe (poziom 4) 69

70 5. dojrzałości architektonicznej: Dynamiczne Przedsięwzięcie Charakterystyka: - Standaryzacja: interfejsów firm - Inwestowanie w IT: moduły biznesowe róŝnych firm łączą się automatycznie w celu obsłuŝenia okazji rynkowej - Uzasadnienie inwestycji w IT: zwrot z inwestycji w nowe przedsięwzięcia biznesowe Efekty: - (+) Poprawa elastyczności budowy całego łańcucha dostaw Zapowiedzią dynamicznych przedsięwzięć mogą być: - interfejsy do usług firmy UPS wbudowane w SAP a - market place y Amazon a, Apple a i Androida - usługi Telco freeconet.pl - operator VoIP, który dobiera dostawcę kaŝdego połączenia telefonicznego na podstawie ceny 70

71 ZAKOŃCZENIE 71

72 Symptomy nieefektywności obserwowane od strony Biznesu Na jedno pytanie klienta padają róŝne odpowiedzi (rework) Nowe przepisy i regulacje nastręczają duŝo pracy (~15% i nie spada) Zwinność sprawia trudności a inicjatywy nakierowane na wzrost nie przynoszą zysków ( % obrotu) IT nie przestaje być wąskim gardłem (<12m) RóŜne procesy i systemy powielają te same czynności (nie spada) Brak dostępu do informacji potrzebnych przy podejmowaniu decyzji (trafne wybory) Pracownicy przerzucają dane z systemu do systemu (19/23% - 50/55%; nie spada) Generalna dyrekcja boi się lub nie chce rozmawiać o planach wdraŝania IT (<3,5p) Biznes nie wie, czy technologie informatyczne wnoszą wartość do firmy (<1/3 zna AK) Co najmniej jedna oznaka sygnalizuje brak solidnego fundamentu działalności firmy źródło: J.W.Ross, P.Weil, D.C.Robertson, Architektura Korporacyjna jako strategia,