Ağır Sanayi ve Üretim Şirketlerinde B2B Portal ve Üretim Takip Yazılımı

Ağır sanayi ve üretim şirketlerinde bir siparişin alınması, yalnızca ürün ve miktarın kaydedilmesi anlamına gelmez. Müşteriye özel fiyatlar, teknik özellikler, termin koşulları, üretim kapasitesi, hammadde durumu, kalite kontrolleri, paketleme ve sevkiyat planı aynı sürecin parçalarıdır. Bu bilgiler e-posta, telefon, Excel dosyaları ve farklı departmanların kullandığı uygulamalar arasında dağıldığında hem müşterinin doğru bilgiye ulaşması hem de ekiplerin ortak bir durumu takip etmesi zorlaşır.

B2B portal ve üretim takip yazılımı, bu dağınık trafiği ERP ile bağlantılı tek bir dijital yapıda birleştirir. Bayi veya kurumsal müşteri siparişini oluşturabilir; satış ekibi ticari koşulları yönetebilir; üretim, depo ve sevkiyat ekipleri kendi görevlerini güncelleyebilir. Yönetim ise siparişin hangi aşamada olduğunu, gecikme ve istisnaları ortak göstergeler üzerinden izleyebilir. Buradaki amaç ERP’nin yerine yeni bir sistem koymak değil, kurum içi veriyi görev odaklı deneyimlere dönüştürmektir.

B2B portal ve üretim takip yazılımı neden birlikte ele alınmalıdır?

Müşteriye yalnızca sipariş formu sunan bir portal, sipariş ERP’ye aktarıldıktan sonra görünürlüğünü kaybedebilir. Üretim takibi ise müşteriden ve satış ekibinden kopuk tasarlandığında operasyonel kayıtları gösterir fakat ticari bağlamı açıklayamaz. İki yapının birlikte planlanması; sipariş numarası, sipariş satırı, üretim emri, parti veya seri, sevkiyat ve belge arasındaki ilişkinin korunmasını sağlar.

Uluslararası ISA-95 kurumsal sistem ve üretim kontrolü entegrasyonu yaklaşımı, işletme süreçleri ile üretim operasyonları arasındaki bilgi alışverişini katmanlar ve ortak modeller üzerinden ele alır. Portal projesinde bu yaklaşımın pratik karşılığı, her verinin kaynağını ve sahibini belirlemektir. Örneğin cari risk ve sözleşmeli fiyat ERP’den, operasyon bildirimi üretim sisteminden, teslimat olayı ise depo veya lojistik kaynağından gelebilir.

Doğru mimari, kullanıcıya bütün bu kaynakların teknik ayrıntılarını göstermez. Bunun yerine “onay bekliyor”, “üretimde”, “kalite kontrolde”, “kısmen sevk edildi” veya “teslim edildi” gibi anlaşılır durumlar sunar. Bunun nasıl kurgulanabileceğine ilişkin daha ayrıntılı bir çerçeve için B2B sipariş takip portalı planlama rehberi de incelenebilir.

Siparişten teslimata uçtan uca dijital akış

Üretim şirketlerinde tek bir genel durum alanı çoğu zaman yeterli değildir. Aynı siparişin bazı satırları stoktan karşılanabilir, bazıları üretime açılabilir ve bir bölümü farklı tarihlerde sevk edilebilir. Bu nedenle akış, sipariş başlığının yanında satır, miktar ve teslimat dilimi düzeyinde modellenmelidir.

1. Sipariş oluşturma ve doğrulama

Portal; müşterinin yetkili ürün listesini, fiyatını, ödeme koşulunu, teslimat adresini ve sipariş limitini ERP veya ilgili ana veri kaynağından almalıdır. Minimum miktar, ambalaj katı, teknik uyumluluk ve zorunlu belge gibi kurallar daha sipariş gönderilmeden kontrol edilmelidir. Böylece hatalı kayıtların departmanlar arasında dolaşması önlenir.

2. Ticari ve operasyonel onay

Standart dışı iskonto, vade, miktar, teslim tarihi ya da teknik özellik içeren talepler otomatik olarak ilgili onay akışına yönlendirilebilir. Rol, tutar, müşteri grubu, ürün ailesi ve vekâlet koşulları birlikte değerlendirilmeli; karar, açıklama ve zaman bilgisiyle kaydedilmelidir. Ayrıntılı kurgu için B2B siparişlerde onay akışı içeriği yol gösterici olabilir.

3. Üretim planı ve gerçekleşen ilerleme

Sipariş kabul edildiğinde ilgili üretim emirleriyle bağ kurulmalıdır. Ancak müşteriye tezgâh veya iş merkezi düzeyindeki ham kayıtları açmak yerine, güvenilir ve iş açısından anlamlı kilometre taşları gösterilmelidir. Planlandı, malzeme bekliyor, üretime başladı, kalite kontrolde ve tamamlandı gibi durumların hangi olayla oluşacağı önceden tanımlanmalıdır.

4. Stok, hazırlama ve kısmi sevkiyat

Üretilen veya stoktan ayrılan miktar, sipariş edilen miktardan farklı olabilir. Portal; hazır, rezerve, sevk edilen ve kalan miktarları birbirine karıştırmadan göstermelidir. Müşterinin kısmi sevkiyatı kabul edip etmediği, teslimatların birleştirilip birleştirilmeyeceği ve kalan miktarın tahmini tarihi de akışın parçası olmalıdır.

5. Belge, teslimat ve kapanış

İrsaliye, fatura, kalite sertifikası, analiz raporu, paketleme listesi veya menşe belgesi doğru sipariş ve sevkiyatla ilişkilendirilmelidir. Yetkili kullanıcı, kendisine ait güncel belgeyi güvenli biçimde indirebilmelidir. Teslim teyidi, itiraz veya eksik teslimat kaydı tamamlandığında süreç denetlenebilir bir kapanışa ulaşır.

ERP entegrasyonunda veri sahipliği ve durum modeli

Entegrasyonun ilk sorusu “Hangi API kullanılacak?” değil, “Hangi bilginin doğru kaynağı hangi sistem?” olmalıdır. Cari kart, kredi limiti, fiyat, ürün ve resmi sipariş kaydı ERP’nin sorumluluğunda kalabilir. Üretim gerçekleşmeleri MES veya başka bir operasyon sisteminden gelebilir. Portal ise kimlik, yetki, kullanıcı deneyimi, bildirim, açıklama ve müşteri etkileşimlerini yönetebilir.

Her veri nesnesi için sahip sistem, benzersiz anahtar, güncelleme yönü, sıklık ve hata davranışı belirlenmelidir. Entegrasyon geçici olarak kesildiğinde aynı siparişin iki kez oluşmasını engelleyen güvenli tekrar mekanizması gerekir. Başarısız kayıtlar görünür bir hata kuyruğuna alınmalı; yeniden deneme, düzeltme ve sorumlu atama adımları tanımlanmalıdır.

• Sipariş, satır, üretim emri ve sevkiyat için kalıcı ilişki anahtarları kullanılmalıdır.
• Planlanan tarih ile teyit edilen tarih ayrı alanlarda tutulmalıdır.
• Durum değişikliğinin kaynağı, zamanı ve önceki değeri kaydedilmelidir.
• İptal, revizyon ve miktar değişikliği normal akıştan ayrı kurallarla yönetilmelidir.
• Müşteriye gösterilecek bilgi, iç operasyon verisinden ayrı bir görünürlük politikasıyla belirlenmelidir.

Bu model, entegrasyonu yalnızca veri taşıyan bir bağlantı olmaktan çıkarır. Portalın gösterdiği her durum açıklanabilir, geriye dönük incelenebilir ve sorumlu sistemle mutabık hâle gelir.

Rol bazlı görünürlük ve yönetim paneli

Aynı sipariş farklı kullanıcılar için farklı anlam taşır. Bayi satın alma sorumlusu fiyat, termin ve belgeyi; satış temsilcisi müşteri talebini ve ticari istisnaları; üretim planlama kapasite ve malzeme etkisini; depo hazırlanacak miktarı; finans ekibi risk ve ödeme koşulunu görmek ister. Yönetim ise ayrıntı içinde kaybolmadan darboğazları izlemelidir.

Yetkilendirme yalnızca menü saklamaya indirgenmemelidir. Kullanıcının hangi şirketi, tesisi, siparişi, fiyat alanını, belge türünü ve işlemi görebileceği ayrı ayrı tanımlanmalıdır. Rol tabanlı kurallar gerektiğinde müşteri, bölge, ürün grubu veya organizasyon birimi kapsamıyla daraltılabilir. Vekâletlerin başlangıç ve bitiş tarihi olmalı; kritik işlemler ek doğrulama ya da ikinci onay gerektirebilmelidir.

Yönetim paneli ise işlem listesi olmanın ötesine geçmelidir. Onayda bekleyen siparişler, geciken üretim aşamaları, entegrasyon hataları, kısmi sevkiyatlar, belge eksikleri ve müşteriye verilen termin değişiklikleri ayrı çalışma kuyruklarında sunulabilir. Her kuyrukta sorumlu, bekleme süresi, öncelik ve sonraki eylem görünmelidir.

İzlenebilirlik, belge yönetimi ve müşteri görünürlüğü

İzlenebilirlik, sadece ekranda bir zaman çizelgesi göstermek değildir. Bir ürünün hangi siparişe, üretim partisine, kalite kaydına ve sevkiyata bağlı olduğunun kanıtlanabilmesidir. GS1 Küresel İzlenebilirlik Standardı; nesnelerin tanımlanması, olayların yakalanması ve verinin paylaşılması için uçtan uca bir yaklaşım tarif eder. Portal tasarımında bu bakış, “ne, nerede, ne zaman ve neden” sorularını cevaplayan olay kayıtlarına dönüştürülebilir.

Müşteriye her iç durumun açılması doğru değildir. Operatör notları, maliyet bilgileri, kalite incelemesinin hassas ayrıntıları veya başka müşterilere ait veriler sınırlandırılmalıdır. Buna karşılık teyit edilen termin, tamamlanan miktar, sevkiyat numarası ve müşterinin işlem yapması gereken istisna açık olmalıdır. Görünürlük politikası, hem ticari şeffaflığı hem veri gizliliğini koruyacak biçimde tasarlanmalıdır.

Belge yönetiminde sürüm, geçerlilik tarihi ve erişim kapsamı önemlidir. Eski kalite belgesinin yeni sevkiyatla paylaşılması veya taslak faturanın kesin belge gibi sunulması ciddi operasyonel sorunlara yol açabilir. Sistem, belgenin kaynağını, sürümünü ve hangi sipariş ya da partiyle ilişkili olduğunu kaydetmelidir.

Güvenlik ve denetim gereksinimleri

Üretim portalı, kurumsal ağ ile dış kullanıcılar arasında kontrollü bir temas noktasıdır. Bu nedenle kimlik doğrulama, çok faktörlü doğrulama, oturum güvenliği, rol bazlı erişim, şifreli iletişim, kayıt tutma ve yedekleme başlangıç kapsamına alınmalıdır. Üretim sistemlerine doğrudan ve sınırsız erişim vermek yerine aracı servisler, doğrulanmış veri sözleşmeleri ve ağ ayrımları kullanılmalıdır.

NIST’in operasyonel teknoloji güvenliği rehberi, OT ortamlarında performans, güvenilirlik ve emniyet gereksinimlerinin güvenlik önlemleriyle birlikte değerlendirilmesini önerir. Bu nedenle sıradan bir kurumsal web uygulamasındaki güncelleme veya erişim yaklaşımı, üretim ortamına aynen uygulanmamalıdır. Entegrasyon noktaları risk değerlendirmesi, en az yetki, ağ segmentasyonu, izleme ve kontrollü değişiklik süreçleriyle ele alınmalıdır.

• Kritik kullanıcı ve yönetici hesaplarında güçlü kimlik doğrulama uygulanmalıdır.
• Yetki, fiyat, banka bilgisi ve durum değişiklikleri denetim izine yazılmalıdır.
• Dosya yüklemeleri tür, boyut, zararlı içerik ve erişim kapsamı açısından kontrol edilmelidir.
• Entegrasyon hesaplarına yalnızca gerekli veri ve işlemler için yetki verilmelidir.
• Yedekleme kadar geri yükleme senaryoları da düzenli olarak sınanmalıdır.

Proje kapsamı nasıl planlanmalıdır?

Başarılı bir proje, ekran çizmekten önce mevcut iş akışını ortaya çıkarır. Siparişin hangi kanallardan geldiği, kim tarafından doğrulandığı, ERP’ye nasıl işlendiği, üretim ve sevkiyat bilgisinin nerede oluştuğu görüşmeler ve gerçek örnekler üzerinden incelenmelidir. İdeal sürecin yanı sıra gecikme, ret, revizyon, eksik üretim, bağlantı hatası ve kısmi sevkiyat gibi istisnalar da modellenmelidir.

İlk sürümde tüm olasılıkları kapsamak yerine ölçülebilir bir çekirdek akış seçilebilir. Örneğin belirli bir müşteri grubu, tesis veya ürün ailesiyle başlayarak sipariş, onay, üretim durumu, sevkiyat ve belge görünürlüğü doğrulanabilir. Pilot sırasında kullanıcı geri bildirimi, veri kalitesi ve entegrasyon hataları izlenir; sonraki aşamalar gerçek kullanım verisine göre genişletilir.

Kapsam dokümanında kullanıcı rolleri, ekranlar, veri alanları, iş kuralları, entegrasyonlar, hata senaryoları, güvenlik gereksinimleri ve kabul ölçütleri birlikte yer almalıdır. Portalın başarısı yalnızca yayına çıkmasıyla değil; manuel durum sorgularının azalması, veri uyuşmazlıklarının görünür olması, işlem sürelerinin kısalması ve müşterinin doğru bilgiyi kendi kendine bulabilmesiyle değerlendirilmelidir.

Hazır paket yerine kuruma özel mimari ne sağlar?

Ağır sanayide fiyatlandırma, üretim yöntemi, kalite belgeleri, termin hesapları ve sevkiyat kuralları şirketten şirkete değişir. Hazır paket, standart sipariş senaryolarında hızlı başlangıç sağlayabilir; ancak kurumun ERP veri modeli, yetki yapısı ve istisnalarıyla uyumsuzsa ek Excel dosyaları ve manuel kontroller yaşamaya devam eder.

Kuruma özel B2B portal geliştirme yaklaşımı, yalnızca arayüzün markaya uyarlanması değildir. Süreçlerin, veri sahipliğinin, kullanıcı rollerinin, entegrasyon sözleşmelerinin ve yönetim sorumluluklarının kuruma göre tasarlanmasıdır. Sürdürülebilir yapı; dokümante edilmiş kurallara, izlenebilir değişikliklere, yönetilebilir yetkilere ve yeni tesis ya da müşteri gruplarına genişleyebilen bir mimariye dayanır.

Kumsal Ajans, ağır sanayi ve üretim şirketleri için özel web yazılımı geliştirirken marka deneyimini operasyonel gerçeklikle birlikte ele alır. Siparişten üretim ve sevkiyata uzanan mevcut iş akışınızı birlikte analiz ederek ERP’nizle uyumlu B2B portal ve üretim takip yazılımının kapsamını planlamak için Kumsal Ajans ile iletişime geçin.