Latest Articles

Headline: Don't Use All Change Categories at Once — A Progressive Implementation Approach The Temptation of All Categories Most ITSM frameworks define three change categories: Standard, Normal, and Emergency. However, the right number of categories depends on your organization's volume and maturity, not simply on framework compliance. A Progressive Approach Start with Normal changes to calibrate the process. When beginning change management, start by classifying all changes as Normal. This allows you to: Define the process Establish roles Build change management muscle Understand your change landscape Graduate proven procedures to Standard status. Once a change type has been consistently successful, move it to Standard status: Criteria for Standard status Evidence Proven success No incidents from implementation Repeatable Same process each time Well documented Clear work instructions Trained personnel Certified staff Establish Emergency workflows for urgent situations. Identify what constitutes an emergency and establish expedited approval processes. Add categories only when volume justifies them. Resist the temptation to add categories for the sake of having them. Change Type Progress Stage Categories Description 1 Normal only All changes go through the same process 2 Normal + Standard Proven changes become Standard 3 Normal + Standard + Emergency Emergency processes added 4 Full ITIL categorization All three with mature processes The Normal Change Process Submit Request for Change Review for necessity Assess risks CAB approval (or Change Authority) Implement Test Review Document The Standard Change Process Pre-approved Requires no CAB Automated or documented runbook Scheduled and tracked Reviewed periodically The Emergency Change Process Expedited approval ECAB review Implemented immediately Reviewed post-implementation Conclusion Implementing change categories progressively ensures your process evolves with your organizational maturity. Start simple, learn what works, and add complexity only when needed. Action Items for Your Organization Start with Normal changes only Identify changes that could become Standard Document Standard change procedures Establish Emergency change workflows Add categories gradually

The AI Gold Rush Has a Shadow Problem Your organization is probably already using AI in ITSM. According to recent research, 93% of IT professionals report their organizations are open to using AI agents in service management. The enthusiasm is understandable—AI promises to slash resolution times, automate routine work, and free your team for higher-value tasks. But here is the uncomfortable truth hiding behind the excitement: 45% of IT leaders cite AI governance, data security, and privacy as their top concern when deploying AI in ITSM. That outranks even reliability fears (39%) and implementation complexity (34%). The situation becomes genuinely alarming when we look at autonomous AI agents. While 92% of executives report moderate or widespread use of autonomous AI agents, only 22% say their organizations have proper identities tied to those agents. This isn't a governance gap—it's a governance chasm. To put it in perspective: you wouldn't give every new employee unrestricted administrative access on day one without vetting, training, or oversight. Yet that's precisely what many organizations are doing with AI agents—except these "employees" work at machine speed, never sleep, and can execute thousands of operations before anyone notices a problem. The security implications are profound. An AI "assistant" in ITSM can be flipped from "recommend" mode to "auto-execute," quietly approving risky firewall rules and configuration changes without anyone noticing—until something catastrophic happens. A classic blind spot: an ungoverned AI account with production-level powers and no paper trail for who enabled it, what it can touch, or how to shut it down safely. This is what we mean when we say AI governance is the unglamorous foundation of ITSM success. It doesn't generate headlines. It doesn't demo well at conferences. But it will absolutely make or break your AI program. What Happens When You Treat AI as "Just Another Feature" The fundamental mistake many organizations make is treating AI as a feature rather than an identity—a new class of digital worker that operates at machine speed and scale. Problem 1: The Non-Human Identity Blind Spot Most identity and access management (IAM) programs were built around people, not machines. The result? AI agents often: Run with shared secrets, tenant-wide tokens, or unchecked API keys Rarely appear in access reviews or certifications Would not trigger any alert if their scope quietly expanded Operate without individual accountability or access logging Every time an AI system can change state in a production system—open tickets, route incidents, merge code, execute transactions—you have effectively created a new operator. Yet most organizations lack full visibility into what these "digital workers" can access and modify. Consider this: if an AI agent can reset passwords, grant permissions, and modify configurations, it effectively has the same privileges as a senior system administrator—but without the training, oversight, or accountability we would demand from a human in that role. Problem 2: The Accountability Void Imagine an AI-driven automation accidentally takes down a business-critical service. Who is on the hook? The developer who originally wrote the script? The manager who green-lit the automation? The vendor that provided the AI platform? The AI itself? If you can't answer this question with certainty, you have a serious governance gap. Without clearly defined accountability, crisis response devolves into finger-pointing exactly when you need decisive action most. This is not a hypothetical scenario. As autonomous AI agents gain the ability to execute actions across your ITSM toolchain, the "blast radius" of a mistake grows exponentially. A human error might affect one or two tickets. An AI error could misclassify thousands of incidents, send sensitive data to the wrong teams, or execute unauthorized changes across your entire infrastructure. Problem 3: Shadow AI Sprawl The most insidious problem is shadow AI. AI capabilities are already embedded in many workflows, often undocumented and ungoverned. Development teams are using tools like Claude Code connected to GitHub and Jira with static tokens stored on local developer machines. Companies are using AI agents, but they've done so in a haphazard, non-secure way. This creates three persistent friction points: Shadow AI: Already exists in many workflows, undocumented and invisible to security teams Retrofit governance: Controls added after deployment, creating risk and expensive rework Explainability gap: Nobody can answer, "Why did the AI make that choice?" The challenge is compounded by the speed of AI adoption. According to a survey of IT decision-makers, 56% said the increased speed of AI adoption has caused their organizations to deprioritize security in favor of innovation. This trade-off is dangerous—especially in regulated industries where compliance failures carry severe penalties. The Financial Reality: Poor Governance Is Expensive Before we dive into solutions, let's be clear about what's at stake. Poor AI governance isn't just a technical risk—it's a financial one. Operational costs: Misconfigured AI agents can create cascading failures that require extensive manual cleanup Compliance fines: GDPR, HIPAA, and the EU AI Act all impose significant penalties for AI-related violations Reputational damage: High-profile AI failures erode customer and stakeholder trust Wasted investment: Organizations with weak governance often abandon AI initiatives after costly failures Shadow IT costs: Undocumented AI tools create hidden maintenance and security burdens The EU AI Act, which came into force in 2024, imposes fines of up to €35 million or 7% of global annual turnover for violations involving prohibited AI practices. This isn't theoretical risk management—it's a regulatory reality that demands attention. The Four Pillars of AI Governance That Matter Effective AI governance rests on four foundational pillars. These are not optional niceties—they are essential requirements for any organization serious about deploying AI in ITSM. Pillar 1: Transparency and Explainability AI that operates as a black box is fundamentally unmanageable. If you can't understand it, you can't control it—and if you can't explain it, you can't trust it. What this means in practice: The system must document its reasoning in language humans can understand Build human checkpoints for high-stakes decisions Configure AI to recommend actions but require human approval before execution Maintain audit trails that clearly show which AI agent made which decision and why When evaluating ITSM tools, explainability must be your deal-breaker. Can the system explain why a ticket was assigned to a specific resolver group? Can it show the reasoning behind a proposed solution? Can you trace every action back to a specific AI instance and prompt? Pillar 2: Identity and Access Management for AI AI agents require their own identity lifecycle management—separate from human users. This means: Provisioning: Each AI agent needs a unique identity with clearly defined permissions Access reviews: Regular certification of AI agent access rights Least privilege: AI agents should only have the minimum permissions needed for their task Lifecycle management: When an AI agent is retired, its access must be revoked Monitoring: Continuous observation of AI agent behavior for anomalies Organizations should treat AI identities as they would treat privileged human accounts—with rigorous controls, regular reviews, and immediate revocation when no longer needed. Pillar 3: Data Governance and Privacy AI systems are voracious consumers of data. They need access to training data, operational data, and user interactions to function effectively. This creates significant privacy and security challenges. Critical requirements: Data minimization: Only provide the data the AI needs for its specific function Classification: Understand what data the AI can access and why Sensitive data handling: Implement controls for PII, PHI, and other regulated data Data lineage: Know where data came from and where it flows Retention policies: Ensure AI doesn't retain data longer than necessary A common mistake is giving AI agents broad access to data "just in case." This violates the principle of least privilege and dramatically increases the risk of data exposure. Pillar 4: Continuous Monitoring and Human Oversight Autonomous AI agents are not set-it-and-forget-it tools. They require ongoing oversight, monitoring, and adjustment. Essential practices: Real-time monitoring: Track AI actions and flag anomalies immediately Performance reviews: Regularly assess AI accuracy and effectiveness Feedback loops: Incorporate human feedback to improve AI performance Kill switches: Ability to immediately halt AI operations if something goes wrong Regular audits: Formal reviews of AI governance practices Creating Your AI Governance Framework: A Practical Roadmap Implementing AI governance doesn't have to be overwhelming. Here is a practical approach: Phase 1: Assessment (Weeks 1-4) Inventory: Identify all existing AI agents and capabilities in your ITSM environment Risk assessment: Evaluate the potential impact of AI failures Gap analysis: Compare current practices against the four pillars Stakeholder mapping: Identify who needs to be involved in governance Phase 2: Foundation (Weeks 5-12) Policy development: Create clear policies for AI use, access, and oversight Identity setup: Implement proper identity lifecycle management for AI agents Monitoring implementation: Deploy tools to track AI behavior Training: Educate teams on responsible AI use Phase 3: Scaling (Months 4-6) Integration: Embed governance into existing ITSM processes Automation: Automate governance tasks where possible (access reviews, monitoring) Continuous improvement: Regular reviews and updates to governance framework Expansion: Apply governance to new AI use cases The Bottom Line: Governance Is Not a Brake—It's an Accelerator Here's the counterintuitive truth that successful organizations have discovered: strong governance accelerates AI adoption rather than hindering it. When your teams have clear guidelines, well-defined boundaries, and confidence in the security and compliance of their AI tools, they move faster. They experiment more confidently. They innovate without fear of creating massive operational or security problems. Conversely, weak governance creates friction. Security teams block AI initiatives because they can't assess the risk. Compliance teams slow deployments because they can't certify the controls. Leaders hesitate to invest because they can't predict the outcomes. The organizations leading in AI are not the ones taking the most risks—they are the ones with the most mature governance frameworks. Conclusion: The 78% That Will Define the Next Wave of AI Innovation With only 22% of organizations having proper identities tied to their AI agents, there's a massive opportunity for the other 78% to get governance right. Those that do will unlock the full potential of AI in ITSM—faster resolution times, improved employee experience, and reduced operational costs—without the security and compliance nightmares that plague their less-prepared peers. The AI governance and security conversation isn't about slowing down innovation. It's about ensuring that innovation is sustainable, secure, and trustworthy. It's about building an AI practice that can grow and scale without creating unmanageable risk. The unsexy work of governance is, paradoxically, the most exciting opportunity in ITSM today. It's where you'll find the competitive advantage that AI itself promises—not in the AI, but in the disciplined, strategic approach to making it work safely and effectively. Call to Action Ready to assess your AI governance readiness? Start with these three questions: Can you list every AI agent currently operating in your ITSM environment? Do you know exactly what data each AI agent can access and what actions it can perform? Could you immediately disable any AI agent if it started behaving unexpectedly? If you can't answer "yes" to all three, your governance journey needs to begin today.  

A Supervisor Agent, a Network Investigator, an Observability Expert — and No Human Involved Until the Report Is Ready The Multi-Agent Revolution Single AI agents are powerful. But multi-agent systems—where multiple specialized AI agents work together—are transformative. Booz Allen has deployed a multi-agent AI system that autonomously triages, validates, investigates, and provides resolution steps the moment an incident ticket is filed. Engineers get a clear summary of findings and recommended actions before they even start their review. The Architecture The Supervisor Agent Pattern The supervisor agent orchestrates the entire process: Receive: Incident ticket is filed Dispatch: Supervisor distributes tasks to specialized agents Aggregate: Supervisor collects and synthesizes results Deliver: Supervisor provides complete incident analysis to human team Specialized Worker Agents Agent Responsibility Contextualization Agent Gathers and summarizes incident context from multiple sources Observability Agent Analyzes metrics, logs, and traces to identify patterns Network Investigation Agent Identifies network-related issues and dependencies Evaluation Agent Assesses the impact and severity of the incident How It Works in Practice Step 1: Incident Filed A user submits a ticket: "Application is slow." Step 2: Supervisor Agent Receives Supervisor agent receives the ticket and dispatches to specialized agents. Step 3: Parallel Investigation Agent Action Contextualization Agent Gathers application details, recent changes, similar past incidents Observability Agent Checks metrics, logs, and traces for anomalies Network Investigation Agent Checks network connectivity, latency, and dependencies Evaluation Agent Assesses impact, severity, and urgency Step 4: Results Aggregated Supervisor agent collects all findings and synthesizes them. Step 5: Report Delivered Engineer receives a complete analysis with findings and recommendations before reviewing the ticket. The Benefits of Multi-Agent AI Benefit Impact Parallel processing Multiple investigations happen simultaneously Specialization Each agent focuses on what it does best Complete analysis Multiple perspectives ensure comprehensive understanding Faster resolution Engineers get analysis immediately Better decisions Findings from multiple agents provide better intelligence Implementation Considerations 1. Agent Orchestration How will agents communicate and coordinate? Options: Centralized supervisor (as above) Decentralized (agents collaborate directly) 2. Agent Specialization What specialized agents do you need? Common specializations: Observability analysis Network investigation Log analysis Dependency mapping Impact assessment 3. Agent Handoffs When should one agent hand off to another? Options: Supervisor-driven (supervisor dispatches) Agent-driven (agents collaborate directly) Hybrid (both patterns) 4. Error Handling What happens when an agent fails or returns uncertain results? Real-World Impact: Booz Allen Booz Allen's multi-agent system has achieved: Zero response time to file (analysis is complete before human review) Comprehensive analysis (multiple perspectives) Improved decision quality (findings from specialized agents) Conclusion: The Future Is Multi-Agent Single AI agents are useful. Multi-agent AI systems—where specialized agents work together under orchestration—are transformative. They provide complete analysis, faster insights, and better decisions. The multi-agent future of incident triage is here. Is your organization ready? Action Items for Your Organization Identify specialized capabilities: What incident analysis tasks could be automated? Design the architecture: How will agents communicate and coordinate? Implement supervisor: Build the orchestration layer Develop specialized agents: Build or integrate specialized capabilities Test and refine: Validate and improve the system  

Stop Blaming, Start Learning — Why Blameless Postmortems Are the Foundation of Incident Mastery The Blame Trap Something goes wrong. The system fails. Users are impacted. The natural human response: Who caused this? Who messed up? Who can we blame? This is the blame trap. It feels satisfying in the moment—you've identified the "bad guy." But it doesn't prevent recurrence. The same problem will happen again. The same people will be blamed again. Blameless postmortems break this cycle. What Is a Blameless Postmortem? A blameless postmortem is an incident review that focuses on what happened and how to prevent recurrence, not on who caused it. The Blameless Principle The principle is simple: Systems fail, not people. When a person makes a mistake, it's because the system allowed it. The question isn't "Who made the mistake?" It's "Why did the system make that mistake possible?" Why Blameless Postmortems Work 1. They Enable Learning When people fear blame, they hide mistakes. When mistakes are hidden, we can't learn from them. Blameless postmortems create psychological safety: people share what happened honestly because they know they won't be punished. 2. They Identify Root Causes, Not Symptoms When you're looking for who to blame, you stop when you find someone. You might identify the person who made the mistake, but you won't identify why the mistake was possible. Blameless postmortems force you to go deeper: Why was the mistake possible? What in the system allowed it? 3. They Build Resilience Every postmortem that identifies a system weakness and fixes it makes the system stronger. Over time, the system becomes increasingly resilient. 4. They Preserve Team Culture Blaming creates a culture of fear. People become defensive. They stop sharing information. They stop taking risks. They stop innovating. Blamelessness creates a culture of learning. People share openly. They take managed risks. They innovate. The Postmortem Process Step 1: Schedule the Postmortem Schedule the postmortem within 5 business days of the incident. Quickness matters—details are fresher, and the incident is still top of mind. Step 2: Gather Data Collect all relevant information: Timeline of events Chat logs System logs Actions taken Communications Step 3: Write the Postmortem Use a structured template to capture: What happened Why it happened (root cause analysis) What worked well What could have been better Action items Step 4: Review and Share Share the postmortem with the wider organization. This enables learning across teams. Step 5: Take Action Assign owners and due dates to action items. Track completion. The Postmortem Template Blameless Postmortem Incident Summary Date: [Date] Start Time: [Time] Resolution Time: [Time] Duration: [Duration] Severity: [P1/P2/P3/P4] Impact: [Description of user impact] Timeline Time Event 14:00 [Event description] 14:15 [Event description] 14:30 [Event description] Root Cause Analysis [Description of root cause] [Why the root cause occurred] What Worked [What went well in the response] What Could Have Been Better [Areas for improvement] Action Items # Action Item Owner Due Date 1 [Action] [Name] [Date] 2 [Action] [Name] [Date] Blameless Statement This postmortem focuses on what happened and how to prevent recurrence, not on who caused it. We recognize that systems fail, not people. The "5 Whys" Technique The "5 Whys" technique is a simple but powerful root cause analysis tool. Example Why did the system fail? Because a configuration change was incorrect. Why was the configuration change incorrect? Because the change wasn't tested in staging. Why wasn't it tested in staging? Because the staging environment doesn't match production. Why doesn't staging match production? Because we haven't invested in staging infrastructure. Why haven't we invested in staging infrastructure? Because we prioritized feature development over reliability. The root cause isn't "someone made a mistake." It's "we prioritized features over reliability." Common Pitfalls and How to Avoid Them Pitfall Solution Finding someone to blame Explicitly state the blameless principle at the start of every postmortem Superficial analysis Use "5 Whys" and other root cause techniques No action items Always end with action items and owners Stale action items Track action items and hold owners accountable Not sharing learnings Share postmortems across the organization Blamelessness = no accountability Distinguish between blame and accountability—accountability is important, blame is destructive The SRE Approach to Postmortems SRE teams have pioneered blameless postmortems: Key Principles Focus on what failed in the system, not who caused it Turn findings into action items with owners and dates Schedule postmortems within 5 business days SRE Postmortem Questions Question Purpose What happened? Establish the facts Why did it happen? Identify the root cause What did we learn? Capture the key lessons What will we do differently? Ensure improvement How will we know we've improved? Measure success Conclusion: Blamelessness Builds Resilience Blameless postmortems are the foundation of incident mastery. They enable learning, identify root causes, build resilience, and preserve team culture. When something goes wrong, don't ask "Who caused it?" Ask "Why did the system allow it?" The answer will make your system better. Action Items for Your Organization Establish the blameless principle: Explicitly state that postmortems are blameless Create a postmortem template: Provide a structured template for postmortems Schedule postmortems: Ensure postmortems happen promptly after incidents Assign action items: Always end with action items and owners Track action items: Ensure action items are completed Share learnings: Distribute postmortems across the organization  

No More Manual Data Entry — How AI Turns Chat Transcripts into Complete Service Requests The Unstructured Input Problem Employees don't think in forms. They think in natural language: "I need a new laptop," "Can I get access to the marketing drive?" or "My computer is slow." This natural language must be translated into structured data—a service request with the correct category, priority, assignment group, and required fields. Traditionally, this translation required service desk agents to read and interpret requests, manually extract key details, select the correct request type, populate fields, and route to the appropriate team. Each step consumed agent time, introduced potential for error, and delayed resolution. How AI Transforms Request Creation AI-powered service request creation solves this problem by automatically generating complete, structured service requests from minimal, unstructured input. The system intelligently analyzes the unstructured text to : Extract relevant details: Identifies key entities like user identity, requested action, urgency, and context Determine the request type: Matches the intent to the appropriate service catalog item Populate required fields: Automatically fills in categories, priority, assignment group, and other metadata Generate a complete request: Creates a well-structured ticket ready for assignment The Natural Language Detection Advantage Modern AI agents can detect intent from simple conversations. For example, when an employee pings their manager requesting approval for a conference, an AI agent can : Detect the intent from the conversation Extract details such as destination, duration, and purpose Automatically create a service request Route the approval request to the manager within the same conversation context The Benefits Benefit Impact Reduced manual effort Agents spend less time on data entry and request processing Minimized misclassification AI applies consistent categorization criteria Faster triage Complete requests can be assigned immediately Higher-quality data Consistent, accurate request data for reporting Improved agent productivity Agents focus on resolution, not administrative work Conclusion: The End of Manual Data Entry AI-powered service request creation is eliminating one of the most persistent inefficiencies in service management. By automatically converting unstructured inputs into complete, structured requests, organizations can reduce manual effort, minimize errors, and speed resolution. Action Items for Your Organization Assess your current request creation process—what's manual? Identify high-volume request types that could be automated Evaluate AI capabilities for request creation in your ITSM platform Pilot with a single request type, then expand Measure the reduction in manual processing time  

Are You Doing Change Management or Just Going Through the Motions? — The Change Maturity Model The Maturity Model Change management maturity describes how advanced your change enablement practice is. Low maturity means changes are slow, risky, and often fail. High maturity means changes are fast, safe, and deliver business value. Maturity Levels Level 1: Initial/Reactive Characteristics: Ad-hoc processes Inconsistent execution High failure rate No formal roles Reactive problem-solving Signs you're at Level 1: Changes often fail or cause incidents No formal change process Emergency changes are the norm Level 2: Repeatable Characteristics: Some process exists Inconsistently followed Basic categorization Some documentation Emerging accountability Signs you're at Level 2: Change process is documented Some changes are tracked Approval process exists Level 3: Defined Characteristics: Standardized process Documented workflows Clear roles and responsibilities CAB functions effectively Change types are used Signs you're at Level 3: Process is consistently followed Changes are categorized Success metrics are tracked Level 4: Managed Characteristics: Process performance is measured Proactive improvement Risk-based decision-making Integration with other processes Change success rates are high Signs you're at Level 4: Metrics are used for improvement Changes are fast and safe Change success is tracked Level 5: Optimizing Characteristics: Continuous improvement Integrated with DevOps AI-driven decision-making Automated approvals for low-risk changes Proactive risk management Signs you're at Level 5: AI assists in risk assessment Standard changes are fully automated Change is viewed as an enabler, not a barrier Maturity Assessment Questions Area Question Process Is there a formal, documented change process? Categorization Are changes categorized appropriately? CAB Does the CAB function effectively? Risk Is risk assessed consistently? Metrics Is change performance measured? Automation Are low-risk changes automated? Integration Is change integrated with other processes? Building a Roadmap Level 1 → Level 2: Document the process Define roles Track changes Level 2 → Level 3: Categorize changes Establish CAB Define workflows Level 3 → Level 4: Implement metrics Proactive improvement Integrate processes Level 4 → Level 5: Automate approvals AI integration Continuous improvement Conclusion Change management maturity is a journey. Organizations that assess their maturity and build a roadmap for improvement will achieve faster, safer changes and better business outcomes. Action Items for Your Organization Assess your current change management maturity Identify gaps in your process Build a roadmap to the next level Measure progress over time Celebrate improvements