Prefix this by "it depends on your organization's priorities, but..."
> Let's say that our OTRS system has a service called OTRS with a criticality of > 4 high because, if it fails, no agent can work. > Let's say there is a problem in OTRS: the company logo is mirrored and > unreadable. It's a problem that affects both customers and agents, all of > them, so its impact is 5 very high. So now I have a very high priority ticket > that is nothing more than a GUI nuisance. No, you have a low impact/low criticality issue that is misclassified. It may be highly visible, but it is not impacting the availability or functionality of the service, thus it does not rate "critical". > I know I can manually change the ticket 's priority, but what I would be > really > doing is saying "Although the impact is really 4, the criticality should be 1, > not 4." That's why you have priority. It should be fixed ASAP (and thus be high up on the list of low impact issues to fix), but it is not impacting usage/availability of the service, and thus, not critical by definition. > Now, my question: do you think that there should be a way to adjust the > criticality of the service for the current ticket? In general, the value of the Severity/Criticality value matrix is that *everyone* has a common set of definitions of what is critically impacting services and how to respond to certain levels of criticality. If agents can edit criticality, then you lose that common definition and your response (and SLA compliance) to the issue can be confused, and thus recovery is delayed because everyone no longer shares the definition of "critical". If there are non-trivial resources involved in the response to a critical event, that can be VERY expensive. Sev 1 or sev 2 fire drills where they aren't really necessary tends to lead to the "cry wolf" syndrome. So, no, I don't think it's a good idea. I'd argue that instead, you need to turn the OTRS service into a composite service made up of presentation, function, and throughput. The logo issue is really relevant only to the OTRS presentation service component; function and throughput are not affected, and the function and throughput of the OTRS system ARE critical services that should require high-severity response. The presentation service component is lower priority, and should be defined as such. Your business dashboard can reflect the overall OTRS service for SLA reporting. Focus your agents on whether the service delivery is impacted, and you'll be able to use the current setup effectively without change. --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
