Kariyerimde belki de en büyük dersleri, yazdığım bir satır koddan değil, bir üretim firmasının ERP’sini geliştirirken aldım. Bana kalırsa, kurumsal yazılım geliştirme, özellikle de ERP gibi sistemlerde, işin yazılım tarafı genellikle buzdağının sadece görünen kısmı oluyor. Asıl mesele, o organizasyonel akışı, insanı ve iş süreçlerini anlamakta yatıyor.
Bu kadar yılın sonunda gördüm ki, bir ERP’nin başarısı, ne kadar hızlı bir API yazdığınızla ya da hangi modern framework’ü kullandığınızla değil, şirketin “satın al/üret/sevk/fatura” akışını ne kadar doğru yansıttığınızla doğrudan alakalı. Hatta bazen, o akışın kendisi bile net değilken, yazılımı buna zorlamak, en büyük hatalara davetiye çıkarıyor.
Kod Değil, Akış ve İnsan Hikayesi
Bir ERP projesine başladığımda, herkesin gözü kodda, ekranlarda, raporlardaydı. Ben de PostgreSQL, FastAPI ve Vue/React frontend üçlüsüyle sağlam bir altyapı kurma peşindeydim. AI ile üretim planlama modülleri, operatör ekranları ve iSCSI tedarik zinciri entegrasyonları gibi teknik konularla boğuşuyordum.
Ancak zamanla anladım ki, asıl zorluk, bir üretim ERP’sinde “geç sevkiyat raporu neden hep eksik geliyor?” gibi soruların cevabını bulmaktı. Bu sorunun kökeni, genellikle teknik bir bug’dan çok, sahadaki bir operatörün veri girişini atlaması, depo ile üretim arasındaki iletişimsizlik ya da satın alma sürecindeki onay mekanizmasının gecikmesi gibi organizasyonel boşluklarda gizliydi. Yazılım sadece bu akışı yansıtan bir ayna görevi görüyordu.
”Evet” Demenin Gizli Maliyeti
Kariyerimin en pahalı hatalarından biri, bir “evet” kelimesiydi. Teknik olarak yapılabilir görünen, ancak iş akışı açısından tam oturmamış bir talebe “evet” demek, sonrasında tahmin edilemez bir karmaşaya yol açabiliyor. Bir müşterinin projesinde, basit görünen bir “depo sayımını anlık görelim” isteği, mevcut envanter yönetim süreçlerindeki tutarsızlıklar nedeniyle aylarca süren bir veri temizleme ve süreç iyileştirme maratonuna dönüşmüştü.
O an anladım ki, yazılım mimarisi çoğu zaman yazılım değil, organizasyonel akıştır. Eğer organizasyonun kendi akışı bulanık veya çelişkili ise, siz ne kadar temiz kod yazarsanız yazın, sistem her zaman bir yerde patlak verecektir. Bu durum, özellikle transaction outbox, event-sourcing veya eventual consistency gibi mimari desenleri uygularken, iş süreçlerinin netliği olmadan nasıl felaketlere yol açabileceğini bana gösterdi.
Veri Bütünlüğü ve Olması Gereken Akış
Veritabanı tarafında PostgreSQL kullanırken, index stratejileri (B-tree, GIN, BRIN), connection pool tuning, replikasyon (logical vs physical) gibi konulara hakim olsam da, asıl zorluk, farklı modüller arasındaki veri tutarlılığını sağlamaktı. Özellikle bir üretim planlama sisteminden gelen verinin, tedarik zinciri ve faturalama süreçleriyle nasıl entegre olacağı, hayati bir konuydu.
Bazen, gerçek zamanlı bir dashboard tasarlarken, veritabanındaki optimistic vs pessimistic lock tercihleri ya da ORM’in N+1 sorgu patlamaları gibi “trap”leri çözmekten çok, iş akışındaki “bu veriyi kim güncelleyecek?” veya “bu bilginin tek kaynağı neresi?” gibi soruların cevabını bulmak daha zordu. Çünkü eğer iş akışı veri bütünlüğünü doğal olarak sağlamıyorsa, yazılımcı olarak siz ne kadar uğraşırsanız uğraşın, bir yerden bir tutarsızlık sızabiliyordu.
Operasyonel Gerçeklikler ve Geri Bildirim Döngüsü
Sistemi canlıya aldıktan sonra da iş bitmiyordu. CI/CD reliability, blue-green deploy stratejileri, feature flag kullanımı ve rollback otomasyonu gibi konular, sistemin sorunsuz çalışması için vazgeçilmezdi. Bir yandan da observability (metrik, log, trace) ile sistemin nabzını tutuyor, SLO ve error budget yönetimiyle olası aksaklıkları önceden tespit etmeye çalışıyordum.
Örneğin, bir operatör ekranındaki küçük bir gecikme, üretim hattında dakikalarca duraklamaya neden olabiliyor, bu da doğrudan şirketin kar marjını etkiliyordu. Bu geri bildirimler, sadece teknik düzeltmeler yapmakla kalmayıp, bazen ekran tasarımını tamamen değiştirmemize, hatta iş akışındaki bir adımı basitleştirmemize yol açıyordu. Bu süreçler, yazılım geliştirmenin sadece kod yazmaktan ibaret olmadığını, sürekli bir iyileştirme ve adaptasyon yolculuğu olduğunu pekiştirdi.
ERP geliştirirken öğrendiğim en büyük ders, teknolojinin sadece bir araç olduğuydu. Asıl güç, organizasyonun içindeki insanları, onların iş yapış şekillerini ve o karmaşık akışları anlayıp, yazılımı buna uygun şekilde şekillendirebilmekte yatıyor. Bir ERP projesi, bir şirketin ruhunu dijitalleştirmeye çalışmaktır ve bu, teknik becerilerin çok ötesinde bir empati ve iş bilgisi gerektirir.
Senin bu konudaki deneyimlerin neler? Bir kurumsal yazılım projesinde en büyük dersi ne zaman aldın? Yorumlarda paylaşmanı merakla bekliyorum.