One or more impacted services should be indicated when the affected Configuration Item is selected. I have seen serious ticketing applications which incorporate a service into categorization. These are good technical schemas and good meaningful categorization can be fit into them, even for less-then-technical business customers. Some industry flagship tools enforce fixed layers like: Category:Subcategory:ProductType:ProblemType, or Category:Type:Item. This way, database integrity is intact and it doesn’t influence reporting. So when a new technology ticket is raised it takes the category “Misc.” A good idea is to open a category “Old” and to put all the obsolete technology there. I know some clients with five and six category layers where more than three layers are seldom used, but the tree is not maintained. The depth of the category tree should be revised periodically and changed according to organization needs. This should be enough for creating a useful category tree, though.ĭepending on the scope of the organization’s service management, here are a few examples of category trees: They are multi-level in three to four layers. ![]() Some tools I have seen living in upper Gartner quadrants are more rigid with regard to customization. Mostly, one has to rely on his ticketing tool abilities and customize them to his business requirements. ITIL is not very specific in incident categorization. Why do we categorize? The main reasons are input for the Problem Management process and empowering decisions in Supplier Management. This way, the agreed Service Level is more easily monitored and reporting problems are avoided. Good practice here would be to resolve the ticket immediately after restoration, and to open a related Problem ticket. An example would be lowering incident priority from 1 to 4 after the service restoration, in order to monitor the infrastructure and perform root cause analysis. This is especially true with lowering priority. If there are available resources, good practice is to accept their request and deal with the ticket with requested priority, and mention the issue during the next SLA periodic meeting.Ĭhanging priority during the incident lifecycle should be avoided, since most ITSM tools have problems recalculating escalation times and SLA parameters.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |