Asset Management | Jira Service Desk | 10 MIN READ

How to Standardize Jira Asset Management in a Decentralized Environment

How do you get 500+ professionals across 100+ support teams to deliver consistent services and support together as one cohesive unit? That was the question that led a major research university embarking on an important journey of digital transformation that leveraged Insight Asset Management for Jira. 

Watch the entire presentation above or jump to the main takeaways:

 Ditch spreadsheets
 Create service catalogues
 Establish a governance committee
 Minimize the cost of licenses
 Offer standard options
 Remember non-IT teams
 Establish a robust digital architecture

This article is part of a series on the key role of context in service management.

Takeaway 

Ditch Spreadsheets and Hop on the Digital Transformation Wagon

Operating with spreadsheets lead to the frequent misrouting of tickets. Bringing all service desks in one system - containing all service catalogues, CMDB, HR and customer databases  - led to cohesive operations and an 80% reduction in misrouting.

 

The starting point was daunting: They wanted to streamline and better manage over a hundred decentralized support teams that were operating through shared mailboxes and spreadsheets. Yikes.

As a result, requests were frequently misrouted to the wrong team, a trend that created a huge backlog of service issues that was quickly spiralling out of control. The university’s Chief IT Architect and his team knew there had to be a better way.

And they found one, using Jira and Confluence as the foundations of a complete change in how their IT teams operated and connected with other departments within the educational institution.

The success of this transformation was made possible in part by the creation of an extensive service catalogue, asset database (CMDB), customer database and HR database - all in Jira. This allowed the university to get a clear picture of their IT infrastructure, something they hadn't been able to do before.

Today, the university operates with a single, cost-effective system that integrates all their decentralized service desks in a seamless ITIL-compliant environment. The results speak for themselves, as the teams involved has combined to reduce misrouted service ticket requests by 80%. 

Takeaway 

Create Service Catalogues to Support Your Service Management Practice 

Though Jira and Confluence were part of the university's long-term plan early on, building a service catalogue and related database functionality was the move that made the lives of staff members and customers alike so much easier.

 

“How do you translate ITIL into an organization that doesn’t know or doesn’t care what it is?” he used this question to frame a conversation that became the university’s starting point for building their overall strategy.

In order to execute this vision, several pieces needed to be in place. One of those elements was their service catalogue, an organized, curated digital mapping of any services related to business or information technology that can be performed by, for, or within an enterprise. 

“When we got started with this [about] 6 years ago, we didn’t know what a service catalogue would look like,” their Chief IT Architect said. “[We] have 260 services within IT, but across the organization, there are many more.” 

 

Although Jira and Confluence established as the university’s foundation early on, it wasn’t until Insight was introduced to the mix that everyone’s lives were made a whole lot easier.

 

Referring to the above, he said:

“Getting organized was tricky until we started actually visually laying things out [in Insight]. So this is what our service catalogue looks like within the tool. It’s a 40 tier hierarchy. And the way I [express] it today is that it’s actually multiple catalogues [...] We broke these down in multiple catalogues and, when you drill into one of these, you get a mixture of processes and services that folks know and also technology [...] So if you know what Active Directory is, great. If you only know it as Account Management, that’s fine too, it’s there.” 

 

Takeaway 

Establish a Governance Committee to Ensure Alignment Across Teams

Building a CMDB and mapping out your dependencies is only part of the university's implementation strategy. With new processes came the need for new governance guidelines and essentially rethinking their operational approach.

 

With an added emphasis on organization and structuring their CMDB came an underrated step in realizing their long-term vision: establishing new guidelines when it comes to governance. This included maintaining the service catalogue and rethinking how different individuals and/or teams operated with and alongside one another. 

Here's their Chief IT Architect on the unique challenges this shift presented:

“At first, everyone who managed a service was responsible for their own catalogues. We wanted to centralize that. So what we did was establish governance. Governance was key to maintaining their service catalogue [...] It’s basically breaking down silos, breaking down the conversations and opening the teams to have a more transparent conversation - versus it’s my service, it’s my way of doing things.”

As with any large-scale changes to organizational structure and inter-team dependencies, the proposed structure that was not accepted initially. Common questions included: “Why do you have so many eyes on this?” and “Why can’t we just do what we want?”

After going through a few iterations of their governance model, the primary stakeholders settled on the solution of having sponsors - in other words, a council with voting members. One of the main reasons for this model’s adoption was because it generated consensus and inclusion, despite the possibility of slower implementation or competing priorities.

 

As for the biggest cost related to governance, he summed it up in two words: “people time. People in meetings listening to other people talk, their ideas, and trying to promote their ideas.”

 

Takeaway 

Minimize Cost with Processes That Require Fewer Licenses for Service Delivery

Licensing was an important factor in the university's decision to change their ITSM strategy, with a major research university upside being the cost savings they would enjoy due to mixed licensing and other ways to minimize expenses.

 

Like most IT organizations, the university also makes identifying and acting on deep cost savings opportunities a major research university priority. One of the ways their team slashed their expenses was rethinking their approach to licensing models and using a mix of Jira products for different needs, instead of shelling out for a pricier site-wide unlimited license.

In this specific instance, they use Jira Core to access add-ons like Insight where the use of Jira Software isn’t needed. They’re not integrated in Jira Service Desk. They just need to get access to our assets for our service catalogue. So we are using our Jira Core license to save there.

 

Takeaway 

Offer Standard Options to Avoid Tailoring to Each Particular Need

Jira and Insight can combine to give users an endless amount of customizability, right at their fingertips. However, with that many options at the ready, avoiding a messy approach to conceptualization and deployment was a huge priority for the the university team.

 

One of the potential downsides to a robustly customizable Jira app like Insight is the seemingly unlimited amount of options. Without a sound sense of structure and a firm grasp on your organization’s long-term needs and goals, things can get away from you in a hurry.

The university's Chief IT Architect said this was one of the keys to the success or failure of the university’s project. In the beginning, it was a matter of going back to ITIL basics:

“[We] went back to that ITIL framework. We can customize, but what is the architecture that the industry is starting to leverage? [...] Basically said: Why do we need to have a custom workflow for every service and every team? So we established basis essentially and then allowed small variants. The used an ABC model, where they create a base version A and slight variants B and C. But they wouldn’t go further to avoid unique workflows.”

However, once those workflow possibilities were explored more deeply, the results were overwhelmingly positive. Him again:

“They asked people to try a couple of templates [and we] found a ton of success for this. I think today we only 4 or 5 types of workflows that have the ABC concept. General service desk for non-IT, service desk for IT, and then everything else that’s either agile or task. 

 

The same mentality carried over to custom fields, where the total amount migrated from multiple Jira environments had ballooned to more than 1,000. Simple language distinctions - such as the difference between “Delivery Date” and “Delivered On” - allowed their team to (re)classify common terms and help everyone involved understand what’s available to them.

Similarly to their workflows, the goal was to limit the number of custom screens, putting an added emphasis on contextual needs, such as those across different Jira projects or issue types. Once again, people were asked to test-drive this revised system, resulting in mostly positive feedback.

 

 

He highlighted the group’s mantra that continues to guide them on the topic of customization: Just because you can doesn’t mean you should. He elaborated:

“We tried to minimize customization. We still have these conversations with technical teams today. They come back and say, ‘Here’s all the fun stuff we can do.’ We [must] have real conversations about what we should or shouldn’t do something. Change the culture to focus on the many, [not] individuals. This helps the teams be more open and be more collaborative because they are talking the same language and structures.”

 

Takeaway

Remember non-IT Teams to Build a Uniform Enterprise Service Management Model

Integrating professionals who don't work in IT into a digital environment that was built with IT personnel in mind was no easy feat. the university accomplished this by, in part, going back to basics and asking some tough questions.

 

Arguably the biggest challenge during the university’s standardization process was transitioning non-IT teams into a digital ecosystem that, in principle, was built for IT professionals. The reason? Regardless of how they replaced their ticketing system, the ripple effect from that decision inevitably touches many other domains outside the scope of IT.

As the university's Chief IT Architect put it:

“We were focusing on what we needed to do to replace our ticketing system. While we were doing that, I was working on the background saying: ‘Well, what does it mean to neuroscience? What does it mean to purchasing? What does it mean to HR? What does it mean to Advancement, which is our gift fundraising? What does this system mean to them?’ [...] They all had spreadsheets, they all had shared mailboxes. I said: ‘Stop. Why are you doing this to yourselves?’” 

 

Conceptually, this meant taking the IT out of ITSM and repositioning the change as moving towards a uniform Enterprise Service Management model. Common workflows and templates were established and distributed to different teams in various departments, with initial bumps in the road giving way to the organized, curated decentralized environment that had been their goal from Day 1.

During the presentation, he summarized how they got around those early failed integration attempts:

“[...] We found was each group that was considered ‘non-IT’ had somebody who knew IT. [So] they took those folks and gave them access to manage request types, permissions and some of the capabilities in service desk. That led to a complicated conversation as well: Do you have an IT team that you lean on? [...] For the non-IT teams, providing support for them is basically coming up with a shared-support model of here’s what you’re responsible for and here what we’re responsible for.”

 

Takeaway 

Establish a Robust Digital Architecture That Keeps Yielding Improvements and Returns

One of the university's most important tasks was building a digital architecture that not only paid dividends for them immediately after adoption, but also set the table for evolution and growth in the future.

 

The university’s solution runs Insight for Jira Server. Initially, this was because, in their unique decentralized environment, they wanted to do things that weren’t possible using Cloud. Since that decision was made two years ago, Jira Cloud continues to mature and many of those capabilities are transitioning over. This could lead to another migration down the road.

That said, he maintains that the university doesn’t want to build a huge server farm:

“We stacked all the Atlassian software on a single server and we connected it to our database and Shibboleth environment. [We also] have a Jenkins process that automates things. Most universities use Shibboleth for the single-sign-on, mainly because of cost. It is open source and highly customized. They connected Jira Core, Confluence and Crowd to Shibboleth, which saved them a great deal of money.”

Because they also used shared mailboxes, email addresses were disseminated across all teams to facilitate the routing of support to the proper shared inbox. Since websites and prints contained specific aliases, they integrated a tool that routed the right alias to a single email after correctly identifying what the original email address was.

If you’re looking for an app that can take the stress out of creating, implementing and maintaining and a new ITSM strategy into your organization's plans for the future, Insight is for you. To find out more about how it can take your IT operations to the next level, sign up for a free trial today or talk to one of our partners about Jira integration possibilities.

Find out more about Insight 

Originally published May 16, 2019 12:00:00 PM