ITSM Service Desk System Audit for Enterprise Client or how to save 100K of the yearly budget?

Atlassian team

The case is about Rozdoum – Atlassian Gold Solution partner, whose proposal for setting up support and help desk systems will later save the client more than $100K yearly.

Background 

The help desk was based on Atlassian Jira Service Management (former Jira Service Desk) platform with close dependency of other Atlassian products, such as Confluence and Jira Service Desk, and required close collaboration of IT and Development teams. 

This is a vivid example of how the right ITSM solution can help the enterprise re-allocate their budget.

What Rozdoum consultants prepared for the client:

• • A general recommended approach for setting up Jira Service Desk in combination with Jira Software and Confluence;
  • A detailed implementation plan with clear step-by-step process of eliminating uncertainty and unknowns; 
  • Projected milestones and deliverables with ideal delivery terms within 23 working days;
  • Projected budgets for implementation as well as Support and maintenance costs. 

Requirement analysis & Scoping

Setup of Information Technology Service Management system that addresses Internal facing Service Desk  and Customer facing Global Operations Center.

Projected Environment:

1. 40 Support agents;
2. 5000 IT assets (software, desktops, laptops etc.);
3. 10000 incidents and requests annually + 500 change requests.

Jira Service Management description

• In brief – Jira Service Management can allow the client to: 

  • address different customer segments (internal, external, etc.) with different Portals, where each 
  • may have different Request Types, with dedicated 
  • easily configurable SLA times, and specific parameters, screens and permissions
  • Adjustable and prioritized Queues  
  • Streamline self-resolution for customer by Knowledge Based articles based on Confluence
  • In coordination with Development team in Jira Software 
  • Automate routine operations on backend and front-facing processes
  • Maintain and operate Assets with CMDB solution.
  
  
  
  

For Customer, it will provide:

• A search-centric approach for addressing problems;
• A targeted set of possible request types to raise;
• Knowledge base articles addressing the search criteria.

For Agent as a part of Support team, it will allow:

• A prioritized queue of items to address;
• Easy access to KB articles;
• Collaboration with the development team inside Jira Software; 
• Clear prioritization and addressing SLAs;
• Access to Asset/CMDB.

Implementation plan

a. Architecture outline

The suggested landscape of the system implies tight integration of available Atlassian products: Jira Service Management (Desk), Confluence and Jira Software. Potentially and in the future, we might consider adding StatusPage as a communication channel with customers during incident resolution time.

The core customer-facing part of the system becomes the Company Help Center that will be split into portals. At the moment envisioned  two types of portals:

• Internal Service Desk (ISD)
• Customer Operations Center (COS)

Each portal will have: 

• A dedicated address that can be presented and given to end customers; 
• A predefined set of request types available to be raised;
• A link to a certain area within the Knowledge Base system.

On the backend of each portal, we will create a dedicated Support project with certain issue types that can be used to address different Request Types. 

Each request type will have a certain, configurable number of relevant fields. Types of fields as well as possible sets of values are to be defined during the assessment phase. Request Types might have associated screens for following operations: create, view, edit. Screens can be shared by several request types or be specific for a certain request type. 

Each request type will be associated with a set of business-driven SLA restrictions.

Issues raised by a customer will be organized in queues to be easily addressed by the support team. 

Issues raised by creating a request type during the lifecycle will have to undergo a set of transitions. This set of transitions as well as associated statuses is referred to as a workflow. A workflow can be shared between several issues or be a specific one. A workflow might have restrictions for transitions, by that ensuring certain criteria are met before or after the transition. Triggering a transition from one status of a workflow to another might raise a set of actions, which is referred to as automation. Automations should address the nature of the business process and can affect different systems in the outlined landscape – Jira Service Management (Service Desk), Confluence, Jira Software. Automations should be defined during the assessment phase for each request. 

b. Phases definition

i. Initial assessment 

Planned activities:

1. Identifying all possible request types for ISD portal.
2. Identifying all possible request types for COC portal.
3. Identifying user groups and corresponding access to information as a basis for permission schemes: 

1. • Who needs to see reports;
   • Who needs to work as an agent;
   • What the customer should see;
   • Who defines workflows and processes.
2. Defining stakeholders on different sides:
   
   • Customer. Who represent customer; 
   • Agents for Internal Service Desk and COC;
   • Management;
   • UAT group.
     
3. Defining metrics and KPI for reports.
4. General configuration questions:
   • Defining necessary queues; 
   • Defining possible issue priorities;
   • Selecting IssueTypes and mapping to RequestTypes;
   • Access and structure of KB;
   • Possible ways of raising requests.

Deliverable : report listing above mentioned items

Tune your Atlassian tools to collaborate effectively. Get advice from Atlassian certified experts and simplify your internal Jira workflow. Arrange a call for the initial Atlassian tools assessment stage.

ii. Processes description

For each request type identified in the phase “Initial assessment”, we need to define:

• A list of relevant fields (their types and possible values);
• Process workflows with all statuses, transitions between statuses. For each transition, we need to set:
  • Triggers – if transition should be executed based on some event happening in the system; 
  • Conditions – definition of who has the permission to execute a given transition;
  • Validators – restriction that must be in place in order for a transition to become possible;
  • Actions that need to happen after a transition takes place. Possible automations.

• Automations
  • What actions needs to be automated, if any?
• Stakeholders
  • Customers: 
    • What is a customer allowed to do?
    • What information can he see?
    • Which transitions should he be able to initiate?
  • Agent
    • Who fit into the agent role for this request?
    • What restrictions ( if any) exist?
    • What are the SLAs for a given type of request?
      • What should happen if a certain SLA is breached?
  • Management
    • Who fits into this role?
    • What permissions should be given?
    • What type of reports are they interested in?
• KB articles
  • Defining relevant spaces and articles
  • Defining relevant keywords

Deliverable: Process description for each Request type

iii. Implementation & Configuration

1. 1. Setup of Portals
   2. Project configuration
   3. Mapping Request Types to Issues
   4. Defining workflows
   5. Request types & Screen configurations
   6. Setup of Queues 
   7. Permission scheme configuration
   8. Setup of SLAs and mapping to request types
   9. Reports 

Deliverable: Configured JSD instance

iv. Asset configuration – preliminary investigation and setup

v. UAT

1. Documentation & Trainings

   a. Customer documentation 
       i.Basic documentation. Jira Service Management how-to
       ii. Request type specific
   b. TechSupport team
       i. Basic documentation. Jira Service Management how-to
   c. Help Desk team
   d. System administrator documentation

vi. Launch

The launch phase doesn’t need to be “all at once”. It may start with a one-step-at-a-time approach. In this way a pilot group of users may start testing the JSM system once a certain request type is configured. This way we can address requests for certain changes early in the process and make appropriate adjustments. 

vii. Maintenance & Post-launch support

Maintenance and support is highly recommended. Experience shows that the best way of organizing a process is preallocating a certain amount of hours monthly. For a challenge of the given complexity with 50 agents, the following amount of support hours is recommended: 

c. Estimate and Timeline

There were a number of assumptions made that directly affected the estimation process.

Assumptions: 

Estimation is provided based on a phase, assuming there is minimum and maximum estimated effort for each type of activity. If an activity includes a sequence of the same operations, such as fields for Request type, min and max effort for an operation is multiplied by the number of operations.

Detailed estimation is presented in Annex 1.

The range estimate for implementation is from 29 to 58 days.

Timeline: is based on simultaneous phase implementation in case it is reasonable.

All in all, a project can be completed within a range of 23 to 38 working days.

Improve your Environment with Atlassian Experts.
We help you optimize your infrastructure and adjust processes with Jira and the Atlassian tools.

Fill in your parameters and get a detailed calculation: