8D problem çözme, önemli, yinelenen veya farklı işlevleri kapsayan bir problemi ele almak için yapılandırılmış bir yaklaşımdır. Anlık önlemeyi araştırmadan, kalıcı düzeltmeden, doğrulamadan ve tekrarı önlemeden ayırır. Formdan çok disiplin önemlidir: 8D raporu yalnızca sekiz başlığın doldurulduğunu değil, kararların ardındaki kanıtları göstermelidir.
ASQ'nun 8D açıklaması sekiz disiplini ortaya koyar ve bazı kuruluşların ön hazırlık aşaması D0'ı eklediğini belirtir. Aşağıdaki yazılım örneği ve kapanış kontrolleri özgün pratik açıklamalardır. Düzenlemeye tabi veya sözleşmeli işlerde blog kontrol listesini yeterli saymak yerine geçerli gereklilikleri izleyin.
Sekiz disipline genel bakış
| Disiplin | Amaç |
|---|---|
| D1 | Araştırma ve eylem için gereken bilgiye sahip kişileri bir araya getirmek |
| D2 | Problemi kesin olarak tanımlamak |
| D3 | Ara önlemeyle etkilenen kişileri veya çıktıları korumak |
| D4 | Problemin ortaya çıkma nedenlerini ve neden tespit edilemediğini doğrulamak |
| D5 | Kalıcı bir düzeltme seçmek ve doğrulamak |
| D6 | Düzeltmeyi uygulamak ve etkinliğini doğrulamak |
| D7 | Benzer tekrarları önlemek için ilgili sistemleri veya uygulamaları değiştirmek |
| D8 | İşi kapatmak ve ekibin katkısını takdir etmek |
Kullanıldığında D0, yaklaşımın gerekli olup olmadığını ve hangi hazırlığın ya da acil yanıtın gerektiğini belirler. Kuruluşlar aşamaları farklı adlandırabilir. Yerel rapor etiketleri üzerinde tartışmak yerine önemli ayrımları koruyun.
8D'nin orantılı olup olmadığına karar verin
Neden belirsizse, birkaç işlev katkıda bulunuyorsa veya geçici çözüm yinelenen bir kusuru gizleyebilecekse 8D yararlıdır. Müşteri resmi bir düzeltici faaliyet istediğinde ortak bir kayıt da sağlayabilir.
Açık bir düzeltmesi ve düşük sonucu olan küçük, yalıtılmış bir sorun için gereğinden fazla olabilir. Buna karşılık bir güvenlik olayı, ürün güvenliği sorunu veya yasal yükümlülük ek süreçler ve uzmanlar gerektirebilir. Bir 8D raporunun varlığı bunların yerini tutmaz.
Gereğinden büyük bir ekip kurmadan önce problemin sınırını belirleyin. Arızayı, tespit kontrollerini, etkilenen iş akışını ve uygulama kısıtlarını anlayan kişileri çağırın. Sorumlunun grubun yetkisini aşan karar ve kaynaklara ulaşma yolu olsun.
Önleme korumadır, düzeltme kanıtı değildir
Araştırma sürerken önleme maruziyeti azaltır. Örneğin etkilenen çıktıları inceleme için bekletmek veya kusurlu bir yolu geçici olarak devre dışı bırakmak. Doğru seçenek riske ve operasyonel bağlama bağlıdır.
Kontrolün neleri kapsayıp neleri kapsamadığını kaydedin. Kimin kontrol edeceğini, arızaların nasıl üst makama iletileceğini ve kaldırılmasına hangi kanıtın izin vereceğini belirtin. Geçici bir kontrol görünmez rutin işe dönüşürse kendi maliyetini veya riskini doğurabilir.
Güvenilir ve sürdürülebilir olup olmadığını incelemeden “bir manuel kontrol daha ekledik” ifadesini nihai düzeltme saymayın. Birinin istisnai bir adımı hatırlamasına dayanan kontrolü özellikle incelemek gerekir.
Uygulamalı örnek: yinelenen hesap dışa aktarımları
Varsayımsal örnek: Bir hizmet, zaman aşımından sonra kullanıcı isteğini tekrarladığında ara sıra yinelenen dışa aktarımlar oluşturuyor. Destek ekibi yinelenen dosyaları kaldırabiliyor, ancak tekrar sorunu uygulama davranışını, arka plan işlemlerini ve müşteri iletişimini kapsıyor.
D2'de ekip gözlemlenen kapsamı tanımlıyor: belirtilen zaman aşımı koşulunda tekrarlanan isteklerle bağlantılı yinelenen dışa aktarımlar. İncelenen vakaları kaydediyor ve her zaman aşımının kopya oluşturduğunu iddia etmiyor.
D3'te onaylanmış geçici kontrol etkilenen dışa aktarma isteklerini belirleyip incelemeye yönlendiriyor. Ekip kontrolün sınırlarını belgeliyor ve meşru dışa aktarımları geciktirip geciktirmediğine bakıyor.
D4'te araştırmacılar iki ayrı soruyu test ediyor. Yinelenen işin oluşturulmasına ne izin veriyor? Mevcut kontroller neden bunu tespit veya reddedemiyor? Davranışı uygun bir test ortamında yeniden üretiyor ve tekrar denemenin çıktıyı çoğaltmadığı vakalarla karşılaştırıyorlar.
D5 ve D6'da ekip istek işleme düzeltmesini değerlendiriyor, ilgili hata yollarını test ediyor, normal sürüm sürecinden uyguluyor ve tanımlanmış koşulu izliyor. Başarılı bir dağıtım uygulamanın kanıtıdır; tek başına etkinliğin yeterli kanıtı değildir.
D7'de ekip benzer istek yollarının aynı zayıflığı taşıyıp taşımadığını inceliyor. Hangi yolların kontrol edildiğini, neyin değiştirildiğini ve belirsizliğin nerede kaldığını kaydediyor. Kapanışta araştırma kaydını koruyor ve raporu suçlama kaydına çevirmek yerine katkıda bulunanlara teşekkür ediyor.
Raporun yanında bir kanıt günlüğü tutun
Önemli her iddia için kısa bir kayıt kullanın:
- İddia: Önerilen koşul veya mekanizma.
- Kanıt: Yeniden üretilebilen gözlem, kayıt veya test.
- Alternatif açıklama: Sonucu başka ne açıklayabilir?
- Kapsam: İncelenen vakalar veya koşullar.
- Sınır: Kanıt neyi ortaya koymuyor?
- Karar: Kanıt hangi eylemi destekliyor?
Bu günlük, beyin fırtınasında ortaya çıkan bir nedenin yalnızca D4'te yer aldığı için doğrulanmış nedene dönüşmesini engeller. Araştırma birkaç hafta sürdüğünde devirleri kolaylaştırır.
Yinelenen dışa aktarma örneğinde “kullanıcılar iki kez tıklıyor” yeterli değildir. Ekip, yinelenen isteklerin neden ek iş oluşturduğunu ve bu davranışın amaçlanan kontrollerden neden kaçtığını anlamalıdır. Kullanıcı davranışı koşulu tetikleyebilir, ancak sistemin yanıtını tek başına açıklamaz.
Gerekmeden önce kapanışı planlayın
Ekip sırf raporu bitirmek için standardı sessizce düşürmesin diye kapanış ölçütlerini erkenden tanımlayın. Uygulama doğrulamasını, etki kanıtını, önlemeyi kaldırma kararlarını ve kalan risklerin sahipliğini ekleyin.
Gözlem süresinin kusura uygun olup olmadığını sorun. Nadir görülen bir koşul, izlemenin yanı sıra hedefli test de gerektirebilir. Kullanım düşükse veya şikâyetler geçmişte geç geldiyse “bu hafta şikâyet gelmedi” zayıf kanıttır.
Kanıt eksikse koşulsuz “çözüldü” yazmak yerine geçici kararı ve sonraki incelemeyi kaydedin. Önemli kalan riski kabul etmeye yetkili kişiye iletin.
8D'yi günlük ekip öğrenimiyle ilişkilendirin
Bir çevik retrospektif yinelenen sorunu ortaya çıkarabilir veya düzeltici işe kapasite ayrılıp ayrılmadığını inceleyebilir. 8D araştırmasının derin neden ve doğrulama çalışmalarının yerini tutmaz.
Tek bir yetkili eylem kaydı tutun. Retrospektif iyileştirme sürecinde ikinci bir sorumlu ve son tarih oluşturmak yerine 8D eylemine bağlantı verin. İş yükünü, koordinasyonu ve araştırmadan öğrenilenleri konuşmak için basit bir pano formatı kullanın.
Retrospektifte en yararlı soru şu olabilir: “Kanıt toplamayı ne zorlaştırdı?” Bu, her teknik sonucu yeniden açmadan erişim, devir veya belgeleme sürtüşmesini ortaya çıkarabilir.
Sık sorulan sorular
Önleme ile düzeltici faaliyet arasındaki fark nedir?
Önleme, problem araştırılırken anlık maruziyeti sınırlar. Düzeltici faaliyet, problemi üreten doğrulanmış koşulları değiştirir. İkisi de kanıt gerektirir, ancak amaçları farklıdır.
D0 nedeniyle 8D her zaman dokuz adımdan mı oluşur?
Sekiz disiplin D1'den D8'e kadardır. Bazı kuruluşlar hazırlık için D0 ekler. Kararları ve kanıtları açık tutarken kuruluşunuzun veya müşterinizin gerektirdiği yapıyı kullanın.
Yazılım ekipleri 8D kullanabilir mi?
Evet, problem resmi ve işlevler arası bir düzeltici faaliyet sürecini gerektiriyorsa. Örnekleri ve kanıtları yazılım davranışına uyarlayın, ancak doğrulamayı zayıflatmayın veya geçerli olay prosedürlerinin yerine raporu koymayın.