Close

Onboardingshandleiding voor Assets

Overzicht

Deze handleiding is voor iedereen aan de slag gaat met Assets in Jira Service Management Cloud Premium of Enterprise. Met Assets kunnen teams hun assets, configuratie-items en resources volgen om inzicht te krijgen in de cruciale relaties tussen applicaties, services, onderliggende infrastructuur en overige belangrijke assets. Assets is gebaseerd op Jira en geeft teams een eenvoudige en snelle manier om assets en configuratie-items te koppelen aan serviceaanvragen, incidenten, problemen, wijzigingen en andere problemen om waardevolle context te verzamelen.


Assets stond voorheen bekend als Insight. We zijn onze contentbibliotheek aan het bijwerken, daarom kan het zijn dat je de term Insight nog tegenkomt. Bij deze overgang zijn er geen technische aspecten en functies veranderd.

Stap 1 - Assets openen

Of je nu een licentie hebt of een proefversie van Jira Service Management Premium of Enterprise gebruikt, je kunt Assets openen door het te selecteren in het bovenste menu.

Open Assets in het bovenste menu in Jira Service Management Premium of Enterprise

Stap 2 - Begrijpen hoe Assets gestructureerd is

Dit gedeelte geeft een overzicht van hoe de Assets-database is gestructureerd.

Diagram met in het midden object, objecttype een niveau hoger en objectschema op het hoogste niveau

Objecten

Een object is alles wat enkelvoudig en uniek is: een laptop, een server, een apparaat, een contract of zelfs een voertuig. Objecten zijn je werkelijke elementen/configuratie-items (CI's).

Objecten kunnen aan je Jira-issues worden gekoppeld, dus als er een issue binnenkomt, heeft de issue onmiddellijk meer context. Objecten kunnen ook aan elkaar gekoppeld worden via objectverwijzingen om te laten zien hoe objecten van elkaar afhankelijk zijn.

Objecttypes

Vergelijkbare objecten worden gegroepeerd in objecttypen. Objecttypen fungeren als containers voor je werkelijke objecten. Objecttypen vallen binnen een schema en definiëren de objecten in het schema. Je kunt ze zelf definiëren of je kunt een objectschemasjabloon gebruiken die vooraf is ingevuld met bepaalde objecttypen die je kunt aanpassen. Veelvoorkomende objecttypen zijn onder andere:

  • Bedrijfsservices
  • Servers
  • Laptops
  • Software

Maar dit hoeven geen IT-assets te zijn. Veel mensen voegen bijvoorbeeld andere handige informatie toe, zoals:

  • Leveranciers
  • Locaties
  • medewerkers
  • Bedrijfsprioriteit

Je kunt objecttypen op een logische manier in de hiërarchiestructuur ordenen. Deze structuur is voornamelijk bedoeld voor navigatie en leesbaarheid en je kunt lege objecttypen hebben om dit te ondersteunen, maar het kan worden geconfigureerd om attributen over te nemen om het maken van objecttypen te vereenvoudigen.

Objecttypen organiseren in een hiërarchiestructuur

Objectschema's

Een objectschema is de werkelijke database voor configuratiebeheer (CMDB) met je objecttypen en objecten. Je kunt meerdere objectschema's aanmaken in Assets, wat om een aantal redenen handig is:

  • Gegevens in kleinere stukjes opdelen helpt bij het controleren en nauwkeurig houden van de gegevens.
  • Als je gevoelige gegevens hebt, zoals werknemersgegevens, kan het handiger zijn om al die gegevens samen op te slaan in één objectschema met beperkte toegangsrechten.

Wanneer je bepaalt hoe gegevens in Assets worden geplaatst, moet je rekening houden met het gebruik van de gegevens en wie deze gaat bijwerken, zodat ze in logische objectschema's kunnen worden opgedeeld. Je kunt eenvoudig meerdere objectschema's voor één use case gebruiken en objecten in verschillende objectschema's koppelen.

Er zijn ook sjablonen beschikbaar voor belangrijke toepassingen zoals IT-assetbeheer, personeelsbeheer en gebouwbeheer. Deze sjablonen bevatten verschillende relevante objecttypen, afhankelijk van je behoeften. Ze geven je een voorsprong bij het bouwen van een effectieve database en bieden een eerste structuur voor het importeren van objecten. Meer informatie over integraties vind je hier.

Assets wordt automatisch gesynchroniseerd met de functie Services binnen Jira Service Management. Assets maakt een alleen-lezen objectschema aan binnen de Assets-database met objecten die zijn ingevoerd voor elke gedocumenteerde service in je serviceregister. Dit betekent dat je je Jira Service Management-services kunt koppelen aan verschillende assets en CI's om een servicekaart te maken voor wijzigingen, incidenten en problemen.

Objectattributen

Een attribuut stelt een specifiek stuk informatie voor dat aan een object is gekoppeld, bijvoorbeeld een beschrijving van het object, het modelnummer, andere bijbehorende objecten of een gebruiker die als objecteigenaar is toegewezen.

Elk objecttype heeft zijn eigen attributen. Het objecttype 'laptops' kan bijvoorbeeld de volgende attributen hebben: model, serienummer, gebruiker, vervaldatum van garantie, etc.

Als je werkelijke waarden voor het attribuut invoert, wordt een object gedefinieerd. Dit kan handmatig of automatisch worden gedaan (zie stap 4).

Alle objecttypen hebben vier verplichte attributen:

  1. Naam
  2. Code
  3. Aanmaakdatum
  4. Laatst bijgewerkte gegevens

De laatste drie worden automatisch ingesteld. Elk ander attribuut kan door de beheerder worden gedefinieerd. En omdat er een uniek hoofdattribuut is, hoeven de namen van objecten niet uniek te zijn.

Kenmerken van objecttype instellen in Jira Service Management

Objectverwijzingen

Een verwijzing is een verbinding tussen twee verschillende objecten in Assets. Elk object kan worden verbonden met veel andere objecten, niet rechtstreeks, maar via attributen die verwijzingen naar andere objecten bevatten.

Als locatie bijvoorbeeld zijn eigen objecttype is, kan elke locatie-object een van de kantoorlocaties van je bedrijf zijn. Zo kun je snel de locatie instellen voor elke laptop door bijvoorbeeld “Stockholm” te selecteren.

Screenshot van objectverwijzingen in Jira Service Management

Objectverwijzingen hoeven niet handmatig ingesteld te worden. Ze kunnen automatisch worden toegevoegd via netwerkscanners, importmodules, automatiseringsregels enz.

Verwijzingen tussen objecten hebben twee belangrijke voordelen:

  1. Je kunt afhankelijkheden tussen je objecten in kaart brengen. Je kunt je ITSM-applicatie bijvoorbeeld toewijzen aan je bedrijfsservices en de verschillende hosts, besturingssystemen en bestanden waarvan ze afhankelijk zijn. Deze kaart kan ongelooflijk handig zijn om de downstream-effecten te begrijpen van wijzigingen (als ik dit besturingssysteem wijzig, waar heeft dit dan invloed op?), en om oorzaken van incidenten en problemen te achterhalen. En omdat elk object kan worden gekoppeld aan een Jira-issue, bouw je na verloop van tijd een uitgebreide geschiedenis op van je infrastructuur of andere elementen die verder helpt om issues en problemen op te lossen.
  2. Het is eenvoudiger te beheren. Als een kantoor bijvoorbeeld verhuist van Montreal naar Toronto, hoef je alleen maar het object Montreal bij te werken in plaats van in elke laptop Montreal in Toronto te veranderen.

Er zijn twee typen objectverwijzingen:

  1. Uitgaande verwijzingen zijn verwijzingen van het huidige object naar een ander object.
  2. Inkomende verwijzingen wijzen vanuit een ander object naar het huidige object.

Verwijzingen tussen objecten kunnen worden bekeken met de grafische viewer. Je kunt zelf je verwijzingstype bepalen (zoals geïnstalleerd op, eigendom van, leverancier) en je kunt ze een kleurcode geven in de instellingen voor het objectschema.

Verwijzingen tussen objecten in een objectgrafiek weergeven

Assets-rechten

Assets heeft twee soorten rechten:

  • Objectschemarechten - In de instellingen van een objectschema kun je definiëren wie beheerdersrechten heeft voor een bepaald objectschema, wie objectschemagegevens kan bijwerken en wie de gegevens alleen kan bekijken.
  • Objecttyperechten - Soms wil je misschien dat klanten van Jira Service Management alleen bepaalde informatie in een objectschema kunnen bekijken, maar wil je ze geen toegang geven tot alle gegevens in het volledige objectschema. Hier kun je objecttyperechten gebruiken.

Stap 3 - Kiezen welke gegevens moeten worden opgenomen

Elke Assets-installatie is uniek, aangezien er voor elk bedrijf andere informatie gevolgd moet worden. Assets kan alle informatie opslaan die jij en je bedrijf moeten weten en begrijpen. Welke specifieke assets of configuratie-items je moet opnemen, hangt af van wat je probeert te doen. Deze sectie bevat ons advies om te bepalen welke gegevens moeten worden opgenomen.

Definieer je probleem

De meeste zijn geïmplementeerd om een probleem op te lossen, en Assets is daarop geen uitzondering. De tijd voor het oplossen van incidenten kan niet zo snel zijn als je zou willen, of wellicht leveren wijzigingen in een specifieke service vaak onverwachte resultaten op, omdat het lastig is afhankelijkheden van een service te bekijken.

Vind je probleem en gebruik dat om al het andere te definiëren, van wie je erbij betrekt tot welke assets en informatie je in je database opneemt. Bekijk het probleem en begrijp welke extra informatie nodig is om het op te lossen. Deze informatie definieert je objecttypen.

Te veel informatie in één keer toevoegen, kan het lastig maken om de nauwkeurigheid te controleren, dus probeer je op één probleem tegelijk te concentreren. Als je eerste probleem is opgelost, kan Assets groeien om andere problemen op te lossen.

Begin met je services

Als je van plan bent om Assets te gebruiken voor configuratiebeheer, dan raden we je een top-down aanpak aan, en te beginnen met je services. Breng vervolgens in kaart waar deze services van afhankelijk zijn (bijv. toepassingen en hosts). Breng vervolgens in kaart waar die afhankelijkheden van afhankelijk zijn, enzovoort. Op deze manier maak je snel een servicekaart die kan worden gebruikt wanneer incidenten en wijzigingsaanvragen binnenkomen. Je kunt andere gebieden documenteren wanneer en waar dat nodig is.

Denk verder dan fysieke items

Omdat je met Assets de objecten kunt definiëren die je nodig hebt, ben je niet beperkt tot traditionele of zelfs fysieke assets. Bedrijfsservices zijn bijvoorbeeld geen fysieke assets, maar moeten vaak wel tot in detail door mensen worden begrepen. Je kunt er alle fysieke en niet-fysieke afhankelijkheden van een service aan koppelen, dus door alleen een bedrijfsservice-object te bekijken, kun je volledig begrijpen hoe het wordt uitgevoerd.

Je kunt het zo abstract maken als je wilt. Wat veel voorkomt zijn bijvoorbeeld object met een zakelijk belang, omgevingstypen, afdelingen/teams, locaties, etc.

Voorbeeld: bedrijfsservices categoriseren

Stel dat al je bedrijfsservices worden toegevoegd aan Assets onder het objecttype 'Bedrijfsservices'. Mogelijk wil je deze bedrijfsservices indelen in 'Financiën', 'Logistiek', 'Verkoop', 'Infrastructuur', etc. Je kunt dit doen met een attribuut in het objecttype Bedrijfsservice of je kunt een eigen objecttype aanmaken voor deze categorieën met de naam 'Servicecategorie'.

'Business Services' als voorbeeld van het categoriseren van objecttypen

Het voordeel hiervan is dat je details (attributen) kunt toevoegen die specifiek zijn voor de bedrijfsservicecategorie. Misschien is er iemand verantwoordelijk voor alle financiële bedrijfsservices. Je wilt die persoon niet rechtstreeks toevoegen aan elk object van een financiële 'Bedrijfservice', omdat het moeilijker te onderhouden wordt. In plaats daarvan voeg je het slechts één keer toe aan het object 'Financiën' in het objecttype 'Servicecategorie' en nu hoef je het slechts op één plaats bij te werken en hoef je geen gegevens te dupliceren.

Je kunt ook regels hanteren die de operationele status van elke individuele financiële bedrijfsservice nemen en deze uitrollen in een algemene status voor de financiële categorie. Op deze manier kun je snel zien of er serviceproblemen zijn met elke servicecategorie door de categorie-objecten te bekijken.

Je hoeft dit soort objecten niet toe te voegen aan Assets, maar het is belangrijk om te weten dat je niet beperkt bent door traditionele assets-/configuratie-items. Het hangt allemaal af van wat je wilt doen en daarom is het begrijpen van je doelen en de informatie die je nodig heeft om ze te bereiken zo belangrijk.

Kijk vooruit en groei geleidelijk

Houd rekening met eventuele uitbreidingen die je in de toekomst mogelijk wilt toevoegen. Dit bepaalt welke gegevens je kiest om toe te voegen, maar ook hoe je je gegevens structureert.

Hoewel het goed is om in gedachten te houden wat je gewenste eindpunt is, raden we aan om Assets geleidelijk op te bouwen. Het is erg lastig om één grote release te doen met 100% nauwkeurige gegevens voor duizenden objecten. Het is veel eenvoudiger om klein te beginnen en nieuwe attributen, objecten en objectschema's toe te voegen.

We raden aan een probleem te vinden, Assets zo in te richten om het op te lossen en vervolgens verder te gaan met het volgende probleem, zodat Assets steeds groter wordt.

Schep realistische verwachtingen voor nauwkeurigheid

100% nauwkeurigheid moet altijd het doel zijn, maar in werkelijkheid is dat misschien niet haalbaar. Zolang de gegevens nauwkeurig genoeg zijn om meer bedrijfswaarde te bieden dan wanneer je ze in de eerste plaats helemaal niet hebt, dan is de uitkomst positief. Veel CMDB-projecten kunnen vertragen of zelfs mislukken, omdat men wacht totdat ze 'perfect' zijn voordat ze live gaan.


Stap 4 - Je gegevens in Assets krijgen

Alles handmatig invoeren kan binnen een grote organisatie een hels karwei zijn. Daarom zijn er een paar tools om je te helpen.

Asset Discovery

Asset Discovery (gratis beschikbaar op de Atlassian Marketplace) is een scanner zonder agent die netwerkassets oppikt. Je kunt kiezen welke assets en attributen je in je Assets-objectschema's verwerkt en je eigen scanpatronen maken om meer nieuwe assets te vinden. Als je het volgens een schema uitvoert, worden wijzigingen opgepikt en gegevens bijgewerkt. Met automatiseringsregels kun je zelfs Jira-issues, e-mailmeldingen en meer activeren op basis van gedetecteerde wijzigingen.

Importeerprogramma's

Je kunt importeurs gebruiken om gegevens uit andere bronnen in te voeren. Deze importeerregels kunnen volgens een schema worden gesynchroniseerd, zodat je je gegevens indien nodig kunt bijwerken. Voor elk importeertype moet je bepalen waar de gegevens worden opgeslagen en waar ze naartoe moeten in Assets.

CSV-import

Als je een spreadsheet zoals Excel of Sheets gebruikt dat al je assets bevat, kun je de CSV-import gebruiken om je gegevens naar Assets te verplaatsen. Dit zorgt ervoor dat je over een geïntegreerd en transparant systeem beschikt waar je je assets kunt koppelen aan issues en de impact kunt analyseren.

JSON-import

Je kunt objecten importeren in Assets met een JSON-bestand met de te importeren gegevens.

Handige tips

We raden aan Asset Discovery en importeurs zo vaak mogelijk uit te voeren in rustige tijden. Bekijk hoe vaak je denkt dat gegevens gaan veranderen en hoe belangrijk die gegevens zijn om te bepalen hoe vaak je moet plannen om ze uit te voeren. Je wilt de snelheid waarmee gegevens veranderen nét voor blijven.

Met Asset Discovery kun je verschillende scanpatronen op verschillende frequenties laten uitvoeren om de benodigde resources te verlagen om Assets zo up-to-date mogelijk te houden.


Stap 5 - Besluiten hoe je je gegevens wilt structureren

Deel gegevens op in logische objectschema's

We raden aan om meerdere objectschema's te hebben gebaseerd op het gebruik van de gegevens of de eigenaar(s) van de gegevens.

Het opsplitsen van je gegevens in verschillende objectschema's is meer gebruiksvriendelijk en eenvoudiger te onderhouden dan een groot schema. Teams zoals financiële of HR-afdelingen die mogelijk informatie van Assets nodig hebben, hoeven niet overspoeld te worden met informatie waar ze niets aan hebben. Het is ook eenvoudiger om een team te vragen een regelmatige controle van de gegevenskwaliteit op één objectschema uit te voeren, dan ze te vragen alleen bepaalde delen van een groot objectschema te controleren.

Bundel je gegevens

Als je ergens een perfect bruikbare database of informatiebron hebt en er al processen zijn om deze up-to-date te houden, hoeven de gegevens niet te worden verplaatst naar Assets. In plaats daarvan is het waarschijnlijk beter een kopie van de relevante gegevens te maken met behulp van integraties en deze integraties uit te laten voeren volgens een schema om de Assets-informatie bij te werken.

Assets wordt geleverd met een aantal importeurs (zie vorig gedeelte). Met deze importeermodules kan je besluitvormingsinformatie beschikbaar worden gesteld in een Jira-issue of in Assets zelf, maar je bewaart geen twee afzonderlijke kopieën.

Soms maken mensen aparte objectschema's aan voor deze geïmporteerde gegevens en soms integreren mensen ze in grotere objectschema's. Als de gegevens voor verschillende toepassingen gebruikt worden (bijv. IT-support en HR), dan is het logischer ze als een apart objectschema op te slaan in plaats van ze direct te koppelen aan je IT-objectschema en vervolgens HR toegang te geven tot dat schema.

Als je geen importeermodule kunt gebruiken, kun je ook een object aanmaken en het een URL-attribuut geven dat gekoppeld is aan de andere database waar meer informatie kan worden gevonden. Deze optie is handig als je alleen wilt dat agents de informatie kunnen bekijken en niet wilt zoeken of rapporteren op basis daarvan.

Voorkom dat dezelfde attributen overal worden gebruikt

Als een attribuut op veel plaatsen wordt gebruikt en dezelfde herhaalde waarden heeft, is het vaak logischer er een eigen objecttype voor te maken. Je kunt een attribuut hebben dat Leverancier heet voor de objecttypen laptop, telefoon, printer, monitor, etc. En voor elk object moet je de leveranciersnaam voor die specifieke laptop of telefoon typen (of importeren).

Dit is prima, maar het is efficiënter om een objecttype “Leveranciers” te hebben en om verschillende redenen elke leverancier als object in te stellen:

  • Misschien wil je meer dan alleen de naam van de leverancier. Mogelijk wil je andere informatie met betrekking tot de leverancier, zoals het nummer van de contactpersoon bij support of links naar contracten. Je wilt dit niet herhalen voor elke laptop en elke telefoon. Gewoon één keer koppelen aan het leverancier-object. Dit helpt ook als je elementen van leveranciersmanagement binnen Jira Service Management wilt uitvoeren.
  • De leverancier wordt op deze manier gestandaardiseerd, wat betekent dat rapporten eenvoudiger kunnen worden uitgevoerd. Als je wilt rapporteren over het aantal ondersteuningsaanvragen per leverancier, kun je er zeker van zijn dat je niets mist omdat iemand Micrsoft of Aple ergens heeft genoteerd.
  • Als de leverancier van naam verandert of op de één of andere manier moet worden aangepast, dan hoef je dit maar op één plek te wijzigen.

Leverancier is slechts een voorbeeld, maar andere zijn onder andere niveaus voor bedrijfsbelang, implementatie-omgevingen, afdelingen en locaties.


Stap 6 - Aangepaste Assets-velden configureren voor je Jira-issues

In dit gedeelte wordt uitgelegd hoe je Jira-issues kunt configureren om ze aan Assets-objecten te koppelen. Bijvoorbeeld het koppelen van de desbetreffende bedrijfsservice aan je incidentissues, het toevoegen van een computer aan een issue van een hardware-aanvraag of het toevoegen van een groep mogelijk betrokken hosts aan een issue met een wijzigingsaanvraag.

Assets geeft je toegang tot een nieuw, specifiek aangepast veld. Dit aangepaste veld moet op zo'n manier worden geconfigureerd dat het naar een bepaalde groep objecten verwijst.


Stap 7 - Automatiseringen instellen

Assets bevat een nieuwe set objectgerelateerde automatiseringtriggers en acties die kunnen worden gebruikt om verschillende taken te automatiseren.

Bijvoorbeeld:

  • De eigenaar of status bijwerken van een laptop tijdens de workflow van een serviceaanvraag
  • De status van onderdelen van je infrastructuur bijwerken naar 'incidenten in behandeling' wanneer zich een incidentissue voordoet
  • Jira-issues automatisch naar bepaalde personen leiden op basis van de bijgevoegde objecten
  • Belangrijke personen op de hoogte stellen wanneer licenties, contracten of garanties vervallen

Stap 8 - Bepalen hoe je je gegevens nauwkeurig kunt houden

Het is van cruciaal belang je gegevens up-to-date houden, anders werken teams onder onjuiste veronderstellingen die het oplossen van incidenten kunnen vertragen of tot het verkeerde resultaat kunnen leiden na een serviceaanvraag.

Er zijn een aantal manieren om je gegevens up-to-date te houden in Assets, waarvan vele afhankelijk zijn van automatisering om het zware werk te doen.

  1. Voer regelmatig audits uit van je gegevens.
    Automatiseringsregels voor Assets kunnen worden ingesteld om mensen op de hoogte te stellen van een gegevensaudit volgens een schema. Dit herinnert ze eraan een snelle controle uit te voeren om ervoor te zorgen dat belangrijke assets up-to-date zijn.
  2. Synchroniseer Asset Discovery en relevante importeerprogramma's en integraties regelmatig.
    Een van de oorzaken van verouderde gegevens is het niet vaak genoeg synchroniseren van Assets met externe gegevensbronnen. Denk eens na over hoe vaak gegevens in je externe bron veranderen en hoe vaak deze worden gebruikt in Jira Service Management om de correcte balans te krijgen. Als iets vaak verandert en regelmatig aan issues wordt gekoppeld, moet het mogelijk om de 24 uur worden gesynchroniseerd. Andere integraties kunnen weken of zelfs maanden wachten.
  3. Gebruik automatiseringsregels.
    Wanneer er beslissingen worden genomen in Jira-issues die asset/configuratiegegevens wijzigen, is het belangrijk dat je ze opslaat in Assets.

Als een agent bijvoorbeeld besluit een gebruiker een nieuwe laptop te geven omdat de huidige kapot is, is er informatie die moet worden opgeslagen in Assets:

  • Voor de nieuwe laptop moet de eigenaar worden aangepast aan de aanvrager en de status worden gewijzigd in 'in onderhoud'.
  • De eigenaar van de oude laptop moet worden verwijderd en de status moet gewijzigd worden in 'defect'.

Terwijl de agent dit doorgeeft aan de aanvrager, kun je overgangsschermen en Assets-postfuncties gebruiken om dergelijke informatie op te slaan en de nieuwe statussen en eigenaars in Assets in te stellen met behulp van automatisering.

Dit is slechts één voorbeeld, maar als je Assets integreert in je Jira-workflows, overweeg dan welke informatie van de issue mogelijk moet worden doorgestuurd naar Assets. Idealiter wil je Assets zo min mogelijk handmatig bijwerken, aangezien dit snel wordt vergeten.


Stap 9: Houd statistieken bij die aantonen dat er vooruitgang is geboekt

Zodra je assets zijn ingesteld, kun je beginnen met het bewijzen van waarde met behulp van kant-en-klare rapporten. Hiermee kun je asset- en configuratiegegevens kritisch analyseren, betere besluitvorming mogelijk maken en eenvoudig rapporten uitbrengen. Afhankelijk van wat je bijhoudt in Assets, kun je deze rapporten gebruiken voor voorraadbeheer, levenscyclusbeheer, het meten van de productiviteit van werknemers en meer. De rapporten tonen objecttypen, objecten per attribuut of objecten in de loop van de tijd. Je zou bijvoorbeeld kunnen kijken naar gegevens over hoeveel laptops van werknemers er momenteel in gebruik zijn en hoeveel laptops er onderhoud nodig hebben, van wie ze zijn en hoeveel ze kosten.


Overige onderwerpen

Assets Query Language - AQL

Assets Query Language (AQL) is de taal die wordt gebruikt voor query's in Assets. AGL is handig wanneer je zoekweergaven, automatiseringsregels, geavanceerde verwijzingen tussen assets wilt aanmaken of zelfs imports wilt instrueren.


Handige tips

Formulierontwerp