Hazır ERP'yi bekleyen bir yönetici, kendi sistemini yazmaya başladı | Vaka Çalışması
Üretim & İmalat Birebir Mentorluk

Hazır ERP'yi bekleyen bir yönetici, kendi sistemini yazmaya başladı

Hazır ERP'nin üretim tarafı için istenen tek bir düzeltme bir ayı geçtiği hâlde gelmedi; bu arada her ihtiyaç için yazılan ayrı uygulamalar birbirini görmüyordu.

Reşat Alemler · Savunma sanayinde üretim yapan bir firmanın yöneticisi Eylül 2026
1 ay+
hazır ERP'den istenen, gelmeyen tek düzeltme
3 sistem
derslerden sonra faaliyette
Her sabah
faturaları kendi kontrol eden rutin
8 gün
ilk dersten son derse
Takım deposu uygulamasının ana sayfası: kullanılabilir, makinede ve bilemede takım sayıları
Ders aralarında kendi kurduğu takım deposu uygulaması; derslerden sonra faaliyette. Tedarikçi adı maskelendi.

Sorun

Reşat Alemler savunma sanayinde üretim yapan bir firmanın yöneticisi. Firmanın kullandığı hazır ERP programı, üretim tarafı için istenen tek bir düzeltmeyi bir ayı geçtiği hâlde yapmamıştı.

“Sadece üretim alanı için bir tane düzeltme istedim. Bir ayı geçti, hâlâ yapmadılar. Zaten ona sinirden ben bu işe girdim, başladım.”

Bu sayfadaki diğer vakalardan farkı burada başlıyor: derse boş gelmedi. Yazılımcı değil, ama gelmeden önce de kendi uygulamalarını yazıyordu — hazır yapay zeka araçlarıyla kurduğu, kodu depoda, yayını bulutta, verisi veritabanında duran çalışan bir üretim takip uygulaması ve bir maliyet uygulaması vardı.

Dolayısıyla getirdiği problem “nasıl yapılır” değildi. İki tanesi vardı ve ikisi de yöntemle ilgiliydi:

  • Test edilmeden ilerliyordu. Hızlı yazıyor, sonra düzeltiyor, düzeltirken başka bir şey bozuluyordu.
  • Her ihtiyaca ayrı bir uygulama yazıyordu. Takım takibi ayrı, personel ayrı, maliyet ayrı; aynı veri üç yerde tekrar ediyor, hiçbiri diğerini görmüyordu.

“Hep böyle genele yapılmış programlar olduğu için sürekli bir yerlerde takılıyoruz. Ama şimdi hayal ettiğim şeyi birebir kendi programımıza tam uyacak şekilde yaptım.”

Aradığı şey bu yüzden yeni bir araç değildi:

“Bir de yol gösteren olursa inşallah.”

Süreç

Birebir, ekran paylaşımıyla, kendi firmasının gerçek işleri üzerinden.

Birlikte ne yaptık, o ne yaptı
  • Birlikte — mevcut uygulamanın kod incelemesi, plan modu ve sorgulayarak planlama, sürüm yönetimi ve ayrı geliştirme ortamı, e-fatura entegrasyonu, ilk rutinin kurulması, ERP çatı mimarisi kararları
  • Dersler arasında — kesici takım deposu uygulamasını sıfırdan kendi kurdu, personel devam uygulamasına başladı, üretim modülünün iş kurallarını tek tek kendi cevapladı
  • Doğrulanan çıktı — takım deposu faaliyette, cihaz veri aktarımı tamamlandı, fatura rutini otomatik çalışıyor

Sonu gelmeyen düzeltme

İlk derste kendi yazdığı uygulamanın koduna birlikte baktık ve ciddi hatalar çıktı. Karar yamamak değil, sıfırdan kurmak oldu. Asıl mesele ise kodun kendisi değildi:

“Yazdıktan sonra zaten düzeltmeye başladım. Bu sefer sonu gelmiyor.”

Bu cümle, bu sayfadaki en öğretici cümle. Yapay zekayla hızlı yazmak kolay; hızlı yazılanı yönetmek zor. Cevabı da basit ama sezgiye aykırı: planlama kısmını uzattıkça uzatın, yazma kısmı zaten kendiliğinden hallolur. Proje büyüdüğünde plansız büyüyen kodu yapay zeka da yönetemiyor.

Dersler arasında kurdukları

Bu vakanın en güçlü verisi derslerde değil, derslerin arasında. Her seferinde işyerinden gelen gerçek bir ihtiyaçla yeni bir şey kurup geldi. Kesici takım deposu uygulamasının tetikleyicisi bir öğle yemeğiydi:

“Biz öğlen yemeği yerken arkadaşlar ‘Takım haneyi takip edemiyoruz.’ dediler. Takımcı arkadaş da işten ayrıldı. Başlamışken bari şunu bir kurcalayayım dedim.”

Uygulamayı kurdu, iki bilgisayardan, tabletten ve telefondan denedi. Sonraki aralarda personel devam uygulamasına başladı, bulutta duran bir takip uygulamasını firma bilgisayarına taşıdı, üretim modülünün iş kuralı sorularını derse kalmasın diye tek tek kendi cevapladı.

Yapay zekayı denetlemeyi öğrenmek

Değişimin en somut göstergesi burada. Başta yapay zekanın ürettiğini kabul ediyordu; sonunda kontrol ediyor:

“Baktım, anlattığım şeyler aslında birebir yapılmamış. Bazı şeyler kafamda oturmadı. Onu yönlendireceğim, değiştireceğim.”

Aynı refleksle, istemediği bir arayüz animasyonunu geri aldırdı. Kurulan ilk rutin de gerçek bir işi doğru yaptı: sabah gelen faturaları kontrol edip dördünün elle zaten işlendiğini fark ederek raporladı.

Dağınıklıktan tek çatıya

Son derste ayrı ayrı yazılmış uygulamaları tek bir sistemde toplama kararı alındı. Karar, yazılan koddan daha önemli:

Dağınık uygulamalardan tek çatıya Solda her ihtiyaç için ayrı yazılmış, her biri kendi verisini tutan dört uygulama. Sağda bunları kapsayan bir platform kabuğu, eşit dört modül, ortak malzeme kartı ve tek veritabanı. ÖNCE Üretim Takım deposu Personel devam Maliyet dört uygulama, dört ayrı veri KARAR Platform kabuğu Üretimmodül Takım deposumodül Personel devammodül Maliyetmodül ortak malzeme kartı tek veritabanı
Son derste alınan mimari karar: ayrı ayrı yazılmış uygulamalar yerine tek kabuk, eşit modüller ve ortak veri.

Platform bir kabuk; üretim, takım deposu, personel ve maliyet eşit modüller; hepsi tek bir veritabanına ve ortak bir malzeme kartına bakıyor. Böylece aynı parça üç ayrı uygulamada üç ayrı kayıt olmaktan çıkıyor.

Sonuç

Sekiz günün sonunda ortada duranlar:

  • Kesici takım deposu uygulaması faaliyette — yerel ağda çok cihazlı, Windows servisi olarak çalışıyor, ayrı bir geliştirme ortamı var.
  • Personel devam cihazından veri aktarımı tamamlandı.
  • E-fatura entegrasyonu çalışıyor ve her sabah faturaları kontrol eden rutin otomatik işliyor.
  • Tek çatı ERP mimarisi kararlaştırıldı — ama kodu henüz yazılmadı.

Asıl değişim araçlarda değil, yöntemde:

BaşlangıçtaSonunda
Nasıl yazıyorduYaz, sonra düzelt — “Bu sefer sonu gelmiyor.”Önce plan, sonra kod
Yapay zekanın çıktısıKabul ediliyordu”Baktım, anlattığım şeyler aslında birebir yapılmamış.”
UygulamalarHer ihtiyaca ayrı, birbirini görmüyorTek veritabanı ve ortak malzeme kartı kararı
Hazır ERPDüzeltme için bekleniyorGereken yeri kendi yazıyor

Kolay olmadı

  • ERP çatısı kodlanmadı. Mimari kararlar alındı, kod yazılmadı. Bu sayfada “dört derste çalışan ERP” diye bir şey yok.
  • Aynı anda çok fazla proje vardı. Takım deposu, personel devam, seri takip, üretim, maliyet, fatura, bir de web sitesi. Tekrar eden uyarı hep aynıydı: tek tek gidin.
  • Dokümansız cihaza bağlanmak uzun sürdü. Personel devam cihazından veri çekmek derslerin içine sığmadı; ders sonunda hâlâ test aşamasındaydı, sonradan tamamlandı.
  • Bilgisayar doldu. Bir derste disk sıfır bayta indi; oturumun bir kısmı temizliğe gitti.
  • Kota kaygısı işi böldü. Başta “token bitecek” endişesiyle çekingen çalışıldı; üst pakete geçilince bu sefer her şeye aynı anda yüklenme eğilimi çıktı.
  • Altyapı belirsizdi. Ana sunucu tamirdeydi; verinin nerede duracağı çalışma boyunca net değildi.
  • Ölçülmüş bir zaman ya da para kazancı yok. Bu sayfadaki hiçbir rakam öyle bir iddia taşımıyor — kendisi de zaten onu aramıyordu.
Sonuç
  • Kesici takım deposu uygulaması faaliyette: yerel ağda çok cihazlı, Windows servisi olarak çalışıyor
  • Personel devam kontrol cihazından veri aktarımı tamamlandı
  • E-fatura entegrasyonu çalışıyor; her sabah faturaları kontrol eden rutin otomatik işliyor
  • Tek çatı ERP mimarisi kararlaştırıldı: platform kabuğu, eşit modüller, tek veritabanı, ortak malzeme kartı
  • Plansız "yaz-düzelt-yaz" döngüsünden planlı ve modüler bir sürece geçiş
Kullanılan araçlar: Claude Code · plan modu · grill-me · Impeccable · OpenSpec · GitHub · SQLite · Supabase

“Amacım yapay zeka ile para kazanmak değil. Şirketteki işleri kolaylaştırmak ve insan hatasını azaltmak.”

“Hep böyle genele yapılmış programlar olduğu için sürekli bir yerlerde takılıyoruz. Ama şimdi hayal ettiğim şeyi birebir kendi programımıza tam uyacak şekilde yaptım. Daha çok kafama yatıyor.”

Reşat Alemler · Savunma sanayinde üretim yapan bir firmanın yöneticisi

Senin işin hangi dosyalara dağılmış?

Ne yapmak istediğini anlat, birlikte yol haritası çıkaralım.

Ücretsiz tanışma toplantısı planla →

30 dakika · Ücretsiz · Satış konuşması değil: uygun değilsen bunu da söylerim.

Devamı

Bu konuda yazdıklarım