Mükerrer proje çalışmasını, yalnızca başlıkları değil girişimlerin neyi başarmayı amaçladığını karşılaştırarak ortadan kaldırın. Devam eden işleri görünür kılın, ortak kullanıcı ve sonuçları bulun; ardından çalışmaları birleştirmeye, yeniden kullanmaya, eşgüdümlemeye ya da bilerek ayrı tutmaya karar verin. Paylaşılan her teslimat için hesap verecek bir sahip belirleyin.
Şirketteki her görevin listesini çıkarmak çözüm değildir. Ekiplerin önemli çakışmaları ciddi çalışma başlamadan fark edecek kadar görünürlüğe ve bunları çözmek için hafif bir yola ihtiyacı vardır. Her küçük iş için merkezi onay kuyruğu kurmak, mükerrerliği beklemeyle değiştirebilir.
Bu kılavuz, sektör standardı olduğu iddiasını taşımayan pratik bir koordinasyon yöntemi sunar. ASQ’nun süreç haritalama rehberi, iş akışında mükerrerlikleri ve devirleri incelemeyi önerir. Burada analiz birimi, birden fazla ekibin çalışmasında görünen girişim veya teslimattır.
Mükerrerliği yararlı paralel çalışmadan ayırın
Benzer çıktılar üreten iki ekip mutlaka emek israf etmiyordur. Farklı kullanıcılara hizmet ediyor, farklı kabul koşullarını karşılıyor veya riskli bir varsayımı bağımsız olarak sınayıyor olabilirler. Soru, işi birleştirmenin amaçlanan değeri koruyup korumayacağıdır.
Benzer biçimde, paylaşılan tek bir bileşen her zaman daha ucuz değildir. Daha önce hiçbir ekibin ihtiyaç duymadığı koordinasyon, ödün, bakım veya izinleri gerektirebilir. Paylaşımın toplam maliyet ve sonuçlarını ayrı çözümlerin maliyetiyle karşılaştırın.
Önce önlenebilir tekrarları arayın: aynı müşteri araştırmasının iki kez yürütülmesi; aynı operasyonel soruyu yanıtlayan iki gösterge panosu; güvenilir bir sonuç paylaşılmadığı için verinin tekrar temizlenmesi; aynı hizmete koordinasyonsuz iki entegrasyon kurulması. Bunların karşılaştırılabilir somut çıktıları vardır.
Tekrarlanan her toplantıyı veya yerel kontrol listesini mükerrer proje saymayın. Başka bir ekip benzer bir konuyu konuşsa da bir ekip kendi değerlendirme ve karar sürecine ihtiyaç duyabilir. Her konuşmayı merkezileştirmeden koordinasyon sorunlarını incelemek için bir agile retrospektifi kullanın.
Küçük bir çakışma kaydı oluşturun
Her ekipten devam eden girişimlerin ve yakın dönem adaylarının kısa bir açıklamasını isteyin. Mümkün olduğunda mevcut planlama kayıtlarını kullanın. Kayıt, güncel tutulacak yeni bir iş listesi yaratmak yerine yetkili kaynaklara işaret etmelidir.
| Alan | Yararı |
|---|---|
| Amaçlanan sonuç | Farklı adlarla anılan benzer işleri ortaya çıkarır |
| Kullanıcılar veya alıcılar | İhtiyaçların gerçekten çakışıp çakışmadığını gösterir |
| Teslimat | Yeniden kullanılabilir çıktıyı belirler |
| Kabul koşulu | Önemli farklılıkları ortaya çıkarır |
| İş sahibi | Diğer ekiplere bir iletişim noktası verir |
| Mevcut aşama | Birleştirmenin hâlâ mümkün olup olmadığını gösterir |
| Bağımlılıklar | Ortak hizmetleri veya uzmanları açığa çıkarır |
| Kaynak kayıt | Proje durumunun rakip bir kopyasını önler |
İlk denetimi tek bir bölüm veya ilişkili iş akışları gibi belirli bir alanla sınırlayın. Şirket genelindeki katalog kullanışlı olmadan önce güncelliğini yitirebilir. Tekrarlanan taleplerin, ortak bağımlılıkların veya rekabet eden kaynak ihtiyaçlarının gerçek çakışmaya işaret ettiği yerden başlayın.
Hassas müşteri bilgilerini kayda kopyalamayın. Amaç işlerin bulunabilir olmasıdır; alttaki tüm kayıtlara geniş erişim vermek değil. Gerekirse erişim denetimleri uygun kanıtlara bağlantı ekleyin.
Çakışma görüşmesini dört olası sonuçtan biriyle tamamlayın
İki girişim benzer göründüğünde sahiplerini, kabul koşullarını bilen biriyle bir araya getirin. Sorunu, kullanıcı grubunu, çıktıyı ve kısıtları karşılaştırın. Tek çalışma sürseydi neyin kaybolacağını sorun.
Dört sonuçtan birini seçin:
- Birleştir: Net sahibi ve ortak kabul ölçütleri olan tek bir teslimat iki ihtiyacı da karşılayabilir.
- Yeniden kullan: Bir ekip mevcut çıktıyı az uyarlamayla kullanabilir.
- Koordine et: Ayrı çıktılar gerekli kalır ama araştırma, bağımlılıklar veya zamanlama paylaşılabilir.
- Bilerek ayrı tut: Farklar bağımsız çalışmayı gerektirir; nedenini ve ne zaman yeniden bakılacağını kaydedin.
Bunlar karar seçenekleridir, olgunluk sıralaması değildir. Birleştirmek otomatik olarak en iyi sonuç olmaz. Yararlı değişim, mükerrerliğin teslimattan sonra tesadüfen fark edilmesi yerine bilinçli bir ödün haline gelmesidir.
Bakımın kime ait olduğunu kaydedin. Sorumlu ekibi olmayan paylaşılan bir varlık, özgün çıktı ihtiyaçları karşılamamaya başladığında her kullanıcının yenisini oluşturmasıyla ileride daha çok mükerrer iş doğurabilir.
Örnek: iki eskalasyon gösterge panosu
Bir destek ekibinin çözümlenmemiş eskalasyonları gösteren bir pano hazırladığını düşünün. Mühendislik operasyonları ekibi de benzer adlı bir rapor oluşturuyor. Yönetim önce bir çalışmanın iptal edilmesini istiyor.
Sahipler kabul koşullarını karşılaştırıyor. Destek ekibi sorumlu sahibi olmayan müşteri kayıtlarını bulmalı. Mühendislik operasyonları ise olaylarda tekrarlanan hizmet arızalarını incelemeli. Etiketler benzer, operasyonel sorular farklıdır.
Ekipler yeniden kullanılabilir bir öğe buluyor: her ikisi de kayıt kimlikleriyle hizmet adları arasındaki güvenilir eşlemeye ihtiyaç duyuyor. Mühendislik operasyonları bu eşlemeyi sürdürmeyi üstleniyor; her ekip kendi raporunu koruyor. Veri tanımlarını eşgüdümleyip veri çekme işini tekrarlamıyorlar.
Sonuç zorunlu birleşme değil, yeniden kullanım ve koordinasyondur. Örnek yöntemi göstermek için kurgulanmıştır. Her gösterge panosunun ayrı kalması gerektiğini veya paylaşılan verinin her çakışmayı çözdüğünü kanıtlamaz.
İş başlarken tekrar oluşmasını önleyin
Giriş kabulüne küçük bir keşif kontrolü ekleyin: “İlişkili bir iş zaten var mı ve kime danışıldı?” Rutin işler için hızlı arama ve konuşma yeterli olmalıdır. Büyük ekipler arası taahhütler daha resmî inceleme gerektirebilir.
Tutarlı sonuç açıklamaları ve görünür sahipler kullanın. Genel bir proje başlığıyla arama, iç kod adıyla gizlenmiş işi bulamayabilir. Kurumun kullandığı kelimeleri bilmeyenlerin de bulabilmesi için kullanıcı sorununu kayda ekleyin.
Tekrarlanan talepleri paylaşılan atölye panosunda inceleyin. Çakışmaları ve kararları kaydedip ekibin normal takip aracına bağlantı verin. Panonun mükerrerleri otomatik bulduğunu veya proje sistemlerini eşitlediğini iddia etmeyin.
Birkaç koordinasyon döngüsünden sonra kaydın işe yarayıp yaramadığını inceleyin. Ekipler mevcut işi daha erken buldu mu? Paylaşılan varlıkların bakım sorumluları oldu mu? Koordinasyon, faydasına göre orantısız gecikme yarattı mı? Gerçek bir durumu incelemek için retrospektif fikirlerinden bir format seçin.
Uydurma bir tasarruf toplamı yerine kararı ölçün
Kabaca tahminleri çıkarıp ölçülmüş sonuçlarmış gibi “kazanılan saat” bildirmeyin. Durdurulan, yeniden kullanılan veya değiştirilen işi kaydedin ve tahminleri tahmin olarak etiketleyin. Kanıt varsa bakım yükünü ve teslimat sonuçlarını zaman içinde karşılaştırın.
Zararlı konsolidasyonu da inceleyin. Ortak ekip aşırı yüklenen bir onay kapısına dönüşürse, katalogda yeniden kullanım başarılı görünürken herkesi yavaşlatabilir. Hem mükerrer iş hem de aşırı bağımlılık anlaşılması gereken sorunlardır.
Sık sorulan sorular
Ekipler farklı araçlar kullanırken mükerrer işi nasıl buluruz?
Sonuçları, teslimatları, sahipleri ve kaynak bağlantılarını içeren küçük bir ortak kayıt kullanın. Ayrıntılı durumu her ekibin yetkili sisteminde tutun. Ortak katman her görevi kopyalamak yerine çakışmayı bulunabilir kılmalıdır.
Benzer projeleri her zaman birleştirmeli miyiz?
Hayır. Kullanıcıları, kabul koşullarını, kısıtları ve bakımı karşılaştırın. Birleştirmek gerekli farklılıkları yok edebilir veya koordinasyon maliyetini artırabilir. Yeniden kullanım ve koordineli ayrı teslimat da geçerli sonuçlardır.
Paylaşılan bir teslimatın sahibi kim olmalı?
Onu sürdürme yetkisi ve kapasitesi olan bir ekip ya da kişi seçin; kullanıcıların sorumluluklarını açıkça belirtin. Net sahiplik olmadan ortak ilgi bir bakım planı değildir.