Thanks everyone. I agree with the concepts laid out by Carl and Brian, and those concepts are basically what I was thinking just written in a different way.
The problem I'm having has to do with how to implement these concepts in Remedy in a consistent manner. A lot of this has to do with SRM. With SRM being the point of interaction between the customer and IT, this is ideally where the SLA/SLTs should be attached. For tickets that are created through SRM, it's fairly easy for us to relate a specific Service and SLT. This allows you to measure the full time from creation of the service request, the time until approval (if there is an approval), and the time to complete from approval. Then you could also attached the OLA SLTs to the fulfillment application(s). The area I'm concerned about is when a ticket is created in the fulfillment application first and then the related service request is generated from there. There's no way to specify the related service, and service targets, that I'm aware of. So the process is not consistent. There's also the concern that the related Service on the fulfillment ticket could be different. Are they picking the business service (parent service) and the technical service (child service)? For me, it seems like we should be able to relate more than one Service to a ticket. Something like one Business service and multiple technical services. On Fri, Jun 17, 2016 at 6:26 PM Joe D'Souza <jdso...@shyle.net> wrote: > ** > > That is a very good explanation of the relationship between SLA’s and its > related child targets OLA’s and UPC’s. > > > > From an implementation perspective if you choose to use SLM, consider > OLA’s and UPC’sto be subset of SLA’s for every task that needs to be > performed to protect the main SLA. So if you will an OLA and UPC is like an > SLA to every task that needs to be performed by an internal or external > group respectively. > > > > Joe > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Carl Wilson > *Sent:* Friday, June 17, 2016 4:39 PM > > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Let's discuss best practices on SLM between the SLA and > OLA relationship for BMC Remedy > > > > Hi, > > Normally the following applies: > > > > SLA - Agreement with the Customer for a defined Target with > penalties/rewards for late/on time delivery. > > OLA - Agreement between delivery teams that are fulfilling the request > e.g. Support Groups such as L1, L2, L3, etc. [this should be a product of > the overall SLA i.e. the OLA's should not exceed the overall SLA to the > customer, but should be a breakdown of the total SLA]. > > UPC - Agreement with a third party vendor i.e. External provider. > > > > So, in your example: > > > > 1. A customer reports a Service that is delivered to them is down > "Email". The ticket is created that carries an overall "SLA" (agreement > with Customer on defined Service Targets for up time e.g. 95%). The moment > the ticket is raised, an SLA is applied and starts measuring. > > 2. A Support agent is assigned and works the request. It may transition > between internal support groups to resolve e.g. Level 1 (Support Desk), > Level 2 (SMA - Subject Matter Expert), Level 3 (Engineer, etc). The OLA's > form the basis of the SLA e.g. if a SLA has 8hr resolution time, each time > may have a defined period of time to resolve i.e. Level 1 = 4hrs, Level 2 = > 3hrs, Level 3 = 1hr (Total = 8hrs = SLA). You would therefore base the > "OLA" targets based on the Support Groups. (not the overall "Status" of the > request which would determine the SLA e.g. Start = Assigned, Stop = > Completed). Each OLA would start when the Assigned Group changes, > therefore measuring the time each group spent working the request. > > 3. If a third party vendor is required to be involved, then you may > "suspend" (pend) the SLA/OLA until the third party vendor resolves the > issue, where the SLA/OLA would stop and not continue until the vendor has > completed the work. > > > > In the above, the OLA's per team are a product of the SLA defined with the > customer i.e. you could not have a total OLA (combination of all OLA's) > that are longer than the overall SLA. The OLA's are a breakdown of the > total SLA. > > > > The "Service" should define the SLA, the interaction between resolver > teams will determine the OLA's that are defined between the resolver teams > with respect to the SLA e.g. a breakdown of the SLA into periods that each > resolver team has to perform their work with respect to the overall SLA > (not exceeding the overall SLA). > > > > ---------------------------------------------- > > > > Kind Regards, > > > > *Carl Wilson* > > > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Brian Pancia > *Sent:* 17 June 2016 19:58 > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Let's discuss best practices on SLM between the SLA and > OLA relationship for BMC Remedy > > > > ** > > Looking at a pure ITIL approach. > > > > Process Started > > > > Incident – Email not working; Email SLA/OLA attached > > > > Incident sent to next tier, where they determined it is a network issue. > At this step a Problem ticket would be opened, the Incident would be > related, and any SLA/OLA for the Problem ticket would be generated. > > > > More than likely the next step would be to issue a Change Request to fix > the network issue, which in turn may have additional SLA/OLA attached. > > > > > > Good Luck, > > > > Brian > > > > > > *From:* Action Request System discussion list(ARSList) [ > mailto:arslist@ARSLIST.ORG <arslist@ARSLIST.ORG>] *On Behalf Of *John > Johnson > *Sent:* Friday, June 17, 2016 1:30 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Let's discuss best practices on SLM between the SLA and OLA > relationship for BMC Remedy > > > > ** > > The more I work on trying to provide best practices to a customer on SLM, > the more I feel like I'm just not there in being able to fully explain the > concepts and correctly guide them on how to configure the SLAs and OLAs. > There are two parts to my issue with SLM: the first part is with the > concepts around SLM (services, SLAs, and OLAs) and the second part is with > implementing them in BMC Remedy. Please provide any comments you have on > my thinking. > > > > 1. Concepts > > 1. Services > > 1. > There are two main types of services: Internal/External Customer Facing > Services (IT services) -- let's call them Parent Services and Supporting > Services (IT Provider services)-- let's call them Child Services. The Child > Services should support the Parent Services. Many Child Services may make > up a Parent Service. > > 2. Service Level > Agreements > > 1. > These are agreements for the Parent Services > > 1. > Example: Email > > 3. Operational Level > Agreements > > 1. > These are agreements for the Child Services > > 1. > Example: Exchange, Network, Database > > 2. Configuration based on concepts above > > 1. Atrium Service > Catalog > > 1. > You would define your services > > 2. Service Level > Agreements > > 1. > You would create an SLA and relate a Parent Service > > 2. > Regarding Incident Management, you would setup the SLA and then relate > service targets to it. Typically the service target would only include the > related company and priority in the "Terms and Conditions" field, and once > related to an SLA, the service target would use the Service defined in the > SLA as part of it's terms and conditions to get attached to an incident > ticket. > > 3. Operation Level > Agreements > > 1. > You would create an OLA and relate a Child Service > > 1. > Related to Incident Management, you would setup the OLA and then relate > service targets to it. Typically the service target would only include the > related company and priority in the "Terms and Conditions" field, and once > related to an OLA, the service target would use the Service defined in the > OLA as part of it's terms and conditions to get attached to an incident > ticket. > > > > So now my question is how would this work together in BMC Remedy? For > example, a critical incident ticket is created because a user says that > their email is not working and it's assigned to the Service Desk. The > "Email" service would be related to the incident ticket using the "Service" > field, which, in turn, would relate a specific service target (e.g. Email - > Critical Priority Incident Resolution). Since "Email" is a Parent Service, > the service target is related to an SLA. The "Email - Critical Priority > Incident Resolution" service target will run from the time the ticket is > created until it is resolved. The Service Desk does initial triage and then > decides to escalate to a Tier 1 group. Tier 1 determines that there is an > issue with a network component. Ideally, this network component should be > part of a child service, which should be related to an OLA. > > > > So how should I continue? The ticket now needs an SLA and an OLA? Should a > separate related incident ticket be created with the Child Service, so that > the OLA would become attached? Is there some other way to have both the OLA > and SLA attached to the original ticket? Should I design everything > differently? > > > > Another thought was that the SLA should only be attached to Service > Requests in SRM, and then only OLAs would be attached to the fulfillment > applications. If this seems like a better solution. My only question is, > because I haven't tested it, can we relate SLAs to the generic SRDs that > Remedy uses when a Incident User creates a ticket directly in Incident > Management and the system creates the related Service Request? > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > [image: > http://t.sidekickopen54.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v5dbp0W7fsMf865jJkdW3MxVyR2zlZNzW3dyJfH1k1H6H0?si=5033628575465472&pi=89435423-35ce-4cd8-9b6f-c6f4b8d56404] > > DISCLAIMER: The information contained in this e-mail and its attachments > contain confidential information belonging to the sender, which is legally > privileged. The information is intended only for the use of the > recipient(s) named above. If you are not the intended recipient, you are > notified that any disclosure, copying, distribution or action in reliance > upon the contents of the information transmitted is strictly prohibited. If > you have received this information in error, please delete it immediately. > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: > "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
