Requests and Tasks
In any organization, there is usually a defined procedure which people must follow in order to implement change or fulfill requests for goods and services and much of it can be automated.
These processes may consist of a few steps, or dozens. They often require approval from some form of management. Workflow is a term used to describe any change or request process, outlining the necessary tasks and approvals required for completion. Examples of these kinds of tickets include the following:
An employee entering the organization
An employee leaving the organization
Replacing an entire computer network
Booking a plane ticket for business travel
Implementing an upgrade to a piece of hardware
Workflow management is the practice of ensuring all requests and changes within an organization are carried out in a planned and authorized manner. It is a component of quality frameworks such as ISO 9001, BS 8018, ISO 20 000 and ITIL (Information Technology Infrastructure Library).
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.
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 and this is the current topic being covered.
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.
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 request 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 when a new vendor was requesting/ordering point of sale devices. 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 screen. We then made the field mandatory.
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.
Lifecycle of a Request
Requests are created when a Change or some other type of fulfillment activity is required, for example when you must implement a workaround to resolve a call logged at the Service Desk.
When a request is created, the appropriate template, including predefined attributes and a dependency diagram linking all tasks and approvals, must be selected. Given the lifecycle of a request and the high number of tasks which must be created, it is important to use the appropriate system tools in which to monitor and keep track of all requests and tasks currently taking place.
ASM Core enables analysts with the appropriate security permissions to effectively create, authorize, observe, and report on every change request and request for good and services throughout the lifecycle.
Typically, all workflow is configured around phases such as:
Initiation
Implementation
Post-Implementation
Closure
There can be any number of phases in addition to the basic phases, such as approvl phases, documentation phases, development and testing, to name a few. These phases help to organize the lifecycle into discernable, logical chunks. You can create as many phases as you need and not all phases need to be used on all requests.
ASM Workflow Management
ASM Workflow Management provides an automated means in which to design systematic and comprehensive procedures that will be implemented when Change is required or a request is initiated. Workflows are displayed in a graphical format, allowing you to easily see the tasks, approvals and any dependencies required.
You can:
Create requests for change
Schedule a change request to occur at a future date and time
Create comprehensive workflows with the vast array of task entities in the drag-and-drop workflow builder on the dependency diagram
Create amendable requests by introducing amendable statuses. This will allow users to create their own service bundle contents in the portal
Create post provision actions, allowing users to add further functionality to a service that has already been provisioned
Use activation rules to automate and streamline any workflow
Define phases of a request, so that the tasks within can be grouped logically
View the progress of a request in the form of a Gantt chart
Essentially, you can monitor and handle all requests and tasks associated with RFC (Requests for Change) and Request Fulfillment for improved, consistent and predictable results. By streamlining your processes, you are contributing to providing a system which is not only systematic but entirely traceable, leading to lower costs and shorter cycle times through a more effective use of resources.
Activating, Closing and Re-opening Tasks
Note the following rules dictating when tasks are activated, closed and re-opened.
A task is activated if all of its parent tasks are closed (except where the parent task is also a child task) and one of the paths is active.
A task will be closed redundant if its parents are in a state where they cannot activate the task. Normally this is where there is a single parent task that is closed redundant or rejected, but can also exist in more complex workflows like activation tasks not being able to meet the activation criteria.
A task will be reopened recursively provided it is not a type of task that has a conditional outcome. For example, the workflow will not reopen after an Approval, Conditional Branching Task, Manage CMDB Task or Outbound Action task.
Last updated
Was this helpful?