Current State (As-Is) Assessment - IfDS (Published 2014-04-14)

CURRENT STATE ANALYSIS &
RECOMMENDATIONS
PREPARED FOR IFDS
APRIL 14, 2015
CURRENT STATE ANALYSIS & RECOMMENDATIONS
Document Version History:
Version Revision Summary of Changes Modified by

Number Date
1.0 2015-04-13 Version 1.0 document published to IFDS. Chris Rutherford
Document Contributors:
Name Title
Adesola Falobi Business Process Consultant

Chris Rutherford Engagement Officer
Dhiraj Girdhar Engagement Officer
Jatinder Bhardwaj Technical Lead
Zubair Zia Project Coordinator
This document contains information that is proprietary and confidential to Innomentum Solutions Corporation and shall not be disclosed to other companies or third parties other than those
addressed to in this document. This document shall not be duplicated, transmitted or used in whole or in part for any purpose other than for its intended purpose.
1|Page
Table of Contents
1 Introduction .................................................................................................................... 4
1.1 Purpose and Scope ................................................................................................................4
1.2 Analysis Approach.................................................................................................................4
2 Executive Summary ......................................................................................................... 5
3 Key Observations............................................................................................................. 8
3.1 Technical Observations .........................................................................................................8
3.2 Operational Observations ................................................................................................... 10
3.3 Process Observations .......................................................................................................... 11
4 Key Recommendations .................................................................................................. 12
4.1 Approach to Identify Recommendations .............................................................................. 12
4.2 Prioritized Recommendations ............................................................................................. 12
5 Appendix A: Detailed Process Analysis .......................................................................... 14
5.1 Detailed Process Observations ............................................................................................ 14
5.1.1 Analysis Approach .................................................................................................................. 14
5.1.2 Change Management Current State Process Flow................................................................. 15
5.1.3 Change Management Process Analysis Table ........................................................................ 15
5.1.4 Incident Management Current State Process Flow................................................................ 21
5.1.5 Incident Management Process Analysis Table ....................................................................... 21
5.1.7 Problem Management Current State Process Flow ............................................................... 28
5.1.8 Problem Management Current State Analysis ....................................................................... 28
5.1.9 Release Management Current State Process Flow ................................................................ 33
5.1.10 Release Management Current State Analysis ...................................................................... 33
5.3 Detailed Process Recommendations .................................................................................... 36
5.3.1 Change Management Process Recommendations................................................................. 36
5.3.2 Incident Management Process Recomendations................................................................... 37
6 Appendix B: Detailed Technical Analysis ........................................................................ 39
6.1 Detailed Technical Observations .......................................................................................... 39
6.1.1 High-Level Technical Architecture .......................................................................................... 39
6.1.2 Instance Review (ACE Report) ................................................................................................ 40
6.1.3 Data Structure ........................................................................................................................ 41
6.1.4 Incident Module Review......................................................................................................... 42
6.1.5 Change Module Review .......................................................................................................... 43
6.1.6 Problem Module Review ........................................................................................................ 46
6.1.7 Release Module Review ......................................................................................................... 48
6.3 Detailed Technical Recommendations ................................................................................. 49
2|Page
6.3.1 Multifactor Factor Security Recommendations ..................................................................... 49

6.3.2 Incident Module Technical Recomendations ......................................................................... 50
6.3.3 Change Module Technical Recomendations .......................................................................... 52
6.3.4 Problem Module Technical Recomendations ........................................................................ 53
6.3.5 Release Module Technical Recomendations .......................................................................... 53
6.3.6 Old Process to New Process Technical Recomendations ....................................................... 53
7 Appendix C: Supporting Artifacts .................................................................................. 55
3|Page
1 Introduction
1.1 Purpose and Scope
Innomentum was engaged by IFDS to conduct an analysis of their current ServiceNow implementation
to ascertain the soundness of using the environment as the foundation to move forward with an
additional process implementation
The scope of the assessment included:
 Evaluation of the current ServiceNow implementation from a process and technology perspective.
 Inspection of the degree of customization within the current environment (to assess future
upgradeability).
 A review of the deviations from standard industry practices within the current implementation.
 A review of existing documentation in order to enable on-going support of the environment.
 Recommendations on process and technology improvements within the platform.
 Recommendations on the environment set up and how quality of code is maintained / managed
within it.
1.2 Analysis Approach
The following approach was used by Innomentum to complete the assessment of the IFDS ServiceNow
implementation.
4|Page
2 Executive Summary
Innomentum was asked by IFDS to complete a current state analysis with corresponding
recommendations on the instance of ServiceNow in use by the organization.
To conduct the analysis, Innomentum focused on both technical, operational and process aspects of the
current installation.
The approach of the assessment consisted of:
 Discussion with key IFDS personnel involved with the prior installation.
 Review of existing documentation (where available).
 Technical, operational and process review of the existing installation (through use of inspection,
comparison of best practices and ServiceNow toolsets).
The team conducting the review consisted of both technical and process consultants. The team also
leveraged a product engineer from ServiceNow to conduct further technical analysis on the platform.
The analysis focused on the following areas:
 Technical: inspection of the ServiceNow instance, underlying data structure, security, workflow
and use of scripting.
 Operational: inspection of existing environments, testing procedures / methods and system
documentation.
 Process: inspection of existing business processes used by IFDS for incident, change, problem
and release.
Based upon the technical, operational and process review, Innomentum has uncovered no major issues
which would prevent IFDS from using the current instance of ServiceNow as the foundation to support
it's current ITIL process deployment initiative.
The following is a summary of Innomentum's key observations and associated recommendations:
During technical analysis, the following was observed:
# Observation Priority to Recommendation

Address
1 Security Gap: Only single factor security is High Implement multi-factor security using a
implemented on the platform. device that generates a secure token. This
will prevent unauthorized users that have
“hacked” credentials to access the system.
5|Page

Address
2 Security Gap: Access control lists (ACL) and UI High Eliminate the current use of client scripting
Policies are not used on the platform for page / for page / form / field access. Implement
form / field level security. This has resulted in proper use of ACL and UI Policies, which is a
security gaps within the platform for field level ServiceNow best practice.
“edit access”.
3 Improper Use of Workflows: Workflows within Medium Implement new workflows within ServiceNow
ServiceNow have been implemented in a non- (based on new process design) that leverage
optimized, “hard coded” manner. “main workflows” and “sub workflow”
techniques.
4 Improper Screen Customization: Each of the Medium Verify the need for custom fields. Leverage
reviewed modules for Incident, Change, ServiceNow forms out of the box where
Problem and Release contain custom fields that possible.
were added during the initial implementation. It is recommended to reset the UI of these
Some of these fields do not work properly and modules (note: this does not lose existing
overall usability is impeded. data) to out of the box prior to additional
changes to the UI.
5 Performance Concerns: Technical analysis of Low Leverage the ACE Report and systematically
custom code (as found in the “ServiceNow ACE fix each of the identified functions using
Report” found that there were a number of “improper scripting” by leveraging
functions written using “improper scripting”. ServiceNow best practices for function calls.
Functions such as this can impact overall
system performance.
During operational analysis the following was observed:

Address
6 Insufficient Testing Procedures: There are High Implement new processes and procedures for
insufficient testing procedures in place when testing. This should include both system test
new changes are implemented in ServiceNow. (executed in the test environment) and user
Current process is for the developer to roll out acceptance testing (executed in a user
a change in development, test and production acceptance test environment). The developer
instances without a separate tester reviewing that made the change should not complete
the change in each environment. system testing. A member or representative
of the business should complete UAT.
7 Insufficient Environments: There are Medium It is recommended that IFDS procure two
insufficient environments available to complete additional instances (in addition to the
dedicated user acceptance testing and training current three). This would allow dedicated
6|Page

Address
activities. Currently, there are only environments for each of development, test,
development, test and production training, UAT and production.
environments available
8 Documentation Gaps: There are significant Medium It is recommended that documentation gaps
documentation gaps for the current be addressed. The opportunity exists to
implementation of ServiceNow. This is properly document the IFDS ServiceNow
problem for overall maintenance and implementation within the project when new
understanding of the system from an processes for Incident, Change, Problem and
administrative perspective. Release are implemented.
Completing the process analysis was important in order for the team to (a) validate raised concerns
regarding existing business processes and (b) assist Innomentum with identifying gaps between current
technical implementation of workflows within ServiceNow against current processes.
During process analysis, the following was observed:

# Process Observation Priority to Recommendation
Area Address
9 Incident It was observed that there were significant gaps Leverage industry best
with existing processes when compared to industry practices during
10 Change best practices. upcoming process
It was observed that there were insufficient High redesigns of Incident,
11 Problem
documentation and understanding of these Change, Problem and
processes within IFDS to compare against industry Release modules.
12 Release
best practices.
7|Page
3 Key Observations
3.1 Technical Observations
The technical analysis consisted of reviewing the system setup, underlying data structures, security,
workflows, use of scripting and the user interface. The following observations were identified when
reviewing the technical characteristics of the IFDS ServiceNow instance.
# Description Risk Level Risk Explanation

OBS-01 Multifactor Authentication: High The identified risk is associated with security.
The current implementation is using Without multifactor authentication, there is a
single factor authentication, which risk of the system being penetrated. Multifactor
provides a lower barrier of security as authentication would include the use of
compared to multifactor credentials and an independent security device
authentication. (such as a fob generating a security token)
thereby ensuring that sign in only occurs after
two layers of authentication has occurred.
Without multifactor authentication, there is a
risk that an unauthorized user may access the
system by knowing a set of credentials (user
name, password) they may have come in
contact with.
OBS-02 Improper Use of ACL and UI Policy: High The identified risk is associated with security.
Implementation of access control list Due to the inconsistency on how field level
(ACL) and User Interface (UI) Policy has security was implemented, the inherent risk is
not been implemented correctly in all that an unauthorized user may have the ability
cases. It was observed that some to edit information they are not supposed to be
pages have inconsistent security (i.e.; able to edit. Since this security was
who is allowed to edit what) on fields implemented within page level scripts and not
due to incorrect usage of client centrally via ACL / UI Policy; there is also a
scripting. maintainability risk in managing field level / data
access within the system as it requires the
organization to inspect /manage / edit all page
level code going forward for security purposes.
OBS-03 Improper Use of Workflows: Medium The identified risk is associated with
Workflows have not been maintainability within the system. Workflows
implemented in a consistent, were not implemented efficiently and are
optimized fashion. For example, in the therefore in effect “hard-coded” to a particular
“change module” there are no central change type or purpose. To continue building
workflows used to define a standard or workflows in this manner would result in
8|Page

emergency change. significant operational cost in maintaining them
within the organization; in particular as the
number of workflows increase with further
process implementation on the platform.
OBS-04 Use of Custom Fields: Medium The identified risks are associated
Incident, change, problem and release maintainability and usability. While the use of
modules all have use of new custom the additional fields does not cause harm within
fields that appear to have been the system, it does however create more work
implemented during the initial set up to upkeep the system in particular during
of ServiceNow within IFDS. While instance upgrades (where custom changes need
these custom fields appear to have no to be tested and verified to ensure there are no
negative impact to the application upgrade issues). Furthermore, custom fields
they do seem to lack business value that were not coded properly or do not serve a
and may result in confusion. business purpose can cause confusion to a
Furthermore, the way in which the business user thus decreasing overall usability.
fields were implemented is not In some cases there were multiple status fields
following ServiceNow best practices. implemented on the screen, which would
certainly create user confusion.
OBS-05 Improper Use of Scripting: Low The identified risk is associated with
There are some minor, recommended performance. During analysis, the team
changes that would enhance leveraged a ServiceNow provided, out of the box
performance of some screens. The inspection tool (the “ACE report”). This report
underlying data structures are fine. identified that there was a significant number of
improperly coded functions that would impact
UI performance. The risk level was identified as
low.
9|Page
3.2 Operational Observations
The operational analysis consisted of reviewing the system in areas of maintainability, operational
effectiveness and overall quality. The following observations were identified when reviewing the
operational procedures and processes associated with the IFDS ServiceNow instance.

OBS-06 Insufficient Testing: High The identified risk is associated with quality.
It was identified that IFDS does not Without proper testing completed by qualified
properly test changes to ServiceNow resources, there is a significant risk that changes
prior to promotion to the production may be introduced into production that either
instance. Improper testing can result (a) do not work properly due to improper coding
in system changes implemented into or (b) do not meet the intended business
production that do not work as requirement. Overall, this poses significant risk
expected which can cause significantly within the IFDS ServiceNow instance because
more harm than good overall. The improperly tested code can equally impact the
lack of testing includes both system business value and integrity of the platform.
test (quality assurance testing after
the developer has finished their work)
and user acceptance testing (testing a
business user might complete to
validate a change that has passed
system test).
OBS-07 Available Environments: Medium The identified risk is associated with quality.
The current installation of ServiceNow Without dedicated environments for UAT and
does not have enough instances training, it becomes challenging to ensure that
available to meet the full software UAT and training activities are not disrupted
development life cycle of IFDS. during the normal SDLC life cycle. It is a best
Currently, IFDS has three instances; practice to possess a dedicated environment for
development, test and production. It UAT so that during acceptance testing by the
was identified that IFDS would need business, there are is no possibility that new
five instances; where the two code may be introduced into the environment.
additional instances would be used for Similarly, it is a best practice for training to
user acceptance testing (UAT) and possess a dedicated environment so that there
training. is no chance of disruption with newly
implemented code during a planned training
cycle.
OBS-08 Insufficient Documentation: Medium The identified risk is associated with
There is a significant lack of functional maintainability and operational effectiveness.
and technical documentation for how Without proper documentation it is challenging
the system was implemented at IFDS. to maintain any system from an ongoing
This documentation also extends to perspective. Although staff members may
how to operate and maintain system retain knowledge, this is short-term thinking as
processes from an administration staff movement (promotions or attrition) can
perspective. result in a significant knowledge loss, which can
hurt the organization.
10 | P a g e
3.3 Process Observations
The following observations were identified when reviewing the business processes and procedures
associated with incident, change, problem and release management within IFDS.
It was identified by IFDS that there were known issues and gaps within the aforementioned business
processes. These issues and gaps were being addressed by a separate team within the organization as
part of the overall program / project.
However, completing the process analysis was important in order for the team to (a) validate raised
concerns regarding existing business processes and (b) assist Innomentum with identifying gaps
between current technical implementation of workflows within ServiceNow against current processes.
During analysis itself, it was discovered that there was a lack of documentation associated with existing
business processes and how they were implemented within the ServiceNow instance.
# Process Reviewed Risk Level Risk Explanation

OBS-09 Incident Management High It was observed that there were significant gaps with existing
Process processes when compared to industry best practices.
Additional information can be found in section “Appendix A:
Detailed Process Analysis”.
OBS-10 Change Management High It was observed that there were significant gaps with existing
Process processes when compared to industry best practices.
Additional information can be found in section “Appendix A:
Detailed Process Analysis”.
OBS-11 Problem Management High It was observed that there were insufficient documentation
Process and understanding of these processes within IFDS to compare
against industry best practices. Additional information can be
found in section “Appendix A: Detailed Process Analysis”.
OBS-12 Release Management High It was observed that there were insufficient documentation
Process and understanding of these processes within IFDS to compare
against industry best practices. Additional information can be
found in section “Appendix A: Detailed Process Analysis”.
11 | P a g e
4 Key Recommendations
4.1 Approach to Identify Recommendations
Recommendations were identified against each of the observations contained within “Section 3: Key
Observations”. In some cases a recommendation addressed several of the identified observations. For
each recommendation listed within this section the following was identified:
 Priority: The priority in which Innomentum feels the recommendation should be actioned
(High, Medium or Low).
 Related Observation: The observation from “Section 3: Key Observations” the recommendation
is derived from.
 Risks Mitigated: The risks identified within the related observation that the recommendation
will address.
4.2 Prioritized Recommendations
The following recommendations were identified and listed within a prioritized order (highest to lowest)
for IFDS to consider.
# Recommendation Priority Related Risks Mitigated
Observation
REC-01 Implement multifactor authentication to strengthen High OBS-01 Security
security on the platform. (Technical)
REC-02 Leverage ACL and UI Policy correctly for page level High OBS-02 Security
security (do not use client scripting for page level (Technical)
security).
REC-03 Implement system test (quality assurance) processes High OBS-06 Quality
and procedures when implementing new features on (Operational)
the ServiceNow platform. New features implemented
in the development environment should always be
tested by a qualified tester (that is not the developer)
within the test environment prior to being promoted to
the production environment.
REC-04 Leverage industry best practices during upcoming High OBS-09, OBS- Process
process redesigns of Incident, Change, Problem and 10, OBS-11,
Release modules. OBS-12
12 | P a g e
# Recommendation Priority Related Risks Mitigated

Observation
(Process)
REC-05 Implement workflows correctly in an optimized Medium OBS-03 Maintainability
manner. Leverage the concept of “main workflows” (Technical)
that control over arching governance of a process.
Leverage “sub workflows” that can focus on a specific
branch of logic and be plugged into a main workflow.
New workflow design should only take place after new
processes have been designed for incident, change,
problem and release.
REC-06 Reset the user interfaces of incident, change, problem Medium OBS-04 Maintainability,
and release. This will achieve a “clean slate” for (Technical) Usability
leveraging ServiceNow out of the box. (Note: this will
not delete existing data or workflows in the system).
Only leverage custom fields were it is really required.
REC-07 Purchase additional instances of ServiceNow to move Medium OBS-07 Quality

from a three (development, test, production) to five- (Operational)
instance environment (development, test, UAT, train &
production). This will provide greater flexibility for user
acceptance testing and training activities with business
users.
REC-08 Shore up missing or incomplete documentation. A Medium OBS-08 Maintainability,

lack of documentation for an implemented process or (Operational) Operational
system can severely impact operational effectiveness Effectiveness.
within an organization. This is particularly true when
staff turnover occurs and knowledge is “lost”. It is
recommended that when the new business processes
are designed for incident, change, problem and release
that they be documented and stored within a proper
document repository at IFDS. Furthermore, all changes
to ServiceNow for modifying the existing
implementation or adding new functionality should
also be documented and stored in the appropriate
document repository.
REC-09 Correct, “improper scripting” warnings in the system. Low OBS-05 Performance
This can be completed most efficiently by leveraging (Technical)
the ACE report (contained within this document). The
report identifies each function that contains improper
scripting so that changes can be made systematically to
each function.
13 | P a g e
5 Appendix A: Detailed Process Analysis

The following represents the current state of Technical and Functional analysis of the ITSM Processes
within the IFDS ServiceNow Modules (Change, Incident, Problem and Release).
5.1 Detailed Process Observations
5.1.1 ANALYSIS APPROACH
This section captures detailed analysis of IFDS current Change and Incident Management processes and
how it relates to the Industry Best Practices.
The approach for this analysis is tailored towards identifying the various process stages currently in
place and verifying how they conform to ITIL/ServiceNow best practices. The goal is to identify the gap
between the two states and provide recommendations based on the gaps.
Below is the structure of the analysis table:
1. Process Step – This captures the various current process steps adopted in IFDS when change or
incident record is created till when the record is closed i.e. Change/Incident life cycle.
2. IFDS Change Process Description – This provides a detailed description of the process steps
identified above i.e. specify the action being carried out in each stage as it relates to IFDS and
identify the various roles responsible for carrying out the actions.
3. Best leading ITIL practice – This provides a detailed description of what happens in each stage
based on best ITIL practice.
4. Gap/Recommended – This illustrates the gaps identified between each state and provides
recommendation based on the gaps.
5. Rating – This is designed to give an assessment of the true state of the current process using the
following mechanism
 High – the gap is significant and needs to be fixed urgently.
 Medium – the gap is moderate but still need to be fixed within a reasonable timeframe.
 Low – the gap is of minimal impact.
14 | P a g e
5.1.2 CHANGE MANAGEMENT CURRENT STATE PROCESS FLOW
5.1.3 CHANGE MANAGEMENT PROCESS ANALYSIS TABLE
Process Step IFDS Change Process Best Leading ITIL Practice Gap/Recommendation Rating
description
1. Create/ Change Owner is Change Requestor/initiator Identified Gap: High
Update responsible for is responsible for creating  No Risk Assessment
Change creating the change the change request in an process in place to identify
Request request and ensures authorized Change the risk of the changes
that the change Management Ticketing tool. being made.
request contains all  Current state ECAB
the required and Normal Production changes discussions are really like
relevant details must be created with change
necessary to allow for sufficient lead time defined planning/scheduling
change Management by the organization to allow discussions, and not about
and all other impacted for change Management to risk level.
stakeholder to properly assess, approve,
15 | P a g e
description
properly access the communicate and schedule
change. changes into Production. Recommendation:
 Have an established Risk
Assessment process in
place and changes must
be categorized based on
the defined risk levels.
2. Submit Change Owner is Change Requestor is Identified Gap: High

Change responsible for responsible for submitting  No adequate process in
submitting the change the change request for place to ensure that
after all the required Analysis & Review within preliminary
and relevant the required lead time. screening/review is done
information has been by CMT as well as to
provided. Once submitted, The ensure that all required
following stages are approvals are obtained
required to be embedded before ECAB weekly
and clearly meeting.
identified/defined in the  No clear list of who the
workflow prior to CAB Change approvers are by
approval change category.
 Pre-planning activities
1. Analyze and Review changes largely doesn’t
Change Request occur ahead of ECAB
2. Authorize for Build meeting.
3. Build Change
4. Technical review of Recommendation:
change (when 1. Ensure all planning
required) activities and required
change approvers are
clearly defined and
embedded within the
workflow prior to ECAB
review/ authorization.
3. Presentati Change Owner If change requires CAB Identified Gap: High

on to presents the change approval. This should be 2. CAB group does not exist
Weekly request at the ECAB reviewed at a sanctioned
ECAB weekly meeting prior CAB Meeting. Recommendation(s):
to scheduling the 3. Constitute a sanitized CAB
change The focus of the CAB review group.
is to purpose of the
proposed changes for risk, 4. Ensure that CAB group
impact, business members constitute all
16 | P a g e
description
significance, scheduling required stakeholders.
conflicts and resource
requirements.
4. Obtain The ECAB approval The CAB approval group Identified Gap(s): High
Formal group decides decides whether or not to  All changes currently get
ECAB whether or not to provide their approval for reviewed by ECAB and not
Approval provide their approval change CAB.
for change
 No clearly defined process
in place for emergency
change as all changes
currently goes through
ECAB
Recommendation(s):
 Clearly define the
difference between CAB
and ECAB i.e. clearly
highlight the roles and
responsibilities
CAB - reviews all Normal

production changes.
ECAB - review Emergency

changes that cannot wait to be
presented and reviewed at the
normal scheduled CAB
Meetings.
 Clearly define the criteria

for emergency change to
avoid unauthorized
changes.
 Clearly identify and outline

the approvers required
and have these approvals
built in the workflow as
much as possible.
5. Schedule The planning of the CAB approved changes are Best ITIL practice not properly High
Change change is made by the scheduled for deployment followed.
Change Owner by Change Management.
17 | P a g e
description
Identified Gap:
Note: If CAB does not  The Planning of the
approve the change, change take place after
Change Requestor/Owner the change has been
can update change record approved by CAB and
with required information already scheduled.
and resubmit for approval.
Note: As per best practice this
planning activity should have
taken place in the earlier stage
prior to CAB meeting and any
scheduling conflict should have
been determined prior to or
during the CAB Meeting.
Recommendation:
 Ensure planning activities
is done and completed in
the early stage prior to
CAB review.
6. Update The Change owner is Once a change request has Identified Gap: Medium
Change responsible for been authorized by CAB  Currently it appears that
Control updating the change and set to schedule by the Change Owner is able
dates and control dates and change management team. to update the change
status status The change record after it’s been
requester/owner should authorized by CAB and
have the ability to update scheduled for change.
the change record at this
point. Based on best practice, the
stage should be locked down
at this point i.e. Change Owner
should not be able to edit the
change record after it’s been
authorized by CAB and
scheduled for change.
To avoid making changes to
already approved change.
Recommendation
 Step to be removed as it
doesn’t seem to add any
value at this point.
7. Implemen The change is Once a change enters this Identified Gap: High
18 | P a g e
description
t Change implemented on the activity, it is authorized as  Post Implementation
approved scheduled required and scheduled for Review currently NOT in
date and time. deployment by Change place or not embedded in
Management the Workflow for
If the change is not Unsuccessful changes.
successful it will be The Change Implementer(s)
backed out using the are responsible for Recommendation:
back out instructions deploying the change as per  Need to have this in place
provided with the the documented for the reasons outlined in
change implementation plan. “ITIL Best practice”
column.
The Change owner ensures
the implementation is
proceeding as planned
If change is successful – can

proceed to close the change
record
Production Changes that

are deemed unsuccessful
are required to go through
post Implementation
review i.e. they must be
reviewed to determine the
cause of failure and
recommend improvements
of actions.
The Change Manager must

ensure this review is
conducted.
8. Close After the change has All successful changes are Identified issue: High
Change been implemented, set to be completed by the  Currently not making use
Record update the actual change implementer and of the notification
start and end dated. closed by the change functionality available
The following points manager or change within the tool.
are then considered. owner/initiator.
 Are there any This Includes identifying an Recommendation:

associated appropriate Closure Code 1. Identify all the notification
incidents tickets that represents the overall types required.
open due to the outcome of the overall
change? change. 2. Identify or define the
19 | P a g e
description
 Did the change trigger points for each
successfully notification required with
address the appropriate recipient.
problem or
business
requirement?
20 | P a g e
5.1.4 INCIDENT MANAGEMENT CURRENT STATE PROCESS FLOW
5.1.5 INCIDENT MANAGEMENT PROCESS ANALYSIS TABLE
Process Step IFDS Incident Process Best ITIL Process description Gap/Recommendation Rating
description
1. Incident Incident is currently This includes the identification Identified Gap: High
Detection/Id being detected and of an incident occurrence, or  Incident Process roles
entification reported through 4 potential incident occurrence. and responsibilities
different channels Incident Identification should not clearly defined and
occur as soon as possible, documented.
1. Event ideally before it has an impact Incident is currently being
Management on Service. This is done reported to and logged by
2. Web Portal through monitoring of key IT Service Delivery Manager.
3. Email/Phone components by event
4. Fax monitoring systems. Recommendation:
 Ensure that roles and
1. Direct end user contact responsibilities are
via phone, email, fax etc. clearly defined and
2. Technical Support staff documented.
3. 3rd Party Vendor or  Ensure that all
21 | P a g e
description
Service incidents are reported
Provider. and logged through
the Service Desk i.e.
establishing the Single
Point of Contact
(SPOC) process.
2. Incident Service Desks logs the Upon validation of an incident Identified Gap High
Logging incident currently occurrence, the service desk  Currently facing some
reported by Phone, agent logs all required and challenges capturing
email of fax and relevant details. complete and accurate
update incident ticket This is essential in recording a information from the
logged by client full historical account of the incident reporters
through web portal incident and made available to
with any additional those support groups who Recommendation
information required may be assigned to resolve the  Ensure that all
incident. required and detailed
information are
captured and logged in
the incident ticket for
accurate
classification/categoriz
ation.
This might result into

identifying and introducing
additional fields.
3. Incident Service Desk Incident classification is very Identified Gap: High
Categorizatio populates the important to understand the  No proper incident
n category, subcategory source of all your incidents. categorization process
and CI field(s) in the Three levels of categorization - in place, even though
attempt to categorize Category, Subcategory and the three levels of
the incident. Item allows more categorization
organization. The incidents currently exist, proper
Note: can be assigned to these data mapping of the
No clearly defined categories depending upon category, sub category
process in place. the issue that is reported and and CI with the
can be automatically routed to Assignment Group is
the appropriate support currently not in place.
engineer.
Note: This would require
some clean up.
Recommendation:
 Need to ensure that
22 | P a g e
description
accurate data is
provided in the above
mentioned fields.
Importance of proper
incident categorization:
1. Routing to the
appropriate resolver
group.
2. Meaningful
management
information can be
obtained.
3. Performance Metrics.
4. Also used to support
other Service
Management
processes such as
Problem,
Configuration, Asset
and Change
management.
4. Incident Service Desk agent The Incident can affect the Identified Gap: High
Prioritization selects the Impact and organization differently.  Currently not using the
Urgency of the Define the Priority based on SLA and SLO
incident in the the Impact and Urgency of the functionality within
attempt to determine Incident. It minimizes the tool – SLAs are
the priority of the incident impact on the monitored outside the
incident. business. Assigns the priorities tool which
based on Predefined significantly defeats
Note: prioritization or Dynamic the purpose of having
No clearly defined prioritization. SLOs and turns the
process in place. actual SLOs to ad-hoc
 Prioritization process SLOs
defined but not
adhered to.  Prioritization process
 Response and/or defined but not
Resolution time not adhered to.
current within “IFDS 
Service Management
Manual”. Recommendation(s):
 Incident Closure  Define SLAs for each
accomplished priority levels and
23 | P a g e
description
through email with ensure this is enforced
client. through the tool.
 Set expected
resolution time for
each priority levels.
 Proper escalation
process to be defined
for the different
priority levels when
SLA is breached.
This would help to get rid

of the Ranking functionality
currently in place.
5. Initial No clearly defined Incident must be diagnosed. Identified Gap: High
Diagnosis process in place. This entails gaining an  The incident
understanding of the full management module
extent and symptoms of the is currently not linked
incident, so that the Service to Knowledge
desk agent can make every management.
attempt to resolve the call
without having to escalate for  Limited resources
resolution. available for Service
Desk to resolve issues
The Service Desk agent should on first contact. Tools
use all knowledge, tools, including Knowledge
and/or Known error base, Known Errors
Information available to them database or
in support of an early and diagnostics tools to
accurate diagnosis assist with incident
diagnostic are lacking.
Recommendation(s):
 The current
Knowledge
management module
needs to be reviewed
and subsequently
linked to the Incident
Management module
to ensure required
information is
24 | P a g e
description
available to Service
Desk teams to support
early and accurate
diagnosis.
 Ensure that Service

Desk have all the
tool/resources
required to do proper
and accurate
diagnosis.
6. Incident An incident is assigned As soon as the Service Desk Identified issue: High
Escalation to Level 2 support if agent determines that they  After 48 hours,
workaround is are not able to resolve the unresolved application
unavailable and agent incident or incident resolution related incidents will
is unable to resolve time frames have exceeded result in a problem
the incident. for first call resolution, ticket being opened
escalation for further support without any proper
All unresolved is required. Service Desk agent
investigation of
application related must ensure that the incident
whether it should
incidents will result in record is updated to reflect all
a problem ticket after activities performed to become a problem or
48 hrs. attempt resolution. not. A bypass may or
may not be available
Note: The incident is assigned to the at this stage
No clearly defined appropriate Level 2 Support  Second and third level
process in place. Group for continuation of support groups have
incident resolution activities. inconsistent
Incident escalation may management of their
continue to Level 3 support, incident queues.
should the level 2 support lack
the knowledge to resolve the
 No clearly defined
incident.
escalation process in
place.
Recommendation:
 Ensure proper
escalation process is in
place to ensure that
incident is routed to
the appropriate Level
2 Support group when
the Service Desk
25 | P a g e
description
cannot resolve an
incident.
 All tickets assigned to

Level 2 support group
should be investigated
and diagnosed to
determine if incident
needs to be converted
to a problem or not.
 Not recommended to
change incident tickets
to a problem without
any proper
investigation.
7. Incident Level 2 Support agent Investigation activities include Identified issue: High
Investigation investigates the determination of what went  No adequate
& Diagnosis incident with the wrong, or what the client/end tool/resources in place
attempt of resolving users is requesting and to ensure that
the incident, if still determine full impact of the accurate
unable to incident. incident by using aids such as: investigation/diagnosis
Ticket should be of the incident are
further escalated to 1. Reviewing recently carried out.
Level 3 support group. implemented changes
2. Use of diagnostic tools Recommendation:
3. Use of remote control 1. Ensure that
diagnosis tools appropriate tool is
4. Perform Incident made available to all
matching support groups (Level
5. Check problem database 1-3) to ensure proper
6. Check 3rd party knowledge and accurate incident
information investigation/diagnosis
7. Run books is carried out.
8. Resolution Service Desk Analyst Once a possible resolution has Identified Gap: High
and Recovery resolves the incident been determined, the  Response and/or
when resolution for resolution should be applied Resolution time not
the incident has been and tested to ensure that the current within IFDS
determined and service has been fully Incident management
applied. restored. process.
The incident record must be Recommendation:

updated by the resolving  Define expected
assignee group(s) to response/resolution
26 | P a g e
description
thoroughly outline all actions time for each priority
taken, and their corresponding levels.
result.
9. Closure Service Desk Analyst Once the incident has been Identified Gap: High
closes the incident resolved, the incident  Currently not making
ticket once the owner/resolver is responsible use of the notification
incident has been for ensuring the following functionality available
resolved and a closure requirements are met: within the tool.
confirmation has been
received from the  Confirmation from the Recommendation(s):
client/end users client/end user that the  Identify all the
regarding incident incident has been fully notification types
resolution. restored to their required.
satisfaction  Identify or define the
 Ensure incident data trigger points for each
quality and completeness notification required
and that the with appropriate
categorization aligns with recipient.
the actual
27 | P a g e
5.1.7 PROBLEM MANAGEMENT CURRENT STATE PROCESS FLOW
5.1.8 PROBLEM MANAGEMENT CURRENT STATE ANALYSIS
Process Step IFDS Problem Process Best Leading Process Gap/Recommendation Rating
description description
1. Problem  After 48 hours,  Upon Suspicion or Identified Gap: High
Detection unresolved detection of one or more
application incidents by a cause, the  Problem management
related incidents Service Desk raises a process which is
will result in a Problem Record – Service consistent with ITIL
problem ticket Desk may have resolved not in place.
being opened. A the incident but has not
bypass may or determined a definitive Recommendation(s):
may not be cause and suspects that it  Need to establish a
available at this is likely to recur. problem management
stage.  Analysis of an incident by process that is
a technical support group consistent with ITIL
which reveals that an best practice.
underlying problem exists,
or is likely to exist.
 Automated detection of
an infrastructure or
28 | P a g e
application fault, using
event/alert tools
automatically to raise an
incident which may reveal
the need for a Problem
Record.
 A notification from a
supplier or contractor that
a problem exists that has
to be resolved.
 Analysis of incidents as
part of proactive Problem
Management: watch-
bulletins, releases,
relevant papers
2. Problem No clearly defined All the relevant details of the Identified Gap: High
Logging process in place. problem must be recorded so  Clearly defined
that a full historic record problem logging
exists. This must be date and process NOT in place.
time stamped to allow suitable
control and escalation. A Recommendation(s):
cross-reference must be made  Need to have a well-
to the incident(s) which defined problem
initiated the "Problem investigation and
Record": diagnosis process in
place.
 User details  Ensure defined process
 Service details is adhere to.
 Equipment details  Ensure all the required
 Date/time initially logged information needed
 Priority and categorization for proper problem
details routing,
 Incident description categorization,
 Details for all diagnostic prioritization etc. is
or attempted recovery logged in the problem
actions taken. record.
3. Problem No clearly defined Problems must be categorized Identified Gap: High

Categorizatio process in place. (severity/priority) in the same  Clearly defined
n way as incidents in order to problem
trace a problem. Prioritize a categorization process
problem implies to keep into NOT in place.
account the impact of the
incidents and the frequency of Recommendation(s):
29 | P a g e
the occurrences. Problem  Need to have a well-
prioritization should take into defined problem
account the severity of the categorization process
problems. From an in place.
infrastructure point of view  Ensure defined process
we can have: is adhere to
 Ensure all the required
 Can the system be information needed
recovered, or does it need for proper problem
to be replaced? categorization is
 How much will it cost? logged in the problem
 How many people will be record.
involved to fix the
problem?
 How long will it take to fix
the problem?
 How many additional
resources will be
involved?
4. Problem No clearly defined All problems must be assigned Identified Gap: High
Prioritization process in place. a risk rating which must align  Clearly defined
to an established risk matrix. problem prioritization
After the overall problem risk process NOT in place.
is established, all associated
problem tasks also need to be Recommendation(s):
assigned a risk rating based on  Need to have a well-
an established risk matrix. defined problem
prioritization process
in place.
 Ensure defined process
is adhere to
 Need to have clearly
defined matrix in place
for problem
categorization/prioritiz
ation.
5. Investigation No clearly defined Problem investigation results Identified Gap: High

and Diagnosis process in place. in getting at the root cause of  Clearly defined
the problem and initiating problem Investigation
actions to resume the failed and Diagnosis process
30 | P a g e
service. Analyze the impact, NOT in place.
root cause and symptoms of
the problem to provide a Recommendation(s):
problem resolution. Make an  Need to have a well-
announcement with the defined problem
problem symptoms to avoid investigation and
the creation of multiple diagnosis process in
incidents. place.
 Ensure defined process
is adhere to
 Ensure all the required
information needed
for proper problem
categorization is
logged in the problem
record.
6. Problem No clearly defined All Problems must be resolved Identified Gap: High
Resolution process in place. and/or mitigated through the Clearly defined Problem
creation and deployment of a Resolution process NOT in
remediation plan which place.
includes appropriate
corrective actions or Recommendation(s):
workaround.  Need to have a well-
defined problem
Known Errors are created and investigation and
associated with Problem diagnosis process in
Record. The Known error will place i.e. clearly define
include a short description of the activities that
the problem, problem state, takes place and the
the root cause description and individuals responsible
the workaround if available. for carrying out the
Once a solution is identified activities.
and tasks are completed in the  Ensure defined process
problem record, the known is adhere to
error record is updated  Need to clearly define
accordingly. and identify resolution
activities.
7. Closure No clearly defined All problem record must be Identified Gap: High
process in place. closed as soon as confirmation  No clear closure
of problem been received activities/process in
from the end user and data place
quality has been validated.
Recommendation(s)
Problem closure is very critical  Need to put a proper
31 | P a g e
as closure confirms that all closure process in
aspects of the user problems place.
are addressed to the user  Need to clearly define
satisfaction. Service Desk and identify closure
helps to ensure that all the activities.
associated incidents are closed
with a proper fix or resolution Examples of closure
to the failure reported using activities:
the Problem closure rules.  The problem
reporter/initiator
confirms that:
1. The problem
has been
fixed.
2. The Service
has not been
disrupted as a
result of the
fix.
 The problem
reporter/initiator
validates problem
record data, known
error and ensures that
the resolver has made
the appropriate
updates where
necessary.
 The problem owner
ensures that the
known error and
problem record is
closed after the
validation.
32 | P a g e
5.1.9 RELEASE MANAGEMENT CURRENT STATE PROCESS FLOW
5.1.10 RELEASE MANAGEMENT CURRENT STATE ANALYSIS
Process Step IFDS Release Process Best Leading Process Gap/Recommendation Rating
1. Plan Release No clearly defined Process Objective: To assign Identified Gap: High
release planning authorized Changes to Release
process in place. Packages and to define the  Release management
scope and content of Releases. process which is
Based on this information, the consistent with ITIL
Release Planning process not in place.
develops a schedule for
building, testing and deploying Recommendation(s):
the Release.  Need to establish a
Release management
process that is
consistent with ITIL
best practice.
 Need to clearly define

release planning
activities.
33 | P a g e
2. Build Release No clearly defined Process Objective: To issue all Identified Gap: High
release building necessary Work Orders and
process in place. Purchase Requests so that  Clearly defined
Release components are release building
bought from outside vendors process NOT in place.
or developed/ customized in-
house. At the end of this Recommendation(s):
process, all required Release  Need to clearly define
components are ready to release building
enter the testing phase. activities.
3. Test User No clearly defined Process Objective: To ensure Identified Gap: High
Acceptance release testing process ITIL guided process that
in place. includes optional paths to  Clearly defined
provide small or large-scale release testing
piloting of the application to process NOT in place.
ensure that your roll out goes
smoothly. An option is also
provided for no piloting when Recommendation(s):
required.  Need to clearly define
release test user
acceptance activities.
4. Prepare No clearly defined Process Objective: To ensure Identified Gap: High
Release release preparation every task for release
process in place. preparation is included here:  Clearly defined
Assembling resources, release preparation
communications plan for process NOT in place.
release to users, training sub-
process for supporting staff, Recommendation(s):
scheduling support for the  Need to clearly define
deployment and completing a release preparation
readiness review. activities.
5. Deployment No clearly defined Process Objective: To deploy Identified Gap: High

release deployment the Release components into
process in place. the live production  Clearly defined
environment. This process is release deployment
also responsible for training process NOT in place.
end-users and operating staff
and circulating information/ Recommendation(s):
documentation on the newly  Need to clearly define
deployed Release or the release deployment
services it supports. activities.
34 | P a g e
6. Review and No clearly defined Process Objective: To formally Identified Gap: High
Close release review and close a Release after verifying
closure process in if activity logs and CMS  Clearly defined
place. contents are up to date. release closure
process NOT in place.
Recommendation(s):
 Need to clearly define
release closure
activities.
35 | P a g e
5.3 Detailed Process Recommendations
5.3.1 CHANGE MANAGEMENT PROCESS RECOMMENDATIONS
Following recommendations are provided based on ITIL best practice and directly mapped to the gaps
identified in the Change Management Process Analysis Table above.
Process Step Recommendation Rating

1. Create/ 1. Have a risk assessment process in place and all changes must be categorized High
Update based on the defined risk levels.
Change 2. Clearly define and document change management roles and responsibilities.
Request
2. Submit 1. Ensure all planning activities and required change approvers as listed below are High
Change clearly defined and embedded within the workflow prior to CAB review/
authorization.
 Analyze and Review Change Request

 Authorize for Build
 Build Change
 Technical review of change (when required)
3. Presentation 1. Constitute a sanitized CAB group and ensure CAB members consist of all High
to Weekly required stakeholders.
ECAB 2. Clearly outline the difference between CAB and ECAB i.e. highlight the roles
and responsibilities of each group.
4. Obtain 1. Clearly define the criteria for emergency change to guide against any High
Formal ECAB unauthorized changes.
Approval 3. 2. Identify and outline all the approvers required for emergency change and have
these approvals defined in the workflow.
5. Schedule 1. Ensure planning activities is done and completed in the early stage prior to CAB High
Change review.
6. Update 1. Recommending removing step and embedding step in the earlier stage. High
Change
Control dates Note:
and status Once a change request has been authorized by CAB and set to schedule by
change management team. The change requester/owner should NOT have the
ability to update the change record at this point.
7. Implement 1. Post Implementation Review should be included as one of stages within change High
36 | P a g e

Change management process and should embedded in the Workflow for unsuccessful
changes to determine cause of failure and recommendations for improvements
actions.
8. Close change 1. Identify all the notification types required and have the notification generated High
record within the tool.
2. Identify and define the trigger points for each notification required with
appropriate recipient.
Note:
 Notification is not limited to this phase only but applies to phases of change
management process.
5.3.2 INCIDENT MANAGEMENT PROCESS RECOMENDATIONS
The following recommendations are provided based on ITIL best practice and directly mapped to the
gaps identified in the Incident Management Process Analysis Table above.

1. Incident 1. Ensure that proper channels of reporting incident is clearly defined and High
Detection documented.
2. Ensure that all incidents are reported and logged through the Service Desk i.e.
establishing the Single Point of Contact (SPOC) process.
2. Incident 1. Ensure that all required and detailed information are captured and logged in High
Identification the incident ticket for accurate classification/categorization.
/Logging
3. Incident 1. Recommend to have more organized process in place with the three levels of High
Categorizatio categorization - Category, Subcategory and Item. The incidents can be assigned
n to these categories depending upon the failure that is reported and can be
automatically routed to the appropriate support group.
Importance of proper incident categorization:

 Routing to the appropriate resolver group.
 Meaningful management information can be obtained.
 Performance Metrics.
 Also used to support other Service Management processes such as
Problem, Configuration, Asset and Change management.
4. Incident 1. Define SLAs for each priority levels and ensure this is enforced through the High
Prioritization tool.
2. Set expected resolution time for each priority levels.
37 | P a g e

3. Proper escalation process to be defined for the different priority levels when
SLA is breached.
5. Initial 1. Current Knowledge management module to be reviewed and subsequently High

Diagnosis linked to the Incident Management module to ensure required information is
available to Service Desk team to support early and effective incident diagnosis.
2. Ensure that Service Desk have all the tool/resources required to do proper and
accurate diagnosis.
6. Incident 1. Ensure proper escalation process is in place to ensure that incident is routed to High
Escalation the appropriate Level 2 Support group when an incident cannot be resolved by
Service Desk.
2. All tickets assigned to Level 2 support group should be investigated and
diagnosed to determine if incident needs to be converted to a problem or not.
7. Incident 2. Ensure that appropriate tool is made available to all support groups (Level 1-3) High
Investigation to ensure proper and accurate incident investigation/diagnosis is carried out.
& Diagnosis
8. Resolution 1. Define expected response/resolution time for each priority levels. High
and Recovery
9. Incident 1. Identify all the notification types required and have the notification generated High
Closure within the tool.
2. Identify and define the trigger points for each notification required with
appropriate recipient.
Note:
Notification is not limited to the closure phase only but applies to phases of
incident management process.
38 | P a g e
6 Appendix B: Detailed Technical Analysis
6.1 Detailed Technical Observations
As part of the Assessment for IFDS, especially to the Technical components of the ServiceNow platform
and its implementation, INNOMENTUM has divided the evaluation into two components:
1. Technical Evaluation of the system platform, as it relates to the implementation of the

processes, scripts and configuration as it relates to the platform and the “Application” itself.
2. Technical Evaluation of the platform as it is involved in the IFDS overall technical ecosystem and
how it interacts and behaves with in and out bound systems.
6.1.1 HIGH-LEVEL TECHNICAL ARCHITECTURE
The following diagram illustrates the High Level Technical Architecture of IFDS at this time. The
Corporate Data Warehouse (CDW) in this case is the Organizations single source of truth and the
ServiceNow instance is main the point of interest. Between these two points all major data elements are
either being pulled or pushed.
*The CDW feeds several critical field level details into ServiceNow and receives essential details from ServiceNow for billing purposes.
39 | P a g e
6.1.2 INSTANCE REVIEW (ACE REPORT)
The following is part of a report that is generated via a Technical Interrogation technique available to
ServiceNow and ServiceNow partners gives you specific details on whether the current implementation
violates or adheres to ServiceNow Technical Best Practices.
Automated Configuration Evaluator (ACE) gives you best practices for configuration and indicates where
those are not followed in the instance. Results of the ACE scan are provided within the Supporting
Artifacts section of the document. This report identifies an evaluation of the risk factors, reducing post
go-live incidents, to help applications perform optimally.
40 | P a g e
The Following definitions detected a few conflicts with the known best technical practices from
ServiceNow:
6.1.2.1 Platform Best Practices: Overall Summary
6.1.3 DATA STRUCTURE
Analysis of the Data Structure was done through looking at the table schema maps as well as the ERwin
Entity Relationship Diagram provided.
 The procedures followed to export data from source systems to SNC are following data best
practices. Export of data from the SNC system to CDW is also following data best practices.
No major issues were noted.
 Utilization of Data Import Sets for loading data into SNC is considered the best approach
with ServiceNow and ensures proper table relationship and overall data integrity.
 The data interface points and update sets being utilized are following standard procedures
both from a data perspective and an SNC prospective.
 Field naming convention followed to indicate user fields is also a best practice.
 There we no issues noted related to data integration.
 The data model is included in the appendix of this document.
41 | P a g e
6.1.4 INCIDENT MODULE REVIEW
The Incident Module has minor issues judging from a technical assessment, these issues stray away from
best practices and is identified below.
6.1.4.1 Client Scripting
Standard out of the box setup, the use of Client scripting for field level security strays away from best
practices. No such issue found within the Incident module
6.1.4.2 User Interface
Some fields have an unknown purpose judging from the way they are currently being used.
 Task History: Not Standard currently has an unknown and undefined purpose within this
modules however there is a better way to utilize this field as a whole.
 Products: Unclear or incorrect use of field. Product field currently allows the creation of a
product from incident form.
42 | P a g e
* ‘Task History’ is an undefined field. The use of ‘Products’ within the forms is used to create a
‘product’ from within the form rather than relating to an existing product.
6.1.4.3 Workflow
Standard out of the box, no issues with workflows as it relates to the Incident module.
6.1.5 CHANGE MODULE REVIEW
The Change Module has issues judging from a technical assessment, these issues stray away from best
practices and is identified below:
Currently within the forms there is use of Client scripting to enforce read-only security on certain fields.
The use of an ‘Admin’ button (UI action) is employed for some fields to be unlocked for editing via
client_script. Currently within change some fields are read only.
* Admin Button on the top right turns read-only on select fields off.
43 | P a g e
* Example of select fields within the Change form that are locked down
* A user without change management role can edit fields that are meant to be read-only.
44 | P a g e
Some Fields within the forms have incorrect values. In addition some fields have an unknown purpose
judging from the way they are currently being used. A good example the above statement is depicted
below:
 Task History: Not Standard currently has an unknown and undefined purpose within this module
however there is a better way to utilize this field as a whole.
 Review Status: Field currently has incorrect values.
* ‘Task History’ and ‘Review status’ are the focus of the above image. ‘Task History’ currently has
an undefined function and does not relate to any other tasks and ‘Review Status’ currently holds
incorrect values.
45 | P a g e
6.1.5.5 Workflow
Workflows are currently individually created rather than employing the use of sub flows. This route of
individual workflows results in a large number of individual flows, which could pose an issue from a
maintenance perspective.
*Example of the number of individual workflows
6.1.6 PROBLEM MODULE REVIEW
The Problem Module has minor issues judging from a technical assessment, these issues stray away
from best practices and is identified below.
practices. No such issue found within the Problem module
46 | P a g e
Some fields may be better utilized which will affect the use of those fields within other modules. An
example of this is for the field ‘Task History’
 Task History: Not Standard currently has an unknown and undefined purpose within other
modules however there is a better way to utilize this field as a whole as it is functional within
this module.
 Task Type: This field is currently on the form.
 Active Field: This field is currently on the form.
 State/Problem State: There is use of two fields that
* ‘Task History’, ‘Task Type’ and ‘Active’ fields standout as possible issues within this form. The use of
‘state’ is duplicated with another field ‘Problem state’.
47 | P a g e
6.1.6.3 Workflow
Standard out of the box, no issues with workflows as it relates to the Problem module.
6.1.7 RELEASE MODULE REVIEW
The Release Module has minor issues associated with its implementation. These issues are identified
below.
practices. No such issue found within the Release module
The Release numbering does not seem to be following a consistent order. Possible issue due to the use
of module at a more ad-hoc level but no major issues found.
6.1.7.3 Workflow
Standard out of the box, no issues with workflows as it relates to the Release module.
48 | P a g e
6.3 Detailed Technical Recommendations
These following recommendations are provided based on the Technical best practice from ServiceNow
and Innomentum.
6.3.1 MULTIFACTOR FACTOR SECURITY RECOMMENDATIONS
Single factor authentication provides a low barrier of security as compared to Multifactor

Authentication. If a user ID and password are compromised, there's no secondary challenge to
the authentication process. To elevate the security barrier it is recommended that Multifactor
Login be implemented.
MULTI FACTOR IDENTITY

EXTERNAL
USER SERVICE-NOW.COM AUTHENTICATION PROVIDER/ACTIVE
DEVICE
SERVER DIRECTORY
1 CHECK CREDENTIALS OF USER

2
ACCOUNT
3
RESPOND WITH CREDENTIALS

PACKAGE
REQUEST SECOND FACTOR THROUGH AUTHENTICATION SERVICE 4
5
SECOND FACTOR CREDENTIALS

6
AUTHENTICATION PACKAGE
7
USER SUCCESSFULLY LOGS IN
8
In this flow you run a Multi Factor Authentication Server close to your Identity Provider (Active
Directory). The Multifactor Server will be coupled with a Multifactor Service. When a user wants
to access instance.servicenow.com:
1. The application connects to the Identity Provider to offload authentication and to make sure
the user account that was used is, in fact, authorized for the application.
2. Instead of talking to Active Directory directly, ServiceNow will talk to the Multi-Factor
Authentication Server installation.
3. This installation checks the credentials for the user account with Active Directory.
49 | P a g e
4. Active Directory responds with a Package.

5. When this is successful, the Multi-Factor Authentication Server requests the second factor
through the Multi-Factor Authentication Service.
6. This service will contact an external device (i.e. phone device or a Key fob).
7. When this is successful, the Multi-Factor Authentication Server installation passes the
authentication package to the application for authorization and further use.
8.
6.3.2 INCIDENT MODULE TECHNICAL RECOMENDATIONS
 Task History: This field is not a standard and was added during the implementation as a custom
field. The business requirements of the field were not clear and the perceived intended
objective of capturing “history” is not a recommended UI approach by ServiceNow.
The recommended approach is to leverage the “many to many task relations” plugin, which is a feature
available within ServiceNow.
http://wiki.servicenow.com/index.php?title=Many_to_Many_Task_Relations
ServiceNow by default allows tasks to be related using a parent/child relationship, such as a problem
with a group of child incidents. However, to record the relationship between the tasks record, the
“Many to Many Task Relationship” plugin needs to be activated. It allows the admin to define
relationships between the different tasks.
When the plugin is activated, the Task Relationships application allows relationships, for example with
incidents:
50 | P a g e
 Products: Unclear or incorrect use of field. Product field currently allows the creation of a
product from incident form.
Depending on the requirements of this field, a related list would provide more optimal way to relate
products. The function would then be to relate existing products to an incident and avoid creating
products from the incident form.
Use of “Related Lists” is a ServiceNow best practice:
http://wiki.servicenow.com/index.php?title=Using_Related_Lists
A “Related List” display records in another table that have a relationship to the current record. Users
can view and modify information in related lists using standard list controls. Administrators can
configure related lists to appear on forms and in hierarchical lists.
51 | P a g e
6.3.3 CHANGE MODULE TECHNICAL RECOMENDATIONS
6.3.3.1 Removing Client scripting for access control list (ACL):
ServiceNow utilizes ACL rules to control what data users can access and how they can access it. Users who
pass the user role requirement of an ACL rule gain access to the protected object, such as a table, field, or
database operation.
The recommended approach and best practice by ServiceNow is to leverage ACL’s. Therefore it is
recommended to remove all use of client scripts as the list view does not enforce them. If no action is taken
then the “read only” security that was implemented within the client scripts will only take effect on detail
views and not list views.
6.3.3.2 Form Fields:
Some Fields within the forms have incorrect values. In addition some fields have an unknown purpose
judging from the way they are currently being used. A good example the above statement is depicted
below:
o The recommended approach is to leverage the “many to many task relations” plugin,
which is a feature available within ServiceNow.
o http://wiki.servicenow.com/index.php?title=Many_to_Many_Task_Relations
 Review Status: Field currently has incorrect values.
 Workflows are currently individually created rather than employing the use of sub flows. This
route of individual workflows results in a large number of individual flows, which could pose an
issue from a maintenance perspective. Once the process is standardized the use of sub flows can
be utilized:
o Sub flows will allow flexibility for process variations as well reduce maintenance of
workflows.
52 | P a g e
6.3.4 PROBLEM MODULE TECHNICAL RECOMENDATIONS
Some Fields may be better utilized which will affect the use of those fields within other modules. An
example of this is for the field ‘Task History’
o The recommended approach is to leverage the “many to many task relations” plugin,
which is a feature available within ServiceNow.
o http://wiki.servicenow.com/index.php?title=Many_to_Many_Task_Relations
 Task Type: This field is currently on the form. Possibly a redundant field.
 Active Field: Recommended to remove field from form.
 State/Problem State: Currently two fields are indicating state on the form. One field should be
used.
6.3.5 RELEASE MODULE TECHNICAL RECOMENDATIONS
Currently the Release Module is at an Ad-hoc level. Once the process is standardized, a solution will be
configured in accordance with the best technical practice.
6.3.6 OLD PROCESS TO NEW PROCESS TECHNICAL RECOMENDATIONS
Depending on the decision of the business the following guidelines should ensure least disruption from a
technical standpoint:
If the old process and new process need to coexist for a period of time the use of views, UI Policies or a
combination of the two can be utilized. After the cloning process that ensures production and sub
instances are in sync:
 Establish a plan for records impacted by the new process

o Reporting Impacts
o Impacts to form usability for old records (new required fields, missing fields)
53 | P a g e
o If using views, create a copy of the existing view and a rule to put users into an old view
during the build of the new process
 This allows changes to be made throughout development to the old view
without impacting the new view
o If using UI Policies and the same view, then establish when to show/hide new/old fields
 This could cause issues if changes are needed to the existing view prior to
implementation of the new process
o If using a hybrid of the two you will still create separate views, but you will also
implement UI Policies on the new view to handle old records. Upon deployment you
can then disable the old view.
 This provides the best of both worlds if they need to work both processes
54 | P a g e
7 Appendix C: Supporting Artifacts
The following are all documents/artifacts received by INNOMENTUM on the ServiceNow

Change/Incident Management Project from various IFDS groups/SMEs in order to understand the
current state.
Artifact Artifact Name/Description Document(s)

Number
1 Change Management Policies and Procedure document
Change Management
Policies and Procedures.doc
2 Fire Fight ID Policy document

Fire Fight ID (FFID)
Policy.doc
3 ServiceNow Change Management Guideline – What information

is required in a Comprehensive change.
ServiceNow_Guidelin
e_What information is required in a Comprehensive
4 ServiceNow Quick Reference Card on how to create a change

request. – Category: Client Software & Type: Comprehensive.
ServiceNow_QuickRe
fCard_How to create a Change Request - Compreh

request. - Category: Client Software & Type: Emergency.
ServiceNow_QuickRe
fCard_How to create a Change Request - Emergen

request. - Category: Client Software & Type: Emergency.
ServiceNow_QuickRe
fCard_How to create Approvals in a Change Reque
7 IFDS Process Improvement Project - Current State Assessment.

IFDS Process
Improvement Project - Current State Assessment -
8 Service Management Overview.

Service Management
Overview.pptx
55 | P a g e
9 ServiceNow Client Experience Booklet.

ServiceNow Client
Experience Booklet.docx
10 ServiceNow Quick Reference Card – How to create ECAB

Presentation change record.
ServiceNow_QuickRe
fCard_eCAB Presentation.docx
11 ServiceNow Quick Reference Card – How to create Routine and

Comprehensive change record.
ServiceNow_QuickRe
fCard_How to create a Change Record.docx
12 IFDS ServiceNow DM – ERwin Diagram
IFDS DM.PDF
13 Automated Configuration Evaluation (ACE) report for IFDS
ACE report for IFDS
14 Many to Many Task Relations Wiki http://wiki.servicenow.c

om/index.php?title=Man
y_to_Many_Task_Relati
ons
15 Related Lists Wiki http://wiki.servicenow.c
om/index.php?title=Usin
g_Related_Lists
16 Sub flows Wiki http://wiki.servicenow.c
om/index.php?title=Usin
g_Subflows
56 | P a g e

Current State (As-Is) Assessment - IfDS (Published 2014-04-14)

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Current State (As-Is) Assessment - IfDS (Published 2014-04-14)

Caricato da

Copyright:

Formati disponibili

CURRENT STATE ANALYSIS &

Document Version History:

Version Revision Summary of Changes Modified by

1.0 2015-04-13 Version 1.0 document published to IFDS. Chris Rutherford

Adesola Falobi Business Process Consultant

6.3.1 Multifactor Factor Security Recommendations ..................................................................... 49

1.1 Purpose and Scope

The scope of the assessment included:

1.2 Analysis Approach

The approach of the assessment consisted of:

The analysis focused on the following areas:

The following is a summary of Innomentum's key observations and associated recommendations:

During technical analysis, the following was observed:

# Observation Priority to Recommendation

# Observation Priority to Recommendation

During operational analysis the following was observed:

# Observation Priority to Recommendation

# Observation Priority to Recommendation

During process analysis, the following was observed:

3.1 Technical Observations

# Description Risk Level Risk Explanation

# Description Risk Level Risk Explanation

3.2 Operational Observations

# Description Risk Level Risk Explanation

3.3 Process Observations

# Process Reviewed Risk Level Risk Explanation

4.1 Approach to Identify Recommendations

4.2 Prioritized Recommendations

# Recommendation Priority Related Risks Mitigated

REC-07 Purchase additional instances of ServiceNow to move Medium OBS-07 Quality

REC-08 Shore up missing or incomplete documentation. A Medium OBS-08 Maintainability,

5 Appendix A: Detailed Process Analysis

5.1 Detailed Process Observations

5.1.1 ANALYSIS APPROACH

Below is the structure of the analysis table:

5.1.2 CHANGE MANAGEMENT CURRENT STATE PROCESS FLOW

5.1.3 CHANGE MANAGEMENT PROCESS ANALYSIS TABLE

2. Submit Change Owner is Change Requestor is Identified Gap: High

3. Presentati Change Owner If change requires CAB Identified Gap: High

CAB - reviews all Normal

ECAB - review Emergency

 Clearly define the criteria

 Clearly identify and outline

If change is successful – can

Production Changes that

The Change Manager must

 Are there any This Includes identifying an Recommendation:

5.1.4 INCIDENT MANAGEMENT CURRENT STATE PROCESS FLOW

5.1.5 INCIDENT MANAGEMENT PROCESS ANALYSIS TABLE

This might result into

This would help to get rid

 Ensure that Service

 All tickets assigned to

The incident record must be Recommendation:

5.1.7 PROBLEM MANAGEMENT CURRENT STATE PROCESS FLOW

5.1.8 PROBLEM MANAGEMENT CURRENT STATE ANALYSIS

3. Problem No clearly defined Problems must be categorized Identified Gap: High

5. Investigation No clearly defined Problem investigation results Identified Gap: High

5.1.9 RELEASE MANAGEMENT CURRENT STATE PROCESS FLOW

5.1.10 RELEASE MANAGEMENT CURRENT STATE ANALYSIS

 Need to clearly define

5. Deployment No clearly defined Process Objective: To deploy Identified Gap: High

5.3 Detailed Process Recommendations