LCC yazılımı nasıl seçilir? Entegre maliyet analizi için 7 kriter

LCC yazılımı, bir ürünün veya yapının yaşam döngüsü boyunca oluşan maliyetleri modüllere yerleştirip iskonto ederek yaşam döngüsü maliyetlendirmesini (LCC) hesaplayan ve raporlayan araçtır. Doğru seçim, hesap tablosunun ötesinde üç şey sağlar: maliyetin çevresel LCA ile aynı yapıda tutulması, iskonto varsayımlarının şeffaf olması ve sonucun bir doğrulayıcı ya da ihale komisyonu önünde savunulabilmesi. Bu yazı, LCA ile entegre bir maliyet analizi kuracak ekipler için yedi değerlendirme kriterini ve her kriterin arkasındaki teknik gerekçeyi sıralar. Kriterler ISO 15686-5 ve EN 16627'nin gereksinimlerinden türetilmiştir; pazarlama özellik listelerinden değil.

Çoğu ekip LCC'ye bir hesap tablosuyla başlar ve bu, tek bir alternatifi bir kez değerlendirmek için yeterlidir. Sorun ölçekle gelir. Otuz maliyet kalemi, üç alternatif ve elli yıllık bir analiz dönemi, iskonto faktörlerinin yüzlerce hücreye elle yayıldığı, değişim yıllarının formülle değil gözle takip edildiği bir dosya üretir. Bir servis ömrünü değiştirmek değişim takvimini ve kalıntı değeri zincirleme etkiler; hesap tablosunda bu zincir kopar ve kimse fark etmez. Daha temel sorun izlenebilirliktir: bir doğrulayıcı hangi hücrenin hangi fiyat teklifinden geldiğini soramaz, çünkü tablo bunu kaydetmez. Aşağıdaki kriterler tam da bu kopma noktalarını hedefler.

1. Modül eşlemesi: maliyet ve çevre aynı paydada

İlk kriter, her maliyet kaleminin bir EN 15804 modülüne atanabilmesidir. EN 16627, EN 15804'ün modül yapısını (A1-A3, A4-A5, B1-B7, C1-C4, D) ekonomik değerlendirme için birebir devralır; bu yüzden yazılım maliyeti ‘yatırım’ ve ‘işletme’ gibi iki kaba kovaya değil, modül bazında tutmalıdır. Aynı yaşam döngüsü aşaması hem çevresel hem ekonomik eksende aynı satıra düşünce iki tablo yan yana okunur ve karbon azaltım maliyeti (€/t CO₂e) gibi türev göstergeler anlamlı hâle gelir. Modül eşlemesi olmayan bir araçta LCC ile LCA iki ayrı çalışma olarak kalır ve birleştirme işi elle, her seferinde yeniden yapılır. İkinci bir eksen olarak maliyet doğası (yatırım, işletme, yaşam sonu, gelir) ayrıca tutulmalı; yönetim bu kırılımı, standart ise modül kırılımını ister.

2. Reel/nominal ayrımı ve iskonto şeffaflığı

İkinci kriter, iskonto mantığının açıkça beyan edilmesidir: yazılım reel terimlerle mi, nominal terimlerle mi çalışıyor ve iskonto hangi zamanlama kuralıyla uygulanıyor? Reel yaklaşım nakit akışlarını enflasyondan arındırır ve reel iskonto oranı kullanır; nominal yaklaşım enflasyon tahmini ister. ISO 15686-5 her iki yolu da tanımlar ama karıştırılmalarını yasaklar. Yüksek enflasyon ortamında reel yaklaşım, modelden bir belirsizlik kaynağını çıkardığı için tercih edilir. Yazılımın bu kararı gizlemesi, sonucu yorumlayan kişinin varsayımı bilmeden rakam okuması demektir. Yıl sonu mu, yıl ortası mı iskonto uygulandığı da raporda görünmelidir; ikisi arasındaki fark uzun analiz dönemlerinde yüzde birkaç düzeyine çıkar ve iki alternatifin sıralamasını değiştirebilir.

3. Envanterden maliyet kalemi türetme

Üçüncü kriter, maliyet kalemlerinin LCA envanterinden türetilebilmesidir. Bir ürünün çevresel modeli zaten her malzeme, enerji ve taşıma akışını miktarıyla içerir; LCC için eksik olan tek şey birim fiyattır. Yazılım envanter satırlarını maliyet kalemine dönüştürebiliyorsa miktarlar tek kaynaktan gelir ve iki model birbirinden sapmaz. Dönüştüremiyorsa aynı miktarlar iki kez girilir ve altı ay sonra hangisinin güncel olduğu belirsizleşir. İyi bir türetme mekanizması sessizce eşitlemez: fiyatı eksik kalemi ve miktarı değişmiş satırı uyarı olarak gösterir, elle düzenlenmiş değeri ezmez ve fazlar arası ürün devirlerini (bir aşamanın çıktısının sonraki aşamaya girdi olması) satın alma sanıp iki kez saymaz.

4. Para birimi ve fiyat tarihi

Dördüncü kriter, fiyatların para birimi ve tarihiyle birlikte saklanmasıdır. Bir çatı kaplamanın fiyatı 2024 tarihli bir teklifte euro cinsinden, montaj işçiliği 2026 tarihli bir sözleşmede lira cinsinden gelebilir. Reel terimli bir motor için bu iki değerin aynı baz yıla ve aynı para birimine getirilmesi gerekir; bu dönüşüm ya açıkça yapılır ya da hiç yapılmamalıdır. Yazılımın para birimi uyuşmazlığını uyarı olarak göstermesi, gizli bir kur varsayımıyla toplam üretmesinden daha güvenlidir. Kur bilgisinin referans amaçlı görüntülenmesi ile motora otomatik dahil edilmesi farklı şeylerdir; ikincisi, kur tahminini belgelenmemiş bir varsayım olarak modele sokar ve doğrulamada ilk sorulan soru olur.

5. Değişim takvimi ve kalıntı değer otomasyonu

Beşinci kriter, değişim sayısının ve kalıntı değerin servis ömründen otomatik türetilmesidir. Analiz dönemi T, bileşenin servis ömrü SL'den uzunsa değişim sayısı N = ceil(T/SL) − 1 olur; 50 yıllık dönemde 20 yıllık bir bileşen için 20. ve 40. yıllarda iki değişim planlanır. Dönem sonunda kalan ömür, doğrusal amortismanla kalıntı değere çevrilip dönem sonu geliri olarak iskonto edilir. Bu iki mekanizma elle kurulduğunda en sık kırılan yerlerdir: servis ömrü güncellenir, değişim yılları güncellenmez. Yazılım bunu türetmiyorsa uzun ömürlü alternatifler sistematik olarak cezalandırılır, çünkü kalan ömürlerinin değeri hesaba hiç girmez.

6. Rapor ayrıştırması: EPD'ye sızmayan maliyet

Altıncı kriter, maliyet verisinin EPD dokümanından fiziksel olarak ayrı kalmasıdır. ISO 14025, Tip III çevresel beyanların yalnızca çevresel bilgi taşımasını şart koşar; fiyat veya maliyet içeren bir EPD doğrulamadan döner. Aynı projede hem LCA hem LCC tutan bir yazılımın, EPD çıktısına tek satır maliyet sızdırmadığını göstermesi gerekir. En temiz mimari, LCC'nin aynı modelden beslenen ama ayrı üretilen bir rapor olmasıdır: aynı beyan birimi, aynı modül kırılımı, ayrı doküman. Bu ayrım yalnızca bir uyum kuralı değil, ticari bir korumadır; fiyat pazarlık konusudur ve beş yıl geçerli bir belgede donmamalıdır.

7. Denetim izi ve doğrulanabilirlik

Yedinci kriter, sonuçtan girdiye giden yolun izlenebilmesidir. Her maliyet kaleminin kaynağı (teklif, sözleşme, fatura, tahmin), fiyat tarihi, birimi ve modül ataması kayıt altında olmalı; hesabın hangi iskonto oranı ve hangi analiz dönemiyle koşulduğu raporda görünmelidir. Envanter değiştiğinde sonucun ‘güncel değil’ olarak işaretlenmesi, eski bir sonucun yeni bir teklifle yan yana sunulmasını önler. Kamu ihalelerinde ve yeşil finansman başvurularında LCC giderek daha sık isteniyor; bu belgeleri okuyan tarafın ilk sorusu toplam değil, toplamın nereden geldiğidir. Bu soruya kalem kalem cevap veremeyen bir araç, ne kadar hızlı hesaplarsa hesaplasın, sonucu savunulabilir kılmaz.

• Her maliyet kalemi bir EN 15804 modülüne ve bir maliyet doğasına (yatırım, işletme, yaşam sonu, gelir) atanabiliyor mu?
• Reel/nominal tercihi ve iskonto zamanlaması raporda açıkça yazıyor mu?
• LCA envanteri maliyet kalemine dönüştürülebiliyor; eksik fiyat ve miktar sapması uyarı veriyor mu?
• Para birimi ve fiyat tarihi kalem bazında saklanıyor, uyuşmazlık uyarısı var mı?
• Değişim sayısı ve kalıntı değer servis ömründen otomatik türetiliyor mu?
• LCC raporu EPD PDF'inden ayrı üretiliyor mu?
• Her sonuç, girdilerinin sürümüne geri izlenebiliyor mu?