Keith Posted February 7, 2017 Posted February 7, 2017 We have a problem with SLA due to the way in which Work Time Calendars have been implemented. If I understand correctly a work time calendar is assigned at the service level. This seems to make it impossible to share services across multiple timezones if you want to manage SLA's. It woudl seem more appropraite for work time calendars to be assignable to SLA's which would allow the assignment of specific SLA's based on rules. I would appreciate any comments on how we can achieve this or guidance on best practice for managing SLA's across these different timezones? Regards Keith
David Hall Posted February 7, 2017 Posted February 7, 2017 Hi Keith, Thanks for the post. The scenario you have raised is something that has been previously mentioned following our initial release of SLM. A change request (CH00142587) has already been raised with the objective of allowing a Service to support multiple Working Time Calendars and Timezones in order to remove the need to have a different Service Level Agreement for each supported time zone. Regards, Dave.
James Ainsworth Posted February 8, 2017 Posted February 8, 2017 Hi @Keith As David has mentioned there is some planned work in our backlog to provide more flexibility with the Working Time Calendars. I hope you don't mind me asking but to help with our requirements I would be interested to understand which of the following best fits the structure of one of your shared services where you are wanting this to be configured Support Teams within one time zone and they are supporting customers spread over multiple time zones Support Teams in multiple time zones and they are supporting all customers in all time zones Support Teams in multiple time zones and each team is supporting customers in their own time zone At the moment the Working Time Calendars are reflecting the time that the support teams are available to provide the support. In the first case where the support team is in a single time zone the single working time calendar can be used with the time zone matching that of where the support team is located. The second option resembles a "follow the sun" type support where there is support from multiple time zones and here the Working Time Calendar needs to reflect the total coverage by all teams and the Time Zone can be used as a reference in case there are any gaps through the 24 hours to ensure that the Service Level Targets are timed from the moment the first team comes on line to when the last team signs off. The third option is possibly where there is a need for a different way to manage the time zones of the support staff. This is where a link between the time zone of the support team and the time zone of the customer need to be matched up to ensure that the service level targets are timed correctly. Regards, James
Keith Posted February 9, 2017 Author Posted February 9, 2017 Thanks @David Hall & @James Ainsworth James, We actually cover all three of the scenarios covered in your bullet points. Our implementation of Hornbill is used across the whole of our organisation globally for all IT & Applications functions and means that there are numerous organisational and team structures. With regards services, we have tried to create as few as possible. As an example: We have a Service called IT Service & Support which is supported by numerous IT departments. Some of these teams support only customers in their own timezone whereas other teams support customers in multiple timezones. Another example is our our SAP support teams which are spread across 4 geographical locations globally and support customers in ALL timezones. For this team in particular we would like to have a follow the sun approach. I'd be happy to talk this through with you in more detail if it would help. This has actually become a major issue for us very quickly and we desperately need a solution. I am sure you will not be able to commit to timescale but is there any indication you can give i.e. 30 days, 90 days etc. Failing this new development are you able to give any advise regarding managing multiple Timezones with current functionality. Is the only way to have multiple services? This would mean us having multiple IT Service & Support services. Any advise and information greatly appreciated. Thanks Keith
Keith Posted February 28, 2017 Author Posted February 28, 2017 Hi @James Ainsworth, any update on this much needed development? We are currently at an extremely low OTD rate due to time differences. I realise you are unable to give exact dates but I really need an indication of where you guys are with this development. Thanks Keith
James Ainsworth Posted February 28, 2017 Posted February 28, 2017 Hi Keith, Thanks for your earlier feedback and apologies for not getting back to you sooner. The work for this has not been scheduled yet. I will take it up with our CAB to see if what we can do about getting this planned and prioritised. Regards, James
Keith Posted February 28, 2017 Author Posted February 28, 2017 Hi @James Ainsworth, would appreciate some feedback when you have done that. I'm facing considerable pressure here as to why global SLA's aren't achievable. If I can be of any help on this let me know. I'd be willing to beta test this as it can only be an improvement on SLA's for us.
Guest Posted February 28, 2017 Posted February 28, 2017 Hi @Keith, I have had a read through this thread, and unless I have misunderstood, I believe that what you are looking to do can be achieved using the current Hornbill functionality. In your very first post you mention that the Working Time Calendar is against the Service Level and not the SLA. Its actually the other way around - you associate a calendar to an SLA. This means that all of the Service Levels within that SLA will run against that calendar. Now on to your scenario. I’m going to make an assumption here - please correct me if I’m wrong - and that is that the site of the customer logging the request is what should drive the selection of the Working Time Calendar that is used. The site of the customer is automatically stored against every request (unless the site has been explicitly selected during progressive capture or after the request has been logged - in which case, this method still works). For example, a customer has a site of Madrid, they log an Incident, the Incident is effectively logged against the site of Madrid and should therefore use the Spanish working time calendar. If the above is valid, this is how you can configure this: Step 1: Create all of your Working Time Calendars with the relevant working hours and holidays. In my Example, I have 2 calendars to use - a UK and USA Calendar Step 2: Create a Corporate Service Level Agreement (SLA) for every Working Time Calendar that you have. In my Example, I’ve created 2 SLAs - one for the UK and one for the USA. When creating these, ensure to select the relevant Working Time Calendar Step 3: For each of these Corporate SLAs, create the Service Levels, Targets and Rules (as you have already performed on your system). Unless you actually have different targets for different countries, these are likely to be the same against every one of your Corporate SLAs. In my Example, I have two Service Levels - one for Critical Priorities and one for Low Priorities. I have set these up with the relevant response and resolution targets and set up the Service Level rules to decide which one is selected, based on the priority of the Incident. I have repeated these actions against both of my newly created SLAs Step 4: Link both of the Corporate SLAs to a Service In my Example, I have created a Service called “IT Service & Support” and linked both my UK and USA SLAs to this Step 5: Create the SLA Rules When you add more than one SLA to a Service, you will receive a “Manage Rules” tab. This is where you define the rules to decide which SLA will be associated to a request of that Service. In my Example, my rules are based on the site of the request (i.e. the site of the customer). If the Site is London or Leeds, the UK SLA, with the UK Working Time Calendar will be selected, and then the relevant Service Level will be selected based on the Priority. If the site is New York or Washington, the USA SLA, with the USA Working Time Calendar will be selected and then the relevant Service Level will be selected based on the Priority. Inside one of the rules: The key thing to assess beforehand is which Sites should result in which Working Time Calendar. If you only have a few Services, this shouldn’t require too much configuration. I hope this makes sense - I have made a few assumptions of your current set up here, but please let me know if these are incorrect and I’ll try and see if there is another way this could be configured for you. Kind Regards Bob Dickinson
Keith Posted March 1, 2017 Author Posted March 1, 2017 Hi @Bob Dickinson, Thanks so much for your detailed thorough explanation. This does actually look very promising and may well work for us. We'll have a look and try it and get back to you. The only thing it wouldn't help with is where we want to implement more of a "follow the sun" approach, but this would certainly get us much closer than we are today. Regards Keith
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now