30 saniyelik özet
Gap Analysis, yani fark analizi, mevcut durum ile hedeflenen durum arasındaki farkları sistematik biçimde değerlendirir. Fark; eksik özellik, süreç, veri, yetki, yetkinlik veya kontrol olabilir. Analist, her farkın hangi iş hedefini engellediğini, neye dayandığını ve hangi seçeneklerle giderilebileceğini açıklar. Sonuç bir alışveriş listesi değildir. Öncelikleri, bağımlılıkları ve kapatılmayan farkların etkisini gösteren bir karar girdisidir. Bilinmeyen mevcut durum, doğrulanmış eksiklik gibi sunulmamalıdır.
Neden önemli?
Bir yönetici proje kârlılığını günlük görmek istediğinde ilk öneri yeni bir raporlama ekranı olabilir. Ancak zaman kayıtları, masraflar ve gelir bilgileri farklı dönemlerde güncelleniyorsa ekran güncel sonucu gösteremez. Görsel çözüm hazır olsa bile hedeflenen karar desteği oluşmaz.
Fark analizi bu durumda soruyu genişletir. Ortak proje kimliği var mı? Gelir ve maliyet aynı kapsamda mı hesaplanıyor? Veriler gereken zamanda ulaşabiliyor mu? Yöneticinin bunları görme yetkisi bulunuyor mu? Eksikliklerin bir kısmı yazılımla, bir kısmı süreç veya sorumluluk değişikliğiyle giderilebilir.
Junior bir iş analisti için fark analizi, talep listesinden gerekçeli kapsam üretme becerisidir. Her değişikliğin neden gerekli olduğunu ve hangi koşula bağlı olduğunu açıklamayı sağlar. Yönetici açısından ise kaynakların nereye ayrılacağına ilişkin seçenekleri görünür kılar. Bütün farkların aynı anda kapatılması mümkün veya ekonomik olmayabilir.
Endüstri mühendisliği açısından bu çalışma, sistemin mevcut kapasitesiyle beklenen performansı karşılaştırmaktır. Ancak karşılaştırmanın ölçüsü tutarlı olmalıdır. Mevcut durumda yalnızca bir departman incelenmişken hedefte bütün işletme değerlendirilirse eksiklikler yanlış yorumlanabilir. Aynı süreç sınırı ve aynı iş tanımı üzerinden ilerlemek gerekir.
Terim nedir?
Fark analizi, “bugün ne var?” ve “hedefe ulaşmak için ne gerekli?” sorularının karşılaştırılmasıdır. Mevcut durumun kanıtı ve hedef durumun gerekçesi bulunmalıdır. Hedef yalnızca başka bir şirketin özellik listesinden türetilirse analiz, işletmenin ihtiyacından uzaklaşabilir.
As-Is, yani mevcut durum, bugün nasıl çalışıldığını gösterir. To-Be, yani hedef durum, gelecekte önerilen çalışma biçimini açıklar. Fark analizi ikisi arasında gereken değişikliği belirler. Ancak her iki modelin de bütün ayrıntılarıyla tamamlanması şart değildir; karar verilecek alanın yeterince açıklanması gerekir.
Karşılaştırma yalnızca sayısal performans üzerinden yapılmaz. Verinin mevcut olması, erişim yetkisinin tanımlanması veya bir kararın sorumlusunun belirlenmesi gibi koşullar da incelenir. Bu koşullar mümkün olduğunca gözlenebilir şekilde yazılmalıdır. “Veri kalitesi yetersiz” yerine hangi kaydın, hangi kurala göre eksik veya tutarsız olduğu belirtilir.
Bir farkın varlığı, nedenini açıklamaz. Ortak proje kimliğinin bulunmaması bir bulgudur; neden oluştuğunu araştırmak ayrı bir analiz gerektirebilir. Benzer biçimde, bir farkı belirlemek çözüm seçmekle aynı şey değildir. Kimlik sorunu için mevcut sistemleri eşleştirmek, süreçte ortak kimlik üretmek veya kapsamı daraltmak gibi farklı seçenekler bulunabilir.
Analist her fark için etki, kanıt, çözüm seçeneği, sorumlu ve bağımlılık kaydeder. Bağımlılık, bir değişikliğin uygulanabilmesi için başka bir koşulun sağlanmasıdır. Veri tanımları netleşmeden rapor geliştirmek, sonraki aşamada yeniden çalışma yaratabilir. Öncelik sıralaması bu ilişkileri hesaba katmalıdır.
Bazı farklar bilinçli olarak açık bırakılabilir. Bu durumda hangi hedefin sınırlı karşılanacağı ve hangi riskin devam edeceği belirtilir. Karar, yetkili kişi tarafından verilmelidir. Fark listesindeki bir satırı kapsamdan çıkarmak, etkisini ortadan kaldırmaz; yalnızca nasıl yönetileceğine ilişkin tercih yapılmış olur.
Gerçek vaka: Netflix’te kişiye bağlı veri işlerinden proje kimliğine
Netflix’in Data Projects yazısı, veri erişiminin ve otomatik işlerin kişilere bağlı yönetilmesinden doğan sorunları anlatıyor. Çalışanların ekip değiştirmesi veya ayrılması, onların kimliğiyle çalışan işlerin yetkilerini etkileyebiliyormuş. Erişimlerin tek tek veri varlıkları üzerinden yönetilmesi de organizasyon değişikliklerini zorlaştırıyormuş.
Şirket, ilişkili veri varlıklarını bir proje altında gruplamayı ve otomatik işleri kişiden bağımsız proje kimliğiyle yürütmeyi sağlayan Data Projects yaklaşımını açıklıyor. Böylece mevcut kişi ve varlık düzeyindeki yönetimle, daha kalıcı bir sahiplik ve erişim düzeni arasında somut bir değişiklik tanımlanmış.
Kaynak bu çalışmayı resmî bir “Gap Analysis projesi” olarak adlandırmıyor. Fark analizi açısından yapılabilecek çıkarım, eksikliğin yalnızca yeni bir yönetim ekranı olmadığıdır: Kimlik, yetki ve iş sürekliliği birlikte ele alınmış. Yazı ayrıca daha geniş platform kullanımını gelecek potansiyeli olarak açıklıyor; bunu tamamlanmış uygulama olarak değerlendirmemek gerekir.
Varsayımsal örnek: Danışmanlık projelerinde güncel kârlılık görünümü
Bir danışmanlık şirketinde proje yöneticilerinin maliyet sapmalarını daha erken görmek istediğini düşünelim. Mevcut durumda çalışanlar zaman kayıtlarını farklı dönemlerde giriyor, masraflar ayrı bir araçta tutuluyor ve finans başka bir sistemden gelir bilgisi sağlıyor olsun.
Analist önce “güncel kârlılık” ifadesini açar. Yöneticinin vermek istediği karar, muhasebede kesinleşmiş sonuçla aynı bilgiye dayanmayabilir. Planlanan, tahmini ve gerçekleşmiş tutarların nasıl ayrılacağı finans ve operasyonla belirlenir. Hedefin hangi bilgiyi hangi gecikmeyle göstereceği açıklanmadan karşılaştırma yapılmaz.
Ardından mevcut kayıtlar incelenir. Bir projeye ait zaman kaydı, masraf ve gelir bilgisi ortak kimlikle eşleştirilemiyorsa bu fark kanıtıyla kaydedilir. Her sistemde proje adı bulunması yeterli değildir; aynı adın farklı projeler için kullanılıp kullanılmadığı ve değişikliklerin nasıl izlendiği araştırılır.
Bir başka fark, zaman kayıtlarının hedeflenen karar sıklığına uygun güncellenmemesi olabilir. Bu sorun yalnızca sistem bağlantısıyla çözülmez. Kayıt sorumluluğu, çalışma düzeni ve kullanıcı yükü değerlendirilmelidir. Daha sık veri talep etmek, doğruluğu kendiliğinden artırmayabilir; girilen bilginin niteliği de kontrol edilmelidir.
Her fark için seçenekler yazılır. Ortak kimlik oluşturma, veri aktarımı, hesaplama kurallarını tanımlama ve erişim yetkisini düzenleme farklı işlerdir. Aralarındaki bağımlılıklar görünür hâle getirilir. Yönetim, başlangıçta yalnızca belirli proje türlerini kapsayan bir çözüm seçebilir; kapsam dışında kalan gruplar açıkça belirtilir.
Doğrulamada örnek bir projenin kaynak kayıtlarıyla hazırlanan görünüm karşılaştırılır. Eksik verilerin ve tahminlerin kullanıcıya nasıl gösterildiği kontrol edilir. Raporun yayımlanması, bütün farkların kapandığını kanıtlamaz. Hedeflenen karar desteğinin oluştuğu, veri güncelliği ve tanımların doğruluğuyla birlikte değerlendirilmelidir.
Yaygın üç hata
- Hedefi belirsiz bırakıp özellik saymak. “Daha iyi raporlama” karşılaştırma için yeterli değildir. Hangi kararın, hangi bilgiyle ve hangi koşullarda destekleneceğini açıklayın. Özellik listesi, bu ihtiyacı karşılayan seçeneklerden biridir; hedefin yerine geçmez.
- Bilinmeyeni eksiklik kabul etmek. Bir kontrolün belgelenmemiş olması, uygulanmadığını göstermeyebilir. Önce ilgili kişiler ve kayıtlarla mevcut davranışı araştırın. Doğrulanmış farklar ile bilgi boşluklarını ayrı tutun. Aksi hâlde zaten yapılan işi yeniden kurmak için gereksiz kapsam oluşabilir.
- Bağımlılıkları görmeden öncelik vermek. Görünür bir ekran yöneticinin ilgisini çekebilir; ancak altında gereken veri ve kurallar hazır olmayabilir. Önce uygulanabilirliği değerlendirin. Erken yapılabilecek işleri, diğer değişikliklerin tamamlanmasına bağlı işlerden ayırın ve kalan etkiyi kaydedin.
Mini uygulama: Fark analizi kayıt kartı
Tek bir iş hedefi seçin ve karşılaştırmayı aşağıdaki alanlarla yapın. Her satırda mümkün olduğunca ayrı bir farkı değerlendirin.
- Hedef ihtiyaç
- Hangi koşul veya performans gerekli?
- Mevcut durum
- Bugün hangi davranış veya kapasite var?
- Kanıt
- Hangi kayıt, gözlem veya belge bunu gösteriyor?
- Fark
- Mevcutla hedef arasında ne eksik veya farklı?
- İş etkisi
- Bu fark hangi sonucu engelliyor?
- Çözüm seçenekleri
- Hangi yollarla giderilebilir?
- Bağımlılık
- Önce hangi koşul sağlanmalı?
- Sorumlu
- Değişiklik ve karar kimde?
- Açık bırakma etkisi
- Giderilmezse ne devam edecek?
- Doğrulama
- Kapanışı hangi kanıt gösterecek?
Kartları ilgili uzmanlarla gözden geçirin. Her fark için hemen çözüm satın almak yerine mevcut araçların ve süreç değişikliğinin yeterli olup olmadığını değerlendirin. Analizin değeri, eksiklerin uzunluğunda değil; hedefe ulaşmak için gereken değişikliklerin ve yönetimin tercih alanının açıklığında ortaya çıkar.
İlgili terimler
As-Is Process, To-Be Process, Business Objective, Domain Knowledge, Requirements Elicitation, Business Requirement, Business Rule, Data Mapping ve Data Dictionary, Scope ve Out of Scope, Dependency Management, Feasibility Study, Business Case