Asset Management vs CMDB: różnica, która kosztuje organizacje więcej niż myślą
Asset management vs CMDB to różnica celu danych, a nie nazwy tabeli
Asset management, czyli zarządzanie zasobami IT, dotyczy przede wszystkim tego, co organizacja posiada i jak tym zarządza. Chodzi o laptopy, monitory, telefony, licencje, oprogramowanie, daty zakupu, gwarancje, przypisania do użytkowników i planowane wymiany.
W prostym ujęciu asset management pomaga odpowiedzieć na podstawowe pytania: co mamy, gdzie to jest, kto z tego korzysta, ile to kosztuje i kiedy trzeba podjąć działanie administracyjne.
CMDB, czyli baza danych konfiguracji, ma inny cel. Nie służy tylko do zapisania, że dany zasób istnieje. Jej zadaniem jest pokazanie, jak elementy środowiska IT są ze sobą powiązane i jaki wpływ mogą mieć na działanie usług.
CMDB pomaga więc zrozumieć nie tylko to, że organizacja ma określony serwer, aplikację albo bazę danych, lecz także to, od czego one zależą, które procesy wspierają i co może się wydarzyć, gdy jeden z tych elementów przestanie działać.
Różnica polega więc przede wszystkim na celu danych. Rejestr zasobów jest bliższy zakupom, cyklowi życia sprzętu, odpowiedzialności za mienie i kontroli kosztów. CMDB jest bliżej zarządzania usługami, zmianami, awariami, ryzykiem operacyjnym i wpływem komponentów na organizację.
Oba obszary mogą się uzupełniać, ale nie powinny być traktowane jako zamienne pojęcia.
Problem zaczyna się wtedy, gdy od jednego rejestru oczekuje się wszystkich odpowiedzi naraz. Arkusz z laptopami ma nagle wyjaśniać wpływ awarii sieci na aplikację sprzedażową, a baza relacji technicznych ma jednocześnie pilnować gwarancji, licencji i audytu sprzętu. W efekcie powstaje zbiór danych, który formalnie wygląda dojrzale, ale operacyjnie nie pomaga tam, gdzie powinien.
Sam rejestr zasobów pomaga kontrolować majątek, ale nie pokazuje pełnego wpływu awarii
Asset management jest potrzebny już na podstawowym etapie rozwoju środowiska IT. Bez niego trudno odpowiedzieć nawet na stosunkowo proste pytania: ile urządzeń znajduje się w organizacji, kto z nich korzysta, jakie oprogramowanie jest przypisane do sprzętu, które licencje wymagają odnowienia, co należy wycofać, a co wymienić.
Dobrze prowadzony rejestr zasobów ogranicza liczbę decyzji podejmowanych na wyczucie. Ułatwia planowanie budżetu, obsługę zwrotów sprzętu, przygotowanie audytu i pilnowanie podstawowych terminów.
Jest też istotny w obsłudze zgłoszeń, ponieważ agent nie musi za każdym razem pytać użytkownika o numer seryjny, model urządzenia czy podstawowe dane techniczne, jeśli są one dostępne w kontekście zgłoszenia.
Nie oznacza to jednak, że rejestr zasobów automatycznie staje się CMDB.
Lista laptopów, monitorów i licencji nie wyjaśnia zależności pomiędzy usługą, aplikacją, bazą danych, serwerem, urządzeniem sieciowym i grupą użytkowników. Informacja o numerze seryjnym komputera jest przydatna, ale sama w sobie nie mówi, czy awaria konkretnego komponentu zakłóci proces obsługi zamówień, dostęp do systemu finansowego albo pracę całego oddziału.
Dlatego porównanie CMDB vs asset register nie powinno być traktowane jako konflikt dwóch konkurencyjnych podejść. To przede wszystkim pytanie o zakres odpowiedzialności danych.
Rejestr zasobów pomaga kontrolować majątek. CMDB ma pomagać rozumieć zależności i wpływ elementów technicznych na usługi.
CMDB traci wartość, gdy staje się ewidencją wszystkiego
Jednym z najczęstszych mitów jest przekonanie, że im więcej danych znajduje się w CMDB, tym większą kontrolę organizacja ma nad zarządzaniem usługami.
Założenie wydaje się logiczne, dopóki nie pojawia się pytanie, kto ma te dane utrzymywać i aktualizować.
Każde dodatkowe pole, kategoria, relacja i atrybut wymagają właściciela, źródła aktualizacji i jasnego powodu istnienia. Jeśli tego brakuje, baza rośnie, ale jej wiarygodność stopniowo spada.
CMDB powinna porządkować informacje potrzebne do zarządzania usługami i konfiguracją. W podejściu ITIL 4 praktyka Service Configuration Management ma zapewniać dokładne i wiarygodne informacje o konfiguracji usług oraz elementach wspierających wtedy, gdy są one potrzebne.
Akcent nie pada więc na samą liczbę rekordów, lecz na użyteczność informacji w określonym momencie pracy.
Źle zaprojektowana CMDB szybko staje się projektem administracyjnym zamiast narzędziem operacyjnym. Zespół zaczyna zastanawiać się, czy każdy monitor powinien być elementem konfiguracji, czy drukarka powinna mieć relację z usługą oraz czy telefon służbowy jest zasobem, elementem konfiguracji, czy jednym i drugim.
To są uzasadnione pytania, ale tylko wtedy, gdy wynikają z realnego scenariusza wykorzystania danych.
CMDB nie musi być mała, ale musi być celowa. Relacja ma sens wtedy, gdy pomaga ocenić wpływ zmiany, skrócić diagnozę awarii albo zaplanować przerwę serwisową.
Najdroższe błędy powstają między zakupem, wsparciem i zmianą
Koszt pomylenia asset management z CMDB rzadko pojawia się jako osobna pozycja na fakturze za system. Znacznie częściej jest widoczny w opóźnieniach, błędnych decyzjach i pracy wykonywanej kilka razy przez różne osoby.
Pierwszym obszarem jest obsługa zgłoszeń.
Użytkownik zgłasza problem z aplikacją, ale dział wsparcia nie widzi od razu, jakiego sprzętu używa, kiedy urządzenie było aktualizowane i czy podobne zgłoszenia dotyczyły tej samej konfiguracji. Agent zaczyna więc od zbierania informacji, które mogłyby być dostępne od początku.
Drugim obszarem jest zarządzanie zmianą.
Organizacja może mieć proces akceptacji, formularze i spotkania, ale nadal nie wiedzieć, które usługi lub procesy zostaną potencjalnie zakłócone po zmianie konfiguracji. Sama informacja, że serwer istnieje, nie wystarcza. Potrzebny jest kontekst: co od niego zależy, kto korzysta z powiązanej usługi i jakie skutki może mieć jej niedostępność.
Trzecim obszarem są koszty, zakupy i odpowiedzialność.
Brak spójnych danych może prowadzić do zbyt wczesnych zakupów, odnowień nieużywanych licencji albo utrzymywania urządzeń, które powinny zostać wycofane. Jeżeli dodatkowo nie wiadomo, kto odpowiada za aktualność informacji, każde narzędzie zaczyna przedstawiać nieco inną wersję tej samej organizacji.
Uporządkowane dane zaczynają się od jasnych zasad, nie od nazwania bazy CMDB
W organizacjach, które dopiero porządkują dane o zasobach, problem jest zwykle bardziej podstawowy: brakuje jednego, wiarygodnego rejestru.
Informacje znajdują się w arkuszach, wiadomościach, systemie finansowym, dokumentach dostawców i głowach osób, które „zawsze wiedzą”.
W takim środowisku rozmowa o pełnej CMDB może być przedwczesna. Najpierw trzeba ustalić, jakie zasoby istnieją, skąd pochodzą dane, kto je aktualizuje i które informacje są rzeczywiście potrzebne w codziennej obsłudze.
Kolejny etap pojawia się wtedy, gdy organizacja ma już rejestr zasobów, ale dane nadal są oderwane od pracy działu wsparcia.
Informacje są formalnie dostępne, jednak agent nie korzysta z nich podczas obsługi zgłoszenia, ponieważ znajdują się w osobnym systemie, są niepełne albo niewystarczająco aktualne.
Wtedy warto połączyć ewidencję z procesem obsługi zgłoszeń. Nie po to, aby nazwać wszystko CMDB, lecz po to, aby skrócić drogę od problemu użytkownika do informacji potrzebnej do jego diagnozy.
Bardziej dojrzałe podejście zaczyna się wtedy, gdy organizacja rozróżnia, które dane służą kontroli majątku, a które pomagają zrozumieć wpływ poszczególnych komponentów na usługi.
Krytyczna aplikacja, baza danych i infrastruktura sieciowa wymagają innego modelu niż mysz komputerowa czy zapasowy monitor.
CMDB może być więc efektem lepiej zorganizowanego zarządzania operacyjnego, ale tylko wtedy, gdy powstaje na podstawie realnych potrzeb: obsługi zgłoszeń, zarządzania zmianą, analizy awarii oraz oceny wpływu na usługi.
Dane o zasobach są użyteczne wtedy, gdy wspierają obsługę zgłoszeń
Najbardziej użyteczne dane o zasobach to te, które pojawiają się bezpośrednio w toku pracy operacyjnej.
Jeżeli agent obsługujący zgłoszenie widzi urządzenie, użytkownika, historię powiązanych zgłoszeń i podstawowe informacje techniczne, diagnoza w mniejszym stopniu opiera się na zgadywaniu, a bardziej na procesie eliminacji.
To samo dotyczy menedżera IT.
Raport pokazujący wyłącznie liczbę zgłoszeń ma ograniczoną wartość, jeśli nie wiadomo, których zasobów, lokalizacji, typów urządzeń albo usług dotyczyły problemy. Sam wolumen zgłoszeń pokazuje przede wszystkim, jak dużo pracy miał dział.
Dopiero dodatkowy kontekst pozwala ustalić, czy problem dotyczył konkretnej klasy sprzętu, aplikacji, dostawcy, lokalizacji albo procesu.
Dlatego rozmowa o asset management vs CMDB nie powinna zaczynać się od wyboru etykiety w systemie. Powinna zaczynać się od scenariuszy pracy.
Ważniejsze jest ustalenie, w których momentach dane o zasobach powinny wspierać zespół: przy przyjmowaniu zgłoszenia, diagnozie awarii, planowaniu zmiany, analizie jakości obsługi, audycie albo raportowaniu.
Dopiero wtedy można ocenić, czy organizacji wystarczy prosty rejestr zasobów, czy potrzebuje bardziej dojrzałego modelu zależności.
Więcej o roli uporządkowanych procesów i danych w zarządzaniu usługami przeczytasz w artykule Czym są systemy ITSM?.
Warto również spojrzeć na ten temat z perspektywy codziennej pracy service desk i różnicy między reagowaniem na pojedynczy problem a uporządkowanym procesem zarządzania incydentami: Zarządzanie incydentami a service desk – jaka jest różnica?.
W Mint Service Desk zasoby warto porządkować w kontekście obsługi zgłoszeń
W tym kontekście Mint Service Desk warto traktować jako środowisko wspierające codzienną pracę działu wsparcia: obsługę zgłoszeń, porządkowanie odpowiedzialności, historię działań i komunikację z użytkownikami.
Dane o zasobach są najbardziej przydatne wtedy, gdy nie pozostają osobną ewidencją, lecz pojawiają się blisko spraw, których dotyczą.
W praktyce liczy się to, czy osoba obsługująca zgłoszenie ma dostęp do aktualnego kontekstu technicznego: informacji o sprzęcie, oprogramowaniu, konfiguracji lub wcześniejszych zgłoszeniach powiązanych z danym zasobem.
W Mint Service Desk taki kontekst może być budowany dzięki wykorzystaniu danych pochodzących z integracji oraz importów, między innymi z narzędzi wspierających zarządzanie sprzętem i środowiskiem IT.
Pozwala to przenieść informacje o sprzęcie, oprogramowaniu lub konfiguracji bliżej codziennej pracy agenta, bez konieczności ręcznego wyszukiwania ich w oddzielnych arkuszach czy systemach.
Więcej informacji znajduje się na stronie dotyczącej zarządzania zasobami w Mint Service Desk.
Korzyść z takiego rozwiązania jest przede wszystkim operacyjna, a nie wyłącznie administracyjna.
Agent, który widzi przy zgłoszeniu powiązany zasób, może szybciej ocenić kontekst problemu i ograniczyć liczbę dodatkowych pytań kierowanych do użytkownika.
Menedżer może natomiast uzyskać lepszy obraz tego, które urządzenia, typy zasobów lub obszary środowiska najczęściej pojawiają się w zgłoszeniach, pod warunkiem że dane są konsekwentnie uzupełniane, synchronizowane i wykorzystywane w procesie zgłoszeniowym.
Takie podejście może być odpowiednie dla organizacji, które nie chcą rozpoczynać od rozbudowanego projektu modelowania konfiguracji, ale jednocześnie widzą, że dane o zasobach powinny wspierać codzienną pracę działu IT.
Nie oznacza to automatycznego rozwiązania problemu jakości danych. Aktualność informacji nadal zależy od ich źródeł, integracji oraz zasad utrzymywania danych w organizacji.
Zmienia się jednak ich rola: przestają być wyłącznie zapisem w rejestrze, a zaczynają wspierać decyzje podejmowane podczas obsługi zgłoszeń.
Najpierw trzeba ustalić, czego dane mają dowodzić
Asset management i CMDB mogą się uzupełniać, ale nie są tym samym.
Rejestr zasobów pomaga kontrolować majątek, jego cykl życia, przypisania i podstawowe informacje operacyjne. CMDB ma sens wtedy, gdy potrzebne jest rozumienie zależności, wpływu poszczególnych elementów na usługi oraz ryzyka wynikającego ze zmian.
Pomylenie tych pojęć prowadzi zwykle do jednego z dwóch problemów: zbyt płytkiego rejestru, który nie pomaga w diagnozie, albo zbyt ambitnej bazy konfiguracji, której organizacja nie jest w stanie skutecznie utrzymać.
Dlatego warto zacząć nie od pytania, czy organizacja „ma CMDB”, lecz od pytania, jakie decyzje mają być dzięki danym mniej przypadkowe.
Czy chodzi o obsługę zgłoszeń, planowanie zakupów, ocenę wpływu awarii, zarządzanie zmianą, audyt, SLA czy raportowanie jakości pracy?
Dopiero odpowiedź na to pytanie pokazuje, czy potrzebny jest prosty asset register, model konfiguracji, czy etap pośredni, w którym dane o zasobach są wykorzystywane dokładnie tam, gdzie powstaje praca.
Najdroższa baza danych to nie ta, która ma najwięcej pól.
Najdroższa jest ta, której wszyscy pilnują, ale nikt nie wykorzystuje do podjęcia lepszej decyzji.
Chcesz sprawdzić, jak połączyć dane o zasobach z codzienną obsługą zgłoszeń w Mint Service Desk? Skontaktuj się z nami.
