Bir üretim ERP’sinde uzun süre çalıştıktan ve bir yandan da kendi yan ürünlerimi geliştirirken, kurumsal standardizasyonun getirdiği çelişkilerle çok karşılaştım. Özellikle, bir tarafta ERP’nin sağladığı öngörülebilirlik varken, diğer tarafta kendi projelerimde aradığım esneklik ve hızlı inovasyon arasında ciddi bir gerilim olduğunu gözlemledim. Bu yazı, bu iki dünyanın nasıl çatıştığını ve benim bu durumu nasıl ele aldığımı anlatacak.
Kurumsal sistemler, özellikle ERP’ler, iş süreçlerini standartlaştırma ve belirli bir düzen içinde yürütme üzerine kuruludur. Bu yaklaşım, büyük organizasyonlar için vazgeçilmezdir, ancak esnekliğe ve hızlı prototiplemeye ihtiyaç duyan yan ürünler için bir engel teşkil edebilir. Bence, bu durum her teknoloji insanının kariyerinde bir noktada sorguladığı, “Acaba daha hızlı ve özgür hareket edemez miydim?” sorusunun temelini oluşturuyor.
ERP Standardizasyonunun Avantajları: Neden Bu Yola Gidiyoruz?
Kurumsal kaynak planlama (ERP) sistemlerinin standartlaştırılması, ilk bakışta birçok avantaj sunar. Finansal raporlamadan tedarik zinciri yönetimine kadar tüm iş akışlarının tek bir sistem üzerinden yürütülmesi, şirket içi tutarlılığı ve verimliliği artırır. Bir üretim firmasının ERP’sinde çalışırken, IFRS entegrasyonu ve aylık kapanış süreçlerinde bu standardizasyonun ne kadar kritik olduğunu defalarca gördüm. Örneğin, maliyet muhasebesi süreçlerinin her ay aynı şablon ve kurallarla işlemesi, hata oranını minimuma indiriyor ve denetim süreçlerini kolaylaştırıyor.
Bu yapı, özellikle büyük ve karmaşık organizasyonlarda operasyonel riskleri azaltır. Farklı departmanların kendi sistemlerini kullanması yerine, merkezi bir ERP, veri bütünlüğünü sağlar ve farklı birimler arasında koordinasyonu artırır. Bu sayede, “satın al, üret, sevk et, fatura et” gibi temel akışlar öngörülebilir bir şekilde yönetilebilir. Birden fazla lokasyondaki envanterin tek bir merkezden izlenmesi gerektiğinde, standart bir ERP modülünün sağladığı merkeziyetçiliğin ne kadar değerli olduğunu bir kez daha anladım.
Ancak bu sağlam yapı, aynı zamanda bir pranga da olabilir. İş süreçleri ne kadar kesin tanımlanırsa, bu tanımların dışına çıkmak da o kadar zorlaşır. İşte tam bu noktada, hızlı değişime ve özelleştirmeye ihtiyaç duyan yan ürünler için sorunlar baş göstermeye başlar. ERP’nin getirdiği bu katı çerçevenin, yaratıcılığımı ve “hızlıca bir şeyler deneyelim” felsefemi nasıl etkilediğini sıkça sorguladım.
Esneklik Kaybının İlk Sinyalleri: Prototipleme Aşaması
Bir fikir aklıma geldiğinde veya bir soruna hızlı bir çözüm geliştirmek istediğimde, ilk düşündüğüm şey “nasıl en hızlı şekilde bir prototip çıkarırım” oluyor. Kendi yan ürünlerimde bu süreç oldukça basit: bir FastAPI backend, bir PostgreSQL veritabanı ve belki bir Vue/React frontend ile birkaç saatte çalışan bir şeyler ortaya koyabiliyorum. Ancak aynı yaklaşımı, bir ERP sistemiyle entegre olması gereken bir senaryoda uygulamaya çalıştığımda, işler anında karmaşıklaşıyor.
Örneğin, üretim planlama için AI destekli bir operatör ekranı geliştirmek istediğimi düşünelim. Bu ekranın, ERP’deki mevcut üretim siparişlerini okuması ve yeni iş emirlerini geri yazması gerekiyor. Benim için basit bir GET /orders ve POST /orders API’si yeterliyken, kurumsal dünyada bu, bir dizi güvenlik politikası, veri dönüşüm katmanı, yetkilendirme mekanizması (JWT/OAuth2 paternleri) ve audit logları anlamına geliyor. Basit bir raporlama aracı için ERP’den toplu veri çekmek istediğimde, bu veriyi doğrudan veritabanından değil, belirli bir API gateway üzerinden, rate limiting’lere dikkat ederek ve özel bir kimlik doğrulama akışından geçerek almam gerekti. Bu süreç, basit bir prototip için öngördüğümün kat kat üzerinde zaman aldı.
# Kendi yan ürünümde basit veri çekme
import requests
response = requests.get("http://localhost:8000/api/production_orders")
orders = response.json()
print(f"Çekilen sipariş sayısı: {len(orders)}")
# Kurumsal ERP entegrasyonunda benzer bir işlem (basitleştirilmiş)
import requests
import jwt
# 1. OAuth2 token alımı
token_url = "https://erp.example.com/oauth/token"
client_id = "my_client_id"
client_secret = "my_client_secret"
auth_payload = {"grant_type": "client_credentials", "client_id": client_id, "client_secret": client_secret}
auth_response = requests.post(token_url, json=auth_payload)
access_token = auth_response.json().get("access_token")
# 2. Yetkilendirme ve Rate Limiting ile API çağrısı
headers = {"Authorization": f"Bearer {access_token}", "X-Correlation-ID": "my-app-123"}
api_url = "https://erp.example.com/api/v1/production_orders?page=1&limit=1000"
erp_response = requests.get(api_url, headers=headers)
if erp_response.status_code == 429:
print("Rate limit'e takıldık, bekle ve tekrar dene.")
elif erp_response.status_code == 200:
erp_orders = erp_response.json()
print(f"ERP'den çekilen sipariş sayısı: {len(erp_orders)}")
else:
print(f"Hata oluştu: {erp_response.status_code} - {erp_response.text}")Bu fark, basit bir fikri hayata geçirme hızı üzerinde doğrudan bir etkiye sahip. Kendi küçük projelerimde, bir sorun gördüğümde veya yeni bir özellik eklemek istediğimde, birkaç saat içinde deploy edip test edebiliyorum. Ancak ERP’nin getirdiği katı entegrasyon kuralları, bu esnekliği ciddi şekilde kısıtlıyor. Benim için “hızlıca bir şeyler yapma” yeteneği, bir nevi mesleki tatmin kaynağı. Bu engellerle karşılaşınca, motivasyonumun düştüğünü ve bazen iyi fikirlerin bile bürokrasiye kurban gittiğini hissettim.
Veri Erişimi ve Entegrasyon Zorlukları
ERP sistemlerinin en büyük sorunlarından biri, içerideki veriye erişimin zorluğudur. Kurumsal yazılım mimarisi genellikle veri bütünlüğünü ve güvenliğini ön planda tutar, bu da dışarıdan doğrudan erişimi kısıtlar. Bir yan ürünüm için, üretim süreçlerinden toplanan sensör verilerini kullanarak bir anomali tespit sistemi geliştirmek istediğimde, ERP’nin veritabanındaki ham verilere erişmek tam bir mücadeleye dönüştü. Doğrudan PostgreSQL’e bağlanmak yerine, ya karmaşık görünümler (views) üzerinden ya da belirli ETL (Extract, Transform, Load) süreçleri aracılığıyla veri almam gerekti.
Bu durum, veri modelinin esnek olmamasından da kaynaklanıyor. ERP’ler genellikle binlerce tablodan oluşan, birbirine sıkı sıkıya bağlı şemalar kullanır. Benim projem için yalnızca bir avuç alana ihtiyacım varken, bu veriye ulaşmak için çok sayıda tabloyu JOIN etmem ve karmaşık sorgular yazmam gerekti. Bu, hem sorgu performansını düşürüyor hem de geliştirme süresini uzatıyor. Bir keresinde, bir gecikmeli sevkiyat raporu için gerekli olan temel bilgiyi çekmek amacıyla yazdığım sorgu çok sayıda tabloyu birleştiriyordu ve büyük veri setinde belirgin şekilde yavaş çalışıyordu. Kendi sistemimde optimize edilmiş bir index stratejisi (B-tree/GIN/BRIN) ile aynı veriyi çok daha hızlı çekebileceğimi biliyordum.
Ayrıca, veri entegrasyonunda idempotency ve transaction outbox gibi paternler, ERP ortamında daha da kritik hale geliyor. Kendi sistemimde bir API çağrısı başarısız olduğunda basit bir retry mekanizması uygulayabilirken, ERP’ye veri yazarken, aynı işlemin birden fazla kez çalışmasını engellemek için çok daha detaylı senaryolar düşünmem gerekiyor. Bu da geliştirme ve test süreçlerini uzatıyor. Veri güvenliği de cabası; kernel module blacklist veya SELinux/AppArmor profilleri gibi güvenlik katmanları, harici bir uygulamanın ERP veritabanına doğrudan erişimini neredeyse imkansız hale getiriyor.
Teknolojik Bağımlılık ve Yenilik Hızı
ERP sistemleri genellikle belirli bir teknoloji yığını üzerinde inşa edilir ve bu yığın, uzun yıllar boyunca değişmeden kalabilir. Bu durum, özellikle yeni ve daha verimli teknolojileri kullanmak isteyen yan ürün geliştiricileri için ciddi bir kısıtlama oluşturur. Bir müşteri projesinde, üretim planlama için AI modelinin gerektirdiği son sürüm PostgreSQL özelliklerini kullanmak istediğimde, ERP’nin çalıştığı eski PostgreSQL 11 sürümü yüzünden bu mümkün olmadı. ERP’nin upgrade edilmesi, yüzlerce farklı modülün test edilmesini gerektiren, aylar sürecek bir projeydi ve benim küçük AI projem için bu kadar efor sarf etmek anlamsızdı.
Bu teknolojik bağımlılık, inovasyon hızını doğrudan etkiliyor. Yeni bir dil, bir framework veya bir veritabanı teknolojisi denemek istediğimde, ERP’nin ekosistemine uyum sağlamak zorunda kalıyorum. Kendi yan ürünlerimde Docker Compose ile hızlıca farklı veritabanlarını veya servisleri ayağa kaldırabilirken, ERP entegrasyonu için mevcut sanal makinelerin, network segmentasyonunun (VLAN segmentasyonu), firewall politikalarının ve hatta mevcut Linux servislerinin (systemd unit’leri) kısıtlamalarına uymak zorundayım. Bu durum, özellikle performans kritik uygulamalar için Redis’in OOM eviction policy seçimleri veya PostgreSQL’in WAL bloat sorunları gibi ince ayarlar yapma konusunda beni kısıtlıyor.
Bu, beni çoğu zaman “en iyi” çözümü değil, “ERP ile uyumlu” çözümü aramaya itiyor. Kendi mobil uygulamamda (bir Android spam blocker) Flutter ile native paket entegrasyonu yapıp, en son Play Store yayınlama süreçlerini deneyimlerken, kurumsal tarafta eski bir Java tabanlı ara katmana entegre olmak zorunda kalmak, aradaki teknolojik uçurumu net bir şekilde ortaya koyuyor. Bu tür durumlar, “Bu kadar eforla kendi sistemimi yapsam, daha iyi olmaz mıydı?” sorusunu akıllara getiriyor.
Operasyonel Yük ve Destek Maliyeti
Bir yan ürün geliştirirken, onu canlıya alma ve sonrasında bakımını yapma süreci de ERP standartlarından etkileniyor. Kendi sunucularımda (kendi VPS’imde) bir container orkestrasyonu (Docker Compose) ile uygulamalarımı saniyeler içinde deploy edebilirken, kurumsal bir ortamda bu süreç çok daha uzun ve zahmetli. CI/CD reliability sağlamak, blue-green veya canary deploy stratejileri uygulamak, feature flag’lerle dark launch yapmak gibi modern DevOps pratiklerini, ERP’nin katı değişim yönetim süreçleri ve test protokolleri nedeniyle uygulamak neredeyse imkansız hale geliyor.
Yan ürünümün bir bölümünü ERP’ye entegre ettiğimde, artık o bölümün operasyonel yükü de ERP’nin operasyon ekibine veya prosedürlerine tabi oluyor. Kendi sistemimde bir hata oluştuğunda journald loglarına bakıp cgroup limit’lerini kontrol edebilirken, ERP entegrasyonunda oluşan bir sorun için karmaşık destek süreçlerinden geçmem gerekiyor. Örneğin, bir API entegrasyonunda oluşan timeout sorunu için ERP’nin Nginx reverse proxy ayarlarını kontrol etme yetkim yok ve bu sorunu çözmek için günlerce beklemem gerekebiliyor.
Bu durum, yan ürünlerin veya özel çözümlerin “pahalı” veya “gereksiz” görülmesine neden olabilir. Çünkü ortaya çıkan operasyonel yük ve potansiyel destek maliyeti, projenin ilk yatırım getirisi hesaplamalarını olumsuz etkileyebilir. Kendi finansal hesaplayıcılarım veya görev yönetim uygulamam gibi yan ürünlerimde, bu tür operasyonel engeller olmadığı için, bir fikir aklıma geldiğinde birkaç saat içinde kodlayıp birkaç gün içinde canlıya alabiliyorum. Bu hız, kurumsal ortamda hayal bile edilemez. Bu da benim için kişisel bir özgürlük alanı yaratıyor.
Yan Ürünler İçin Bir Çözüm: Stratejik Ayrışma
Bu kadar olumsuzluktan bahsettikten sonra, peki ne yapıyorum? Benim yaklaşımım, ERP’nin gücünü ana iş süreçlerinde kullanırken, yan ürünler için stratejik bir ayrışma modeli benimsemek oldu. Yani, ERP’yi bir veri kaynağı ve ana işlem motoru olarak görüyorum, ancak esneklik gerektiren, hızlı iterasyon yapılması gereken yerlerde kendi “bounded context”lerimi oluşturuyorum.
Bu, genellikle şu şekilde işliyor:
- Veri Kopyalama ve Senkronizasyon: Kritik ERP verilerini, kendi yan ürünümün daha esnek bir veritabanına (örneğin, PostgreSQL’de özel partition stratejileriyle) kopyalıyorum. Bu kopyalama, ya event sourcing paternleriyle (ERP’den gelen olayları dinleyerek) ya da belirli periyotlarda çalışan ETL job’larıyla yapılıyor. Böylece, yan ürünüm ERP’nin karmaşık şemasından bağımsız kendi optimize edilmiş veri modelini kullanabiliyor.
- Asenkron Entegrasyon: ERP’ye veri yazmam gerektiğinde, bunu genellikle asenkron kuyruklar (message queues) üzerinden yapıyorum. Yan ürünüm, gerekli veriyi kuyruğa bırakıyor ve ERP entegrasyonu ayrı bir servis tarafından yürütülüyor. Bu, yan ürünün performanstan ödün vermeden çalışmasını sağlarken, ERP tarafındaki işlem yükünü de yönetilebilir kılıyor. Bir üretim ERP’sinde AI ile üretim planlama yaparken, önerilen planları doğrudan ERP’ye yazmak yerine, bir “plan onay” kuyruğuna atıyorduk. ERP’nin kendi entegrasyon servisi bu kuyruktan okuyup veriyi işliyordu. Bu sayede, AI modelinin tepki süresi ERP’nin entegrasyon hızına bağımlı olmuyordu.
- Mikroservis Yaklaşımı: Yan ürünlerimi genellikle mikroservis mimarisiyle geliştiriyorum. Her küçük fonksiyonellik ayrı bir servis olarak ayağa kalkıyor. Bu servisler kendi veritabanlarını kullanıyor ve ERP ile yalnızca ihtiyaç duydukları noktalarda, minimal API’ler veya mesajlaşma yoluyla iletişim kuruyorlar. Bu sayede, bir servis üzerinde yapılan değişiklikler diğerlerini etkilemiyor ve farklı teknoloji yığınları (örneğin, FastAPI, Golang, Node.js) rahatlıkla kullanılabiliyor.
- Observability ve Gözlem: Ayrışık sistemlerin en büyük zorluğu, bütünsel bir resim elde etmek olabilir. Bu yüzden, tüm yan ürünlerimde güçlü bir observability (metrik, log, trace) altyapısı kuruyorum. Prometheus ile metrikleri topluyor, Loki ile logları merkezi bir yerde tutuyor ve Jaeger ile distributed tracing yapıyorum. Bu sayede, bir sorun çıktığında “Hangi servis ERP ile konuşurken hata aldı?” sorusunun cevabını hızlıca bulabiliyorum. Daha önce bir dağıtık sistemde routing flap sorunu yaşadığımda, BGP routing decisions’ı anlamak için bu tür bir izleme hayati olmuştu.
Bu yaklaşım, elbette beraberinde kendi zorluklarını getiriyor: veri tutarlılığı riskleri, daha fazla dağıtık sistem yönetimi yükü ve potansiyel güvenlik boşlukları. Ancak benim için, kurumsal ERP’nin sunduğu sağlamlığı temel iş süreçlerinde korurken, yan ürünlerimin esnekliğini ve inovasyon hızını kaybetmemek adına bu trade-off’u göze almaya değer. Kendi anonim Türkiye veri platformumda veya Android spam uygulamamda bu ayrışmanın faydalarını net bir şekilde görüyorum.
Sonuç
ERP standardizasyonu, büyük organizasyonlar için vazgeçilmez bir istikrar ve verimlilik kaynağıdır. Ancak bu yapı, hızlı prototipleme, teknolojik yenilik ve esnek veri erişimi arayan yan ürünler için ciddi kısıtlamalar getirebilir. Benim deneyimime göre, bu bir “ya o, ya bu” durumu değil, akıllıca yönetilmesi gereken bir trade-off.
Benim kişisel felsefem, kurumsal dünyanın güçlü ve yavaş gemisini, kendi küçük ve hızlı botlarımla desteklemek üzerine kurulu. Temel ve kritik iş süreçleri ERP’de standart ve güvenli bir şekilde akarken, niş ihtiyaçlarımı ve inovatif fikirlerimi kendi ayrı, esnek ve hızlı geliştirilebilen sistemlerimde hayata geçiriyorum. Bu dengeyi bulmak, hem kurumsal sorumluluklarımı yerine getirmemi sağlıyor hem de teknolojiye olan tutkumu ve “bir şeyler yapma” arzumuzu besliyor. Özetle, ERP standardizasyonu esnekliği azaltır, ama bu esneklik kaybının yan ürünlere olan etkisini doğru mimari ve stratejik ayrışma ile yönetmek mümkün. Bu, benim için kariyerimin bir parçası haline gelmiş, sürekli öğrenmeyi ve adapte olmayı gerektiren bir yolculuk.