Neem contact met ons op
As Atlassian consultants, we've implemented numerous ITSM solutions, in varying degrees of complexity and for different types of businesses, for startups all the way to large enterprises. One of the most challenging parts of these implementations is often to map out all of the different organizational processes and then, to translate them into perfectly matching workflows in Jira. This should really be done in collaboration with the customer, in order to get their processes right while still keeping best practices from sources like Atlassian and the ITIL Framework in mind throughout the process.
In this blog, we will tell you more about how we implement best practices when it comes to Jira Service Management workflows.
Besides the fact that all organizations are different from one another, every implementation we work on starts with a basic workflow. Of course, some customers have processes that may require a lot more custom adjustments than others, but there's always this basic workflow we like to start with. From there the flows for incidents, service requests, changes and problems are easily designed and further customized to fit the customer's needs.
With this post, we'd like to share this basic workflow with you!
One workflow to rule them all
Here it is! The basic workflow we use in roughly all our Jira Service Management implementations. Simple, yet very effective!
First status: Waiting for support
Requests come in on the Waiting for support status. From that status, a (first line) agent can assess whether the request includes enough information, or if the customer should provide more information (enter; the Waiting for customer ↔ Waiting for support loop).
Once this is done, the agent can proceed with the Allocate transition. This transition may seem like 'an unnecessary extra click for the agent', but I find this very powerful; if used in the right way!
This transition in the workflow gives you the opportunity to present your agent with a screen where important fields are shown. Fields like 'Solution group', 'Priority', 'Organization', 'Request Category' and/or 'Assignee'. These are fields which your customer may have not filled in correctly (or in some cases, isn't able to fill in at all). And yet this is very valuable data, which you should want to capture correctly as soon as possible.
The 'Solution group' for example can be used to distribute the issue to the right group in your Service Desk. The 'Priority' for be used to base SLA's on. The 'Request Category' can be used in reporting, so you can analyze for example, what kind of requests are coming in most. And if you present these fields in your transition screen, maybe even make them required, your agent is triggered to review and/or fill in these fields. In short, this step ensures your issue is dispatched and data is collected properly!
The link with development
After the agent successfully allocated the request to a colleague, to a team or to himself, the request is ready to get picked up by the right person, who can set the status to In progress. So as you can see in the image above, we only have one blue In progress status here. This is where we usually expand the workflow to fit the issue type and organization-specific processes. For example, when this workflow is going to be used for the issue type Incident, we can implement one or more statuses like 'Waiting for Development'. This can be used when the Incident is caused by a Bug for example, which the Development team first needs to resolve before the Incident can be resolved. With issue linking and automation rules - that can, for example, create a linked Bug for you - you can really streamline this process.
Assess, Assign, Resolve, Repeat
Lastly, a request will move to the Resolved status and finally ends up in the final Closed status.
Why do we need these two separate "green" statuses you are wondering? Well, we usually advise implementing this to make sure your customer has the opportunity to accept or decline the solution as offered. By using the Resolved status, the request can still be reopened if the customer is not happy with the resolution provided.
However, after a certain period of time when the issue is in the Resolved status and no feedback returns from the customer, you'll want to assume that the customer has accepted this resolution and that you can close the request. With some automation in place, you can make sure your requests move to the Closed status after the desired period of time, if there's no feedback from the customer. This prevents a situation where a customer reopens a request that has been resolved for let's say, a year! This could cause some serious damage to your SLA's and reports.
Tune & expand, but keep it simple!
Using this basic workflow, you can start to fine-tune and expand it to make it fit specific issue types like incidents, service requests, changes and problems. As these types of requests are often different in nature, workflows should be adjusted too. Try to keep it simple though! (Over)complex workflows are hard to understand, use and maintain and can lead to serious frustration for all those involved. So only expand in case it's really needed and if you do expand the basic workflow with a new status, try to use one of the existing statuses in your Jira instance.
Do you need assistance with configuring workflows in Jira? Or creating the perfect workflow for your team's processes?
Get in touch and let us help you out!
Vond je deze post leuk
Dan denken we dat dit ook wat voor jou is.