CTQ: "İyi Olsun" İsteğini Ölçülebilir Bir Ölçüte Çevirmek

Proje başlangıç toplantılarının çoğunda aynı cümleler kurulur:

"Sistem hızlı olsun." "Stok tutsun." "Rapor beklemeyelim." "Ay sonu rahat kapansın."

Bu cümlelerin hiçbiri yanlış değildir. Hiçbiri gereksinim de değildir. Çünkü proje bittiğinde "hızlı oldu mu?" sorusuna iki kişi iki farklı cevap verebilir ve ikisi de haklı olabilir.

CTQ — Critical to Quality, "kalite için kritik ölçüt" — bu boşluğu kapatan adımdır. İşi şudur: müşterinin ya da kullanıcının söylediği şeyi, üzerinde tartışılamayacak bir ölçüte çevirmek.

VOC'tan CTQ'ya

Başlangıç noktası VOC'tur (Voice of the Customer): kullanıcının kendi cümleleri. VOC'u düzeltmeye çalışmayız, olduğu gibi kaydederiz. Dönüşüm sonra gelir.

Aradaki yol üç basamaklıdır:

İhtiyaç              Sürücü                      CTQ (ölçüt)
(ne isteniyor)       (neyi etkiliyor)            (nasıl ölçülür)
──────────────────────────────────────────────────────────────────────
"Sipariş            → teyit süresi           → Teyit ≤ 4 saat,
 hızlı              → stok görünürlüğü          siparişlerin %95'inde
 onaylansın"        → onay zinciri           → Onay adımı ≤ 2 kademe

"Stok tutsun"       → sayım doğruluğu        → Sayım farkı ≤ %2 (aylık)
                    → hareket anındalığı     → Hareketin sisteme girişi
                                               ≤ 15 dakika

"Ay sonu            → kapanış adımları       → Kapanış ≤ 5 iş günü
 rahat kapansın"    → mutabakat süresi       → Bekleyen mutabakat = 0

Orta sütun en çok atlanandır ve en çok işe yarayandır. "Sipariş hızlı onaylansın" isteğinin altında üç ayrı sürücü vardır; hangisine dokunacağınızı bilmeden ölçüt yazarsanız yanlış şeyi ölçersiniz.

Bir CTQ'nun beş parçası

Yazdığınız şeyin gerçekten CTQ olup olmadığını anlamanın pratik yolu: beş parçası da var mı?

Beşinden biri eksikse CTQ tamamlanmamıştır. En sık eksik kalan ikisi ölçüm noktası ve sıklık'tır — ve tam da bu ikisi olmadığı için ölçüm hiç yapılmaz.

ERP'de ölçüm noktası zaten hazır

Kalite yönetiminde CTQ ölçmek çoğu zaman yeni bir veri toplama düzeni kurmayı gerektirir. ERP kullanan bir şirkette durum farklıdır: veri zaten kayıtlıdır, yalnızca hangi alandan okunacağı yazılmamıştır.

Bu tablonun pratik faydası şudur: CTQ yazarken "bunu nasıl ölçeceğiz?" sorusu genellikle "bu bilgi zaten sistemde var mı?" sorusuna dönüşür. Cevap hayır çıkıyorsa, ilk iş CTQ'yu ölçmek değil, o damganın kaydedilmesini sağlamaktır.

İyi CTQ, kötü CTQ

Son satır ayrı bir başlık hak ediyor. Sıfır hata bir CTQ değildir, bir temennidir. Ölçüt, süreç bozulduğunda uyarı verebilmelidir; hedefi sıfıra koyarsanız her sapma alarm çalar ve kısa sürede kimse alarma bakmaz olur.

Kaç tane CTQ?

Az. Sahada gördüğümüz iyi işleyen sayı bir süreç zinciri için 3–5 arası.

Uzun CTQ listelerinin ortak kaderi şudur: ilk ay hepsine bakılır, ikinci ay yarısına, üçüncü ay hiçbirine. Oysa üç ölçüt aylarca izlenebilir.

Listeyi kısaltırken Pareto mantığını kullanıyoruz: hangi ölçütler sorunun büyük bölümünü temsil ediyor? Geri kalanı silmiyoruz, "izlenen" listesinden çıkarıp "gerekirse bakılır" listesine alıyoruz.

Bir de sahip meselesi var: sahibi olmayan CTQ ölçülmez. Her ölçütün karşısında bir isim olmalı — o rakam kötüleştiğinde kimin bakacağı belli olmalı.

CTQ'yu sisteme gömmek

CTQ'nun bir Excel'de kalması onu ölçüt olmaktan çıkarır. ERP kullanan bir şirkette ölçütü üç yerde canlı tutabilirsiniz:

• Zorunlu alan ve doğrulama. Ölçütü besleyen veri boş geçilemiyorsa ölçüm de güvenilir olur. Boş geçilebilen alan, olmayan alandır.
• Eşik uyarısı. Sınır aşıldığında sistemin uyarması, raporu birinin açmasını beklemekten hızlıdır.
• Kalıcı gösterge. Ölçüt bir panoda sürekli duruyorsa tartışma rakam üzerinden yürür. Bunu ErpwareBI üzerinde kuruyoruz.

Bu üçü aynı zamanda DMAIC'in Control adımıdır. CTQ'yu sisteme gömmek, iyileştirmenin birkaç ay sonra eski hâline dönmesini engelleyen şeydir.

Nerede kullanıyoruz

CTQ iki ayrı yerde karşımıza çıkar ve ikisinde de işlevi farklıdır:

• DMADV — sıfırdan kurulan süreçte. Ortada ölçülecek bir performans yoktur; CTQ, tasarım tercihlerinin hakemidir. "Bu alan zorunlu olsun mu?" sorusunun cevabı, o alanın hangi CTQ'yu beslediğine bakılarak verilir.
• DMAIC — mevcut süreç iyileştirilirken. CTQ, başlangıç çizgisini ve "iyileştik" cümlesinin ölçüsünü verir. Ölçüt olmadan yapılan iyileştirmede herkes iyileştiğini düşünür, kimse ne kadar olduğunu söyleyemez.

Nerede tökezleniyor?

1. CTQ hiç yazılmaz. Proje başarısı "canlıya geçtik mi?" sorusuna indirgenir. Takvim ölçülür, kalite ölçülmez.
2. Ölçüm noktası belirsiz kalır. Ölçüt yazılır ama nereden okunacağı yazılmaz; ilk ölçüm denemesinde iş durur.
3. Sınır konmaz. "Daha iyi olsun" hedefi, hiçbir zaman ulaşılmayan bir hedeftir.
4. Liste uzun tutulur. On beş ölçüt, sıfır ölçütle aynı sonucu verir.
5. Sahibi yoktur. Rakam kötüleşir, kimse üstlenmez, bir sonraki toplantıda konu değişir.

Biz nasıl yürütüyoruz

CTQ listesini süreç analizinin çıktısı olarak çıkarıyoruz — Süreç Danışmanlığı kapsamında, kullanıcının kendi cümleleriyle başlayıp ölçüte kadar indirerek. Ölçüm noktası sistemde yoksa gereken damgayı veya ekranı özel uygulama geliştirme tarafında ekliyor, ölçütleri ErpwareBI üzerinde kalıcı göstergeye bağlıyoruz.

Tek cümlelik özeti şu: ölçüsü yazılmamış bir beklenti, proje sonunda tartışma konusudur; yazılmış olan ise kabul kriteridir.