Otomasyon Kurulduktan Sonra Hangi Sayıları İzlemeli Ve Bozulduğunu Nereden Anlarsınız

Otomasyonun sağlığı tek bir sayıyla ölçülmez. En az dört şeyi izleyin: kaç sipariş insan müdahalesi olmadan tamamlandı, istisna kuyruğuna kaç kayıt düştü, bir istisnanın çözülmesi ne kadar sürdü ve hata hangi adımda yakalandı. Bu dördü birlikte bozulmaya başladığında sorun kuralda değil, kuralın dayandığı veridedir.

• Tek metrik yanıltır: dokunulmadan tamamlanan sipariş oranı tek başına yükselirken kalite düşüyor olabilir.
• İstisna kuyruğunun boyu değil, boyunun değişim yönü ve kuyrukta bekleme süresi bilgi verir.
• Hatanın yakalandığı adım geriye kaydıkça düzeltme maliyeti artar, bu yüzden yakalama noktası izlenmelidir.
• Otomasyon genellikle bir anda değil, veri kaynakları sessizce değiştiği için yavaş yavaş bozulur.
• Her kural değişikliği tarih ve gerekçeyle kaydedilmezse bozulmanın başlangıcı bulunamaz.

Otomasyonun Sağlıklı Çalıştığını Hangi Sayı Gösterir?

Tek bir sayı yeterli değildir; dokunulmadan tamamlanan sipariş oranı, istisna sayısı, çözüm süresi ve hatanın yakalandığı adım birlikte okunur.

Otomasyon kurulduktan sonra sorulan ilk soru genellikle şudur: işe yarıyor mu. Bu sorunun tek sayılık bir cevabı yok, çünkü tek sayı optimize edilebilir bir hedefe dönüşür ve optimize edilen hedef kısa sürede anlamını kaybeder. Birinci sayı, insan müdahalesi olmadan tamamlanan sipariş oranıdır. Bir siparişin baştan sona hiçbir alanına dokunulmadan çıkması, kuralların gerçekten çalıştığını gösterir. Bu oranı kendi tarihinize göre okuyun. Başka bir şirketin oranıyla karşılaştırmanın anlamı yok, çünkü katalog yapısı ve kanal karması oranı doğrudan belirler. İkinci sayı, istisna kuyruğuna düşen kayıt sayısıdır. Bu sayının sıfıra yaklaşması iyi haber değildir. Sıfıra yakın bir kuyruk çoğu zaman kuralların yeterince sıkı olmadığını, yani hatalı kayıtların da geçtiğini gösterir. Sağlıklı bir operasyonda kuyruk hep biraz doludur. Üçüncü sayı, bir istisnanın çözülme süresidir. Kuyruğa düşen kayıt hızlı çözülmüyorsa otomasyon iş yükünü azaltmamış, sadece yerini değiştirmiştir. Bu süreyi ortalamayla değil, en uzun bekleyen kayıtlarla izleyin. Ortalama, kuyruğun dibinde unutulan kayıtları saklar. Dördüncü sayı, hatanın hangi adımda yakalandığıdır. Her düzeltilen hata için iki bilgi kaydedin: veri nerede oluştu, hata nerede fark edildi. Yakalama noktası sipariş anına yakınsa sistem işini yapıyordur. Yakalama noktası son mile, iadeye veya müşteri şikayetine kaymışsa kontroller geriden geliyordur. Bu dört sayıyı birlikte okumak gerekir, çünkü ayrı ayrı hepsi yanıltabilir. Dokunulmadan tamamlanan sipariş oranı yükselirken müşteri şikayeti de yükseliyorsa, sistem daha fazla kaydı geçiriyor ama daha az kontrol ediyor demektir. Kuyruk kısalırken çözüm süresi uzuyorsa, kolay istisnalar çözülüp zorlar birikiyordur. Sayıları haftalık olarak aynı gün ve aynı yöntemle çıkarın. Yöntem değişirse eski hafta ile yeni hafta karşılaştırılamaz hale gelir ve bir bozulmayı mı yoksa ölçüm değişikliğini mi gördüğünüzü ayırt edemezsiniz. Ölçüm yöntemini de kural gibi sürümleyin.

İstisna Kuyruğu Neyi Anlatır ve Nasıl Okunur?

Kuyruğun uzunluğundan çok bileşimi bilgi verir: hangi kural, hangi ürün ailesi ve hangi kanal kuyruğu besliyor.

İstisna kuyruğu otomasyonun en dürüst göstergesidir, çünkü sistemin çözemediği her şeyi tek bir yerde toplar. Ancak kuyruğu yalnızca uzunluğuyla okumak bilgi kaybettirir. Kuyruğu üç eksende ayırın. Birincisi tetikleyen kural: hangi kontrol kaydı durdurdu. İkincisi ürün ailesi: kuyruk belirli bir kategoride mi yoğunlaşıyor. Üçüncüsü kaynak: hangi kanaldan veya hangi tedarikçiden gelen kayıtlar durduruluyor. Bu üç kırılım genellikle sorunun yerini doğrudan gösterir. Tek bir kuralın kuyruğun büyük bölümünü üretmesi tipik bir durumdur ve iki anlama gelebilir. Ya kural fazla sıkıdır ve düzgün kayıtları da durduruyordur, ya da o kuralın kontrol ettiği alanda gerçek bir veri sorunu vardır. Ayrımı yapmak için kuyruktaki kayıtların ne kadarının değişiklik yapılmadan onaylandığına bakın. Çoğu dokunulmadan onaylanıyorsa kural fazla sıkıdır. Belirli bir ürün ailesinde yoğunlaşma genellikle katalog kaynaklıdır: eksik özellik bilgisi, hatalı birim, tanımsız varyant. Burada çözüm kuralı gevşetmek değil, katalogdaki eksiği tamamlamaktır. Kuralı gevşetmek belirtiyi kapatır, sorunu operasyonun ilerisine taşır. Belirli bir kaynakta yoğunlaşma ise dış bir değişikliğe işaret eder. Bir kanal alan yapısını güncellemiş, bir tedarikçi dosya biçimini değiştirmiş olabilir. Bu tür değişiklikler size haber verilmeden olur ve ilk belirtileri kuyrukta görünür. Kuyrukta bekleyen kayıtların yaşını da izleyin. En eski kaydın kaç gündür beklediği, ortalama süreden daha çok şey anlatır. Kuyrukta günlerce bekleyen kayıtlar varsa ya sahibi belirsizdir ya da çözümü kimsenin yetkisi dahilinde değildir. İkisi de yapısal sorundur ve daha fazla kural yazarak çözülmez. Son olarak kuyruktan çıkış biçimini kaydedin. Kayıt düzeltilerek mi onaylandı, olduğu gibi mi geçirildi, iptal mi edildi. Olduğu gibi geçirilen kayıtların oranı yükseliyorsa kuyruk bir kontrol noktası olmaktan çıkıp formaliteye dönüşmüştür. Bu, otomasyonun sessizce bozulduğunu gösteren en erken işaretlerden biridir.

Bozulma Neden Yavaş Yavaş Başlar?

Kurallar sabit kalırken besledikleri veri değiştiği için bozulma bir anda değil, fark edilmeyecek kadar küçük adımlarla ilerler.

Otomasyon nadiren bir günde bozulur. Bozulma, kuralların değişmediği ama dünyanın değiştiği süreçte birikir. En sık görülen kaynak katalog değişikliğidir. Yeni varyantlar eklenir, ürün adları güncellenir, tedarikçi bir bileşeni değiştirir. Kural aynı kalmıştır ama kontrol ettiği veri artık aynı anlama gelmemektedir. Kimse bir şeyi bozmamıştır, yine de sonuç bozulur. İkinci kaynak dış biçim değişiklikleridir. Bir kanal alan adını değiştirir, bir dosya sütun ekler, bir entegrasyon yanıt yapısını günceller. Bu değişiklikler genellikle önceden duyurulmaz ve etkisi tek bir alanla sınırlı kalmaz. Üçüncü kaynak insan alışkanlığıdır. Ekip kuyruğu boşaltmak için hızlanır, benzer görünen kayıtları toplu onaylar, aynı istisnayı her hafta aynı şekilde geçer. Kural kağıt üzerinde hala oradadır, uygulamada aşınmıştır. Dördüncü kaynak istisnaya istisna eklenmesidir. Bir müşteri için yazılan özel kural, sonra bir kampanya için yazılan bir başkası, derken kural setinin kendisi kimsenin baştan sona okuyamadığı bir yapıya dönüşür. Bu noktada yeni bir kural eklemek eskilerinden birini sessizce etkisiz bırakabilir. Bu dört kaynağın ortak özelliği, hiçbirinin alarm üretmemesidir. Bu yüzden bozulmayı yakalamanın yolu alarm beklemek değil, düzenli olarak bakmaktır. İki alışkanlık işe yarıyor. Birincisi örnekleme: her hafta az sayıda tamamlanmış siparişi rastgele seçin ve biçim olarak değil anlam olarak okuyun. Adres gerçekten doğru mu, ürün tanımı ürünü anlatıyor mu, adet mantıklı mı. Bu kontrol hiçbir kuralın yakalayamadığı hata sınıfını yakalar ve işler yoğunlaştığında ilk terk edilen şey olur. İkincisi kural envanteri: çeyrekte bir kural listesini baştan sona okuyun ve her kuralın hala gerekli olup olmadığını sorun. Gereksiz kurallar kuyruğu şişirir, gereksiz kuyruk dikkati dağıtır, dağılan dikkat gerçek istisnaları gözden kaçırır. Bir de tedarikçi ve kanal tarafından gelen değişiklikler için bir bildirim yolu kurun. Sizi haberdar etmeyen bir değişikliği ancak sonuçlarından fark edersiniz ve sonuçlar her zaman daha pahalıdır.

Hangi Eşikler Uyarı Üretmeli?

Eşikler mutlak sayılara değil, kendi geçmişinize göre değişim yönüne ve hızına bağlanmalıdır.

Uyarı kurmanın en yaygın hatası mutlak bir sayı seçmektir. Bir eşiği kendi ölçümünüz olmadan belirlediğinizde ya sürekli uyarı alırsınız ve uyarılara bakmayı bırakırsınız, ya da hiç uyarı almazsınız ve sistemin sağlıklı olduğunu sanırsınız. Doğru yaklaşım kendi taban çizginizi çıkarmaktır. Dört sayıyı en az birkaç hafta boyunca ölçün, normal aralığın nerede olduğunu görün ve uyarıyı bu aralıktan sapmaya bağlayın. Sapmanın büyüklüğü kadar yönü de önemlidir: bir sayının hızla iyileşmesi de incelenmeye değer, çünkü çoğu zaman ölçüm yönteminin değiştiğini gösterir. Hangi olaylara uyarı bağlanmalı? Kuyruğun bileşiminde ani değişiklik, yani daha önce hiç görülmeyen bir kuralın aniden kuyruğu doldurmaya başlaması. Kuyrukta belirli bir yaşı aşan kayıt bulunması. Olduğu gibi geçirilen kayıtların oranındaki artış. Hatanın yakalandığı adımın geriye kayması, örneğin daha önce sipariş anında yakalanan bir hata tipinin artık müşteri şikayetiyle gelmesi. Bir de kural değişikliğinden sonraki ilk günler: her değişiklikten sonra kısa bir gözlem penceresi tanımlayın. Uyarıların bir sahibi olmalı. Kimseye atanmamış uyarı, kimsenin bakmadığı uyarıdır. Her uyarı tipinin yanına kimin bakacağını ve ne kadar sürede döneceğini yazın. Bu süreyi kendi kesim saatlerinize göre belirleyin, başka bir operasyonun rakamını kopyalamayın. Uyarı sayısını da izleyin. Haftada gelen uyarı sayısı sürekli artıyorsa eşikler fazla hassastır ve ekip kısa sürede uyarıları görmezden gelmeye başlar. Uyarı yorgunluğu, hiç uyarı kurmamış olmaktan daha tehlikelidir, çünkü güvenlik hissi verir. Son olarak sayıları tek bir yerde ve aynı biçimde tutun. Dört sayının haftalık değerini gösteren basit bir tablo, karmaşık bir panodan daha çok kullanılır. Kullanılmayan panonun ölçüm değeri yoktur. Tabloyu haftalık toplantının başına koyun ve her hafta aynı iki soruyu sorun: ne değişti, neden değişti.

Sayılar Bozulduğunda Hangi Sırayla Bakmalısınız?

Önce ne değiştiğine, sonra veri kaynağına, sonra kural setine, en son ekip davranışına bakın.

Sayılar bozulduğunda en verimsiz yaklaşım kuralları rastgele gevşetmektir. Belirti kaybolur, sorun operasyonun ilerisine taşınır ve birkaç hafta sonra daha pahalı bir biçimde geri döner. Sıralı bir inceleme daha hızlı sonuç verir. Birinci adım: ne değişti. Kural değişikliklerini, entegrasyon güncellemelerini, katalog yüklemelerini ve ekip değişikliklerini tarihleriyle listeleyin ve bozulmanın başladığı tarihle karşılaştırın. Değişiklikleri gerekçesiyle kaydeden operasyonlarda bu adım dakikalar sürer, kaydetmeyenlerde günler. İkinci adım: veri kaynağı. Kuyruğa düşen kayıtların ham halini açın ve alanların beklenen biçimde gelip gelmediğine bakın. Alan adları, birimler, boş gelen alanlar, kodlama sorunları. Bozulmaların önemli bölümü buradan çıkar ve kuralla ilgisi yoktur. Üçüncü adım: kural seti. Son eklenen kuralların eskileriyle çakışıp çakışmadığını kontrol edin. İki kuralın aynı kaydı farklı yönlere iten bir çift oluşturması, sonucu kuralların çalışma sırasına bağımlı hale getirir ve bu tür sorunlar kesintili görünür. Dördüncü adım: ekip davranışı. Kuyruktan çıkış biçimlerine bakın. Toplu onay artmış mı, aynı kişi aynı istisnayı sürekli aynı şekilde mi geçiyor, çözüm süreleri belirli saatlerde mi kısalıyor. Bu adım suçlu aramak için değil, sürecin ekibe fazla yük bindirdiği yeri bulmak için yapılır. Beşinci adım: düzeltmeyi tek tek uygulayın. Aynı anda üç şeyi değiştirirseniz hangisinin işe yaradığını öğrenemezsiniz. Bir değişiklik yapın, bir gözlem penceresi bekleyin, sonucu kaydedin. İncelemenin sonunda bulguyu yazılı bırakın: ne bozuldu, nereden geldi, ne yapıldı, hangi kontrol bunu bir dahaki sefere daha erken yakalar. Bu kısa not zamanla operasyonun en değerli belgesine dönüşür, çünkü aynı sorunlar farklı kılıklarda geri gelir. Ve unutmayın: otomasyonun amacı hatayı sıfırlamak değil, hatayı doğduğu yere yakın yakalamaktır. İzlediğiniz sayılar da bu mesafeyi ölçtüğü için anlamlıdır.

İzlenecek Sayılar ve Bozulma İşaretleri

BringGo Ship Kendi Süreçlerinde Neyi İzliyor

BringGo Ship olarak ABD'den Meksika'ya giden gönderilerde kural dışına çıkan kayıtları ayrı bir listede tutuyor ve bu listenin neden büyüdüğünü haftalık olarak konuşuyoruz. Laredo ve Monterrey depolarımız tek bir kayıt üzerinden çalıştığı için bir hatanın hangi adımda doğduğunu ve hangi adımda yakalandığını geriye dönük görebiliyoruz. Kural değişikliklerini tarihiyle kaydediyoruz, çünkü bir sonuç değiştiğinde ilk sorulacak soru neyin değiştiğidir. Ölçmediğimiz bir oranı size sayı olarak sunmuyoruz; elimizde olan veriyi olduğu gibi paylaşıyor, olmayanı da açıkça söylüyoruz. İngilizce, İspanyolca ve Türkçe destek verdiğimiz için bu görüşmeleri ekibinizin rahat olduğu dilde yapıyoruz.

Tanımlar

• Dokunulmadan tamamlanan sipariş: Hiçbir alanına insan müdahalesi yapılmadan baştan sona işlenip çıkan siparişe verilen addır.
• Taban çizgisi: Bir metriğin kendi operasyonunuzdaki normal aralığını gösteren ve uyarı eşiklerinin dayandırılacağı geçmiş ölçüm setidir.
• Yakalama noktası: Bir hatanın fark edildiği süreç adımıdır ve hatanın doğduğu adıma ne kadar yakınsa düzeltme o kadar ucuzdur.
• Uyarı yorgunluğu: Fazla hassas eşikler yüzünden çok sayıda uyarı üretilmesi ve ekibin uyarılara bakmayı bırakması durumudur.

Sık sorulan sorular

Tek bir metrikle otomasyonu izlemek yeterli değil mi?

Yeterli değil, çünkü tek metrik hedefe dönüşür ve hedefe dönüşen metrik anlamını kaybeder. Dokunulmadan tamamlanan sipariş oranını tek başına takip ederseniz, kontrolleri gevşeterek oranı yükseltmek mümkündür. Dört sayıyı birlikte okumak bu sapmayı engeller.

İstisna kuyruğunun boşalması iyi bir işaret mi?

Genellikle değil. Kuyruğun sıfıra yaklaşması çoğu zaman kuralların gevşediğini ve hatalı kayıtların da geçtiğini gösterir. Sağlıklı bir operasyonda kuyruk sürekli biraz doludur ve içindeki kayıtlar makul sürede çözülür.

Uyarı eşiklerini nasıl belirlemeliyiz?

Mutlak bir sayı seçmeyin. Dört metriği birkaç hafta ölçüp kendi normal aralığınızı çıkarın ve uyarıyı bu aralıktan sapmaya bağlayın. Başka bir operasyonun eşiğini kopyalarsanız ya sürekli uyarı alırsınız ya da hiç almazsınız.

Sayılar bozulduğunda ilk ne yapmalıyız?

Kuralları gevşetmeden önce ne değiştiğine bakın. Kural güncellemelerini, entegrasyon değişikliklerini ve katalog yüklemelerini tarihleriyle karşılaştırın. Bu kayıtlar tutuluyorsa inceleme dakikalar sürer, tutulmuyorsa günler alır.

Ne sıklıkla ölçüm yapmalıyız?

Haftalık ölçüm çoğu operasyon için yeterli ritmi verir, yeter ki her hafta aynı gün ve aynı yöntemle yapılsın. Yöntem değiştiğinde haftalar karşılaştırılamaz hale gelir, bu yüzden ölçüm yöntemini de kurallar gibi sürümleyin.

İlgili Yazılar

• otomasyonda hangi adımlar elde kalmalı
• iade gelen ürünün tekrar satılabilir hale gelmesi
• Meksika gönderim maliyeti kalemleri

Operasyonunuzu tek kayıt üzerinden izlemek için hesap açın

Kaynaklar

• Amazon Seller Central México (sellercentral.amazon.com.mx)
• SAT (Servicio de Administración Tributaria) (sat.gob.mx)

Not: Bu içerik yalnızca bilgilendirme amaçlıdır ve hukuki, mali veya gümrük danışmanlığı değildir. Vergi oranları ve mevzuat 2026'da sık değişebilir; işlem yapmadan önce resmi kaynaktan (SAT, DOF, CBP) veya lisanslı bir gümrük müşavirinden güncel bilgiyi teyit edin.

Hazırlanışı: Bu yazının konusu ve kaynakları BringGo Ship ekibi tarafından belirlenmiştir. Metin yapay zekâ desteğiyle yazılmış, içindeki rakamlar ve mevzuat bilgileri resmî kaynaklarla (DOF, SAT, ANAM, CBP) karşılaştırılarak doğrulanmış ve yayımlanmadan önce ekibimiz tarafından gözden geçirilmiştir.