Bir soruna çözüm önermeden önce neyi anlamalısınız?

Bir soruna çözüm önermeden önce neyin beklenenden farklı olduğunu, bunun kimi nasıl etkilediğini ve sorunun hangi koşullarda ortaya çıktığını anlayın. Gözlediğiniz belirtiyi, düşündüğünüz neden ve önerdiğiniz çözümden ayrı yazın. “Yeni bir sisteme ihtiyacımız var” bir çözüm önerisidir; sorunun kendisi değildir. Önce mevcut işte neyin aksadığını tarif edebilirseniz seçenekleri daha anlamlı karşılaştırabilirsiniz.

İlk akla gelen çözüm doğru olabilir. Ancak neden işe yarayacağını açıklayamıyor veya hangi sorunu çözdüğünü net söyleyemiyorsanız önce biraz daha bilgi toplamanız gerekir. Bu çalışma, karar vermeyi süresiz ertelemek için değil, yanlış soruna doğru çözüm üretmemek içindir.

Belirtiyi neden olarak adlandırmayın

Şöyle bir ekip düşünün: Müşterilere yanıt geç gidiyor ve ilk öneri yeni bir mesajlaşma aracı almak oluyor. Oysa gecikmenin nedeni taleplerin yanlış kişiye yönlenmesi, eksik bilgiyle gelmesi veya karar için onay beklemesi olabilir. Yeni araç bunlardan bazılarını etkileyebilir; fakat hangisinin asıl sorun olduğunu bilmeden çözümün kapsamı belirsiz kalır.

Sorunu önce gözlenebilir biçimde yazın: “Müşteri talepleri ilgili kişiye ulaşmadan önce birkaç ekip arasında dolaşıyor.” Bu ifade, “İletişimimiz kötü” cümlesinden daha incelenebilir. Hangi talepler, hangi ekipler ve hangi aşamalar söz konusu? Bunları araştırabilirsiniz.

Neden hakkında bir fikriniz varsa onu varsayım olarak kaydedin. “Talep türleri baştan ayrılmadığı için yönlendirme gecikiyor olabilir” diyebilirsiniz. Sonra bu varsayımı destekleyen ve desteklemeyen örnekleri arayın. Yalnız kendi fikrinize uyan olayları seçmek, sorunun başka bölümünü görmenizi zorlaştırır.

Beklenen sonuç neydi?

Bir durumun sorun olduğunu söylemek için beklenen sonucu anlamak gerekir. Hangi hizmet, teslim veya karar bekleniyordu? Beklenti açık mıydı? Taraflar aynı sonucu mu düşünüyordu? Bazen işin kendisinden önce beklenti belirsizliği çözülmelidir.

Örneğin bir rapor “geç” bulunuyorsa teslim tarihi konuşulmuş mu, raporun hangi kararda kullanılacağı belli mi? Bir ekip dosyanın sabah hazır olmasını beklerken diğeri gün sonunu hedefliyorsa önce ortak teslim anlayışı gerekir. Sorun yalnız kişinin çalışma hızına indirgenmemelidir.

Beklentiyi netleştirirken gerçekçi olup olmadığını da değerlendirin. Mevcut bilgi, erişim ve kaynaklarla istenen sonuç üretilebilir mi? Bu soruya tek başınıza karar vermeniz gerekmeyebilir. İşin sahibi ve karar verecek kişiyle kapsamı konuşun. Çözüm, bazen işi hızlandırmak; bazen de kapsamı veya tarihi değiştirmektir.

Sorun nerede var, nerede yok?

Sorunun her durumda mı, belirli koşullarda mı ortaya çıktığını karşılaştırın. Aynı süreç bazı müşterilerde düzgün çalışıyor, bazılarında aksıyor olabilir. Yeni başlayanlarda görülen bir hata deneyimli kişilerde görülmüyor olabilir. Belirli bir veri türü veya iş yoğunluğu sorunu etkiliyor olabilir.

Bu karşılaştırma, tek başına nedeni kanıtlamaz; fakat araştırmayı daraltır. Örneğin eksik bilgiyle gelen taleplerin daha çok beklediğini görüyorsanız başlangıç formunu ve bilgi toplama adımını incelemek anlamlı hale gelir. Buna rağmen bütün gecikmeleri aynı nedene bağlamadan diğer örnekleri de kontrol edin.

İşten etkilenen kişileri dinleyin. Süreci tasarlayan kişiyle kullanan kişinin gördüğü sorun farklı olabilir. “Sistem neden kötü?” gibi yönlendirici soru yerine “Son talepte hangi adımda durdunuz?” diye sorun. Somut bir olay üzerinden konuşmak, genel memnuniyetsizliğin içindeki kullanılabilir bilgiyi ortaya çıkarır.

İlk çözümü küçük bir denemeye çevirin

Sorunu yeterince anladıktan sonra birden fazla seçenek düşünün. Yeni araç, görev dağılımı, bilgi standardı veya onay akışı farklı çözümler olabilir. Her seçeneğin hangi nedeni hedeflediğini yazın. Böylece yalnız sevdiğiniz aracı önerdiğiniz için çözüm seçmemiş olursunuz.

Mümkün olduğunda küçük, geri alınabilir bir deneme yapın. Müşteri talepleri örneğinde tek bir talep grubunu başlangıçta sınıflandırıp doğru kişiye yönlendirmek denenebilir. Denemenin süresini, sorumlusunu ve hangi sonucun gözleneceğini önceden belirleyin. Sadece “Daha iyi oldu” hissiyle karar vermeyin.

Deneme sırasında başka bir sorun oluşup oluşmadığını da izleyin. Bir adımı hızlandırırken başka ekibe daha fazla kontrol yükü taşımış olabilirsiniz. Başarı ölçütü, yalnız sizin bölümünüzün rahatlaması olmamalıdır. Çözümün etkisini işin bütünü içinde değerlendirin.

Bir sayfalık sorun notu hazırlayın

Yakın zamanda yaşadığınız bir aksaklığı seçin. Notunuzda beklenen sonuç, gözlenen durum, etkilenen kişi veya iş, bilinen örnekler, bilinmeyen noktalar ve ilk varsayım bulunsun. Çözüm önerisini en sona yazın. İlk bölümleri doldurmadan çözüm seçmekte acele ediyorsanız bunu fark edin.

Sonra notu işle ilgili bir kişiye okutun. “Bu sorunu siz de aynı şekilde mi görüyorsunuz?” diye sorun. Aynı fikirde değilseniz hemen çözümü savunmayın. Farklı tanımın hangi bilgiye dayandığını öğrenin. Sorun üzerinde anlaşmak, her ayrıntıda aynı düşünmek anlamına gelmez; kararın neyi iyileştirmeyi amaçladığını ortaklaştırır.

Bu çalışma için kusursuz veri beklemeyin. Hangi bilgiye sahip olduğunuzu ve hangi belirsizliği kabul ederek ilerlediğinizi açıkça belirtin. Küçük ve düşük etkili bir sorunla büyük sonuç doğurabilecek bir soruna aynı araştırma derinliğini uygulamak gerekmez. İncelemenin kapsamını kararın önemine göre ayarlayın.

Veri içeren bir sorunla çalışıyorsanız rapordaki sayıların bağlamını değerlendirme yazısı yardımcı olabilir. İyi bir çözüm önerisi, yalnız ne yapılacağını değil, neden bu adımın seçildiğini de açıklar.

Sorunu tarif ederken kişilerden önce iş akışına bakın. “Ekip dikkatsiz” demek hangi adımın düzeltilmesi gerektiğini göstermez. Eksik bilgi nerede oluşuyor, kim hangi veriyi bekliyor ve hata hangi koşulda tekrarlanıyor? Bu sorular kişileri sorumluluktan çıkarmaz; müdahale edebileceğiniz noktayı görünür kılar. İlk bulduğunuz nedeni tek neden saymayın. Küçük bir gözlem veya örnek kayıt, önerinizin doğru yere yönelip yönelmediğini anlamanıza yardım edebilir.

Çözümden önce üç soruyu yanıtlayın

Kariyerinizdeki bir sonraki adımı çalışmak için Kariyer Gelişim Kursu programını inceleyebilirsiniz.

Sıkça sorulan sorular

Acil durumda da önce araştırma mı yapmalıyım?

Önce acil etkiyi sınırlamak için gerekli adımı atmanız gerekebilir. Geçici müdahaleyi kalıcı neden çözümüyle karıştırmayın; durum uygun olduğunda incelemeyi sürdürün.

Sorunun nedenini zaten biliyorsam ne yapayım?

Bunu destekleyen bilgiyi ve alternatif açıklamaları kontrol edin. Deneyiminiz değerli olabilir; yine de bu olayın aynı koşulları taşıdığını doğrulayın.

Her sorun için ayrıntılı rapor gerekir mi?

Hayır. Küçük bir iş sorunu için birkaç açık cümle yeterli olabilir. Amaç belge üretmek değil, kararın dayanağını netleştirmektir.

Çözümüm reddedilirse sorun tanımını mı değiştirmeliyim?

Önce itirazın nedenini anlayın. Sorun tanımı, maliyet, öncelik veya uygulanabilirlik açısından farklı bir değerlendirme olabilir.