Süreç Haritalamada Görünmeyen Tuzaklar: Yanlış Kapsam, Yanıltıcı Metrikler ve Sahiplik Boşlukları

Bir süreç haritalama projesi 'başarıyla' tamamlanır: haritalar çizilmiştir, atölyeler yapılmıştır, doküman yayınlanmıştır. Altı ay sonra kimse haritaya bakmaz, süreç eskisi gibi işlemeye devam eder. Bu son ders, projenin kendisini değil, projenin neden sessizce çöktüğünü konu alır.

Tuzak 1: Kapsam Hatası — Çok Geniş veya Çok Dar

İki uç da aynı sonucu doğurur: kullanılmayan bir harita.

• Çok geniş kapsam: 'Müşteri Deneyimi Süreci' gibi bir başlıkla işe başlanır. Ekip üç hafta boyunca pazarlama, satış, teslimat, faturalama ve şikayet yönetimini tek bir haritada birleştirmeye çalışır. Sonuç: 40 kutucuklu, kimsenin anlamadığı bir duvar posteri.
• Çok dar kapsam: Tam tersi — yalnızca 'fatura kesme' adımı haritalanır, ama faturanın neden yanlış geldiğinin kök nedeni bir önceki süreç olan sipariş onayındadır. Dar kapsam, sorunu değil semptomu haritalar.

Pratik kural: Bir süreç haritası, tek bir tetikleyiciyle başlayıp tek bir sonuçla bitmelidir (örn. 'Müşteri sipariş verir' → 'Ürün teslim edilir ve fatura kapanır'). Eğer haritalama sırasında ekip üçten fazla farklı 'ama bazen şöyle de oluyor' senaryosu tartışıyorsa, bu bir alt-süreç ayrımı sinyalidir — kapsamı bölün.

Kapsam Testi (Atölye Öncesi Doldurulacak)

Tuzak 2: 'Olması Gereken'i Haritalamak

Bir yönetici, ekibe süreci anlatırken genellikle prosedür dokümanındaki idealize edilmiş akışı anlatır. Ama saha çalışanı farklı bir gerçeği yaşıyordur: sistem yavaş kaldığında Excel'e geçilir, onay bekleyen bir adım aslında telefonla 'hallediliyor', resmi form yerine WhatsApp'tan fotoğraf gönderiliyor.

Bu fark tehlikelidir çünkü haritalama ekibi 'temiz' bir süreci çizip gider, ama iyileştirme çalışması gerçek olmayan bir sorunu çözmeye çalışır.

• Belirti: Atölyede yönetici konuşuyor, saha çalışanı sessiz kalıyor veya sadece başını sallıyor.
• Çözüm: As-Is haritalama atölyelerine mutlaka fiilen işi yapan kişiyi (yöneticisi değil) davet edin. Yönetici varsa, önce saha çalışanına söz verin — hiyerarşi tersine döndüğünde gerçek akış daha kolay çıkar.
• Doğrulama tekniği: Harita taslağını, süreci hiç görmemiş üçüncü bir kişiye (başka departmandan) okutun ve 'Bu adımı neden atlıyor?' diye sorduğunuzda saha çalışanının kolayca cevap verip vermediğine bakın. Kolay cevap veriyorsa muhtemelen gerçek akış budur; tereddüt ediyorsa 'olması gereken' anlatılmış olabilir.

Tuzak 3: Varyantları Tek Haritada Eritmek

Örnek: 'Satın Alma Onay Süreci' haritalanırken, 5.000 TL altı talepler tek onaylı, 5.000-50.000 TL arası iki onaylı, 50.000 TL üstü ise komite onaylı işliyor olabilir. Bu üç varyantı tek bir haritaya sıkıştırmak, haritayı karar noktalarıyla dolu, okunması imkansız bir örümcek ağına çevirir.

Doğru yaklaşım: Ortak gövdeyi (talep oluşturma, teslimat, kapama) tek haritada tutun; ayrışan onay mantığını ayrı bir karar tablosu veya ayrı mini-akış olarak yan panelde gösterin. Harita 'ya/ya da' okları yerine, mümkün olduğunca doğrusal akış + ayrı referans tablosu kombinasyonunu tercih etmelidir.

Tuzak 4: Süreç Sahibi = Fonksiyonel Yönetici Karışıklığı

En sık görülen yapısal hata budur. 'Sipariş Teslim Süreci'nin sahibi olarak Lojistik Müdürü atanır çünkü teslimat onun departmanındadır. Ama süreç aynı zamanda satış, depo ve muhasebeyi de kapsıyordur. Lojistik Müdürü kendi biriminin dışındaki adımlarda yetki kullanamaz, dolayısıyla süreçteki gerçek darboğaz (örneğin muhasebe onayının 3 gün sürmesi) hiç kimsenin gündemine giremez.

• Fonksiyonel yönetici: Bir departmanın kaynaklarından (insan, bütçe) sorumludur.
• Süreç sahibi: Uçtan uca sonuçtan (örn. teslimat süresi, hata oranı) sorumludur ve departman sınırlarını aşan iyileştirme kararı alabilecek yetkiye sahip olmalıdır — bu genellikle üst yönetimden alınan açık bir yetkilendirmeyle sağlanır.

Pratik test: Süreç sahibi adayına şunu sorun: 'Süreç başka bir departmanda tıkanıyorsa, o departmanın çalışma şeklini değiştirmesini isteyebilir misiniz?' Cevap 'hayır, sadece rica edebilirim' ise, o kişi süreç sahibi değil, sadece bir paydaştır.

Tuzak 5: Yanıltıcı Göstergeler

İyileştirme projelerinde en tehlikeli hata, tek bir metriğe (genellikle süre) odaklanıp diğerlerini gözden kaçırmaktır.

Kural: Her iyileştirme metriğinin yanına mutlaka bir 'dengeleyici gösterge' (counter-metric) koyun. Süreyi iyileştiriyorsanız kaliteyi, kaliteyi iyileştiriyorsanız süreyi ve maliyeti izleyin. Tek boyutlu başarı, çoğunlukla başka bir yerde gizli bir maliyet demektir.

Bir Üst Seviyeye Taşımak İçin

• Her haritanın üstüne kapsam sınırını (başlangıç/bitiş olayı) yazılı olarak not edin — harita güncellenirken kapsam kayması hemen fark edilir.
• As-Is atölyelerinde önce sahayı, sonra yöneticiyi dinleyin.
• Üç veya daha fazla varyant varsa, tek harita yerine ortak gövde + karar tablosu yapısını kullanın.
• Süreç sahipliğini departman sınırlarından bağımsız, üst yönetim onaylı bir yetkiyle tanımlayın.
• Her performans göstergesinin yanına bir dengeleyici gösterge ekleyin; tek metrikle 'başarı' ilan etmeyin.