Otomasyonun getirisi nasıl hesaplanır
Karar duygusal değil aritmetiktir. Bir sürecin otomasyona değip değmediği üç değişkene bakar:
yıllık kazanç = (işlem sayısı × işlem süresi × saatlik maliyet)
+ (önlenen hata sayısı × hata başına maliyet)
örnek — stok güncelleme:
günde 3 kez × 20 dk × 250 ₺/saat × 300 gün = 75.000 ₺/yıl
önlenen stoksuz satış: ayda 6 × 400 ₺ × 12 = 28.800 ₺/yıl
toplam kazanç ≈ 103.800 ₺/yıl
kurulum + yıllık bakım 40.000 ₺ ise → açık ara değer
Aynı hesabı, ayda üç kez yapılan bir işlem için yaptığınızda sonuç genellikle tersine döner. Bu yüzden otomasyon listesi sıklığa göre sıralanmalıdır, önemine göre değil.
Öncelik sırası: sıklık × hata maliyeti
| Süreç | Sıklık | Hata maliyeti | Öncelik |
|---|---|---|---|
| Stok senkronizasyonu | Sürekli | Çok yüksek (stoksuz satış, puan) | 1 — ilk sırada |
| Sipariş aktarımı | Sürekli | Yüksek (termin kaybı) | 2 |
| Fiyat güncelleme | Günlük | Orta-yüksek (marj) | 3 |
| Kargo etiketi / takip | Sürekli | Orta | 4 |
| Fatura kesimi | Sürekli | Orta (mevzuat) | 5 |
| Ürün açma / katalog | Haftalık | Düşük-orta | 6 |
| Raporlama | Haftalık | Düşük | 7 — en sona |
Raporlamanın en sonda olması şaşırtıcı gelebilir. Sebebi şu: rapor otomasyonu zaman kazandırır ama hata önlemez. Stok senkronizasyonu ise her iki tarafta da kazandırır.
Otomatikleştirilmemesi gereken işler
- Fiyat kararı. Fiyat izleme otomatik olabilir; fiyat kararı tabanı olmadan otomatikleştirilirse dip fiyat sarmalına girilir.
- Olumsuz yorum cevabı. Şablon cevaplar ilgisizlik olarak okunur ve zarar verir.
- Ürün açıklaması üretimi. Otomatik üretilen açıklamalar ürünün gerçek ölçü ve malzeme bilgisini içermediği için iadeyi artırır.
- Kampanya katılım kararı. Marj hesabı gerektirir; otomatik katılım en hızlı marj eritme yöntemidir.
Entegrasyon kesintisi: kaçınılmaz, ama yönetilebilir
Her entegrasyon eninde sonunda kesilir: API değişikliği, kota aşımı, ağ sorunu. Sorun kesintinin kendisi değil, kesintinin fark edilmemesidir. Sessizce duran bir stok senkronizasyonu, saatler içinde onlarca stoksuz satış üretir.
- Ölü adam düğmesi kurun. Senkronizasyon X dakikadır çalışmadıysa uyarı gitsin.
- Kritik ürünlerde tampon bırakın. Çok satan üründe birkaç adetlik pay, kesinti anında koruma sağlar.
- Son işlem zamanını görünür yapın. Panelde "son güncelleme: 14:32" gibi bir bilgi, sorunu dakikalar içinde fark ettirir.
- Manuel geri dönüş planı yazın. Kesinti uzarsa hangi süreç nasıl elle yürütülecek?
Entegrasyonun "çalışıyor görünüp" yanlış veri yazması, hiç çalışmamasından daha pahalıdır. Bu yüzden yalnızca çalışıp çalışmadığını değil, yazdığı verinin doğruluğunu da örnekleme ile kontrol eden bir denetim gerekir.
Hazır entegrasyon mu, kendi geliştirmeniz mi
| Ölçüt | Hazır çözüm | Kendi geliştirme |
|---|---|---|
| Kurulum süresi | Günler | Haftalar-aylar |
| Başlangıç maliyeti | Düşük | Yüksek |
| Süreklilik maliyeti | Abonelik | Bakım ve geliştirici |
| Esneklik | Sınırlı | Tam |
| API değişikliğine uyum | Sağlayıcı halleder | Sizin sorumluluğunuz |
| Uygun olduğu durum | Standart süreçler, orta ölçek | Sıra dışı iş kuralları, büyük ölçek |
Çoğu mağaza için doğru cevap hazır çözümdür. Kendi geliştirme, ancak standart çözümlerin karşılayamadığı gerçek bir iş kuralı varsa ve bu kural ölçülebilir para üretiyorsa mantıklıdır. "Bize özel olsun" isteği, çoğu zaman ödediğinden az değer üretir.