Planning Your Incident Management Implementation

Audience: Incident Manager, Service Desk Manager, Service Delivery Manager, Alemba Service Manager Administrator(s)

Time to Complete: Varies, Average 3-5 days (Including screens build and UAT)

This topic covers configuring ASM for Incident Management. For help performing actions related to Incident management, please see:

Overview of ASMs Incident Management Capability (Video)

Using ASM Core | ASM Hermes

Managing Your Tickets - Calls and IPK | ASM Hermes

Planning Checklist

(You can print this page if you would like a hard copy)

To prepare for Incident Management, or for your Incident Management workshop if you are receiving assistance from Alemba's Professional Services team, consider the following before you begin configuring ASM. This step may require several meetings with relevant stakeholders. You should not attempt to implement Incident Management until you have completed this checklist.

As you will see, there is a lot to think about not the least of which is Security and Access considerations for your analysts, users, and the ASM system itself. Depending on your decisions below you may very well need to also secure system and service accounts, certificates, and other access permissions that will allow the Alemba API to integrate to other applications to receive and distribute data such as user accounts, configuration items, event alerts, and email messages.

Write down what you hope to achieve by implementing Incident management for your: Users, Support Staff, and for the Organization(s).

• Specific – The goal should be clear and well-defined.

• Measurable – You should be able to track your progress and know when it’s achieved.

• Achievable – It should be realistic and attainable, not impossible.

• Relevant – The goal should matter to you and align with broader objectives.

• Time-bound – There should be a clear deadline or timeframe.

Reporting

• What Information is needed for Call Logging - Minimum required data is: User, Affected Configuration Item(s), Affected Service, and Type/Tier:

  • For Reporting

  • For KPI

  • For Troubleshooting

  • For Assignment

  • For Resolution

  • For Knowledge Capture

  • For Escalations and Chases

Integrations

• Are your Users already in ASM? Will you need to connect to a directory service?
• How will tickets be logged? Email, Chat, Phone Call, Self Service (how will users log in?)
• How will you get Configuration Items into ASM?

  • Option 1: No Integration or CI Imports. You will create generic CI such as Laptop, Mobile Device, or MS Outlook

  • Option 2: Import or link to another repository (or multiple repositories) such as Intune

  • Option 3: Bring in raw data from a .CSV

  • Option 4: A mixture of 1 or more options

  While ASM has a very comprehensive Software, Asset, and Configuration Management capability that is fully integrated throughout the application, you really only need to bring over CI if it makes sense for YOU. It is possible to use Generic CI, and still pull meaningful metrics.

  e.g., All Incidents for O365, all incidents for Printers, all Incidents for Mobile Devices, etc...

  Note: You will need to bring in CI if you plan to do Asset Management or other Inventory Management activities but, strictly speaking, you do not necessarily need to manage individual CI in ASM simply to do Incident Management if this is not part of your journey thus far, or if your Asset Management Software is working well for you and the data is not needed for your KPI or other reporting and troubleshooting.

Metrics and Data

• What Services do you provide? Most organizations do not have more than 5-10 Services they provide their end-users. Example:

  Email and Messaging is a service

  MS Outlook is a configuration item (it is software)

• How do you categorize your tickets? Will this change or is it working?

  • The Categorization describes an action, condition or experience e.g. 'performance degradation', 'monitor flicker’, ‘Access Errors’, or ‘functionality change’.

  • This is your Type, Type/Tier in ASM, or more commonly referred to in plain language as the category.

  • Type should describe generally what the issue is – action!

• What are your Service Level Agreements (SLAs) for acknowledging a ticket, resolving/closing

  • Who will get breach notifications

  • How often will these go out?

• Define your Impact, Urgency, and Priority Matrix. ASM can automatically assign the priority based on the impact and urgency of the ticket.

Checklist Incident Priority | IT Process WikiIT Process Wiki - the ITIL® Wiki

Priority Matrix using the number of affected users as the impact. This can be any set of values you need it to be, however.

Communications

• Do you have a dedicated email address(s) for users to email to ASM and for ASM to send through?
• What will or should the emails to the customer say when (& what specific data points should be included with the text?)

  • A new ticket is logged

  • A ticket is resolved/Closed

  • A ticket is updated

Role Based Access Security

• What restrictions will Analysts have?

  • Can they close tickets or simply resolve them? Who will close them?

  • Can they escalate or do they need to follow a script first?

  • Is any PII (sensitive or personally identifiable information) present that needs to be masked?

• What support groups do you have - these are the groups where tickets will be assigned. Each group must have at least 1 member.

Training and Socialization

• How do you plan to socialize your customers/users and your Analysts to Incident Management in ASM?