ServiceNow implementations typically start with platform configuration — modules are set up, workflows are built, forms are designed. The process questions come later, when something does not work as expected or when users find workarounds that bypass the intended flow. By then, the configuration is done and changing it is expensive.

We flip the sequence. Before any configuration work begins, we run a process design sprint that documents the target ways of working in enough detail to drive implementation decisions. Who owns which step. What triggers an escalation. Where approvals are required and by whom. What happens when an exception occurs. These are not abstract questions — they are the decisions that determine whether ServiceNow reflects how your organization wants to work or simply digitizes the confusion that already exists. The sprint produces validated process documentation that serves as the implementation specification — and as the governance reference once the platform is live.

Compliance, Risk, Operations and Quality teams own the processes — they define what should happen, why, and under what controls. IT owns the workflows — they build what actually runs in the platform. When these two groups do not share a common reference, the result is predictable: configured workflows that drift from the governed process, audit findings that surprise everyone, and a CMDB that nobody fully trusts because it was populated by IT without process ownership input.

We work at exactly this seam. Our enterprise architecture practice means we can sit with process owners and capture what genuinely needs to be controlled, then translate that into workflow and CMDB requirements that IT can implement without losing the governance intent. The CMDB becomes the shared reference point — and this is also where the business case for governed execution becomes tangible: modelling processes on paper rarely closes the ROI conversation, governed and traceable execution does.