Hakediş programı seçerken dikkat edilmesi gereken 12 özellik

Hakediş programı seçimi çoğu kurumda “cetveli doğru çıkarıyor mu?” sorusuna indirgenir. Oysa cetvel, çok daha uzun bir kanıt ve karar zincirinin son görünümüdür. Miktarın hangi çizim revizyonundan ölçüldüğü, sahada gerçekten yapılıp yapılmadığı, kalite kontrolünden geçip geçmediği, sözleşme pozuna nasıl eşlendiği, önceki dönemde ne kadarının ödendiği ve değişikliğin kim tarafından onaylandığı güvenilir değilse en düzgün PDF bile zayıf bir ticari kayıttır.

Bu rehber, yüklenici, işveren, proje yönetimi ve taşeron ekiplerinin hakediş yazılımını değerlendirebilmesi için on iki kritik özelliği ayrıntılandırır. Özelliklerin her biri için neden önemli olduğu, demoda nasıl sınanacağı ve hangi kırmızı bayraklara bakılacağı açıklanır.

Hakediş programı neyi çözmelidir?

Hakediş programı, belirli bir dönemde sözleşmeye uygun tamamlanan işin miktar ve değerini, önceki dönemlerle birlikte, kesinti ve ekleriyle hesaplayan; hazırlama, kontrol, itiraz, onay ve muhasebeleştirme adımlarını izleyen sistemdir. “Program” masaüstü bir hesap aracından kurumsal iş akışı platformuna kadar farklı kapsamları ifade edebilir. Doğru kapsam, projenin sözleşme ve organizasyon karmaşıklığına göre belirlenir.

Asgari hedefler şunlardır: tekrar veri girişini azaltmak, hesap tutarlılığını sağlamak, kanıtı satıra bağlamak, rol ve süreleri yönetmek, kapanmış dönemi korumak, değişikliği görünür kılmak ve finansal sisteme güvenilir sonuç aktarmak. İleri hedefler ise nakit tahmini, taşeron–işveren marj analizi, gecikme ve hak talebi bağlantısı, portföy karşılaştırması ve erken risk sinyalidir.

Construction Suite Pro hakediş ve maliyet kontrolü gibi sektörel bir çözüm incelenirken kullanıcı ekranından önce veri modeli sorgulanmalıdır. Poz, sözleşme, mahal, aktivite, miktar, belge ve dönem ayrı nesneler mi; yoksa bütün bilgi bir tablo hücresinde mi tutuluyor?

Ön hazırlık: kendi hakediş modelinizi belgeleyin

Satıcı görüşmesinden önce mevcut süreci bir sayfalık haritaya dönüştürün. Hakedişi kim başlatıyor, ölçümü kim yapıyor, kim kontrol ediyor, hangi belgeler zorunlu, itiraz nasıl yönetiliyor, hangi kesintiler uygulanıyor, dönem ne zaman kilitleniyor ve sonuç nereye aktarılıyor? Kamu ve özel iş, ana yüklenici ve taşeron, birim fiyat ve götürü bedel gibi modelleri ayrı varyantlar olarak yazın.

Son altı aydan şu ölçümleri alın: hazırlama süresi, kontrol süresi, iade sayısı, eksik belge oranı, sonradan düzeltme sayısı, dönem kapanış gecikmesi, ihtilaflı tutar ve manuel veri giriş saati. Yazılımın değeri bu tabanla karşılaştırılacaktır. Mevcut sorun veri kalitesiyse yalnız yeni ekran sorunu çözmez; poz ve kod standardı da gerekir.

Anonimleştirilmiş demo paketi oluşturun: yaklaşık 30 poz, iki keşif revizyonu, iki hakediş dönemi, bir yeni fiyat, bir fiyat farkı, avans ve teminat kesintisi, reddedilen miktar, üç ataşman ve bir taşeron sözleşmesi. Her satır için beklenen sonucu hesaplayın. Satıcı aynı paketi canlı kurabilmelidir.

Özellik 1: Sözleşme bazının ve revizyonların korunması

Hakedişin referansı onaylı sözleşme bazıdır. Program ilk sözleşme bedelini, poz listesini, miktar ve birim fiyatları dondurmalı; sonraki değişiklikleri eski değerin üzerine yazmadan ayrı kayıt olarak yönetmelidir. İş artışı, iş eksilişi, yeni fiyat, kapsam transferi ve revizyon bekleyen değişikliklerin durumları ayrılmalıdır.

Demoda bir pozun sözleşme miktarını 100'den 130'a çıkarın. Sistem başlangıç miktarı 100, onaylı değişiklik 20 ve bekleyen değişiklik 10 olarak gösterebiliyor mu? İlk hakediş, sonradan yapılan revizyon nedeniyle geçmişe dönük değişiyor mu? Değişikliğin dayanak yazısı, onay tarihi, etkili olduğu dönem ve yetkili kişisi görülebiliyor mu?

Kırmızı bayrak, yalnız “güncel sözleşme” tablosu bulunmasıdır. Tarihsel baz kaybolursa hangi dönemde hangi koşulun geçerli olduğu ispatlanamaz. Ayrıca tüm değişiklikleri tek “revize bütçe” alanında toplamak, fiyat ve miktar etkisini ayırmayı engeller.

Özellik 2: Poz, mahal, WBS ve maliyet kodu ilişkisi

Poz hakedişin ticari birimidir; fakat sahadaki üretim çoğunlukla mahal ve iş programı üzerinden yönetilir. Program bir pozun birden fazla mahal ve aktiviteye; bir aktivitenin de birden fazla poza bağlanmasına izin vermelidir. ERP maliyet koduyla eşleme ayrıca tutulmalıdır. Bu ilişkiler sayesinde ödeme, fiziksel ilerleme ve maliyet karşılaştırılabilir.

Demoda aynı sıva pozunu üç blok ve altı katta dağıtın. Saha ekibi kat bazında miktar girerken hakediş cetveli sözleşme pozu bazında toplanabilmeli; yönetici blok bazında kalan işi görebilmelidir. Birim dönüşümü gerekiyorsa kural açık ve sürümlü olmalıdır. Poz numarası değiştiğinde geçmiş belgeler kopmamalıdır.

Kırmızı bayrak, her rapor için ayrı kod tablosu veya serbest metin eşlemesidir. İsim benzerliğiyle otomatik eşleme sessiz hatalar üretir. Değişmez kimlik, kurumsal kod sözlüğü ve kontrollü eşleme ekranı aranmalıdır.

Özellik 3: Metraj, ataşman ve kanıt zinciri

Ödeme miktarı kaynağından kopmamalıdır. Metraj föyü; ölçüm satırı, formül, birim, mahal, çizim ve revizyonu taşımalıdır. Ataşman kroki, ölçü ve hesapla ilişkilendirilmeli; fotoğraf, tutanak, laboratuvar sonucu veya teslim belgesi gerektiğinde aynı satıra bağlanabilmelidir. Bir belge birden çok satırı kanıtlayabilir; ilişki çoktan çoğa desteklenmelidir.

Demoda ölçü değerlerinden birini değiştirin. Etkilenen hakediş satırı, toplam miktar ve onay durumu otomatik güncelleniyor mu? Onaylı ataşman değiştirilmeye çalışıldığında yeni revizyon mu açılıyor? Belgenin kim tarafından ne zaman yüklendiği, kontrol edildiği ve onaylandığı görülebiliyor mu? Mobil sahada çevrimdışı ölçüm ve fotoğraf alınıp eşitlenebiliyor mu?

Kırmızı bayrak, yalnız PDF eklemek ve satırla anlamsal bağ kuramamaktır. Dosya arşivi kanıtın varlığını gösterir; hangi miktarı kanıtladığını göstermez. Ayrıca fotoğraf meta verisinin korunması ve sonradan yüklenen görsellerin ayrılması önemlidir.

Özellik 4: Dönemsel miktar ve kümülatif kontrol

Her poz için sözleşme miktarı, önceki dönem, bu dönem, toplam ve kalan miktar net görünmelidir. Sistem toplamın onaylı sınırı aşmasını engellemeli veya yetkili istisna akışına sokmalıdır. Negatif düzeltme, iade, yeniden ölçüm ve önceki dönem hatası için tanımlı yöntem bulunmalıdır.

Demoda ilk dönemi kapatın. İkinci dönemde ilk döneme ait miktarın hatalı olduğu anlaşılsın. Program kapanmış kaydı sessizce değiştirmeden bu dönem düzeltmesi oluşturabiliyor mu? Cetvelde ve denetim izinde eski ve yeni durum anlaşılır mı? Yuvarlama farkları satır ve genel toplamda kontrol ediliyor mu?

Kırmızı bayrak, kümülatif miktarın kullanıcı tarafından doğrudan yazılmasıdır. Bu durumda önceki + bu dönem = toplam eşitliği bozulabilir. Program hesaplanan alanı korumalı, istisnayı açıklama ve onayla yönetmelidir.

Özellik 5: Birim fiyat, yeni fiyat ve fiyat farkı motoru

Birim fiyat yalnız bir sayı değildir; para birimi, geçerlilik, vergi dahil/hariç durumu, analiz, revizyon ve onay kaynağı vardır. Yeni fiyat süreci teklif, analiz, müzakere ve onay adımlarını taşımalıdır. Bir pozun belirli miktarı eski, kalan kısmı yeni koşulla değerlendirilecekse dönem ve miktar ayrımı yapılabilmelidir.

Fiyat farkı motoru endeks kaynağı, baz tarih, uygulama ayı, ağırlık katsayıları ve sözleşme istisnalarını yapılandırabilmelidir. Kullanılan tüm parametreler çıktı üzerinde ve denetim izinde görünmelidir. Formül değişikliği eski dönem hesabını bozmamalı; sürüm ve yürürlük tarihiyle uygulanmalıdır.

Demoda iki farklı endeks dönemi, eksik endeks için geçici hesap ve daha sonra kesinleşen düzeltme çalıştırın. Kırmızı bayrak, satıcının her yeni sözleşme formülü için kod değişikliği istemesi veya formül sonucunu gösterip ara değerleri saklamamasıdır. Otomasyon uzman kontrolünü kaldırmaz; sözleşmeye uygunluk yetkili ekipçe doğrulanmalıdır.

Özellik 6: Kesinti, avans, teminat ve mahsup esnekliği

Hakediş net tutarı, brüt imalat değerinden farklıdır. Avans mahsupları, nakit ve teminat kesintileri, gecikme veya kalite kesintisi, stopaj, vergi, sigorta, malzeme avansı ve önceki dönem düzeltmeleri sözleşmeye göre değişir. Program kuralı satır, grup veya genel toplam seviyesinde uygulayabilmelidir.

Kesintinin sabit tutar, oran, kademeli oran, üst sınır veya belirli tarihe kadar geçerli olması gerekebilir. Teminat birikimi ve iade koşulları izlenmeli; avansın hangi baz üzerinden mahsup edildiği açık olmalıdır. Aynı kesintinin hem taşeron hesabında hem ERP'de iki kez uygulanması entegrasyon tasarımıyla engellenmelidir.

Demoda teminat üst sınırına ulaşıldığı dönemi ve kısmi iade senaryosunu çalıştırın. Ara hesap değerleri görülebiliyor mu? Kırmızı bayrak, formüllerin yalnız geliştirici tarafından değiştirilebilmesi veya kullanıcıların formülü serbestçe değiştirip onay izi bırakmamasıdır.

Özellik 7: İşveren ve taşeron hakedişlerinin birlikte yönetimi

İşverenden tahsil edilen değer ile taşerona ödenen değer bire bir değildir. Kapsam, poz, miktar, zamanlama, kesinti ve fiyat yapısı değişebilir. Program iki sözleşmeyi ortak iş kırılımında ilişkilendirerek kazanılan ve ödenen miktarı, birim marjı, kapsam boşluğunu ve nakit zamanlamasını göstermelidir.

Aylık taşeron hakedişi akışında taşeron talebini portal veya kontrollü form üzerinden iletebilir; saha ve kalite ekipleri miktarı doğrular; ticari ekip fiyat ve kesintiyi kontrol eder; finans onay sonucunu alır. Taşeron yalnız kendi sözleşme ve belgelerini görmelidir. İç marj, diğer taşeron ve işveren ticari notları dış kullanıcıya açılmamalıdır.

Kırmızı bayrak, işveren pozlarını taşeronlara zorla bire bir kopyalamaktır. Eşleme esnek olmalı, farklar raporlanmalıdır. Aynı imalatın birden çok taşeron paketiyle yapılması ve kapsam transferi desteklenmelidir.

Özellik 8: İş akışı, yetki ayrılığı ve elektronik onay

Hazırlayan, ölçen, kontrol eden ve onaylayan roller ayrılmalıdır. Yetki tutar, proje, sözleşme, şirket ve işlem türüne göre değişebilir. Vekâlet, izin, süre aşımı, iade, yeniden gönderim ve eskalasyon akışları desteklenmelidir. Onay yalnız butona basmak değil, o anda görülen veri sürümünü kabul etmektir.

Demoda kontrol sonrası miktarı değiştirin. Önceki onay geçersizleşiyor mu; ilgili role yeniden görev gidiyor mu? Kullanıcı kendi hazırladığı hakedişi son onaya taşıyabiliyor mu? Vekil kullanıcının işleminde hem asıl yetki hem vekâlet dönemi kaydediliyor mu? Elektronik imza gerekiyorsa belgenin hash'i ve imza doğrulaması saklanıyor mu?

Kırmızı bayrak, ortak hesap kullanımı, e-posta ile “olur” alınması veya onay sonrası verinin değişebilmesidir. Mobil onay kolay olmalı; fakat özet ekran kritik miktar, kesinti ve değişiklikleri görünür kılmalıdır.

Özellik 9: Dönem kilidi, sürümleme ve denetim izi

Kapanmış hakediş muhasebe ve ödeme kaydının dayanağıdır. Program dönem kilidi uygulamalı; yetkili düzeltmeyi bile görünür bir işlem olarak kaydetmelidir. Kim, ne zaman, hangi alanı, eski ve yeni hangi değer arasında, hangi gerekçeyle değiştirdi soruları yanıtlanmalıdır. Log yalnız teknik veri tabanında değil, yetkili kullanıcıların anlayacağı raporda bulunmalıdır.

Belge sürümü, hesap motoru sürümü ve kullanılan endeks seti de denetim kapsamındadır. Yıllar sonra aynı hakediş yeniden üretildiğinde aynı sonuç alınabilmelidir. Kullanıcı veya proje silinse bile tarihsel kimlik ve işlem korunmalıdır. Saat dilimi ve tarih formatı çok ülke projelerinde önem kazanır.

Demoda yönetici yetkisiyle kapanmış satırı değiştirmeyi deneyin. Sistem engelliyor mu, kontrollü düzeltme mi açıyor? Kırmızı bayrak, “veri tabanında log var” denilip örnek bir işlemin kaynaktan çıktıya gösterilememesidir.

Özellik 10: ERP, muhasebe ve e-belge entegrasyonu

Hakedişin teknik hesabı ile finansal kaydı arasında manuel köprü hata ve gecikme yaratır. Onaylanan hakediş ERP'ye sözleşme, tedarikçi, maliyet kodu, tutar, kesinti ve vergi referanslarıyla aktarılmalıdır. ERP'de oluşan tahakkuk, fatura ve ödeme kimliği platforma geri dönmelidir. Böylece teknik ekip ödeme durumunu görebilir, finans kaynak belgeye inebilir.

Entegrasyon API, dosya veya mesaj kuyruğuyla yapılabilir; yöntemden çok kontrol önemlidir. Çift gönderim aynı fişi iki kez oluşturmamalı. Geçersiz maliyet kodu hata kuyruğuna düşmeli, sorumlu ve çözüm süresi görünmelidir. ERP dönemi kapalıysa kayıt kaybolmamalı veya yanlış döneme sessizce atılmamalıdır.

Demoda aynı aktarımı iki kez çalıştırın, ERP'yi erişilemez yapın ve bir satırın kodunu bozun. Kırmızı bayrak, entegrasyonun yalnız toplu Excel dışa aktarma olarak sunulması veya hata durumunun teknik logda kalmasıdır.

Özellik 11: Raporlama, nakit ve tamamlanma tahmini

Standart hakediş kapağı ve icmal zorunludur ama yönetim ihtiyacı bunun ötesindedir. Program sözleşme bedeli, onaylı/bekleyen değişiklik, kazanılan değer, faturalama, tahsilat, taşeron ödeme, kesinti birikimi ve nakit tahminini birlikte sunmalıdır. Raporlar proje, işveren, taşeron, disiplin, poz grubu ve dönem düzeyinde filtrelenmelidir.

Her KPI kaynak satıra kadar izlenmelidir. Grafik güzel görünse bile veri tazeliği, para birimi, KDV durumu ve tarih aralığı açık değilse karar riski taşır. Yönetim raporunda “bekleyen onay nedeniyle faturalanamayan tutar” ve “kanıtı eksik miktar” gibi eyleme dönük göstergeler bulunmalıdır.

Maliyet aşımı erken tespiti hakediş verisini taahhüt ve tamamlanma tahminiyle birleştirir. Kırmızı bayrak, yalnız geçmişi raporlayan ve tahmin gerekçesini saklamayan sistemdir.

Özellik 12: Mobil deneyim, çevrimdışı çalışma ve kullanılabilirlik

Hakediş merkez ofiste hazırlanabilir, ancak miktar ve kanıt sahada doğar. Mobil uygulama mahal ve poz seçimini hızlandırmalı; ölçüm, fotoğraf, imza, açıklama ve kontrol listesini çevrimdışı toplayabilmelidir. Bağlantı geldiğinde eşitleme durumu, çakışma ve hata kullanıcıya açık olmalıdır.

Kullanılabilirlik ölçülebilir. Saha mühendisi yeni miktar ve ataşman kaydını kaç dakikada tamamlıyor? Yanlış poz seçme olasılığı nedir? 200 poz arasında arama, favori ve QR kod desteği var mı? Eldivenli kullanım, düşük ışık, zayıf cihaz ve büyük dosya koşulları denenmelidir. Responsive masaüstü sayfası, yerel çevrimdışı deneyimin yerine geçmeyebilir.

Kırmızı bayrak, demoda yalnız hızlı internet ve önceden hazırlanmış kayıt kullanılmasıdır. Uçak modunda veri oluşturun, aynı kaydı iki cihazda değiştirin ve senkronizasyon sonucunu inceleyin.

12 özelliği puanlamak için kanıt ölçeği

Her özelliğe 1–5 vermek yerine kanıt seviyesini puanlayın:

Özelliklerin ağırlığı eşit olmayabilir. Kamu yapım işinde formül ve belge uygunluğu; özel EPC projesinde değişiklik, çok para birimi ve claim bağlantısı; yoğun taşeronlu projede portal ve kapsam eşleme daha yüksek ağırlık alır. Dönem kilidi, yetki ayrılığı, veri dışa aktarımı ve hesap yeniden üretilebilirliği gibi bazı maddeleri veto kriteri yapın.

Güvenlik ve veri koruma kontrol listesi

Hakediş verisi ticari sır, sözleşme, kişi ve banka bilgisi içerebilir. Rol tabanlı erişim proje ve şirket sınırına kadar inmelidir. Dış taşeron kullanıcısı iç not veya başka sözleşme görmemelidir. Çok faktörlü doğrulama, tek oturum açma, cihaz ve oturum politikası, şifreli aktarım/saklama, yedekleme ve felaket kurtarma kanıtı istenmelidir.

Bulut hizmetinde veri konumu, alt yükleniciler, yedek bölgesi, olay bildirimi, hizmetten çıkış ve veri silme süreçleri sözleşmede yer almalıdır. On-premise tercihinde kontrol kurumda olur fakat güvenlik güncellemesi, izleme, kapasite ve yedek sorumluluğu da kuruma geçer. Satıcının sertifikası ürünün doğru yapılandırıldığını tek başına kanıtlamaz.

Denetim loglarına erişim ayrıca sınırlandırılmalı, logların değiştirilmesi engellenmelidir. Rapor dışa aktarımlarında filigran ve hassas alan maskeleme değerlendirilebilir. Canlı veriyi destek ortamına kopyalama politikası açık olmalıdır.

Yapay zekâ özelliklerini değerlendirirken sorulacak sorular

Yapay zekâ ataşman sınıflandırabilir, sözleşmeden kesinti maddesi önerebilir, anormal miktarı işaretleyebilir ve dönem özetini yazabilir. Ancak finansal hak doğuran hesabı açıklanamaz model kararına bırakmak uygun değildir. Model öneri üretmeli, kaynak metni göstermeli ve insan onayı istemelidir.

Satıcıya şu soruları sorun: Hangi veri modele gönderiliyor? Yurt dışı aktarım var mı? Kurum verisi model eğitimi için kullanılıyor mu? Model ve istem sürümü kaydediliyor mu? Yanlış öneri nasıl düzeltiliyor? Güven skoru var mı? Kullanıcı otomasyonu kapatabiliyor mu? Sözleşme maddesi alıntısının kaynağına gidilebiliyor mu?

Yapay zekâ başarısı “kaç özet üretildi?” ile değil, inceleme süresini ne kadar azalttığı ve kaç riskli satırı doğru işaretlediğiyle ölçülmelidir. Yanlış pozitif ve yanlış negatif ayrı izlenmelidir.

Uygulama ve veri geçişi planı

Program seçildikten sonra ilk iş tüm Excel'leri içe aktarmak değildir. Kurumsal poz, birim, sözleşme, kesinti ve onay sözlüğü temizlenmelidir. Aktif projeler için başlangıç bakiyesi belirlenir: son onaylı hakediş, kümülatif miktar, kalan sözleşme, kesinti ve avans durumu mutabık şekilde yüklenir. Eski dönem ayrıntısı gerektiğinde salt okunur arşivde tutulabilir.

Pilot proje tipik karmaşıklıkta ve iş birliğine açık ekiple seçilmelidir. İlk iki dönem paralel kontrol yapılabilir; fakat kullanıcıların iki sistemi süresiz doldurmasına izin verilmemelidir. Kabul sonrası eski araç yeni dönem için kapatılmalıdır. Süper kullanıcılar ticari, saha ve finans rollerinden seçilir.

Veri geçişi kabulünde toplam tutar kadar satır sayısı, miktar, para birimi, kesinti birikimi ve belge bağlantısı örneklemle doğrulanmalıdır. Mutabakat raporu proje tarafı ve finans tarafından imzalanmalıdır.

İlk 90 gün başarı göstergeleri

Başarı yalnız kullanıcı giriş sayısı değildir. Aşağıdaki KPI'lar daha anlamlıdır:

• Hakediş hazırlama ve onay çevrim süresi,
• Eksik kanıt nedeniyle iade edilen satır oranı,
• Kapanış sonrası düzeltme sayısı ve tutarı,
• Otomatik ERP aktarım oranı ve hata çözüm süresi,
• Poz–mahal–maliyet kodu eşleme doğruluğu,
• Mobil kaynaktan gelen ölçüm oranı,
• İhtilaflı miktarın toplam hakedişe oranı,
• Bekleyen onay nedeniyle faturalanamayan tutar,
• İşveren tahsilatı ile taşeron ödeme zaman farkı,
• Kullanıcı başına manuel yeniden giriş saati.

Hedefler pilot öncesi taban değere göre konmalıdır. “Yüzde 100 otomasyon” gerçekçi olmayabilir; istisnaların kontrollü ve ölçülebilir olması daha önemlidir. İlk 30 günde veri ve eğitim, 60 günde çevrim süresi, 90 günde finansal ve operasyonel sonuçlar değerlendirilir.

Sözleşmeye yazılması gereken kabul maddeleri

Teknik şartname ürün broşürünü kopyalamamalıdır. Sonuç odaklı kabul maddeleri yazılmalıdır: iki dönemlik örnek veriyle hesap sonucu; kapanmış dönemin değiştirilememesi; belirli kullanıcı yükünde yanıt süresi; çevrimdışı kaydın eşitlenmesi; API hata ve tekrar deneme davranışı; rol sınırlarının testi; veri ve eklerin açık formatta dışa aktarılması; yedekten geri dönüş süresi.

Hesap motoru veya kritik mevzuat güncellemesinin destek süresi, sürüm bildirimi ve geriye dönük etki analizi tanımlanmalıdır. Özel geliştirmelerin ürün yükseltmelerinde nasıl korunacağı açıklanmalıdır. Hizmet seviyesi yalnız sistem erişilebilirliği değil, kritik hakediş dönemindeki destek yanıtını kapsamalıdır.

Çıkış planı başlangıç sözleşmesinde yer almalıdır. Kurum verinin sahibi olmalı; sözleşme sonunda veri tabanı dökümü, dosyalar, sözlük ve ilişki anahtarlarını alabilmelidir. Salt PDF arşiv uzun vadeli erişim ve göç için yeterli değildir.

Hakediş veri sözlüğü için örnek çekirdek alanlar

Kurumlar program almadan önce en az şu alanları ortaklaştırmalıdır: sözleşme ve revizyon kimliği; poz ve poz grubu; birim; mahal/WBS; başlangıç, onaylı ve bekleyen miktar; önceki, bu dönem, toplam ve kalan miktar; birim fiyat ve para birimi; yeni fiyat statüsü; metraj/ataşman kimliği; kalite kabulü; kesinti türü ve matrahı; hazırlayan, kontrol eden, onaylayan; dönem ve kilit durumu; ERP belge kimliği. Her alan için tanım, kaynak, sahibi, zorunluluk, değişiklik yetkisi ve saklama kuralı yazılmalıdır.

Bu sözlük, iki satırın “aynı” görünüp farklı anlam taşımasını önler. Örneğin toplam miktarın onaylı kümülatif değer mi yoksa saha tahmini mi olduğu açıklanır. Birim ve yuvarlama hassasiyeti belirlenir. Göç, entegrasyon ve rapor kabul testleri aynı sözlüğe dayanır; böylece satıcıya özel ekran dili kurumun ticari gerçeğinin önüne geçmez.

Sözlük yalnız başlangıç dokümanı değildir. Yeni sözleşme türü, kesinti veya entegrasyon alanı eklendiğinde veri sahibi değişikliği inceler; rapor ve API etkisini kaydeder. Test ortamında iki dönemlik regresyon hesabı yeniden çalıştırılır, önceki sonuçla farkı beklenen gerekçeye bağlanır. Böylece küçük bir konfigürasyon değişikliği kapanmış projeleri veya yönetim raporlarını sessizce bozmaz. Kurum ayrıca yılda en az bir kez kullanılmayan alanları, serbest metin oranını ve kod eşleme hatalarını gözden geçirerek modeli sade tutar. Her yeni proje, kurumsal sözlüğü kopyalar ama proje özelindeki istisnayı ayrı ve onaylı bir katmanda yönetir.

Program canlıya alındıktan sonra ilk üç hakediş döneminde hesap sonuçları risk tabakalı örneklemle bağımsız kontrol edilmelidir. Yüksek tutarlı, yeni fiyatlı, düzeltmeli ve çok kesintili satırlar özellikle seçilir. Fark bulunursa yalnız satır düzeltilmez; kural, ana veri, entegrasyon veya eğitim kök nedeni belirlenir ve regresyon paketine yeni test eklenir. Böylece kurum her hata ile kontrol setini güçlendirir.

Sonuç: özellik değil kanıt satın alın

Hakediş programında on iki özellik birbirinden bağımsız değildir. Sözleşme bazını korumayan sistemde doğru dönem hesabı; metraj ve kanıt bağı olmayan sistemde güvenilir onay; dönem kilidi olmayan sistemde sağlam denetim izi; ERP entegrasyonu olmayan sistemde hızlı kapanış mümkün değildir. Bu nedenle değerlendirme, menü işaretlemek yerine uçtan uca iki dönemlik senaryo üzerinden yapılmalıdır.

İlk adım olarak kendi sözleşme varyantlarınızı, istisnalarınızı ve KPI tabanınızı çıkarın. Ardından kanıt ölçeğiyle puan kartı oluşturun, saha ve finans kullanıcılarını aynı demoya alın ve veto kriterlerini baştan ilan edin. Construction Suite Pro kapsamını ve hakediş–maliyet yeteneğini inceleyebilir; veri paketinize dayalı değerlendirme için ön görüşme talep edebilirsiniz.

Resmî ve birincil kaynaklar

• Çevre, Şehircilik ve İklim Değişikliği Bakanlığı: Ara ve kesin hakediş süreçlerinde istenen belge örnekleri
• Yüksek Fen Kurulu: İnşaat ve tesisat birim fiyatları ile sözleşme uygulama kaynakları
• Yapı İşleri Genel Müdürlüğü: Yapım işleri, hakediş ve yaklaşık maliyet açıklamaları

Sözleşme ve mevzuat uygulaması proje türüne ve tarihe göre değişebilir. Bu içerik ürün değerlendirme rehberidir; hukuki, mali veya teknik müşavirlik görüşü yerine geçmez.