ESL'de toplu şablon değişikliği

Şablon değişikliği, ESL operasyonunun en yüksek kaldıraçlı işlemidir: tek bir düzenleme binlerce etikete aynı anda uygulanır. Bu, hem en büyük kolaylık hem de en büyük risktir.

Ne zaman şablon değişir?

Şablon revizyonunu tetikleyen dört durum:

1. Mevzuat değişikliği. Yeni bir zorunlu alan ya da gösterim kuralı.
2. Marka/kurumsal kimlik güncellemesi. Yazı tipi, düzen, logo.
3. Operasyonel ihtiyaç. Ürün adları sığmıyor, birim fiyat okunmuyor.
4. Yeni kampanya türü. Mevcut şablonun karşılamadığı bir düzen.

Birincisi acil ve zorunludur; diğerleri planlanabilir.

Değişiklik öncesi üç test

1. Uç durum testi

Ortalama ürünle yapılan test yanıltır. Test edilecekler:

• En uzun ürün adı. Katalogdaki en uzun ad.
• En yüksek birim fiyat. Beş haneli değerler (birim fiyat hesabında yuvarlama kuralları).
• En çok zorunlu alan gerektiren ürün. Menşe, alerjen, üretim yöntemi birlikte.
• İndirimli ürün. Eski/yeni fiyat, oran, süre bir arada.

Şablon simülatörü bu testleri tarayıcıda yapmanızı sağlıyor.

2. Gerçek ekran testi

Simülatör ve editör önizlemesi, gerçek e-kâğıt ekranın birebir karşılığı değildir. Kontrast, çizgi kalınlığı ve punto, gerçek ekranda farklı görünebilir.

Değişiklik, önce birkaç test etiketine uygulanıp rafta gözle kontrol edilmelidir.

3. Okunabilirlik testi

Test etiketini rafa takın, mağazanın en loş koridorunda iki metreden bakın. Fiyat okunuyor mu (fiyat etiketinde yazı boyutu kuralları)?

Kademeli yayma

Testler geçilse bile tam yayma tek seferde yapılmamalıdır:

1. Pilot grup (20–50 etiket). Farklı kategorilerden.
2. Bekleme (1–3 gün). Personel ve müşteri geri bildirimi.
3. Bir kategori (%10–20).
4. Tam yayma.

Bu sıra, ESL firmware güncellemesi yazısındaki yayma mantığıyla aynıdır ve aynı sebebe dayanır: geri dönüşü zor bir işlemi küçük adımlarla yapmak.

Geri alma planı

Değişiklik uygulandıktan sonra bir sorun görülürse ne olacak? İki soru:

• Sistem önceki şablon sürümünü saklıyor mu?
• Tek bir işlemle geri dönülebiliyor mu?

Sürüm saklama yoksa, eski şablonun bir kopyası değişiklik öncesinde elle alınmalıdır. Bu, beş dakikalık bir iştir ve bir kez işe yaradığında kendini fazlasıyla öder (ESL'de yedekleme ve felaket kurtarma).

Zamanlama

Toplu şablon değişikliği, bir toplu güncelleme demektir: binlerce etiket yeniden basılır. Bunun iki sonucu vardır.

Pil. Her etiket bir yenileme harcar. Yılda birkaç şablon revizyonu, pil ömrünü hesaba katılması gereken ölçüde etkiler (pil ömrü simülatörü).

Süre. Güncelleme kuyruğu dolar; normal fiyat değişiklikleri gecikir.

Bu yüzden şablon değişikliği kampanya günlerinden uzak ve tercihen mağaza kapalıyken yapılmalıdır (kampanya günü toplu güncelleme).

Kim yapmalı?

Şablon yetkisinin içeride olması, her kampanyada tedarikçiye bağımlı kalmamayı sağlar. Ama yetki dar tutulmalıdır: şablon düzenleyebilen kişi sayısı az olmalı ve değişiklikler kayıt altına alınmalıdır.

Pratik bir ayrım: kategori sorumlusu şablon içeriğini (hangi alan gösterilsin) belirler, sistem yöneticisi uygular. Bu, hem uzmanlığı hem kontrolü korur (şablon yönetimi, yetkilendirme).

Zincirde ek katman

Çok mağazalı yapıda şablon merkezden yönetilmelidir; her mağazanın kendi şablonunu düzenlemesi, kısa sürede yüzlerce farklı düzen üretir.

Merkezi şablon yönetiminin gerçekten çalıştığı demo sırasında sınanmalıdır: tek bir değişiklik, üç mağazada birden görünüyor mu (zincir markette ESL)?

Değişiklik sonrası doğrulama

Yayma bittikten sonra üç kontrol:

1. Güncellenemeyen etiket raporu — kaç etiket yeni şablonu alamadı?
2. Rastgele 20 etikette gözle kontrol.
3. Şablon belgesinin güncellenmesi (denetim için) (denetimde istenecek ESL kayıtları).

Üçüncüsü en çok atlanan adımdır ve denetim geldiğinde eksikliği hissedilir.

Şablon sürümleri ve kayıt

Her şablon değişikliği kayıt altına alınmalıdır: ne zaman, kim tarafından, ne değişti. Bu kayıt üç işe yarar.

Denetim. Şablonun hangi tarihte hangi hâlde olduğunu belgeler (denetimde istenecek ESL kayıtları).

Geri dönüş. Bir sorun çıktığında hangi değişikliğin sebep olduğu bulunur.

Bilgi aktarımı. Şablonu tasarlayan kişi ayrıldığında, kararların gerekçesi kayıtta kalır.

Sistem sürüm kaydı tutmuyorsa, basit bir dosyada elle tutulmalıdır: tarih, değişiklik, gerekçe.

Kategori bazında ayrı şablonlar

Tek bir şablonu bütün kategorilere uydurmaya çalışmak, her kategoride taviz demektir. Doğru yaklaşım, kategori grupları için ayrı şablonlar tanımlamaktır: ambalajlı gıda, tartılı ürün, tekstil, elektronik.

Ama sayı kontrol altında tutulmalıdır. Kırk şablonlu bir kurulum teknik olarak mümkün, operasyonel olarak yönetilemezdir: bir mevzuat değişikliği kırk yerde birden düzeltme gerektirir.

Pratik aralık altı ila on iki şablondur (şablon yönetimi).

Değişikliği duyurmak

Şablon değiştiğinde mağaza ekibi haberdar edilmelidir. Aksi hâlde "etiketler değişmiş, bir sorun mu var?" soruları destek kuyruğuna düşer.

Bir cümlelik bir duyuru yeterlidir: ne değişti, neden, ne zaman. Bu, ESL'ye geçiş sonrası ilk 90 gün yazısındaki güven kurma mantığının devamıdır.