Setting Up your System
This section gives you a high level overview of the different aspects of the system you should consider when planning your system. See "Configuring Your System" for detailed configuration options.
Concepts and Considerations
There are various concepts and functions you need to understand and consider before setting up ASM Core.
To consider
To what extent do you want to configure ASM Core?
For example, do you want to change the field titles for the Call Details, Request Details and Configuration Item Details windows?
Do you want to redesign ASM Core windows (for example, add fields to the main display and change colors)?
The ASM System can be configured to whatever extent is required to reflect your organization’s terminology and procedures.
You can change the names of fields and menu items using the System Titles window. You can simply change the spelling, the terminology (for example, rename Call to Ticket), and so on.
To configure windows further, use the ASM Designer to add and remove fields from windows, rearrange them, and change colors.
Analyst Skills and Security Roles
To consider
If analysts have specialist skills, do you want to link them to call types or to CMDB item types? Ensure their security role grants enough access for them to work these kinds of Calls.
Which analysts do you want to be able to change options in the Administration module or add other analysts to the system?
Do you want all analysts to be able to log calls and/or requests or give only certain analysts the ability to receive calls and tasks?
The skills of your analysts can be linked to both call types and/or CMDB item types. This enables analysts to direct calls to the appropriate person to be solved, based on the issue type or CMDB item type specified in the call.
Dynamic Ticket Routing: Assign Skills to Analysts
Skills are assigned to analysts on the Person Details window through the Skills Explorer option.
Security Roles (RBAC)
Controlling access to different parts of the system is important. A security role is a set of security options and permissions pertaining to a specific part of the application. There are security roles for general access, IPK Management, Workflow Management, Configuration (CMDB) Management, Service Level Management, Availability Management, Knowledge Management, and the Bulletin Board. You can create any number of roles and then assign those roles to individual analysts.
Security roles are created in the various Security Roles options in System Administration, and assigned to people in the Person Details window.
Analyst's Groups (Queues)
Analysts can be organized into groups to reflect how your support center operates and optimize ASM Core features such as call and task forwarding and escalation.
When a call or task is forwarded to a group, every member of the group receives it. In the case of calls, the first analyst to action the call becomes the owner and the call is removed from the other analysts’ Calls Outstanding windows.
To create IPK groups, use the IPK Groups window. To create workflow groups, use the Workflow Management Groups window.
Call Resolution and Closure
To consider
Do you want only specific analysts to be able to close calls/tickets?
Do certain calls/tickets need to be reviewed before they can be closed?
Will you configure auto-close for certain calls/tickets?
ASM Core can be set up to allow any analyst who resolves a call to also close it, or to give only certain analysts the ability to close calls. In the latter case, ASM Core automatically forwards the call to a closing analyst for final sign-off once the call has been resolved.
If you want only certain analysts to be able to close calls, select the Comments closure method in the IPK Settings (Partitioned) window.
You can then either:
give analysts the ability to close calls as part of their IPK security role
or
nominate a particular group as the closure group and link analysts to that group.
Requests, Tasks and Approvals
To consider
What sort of request types do you want to set up?
Do you want ASM Core to automatically calculate requests and task target dates?
A request is an order for change. The owner of a request is known as the Request Manager for that request. A Request Manager is defined as any analyst who has been assigned Manager permissions as part of their Workflow Management security role.
By default, new tasks are suspended when they are created and need to be authorized by the Request Manager. The tasks are then unsuspended but only become active (that is, able to be actioned) once all their parent tasks are completed, which means that the tasks that precede the current task in the workflow and upon which it depends must be closed.
An approval is a special kind of task that must be signed off before the workflow can progress and the request can be completed.
ASM Core provides several task types that can be added to your workflow to perform specialized actions.
Service Level Management
To consider
Do you want ASM Core to escalate calls, requests and tasks if they are not actioned or resolved within a certain period of time?
Would you like calls and requests involving different configuration items, Users or organizations to escalate at different times?
Do you want to be able to escalate different types of CMDB items at different times?
Escalation causes alarms to be activated when a call or request has not been actioned or closed within the required period of time. The call or request escalates to one or more analysts and appears on their Calls or Requests Outstanding window (providing the relevant escalation options have been selected).
You can configure the system to automatically send an email or pager message to the analyst(s) receiving the escalated call or request when it is first escalated.
After a certain amount of time (longer than the escalation time), the service agreement is said to be “breached”. In this case, financial penalties may apply, depending on the particular agreements and relationships you have set up. Escalations are designed to prevent these agreement breaches by warning analysts that the maximum time permitted by the agreement is approaching.
Partitioning
To consider
Do you want to create different system configurations for different groups in such areas as IT, HR, Legal, Projects, or Finance? ASM has field level security and status and reason linking to screen sets, so partitioning may not be necessary if the sole reason for considering it is to protect sensitive data or eliminate screen clutter between different groups and work processes.
Partitioning is a way of dividing items in your database into separate sections in order to set up different Service Desk, Workflow Management, and CMDB options for different functional units. It provides a means of true Enterprise Service Management (ESM) where field level security and other system settings will not suffice. Sometimes, regulatory mandates require a secure partition for certain areas of support and service management. This is common in health care and banking.
Alemba recommends that you see your professional services consultant or your account manager for help deciding what is right for you.
Partitioning effectively creates secure, separate, but shared ASM systems (certain data, such as people and locations, can be shared across partitions) without actually creating separate enterprise ASM systems. This means there is no need for the additional cost, infrastructure, and maintenance that adding additional copies of ASM would ordinarily incur. You can have as many partitions as you want. There are no additional fees or maintenance and support costs.
For example, an organization’s Service Desk can have multiple support groups responsible for a wide variety of unrelated systems, technologies and User support. They may or may not share a common user-base and organizational structure. Each support group requires its own issue types and service levels for different organizations and Users, as well as different escalation response times. In addition, the configuration items supported by each group may be of no interest to other groups. They are effectively separate support groups entirely, such as one might encounter with a 3rd party support provider or MPO. While this could be handled with field level security and system settings, some organizations providing support in this manner may prefer the physical separation partitioning provides.
In another example, a hospital must maintain strict security over the health records of its patients. The service and support for Epic, EpicShare, EpicResearch, Cosmos, MyChart, and EpicUserWeb system tickets and patient related inquiries and assistance may contain sensitive patient health record data and only certain analysts are permitted access.
The hospital chose to partition its Epic family of support services and all related patient and ticket data into a "Patient Support Services" partition. All other IT Service and Support for the hospital is held in the "IT" partition and much of the common data is not partitioned. This satisfies HIPAA (a federal law that required the creation of national standards to protect sensitive patient health information from being disclosed without the patient’s consent or knowledge), and JCAHO oversight (an accreditation body responsible for healthcare delivery).
With partitioning, the organization only needs to maintain one database, with only the information relevant to Analysts and Users of a particular partition being accessible to them. On the other hand, non-partitioned information can be accessed and updated by all analysts with security access rights to do so.
Configuration Management Database (CMDB)
To consider
What services do you want to create for your organization?
What type of configuration items do you want to record: hardware, software? How many components of these do you want to record: PC, screen, keyboard, cards in the PC?
Who are your Users (internal staff, external Users)?
Which organizations do you support (if any)?
The CMDB refers to the collection of services you provide and the configuration items, people, organizations, locations, agreements, cost centers, and contracts supporting these services.
CMDB records are added to the CMDB from the New drop-down menu on the toolbar or from the Call, Request and Task Details or Search windows. Parameters for the CMDB are defined under System Administration > CMDB.
The Users supported by your Service Desk (that is, the people who contact the Service Desk with problems) can vary. They may be linked to different organizations, be located at different sites, belong to different departments, use different CMDB items, require different levels of support, have specific network IDs, and so on. ASM Core enables you to record all of this information.
You can also give certain analysts in your Service Desk responsibility for particular contracts, and define separate agreements for different Users, organizations and external suppliers.
Steps in Setting Up the System
Because of the flexibility offered by ASM Core, you do not need to set up your system in a particular order. However, if you are setting up your system for the first time, we recommend you do so in the following order.
Best Practice
ASM Rapid Start is a preconfigured database with much of the setup completed to ITIL specifications. You need then only consider what will not work for your organization instead of beginning with a "blank slate" or recreating the same processes you are currently using that may not be working as well as you would like. To find out more about Rapid Start systems, please contact your account manager or [email protected]
Last updated
Was this helpful?