SX R13

This release includes many new features and enhancements for improving user experience, configurability, and ease of use. In this release, we’ve introduced a new capability to map ‘Business Owner’ and ‘Technical Owner’ roles to ‘Support Providers’, enabled support users to raise service requests on the behalf of ‘Consumer Companies’ and added the configurability to create AMS rules based on ‘Cis’ or ‘Services’. Other highlights include the addition of new filters to improve search capabilities within the work item board for all modules

The scope of this release extends to the Consumer Portal, Service Board, Foundation, Incident Management, Problem Management, Change Management, Asset and Configuration Management, AMS Board, and Notifications Module.

Asset and Configuration Board

• Now in the Asset and Configuration board, a ‘Support Provider’ can also be assigned the role of a ‘Business Owner’ or ‘Technical Owner’.

  Currently, while creating a CI for any consumer company, the ‘Configuration Manager’ can select only the ‘Consumer Company’ user for the ‘Business’ or ‘Technical Owner’ role. This is not aligned to the MSP model since the ‘Financial Ownership’ and the ‘Business Ownership’ of CIs are associated with both the ‘Consumer Company’ and the ‘Support Provider Company’ while the ‘Technical Ownership’ role is solely vested with the ‘Support Provider’.

  The new capability will allow the configuration managers to map CIs to support providers as business owners as well as the technical owners as per requirements.

Service Board

• The concept of a shared offering has been extended further to allow support users of provider companies to create ‘Fulfillment Work Items’ for the consumer of other consumer companies.

  Currently the limitations for support users are as follows:

  • Support users are not able to see the offerings of the consumer company on their home page. Offerings are visible only if they have been created in the support user’s catalog or shared by the support company.

  • Even if the offering of the consumer company is available, support users will see only the names of users of their own company in the ‘Requesting For’ drop down on the ‘Ordering Information’ page.

  • Also, the order record that gets generated in D2C always gets created in the logged in user’s company, even in case of shared offerings

This will allow support users to quickly raise service requests on behalf of the consumers if required, instead of having to wait for the consumer to raise such requests.

• Now while creating or editing a catalog-based, standard change offering, support users will have the flexibility to configure AMS rules based on service or CI. The new workflow is as follows -

  CI: Upon clicking the ‘CI’ radio button, users would be able to select the required CI from all the deployed CIs and create the AMS rule accordingly.

  Service: Upon clicking ‘Service’ radio button, users would be able to select any service from all the deployed catalog-based standard changes and create the AMS rule accordingly.

  This will ensure that the workflows for standard change offerings are orchestrated to their correct groups based on the associated CI or service.

TMS Board

• The introduction of ‘Assigned to me’ and ‘Assigned to my groups’ filters on the ‘Tasks’ list view will accelerate the page upload time since the number of records being pulled up will be fewer with these filters in place. It will also allow users to focus on items that are assigned to him or to his groups as the search results will be relevant.

Incident Management

• Now upon making a change in the ‘Impact/Urgency’ field of an ‘Incident’ form, ‘Support Users’ will have to validate their credentials through the validation drop down to proceed with the changes. This will ensure that only assigned users can make these changes, while restricting other users.

• A new ‘Criticality’ column with the values ‘Yes’ and ‘No’ has been added on the ‘Work Item board’ of the incident page which are displayed only to the ‘Incident Manager’ and user with a ‘CIM’ role. This will help them to identify critical incidents based on the value populated in the ‘Criticality’ column.

• Now the status of incidents will have to be modified based on the client item number for incidents generated through monitoring system alerts.

  Incidents created through monitoring system alerts (like Moogsoft) are associated with a client item number (Situation key in case of Moogsoft). Once an alert is received, then following actions will have to be taken:

  • If the INC status = Submitted/In Progress/Pending → Activity Journal needs to be updated with the Alert

  • If the corresponding INC status = Fixed → Ticket needs to be reopened, Status change to ‘Submitted’, Activity Journal needs to be updated accordingly.

  • If the corresponding INC status = Closed/Cancelled → Fresh INC to be created

This will ensure that the incidents are updated according to the alerts generated by the monitoring tools.

Change Management

• Now, the rules have been applied to make the ‘Change Schedule’ and ‘Downtime Fields’ non-editable for any change if the change status is 'Under Implementation'. Also, users will no longer be able to ‘Start Implementation’ before the ‘Start Date’ provided in the ‘Expected Start Date’ field.

  This will ensure that there is no change in schedule once the change is initiated and thereby reducing the risks.

• Now there is an option to capture the implementation sub-status for a ‘Standard Change’ like ‘Successful’, ‘Partially Successful’, ‘Not Successful’ etc.

  Upon selecting the closure code and clicking on submit, the ‘Standard Change’ will be marked as 'Completed’ and the selected 'Closure Code' value will be displayed in the Activity Journal.

  This will help organizations to review, assess, evaluate the change for identifying any deviations and auditing at a later stage.

• The column filters ‘Change Mgt Group’ and ‘Implementation Group’ have been added in the ‘Change Module’ to narrow down the search results only to the changes that have been assigned to a particular group.

All processes

• The assignation rules for triggering email notifications have been enhanced as follows -

  • Mail notification triggered to an assigned individual when ticket is assigned

  • Mail notification triggered to requestor when status of the respective ticket has changed from ‘Submitted’ to ‘In Progress’

  • Mail notification triggered to requestor when status of the respective ticket has changed from ‘Pending’ to ‘In Progress’

With the configuration of these rules, notifications will be triggered appropriately and in a timely manner to the requestors and assignees to help them take the necessary actions at the right time.

• The UI has been improved to provide ease of access to work item applications and the activity journal.

  • The work item icon tray will now be available on the top right-hand side of the screen

  • The audit log and comments sections have been brought under a single window for ease of access    

These changes will enhance the user’s UX while working on a ticket. This will in turn pave the way for more productivity.

• The introduction of the filters- ‘Me’, ‘My Groups’ and ‘All’, on the Work Item Board for all modules will enable users to filter relevant items only, making tracking easy.

Fulfilment Module

• The introduction of the ‘On Hold’ value filter on the ‘Fulfilment Board’ will now allow ‘Support Users’ to navigate to the ‘Work Item Board’, and quickly identify the tickets that have been put on hold.

SLA Module

• Now upon making any change in the assignment group field of a ticket, the corresponding SLA will be paused instead of being cancelled.

• The menu options on the application menu for ‘Work Schedule’ and ‘Holiday Schedule’ has been removed as it is now available in the SLA module. This will simplify SLA configurations since all the associated workflows will be available in a single module.

Notifications

• Now upon posting any comment in the ‘Activity Detail’ section, notifications will be sent to the requester/fulfiller based on the ‘Internal Flag’ status and the value input in the ‘Assignee Field’ -

  • If ‘Internal Flag’ = ‘False’ and ‘Assignee’ field is left blank, then the notification will be sent to the requester/support users (separate calls) and fulfillment group members

  • If ‘Internal Flag’ = ‘True’ and ‘Assignee’ field is left blank, then the notification will be only sent to the fulfillment group members

  • If ‘Internal Flag’ = ‘True’ and ‘Assignee’ field is not left blank, then the notification will be only sent to the fulfillment group members

The fulfillment group will not be marked in Cc.

This provides a quick and intuitive mechanism to configure recipients based on the content posted in the ‘Activity Detail’ section.

• The label ‘Resolution Notes’ has been changed to ‘Notes’ in the templates given below as it contains the survey comments, rather than resolution notes.

  The 3 templates are:

  • Item Closed - Notify Assignment Group

  • Incident Closed - Notify Requestor

  • Incident Closed - Notify Assignment Group

This will help to improve the audit efficiency as the label will now identify the contents appropriately.

• Now upon problem ticket re-assignation to a new group, notifications will be auto triggered to ‘Requestor’ and new ‘Group’ if the ‘Assignee’ field is blank. However, if the field is populated the notification will only be sent to the ‘Assignee’. This flexibility to configure notification recipients for each ticket will ensure no communication is missed.

DRYiCE SX™ offers a unified marketplace for enterprise services fulfilled by best-in-class service management practices.

For product-related inquiries, please reach us at support.dryice.ai@hcl.com