Niedoceniane utrzymanie

Podziel się
  • 5
  •  
  •  
  •  
  •  

utrzymanie

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.


Podziel się
  • 5
  •  
  •  
  •  
  •  

Dodaj komentarz

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.