D-RJ-01: OPERASYONEL RÖNTGEN VE MEVCUT DURUM ANALİZİ (AS-IS GAP ANALYSİS) TAM METİN METODOLOJİ / DOLDURULABİLİR ŞABLON Bu metin genel kullanım için hazırlanmış operasyonel teşhis ve raporlama şablonudur. Şirkete ait inceleme yapılmış veya ölçülmüş sonuç elde edilmiş değildir. Kaynak metindeki 40+ insan-saat ve %30 gecikme ifadeleri, aşağıdaki ölçüm protokolünde sınanacak örnek iddialar olarak tutulmuştur. Proje: ReJourney Operasyonel Dönüşüm ve Yalınlaşma Programı Şirket: [Şirket Adı / Holding] Tarih: Ekim 2026 Versiyon: v1.0 Hazırlayan: İnovapark Danışmanlık Ekibi 1. BELGENİN AMACI, KAPSAMI VE KULLANIM SINIRI D-RJ-01, dönüşüm kararı verilmeden önce şirketin günlük işleyişini görünür kılar. Amaç; müşteri talebinin alınmasından tahsilata, satın alma ihtiyacından ödemeye ve personel talebinden göreve başlatmaya kadar kritik akışlarda zaman, maliyet, hata ve yetki kayıplarını kanıtlarıyla belirlemektir. Rapor bir çözüm satışı veya gerçekleşmiş başarı beyanı değil, karar vericilerin doğrulayabileceği bir başlangıç fotoğrafıdır. Kapsam şirketle birlikte yazılı olarak belirlenir: incelenecek tüzel kişiler, lokasyonlar, süreçler, zaman aralığı, sistemler ve hassas veriler. Belge sahibi [Proje sponsoru], süreç sahipleri [Rol/ad], veri sorumlusu [Rol/ad] ve rapor onay makamı [Rol/ad] doldurulmadan saha çalışması başlatılmaz. Çalışma, mali denetim veya hukuki uygunluk görüşü yerine geçmez; ilgili bulgular uzman incelemesine sevk edilir. Teşhis soruları - Hangi talep veya işlem nerede bekliyor; beklemenin sahibi ve nedeni kim tarafından doğrulanıyor? - Hangi veri birden fazla kez giriliyor ve kayıtlar arasında hangi tutarsızlıklar oluşuyor? - Hangi görev bir kişinin yokluğunda duruyor; yazılı yetki, yedek ve SOP var mı? - Hangi adım müşteri, çalışan veya kontrol açısından değer üretmiyor; kaldırılırsa hangi risk doğar? 2. ÇALIŞMA YÖNETİMİ, TARAFSIZLIK VE KANIT STANDARDI Teşhis ekibi, süreç sahibinin anlattığı akışı sistem kaydı ve işlem örneğiyle karşılaştırır. Görüşme tek başına bulgu kanıtı sayılmaz. Her bulguya bir ID, süreç adı, tarih aralığı, kaynak sistem, örnek işlem, doğrulayan kişi, belirsizlik ve veri kısıtı eklenir. Bir görüş ile bir işlem kaydı çelişiyorsa rapor bunu gizlemez; açık konu olarak kaydeder. Örnek çalışma sırası: ilk hafta kapsam ve veri sözlüğü, ikinci hafta görüşmeler ve akış izleme, üçüncü hafta kayıt analizi ve zaman etüdü, dördüncü hafta bulgu teyidi ve karar toplantısı. Bu süre şirketin büyüklüğüne ve erişim iznine göre değişir. Kanıt kaydı: E-01 Süreç envanteri Asgari içerik: Başlangıç-bitiş, tetikleyici, çıktı, sistem ve süreç sahibi Kontrol / kabul kuralı: Süreç sahibi ve en az bir uygulayıcı aynı sınırı onaylar Sorumlu: Süreç analisti Kanıt kaydı: E-02 İşlem örneklemi Asgari içerik: Anonim işlem ID, açılış/sonuç zamanı, onaylar ve istisnalar Kontrol / kabul kuralı: Kaynak sistemden yeniden üretilebilir; kişisel veriler en aza indirilir Sorumlu: Veri sahibi Kanıt kaydı: E-03 Görüşme notu Asgari içerik: Rol, tarih, sorular, gözlem ve doğrulama ihtiyacı Kontrol / kabul kuralı: Öznel değerlendirme ile sistem kanıtı ayrı işaretlenir Sorumlu: Görüşmeci Kanıt kaydı: E-04 Ölçüm çalışma kağıdı Asgari içerik: Formül, pay/payda, dönem, veri kaynağı ve eksik kayıt Kontrol / kabul kuralı: İkinci göz hesaplamayı tekrar edebilir Sorumlu: Analist + süreç sahibi Kanıt kaydı: E-05 Bulgu kaydı Asgari içerik: Bulgu, etki, kök neden hipotezi, kanıt ve itiraz Kontrol / kabul kuralı: Sahip teyidi veya açık itiraz kaydı vardır Sorumlu: Proje lideri Veri çekimleri yalnızca onaylı erişimle yapılır. Rapor ve dışa aktarımlarda müşteri/çalışan kimlikleri, ödeme ve sağlık verileri amaç dışı çoğaltılmaz. 3. AS-IS SÜREÇ HARİTALAMA PROTOKOLÜ Her süreç aynı şemada belgelenir: tetikleyici → işlem adımları → karar noktaları → bekleme → istisna → çıktı → kapanış. Her adım için yapan rol, onaylayan rol, kullanılan sistem, veri girişi, işlem süresi, kuyruk süresi ve kontrol noktası ayrı kaydedilir. Akış yalnızca ideal prosedürü değil, sahadaki gerçek istisnaları da gösterir. Başlangıç örneklemi; satış-teklif-sipariş, satın alma-talep-sipariş, fatura-mutabakat-ödeme ve talep-onay-teslim akışlarından seçilir. Tekrarlayan işler ile seyrek ama yüksek riskli işler ayrı örneklenir. Mümkünse en az iki lokasyon ve farklı yoğunluk dönemleri karşılaştırılır; uygun değilse bu sınır raporda belirtilir. Bir işlem için gözlem formu - İşlem ID [anonim], süreç [ad], başlangıç [zaman], bitiş [zaman], kanal [ERP/e-posta/Excel/diğer]. - Adım [no], işi yapan [rol], kararı veren [rol], bekleme nedeni [kod], yeniden giriş sayısı [adet]. - İstisna [var/yok], kontrol kanıtı [kayıt], çıktı kalitesi [kabul/red], işlem sonucunu etkileyen bağımlılık [açıklama]. Haritalama kalite kapısı - Akışın başlangıcı ve bitişi belirsizse o süreç için verimlilik oranı yayımlanmaz. - Yalnızca yönetici anlatımıyla çizilen akış As-Is olarak onaylanmaz; uygulayıcı ve işlem iziyle test edilir. - İstisnaların toplam hacimdeki payı ayrı ölçülür; istisna görünmezse ortalama süre yanıltıcı olabilir. 4. KİŞİ BAĞIMLILIĞI VE YETKİ DARBOĞAZI ANALİZİ Kişi bağımlılığı; karar, bilgi, erişim veya ilişki tek bir kişide toplandığında ve belgelenmiş yedek bulunmadığında oluşur. Her kritik iş için asıl rol, yedek rol, yazılı talimat, yetki sınırı ve son 90 günde bu kişinin yokluğunda görülen etki kaydedilir. Bir kurucunun onayı hukuken veya yönetişim gereği zorunluysa bu durum israf diye etiketlenmez; karar limiti ve devir olanağı ayrıca incelenir. Karar / bilgi noktası: Rutin satın alma onayı Mevcut tekil bağımlılık: Tek üst yönetici / [doğrulanacak] Yokluk senaryosu: Talep kuyruğunun uzaması Gerekli kanıt: Onay izi, limit, işlem hacmi İlk müdahale: Yetki matrisi ve limit taslağı Karar / bilgi noktası: Müşteri fiyat istisnası Mevcut tekil bağımlılık: Tek satış lideri / [doğrulanacak] Yokluk senaryosu: Teklifin beklemesi veya tutarsız fiyat Gerekli kanıt: CRM teklif ve onay kayıtları İlk müdahale: Fiyat bandı ve eskalasyon kuralı Karar / bilgi noktası: Ay sonu mutabakat Mevcut tekil bağımlılık: Tek finans çalışanı / [doğrulanacak] Yokluk senaryosu: Kapanış gecikmesi Gerekli kanıt: İş listesi, sistem yetkileri, kapanış takvimi İlk müdahale: Yedek ataması ve işlem talimatı Karar / bilgi noktası: Sistem entegrasyon bilgisi Mevcut tekil bağımlılık: Tek geliştirici / [doğrulanacak] Yokluk senaryosu: Hata çözümünün durması Gerekli kanıt: Kod deposu, runbook, erişim günlüğü İlk müdahale: Dokümantasyon ve ikinci göz eğitimi Bu tablo örnek risk hipotezidir. Şirketin fiili durumu, pozisyon ve işlem kanıtı olmadan kesin bulguya çevrilmez. 5. MANUEL EFOR VE VERİ GEÇİŞİ İNCELEMESİ Sistem kullanımı otomatik akış anlamına gelmez. ERP, CRM, e-posta ve elektronik tablolar arasındaki her veri geçişi için kaynak kayıt, hedef kayıt, alan eşleşmesi, kopyalama yöntemi, tekrar sıklığı, hata ve düzeltme süresi çıkarılır. Tekil doğruluk kaynağı (SSOT) kararı verilirken kayıt sahipliği, güncelleme hakkı ve mutabakat zamanı birlikte tanımlanır. Haftalık manuel efor = işlem başına aktif dokunma dakikası × haftalık işlem hacmi ÷ 60. Aynı işlemde birden fazla kişinin eforu ayrı toplanır; bekleme süresi insan-saat hesabına eklenmez. Kaynak metindeki ‘40+ insan-saat’ değeri ancak gözlem sayısı, işlem hacmi ve yöntem doğrulanırsa rapora sonuç olarak girer. - Alan düzeyi eşleştirme: müşteri, sipariş, fatura, tutar ve tarih alanlarının kaynağı ile hedefi yazılır. - Mükerrer kayıt testi: aynı iş olayının birden çok sistemde ne kadar ve hangi koşulla tekrarlandığı ölçülür. - Hata testi: örneklemde yanlış eşleşme, eksik alan ve gecikmiş güncelleme ayrı kodlanır. - Entegrasyon kararı: önce veri sözlüğü ve sorumluluk, ardından API veya otomasyon tasarımı; otomatik yazma için kontrol ve geri alma kuralı. 6. ONAY ZİNCİRİ, BEKLEME VE KARAR SÜRESİ Her onay için talep oluşturulma, sıraya girme, ilk inceleme, geri gönderme, nihai karar ve icra zamanları ayrı alınır. Uçtan uca süre ile aktif çalışma süresi karıştırılmaz. Standart ve istisnai işlemler ayrılır; median, 90. yüzdelik ve yeniden açılan talep oranı birlikte raporlanır. Karar ağacında tutar, risk, mevzuat, sözleşme ve müşteri etkisi için eşikler belirlenir. Çift kontrol gerektiren yüksek riskli adımlar otomatik olarak kaldırılmaz. Düşük riskli tekrarlayan onayların devri, ancak süreç sahibi ve kontrol biriminin onayladığı yetki matrisiyle önerilir. Bekleme kodları - B1: Onay sahibine ulaşamama; B2: Eksik veri/belge; B3: Sistem erişimi veya entegrasyon sorunu. - B4: Yetki limiti belirsizliği; B5: Bütçe veya nakit kısıtı; B6: Müşteri/tedarikçi yanıtı. Gecikme hesabı - Gecikme oranı = taahhüt tarihini aşan uygun işlem sayısı / taahhüt tarihi olan uygun işlem sayısı. - Kaynak metindeki ‘%30 gecikme’, onaylanmış hedef tarihleri ve gerçekleşen bitiş kayıtlarıyla doğrulanacak örnek iddiadır. - Neden ayrıştırması yapılmadan gecikmenin tamamı yönetici onayına bağlanmaz. 7. MUDA TÜRLERİ, ETKİ VE KÖK NEDEN MATRİSİ İsraf kaydı yalnızca ‘fazladan iş’ etiketiyle kapatılmaz. Her satırda gözlenen olay, olası kök neden, müşteri/çalışan/finans etkisi, veri güveni ve kontrol riski yer alır. Otomasyon önerisi, gereksiz adım kaldırma önerisinden ayrı değerlendirilir. Muda türü: Gereksiz işlem / overprocessing Gözlenecek örnek: Aynı siparişin Excel ve ERP'ye yeniden girilmesi Ölçüm / etki: Dokunma süresi, tekrar sayısı, düzeltme eforu Kök neden testi: Kaynak sistem, zorunlu alan ve entegrasyon boşluğu Müdahale hipotezi: Tek giriş noktası ve kontrollü veri aktarımı Muda türü: Bekleme / waiting Gözlenecek örnek: Onayın e-posta kuyruğunda kalması Ölçüm / etki: Kuyruk süresi, P90, geciken teslim Kök neden testi: Limit belirsizliği mi, kapasite mi, eksik veri mi? Müdahale hipotezi: Yetki devri veya eksik veri kontrolü Muda türü: Hata / defects Gözlenecek örnek: Yanlış fatura veya sipariş alanı Ölçüm / etki: Düzeltme sayısı, kredi/iade, müşteri şikâyeti Kök neden testi: Alan eşleşmesi ve giriş doğrulaması Müdahale hipotezi: Giriş doğrulama ve hata yakalama Muda türü: Fazla hareket / motion Gözlenecek örnek: Dosya ve ekranlar arasında sürekli geçiş Ölçüm / etki: İşlem başına ekran/araç geçişi Kök neden testi: Arayüz ve görev ayrımı Müdahale hipotezi: Çalışma ekranı sadeleştirme Muda türü: Fazla stok / inventory Gözlenecek örnek: Bekleyen iş ve tamamlanmamış talep yığını Ölçüm / etki: Açık iş yaşı ve hacmi Kök neden testi: Talep girişi ve kapasite dengesizliği Müdahale hipotezi: WIP sınırı ve öncelik kuralı Muda türü: Gereksiz taşıma / transport Gözlenecek örnek: Bilginin e-posta ekleriyle aktarılması Ölçüm / etki: Handoff sayısı, sürüm uyuşmazlığı Kök neden testi: Sistemler arası sözleşme eksikliği Müdahale hipotezi: Ortak iş kaydı ve erişim yetkisi Muda türü: Fazla üretim / overproduction Gözlenecek örnek: Kullanılmayan yinelenen raporlar Ölçüm / etki: Rapor üretim süresi ve kullanım Kök neden testi: Karar sahibi ve kullanım amacı var mı? Müdahale hipotezi: Rapor portföyünü sadeleştirme Muda türü: Kullanılmayan yetkinlik Gözlenecek örnek: Uzmanın tekrar veri temizlemesi Ölçüm / etki: Uzman saatinin rutin işte payı Kök neden testi: Rol tasarımı ve otomasyon kapasitesi Müdahale hipotezi: Rolü ve çalışma aracını yeniden tasarlama İlk üç satır kullanıcı metnindeki örnekleri açar; diğer satırlar teşhisin kör noktalarını azaltan kontrol listesidir. Hiçbir örnek müşteri bulgusu olarak sunulmaz. 8. ÖLÇÜM SÖZLÜĞÜ VE BAŞLANGIÇ ÇİZGİSİ Her gösterge için isim, işlem evreni, pay, payda, dönem, veri kaynağı, veri sahibi, dışlama kuralı ve beklenen güncelleme sıklığı yazılır. Karşılaştırma yapılacaksa aynı tanım önce/sonra döneminde korunur. Eksik zaman damgası, geri alınmış işlem ve birleşik siparişler rapordan sessizce çıkarılmaz; adet ve etkileri açıklanır. Gösterge: Uçtan uca süre Tanım / hesap: Kapanış zamanı − geçerli başlangıç zamanı Kaynak: ERP/BPM olay günlüğü Raporlama kuralı: Median, P90 ve işlem sayısı birlikte Gösterge: Aktif dokunma eforu Tanım / hesap: Adım başına aktif dakika toplamı Kaynak: Zaman etüdü / görev kaydı Raporlama kuralı: Hacimle çarpılır; bekleme dahil edilmez Gösterge: İlk seferde doğru tamamlama Tanım / hesap: Düzeltmesiz kapanan uygun işlem / uygun işlemler Kaynak: İstisna ve düzeltme kayıtları Raporlama kuralı: Örneklem ve dışlamalar belirtilir Gösterge: Tekil kişi bağımlılığı Tanım / hesap: Yazılı yedeği olmayan kritik görev / tanımlı kritik görev Kaynak: Görev ve erişim envanteri Raporlama kuralı: Risk ağırlığıyla ayrıca değerlendirilir Gösterge: Onay bekleme payı Tanım / hesap: Onay kuyruğunda geçen süre / uçtan uca süre Kaynak: Olay günlüğü Raporlama kuralı: Rutin ve istisnai karar ayrı Gösterge: Mükerrer veri girişi Tanım / hesap: İkinci kez girilen alan/işlem / incelenen alan/işlem Kaynak: Sistem eşleştirme örneklemi Raporlama kuralı: Kaynak ve hedef kayıt kimliği saklanır Eşikler ve hedefler başlangıç çizgisi çıktıktan sonra süreç sahibi tarafından onaylanır; hazır yüzde vaatleri kullanılmaz. 9. BOŞLUK PUANI VE MÜDAHALE ÖNCELİĞİ Bulgular üç ayrı soruyla puanlanır: etki (1–5), gerçekleşme sıklığı (1–5), kanıt güveni (düşük/orta/yüksek). Etki × sıklık ilk tarama puanıdır; güven düşükse karar ‘araştır’ olarak kalır. Yasal veya güvenlik riski, sayısal puanı düşük olsa da ayrı yönetim eskalasyonuna gider. Müdahale sırası, bütçe ve bağımlılıklarla birlikte kararlaştırılır. Karar sınıfları - Hemen güvenceye al: kritik kontrol veya hizmet sürekliliği riski; geçici kontrol sahibi ve son tarih atanır. - Pilotla: ölçülebilir yüksek hacimli darboğaz; küçük örneklemde yeni akış test edilir. - Tasarım kuyruğuna al: birden fazla sistem veya departmana bağlı yapısal sorun. - Veri topla: kanıt zayıf veya baz çizgi yok; çözüm ve tasarruf vaadi verilmez. 10. DÖNÜŞÜM İŞ PAKETLERİ VE SORUMLULUKLAR D-RJ-01'in çıktı kararı ‘sistem kuruldu’ değildir; hangi işin hangi sahiplikle tasarlanacağıdır. Her öneri için beklenen etki, maliyet, kontrol şartı, bağımlılık, pilot kapsamı, kabul ölçütü ve geri alma planı yazılır. Standart bir öncelik kaydı aşağıdaki iş paketlerini içerir. İş paketi: Süreç yalınlaştırma Sorumlu (R): Süreç sahibi + analist Hesap veren (A): Operasyon lideri İlk teslimat: As-Is/To-Be karşılaştırması ve kaldırılacak adım listesi Karar kapısı: Kontrol etkisi onaylandı mı? İş paketi: Yetki ve yedekleme Sorumlu (R): İK + süreç sahibi Hesap veren (A): İcra lideri İlk teslimat: Kritik görev, yedek ve limit taslağı Karar kapısı: Yetki ve imza sınırı doğrulandı mı? İş paketi: Veri ve entegrasyon Sorumlu (R): BT/veri sahibi Hesap veren (A): Sistem sahibi İlk teslimat: Alan sözlüğü ve kaynak-hedef eşleştirmesi Karar kapısı: Erişim, hata ve geri alma testi var mı? İş paketi: KPI başlangıç çizgisi Sorumlu (R): Analist Hesap veren (A): Süreç sahibi İlk teslimat: Tanımlı dönem, formül ve kanıt dosyası Karar kapısı: Örneklem ve veri kalitesi yeterli mi? İş paketi: Finansal etki Sorumlu (R): Finans analisti Hesap veren (A): CFO İlk teslimat: Maliyet varsayımı ve doğrulama yöntemi Karar kapısı: Çifte sayım ve tek seferlik gider ayrıldı mı? R ve A, şirketin kendi organizasyonuna göre isimlendirilip yazılı onaylanır. Bir iş paketinde tek hesap veren makam bulunur. 11. RAPOR PAKETİ, KABUL KONTROLÜ VE DEVİR Teslim paketi; kapsam beyanı, süreç haritaları, kanıt dizini, Muda matrisi, baz çizgi hesapları, kişi bağımlılığı haritası, açık itirazlar, öncelikli iş listesi ve karar tutanağından oluşur. Her dosya sürüm, tarih ve sahibiyle kaydedilir. Duyarlı işlem ayrıntıları genel dolaşıma açılan rapora eklenmez; yetkili inceleme alanında saklanır. Kabul toplantısında proje sponsoru şu soruları yanıtlar: Süreç sınırı ve örneklem yeterli mi? Sayısal bulgular yeniden hesaplanabiliyor mu? Kontrol kaybı yaratmadan kaldırılabilecek adımlar hangileri? Öncelik, bütçe ve uygulama sahibi belli mi? İtirazlı bulgular kapatıldı mı? Açık kalan bulgular karar kaydında görünür bırakılır. Onay alanları - Hazırlayan: [ad/rol, tarih, sürüm]. İnceleyen süreç sahibi: [ad/rol, görüş]. Veri doğrulayan: [ad/rol, örneklem]. - Karar: [kabul / koşullu kabul / iade]. Açık koşullar: [ID, sahip, son tarih]. Bir sonraki gözden geçirme: [tarih]. Kod ve sıra notu - Yeni operasyonel dizide D-RJ-03 Süreç Yalınlaştırma ve Yeniden Tasarım Master Planı, bu teşhisin doğrudan devamıdır. D-RJ-09 mevcut BPR arşiv belgesi olarak ayrıca okunabilir. - Önceki dizide D-RJ-03 koduyla yayımlanan Stratejik Yönelim Manifestosu, tarihsel bağlamı korunarak D-RJ-03 sayfası altında ayrı bir arşiv varyantına taşınmıştır. D-RJ-01, kanıt ve onay alanları doldurulduğunda D-RJ-03 Süreç Yalınlaştırma ve Yeniden Tasarım Master Planı'na girdi olur. Sahada ölçülmeyen 40+ insan-saat ve %30 gecikme ifadeleri gerçekleşmiş sonuç olarak kullanılmaz.