Tekstilde veri modelini zorlayan şey
Zorlayan şey varyant patlamasıdır: tek bir model, renk × beden matrisiyle yüzlerce stok kaydına dönüşür. Bu varyantlar ayrı ürün kartları olarak açıldığında sipariş, üretim ve stok raporları model seviyesinde okunamaz hâle gelir. Doğru model, ana ürün (model) altında varyant hiyerarşisi kurmaktır.
Kritik süreçler
- Renk/beden matrisi: Model altında varyant yönetimi; sipariş, üretim ve sevkiyatın hem model hem varyant seviyesinde raporlanması.
- Koleksiyon ve sezon: Model yaşam döngüsü, sezon bazlı fiyat ve indirim planı.
- Numune süreci: Numune talebi, revizyon turları, müşteri onayı ve onaylı numunenin üretim referansı olması.
- Fason takibi: Kesim, dikim, yıkama, baskı ve nakış gibi dışarı verilen operasyonlar; gönderilen/dönen miktar ve fire.
- Kumaş metrajı: Model başına teorik tüketim, pastal planı, gerçekleşen tüketim ve fark analizi.
- Kalite ve ikinci kalite: Ayıplı ürünün ayrı stok olarak yönetilmesi.
Hangi çözüm neye karşılık geliyor?
Model/varyant, ürün ağacı, fason ve maliyet [ERP danışmanlığı ve geliştirme](/cozumler/erp-danismanligi) kapsamındadır. Bayi ve toptan satış kanalı için [B2B bayi portalı](/urunler/bayi-portal), kendi mağazaları için [perakende POS](/urunler/perakende-pos), online kanal için [e-ticaret yazılımı](/urunler/e-ticaret), atölye terminalleri için [mobil uygulama geliştirme](/cozumler/mobil-uygulama-gelistirme) kullanılır.
Zorunlu entegrasyonlar
Kesim ve dikimhane terminalleri, barkod ve etiket yazıcıları, e-fatura ve e-irsaliye, pazaryeri kanalları, kargo firmaları, banka hesap hareketi ve muhasebe.
Nereden başlıyoruz?
Tekstil ve konfeksiyonda başlangıç durumu genellikle bir varyant patlamasıdır: aynı model 8 renk × 6 beden ile 48 satıra dönüşür ve bu satırlar stok programında ayrı ürün olarak açılır. Model bazında raporlama yapılamaz, koleksiyon performansı görülemez.
İlk çalışmanın çıktısı model–varyant hiyerarşisidir: model bir üst kayıt, renk ve beden ise onun boyutlarıdır. Bu hiyerarşi kurulduğunda hem sipariş girişi hem raporlama tek satırdan yönetilir; kurulmadığında her yeni sezon veri tabanını büyütür ama görünürlük artmaz.
Veri modelinde net olması gerekenler
- Model ve varyant: Model kodu üst kayıt; renk, beden ve varsa desen boyut olarak. Barkod varyant düzeyinde üretilir.
- Beden serisi: Müşteriye veya pazara göre değişen seri tanımları (örneğin S-M-L ile 36-38-40 aynı üründe).
- Koleksiyon ve sezon: Model kaydına bağlı sezon, koleksiyon ve satış dönemi.
- Fason operasyon: Kesim, dikim, yıkama, ütü gibi adımların dışarıda yapılan kısımları; gönderilen/dönen adet ve fire.
- Kumaş tüketimi: Model başına teorik tüketim (pastal) ile gerçekleşen tüketim farkı.
- Kalite ayrımı: Birinci kalite, ikinci kalite ve defolu stoğun ayrı tutulması.
Devreye alma sırası
1. Model yapısı: Model–varyant hiyerarşisi, beden serileri, barkod mantığı.
2. Üretim ve fason: İş emri, fason gönderim/dönüş, kumaş tüketimi ve fire kaydı.
3. Satış kanalları: Toptan sipariş, [B2B portal](/urunler/bayi-portal), mağaza ve online kanal stok senkronu.
4. Maliyet ve koleksiyon analizi: Model bazlı gerçekleşen maliyet, sezon sonu satış performansı.
Neyi ölçüyoruz?
- Beden ve renk kırılımında satış dağılımı (üretim serisinin talebe uyumu)
- Teorik kumaş tüketimi ile gerçekleşen tüketim farkı
- Fasona giden ve dönen adet farkı, fason bazlı fire oranı
- Sezon sonunda kalan stoğun model ve varyant dağılımı
- İkinci kalite ve defolu ürün oranı
Sık yapılan hatalar
- Varyantları ayrı ürün olarak açmak. Model bazlı analiz imkânsız hâle gelir, ürün listesi yönetilemez büyür.
- Beden serisini tek bir standarda zorlamak. Farklı pazarlar farklı seri kullanır; tek seri, siparişte elle dönüşüm demektir.
- Fason fireyi genel fireye yazmak. Hangi fasonun ne kadar fire ürettiği görünmez.
- İkinci kaliteyi aynı stok kaydında tutmak. Satılabilir stok olduğundan yüksek görünür.
Sık sorulan sorular
Varyantlar ayrı ürün kartı olarak mı açılmalı?
Hayır. Model ana kayıt, renk/beden varyant olmalıdır. Ayrı kart yapısında koleksiyon performansı, model bazlı satış ve toplam sipariş takibi elle birleştirme gerektirir.
Fason operasyonlarında fire nasıl izlenir?
Gönderilen ve dönen miktar ayrı kaydedilmeli, aradaki fark sözleşmedeki fire toleransıyla karşılaştırılmalıdır. Tolerans sistemde tanımlanmazsa her fason hesabı elle kapatılır.
Pastal planı ERP'ye bağlanabilir mi?
Pastal yazılımı genellikle ayrı çalışır; bağlantı, teorik tüketim değerinin ERP'ye aktarılması ve gerçekleşenle karşılaştırılması şeklinde kurulur. Bu karşılaştırma yapılmadığında kumaş fire oranı ölçülemez.
Barkod model düzeyinde mi varyant düzeyinde mi olmalı?
Varyant düzeyinde. Aynı barkodun farklı beden veya renkte kullanılması, mağaza satışında ve sayımda ayrıştırılamayan fark üretir. Model kodu ayrı bir alan olarak tutulur ve raporlama bu alan üzerinden yapılır.
Sezon sonu kalan stok nasıl değerlendirilir?
Kalan stoğun model, renk ve beden kırılımında görülmesi gerekir; toplam adet karar üretmez. Outlet, indirim veya paket satış kararı bu kırılım üzerine kurulur. Sistemde "sezon" alanı model kaydına bağlı değilse bu analiz her seferinde elle yapılır.
Fason takibi için ayrı bir portal gerekir mi?
Gerekmez, ancak fason sayısı arttıkça e-posta ve telefon takibi bekleme süresini artırır. [B2B portal](/urunler/bayi-portal) altyapısı, fason firmalara gönderim/dönüş bildirimi yaptırmak için de kullanılabilir; kritik olan, bildirimin iş emri adımıyla eşleşmesidir.