DRYiCE Gold BluePrint on Cherwell R5

In this release, we have introduced new capabilities in the walk-up support module on the self service portal to allow both fulfillers and support users raise incidents or service requests from the details available in the walk-up record. Other highlights include introduction of automation for updating incident tickets and change approval workflow, new notifications informing stakeholders on any change in status of an asset or CI, and enhanced reporting capability with more graphs and widgets.  

Walk-Up Support

• The ‘check-in’ option on the walk-up support page will now be enabled only during the working hours of the support location. This will allow end users to choose only those walk-up support locations that are operationally active at a given point of time, making it easier and convenient to seek support.
• A mandatory field called ‘Support Hours’ has been introduced on the form for creating a walk-up support location which will allow admin users to specify the operational hours. The hours of operation specified by the admin will alert visitors if the location is closed.
• The ‘Action’ section on the walk-up support form will now have a link to allow fulfiller users to take ownership of a walk-up record. Upon taking ownership, a link will be enabled for fulfillers on the walk-up record to create an incident or service ticket. Clicking on the link will direct fulfillers to the incident or service request form with auto populated ‘Requested For’ and ‘Source’ fields. Any member of the fulfiller team can now take ownership of the walk-up record to create an incident or service request as required.

Dashboard & Reports

• A new graph named 'Changes by Close Code' has been introduced in the ‘Performance’ tab on the change dashboard to show the count of all closed changes grouped by their type and close code. This will help the change managers to analyze closed change tickets according to their close codes.

• A new tab named 'Actionable' has been introduced on the change dashboard to display change tickets, grouped according to their stage in the approval process. The filters available in the ‘Actionable’ tab are as follows: View Filter: A filter to display records based on selected date, time and date range. Risk Filter:  A filter to display records based on risk type, i.e. ‘Any’, ‘High’, ‘Moderate’ or ‘Low’. Type Filter: A filter to display records based on change category, i.e. ‘Any’, ‘Normal’, ‘Standard’, ‘Emergency’. Service Filter: A filter to display records based on service type, i.e., any specified service. 
  The widgets configured on the dashboard are as follows: ‘Overdue Changes’ to display all the approved changes whose implementation date has expired. ‘Changes Pending PIR’ to show the count of all changes with their status showing as ‘Completed’ but with pending PIR and not yet closed. ‘My Pending Approvals’ to show the list of change approvals that are pending on a user. ‘Pending Approval more than seven days’ to depict the count of change approvals in ‘Pending’ status for more than seven days.
  A section named 'Changes Pending Approval' has been provided in the tab with the following widgets:  ‘Under Review’ to show the count of change records in ‘Review’ status. ‘Technical’ to show the count of change records that are in ‘Pending Technical Approval’. ‘Service Owner’ to show the count of change records that are pending service owner approval. ‘CAB’ to show the count of change records that are pending CAB approval. ‘ECAB’ to show the count of change records that are pending ECAB approval. ‘Moratorium’ to show the count of change records that are pending moratorium approval.

• A new tab named 'Volumetric' has been introduced on the change dashboard to show count of tickets categorized by type of change request. The ‘Volumetric’ tab will have the following filters: ‘View Filter’ to display the records based on selected date, time and date range. ‘Risk Filter’ to display records based on the Risk Type, i.e. Any, High, Moderate or Low. ‘Type Filter’ to display records based on the category, i.e. Any, Normal, Standard, Emergency. ‘Service Filter’ to display records based on the Service type, i.e. any specified service.
  The widgets configured on the dashboard are as follows:
  ‘Open Standard changes’ to show the count of all open standard changes. ‘Open Normal changes’ to show the count of all open normal changes. ‘Open Emergency Changes’ to show count of all open emergency changes. ‘All Changes’ to show count of all changes (open or closed). ‘Open Changes by Status’ to display the status based distribution of the open changes in a pie chart format. ‘Changes by RFC Type’ to show the count of changes based on RFC type. ‘Top 5 Services with Changes’ to display the top 5 services with the count of open changes. ‘Top 10 CIs with Changes’ to display in a bar graph format the top 10 CIs with the count of changes (open or closed).

• The customer satisfaction graph on the incident dashboard will now have the colors blue, green, yellow, red and dark red to denote customers as ‘Very Satisfied’, ‘Satisfied’,  ‘Neutral’, ’Dissatisfied’, and ‘Very Dissatisfied’ respectively. A table shown below the graph will provide details for the records marked as dissatisfied or very dissatisfied such as ‘Incident ID’, ‘Priority’, ‘Category’, ‘Sub Category’, ‘Reason for Dissatisfaction’, ‘Owned by Team’, ‘Survey Response’. This will allow fulfiller users to gauge the level of customer satisfaction in an intuitive manner and investigate all records with status as ‘Dissatisfied’ or ‘Very Dissatisfied’.

• A new pie chart graph named '%age of First Call Resolution' has been introduced on the incident management dashboard to show the ratio of tickets resolved to those unresolved during the first contact with an agent. The graph will allow fulfiller users to analyse the efficiency of the existing incident resolution processes.

• A new '%age of Major Incidents' graph has been introduced on the major incident dashboard to show the ratio of tickets that qualified as major incident to the count of all normal incidents logged into the system. This will highlight risks to business critical services and systems that require a response beyond routine incident management processes.

• A new column named 'Target Resolution Time' has been added in the ’Resolution Time’ report on the ‘Incident’ dashboard to show the expected time to resolve a ticket based on its SLA. It allows the fulfiller users to calculate the deviations and plan for corrective actions, if required.

• A new column named 'Target Response Time' has been added in the ’Response Time’ report to show the expected time to respond to an incident ticket on the basis of its SLA. This will allow fulfiller users to calculate the deviations from the target resolution time and plan for corrective actions, if required. 

• A new graph named '%age of Orphan Tickets' has been added on the incident dashboard to show the ratio of tickets unassigned to any teams or individuals in comparison to the total incidents logged into the system. This will highlight potential risks to business services due to unattended tickets and provide a scope to improve system efficiency.

• A new graph named 'Change Implementation ON vs OFF Schedule' has been introduced in the 'Performance’ tab on the change dashboard to show change requests that were completed and closed within their scheduled dates and those outside the implementation window. This will allow change managers to assess the efficiency of existing change implementation processes.

• A new graph named 'Overdue Changes' has been introduced on the change dashboard to show the count of change records categorized by their type and status as ‘Scheduled’ or ‘Work in Progress’ which have passed their due dates. The graphical format will help users better analyze the process efficiency and take the necessary steps to improve.

• A new button named 'Search Team for a Different User’ has been added on ‘My Teams’ dashboard. Upon clicking on the button process managers will be directed to a ‘Select User’ prompt to select a fulfiller from the list of users. Upon making the selection, the list of teams associated with the selected fulfiller will become visible. The 'Search Team for a Different User' button will continue to be available on this page allowing process managers to persist with the search, if required. This capability will allow process managers to assign tickets to correct fulfiller users after ascertaining their membership in the team authorized to handle the request.

Self Service Portal

• The widgets for 'Announcements' and 'News' have been combined into a single 'Major Incidents' widget on the ‘Broadcast’ section of the self service portal. Now, end users will be able to access and consume news and announcements related to major incidents from a single point, improving their user experience on the portal.

• The icons on the ‘Contact Us’ section have been updated according to a new design guideline.

• The subcategory pages on the service catalog have been redesigned. Now each subcategory will be represented in the form of a tile with an image on top. The new design will make the subcategory pages similar in format to the service and category pages, thus improving user experience.

CMDB

• The baseline changes to configuration items are now available in the asset management system for the following CMDB classes. Network, Database Datacenter, Server, Computer, Cluster, Application, Consumables, Telephony, Mobile devices, Other CI, System, Printer, Storage. This new capability will now help to track the changes made to these CI attributes during baseline changes.

• Email notifications will now be triggered to primary users and asset management group in intervals of 60 days before expiry, 30 days before expiry and on the expiry date of an asset to keep them informed about the expiry date of the asset. A link will also be provided in the email to allow the relevant stakeholders to renew the asset in time. This will ensure the continued availability of the assets as the relevant stakeholders will be able to renew the asset before its expiry date.

• A new capability has been introduced on the quick search bar to allow fulfillers to search for CIs with their aliases.

• Email notifications have been configured for primary users and asset management groups to inform them on the change in status of an asset as given below. 
   When the asset is disposed at ‘Vendor Credit’. When the asset is retired. When the asset is decommissioned. When the asset is moved to ‘In-stock’ or ‘Disposed from Missing’. The notifications will allow the stakeholders to renew the asset before its expiry. 

• All classes on the CMDB overview form will now have a mandatory ‘Type’ field. Admin users will now have to mention the type of class before they are allowed to enter the class in the CMDB thus improving the categorization of classes.

• An email notification has been configured to inform asset owners of the issuance of an asset after 30 days of the asset's reservation in their name.

• Upon changing the status of an asset to ‘In Transit’, a popup will be triggered to capture mandatory information in ‘From Warehouse’ and ‘To Warehouse’ fields. The status of the asset will be updated after the information has been captured successfully. The introduction of these mandatory fields will ensure that the asset's location-specific information is captured if it is moved from its existing location. 

Incident Management

• Introduced navigable “Related List Items” on the incident overview form to allow fulfillers to click and navigate to the resources linked to listed items. The new items added in the related items tab are as follows: Similar Incidents, Related CIs, Open Incidents, Related Problems, Attachment, Solution. The navigable ‘Related List Items’ will allow fulfillers to access the resources needed to resolve an incident quickly without leaving the incident form.   

• The ‘Performance Analysis’ and ‘Process Reports’ tabs introduced on the incident dashboard of the fulfiller portal will now allow fulfillers to see system performance data and process workflows.
• Now, the ‘Publish Broadcast’ task configured for a major incident will close automatically after the incident has been published in the Major Incidents tab on the self-service portal.
• An incident ticket can now be created automatically on the basis of the content of the email sent by an end user to the customer service desk reducing the creation time of incidents.       
• Now, an email will be automatically triggered to the requester of an incident ticket when the status of the ticket changes to ‘Pending’. When the requester responds to the email, the status of the ticket will be automatically updated to ‘Assigned’ and the response will be recorded in the incident journal. In addition, the status of an incident ticket will automatically change to ‘Closed’ or ‘Reopen’ after the requester clicks on their corresponding links on the incident resolution email notification. This will allow requesters to convey their acceptance/ rejection  by reverting to the email from the customer service desk.
• A new 'Announcements' tab has been introduced in the “Related List” tab on the incident overview form to show announcements related to major incidents. This will allow fulfillers and incident managers to access all information related to major incidents from a single place.   
• New graphs have been introduced to show priority wise count of tickets with breached SLAs and priority wise percentage of reopened tickets. Fulfiller users will now be able to leverage this information to take remedial actions based on the level of urgency.  

Change Management

• A new ‘Trend by Close Code’ graph has been introduced on the change dashboard to display the count of change tickets closed in a month categorized by their close code such as ‘Successful’, ‘Partially Successful’, ’Unsuccessful’, ‘Rejected’, ‘Cancelled’.  This will allow change managers to analyze the effectiveness of the existing change management processes.

• If the owner of a change request ticket modifies the service and category fields in a ‘Normal’ or ‘Emergency’ change ticket, the ticket will get assigned automatically to the correct team for approvals. This ensures that there is no loss in productivity due to unreliable approval mechanisms.

• Now, when a change request is closed, the values in ‘Closure Date’ and ‘Time’ fields on the change overview form will get automatically updated according to the date and time of closing the ticket. Change managers will now be able to see the date and time of closed requests upon opening the change overview form. 

• A new report called ‘Changes Implemented in Freeze Period’ has been introduced in the change dashboard to show change requests that were closed and completed in the 'Freeze Period’ when changes to critical services are not supposed to be made. A new report called ‘Changes by Closed Code’ has been introduced on the change dashboard to show the percentage of change tickets closed by ‘Close Code’ such as Successful’, ‘Partially Successful’, ’Unsuccessful’, ‘Rejected’, ‘Cancelled’. A new report called ‘Changes Implemented Outside Implementation Window’ has been introduced on the change dashboard to show the count of tickets closed outside the implementation window and categorized by ‘Close Code’. Change managers will now be able to analyze the success or failure of a change process with the help of reports accessed from a single dashboard.

For Support related queries, please log onto [email protected]