SERENA® SERVICE MANAGER · Serena Service Manager comes packaged with fully functional, easy-to-use applications for incident, problem, change, and configuration management. Workflow

SERENA®SERVICE MANAGER

Getting Started Guide

Serena Proprietary and Confidential Information

Copyright © 2011-2016 Serena Software, Inc. All rights reserved.

This document, as well as the software described in it, is furnished under license and may be used or copied onlyin accordance with the terms of such license. Except as permitted by such license, no part of this publicationmay be reproduced, photocopied, stored in a retrieval system, or transmitted, in any form or by any means,electronic, mechanical, recording, or otherwise, without the prior written permission of Serena. Any reproductionof such software product user documentation, regardless of whether the documentation is reproduced in wholeor in part, must be accompanied by this copyright statement in its entirety, without modification. This documentcontains proprietary and confidential information, and no reproduction or dissemination of any informationcontained herein is allowed without the express permission of Serena Software.

The content of this document is furnished for informational use only, is subject to change without notice, andshould not be construed as a commitment by Serena. Serena assumes no responsibility or liability for any errorsor inaccuracies that may appear in this document.

License and copyright information for 3rd party software included in this release can be found on the product'snews page at http://support.serena.com/ProductNews/default.aspx and may also be found as part of thesoftware download available at http://support.serena.com.

Trademarks

Serena, Dimensions, ChangeMan, Comparex, and StarTool are registered trademarks of Serena Software, Inc.The Serena logo, PVCS, TeamTrack, License Manager and Composer are trademarks of Serena Software, Inc. Allother products or company names are used for identification purposes only, and may be trademarks of theirrespective owners.

U.S. Government Rights

Any Software product acquired by Licensee under this Agreement for or on behalf of the U.S. Government, itsagencies and instrumentalities is "commercial software" as defined by the FAR. Use, duplication, and disclosureby the U.S. Government is subject to the restrictions set forth in the license under which the Software wasacquired. The manufacturer is Serena Software, Inc., 1850 Gateway Drive, Suite 150, San Mateo, CA 94404.

Part number: Serena Service Manager 5.2.2

Publication date: 2016-10-06

2 Serena® Service Manager

Table of ContentsPart 1: Overview ................................................................................................9

Chapter 1: Welcome to Serena Service Manager ................................................ 11

About This Document .................................................................................... 11

Getting Help ................................................................................................ 11

Chapter 2: About Serena Service Manager ......................................................... 13

Additional Information ................................................................................. 14

Part 2: Concepts and Processes........................................................................... 15

Chapter 3: Process Apps Overview .................................................................. 17

Service Management Process Apps .................................................................. 17

Incident Management ................................................................................. 17

Incident Management Overview .................................................................. 18

1. Incident Creation .............................................................................. 18

2. Incident Classification and Initial Support ............................................. 19

3. Incident Investigation and Diagnosis...................................................... 21

4. Incident Resolution and Closure ............................................................ 22

5. Incident Monitoring and Communication ................................................ 24

6. Incident Reporting .............................................................................. 24

Incident Management Roles ..................................................................... 25

Problem Management ................................................................................. 26

Problem Management Overview .................................................................. 26

1. Problem Creation .............................................................................. 27

2. Problem Classification ........................................................................ 28

3. Problem Investigation and Diagnosis...................................................... 29

4. Problem Error Assessment .................................................................. 29

5. Known Errors .................................................................................... 30

6. Problem Resolution ........................................................................... 30

Problem Management Roles ..................................................................... 31

Change Management ................................................................................. 32

Change Management Overview .................................................................. 33

1. RFC Creation .................................................................................... 33

Getting Started Guide 3

2. RFC Classification .............................................................................. 34

3. RFC Impact Analysis ........................................................................... 35

4. RFC Assessment ................................................................................. 36

5. RFC Authorization .............................................................................. 37

6. RFC Implementation ........................................................................... 38

7. RFC Review and Closure ..................................................................... 38

Change Proposal Management Overview ...................................................... 39

Change Impact Analysis ........................................................................... 40

Risk Analysis Calculator ........................................................................... 42

Change Advisory Boards and Approvals ...................................................... 44

Change Management Roles ........................................................................ 45

Configuration Management System ............................................................... 46

Configuration Management Overview ......................................................... 46

1. Configuration Identification .................................................................. 47

About Relationships .............................................................................. 48

Creating CIs from Events ..................................................................... 51

Creating a Service as a CI ..................................................................... 51

2. Configuration Control........................................................................... 52

Understanding Baselines........................................................................ 53

3. Audit and Verification ........................................................................ 54

4. Status Accounting .............................................................................. 54

Configuration Management System Roles ................................................... 56

Asset Discovery Integrations ..................................................................... 56

Asset Management .................................................................................... 57

Asset Management Overview ..................................................................... 57

Asset Management Roles ........................................................................... 60

Asset Management Integrations .................................................................. 61

Service Request Process Apps ........................................................................ 62

Service Requests ....................................................................................... 63

Service Requests Overview ........................................................................ 64

1. Request Creation .............................................................................. 64


2. Request Classification and Initial Support ............................................. 64

3. Request Approvals .............................................................................. 65

4. Request Resolution and Support............................................................ 66

5. Request Monitoring and Communication ................................................ 67

Service Request Roles .............................................................................. 67

Knowledge Management .............................................................................. 68

Knowledge Management Roles .................................................................. 69

Starter Pack Forms - IT .............................................................................. 70

Starter Pack Service Requests by Category................................................... 71

Chapter 4: Serena Request Center Overview ...................................................... 85

About Request Center.................................................................................... 86

About Legacy Requests and Approvals ......................................................... 86

Service Catalog .......................................................................................... 87

Requests View .......................................................................................... 89

Approvals View .......................................................................................... 90

Knowledge Center ....................................................................................... 90

Using Knowledge Center Articles ............................................................... 91

Managing Knowledge Center Articles ......................................................... 92

Creating Announcements and Articles ...................................................... 93

Creating Urgent Announcements............................................................... 95

Reviewing Articles ................................................................................. 95

Publishing Knowledge Center Articles......................................................... 96

Updating Knowledge Center Articles ......................................................... 97

Deleting Knowledge Center Articles ......................................................... 97

Chapter 5: Serena Work Center Overview ......................................................... 99

Application Groups ....................................................................................... 99

Key Metrics ............................................................................................. 100

Service Management Views ..................................................................... 100

Incident Management Dashboards............................................................ 100

Problem Management Dashboards............................................................ 101

Change Management Dashboards ............................................................ 102


CMS Dashboard .................................................................................... 103

Service Requests Views ........................................................................... 103

Service Request Dashboards .................................................................. 103

Knowledge Dashboard ........................................................................... 104

Part 3: Installation and Configuration ............................................................... 105

Chapter 6: Getting Started ........................................................................... 107

Overview ................................................................................................ 107

Serena Service Manager Installer Components ............................................. 107

Pre-Installation Checklist ........................................................................... 109

Chapter 7: Installing Serena Service Manager ................................................ 111

Install Process Overview ........................................................................... 111

Running the Installer ................................................................................. 112

Chapter 8: Configuring Serena Service Manager ............................................. 113

Configuring the SLA Load Level .................................................................. 113

Accessing Serena Work Center..................................................................... 113

Chapter 9: Importing the Solutions ............................................................... 115

Troubleshooting Imports ........................................................................... 115

Chapter 10: Promoting the Snapshots ............................................................ 117

Promoting the Serena Request Center Snapshots .......................................... 118

Promoting the Serena Service Manager Snapshots.......................................... 120

Troubleshooting Promotions ........................................................................ 122

Chapter 11: Post-Installation Tasks ............................................................... 125

Updating Endpoints .................................................................................... 125

Preparing the System for Use ..................................................................... 126

Setting Authentication for Orchestrations ...................................................... 126

Part 4: Administration .................................................................................... 129

Chapter 12: Serena Service Manager ............................................................ 131

Preparing Applications for Use ..................................................................... 131

Adding Auxiliary Data to SSM Tables ......................................................... 131

Enabling Notifications .............................................................................. 132

Common Customizations ........................................................................... 135


Customizing the Process Apps .................................................................. 135

Customizing Asset Management............................................................... 135

Enabling the Service Requests Integration with Asset Management ............ 138

Importing Assets ................................................................................. 140

Customizing Change Management ............................................................ 140

Customizing Incident Management ......................................................... 143

Customizing Configuration Management ................................................... 143

Managing CI Types .............................................................................. 144

Associating an Icon with a CI Category ................................................... 144

General Modifications to Service Manager ................................................... 145

Chapter 13: Serena Request Center ............................................................... 147

Preparing Applications for Use ..................................................................... 147

Adding Auxiliary Data to Request Center Tables .......................................... 147

Enabling Notifications .............................................................................. 148

Configuring Request Center ........................................................................ 148

Configuring the Catalog View..................................................................... 148

Defining Category Containers .................................................................. 150

Defining Categories .............................................................................. 151

Defining Service Requests ..................................................................... 152

Defining Sections ................................................................................. 156

Adding Tabs to Request Center .................................................................. 158

Configuring the Knowledge View ............................................................... 160

Assigning Knowledge Center Privileges...................................................... 160

Creating Article Templates ..................................................................... 161

Managing Article Types ........................................................................... 163

Managing Categories .............................................................................. 163

Importing Articles ................................................................................. 164

Configuring the Requests View .................................................................. 166

Configuring the Approvals View.................................................................. 169

Customizing the Request Center Properties ................................................ 172

Using the Image Picker........................................................................... 173


Localizing Request Center Strings............................................................... 175

String Localization Categories .................................................................. 176

SLS and Design Object Strings ............................................................ 176

MLS Runtime Object Strings .................................................................. 178

Translating Strings................................................................................. 179

Translating Strings Using XML ............................................................... 179

Translating Strings in Application Administrator ....................................... 182

Promoting Translated Strings .................................................................. 182

Troubleshooting Localization .................................................................. 183

Troubleshooting Request Center .................................................................. 184

Chapter 14: Additional Information ............................................................... 185

Managing Users ....................................................................................... 185

Service Level Agreements ........................................................................... 189

About SLA Reports ................................................................................. 189

About the SLA Widget .............................................................................. 192

Defining SLAs .......................................................................................... 194

SLA Settings ....................................................................................... 196

SLA General Options ........................................................................... 197

SLA Clause Options .............................................................................. 198

SLA Clause General Options .................................................................. 199

SLA Clause Action Options .................................................................. 201

SLA Action Options .............................................................................. 201

General Features ....................................................................................... 203

State Forms .......................................................................................... 204

Transition Forms .................................................................................... 205

Custom Form Actions .............................................................................. 207

Modern Forms vs. Legacy Forms ............................................................... 208

Working Groups and Suggested Experts Panel ............................................. 208

Modifying Urgency, Impact, and Priority ...................................................... 209

Custom Help .......................................................................................... 211


Part 1: Overview

This section contains the following information:

• Chapter 1: Welcome to Serena Service Manager [page 11]

• Chapter 2: About Serena Service Manager [page 13]


Part 1: Overview


Chapter 1: Welcome to Serena ServiceManager

Service Manager is an orchestrated service management system powered by Serena®

Business Manager, also known as SBM. Available for deployment on your servers or in thecloud, Service Manager addresses the flexibility, visibility, and usability challengesinherent in traditional ITSM solutions.

Service Manager provides the following benefits:

• Lower total cost of ownership (TCO)

• Complete visibility and full audit trail

• Improved user satisfaction and agent productivity

• Contemporary interface for IT services

About This DocumentThis document describes Service Manager and explains how to install, configure, andadminister the system.

Service Manager users, such as change managers and service technicians, may find usefulinformation in Part 2: Concepts and Processes [page 15]. Online help is also available forthese users on each form in Service Manager, as discussed in Getting Help [page 11].

This document is organized into the following parts:

• Part 1: Overview [page 9]

Provides a brief overview of Service Manager.

• Part 2: Concepts and Processes [page 15]

Provides details about each process app included with Service Manager and SerenaRequest Center.

Information is also provided for the two end-user interfaces (Serena Request Centerand Serena Work Center).

• Part 3: Installation and Configuration [page 105]

Explains how to install and configure Service Manager.

• Part 4: Administration [page 129]

Provides administrators tasks to help you configure and maintain Service Manager.

Getting HelpAside from this document, Service Manager provides additional guidance for configuringand using this product.


Custom Online Help

Every Serena-provided solution that is powered by SBM includes end-user help that youcan customize to suit your needs. End-user help is added to solution design elements inSBM Composer, deployed as part of the solution, and shown to users as they work withitems at runtime.

For details, refer to the SBM Composer Guide or SBM Composer online help.

Documentation Center

Visit the Documentation Center for the most current documentation for Serena productsand solutions, along with an extensive documentation archive.

Support and Knowledgebase

The support site at http://www.serena.com/support provides an extensive, searchableKnowledgebase and other information about Serena products.

You must have a serena.com user account to view items in the Knowledgebase. Registerfor a free account if you do not have already have one.

User Forums

Visit the Serena User Forums to interact with other users and learn more about using ourproducts.

You can view and search for information, but you must create and log in to a forumaccount to respond to articles and interact with other users.

Part 1: Overview


http://help.serena.com/doc_center/doc_center.html

http://www.serena.com/support

http://central.serena.com/community/forums

Chapter 2: About Serena Service Manager

Service Manager includes:

• Process apps

• Serena Request Center

• Serena Work Center dashboards and views

Process AppsSerena Service Manager comes packaged with fully functional, easy-to-use applicationsfor incident, problem, change, and configuration management.

Workflow rules determine how an item should progress through each process and whethercertain criteria must be met before an action can be performed. These actions can beperformed automatically.

For example, workflow rules can be established to ensure that a configuration item (CI)has valid data. If these conditions are not met, an automated action can be launched onthe item, such as preventing the item from being transitioned to the next state.

Service Manager includes the complete tracking functionality of SBM, which enables youto track changes to every item. Each item is assigned a unique identifier after it is createdin SBM. Every activity is recorded, including field updates, transitions, and relationships,as the item moves through the workflow.

You can access this data by viewing the Change History of the item or by running reports.This data provides an audit trail for the item throughout its life cycle; you can use thisdata to improve your processes.

Multiple auxiliary tables are included that contain values that are used by selection fields.The values for these fields can be easily changed by modifying the auxiliary tables.

For details, refer to Chapter 3: Process Apps Overview [page 17].

Serena Request CenterRequest Center provides a one-stop Web portal for corporate users to request servicesand view requests they submitted or need to approve.

Request Center includes Knowledge Center for managing knowledge base articles andannouncements. Urgent announcements are displayed prominently below the RequestCenter banner, unless the announcement bar is disabled. Articles are organized bycategory to filter them for easier searching, and are assigned to visibility groups to controlwho can access them.

For details, refer to Chapter 4: Serena Request Center Overview [page 85].


Serena Work Center Dashboards and ViewsWork Center organizes Service Manager applications into application groups to streamlinehow your IT service team fulfills services requests, publishes articles to the KnowledgeCenter, and manages changes and configurations.

Work Center also provides the IT operations team with a set of dashboards and activityviews, enabling them to maintain complete visibility across the end-to-end servicedelivery process. This includes the ability to view actionable metrics related to costs andresource utilization.

For details, refer to Chapter 5: Serena Work Center Overview [page 99].

Additional InformationThe following sites contain additional information about ITIL standards.

• OGC Official ITIL® Website: http://www.itil-officialsite.com

• Wikipedia Article on IT Service Management: http://en.wikipedia.org/wiki/IT_Service_Management

• itSMF International - The IT Service Management Forum:http://www.itsmfi.org/

Part 1: Overview


http://www.itil-officialsite.com

http://en.wikipedia.org/wiki/IT_Service_Management

http://en.wikipedia.org/wiki/IT_Service_Management

http://www.itsmfi.org/

Part 2: Concepts and Processes


• Chapter 3: Process Apps Overview [page 17]

• Chapter 4: Serena Request Center Overview [page 85]

• Chapter 5: Serena Work Center Overview [page 99]




Chapter 3: Process Apps Overview

• Service Management Process Apps [page 17]

• Service Request Process Apps [page 62]

Service Management Process AppsThe Service Manager solution contains the following process apps:

• Incident Management

Refer to Incident Management [page 17].

• Problem Management

Refer to Problem Management [page 26].

• Change Management

Refer to Change Management [page 32].

• Configuration Management System (CMS)

Refer to Configuration Management Overview [page 46].

• Asset Management

Refer to Asset Management [page 57].

Incident Management

Incident Management focuses on restoring services to normal operation after serviceinterruptions as quickly as possible and with minimal impact to business operations, thusensuring that the best possible levels of service quality and availability are maintained.

The following topics explain the features of Incident Management in Serena ServiceManager.

• Incident Management Overview [page 18]

• Incident Management Roles [page 25]

Key Benefits

• Incident prioritization and classification based on ITIL standards.

• Graphical indicators for easier process visualization.

• Incident workflow that complies with ITSM best practices.

• Ability to relate existing Known Errors to new incidents.

• Ability to track first call resolution rates.


• Reporting dashboard to monitor possible problem areas and resolution rate.

Incident Management Overview

The incident management application addresses the following areas:

1. Incident Creation [page 18]

2. Incident Classification and Initial Support [page 19]

3. Incident Investigation and Diagnosis [page 21]

4. Incident Resolution and Closure [page 22]

5. Incident Monitoring and Communication [page 24]

6. Incident Reporting [page 24]

1. Incident Creation

Incident creation is known as submitting incidents in Serena Service Manager. Twoprimary actors responsible for submitting incidents are users and IT Service Desk staff.Users can submit their incidents using Request Center, Serena Work Center, or e-mail.

Most users assigned to Incident Management roles can submit incidents on their ownbehalf or on the behalf of another user. This enables service desk staff to submit incidentson behalf of their customers, for example. To submit an incident on behalf of anotheruser, search for and select that user from the Affected User field on the Submit form.

To disable the submit on behalf feature, refer to Disabling "Submit on Behalf" [page 143].

Incidents can also be submitted automatically from another application using Webservices. For example, if you have the Service Manager integration to MicrosoftOperations Manager, incidents will be submitted automatically when certain issues arise.

To create a new incident:

1. Click the +New icon located on the Work Center toolbar.

2. Click the Browse tab.

3. Search for or navigate to the project to submit into. The Incidents project isprovided as a default.

4. On the Submit form:

• Choose the Urgency and Impact. Priority is calculated automatically asdescribed in Modifying Urgency, Impact, and Priority [page 209], but the valuecan be overridden.

• Enter a Title and Description.

• Choose the Reported By user. If necessary, you can also select the AffectedUser and any other Additional Contacts.

5. Click OK to create the new incident.

Submitting Incidents Using E-mail

You can configure SBM to accept new incidents through e-mail.



Information on configuring SBM to handle e-mail submissions is available in the SBMApplication Administrator Guide.

Submitting Incidents from an Existing Incident

The Incident Management workflow has two methods for creating incidents from anotherincident. They are accessible under the More Actions menu.

• Copy Incident - Creates an identical copy of the existing incident.

• Post New Incident - Opens the submit form with the fields populated based on theexisting incident. The values can be edited in the new incident before you submit theitem.

2. Incident Classification and Initial Support

Incident classification includes setting priority, performing incident matching, and linkingincidents to configuration items. Initial support includes finding an existing workaround ormatching other existing errors.

In the Classification state, the Service Desk staff reviews the issue and determines howthe incident should be handled. The following actions may be available to you for updatingand routing the incident, depending on your role:

• Assign the incident, which automatically routes the item based on the answer toMajor Incident.

▪ If item is not a major incident, the issue is either assigned to the Level 1Technician for additional review, or to a group queue where the issue remainsuntil a member of the group takes ownership of it. It can also be assigned to botha technician and a group queue, which provides a backup if the technician cannotcomplete the work in a timely manner. (For information about group queues, seeGroup Queues [page 187].)

Note: The Level 1 Technician list includes users who are in the Level1 Tech, Level 2 Tech, and Level 3 Tech roles. This allows a Level 2 Techor Level 3 Tech to be assigned level 1 incidents if the technician isavailable.

▪ If item is a major incident, the incident is immediately escalated to theincident manager.

Note: Major incidents require the immediate attention of the incidentmanager. The incident manager may pull in the appropriate resourcesto quickly restore normal service operations. It may also require theincident manager to coordinate with problem management to find theroot cause of the major incident to prevent its recurrence.

• Resolve the incident, noting whether it was resolved on the first call.

• Update with additional information from the user.

The following options are available under the More Actions menu. They allow you todelete an incident, move the incident to another project, merge the incident with otherincidents, or create duplicate incidents.

• Remove Problem Link removes a problem link from the incident. The problem isnot deleted, only the relationship between the incident and the problem.


• Copy Incident creates a duplicate of the incident in the same state as the currentincident. You cannot modify the values when the item is created.

• Merge Incident ties the current incident to another existing incident using Parent/Child relationships. See Merging or Linking Incidents [page 20].

• Post New Incident creates another incident based on the current incident. You canmodify the values in the new incident on the Submit form; the new incident beginsat the start of the workflow.

• Delete Incident removes the incident from the system.

• Convert to Service Request moves the incident to the Service Requestsapplication. Files attached to the incident are added to the service request.

In the Classification state, users such as service desk staff can choose from thefollowing:

• Attach a file to an incident on the Notes/Attachments tab.

• Choose an action such as sending an e-mail from the More Actions menu.

When service desk staff updates or transitions the incident, they can modify data in theincident. The following describes the information to add in the fields, and how theinformation is used:

• The Request Type is usually set automatically during submit; however, techniciansmay be allowed to override the value.

• Choose the Urgency and Impact. Priority is calculated automatically as describedin Modifying Urgency, Impact, and Priority [page 209], but the value can beoverridden.

• Use the Caused by RFC(s) field to search for a Request for Change, or RFC, torelate to the incident.

• Search for a Configuration Item to relate to the incident. The configuration itemcategorizes the incident by automatically adding an incident category, incident sub-category, and incident sub-category type (if defined).

Note: Selecting a configuration item is important as the CI is used to showrelated CIs and to show links to existing problems.

• Choose the Reported By user from the list. If necessary, you can also select theAffected User and any other Additional Contacts.

• Choose a Level 1 Group that will own the issue until it is assigned to a technician.

• After selecting the Configuration Item, you can view other active incidents for that CIby displaying the Active Incidents tab.

Merging or Linking Incidents

Merging or linking incidents creates a parent/child relationship between the incidents thatyou are merging. The parent becomes the main item, which continues to move throughthe workflow as updates are performed. The children move to the Linked to Parentstate, indicating that they are no longer the main item. When users view the item, they



see a note across the top that says "This incident has been MERGED...." The parentissue is then displayed beneath the message.

When the parent is resolved, the children are automatically resolved as well. Theresolution notes from the parent are added to the children.

To merge incidents, select the Merge Incident action. On the Merge Details tab,choose whether the incident should become the child or parent:

• If you chose the incident to become the Parent:

1. Select the incidents to add as children and click OK.

2. The children will be moved to the Linked to Parent state.

3. The parent continues to move along the workflow.

4. When the parent is resolved, all children are automatically moved to theResolved state and the parent's resolution notes are added to each child.

• If you chose the incident to become the Child:

1. Select the parent to merge into and click OK.

2. The current incident will be moved to the Linked to Parent state while theparent moves along the workflow normally.

Note: When you view the child, you will see a note about the itembeing merged and the parent item. Details about the parent item aredisplayed on the Parent Incident tab of the child; details about thechild item are displayed on the Details and System tabs of the child.

3. When the parent is resolved, the incident is automatically moved to theResolved state and the parent's resolution notes are added to the incident.

Note: To unlink a child from a parent, click Unlink from Parent at the topof the child item.

3. Incident Investigation and Diagnosis

If the initial support fails to resolve the incident, the IT Service desk staff can transfer theincident to a Subject Matter Expert (SME). The SME investigates the incident, addsdetails, and, if possible, resolves the incident. Other options include escalating theincident to another SME or posting an RFC to the change management group.

The default incident management workflow contains three levels of support. Each level isassociated with a different user field as described below:

• Investigation and Diagnosis state – Level 1 Technician

• Investigation Queue state – Level 1 Group

• Escalated to L2 state – Level 2 Technician

Note: The Level 2 Technician list includes users who are in the Level 2Tech and Level 3 Tech roles. This allows a Level 3 Tech to be selected tohandle a lower level incident if the technician is available.

• L2 Escalation Queue state – Level 2 Group


• Escalated to L3 state – Level 3 Technician

• L3 Escalation Queue state – Level 3 Group

Depending on the state, the SME or technician can choose from the following actions:

• Resolve the incident, supplying how it was resolved and any other resolutiondetails.

• Escalate the incident to the next level; for example, escalate the issue from level 2to level 3.

• Post RFC to create a request for change from the incident. The incident moves tothe Pending Change state. It will return to the Investigation and Diagnosisstate after the related change is closed.

• Post Problem to either create a new problem or choose an existing problem (onlyavailable above level 2). To create a new problem, choose Create New Problemfrom the Problem Link list. To link to an existing problem, choose Link to anExisting Problem and search for the existing problem under Raised Problem. Thelinked problem appears on the Linked Problem tab. The link can be removed byselecting Remove Problem Link from the More Actions menu.

Tip: You can configure SBM to automatically assign the correct owner for eachstate. This improves the user experience by eliminating the need for them toselect the correct SME when escalating the incident.

From the "queue" states, individual technicians use the Assign action to assign theincident to themselves.

Similar to the Classification state, the investigation states provide the followingadditional actions:

• Reassign assigns the incident to another technician or moves it back into the groupqueue.

• Merge Incident ties the current incident to another existing incident using Parent/Child relationships. See Merging or Linking Incidents [page 20].

• Copy Incident creates a duplicate of the incident. You cannot modify the valueswhen the item is created.

• Post New Incident creates another incident based on the current incident. You canmodify the values on the Submit form for the new incident.

• Delete Incident removes the incident from the system.

• Convert to Service Request moves the incident to the Service Requestsapplication.

4. Incident Resolution and Closure

Incidents are resolved when service has been restored to normal. Incidents can beresolved in a variety of ways including attaching a Workaround or a Known Error. AWorkaround includes the steps on how to circumvent the problem. A Known Error is aproblem where there is no known fix. There might be a workaround for the Known Error.



When you resolve an incident, you can select a Known Error, a Workaround, or aKnowledge Center article as a solution.

Note:

• When the incident is resolved from the Classification state, it may bemarked as First Call Resolved. This data is used in reports, such asWeekly First Call Resolution Rate, to keep managers informed aboutwhich incidents are resolved with the first call.

• Users can automatically submit and then immediately resolve an incident ifa Knowledge Center article presented from the submit form addresses theirneeds. See Viewing Articles When You Submit a General Request orIncident [page 92] for more information.

The option to create a How To article in the Knowledge Center is available on theResolve transition. Select Yes to launch the Submit form into Knowledge Managementafter you complete the Resolve transition.

The content fields in the Knowledge Center article are automatically populated with thecontent from the incident. Select Load Article Template to clear the populatedinformation and replace it with the content from the template.

Restriction: You must have permissions to submit an item into KnowledgeManagement to create an article. For example, you could be a member of theContributors role in Knowledge Management.

In the Resolved list, select one of the following options:

• without Known Error enables you to enter the resolution details in the Resolutionfield.

• with Known Error and with Workaround enable you to search for existing knownerrors and their associated workarounds.

Tip: When you close the item with Known Error or with Workaround,you must select an active Problem or Known Error. A problem or errorcannot be selected if it is in the Closed state.

• with Knowledge Center Article enables you to search for and select a KnowledgeCenter article to associate with the incident. To search for the article, click SearchKnowledge Center and choose the relevant article from the results.

Depending on whether the incident was resolved with a workaround:

• If the incident was resolved without a workaround, it moves to the Resolved state,where it can be closed.

• If the incident was resolved with a workaround, it moves to the Resolved byWorkaround state. The incident remains in this state until the problem associatedwith the workaround is addressed. When the problem is closed, the incidentautomatically moves to the Resolved state.

From the Resolved state, a user can close the incident by selecting the Close transition.The Close transition launches a survey form, where users can rate their service deskexperience. The survey form has four selection fields and a text entry field for additionalcomments.


The completed incident moves to the Closed state, indicating that it is no longer active.The final incident displays a total Survey Score, which is a summation of the weightedvalues of Courtesy, Responsiveness, Technical Expertise, and Overall Satisfactionvalues. The default weightings for Courtesy, Responsiveness, and TechnicalExpertise are the selected values. Overall Satisfaction is weighted at ten times theselection, for example, a selection of 1 would be weighted as 10 for the Survey Score.

Tip: The Satisfaction Dashboard provides four reports to assist in monitoring theresponses to the satisfaction survey.

Administrators can change the weights by editing the fields in SBM Composer.

A second method of closing an incident from the Resolved state is the IT Closetransition. This transition is not available to users in the User or Contact roles. Thistransition does not include a survey form.

5. Incident Monitoring and Communication

Serena Service Manager has two main methods to monitor and communicate the status ofincidents: notifications and reporting.

The first method is through e-mail notifications, which inform users about the status ofincidents. Automated e-mail notifications can be configured to notify users of incidentcreation, incident transfers, incident resolutions, and incident closures.

For example, you can create a notification that automatically informs incident submittersthat they need to update their incident with more information. The submitters can eitherlog in to Serena Work Center using the link in the notification or reply to the e-mail toupdate their incident.

The notifications are tailored using notification rules and notification templates.Administrators are responsible for editing the notifications and creating the workflowrules. See the SBM Application Administrator Guide for more information.

If you allow users to subscribe to notifications, they can do so in their User Profile inWork Center.

For information on reporting, see 6. Incident Reporting [page 24].

6. Incident Reporting

In addition to the preconfigured reports that are included with Service Manager, you cancreate a variety of reports in SBM to track your incidents.

The following are some example reports:

• First Call Resolution

• Mean Time to Incident Resolution

• Number of Incidents SLA Breaches per Week

• Number of Incidents by Category

• Number of Escalations



You can also combine reports to create a dashboard or multi-view report like the onecreated for the Incident Management launch page (Incident Management Dashboards[page 100]).

Tip: You can create reports to perform keyword searches on auxiliary tables,such as the Workarounds table. To create this type of report, select to report onthe table and create a search filter with Title contains Query-at-runtime. Whenyou run the report, you will be prompted to enter your keyword search criteria,and the results will return each workaround that contains the search terms inthe title.

Incident Management Roles

The following roles (or actors) are used in the Incidents workflow.

Manager - This role is responsible for overseeing the flow of incidents through theworkflow. Other duties include:

• Ensure efficiency and effectiveness of the Incident Management process

• Manage incident management staff

• Provide for continuous service improvement for incident management

• Produce KPI reports for management review

• Maintain the incident management system

• Collaborate with other Service Manager processes such as Request Fulfillment,Problem Management, Change Management, and Configuration Management

Level 1 Tech - This role is for service desk staff or first level support who are responsiblefor handling incoming calls and e-mails. Other duties include:

• Own incidents from recording to closure

• Record, classify, and resolve incidents as quickly as possible

• Collaborate with users and technical SMEs to quickly restore normal serviceoperation

• Escalate incidents appropriately

• Keep users informed of incident status

• Ensure Service Level Agreements (SLAs) are met

• Match similar incidents

Level 2 Tech and Level 3 Tech - These roles are for technical SMEs and advancedsupport staff responsible for further incident investigation and diagnosis. Other dutiesinclude:

• Resolve incidents that were not resolved at first level support

• Escalate service level breaches to an incident manager

• Inform Service Desk staff of incident status and resolution


• Identify matching workaround

• Record new workaround

Note: The Incident Operators field includes all members in the Level 1 Techs,Level 2 Techs, and Level 3 Techs roles.

User - This role is for the users who will be submitting incidents, providing the necessarydetails to the Service Desk. This is the only role associated with the Affected User field.

Contact - This role is for users who should be available for selection in the AdditionalContacts field.

Administrator - This role is responsible for administering Incident Management, such asassigning users to roles or fixing SBM issues.

Problem Management

Problem Management is a deeper look into the causes of incidents. Problem Managementseeks to find a resolution to the root cause of a problem to minimize or prevent therecurrence of incidents caused by the problem. It seeks to identify known errors anddefine a resolution. This information can prevent service disruption in the future. ProactiveProblem Management helps your team decrease the number of incidents as trends areanalyzed and permanent fixes are implemented.

Problem Management works together with Incident Management and ChangeManagement to ensure that IT service availability and quality are increased. As permanentresolutions are found to fix known errors, Requests for Change (RFCs) can be raised tomake alterations to your IT process, applications, or infrastructure. As these RFCs areimplemented to resolve problems, related incidents are less likely to occur.

Problems can be related to incidents, changes, or solutions, giving your support desk theinformation that they need when they encounter similar issues. Known errors and theirresolutions are added to the Knowledge Center, where they can be accessed by thesupport team to help identify permanent solutions and speed up the resolution time forsimilar incidents. This results in less downtime and less disruption to business criticalsystems.

The following sections describe the Problem Management application:

• Problem Management Overview [page 26]

• Problem Management Roles [page 31]

Key Benefits

• Problem management for root cause analysis.

• Ability to relate existing Known Errors to new problems.

• Automatic recording of Known Errors.

• Auxiliary table to store Workarounds.

Problem Management Overview

The problem management application contains the following areas:



1. Problem Creation [page 27]

2. Problem Classification [page 28]

3. Problem Investigation and Diagnosis [page 29]

4. Problem Error Assessment [page 29]

5. Known Errors [page 30]

6. Problem Resolution [page 30]

1. Problem Creation

Creating a problem is known as submitting a problem in Service Manager. Problems maybe submitted directly by the Problem Management team or they may be spawned from anincident using the Post Problem transition in the Incident Management workflow.

The Submit form enables you to add the following information when creating a problem:

• A title and description for the problem

• Problem Status (development, production, or mixed)

• The urgency, impact, and priority of the problem. For details, see Modifying Urgency,Impact, and Priority [page 209].

• The primary configuration item (CI), problem category, sub-category, and sub-category type. The problem category fields will be populated based on the values inthe primary CI, but they can be modified. For details, see Configuration ManagementOverview [page 46].

• The user who reported the problem, the affected user, and additional contacts. TheReported By field is used when the submitter of the item is not the user affected bythe issue.

• Any work notes or attachments you want to include.

• Links to related incidents.

Note: When the problem is created from an incident using the Post Problemtransition, incident details are pre-populated in the Submit form.


To create a problem directly:



3. Search for or navigate to the project to submit into.

Note: You will only be allowed to submit into a project if you have theappropriate permissions.

4. Complete the Submit form with the necessary information.

5. Click Submit to create the new problem.

Tip: You can find the items that you submitted by using Search by Submitterfunctionality and searching for items submitted by Current User.

When the problem is created, it is assigned a unique item ID and moves to theClassification state, where it can be classified by problem management staff.

If you selected a CI for the problem, the Active Problems tab will show all activeproblems related to the particular CI and the CI Relationships tab will list all of therelationships for the particular CI.

2. Problem Classification

Problem classification involves the triage and assignment of the problem for moreinvestigation. After a problem is submitted, it moves to the Classification state, wherethe project management team can do one of the following:

• Start investigating the problem by assigning it to one of the following:

▪ A technical team, where the problem remains until a member of the team takesownership of it. In this scenario, the team members are secondary owners of theproblem; there is no primary owner. If a technical SME is also selected, he or shedoes not become the primary owner, but is automatically selected when theproblem is assigned.

▪ A technical SME, with no technical team members selected. In this scenario, thetechnical SME is the primary owner and there is no secondary owner.

▪ A technical SME, with technical team members selected. This provides a backup ifthe technical SME cannot complete the work in a timely manner, because thetechnical team members are secondary owners.

Note: You can use the Reassign transition in applicable states toassign the problem to another technical SME. For more informationabout group queues, see Group Queues [page 187].

• Update the problem with new information

• Put the item on hold

• Delete the problem (if the user has the "delete item" privilege)

• Add a file, item link, or URL to the item



• Choose an action such as sending an e-mail or adding a note

• Decide whether a tech note should be created when the problem is resolved.

Note: When you link items, the related incidents are linked to the item, and theitem is saved. The linked items are shown on the Incidents tab.

3. Problem Investigation and Diagnosis

The Investigation and Diagnosis state is where the technical SME investigates the rootcause of the problem. The Investigate transition from the Investigation Queue statelets you select the technical SME and the problem manager. It also lets you update theurgency, impact, and priority; attach supporting documentation, and add work notes forthe SME.

Note: If a problem is not routed directly to a technical SME after it is classified,it moves to the Investigation Queue state, where it remains until it isassigned to a technical SME.

The SME will use Serena Service Manager to diagnose and resolve the problem. The CMSapplication can be used to help determine the level of impact and assist in pinpointing thepoint of failure. The Known Errors will be accessed and checked to discover whether theproblem has occurred in the past and, if so, whether a resolution is already in place.Related problems should be checked to see whether similar problems have been raisedpreviously. Information in these tables is available through the Active Problems, CIRelationships, and Incidents tabs for the problem.

The result of an investigation for a problem will be a root cause diagnosis. The resolutionshould be the sum of the appropriate level of resources and skills used to find it.

After the cause of the problem is discovered, it is forwarded to the error control phase.The information discovered about the cause is entered in the Work Notes field.

In addition to entering a root cause, the SME can perform other actions from this state,including:

• Updating the problem with new information

• Putting the problem on hold

• Reassigning the problem to another SME

• Attaching a file to the problem

• Sending an e-mail from the problem

4. Problem Error Assessment

After the causes of a problem have been discovered, the problem goes into the errorcontrol phase, where a resolution to the known error is established. The Assessmentstate is where the SME logs the known error and describes a workaround.


The SME selects the Error Identified transition to log the known error and workaround.This transition allows the SME to add the details about the known error and what theworkaround would be in the Known Error Description field.

Note: The Error Identified transition changes the problem prefix to KE,signifying that it is a Known Error. Known Errors are described in the followingtopic.

After completing the Error Identified transition form, a Workaround submit form isdisplayed, where the SME can enter information about the workaround for the problem.Workarounds are submitted into the Workarounds auxiliary table. The items are linkedto the problem. This allows incidents that are linked to the problem to refer to theworkaround.

Note: You can avoid submitting the workaround at this point and add it in thenext state. To do so, click Cancel on the Submit form for the workaround.

In addition to transitioning the item and adding a workaround, the SME can perform thefollowing actions in the Assessment state:

• Update the problem with new information

• Put the problem on hold

• Reassigning the problem to another SME

• Attach a file to the problem

• Send an e-mail from the problem

5. Known Errors

In ITIL terminology, when the root cause of a problem is known and there is aworkaround, it becomes a known error. Serena Service Manager changes the problem to aKnown Error record automatically during the Error Identified transition.

The change from problem to known error is noted by the change of the Problem Typeprefix from PR to KE. This change allows users to easily discern problems from knownerrors when looking at a Problems report, such as the report that is displayed on theProblems tab for a configuration item. You can also create a report that searches only foritems that have a Problem Type of Known Error to help find possible solutions.

6. Problem Resolution

Problems can be resolved in a variety of ways. First, there may be a workaround to theproblem, explaining how to address the problem when it is encountered. Second, theproblem may be caused by an underlying problem in the system that needs to bechanged. A change needs to be made in the system at large to fix the root cause of theproblem. And third, the problem may have no solution. In this case, you may want tocreate a tech note in Knowledge Center to alert people about the problem.



These three approaches are not mutually exclusive; for example, there may be aworkaround but there may still be a problem in the system that needs to be resolved.

Tip: A good practice is to occasionally review all major problems to ensure thatthe correct steps were followed, how to improve the process overall, and how toprevent recurrence of similar incidents. The reporting functionality in SBM helpsto expedite this review process. You can create and share reports listing themajor problems that were recently closed, and then share the list with yourteam.

All of these approaches can be implemented from the Error Identified state in theproblem workflow.

• Workaround, which opens a Submit form into the Workaround auxiliary table.

• Post RFC, which opens the Submit form into the Changes workflow. This change islinked to the item. The problem moves into the Pending Change state. It will beautomatically transitioned back to the Error Identified state when the change iscompleted.

• Resolve, which moves the known error to the Resolved state, where it can bereassessed at a future time.

To create a tech note from the problem, select Yes in the Create Tech Note field.The Confirm transition then opens a submit form into Knowledge Management.

The content fields in the Knowledge Center article are automatically populated withthe content from the problem. Select Load Article Template to clear the populatedinformation and replace it with the content from the template.

Restriction: You must have permissions to submit an item into KnowledgeManagement to create an article. For example, you could be a member ofthe Contributors role in Knowledge Management.

Problem Management Roles

The following roles (or actors) are available in the Problem Management process app.

Manager – This role is responsible for ensuring the efficiency and effectiveness of theProblem Management process. Other duties include:

• Initiate proactive problem management initiatives

• Provide for continuous service improvement for problem management

• Monitor the quality and usefulness of problem records and known error information


• Maintain the problem management system

• Collaborate with other Service Manager processes such as Incident Management,Change Management, and Configuration Management

Specialist – This role is for technical SMEs and advanced support staff responsible forproblem investigation and diagnosis. Duties include:

• Perform investigation and diagnosis to determine the root cause of a problem


• Identify, record, and update known error records

• Identify incident trends that might be caused by a technical error

Staff – This role provides information to problem management staff as needed, includingtechnical and business related details.

Submitter – This role submits problems and provides incident details to problemmanagement staff.

Administrator – This role is responsible for administering Problem Management, such asassigning users to roles or addressing SBM issues.

Viewer – This role enables users to view problems and their history.

Change Management

Change Management helps ensure that standard methods and procedures are used forefficient and prompt handling of all changes to controlled IT infrastructure. This minimizesthe number and impact of any related incidents upon service operations after changes areimplemented.

Two distinct workflows enable you to track:

• Requests for Change (RFCs)

Use the Change Management to manage normal, standard, and emergency changes.For details, refer to Change Management Overview [page 33].

• Change Proposals

Use the Change Proposals workflow to manage proposals that need to be assessedand approved. You can create RFCs from proposals or link existing RFCs toproposals. For details, refer to Change Proposal Management Overview [page 39].

Change Management includes features that help you:

• Assess the potential impact that a proposed request for change (RFC) or proposalwould have on related services, consumers, and assets. For details, refer to 3. RFCImpact Analysis [page 35].

• Calculate how changes affect business critical services. For details, refer to RiskAnalysis Calculator [page 42].

• Provide your Change Advisory Board, or CAB, with full approval control and visibility.For details, refer to Change Advisory Boards and Approvals [page 44].

You can tailor both workflows to your specific business environment.

Key Benefits

• Flexibility in implementing tailored change management processes.

• Ability to determine the impact of a change on related services and assets.

• Full visibility and control into the change approval process.

• Ability to spawn Requests for Change (RFCs) from problems and incidents.

• Separate but integrated process for proposal management.



Change Management Overview

The Change Management workflow enables you to track Requests for Change (RFCs) fromcreation to closure.

1. RFC Creation [page 33]

2. RFC Classification [page 34]

3. RFC Impact Analysis [page 35]

4. RFC Assessment [page 36]

5. RFC Authorization [page 37]

6. RFC Implementation [page 38]

7. RFC Review and Closure [page 38]

1. RFC Creation

There are multiple methods for creating Requests for change (RFCs):

• You can submit RFCs directly into the Changes project of the Change Managementprocess app.

• You can create RFCs from problems, incidents, and configuration items (CIs).

Regardless of the creation method, the Submit form contains multiple fields and tabs toenter appropriate information, such as:

• Change Management Team members, who are secondary owners of the item until itis assigned to a change manager. (For information about group queues, see GroupQueues [page 187].)

• Change Title and Description

• Change Type

• Change Category

• Change Status (development, production, or mixed)

• Urgency, Impact, and Priority (For details, see Modifying Urgency, Impact, andPriority [page 209].)

• Primary CI

Note: When you select a primary CI on the submit form, a new baseline iscreated automatically in the Configuration Management System (CMS) forthe CI. For details, refer to Understanding Baselines [page 53].

• Affected CIs (For details, see 3. RFC Impact Analysis [page 35].)

• Contact Details

• Announce Change

• Risks

• Communication, Training, and Marketing Plans


• Implementation Plans

• Linked Incidents and Problems

To create an RFC directly:



3. Search for or navigate to the change management project to submit into.

Note: You will be allowed to submit into a project only if you have theappropriate permissions.

4. Complete the Submit form with the necessary information.

Note: You can modify the workflow to select which fields are mandatory ateach step of the process. For example, the default workflow requires thatthe submitter select a value for the Change Type and Priority fields.Your process may require the change manager to set these values whenassessing the RFC. You can modify the workflow accordingly.

5. Click Submit to create the new RFC.

When the RFC is created, it is assigned a unique item ID and moves to the ClassificationQueue state where change management team members are selected and then to theClassification state where the change manager determines how the change will beaddressed.

2. RFC Classification

After an RFC is created, it moves to the Classification Queue state, where it is assignedto a change manager. The change management team members selected when the RFC iscreated remain secondary owners, and can take ownership of the item if the changemanager cannot complete the work.

You can use the Reassign transition in applicable states to assign the RFC to anotherchange manager as needed.

Next, a preliminary assessment needs to be made of the RFC's importance. This occurs inthe Classification state.

All fields are available for editing when you act on an item in the Classification state.This allows the change manager to modify the proposed values for the Priority,Urgency, and Change Category fields. The change manager can provide or updateinformation that is critical for an accurate impact analysis of the RFC. In particular, thechange manager can modify the values in the Primary CI and Affected CIs fields andthe estimated Implementation Start Date and Implementation End Date.

The change manager must determine the type of RFC change. The Change Type valuecontrols the path the change follows through the workflow.

• Normal

Normal changes move through the entire workflow.

• Standard



In ITIL, "standard" changes refer to those changes that are commonly performed,such as password resets or user account provisioning. Standard changes are pre-approved and do not follow the normal approval process.

Standard changes also skip the assessment and authorization phases and movedirectly from the Classification state to impact analysis, which determines theimpact of the change on associated services and CIs. If the impact is minor, changesmove to the Approved Changes state; otherwise changes move to the CABReview/Planning state. (For more information, see 3. RFC Impact Analysis [page35].)

• Emergency

Emergency changes bypass the Assessment state and move directly to the ECAB(Emergency CAB), which is a subset of the CAB. ECAB is convened to handleemergency RFCs.

Emergency changes must be responded to immediately, and the procedure to befollowed in such cases must be planned for. Notifications are provided for notifyingECAB members when emergency changes have been submitted and when a changerequires an ECAB meeting.

From the Classification state, the change manager can choose from a variety of options,depending on the Change Type value:

• An RFC may be approved, which does not mean that it will subsequently beapproved by the CAB, only that it is sufficiently justified to be given furtherconsideration.

• An RFC may simply be rejected if it is felt that the change is not justified.

• An RFC may be deferred back to the originator, who can modify the item and thenre-open it after the change is defined more clearly.

• An RFC may need to be assessed further by the change manager before being sentto the CAB.

• A standard RFC can be implemented immediately without moving to the CAB, if theimpact analysis performed on it determines that it does not require CAB review.

Note: If the RFC was not submitted with linked items, the Linked Items tabdoes not appear on the Classification state form. The change manager mustclick Update to add linked items such as problems and incidents.

3. RFC Impact Analysis

The change manager should update the change item with pertinent data before it leavesthe Classification state. This ensures that the full impact of the RFC is taken into accountwhen the impact analysis is initially conducted.

Note: Data can be changed as needed throughout the process to adjust theimpact analysis results.

The impact analysis process involves the following steps:

1. Associate CIs with the change item. The Primary CI field stores CIs directly actedupon by the change request; the Affected CIs field stores CIs that could be


impacted by the change request. This step can be performed when the RFC issubmitted or classified, and then adjusted prior to the impact analysis.

2. Schedule the change by selecting an Implementation Start Date andImplementation End Date on the Implementation tab.

3. Generate the Impact Analysis Results [page 41] by clicking the Impact Analysistab.

4. Review the results. If there are warning icons in the results, rule out potentialtechnical problems before proceeding.

5. Approve the RFC by clicking the Approve button.

6. Make an initial evaluation of the impact by selecting an Impact Assessment valueon the Impact Analysis tab of the Approve transition form.

7. At this point, impact analysis routing is performed. If the RFC does not meet theapproval criteria described above, it moves to the CAB Review/Planning state soits impact can be formally reviewed. Otherwise, it moves to the Approved Changesstate.

Note: Standard changes normally skip the CAB Review/Planning state,but if they do not meet the approval criteria described above, they arerouted to this state anyway.

8. Make adjustments and then regenerate the impact analysis to see the new results.For example, you can try to change the implementation dates to reduce the impactto an acceptable level.

9. If the impact still does not meet the approval criteria, do one of the following:

• Approve the RFC, and on the Impact Analysis tab of the Approve transitionform, change the Impact Assessment value to Investigated but determinedinsignificant or Investigated, no action required.

• Keep the RFC in the CAB Review/Planning state by selecting one of the otherImpact Assessment options.

Use the Changes in Range (Impact Analysis) report to see the change items withconflicting implementation dates (that is, implementation dates that are in the samerange). You are prompted to provide query parameters based on implementation datesand the item ID before running this report.

CAUTION:

Do not modify this report.

4. RFC Assessment

A preliminary assessment occurs in the Classification state when the change managerdetermines the change type and where to route the change; however, a deeperassessment may be required. When this is the case, the change is routed to theAssessment state where a change manager can further assess the change.



When assessing the RFC, the change manager needs to set the appropriate values for thepriority and category. The Priority and Change Category values are important for theRFC process in ITIL. The priority determines the relative importance of the RFC in relationto other outstanding RFCs; it should be the main basis of when pending changes arescheduled. The change category determines the difficulty and impact of the RFC and willbe the main parameter used to determine the resources that need to be allocated. Thedefault Change Category values are:

• Minor

• Significant

• Major

Assessment also involves calculating the possible risk in implementing the change. TheRisk Calculator on the Risk tab automatically determines the risk based on the changecategory, estimated effort, and an array of survey questions. For more information, seeRisk Analysis Calculator [page 42].

Following assessment, the change manager accepts the RFC, and the RFC transitions tothe CAB for approval.

Note: Financial and Effort estimates are required for items that go through theAssessment phase.

5. RFC Authorization

RFCs require CAB approval in these cases:

• Normal RFCs

Once RFCs that are classified as normal changes reach the Assessment state, theymust be approved by the CAB.

• After Impact Analysis, RFC Does Not Meet Approval Criteria

After impact analysis is performed, any change that does not meet certain "approval"criteria is automatically routed to the CAB, which is responsible for evaluating thechanges and discussing the possible side effects of the change before it gives itsapproval. (See 3. RFC Impact Analysis [page 35] for more information.)

• Emergency Changes Need Approval

Change managers can choose to send emergency RFCs to an emergency CAB.

For details on the approval process, refer to Change Advisory Boards and Approvals [page44].

After the change is approved, it can be decided whether it should be implemented inisolation or as part of a package of changes that would be formally equivalent to a singlechange. The latter approach optimizes the use of resources, reduces the incompatibilitiesbetween different changes, and simplifies the back-out plan. Change managers can linkRFCs by creating a principle RFC and then grouping the RFCs using the subtaskingcapabilities of SBM.

Announcing a Change

You can announce RFCs to Knowledge Management after completing the Approvetransition from the CAB Review/Planning state.


When the Announce Change field is set to Yes, the Submit form into KnowledgeManagement will be displayed after completing the Approve transition.

The content for the new announcement is populated with information from the article. Thestart date for the announcement is specified in the Implementation Start Date field.

Select Load Article Template on the Content tab to clear the information that wasimported from the change. The content will be replaced with the template.

Restriction: You must have permissions to submit an item into KnowledgeManagement to create an article. For example, you could be a member of theContributors role in Knowledge Management.

6. RFC Implementation

The responsibility for implementing a change usually falls in the realm of theimplementation team; however, the Change Management team remains responsible foroverseeing and coordinating the implementation of the change. The Change Managementteam usually helps monitor that:

• Schedules are met and the appropriate resources are assigned.

• Software is developed and hardware is purchased according to specifications.

• The test environment is realistic and simulates the live environment.

• Back-out plans are created that will allow the last stable configuration to berecovered rapidly.

By default, the Implementation Team members must be selected when the change isapproved. The Implementer phase of the workflow contains only one state,Implementation, where the assigned implementer is the primary owner and theimplementation team is the secondary owner.

Note: The implementation team provides backup in case the implementercannot complete work. You can use the Update transition to assign the RFC toanother implementer. For more information, see Group Queues [page 187].

After the implementation is complete, the RFC moves to the Post ImplementationReview state, where the change manager conducts a review of the RFC before closing it.

7. RFC Review and Closure

After the implementation is complete, the RFC moves to the Post ImplementationReview state, where the change manager can review the change. This is known as a PostImplementation Review (PIR).

Note: By default, the change manager is notified when a change is transitionedto the Post Implementation Review state.

The review allows the real impact of the change on the organization's quality of serviceand productivity to be assessed. Some of the basic points to take into account are:

• Were the objectives met, and if necessary, were there any restrictions?

• Did the process deviate from the original plans?

• Were there any unexpected problems?



The PIR also verifies that all of the information related to the implementation is enteredinto the Change Record, such as the objectives, beginning and end dates, time and effort,cost, and lessons learned.

If the final evaluation finds the process and results are satisfactory and the informationwas entered in the RFC, the RFC can be closed using the Complete transition.

Items that raised the RFC are automatically transitioned to the next state when the RFC isclosed. For example, if the RFC was raised from a problem, the problem is moved to thePending Change state. When all of the RFCs are closed, the All RFCs Closed transitionis automatically performed, moving the problem back to the Assessment state.

Change Proposal Management Overview

The Change Proposal Management workflow enables you to track proposals that needevaluation before changes are made.

• 1. Proposal Creation [page 39]

• 2. Proposal Assessment [page 39]

• 3. Proposal Approval [page 40]

• 4. Proposal Implementation [page 40]

1. Proposal Creation

Change proposals are submitted into the Change Proposals project in the ChangeManagement process app.

The Submit form contains multiple fields and tabs to enter appropriate information, suchas:

• Change Manager and Change Management Team

• Change Title, Description, and Reason for Change

• Urgency, Impact, and Priority (For details, see Modifying Urgency, Impact, andPriority [page 209].)

• Primary CI

• Affected CIs (For details, see 3. RFC Impact Analysis [page 35].)

• Risks

• Communication, Training, and Marketing Plans

• Implementation and Backout Plans

The Change Type is always set to Change Proposal and the Change Category is always setto Significant.

When the Change Proposal is created, it is assigned a unique item ID and moves to theProposal Assessment state.

2. Proposal Assessment

During assessment, change managers select CAB members who need to approve theproposal.


The change manager must provide an estimated effort at this time, and can also providean estimated cost, implementation start and end days, and implementation and backoutplans.

Information provided when the proposal was submitted can also be changed. This includesthe urgency, impact, and priority, along with the reason for the proposal.

The change manager can also use the Risk Analysis Calculator on the Risk tab to assessthe risk associated with the proposal. For details, refer to Risk Analysis Calculator [page42].

Once a proposal is assessed, use the "Accept" transition to send the proposal to the CABfor approval.

At any time during the process, a proposal can be deferred or rejected.

3. Proposal Approval

Once a proposal is assessed, they typically require CAB approval. For details on theapproval process, refer to Change Advisory Boards and Approvals [page 44].

Assessed proposals are sent to the "Proposal Approved" state. Implementation start andend dates are required at this point.

Typically, the change manager will use the "Create New Change" transition to create RFCsfrom the proposal. Pertinent data from the proposal is copied to the change, and the RFCand proposal item are linked together.

Change managers can also use the "Link to Existing Change" transition to link existingRFCs to the proposal. In this case, data is not copied from the proposal to the change, butthe two items are linked together.

Once the CAB approves a proposal, the change manager uses the "Cab Complete"transition to send the proposal to the "Implementation" state.

4. Proposal Implementation

When a proposal is sent for implementation, an implementation team is selected. Thisteam is responsible for ensuring the RFCs linked to the proposal are implemented.

When all of the RFCs linked to a proposal are closed, the proposal automatically movesfrom the "Proposal Approved" state to the "Post Implementation Review" state.

After the implementation is reviewed, the proposal can be closed.

Change Impact Analysis

Impact analysis looks at the services, consumers, and assets affected by a change todetermine impact of a change on your organization. The handling of RFCs and proposalsdepend on their impact level and how change managers or CAB members assess theimpact.

The impact level is based on a combination of predefined thresholds and the analysisresult, which is calculated based on the number of affected services, consumers, assets,and detected conflicts and on the weights assigned to each of them. An implementationdate that coincides with another scheduled change is an example of a conflict.

The following table shows the impact levels based on the default thresholds.



Analysis Result Impact Level

Less than 15 Low

Greater than or equal to 15 and less than 30 Medium

Greater than or equal to 30 High

Note: The thresholds can be changed as described in Changing the ImpactLevel Threshold for Change Management [page 0].

The following Impact Assessment selections are available:

• Under Investigation

• Investigated but determined insignificant

• Investigated, no action required

• Investigated, rescheduling required

• Ignored

• (None)

Note: Ignored and (None) indicate that the change manager will not takefurther action based on the impact analysis results, even if that means the RFCwill not be approved.

If either the impact level is "Low" or the impact assessment is "Investigated butdetermined insignificant" or "Investigated, no action required," the RFC is approved andmoves to the Approved Changes state and continues through the rest of the workflow.Otherwise, the RFC moves to the CAB Review/Planning state for a formal review of theimpact.

Impact Analysis Results

The results shown on the Impact Analysis tab include the following information:

• Potential Impact. This section includes the CIs in the Affected CIs field. It isdivided into the following three lists, which display the ID, title, category, and stateof each CI.

▪ Affected Services. Service CIs, such as "IT Service" or "Business Service."

▪ Affected Consumers. CIs that model end-users or customers.

▪ Affected Configuration Items. CIs that represent IT assets, such asapplications or servers.

• Schedule Conflicts. This section lists other change items scheduled to beimplemented during the same period of time. It includes the ID, title,implementation start and end dates, and state of each change item.


• Related Activity. This section includes incidents and other change items that areassociated with the same services and CIs. It is divided into the following two lists,which display the ID, title, type, and state.

▪ Active Incidents against Affected Services and CIs. The items in theIncident Management application that have one or more of the same CIs in theAffected CIs field.

▪ Active Change Requests against Affected Services and CIs. Other changeitems that have one or more of the same CIs in the Affected CIs field.

• Analysis Result. This number is calculated based on the number of affectedservices, consumers, configuration items, and detected collisions; and the weightsassigned to each of them. It is updated automatically each time the report isgenerated.

Note: A warning icon indicates a collision. A collision is detected when otherchange items have the same implementation time as this RFC; or other changeitems associated with the same CIs were submitted, under review, or scheduledfor implementation.

The results also include the following fields that are populated after a formal impactanalysis review:

• Impact Assessment. The option that was selected during the review.

• Impact Assessment Date. The date and time the review took place.

• Impact Level (when reviewed). The level of impact when the review took place.

• Analysis Result (when reviewed). The analysis result that was calculated whenthe review took place. This can differ from the current, real-time value.

You can also use the Change Calendar Feed included in the Service Calendar to see activechanges by month, week, and day.

Risk Analysis Calculator

The Risk Analysis calculator determines how the change affects business critical services.It uses the change category, the estimated effort, and a group of questions to determinethe risk level of the change.

The Risk Analysis calculator appears on the Risk tab of an RFC. The risk level isdetermined to be either Low, Medium, or High based on the above criteria. The defaultranges are: Low is less than or equal to 20; Medium is 21 to 40; High is greater than40.

Note: Total Risk Score contains the summation of the weighted answers tothe survey.



On the Risk tab, the risk level is only displayed when the Risk Analysis Completed fieldis set to Yes. This ensures that users have answered the risk survey before calculatingthe risk level. If the risk survey has not been completed and Risk Analysis Completedremains set to No, the risk level displays Questionnaire Not Completed.

Tip: When creating a report to show high risk items, remember to include bothitems that have a high Total Risk Score and items that have a changecategory set as Major and their Risk Analysis Completed field set as No.Items without a completed risk survey will show a lower overall risk level sincethe risk level sums the survey responses and a null response is given a weightof zero.

The following are the default questions and weighted answers (default weights) in the RiskAnalysis questionnaire:

1. Does the change affect business-critical services?

• High Impact: Service temporarily unavailable / major changes (10)

• Low Impact: Small upgrade, some features temporarily unavailable (5)

• No Impact (0)

2. Does the change affect major IT infrastructure components?

• High Impact: Components taken offline / major service impact (10)

• Minor upgrade or temporary performance degradation (5)

• No Impact (0)

3. Will the change be tested prior to implementation in a development or testenvironment?

• Yes (3)

• No (7)

4. Is the implementation well understood and documented?

• This process has been done in the past and is repeatable (0)

• This process is similar to one done in the past (5)

• This is a completely new process or implementation (10)

5. What is the implementation time? (This field is set automatically based on thevalue entered in the Estimated Effort field for the change request. It can also bemanually modified by choosing a selection in the list. The Estimated Effort fieldappears on the Implementation tab for a change request. This tab appears whenapproving a change.)

• 4 hrs or less (0)

• 4 hrs to less than 1 day (5)

• More than 1 day (10)

6. What is the change complexity? (This field is set automatically based on thevalue of the Change Category field.)


• Minor (0)

• Significant (5)

• Major (10)

Change Advisory Boards and Approvals

Information management systems are highly sensitive to configuration changes due to thecomplex relationships between all the CIs involved. An apparently minor change couldtrigger a chain reaction with catastrophic results.

The Change Management process app enables approval boards to review and approvemost changes. Each advisory board member can approve or reject changes and canprovide written feedback for each RFC and proposal.

For details on the approval process for RFCs and proposals, refer to:

• 5. RFC Authorization [page 37]

• 3. Proposal Approval [page 40]

About CABs and ECABs

The Change Advisory Board, or CAB, is usually chaired by a change manager and itsmembers include other service management managers. The CAB may also include otherstakeholders such as customers or other third-party providers.

In the case of high impact changes, upper management may need to be consulted asstrategic issues and the organization's general policy may come into play.

The CAB typically meets regularly to analyze and approve the pending proposals and mostRFCs. CAB members discuss the benefits of changes and verify that a back-out planexists. They decide when changes should be implemented, assess the effort, and assessthe cost. The CAB also discusses possible risks, services that are affected, impacts tobusiness continuity, and disaster recovery.

Emergency Change Advisory Boards, or ECABS, can be convened to discuss and approveemergency RFCs as needed. Emergency RFCs follow a streamlined process that enablesyour organization to react quickly, but with control and visibility. Provided notificationsalert ECAB members about emergency RFCs and the "All Open Emergency Changes"reports provides visibility into emergency RFCs that need to be addressed.

The results and decisions of CAB and ECAB discussions are collected and entered in eachchange. Details can be entered directly into the change or attached as supportingdocumentation using Add File.

About the Approval Process

The approval process is similar for RFCs and proposals.

Both processes require that CAB members selected during the assessment phase approve,reject, or suggest delaying the change. Emergency RFCs can be sent directly to the ECABonce they are submitted.

CAB and ECAB members use the "Add CAB Comment" to register their decision andprovide a comment.

Depending on the approval results:



• The change manager uses the "CAB complete" transition to move to change the"Implementation" state if all members approve.

• The change manager can override approval if the vote results differ or if CAB orECAB members are unavailable to approve the change.

• The change can be rejected.

• Non-emergency RFCs and proposals can be deferred.

Change Management Roles

The following roles (or actors) are available in the Change Management process app.

Note: Users should be assigned to these roles in the Change Management andChange Proposal Management projects.

Adviser - This role is intended for members of the Change Advisory and EmergencyChange Advisory boards.

• Assess and approve RFCs and proposals

• Approve emergency RFCs

Manager - This role ensures that standard procedures for change are followed. Otherduties include:

• Ensure efficiency and effectiveness of the Change Management process

• Manage change management staff

• Provide for continuous service improvement for change management

• Conduct impact analysis on proposed changes

• Schedule regular configuration item (CI) verification and audits


• Manage Forward Schedule of Change conflicts

• Conduct the Change Advisory Board (CAB) meetings on a regular basis

• Maintain the change management system

• Collaborate with other ITSM processes such as Problem Management, IssueManagement, and Configuration Management

Implementer - This role is for change management staff who are responsible forimplementing the change. Other duties include:

• Own requests from implementation to closure

• Ensure that prior approval has been granted before executing the change

• Collaborate with requesters to implement the requested change

• Inform change management staff of request status and resolution


• Coordinate with release management staff to ensure that processes are followed

• Provide post-implementation feedback during PIR (Post Implementation Review)

Requester - This role is for the users who will submit RFCs, providing the necessarydetails to the change implementers.

Administrator - This role is responsible for administering the Change Managementprocess app, such as assigning users to roles or fixing SBM issues.

Configuration Management System

The Configuration Management System (CMS) process oversees the life cycle ofConfiguration Items (CIs) through the fundamental elements of identification, statusaccounting, and audit. From initial activation to final deactivation, the CMS processenables you to track your IT Assets.

The CMS application contains the Relationship Explorer, which is used to store relationshipinformation between your CIs. This information allows you to see how items relate to eachother, and how dependencies among items affect your IT services.

• Configuration Management Overview [page 46]

• Configuration Management System Roles [page 56]

• Asset Discovery Integrations [page 56]

Key Benefits

• Configuration Management Database with CI categorization according to ITIL.

• Management of complete Configuration Item life cycle.

• Ability to create relationships between CIs and view relationships in a graphicalformat.

• Links between CIs and other items (such as Incidents, Problems, or Changes) forquick problem diagnosis and change control of assets.

• Ability to create a high-level service CI that can be associated with any servicerequest so that services can be accurately and efficiently captured and reported.

• Ability to give a CI a "consumer" type so the effect of a proposed change on end-users can be taken into account when impact analysis is performed in the ChangeManagement application.

• Ability to integrate with external asset discovery systems that detect changes to yourIT assets.

• Ability to integrate with the Asset Management process app, which tracks financialinformation about your assets.

Configuration Management Overview

The configuration management application contains the following areas:

1. Configuration Identification [page 47]



2. Configuration Control [page 52]

3. Audit and Verification [page 54]

4. Status Accounting [page 54]

1. Configuration Identification

Creating and identifying Configuration Items (CIs) is the process in which new items aredefined and added to the Configuration Management database. After an item has beenadded, it can be tracked and managed through its workflow. This enables you to performthe necessary audits using the reporting capability found in SBM.

New items can either be created automatically based on an event raised from another toolor manually from within SBM. Other tools that can be configured to raise events includeother asset management systems or asset discovery systems. New items may need to becreated from within SBM based on a Request for Change (RFC), Service Request for newhardware, or the results of an audit where items that do not exist in the system werediscovered.

Note: Raising and receiving events within SBM requires knowledge of Webservices and SBM orchestrations. If you do not have in-house expertise, contactSerena Professional Services, which can help you modify your Service Managerimplementation to communicate with third-party tools.

When you create or classify a CI, some fields have predefined values that are available inlists on the Submit form. These values create consistency among your configurationitems, which in turn helps when searching for existing configuration items to relate to anincident or problem. In addition, this consistency improves audit and report results formanaging your configuration items.

By default, predefined values can be selected for the following fields. CI Type, Status(development, production, mixed), Category, Sub-Category, and Sub-Category Typefields. Note that the Sub-Category and Sub-Category Type fields are relational fields,which means that you must select a value in the related field before they are populatedwith values. For example, you must select a Category before values appear in the Sub-Category list, and when you select a Sub-Category, the Sub-Category Type list ispopulated.

Tip: Some selection lists are populated from auxiliary tables, such as Categoryand Sub-Category. If you have permission to edit a table, you can add or modifyselections by selecting , navigating to the auxiliary table (Search | ManageData), or using an Editable Grid report run against the auxiliary table.

Some of the fields in CI items are free-form text fields, which allow flexibility whendefining items. Examples of these fields are CI Name, Description, MaintenanceWindow, Manufacturer, and Serial Number. For CI items with software attributes, theDML Link field allows you to include a link to your Definitive Media Library, where yoursoftware components are stored and protected.


After you complete the submit process by clicking Submit on the submit form, the CI iscreated. It is assigned a unique identification number and then moves to theClassification state, where it is assigned to a Configuration Analyst. The analyst canchoose how to proceed with the item. The analyst could choose to modify the CI byselecting to Update the item, and then entering appropriate values for the item. If the CIis ready to activate or publish, the analyst clicks Activate. The configuration item is nowlive in the system, and it resides in the Active state in SBM until it is audited, inactivated,or disposed.

Note: Functional and access privileges to configuration items are role-basedand your role is defined by your administrator. Depending on your privileges,you may not be able to create new items, update items, or add relationships toitems. Field attributes may also be classified, and access to each dataclassification can be granted according to your role. The right to transitionchanges from one state to another can also be controlled by the role privileges.

About Relationships

Service Manager stores not only your configuration items (CIs), but the relationshipsbetween them as well. Knowing about these relationships helps you understand whatcould happen when an asset is modified. For example, your company's internal Wiki canbe hosted on server A. A change to Server A could affect the Wiki.

Constraints can be defined to prevent relationships that do not make sense, such as"Server runs on Software," from being created. An administrator can select which parentand child CI types are allowed for each relationship type. Validation checks ensure thatthe constraints are enforced when a relationship is submitted or updated.

Note: No constraints are enforced if no parent and child CI types are selected,or if all of them are selected.

In addition, relationships can be used to group CIs under one main CI. For example, an ITservice such as the ERP application can be defined as a CI, which is made up of anapplication, database, server, and network components to provide that IT service.



The Relationship Explorer displays relationships between active CIs. It graphically depictsthe relationships between the currently displayed item and other items. You can viewinformation about the related items from the graph. The Relationship Explorer is on theRelationships tab for an active configuration item, and on the CI Relationships tab foritems in the Incident, Problem, and Changes applications.

Important: When a new version of CI replaces an existing CI, the relationshipsare automatically transferred to the new version of the item.

Note:

• The arrows in the Relationship Explorer point from the primary (parent) CIto the related (child) CI. The primary CI is the item that was specified assuch when creating the relationship. By default, the item from which youare creating the relationship is considered the primary CI.

• By default, the Visualize check box is selected when you add a newrelationship type. If this check box is cleared, CIs that are related by thisrelationship type do not appear in the Relationship Explorer.

• The Relationship Explorer requires the Adobe Flash Player. If the FlashPlayer is not installed or enabled for your browser, you are prompted toinstall or enable it when click the Relationships tab. In addition, youradministrator may disable Flash-based features, which will prevent youfrom using the Relationship Explorer.

Navigating Relationships

The Relationship Explorer displays the relationships between CIs in a tree format. Theselected CI is the primary CI and has a red border. The parent of the primary CI is alwaysshown. By default, five levels of children from the primary CI are shown. Each CI isrepresented by an icon that is associated with the CI category (for details, see Associatingan Icon with a CI Category [page 144]).

You can do the following to navigate relationships:

• Display the details of a CI:

▪ Point your mouse over its icon to see its category, name, and type.

▪ Right-click its icon and then select Show Details to open the Item Detailswindow. The values of fields from the Details tab on the CI item are displayed.

The Related items section at the bottom of the Item Details window containslinks to reports containing the Incidents, Changes, and Problems items that areassociated with this CI.

Note: These reports match the default reports shown on the RFCs,Incidents, and Problems tabs on a CI item. The default reports willopen from this window, even if the tabs were modified to point to adifferent report.

▪ Click its title to open the CI in another window.

• Focus the graph on another item by clicking its icon. This centers the graph on that

item. To restore the original focus, click .


• Change the number of child relationship levels to display by moving the Levelsslider.

• Show or hide labels on the arrows in the graph by selecting or clearing the Showlabels check box. The labels indicate the type of relationship that two connected CIsshare.

• Change the zoom on the graph:

▪ Click the Original size icon to restore the graph to its default size.

▪ Click the Zoom out icon to make the items in the graph smaller. This is usefulwhen the graph is large because it lets you see more items.

▪ Move the slider to adjust the zoom from 20% to 200%. Click the Zoom out iconto adjust the zoom smaller than 20%.

▪ Click the Zoom in icon to make the items in the graph larger.

▪ Click Fit to view to resize the graph so that all items fit in the current window.

• Open the graph in another window by clicking the Open in new window icon.

• Toggle the orientation of the graph by moving the slider to Horizontal or Vertical.

Adding a Relationship

1. Open the active CI.

2. Click the Relationships tab and then click Add New Relationship.

3. A Submit form to the Relationships auxiliary table in the CMS process app isdisplayed. The current CI is automatically selected as the Primary CI.

4. Select the Relationship Type and the Related CI.

5. Click OK to submit the form.

After the relationship is added, it appears on the Relationships tab on the CI item.

Removing or Modifying a Relationship

1. Open the active CI.

2. Click the Relationships tab.

3. If necessary, expand the Relationship Maintenance section. A report containingthe primary relationships associated with the CI is displayed.

4. In the report, click the relationship you want to modify or delete. The relationshipopens in a new window.

5. Use the applicable options to Update or Delete the relationship.

Adding, Updating, or Deleting a Relationship Type

1. Open the Relationship Types auxiliary table in the CMS process app by clickingManage Data in the Search pane or by running a report against it.



2. Use the applicable options to add, update, or delete a relationship type.

Note: If you select no values or all values in the Parent Types Allowedand Child Types Allowed fields, then any relationship can be defined,even one that does not make sense, such as "Laptop runs on Document."

Creating CIs from Events

When the Service Manager connector issues an event, the event triggers the creation of aconfiguration item.

The submission from the connector populates the new CI with specific information thatallows it to be automatically routed to the Active state, bypassing the Classificationstate.

Note: Any submission that is populated with this information is automaticallyrouted to the Active state; items that are submitted manually are routed to theClassification state.

Creating a Service as a CI

A service CI is a the highest level of CI and is visible throughout the CI hierarchy down tothe individual request. It can be used to capture and report details about services beingoffered; report on the content of the Service Request Catalog in Serena Request Center;and review volume, usage, and compliance information about Service Level Agreements(SLAs) that are associated with the services.

A service CI has a SERVICE ATTRIBUTES section containing the fields that are required forITIL certification. The following fields are exceptions because existing CI fields serve thesame purpose:

ITIL Certification Field Comparable CI Field

Service name Name

Service description Description

Service status Status, State

Service classification andcriticality

Type, Category, Sub-Category, Sub-CategoryType


To create or update a service CI, select a service type in the Type field. Two service typesare provided by default: IT Service and Business Service. "Network Management" and"Access and Permissions" are examples of IT services; "Payroll" and "Finance" areexamples of business services.

After an administrator associates a service CI with a service request in Request Center,requests submitted into that service request from Request Center are automaticallyassociated with that service CI and are displayed in the Service Affected field on stateforms. The association can be changed when a request is updated.

Note: An administrator can also associate a service CI with a service request atthe project level in SBM Application Administrator by setting a default value forthe Service Affected field for the Submit transition. This will be the initial valuefor all requests submitted into that project, unless an administrator used SRC toassociate another service CI with that service request. In this case, there is nodefault value for the Service Affected fields for requests submitted throughRequest Center.

2. Configuration Control

Configuration Management has a set of processes and approvals that are required tochange a configuration item's attributes. ITIL best practices recommend that changes toCIs require an RFC. The default Service Manager configuration enforces the need of anRFC for certain changes to the CI. The RFC captures the details of the change and ismanaged by the Changes workflow, which enforces the collection of appropriate approvalsand tracks the implementation steps.

The management of CIs can span across other process teams in addition to theConfiguration Management team. For example, before an RFC is implemented, theattributes of the associated CI may need to be validated against the RFC by the ChangeManagement team. After the change is implemented, the validation can be repeated bythe Configuration Management team to ensure consistency.

After a non-emergency RFC has been approved and the changes have been made, abaseline is automatically created for the existing CI and changed information is recorded.For emergency RFCs, change mangers can manually create a baseline after the RFC isimplemented. For details, refer to Understanding Baselines [page 53].

Note: Updating from an RFC is different from using the Update transition onthe CI directly. The Update transition prevents modification of some fields suchas version number. These fields can only be modified using an RFC.

The ability to create, manage, and update CIs and their attributes depends on howadministrators assign roles within Configuration Management. Access privileges may grantread-only access for some roles, but update privileges for other roles. Data attributes canalso be classified, and access to each data classification can be granted through the role.The right to transition changes from one state to another can also be controlled by therole privileges. Details of the roles in Configuration Management are described inConfiguration Management System Roles [page 56].

Administrators can manage the workflow of CIs by determining owners for each state.They can also set rules that determine who the owner will be based on the CI attributes;this automates the workflow by automatically assigning items to the correct owner.

The fields that contain the CI attributes can be configured to be required or optional. Youcan fine-tune the requirements by marking the field as mandatory throughout the life



cycle of a configuration item (CI) or only for certain transitions from one state to another.Field settings are customized using SBM Composer.

Understanding Baselines

Baselines identify the significant states within the revision history of a configuration item.They capture the changes that were approved and implemented for a particular version ofan item. By comparing the active item with its previous baselines, you can view themodifications that occurred between CI versions.

Service Manager uses separate items in the CMS workflow to track active CIs andbaselines. The state of the item in CMS workflow determines whether the item is an activeCI, an active baseline, or an inactive baseline. Links exist between baselines and activeCIs, which allows Service Manager to track the baselines associated with each active CI.

The complete process for creating a new active CI and baseline using a non-emergencyRFC is as follows:

1. RFCs are required for a change to a CI. When you submit an RFC against an activeCI, a new CI is also submitted. The new CI is placed in the Pending Change state,where it remains until the change is completed. The new CI is linked to the active ororiginal CI, and it is pre-populated with information from the existing CI. You canfind a link to an active CI from the new CI on the Details tab. You will see that theversion number was automatically incremented on the new CI.

2. The original CI moves to the Baseline Pending state, informing you that a new CIis in the process of being implemented.

3. After the RFC is closed, the new CI moves to the Verification Required state,where the change is verified by the Configuration Analyst to ensure that it matcheswhat was expected.

4. After being verified, the new CI becomes the active CI. The original CI transitionsfrom the Pending Change state to the Active Baselines state, marking it as abaseline. Active baselines appear on the Baselines tab.

5. A baseline can replace the active CI by selecting to Restore it. This creates an RFCand a duplicate of the baseline item. After the RFC is completed, the duplicate itemwill become the new active CI.

In summary, an item in the CMS workflow can have the following possible designations asit moves through the workflow:

• An Active CI is the current version of the CI.

• A Pending Change is an item that is waiting for an RFC to be completed before itbecomes the active CI.

• An Active Baseline is a non-current version of the CI that is in the ActiveBaselines state. You can see the active CI on the Details tab. (When you areviewing an active baseline, the report on the Baselines tab is empty.)

• An Inactive Baseline is a version of the CI that has been deactivated. Deactivatedbaselines do not appear on the Baselines tab. You can find inactive baselines byrunning a report against the CMS project that contains the baseline items.Remember to include inactive items in your report.


Note that all opened RFCs must be closed before the CI will transition to the next state.That is, if you have multiple RFCs open for one CI, all of them must be closed before theCI becomes the new active CI.

Note: Baselines are not created for a CI related to an emergency RFC until theRFC is closed.

3. Audit and Verification

Audit and verification checks for the existence and accuracy of information contained inthe Configuration Management Database (CMDB) against the actual asset. If anyexceptions are found, the CMDB has to be updated appropriately.

In Service Manager, a Configuration Analyst can audit an item by selecting the Audittransition and adding any applicable Work Notes. The CI moves to the Audit state, whereit is verified. If a discrepancy is found or a change is required, the Configuration Analystcan choose from a variety of transitions to determine what will happen to the CI:

• Verify – Marks the CI as verified against the actual asset, returning the CI to theActive state.

• Not Found – Marks an item as not found.

• Remove – Marks an item as disposed or inactive.

• Post RFC – Raises a Request for Change to fix an issue or exception found duringthe audit.

Note: Service Manager supports the process of auditing and verification, but theactual act of auditing or verifying a CI has to be performed by a member of theConfiguration Management team.

CIs, their versions, and their changes form the basis of any configuration audit, and SBMenables you to create and run reports on these items. Service Manager provides defaultreports, and users can create additional reports in Serena Work Center.

Some of the default reports follow:

• Configuration Items by State

• Configuration Items by Type

• Missing Configuration Items

• All Laptops

• All Servers

4. Status Accounting

Status accounting for CIs refers to the ability to record and report on the status of all CIsthat are under control of the Configuration Management System (CMS).

Any activity performed on the CI from creation to disposal is recorded, providing an audittrail throughout its life cycle. Records are marked with the activity date and ID of theindividual who performed the action. This means that you can see who updated items,performed transitions, or added relationships to a particular item, and when thesetransactions occurred.



Status information is used for successful audits by the Configuration Management team,which needs to see the current status of CIs. Service Manager provides many defaultreports that the Service Management team can use to find the status of CIs. In addition,custom reports can easily be created to display required information.

Status information could also be needed by other service management processes, such asChange Management and Problem Management, to relate new RFCs, problems, andworkarounds to particular CIs. Other Service Manager processes link directly to theConfiguration Management application, enabling you to find CI information from within thecontext of the other process. For example, the Incident Management, ProblemManagement, and Change Management processes require you to choose a CI to relate tothe new issue. This can be done directly from the form using the relational field searchbox.

SBM reports are important for keeping up-to-date on your configuration status. Statusreports that include the following should be produced on a regular basis:

• Lists of all CIs under control, their current version, and change history

• Status accounting reports on the current, previous, and planned states

• Unique identifiers of constituent CIs and their current status

• Configuration baselines, releases, and their status

• Latest software item versions and their status for a system baseline

• Persons responsible for making status changes

• Change history and audit trail

• Open Problems and RFCs

Status accounting reports can be used to establish system baselines and to trace changesbetween baselines and releases. Status reports could include:

• Baseline and release identifiers

• Latest software versions associated with each build

• The number of changes for a system

• The number of baselines and releases

• The usage and volatility of CIs

• Comparisons of baselines and releases

In addition to reports, notifications can be created to inform IT staff about CI changes.SBM enables users to subscribe to notifications for changes to a CI, such as a statetransition or an update. Service Manager comes with default notifications. Additionalnotifications can be created and configured using SBM Application Administrator. Forexample, you may be responsible for your production servers, and you want to be notifiedwhenever a CI item related to servers is updated. Your administrator can create anotification that looks for certain conditions, such as updates on items related toproduction servers, and then sends an e-mail notification when the event occurs. Userscan subscribe to any notification to which they have access by configuring the notificationsin their User Profile in Serena Work Center.


Configuration Management System Roles

The following roles (or actors) are available in the Configuration Management Systemprocess app.

Manager - This role is responsible for the Configuration Management System and the CIRelationships. Duties include:

• Ensure efficiency and effectiveness of the Configuration Management process

• Define Configuration Management policy and scope

• Promote continuous service improvement for Configuration Management


• Schedule regular CI verification and audits

• Maintain the Configuration Management System

• Monitor the quality of the CI records and their usefulness to the other ServiceManager processes, especially Incident Management, Problem Management, ChangeManagement, and Release Management

• Monitor the quality of CI information, including CI-to-CI relationships

• Develop methods and procedures for populating the CMDB

Analyst - This role is responsible for monitoring CI records. Duties include:

• Coordinate Configuration Management activities including CI identification, control,audit, and verification

• Collaborate with Change Management to update CI records

• Produce KPI reports

User - This role is for the users who will submit new CIs or search for CIs to relate toincidents, problems, or requests.

Administrator - This role is responsible for administering the Configuration ManagementSystem process app, performing such duties as assigning users to roles or fixing issues.

Asset Discovery Integrations

The SSM-Integrations process app in the Serena Service Manager solution contains twoorchestration workflows that support integrations with external asset discovery systems:

• CIManagement_IC supports the integration between the ConfigurationManagement System (CMS) and Serena Asset Manager.

• CIManagement supports the integration between the CMS and Microsoft® SystemCenter Configuration Manager 7 (Configuration Manager).

When these systems detect changes to your IT assets, they send events to the SBM EventManager, which starts the applicable orchestration workflow. The orchestration workflowlogic processes the update, delete, or create events; calls Web services that update theCMS database; and invokes the corresponding transition in the ConfigurationManagement System application workflow.



In the CMS application, the Integration Log section at the bottom of the System tabcan contain messages logged from Serena Asset Manager events. This section containsinformation only if there are such messages pertaining to the CI.

For more information about these integrations, contact your salesperson.

Asset Management

Use the Asset Management process app to track the acquisition, ownership, and value offinancial assets throughout their life cycle.

Asset management helps you monitor requests for assets, track business and financialapprovals, and calculate depreciation values for each asset. You can easily report onassets in your inventory, incoming asset requests, and assets assigned to individualemployees. You can also quickly see year-to-date depreciation numbers, along withdepreciation of assets by department.

This ITIL-compliant process is fully integrated with the Configuration Management System(CMS) and the Service Requests process apps. For details, refer to Asset ManagementIntegrations [page 61].

Key Benefits

• Track assets by employee, class, or department.

• Greater visibility into depreciation values.

• Ability to link financial assets to service requests and configuration items (CIs).

Asset Management Overview

The Asset Management process app addresses the following areas:

1. Asset Creation [page 57]

2. Approvals [page 58]

3. Inventory Management and Maintenance [page 58]

4. Depreciation [page 59]

5. Audit [page 60]

1. Asset Creation

By default, Asset Management tracks assets of the following classes:

• Computer

• Furniture

• Hardware

• Leasehold Improvements (new carpet, for example)

• Office Equipment

• Other Fixed Assets

• Software


You can use these methods to add assets to your system:

1. Submit assets directly into an asset management project.

2. Create new assets from service requests. Refer to About the Service RequestsIntegration [page 61].

3. Post configuration items (CIs) from the Configuration Management System (CMS).For details, refer to About the Configuration Management System (CMS) Integration[page 61].

4. Administrators can import assets from a spreadsheet. For details, refer to ImportingAssets [page 140].

2. Approvals

You can use Asset Management to track approvals for assets that have not been approvedby a different process, such as Service Requests.

By default, two levels of approval are required for new assets:

• Business

Approvals are typically made by managers or department leads, who provide orapprove the business justification for an asset.

• Financial

Approvals are typically made by members of the financial team, who approve thecost of the asset.

Once assets are approved, they move to purchasing.

To ensure new assets are approved, you can:

• Submit them directly into an Asset Management project.

• Create new assets from service requests that are assigned to a fulfiller.

• Import them into the "Planning"' state. For details, refer to Importing Assets [page140].

To make approvals optional or to use the Service Requests approvals process, refer toManaging the Approval Process [page 136].

3. Inventory Management and Maintenance

After assets are ordered and delivered, they move to the acquired state.

Assets with an assigned class of Computer, Hardware, Office Equipment, Other FixedAssets, and Software must be added to the configuration management database (CMDB).The asset and the configuration item (CI) are linked together.

After assets have been added to the CMDB, they are typically assigned to an employee.You can use the User Info tab on the asset to see all assets assigned to that employee.

You can also choose to move acquired assets directly to the IT inventory.

The exception is leasehold improvements, which would include capital improvements toleased properties, such as adding new carpet or renovating a workroom. Leasehold



improvements move directly from "Purchasing" to "Active" until their associated leasesare terminated.

Asset managers can also perform these tasks during this phase:

• Collect assets

Use the Collect transition to move assets from an employee to the IT inventory sothey are available for other employees.

• Salvage assets

Use the Salvage transition to dispose of assets. For example, you may destroy,recycle, or sell assets. To ensure the asset is included in depreciation calculations,you must provide a salvage value, even if that value is $0.

Once assets are salvaged, the related CI automatically becomes inactive in theCMDB.

• Report lost or stolen assets

Use the Report Lost transition to move assets to a missing state. If an asset is laterfound, it can be returned to the assigned state. If the asset is not found, it can beremoved from inventory.

• Audit assets

Refer to 5. Audit [page 60].

And once assets associated with CIs are salvaged or removed from your inventory, therelated CI is automatically set as inactive.

4. Depreciation

Depreciation calculations start once assets are acquired. After that, depreciation isautomatically calculated on the first day of every month until an asset is retired.

Asset managers, members of the financial team, and administrators can also use the"Update Depreciation" transition to manually calculate depreciation for individual assetsbetween the automated calculation cycles. This transition is located on the More Actionsmenu.

Note: If you experience unexpected results after using the "UpdateDepreciation" transition, refer to Changing an Asset's Depreciation Date andRecalculating [page 138].

Your administrator can configure when depreciation calculations automatically occur. Fordetails, refer to Changing Depreciation Calculation Dates [page 136].

The following depreciation rates are provided:

• Double Declining Balance - 3 years

• Straight Line - 15 years



• No Depreciation (no calculations when this is selected)


Typically, the depreciation rate is set after an asset has been purchased.

Important: Before using the provided depreciation rates, verify that they areconsistent with the calculations used by your financial team.

You can view depreciation data on each asset or run one of several provided reports toquickly see depreciation data by department or asset class.

5. Audit

Auditing capabilities are available after assets have been acquired:

• From the Acquired State

Assets that have been acquired but not assigned to an employee are automaticallymoved to an audit state after 30 days.

• From the Assigned State

Assets can be manually moved to an audit state so you can verify their existence andthe accuracy of information about the asset. If assets are not found, they can bemoved to a missing state.

Auditing is typically performed by an asset manager or another member of the IT group.To audit assets, use the provided Assets Currently Being Audited report or create yourown reports.

Asset Management Roles

The following roles are available with the Asset Management process app:

• Manager

Intended for IT personnel who manage assets. Users assigned to this role cansubmit, own, and act on assets. They can also create and run asset managementreports.

• Employee

Intended for employees who are assigned assets. Users assigned only to this rolecannot own or view assets, but they are available as selections in the Employee field.

• Financial Team

Intended for members of your financial team who need visibility into asset cost anddepreciation information. These users can also submit, view, and act on assets.Financial team members can also manually calculate depreciation for individualassets.

• Business Approver

Intended for users who need to approve assets based on business need. Forexample, a manager may need to approve a new laptop for an employee. Usersassigned to this role can submit, own, and act on assets. They can also create andrun asset management reports.

• Financial Approver



Intended for users who will approve assets from a financial perspective. Financialapprovers can also run create and asset depreciation reports and update accountingand purchasing information.

• Purchasing

intended for users who will purchase assets. Users assigned to this role can submit,own, and act on assets. They can also create and run asset management reports.

• Administrator

Intended for users who need all privileges in the Asset Management process app.These users are typically administrators.

Asset Management Integrations

The Asset Management process app is configured to work with the Service Requests andChange Management Systems (CMS) process apps.

• About the Service Requests Integration [page 61]

• About the Configuration Management System (CMS) Integration [page 61]

About the Service Requests Integration

Once the Service Requests integration is enabled, request fulfillers can:

• Check inventory for an asset when a request is in classification. If an appropriateasset is found in inventory, the asset can be linked to the request and isautomatically assigned to the user.

• Use the User Assets tab on service requests to see assets currently assigned torequesters.

• Create new assets from requests that are assigned to a fulfiller. To do this, use the"Purchase Asset" transition.

• Link existing assets to requests that are assigned to a fulfiller.

In case of errors or to fix items that were incorrectly linked together, use the "UnlinkAsset" transition to remove the links between assets and active requests.

• Be assured that service requests are automatically resolved once assets are assignedto the requestor.

By default, assets created from service requests are added to the "Planning" state so thatthey can move through the Asset Management approval process. Your administrator canmodify the integration so that approvals are handled in the Service Request process app.

For setup and configuration details, refer to Enabling the Service Requests Integrationwith Asset Management [page 138].

About the Configuration Management System (CMS) Integration

Service Manager is configured to ensure data integrity between your configuration items(CIs) and your financial assets.

Once assets are retired, the related CIs automatically become inactive.

From the Configuration Management System process app:


Configuration analysts can use the "Add Asset to AM" transition to create a financial asset.

The "Add Asset to AM" transition is available in the "Active" or "Audit" states from CIs ofthese types:

• Software

• Hardware

• Laptop

• Workstation

Relevant information is posted between the CI and the asset.

You can use this transition on individual CIs or run the "Active Configuration ItemsWithout an Asset" reports to add multiple assets at once. For details, refer to ImportingAssets [page 140].

Assets created from CIs are added to the "Verify Import" state in the Asset Managementprocess app. From here, use the "Verify" transition to move assets to the "Acquired" stateso they can be assigned to employees.

From Asset Management process app:

Asset managers can use the "Add to CMDB" transition to add financial assets to theconfiguration management database. Posted assets are added to the "Classification" stateand must be activated to become CIs. Relevant information is posted between the assetand the CI.

Note: Typically, CIs cannot have duplicate names. This restriction does notapply to CIs created from assets, however.

Asset managers can also use the "Select Configuration Item" transition to link an asset toan active CI.

These transitions are available from the "Acquired," "Assigned," "IT Inventory," "Audit,""Missing," and "Verify Import" states.

In case of errors or to fix items that were incorrectly linked together, administrators canuse the "Unlink Configuration Item" transition to remove the links between assets andCIs.

Service Request Process AppsThe Serena Request Center solution contains the following process apps:

• Service Request

Refer to Service Requests [page 63].

• Knowledge Management

Refer to Knowledge Management [page 68].

• Starter Pack Forms - IT

Refer to Starter Pack Forms - IT [page 70].



The starter packer contains forms for commonly used IT services, such as passwordchange requests and software installations. You can use these forms as they are providedor you can customize them to meet your specific business needs.

Starter pack forms are available through two process apps:

• SRC - Starter Pack Forms - IT

• SRC - Service Request

A complete list of service requests organized by Serena Request Center category isprovided in Starter Pack Service Requests by Category [page 71].

Service Requests

Request fulfillment is responsible for handling requests that are less than major changesand outside of items that require immediate resolution such as problems and incidents.These requests can come from employees or customers. Each request is logged andtracked as it progresses through the workflow. Request fulfillment can optionally haveapproval processes that can be incorporated as part of the request fulfillment process.

Note: Service requests differ from incidents in that they do not involve a serviceinterruption. In other words, there is nothing broken that needs fixing with aservice request.

Typical service requests include:

• Configuration requests, such as new employee setup or network access.

• Security requests, such as allowing building access.

• Facilities requests, such as moving offices or furniture.

• Communication requests, such as adding a cellular phone.

• Information requests, such as how to connect to the network.

The following topics describe the features found in Request Fulfillment:

• Service Requests Overview [page 64]

• Service Request Roles [page 67]

Key Benefits

• Four different processes for tracking and monitoring requests.

• Reports for showing response time and customer satisfaction.

• Approval process to manage requests.

• Request fulfillment workflow that complies with ITSM best practices.

• Ability to integrate with Serena Service Manager process apps, such as AssetManagement.


Service Requests Overview

The Service Request application contains the request workflow. The following topicsexplain the general stages in the workflow:

1. Request Creation [page 64]

2. Request Classification and Initial Support [page 64]

3. Request Approvals [page 65]

4. Request Resolution and Support [page 66]

5. Request Monitoring and Communication [page 67]

1. Request Creation

Request creation is known as submitting requests in SBM. The primary actors responsiblefor submitting requests are employees, customers, and IT service desk staff. Employeesand customers can submit their requests using the Request Center or Work Center.

Most users assigned to Service Request roles can submit requests on their own behalf oron the behalf of another user. This enables service desk staff to submit requests on behalfof their customers or for managers to submit a request on behalf of an employee, forexample. To submit a request on behalf of another user, search for and select that userfrom the Affected User field on the Submit form.

To disable the submit on behalf feature, refer to Disabling "Submit on Behalf" [page 143].

To create a request:

1. Log in to Request Center: http://serverName/tmtrack/tmtrack.dll?shell=srp.

2. Search for or navigate to the service request you need, For example, select theEmployee Services service request category on the Catalog tab.

3. Click the service request to open the submit request form.

4. Complete the submit request form.

5. Click Submit to create the new request.

2. Request Classification and Initial Support

Request classification includes setting priority, performing request matching, anddetermining which approvals are needed.

In the Classification state, the service desk staff reviews the request and determineshow the request should be handled. The following actions may be available for updatingand routing the request, depending on your role:

• Assign to assign the request to someone who will fulfill it. The request can beassigned to a fulfiller or a group queue. It can also be assigned to both a fulfiller anda group queue, which provides a backup if the fulfiller cannot complete the requestin a timely manner. (For information about group queues, see Group Queues [page187].)

• Convert to Incident to move the request to the Incident Management workflow inSerena Service Manager. Files attached to the service request are added to theincident.



• Other actions from the More Actions menu, such as Recategorize and Send an E-mail.

When transitioning the request, fields can be modified. The following describes how theinformation in each field is used:

• Choose the Type, Urgency, and Impact from the lists. Priority is calculatedautomatically as described in Modifying Urgency, Impact, and Priority [page 209],but its value can be overridden.

• Choose a Fulfiller who will be responsible for resolving the request once the requesthas been approved.

• Choose a Fulfillment Group that will own the request until it is assigned to afulfillment group member.

• Choose the Reported By user from the list. If necessary, you can also select theAffected User and any other Additional Contacts.

• For the Service Request workflow, select whether the request requires BusinessApproval, Financial Approval, or Purchasing, and the person who will beresponsible for the action.

• If financial approval is required, enter the Cost Center associated with the request.

• Change the service CI (configuration item) associated with the request or add anassociation.

Recategorizing Requests

Each request is submitted into a specific project that is associated with the servicerequest. There is a possibility that users will submit a request into the wrong project,especially if there are a large number of service requests available or service requeststhat are similar to each other. The Recategorize transition gives staff in certain roles theability to move such a request into the correct project. This transition is available in allstates except for inactive states and the Resolved state.

To recategorize a request:

1. From the More Actions menu, select Recategorize.

2. In the Recategorize form, click the Notes/Attachments tab.

3. Search for the correct project in the Project field, and then add an explanation tothe Work Notes field.

4. Click the Details tab and update fields as needed. For example, you might need tochange the title and update the Description field with information relevant to thenew project.

5. Click OK.

3. Request Approvals

The Service Request workflow has two levels of approval: financial and business. Theseapprovals help ensure that requests adhere to the company's fiscal goals and business


rules. The primary roles responsible for these approving requests are Financial Approversand Business Approvers.

When a request is routed for financial or business approval, the selected financialapprover or business approver can either approve or reject the request. If approved, therequest moves to the Fulfillment state, where a fulfiller is assigned the item andbecomes responsible for resolving the approved request, or the Fulfillment Queue state,where a fulfillment group owns the item until it is assigned to a fulfiller.

The path through the Service Request workflow is usually determined by the type ofrequest. For example, requesting access to a building or network usually does not haveany financial cost, but there is usually a business approval process to ensure that thisperson should be granted access rights. These requests require business approval but nofinancial approval.

In contrast, purchase requests require financial approval but probably not businessapproval. The purchase request for a new PC would require financial approval and have apurchaser defined.

Tip: To require both types of approval, set the values for the RequiresBusiness Approval and Requires Financial Approval fields to Yes, and markthe fields as read-only for the project. This causes all requests to be routed forapprovals.

4. Request Resolution and Support

The actual fulfillment of a request depends on its nature. The service desk staff may beable to fulfill a request, or the request may need to be sent to an outside group forcompletion.

After the request has been approved, it moves to one of the following states:

• Fulfillment, where the assigned fulfiller is responsible for overseeing the closure ofthe request.

• Fulfillment Queue, where the request remains until a member of the fulfillmentgroup takes ownership of it.

In the Fulfillment state, there are different options available to the fulfiller to completethe request. The fulfiller can choose to:

• Resolve the request, completing the request and closing the issue. At this point, thefulfiller can update the Request Cost field with the actual cost.

• Request Info, which sends the request back to the submitter to gather moreinformation.

• Create a Task to open a subtask in the Service Request Task workflow in ServiceRequests. The Service Request Task workflow is a simple workflow with two mainstates, In Process and Closed. The request stays in the Fulfillment state while thesubtask is being completed. Examples of subtasks include placing an order with avendor and acquiring an access fob. Once the subtasks are completed, the requestmoves to the Task Completed state where the fulfiller can close the request. Thesubtasks related to the request can be seen on the Subtasks tab.

• Reassign the request to another fulfiller or move the request back into the groupqueue.



• Recategorize the request, moving it from this project to another.

In the Fulfillment Queue state, the Assign option is used to specify the primary ownerof the request.

Depending on the fulfiller's privileges, the following transitions may also be available:

• Convert to Incident creates an incident in the Incident Management application.

• Delete deletes the request.

The completed request moves to the Resolved state.

5. Request Monitoring and Communication

Request Center has two main methods to monitor and communicate the status ofrequests: notifications and reporting.

The first method is through e-mail notifications, which inform users about the status ofrequests. Automated e-mail notifications can be configured to notify users of requestcreation, request transfers, and request resolutions.

For example, you can create a notification that automatically informs request submittersthat they need to update their request with more information. The submitters can eitherlog in to Request Center using the link in the notification or reply to the e-mail to updatetheir request.

The notifications are tailored using notification rules and notification templates.Administrators are responsible for editing the notifications and creating the workflowrules. (On-premise only)

Users can subscribe to the selected notifications under their User Profile in Serena WorkCenter.

The second method to monitor communication is through reports. Request Centersnapshots come pre-configured with common useful reports for IT administrators andusers.

The following are some example reports:

• Active Service Requests by State

• Active Service Requests by Type

• Request Elapsed Time by Type

In addition to these pre-configured reports, you can create tailored reports in SBM totrack your requests.

You can also combine reports to create a dashboard or multi-view report.

Service Request Roles

The following roles are available for the Service Request workflow.

Manager - This role is responsible for the Service Request process. Other duties include:

• Ensure efficiency and effectiveness of the Service Request process

• Manage service request staff


• Provide for continuous service improvement for Service Request


• Maintain the Service Request system

• Collaborate with other Service Manager processes such as Incident Management,Problem Management, Change Management, and Configuration Management

Fulfiller - This role is for service desk staff who are responsible for handling incomingcalls and e-mails. Other duties include:

• Own requests from classification to closure

• Record, classify, and resolve requests as quickly as possible

• Escalate requests appropriately

• Keep users informed of request status

• Ensure Service Level Agreements are met

• Match similar request records

• Move a request to the correct project

Contact - This role is used to populate the Reported By and Additional Contacts fields.

Business Approver and Financial Approver - These roles are for the business andfinancial approvers who verify that a request meets business and financial requirements.

Purchasing - This role is for users who purchase software or hardware.

User - This role is for the users who submit requests and providing the necessary detailsto the request. This role is associated with the Affected User, Reported By, andAdditional Contacts fields.

Administrator - This role is responsible for administering the Service Requestapplication, such as assigning users to roles or managing auxiliary data.

Knowledge Management

Serena Service Manager integrates with the Knowledge Management application, which isincluded with the Serena Request Center solution. This section describes how to useKnowledge Management independently as well as with Serena Service Manager.

• Knowledge Management Overview [page 68]

• Knowledge Management Roles [page 69]

Knowledge Management Overview

Serena Request Center includes Knowledge Center for managing knowledge base articlesand announcements. The Knowledge Management application allows you to manage thesubmission of new articles, specify whether articles are public or private, monitor changesto existing articles, and manage article templates.

The Knowledge Management application has two main types of users:



• Contributors submit articles and add content. They edit the content and format ofthe articles. Contributors can save the articles as drafts, which stores the data in thedatabase until the article is ready to be sent to the publisher for final approval.

• Publishers review articles before they are made available to users. The publishercan send the article to additional team members for approval. When the article isready, the publisher posts or publishes the articles to Knowledge Center.

After an article is published, the Knowledge Management item is closed and the content iscopied to Knowledge Center, where the material becomes available to users. Users cancomment on and rate an article; the comments and ratings are stored in KnowledgeCenter.

Urgent announcements are displayed in the banner bar of Request Center.

When users start to submit general service requests into Request Center or incidents intothe Serena Service Manager Incident Management application, a keyword search ofKnowledge Center is performed. Links to related articles are displayed. If one of thearticles addresses the issue, users can click a button to submit and then immediatelyresolve their request or incident.

The content of published articles cannot be edited directly in Knowledge Center. Instead,a new item is submitted into Knowledge Management using the Update this item link onthe published article. The new item must proceed through the Knowledge Managementworkflow. When the change is published, the updated content replaces the existingcontent in Knowledge Center, while the comments and ratings remain unchanged.

Key Benefits

• HTML editor for easy formatting of article content.

• Four distinct types of articles to distinguish types of information within KnowledgeCenter.

• Distinct user roles for publishers and contributors to ensure quality of KnowledgeCenter content.

• Tracking of approvals to ensure knowledge base article quality.

• "Public" or "private" visibility into published articles. Users cannot view a "private"article if they are not assigned to the visibility group associated with the article.

• Ability to create article templates based on article type.

Knowledge Management Roles

The following roles (or actors) are available for the Knowledge Management workflow.Members assigned to these roles are available for selection when an article is sent forapproval.

Editor/Publisher -This role is responsible for editing, approving, and publishingKnowledge Center articles. Other duties include:

• Submit new articles to Knowledge Center.

• Update existing Knowledge Center articles.


• Approve articles before they are published, ensuring that Knowledge Center articlesmeet the accepted standards.

Contributor - This role is responsible for adding content to Knowledge Center articles.Other duties include:

• Add content to articles that are in the Edit state.

• Edit existing articles that have been re-opened.

• Review and approve content of an article written by another contributor.

Announcement Contributor - This role has the same privileges as the Contributors role.In addition, the Announcement Contributor can publish announcements without Publisherapproval.

Administrator - This role is responsible for administering Knowledge Management, suchas assigning users to roles, fixing SBM issues, or restoring deleted items.

Setting Default Values for Publishers and Contributors

After you add adding users to Knowledge Management roles, set default values for thePublisher and Contributor fields at the project level in SBM Application Administrator.

The default values prevent possible permission errors that can result when KnowledgeCenter articles are submitted from other process apps.

One option is to set the default value of the Contributor field to Current User, which willimmediately assign the item to the submitter for editing.

Setting a default value for the Publisher field also prevents errors that can result when theTime Capture feature is enabled.

Starter Pack Forms - IT

Forms included with the SRC - Starter Pack Forms - IT process app have two versions:one for the submitting requests (Transition) and one for viewing requests (State). Whenyou install and deploy the process apps, unique services and projects are created for eachpair of forms.

The transition form includes fields referenced from the SRC - Service Request process appand from multiple edit box controls that gather information. After the submit iscompleted, the data from the edit box controls and the fields are added to theDescription field of the item.

The state forms appear on the Request Data tab for submitted items. The tab containsmany of the custom fields for that item. The state form that is displayed is determined bythe value of the Request Form field, which is automatically set when the original item issubmitted. This allows the state form that is paired with the original submit form to bedisplayed.

Note: The Starter Pack Forms significantly improve the ease at which forms canbe updated and customized. Instead of modifying the main process app forevery change to forms, you can modify the SRC - Service Request process appprocess app. The workflow does not have to be modified since the customsubmit forms are determined when services are set up in Request Center. Thedisplay of the accompanying custom state form on the Request Data tabrequires only two state forms on the main workflow, while allowing the displayof custom fields appropriate for the submitted item.



Creating Custom Starter Pack Forms

In addition to the specialized forms, three generic forms are provided as a basis forcreating other specialized forms. To use one of these forms as a template in SBMComposer, right-click the form and choose Duplicate.

The following table describes these three forms.

Form Description

SubmitTemplate

This default template can be used as a basis for creating a simple submitform. The form includes the basic fields such as Requester Name, Urgency,Impact, and Priority, Required Date and Cost Center. The Request Detailstab contains space to add additional fields. The Hidden Fields section is aplace for you to place fields you do not want users to see or change.

SubmitTemplate(Wizard)

This wizard template can be used as a basis to create a multi-page submitform. This form is useful for collecting more data during the submitprocess. When users click Next, the next tab in the submit form opens,enabling them to progress through each tab and add required information,while maintaining a clutter-free page.

StateTemplate

The state template is a simple state form that contains the basic fields laidout to match the submit forms. You can include this state form as anembedded form on the tab for your item.

Starter Pack Service Requests by Category

After you import and promote the Starter Pack Forms and SRC - Service Request processapp, the Request Center is populated with the Starter Pack Service Requests.

All Starter Pack Forms include fields to gather requester details, project information, andcost center. Pertinent fields in each service have been set as required and many havedefault values; you can change these settings in SBM Application Administrator asneeded. Be sure to test your changes to ensure users can submit requests without errors.

You can also customize service level agreements in SBM Application Administrator.

The following table lists the Starter Pack Service Requests by category, the form used foreach service request, a description of how each service request is meant to be used,default service level agreement. Unless otherwise noted, the service requests use theService Request workflow in the SRC - Service Request process app and the externalforms found in the Starter Pack Forms process app.


Advanced IT Services

ServiceRequest

Submit and StateForms

Description DefaultServiceLevelAgreement

BackupRequest

Backup Tracks one-time or ongoing requestsfor IT to back up a server machine.

Default settings include:

• Urgency, Impact, and Priorityfields are set to Department,Single User, and 3.

• Type set to Other.

• Requires Business Approval setto Yes.

Resolvedwithin twobusinessdays.

FirewallRequest

Firewall Tracks requests for users who needto access a particular server that isoutside the network firewall.


• Urgency, Impact, and Priorityfields are set to Medium, SingleUser, and 4.

• Requires Business Approval fieldis set to Yes.

• Type set to Access.

• Title set to Firewall Request.

Resolvedwithin fivedays.



ServiceRequest

Submit and StateForms

Description DefaultServiceLevelAgreement

MSDNLicenseRequest

MSDN Account Tracks access to MSDN licenses.


• Urgency, Impact, and Priorityfields are set to Medium, SingleUser, and 4.

• The Requires Financial Approvalfield is set to Yes.

• The Requires Purchasing field isset to Yes.

• Type set to Purchase.

• Title set to MSDN AccountRequest.

Resolvedwithin fivebusinessdays.

NetworkPortRequest

SR - Submit (foundin SRC - ServiceRequest processapp)

Tracks employee requests for accessto restricted network ports.


• The Requires Business Approvalis set to Yes.


Resolvedwithin threebusinessdays.

NewMailboxRequest


Tracks employee requests for newmailboxes.




RestoreRequest


Tracks the restoration of an ITsystem or service.





Employee Services

ServiceRequest

Form Description DefaultServiceLevelAgreement

DeskPhoneRequest

Desk PhoneVoice Mail

Tracks the setup of a new phone for anemployee.


• Urgency, Impact, and Priority fields areset to Medium, Single User, and 4.

• Requires Business Approval set to Yes.


• Title set to Desk Phone/Voice MailRequest.

Resolvedwithin twodays.

New HireRequest

New Hire Manages the hiring of a new employee. Thesubmit form is a wizard that walks youthrough multiple tabs, including:

• General information about theemployee, such as employee name,expected start date, job title,department, and office location (such ascube number or remote location).

• Computer tab collects information aboutthe required computer and softwareneeds.

• Voice and data tab collects informationabout phone and voicemailrequirements.

• Network tab collects information aboutVPN access and email setup.

• Special Instructions include other setuprequirements such as access to aprinter, mainframe, or CRM tools.


• The Urgency, Impact, and Priority fieldsare set to Medium, Department, and3.


Resolvedwithin 10businessdays.



ServiceRequest


OfficeMoveRequest

Office Move Enables employees or contractors to requestan office move.


• The Urgency, Impact, and Priority fieldsare set to Medium, Single User, and4.



UpdateContactInfo

SR - Submit(found inSRC -ServiceRequestprocess app)

Enables employees to request updates totheir contact information.




VPNAccessRequest

VPN Access Enables users to request VPN access for aspecific IP address.






Facilities Services

ServiceRequest


BuildingSecurity

NewAccessBadge

Tracks requests for security badges. The NewAccess Badge wizard submit form collects allof the pertinent information about theemployee, including name, department,manager, access needs, and emergencycontact information.


• The Urgency, Impact, and Priority fieldsare set to Medium, Single User, and 4.



• Title set to New Access BadgeRequest.


FacilitiesIssue

SR -Submit(found inSRC -ServiceRequestprocessapp)

Tracks general facilities issues.



Resolvedwithin oneday.

HVACRequest

HVAC Tracks requests for managing heating,ventilation, and air conditioning set up andchanges.


• The Urgency, Impact, and Priority fieldsare set to Medium, Department, and 4.

• Requires Business Approval and RequiresFinancial Approvalset to Yes.


• Title set to HVAC Request.

Resolvedwithinseven days.



ServiceRequest


SecurityCardRequest


Tracks requests for employee security cards.





SecurityIncidentReport


Tracks generic requests related to securityconcerns.




SuggestionBox


Tracks suggestions for the facilities team.





IT Infrastructure

ServiceRequest


InstallServer

InstallServer

Tracks new server installations. The Install Serverwizard submit form collects pertinent information,including:

• Hardware and operating system requirements.

• Permission requirements.

• Network configuration, such as load balancingrequirements and DMZ need.

• Backup configurations such as frequency ofbackups and retention periods.

• General instructions such as monitoring needsand driver specifications.


• Urgency, Impact, and Priority fields are set toMedium, Department, and 3.

• Requires Purchasing and Requires FinancialApproval are set to Yes.


• Title set to Install Server Request.

Auxiliary table relationships:

The Requested Operating System field referencesthe SRC - Operating Systems auxiliary table.Populate this table with available operatingsystems before users submit requests.




ServiceRequest


Install/UpgradeOS

InstallOS

Tracks requests to install operating systems.submit form collects the pertinent information for anew operating system, including:

• Request details such as upgrade reason,current and requested operating systems, andadditional information such as drivers,adapters, and components.

• Attachments.


• The Urgency, Impact, and Priority fields are setto Medium, Single User, and 4.



• Title set to Install OS.


The Current Operating System and RequestedOperating System fields reference the SRC -Operating Systems auxiliary table. Populate thistable before users submit requests.

Resolvedwithin10days.

New VMImageRequest

VMImage

Tracks requests for the installation and setup ofnew VMWare ESX images.


• The Urgency, Impact, and Priority fields are setto Medium, Department, and 3.

• Requires Financial Approval set to Yes.


• Title set to VM Image Request.

Provisionedwithin 15businessdays.


IT Purchasing Requests

ServiceRequest


InstallClientSoftware

ClientSoftwareInstall

Tracks new software installations. The requestfilters available software choices based on theselected department. Pertinent information for asoftware installation is gathered, including:

• Request details such as department, currentoperating system, requested software, andPC IP address.

• Attachments


• The Urgency, Impact, and Priority fields areset to Medium, Single User, and 4.



• Title set to Install Client Software.


The Current Operating System and ClientSoftware Requested fields reference the SRC -Client Software and SRC - Operating Systemsauxiliary tables. Populate these tables beforeusers submit requests.




ServiceRequest


InstallNewDesktop

NewDesktopInstall

Tracks requests for new personal computers.The request gathers the requested computertype, along with the desired model andoperating system. The request collects otherpertinent information including:

• Request details include department,requested PC type and model, requestedoperating system, monitor requirements,speaker requirements, and fields foradditional information. Note that the

• The available selections for Request PCModel and Request Operating Systemdepend on the selection for Requested PCModel. The available selections areconfigured in the Computer Types auxiliarytable.

• Attachments



• The Requires Purchasing and RequiresFinancial Approval fields are set to Yes.


• Title set to New Desktop Install.


Request PC Type, Requested PC Model, andRequested Operating System fields reference theSRC - Computer Types, SRC - Computer Models,and Operating Systems auxiliary tables. Populatethese tables before users submit requests.



ServiceRequest


MobileDeviceRequest

MobileDevice

Tracks employee requests for new mobilephones and pagers.





• Title set to Mobile Device Request.


Mobile Device selections are based on the MobileCarrier selection. These two fields are populatedbased on their respective auxiliary tables.

Populate the SRC - Mobile Carrier and SRC -Mobile Device tables before users submitrequests.




IT Services for Users

ServiceRequest


Access toNetworkPrinter

NetworkPrinterAccess

Tracks requests for users who need accessto a particular network printer or need aprinter to be added to the network. Therequest gathers the basic details, includingprinter name, IP address, and any specialfeatures.



• Title is set to Network Printer AccessRequest.




ModifyDistributionList

ModifyDistributionList

Tracks requests for adding, modifying, ordeactivating e-mail distribution lists.



• Title is set to Modify Distribution List.




PasswordReset


Tracks password reset requests foremployees



Resolvedwithin oneday.


ServiceRequest


PrinterServiceRequest


Tracks requests for access to a printer ornew printer purchases.




SoftwareLicenseRequest


Tracks requests for new software licenseorders or assignments.



Resolvedwithin tenbusinessdays.



Chapter 4: Serena Request CenterOverview

Request Center is a portal into IT services. Request Center is intended for users whorequest services and need to check on the status of those requests. A knowledge base,called Knowledge Center, is also provided.

The portal is pre-populated with service requests, such as "New Hire Request" and"Install/Upgrade OS." These service requests follow the Service Request workflow in theSRC - Service Request process app.

Users access Request Center through the following URL:

http://serverName/tmtrack/tmtrack.dll?shell=srp

Key Benefits

• User friendly, visually appealing interface into IT service operations.

• Pre-populated service requests.

• Custom submit forms tailored for request fulfillment.

• Instant access to important IT service announcements.

• Easy access to knowledge base articles in Knowledge Center.

The following topics describe the features available in Request Center.

• About Request Center [page 86]

• About Legacy Requests and Approvals [page 86]

• Service Catalog [page 87]

• Requests View [page 89]

• Approvals View [page 90]

• Knowledge Center [page 90]


About Request CenterUse the legend below the image to learn about Request Center.

1. Use the Catalog tab to navigate the service catalog and submit requests. Refer toService Catalog [page 87].

2. Use the Requests tab to monitor requests based on a report specified by anadministrator. Refer to Requests View [page 89].

3. Use the Approvals tab to monitor items that are pending approval. Refer toApprovals View [page 90].

4. Use the Knowledge tab to access Knowledge Center articles. Refer to KnowledgeCenter [page 90].

5. Configure custom tabs in Request Center to display an external URL, SBM report, orWork Center activity view. Refer to Adding Tabs to Request Center [page 158].

6. See urgent announcements.

7. Open the user profile and change settings, including the user's locale to viewlocalized strings (if any) in Request Center.

8. Configure the banner and the Contact Info, or enter edit mode to configure customcategories, sections, and tabs (available to administrators only). Refer toCustomizing the Request Center Properties [page 172].

9. Launch SBM Application Administrator (available to administrators only).

Legacy Requests and Approvals tabs are also displayed if you have upgraded from aprevious version of Service Manager (they can also be enabled in the Request CenterProperties and added manually). For details, refer to About Legacy Requests andApprovals [page 86].

About Legacy Requests and Approvals

In Service Manager 5.2.1 and earlier, the Requests view and the Approvals view (nowreferred to as "legacy" views) displayed the user's requests and items requiring the user'sapproval using provided reports. The administrator could specify different reports forthose views as long as the reports followed certain criteria.

In Service Manager 5.2.2 and later, the administrator can specify any report for the newRequests and Approvals views. This provides the administrator complete control overthe items and fields that appear in the views. In addition, the results of the report appearin the views just as they do in Work Center.



For upgrading customers, the legacy Requests and Approvals views are automaticallydisplayed in addition to the new views. New customers can also display the legacy viewsby following the procedure below.

To display the legacy Requests and Approvals views:

1. Select Customize | Request Center Properties.

2. Set Add legacy tabs to Allow and click Save.

3. Select Customize | Request Center Portal.

4. Click Add tab, and then select Add Legacy Approvals or Add Legacy Requests.

Service Catalog

Use the Catalog view to search for and request IT services. Service requests are createdand organized into containers and categories by an administrator. The containers andcategories you see are based on your privileges for submitting service requests assignedto categories.

Use the legend below the image to learn about the Catalog view.

1. Home

Shows the highest level of category containers and categories.

2. Category Container

Containers include a navigation arrow, indicating they include categories of servicesand possibly other containers. Click the arrows to navigate through the containers.

3. Category

Categories provide a way to organize service requests. When a category is selected,service requests assigned to that category appear in the service list.


4. Service List

Click any service request to open a submit form.

Hover over a service and click the blue arrow to see detailed information about theservice.

Once you navigate to a container or category, you can change the service list viewmode to Standard view or Compact view. The Standard view shows a large iconand the service summary; the Compact view only shows a small icon. You canexpand the service in the Compact view to see detailed information.

Note: The Standard view is always used for Home.

5. Catalog Search

Search for service requests and categories.

Requesting a Service

To request a service:

1. Search for or navigate to the service you need.

2. Click the service request in the service list to open the submit form.

3. Enter information as needed, and then click the Submit button at the bottom of theform.

The service request is submitted into the SBM project associated with the servicerequest.

Tip: If a user submits a request into the wrong project, service desk staff canmove the request into the correct one.

Searching for Services

You can search the catalog for service requests and categories.

You can search for content in the service name, summary, or description or in thecategory name and description. Containers are not included in the search results.

Search criteria must contain at least two characters. You can use asterisks (*) as awildcard character. For example, if you search for serv*, services or categories thatcontain server or service are returned.

By default, searches are limited to 100 results.

To search for a service:

1. Select the Catalog tab.

2. Enter search criteria in the Search Catalog box, and then press Enter.

Categories and services that match your criteria are returned.

3. Click a service to open a submit form or click Close to exit the search results page.



Requests View

Use the Requests view to see requests based on criteria defined by an administrator. Bydefault, you will see requests that you submitted and that have been modified in the past30 days. This enables you to see the status of these requests. Administrators can modifythis report or use a different report, however. For setup details, refer to Configuring theRequests View [page 166].

Legacy Requests View

By default, items are grouped by request date.

A symbol represents the status of each item:

• - Indicates active items that are currently waiting for action by other users.

• - Indicates items that the user must act on. These items may require that theuser's input or approval.

• - Indicates that the items are inactive.

The following actions can be performed on the legacy Requests view:

• Filter items by selecting Active, Follow Up, or Inactive.

• Sort items by selecting Request Date, Last Update, Type, Owner, or State.

• Search for items in the Requests report set by your administrator. You can search forinformation in the title and description or by request ID.

Search criteria must contain at least two characters. You can use asterisks (*) as awildcard character.

• See the details of an item by clicking on its title.

• See the history of an item by clicking the magnifying glass adjacent to the title.


Approvals View

The Approvals view displays items that users are required to approve. Administratorscan configure the approval items that are shown. For setup details, see Configuring theApprovals View [page 169].

Click the title of an item to open the approval item. Select from the available transitions toapprove or reject the item.

Legacy Approvals View

By default, the items are grouped by request date.

In addition to displaying the item, users can:

• Sort items by selecting Request Date, Last Update, Type, Owner, or State.

• Search for approval items returned by the Approvals report set by youradministrator. You can search for information in the title and description or byrequest ID.

Search criteria must contain at least two characters. You can use asterisks (*) as awildcard character.

Knowledge Center

Knowledge Center is the online interface into the Knowledge Management system. Toaccess Knowledge Center, log into Request Center and select the Knowledge tab.

Knowledge Center has two types of users:

• Article Viewers



All SBM users have privileges to view and comment on public articles. Other articlesare visible to you based on visibility settings made by contributors.

For details, refer to Using Knowledge Center Articles [page 91].

• Article Contributors and Publishers

Typically, articles are added by service desk technicians as they resolve incidents,problems, and service requests.

For details, refer to Managing Knowledge Center Articles [page 92]

Using Knowledge Center Articles

Use Knowledge Center to:

• Search for articles.

• Sort the search results by most recent, best, most popular, or most commented.Best is based on cumulative ratings and Popular is based on the total number ofviews.

• Filter results based on article category or type.

• Group results by article category or type.

• View article details.

• Add comments and rate the article in the detailed view. Choose the number of starsto give the article and enter any comments.

Note: You are allowed only one comment and rating for each article.Subsequent comments will replace the original comment.

• View important IT announcements, such as possible outages. Announcements appearbelow the banner and are visible on all tabs, as shown in the following figure.

Searching for Articles

You can search for public articles by entering keywords in the search field on theKnowledge tab. You can see private articles if you belong to a visibility group associatedwith the article.

If you have privileges to publish articles, you can view expired articles and updatearticles. Select Include Expired to include expired articles in your search results.

Adding Comments or Ratings

You are allowed one comment or rating.


To add comments, view the article, and then click Add your own comment. To updateyour comment, click Update your comment

To rate articles, click the stars below the comment box.

Sending a Link to the Article

Send the article to another person by copying the URL and pasting it in an e-mail orinstant message.

To copy the URL to your clipboard, click . You can then paste (CTRL+V) the URL into ane-mail or instant message. This URL gives users direct access to the article.

Viewing Articles When You Submit a General Request or Incident

By default, when you submit an incident or a general service request, you are promptedthat articles related to your submission may already exist. You can view a related article,then choose Yes, resolve this issue to automatically submit and then immediatelyresolve the issue. A link to the article will be displayed in the Resolution field of theissue. The issues are created with a "low" urgency, a "single user" impact, and a "5"priority. This increases the accuracy of service desk metrics, because issues with self-service resolution are accounted for properly.

A keyword search is performed after you have entered a Title and moved focus toanother field.

When articles that match the title words exist in Knowledge Management, a messageappears informing you of the number of matches. Click View to look at matching articles.

Managing Knowledge Center Articles

Knowledge Center articles and announcements are managed with the KnowledgeManagement process app. These tasks are performed by users assigned to service deskstaff assigned to Knowledge Management roles.

For details, see Knowledge Management [page 68].

The following section discuss these Knowledge Management activities:

• Creating Announcements and Articles [page 93]

• Creating Urgent Announcements [page 95]

• Reviewing Articles [page 95]

• Publishing Knowledge Center Articles [page 96]

• Updating Knowledge Center Articles [page 97]

• Deleting Knowledge Center Articles [page 97]



Creating Announcements and Articles

Knowledge Center articles and announcements are created in the Knowledge Managementprocess app. You can:

• Submit new articles into the Knowledge Management Articles project.

• From an existing article template, use the Create New Article transition located onthe More Actions menu.

• Administrators can import articles from a spreadsheet. This provides a way to quicklypopulate the Knowledge Center with articles from another system.

For details, refer to Importing Articles [page 164].

If you use Serena Service Manager, you can also use one of these methods to createKnowledge Center articles:

• Post articles from incidents as they are resolved. For details, refer to 4. IncidentResolution and Closure [page 22].

• Post articles from problems as they are resolved. For details, refer to 6. ProblemResolution [page 30].

• Post announcements from requests for change (RCFs) after they have beenapproved. For details, refer to Announcing a Change [page 37].

With the exception of importing articles, these tasks are performed in Work Center.

Regardless of the origination point, articles are submitted into the KnowledgeManagement Articles project. The articles are assigned to contributors, who add contentto the article. Contributors can save the articles as drafts so they can work on them later.

Articles contain two types of data:

• Article Metadata [page 93]

• Article Content [page 94]

Article Metadata

Article metadata is added on the Details tab. The following information can be added asmetadata.

• Article TypeKnowledge Management articles are divided into four types, and some types areassociated with particular items. The four types with their respective items inparentheses follow:

▪ Announcement (Changes)

▪ FAQ

▪ How To

▪ Tech Note (Incidents, Requests, Tech Notes)

Note: For details on creating urgent announcements, refer to CreatingUrgent Announcements [page 95].


You can create custom article templates and associate them with article types. Fordetails, refer to Creating Article Templates [page 161].

• Article Category

You can assign article to a particular category when they are created or modified.This allows Knowledge Center users can filter articles based on categories, whichmakes it easier to find articles.

For details on modifying categories, refer to Managing Categories [page 163].

• Visibility

By default, articles have public visibility, which means that all SBM users can seethem in Request Center.

To make an article private, select Private in the Article Visibility field, and thenselect a group in the Visibility Group field. Only users and groups that are assignedto that visibility group can see the article on the Knowledge tab.

For details on visibility groups, refer to Assigning Knowledge Center Privileges [page160].

• Duration

You can define how long an article is available to users in Knowledge Center byselecting the Article Duration. Does not expire means that you define when thearticle becomes active in Knowledge Center; the article will not be removedautomatically at a specific date. Expires allows you define both the Start Date andExpiration Date for when the article will be available in Knowledge Center.

For example, you may be performing maintenance on your e-mail server thisweekend, and you want to inform your users that the services will be offline fromnoon to midnight on Saturday. You would set expiration date and time at the end ofthe Saturday. The announcement will no longer appear in Knowledge Center afterthe expiration date.

Users who have the privilege to submit articles can view expired articles by selectingInclude Expired articles in Request Center.

• Title, Summary, and Keywords

When a user performs a Knowledge search in Request Center, the search isperformed against all words in the content, title, and summary of the article. You cantype additional keywords that you anticipate users will use to search in theKeywords field.

The words in these fields are also used for the item match search that is performedwhen a user submits an item.

Note: Search options need to be configured on the Smart Search tab inSBM Configurator. For details, refer to SBM Installation and ConfigurationGuide.

Article Content

Article templates and content are added on the Content tab.

The following options are available:

• Load Template



Click this link to load an article template associated with the specified article type.The article template includes sample data and headings to assist in completing thedifferent sections according to company standards.

For details on creating article templates, refer to Creating Article Templates [page161].

• Show Labels/Hide Labels

Click this link to show or hide label text in the article.

• Populate Sections

Click this button to add template content to the article.

If your template contains multiple sections, use the Select sections to Copy drop-down list to the sections to copy template content from.

• Section Labels/Content

Add content by placing your cursor in each section and adding the text. The HTMLeditor opens, allowing you to apply formatting to the text and insert links or images.

• Save as Draft

Choose to save the article as a draft or to send it to a publisher.

Creating Urgent Announcements

Announcements that are marked as urgent appear both in Knowledge Center and in theannouncement bar below the Request Center banner. Urgent announcements also appearin search results on the Knowledge tab.

To create an urgent announcement, submit an article into Knowledge Management. Setthe Article Type to Announcement, and then select the Urgent check box.

Users can navigate through the urgent announcements in the announcement bar by usingthe up and down arrows.

The arrow in the following illustration points to an urgent announcement in RequestCenter.

Note: The IT administrator can disable the announcement bar in RequestCenter.

Reviewing Articles

Reviewing articles before they are published for public viewing in the Knowledge Centerensures that they meet the standards set by your company.

The main actors for reviewing articles are editors/publishers and reviewers. The editor/publisher is responsible for sending the article for review, adding suggested edits to the


article, and publishing the article. Reviewers are responsible for reviewing the article andsuggesting edits.

The Knowledge Management review steps follow:

1. The contributor finishes an article and sends it to the publisher using the Send toPublisher transition. The article moves to the Content Preparation state.

2. The publisher uses the Send for Review transition to send the article for review.

3. The publisher chooses the reviewers by moving them into the Reviewers list.

4. After adding the Work Notes to the article, the publisher completes the transitionby clicking OK.

5. The article moves to the Content Review state, where the selected reviewersbecome the owners.

6. The reviewer can Approve the article or Suggest Edits. The suggested edits arenoted in the Suggested Edit field.

7. If the reviewer suggested edits, the article moves to the Edits Suggested state.

8. The publisher can Edit the item with the suggested edits.

9. After the edits have been incorporated, the publisher chooses to either publish thearticle or send it for another round of review.

In addition to the usual review path, publishers can choose from the following options:

• Return the article to the contributor, which moves the article back the Draft state.The contributor can add to the article and then send it back to the publisher.

• Reject the article, which moves it to the Rejected state. The contributor to thearticle can choose to Re-Submit the article.

• Cancel review of the article, which returns it to the publisher. If suggested editshave been added, the article moves to the Edits Suggested state. If not, it returnsto the Content Preparation state.

• Delete the article, removing it from the system.

Publishing Knowledge Center Articles

Publishing moves the article into Knowledge Center, where it becomes active andavailable for searching, rating, and commenting by users. Publishing articles copies thecontent from the article in the Knowledge Management application into the KnowledgeCenter.

Publishing occurs with the Publish transition. This transition is available from multiplestates within the Knowledge Management workflow.

Important: Do not use Mass Update or the Editable Grid to perform thePublish transition. If you do, articles will not be published to Knowledge Center,and instead will move to the Published state in Knowledge Management,preventing you from publishing the articles again. You will instead have torecreate the article.



Updating Knowledge Center Articles

You may need to modify the published articles in Knowledge Center to add information orto fix errors.

Modifying a published article requires that a new item be submitted into KnowledgeManagement to track the updates. The new item contains a copy of all the informationcontained in the published article. The published article remains in Knowledge Center.

This duplicate item proceeds through the same Knowledge Management workflow,requiring approvals, if needed. When the item is published, the new content replaces theprevious content in Knowledge Center. The comments that were made against the originalarticle remain in Knowledge Center.

Restriction: To modify an existing article, you must have permissions topublish articles.

To modify an existing article:

1. Select the Knowledge tab in Request Center.

2. Search for the article.

Note: Click Include Expired to access expired articles.

3. Open the article and then click Update This Article. A new item is submitted intoKnowledge Management with the Content field populated with the data from theoriginal article.

4. Edit the article using the Edit transition and the HTML editor.

5. After you finish the modifications, publish the article to replace the existing contentin Knowledge Center.

Deleting Knowledge Center Articles

You may need to delete or remove articles from Knowledge Center.

To remove items, update the item from Knowledge Center as described in UpdatingKnowledge Center Articles [page 97], and then select an expiration date in the past.Remember that the start date must be prior to the end date, or the article will beconsidered a non-expiring article.

This will remove the article from the Knowledge Center, while keeping an audit trail of theitem, informing others about who removed the article.

Other publishers will be able to view the deleted article and its contents by selecting theoption to view expired articles in Knowledge Center.




Chapter 5: Serena Work Center Overview

Work Center is designed for users who need to act on work items, including servicerequests, change requests, incidents, and problems.

Service Manager users, such as IT fulfillers and change managers, use this URL to log into Work Center:

http://serverName/workcenter

The following topics describe the Service Manager features available in Work Center. Forguidance on general Work Center use, refer to the online help.

• Application Groups [page 99]

• Key Metrics [page 100]

Application GroupsService Manager includes two application groups, which are a set of applications organizedaround a business need. The Service Manager application groups contain the followingapplications:

• Service Requests — Manages request fulfillment:

▪ Service Request

▪ Knowledge Management

• Service Mgmt — Manages incidents, problems, changes, and configurations:

▪ Change Management

▪ CMS

▪ Incident Management

▪ Problem Management

▪ SSM Integrations

Each application group provides key metrics through a set of dashboard and activityviews, as described in Key Metrics [page 100].

When users create their own views or add shared views to their menus, they can chooseto organize the view under any of the applications in the Service Mgmt or ServiceRequests application groups.

For best results, users should "pin"' the application groups to their Work Center toolbar.


Key MetricsService Manager provides several views into your ITSM activities. Views are organized byapplication group, as described in the following sections.

Two types of views are provided:

• Dashboard Views

Contain reports and external Web pages.

• Activity Views

Contain feeds that show either all items or items owned by the user who is logged in.

Note: The default views cannot be deleted, but feeds can be added to thedefault views. For guidance, refer to the Work Center online help.

Service Management Views

Service management views are available when the Service Mgmt application group ispinned to the Work Center toolbar and is selected.

Each application in the Service Mgmt application group contains activity views that showitems that the current user is responsible for, along with all active items in that processapp.

In addition, Dashboard views are provided for each application, as described in thefollowing sections:

• Incident Management Dashboards [page 100]

• Problem Management Dashboards [page 101]

• Change Management Dashboards [page 102]

• CMS Dashboard [page 103]

Incident Management Dashboards

Incidents Dashboard

Provides an overview of existing incidents and possible problem areas. It includes thefollowing reports.

• Active Incidents by Type gives an overall view of the distribution of incidentsbased on their type.

• Active Incidents by State shows incidents and whether the number of incidentshas reached a threshold. This graph allows the team to be proactive in addressingissues and keeping them under the critical threshold.



• Incidents Time in State (SLA) shows the duration of time that incidents remain ineach state. Incidents are grouped by priority.

• Incidents Resolved by Level and Priority shows at which support level incomingincidents have been resolved.

• Unresolved High Priority Incidents lists existing high priority incidents. Theseincidents may be a cause for alarm, because they are high priority and have notbeen addressed.

Satisfaction Dashboard

Provides an overview of how quickly incidents are being addressed and the responses tothe satisfaction surveys for the incidents. It includes the following reports.

• Surveys by Level and Request Type shows the incidents that have completedsurveys based on level and type. You can drill down to the incident to view thesurvey.

• Survey Scores by Type shows the average score and the number of surveys thatwere received for each incident type.

• Completed Survey Ratio shows the number of incidents with completed surveyscompared to the number of incidents where surveys were not completed.

• Week on Week First Call Resolution Rates shows the number of incidents thatwere resolved on the first call, broken down by weeks.

IT Analysts Dashboard

Provides easy visibility into incidents waiting in a queue and incidents for which they arethe primary owner or a secondary owner. It supports the Group Queues [page 187]feature, and includes the following reports:

• My Incident Worklist lists each incident for which the current user is the primaryowner.

• Incidents Requiring Classification shows the number of incidents that awaitingclassification. Incidents are organized by priority and impact.

Problem Management Dashboards

Problem Dashboard

Provides managers and staff an overview of existing problems, which states they residein, what the backlog of problems is, and what the high priority problems are. It includesthe following reports.

• Active Problems lists all problems in active states, such as Classification,Assessment, Investigation & Diagnosis, and Pending Change.

• Active Problems by State shows problems that have not been resolved. Theproblems are broken down by state. This graph allows the team to see where mostproblems are in the problem management process.

• Known Error Trend by Category is a graphical trend report, showing the rate thatproblems were submitted over a recent time frame. The submit rates are dividedbased on the category of the problem.


Technical SME Dashboard

Provides technical SMEs easy visibility into problems waiting in a queue and problems forwhich they are the primary owner or a secondary owner. It supports the Group Queues[page 187] feature, and includes the following reports:

• Unassigned Problems in Queue States shows the number of problems that are ineach queue state, and therefore not assigned to a technical SME.

• My Problem Worklist lists each problem for which the current user is the primaryowner.

Change Management Dashboards

Change Dashboard

Alerts change management staff to emergency RFCs and how long other RFCs have beenactive. It includes the following reports.

• Active Changes by State displays the number of changes in each state.

• Change Request Submits by Types breaks down by type how many changes weresubmitted over the past few weeks.

• Change Calendar shows the scheduled changes and when they are scheduled.

Risk Dashboard

Alerts the Change Management team to the risk of upcoming RFCs. The reports on thedashboard use the Risk Analysis survey and the Risk Calculator to determine the risk ofthe changes, and include the following reports.

• Upcoming Changes by Level and Type displays the number of upcoming changesbroken down by type. These changes have a completed Risk Analysis survey.

• Upcoming Changes Avg Risk Score by Type breaks down the average risk scorefor the upcoming changes based on change type.

• Upcoming Changes Risk Ratio shows the upcoming changes that have acompleted Risk Analysis survey compared to the changes that do not have acompleted survey.

• Upcoming High Risk Changes lists upcoming changes with a risk score greaterthan 39. The items are sorted based on implementation start dates.

Change Implementer Dashboard

Provides easy visibility into problems waiting in a queue and problems for which they arethe primary owner or a secondary owner. It supports the Group Queues [page 187]feature, and includes the following reports:

• Approved Changes Queue shows approved changes by change type.

• My Change Worklist lists each RFC for which the current user is the primaryowner.

Change Manager Dashboard

Enables managers to quickly see changes they are responsible for.



• Changes Requiring My Action shows changes that need action from the changemanager who is currently logged in.

• Change Manager Distribution shows all changes across all states for the changemanager who is currently logged in.

CMS Dashboard

The CMS Dashboard gives an overview of your existing assets, incidents associated withthose assets, and ongoing requests for change.

• Configuration Items by Type gives an overview of the distribution of assets thatyou have across your company.

• Configuration Items with non-Baseline States shows a breakdown of all activeCIs (that is, CIs that are not in the Baseline Pending, Active Baseline, orInactive Baseline states).

Note: This report does not include service CIs, which are high-levelcategories of individual CIs.

Service Requests Views

Request management views are available when the Service Requests application groupis pinned to the Work Center toolbar and is selected.

Dashboards and activity views are provided for each application, as described in thefollowing sections:

• Service Request Dashboards [page 103]

• Knowledge Dashboard [page 104]

Service Request Dashboards

Along with the following Dashboard views, the Service Request application containsactivity views that show requests that the current user is responsible for, along with allactive requests.

Service Request Dashboard

The Service Request Dashboard is designed to give managers and staff an overview ofexisting requests and possible problem areas. It includes the following reports.

• Active Requests by Type gives an overall view of the distribution of requestsbased on their type.

• Active Requests by State shows requests and whether the number of requests hasreached a threshold. This graph allows the team to be proactive in addressing issuesand keeping them under the critical threshold.

• Requests Time in State (SLA) shows the duration of time that requests remain ineach state. Requests are grouped by priority.

• Requests Elapsed Time by Type shows how long current requests have been in anopen state such as Business Approval, Classification, or Fulfillment.


Worklist Dashboard

The Worklist Dashboard is designed to give fulfillers easy visibility into requests waiting ina queue and requests for which they are the primary owner or a secondary owner. Itsupports the Group Queues [page 187] feature, and includes the following reports:

• Unassigned Requests in Queue States shows the number of requests that are ineach queue state, and therefore not assigned to a fulfiller.

• My Request Worklist lists each request for which the current user is the primaryowner.

• Requests where I am the Secondary Owner lists each request for which thecurrent user is a secondary owner. A request can be assigned to anyone who is asecondary owner.

Knowledge Dashboard

The Knowledge Dashboard gives an overview of the existing Knowledge Center articles,trend lines of published articles, and articles currently in the process of being published.

• Published Articles displays the recently published articles in the same format thatappears in Request Center. Choose from different display options such as filtering todisplay articles in one category.

• Published Articles Trend by Type shows the trend of how many articles are beingpublished each week, based on the article types.

• Articles in Progress shows the open active articles that have not been publishedand that are not in the draft state. After articles are published, they are marked asinactive.

Knowledge Views

Three activity views are provided for the Knowledge Center. By default, system feeds areprovided for each view. These feeds cannot be modified or deleted, but users can addtheir own feeds to the provided activity views.

• Active Articles I'm Working On

• Active Articles I Contributed To

• All Active KM Articles



Part 3: Installation and Configuration


• Chapter 6: Getting Started [page 107]

• Chapter 7: Installing Serena Service Manager [page 111]

• Chapter 8: Configuring Serena Service Manager [page 113]

• Chapter 9: Importing the Solutions [page 115]

• Chapter 10: Promoting the Snapshots [page 117]

• Chapter 11: Post-Installation Tasks [page 125]




Chapter 6: Getting Started

This section discusses the tasks that you perform before installing Serena ServiceManager.

• Overview [page 107]

• Serena Service Manager Installer Components [page 107]

• Pre-Installation Checklist [page 109]

OverviewThe Serena Service Manager install requires that you have a complete and functionalSerena Business Manager installation first. You must follow the steps in the SBMInstallation and Configuration Guide to install SBM before you install Service Manager.

This guide describes how to install Service Manager using the Service Manager installer.You will run the installer on one or more SBM servers, depending on how you installedSBM.

The exact Service Manager install process depends on a variety of factors, such as thelocation of the SBM components that you have installed. For example, you must install allof the SBM components in order to have a working installation; however, you could installtwo components, such as SBM Application Engine and Application Repository, on differentservers. Therefore, you must run the Service Manager installer on both servers (inaddition to the server that hosts SBM Common Services).

Serena Service Manager Installer ComponentsThe following components are delivered as part of every Service Manager installationdepending on which underlying required SBM components are detected on the server:

• Solution Files [page 107]

• Framework Files [page 108]

• Service Level Agreement (SLA) Files [page 108]

Solution Files

The solution files contain the workflows and data models that comprise each of theService Manager process apps. The Service Manager installer delivers the followingsolution files on the server that hosts SBM Application Repository:

• Serena Request Center (SRC) – Includes the process apps associated withRequest Center:

▪ SRC - Starter Pack Forms - IT

▪ SRC - Knowledge Management

▪ SRC - Service Request


• Serena Service Manager (SSM) – Includes the process apps associated withService Manager:

▪ SSM - Change Management

▪ SSM - Configuration Management System

▪ SSM - Asset Management

▪ SSM - Incident Management

▪ SSM - Problem Management

▪ SSM - Integrations

If you are upgrading from an earlier version, it is likely that you modified these processapps; therefore, the solutions that are delivered by the installer are not automaticallydeployed to your default environment. You can either use SBM Composer to compare andmerge changes and then deploy the apps or you can promote and deploy the newversions, which will overwrite your existing modifications. For detailed upgradeinstructions, refer to the Serena Service Manager On-Premise Upgrade Guide.

After the installation is complete, the solution files can be found in the Solutionsdirectory located here: SBM InstallationDirectory\Serena\Solutions\SSM\Solution. The file names are composed of theversion number of the current solution and the .sln extension. After you upgrade to anewer version of a solution, the previous .sln files are no longer used, but they are notdeleted. You can delete these previous solution files to save space.

Framework Files

The framework files augment your underlying SBM installation to enable certain ServiceManager features. The framework files include new templates, images, and code that arebackward compatible with your existing installation.

For example, the Service Manager installer provides a set of HTML templates to displaythe Request Center. The HTML templates are installed on your SBM Application Engineserver, but do not affect your current SBM installation.

The following important framework files are delivered by the Service Manager installer onthe server that hosts the SBM Application Engine:

• Custom e-mail templates that are used by the Service Manager process apps.

• Framework files that are required for the Knowledge Center.

• Relationship Explorer framework files, including the files needed for the graphicalvisualizer, which is used to visually depict relationships between items.

Service Level Agreement (SLA) Files

Service Level Agreements (SLAs) define the level of service that an organization commitsto its customers. SLAs contain performance metrics that correspond to thesecommitments. You define these metrics in SBM Application Administrator. The SLA filesare delivered by the Service Manager installer on the server that hosts SBM CommonServices.



Pre-Installation ChecklistThe following checklist describes the tasks that you need to perform before installingSerena Service Manager.

• You must successfully install, configure, and verify SBM 11.1 or higher on one ormore servers according to the steps in the SBM Installation and Configuration Guide.This means you will have a fully functional SBM system and database created beforeyou install Serena Service Manager.

• Ensure that you have at least one administrative user who has sufficient privileges toimport and promote the solution files in SBM Application Repository. For details onthese privileges, see the SBM Application Repository Guide.

• If your SBM installation is distributed among multiple servers, determine whichservers host the following SBM components:

▪ SBM Application Engine

▪ SBM Application Repository

▪ SBM Common Services

You will run the Service Manager installer on the server or servers that host theseSBM components.

• As of Serena Service Manager 5.0, you must ensure that your server has at least4GB of RAM. If you are using a distributed installation, you must ensure that eachService Manager server has 4 GB of RAM.

CAUTION:

4GB of RAM is required to run Service Manager. You may encounterproblems running the SBM Tomcat service with less RAM.

• If you are using multiple environments in SBM (such as development, test, andproduction), you must ensure that each environment has its own instance of SBMCommon Services (not a shared instance). SBM Application Repository is the onlycomponent that can be shared by multiple environments.

• Procure and install licenses for the solutions that you intend to use. Note that theSLA feature is enabled with any of these solution licenses.

• For Oracle systems, the Oracle schema user requires a certain set of roles andprivileges to enable "Oracle Text" for use with the Social Widget control that isenabled by default in the Service Manager process apps. See solution S133641 fordetails.

Important: You must apply these roles and privileges to the Oracleschema user prior to promoting or deploying the apps.

• For SQL Server systems, you must ensure that "Full-Text Indexing" is enabled in theDBMS. Note the following:

▪ In SQL Server 2005, "Full-Text Indexing" is enabled automatically once yousuccessfully deploy any process app in which the Social Widget is enabled, as


http://knowledgebase.serena.com/InfoCenter/index?page=content&id=S133641

long as the "Full-Text Search" feature was selected during the SQL Server DBMSinstallation.

▪ In SQL Server 2008 and later, "Full-Text Indexing" is selected by default for alldatabases, as long as the "Full-Text Search" feature was selected during the SQLServer DBMS installation.

Note: The Full-Text Search feature in SQL Server is an optional installationcomponent. Therefore, first verify that the feature is installed in SQLServer. To verify this, right-click the database in SQL Server, selectProperties, and then select the Files page. “Use full-text indexing” shouldbe selected.

• If you are upgrading from a previous version of Service Manager, before youupgrade, log in to SBM Application Repository, and save both the original and latestversions of each process app to file. After you save both copies, follow the stepsdescribed in the Serena Service Manager On-Premise Upgrade Guide to create acomparison report that highlights the changes you have made to each process app.You will use this report to help you decide which changes you want preserve in thenew version of each process app.



Chapter 7: Installing Serena ServiceManager

Before you install Serena Service Manager, complete the tasks described in Chapter 6:Getting Started [page 107]. A message appears during the install if SBM is not currentlyinstalled. If one of the required SBM components is not installed, the installer prompts youto finish the install on the server or servers that host the missing components.

Install Process OverviewThis section provides an overview of the entire install, configuration, and set up processfor Serena Service Manager. Each step listed below is described in more detail later in thisguide.

To install Service Manager in an on-premise SBM system:

1. Install and configure SBM 11.1 or higher as described in the SBM Installation andConfiguration Guide.

2. Ensure that the SBM Notification Server is running. This is important because certainWeb services in Service Manager are triggered by notifications.

3. Close SBM Configurator on all servers if it is open.

4. Run the installer as described in Running the Installer [page 112] and install ServiceManager on the SBM server or servers that host the following components:

• SBM Application Engine

• SBM Application Repository

• SBM Common Services

5. Launch SBM Configurator, set the appropriate SLA load level as described in Chapter8: Configuring Serena Service Manager [page 113], and then click Apply. Confirmthat the IIS and SBM Tomcat services restart.

6. Access Serena Work Center using the following URL:


When Work Center is accessed for the first time after the install is complete, theloading time will be longer than normal, which may cause a timeout to occur. This isdue to the server loading data associated with the new solutions. The slow loadingtime is a onetime occurrence. See Accessing Serena Work Center [page 113] formore information.

7. Import the solution files as described in Chapter 9: Importing the Solutions [page115].


8. Promote the solution snapshots as described in Chapter 10: Promoting theSnapshots [page 117].

Important: If you are upgrading from a previous version and you want topreserve modifications you have made to existing process apps, see theSerena Service Manager On-Premise Upgrade Guide for steps to preserveyour changes before you promote new versions of the process apps.Promoting the new snapshots overlays any existing modifications that youhave made to your existing workflows.

Running the InstallerTo install Service Manager:

1. Run the installer on the server or servers that host the following SBM components:

• SBM Application Engine

• SBM Application Repository

• SBM Common Services

The "Welcome to the Install Wizard" message appears. Click Next to continue.

2. Accept the license agreement. Click Next to continue.

3. Choose the destination folder. This directory temporarily stores files before they arecopied into the appropriate folders inside the SBM installation directory for use bythe SBM Server.

Note: You cannot choose to install in the same directory as your existingSBM installation.

Click Next to continue.

4. The installer detects which SBM components are currently installed on the server. Amessage appears if any of the required SBM components are not detected on theserver. Click Install.

5. Allow the install to complete, and then click Configure to launch SBM Configurator.For details, see Chapter 8: Configuring Serena Service Manager [page 113].



Chapter 8: Configuring Serena ServiceManager

After the installer is finished, you must launch SBM Configurator, configure your SLA loadlevel in the Service Manager tab, and then click Apply to finish the install andconfiguration process. When you click Apply, SBM Configurator updates variousconfiguration files on the server and prepares the system for use. Note that you must stillimport solution files and complete the remaining tasks described in this guide before theprocess apps are ready for your users.

Configuring the SLA Load LevelIn the Service Manager tab, you configure the SLA load level setting.

In the SLA Settings section, use the vertical slider to throttle the load-bearingcapabilities for SLA depending on the number of users and requests that are serviced inyour environment. The SLA engine uses a set of user-defined clauses that are periodicallycompared against new items and change records, which then triggers specific actions if aclause becomes true. The SLA level that you set determines how often the SLA enginecompares the clauses to these items. You can change these settings any time afterinstallation by running SBM Configurator in utility mode.

Note: For distributed installations, you configure these settings directly on theSBM Common Services server (which is where the SLA component is installed).

To configure load level settings for SLA, use the slider to change the load level:

• Low load – Forces SLA to run every 15 seconds. Select this level for an environmentthat services a small number of users and requests.

• Medium load – Forces SLA to run every 10 seconds. Select this level for anenvironment that services an average number of users and requests.

• High load – Forces SLA to run every 5 seconds. Select this level for an environmentthat services a high number of users and requests.

Note: The Service Manager tab appears after the installation is finished, evenif SLAs are not used or not yet defined, regardless which solution licenses havebeen added.

Accessing Serena Work CenterAfter you run SBM Configurator and click Apply, a prompt states that the services mustbe restarted for changes to take effect. Confirm that the IIS and SBM Tomcat services arerunning after the restart, and then launch Work Center using the following URL:



Important: Accessing Work Center immediately after SBM Configurator is animportant part of the installation and configuration process. This enables theSBM Application Engine to import the framework files that comprise SerenaRequest Center.

When Work Center is accessed for the first time after the installation is complete, theloading time will be longer than normal, which may cause a timeout to occur. This is dueto the server loading data associated with the new solutions. The slow loading time is aonetime occurrence.

After you log in to Work Center, launch SBM Application Repository to continue the setupprocess by importing the Service Manager solutions.



Chapter 9: Importing the Solutions

Importing a solution adds all of the snapshots and process apps for the solution to yourSBM Server. The process apps and snapshots are available for promotion after the import.

Note the following about importing the solutions:

• If you plan to import multiple solutions, you can import them in any order.

• Each solution contains a subset of the process apps. You must import all thesolutions if you want to use all the process apps.

• If you encounter any problems with importing solutions, refer to TroubleshootingImports [page 115].

To import a solution:

1. Log in to SBM Application Repository using the following URL:

http://serverName:port/mashupmgr

2. Select the Solutions tab.

3. Import the Serena Service Manager solutions.

Upon successful completion, the imported solutions appear in the Imported solutionslist.

The snapshots contained in the imported solution are now available for promotion. Forsteps on promoting the snapshots, see Chapter 10: Promoting the Snapshots [page 117].

Troubleshooting ImportsIf the import of a solution file fails with an error, you can view the error in theApplication Repository Log in the Advanced tab.

If there are existing applications in the destination environment during the import, thenApplication Repository attempts to upgrade the existing application with the data in thenew application if the internal IDs (UUIDs) are identical. If the internal IDs are differentbut the application names are identical, then the import fails.

Note: Contact Serena support for information on finding an application's UUID.

If the import fails due to identical application names, the workaround is to delete theprocess app in the repository and then re-import the solution. Note that this will deletethe existing process app and all of its associated data, so make sure the app can safely bedeleted. Contact Serena support for more information on this process.




Chapter 10: Promoting the Snapshots

After you import a solution, you can promote the associated snapshots to an SBMenvironment. Promoting the snapshots places the contents of the solution, including allreports, notifications, process apps, and auxiliary table data, onto your SBM Server.

Important: If you are upgrading from a previous version and you want topreserve modifications you have made to existing process apps, see the SerenaService Manager On-Premise Upgrade Guide for steps to preserve your changesbefore you promote new versions of the process apps. Promoting the newsnapshots overlays any existing modifications that you have made to yourexisting workflows.

Note the following:

• You must promote the snapshots before you modify and deploy them. Promotingmaintains data that is necessary for some operations such as maintaining internalIDs and priming Request Center with sample data. Deploying first could causecompatibility problems later on.

• If you import multiple solutions, promote the Serena Request Center apps beforeyou promote the Serena Service Manager apps. If you promote the Serena ServiceManager first, the legacy My Approvals and My Requests tabs appear in RequestCenter instead of the newer versions of these tabs.

• You can promote the process apps in a given solution in any order, except for theSerena Request Center process apps.

Restriction: You must promote the SRC apps in a specific order, becausethe Starter Pack and Service Request process apps contain uniquereferences to one another. This ensures that the proper forms in theStarter Pack process app are available for use in each of the services.Promote the SRC apps in the following order:

1. SRC - Starter Pack Forms – IT

2. SRC - Service Request

3. SRC - Starter Pack Forms – IT (promote again)

4. SRC – Knowledge Management

• It is recommended that you promote all of the process apps for a given solution,except for the SSM - Integrations process app. You should only promote the SSM -Integrations process app if you are using Serena Asset Manager or the AssetDiscovery Adapter.

Tip: Other than the SSM - Integrations process app, if you do not plan touse a particular process app, it is recommended that you still promote it(you do not need to make it available to your users). Each process appreferences other process apps and you will encounter reference errors inSBM Composer when you attempt to modify the process apps if you do notpromote them all.


• If you encounter any problems with promoting the snapshots, refer toTroubleshooting Promotions [page 122].

The following sections describe the promotion steps for the snapshots in each solution:

• Promoting the Serena Request Center Snapshots [page 118]

• Promoting the Serena Service Manager Snapshots [page 120]

• Troubleshooting Promotions [page 122]

Promoting the Serena Request Center SnapshotsPerform the following steps to promote the Request Center snapshots.



2. Select the Snapshots tab.

3. In the Sources drop-down list, select Serena Request Center.

4. Follow the steps below and promote the Request Center snapshots in the orderdescribed in Chapter 10: Promoting the Snapshots [page 117].

a. Select the snapshot, and then click the Promote icon.

b. On the Destination page, select the destination environment, and then clickNext.

c. On the Entities page, select which entities to import. It is recommended thatyou import all of them, but it is not mandatory.

Important: Select the Merge conflicts option if you have alreadypromoted the snapshot to the target environment and you want topreserve changes that you made to the existing application. Forexample, if you want to keep new user roles that you added to anapplication, select the Merge conflicts check box to preserve them inthe target environment after the promotion. If Merge conflicts is notselected, the existing entities will be deleted in the target environment.

The following tables describe which options must be selected for each snapshotand which are optional.Table 1. Entities

Type Notes

Projects Mandatory.

Notifications Optional, but suggested. Not importing notifications meansthat no notifications will be available until you create them.



Type Notes

NotificationRules

Optional, but suggested. Not importing notification rules meansthat notifications will not be sent within the workflow until youadd new notification rules.

Reports Mandatory.

AuxiliaryTable Data

Depends on the process app. See the following table for moreinformation.

TransitionGroups

Mandatory.

Mailboxes Optional.

User FieldSelections

Mandatory.

Templates Mandatory.

Table 2. Auxiliary Table Data

Snapshot Notes

SRC - Starter Pack Forms -IT

No auxiliary data required.

SRC - Service Request• SRC - Client Software: Not required.

• SRC - Computer Models: Not required.

• SRC - Computer Types: Not required.

• SRC - Mobile Carriers: Not required.

• SRC - Mobile Device Platforms: Notrequired.

• SRC - Mobile Devices: Not required.

• SRC - Operating Systems: Not required.

SRC - KnowledgeManagement • KM Categories: Required.

• KM Visibility Group: Required.

Once you have finished making your selections, click Next.


d. If no mappings are needed on the Mappings page, click Next.

e. Review the information that appears on the Summary page, and makeadjustments as needed. Click Promote to finish the operation.

f. Click the refresh icon, and check the Last Promoted column to verify that thepromotion succeeded.

Tip: If you are following the required promotion order, the LastPromoted time for SRC - Starter Pack Forms - IT will be later than theLast Promoted time for SRC - Service Request once you promote SRC- Starter Pack Forms - IT a second time.

g. Repeat this process for each snapshot in the solution.

5. Access the Request Center using the following URL:


If you encounter problems with accessing the Request Center after you have completedthese steps, reset IIS, and then try to access the Request Center again.

The Request Center apps are now accessible and ready for implementation. Complete thetasks described in Chapter 11: Post-Installation Tasks [page 125], and then continue toChapter 12: Serena Service Manager [page 131].

Promoting the Serena Service Manager SnapshotsPerform the following steps to promote the Service Manager snapshots.



2. Select the Snapshots tab.

3. In the Sources drop-down list, select Serena Service Manager.

4. Promote the snapshots (in no particular order) by performing the following steps:

a. Select the snapshot, and then click the Promote icon.

b. On the Destination page, select the destination environment, and then clickNext.

c. On the Entities page, select which entities to import. It is recommended thatyou import all of them, but it is not mandatory.

Important: Select the Merge conflicts option if you have alreadypromoted the snapshot to the target environment and you want topreserve changes that you made to the existing application. Forexample, if you want to keep new user roles that you added to anapplication, select the Merge conflicts check box to preserve them inthe target environment after the promotion. If Merge conflicts is notselected, the existing entities will be deleted in the target environment.

The following tables describe which options must be selected for each snapshotand which are optional.



Table 1. Entities

Type Notes

Projects Mandatory.

Notifications Optional, but suggested. Not importing notifications meansthat no notifications will be available until you create them.

NotificationRules

Optional, but suggested. Not importing notification rules meansthat notifications will not be sent within the workflow until youadd new notification rules.

Reports Mandatory.

AuxiliaryTable Data

Depends on the process app. See the following table for moreinformation.

TransitionGroups

Mandatory.

Mailboxes Mandatory.

User FieldSelections

Mandatory.

Templates Mandatory.

Table 2. Auxiliary Table Data

Snapshot Notes

SSM - AssetManagement • Cost Center: Not required.

• Depreciation Types: Mandatory.

• Hardware: Not required.

• Leasehold: Not required.

• Location: Not required.

SSM -ChangeManagement

No auxiliary tables or data.


Snapshot Notes

SSM -ConfigurationManagementSystem

• CI Categories, CI Sub-Categories, CI Sub-CategoryTypes: Recommended, but not required. If you do notimport the table data, you must populate the tables withdata before using Service Manager.

• Relationship Types: Strongly recommended. If not, youmust add relationship types before you can createrelationships between CIs.

• Model Numbers, Relationships, Software Platforms:Not required. Note that these tables do not contain dataand selecting them to import will have no effect.

• Vendors: Mandatory.

SSM -IncidentManagement

• Resolution Codes: Not required.

• Symptom Codes: Not required.

SSM -Integrations • CI Events: Mandatory.

SSM -ProblemManagement

• Workarounds: Not required. Note that these tables donot contain data and selecting them to import will have noeffect.

Once you have finished making your selections, click Next.

d. If no mappings are needed on the Mappings page, click Next.

e. Review the information that appears on the Summary page, and makeadjustments as needed. Click Promote to finish the operation.

f. Click the refresh icon, and check the Last Promoted column to verify that thepromotion succeeded.

g. Repeat this process for each snapshot in the solution.

The Service Manager apps are now accessible and ready for implementation. Completethe tasks described in Chapter 11: Post-Installation Tasks [page 125], and then continueto Chapter 12: Serena Service Manager [page 131].

Troubleshooting PromotionsThe Activities tab in Application Repository contains a log of the promotions. Whenviewing the logs, you may notice several warning messages, such as the following fromthe promotion log for the SSM - Change Management process app:



WARN -- Unable to create field 'Linked CIs' in table'Changes' because relational table 'Configuration Items' is not defined.

These warning messages are usually due to the related application having not yet beenpromoted to the target environment. In this example, the SSM - ConfigurationManagement System application has not yet been promoted, which means that theLinked CIs relational field in the SSM - Change Management application cannot bedefined successfully. This warning will be fixed once the referenced snapshot has beenpromoted.




Chapter 11: Post-Installation Tasks

After you install and configure Service Manager, import the solutions, and then promotethe snapshots, perform the post-installation tasks that are described in the followingtopics.

• Updating Endpoints [page 125]

• Preparing the System for Use [page 126]

• Setting Authentication for Orchestrations [page 126]

Updating EndpointsAfter you have successfully promoted all of the Serena Request Center snapshots, if youhave a distributed installation, you must update the RESTCaller endpoint that is used bythe SRC - Knowledge Management process app.

To update the endpoint:

1. Log in to Application Repository using the following URL:


2. Open the Environments tab.

3. Select the environment that you used to promote the snapshots.

4. Click the Endpoints sub-tab. A list of endpoints for all the promoted process appsappears.

5. Select the RESTCaller endpoint:

http://localhost:8085/orchestrationutilities/services/RESTCaller

Click the Edit button, and then change the host name in the URL from localhost tothe host name of your SBM Orchestration Engine server.

6. Click Save.

7. Open the Process Apps tab.

8. Select the SRC - Knowledge Management app, and then click the Deploy icon.

a. On the Destination page, select the environment that you used to promoteearlier. Click Next.

b. On the Mappings page, select the RESTCaller endpoint, and then click the Editicon.

c. In the endpoint selection dialog box, select the RESTCaller endpoint thatcontains the host name that you added in step 5. Click Next.


d. On the Summary page, review your selections, and then click Deploy.

The RESTCaller endpoint that is used in the SRC - Knowledge Management process app isnow configured properly.

Preparing the System for UseAfter you have successfully promoted all of the snapshots, perform the following post-installation tasks to prepare the system for your users.

Once you have completed these tasks, you can add auxiliary data, set default field values,assign users to appropriate roles, and define SLAs.

Configuring the My Requests Report

If you want the My Requests report to include incidents, you can modify the report asfollows.

1. Log in to Serena Work Center using the following URL:


2. In the Serena Work Center toolbar, select the Service Requests application group.

3. Click Reports | All Reports, and then edit the Request Center - My Requestsmulti-table report.

4. Add the Incidents table to the Tables to Search list, and then save your changes.

Setting Authentication for OrchestrationsAs of SBM 10.1, security tokens are issued to all authenticated users whether you useSingle Sign-On (SSO) or not, so you are no longer required to provide authenticationcredentials for SBM Application Engine calls in orchestrations. However, you might want tohard-code specific authentication credentials so that the orchestration runs under aspecific user in either of the following scenarios:

• The calling user does not have sufficient privileges.

Tip: Consider creating a dedicated user with API/Script product access andgrant the following privileges in Application Administrator to theConfiguration Management System, Incident Management, and ProblemManagement projects:

▪ View All Items

▪ Update All Items

▪ Transition All Items

• You upgraded from a previous SBM release in which SSO was disabled and you useexternal events in your orchestrations (because no token is issued for anonymousevents).



The following steps explain how to import the process app into SBM Composer, modify theorchestration, and deploy the process app to your SBM Server.

Important: Open all process applications in SBM Composer before attemptingto edit. The applications reference each other, and if one is not imported intoSBM Composer, you could encounter validation errors.

To modify the orchestrations:

1. Open the process app in SBM Composer.

2. Configure the orchestrations (if any) in the process app to be authenticated under auser account that is authorized to run orchestrations:

a. Select an orchestration workflow under Orchestration Workflows.

b. Click the Data Mapping tab in the Property Editor.

c. Under Working Data, add a user account to the userId and password DefaultValues. These values will be used to authenticate the orchestration.

d. Repeat for all orchestrations in the process app.

3. Publish and deploy the updated process app to your environment. You are promptedto save your changes, and the process app is then deployed to your environment. Aconfirmation message will appear in the Message List when the deployment iscomplete.

4. Repeat these steps for each of the process apps. When you open the next processapp, you are prompted to check in the application. Click Yes, and then OK toconfirm (even if no changes were made).




Part 4: Administration

This section contains information about administration tasks for:

• Chapter 12: Serena Service Manager [page 131]

• Chapter 13: Serena Request Center [page 147]

• Chapter 14: Additional Information [page 185]




Chapter 12: Serena Service Manager

This section explains how to set up and administer Serena Service Manager after youhave promoted the solution files. The following topics are included in this section:

• Preparing Applications for Use [page 131]

• Common Customizations [page 135]

Preparing Applications for UseThis section contains the following topics:

• Adding Auxiliary Data to SSM Tables [page 131]

• Enabling Notifications [page 132]

Adding Auxiliary Data to SSM Tables

Service Manager uses data that is stored in auxiliary tables. Data stored in these tables isused to populate fields in related tables. This ensures consistency and control for dataselections.

For example, data in the Cost Center table is used to populate the Cost Center field inassets. Asset managers can add cost center values to the Cost Center table. As assets areacquired and assigned to users, the list of cost centers from the Cost Centers table isused.

You must populate most tables with data. If you followed promotion recommendations,however, some of these tables will have pre-populated data. You can read the promotionrecommendations in Chapter 10: Promoting the Snapshots [page 117].

To add or edit data records to your auxiliary tables, do one of the following:

• Log into SBM Application Administrator as a privileged user, select Auxiliary Data,choose the table from the list, and then click New or search for an existing item toedit.

• Log into Work Center and then select Manage Data from the Options menu. Choosethe table from the list, and then click New or search for an existing item to edit.

The following table shows the auxiliary tables that are packaged with each process app.

CAUTION:

The tables shown in bold type are populated automatically through actions inthe workflow. Do not manually add to or manipulate these tables.


Process App Auxiliary Tables

SSM - Asset Management Depreciation TypeHardwareLeaseholdLocationCost Center

SSM - Change Management No auxiliary tables are packaged with thisprocess app.

SSM - Configuration ManagementSystem

CI CategoriesCI Sub-CategoriesCI Sub-Category TypesModel NumbersRelationship TypesRelationshipsSoftware PlatformsVendors

SSM - Incident Management Symptom CodesResolution Codes

SSM - Problem Management Workarounds

Enabling Notifications

Notifications keep users and staff aware of changes to items. These notifications arecontained in the application snapshots that were promoted during installation.

After the snapshots have been promoted, the administrator must grant allowsubscription privileges to the users who will subscribe to the notifications. Once a userhas been allowed subscription to a notification, the user or the administrator cansubscribe the user to a notification. The administrator grants these privileges using SBMApplication Administrator.

Users manage subscriptions on the Notifications tab of their User Profiles, where theycan subscribe or unsubscribe to notifications.

Service Manager contains specialized notifications and notification templates in addition tothe default notifications usually available with SBM applications. The following are thedefault notifications available for a deployed process app:

• Any [item] changes owner

• Any [item] changes state

• Any [item] changes to inactive

• Any [item] I submitted changed state

• Any [item] I submitted changed to inactive



• Any [item] is submitted

Note: This notification notifies users other than the current user when anitem is submitted.

• I become the owner of any [item]

The following table explains additional or modified notifications available with eachprocess app:


Application NotificationName

Modification to the Notification

IncidentManagement

IM - Incidentsubmittedwhich affectsme

Notifies Affected By user and Additional Contactsusers when an incident is submitted.

IncidentManagement

IM - AutomaticEscalation toL2

Notifies when incident is moved to theInvestigation & Diagnosis state.

IncidentManagement

IM - Resolved Notifies Reported By, Affected By, and AdditionalContacts users when incident is moved to Resolvedstate.

IncidentManagement

IM - ResolvedRepeat Cancel

Notifies user when an incident moves from theResolved state.

IncidentManagement

IM - ResolvedwithWorkaround

Notifies Reported By, Affected By, and AdditionalContacts users when an incident is moved to theResolved by Workaround state.

ChangeManagement

CM - ChangeClosed

Notifies the submitter and the user selected as thecontact when the change request is closed.

ProblemManagement

PM - ProblemClosed

Notifies the submitter and the user selected as thecontact when the problem is closed.

ProblemManagement

PM - Problemsubmittedwhich affectsme

Notifies Affected By user and Additional Contactsusers when a problem is submitted.

ConfigurationManagementSystem

CMS -ConfigurationItemsubmitted

Notifies users that the configuration items theysubmitted were submitted successfully.

Note: There are additional notifications that are used with Service LevelAgreements (SLAs) or OLAs. The rules for these notifications are defined as partof the SLA or OLA configuration.

Service Manager also contains specialized notification templates. For on-premiseinstallations, these templates are prefixed by ITSM and are installed into the followingdirectory:



SBMinstallationDirectory\Serena\SBM\ApplicationEngine\emailtemplate\notificationtemplates

Note: The notification template for SLAs and OLAs is also installed into thisdirectory, and is prefixed by OLA.

Common Customizations• Customizing the Process Apps [page 135]

• General Modifications to Service Manager [page 145]

Customizing the Process Apps

Use SBM Composer to modify the process apps, applications, and orchestrations includedwith Service Manager. This includes designing states, transitions, forms, actions, andother design elements. You also use SBM Composer to create new roles and tie the rolesto particular states or transitions.

The Service Manager process apps contain references to each other; for example, theChange Management application references the Incident Management application. Toeliminate validation errors in SBM Composer, open all of the process apps locally beforemodifying and deploying a specific process app.

To modify the process apps using SBM Composer:

1. Click File | Open | Application Repository and select a Service Manager processapp.

2. Repeat for all Service Manager process apps. This allows reference information to beloaded into the SBM Composer local cache.

3. Open the process app to modify.

4. Modify the process app.

5. Deploy the changes to your server.

For more information on using SBM Composer, refer to the SBM Composer Guide.

For details on customizing specific process apps, refer to:

• Customizing Asset Management [page 135]

• Customizing Change Management [page 140]

• Customizing Incident Management [page 143]

• Customizing Configuration Management [page 143]

Customizing Asset Management

You can customize Asset Management as follows:

Managing the Approval Process [page 136]

Changing Depreciation Calculation Dates [page 136]

Adding Depreciation Types [page 137]


Changing an Asset's Depreciation Date and Recalculating [page 138]

Managing the Approval Process

By default, assets are approved using the Asset Management process app.

You can use these methods to modify the approval process as needed:

• Disable Asset Management Approvals

In Asset Management, change the default value of the Requires Business Approvaland Requires Financial Approval fields from Yes to No.

• Manage Approvals Through Service Requests

In Service Requests, change the default value of the Requires Business Approval andRequires Financial Approval fields from No to Yes. This task can be performed in forthe entire process app in SBM Composer or in SBM Application Administrator forspecific Service Request projects.

To prevent duplicate approvals, disable approvals in the Asset Management processapp and set the Requires Business Approval and Requires Financial Approval fields toread only.

Regardless of the process app you use for asset approvals, you can enforce the processby setting the Requires Business Approval and Requires Financial Approval fields asrequired and as read only. This forces new assets through the approval process.

These tasks can be performed in for the entire process app Asset Management or ServiceRequests in SBM Composer or in SBM Application Administrator for specific projects.

Changing Depreciation Calculation Dates

By default, depreciation is automatically calculated on the first day of every month basedon the calculation set for the Next Depreciation Date field and the "AM - StartDepreciation when Date is Reached" notification. The Notification Server must be runningbefore depreciation calculations can occur.

You can change the frequency of depreciation calculations and the date on whichcalculations occur.

To change depreciation calculation dates:

1. In SBM Composer, open the Asset Management process app.

2. Edit the "Received" transition.

3. Modify the calculation for the Next Depreciation Date field. By default, the Operand1 value is set to "Start of next month." Select a different value that occurs in thefuture.

Tip: For best performance, calculate depreciation monthly rather thanweekly or daily.

4. Repeat these steps for the "In Past" and "Empty" transitions.

5. Deploy your changes.

Customizing Asset Classes

By default, Asset Management tracks assets of the following classes:



• Computer

• Furniture

• Hardware

• Leasehold Improvements (new carpet, for example)

• Office Equipment

• Other Fixed Assets

• Software

Follow these steps to customize asset classes:

1. In SBM Composer, open the Asset Management process app.

2. Edit the Asset Classes field in the Assets table.

3. On the Options tab, modify the asset class values, including the prefixes for eachvalue.

4. Review and modify the following form actions to show and hide values based on yourasset class modifications:

• Form Click: Set asset Name according to asset type (Update form)

• Form Click: Hide panels according asset type (multiple transition forms)

Tip: You can update this form action for one form, then copy the actionto the remaining forms. Be sure to delete the original form action afteryou copy the modified action to a form.

5. Deploy your process app.

Adding Depreciation Types

Depreciation types are stored in the Depreciation Types auxiliary table. The types areused by the Asset Management orchestrations to calculate straight line and decliningdepreciation rates.

The following depreciation rates are provided:

• Double Declining Balance - 3 years




• No Depreciation (no calculations when this is selected)

To add a depreciation type:

1. In SBM Application Administrator, open the Manage Data feature, and then selectDepreciation Types from the Tables list.

2. Click New.


3. Provide a title for the depreciation type.

4. In the Expected Life box, specify the number of months for which depreciationshould be calculated. The number must be divisible by 12.

Depreciation for assets assigned to this type begins on the date set in theDepreciation Start Date field ends at the end of the period you specify here. Thedepreciation start date is typically set when an asset is acquired.

5. Select one of the following depreciation methods:

• 1

Use to calculate straight line depreciation.

• 2

Use to calculate declining balance depreciation.

• 0

Depreciation will not be calculated for this type.

Tip: You can set a default depreciation type by editing the Assets project in SBMApplication Administrator, and then setting a default value for the DepreciationType field. If you want to set a default value for specific asset classes, such ashardware, create a new child project (with Asset Management as the parentproject) for each asset class. Then, set the default depreciation type for thatproject and asset class.

Changing an Asset's Depreciation Date and Recalculating

There are times when you may need to modify an asset's depreciation method, cost, startdate, or salvage value and recalculate the YTD Depreciation, Accumulated Depreciation,and Depreciation End Date for the asset. You must use the "Update Depreciation"transition after you modify the values since the depreciation fields are not calculatedinstantaneously.

In certain cases, the previously calculated Depreciation End Date prevents thedepreciation fields from being updated. To stop the unnecessary overhead of processingassets that are past their Depreciation End Date, assets with an expired end date areignored.

In some cases, when you change an asset's values, the Update Depreciation calculationwill not update the item because its depreciation life has expired. If the calculated fieldssuch as Depreciation End Date, YTD Depreciation, and Accumulated Depreciation are notbeing updated, you can use the "Reset Depreciation End Date" transition to clear theDepreciation End Date field. This allows depreciation orchestrations to run again. The"Reset Depreciation End Date" transition is only available to administrators.

Enabling the Service Requests Integration with Asset Management

You can configure service request projects so that service requests in fulfillment can beassociated with financial assets. For details, refer to Asset Management Integrations[page 61].

To enable the Service Requests integration:

1. Open SBM Application Administrator.



2. Click Projects, and then expand the SRC - Service Request node in the navigationpane.

3. Expand the Service Request project list.

4. Edit each project (service) you want to integrate with the Asset Managementapplication.

5. On the Default Fields tab, search for the Use SSM Asset Management field, andthen edit the field.

6. On the Attributes tab, change the Default Value setting to one of the followingoptions:

• Yes

Enables the integration.

• No

Disables the integration.

Tip: If you want to enable the Asset Management integration for allservice requests, enable this setting at the highest Service Requestproject. Otherwise, enable the integration for specific request projects.For example, you may want to enable the integration for new hardwareand software requests, but not for password reset requests.

Mapping User Field Selections

The following table lists user-type fields that are mapped for the "Submit from SR"transition in the Service Request process app to fields in the Asset Management processapp.

To ensure that users have valid selections in these fields as they work with linked assetsand service requests, verify that users are assigned to the listed roles for both processapps.

If you do not want to assign users to these roles, you can add them as selections to theindividual fields in each process app.

Both of these tasks are performed in SBM Application Administrator.

Service Requests Process App - Submit from SR Transition

ServiceRequests Field

Service RequestRoles

AssetManagement Field

Asset ManagementRoles

Purchaser Purchasing Purchaser Asset ManagerPurchasing

Fulfillment Group Fulfiller IT Group Asset Manager

Fulfiller Fulfiller IT Asset Manager Asset Manager

Financial Reviewer Financial Approver Financial Reviewer Financial Approver


ServiceRequests Field

Service RequestRoles

AssetManagement Field

Asset ManagementRoles

Affected User User Employee Employee

Business Reviewer Business Approver Business Reviewer Business Approver

Importing Assets

There are multiple ways to import assets into the Asset Management process app:

• Import Existing Assets from a Spreadsheet

Use the Import Data feature in SBM Application Administrator to import assets thathave already gone through approval process. In this case, import items into the"Verify Import" state.

From the "Verify Import" state, you can add an asset to the CMDB or link the assetto an existing CI.

You can then use a "mass update" to move items to the "Acquired" state so they canmove to the inventory management and maintenance phase of the process.

• Import New Assets from a Spreadsheet

Use the Import Data feature in SBM Application Administrator to import assets thatneed to go through approval process. In this case, import items into the "Planning"state. Imported assets can then move through the approval process.

• Import from Configuration Items (CIs)

Run the "Active Configuration Items Without an Asset" report to see CIs that are notassociated with an asset. Select multiple assets, and then select the Update AllChecked box. Select the Add Asset to AM from Any transition, and then clickNext. The selected assets are added to the "Verify Import" state in the AssetManagement process app and are linked to the CIs you selected in the report.

This task can be performed in Serena Work Center or in the SBM User Workspace.

Customizing Change Management

• Modifying the Risk Calculator and Survey [page 140]

• Changing the Impact Level Threshold for Change Management [page 0]

• Enhancing the Implementation Process [page 143]

Modifying the Risk Calculator and Survey

You can modify the risk calculator and survey so that it reflects your company'sprocesses. This topic describes how to do this.

The Risk Calculator uses a summation field to add the values of the weighted selections.The summation value is then evaluated using a JavaScript that adds a risk level of eitherLow (0-20), Medium (21-40), or High (>40).

The Risk Level is configured to only display a result when the Risk Analysis Completedfield is set to Yes. This field is automatically updated by a JavaScript to Yes if any of the



four survey fields contain an answer. After being set to Yes, the weighted values aresummed and the results displayed. If not, the Risk Level displays Questionnaire NotCompleted.

You can modify the risk survey and calculator, such as the risk level thresholds, thequestions, or the weightings of the answers. The modifications are performed in SBMComposer, and then deployed to your server.

The following are some changes that you could make to the survey:

• Make the survey mandatory by marking all of the fields as Required.

• Modify the weighted responses to questions by editing the field and setting theweighted values on the Options tab of the Property Editor for the field.

• Change existing questions and answers by modifying the field names anddescriptions in the Property Editor for the field.

• Add new questions by adding Single Selection fields with weighted values. To addthe new questions:

▪ Modify the Total Risk Score Summation field to include the weighted value inthe result.

▪ Add the new field to the Risk tab on every form in the Change Managementprocess application.

▪ Add the field name to the JavaScript contained in the calcRisk_TransitionHTML/JavaScript widget. This script checks whether the question was answered.The following JavaScript excerpt is an example of how to add a new field:

AddChangeCallback("ESTIMATED_EFFORT", funcLinkEstimatedEffort);AddChangeCallback("RISK_ANALYSIS_Q1", funcAnalysisCompleted);AddChangeCallback("RISK_ANALYSIS_Q2", funcAnalysisCompleted);AddChangeCallback("RISK_ANALYSIS_Q3", funcAnalysisCompleted);AddChangeCallback("RISK_ANALYSIS_Q4", funcAnalysisCompleted);AddChangeCallback("RISK_ANALYSIS_Q5", funcAnalysisCompleted);AddChangeCallback("NEW_FIELD_NAME", funcAnalysisCompleted);

• Change the range for how risk is calculated by editing the JavaScript on the stateforms. The JavaScript is contained in the calcRisk_State HTML/JavaScript widget.For example, you would make the following change to add an additional riskcategory for Medium-High for risk scores between 31 and 40:

<script type="text/javascript">AddLoadCallback(calcRisk);function calcRisk() \{var answered = GetFieldValue("RISK_ANALYSIS_COMPLETED");if(answered == "Yes") \{var score = parseInt(GetFieldValue("TOTAL_RISK_SCORE", 0));if(score > 40) \{ SetFieldValue("RiskScoreLabel", "(High Risk)"); }else if( score > 30) \{SetFieldValue("RiskScoreLabel", "(Medium-High Risk)"); }else if( score > 20) \{SetFieldValue("RiskScoreLabel", "(Medium Risk)"); }else \{ SetFieldValue("RiskScoreLabel", "(Low Risk)"); }\}else \{


SetFieldValue("RiskScoreLabel", "(Questionnaire Not Completed)");\}\}</script>

• Change how the estimated effort is weighted by modifying the JavaScript on thetransition forms. The JavaScript is contained in the calcRisk_Transition HTML/JavaScript widget. For example, to set everything to less than one-half of a day (12hours) as low impact and everything else as high impact:

<script type="text/javascript">var funcLinkEstimatedEffort = function()\{

var effort = GetFieldValue("ESTIMATED_EFFORT", "");var implTimeFld = GetFieldByName("RISK_ANALYSIS_Q5");

if(effort != "") \{//Convert Estimated Effort field from milliseconds to hours

var hours = effort / 3600000;

if(hours > 12) \{ implTimeFld.selectedIndex = 3; \}else \{ implTimeFld.selectedIndex = 1; \}

DisableField("ESTIMATED_EFFORT");\}

\}

For more information on working with fields, refer to the SBM Composer Guide.

Impact analysis uses an Impact Level field value to determine how a change item isrouted. This value is based on the threshold into which an impact analysis score falls. Thethresholds are defined in application variables in SBM Composer, but can be overriddenusing SBM Application Administrator. The default thresholds follow:

• Low is a score less than 15.

• Medium is a score greater than or equal to 15 and less than 30.

• High is a score greater than or equal to 30.

To change the default thresholds:

1. Select the Changes project in Application Administrator.

2. Select the Variables tab.

3. Select the High Impact Level Threshold application variable and then clickDetails.

4. Select the Allow Overrides check box.

5. Type the new number in the box.

6. Save your changes.

7. Repeat these steps for the Medium Impact Level Threshold application variable.



For details on this feature, refer to 3. RFC Impact Analysis [page 35].

Enhancing the Implementation Process

Change Management is designed with the assumption that implementation steps varybetween companies, and that the steps will be tailored according to the company'sprocesses.

For example, you can:

• Add additional states to track the implementation steps.

• Link the Change Management process to your existing Release Management processusing Web services.

• Use subtasks to track the implementation tasks, automatically transitioning RFCs orproposals when the subtasks are completed.

Customizing Incident Management

Disabling "Submit on Behalf"

Use the following steps to disable the ability for one user to submit a request or anincident on behalf of another user.

To disable submit on behalf:

1. In SBM Application Administrator, edit one of the following projects:


• Service Request

Note: These are parent projects in the Incident Management and ServiceRequest projects apps. You can follow the steps in this section to enable ordisable this feature for specific child projects in these process apps asneeded.

2. Select the Default Fields tab.

3. Search for the Submit on Behalf Enabled field, and then edit the field.

4. On the Attributes tab, set the default value to No.


6. Repeat these steps as needed for additional projects in the Incident Managementand Service Request process apps.

Customizing Configuration Management

• Managing CI Types [page 144]

• Associating an Icon with a CI Category [page 144]


Managing CI Types

If you use the integration between the Configuration Management Systems and AssetManagement process apps, you must follow these steps when you add, edit, or delete CITypes. This ensures CIs are correctly mapped to assets created from either process app.

1. In SBM Composer, open the SSM - Configuration Management Systems process app.

2. Select the Data Design tab, and then edit the Type field. On the Options tab,modify the types, including the prefixes for each type.

3. Select Workflow Design.

4. In the Rules area, select the export rule that applies to your type. For example,"Router" would typically apply to the "CMS - Export Hardware Rule."

5. Select "Type" inside the rule, and then add or remove types to match themodifications you made in step 1.

6. In the Rules area, select the rule that applies to your type. For example, "Router"would typically apply to the "CMS - Is Hardware Rule."

7. Select "Type" inside the rule, and then add or remove types to match themodifications you made in step 1.

8. If you added or removed types, select the "CMS - Restrict Post to AM Rule."

9. Add types that you want posted to Asset Management or remove types that you donot want to post to Asset Management.

10. Deploy your process app.

Associating an Icon with a CI Category

Each CI category is represented by an icon, which is displayed in the Relationship Explorerand stored in the CI Categories auxiliary table. By default, certain icons are associatedwith the default categories and a computer icon is associated with new categories. Youcan change an icon by selecting another image stored in a provided library or by enteringa URL to an image stored somewhere else.

Important: To change an icon or associate an icon with a new category, youmust have privileges to the CI Categories auxiliary table.

Note: The images in the library are 64x64 pixels. For optimal viewing, use asquare image with a suitable resolution. If the resolution is too low, the imagecan appear grainy; if it is too high, performance can be slow.

To add or change a CI category icon:

1. Open the CI Categories auxiliary table in the CMS process app by clicking ManageData in the Search pane or by running a report against it. The Manage AuxiliaryData page opens.

2. To change an icon for an existing category, select the category and then clickDetails. To add a new category, click New.

3. For an existing category, click change image. For a new category, type thecategory name and then click new image. The Select an Image window opens.



4. Select an image from the library or enter a URL to an image in the box at thebottom left, and then click OK. If you enter a URL, make sure that all users haveaccess to it (for example, do not use a URL in a restricted domain).

General Modifications to Service Manager

The following sections address questions about some basic modifications that you canmake to the process apps.

Can I use my existing Incident process app?

You can link your existing SBM Incident process app to the Change Management, ProblemManagement, and CMS process apps found in the Serena Service Manager. The procedurefor doing this is beyond the scope of this guide, and it is suggested that you contactSerena Professional Services for help.

Can I use my existing auxiliary tables?

You could have an existing auxiliary table that you want to link to one the processmanagement apps. For example, you could have an existing "vendors" auxiliary table andyou do not want to copy all of the data to the Vendors table included with Serena ServiceManager. You would modify the incident management process app in SBM Composer toreference your existing table.

For details, see SBM Composer Guide.

Can I edit the default reports?

You can edit the default reports that are included with Serena Service Manager. Whensaving edited reports, remember to save the reports under a new name. This will preventyour changes from being overwritten when you upgrade to the next version of SerenaService Manager.




Chapter 13: Serena Request Center


• Preparing Applications for Use [page 147]

• Configuring Request Center [page 148]

• Troubleshooting Request Center [page 184]

Preparing Applications for UseThis section contains the following topics:

• Adding Auxiliary Data to Request Center Tables [page 147]

• Enabling Notifications [page 148]

Adding Auxiliary Data to Request Center Tables

SRC uses data that is stored in auxiliary tables. These tables must be populated withinformation to use the solution; however, the tables are meant to be added to as you addmore information into your systems.

To add or edit data records to your auxiliary tables, do one of the following:

• Log into SBM Application Administrator as a privileged user, select Auxiliary Data,choose the table from the list, and then click New or search for an existing item toedit.

• Log into Work Center and then select Manage Data from the Options menu. Choosethe table from the list, and then click New or search for an existing item to edit.

Certain fields in the provided auxiliary tables have default values and dependenciesdefined, but you can tailor these in SBM Composer. The values determine which selectionsare available when working with requests, incidents, problems, changes, and CIs.

The following auxiliary tables are packaged with the SRC - Service Request process app:

• SRC - Client Software

• SRC - Computer Models

• SRC - Computer Types

• SRC - Mobile Carriers

• SRC - Mobile Device Platforms

• SRC - Mobile Devices

• SRC - Operating Systems


The following auxiliary tables are packaged with the SRC - Knowledge Managementprocess app.

• KM Categories

• KM Visibility Group

Enabling Notifications

Notifications keep users and staff aware of changes to items. These notifications arecontained in the application snapshots that were promoted during installation.

After the snapshots have been promoted, the administrator must allow users to subscribeto the notifications. This is set for each notification in the SBM Application Administrator. Auser or an administrator can then subscribe the users to the notifications.

Users manage subscriptions on the Notifications tab of their User Profile, where they cansubscribe or unsubscribe to notifications after they have been allowed to subscribe tothem.

Configuring Request CenterUsers with the Remote Administration privileges can customize Request Center. Thesemodifications affect all users. Users cannot personalize Request Center.

On-demand administrators must be a member of the Administrator group.

To configure Request Center, log in using the following URL:


Tip: If you were already logged in to the Request Center, refresh your browser.This ensures that you have the latest updates to Request Center and that youwill not overwrite someone else's updates. (When you log in, the RequestCenter properties are cached locally. Failing to refresh will use the cachedproperties instead of the latest properties in the database.)

This section contains the following topics:

• Configuring the Catalog View [page 148]

• Adding Tabs to Request Center [page 158]

• Configuring the Knowledge View [page 160]

• Configuring the Requests View [page 166]

• Configuring the Approvals View [page 169]

• Customizing the Request Center Properties [page 172]

• Localizing Request Center Strings [page 175]

Configuring the Catalog View

You can organize the Catalog view so that users can easily find service requests.

You can add and customize:



• Category Containers

Containers provide a way to group categories. For example, you can create a "UserServices" container, then group "HR Services" and "IT Services" categories in thatcontainer.

Category containers are listed in the Browse Categories section.

A down arrow on the category icon indicates that the container includes othercontainers.

An up arrow indicates that users can navigate back to a parent container or Home.

For details, refer to Defining Category Containers [page 150] and Creating "Nested"Containers [page 150].

• Categories

Categories provide a way to group service requests. For example, a "HR Services"category may contain service requests for "Benefits Change" and "ContactInformation Change."

Categories are listed in the Browse Categories section for Home or the selectedcategory container.

When users select a category, the service requests assigned to that category appearin the lower half of the content pane.

For details, refer to Defining Categories [page 151].

• Service Requests

Service requests provide a way for users to submit new requests into an SBM projector to access an external Web page. Users can browse service requests or search forthem with the search filter.

For easy navigation, you can assign service requests to categories. You can alsochoose to highlight service requests on a container overview page or in special Homeview categories, such as Favorite, What's New, or Featured.

For details, refer to Defining Service Requests [page 152].

• Sections

Custom sections enable you to embed relevant Web sites, Work Center activityviews, and SBM reports on the Catalog view. This ensures that your chosen contentappears to your users when they open Request Center.

Home is the top level of the Catalog view and is always shown in the first positionBrowse Categories section. You can add category containers and categories to Home.

You can create a catalog hierarchy by adding catalog containers and selecting differentparent categories. For details, refer to Creating "Nested" Containers [page 150].


Within each level of the Browse Categories section, containers and categories arearranged by defined display order and then alphabetically if the display order is the same.

Defining Category Containers

Use containers to organize categories, which contain sets of services requests.

• Creating Containers [page 150]

• Creating "Nested" Containers [page 150]

• Modifying Containers [page 150]

Creating Containers

To create a category container:


2. Click + Category Container.

3. Enter a Name and Description.

4. Choose a display image by clicking Change image. You can choose from existingimages or insert a URL. For best results, use an image that is 64 x 64 pixels. Forinformation about the image picker, see Using the Image Picker [page 173].

5. Select the Display Order for the category by dragging the slider. The lower thenumber, the further to the left it will appear.

6. Select a parent container. If you do not select a parent container, your newcontainer is shown on the Home view.

7. Click Save.

Creating "Nested" Containers

You can "nest" containers to create a hierarchy.

To nest containers:

1. Create a container, and then select None from the Parent Container drop-downlist.

2. Create additional containers, and then select the parent containers from the ParentContainer drop-down list.

3. Add categories to each container as needed. Refer to Creating Categories [page151].

Modifying Containers


2. Navigate to the container you want to modify, and then select the container.

3. Click on the appropriate icon to edit, copy, or delete the container.



Note: If you attempt to delete a parent container that contains categories, youare warned that you must first reassign the categories to different containers.

For details on localizing container names and descriptions, refer to Localizing RequestCenter Strings [page 175].

Defining Categories

Use categories to organize service requests.

• Creating Categories [page 151]

• Modifying Categories [page 151]

Creating Categories

To add a new category:


2. Click + Category.

3. Enter a Name and Description. Users can search for the information you providehere.


5. Select the Display Order for the category by dragging the slider. The lower thenumber, the further to the left it will appear.

6. Select a parent container. If you do not select parent container, your new categoryis shown on the Home view.

7. Click Save.

Modifying Categories

To edit, clone, or delete a category:


2. Search for or navigate to the category you want to modify.

3. Click on the appropriate icon to edit, copy, or delete the category.


Note: Before you delete a category, you must first edit each service requestassigned to the category and assign it to a different category or clear the Showin Catalog check box. Once all service requests are reassigned or hidden, usersno longer see the category, but it remains visible to administrators so it can beeasily restored.

For details on localizing category names and descriptions, refer to Localizing RequestCenter Strings [page 175].

Defining Service Requests

Service requests use SBM projects as an entry point to IT services.

Consider the following information as you manage service requests:

• There is a one-to-one relationship between projects and service requests. Alert icons

appear when you are customizing the catalog if multiple service requests sharethe same project or if a project assigned to a service request has been deleted.

• When you associate a service request to a project, that project is removed from theproject tree in Work Center. To submit into the project, users will use the associatedservice in the project tree. This means that if you decide to name the service andproject differently, users might not be able to search for the project when it becomesassociated with the service.

• Users can only see service requests associated with projects they have privileges tosubmit items into.

• When you delete a service request from Request Center, it is hidden from users, butis still visible to administrators (its icon has a blue circle overlaid on it). To restorethe service request for users, edit it, and then select the Show in Catalog checkbox.

• Creating Service Requests [page 152]

• Modifying Service Requests [page 155]

Creating Service Requests

To add a service request:

1. Select Customize | Service Request Catalog.



2. Click + Service Request.


4. Enter a Name and Summary for the new service request. The summary appears asa quick description. Users can search for the information you provide here.

5. From the Service Request Category option, select one or more categories towhich the service request should be assigned.

6. Enter a longer description in the Description box. The long description appearswhen users expand the service request in Request Center. Users can search for theinformation you provide here.

7. Enter the Charge Back cost. This is the cost that user or the user's department willincur when the service request is completed successfully. Note that this field is onlyshown to users if you enter a charge back value.

8. Select whether you want to display the service request under the Favorite, What'sNew, and Featured sections in the home view of the Catalog tab.

9. Select the Display Order for the service request by dragging the slider. The lowerthe number, the further to the left and the higher it will appear on the Catalog tab.

10. Select these Visibility options as they apply:

• Show in Catalog

Select to show the service request to users. If this check box is cleared, theservice is hidden and can only be seen by administrators. Icons for hiddenservices are noted with a blue circle.

• Show in Container Overview

Select this option to show a service request for the overview page for acontainer. If this option is cleared, the service is shown only when users select acategory within a container.

11. Select how the request should be submitted.

• If you select Submit request into Process App, you must define the project tosubmit into and which submit form to use. You can specify the Type and pre-populate the Title field for the new item as well. The following table explains thefields on this form.

Fields Description

ProcessApp

Choose the process app that contains the project to submit into.


Fields Description

Project Select the project to submit into. Projects used by anotherservice request cannot be selected.

You can modify and create projects directly. Select OpenProject to open the selected project in SBM ApplicationAdministrator. Select Add Project to open SBM ApplicationAdministrator, navigate to the appropriate process app andparent project to add a new sub-project. After you add theproject, click to refresh the project list.

SubmitForm

Select a submit form to override the submit form selected for theproject. The form can either be in the selected process app or ina process app that has forms that reference the primary table,such as the forms contained in the Starter Pack Forms processapp.

Note: SRC - Service Request process app includesadditional forms that are designed for transitions otherthan submit. Do not choose these forms, because theJavaScript included on them can cause unexpectedbehavior, such as a disappearing form.

Close onsubmit

Select this check box to close the form after users submit arequest.

Clear this check box to present the submitted request to usersso they can view it and act on it as needed.

Type Select an default item type for the request. Available tem typesare based on the project that you selected.

Title Enter text that will be pre-populated in the Title field of therequest.

Note: The name of this option depends on the displayname of the system Title field in your process app.

CI Service Select the service configuration item (CI) that you want toassociate with the service request. This field is visible if the SSM- Configuration Management System process app is deployed.Values are active CIs. For details, refer to Creating a Service asa CI [page 51].

Show SLASummary

Select this check box to show the SLA summary when users viewservice request details.



Fields Description

SLASummary

Enter the level of service that users should expect. If the projecthas SLAs defined, users will see a list of defined SLAs and theirdescriptions instead of the text entered here.

OverrideSLASummary

This option is available when the selected service project hasSLAs defined. Select this check box to override the SLA definedfor the project.

AlternativeSLASummary

Provide alternative SLA information. The SLA summary definedfor the project will not be shown to users.

• If you select Show external web page, enter the URL. Choose whether todisplay the link in Request Center or in a new window. Optionally, you can add anSLA summary.

Modifying Service Requests

To edit, clone, or delete a service request:

1. Select Customize | Service Request Catalog.

2. Search for the service request you want to edit, clone, or delete.

3. Click the down arrow in the upper right corner, and then click the appropriate icon.


For details on localizing service request names, descriptions, summaries and otherproperties, refer to Localizing Request Center Strings [page 175].

Defining Sections

Use custom sections on the Catalog view to provide information relevant to your users ina single view. Custom sections can display SBM reports, external URLs, and Work Centeractivity views, which provide easy access to items from one or more feeds.

For example, the custom section below displays the Change Requests In Review listingreport and the Active Incidents By Type & Status distribution report.



You can also add reports, URLs, and activity views as custom tabs in Request Center. SeeAdding Tabs to Request Center [page 158].

To add a section:


2. In the Catalog view, click Manage Sections.

3. Click Add Section.

4. Specify the size and display order, enter a section title, and define borders asneeded.

5. Select the section layout. Up to three subsections can be included, which will appearin a row. You can define additional rows by adding new sections.

6. Specify the contents of the section:

• URL


Provide a URL for a Web page, such as your company intranet. Note the followingrequirements:

▪ The URL must be valid.

▪ The URL response header should not contain x-frame-options equals deny orcross-origin.

▪ When SSL is enabled, you can use only https resources for both external andinternal hosts.

▪ Users should have enough permissions to view the content.

Note: Some Web sites do not support embedding on other sites. If youcannot embed an external Web site into Request Center, refer to theWeb site's documentation.

• Add Activity

Click Add Activity to search for a Work Center activity view URL. Note that usersshould have access to the activity view you select.

• Add Report

Click Add Report to search for an SBM report URL. Note that users should haveaccess to the report you select.

7. Click Preview to ensure that the section loads as intended.

8. Click Add Section to add another URL, activity view, or report, and repeat steps4-7.

Note: By default, the display order increments by ten as you add newsections. This provides flexibility when you need to reorder sections afteradding them.

9. Click Save.

10. To exit edit mode, click the Quit edit mode link or select Customize | RequestCenter Portal again.

To edit or delete a custom section:


2. In the Catalog view, click Manage Sections.

3. Edit each section as necessary. To delete a section, click the x in the right-handcorner.

Adding Tabs to Request Center

Use custom tabs to provide information relevant to your users. Custom tabs can displaySBM reports, external URLs, and Work Center activity views, which provide easy access toitems from one or more feeds.



For example, you may want to use a custom tab to display the activities of anorganization, such as IT or HR, or you may want to provide access to your company'sintranet sites.

You can also add reports, URLs, and activity views directly to the Catalog tab so they arevisible when users open Request Center. See Defining Sections [page 156].

To add a tab to Request Center:


2. Click Add Tab.

3. Select Add URL, Add Activity, or Add Report.

Note: If you have enabled legacy tabs in Request Center Properties, youcan also select Add Legacy Approvals or Add Legacy Requests. Toconfigure these tabs, refer to Configuring the Approvals View [page 169]and Configuring the Requests View [page 166].

4. Enter a title for the tab and use the slider to specify where the tab should appear inthe display order.

5. Depending on the type of content, do one of the following:

• URLProvide a URL for a Web page, such as your company intranet. Click Preview toensure that the page loads as intended. Note the following requirements:

▪ The URL must be valid.

▪ The URL response header should not contain x-frame-options equals deny orcross-origin.

▪ When SSL is enabled, you can use only https resources for both external andinternal hosts.

▪ Users should have enough permissions to view the content.

▪ If you add a URL to an SBM report, you must use the Reference Link (notthe Direct URL link).

• Activity

Use the search tool to locate and select a Work Center activity view. Note thatusers should have access to the activity view you select.

• Report

Use the search tool to locate and select an SBM report. Note that users shouldhave access to the report you select.

6. Click Save to add the tab.

7. To exit edit mode, click the Quit edit mode link or select Customize | RequestCenter Portal again.

To edit or delete a tab:



2. Click the edit or delete icon under the tab.

Configuring the Knowledge View

The Knowledge view displays Knowledge Center articles. You can configure perform thefollowing configuration tasks:

• Assigning Knowledge Center Privileges [page 160]

• Creating Article Templates [page 161]

• Managing Article Types [page 163]

• Managing Categories [page 163]

• Importing Articles [page 164]

Assigning Knowledge Center Privileges

The following sections discuss:

• Granting Privileges to Article Viewers [page 160]

• Granting Privileges to Article Contributors [page 161]

Granting Privileges to Article Viewers

Access to Knowledge Center articles is controlled by two mechanisms:

• Article Visibility

When contributors submit articles, they specify whether the article has public orprivate visibility. Any SBM user can access public articles. Private articles can only beaccessed by users or groups that belong to the visibility group that is associated withthe article.

• Visibility Group

If an article has private visibility, the contributor must select a visibility group for it.Administrators assign users and groups to visibility groups as described below. Ifusers are not part of the visibility group for private articles, the article will not bedisplayed for them on the Knowledge tab.

To add, modify, or delete visibility groups, access the KM Visibility Group auxiliarytable by selecting Manage Data from the Options menu in Work Center.

To assign privileges for articles:

1. Log in to http://serverName/tmtrack/tmtrack.dll?shell=srp with a useraccount that has Remote Administration privileges.


3. Do one of the following:

• If the Knowledge tab is displayed, select it and then click the edit icon.

• If the Knowledge is not displayed, click Add Tab and then select AddKnowledge Base.



4. On the Knowledge Center Privileges page, select either Group or User.

5. Type the name (or a few letters of the name) of the group or user you want toassign to visibility groups. Click the search button.

6. Select the group or user in the left pane, and then in the right pane, select thevisibility group or groups you want to assign to that group or user.

7. Click Save to save your changes. To undo unsaved changes and start over, clickDiscard.

Note: Knowledge Center privileges are not transferred to copied groups orusers.

Granting Privileges to Article Contributors

At a minimum, article contributors and publishers must be assigned to the roles discussedin Knowledge Management Roles [page 69].

If you integrate Knowledge Management with Service Manager, consider assigning userswho will contribute articles to roles listed in the following table. This enables these usersto contribute articles as they resolve requests for change, problems, and incidents.

Process App Role

Change Management Implementer

Problem Management Staff

Incident Management Level 1 Tech, Level 2 Tech, or Level 3 Tech

Creating Article Templates

Knowledge Management includes a standard article template that by default contains asingle section and formatting for the Section 1 label. An HTML editor is available so thatarticle contributors can format article content.

To ease the article creation process, users who are assigned to any KnowledgeManagement role can create custom templates and associate them with different articletypes. Templates are primary items submitted into the Knowledge Management -Templates project. Once submitted, they are available for articles.

Once you create custom article templates, you can set them as default templates forprojects. For details, refer to Creating Default Templates [page 162].

To create custom article templates:

1. From Serena Work Center, submit a new item into the Knowledge Management -Templates project.

2. Provide data for the required fields:

• Article Title

Used to name your template.


• Article Type

Used to associate the template with the article type. When contributors load atemplate for an article, the list of available templates is based on the article type.For details on creating article types, refer to Managing Article Types [page 163].

• Article Summary

Used to describe your template.

• Section 1 Label

Used to provide a default label and formatting for articles based on the template.

• Section 1 Content

Used to provide default content and formatting for articles based on thetemplate.

3. Provide default content and formatting for additional sections, if they are available.

4. Submit the template.

By default, active templates are available to associate with articles. To remove atemplate, use the "Inactivate" transition.

Adding Sections to Templates

By default, article temples have a single section. You can add multiple sections.

To add sections to all article templates:

1. Open the Knowledge Management process app in SBM Composer.

2. On the Data Design table, select the Knowledge Management table, and then selectthe Allow Multiple Selections field.

3. On the Attributes tab, set the default value to Yes.

4. Deploy the process app.

Tip: You can also change the default value for the Allow Multiple Sections fieldin SBM Application Administrator. You may choose to do this if you createdefault templates as described in the following section and you want to usemultiple sections for specific templates rather than all templates.

Creating Default Templates

You can create default templates are associated with a specific project. For example, youcan create a project for all "How To" articles, then assign a default template for all articlessubmitted into that project.

To create a default template:

1. Create a custom template, following the steps in Creating Article Templates [page161].

2. In SBM Application Administrator, create a project and assign it to the KnowledgeManagement workflow. For example, create a project named "How To."



3. Select the Default Fields tab for the project, and then search for the Copy FromTemplate field.

4. Edit the field, and then on the Attributes tab, select your custom template from theDefault Value list.

5. Search for the Article Type field.

6. Edit the field, and then on the Attributes tab, select an appropriate default valuebased on your default changes.


Managing Article Types

Article types are used to organize Knowledge Center articles. You can also create articletemplates and associate them with the various article types.

Four article types are provided by default:

• Announcement

• FAQ

• How-to

• Tech Note

You can add, modify, or remove these default types.

To edit the default article types:

1. Open the Knowledge Management process app in SBM Composer.

2. Select the Data Design tab, and then select the Article Type field.

3. On the Options tab in the property editor:

• Click the Plus sign to add an article type.

• Click in the value row to modify the article type name.

• Click Remove to delete an article type.

Note: Remove a type rather than disable it to remove the value fromthe Filter list in Request Center. Existing articles that have the typeyou remove continue to be returned in search results.

4. Click the Validate arrow to ensure your process app will deploy. In some cases, youmay need to modify other settings. For example, the PM Submit transition uses theFAQ type as a default value for the Article Type field and you may need to select adifferent default value if you disable the FAQ type.

5. Deploy the process app.

Managing Categories

Users can filter articles by categories.

Default categories are:


• Access and Directory

• Data and Backup

• Email Management

• Enterprise Applications

• Facilities

• Hardware

• Other

• Software

• Telephone and Network

Users with privileges to add and modify items in the KM Categories table can perform thistask.

To add, modify, or delete categories, use the Manage Data feature to access the KMCategories auxiliary table. You can open Manage Data from the options menu in WorkCenter.

You can choose an image to represent each category by clicking Change image. Formore information, see Using the Image Picker [page 173].

Importing Articles

Administrators can import articles from a spreadsheet using the Import Data feature inSBM Application Administrator. This enables you to quickly populate the KnowledgeCenter with articles from another system.

Spreadsheet Preparation

The SBM Application Administrator Guide contains detailed information about spreadsheetpreparation for data imports. The guide is available on the Documentation Center; searchfor the "About Data Import" section.

General guidelines include:

• Spreadsheets must be .xls file types. If you have an .xlsx file or any other type ofspreadsheet, you must convert it to .xls.

• Spreadsheet columns represent SBM fields and all spreadsheet data is treated astext. Spreadsheet columns must be formatted as Text types.

• Each row represents an item that will be imported, except for the first row, which isused to define columns available for mapping. Data from this row is never imported.

• To preserve formatting, HTML tags must be added to applicable rows in yourspreadsheet.

• Attachments are not imported.

Recommended Field Mapping and Values

Use the guidelines below to populate your spreadsheet before you import articles.




FieldName

Data Values

State Import to "Pending Review" state.

ArticleType

Imported data must match valid selections in Article Type field.

ArticleCategory

Imported data must match valid selections in Article Category field.

ArticleVisibility

Must be Private or Public.

VisibilityGroup

Required for items with Private visibility. You can leave rows empty forPublic articles.

Contributor For auditing purposes, add the user name of the person who imports thearticles to this field.

Publisher For auditing purposes, add the user name of the person who imports thearticles to this field.

Section 1Label

Optional, but you can map to this field to overwrite the default label fortemplates.

When you map to this field, you must provide data in each row.

Section 1Content

Should include the article content you want users to see. Any formattingmust be included as HTML tags in the spreadsheet.

When you map to this field, you must provide data in each row.

Import Process

To import articles into Knowledge Center:

1. Prepare your spreadsheet as explained in Import Process [page 165].

2. Use the Import Data feature in SBM Application Administrator to import data inyour spreadsheet. Be sure to import items to the Pending Review state.

3. In Work Center, run the "Imported Articles in Pending Review" report to Verify thatarticles were successfully imported.

4. From the report, select the items you want to publish, then click the Update AllChecked button at the bottom of the page.

5. From the Actions list, select Mass Publish from Pending Review.

6. Run the Published Articles report to verify that your articles were successfullypublished.


Using Import to Update Articles

You can use the process described in Using Import to Update Articles [page 166] toupdate existing articles. Updated articles need to be republished after the import,however.

To update articles, be sure to select these options in SBM Application Administrator whenyou import your spreadsheet:

• Spreadsheet column for duplicate detection

Select a field that you are sure contains unique data in your articles, such as ArticleTitle or the KM Request ID fields. These fields must be included in your spreadsheetand must contain values that correspond to the articles you want to update.

• If matching record exists in the SBM database

Select the Replace mapped attributes option. This will update the article with datain mapped fields in your spreadsheet.

Configuring the Requests View

By default, the Requests view uses the provided Request Center - My Requestsreport, which returns items submitted by the logged-in user that were modified in thepast 30 days. You can customize the view to use any SBM report to return requests.

To customize the Requests view:


2. Select the Requests tab, and then click the edit icon.


4. Use the search tool to locate and select an SBM report. Note that users should haveaccess to the report you select.



5. Click Save.

You can also choose a custom report for the legacy Requests view, as long as you followthe criteria in Legacy Requests – Report Criteria [page 169].

To customize the legacy Requests view:



• If the legacy Requests tab is displayed, select it and then click the edit icon.

• If the legacy Requests tab is not displayed, click Add Tab and then select AddLegacy Requests.

Note: If Add Legacy Requests does not appear, select CustomizeRequest Center Properties and set Add legacy tabs to Allow.

3. Choose from the available options (which change depending on the detected processapps):

• Request Center default, which uses the Request Center - My Requestscontained in the Service Desk snapshot shipped with Request Center.


• Other report, which allows you to search for and select a custom Listing orMulti-Table report. Reports are available only if they meet the criteria listed inLegacy Requests – Report Criteria [page 169].

If you select Other report, you can select the Use first six report columns tocontrol the headers in the Requests view. The first six columns use the same orderas specified in the Select Columns to Display setting in the report you select toreturn requests.

Note: The report must contain the system fields as noted in the followingsection because they are used for sorting items. The system fields canappear after the six fields you choose as column headers.

To rename the legacy Requests tab:

1. In Application Administrator, click the Localization icon.

2. Select the Values tab.

3. Expand the Request Center category and select the main section.



4. Navigate to the requests string and enter the new name for the tab in theOverride column.

5. Click Save.

Legacy Requests – Report Criteria

Reports must meet the following criteria before you can add them to the legacy Requestsview.

• Report Type

You can choose a single pre-defined Listing report or a Multi-Table report. Multi-Table reports are recommended if you want to return requests from multipleapplications.

• Privilege Category

You cannot select a private report. Also, be sure to verify that all Request Centerusers have access to run the reports and view report results. For example, If youadd the report at the Base Project level, users may not see results in their RequestCenter view.

• Required System fields as display columns

The following system fields must be set as display columns or the report will not beavailable for the b view.

▪ Last Modified Date

▪ Owner

▪ Submit Date

▪ Title

• Search Filter

▪ Query-at-Runtime parameters are not allowed.

▪ Calculation columns are not allowed.

▪ Optionally, use a "Submitter contains any current user" condition to only returnitems submitted by the user who is logged in.

Configuring the Approvals View

By default, the Approvals view uses the provided Requests requiring my approvalreport. This report returns requests in the "Business Approval" and "Financial Approval"states where the logged-in user is the owner.

You can customize the view to display results from any other SBM report as needed. If arequest is returned by multiple reports set for the view, the request is listed only once inthe Approvals view.

To customize the Approvals view:


2. Select the Approvals tab, and then click the edit icon.



4. Use the search tool to locate and select an SBM report. Note that users should haveaccess to the report you select.

5. Click Save.

You can also choose a custom report for the legacy Approvals view, as long as you followthe criteria in Legacy Approvals – Report Criteria [page 171].

To customize the legacy Approvals view:



• If the legacy Approvals tab is displayed, select it and then click the edit icon.

• If the legacy Approvals tab is not displayed, click Add Tab and then select AddLegacy Approvals.

Note: If Add Legacy Approvals does not appear, select CustomizeRequest Center Properties and set Add legacy tabs to Allow.



3. Click + another report.

4. Select the application, enter the report name, and then click Go.

5. Select the report from the results, and then click Add.

To rename the legacy Approvals tab:

1. In Application Administrator, click the Localization icon.


3. Expand the Request Center category and select the main section.

4. Navigate to the approvals string and enter the new name for the tab in theOverride column.

5. Click Save.

Legacy Approvals – Report Criteria

Reports must meet the following criteria before you can add them to the legacyApprovals tab.

• Report Type


You can choose pre-defined Listing and Multi-Table reports. Multi-Table reportsprovide an easy way to return requests from multiple applications.

• Privilege Category

You cannot select a private report. Also, be sure to verify that all Request Centerusers have access to run the reports and view report results. For example, If youadd the report at the Base Project level, users may not see results in their RequestCenter view.

• System fields as display columns

System Field Notes

Last ModifiedDate

Optional, but used to populate the Updated column on approvalitems.

Submit Date Optional, but used to populate the Requested column onapproval items.

State Optional, but used to populate the State column on approvalitems.

Title Optional, but used to populate approval item titles.

• Search Filter

▪ For best results, query states where items requiring approval reside.

▪ Optionally, use an "Owner contains any current user" condition to return onlyitems needing approval from the logged-in user.

▪ Query-at-Runtime parameters are not allowed.

▪ Calculation columns are not allowed.

Customizing the Request Center Properties

Request Center is easily customizable, allowing you to tailor the look and feel of theportal. You can:

• Change the graphic that is displayed in the title bar.

• Modify the information and hyperlink that appears alongside the graphic.

• Show or hide the announcements that are added to Knowledge Center.

• Set the default Catalog view from Standard to Compact mode.

• Change the contact information that appears in the Contact Info link.

The following settings are available on the Request Center Properties page.

Customizing the Banner

Use the following settings to modify the Request Center banner.



• Title

The title appears next to the logo. You can use the toolbar to format the text.

• Image (URL)

Enter an URL to your corporate logo or another image. Remember that all RequestCenter users must be able to access this URL. Do not, for example, use a URL to arestricted domain.

• Image Link

Enter a URL that a user a will be directed to if they click on the logo.

Showing News and Announcements

Select Show in Request Center to display urgent announcements to users in theannouncement bar underneath the banner.

Set the Refresh Interval in minutes for the urgent announcements.

For information about creating and publishing urgent announcements, see CreatingUrgent Announcements [page 95].

Setting the Default Catalog View Mode

Set the default view mode for service list on the Catalog tab.

Standard mode shows a large icon and the service summary; Compact mode only shows asmall icon. Users can expand the service in Compact mode to see detailed information.

The view mode is available once users navigate to a container or category. The standardview is always used for Home.

Managing Tabs

Allow legacy tabs if you want the legacy Requests and Approvals tabs to be available inRequest Center. After you save this setting, select Customize | Request Center Portaland then select Add Tab | Add Legacy Requests or Add Legacy Approvals.

Specify the number of tabs to display in Request Center. The rest are available from theMore drop-down list.

Note: The browser automatically adds tabs to the More drop-down list if thepage would be greater than the browser width.

Setting Contact Info

Add a title and content for the contact info link. The title affects both the dialog title andthe link name. HTML is not supported in the title field.

The contents appear in the dialog. Use the formatting toolbar to apply styles andformatting to the content.

You can hide the Contact Info link by clearing the Show in Request Center checkbox.

Using the Image Picker

The image picker is used to select images for categories and service requests in RequestCenter and for categories in Knowledge Center.


The image picker comes with a collection of images that are arranged in groups. You canview all images or the images in a group. To choose the image, select it and then clickOK.

Tip: Instead of choosing an existing image, you can insert a URL to an image inthe text field. Remember that the image location must be accessible by allRequest Center users.

On-premise installations can add new images to the image picker. The administrator mustperform the following steps on the SBM Server:

1. Add the new PNG image files to the 32x32, 48x48, and 64x64 folders in the followingdirectory:

SBMinstallationDirectory\Serena\SBM\ApplicationEngine\bin\images\shell\SRP\iconlibrary

Note:

• The image size should be 32 by 32 pixels in the 32x32 directory. Theimages in this directory are used for the image picker.

• The image size should be 48 by 48 pixels in the 48x48 directory. Theimages in this directory are used for the service requests.

• The 64 by 64 images are placed in the 64x64 directory are used byboth Request Center categories and KM Categories.

2. Add the new images to the serviceimages.js and categoryimages.js files. Thesefiles are found in the following directory:

SBMinstallationDirectory\Serena\SBM\ApplicationEngine\bin\javascript\shell\SRP

3. Open SBM System Administrator and go to File | Put Files Into Database. Thiswill prevent the new images from being deleted the next time IIS is restarted.



Localizing Request Center Strings

Administrators can use the Localization feature in Application Administrator to translatestrings throughout Request Center.

To translate Request Center strings:

1. Log in to Application Administrator as a user with Remote Administration privilege(or as a member of the Administrator group if on-demand), and then open theLocalization feature.

2. Select the Allow translation for MLS Runtime Objects and Design Objectscheck box on the Settings tab.

3. Determine which type of string you want to translate. Request Center strings arecategorized as follows:

• SLS Design Object Strings

The Request Center SLS design object strings that are available for translationinclude Request Center SLS strings and user-defined object strings. For moreinformation, refer to SLS and Design Object Strings [page 176].

• MLS Runtime Object Strings

The Request Center MLS runtime strings that are available for translation includeKnowledge Management categories and Knowledge Management visibility groups.For more information, refer to MLS Runtime Object Strings [page 178].

4. If you want to translate strings in the SSM process apps, including KnowledgeManagement, promote or re-deploy the process apps.

5. Use one of the following methods to translate the default English (United States)strings into another language:

• Importing a Translated XML File

Ideal for sending strings to a translation vendor or for translating all defaultstrings at one time. See Translating Strings Using XML [page 179].

• Translating Strings Directly in Application Administrator

Recommended for users who are more comfortable working in an interface thanin an XML file or when you are translating a small number of strings. SeeTranslating Strings in Application Administrator [page 182].

On-premise customers can use the Languages, Strings, and String IDs systemauxiliary tables to customize or translate other strings in Request Center that aregenerated by SBM Application Engine (such as labels on the Notes/Attachments tab).For details, refer to the "Customizing and Translating SBM User Workspace Strings"section of the SBM System Administrator Guide.

When translation is complete, users who select the locale for the translated version willsee the translated strings.

If you add locales in the Predefined Locales tab in Application Administrator beforeinstalling or upgrading SSM to 5.2.1 or later, strings are created with default valuesautomatically on the Values page for each predefined locale, and those locales are alsoavailable on the Export page. This enables you to export strings to XML using a


predefined locale, which means you do not need to use search and replace to alter the<locale> values in the XML file.

String Localization Categories

The following topics describe the types of strings that you can translate.

• SLS and Design Object Strings [page 176]

• MLS Runtime Object Strings [page 178]

SLS and Design Object Strings

You can translate SLS design strings on the Values page in Application Administrator oryou can export the strings to XML on the Export tab (under SLS/Design). Review thefollowing sections for more information on each category of SLS strings.

Request Center Strings

Strings in the Request Center category on the Values page are available for translationafter you install Service Manager. You do not need to re-deploy any of the SSM processapps to start translating these strings.

Modify strings in the Request Center category if you want to override the default labels,messages, and fields for Request Center that are not user-defined. Customizable stringsinclude:

• Static page headers

• Static toolbar, button, and control labels

• Hover text for static elements

• Error and warning messages

• Tab names for the legacy Approvals, Requests, and Knowledge tabs (available inthe main section

Request Center (User Defined Objects)

Strings in the Request Center (User Defined Objects) category are available fortranslation after you install Service Manager. You do not need to re-deploy any of the SSMprocess apps to start translating these strings.

Remember: The Allow translation for MLS Runtime Objects and DesignObjects check box must be selected for you to see the Request Center (UserDefined Objects) category.

Strings available for localization are listed below, followed by the corresponding sectionin Application Administrator in parenthesis.

Categories and Category Containers

• Name (SRC Category Name)

• Description (SRC Category Description)

Services

• Name (SRC Service Name)



• Description (SRC Service Description)

• Summary (SRC Service Summary)

• Charge back (SRC Service Property "chargeback")

• SLA summary / Alternative SLA summary (SRC Service Property "service level")

Request Center Properties

• Banner title (SRC Catalog property "title")

• Contact info title (SRC Catalog property "contactinfo_title")

• Contact info content (SRC Catalog property "contactinfo_content")

Tip: If the strings above are not visible under Request Center (User DefinedObjects), try customizing the Request Center properties and then refreshingthe view in Application Administrator.

When you add custom tabs and custom sections, additional strings appear for each newelement. For example:

• SRC Catalog property "tab_1_title"

• SRC Catalog property "tab_2_title"

• SRC Catalog property "block_1_title"

• SRC Catalog property "block_2_title"

By default, the tab strings correspond to the new Approvals and Requests tabs thatwere added in SSM 5.2.2. The blocks correspond to each custom section that you add tothe Request Center Catalog.

To identify the tab title in Request Center that matches the tab title number in ApplicationAdministrator, refer to the tab number that appears in the Request Center browseraddress bar after the hash tag. For example, if you add a custom tab for a report, and youare using the Approvals and Requests tabs that were added in SSM 5.2.2, the browseraddress bar shows:

http://serverName/tmtrack/tmtrack.dll?shell=srp#tab_3

In Application Administrator, you can translate the title for this new tab by overriding thevalue for SRC Catalog property "tab_3_title".

Tip: Note that if you delete the default Requests or Approvals tabs and addanother tab, the new tab will reuse either the tab_1_title or tab_2_title sectionin Application Administrator.

Knowledge Management Strings

When you select Allow Translation for MLS Runtime Objects and Design Objects onthe Values tab and you re-deploy the Knowledge Management app, each primary tableand auxiliary table in the process app appears as a category on the Localization page.Design object strings are organized by section in the following categories:

• KM Visibility Group


• Knowledge Management

• KM Categories

Customizable Knowledge Management strings that you can translate include:

• Name and Help Text for workflows, states, transitions, fields.

• Field selections

• Form strings (displayed on custom forms)

• Labels associated with tables (displayed on quick forms)

• Name, description, and tab name for applications

• Name, description, and singular name for tables

• Workflow annotation and swimlanes in the workflow diagram

Important: Translated strings appear in the diagram only if you haveenabled HTML5 features in SBM.

When you edit a custom form in SBM Composer, you can view a list of the text fieldstrings that are used by form actions to set values. When you deploy or promote theKnowledge Management process app, these strings are available for translation as well.

To view these strings in SBM Composer:

1. In SBM Composer, open the Knowledge Management process app and select acustom form.

2. Open the Property Editor.

3. In the Filter drop-down list, select Container Controls.

4. In the list of containers, select the TranslatableStrings expander.

MLS Runtime Object Strings

MLS runtime object strings that are available for translation include values in the followingfields:

• KM Categories: Name

• KM Visibility Group: Title

Note: You can only translate strings for MLS runtime objects by exporting andimporting XML with translated strings.

To export values in these fields to XML for translation:

• Ensure that Allow Translation for MLS Runtime Objects and Design Objects isselected on the Settings tab in Application Administrator.

• Ensure that Allow translation for value display in relational fields check box isselected on each field in the Options tab in SBM Composer and either promote theKnowledge Management process app after a new SSM install or re-deploy it afterupgrading to 5.2.2 or later.



Translating Strings

Use one of these methods for translating the default English (United States) strings intoanother language:

• Importing a Translated XML File

Ideal for sending strings to a translation vendor or for translating all default stringsat one time. For details, refer to Translating Strings Using XML [page 179].

• Localization Options in Application Administrator

Recommended for users who are more comfortable working in an interface than inan XML file or when you are translating a small number of strings. For details, referto Translating Strings in Application Administrator [page 182]:

When translation is complete, users who select the locale for the translated version willsee the translated strings.

Important: String changes are global and impact your entire installation ornamespace (on-demand customers.)

Translating Strings Using XML

Use the Export tab in Application Administrator to first create an XML file that containsthe default English strings. You can then import this file after strings are translated. Notethat you must select the Allow translation for MLS Runtime Objects and DesignObjects check box on the Settings page before you promote or deploy the process appsin order to create the default locale strings.

Translating SLS Design Object Strings Using XML

Review the following section to learn about exporting SLS and user defined object stringsto XML for translation.

Each SLS / Design string is composed of the following elements in the XML:

• Key

Container for each string, including values and tags for all locales.

• Name

The key name for each string.

• Locale

The locale for each key value.

• Key Value

If no override is applied, the text that is shown to users for the specified locale.

• Override

A way to customize a string and maintain the provided value. Overrides, if provided,are always shown to users.

• Tag


Customizable label for each key value.

Important: Do not modify the structure of the XML file. Instead, providetranslations in the KeyValue tags.

To translate SLS and user defined object strings using XML:

1. In the Localization | Settings tab, select Allow translation for MLS RuntimeObjects and Design Objects if it is not selected already.

2. Select the Export tab.

3. Select the SLS / Design type.

4. Select the locale you want to export.

5. Select the category of strings to export (Request Center) or Request Center(User Defined Objects).

6. Click Export and save the file.

7. Open the file of exported strings in an XML or text editor.

8. Use search and replace to change the <Locale> value for each key.

Note the following:

• When you replace the <Locale> values, you must use the proper abbreviation forthe locale. For example, to designate French, you must specify:<Locale>fr</Locale>.

• If you added the desired locale to the Predefined Locales page before installingor upgrading SSM, you can export the strings to XML in the desired locale withouthaving to use search and replace.

9. Translate the <Value> for each key as needed. If an override is used, edit the<Override> value to update the translation that appears in Request Center.

Important: For on-demand customers, you must use the <Override>element to override or translate an existing key. You cannot import newkeys, and if you attempt an import and you specify a new value for a key,it will be ignored.

10. In Application Administrator, select the Import tab, and then import the file.

Translating MLS Runtime Object Strings Using XML

Review the following section to learn about exporting Request Center MLS runtime objectstrings to XML for translation.

Each string in the XML is a separate runtime object that is identified by uuid, with stringsfor each locale that you selected at the time of the export.

There are two types of MLS Runtime strings that you can translate in Request Center:

• KM Categories: Name

• KM Visibility Group: Title



The values in both of these fields are available for export to XML if the Allow translationfor value display in relational fields check box is selected on each field in the Optionstab in SBM Composer and the process app is either promoted after a new SSM install orwhen the Knowledge Management process app is re-deployed after an upgrade.

Important: If you are upgrading to SSM 5.2.2 or later, you must manuallyselect this option in SBM Composer and re-deploy the process app.

The following XML shows the KM Categories: Name field after it has been exportedusing the French locale:

<Table dbname="TSM_CATEGORIES" name="KM Categories"uuid="e8af206b-c333-48b2-ba40-f17b2ec68550"><Field dbname="TITLE" name="Name"uuid="0c6d9e0e-16e3-49f9-a44d-67f72e4852ee"><Obj Iden="0" uuid="b48b705f-ee74-468a-a356-b072445ab8bb"><Str Loc="fr_FR">Hardware</Str></Obj><Obj Iden="0" uuid="d7a64711-c26d-41a9-8fe7-3485fc8e073a"><Str Loc="fr_FR">Access and Directory</Str></Obj><Obj Iden="0" uuid="d6de174f-0863-4b12-bbe8-1214fa96da73"><Str Loc="fr_FR">Telephone and Network</Str></Obj><Obj Iden="0" uuid="0306583a-67ac-44da-8758-10d619f3a12b"><Str Loc="fr_FR">Facilities</Str></Obj><Obj Iden="0" uuid="617c8640-ea43-4e02-9084-6dd9326d4d55"><Str Loc="fr_FR">Enterprise Applications</Str></Obj><Obj Iden="0" uuid="29ea3235-a3f0-4720-996b-afdbddc6b8ca"><Str Loc="fr_FR">Data and Backup</Str></Obj><Obj Iden="0" uuid="d88a0a1c-4d99-4927-b630-972615674437"><Str Loc="fr_FR">Email Management</Str></Obj><Obj Iden="0" uuid="ec403323-35e4-46dc-a3bc-00e55e760c3d"><Str Loc="fr_FR">Software</Str></Obj><Obj Iden="0" uuid="cfb48687-a423-42b7-a96a-59b031d9a3f3"><Str Loc="fr_FR">Other</Str></Obj></Field></Table>

To translate these strings into French, simply modify the English value that appears after<Str Loc="fr_FR"> for each string. The steps below walk you through the process ofexporting, translating, and then importing the XML back into Application Administrator.

To translate Request Center MLS runtime object strings using XML:

1. In the Localization | Settings tab, select Allow translation for MLS RuntimeObjects and Design Objects if it is not selected already.

2. Select the Export tab.

3. Select the MLS / Runtime type.


4. Select the locale you want to export.

Important: You cannot change the "Root" value by importing modifiedXML—translated values for the root locale are ignored when you import theXML. You can only change root values directly in the object itself. In otherwords, to change the root values for the KM Categories, you must editeach category name in the KM Categories auxiliary table via ManageAuxiliary Data in Application Administrator. This applies to the rootvalues for the KM Visibility Groups as well.

5. Select the values to export (KM Categories: Name) or KM Visibility Group: Title.

6. Click Export and save the file.

7. Open the file of exported strings in an XML or text editor.

8. Change the Str value for each string you want to translate.

9. Save your changes to the XML file.


Translating Strings in Application Administrator

Use the Values page in Application Administrator to provide new translated values forlanguages other than the default English (United States) or other languages that havetranslations.

To modify strings:


2. Expand either the Request Center or Request Center (User Defined Objects)category.

3. Select a section that contains strings you want to translate. For example, totranslate Request Center category names, select the SRC Category Name sectionin the Request Center (User Defined Objects) category.

4. Navigate to or search for the string you want to modify.

5. On-premise – Click in the Value column, and then provide the value that should beshown to users for each predefined locale.

On-demand – Click in the Override column, and then provide the value that shouldbe shown to users for each predefined locale.

6. Optionally, click in the Tag row and provide a label or comment for the string value.



Promoting Translated Strings

To promote translated strings for user defined objects from one environment to another(for example, from test to production), you must export the service definitions and



translated strings from the source environment, and then import them into the targetenvironment.

Exporting and importing service definitions is currently an experimental feature that isexplained in detail in solution S141047. You export and import the XML file of translatedstrings from one environment to another using Application Administrator. The order of theimport does not matter; you can import service definitions before importing translatedstrings or vice versa.

When you export and import the XML file of translated strings from one environment toanother:

• Default SLS locale strings (en_US) are not changed in the target environment.

• Default strings and translations for non-default locales are overwritten in the targetenvironment.

Troubleshooting Localization

The default SLS locale that is used for the Request Center snapshots is (en_US). Anystring changes that users attempt to make to user defined objects in Request Center aremade to this default locale. This means:

• If a user attempts to edit strings in Request Center and his or her locale is not thedefault SLS locale (en_US), but translated strings have been added to the system, awarning icon appears with hover-text stating that any changes will be made to thedefault locale; not the locale that the user has selected in his or her user profile. Ifthe user has selected the French locale and wants to modify the French strings, he orshe must use Application Administrator to edit the French strings that have beenimported or added.

• Even if the system locale in SBM System Administrator is not set to English (UnitedStates), string changes in Request Center are made to the default locale that is usedfor the Request Center snapshots (which is en_US), and not the locale that isselected in SBM System Administrator. If the system locale in SBM SystemAdministrator is set to French, and users want to translate strings into French, theymust do so using Application Administrator.

• On-premise – If any localization overrides are used in Application Administrator,those values appear throughout Request Center; however, any string changes thatusers make in Request Center affect the default locale (en_US) values, and not theoverridden values. If users want to update the overridden value, they must do sousing Application Administrator.

On-demand – String changes that users make in Request Center always affect theoverridden values, and not the default values (which are always empty).Administrators can only modify strings in the Override column in ApplicationAdministrator.

In addition, if you have translated strings for a language and your users select a relatedlanguage (locale), the system falls back to the translated strings for that language if thelanguage (locale) is not used. This means users who select French (Belgium) will seetranslated strings for French if French (Belgium) is not used as a locale for translatedstrings in Application Administrator.


http://knowledgebase.serena.com/InfoCenter/index?page=content&id=S141047

Troubleshooting Request CenterIf the SBM User Workspace opens instead of Request Center when you access the URL,verify that:

• Request Center has been installed by running the Service Manager installer.

• After installing Service Manager, the SLA settings have been applied in SBMConfigurator and IIS Web Server has been restarted. This must be done even if SLAsare not used.

If you are getting the message that you do not have permission to view a report on theRequests tab, verify that the IT administrator has configured a report to be displayed asdescribed in Configuring the Requests View [page 166]. Also, verify that you havepermissions to access and run the report that the IT administrator has configured.



Chapter 14: Additional Information

This chapter has additional information about Serena Service Manager.

• Managing Users [page 185]

• Service Level Agreements [page 189]

• General Features [page 203]

Managing UsersUse the following general steps for establishing user accounts:

1. Determine the types of user accounts you need.

2. To better manage sets of users, log in to Application Administrator, and then creategroups, such as "Release Engineers" and "Service Technicians."

3. Add accounts for each active user.

4. Assign users to the applicable groups you created. This will ease the process ofassigning users to roles.

5. Assign groups to roles in each process app.

For guidance on each of these steps, refer to the Application Administrator online help orthe SBM Application Administrator Guide located on the Documentation Center.

Types of Users

Before you add user accounts, consider the types of users you need. This helps youdetermine the product-access level you should assign to each user.

For example, Serena Request Center has two distinct types of users: requesters andfulfillers. Requesters are those who request IT services, such as logging a ticket to reporta problem and asking for additional network access. Fulfillers are those who respond torequests by either directly working on them or by managing incoming requests to ensurethat an organization's activities are streamlined.

Use the following information to determine which product-access type to assign to eachset of users:

• Occasional User

Assign to users who will use Serena Request Center to submit IT service requests.These users can also view and update the requests and proposals that theysubmitted.

• Regular User

Assign to users who will fulfill requests.

• Managed Administrator



Assign this product-access level to users who will configure Serena Request Center,administer your process apps in SBM Composer and Application Administrator,manage user accounts, and other administrative duties. By default, this product-access level is automatically granted to the user who establishes your on-demandaccount.

Adding User Accounts

Each active user in your system must have an account that includes:

• Name and e-mail address

• Product-access level

• Group membership (optional, but recommended)

To add user accounts, log in to Application Administrator, and choose one of the followingmethods:

• Select the Users icon and manually add individual user accounts.

• Select the Import Users icon to import users from a spreadsheet or from an LDAPstore.

For details steps on adding or importing users, creating groups, and assigning users togroups, click Help in Application Administrator.

Assigning Users to Roles

After you establish accounts for each user in your system, assign these users to applicableroles in Application Administrator using the following guidelines.

Product-accessLevel

General Guidance Example

OccasionalUser

Assign these users to roles intended for ITcustomers and planners who submit requests andwho need to view and update their requests later.

User(SSM -IncidentManagement)

User (SRC -Service Request)

Regular User Assign these users to roles intended for IT staffwho will fulfill requests submitted by ITcustomers.

Level 2Tech(SSM -IncidentManagement)

Editor/Publisher(SRC -KnowledgeManagement)



Product-accessLevel

General Guidance Example

ManagedAdministrator

Assign these users to roles intended for users whowill administer the process app in ApplicationAdministrator, SBM Composer, and ApplicationRepository.

Administrator(SSM -ConfigurationManagementSystem)

Administrator(SSM - ProblemManagement)

Group Queues

Group queues keep items from being missed or delayed if individuals are absent whenitems are submitted or move into an investigation state because the entire group hasvisibility and ownership of items. In addition, items with a primary owner can bereassigned to the group queue.

The following applications allow items to move into a group queue, where team membersare secondary owners and can assign items to themselves or to someone else on theteam:

• Service Request


• Change Management

• Problem Management

An item can be assigned to both a group and an individual, or to one or the other. Thisallows users to assign an item directly to the appropriate individual without having tomove it into a queue state.

• If an individual is selected, he or she becomes the Owner of the item, and if a groupis also selected, it becomes the Secondary Owner.

• If a group (or individuals in a Multi-Group field) are selected, the group or individualsbecome the Secondary Owner; there is no Owner.

For example:

• An incident is assigned directly to Jim, a Level 1 Technician. Level 1 Group isselected in the group field, which is optional. The item moves to the Investigation& Diagnosis state, where Jim is the owner, and Level 1 Group is the secondaryowner. Jim starts working on the item, but is called to a customer site to handle anemergency. Sally is also a member of the Level 1 Group. She reassigns the itemback to the group queue and then assigns it to herself to complete.

Note: If no group is selected in the group field, only Jim has directknowledge of the item while he is the owner, so the benefits of groupqueues will not be realized.


• An incident is assigned directly to the Level 1 Group and moves to theInvestigation Queue state. Level 1 Group is the secondary owner; there is noowner. Carlos opens his Worklist Dashboard report, sees the item in the groupqueue, assigns it to himself, and resolves the incident. As in the first example, if hewere unable to start or complete his work, another member of the group couldreassign the issue back to the group queue for someone else to work on.

The provided applications listed at the beginning of this topic include special dashboardreports that show the number of items in queue states and the items for which thecurrent user is a primary or secondary owner. The queue states in these applications haveOperational Level Agreements (OLAs) that stipulate how long items can remain in queue.E-mail notifications defined for the OLAs warn users when items are at risk or in violationof the agreements.

The following steps should be followed if you want to customize the implementation ofgroup queues.

In SBM Application Administrator:

1. Assign users to groups.

2. Assign these groups to the roles that were associated with Multi-User and Multi-Group fields in SBM Composer. For example, Carlos is in the IM Technician group,which is assigned to the Level 1 Techs role. This role is associated with the Level 1Group Multi-User field, so Carlos can be selected when an item is assigned to atechnician and is a secondary owner when the item is in a queue state.

3. Define Operational Level Agreements (OLAs) or Service Level Agreements (SLAs) forthe queue states.

4. Subscribe the groups to notifications. For example, if the group is subscribed to the"I become the owner of any Incident" notification, all group members will be notifiedwhen an item moves into a state in which the group is the secondary owner.

Note: For details, see the SBM Application Administrator Guide.

In SBM Composer:

1. Associate roles with Multi-User and Multi-Group fields in primary tables. Forexample, you could associate the Level 1 Techs, Level 2 Techs, and Level 3 Techsroles with the Incident Operators field.

2. Set the selection mode for the Multi-User fields to Groups & users.

3. Use decisions in application workflows to route items to "work" states when anindividual owner is specified or to "queue" states when a group is specified.

4. Assign the group fields as secondary owners of the "work" and "queue" states inapplication workflows. (The Secondary Owner system field must be added to theprimary table before you can do this.)

Note: For details, see the SBM Composer Guide.



Service Level AgreementsService Level Agreements (SLAs) define the level of service that an organization commitsto its customers. Projects can be associated with a specific SLA, allowing you to track SLAcompliance for items submitted in that project.

Users have different reasons to monitor SLAs. For example, service technicians may needSLAs to help prioritize their work. Managers may need historical information to measurehow well their organization conformed to SLAs.

The following examples illustrate how SLAs can be tracked:

• High-priority items should be assigned to a technician within one business hour.

• High-priority items submitted by "Platinum" customers should be assigned to atechnician within 30 minutes.

• High-priority items should be resolved within three business days.

• Ninety-nine percent of hardware requests should be completed within three businessdays of approval.

• No item should be in the New state for more than three business days.

SLAs can be monitored in the following ways:

• Customize and view SLA reports that include past performance and current riskinformation in various formats.

• Include the SLA widget control on state forms to view the status of SLAs for aspecific item.

• Create and subscribe users to notifications that generate when SLA criteria is notmet.

Important: SLA reports and the SLA widget only show data if projects haveSLAs defined for them, and if one or more services have been associated withthose projects in Serena Request Center.

About SLA Reports

SLA reports allow you to review and monitor how you and your organization respond torequests for service in comparison to customer commitments. SLA rules and metrics aredefined by an administrator.

Use the following sections to learn more about SLA reports:

• SLA Report Types [page 189]

• Running SLA Reports [page 191]

SLA Report Types

Past Performance Reports

Past Performance reports provide historical information. By default, data for all servicerequests from the last six months is displayed, with a performance threshold of 80%. Thismeans that over the last six months, an overall SLA "passing" performance level of 80%or greater (with an overall "violation" performance percentage of less than 20%) is


considered acceptable for normal operation. You can change this filter, as described inRunning SLA Reports [page 191].

The following Past Performance reports are available:

• Aggregate Performance—Measures the aggregate performance level of all servicerequests included in the report. This is the percentage of items that are within theacceptable range of the performance threshold, which is specified in the Report Filter(see above). The red part of the gauge represents the percentage that is under theperformance threshold; the green part represents the percentage that meets orexceeds the performance threshold. The goal is for the needle to point in the greenarea.

• Performance Breakdown—Shows each service request name, the SLAs associatedwith each service request, the SLA threshold specified by an administrator during thedefinition of the SLA, and the actual SLA performance. The SLA performance value isdisplayed in red if it falls into the unacceptable range.

• Violations by Service Request—Shows the service request names and the numberof items for each service request that are in violation of the SLAs defined for it. Youcan click a bar in the chart to drill down to the next chart.

• Violations by SLA for Service Request: "service name"—Shows the number ofitems that are in violation of each SLA defined for the service request. By default,the report format is a chart; click a bar in the chart to drill down to the next report.Click the Listing report button to change the report format.

• Violations for SLA: "SLA name"—Lists each item that is in violation of the SLA.For details about the content of the report, see "Listing Reports," below. Click thelink in the Item Id column to open the item. To close the item and return to thereport, click the X at the top right corner of the item.

Current Risk Reports

Current Risk reports are calculated using the time and risk values defined for each SLA.By default, data for all service requests is displayed in the reports. You can select specificservice requests to monitor and specify that only data for items you own is displayed. Youcan change this filter, as described in Running SLA Reports [page 191].

The following Current Risk reports are available:

• Risk Projection—Shows the number of items from all service requests included inthe report that are in violation of or are at risk of violating the SLAs associated withthem. Violations and risk categories are stacked horizontally in the bar in differentcolors; click one to view the corresponding chart on the right.

• Violation/Risk Category Items by Service Request—Shows the service requestnames and the number of items for each service request that are in violation of or atrisk of being in violation of the SLAs defined for it. The name of the chart changesdepending on what is clicked in the Risk Projection report. You can click a bar in thechart to drill down to the next chart.

• Violation/Risk Category Items by SLA for Service Request: "service requestname"—Shows the number of items that are in violation of or at risk of being inviolation of each SLA defined for the service request. By default, the report format isa chart; click a bar in the chart to drill down to the next chart. Click the Listingreport button to change the report's format.



• Violation/Risk Category Items for SLA: "SLA name"—Lists each item that is inviolation of or at risk of being in violation of the SLA. For details about the content ofthe report, see "Listing Reports," below. Click the link in the Item Id column to openthe item. To close the item and return to the report, click the X at the top rightcorner of the item.

Listing Reports

Some of the SLA reports are in a list format. Most, but not all columns are displayed bydefault. To display hidden columns, and to optimize the reports for your screen, right-clickin any column header and select or clear check boxes for columns you want to see orhide. In these reports, you can also click a column header to sort rows in ascending ordescending order.

The information displayed in a column can be modified with the "value display format"option. This option is configured on the General tab of the table Property Editor in SBMComposer. For example, you could have the Title column include both the title and ownerof the item. For details, see the SBM Composer Guide or online help.

Descriptions for some of the columns follow:

• Estimated Date: The date the item will violate the SLA if the item does notcomplete the SLA process within the "duration" that was defined for the SLA. Thisdate should move forward to account for the time the item spends in "paused"states.

Note: Waiting for Input is an example of a paused state in which atechnician waits for a customer to provide information needed to proceedwith the item.

• Completion Date: The date the item reached the "end state" that was defined forthe SLA.

• Elapsed Time: The amount of time since the item entered the "start state" that wasdefined for the SLA, with the exception of the amount of time it spent in "paused"states.

• SLA Type: SLA (Service Level Agreement) or OLA (Operational Level Agreement).SLAs and OLAs are defined and processed the same way. They differ in that SLAstypically address customer commitments, while OLAs typically address internalcommitments that ensure that SLAs are met.

• SLA Clause: The name of the clause that applies to the item. Clauses define thecriteria under which items are monitored; for example, a "High Priority Incidents"clause defines SLA timing and conditions for high priority items, while a "NormalPriority Incidents" clause would define less stringent criteria.

Note:

• If you do not have privileges to view an item, it will not be included in theListing report. It will, however, be included in the chart reports.

• If an item being tracked by an SLA cannot be processed, "Exception" isdisplayed in the Status column for the item in the Listing report.

Running SLA Reports

SLA reports are available in Serena Work Center and in the SBM User Workspace.


To run an SLA report:

• In Serena Work Center, select the Service Manager application group from thetoolbar, and then expand Reports in the navigation pane. (You may need to pin theService Manager application group.)

• In the SBM User Workspace, select the Application tab that contains SLAinformation. Click the Reports link, and then click Access SLA Reports underAdvanced Tasks.

Select one of these tabs: Past Performance or Current Risk.

The report page also contains a report filter that lets you change the criteria for thereports. You can either apply the criteria to the current report or save the criteria to beused in the next report.

To open the report filter, click the Define Filter link on the report page.

• To specify which service requests to include in the report:

1. Click Select Service Requests.

2. In the dialog box that opens, select a service request. Move it to the right toselect it or to the left to remove it. To move it, click the plus or minus icon ordouble-click it. You can also drag a service request to the right to select it. Toadd or remove all service requests, click Add all or Remove all.

3. Click Select to close the dialog box.

• Past Performance reports only: To change the date range, click in the date box. Fromthe menu that opens, select a specific date range or click Date Range and thenselect a start date and end date from the calendars. Alternatively, you can type overthe date in the Date Range box, or click the Prev or Next arrows to bring the daterange backward or forward by six months.

• Past Performance reports only: To change the threshold, type over the number in thePerformance Threshold box. For example, 75 means that 75% or more of itemsmeeting the SLAs is acceptable, and less than 75% is unacceptable. To raise theexpectation, change the number to something higher.

• Current Risk reports only: Select the Items I Own check box if you only want to seedata that is relevant to items for which you are the primary or secondary owner.

• Click Apply to apply the settings to the current SLA report and close the dialog box.Click Save Settings to save the settings to the database so they are applied to thenext SLA report you run.

About the SLA Widget

SLAs are used to review and monitor how your organization responds to requests forservice in comparison to customer commitments. SLA rules and metrics are defined by anadministrator.



The SLA widget, which can be included on state forms, contains the status of the currentitem for each SLA that applies to it. Initially, the most severe status is displayed. Thecomplete status list can be seen by clicking the arrow on the widget.

Important: The SLA widget only shows status information if projects have SLAsdefined for them, and if one or more services have been associated with thoseprojects in Serena Request Center.

The list can contain the following values:

• VIOLATED, HIGH, MEDIUM, or LOW means the item is in violation of this SLA orat risk of violating it. The risk level is estimated in terms of time remaining to complywith the SLA. For example, an item is in violation if 0% of the allotted time remains,at high risk if 25% of the time remains, at medium risk if 50% of the time remains,and at low risk if 100% of the time remains. An item always starts the SLA processat low risk.

If (Pending) is appended to the value, the item is in a paused state, in which timeis not counted against the SLA.

• COMPLETED means that the item has reached the "end state" defined in the SLA. If(VIOLATED) is appended to this value, the item was in violation when it reachedthis state.

• No SLA Status means that no SLA currently applies to the item.

When the status is hovered over, additional information is displayed. This informationincludes:

• Name

• Description (if provided)

• Type: SLA or OLA (Operational Level Agreement)

Note: SLAs and OLAs are defined and processed in the same way. OLAstypically monitor internal commitments that ensure that SLAs are met.

• Date: The date that the item violated the SLA or is expected to move to the nextrisk level. In the case of the COMPLETED (VIOLATED) status, the completion dateis displayed, not the date the item violated the SLA.

Important: An SLA includes one or more "clauses," or rules. In addition toduration and severity percentages, the clause defines the portion of theworkflow to which it applies.

For example, a clause could apply to the range of states from the "New" to"Assigned" states. Another clause in the same SLA could apply to the range ofstates from the "Assigned" to "Completed" states. This means that if an SLAwith multiple clauses applies to an item, the widget could show multiple statusvalues, some of which may not be current.

Using the previous example, the list would include VIOLATED if the item wasnot assigned to a technician within the allotted time. However, after it wasassigned, if only 50% of the time for the technician to complete the item haselapsed, the list would also include MEDIUM.


Defining SLAs

Service Level Agreements (SLAs) define the level of service that an organization commitsto its customers. You can use the SLA feature in SBM Application Administrator to definemetrics for tracking these commitments. The topics in the SLA Settings [page 196]section describe how to do this.

Best Practices

SLAs need to be designed to ensure that performance measurements are meaningful andaccurate. If SLAs are defined too broadly, practical usage can cause measurements to bedistorted or items could remain in certain states without being noticed. To prevent this,define more granular SLAs (or SLA clauses) that monitor specific phases of an item'slifetime.

The following illustration shows a workflow that tracks the progress of an item.

Note: See SLA Clause General Options [page 199] for complete descriptions ofthe terminology used in the following use cases.

Use Case 1: Different Paused States

The following table describes two paths that an item could take in the workflow. Different"paused" states are defined for each path.



Scenario StartState

EndState

Paused State(s)

Entire process (SLA 1) Assigned Resolved Waiting, Researching,Deferred

Technician needs information beforeproceeding (SLA 2)

Waiting Resolved In Progress, Testing

When an item is in a "paused" state, time is not counted against the time remainingbefore the item is in violation of or at risk of violating the SLA. If only SLA 1 monitoredthe item, the item could remain in the Waiting, Researching, or Deferred statesindefinitely. Reports would not indicate a problem, and warning notifications would not besent. Customer service would be poor, even though it would appear that commitmentsare being met.

To ensure that an item is not neglected, an SLA should also be defined for the path thatstarts with the Waiting state. For example, suppose a new item must be completedwithin three days, according to the high-level SLA (SLA 1). The technician needs criticalinformation before work can start, and moves the item to the Waiting state.

At this point, the item is under SLA 2, which stipulates that an analyst must provide theinformation within four hours. Because the Waiting state is not a "paused" state in SLA 2,the item will have visibility in reports and notifications if the item stays in this state (orthe Researching or Deferred states) too long.

Use Case 2: Re-Opening a Closed Item

When you define multiple start and end states in a clause, the time an item spends in allpaths is combined to calculate elapsed time. For example, suppose you have New andAssigned start states, and a Resolved end state.

1. An employee submits a request for a software application. The technician assignedto the item installs and tests the software, and moves the item to the Resolvedstate. The item spends two days in this path.

2. The employee cannot use key functionality in the software because of configurationproblems.

3. The IT manager executes the Re-Open transition on the Resolved state form, andthe item moves to the New state. The manager immediately reassigns the item tothe technician, moving it to the Assigned state. The technician moves the item tothe In Progress state, and has been working on it for one day.

In this use case, the elapsed time for the item is three days, because the time since theitem was re-opened is added to the previous time.


SLA Settings

Restriction: To define or modify SLAs, you must have the following:

• "Managed Administrator" or "Regular User" product access type

• "Remote Administration" system privilege

• Privileges to edit projects for which SLAs are defined

• Enabler licenses for Serena Service Manager (SSM) or Serena RequestCenter (SRC). To enable SLAs, either the SSM or SRC enabler license mustbe procured and installed.

Service Level Agreements (SLAs) are used to measure how well an organization respondsto requests for service compared to its published metrics. You define SLAs at the projectlevel of an application.

The SLAs page lists the SLAs that have been defined for the project. It includes thename, description, status, and effective date of each SLA.

To access this page, in SBM Application Administrator, click the SLAs tab on the projectpage.

Note:

• If you change settings for an active SLA, both the old and new version ofthe SLA are stored. New items will use the new settings, but existing itemswill continue to use the original settings.

• If an item is updated in a way that makes the condition defining the SLAfalse, the SLA will no longer be in effect. For example, suppose a high-priority item is being monitored by an SLA that defines that high-priorityitems should be resolved within three business days. If someone changesthe priority to "medium," the SLA will no longer monitor that item.

Important: In the SBM User Workspace, SLA reports and the SLA widget onlyshow data if projects have SLAs defined for them, and if one or more servicerequests have been associated with those projects in Serena Request Center.

Toolbar Options

• Add

Click to add a new SLA.

• Details

Click to view or modify a selected SLA.

• Delete

Click to delete a selected SLA.

• Copy



Click to copy a selected SLA to the current project or to a sub-project in itshierarchy. If you are copying to the same project, you must provide a unique name.

Note: Actions and notifications defined for the SLA are not copied.

• Refresh

Click to refresh the page to its last saved state.

• Search for SLA

Type a text string to find matching SLAs. After a moment, all SLAs that contain the

string are displayed. To clear your text to search for something else, click .

Tip: Click the icon next to the SLA name to see a summary of the SLA.

SLA General Options

The following options are available when you add or edit an SLA:

Toolbar Options

• Save

Click to save changes made on the page.

Note: If you make changes and do not click Save, you are prompted tosave your changes when you navigate away from the page.

• Discard

Click to discard changes made on the page.

Basic SLA Options

The following options enable you to define basic SLA settings.

• Type

Select SLA (Service Level Agreement) or OLA (Operational Level Agreement).

SLAs and OLAs are defined and processed the same way, but typically an SLAaddresses customer commitments, while an OLA addresses internal commitmentsthat ensure that an SLA is met. For example, an SLA could stipulate that a PC isdelivered to a customer within five business days; one OLA could stipulate that thepurchasing department processes the purchase order within four hours, and anotherOLA could stipulate that the IT department sets up the PC within one business day.

• Name

Enter a name. Names must be unique within a project.

• Description

Enter an optional description.

• Starts On


(Optional) Click the calendar icon and select a start date and time for when the SLAshould take effect. For the time, click the hour, minute, or second, and scroll up ordown. Click Accept to keep the values, or click Clear to start over or specify no startdate.

• Ends On

(Optional) Click the calendar icon and select an end date and time for when the SLAshould stop being in effect. For the time, click the hour, minute, or second, and scrollup or down. Click Accept to keep the values, or click Clear to start over or specifyno end date.

• Threshold

Type a number that represents the percentage of items that must meet the SLAbefore it is considered in violation. If you want the threshold to be measured againsta period of time, select per month, per quarter, or per year. This value is used inthe "Performance Breakdown" SLA report in the SBM User Workspace.

• Status

After you click Save, this field shows Active (if the current date and time are withinthe specified range), Inactive (if the start date and time have not been reached), orExpired (if the end date and time have elapsed).

Note: If you do not specify Starts On and Ends On values, the SLA isconsidered active.

SLA Clause Options

A clause defines when items should be monitored, and can define what should happenwhen items violate or are at risk of violating the criteria defined for it. An SLA can containmultiple clauses. The following are examples of clauses:

• Items in the New state must reach the Assigned state within two hours if the valueof the Priority field is "High." If the item is still in the New state and is 30 minutesaway from being at high risk, an e-mail notification will be sent to the manager.

• Items in the Assigned state must reach the Resolved state within three businessdays if the value of the Request Type field is "Hardware," and time should not becounted against the SLA when the item is in the Waiting for Customer state.

• Items in the Work Started state must reach the Tested state within one businessday if the value of the Impact field is "All work stopped."

When you click the Clauses tab, a list of existing clauses is displayed. The list includesthe name, description, and duration of each clause.

The following toolbar options are available:

• Add

Click to add a new clause.

• Details

Select a clause and then click this button to view or edit the clause.

• Delete



Select a clause and then click this button to delete the clause.

• Refresh


By default, the Group by path check box is selected, and defined clauses are organizedon this page according to the path specified in the SLA Clause General Options [page199]. Clear this check box if you want to view defined clauses alphabetically by name.

SLA Clause General Options

The following options are available when you add or edit a clause:

Toolbar Options

• Save



• Discard


• Show Workflow

Click to show the visual workflow assigned to the project.

Basic Clause Options

• Name

Type a name. Names must be unique within an SLA.

• Description

Type an optional description.

Time & Risk Options

• Duration

Type a number and then select Minute(s), Hour(s), Day(s), or Week(s). Thisoption specifies how long the clause will stay in effect, beginning with the start dateand time for the SLA. The default value is 2 Day(s).

• Calendar

By default, 24 Hour Calendar and User Submitter are provided. You can alsoselect user-defined calendars or calendars that are included in SBM.

• Risk

This option enables you to define risk levels in terms of time remaining before itemsare in violation of this SLA. When 100% of the time remains, the risk is consideredLow. When 0% of the time remains, items are in Violation. You can define thepercentage of time remaining that puts items in Medium or High risk of violation.The default value for medium risk is 50%; the default value for high risk is 25%.


Path Options

Path options enable you to define the range of states in the workflow that needs to bemonitored. For example, if the SLA states that 99% of hardware requests must becompleted within three business days of approval, the path would start with theApproved state and end with the Completed state. If a technician needs informationfrom a customer before proceeding, then the Waiting for Input state should be definedas a "paused" state, because the time an item is in this state should not be countedagainst the time remaining.

If you define multiple start and end states in a clause, the time an item spends in allpaths is combined to calculate elapsed time. For example, suppose you have New andAssigned start states, and a Closed end state.

1. An item moves from the New to Closed state. The item spent two days in this path.

2. The item needs to be re-opened.

3. A manager executes the Re-Open transition on the Closed state form, and the itemmoves to the Assigned state. A technician moves the item to the In Progressstate, and has been working on it for one day.

In the preceding scenario, the elapsed time for the item is three days, because the timesince the item was re-opened is added to the previous time.

Tip: Click Show Workflow in the toolbar to view the entire process flow.

• Start State(s)

Select the start state or states from the list, or type ahead to search for states

containing the characters you type. Click to clear the search and start over.

• End State(s)

Select the end state or states from the list, or type ahead to search for states


• Paused State(s)

Select the paused state or states from the list, or type ahead to search for states


Qualifying Conditions

You must define at least one condition that evaluates to "true" before the clause takeseffect. For example, the SLA might only be relevant if the value of the Customer Rankfield is "Gold."

To add or edit a condition:

1. To add a condition, click Add condition and then click Click here to edit.

2. To edit a condition, click the condition.

3. Select the field you want to evaluate.

4. Select a comparison operator.



5. Select or type a value to compare to the field, or type ahead to search for a value.

6. Click OK.

If you define multiple conditions, they are joined by logical operators. AND means thatboth conditions must evaluate to "true" before the clause is put into effect; OR meansthat only one condition must evaluate to "true." Click the logical operator to togglebetween them.

You can view a string that represents the conditions in the Summary section.

SLA Clause Action Options

Actions define what should happen when items are in violation or at risk of being inviolation of the conditions defined in a clause. The Actions tab appears after you saveyour clauses on the SLA Clause General Options [page 199] page. When you click theActions tab, a list of existing actions is displayed. The list includes the name anddescription of each action.

The following toolbar options are available:

• Add

Click to add a new action.

• Details

Select an action and then click this button to view or edit the action.

• Delete

Select an action and then click this button to delete the action.

• Refresh


SLA Action Options

The following options are available when you add or edit an action:

Toolbar Options

• Save



• Discard


Basic Action Options

• Name

Type a name. Names must be unique within a clause.

• Description


Type an optional description.

Conditions

You must define at least one WHEN or IF condition.

• WHEN

You can specify that a notification be sent before an SLA reaches a state of violationor risk so that preemptive actions can be taken. The WHEN condition specifies thistime period. For example, you may want a manager to be notified when a requesthas not been fulfilled, and only four hours remain before the SLA is violated.

To add or edit a WHEN condition:

1. To add a condition, click Add condition in the WHEN section, and then clickClick here to edit.


3. Type a number and select minutes, hours, days, or weeks.

4. Select High, Medium, or Violation.

5. Click OK.

• IF

IF conditions define conditions other than timing that must be true before the actionis taken. IF conditions are based on field values. For example, the action only needsto be taken WHEN you are six hours from high risk IF the value of the Priority field is"High."

To add or edit a condition:

1. To add a condition, click Add condition in the IF section, and then click Clickhere to edit.


3. Select the field you want to evaluate.

4. Select a comparison operator.

5. Select or type a value to compare to the field, or type ahead to search for avalue.

6. Click OK.

• Summary

A string that represents the conditions is displayed in this section.

• THEN



The THEN condition defines the action to take when the WHEN and IF conditions aremet. When you click the + icon next to Run notification, the Add Notificationpage opens. When you click the icon next to an existing notification, the EditNotification page opens. Refer to the notifications documentation for instructions ondefining and editing notifications.

Note:

▪ The Notification Actions that are available for SLAs are NO ACTION,SEND E-MAIL, RUN SCRIPT (on-premise only), and RUN WEBSERVICE.

▪ The provided "SOO_OLA_default.htm" e-mail template includes textthat informs users that the item is being monitored by an SLA or OLAand has reached a level of risk or violation.

▪ You can use any notification e-mail tag for the item being monitored byan SLA; however, dynamic SLA-specific information cannot be included.If you want to include SLA information in an e-mail notification, createan e-mail template with static SLA information and then associate thattemplate with the applicable action. For example, you could add "Thisitem is at high risk of SLA violation" and then select that template whenyou create a notification for a high-risk SLA clause.

▪ SLA notifications are distinct from standard notifications and are notlisted in the Notifications view accessed directly from theAdministrator Portal. Standard notifications cannot be used for SLAs.

▪ If a user or group is allowed to subscribe to SLA notifications, thesenotifications do appear in the Notifications page when you edit theuser or group, and also appear on the Notifications tab in the UserProfile for the user in the SBM User Workspace.

▪ You cannot discard SLA notifications.

▪ Not all notification options are available for SLAs.

General FeaturesThe following topics describe the general features and settings available in Serena ServiceManager.

These features apply to the process apps contained in Request Center and ServiceManager. For information on specific process apps in a solution, refer to the sectiondescribing the solution.

• State Forms [page 204]

• Transition Forms [page 205]

• Custom Form Actions [page 207]

• Modern Forms vs. Legacy Forms [page 208]

• Working Groups and Suggested Experts Panel [page 208]

• Modifying Urgency, Impact, and Priority [page 209]


• Custom Help [page 211]

State Forms

State forms are displayed when an item is in a state. They are designed with the followingfeatures to give visual indicators of the status of the item and other importantinformation.



1. The state icon gives users a visual cue of where the item is in the workflow. The iconis added during form load using a form action. The colored backgrounds are basedon the process app that you are in.

2. The item's title appears along the top of the item.

3. Tabs contain specific information about the item. For example, the User Incidentstab, which is present on Incident Management state forms, and the User Requeststab, which is present on Service Request state forms, contains a report of all otheritems submitted for the same Affected User. This report includes the Request ID,Title, State, Project, Submit Date, and Reported By fields.

Tip: Other reports can be added to the User Incidents or UserRequests tab with the Embedded Report widget. For example, it could beuseful to have a report showing only closed items for this affected user, oritems related to the affected user's group. For information about thiswidget, see the SBM Composer Guide.

4. Primary transition buttons are enlarged to display to users the usual path throughthe workflow. Secondary transitions and item actions, such as Send E-mail, arecollapsed to reduce the clutter on the page. Expand the More Actions menu toaccess these functions.

5. Working group Social widget displays users who have interacted with the item.

6. Service Level Agreement status appears on the left side. It displays the current SLAstatus for the highest SLA pertaining to the item. Click the SLA widget to displaydetails about the SLA and to display other SLAs that are related to the item.

Note: The state and transition forms are designed for screen resolutions of1024x768 or higher. You may experience problems if you use a lowerresolution, such as 800x600. If the forms are difficult to read at the minimumresolution of 1024x768, you can increase the browser's zoom setting. Forexample, changing the browser's zoom setting to 125 percent will increase thesize of text, buttons, and other controls throughout the interface. However, beaware that increasing the zoom setting from 100 percent may require you toscroll through pages as you work.

Transition Forms

Transition forms are displayed when you click a transition button on a state form orsubmit a new item. Transition forms share a similar layout, which assists you whenpopulating the form with the necessary information.




1. Sections with required fields are highlighted in yellow, calling attention to fields thatmust be populated. This is done by adding background coloring to the cells for theform in SBM Composer.

2. Relational fields enable a keyword search with a list of results.

3. Cancel and OK controls are placed on the bottom of the form.

Note: For form designers: the forms are designed so fields that are setautomatically are put into the System section. Other fields are in the Usersection so users can view the ones that require information. In addition, formactions, such setting the transition icon on page load, are used to modify theform design.

Tip:

Use SBM Composer to modify the process apps, and change any user fields thatcontain several selections to be searchable instead of using drop-down lists. Thisimproves performance when transition forms are displayed in the browser.

Custom Form Actions

Service Manager process apps include special custom form actions. They appear in theActions tab of the form Property Editor in SBM Composer when you create statements forevents, conditions, and actions.

Note: The Solution Util Loader.js file included with Service Manager processapps loads JavaScript files used by these forms actions. The Solution UtilLoader.js content should not be modified.

The custom form actions include:

• Events

▪ execute immediately: Executes the action immediately when the form beginsto load, instead of waiting for it to load completely.

• Conditions

▪ an SOO process application is deployed: Checks whether the selected processapp has been deployed.

▪ this form is zoomed/not zoomed: Checks whether the form is in a zoomedview, such as when it is viewed from a multi-view report.

▪ this form is in a shell: Checks whether the form is loaded from a shell, such asRequest Center.

▪ current user is in a Multi-User field: Checks whether the current user isincluded in the selected Multi-User field.

▪ format and compare two date fields: Formats two "Date only" Date/Timefields and then compares their values. You can check whether one is later thanthe other, or whether one is the same as or later than the other. If one of thefields is empty, the condition will evaluate to true.

• Actions


▪ do SOO form formatting: Detects the type of form that is displayed (state ortransition) and applies the standard formatting for that type of form. This includeshiding the standard transition button bar on state forms.

▪ initialize SOO utils: Pre-loads the SOO utility JavaScript and CSS files. Bydefault, they are loaded on first use.

▪ add more actions widget to an action control: Links the More Actions menuto the selected action control. Also adds the transitions hidden by the do SOOform formatting action to the More Actions menu.

▪ format a tab with new tab style: Applies either the grey bar or the wizard tabstyle to the selected tab control.

▪ toggle sidebar control: Displays a control that the user can use to togglewhether the sidebar is shown or hidden.

▪ collapse sidebar control: Collapses the sidebar so it is hidden, with no controlfor the user to show it.

▪ expand sidebar control: Expands the sidebar so it is shown, with no control forthe user to hide it.

▪ add/remove current user to/from a Multi-User field: Adds the current userto or removes the current user from the selected Multi-User field.

Modern Forms vs. Legacy Forms

Modern forms, introduced with SBM 11.1, use technologies such as HTML5 and .cssproperties to achieve greater stability in layout and less reliance on scripting overall.

Legacy forms refer to forms created before SBM 11.1. All of the existing SSM forms arelegacy forms and will continue to work as expected.

Note: In SBM Composer, be sure to keep legacy mode enabled for SSM formsand for any new forms that you create based on SSM forms. Disabling legacymode will lead to unexpected results.

Working Groups and Suggested Experts Panel

Custom forms can include the Social widget, which displays a working group and anexpert panel.

Working Group

The working group shows the number of interactions other users have had with the itemand then displays the number of interactions for each of those users. It also displays thecurrent fields in which the user is selected. The users are sorted based on the number ofinteractions in a list.

Note: The current user is not displayed in the list of users in the working group.

You can select a user to open the details pane. The details pane contains contactinformation for the user, the number of interactions broken down by type, and the currentfields in which the user is selected, such as Owner or Submitter.



The interactions are divided as follows on the details pane. They are denoted by a uniqueicon:

• indicates the number of transitions. Transitions include submit, updates, andother transitions.

• indicates the number of notes added to the item using the item actions or onitem update.

• indicates the number of attachments added to the item. Attachments includefiles, URLs, and item links.

Expert Panel

You can display a list of suggested experts by clicking the Suggest 3 Experts link on theSocial widget. The suggested experts are a list of users who are ranked based on thenumber and kind of similar items that they worked on. The top three users are displayed.

Click a suggested expert to display contact information. If this user has a configured emailaddress, you can send the user an email by clicking the email link.

The experts are found and ranked based on the following criteria:

• The title words in the item are used to search for similar items within the sameproject and subprojects. Similar items are found and ranked based on a weightedkeyword search of the title and description of the items.

• Only items that have been in the same state over the past six months are evaluated.

• Deleted users are not included in the suggested expert list.

• The current user is not included in the suggested expert list.

Modifying Urgency, Impact, and Priority

An item's Priority determines the sequence in which it will be addressed. High priorityitems should be addressed quickly and escalated up the organizational hierarchy, ifnecessary. Lower priority items can be addressed in a less urgent manner, and theyshould not be re-prioritized to expedite their resolution.

The default Service Manager includes five levels of priority, with 1 being the highestpriority and 5 being the lowest priority.


ITIL defines priority as being based on the impact to the business and the urgency forwhich the resolution is required by the user or business. In other words, impact is ameasure of how business critical the incident is and urgency is the speed required toresolve the incident. Service Manager automatically determines priority after you haveselected the impact and urgency for an item.

Tip: Since there are additional elements that could be included in determiningthe priority, like scope, complexity, who is requesting the change, and resourcesrequired for resolution, submitters can override the automatically determinedpriority by selecting a new one in the Priority list.

Note: Overall impact can be difficult to determine, and it is common to simplifyimpact by relating it directly to how many users are affected by the item.Serena Service Manager uses this approach and allows for three impact choices:Enterprise, Department, and Single User.

The following table explains how the priority is determined based on impact and urgency:

Table 1. Urgency, Impact, and Priority

Impact

Enterprise Department Single User

High 1 2 3

Medium 2 3 4Urgency

Low 3 4 5

Implementation Method

The automatic calculation is performed by rules defined in SBM Composer and called byform actions.

You can make modifications to how the priority is calculated by changing these rules. Notethat this change must be performed for each process app, such as Incident Management,Problem Management, and Change Management.

To update the rules:

1. Open the process app in SBM Composer.

2. Add the selection values to the Impact, Urgency, and Priority fields in the primarytable. For example, for Incident Management, you would add the values to theIncidents table under Data Design.

3. Add a rule to calculate the new priority. Use an existing rule, such as Priority 1Calculation.

4. Open the submit form and include the new rule in the Click: Set Priority Based onUrgency and Impact Values form action. You can include the rule by addinganother Else If condition and setting the priority appropriately for when the conditionis true. Refer to the existing conditions for examples.

5. Copy the updated form action to the other transition forms.



6. Repeat for all of the process apps.

Custom Help

Solution developers can document applications as they develop and maintain them in SBMComposer. The information they provide for key application elements is presented tousers as they work with items. Custom help is provided for the Serena Service Managerapplications. This information can help you understand the design and function of theapplications. You can modify this information to customize it for your organization.

In SBM Composer, the custom help text is entered in the End-user help text setting.This setting is on the General tab of the Property Editor for all elements exceptapplications. For applications, this setting is in the application editor. The Find End-UserHelp Text dialog box can be used to find elements that include custom help text. This ishelpful both for reviewing and modifying the provided help text, and for identifyingelements that do not have help text. To open this dialog box, click End-User Help in theFind area on the Home tab of the Ribbon.

Note: For details, see the SBM Composer Guide.

The following table lists the elements for which custom help can be provided, anddescribes how users can view it.

Element How to View

Application Hover over an application tab to see a brief description of it.

Workflow Click the workflow icon on any primary item to open a help window thatcontains information describing the process items follow, including agraphical view. Information about each transition, state, and decision isalso shown.

Transition Hover over any transition button on a state form to view provided helpcontent.

Form Click the help icon on any primary or auxiliary item to open help aboutthe fields on the form. On transition forms, information about thetransition is included. On state forms, information about the state isprovided, including help about each available transition and field. Customform information is also shown if it was provided.

Field Hover over the name of any field that includes a dotted underline to viewa shortened version of the provided help for that field. Click the help iconon the form to see a full version of the provided field help.


Documents

SERENA® SERVICE MANAGER · Serena Service Manager comes packaged with fully functional, easy-to-use applications for incident, problem, change, and configuration management. Workflow