Udostępnij!

KONSPEKT (SKRÓCONA TRANSKRYPCJA):

 

Dzień dobry, witam wszystkich, z tej strony Arkadiusz Gałecki, firma Altkom Akademia. Bardzo mi miło Was wszystkich dzisiaj powitać z uwagi na to, że będziemy mieli okazję porozmawiać sobie o takich dobrych praktykach chociażby jak Lean, ITIL i DevOps. Dlaczego zadałem sobie pytanie „szukając wspólnego języka”? Dlatego aby postarać się i pokazać Wam w jaki sposób dobre praktyki ITIL’owe tak naprawdę, Lean IT, DevOps i oczywiście inne praktyki na rynku łączą się ze sobą po to aby móc dostarczać wartość klientom. Co ważne, bardzo wiele się na rynku w ostatnich latach zmieniło. Kiedyś klienci nie oczekiwali tak wiele jak w tej chwili, nie oczekiwali również w tak krótkim czasie jak teraz. Dlatego niezbędne jest znalezienie wspólnego mianownika dla wszystkich dobrych praktyk, które występują na rynku po to abyśmy mogli tworzyć i dostarczać wartość naszym klientom. Moi drodzy, zanim zaczniemy to na początek prosta agenda – agenda wprowadzająca nas do tego o czym będziemy dzisiaj mówić.

  • Rys historyczny – pochodzenie dobrych praktyk takich jak Lean IT, ITIL i DevOps
  • Potrzeby i oczekiwania rynku
  • Nowa odsłona – połączenie dobrych praktyk, czyli ITIL 4/DevOps
  • Szybciej czy stabilniej? Co jest ważniejsze dla kienta?
  • Wartość ponad wszystko
  • Wyniki nie kłamią – pokazują w jaki sposób wartość jest dostarczana klientowi.

Rys historyczny:

Biblioteka ITIL pozwala nadążyć za zmieniającymi się potrzebami organizacji biznesowych poprzez zrozumienie obu stron i tego czym jest wartość dostarczana dla klienta. Rynek się zmienia – obecnie żyjemy w świecie transformacji cyfrowej, czwartej rewolucji przemysłowej, Internetu Rzeczy i tak dalej. Jak dać sobie z tym radę i nadążyć nie narażając klienta na utratę wartości?  Z pomocą przychodzi ITIL, który od prawie 40 lat ewoluuje jako potężne narzędzie, pomagające klientom w osiągnięciu wyniku. Wynik to finanse i zarabianie pieniędzy – dzięki wartości.

 

Co jest celem każdej organizacji? Zarabianie pieniędzy, zdefiniowane przez Elijahu Goldratta w jego publikacjach. Jak wyglądała droga od ITIL 1 do ITIL 4? Lata 1989-1999 to biblioteka ITIL w wersji pierwszej, jej właścicielem jest rząd Wielkiej Brytanii. Posiada 36 różnych pozycji + tzw. publikacje uzupełniające. Trochę wcześniej – na przełomie 1981/1982 ówczesna premier Wielkiej Brytanii, Margaret Thatcher prosi doradców o znalezienie dobrych praktyk w zarządzaniu. Był to początek ITIL.  Po ITIL 1 przychodzi spora zmiana – na przełomie lat 2000/2001 pojawia się kolejna wersja, ITIL 2.

 

Działa w oparciu nie o funkcje, ale o procesy. Wyróżnia service delivery  – wszelkie procesy, które odpowiadają za dostarczanie usługi – i service support; wszelkie procesy i funkcje związane z utrzymaniem i operacjami. Do dziś trudno sobie poradzić z tym żeby połączyć organizację IT w jedno; ITIL 2 połączył kros-funkcjonalność na silosy, z którymi trzeba teraz walczyć. Fajnie, że taki ITIL istnieje, ale nie da nam za dużej wartości ponieważ będziemy od siebie odizolowani.

 

Maj 2007 – ukazuje się ITIL 3, oparty na cyklu życia usługi. Ma zapewnić zburzenie muru narastającego od ITIL 2  – podziału na rozwój i eksploatację. Nie było to łatwe i za mało uwagi poświęcano zaangażowaniu. Zasoby ludzkie należy włączać do poszczególnych faz cyklu życia usługi – strategii, propozycji zmian, udoskonaleniach, projektowaniu usług. Również do kryteriów akceptacji usługi czy fazy Transition z testowaniem, walidowaniem, wsparciem powdrożeniowym etc. Jest to już tworzenie organizacji czy projektu kros-funkcjonalnego, często jednak o tym zapominano.

 

Lipiec 2011 – pojawia się ITIL 2011. Przynosi takie elementy jak Business Relationship Management, wprowadza rolę odpowiedzialną za satysfakcję klienta. Poza tym ważna rola SLR – Service Level Requirements, wymagań dotyczących poziomu świadczenia usługi. Kiedy projekt lub stabilizacja się kończą, zamieniają się w Service Level Target. Silna relacja pomiędzy BRM (relacje z biznesem) a SLR. W lutym 2019 r., po kilku drobnych zmianach, pojawia się ITIL 4; właścicielem jest już firma Axelos.

 

Jego fundamenty to siedem zasad przewodnich, service value system, cztery wymiary zarządzania usługami i łańcuch wartości usług. Poza tym strumienie wartości, przeplatające się z łańcuchami – jest to współtworzenie wartości. Jak widać, ITIL 4 mocno skupia się na współtworzeniu wartości przez klientów, dostawców i poddostawców. Poza poziomem Foundation, we wrześniu 2019 r. pojawia się rozszerzenie ITIL Professional Transition. Pojawiły się też pierwsze szkolenia na poziomie Intermediate. W najbliższym czasie ukażą się kolejne szkolenia.

 

Tak mniej więcej wygląda rys historyczny jeżeli chodzi o bibliotekę ITIL. Docieramy tu w pewnym sensie do kwestii czwartej rewolucji przemysłowej. IT to istota każdej współczesnej firmy. Aktualizacja pozwala ITILowi odzwierciedlać nowe sposoby pracy, praktyki i środowiska. ITIL4 będzie również ewoluował żeby zapewnić kompletny informatyczny i cyfrowy model operacyjny, z kompletnym utrzymaniem produktów i usług.

 

Czwarta rewolucja przemysłowa nie wzięła się sama z siebie – pod koniec XVIII wieku pojawia się wykorzystanie energii wody i konkretne wynalazki, jak mechaniczne krosno prackie czy maszyna parowa. Kolejne innowacje to przełom XIX i XX wieku – wykorzystanie energii elektrycznej, produkcja masowa, standaryzacja. Energia elektryczna to fundament dzięki któremu możemy dzisiaj komunikować się cyfrowo. Pojawia się również produkcja masowa. Potem w latach siedemdziesiątych XX wieku dochodzi do robotyzacji produkcji, zastępującej pracę rąk ludzkich, czynności powtarzalne, wymagające dużej precyzji i dokładności.

 

Roboty wykonują za nas część pracy, poza tym takie wynalazki jak systemy teleinformatyczne, czy układy scalone, wynalezione zostają tranzystor i roboty. Jest to trzecia rewolucja przemysłowa, związana m.in. z Doliną Krzemową. Nastąpił szybki rozwój IT  – stąd też potrzeba stworzenia ITIL. W końcu pojawia się XXI wiek kiedy jesteśmy świadkami i uczestnikami czwartej rewolucji przemysłowej. Co mamy?

 

Cyfrowa integracja, łańcuchy wartości i autonomiczne podejmowanie decyzji przez maszyny. Na co dzień spotykamy się już ze sztuczną inteligencją, obecną w smartfonach, komputerach czy telewizorach. Jako automat zbiera od nas podstawowe informacje i przy tym uczy się – analizuje żebyśmy zostali szybciej czy lepiej obsłużeni. W ciągu kilku lat prawdopodobnie wszystko będzie się opierało na wsparciu sztucznej inteligencji. Pytanie czy nie wyeliminuje kiedyś człowieka, trzeba więc ją kontrolować. Poza tym współcześnie pojawiają się takie ciekawe wynalazki jak Big Data, Internet Rzeczy i tak dalej. To wszystko jest niczym innym jak realizacją czwartej rewolucji przemysłowej.

 

Kolejną dobrą praktyką o której można powiedzieć jest filozofia Lean, od 2011 Lean IT. Spójrzmy znowu historycznie – wracamy do początków XX wieku, jest rok 1910. Frederick Taylor wymyśla zarządzanie naukowe, które ma poprawiać wydajność. To podwaliny pod filozofię Lean, która powstawała głównie w Toyocie. W 1920 r. powstaje produkcja masowa, wynika z zastosowania linii produkcyjnej. Jeden pracownik wykonuje tylko jedną czynność, praca jest systematyzowana, produkt dostarcza się szybciej. Te rozwiązania wdrożono w Fordzie; produkcja zwiększa się z 28 do prawie 128 pojazdów dziennie.

 

Potem przychodzi kolejna ważna data – lata 1948/1950-1975. Amerykanie decydują się wesprzeć Japonię po zniszczeniach wojennych. Współpracują z Japończykami w Toyocie, poznają japońskie doświadczenia , wspólnie tworzą filozofię Lean. TPS – Toyota Production System, 14 zasad szczupłej produkcji. W latach 1975-1985 w USA następuje kryzys paliwowy, firma General Motors jest w kryzysie. Żeby wyjść z problemów i uratować firmę, wprowadzają filozofię Lean. Potem w Ameryce gości prezes Toyoty, docenia produkcję w Fordzie, ale uznaje, że w Japonii to nie zadziała. Następuje wprowadzenie eliminacji wast’eów i bottom necków (wąskich gardeł). W 1987 r. Motorola i General Electric wdrażają Six Sigma, czyli kontynuację filozofii Lean.

 

W 2011 r. Steve Bell i Mark Ozen tworzą Lean IT – wykorzystuje 14 zasad szczupłej produkcji, drogi Toyoty, TPS i innych narzędzi w ramach IT. Cykl życia usługi w ITIL 3 to też linia produkcyjna bo najpierw jest pomysł, strategia, potem projektowanie, fizyczna budowa, testowanie, walidacja, przeniesienie na produkcję i utrzymywanie. Kolejna dobra praktyka tu wykorzystywana to DevOps, warto pokazać jak się w tym wszystkim plasuje i łączy z innymi praktykami. Szeroko czerpie z Leana i jego różnych elementów, takich jak eliminacja marnotrawstw, mapowanie strumienia wartości etc. Sfrustrowany Belg, Patric Dubois, po konferencji Agile w Toronto w 2007 r podejmuje pracę w belgijskim ministerstwie żeby zająć się migracjami centrów danych, testuje gotowość operacyjną – łączy działania między zespołami deweloperów i operacji. Po spotkaniu z Andrew Schefferem razem wymyślają koncepcję Agile System Administration – tworzą grupę w Google’u Google Agile System Administrator. Były to początki DevOpsa.

 

Szukano połączenia dwóch światów rozwoju i operacji. Zainspirowany Debois zorganizował konferencję o nazwie DevOps Day i od tamtej pory ta metodyka gości w wielu organizjach na całym świecie. Poza takimi kwestiami jak kultura, automatyzacja, pomiary i współdzielenie, uwzględniono również tematy związane z Lean. Kultura mówi o zmianie kulturowej i potrzebie zarządzania zmianą organizacyjną, Lean o udoskonaleniu flow i eliminacji wszelkich nieefektywności, skróceniu czasu cyklu dostarczania produktów i usług. Współdzielenie wykorzystuje system zarządzania wiedzą o usługach z ITIL i pozwala na odpowiednią komunikację, podejmowanie ryzyka i odpowiednie dostarczanie produktów i usług w kontekście informacji/wiedzy.

 

W 2013 r. wydano książkę The Phoenix Project, w której opisano historię pewnej organizacji borykającej się z różnymi problemami w kontekście dostarczania produktów i usług; są tam widoczne inspiracje z Goldratta. Pokazuje dobre praktyki, które trzeba wykorzystywać i łączyć ze sobą żeby dostarczać produkty. DevOps można porównać do pewnej podróży i inspiracji, a nie określonego celu. Tak samo jak Lean, dąży do ciągłego doskonalenia i wyższej wydajności; pojawiają się takie pojęcia jak continous integration i continous delivery. Automatyzuje narzędzia – komercyjne i open source’owe. Narzędzia zmieniają kulturę i wpływają na zachowania ludzi.

Potrzeby i oczekiwania rynku.

Czego potrzebuje rynek? Według WTO, usługi to największy i dynamiczny składnik gospodarki w krajach zarówno rozwiniętych jak i rozwijających się. Prawie wszystkie usługi są obsługiwane przez IT; biznes bez IT nie ma już racji bytu.  Dlatego organizacje czerpią ogromne korzyści z tworzenia, rozwijania i doskonalenia swojego potencjału zarządzania usługami, a technologia rozwija się szybciej niż kiedykolwiek. Takie technologie jak przetwarzanie w chmurze, uczenie maszynowe czy blockchain otworzyły nam nowe możliwości – IT stało się ważnym motorem biznesu i źródłem przewagi konkurencyjnej. Zarządzanie usługami IT staje się więc kluczową zdolnością strategiczną w organizacji.

 

Organizacje wdrażają programy transformacyjne żeby pozyskiwać nowych klientów i reagować na zmiany. To także ewolucja w sposobie działania organizacji dzięki czemu mogą się rozwijać i równoważyć potrzebę stabilności i przewidywalności w odniesieniu do rosnącego zapotrzebowania na zwinność operacyjną i szybsze działania. Informacje i technologie są coraz mocniej integrowane z innymi zdolnościami organizacyjnymi. Burzy się bariery poprzez zmiany zachowania ludzi – zmianę kulturową. Pracuje się kros-funkcjonalnie. Aby wesprzeć transformację cyfrową, zmienia się też zarządzanie usługami, żeby maksymalnie wykorzystywać możliwości.

 

Potrzeby rynku są różne – kiedyś klient definiował wymagania, wiedział ile może za to zapłacić i mówił na kiedy ma to być dostarczone. To tradycyjne, waterfallowe podejście. O tym co dostaje klient dowiadywał się kiedy było to przeniesione na produkcję i okazywało się, że chciał czegoś innego, mimo, że wymagania były spełnione. Kiedyś wszystko trwało wolniej. Dzisiaj przeszliśmy drogę od drezyny do super szybkiego japońskiego pociągu, który przemieszcza się z prędkością prawie 600 km/h – czyli obecnie dużo szybciej reagujemy na potrzeby klientów.

 

Dzisiaj klient mówi bardziej o potrzebie a nie o samym produkcie, chce ją zrealizować szybko. Nie chce czekać, mówi, ze chciałby spełnić potrzebę np. w maksymalnie dwa tygodnie. Jeśli potrzeba to np. przemieszczanie się z punktu A do punktu B, to na początek możemy wyprodukować choćby deskorolkę. W kolejnym kroku dostanie od nas np. elektryczną hulajnogę – będzie przemieszczać się szybciej. Kolejny sprint przyniesie coś za co będzie chciał zapłacić, czyli kolejną wartość – rower elektryczny z kolejnymi możliwościami,z czego będzie dużo bardziej zadowolony. W końcu otrzymałby świetny, rozbudowany samochód; ale jeśli chce jeszcze lepszego produktu, to w kolejnym sprincie dostanie samolot żeby jeszcze lepiej się przemieszczać z punktu A do punktu B.

 

Podsumowując – tam gdzie są jasne, znane wymagania, czas i pieniądze można realizować spokojnie podejście waterfallowe, ale kiedy wszystko zmienia się w czasie, najlepiej wykorzystać podejście zwinne i szybko reagować na potrzeby naszych klientów. Jednym z podstawowych elementów pozyskiwania wymagań w Lean jest voice of customer – głos klienta, to czego klient potrzebuje. Określa się je jako SLR-y, potem dalej tłumaczone i rozkładane na mniejsze elementy. Naszym zadaniem jest w miarę szybko, elastycznie dostarczyć to za co klient chce zapłacić, reagując na wszystkie wymagania. Trzeba identyfikować to co nasz klient robi na rynku – pattern business activity.

Nowa odsłona.

Co przynoszą Lean, ITIL i DevOps? Przede wszystkim możliwość współpracy klienta czy konsumenta z dostawcą, współtworzenie wartości. Istnieje service provider oraz service supplier , dostawca zewnętrzny. Wyróżniamy także cztery wymiary zarządzania usługami – organizacja i ludzie, informacje i technologie, strumienie wartości i procesy, partnerzy i dostawcy.

 

Kolejny kluczowy element to łańcuch wartości usług. Opiera się na odpowiednio generowanym popycie i dostarczaniu wartości dzięki wykorzystaniu wielu elementów. Nie uda się to bez planowania i udoskonalania. Kolejny element, zaczerpnięty mocno z filozofii Lean, to value stream mapping, czyli mapowanie strumienia wartości. Tworzy się stan obecny i docelowy, identyfikuje i eliminuje działania, które nie dają wartości. Kolejny aspekt – Continous Integration i Continous Delivery, a tak naprawdę Continous Everything – automatyczna integracja, budowa, testowanie, monitorowanie i dostarczanie.  To już scisły element DevOpsa, mający zapewnić odpowiednią współpracę pomiędzy biznesem i rozwojem a eksploatacją.

 

Kolejny ważny element – service value system. Wspierają go guiding principles, zasady przewodnie, odpowiedzialne za dobre praktyki w organizacji. Wszystko w ramach łańcuchów wartości. Siedem zasad przewodnich to fundament ITIL-a; każda z nich może być używana niezależnie i jest uniwersalna. Postaram się teraz powiedzieć trochę więcej o każdym aspekcie. Zacznijmy od czterech wymiarów zarządzania usługami.

 

Przede wszystkim, mają kluczowe znaczenie dla skutecznego i wydajnego ułatwiania wartości klientom i innym interesariuszom w postaci zarówno produktów jak i usług. Reprezentują perspektywy istotne dla całego systemu, w tym całego łańcucha wartości usług. Powinny być dobrze zdefiniowane i wspierać cały model działania. Drugi filar czy wymiar po organizacji i ludziach to informacje i technologie; obejmuje wiedzę niezbędną do zarządzania usługami, skupia się na wymaganych technologiach. Partnerzy i dostawcy – ten wymiar obejmuje pewne relacje organizacji z innymi zangażowanymi w projektowanie, rozwój, wdrażanie, dostarczanie, wsparcie, doskonalenie. Zawiera umowy organizacji z partnerami i dostawcami. Każda organizacja i usługa zależy od innych.

 

Jeszcze jeden element – strumienie wartości i procesy. Odnosi się do tego, że różne części organizacji pracują w zintegrowany i skoordynowany sposób aby umożliwić tworzenie wartości poprzez produkty i usługi. Kolejny element to system wartości usług, który pokazuje jak wszystkie elementy organizacji współpracują w celu dostarczania wartości. Zasady przewodnie – to zalecenia, które mają kierować organizacją we wszystkich okolicznościach, niezależnie od zmian w celach, strategiach czy strukturze organizacyjnej.

 

Governance – środki za pomocą których organizacja jest zarządzana. Łańcuch wartości – zestaw powiązanych ze sobą działań wykonywanych przez organizację żeby dostarczyć produkt lub usługę. Praktyki – różnego rodzaju zasoby do wykonania pracy. W ITIL 3 mieliśmy 26 procesów i 4 funkcje, w ITIL 4 jest 34 praktyk. Continual Improvement to powtarzające się na wszystkich poziomach działania, które wykonuje się żeby było wiadomo, że wydajność organizacji spełnia oczekiwania interesariuszy. Stosujemy miary usług, procesów i komponentów oraz KPI.

 

Wszystko co robimy ma doprowadzić do zburzenia silosów, które mogą się tworzyć z różnych powodów i być odporne na zmiany. Mogą ograniczać dostęp do wiedzy, zmniejszać wydajność, zwiększać koszty i utrudniać komunikację. W takiej sytuacji często nie da się podejmować odpowiednich decyzji. Praktyki również mogą stać się pewnymi silosami – dlatego wszystkie powinny mieć różne interfejsy. Architektura systemu wartości usług w  ITIL umożliwia pewną elastyczność i zniechęca do pracy w trybie „cichym”. Nie ma stałej, sztywnej struktury, jest więcej kros-funkcjonalności.

 

Organizacje powinny być w stanie przedefiniować swoje strumienie wartości żeby zaspokajać potrzeby w różnych scenariuszach. Wymaga to doskonalenia na wszystkich poziomach – wykorzystujemy więc model ciągłego doskonalenia.  Kolejny ważny aspekt, na który warto zwrócić uwagę to łańcuch wartości występujący w ITIL 4. Jest to każde działanie, które wykorzystuje kombinację praktyk do przekształcenia danych wejściowych w konkretny wynik. Te dane mogą pochodzić z zewnątrz – z rynku.

 

Abyśmy mogli przekształcić dane wejściowe w dane wyjściowe, wykorzystuje się różne kombinacje praktyk ITIL. Każde działanie opiera się na zasobach, procesach, umiejętnościach a nawet osobach trzecich. Strumienie wartości usług to specyficzne kombinacje działań i praktyk, każda przeznaczona dla konkretnego scenariusza.  Siedem zasad przewodnich to zalecenia, które prowadzą organizację niezależnie od wszystkich zmian. Każda jest uniwersalna i trwała.

 

Może teraz kilka słów o każdej z nich – najpierw focus on value, czyli skupienie się na wartości. Wszystko co robi organizacja powinno łączyć się z wartością, dla siebie, klientów i wszystkich innych interesariuszy. Może przybierać różne formy – przychody, lojalność klientów, niższe koszty, możliwość rozwoju dla organizacji. Kolejna zasada – zacznij gdzie jesteś, z uwzględnieniem tego co zostało już wcześniej zrobione. Kolejna zasada – postępuj iteracyjnie dzięki opiniom. Trzeba oprzeć się pokusie robienia wszystkiego naraz. Nawet wielkie inicjatywy muszą być podzielone na mniejsze części; dzięki temu można wszystko realizować w odpowiednim czasie.

 

Kolejna zasada – współpracuj i promuj widoczność. Gdy przypiszemy odpowiednie role i dobrze zagospodarujemy zasoby, korzystamy z lepszego zaangażowania. Wszystko nabiera szerszego znaczenia – dostępne są choćby lepsze informacje do podejmowania decyzji, jest większe prawdopodobieństwo długoterminowego sukcesu. Kolejna myśl – pracuj holistycznie. W żadnej organizacji nic nie działa samodzielnie – produkty ucierpią jeśli nie będziemy działać w zintegrowany sposób. Wszystkie działania organizacji powinny się koncentrować na dostarczaniu wartości. Są dostarczane klientom zewnętrznym i wewnętrznym poprzez integrację czterech wymiarów zarządzania usługami.

 

Kolejna zasada – utrzymuj to proste i praktyczne. Upraszczając – wyeliminuj wszelkiego rodzaju nieefektywności i wąskie gardła. Technologia może pomóc w automatyzacji i eliminacji tego co powtarzalne. Sztuczna inteligencja może generować kod na podstawie konkretnych wymagań. Jeśli pojawiają się błędy i incydenty po przeniesieniu usługi na produkcję, następuje automatyczne wycofanie.

 

Ciekawe narzędzie w ITIL 4, DevOpsie i Lean to także mapowanie strumienia wartości VSM – mówi jak identyfikować proces, tak jak rzeczywiście jest obsługiwany przez ludzi. Przyklejając na ścianie kolorowe karteczki, tworzą stan obecny procesu, potem stan docelowy i identyfikują nieefektywności. Są tu takie elementy jak czas oczekiwania, czas procesowania, czas łączny i czas standardowy. Mają one wpływ na czas dostarczenia. Jeżeli dzisiaj oczekiwanie na każdą akceptację trwa 14-15 dni, jest to być może za długo. Mapowanie strumienia wartości może to przyspieszyć.

 

Warto mieć też świadomość czym jest DevOps –  mówi się, że DevOps to kultura i czas. Czas bo musimy sprawić, że produkty i usługi będą szybciej dostarczane. Dlaczego kultura? Dlatego, że organizacja wymaga nowego spojrzenia. Możemy wpływać na zachowania ludzi, które staną się kulturą. Żeby to zrobić, skorzystamy z takich narzędzi jak Agile, CI/CD (Continous Integration/Continous Delivery), ITSM i dobrych praktyk Lean. Całość flow powinna zostać odpowiednio zautomatyzowana.

 

Mamy też trzy drogi DevOpsowe – pierwsza droga to flow, druga to pętla zwrotna i feedback, trzecia to eksperymentowanie i uczenie się – ma zapewnić, że będziemy eksperymentować nie karząc za błędy a organizacja będzie się uczyć. Continous Deployment to już pełna automatyzacja flow. Automatyzuje się także testy akceptacyjne. Podobnie jak DevOps, również ITIL 4 jasno wskazuje na automatyzację.

Szybciej czy stabilniej?

Nasz rytm jest zatrzymany – ponieważ kiedyś dla biznesu liczyły się pieniądze i czas. Jeśli biznes potrzebuje innowacji, nowych rozwiązań, korzystaliśmy z podejścia waterfallowego i rygorystycznych procedur. Biznes nadal będzie oczekiwał innowacji i będzie przez nie wygrywał, ale mają one zapewnić, że będziemy korzystać z takich praktyk jak Agile, Lean, ITSM i jeszcze wiele innych. Pod spodem będzie Continous Everything – zapewnimy, że ten flow zostanie w pełni zautomatyzowany.

 

Skoro tak to musimy sobie zadać pytanie – jak szybciej i stabilniej to czego chciałby biznes? Obecnie po stronie biznesu i developmentu panuje ekstremalne sfokusowanie na zmianę a po stronie eksploatacji – ekstremalne sfokusowanie na stabilność. Czego chce eksploatacja? Stabilności. Każda strona będzie ciągnąć w swoją stronę. Biznes oczekuje zachowania odpowiedniej jakości i mówi jasno czego chce; zarówno maksymalnie dużo zmian a z drugiej strony stabilności środowisk. Łańcuch wartości, odpowiednie flow, mapowanie strumienia wartości etc może to zapewnić i w ten sposób dostarczać wartość naszym klientom.

Wartość ponad wszystko.

Wartość to dostrzeganie korzyści, użyteczności i znaczenia czegoś – jest współtworzona przez aktywną współpracę między dostawcami, konsumentami i innymi organizacjami. Celem organizacji jest przede wszystkim tworzenie wartości dla odbiorców, klientów i interesariuszy. Termin „wartość” jest bardzo często używany w zarzadzaniu usługami i jest to główny cel ITIL 4. Wartośc jest postrzegana przez interesariuszy, stakeholderów – niezależnie czy to klienci, konsumenci czy ktoś inny. Czasem jest subiektywna i inaczej postrzegana przez każdego.

 

Przykładowo – różne osoby będą chciały innego samochodu, o trochę innych cechach. Żebyśmy mogli tworzyć wartość, tworzymy propozycję wartości, która składa się z dwóch elementów – użyteczności i gwarancji. Użyteczność to zgodność z przeznaczeniem, to co usługa robi. Żeby mogła coś robić i dostarczać wartość, eliminujemy ograniczenia. Gwarancja musi obejmować wystarczającą dostępność, odpowiedni potencjał wykonawczy, odpowiednią ciągłość działania i bezpieczeństwo. Tworząc wartość powinniśmy się skupić na tych wszystkich aspektach.

 

Wyniki nie kłamią.

Co będziemy mierzyć w kontekście ITIL 4, DevOpsa i tak dalej? Przede wszystkim prędkość, jakość, stabilność i kulturę. Jeżeli mówimy o prędkości, to czas cyklu i dostarczania zmian, częstotliwość wdrożeń na produkcję i szybkość tych wdrożeń. Jeżeli spojrzymy na jakość, to wskaźniki nieudanych zmian, ale również wskaźnik udanych wdrożeń, incydenty i defekty jakie się pojawią.

 

Patrząc na stabilność, mierzymy takie elementy jak średni czas wykrycia incydentu, średni czas przywrócenia komponentów czy elementów konfiguracji, średni czas przywrócenia usług. Pozostaje jeszcze kwestia kultury – tutaj retencje, lojalność jeśli chodzi o pracowników, zaangażowanie i morale, wiedza i współdzielenie. Te wszystkie elementy, które będą później przedstawiane i raportowane razem pokażą nam jak dobrze działamy, na jakim poziomie, na ile środowiska sa stabilne i jak przebiega ta nasza zmiana kulturowa.

 

Co mierzymy, a czego nie mierzymy? Nie mierzymy wyjścia, nie mierzymy produktywności, dojrzałości, linijek kodu bo byłoby to bez sensu. Nie mierzymy velocity i utylizacji. Nie mierzymy się też indywidualnie lub lokalnie, w ramach pojedynczej grupy; dokonujemy pomiarów wyników i wartości, zdolności, czasu dostawy, częstotliwości wdrożeń, czasu przywrócenia usługi po awarii, zespołu jako całości. W odniesieniu do tych pomiarów należy spojrzeć na cztery rodzaje prac wykonywanych w IT – projekty biznesowe, projekty IT, planowane zmiany i nieplanowane prace, czyli nic innego jak wynik tych trzech pierwszych.

 

Mówiłem, że wyniki nie kłamią – w odniesieniu do dobrych praktyk DevOpsa, ITIL 4, Leana i tak dalej, problemy jakie napotykamy i kwestie utrudniające przyjęcie tej kultury usługowej, 50% różnego rodzaju kwestii dotyczy ludzi. Można powiedzieć, że największym problemem organizacji jest nic innego jak zmiana kulturowa. 37% to aspekty procesowe – zbyt ciężkie, zbyt biurokratyczne procesy. 5% to informacja, komunikacja, 8% to technologia. Wciąż największym problemem organizacji to ludzie i zmiana kulturowa.

 

Wszystkich, którzy mają czas odsyłam do State of DevOps Reports – za lata 2016-2019. Pokazują one jak łączy się dobre praktyki, jak działa DevOps i jak się mierzymy, jak możemy włączać elementy Leana i ITIL-a do naszego DevOpsa. Bardzo zachęcam i mam jeszcze jeden element – wyniki nie kłamią, w roku 2016 organizacje, które przyjęły dobre praktyki, DevOpsa, łączenie ze sobą Agile, Leana, ITIL i tak dalej, mamy 200 razy częstsze wdrożenia, potem w 2017 r. 46 razy częściej niż w roku poprzednim. W roku 2018 – wiele razy dziennie. I tak dalej, i tak dalej.

 

Jeśli zastosujemy dobre praktyki, IT jest w stanie zmieniać się z roku na rok – narzędzi, które można ze sobą połączyć, jest bardzo dużo. To tyle na dzisiaj, miło było się z Wami spotkać. Zainteresowanych zapraszam do kontaktu przez firmę Altkom Akademia. Zapraszam na inne webinaria. W przypadku pytań proszę pisać. Dziękuję wszystkim za spotkanie.