1. Resolving a fault addresses the symptom; removing the problem addresses the cause
Even if a malfunction in a steriliser appears to be fixed, if the same issue recurs within a few weeks, it means the symptom was treated — not the cause. With an engineering perspective, our main goal is to identify the root structure generating the problem and eliminate it permanently
This article explores two systematic approaches we apply to tackle technical challenges in sterilizer devices
5W1H Analysis and Ishikawa (Fishbone) Diagram.
Starting with the 5W1H Method: Define the Problem
With this method, we clearly outline the boundaries of the problem
| Question | What Does It Provide? |
|---|---|
| What ? | What is the problem? |
| Where ? | Where is the problem with the device? Or on-site? |
| When ? | When it appears |
| How ? | Which action triggers the problem? |
| Why ? | What are the possible causes based on the initial observation |
| Who ? | Which user, during which operation |
Application Example – Stericool Device:
- What? → The vacuum does not start
- Where? → Device rear module, valve 4
- When? → After the 2nd cycle, if the door remains open
- How? → Frequent intervention between stop/start
- Why? → The valve command is given, but no feedback is received
- Who? → New operator
Ishikawa Diyagramı ile Görselleştir
Problem ortaya çıktıysa, onu etkileyebilecek tüm başlıkları masaya yatırmak gerekir. Ishikawa diyagramı bunu görselleştirir:
Başlıca dallar şunlardır:
- Makine: Valf, pompa, PLC, sensör
- İnsan: Operatör, teknisyen, eğitim düzeyi
- Yöntem: Prosedür eksikliği, düzensiz kontrol
- Malzeme: Su, H₂O₂ kartuşu, basınçlı hava
- Ortam: Nem, sıcaklık, altyapı
- Ölçüm: Geri bildirim eksikliği, validasyon sorunu
Aksiyon Planı Çıktısı:
- Valf sensörü sinyal üretmiyor
- Operatör manuel kapatma yapıyor ama sistem bunu anlamıyor
- HMI ekranında sinyal eksikliği için uyarı yok
- Eğitim güncellemesi yok
Sonuç:
“Arızaya değil, sistemin arızaya izin vermesine odaklanmalıyız.”
5N1K ve balık kılçığı gibi yaklaşımlar; sterilizatör gibi yüksek riskli cihazlarda sadece arızayı çözmek değil, arızayı sürdüren koşulları ortadan kaldırmak için kritik öneme sahiptir.
Sizde benzer problemler mi tekrar ediyor?
Cihaz bazlı problem çözme danışmanlığımız için bizimle iletişime geçin.
2.Sterilizatör Cihazlarında Teknik Müdahale Önceliklendirme Nasıl Yapılır?
Giriş:
Sahada sınırlı zaman, sınırlı kaynak ve yüksek baskı… Peki nereden başlayacaksın?
Teknik müdahaleyi “önce neye dokunmalıyım” sorusuyla değil, sistematik önceliklendirme yaklaşımıyla planlamak gerekir.
Müdahale Önceliği Belirlemede 3 Ana Kriter:
1. Kritiklik:
Cihazın hastane işleyişindeki yeri, risk puanı, süreçteki rolü
→ “Bu cihaz çalışmazsa ne durur?”
2. Süreçteki etkisi:
Arıza, sterilizasyon güvenliğini mi etkiliyor, sadece konforu mu?
3. Müdahale kolaylığı:
Parça ulaşılabilir mi? Erişim var mı? Yedek var mı?
Uygulama: 3×3 Öncelik Matrisi
| Kolay Müdahale | Orta | Zor | |
|---|---|---|---|
| Kritik | Öncelikli A | A | B |
| Orta | A | B | C |
| Düşük | B | C | C |
Örnek:
- Sensör arızası → Kolay müdahale / yüksek kritik
- PLC donma → Zor müdahale / çok yüksek kritik
- Kapak switch arızası → Orta müdahale / orta kritik
Sonuç:
Müdahale önceliği teknik bilgi kadar stratejik karardır.
“İlk hangisine dokunursam tüm sistemi çalıştırırım?” sorusunu sor.
3.Bir PLC Arızasını Sadece Kodla Değil, Süreçle Anlamak
Giriş:
PLC arızası genellikle “kod bozulmuş” zannedilir. Oysa çoğu zaman problem yazılımda değil, sürecin kendisindedir.
1. Kodun Ötesine Bak:
- Input sinyali neden geç geliyor?
- Operatör müdahalesiyle sistem çakışıyor mu?
- Delay timer’lar sistem yükünü artırıyor mu?
2. Sistemsel Yaklaşım
İzlenecek Adımlar:
- Kod → Giriş-çıkış senkronu
- Fiziksel test → Sensör & röle doğrulaması
- Proses → Operatör davranışı ve cihaz akışı
- Hata günlüğü → Hangi koşulda takılıyor?
Örnek:
Vakum valfi komutu geliyor, ama vakum başlamıyor.
→ PLC çıkış veriyor ama kontaktör çekmemiş.
→ Kontaktör rölesine gelen kablo gevşek.
Yani yazılım değil, temas problemi.
Sonuç:
Bir arıza kodda görünüyorsa, süreçte gömülüdür.
Kodda hata yoksa, sistem davranışına bak.
4.Teknik Serviste ‘Yedek Parça Değiştirmek’ mi, ‘Mühendislik Yapmak’ mı?
Giriş:
Bazı teknik servis ekipleri cihazı, bazıları sistemi tamir eder.
Arıza çözümünde parça değiştirmek ile mühendislik çözüm üretmek arasındaki farkı konuşalım.
Parça Değiştiren Servis Ne Yapar?
- Arıza → Parça → Yenisiyle değiştir
- Kısa vadeli çözüm üretir
- Arızanın sistemsel nedenine inmez
Mühendislik Odaklı Servis Ne Yapar?
- Neden bu parça yandı?
- Bu parçayı yakan süreç neydi?
- Diğer benzer riskler nerede olabilir?
Örnek:
3 ayda 2 kez valf yandıysa, problem valf değil sistemdir.
→ Basınç pikleri mi var?
→ Sıcaklık dağılımı hatalı mı?
→ Yazılımda valf aç/kapa frekansı mı yüksek?
Sonuç:
Parça değiştirerek cihaz çalışır.
Sistem çözülerek cihaz güvenle çalışır.
5.Sahada Hatalı Cihaz Davranışlarını Simülasyonla Önceden Anlamak
Giriş:
Bazı arızalar oluşmadan tahmin edilebilir.
Doğru teknik simülasyonlar sayesinde “ne olursa ne olur” sorusuna cihaz üzerinden değil, düşünsel olarak yanıt verebiliriz.
1. “Varsay ve Test Et” Yaklaşımı:
Senaryo 1:
Vakum sensörü değer göndermezse ne olur?
→ Cihaz döngüye girer mi?
→ Güvenlik kilidi devre dışı kalır mı?
2. Simülasyon İçin Gerekli Unsurlar:
- Fonksiyon listesi
- I/O haritası
- HMI ekran akışı
- Süreç tablosu
- Alarm senaryoları
Örnek:
Trans otoklavda, sıcaklık sensörü sapma yaparsa döngü sonunda validasyon geçer mi?
Senaryo 2:
H₂O₂ kartuşu boşken döngü başlatılırsa ne olur?
Log sistemi bu hatayı kayıt altına alır
Durum: Kartuş algılayıcı sensör arızalı veya yazılım kontrolü devre dışı.
Olası sonuçlar:
Döngü başlar ama sterilizasyon gerçekleşmez
Hatalı döngüyle “steril” kabul edilen yük, hasta güvenliğini riske atar
Döngü sonunda validasyon verisi eksik kalır
İşletmeci, sonuçları geç fark eder → ciddi kalite vakası oluşur
İdeal sistem davranışı:
Kartuş doluluğu doğrulanmadan döngü başlatılamaz
Operatöre açık uyarı verilir
Sonuç:
Arıza gelmeden analiz yapılırsa, müdahale fırsatı doğar.
Mühendislik, problemi yaşamadan önce çözmektir.
