GlydePath Insights

Why AI Planning on ServiceNow Starts With Your CMDB | GlydePath

jamie@glydepath.com.au (Jamie Douglas) — Sat, 07 Nov 2026 03:19:58 GMT

Most AI planning starts in the wrong place: a use case, a demo, a vendor pitch. On ServiceNow, the better starting point is your CMDB, because every AI capability you build depends on it for context, and AI Control Tower now gives you a structured way to plan, assess, and govern use cases before a single agent gets built.

Why does most AI investment fail to pay off?

RAND Corporation's analysis of more than 2,400 enterprise AI initiatives found over 80% fail to deliver the business value they promised, roughly twice the failure rate of a typical IT project. The pattern behind that number matters more than the number itself: research across multiple independent studies keeps landing on the same root cause, and it isn't the model. It's governance. No agreed definition of success before the project started. No risk read before anyone built anything. No named owner once the initial sponsor moved on.

That's the gap AI Control Tower is built to close, and closing it is worth something on its own, before a single agent gets built. A structured intake and risk assessment that kills or reshapes a bad use case in week one is cheaper than discovering the same problem after six months of build.

Why does AI planning keep stalling before it starts?

Most organisations we assess have the same problem: ideas for AI live in Slack threads, slide decks, and someone's notebook. There's no single place to see what's been proposed, what's approved, what it's expected to deliver, or what it depends on. Without that, "AI strategy" is really a collection of disconnected pilots competing for budget and attention.

ServiceNow's answer to this is AI Control Tower: a structured intake, assessment, and governance layer purpose-built to link AI initiatives back to actual business goals rather than tracking them as isolated projects.

What does Control Tower's out-of-the-box process actually look like?

A business user submits an AI use case through the Employee Center, describing the business goal and linking the systems and Datasets it depends on. Those Datasets should already carry sensitivity metadata, PII, PHI, ownership, before the use case ever gets submitted. From there, an AI Steward runs the AI Impact Assessment, and the platform classifies the use case as minimal, limited, or high risk. High-risk or non-compliant use cases get flagged for Steward review before anything gets built.

That classification depends on data that's already been classified. If your Datasets don't carry sensitivity metadata yet, the assessment is guessing.

For an Australian organisation, that assessment can link back to the Privacy Act, the Australian Privacy Principles, or sector rules like APRA CPS 230. The templates ship with global frameworks like the EU AI Act and NIST AI RMF pre-loaded too, useful if you operate across borders, but the local frameworks are the ones that actually apply to most of our clients. The point is that risk and privacy get assessed early in the lifecycle, before development starts, not retrofitted after something's already live.

Why does the CMDB matter more than the AI model?

Every AI capability acts on information objects (data sets, the structured data your business applications hold and exchange) and CIs that live somewhere. It needs to know what a service is, who owns it, what depends on it, and what it's allowed to touch. That's exactly what the CMDB already holds, assuming it's accurate.

ServiceNow's own field guidance on this is blunt: successful teams don't chase the most advanced AI capability first. They identify three to five priority use cases, then clean and validate the CMDB data those use cases actually depend on, before building anything. Get that sequence backwards and you get an agent making confident decisions on top of stale ownership data and orphaned CIs. That's not a model problem. It's a foundation problem wearing an AI costume, the one we cover in detail in Why Your ServiceNow CMDB Is Lying to You.

CSDM 5.0 also now has two dedicated CI classes for this: AI Function, for AI hosted externally, and AI & Model Application, for AI built and hosted in-house. Every AI asset should be traceable through your CMDB the same way a server or an application is, with lineage, ownership, and a lifecycle state, not sitting off to the side in a spreadsheet someone updates occasionally.

What does an information object need before AI can touch it?

Knowing an information object exists isn't the same as knowing what's safe to do with it: what's sensitive inside it, who's allowed to touch it, and which rules govern it.

A few organisations have already solved that classification problem properly. NC State University added data classification tables directly into their CMDB, tagging systems and data by sensitivity tier, specifically to meet a state government data-security standard. That's the pattern worth copying: your CMDB shouldn't just record what a system is. It should record how sensitive the data behind it is, which security standard governs it, and which other applications touch it. When an AI use case comes through Control Tower's intake process, that classification is exactly what should be feeding the risk assessment, not a separate exercise someone does by memory.

Where do you actually start?

Cleaning up your CMDB and classifying your information objects shouldn't happen off to the side, separate from the rest of your roadmap. AI is going to shape how your ServiceNow platform evolves over the next several years, not just the next project, so it belongs inside your existing roadmap, not next to it as a separate stream of work. Treated as its own thing, it's easy to lose sight of automation that doesn't need AI at all: every AI call carries a token cost, and a good share of what looks like an AI opportunity is really a flow with the right spokes wired up, something that costs nothing extra to run once it's built. That trade-off, cost, effort, and whether a model is actually required, deserves the same evaluation rigour as anything else on the roadmap, and it's worth its own article.

For the AI side specifically, three things, in order:

Get your CMDB Health score. It's in CMDB Workspace → Management → CMDB Health. If completeness and correctness sit below eighty percent on your business-critical classes, fix that before any AI use case goes near those services. That's the starting point of a CMDB Excellence engagement, if you'd rather have someone else run the assessment.
Pick three to five use cases, not thirty. Bring them through a structured intake, even a simple one, that captures the business goal, the data it touches, and a basic risk read, before anyone starts building.
Classify sensitivity at the information object level. If you don't know which of your data is sensitive, or which standard governs it, that has to happen before AI touches it, not after.

Last updated: 22 July 2026. This article covers ServiceNow's AI Control Tower and CMDB capabilities as they currently stand and will be revisited as the platform evolves.

If you want a clear read on where you stand, we run a roadmap that covers three things together: AI use case identification with real ROI calculations, a CMDB health assessment specific to what those use cases would depend on, and a broader automation review, so the highest-value work that doesn't need AI at all doesn't get missed. Book a platform assessment.

CMDB Remediation: Where to Start When Everything Is Broken | GlydePath

jamie@glydepath.com.au (Jamie Douglas) — Sat, 07 Nov 2026 02:34:15 GMT

The most common mistake in CMDB remediation is trying to fix everything at once. The second most common mistake is fixing the data before fixing the governance.

Both errors lead to the same outcome: a remediation project that improves the CMDB for six months and then reverts to its previous state, having consumed significant budget and goodwill in the process.

Here is the approach that actually works.

Start with governance, not data

Before touching a single CI record, answer three questions:

Who owns the CMDB? Not "which team is responsible for it," but who is the named individual with authority to make decisions about the data model, CI lifecycle rules, and quality standards? If the answer is ambiguous, remediation will be undermined at every step.

What are the quality success criteria? "Better" is not a success criterion. What CI classes need to be accurate? What accuracy level is acceptable? What does the ongoing measurement look like? Without defined criteria, remediation is a project with no completion condition.

How will ongoing quality be maintained? If the answer is "we'll sort that out after the remediation," you are planning to repeat this engagement in two years. The maintenance model needs to be designed as part of the remediation, not deferred.

Identify the CI classes that actually matter

Every organisation has a CMDB with dozens of CI classes. Most of them are not business-critical. The remediation effort should be concentrated on the classes that downstream services depend on.

Top tip

A reliable shortcut: pull the last thirty days of P1 and P2 incidents and look at what CI classes were referenced in the impact assessment. Those are your critical classes. Everything else is secondary.

In most mid-market organisations, the business-critical CI classes are:

Business applications (the services the business actually uses)
Infrastructure that supports those applications (servers, databases, network)
The relationships between them (the CMDB relationships that make impact analysis work)

Everything else, such as physical locations, printers, and mobile devices, can be remediated in a second phase if it matters enough to prioritise.

Discovery versus manual reconciliation

Discovery tools are good at finding things. They are not good at deciding what to do with what they find when it conflicts with existing records. Manual reconciliation, meaning a human reviewing discovery findings against existing CI data, is the step that organisations most frequently skip, and the one that determines whether the remediation actually results in accurate data.

The architecture of the reconciliation process matters as much as the data quality rules. Who reviews reconciliation exceptions? On what cadence? What happens to discovery-found devices that have no matching CI? These decisions need to be made before discovery runs, not after.

Quick wins that restore confidence

Remediation projects lose momentum when early progress is not visible. Identify two or three quick wins that can be demonstrated in the first four weeks:

A specific CI class that is small enough to remediate completely and important enough to matter
A quality metric that is currently red and can be moved to amber with targeted effort
A downstream use case, such as incident routing or change impact analysis, that visibly improves when the underlying data is corrected

Demonstrating real improvement early maintains the organisational will to continue.

The governance model that makes it stick

The remediation project ends. The CMDB governance model does not. What you need by the end of the engagement is:

CI lifecycle rules: documented criteria for creation, modification, and decommission of each critical CI class, with named owners for each rule.

Quality thresholds and alerts: automated monitoring that flags when quality drops below defined thresholds, going to a named person who has the authority to act on it.

A reconciliation cadence: scheduled review of discovery output against CMDB records, with clear exception handling.

A change control process for the data model: changes to CI class structure, relationship types, and quality rules require the same governance as changes to anything else in the platform.

If you are at the beginning of a CMDB remediation and want an independent assessment of your current state and a recommended approach, we can help.

Architecture-Led Delivery: Why It's Different from a Typical Implementation Partner | GlydePath

jamie@glydepath.com.au (Jamie Douglas) — Sat, 07 Nov 2026 02:32:48 GMT

The Certified Master Architect credential is the highest technical certification ServiceNow issues. There are fewer than seven hundred of them in the world.

<700

Certified Master Architects globally

100%

Certified Architect on every engagement

Most ServiceNow implementation partners will have one or two CMAs. They are involved in pre-sales, they attend the kick-off, they sign off on the high-level design. Then delivery is handed to a team of certified consultants: qualified people, but without the same depth of platform knowledge. The CMA moves on to the next opportunity.

This is the model that produces the outcomes I've seen across years of ServiceNow remediation work. It is not a staffing criticism; it is an economic reality of how large implementation partners work. Senior people are expensive. Keeping them on projects for the full delivery duration compresses margin.

GlydePath works differently because we have to. We are small enough that the CMA on your engagement is also the person doing the work.

What architecture-led actually means

The architect designs it. This sounds obvious. In practice, it is not. Many engagements have a high-level architecture document produced at the start and then a series of configuration decisions made during delivery that are not architectural decisions in the strict sense but that have architectural consequences. An architect who is not in the delivery knows what was designed. An architect who is in the delivery knows what is actually being built.

The architect sees the whole platform. Configuration decisions that are locally reasonable can be globally problematic. A customisation that solves today's problem creates an upgrade barrier. An integration approach that works for one system does not scale when applied to twenty. These interactions only show up if someone is holding the complete picture, not the sub-deliverable they are responsible for this sprint.

The architect makes the hard calls. Technical debt accumulates when the hard calls are deferred. "We'll fix that later." "That is out of scope." "The client wanted it that way." In architecture-led delivery, the architect is present when these moments happen and can make the trade-off explicit rather than invisible. Sometimes the answer is still "we'll fix it later," but it is a documented decision, not an undocumented compromise.

What it means for documentation

Top tip

The documentation test: can someone who was not involved in the engagement pick up the documentation and understand what was built, why specific decisions were made, and what the constraints on future changes are? If the answer is no, the documentation is a liability record, not an asset.

Architecture documentation produced retrospectively, at the end of a project and by someone who was not in the delivery, is reconstruction, not documentation. It gets the what mostly right. It misses the why almost entirely.

Architecture decision records written during delivery capture the context that matters. Why was this approach chosen over the alternatives? What were the constraints? What would need to change if the constraint changes? This is the information that makes platforms maintainable over time.

Every GlydePath engagement produces documentation that meets the test above. It is not a deliverable we add to the statement of work; it is how we work.

The AI angle

We use AI in our own delivery work: design review, documentation drafting, code generation, quality checking. The result is that a small team can move at the pace of a larger one without sacrificing architectural quality.

This is not about replacing architects with AI. It is about letting an architect's time go further: less time on the mechanical parts of delivery, more time on the decisions that require genuine expertise. AI does not know what architectural trade-offs are appropriate for your platform. A CMA does.

What this means for you

If you are evaluating ServiceNow implementation partners, the question to ask is not "do you have a CMA?" Most do. The question is "who is the architect on this engagement, and what does their involvement look like after the kick-off?"

The answer will tell you what you need to know.

If you want to understand what architecture-led delivery looks like for your specific situation, start with a conversation.

AI in ServiceNow: The Use Cases That Deliver | GlydePath

jamie@glydepath.com.au (Jamie Douglas) — Sat, 07 Nov 2026 02:32:31 GMT

There's a gap between the AI conversation in ServiceNow marketing and what actually works for mid-market Australian organisations. Here's an honest field guide to the use cases that deliver, the ones that need a human in the loop, and how we approach them.

What each use case actually does

Service desk triage. This is the most mature use case and the one with the most demonstrable ROI. An AI classifier sits at the point of intake, before a human touches the ticket. The agent picks up a ticket that's already classified, routed and enriched with context — which cuts time-to-assign and lifts first-contact resolution.

The key architectural decision here is how much autonomy to give the AI. We default to AI-suggested routing with human confirmation, not fully automated routing, until the classification confidence data is established. This is the responsible approach, and it is what we recommend.

Knowledge base automation. Drafting knowledge articles from resolved tickets is working well. The AI takes the resolution notes, the closure code, and the ticket context, and produces a structured draft. A knowledge manager reviews and publishes. The result is knowledge bases that are actually current, because the friction of creating articles is low enough that it actually happens.

Catalog item generation. Generating service catalog items from plain-language descriptions is reliable and saves significant time. The AI produces a structured item with description, variables, and fulfillment workflow stub. Someone with ServiceNow configuration knowledge reviews and adjusts. Not a replacement for a catalog architect, but an accelerator.

What needs a human in the loop

Top tip

Any AI that takes action in ServiceNow without human review should be treated as a significant architectural decision, not a default configuration choice. The question is not whether to include humans; it is where in the process to include them for maximum effect with minimum friction.

Change management automation is where we exercise the most caution. AI-assisted change risk scoring is useful. Fully automated change approval for standard changes is a more complex decision that depends on your change process maturity and your organisation's risk appetite. We help clients think through the architecture of human-in-the-loop controls before they are needed, not after something goes wrong.

Incident correlation and major incident identification are areas where AI can add significant value but where false positives are costly. We implement these with human confirmation for anything that would trigger a major incident process.

The data sovereignty question

For Australian organisations, particularly in government, education, finance, and health, data sovereignty is not optional. Any AI implementation needs to answer: where is the data going, who controls it, and what happens if the relationship with the AI provider changes?

Onshore AU

All GlydePath AI hosted

All AI capability we build is hosted in AWS using Anthropic's Claude models, onshore in Australia. No customer data leaves the country. This is not a marketing claim; it is an architectural constraint we apply from the start.

What Now Assist actually delivers

ServiceNow's own AI offering, Now Assist, is maturing. The search and summarisation capabilities are genuinely useful. The generative AI for incident resolution recommendations is improving. Where it falls short is customisation: adapting the AI to your specific organisation's language, processes, and data requires configuration that goes beyond what is available out of the box.

The honest answer is that Now Assist and custom AI capability are complementary, not competing. Now Assist handles the standard cases. Custom AI handles the organisation-specific ones.

Where to start

If you are evaluating AI on ServiceNow, start with service desk triage. It has the clearest ROI, the lowest risk profile, and the best feedback loop for improving AI performance over time. The data you collect from a triage implementation is also directly useful for more advanced AI capability later.

We are happy to assess your platform's AI readiness and talk through what would actually work for your context. Start that conversation here.

The Real Cost of a Bad ServiceNow Implementation | GlydePath

jamie@glydepath.com.au (Jamie Douglas) — Sat, 07 Nov 2026 02:31:31 GMT

The original implementation invoice looks big. In our experience, it is usually the smallest line item in the total cost of a poor ServiceNow delivery.

The rest of the cost is distributed across the organisation in ways that are difficult to attribute but easy to observe: the service desk workarounds that have become process, the modules that are licensed but not used, the IT team that has to manually reconcile data that should be automatic, the upgrade that keeps getting deferred because nobody knows what it will break.

Where the money actually goes

Re-work. The most visible cost. A platform delivered without proper architecture review typically requires significant remediation within two to three years. The customisations that seemed reasonable at the time create upgrade barriers. The data model that worked for the initial scope does not work when the platform expands. In my experience, remediation often costs a large fraction of the original implementation, sometimes approaching it, for a platform that still does not work as well as it should.

Unused licences. ServiceNow licences are not cheap. Platforms implemented without a clear adoption strategy routinely have modules that are in scope and licensed, but that the business never actually used. In my experience, organisations end up paying for years of licences on modules that were configured but never put in front of users, because nobody had the architectural conversation about what adoption actually required.

Workarounds that became process. This is the insidious one. When a platform does not do what people need it to do, people build workarounds. Then the workarounds become muscle memory. Then they become documented process. Then the platform gets fixed, and nobody uses the fix because the workaround is now habit. The cost of unwinding this is underestimated almost universally.

Deferred upgrades. ServiceNow releases two major versions per year. Staying current is not optional in the long run: older versions lose support, new capability requires current releases, and the gap between your version and current widens with every cycle you skip. A platform delivered without upgrade strategy in scope often defers its first upgrade within a couple of years. After three or four deferrals, the upgrade is a major project in its own right, delivered under time pressure, and carries significant risk.

The three questions to ask before signing

Top tip

Before you sign with any ServiceNow implementation partner, ask these three questions: Who is the architect on this engagement, and will they be hands-on throughout delivery? What is the upgrade strategy for the configuration decisions you are making? What does the documentation look like, and who owns it at completion?

The answers are diagnostic. An SI that cannot name a specific architect, defaults to "we follow upgrade best practice" without elaborating, and describes documentation as a project deliverable rather than a continuous practice is telling you something important.

The compounding problem

Technical debt in a platform context compounds differently from technical debt in a software project. In a software project, the debt is mostly in the code. In ServiceNow, the debt is in the configuration, the data model, the integration architecture, and the customisation layer, and all of them interact.

A bad CMDB makes incident routing unreliable. Unreliable incident routing makes SLA compliance difficult to measure. Difficult SLA measurement makes performance management ineffective. The cascade is real and the cost at each step is real.

Starting well costs more upfront. Not in licence fees, but in the quality of the architectural work. But it is consistently cheaper over a five-year horizon than starting cheap and remediating over the same period.

If you are assessing an existing platform or evaluating a new implementation, we are happy to give you an independent read. Start with a conversation.

Why Your ServiceNow CMDB Is Lying to You | GlydePath

jamie@glydepath.com.au (Jamie Douglas) — Sat, 07 Nov 2026 02:30:31 GMT

A CMDB nobody trusts is not a data problem. It is a governance problem wearing a data problem's clothes.

This distinction matters because organisations keep trying to solve it with technology. Better discovery tooling. More integrations. A fresh import. What they get is fresh inaccurate data arriving faster than before.

What actually goes wrong

The pattern is consistent across almost every platform we assess:

Discovery runs, but nobody owns reconciliation. ServiceNow's Discovery tool is excellent at finding things. It is not good at deciding what to do when what it finds conflicts with what is already in the CMDB. That decision requires a human with authority, and in most organisations, that human does not exist.

CI lifecycle has no owner. Configuration items are created (often correctly) and then never decommissioned. Servers get retired, the CMDB record stays active. Applications get sunset, their CIs remain. In the platforms we assess, it's common to see a large share of CI records go stale within eighteen months, often well over half.

The data model grew organically. What started as a clean class hierarchy became a negotiation with every team that wanted their things in the CMDB slightly differently. Now you have six different ways to represent a server and no canonical definition of what a "service" actually is.

Nobody checks the quality metrics. Most platforms have ServiceNow's built-in CMDB Health dashboard available. Most administrators have never looked at it. The score is not great. Nobody knows.

Why this matters more now

Top tip

If you are planning to implement any AI capability on top of your ServiceNow platform, your CMDB is the first thing to fix. AI-driven triage, change impact analysis, and cost allocation all depend on configuration data being accurate. Garbage in, garbage out, only faster.

Every downstream service depends on CMDB accuracy. Incident routing relies on it. Change impact assessment relies on it. Cost allocation reports rely on it. When AI enters the picture, and it is entering the picture, the dependency compounds. An AI that routes incidents based on stale service ownership data makes confidently wrong decisions at scale.

Three things to check this week

You do not need a full remediation engagement to get a read on where you stand. Start here:

Check your CI count trend. Pull a report of CI records created vs decommissioned over the last twelve months. If the gap is growing, you have a lifecycle problem.

Run the CMDB Health dashboard. It is under Configuration → CMDB → Health. Read the completeness and correctness scores. If they are below eighty percent, the platform is lying to everything built on top of it.

Find one business-critical service and trace it. Pick something that matters: payroll processing, customer onboarding, a core IT service. Map every CI that supports it. Ask a human who actually runs that service whether the map is accurate. The answer will tell you what you need to know.

What good looks like

A well-governed CMDB is not a perfect CMDB. Perfect is the wrong goal. What you want is a CMDB with known quality: one where the business-critical CI classes are accurate and governed, the quality metrics are monitored, and the remediation backlog is prioritised and visible.

That state is achievable in most organisations. It requires architectural design, not just tooling. And it requires someone owning it continuously, not just at project kickoff.

If you want an honest read on where your platform sits, we offer a platform assessment that covers CMDB specifically: a short call, then a read-only script your admin runs, and you get a written report, not a sales deck.

What a Platform Excellence Partnership Actually Looks Like | GlydePath

jamie@glydepath.com.au (Jamie Douglas) — Sat, 07 Nov 2026 02:25:12 GMT

The phrase "ongoing support retainer" covers a lot of ground in the ServiceNow world. Some of it is a block of hours you can use for incidents and small enhancements. Some of it is a named resource who is nominally available but usually busy on other clients. Almost none of it is what we mean when we say Platform Excellence Partnership.

Here is what ours actually involves.

The monthly health scan

Every month, your platform is assessed against ten domains and 50+ metrics. Configuration hygiene, CMDB integrity, upgrade readiness, integration health, and AI readiness are scored, trended, and reported.

95/100

Anchor client platform health score

Domains assessed every month

50+

Metrics assessed every month

The score matters less than the trend. A platform at sixty-five and improving is in a better position than one at eighty-five and declining. What we are tracking is trajectory, and surfacing the things that will become problems before they become incidents.

The governance cadence

Each month there is a structured conversation with your platform owner. Not a status update but a decision meeting. We work through:

The health scan findings and what to do about them
The enhancement backlog and how to prioritise it
Any architectural decisions that need to be made before they get made by accident
What is coming in the next ServiceNow release and what it means for your configuration

This is the conversation most platforms never have. Without it, architectural decisions get made by whoever raises a ticket and whoever happens to pick it up. The platform drifts. Technical debt compounds quietly until it is expensive to fix.

What the architect actually does

The partnership includes a dedicated Certified Architect: the same person, consistently. Not a ticket queue staffed by whoever is available.

Your architect reviews every significant platform change before it goes to production. Not as a bureaucratic gate, but as a genuine architecture review that catches the problems that are much cheaper to fix before they are deployed than after.

Top tip

The most common thing we catch in architecture reviews is not bugs; it is configuration choices that work fine in isolation but create problems when the platform is upgraded or when another team makes a seemingly unrelated change. This is the kind of thing that only shows up if someone is holding the whole picture in their head.

Your architect is also available for design questions: the kind that come up in the middle of a project and need a quick answer from someone who understands the platform deeply, not a ticket that comes back in three business days.

Enhancement delivery

The partnership includes structured delivery of improvements within the retainer. Not a separate project, not separately scoped and separately billed for routine enhancement work. This is what makes the model work for clients: the friction between identifying an improvement and delivering it is low.

Significant new capability, such as a new module, a major integration, or a custom AI implementation, is scoped and delivered separately. But the ongoing work of making a platform better is included.

Why retainer beats project for platform work

A platform delivered as a one-time project and then handed to an operations team tends to drift. The operations team is skilled at keeping the lights on, not at architectural evolution. The SI who built it moves on to the next project.

What the platform needs is someone who is always current: always watching the trajectory, always seeing the next ServiceNow release coming before it arrives, always available when an architectural question needs answering.

That is the model. If it sounds like something your platform needs, start with a conversation.