Jak zacząć budować użyteczny CMDB bez wielkiego programu transformacyjnego
Administrator otrzymuje zgłoszenie dotyczące problemu z aplikacją, ale przed rozpoczęciem diagnozy musi ustalić, na jakim urządzeniu pracuje użytkownik, jaka wersja systemu jest zainstalowana i czy podobna awaria występowała wcześniej. Informacje istnieją, tylko są rozproszone między arkuszami, narzędziami administracyjnymi i wiadomościami. Właśnie w takich sytuacjach fraza CMDB for mid-sized IT teams, czyli CMDB dla średnich zespołów IT, przestaje oznaczać rozbudowany projekt architektoniczny, a zaczyna dotyczyć jakości codziennych decyzji.
Użyteczny model CMDB zaczyna się od jakości decyzji, a nie od kompletności danych
Wiele inicjatyw związanych z CMDB rozpoczyna się od próby opisania całego środowiska: urządzeń, aplikacji, usług, lokalizacji, właścicieli, umów i zależności technicznych. Na poziomie koncepcyjnym brzmi to poprawnie. W praktyce szybko powstaje projekt wymagający wielu integracji, rozbudowanego modelu danych i stałej pracy nad ich aktualnością.
Dla średniej organizacji pełne odwzorowanie środowiska rzadko jest właściwym punktem startu. Najpierw warto ustalić, przy których decyzjach brak danych regularnie opóźnia obsługę albo zwiększa ryzyko błędu. Może chodzić o identyfikację urządzenia użytkownika, ustalenie właściciela aplikacji, ocenę wpływu awarii lub przekazanie zgłoszenia do właściwego zespołu.
Zmiana perspektywy jest istotna. Zamiast pytać, jakie informacje da się zgromadzić, należy sprawdzić, których informacji brakuje w momencie podejmowania konkretnej decyzji. Wtedy można określić, co powinno znaleźć się w pierwszym zakresie modelu CMDB.
Brak wiarygodnego kontekstu ma również konsekwencje biznesowe. Wydłuża diagnozę, zwiększa zależność od wiedzy pojedynczych administratorów i utrudnia ocenę, które problemy wymagają pilnej reakcji. Zespół może być zajęty przez cały dzień, a mimo to część czasu przeznaczać na odtwarzanie informacji, które organizacja formalnie już posiada.
CMDB nie powinno więc powstawać po to, aby stworzyć kompletną ewidencję. Powinno poprawiać sposób podejmowania decyzji operacyjnych.
CMDB dla średnich zespołów IT: jeden problem operacyjny powinien wyznaczać zakres
W średnich zespołach IT barierą rzadko jest całkowity brak danych. Informacje o urządzeniach mogą znajdować się w narzędziu do zarządzania stacjami roboczymi, dane o użytkownikach w katalogu tożsamości, a wiedza o aplikacjach w dokumentacji prowadzonej przez administratorów. Problem polega na tym, że dane te nie zawsze są dostępne tam, gdzie są potrzebne.
W rzeczywistości warto zacząć od jednego procesu, w którym brak kontekstu regularnie zwiększa koszt obsługi. Może to być diagnozowanie problemów sprzętowych, obsługa dostępu do aplikacji, przygotowanie stanowiska dla nowego pracownika albo analiza powtarzających się awarii.
Dla wybranego scenariusza należy ustalić, jakiej decyzji nie można dziś podjąć bez dodatkowych ustaleń, jakie dane są potrzebne do jej podjęcia, w którym systemie znajdują się obecnie, kto odpowiada za ich poprawność oraz gdzie powinny być widoczne podczas pracy.
Taki zakres jest możliwy do oceny. Można sprawdzić, czy dane rzeczywiście ograniczają ręczne ustalenia i czy zmieniają sposób obsługi zgłoszeń. Znacznie trudniej ocenić powodzenie projektu, którego celem jest po prostu „zbudowanie kompletnego CMDB”.
Jeden scenariusz nie rozwiąże wszystkich problemów organizacji. Pozwala jednak zweryfikować model odpowiedzialności, źródła danych i sposób ich wykorzystania, zanim projekt zostanie rozszerzony na kolejne obszary.
Minimalny model danych powinien wynikać z konkretnego scenariusza użycia
Każdy dodatkowy typ obiektu, pole i relacja zwiększają koszt utrzymania modelu CMDB. Trzeba wskazać źródło danych, sposób aktualizacji, osobę odpowiedzialną za poprawność i regułę postępowania w przypadku sprzecznych informacji.
Dlatego pierwszy model powinien obejmować wyłącznie elementy potrzebne w wybranym procesie. Jeżeli celem jest usprawnienie obsługi zgłoszeń sprzętowych, nie trzeba od razu odwzorowywać wszystkich usług biznesowych, serwerów i zależności aplikacyjnych. Wystarczający może być ograniczony zestaw danych opisujących urządzenie oraz jego użytkownika.
Przykładowy scenariusz może wyglądać następująco. Do działu wsparcia trafia zgłoszenie od pracownika, który ma problem z komputerem, ale nie podaje żadnych szczegółów poza ogólnym opisem usterki. Osoba obsługująca zgłoszenie musi więc najpierw ustalić, z jakiego urządzenia korzysta użytkownik, gdzie ono się znajduje i jaka jest jego konfiguracja. Zamiast dopytywać o te informacje w kilku wiadomościach, widzi je bezpośrednio przy zgłoszeniu, ponieważ dane o urządzeniu są pobierane z narzędzia do zarządzania stacjami roboczymi i utrzymywane przez zespół odpowiedzialny za ich administrację. Dzięki temu może szybciej przejść do diagnozy problemu, a użytkownik nie musi odpowiadać na dodatkowe pytania o rzeczy, które organizacja już powinna wiedzieć.
Po sprawdzeniu takiego scenariusza warto dodawać kolejne pola lub relacje. Rozszerzenie może obejmować na przykład informacje o gwarancji, modelu urządzenia albo wcześniejszych zgłoszeniach. Każdy nowy element powinien jednak odpowiadać na jasno określone pytanie operacyjne.
Minimalizm nie świadczy o rezygnacji z rozwoju, ale zakłada, że zakres rośnie wraz z potwierdzoną wartością danych, a nie wraz z liczbą możliwości technicznych.
Import powinien wynikać z wcześniejszego wskazania systemu nadrzędnego
Import danych często traktuje się jako początek budowy CMDB. Tymczasem powinien być konsekwencją wcześniejszego ustalenia, który system jest nadrzędnym źródłem danych dla danego typu informacji.
Jeżeli dane o urządzeniach pochodzą z narzędzia administracyjnego, należy zdecydować, czy właśnie tam są aktualizowane i korygowane. Jeżeli dane użytkowników są pobierane z katalogu tożsamości, warto określić, które pola mogą być modyfikowane w innych systemach, a które powinny pozostać wyłącznie informacją referencyjną.
Bez takich zasad łatwo utworzyć kilka wersji tego samego rekordu. W jednym miejscu urządzenie jest przypisane do użytkownika, w drugim do działu, a w arkuszu do konkretnej lokalizacji. Każda informacja może być częściowo poprawna, ale zespół nadal nie wie, na której powinien oprzeć decyzję.
Przed pierwszym importem warto ustalić system nadrzędny, sposób identyfikowania rekordów, właściciela danych oraz zasady obsługi duplikatów i błędów. Należy również określić, kiedy nieaktualne informacje są wycofywane. Bez tych reguł import może jedynie szybciej rozpowszechniać niespójne dane.
Integracja może przyspieszyć przesyłanie informacji. Nie rozstrzygnie jednak, które dane są właściwe ani kto odpowiada za ich jakość. Technologia automatyzuje ustalone reguły, ale ich nie zastąpi.
Relacje powinny opisywać tylko te zależności, które wpływają na decyzje
Relacje są jednym z najbardziej atrakcyjnych elementów modelu CMDB. Pozwalają pokazać, że aplikacja działa na określonym serwerze, wspiera konkretna usługę i ma przypisanego właściciela. Problem zaczyna się, gdy liczba relacji rośnie szybciej niż zdolność organizacji do ich aktualizowania.
W pierwszym etapie warto opisywać wyłącznie zależności, które wpływają na diagnozę, przypisanie odpowiedzialności, ocenę wpływu awarii lub sposób obsługi zgłoszenia. Relacje takie jak użytkownik-urządzenie, aplikacja-właściciel oraz usługa-zespół mogą pomóc w diagnozie problemu, ułatwić eskalację i wskazać użytkowników lub usługi, których dotyczy problem.
Jeżeli dana relacja nie wpływa na decyzję, trudno uzasadnić koszt jej utrzymania wyłącznie potrzebą kompletności. Pełna mapa zależności może dobrze wyglądać podczas prezentacji projektu, lecz jej wartość operacyjna zależy od tego, czy z biegiem czasu nadal odzwierciedla środowisko.
Jakość modelu CMDB mierzy się wykorzystaniem, a nie liczbą danych
Liczba rekordów nie jest wiarygodnym miernikiem skuteczności. Nie pokazuje, czy dane pomagają szybciej diagnozować problemy, ograniczać liczbę dodatkowych pytań albo właściwie oceniać wpływ awarii. Podobnie liczba integracji nie świadczy jeszcze o użyteczności modelu.
Jeżeli informacje nie zmieniają sposobu podjęcia decyzji, ich obecność w modelu trudno uzasadnić samą kompletnością ewidencji. Dlatego warto okresowo przeglądać pola i relacje, które nie są wykorzystywane, oraz sprawdzać, czy nadal mają uzasadnienie procesowe, integracyjne lub audytowe. Rozbudowywanie modelu bywa przedstawiane jako oznaka rozwoju, choć czasami świadczy przede wszystkim o braku kontroli nad zakresem.
Szersze omówienie relacji między ewidencją zasobów a pracą operacyjną znajduje się w materiale wyjaśniającym, dlaczego samo CMDB to za mało, gdy informacje pozostają poza codzienną obsługą zgłoszeń.
Pierwszy etap uznaje się za zakończony, gdy dane mają przypisanego właściciela i konkretne zastosowanie
Pierwszy zakres budowy CMDB nie musi obejmować wielu obiektów. Powinien jednak działać jako zamknięty proces. Sam import danych nie oznacza jeszcze, że etap został zakończony.
Za gotowy można uznać zakres, w którym dane są wykorzystywane w jednym jasno wskazanym procesie, a jednocześnie wiadomo, z jakiego systemu pochodzą, kto odpowiada za ich poprawność oraz w jaki sposób są aktualizowane. Istotne jest również, aby istniała procedura zgłaszania i poprawiania błędów, dzięki czemu zespół nie musi regularnie odtwarzać tych samych informacji ręcznie.
Wtedy warto przejść do kolejnego scenariusza. Może nim być powiązanie aplikacji z właścicielami, określenie podstawowych zależności między usługami albo rozszerzenie informacji o urządzeniach.
Takie podejście pozwala rozwijać CMDB etapami zgodnymi z dojrzałością organizacji. W pierwszej kolejności budowana jest widoczność danych. Następnie informacje zaczynają być wykorzystywane przy zgłoszeniach i innych jasno określonych działaniach operacyjnych. Później można rozwijać bardziej złożone zależności.
Przeskoczenie od razu do rozbudowanego modelu zwykle tworzy więcej danych, niż organizacja jest w stanie utrzymać. Rozwój powinien następować wtedy, gdy wcześniejszy etap ma właścicieli, reguły i potwierdzone zastosowanie.
CMDB jest przy tym tylko jednym z wielu elementów szerszego podejścia do organizacji usług. Zależność między zgłoszeniami, odpowiedzialnością i procesami szerzej opisuje materiał wyjaśniający, czym są systemy ITSM.
Wartościowe dane to dane dostępne, gdy są potrzebne
Informacje o zasobach nie powinny funkcjonować wyłącznie jako osobna ewidencja. Ich wartość leży w wykorzystaniu przy obsłudze konkretnego zgłoszenia.
W Mint Service Desk dane o zasobach mogą być dostarczane przez integracje, między innymi z baramundi i Lansweeper, a także przez import CSV.
Praktyczną wartość stanowią informacje o zasobie dostępne w kontekście zgłoszenia, którego dotyczą. Dostępność tych informacji przy zgłoszeniu może ograniczyć liczbę dodatkowych ustaleń i ułatwić ocenę związku między problemem, urządzeniem oraz użytkownikiem. Historia zgłoszenia pozwala jednocześnie zachować kontekst podjętych działań.
Narzędzie nie ustali automatycznie właścicieli danych ani reguł ich jakości. Może natomiast przybliżyć informacje techniczne do miejsca, w którym są podejmowane decyzje operacyjne.
Dodatkowy kontekst dotyczący sposobu wykorzystania informacji o zasobach można znaleźć na stronie opisującej system zarządzania zasobami.
Mały zakres ma sens, jeśli prowadzi do mierzalnej zmiany w pracy
Kryterium sukcesu może dotyczyć liczby sytuacji, w których pracownik działu wsparcia musi ponownie pytać o urządzenie, czasu potrzebnego na wskazanie właściciela aplikacji albo odsetka zgłoszeń, przy których dane o zasobie są rzeczywiście wykorzystywane. Wartość docelową należy określić na podstawie warunków konkretnej organizacji.
Budowa użytecznego CMDB bez wielkiego programu transformacyjnego wymaga przede wszystkim dyscypliny zakresu. Należy wybrać jeden problem, określić minimalny model danych, wskazać system nadrzędny i przypisać odpowiedzialność za jakość informacji.
Pierwszy etap nie musi dawać pełnej mapy środowiska. Powinien jednak zmienić sposób obsługi konkretnego procesu. Jeżeli zmniejsza się liczba dodatkowych ustaleń, łatwiej przypisać odpowiedzialność i szybciej ocenić wpływ problemu, model zaczyna spełniać swoje zadanie.
Po potwierdzeniu takiej wartości warto dodawać kolejne dane i zależności. Rozbudowany model może powstać później, jeżeli organizacja rzeczywiście go potrzebuje. Użyteczne CMDB zaczyna się jednak nie od liczby rekordów, lecz od decyzji, której nie trzeba już podejmować na podstawie domysłów.
