Onboardingshandleiding voor Assets

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'.

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.

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.