Managing Your Tickets - Calls and IPK
This area of the documentation will deal with managing incidents, problems and known errors, collectively referred to as IPK, or simply as calls.
IPK is an acronym referring to the collective of Incidents, Problems, and Known errors (IPK), although you could also lump in Service requests (without workflow) and Major Incidents in this group.
ASM is an ITIL compliant system built on the foundation of a federated CMDB. There are essentially 2 halves:
IPK (Break/Fix Tickets - but could also include simple Service Requests)
Workflow (Requests - "I want/I need something")
This is because fundamentally, when we provide services we are either performing break/fix functions or we are fulfilling requests for something. Requests tend to have many moving parts (approvals, ordering, CMDB updates). This section will cover IPK as outlined above. For more information on working with requests, please see Working with Requests.
When planning your system, these two concepts would have been carefully considered and mapped so that as you begin using your system, the configuration and language should be relatively self-evident to members of the organization.
Understanding the Different Entities in ASM
It is important to understand the different entities in ASM so that as you begin learning to use the application, you can be clear on what area you need to navigate into to complete your work. Some of the language used in ASM may be different from what you are used to if you have used other systems. This section will help you get clear on what is being referred to as you move through the documentation and the application.
Call/Ticket
A call, also known as a ticket is any break/fix issue that an agent will need to resolve. These can have additional call activities added (these function as separate tickets however are maintained on the initiating ticket) that may be assigned to other agents. IPK tickets can also have quick solutions, quick forms, and troubleshooting scripts added to them.
It is likely that this will be the first capability setup in your implementation.
Service Request
A ticket requiring an agent to perform an action/provide a service. It is not break/fix. These can have additional call activities added (these function as separate tickets however are maintained on the initiating ticket) that may be assigned to other agents. These can also have quick solutions, quick forms, and scripts added to them.
Request
A ticket in the system such as a Change Request, Release Process, or New Employee Onboarding. These tickets will have workflow and automation that sits behind them.
In ASM, the request capability exists on both the break fix (IPK) side of the application and on the workflow side of the application. This is a potential point of confusion:
For example: Change Requests would be configured in the Workflow capability so that all the tasks required for a change can be preconfigured, whereas simple service requests can be set us as plain tickets (IPK) to be actioned and completed by an agent.
This is because Requests and Service Requests may or may not have workflow that sits behind them. Collectively, Service Requests that do not need workflow are configured and managed on the IPK side of the application even though it may not be a true "Break/Fix" problem.
You do not need to manage non-workflow dependent service requests as an IPK-type ticket, however the system is OOB (out of the box) configured as such for the sake of making implementation easier, particularly for those desiring to self-implement.
Your Professional Services Consultant will conduct a workshop during the initial implementation to determine the best way for you to implement Request Fulfillment and Workflow capabilities.
CMDB Item
It is important to understand some of the basic concepts and language we use when discussing configuration items and the CMDB. At it's heart, ASM is a system structured around a federated CMDB. Essentially, it is the foundation of the application. You will likely need to put at least one CMDB item on every ticket you log.
The CMDB contains:
People
Locations
Organisations
Configuration items
Assets
Services
Service Actions (think Request Fulfillment here)
Contracts
and more....
Everything listed above is collectively referred to as a CMDB Item. Think of it as the top-most parent classification of any item in the database that belongs to the Federated CMDB.
When we talk about CI (Configuration Items), we mean individual configuration items. Many times, assets are lumped into it too. Think of this as the second level sitting right under the CMDB Item. Typically, a CI is anything tangible. **You can create any kind of CI though. There really are no rules here and there are no limits, so you can even create CI out of intangible things such as error codes or versions of a system, for example.
Example: A client had a need to tag all incidents with a specific ISO9000 code that identified the vendor they were working with. This was a regulatory reporting requirement so the information had to be captured. There were nearly 200.
It did not make sense to make that a drop-down, so we placed them in the CMDB instead and created a special CI Type called ISO_CODE. Then, using screen designer, we created a new CI Lookup field, placed a filter on it to only show the CI Type of ISO_CODE, and put it on the incident screen. We then made the field mandatory, but only for resolving or closing the ticket to ensure that before it is wrapped up, the necessary code was applied.
This made managing the codes easier (import capability) as the list was subject to change, and enhanced reporting capabilities substantially.
The CMDB is structured by CMDB Item Types. It is a master, tiered list of all of the kinds fo CI you can have in your CMDB. For more information, see Managing your CMDB.
The structure of your CMDB will have been carefuly considered and configured during your initial implementation. Before making changes, if you have sufficient rights to do so, consider reviewing the initial documentation around the configuration of ASM and perhaps consult with Alemba Professional Services or your Account Manager. Changes to the CI Item Types could have unforeseen implications.
Classifying Tickets - IPK Status
Picking the correct kind of ticket to log in ASM is easy. Classifying the ticket happens as soon as the agent selects what kind of ticket they want to log. In this way - they need not be concerned with ITIL or memorizing complex processes. ASM is already configured behind the scenes.
Each organization can define its ticket types. In the example below, 2 additional ticket types with custom screens were added, Events, and PPM (Project and Program Management).
If a ticket is logged incorrectly, it can be easily changed to the correct type. For example, an incident is logged when it should have been a service request. To change the IPK Status (to what the ticket should be), click the Change IPK Status quick Link:
Select the correct status from the list, and the ticket is converted with no loss of data and no rework required:
