Kocaeli'de bir üretici firmada işi yavaşlatan şey çoğunlukla makine ya da kapasite değil; talebin, stok bilgisinin ve evrakın insan eliyle bir masadan diğerine taşınmasıdır. Sahada en sık tıkanan beş süreç var: gelen fiyat talebinin cevapsız beklemesi, stok bilgisinin ERP ile sahada tutmaması, tedarikçi fiyat ve terminini telefonla toplamak, üretim ilerlemesinin ancak gün sonunda görülmesi, sevkiyat ve irsaliye evrakının elle girilmesi. Aşağıda her birini belirtisi, kök nedeni ve yazılım tarafındaki karşılığıyla tek tek ele alıyoruz.
Kocaeli'de tıkanma neden daha çok can yakıyor
Kocaeli, Türkiye sanayi üretiminde ağırlığı en yüksek illerden biri. Kimya ve petrokimya, otomotiv ve yan sanayi, metal işleme, ambalaj ve lojistik aynı coğrafyada iç içe çalışıyor. İzmit, Gebze, Darıca, Körfez, Gölcük, Dilovası ve Çayırova hattında bir firmanın müşterisi de tedarikçisi de çoğu zaman yarım saatlik mesafede.
Bu yakınlık avantaj gibi görünür ama bir yan etkisi vardır: müşteri hızlı cevap beklemeye alışmıştır. Aynı talebi üç firmaya birden gönderen bir satınalmacı için sıralama çoğu zaman fiyattan önce sırayla belirlenir. Bu yüzden Kocaeli'de operasyonel gecikme, başka bir ilde "biraz yavaş çalışıyoruz" olarak geçiştirilebilecekken burada doğrudan kaybedilen iş demektir.
İkinci bir etken de ürün çeşitliliği. Kimya tarafında çalışan bir firmanın ambalaj tedarikçisi, otomotiv yan sanayiye de parça basıyor olabilir. Aynı atölyede birbirinden çok farklı iş kalemleri, farklı terminler ve farklı belge düzenleri yan yana ilerler. Süreçler bu çeşitlilik altında kâğıtla ve hafızayla yürütülmeye çalışıldığında, tıkanma tek bir yerde değil aynı anda birkaç noktada başlar.
1. Gelen fiyat talebi cevapsız bekliyor
Belirtisi: Talep mail kutusuna düşer, okunur, "bunu bir bakalım" denir ve akşama kalır. Ertesi sabah kimse tam olarak hatırlamaz kimin baktığını. Müşteri arayıp sorduğunda telaşla açılır. Ayda birkaç talebin hiç cevaplanmadığı, ancak müşteri bir daha aramadığı için fark edilmediği de olur.
Tipik bir talep şöyle gelir: "Merhaba, ekteki resme göre 8 mm sac, 40 adet, lazer kesim + büküm. Gebze'ye teslim, termin ne olur, fiyat bekliyoruz." Bu tek cümle üç ayrı işi tetikler: teknik okuma, malzeme kontrolü, termin hesabı. Üçü de aynı kişinin masasında birikir.
Kök nedeni: Talep bir sisteme değil bir kişiye düşer. Kayıt yoksa sayaç da yoktur; "kaç talep bekliyor" sorusunun cevabı kimsede olmaz.
Yazılım tarafındaki karşılığı: Gelen talebi okuyup içindeki kalemleri ayrıştıran, hangi ürün olduğunu sistemdeki kayıtlarla eşleştiren ve eksik bilgi varsa bunu işaretleyip önünüze koyan bir yapay zeka personel ekibi bu adımı devralabilir. Sonuç bir chatbot cevabı değildir; teklifi hazırlayacak kişinin masasına düşen, kalemleri eşleşmiş, eksikleri belirtilmiş bir taslaktır. Metal ticaretinde kurduğumuz sistem 1.500+ gerçek talep ve 8.000+ kalemlik tedarikçi stok listesi üzerinde çalıştı; kalem eşleştirmesinde isabet %99'un üzerinde ölçüldü. Ayrıntısı talep-teklif otomasyonu vakasında anlatılıyor.
2. Stok bilgisi ERP ile sahada tutmuyor
Belirtisi: ERP'de 120 adet görünen parça depoda 60 çıkar. Ya da tersi olur: elde mal vardır, sistemde görünmediği için dışarıdan sipariş verilir. Satış ekibi bir süre sonra ERP'ye güvenmeyi bırakıp depoyu telefonla arar. O andan itibaren tek doğru bilgi kaynağı depo sorumlusunun hafızasıdır.
Kök nedeni: Stok hareketi gerçekleştiği anda değil, sonradan girilir. Üretime çıkan malzeme akşam, fireler haftada bir, iade edilen parçalar hiç girilmez. Sistem yanlış değildir; sadece geç beslenir.
Yazılım tarafındaki karşılığı: Burada yeni bir ERP satın almak nadiren doğru cevaptır. Doğru cevap genelde araya giren ince bir katmandır: sahadaki hareketi olduğu yerde, birkaç saniyede kaydettiren mobil bir ekran ve bunu mevcut ERP'ye aktaran bir entegrasyon. Terminalden okutulan bir etiket, tabletten seçilen bir iş emri, ERP'ye giden bir kayıt. Özel yazılım tarafında bu, en hızlı geri dönen işlerden biridir çünkü mevcut yapıyı yıkmaz, sadece besleme hızını düzeltir.
3. Tedarikçi fiyat ve termini telefonla toplanıyor
Belirtisi: Satınalma sorumlusu sabah beş tedarikçiyi arar, fiyatı ve termini bir deftere ya da Excel'e yazar. Biri o an ulaşılamaz, öğleden sonra tekrar aranır. Akşam olduğunda karşılaştırma tablosu hâlâ yarımdır. Bu arada müşteriye verilecek teklif bekler.
Dilovası ya da Körfez'deki bir tedarikçiden gelen "stokta var, yarın yükleriz" cevabı bir yere kaydedilmezse, iki gün sonra aynı soru yeniden sorulur.
Kök nedeni: Tedarikçi iletişimi bir sürece değil bir ilişkiye bağlıdır. Bilgi telefon görüşmesinin içinde kalır ve kurum hafızasına geçmez. O kişi izne çıktığında süreç durur.
Yazılım tarafındaki karşılığı: Sorulacak kalem listesini çıkaran, doğru tedarikçiye standart formatta soru gönderen, gelen cevapları tek tabloda toplayıp yan yana koyan bir akış kurulabilir. Karar yine satınalmacınındır; ama önüne yarım tablo değil tamamlanmış bir karşılaştırma gelir. Cevap gelmeyen tedarikçinin takibi de aynı akışın işidir.
- Hangi kalem, hangi tedarikçiye, ne zaman soruldu
- Kim cevapladı, fiyat ve termin ne verdi
- Hangi teklif hangi müşteri talebine bağlı
- Aynı kalemde geçen ay ne fiyat gelmişti
4. Üretim ilerlemesi ancak gün sonunda görülüyor
Belirtisi: "Şu iş nerede" sorusunun cevabı için birinin atölyeye inmesi gerekir. Müşteri termin sorduğunda verilen cevap tahminidir. Gecikme, gecikmeye dönüştükten sonra öğrenilir; önlem alınacak zaman kalmaz.
Kök nedeni: İş emri kâğıt üzerindedir ve kâğıt tezgâhın yanında durur. Bilgi ancak vardiya bitince, o kâğıt ofise geldiğinde sisteme girer. Yani gün içinde şirketin üretim görüntüsü yoktur.
Yazılım tarafındaki karşılığı: Her operasyonun başlangıç ve bitişinin tezgâh başında tek dokunuşla işaretlendiği basit bir ekran çoğu zaman yeterlidir. Amaç operatörü izlemek değil, işin hangi istasyonda beklediğini görünür kılmaktır. Bunun üstüne kurulan bir uyarı katmanı, planlanan süreyi aşan işi kendiliğinden bildirir. Böylece müşteri termini sorduğunda verilen cevap tahmin değil, sistemdeki gerçek duruma dayanan bir bilgi olur; gecikme de ortaya çıktığı gün, hâlâ önlem alınabilecekken görülür. Böyle bir çözüm genellikle sahadaki gerçek akışa göre tasarlanır; hazır paketler bu noktada zorlanır çünkü her atölyenin rota mantığı farklıdır.
5. Sevkiyat ve irsaliye evrakı elle giriliyor
Belirtisi: Aynı bilgi gün içinde üç kez yazılır: bir kez sevk emrine, bir kez irsaliyeye, bir kez faturaya. Araç kapıda beklerken evrak hazırlanır. Ay sonunda irsaliye-fatura eşleşmesinde farklar çıkar, muhasebe bunları tek tek geri sorar.
Kök nedeni: Sevkiyat, üretim ve muhasebe ayrı kayıtlar tutar. Bunları birbirine bağlayan tek şey insanın dikkatidir; yoğun bir günde ilk zayıflayan da odur.
Yazılım tarafındaki karşılığı: Sipariş kaydından sevk emrine, oradan irsaliye ve faturaya tek bir veri zinciri kurulur. Aynı bilgi bir kez girilir, sonraki belgeler onu devralır. Plaka, sürücü, teslim adresi ve teslim alan kişi bilgisi de aynı kayıtta durur; müşteri bir ay sonra sorduğunda arşiv karıştırılmaz.
Bu zinciri kurarken en çok işe yarayan şey yeni bir modül değil, kimin neyi nerede girdiğinin netleşmesidir. Çoğu firmada aynı veriyi üç kişinin girmesinin sebebi, hiçbirinin diğerinin kaydına güvenmemesidir. Tek kayıt noktası belirlendiğinde ay sonu mutabakatı bir düzeltme turu olmaktan çıkıp kontrol adımına dönüşür.
Kocaeli üreticisi için beş süreç tek tabloda
| Süreç | Belirti | Kök neden | İlk adım |
|---|---|---|---|
| Fiyat talebi | Talep akşama kalıyor, bazıları hiç cevaplanmıyor | Talep sisteme değil kişiye düşüyor | Gelen talebi kayda alıp kalemlerine ayıran akış |
| Stok | ERP'deki miktar depoyla tutmuyor | Hareket anında değil sonradan giriliyor | Sahada anlık kayıt ekranı + ERP entegrasyonu |
| Tedarikçi fiyat/termin | Karşılaştırma tablosu gün sonunda hâlâ yarım | Bilgi telefon görüşmesinde kalıyor | Standart soru formatı ve tek toplama tablosu |
| Üretim ilerlemesi | "İş nerede" sorusuna atölyeye inmeden cevap yok | İş emri kâğıtta, veri vardiya sonunda giriliyor | Operasyon başlat/bitir ekranı, gecikme uyarısı |
| Sevkiyat ve irsaliye | Aynı bilgi üç belgeye elle yazılıyor | Sevkiyat, üretim ve muhasebe ayrı kayıt tutuyor | Sipariş-sevk-irsaliye-fatura veri zinciri |
Hepsini birden yapmayın
Bu beş sürecin tamamına aynı anda girmek, çoğu KOBİ'de projenin yarıda kalmasının en yaygın sebebidir. Doğru sıralama genellikle şudur: en çok para kaybettiren tıkanma hangisiyse oradan başlanır, iki-üç haftada çalışan bir parça çıkarılır, saha onu kullanmaya başlar, sonra bir sonrakine geçilir.
Bu sıralamanın bir faydası daha var: ilk parça çalışmaya başladığında ekip, ikinci adımda neye ihtiyaç duyduğunu çok daha net söyler. Baştan yazılan uzun bir istek listesi, sahayı bir kez gördükten sonra genellikle yarı yarıya değişir. Küçük başlamak bu değişimi maliyetsiz kılar.
Hangisinin öncelikli olduğunu anlamak için karmaşık bir analize gerek yok. Bir hafta boyunca üç şeyi not almak yeterlidir: kaç talep geldi ve kaçı aynı gün cevaplandı, kaç kez stok bilgisi için depo arandı, kaç sevkiyat evrakı ikinci kez düzeltildi. Bu üç sayı, nereden başlanacağını neredeyse her zaman kendiliğinden söyler. Çalışma biçimimiz de bu mantığa göre kurulmuştur: önce dar bir iş, çalışan bir sonuç, sonra genişleme.
Kısa özet ve bir sonraki adım
Kocaeli'deki bir üretici firmada tıkanmanın kaynağı çoğunlukla ekipte değil, bilginin bir masadan diğerine elle taşınmasındadır. Talep, stok, tedarikçi cevabı, üretim durumu ve sevk evrakı — beşi de aynı hastalığın farklı yüzleridir: veri geç girer, geç görünür, geç karar verilir. Bunlardan birini bile yerine oturtmak, ekibin gününü gözle görülür biçimde boşaltır.
İzmit, Gebze, Darıca, Körfez, Gölcük, Dilovası ya da Çayırova'da üretim yapıyorsanız ve bu beş başlıktan en az ikisi tanıdık geldiyse, kendi sürecinizin hangisinden başlaması gerektiğini konuşalım: teklif alın.
Sıkça Sorulan Sorular
Mevcut ERP'mizi değiştirmeden bu sorunları çözebilir miyiz?
Beş süreçten hangisine önce girmeliyiz?
Küçük bir atölyeyiz, bu tür bir yazılım bize göre mi?
Sahadaki ustalar tablet üzerinden kayıt girmeye alışır mı?
Yapay zeka personeli dediğiniz şey chatbot mu?
Kocaeli dışında çalışıyor musunuz?
Yazar
Doğukan Azer ÇİFTCİYazılım Mühendisi
QuantKOD’da yazılım mühendisi. Ölçeklenebilir mimariler, özel yazılım geliştirme ve doğru teknoloji seçimleri üzerine yazıyor.