Jak zacząć korzystać z Assets for Jira Service Management Data Center

Obiekty

Obiekty są rzeczywistymi zasobami / elementami konfiguracji. Można je połączyć ze zgłoszeniami w Jira, zatem za każdym razem, gdy pojawia się zgłoszenie, od razu zyskuje ono szerszy kontekst.

Można je również połączyć ze sobą przy użyciu odniesień do obiektów, odzwierciedlając w ten sposób zależności między obiektami.

Schematy obiektów

Schemat obiektów to rzeczywista baza danych zarządzania konfiguracjami (CMDB), która zawiera Twoje typy obiektów (więcej na ten temat w dalszej części) oraz obiekty. W Assets można utworzyć szereg schematów obiektów, co przydaje się z wielu powodów:

• Podział danych na mniejsze części ułatwia ich audyt i zapewnianie dokładności.
• Jeśli posiadasz dane wrażliwe, np. informacje o pracownikach, prościej będzie przechowywać wszystkie te dane razem w obrębie jednego schematu obiektów o ograniczonych uprawnieniach dostępu.

Wybierając sposób wprowadzania danych do Zasobów, należy wziąć pod uwagę sposób używania danych i osoby, które będą aktualizować dane, aby pogrupować je w logicznych schematach obiektów.

Assets (a w drodze rozszerzenia także Jira Service Management) nie zważa na to, do którego schematu obiektów zaliczone są poszczególne informacje. Widzi tylko jedną wielką pulę danych. Dzięki temu można w prosty sposób użyć wielu schematów obiektów w jednym przypadku użycia i tworzyć łącza między obiektami w różnych schematach obiektów.

Typy obiektów

Typy obiektów są częściami składowymi schematu i określają rodzaj obiektów, jakie zawiera dany schemat. Można je zdefiniować samodzielnie lub skorzystać z szablonu schematu obiektów zawierającego wstępnie wypełnione typy obiektów, które można dostosowywać. Typy obiektów pełnią funkcję kontenerów na rzeczywiste obiekty. Typy obiektów mogą być dowolne, ponieważ Assets jest narzędziem bardzo otwartym i elastycznym, jednak najczęściej spotykane typy obiektów to:

• Usługi biznesowe
• Hosty
• Laptopy
• Oprogramowanie

Nie muszą to być jednak zasoby IT. Wiele osób dodaje na przykład inne przydatne informacje, takie jak:

• Dostawcy
• Lokalizacje
• employees
• Priorytet biznesowy

Atrybuty typu obiektu

Atrybuty obiektów są typ, co definiuje konkretny typ obiektu. Każdy typ obiektu posiada własny zestaw atrybutów. Na przykład typ obiektu „laptopy” może posiadać takie atrybuty, jak model, numer seryjny, użytkownik, data wygaśnięcia gwarancji itp.

Wprowadzenie rzeczywistych wartości dla atrybutu pozwoli zdefiniować obiekt. Można to robić ręcznie lub automatycznie (patrz krok 4).

Odniesienia do obiektów

Konkretnie atrybutem obiektu do wywołania jest typ atrybutu „obiekt”. W ten sposób powstaje odniesienie do innych obiektów, co stanowi pierwszy etap tworzenia mapy zależności między obiektami.

Jeśli na przykład lokalizacja jest sama w sobie typem obiektu, wówczas każdy obiekt lokalizacji może odpowiadać lokalizacji jednego z biur firmy. Dzięki temu można szybko ustawić lokalizację każdego laptopa, na przykład wybierając opcję „Sztokholm”.

Uprawnienia w narzędziu Zasoby

W narzędziu Assets są dostępne trzy rodzaje uprawnień:

• Uprawnienia globalne — w ustawieniach globalnych można wskazać osoby z uprawnieniami administracyjnymi w Assets. Osoby przypisane do roli „Administrator Assets” mogą wykonywać wszystkie czynności w aplikacji Assets.
• Uprawnienia do schematu obiektów — w ustawieniach schematu obiektów można zdefiniować osoby posiadające uprawnienia administracyjne do konkretnego schematu obiektów, uprawnienia do aktualizacji danych schemat obiektów oraz uprawnienia wyłącznie do przeglądania danych.
• Uprawnienia do typu obiektu — czasami chcemy, aby klienci systemu Jira Service Management mogli wyświetlać tylko określone informacje należące do schematu obiektów, ale nie mieli dostępu do wyświetlania wszystkich danych w całym schemacie obiektów. W takim przypadku można użyć uprawnień do typu obiektu.

Zdefiniuj problem

Większość narzędzi wdraża się w celu rozwiązania problemu, a Zasoby nie stanowią pod tym względem wyjątku. Być może incydenty nie są rozwiązywane wystarczająco szybko bądź zmiany w konkretnej usłudze często prowadzą do nieoczekiwanych rezultatów, ponieważ trudno dostrzec zależności między usługami.

Określ problem i na tej podstawie zdefiniuj wszystkie inne kwestie, od osób zaangażowanych po zasoby i informacje do uwzględnienia w bazie danych. Przyjrzyj się problemowi i postaraj się zrozumieć, jakich dodatkowych informacji będą potrzebowali pracownicy, aby go rozwiązać. Informacje te wyznaczą typy obiektów.

Dodanie zbyt dużej ilości informacji za jednym razem może utrudniać sprawdzanie dokładności. Spróbuj skoncentrować się tylko na jednym problemie naraz. Po rozwiązaniu pierwszego problemu można rozwijać narzędzie Assets, aby rozwiązać również inne problemy.

Zacznij od usług

W zastosowaniach związanych z zarządzaniem konfiguracjami zalecamy rozpoczęcie od usług powiązanych z problemem, który próbujesz rozwiązać. Usługi są dobrze zdefiniowane i stosunkowo łatwo przystąpić do dodawania różnych zasobów, od których zależy ich uruchomienie, a następnie kolejnych zasobów, od których zależne są te zasoby, i tak dalej. W końcu powstaje kompletny obraz każdej istotnej usługi wraz z jej zależnościami.

Musisz określić, jak głęboko chcesz sięgnąć. Pomyśl realistycznie, ilu szczegółów potrzebujesz, aby zrozumieć swoje usługi. Dla niektórych mapowanie konkretnych stojaków i przewodów będzie zbyt szczegółowe, a w przypadku innych może być konieczne.

Nie musisz uwzględniać wszystkich swoich usług naraz. Możesz rozpocząć od usług o znaczeniu krytycznym dla firmy lub tych, w przypadku których odnotowano przestoje.

Rozpoczęcie od usług pozwala uzyskać określony zestaw zasobów / elementów konfiguracji na początek. Następnie, w miarę pojawiania się nowych problemów, można dodawać inne zasoby. Najlepiej tworzyć swoją bazę CMDB kawałek po kawałku, ponieważ łatwiej sprawdzić dokładność niewielkich fragmentów danych niż całej infrastruktury i wszystkich zasobów za jednym razem.

Korzystaj z szablonów schematów obiektów

W Assets można znaleźć gotowe szablony schematów obiektów do zarządzania zasobami IT i konfiguracjami, zasobami ludzkimi oraz relacjami z klientem.

Szablony te można modyfikować, dostosowując je do własnych potrzeb, stanowią one też doskonały punkt wyjścia do wdrożenia typów obiektów, jakie użytkownicy często przechowują w Assets. Przejrzyj listę typów obiektów i usuń te, z których nie będziesz korzystać.

Zastanów się, bez czego możesz się obejść

Przemyśl dokładnie, co próbujesz osiągnąć i jakie informacje będą do tego potrzebne. Każdy obiekt oraz jego atrybuty powinny być przydatne.

Porozmawiaj z zespołem i osobami zainteresowanymi, aby upewnić się, że każdy atrybut jest wykorzystywany przez kogoś lub do czegoś. Jeśli nikt nie ma zastosowania dla jakiegoś atrybutu, odrzuć go. Zawsze można go dodać później!

Czy naprawdę musisz znać dokładną lokalizację swoich serwerów? Albo producenta systemów operacyjnych? Być może tak i to jak najbardziej ma sens. Jeśli jednak nie zamierzasz podejmować decyzji ani tworzyć zapytań w oparciu o te dane, po prostu odłóż je na bok.

Dodanie zbyt dużej ilości danych stwarza wyzwania:

• Im więcej obiektów i atrybutów, tym więcej pracy potrzeba, aby zapewnić ich dokładność.
• Duża ilość nieużywanych danych będzie przesłaniać cenne dane, a w skrajnych przypadkach może nawet obniżać wydajność.
• Łatwiej dodać dane później niż je usuwać. Lepiej dodać później brakujące dane niż zacząć od ogromnej ilości danych „na wszelki wypadek”. Nikt nie lubi usuwać danych.

Weź pod uwagę łatwość utrzymania w przyszłości

Przemyśl sposób utrzymywania danych wprowadzonych do Assets. Jak często będą się zmieniać atrybuty obiektu i na ile łatwo będzie zapewnić ich aktualność w Assets?

Jeśli konkretny wycinek danych dotyczących obiektu często ulega zmianie, ale rzadko się go wykorzystuje, prawdopodobnie lepiej będzie nie wprowadzać go do Assets, tylko po prostu wyszukać przy tych rzadkich okazjach, gdy faktycznie jest potrzebny. Jeśli czegoś używa się od czasu do czasu, ale jest to wysoce niezmienne, wprowadzenie tego w celu ułatwienia dostępu może być dobrym pomysłem.

Posłużmy się przykładem oprogramowania na laptopie. Jeśli zechcesz, możesz aktualizować Assets o każdy element oprogramowania zainstalowany na laptopie, wykorzystując w tym celu agenta skanowania, zgłoszenia dotyczące wniosków o oprogramowanie i reguły automatyzacji. Jeśli w Twojej firmie obowiązują otwarte zasady dotyczące instalacji, oprogramowanie będzie się zmieniało stosunkowo szybko i wzorce skanowania mogą nie wychwycić nowego oprogramowania, co może prowadzić do nieznacznego obniżenia dokładności. W takiej sytuacji lepiej przyjrzeć się kluczowemu zestawowi oprogramowania, którego wzorce użytkowania chcesz poznać w szczególności.

Jeśli w Twojej firmie obowiązują rygorystyczne zasady dotyczące instalacji, a oprogramowanie instalowane jest tylko przy konfiguracji laptopa i za pośrednictwem wniosków do działu obsługi, wówczas warto zapisać je w całości w Assets, ponieważ tempo zmian jest wolniejsze i łatwiej jest je śledzić.

Wyjdź poza elementy fizyczne

Narzędzie Assets umożliwia definiowanie potrzebnych obiektów, co oznacza, że nie musisz się ograniczać do zasobów tradycyjnych ani nawet fizycznych. Na przykład usługi biznesowe nie są zasobami fizycznymi, ale często ich szczegółowe zrozumienie ma dla ludzi krytyczne znaczenie. Z usługą można powiązać wszystkie jej zależności fizyczne i niefizyczne, dzięki czemu spojrzenie na obiekt usługi biznesowej pozwala w pełni zrozumieć sposób jej funkcjonowania.

Możesz przejść na dowolny poziom abstrakcji. Do przykładów obiektów ważnych dla firm, jakie tworzą użytkownicy Assets, należą typy środowisk, działy/zespoły, lokalizacje itp.

Innym zaczerpniętym z praktyki przykładem jest kategoryzowanie usług biznesowych. Załóżmy, że wszystkie Twoje usługi biznesowe są dodane do narzędzia Assets jako typ obiektu „Usługi biznesowe”. Możesz podzielić te usługi na kategorie, takie jak „Finanse”, „Logistyka”, „Sprzedaż”, „Infrastruktura” itp. W tym celu możesz użyć atrybutu w typie obiektu Usługa biznesowa lub stworzyć dla tych kategorii ich własny typ obiektu o nazwie „Kategoria usług”.

Spoglądaj w przyszłość i postaw na stopniowy rozwój

Miej na uwadze wszelkie rozszerzenia, które mogą się przydać w przyszłości. Od nich zależeć będzie nie tylko rodzaj uwzględnianych danych, ale także ich struktura.

Choć warto o tym pamiętać, zalecamy tworzenie bazy Assets stopniowo. Bardzo trudno utworzyć jedno ogromne wydanie zawierające w 100% dokładne dane dla tysięcy obiektów. Znacznie prościej będzie zacząć od drobnych elementów i dodawać nowe atrybuty, obiekty i schematy obiektów na bieżąco.

Zalecamy zidentyfikowanie problemu, utworzenie bazy Zasobów w celu jego usunięcia, a następnie przejście do kolejnego problemu poprzez rozwój tej bazy.

Wyznacz realistyczne oczekiwania względem dokładności

Docelowo dokładność powinna być 100% przez cały czas, jednak w rzeczywistości może się to okazać niemożliwe. Nie ma w tym nic złego. Dopóki dane są na tyle dokładne, że pod względem biznesowym przynoszą większą wartość niż ich brak, wciąż wychodzisz na swoje. Wiele projektów CMDB doświadcza opóźnień, a nawet nigdy nie zostaje ukończonych w oczekiwaniu na osiągnięcie „ideału” jeszcze przed wdrożeniem.

Skaner sieciowy Assets Discovery

Assets Discovery to darmowe narzędzie dostępne w sklepie Marketplace.

Aplikacja Assets Discovery to bezagentowy skaner (choć dostępny jest agent pozwalający uzyskać bardziej szczegółowe informacje), który wychwytuje zasoby sieciowe. Pozwala ona wybrać zasoby i atrybuty, które mają zostać ściągnięte do schematów obiektów Zasobów, a także tworzyć własne wzorce skanowania w celu wykrycia bardziej niszowych zasobów. Regularne uruchamianie tego narzędzia umożliwia wychwytywanie zmian i zapewnienie aktualności danych. Za pomocą reguł automatyzacji można nawet wyzwalać zgłoszenia Jira, powiadomienia e-mail oraz inne operacje w oparciu o wykrywane zmiany.

Narzędzia importu

Za pomocą narzędzi importu Assets można pobierać dane z innych źródeł. Te reguły importu można regularnie synchronizować, aby w razie potrzeby móc aktualizować dane. Dla każdego typu importu należy zdefiniować miejsce zapisu danych oraz ich lokalizację docelową w Assets.

Import plików CSV

Jeśli korzystasz z programu opartego na arkuszach kalkulacyjnych, takiego jak Excel lub Arkusze Google, do przechowywania swoich zasobów, możesz wprowadzić te dane do Zasobów za pomocą funkcji importu plików CSV. Dzięki temu uzyskasz zintegrowany i przejrzysty system z możliwością łączenia zasobów ze zgłoszeniami i analizowania wpływu.

Importowanie bazy danych

Korzystając z funkcji importu bazy danych, można zaimportować dane z systemu wewnętrznego lub zewnętrznego. Obsługiwane są bazy danych Oracle, MySQL, Microsoft SQL Server i PostgreSQL.

Importowanie użytkowników Jira

Często użytkownicy Assets łączą użytkowników Jira z posiadanymi przez nich zasobami. W tym celu konieczne jest zaimportowanie poszczególnych użytkowników lub konkretnych grup użytkowników Jira do Assets, co można zrobić za pomocą funkcji importowania użytkowników Jira.

Importowanie katalogów LDAP

Korzystasz z katalogu korporacyjnego zawierającego dane na temat zasobów lub relacji pracowników z kierownictwem używanych w procesach zatwierdzania? Aby to ułatwić, w Assets przewidziano moduły współpracujące z popularnymi katalogami LDAP, które umożliwiają pobranie struktury i zasobów z Twojego katalogu.

Import pliku JSON

Obiekty można importować do Zasobów z plików JSON zawierających dane do zaimportowania.

Narzędzia Integracji

Za pomocą integracji można tworzyć połączenia z innymi narzędziami, takimi jak usługi w chmurze, menedżery zasobów oraz inne bazy CMDB.

Choć wszyscy dysponujemy takimi narzędziami, nie zaleca się przenoszenia każdego fragmentu danych do Assets, chyba że planowane jest wycofanie narzędzia. Lepiej wprowadzić te dane, które będą potrzebne w Jira Service Management — później zawsze można wprowadzić więcej informacji.

Wszystkie integracje można zainstalować za darmo ze sklepu Marketplace.

Poniżej znajduje się pełna lista integracji Assets:

• Integracja Assets z AWS
• Integracja Assets z Azure
• Integracja Assets z Google Cloud
• Integracja Assets z SCCM
• Integracja Assets ze Snow
• Integracja Assets z ServiceNow
• Integracja Assets z JAMF
• Integracja Assets z Device42
• Integracja Assets z krajową bazą danych luk w zabezpieczeniach
• Integracja Assets z Jira i Bitbucket
• Integracja Assets z Tempo

Porady i wskazówki

Trzeba wypracować optymalną częstotliwość uruchamiania narzędzia Assets Discovery, narzędzi importu i integracji. Jeśli będzie się to robić zbyt rzadko, dane w Assets nie będą aktualne. Zbyt częste ich uruchamianie może powodować wysokie zużycie zasobów — w zależności od liczby przetwarzanych obiektów. Niektórzy użytkownicy uruchamiają integracje co godzinę, inni raz w tygodniu, a jeszcze inni na żądanie.

Zalecamy możliwie częstą synchronizację w okresach spokojnych. Zastanów się, jak często dane mogą ulegać zmianie, i na podstawie stopnia istotności tych danych określ, jak często należy zaplanować uruchamianie tych operacji. Twoim celem jest dotrzymanie kroku zmianom danych.

Aplikacja Assets Discovery umożliwia uruchamianie różnych wzorców skanowania w różnych odstępach czasu, aby w miarę możliwości ograniczyć liczbę zasobów potrzebnych do zapewnienia aktualizacji danych Assets.

Podziel dane na logiczne schematy obiektów

Nie wszystkie Twoje dane muszą trafić do jednego ogromnego schematu obiektów. Zalecamy utworzenie wielu schematów obiektów, w zależności od sposobu używania danych lub ich właściciela.

Aplikacje Assets i Jira nie biorą pod uwagę przynależności danych do konkretnych schematów obiektów. Administrator po prostu wskazuje pole niestandardowe Assets przy potrzebnych danych, niezależnie od schematu, do którego należą. Z kolei pola niestandardowe mogą przesyłać dane do wielu schematów obiektów i je z nich pobierać z poziomu jednego zgłoszenia Jira. Obiekty należące do jednego schematu obiektów można łączyć z obiektami w innych schematach. Można też uruchamiać zapytania obejmujące różne schematy. Schematy obiektów mają na celu przede wszystkim ułatwienie nam życia. Nie są szczególnie istotne dla samej aplikacji Assets.

Zastosowanie podziału danych na różne schematy obiektów ułatwia nie tylko pracę, ale także utrzymanie bazy. Konkretne zespoły, na przykład z działu finansów lub HR, mogą potrzebować pewnych informacji z Zasobów, ale niekoniecznie chcą być bombardowane danymi, które nie są dla nich istotne. Łatwiej również poprosić jeden zespół o regularne sprawdzanie jakości danych w jednym schemacie obiektów niż o sprawdzanie tylko pewnego wycinka jednego ogromnego schematu obiektów.

Łącz swoje dane

Jeśli masz już w innym miejscu dobrze funkcjonującą bazę danych lub źródło informacji, a także procesy pozwalające zapewnić aktualność zawartych w nich danych, nie musisz przenosić tych danych do Zasobów. Prawdopodobnie lepiej będzie utworzyć kopię odpowiednich danych przy użyciu integracji i uruchamiać te integracje według harmonogramu w celu aktualizowania informacji w Zasobach.

Assets ma szereg narzędzi importu oraz integracji (patrz wyżej). Umożliwiają one udostępnienie informacji potrzebnych do podejmowania decyzji w zgłoszeniu Jira lub samej aplikacji Assets bez konieczności utrzymywania dwóch odrębnych kopii.

Często obserwujemy korzystanie w tym celu z narzędzia importu LDAP do synchronizacji Assets z Active Directory. Pozwala to zyskać łatwy dostęp do wszystkich użytkowników Windows, a uruchamiając tę funkcję okresowo, można łatwo zaktualizować dane.

Czasami ludzie tworzą odrębne schematy obiektów dla tych zaimportowanych danych, a innym razem integrują je do postaci większych schematów obiektów. Jeśli dane będą wykorzystywane w różnych celach (np. na potrzeby wsparcia IT lub HR), wówczas sensowniejszym rozwiązaniem będzie stworzenie z nich odrębnego schematu obiektów, zamiast włączania ich w schemat obiektów IT, do którego dostęp zapewni się również pracownikom HR.

Osobom korzystającym z integracji zalecamy niewprowadzanie każdego elementu dostępnych danych do Assets. Podczas konfiguracji integracji można określić, jakie dane będą trafiały do schematu obiektów, a jakie nie. Takich danych nie należy również aktualizować w samej aplikacji Assets, chyba że później wysyła się wprowadzone zmiany do pierwotnego źródła danych. W przeciwnym razie pojawią się konflikty danych.

Jeśli nie ma żadnej gotowej integracji, dostępne są również inne opcje. Pierwszą z nich jest okresowe eksportowanie danych do pliku CSV/JSON i regularne ich importowanie za pomocą narzędzi importu plików CSV/JSON do Assets. Można również utworzyć obiekt i przypisać mu atrybut adresu URL do innej bazy danych, w której można znaleźć więcej informacji. Ta opcja sprawdza się w sytuacji, kiedy chcemy zapewnić agentom możliwość przeglądania informacji bez możliwości wyszukiwania lub tworzenia raportów na ich podstawie.

Nie używaj wszędzie tych samych atrybutów

Jeśli atrybut jest używany w wielu miejscach i posiada te same, powtarzające się wartości, wówczas często lepiej jest zrobić z niego odrębny typ obiektu. Dostawca jest dobrym tego przykładem. Atrybut o nazwie „Dostawca” można zastosować do typów obiektów laptop i telefon, a następnie wpisać (lub zaimportować) nazwę dostawcy dla każdego obiektu.

Można tak zrobić, ale znacznie lepszym rozwiązaniem będzie ustawienie typu obiektów o nazwie „Dostawcy”, a następnie ustawienie każdego dostawcy jako obiektu. Taka konfiguracja jest korzystna z wielu powodów:

1. Być może sama nazwa dostawcy nie wystarczy. Możesz potrzebować innych informacji związanych z dostawcą, takich jak numer kontaktowy działu wsparcia lub łącza do umów. Nie chcesz wprowadzać tych danych dla każdego laptopa i telefonu z osobna. Możesz ustawić je raz i połączyć z obiektem dostawcy. W ten sposób można również wprowadzić elementy zarządzania dostawcami w Jira Service Management.
2. Takie rozwiązanie pozwoli znormalizować dostawców, co ułatwi tworzenie raportów. Jeśli zechcesz utworzyć raport na temat liczby wniosków o wsparcie zgłoszonych przez poszczególnych dostawców, masz pewność, że nie przegapisz niczego tylko dlatego, że ktoś gdzieś popełnił literówkę, pisząc Micrsoft lub Aple.
3. Jeśli dostawca zmieni markę lub będzie wymagał innego rodzaju modyfikacji, wówczas wystarczy zaktualizować dane w jednym miejscu.

Dostawca to zaledwie jeden przykład. To samo dotyczy poziomów istotności dla firmy, środowisk wdrożenia, działów i lokalizacji.

Automatyzacja narzędzia Assets

Automatyzacje Assets są właściwe dla poszczególnych schematów obiektów. Do ich częstych zastosowań należą:

• Wysyłanie powiadomień w oparciu o konkretne wyzwalacze lub zmiany w obiektach Assets należących do schematu — np. wysyłanie wiadomości e-mail, gdy zbliża się data wygaśnięcia licencji lub gwarancji, bądź tworzenie zgłoszenia w Jira, gdy usługa przestaje działać.
• Porządkowanie i normalizacja danych w Assets w celu ułatwienia tworzenia raportów i zapytań.

Reguły automatyzacji umożliwiają aktualizowanie informacji o obiektach, tworzenie zgłoszeń, wysyłanie wiadomości e-mail, tworzenie wniosków HTTP, wykonywanie skryptów Groovy i wiele innych.

Tutaj znajdziesz informacje na temat tworzenia reguł automatyzacji:

Funkcje następujące

W Assets wprowadzono również nowe funkcje następcze. Funkcje te, podobnie jak reguły automatyzacji, umożliwiają automatyzowanie wykonywania czynności.

Różnica polega na tym, że czynności są wykonywane, gdy status zgłoszenia w przepływie pracy Jira ulega zmianie (podczas przejścia zgłoszenia). Czynności te obejmują aktualizację zasobu, wysłanie powiadomienia i uruchomienie skryptu.

Można na przykład opracować zadania, które po utworzeniu zgłoszenia z wnioskiem o wdrożenie pracownika spowodują przypisanie do nowego użytkownika niezbędnych zasobów, takich jak laptop, telefon komórkowy i abonament telefoniczny, z których każdy będzie połączony z obiektami Assets.

Porady i wskazówki

Jeśli wprowadzasz lub aktualizujesz dane w Assets przy użyciu pól tekstowych zgłoszeń bądź od czasu do czasu wprowadzasz obiekty do Assets ręcznie, do danych może wkraść się bałagan. W takich przypadkach warto skorzystać z automatyzacji.

Dobrym tego przykładem są nazwy serwerów. Zazwyczaj są ono znormalizowane i łatwo się pomylić przy ich wpisywaniu. Można utworzyć reguły automatyzacji wyzwalane po utworzeniu lub zaktualizowaniu obiektu z uwzględnieniem serwera, aby się upewnić, czy nazwa zgadza się z konwencją nazewnictwa, a w razie potrzeby dodać oznaczenie sygnalizujące błąd.

Etykiety i kody QR

Korzystanie z etykiet i kodów QR może w dużym stopniu usprawnić zarządzanie środkami trwałymi. Dlatego Assets pozwala na drukowanie etykiet i kodów QR, które można umieszczać na dowolnych obiektach.