Blog

ERP Şantiye Karşılaştırması Nasıl Yapılır?

15 Ağustos 2026

Bir şantiyede maliyetin neden yükseldiğini ay sonu muhasebe raporundan öğrenmek geç kalmaktır. Malzeme girişi, taşeron imalatı, puantaj, avans ve tahsilat aynı gün görünmüyorsa, firma aslında projeyi değil geçmişi yönetir. Bu nedenle ERP şantiye karşılaştırması, ekran sayısı veya marka bilinirliği üzerinden değil; sahadaki verinin ne kadar hızlı, doğru ve proje bazında karar verilebilir hale geldiği üzerinden yapılmalıdır.

Genel bir ERP, finans ve muhasebe disiplinini güçlü şekilde kurabilir. Ancak şantiye; depo fişi, günlük rapor, hakediş, metraj, taşeron ilerlemesi ve dövizli satın alma gibi kendi dili olan bir operasyon alanıdır. Doğru seçim, bu iki gerçeği karşı karşıya koymak değil, firmanızın günlük iş akışında hangi ihtiyacın öncelikli olduğunu netleştirmektir.

ERP şantiye karşılaştırmasında asıl soru nedir?

Asıl soru “Hangi yazılımda daha çok özellik var?” değildir. Asıl soru şudur: Şantiye şefi bugün yaptığı kaydı zorlanmadan sisteme giriyor mu ve yönetici bu kaydı yarın değil, şimdi maliyet kararında kullanabiliyor mu?

Bir yazılımda yüzlerce menü bulunabilir. Fakat satın alma sorumlusu malzeme talebini açmak için muhasebe kodu, depo tanımı ve birkaç farklı onay ekranı arasında kayboluyorsa, o sistem sahada kullanılmaz. Kullanılmayan sistemin raporu da güvenilir olmaz. Excel, WhatsApp ve telefon notları yeniden devreye girer; ekip aynı veriyi iki kez girer.

Bu yüzden karşılaştırmayı ürün tanıtım ekranlarıyla sınırlamayın. Her aday sistemden kendi gerçek senaryonuzu çalıştırmasını isteyin: Bir malzeme alımı açın, ilgili projeye maliyetleyin, taşeron hakedişi oluşturun, o günün puantajını girin ve nakit akışına etkisini görün. İş akışı kısa değilse, sistemin vaat ettiği kontrol uzun ömürlü olmayacaktır.

Proje maliyeti sadece muhasebe kaydı değildir

İnşaat firmalarının ilk ihtiyacı, harcamanın hangi projeye, hangi işe ve hangi döneme ait olduğunu görmektir. Genel amaçlı ERP'ler bunu çoğu zaman masraf merkezi, hesap planı veya ek geliştirmeler üzerinden kurgular. Bu yapı finans ekibi için anlamlı olabilir; fakat saha tarafında günlük kullanımı ağırlaştırabilir.

Şantiye odaklı bir sistemde proje maliyeti, işlemin doğal parçası olmalıdır. Malzeme girişi yapılınca, tedarikçi faturası işlendiğinde veya taşeron hakedişi onaylandığında maliyet ilgili projeye doğrudan yansımalıdır. Yönetici, toplam rakamın yanında planlanan ve gerçekleşen tutarı, maliyet grubunu ve sapmanın kaynağını izleyebilmelidir.

Dövizli çalışan firmalarda bu konu daha da kritiktir. Dolar veya euro ile alınan malzemenin, ödeme tarihindeki kur etkisinin ve proje kârlılığına yansımasının ayrı izlenmesi gerekir. Sadece TL toplamı görmek, özellikle uzun süren projelerde gerçek maliyet tablosunu gizleyebilir. Karşılaştırma sırasında sistemin işlem dövizi, kur farkı ve proje bazlı dövizli analiz yaklaşımını mutlaka sorun.

Saha kullanımı bir özellik değil, benimsenme testidir

Ofiste sorunsuz çalışan her yazılım şantiyede çalışmaz. İnternetin zayıf olduğu, ekiplerin hareket halinde bulunduğu ve kayıt için ayrılabilecek sürenin sınırlı olduğu ortamda sade ekranlar belirleyicidir. Günlük saha raporu, malzeme girişi veya personel puantajı birkaç dakikada girilemiyorsa, veri gün sonunda değil haftalar sonra toplanır.

Burada mobil erişim tek başına yeterli değildir. Mobil ekranın saha rolüne uygun olması gerekir. Şantiye şefinin günlük gerçekleşmeyi girdiği sayfa ile muhasebenin ödeme kontrol ekranı aynı karmaşıklıkta olmamalıdır. Rol bazlı erişim hem kullanıcı deneyimini iyileştirir hem de herkesin görmemesi gereken finansal veriyi sınırlar.

Demo sırasında ekibe şu basit görevi verin: Dün sahada gerçekleşen imalatı, kullanılan malzemeyi ve çalışan personeli kaydetsinler. Sonra proje yöneticisi bu kayıtların maliyet etkisini görsün. Bu akış gerçek kullanıcılarla hızlı tamamlanıyorsa sistemin benimsenme şansı yüksektir.

Hakediş ve taşeron sürecini ayrı değerlendirin

Taşeron yönetimi, standart satın alma sürecinden daha fazlasıdır. Sözleşme bedeli, ilerleme, kesinti, avans, önceki dönem hakedişi ve ödeme planı birbirine bağlıdır. Bu bağ koparsa aynı taşerona ne kadar borç oluştuğunu, işin fiziksel ilerlemesini ve kalan sözleşme tutarını ayrı dosyalardan takip etmek zorunda kalırsınız.

Bazı ERP çözümleri taşeron sürecini satın alma veya hizmet faturası mantığıyla yürütür. Bu, basit işlerde yeterli olabilir. Çok sayıda taşeron ve dönemsel hakediş bulunan projelerde ise imalat-temelli hakediş kurgusu ciddi zaman kazandırır. Sistem, onaylanan hakedişi ödeme planına ve proje maliyetine bağlayabilmelidir.

Aynı değerlendirme malzeme için de geçerlidir. Talep, teklif, sipariş, teslimat, stok ve proje tüketimi arasında kopukluk varsa satın alma ekibi en uygun fiyatı bulsa bile gerçek tasarrufu ölçemez. Çünkü ucuz alınan ürünün yanlış projeye, yanlış zamanda veya gereğinden fazla sevk edilmesi maliyeti büyütür.

Nakit akışı ile satış tahsilatı aynı fotoğrafta olmalı

Şantiyede kâr etmek ile nakit taşımak aynı şey değildir. Satışı yapılmış dairelerin tahsilat takvimi, vadesi yaklaşan tedarikçi ödemeleri, taşeron hakedişleri ve personel giderleri birlikte görülmezse yönetim sürekli yangın söndürür. Özellikle çok projeli yapılarda bir projenin tahsilat gücü, diğer projenin ödeme kararını etkileyebilir.

Bu nedenle ERP şantiye karşılaştırmasında finans ekranını sadece genel muhasebe raporuyla değerlendirmeyin. Proje bazlı beklenen giriş ve çıkışların, geciken tahsilatların ve yaklaşan ödemelerin ne kadar anlaşılır göründüğüne bakın. Satış ekibinin daire rezervasyonu, sözleşme ve tahsilat bilgisini girmesiyle finans ekibinin aynı veriyi izlemesi gerekir.

Bir sistem satış süreçlerini tamamen dışarıda bırakıyorsa, konut üreten firmada nakit görünürlüğü eksik kalabilir. Tersine, yalnızca satışa odaklanan bir araç da şantiye maliyetini yönetemez. İhtiyacınız iki süreci tek bir karar tablosunda buluşturmaktır.

Genel ERP mi, şantiye odaklı platform mu?

Bu seçim her firma için aynı cevapla yapılmaz. Çok uluslu yapısı olan, üretimden dağıtıma kadar farklı sektörlerde faaliyet gösteren ve kapsamlı kurumsal standartlara bağlı büyük gruplar için genel ERP ana omurga olabilir. Özellikle merkezi muhasebe, insan kaynakları veya grup şirketleri arasında ortak veri modeli zorunluysa, güçlü bir ERP altyapısı anlamlıdır.

Buna karşılık ana operasyonu proje üretimi olan müteahhitlik firmalarında, şantiyeye uyarlanmış bir platform daha hızlı sonuç verebilir. Çünkü ekiplerin günlük dili hazırdır: hakediş, puantaj, malzeme, tedarikçi, saha raporu, satış ve tahsilat. Kurulum süresi, eğitim yükü ve sahadaki direnç genellikle daha düşüktür.

En sağlıklı model bazı firmalarda hibrit olabilir. Şantiye operasyonu uzman bir sistemde yürütülür; finansal kayıtlar veya zorunlu kurumsal süreçler mevcut ERP'ye aktarılır. Burada kritik konu entegrasyonun gerçekten hangi veriyi, hangi sıklıkta ve hangi sorumlulukla taşıdığıdır. “Entegrasyon var” ifadesi tek başına yeterli değildir. Çift kayıt oluşup oluşmadığını, hatalı aktarımda kimin müdahale edeceğini ve proje kodlarının iki sistemde nasıl eşleşeceğini netleştirin.

Karar verirken lisans modelini de operasyonla eşleştirin

Yazılım maliyetini yalnızca aylık abonelik bedeli olarak okumak yanıltıcıdır. Asıl maliyet; kuruluma harcanan zaman, danışmanlık bağımlılığı, ek kullanıcı ücretleri, özel rapor talepleri ve sisteme girmeyen saha verisidir. Çok ekranlı ve zor öğrenilen bir çözüm, ilk bakışta güçlü görünse bile kullanıcıların geri dönüp Excel kullanmasına neden olabilir.

Paketleri proje sayısı, personel kapasitesi ve alt kullanıcı ihtiyacıyla birlikte inceleyin. Şantiye ekipleri sisteme giremiyorsa sınırlı kullanıcı lisansı tasarruf değil, veri kaybıdır. Benzer şekilde ihtiyacınız olmayan ağır modüllere peşin yatırım yapmak da bütçeyi gereksiz büyütür.

ŞantiyePro gibi dikey çözümler değerlendirilirken de aynı disiplin geçerlidir: Kendi projeniz üzerinde ücretsiz deneme yapın, Türkçe destek ekibinin sürece hakimiyetini ölçün ve ihtiyacınız olan raporları ilk haftada alın. Yazılımın ne söylediğinden çok, ekibinizin neyi gerçekten kaydedebildiğine bakın.

Karşılaştırmayı 30 günlük gerçek kullanım testiyle tamamlayın

Satın alma kararını sunum günü vermek yerine, kısa bir pilot çalışma planlayın. İlk hafta bir projenin temel tanımlarını, tedarikçilerini ve maliyet gruplarını kurun. İkinci hafta malzeme, puantaj ve günlük saha raporlarını gerçek kişilerle girin. Üçüncü hafta taşeron hakedişi ile ödeme-tahsilat takvimini çalıştırın. Son hafta ise yöneticinin tek ekrandan görmek istediği üç raporu üretin.

Pilot sonunda ekipten yalnızca “beğendiniz mi?” yanıtını istemeyin. Hangi kayıt iki kez girildi, hangi ekran açıklama gerektirdi, hangi rapor karar vermeyi hızlandırdı ve hangi veri hâlâ dışarıda kaldı sorularına cevap arayın. Bu sorular, ürün broşürlerinin gösteremediği gerçek farkı ortaya çıkarır.

Doğru sistem, şantiyeye yeni bir bürokrasi eklemez. Gün içinde zaten yapılan işi düzenli kayda çevirir; ofise doğru maliyeti, yönetime de zamanında karar alma gücünü verir. Önce en çok veri kaybettiğiniz projeyi seçin ve yazılımı o projenin gerçek ritminde sınayın.

← Tüm yazılar