Hi,
I'm trying to evaluate Jira Service Desk for our enterprise ITIL support model, looking to migrate from an older system that is heavily customised and is not capable of supporting our organisation as we transition to a fully global support model.
We are just under 1000 users in a hardware/software solution provider, approx 300 in support (multiple layers/functions), 400 in dev/test and 300 in auxiliary functions. We primarily support external customers with Incident/Problem/Change/Release ITIL processes, but would also like to use Jira to support our internal users for "normal" internal IT functions (using the same ITIL processes).
We are primarily looking at Jira Service Desk because we have Jira Software and Confluence and use these globally (albeit not using best practice in some cases).
I'm trying to get a handle on how much effort is required to take the out-of-box Jira SD and make it fit an enterprise-level process where you have L1 service desk triaging incidents, escalating to an L2 specialist team if they can't fix, and this team then escalating to development as a Problem record. In our organisation L2 teams may be the Incident Owner, however, they may request other teams at any level complete a task for them, or they may transfer the Incident Ownership (main ticket) themselves.
This is barely scratching the surface of the complexity - we're happy to hire consultants or application engineers, however, we can't do this unless we know (1) our end goal is achievable, and (2) it won't take forever (or we may as well just go spend the extra license and pay for ServiceNow or some other enterprise-ready application).
Thanks for your time and comments Christian!
I do appreciate that "it's possible". I have worked in IT for > 20 years and this is ultimately the answer in most cases, however, the critical factor is how long it would take to achieve the required customisation, and if the solution offered is workable in day-to-day usage for our use cases.
I could list all the areas of concern, however in our organisation that may be a very large list and something that normally a consultancy or internal analyst would have to go through with a fine tooth comb.
What I'm really looking for is people who understand ITIL that have experienced this implementation. To take a very simple example, if you use ITIL definitions then (literally) everything you do that changes the state of an operational environment must be recorded as a Change (like editing a config file). For Standard Changes these need to be in a selectable catalogue, and if selected from an Incident or Service Request this list should be restricted to Standard Changes valid for the Services the Customer has assigned to them. The overhead of these Changes must be minimal, as we are doing several hundred every day. Similarly, we have 10,000 incidents/month. If the interface "works" but with significant overhead it's a total non-starter.
The alternative is ServiceNow or similar, but they have massively greater license costs, so we need to understand these trade-offs.
To explain some of our concerns some of the main ones are:
1) Time to enter Incidents and progress workflows
2) Ease of use in general when passing Incidents between Service Desk, L2 teams (4 types), Engineering teams (2 types of engineering teams, running many different engineering workflows in Jira).
3) Ability to have multiple workstreams on 1 Incident or Problem, with a 1-to-many Problem-Incident relationship
4) Ease of reporting
5) Customisation of SLAs - we have 500+ customers with individual SLAs with different working times, exceptions, timezones, etc. The admin of this is unsustainable in our current system when we add new services or customers (when we add a service or customer we have to manually set SLAs on everything).
6) Configurable alerting/escalation system based on system triggers
Hi Dan,
Welcome to the Community. Yes, there is configuration and some add-ons required but you can get a fully ITIL compliant service desk. I am mentioning that we have done a number of implementations in banking and insurance industry so that you can understand, that this is feasible and yes, you can adapt Jira Service Desk to ITIL processes of Incident, Service, Change and Problem Management. With Automations as Christian mentions, you can have automatic issue creation with information transferred between tickets e.g. create a Problem from an Incident and link these issues together. Or you can use add-ons to bring similar Incidents based on criteria under a new Incident so that you can understand if you have repetitive Incidents and link them to the same Problem.
SLAs, alerts and workstreams can be covered. Also service catalogue with linked assets or a CMDB can be added. KEDB can be hosted in Confluence.
I strongly suggest you work with one Atlassian Partner with this and you will get your ITIL Service Desk at a fraction of a cost comparing to other platforms, plus you gain development world integration.