Optymalizacja IT. Idee na czas zmiany

Transkrypt

1 Optymalizacja IT Idee na czas zmiany 1

2 Spis treści Optymalizacja projekt nie tylko kryzysowy Robert Jesionek Optymalizacja w IT Witold Kilijański Jaka powinna być architektura IT? Marek Wiśniewski Czy grozi nam terror benczmarków? Andrzej Jarosz Odcienie optymalizacji IT Łukasz Piątkowski Telekomy, to nie samotne wyspy Agnieszka Zalewska-Sawicka, Rafał Pisz, Krzysztof Przybylski Informacjom na ratunek Paweł Wróblewski Cięcie kosztów w gospodarce opartej na wiedzy Tomasz Jaworski IT jest kosztem Tomasz Kozłowski Dojrzałość informacyjna organizacji jako narzędzie wspierające zmiany strategiczne Mariusz Rafało Optymalizacja procesów jako kierunek minimalizacji skutków kryzysu Krzysztof Bernacki Między transformacją roli informatyki, a ewolucją roli menadżera IT Józef Wacnik Podróż w chmury Marek Godala Mocnym słowem o CIO Rozmowa z Tomaszem Mnichem Światowy kryzys finansowy był jak odpływ pokazał kto pływał nago. Rozmowa z Anną Wicha

3 Optymalizacja projekt nie tylko kryzysowy Według różnych źródeł, około 75 procent przedsiębiorstw w Polsce przechodzi właśnie proces optymalizacji swoich kosztów. Pozostałe firmy deklarują, że taki projekt przeprowadzi w ciągu najbliższych dwunastu miesięcy. Wyniki takie nie są właściwe dzisiejszemu, krótkiemu momentowi w historii gospodarki. To raczej cyfry, które obrazują pewien trend, właściwy czasom nazywanym trudnymi, kryzysowymi, czy też podlegającymi gospodarczemu spowolnieniu. Firma, która podejmuje się takich zmian, z całą pewnością ma świadomość, że aby przetrwać na trudnym rynku, konieczne są pewne wyrzeczenia przypisywane właśnie optymalizacji kosztów. Czy jednak szukając takiej racjonalizacji można mówić i myśleć wyłącznie o trudach, cięciach i oszczędnościach? Doświadczeni menedżerowie są przekonani, że nie. W trudnych realiach rynkowych firmy nadal muszą mieć możliwości konkurencyjnego działania i różnicowania względem innych organizacji. Dlatego w procesie zmian i optymalizacji, nie przestaje być istotny także element rozwoju i inwestycji. Może to się wydawać tym bardziej skomplikowane, że pieniądze na inwestycje są przecież z każdej strony oglądane po wielokroć. Różnorakie badania, do których można dotrzeć na polskim rynku pokazują, że ponad połowa firm deklaruje, iż redukcja kosztów powinna być wdrażana na bieżąco, co roku. Niestety, tylko 1/3 menedżerów realizuje te założenia. Zarządzający swoimi organizacjami, którzy zaniechali takich działań mogą tego żałować, bo niemal połowa ankietowanych w różnych badaniach przyznaje, że w wyniku realizowanej optymalizacji kosztów udało im się osiągnąć oszczędności na poziomie 5-10%. Trzeba też podkreślić, że wyniki te mogłyby być lepsze, gdyby program optymalizacji został przeprowadzony w sposób bardziej konsekwentny. Dowodem tego są wypowiedzi menedżerów potwierdzających oszczędność ich firm nawet na poziomie wyższym niż 20%. Trzeba też mieć świadomość, że w procesie optymalizacji każda organizacja natrafia na bariery. Te najczęściej spotykane to przede wszystkim brak wsparcia ze strony zarządu, opór związków zawodowych, nieprofesjonalnie przygotowany program optymalizacji, czy w końcu zła komunikacja w procesie zmian. Ta ostatnia kwestia bywa często powodem wielu nieporozumień, z których lęk pracowników, a w rezultacie ich częste odchodzenie (uciekanie) z firmy do organizacji konkurencyjnych, bywa najbardziej bolesnym skutkiem niedoinformowania załogi w zakresie tego, co dzieje się w firmie. Można by tego uniknąć, edukując ludzi w firmie i tłumacząc, że optymalizacja kosztów wcale nie musi być odpowiedzią na spadek zyskowności firmy i jej kłopoty finansowe. Praktyka pokazuje przecież, że proces zmian może mieć i bardzo często ma charakter proaktywny, potwierdzający strategiczne plany kadry zarządzającej. W procesie optymalizacji kosztów nie można zapomnieć o motywowaniu pracowników. Organizacje, które wdrażają takie programy w ogromnej większości potwierdzają ich skuteczność (75%), a część badanych (19%) mówi nawet o wynikach przekraczających założone cele. Obszar IT jest szczególnie wrażliwy na wahania rynku. To niestety część firmy postrzegana często jako źródło kosztów. Dlatego, gdy CEO szuka oszczędności, to oczekuje że odnajdzie je właśnie w strukturach IT. Rolą CIO jest odpowiedzieć na te oczekiwania. Czyli przeprowadzić zmianę, wiodącą do optymalizacji funkcjonowania obszaru IT. Najczęściej dotyczy to trzech obszarów: architektury, modelu operacyjnego i zespołu ludzi. Publikacja pt. Optymalizacja IT. Idee na czas zmiany. chce zaproponować polskiemu CIO rozsądne opcje na czas restrukturyzacji i szukania oszczędności. redaktor publikacji 3

4 Optymalizacja w IT Witold Kilijański, Controlling Systems Na początek lapsus. Przygotowując się do napisania tego artykułu, zacząłem wypisywać sobie różne słowa klucze, pojęcia, luźne myśli, z których chciałbym skorzystać. Było wśród nich Cięcie kosztów. WORD, który jak zwykle chce być mądrzejszy ode mnie, zamienił to na Ciecie kosztów. Pomyślałem sobie, że może tym razem ma rację? Może rzeczywiście sporą część pomysłów na Cięcie kosztów wymyślają tacy Ciecie kosztów?... Chyba coś w tym jest. Zacznijmy od definicji kosztu. Nie podręcznikowej, tylko controllingowej. Kosztem według controllerów jest to, za co chce zapłacić Klient. Wszystko inne jest inwestycją (czyli Klient może będzie chciał zapłacić za jej efekty w przyszłości), lub naszą fanaberią, luksusem (za który Klient nie chce zapłacić). Tu musimy się dobrze zrozumieć Klient czasem jest skłonny zapłacić i to sporo za SWÓJ LUKSUS, nie za NASZ. Oczywiście, idealnie jest, gdy luksus Klienta jest też naszym luksusem (stąd wynika szczęśliwość właścicieli np. renomowanych kancelarii prawnych po 200 EURO za godzinę ) Skoro zatem Klient chce zapłacić za koszty, to złym podejściem jest ich redukowanie! To jest podejście Ciecia kosztów, nie controllera. Warto mieć jak największe koszty, bo wtedy Klient zapłaci więcej pod warunkiem, że: a) Klient się na to zgodzi b) znajdziemy odpowiednio dużo Klientów. Tylko chodzi o koszty rozumiane controllingowo. I tu zaczyna się sztuka oddzielania kosztów od inwestycji (które można rozważyć) oraz luksusów (które niestety trzeba minimalizować). Może to jest właśnie poprawna definicja optymalizacji kosztów? Rozpatrzmy kierując się powyższą logiką kilka zagadnień z mojego podwórka. Na co dzień rozwijamy i wdrażamy narzędzia controllingowe, nomen omen służące właśnie optymalizacji kosztów. Popatrzmy, które aspekty IT są kosztami (chcą za nie płacić Klienci), inwestycjami (może kiedyś będą chcieli zapłacić za ich efekty), a które luksusami (nie chcą za nie płacić). Infrastruktura sprzętowa w większości przypadków wprost Klienci nie chcą za nią płacić, bezpośrednio się z nią nie stykają. Z drugiej strony Klienci wymagają szybkiej obsługi, sprawnego załatwiania spraw, nie życzą sobie, byśmy gubili informacje itp. ale wprost z infrastrukturą stykają się tylko w niektórych branżach/ obszarach (np. na naszej stronie www, serwisie Home-bankingowym, kasowym, czy podczas przyjmowania zamówienia/wystawiania faktury). Jeśli czekają wtedy zbyt długo, bardzo się złoszczą i odchodzą do konkurencji. Pamiętacie Państwo początki portalu Jednym z głównych ich problemów były wtedy zbyt słabe serwery, co bardzo obniżało poziom zadowolenia użytkowników. Generalnie, możemy więc na infrastrukturę popatrzeć jak na inwestycję (i oceniać jak inwestycję czyli jak uzyskać maksymalny efekt wydajnościowy i jakościowy przy minimalnym nakładzie), w pewnych aspektach (tam gdzie bezpośrednio pracują z nią nasi Klienci) jako koszt, z małymi wyjątkami (w jakże wielu firmach najbardziej wypasionego laptopa ma prezes i korzysta z niego w bardzo ograniczonym zakresie!) jako luksus. Zauważmy, że kryteriami rozpatrywania INWESTYCJI bardzo rzadko są takie elementy, jak np. marka Dostawcy, czy relacje z nim (a jego referencje, warunki serwisowe oraz parametry techniczne tego co dostarcza i owszem). Obsługa informatyczna procesów wewnętrznych (poczta, ewidencja finansowo księgowa, systemy pracy grupowej, wewnętrzne raportowanie, budżetowanie itp.) podobnie jak z infrastrukturą sprzętową jeśli Klient nie korzysta z tych narzędzi bezpośrednio, jest to w najlepszym przypadku 4

5 inwestycja w przyszłą, lepszą obsługę Klienta (np. skrócenie cykli logistycznych, zmniejszenie liczby reklamacji, lub szybszą ich obsługę, większą dostępność naszych produktów i usług, obniżenie cen itp.). Dla Klienta jest wszystko jedno, czy wystawiamy mu fakturę przygotowaną w EXCELU, czy też wygenerowaną z systemu ERP za kilka milionów złotych. Ważne, aby dostał to co chce, za dobrą cenę i w krótkim czasie. Co innego, gdy Klient sam korzysta z naszych systemów (np. sam wprowadza zamówienia w sklepie internetowym, korzysta z naszych usług w chmurze, czy też sam się obsługuje w systemie rezerwacyjnym, Home-bankingowym itp. Zapewnienie mu takiego narzędzia jest wówczas dla naszej Firmy kosztem, za który jest skłonny zapłacić choć wielu dostawców (np. linie lotnicze) zdecydowanie nadużywa tego faktu, żądając wysokich opłat za samoobsługowe przygotowanie biletu, płatność kartą itp. A czy Klient chce zapłacić za pracę naszych controllerów, związaną z przygotowaniem miesięcznych raportów? Albo za nasze planowanie budżetu? Raczej nie, no może w bardzo ograniczonym zakresie są to inwestycje w to, że Nasza Firma przetrwa i będzie mogła się rozwijać. Tak czy owak, to bardzo dalekie skojarzenie. Z drugiej strony, reguły prowadzenia biznesu wymagają wykonywania tego typu luksusowych działań. Co zatem robić z obsługą takich procesów, jak raportowanie, budżetowanie, księgowość, kadry, płace itp.? Odpowiedź znana jest od dawna w możliwie dużym zakresie automatyzować. Niepostrzeżenie w ostatnich latach bardzo dużo się w tym zakresie zmieniło. Zaczynałem swoją karierę zawodową w 1995 roku, w 46-osobowej firmie produkującej i wdrażającej oprogramowanie finansowo księgowe. Z tych 46 osób, 3 panie zajmowały się księgowością, kadrami i płacami. Jedna z nich CODZIENNIE RANO szła do banku, aby odebrać wyciągi i zanieść przelewy Dziś jestem szefem niemal 40-osobowej firmy, gdzie cała obsługa księgowo kadrowo płacowa odbywa się siłami JEDNEJ osoby (i to nie na pełnym etacie). A jakość informacji zarządczych jest nieporównanie lepsza częściowo dzięki temu, że sami jesteśmy swoimi Klientami i wdrożyliśmy nasze rozwiązanie controllingowe u siebie :). Skoro tak mocno wzrosła wydajność procesów ewidencyjnych, to co stoi na przeszkodzie podobnej automatyzacji pozostałej części tzw. Back Office? W wielu organizacjach taką przeszkodą są nieustabilizowane reguły. Obsługę księgowości, czy kadr definiują przepisy dokładnie wiadomo, jak mają wyglądać informacje wejściowe i wyjściowe oraz cały proces ich przetwarzania. Obsługą poczty elektronicznej, czy sieci technologia. Dokładnie wiadomo, jak ma wyglądać konfiguracja skrzynki pocztowej, czy konta użytkownika sieci, definiowanie uprawnień, zabezpieczeń itp. Musimy podjąć kilka kierunkowych decyzji konfiguracyjnych na początku (np. zdefiniować plan kont, słowniki dokumentów, czy poziom zabezpieczeń poczty elektronicznej), a całą resztę procesu można w miarę szybko zautomatyzować. Nieco inaczej jest z obsługą raportowo budżetowo controllingową. Tutaj reguły ustalamy sami i bardzo często są one zmieniane, dostosowywane do nowych potrzeb informacyjnych kierowników oraz Zarządu. Na ile często generując te potrzeby uświadamiają oni sobie, czy powstaje w ten sposób KOSZT, INWESTYCJA, czy LUKSUS? Śmiem twierdzić, że bardzo rzadko Dobry controller jest w stanie już na etapie dyskusji z managerem (czyli duuuużo wcześniej, niż powstanie z tego jakikolwiek projekt informatyczny) sprawdzić sensowność danego pomysłu i zweryfikować jego pracochłonność. Bardzo dużo ciekawych inicjatyw rynkowych przynoszących dziś niebagatelne przychody miało 5

6 swój początek w analizie danych choćby nowe plany taryfowe w firmach telekomunikacyjnych, czy rozwój dodatkowej oferty sklepów, czy kafejek przy stacjach benzynowych. Jeden z naszych Klientów analizując marże wynikające z obsługi poszczególnych odbiorców i koszty procesów na tę obsługę się składających, był w stanie zwiększyć swoją rentowność na sprzedaży o kilkadziesiąt procent (okazało się, że nie wszyscy wymagali codziennego zatowarowania i wizyty przedstawiciela handlowego, w zamian za drobny rabat zgadzali się na składanie zamówień przez Internet, byli w stanie szybciej opłacać faktury dostając w zamian rabat w formie skonta a ten rabat kosztował mniej niż odsetki od kredytu obrotowego, można było planować trasy i punkty rozładunku samochodów dostarczających towar osobno na każdy dzień, a nie trzymać się sztywnego wahadła czyli z całości naszych kosztów zostawić tylko KOSZTY właściwe, eliminując LUKSUSY). Oczywiście, controller potrzebował narzędzia oraz wiedzy i w tym przypadku jedno i drugie było dobrze pojętą INWESTYCJĄ, skalkulowaną tak, jak każda inwestycja (czyli jak możliwie najmniejszymi nakładami osiągnąć jak najlepsze efekty). Oczywiście, czasem pojawia się problem wielkości opakowania czyli np. uzasadnionym ekonomicznie poziomem kosztu czy inwestycji w Naszej Firmie jest np. korzystanie z usług administratora, controllera, czy księgowego w niepełnym wymiarze czasu, albo tylko na żądanie. Zwykle też nierównomierne jest nasze zapotrzebowanie na zasoby informatyczne spójrzmy na system kadrowo płacowy i serwer na którym on działa. Przez większość miesiąca nic specjalnego tam się nie dzieje, aż przychodzi moment naliczenia listy płac i obciążamy te zasoby bardzo mocno. W takiej sytuacji wyjściem może być outsourcing, lub tzw. source sharing (czyli współdzielenie zasobów) w epoce cloud computing coraz bardziej dostępny. Często spotykam się z pytaniem Czy można i warto zlecić na zewnątrz controlling? Czy aby nie jest to na tyle istotna część naszego biznesu, że nie warto tego robić?. Odpowiedź jest prosta tam, gdzie mamy do czynienia z powtarzalnymi, rutynowymi czynnościami controllingu (np. obsługa raportowania), jak najbardziej można i warto zlecić to wyspecjalizowanemu dostawcy, dysponującemu odpowiednimi narzędziami (lub zautomatyzować w postaci np. kokpitów managerskich). Tam, gdzie pojawia się konieczność posiadania dogłębnej, eksperckiej wiedzy na temat naszego biznesu i szukania możliwości jego optymalizacji trudniej to sobie wyobrazić (choć i wtedy możemy zlecić na zewnątrz całą sferę techniczną jak np. utrzymywanie i rozwój hurtowni danych, konfigurację narzędzi planistycznych, obliczenia itp.) Inną odmianą problemu wielkości opakowania, zwłaszcza w sektorze publicznym, jest konfigurowanie treści zapytań przetargowych. W ostatnim roku zaczyna przybierać to rozmiary plagi coraz częściej dostajemy zaproszenia do przetargów na dostawę np. rozwiązań GIS, systemu BI, oprogramowania do zarządzania placówkami oświatowymi, systemu kart miejskich i pakietu ERP, albo systemu ERP, oprogramowania do obsługi Ruchu Chorych, Hurtowni Danych Medycznych i systemu controllingowego W JEDNYM. Zakres funkcjonalny poszczególnych komponentów jest tak od siebie odległy, że aby je spełnić, powoływane są ad hoc rozmaite konsorcja pod przewodnictwem któregoś z integratorów (którzy za to przewodnictwo kasują kilkadziesiąt procent dodatkowej marży), prawdopodobieństwo sukcesu całego projektu jest bardzo niewielkie, a w całym postępowaniu chodzi chyba głównie o wygodę Działu Zamówień Publicznych w danej organizacji. No bo będą mieli jeden przetarg, a nie kilka i na pewno nikt ich nie oskarży o sztuczne dzielenie zapytań. Ale optymalizacji nie ma w tym żadnej, wręcz przeciwnie 6

7 A integracja? mało jest innych obszarów IT, gdzie można uzyskać podobnej skali korzyści finansowe, gdzie używając małych nakładów można uzyskać naprawdę duże efekty. A jednocześnie zbudować istotną i trwałą przewagę konkurencyjną dla Firmy. Z drugiej strony mało jest obszarów wymagającej tak wysokiego poziomu kompetencji i doświadczenia. I tak wrażliwych na wszelkie zmiany. Szef IT miewa czasem problemy z obsługą wertykalnych potrzeb Użytkowników np. controller potrzebuje narzędzia do budżetowania, serwis do ewidencji zgłoszeń i śledzenia ich obsługi, sprzedaż systemu CRM, marketing narzędzia wspomagającego Web marketing, inżynierowie specjalistycznych narzędzi monitorujących proces technologiczny, księgowość i inne komórki pakietu ERP, prezes i managerowie platformy raportującej i kokpitów managerskich, zbierających dane z różnych źródeł (również tych wymienionych powyżej). Każde z tych rozwiązań pochodzi od wyspecjalizowanego dostawcy, powinny się one ze sobą komunikować, po jakimś czasie schemat połączeń między nimi przypomina sieć pająka A naprawdę niewiele może kosztować projekt organizujący wymianę danych między tymi systemami i prezentujący je w spójny sposób. W epoce narzędzi typu SOA, szyn integrujących i serwisów nasłuchujących jest to naprawdę możliwe. 2 lata temu przeprowadziliśmy przedsięwzięcie CS_SERVICE_ON LINE, polegające na spięciu ze sobą działających u nas systemów MS CRM (czyli bazy danych Klientów), NTR SUPPORT (czyli narzędzia do komunikacji zdalnej między komputerami), naszej strony www, narzędzia generującego wersje instalacyjne dla Klientów i ewidencji czasu pracy. Trwało to kilka miesięcy, kosztowało niewiele, a w efekcie uzyskaliśmy naprawdę bardzo sprawną i wydajną platformę serwisową, która jest dziś naszym podstawowym medium komunikacji z Użytkownikami. Projekt ten pozwolił podnieść wydajność pracy w naszym zespole help desku o kilkadziesiąt procent. W bardzo wielu firmach jest taki potencjał i taka potrzeba, by o tego typu projekcie pomyśleć. Gdzie zatem szukać optymalizacji w IT? Myślę, ze pointą powyższych rozważań powinno być kilka pytań kontrolnych, jakie CIO powinien sobie zadać, takich jak: Które elementy naszych działań są KOSZTEM, INWESTYCJĄ, a które LUKSUSEM w wyżej opisanym rozumieniu? Z których LUKSUSÓW możemy bez żalu zrezygnować? Które z naszych działań wykonujemy Dobrze Od Razu, a które musimy poprawiać? Dlaczego? Ile to kosztuje? Może wynika to z tego, że robimy na tyle rzadko, że nie jesteśmy w stanie utrzymać odpowiednich kompetencji? Może zatem taniej będzie je kupić u specjalistów? Gdzie i co kupujemy w zbyt dużych opakowaniach, czyli nie wykorzystamy posiadanego potencjału? Gdzie występuje redundancja informacji lub czynności, którą możemy usunąć przy pomocy odpowiedniej integracji systemów, lub zmian organizacyjnych? Czy i gdzie jesteśmy w stanie kupować w hurcie, czyli osiągnąć korzyści skali zarówno w zakupie, jak i w eksploatacji? (coraz częściej spotykam się np. ze standaryzacją sprzętu używanego w firmach, ograniczaniem liczby modeli np. laptopów czy telefonów do 2-3 wariantów) Czy koszt naszych działań jest niższy czy wyższy niż koszt porównywalnej usługi, kupowanej na rynku? Jakie są ewentualne dodatkowe ryzyka zlecenia na zewnątrz? 7

8 Czy myśląc o optymalizacji kosztów wystarczająco dbamy o to, co w naszej organizacji jest najcenniejsze czyli WIEDZĘ? (są firmy, które zbyt łatwo pozbyły się jej na zewnątrz) Z jakimi problemami najczęściej przychodzi do nas tzw. biznes? Czy dotyczą one KOSZTÓW (zająć się natychmiast), INWESTYCJI (zająć się po gruntownym przemyśleniu) czy LUKSUSÓW (zająć się tylko, jeśli mamy czas i ochotę)? Czy mamy wystarczająco dużo dystansu do swojej pracy, by na powyższe pytania odpowiedzieć? Jeśli nie, to gdzie znaleźć bezstronnego sparring partnera? Najtrudniejsze z nich jest oczywiście pytanie ostatnie, ale to już temat na zupełnie inny artykuł Witold Kilijański Witold Kilijański, prezes CONTROLLING SYSTEMS, ma 41 lat, jest absolwentem Akademii Ekonomicznej we Wrocławiu (dyplom w 1995 z wyróżnieniem), od 1995 zawodowo zajmuje się oprogramowaniem dla przedsiębiorstw początkowo systemami typu ERP i HR (w latach pracował w TETA SA kolejno jako Handlowiec, Dyrektor ds. Marketingu, Dyrektor ds. Strategii, Członek Zarządu). Od 2002 Prezes i współzałożyciel CONTROLLING SYSTEMS firmy software owej, wyspecjalizowanej w tworzeniu i wdrażaniu rozwiązań informatycznych, wspomagających prowadzenie controllingu i analiz ekonomicznych w przedsiębiorstwie. Klientami CONTROLLING SYSTEMS są takie Firmy, jak np. TORFARM SA, TOYOTA MOTOR MANUFACTURING POLSKA, INCO VERITAS, ENERGETYKA CIEPLNA OPOLSZCZYZNY SA, TVN SA, MPWiK WARSZAWA, czy PWC POLSKA. CONTROLLING SYSTEMS posiada status MICROSOFT GOLD CERTIFIED PARTNER (najwyższy możliwy poziom partnerstwa technologicznego MICOROSOFT, potwierdzający wysokie kompetencje w tworzeniu oprogramowania). Firma przeprowadziła do tej pory z sukcesem ponad 120 wdrożeń swojego rozwiązania systemu EURECA w firmach, działających w całej Europie. Artykuły Witolda Kilijańskiego systematycznie ukazują się w mediach fachowych (przede wszystkim CONTROLLING I RACHUNKOWOŚĆ ZARZĄDCZA), w miarę wolnego czasu prowadzi także zajęcia ze studentami. Jego hobby to narciarstwo, turystyka górska i kajakowa, a przede wszystkim... gotowanie. Jego dewizą jako Prezesa jest primus inter pares twierdzi, że inaczej nie da się zarządzać innowacyjną Firmą. 8

9 Gotowi na innowacje Partner Partner strategiczny Przeczytaj inne publikacje pod redakcją Roberta Jesionka 1 9

10 Jaka powinna być architektura IT? Marek Wiśniewski, CTPartners SA Tradycyjnie termin architektura IT oznacza (zgodnie ze standardem przemysłowym ISO/IEC/ IEEE 42010) fundamentalną organizację systemu IT, wynikającą z jego otoczenia, w tym podstawowe elementy, własności, relacje, a także pryncypia jej projektowania i rozwoju. Już sama ta definicja mówi o tym, jaka powinna być architektura IT. Po pierwsze, powinna wynikać z otoczenia systemu IT, a więc w głównej mierze z oczekiwań jego interesariuszy, a po drugie, powinna być zgodna z ogólnymi zasadami (pryncypiami) projektowania i rozwoju systemów w danej organizacji. Zgodność z oczekiwaniami interesariuszy, w tym użytkowników systemu, jest metodycznie oczywista i sprowadza się do ich poprawnej identyfikacji, określenia ich oczekiwań oraz zgromadzenia i specyfikacji wymagań. W tym celu projektanci systemów informatycznych posługują się perspektywami poszczególnych interesariuszy, tzw. widokami architektonicznymi. Widok architektoniczny jest ujęciem architektury systemu IT z punktu widzenia danego interesariusza. I tak: administratora baz danych interesuje model logiczny danych, integratora systemów interesuje widok specyfikacji interfejsów, a sponsora interesuje widok korzyści, kosztów lub ryzyk. Każda z tych ról posiada własną perspektywę patrzenia na system informatyczny i dla każdej z nich przygotowywany jest oddzielny widok architektoniczny. Z kolei uwzględnienie ogólnych zasad projektowania i rozwoju systemów sprowadza nas do bardziej ogólnego zagadnienia w organizacji wytycznych i zasad dotyczących całości krajobrazu architektonicznego. Zasad które powinny obowiązywać wszystkie dostarczane systemy IT, bez względu na ich lokalną specyfikę funkcjonalną. Opracowaniem i uzgadnianiem w organizacji wspólnych zasad dla architektury systemów IT zajmuje się dyscyplina zarządzania architekturą korporacyjną. Architektura korporacyjna jest tym dla architektury systemów informatycznych, czym urbanistyka, jako nauka o planowaniu i rozwoju miasta, dla architektury poszczególnych budynków na terenie miasta. Głównym kryterium oceny jakości danej architektury IT jest jej zgodność z architekturą korporacyjną, podobnie jak jakość budynku na terenie miasta powinno się oceniać na podstawie zgodności z ogólnie przyjętymi standardami i praktyką urbanistyczną miasta. Ten sam blok wielorodzinny w stylu modernistycznym w zależności od wizji urbanistycznej miasta może spełniać swoją funkcję lub być zupełnie nieadekwatnym i rażąco niszczyć jego układ przestrzenny i funkcjonalny. Architektura korporacyjna jest więc pomostem pomiędzy celami na poziomie strategicznym, a architekturą poszczególnych systemów IT. Dyskusję o jakości architektury systemu IT można więc sprowadzić do jakości architektury korporacyjnej i zgodności z nią, a przede wszystkim do jakości zasad związanych z projektowaniem i rozwojem architektur systemów IT. Z doświadczenia wiem, że powstanie elementów architektury korporacyjnej ma czysto prozaiczny powód. W przypadku prowadzenia wielu projektów IT zwyczajnie się to opłaca przygotowanie dobrych jakościowo wytycznych i zasad postępowania wspólnych dla wielu przedsięwzięć, sumarycznie mniej kosztuje. Jaka zatem powinna być architektura korporacyjna? Najważniejszą przesłanką jakościową architektury korporacyjnej, niezależnie od zastosowanej metodyki, jest jej zgodność z celami biznesowymi, a więc oczekiwaniami interesariuszy organizacji. Efektywne IT wspiera organizację proste, lecz nadal najbardziej prawdziwe. Architektura korporacyjna jest więc narzędziem ukierunkowania architektur na różnym poziomie z celami biznesowymi organizacji. No dobrze, ale co to znaczy? Czy to, że architektura IT powinna 10

11 być tania w wytworzeniu (aspekty finansowe), czy bardziej elastyczna i dążąca do minimalizacji czasu reakcji na potrzeby organizacji (aspekt zdolności biznesowych), czy może po prostu architektura IT powinna wprost przyczyniać się do wzrostu wartości strategicznej organizacji (aspekt wartości)? W celu odpowiedzi na powyższe pytania posłużę się dwoma badaniami. Pierwsze z nich prowadzone jest cyklicznie przez MIT Center for Information Systems Research (CISR) i przedstawia wartość strategiczną IT dla organizacji w zależności od jednego z 4 poziomów dojrzałości architektury korporacyjnej. Business Silos Standardized Technology Optimized Core Business Modularity Standard Interfaces and Business Componentization Locally Optimal Business Solutions Enterprise-Wide Technology Standards Standardized Enterprise Processes/Data Rysunek 1. Wartość strategiczna IT dla organiazacji, w zależności od poziomu dojrzałości architektury korporacyjnej. Źródło: Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, J. Ross, P. Weill, D. Robertson, HBS Press, Każdy z poziomów dojrzałości ma swoje specyficzne właściwości. Pierwszy poziom charakteryzuje się lokalnie optymalizowanymi rozwiązaniami. Marketing, dział HR, ryzyko wszystkie te działy budują własne rozwiązania i stosują standardy oraz metody, które dla nich są optymalne. Drugi poziom dojrzałości związany jest z wprowadzeniem standardów organizacyjnych, np. w zakresie technologii wymiany danych. W tym przypadku, wszystkie powyższe działy tracą część swojej autonomii na rzecz ogólnie przyjętych rozwiązań. Trzeci poziom dojrzałości wprowadza standaryzację na poziomie procesów i danych, a ostatni czwarty poziom celuje w wysoką 11

12 komponentyzację usług IT każdy z nich wymusza jeszcze bardziej posuniętą utratę niezależności. Wybór więc wcale nie jest prosty nie zawsze wyższy poziom dojrzałości jest rozwiązaniem dobrym. Decyzja zależy od właściwości otoczenia biznesowego organizacji, takich jak powtarzalność oraz oczekiwany stopień integracji procesów biznesowych. Różne organizacje potrzebują różnego poziomu dojrzałości architektury korporacyjnej. Dla organizacji charakteryzujących się wysokim poziomem standaryzacji procesów oraz wysokimi wymaganiami związanymi z integracją procesów i danych, odpowiedni będzie czwarty poziom dojrzałości, oznaczający wysoką globalną elastyczność. Przeciwieństwem są organizacje wymagające wysokiej autonomii na poziomie lokalnym. Tam wystarczający jest drugi poziom dojrzałości. Dylemat modelowy jest jeszcze bardziej widoczny, gdy spojrzymy na strukturę kosztów IT, związaną z wprowadzeniem określonego poziomu dojrzałości architektury korporacyjnej. Okazuje się, że początkowo wdrożenie architektury korporacyjnej przynosi korzyści kosztowe, niestety po osiągnięciu pewnego stopnia dojrzałości koszty zaczynają mocno rosnąć. Przyjmując za stan wyjściowy (pierwszy poziom dojrzałości) bazową wartość 100% budżetu IT to w kolejnej, drugiej fazie wartość ta wynosi już 85% tej kwoty, a w trzeciej 75%. Na tym poziomie następuje wartość graniczna. Ostatni, czwarty poziom związany z modularnością oznacza już wzrost budżetu IT do wartości 120% stanu bazowego. Drugim spojrzeniem na zagadnienie jest badanie dotyczące klasyfikacji zmienności rynkowej przeprowadzone przez Infovide-Matrix S.A. Badanie to wprowadza 4 modele zmienności, w zależności od dwóch właściwości otoczenia biznesowego organizacji: częstości oraz skali zmian. Częstość zmian oznacza subiektywną liczbę zmian jak często zmiany mają miejsce. Skala zmian to wielkość pojedynczej zmiany czy jest to zmiana mała z punktu widzenia organizacji, czy też obejmuje swoim zasięgiem np. całość organizacji. Głównym wnioskiem tego badania jest to, że w zależności od modelu, organizacja posiada inne potrzeby w zakresie narzędzi i metodyk IT. Potrzeby te obejmują również architekturę - zarówno na poziomie korporacyjnym, jak i systemów informatycznych. Model ciągłej transformacji (duża częstość i skala zmian) wymaga wysoce elastycznych rozwiązań w obszarze architektonicznym, w związku z tym, dla efektywnego wsparcia biznesu warto ponieść koszt związany z wyższym poziomem dojrzałości architektury korporacyjnej. Czy warto jednakże ten koszt ponosić w przypadku organizacji o cechach modelu usługowego? Moim zdaniem nie warto, przynajmniej bez wyraźnych ku temu przesłanek. Wnioski dla postawionego w tytule pytania są więc niejednoznaczne. Jak pokazałem, nie ma konkretnego typu, modelu, czy poziomu dojrzałości architektury korporacyjnej, który będzie wystarczająco dobry dla wszystkich organizacji. Większość organizacji, które znam potrzebuje przede wszystkim elastyczności. Są to jednak organizacje w przeważającej części spełniające przesłanki organizacji adaptacyjnej. Oczywiście nie są one skore do wzrostu ogólnego poziomu kosztów IT. Praktyka w takich przypadkach pokazuje co jest rzeczywistym priorytetem czy elastyczność IT jest tylko hasłem z pięknie opakowanej Strategii organizacji lub IT, czy rzeczywiście realizowanym celem. Jest jedna branża, która idealnie pasuje do modelu transformacyjnego (szeroko zakrojona aczkolwiek nieczęsta zmiana) to branża publiczna. W tym przypadku dobrym pomysłem jest wykorzystanie techniki zwanej w architekturze korporacyjnej jako mapa drogowa (tzw. roadmapping). 12

13 Dokąd zmierzamy w obszarze zarządzania architekturą IT? Uważam, że po zachwycie różnymi koncepcjami z zakresu architektury (warto tylko wspomnieć takie pojęcia jak SOA, usługi sieciowe, szyna usług, czy architektura korporacyjna bez względu na ograniczenia), nadszedł czas dojrzałego spojrzenia na architekturę. Spojrzenia, w którym jedyną pewną rzeczą jest to, że architektura odpowiada potrzebom związanym z celami biznesowymi organizacji i w zależności od nich, jest to architektura dla każdej organizacji zupełnie inna. Marek Wiśniewski Lider obszaru Architekura i IT Governance w CTPartners SA. Z wykształcenia doktor nauk ekonomicznych obronił pracę z formalnej reprezentacji wiedzy w systemach informacyjnych (ontologie). Specjalista w zakresie projektowania systemów informacyjnych oraz nadzoru zarządczego IT, certyfikowany architekt korporacyjny (TOGAF). Członek licznych organizacji branżowych: The Open Group, PKN, NTIE, ACM. Autor i współautor 27publikacji naukowych z zakresu informatyki ekonomicznej. 13

14 Czy grozi nam terror benczmarków? Andrzej Jarosz, IDC Poland Nie zdajemy sobie do końca sprawy, jak bardzo jesteśmy uzależnieni od różnych wskaźników. Żyjemy w ich świecie w świecie wskaźników, które pozwalają nam przełożyć często bardzo skomplikowaną rzeczywistość na proste liczby, za którymi zwykle kryją się zjawiska i procesy, które rozumieją tylko specjaliści i eksperci z wąsko wyspecjalizowanych dziedzin. Wskaźniki czyta się łatwo, bo tak są zbudowane, ale już trudniej na ich podstawie dokonać właściwej interpretacji rzeczywistości, bo zwykle nie zadajemy sobie trudu, aby tracić czas na zrozumienie, w jaki sposób są skonstruowane, jak się dokonuje ich pomiarów i obliczeń, jakie są ograniczenia ich interpretacji. Dochodzi często do kuriozalnych sytuacji, że autorów i rachmistrzów różnych wskaźników obwinia się za katastrofalny stan rzeczywistości, (czego ostatnio doświadczyły tzw. agencje ratingowe). Być może nieuchronnym skutkiem tej wskaźnikomanii jest malejąca umiejętność trzeźwej oceny rzeczywistości, tzn. im więcej wskaźników używamy, tym mniej staramy się zrozumieć, co się za nimi kryje. Niepokojącym zjawiskiem jest również to, że wskaźnikami, które odzwierciedlają skomplikowane procesy gospodarcze jest łatwo manipulować, co często słychać w debacie publicznej, łatwo ich używać jako argumentów za, a nawet przeciw, bo i tak nikt nie rozumie, co one dokładnie oznaczają. W miarę jak komplikuje się nasze otoczenie, wskaźników przybywa. Jesteśmy zatem skazani na świat wskaźników, które pełnią role drogowskazów i są wręcz niezbędne do podejmowania różnych życiowych decyzji. Nie ma umowy kredytowej, w której nie pojawi się LIBOR lub WIBOR, nie kupimy samochodu bez informacji ile paliwa zużywa na 100 km, żaden podmiot nie wyemituje swoich obligacji bez wskaźników ratingowych. Wiele popularnych wskaźników stało się przedmiotem hazardu, gdyż mają one tą cechę, że ich wartość zmienia się w czasie, a współczesne platformy elektroniczne umożliwiają robienie zakładów, dotyczących tego, jaka będzie wartość danego wskaźnika w przyszłości. Miliony ludzi oraz instytucji na świeci takie zakłady robi codziennie, a wartość tych zakładów przewyższa wielokrotnie wartość wytworzonych światowych dóbr i usług. Oprócz hazardu, do rozwoju wskaźnikomanii przyczyniły się również wszelkiego rodzaju rankingi, które porównują zjawiska zwykle trudno porównywalne. Nie ma dziś wiadomości bez publikacji jakiegoś rankingu konsumpcji, innowacji, biedy czy bogactwa, rozumu lub głupoty. Produkcja nowych wskaźników nie omija również wydawałoby się bardzo konserwatywnych obszarów, jakim do tej pory była sprawozdawczość księgowa. Modele biznesowe współczesnych przedsiębiorstw tak bardzo się skomplikowały, że po to, aby wyjaśnić ich efektywność akcjonariuszom i potencjalnym inwestorom tworzy się masowo nowe mierniki, o czym donosił w jednym z listopadowych numerów The Wall Street Journal. Ile kilogramów IT w przedsiębiorstwie wskaźniki dla technologii informatycznych Skoro nowe wskaźniki coraz szerzej są stosowane w przedsiębiorstwach, nie mogą ominąć technologii informatycznych. IT jest wszechobecne w różnych działach gospodarki oraz w sektorze publicznym, nic więc dziwnego, że funkcjonowanie tego coraz częściej krytycznego zasobu, budzi ogromne zainteresowanie. I nie jest to tylko zainteresowanie jakiejś niszowej grupy informatyków, ale wielu grup decyzyjnych na różnych poziomach organizacji przedsiębiorstwa, które dzięki IT mogą rozwijać nowe produkty, optymalizować 14

15 działania operacyjne, pozyskiwać nowych klientów i partnerów. i struktura zatrudniania w działach IT to kolejna grupa ok. 10 wskaźników. W dzisiejszych czasach, już o ponad pięćdziesięciu procentach wydatków na technologie informatyczne nie decydują działy IT, lecz inne działy przedsiębiorstwa, a prognozy wskazują, że rola decyzyjna w spawach inwestycyjnych działów IT będzie w dalszym ciągu malała. Dlatego też rośnie rola czytelnych mierników, które pozwolą ocenić: Jaki jest wystarczający poziom IT w przedsiębiorstwie? Jaka infrastruktura IT powinna być dostarczona? Jak system IT w przedsiębiorstwie powinien być zaprojektowany? Jaki jest aktualny poziom usług informatycznych w przedsiębiorstwie? W jakim stopniu IT wpływa na budowanie przewagi konkurencyjnej przedsiębiorstwa? Przedmiotem oceny efektywności IT za pomocą różnych wskaźników może być zagregowany, cały obszary funkcjonowania IT lub poszczególne jego elementy jak telekomunikacja, infrastruktura sieciowa, aplikacje, pamięci masowe, serwery. Można też poddawać ocenie za pomocą mierników pewne agregaty zawierające nie tylko elementy technologiczne, jak np. poziom świadczenia usług informatycznych w przedsiębiorstwie, czy też bezpieczeństwo informacji, co znacznie wykracza poza mierniki technologiczne. W powszechnym użyciu jest ok. 100 różnych mierników, które w mniej lub bardziej zagregowany sposób pozycjonują funkcję IT w przedsiębiorstwie. Dla przykładu, do charakterystyki wydatków operacyjnych IT (OPEX) używa się ok. 50 różnych miar, wydatki kapitałowe (CAPEX) opisuje ok. 10 popularnych wskaźników. Koszty osobowe Wielkiej liczbie mierników towarzyszy też swoisty konkurs piękności, który z nich zgrabniej, trafniej, bardziej precyzyjniej pokaże procesy, ukryte zależności lub zjawiska. Ma to ogromne znaczenie, ponieważ interpretacja wskaźników skutkuje różnymi decyzjami, mającymi spowodować lepsze wykorzystanie technologii informatycznych. Te lepsze, zgrabniejsze i mądrzejsze są oczywiście częściej stosowane i publikowane, można więc mówić o modzie na niektóre wskaźniki. Niestety, dla fanów benchamarków jest też zła wiadomość. Korzystanie z nawet najmodniejszych miar nie zwalnia decydentów z umiejętności ich interpretacji. Tu pojawia się wiele dylematów. Jednym z podstawowych jest jakie działania należy podjąć, aby poprawić wartość jakiegoś wskaźnika? Czy bardziej miarodajne są wskaźniki oparte na różnych średnich branżowych, czy też wskaźniki konstruowane na podstawie tzw. dobrych praktyk? Analizując, np. tylko odchylenie od średniej jakiegoś zagregowanego wskaźnika, można podejmować błędne decyzje, ponieważ nie widać realnych przyczyn, dla których nie uzyskuje się pożądanej wartości. Dużo lepsze rezultaty daje budowanie wskaźników na podstawie pogłębionej analizy dobrych praktyk, gdzie lepiej widać słabe punkty funkcjonowania jakiegoś złożonego obszaru. Dla przykładu, analizując tylko niską wartość średniej wskaźnika załatwionych interwencji Help Desku w pierwszym kontakcie, można dojść do wniosku, że poziom wyszkolenia pracowników jest niezadawalający lub, że system IT, którego interwencje dotyczą, jest bardzo złożony i trudno go diagnozować, albo też, że normy nałożone na funkcjonowanie Help Desku są zbyt niskie. W każdym przypadku ocena przyczyny będzie skutkowała innymi rozwiązaniami. 15

16 Wskaźniki kosztów bezpieczeństwa informacji Niestety, świat wskaźników informatyki opisujących relacje świata biznesu i technologii nie jest ani prosty, ani uniwersalny, a przydatny może być tylko wtedy, kiedy potrafimy poszczególne wskaźniki właściwie interpretować. W wielu przypadkach systemy informatyczne pełnią rolę krytyczną w realizacji procesów przedsiębiorstwa, dlatego właściwa ocena nakładów w relacji do uzyskanego poziomu bezpieczeństwa odgrywa zasadnicza rolę. Jednym z popularnych wskaźników jest tzw. zwrot inwestycji w bezpieczeństwo informacji ROSI = {[wartość całkowita strat * % ryzyko wystąpienia] - koszt inwestycji} /koszty inwestycji. Dobór oraz liczenie takich wskaźników jest trudne, ale istnieje wiele dobrych praktyk i wskazówek, jak należy postępować, aby wyliczyć właściwe wartości. Bardzo częsty błąd popełniany przez różnego typu analizy polega na tym, że traktuje się nasycenie technologiami IT w zakresie bezpieczeństwa, jako tożsame z uzyskanym poziomem bezpieczeństwa. Technologia jest tylko środkiem do uzyskania odpowiedniego poziomu bezpieczeństwa informacji w przedsiębiorstwie, a nie celem. Wiadomo, że w przypadku pewnych transakcji, odpowiedni poziom bezpieczeństwa informacji jest niezbędny, aby w ogóle można ich dokonywać, dlatego wydatki na bezpieczeństwo informacji w takich przypadkach muszą być traktowane w kategoriach umożliwienia prowadzenia biznesu. Problem oceny właściwych wydatków na bezpieczeństwo polega na tym, że koszty na bezpieczeństwo są wydatkami na umożliwienie prowadzenia określonego biznesu i mają ogromny wpływ na zyskowność określonych przedsięwzięć. Wówczas problem efektywności nakładów na bezpieczeństwo jest ściśle powiązany ze strategią firmy. Wskaźniki oceniające efektywność centrów danych W dzisiejszym świecie większość informacji przetwarza się w centrach danych, czyli wydzielonych obszarach spełniających określone wymogi fizycznego bezpieczeństwa, gdzie następuje duża koncentracja infrastruktury teleinformatycznej. Konstrukcja wskaźników centrów danych obejmuje wiele elementów operacyjnych, ale również pojawiają się próby całościowego spojrzenia na efektywność przetwarzania, czy też np. na stopień koncentracji oraz kompatybilności (tzw. poziom konwergencji) różnych elementów technologicznych, które ze sobą musza współgrać. Przedmiotem analizy konwergentnej infrastruktury centrów danych są takie elementy technologiczne, jak: serwery, poziom ich wirtualizacji, jakość infrastruktury sieciowej oraz pamięci masowe. Popularne są też wskaźniki określające wydajność centrów danych z jednego metra kwadratowego powierzchni lub z 1 kwh zużytej energii, a to już jest pełna analogia z powszechnie stosowanymi wskaźnikami, opisującymi funkcjonalność produktów konsumenckich, takimi jak w przypadku źródeł światła liczba lumenów z jednego wata, rocznego zużycia kwh przez lodówkę, czy najpopularniejszego wskaźnika efektywności samochodów, czyli zużycia paliwa na 100 km. Należy się przyzwyczaić do tego, że wraz z szybko rosnącym popytem na usługi informatyczne w tzw. chmurze obliczeniowej pojawi coraz więcej popularnych wskaźników, zrozumiałych dla szerokich grup użytkowników, odwołujących się do znanych benchmarków konsumenckich. Bo tylko w ten sposób klienci tych usług będą mogli podejmować racjonalne decyzje, dotyczące zakupów tych usług. 16

17 Technologiczne możliwości zakupu usług informatycznych w chmurze obliczeniowej sprawiają, że mamy do czynienia z eksplozją niekiedy bardzo złożonych modeli biznesowych. A zatem należy oczekiwać nowych ciekawych wskaźników, które będą próbowały sportretować właściwie nowe przedsiębiorstwa oraz kluczową rolę IT w efektywności ich działania, pewnie ku mitrędze księgowych, audytorów, inwestorów oraz analityków. Andrzej Jarosz Jest Dyrektorem Zarzadzjącym w IDC Polska. Zajmuje się problemtayką oceny efektywności inwestycji ICT w przedsiebiorstwach. Absolwent Politechniki Warszawskiej. Posiada tytuł Dr nauk technicznych. mail: ajarosz@idc.com, tel

18 Odcienie optymalizacji IT Łukasz Piątkowski, SAP Polska SAP posiada rozwiązania, które pozwalają optymalizować obszar IT w różnych aspektach, za każdym razem nie tracąc z pola widzenia kontekstu całej firmy i jej celów biznesowych. Największym zagrożeniem dla skutecznej optymalizacji IT jest jej punktowe rozumienie i stosowanie. Wycinkowe podejście do optymalizacji może przekreślić możliwości sięgnięcia po rysujące się biznesowe szanse. Przeciwdziałać takiemu niebezpieczeństwu może zastosowanie całościowego i spójnego podejścia, które ściśle wiąże IT z biznesem. Inżynieria wartości całościowe podejście do optymalizacji SAP Value Engineering stanowi przykład szeroko zakrojonego podejścia do identyfikowania korzyści w procesach transformacji IT, które SAP proponuje w odniesieniu do optymalizacji zarówno w obszarach biznesowych, jak i IT. To wyzwanie o ciągłym charakterze w każdej firmie, w naturalny jednak sposób presja optymalizacyjna nasila się w czasie kryzysu. Podejście Value Engienering ma na celu, poza analizą sytuacji przed podjęciem decyzji o nowym projekcie IT, również zaszczepienie w obszarze IT optymalizacji o charakterze nieustannego, automatycznego procesu weryfikacji określonych parametrów wydajności względem rynku i konkurencji. W praktyce SAP Value Engeenering opiera się na trzech kolejnych krokach: przeprowadzeniu benchmarkingu, budowie business case oraz sformułowaniu IT Roadmap. W pierwszym etapie organizacja IT zostaje porównana do próby reprezentatywnej (np. w ramach sektora). Podstawę porównania stanowi szczegółowa ankieta (czas wypełnienia to ok. 2-4 godz.), na podstawie której konsultanci SAP w ciągu 1-2 tygodni dostarczają szczegółowe porównanie do sytuacji w innych organizacjach. Następnie we współpracy z klientem definiowane lub redefiniowane są priorytety IT oraz kalkulowane korzyści z przyjęcia rozważanych scenariuszy zmian. Jednym słowem dla dostępnych sposobów optymalizacji IT budowane są business cases. W tym wypadku punktem odniesienia są także rzeczywiste dane pochodzące z badań dotyczących kosztu i efektywności rozwiązań IT, m.in. prowadzonych przez SAP. Oszacowanie dokonywane w business case dotyczy całkowitego kosztu użytkowania rozwiązania w okresie 5-10-letnim. Warto przytoczyć, że według danych, na których opierają się specjaliści SAP od Value Engeneering, statystycznie udział poszczególnych elementów kosztowych (TCO) rozkłada się następująco: infrastruktura = 20% operacje = 40% (= 20 pp bieżące operacje + 20 pp interfejsy) wdrożenia i upgrade = 22% (= 11 pp wdrożenie + 11 pp integracja) koszty utrzymania, wyszkolenia, itp. = 13% koszty licencji na oprogramowanie = 5%. W przypadku każdego z tych elementów w toku Value Engineering można wypracować istotne oszczędności, zachowując jednocześnie zrównoważoną, spójną strukturę IT. Należy pamiętać, że nadmierne redukcje kosztów w jednym obszarze mogą zaburzyć osiąganie korzyści w pozostałych. Przykładowo wydatki na innowacje stanowią istotny koszt, ale również niosą ze sobą korzyści dla rozwoju organizacji. W wyniku procesu Value Engineering powstaje raport, pokazujący badane wskaźniki na tle 18

19 grupy odniesienia. Można na tej podstawie stwierdzić, jakie korzyści przyniesie inwestycja w nowe rozwiązania IT i w jakim okresie czasu. Jeżeli te informacje są zbieżne ze strategią firmy, dokument taki może posłużyć jako podstawa działań optymalizacyjnych. Podejście zgodne z Value Engineering odpowiada na jedno z kluczowych pytań sprawdzających skuteczność prowadzonej optymalizacji w jakim zakresie udało się zmniejszyć stopień złożoności IT. Złożone, skomplikowane środowisko IT jest trudne w zarządzaniu, utrzymaniu (znacząca część budżetu pochłaniana jest przez koszt utrzymania zamiast na działania o charakterze innowacyjnym), pożera efektywność procesów biznesowych i destrukcyjnie wpływa na poziom produktywności użytkowników. Jednym z podstawowych parametrów złożoności IT jest liczba aplikacji. W grupie firm badanych przez SAP i ASUG (American SAP User Group) liczba aplikacji na każdy mld USD przychodów wynosiła od 5 w przypadku firm najbardziej efektywnych, do 68 u najmniej efektywnych. Średnia wynosiła 26 aplikacji na każdy miliard wypracowywanego przez firmę rocznie przychodu. Inne przekonujące cechy, które wyróżniają firmy z najefektywniejszym IT to znacznie niższy stosunek budżetu IT do przychodów (0,5% wobec 2% u najmniej efektywnych), oraz znacznie wyższy odsetek budżetu przeznaczany na działania innowacyjne (50% na innowacje, wobec 10% w przypadku firm najmniej efektywnych. W tych parametrach także pokazywany jest zysk z optymalizacji. Powyższe parametry mogą różnić się w różnych branżach. Ostatnim i najbardziej zaawansowanym etapem jest budowa IT Roadmap, czyli ścieżki rozwoju obszaru IT w firmie w oparciu o strategiczne cele oraz projekty prowadzone przez firmę. Zadanie to prowadzi do kolejnego szeroko pojętego aspektu optymalizacyjnego architektury korporacyjnej. Architektura korporacyjna: pełen obraz optymalizacji Zdecydowanie jednym z obszarów optymalizacji IT są inicjatywy związane z architekturą korporacyjną realizowane pod auspicjami The Open Group. SAP należy do tego konsorcjum od 2007 r., pełniąc jedną z wiodących ról. Aktywna i zdecydowana postawa firmy (wespół z Capgemini) pozwoliła wówczas przełamać impas wokół TOGAF w wersji 9 i doprowadziła do przyjęcia jej przez The Open Group w 2009 r. Punktem wyjścia do nowej wersji stało się rozszerzenie zbudowane siłami SAP i Capgemini. Kluczowe elementy metodyki dotyczącej architektury korporacyjnej SAP Enterprise Architecture Framework (EAF) weszły wprost do wersji 9 metodyki TOGAF. Dotyczy to w szczególności koncepcji cykli iteracyjnych dla utrwalonego w TOGAF modelu rozwoju architektury (Achitecture Development Model) oraz jako konsekwencja poprzedniej koncepcji stylów procesowania ( As Is First oraz To Be First ), a także zastosowanego rozróżnienia pomiędzy architekturą korporacyjną a architekturą rozwiązania. To ostatnie rozróżnienie, ale także dwie wymienione koncepcje, związane są z pragmatycznym celem przyświecającym autorom SAP EAF, doprecyzowującym abstrakcyjną z założenia formułę TOGAF. Samo w sobie rozszerzenie SAP EAF stanowi zbudowany na bazie TOGAF fundament do tworzenia i zarządzania architekturą korporacyjną w sytuacji, w której strategia firmowa zakłada wdrożenia rozwiązań pakietowych, i w przypadku, gdy architektura korporacyjna opisuje docelowe przedsiębiorstwo jako zorientowane na usługi (service-oriented enterprise). Te dwa podejścia, bardzo istotne z punktu widzenia możliwości optymalnego dostosowania technologii biznesowej do celów nakreślonych przez biznes, nie były przez TOGAF uwzględniane. Ich ujęcie w ramach SAP EAF związane jest także z pojawieniem się szeregu 19

20 Ilustracja: SAP AG bardzo istotnych udoskonaleń w zarządzaniu architekturą korporacyjną. Należą do nich m.in.: jednolita definicja procesów, słowniki, kompletny zestaw narzędzi do budowania architektury wraz ze zbiorem dobrych praktyk i sprawdzonych wzorców referencyjnych. Ważnymi elementami, pozwalającymi na szybsze zamodelowanie architektury korporacyjnej są również: jednoznaczny metamodel oraz wzorzec przejścia od architektury korporacyjnej do dostarczenia rozwiązania. Ponownie także pojawia się charakterystyczny dla SAP motyw dostarczenia rozwiązania, które nie tylko pomoże w uporządkowaniu zagadnień architektury korporacyjnej oraz w wyznaczeniu celów jej rozwoju, ale także dostarczy narzędzi i elastycznych metodyk do realizacji tych zamierzeń. Wprowadzenie podejścia SAP EAF w organizacji stanowi okazję do uzyskania klarownego obrazu zastanej architektury korporacyjnej, określenia docelowej wizji oraz zaplanowania metod przejścia. Przejrzysty obraz zyskuje nie tylko IT i zarządzający nim CIO oraz Chief Enterprise Architect, ale także biznes, który pytają z zasady o koszt, efektywność, celowość działań i o odniesienie do działań konkurencji. W tym kontekście optymalizacji warto pomyśleć o zagadnieniach Cloud Computing. Chmura sposobem na usprawnienie Standaryzacja IT prowadzą do sięgania po usługi i produkty dostępne w modelu na żądanie, czyli w tzw. chmurze. SAP także jest dostawcą aplikacji i platform IT w chmurze, czego przykładem jest SAP NetWeaver Cloud lub rozwiązania SAP SuccessFactors oraz Ariba. W kontekście optymalizacji infrastruktury IT, SAP oferuje model SaaS jako kolejną możliwość, która zależnie od modelu biznesowego klienta, 20