This article is part of a blog series!

Part Title
1 JIRA for asset management: Overview
2 JIRA for asset management: Inventory setup
3 JIRA for asset management: Workflow setup
4 JIRA for asset management: Reporting setup
5 JIRA for asset management: Physical implementation

 

This is the second article in a series of five about using JIRA for asset management. If you can read the first article, please do so for an overview of the entire process. In this article, we will dig into how to set up a project, configure asset types, and track the right level of attributes on each item in inventory.

Create a project

A project in JIRA is a collection of issues that revolve around a single set of work or theme. I highly recommend creating a separate project to manage inventory. Why not keep it in the same project as the helpdesk? The helpdesk will have specific workflows and service level agreements (SLAs) to manage requests from their customers. Having a separate project enables administrators to more flexibly tune JIRA for each use case.  Let’s start with the simple issue tracking project.

jira_asset_tracking_project_type

Let’s call our project TAG as each item in inventory will have a “tag” from JIRA.

Define types of assets

The first step is deciding the classes of inventory to put under tracking. Each team will have slightly different needs for their asset management. In this example, I’ll be focusing on typical office hardware: computers, monitors, and software.

asset_management_issue_typesIn JIRA, issue types define classes of inventory. In our example, we will create an issue type for a computer, monitor, and software. We can then associate the asset issue types using an issue type scheme. What is an issue type scheme? An tissue type scheme is a set of issue types that are available for creation in a project. Our asset project and a project used for software development would have different issue type schemes because the two projects contain different types of issues.

asset_management_issue_type_scheme

Add Custom Fields

JIRA has two main field types: system and custom. Many of the system fields apply for asset management. Let’s take a quick overview:

  • Summary: The summary is a text field that defines what the inventory item is.
  • Assignee: Assignees in JIRA are responsible for issues to which they are assigned. For example, if John Smith has a Macintosh laptop, the issue in JIRA associated with that laptop would be assigned to him.
  • Reporter: The reporter is usually someone in IT who manages inventory. The reporter is usually the person who procures the item and delivers it to the end-user.
  • Labels: Labels are flexible metadata that teams can use to describe assets. A team may decide to use a label called “custom” to indicate that this piece of inventory deviates from the standard build-out process.
  • JIRA also tracks fields like create date, last updated, status, resolution, and the inventory type by default.

You’ll also want to add your own attributes to each asset type. Custom fields allow each organization to track the information that’s important for them. From the prior example, you might be thinking, shouldn’t I create specific issue types for Macs and PCs? With JIRA, administrators can create custom fields for each issue type. In this example, we will use a custom field to track the platform of the computer.

Let’s take a look at how we use JIRA for asset management here at Atlassian. Below I have two screens that show all of the custom fields for a Macintosh computer and a monitor. Because they are two different issue types, you can define custom fields independently between them.

A monitor:

asset_tracking_monitorA laptop:

jira_asset_tracking_laptop

How do you add a custom field? With JIRA 6.1, it’s easy! Just go to the issue detail page for the type of inventory you’d like to add a button on, click the admin button, and follow the wizard.

jira_asset_tracking_add_field

At first it can be tempting to add lots of fields for each type of inventory. I encourage you to read my best practices guide: 8 steps to unlock the power of JIRA fields.

Connect fields to screens

Screens in JIRA are the visual way users interact with fields. For example, pressing the create button brings up the create screen for that issue type.

create_asset

When creating a field, JIRA will prompt you to relate a field to a screen. By default, each issue type has three primary screens: create, view, edit. Usually, all fields are on the view and edit screen. Some teams will remove a few fields from the create screen that aren’t known at creation time.

Screens can also be used in workflow transitions. If a device needs to go out for service, the IT team could have a list of vendors pop up when a device transitions to “service required” in JIRA. Screens are optional on workflow transition.  Just remember you can collect data incrementally rather than leaving a bunch of fields blank up-front.

As a best practice, I recommend having a screen scheme for each issue type. For example, the computer issue type would have a set of screens for create, view, and edit. A collection of using schemes for issue types is called an issue type screen scheme. You’ll want to associate the issue type screen scheme for asset management with the asset management project in JIRA.

Enabling permissions and security

JIRA has two main ways to control access to issues. Permission schemes focus on actions the user does inside of the JIRA project. Some IT organizations will want to restrict the editing of assets to members of the IT group while allowing everyone to browse individual inventory. A permission scheme can use an active directory or lightweight directory access protocol (LDAP) group to restrict access to the edit issues feature in our asset management project. At Atlassian, we give people the option to browse inventory, but only the IT team can make edits to the individual records.

 

asset_tracking_permission_scheme

Issue security schemes restrict which issues a user can see inside of a project. If the IT group wants users to see inventory that is assigned to them but not anything else, an issue security scheme is the way to go. JIRA administrators can create custom security levels for a fine-grained permission model inside of a JIRA project.

Workflow?

At this point, I’d recommend sticking with the default JIRA workflow. It won’t be perfect for asset management, but it will give you time to learn the other core concepts in JIRA. In the next article, I’ll focus specifically on workflow for inventory management.

Ready to try JIRA? Sign up for a free trial below.

Try JIRA Free!