MORE

Define explicit business case guidelines for customization

Clear, validated business requirements are at the heart of business‑smart customization. Use an explicit statement of business objectives, an understanding of ServiceNow functionality at a “desk level,” and simple scoring mechanisms to evaluate and prioritize demands for customization.

Key insights

  • Guidelines for business‑smart customization should be defined first by your “North Star”:  the business objectives and value you’re trying to capture with ServiceNow.
  • Use interviews to discover whether or not customization is required to deliver these objectives at the “desk level” of the individual user.

Customization

Customization refers to business demands for custom functionality. When referring to implementation, this guide will refer to both configuration and custom development (both on ServiceNow applications and new applications).

Configuration

Configuration includes capabilities and/or features on the ServiceNow platform that enable

organizations to deliver against “custom” business demands, in a safe and supported way (such as modifications to forms or table extensions). While organizations should avoid overconfiguration—for example, by adding excessive forms or UI policies—they should still use configuration as a first or preferred option to meeting business demands.

Custom development

Custom development includes custom development on both ServiceNow applications as well as the development of new applications, by changing baseline business rules or developing new applications from table extensions. Custom development is recommended only where configuration cannot meet business demands, and should employ recommended tools and methods (outlined in Step 3 of this document) as well as be supported by clear governance.

Configuration Item (CI)
A CI is one of the most important components of your CMDB. It’s simply an application, infrastructure, or service component you’re managing. It can be a physical server, an app running on a virtual server, or a business service.

Configuration Item (CI)
A CI is one of the most important components of your CMDB. It’s simply an application, infrastructure, or service component you’re managing. It can be a physical server, an app running on a virtual server, or a business service.

Business‑smart customization comes down to one simple equation: Does customization deliver business value that is greater or less than the cost required to maintain it?

Begin by going back to your original business objectives and use cases before you evaluate specific configurations and custom applications. Then answer these two questions:

 

  1. What business objectives and value are we trying to capture with ServiceNow?

    Demands and use cases for customization should be tied to relevant business objectives and desired business outcomes from the Now Platform. To answer this question, engage the executive sponsor and/ or key IT and business process owners to define and prioritize the business objectives and associated value metrics for your ServiceNow implementation.

  2. How is ServiceNow working today at a desk level?

    Now Platform owners should invest the time and resources necessary to understand the workflows of users—especially service fulfillers like service desk personnel, who use ServiceNow to carry out their daily work—to determine where customization can help and where older customization is getting in the way or not functioning as intended. Conduct interviews (either one on one or through focus groups) with process owners and a sample of service consumers, fulfillers, and developers. Interviews should help you understand where customization can improve workflow and adoption, and where it isn’t necessary. Use our sample interview template to get started.

Customization

Customization refers to business demands for custom functionality. When referring to implementation, this guide will refer to both configuration and custom development (both on ServiceNow applications and new applications).

 

Configuration

Configuration includes capabilities and/or features on the ServiceNow platform that enable

organizations to deliver against “custom” business demands, in a safe and supported way (such as modifications to forms or table extensions). While organizations should avoid overconfiguration—for example, by adding excessive forms or UI policies—they should still use configuration as a first or preferred option to meeting business demands.

Custom development

Custom development includes custom development on both ServiceNow applications as well as the development of new applications, by changing baseline business rules or developing new applications from table extensions. Custom development is recommended only where configuration cannot meet business demands, and should employ recommended tools and methods (outlined in Step 3 of this document) as well as be supported by clear governance.

Interview Template

1.      Is there a documented guide, diagram, and/or flowchart for the process? (Process owner)

 

2.      Could you demo the process as it functions in ServiceNow? (Process owner)

 

3.      How does this process integrate with other processes? (Process owner)

 

4.      Are there process activities today that are no longer useful? (Process owner)

 

5.      Are there any process improvement activities that are in flight, or under consideration? (Process owner)

 

6.      How clear is the process in ServiceNow? Where could it be made simpler? (Service consumer, fulfiller)

 

7.      What integration and interfaces to other ServiceNow modules or other systems are in place? How well are these documented? (Process owner, service developer)

 

8.      What ServiceNow features work well? What could be improved? (Process owner)

 

9.      What ServiceNow features have been problematic during upgrades? (Process owner)

 

10.   Are there any process improvement activities that are in flight, or under consideration? (Process owner)

 

11.   How clear is the process in ServiceNow? Where could it be made simpler? (Service consumer, fulfiller)

 

12.   What integration and interfaces to other ServiceNow modules or other systems are in place? How well are these documented? (Process owner, service developer)

 

13.   What ServiceNow features work well? What could be improved? (Process owner)

 

14.   What ServiceNow features have been problematic during upgrades? (Process owner)

Interview Template

1.      Is there a documented guide, diagram, and/or flowchart for the process? (Process owner)

 

2.      Could you demo the process as it functions in ServiceNow? (Process owner)

 

3.      How does this process integrate with other processes? (Process owner)

 

4.      Are there process activities today that are no longer useful? (Process owner)

 

5.      Are there any process improvement activities that are in flight, or under consideration? (Process owner)

 

6.      How clear is the process in ServiceNow? Where could it be made simpler? (Service consumer, fulfiller)

 

7.      What integration and interfaces to other ServiceNow modules or other systems are in place? How well are these documented? (Process owner, service developer)

 

8.      What ServiceNow features work well? What could be improved? (Process owner)

 

9.      What ServiceNow features have been problematic during upgrades? (Process owner)

 

10.   Are there any process improvement activities that are in flight, or under consideration? (Process owner)

 

11.   How clear is the process in ServiceNow? Where could it be made simpler? (Service consumer, fulfiller)

 

12.   What integration and interfaces to other ServiceNow modules or other systems are in place? How well are these documented? (Process owner, service developer)

 

13.   What ServiceNow features work well? What could be improved? (Process owner)

 

14.   What ServiceNow features have been problematic during upgrades? (Process owner)

Expert Tip

EXPERT TIP

Guidelines for business‑smart customization should be defined first by your “North Star”:  the business objectives and value you’re trying to capture with ServiceNow.

Evaluate customization to determine costs vs. real value

Once you’ve revalidated your business objectives and use cases, these three steps will help you decide which configurations and custom applications deliver enough real value to merit implementation.

 

STEP 1: Score your configurations and custom applications by the business value they deliver.

Individual configurations and custom applications can also be assigned a simple “value score” that reflects how critical they are to business value realization. Perform the “North Star” assessment of your business value objectives and use cases as described above, and use that information when you analyze specific customizations.

Use Figure 2 as a starting point. Scoring should be consistent with your organization’s existing model for requirements management, using standard business value criteria that business analysts employ to prioritize requirements and/or user stories.

Figure 2: Value scoring for individual customizations (includes both configuration and custom applications)

 

STEP 2: Score common customization scenarios by their potential to impact upgrades, performance, or technical debt.

Most configurations and customizations can be assigned a low, medium, or high “complexity score” to reflect their volatility and the potential risk they present to upgrades, technical debt, and/or performance. Figure 3 shows a simple rating for common customization scenarios and the minimum level of business value that a new configuration or custom application should deliver to warrant implementation. Business value, per the table outlined above, takes into account improvements to user experience, adoption/usage, compliance, or the accomplishment of business objectives. These “complexity scores” reflect a simple low, medium, or high rating. Your platform experts can assign this rating based on experience with upgrades, data on past support issues, and/or the level of testing required to validate the customization. You can also consult with ServiceNow experts for additional guidance.

Figure 3: Scoring common customization scenarios by complexity and value

 

These “complexity scores” reflect a simple low, medium, or high rating. Your platform experts can assign this rating based on experience with upgrades, data on past support issues, and/or the level of testing required to validate the customization. You can also consult with ServiceNow experts for additional guidance. 

What about existing customizations?

Out of the box business rules

 

STEP 3: Tally your score to determine cost vs. value

While perfect cost‑benefit analysis is nearly impossible, this scoring system should give you a consistent, objective, and easily explained means to determine whether configuration or a custom application is worth its potential cost.

In smaller or more centralized organizations, your core ServiceNow team can administer this scoring. Size the level of effort required by:

  • The total volume of demand you anticipate for configurations and custom applications
  • A rough estimate of the time required to assess each of the potential scenarios listed in Figure 3

One customer interview suggested that an evaluation of individual custom applications may requires several hours per application, depending on the complexity of both workflows and data requirements. This may vary by organization or an application’s complexity, but some initial sampling can help to develop a baseline time estimate.

Simpler configurations, like field additions, may require less scrutiny, or you can evaluate them based on inferences you draw from data (like usage data) and/or interviews with power users. Keep process owners central to this evaluation to help determine whether customization is improving or detracting from process efficiency and effectiveness.

Integrations and customization

In more complex or decentralized organizations, your team may include multiple platform owners/administrators who complete the evaluation process. In this case, a globally consistent scoring mechanism is critical to avoid major differences in customization levels across business units or functions. You’ll want to ensure that different business lines, regions, and teams use a consistent definition and evaluation process for “business‑smart customization,” to avoid disrupting global workflows and data exchange.

Should we evaluate every configuration and custom application?

Keep in mind that this assessment isn’t a one‑time endeavor! It should be core to your ongoing ServiceNow governance and similar or consistent with your broader approach for IT change management, especially as you evaluate the level of effort needed to implement each new ServiceNow upgrade.

You can also reassess the value of specific custom applications or configurations relative to the new capabilities available in an upgrade. In many cases, new functionality may satisfy the original customization use case, making removal an option.

What to Do About Existing vs. New Customizations

The steps listed here can help make a clear cost-benefit analysis for new configurations and custom applications. But what about existing configurations and customizations?

 

As part of the system upgrade process, ServiceNow provides customers the ability to run an automated inventory of changes made to out-of-the-box scripting and configuration. To prevent customizations from being overwritten during system upgrades, the upgrade process skips (does not apply the update to) objects that have been customized. Upgrade Monitor can be used to list all updates skipped during the upgrade process to assist in resolving customizations that need review. Skipped records (including changes to hard-coded records sys_ui_form_section, sys_ui_related_list, and sys_choice_set; and changes to tables that have at least one field of type HTML, XML, script, or script_plain) are flagged with a priority score reflecting their potential need for remediation for an upgrade. Any of the customization scenarios outlined in Figure 3 (p. 7), above, will likely be associated with multiple skipped records.

As such, customers with existing customizations can:

  • Generate a list of skipped records and their priority scores
  • Conduct an analysis to group and associate relevant skipped records with a specific customization (for example, extending an existing table in scope). You may be able to look to update sets and scoped applications for documentation on why a specific record was customized.
  • Evaluate the customization in terms of its total cost and benefit, and determine if any remediation is necessary at the level of individual skipped records.
Changing “Out of the Box” Business Rules – A Note of Caution

Business rules can be changed to perform several actions, including preventing users from accessing or modifying certain fields on a form, displaying information messages to the user, or changing field values on a form that the user is updating. Changes to business rules in ServiceNow can be complex, and should adhere to the following best practices

  • Don’t overwrite the original rule. When you change an “out of the box” business rule, you should (a) copy and rename the rule, (b) modify the rule, and (c) point your process to the new rule. If you instead overwrite/overtype the original, future upgrades may take your rule “back to baseline” or fail to provide new functionality.
  • Prevent recursive business rules. Avoid using current.update() in a business rule script. The update() method triggers business rules to run on the same table for insert and update operations, leading to a business rule calling itself over and over, causing system performance issues. You can prevent recursive business rules by using the setWorkflow() method with the false parameter.
  • Where possible, stay small and specific. Ideally, changes to business rules should remain limited. “Big” business rule changes should come with strong business justification, given their potential complexity.
Integrations and customization

Customers engaged in enterprise services transformation will see more demands for cross-platform integration, but this doesn’t necessarily have to lead to complex, customized integration. ServiceNow’s IntegrationHub reduces the need for complex, custom-coded integrations by enabling execution of third-party REST APIs as part of a workflow, when a specific event occurs in ServiceNow. IntegrationHub supports three use cases, reducing the need for custom code:

  • Third-party REST API integrations.  Customers can post messages and ServiceNow incident, problem, and change record details to HipChat, Slack, or Microsoft Teams collaboration channels.
  • Integrations between ServiceNow instances. IntegrationHub provides an easy-to-configure spoke allowing for data synchronization across multiple ServiceNow instances.
  • Create REST actions.  IntegrationHub supports the development of custom REST web service actions, to support API development for web-based applications.
Should we evaluate every configuration and custom application?

For larger organizations, it may not feasible or economical to run a line-by-line review of every configuration and custom application, especially if this includes an evaluation of legacy configurations or applications. In these cases, you have two options:

  • Restrict evaluation to the riskiest points of customization. Using a list of common customization objectives (like those in Figure 4), you can elect to review only custom applications characterized by medium or high complexity or with known points of overconfiguration. The challenge with this approach, however, is that it could leave a number of safe—but legacy—configurations in place, regardless of their value.
  • Use a zero-baseline process. You can elect to remove any configuration or custom applications that don’t have a clear, validated demand from a process or workflow owner (with the exception of the configurations required for regulatory or compliance purposes). Alternatively, you can also allow individual business lines or distributed teams to implement configurations and/or custom applications as needed—as long as they adhere to appropriate development and governance guidelines. (See Steps 2 and 3 for more on this.)

The challenge with removing legacy points of customization, however, is it that it requires strong organizational change management for service fulfillers (e.g., service desk personnel) whose workflows and behaviors may have adapted to legacy configurations and custom applications.

What to Do About Existing vs. New Customizations

The steps listed here can help make a clear cost-benefit analysis for new configurations and custom applications. But what about existing configurations and customizations?

 

As part of the system upgrade process, ServiceNow provides customers the ability to run an automated inventory of changes made to out-of-the-box scripting and configuration. To prevent customizations from being overwritten during system upgrades, the upgrade process skips (does not apply the update to) objects that have been customized. Upgrade Monitor can be used to list all updates skipped during the upgrade process to assist in resolving customizations that need review. Skipped records (including changes to hard-coded records sys_ui_form_section, sys_ui_related_list, and sys_choice_set; and changes to tables that have at least one field of type HTML, XML, script, or script_plain) are flagged with a priority score reflecting their potential need for remediation for an upgrade. Any of the customization scenarios outlined in Figure 3 (p. 7), above, will likely be associated with multiple skipped records.

As such, customers with existing customizations can:

  • Generate a list of skipped records and their priority scores
  • Conduct an analysis to group and associate relevant skipped records with a specific customization (for example, extending an existing table in scope). You may be able to look to update sets and scoped applications for documentation on why a specific record was customized.
  • Evaluate the customization in terms of its total cost and benefit, and determine if any remediation is necessary at the level of individual skipped records.
Changing “Out of the Box” Business Rules – A Note of Caution

Business rules can be changed to perform several actions, including preventing users from accessing or modifying certain fields on a form, displaying information messages to the user, or changing field values on a form that the user is updating. Changes to business rules in ServiceNow can be complex, and should adhere to the following best practices

  • Don’t overwrite the original rule. When you change an “out of the box” business rule, you should (a) copy and rename the rule, (b) modify the rule, and (c) point your process to the new rule. If you instead overwrite/overtype the original, future upgrades may take your rule “back to baseline” or fail to provide new functionality.
  • Prevent recursive business rules. Avoid using current.update() in a business rule script. The update() method triggers business rules to run on the same table for insert and update operations, leading to a business rule calling itself over and over, causing system performance issues. You can prevent recursive business rules by using the setWorkflow() method with the false parameter.
  • Where possible, stay small and specific. Ideally, changes to business rules should remain limited. “Big” business rule changes should come with strong business justification, given their potential complexity.
Integrations and customization

Customers engaged in enterprise services transformation will see more demands for cross-platform integration, but this doesn’t necessarily have to lead to complex, customized integration. ServiceNow’s IntegrationHub reduces the need for complex, custom-coded integrations by enabling execution of third-party REST APIs as part of a workflow, when a specific event occurs in ServiceNow. IntegrationHub supports three use cases, reducing the need for custom code:

  • Third-party REST API integrations.  Customers can post messages and ServiceNow incident, problem, and change record details to HipChat, Slack, or Microsoft Teams collaboration channels.
  • Integrations between ServiceNow instances. IntegrationHub provides an easy-to-configure spoke allowing for data synchronization across multiple ServiceNow instances.
  • Create REST actions.  IntegrationHub supports the development of custom REST web service actions, to support API development for web-based applications.
Should we evaluate every configuration and custom application?

For larger organizations, it may not feasible or economical to run a line-by-line review of every configuration and custom application, especially if this includes an evaluation of legacy configurations or applications. In these cases, you have two options:

  • Restrict evaluation to the riskiest points of customization. Using a list of common customization objectives (like those in Figure 4), you can elect to review only custom applications characterized by medium or high complexity or with known points of overconfiguration. The challenge with this approach, however, is that it could leave a number of safe—but legacy—configurations in place, regardless of their value.
  • Use a zero-baseline process. You can elect to remove any configuration or custom applications that don’t have a clear, validated demand from a process or workflow owner (with the exception of the configurations required for regulatory or compliance purposes). Alternatively, you can also allow individual business lines or distributed teams to implement configurations and/or custom applications as needed—as long as they adhere to appropriate development and governance guidelines. (See Steps 2 and 3 for more on this.)

The challenge with removing legacy points of customization, however, is it that it requires strong organizational change management for service fulfillers (e.g., service desk personnel) whose workflows and behaviors may have adapted to legacy configurations and custom applications.

Expert Tip

EXPERT TIP

Use simple scoring mechanisms to frame the cost‑benefit of common customization scenarios, and use this evaluation as means to evaluate and prioritize business demands for customization.

Explore additional phases

Plan

You want to be sure everything is in place for a smooth, successful deployment.

Deploy

You want to be sure you’re following best practices during implementation.

Optimize

You’re up and running and want to get the most from your investment.

Extend

You’re ready to extend ServiceNow into other areas of your enterprise.