Latest Articles

Headline: AI Adoption Fails Without Change Management — Here's Why The AI Adoption Challenge AI is creating rapid, high-stakes shifts that are triggering ripple effects across businesses . In the past year, just over half of organizations have redesigned or redefined roles because of AI. Yet the traditional change management model, built for linear workflows and finite initiatives, no longer fits the speed or complexity of today's work . Why AI Needs Change Management 1. AI Changes Work Design, Not Just Tools AI changes how work is designed, not just how tools are used. Without rethinking roles, workflows, and decisions, organizations often limit AI's impact . 2. Employees Need to Understand AI Employees need to understand how AI fits into their roles, what it means for their work, and how to succeed in a new environment . 3. Trust Must Be Built Without trust in AI systems, even the best-designed programs stall. Employees who trust their organization's AI solutions are 2.8 times more likely to use GenAI daily . 4. New Skills Are Required AI transforms the skills employees need. Organizations must provide training and support to help people adapt . 5. Resistance Must Be Managed AI often creates anxiety and resistance. Without proactive change management, this resistance can derail even the most sophisticated AI initiatives. The Cost of Poor Change Management Organizations that fail to adapt their change management strategies risk significantly undermining transformation efforts . Gartner predicts that organizations that fail to adapt their change management strategies risk significantly undermining transformation efforts. What Works Organizations that adapt change plans based on employee responses are four times more likely to achieve success with AI initiatives. Conclusion AI is not just a technology shift—it's a human shift. Organizations that invest in change management for AI adoption will see higher adoption, greater trust, and faster returns. Organizations that neglect change management risk AI failure. Action Items for Your Organization Assess your organization's AI change readiness Develop a change management strategy for AI adoption Build trust through transparency and reliability Provide training and support for AI adoption Adapt change plans based on employee responses  

Headline: Two Types of Control Testing — Design Effectiveness and Operating Effectiveness The Two Types of Control Testing Controls must be tested for both design and operating effectiveness. Both are essential for audit readiness. Design Effectiveness Testing Purpose: To determine whether a control is designed appropriately to mitigate the identified risk. Definition: Is the control designed effectively to achieve its control objective? Questions to answer: Does the control address the identified risk? Is the control designed to prevent or detect the risk? Is the control design consistent with regulatory requirements? Is the control clearly documented and understood? How to test design effectiveness: Review control documentation Interview control owners Walk through the control process Compare to regulatory requirements Evaluate against best practices When to test design effectiveness: When the control is first implemented When the control is redesigned When requirements change When risks change Operating Effectiveness Testing Purpose: To determine whether a control is operating as designed on a consistent basis. Definition: Is the control operating as designed and is it effective on a consistent basis? Questions to answer: Is the control being executed consistently? Is the control being executed as documented? Is the control achieving its objective? Is the control generating adequate evidence? How to test operating effectiveness: Review evidence of control execution Observe the control being performed Reperform the control Test the completeness and accuracy of evidence Analyze exceptions and deviations When to test operating effectiveness: Regularly (quarterly, semi-annually, annually) After changes to the control After changes to systems or processes When issues are identified Design vs. Operating Effectiveness Dimension Design Effectiveness Operating Effectiveness Purpose Is it designed right? Is it working right? Focus Control design Control operation When Design phase, significant changes Regular intervals Evidence Documentation, interviews Execution evidence, observations Outcome "This control should work" "This control does work" Testing Approaches 1. Walkthroughs A walkthrough is a procedure that involves tracing a transaction from initiation through completion to understand the process and identify control points . Example: Signal Corp. performed a walkthrough of each significant financial process and documented in a process flow diagram all the applications that supported these processes, including automated controls and controls that depended on system-generated reports . 2. Reperformance Reperforming the control to verify it was executed correctly. 3. Inspection Reviewing evidence of control execution. 4. Observation Observing the control being performed. 5. Inquiry Interviewing control owners and operators. Control Testing Program Elements of a control testing program: Element Description Control inventory Complete list of controls Testing schedule When each control will be tested Testing procedures How each control will be tested Responsibility Who will test each control Documentation How testing will be documented Reporting How findings will be reported Remediation How issues will be addressed Conclusion Control testing is essential for audit readiness. Organizations that test both design and operating effectiveness will have controls that are both well-designed and operating effectively. Action Items for Your Organization Document your control testing program Test design effectiveness for new controls Test operating effectiveness regularly Use multiple testing approaches Document test results Address issues promptly

Headline: The Technical Change Is Perfect — But Your Employees Are Resisting. What Now? The Resistance Reality Employees and stakeholders often resist change due to fear of the unknown, lack of trust, or previous negative experiences. This resistance can lead to change delays and low adoption rates . Why Resistance Happens Fear of the unknown: People are naturally wary of what they don't understand. Lack of trust: If employees don't trust leadership, they resist change. Previous negative experiences: Past change failures create skepticism. Loss of control: Change often means losing familiar ways of working. Perceived threat: Employees may see change as threatening their job security or status. Information overload: Too much change at once can overwhelm. Identifying Resistance Early Signs of resistance: Lack of engagement Negative sentiment (from surveys or sentiment analysis) Workarounds to avoid change Low adoption rates Complaints Using AI to detect resistance: AI sentiment analysis can identify patterns of resistance early, allowing leaders to intervene before resistance escalates . Overcoming Resistance 1. Communicate the Why Communicate the change details—including the "why" and benefits—early and often . What's changing and why? How will employees benefit? What's in it for them? 2. Involve Stakeholders Involve change stakeholders in the change process . Seek input on design Create ownership Build advocates 3. Provide Training and Support Provide sufficient training and support . Make training accessible Offer 24/7 support through AI agents Create peer support networks 4. Build Trust Build trust through humanity, transparency, capability, and reliability. Trust is the catalyst that drives sustainable change . 5. Use Sentiment Analysis Use sentiment analysis to identify resistance early . What are employees saying? Where is resistance strongest? How is sentiment changing? The Human Element Resistance to change is a natural human response—not a sign of weakness. The most effective change managers approach resistance with empathy, transparency, and support. A human-and-machine partnership can transform how organizations sense and sustain change . Conclusion Resistance to change is inevitable—but it can be managed. By communicating effectively, involving stakeholders, building trust, and using AI to detect resistance early, organizations can overcome the people challenge and drive successful change. Action Items for Your Organization Identify signs of resistance early Communicate the "why" and benefits clearly Involve stakeholders in the change process Provide training and support Build trust through transparency Use sentiment analysis to detect resistance Address resistance with empathy

A Complete Guide to the Problem Management Workflow — From Creation to Closure The Problem Management Workflow An ITIL problem management workflow aims to investigate, record, and prevent IT infrastructure problems . When correctly managed, problem records prompt agents to detail known errors and workarounds in your knowledge base. These documents : Help service agents resolve issues and restore services Reduce downtime Increase the quality and trust of your IT infrastructure The Default Workflow The IT Service Desk template comes with a built-in workflow for handling problems. The default workflow supports : Problem investigation Identification of workarounds Recording of known errors Workflow Stages Stage 1: Problem Creation Problem is detected Problem record is created Required fields are populated Problem is assigned to a team Stage 2: Problem Investigation Root cause analysis is performed Investigation reason is documented Related incidents are linked Stage 3: Diagnosis and Workaround Root cause is identified Workaround is documented Known error is created Stage 4: Resolution Change request is created Fix is implemented Resolution is verified Stage 5: Closure Problem is resolved Documentation is updated Lessons learned are captured Adapting the Workflow We recommend you start with the default workflow and adapt it to your specific needs over time . Common adaptations: Additional approval steps Integration with change management Automatic escalation rules SLA tracking Workflow Configuration Fields to configure : Field Configuration Priority Define priority levels and rules Impact Define impact criteria Urgency Define urgency criteria Category Define categorisation scheme Investigation reason Define triggers for investigation Pending reason Define reasons for hold Integration Points The problem workflow integrates with: Incident Management Link to related incidents Known errors help resolve incidents Incident trends trigger problems  Change Management Create change requests from problems Track implementation of fixes Knowledge Management Known errors are documented Workarounds are captured Service Level Management Track SLA compliance Measure service impact Statuses and Transitions Common statuses: Open Under Investigation Workaround Identified Resolution Proposed Resolved Closed Transitions: Each status has defined transitions Only authorized users can perform transitions Audit trail is maintained Conclusion A well-designed problem management workflow is the foundation of effective problem management. By starting with ITIL best practices and adapting to your needs, organizations can ensure systematic, consistent problem resolution. Action Items for Your Organization Review your current problem management workflow Identify gaps against ITIL best practices Adapt the workflow to your specific needs Train your team on the workflow Measure workflow effectiveness  

Some Problems Can't Be Predicted — But Most Can Be Prevented The Two Sub-Processes Problem Management is broken into two distinct sub-processes : Reactive Problem Management: Identifying the root cause, or providing suitable workarounds, of known incidents Proactive Problem Management: Identifying and eliminating the root cause of incidents, or providing suitable workarounds, in order to prevent their recurrence Both are essential for effective problem management. Reactive Problem Management Definition: Reactive Problem Management is triggered by incidents and aims to identify root causes and provide suitable workarounds . When it's triggered: Major incidents Recurring incidents Patterns of incidents Events from monitoring Key activities: Root cause analysis of incidents Workaround development Known error documentation Change requests Outcome: Permanent resolution of issues that have already occurred. Proactive Problem Management Definition: Proactive Problem Management identifies and eliminates root causes before incidents occur . When it's used: Trend analysis Monitoring data review Continuous improvement initiatives Preventive maintenance Key activities: Trend analysis Pattern detection Predictive analytics Preventive actions Outcome: Prevention of incidents before they occur. Balancing Reactive and Proactive Dimension Reactive Proactive Trigger Incidents Data analysis Focus Past Future Timeframe Immediate Strategic Resource investment High initially Ongoing The 80/20 Rule A significant portion of incidents come from a small number of underlying problems. By identifying and fixing these root causes, organizations can dramatically reduce incident volume. Proactive Problem Management in Practice 1. Trend Analysis Review incident data over time to identify patterns: Which incident types are increasing? What systems have the most incidents? What times of day/week have the most incidents? 2. Predictive Analytics Use historical data to predict future incidents: Which patterns preceded past incidents? What thresholds indicate risk? What systems are at risk? 3. Preventive Action Take action based on analysis: Apply patches before vulnerabilities are exploited Scale resources before capacity is exceeded Update procedures before they cause errors The Business Case for Proactive Investment Return Trend analysis Fewer incidents Predictive analytics Reduced downtime Preventive maintenance Lower incident volume Root cause elimination Permanent fixes Conclusion Reactive and proactive problem management are not competing approaches—they're complementary. Reactive problem management addresses issues after they occur; proactive problem management prevents them from occurring in the first place. Action Items for Your Organization Assess your current balance between reactive and proactive problem management Allocate dedicated time for proactive analysis Start trend analysis on incident data Identify high-volume incident patterns Implement preventive actions for top patterns

Stop Confusing Incidents and Problems — Why the Distinction Is the Foundation of Service Stability The Simple Rule Incidents are about restoring service; Problems are about preventing recurrence. This simple distinction is the foundation of effective service management. Yet many organizations fail to maintain the separation, leading to recurring issues and frustrated users. ITIL Definitions Incident: An unplanned interruption to an IT service or reduction in the quality of an IT service. Problem: The underlying cause of one or more incidents . Key Differences Dimension Incident Problem Purpose Restore service quickly Prevent recurrence  Reported by Customers/Users Internal IT members  Focus Symptom Root cause Resolution Workaround or fix Permanent elimination Timeline Immediate Can take months Priority Service impact Business impact and recurrence Why the Distinction Matters 1. Avoiding Recurrence If you only fix incidents and never investigate problems, the same issues will happen again and again. Incident management restores service; problem management prevents future disruptions. 2. Resource Allocation Incident management requires immediate attention; problem management can be planned. Without distinguishing between the two, urgent incidents can prevent strategic problem investigation. 3. Knowledge Management Known errors (problems with documented workarounds) enable faster incident resolution. Without problem management, this knowledge isn't captured. 4. Continuous Improvement Problem management drives improvement by identifying and eliminating systemic issues. When Does an Incident Become a Problem? An incident should become a problem when : A Major Incident has occurred A pattern of recurring Incidents suggests an underlying cause should be addressed An Event has occurred where an underlying cause should be addressed Real-World Example Incident: A server crashes. Teams restart the server, restoring service. Problem: Investigation reveals the server crashed because of a memory leak in the application. Problem resolution: The application is patched to fix the memory leak. Result: The incident doesn't recur. Common Mistakes Mistake Consequence Treating every incident as a problem Overwhelmed problem management team Never escalating incidents to problems Recurring issues never fixed Using the same process for both Problems treated as urgent fixes Not documenting known errors Same incident repeats Conclusion The distinction between incidents and problems is not academic—it's operational. Organizations that maintain this separation will have fewer recurring incidents, better knowledge management, and more stable services. Action Items for Your Organization Ensure your ITSM platform has separate Incident and Problem record types Train your team on the incident vs. problem distinction Create clear criteria for when an incident should become a problem Document known errors when problems are resolved Measure recurring incident rates Topic 11: Known Errors and Workarounds — The Knowledge Foundation of Problem Management Headline: When You Can't Fix It Permanently — How Known Errors and Workarounds Keep Services Running What Is a Known Error? When Problem Management identifies the underlying cause and develops a workaround, the problem becomes a "known error" . A known error is a problem that has been diagnosed and has a documented workaround. Key characteristics: Root cause is identified Workaround is documented May not be permanently fixed yet Knowledge is available for future incidents What Is a Workaround? A workaround is a temporary method for achieving the given task when the planned method is not working due to the Problem. The workaround is abandoned when the Problem is fixed . Workarounds help reduce service interruptions until the Problem is fully resolved . Characteristics of a good workaround: Restores service Is documented clearly Is easy to implement Is safe to use The Known Error Database (KEDB) Known Error articles are documented both in the Problem Record and as articles in the IT Service Management tool's Knowledge Base . The KEDB is the repository for known errors and their associated workarounds. It serves as a critical knowledge resource for incident management teams. What the KEDB contains: Problem description Root cause Symptoms Workarounds Resolution (if available) Related incidents Why Known Errors Matter Benefit Impact Faster resolution Incidents resolved using known workarounds Reduced downtime Services restored quickly Increased confidence Teams can resolve issues reliably Knowledge sharing Tribal knowledge is captured Better reporting Known errors inform trend analysis The Known Error Workflow Problem diagnosed: Root cause is identified Workaround identified: A temporary fix is developed Known error created: Documented in the KEDB Incidents linked: Related incidents associated with the known error Incident resolution: Agents use the workaround to restore service Problem resolution: Permanent fix is implemented Known error updated: Resolution is documented, workaround retired Creating Effective Known Error Articles Essential information: Problem description Symptoms Root cause Workaround steps Implementation considerations Related incidents Resolution (when implemented) Best practices: Use clear, plain language Include steps in chronological order Note any limitations of the workaround Keep articles current Link to related knowledge When Known Errors Are Most Valuable Known errors are particularly valuable for: Scenario Why High-volume incidents Same issue repeatedly resolved faster Complex systems Expert knowledge is captured and shared New team members Access to institutional knowledge Service desk triage First-line support can resolve more issues Conclusion Known errors and workarounds are the foundation of effective incident and problem management. By documenting known errors, organizations capture institutional knowledge, enable faster incident resolution, and build a learning culture. Action Items for Your Organization Establish a Known Error Database (KEDB) Create a template for known error articles Train teams on how to create and use known errors Link known errors to incident records Measure how often known errors are used in incident resolution