Clarity Service Management

Expand all | Collapse all

Service Type

Jump to Best Answer
  • 1.  Service Type

    Posted 27 days ago
    ​Hello, I have a service desk requirement which I am trying to understand if configurable in the Service Desk or not:

    When changing an Incident service type e.g. due to a change in Incident priority, area or contact, the new service type SLA events do not take into account any time spent accumulating time when with the previous service type, i.e. the elapsed time (time not spent suspended or resolved).

    We need the total for this accumulated time (elapsed time) to be subtracted from the new event fire times for the new allocated service type.

    Is the Service Desk be configurable in this manner?


  • 2.  RE: Service Type
    Best Answer

    Posted 26 days ago
    Hi Paul

    Look at the option 'set_sla_evt_open_date' in Service Desk located per below, this set the 'open date' as the start of an SLA, any change in Service Type should use the 'Open Date' of the ticket 

    Service Desk --> Administration Tab --> Options Manager --> Request-Change --> set_sla_evt_open_date

    Hope this helps
    Jacques


  • 3.  RE: Service Type

    Posted 25 days ago
    Hello

    As described, the "set_sla_evt_open_date' takes the open date instead of the current date into account,
    when calculating the fire-time of the new Service Type events.

    This might be a bit too short sighted. I see two questions to discuss here:

    1.)
    Using the open date of the ticket as the start date for the fire-time calculation, depends on the contract and service agreement with your end users.
    It doesn't need to be necessarily the open date !
    For example:
    part of your incident process is a triage phase, where the ticket gets evaluated. It gets filled up with necessary information, and assigned to the appropriate group.
    Part of the triage phase is setting the appropriate Service Type for this ticket.
    The triage phase must not be necessarily part of your SLA.
    Having this kind of process and SLA definition, not the open date , but the date at the end of the triage phase should be the starting point of fire time calculation.

    2.)
    Even though if Paul would say, okay , I use the open date as my starting time, as I don't have any other capability to use,
    He might ask, whats about all the "on-hold" times in previous phases of the ticket.
    They should be taken into account for the new Service Type fire-time calculation.

    I see two missing capabilities here
    - being able to specify the start time for fire-time calculation of Service Type events, other than now or open_date.
    - taking the past "on-hold" times into account in fire-time calculation.

    That said, I have no idea how to configure this approach in SDM in its current version.
    Sure, I can think of customization of course, but ... well...

    Wondering if others see a lack of functionality here as well. Might be worth an idea?

    Best Regards
    .................Michael


    ------------------------------
    Principal Services Consultant
    HCL Enterprise Studio
    ------------------------------



  • 4.  RE: Service Type

     
    Posted 25 days ago
    Hello Michael,

    Being able to nominate a different "start time" that a variable like "set_sla_evt_open_date" would run off might be worth an idea. 
    I don't know if it helps though . . . because it might help with that first change of SLA Type - but what about the next one? When does that run from? You'll still hit similar problems with Events having "wrong fire times."  

    I think this is like where CA Process Automation started to be used a lot more as "the solution" to complex workflow issues. The Devs. realised that they would never be able to build in everyone's preferred complex flow mechanisms, so it was split out into a separate tool that could be used across products. Then people found it could be used for more than just Workflow and started combining (a) SDM field level customisations (b) CA PAM workflows and (c) reporting in order to pull out data and still keep the ticket activity moving. Now there are some blistering CA PAM flows that do a whole lot more than the original CA SDM Classic Workflow could ever hope of doing.

    So if anything, I'd see more flexibility around Event definitions being built (Different start date? Cumulative time totals?) With possibly building a whole new Event handler. (Leaving the "classic" Events as is.)   . . . Just as an idea!


    Getting back to Paul's issue, I feel like I'm missing the "what and why" of the problem he's trying to solve.

    Why did the SLA change in the first place? Why should the time spent in a previous SLA be "thrown out" from the current SLA Events? Is this primarily a reporting or issue handling concern? Some business background would be good.

    I think we need a simple example.

    Then to see if we can adapt the business process/reporting/existing functionality enough to still meet the end goal, even if the technical direction is different.

    And yes, there will be limitations.

    Kyle_R.


  • 5.  RE: Service Type

    Posted 20 days ago
    Hello Kyle.
    Thanks for your thoughts.
    I personally don't like the idea, that each time the application logic does not fulfill certain expectations, someone is bringing the knockout argument "Process Automation" on the table.
    I know a lot of customers, which don't have PA in place, and don't want to, for several reasons (different topic).
    Beside that, in this situation, even PA will not help at all, I assume.
    As far as I am aware : the event handling related to  service types is hidden to the outside and not exposed thru the SDM web-services.

    Additionally, I also think of consistency:
    Why are hold times reflected in time calculations for targets, while they are not in service type calculations?

    But I totally agree to your approach of a simple example:

    Example ( As simple as possible ;)  ) - ( @Paul Edwards Please let us know your point of view) :

    1. Monitoring / Tracking of the overall solving process of an incident during its solution phase.
    2. Incident process consist of several phases: opening, triage, solving, closing.
    3. only the solving phase should be monitored.
    4. On-hold times during the solving phase should be reflected.
    5. SLA (Service Type) changes might occur in any process phase ,for example because of a priority change (escalation) or a re-categorization (triage failure).

    Some thoughts related to the items above:
    1. This is a typical SLA approach, in contrast to OLA's
    2. Its a typical overall incident process.
    3. to be able to monitor the solving phase only, we need to know the start time of the solving phase.
      1. This completely depends on the customers requirements and process definition.
      2. lets say we have a specific date attribute , where this start-time gets stored, for example, when a Service Type gets assigned to the ticket for the first time( end of triage phase).
      3. SDM would need to be able to take this start-time into account when calculating Service Type fire-times.
      4. The end of the solving phase could be checked by the resolve date.
    4. as long as the Service Type does not change, SDM works just fine. Based on certain status changes and/or manually done, the attached events gets delayed and continued.
    5. those things are just happening
      If the Service Type changes , all past hold times during the monitored phase, should be reflected in the new fire time calculation 
      1. For example: The ticket was on hold for 10 hours of 15 hours expected solution time
      2. Now it gets escalated, so that the expected/tracked solution time is only 8 hours
      3. Not reflecting the hold time of 10 hours would breach the SLA all of a sudden, even though the ticket was 10 hours on hold.

    Conclusion:
    From my point of view , there are two things missing here to make SDM much more flexible in handling SLA's .
    1. Taking a different start-time point into account , other than now or open_date, when calculating fire-times.
      1. happily provided on Service Type level, rather than on system/option level.
    2. taking past hold - times into account, when calculating fire-times.
      1. Maybe configurable on Service Type level as well.
      2. As said, it seems, that this is already done in target fire-time calculation. So why only there?

    ​​I am always a friend of trying to find generic approaches, which will enhance the system capabilities not only for one specific business requirement, but which broaden up the functionality that way, that it fits to a set of possible requirements.
    That said, I did not start to think about OLA's/underpinning contracts , which do have a slightly different approach.

    Best regards
    .............Michael


    ------------------------------
    Principal Services Consultant
    HCL Enterprise Studio
    ------------------------------



  • 6.  RE: Service Type

    Posted 19 days ago
    ​Thank you all for your input. I agree a PA solution is not the way ahead as a solution will need to intercept event records which I understand are not exposed to PA.
    Also adopting the "set_sla_evt_open_date" option will not help because when allocating a new service type (with events) they will still not take into account any accumulated time with the previous service type
    I have attached a document with some examples which explain this further


  • 7.  RE: Service Type

     
    Posted 18 days ago
    I don't see an attached document?

    Kyle_R.


  • 8.  RE: Service Type

    Posted 18 days ago
      |   view attached
    Hello, examples attached