Bir danışmanlık ya da ajans projesinde ekip aylarca çalışır, teslimatlar zamanında yapılır, müşteri memnun ayrılır — ama proje kapandığında ortaya çıkan tablo farklıdır: harcanan saat, teklif aşamasında öngörülenin çok üstündedir ve proje aslında zarar etmiştir. Bu fark genellikle kimsenin hatası değildir; danışman zamanını doğru işe ayırmıştır, proje yöneticisi teslimatı zamanında çıkarmıştır. Sorun, harcanan zamanın proje anında değil, ay sonunda muhasebe kayıtlarına bakılınca görülmesidir.
Ürün satan bir işletmede stok, depoda sayılabilen bir şeydir. Danışmanlık, ajans, yazılım geliştirme veya mühendislik hizmeti veren bir işletmede stok, personelin zamanıdır — ve zaman, günün sonunda kaydedilmezse geri kazanılamaz. Bu yazı, proje bazlı kârlılığın ERP'de proje bitmeden nasıl görünür hale getirildiğini anlatıyor.
Danışmanlık ve ajans işlerinde "stok" neden insan zamanıdır?
Ürün işinde maliyet, alım faturası kesildiği anda bellidir: birim fiyat, miktar, toplam — hepsi net. Hizmet işinde maliyetin büyük kısmı personel maliyetidir ve bu maliyet, kişinin hangi projeye ne kadar zaman ayırdığına göre değişir. Aynı danışman bir hafta içinde üç farklı müşteri projesine zaman ayırabilir; bu dağılım kayıt altına alınmazsa, hiçbir proje için "bu işe gerçekte ne kadar maliyet gitti" sorusuna doğru cevap verilemez.
Bu nedenle hizmet işletmelerinde proje muhasebesinin çıkış noktası zaman kaydıdır. Zaman kaydı yoksa proje maliyeti yalnızca tahminle, genellikle de proje bittikten çok sonra, geriye dönük olarak hesaplanır — ki o noktada yapılacak tek şey hasar tespitidir, düzeltme değil.
Zaman çizelgesi tutulmazsa proje kârlılığı neden görünmez?
Çoğu hizmet firmasında zaman takibi ya hiç yapılmaz ya da personelin hafta sonunda hatırladığı kadarıyla doldurduğu bir Excel formudur. İki sorun birlikte ortaya çıkar:
- Gecikme: Zaman kaydı proje bitince ya da ay sonunda toplanıyorsa, bir projenin bütçeyi aştığı ancak geriye dönük fark edilir — proje yöneticisinin araya girip kapsamı ya da ekibi düzeltme şansı kalmamıştır.
- Doğruluk: Hafta sonunda hatırlanarak doldurulan bir zaman çizelgesi, gerçek dağılımı değil, kabaca bir tahmini yansıtır; hangi görevin ne kadar sürdüğü değil, hangi projeye "galiba çoğunlukla" çalışıldığı kaydedilir.
ERP'de zaman çizelgesi günlük, proje ve görev bazında tutulur; her kayıt doğrudan ilgili projenin maliyet tablosuna işlenir. Bir proje devam ederken harcanan saat sayısı ile öngörülen bütçe saati her an karşılaştırılabilir hale gelir — sapma, proje kapanmadan, hatta ideal olarak sapma küçükken fark edilir.
Retainer, proje bazlı ve saatlik paket fiyatlama aynı sistemde nasıl yönetilir?
Hizmet firmalarının çoğu tek bir fiyatlama modeliyle çalışmaz. Aynı firma bir müşteriyle aylık sabit ücretli (retainer) çalışırken, başka bir müşteriyle sabit bütçeli proje bazlı, üçüncü bir müşteriyle de saatlik faturalama üzerinden ilerleyebilir. Bu üç model ayrı ayrı, elle takip edildiğinde fatura kesim süreci her müşteri için farklı bir hesaplama gerektirir ve hata riski artar.
| Model | Fatura mantığı | Riski |
|---|---|---|
| Retainer (aylık sabit) | Sabit tutar, aylık dönemde otomatik | Harcanan saat sabit ücreti aşarsa fark edilmeyebilir |
| Proje bazlı (sabit bütçe) | Teslimat/aşama bazlı, sözleşmede tanımlı | Kapsam genişlerse (scope creep) bütçe sessizce aşılır |
| Saatlik | Onaylı zaman kaydı × birim ücret | Onaysız ya da geç girilen saat faturaya yansımaz |
ERP'de her müşteri/proje için fiyatlama modeli baştan tanımlanır ve zaman çizelgesi bu modele göre otomatik işlenir: retainer'da harcanan saat sabit ücretle karşılaştırılıp aşım uyarısı üretir, saatlik modelde onaylı saatler doğrudan faturaya dönüşür, proje bazlı modelde ise gerçekleşen maliyet sözleşme bütçesiyle sürekli karşılaştırılır. Üç model de aynı zaman verisini farklı kurala göre yorumladığı için, tek bir sistemde bir arada yönetilebilir.
Teklif-sözleşme-fatura döngüsü neden yavaşlar, nasıl hızlanır?
Hizmet satışında döngü ürün satışından daha uzundur: teklif hazırlanır, görüşülür, sözleşme imzalanır, iş başlar, ilerleme faturalandırılır. Bu adımlar ayrı belgelerde, ayrı kişiler tarafından hazırlandığında iki gecikme noktası oluşur: teklif onaylandıktan sonra sözleşme metninin hazırlanması için beklenen süre, ve iş bittikten sonra faturanın kesilmesi için beklenen süre. İkisi de nakit akışını geciktirir.
ERP'de teklif onaylandığında sözleşme, teklifteki kalemler ve fiyatlama üzerinden otomatik türetilir; sözleşme imzalandığında proje otomatik açılır ve fiyatlama modeli (retainer/proje/saatlik) projeye bağlanır. İş ilerledikçe hakediş ya da saatlik dönem kapandığında fatura, elle yeniden veri girmeden, sözleşmedeki koşullara göre üretilir. Bu, teklifin fatura haline gelme süresini kısaltmanın ötesinde, üç ayrı belge arasında tutarsızlık (teklifte olmayan bir kalemin faturada çıkması gibi) riskini de ortadan kaldırır.
Kapsam değişikliği de bu döngünün bir parçasıdır. Ajans ve danışmanlık projelerinde müşteri talebi proje ilerledikçe genişler — ek bir revizyon, ek bir teslimat, orijinal sözleşmede olmayan bir iş kalemi. Bu değişiklikler sözlü onayla, belgeye dökülmeden ilerlerse hem ek iş faturalandırılamaz hem de proje bütçesi sessizce aşılır. Kapsam değişikliğinin ek sözleşme maddesi ya da ek teklif olarak sisteme girilmesi, hem müşteriyle yazılı mutabakatı hem de ek işin faturaya doğru yansımasını garanti eder.
Doküman ve sözleşme sürümleri nereye oturmalı?
Danışmanlık ve ajans projelerinde sözleşme, teklif revizyonu, teslimat raporu gibi belgeler proje boyunca birkaç kez güncellenir. Bu belgeler e-posta eklerinde veya kişisel bilgisayarlarda dağınık tutulduğunda, "hangisi son sürüm" sorusu proje ilerledikçe sıkça tekrar sorulur — özellikle müşteri tarafında da revizyon isteyen birden fazla kişi varsa.
Doküman yönetimi projeye bağlı tek bir kayıt merkezinde tutulduğunda her belgenin sürüm geçmişi, kim tarafından ne zaman değiştirildiği ve hangi sürümün imzalandığı görünür kalır. Sözleşme e-imza ile tamamlandığında, imzalı nihai sürüm otomatik olarak proje dosyasına bağlanır; bu, hem hukuki referans hem de fatura itirazlarında ("bu kalem sözleşmede var mıydı") hızlı doğrulama sağlar.
Proje kârlılığı proje bitmeden nasıl görülür?
Zaman kaydı, fiyatlama modeli ve fatura akışı aynı proje koduna bağlandığında, proje kârlılığı (fatura edilen ya da edilecek tutar – harcanan personel maliyeti – varsa alt yüklenici/dış hizmet maliyeti) ay sonu beklenmeden herhangi bir anda okunabilir. Bir proje bütçesinin belirli bir oranını (örneğin harcanan saatin öngörülen saate oranını) aştığında proje yöneticisine otomatik uyarı düşmesi, kapsamın genişlediğini ("scope creep") sözlü bir şikâyet haline gelmeden, veri üzerinden fark ettirir. Bu erken uyarı, ek iş için müşteriden yeni onay istemeyi ya da kalan kapsamı yeniden planlamayı proje bitmeden mümkün kılar.
Birasyo'da bu akış nasıl kurulur?
Birasyo'nun proje modülü, her müşteri işini ayrı bir proje kodu olarak tanımlar; personelin günlük zaman çizelgesi bu koda işlenir ve fiyatlama modeline (retainer, proje bazlı, saatlik) göre otomatik yorumlanır. Teklif onaylandığında sözleşme ve proje kaydı türetilir, hakediş ya da dönem kapandığında fatura sözleşme koşullarına göre üretilir — kalemler yeniden elle girilmez. Proje bütçesi ile fiili maliyet (personel zamanı + dış hizmet) sürekli karşılaştırılır ve sapma eşiği aşıldığında proje sorumlusuna görünür hale gelir. Sözleşme ve teklif belgeleri doküman yönetimi üzerinden sürüm geçmişiyle tek merkezde tutulur.
Danışmanlık, ajans ve yazılım firmalarına özgü bu akışın satış, muhasebe ve İK modülleriyle birlikte nasıl bütünleştiği profesyonel hizmet çözümü sayfasında anlatılıyor.
Özet
- Hizmet işletmelerinde stok insan zamanıdır; zaman kaydedilmezse proje maliyeti ancak proje bittikten sonra, tahminle hesaplanabilir.
- Zaman çizelgesinin günlük ve görev bazında tutulması, bütçe sapmasını proje devam ederken görünür kılar.
- Retainer, proje bazlı ve saatlik fiyatlama modelleri aynı zaman verisini farklı kurala göre yorumlayarak tek sistemde yönetilebilir.
- Teklif-sözleşme-fatura akışının aynı veriden türemesi, hem nakit akışını hızlandırır hem de belgeler arası tutarsızlığı önler.
- Sözleşme ve teklif belgelerinin sürüm geçmişiyle proje dosyasına bağlanması, "hangisi son sürüm" sorusunu ortadan kaldırır.
- Proje bütçesi ile fiili maliyetin sürekli karşılaştırılması, kapsam genişlemesini (scope creep) proje bitmeden fark ettirir.
İlgili yazılar:
Bu yazıyı LinkedIn'de paylaşın
Başlık, özet ve hashtagler panoya kopyalanır, LinkedIn paylaş penceresi açılır — yapıştırın (Cmd/Ctrl+V) ve gönderin.
