Siedem Podstawowych Zasad (Guiding Principle) w ITIL 4 jest rekomendacjami jak należy się zachować i możemy je stosować w każdych okolicznościach. Są na tyle uniwersalne, że pasują do każdej organizacji, niezależnie czy jest duża czy mała, prywatna czy państwowa, jak jest kierowana i zarządzana.

Podstawowe Zasady to jeden z pięciu komponentów Systemu Wartości Usług, bardzo ważny i kluczowy.

Podstawowe Zasady pomagają odpowiedzieć na pytania: co jest ważne? na czym się skupić?, w którym kierunku podążać? Są drogowskazem i jednocześnie drogą aby nie zboczyć z wybranego kierunku.

Każda organizacja powinna dokonać przeglądu wszystkich siedmiu Podstawowych Zasad i wybrać KILKA, którymi będzie się kierować.

Podstawowymi Zasadami ITIL wyciąga rękę do takich metodyk pracy jak Lean, Agile czy DevOps, pokazując że tworzą synergię w dostarczaniu, wsparciu i zarządzaniu produktami i usługami.

1. Skoncentruj się na wartości (Focus on value) wskazuje, że tworząc i dostarczając produkty i usługi, dostawcy usług muszą pamiętać, że mają one przyczyniać się do tworzenia wartości dla konsumentów. W pierwszej kolejności dostawca usługi musi zidentyfikować i ustalić, kto korzysta ze świadczonych usług aby dobrze zrozumieć potrzeby konsumentów. Ważne jest również doświadczenie klienta (Customer Experience) oraz doświadczenie użytkownika (User Experience) związane z danym produktem lub usługą. Hasło klient na pierwszym miejscu (Customer first), sprawdza się bardzo dobrze w tej zasadzie.
2. Zacznij tam gdzie jesteś (Start where you are), mówi aby wykorzystać usługi i metody, które już mamy, nawet jeżeli są one niedoskonałe i nie działają idealnie. Należy ocenić i zweryfikować co działa dobrze a co działa źle. To co działa dobrze zostawiamy a to co działa źle poprawiamy, zmieniamy, doskonalimy a jeżeli okaże się, że nie można tego poprawić to dopiero wtedy pozbywamy się i robimy nowe. Ale skąd mamy wiedzieć czy coś działa dobrze czy działa źle. Pomagają nam w tym dwa narzędzia pomiar czyli mierniki, KPI, liczby oraz bezpośrednia obserwacja, jako informacja zwrotna, przeprowadzania w formie ankiet, spotkań, warsztatów lub indywidualnych obserwacji na miejscu.
3. Postępuj iteracyjnie, wykorzystując informacje zwrotne (Progress iteratively with feedback), zaleca oparcie się pokusie zrobienia wszystkiego naraz. Nawet największe zadania i projekty możemy wykonać dzieląc je na mniejsze części i realizować po kawałku. Zasada ta bezpośrednio nawiązuje do metodyki pracy Agile. Dzięki podziałowi na mniejsze części, szybciej dotrze do nas informacja zwrotna o tym, czy usługa spełnia wymagania zgłaszane przez klienta oraz czy występują w niej błędy. To pozwoli na zareagowanie na tą informację zwrotną i naprawienie błędów oraz ewentualne korekty w usłudze aby jak najlepiej spełniała wymagania klienta.
4. Współpracuj i promuj widoczność (Collaborate and promote visibility), zachęca do otwartości w działaniu i burzeniu silosów w organizacjach. Współpraca rozumiana jest jako realizacja zadań w dążeniu do wspólnego celu. Każdy wie w jakim stopniu to co robi, przyczynia się do osiągnięcia wspólnych celów. Dobra współpraca wymaga zidentyfikowania wszystkich interesariuszy abyśmy wiedzieli z kim współpracować i budować relację. Dotyczy to współpracy wewnętrznej pomiędzy osobami w zespole, pomiędzy zespołami i działami, jak również zewnętrznej z klientami, użytkownikami i innymi interesariuszami (np. partnerzy, dostawcy). Widoczność zapewniamy poprzez pokazywanie co robimy, czym się zajmujemy i jaka jest ważność naszej pracy. Pomagają nam w tym między innymi tablice Kanban.
5. Myśli i pracuj całościowo (Think and work holistically), pokazuje że musimy mieć postrzeganie całej rzeczywistości a nie tylko jej wybranych elementów. Pomagają nam w tym Cztery wymiary zarządzania usługami, które poprzez wymiary Organizacje i ludzie, Informacje i technologie, Partnerzy i dostawcy oraz Strumienie wartości i procesy, dają pełne spojrzenie na analizowany element. Wyjście z własnego, czasami ograniczonego „pudełka” i spojrzenie z perspektywy klienta, użytkownika, dostawcy czy partnera, pozwala dostrzec inne aspekty, ważne dla tych interesariuszy.
6. Zadbaj o prostotę i praktyczność (Keep it simple and practicle), wskazuje aby zawsze wykonywać minimalną liczbę kroków aby osiągnąć cel, np. pisząc procedurę lub tworząc produkt lub usługę. Zrób proste rozwiązanie, wdróż je i zacznij używać. Jeżeli okaże się, że czegoś brakuje, dodaj, zmień i udoskonal ale dopiero wtedy. Nie twórz rozwiązania, które obsłuży wszystkie wyjątki. Skąd jednak masz wiedzieć, co jest potrzebne a co zbędne? Jest jedyna reguła, którą powinieneś się kierować. Jeżeli coś przyczynia się do tworzenia wartości zostaw to a jeżeli nie przyczyna się do tworzenia wartości eliminuj i pozbywaj się wszelkich marnotrawstw.
7. Optymalizuj i automatyzuj (Optimize and automate), pozwala optymalizować i automatyzować działania wykonywane przez człowieka. Robimy dokładnie w takiej kolejności. Najpierw optymalizujemy, usprawniamy aby działało optymalnie a dopiero potem automatyzujemy. Jakie czynności i działania automatyzujemy? Automatyzujemy czynności, które są proste, powtarzalne i mogą być źródłem błędów, popełnianych przez ludzi, wynikających z monotonii wykonywanych czynności. Jeżeli zrobimy dobry automat/robot to wykona on daną czynność szybciej, lepiej (bez błędów) oraz taniej. Jednym ale nie jedynym powodem wprowadzania automatyzacji jest obniżenie kosztów wykonywania określonych czynności.

Które z siedmiu Podstawowych Zasad wybrać? Należy dobrze poznać i zrozumieć wszystkie Podstawowe Zasady i po analizie wybrać KILKA, które będą najbardziej pomocne dla danej organizacji. Jak już wybierzemy nasze podstawowe zasady to konsekwentnie powinniśmy postępować zgodnie z nimi do czasu aż uznamy, że należy dokonać kolejnego przeglądu i może trzeba zmienić kurs lub wprowadzić jego korektę, w związku ze zmieniającym się otoczeniem biznesowym, naszym rozwojem czy nowymi potrzebami i wymaganiami.

Którymi Podstawowymi Zasadami się kierujesz? Która Podstawowa Zasada jest dla Ciebie najważniejsza? Podziel się swoim doświadczeniem i uwagami.

Artykuł Prosto o ITIL – Jak Podstawowe Zasady wyznaczają kierunek? pochodzi z serwisu Mariusz Siek.

W artykule „DevOps – Trzy drogi” opisałem podstawowe zasady jakimi kieruje się DevOps w strumieniu wartości technologii. Teraz chciałbym bliżej przyjrzeć się na czym polega pierwsza droga i w jaki sposób może pomóc w zarządzaniu usługami IT. Pierwsza droga obejmuje zasady przepływu pracy w strumieniu wartości technologii, czyli np wytwarzaniu oprogramowania. Co jest w niej najważniejsze?

Spraw aby praca była widoczna

Pracę można zobaczyć w fabryce, gdzie mamy materiały do produkcji, maszyny i linie produkcyjne oraz pracowników obsługujących te maszyny lub przemieszczających się po zakładzie. Jak jednak to zrobić w przypadku wytwarzania oprogramowania komputerowego? Z pomocą przychodzi bardzo ciekawy wynalazek, tablica kanban. Jest to sposób aby na tablicy zwizualizować pracę, jaka jest wykonywana w zespole. W kolumnach mamy poszczególne etapy, kroki pracy do wykonania. W poziomie możemy mieć np. osoby, które dana pracę wykonują. Bardzo prosto możemy zrobić tablicę kanban rysując ją na dużym arkuszu papieru lub tablicy ścieralnej i naklejając karteczki post-it w odpowiednich kolumnach, jako reprezentację zadań, kart pracy. Na tablicy kanban praca wpływa z lewej strony i jest przekazywana w prawą stronę, pomiędzy kolejnymi etapami pracy. Praca kończy się z prawej strony, która reprezentuje produkcyjne działanie, wykonaną pracę. Takie podejście pozwala na zarządzanie pracą i mierzenie czasu jej wykonania na poszczególnych etapach. Takie obrazowanie pracy pozwala lepiej określać priorytety dla zadań oczekujących w kolejce i w ten sposób zwiększać przepustowość systemu.

Ograniczenie pracy w toku

Kolejna zasada przepływu, pokazuje nam, że powinniśmy ograniczać pracę w toku, czyli tą która jest aktualnie wykonywana. Czy to ma sens? Mamy robić wszystko aby pracy było mniej? Brzmi trochę podejrzanie ale wcale takie nie jest. DevOps wskazuje, że wielozadaniowość jest nieefektywna i proponuje jej ograniczanie, tak aby koncentrować jest na wykonaniu jednego zadania. Do tego wykorzystywana jest oczywiście tablica kanban. Określamy limity pracy w toku (Work In Progress – WIP), dla każdej kolumny lub etapu/ośrodka pracy poprzez ograniczenie liczby kart, które mogą występować w jednej kolumnie. Żadna praca nie może być wykonana, dopóki nie stworzy się jej reprezentacji w postaci karty pracy. Takie podejście nie zmniejsza ale zwiększa efektywność pracy i powoduje, że jest jej wykonywane więcej a nie mniej.

Zmniejszenie wielkości partii

Aby przepływ pracy był jak najbardziej optymalny, musimy zastosować kolejną zasadę, czyli wykonywać pracę w małych partiach. Takie postępowanie prowadzi do skrócenia czasu realizacji pracy oraz zwiększa jej jakość. Przy małych partiach pracy, wcześniej możemy wykryć błędy i je skorygować, tym samym poprawiając jakość pracy. W ten sposób zmniejszamy też współczynnik pracy w toku, który jest kluczowy dla DevOps. Oczywiście jeżeli mamy mniejsze partie pracy to jest ona wykonywana szybciej i czas realizacji jest krótszy. Dodatkowo jesteśmy w stanie szybciej wykrywać błędy i wprowadzać działania naprawcze. Oznacza to także, mniejszą liczbę koniecznych zmian.

Zmniejszenie liczby przełączeń

Aby przepływ pracy był jak najkrótszy, konieczne jest zautomatyzowanie jak największej ilości pracy, aby mogła być wykonywana bez oczekiwania w kolejkach. To kolejna zasada przepływu, którą musimy zastosować. Aby z niej skorzystać musimy zmienić organizację zespołów, tak aby mogły dostarczać wartość bezpośrednio do klienta. W ten sposób skracamy czas jaki praca musi czekać w kolejce i nie przynosi wartości dodanej.

Stałe identyfikowanie i eliminowanie ograniczeń

Jeżeli chcemy aby nasz praca była efektywna, musimy stale identyfikować i eliminować ograniczenia systemu naszej pracy. Najczęściej występujące ograniczenia w wytwarzaniu oprogramowania to:

• Tworzenie środowiska. Kto nie spotkał się z sytuacją, że nie można wdrożyć oprogramowania bo nie ma środowiska do testów funkcjonalnych lub wydajnościowych lub brakuje zasobów do środowiska produkcyjnego? Dążymy do środowisk na żądanie i pełnej automatyzacji ich tworzenia.
• Instalacja kodu. Jeżeli instalacja oprogramowania składa się z wielu kroków i wymaga kilku specjalistów to nie może trwać krótko. Dlatego pracujemy nad pełną automatyzacją instalacji oprogramowania.
• Konfiguracja i uruchamianie testów. Wykonywanie testów ręcznie, przygotowywanie danych testowych, planowanie zasobów ludzkich do testów, to wszystko powoduje, że testy trwają tygodniami. Lekarstwem jest jak w poprzednich punktach zautomatyzowanie testów.
• Zbyt ścisła architektura. Jeżeli architektura nie pozwala wprowadzać zmian bez angażowania procesu zarządzania zmianą i CAB, to jest to ograniczenie. Dążymy do wprowadzania zmian bezpiecznie i z większą autonomią.

Eliminowanie trudności i odpadów w strumieniu wartości

Ta zasada przepływu mówi, że powinniśmy dążyć do zmniejszenia trudności i uciążliwości codziennej pracy przez ciągłe uczenie się w celu osiągnięcia stawianych celów. Przykładowe kategorie trudności i odpadów to:

• Prace wykonane częściowo
• Dodatkowe procesy
• Dodatkowe funkcjonalności
• Oczekiwanie
• Defekty
• Prace niestandardowe i ręczne

Podsumowanie

Opisałem najważniejsze zasady przepływu, będące pierwszą drogą. Praca musi być widoczna, aby można było nią lepiej zarządzać. Należy zmniejszać pracę, która jest aktualnie wykonywana oraz dzielić pracę na małe partie i części. Zmniejszamy liczbę przekazywania pracy z etapu do etapu i z zespołu do zespołu. Ciągle identyfikujemy i eliminujemy ograniczenia systemu pracy. Stale eliminujemy trudności i problemy w strumieniu wartości technologii. Ich zastosowanie i przestrzeganie pozwoli na jak najkrótszy przepływ pracy.

Na podstawie książki „DevOps – Światowej klasy zwinność, niezawodność i bezpieczeństwo w twojej organizacji”.

Artykuł DevOps – Pierwsza droga – Zasady przepływu pochodzi z serwisu Mariusz Siek.

Świat się zmienia. Zarządzanie usługami IT też. To co dziesięć lat temu wydawało się dobre i skuteczne dzisiaj stało się trochę skostniałe i mało elastyczne. Nie znaczy, że całkowicie jest niepotrzebne ale wymaga odświeżenia i dostosowania do istniejących warunków. Tak dzieje się np z ITIL, który w tym roku wprowadza czwartą wersję swojej biblioteki. Zanim jednak Axelos odkryje wszystkie karty postanowiłem bliżej przyjrzeć się DevOps. W tym celu nabyłem książkę „DevOps – Światowej klasy zwinność, niezawodność i bezpieczeństwo w twojej organizacji”. Autorami są Gene Kim, Jez Humble, Patrick Debois i John Willis. Zacząłem ją zgłębiać i chciałbym się podzielić podstawową wiedzą o trzech drogach w DevOps.

Trzy drogi

Jako fundamentalne zasady DevOps wprowadza pojęcie trzech dróg:

• Pierwsza droga – Zasady przepływu pracy
• Druga droga – Zasady sprzężenia zwrotnego
• Trzecia droga – Zasady ciągłego uczenia się i eksperymentowania

Pierwsza droga – Zasady przepływu pracy

Pierwsza droga mówi o zasadach związanych z przepływem pracy od jej rozpoczęcia do zakończenia. W przypadku strumienia wartości technologii, czyli działu wytwarzania oprogramowania, początkiem przepływu pracy jest zdefiniowanie wymagań biznesowych a końcem wdrożenie oprogramowania zawierającego funkcjonalności dotyczące tych wymagań na produkcję. Proces ten obejmuje przejście od developmentu do operacji (utrzymania). Jakoś nie lubię terminu operacje, bo źle mi się kojarzy i wolę używać „utrzymanie”. Według mnie lepiej odzwierciedla funkcje tej aktywności.

Zasady z pierwszej drogi koncentrują się na zwiększeniu przepływu pracy, tak aby czas od rozpoczęcia do zakończenia pracy był jak najkrótszy. Najważniejsze elementy to:

• Zwiększenie widoczności praca, które najlepiej wykonać poprzez tablicę kanban, umieszczoną w miejscu pracy zespołu
• Zmniejszenie rozmiaru partii, sprowadza się do dzielenia pracy, na jak najmniejsze, niezależne zadania
• Zmniejszenie interwału pracy, poprzez skracanie okresów wydań oprogramowania z miesięcy do tygodni, dni i godzin.
• Tworzenie jakości poprzez przeciwdziałanie przekazywania defektów, pomiędzy poszczególnymi etapami wytwarzania oprogramowania. Jednym słowem usuwanie błędów jak tylko się pojawią.
• Stałe optymalizowanie pracy, poprzez dążenie do ciągłego zwiększania efektywności i usuwania wąskich gardeł

Druga droga – Zasady sprzężenie zwrotnego

Druga droga skupia się na szybkim i stałym przepływie informacji zwrotnych. Najważniejsze jest aby wszystkie informacje, które mogą przyczynić się do skutecznego usuwania problemów były przekazywane na bieżąco z zespołu operacji (utrzymania) do zespołu developerskiego. Celem takiego działania jest:

• Zapobieganie występowaniu podobnych problemów w przyszłości
• Zwiększenie efektywności procesów wykrywania problemów i eliminowania ich skutków.

Budujemy w ten sposób mechanizmy pracy, które mogą rozwiązywać problemy na wczesnym etapie i zapobiegać ich katastrofalnym skutkom.

Trzecia droga – Zasady ciągłego uczenia się i eksperymentowania

Trzecia droga koncentruje się na:

• Dynamicznym, zdyscyplinowanym i naukowym podejściu do eksperymentowania i podejmowania ryzyka
• Czerpaniu nauki z sukcesów jak i porażek
• Ciągłym skracaniu i wzmacnianiu pętli sprzężenia zwrotnego

Poszukujemy takich usprawnień w naszym codziennym działaniu, które będzie można zastosować globalnie i przyczynią się do poprawy działania innych osób w zespole.

Podsumowanie

Trzy drogi to dopiero początek mojej drogi w DevOps. Podane zasady wyglądają na proste i zrozumiałe. Pozostaje tylko zastosować je w praktyce i zweryfikować jak się sprawdzają. Do zobaczenia na dalszej drodze w odkrywaniu tajników DevOps.

Artykuł DevOps – Trzy drogi pochodzi z serwisu Mariusz Siek.

Każdy nazywa je trochę inaczej: utrzymanie, operacje, eksploatacja, produkcja, serwis. Zapewne określeń znalazłoby się jeszcze więcej ale nie to jest najważniejsze. Czy utrzymanie jest ważne i potrzebne do działania systemów i usług informatycznych? Najprawdopodobniej każdy z IT i biznesu powiedział by, że tak. Ktoś przecież musi dbać o to aby aplikacje, systemy i usługi dla biznesu działały nieprzerwanie a w przypadku incydentów i problemów rozwiązywane były zgodnie z SLA. Nie ma chyba obecnie firmy, która nie korzystała by z rozwiązań informatycznych, a co raz więcej z nich w swoim modelu biznesowym jest wręcz „uzależnione” od IT. Dlaczego więc utrzymanie jest na końcu, dosłownie i w przenośni, jako obszar w IT? Czy to jest tylko moje odczucie czy może faktycznie nie przykładamy właściwej wagi do utrzymania?

Trochę teorii

Niezależnie jakie dobre praktyki w zarządzaniami usługami IT weźmiemy pod uwagę: ITIL, DevOps, COBIT, LeanIT, znajdziemy w nich obszar związany z „utrzymaniem”. To prawda występuje on przeważnie zawsze na końcu cyklu produkcyjnego ale taka jest jego natura. Tego się nie zmieni i z tym nie zamierzam walczyć. Czy jednak fakt, że utrzymanie jest ostatnim elementem w zarządzaniu usługami IT, oznacza że powinniśmy zająć się nim dopiero po zakończeniu cyklu wytwórczego usług, aplikacji, oprogramowania IT? Niestety w większości organizacji utrzymanie ma niski priorytet w cyklu życia usługi IT. Kto by myślał i zastanawiał się nad utrzymaniem skoro jeszcze nawet nie wiemy, jakie są wymagania funkcjonalne, jaka będzie architektura rozwiązania IT oraz w jakiej technologii usługa będzie wytwarzana.

To jest jednak podstawowy błąd, jeżeli na wczesnym etapie wytwarzania rozwiązania IT, nie uwzględnimy wymagań niefunkcjonalnych, które są bardzo mocno związanych z utrzymaniem.

Wymagania niefunkcjonalne

Oprócz wymagań funkcjonalnych, które są kluczowe dla wytworzenia rozwiązania informatycznego, bardzo ważnym elementem każdej usługi IT są wymagania niefunkcjonalne. Główne obszary wymagań niefunkcjonalnych to: bezpieczeństwo, dostępność, niezawodność, wydajność, obsługa serwisowe, odtwarzanie po awarii (backup and recovery). Jak widać są to bardzo ważne i duże w swoim zakresie obszary. Aktualnie bezpieczeństwo ma co raz większe znaczenie i wymagania z nim związane powinny być dobrze zdefiniowane, zaprojektowane i wdrożone. Takie aspekty jak polityka haseł, sposób logowania i autoryzacji, nadawanie i odbieranie uprawnień, muszą zostać uwzględnione. Dostępność i niezawodność to chyba najważniejszy z obszarów, ponieważ od niego zależy na jakim poziomie będzie świadczona usługa IT. Wymagania od biznesu należy przełożyć na architekturę rozwiązania, które zapewni oczekiwany poziom dostępności. Wymagania na wydajność zagwarantują, że usługa IT będzie wspierała funkcjonowanie biznesu a nie je spowalniała. Wiemy, że usługi IT mogą się zepsuć, dlatego tak ważne jest aby określić w jakim czasie będą usuwane wszelkie awarie i usterki. Na koniec ciągłość działania, która zawiera wymagania związane z kopiami zapasowymi (backup) i ich odtwarzaniem (recovery). Uzbierało się całkiem sporo a przecież każdy z podanych obszarów wymagań niefunkcjonalnych to dziedzina sama w sobie.

Kto to zrobi?

Dla obsługi wymagań funkcjonalnych mamy dedykowane zespoły, które zwierają biznes, analityków, projektantów, programistów, testerów, scrum masterów itp. W przypadku wymagań niefunkcjonalnych jest już trochę gorzej. W ich przypadku już nie mamy takiego komfortu zasobów ludzkich, które za nie odpowiadają. Główną rolę pełni tu architekt systemowy, tylko czy jest w stanie zapanować nad wszystkimi wymaganiami z tych obszarów? Pewnie z działu bezpieczeństwa ktoś się znajdzie ale czy może poświęcić wystarczającą ilość czasu aby uczestniczyć w projekcie? Dobrze jak jest Service Level Manager, bo on jest w stanie dużą część wymagań niefunkcjonalnych obsłużyć. Jednak gdy go nie ma kto zadba o te wymagania? Już na etapie definiowania wymagań powinny w proces/projekt wytwórczy włączać się osoby z zespołów utrzymania (infrastruktura, aplikacje, bazy danych, service desk, managerowie ITSM). Bez ich udziału, trudno będzie oczekiwać, że po wdrożeniu na produkcje usługa będzie działać bez jakichkolwiek problemów.

Niestety pierwszym błędem jest nie wystarczająca ilość osób, które odpowiadają za te wymagania. Drugim jest włączanie tych osób na późnym etapie realizacji projektu, gdy już etap wytwarzania usługi IT jest bardzo mocno zaawansowany i nie można wpływać np. na jej architekturę.

Czy tylko brak zasobów ludzkich?

Powstaje pytanie czy tylko brak ludzi odpowiedzialnych za wymagania niefunkcjonalne jest głównym problemem? Oczywiście nie. Bardzo często biznes nie potrafi zdefiniować swoich oczekiwań co do wymagań niefunkcjonalnych lub brak jest kogoś kto te wymagania określa. Kluczową jednak przyczyną dlaczego tak się dzieje, jest presja czasu. Biznes oczekuje rozwiązań IT na wczoraj a jednocześnie nie chce się angażować w proces wytwórczy. IT aby sprostać oczekiwaniom biznesu dwoi się i troi, jednak ograniczenia czasowe nie pozwalają na rzetelną obsługę wszystkich wymagań. Dlatego w pierwszej kolejności odbija się to na wymaganiach niefunkcjonalnych, w szczególności tych najbliższych utrzymaniu. Projekt, rozwiązanie, usługę IT trzeba dowieźć na dany termin i zespół projektowy, wytwórczy zrobi wszystko aby to osiągnąć i zakończyć ten etap. Nie patrzy przy tym, jakie problemy będą występować na produkcji, bo przecież to nie jego odpowiedzialność. Nawet jak zespół developerski wspiera utrzymanie w obsłudze incydentów i problemów to robi to na innym etapie z innej pozycji. Wdrożenie zakończyło się sukcesem. Fakt, że później jest setki lub tysiące zgłoszeń już nikt z „projektu” nie analizuje. Niech się tym martwi utrzymanie a jak nie będzie sobie radzić to wspaniałomyślnie mu pomożemy.

Co dalej?

Nie wiem czy tak jest wszędzie ale ja mam takie doświadczenia i uważam, że nie są odosobnione. Kiedy zaczniemy patrzeć na usługę informatyczną jako na całość i nie będziemy budować murów pomiędzy wy development i my utrzymanie lub na odwrót. Kiedy osoby odpowiedzialne za cały obszar IT, zobaczą że myślenie o utrzymaniu, na jak najwcześniejszym etapie projektu, daje wymierne korzyści i przynosi widoczne efekty całej organizacji IT oraz biznesowi, który przecież za to IT płaci. Widzę bardzo ważną rolę utrzymania a w szczególności menedżerów ITSM w uświadamianiu i edukowaniu innych działów IT, jak ważne jest uwzględnianie aspektów utrzymaniowych na wczesnym etapie rozwoju usługi IT.

Artykuł Niedoceniane utrzymanie pochodzi z serwisu Mariusz Siek.

W poprzednim artykule opisywałem proces zarządzania katalogiem usług. Bardzo mocno z nim powiązany jest proces zarządzania poziomem usług. Tak naprawdę kiedyś zarządzanie katalogiem usług było w ramach procesu zarządzania poziomem usług, ale zostało wydzielone do oddzielnego procesu. Nie dziwi więc fakt, że oba procesy są spokrewnione i zarządzanie poziomem usług bez katalogu usług nie miałoby co robić, bo poziom świadczenia określa się dla usług zdefiniowanych w katalogu usług. Ponieważ katalog usług jest bardzo ważnym produktem i narzędziem w zarządzaniu usługami IT, według mnie dobrze się stało, że został do jego zarządzania powołany dedykowany proces. Co zatem zostało w procesie zarządzania poziomem usług?

Cele

Podstawowym celem procesu zarządzania poziomem usług jest zagwarantowanie, że wszystkie aktualne i planowane usługi, są dostarczane na uzgodnionym, wymaganym poziomie. Osiąga się ten cel poprzez ciągły cykl negocjacji, uzgadniania, monitorowania, raportowania i przeglądania wymaganych (dopuszczalnych) wartości parametrów SLA.

Proces koncentruje się na:

• Definiowaniu, dokumentowaniu, uzgadnianiu, monitorowaniu, mierzeniu, raportowaniu i przeglądaniu poziomu, dostarczanych usług IT. Jeżeli jest potrzeba wprowadzane są środki naprawcze
• Zapewnieniu i poprawie relacji i komunikacji z biznesem i klientami
• Zapewnieniu, że zostaną określone, konkretne i mierzalne cele (wartości dopuszczalne) dla wszystkich usług IT
• Monitorowaniu i poprawie satysfakcji klienta z jakości świadczonych usług
• Zapewnieniu, że IT i Klienci mają jasne i jednoznaczne oczekiwania co do poziomu świadczonych usług
• Zagwarantowaniu, że nawet jeżeli wszystkie wymagane wartości poziomu usług zostaną spełnione, będą podejmowane proaktywane działania, mające na celu ciągłą poprawę kosztową usług

Zakres

Rysunek z książki ITIL Service Design

W zakresie procesu zarządzania poziomu usług jest zapewnienie regularnych kontaktów i komunikacji z klientami i menedżerami biznesowymi, w zakresie związanym z poziomem świadczonych usług. W tym względzie proces SLM powinien reprezentować dostawcę usług IT przed biznesem i biznes przed dostawcą usług IT. Zakres procesu SLM obejmuje również:

• Współpracę z procesem zarządzania relacjami biznesowymi (proces na etapie strategii), w zakresie osiągnięcia celów procesu SLM
• Negocjacje i uzgodnienie przyszłych (planowanych) wymagań na poziom usług i wartości dopuszczalnych (Service Level Requirements – SLR) dla wszystkich usług
• Negocjacje i uzgodnienie aktualnych wymagań na poziom usług i wartości dopuszczalnych (Service Level Agreement – SLA)
• Rozwijanie i zarządzanie odpowiednich umów OLA, które zagwarantują dotrzymanie celów w umowach SLA
• Przeglądanie i zarządzanie umowami z dostawcami zewnętrznymi (Underpinning contracts),które zagwarantują dotrzymanie celów w umowach SLA
• Proaktywne zapobieganie awarią usług, minimalizowanie ryzyka i poprawa jakości usług
• Raportowanie i zarządzanie rzeczywistym poziomem usług i przeglądanie wszystkich przekroczeń poziomu usług zdefiniowanego w SLA
• Okresowe przeglądy SLA, OLA i zakresu usług
• Identyfikowanie możliwości usprawnień i wprowadzanie ich do rejestru usprawnień
• Inicjowanie i koordynowanie planu poprawy usług (Service Improvement Plan – SIP)

Proces zarządzania poziomem usług nie obejmuje:

• Negocjacji i uzgodnienia wymagań funkcjonalnych, oprócz tych funkcjonalności, które mogą wpływać na poziom świadczonych usług
• Pilnowania aktywności, które są konieczne do zapewnienia wymaganego poziomu usług, ale są realizowane przez inne procesy takie jak zarządzanie dostępnością i zarządzanie pojemnością.
• Negocjacji i podpisywania umów z dostawcami zewnętrznymi, za które odpowiada proces zarządzania dostawcami. SLM dostarcza tylko dane wejściowe i wymagane konsultacje.

Korzyści

Efektywnie funkcjonujący proces zarządzania poziomem usług zapewnia:

• Interfejs dla biznesu, dla wszystkich zagadnień związanych z poziomem usług
• Uzgodnione SLA z określonymi celami (wartościami dopuszczalnym) oraz informację zarządczą, że te cele są spełnione
• Wyjaśnienie przyczyn źródłowych przekroczenia SLA i podejmowanie działań, które zagwarantują nie powtarzanie się tych przekroczeń
• Wiarygodny kanał komunikacji i zaufane relacje z klientem i biznesem

Rodzaje SLA

SLA możemy definiować na kilka różnych sposobów.

• SLA zorientowane na usługę, definiujemy jedno SLA dla usługi, chociaż może z niej korzystać wielu klientów. Problemem może być zróżnicowanie poziomu SLA, jeżeli usługa korzysta z tych samych elementów konfiguracji
• SLA zorientowane na klienta, definiujemy SLA dla jednego klienta, uwzględniając wszystkie usługi jakie dla niego świadczymy
• Wielopoziomowe SLA, którego przykładem może być trzypoziomowe SLA: poziom korporacji, poziom klienta i poziom usługi

Podsumowanie

To zaczyna się robić nudne :-). Zarządzanie poziomem usług to kolejny bardzo ważny proces w zarządzaniu usługami IT. Jest odpowiedzialny za ustalenie z biznesem, na jakim poziomie będą świadczone usługi IT. Musi przy tym uwzględniać wymagania biznesu i klienta, możliwości organizacji IT, posiadane zasoby sprzętowe i softwareowe oraz obowiązujące umowy z dostawcami zewnętrznymi. Żąglowanie tymi wszystkimi elementami, wymaga nie lada umiejętności od Menedżera poziomu usług. Potrzebne jest również doświadczenie w negocjowaniu, komunikacji, budowaniu relacji i balansowaniu pomiędzy biznesem a IT.

Pytanie: Jaki rodzaj SLA stosujesz najczęściej i dlaczego?

Artykuł Zarządzanie poziomem usług pochodzi z serwisu Mariusz Siek.

Odkąd zacząłem się zajmować zarządzaniem usługami IT, uważałem że wprowadzanie najlepszych praktyk ITIL należy zaczynać od katalogu usług. Nadal tak uważam, bo jak można zarządzać usługami nie wiedząc jakie mamy usługi i jaki poziom ich świadczenia (SLA) jest określony. Potwierdza to biblioteka ITIL, która w wersji 3 w 2007 roku, oprócz procesu „Zarządzanie poziomem usług„, wprowadziła dedykowany proces „Zarządzanie katalogiem usług”. Jeżeli mamy specjalnie dla katalogu usług proces do jego zarządzania, to chyba należy uznać, że katalog usług, jest bardzo ważnym narzędziem w zarządzaniu usługami IT. Zobaczmy co zawiera proces „Zarządzania katalogiem usług”

Cele

Celem procesu Zarządzania katalogiem usług jest dostarczenie i utrzymanie jednego, spójnego źródła informacji o wszystkich produkcyjnych i projektowanych usługach i zapewnienie, aby te informacje były dostępne dla jak najszerszego grona, uprawnionych odbiorców.

Proces koncentruje się na:

• Zarządzaniu informacjami zawartymi w katalogu usług
• Zapewnieniu, że katalog usług jest dokładny i odzwierciedla aktualny stan usług, które działają produkcyjnie lub są przygotowywane do wdrożenia na produkcji
• Zapewnieniu, że katalog usług jest dostępny dla wszystkich uprawnionych interesariuszy, w sposób który zapewnia efektywne wykorzystanie zgromadzonych w nim informacji
• Zapewnieniu, że katalog usług wspiera zmieniające się potrzeby pozostałych procesów zarządzania usługami, w zakresie informacji zawartych w katalogu usług

Zakres

Proces Zarządzania katalogiem usług, obejmuje swoim zakresem:

• Przygotowanie wsadu do definicji usług i pakietów usług
• Rozwój i utrzymanie opisów usług i pakietów usług, według ustalonych standardów
• Wytworzenie i utrzymanie prawidłowego katalogu usług
• Interfejsy, zależności i spójność pomiędzy katalogiem usług a portfolio usług
• Interfejsy i zależności pomiędzy usługami i usługami wspierającymi w katalogu usług i CMS
• Interfejsy i zależności pomiędzy usługami a komponentami wspierającymi i elementami konfiguracji, w katalogu usług i CMS

Proces Zarządzania katalogiem usług nie obejmuje:

• Gromadzenia, utrzymania i wykorzystania zasobów usługi i danych konfiguracji. Tym zajmuje się proces zarządzania zasobami i konfiguracją.
• Gromadzenia, utrzymania i spełnienia żądań o usługę. Tą aktywnością zajmuje się proces spełniania żądań (request fulfillment)

Korzyści dla biznesu

Efektywne zarządzanie katalogiem usług, pozwala na osiągnięcie następujących korzyści:

• Dostarcza biznesowi centralne źródło informacji o usługach IT, ich szczegółach, statusie, poziomie świadczenia, jakie procesy biznesowe wspierają, sposobie wykorzystania.
• Zapewnienie wspólnego rozumienia usług IT przez biznes i IT, skutkujące lepszymi relacjami pomiędzy klientem a dostawcą, poprzez wykorzystanie katalogu usług jako narzędzia marketingu i komunikacji
• Lepsza koncentracja dostawcy usług na wynikach klienta, dzięki powiązaniu wewnętrznych aktywności dostawcy usługi i zasobów usługi z procesami i wynikami biznesowymi
• Poprawa wydajności i efektywności pozostałych procesów zarządzania usługami IT, poprzez wykorzystanie informacji zawartych w katalogu usług
• Lepsza wiedza, dopasowanie i koncentracja na wartości dla biznesu, dla każdej usługi, po stronie dostawcy usług IT

Rodzaje usług

Katalog usług to nie zwykła lista usług ale pewna hierarchia i struktura, która pokazuje zależności pomiędzy procesami biznesowymi, usługami i SLA. Same usługi możemy podzielić na dwie główne grupy:

• Usługi udostępniane użytkownikowi, są to usługi które wspierają procesy biznesowe klienta, bezpośrednio dostarczające oczekiwanych wyników
• Usługi wspierające, są to usługi, które wspierają funkcjonowanie usług udostępnianych użytkownikowi i nie są przez niego widziane

Ja nazywam pierwsze usługami biznesowymi a drugie usługami systemu. Oczywiście nazw usług wspierających może być więcej: infrastrukturalne, sieciowe, aplikacyjne, techniczne itp. Niezależnie jak będą się nazywać, należy zadbać aby były jednoznacznie zdefiniowane, aby każdy zainteresowany rozumiał je w ten sam sposób.

Na poniższym rysunku (z książki ITIL Service Design) pokazano rodzaje usług, przykładowe usługi, ich relacje pomiędzy nimi, procesami biznesowymi i SLA. Daje on pewne wyobrażenie, co powinien zawierać katalog usług i jak ważnym jest narzędziem.

Podsumowanie

Proces Zarządzania katalogiem usług, jest jednym z najważniejszych na etapie projektowania usług oraz w całym cyklu życia usługi. Zapewnia, że:

• wszystkie usługi funkcjonujące produkcyjnie, będą w katalogu usług opisane
• będą określone relacje pomiędzy procesami biznesowymi a usługami udostępnianymi użytkownikowi (biznesowymi)
• będą określone relacje pomiędzy usługami biznesowymi a wspierającymi (systemu)
• informacje będą aktualne, prawidłowe i odzwierciedlające rzeczywistość produkcyjną.

Jeżeli zastanawiałeś się dlaczego potrzebny jest dedykowany proces dla zarządzania katalogiem usług, to teraz już chyba nie masz wątpliwości. Wykorzystaj go aby poprawić jakość świadczonych usług IT do biznesu.

Pytanie: Ile usług masz w katalogu usług i jakie są ich rodzaje?

Artykuł Zarządzanie katalogiem usług pochodzi z serwisu Mariusz Siek.

Od 12 lat zajmuję się zarządzaniem usługami IT. W mojej pracy wykorzystuję najlepsze praktyki ITIL i doświadczenie zdobyte na przestrzeni tego okresu. Świat jednak nie stoi w miejscu i zmienia się bardzo szybko, szczególnie w obszarze technologii. Czy ITIL, który został wymyślony w latach dziewięćdziesiątych poprzedniego wieku, spełnia oczekiwania dzisiejszego IT, które musi sprostać wysokim wymaganiom biznesowym? Czy wersja trzecia ITIL, która ukazała się w 2007 roku, nadal jest aktualna i stosowanie jej przynosi spodziewane korzyści? Jak zmieni się ITIL w wersji 4, która jest zapowiadana na ten rok? Czy ITIL ma szanse w konfrontacji z DevOps, które obecnie jest jednym z najbardziej popularnych i pożądanych podejść na funkcjonowanie IT? Za dużo pytań jak na początek artykułu :-). Spróbujmy znaleźć na nie odpowiedzi.

ITIL

ITIL w wersji 3 wprowadził usługowe podejście do IT i cykl życia usługi. Cykl życia składa się z pięciu faz:

• Strategii
• Projektowania
• Wdrożenia
• Utrzymania
• Ciągłej poprawy

Cykl ten się powtarza, ponieważ zawsze możemy coś zrobić aby usługa była świadczona lepiej, taniej i na wyższym poziomie.

To podejście objęło cały cykl wytwórczy dla usługi, czego nie było w poprzedniej, drugiej wersji biblioteki. Całkowitą nowością była faza strategii. Natomiast pozostałe fazy zostały rozszerzone o brakujące procesy.

Wiele organizacji IT nadal funkcjonuje w oparciu o procesy opisane w ITIL, z uwzględnieniem ich potrzeb i wymagań. Według mnie nie straciły one nic ze swojej aktualności, chociaż mogą się wydawać „ciężkie”, mało zwinne i bardzo sformalizowane. Czy ich biurokracja jest w stanie sprostać, wymaganiom na wykonywanie kilku wdrożeń dziennie?

Rys 1. Na podstawie książki ITIL Service Transition.

DevOps

Po drugiej stronie mamy DevOps, który mocno się rozpycha i pokazuje, że można do wytwarzania i wdrażania usług, rozumianych jako oprogramowanie i infrastruktura sprzętowa, zastosować takie rozwiązania, które pozwolą szybko, sprawnie i bezproblemowo, dostarczać na produkcję nowe funkcjonalności i aplikacje. W największym uproszczeniu, DevOps to połączenie wytwarzania usług (development) z ich utrzymaniem (operations). Usuwamy odwieczny mur pomiędzy rozwojem i utrzymaniem, i tak organizujemy pracę zespołu aby mógł szybko dostarczać wartość biznesową na produkcję. Nie chodzi tu oczywiście tylko o ludzi ale przede wszystkim procesy i narzędzie. Musimy zastosować pełną automatyzację testów, ciągłą integrację, infrastrukturę jako kod i kilka innych specyficznych dla DevOps rozwiązań.

Rys 2. Na podstawie wideo What is DevOps

Wspólne elementy

Czy to oznacza, że nie można pogodzić DevOps z ITIL? Na pierwszy rzut oka, wydaje się, że są to dwa różne światy, jednak po bliższym przyjrzeniu się znajdziemy kilka części wspólnych.

• Cykliczność. Oba podejścia uwzględniają cykliczne działanie, które ma na celu ciągłe doskonalenie wytwarzanych i implementowanych rozwiązań. Łatnie to widać na dwóch powyższych rysunkach. Oczywiście częstotliwość tych cykli jest inna ale można ją próbować synchronizować.
• Procesy. W obu metodykach wykorzystywane są procesy, które muszą być dobrze zaprojektowane, dostosowane i wdrożone do potrzeb organizacji. Co ciekawe niektóre tak samo lub bardzo podobnie się nazywają: zarządzanie zmianą, zarządzanie wydaniami, zarządzanie pojemnością i zarządzanie konfiguracją. Nie trzeba wyjaśniać, że np. proces zarządzania zmianą w ITIL aby działał na potrzeby DevOps musi zostać odpowiednio zmieniony, zaadaptowany i zautomatyzowany.
• Ciągłe doskonalenie. Nie ważne czy nasz cykl wytwórczy trwa jedną godzinę, jeden dzień czy jeden miesiąc, mamy świadomość, że nie dostarczymy idealnego rozwiązania i będziemy musieli je poprawiać, usprawniać i rozwijać. Tak samo do tego zagadnienia podchodzą obie metodologie i to daje szansę na ich wspólne funkcjonowanie.
• Narzędzia. Do wsparcia procesów zarówno w ITIL jak i DevOps potrzebne są specjalistyczne narzędzia. Oczywiście są to innego rodzaju narzędzia, bo specyfika jest różna ale bez narzędzi, obsługa procesów nie byłaby możliwa.

Chociaż ITIL i DevOps, wydają się dwoma, odmiennymi światami, to można znaleźć kilka cech wspólnych, które pozwalają na funkcjonowanie obu podejść jednocześnie w tej samem organizacji. ITIL nie wyklucza DevOps i DevOps nie wyklucza ITIL. Można wykorzystać obie metodologie i stworzyć własne rozwiązanie dopasowane do potrzeb organizacji. Wydaje się, że to ITIL, zgodnie z dewizą „adopt and adapt” musi dopasować się do DevOps a nie odwrotnie. Wymaga to jednak poważnego zastanowienia się jak to zrobić.

Pytanie: Czy uważasz, że można pogodzić ITIL i DevOps i dlaczego?

Artykuł Czy ITIL i DevOps można pogodzić? pochodzi z serwisu Mariusz Siek.

Przejście z etapu projektowania i wytwarzania do etapu eksploatacji usługi IT, oprócz procesu walidacji i testowania, wymaga jeszcze zarządzenia wydaniami i wdrożeniami, które te wydania wprowadzą na produkcję. Żeby nie było, mamy dedykowany proces, który się tym zajmuje i pomaga nam abyśmy o niczym nie zapomnieli. Jakie są najważniejsze elementy tego procesu, chciałbym napisać w tym artykule.

Cele

Proces zarządzania wydaniami i wdrożeniami odpowiada za zaplanowanie, zaharmonogramowanie i kontrolę budowania, testowania i wdrażania wydań oraz dostarczenie nowych funkcjonalności dla biznesu, jednocześnie zapewniając integralność istniejących na produkcji usług.

Realizacja tej odpowiedzialności wymaga:

• Zdefiniowania i uzgodnienia planów wydań i wdrożeń z wszystkimi udziałowcami, w tym z klientem
• Przygotowania i przetestowania pakietu wydania, składającego się z elementów konfiguracji, które są ze sobą spójne
• Zapewnienia integralności pakietu wydania oraz komponentów wchodzących w jego skład, w całym procesie wdrożenia
• Przechowywania pakietów wydań w repozytorium wydań (Definitive Media Library)
• Wdrożenia pakietu wydania z repozytorium wydań na produkcję, zgodnie z planem i harmonogramem
• Zagwarantowania, że wszystkie pakiety wydania mogą być monitorowane, instalowane, testowane, weryfikowane, odinstalowywane i wycofane
• Zagwarantowania, że nowa lub zmieniona usługa, w zakresie technologii i organizacji, dostarcza oczekiwane wymagania funkcjonalne i niefunkcjonalne
• Rejestrowania i zarządzania ryzykami i zagadnieniami, związanymi z nową lub zmienioną usługą oraz podejmowanie działań naprawczych
• Zagwarantowania transferu wiedzy do użytkowników aby mogli lepiej wykorzystać dostarczane usługi
• Zagwarantowania przekazania umiejętności i wiedzy do zespołu utrzymania, aby mógł świadczyć wsparcie zgodne z SLA

Zakres

Zakres procesu zarządzania wydaniami i wdrożeniami obejmuje procesy, systemy i funkcje, wymagane do przygotowania pakietu, testowania i wdrożenia wydania na produkcję.

W szczególności dotyczy elementów konfiguracji takich jak:

• Infrastruktura sprzętowo-programowa
• Zasoby wirtualne jak serwery i dyski
• Aplikacje i oprogramowanie standardowe
• Szkolenia na użytkowników i zespołów utrzymania
• Usługi oraz związane z nimi umowy np SLA, katalog usług

Proces zarządzania wydaniami i wdrożeniami:

• Odpowiada za testowanie wydania, jednak samo testowanie jest wykonywane w ramach procesu walidacji i testowania
• Nie odpowiada za akceptację zmian, która jest przeprowadzana w procesie zarządzania zmianą

Korzyści

Dobrze i efektywnie działający proces zarządzania wydaniami i wdrożeniami, przynosi następujące korzyści:

• Zmiana dostarczana jest szybciej, optymalnie kosztowo i ze zminimalizowanym ryzykiem
• Gwarancja wykorzystania nowych lub zmienionych usług przez klientów i użytkowników, w sposób, który wspiera cele biznesowe
• Poprawa spójnego podejścia do wdrożenia w zakresie zmiany biznesowej, zespołów usługowych, dostawców i klientów
• Przyczynienie się do spełnienia wymagań audytowych, związanych z monitorowaniem w całym procesie wdrożenia
• Zmniejszenie kosztów dostarczanej usługi – zespoły IT nie muszą rozwiązywać problemów związanych z wdrożeniem

Pilot

Bardzo użytecznym rozwiązaniem przy wdrażaniu nowych usług jest skorzystanie z pilota, czyli wdrożenie usług tylko dla wybranych użytkowników. Należy jedna zwrócić uwagę na właściwe dobranie liczby użytkowników. Jeżeli użytkowników będzie za mało, to weryfikacja będzie nie wystarczająca i nie zostaną wykryte błędy, które wystąpią następnie na produkcji. Jeżeli użytkowników będzie za dużo, to nie uzyskamy odpowiedniej elastyczności i prędkości, w osiągnięciu oczekiwanych korzyści pilota.

Ważne jest aby dobrze ustalić kryteria, na podstawie których będziemy oceniali, czy pilot zakończył się sukcesem i możemy wdrożyć usługę dla wszystkich użytkowników.

Odpowiednie przygotowanie i przetestowanie wydania, pozwala na jego sprawne przeprowadzenie na produkcji i zminimalizowanie niedostępności usług dla biznesu. Bardzo dużo zależy od pakietów instalacyjnych, które wykorzystywane są do wdrożenia wydania na produkcji, dlatego trzeba zwrócić szczególną uwagę, na ich przygotowanie. Najważniejsze aspekty to kompletność i instrukcje instalacji oraz poprawność przygotowanych paczek. Dobrze wykonana praca, zaowocuje krótszym czasem trwania wdrożenia i mniejszą ilością błędów, które podczas niego wystąpią. Warto poświęcić czas i energię w proces zarządzania wydaniem i wdrożeniami, aby zagwarantować sobie wysoki poziom usług na produkcji.

Pytanie: Jak często wdrażasz wydania na produkcję?

Artykuł Zarządzanie wydaniami i wdrożeniami pochodzi z serwisu Mariusz Siek.

W grupie procesów, odpowiedzialnych za przejście z etapu projektowania i wytwarzania do etapu eksploatacji usługi IT, jest w ITIL nowy proces zarządzania walidacją i testowaniem usług IT. Nie jest to nowa dziedzina, bo samo testowanie oprogramowania ma długą historię i jest samodzielnym obszarem. Ponieważ jest on bardzo ważny w dostarczaniu poprawnie działających usług, warto zastanowić się, jakie są jego najważniejsze elementy i na co trzeba zwrócić uwagę. Uważam, że proces ten nie jest właściwie doceniany i wykorzystywany, a konsekwencje tego widzimy w działaniu usług IT na produkcji.

Konsekwencje

Czy na co dzień zastanawiamy się, jaka jest różnica pomiędzy walidacją a testowaniem?

Walidacja to sprawdzenie, czy usługa spełnia zdefiniowane wymagania biznesu a testowanie, ma za zadanie, wykrycie wszystkich błędów w działaniu usługi.

Jakie są konsekwencje, niewystarczającej i źle przeprowadzonej walidacji i testowania usługi?

• Występują incydenty, wynikające z błędów lub niewłaściwego zrealizowania wymagań biznesu
• Wymagane jest większe wsparcie Service Desk w wyjaśnieniu i tłumaczeniu, niewłaściwie działających usług
• Trudniej zdiagnozować i wykryć błędy i problemy w funkcjonowaniu usługi
• Mamy większe koszty, związane z naprawą błędów na produkcji, zamiast podczas etapu testowania rozwiązania
• Dajemy mniejszą wartość usługi dla klienta, z powodu jej nieefektywnego działania

Cele

Głównym celem procesu walidacji i testowania usługi jest zapewnienie, że nowe lub zmienione usługi IT, spełniają wymagania projektowe i odpowiadają na potrzeby biznesu.

Ważnymi elementami procesu są również:

• Zagwarantować, że wydanie zawiera nową lub zmienioną usługę, która przyniesie oczekiwane rezultaty i wartość dla klienta w ustalonych kosztach, zasobach i warunkach brzegowych.
• Zapewnić odpowiednią jakość wydaniu i wszystkim elementom wchodzącym w jego skład
• Sprawdzić, że usługa spełnia wymagania funkcjonalne biznesu i dostarcza oczekiwaną użyteczność
• Zweryfikować, że usługa spełnia wymagania niefunkcjonalne takie jak: dostępność, wydajność, niezawodność, bezpieczeństwo
• Potwierdzić, że wymagania klienta dla nowych lub zmienionych usług są poprawnie zdefiniowane oraz podjęte zostały działania aby wyeliminować błędy przed wdrożeniem na produkcję
• Zaprojektować i wdrożyć, dobrze zorganizowany proces walidacji i testowania, który dostarczy wiarygodnych dowodów, że zostały spełnione wymagania funkcjonalne i niefunkcjonalne dla usługi
• Wykryć, ocenić i zaadresować zagadnienia, błędy i ryzyka na etapie wdrożenia (przejścia)

Zakres

Proces walidacji i testowania jest wykorzystywany do:

• Oceny jakości wszystkich aspektów związanych z usługą i jej dostawcą
• Weryfikacji usług dostarczanych przez wewnętrzne zespoły, jak i dostawcę zewnętrznego.
• Nowych usług, jak i dla zmian wprowadzanych w usługach lub ich komponentach.
• Wykonania weryfikacji w środowisku biznesowym i sprawdzenia wszystkich aspektów, związanych z działaniem usługi, w tym takich, które nie zależą od dostawcy usługi np. sieć publiczną (Internet), zasoby klienta.

Testowanie bardzo mocno związane jest z procesem zarządzania wydaniem i wdrożeniem i wspiera go bezpośrednio, na różnych etapach.

Wyniki testów wykorzystywane są przez proces zarządzania zmianą, podczas oceny zmiany i ryzyka jej wprowadzenia na produkcję.

Korzyści

Jakie korzyści daje dobrze funkcjonujący proces walidacji i testowania:

• Zadowolony biznes, klient i użytkownik, z dostarczenia usługi spełniającej wymagania funkcjonalne i niefunkcjonalne
• Mniej błędów na środowisku produkcyjnym zgłaszanych przez użytkowników
• Większą dostępność usług dla użytkowników, związaną z mniejszą liczbą awarii
• Mniejsze koszty świadczenia usługi, wynikające z napraw na etapie testowania zamiast na produkcji
• Listę znanych błędów, wykrytych na etapie testowania, które nie zostały naprawione i wymagają obsługi na etapie utrzymania

Rodzaje testów

Ile mamy rodzajów testów?

• Testy funkcjonalne, nazywane również testami użyteczności, które powinny zawierać
  • Sprawdzenie dostępu do usługi (logowanie, zmiana hasła itp)
  • Weryfikację działania procesów biznesowych i wymaganych procedur
  • Przekazanie wiedzy i kompetencji
  • Kompatybilność i współdziałanie z innymi usługami i komponentami
  • Sprawdzenie dokumentacji
• Testy wydajnościowe, sprawdzające pojemność usługi
• Testy dostępności, weryfikujące wymagania związane z wysoką dostępnością
  • Testy kopii zapasowej i odtwarzania z backupu
  • Testy ciągłości działania
• Testy bezpieczeństwa, sprawdzające wszystkie aspekty związane z bezpieczeństwem
• Testy konfiguracji, tworzenia i instalacji wydania na produkcji
• Testy mierzenia i raportowania SLA dla usługi
• Testy procedur i instrukcji związanych z utrzymaniem usługi

W przypadku procesu walidacji i testowania, sprawdza się dobrze znana zasada z wojska: im więcej potu na ćwiczeniach tym mniej krwi i ofiar w walce i boju. Im więcej czasu, energii i zasobów poświęcimy na rzetelne przetestowanie usługi przed wdrożeniem, tym mniej problemów będziemy mieli, z działaniem tej usługi na produkcji. Oczywiście jak wszędzie musimy znaleźć złoty środek, aby etap testów nie sparaliżował nam cyklu wprowadzania zmian. Z drugiej strony nie możemy sobie pozwolić aby niewystarczająco przetestowane usługi, były implementowane na środowisku produkcyjnym i zaburzały prawidłowe działanie tej lub innych usług. Pamiętajmy, że koszt usunięcia błędów na etapie testowania jest mniejszy, niż gdy musimy je rozwiązywać na działającym środowisku produkcyjnym.

Pytanie: Których rodzajów testów nie wykonujesz i dlaczego?

Artykuł Walidacja i testowanie usług IT pochodzi z serwisu Mariusz Siek.

Napisałem już dwa artykuły o zarządzaniu zmianą, jednak cały czas mam nieodparte wrażenie, że nie wyczerpałem tematu. Po pierwsze dlatego, że proces jest bardzo złożony i może mieć kilka wariantów. Po drugie, jest jednym z ważniejszych procesów ITSM w każdej organizacji. Na co jeszcze warto zwrócić uwagę, co jest istotnym elementem, który decyduje, czy dobrze czy źle działa on u nas w firmie?

Rodzaje zmian

Mamy trzy rodzaje zmian, które możemy wprowadzać w organizacji: standardowa, pilna i normalna. Z każdą wiąże się inny sposób postępowania i inny jest cel jej zastosowania. Można powiedzieć, że dobieramy narzędzie do pracy jaką mamy wykonać.

• Zmiana standardowa stosowana jest w sytuacji niskiego ryzyka, powszechnie wykonywanych aktywności, dla których określone są procedury i instrukcje i jest wstępnie autoryzowana
• Zmiana pilna wykorzystywana jest, gdy musimy wprowadzić zmianę tak szybko jako to możliwe w celu rozwiązania krytycznego incydentu lub wdrożenia poprawki bezpieczeństwa
• Zmiana normalna obejmuje pozostałe przypadki, nie wskazane dla zmiany standardowej i pilnej.

Zmiana standardowa

Każda zmiana standardowa powinna korzystać z ustalonego modelu zmian, który określa jak z nią postępować, począwszy od tego, jak powinna być rejestrowana, przez sposób zarządzania po jak powinna być wdrażana.

Dla zmiany standardowej jej autoryzacja jest zdelegowana z menedżera zmian na inną rolę, np zarządzającego licencjami, service desk, dział zakupów itp.

Najważniejsze elementy związane ze zmianą standardową to:

• Ustalone zdarzenie wyzwalające zmianę takie jak service request lub wyjątek powstały w procesie zarządzania zdarzeniami
• Zadania są dobrze znane, udokumentowane i sprawdzone
• Autoryzacja zmiany jest z góry przekazana do innych ról
• Akceptacja finansowa jest z góry ustalona lub pod kontrolą wnioskującego o zmianę
• Ryzyko jest zwykle niskie i dobrze rozumiane

Jeżeli zmiana spełnia powyższe kryteria, może być wdrażana w tym trybie. Jest to duże ułatwienie i uproszczenie, dla wprowadzania znacznej ilości zmian. Sprawdź jak dużo zmian możesz wprowadzać w ten sposób i korzystaj z niego codziennie.

Zmiana pilna

Ten rodzaj zmiany powinien być wykorzystywany tylko w wyjątkowych sytuacjach. Głównie gdy usługa IT przestaje działać a sposobem na jej uruchomienie jest wprowadzenie zmiany. Mimo krótkiego czasu na procesowanie zmiany nie należy zapominać o:

• Uzyskaniu akceptacji zmiany przez radę ds. zmian pilnych (ECAB). Szczególnie taka zmiana wymaga akceptacji, odpowiednich osób, aby nie wprowadziła więcej i większych problemów, niż te które ma rozwiązać. Procedura dla zmiany pilnej musi jasno określać, kto podejmuje decyzje o wprowadzeniu tego rodzaju zmiany.
• Przetestowanie zmiany, przed wdrożeniem na produkcję. Mimo pośpiechu i chęci jak najszybszego przywrócenia usługi IT do działania, nie można pominąć kroku związanego z skutecznym sprawdzeniem, czy zaproponowane rozwiązanie jest prawidłowe i efektywnie rozwiąże awarię. Tylko w szczególnych przypadkach, można zdecydować o wdrożeniu zmiany, bez jej testowania. Powinna to jednak być świadoma i podjęta jednogłośnie decyzja.
• Ocenie wpływu zmiany w jednej usłudze na działanie pozostałych usług. Analizy wpływu musi być przeprowadzona i być podstawą do podjęcia decyzji o akceptacji zmiany.

Zmiana normalna jest nudna, dlatego nie będę się o niej się rozpisywał :-). Chciałem jednak zwrócić uwagę na jeden element, który powinien występować, dla każdej z rodzajów zmian.

Plan wycofania

Plan wycofania to bardzo ważny element dla wprowadzania zmian. Zawsze może coś pójść nie tak i musimy mieć plan postępowania na tę okoliczność. Wiem, że większość zespołów zakłada, że wszystko pójdzie dobrze i po co tracić czas na przygotowywanie planu wycofania. Jak jednak pokazuje życie, może zdarzyć się taka sytuacja i musimy być na nią przygotowani. Pamiętajmy, że plan wycofania powinien być przetestowany i uwzględniony w czasie trwania zmiany, a tym samym niedostępności usługi. Plan wycofania musimy mieć opracowany i przetestowany, zarówno dla zmiany normalnej jak i pilnej. W przypadku zmiany standardowej, możemy mieć go uwzględnionego w procedurze lub instrukcji, na podstawie której wykonywana jest zmiana.

Miałem świadomość, że proces zarządzania zmianą jest obszerny ale nie sądziłem, że pokazania jego najważniejszych elementów jest tak trudne w kilku artykułach. Wygląda na to, że będę musiał jeszcze pociągnąć ten temat w kolejnym tygodniu.

Podsumowując. Korzystaj ze wszystkich rodzajów zmian a zwiększysz sprawność swojej organizacji w zarządzaniu zmianami. Nie zapomina tylko, że każda zmian musi być zaakceptowana (autoryzowana), przetestowana i mieć plan wycofania.

Pytanie: Które rodzaje zmian najczęściej stosujesz i dlaczego?

Artykuł O czym zapomniałeś zarządzając zmianą? pochodzi z serwisu Mariusz Siek.