3

Capturing Value from your Implementation

Now that you know what traps to avoid when it comes to value realization, it’s time to highlight how and where ServiceNow can bring value to the organization.

We will look at how and where ServiceNow can help your organization capture value across the following themes:

• Lowering the process cycle time
• Optimizing asset utilization
• Automating repetitive tasks
• Improving customer experience

You will see as we elaborate on the various platform strategies used to achieve these outcomes that there are often various degrees of value realization that can be achieved depending on the scope and scale of the transformation. For some areas, the growth in value realization can be directly proportional to the investment, whereas others follow a more discrete pattern: investments provide little business returns until hitting a critical threshold upon which significant value is unlocked.

For each theme, we will summarize the value realization opportunity first, followed by what the common issues affecting value realization are in that particular area, and then detail how ServiceNow can help an organization capture the value. For each value realization strategy or tactic using ServiceNow, we will also provide some insights into how to plan for achieving the outcomes.

Lowering the process cycle time

Processes take a given input and produce an output of value to the organization. A lower process cycle time is about reducing the time it takes to complete the process from start to finish, with the primary goal of being able to run through the process more quickly and therefore produce value sooner.

Long process cycle times or unpredictable process cycle times can impact customer experience, as customer expectations are inconsistently met or missed. They also carry with them potentially significant financial costs where contractual obligations specify delivery according to a timeline with financial penalties attached to breached agreements. One area where long or unpredictable cycle times really matter is in the supply chain or procurement and asset management space where a long cycle time may mean very real increases in the financial risks, such as in the impacts on working capital or supplier payments.

Causes of long cycle times

Long cycle times do not simply just happen. Instead, there are many common patterns repeated across industries and markets, most of which arise due to the way organizations grow and operate. Learning what these common patterns are serves as a first step in determining how to solve these problems. We will list several such common patterns here that can help you identify how long cycle times may come about.

Confusion in how and where to engage a process

A frequent cause of long cycle times involves a lack of clarity on how a process can and should be engaged. This issue is common in organizations that are just starting to or have yet to build out their service management capabilities.

A sign of this problem occurring is when many services provided by IT or otherwise are engaged via the phone, email, or ad-hoc chat channels instead of through structured service requests. Typically, when there is a lack of clarity on how services should be engaged, customers will tend to prefer high-touch channels to be able to best articulate their issues and have a human help route them to the right place.

Having humans play the role of processing service requests and routing the work to the right place is only half of the battle (or less). If the processes and services being provided within (and outside of) the organization are ill-defined, even a person may not be able to appropriately determine where to send a particular request and what information to provide the receiving party. Another common pattern arising from this inefficiency can be seen in the sending of multiple internal emails and communications as part of a single request by a single requestor. Often, you will see emails going back and forth between the service requestor and the service desk, as well as the service desk and underlying teams who are trying to obtain the right information from the service desk and the customer.

If processes and the methods to engage them are ill-defined, the consistency of service request fulfillment times can be significantly impacted. This lack of consistency then results in several additional issues, which compound together to dramatically impact the organization. First, it is much more difficult to prioritize service requests effectively. This inability to prioritize will then result in more context switching in process and service operations, as tasks at risk of being overdue constantly appear and force the team to put all their effort into resolving them. This constant fire-fighting mindset can not only fail but even when successful, may also result in the highly inefficient delivery of service (either much earlier than necessary or perhaps just in time but with far more resources committed than should have been).

How to measure process cycle times and see your issues

It’s easy to tell when process cycle times are long or inconsistent – it may be much harder to quantitatively measure and see where the issues are occurring and prioritize the opportunities according to the return on investment.

Recently, multiple products have arrived on the market that can help the organization better understand and identify improvement opportunities. These ‘process mining’ systems plug into major service management, order management, or supply chain management platforms, automatically ingest and interpret the data flowing through these systems, help create a visualization of the health and flow of the process, and identify any bottlenecks.

If you suspect long cycle times are impacting your processes, utilizing a process mining solution in a targeted way to identify bottlenecks may allow you to take a more targeted approach to resolve the issue, improving your overall return on investment.

Delays in response to requests for service

Response delays can impact process cycle time by straightforwardly delaying the start of process engagement. Several factors can cause response delays. First, if there are simply too many incoming requests or inquiries compared to the throughput of the process, new inquiries and requests will begin building up in the backlog, drawing out the period between the time of submission to when the process is formally engaged.

Another cause for long response delays occurs when the intake channel for new requests is not formalized (as in the previously mentioned confusion over how to engage a process). In this case, the service fulfillers may not be monitoring the intake queues, especially for infrequently engaged channels – this can then result in long delays before a process is formally engaged.

A lack of upfront prioritization capabilities may exacerbate any existing response delay issues. When queues are backed up, it pays to work on the most urgent requests, inquiries, or issues first, but if there is no clear system to prioritize work, then a first-come-first-serve (or last-come-first-serve) model may arise very naturally. In the best case, the randomness of service requests causes the average response time to even out, but in the worst case, this can cause significant delays, as frequent but low-value inquiries and requests block the rapid allocation of resources for servicing high-value but less frequent requests.

Inability to find the right expertise to fulfil the request

Even when there is a structured way to engage in a process, the fulfillment of that process may still involve the identification of exactly where to send it after the initial attempts to address the service request have failed.

This situation occurs more commonly with processes that are initially engaged without perfect information, such as incident or problem processes. In these process types, it may not initially be clear what kind of expertise is needed to solve the issue, or indeed, even what the reason for the issue may be.

With these types of service requests, the initial response time may be rapid, but the resolution time may be exceptionally long, as the service fulfillment teams struggle to send the request to the teams where the cause or root cause can be identified, the issue resolved, or the request fulfilled.

Lost updates and poor transitions between service fulfillment parties

Processes often involve many different parties and some processes may even involve third parties external to the organization, such as contractors, vendors, and external service providers. Process cycle times may be significantly impacted if these third parties are delayed in delivering their results.

In addition to delays or failures to deliver by these third parties, cycle times can increase because there is no immediate feedback on when these external parties have completed their work. There are two primary reasons why this may occur: first, there may be no clearly defined way for the vendor to communicate the completion of their work back to the originating service, or the method to communicate back may be deficient in some way. A common example of this is when a particular third-party fulfiller is engaged via an external support system or channel. The fulfiller, upon completion of their service, updates a service request ticket in their system, at which point the onus is on the originating process fulfillment team to check that system to determine when the fulfillment has been completed so that they can take the appropriate next steps. The delay between when the process step has been completed and when an agent checks that system can significantly impact the process cycle time.

Second, the completion of the external party or process may not have clear traceability back to the originating process. This can be a much more significant source of process delays compared to the first issue. A common example of this is in hardware asset management or software asset management processes. A customer engaging in the process of getting a new laptop may encounter a situation where the fulfillment process identifies a lack of stock. The team fulfilling the IT asset request may then need to engage procurement to purchase more stock, which then needs to be shipped by the vendor to the shipping dock and delivered to the appropriate stock room before being sent to the customer. By the time the laptop has arrived at the shipping dock, the team receiving the laptop may not have a straightforward way of identifying that this laptop received was associated with the initial order, and therefore the update that they make to their inventory system to indicate this laptop has been received may be invisible to the initial service request or lost. In such a case, it is common to see the request be completely forgotten about until the customer, frustrated, calls in about the status of their order, which is then finally fulfilled as the agent checks the stock room and finds the laptop in stock.

How your ServiceNow transformation can reduce process cycle times

ServiceNow can reduce cycle times of processes through the following platform capabilities, often working in conjunction with each other.

Hosting structured service requests forms that may be driven by fulfillment workflows

The Request Management capability in ServiceNow, when combined with Service Catalog and Workflow, allows you to provide a centralized location where users may request services, reducing any confusion about how services and processes may be engaged.

Formalizing the request intake using electronic forms can reduce the number of low-quality requests that are received by the fulfillment teams. By making requests for service (and the engagement of processes) highly differentiated, the intake forms can contain error checking and input checking so that the user is encouraged and incentivized to provide the right information and the fulfillers can provide service immediately.

Finally, structured and differentiated service requests can then have workflows that send the requests to the right teams and individuals to service the requests at the right time. Workflows can also trigger automation and integration and send out appropriate notifications to agents if they do not consistently monitor the ServiceNow platform. With consistent processes, workflows can drastically reduce response delays and lost updates by facilitating the transfer of a task from one team to another.

The value that can be achieved by simply identifying frequently engaged services and putting them onto a central portal where users can engage these services using clear and simple forms should not be under-estimated: for organizations that are used to service engagement through email and phone calls, it can singlehandedly improve the customer experience and reduce the cost of service.

Utilizing master data such as the CMDB to automate or reduce the time spent on often time-consuming manual procedures

ServiceNow workflows and automation can be made significantly more powerful and effective with well-managed and purposefully designed master data. Master data, in this case, refers to data within the system that is consumed and shared across capabilities and processes – it is also often referred to as foundational data. The Configuration Management Database (CMDB) is a classic example of master data in that it is shared by multiple IT service management processes such as incident management and change management. Capabilities and processes utilizing master data can realize value beyond what can be achieved in isolation, as the master data itself ‘links’ the processes and allows for activities and events occurring as part of one process to signal other related processes. For example, utilizing shared application service data combined with technical service data events detected by event monitoring systems can automatically trigger the creation of incidents and the assignment of incidents to the technical service team closest to the probable cause. Taking a step further, the team investigating the incident may then look at change records associated to Configuration Items (CIs) with a relationship to the source of the error to help them narrow down the possible change that may have caused the problem.

Connecting multiple processes to prevent lost updates and improve on-time fulfillment rate

Shared master data and shared processes operating on a single platform can improve or eliminate the problem of lost updates during process transitions. An example is hardware asset management, enabling the teams at a loading dock to check in assets that have been purchased previously in the procurement or request process and notify the waiting party that their shipment has arrived.

ServiceNow bridges these gaps by tracking some aspects of each process and connecting them by looking at specific state transitions or data changes in one process that is shared in another. For example, in the case of hardware asset management, ServiceNow tracks hardware assets across multiple processes. When an asset is initially ordered, a record is created that associates the asset with the purchase order. Subsequently, using data from the vendors, the asset is associated with a serial number, which can then be scanned in at the loading dock to identify that the asset has now arrived. Upon arrival, ServiceNow can then notify the customer requesting the asset that they will soon be able to receive the item and have the asset moved to the right stockroom for distribution.

How to prepare for an implementation with a focus on reducing the cycle time

When attempting to use the ServiceNow platform to reduce cycle times, make sure you have prepared in the following ways as part of the implementation to improve your chance of success.

Clearly understanding the major process bottlenecks and the value of removing bottlenecks

Before starting the actual platform implementation, it is helpful to identify through process mining or other techniques where the actual process bottlenecks are. Once bottlenecks are identified, it is good to prioritize the bottlenecks by order of the value returned when the bottlenecks are reduced or removed to focus the implementation’s objectives and scope better.

Identifying exactly what kind of value you are looking to achieve with process optimization will help the team determine how best to solve the problems they will inevitably encounter during the implementation. Without an identified objective, it will be easy for the team to get lost and go beyond the scope of what is required or miss the ultimate objective as they get bogged down in the details of the specific issue they are facing.

Identifying and aligning the stakeholders and parties that will need to be involved to complete the change

If a bottleneck occurs due to lost updates or poor management of the master data then process optimization may require the involvement of multiple parties and stakeholders, often more than what you might initially expect due to the interconnected nature of typical enterprise processes. For example, optimizing hardware asset management processes often requires the service desk, the supply chain, and the IT, procurement, and HR departments to be involved and make changes. This does not even include external vendors who may also be involved in the end-to-end process.

If one or more of these groups are not aligned or are unwilling to implement changes in their respective processes or procedures, the results of the transformation may be significantly impacted. Therefore, an important first step in the implementation is identifying the types of change that may be required of these stakeholders and obtaining alignment with these stakeholders on the right timeline and resource commitments required to enable them to make these changes.

Now that we have covered how you can leverage ServiceNow to reduce process cycle times and identify where these cycle times may be, we will move on to look at another use case well-aligned with the capabilities of the platform – the optimization of asset utilization to reduce overhead and costs.

Optimizing asset utilization

Asset management has traditionally been an area where organizations invest substantial manual effort due to the lack of technology and the complexity of coordinating the various functions of the organization involved in the management of the asset life cycle. The problem is complex enough that for some organizations, certain asset types, including crucial ones such as end user computing devices, are completely neglected.

Low asset utilization and lost assets can cause tangible and serious financial impacts on an organization. The optimization of asset utilization includes increasing asset reuse, increasing the overall utilization of an asset’s value, identifying lost assets, and improving the purchasing or leasing strategies of assets so that they can be procured as cheaply as possible to maximize the return on investment for these assets.

A further important benefit of asset management in the IT space is in security. Understanding the disposition of technology assets – in particular, end user devices – can reduce the chances of security compromises by enabling the organization to quickly recover assets that are no longer needed by employees (such as in the case of offboarding) or be alerted about the possible loss of assets.

What do you consider an asset?

Any organization will have many types of assets, from office chairs and application servers to buildings, and many of these assets are managed by different teams, so there may be disparate requirements on how they should be managed.

When discussing the optimization of asset utilization in the ServiceNow context, we primarily mean IT assets (servers, laptops, desktops, software licenses, and mobile devices), as ServiceNow has out-of-box solutions created for managing these types of assets.

Within the vast universe of IT assets out there, only a proportion of them will be ‘managed’ by the organization. These are assets that the IT department or organization has determined to be important enough (typically due to the total cost of ownership of the asset) that the disposition, procurement, and utilization of these assets must be monitored. Not all IT assets should be managed, as the return on investment when tracking certain assets is low – examples of these types of assets include most consumables (e.g., mousepads).

While the focus in the following content will be on IT assets, many of the concepts apply to other types of assets within the organization. ServiceNow can also be used (and has successfully been used) to support the management of assets outside of IT, but these may require additional configuration.

Causes of poor asset utilization

Poor asset utilization can be caused by loss, over-allocation, or over-procurement, amongst other reasons. In this section, we will list many common causes to help you identify possible opportunities within the organization. It is important to know that while you may find poor asset utilization using these criteria, you must also qualify the opportunity. Not all assets are created equal and likewise, not all poor asset utilization scenarios are worth solving. With that said, it is also true that when it comes to IT hardware and software, there is often at least one or two asset classes whose poor utilization can incur significant negative costs to the organization.

Lack of a clear view of the organization’s asset inventory

To utilize assets effectively, organizations should have a clear view of what assets they have and where those assets are located. While this sounds simple in theory, in practice, this visibility is obscured within an organization by process, governance and technology gaps.

First, there may not even be a clear understanding of what kinds of assets are to be managed and what kinds are not to be managed within IT or the organization. The lack of formal standards in this area will often result in a lack of standardized processes to keep track of assets, leading to immediate losses of managed assets, as some assets slip through the cracks.

Software Asset Management (SAM) is a notable example of this issue. Without a formal SAM team or function within the organization, software assets tend to be purchased by many different departments for various purposes and tracked in different ways (or not tracked at all). This lack of standardization or a central purchasing process can make it impossible to determine the full extent of the organization’s software asset inventory. Software assets are particularly difficult to manage, as they are often entirely intangible, and unlike hardware, assets cannot be physically counted.

Without a clear view of the asset inventory, it is impossible for an organization to efficiently decide when and how to purchase new assets – it also significantly impedes opportunities for asset reuse, which then leads to increased operational costs for the organization.

Inability to determine the actual disposition of assets

Even if the asset inventory is well managed and understood, organizations may still have trouble maximizing the utility of assets because once an asset is known to be owned by the organization, the exact disposition of that asset is lost.

For example, laptops may be purchased, placed into a master inventory list, handed out, and then lost until an inventory count finds the laptop missing from a stockroom or facility.

Some of the difficulties in managing the disposition of assets include the fact that not every step of the asset life cycle is managed by the same teams in the same systems, and in other cases, it can be extremely time-consuming or resource-intensive to manage the state of these assets, even if a centralized group of individuals decides that they would like to track them.

Inability to understand the true utilization of an asset

Ideally, an organization wants every asset purchased to be highly utilized, with the assumption that high utilization of the asset contributes directly or indirectly to business value. It can be difficult, however, to measure what the utilization of an asset is and even what constitutes good utilization versus poor utilization.

For many high-value asset processes such as IT hardware asset management and IT software asset management, measuring useful utilization metrics is typically an activity that must be done using automated systems and tools. However, even when these tools are readily available, integrating them and federating them into a comprehensive view may prove to be a challenge.

How your ServiceNow transformation can improve asset utilization

ServiceNow has two primary modules that are directly created to optimize asset utilization: Software Asset Management and Hardware Asset Management. At a very high level, each module provides conceptually similar functionality: the ability to track the inventory of assets, the ability to track the disposition of assets, the ability to track the utilization of assets and the ability to integrate with other systems that may bring in asset data across these areas.

When evaluated in detail, software and hardware asset management are very different products as the high-level concepts of asset management translates into extremely different practical problems that each product is purpose built to solve.

ServiceNow provides a suite of capabilities that when set up and working together can be extremely powerful in achieving asset optimization goals. Initially, there are a set of three broad capabilities that should first be established:

Tracking IT hardware assets across the life cycle

ServiceNow’s Hardware Asset Management function allows the organization to track the inventory and disposition of IT hardware assets across their entire life cycle, from request and purchase to retirement. When processes are aligned to utilize this system, the organization can have a single view of its IT assets, where they are located, who they are assigned to, and where they came from.

ServiceNow’s IT Hardware Asset Management capability is also well integrated into the CMDB and can improve the CMDB by providing initial IT hardware CI data before the CI is installed into the IT environment. In this way, IT asset management provides an entry point for some CI types, giving processes such as Change Management and Release Management an early heads-up that these resources are available and may be used as part of implementations.

When service requests are designed to take advantage of IT hardware management, requests for IT hardware may directly utilize real asset inventory data in their fulfillment processes. Should procurement be an activity in these processes, procurement can utilize IT asset data to optimize purchasing decisions (e.g. by buying in bulk whenever possible) that can reduce the total cost of ownership of IT assets, thereby improving utilization.

Tracking IT software assets across the life cycle

Similar to IT hardware asset management, ServiceNow also provides capabilities to track the life cycle of software assets available to the organization. Unlike IT hardware asset management, however, identifying just what constitutes an IT software asset and ‘counting’ how many are available is a far more significant task for software assets. Because software is intangible, it can be difficult to even define what is the ‘asset’ component of the software, let alone being able to track its state.

ServiceNow’s software asset management capabilities provide organizations with reference models for software assets for major enterprise software manufacturers. These models allow the organization to manage software assets correctly, sometimes using named user licenses, and sometimes using several available installs. ServiceNow also provides capabilities to detect these assets, as they are installed across IT infrastructure, provided ServiceNow’s discovery capabilities are running in the environment or the data is being integrated from external systems such as Microsoft SCCM.

ServiceNow’s software asset module also provides ways to both automatically and manually track the state of software assets once they are in the system. Again, unlike IT hardware asset management, the intangible nature of software means that there are many different ways to track the disposition of software assets. For named user licenses, each named user consumes a purchased asset, while for utilization-driven licenses, the number of entitlements (or assets) may be depleted as they are installed. To complicate matters even further, the depletion of licenses may be based on other properties such as the number of CPU cores on the server a software may be installed on. Without software asset management, manually managing all the various types of licenses and entitlements that are available can become almost impossible.

Tracking hardware and software utilization

Determining the utilization of assets first requires that ‘utilization’ be appropriately defined. Subsequently, depending on how utilization will be measured, processes and technology can be put into place to monitor and improve that utilization.

For end user hardware, such as laptops and desktops, metrics such as login times are common and easy to obtain, as popular configuration management systems such as SCCM can be used to automatically report these metrics. ServiceNow can integrate with the system as a native platform capability and collect utilization metrics against the assets.

Software asset utilization is more difficult to measure, as usage information may not be directly available or if it is available, must be measured using proprietary approaches. For software covered by its publisher packs, ServiceNow has pre-built capability to determine usage. This can greatly simplify or reduce the amount of additional technology to be integrated with the platform to track utilization.

In any case, the actual tracking of utilization itself is typically done with technology outside of ServiceNow, but the platform provides capabilities to integrate with these data sources.

Once these three initial foundational capabilities are established, additional investment into the following three areas can substantially increase asset utilization and return on investment on the platform.

Reducing software asset compliance costs and reclaiming software assets

Poor software license management not only costs the organization in the form of penalties but over-purchasing can also be a source of substantial expense for the organization.

Once the capability is in place to identify and track the software asset inventory and measure the consumption of entitlements and the utilization of these entitlements, ServiceNow can then produce reports and alerts for when the organization’s software compliance position is at risk or has been breached.

The same synthesis of collected asset metrics for compliance purposes can also be used to help the organization reclaim unused or underutilized software assets. This can be particularly useful in the case of highly expensive, consumption-based licenses, where reclaiming an underutilized entitlement can save the organization tens of thousands of dollars per year for each reclaimed entitlement.

Optimizing asset procurement strategy

When purchasing assets, do you purchase a single asset as a one-off – or perhaps purchase in bulk to try to save money via economies of scale? When purchasing in bulk, how much of a particular asset should be purchased so that there is just enough inventory on hand for operational needs and not too many in storage?

When requests for assets, purchasing, receiving, distribution and utilization can all be monitored on a single platform, the ability to make asset purchasing decisions more strategically and in a more optimized way becomes possible.

With this information, ServiceNow can be used to centralize asset sourcing, pool requests for assets, and enable asset management teams to purchase assets in bulk by utilizing asset consumption trends to decide exactly how many assets to purchase.

Identifying and reclaiming hardware assets

For end user hardware assets in particular (laptops, for example), tracking the life cycle and utilization of assets from the time of distribution and installation provides organizations with the opportunity to reclaim potentially lost or under-utilized assets.

There is great potential for the loss of assets during the employee offboarding or transfer processes, either when employees are provided with new equipment as they move between departments or geographies or when employees leave the organization. By keeping track of what each employee has been provided with during onboarding, the offboarding process can utilize this information to reclaim the assets of a departing or transferring employee. Additionally, tracking the utilization of hardware assets through metrics such as login time allows for asset management teams to trigger automated attestations to validate that the asset is still being used and available.

Even if reclamations do not successfully occur, identifying the number of hardware assets that are lost annually can be a valuable metric to drive future continuous improvement opportunities.

How to prepare for an implementation with a focus on optimizing asset utilization

While ServiceNow can bring significant business value through optimizing asset utilization, careful preparation is needed to improve the success rate of implementation.

Before engaging in any asset management implementations, it is recommended that you are clear on the following points.

There should be a clearly defined asset management process owner

Asset management requires at least some level of centralized control and governance. There should be clear accountability in terms of who will be managing the asset data in the ServiceNow platform and the overall value realization of hardware asset management.

Sometimes, assets are managed in a distributed manner in an organization due to organizational silos (for example, perhaps IT manages most end user IT devices but the business manages permanent workstations in certain office locations). The asset management process owner can, but does not need to be, from any of those groups and can be part of a separate organization altogether. The asset management process owner does not necessarily need to be a direct manager of all individuals managing assets, but they should be someone at a someone empowered with sufficient authority to be able to set and enforce process standards for teams managing assets and ultimately report asset management metrics to the organization.

The asset management process owner should work with the executive team of the organization to clearly establish the scope of the asset process they are managing. This may include establishing factors about the metrics such as the types of assets that will be placed under management, what must be tracked to determine the success of the process (e.g., asset spend or asset utilization), and the escalation path for the process owner if they identify organizational changes that are outside their direct authority.

Is it also possible that an organization requires multiple asset process owners to manage all of the assets that it deems ‘important’. For example, it may be much more effective for the asset process owner managing end user computing devices for an organization to be different than the process owner managing corporate capital assets, such as buildings or large equipment. In the IT-specific context, you may still choose to have multiple distinct asset processes by splitting across organizational lines such as regions or lines of businesses. From a CIO or COO perspective, if these distinct asset owners exist, their overall effectiveness is best managed through having common reporting metrics as opposed to focusing on transforming the distinct operational processes into a single unified whole. For example, while the EMEA region may largely lease their laptops and the APAC region may largely buy them, the process owners responsible for IT hardware asset management in both organizations must collect metrics on the dollars spent per laptop and the business customer satisfaction with the IT hardware provided in the exact same way. These common metrics will align the distinct process owners in fulfilling the same important business objectives while providing them with the flexibility to optimize according to their local environment.

In summary, when allowing for multiple asset process owners in an organization, it is important to make sure that they each have clearly defined domains that have minimal overlap in terms of accountabilities and responsibilities, and this generally means splitting responsibilities along clearly distinct asset types (hardware versus software and facilities equipment versus IT equipment) or clear organizational lines.

Defining the scope of asset management based on the area of value to be realized

Just because it’s called asset management doesn’t mean that the scope is everything that could be considered an asset within the business. Assets can be tables, chairs, computers, servers, or transistors on a motherboard. Not all assets are worth the effort of tracking and optimizing. Additionally, what may be worth tracking tomorrow is not necessarily the lowest hanging fruit today, so careful consideration of the immediate scope of which asset utilization you wish to utilize compared to what you wish to manage in the long run is important to define beforehand.

Without a clearly defined scope of exactly what kinds of assets will be managed and why we want to manage them (that is, which of the value realization opportunities mentioned previously we are looking to take), it can be very easy to under- or over-commit resources during the implementation, as the scope either creeps beyond what is optimal or the stakeholders, time, and resources allocated are insufficient to truly create a positive return on investment.

When defining the scope of the implementation, make sure the following is clear:

• Exactly what assets will be managed by the system and supporting processes.
• How the implementation will deliver value (for example, which of the points in the How your ServiceNow transformation can improve asset utilization section are you going for? Which of the problems in the Causes of poor asset utilization section are you looking to resolve?)
• What supporting processes and teams will be subject to (or must execute) business change as part of the transformation and which ones will be off-limits (for example, procurement, supply chain, or the IT service desk).

The third point is particularly important, as implementation without the involvement of the right stakeholders might produce a half-baked solution that doesn’t realize the full potential of the platform in optimizing asset utilization.

Aligning and ensuring that all teams and stakeholders to be involved in the transformation are prepared

As with any other transformation initiative, the alignment of stakeholders is critical to the success of an asset optimization or asset management implementation on ServiceNow.

For asset management, consider the readiness and alignment of the following stakeholders and teams (depending on the implementation):

• IT service desk: Usually involved in asset management, as they may be the main team in the distribution of hardware assets and managing the installation of software assets.
• HR: Specifically teams involved in the onboarding, offboarding, and transfer functions that may currently provide end user hardware and software assets.
• Procurement/supply chain: Depending on the organization, asset purchases may go through centralized procurement or supply chain teams, and optimizing spending will require procurement to buy in to adjust their processes to leverage the new tools and data.
• Facilities/receiving/mailroom: Whoever may be involved in the initial receipt of assets at the loading dock and who (depending on the target process) may be involved in entering assets into the system once it has arrived.
• Vendors: Vendors may provide advanced asset data before the asset arrives in the environment, allowing traceability early in the asset life cycle. Vendors may also be responsible for asset tags or serial numbers that can be used to uniquely identify assets. For certain software assets, vendors may have tools and technologies that monitor asset utilization and asset usage, and these tools and technologies must be integrated with ServiceNow to complete the view of the software asset in the environment.
• Independent business units with significant off-the-shelf asset purchases: In many organizations, business units or business leaders may have access to individual budgets and may make substantial asset purchases. Depending on the scale of this purchasing, asset management may need to involve key business units and leaders so that these purchases are either consolidated into centralized processes or tracked so that enterprise-level optimizations can be achieved.

When embarking on an asset management transformation, you may encounter situations where some groups just do not wish to be a part of the change. Even in the most hierarchical and integrated organizations, business realities will still exist that may create resistance between a business unit, group, or team in following some broader integrated process to support an enterprise goal.

For example, it’s possible that a particular team has extremely high local levels of maturity and there would be an unacceptable impact on a team or its customers if they simply adopted a less mature enterprise process (e.g. the engineering team has a hardware procurement and provisioning process that’s highly automated with a small number of preferred vendors that they set up in isolation so that they can deliver their releases at a rapid pace, far beyond the needs of the rest of the organization).

While it may be possible to accommodate these differences, to match maturity levels, or myriad other ‘ideal’ options, there will be situations where the constraints of resources, time, and competing priorities may truly cause the integration to be impossible.

In such cases, the transformation initiative should look to reduce its scope so that the impact of non-involvement by the particular business unit, team, or group is minimized. This means not only restricting the scope of the target state process from the team ‘out-of-scope’ but also ensuring that there will still be sufficient business value delivered if the out-of-scope team does not change their process, procedures, or technology at all to accommodate the implementation of the target state transformation. Transformation plans should be halted and replanned if the return on investment is no longer justifiable without the involvement of the team. This should not be seen as a negative and instead, seen as an opportunity to identify why discrepancies in terms of priorities, initiatives, or level maturity exist and pivot the transformation to these areas first before proceeding with a broader asset utilization optimization transformation. The leadership of the organizational change management (OCM) team is crucial in determining whether these options should be considered, as they can provide a clear and people-centric view of the level and legitimacy of resistance and help the project’s steering committee to decide whether the costs of removing the resistance are worth the business value ultimately obtained.

Optimizing asset utilization involves the addition or enhancement of new and existing business processes to take advantage of the platform’s automation capabilities. In the next section, we will look at leveraging the automation capabilities of the platform to eliminate the boring, repetitive, and high-volume activities that erode productivity.

Automating toil

There are numerous repetitive, heavily repeated tasks in the operations of a business – wouldn’t it be nice if some or all of these tasks could be automated somehow so that a human could go do something more creative or more valuable with their time?

Sources of toil

Automating toil is an easily understandable concept and a major source of business value that can be delivered by the ServiceNow platform. While there are countless areas of work that can qualify as toil, given the areas of focus of ServiceNow, the following are several major relevant areas to focus on.

Creating, assigning, and managing tasks

As boring as it sounds, one of the most basic, time-consuming acts of toil is simply the management of tasks and to-dos, including the creation of them, the assignment of them, and keeping track of a list of them so that nothing is missed.

The management of a large queue of tasks can be tedious and error-prone if performed quickly, and when these tasks are arriving in an unstructured format such as email, time must usually be taken to convert the tasks into structured formats in systems so that they can be reported on and tracked.

To get a sense of how much time and effort is spent on this activity, examine the number of unique instances in a particular process flow where unstructured data is interpreted by a person and converted to structured data and where a record of a task (an email or a ticket) needs to be interpreted by a human and sent to another human or back to the customer. For each action that exists, assume a reasonable amount of action time (such as 30 seconds) to get a sense of the amount of time consumed by this simple activity alone.

Copying data or actions across systems

Organizations with complex workflows or many distinct teams and processes that interact with each other may also use multiple distinct technologies. While it is not wrong to choose technology that is fit for purpose, issues arise when some teams act as a bridging point between multiple technologies used by different teams as part of the same process.

For example, a front-line customer support team may take calls from customers and need to dispatch field agents to the customer site for additional triage. The field services team and the customer support platform may be different platforms, requiring an agent to copy information already captured in one system to the other to inform the field team that they must be dispatched. This discontinuity between systems may also add additional manual work if status checks are required – for example, if the field agent did not make it to the site, the customer may call for a status update, requiring the customer service agent to look for the customer on in the customer support platform first before then checking the field services platform to see why the visit was not accomplished.

This type of swivel-seating can be extremely time-consuming. Each time data is copied, not only is time spent to copy the data (upward of 1 minute or higher) but each transition can also cause errors and information loss that impact the quality of service delivery.

Operational reporting and distributing operational reports

Operational teams can spend hours or tens of hours every week compiling operational reports. The less structured the incoming data is, the more time-consuming and less accurate these reports become.

Operational reporting should be differentiated from analytical reporting. The former is meant to provide a more granular (and ideally real-time) view of the immediate situation. Operational reporting is useful to help operational teams allocate resources, manage staffing levels, and identify operational gaps and issues. Analytical reporting is often done for longer-term, predictive use cases such as determining long-term organizational strategies and computing metrics that may only become apparent when data from many sources is aggregated and then transformed to be useful for a particular algorithm or heuristic.

Operational reporting is generally a greater cause of toil (and certainly a greater opportunity to reduce toil) than analytical reporting because it is repetitive, typically comprised of numerous simple but manual steps, and occurs on a fairly frequent basis. Operational reporting’s most time-consuming aspects include extracting any required data into a tabular format, cleaning up any data in the reporting that may be invalid or incorrect, interpreting the data line by line, applying metadata that may be needed to facilitate operational reporting metrics, calculating the operational metrics, and generating reports for the metrics.

In addition to the work of actually compiling the report, another time-consuming process concerning operational reporting is the distribution of the reports to stakeholders, involving identifying the stakeholders, crafting the communications, embedding the report files into the communications, and sending it.

Regression testing

A ServiceNow platform that is thriving as an enterprise enabler of value will inevitably experience a high volume of changes as new configurations are released regularly to deliver additional value to the organization. Inevitably, the pace of these changes runs into the competing issue of maintaining the integrity of the platform and reducing disruptions caused by the unintended impacts of change.

For smaller implementations or inactive platforms, regression testing existing functionality by hand may be feasible. For large enterprise implementations where releases occur frequently and ServiceNow is used as a platform for numerous business-critical teams, automating the testing of existing functionality not only reduces toil significantly but also significantly improves time to value. ServiceNow provides automation capabilities for regression testing using its Automated Test Framework (ATF), which can significantly reduce this overhead.

Where ServiceNow can automate toil

ServiceNow provides several key capabilities that can be used to automate the various sources of toil within service delivery.

Workflow engines, email actions, chatbots, and structured service requests for automating the toil of creating, assigning, and managing tasks

ServiceNow has a collection of capabilities that when used in conjunction with good process design and underlying master data, can significantly automate the toil of creating, assigning, and managing tasks.

The actual principles of this automation are simple: common customer requests are analyzed so that the standard set of information needed from the customer to deliver service is structured into purpose-built intake fields on an electronic form. Automated error checking can then be implemented to reduce errors from customer entries. The structured form will improve the quality of the requests and improve the chances that the request can be serviced correctly the very first time. The agent’s toil of having to engage the customer to truly understand what they are asking for is also reduced by this improved clarity.

Once the request has been submitted, the structured input data can then be used as a component of automation. ServiceNow has a workflow engine that can direct the task to the appropriate teams and individuals for service based on both the intake data and the business logic working on that data. For example, an HR service request for a recommendation letter may go to two different departments depending on whether the requester is a contractor or a full-time employee. With the appropriate HR data integrated into the platform, ServiceNow can decide this on behalf of agents and route the request to the appropriate team automatically.

Sometimes, even though a structured intake exists for a particular kind of service, customers may intentionally or unintentionally avoid engaging with that structured intake due to ignorance, convenience, or preference. Whatever the case, ServiceNow provides capabilities such as Virtual Agent that can help take these unstructured inquiries, prompt the user with the appropriate questions, and then turn the initially unstructured engagement into a structured request. In this way, ServiceNow can help increase the number of customer engagements that become structured requests that can then be targets of automation.

Integrations for supporting e-bonding and sharing data across systems to reduce swivel-seating and copying data between systems

ServiceNow makes integration with other systems relatively easy to build and maintain. Components such as its Integration Hub and its native integration and API capabilities can be used in a fit-for-purpose way to automate the copying of data across systems at critical transition points.

Several use cases are particularly low-effort but high-value – for example, when records need to be created in remote systems (such as when customer service agents have to dispatch field agents using a different system) and only the remote agent’s text and status updates are needed to help the ServiceNow agent obtain the appropriate visibility to best serve the customer. In these cases, having a ‘shell’ record on the ServiceNow platform reflecting status and work-note information from the target system using integration can provide the ServiceNow agent with the required visibility while requiring very little technical complexity.

The remote ticket can even be created from ServiceNow via an integration where ServiceNow passes the appropriate information required by using the initially created ticket, reducing the need for agents to take the same action twice in two different systems.

Some caution should be applied to attempting to create ‘true’ e-bonding designs when automating task copying across systems. This refers to e-bonding solutions that attempt to merge business processes across two systems using technical integrations, which can be very complex to accomplish and should be avoided when other alternatives exist.

In most use cases where ticket information needs to be passed between systems, the appropriate design is to create a proxy record in ServiceNow representing the basic information about the state of the remote record and link that proxy record to the initial task record (for example, an incident created in ServiceNow is passed to a remote team on a different platform on an incident task record, which serves as the ‘proxy’).

With this design, the proxy record’s state and other information can be independent of the parent record, creating a great amount of flexibility on the ServiceNow developer’s side in terms of how to change the parent ticket’s attributes given changes occurring to the proxy ticket (if at all).

A design that should be avoided unless absolutely required is a true ‘e-bonding’ system where instead of creating a proxy ticket to designate the remote ticket, the initially created record is, upon a triggering action, effectively synchronized to a record in a remote system and from that point, effectively exists as a virtual mirrored object across two systems.

The risks of this design are that unless the target system can fully mirror the source system, and unless the target system’s teams execute identical processes and procedures, the synchronization process will need to be complex to translate the various idiosyncrasies between the remote and source records. For example, if the remote system has five incident states while the source system has four, the e-bonding will require logic to translate the odd state on the remote system into a valid state value on the source system, or the remote system will have to block the extra state when the ticket is in a synced state. If all that sounds confusing, it is because it is. E-bonding solutions should be avoided whenever possible in favor of the proxy record design and even if attempted, it is recommended to use technologies specifically created for this purpose to manage all the issues that could arise from such a design.

Before embarking on any e-bonding solution, your platform team should make sure it is familiar with the various out-of-box capabilities offered by ServiceNow to simplify e-bonding in specific cases. For example, Integration Hub offers spokes that provide out-of-the-box capabilities for querying, updating, and creating tickets in supported external systems, which can reduce the need for bespoke integration development. The Service Bridge capability of the Telecommunications Service Management application provides a framework for facilitating e-bonding between ServiceNow instances.

Real-time operational reports and dashboards eliminate the time needed to create operational reports by hand

ServiceNow has out-of-the-box, competent operational reporting capabilities that can be used to generate real-time operational reports based on the data flowing through the system.

ServiceNow also provides the capability to present these reports (and related reports) on real-time dashboards, which can be made accessible to specific individuals and groups.

This operational reporting capability, when appropriately leveraged and planned for during the implementation of the platform, can eliminate or drastically reduce the need for manually created operational reports. If some may not want to access these reports and dashboards in the system, ServiceNow can schedule these reports to be sent to specific groups and individuals regularly by the more traditional email channel.

The automated testing framework can be used to increase agility and reduce the manual effort of regression testing

ServiceNow’s ATF can be used to automate testing platform changes. The ATF is a built-in testing tool that can exercise ServiceNow platform changes, including interfaces built on the service portal.

The ATF is highly complementary to test-driven development approaches where tests are written to fail and then platform changes are implemented to pass these tests.

Once automated tests have been set up to test a particular functionality, platform deployments (including minor releases) should require test suite runs to verify that changes in a release have not impacted the expected behavior of the existing configuration.

While automated tests can significantly reduce toil in the medium and long term, they do add overhead to the configuration process. The time it takes to write good tests that are robust and fail for the right reasons should not be underestimated, and teams should expect an increase of at least 10 to 20% in the overall development effort (some say it could be 50% or greater) when automated tests are written as a rule for all configurations. Despite the costs, the rewards of automated testing are significant, both in terms of long-term savings in toil and reducing risk to the business caused by bad changes.

How to prepare for an implementation with a focus on automating toil

Besides the universally relevant truisms ‘understand your stakeholders’ and ‘understand your use cases’, there are some preparations to make when it comes to planning and preparing for an implementation targeted towards automating toil.

Measuring and ranking your sources of toil

One of the most important preparations when looking to automate toil is to measure and rank your sources of toil. This means collecting operational data, either manually or automatically, to determine where the greatest source of toil is occurring so that your automation initiatives can target the right automation opportunities.

While there is likely to be a broad array of places where repetitive and menial tasks happen, the greatest opportunities are typically found in areas where there are high volumes and even small improvements or savings can lead to dramatic savings in time and frustration.

Another easy way to identify potential areas of toil is to simply ask the people that do the work – they will likely provide a host of insights into where toil happens and opportunities to automate exist. Whenever stakeholders are questioned or interviewed, the information should always be used only as a starting point – some level of measurement should be done to quantify the actual impact on the business and enable prioritization.

Standardizing processes and procedures

Automation is not magic. Machines are great at automating tasks with a fixed number of objective and quantifiable decision points and not so good at making decisions that rely on subjective interpretations of ambiguous data. This is true even today when advances in artificial intelligence have made machines much better at making decisions based on larger input data sets with less discrete differentiation between those inputs.

The first step in enabling automation in areas where repetitive actions or manual tasks are currently being performed is to attempt to standardize or simplify those actions and tasks into clearly defined logical workflows and decision-making points so that the rules can be captured and then executed by the platform instead. To do so, you should examine the processes of opportunity and design changes into the process to better facilitate automation. This usually means identifying the distinct decision points that need to be made, standardizing the input data required to drive those decisions, and standardizing the actions taken once those decisions are made.

This concept of designing or changing business processes in support of automation is not only powerful for preparing for ServiceNow implementations but is also a generally applicable concept that can significantly differentiate a business in its ability to return investment on technologies.

Clearly understanding how value will be measured for returns

While any initiative should be measured for its returns on investment and value realization, the automation of toil is a particularly strong use case for having quantifiable measurements of value because it’s usually clearly aligned with directly measurable metrics.

Establishing ahead of time how value will be measured and return on investment calculated can help focus the implementation on dealing with toil in the right places and the right ways, avoiding overcommitting or under-committing resources or over- and under-pivoting on requirements.

One important pitfall to avoid when it comes to measuring the return on investment on this type of initiative is to think that the only way to actually realize value from automation projects is when there is a reduction in headcount. This perspective is shortsighted and neglects other benefits that could be just as or even more valuable than operating costs but are simply not being regularly measured – improvements to the quality of service, improvements to the quality of life of your staff (leading to reduced turnover), and enabling your teams to focus on more creative work, leading to new business value opportunities being generated that no one had time for in the past.

Up until now, we have extensively discussed opportunities for the platform to deliver value to the organization by optimizing and enhancing its capabilities to deliver service efficiently. In the next section, we discuss how these capabilities, in combination with others, can help create exceptional customer experiences.

Improving customer experience

Regardless of how well an organization has optimized its processes and streamlined its services, these improvements are irrelevant if they do not tangibly affect the ability of the organization to deliver a great customer experience. In this section, we will highlight the levers of customer experience that can be pulled to improve it and how ServiceNow plays a role.

Where customer experience can improve

Whether it’s an IT organization at a small organization or a globe-spanning product company servicing millions of customers, the improvement of customer experience is an oft-pursued goal when it comes to ServiceNow transformations.

The issues that organizations are looking to resolve typically follow a few key themes.

Providing a non-fragmented service experience and a single place of service

Service portals and digital storefronts are all concepts related to solving a common customer service problem – how to provide a user-friendly and personalized place where customers can engage the services offered by an organization (or parts of the organization).

The concept itself seems simple enough – if a single highly personalized and user-friendly portal exists for the customer, it will improve customer experience and reduce customer frustration when they need help or support for one or more of these services. It also allows the teams supporting that customer or delivering that service to focus their resources on improving that single portal or storefront, increasing efficiency and generating greater returns on investment.

In practice, customer service remains highly fragmented. Within the enterprise, there are more often than not many ’storefronts’: IT service portals, the company intranet, and so on, and it can often be highly confusing for employees to navigate the maze of options available to them. If no clear guidance is provided, business customers will resort to what they know best: reaching out by email or phone to get the support they need, not only increasing their frustration but also the operational costs of the business.

While the consumer or customer-facing space tends to be in better shape, many problems still exist. While there is typically only a single digital engagement channel initially, the problem is complicated when acquisitions and the launch of new services fragment that storefront.

A single view of the customer across all service channels

For product or service organizations with consumers as customers, the concept of a single pane of glass or a single view of the customer describes the ability of agents and systems to get visibility into a customer’s history, preferences, and past interactions regardless of which channel the engagement has occurred within. A typical example of this is for a customer service agent to be able to see that a customer has had a recent interaction with a sales agent inquiring about new services or that several returns have been processed in the last 6 months.

The single view of the customer ideally enables agents and systems to present services, options, and support in a more personalized fashion, specifically in the world of consumer and services industry organizations, which could lead to greater monetization opportunities.

For the customer, a single view can also lead to more consistent service experiences and engagement across various channels (imagine going to a walk-up or store and being provided tailored services or experience because of your frequent online purchases and preferences).

In the context of enterprise services meant for the internal organization, a better internal view of the customer can also allow more targeted enabling services, better prioritization and stratification of support levels, and better analytics to help enterprise services deliver better outcomes for their customers. An example of having a single pane of glass in the internal organization includes tying HR, facilities, and IT services together to enable employees to have a seamless onboarding and offboarding experience.

Linking customer-facing services and products to internal services to predict service impact and plan service improvements better

Customer-facing organizations often struggle to connect their internal business services to their customer-facing services despite the deep relationships that often exist between the two. For example, telecommunications companies rely on both technicians and support personnel facing the customer to deliver service, as well as internal technical teams who maintain applications, servers, databases, and core network infrastructure that delivers telecommunication services to the customer.

In these deeply connected organizations, the ability to see the interdependencies of these disparate parts of the organization can improve customer experience by better managing the risk of change impact. It can also deliver better service by letting customers know when downtimes may occur and when service may be restored. Again, using a telecom example, in the case of outages caused by issues in the core network or internal applications responsible for the delivery of service, customers often have little visibility into even the most basic information, often because it is difficult for even the telecom to understand which customers may be impacted by the outage they are seeing. By creating more visibility into these dependencies between internal and external services, it becomes possible to provide customers with more proactive and regular feedback, improve their experience, and reduce the number of calls to and engagements with the customer support organization.

The visibility of the interconnection of services can also help product-driven organizations to coordinate marketing, sales, product design, and customer support better and reduce intra-company friction. Sales and marketing often love to create as many product and support options as possible to optimize monetization opportunities, whereas the support and product organization prefer more simplified options as it reduces the complexity of the support and maintenance. By connecting these domains through integrated processes and data, the organization has a better chance at finding the right balance that optimizes cost against revenue generation.

Where ServiceNow can help improve customer experience

Now that we have seen where several areas of customer experience can be improved, we will look at where the platform can add value by improving the experience across these areas with its capabilities.

Consolidating services into a single portal or related portals on a single platform

ServiceNow’s Service Portal capability provides a way to reduce the number of integrations necessary to tie multiple distinct service delivery groups together, consolidating a fragmented customer experience into a more cohesive one.

The advantage of using ServiceNow as your platform to deliver a service portal or portals is primarily gained through the ability of ServiceNow to also be a work management and workflow management tool in the delivery of these services. Many dedicated portals or content management solutions will require more complex and difficult-to-maintain integrations with the underlying systems of action to provide users with visibility into the status of the services they have requested from the portal – ServiceNow can provide this level of visibility in a much more technically straightforward way, with significant reductions in the number of custom integrations required. This tight integration enables organizations to provide a deeply interconnected and cohesive experience with fewer resources upfront as well as reduced operational costs over time.

How to make objective decisions on designing a subjective customer experience using experiments

Taste and preferences vary by individual. Organizations pursuing a transformation to consolidate or create a brand-new service portal or service catalog may have questions such as “How many portals should we have?”, “Should we split our services into their own distinct portal areas or have them all on a single page?”, or “What should our catalog look like and what categorizations should we apply?”

Many of these questions are highly subjective in nature and can be prone to contentious debates that go nowhere, increasing the cost of the transformation and stalling time to value in the worst cases.

The secret to success is embracing the fact that there will never be universal agreement on something so subjective. Instead, the ‘best’ solution will often be the solution with the greatest buy-in despite the existence of reasonable counter-perspectives. With that said, a democratic voting process is not always the only option when deciding which design is best. User experience design tools such as A/B testing, card sorting (and reverse card sorting), and mouse and eye tracking heatmaps can be used to provide more objective data on how designs differ. In the case of methods such as card sorting and reverse card sorting, it is possible to decide with the appropriately sized testing groups which proposed catalog categorization structure is objectively better than another, even if the advantage is slight.

Integrating end-to-end service delivery processes and channels onto a single platform

Enabling a single view of the customer often begins with consolidating the work products of operational processes that engage or support the engagement of those customers into a single cohesive design. ServiceNow, by virtue of its focused capabilities for workflow management and task management, can serve as the primary platform of work for many of these channels, with its robust and easy-to-maintain integration capabilities bringing in further data and insights from other systems of engagement to provide a single, unified view of the customer.

The ability for ServiceNow to take advantage of federated data comes from using that data to drive workflows, improve operational reporting, and assign the right teams to help the customers at the right time.

ServiceNow also provides a ‘next-best-action’ capability that allows rules to be created using the customer data to guide agents on how to provide the best support and service outcomes. This capability is particularly important as the amount of data known about the customer (and related to the customer) grows. A human will find it difficult, especially under time pressure, to be able to consume all the relevant data and decide on a best course of action, but having the platform provide these recommendations on behalf of the human agent allows them to take full advantage of the federation of customer data and provide a differentiated service experience.

Tying internal and external services together using the Common Service Data Model and CMDB

While the concept began in IT Service Management, the concept of the CMDB and ServiceNow’s implementation of its CMDB and related capabilities provides the building blocks necessary for internal operations and customer-facing operations to understand their interdependencies better and create a clear picture of how they impact each other.

When following the common service data model design and with clear use cases and governance in place, ServiceNow can be leveraged to help organizations anticipate, visualize, and measure the true impact of internal service outages and the problems caused for the customer and the cost of maintaining and supporting the new products and services sold to the customer.

Being able to visualize and tangibly see how these processes and services relate and connect can often act as a starting point for more ambitious business transformations that will truly align the organization from end to end. A valuable goal would be to create services and products that are not only optimized by looking at sales but also by incorporating the total costs and requirements of support and operations through the lifetime of the new product.

How to prepare for an implementation to improve customer experience

When implementing a project with a significant customer experience improvement objective, one of the most significant steps to take is to identify a set of objective measures alongside more subject measures of value realization.

Capturing a baseline of the relevant metrics and then subsequently measuring improvements in these metrics when the transformation is underway or complete could in and of itself be a project or transformation. This is especially true in the case of customer experience when most metrics need to be collected against a large representative sample size to be relevant and prevent overfitting or focusing on something that feels significant but is not in the grand scheme of the overall customer experience.

Knowing where to focus customer experience improvements is another important activity that can help with implementation success. Key elements of this understanding when it comes to a customer experience focus include the following:

• Clearly defined types of profiles for customers that describe distinct or unique needs and behaviors
• Collections of user journeys that these customer profiles undertake, ranked from the most common journeys to the least common ones
• An idea or directional alignment on which journeys need improvement (ideally backed by measurable data points)

Summary

In this chapter, we looked at common value realization opportunities within organizations and how ServiceNow’s capabilities can be used to capture these value opportunities. We also looked at how careful pre-planning can make transformations more successful when they occur. Common themes that enable success for all value opportunities include establishing clear governance, identifying metrics and measurables to create quantifiable goals and objectives, and having concrete ideas on what should be changed in the target state compared to the current state.

In the next chapter, we will look at a broader collection of these optimizing factors that you should be aware of so that your transformation has the greatest return on investment and chance of success.