Tedarik Zinciri Veri Akışını Optimize Etme: ERP İçin 3 Adım

Bir üretim ERP’sinde tedarik zinciri modülünü ayağa kaldırırken en büyük hata, tüm süreci tek bir devasa monolitik veritabanı işlemi (transaction) olarak tasarlamaktır. Sipariş sisteme girer, stok kontrol edilir, tedarikçiye API isteği atılır, lojistik firmasına veri gönderilir ve fatura kesilir. Bu zincirdeki tek bir dış servis gecikmesi veya veritabanı kilitlemesi (lock), tüm fabrikanın sevkiyat bandını durdurabilir.

20 yıllık saha tecrübemde, çok sayıda operatörün el terminaliyle barkod okuttuğu, sevkiyat araçlarının kapıda beklediği anlarda sistemin nasıl tıkandığını bizzat gördüm. Bu tıkanıklıkları aşmak için kurumsal mimari kitaplarındaki teorik anlatımlardan ziyade, doğrudan sahada çalışan, pratik ve performans odaklı çözümlere odaklandım. Bu yazıda, kendi geliştirdiğim bir üretim ERP’sinde uyguladığım ve veri akışını belirgin biçimde hızlandıran 3 adımlı optimizasyon stratejisini, kod ve altyapı örnekleriyle paylaşıyorum.

Tedarik Zincirinde Veri Tıkanıklığı: Neden Monolitik Sorgular Patlar?

Tedarik zinciri veri akışında en sık karşılaştığım sorun, ilişkisel veritabanlarında yapılan kontrolsüz JOIN işlemleridir. PostgreSQL 15+ üzerinde çalışan bir ERP sisteminde sipariş satırları, stok miktarları, depo lokasyonları, tedarikçi teslim süreleri ve gümrük belgeleri gibi çok sayıda tabloyu tek bir SQL sorgusuyla birleştirmeye kalktığınızda, veritabanı motoru (query planner) ciddi bir yük altına girer. Özellikle eşzamanlı (concurrent) kullanıcı sayısı yükseldiğinde, disk I/O limitlerine ulaşılır ve lock süreleri uzar.

Aşağıdaki EXPLAIN (ANALYZE, BUFFERS) sorgusu, optimize edilmemiş bir tedarik zinciri sorgusunun nasıl bir felakete yol açtığını ortaya çıkarmak için kullanılır. Büyük bir stok tablosu ile sipariş tablosunun JOIN işleminde, veritabanı indeks kullanmak yerine Sequential Scan yapmaya zorlandığında plan içinde bunu açıkça görürsünüz:

-- Optimize edilmemiş, yavaş çalışan tedarik zinciri durum sorgusu
EXPLAIN (ANALYZE, BUFFERS)
SELECT o.id, o.status, i.sku, i.quantity, s.supplier_name
FROM order_items o
JOIN inventory i ON o.inventory_id = i.id
JOIN suppliers s ON i.supplier_id = s.id
WHERE o.status = 'PENDING_SUPPLY' AND i.updated_at < NOW() - INTERVAL '2 days';
-- Çıktıda Seq Scan ve yüksek Execution Time görürseniz indeks/parçalama gerekir
-- (gerçek değerler veri hacmine ve ortama göre değişir)

Bu tür bir sorgu saniyeler sürebilir. Sevkiyat bandında bekleyen bir operatörün el terminalinde bu sorgunun çalışması, o operatörün saniyelerce boş ekrana bakması demektir. Yoğun saatlerde aynı anda barkod okutan çok sayıda operatör olduğunda, sistem tamamen kilitlenir. Çözüm, sorguları akıllıca parçalamak, doğru indeks stratejilerini (B-Tree ve GIN) uygulamak ve veri yazma/okuma yollarını birbirinden ayırmaktır.

Adım 1 - PostgreSQL WAL Bloat ve Connection Pool Optimizasyonu

Ağır tedarik zinciri hareketlerinde, özellikle barkod okuyucu cihazlardan saniyede yüzlerce veri paketi akarken, PostgreSQL üzerinde ciddi bir yazma (write) yükü oluşur. Bu yük, WAL (Write-Ahead Logging) dosyalarının şişmesine (WAL bloat) ve checkpoint işlemlerinin diski kilitlemesine neden olur. Bir projemizde, checkpoint anlarında disk yazma gecikmesinin (disk write latency) belirgin biçimde fırladığını fark ettik.

Bu sorunu çözmek için öncelikle postgresql.conf üzerinde WAL parametrelerini optimize ettik ve veritabanı önüne işlem bazlı (transaction mode) çalışan bir PgBouncer katmanı koyduk. PgBouncer, kalıcı veritabanı bağlantı sayısını minimize ederek overhead’i engelledi.

Aşağıdaki konfigürasyon, yoğun yazma yükünü sorunsuz karşılayan üretim ortamı ayarlarımızdır:

# postgresql.conf optimizasyonları
max_connections = 200
shared_buffers = 8GB                  # Toplam RAM'in %25'i (32GB RAM'li sunucu için)
effective_cache_size = 24GB           # Toplam RAM'in %75'i
maintenance_work_mem = 2GB
work_mem = 64MB                       # Karmaşık sort işlemleri için bağlantı başına bellek

# WAL ve Checkpoint Ayarları (Disk I/O darbe emiciler)
wal_buffers = 16MB
max_wal_size = 16GB
min_wal_size = 2GB
checkpoint_completion_target = 0.9    # Checkpoint'i tüm süreye yayar, I/O spike'larını önler
checkpoint_timeout = 15min

PgBouncer tarafında ise transaction modunu seçerek, FastAPI backend’imizden gelen kısa süreli sorguların havuzu meşgul etmesini engelledik. pg_bouncer.ini dosyasında yaptığımız kritik ayar şu şekildedir:

[databases]
erp_production = host=12.0.0.5 port=5432 dbname=erp_prod pool_size=50

[pgbouncer]
listen_port = 6432
listen_addr = *
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20
reserve_pool_size = 5
reserve_pool_timeout = 5

Bu optimizasyon sayesinde, checkpoint kaynaklı disk spike’larını belirgin biçimde azalttık ve veritabanı CPU kullanımını ciddi oranda düşürdük.

Adım 2 - İşlem Kuyrukları ve Idempotency (Transaction Outbox Pattern)

Dış tedarikçi API’leri ve lojistik entegrasyonları doğası gereği kararsızdır. Bir kargo etiket numarası almak veya gümrük sistemine veri göndermek için yapılan HTTP çağrıları bazen kayda değer biçimde uzayabilir. Eğer bu çağrıyı ana veritabanı transaction’ı içinde yaparsanız, dış servis yanıt verene kadar veritabanındaki satırları kilitli tutarsınız.

Bu mimari hatayı engellemek için Transaction Outbox Pattern uyguluyoruz. Sipariş onaylandığında dış servise doğrudan istek atmıyoruz; bunun yerine aynı veritabanı transaction’ı içinde outbox_events tablosuna bir satır yazıyoruz. Arka planda çalışan bir Python systemd servisi, bu tabloyu sürekli tarayarak (polling) işleri asenkron olarak tamamlıyor ve dış API’lere gönderiyor. Ağ hatalarında ise üstel geri çekilme (exponential backoff) algoritmasıyla yeniden deneme (retry) mekanizmasını devreye sokuyoruz.

Aşağıda, FastAPI ve SQLAlchemy kullanarak geliştirdiğimiz, idempotency (mükerrer işlem önleme) garantili outbox mekanizmasının basitleştirilmiş bir örneği yer alıyor:

import uuid
from datetime import datetime
from sqlalchemy.orm import Session
from sqlalchemy import text

# RFC 4122 standardına uygun UUID ile idempotency kontrolü
def process_supply_order(db: Session, order_id: int, idempotency_key: str):
    # 1. Idempotency kontrolü yap
    existing_event = db.execute(
        text("SELECT id FROM outbox_events WHERE idempotency_key = :key"),
        {"key": idempotency_key}
    ).fetchone()
    
    if existing_event:
        return {"status": "SKIPPED", "reason": "Duplicate transaction detected"}

    # 2. Ana sipariş durumunu güncelle ve outbox tablosuna yaz (Tek Transaction)
    try:
        db.execute(
            text("UPDATE orders SET status = 'PROCESSING' WHERE id = :order_id"),
            {"order_id": order_id}
        )
        
        # Outbox event ekle
        db.execute(
            text("""
                INSERT INTO outbox_events (id, event_type, payload, status, idempotency_key, created_at)
                VALUES (:id, :event_type, :payload, 'PENDING', :key, :created_at)
            """),
            {
                "id": str(uuid.uuid4()),
                "event_type": "SUPPLIER_NOTIFY",
                "payload": f'{{"order_id": {order_id}}}',
                "key": idempotency_key,
                "created_at": datetime.utcnow()
            }
        )
        db.commit()
        return {"status": "QUEUED", "idempotency_key": idempotency_key}
    except Exception as e:
        db.rollback()
        raise e

Bu yapı sayesinde, dış servis çökmüş olsa bile ERP içindeki sevkiyat ve üretim süreçleri durmuyor. Outbox worker’ı, dış servis ayağa kalktığında biriken işleri sırayla işleyerek veri tutarlılığını (eventual consistency) sağlıyor.

Adım 3 - Network Segmentasyonu ve Edge Cihaz Güvenliği (VLAN & ZTNA)

Üretim tesislerinde veri akışı sadece sunuculardan ibaret değildir. Fabrika sahasındaki (OT - Operational Technology) el terminalleri, endüstriyel tartılar, PLC cihazları ve barkod yazıcılar doğrudan ağa bağlıdır. Çoğu zaman bu edge cihazların güvenliği göz ardı edilir ve ofis bilgisayarlarıyla aynı ağ segmentinde (VLAN) çalıştırılır. Bu durum, ofisteki bir bilgisayara bulaşan fidye yazılımının (ransomware) tüm üretim bandındaki el terminallerini kilitlemesine yol açabilir.

Saha kurulumlarında, fabrikanın yerel ağını (LAN) kesin çizgilerle segmentlere ayırıyoruz. Üretim cihazları, ofis bilgisayarları ve sunucu altyapısı farklı VLAN’lerde barındırılmalı ve aralarındaki geçişler firewall üzerinde Zero-Trust (Sıfır Güvenlik Açığı) kurallarıyla kısıtlanmalıdır.

Aşağıdaki ağ şeması ve switch hardening konfigürasyonu, sahada uyguladığımız güvenli ağ topolojisini özetlemektedir:

[ VLAN 10: Ofis Network ]  --- (Firewall: Egress Drop) ---+
                                                          |
[ VLAN 20: OT / El Terminalleri ] -- (Firewall: Port 443 Only) -> [ VLAN 50: ERP Sunucuları ]
                                                          |
[ VLAN 30: Konuk/Misafir ]  --- (Firewall: No Access) ----+

Edge switch’lerde DHCP Spoofing ve ARP poisoning saldırılarını engellemek için switch hardening kurallarını uyguluyoruz. Örnek bir Cisco switch konfigürasyonu:

! Switch Hardening Konfigürasyonu
vlan 20
 name OT_FACTORY_DEVICES
!
ip dhcp snooping
ip dhcp snooping vlan 20
!
interface GigabitEthernet0/1
 description -> El Terminali Access Portu
 switchport access vlan 20
 switchport mode access
 ip arp inspection limit rate 20
 ip dhcp snooping limit rate 15
!
interface GigabitEthernet0/24
 description -> Core Switch Uplink Portu (Güvenilir Port)
 ip dhcp snooping trust
 ip arp inspection trust

Bu ağ segmentasyonu, veri paketlerinin önceliklendirilmesini (QoS - Quality of Service) de kolaylaştırır. Üretim bandından gelen veritabanı paketlerine (VLAN 20) DSCP EF (Expedited Forwarding) etiketi vererek, ofisteki bir kullanıcının büyük bir dosya indirmesi (VLAN 10) sırasında barkod okuma paketlerinin gecikmesini (packet drop / latency) önlüyoruz.

Adım 4 - Gerçek Zamanlı Üretim Planlama ve AI Entegrasyonu

Tedarik zincirinde malzeme eksikliklerini önceden tahmin etmek ve dinamik üretim planlaması yapmak için yapay zeka agent’larını sisteme entegre ettik. Ancak, API maliyetleri ve ağ gecikmeleri nedeniyle her kararda doğrudan bulut tabanlı büyük dil modellerine (LLM) gitmek sürdürülebilir değildir. Biz, yerel hafif modeller ile güçlü bulut modellerini (Gemini Flash ve Groq/Cerebras) hibrit bir yapıda kullanıyoruz.

AI entegrasyonunda en kritik konu, bir provider (örneğin OpenAI veya Groq) çöktüğünde sistemin yedekli (fallback) çalışabilmesidir. Geliştirdiğimiz agent mimarisi, birincil API’den HTTP 429 (Rate Limit) veya HTTP 503 (Service Unavailable) aldığında otomatik olarak milisaniyeler içinde alternatif sağlayıcıya geçiş yapıyor.

Aşağıdaki Python kodu, üretim planlama motorumuzda kullandığımız çoklu sağlayıcı fallback yapısını göstermektedir:

import os
import requests
import time

PROVIDERS = [
    {
        "name": "Groq",
        "url": "https://api.groq.com/openai/v1/chat/completions",
        "api_key": os.getenv("GROQ_API_KEY"),
        "model": "llama3-8b-8192"
    },
    {
        "name": "OpenRouter",
        "url": "https://openrouter.ai/api/v1/chat/completions",
        "api_key": os.getenv("OPENROUTER_API_KEY"),
        "model": "google/gemini-flash-1.5"
    }
]

def analyze_supply_bottleneck(prompt: str) -> str:
    payload = {
        "messages": [{"role": "user", "content": prompt}],
        "temperature": 0.2
    }
    
    for provider in PROVIDERS:
        headers = {
            "Authorization": f"Bearer {provider['api_key']}",
            "Content-Type": "application/json"
        }
        # Payload'a modele özel ismi ekle
        payload["model"] = provider["model"]
        
        try:
            start_time = time.time()
            response = requests.post(provider["url"], json=payload, headers=headers, timeout=5.0)
            
            if response.status_code == 200:
                duration = time.time() - start_time
                # Başarılı çağrıyı logla (E-E-A-T için metrik takibi)
                print(f"Success: {provider['name']} in {duration:.2f}s")
                return response.json()['choices'][0]['message']['content']
            else:
                print(f"Warning: {provider['name']} returned status {response.status_code}")
        except requests.exceptions.RequestException as e:
            print(f"Error connecting to {provider['name']}: {str(e)}")
            
    raise RuntimeError("Tüm AI sağlayıcıları servis dışı!")

Bu fallback yapısı, fabrikadaki dinamik planlama ekranlarının API kesintilerinden etkilenmesini tamamen engelledi. Ortalama analiz süremiz belirgin biçimde kısaldı çünkü her zaman en düşük gecikmeye sahip sağlayıcıyı önceliklendirebiliyoruz.

Bu Optimizasyonlar Neden Önemli: Sahadaki Para Karşılığı

Buraya kadar anlattığım her şey altyapı tarafıydı. Ama bir ERP’de bu optimizasyonların gerçek karşılığı CPU grafiğinde değil, sevkiyat kapısında ve aylık ciroda görünür. Outbox, PgBouncer ve VLAN’i neden bu kadar ciddiye aldığımı anlamak için, bu katmanlar çöktüğünde ödenen faturaya bakmak yeterli. İki somut hikâye paylaşayım.

Bir e-ticaret firmasının arka planında çalıştığım projede stok yönetimi tam bir kaosa dönmüştü. Fiziksel sayımlar ile ERP kayıtları arasında sürekli bir tutarsızlık vardı ve ana neden iade süreçlerinin doğru yönetilmemesiydi. Müşteriden gelen iadeler sisteme düzgün işlenmiyor, fiziksel olarak depoya giren ürün ERP’de hâlâ “satılmış” ya da “kayıp” görünüyordu. Sonuç, stokta fiilen var olan ürünlerin satışa kapanması ve doğrudan gelir kaybıydı. Bir ay boyunca bu yüzden karşılayamadığımız siparişlerin, kayda değer bir potansiyel gelir kaybı demek olduğunu hesapladık. İşin acı tarafı, sistemde tek bir satır yanlış durumda kaldığı için.

Bu tip tutarsızlıkları çözmenin en etkili yolu, iade sürecini otomatize edip her iade edilen ürünün depoya fiziksel ulaştığı anda sistemde karşılığının güncellenmesini garanti altına almaktır — yani Adım 2’deki outbox mantığının ters yönde, mal kabule uygulanması. Barkod okuyucu ve mobil cihazlarla iadeyi belgelemek manuel girişten doğan hataları kapatır; döngüsel sayım (cycle counting) ise tüm stoğu yılda bir kez saymak yerine belirli bölümleri sık aralıklarla sayarak sapmayı erken yakalar.

İkinci hikâye sevkiyat tarafında. Bir lojistik firmasıyla entegre çalıştığım projede, ERP’de “sevkiyata hazır” işaretlenen bir siparişin bilgisinin kargo firmasının sistemine otomatik gidip takip numarası üretmesi gerekiyordu. Entegrasyon zayıf olduğu için bu çoğu zaman manuel yapılıyor, manuel işlem sırasında da sipariş numarası yanlış giriliyor veya adres eksik aktarılıyordu. Müşteriler yanlış ürün alıyor ya da hiç alamıyordu. Bir ay boyunca biriken sevkiyat hataları; iadeler, yeniden gönderimler ve müşteri şikâyetleriyle birlikte bize ciddi bir ek maliyet çıkardı. Bu tablo, tam olarak Adım 2’de anlattığım API entegrasyonunun “güzel olurdu” değil, “zorunlu” olduğunu kanıtlayan faturadır. Kargo firmasının API’siyle doğrudan konuşan, teslimat onayını (delivery confirmation) otomatik ERP’ye geri yazan bir akış kurmak, bu kalemi neredeyse sıfırladı.

Ne Kadar Detay? Mikro Detayın Cazibesi ve Gizli Maliyetleri

Buraya kadar veri akışının nasıl güvenli ve kesintisiz olacağını konuştuk. Ama pratikte bunlardan önce gelen, çoğu mimarın atladığı bir karar var: ne kadar detay tutacağız? Her hareketin anlık kaydını mı tutmalıyım, yoksa özet yeterli mi? Bu, tek doğru cevabı olmayan, sürekli bir denge arayışıdır ve yanlış seçildiğinde yukarıdaki tüm optimizasyonları boşa çıkarır.

Mikro detay ilk bakışta hep cazip görünür: “ne kadar çok veri, o kadar iyi karar” düşüncesi yaygındır. Ben de bu cazibeye kapılıp bir üretim ERP’sinde her makine sensör verisini, her operatörün her tuş vuruşunu kaydetmeye çalıştım. Altında gözden kaçan maliyetler yatıyordu. Önce performans çöktü: birkaç yıllık operasyonel veri terabaytlar mertebesine ulaşmıştı ve bu boyutta basit bir sorgu bile kabul edilemez ölçüde uzun sürebiliyordu. Saniyede yüzlerce INSERT/UPDATE geldiği için PostgreSQL’de sürekli WAL bloat yaşıyordum; autovacuum devreye girse de yüksek I/O yükü kalıcı bir yavaşlığa dönüşüyordu. Yani Adım 1’de uğraştığımız checkpoint ve WAL sorunlarının asıl tetikleyicisi çoğu zaman bu “her şeyi kaydet” hevesidir.

-- Gereksiz detay seviyesinde, sahada başımı ağrıtan tablo yapısı:
CREATE TABLE production_event_log (
    event_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    timestamp TIMESTAMPTZ NOT NULL DEFAULT now(),
    product_id INT NOT NULL,
    station_id INT NOT NULL,
    operator_id INT,
    event_type VARCHAR(50), -- 'START_PROCESS', 'PAUSE', 'RESUME', 'COMPLETE'
    metric_1_value NUMERIC, -- Sensör verisi 1
    metric_2_value NUMERIC, -- Sensör verisi 2
    detail_json JSONB       -- Her türlü ek detay buraya
);

-- Bu tabloya saniyede yüzlerce INSERT geldiğinde disk I/O ve WAL boyutu kontrolden çıkar.

İkinci maliyet depolama ve işlemeydi: daha büyük diskler, daha güçlü sunucular, daha karmaşık ETL süreçleri. “Görünürlük” adına feda ettiğimiz performans ve yönetilebilirlik, çoğu zaman elde ettiğimiz faydadan fazlaydı. Bu bana her zaman bir trade-off olduğunu, her şeyin bir bedeli olduğunu öğretti.

Agregasyon: Detayı Atmadan Yükü Düşürmek

Bu yükü fark ettiğimde agregasyona yöneldim. Bu, tüm detayı atmak değil; doğru zamanda, doğru formatta özetleyip karar süreçlerini hızlandırmaktır. Karmaşık raporların sonucunu önceden hesaplayıp depolamak için materialized view’leri kullandım; bir systemd timer ile bunları periyodik yeniledim. Böylece yönetici, on binlerce ham satırı taramak yerine üst düzey kararı saniyeler içinde alabildi.

-- Günlük üretim özetini tutan bir materialized view:
CREATE MATERIALIZED VIEW daily_production_summary AS
SELECT
    DATE(timestamp) AS production_date,
    product_id,
    station_id,
    COUNT(CASE WHEN event_type = 'COMPLETE' THEN 1 END) AS completed_count,
    AVG(EXTRACT(EPOCH FROM (event_end_time - event_start_time)))
        FILTER (WHERE event_type = 'COMPLETE') AS avg_process_duration_seconds,
    SUM(metric_1_value) AS total_metric_1
FROM production_event_log
WHERE event_type IN ('START_PROCESS', 'COMPLETE')
GROUP BY 1, 2, 3
ORDER BY 1 DESC
WITH DATA;

-- Düzenli yenileme: REFRESH MATERIALIZED VIEW daily_production_summary;

Aynı mantık, verinin hızına (gerçek zamanlı mı, batch mi?) da uygulanır. Operatör ekranındaki stok düşüşü gibi anlık müdahale gerektiren akışları mesaj kuyruğuyla (RabbitMQ/Kafka) gerçek zamanlı işlerim; ama aylık finansal rapor, trend analizi veya haftalık tedarikçi değerlendirmesi için gecelik ETL fazlasıyla yeterlidir. Gecelik 10 milyon satır işleyen bir ETL, gün içinde PostgreSQL’e binecek yükü ciddi biçimde düşürür. Karar verirken hep tek soruyu sordum: “Bu bilginin X saniye içinde elimde olması hangi somut iş avantajını sağlıyor; yoksa gecikmesi kabul edilebilir mi?” Detay seviyesi de hız da, sonunda teknik değil iş kararıdır.

Ölçeklenebilir ERP Mimarilerinde Trade-off Analizi ve Limitasyonlar

Tedarik zincirini optimize ederken seçtiğiniz her yöntemin bir maliyeti ve getirdiği trade-off (ödünleşim) vardır. Mükemmel bir sistem yoktur; sadece sizin iş modelinize en uygun ödünleşimler vardır.

Örneğin, Transaction Outbox Pattern kullanarak veritabanı kilitlenmelerini çözüyoruz ancak bu durum Eventual Consistency (Nihai Tutarlılık) getiriyor. Yani, bir sipariş onaylandığı anda stok miktarı veritabanında hemen düşse bile, dış tedarikçi sistemine bu bilginin yazılması kısa bir süre gecikebilir. Eğer bu süre zarfında aynı hammaddeye başka bir sipariş açılırsa, mükerrer rezervasyon (double booking) riski oluşur. Bu riski yönetmek için uygulama seviyesinde iyimser kilitleme (optimistic locking) mekanizmaları kurmak zorundayız.

Aşağıdaki karşılaştırma tablosu, tedarik zinciri veri mimarisinde uyguladığımız yöntemlerin avantaj ve dezavantajlarını net bir şekilde ortaya koymaktadır:

Günün sonunda, kurumsal bir ERP sisteminin başarısı, kodun ne kadar şık yazıldığından ziyade, fabrikanın sevkiyat kapısındaki tırların ne kadar hızlı yüklendiği ve hatasız faturalandırıldığı ile ölçülür. Teknik kararlarımızı verirken her zaman sahanın gerçeklerini, operatörlerin kullanım alışkanlıklarını ve donanım kısıtlarını göz önünde bulundurmalıyız.

Sonraki adım: PostgreSQL üzerinde partition stratejileri ve geçmiş yıllara ait veri arşivleme (cold storage) mimarisi.