Remedy 7 User Data Model Guide

Remedy 7 User Data Model Guide

IT Quality/Remedy Support Cummins, Inc
Version 1.1 November 25, 2009

11/25/2009

Page 1 of 32

Remedy 7 User Data Model Guide

R EVISION H ISTORY
VERSION
0.1 0.2 0.3 1.0 1.1

REVISION DATE
10/09/09 10/14/09 11/2/09 11/05/09 11/25/09

REVISED
Chris Romano Chris Romano

BY

DESCRIPTION

OF CH ANGE

Chris Romano/David Tie man Chris Romano Chris Romano

Initial review draft with customers and suppliers Changes made based on initial review with Project Manager and Project Support Team Added links to reference Revised Checklists Initial Release Resolved errors in the checklists

11/25/2009

Page 2 of 32

Remedy 7 User Data Model Guide

Table of Contents
Overview ........................................................................................................................................ 4 Design Sequence............................................................................................................ 5 Data Model Design Process Flow ................................................................................ 6 Help and Support.......................................................................................................... 8 1. Support Group Structure................................................................................................. 9 Support Group Checklist ........................................................................................... 10 2. People Profile................................................................................................................... 12 Checklist ...................................................................................................................... 14 3. Product Categorization Guidelines ............................................................................... 15 Checklist ...................................................................................................................... 17 4. Operational Categorization Guidelines ........................................................................ 18 5. Resolution Categorizations Guidelines ......................................................................... 20 Checklist ...................................................................................................................... 21 6. Assignment Mappings .................................................................................................... 22 Checklist ...................................................................................................................... 25 7. Change Timing & Approval Mappings ........................................................................ 27 Checklist ...................................................................................................................... 29 8. Information Tracking for Configuration Management .............................................. 30 Checklist ...................................................................................................................... 32

11/25/2009

Page 3 of 32

Remedy 7 User Data Model Guide

Overview
Purpose
The purpose of this guide is to help customers, (Remedy Support Users), understand the Remedy 7 IT Request and Fulfillment systems data model and act as a guide in the decision making process so they can choose a configuration that maximizes the capabilities of the tool and business processes, maintains a consistent data model design and meets customer business requirements.

Supported Processes
Remedy 7 has been configured to support the following IT Processes: Incident Management: An Incident is any event which is not part of the standard operation of a service and which causes, or may cause an interruption to, or reduction in quality of that service. The purpose of Incident Management is to provide guidelines that ensure all reported Incidents are handled in a timely and consistent manner. The goal of Incident Management is to minimize the adverse impact of IT-related Incidents on business operations by restoring productivity and fulfilling standard user service requests as quickly, efficiently and effectively as possible Change Management: A Change is a planned and authorized modification request that impacts a controlled configuration item within the IT infrastructure Change Management ensures that before any Change is introduced to the live environment; it undergoes a thorough assessment to detect potential impact and risk that would affect the stability of the infrastructure. Problem Management: A Problem is an unknown root-cause of major or recurring incidents. The purpose of Problem Management is to minimize the adverse impact of Incidents and Problems on the business that caused errors within the IT infrastructure, and to prevent recurrence of Incidents related to these errors. Configuration Management: Defines configuration items, (CI), and maintains accurate records to support other related IT business processes by tracking and managing the relationships amongst configuration items, services and the processes they support. A configuration item is a record stored within the Configuration Management Database, (CMDB), used to represent a physical or information asset and relationships to systems, components, documentation, processes, owners, services, etc...

11/25/2009

Page 4 of 32

Remedy 7 User Data Model Guide

Design Sequence
The sequence of sections in this guide is structured to mirror the preferred implementation method when designing and populating the required foundational data for Remedy 7. Identifying the appropriate section to start and required dependant sections depends on the type of foundation data being proposed for inclusion into the model.

Support Group Structure

Sequential

People

Product Categorization

Operational Categorization

Resolution Categorization

Approval Mappings

Auto-Assignment Mappings

Information Asset Tracking (CI)

In Parallel

11/25/2009

Page 5 of 32

Remedy 7 User Data Model Guide

Data Model Design Process Flow

The process of designing a data model is a reiterative. You move up and down and back and forth as you consider how best to capture the information needed.

Audience
Business Needs -Detail Needs, wants, dont wants Business Consumers & Providers

Possible Approaches for design -guidelines, watchouts

Remedy Ops and Steering Committee

Evaluate - Tech requirements - Business Needs - Remedy Strategy - Other Business Needs

All Stakeholders

Phase 1: Identify Business Needs:

1. Focus on data that is important to your business. If the data or configuration doesnt provide reasonable value, dont do it. 2. Model your data based on the needs of your Consumers, not your Providers. It is the Providers job to adapt to that structure. If nobody will consume a particular type of data, there is no need to track it in your business system. Data Provider Individuals or groups who provide segments of information about an asset or service Data Consumer individuals or groups that use the data.

3. Consider future needs as well as present ones. If it is easier to start tracking something later if it is already in your data model than to adjust the model at that time then include the requirements up front. If you are uncertain of the present value add, and it is easy to add the data later, consider waiting. Balance present and future needs against the need to manage scope. 4. Consider the following types of questions when identifying the business requirements. What is the scope of the business requirements that need to be fulfilled, i.e., want, dont want? What business process does the information item(s) support? What process does the business currently rely on to fulfill the requirement? Who are the data providers? Who are the data Consumers?

11/25/2009

Page 6 of 32

Remedy 7 User Data Model Guide

Can you leverage existing data to suit the business need? Are there any constraints that the design team needs to be aware of, e.g., resource, technology, timing, budgetary, regulations, controls, etc?

Phase 2: Identify Potential Design Solutions

The Remedy Operational Support Group, key process and application stakeholders will attempt to identify a potential solution that meets the business requirements provided by the data Providers and Consumers. The design team will develop potential solutions based on the industry and internally developed Best Practices as well as the following considerations: Key questions to consider when deciding how to track information assets in the CMDB: Keep the application as out of the box as possible; customizations should be kept to a minimum. Is there an existing configuration or data that meets the business requirements? Is there update available for download from BMC that meets the business requirements? What are the minimum data elements that need to be stored? Is the data available from another source? If customization is needed the following questions must be considered: What Remedy processes/workflows or data output are impacted, and how? Customization choices may impact workflows used by other data and applications within the Remedy ITSM suite. Is the customization stable, scalable and flexible? Is it maintainable from an auditing aspect and complexity standpoint? Would it hinder future upgrades? At what level do the benefits of the customization satisfy the business requirements and outweigh the effort, cost, and complexity?

Phase 3: Evaluate Design Solution

Once a potential solution has been designed, a review will be conducted amongst the Remedy Operations Support Group, relevant Steering Committees, and the customer to evaluate the solution. If the proposed solution impacts other workflows or BMC applications within the ITSM suite, then the appropriate process or data owners will also be included in the evaluation phase. Validate the solution satisfies the criteria listed in Phases 1 and 2 above, as well as the following: Business Needs Does the model represent the needs of the Consumer? Consistent Remedy Strategy o o o Did we balance the needs of the business with the goal of keeping customizations to a minimum? Did we progress through the options as recommended by the best practices? If we customize the Out-of the-box functionality or data model, did we explore multiple options and mitigate the technical and process risks appropriately? System(s) Performance

11/25/2009

Page 7 of 32

Remedy 7 User Data Model Guide

Standards and Exceptions

The standards and guidelines defined within this document have been created to make the most efficient use of the tool, reduce unnecessary complexity, and to provide a suitable end-user experience for both customers and IT Support. Please adhere to the guidelines as defined or contact the Remedy Business Process Owner to discuss any exception requests?

Related Materials
Document Name Remedy Training Materials Data Model Templates Remedy 7 User Guides CMDB Data Model Templates Incident Management Process Change Management Process Problem Management Process Remedy 7 User Guides Link CMDB Data Model Reference Material Links Remedy 7 Training Link Links

Help and Support

The sections below will outline the best practices, requirements and recommendations that need to be considered when looking to fulfill business process requirements by adding and configuring foundation data to the Remedy 7 Data Model. The process of completing this information is a cooperative process to ensure a consistent Remedy strategy. If you require assistance please submit a ticket to the Remedy Support Team.

11/25/2009

Page 8 of 32

Remedy 7 User Data Model Guide

1. Support Group Structure

Background
The Support Group Structure is a three-tiered hierarchy used throughout the Remedy 7 application suite. 1. Support Company 2. Support Organization 3. Support Group The same group can be used throughout the Remedy suite if appropriate permissions are granted to members. Incident Management - Incident Assignee, Incident Owner (currently not used) Problem Management - Problem Manager, Problem Assignee and Requested By Change Management - Change Manager, Change Assignee, Change Implementer and Requested By Task Management - Task Assignee(s) Configuration Management (CMDB) - Support Group Relationships to Configuration Items (CIs)

Tier Structures Guidelines and Examples

Before you make a final decision on the support group structure you wish to build please review the Operational Categorization, Product Categorization and Assignment Mappings sections of this document to avoid rework at later phases. 1. Support Groups must represent unique work groups. Do not use the Support Group Structure as a primary means of trend reporting. Remedy 7 provides a robust set of categorization structures and attributes that enables reporting of granular details of the activity performed. 2. Limit the amount of groups you create. Complex group structures lead to complex configurations that will often not realize the desired results. 3. Avoid redundant names in each level of the hierarchical tree. Since this is a tree structure it is not necessary to use the same pre-fix at each level. Instead you can find the Support Group. You can not search by prefix in Remedy 7 4. Support Groups can not be seen by customers who submit tickets from the Requester Console. Ambiguous acronyms should still be avoided when naming the Support Group Structure because even within IT function it could have no or multiple meanings. Remedy supports between 60 and 254 characters depending on the level of tier structure. The more clearly the names are displayed, the more likely other support group members will find the correct group. Support Structure Guidelines Tier Name 1 Support Company 2 Support Organization 3 Support Group Structure Examples: Tier Ex: 1 ADSC 1 Americas ERP 2 Support 3 Description BU + Function or Shared Service Organization Service Service Track Character Limit 254 60 60

Ex: 2 ADSC Americas ERP Development

Ex: 3 EBU IT Supply Chain Logistics

Ex: 4 EBU IT Supply Chain Order Management

Ex: 5 EBU IT Supply Chain Finance

11/25/2009

Page 9 of 32

Remedy 7 User Data Model Guide

System Requirements
Assignees: - All Support Staff must belong to at least one Support Group, but can belong to more than one. Individuals configured as available for assignment for all, some, or none of the group for which they are a member. (If you are not assignable you will still have the write access according to the permission granted to your account. You just can not be listed as an assignee on a request assigned to groups that you are not assignable). Support Group Roles - Remedy 7 uses Functional Roles to expand permissions for an associated group. Role assignments are not required for every Support Group Member. Role requirements are dependant on the types of requests the members of the support group need access to within Remedy. Please refer to the People Section of this user guide for additional information on Functional Roles.

Additional Considerations
CI Association Support Groups can be related to Configuration Items and different relationship types can be defined for each relationship, i.e. Owned By, Supported By, Managed By, etc (This is only available if CIs that represent your supported systems or components exist in the Configuration Management Database) Approval Assignment Support Groups, with at least one member with the Change Approver functional role, can be mapped as an approving group. If a support group is mapped than any member of that group with the Change Approver functional role can approve changes on behalf of the group. Notification Assignment - Assignment, On-Call, Business & Holiday Calendar, and Ad Hoc notifications can be configured to notify all members of a Support Group. Individuals and Support Group Admins have the ability to select their own notification preferences, including when (Ticket type, assigned to group or individual), and how (Pager or Email). On Call notifications enable the ability to provide an individual or generic pager number. This feature allows you to differentiate between the people you want paged based on the time the ticket was assigned. Searching Support Groups can be included as a search variable to identify records with common attributes. Service Level Management & Escalation Mappings Support Group Structure is one of the primary variables used for SLA Mappings and Escalation Milestones. If different Support Groups require different SLAs then inclusion of the Support Group Structure as a variable would be required. Vendor Assignments - Vendor Support groups can be set up as a Vendor Company and configured for external assignment of tickets through a translation interface. Vendor with access to Remedy should not be configured as a Vendor Support Group.

Support Group Checklist

If submitting a request to create, modify or remove support groups please review the checklist below to ensure you have addressed the following questions: Does the requested support group structure comply with the guidelines and policies? If Problem Management will be used, has at least one person been assigned the Problem Manager Functional Role as required to assign root cause analysis investigations for the purposes of reducing the number of future incidents? If Support People will create solutions has at least one person been assigned the Problem Manager Functional Role as required to approve suggested solution database articles? If Change Management will be used has at least one assignable IT Owner been assigned as the Infrastructure Change Manager Functional Role to gather requirements from the business authorize Normal and Emergency Change requests, manage the overall change management process, assign changes to Change Assignees, receive escalations and review survey results? If Change Management will be used, has at least one assignable Support Owner been assigned as the Infrastructure Change Assignee Functional Role to supervise the change and manage resources?

11/25/2009

Page 10 of 32

Remedy 7 User Data Model Guide

If Incident Management will be used has at least person been assigned the Support Group Admin Functional Role as required to authorize changes to the group, its relationships and mappings, control group membership and assign functional roles to the group members? Will anyone be assigned the Infrastructure Change Approver Functional Role to enable group approvals? Who will approve Changes assigned to this group, Group Approvals or Individuals? Will anyone be assigned the Incident Manager Functional Role to provide access to the Incident Management Console, receive escalation notifications, and review survey results? Is it replacing an existing support group? If yes, does the new support group inherit the relationships, assignment and approval mappings, and members of the old support group? Are existing Operational and Product Categorization sufficient for this group? What new or modified auto - assignment mapping configurations will be required? Will tickets be automatically generated and assigned to this group by an interface, i.e. email template, web services, API, etc? Does this group need to be related to a CI to identify support responsibility? Does this group require an Alias? Does the group need On Call Scheduling Configured to enable time based escalation notifications

11/25/2009

Page 11 of 32

Remedy 7 User Data Model Guide

2. People Profile
Background
Note: The People referenced within this document refer to either IT Support Staff (Support People), non-support (Customer People) Support People are assignable in Remedy and have write access that allows them to work requests submitted by Customer People. Support people must belong to at least one Support Group. Customer People - Customer People submit requests and normally do not have a special configuration in Remedy, with the possible exception of being associated as business approvers of Change Requests.

Application Permissions
Permissions are used to align the support process role of an individual with the tool by granting appropriate user access and privileges to different applications and modules within Remedy. Unlike Functional Roles, permission provides the same access regardless of support group membership. Asset Viewer: This permission is recommended for all support people. It provides support with the ability to view the relationships amongst Configuration Items, (Asset Records), in the CMDB to help with impact and risk assessments. This permission also provides support with the ability to relate requests to the impacted CI(s) to help with trending and compliance audits. Incident Master: This permission is recommended for all support people who fulfill Incident requests submitted by customers. It provides the ability to create, modify, assign, reassign, resolve and reopen Incidents. Task Manager: This permission is recommended for all support people. IT provides support with the ability to create, modify, assign, reassign, and resolve tasks created from Incident, Change, or Problem requests. Change User: This permission is recommended for only those support people who will fulfill Normal and Emergency Change Requests. It provides the ability to create, modify, assign, reassign, resolve and reopen Change Requests. Change Submitter: This permission is recommended for support people who only need the ability to view and submit change requests. Problem User: This permission is recommended for only those people who are involved in the Problem Management process. It provides the ability to create, modify, assign, rand resolve Problem and Known Error Investigations. Problem Submitter: This permission is recommended for support people who only need the ability to view and submit Problem and Known Error Investigations. Problem Viewer: This permission is recommended for support people who only need the ability to view and update work log entries for Problem and Known Error Investigations.

Support Group Functional Role Assignments

Functional Roles differ from permissions because they elevate a persons privileges only for the Support Group(s) for which they were assigned the role. If a support person needs to fulfill the same role for multiple groups then they must be assigned the role for each group separately.

Incident Management Roles

Support Group Admin: Support Groups that will work Incidents, pre-approved changes and user service requests that do not require Change Board approval will require each Support Group to have at least one member with a Functional Role of Support Group Admin.

11/25/2009

Page 12 of 32

Remedy 7 User Data Model Guide

The Support Group Admin can modify Incident and Change Templates, add or remove members from their support groups, and are responsible for approving requests to modify group configurations and associated data. Incident Manager: - In Remedy 7 the Incident Manager receives ticket escalation notifications and has access to the Incident Manager Console.

Change Management Roles

Change Manager: Person responsible for the integrity of the Change Management Process. This role is required if a group will use the Change Management application to receive or fulfill change requests. This role is normally fulfilled by the IT Owner Group, (Infrastructure or Application Owner), and their primary responsibilities are to authorize and assign change requests to Change Assignees. Change Assignee: Person responsible for planning and supervising the execution of the change and assigning implementation resources. This role is normally fulfilled by Technology Support Owner Group. A Change Assignee is not required by tool, but is often required by the process. Change Approver: Person or group responsible for approving a change requests assigned to their group. This role is only needed if a person is responsible for approving all changes assigned to a group. A group can have more than one person assigned the Functional Role of Change Approver. In this case the system will accept approval by one as approval on behalf of the group. The benefit to group approvals is that it ensures backup coverage by defining multiple people with authorization to approve changes on behalf of a support group, but only one approval is needed to satisfy the group approval requirement. All people within Remedy can be listed as an Approver on a change request by predefining the approval mappings or by manually adding additional approvers to the approval phase, but only support people can be assigned the Functional Role of Change Approver and approve on behalf of a group. An individual whose only role is to approve changes does not need to be configured as Support Person or assigned to a group because approvals in Remedy 7 do not require write access and are accessed through a separate console called, Approval Central.

Problem Management Roles

Problem Manager: Person responsible for assigning Problem Investigations and Known Error resolutions to Problem Assignees for root cause analysis and solution development. It also provides the ability to screen and publish suggested solution database entries submitted by group members This role is required if group will use Problem Management application

Attributes
People Profiles list the names and contact information of individuals as well as other key attributes. Most attribute information like cost center, name WWID and Contact information is populated from other master source data repositories, like the LDAP extension tables and Cummins Enterprise Directory (CED). Attributes can be used as searching and reporting variables. WWID is Primary identification attribute for all People Profiles. WWID is available in all Remedy applications views where customer or support name is present. Support Staff: Identifies people who perform a support function during the request fulfillment process. Assignment Availability: Indicates whether a support person is assignable for each group for they are a member.

11/25/2009

Page 13 of 32

Remedy 7 User Data Model Guide

Notification Preferences
Support People can define their default notification method in their People Profile. The system will notify Support People when a ticket is assigned to a support group to which they are a member. People can choose email and set up their paging information to activate pager notification. Pager service provider changes require assistance from the Remedy support team before setup is complete. New pager service providers may require approval and additional setup steps. Support Group Admins can define the conditions for which they want support groups to be notified and Support People can manage their individual notification settings. 1. Support Group Admins own the Support Group, membership within the group, and its relationships; including scripts, templates and relationships to CIs. 2. Support Group Admins are responsible for maintaining the accuracy of the Remedy data for which they are the identified owner and completing audits of such data when they are performed.

Checklist
If submitting a request to remove or modifying people, please review the checklist below to ensure you have addressed the following questions: If the user is being removed or replaced from a group or the system, have we verified that any open tickets, relationships, approval mappings or functional roles should be transitioned to another support person? Does the user need Asset Viewer permission to relate requests to configuration items? Does the user need Task Manager permission to be able to create tasks? Will the user need Incident Master permission to work incidents? Will this user need Problem User permission so they can be assigned problem investigations? Will this person need Change User permission to modify Normal and Emergency change requests? What group memberships will the user have? If the person is a member of more than one group, what is their default group? For which groups should the user be assignable? Will the user be given a functional role, and for what groups? Will the user be mapped as an individual approver? Does the user need to be redirected somewhere else to modify people attributes for which Remedy is not the master source? Will the person need to be mapped as an owner to any CIs? Does the user need to be redirected somewhere else to modify people attributes for which Remedy is not the master source?

11/25/2009

Page 14 of 32

Remedy 7 User Data Model Guide

3. Product Categorization Guidelines

Background
Product Categorization is based on a five - tier hierarchy that helps identify the products or services impacted by a request, i.e. the software or hardware for which service is being requested. It is a base element that is used throughout the Remedy 7 AR System: Incident Management Problem Management Change Management Task Management Configuration Management (CMDB) Requester Console

Product Categorizations are associated with Configuration Items (CI) Classes defined in the Configuration Management Database (CMDB). Each can be made available or excluded by within the AR System. Remedy refers to this as a 5 tier categorization since Manufacturer is required if Product Name is populated. So Product Name and Manufacturer are considered a single tier. 1. 2. 3. 4. 5. Tier 1 Tier 2 Tier 3 Product Name Model Version Manufacturer (Required if Product Name is filled out. Will also create a Manufacturer company entry in the Company form).

Tier Structures Guidelines and Examples

1. Use commonly recognized product names. Dont assume everyone knows the meaning of an acronym. Remedy 7 supports a maximum of 60 characters for each categorization tier. The more clearly the names are displayed the more likely support and customers will find their products. 2. Do not include non-product information in the Product Categorization Tier Structure. The purpose of these categories is to classify products. There are other categorization structures that can be used to meet trending and auto-assignment needs 3. Do not mix systems and components in the same categorization structure. The system requires that Tier 4 (Product Name) must be unique for each Tier 1, 2, and 3 classification structure. In order to ensure the Product Name can always be unique for each categorization, we are requiring that you only categorize one CI in each tier structure. Tier Tier 1 Tier 2 Tier 3 Product Name Model/Version Manufacturer Hardware Categorization Guidelines Hardware System, Component, or Peripheral Hardware Type (Tier 4) - Product Name (Tier 5) - Model/Version (Part of Tier 4) - Required if Product Name is Populated Character Limit 60 60 60 254 254 254

11/25/2009

Page 15 of 32

Remedy 7 User Data Model Guide

Tier Tier 1 Tier 2 Tier 3 Product Name Model/Version Manufacturer Software Categorization Guidelines Software COS Function ( There are 10 COS Functions), or Software Enterprise (software shared across COS Functions), or Software Common PC (Class 1 and 2 Software) Name of Software Module or Instance (Tier 4) - Product Name (Tier 5) - Model/Version (Part of Tier 4) - Required if Product Name is Populated Character Limit 60 60 60 254 254 254

Hardware Examples: Tier Example 1 Hardware 1 System 2 Laptop 3 Latitude Product Name D620 Model/Version Dell Manufacturer

Example 2 Hardware Component Memory

Example 3 Hardware System Server Sun Fire V445 SUN

Example 4 Hardware System Printer Multi-Function

Example 5 Hardware Peripheral Local Printer

Software Examples: Tier Example 1 Software - Finance 1 Concur 2 US 3 Product Name Model/Version Manufacturer

Example 2 Software - Enterprise BMS Logistics

Example 3 Software Common PC Notes Mail Notes 6.5 Lotus

Example 4 Software - IT Remedy CMDB Atrium 2.1 BMC

Additional Considerations
CI Categorization This categorization is used to specify the range of products or services for which the configuration item record applies. Product Categorization is used to both classify CIs in the CMDB and classify requests within Change, Incident and Problem Management. If your CI exists in the CMDB, you can relate requests to the CI and copy the Product Categorization automatically using the Get CI Product Categorization feature within Remedy. This can help ensure the correct categorization is populated and strengthen your trending and reporting capabilities. Request Classification Product Categorization is used, along with Operational Categorization, Asset, Incident, Change, Problem Management Applications to help classify request. Product Categorization is also available on the Requester Console to help users classify their service requests by the affected software or hardware product. Auto-Assignment Product Categorization, along with Operational Categorization, Location, and Customer Organization, can be included as an auto-assignment mapping variable. Note: A persons organization can be used as an auto - assignment variable, so BU should only be included in the Product Categorization Tier Structure if it represents an application instance or module.

11/25/2009

Page 16 of 32

Remedy 7 User Data Model Guide

Approval Mapping Product Categorization is one of the main criteria used to determine approval mappings, along with Company, Organization, Department, Location, Requestor and Implementor Support Group Structure, and Operational Categorization.

Checklist
Changes to Tier 1 of Product Categorization values are restricted and require approval from the Remedy Business Process Owner and Application Development & the Support leadership team. Changing the values stored in tier 1, 2, and 3 are permitted so long as they adhere to the standard guidelines. If the change impacts existing configuration items then the CI owners must also be added as an approving stakeholder. When making changes to these tiers please ensure the following considerations are addressed. Modify Have any associated auto-assignment mappings been updated to reflect the change? Is the current product categorization associated with any approval mappings? Has the categorization been made available in the Incident, Change, and Problem Management applications as required? Do any email templates or other interfaces need to be modified to account for this change? Is the current product categorization associated with a Configuration Item? Create (Please also answer the modify questions if the new categorization replaces an existing categorization) Have any associated auto-assignment mappings been added as required? Does the new categorization need to be associated with approval mappings? Has the categorization been made available in the Incident, Change, and Problem Management applications as required? Will the new product categorization be associated with any Configuration Items? Remove Does the Support Group it was associated with have any other assignment mappings? If no, should the support group also be removed? Was this product categorization being used by any email templates or other interfaces that automatically generate tickets within Remedy?

11/25/2009

Page 17 of 32

Remedy 7 User Data Model Guide

4. Operational Categorization Guidelines

Background
Operational Categorization is a three-tier hierarchical representation of operational activities. This categorization is included to specify the range of operations to which a request applies and can define the activities to be performed against the Product Categorization, i.e. The activity to be performed. It is a base element that is used throughout the Remedy 7 AR System: Incident Management Problem Management Change Management Requester Console Task Management

Each categorization structure can be made available or excluded in each application within the AR System.

Tier Structures Guidelines and Examples

Changes to the Operational Categorization values are restricted and require approval from the Remedy Business Process Owner. The tier values are meant to describe common activities requested or fulfilled within the IT function at a high level. These categorization values can not be modified to meet the details of a specific request without a strong business case. 1. Operational Categorizations are used to describe the activity being requested. Together with Product Categorization they help further define the request to allow support to accurately assign, classify, prioritize and process the request correctly. E.g. How Operational and Product Categorization work together: Operational Categorization What action should IT take? Product Categorization What specific Product should IT to take the action on? 2. Operational Categorizations are used by both Support and Customer people. The goal is to use Operational Categorization to define common types of customer requests at a high level and avoid constructing a list that is complex, confusing and difficult to navigate. Specific activities and issue types can be addressed using Resolution Categorization to satisfy any remaining trending needs not fulfilled through a combination of Operational and Product Categorization. 3. Operational Categorizations are tightly controlled and should not change much. There are only so many ways to describe IT related activities at a high level. Keeping this list manageable is an important factor in enabling customers and support ability to report and trend activities accurately and consistently. Operational Categorization Tier Guidelines Tier Description (Verb) - Generic classification of action required 1 Determines the target application of the request, (Noun) - Logical grouping of activity, product or 2 service types. Common Differentiator 3 Examples: Tier 1 2 3 Character Limit 60 60 60

Ex: 1 Install Software

Ex: 2 Change Hardware Manufacturing

Ex: 3 Repair Hardware App Hosting Windows

Ex: 4 Repair Software

Ex: 5 Reset Account Password

11/25/2009

Page 18 of 32

Remedy 7 User Data Model Guide

Additional Considerations
Categorization - Operational Categorization is used within the Incident, Change, and Problem Management Applications to classify the activity being requested. Request Classification Operational Categorization is used, along within Product Categorization, Incident, Change, Problem Management Applications to help classify request. Operational Categorization is also available on the Requester Console to help users define the action they want taken to complete their service request. Auto-Assignment Operational Categorization, along with Product Categorization, Location, and Customer Organization, can be used as an auto-assignment mapping variable. Approval Mapping Operational Categorization can be used to determine approval mappings, along with Company, Organization, Department, Location, Requestor and Implementor Support Group Structure, and Product Categorization.

11/25/2009

Page 19 of 32

Remedy 7 User Data Model Guide

5. Resolution Categorizations Guidelines Background

Resolution Categorization and Resolution Product Categorization are only available in the Incident Management application When resolving an Incident in Remedy the support members can use the Resolution Categorization and Resolution Product Categorization fields to help further define the action required to resolve the Incident and broaden their reporting capabilities.

Resolution Categorization
Resolution Categorizations is a three tiered menu structure used to identify the steps needed to resolve an Incident. The data in this field can fulfill additional reporting requirements to support reliability or trend analysis reporting requirements and expand on the operational and product categorizations by providing more detail around the specific activity or product attributes required to resolve the Incident.

Resolution Product Categorization

Resolution Product Categorization contains the same values that exist in the Product Categorization tier structure. It is the same list represented in two different places within an Incident. Product Categorization can be used to identify the system that was impacted the service request, and Resolution Product Categorization can be used to identify the hardware or software component that was impacted by the service request.

Tier Structures Guidelines and Examples

1. Support has significant decision rights as to how they want to use Tiers 2 and 3 of the Resolution Categorization Structure. 2. For ease of browsing and reporting you should categorize the categorization values within each from the largest tier grouping to smaller more granular tier groupings. The levels required will depend on the type of activities and the level of detail you need to support your reporting requirements. 3. For Tier 1 use a combination of Support Company plus your support Organization to differentiate your resolution categorizations from other services. This will help ensure that support people are routinely selecting the desired values needed to support your reporting needs. Resolution Categorization Tier Guidelines Tier Description Support Company + Support Organization 1 Logical grouping of activity, product or service 2 types. Specific activity or product descriptor 3 Resolution Categorization Examples: Tier Ex: 1 Ex: 2 Global Desktop AS400 1 Warranty Apply Patch 2 Stolen Program Fix 3 Character Limit 60 60 60

Ex: 3 DBU EMEA Config Error

Ex: 4 DBU EMEA Incorrect Procedure

Ex: 5 ADSC - EDI Trading Partner Setups

11/25/2009

Page 20 of 32

Remedy 7 User Data Model Guide

Additional Considerations
By itself the Resolution categorization provides limited information to fulfill reporting or trending requirements. But used in conjunction with other incident attributes it can provide a very specific description of the issue, systems, components, and resolution steps for that incident. The example below illustrates how the information in all the categorization fields can be used to provide meaningful data to a service or technology owner. From this information you can tell that the incident reported was for the repair of T6320 Server caused by poor performance of the CPU. Categorizations & Trending (Hardware Example): From this information you can tell that the incident reported was for the repair of T6320 Server caused by poor performance of the CPU. Tier 1 2 3 Product Name Model/Version Manufacturer Categorizations Resolution Application Hosting Performance NA NA NA

Operational Repair Hardware NA NA NA

Product Hardware System Server Sun Blade T 6320 Sun Micro

Resolution Product Hardware Component CPU

Categorizations & Trending (Software Example): From this information you can tell that the incident reported was for a Onesource Software Change and part of the change resulted in modifying the interface with Eracent. Categorizations Tier Resolution Operational Product Resolution Product Change Software - HR ADSC - Custom Oracle Software - IT 1 Software OneSource (Oracle HRMS) Interfaces Eracent 2 3 Product Name Model/Version Manufacturer NA NA NA NA NA NA

Checklist
Resolution Categorization Tier 2 and 3 can be used at the discretion of support the Support Group Admin. If the requester is part of an Application Services group, does Tier 1 contain a valid combination of Support Company and Support Organization? If the requester is part of Infrastructure Service, does Tier 1 contain a valid Support Organization?

11/25/2009

Page 21 of 32

Remedy 7 User Data Model Guide

6. Assignment Mappings
Background
Auto-Assignment is a feature that allows support organizations to configure and pre-define the assignment of tickets based on the on the customer organization, incident location, operational categorization, and/or product categorization. Assignment of tickets is a required means of ensuring requests are assigned or reassigned to the correct support groups. The auto-assign feature allows support groups to automate this function and thereby expedite assignment. When configured correctly auto-assignment can support an organizations operational agreements with other support groups including the help desk, or reduce the time spent by a Help Desk that provides only log and route support for a specific support group. The auto assignment feature is available in the following Remedy 7 AR System Applications: Incident Management Problem Management Change Management Requester Console Task Management

Notes: 1. Tickets generated from the on-line IT Request System (Requester Console) will be automatically assigned providing the request meets the criteria for a defined mapping. 2. Tickets created from inside the application can be auto-assigned providing the request meets the criteria for a defined mapping, and the support person chooses to use the auto assignment function. 3. Tickets generated from electronic interfaces such as email templates will be auto assigned based on the configurations details of the specific interface.

Auto Assignment Guidelines and Examples

The guidelines below address the most common types of assignment mappings and options. They can be used independently or in combination to address different assignment mapping requirements. Failure to explore or recognize the various options or consequences of each mapping can result in incorrect assignments, by creating assignment mappings that are either to inclusive, i.e., (includes tickets that should have been assigned to another group), or it can be to restrictive, i.e., (doesnt auto-assign enough tickets). 1. Auto-Assignments can be configured using Product Categorization, Operational Categorization, Requester BU, and Requester Location (Country, City, and/or Onesource Location Code) 2. During the initial configuration only Incidents and Changes were configured for auto-assignment since they are the requests most likely to be assigned via auto-assignment. 3. Problems, Solutions and Tasks are more likely to be assigned manually since the person assigning the ticket will always be in the support console and should know where those tickets need to be assigned. 4. Change Manager is a required field within Change Management. If assignment mappings are configured for Changes then it must contain a Change Manager mapping. The same is true for the Problem Manager with Problem Investigations. 5. When thinking about how to use auto-assignment you should also be looking at how your groups are structured. Assignment mappings can be many to one group, or one to one group assignments. 6. Assignment Mappings can be a benefit to support groups but the primary benefit and focus should be from a user perspective.

11/25/2009

Page 22 of 32

Remedy 7 User Data Model Guide

a. Users will select Operational and Product Categorization values when submitting tickets from the Requester Console. This action along with the persons BU and Location attribute data can be used to assign tickets. Support and the end user may often have different expectations regarding what is seen as correct inputs. The more complicated the mapping the more likely the request will be assigned incorrectly. b. While support can use auto assignment, depending on the amount of categorization variables used it may often be less efficient and accurate to correctly select up to 6 categorization values, instead of a maximum of 3 Support Group values to reassign a ticket. 7. Recommendations: a. Product Support Ownership - Look at support from the product perspective, not the components that make up a product. Each Product listed in Tier 2 should have a have a clear Level 1 Support Owner identified. That group should be responsible for the receipt and triage of requests submitted for that product. If tier 3 is being used to represent different instances or modules then support can use them to assign requests to different group. b. Support should not expect customer to know what component is causing the issue and as stated in the Product Categorization guidelines components can not be added to the same categorization structure as the system. Each Product must have its own categorization structure. c. Limit the use of multiple variables in the assignment mappings where possible. The more variables added the more numerous and complex the mappings are that need to be create, and the more likely it is tickets will be assigned incorrectly.

Examples of a Product Fully Supported by one Support Group: (Common starting point) If a product is supported by only one group, regardless of the type of request, location or BU, then the auto-assignment can be completely configured based on the Product Categorization tier structure. Even if this is not the only factor in determining the auto-assignment mapping, the majority will start with product categorizations. Example - Support Group A supports all request types for Product A or Service A: Then the mapping would say all tickets associated with Product A or Service A will be assigned to the level 1 support, Support Group A. Product Categorizations: T1 = Product Type T2 = Product A

Support Group A

11/25/2009

Page 23 of 32

Remedy 7 User Data Model Guide

Examples of Product Supported shared by multiple Support Groups: (Common differentiators) If a product is supported by multiple support groups, within one or across Support Organizations, then the auto assignment mapping needs to include other available data fields to differentiate the request and assign it to the correct group. Example 1- Operational agreements between groups: Support Group A is a system administration group that deals with account access and maintenance Support Group B is a business function group that deals with customer education requests In this case the mappings include Operational Categorizations as a differentiator. Operational Categorizations: T1 = Blank T2 = Account T3 = Blank Product Categorizations: T1 = Blank T2 = Product A T3 = Blank Or

Support Group A

Operational Categorizations: T1 = Question T2 = Blank

Product Categorizations: T1 = Blank T2 = Product A T3 = Blank

Support Group B

Example 2- Support differs based on customer segmentation: Support Group A supports Customer Segment A for Product A, and Support Group B supports Customer Segment B for Product A. In this case the assignment mapping may need to include the Business Unit or Location of the end user as a differentiator.

Organization:

Product Categorizations: T1 = Product Type T2 = Product A

Organization = BU A

+
Or

Support Group A

Location: Region = UK Site Group = Peterborough Site = uk.pet.cise

Product Categorizations: T1 = Product Type T2 = Product A

Support Group B

Additional Considerations
Requester Console: The Requester Console uses assignment mappings to populate search results. When configuring assignment mappings you will have the choice of allowing requests to be generated through the Requester Console based on the combination of Operational and Product Categorization selected.

11/25/2009

Page 24 of 32

Remedy 7 User Data Model Guide

A message can also be added based on categorizations selected. This provides the ability to display a message with helpful information and allow the request to continue, or to display a message that instructs a user to submit their request through another source and prevent the request from being submitted using the categories selected. Assignment Types: Auto Assignments can assign a request to different groups using identical variables based on the assignment type if they are created within the Support Console, since Change and Problem Requests can not be submitted through the Requester Console. You can map the roles individuals fulfill within your process or function to the appropriate Remedy 7 Functional Roles and Assignment Mappings to help reinforce and control your processes. General This Assignment type will auto assign tickets to the Implementer for each request if the mapping is enabled for that application (Incident, Change, or Problem) If a ticket is submitted via the requester console it will always come in as an Incident and use the General mapping for assignment. Infrastructure Change Manager Assigns a change request to a specific Change Manager Group Infrastructure Change Assignee Assigns a change request to a specific Change Assignee group

Assignment Type Example In this example you have an assignment mapping using the exact same variables. For simplicity sake we will only use Product. If a Change request is submitted via the Support Console and the Auto-Assign feature is used the mappings can be configured so that the change automatically assigns to only the Change Manager, the Change Manager and the Change Assignee, or the Change Manager, Change Assignee and Implementer.
Group Type Change Manager Product Categorization Assigned Support Group Company = Corp Functions IT Organization = Human Resources Group = HR Applications Tier 1= Software - HR Tier 2 = OneSource Tier 3 = Company = ADSC Organization = Oracle Applications Enhancement Group = Minor Enhancement Company = ADSC Organization = Oracle Applications Support Group = Support - HRMS Request Type Change

Change Assignee

Change Incident Change

General

Support can select the groups they want to map to for each request types. If a Change Request contains the Product Categorization above, it will assign the ticket to three different groups simultaneously. If support wanted to assign it only to the Change Manager for authorization; the General for Request Type = Change, and the Change Assignee type would need to be removed. Then it would look as follows:
Group Type Change Manager Tier 1= Software - HR Tier 2 = OneSource Tier 3 = Product Categorization Assigned Support Group Company = Corp Functions IT Organization = Human Resources Group = HR Applications Company = ADSC Organization = Oracle Applications Support Group = Support - HRMS Request Type Change Incident

General

Now the Assignment Mappings are configured to assign Change Requests submitted with the selected product Categorization to the Change Manager Group, and assign Incident Requests submitted with the same Product Categorization information to a different support group.

Checklist
When submitting requests to modify, create or remove assignment mappings consider the following: Do the required categorizations exist? Have you identified which group should provide level 1 support and map them as general for the Product Categorization?

11/25/2009

Page 25 of 32

Remedy 7 User Data Model Guide

Are different level 1 configurations required based on Product Categorization Tier 3 or Operational Categorization value? If using Change Management Does the Auto Assignment for Change Manager need to be assigned to IT Owner Group? (IT Owner is the person who is responsible for interfacing with the customer, gathering requirements, authorizing changes and assigning them to the Support Owner for planning an d implementation. The IT Owner group may be different that the group that provides support). If using Change Management Does the Auto Assignment for Change Assignee need to be assigned to a Support Owner Group? (Support Owners plan the change and manage the implementation resources). Do you need to use Organization to differentiate assignments by the Requesters BU? Do you need to use the Requesters Location information to differentiate assignments? Do you need to add Organization or Location values to applications for which Remedy is not the master source, i.e. LDAP, Onesource, etc? Do any redirect or informational messages need to be added to the categorization for the Requester Console view?

11/25/2009

Page 26 of 32

Remedy 7 User Data Model Guide

7. Change Timing & Approval Mappings Background

Approvals are available in the Remedy 7 Change Management Application. An Approval Mapping is a feature that allows support organizations to pre-define the approval of Change Requests based on the on the attributes of the request. Approvals can be automatically added to approval phases based on a predefined mapping, can be added manually prior to reaching an approval phase, and sequenced to define whether certain approvers need to approve the change prior to progressing to next approver in the sequence.

Change Timings
A Normal Change is a controlled non emergency modification to a supported configuration item that requires review and approval by a Change Advisory Board to mitigate any potential risks to the business. Approvals are required during the Business Approval and Implementation Approval phases. Request for Authorization is optional Close - Down Approval is primarily used to capture customer verification of a completed change, but it can also be used as a Post Implementation Review phase for larger or more complex changes.

An Emergency Change is a change that must be implemented immediately to resolve or prevent a break-fix that adversely impacts a configuration item within the IT infrastructure, a safety issue, or a significant financial loss to the business. Remedy has been configured to require Close-Down Approval for Emergency Change. They can be pre-defined or added manually. Approval Phases: There are four approval phases available in Remedy 7: 1. 2. 3. 4. Request for Authorization: Authorization to perform the work Business Approval: Business approval of the design and plan Implementation Approval: Testing and schedule approval Close-Down Approval: Post Implementation review

Approval Mapping Requirements and Guidelines

1. Requirement: Each Support Group Structure must contain at lease one safety-net mapping for the Business and Implementation Approval phases for Normal Changes, and the Close-Down Approval phase for Emergency Changes. This is to ensure that if a Change Request was assigned to your group at least match one mapping will be in place to ensure no changes are fulfilled unapproved. This safety-net mapping can serve as a starting point and you can add mappings with additional variables to differentiate your approval mappings. E.g. You have a Safety net mapping that configures the system so that any Normal Changes assigned to this group require approval by this individual or group during the Implementation Approval phase. Then, if needed, you can create an additional mapping that configures it so that any Normal Changes assigned to this group with a new variable, such as Product Categorization or CI; require approval by an additional individual or group during the Implementation Approval Phase.

11/25/2009

Page 27 of 32

Remedy 7 User Data Model Guide

Approval Timing\Phase Matrix

The table below defines the approval requirements for each Timing type. Timing Normal Approval Phases Implementation Required Approvers Level 1 Typically consists of the Customer and Suppliers Service, Business, and/or Technology Owner Change Coordinator or Last CCB Group Level Optional

Authorization Optional

Business Required

Approvers Change dependant, but typically consists of the Customer and Suppliers Service, Business, and/or Technology Owner Emergency Optional Optional

Close Down System maps customer for all Normal Changes Others can be added as needed.

Required Approvers Customer and Suppliers Service, Business, and/or Technology Owner

Notes:
1. 2. 3. 4. If the Approval Phase is listed as Required, Approval Mappings are Required. If the Approval Phase is listed as Optional and if no approvers are mapped the system will bypass the phase. The Requester is automatically added to the Close-Down Approval phase of every Normal change for customer verification. Emergency Changes require approval from the business at the Close-Down Approval phase. If approval is granted in an earlier phase, the Change Manager can approve the change if there are no pre-defined mappings for the Close-Down phase. Customer verification is received via the related incident. The Quality Change Coordinator or Change Board can be mapped as a Last Level Approver for all Normal Changes. This will satisfy the Quality assurance and change controls. Additional Approvers can be mapped at any available phase. Below are some examples: Implementation Phase: Owners of impacted services or configuration items that are upstream in the technology stack. Close Down Approval Phase: Stakeholders who are required to complete a Post Implementation Review of high risk or complex changes. Special Approvers: Persons who are required to approve based on the uniqueness of the Change Request.

5. 6.

Additional Considerations
Change Approvers: A write license is not required to approve changes and any person with an active WWID can approve change requests using a web based client called Approver Central. Users can be added as an individual to one of four available approval phases and two timings. Users can also be added to an approval as part of a group assignment, providing that they have been granted the infrastructure Change Approver functional role, and are a member of the support group. Note: If a group does not contain any members with an associated functional role of Infrastructure Change Approver, then that group will not be displayed in the add approvers list. Risk Level: Risk can be used as a mapping differentiator. You can choose to be an approver only for changes that are of a certain Risk Level or higher. If the Risk Level is lower than the specified risk level you will only be notified when a change has reached the approval phase, but not required to approve.

11/25/2009

Page 28 of 32

Remedy 7 User Data Model Guide

Checklist
When submitting requests to modify, create or remove assignment mappings consider the following: Will group approvals be used? If so, do the required groups exist with an associated member assigned to the Infrastructure Change Approver functional role? Has the group been set up with at least one Business Approval mapping for Normal Changes as required? Has the group been set up with at least one Implementation Approval mapping for Normal Changes as required? Has the group been set up with at least one Close-Down Approval mapping for Emergency Changes as required? Does a Change Board Chair, or Change Coordinator need to be mapped at the highest level in the Implementation Approval phase for Normal changes? Are additional attributes to be added to differentiate approvals, i.e. Product Categorization or CI for Technology Owner approval?

11/25/2009

Page 29 of 32

Remedy 7 User Data Model Guide

8. Information Tracking for Configuration Management Purpose

This section is intended to help guide the decision making process when IT asset tracking needs are identified. (For example: server leases and maintenance contracts, network routers, printers, applications, etc) The scope covered by this process usually includes Remedy 7 Configuration Management Database (CMDB) and other data sources which may play a role in meeting the overall information tracking needs.

Prerequisites:
Configuration Items need to be associated with an Operating Company. Before a Configuration item can be created they must be related to the Operating Company of Cummins. Configuration items need to be related to a Support Group. If the Support Group responsible for the proposed CI does not exist, one must be created. Configuration items need to be related to a Product Categorization. If an appropriate Product Categorization for the proposed CI does not exist, one must be created.

Background
The term Configuration Item (CI) in this document refers to an item or an asset about which information must be tracked within a Configuration Management System. Configuration Items are considered foundational data and is used throughout the Remedy 7 AR System: Incident Management Problem Management Change Management Configuration Management Requester Console

Guidelines
When thinking about creating and storing information assets to support a business requirement, several areas need to be considered. This document will help you think about those areas and provide guidance in helping you create the information asset. 1. A CMDB is for sharing data between applications. If only one application will consume a particular type of data, store the data with that application instead of in the CMDB. 2. Data stored in the CMDB must remain current to provide value. The data should be reconciled an audited routinely. The preferred option for data reconciliation and auditing is through a fully or semi-automated process. Manual reconciliation and audits of data are more error prone and affect the reliability of the data. 3. The CI owner is responsible for maintaining the data accuracy, attribute data, and assigned relationships. 4. One of the primary benefits of configuration management is the ability to create relationships between CIs, extended data and service requests. Whether relationships are preferred on non-preferred will depend on the value added to the Consumers and Providers of the data, and the complexity and costs associated with creating and maintaining the relationships. Mandatory Relationships: o o o Relationship with an Individual as an Owner of the CI. Relationship with a Support Group Relationship with other CIs in the technology stack and their relationship type, i.e. Dependency, Component, etc...

11/25/2009

Page 30 of 32

Remedy 7 User Data Model Guide

Federated Data Model

Cummins Inc. is using the federated CMDB model design where appropriate. Federated data is data stored outside the BMC Atrium CMDB but linked to CIs so that it is accessible through the BMC Atrium CMDB. The most common types of federated data are related information and detailed attributes. Related information is information about a CI that does not itself qualify as a CI and therefore should not be stored in a CMDB. Detailed attributes are attributes of CIs that are stored outside of the BMC Atrium CMDB. These attributes are not important enough or change too frequently to merit being stored with the base CI inside of the BMC Atrium CMDB. In the federated model, you store only the minimum number of important attributes inside the CMDB. Other detailed information is stored in another application that is accessed from inside the CMDB. The federated data model should be considered when an existing data source holds the detailed information, can be accessed from inside the CMDB, and there are no performance or reporting issues when accessing the data. Dynamic data such as an up-or-down state or current load on a server does not belong in the CMDB because it will always be out of date. Instead, store it as federated data in a source that can be updated more frequently.

Attributes and Classes

The CMDB should hold only common CIs and their relationships. Adding classes and attributes for unimportant CIs needlessly taxes your CMDB. Also, creating too many subclasses can leave you with classes so narrowly defined that they hold very few instances. Balance the need for categorization with the need to store similar CIs. You dont need to use every class in the Common Data Model (CDM), or every attribute of the classes. If you need to further categorize a CI class that has the specific attributes you need, consider using the existing Category, Type, and Item attributes instead of creating attributes or subclasses. These three attributes are part of the BMC BaseElement class and are thus inherited by all other CI classes. You can use them to provide three levels of categorization for instances of a class without the performance cost of a subclass. BMC Software provides extension packs that address common needs for extending the data model. Each extension pack provides extra classes and attributes for a specific type of configuration data, such as J2EE or SAP objects. For information on the BMC Atrium CMDB Common Data Model and available extension packs refer to the Common Data Model Reference Materials in the Overview section of this document.

Adding Attributes
If an existing class describes your CI well but lacks a few pieces of information, there is no need to create a subclass to hold those extra attributes. Add attributes to the existing class to store that information while avoiding the performance cost of a subclass. If you will need to store some CIs that use these attributes and some that dont make the entry mode of the attributes Optional. Adding attributes works well when you have only one variation on a class to accommodate. If you have two or more variations, each with their own set of attributes, consider creating subclasses for them instead. If the requirement is involved in a relationship that requires tracking in the CMDB then it needs to be a CI and not an attribute or a relationship between CIs.

Adding subclasses
Before you decide to add classes for CIs and relationships consider the alternatives. When one of them can address your problem, it is almost always better than adding subclasses to the CDM. But there are situations in which none of those alternatives meets your needs, such as when you need to refine your classification.

11/25/2009

Page 31 of 32

Remedy 7 User Data Model Guide

Customization and Risk Matrix The table below highlights the potential risk associated with customizations of CI Classes

Component
Standard CI Standard CI Custom CI

Field
Standard Custom Custom

Value
Custom Custom Custom Custom Custom Custom

Risk (Examples)
Low Possible work flow and reporting impact Med Possible work flow, reporting, and upgrade impact High - Possible work flow, reporting, and upgrade impact Low Possible work flow and reporting impact Med Possible work flow, reporting, and upgrade impact High - Possible work flow, reporting, and upgrade impact

Standard Relationship Standard Standard Relationship Custom Custom Relationship Custom

There is more than one way to store information about an asset. The CMDB maps business processes to the technology stacks that supports them. You achieve this by conducting a review of technology assets and identify those of value and track them within the CMDB. Value is determined by evaluating the needs of the Consumers of the data, not the Providers.

Checklist
When submitting requests to modify, create or remove Configuration Items, Classes, Sub Classes, attributes, or values consider the following: Is the data important to your business? Is this data you need to track? Do you need to perform changes against the data? Does the data need to be shared between applications or processes? What is the scope of the business requirements that need to be fulfilled, i.e., want, dont want? What business process does the information item(s) support? What process does the business currently rely on to fulfill the requirement? Who are the data providers? Who is the Owner? Who are the data Consumers? Are there any constraints that the design team needs to be aware of, e.g., resource, technology, timing, budgetary, etc? Can the mandatory relationships be maintained? Can the data be reconciled and audited? Will it be automated, semi-automated, or manual? What data will be federated? Does the tool contain the required attributes, values, classes, relationships out-of-the-box? Do the Product Categorizations exist?

11/25/2009

Page 32 of 32