Sipariş yönetim sistemini tanımlayan şey, yolunda gitmeyen siparişlerde ne yaptığıdır: e-postayla gelen sipariş, iki müşterinin son ürünü istediği durum, geri dönen ürün.
Bu rehber bu vakaların geçen ayın verisinde nasıl bulunacağını, hangi kuralın en çok manuel müdahaleyi kaldırdığını ve devreye aldıktan sonra tek dürüst ölçünün neden müdahale oranı olduğunu anlatıyor.
Kısa cevap
- Ölçü müdahale oranıdır: Kaç siparişin bir kişiye ihtiyaç duyduğu hem iş gerekçesi hem de sistemin işe yarayıp yaramadığının sınavıdır.
- Sistemi istisnalar tanımlar: Geçen ayın elle işlenen siparişleri, gerçek oldukları için her özellik listesinden iyi bir şartnamedir.
- Bir değil üç stok rakamı: Fiziksel, rezerve ve satılabilir stok farklıdır; bunları tek saymak bilinen hatayı üretir.
- Sapma iadelerde başlar: Sistem dışında yürütülen yol, rakamların gerçekle örtüşmeyi bıraktığı yoldur.
Kullanıcı ve iş sonucuyla başlayın
Sipariş sisteminin hedefi, insan dokunmadan tamamlanan sipariş oranını yükseltmektir. Bu oranı bugünkü haliyle ölçün; hem gerekçe hem de sonraki sınav odur. Bu oran yazılmadan yapılan yatırım tartışması, özellik listesi üzerinden yürür ve sonucu ölçülemez.
Geçen ayın elle işlenen siparişlerini nedenlerine göre gruplayın. En büyük grup sistemde eksik olan kuralı, en yavaş grup ise gereken uyarıyı gösterir. Grupları sayıya göre sıralayın; en sinir bozucu istisna genellikle en pahalısı değildir.
Siparişin gelebileceği her kanalı listeleyin; telefonla gelenler ve müşterinin gönderdiği tablo dahil. Kontrolleri atlayan kanallar, gelecek ayın istisnalarını üreten kanallardır. Kanalları listelerken satış ekibine de sorun; resmi kanal listesi nadiren eksiksizdir.
Sipariş yönetim yazılımı geliştirme için dört karar alanı
Sipariş girişi
Siparişin gelebileceği her kanalı listeleyin; telefonla gelenler ve önemli bir müşterinin e-postayla gönderdiği tablo dahil. Hangilerinin diğerlerinin geçtiği kontrolleri atladığını işaretleyin. Gelecek ayın istisnaları o kanallardan gelir.
Karşılama
Stoğun siparişe hangi anda bağlandığına ve iki sipariş son ürünü istediğinde ne olacağına karar verin. Satılabilir stok, fiziksel stok ve rezerve stok üç ayrı rakamdır; bunları tek sayan her operasyon ekibinin tanıdığı hatayı üretir.
İstisnalar
Geçen ayın istisnalarını nedenlerine göre gruplayın ve her birinin fark edilmesinin ne kadar sürdüğünü kaydedin. En büyük grup sistemde eksik olan kuralı, en yavaş grup gereken uyarıyı söyler; bu ikisi genellikle aynı şey değildir.
İadeler
İadenin nasıl onaylandığını, ürünün nereye gittiğini ve para iadesinin ürünün varışına göre ne zaman yapıldığını tanımlayın. Sistem dışında ele alınan yol iadelerdir ve stok rakamları da oradan kaymaya başlar.
Riskler, geliştirme başlamadan önce
- Bazı kanallar kontrolleri atlar: Siparişin gelebileceği her yolu listeleyin ve doğrulamadan geçmeyenleri işaretleyin. Atlanan kontrolleri kapatmak genellikle yeni kural yazmaktan ucuzdur.
- Stok yanlış anda bağlanır: Siparişin stoğu hangi anda aldığını ve iki sipariş son ürünü istediğinde ne olacağını yazın. Stok kuralını depo ekibiyle birlikte yazın.
- İstisnayı önce müşteri fark eder: Her istisna tipini kimin, ne kadar sürede fark ettiğini kaydedin. Fark etme süresi uzun olan istisnalar için uyarı tanımlayın.
- İade sistem dışında yürür: İadenin nasıl onaylanacağını, ürünün nereye gideceğini ve paranın ne zaman döneceğini tanımlayın. İade yolu tanımsızsa stok rakamları birkaç ayda güvenilmez hale gelir.
Uygulanabilir adımlardan bir yol haritası
- Kanalları listeleyin. Siparişin gelebileceği her yolu yazın ve kontrolleri atlayanları işaretleyin.
- İstisnaları gruplayın. Geçen ayın elle işlenen siparişlerini nedenlerine göre ayırın ve fark edilme süresini ölçün.
- Eksik kuralı yazın. En büyük grubun kuralını net biçimde yazın ve iki hafta elle uygulayın.
- Tek ürün grubunda deneyin. Kuralı hacmin onda birinde çalıştırın, ardından müdahale oranına bakarak genişletin.
Güven, izin ve sorumlu veri kullanımı
Sipariş yönetim yazılımı geliştirme için güvenlik gereksinimini yalnızca son teknik teste bırakmayın. Kimlerin hangi kaydı görebildiği, oluşturabildiği, değiştirebildiği, onaylayabildiği ve dışa aktarabildiği rol ve sorumluluk üzerinden tanımlanmalıdır. Hassas kararlar için ek onay, gerekçe veya denetim izi gerekip gerekmediğini iş etkisine göre belirleyin.
Toplanan her veri için amaç, erişim, saklama süresi, düzeltme ve silme yolu yazın. Sipariş yönetim yazılımı geliştirme için kullanıcı değeri gerektirmeyen bilgiyi toplamak, ürünü daha akıllı yapmaz; güven ve işletim yükü oluşturur. Ülke, sektör ve veri türüne göre hukuki veya düzenleyici yükümlülükler değişebileceği için uygun uzman değerlendirmesini planlayın.
Tehdit ve hata senaryosunu bir kullanıcı yolculuğuyla birleştirin: hesap ele geçirilmesi, yanlış kişiye görünürlük, kayıp cihaz, yetki değişikliği veya kötüye kullanım bildirimi olduğunda ne olur? Sipariş yönetim yazılımı geliştirme ekibi olayın etkisini anlayabilmeli, erişimi sınırlayabilmeli ve gerekli inceleme kanıtını koruyabilmelidir.
Sonraki adım
Sipariş yönetim sistemini ekran listesinden çıkarıp tek bir rakama bağlayın: insan müdahalesi olmadan tamamlanan sipariş oranı. Bu rakam hem gerekçe hem de devreye alma sonrası sınavdır.
Bu konuda bir sonraki rehber: İşletme Kontrol Merkezi Panosu Nasıl Kurulur?
30 günlük doğrulama planı: Sipariş yönetim sistemi
1-5. günler: siparişin gelebileceği her yolu listeleyin. Telefonla gelenler, e-postalar ve önemli bir müşterinin gönderdiği tablo dahil her kanalı yazın. Hangilerinin diğerlerinin geçtiği kontrolleri atladığını işaretleyin. İstisnalar oradan gelir ve bunlar genellikle gereksinim toplantısında kimsenin anmadığı kanallardır. Verildikten sonra değiştirilen siparişleri de dahil edin; bir değişiklik, belgelenmemiş bir yoldan gelen ikinci siparişten başka bir şey değildir.
6-15. günler: geçen ayın istisnalarını tek tek çalışın. Bir kişinin müdahale etmesi gereken bütün siparişleri alın ve nedenleri gruplayın. Her grubun fark edilmesinin ve çözülmesinin ne kadar sürdüğünü sayın. En büyük grup sistemde eksik olan kuralı, en yavaş grup ise gereken uyarıyı söyler. Hangi istisnaları müşterinin sizden önce bulduğunu not edin; bunlar işlem süresinde görünmeyen bir maliyet taşır.
16-30. günler: en çok müdahaleyi kaldıran kuralı seçin. O tek kuralı net biçimde yazın, iki hafta elle uygulayın ve müdahaleleri yeniden sayın. Sayı düşmüyorsa kural yanlıştı ve bunu bir sürümün değil iki haftanın bedeliyle öğrenmiş olursunuz. Önce tek bir ürün grubuna uygulayın; her şey için yanlış olan bir kuralı hacmin onda birinde keşfetmek daha ucuzdur.
Pratik çalışma sayfası: Sipariş yönetim sistemi
Sipariş yönetim sistemini tanımlayan şey, yolunda gitmeyen siparişlerde ne yaptığıdır. Bu satırları ideal akıştan değil, geçen ayın istisnalarından doldurun.
| Karar alanı | Kaydedilecek bilgi |
|---|---|
| Sipariş girişi | Siparişin gelebileceği her kanal ve bunlardan hangilerinin diğerlerinin geçtiği kontrolleri atladığı |
| Karşılama | Stoğun siparişe hangi anda bağlandığı ve iki sipariş son ürünü istediğinde ne olduğu |
| İstisnalar | En sık ters giden beş durum, her birini kimin fark ettiği ve fark etmesinin ne kadar sürdüğü |
| İadeler | İadenin nasıl onaylandığı, ürünün nereye gittiği ve para iadesinin ürünün varışına göre ne zaman yapıldığı |
| Ölçüm | İnsan müdahalesi olmadan tamamlanan sipariş oranı; kuralların doğru yazılıp yazılmadığının dürüst ölçüsü budur |
Devreye aldıktan sonra izlenecek rakam müdahale oranıdır. Siparişlerin üçte birine hâlâ birinin dokunması gerekiyorsa sistemdeki kurallar işletmeye uymuyordur ve ekran eklemek bu farkı kapatmaz.
İlgili rehberler
- Karar vermeden önce okunacak yazı: Özel Yönetim Panosu Geliştirme: Metrikten Aksiyona.
- Aynı ödünleşmenin diğer tarafı için: Operasyonel Dashboard: KPI'lar, Örnekler ve Tasarım.
Sipariş Yönetim Sistemi: Süreç, Özellikler ve KPI'lar ekibinizin uzun süredir istediği operasyon araçlarına yol açıyorsa Operasyon Platformunuzu Konuşalım.
Ali Boran Gazel