In the Kingston release (I think – it’s hard to find the exact history), ServiceNow debuted “Flow Designer”, ostensibly a newer and better way of creating automated workflows. The idea being that the Workflow engine was coming to the end of its useful life, and the platform needed an upgraded way to automate processes and give more power to non-developers and non-ServiceNow admins. Ostensibly fulfilling the marketing pitch of “Citizen Developer”.

I’ve begun working with Flow Designer and completed the primary micro-certification. After both studying Flows and using them in the real-world, I’m struggling to “get onboard” with either the marketing or the reality of using them. Despite my rapidly advancing age, I try to keep an open mind about these things and, when I get frustrated, stop to think, “Am I approaching this from the wrong angle? Am I missing something obvious? Am I too set in my ways?” However, after this experience and these considerations, I have several observational concerns about Flow Designer:

The Flow UI does not align with how humans visualize processes

Flow Designer is a linear, top-down graphical model. Step 2 follows (falls under) Step 1, Step 3 follows (falls under) Step 2, and so on. While I think this is fine for very basic logic flows, rarely do business problems get solved with very simple rules with a handful of steps. Rather, when humans gather to map out business flows and determine what and how many paths are needed to arrive at the solution, or at least the conclusion, they draw them on the whiteboard like this:

At least they have in my experience. In other words, they draw flowcharts, which can and often do incorporate lots of divergent paths. These are both hard to visualize and to build in Flows. In fact, it’s almost laid out in pseudo-code fashion.

This is how an actual flow appears:

I’ve seen flows in the real world where an else comes 30-40 steps after its corresponding if, making it quite difficult to visualize as a lot of scrolling is required to see the complete block. And although I’ve heard this is coming, you can’t easily do branches or rollbacks. You simply have to keep adding and nesting steps.

I was recently working on an integrated request application where we were having lots of issues with the Flow because it was almost 140 steps, making it hard to visualize and troubleshoot the end-to-end. I suggested we try a Workflow alternative, and not only were we able to reduce it to less than 30 activities, but when the customer saw it using “Show Workflow”, they immediately said “Oh, this is much easier. I can understand this.”

Flow Designer takes longer to develop and deploy

In my experience, developing the same solution in Flow Designer takes longer than in Workflow Editor, and not by a small amount. When I’ve been working with project teams that are attempting to build solutions in ServiceNow using Flows, and I estimate time to complete using my 12+ years of ServiceNow experience, I’m always underestimating the level of effort, because I’m basing it on how long it would take using a Workflow. Here are a couple of more specific examples:

• When I was trying to “do the right thing” and learn Flow Designer, I went through the micro-certification course. One of the learning activities was to create an approval. After finishing 20 minutes later, I thought, “this is supposed to be easy?” Here’s ServiceNow’s documentation on it: Flow Approval. I realize it has flexibility, but if you want a simple approval, why all the hassle? Conversely, in Workflow, you add an Approval activity, add the approver(s) to it, and draw the lines out of Approve and Reject. This can be done a few minutes or less.
• In a recent project, there was an integration to Service Request and Hardware Asset Management that used a Flow to manage the lifecycle of the request. The Flow was over 130 steps. After nearly a year of trying to resolve all issues and go-live, and after HI Cases to figure out why the flow wasn’t working, we scrapped it in favor of a Workflow. The Workflow was less than 30 activities and was deployed in less than 4 weeks.

Part of the marketing pitch is that Flows can be built as small, standalone chunks of work that can be called from other Flows, allowing for quick build of these standalone chunks of work. I see problems with this idea:

1. Having the knowledge and intelligence to logically break the Flows into the correct smaller Flows is quite difficult, particularly for folks who do not come from or have a design background.
2. Managing lots of Flows and being able to piece them together into a workable Top-level Flow with Subflows is also challenging. It’s like dumping a series of Lego sets on the floor without the instruction sheets and trying to piece together coherent models. It’s technically possible, but unlikely and frustrating to-boot.
3. If you are able to build the Flow, testing and debugging is harder because you have to drill into subflows to see where the issue may occur. I’ve also found that it’s not super easy to see what data is passing back and forth between the subflows and the calling Flow.

Given these, I haven’t found that non-developers can easily design and build these the correct way, if at all. As I mentioned in one of my examples, I get pulled into troubleshoot a Flow that’s well over 100 steps, because the original developer couldn’t logically factor it into manageable subflows.

Flow Designer is a code-replacement tool that requires code to make work

If you think about what a Flow is, and how it is built, it is essentially a complicated code-replacement tool. Think about data pills – these are graphical dot-walks, and workflow variables. All this is wonderful if you can actually have non-developers creating viable Flows, which is the advertised benefit. I have yet to see this actually happen in reality, for the reasons I’ve mentioned thus far. Here’s another reason: In my experience, when Flow steps don’t work as expected, and there’s not an obvious reason why, the solution is usually to open up the script editor in the Flow step and write the equivalent script to what the flow should be doing without script. This negates the ability for non-developers to create them, or at least to make them production-ready. My experience has been teams using Flows can have less senior folks put together a framework, but require senior developers to actually get them in working order.

Conclusion

My straw polling amongst my peers and teammates is that no one finds Flows easier to use than Workflows, and many either shrug and say, “Well this is what ServiceNow is telling me to do”, or, “This is what I learned in training”. My educated guess is that Flow Designer was introduced to ServiceNow by an executive with enough clout to push it through as a viable Workflow replacement. I’d also guess it was purchased rather than built. After attempting to work with it for the better part of two years, my conclusion is: “Why?”. Why am I compelled to use this product? Why was Workflow scrapped instead of being upgraded?

I’m fairly certain that putting some development heft behind Workflow could have made it more powerful and more flexible, rather than leaving it as is for a more complicated, less useful tool. Until someone who knows tells me that there’s a technical reason Workflows had to be scrapped, or a technical reason I shouldn’t use them (rather than “marketing” reasons), my conclusion is that for the foreseeable future, unless there’s a pre-built Flow that does exactly what I need, I will continue to build in Workflows until I can’t.

Develop based on what you know, not what you’re sold

Tiering Examples

1. User in building 3, floor 2, Accounting department reports an issue with accessing SAP. Root cause is a misconfigured switch port.

• Tier 1: User calls the Help Desk. A support agent opens a support ticket and does some basic troubleshooting – reboots, logs out and in. After 10 minutes, the agent tells the user they need to escalate and ends the call. The agent assigns to a SAP support group. After a few hours, an SAP engineer sees the ticket and begins to ask around if there are any known issues currently. He also confirms he can access SAP and notes no issues in the logging. He IMs local support in building 3 and asks if they can do a remote session. After some troubleshooting, they realize all computers on floor 2 are having trouble accessing some network resources. The ticket is reassigned to Networking. The next morning, the Networking team picks up the ticket and reads through all the notes. They check with the team verbally and via IM to see if any changes went in recently. After a few hours, they realize there was a switch card installed to fix a hardware issue 2 days ago. They begin to troubleshoot and by early afternoon, find the misconfiguration and fix it. They assign the ticket back to the Help Desk and the level one support team checks with the end user that service has been restored before closing the ticket.
• Tier 5: User submits an incident through the Self Service portal with a high impact, after confirming several members of his team are having the same issue. The incident is marked medium priority and tied to the SAP service and auto-routed to SAP support. SAP support picks up the incident and checks the SAP system for issues, seeing none. They view the CMDB map to check for upstream issues, and see that there are other incidents and a change tied to the network switch in building 3, floor 2. They change the affected CI to the switch and the ticket is auto-reassigned to the networking team, and change the priority to high. The networking team’s SLA-based queue dashboard moves the incident to the top, and the incident is assigned to a level 2 engineer automatically. The engineer, viewing the same CMDB map, makes the incident a child of another incident opened against the same switch. The team sees the change, and finds and fixes the configuration error based on the implementation notes for the Change. The parent is closed and the resolution flows to all children. Service is restored within 2 hours. Management reviews the change and sees a gap in the review process that allowed the issue to occur, and the change templates are changed to prevent the issue in the future.

2. A manager in Sales needs to onboard a new sales rep working remotely

• Tier 1: The manager emails the Help Desk with the details about the new rep. A support agent opens a support ticket and fills out what was provided in the email, but has to contact the manager to get additional information. After several back-and-forths, the agent begins to email other teams with the ticket information so that they can fulfill the portions they are responsible for, e.g. Procurement to get the hardware and Application Support to set up accounts. The agent has to manage the disparate fulfillment processes through phone, email and IM. Because of different lead times, it takes 8 days until the agent has everything she needs. Meanwhile the rep starts on day 10. The agent sets up the laptop, logs in as the new rep, sets up the applications, and ensures access. She then works with shipping to get the “office setup” sent to the new rep. The new rep receives everything after 13 days.
• Tier 5: The manager submits an Onboarding request through the Self Service portal, filling out all required information, including choosing available hardware stored in the system by department. The system also contains a master list of applications by department. The system’s fulfillment workflow for Onboarding sees the new rep is part of Sales, orders the Sales laptop automatically from Procurement, and auto-provisions all enterprise-wide and sales specific applications. Procurement uses Asset and Inventory management, and has hardware in-stock for such requests. The hardware is delivered to the Service Desk, and an Agent, who owns the master request, sets up the laptop for the rep and confirms the application access that has already been provisioned. The entire process takes 2 days. The Agent works with shipping to ensure the “office setup” is delivered the day the rep starts their position with the company. The system, based on the request, keeps a record of all hardware and application access received, and uses that data for managing shutoffs and reclamations when the sales rep transfers to another department or leaves the company. Management uses the requester’s and fulfiller’s departments and cost centers to report on how much service is being provided, and to whom, to manage budgets and do chargebacks.

Tier 1 vs. Tier 5

Tier 1

Characterized by:

• Lack of self-service
• Centralized help desk
• Unrelated tickets
• Tribal knowledge
• “Catch as catch can” prioritization and resolution

Tier 5

Characterized by:

• Multiple service channels
• Distributed, specialized support groups
• Prioritized and correlated ticket queues
• Synchronization between core data, knowledge and CMDB to align, diagnose and resolve and fulfill
• Automation, orchestration and integrations to fulfill and synch systems

What I hope is an obvious conclusion from all this is that ServiceNow is able to achieve all these tiers. Many systems that were designed as ticketing systems first can reach the first, second or perhaps third tier, but struggle to achieve the goals of tiers four and five. Because ServiceNow was designed as a platform first, and ticketing, specifically ITSM ticketing was layered on top, it is flexible enough to achieve any desired level. When Service Management is viewed holistically – from a platform perspective and not just a series of unrelated operations applications – it has the ability to help your company become a strategic leader in your industry. (Wow this sounds terribly like marketing – sorry about that!) So why drive a Cadillac? This is why!

Happy transforming!

I had a client recently refer to ServiceNow as a “Cadillac Escalade”, and that they “just needed a Kia”. This is certainly a long way from when I started at ServiceNow in 2010 and the company and the platform was still just emerging from its “gutsy startup” phase. We’ve now reached the point where ServiceNow has become a “gold standard” in cloud platforms and Service Management, and customers are having to decide if they can afford such a high-end solution.

Anyone who has spent time in business realizes that many decisions are made strictly on financial conclusions, or at the least, what is the minimum required solution for the minimum price. While this exercise is black and white, it’s often overly simplistic and short-sighted.

I’d like to use the remainder of this article to talk about the decisions made about using ServiceNow as your Service Management platform: What do you get out of it, what do you want to get out of it, and are you thinking about both in the right way?

Deciding what Service Management is to your business

For much of IT’s history in business environments, upper management’s view of it (and often the whole company’s) is mainly or purely operational: While it automates a previously manual process, it is there simply to “keep the lights on”, and isn’t core to the company strategy. As a subset of IT, Service Management serves the same function: Ensure people can do their work, and speed up the process of getting people what they need where possible.

Only recently have I started to see a shift in philosophy where companies and company decision-makers start to view IT and Service Management strategically: How can this business function actually be leveraged to make us more competitive, increase our margins, allow our people to focus on strategy and not day-to-day repetition. Let’s explore what this means. The following image shows the upward pyramid of Service Management from operational to strategic:

Here’s each tier in greater detail:
Tier 1
Organizations have a central mechanism for taking in issues and requests, assigning them, and working them through to completion. Issues and requests are lumped together; customers and fulfillers view everything as a “ticket” to get reported and completed. Processes are manual: the customer calls or emails, queue managers or general fulfillers assign out the work. No SLAs are defined or tracked – work is done “catch as catch can”. Knowledge and solutions are tribal. No CMDB exists or is leveraged for ticket alignment. No attempt to recognize patterns or recurrences. Reporting is basic and often compiled and manipulated “just in time”.

Tier 2
The central mechanism begins to delineate between types of requests, and defining SLAs around each. For example, an issue preventing a person or persons from doing their job is prioritized over a request for a new software installation. Customers have other interfaces to submit and view their issues and requests – portal, mobile apps, etc. Fulfiller queues become better defined and therefore easier to assign. Management starts to standardize reporting and it becomes more real-time in nature. Knowledge begins to be documented. A CMDB is started for aligning issues and requests with physical and logical infrastructure. Fulfillers begin to recognize and report patterns.

Tier 3
Based on information in submissions, some routing is automated, bypassing the initial queue. SLAs begin to be used to measure performance and enforce accountability. The customer experience becomes both broader and more intuitive – more information and paths to get service exist, but the interfaces are easy to navigate and the correct information is presented at the correct place and time. The CMDB becomes core to understanding and analyzing the service environment – where are issues arising and how is it tied to the broader environment? Reporting starts to move up and down the enterprise hierarchy and is not just limited to single service areas or tiers. Knowledge management processes become defined to ensure knowledge is relevant and up-to-date.

Tier 4
The service desk becomes de-centralized as the CMDB and other mechanisms define and route tickets to the correct initial fulfillment groups (bypassing the generic “service desk” or “help desk”). Correct and available knowledge begins to deflect ticket creation as customers are able to self-serve. Other tickets, particularly requests, are auto-fulfilled (require no human interaction) with orchestration. CMDB relationships are defined allowing fulfillers to see impact across services and the enterprise infrastructure.

Tier 5
All ticket types are defined based on the information presented and the service required – the “right tool to get the job done”. SLAs are defined by type and measured, viewed and accountability exists for meeting them. Almost every submission is routed to a minimum level 2 support group based on the information provided. Fulfillment flows are defined and automation/orchestration is used wherever possible, and fulfillment flows are not implemented without exploring and understanding what automation is possible. CMDB and core data drive the routing, the fulfillment flows and the reporting. Fulfillers leverage the CMDB relationships to understand issues and change impacts across the enterprise. Reporting can be done from the fulfillment teams and ticket type level all the way up to the enterprise, based on available core data. All opportunities for self service and ticket deflection mechanisms are implemented and exposed to the customer. Knowledge is cultivated, managed, standardized and available to the correct audiences. The service management system becomes a system of record for all services delivered and aligns with systems of truth for devices, licensing and access.

Where do you want to be in this tiering?

As stated earlier, it’s much easier to do a cost-benefit analysis of Tier 1. But the real ROI comes from leveling up towards Tier 5. ServiceNow’s flexibility allows you to reach any of these tiers, so a goal of Tier 5 is very attainable. When your employees are no longer focused on day-to-day operational concerns, but rather focus their energies on business improvement, strategic initiatives and outside the box thinking, your business becomes a leader.

In Part 2, we’ll examine the key differences between Tier 1 and Tier 5.