Sipariş durumları nasıl tasarlanır? Durum akışı rehberi

Sipariş durumu bir etiket değil, iş akışının sözleşmesidir: hangi durumdan hangisine geçilebileceğini ve her geçişte hangi işin tetikleneceğini belirler. İyi tasarlanmış bir durum kümesi azdır, maddeleri birbirini dışlar ve her biri gerçek bir iş kararına karşılık gelir. Durum listesi uzadıkça kullanıcı hangi kaydı ne yapacağını bilemez, raporlar tutmaz ve entegrasyonlar birbirine karışır. Aşağıda durum kümesinin nasıl sadeleştirileceğini, geçişlerin nasıl tanımlanacağını ve dış sistemlerden gelen durumların nasıl eşleneceğini anlatıyoruz.

Durum listesi neden zamanla şişer

Şişmenin sebebi genelde şudur: bir ihtiyaç ortaya çıkar, hızlı çözüm olarak listeye yeni bir durum eklenir. Kargoya verildi varken kargoya hazır eklenir, sonra depoda bekliyor, ardından muhasebe onayında gelir. Birkaç ay sonra listede on beş madde olur ve bunların bir kısmı aslında aynı anda doğru olabilen hâllerdir.

Asıl sorun şudur: eklenen maddelerin çoğu durum değil, duruma eşlik eden bir bilgidir. Muhasebe onayında bir durum değil, bir onay bayrağıdır; sipariş o sırada hazırlanıyor durumunda olmaya devam eder. Bu ayrım yapılmazsa aynı sipariş için iki farklı bilgiye ihtiyaç duyulur, ama alan tektir ve biri feda edilir.

İyi bir durum kümesinin beş özelliği

• Az sayıdadır. Çoğu akış beş ile sekiz durum arasında anlatılabilir.
• Birbirini dışlar. Bir kayıt aynı anda yalnızca tek bir durumda olabilir.
• Bitiş durumları bellidir. Tamamlandı ve iptal edildi gibi, sonrasında geçiş olmayan durumlar açıkça işaretlenir.
• Her durum bir sorumluya karşılık gelir. Kaydın o anda kimin önünde beklediği durumdan okunabilmelidir.
• İsimler iş dilindedir. Durum adı depodaki ve muhasebedeki kişinin kullandığı kelime olmalı, teknik kısaltma olmamalıdır.

Tek eksen yetmez: durumu bayraklardan ayırın

Bir siparişin aynı anda birden fazla ekseni vardır. Sipariş hazırlanıyor olabilir ama ödemesi beklemede, ya da teslim edilmiş olabilir fakat iade talebi açılmıştır. Bunların tek bir alana sıkıştırılması, durum sayısını eksenlerin çarpımı kadar büyütür. Pratik çözüm eksenleri ayırmaktır: sipariş durumu, ödeme durumu, sevkiyat durumu ve iade durumu ayrı alanlarda tutulur. Böylece her eksenin kendi kısa listesi olur ve raporlar sade kalır.

Ayrım yapıldığında ekranlarda görünen metin de sadeleşir: kullanıcı ana durumu başlıkta, diğer eksenleri rozet olarak görür. Bu yapı, veri modeli kararlarının arayüz kararlarından önce geldiğini gösteren tipik bir örnektir.

Geçiş tablosu nasıl kurulur

Bu tablo yazılı değilse kural koda dağılır ve her ekran kendi istisnasını üretir. Tablo tek yerde tanımlandığında, izinsiz bir geçiş denemesi anlaşılır bir hata mesajıyla reddedilir. Tabloda yer almayan geçişler yasaktır; bu varsayım açıkça yazılmalıdır.

Her geçişte ne tetiklenir

1. Stok hareketi: Hazırlanıyor durumuna geçişte rezervasyon, sevkte çıkış kaydı oluşur.
2. Muhasebe kaydı: Hangi geçişte belge üretileceği tek bir yerde tanımlanır; iki farklı ekranın aynı belgeyi üretmesi engellenir.
3. Bildirim: Müşteriye gidecek mesajlar geçişe bağlanır, ekranın kaydet düğmesine değil.
4. Dış çağrı: Kargo etiketi talebi gibi geri alınamayan işlemler yalnızca belirli bir geçişte yapılır.
5. İz kaydı: Her geçişte kim, ne zaman, hangi durumdan hangisine ve hangi gerekçeyle geçirdi bilgisi yazılır.

Tetiklemelerin geçişe bağlanması, aynı işin iki kez yapılmasını da engeller. Kaydet düğmesine bağlı bir bildirim, kullanıcı formu iki kez kaydettiğinde müşteriye iki mesaj gönderir; geçişe bağlı bildirim ise durum gerçekten değişmediği sürece hiç çalışmaz.

Durum geçmişi: alanı güncellemek yetmez

Yalnızca güncel durumu tutan bir tasarım, en çok ihtiyaç duyulan soruyu cevaplayamaz: bu sipariş neden üç gün beklemede kaldı? Geçmişi saklamak için durum alanının yanında bir geçiş kaydı tutulur. Bu kayıt, hem operasyon sorularına hem de süre ölçümlerine temel olur: ortalama hazırlanma süresi, beklemede kalan kayıtların payı, iptal gerekçelerinin dağılımı. Geçmiş tutulmadığında bu ölçümler sonradan üretilemez, çünkü veri hiç yazılmamıştır.

Dış sistem durumlarını kendi akışınıza eşleyin

Kargo firmaları, pazaryerleri ve ödeme sağlayıcıları kendi durum kodlarını gönderir ve bu listeler birbirinden farklıdır. Doğru yaklaşım, gelen kodu olduğu gibi siparişin durumuna yazmak değil, iki ayrı alan tutmaktır: dış sistemin ham kodu ve sizin akışınızdaki karşılığı. Eşleme tablosu kod içinde değil, yönetilebilir bir yerde durur; sağlayıcı yeni bir kod eklediğinde eşlenmemiş kodlar bir uyarıya düşer ve sessizce yanlış duruma yazılmaz.

Eşlemenin yönü tek taraflı da değildir. Siz de pazaryerine ya da müşteriye durum bildiriyorsanız, kendi durumlarınızın karşı tarafta hangi kodla ifade edileceği aynı tabloda tutulur. İki ayrı yerde tutulan eşleme zamanla birbirinden ayrılır ve hangisinin doğru olduğu tartışmaya açılır.

Kısa kontrol listesi

• Durum listesi sekizden uzun mu? Uzunsa, maddelerin hangileri aslında bayrak?
• Ödeme, sevkiyat ve iade ayrı eksenlerde mi tutuluyor?
• Geçiş tablosu yazılı ve tek yerde tanımlı mı?
• Her geçişin tetiklediği işler belgelenmiş mi?
• Durum geçişleri geçmişe dönük sorgulanabilecek şekilde kaydediliyor mu?
• Dış sistemden eşlenmemiş bir durum kodu geldiğinde uyarı üretiliyor mu?

KAV Yazılım, özel yazılım projelerinde durum akışını kapsam belgesinin parçası olarak çıkarır; akış yazılı değilse sonradan her ekip kendi yorumunu kodlar.