Deployment Sequence

Tasks that will help you define your account settings include:

• Determine your hours of operation, taking into account any remote locations that can access the system.
• Determine SMTP settings for sending email and Email Listener settings (POP or IMAP).
• Organize Microsoft SQL Server reporting settings.
• Note any integrated or add-on modules for your system.
• Note additional service settings, including those for messaging and licensing servers.
• Identify the email client settings required to send and receive notifications.

Items to pursue when organizing your customer information include:

• What type of customers are you supporting? Are they internal customers or external customers? Are you a Managed Service Provider (MSP) for another organization?
• What is their level of expertise when using technology such as a self-service module or an automated call center?
• Distribution of your customer base. This helps define your hours of operation.
• The customer structure as it pertains to the HEAT environment. For example, knowledge of the customer-service and IT departments is vital in designing the system.
• The service level agreements that are being provided. Should every customer receive the same experience? Does it differ by department? By company?

Incidents are events that are either caused by or may cause an interruption in the quality of service. Incident management involves creating, monitoring, evaluating, and resolving incidents. The main goals of incident management are to restore normal service quickly and to reduce the impact on business operations.

Questions to ask when planning for incident management include:

• How are incidents classified? Do you offer multiple services that will require different structures?
• How will a customer contact the Service Desk to submit an incident? Creating an incident through the Self Service module? Or by calling or emailing the Service Desk to report the incident?
• What existing knowledge bases and other resources used for research are in place at your company? Do you plan on implementing any?
• What escalation stages and follow-up workflows are in place at your company? Do you have a formal set of service level agreements or do they need to be developed?
• What is the criteria for resolving and closing an incident? How is this information captured and added to your knowledge base?

Service requests are for normal services that do not involve a failure of some kind. They can include requests for disk space or adding a new user to the system.

Questions to ask when planning for service requests include:

• What items are available for request in your service catalog?
• Who will process service requests?
• What is the criteria for fulfilling a service request?

Change management is the process of assessing any impact or potential risk a proposed change could have on your organization before it is introduced. Change management's goal is to manage the process of change without creating incidents related to change.

Questions to ask when planning to manage a change through its lifecycle include:

• How will changes be categorized?
• How is a change request introduced and approved?
• What is the schedule and process for implementing a change? Is there a staging area for testing a change before implementation in a production environment?
• If needed, how will a change be rolled back in the production environment?

Enabling the Self Service module involves planning out the accessibility of services from this module.

• What levels of Self Service access should be available? Should it vary by contracted support level or service level agreement?
• What system information should be available to the Self Service user?
• Can the user access and search your organization's knowledge base, FAQ files, or announcements through this portal?
• Can the user create a support ticket through the portal? If so, how will it comply with any defined service level agreements?
• Create the user create a service request? If so, what items are available in the Service Catalog?

Structuring your company's service organization lends itself to planning out the workflows processed within HEAT. Typical roles include Service Desk Analysts and Service Desk Managers. Questions to ask when mapping our your service organization include:

• Who will assign incidents or service requests to Service Desk personnel? Will the ability to assign an incident and its associated tasks be owned solely by a Service Desk Manager, or can a Service Desk Analyst take ownership upon submission?
• What restrictions, if any, are there between departments? Can a Service Desk Manager for group A manage incidents or service requests for group B?

As you map out the roles and workflows required to process HEAT information to a successful resolution, these components often dictate the user interfaces required to monitor and capture information in the system.

Determine the central business functions that your organization needs to track and manage in HEAT. The HEAT demo database contains business objects and other database structure elements to help you plan an effective design. For example, a technical support center needs to track customer incidents, and a service organization needs to track service orders. Business objects would then be required for incidents and service requests.

Also, determine the categories of data supporting these central functions, such as name, address, urgency, and order number information.

• List your organization's central business functions or components.
• List your organization's supporting categories of information or basic business components.

Outlining Business Object Groups

Group similar objects so they can share fields. A group lead contains the shared fields, and the remaining group members are similar objects, functioning in their own capacities.

For example, address could be a business object group because several types of addresses exist and contain similar information. Address would be the group lead and its members could be Address.Email, Address.Home, Address.Work, etc.

• From the business objects listed, outline the objects that would benefit from sharing fields as part of a group.
• Determine whether each group member functions as a lead (contains central information) or supporting object (contains supporting information).

During the development of the business objects, note the types of information that can be stored. Continue adding to your list of objects and add new objects as needed.

Outlining Business Object Relationships

When an object must include information from another object, create a relationship between the objects. Each relationship comprises a:

• Parent object: Functions as the center of a relationship.
• Child object: Assists a parent object by supplying it with additional data.

When creating the forms that appear in the application, parent object forms appear in the main user interface and child object forms appear as tabs in the lower pane.

From the business objects and business object groups you have created, outline the objects that need to be part of a relationship.

To help determine the objects to relate, think about which objects should appear on the same layout (that is, which objects should appear as tabs on the form of another object).

Categorize each relationship and determine the following:

• Which object is the parent.
• Which object is the child.
• What type of relationship is most appropriate: contains, associates, or embedded.
• Whether you want a one-to-one relationship (parent has only one child), a one-to-many relationship (parent has several children), or a many-to-many relationship (child record has a relationship with more than one parent record).

Organizing Fields

For each business object, list the parcels of information to store within the object.

When creating fields, define the field properties, including its format (text box, DateTime box, checkbox, etc.), length, default value, and requirement in completing a form. After adding the fields, you can define additional field properties, including whether it has validation options or is encrypted.

Certain fields may need to use expressions for calculating a value or use a counter to automatically increment a tracking number contained within.

Assigning Layouts

Layouts comprise the forms, tabs, and grids that display a complete view of the parent record and its child records in the application. After creating objects, the administrator adds a default layout for the object.

Designing Dashboards

Dashboards are groupings of dashboard parts that appear on the main user interface in the application. Dashboard parts comprise elements such as a specialized grid to the home page dashboard, a chart, etc. You determine the scope of each dashboard: personal, global, or role (these are assigned to roles and called default user interfaces).

Create the default set of dashboards as an administrator. However, you can grant permission to create additional custom dashboards to other roles, such as Service Desk Manager.

Defining Search Criteria

Define default search users can employ from the application. Searches employ object matching, which combine business objects and expressions. Create the default set of searches as an administrator. However, you can grant permission to create additional custom searches to other roles.

Organizing Quick Actions

Define automated actions to perform routine tasks in the application. Quick actions are business object-based.

Create the default set of quick actions as an administrator. However, you can grant permission to create additional custom quick actions to other roles.

The roles you create let you define different views of the user interfaces you create later. In deciding on roles to add, consider your users, and anticipate the job tasks they will perform upon logging in.

Each role is likely to require a different set of forms, dashboards and controls to facilitate their job duties. For example, a Self Service user who is interested in tracking a particular service request ticket would create the request using a form, while a Service Desk Analyst would use a dashboard or user interface to process multiple requests from different origins. A Change Manager is likely to require a different set of forms than a Service Desk Manager, despite operating at a supervisory level.

• List the types of roles your organization needs.
• Group users within these roles.

Before implementing a production system, FrontRange Solutions recommends testing your deployment design in an offline database.