Week 14 - Event & Knowledge Management
December 2025
When ITSM Becomes About Awareness and Collective Memory. Week 14 felt different from all the weeks before. Instead of resolving incidents or managing changes, this week asked me to understand two practices that work quietly in the background: Event Management, which gives IT the "eyes" to detect early signals of trouble, and Knowledge Management, which gives IT the "memory" to solve problems faster and smarter.
This week helped me see that stable IT services are not only built from good processes - they rely heavily on constant monitoring and good knowledge flow. Without these two practices, IT teams would always be blind and forgetful.
Part 1 - Event Management
My assignment began with the fundamentals: Event Management detects meaningful changes in the state of a service or configuration item. But as I explored the mind map in my file, I realized it is more than just alerts and logs - it is the early warning system that tells IT whether a service is healthy, degraded, or failing.
What Counts as an Event
The examples were clear: Indicators of upcoming failures such as high CPU usage, increasing latency, packet drops. Triggering automated responses like restart a process or scale an instance. Notifications to the Service Desk when customer-impacting thresholds are reached. System-generated updates from tools like monitoring dashboards, sensors, and application logs. These events form "signals" that IT uses to predict issues before incidents occur.
The Event Management Flow
The process flow is structured into four key steps: Event Detection where tools, sensors, dashboards, or applications detect anomalies. Event Notification where alerts are generated and forwarded to the appropriate teams or systems. Event Filtering and Correlation where not all events matter - some are noise, and critical ones must be correlated to find patterns or early warnings. Event Response which could be automated (auto-scaling) or manual (raising an incident). This flow helped me appreciate how Event Management is what allows IT teams to act before users complain.
Part 2 - Knowledge Management
If Event Management is the "eyes," then Knowledge Management (KM) is the "brain." Knowledge Management is defined as a structured process to collect, organize, validate, store, and share knowledge so the right information reaches the right people at the right time.
The Components of Knowledge Management
The knowledge ecosystem includes: Knowledge Repository and Knowledge Base, Standard Operating Procedures (SOPs), Templates and Guidelines, and Knowledge Articles. These repositories ensure that teams are never solving the same problem twice.
The Role of the KEDB
The KEDB stores every Known Error and its workaround so the Service Desk, Problem Management, and Incident Management can restore services faster. This echoes what we learned back in Week 5 - KEDB is how organizations turn painful incidents into quick solutions.
The Knowledge Management Lifecycle
The lifecycle includes: Knowledge Identification where we decide what knowledge the organization needs. Capture and Creation by extracting tacit and explicit knowledge. Review and Validation through SME verification. Storage and Maintenance by putting content into SKMS and Knowledge Base. Publishing and Sharing by distributing knowledge to users and IT teams. Usage and Improvement by using knowledge and refining it through feedback. This cycle showed me one important truth: Knowledge is not one-time documentation - it is a continuous improvement loop.
Part 3 - Group Activity: Mapping & Connecting ITSM Practices
For the group task, my team created a large sticky-note mapping exercise to connect Event and Knowledge Management with all other ITSM practices we learned this semester. The sticky board was divided into four clusters: Event Management (Pink), Knowledge Management (Green), Related Practices (Blue), and Scenario Notes (Yellow and Purple).
What We Mapped
We connected scenarios like login failures, unstable Wi-Fi, slow system performance during peak hours, service degradation, incident escalations, wrong configurations, outdated knowledge articles, and missing diagnostics. We then mapped how each scenario would flow through multiple ITSM practices, such as: Event to Incident to Problem to Change to Release to CMDB to SLM.
The Complete Flow Visualization
The bottom diagram shows the complete "connecting the dots" flow - a long chain visually tracing how an event triggers a cascade through every practice until the issue is resolved and knowledge is updated. It was the most holistic visualization of ITSM we have done so far. This task helped me see ITSM as a living system: everything is connected - an event triggers an incident, which can become a problem, which requires a change, which updates the CMDB, which then must be reflected in the knowledge base and catalog.
Reflection
Week 14 was a reminder that ITSM is not just about solving issues - it is about detecting signals early and sharing knowledge continuously. Event Management makes organizations aware, alert, and proactive, while Knowledge Management ensures teams never lose what they have learned. And the group mapping activity brought everything together, showing how these two practices support every other part of IT Service Management. This week helped me understand that reliable IT services depend not only on hard skills or tools, but also on visibility, memory, and collaboration.
