OLA per team

🤦 🤦 🤦 Combodo's customers only 😎 😎 😎

This extension adds the capability to compute the time spent by delivery teams on a ticket and therefore to ensure that tickets are not “forgotten” by a team. As stopwatch have been added, you can also generate triggers on OLA threshold.

The extension creates stopwatch to calculate OLA_TTO and OLA_TTR.

OLA_TTO calculates Time to Own ticket by an agent in a team (so you will find one OLA_TTO per team the ticket goes through). OLA_TTR calculates time ticket spent in a team.

Thanks to threshold you can set on stopwatch, you can configure some triggers on OLA_TTO or OLA_TTR.

Standard behaviour is that OLA_TTR is reset when a ticket is redispatched to a team. Limitation is that OLA_TTR is reset even if it is redispatched to the same team.

The extension requires iTop 2.7.0, at least, and the following modules:

• iTop request management or iTop request management itil ,
• combodo-sla-computation 2.0.0,
• itop-profiles-itil,

Use the Standard installation process for this extension.

This extension has no specific configuration setting.

OLA calculations are done thanks to links between OLA-SLT-Teams-Coverage

You will be able to configure OLAs directly from Left Menu under Service Management Section:

Link OLA-SLT

You can create new OLA under which you will attach specific SLT (Service Level Target). These ones will permit calculation of thresholds.

Idea is exactly the same than SLT attached to SLA to calculate TTO and TTR. We recommend you to differentiate, in SLT, the name of the ones you will attach to SLAs and the ones you will attach to OLAs as all of them will appear in same list under the SLT section.

You can find below example of SLT applied to OLA Helpdesk:

Link Team-OLA-Coverage

For every team, you will need to indicate which OLA will apply with which coverage. If you don't indicate coverage window, the computation of OLA deadlines will be done using a 24h*7 coverage window.

You will need to go on Team window to indicate OLA and coverage you will assign to each team.

Result

As soon as ticket leaves a team to another one, OLA_TTR will be updated and documented in additional sheet that is created in UserRequest or Incident ticket.

Stopwatch ola_ttr is reset as soon as ticket goes to status dispatch or re-dispatch.

Stopwatch ola_tto is reset as soon as ticket is assigned from dispatch or re-dispatch status.

In this sheet , we can see time spent in each team and if OLA_TTO and OLA_TTR has been respected.

A trigger on threshold can be defined to generate an event when a reminder expires. Parameters to be used are :

• Target class : UserRequest (or Incident)
• Stop watch : ola_ttr (or ola_tto)
• Threshold : 100

You can, then, associate email notification to this trigger.

Question: Can I have access to the time spent by a team, even if no OLA is defined for it?
Answer: Yes, you can. The time spent by team is measured and undefined OLA is considered as reached.

Question: Can I change the way to find applicable SLTs, holidays and coverage windows?
Answer: Yes, you can. There is three constants which defined the OQLs to retrieve those SLTs, Holidays and Coverage Windows. They can be overwritten in the ITSM Designer.

itop_design | constants

    <constant id="OLA_SLT_QUERY" xsi:type="string">
       <![CDATA[SELECT SLT AS slt JOIN lnkOLAToSLT AS l1 ON l1.slt_id=slt.id JOIN OLA AS ola ON l1.ola_id=ola.id JOIN Team AS t ON t.ola_id=ola.id  
                WHERE slt.metric = :metric AND t.id = :this->team_id AND slt.request_type = :request_type AND slt.priority = :this->priority]]>
    </constant>
    <constant id="OLA_COVERAGE_QUERY" xsi:type="string">
       <![CDATA[SELECT CoverageWindow AS cw JOIN Team AS t ON t.coveragewindow_id=cw.id WHERE t.id=:this->team_id]]></constant>
    <constant id="OLA_HOLIDAYS_QUERY" xsi:type="string">
       <![CDATA[SELECT Holiday]]>
    </constant>

Question: Can I adapt the extension to my customized User Request lifecycle?
Answer: Maybe.

There are 2 methods provided by the extension:

• UpdateOLATTOAssign which must be called as a lifecycle action, each time the User Request is leaving a state where the TTO was running
• UpdateTeamTimeSpent which must be called as a lifecycle action, each time the User Request is leaving a state where the TTR was running
  and each time the User Request team is changed.