Kariyerimde belki de en çok ter döktüğüm, en çok “bu da mı olacak şimdi?” dediğim alanlardan biri kurumsal yazılımlar, özellikle de ERP’ler oldu. Bir üretim firmasının ERP’sini sıfırdan yazarken ya da mevcut bir sistemin derinliklerine indikçe anladım ki, ERP yazmak gerçekten de çok zor. Ama bu zorluk, genelde düşündüğümüz gibi sadece teknik bir mesele değil.
Bana kalırsa, ERP yazmanın asıl çetrefilli yanı, kodun kendisinden çok, organizasyonların karmaşık ve sürekli değişen insan süreçlerini dijitalleştirmeye çalışmakta yatıyor. Benim en pahalı hatalarım bir kod satırında değil, bir müşterinin “evet, tam olarak böyle çalışıyor” dediği bir iş akışının aslında hiç de öyle çalışmadığını fark ettiğim anlarda gizliydi.
Yazılım Değil, Organizasyon Akışı
Bir ERP’nin kalbi, bir şirketin tüm operasyonlarını, yani satın-almadan üretime, sevkiyattan faturalandırmaya kadar her şeyi birbirine bağlamaktır. Bu, sadece veritabanı tablolarını birleştirmekten çok daha fazlasını gerektirir. Benim tecrübelerime göre, bu süreçlerin her biri kendi içinde bir dizi istisna, onay mekanizması ve beklenmedik durum barındırır.
Yıllar önce bir üretim ERP’sinde, sevkiyat raporlarının sürekli eksik geldiğini fark ettik. Uzun bir debug sürecinden sonra anladık ki sorun, yazılımın kendisinde değil, depo personelinin “acil” durumlar için kullandığı, resmi olmayan bir manuel çıkış formundaydı. Yazılım, o formdan geçen ürünleri göremiyor, dolayısıyla raporlarda da eksik kalıyordu. Bu, organizasyonel bir “hack”in yazılımı nasıl etkilediğine güzel bir örnekti.
”Kurallar” ve “İstisnalar” Labirenti
Her şirket, kendi iş yapış şeklinin benzersiz olduğuna inanır. Bu, bir ERP projesinde en sık karşılaştığım durumlardan biridir. Başlangıçta belirlenen basit kurallar, zamanla onlarca istisna ve özel senaryo ile dolup taşar. Her bir istisna, kod tabanında yeni bir if-else bloğu, yeni bir veritabanı alanı veya bambaşka bir modül anlamına gelir.
Bir müşteri projesinde, bir ürünün iade sürecini tasarlarken “normal iade”, “hatalı ürün iadesi”, “müşteri memnuniyetsizliği iadesi”, “kampanya ürün iadesi” gibi bir dizi ayrı senaryo ortaya çıktı. Her birinin farklı onay süreçleri, farklı muhasebe kayıtları ve farklı stok hareketleri vardı. Bu durum, basit bir “iade” işlemini, içinden çıkılmaz bir mantık yumağına dönüştürdü. Yazılım mimarisi çoğu zaman yazılım değil, organizasyonel akıştır derken kastettiğim tam olarak buydu.
Değişen İhtiyaçlar ve Sürekli Evrim
Bir ERP yazdığınızda veya birini yönettiğinizde, asla bitmeyen bir döngünün içine girersiniz. İş süreçleri değişir, yeni yasal düzenlemeler gelir, şirket büyür veya küçülür, hatta global pazarlar farklı gereksinimler dayatır. Üretim planlama gibi alanları AI ile iyileştirmeye kalktığınızda bile, ana zorluk modelin doğruluğu değil, önerilen planın insan faktörleri ve mevcut makine durumları ile nasıl entegre edileceğidir.
Bugün doğru çalışan bir sistem, bir süre sonra işlevsiz hale gelebilir. Bu sürekli değişim baskısı, ERP’yi yaşayan bir organizmaya dönüştürür. Her yeni gereksinim, mevcut yapının üzerine yeni bir katman ekler ve bu katmanlar zamanla bir legacy debt dağı oluşturur. Çok daha küçük ölçekli sistemlerde bile sadece vergi oranları değiştiğinde ne kadar çok kodun etkilendiğini görünce, kurumsal ölçekteki bir ERP’nin yükünü daha iyi anlıyorum.
İnsan Faktörü ve Veri Bütünlüğü
Son olarak, ERP’lerin karmaşıklığına en büyük katkıyı insan faktörü yapar. Kullanıcılar hatalı veri girebilir, süreçleri atlayabilir veya eğitimi yeterli olmadığı için sistemi doğru kullanamayabilir. Bu durum, veri bütünlüğünü korumak için ek doğrulama katmanları, yetkilendirme kontrolleri ve karmaşık iş akışları gerektirir.
Sık karşılaşılan bir örnek: kullanıcılar manuel veri girişinde bir alana yanlışlıkla beklenenden farklı tipte bir değer girer; backend’deki validation yeterli değilse bu basit hata veritabanı tarafında bir type mismatch’e ve beklenmedik bir crash’e yol açabilir. Bu tip senaryolar, sadece kodun sağlamlığını değil, aynı zamanda kullanıcı arayüzü (UI/UX) tasarımının ve eğitim süreçlerinin ne kadar kritik olduğunu gösterir.
ERP yazmak, teknik yetkinlikten çok daha fazlasını gerektiren bir alandır. Organizasyonel dinamikleri anlamak, insan davranışlarını öngörmek ve sürekli değişen bir ortamda esnek kalabilmek esastır. Bu yüzden, bir sonraki “basit” ERP projeniz için teklif verirken, göz ardı edilen bu derinlikli karmaşıklığı aklınızda bulundurun.
Peki, sizin en zorlu ERP deneyiminiz neydi? Teknik bir sorun mu, yoksa organizasyonel bir karmaşa mı? Yorumlarda paylaşın, ben de tecrübelerinizden öğrenmek isterim.