Jira Service Management implementation in one of the biggest Polish banks
One of the biggest universal banking institutions in Poland found out that the ITSM software had stopped supporting their advanced IT processes. Therefore, they decided to switch to the Atlassian suite. Since then, they have created 687 Jira Software projects and 38 Jira Service Management projects, received about 480,000 issues, created 887 custom fields and 138 workflows, and registered over 8000 users… and counting! However, implementation of Jira Service Management wouldn’t have been possible if it hadn’t been for apps available on the Atlassian Marketplace.
What made the bank try out the Atlassian tool?
Before working with Jira Service Management, the company had been using ServiceDesk Plus. They considered it a quite sufficient tool for classic service desk work. However, the software features proved inadequate for such a demanding business. For example, when teams were using ServiceDesk Plus, they had to ask the provider to introduce modifications every time the requirements changed. The in-house improvement of the tool wasn’t possible then. With Jira Service Management, they have become fully independent. If there’s no solution in the Marketplace, then the team is able to develop it on their own. The bank is proud to say that they added lightning speed to the implementation of new ideas thanks to this.
The second reason was the large license limitations in the case of ServiceDesk Plus. People with permissions similar to the agent from Jira Service Management weren’t able to edit, validate or check anything, thus having their work obstructed. Whilst linking tasks with a project, the team wasn’t able to track maintenance work which usually focuses on development. The cost of accessing the agent’s service functionality for multiple ServiceDesk Plus users was greater than the benefits ServiceDesk Plus could offer. In the case of Jira Service Management, they have a simple solution that provides consistent tracking regardless of the project.
Banking processes moved safely into Jira
Thanks to Jira Service Management, the bank has a full picture ITIL-wise: projects, implementation, service requests, maintenance, and incident management in one place. This is a major advantage of the tool. Because of this seamlessness, the managers now aim to move all processes and solutions to Jira, so they also have switched from their test management tool TestLink to TestFLO.
The bank teams appreciate custom apps for Jira that provide the company with useful functionalities. Most of all, they value incident linking, service requests, changes, etc., through Project Charter. For some time now, they have been using Jira Service Management as well. The uplifted tool with new features that include Opsgenie tremendously helps process major incidents that go to various teams involved in various stages of incident management.
Efficient project management in Jira Service Management
The banking process starts with a software request which then transitions through a custom Project Charter to Jira Service Management. However, for all the other matters, especially those in the maintenance team like network configuration, etc., they have separate Jira Service Management projects. This is possible thanks to Project Charter. It links a project card with these tickets using an Issue Picker custom field that defines the main ticket. This makes it easier to track the work of the maintenance teams.
This is crucial from the project and resource management point of view. This system enables tracking of users’ work regardless of the project they work on. Another key point here is the ability to tell apart new projects from maintenance requests. This helps to distinguish which tasks a user does within the project, not as part of maintenance that happens after the project is implemented. What’s more, administrators differentiate tasks they do as maintenance and those within a specific project. It makes it easier for them to move within Jira and find the scope of their work.
Jira Service Management is a part of a compatible system that enables implementation of the project management cycle and accurately tracks the user’s progress regardless of the project they work on
The licensing model for the 300-people IT department
For now, there are 200 agents working in the IT department of the bank, if we focus only on agents responsible for administration and maintenance. Once we add development, there will be around 300 people. The banking institution decided on an unlimited Jira Service Management license. They claim to have learned a lesson from problems with licenses whilst using ServiceDesk Plus. The number of service desk projects, tickets, and therefore the demand for new employees and licenses is constantly increasing. It has turned out that only the unlimited version could meet the expectations of the growing business.
The decision has paid off because now they don’t have to worry that someone doesn’t have a license and can’t do their work properly. In this case, there are more licenses available, people can work in real-time, exchange tickets, have some ideas, and share them with us to evaluate, fix or develop.
It was a significant change for this particular bank. Usually, a service desk is associated solely with IT processes. In this case, the IT department has access to those licenses. Also, HR and other business areas unrelated to IT use it, for example, to manage and cash intellectual property. From the legal point of view, a person who creates a piece of code, document, presentation, etc., may choose to account for a share of the tax as intellectual property, just like artists do. Thanks to the choice of licensing, the team could create a legitimate process together with the HR department.
For instance, people from the IT department want to deduct that tax share as intellectual property. In order to do this, they need to raise a dedicated request which goes to the HR department. They store it and pay a lower tax rate for them. The whole process works pretty well because teams don’t have a lot of requests to correct the tax returns, even though the interest in intellectual property and the monthly number of requests is quite high.
The influence of Jira Service Management on maintenance and performance
Each month the bank gets around 13,000 tickets for service desk projects and 7,000 tickets for software projects. It gives around 20K tickets in our Jira each month. From the moment they switched to Jira Service Management, in January 2018, they have received around 170,000 tickets. This number will be increasing because the company is constantly adding new areas based on the so-called “e-mail flow”. There are more and more teams and functionalities that, for example, add new templates to existing workflows, new fields, or new items in general. Based on this, they need to create new rules, etc., to ensure that the ticket goes to a specific agent.
Jira Service Management definitely meets the challenge. Ultimately, the bank aims for a Single Point of Contact (SPOC) so that everything goes to the service desk, including technical matters.
Queues for Jira Service Management extension as a solution that supports IT, HR, and developers
According to the bank representatives, the native Jira Service Management queues had some flaws and turned out to be insufficient for the company’s needs. For example, there were 38 service desk projects going on at the same time, and agents needed to work in various areas, switching between projects. It was tedious for them. That’s why the team had to have the possibility to configure cross-project queues with filters, and Queues for Jira Service Management helped with this.
The key here is that agents who solve tickets need to have access to the queues with listed tickets they’re responsible for. They shouldn’t switch between projects to find their tickets. In this case, it’s best to use cross-project queues with well-defined filters and the Queues app provides its users with this possibility. Also, in the case of cross-project queues, the dashboards refresh automatically. The tickets are constantly updated or uploaded, no matter if they come from projects A, B, or C. Thanks to this, all the stakeholders can keep track of the project.
The factors that could make or break the decision about Jira Service Management
The other app that convinced the bank to switch to the Atlassian Suite was Extension for Jira Service Management because of its Dynamic Forms and Visibility features. Multiple projects and big teams required the company to find a solution to optimize the request forms. Additionally, thanks to the apps’ functionalities, the team was able to limit the visibility of the template or specific fields to a specific user group.
Another core app for the bank is ScriptRunner. It allows writing simple scripts with various functionalities from validators through post functions to automatization rules, instead of developing plugins. It provides a lot of possibilities, so now the team can focus on developing this script more precisely without worrying about digging into the API or Atlassian’s SDK.
Yet another key app is Active Directory Attribute Sync which enables to display of user attributes not only in the default way but also inside Jira as read-only values in custom fields or on the user’s profile view.
The results of the Jira Service Management implementation
The Atlassian tool has improved the perception of internal processes in the entire institution. Before, the team used NPS for the purpose, and as the managers asked people to conduct relevant measurements after changing the solution, they mostly received positive answers. The team has noticed a significant improvement in user experience. The operations have been optimized, and the employees are able to process more work, automate more tasks, and integrate the service desk with various systems, not only those from Atlassian.
Another benefit mentioned by the bank managers is the integration of Jira Service Management with Confluence. All data stored in Confluence can be connected to Jira Service Management as, for example, knowledge base, documentation, or project documents. It assures the comfort of working in one place and transparency because the team members can see the entire lifecycle of the tickets.
Last but not least, other business teams in the company want Jira Service Management to replace their existing solution or become their first solution (if they have never had one). They prefer implementing the tool that has been tested instead of going for a different solution with which they can have problems when it comes to development and maintenance. And if other teams want what you have – can you think of a better recommendation?
Was this helpful?
Thanks!
Katarzyna Kornaga _Deviniti_
4 comments