SAP ile elektronik raf etiketi entegrasyonu

SAP kullanan bir perakendecide elektronik raf etiketi projesi, teknik olarak en öngörülebilir entegrasyonlardan biri. Standart arayüzler var, veri modeli belgelenmiş, kurumsal ölçekte benzer akışlar defalarca kurulmuş.

Buna rağmen bu projeler genellikle en uzun sürenler oluyor. Sebebi kod değil, süreç.

Zorluk teknikte değil yönetişimde

Küçük bir işletmede entegrasyon kararını bir kişi verir. SAP kullanan bir kurumda aynı karar en az üç birimi ilgilendiriyor: ERP tarafı, perakende operasyonu ve bilgi güvenliği.

Bunun projeye etkisi doğrudan takvim olarak çıkıyor. Bağlantının kurulması birkaç gün sürebilir; o bağlantının onaylanması, test ortamında doğrulanması ve canlıya alınması haftalar alabilir.

Pratik sonuç: SAP projelerinde entegrasyonu erken başlatmak, donanım tedarikinden bile önce gelen bir iş. Takvimi ERP tarafındaki değişiklik penceresi belirliyor.

Standart arayüz, özel alan

SAP tarafında etiketin ihtiyaç duyduğu veriyi dışarı almak için yerleşik yöntemler bulunuyor. İşin zor kısmı hangi verinin çıkacağına karar vermek.

Kurumsal kurulumlarda fiyat tek bir alan değil: liste fiyatı, kampanya koşulu, mağaza grubu fiyatı, dönemsel indirim ayrı ayrı tutulabiliyor. Rafta hangisinin görüneceği ticari bir karar ve entegrasyondan önce verilmesi gerekiyor.

Bu karar mevzuatla da kesişiyor: indirimli satışta "önceki fiyat" gösterimi belirli bir yönteme bağlı. İndirimli satışta etiket kuralları hesabı, mevzuat uyum denetçisi de şablonun gerekli alanları taşıyıp taşımadığını gösteriyor.

Test ortamı pazarlık konusu değil

Kurumsal kurulumlarda canlı sistem üzerinde deneme yapılmaz — bu zaten kurum politikasıdır. ESL projesinde de aynı disiplin geçerli olmalı.

Doğrulanacak üç şey var ve üçü de gözle kontrol edilebilir: etiketteki ad rafta okunuyor mu, birim fiyat gereken üründe çıkıyor mu, kategori doğru şablonu seçiyor mu. Şablon simülatörü bunu gerçek veriyle, gerçek ekran ölçüsünde yapıyor.

Test kümesinin gerçek alan yapısını taşıması önemli. Temizlenmiş örnek veriyle yapılan test, canlıdaki eksik alanları göstermez.

Çok ülkeli kurulumlarda ek katman

SAP kullanan perakendecilerin bir kısmı birden çok ülkede faaliyet gösteriyor. Bu, etiket tarafına iki ek gereksinim getiriyor.

Zorunlu alanlar ülkeye göre değişiyor. Türkiye'de etiket bilgilerinin Türkçe olması ve fiyatın Türk lirası cinsinden gösterilmesi zorunlu; ikinci dil ve para birimi ancak ek olarak yer alabiliyor. Etikette Türkçe zorunluluğu ve çoklu dil ve para birimi yazıları bu sınırları çiziyor.

Şablon kümesi çoğalıyor. Her ülke için ayrı şablon tutmak bakım yükünü doğrusal büyütüyor. Şablon yönetimi yazısı bu sayıyı düşük tutmanın yolunu anlatıyor.

Hangi alanlar gerekiyor?

Asgari küme ölçekten bağımsız aynı: ürün kodu veya barkod, rafta okunur gösterim adı, satış fiyatı, net miktar ve birim, kategori, KDV oranı.

SAP kurulumlarında bu alanlar genellikle dolu. Buna karşılık gösterim adı sorun çıkarıyor: kurumsal ürün adı lojistik ve satın alma için yapılandırılmıştır ve rafta okunmaz. Ayrı bir gösterim adı alanı açılması gerekiyor — ve bu, ERP tarafında bir değişiklik talebi demek, yani yine süreç.

Mevcut durumu ERP veri hazırlık denetçisiyle ölçmek entegrasyondan önce yapılacak iş. Veri kalitesi yazısı bu kalemin neden en çok geciktiren kalem olduğunu anlatıyor.

Güvenlik tarafı erken masaya gelsin

Bilgi güvenliği birimi projeye geç dahil olduğunda, kurulmuş bir bağlantı sökülebiliyor. Erken sorulacak sorular belli: veri hangi yöne akıyor, hangi hesapla okunuyor, yönetim arayüzü nereden erişilebilir, günlük kaydı tutuluyor mu.

ESL sistemi güvenli mi yazısı bu soruların tamamını ve sözleşmeye yazılacak karşılıklarını veriyor.

Pilot mağaza, kurumsal projede daha da gerekli

Kurumsal ölçekte "önce bir mağazada deneyelim" yaklaşımı kolayca atlanıyor: bütçe onaylanmış, takvim çıkarılmış, doğrudan yaygınlaştırma planlanmış oluyor.

Oysa SAP tarafındaki alan eşleştirmesinin gerçek raf koşullarında doğrulanması, ancak canlı bir mağazada mümkün. Test ortamında doğru görünen bir gösterim adı, rafta uzaktan okunmayabiliyor; kategori eşleşmesi doğru çalışsa bile şablon seçimi beklenmedik bir sonuç verebiliyor.

Pilot ayrıca ikinci bir işi görüyor: ölçüm zemini kuruyor. Fiyat değişikliğinin rafa yansıma süresi, personelin harcadığı zaman ve yanlış fiyat sayısı pilot mağazada ölçülürse, yaygınlaştırma kararı tahminle değil veriyle veriliyor. Pilot kurulumdan yaygınlaştırmaya yazısı bu ölçümün nasıl kurulacağını anlatıyor.

Kurumsal projelerde pilotun bir faydası daha var: iç bütçe savunmasını kolaylaştırıyor. Yaygınlaştırma bütçesi, tahmini kazanç yerine ölçülmüş kazançla istenebiliyor.

Sözleşmeye yazılacaklar

Kurumsal projelerde beş madde takvimi belirliyor: hangi SAP sürümü ve hangi modül, veri hangi arayüzle çıkacak, rafta hangi fiyat gösterilecek, test ortamı kim tarafından sağlanacak, ve değişiklik penceresi ne zaman.

Son madde çoğu projede hiç yazılmıyor ve teslim tarihini tek başına belirleyen şey oluyor.

Şartname üreteci bu maddeleri kapsamınıza göre üretiyor. Uygun çözümü birlikte belirlemek için ihtiyaç analiziyle başlayıp teklif isteyebilirsiniz.