The integration of Artificial Intelligence (AI) into IT Service Management (ITSM) is redefining the way organizations handle their IT operations, processes, and customer interactions. By automating repetitive tasks, providing intelligent insights, and fostering proactive problem-solving, AI transforms ITSM into a more efficient, resilient, and innovative function. Here's a look at how AI is enhancing ITSM.

## 1. **Automating Routine Tasks**
One of AI’s most impactful contributions to ITSM is its ability to automate repetitive, time-consuming tasks. Examples include:
- **Ticket Routing:** AI-powered systems analyze the nature of IT requests and route them to the most appropriate team or individual.
- **Password Resets and Access Requests:** Virtual agents can handle these straightforward tasks, freeing up IT staff for more complex work.
- **System Monitoring:** AI tools can automatically monitor IT infrastructure, detecting anomalies and generating alerts.

This automation reduces workload, speeds up response times, and allows IT teams to focus on strategic activities.

## 2. **Enhancing Incident Management**
AI improves the incident management process by:
- **Real-Time Diagnostics:** Identifying the root causes of incidents quickly using historical data and machine learning.
- **Predictive Insights:** Anticipating potential failures and alerting teams before issues escalate.
- **Automated Resolution:** Suggesting or even implementing solutions for common problems without human intervention.

The result is faster incident resolution, minimized downtime, and enhanced service reliability.

## 3. **Enabling Proactive Problem Management**
Traditionally, ITSM has been reactive, addressing issues after they occur. AI shifts the focus to proactive problem management by:
- **Identifying Patterns:** Analyzing historical data to uncover recurring issues.
- **Preventive Actions:** Recommending and implementing measures to mitigate potential problems.
- **Improving System Resilience:** Ensuring that systems are optimized to withstand challenges.

This approach minimizes disruptions and fosters a more stable IT environment.

## 4. **Enhancing Change Management**
AI simplifies the complexities of change management through:
- **Risk Analysis:** Evaluating the potential impacts of changes and identifying risks.
- **Best Practices:** Providing recommendations based on successful implementations in similar scenarios.
- **Automated Testing:** Running simulations to predict outcomes and ensure smooth transitions.

With AI, organizations can implement changes more confidently and efficiently.

## 5. **Streamlining Knowledge Management**
A well-maintained knowledge base is essential for ITSM. AI enhances knowledge management by:
- **Organizing Information:** Structuring data into easily accessible formats.
- **Answering Queries:** Using natural language processing to help users and IT staff find relevant information quickly.
- **Learning and Updating:** Continuously updating the knowledge base as new issues and solutions arise.

This ensures that both users and IT teams have access to up-to-date, relevant information.

## 6. **Optimizing Service Delivery**
AI improves the service delivery process by:
- **Personalization:** Tailoring responses and recommendations based on user profiles and preferences.
- **Predictive Analytics:** Anticipating user needs and offering solutions proactively.
- **Virtual Agents:** Providing 24/7 support to handle user queries, ensuring consistent service availability.

These enhancements lead to better user experiences and stronger service outcomes.

## 7. **Empowering IT Teams**
AI is not here to replace IT professionals but to empower them. By taking over repetitive tasks and providing actionable insights, AI allows IT teams to focus on innovation, strategy, and complex problem-solving. This fosters a more engaged and productive workforce.

## Final Thoughts
Artificial Intelligence is revolutionizing ITSM by making it smarter, faster, and more proactive. From automating tasks to enabling predictive insights and enhancing user experiences, AI empowers organizations to deliver superior IT services while adapting to the challenges of a fast-paced digital world. By embracing AI, businesses can not only streamline their operations but also unlock new opportunities for growth and innovation.


How Artificial Intelligence Enhances IT Service Management

AI driving ITSM

## **How Service Architecture Boosts Business Effectiveness**

In today’s rapidly evolving business environment, organizations must be agile, efficient, and customer-focused to stay competitive. Service architecture, a strategic design approach for structuring business processes and systems, plays a critical role in achieving these goals.

By aligning services with business needs, it ensures that resources are optimized, processes run smoothly, and customer experiences are enhanced. Here’s how service architecture can transform your business:

### 1. **Streamlining Business Operations**

Service architecture breaks down complex systems into modular, manageable services. Each service represents a specific function or process, such as order management or customer support. By designing these services to work independently yet cohesively, businesses can:

- Reduce inefficiencies by eliminating redundancies and streamlining workflows.
- Quickly adapt to changes, as individual services can be updated or replaced without disrupting the entire system.

For example, if your organization introduces a new payment method, the payment processing service can be updated without overhauling the entire operational framework.

### 2. **Enhancing Scalability and Flexibility**

As your business grows, so does the demand for resources and capabilities. A well-designed service architecture allows for seamless scaling by enabling the addition of new services or the expansion of existing ones. This flexibility ensures that your operations can handle increased workloads without compromising performance or customer satisfaction.

### 3. **Improving Collaboration and Communication**

Service architecture fosters better collaboration within and across teams by clearly defining roles, responsibilities, and workflows. Each service has a specific purpose and owner, reducing ambiguity and encouraging accountability. Moreover, the use of standardized interfaces and protocols facilitates smoother communication between services, ensuring that data flows efficiently across departments.

### 4. **Driving Innovation and Adaptability**

In a world where customer needs and market conditions change rapidly, businesses must be able to pivot quickly. Service architecture supports innovation by enabling organizations to experiment with new ideas and technologies without disrupting existing operations. Whether it’s integrating AI-driven analytics or launching a new digital product, service architecture provides the flexibility to stay ahead of the curve.

### 5. **Enhancing Customer Experience**

By aligning services with customer journeys, service architecture ensures that each touchpoint delivers value and meets expectations. Whether it’s faster response times, personalized recommendations, or seamless transactions, a customer-centric service architecture can significantly enhance satisfaction and loyalty.

### 6. **Reducing Costs and Risks**

Service architecture promotes cost-efficiency by optimizing resource allocation and reducing waste. Additionally, its modular nature minimizes risks, as failures in one service are less likely to impact the entire system. This resilience is crucial for maintaining business continuity and protecting your reputation.

### Conclusion

Service architecture is more than just a technical framework; it’s a strategic tool for enhancing business effectiveness. By streamlining operations, enabling scalability, fostering collaboration, driving innovation, and improving customer experiences, it empowers organizations to thrive in a competitive landscape. Embracing service architecture isn’t just an investment in technology—it’s an investment in your business’s future success.


Using Service Architecture to improve your business

Embracing Service Architecture

In the ever-evolving IT Service Management (ITSM) landscape, staying ahead of the curve is crucial for organisations aiming to deliver exceptional service and maintain operational efficiency. One of the most exciting innovations in ITSM today is the integration of Artificial Intelligence (AI) and Machine Learning (ML) to revolutionize service delivery and user experience.

**AI-Powered Automation: Transforming ITSM**

AI-driven automation is poised to redefine ITSM by taking over routine tasks, such as password resets, troubleshooting, and system updates. This not only reduces the reliance on human intervention for repetitive support but also frees up IT staff to focus on higher-value tasks. With advancements in Natural Language Processing (NLP), AI agents can understand complex queries, improving response times and reducing human error.

**Experience-Driven ITSM: The Shift to XLAs**

Traditional Service Level Agreements (SLAs) have long focused on system uptime and response times. However, the shift towards Experience Level Agreements (XLAs) is gaining momentum. XLAs prioritise service quality and user satisfaction over mere technical performance. By integrating AI-driven monitoring and real-time sentiment analysis, IT teams can enhance IT services, improve user satisfaction, and align ITIL-driven services more closely with business goals.

**Enhanced AI Governance: Ethical and Effective AI Use**

As organizations increasingly rely on AI, the need for robust AI governance frameworks becomes paramount. These frameworks ensure ethical and effective AI use within ITSM, promoting transparency and accountability. By continuously monitoring AI performance and adjusting algorithms, organizations can maintain accuracy and improve service delivery.

**Holistic ITSM: Integrating Business Functions**

The future of ITSM lies in its integration with other business functions, such as Enterprise Resource Planning (ERP) systems and Customer Relationship Management (CRM) software. This holistic approach improves data sharing and decision-making across departments, aligning business goals with IT capabilities. By leveraging shared data, organizations can develop coordinated strategies that enhance service delivery and operational efficiency.

**Conclusion**

The integration of AI and ML into ITSM is not just a trend; it's a transformative shift that promises to enhance efficiency, improve user experience, and drive innovation. As we embrace these advancements, it's essential to balance AI's capabilities with the human touch, ensuring that technology serves to augment, not replace, human interactions. By adopting AI-driven ITSM solutions, organizations can stay ahead in the competitive landscape and deliver exceptional service to their users.

AI-Driven ITSM for Enhanced Efficiency and User Experience

Embracing the future

IT security operations (SecOps) involve protecting an organisation’s IT infrastructure, data, and users from cyber threats. This requires a combination of proactive measures, incident response, and continuous monitoring. Integrating the Japanese philosophy of **Ichi-go Ichi-e** can offer unique and valuable benefits to IT security operations.

**Ichi-go Ichi-e**, meaning "one time, one meeting," emphasises the uniqueness and irreproducibility of each moment. This mindfulness philosophy encourages presence, appreciation, and attention to detail, which can significantly enhance IT security operations.

## 1. Improved Incident Response
Approaching each security incident with the Ichi-go Ichi-e mindset ensures that IT professionals are fully present and focused on the specific threat at hand. This heightened attention can lead to quicker identification of attack vectors, more effective containment measures, and faster resolution of incidents, thereby minimising potential damage.

## 2. Enhanced Threat Analysis
Treating each threat as a unique and valuable learning opportunity fosters a deeper and more thorough analysis. This approach can help security teams uncover subtle patterns, understand attacker behaviour, and develop more robust defences against future attacks.

## 3. Better Communication and Collaboration
SecOps require seamless collaboration between various teams, including IT, security, and compliance. Embracing Ichi-go Ichi-e fosters mindful and respectful communication, ensuring that all parties are fully engaged and understood. This can lead to stronger collaboration, better decision-making, and a more cohesive security posture.

## 4. Increased Efficiency and Productivity
By focusing on the present moment and giving full attention to each task, IT security professionals can work more efficiently and effectively. This mindfulness can lead to higher-quality work, reduced errors, and faster completion of tasks, ultimately boosting overall productivity.

## 5. Enhanced User Awareness and Training
Applying Ichi-go Ichi-e to user interactions ensures that each training session, awareness campaign, and security briefing is conducted with full attention and appreciation for the unique needs of the audience. This can lead to more effective training outcomes and a higher level of security awareness among users.

## 6. Reduced Stress and Burnout
The demanding nature of SecOps can lead to stress and burnout among security professionals. Adopting the principles of Ichi-go Ichi-e encourages a mindful approach to work, helping individuals stay calm and composed even during high-pressure situations. This can lead to a healthier work environment and improved well-being for security staff.

## 7. Continuous Improvement
Viewing each security incident and threat analysis as a unique learning opportunity aligns with the philosophy of continuous improvement. By reflecting on the lessons learned from each incident and interaction, security teams can identify areas for enhancement and implement changes that drive ongoing improvement.

## Conclusion
Integrating Ichi-go Ichi-e into IT security operations brings a mindful and human-centred approach to a traditionally technical field. By fostering presence, attention to detail, improved communication, and a focus on continuous improvement, IT security professionals can enhance the effectiveness and efficiency of their operations. As the cyber threat landscape continues to evolve, embracing the timeless wisdom of Ichi-go Ichi-e can provide a significant advantage in safeguarding an organisation’s digital assets and ensuring the smooth functioning of business processes.

The Benefits of Applying Ichi-go Ichi-e to IT Security Operations

Ichi-go ichi-e and Service Excellence

Service Excellence

IT operations encompass a wide range of activities aimed at managing and maintaining an organisation’s IT infrastructure to ensure smooth and efficient business processes. While technical expertise and procedural rigour are essential, integrating the Japanese concept of **Ichi-go Ichi-e** can bring a refreshing and highly beneficial perspective to IT operations.

**Ichi-go Ichi-e**, meaning "one time, one meeting," emphasises the uniqueness and irreproducibility of each moment. This mindfulness philosophy encourages presence, appreciation, and attention to detail, which can significantly enhance IT operations.

## 1. Improved Incident Response
Approaching each incident with the Ichi-go Ichi-e mindset ensures that IT professionals are fully present and focused on resolving the issue at hand. This heightened attention can lead to quicker identification of root causes and more effective solutions, minimising downtime and reducing the impact on business operations.

## 2. Enhanced Preventative Maintenance
Treating each maintenance activity as a unique opportunity to ensure the health of IT systems encourages thoroughness and attention to detail. This proactive approach can help identify potential issues before they escalate into major problems, leading to more reliable and resilient IT infrastructure.

## 3. Better Communication and Collaboration
IT operations often involve coordination between various teams and stakeholders. Embracing Ichi-go Ichi-e fosters mindful and respectful communication, ensuring that all parties are fully engaged and understood. This can lead to stronger collaboration, better decision-making, and a more cohesive team environment.

## 4. Increased Efficiency and Productivity
By focusing on the present moment and giving full attention to each task, IT professionals can work more efficiently and effectively. This mindfulness can lead to higher-quality work, reduced errors, and faster completion of tasks, ultimately boosting overall productivity.

## 5. Enhanced Customer Satisfaction
Applying Ichi-go Ichi-e to customer interactions ensures that each user feels valued and appreciated. By being fully present and attentive during support interactions, IT professionals can provide a higher level of service, leading to improved customer satisfaction and loyalty.

## 6. Reduced Stress and Burnout
The demanding nature of IT operations can lead to stress and burnout among IT professionals. Adopting the principles of Ichi-go Ichi-e encourages a mindful approach to work, helping individuals stay calm and composed even during high-pressure situations. This can lead to a healthier work environment and improved well-being for IT staff.

## 7. Continuous Improvement
Viewing each operational activity as a unique learning opportunity aligns with the philosophy of continuous improvement. By reflecting on the lessons learned from each incident, maintenance task, and interaction, IT teams can identify areas for enhancement and implement changes that drive ongoing improvement.

## Conclusion
Integrating Ichi-go Ichi-e into IT operations brings a mindful and human-centred approach to a traditionally technical field. By fostering presence, attention to detail, improved communication, and a focus on continuous improvement, IT professionals can enhance the effectiveness and efficiency of their operations. As the IT landscape continues to evolve, embracing the timeless wisdom of Ichi-go Ichi-e can provide a significant advantage in delivering exceptional IT services and ensuring the smooth functioning of business processes.

The Benefits of Applying Ichi-go Ichi-e to IT Operations

DevOps, the amalgamation of development and operations, emphasises collaboration, automation, and continuous improvement to deliver high-quality software rapidly and efficiently. While technical methodologies are at its core, integrating the Japanese philosophy of **Ichi-go Ichi-e** can provide profound enhancements to the DevOps culture and practices.

**Ichi-go Ichi-e**, meaning "one time, one meeting," emphasises the uniqueness and irreplaceability of each moment. This mindfulness philosophy encourages presence, appreciation, and attention to detail, which can significantly benefit DevOps.

## 1. Enhanced Focus on Each Deployment
Treating each deployment with the Ichi-go Ichi-e mindset ensures that every release is given the attention and care it deserves. This heightened focus can lead to more thorough testing, validation, and monitoring, resulting in higher-quality software releases with fewer issues.

## 2. Improved Collaboration and Communication
DevOps relies heavily on collaboration between development and operations teams. By embracing Ichi-go Ichi-e, team members are encouraged to be fully present and engaged in their interactions. This can lead to more meaningful and productive communication, fostering a stronger sense of teamwork and mutual respect.

## 3. Increased Responsiveness to Feedback
Viewing each piece of feedback as a unique opportunity to improve aligns perfectly with the DevOps culture of continuous improvement. By treating feedback with mindfulness and appreciation, teams can more effectively address user concerns and enhance their products based on real-world experiences.

## 4. Reduced Stress and Burnout
The fast-paced nature of DevOps can lead to stress and burnout. Applying Ichi-go Ichi-e encourages individuals to approach their work with mindfulness, helping them stay calm and composed even under pressure. This can lead to a healthier work environment and improved well-being for team members.

## 5. Better Incident Management
In the event of an incident, approaching it with the Ichi-go Ichi-e mindset can lead to more focused and effective problem-solving. By fully engaging with the incident at hand, teams can quickly identify root causes, implement solutions, and document learnings for future reference.

## 6. Enhanced Innovation and Creativity
Mindfulness fosters an open-minded and reflective approach to problem-solving. By embracing Ichi-go Ichi-e, DevOps teams can tap into their creativity and explore innovative solutions that might not have been considered otherwise. This can lead to more effective and forward-thinking development practices.

## 7. Stronger Continuous Improvement Culture
The philosophy of Ichi-go Ichi-e aligns with the DevOps principle of continuous improvement. By treating each sprint, each deployment, and each feedback loop as unique opportunities for learning and growth, teams can continually refine their processes and deliver better outcomes.

## Conclusion
Integrating Ichi-go Ichi-e into DevOps brings a mindful and human-centered approach to a fast-paced and technical discipline. By fostering attention to detail, improved collaboration, better incident management, and a culture of continuous improvement, DevOps teams can enhance their effectiveness and achieve greater success. As the tech landscape continues to evolve, embracing the wisdom of Ichi-go Ichi-e can provide a significant advantage in delivering high-quality software and fostering a positive work environment.

The Benefits of Applying Ichi-go Ichi-e to DevOps

Change management within IT Service Management (ITSM) involves the controlled process of managing changes to IT services, ensuring minimal disruption and maintaining service quality. While technical procedures and frameworks are essential, integrating the Japanese concept of **Ichi-go Ichi-e** can offer valuable insights and improvements to this critical function.

**Ichi-go Ichi-e**, meaning "one time, one meeting," emphasises the uniqueness and irreplaceability of each moment. This mindfulness philosophy encourages presence, appreciation, and attention to detail, which can significantly benefit ITSM Change Management.

## 1. Enhanced Attention to Detail
Approaching each change with the Ichi-go Ichi-e mindset means giving full attention to every aspect of the change process. This thoroughness can lead to more accurate impact assessments, risk evaluations, and implementation plans, reducing the likelihood of errors and unforeseen issues.

## 2. Improved Stakeholder Engagement
Viewing each change as a unique event fosters a more considerate and collaborative approach to stakeholder engagement. By valuing each interaction and ensuring that all voices are heard, change managers can build stronger relationships with stakeholders, gaining their trust and support for the change.

## 3. Better Change Documentation
Mindfulness in the documentation process ensures that each change is recorded with precision and clarity. Detailed documentation helps create a comprehensive change history, which can be invaluable for future reference, audits, and continuous improvement initiatives.

## 4. Reduced Resistance to Change
When change managers are fully present and empathetic during the change process, they can better understand and address the concerns of those affected by the change. This approach can help mitigate resistance and foster a more positive attitude towards the change, leading to smoother implementations.

## 5. Increased Flexibility and Adaptability
The philosophy of Ichi-go Ichi-e encourages an open-minded and flexible approach to each unique change. This adaptability allows change managers to respond more effectively to unexpected challenges and to tailor their strategies to the specific needs of each situation.

## 6. Enhanced Learning and Improvement
Treating each change as an opportunity to learn and improve aligns with the continuous improvement mindset central to ITSM. By reflecting on the unique aspects and outcomes of each change, teams can identify best practices and areas for enhancement, leading to more effective change management over time.

## 7. Strengthened Team Collaboration
Applying Ichi-go Ichi-e principles can foster a culture of mutual respect and cooperation within the change management team. When team members approach their work with mindfulness and appreciation for each other's contributions, it can lead to stronger collaboration and more innovative solutions.

## Conclusion
Integrating Ichi-go Ichi-e into ITSM Change Management brings a mindful and human-centred approach to a structured process. By fostering attention to detail, improved stakeholder engagement, better documentation, and a culture of continuous improvement, IT professionals can enhance the effectiveness and success of change initiatives. As the IT landscape evolves, embracing the wisdom of Ichi-go Ichi-e can provide a significant advantage in managing changes with grace and efficiency.

The Benefits of Applying Ichi-go Ichi-e to ITSM Change Management

In the fast-paced world of IT Service Management (ITSM), incident management is a critical function that ensures the continuity of business operations and the swift resolution of IT issues. Amidst the technical and procedural rigour of ITSM, a Japanese concept known as **Ichi-go Ichi-e** can offer a refreshing and highly beneficial perspective.

**Ichi-go Ichi-e** translates to "one time, one meeting" or "for this time only." It emphasises the uniqueness and irreproducibility of each moment, encouraging mindfulness, presence, and appreciation for the here and now. Applying this philosophy to ITSM Incident Management can bring several significant benefits:

## 1. Enhanced Focus and Presence
When IT professionals approach each incident with the mindset of Ichi-go Ichi-e, they become fully present and focused on the task at hand. This heightened attention can lead to a more thorough and accurate diagnosis of issues, reducing the likelihood of overlooking critical details.

## 2. Improved Customer Satisfaction
Treating each incident as a unique opportunity to provide excellent service fosters a customer-centric approach. By valuing each interaction with the end-user, IT support teams can build stronger relationships, ensuring that users feel heard, respected, and valued. This can lead to higher levels of customer satisfaction and loyalty.

## 3. Reduced Stress and Burnout
The high-pressure environment of incident management often leads to stress and burnout among IT professionals. Adopting Ichi-go Ichi-e encourages a mindful approach to work, helping individuals stay calm and composed, even in the face of challenging situations. By taking each incident one at a time and fully engaging with it, IT professionals can avoid feeling overwhelmed by the volume of incidents.

## 4. Increased Collaboration and Team Cohesion
When team members embrace the principles of Ichi-go Ichi-e, they are more likely to engage in meaningful and respectful communication. This fosters a collaborative environment where ideas and solutions are freely shared, leading to more effective problem-solving and a cohesive team dynamic.

## 5. Continuous Improvement
Viewing each incident as a unique learning opportunity encourages a culture of continuous improvement. By reflecting on the lessons learned from each incident, IT teams can identify patterns, uncover root causes, and implement preventative measures to reduce the likelihood of future incidents.

## 6. Enhanced Incident Documentation
Mindfulness in incident management extends to the documentation process. When IT professionals approach each incident with the intention of capturing its unique aspects, they produce more detailed and accurate records. This improved documentation can serve as a valuable resource for future incidents, providing insights and references that enhance the overall effectiveness of the ITSM process.

## Conclusion
Incorporating Ichi-go Ichi-e into ITSM Incident Management brings a human-centred approach to a traditionally technical field. By fostering mindfulness, presence, and appreciation for each unique incident, IT professionals can improve their focus, reduce stress, enhance customer satisfaction, and promote continuous improvement. As the IT landscape continues to evolve, embracing the timeless wisdom of Ichi-go Ichi-e can offer a significant competitive advantage in delivering exceptional IT services.


The Benefits of Applying Ichi-go Ichi-e to ITSM Incident Management

In the fast-paced world of IT Service Management (ITSM), efficiency and effectiveness are often prioritised. However, integrating the Japanese philosophy of "ichi-go ichi-e" (一期一会), which translates to "one time, one meeting," can bring a unique and valuable perspective to managing service requests. This philosophy emphasises treasuring each moment and encounter, treating it as a once-in-a-lifetime opportunity. By applying "ichi-go ichi-e" to ITSM, organisations can enhance the quality of their service and improve customer satisfaction.

#### Understanding "Ichi-go Ichi-e"

"Ichi-go ichi-e" encourages individuals to fully appreciate and value each unique moment and interaction. Originating from the Japanese tea ceremony, this concept can be applied to various aspects of life, including business and customer service. By embracing this philosophy, ITSM professionals can transform routine service requests into meaningful and memorable experiences.

#### Applying "Ichi-go Ichi-e" to Service Request Management

1. **Personalised Interactions**: Each service request should be approached as a unique encounter. Personalise interactions by addressing users by their names, understanding their specific needs, and providing tailored solutions. This creates a sense of importance and appreciation for each user.

2. **Active Listening**: Practice active listening to fully understand the user's concerns and requirements. By giving undivided attention to each service request, ITSM professionals can gather valuable insights and provide more accurate and effective solutions.

3. **Empathy and Understanding**: Show empathy and understanding towards users' challenges. Acknowledge their frustrations and reassure them that their issues are being taken seriously. This humanises the interaction and builds trust between users and ITSM professionals.

4. **Timeliness and Quality**: Treat each service request as a priority and strive to resolve issues promptly and efficiently. Ensure that the quality of the solution is not compromised by time constraints. A timely and high-quality response reflects the value placed on the user's unique situation.

5. **Continuous Improvement**: After resolving a service request, seek feedback from users to understand their experience. Use this feedback to continuously improve service delivery and ensure that future interactions are even more valuable.

#### Benefits of "Ichi-go Ichi-e" in ITSM

- **Enhanced User Experience**: By valuing each service request as a unique opportunity, users feel appreciated and respected, leading to higher satisfaction levels.
- **Improved Trust and Loyalty**: Personalised and empathetic interactions foster trust and loyalty, encouraging users to return for future services.
- **Increased Efficiency**: Active listening and a thorough understanding of user needs result in more accurate and efficient resolutions, reducing the need for repeat requests.
- **Positive Workplace Culture**: Embracing "ichi-go ichi-e" cultivates a positive and respectful workplace culture, motivating ITSM professionals to deliver their best.

#### Conclusion

Incorporating the philosophy of "ichi-go ichi-e" into IT Service Management can transform the way service requests are managed. By treating each interaction as a unique and valuable moment, ITSM professionals can enhance the user experience, build trust, and improve overall service quality. In a world where technology often dominates, bringing a human touch to ITSM can make all the difference.

By embracing "ichi-go ichi-e," IT organisations can ensure that each service request is not just a task to be completed but an opportunity to create a lasting positive impact.

Embracing "Ichi-go Ichi-e" in IT Service Management: A Unique Approach to Service Request Management

The concept of Ichi-go Ichi-e, emphasising the uniqueness of each moment and interaction, can significantly enhance engagement in Information Technology Service Management (ITSM). However, to effectively incorporate and measure this philosophy within an ITSM environment, Experience Level Agreements (XLAs) can be a valuable tool. XLAs focus on the end-user experience rather than just service-level metrics, making them an ideal framework for assessing the impact of Ichi-go Ichi-e.

## Understanding XLAs

XLAs are agreements that define the desired user experience and outcomes in IT services. Unlike traditional Service Level Agreements (SLAs), which measure technical performance metrics such as uptime and response time, XLAs concentrate on the quality of the user experience, satisfaction, and overall engagement. By using XLAs, ITSM teams can ensure that they are meeting the users' expectations and providing a meaningful, impactful service.

## Measuring Ichi-go Ichi-e with XLAs

To measure the application of Ichi-go Ichi-e within an ITSM environment, it is essential to establish XLAs that capture the essence of this concept. Here are some key steps to achieve this:

### 1. Define User Experience Metrics

Identify and define metrics that align with the principles of Ichi-go Ichi-e. These metrics should focus on the uniqueness and quality of each user interaction. Examples include:
- **Personalisation Index**: Measure the extent to which service interactions are tailored to individual users' needs and preferences.
- **Engagement Score**: Assess how engaged and involved users feel during their interactions with IT services.
- **Satisfaction Rate**: Capture overall user satisfaction with the service provided.

### 2. Collect Qualitative Feedback

In addition to quantitative metrics, gather qualitative feedback from users to gain deeper insights into their experiences. Use surveys, interviews, and feedback forms to understand how users perceive the uniqueness and value of each interaction. Questions to consider include:
- How personalised did you feel your service experience was?
- Did the service interaction meet your unique needs and expectations?
- How likely are you to recommend our IT services to others?

### 3. Monitor Real-Time Data

Utilise real-time data analytics to monitor user interactions and experiences continuously. Track metrics such as response times, resolution times, and user sentiment during each service interaction. Real-time monitoring allows ITSM teams to identify trends and make adjustments to improve user experiences on the fly.

### 4. Conduct Experience Reviews

Regularly review and analyse user experiences to identify areas for improvement. Hold experience review sessions where ITSM teams can discuss feedback, reflect on recent interactions, and brainstorm ways to enhance the uniqueness and quality of service. Use this information to refine XLAs and ensure they remain aligned with the Ichi-go Ichi-e philosophy.

### 5. Foster a Culture of Continuous Improvement

Encourage a culture of continuous improvement within the ITSM team. Emphasise the importance of learning from each interaction and making incremental enhancements to service delivery. By fostering a mindset of continuous improvement, ITSM teams can consistently elevate the user experience and embody the principles of Ichi-go Ichi-e.

## Conclusion

Incorporating the concept of Ichi-go Ichi-e into an ITSM environment can transform the way IT services are delivered and experienced. By using XLAs to measure the uniqueness and quality of each interaction, ITSM teams can ensure they are providing meaningful, personalised, and engaging services. Embracing Ichi-go Ichi-e through XLAs not only enhances user satisfaction but also fosters a culture of continuous improvement and respect for each unique encounter.

As we continue to navigate the evolving landscape of ITSM, let us remember the wisdom of Ichi-go Ichi-e and strive to create memorable and impactful experiences for every user.

Measuring Ichi-go Ichi-e in an ITSM Environment Using XLAs

In the fast-paced world of Information Technology Service Management (ITSM), maintaining meaningful engagement with users and stakeholders can often be a challenging endeavour. However, there is a unique concept from Japanese culture that can significantly enhance ITSM engagement: Ichi-go Ichi-e (一期一会).

## Understanding Ichi-go Ichi-e

Ichi-go Ichi-e, which translates to "one time, one meeting," is a Japanese idiom often used in the context of the traditional tea ceremony. It encapsulates the idea that each encounter is unique and will never happen again in exactly the same way. This philosophy encourages individuals to cherish each moment and interaction, recognising its singular importance.

## Applying Ichi-go Ichi-e to ITSM

Incorporating the principle of Ichi-go Ichi-e into ITSM practices can lead to more meaningful and effective engagement. Here’s how:

### 1. Personalising User Interactions

Each interaction with a user or stakeholder is an opportunity to create a lasting impression. By embracing the concept of Ichi-go Ichi-e, ITSM professionals can focus on personalising each encounter, addressing individual needs, and showing genuine care and attention. This can build stronger relationships and foster trust.

### 2. Enhancing Customer Experience

Ichi-go Ichi-e encourages ITSM teams to view each service request or incident as a unique event. By treating every service interaction as a one-of-a-kind experience, teams can enhance the overall customer experience, ensuring that users feel valued and understood. This approach can lead to higher satisfaction rates and positive feedback.

### 3. Encouraging Active Listening

The philosophy of Ichi-go Ichi-e emphasises the importance of being fully present in the moment. For ITSM professionals, this means actively listening to users’ concerns and feedback without distractions. By practicing active listening, teams can better understand user needs, leading to more effective problem-solving and service delivery.

### 4. Promoting Continuous Improvement

Recognising the uniqueness of each interaction allows ITSM teams to learn and improve continuously. By reflecting on each engagement, identifying areas for improvement, and celebrating successes, teams can evolve their practices and deliver better services over time.

### 5. Fostering a Culture of Respect

Ichi-go Ichi-e teaches respect for the present moment and for the individuals involved. In ITSM, this translates to respecting users' time, opinions, and experiences. By fostering a culture of respect, ITSM teams can create a positive and collaborative environment, enhancing overall engagement and productivity.

## Conclusion

Incorporating the concept of Ichi-go Ichi-e into ITSM practices offers a fresh perspective on engagement. By cherishing each interaction as unique and significant, ITSM professionals can build stronger relationships, enhance customer experiences, and promote continuous improvement. Embracing Ichi-go Ichi-e can transform the way ITSM teams connect with users, leading to more meaningful and impactful engagements.

As we move forward in an ever-evolving technological landscape, let us remember the wisdom of Ichi-go Ichi-e and the value of each unique encounter.

Enhancing ITSM Engagement through the Concept of Ichi-go Ichi-e

Greetings!

Governance of how an organisation uses AI will be a key factor in how much value/benefit can be realised in the future.

As AI becomes increasingly present in our everyday lives, both at work and at home, more domestic and international governments will attempt to exert control through legislation and regulatory standards.

This will naturally lead to organisations needing to understand, in-depth, how they are using AI and what data sources/structures are being used so they can monitor, manage and maintain compliance with all of the applicable statutes and industry best practices.

Areas that will need careful consideration include the following.

**Business case/usage**

A clear idea of what AI can and cannot be used for should be established. This should establish firm use cases and decision trees that teams within the organisation can follow if they want to implement AI to tackle specific scenarios.

**Intellectual property**

An organisations IP must be protected to ensure that, through the use of AI, whether public platform or internet connected private platform, it isn’t exposed to the threat of theft or loss.

**Legislative compliance**

The introduction of new legislation, such as the ~[EU AI Act](https://artificialintelligenceact.eu/)~, organisations have new statutory obligations to meet or face significant fines and damage to their reputation.

**Organisational culture/Skills evolution**
At this stage, AI introduces new and exciting, tools that are lauded as being able to improve an organisation’s productivity by percentages that have not been achieved since the Industrial Revolution. However, picking up a spanner doesn’t automatically make me a mechanic! 

Therefore, an organisation needs to define, implement and continually refresh its culture to ensure that its resources make effective use of these new tools and that the expected Return On Investment is achieved.

An organisations ITSM capability will need to be at the core of this, ensuring that the appropriate strategies and plans are in place to enable business AI agility whilst robustly managing the associated risks.

“But how?!”, I hear you cry…. Well here are some of my thoughts on the subject.

**Robust** enterprise architecture to provide

- architectural patterns and reusable technology stacks, that evolve with business needs and technology improvements
- enterprise management solutions that can manage, monitor, alert, and report on the organisations AI solutions
- automated and integrated tracking of key data assets that underpin an organisations AI implementation e.g. Large Language Models

**Adhere** through the use of policy and process controls designed to meet the regulatory requirements of the geographies that the organisation operates in.

**Effective** audit and reporting capabilities that can analyse information, in real-time, and facilitate escalations, as appropriate, within the organisation so that risks can be managed. The more this can be automated, possibly with the use of AI for analysis, the more robust this will be.

**Enforce** policies, at the operational and technology levels, to control
- usage (appropriate and inappropriate)
- data separation to safeguard company intellectual property
- user access controls

**Invest** in the skills of your team, and encourage experimentation with new technologies. AI is growing at an unprecedented pace and so organisations must adapt quickly to meet business demands.

In summary, ITSM capabilities must embrace the organisations use of AI and provide guidance and guardrails. How fast they can evolve with business needs will have a significant impact on the organisations ability to manage risks and realise value from AI.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

AI Governance

Greetings!

In this weeks article I will be talking about the concept of a Configuration Management Database (CMDB) and whether it is still relevant in today’s fast paced I.T. world.

## What is a CMDB?

A CMDB is, in essence, the main tool that the Service Asset & Configuration Management function uses to track the state of “stuff”. In the context of an I.T. service “stuff” is anything that the services needs to manage and control the state of in order to be able meet its obligations e.g. levels of service, compliance requirements etc.

Commonly each instance of “stuff” is referred to as a Configuration Item (CI), at least in the world of ITIL&reg;, and has a number of attributes against which pertinent information is stored. For example, the CI record, in a CMDB, for a laptop may hold the following information; 

- Make
- Model
- Warranty Status
- Operating System
- Assigned Owner
- Related Cost Centre
- Previous Incidents
- etc

This information can all be useful to various roles and functions within an I.T. service, for example;

- Operating System - can be used by Technical Management to know which devices to patch with what updates
- Related Cost Centre - can be used by Financial Management for cross charging
- Previous Incidents - may be useful to the Service Desk when trying to diagnose a  reported issue

Now all of this information is undoubtedly useful, but does it all need to be kept in (and typically manually replicated into) a monolithic CMDB?

## Is there a better way?

Better, in a sense of being more efficient, and less prone to human error? Absolutely! In the following sections I will expand upon this and describe the options in a toolset agnostic way.

### Federation

![Federated CMDB!](https://res.cloudinary.com/xenos-design/image/upload/v1689867576/ITSM/CMDB_Federation_zybvzx.png)

The federation model is where the base minimum of data is held in the CMDB to enable ITSM processes but, when further information is required, it points to the single source of truth for that data type. 

The guiding principle is here “Right data, right place and only accessible by those who need it, when they need it”.

This model is my preference when there is a complex service environment spanning multiple delivery models and architectures.

### Integration

![Integrated CMDB!](https://res.cloudinary.com/xenos-design/image/upload/v1689867576/ITSM/CMDB_Integration_p9lipe.png)

The integration model is where the various primary data sources,  that underpin delivery of your service(s), feed into your central CMDB (typically within your ITSM toolset).

Automation is the underpinning point here. This approach can work well where integrations have been proven to work, and most leading ITSM tools will come with standard integration with other leading tools, but I am always conscious that anything new requires time and will undoubtedly need iteration to get it right.

## Conclusion

The CMDB still has an important part to play in delivering and controlling services to ensure consistency and quality.

However, the days of the CMDB being deployed as a single entity, and source of truth for everything, should be reconciled to the past.  Instead consideration should be given to who really needs the information and how that information visibility requirement should be met.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

Config Management Database (CMDB)

Greetings!

This week we will be diving deeper into what an XLA (eXperience Level Agreement) should be and look at some examples.

If you are not familiar with XLAs then my previous article XLAs - avoiding watermelons give a useful introduction.

An XLA is a combination of objective and subjective measures that give you a balanced measurement of the impact of the service, with a weighting towards how the “users” experience the service. So let’s look at some examples of what that means in reality.

## Balanced Measurement

### Objective and Subjective

An objective measure is based on data derived, usually, from the systems or toolsets that are used to manage either ITSM processes, e.g. Incident Management tools, or IT systems, e.g. Application Performance Management.

The objective measures, that help to make up an XLA, are important because they bring context and meaning to the subjective measures.

For example, if you have an XLA that is measuring user satisfaction with your Service Desk, then objectively measuring the number of contacts with the Service Desk gives context.

The context is important because if your subjective result shows 50 negative responses then this sounds, on the face of it, to be a bad thing. Now this result is never a “good” thing but, when taken into the context of 20,000 contacts in the Service Desk in a measurement period, thus meaning a 0.25% negative response, it doesn’t sound so bad.

But, is this really an accurate measure?

Again the answer revolves around context. If 20,000 contacts result in 20,000 survey responses, your subjective source, then this could well be a valid measurement. However, this is unlikely to be the case.

So, another objective measure would be the number of survey responses received in your measurement period. For the sake of novelty let’s say you get 420 completed surveys. Now this changes your perspective quite significantly.

Your original 0.25% becomes 11.9%, which is quite a dramatic change and suddenly things don’t seem quite so good.

However, what cannot be emphasised enough is that XLAs are for driving improvement in areas that are important to the business to that the service(s) are being delivered.

An XLA is neither a carrot to reward a service provider, nor is it a stick with which to beat one. An XLA is a point on the horizon that both customer and supplier are walking towards together. The measurement points are simply there to identify whether they are walking forwards, standing still or are walking backwards.

Source: Steven Godson

So, what we have, so far, is a number of objective measurements, which are as follows.

- Total contacts to a Service Desk
- Total number of survey results and as a % of total contacts
- Total number of positive/negative survey responses and their respective percentages

So, what’s next? Well, the next thing is to define what good” actually looks like in your context and ensure balance in your results.

### What is “good” anyway?

What good means, in the context of XLAs, will greatly depend on what you are using XLA measurements to achieve.

However, it is true to say that whatever it is there needs to be acknowledgement that the target chosen should be realistic and is a target to be worked towards rather than there being an expectation that it will be achieved from day one.

It is also sensible to apply a balanced approach to reporting the measures that combine to give the overall XLA measure. A pragmatic way to do this is to apply weighting to each of the component measures based on their importance/significance. The weighting is a % split across the number of measures you are using to calculate your XLA score.

For example, if you are working towards users adopting self-service and digital channels, your XLA measurement may look like this.

![XLA_Example_001_ndly20](https://res.cloudinary.com/xenos-design/image/upload/v1689089665/ITSM/XLA_Example_001_ndly20.png)

- **Weighting %** - this weighting allows you to apply a balanced, business-focused, view whilst maintaining transparency

- **Metric** - the objective and subjective numbers captured in the reporting periods

- **eXperience Performance Indicator** - the XPIs expressed as a % of the relevant total

- **XLA Score**- the weighting applied to the XPI

- **XLA achievement**- the figure that you would be reporting for the given measurement period

The examples of what an XLA could be used to measure are;

- Gauging the impact of a new supplier or service, so that improvements can be identified

- Measuring the end-user experience (UX) for one or more applications, as long as there is a subjective element to the measurement

- Impact of a change program

Summary

In this article, I have talked about what makes up an XLA, and the mindset required, and provided a real-life example. Hopefully, this article has been of some use and has given you a good idea of the types of areas that need to be addressed.

I wish you well on your ITSM journey…

Inside an XLA

Greetings!

In this week's article, I will be talking about how ITSM can co-exist with DevOps so that the ITSM teams are not seen as blockers and the DevOps team(s) are not seen as “chaos monkeys”.

This can be achieved through two fronts;

1. Culture
2. Understanding and agreeing on the touch points

## Culture

It is easy to say that a good working culture, within an organisation, leads to better interworking between departments and the teams within them. But what does that mean in practical terms when you are aspiring to get ITSM and DevOps working together?

In my experience, this means addressing the following areas, in a program of change that is sponsored from the top but driven from the bottom up.

- Open and respectful dialogue - so that issues can be raised and ideas discussed
- Willingness to change - adopting a one-team approach
- Continual improvement mindset - striving to do better

## Touchpoints

The below diagram is my view on where the key touch points are between ITSM and DevOps as models. I have deliberately used ITIL terminology for the ITSM side, mainly because it is widely used around the globe.

![DevOps and ITSM!](https://res.cloudinary.com/xenos-design/image/upload/v1687544857/ITSM/ITSM_and_DevOps_Interaction_n60p55.png)

### Ticket Creation / Update / Resolve

- The resolution of an Incident or Problem may require the DevOps team so, unless it is critical, it would need to be cross logged onto the appropriate Product Backlog
- A Service Request could be a conduit for “asks” being raised onto a Product Backlog
- Depending on how rigorously the deployment of Release Packages to the production environments is controlled, the DevOps team will be raising Operational Request for Changes (RFCs) to get approval to deploy. This can be seen as a bottleneck that restricts business agility, so consideration must be given to;
	- Agreement on what can be automatically approved based on specific criteria being met i.e. tests passing
	- Pre-agreed windows for deployment

### Authorisation

The Operational Change Management process will provide authorisation to deploy based on what criteria is either defined in the Change Management policy document or as agreed operationally for each Product. 

The key to this is finding the appropriate balance between the business's needs;
	- frequency and rapidity of change
	- ensuring that users / customers, depending on your business environment, do not suffer from change fatigue
	- maintaining the required levels of service availability
	- minimising risks

### Pre/Post Baseline Report

The SACM (Service Asset and Configuration Management) team is responsible for ensuring that there is accuracy in the configuration of the service(s). 

The DevOps team relies on this information to;

- know what *good* looks like, so they can restore the service back to its baseline configurations in the event of an Incident
- identify what might be impacted as a result of planned changes

The typical advice, which I broadly agree with, is to use a CMDB (Configuration Management Database)  to hold this data. 

My view on this is that a CMDB should be seen as a collection of federated data / information repositories that are specific to the type of data / information that is being managed e.g. a Software Configuration Manager tool (CICD pipeline or Github etc) or Wiki / Knowledge Articles (ITSM tool, Gitbook, Confluence).

### Knowledge Share

This touchpoint is important to ensure that changes to the service(s) are understood by the Service Desk, and other support tiers, so that they know what to do when an Incident occurs or a user phones up to query something.

It is also important from a user perspective so that they;

- know what has changed and what, if anything, that change means to them
- can access self-service knowledge to resolve issues themselves

The DevOps team also needs a flow of knowledge not them so that they can understand;

- whether the knowledge that they are providing is actually of use
- how users are reacting to the visible changes that are being made

## Summary
In this article, I have described the key touchpoints between ITSM and DevOps and why they are important. Hopefully, this article has been of some use and has given you a good idea of the types of areas that need to be addressed.

I wish you well on your ITSM journey…

ITSM and DevOps

Greetings!

In this article I will be exploring the concept of the Service Design Package, what it should be and what should be included within its scope.

## What is a Service Design Package?
Service Design Package, abbreviated to SDP, is a term that initially appeared in ITL&reg; v3 which was first published in 2007, is a collection (the package part) of documents and artefacts that describes;  

- Scope - what a service is
- Users / Location - who it can be consumed by
- Compliance - the business, regulatory and statutory constraints that it has to exist within
- Requirements - the warranty, utility, quality and satisfaction characteristics that it has to meet
- Processes - that will be used to manage the service on a day to day basis
- Products - the tools that will be used to deliver the service. This includes everything from SaaS solutions through to bespoke applications
- Partners - the sub-contractors you use to deliver parts of the service
- People - the individual roles and functions that will govern and manage all of the above

> “Good service starts, and ends, with having great people..”. Source: me

## What should it be?
An SDP should be the definitive source of information for anyone requiring an understanding on what a service should deliver and how it delivers that service.

It should provide different views so that it can be used by different stakeholders with different perspectives.

It should be useable, accessible and written in plain English (or whichever language is relevant).

It should be a number of complimentary, and not over lapping, documents that are regularly reviewed and maintained to ensure currency.

## What should be included within an SDP?
The following is based on my years of experience of designing and building ITSM solutions as part of a Managed Services provider. 

Depending on your situation e.g. internal servicer provider (“The IT department”) or a Managed Service provider (external organisation to the one buying the services), you may consider some of these to not be relevant.

And, depending on your situation, you may be correct. However, all of the following areas should at least be considered when creating an SDP.

### Service Description - the what and the when…

A Service Description is the shiny document that, depending on your scenario, your customers and / or users will read to understand what the service is that they are consuming / paying for.

The common scenarios under which these tend to exist are;

- Contractual Service Description - part of a customer / supplier legal agreement where what is being delivered needs to be concise
- Service Catalogue (Public) - part of your businesses website / marketing collateral where you describe the services you offer
- Service Catalogue (Internal) - the portal where your internal IT department lists the services that users get as standard or that can be ordered

However, there is a common set of information, described below, that a Service Description should cover.

SCOPE - this is where you clearly describe what the service is and what it will, and as importantly will not (exclusions), delivers.

SERVICE LEVELS & PATTERNS - this is the level of service that a consumer should expect to receive and when the service will be available to them.

GOVERNANCE - how the service will be governed, who the key points of escalation are and what the measurement periods will be.

CHARGES - inescapable, but possibly less relevant in an internal IT department setting, how much the customer will pay for the service(s) that you are describing is important.

### Service Management Design - the how and tho who…

A Service Management Design (or Architecture or Blueprint or…) is the document where you describe how the service is going to be put together to deliver the service.

It covers the various building blocks needed, and how they interact, to deliver the service(s) covered by the SDP.

Typically, in no particular order, this includes;

SCOPE - this is where you clearly describe what the service is and what it will, and as importantly will not (exclusions), delivers.

RCTM - the Requirements Capture and Traceability Matrix where all the requirements that the service(s) need to meet are captured.

COMPLIANCE - the legislative, regulatory and industry standards that the service(s) need to comply with. Examples include ISO20k, ISO27001, Payment Card Industry (PCI) etc

UTILITY / WARRANTY - what the service(s) provide functionally, the *utility*, and when the customer / user can expect the service to be available to them, the *warranty* or Service Levels.

PROCESSES - the ITSM processes that need to be used for the service(s), whether there is any “localisation” needed or whether bespoke processes are needed.

TOOLSETS - the shiny toys that the service and support functions will use to underpin the ITSM process and technical activities required to manage the service. Given the availability or relatively mature and emergent technologies, the following should be considered;

- Integration
- Robotic Process Automation
- Artificial Intelligence
- Augmented and Virtual Reality
- Smart Locker / Vending solutions
- Self-healing systems

DATA MAP - crucial to both understanding where the data that will feed into your billing and performance measurement of the service, as well as helping you to understand your position as it relates to data residency and access legislation / regulations.

> Data is like garbage. You’d better know what you are going to do with it before you collect it. - Mark Twain

ROLES & FUNCTIONS - the individual roles and functions, within your organisation, that will perform day to day management or technical support functions to support the service(s). Examples are Service Desk, Security Operations Centre, Service Delivery Manager or Release Management.

PARTNERS / SUPPLIER MANAGEMENT - the third parties, and how they will be managed / governed, they will deliver aspects of the service(s). Thought needs to be given as to how Service Levels will be flowed down to them.

INFORMATION SECURITY - either described separately, or interwoven into all of the above, a description of how Information Security will be managed against the defined Information Security Management System (ISMS).

> It takes 20 years to build a reputation and few minutes of cyber-incident to ruin it. - Stephane Nappo

RAID - the identified Risks, Assumptions, Issues and Dependencies of the service(s), both for the transition to live and ongoing.

TECHNICAL REFERENCE DOCUMENTS - such as…
- Enterprise Architecture
- High Level Designs for Networks, Applications, Infrastructure, Integrations, Enterprise Management, Data Management
- ISMS, Role Based Access Controls etc
- Disaster Recovery, Backup, Recovery and Data Retention 

### Ops Policies, Processes and Procedures

A service can be described beautifully and designed to within an inch of its life but, when the brown and sticky hits the spinning blades, it is the operational processes and procedures, based on well thought out policies, run by well trained people that will see you through. Consideration should be given to…

- Incident, Problem and Event
- Call Handling, Knowledge Articles and escalation management
- Major Incident Management
- Change (Normal, Standard and Emergency), Release, Knowledge and SACM
- Information Security, SIEM, Access Control etc
- Applications Management, Agile and DevOps
- Capacity and Availability
- IT Service Continuity
- Technical Management, Patch Management, On Premise vs Hybrid vs Cloud and Technical Refresh
- Request Catalogue and Fulfilment
- Management Information, Billing and Invoice to Cash
- Continual Service Improvement

## Things to avoid…

Based on my, not inconsiderable experience, try to avoid the following.

- Trying to fit all of the above into a single document, it doesn’t work and creates a monolithic document that no-one, other than insomniacs, will want to read
- Re-inventing the wheel, re-use is awesome and helps to create consistency (as long as it is consistently good!)
- Repetition, say it once and cross reference, where practical. Adopting a Document as Code approach can greatly help with this 

> In our company, we all have 2 jobs: 1) to do our job and 2) to improve it - Toyota

## A final word…

Ultimately the SDP scope you use has to meet the needs of the business environment that you are working in. Hopefully this article has been of some use and has given you a good idea of the types of areas that need to be addressed.

I wish you well on your ITSM journey…

Service Design Package

Greetings!

This weeks article is dedicated to is XLAs (eXperience Level Agreements) and will answer:

- What are they?
- Should you care?
- How can they be used?

## What is an XLA?
A couple of quotes to start us off…

> XLA is a powerful new addition to the traditional IT Service Level Agreement (SLA). One that builds on the SLA concept by measuring human sentiment and using this to break down silos and think and act from the perspective of a user. 
*Source: [Giarte.com](https://www.giarte.com)*

> Xperience Level Agreement (XLA) is the *concept* of consensus between IT service provider and consumer regarding the desired human experience and business impact.  
> 
> It is also an *agreement* that extends the scope of the output-oriented Service Level Agreement (SLA) to describe the collaboration, experience, and business impact associated with IT services – the outcome. This outcome-oriented document defines the agreed goals, metrics that indicate achievement of the goals, and procedures for collaboration.
*Source: [www.xlaconsortium.com](https://www.xlaconsortium.com)*

In my opinion, both of the above quotes work quite nicely.

An SLA is purely an objective measure based on metrics that are gather from tools (ideally). It should be unimpeachable. 

However, beware of watermelons… which is where your shiny SLA dashboard or report is a field of green, but your customer still isn’t happy! This usually signifies you are not measuring the right things.

An XLA is a combination of objective and subjective measures that give you a balanced measurement of the impact of the service, with a weighting towards how the “users” experiences the service.

## Should you care?
Yes, yes you should… assuming that you are providing a service to a customer  rather than a utility type product that is positioned as being a “service”.

## How can XLAs be used?
XLAs can be used in a number of ways.

- Drive a specific business outcome e.g. adoption of digital channels to drive quicker resolution for users
- Improve the relationship between supplier and consumer by measuring what actually matters to your customers and users
- Gauging the impact of a new supplier or service, so that improvements can be identified
- Measuring the end user experience (UX) for one or more applications, as long as there is a subjective element to the measurement
- Impact of a change programme

The possibilities are varied. The key is having the subjective measure as part of any XLA calculation, ideally captured in a consistent way e.g. using a user survey tool.

However, XLAs should *not* be used as a stick to beat a supplier of services with. Rather they should be entered into as a joint exercise between the Service Provider and Customer to drive improvements.

In future posts I will be diving deeper into this space, so keep an eye open!

XLAs

Greetings!

In this article I will be looking at *Agile Service Management&reg;* (ASM) and how it can be practically implemented. This will be based on the real world experience I gained in my 12 years as a Service Architect.

## What is ASM and where did it come from?

ASM is an approach to developing and maintaining ITSM processes. It was developed by the DevOps Institute&reg; in response to the perception that ITSM can be a blocker to the speed and agility of delivering benefit to the business.

So ASM is essentially using the Scrum, but instead of developing software you are developing processes. The following diagram compares ASM to pure Scrum and identifies key differences in terminology and cadence.

![Agile Service Management!](https://res.cloudinary.com/xenos-design/image/upload/v1687715150/ITSM/ASM_high_level_diagram_v0.1_brkh3d.jpg)

So, as you can see, the key differences are;  

- Scrum Master = Agile Service Manager  
- Product Backlog = Process Backlog (or CSI Register if it is a mature process)
- Product Owner = Process Owner  

## Example Implementation: Developing the Service and Support Model

This example of implementing ASM is where I was working with a client, who were creating a new business application using SCRUM to manage the software development, and there was a need to align the development of the service management and support model in alignment with the sprint planning and cycles.

This new application was going to be supported by a well established and mature support organisation. This meant that I didn’t have to look a standing up new processes, rather that I needed to analyse what needed to be designed and implemented to support the smooth transition from project to live service.

What I ended up with, as an output of the analysis, was a number of *Epics*, spanning the various processes, functions and tools, each of which had a number of high level *User Stories*. 

These *User Stories* were classified as either Enablers, which meant they needed to be completed before further work could be undertaken, or Functional, which were delivering specific elements inline with the delivered output from the software development sprints.

Then I brought all of the key protagonists together for a *Backlog* refinement and initial sprint planning session. This turned out to be invaluable as we were able to refine some needs, re-align others and produce the *Sprint Backlog* for the enabler sprint and the first functional sprint.

These sprints went well, or at least better than I was expecting given how new the approach was to all parties, and the project was delivered successfully. 

The following actions / activities certainly paid dividends;

- Establishing the *Minimum Viable Product* (MVP) is less straight forward in a well established ITSM model than if you are building some thing new, so allow time for this, listen to opinions but never be afraid of challenging the “norm” as, just because something is done in a certain way it doesn’t mean it is the best or most efficient way
- Engaging with the local process owners early on, and taking them through the ASM&asm; approach, and listening to their concerns helped to smooth the path to adoption
- Working closely with the software Product Owners and Solution Architects enabled early identification of challenges and producing collaborative responses 
- Acknowledging that issues arise in live operations, that may require the “service development” teams focus, and allowing a reasonable allowance in the *Sprint Plan* worked well and allowed us to meet expectation
- Stabling the correct routes of escalation, so that blockers can be removed as soon as possible, is essential to maintaining the cadence of the team

## Moving Forwards…

In my opinion the ASM approach can be very useful when you need to deliver and maintain an ITSM model for a software product where SCRUM, or another form of Agile, is used. However, as with any tool, it is not a one size fits all answer, so give serious consideration to the environment in which you want to use it.

I recommend that you go to the [DevOps Institute](https://www.devopsinstitute.com/skilbooks/agile-service-management-guide/) site and read about ASM further. 

If you decide that you want to use ASM then there are a couple of certification courses that you can attend, both developed and licensed by the DevOps Institute.

These are *Certified Agile Service Manager* (CASM) and *Certified Agile Process Owner* (CAPO). I have attended both of these courses, and gained the certifications, and see there is a lot of content that is repeated so attending one or the other, depending on what role you will be in, should be suffiicient to get a good baseline of understanding.

I hope that you found this article useful and I wish you good fortune in your ITSM journey.

Agile Service Management

Greetings!

So, assuming you are relatively new to it, I thought I would give a high level overview of what ITSM is.

ITSM is an acronym, we use a lot of these, for Information Technology Service Management.

Since the early days of I.T. there has been a concept of “managing” the services that customers were buying. Initially this was very limited to support the products (hardware or software) that were purchased and, in my opinion, was very much there to drive additional sales rather then deliver any tangible value beyond that derived from the products.

Towards the end of the 1980’s the Central Computing and Telecommunications Agency, a government department in Great Britain, developed a framework for managing IT infrastructure. This methodology was called ITIL&reg; (IT Infrastructure Library), and was series of books that described how IT could be managed in a consistent way. It is now owned by AXELOS&trade;.

My first introduction to ITIL&reg; was in the late 1990’s / early 2000’s as I moved up the career ladder. At that point ITIL&reg; v2 was out and predominantly focused on two areas Service Delivery (SLAs, BCDR etc) and Service Support. My enduring memory is sitting two very long, and handwritten, exams after 2 weeks of training, which felt quite hellish at the time.

Since then ITIL&reg; has kept evolving with v3 coming out in 2007 and v4, the most recent iteration, coming out in 2019.

One of the things I have always found fascinating in this areas is the continual evolution of how close an “IT Department” should be to its “Customer” from a relationship and goal alignment perspective. Initially coming across as quite standoffish through to being closely interwoven with how the business operates.

Also that ITIL&reg; has never positioned itself as a standard that must be followed to the letter. Rather you _adopt_ the methodology and _adapt_ it to the needs and constraints of your organisation. Thankfully this message has never changed but, what has grown up along side this methodology, are a number of other frameworks and standards, such as:

- _[Microsoft Operations Framework](https://learn.microsoft.com/en-us/previous-versions/tn-archive/cc506049(v=technet.10)?redirectedfrom=MSDN)_ - based on ITIL, that came out in 2008
- _[ISO 20000-1](https://www.iso.org/standard/70636.html)_ - the international standard for IT Service Management. This has been heavily influenced by ITIL evolution over the years and could be considered the hard stick for what “good” looks like
- _[IT4IT](https://www.opengroup.org/it4it)_ - developed by The Open Group&trade; who, among other areas, own the TOGAF framework for Enterprise Architecture (I am a big advocate of this) , this is a architectural model for delivering and managing IT service. There is a lot of crossover, in my opinion, between this and ITIL&reg; v4 which makes them very complimentary
- _[Agile Service Management](https://www.devopsinstitute.com/skilbooks/agile-service-management-guide/)_ - developed by The DevOps Institute, which heavily focuses on service management process development as a “product”. Think scrum for process development and maintenance and you will get the picture.

Now, fascinating as this potted history is, it doesn’t quite answer the question of what ITSM actually is.

One definition of ITSM is

> IT service management (ITSM) is a strategic approach to design, build, deliver, operate, and control information technology (IT) services offered to customers. Source: Wikipedia.

This is an ok, if somewhat dry, statement but misses a fundamental point, which is that IT, as a business function / capability, _MUST_ be aligned with the operational, regulatory and governance needs of the business that it delivers to.

If this isn’t achieved the IT will typically be seen as a “problem child”. Sadly even today, this kind of mis-alignment between the business needs and what the “IT department” thinks it reason for existing is, still exists.

Now when you get into the world of Managed IT Services e.g. those procured by a business from a 3rd party organisation, the original definition is still ok, but there still needs to be that alignment between the _consumer_ and _provider_ of IT services, albeit constrained by the boundaries of a commercial agreement (contract) of some kind.

I will be expanding on some of these areas in future posts.

I will sign-off at this point but watch out for future posts and discussions.

ITSM tales from the deep...

AI driving ITSM

Embracing Service Architecture

Embracing the future

Service Excellence

Service Excellence

Service Excellence

Service Excellence

Service Excellence

Service Excellence

Service Excellence

Service Excellence

AI Governance

Config Management Database (CMDB)

Inside an XLA

ITSM and DevOps

Service Design Package

XLAs

Agile Service Management

An introduction to ITSM