You will be looking at each of the ITSM services individually in this ServiceNow ITSM tools article. Let us start with the Management of Incidents,More info go through servicenow online course
Control of incidents in ServiceNow ITSM
Next, let's have a look at what a ServiceNow incident is. The first thing needed when a user faces a problem and wants to get in contact with the support team is to document the information in a user form. An incident is any problem recorded by a user or group of users that are registered with a specific record ID, to put it in simple terms.
Let us look at the measures involved in Incident Management to get more details about an incident:
Stage 1: Classifying
Either the hardware, software, network, or some potential combination of them can be connected to the problem.
Examples:
The laptop stopped running. This may be due to an inherent problem with the hardware or software.
Wi-Fi has problems with results. This can be triggered because of a network issue or software problem.
Stage 2: The Goals
The reported incident is treated according to its priority level. Priority is a mixture of the effect of an event on the company as well as the level of urgency.
Incidents are graded following their respective priority levels as P1, P2, P3, P4:
P1-The Vital
The P2-high
P3-Moderate for the
P4-Low in scale
P5-Planning with
EXAMPLE:
An incident that has a high impact with an urgent timeline at the organizational level is known as a P1 level or critical level incident, whereas an incident with a low impact with a standard timeline at the consumer level is categorized as a P5 level or preparation level incident.
In addition to resolving accidents, preventing associated accidents, and reducing the total number of incidents is also important. This can only be achieved by defining the underlying issue. This takes us to our next problem management subject.
Control of Issues in ServiceNow ITSM
Issue Management is concerned with the detection of the root cause of the problem. We analyze how accidents can be mitigated or minimized. Assume that there are several email-related accidents. To determine the root cause, we may perform Root Cause Analysis.
Step 1: Define the problem and log in.
IT workers can create a log and make a note of the 'error' manually, or we can refer to an incident report.
Step 2: Update & explore the problem
It is possible to communicate notifications via Email. To accomplish this, we select the inbound Email configuration.
Service Level Agreements (SLA): are used to assign tasks priority and track the progress of the team.
Inactivity tracker: We can construct events that are triggered during a certain period when the problem is not dealt with. This event could be a message from a script or email.
Step 3: Fix the Problem
If the problem is solved, the problem-related cases are immediately closed. We can call it a Known Error if we can not find a solution to the given problem, which saves us time in the future.
A Configuration Item (CI) is the basic asset in a CMDB (Configuration Management Database) for those not familiar with CIs.
Example: Workstation, server, or service for a company
The main distinction between a list of static properties and CMDB is that we map CI relationships. This brings us to Dependency Views, our next subject. The relationships between various configuration objects are described by Dependency Views. One example of Dependency Views is the following diagram.
The interaction between the Email Exchange Server and separate email servers can now be seen. Also, it is possible to test the San Storage Unit.
Next, to classify the affected region, we establish problem tasks. For network and server domains, we may assign two teams, one each. Since the incident is important, we need a temporary solution, such as an alternate server, until the specific server is set. It may require a software patch from the server team to repair the email server to permanently solve the problem.
If the problem is found, the problems causing the problem must be resolved. This takes us to our next topic, Change Management.
Change Management in ServiceNow ITSM
Change Management is the lifecycle of changes proposed and the changes mirrored. We create a problem and conduct Root Cause Analysis after accidents are identified. Based on the given situation, we further build Change Requests. Changing activities are then scheduled and their related events and problems are closed/resolved after completion.
Requests for changes may be divided into Normal or Emergency. Normal changes require written approval and a fixed protocol is in effect, while verbal contact for emergency changes is necessary.
Workflows are used from initiation to acceptance to reflect the processes involved in the Change Request lifecycle. This is represented in the following diagram.
Workflow-change-Servicenow ITSM- tools
Having a folder of files covering previous support requests and posts related to the Platform is highly advantageous. This leads to Knowledge Management, our next subject. Let's take a look at Information Management and move forward with this ServiceNow ITSM Resources site.
The Management of Information in ServiceNow ITSM
ServiceNow comes with a Knowledge Base that includes articles, Faq's, troubleshooting. This is a plethora of data covering many classes. Who can submit an article to a database of knowledge? Information articles may be added by the owner or manager along with contributors who are allowed to contribute details to the knowledge base. Contributing to the Knowledge Base is also authorized by the admin.
Let us now understand the Information article lifecycle in the ServiceNow Platform in our ServiceNow ITSM resources site.
Articles Posting in ServiceNow ITSM
Two distinct scenarios are probable when an author publishes his paper:
If the Approval Publish Workflow is configured, the article reaches the Draft State that can either accept or deny the article and is forwarded to the Reviewer.
The article is automatically published and appears in the Knowledge Base if the Instant Publish Workflow is configured.
Retirement of Objects in ServiceNow ITSM
If it is no longer helpful, the article may be deleted from the Knowledge Base. This cycle is referred to as retirement.
The article transitions to the pending retirement state and the owner of the Knowledge Base needs to approve its retirement if the Approval Retirement Workflow is applied.
If the Instant Retire Workflow is applied, the article skips the analysis and moves straight to the withdrawal point. After the article is deleted, the Knowledge Base does not appear. The post, however, remains within the system and, if necessary, can be restored to the Draft state.
Step1: Create an Incident
To build an Incident on the ServiceNow Website, follow the instructions below.
Incident-record-service
We create a record of an event to report that the email service is not functioning. The record includes the assigned mission, organizational effect, affected business resources and configuration objects, urgency, as well as a problem summary. The diagram below reflects the same thing.
Step 2: Build a problem
To perform Root Cause Analysis, as shown below, we create a problem by clicking the Incident Properties tab.
We may go ahead and construct problem tasks after we look at the dependency view and allocate it to a particular community or user.
In our example, a compromised network adapter has been established as a problem after Root Cause Analysis, so we assign problem tasks to the network community and assign Fred Luddy as the associated user.
Problem-task-service-ServiceNow ITSM-tools
Step 3: Requests to Modify
If the problem is established, the assigned task assigners may call if a change request is necessary to solve the problem. When a Change Request is initiated, the issuing state is changed to pending.
In our example, Fred Luddy's assignee takes care of the Change Request to replace the network adapter found.
Step 4: Closing Accidents and Issues
If the Improvement Request is completed/closed, all relevant issues are resolved automatically.
The problem linked change request-ServiceNow ITSM tools request in ServiceNow ITSM tools
All related activities are automatically closed after one day. We can also manually close them by setting the Closed / Resolved state parameter.
Incident-linked-change request-ServiceNow ITSM tools
Step 5: Importing a Knowledge Base Issue
We may extract information directly from the filled-out form of the problem record. This can be applied to the Knowledge Base as an article to provide help to users who can in the future experience the same problem.
To do so, we open the associated problem file and move to the Post Information alternative.
Conclusion
This takes us to the end of the article for today. I am sure you get the idea of how ITSM tools from ServiceNow come with a feeling of consumerism. This is mostly found prevalent in social media applications but was due in the ITSM field for a long time. ServiceNow seeks to recreate the ease of use that we experience for internal support activities within the company in our day-to-day activities. You can learn more about ServiceNow ITSM through ServiceNow online training.
No comments:
Post a Comment