Using the Deployment Sequence

Gather the following information before performing the Neurons for ITSM deployment:

The customer types serviced by your company

For information about the data you'll need, see Organizing Your Customer Information.

Define the workflow for incidents, from notification of an incident to its resolution. For information about designing incident workflow, see Planning for Incidents.

Define the workflow for service requests placed by Neurons for ITSM users. For example, service requests may include IT tickets, requests to book a conference room, or orders for supplies. For information about planning service request workflows, see Planning for Service Requests.

Define the workflow for changes, from the initiation of a change request to its implementation in a production environment. For information about planning change workflow, see Planning for Changes.

  Step Description Information

 

 

Entering Account Information

 

Define the customer types serviced by your company.

Adding Customer Information

 

Define the workflow for incidents, from notification of an incident to its resolution.

Setting Up Incident Management

 

Define the workflow for service requests placed by Neurons for ITSM users. These can include IT requests, booking conference rooms, or ordering supplies to support a particular department.

Configuring the Service Desk

 

 

Define the workflow for changes, from the initiation of a change request to its implementation in a production environment.

Setting Up Change Enablement

Defining the Self-Service Portal

Define the customer Self-Service Portal, where customers can use a web browser to log incidents, place service requests, access the company knowledge base and track the progress of service ticket items in Neurons for ITSM.

Configuring the Self-Service Portal

Structuring Your Service Organization

Define the service structure of your company. This includes the Service Catalog offered by your company as well as the service level agreements.

Internal tasks involve defining the steps needed to provide each service offering in the Service Catalog.

Working with the Service Catalog

Defining Your User Interfaces

Assemble the default dashboards to be displayed on the user's home page upon logging in, identify search criteria, and identify quick actions to benefit your users. Determine the core business functions to be stored in business objects as well as grouping similar business objects so that they can share fields. Also, determine relationships to be created between business objects to enable information to be shared. Design the forms used in your application based on these business objects.

Working with Dashboards

 

Using Actions

Working with Business Objects

Using Forms

Using Layouts

Defining Your Users and Roles

Roles determine the access a user has to the Neurons for ITSM user interfaces, which include forms, dashboards, and controls. Organize your users by job task before adding them to your application.

 

Creating a Test Application

Design a test case to determine that your application settings are producing the desired results before deploying the application.

 

Defining Your Account Settings

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 application.

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 application.

Note additional service settings, including those for messaging and licensing servers.

Identify the email client settings required to send and receive notifications.

See Entering Account Information.

Organizing Your Customer Information

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 Neurons for ITSM environment. For example, knowledge of the customer-service and IT departments is vital in designing the application.

The service level agreements that are being provided. Should every customer receive the same experience? Does it differ by department? By company?

See Adding Customer Information.

Planning for Incidents

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 Portal? 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?

See Setting Up Incident Management.

Planning for Service Requests

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 application.

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?

See Configuring the Service Desk.

Planning for Changes

Change Enablement is the process of assessing any impact or potential risk a proposed change could have on your organization before it is introduced. The goal of Change Enablement 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?

See Setting Up Change Enablement.

Defining the Self-Service Portal

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

What levels of access to the Self-Service Portal should be available? Should it vary by contracted support level or service level agreement?

What application information should be available to users in the Self-Service Portal?

Can the user access and search your organization's Knowledge Base, FAQs, or announcements through the Self-Service Portal?

Can the user create a support ticket through the Self-Service Portal? If so, how will it comply with any defined service level agreements?

Can the user create a service request through the Self-Service Portal? If so, what items are available in the Service Catalog?

See Configuring the Self-Service Portal.

Structuring Your Service Organization

Structuring your company's service organization lends itself to planning out the workflows processed within Neurons for ITSM. 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?

See Working with the Service Catalog.

Defining Your User Interfaces

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

See Working with Dashboards, , Using Actions, and Using Forms.

Structuring Business Objects

About Structuring Business Objects

Outlining Group Business Objects

Outlining Business Object Relationships

Organizing Fields

Assigning Layouts

About Structuring Business Objects

Determine the central business functions that your organization needs to track and manage in Neurons for ITSM. The Neurons for ITSM 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.

See Working with Business Objects.

Outlining Group Business Objects

Group similar business objects so that they can share fields. A group lead contains the shared fields, and the remaining group members are similar business 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 business object and member business objects could be Address.Email, Address.Home, Address.Work, etc.

From the business objects listed, outline the business 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 business 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 business objects and add new business objects as needed.

See Creating a Group Business Object.

Outlining Business Object Relationships

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

Parent business object: Functions as the center of a relationship.

Child business object: Assists a parent business object by supplying it with additional data.

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

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

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

Categorize each relationship and determine the following:

Which business object is the parent?

Which business object is the child?

What type of relationship is most appropriate: contains, associates, or embedded?

Whether it is 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).

See About Business Object Relationships.

Organizing Fields

For each business object, list the parcels of information to store within the business 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.

See Working with Fields.

Assigning Layouts

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

See Using Layouts.

Customizing Your System

Designing Dashboards

Defining Search Criteria

Organizing Quick Actions

Customizing the Loading Page

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 list 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.

See Working with Dashboards.

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.

See .

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.

See Using Actions.

Customizing the Loading Page

Customize the text that users see when the application is loading. Define a new global constant called ApplicationDisplayName.

See Defining the Loading Message.

Defining Your Users and 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 user in the Self-Service Portal 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 that your organization needs.

Group users within these roles.

Creating a Test Application

Before implementing a production application, Ivanti recommends testing your deployment design in an offline database.