Site Loader
Change Management | Creating a Change Request

This video introduces the ServiceNow features
for creating change requests. This video is intended for ITIL users, the
ones who typically create change requests. From time to time, your IT organization needs to make changes to the IT system to solve problems… or perform maintenance… or make upgrades. The ServiceNow system lets you track these
changes from start to finish. Each change is started by creating a change
request in the system. Let’s look at an example. This is a pretty
typical example, but bear in mind, things may work a little differently at your company. For this example, we’re logged on as Beth Anglin, an ITIL user. In our example, a few users have recently
submitted incidents about issues with email. We’ve already created a problem identifying
the root cause: errors in the recent email client upgrade. We determined that rebooting the email server
will fix the problem. Now we want to create a change request to
reboot the server. We could create the request directly from
the Problem form. That’s an easy way to do it since the system performs some of the steps for you. But instead we’re going to create the request
from scratch to show all the steps. To create the change request, we’ll go to
Change >Create New……and choose an emergency change since it’s a service outage. Here’s the default form. Email is a business service. The configuration item is IronMail-SD-02, which we saw in the Problem record. The loss of email is a critical problem. The risk of rebooting the server is low… …and the impact is high since it’ll restore
email service for many users. We’ll add a short description… …and a more detailed description. We’ll assign the change to the software group… …and to Emil Anderson in particular. Here on the Planning tab… …we’ll add a justification… …and an implementation plan. Since the server isn’t working now, the
risk of rebooting is low. Since the reboot is not reversible, we don’t
have a backout plan. But in general it’s good to have a backout plan in case the change doesn’t work or causes a new problem. And for the Test plan, we’ll send and receive
test email. As for the schedule, we want to get this done
by 5pm today. Let’s plan to start at 2 pm… …and finish at 3 pm. We’ll come back and record the actual start and end when they occur. By default, emergency changes go to the $CAB_Approval
group, so we can leave this check box clear. Finally, we’ll submit the change… …and here’s our request. Now let’s go back and look at a few more things. First, you’ll notice that the system detected a conflict. Down here we see that the change conflicts
with the maintenance schedule for the email server. Ordinarily we’d only reboot the server during the maintenance window. But since this is an emergency change to resolve a service outage, we’ll ignore the conflict and reboot the
server outside the window. Next… the system supplied the email server
as the affected CI. For Impacted Services…
…we’ll refresh the list… …and here are the services that’ll be
impacted by the change. In our example, the approvers for the request are determined by a workflow defined by the system administrator. And here’s the workflow. The change request is currently awaiting the
request for approval. Next we’ll enter the tasks for the change. The first task is rebooting the email server. The configuration item is IronMail-SD-02. The priority is Critical… …and the task is due today by 5pm. We’ll assign the task to Emil Anderson… …and submit. And here’s our new task. The second task is validating that email service
has been restored. Like before, the configuration item is IronMail-SD-02. The priority is Critical… …and the task is due today by 5pm. We’ll assign this task to Ethan Taylor… …and submit. There, that’s it for our tasks. The Problems tab lists the problems associated
with this change. Remember the problem we saw earlier, the reason
for this change? We’ll add that problem here. When this change is complete, this problem
will be Closed Resolved in the system. The Incidents Pending Change tab lists the
incidents associated with this change. Remember the incidents we saw before? We’ll add them here. When the change is complete, these incidents
will be Resolved in the system. Finally, if the change causes any new incidents,
we’ll come back and enter them here. But we don’t need to worry about that now. That’s all the information we need to enter,
so we’ll save our updates. Now that we’ve filled in the information,
we’ll request approval. When we do that, the state changes to Authorize… …and the workflow shows that the request
is awaiting approval. The system sends an email notification to
each approver. When they approve the request, the state will change to Approved. That’s it—our new change request is done. We’ll see how to follow a change through
to completion in the next video. For more information, please consult our product
documentation, knowledge base, or podcast. Or ask a question in the ServiceNow Community.

Reynold King

One Reply to “Change Management | Creating a Change Request”

Leave a Reply

Your email address will not be published. Required fields are marked *