Difference between revisions of "Approving, Scheduling, and Implementing Changes"

From Hornbill
Jump to navigation Jump to search
(17 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
==Introduction==
 
==Introduction==
  
Once a Change has been assessed and accepted it may require a prescribed business process to be followed which may involve approvals, scheduling, and tasks. All of this can be orchestrated using the '''[[Business_Process_Workflow|Business Process Engine]]'''.  The complexity of the underlying change process can be shielded from the change users, and instead a graphical Head's Up Display can represent the Processes stages, tasks, authorisations, and milestones.
+
Once a Change has been assessed and accepted it may require a prescribed business process to be followed which may involve approvals, scheduling, and tasks. All of this can be orchestrated using the '''[[Business Process Designer|Business Process Engine]]'''.  The complexity of the underlying change process can be shielded from the change users, and instead a graphical Head's Up Display can represent the Processes stages, tasks, authorisations, and milestones.
  
 
[[File:Change Process.png|center|800px]]
 
[[File:Change Process.png|center|800px]]
  
 
==Approvals==
 
==Approvals==
 +
 +
Changes can include multiple approval stages in a single underlying Change Process.  Approval stages can be configured using the '''[[Business Process Designer]]''' and the '''Authorisation''' node. 
 +
:* Each Authorisation gate can be configured with the required approvers which can be named co-workers, or variables such as '''Request Owner''' or '''Customers Manager'''. 
 +
:* Approvals can require a unanimous outcome, or each approver can be attributed a weighting, and a weighting can be set to approve or reject the request.
 +
:* Authorisation outcomes:
 +
::* '''Approved'''
 +
::* '''Rejected'''
 +
::* '''Expired''' - Define how long the Authorisation window is available for, if no other outcome has been made, the Authorisation can be set to expire.
 +
:* Branching can be configured based on each possible outcome, and this could include a delegate authorisation point in the event of an Expired outcome.
 +
:* Reasons for Approval or Rejecting can be made mandatory if required.
 +
:* Authorisation Decision - Once an authorisation outcome has been made, you can use the '''Authorisation Decision''' node to mark the Change as Approved or Rejected.
 +
 +
Approvers will be notified by Hornbill Notifications which they will receive through their web user app, and or via the native Hornbill  iOS or Android app.  If the approver has a minimum of the '''Change Management User''' Role they will be able to view the Change and make a decision.  If they only have the '''Collaboration''' Role they will be able to view the Authorisation task and supporting details and make their decision by choosing from one of the two available outcomes again through the web user app, or native mobile apps.
  
 
==Scheduling==
 
==Scheduling==
  
Changes can be scheduled manually using the '''Schedule''' action bar option on the Change record. Using the business process engine, the underlying Change process can be '''suspended pending scheduling''' which will take the Change record in context to the '''Schedule''' action option, and will wait for the Change to be scheduled before the Change process resumes.
+
Changes can be scheduled manually using the '''Schedule''' action bar option on the Change record. Using the business process engine, the underlying Change process can be '''Suspended Pending Scheduling''' which will take the Change record in context to the '''Schedule''' action option, and will wait for the Change to be scheduled before the Change process resumes.
  
 
Once a Change is scheduled it will appear on the Forward Schedule of Change calendar.
 
Once a Change is scheduled it will appear on the Forward Schedule of Change calendar.
Line 17: Line 30:
 
'''Forward Schedule of Calendar'''
 
'''Forward Schedule of Calendar'''
  
In ''Service Manager''  if you have at least the ''Change Calendar Viewer'' role, you can review scheduled change in the change calendar by:-
+
In ''Service Manager''  if you have at least the '''Change Calendar Viewer''' role, you can review scheduled change in the change calendar by:-
:# On the [[What_is_the_Navigation_bar? |navigation bar]] select Service Desk [[File:Service_Desk.png |16px| Service Desk]] and then 'Change calendar'
+
:* On the App Menu select Service Desk [[File:Service_Desk.png |16px| Service Desk]] and then 'Change calendar'
:# The default view is the current month. Today’s date is highlighted along with any changes scheduled by day
+
:* The default view is the current month. Today’s date is highlighted along with any changes scheduled by day
:# Each change can be reviewed by selecting it and drilling down into the change record.
+
:* Each change can be reviewed by selecting it and drilling down into the change record.
:# You can change the view to by week or day and scroll between those periods using the ‘<’ or ’>’ buttons
+
:* You can change the view to by week or day and scroll between those periods using the ‘<’ or ’>’ buttons
 +
 
 +
==Implementing==
 +
 
 +
Change implementation tasks can be configured using the business process engine.  Tasks can be assigned to named users, roles, and variables (for example Request Owner).  Implementation tasks can include review activity once the Change has been deployed. Review activity can be used to identify the '''Effect of Change''' identifying and recording any Incidents or Problems which have been raised as a result of the Change.
 +
[[File:Change_Board.png|right|thumb|400px]]
 +
 
 +
:* '''Updated linked Requests''' - Automatically push down automatic updates to affected Incidents and Problems
 +
:* '''Promote the Change to a Change Board''' - A helicopter view of all Changes which are inflight can be visualised using the '''[[My_Boards|Hornbill Boards]]'''.  Each lifecycle stage of your Change Process can be represented by a list on the Board.  Changes can be manually added to the Board, and each Change card dragged and dropped between '''Lists'''. (Incoming, Assessed, Planning, with CAB, Approved, Scheduled, Implementation, Review for example). Alternatively the business process engine and the Add to Boards node, allows for Changes to automatically be added and moved between '''Lists''' on the Board as the Change progresses without the need for manual intervention.
 +
:* '''Push updates to Public Workspaces and Newsfeeds''' - Keep interested stakeholders informed in real time as Changes are approved, scheduled and released, by automatically pushing updates from the Change to a Change Management Workspace - All members of the Workspace will then see the updates on their Personal Newsfeed alongside updates to other requests they are following, and other notifications they are interested in.
 +
 
 +
All the above actions are configurable in the supporting Change processes using the '''[[Business Process Designer]]'''
  
  
 
[[Category: Service Manager]]
 
[[Category: Service Manager]]

Revision as of 03:07, 8 March 2017

Home > Service Manager > Approving, Scheduling and Implementing Changes

Introduction

Once a Change has been assessed and accepted it may require a prescribed business process to be followed which may involve approvals, scheduling, and tasks. All of this can be orchestrated using the Business Process Engine. The complexity of the underlying change process can be shielded from the change users, and instead a graphical Head's Up Display can represent the Processes stages, tasks, authorisations, and milestones.

Change Process.png

Approvals

Changes can include multiple approval stages in a single underlying Change Process. Approval stages can be configured using the Business Process Designer and the Authorisation node.

  • Each Authorisation gate can be configured with the required approvers which can be named co-workers, or variables such as Request Owner or Customers Manager.
  • Approvals can require a unanimous outcome, or each approver can be attributed a weighting, and a weighting can be set to approve or reject the request.
  • Authorisation outcomes:
  • Approved
  • Rejected
  • Expired - Define how long the Authorisation window is available for, if no other outcome has been made, the Authorisation can be set to expire.
  • Branching can be configured based on each possible outcome, and this could include a delegate authorisation point in the event of an Expired outcome.
  • Reasons for Approval or Rejecting can be made mandatory if required.
  • Authorisation Decision - Once an authorisation outcome has been made, you can use the Authorisation Decision node to mark the Change as Approved or Rejected.

Approvers will be notified by Hornbill Notifications which they will receive through their web user app, and or via the native Hornbill iOS or Android app. If the approver has a minimum of the Change Management User Role they will be able to view the Change and make a decision. If they only have the Collaboration Role they will be able to view the Authorisation task and supporting details and make their decision by choosing from one of the two available outcomes again through the web user app, or native mobile apps.

Scheduling

Changes can be scheduled manually using the Schedule action bar option on the Change record. Using the business process engine, the underlying Change process can be Suspended Pending Scheduling which will take the Change record in context to the Schedule action option, and will wait for the Change to be scheduled before the Change process resumes.

Once a Change is scheduled it will appear on the Forward Schedule of Change calendar.

Forward Schedule of Calendar

In Service Manager if you have at least the Change Calendar Viewer role, you can review scheduled change in the change calendar by:-

  • On the App Menu select Service Desk Service Desk and then 'Change calendar'
  • The default view is the current month. Today’s date is highlighted along with any changes scheduled by day
  • Each change can be reviewed by selecting it and drilling down into the change record.
  • You can change the view to by week or day and scroll between those periods using the ‘<’ or ’>’ buttons

Implementing

Change implementation tasks can be configured using the business process engine. Tasks can be assigned to named users, roles, and variables (for example Request Owner). Implementation tasks can include review activity once the Change has been deployed. Review activity can be used to identify the Effect of Change identifying and recording any Incidents or Problems which have been raised as a result of the Change.

Change Board.png
  • Updated linked Requests - Automatically push down automatic updates to affected Incidents and Problems
  • Promote the Change to a Change Board - A helicopter view of all Changes which are inflight can be visualised using the Hornbill Boards. Each lifecycle stage of your Change Process can be represented by a list on the Board. Changes can be manually added to the Board, and each Change card dragged and dropped between Lists. (Incoming, Assessed, Planning, with CAB, Approved, Scheduled, Implementation, Review for example). Alternatively the business process engine and the Add to Boards node, allows for Changes to automatically be added and moved between Lists on the Board as the Change progresses without the need for manual intervention.
  • Push updates to Public Workspaces and Newsfeeds - Keep interested stakeholders informed in real time as Changes are approved, scheduled and released, by automatically pushing updates from the Change to a Change Management Workspace - All members of the Workspace will then see the updates on their Personal Newsfeed alongside updates to other requests they are following, and other notifications they are interested in.

All the above actions are configurable in the supporting Change processes using the Business Process Designer