D-RJ-03 / REJOURNEY / Operasyonel tasarım belgesi

Süreç Yalınlaştırma ve Yeniden Tasarım Master Planı

D-RJ-01 teşhisini kontrollü To-Be akışlarına, yetki sınırlarına, pilot takvimine ve ölçülebilir kabul kriterlerine dönüştüren plan.

Tam metin 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.

BÖLÜM 01

Amaç, girdi ve karar sınırı

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.

BÖLÜM 02

Dört yalınlaştırma ilkesi ve tasarım testleri

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.

Matrisin tamamı için yatay kaydırabilirsiniz.

Dört yalınlaştırma ilkesi ve tasarım testleri
İlke	Tasarım sorusu	Olası müdahale	Kabul / koruma koşulu
Elimination / değer katmayan adımı ayıkla	Bu adım müşteri değeri, mevzuat veya iç kontrol için neden gerekli?	Mükerrer veri girişi, kullanılmayan form ve yinelenen rutin onayı kaldır	Kaldırılan adımın kontrol işlevi belgelenmiş ve yeni akışta karşılanmış olmalı
Flow / kesintisiz akış	İş birim veya sistem sınırında ne kadar bekliyor?	Tek iş kaydı, açık durum kodları ve otomatik bildirim	Handoff, hata ve geri dönüş yolu uçtan uca test edilmeli
Pull / gerçek talep	İş hangi doğrulanmış olayla başlamalı?	Sipariş, stok eşiği veya onaylı ihtiyaç tetiklemesi	Mükerrer tetikleme ve gereksiz üretim engellenmeli
Poka-Yoke / hata önleme	Hata hangi alanda ve hangi anda yakalanabilir?	Zorunlu alan, tutar/limit kontrolü ve fatura-sipariş eşleştirmesi	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.

BÖLÜM 03

As-Is / To-Be dönüşüm ve kazanım matrisi

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.

Matrisin tamamı için yatay kaydırabilirsiniz.

As-Is / To-Be dönüşüm ve kazanım matrisi
Süreç	As-Is örnek durum	To-Be tasarım	Ölçüm ve hedef hipotezi	Kontrol sahibi
Satın alma talep ve onay	E-posta ile çoklu onay; Excel'de manuel takip	ERP'de tek talep, bütçe ve limit kontrolü, istisnada rol bazlı eskalasyon	Başlangıç median/P90 onay süresine göre kısalma; %75 kaynak iddiası pilotla sınanır	Satın alma lideri + CFO/iç kontrol
Veri girişi ve raporlama	Departman tabloları elle birleştiriliyor	Kaynak sistem sahipliği, veri sözlüğü ve mutabakatlı konsolide rapor	Alan doğruluğu ve manuel dokunma dakika/işlem; %100 doğruluk ve sıfır efor vaat edilmez	Veri sahibi + finans
Müşteri sipariş karşılama	Satış ile depo arasında sözlü/e-posta teyit	CRM/ERP siparişi → stok uygunluğu → rezervasyon → onaylı sevkiyat	Sipariş hata/iade oranı ve teslim süresi; sıfır hata hedefi kanıt gerektirir	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.

BÖLÜM 04

To-Be süreç mimarisi ve ortak veri sözleşmesi

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.

BÖLÜM 05

Satın alma talep ve onay akışının yeniden tasarımı

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

İhtiyaç sahibi ERP'de talep açar; maliyet merkezi, miktar, gerekçe ve hedef tarih zorunludur.
Sistem mükerrer talep, onaylı tedarikçi, mevcut stok ve bütçe uygunluğunu kontrol eder; eksik bilgi talep sahibine döner.
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.
Onay sonrası satın alma emri üretilir; mal/hizmet kabulü ve fatura eşleştirmesi farklı rollerce yapılır.
İş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.

BÖLÜM 06

Veri girişi ve raporlama akışının yeniden tasarımı

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

Veri sahibi müşteri, sipariş, fatura ve maliyet alanları için kaynak sistemi ve tanımı onaylar.
Entegrasyon olayları şema ve alan doğrulamasından geçer; başarısız kayıt veri kalite kuyruğuna alınır.
Finans ve operasyon toplamları belirlenen tarihte mutabık kılınır; açık farklar raporda ayrı görünür.
Kokpit veri tazeliği, kayıt sayısı ve mutabakat durumunu göstererek yayımlanır.
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.

BÖLÜM 07

Müşteri sipariş karşılama akışının yeniden tasarımı

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

Satış onaylı siparişi CRM/ERP'ye tek ID ile kaydeder; adres, ürün, miktar, tarih ve fiyat doğrulanır.
Sistem stok veya kapasiteyi sorgular; uygun miktarı ayırır, eksik kısmı istisna kuyruğuna taşır.
Operasyon, teslim taahhüdü ve taşıma kuralını onaylar; yalnızca uygun sipariş için sevkiyat işi açılır.
Depo barkod/ürün eşleştirmesi ve çıkış kontrolü yapar; teslim kanıtı sipariş kaydına döner.
İ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.

BÖLÜM 08

Yetki, istisna, iç kontrol ve değişim yönetimi

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.

Matrisin tamamı için yatay kaydırabilirsiniz.

Yetki, istisna, iç kontrol ve değişim yönetimi
Karar	R / uygulayan	A / tek hesap veren	C / danışılan	I / bilgilendirilen
Satın alma limit kuralı	Satın alma süreç sahibi	CFO / atanacak yetkili	İç kontrol, BT	Operasyon lideri
Kaynak alan ve veri düzeltmesi	Veri yöneticisi	Veri sahibi	Finans, operasyon	Rapor kullanıcıları
Sipariş taahhüt ve sevkiyat kuralı	Operasyon/depo	COO / atanacak yetkili	Satış, müşteri deneyimi	Finans
Pilot canlıya geçiş	Ürün/BT ekibi	Proje sponsoru	Süreç sahibi, güvenlik, iç kontrol	Etkilenen ekipler

Bu RACI roller için başlangıç örneğidir. Şirketin mevcut imza sirküleri ve organizasyonuyla doğrulanmadan yetki ataması sayılmaz.

BÖLÜM 09

Sekiz haftalık uygulama ve geçiş takvimi

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.

Matrisin tamamı için yatay kaydırabilirsiniz.

Sekiz haftalık uygulama ve geçiş takvimi
Hafta / evre	Saha faaliyeti	Somut teslimat	Kapı / onay
1–2 / tasarım	As-Is bulgularını doğrula; değer ve kontrol analizini yap	Öncelikli süreç listesi, kaldırılacak adımlar, taslak To-Be	Süreç sahibi + iç kontrol
3–4 / hazırlık	Akış, veri sözlüğü, RACI, istisna ve test senaryolarını tamamla	Onaylı akış şeması, entegrasyon sözleşmesi, pilot planı	Proje sponsoru + sistem sahibi
5–6 / pilot	Seçili departmanda normal ve istisna işlemlerini çalıştır	Test kanıtı, hata listesi, eğitim kaydı, ilk KPI	Pilot kabul veya düzeltme
7–8 / geçiş	Düzelt, kullanıcıları eğit, kontrollü canlıya al ve izle	SOP sürümü, destek/geri alma planı, devir tutanağı	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.

BÖLÜM 10

KPI baz çizgisi, pilot testi ve kabul kriterleri

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.

BÖLÜM 11

Teslim paketi, sürümleme ve sonraki çalış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].

ONAY VE SONRAKİ ÇALIŞMALAR

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.

D-RJ-01 · Operasyonel Röntgen ↗Önceki serideki D-RJ-09 · BPR Raporu ↗Önceki D-RJ-03 · Vizyon/Misyon Manifestosu ↗

Çalışmanın bağlamı.

Katalog kaydı ↗ReStructuring modülü ↗Saha planı ve teslimatlar ↗Önceki D-RJ-03 vizyon/misyon manifestosu ↗