Ürün kodlaması ile ilgili önceki yazımızda doğru ürün kodlama mimarisinin öneminden bahsetmiş, ayrıca konuşan ve konuşmayan kod sistemlerini karşılaştırmıştık.

Bu yazımızda SKU kodlaması ile ilgili pek sorgulanmayan geleneksel yaklaşımları incelemeye devam edeceğiz. Böylece doğru kodlama mimarisi oluşturmak isteyen mühendis arkadaşlarımıza destek olmaya çalışacağız.

Unutmayın kodlama bir binanın temeline benzer; aslında yapımı zor değildir ama hatalı yapılması durumunda düzeltilmesi ya çok zordur ya da imkânsızdır.

SKU terimi İngilizce “Stock Keeping Unit” teriminin baş harflerinden oluşuyor. Çok kabaca stokta yer işgal eden her türlü parça (item) anlamına geliyor. Yani hammadde, yarı mamul ve mamuller için kullanılan ortak bir terim.

İlginç bir şekilde bu terimin Türkçede birebir karşılığı yok. Bu da hammadde, yarı mamul ve mamul kavramlarının aslında aynı çatı altında olduğunun bilincinin bizde henüz oluşmadığını gösteriyor. Bu yazı biraz da bu eksiklikten dolayı yazılıyor.

SKU kodlama ile ilgili sık karşılaşılan argümanları sizi sıkmadan kısa başlıklar hâlinde ele almaya devam edelim:

• SKU kodlamada Hammaddeler “H” ile Yarı Mamuller “YM” ile Mamuller “M” ile başlasın

Bu argümanı savunanlara “Hammadde”, “Yarı Mamul” ve “Mamul” tanımı nedir diye sorduğumuzda genellikle şu cevapları alırız:

Hammadde, işletme dışından tedarik ettiğimiz her şeydir. Örneğin krank milini (bir traktör imalatçısı için) dışardan alırız.

Yarı mamul, işletme içinde ürettiğimiz fakat henüz son ürün haline gelmemiş tüm SKU’lardır. Örneğin Traktör Motor Kapağı bizim için yarı mamuldür.

Mamul, işletmemizde üretilmiş satılmaya hazır tüm SKU’lardır; örneğin traktörün kendisi.

Bu yaklaşım SKU düzenlemesi yönünde bir çabadır. Fakat gerçekte bir düzen sağlayamadığı gibi hem kod karışıklığına hem de kafa karışıklığına sebep olur. Şöyle ki;

• H ile başlayan krank mili, bir süre sonra işletme içinde üretilmeye başlarsa, yani yarı mamul hâline gelirse ne olacak?
• YM ile başlayan Motor Kapağı işletmede üretilmek yerine dışardan tedarik edilmeye başlarsa, yani hammadde hâline gelirse ne olacak?
• YM ile başlayan Motor Kapağı zaman zaman doğrudan satılırsa (yedek parça gibi) ne olacak
• M ile başlayan traktör bazı müşteriler için fasona gönderiliyor ve camına özel bir film kaplanıyorsa (yani yarı mamul hâline geliyorsa) ne olacak?

Ben bazen bu karşı soruların ortamı gereceğini hisseder ve elden geldiği kadar sessiz kalmayı tercih ederim. Yazmayı tercih etmemin bir sebebi de bu zaten 🙂

Ola ki sormayı başarabilirsek genelde şuna benzer cevapları alırız:

• O zaman yeni duruma göre kodları değiştiriveririz. Yani H ile başlayan eski kodu kaldırır yerine YM ile başlayan yeni kod atarız.

Veya:

• Bu duruma düşen kodlar eski hâliyle kalır. Yani krank mili yarı mamul olduğu hâlde H’li kodla takip edilmeye devam eder (o zaman neden bu zahmete katlandık).

Oysa ERP sistemlerinde kod değiştirmek hiç tercih edilmeyen bir durumdur. Bazı ERP yazılımlarında, altyapı uygun olmadığı için kod değişikliği için oldukça karmaşık bir prosedürü izlemeniz gerekir. Yazılım kod değişikliğine kolayca izin verse bile eski ve yeni kodlar arasında bütünlüğün sağlanması için her zaman ekstra çaba harcamanız gerekecektir.

Arka planda yatan esas soru şudur: Bu ödediğiniz bedelin (kod değişikliği olduğunda harcanan efor) ödülü nedir? Yani H’li, YM’li ve M’li kod yapısı kurarak ne kazandık ki bu bedellere katlanmaya değer olsun?

Maalesef kazancınız yoktur. Ödediğiniz bedel ise gereksiz bir altyapı için katma değeri olmayan sıkıcı bir çalışmadır.

Ziyaret ettiğimiz bir firmada tüm SKU’ların (hammadde, yarı mamul, mamul hepsi) “S” ile başlayan ve devamında nümerik artan kodlar olduğunu gördük.

Yani kodlar S1’den başlayıp S100000000’a kadar artan sırada gidiyordu. Yeni bir SKU numarası atanacağı zaman hammadde, yarı mamul veya mamul olmasına bakılmaksızın S ile başlayan sıradaki kod numarası atanıyordu; mesela S33245 gibi.

Kod konuşmuyordu. Tek standart kodun ilk dijitinin S olması idi, devamı artan sıra numarası şeklindeydi.

Dayanamayıp sorduk: Peki neden “S” ile başlıyor, yani neden doğrudan nümerik parça kodu kullanmadınız? Cevap çok mantıklıydı “Sıfır ile başlayan SKU kodlarımız var, başına bir harf koymadığımızda ERP sistemi bazen şaşırıyor. O yüzden bir karakter seçmemiz gerekiyordu. Biz de “S” seçtik. Özel bir sebebi yok başka bir harf de olabilirdi”.

Bu firma, bu şekildeki kodlama mimarisini yıllardır kullanıyordu ve kodlama kaynaklı hiçbir sorun yaşamadılar.

Kodlarınızı H’li, YM’li veya M’li başlatmayı düşünüyorsanız, “bunu yaptığımda ne fayda sağlayacağım” diye kendinize mutlaka sorun. “Kodlar daha düzgün görünür” veya “canım, herkes öyle yapıyor” gibi cevaplar geçersizdir. Mantıklı bir cevap bulamazsanız (ki ben bulamayacağınızı düşünüyorum :), bu sevdadan vazgeçin.

Not: Zaman zaman yaptığım bir hatırlatmayı burada yinelemek istiyorum. Yazılarımızdaki tezlerle ilgili eksik kaldığımız, gözümüzden kaçan konular olabilir. Böyle bir durumu fark edip bizi uyarırsanız yazılarımızı tekrar gözden geçirir ve gerekli düzeltmeleri yaparız.

Sık karşılaştığımız başka bir argümanla devam edelim:

• Yarı mamul ve hammadde önemli değil fakat mamuller mutlaka konuşan kod olmalı

Mamullerin konuşan kod olması gerektiğini savunan argüman, müşterinin ihtiyacı olan bir ürünü seçerken konuşan kod mimarisinin yardımcı olacağı yönündedir.

Yani müşteri, bir satış temsilcisi ile beraberken veya doğrudan web sitesi üzerinden veya ürün broşürü üzerinden ürünü incelerken istediği karakteristikleri seçtikçe kod yapısı oluşacak ve sipariş vermek daha rahat olacaktır.

Müşterilerin istedikleri ürünü seçerken onlara kullanıcı kolaylığı sağlayacak bir altyapının sağlanması elbette müşteri ile iletişimi güçlendirecek ve ürünün satılma potansiyeline katkıda bulunacaktır.

Bizim cevabını aradığımız soru ise şudur: Müşterilere ürün seçmede kolaylık sağlayan bir altyapı, mutlaka konuşan kod ihtiyacını mı öne çıkarır? Konuşan kod ile müşterilerimize ürün seçiminde kolaylık sağlar mıyız? Yoksa tam tersi onların kafalarını karıştırıp ürün seçimini ve satışını zora mı sokarız?

Basit düşünelim, cep telefonu almak bir portalde arama yapıyor olalım. Almak istediğiniz telefon için bazı kriterleri sisteme girersiniz; kaç kamerası olsun, piksel sayısı, ekran büyüklüğü, pil ömrü, hatta markası ve fiyat aralığı, vs, vs.

Kriterlerin sonucunda ekranda uygun marka modeller görünür ve siz birini seçip alım işlemini tamamlarsınız. Seçtiğiniz model iphone7 veya Samsung Note4 gibi bir marka/modeldir. Farkındaysanız hiçbiri konuşan kod içermiyor. Iphone7 içinde hiçbir anlaşılır kod bulundurmuyor. Sadece bir kod; reklamcılar ve pazarlamacılar tarafından seçilmiş müşteride satın alma algısını mümkün olduğu kadar canlı tutabilecek bir isim.

Alıcı ilk olarak markadan (ve tabii ki fiyattan) etkilenir (yukardaki örnekte iphone veya Samsung). Devamında aradığı özellikteki ürüne çabuk ulaşabileceği kullanıcı dostu bir filtreleme ve karşılaştırma sistemi arar.

Kodun konuşuyor olması ve koda bakınca ürün özellikleri hakkında bilgi sahibi olmanın tüketici için bir faydası olmadığından tüketiciyi ilgilendirmez.

Bir su pompası almak isteyen tüketici için de durum farklı değildir. Tüketici seçtiği marka için motor tipi (seçimi M5 olsun), 2 veya 3 faz (seçimi 3 faz olsun), boru çapı (seçimi 4 inch olsun), motor gücü (seçimi 2 kW olsun) gibi filtrelemeleri yaparak istediği ürüne hızla ulaşmak ister.

Aradığı ürünün sipariş kodunun A0127421 gibi konuşmayan bir kod olması (veya M5.3F.40i.2KW gibi konuşan kod olması) müşterinin umurunda olmaz (Bu kodların ikisi de “müşteri kodudur”, “üretici kodu” değil). Yeter ki sipariş verme işlemi aşamasında doğru ürünle işlem yaptığı ile ilgili bir kaygı taşımasın.

Bu arada sık düşülen bir yanılgıdan da bahsetmek istiyorum: Müşterinin ürününüzü satın alırken kullandığı kod (konuşan veya konuşmayan fark etmez) üreticinin ERP sistemindeki mamul kodundan farklıdır ve farklı olmalıdır.

Örneğin Apple iphone7 modeli piyasaya çıktıktan bir süre sonra mikrofon sisteminde önemli bir değişiklik (farazi olarak söylüyorum böyle bir şey duymadım) yapıp kendi içinde bunu farklı bir mamul kodu ile takip etmek isteyebilir (izlenebilirlik, maliyet gibi özel sebeplerden dolayı olabilir).

Buna benzer değişiklikleri belki defalarca yapabilir. Dolayısıyla iphone7 “müşteri koduna” ait onlarca “Apple mamul kodu” (üretici kodu) mevcut olabilir.

Ana fikir üretici kodu değiştiğinde müşteri kodu değişmeyeceğidir: iphone7. Çünkü firmalar bu gibi değişikliklerin müşteriler tarafında olumsuz bir algı yaratacağını bildikleri için farklı mamul kodlarını mutfaklarında saklı tutarlar. Müşteri kodunu değiştirerek müşterinin durumu fark etmesin istemezler.

Bu durum yukarda A0127421 kodunu verdiğimiz su pompası firması için de geçerlidir. Bu ürünün dâhili kodu defalarca değiştiği hâlde müşteri kodu aynı kalmış olabilir. Sıklıkla değişen kodlar müşterilerin kafasını karıştırır güven algısını düşürür.

Bu noktadan hareketle şirketin kendi mamul koduna karşılık gelen çok sayıda ilişkili kod bulunabilir. Aşağıdaki tabloda çok kullanılanları kodları tanımlamaya çalışalım:

Tanımlama	Açıklama
Üretici mamul kodu	Üreticinin kendi içinde kullandığı mamul kodudur. Ana referans koddur. Aşağıda bazıları açıklanmış olan kodlar bu kodla ilişkilendirilir. “Dâhili mamul kodu” olarak da tanımlanabilir.
Üretici pazar kodu	Üreticinin pazarda doğrudan yaptığı satışlarda müşterilerin görmesini istediği mamul kodudur. “Müşteri kodu” olarak da anılabilir.
Mamul grup kodu	Üreticiler aynı “Pazar kodu” için 1’den fazla “Üretici Mamul kodları” türettiğinde raporlama amaçlı kullanılan grup kodudur.
Mamul cari kodu	Firma OEM üretim yapıyorsa müşteriler ürünlerini kendileri tarafından belirlenen kodlarla anmak isterler. Müşteri bazında farklılık gösterir.

 

Özetlemek gerekirse, şirketinizde üretilen bir mamulün alacağı kod ile ara satıcıların veya son kullanıcının göreceği kod aynı değildir ve aynı olmamalıdır. Daha önce bahsettiğimiz gibi dâhili mamul kodunuz tekrar etmeyen unique bir kod olması esastır. Diğer bütün kodlar (müşteri kodu, cari kodu, vs) one-to-many ilişkisi ile dâhili mamul kodunuzla ilişkili olmalıdır.

Bu zincirde konuşan koda itiraz edemeyeceğimiz tek nokta müşterinin konuşan kod istemesi durumudur. Müşterinizle tartışmayın, onlara bu yazıyı okutmayın. Onları üzmeyin, istedikleri konuşan kodu kullanın. Fakat anlamlı bir gerekçe bulamadığınız sürece dâhili mamul kodunuzu konuşturmayın.

• Peki, mamul kodunda gerçekten konuşan kod kullanmamızı gerektiren bir durum yok mudur?

Birinci yazımızda bu durumla ilgili bir örnek vermiştik. Örneğin şöyle bir senaryoda kodun konuşan kod olması bir ihtiyaçtır:

Bir mamulünüz var. Etiket bilgisinde birçok yazılı bilgi yanında bir de barkod mevcut. Mamul bir süre sonra uzak bir noktaya gidiyor ve burada bir depo görevlisi veya forklift operatörü barkodu okutuyor. Operatör ürün karakteristiklerine göre bir işlem yapmak istiyor (Örneğin mamulün kalitesine göre depoda farklı alanlara istiflemek istiyor).

Fakat bu noktada bir ağ bağlantısı bulunmuyor. Yani mamul barkodunu okuttuğumda bu kodun karakteristiklerini sorgulayacağım bir altyapı mevcut değil. Bu durumda kod konuşan kod değilse operatör bir işlem yapamaz. Veya sadece etiketteki yazılı bilgilere göz ile bakarak işlem yapabilir ki bu pek kolay bir çalışma şekli değildir.

Kod konuşan kod olduğunda, örneğin barkodun 5 ilâ 8. dijitleri kalite tanımı ise barkod okuttuğumuz terminal bir program sayesinde bu mamulün kalite kodunu tanır ve operatörü yönlendirir (örneğin ürünü nereye istiflemesi gerektiğini bildirir).

Birinci yazımızda bu durumla açıklayan bir vaka örneğinden bahsetmiştik. Fakat temel koşul barkod okutulan yerde merkezi sunucu ile bağlantı bulunmaması veya bağlantı olduğu hâlde mamul işletmeye ulaştığında mamul ile ilgili bilgilerin merkezi sunucuya henüz ulaşmaması durumudur.

• Ya tamam da fazla mal göz çıkarmaz biz kodlarımızı yine de konuşturalım ne sakıncası olabilir ki?

Bu  argüman gereksiz yere kod konuşturmanın faydası olmasa bile zararı da olmayacağını, belki bir yerlerde işe yarayacağı için kodun konuşturulması gerektiğini savunur.

Oysa durum böyle değildir. Gereksiz yere konuşan kod, bu ve önceki yazıda açıklandığı şekilde, iş süreçlerinize kesinlikle zarar verir.

Basit bir örnekle kapatalım: Benim TC numaramda hiçbir konuşan kod yok. E-devlete bağlanmadan kimse TC numaramdan hareketle benim bilgilerime ulaşamaz. Bu argümanı savunanlar şöyle diyebilir: TC numaramın içinde “67” numarası olsa (doğum yılımı gösteren) ne zararı olurdu ki?

Peki ben mahkeme kararı ile doğum yılımı değiştirirsen ne olacaktı? a) TC numarası değişirdi, b) değişmez aynı kalırdı bla bla bla…

Bakın şimdiden kafa 1500 oldu. Oysa kodunuz konuşmuyorsa bunun gibi bir dolu komplikasyonun oluşmasını baştan engellersiniz.

İnsan beyni, neden bilinmez, kodları konuşturma meylindedir. Net bir gerekçe bulmadıkça siz bu sarmala kapılmayın.

Unutmayın: Konuşan kod dostunuz değildir! Ondan uzak durun 🙂