# İnşaat ERP’si mi, şantiye yönetim platformu mu? Farklar ve seçim kriterleri

*2026-09-29 · 15 dk*

Finansal kayıt sistemi ile saha operasyon platformunun sınırlarını; veri sahipliği, entegrasyon, toplam maliyet ve seçim senaryolarıyla açıklayan kapsamlı karşılaştırma.


“ERP’miz varken neden başka bir şantiye yazılımına ihtiyacımız var?” ile “Saha platformu bütün süreçleri yönetiyorsa ERP neden gerekli?” soruları aynı yanlış varsayımdan doğar: kurumda tek bir sistemin her işi en iyi biçimde yapması gerektiği düşüncesi. Oysa bir yapım şirketinin finansal gerçekliği ile fiziksel üretim gerçekliği farklı hızlarda, farklı ayrıntıda ve farklı sorumlularla oluşur. Sağlıklı mimari bu gerçeklikleri tek ürüne zorla sıkıştırmaz; sınırlarını ve aralarındaki güvenilir veri akışını tasarlar.

Bu karşılaştırma marka veya ürün listesi değil, karar modelidir. Şirket ölçeği, proje türü, sözleşme modeli, ülkeler, ortak girişimler ve mevcut teknoloji yatırımı sonucu değiştirir. Ama temel ilke sabittir: bir veri yalnız bir yerde ana kayıt olmalı, diğer sistemler onu tanımlı kurallarla tüketmelidir.

## Kısa tanımlar: ERP ve şantiye platformu neyi yönetir?

ERP, kurumsal kaynak planlama sistemidir. Genel muhasebe, bütçe, nakit, banka, sabit kıymet, satın alma, stok, satış, insan kaynakları, bordro, vergi ve konsolidasyon gibi şirket süreçlerinde ortak kayıt üretir. Zaman ufku çoğunlukla dönemsel ve finansaldır. Bir faturanın muhasebe hesabı, KDV'si, vadesi, ödeme durumu ve şirketler arası kaydı ERP'de güvenilir olmalıdır.

Şantiye yönetim platformu ise projenin teknik üretim sistemidir. Poz, mahal, metraj, çizim revizyonu, iş programı, gerçekleşen miktar, ekip, ekipman, kalite kontrolü, RFI, submittal, saha günlüğü, hakediş ve değişiklik olayı gibi nesneleri yönetir. Zaman ufku günlük hatta anlıktır. Bir imalatın nerede, hangi çizime göre, ne kadar, kim tarafından ve hangi kalite kanıtıyla yapıldığı burada güvenilir olmalıdır.

İnşaat ERP'si ifadesi iki farklı ürün tipini anlatabilir. Bazı ERP'ler sektörel modüllerle proje maliyeti ve hakedişi derinleştirir. Bazı satıcılar ise saha platformuna finans modülleri ekleyip ERP adı kullanır. Etikete değil, veri nesnesi ve süreç derinliğine bakılmalıdır.

## Temel fark: işlem kaydı ile üretim bağlamı

ERP'nin güçlü olduğu işlem, muhasebeleştirilebilir ve kuralları net olaydır: sipariş, irsaliye, fatura, ödeme, bordro. Şantiye platformunun güçlü olduğu olay bağlama bağımlıdır: revizyon nedeniyle artan metraj, kalite onayını bekleyen ilerleme, gecikmeye yol açabilecek RFI veya taşeronun itiraz ettiği ataşman. Aynı olay iki sistemde farklı temsil edilebilir.

Örneğin 120 ton donatı siparişi ERP'de tedarikçi, fiyat, vergi, vade ve teslimat olarak izlenir. Şantiye platformu aynı siparişi blok, kat, iş paketi, ihtiyaç tarihi, bütçe kodu ve program aktivitesiyle ilişkilendirir. Mal geldiğinde ERP stok ve mali kaydı oluşturur; saha platformu kalite kabulünü, lotu, kullanım mahallini ve ilerleme etkisini saklar. İki sistemden birini kaldırmak yerine, teslimat kimliği ve durumlarının nasıl eşleneceği belirlenir.

Bu ayrım raporlamayı da etkiler. ERP “ne kadar harcadık?” sorusuna güçlü cevap verir. Şantiye platformu “ne ürettik, ne kadar iş kaldı ve kaça bitecek?” sorusunu yanıtlar. Yönetim ikisini birleştirerek proje marjını görür.

## Süreç kapsamı karşılaştırma tablosu

| Süreç | ERP'nin doğal rolü | Şantiye platformunun doğal rolü | Ana kayıt önerisi |
|---|---|---|---|
| Şirket/proje finansı | Genel muhasebe, konsolidasyon | Proje tahmini ve teknik dağılım | ERP |
| Keşif ve metraj | Özet bütçe | Poz, mahal, revizyon, ölçüm | Şantiye platformu |
| İş programı | Finansal dönem ve bütçe | Aktivite, kritik yol, ilerleme | Şantiye platformu |
| Satın alma | Onay, sipariş, fatura, ödeme | Teknik talep, ihtiyaç tarihi, saha kabulü | Bölüşümlü |
| Stok | Değerleme ve muhasebe | Şantiye lokasyonu ve kullanım bağlamı | Mimariye göre |
| Hakediş | Tahakkuk ve finansal kayıt | Miktar, ataşman, kesinti hesabı, onay | Şantiye platformu; sonuç ERP |
| Doküman/RFI | Ek veya genel arşiv | Revizyon, dağıtım, teknik bağlam | Şantiye platformu/DMS |
| Bordro | Yasal hesap ve ödeme | Proje/aktivite zaman dağılımı | ERP/HR; dağılım sahadan |
| Kalite ve İSG | Maliyet etkisi | Kontrol, uygunsuzluk, aksiyon | Şantiye platformu |
| Nakit | Banka, ödeme planı | Hakediş ve taahhüt tahmini | ERP; tahmin girdisi platformdan |

Tablo bir kanun değildir. Örneğin ileri depo yönetimi ayrı WMS'de, belge yaşam döngüsü kurumsal DMS'de bulunabilir. Önemli olan her satır için sistem sahibi, aktarım yönü, sıklık, doğrulama ve hata sorumlusunun yazılmasıdır.

## İnşaat ERP'sinin güçlü olduğu alanlar

ERP, çok şirketli yapı ve mali mevzuat söz konusu olduğunda merkezî kontrol sağlar. Hesap planı, mali dönem, döviz değerleme, şirketler arası işlem, vergi, banka ve konsolide raporlama uzmanlık ister. Proje bazlı maliyet muhasebesi güçlü bir ERP, faturaları maliyet merkezine ve iş kırılımına dağıtır; bütçe kontrolü ve nakit planı üretir.

Satın alma tarafında tedarikçi ana verisi, yetki limitleri, sipariş, sözleşme taahhüdü, mal kabul ve üçlü eşleşme ERP'nin olgun olduğu alanlardır. İnsan kaynakları ve bordro entegrasyonu sayesinde çalışan maliyetleri projelere aktarılabilir. Varlık ve ekipman modülü amortisman, bakım maliyeti ve zimmeti finansal kayıtla bağlar.

ERP ayrıca denetçi ve finans ekiplerinin beklediği dönem kilidi, fiş izi ve onay ayrılığını sağlar. Fakat bu güçlü yön, sahadaki teknik kaydı otomatik olarak çözmez. Bir faturanın doğru muhasebe hesabına gitmesi, faturaya konu imalatın doğru revizyona göre ve kalite onayıyla yapıldığını kanıtlamaz. ERP'ye yüzlerce sektörel özel alan eklemek mümkün olsa da kullanıcı deneyimi ve sürüm yükseltme maliyeti kötüleşebilir.

## Şantiye yönetim platformunun güçlü olduğu alanlar

Şantiye platformu proje bağlamını korur. Bir saha kaydı lokasyon, poz, aktivite, sözleşme, ekip ve belgeyle ilişkilendirilir. Mobil kullanım, çevrimdışı çalışma, fotoğraf, çizim üzerinde işaretleme, QR kod ve hızlı form tasarımı saha benimsemesi için özelleşmiştir.

Planlama ve ilerleme tarafında fiziksel miktar, kilometre taşı, kazanılmış değer ve kritik yol takip edilir. Doküman tarafında RFI, submittal, transmittal, revizyon ve dağıtım statüleri yönetilir. Ticari tarafta işveren ve taşeron hakedişi, ataşman, fiyat farkı, değişiklik ve hak talebi gibi inşaata özgü ilişkiler kurulur. [Construction Suite Pro](/urunler/construction-suite-pro) bu katmanları ortak proje modeli içinde ele alan bir örnektir.

Platformun zayıf kalabileceği alanlar yasal muhasebe, vergi, banka, bordro ve kurum çapında finans konsolidasyonudur. Satıcının “finans modülümüz var” demesi, ülkeye ve şirket yapısına uygun ERP işlevi sunduğu anlamına gelmez. Canlı referans, mevzuat güncelleme süreci ve bağımsız denetim gereksinimi doğrulanmalıdır.

## Aynı verinin iki sistemde yaşaması neden tehlikelidir?

En yaygın entegrasyon hatası, veri paylaşmak yerine kopyalamaktır. Proje kodu iki sistemde ayrı açılır, tedarikçi adı farklı yazılır, kur veya birim farklı uygulanır. Başlangıçta küçük görünen fark dönem sonunda saatler süren uzlaştırmaya dönüşür. Daha kötüsü, kullanıcı hangi değerin doğru olduğunu bilemez.

Ana veri sahipliği matrisi şu alanları içermelidir: veri nesnesi, sahibi sistem, oluşturan rol, onaylayan rol, tüketen sistemler, benzersiz anahtar, güncelleme sıklığı, silme/kapatma kuralı ve hata sorumlusu. Örneğin tedarikçi ERP'de açılır; şantiye platformu benzersiz kimlikle tüketir. Poz platformda oluşur; onaylı maliyet kodu ve bütçe özeti ERP'ye gönderilir. Fatura ERP'de kayda girer; teknik kabul durumu platformdan referansla gelir.

İki yönlü senkronizasyon yalnız gerçekten gerekli alanlarda kullanılmalıdır. Her iki sistemin aynı alanı değiştirebilmesi döngü ve çatışma yaratır. Durum geçişleri event tabanlı olabilir: “teknik kabul tamamlandı”, “fatura muhasebeleşti”, “ödeme yapıldı”. Kullanıcıya son senkronizasyon ve hata görünürlüğü sağlanmalıdır.

## Dört olası hedef mimari

Birinci model ERP merkezlidir. Şirket güçlü bir ERP kullanır; saha için sınırlı mobil uygulama ve özel ekranlar ekler. Finans kontrolü baskın, proje türleri standart ve saha karmaşıklığı düşükse işe yarayabilir. Risk, özel geliştirme birikmesi ve saha deneyiminin zayıf kalmasıdır.

İkinci model şantiye platformu merkezlidir. Proje operasyonu platformda, temel muhasebe daha dar bir finans uygulamasında yürür. Tek veya az şirketli, proje odaklı büyüyen işletmelerde uygun olabilir. Risk, ölçek büyüdükçe konsolidasyon ve yasal süreç ihtiyacının platform sınırını aşmasıdır.

Üçüncü model iki katmanlı “best of breed” yapıdır. ERP kurumsal ve finansal kayıt sistemi; şantiye platformu proje üretim sistemidir. Entegrasyon katmanı veri akışını yönetir. Orta ve büyük yükleniciler için çoğu zaman dengeli çözümdür; ancak veri yönetişimi ve entegrasyon işletme yetkinliği gerektirir.

Dördüncü model veri platformlu ekosistemdir. ERP, şantiye, BIM, DMS, planlama ve analitik sistemleri ortak veri sözlüğü ve entegrasyon platformuyla bağlanır. Büyük portföy ve çok ülke operasyonunda değerlidir. Teknoloji hevesiyle erken kurulursa gereksiz karmaşıklık doğurur; önce sahiplik ve kullanım senaryosu olmalıdır.

## Hangi durumda yalnız ERP yeterli olabilir?

Proje sayısı az, saha iş akışları basit, teknik doküman yönetimi dış hizmetle çözülüyor ve hakediş yapısı sınırlıysa iyi yapılandırılmış sektörel ERP yeterli olabilir. Özellikle ana iş modeli malzeme tedariği veya tekrarlı küçük uygulamalarsa ayrı platformun toplam maliyeti değer üretmeyebilir.

Ancak “yeterli” kararı ekran varlığıyla değil, operasyon testiyle verilmelidir. ERP şu sorulara kabul edilebilir eforla cevap verebiliyor mu: güncel çizime göre hangi mahalde ne kadar imalat yapıldı; kalite onayı olmayan miktar hakedişe girebiliyor mu; taşeron talebi ataşmana bağlı mı; program aktivitesi ile maliyet tahmini ilişkili mi; mobil kullanıcı internet yokken kayıt yapabiliyor mu? Cevaplar manuel dosya ve e-posta gerektiriyorsa ERP teknik kayıt sistemi değildir.

ERP içinde özel geliştirme yapmanın sürüm, test ve ana ürün yol haritası üzerindeki etkisi hesaplanmalıdır. İlk proje maliyeti düşük görünen özelleştirme, her güncellemede yeniden test ve danışman bağımlılığı yaratabilir.

## Hangi durumda ayrı şantiye platformu gerekir?

Çok disiplinli büyük projeler, çok sayıda taşeron, karmaşık hakediş, sık tasarım revizyonu, işveren raporlama yükümlülüğü ve sahada yoğun kalite/İSG süreci ayrı platform ihtiyacını artırır. Portföy seviyesinde standart veri, erken maliyet uyarısı ve kurumsal bilgi hafızası hedefleniyorsa da proje katmanı gerekir.

Belirgin sinyaller şunlardır: aylık kapanışta farklı ekiplerin Excel birleştirmesi; gerçekleşen miktarın haftalar sonra finansal rapora yansıması; RFI ve revizyonun e-postadan izlenmesi; taşeron hakedişlerinde aynı ölçümün tekrar yapılması; maliyet tahmininin kişilere bağımlı olması; proje sonunda dokümanın devredilememesi. Bu sinyallerin üç veya daha fazlası varsa saha katmanı için iş vakası güçlüdür.

[Tekliften ilk hakedişe akış](/urunler/construction-suite-pro/is-akislari/teklifden-ilk-hakedise-uctan-uca) gibi bir senaryo, ayrı platformun ERP'ye göre hangi bağlamı eklediğini somutlaştırır. Değer, yeni ekran değil; tekrar girişi ve karar gecikmesini azaltmaktır.

## Entegrasyonda paylaşılması gereken veri nesneleri

Başlangıç entegrasyonu her şeyi kapsamak zorunda değildir. Değer ve risk esasına göre önceliklendirin:

1. Şirket, proje, maliyet merkezi ve kullanıcı kimlikleri,
2. Tedarikçi ve taşeron ana verisi,
3. Para birimi, kur ve vergi referansları,
4. Onaylı bütçe ve maliyet kodları,
5. Satın alma talebi, sipariş ve taahhüt durumu,
6. Mal kabul ve teknik kabul bilgisi,
7. Fatura, tahakkuk ve ödeme durumu,
8. Bordro/puantaj maliyet dağılımı,
9. Ekipman ve varlık maliyeti,
10. Hakediş onay sonucu ve muhasebe fişi referansı.

Poz, mahal, çizim nesnesi ve ayrıntılı kalite verisini ERP'ye taşımak çoğu zaman gereksizdir. ERP için özet ve referans yeterli olabilir; gerektiğinde kullanıcı kaynak kayda bağlantıyla iner. Büyük dosyalar API mesajına gömülmemeli, güvenli belge bağlantısıyla paylaşılmalıdır.

Kimlik eşleme kritik konudur. İsim üzerinden eşleme yerine değişmez benzersiz anahtar kullanın. Silme yerine pasife alma, tarihsel raporları korur. Entegrasyonun yeniden çalıştırılması aynı işlemi iki kez oluşturmamalıdır. Hata kuyruğu teknik ekip kadar iş birimi tarafından da anlaşılabilir olmalıdır.

## Hakediş ve maliyet kontrolünde görev paylaşımı

Hakedişin teknik hazırlığı şantiye platformunda yapılmalıdır: sözleşme pozları, önceki ve bu dönem miktarı, ataşman, kalite şartı, kesinti ve onay. Onaylanan sonuç ERP'ye tahakkuk veya fatura öncesi belge olarak geçer. ERP vergi, muhasebe hesabı, cari hesap, vade ve ödeme sürecini yönetir. ERP'deki fiş numarası tekrar platforma dönerek uçtan uca iz bırakır.

Maliyet kontrolünde ERP gerçekleşen finansal maliyetin; platform ise taahhüt, sahadaki ilerleme ve tamamlanma tahmininin kaynağıdır. [Hakediş ve maliyet kontrolü](/urunler/construction-suite-pro/yetenekler/hakedis-ve-maliyet-kontrolu-derinlemesine) bu iki veri setinin ortak maliyet kodunda buluşmasını gerektirir. Sadece faturaya dayalı rapor gecikmeli; sadece saha tahminine dayalı rapor ise finansal doğrulamadan yoksundur.

Dönem kilitleri uyumlu olmalıdır. Platformda onaylı hakediş değiştiğinde ERP'deki kapanmış dönem bozulmamalı; düzeltme belgesi veya sonraki dönem farkı oluşturulmalıdır. Yetki ayrılığı iki sistem arasında da korunmalıdır; teknik onayı veren kişinin ödeme onayını tek başına tamamlaması engellenebilir.

## BIM ve iş programı ERP'ye mi bağlanmalı?

BIM modeli ve ayrıntılı iş programı genellikle şantiye/ortak veri ortamı katmanıyla ilişkilendirilir. ERP'nin binlerce model nesnesini veya günlük aktivite durumunu saklamasına gerek yoktur. ERP'ye mali ve zaman dönemleri için özet aktarılır. Model nesnesi poz ve aktiviteyle eşlenir; onaylı ilerleme bütçe tahminine yansır.

[Saha dijitalleşmesi ve BIM yeteneği](/urunler/construction-suite-pro/yetenekler/saha-dijitallesmesi-mobil-ve-drone-bim), modelin yalnız görsel olarak açılmasından daha fazlasını hedefler. Model sürümü, nesne kimliği, sınıflandırma ve ölçüm kuralı korunmalıdır. 4D bağ programı, 5D bağ maliyeti temsil eder; fakat yanlış eşleme otomasyonu hatayı büyütür. Örnek model üzerinde yüzde kaç nesnenin güvenilir eşleştiği ölçülmelidir.

Program tarafında Primavera veya benzeri araç ana planlama sistemi olabilir. Şantiye platformu saha ilerlemesini ve olayları toplar, planlama sistemi hesaplar, özet kilometre taşları ERP nakit tahminine gider. Üç sistemin de aynı aktivite alanını değiştirmesi önlenmelidir.

## Güvenlik, yetki ve denetim karşılaştırması

ERP'deki rol çoğunlukla şirket, muhasebe kodu ve işlem türüne dayanır. Şantiye platformunda proje, sözleşme, firma, mahal, doküman durumu ve saha rolü gibi daha dinamik sınırlar vardır. Ortak kimlik sağlayıcı ve tek oturum açma kullanıcı yaşam döngüsünü kolaylaştırır; ancak uygulama içi ayrıntılı yetki yine tasarlanmalıdır.

İki sistemde ortak güvenlik asgarileri şunlardır: çok faktörlü doğrulama, en az ayrıcalık, hazırlayan–onaylayan ayrılığı, değiştirilemez denetim izi, şifreli aktarım ve saklama, yedekleme testi, oturum ve cihaz politikası, servis hesabı yönetimi. Entegrasyon hesabı sınırsız yönetici olmamalıdır. API anahtarları kullanıcı dosyalarında tutulmamalı, düzenli döndürülmelidir.

Ortak giriş, ortak denetim izi demek değildir. Bir işlemin platformdan ERP'ye geçişinde korelasyon kimliği kullanılmalı; kaynak kayıt, mesaj, hedef kayıt ve hata aynı zincirde izlenebilmelidir. Denetçi bir hakediş satırından ERP fişine, oradan ödeme belgesine; ters yönde de ataşmana ulaşabilmelidir.

## Toplam sahip olma maliyeti nasıl karşılaştırılır?

“Mevcut ERP'ye modül eklemek daha ucuzdur” veya “bulut platform her zaman daha ekonomiktir” genellemeleri yanıltır. Beş yıllık modelde lisans/abonelik, kullanıcı ve proje ölçeği, danışmanlık, özel geliştirme, entegrasyon, veri göçü, altyapı, güvenlik, eğitim, destek, sürüm yükseltme ve iç personel zamanı yer almalıdır.

ERP özelleştirmesinde başlangıç geliştirmesi kadar gelecekteki regresyon testi ve uzman bağımlılığı hesaplanmalıdır. Ayrı platformda ikinci lisansın yanında entegrasyon işletimi ve veri yönetişimi maliyeti vardır. Tek paket çözümünde modüller arası teknik entegrasyon kolay olabilir; fakat zayıf saha kullanımının gizli maliyeti yüksektir.

Maliyet modelini üç senaryoyla kurun: ihtiyatlı, beklenen, yüksek büyüme. Proje ve kullanıcı sayısı artınca fiyat basamaklarını; depolama, API çağrısı, yapay zekâ kullanımı ve dış kullanıcı ücretlerini sorun. Çıkış maliyetini de dahil edin: veri ve ekleri dışa aktarmak, arşivi salt okunur tutmak ve yeni sisteme taşımak ne kadar efor gerektirir?

## Seçim puan kartı ve ağırlıklandırma

Karar komitesi finans, proje kontrol, saha, satın alma, kalite, BT, güvenlik ve üst yönetim temsilcilerinden oluşmalıdır. Her rolün ağırlığı ve veto kriteri önceden belirlenmelidir. Örnek puan kartı:

| Boyut | Örnek ağırlık | Ölçüm yaklaşımı |
|---|---:|---|
| Saha ve sektör derinliği | %20 | Gerçek cihazla senaryo tamamlama |
| Finans ve yasal uygunluk | %15 | Yerel süreç ve referans kanıtı |
| Hakediş/maliyet tahmini | %15 | İki dönem ve revizyon demosu |
| Entegrasyon/açıklık | %15 | API, olay, hata ve dışa aktarım testi |
| Kullanılabilirlik | %10 | Rol bazlı görev süresi ve hata |
| Güvenlik/yönetişim | %10 | Kontrol kanıtı ve sözleşme |
| Toplam sahip olma maliyeti | %10 | Beş yıllık üç senaryo |
| Ürün ve hizmet sürekliliği | %5 | Yol haritası, SLA ve ekip |

Puanı satıcı beyanına göre değil kanıt seviyesine göre verin: 1 = yok; 2 = yol haritasında; 3 = yapılandırmayla var; 4 = canlı demoda kanıtlandı; 5 = benzer ölçekte referans ve kabul testiyle doğrulandı. Böylece etkileyici sunum ile işletilebilir yetenek ayrışır.

## Kavram kanıtı için uçtan uca senaryo

Kavram kanıtı bir aylık ücretsiz kullanım değil, hipotez testidir. Örnek hipotez: “Onaylı saha ilerlemesi platformdan ERP maliyet koduna hatasız akacak ve aylık kapanış uzlaştırmasını yüzde 50 azaltacak.” Veri seti, mevcut ölçüm ve başarı eşiği belirlenir.

Senaryo şu zinciri kapsayabilir: ERP'de proje ve tedarikçi açılır; platforma aktarılır. Platformda keşif ve iş programı bağlanır. Saha çevrimdışı ilerleme kaydeder. Teknik satın alma talebi oluşur; ERP siparişe dönüştürür. Teslimat ve kalite kabulü platformdan gelir. Fatura ERP'de eşleşir. Taşeron hakedişi platformda onaylanır, ERP'de tahakkuk eder. Yönetim raporu bütçe, taahhüt, gerçekleşen ve EAC değerini birlikte gösterir.

Bir hatayı kasıtlı oluşturun: geçersiz maliyet kodu, çift fatura veya bağlantı kesintisi. Sistem kaydı kaybetmeden uyarıyor mu; kullanıcı hatanın sahibini ve çözümünü görüyor mu? Başarılı entegrasyon yalnız mutlu yolun çalışması değil, hatanın kontrollü yönetilmesidir.

## Geçiş stratejisi ve sıra

Her iki sistem de yenilenecekse “hangisi önce?” sorusunun tek cevabı yoktur. ERP dönüşümü sürerken şantiye platformunu bekletmek yıllar süren operasyon kaybı yaratabilir; eş zamanlı büyük dönüşüm ise kurum kapasitesini aşabilir. Mimari hedef ve ana veri modeli ortak tasarlanıp uygulama dalgaları ayrılabilir.

Bir yaklaşım, temel ERP ana verisini ve mali kodları stabilize etmek; ardından şantiye pilotunu başlatmaktır. Başka bir yaklaşım, mevcut ERP'yi koruyup saha platformuyla hızlı değer üretmek, yeni ERP geldiğinde tanımlı entegrasyon sözleşmesini yeniden bağlamaktır. Seçim; mevcut sistem ömrü, sözleşme takvimi ve proje portföyüne göre yapılır.

Eski verinin tamamını taşımak zorunlu değildir. Aktif projeler ayrıntılı; kapanmış projeler aranabilir arşiv; kurumsal poz, tedarikçi ve dersler temiz ana veri olarak taşınabilir. Mutabakat planı ve geri dönüş senaryosu olmadan canlı geçiş yapılmamalıdır.

## Yönetim için karar ağacı

Şu sorular kararı hızlandırır:

- Yasal finans, konsolidasyon ve bordro ana sorunsa: ERP çekirdeğini güçlendirin.
- Saha ilerlemesi, revizyon, kalite ve hakediş görünmüyorsa: şantiye platformunu önceliklendirin.
- Her iki katmanda güçlü sistem var fakat raporlar uyuşmuyorsa: yeni ürün almadan önce veri sahipliği ve entegrasyonu düzeltin.
- Mevcut ERP'nin sektör modülü gerçek saha senaryolarını düşük özelleştirmeyle geçiyorsa: ayrı platformun iş vakasını dikkatle test edin.
- ERP derin ama mobil/saha zayıfsa: iki katmanlı mimariyi değerlendirin.
- Küçük, tek şirketli ve standart projeli yapıysanız: kontrollü kapsamlı tek ürün ekonomik olabilir.
- Çok ülke, ortak girişim ve büyük portföy varsa: açık API'li iki katman ve veri yönetişimi genellikle daha dayanıklıdır.

Bu ağacın sonunda marka değil hedef işletim modeli çıkar. Ürün seçimi bu modelin teknik ve ticari doğrulamasıdır.

## Yönetim kuruluna sunulacak tek sayfalık karar belgesi

Karar belgesinde mevcut sorun, hedef işletim modeli, sahip sistemler, beklenen fayda, toplam maliyet, temel risk ve pilot kabul eşiği yer almalıdır. “Yeni ERP” ya da “dijital şantiye” gibi geniş proje adları yerine iki ölçülebilir sonuç seçin: örneğin saha gerçekleşmesinin maliyet tahminine bir iş günü içinde yansıması ve kapanış uzlaştırma eforunun yarıya inmesi. Mimari diyagramda her veri nesnesinin sahibi ile aktarım yönünü gösterin. Yönetim böylece ürün özelliklerine değil, değişecek karar döngüsüne onay verir.

Karar belgesinin ekinde mevcut taban ölçüm, kavram kanıtı sonuçları ve beş yıllık maliyet senaryosu bulunmalıdır. Faydaların sahibi iş birimi, teknik bağımlılıkların sahibi BT olur. Belge pilot kapanışında yeniden açılır; varsayım ile gerçekleşen farkı ve devam kararını kaydeder. Böylece seçim tek seferlik satın almadan ölçülebilir işletim dönüşümüne evrilir.

## Sonuç: doğru soru hangisi?

Doğru soru “ERP mi, şantiye platformu mu?” değil, “Hangi kayıt nerede sahiplenilecek ve karar için nasıl birleşecek?” sorusudur. ERP şirketin finansal ve yasal omurgasını; şantiye platformu projenin teknik ve fiziksel üretim omurgasını oluşturur. Birini diğerine benzetmeye çalışmak, ya sahayı muhasebe ekranına ya da muhasebeyi proje formuna sıkıştırır.

Karar vermeden önce veri sahipliği matrisi hazırlayın, üç kritik uçtan uca senaryo seçin, beş yıllık maliyeti hesaplayın ve gerçek kullanıcılarla kavram kanıtı yapın. [Construction Suite Pro ürün mimarisini](/urunler/construction-suite-pro) ve [maliyet aşımını erken tespit akışını](/urunler/construction-suite-pro/is-akislari/maliyet-asimi-erken-tespiti) inceleyerek saha katmanının ERP ile hangi noktalarda buluşacağını somutlaştırabilirsiniz. Kurumunuza özel hedef mimari için [ön görüşme](/on-gorusme) planlanabilir.

## Resmî ve birincil kaynaklar

- Çevre, Şehircilik ve İklim Değişikliği Bakanlığı Yüksek Fen Kurulu: [Yapım işleri, birim fiyat ve sözleşme uygulama kaynakları](https://yfk.csb.gov.tr/)
- International Society of Automation: [ISA‑95 kurumsal sistemler ile operasyon sistemleri katmanları](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard)
- Google Search Central: [İnsan odaklı, güvenilir içerik yaklaşımı](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)

> Bu yazı teknoloji ve işletim modeli karşılaştırmasıdır; muhasebe, vergi veya sözleşme konusunda profesyonel görüş yerine geçmez.