This KPI represents a dynamic weather icon that reflects the current status of DT services. The icon adjusts and provides details based on last information received (according to refresh time) on factors such as service slowdowns or crisis, blocked apps, incidents, or user pending tickets . It transitions from sunny (indicating smooth service) to stormy (reflecting significant issues or disruptions), providing an intuitive, visual summary of system health and performance for quick monitoring and proactive action. DT-DASH Mappings:

Source: Service One and Helix

Total of ongoing requests or closed / resolved in the last 30 days

Source: Service One and Helix

Total of ongoing requests that need user action to proceed.

Service one tickets in which at least one of the related helix tickets is with the  "Status_Reason": "Client Action Required".

Calculation at Helix ticket level: 

The number of INC and WO where 

status "pending"  

AND  "Status_Reason": "Client Action Required" 

And The number of CASE tickets where 

status "pending"  

AND statusReason: "Customer Response"AND "Customer Follow Up Required"

Source: Helix

Fastlane is defined at WO, INC, and Case ticket level. 

The number of service request tickets for which the corresponding :

WO in helix is "Escalated Fastlane"= "YES",

AND

INC is "Total_Escalation_Level"= between 0 to 13 (not applicable for case tickets)

AND

CASE with  "Escalated_Custom"= 10

If the Service one ticket refers to WOs in helix, at least one  of the WO associated should be  "Escalated Fastlane"= "YES" to be counted as Fastlane.

Source: Service One

The title of the service one ticket

Anonymisation if related to HR: Condition
IF (line_of_business == human-resources)
then "*** Anonymised info ***"
else > source value.

Source: Service One and Helix

• Identify the SR Type of Each Ticket: Extract the SR type from the user list for each ticket.

• Find Corresponding MTTR in the Reference File: Match the SR type from the user list with the SR type in the reference file to retrieve the MTTR.

Image Modified https://docs.google.com/spreadsheets/d/14tu7mSb4co4CXGHL-9y-4Y-mqErW6er4ei8dX6BjOuQ/edit?pli=1&gid=0#gid=0 Connect your Google account

• Calculate “Expected resolution date”: Add the MTTR to the submit date of each ticket. Then, round the resulting date to the next day to get the “estimated resolution date”.

• Calculate the days passed since the Submit Date and compare it with Expected resolution date”. 

• Specify states including: 

  • If the status of the ticket is 'closed','cancelled','canceled','completed','rejected','resolved' => we display “completed” (grey background)

  • if the ongoing resolution date < 1.15 * estimated resolution date => “too early” (grey background)

  • if the ongoing resolution date >= 1.15 * estimated resolution date and <= 1.15 * estimated resolution date => “ontime” (green background)

  • if the ongoing resolution date > 1.15 * estimated resolution date => “overdue” (red background)

  • if not possible to compute => “not available” (grey background)

  In order to determine the estimated resolution date of a ticket (available only for workorders):

  • we compute the average resolution time of the tickets of the same service in the last 3 months

  • and add this average resolution time to the submit date.

Source: Helix

There is a WorkOrder (Crisis Ticket) managed by Siam team (part of Command Center) that is expected to update it upon any Crisis or Major Incident is identified. The table is then populated accordingly.

• When WO (crisis ticket) is resolved, the status should turn mainly “complete”, “Closed”, “Rejected”, “Closed” .→ Green in the dashboard 

• The WO (crisis ticket) with status “Cancelled” are excluded

• The WOs with Status “In progress” always should appear on top of the list→ Red in the dashboard

• When WO (crisis ticket) is still ongoing (NOT resolved yet), the status is mainly “In progress”. In case the other status such as “Pending”, “Planning”, “Assigned”, “Waiting Approval” appears, the red colorcoding rules should be applied.

Source: Kadiska and SolMan

Connectivity per Application
The avg connectivity for a specific application. it is used to assess the performance of individual applications globally.

Calculation steps:

• AVG (CT) per Site Application in the Last Hour:   Compute the average connection time for each application globally

• AVG (CT) per Site Application in the Last 3 Months: Compute the mean and standard deviation of the connection time for each application and use these as the reference for evaluating the last hour's connectivity.  

• Display the results in the dashboard using 4 states visual as below:

4 States explanation:

Fast:

• When the AVG (CT) in the last hour is less than the mean CT of the last 3 months minus 1 standard deviations.

Medium:

• When the AVG (CT) in the last hour is within 4 standard deviations below the mean CT of the last 3 months but less than the mean CT.

Slow:

• When the AVG (CT) in the last hour is greater than the mean CT but less than the mean CT plus 4 standard deviations.

Blocked:

• When the AVG (CT) in the last hour is greater than or equal to the mean CT plus 4 standard deviations, or there is no connectivity at all.

Example Calculation-> NOH

• Last 3 Months Mean (μ) CT: 37ms

• Last 3 Months Standard Deviation (σ) CT: 17ms

• Fast: AVG (CT) in the last hour< (μ - σ) → 37ms - 17ms = 20ms

• Medium: (μ - σ) <AVG (CT) in the last hour<(μ + σ) →20< AVG (CT) in the last hour<54

• Slow: (μ + σ) <AVG (CT) in the last hour<(μ + 2*σ) →54< AVG (CT) in the last hour<37+2*17=71

• Blocked: AVG (CT) in the last hour>(μ + 2*σ)

 Note: if there is no information related to the application up to 3 months, it will still be displayed, with the related last update time, due to the 3 months average calculation baseline.

Displays the user site by default, according to his HR register