Montaigne’in “Gideceği limanı bilmeyen gemiye hiçbir rüzgardan hayır gelmez” sözü birçok konuda geçerli olsa da iş analizi için özellikle akılda tutulmalıdır. Epeyce zahmetli olan iş analizlerini yapıp bitirdikten sonra “Aa, siz onu mu istiyordunuz?” veya “Bize öyle bir bilgi gelmedi” cümlelerini kurmak sizin adınıza hiç hoş bir görüntü vermez. Bir dost!
Süreç tasarımının olmazsa olmazı ve ilk adımıdır iş analizi. Hatta literatürde iş analizi denildiğinde onun içine süreç tasarımı gizlenmiştir aslında; elde edilen bilgiyi değerlendirmeyecek, bir şeyleri düzeltmek için kullanmayacaksanız neden sordunuz o kadar soruyu, o kadar kişiye değil mi ama?
İş analizini iyi yapabilmek için sonuçta elde etmek istediğiniz şeyi en baştan bilmeniz gerekir. Süreçlerinizi mi iyileştirmek istiyorsunuz, satın alma işinin yanlış veya yavaş yapıldığını mı düşünüyorsunuz? İşlerin birbirine göre zorluğunu ölçmek, iş değerlemesi yapmak, ücret skalasını buna göre düzenlemek mi istiyorsunuz? Norm kadroları bölümlere göre belirlemek mi istiyorsunuz, örneğin sizce üretim bölümünde çok fazla beyaz yaka mı çalışıyor ya da muhasebe bölümünde çalışan sayısı mı yetersiz? Analizin başında nereye gitmek istediğinizi net olarak belirlemediyseniz çok yorucu ve uzun bir analiz çalışması sonucunda işinize yarayacak bilginin elinizde bulunmadığını gözyaşları içinde farkedersiniz. Elbette burada iş analizi olarak kastettiğim şey bire bir, yüz yüze görüşmeler. İş analizi yapmanın birçok farklı şekli var (anket, gözlem, toplantı vb) ama hem bu yazının konusu o değil, hem de en etkili yöntemin her zaman karşılıklı görüşme olduğunu düşünürüm.
İş analizi yaparken çok kritik sorular sizi bekler. Bunları hem kendinize, hem sürecin sahiplerine, yani o birimde çalışanlara, hem de tepe yöneticilere sormanız gerekir. Bu iş gerçekten gerekli mi? Bu işi yapmak bize ne fayda sağlıyor? Yapmasak ne kaybederiz? Mutlaka yapılması gerekiyorsa daha kolay bir yapma şekli var mıdır? En çok zaman alan kısımları hangileridir? Bu işi dışarıya verebilir miyiz, verirsek ve vermezsek her birinin maliyeti bize ne kadara gelir? Bu işin girdileri nelerdir, çıktıları nelerdir? Çıktıların her biri nerede kullanılıyor? Öyle ya, üretmek için bir birimin saatlerini harcadığı o “çok önemli” raporu belki gittiği birimde kimse okumuyordur?! İşte, en baştan itibaren bilmeniz gereken hedef, iş analizindeki bütün bu sorularınızı belirleyecektir. Hangilerini sormalısınız, hangi tür bilgiyi almaya devam etmelisiniz veya hangisinin detayına daha fazla girmemelisiniz? Hıza, kaliteye, adetlere, memnuniyete, otomasyona, teknolojiye ya da birimler arası iletişime mi odaklanmalısınız?
Örneğin süreç tasarımı amaçlı olarak iş analizi yaptığınızı varsayalım… Yukarıdaki bir soru son derece önemli hale gelir: Bu işi yapmasak ne kaybederiz?
Kurumlarda “burada işler böyle yapılır” adlı bir sendrom vardır. Aslında temelde kurum kültürünü, felsefesini işaret eder ve sendrom haline gelmemişse kötü de değildir. Ancak bu kavram eğer iş yapma şeklini sabitleyen, yıllarca sorgulanmamasını sağlayan bir hale gelmişse sendrom halini almıştır. Çalışanlar kendilerine söylenen işi kayıtsız şartsız yapar ve şirkete faydasını hiç sorgulamaz. Patronlar da mutludur çünkü bir grup itaatkar çalışan kuzu gibi çalışmaktadır, daha ne olsun? Halbuki babadan kalma o iş şekli belki artık örgütün değişmiş olan dinamiklerine hiçbir şey katmıyordur? Çalışan sorgulamamaktadır, patron da yıllardır onu “tanım gereği” bir iş olarak kabullenmiştir ve faydasını sorgulamak artık aklına bile gelmemektedir. Harry Frederick Harlow’a ait olduğu rivayet edilen meşhur 5 maymun deneyindeki gibi…
İşte bu noktada, atılan taşın ürkütülen kurbağaya değip değmediğini sorgulamak kahraman iş analistinin/süreç tasarımcısının işidir. İş analizi sırasında bu dinamikleri öğrenmek, bunları anlamak için doğru soruları sorabilmek bu süper kahraman kadronun işidir. Bütün gerekli bilgiyi analiz sayısı arttıkça çalışanlardan çekip almalıdır, konuya geniş perspektiften bakıp o an gerekli diğer soruları da sorabilmelidir.
Yapabilir… yeter ki gideceği limanı bilsin!
Baler Eskibatman, PMP