D-RJ-03: SÜREÇ YALINLAŞTIRMA VE YENİDEN TASARIM MASTER PLANI TAM METİN MASTER PLAN / UYGULAMA ŞABLONU Bu belge şirket verisi ve sistem erişimi olmadan hazırlanmış tam metin tasarım şablonudur. To-Be akışları kurulmuş veya canlıya alınmış sayılmaz. Kaynak metindeki %75 süre kısalması, %100 veri doğruluğu ve sıfır hata ifadeleri gerçekleşmiş sonuç değil; başlangıç ölçümü, pilot ve kontrol testi gerektiren hedef hipotezleridir. 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. AMAÇ, GİRDİ VE KARAR SINIRI D-RJ-03, D-RJ-01 Operasyonel Röntgen'de kanıtlanan darboğazları ve israfları uygulanabilir bir süreç tasarımına çevirir. Çıktısı yalnızca akış şeması değildir: adımın sahibi, veri kaynağı, karar limiti, kontrol noktası, istisna yolu, pilot kabul ölçütü ve sistem devri birlikte tanımlanır. Şirket adı, lokasyon, süreç hacmi ve mevcut yazılımlar [Şirket Adı] tarafından doldurulmadan bu metin canlı işletim talimatı olarak kullanılamaz. Tasarıma alınan her bulgu D-RJ-01 kanıt ID'sine bağlanır. Baz çizgi yoksa beklenen tasarruf ya da hız artışı yüzde olarak onaylanmaz. Bir onayın kaldırılması finansal, sözleşmesel veya güvenlik kontrolünü zayıflatacaksa önce alternatif kontrol tasarlanır. Süreç sahibi, finans/iç kontrol ve sistem sahibi karar kapısında birlikte imza verir. Giriş paketi - D-RJ-01 As-Is akışı, Muda kaydı, işlem örneklemi, başlangıç KPI'ları ve açık veri kalitesi sorunları. - Güncel organizasyon, yetki ve imza sınırları; ERP/CRM/POS/BPM alan sözlüğü ve sistem sahipleri. - Müşteri taahhütleri, hizmet seviyeleri ve korunması gereken yasal veya sözleşmesel kontrol adımları. Başarı koşulu - Yeni akış daha az aktif efor veya bekleme üretirken hata, kontrol ihlali ve müşteri zararını artırmamalıdır. - Pilot sonunda ölçülen sonuç, hedef aralığı ve kalan istisnalar aynı raporda yer almalıdır. 2. DÖRT YALINLAŞTIRMA İLKESİ VE TASARIM TESTLERİ Elimination (ayıklama), Flow (akış), Pull (talep tetiklemesi) ve Poka-Yoke (hata önleme) aynı sürecin farklı kararlarıdır. Hız uğruna kontrol kaldırılmaz; kontrolün nerede ve kim tarafından yapıldığı yeniden tasarlanır. Önce adımın değerini, sonra devredilebilirliğini, ardından otomasyon olanağını sorgulamak gerekir. İlke: Elimination / değer katmayan adımı ayıkla Tasarım sorusu: Bu adım müşteri değeri, mevzuat veya iç kontrol için neden gerekli? Olası müdahale: Mükerrer veri girişi, kullanılmayan form ve yinelenen rutin onayı kaldır Kabul / koruma koşulu: Kaldırılan adımın kontrol işlevi belgelenmiş ve yeni akışta karşılanmış olmalı İlke: Flow / kesintisiz akış Tasarım sorusu: İş birim veya sistem sınırında ne kadar bekliyor? Olası müdahale: Tek iş kaydı, açık durum kodları ve otomatik bildirim Kabul / koruma koşulu: Handoff, hata ve geri dönüş yolu uçtan uca test edilmeli İlke: Pull / gerçek talep Tasarım sorusu: İş hangi doğrulanmış olayla başlamalı? Olası müdahale: Sipariş, stok eşiği veya onaylı ihtiyaç tetiklemesi Kabul / koruma koşulu: Mükerrer tetikleme ve gereksiz üretim engellenmeli İlke: Poka-Yoke / hata önleme Tasarım sorusu: Hata hangi alanda ve hangi anda yakalanabilir? Olası müdahale: Zorunlu alan, tutar/limit kontrolü ve fatura-sipariş eşleştirmesi Kabul / koruma koşulu: Yanlış pozitifler, erişilebilirlik ve istisna onayı izlenmeli ‘Hatasız akış’ bir tasarım yönüdür. Üretim ortamında sıfır hata iddiası, gözlem dönemi ve hata tanımı olmadan sonuç diye raporlanmaz. 3. AS-IS / TO-BE DÖNÜŞÜM VE KAZANIM MATRİSİ Aşağıdaki üç akış kaynak metindeki örnekleri korunarak operasyonel hale getirilmiştir. As-Is sütunu gerçek bir müşteri bulgusu değildir; D-RJ-01 işlem iziyle doğrulanır. To-Be sütunu önerilen tasarımdır. Son sütundaki sayılar gerçekleşmiş kazanım değil, pilot öncesi test edilecek hedef hipotezleridir. Süreç: Satın alma talep ve onay As-Is örnek durum: E-posta ile çoklu onay; Excel'de manuel takip To-Be tasarım: ERP'de tek talep, bütçe ve limit kontrolü, istisnada rol bazlı eskalasyon Ölçüm ve hedef hipotezi: Başlangıç median/P90 onay süresine göre kısalma; %75 kaynak iddiası pilotla sınanır Kontrol sahibi: Satın alma lideri + CFO/iç kontrol Süreç: Veri girişi ve raporlama As-Is örnek durum: Departman tabloları elle birleştiriliyor To-Be tasarım: Kaynak sistem sahipliği, veri sözlüğü ve mutabakatlı konsolide rapor Ölçüm ve hedef hipotezi: Alan doğruluğu ve manuel dokunma dakika/işlem; %100 doğruluk ve sıfır efor vaat edilmez Kontrol sahibi: Veri sahibi + finans Süreç: Müşteri sipariş karşılama As-Is örnek durum: Satış ile depo arasında sözlü/e-posta teyit To-Be tasarım: CRM/ERP siparişi → stok uygunluğu → rezervasyon → onaylı sevkiyat Ölçüm ve hedef hipotezi: Sipariş hata/iade oranı ve teslim süresi; sıfır hata hedefi kanıt gerektirir Kontrol sahibi: Satış + operasyon/depo Her hücre için yerel süreç ID, sistem adı, işlem hacmi, baz dönem ve hedef tarih ayrıca doldurulur. Baz çizgisi olmayan yüzde hedefi bütçe veya yatırım gerekçesine dönüştürülmez. 4. TO-BE SÜREÇ MİMARİSİ VE ORTAK VERİ SÖZLEŞMESİ Bir iş olayı tek bir kimlikle izlenir: talep/sipariş ID, müşteri veya tedarikçi ID, açılış zamanı, durum, sahip rol, tutar/para birimi, gerekli onay, değişiklik izi ve kapanış zamanı. Kaynak sistem (system of record) süreç bazında yazılır; ortak raporlama katmanı kaynak kaydı sessizce değiştirmez. İş kuralları uygulama ekranı, API ve raporda aynı sürümde tutulur. Önerilen durum dizisi: Taslak → Doğrulandı → Onay Bekliyor → Onaylandı/Reddedildi → İcra Edildi → Mutabık → Kapandı. Her geçiş için yetkili rol, zorunlu alan, zaman damgası ve geri alma yolu tanımlanır. İstisnalar kayıt dışı e-posta veya sözlü talimatla atlatılmaz; gerekçe, süre ve onaycı ile ayrı kuyrukta görünür. Entegrasyon sözleşmesi - Girdi: olay adı, kaynak ID, şema sürümü, oluşma zamanı ve idempotency anahtarı. Aynı olay iki kez gelirse tek işlem yaratılır. - Doğrulama: zorunlu alan, müşteri/tedarikçi eşleşmesi, stok veya bütçe uygunluğu ve yetki limiti. - Çıktı: işlem durumu, hata kodu, sorumlu kuyruk ve denetim izi. Başarısız aktarım sessizce kaybolmaz; yeniden deneme ve insan incelemesine düşer. - Güvenlik: en az yetki, sistem hesabı ayrımı, erişim kaydı, saklama süresi ve veri sınıfına göre görünürlük. 5. SATIN ALMA TALEP VE ONAY AKIŞININ YENİDEN TASARIMI Amaç talebin gerekli bütçe ve tedarik kontrolünden geçerken bekleme ve mükerrer girişi azaltmaktır. Yetki sınırı ve satın alma politikası şirket tarafından onaylanır; sistem otomatik onay verecekse limit, mali dönem, tedarikçi statüsü ve görevler ayrılığı kuralı birlikte test edilir. Pilot öncesinde en az bir normal, bir limit aşımı, bir mükerrer talep ve bir reddedilmiş tedarikçi senaryosu test edilir. TOBE-SAT-01: Talep → sipariş Amaç: Rutin satın alma talebini izlenebilir tek iş kaydında sonuçlandırmak. Adımlar: 1. İhtiyaç sahibi ERP'de talep açar; maliyet merkezi, miktar, gerekçe ve hedef tarih zorunludur. 2. Sistem mükerrer talep, onaylı tedarikçi, mevcut stok ve bütçe uygunluğunu kontrol eder; eksik bilgi talep sahibine döner. 3. Politika içi rutin işlem yetki matrisindeki onaycıya yönlenir; limit üstü, tek tedarikçi veya olağandışı fiyat iç kontrol incelemesine yükseltilir. 4. Onay sonrası satın alma emri üretilir; mal/hizmet kabulü ve fatura eşleştirmesi farklı rollerce yapılır. 5. İşlem kapanınca süre, iade ve istisna kodları D-RJ-14 KPI kaydına aktarılır. Kontrol Noktası: Talep açan, siparişi onaylayan ve ödemeyi yapan rollerin çakışması kontrol edilir. Otomatik onay, şirketin belirlediği tutar ve risk sınırını aşamaz. 6. VERİ GİRİŞİ VE RAPORLAMA AKIŞININ YENİDEN TASARIMI Tekil doğruluk kaynağı tek veritabanı demek değildir. Her alan için yetkili kaynak, veri sahibi, güncelleme ritmi ve mutabakat kuralı belirlenir. Konsolide rapor yalnızca tamamlanmış veya açıkça işaretlenmiş istisna kayıtlarını toplar. Sistemler arası uyuşmazlık, ‘en son yazan kazanır’ yöntemiyle gizlenmez. TOBE-VERI-01: Kaynak → mutabakat → kokpit Amaç: Raporun temel alanlarını bir kez üretip doğrulanmış biçimde yeniden kullanmak. Adımlar: 1. Veri sahibi müşteri, sipariş, fatura ve maliyet alanları için kaynak sistemi ve tanımı onaylar. 2. Entegrasyon olayları şema ve alan doğrulamasından geçer; başarısız kayıt veri kalite kuyruğuna alınır. 3. Finans ve operasyon toplamları belirlenen tarihte mutabık kılınır; açık farklar raporda ayrı görünür. 4. Kokpit veri tazeliği, kayıt sayısı ve mutabakat durumunu göstererek yayımlanır. 5. Aylık rapor dönem kapanışında sürümlenir; daha sonraki düzeltmeler yeni sürüm olarak izlenir. Kontrol Noktası: Kritik tutarlar ve işlem sayıları kaynak sistemle örneklem bazında karşılaştırılır; erişim ve veri düzeltme yetkileri ayrılır. 7. MÜŞTERİ SİPARİŞ KARŞILAMA AKIŞININ YENİDEN TASARIMI Satışın verdiği teslim taahhüdü depo veya operasyonun gerçek kapasitesiyle eşleşmelidir. Otomatik sevkiyat emri, siparişin geçerli olması ve stokun ayrılmış olması şartıyla üretilir; tedarik, iade ve kredi istisnaları otomatik akıştan ayrılır. TOBE-SIP-01: Sipariş → stok → sevkiyat Amaç: Sözlü teyit döngüsünü kayıtlı kapasite ve stok kararına dönüştürmek. Adımlar: 1. Satış onaylı siparişi CRM/ERP'ye tek ID ile kaydeder; adres, ürün, miktar, tarih ve fiyat doğrulanır. 2. Sistem stok veya kapasiteyi sorgular; uygun miktarı ayırır, eksik kısmı istisna kuyruğuna taşır. 3. Operasyon, teslim taahhüdü ve taşıma kuralını onaylar; yalnızca uygun sipariş için sevkiyat işi açılır. 4. Depo barkod/ürün eşleştirmesi ve çıkış kontrolü yapar; teslim kanıtı sipariş kaydına döner. 5. İade veya yanlış ürün olayı kök neden koduyla açılır ve sonraki süreç kalibrasyonuna girer. Kontrol Noktası: Müşteriye otomatik taahhüt verilmeden önce stok doğruluğu ve teslim kapasitesi teyit edilir. Yüksek riskli/özel sipariş insan onayı alır. 8. YETKİ, İSTİSNA, İÇ KONTROL VE DEĞİŞİM YÖNETİMİ Her To-Be adımının bir icracısı (R), tek hesap veren sahibi (A), gerekli danışılan rolü (C) ve bilgilendirilen paydaşı (I) vardır. Sistem kuralı ile hukuki imza yetkisi karıştırılmaz. Limitler belgelenmeden ‘otomatik onay’ açılmaz; erişim düzeni D-IS-07 Yetki Matrisi ile uyumlu hale getirilir. İstisna kuyruğu en az dört olayı içerir: veri eksikliği, limit aşımı, sistem hatası ve müşteri/tedarikçi uyuşmazlığı. Her olay için sahibin yanıt süresi, yedek rol, eskalasyon ve geri alma adımı yazılır. Pilot sırasında eski yol bir süre kontrollü geri dönüş olarak tutulur; kapanış kararı ölçüm ve güvenlik testlerinden sonra verilir. Karar: Satın alma limit kuralı R / uygulayan: Satın alma süreç sahibi A / tek hesap veren: CFO / atanacak yetkili C / danışılan: İç kontrol, BT I / bilgilendirilen: Operasyon lideri Karar: Kaynak alan ve veri düzeltmesi R / uygulayan: Veri yöneticisi A / tek hesap veren: Veri sahibi C / danışılan: Finans, operasyon I / bilgilendirilen: Rapor kullanıcıları Karar: Sipariş taahhüt ve sevkiyat kuralı R / uygulayan: Operasyon/depo A / tek hesap veren: COO / atanacak yetkili C / danışılan: Satış, müşteri deneyimi I / bilgilendirilen: Finans Karar: Pilot canlıya geçiş R / uygulayan: Ürün/BT ekibi A / tek hesap veren: Proje sponsoru C / danışılan: Süreç sahibi, güvenlik, iç kontrol I / bilgilendirilen: Etkilenen ekipler Bu RACI roller için başlangıç örneğidir. Şirketin mevcut imza sirküleri ve organizasyonuyla doğrulanmadan yetki ataması sayılmaz. 9. SEKİZ HAFTALIK UYGULAMA VE GEÇİŞ TAKVİMİ Takvim D-RJ-01 teşhisi tamamlandıktan sonra başlar. İlk dört hafta tasarım ve hazırlığa, sonraki dört hafta kontrollü pilot ve geçişe ayrılır. Veri erişimi, yazılım geliştirme veya hukuki izin bağımlılığı gecikirse süre yeniden planlanır; takvim tek başına canlıya geçiş onayı değildir. Hafta / evre: 1–2 / tasarım Saha faaliyeti: As-Is bulgularını doğrula; değer ve kontrol analizini yap Somut teslimat: Öncelikli süreç listesi, kaldırılacak adımlar, taslak To-Be Kapı / onay: Süreç sahibi + iç kontrol Hafta / evre: 3–4 / hazırlık Saha faaliyeti: Akış, veri sözlüğü, RACI, istisna ve test senaryolarını tamamla Somut teslimat: Onaylı akış şeması, entegrasyon sözleşmesi, pilot planı Kapı / onay: Proje sponsoru + sistem sahibi Hafta / evre: 5–6 / pilot Saha faaliyeti: Seçili departmanda normal ve istisna işlemlerini çalıştır Somut teslimat: Test kanıtı, hata listesi, eğitim kaydı, ilk KPI Kapı / onay: Pilot kabul veya düzeltme Hafta / evre: 7–8 / geçiş Saha faaliyeti: Düzelt, kullanıcıları eğit, kontrollü canlıya al ve izle Somut teslimat: SOP sürümü, destek/geri alma planı, devir tutanağı Kapı / onay: Canlıya geçiş ve süreç sahibi devir onayı Evre 1 kaynak metindeki 1–4, Evre 2 ise 5–8. haftalara karşılık gelir. Akış şeması ilanı eğitim ve erişim doğrulamasıyla birlikte yapılır. 10. KPI BAZ ÇİZGİSİ, PİLOT TESTİ VE KABUL KRİTERLERİ Kazanım yalnızca aynı süreç tanımıyla, karşılaştırılabilir hacim ve dönemlerde ölçülür. Pilot öncesi baz çizgi ile pilot sonrası dönem için işlem sayısı, median/P90 süre, hata/yeniden işleme oranı, aktif insan dakikası, kontrol istisnası ve müşteri şikâyeti birlikte raporlanır. Hacim veya işlem karışımı değiştiyse karşılaştırma bu farkla birlikte sunulur. Örnek hedef kartı: Satın alma onay median süresi [baz gün] → [hedef gün]; ilk seferde doğru işlem oranı [baz %] → [hedef %]; veri mutabakat farkı [baz adet/tutar] → [hedef]; sipariş iade oranı [baz %] → [hedef %]. Bu alanlar şirket ölçümü ve yönetim onayıyla doldurulur. %75 süre kısalması, %100 doğruluk veya sıfır iade yalnızca erişilirse ve dönem/örneklem açıklanırsa sonuç olarak yazılır. Pilot test senaryoları - Normal işlem, eksik veri, limit aşımı, mükerrer talep, sistem kesintisi ve geri alma test edilir. - Kullanıcı deneyimi, erişim yetkisi ve destek yükü hedef KPI ile birlikte değerlendirilir. - Kontrol zafiyeti veya müşteri zararı görülürse yaygınlaştırma durdurulur, olay sahibi atanır. Kabul kapısı - Süreç sahibi akış ve SOP'yi; finans/iç kontrol kontrol noktalarını; sistem sahibi entegrasyon ve geri alma planını; proje sponsoru ölçülen etkiyi onaylar. - Açık hata ve istisnalar sahip, son tarih ve kabul edilen risk düzeyiyle devir tutanağında görünür. 11. TESLİM PAKETİ, SÜRÜMLEME VE SONRAKİ ÇALIŞMA D-RJ-03 teslim paketi şu dosyalardan oluşur: D-RJ-01 bulgu referansları, As-Is/To-Be akışları, adım kaldırma gerekçesi, RACI ve limit tablosu, alan/veri sözlüğü, API veya BPM iş kuralı, istisna kuyruğu, test senaryoları ve sonuçları, eğitim kaydı, KPI karşılaştırması, destek/geri alma planı ve devir tutanağı. Her parçanın sahibi, tarihi, sürümü ve onay durumu görünür olur. Bu plan operasyonel tasarımın kararıdır; D-RJ-05 olarak önerilen ‘Sıfır Tabanlı Bütçeleme ve Maliyet Optimizasyon Modeli’ henüz bu yeni dizide yazılmamıştır. Önceki arşivde D-RJ-05 kodu Marka Anayasası ve Kimlik Kılavuzu'na aittir. Yeni finans belgesi hazırlanırken aynı kod çakışması korunmuş kayıtlar üzerinden açıkça çözülecektir. - Hazırlayan: [ad/rol, sürüm/tarih]. Süreç sahipleri: [ad/rol]. Veri ve sistem sahibi: [ad/rol]. Kontrol incelemesi: [ad/rol]. - Karar: [tasarım onayı / koşullu pilot / iade]. Açık koşullar: [bulgu ID, aksiyon sahibi, son tarih]. Sonraki gözden geçirme: [tarih]. D-RJ-03, ölçüm baz çizgisi, kontrol etkisi ve pilot kabulü tamamlandığında uygulama ve finansal optimizasyon işlerine devredilir. Yeni seride önerilen D-RJ-05 finans belgesi, önceki D-RJ-05 marka kılavuzuyla kod çakışması taşıdığı için henüz ayrı kayıt olarak yayımlanmamıştır.