DRYiCE Gold BluePrint on Cherwell R3

Release 3.0 of DRYiCE GBP on Cherwell platform focuses majorly on enhancing the capabilities of DRYiCE GBP in harmony with the underlying Cherwell platform. Apart from this, release version 3.0 also comprises of some enhancements to improve the customer experience.

Integrated OOTB mApp

• CSM license mApp: Integrated the CSM license mApp that is available out of the box with Cherwell platform, in order to manage the user licenses

Connector for iAutomate

A new connector for DRYiCE iAutomate, our own intelligent run book automation (RBA) product, has been created which will automate the closure of Incidents, Service Requests and task tickets.

• Consolidated mApp: Created a consolidated mApp of Connector for DRYiCE iAutomate that enables automated resolution of Incident ticket, Change task and Service Request Task

Bagheera

An additional scoped application to automate the admin and data management tasks like adding or updating the records. Following capabilities are enabled in the Bagheera application over GBP on Cherwell.

• New Service named Bagheer: A new service named Bagheera request has been added in the service catalog in self-service portal with description as ‘Use this request to add or update user data’.
• Requests in Service Catalog: Bagheera Service has a category named ‘Data Management’ with description as ‘Add or Update records in Data template’. Category has a Sub-category named ‘Request to Add/Update Location’. Clicking on the sub-category will launch the form submitting the same, users will be able to update the current working location
• Attach Bagheera template: On launching the Bagheera sub-category form, users will have an option ‘Attach on the tool bar’ on the form enabling them to download respective pre-defined templates and then attach the filled templates through the Attach File option. Hovering on the pre-defined template, users will have an option named ‘Open’, clicking on the same, template (in csv format) is downloaded on the local system. Once the form is complete, users can attach the filled template using another link named ‘Add Attachments’ visible on the form. Using the link, users will be able to attach the filled template only. Only if the users have successfully uploaded the Bagheera template, Order Now button in the form will be active. Else the button will remain inactive.

Dashboard & Reports

• Survey Report: Added a new Report in the Dashboard depicting the data generated from end user survey submitted on resolution and closure of a ticket. Report display the data in the form of bar graph where each bar depict each response and height of bar depicts the response count (or count of users, responded with the specified response). Fulfiller users can view this report in the Report manager section in the Fulfiller client. For generating the report, fulfiller user has to select the date range for which the report is required
• All Incident widget in the Incident Dashboard: An ‘All Incident’ widget was configured in the Incident management dashboard in the fulfiller portal. All Incident widget depicts the count of incident requests, logged in the system, categorized based on the current status. Launching the dashboard will display the graph with default value (value based on the last selected range). Fulfiller users also has the option to update the time range and for the selected time range, updated graph will be displayed
• All Incident widget in the Major Incident Dashboard: An ‘All Incident’ widget was configured in the Major Incident dashboard in the fulfiller portal. All Incident widget depicts the count of major incident requests, logged in the system, categorized based on the current status. Launching the dashboard will display the graph with default value (value based on the last selected range). Fulfiller users also has the option to update the time range and for the selected time range, updated graph will be displayed.
• All Request widget in the Service Request Dashboard: An ‘All Requests’ widget was configured in the Service Request dashboard in the fulfiller portal. All Request widget depicts the count of service requests, logged in the system, categorized based on the current status. Launching the dashboard will display the graph with default value (value based on the last selected range). Fulfiller users also has the option to update the time range and for the selected time range, updated graph will be displayed
• All Problem widget in the Problem Dashboard: An ‘All Problem’ widget was configured in the Problem dashboard in the fulfiller portal. All Problem widget depicts the count of problem records, logged in the system, categorized based on the current status. Launching the dashboard will display the graph with default value (value based on the last selected range). Fulfiller users also has the option to update the time range and for the selected time range, updated graph will be displayed.
• All Change widget in the Change Dashboard: An ‘All Change’ widget was configured in the Change dashboard in the fulfiller portal. All Change widget depicts the count of change requests, logged in the system, categorized based on the current status. Launching the dashboard will display the graph with default value (value based on the last selected range). Fulfiller users also has the option to update the time range and for the selected time range, updated graph will be displayed.
• Teams I Belong to widget in the My Teams Dashboard: New widget named ‘Teams I Belong to’ added in My Team dashboard in the fulfiller client. This dashboard display the list of teams, the logged in user belong to
• ‘Changes Initiated by Me’ Widget introduced in Change Dashboard: A new Widget has been configured in the Change Dashboard called ‘Changes Initiated by Me’ that will list the change tickets initiated by the logged in individual within the given time duration. User can update the time duration using the time duration dropdown in the widget. On selecting new duration, data listed in the widget will be refreshed and will display the tickets based on the new time duration. Tickets will be listed in tabular format with minor details like Category, Request Date, Status mentioned in the widget. User also has an option to view more. Clicking on View more will launch a new page listing all the change ticket with complete details like description, short description, Start and end date and status
• New report to list Changes Made Outside Implementation time window: A report named ‘Changes Implemented Outside the Approved Window’ is configured in the Change Dashboard. This report lists all approved changes that has been implemented outside the defined implementation window. If the Actual Implementation Start Date and End Date does not fall within the Planned Implementation Start Date and End Date for a Change ticket, then these tickets will fall outside the defined implementation window. Report will include the following details for each change: Count of all these changes, Change ID, Change Type, Implementation start and end date/time, Actual start and end date/time

Self Service Portal

Following are the enhancements introduced in the self service portal:

• Share link on Knowledge articles: A new icon by the name ‘Share’ will be present on all Knowledge Articles. Using the share functionality, end users can share the article with others. Clicking on the share link will launch the mail client installed on the user’s system. A new compose mail will launch in the mail client, with the link to selected article. User can enter the Email ID of recipients and share it with them for reference

CMDB

Following new Classes and changes were implemented in the CMDB Classes:

• New classes and attributes created in CMDB: Configured new classes and their attributes in CMDB - Consumables, Database Instances, Cluster, Storage, Datacenter, Network Devices, Server, Computer
• Warehouse tab in Consumable classes: A new field named ‘Warehouse’ created in the Consumable classes form. Field is a dropdown field with following values
  • Core A Warehouse
  • Core B Warehouse
  • Site A-1 Warehouse
  • Site A-2 Warehouse
  • Site B-1 Warehouse
  • Site B-2 Warehouse

This will be a configurable field that list the various warehouse sites. There will also be a related tab named 'Warehouse' created in Consumables Class. The warehouse tab will be visible only when the user has selected value in Warehouse field. Warehouse tab display the following fields for the selected warehouse site

1. Warehouse Name – Non editable, auto-populated based on the selected warehouse site, field displaying the warehouse name for the selected site
2. Type – Non editable field, auto-populated based on the selected warehouse site, displaying the Warehouse type (as Central or Local warehouse)
3. Site – Non editable field, auto-populated based on the selected warehouse site, displaying the site value.
4. Warehouse manager – Non editable field, auto-populated based on the selected warehouse site, displaying name of the warehouse manager
5. Description – Non editable field, auto-populated based on the selected warehouse site, displaying miscellaneous information (if any) stored in the database

• Separate identifier for CMDB class: Two check box field added in the CMDB Group leader object, one with label Asset and another with label CI. Selected value in the CMDB Group leader object will depict the identity of the CMDB class. If admin user has selected both CI and Asset check box, then the CMDB class is considered as both Asset and CI
• New CI record on movement of Asset ‘Decommission’ to ‘In Stock’ stage: When a class, marked as Asset or Asset and CI, moves from ‘Decommission’ to ‘In Stock’ stage, a new CI record will be created in reference to the old CI record. The Old CI for the specified class will move to ‘Decommission’ Stage and will be in read only mode for review. When a user clicks on the ‘Move to In stock’ from Decommission, a popup will appear with message, “This CI has been Decommissioned and a New CI record will be created in In Stock status. Kindly fill the Ownership details for the same.” Popup will have a Drop downfield, where user has to select the ‘Team for New CI record’. On selecting the team and submitting details, all asset related attributes gets copied to the new CI record and new CI record will be created in ‘In stock’ status and ‘In Inventory’ as Sub Status. The New CI record will have a related tab named ‘Asset History’ that displays the old CI record.
• Hide Warehouse field: When the status of  a class moves to ‘In Transit’. warehouse field will become empty and will be hidden in the form. Two new mandatory fields will appear in the form, named ‘From Warehouse’ and ‘To Warehouse’. Both fields will be drop-down fields listing the warehouses. Values in the ‘From Warehouse’ and ‘To Warehouse’ fields should have different values
• End of Life field created for CMDB classes: A new field ‘End of Life’ Date field created for all classes. End of Life date field is an editable and optional field that will specify the date after which the asset will no longer be fit to use for marketing and selling stops
• Mandatory Cancellation Reason: When user clicks on cancel link in any of the class, a prompt will appear asking user to specify the reason for Cancellation. It will be mandatory for the user to enter the cancellation reason. User will get an error in the popup on not filling cancellation reason. Cancellation reason specified by the user will be mentioned in the journals.

Incident Management

Following new Classes and changes were implemented in the Incident Management module

• Submitted Date and Time in Incident form on fulfiller view: A new field ‘Submitted date and time’ created below the ‘Created date and time’ field in the incident form in the fulfiller view. When user is creating the incident on the fulfiller view, clicking on the 'Save' button on the toolbar or 'Assigned' (After filling all the mandatory details), Current date and time will be auto-populated in the submitted date and time field. When user, creating the incident using self-service portal, date and time when user clicked on the ‘Save’ or 'Submit' button will  be captured as Submitted Date and time for the ticket.
• Log journal entry on Team change for a ticket: Journal Notes in the incident ticket and Major incident ticket will get updated every time a new team is assigned on the ticket. It also includes the cases of auto-update of team based on the pre-set rules like: If incident classification is changed, If a Primary CI is selected or updated. In case, on changing the classification or updating the CI, if assigned team doesn’t update, then Journal notes will not be updated
• Team manager can change owner of the ticket within the team: Team Manager of a Team assigned to the Incident ticket, will have the rights to change owner of a ticket within the Team  and assign the ticket from one team member to another team member. A new link, ‘Select owner’ will be visible to the Team manager in the ticket detail page. Clicking on the link, Manager will be asked to select the new owner of the ticket, Select owner field will be a dropdown field and on selecting the new owner, ticket will be assigned to the new selected member within the team.
• New 'Resolution Time' field in the 'Resolution Details' tab: A new field named ‘Resolution Time’ introduced in the Resolution details tab for the incident. The 'Resolution Time' will display the complete resolution time in terms of number of days, hours, minutes and seconds. This field will auto populate once the user click on resolve for a particular ticket and users will not be able to edit the same.

Change Management

• Copy Change Record: Fulfiller users will have the ability to copy the details from one change record to another. Under the ‘Action section’ in the form of Normal and Emergency Change, a new link ‘Copy Change’ has been configured. Copy Change link will be inactive in new change form and will be activated as soon as the Change Record is Saved. In case the fulfiller user has opened an existing change record, Copy Change link will be activated. Clicking on the link will prompt user to select the type of change to be created with two options, Normal Change and Emergency Change. Selecting the option will close the prompt and new change form will open in draft status with following fields prepopulated based on the original change record. Service & Category, Primary CI, Reason for Change, Short Description and Description, Test Plan, Backout Plan, Implementation Plan, Validation Plan. Users can change the details prepopulated and can save the new change record.
• Delegate Change Approvals: Change approver will be able to delegate their approvals to another users, so that approval process or cycle is not delayed in case of the unavailability of change approver. Users can activate the delegation using My profile section, where they can select Start date, End date and select Delegate Name (whom they want to delegate the approvals). Clicking on Save Button will save changes and will activate the delegation for the specified time period to the delegated user.
• Task Start Date in the Change Implementation Tasks: Introducing a new ‘Task Start Date’ field in the Change Implementation task. It is mandatory for the Change Initiator to select a task start date and time in the Task Start Date’. Introduce a field on Change Implementation Task Form - *Task Start Date* - mandatory date time field. By default, all implementation tasks, should auto-populate the Task start date as Implementation start date of change. This field will be editable by the *Change Initiator, Change Management Team, and the respective Task Assignee*. They will be editable *before the Change status moves to Scheduled*. Once a Change is scheduled, start date for all implementation tasks should become read-only. Validation - The Task Start Date for all implementation tasks should be *within the change implementation window*. If it is selected as a date before change implementation start date or after change implementation end date, user should be given a error prompt that Task Start Date should be within the change Implementation window. Also, once a change implementation task is closed, a field* 'Task Close Date'*, capturing the closed date/time of task should appear on the task form.
• Collaborative Change Management Teams: Enabling change managers or the member of change management team to Approve, Deny, Refer back any change ticket that is assigned to their team or an individual in their team. In case a Change ticket is assigned to a different change management team (based on the Service, Category and Sub Category), then the individuals will not be able to access or update the ticket.
• Submitted Date Time: System will capture Submitted Date and time separately in Change tickets. As soon as the user clicks on ‘Save’ button on the toolbar or ‘Submit for Review’ link in action, Submission time will be logged in the system for the Standard, Normal or Emergency change tickets

Problem Management

• CAPA Check list: Problem Manager will be able to add checklist items for Corrective Actions and Preventive Actions (CAPA) in problem record. So that one can track the actions to be taken and who will be responsible for those actions. There will be a link named ‘Add Checklist’ under Actions section. Clicking on the link will open a checklist form where users can add up to 20 checklist items and Save the list using Save button in the form. Form will have the following fields:
  • Checklist name: mandatory text field, where users can add name of the checklist
  • Module: A non-editable field, auto-populated based on the module name from which checklist is being created
  • 20 item records with each record having following fields
  • Item Description text field to capture description for individual checklist item
  • Due Date: Checkbox to specify if the Due date is required or not
  • Due Date: Date and Time field that will be activated only when Due Date Checkbox is active.

On saving the checklist, updated checklist will be visible in the CAPA checklist related list tab in the problem record page. CAPA checklist tab will display following records:

• • Checklist ID: Auto-created unique identifier
  • Checklist Name: As specified at the time of creation
  • Assignee field: for every checklist item added reference field to user info table
  • Done and Skip buttons for individual checklist item, enabling the users to update the status for each checklist item
  • Status for every checklist updated as ‘Completed’ or ‘Skipped’ ‘by username’ ‘on date and time’
  • Due date visible if selected during checklist creation
  • Users comments for every checklist item
  • ‘Add items’ link: Clicking on it will redirect user to original checklist form
• Cause By Change Field: As a problem stakeholder, If a problem has been caused because of a change implementation, I should be able to link that change to the problem separately, so that it is identifiable that the problem was caused by which change record. There will be a new reference field named Cause by Change on problem form. It will be an optional field where the problem stakeholders can link the Change record, if the problem has been created due to a change implementation. Field will show a list of all the changes (open or closed) in the system, and user can select any one record for reference in the field. Field will be an editable field and Problem Submitter, Problem Manager and the PIT Members can edit the fields throughout the lifecycle till the ticket is Closed.
• Tool Tip for Fields: Tool tips added for the following fields in the Problem form. Tool tips will be visible when the user hover over the fields. Root Cause, Workaround, Corrective Action, Preventive Action, Resolution
• 5 WHYs RCA Example: A new link named ‘Refer 5 Why Example’ is implemented in the RCA form. Clicking on the link will redirect user to a new browser tab showing a dashboard explaining 5 Why RCA technique with example

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