Maden Şirketinde ERP Seçerken Neden Standart Muhasebe Yazılımı Yetmez?

Bir maden işletmesinde ERP görüşmesi finans ekranlarıyla başladığında toplantının önemli bölümü doğru sorular sorulmadan geçebilir. Muhasebe, vergi ve genel satınalma elbette zorunludur; fakat cevher hareketi, ekipman bakımı, laboratuvar sonucu, vardiya tüketimi ve proje maliyeti farklı dosyalarda kaldığında yönetim aynı işletmeye ait birden fazla gerçekle karşılaşır. Finansal kapanış düzgün olsa bile operasyonel karar gecikebilir.

Business Central, Dynamics 365 Finance and Supply Chain, IFS ve benzeri platformların her birinin güçlü olduğu alanlar ve farklı uygulama yükleri vardır. Ürün adından önce işletme modelini anlamak gerekir. Biz seçim çalışmasını demo özelliklerinden değil, ocaktan veya yer altından başlayıp stok, işleme, satış ve finans kaydına uzanan uçtan uca senaryolardan yürüttük.

Sorunun ortaya çıkışı

Mevcut sistem temel muhasebe ve bordro ihtiyacını karşılıyor, ancak bakım planları ayrı uygulamada, depo hareketleri tabloda, laboratuvar sonuçları başka bir veritabanında tutuluyordu. Ekipman duruşunun üretim ve maliyet etkisi ancak ay sonunda elle birleştirilebiliyordu. Yeni ERP talebi önce finans yenilemesi gibi tanımlandı. Süreç haritası çıkarıldığında asıl ihtiyacın varlık yoğun operasyonu bütünleştirmek olduğu ortaya çıktı.

İlk belirtiler ve yanlış varsayımlar

“Her ERP aynı muhasebeyi yapar, geri kalanı özelleştiririz” varsayımı tehlikeliydi. Yoğun özelleştirme yükseltme ve destek maliyetini artırır. Diğer uçta, sektör etiketli ürünün tüm süreçleri hazır getireceği düşünülebilir; yerel mevzuat, işletme yöntemi ve entegrasyonlar yine çalışma ister. En çok ekranı gösteren demo da en uygun çözüm değildir. Kritik senaryonun standartta ne kadar karşılandığı ölçülmelidir.

Teknik analiz

Üretim miktarı ve kalite, varlık hiyerarşisi, önleyici bakım, yedek parça, seri ve lot takibi, laboratuvar entegrasyonu, saha bağlantısı, proje bütçesi ve birim maliyet için gereksinimler yazıldı. Her madde must-have, differentiator veya sonraki faz olarak sınıflandı. Offline çalışma, mobil kullanım, API, raporlama, yerel destek ve veri taşıma kapasitesi incelendi. Tedarikçilere aynı uçtan uca senaryolar canlı gösterim için verildi.

Uygulanan çözüm veya önerilen mimari

Önerilen mimari ERP’yi finans, tedarik, stok, proje ve varlık kayıtlarının omurgası yaptı; uzman saha ve laboratuvar sistemleri doğrulanmış entegrasyonlarla bağlı kaldı. Ana veri sahipleri ekipman, malzeme, lokasyon ve maliyet merkezi bazında belirlendi. Fazlandırma önce temel finans ve tedarik, sonra bakım ve üretim, ardından ileri planlama olacak şekilde risk bazlı yapıldı. Her faz için veri, süreç ve kabul sahibi atandı.

Alternatifler ve karar gerekçesi

Daha hafif bir finans ERP’si hızlı ve düşük maliyetli olabilir; uzman bakım ve üretim araçlarıyla entegrasyon olgunluğu varsa geçerli seçenektir. Geniş kurumsal platform daha bütünleşik yapı sunar fakat proje kapasitesi ve değişim yönetimi ister. Best-of-breed yaklaşımı fonksiyon derinliği sağlar, veri ve entegrasyon yönetişimini zorlaştırır. Kararı marka büyüklüğüne değil, standart uyum, toplam sahip olma maliyeti ve kurumun işletme kapasitesine dayandırdık.

Güvenlik ve operasyonel riskler

ERP kesintisi saha ve finansı aynı anda etkileyebileceği için yüksek erişilebilirlik, yedekleme ve geri dönüş testleri tasarıma dahil edildi. Görev ayrılığı; tedarikçi açma, sipariş, mal kabul ve ödeme zincirinde test edildi. Saha entegrasyonları doğrudan geniş veritabanı yetkisiyle kurulmadı. Ticari tekliflerde gerçek üretim ve rezerv verisi paylaşılmadı; maskelenmiş senaryolar kullanıldı. Bulut veya şirket içi tercihte veri konumu ve bağlantı bağımlılığı değerlendirildi.

Çıkarılan Dersler

Kontrol Listesi

Dijital dönüşüm ekibi kurulurken iki ayrı pozisyon için iş vardı, fakat başlangıç hacmi iki tam zamanlı rolü doldurmuyordu. Aynı kişinin hem gereksinim görüşmelerini yürütmesi hem de plan, risk ve toplantı takibini yapması önerildi. Küçük ekiplerde bu yaklaşım pratik olabilir; ancak “şimdilik birlikte” kararı sınırları yazılmazsa kalıcı ve aşırı yüklü bir role dönüşür.

İş analisti problemi, süreç ve gereksinimi derinleştirir. PMO rolü ise portföy görünürlüğü, standart, bağımlılık, risk ve karar ritmini korur. İki rol ortak bilgi kullanır, fakat odak ve bağımsızlık ihtiyacı farklıdır. Birleştirme kararı unvan tartışmasıyla değil, gerçek iş yükü, proje karmaşıklığı ve kontrol ihtiyacıyla verilmelidir.

Sorunun ortaya çıkışı

Ekip aynı anda birkaç dijitalleşme girişimi yürütüyordu. Gereksinim toplantıları, süreç şemaları, test senaryoları, haftalık durum raporu, risk kaydı ve tedarikçi takibi için tek koordinasyon noktası isteniyordu. Ayrı roller bütçe açısından erken görünürken işler yöneticiler arasında paylaşıldığında standart kayboluyordu. Birleşik rol, başlangıç için sahiplik sağladı; sürdürülebilir sınırları ayrıca tasarlamak gerekti.

İlk belirtiler ve yanlış varsayımlar

İki rolün de toplantı ve dokümantasyon yapması aynı iş oldukları izlenimini verdi. Oysa analist gereksinimin doğruluğunu sorgularken PMO teslimatın plan ve yönetişim kalitesini izler. Bir kişinin bütün toplantılara girmesi iletişimi hızlandırabilir, fakat odak değiştirme maliyeti yaratır. Ayrıca kendi hazırladığı gereksinimin ilerlemesini bağımsız raporlamak iyimserlik yanlılığına açık olabilir.

Teknik analiz

Sorumlulukları haftalık saat, uzmanlık ve kontrol ihtiyacına göre ayırdık. Süreç keşfi, gereksinim, kabul kriteri ve UAT desteği BA tarafında; portföy takvimi, risk standardı, karar kaydı, bağımlılık ve yönetim raporu PMO tarafındaydı. Proje sayısı, paydaş sayısı, tedarikçi yoğunluğu ve kritik teslimatlar kapasite göstergesi oldu. Rolün onay vermediği, kolaylaştırdığı noktalar açıklandı.

Uygulanan çözüm veya önerilen mimari

Başlangıçta birleşik rol kuruldu, fakat haftalık kapasite iki iş kovasında ayrı izlendi. Gereksinim onayını süreç sahibi, proje durum doğrulamasını sponsor veya portföy yöneticisi yaptı. Ortak şablonlar ve tek karar günlüğü çift çalışmayı azalttı. Derin analiz günleri toplantısız bloklandı. Üç aylık gözden geçirmede kapasite, geciken analiz, rapor kalitesi ve yeni proje hattına göre rolün ayrılması değerlendirildi.

Alternatifler ve karar gerekçesi

BA’yı süreç ekiplerine dağıtıp merkezi hafif PMO kurmak iş bilgisine yakınlık sağlar; yöntem tutarlılığı için topluluk yapısı gerekir. Dış analist pik dönemi karşılayabilir, fakat kurumsal bilginin içeride kalması sağlanmalıdır. Tam teşekküllü PMO erken aşamada bürokrasi yaratabilir. Birleşik rolü geçiş modeli olarak seçtik; ayrışma eşiğini proje sayısı, kritik yol çatışması ve sürekli kapasite aşımıyla önceden tanımladık.

Güvenlik ve operasyonel riskler

Tek kişide gereksinim, rapor ve tedarikçi iletişiminin toplanması bilgi ve süreklilik riski yaratır. Belgeler kişisel klasörde değil ortak kontrollü alanda tutuldu, vekil belirlendi. Ticari değerlendirme ve kapsam onayı rolün tek başına vereceği kararlar olmadı. Fazla iş yükünün riskleri yeşil raporlama baskısıyla gizlenmemesi için kapasite görünür kılındı. Hassas proje bilgisine erişim her iki sorumluluk için de ihtiyaç kadar sınırlandı.

Çıkarılan Dersler

Kontrol Listesi