HAKEDİŞ DOSYASINDA EVRAK KONTROLÜ VE İMZA AKIŞI KURGULAMAK

Hakediş dosyası, sahadaki gerçekleşen işin finansal karşılığa dönüştüğü en kritik köprüdür. Bu köprüde evrak kontrolü dağınık ilerlerse, tek bir eksik belge tüm onay hattını durdurur; geciken ödeme, sahada motivasyon kaybı ve yönetimde güven erozyonu olarak geri döner.

İyi kurgulanan bir evrak kontrolü ve imza akışı, “kim neyi ne zaman kontrol etmeli” sorusunu şeffaflaştırarak süreci hızlandırır. Üstelik yalnızca hız değil, izlenebilirlik, uyumluluk ve kanıta dayalı karar üretmekle de ilgilidir. Böylece hem proje ekipleri hem de finans, satınalma ve üst yönetim aynı veri üzerinden konuşur.

Bu yazıda hakediş dosyasında evrak kontrolü ve imza akışı kurgulamak için rol dağılımını netleştirmeyi, belge doğrulama adımlarını standartlaştırmayı, revizyon döngüsünü yönetmeyi ve denetim iziyle güvence oluşturmayı ele alacağız. Ayrıca yazılım ekibinin uygulayabileceği pratik akış örnekleri ve sorgu örnekleri de bulacaksınız.

Hakediş dosyasında evrak kontrolü çerçevesini kurmak

İlk adım, “evrak kontrolü”nün neyi kapsadığını ekipler arasında aynı anlama getirmektir. Hakediş dosyası, sözleşme, keşif, metraj, ataşman, puantaj, irsaliye, tutanak, fotoğraflı saha kanıtı, fiyat farkı hesapları, kesinti kalemleri ve varsa alt yüklenici icmal gibi bileşenlerle oluşur. Her bileşenin hangi kaynağa dayandığı, hangi formatta sunulduğu ve hangi kriterle “tam” sayıldığı tanımlanmalıdır.

Bu çerçeveyi kurarken iki temel hedef gözetilmelidir: Birincisi, eksik ve hatalı evrakı en erken aşamada yakalamak; ikincisi, doğru evrakın gereksiz yere tekrar tekrar kontrol edilmesini önlemektir. Bu nedenle kontrol listelerini ortaklaştırmak, “kontrol edildi” işaretini tek bir yerde tutmak ve tüm adımların aynı doğrulama mantığına bağlanması önemlidir.

Evrak setini standarda bağlamak ve kapsamı kilitlemek

Projeden projeye değişen evrak beklentisi, yazılım tarafında sonsuz istisnaya dönüşebilir. Bunun yerine “zorunlu”, “koşullu” ve “opsiyonel” evrak kategorileri oluşturmak gerekir. Örneğin fiyat farkı uygulanan sözleşmelerde fiyat farkı hesap çizelgesi koşullu zorunlu sayılmalıdır; alt yüklenici bulunan paketlerde alt yüklenici icmal seti otomatik olarak devreye alınmalıdır.

Belge doğrulama kriterlerini ölçülebilir hale getirmek

“Uygun” veya “tam” gibi öznel ifadeler, kontrol adımında gereksiz tartışma çıkarır. Bunun yerine ölçülebilir kriterler tanımlamak gerekir: tarih aralığı uyuşması, imza/paraf varlığı, referans numarası eşleşmesi, birim fiyat veya poz kodu eşleşmesi, metraj toplamının icmalle uyumu gibi. Yazılım tarafında bu kriterlerin bir kısmı otomatik kontrol kurallarıyla, bir kısmı ise insan onayıyla yürütülebilir.

Rol tabanlı yetkilendirmeyi ve sorumlulukları netleştirmek

Hakediş onayı, çoğu kurumda “herkesin biraz baktığı ama kimsenin tam sahiplenmediği” bir alana kayabilir. Bu riski azaltmak için rol tabanlı yetkilendirmeyi netleştirmek gerekir. Her adımın bir sahibi, bir yedeği ve bir eskalasyon kuralı olmalıdır. Böylece süreç “kişiye bağlı” olmaktan çıkar ve kurumsal hale gelir.

Kontrol rolleri, onay rolleri ve imza rolleri ayrıştırmak

Kontrol rolü evrak bütünlüğünü ve hesap doğruluğunu incelerken, onay rolü işin kapsam ve uygunluğunu, imza rolü ise yetki sınırları içindeki nihai bağlayıcılığı temsil eder. Tek kişinin tüm rolleri üstlenmesi kısa vadede hızlı görünse de uzun vadede hata riskini artırır. Bu ayrıştırma, denetim izinin temiz kalmasını ve sorumlulukların tartışmasız olmasını sağlar.

Yetki matrisini tutarlı hale getirmek ve değişikliği yönetmek

Yetki matrisi; tutar aralıkları, proje türleri, bölge/şantiye kırılımları ve sözleşme tiplerine göre değişebilir. Bu değişkenliği yönetmek için “matris versiyonlama” yaklaşımı iyi çalışır. Yetki kuralı değiştiğinde, devam eden hakedişlerde hangi matrisin geçerli olacağı açıkça belirtilmelidir. Aksi halde aynı dosya üzerinde farklı tarihlerde farklı yetkilerle işlem yapılması uyumsuzluk doğurur.

İmza akışını adım adım kurgulamak ve otomatikleştirmek

İmza akışı, yalnızca “kim imzalayacak” listesinden ibaret değildir. Akış; hangi adımda hangi kontrolün zorunlu olduğu, bir adım reddedildiğinde sürecin nereye döneceği, kimin bilgilendirileceği ve hangi SLA ile takip edileceği gibi detaylarla birlikte tasarlanmalıdır. İyi tasarlanmış bir imza akışı, revizyon yönetimini kolaylaştırır ve gereksiz e-posta trafiğini azaltır.

Durum modeli ile yaşam döngüsünü tanımlamak

Hakediş dosyası için bir durum modeli (state machine) tanımlamak, yazılımda basit ve tutarlı bir akış sağlar. Örnek durumlar: Taslak, Evrak Toplama, Evrak Kontrol, Teknik Onay, Finans Kontrol, İmza Bekliyor, Onaylandı, Revizyonda, İptal. Her durumun giriş kriteri ve çıkış kriteri belirlenmelidir. Böylece “neden bekliyor” sorusu yanıtlanabilir hale gelir.

SLA, eskalasyon ve bildirim akışını kurgulamak

Akışın tıkanma noktaları genellikle “kimin üzerinde bekliyor” ve “ne zamandır bekliyor” sorularında ortaya çıkar. Bu nedenle her adım için SLA tanımlamak, gecikmelerde otomatik eskalasyon üretmek gerekir. Eskalasyon; hatırlatma bildiriminden yönetici bilgilendirmeye, kritik gecikmede alternatif onaycıya yönlendirmeye kadar kademeli tasarlanmalıdır. Böylece süreç insan takibinden bağımsız şekilde işletilebilir.

{
  "workflow": "hakedis_onay",
  "version": "1.0",
  "states": [
    "TASLAK",
    "EVRAK_TOPLAMA",
    "EVRAK_KONTROL",
    "TEKNIK_ONAY",
    "FINANS_KONTROL",
    "IMZA_BEKLIYOR",
    "ONAYLANDI",
    "REVIZYONDA"
  ],
  "transitions": [
    { "from": "TASLAK", "to": "EVRAK_TOPLAMA", "byRole": ["SantiyeMuhendisi"] },
    { "from": "EVRAK_TOPLAMA", "to": "EVRAK_KONTROL", "byRole": ["DokumanKontrol"] },
    { "from": "EVRAK_KONTROL", "to": "TEKNIK_ONAY", "byRole": ["KontrolAmiri"], "slaHours": 24 },
    { "from": "TEKNIK_ONAY", "to": "FINANS_KONTROL", "byRole": ["ProjeMuduru"], "slaHours": 48 },
    { "from": "FINANS_KONTROL", "to": "IMZA_BEKLIYOR", "byRole": ["Finans"], "slaHours": 24 },
    { "from": "IMZA_BEKLIYOR", "to": "ONAYLANDI", "byRole": ["YetkiliImza"], "slaHours": 72 },
    { "from": "*", "to": "REVIZYONDA", "byRole": ["DokumanKontrol", "KontrolAmiri", "Finans"] }
  ]
}

Bu örnek; rol, durum ve SLA’yı tek bir şemada toplamak için kullanılabilir. Uygulamada ek alanlar (tutar limiti, paket türü, e-imza sağlayıcı parametreleri) eklenebilir; ancak temel fikir aynıdır: Akışı okunabilir ve denetlenebilir bir modele dönüştürmek.

Revizyon yönetimini tasarlamak ve geri dönüşleri azaltmak

Hakediş sürecinde revizyon kaçınılmazdır; önemli olan revizyonu “kayıp zaman” olmaktan çıkarıp yönetilebilir bir döngüye çevirmektir. Revizyonun temel sebepleri genellikle eksik evrak, tutarsız metraj, hatalı birim fiyat eşleşmesi veya onaycıların farklı beklentileridir. Bu sebeplerin her biri için ayrı bir geri dönüş nedeni seti tanımlamak, kök neden analizi yapmayı kolaylaştırır.

Revizyon nedenlerini sınıflandırmak ve zorunlu not alanı koymak

“Revize et” butonuna basmak kolaydır; ancak gerekçe belirtilmezse aynı hata tekrar eder. Bu nedenle revizyon nedenlerini sınıflandırmak (eksik belge, yanlış dönem, tutarsız metraj, sözleşme dışı kalem, imza eksikliği gibi) ve her revizyonda açıklama notunu zorunlu yapmak gerekir. Notun hedefi, karşı tarafın “ne yapması gerektiğini” açıkça anlatması olmalıdır.

Versiyonlama ile karşılaştırılabilirlik sağlamak

Her revizyon bir “hakediş versiyonu” üretmelidir. Versiyonlar arasında değişen kalemler, eklenen/çıkarılan belgeler ve hesap farkları karşılaştırılabilir olmalıdır. Bu yaklaşım, onaycıların aynı dosyayı baştan okumak zorunda kalmasını azaltır. Aynı zamanda denetim izinde hangi değişikliğin hangi gerekçeyle yapıldığı görülebilir.

Bir görsel anlatı gibi düşünün: Evrak seti tek bir kontrol listesi üzerinden toparlanır, otomatik kurallar temel tutarlılık denetimini yapar, insan kontrolü ise istisnalara odaklanır. Bu düzen, revizyon döngüsünü kısaltır ve iş yükünü doğru yere taşır.

Denetim izi, audit log ve kanıt üretimini güvenceye almak

Kurumsal ölçekte hakediş süreçlerinde en kritik beklentilerden biri denetlenebilirliktir. Kim hangi adımda hangi kararı verdi, hangi belgeye dayanarak onayladı, hangi tarihte hangi revizyon yapıldı gibi soruların yanıtı net olmalıdır. Burada “audit log” sadece teknik bir kayıt değil, kurumsal güvenin temel bileşenidir.

Audit log kapsamını belirlemek ve asgari veriyi standarda bağlamak

Asgari kayıt seti genellikle şunları içerir: işlem yapan kullanıcı, rol, işlem tipi (onay, red, revizyon, ekleme, silme), tarih-saat, etkilenen nesne (belge, kalem, icmal), önceki değer ve yeni değer. Bu kayıtlar değiştirilemez şekilde saklanmalı, raporlanabilir olmalı ve gerektiğinde dış denetim için export edilebilir olmalıdır.

Uygunluk, e-imza ve bütünlük kontrollerini tamamlamak

İmza adımında e-imza kullanılıyorsa, imza sağlayıcısının döndürdüğü doğrulama verisi (hash, sertifika bilgisi, zaman damgası) dosyayla ilişkilendirilmelidir. Böylece “imza atıldı” demek yerine, “hangi sertifika ile hangi tarihte imzalandı” kanıtı tutulur. Bütünlük kontrolü, hukuki ve finansal itirazlarda kurumun elini güçlendirir.

SELECT
  hakedis_id,
  version_no,
  action_type,
  actor_user_id,
  actor_role,
  action_time,
  detail_json
FROM audit_log
WHERE hakedis_id = :hakedisId
  AND action_time >= :startDate
ORDER BY action_time ASC;

Bu örnek sorgu; belirli bir hakediş dosyasının belirli dönem içindeki tüm hareketlerini kronolojik görmeye yarar. Uygulamada detail_json alanı içinde değişen kalemler, gerekçe notu ve hedef durum gibi veriler saklanabilir. Böylece hem operasyon ekipleri hem de denetim ekipleri aynı kaynağa dayanarak inceleme yapabilir.

Entegrasyon ve veri kalitesini süreçle birlikte geliştirmek

Hakediş dosyasındaki evrak kontrolü ve imza akışı, çoğu zaman farklı sistemlerin sınırında çalışır: ERP, e-fatura/e-arşiv, doküman yönetimi, saha uygulamaları, sözleşme yönetimi, insan kaynakları (puantaj) ve satınalma sistemleri. Bu entegrasyonlar yoksa süreç manuel yükle ilerler; entegrasyon varsa veri kalitesi sorunu ortaya çıkabilir. Her iki durumda da amaç, tekil doğruluk kaynağını (single source of truth) yaklaşmak olmalıdır.

Belge kaynaklarını izlemek ve doğrulamayı otomatikleştirmek

Her belgenin bir kaynağı vardır: kullanıcı yüklemesi, entegrasyon çekimi, e-posta ile gelen ek, saha uygulaması üretimi gibi. Kaynak bilgisi tutulduğunda sorun çıktığında “nereden geldi” sorusu anında yanıtlanır. Ayrıca referans numarası eşleşmesi, dönem kontrolü ve zorunlu alan doğrulaması gibi kontroller otomatikleştirildiğinde, insan kontrolü yalnızca istisnalara odaklanır.

Raporlama ile tıkanma noktalarını görünür kılmak

En çok geciken adım hangisi, en sık revizyona giden neden ne, hangi proje türünde evrak eksikliği artıyor gibi soruların yanıtı raporla görünür olmalıdır. Bu raporlar yalnızca yönetim panosu değil, iyileştirme döngüsünün yakıtıdır. İyileştirme, süreçteki tekrar eden kusuru yakalamak ve kalıcı kontrol kuralı üretmekle hızlanır.

Uygulama planı: hızlı kazanım üretmek ve kurumsallaştırmak

Bu yapıyı hayata geçirmek için büyük bir dönüşümü tek seferde yapmak yerine, iteratif ilerlemek daha sağlıklıdır. Önce evrak seti ve kontrol listesi standarda bağlanır, ardından akış durum modeli devreye alınır, son olarak audit log, raporlama ve entegrasyon derinleştirilir. Bu sırada her iterasyonda kullanıcı geri bildirimiyle kural seti olgunlaştırılır.

İlk 2 haftada uygulanabilir minimum akış çıkarmak

Minimum akış; Taslak → Evrak Toplama → Evrak Kontrol → İmza Bekliyor → Onaylandı adımlarıyla başlayabilir. Bu akışa yalnızca kritik zorunlu evrak kontrolü eklenir. Revizyon gerekçesi ve versiyonlama temel seviyede tutulur. Amaç, sahada “gerçek hayatta çalışan” bir yapı kurmak ve kullanım alışkanlığı oluşturmaktır.

Sonraki aşamada kontrol kuralları ve metriklerle olgunlaştırmak

Kullanım başladıktan sonra en sık hata veren alanlar tespit edilir. Örneğin metraj-icmal tutarsızlığı veya dönem uyuşmazlığı sık çıkıyorsa, otomatik kontrol kuralı yazılır. SLA metrikleri ve eskalasyon devreye alınır. Böylece süreç, sadece “işleyen” değil aynı zamanda “öğrenen” bir mekanizmaya dönüşür.

Bu yaklaşımı kurum içinde yaygınlaştırmak için eğitim ve örnek akış dokümantasyonu önemlidir. Hakediş ve kesin hesap konularında daha sistematik ilerlemek isterseniz, ilgili içeriklere Hakediş Kesin Hesap Eğitimi sayfasından devam edebilirsiniz.

• Kontrol listelerini proje türüne göre şablonlaştırmak
• Rol ve yetki matrisini versiyonlayarak yönetmek
• SLA ve eskalasyonu süreç tasarımına gömmek
• Revizyon nedenlerini sınıflandırıp ölçülebilir yapmak
• Audit log ile izlenebilirliği kalıcı hale getirmek

Sonuç olarak, hakediş dosyasında evrak kontrolü ve imza akışı kurgulamak; yalnızca bir ekran akışı çizmek değil, doğrulama, sorumluluk ve kanıt üçgenini sistematik şekilde kurmaktır. Bu üçgen kurulduğunda ödeme süreçleri hızlanır, hatalar azalır ve kurum içi güven artar.