In ITSM, OOTB, there is no workflow difference between Standard or Normal change. The difference is to do with ITIL definitions. As a Standard change refers to a pre-approved change for which the tasks are well known, the usual practice will be to use a pre-configured change template to create such CRs. In order to skip approvals (auto-approve) in case of a standard change, appropriate approval phase configuration can be done for the Standard class. A Normal change, will usually go through the complete CR lifecycle.
Following link provides overview about Standard and Normal change requets:
Hope this helps.
I do not have hands on experience as a ITSM customer. However as a ITSM developer, I can suggest the below.
As there are no workflow difference between the Normal and the Standard process OOTB, but ITIL has differences in the defns, you can very well achieve the behavior by:
1. Configuring approval phases to suit your business needs. As Standard change is a pre-configured change, so it may very from company to company. And a custom approval process (phases) may be used.
2. Another way, you may create a custom change process to define the pre-configured change, associate it to a custom change template where you set shange type as Standard and use that template to create change requests.
Like wise other Change types functionalities can also be achieved.
if i put it simply then
Standard: This happens as a routine Change, say for example Changing the Backup Tape whenever Backup is scheduled or updating anti virus in all the Desktops every 6 months once...
so its a predefined, planned and routine change.
Normal: This is a well known change which equally has predefined steps but does not gets initiated on routine basis, this gets triggered based on the user request.
We are well versed to perform this change but will be performed as per the user request.
pls find the comments here...
Standard changes (pre-authorised)
A standard change is a change to a service or infrastructure for which the approach is pre-authorised by change management that has an accepted and established procedure to provide a specific change requirement.
The elements of a standard change are:
- There is a defined trigger to initiate the request for change
- The activities/tasks are well known, documented and proven
- Approval has been taken already (these changes are pre-authorised)
- So as per BMC Remedy Application a Standard Change goes through all the Status from DraftàRFAàRFCàScheduled for Review-àScheduled for Approval-àScheduledàImplement-àComplete(Review)---Close with no Approval mapped for any of the Status ….
A normal change
A normal change refers to changes that must follow the complete change management process. By definition a normal change will proceed through all steps of the change management process and those that are categorized as medium or high risk will be reviewed by the Business Owners, Change Advisory Board (CAB) .
The activities are of the normal change process are:
- ..Record requests for change
- Review the request for change
- ..Assess and evaluate the change
- ..Evaluation of change
- ..Change planning and scheduling
- ..Authorising the change
- ..Coordinating change implementation
- ..Review and close change record
So as per BMC Remedy Application a Standard Change goes through all the Status from DraftàRFAàRFCàScheduled for Review-àScheduled for Approval-àScheduledàImplement-àComplete(Review)---Close with Review, Business and Implementation Approval Mappings in place….
note: A well known task but has high impact can also be classified as normal change in order to opt the approvals to go ahead...some critical changes things like that....
Ashwanth, what does your company use for an usual change then? Something isn't routine or predefined.
Saroj, when you put in Change Requests for change you make to ITSM, as an admin, can you describe the classes you have to use for those changes and why? Unless maybe you aren't required to submit changes?
Thanx again everyone. Still unraveling a definition set that will make sense for our company.
It would be useful to respond to your query, if you can specify the change life cycle you want to follow your company. As mentioned earlier. this can be achieved by using a combination of change class / change process / approval phases and change template.
e.g. as the ITIL defn also says, a Standard change is a pre-approved change, you may directly goto Scheduled. To achieve this, configure Review and Business approvals for Standard change class as below:
- Open approval process config form
- Create Review Standard - phase:
approval process : change level - review
begin status - RFA, approved status - RFC, rejected status - Rejected, no approvers - RFC
- Create Business Approval Standard - phase:
approval process : change level - business
begin status - RFC, approved status - Scheduled, rejected status - Rejected, no approvers - Scheduled
- Do not create any approval mapping for these phases.
- Now when u create a standard CR, and do next stage from Draft, the CR will goto Scheduled directly. And the 2 approval phases will be kinda auto-approved and entries will be there in ap:detail form which can be used for audit purpose.
Hope this helps.
Let me know if the below is clearer and what else can be added for further clarity.
The organisation/business need to ensure that appropriate procedures are available to cover the different types of change requests. For different change types there are specific procedures, e.g. for impact assessment and change authorisation.
Change Class is a way to categorize a change such that each class can be mapped to a different Approval Process which drives different status transitions in order to meet your needs.
For example, I can configure a Change Class – Standard, such that all approval phases are auto-approved except for Business Approval by the Change Manager.
Following Change Classes are provided out of box. For Change Classes - Latent, No Impact & Normal – out of box configuration is provided as per the definition stated below. For other Change classes ( Emergency, Expedited, Standard), it is expected that the customer configure the process as per their needs. To configure an different approval processes for different Change Class, use Approval Process Configuration form under Approval Administration ( Custom tab, Foundation->Advanced->Approval Process Configuration).
■ Standard indicates a change (for example, a computer upgrade) that is
typically pre-approved and requires only approval by the change manager.
Standard changes follow the out-of-box change process defined as per ITIL
specifications. This configuration is not provided out of box.
■ Emergency indicates a change that resolves an incident or problem deemed
critical to business continuity and for which a work-around is not sufficient.
For more information, see Creating emergency change requests on page 133. Here again, it is expected that the configure an Approver process for Emergency change as per their needs.
■ Expedited indicates that a change has an enterprise-wide impact with an
associated risk. If you select Expedited, you must also select the Timing
Reason (for example, Known error correction). For more information, see
Timing Reason under “Adding classification information” on page 126.
Please configure the Approval Process that you would like to follow for Expedited changes.
■ Latent indicates a change that has already been performed (for example, if a
task implementer is assigned to replace the hard drive on a computer and
then decides to upgrade the memory while the computer is open). Latent
timing automatically sets the request status to Completed after you save the
change request. This is out of box behavior and cannot be changed.
■ Normal A normal change refers to changes that must follow the complete change management process. Normal changes are often categorised according to risk and impact to the organisation/business. For example, minor change – low risk and impact, significant change – medium risk and impact and major change – high risk and impact.
By definition a normal change will proceed through all steps of the change management process and those that are categorised as medium or high risk will be reviewed by the Change Advisory Board (CAB).
The default value is Normal. Out of box configuration follows this process.
■ No Impact indicates a change that has no impact on the infrastructure and
requires no approval.
By default, No Impact changes follow the Business Approval - No Impact
phase and move forward to the Scheduled status. Use this process for pre-approved
No Impact changes where the change is automatically scheduled
after the approval phase is satisfied. For more information, see Approval
processes provided out-of-the-box on page 357. This configuration is provided out of box.
Hi Saroj, & Girish. Thank you, this is hepful (and not what the documentation says).
What I see here is
Standard = Pre-Approved
Normal = Normal (NOT pre-approved)
I wish the documentation provided the defintion that Girish has provided.
I am still struggling with the words that were chosed for these, which will never make sense to the common user without a definition grid pinned to their cube. I fear we may need to ask our admins to remove one of them. We have been using No-Impact for our Pre-Approved changes, and we do not allow ANY changes to proceed without change management review.
This has been very helpful, thank you all very much. I now have to work through this against our own processes.
And thanx, Shivkumar, I will check that out.
Bit of an old thread now, but I have a query based on the line from the documentation
- "For other Change classes ( Emergency, Expedited, Standard), it is expected that the customer configure the process as per their needs."
If I were to leave the Approval Process configuration as-is OOTB but create an Approval Mapping set to 'Class = Standard', it will still kick in right? The above suggests that it wouldn't?
I have not tried exactly the case, but logically it will work, provided the "Class in Mapping" = "Class in AprProcConfig" record or the "Class in AprProcConfig" record is NULL.
Essentially if the status transition as a result of the approve remains the same for all change classes, one can have the same apr-process (phase) for all classes and can control approver-list using the mapping form.
And if the status transition varies from class to class, one will need to use the "Class field in AprProcConfig" form.