Birçok kuruluşta, bir zorluk ortaya çıkar çıkmaz ilk tepki hemen bir çözüm aramaktır. Problemin tanımlanması ise ikincil, neredeyse bürokratik bir adım olarak görülür. Toplantılar birbirini izler, varsayımlar havada uçuşur ve eylem planları hızla hazırlanır.
Ancak bu acelecilik sıklıkla hayal kırıklığı yaratan sonuçlar doğurur. Uygulanan eylemler yalnızca sınırlı bir etki sağlar; zorluklar bazen farklı bir biçimde yeniden ortaya çıkar. Bir şeyler yapılmış olması hissi, çoğu zaman gerçek bir ilerlemenin yokluğunu gizler.
Bu başarısızlıkların mükerrer bir nedeni, çözümlerin üst safhasında, problemin ele alınış biçiminde yatar. Muğlak veya taraflı bir problem tanımı, mekanik olarak yetersiz yanıtlar doğurur. Harekete geçmeden önce, neyin çözüleceğinin tam olarak adının konması gerekir.
Bu aşama neden bu kadar sık aceleye getiriliyor?
Mantığında, DMAIC mantığında, ilk adım olan Tanımla (Define) adımı, problem tanımının yapıldığı aşamadır. Kağıt üzerinde tüm yaklaşımı başlatır. Uygulamada ise düzenli olarak aceleye getirilir.
Ekiplerin dikkati kendiliğinden, daha aktif olarak algılanan Analiz Et ve İyileştir aşamalarına kayar. Bu durumda Tanımla aşaması, asıl meselelere geçmek için bir an önce atlanması gereken idari bir ön şart gibi görünür.
Bu aceleciliğin bir bedeli vardır. Kötü tanımlanmış bir iyileştirme projesi zaman tüketir, kaynakları seferber eder ve zayıf sonuçlara yol açar. Başlangıçtaki titizlik, kalan tüm akıl yürütme sürecini doğrudan etkiler.
Bir semptomu tarif etmek, bir problemi tanımlamak demek değildir
Daha ilk görüşmelerden itibaren yaygın bir kafa karışıklığı baş gösterir. Gözlemlenebilir bir semptom, problemin kendisi sanılır.
Urayan bir teslim süresi, yükselen bir fire oranı, tekrarlayan bir müşteri şikayeti: Bunlar birer sinyaldir, problem değildir. Sürecin bir yerlerinde bir aksaklık olduğunu haber verirler. Ancak bunun niteliği, boyutu veya tam konumu hakkında hiçbir şey söylemezler.
Semptom ile problemi karıştırmak, olayı doğuran sebebe dokunmadan yalnızca görünür olanı tedavi etmeye yol açar. Sonuç bellidir: Dikkat azaldığı anda etki geri döner.
Bir nedeni adlandırmak da bir problem tanımı değildir
Diğer bir sapma ise varsayılan bir nedeni problemin kendi ifadesine dahil etmektir. Problem tanımı bu durumda kılık değiştirmiş bir açıklamaya dönüşür.
"Ekiplerde personel eksikliği olduğu için teslimat süreleri uzuyor" ifadesi bir problem tanımı değildir. Bu, kesin bir gerçekmiş gibi sunulan bir neden hipotezidir. Teşhis zaten konmuş, analiz baypas edilmiş ve diğer olası nedenler görünmez hale gelmiştir.
Bu kafa karışıklığı, analizi daha başlamadan kapatır. Ardından gelecek eylemler, doğru olmayabilecek varsayımsal nedeni hedef alacaktır.
Kullanışlı bir problem tanımının bileşenleri
İyi bir problem tanımı tarafsız, tanımlayıcı ve ölçülebilir kalır. Kaynağı veya çözümü hakkında ön yargıda bulunmaksızın gözlemlenen bir sapmayı tarif eder. Birkaç net unsurdan oluşur:
- gözlemlenebilir terimlerle somut olarak neyin gerçekleştiği
- olayın nerede, hangi süreçte veya hangi hatta meydana geldiği
- ne zaman ortaya çıktığı ve hangi sıklıkta kendini gösterdiği
- bir göstergeyle ifade edilen boyutunun ne olduğu
- bu durumun beklenen duruma kıyasla nasıl bir sapmayı yansıttığı
- kuruluş veya müşteri için ne gibi ölçülebilir sonuçlar doğurduğu
Bu unsurlar bir araya geldiğinde muğlak bir şikayeti eyleme dönüştürülebilir bir ifadeye dönüştürür. Böylece ekip neyi aradığını, nerede arayacağını ve bulduğunu nasıl doğrulayacağını bilir.
Problem tanımının kilit noktası: Beklenenden sapma
Sapma kavramı merkezi bir öneme sahiptir. Beklenen bir seviyeye atıfta bulunulmadığında ortada bir problem yok, sadece bir gözlem vardır.
Beklenen seviye bir norm, bir iç standard, bir müşteri taahhüdü, bir performans hedefi veya geçmiş bir seviye olabilir. Niteliği ne olursa olsun problemi anlaşılır kılar. Ham bir veriyi anlamlı bir bilgiye dönüştürür.
Bir problemi tanımlamak, her şeyden önce bu sapmanın adını koymak demektir. Beklenen durum açıkça ortaya konmadığı sürece analiz boşa kürek çeker.
Problem tanımının kalitesinde yönetimin rolü
Bir zorluğun ele alınış biçimi, büyük ölçüde onu çevreleyen yönetsel tutuma bağlıdır.
Yönetim anında yanıtlar beklediğinde ve eylem hızına değer verdiğinde, ekipler tanım aşamasını kısa tutmayı öğrenir. Problem, genellikle varsayılan bir neden olarak birkaç kelimeyle ifade edilir ve tartışma hemen eylem planına kayar. Problem tanımı, gerçek bir analiz talebi içermeyen formaliteden ibaret bir adıma dönüşür.
Aksine, yönetim ilk ifadeyi sorgulamaya zaman ayırdığında, veri talep ettiğinde ve bunu yeniden formüle ettirdiğinde tanımın kalitesi artar. Ekip, kötü tanımlanmış bir problemin detay değil bir risk olduğunu anlar. Onu doğru çerçevelemek için gereken zamanı yatırır.
Bu tutum, baskı altındaki ortamlarda pek doğal olmayan bir sabır gerektirir. Ancak takip edecek çözümlerin uygunluğunu doğrudan etkiler. Titiz bir problem tanımı talep eden bir yönetim, kendisini gereksiz tekrarlardan kurtarır.
Hatalı bir problem tanımının sinyalleri
Zayıf bir tanımı ele veren birkaç ipucu vardır. İfade, "iletişim eksikliği" veya "eğitim ihtiyacı" gibi problem kılığına girmiş bir eylem fiili içerir. Bir gerçekten ziyade bir yargı belirtir. "Çok sık" veya "çok fazla" gibi ilişkili bir büyüklüğü olmayan muğlak terimler kullanır.
Ayrıca çok geniş olup heterojen birkaç olguyu kapsayabilir veya aksine çok dar olup genel bir kapsamı olmayan özel bir durumu izole edebilir. Tüm bu durumlarda, yaklaşımın geri kalanı zarar görecektir.
Yeniden formüle etmek bir zaman kaybı değildir. Esaslı bir adımdır.
Aceleye getirilmiş bir ifadeden kalıcı bir problem tanımına
Sağlam bir problem tanımı oluşturmak tek seferlik bir egzersiz değildir. Bir kuruluşun uygulamalarına kademeli olarak yerleşen bir disiplindir.
Bu, ekipler tarafından paylaşılan ve bir tanımın beklenen bileşenlerini hatırlatan basit çerçeveler gerektirir. Ayrıca analiz ve çözüm süresinden ayrı olarak tanıma ayrılmış bir zaman gerektirir. Ve bu titizliğe uygulama hızı kadar değer veren bir yönetim gerektirir.
Bu koşullar karşılandığında, iyileştirme projelerinin kalitesi gözle görülür şekilde ilerler. Analizler daha isabetli hale gelir, çözümler kalıcılık kazanır, tekrarlar azalır. Problem tanımı basit bir ön formalite değil, sürdürülebilir performansın gerçek bir kaldıracı haline gelir.
Önemli çıkarımlar
- Kötü bir problem tanımı, mekanik olarak kötü bir çözüme yol açar
- Tanımla aşaması, DMAIC sürecinde sıklıkla yanlış bir şekilde aceleye getirilir
- Bir semptom problem değildir
- Varsayılan bir neden problem değildir
- Problem tanımı, beklenen seviyeden sapmayı tanımlar
- İyi bir tanım tarafsız, tanımlayıcı ve ölçülebilirdir
- Yönetim, gerekli titizlik seviyesini belirler
- Başlangıçtaki titizlik, tüm proje boyunca zaman kazandırır
