Problem management

If incident management is the fire brigade, problem management is fire prevention. A problem is the cause, or possible cause, of one or more incidents. Problem management asks "why does this keep happening?" and works to stop it, so the same incident doesn’t come back next week.

Jika incident management adalah pemadam kebakaran, problem management adalah pencegahan kebakaran. Problem adalah penyebab, atau kemungkinan penyebab, dari satu atau lebih incident. Problem management bertanya "mengapa ini terus terjadi?" dan berupaya menghentikannya, agar incident yang sama tidak muncul lagi minggu depan.

Key ideasKonsep kunci

• Three phases. Identify problems, control them (analyze and find workarounds), and control errors (manage known errors until fixed).
• Known errors and workarounds. Once the cause is understood, record it with a workaround so the service desk can help users faster.
• Root cause, not blame. Look at systems, processes and decisions, not at who made a mistake.
• Reactive and proactive. Investigate after repeated incidents, but also look at trends and risks before they hurt.
• Not every problem is worth fixing. Sometimes a good workaround is cheaper than a permanent fix. Make that a conscious decision.

• Tiga fase. Mengidentifikasi problem, mengendalikannya (menganalisis dan mencari workaround), dan mengendalikan error (mengelola known error hingga diperbaiki).
• Known error dan workaround. Setelah penyebabnya dipahami, catat beserta workaround-nya agar service desk bisa membantu pengguna lebih cepat.
• Root cause, bukan mencari kambing hitam. Lihat sistem, proses, dan keputusan, bukan siapa yang berbuat salah.
• Reaktif dan proaktif. Investigasi setelah incident berulang, tetapi juga perhatikan tren dan risiko sebelum menimbulkan kerugian.
• Tidak semua problem layak diperbaiki. Kadang workaround yang baik lebih murah daripada perbaikan permanen. Jadikan itu keputusan yang disadari.

Key activitiesAktivitas kunci

A typical flow. Real work loops back and skips steps when it makes sense.

Alur yang umum. Dalam praktik, pekerjaan bisa kembali ke langkah sebelumnya atau melewati langkah tertentu bila masuk akal.

1. IdentifySpot repeat incidents, trends, major incidents or risks.
2. Log and prioritizeFocus on problems with the most business impact.
3. AnalyzeUse 5 whys, timelines or fishbone diagrams to find causes.
4. Record a workaroundPublish the known error so the desk can use it.
5. Fix through changeRaise a change for the permanent fix if it’s worth it.
6. Verify and closeCheck the incidents have stopped, then close.

1. MengidentifikasiTemukan incident berulang, tren, major incident, atau risiko.
2. Mencatat dan memprioritaskanFokus pada problem dengan dampak bisnis terbesar.
3. MenganalisisGunakan 5 whys, kronologi, atau diagram fishbone untuk menemukan penyebab.
4. Mencatat workaroundPublikasikan known error agar service desk bisa memakainya.
5. Memperbaiki melalui changeAjukan change untuk perbaikan permanen jika layak.
6. Memverifikasi dan menutupPastikan incident sudah berhenti, lalu tutup.

How to measure itCara mengukurnya

What each level looks likeGambaran setiap level

Use these descriptions as a quick self-check before running the full assessment. Level 3 is a strong, realistic target for most teams.

Gunakan deskripsi ini sebagai pengecekan cepat sebelum menjalankan asesmen lengkap. Level 3 adalah target yang kuat dan realistis bagi sebagian besar tim.

1. L1InitialThe same incidents keep coming back. Nobody has time to ask why.
2. L2RepeatableSome big issues get investigated by enthusiastic individuals, but findings aren’t recorded or shared.
3. L3DefinedProblems and known errors are recorded in a shared tool, with owners and a standard analysis method.
4. L4MeasuredProblems are prioritized by impact, and the drop in repeat incidents is measured and reported.
5. L5OptimizedTrend analysis finds problems before users notice, and lessons feed design and continual improvement.

1. L1InitialIncident yang sama terus muncul. Tidak ada yang punya waktu untuk bertanya mengapa.
2. L2RepeatableBeberapa masalah besar diinvestigasi oleh individu yang antusias, tetapi temuannya tidak dicatat atau dibagikan.
3. L3DefinedProblem dan known error dicatat di tools bersama, dengan pemilik dan metode analisis yang standar.
4. L4MeasuredProblem diprioritaskan berdasarkan dampak, dan penurunan incident berulang diukur serta dilaporkan.
5. L5OptimizedAnalisis tren menemukan problem sebelum pengguna menyadarinya, dan pelajaran yang didapat menjadi masukan bagi desain dan continual improvement.

Assess problem management in the wizardNilai problem management di wizard →

Using AIMemanfaatkan AI

• Pattern detection clusters incidents that look different but share a cause.
• Log and change analysis highlights what changed just before incidents started.
• Draft known error articles from investigation notes.
• Predictive signals warn about components likely to fail.

• Deteksi pola mengelompokkan incident yang tampak berbeda tetapi memiliki penyebab yang sama.
• Analisis log dan change menyoroti apa yang berubah tepat sebelum incident dimulai.
• Draf artikel known error dari catatan investigasi.
• Sinyal prediktif memperingatkan komponen yang kemungkinan akan rusak.

Real-world example: the Monday morning slowdownContoh kasus: sistem lambat setiap Senin pagi3 min3 menit

A logistics company’s warehouse system is slow every Monday between 8 and 9 a.m. The service desk logs 40 to 60 incidents each week, and each one is "resolved" by asking users to wait.

Sistem gudang sebuah perusahaan logistik melambat setiap Senin pukul 8 hingga 9 pagi. Service desk mencatat 40 hingga 60 incident setiap minggu, dan masing-masing "diselesaikan" dengan meminta pengguna menunggu.

A problem is opened. The analysis finds that a weekly report job was moved to Monday 8 a.m. after a change last year. The known error is published with a workaround, and a change moves the job to Sunday night. Monday incidents drop to almost zero.

Sebuah problem dibuka. Analisis menemukan bahwa job laporan mingguan dipindahkan ke Senin pukul 8 pagi setelah sebuah change tahun lalu. Known error dipublikasikan beserta workaround-nya, dan sebuah change memindahkan job tersebut ke Minggu malam. Incident hari Senin turun hampir nol.

Common pitfallsJebakan umum

• Treating problem management as paperwork after major incidents only.
• Stopping at "human error". Ask why the system made the error easy.
• Recording known errors where the service desk can’t see them.
• Keeping hundreds of open problems that nobody will ever work on.

• Memperlakukan problem management sekadar urusan administrasi setelah major incident.
• Berhenti di "human error". Tanyakan mengapa sistem membuat kesalahan itu mudah terjadi.
• Mencatat known error di tempat yang tidak bisa dilihat service desk.
• Menyimpan ratusan problem terbuka yang tidak akan pernah dikerjakan siapa pun.

Related practicesPractice terkait