Sipariş Durumları ve Operasyon Kuralları Nasıl Tasarlanır?
Ders 2 / 10 · 30 dakika okuma · İleri
Sipariş, ödeme, fulfillment ve kargo durumlarını birbirine karıştırmadan modellemeyi; geçiş kuralları, zaman aşımı, iptal ve istisna kontrolleriyle güvenilir sipariş durum yönetimi kurmayı öğrenin.
Bu Derste Öğrenecekleriniz
- ✓Sipariş durumu ile ödeme, fulfillment ve kargo durumunu ayırmak
- ✓Durum geçişlerini gerçek iş olaylarına bağlamak
- ✓Geçersiz ve geri dönüşü riskli durum geçişlerini önlemek
- ✓İptal talebini otomatik iptal sonucundan ayırmak
- ✓Zaman aşımı ve bekleyen sipariş kontrolleri oluşturmak
- ✓Durum geçmişini audit ve KPI amacıyla kullanmak
- ✓Müşteriye gösterilen durum ile iç operasyon durumunu doğru ilişkilendirmek
E-ticaret operasyonunda en sık yapılan tasarım hatalarından biri, bütün gerçekliği tek bir sipariş durumu alanına sıkıştırmaktır. 'Hazırlanıyor' görünen bir siparişin ödemesi doğrulanmış mı, stok ayrılmış mı, paketlenmiş mi veya kargo etiketi basılmış mı soruları ayrı operasyon gerçekleridir.
1. Durumları ayrı yaşam döngülerine bölün
| Durum ailesi | Örnek durumlar | Ne anlatır? |
|---|---|---|
| Sipariş | Yeni / İşleniyor / Tamamlandı / İptal | Ticari siparişin genel yaşam döngüsü |
| Ödeme | Bekliyor / Başarılı / Başarısız / İade | Finansal işlem gerçeği |
| Fulfillment | Bekliyor / Toplanıyor / Paketlendi / Hazır | Depo hazırlık süreci |
| Kargo | Etiketlendi / Taşıyıcıya verildi / Dağıtımda / Teslim | Fiziksel gönderi süreci |
| İstisna | Stok sorunu / Adres sorunu / Hasar / Kayıp | Normal akışı bozan olay |
Not — Durum adları işletmeye göre değişebilir
2. Durumu kullanıcı tıklamasıyla değil doğrulanmış olayla değiştirin
Bir çalışanın 'Kargoya Verildi' düğmesine basması tek başına fiziksel devir kanıtı değildir. İşletmenin olgunluk seviyesine göre taşıyıcı kabul olayı, manifest/devir kaydı veya ilk taşıyıcı hareketi gibi doğrulanabilir olaylar durum değişikliğini desteklemelidir.
Örnek — Etiket üretildi ama paket depoda
3. Durum geçiş matrisi oluşturun
Her durumdan her duruma geçişe izin verilmemelidir. Geçiş matrisi, hangi mevcut durumdan hangi hedef duruma hangi koşulla geçilebileceğini belirler.
| Mevcut durum | Hedef durum | Örnek koşul | İzin |
|---|---|---|---|
| Operasyon bekliyor | Hazırlanıyor | Ödeme/stok/risk uygun | Evet |
| Hazırlanıyor | Paketlendi | Toplama + kontrol tamam | Evet |
| Paketlendi | Taşıyıcıya verildi | Fiziksel devir doğrulandı | Evet |
| Teslim edildi | Hazırlanıyor | Normal akışta anlamsız | Hayır |
| İptal edildi | Taşıyıcıya verildi | İptal kapanmış | Hayır |
4. Genel sipariş durumunu alt süreçlerden türetin
Siparişin genel görünümü müşteriye ve yönetim ekranına sade bir özet sunabilir; ancak gerçek operasyon kararı alt süreçlerin durumlarından üretilmelidir. Örneğin ödeme başarılı, fulfillment paketlendi ve kargo henüz devralmadıysa genel sipariş 'hazırlanıyor/sevke hazır' gibi bir görünümde olabilir.
5. İptal talebi ile iptal sonucunu ayırın
Müşterinin iptal istemesi siparişin o anda güvenle iptal edilebildiği anlamına gelmez. Siparişin ödeme, fulfillment ve kargo aşaması kontrol edilmelidir. Paket taşıyıcıya devredildiyse süreç iptalden teslimat/iade yönetimine dönüşebilir.
| Operasyon aşaması | İptal talebinde kontrol | Olası yaklaşım |
|---|---|---|
| Hazırlama başlamadı | Ödeme + stok rezervasyonu | İptal ve rezervasyon/iade işlemleri |
| Toplanıyor/paketleniyor | Depoda durdurulabilir mi? | Operasyonu durdur ve kontrollü iptal |
| Taşıyıcıya devredildi | Gönderi geri çağırma mümkün mü? | Taşıyıcı süreci veya teslimat sonrası iade |
| Teslim edildi | İptal artık uygun kavram değil | İade süreci |
Uyarı — İptal ile finansal iadeyi aynı işlem saymayın
6. Bekleyen durumlara zaman aşımı kuralları ekleyin
Siparişler 'bekliyor' durumunda süresiz kalmamalıdır. Ödeme bekliyor, stok problemi, adres düzeltme bekliyor veya kargo hareketi bekliyor gibi durumlar için işletme politikası ve müşteri vaadine uygun zaman eşikleri tanımlanmalıdır.
Örnek — Aging kuyruğu
7. Durum değişikliklerinde neden kodu kullanın
- Müşteri talebiyle iptal
- Stok bulunamadı
- Ödeme doğrulanamadı
- Risk incelemesi
- Adres problemi
- Ürün hasarlı
- Taşıyıcı kabul hatası
- Teslim edilemedi
- Operasyonel düzeltme
Serbest metin açıklama yararlı olabilir ancak raporlama için tek başına yeterli değildir. Standart neden kodu + isteğe bağlı açıklama modeli, hangi sorunların tekrarlandığını ölçmeyi kolaylaştırır.
8. Manuel durum değişikliklerini kontrollü tutun
Operasyon ekibinin istisnai durumlarda manuel düzeltme yapması gerekebilir. Ancak kim, hangi eski durumdan hangi yeni duruma, hangi gerekçeyle ve ne zaman geçti bilgisi audit kaydında tutulmalıdır. Kritik geçişler rol/yetki kontrolüne bağlanabilir.
9. Müşteriye iç operasyon jargonunu göstermeyin
İçeride 'pick wave assigned', 'pack QC failed' veya 'carrier handover pending' gibi ayrıntılı durumlar bulunabilir. Müşteri tarafında ise daha anlaşılır 'Siparişiniz hazırlanıyor', 'Kargoya verildi' veya 'Teslimatla ilgili bir sorun üzerinde çalışıyoruz' gibi durumlar kullanılabilir.
| İç durum | Müşteri görünümü | Neden |
|---|---|---|
| Pick bekliyor | Hazırlanıyor | Depo jargonunu gizler |
| Pack QC | Hazırlanıyor | Aynı müşteri aşaması |
| Taşıyıcıya devir doğrulandı | Kargoya verildi | Fiziksel olay gerçekleşti |
| Delivery exception | Teslimat sorunu | Müşteriye anlaşılır aksiyon bilgisi |
10. Parçalı sevkiyat ihtiyacını baştan düşünün
Bir siparişteki ürünler farklı depolardan veya farklı zamanlarda gönderilebiliyorsa tek sipariş durumu fiziksel gerçeği açıklayamaz. Sipariş altında birden fazla shipment/gönderi kaydı tutulmalı; her gönderinin kendi ürünleri, taşıyıcısı, takip numarası ve teslimat durumu bulunmalıdır.
Örnek — İki paketli sipariş
11. Durum geçmişinden operasyon KPI'ları üretin
| Olay zamanları | Üretilebilecek ölçüm |
|---|---|
| Sipariş oluşturuldu → operasyona serbest | Ön kontrol bekleme süresi |
| Operasyona serbest → toplama başladı | Kuyruk bekleme süresi |
| Toplama başladı → paketlendi | Fulfillment işlem süresi |
| Paketlendi → taşıyıcıya devir | Sevk bekleme süresi |
| Taşıyıcıya devir → teslim | Transit süresi |
| İstisna açıldı → kapandı | İstisna çözüm süresi |
12. Durum modelini gerçek senaryolarla test edin
- Başarılı ödeme + stok var + normal teslimat
- Ödeme başarısız
- Ödeme başarılı fakat stok yok
- Hazırlama sırasında ürün hasarlı
- Paketlenmeden müşteri iptal talebi
- Etiket oluştu fakat taşıyıcıya devir gerçekleşmedi
- Parçalı sevkiyat
- Teslim edilememe
- Teslimat sonrası iade
Şimdi Uygulayın
Uygulama Görevi — Sipariş Durum ve Geçiş Matrisi
Sipariş, ödeme, fulfillment ve kargo için ayrı durum listeleri oluşturun. En az 12 kritik geçiş için mevcut durum, hedef durum, tetikleyen olay, gerekli koşul, sorumlu sistem/rol ve hata halinde yapılacak işlemi yazın.
| Durum ailesi | Mevcut | Hedef | Tetikleyici | Koşul | Hata/istisna |
|---|---|---|---|---|---|
| Ödeme | … | … | … | … | … |
| Fulfillment | … | … | … | … | … |
| Kargo | … | … | … | … | … |
| Sipariş | … | … | … | … | … |
İpucu — Kabul testi
Bu Derste Ne Öğrendik?
- ✓Tek bir 'sipariş durumu' alanına ödeme, depo, kargo ve müşteri deneyimini sıkıştırmak operasyonu belirsizleştirir.
- ✓Ödeme, fulfillment ve sevkiyat kendi yaşam döngülerine sahip olmalı; siparişin genel durumu bu gerçek olaylardan türetilmelidir.
- ✓Durum değişiklikleri geçiş kuralları, zaman damgaları ve neden kodlarıyla kaydedildiğinde hatalı sevkiyat, erken iptal ve görünmeyen beklemeler azaltılabilir.