Excel'in bittiği yer
Bir taahhüt firmasında ay sonu şöyle geçer: şeflerden gelen puantaj kâğıtları, WhatsApp'tan düşen fazla mesai notları, ayrı bir dosyada tutulan yol ücretleri, muhasebenin kendi tablosunda tuttuğu yevmiyeler. Hepsi tek bir dosyada birleştirilir, formüller kopyalanır, bir hücre kayar ve kimse fark etmez.
Sorun Excel'in yetersizliği değil. Sorun şu: puantaj aslında bir tablo değil, bir kural motoru. Ve kurallar tabloya sığmıyor.
Puantaj bir tablo değil, bir kural motorudur
Aynı 10 saatlik mesai, hafta içi ile pazar günü aynı şey değildir. Kadrolu personel ile taşeron personel aynı hakka sahip değildir. Resmi tatilin yarım günü ile tam günü farklı hesaplanır. Bir personelin ay içinde maaşı değiştiyse, ayın tamamı yeni maaş üzerinden hesaplanamaz.
Doğru kurgulanmış bir sistemde bunların hepsi firma bazında tanımlanan kurallardır:
- Mesai katsayıları: hafta içi, cumartesi, pazar, dini bayram ve milli bayram için ayrı ayrı çarpanlar (tipik olarak 1.0 / 1.5 / 2.0).
- Çalışma şekli ayrımı: kadrolu ve taşeron personelin mesai hakkı ayrı kurallara bağlanır.
- Ek yevmiye: hangi gün tiplerinde devreye gireceği tanımlanır ve uygun günlerde otomatik işaretlenir.
- Yol ücreti: puantajdan bağımsız bir kalem olarak günlük bazda takip edilir.
- Resmi tatil takvimi: tam gün / yarım gün ayrımıyla birlikte tutulur.
- Çalışma geçmişi: maaş, günlük ücret ve ek yevmiye değişiklikleri tarih aralığıyla saklanır; geçmiş dönemler geriye dönük bozulmaz.
Kurallar bir kez tanımlandığında, ay sonu tek bir işleme dönüşür: dönemi seçersiniz, sistem tüm aktif personel için hakedişi hesaplar ve hangi personelin hesaplandığını, hangisinin atlandığını, hangisinde sorun olduğunu satır satır raporlar. Yeniden hesaplama gerektiğinde mevcut kayıtların üzerine kontrollü şekilde yazılır.
Kazanç sadece hız değil. Kazanç, aynı girdiyle her zaman aynı sonucun çıkması.
Maliyeti proje bittikten sonra öğrenmemek
Puantaj tek başına bir insan kaynakları verisi değil, aynı zamanda bir proje maliyeti verisidir. Saha maliyeti tek bir kalemden oluşmaz:
- Projeye atanmış personel ve onların puantajı
- Sahaya çıkan ürün ve malzeme
- İş makineleri
- İaşe ve konaklama
- Lojistik ve sevkiyat
Bu kalemler ayrı ayrı yerlerde tutulduğunda, projenin gerçek maliyeti ancak proje bittikten sonra ortaya çıkar — yani müdahale etme şansının kalmadığı anda. Aynı kalemler proje kartının altında toplandığında ise maliyet, proje devam ederken görünür hale gelir. Finansman giderleri, gelir planı ve sözleşme tutarı da aynı yerde durduğunda, "bu proje para kazandırıyor mu" sorusunun cevabı bir tahmin olmaktan çıkar.
Stok değil, kaynak yönetimi
Şantiye ekipmanı klasik anlamda "stok" değildir. Bir iskele sistemi satılmaz; bir projede kullanılır, biter, döner ve başka bir projeye gider. Bu yüzden kritik soru "elimde kaç adet var" değil, "15 Mart ile 20 Nisan arasında kaç adedi müsait" sorusudur.
Doğru model, ortak bir havuz üzerinde tarih bazlı blokaj kurmaktır: planlama aşamasındaki rezervasyon da, sahada aktif kullanım da müsait miktardan düşer. Tarih çakışması olduğunda sistem yetersiz stokta işlemi engeller; çakışma yoksa kullanımı serbest bırakır. Böylece iki proje aynı ekipmanı aynı tarihte planlayamaz — hata sahaya gitmeden önce yakalanır.
Talepten teklife, tekliften projeye
Saha operasyonu, işin alındığı yerden kopuk düşünülemez. Müşteriden gelen talep, hazırlanan teklif ve revizyonları, teklifin dönüştüğü proje ve o projeye bağlanan görevler tek bir zincir üzerinde durduğunda, "bu projeye neden bu fiyatı verdik" sorusunun cevabı altı ay sonra da elinizin altındadır. Teklif kalemlerinin (personel, ürün, iş makinesi, iaşe, lojistik) proje kalemleriyle aynı yapıda olması, teklif ile gerçekleşen arasındaki farkı doğrudan karşılaştırılabilir kılar.
Rapor, ekranın kendisi kadar önemlidir
Bir sistemin değeri, veriyi ne kadar kolay geri verdiğiyle ölçülür. Proje, personel, stok ve CRM için hazır rapor modülleri; kullanıcının kurduğu filtre ve kolon setinin kayıtlı rapor olarak saklanabilmesi; sonuçların Excel'e aktarılabilmesi — bunlar "ekstra özellik" değil, sistemin günlük kullanılabilirliğinin şartıdır. Her ay aynı raporu sıfırdan kurmak zorunda kalan kullanıcı, bir süre sonra o raporu yine Excel'de kurar.
Çok kiracılı mimaride asıl mesele: veri izolasyonu
Platform birden fazla firmaya hizmet ediyorsa, en büyük risk hatalı bir sorgunun başka bir firmanın verisine dokunmasıdır. Bunu her ekranda geliştiricinin dikkatine bırakmak sürdürülebilir değildir; firma süzgecinin tek bir merkezden ve zorunlu olarak uygulanması gerekir. Silme ve güncelleme işlemleri beyaz listeden geçen tablo adlarıyla çalıştığında, alt kayıtların sahipliği üst kayıttan doğrulandığında ve oturumda firma bağlamı yoksa işlem hiç başlamadığında, izolasyon bir alışkanlık olmaktan çıkıp bir garanti haline gelir.
Bunun üstüne binen katmanlar da aynı mantıkla merkezîdir: rol bazlı yetkilendirme (görüntüleme, ekleme, güncelleme, silme kırılımında), menünün kullanıcının yetkisine göre dinamik üretilmesi, iki adımlı doğrulama, modern algoritmayla saklanan parolalar, başarısız giriş denemelerinde hesap kilidi, sistem ve güvenlik logları, bakım modu ve lisans kontrolü.
Sonuç
Şantiye yönetiminde asıl kayıp, yapılan işte değil; işin kaydedilme biçimindedir. Aynı veri üç ayrı yerde tutulduğunda, üçü de bir süre sonra yanlış olur.
Puantajın kurallara bağlandığı, maliyetin proje devam ederken göründüğü, ekipmanın tarih bazlı planlandığı ve tüm bunların tek bir veri modeli üzerinde durduğu bir yapı; ay sonunu bir "kapanış telaşı" olmaktan çıkarıp rutin bir işleme dönüştürür. Kazanılan zaman önemlidir — ama asıl kazanç, kararları doğru sayılarla verebilmektir.