CMDB w obsłudze klienta — zastosowania i aktualność danych

CMDB to baza elementów konfiguracji (configuration items) i relacji między nimi. W obsłudze klienta daje agentowi kontekst potrzebny do zrozumienia zgłoszenia. Może przechowywać 4 rodzaje informacji: właścicieli zasobów, gwarancje, harmonogramy konserwacji i umowy serwisowe.¹ Artykuł pokazuje, jak zaprojektować taką bazę, połączyć ją ze zgłoszeniami i dbać o aktualność danych.

Czym jest CMDB w obsłudze klienta?

CMDB opisuje, z czego składa się usługa i od czego zależą jej części. Łączy usługę zgłaszaną przez klienta z infrastrukturą oraz oprogramowaniem potrzebnymi do jej działania. Agent może dzięki temu ustalić, czego dotyczy problem i jakie inne usługi zależą od tego samego elementu. W bazowym modelu ServiceNow każdy element ma trzy obowiązkowe pola: nazwę, opis i status².

Mapowanie relacji (Relationship Mapping) pokazuje, jak komponenty IT, takie jak aplikacje, bazy danych i serwery, wspólnie dostarczają usługę. Informacja „aplikacja korzysta z bazy danych” mówi agentowi więcej niż dwa osobne rekordy zasobów. W modelu ServiceNow relację między dwoma elementami konfiguracji można odczytać w obu kierunkach: od nadrzędnego do podrzędnego i odwrotnie³.

Jakie elementy konfiguracji i relacje między nimi warto opisać?

Model CMDB powinien obejmować usługi dostępne dla klientów oraz komponenty konieczne do ich działania. Może rozróżniać usługę, aplikację, bazę danych, serwer i urządzenie sieciowe. Każda kategoria potrzebuje nazwy, identyfikatora, stanu i powiązań przydatnych przy ocenie wpływu awarii. W bazowym modelu atrybutów ServiceNow każdy element ma trzy obowiązkowe pola: nazwę, opis i status².

Relacje w CMDB muszą nazywać zależność, nie tylko łączyć rekordy. Opisy „usługa jest dostarczana przez aplikację” oraz „aplikacja korzysta z bazy danych” prowadzą agenta od objawu do komponentu. Bez określenia znaczenia relacji nie wiadomo, czy problem jednego elementu wpływa na drugi. ServiceNow podaje przykład odczytu w obu kierunkach: „Bond Trading zależy od lnux100” oraz „lnux100 jest używany przez Bond Trading”³.

Jak wyznaczyć zakres pierwszego wdrożenia?

Zakres wdrożenia CMDB warto wyznaczyć na podstawie usług, z którymi klienci zwracają się do zespołu obsługi. Model ma pomagać rozpoznać usługę, potrzebne do jej działania komponenty i zespół właściwy do rozwiązania problemu⁴. Na początek można przyjąć trzy wymagane pola elementu z modelu ServiceNow: nazwę, opis i status².

• Usługi objęte wdrożeniem to usługi, które zespół musi rozpoznawać w zgłoszeniach. Ich nazwy powinny odpowiadać nazwom używanym podczas przyjmowania spraw od klientów.
• Kategorie elementów konfiguracji powinny obejmować komponenty potrzebne do wyjaśnienia działania wybranych usług. Pozostałe kategorie można pominąć w początkowym modelu.
• Atrybuty elementów powinny odróżniać rekordy i określać ich stan. Jednolite nazwy zmniejszają ryzyko przypisania zgłoszenia do niewłaściwego komponentu.
• Typy relacji powinny wskazywać kierunek zależności między usługą a komponentem. Agent może wtedy prześledzić wpływ problemu bez zgadywania, co oznaczają połączenia.

Wynikiem wdrożenia CMDB jest ograniczony model usług i zależności. Powinien odpowiadać na pytania, które pojawiają się podczas obsługi zgłoszeń.

Czym baza konfiguracji różni się od spisu zasobów?

Baza konfiguracji i spis zasobów opisują ten sam składnik z różnych perspektyw. Serwer może być po prostu pozycją ewidencyjną albo częścią usługi zgłaszanej przez klienta. Poniższe porównanie pokazuje, jakie informacje daje każde podejście podczas obsługi sprawy.

Dane w tabeli: 5

CMDB odpowiada na pytanie, jak zasób uczestniczy w dostarczaniu usługi klientowi. Dla zespołu obsługi liczą się czytelne zależności, a nie sama liczba zgromadzonych rekordów.

Od zasobu do zgłoszenia: zastosowania bazy konfiguracji

CMDB łączy zasób wskazany w zgłoszeniu z usługą i innymi zależnymi komponentami. Agent widzi więc nie tylko nazwę urządzenia lub aplikacji, ale też możliwy wpływ awarii na klienta. Te same powiązania pomagają ocenić zakres analizy przed zmianą konfiguracji⁶. Sprawę można powiązać z incydentem, problemem lub zamówioną pozycją usługi – trzema typami wskazanymi w dokumentacji ServiceNow⁷.

Baza konfiguracji jako źródło kontekstu zgłoszenia

Baza konfiguracji daje kontekst wtedy, gdy agent potrafi wskazać element związany z objawem i prześledzić drogę do usługi klienta. W CMDB Aptien można mapować relacje między komponentami IT na potrzeby analizy zależności i wpływu.⁸ Taka mapa pomaga odróżnić problem pojedynczego elementu od problemu usługi, która od niego zależy. W obu przypadkach punktem wyjścia pozostaje konkretny rekord.

Jakie zasoby i zależności pomaga uporządkować baza konfiguracji?

CMDB porządkuje zasoby techniczne i ich związki z usługami świadczonymi klientom. Mapowanie zależności pokazuje, które komponenty wspierają usługę oraz które usługi trzeba uwzględnić przy incydencie lub planowanej zmianie. Nie każde połączenie oznacza jednak zależność awaryjną; przypisanie odpowiedzialności ma inne znaczenie niż relacja techniczna. W opublikowanym przykładzie zmiana serwera Win_test wskazała trzy zależne usługi aplikacyjne: A, B i C⁹.

• Zasób techniczny można powiązać z aplikacją, która z niego korzysta. Relacja wskazuje, gdzie szukać skutków jego awarii.
• Aplikację można powiązać z usługą widoczną dla klienta. Analiza przechodzi wtedy od komponentu do usługi, której dotyczy zgłoszenie.
• Planowaną zmianę można zestawić z zależnościami elementu konfiguracji. Pozwala to ustalić, które usługi trzeba uwzględnić przed wykonaniem prac.

Jak powiązać bazę konfiguracji z obsługą zgłoszeń?

Powiązanie CMDB ze zgłoszeniami wymaga przypisania sprawy do właściwego elementu konfiguracji i zachowania tego przypisania podczas obsługi. Dotyczy to incydentu, czyli nieplanowanego zakłócenia usługi, oraz problemu, w którym bada się przyczynę incydentów. Obejmuje też wniosek o usługę, czyli prośbę o standardowe działanie. Dokumentacja ServiceNow wskazuje pole elementu konfiguracji dla wszystkich trzech typów spraw: incydentu, problemu i zamówionej pozycji usługi⁷.

• Rejestracja zgłoszenia powinna pozwalać wskazać usługę lub element konfiguracji rozpoznany przez agenta. Wybrany rekord otwiera analizę zależności.
• Obsługa incydentu powinna korzystać z relacji elementu przy ustalaniu usług, na które problem może wpływać. Agent zachowuje identyfikator analizowanego elementu w zgłoszeniu.
• Analiza problemu powinna łączyć powtarzające się incydenty z badanym komponentem. Takie powiązanie oddziela objawy zgłaszane przez klientów od analizowanej przyczyny.
• Realizacja wniosku o usługę powinna wskazywać zasób objęty zamówionym działaniem. Aptien pozwala przypisywać zadania do elementów CMDB, również te związane z konserwacją zasobów i aktualizacją oprogramowania.⁸

Element konfiguracji przypisany do zgłoszenia daje zespołowi wspólny punkt odniesienia. Na jego podstawie można obsługiwać sprawę i oceniać jej wpływ na usługę.

Jak utrzymać aktualność danych w CMDB?

CMDB zachowuje aktualność, jeśli po zmianie zasobu lub usługi ktoś poprawia rekord i jego relacje. Właściciel danych powinien następnie skontrolować wynik. Śledzenie zmian zapisuje, co zmieniło się w elemencie konfiguracji, i pozwala odróżnić obecny stan od wcześniejszych ustawień. Automatyczne wykrywanie oraz importy pomagają zbierać dane, ale nie ocenią, czy komponent nadal wspiera daną usługę. W wersji Brazil systemu ServiceNow domyślna reguła CMDB Health uznaje element konfiguracji za nieaktualny, jeśli nie aktualizowano go przez 60 dni¹⁰.

Jak aktualizować elementy konfiguracji i ich relacje?

Aktualizacja CMDB musi objąć element i jego powiązania z usługami. Inaczej agent może oprzeć analizę zgłoszenia na zależności, która już nie istnieje. Udział osieroconych relacji oblicza się przez podzielenie ich liczby przez liczbę wszystkich relacji; przykładowy pulpit ServiceNow pokazuje 0 z 1551, czyli 0%¹¹.

• Zmiana zasobu powinna uruchamiać poprawę jego rekordu w CMDB. Aptien umożliwia dokumentowanie zmian zasobów i konfiguracji.⁸
• Automatyczne wykrywanie pomaga identyfikować komponenty infrastruktury. Wyniki trzeba dopasować do istniejących rekordów, by nie tworzyć duplikatów.
• Import danych powinien aktualizować rekord rozpoznany po stałym identyfikatorze. Wcześniej trzeba ustalić, które pola pochodzą z systemu źródłowego.
• Zmiana relacji wymaga poprawienia połączenia komponentu z usługą, jeśli zmienił się sposób jej dostarczania. Właściciel usługi powinien ocenić skutki tej zmiany dla obsługi zgłoszeń¹².

Aktualny rekord wraz z aktualną relacją daje agentowi obraz bieżącej konfiguracji. To na nim powinien opierać analizę zgłoszenia.

Jak kontrolować kompletność, dokładność i aktualność danych?

Kontrola jakości CMDB powinna osobno sprawdzać kompletność pól i relacji oraz zgodność rekordów z rzeczywistym stanem. Trzeba też ustalić, czy ostatnie zmiany trafiły już do bazy. Mierzalny przykład daje domyślna reguła CMDB Health w wersji Brazil ServiceNow: próg aktualności wynosi 60 dni¹⁰.

• Kompletność danych należy sprawdzać według wymaganych pól dla każdej kategorii elementów. Osobnej uwagi wymagają usługi bez opisanych zależności.
• Dokładność danych wymaga porównania rekordu z uzgodnionym źródłem informacji o zasobie. Właściciel rekordu powinien wyjaśnić każdą wykrytą rozbieżność.
• Aktualność danych trzeba oceniać przez zestawienie zmian zasobów z aktualizacjami CMDB. Niezakończona poprawka powinna pozostać widoczna do czasu zmiany rekordu¹².

Kontrola CMDB wskazuje rekordy wymagające poprawy. Dopiero po jej wprowadzeniu mogą służyć do oceny wpływu zgłoszenia na usługę¹³.

ServiceNow: model konfiguracji w kontekście obsługi zgłoszeń

ServiceNow CMDB może dostarczyć zespołowi obsługi kontekst sprawy przez połączenie jej z elementem konfiguracji. Produkt pozwala wiązać elementy konfiguracji z incydentami i problemami.⁸ Model danych powinien odzwierciedlać usługi klientów, wspierające je komponenty i odpowiedzialność za rekordy. Dokumentacja wskazuje trzy obowiązkowe pola elementu: nazwę, opis i status².

Czym jest baza konfiguracji w ServiceNow?

ServiceNow CMDB przechowuje elementy konfiguracji oraz relacje między nimi w środowisku ServiceNow. Produkt automatycznie wykrywa zasoby sieciowe i aktualizuje informacje o nich.⁸ Samo wykrycie nie pokazuje jeszcze agentowi, którą usługę wspiera zasób. Wykryty element trzeba przyporządkować do właściwej usługi, by przydał się podczas analizy zgłoszenia.

Jakie elementy modelu danych uwzględnić w ServiceNow?

Model danych ServiceNow CMDB powinien odróżniać usługi klienta od wspierających je komponentów. Musi też określać typy relacji i właścicieli rekordów. ServiceNow CMDB umożliwia monitorowanie kosztów zasobów oraz ograniczanie dostępu do danych według ról użytkowników.⁸ Kontrola dostępu oparta na rolach określa uprawnienia zgodnie z funkcją użytkownika; należy je dopasować do zadań agentów i osób utrzymujących bazę¹⁴.

Jak analizować przykłady wdrożeń w ServiceNow?

Przykład wdrożenia ServiceNow CMDB warto oceniać przez użyteczność modelu podczas obsługi zgłoszenia. Sama liczba zapisanych zasobów nie mówi, czy agent potrafi ustalić wpływ problemu na usługę. Przy ocenie pól punktem odniesienia mogą być trzy obowiązkowe atrybuty elementu: nazwa, opis i status².

• Zakres usług trzeba odczytać z opisu wdrożenia. Pozwala to porównać przedstawione usługi z tymi, które obsługuje własny zespół.
• Relacje elementów warto prześledzić od usługi klienta do komponentu technicznego. Taka droga pokazuje, czy model wyjaśnia wpływ problemu na usługę.
• Odpowiedzialność za dane należy powiązać z rolami opisanymi w przykładzie. Dzięki temu wiadomo, kto rozstrzyga rozbieżności w rekordach.

Przydatny przykład wdrożenia pokazuje użycie danych w konkretnej sprawie. Sama struktura bazy nie wystarczy.

Jakie pytania zadać przed wdrożeniem w ServiceNow?

Wdrożenie ServiceNow CMDB warto zacząć od pytań o zakres usług, źródła danych i właścicieli rekordów. Trzeba też ustalić, jak agenci będą korzystać z bazy. Które usługi klient wskazuje w zgłoszeniach i jakie zależności wyjaśniają ich niedostępność? Kto poprawi rekord po zmianie konfiguracji, a kto potrzebuje do niego dostępu podczas obsługi sprawy? Odpowiedzi wyznaczają zakres modelu i podział odpowiedzialności¹⁵.

LogicGate Risk Cloud w kontekście danych o konfiguracji

LogicGate Risk Cloud można wykorzystać do połączenia danych o konfiguracji z obiegiem zmian, zatwierdzeń i powiadomień. Produkt umożliwia automatyzację zatwierdzeń i powiadomień powiązanych z elementami konfiguracji.⁸ Pozwala także dostosować przepływy pracy, pola oraz raporty.⁸ Wniosek o zmianę może wskazywać usługę, aplikację i element techniczny, aby decyzja uwzględniała zależności między nimi.

Przepływ pracy określa, kto decyduje o zmianie i jakie dane otrzymuje przed jej zatwierdzeniem. Analiza wpływu ustala, których usług i klientów dotyczy planowana zmiana elementu konfiguracji. Zespół obsługi może na tej podstawie przygotować komunikat o zakresie prac.

• Wniosek o zmianę powinien wskazywać element konfiguracji i usługę, której dotyczy. Osoba zatwierdzająca zyskuje wtedy kontekst decyzji.
• Zatwierdzenie zmiany powinno uwzględniać właściciela elementu oraz usługę objętą pracami. Decyzja trafia dzięki temu do osoby odpowiedzialnej za jej skutki.
• Powiadomienie o zmianie powinno wynikać z ustalonego wpływu na usługę. Zespół obsługi może wtedy przekazać klientowi informację odnoszącą się do jego sytuacji.

LogicGate Risk Cloud służy w tym scenariuszu do organizacji decyzji i komunikacji. Punktem odniesienia pozostają zmiany elementów konfiguracji oraz usług z nimi powiązanych.

ManageEngine: baza konfiguracji i organizacja odpowiedzialnego zespołu

ManageEngine CMDB może wspierać obsługę klienta, jeśli dane o komponentach łączą się z usługami wskazywanymi w zgłoszeniach. Produkt automatycznie wykrywa dane konfiguracyjne i wprowadza je do bazy.⁸ Umożliwia także przedstawienie zależności między konfiguracjami a usługami, które obsługują.⁸ Przy projektowaniu własnych danych zespół może wykorzystać jako punkt odniesienia trzy obowiązkowe pola z modelu ServiceNow: nazwę, opis i status².

Mapowanie usług pokazuje, które elementy konfiguracji wspierają usługę klienta. Zespół obsługi korzysta z tej zależności przy analizie incydentu, a osoby planujące zmianę – przy ocenie wpływu prac. Automatyczne zasilanie bazy nie rozstrzyga jednak, kto odpowiada za poprawność przypisania komponentu do usługi¹⁶.

Jak zorganizować centrum kompetencyjne do utrzymania bazy konfiguracji?

Centrum kompetencyjne CMDB powinno rozdzielić odpowiedzialność za model danych, rekordy usług i rozbieżności wykrywane przy zgłoszeniach. Podział ułatwia kierowanie poprawek do właściwej osoby. W bazowym modelu atrybutów ServiceNow każdy element ma trzy obowiązkowe pola: nazwę, opis i status²; właściciel modelu może uwzględnić je przy określaniu wymaganych danych.

• Właściciel modelu danych ustala kategorie elementów, wymagane pola i znaczenie relacji. Dzięki temu zespoły opisują podobne komponenty w ten sam sposób.
• Właściciel usługi odpowiada za jej powiązanie z komponentami, które ją wspierają. Rozstrzyga, czy zależność widoczna dla agenta odpowiada rzeczywistemu sposobowi dostarczania usługi.
• Opiekun danych konfiguracyjnych wyjaśnia różnice między rekordem a stanem zasobu. Po zmianie konfiguracji poprawia też powiązania, których ta zmiana dotyczy.
• Zespół obsługi zgłoszeń przekazuje zauważone błędy osobom odpowiedzialnym za dane. Agent może zgłosić nieprawidłową zależność bez samodzielnej zmiany modelu.

Podział odpowiedzialności za CMDB pomaga poprawiać dane używane przez agentów. Od jakości tych danych zależy analiza zgłoszenia⁶.

Dostawcy MSP: zasoby i zależności w obsłudze wielu klientów

Dostawcy MSP, czyli firmy zarządzające usługami IT klientów, używają CMDB do rozdzielania środowisk i opisywania zależności. Wdrożenie CMDB dla MSP obejmuje kategoryzację elementów konfiguracji, integrację z obsługą incydentów oraz automatyzację zbierania danych.¹ Oddzielenie rekordów według klienta pomaga agentowi przypisać incydent do właściwego środowiska. CMDB może też przechowywać 4 rodzaje informacji: właścicieli zasobów, gwarancje, harmonogramy konserwacji i umowy serwisowe.¹

Jak baza konfiguracji może wspierać obsługę klientów MSP?

CMDB dostawcy MSP powinna łączyć obsługiwany element konfiguracji zarówno z klientem, jak i z usługą. Agent może wtedy ustalić zakres zgłoszenia bez mieszania środowisk¹. Kontekst rekordu mogą uzupełniać cztery rodzaje informacji: właściciel zasobu, gwarancja, harmonogram konserwacji i umowa serwisowa¹.

• Przypisanie do klienta wskazuje środowisko, do którego należy element konfiguracji. Chroni przed analizą zasobu w kontekście niewłaściwej firmy.
• Powiązanie z usługą pokazuje, jaką usługę wspiera element. Agent może dzięki temu odróżnić problem zasobu od problemu usługi lub ich zależności.
• Oznaczenie zasobu współdzielonego odróżnia komponent używany przez wielu klientów od zasobu jednej firmy. Podczas incydentu pomaga ustalić, czy trzeba przeanalizować także inne usługi.

Rekord powiązany z klientem i usługą daje agentowi punkt wyjścia do obsługi incydentu. Pozwala też zachować rozdział między środowiskami klientów.

Co daje powiązanie danych o konfiguracji ze zgłoszeniami MSP?

Powiązanie CMDB ze zgłoszeniem MSP wskazuje element, którego dotyczy sprawa, i usługi zależne od tego elementu. Agent zapisuje jego identyfikator w zgłoszeniu; osoba analizująca incydent korzysta z tych samych relacji. Przy zasobie współdzielonym zespół może ocenić wpływ problemu na pozostałych klientów korzystających z powiązanych usług. W dokumentacji ServiceNow pole elementu konfiguracji występuje przy trzech typach spraw: incydencie, problemie i zamówionej pozycji usługi⁷.

SCP Health: jak analizować przykład wykorzystania bazy konfiguracji?

Przykład SCP Health warto analizować przez sposób połączenia rekordu zasobu ze zgłoszeniem i usługą. Sama nazwa organizacji nie dowodzi skuteczności wdrożenia. Punktem odniesienia dla struktury rekordu mogą być trzy obowiązkowe pola z bazowego modelu ServiceNow: nazwa, opis i status².

• Zakres modelu SCP Health należy ustalić na podstawie usług i zasobów opisanych w przykładzie. To pozwala ocenić, do jakich spraw można odnieść przedstawiony model¹⁷.
• Sposób powiązania zgłoszenia warto prześledzić od sprawy klienta do elementu konfiguracji. Widać wtedy, czy agent może wskazać zasób związany z problemem.
• Opis zależności trzeba odczytać od elementu do obsługiwanej usługi. Pokazuje to, czy przykład dotyczy wpływu awarii, czy tylko ewidencji zasobów.

Przykład SCP Health przydaje się przy projektowaniu CMDB dla MSP, jeśli pokazuje drogę od zgłoszenia do zasobu. Ta droga powinna prowadzić dalej do usługi klienta.

Zewnętrzni programiści do rozbudowy bazy konfiguracji

Zewnętrzni programiści mogą rozbudować CMDB, gdy zespół potrzebuje własnej integracji ze źródłem danych lub systemem obsługi zgłoszeń. Zakres prac powinien określać tworzone rekordy i relacje, źródło ich aktualizacji oraz sposób wykorzystania danych przez agenta¹⁸. Przy porównywaniu zakresów usług można uwzględnić deklarację Royal Cyber. Firma zapowiada przygotowanie wyceny niestandardowych rozwiązań i rekomendacji dotyczących CMDB w ciągu 24 godzin¹⁸.

Integracja danych potrzebuje reguł rozpoznawania istniejących elementów konfiguracji. Bez nich import może tworzyć duplikaty. Specyfikacja powinna też opisywać postępowanie ze sprzecznymi informacjami o tym samym zasobie. Przed uruchomieniem integracji właściciel danych powinien zaakceptować zasady aktualizacji rekordów i relacji.

Odbiór rozbudowy CMDB warto oprzeć na scenariuszach z obsługi klienta. Obejmują one przypisanie zgłoszenia do zasobu, odczytanie zależnej usługi i poprawienie błędnej relacji. Umowa z wykonawcą powinna wskazywać osobę odpowiedzialną za utrzymanie integracji po wdrożeniu. Powinna też określać, kto może zmieniać model danych.

Efektem pracy programistów powinna być baza przydatna w obsłudze zgłoszeń. Jej powiązania trzeba móc zarówno odczytać, jak i poprawić.

Royal Cyber: zakres usług związanych z ServiceNow

Royal Cyber oferuje usługi zasilania ServiceNow CMDB danymi o infrastrukturze chmurowej, Kubernetes i technologiach serverless.¹⁸ Firma deklaruje możliwość obniżenia kosztów rozwoju, utrzymania i wsparcia związanych z CMDB o maksymalnie 40%.¹⁸ Zapowiada też przygotowanie wyceny niestandardowych rozwiązań i rekomendacji dotyczących CMDB w ciągu 24 godzin.¹⁸

Deklaracja 40% dotyczy maksymalnej możliwej obniżki wskazanych kosztów. Nie oznacza wyniku gwarantowanego dla każdego wdrożenia. Termin 24 godzin odnosi się do przygotowania wyceny i rekomendacji, a nie do wykonania prac nad CMDB. Dla zespołu obsługi znaczenie ma zakres danych trafiających do elementów konfiguracji oraz ich powiązanie z usługami klientów.

Usługi Royal Cyber warto oceniać przez zakres zasilania CMDB. Uzyskane dane powinny pomagać zespołowi podczas obsługi zgłoszeń.

CMDB w Jira Service Management Assets: projektowanie modelu zasobów

Jira Service Management Assets pozwala zbudować CMDB jako model obiektów reprezentujących zasoby i usługi. Obiekty w Assets można łączyć z incydentami, wnioskami o usługę, problemami i zmianami.¹⁹ Zgłoszenie wskazuje wtedy konkretny obiekt, a nie tylko nazwę zasobu wpisaną w opisie.

Model danych powinien określać typy obiektów, ich atrybuty oraz znaczenie relacji. Usługa, aplikacja i urządzenie potrzebują odrębnych typów, jeśli pełnią różne role w zgłoszeniu. Identyfikator pozwala odróżnić zasoby o podobnych nazwach. Przy wyborze pól punktem odniesienia mogą być trzy obowiązkowe atrybuty elementu w bazowym modelu ServiceNow: nazwa, opis i status².

Dlaczego budować bazę konfiguracji w Assets?

Baza konfiguracji w Assets ma sens, gdy zespół chce odnosić sprawy klientów do obiektów opisujących obsługiwane środowisko. Powiązanie z obiektem zachowuje kontekst zasobu podczas przekazywania zgłoszenia między agentami. Relacje pomagają też ustalić, której usługi dotyczy problem z komponentem. Assets może łączyć obiekty z czterema wymienionymi rodzajami spraw: incydentami, wnioskami o usługę, problemami i zmianami¹⁹.

Aktualność modelu Assets zależy od sposobu zasilania danych i zasad poprawiania rekordów. Trinidad Wiseman wskazuje importy, integracje oraz powtarzalne procesy aktualizacji jako sposoby utrzymywania aktualności CMDB w Assets.¹⁹ Właściciel danych powinien rozstrzygać rozbieżności między zaimportowanym rekordem a rzeczywistą zależnością usługi. Assets wspiera obsługę zgłoszeń, gdy obiekty i ich relacje pozostają użyteczne dla agentów.

Ceny i warunki sprawdzone u źródeł: październik 2026.