Önce en kötü senaryo

Bir AI projesi stratejik olarak mantıklı, teknik olarak etkileyici ve kâğıt üzerinde kârlı olabilir — yine de ölebilir. Değer üretmediği için değil, kanıt oluşmadan nakit bittiği için. Faturalar planlanandan geç ödenir. Bulut, inceleme ve entegrasyon maliyetleri birlikte yükselir. Finansman görüşmesi kullanılabilir para sanılır. Ya da ekip, durmayı ancak gerçek seçeneklerin neredeyse tamamı kaybolduğunda konuşur.

Bu nedenle en kötü senaryo bir iş planının sonuna değil, operasyonel finans yönetiminin başına aittir.

En kötü senaryo planlaması kötümserlik değildir. Belirsizliği zamana, eşiklere ve önceden hazırlanmış kararlara çevirir.

İyi bir fikir yanlış zaman ekseninde başarısız olabilir

Genel proje ekonomisi bir teklifin temelde değer üretip üretemeyeceğini sorar: hedef kitle, problem, ödeme isteği, fiyat, değişken maliyet ve katkı marjı. Bunlar gereklidir. Fakat proje bu duruma giden yolu finanse edebilir mi sorusunu henüz cevaplamaz.

Bugün ile sürdürülebilir model arasında maaş, geliştirme, veri işi, hukuk incelemesi, satış ve işletme ayları vardır. Gelir çoğu zaman işten sonra gelir. Bu yazının konusu tam olarak bu zaman farkıdır.

Genel proje ekonomisinden ayrılan nokta

Bu metin pazar segmentasyonu, fiyatlandırma veya unit economics’i tekrar etmez. Bunları kabul eder ve farklı bir soru sorar:

Merkezî varsayımlar planlanandan geç, pahalı veya zayıf gerçekleşirse ne olur?

Cevap ikinci bir iyimser tahmin değildir. Nakit takvimi, senaryolar, öncü göstergeler, rezervler, finansman tarihleri ve önceden kararlaştırılmış aksiyonlardan oluşan bir hayatta kalma sistemidir.

Kâr likidite değildir

Bir şirket dönem içinde kârlı görünüp ödeme gücünü kaybedebilir. Gelir kaydedilmiş olabilir fakat para hesaba gelmemiştir. Yatırım hemen ödenirken faydası yıllara yayılır. Vergi, maaş ve tedarikçi ödemelerinin farklı vade tarihleri vardır.

Birleşik Krallık Insolvency Service, şirket etkin biçimde ticaret yapsa bile yeterli hazır nakit bulunmamasının önemli bir başarısızlık nedeni olabileceğini belirtir.^[2] Bu nedenle yönetim yalnızca bir sipariş para kazandırıyor mu diye değil, her yükümlülük vadesinde ödenebiliyor mu diye sormalıdır.

Bütçe cash flow değildir

Bütçe planlanan gelir ve giderleri kategorilere ayırır. Cash-flow planı gerçek para giriş ve çıkışlarını tarihlere yerleştirir. İki görünüm ciddi biçimde ayrışabilir.

Yıllık bütçe dengeli olsa da dördüncü ayda finansman açığı çıkabilir. 60.000 euroluk fatura, maaştan 60 gün sonra ödenirse bugünkü bordroyu finanse etmez. Sağlam downside planı en az aylık, kritik dönemde haftalık görünüm ister.

Nakit takvimi operasyonel gerçektir

Takvim gerçekten kullanılabilir ve kısıtsız nakitle başlar. Ödemeler, fatura yazıldığı tarihe değil gerçekçi tahsilat tarihine konur.

Dört para türü ayrılır:

En yaygın hata son satırdadır: umut fark edilmeden nakde dönüşür.

Burn rate: proje parayı ne hızla tüketiyor?

Brüt burn, dönemdeki tüm nakit giderlerdir. Net burn, aynı dönemin güvenilir tahsilatlarını çıkarır.

Net burn = nakit giderler − güvenilir nakit girişleri

Büyüyen projede hem gider hem giriş yüksek olabilir. Tehlike yalnız brüt burn değil; net çıkışın belirsiz tahsilat ve geri alınamaz taahhütlerle birleşmesidir.

Runway: rahatlatıcı sayı değil, karar süresi

Sabit pozitif net burn için ilk yaklaşım:

Runway = serbest kullanılabilir nakit ÷ dönemsel net burn

120.000 euro serbest nakit ve ayda 20.000 euro net burn altı ay verir. Bu bir örnektir, benchmark değildir. Değişken maliyet, geç ödeme, vergi veya kademeli altyapı harcaması gerçek süreyi kısaltabilir.

Statik runway formülü neden yanıltır?

Formül düz bir akış varsayar. Gerçek projelerde ramp-up, yıllık faturalar, milestone ödemeleri, minimum alımlar, fesih süreleri ve mevsimsel gelir vardır. Ortalama erken bir açığı gizleyebilir.

Daha iyi soru şudur: Serbest nakit hangi hafta veya ayda tanımlı güvenlik tabanının altına iner?

Dinamik runway ödeme dizileriyle çalışır

Her dönem ileri taşınır:

Dönem sonu nakdi(t) = dönem başı nakdi(t) + güvenli girişler(t) − vadesi gelen çıkışlar(t)

Dönem sonu bir sonraki dönemin başlangıcı olur. Beklenen fakat güvence altına alınmamış gelir ayrı senaryo satırında kalır. Ekip yalnız kaç ay kaldığını değil, hangi açığın ne zaman oluştuğunu görür.

Tablonun sıfırın üzerinde bir güvenlik tabanına da ihtiyacı vardır. Sıfır nakit iyi trigger değildir; o noktada maaş, iade, fesih veya düzenli kapanış zaten finanse edilemeyebilir. Taban gerçek kalan yükümlülüklere bağlıdır: ihbar süreleri, açık müşteri işi, veri migration’ı, vergi ve minimum işletme. Bu nedenle evrensel ay kuralı değil, gerekçeli proje değeridir.

Tamamen örnek amaçlı küçük tablo mantığı gösterir. Tutarlar öneri değildir:

Gerekçeli güvenlik tabanı 40.000 ise dördüncü ayda ihlal edilir. Hesapta hâlâ para olsa bile operasyonel trigger daha önce gelir.

Üç senaryo minimumdur, hedef değildir

Tek tahmin bir hikâyedir. Erken projeler en az üç tutarlı senaryo ister:

Worst case dünyanın sonu değildir. Kararı değiştirecek kadar makul olan en ağır durumdur.

Üç durum aynı kararı zorlamamalıdır. Temel senaryo hangi kanıtın sonraki büyüme basamağına izin verdiğini gösterir. Downside senaryosu harcama veya scope’un ne zaman değişeceğini gösterir. Ağır makul durum duraklatma, pivot veya kapanışın uygulanabilir ve finanse edilebilir kalıp kalmadığını sınar. Üçü de yalnız “devam et” diyorsa ekip aynı umudun üç sürümünü üretmiştir.

Senaryolar iç tutarlılığa sahip olmalıdır

Downside senaryosu geliri yüzde 30 azaltıp her şeyi sabit bırakamaz. Düşük talep daha uzun satış döngüsü, daha yüksek edinme maliyeti ve indirim anlamına gelebilir. Kalite sorunu destek, iade ve inceleme işini birlikte artırabilir.

Bu yüzden her senaryonun nedensel hikâyesi gerekir: önce ne değişti, sonra ne oldu, hangi tahsilat veya maliyet kaydı?

Bağlı şoklar tek sapmadan daha tehlikelidir

Birçok plan değişkenleri tek tek sınar. Krizler onları bağlar. Provider fiyat artırırken model daha çok token tüketir. Müşteri kabulü, kalite incelemesi uzadığı için gecikir. Beklenen tahsilat kaybolurken burn yükselir.

Stress test en az bir birleşik durum içermelidir. Amaç aynı rezervin tek bozulmanın birkaç sonucunu birden karşılayıp karşılamadığını görmektir.

AI projesinin yedi finansal stres ekseni

Bu eksenler keyfî yüzdelere dönüşmemelidir. Her birinin mekanizması ve kanıtı olmalıdır.

Pre-mortem: başarısızlık olmuş gibi düşünmek

Pre-mortem’de ekip projenin on iki ay sonra başarısız olduğunu kabul eder. Her kişi bağımsız cevap verir: Muhtemelen ne oldu?

Deborah Mitchell, Jay Russo ve Nancy Pennington’ın “prospective hindsight” araştırması, sonucu gerçekleşmiş kabul etmenin insanlar için olası neden üretmeyi geliştirebildiğini gösterdi.^[5] Projede konuşma “Olabilir mi?” sorusundan “Nasıl oldu?” sorusuna geçer.

Pre-mortem dramatik kelimelerle risk listesi değildir

Kullanışlı kayıt beş öğe taşır: gözlenebilir trigger, etkilenen varsayım, finansal aktarım, en erken sinyal ve hazırlanmış tepki.

“Pazar çöker” çok geniştir. “Nitelikli görüşmeler üç ay boyunca dördün altında kalır, ilk ücretli kohortu sekiz hafta kaydırır ve net burn’ü X artırır” yönetilebilir.

Reference Class Forecasting iç bakışı düzeltir

Ekipler çoğunlukla içeriden planlar: kendi projelerini parçalara ayırıp her adımı tahmin eder. Bilinmeyen zorlukları küçümser, kendi vakalarının özelliğini abartırlar.

Reference Class Forecasting dış bakışı ekler. Gerçekten benzer projeler bulunur, süre, maliyet ve sonuç dağılımları incelenir, proje bu dağılımda konumlandırılır. Bent Flyvbjerg bunu iyimserlik yanlılığını ve stratejik yanlış sunumu azaltan yöntem olarak açıklar.^[4]

Referans sınıfı gerçekten benzer olmalıdır

“Diğer AI start-up’ları” çoğunlukla çok geniştir. Benzer procurement yapısına sahip B2B pilotları, hassas veri projeleri, insan review’lu ürünler veya aynı sistem sınıfına entegrasyonlar daha iyidir.

Sınırları açıklanan küçük bir sınıf bile yalnız sezgiden iyidir. Kesinlik değil, buffer ve zaman için empirik taban verir.

Maliyet belirsizliği dipnota değil tahmine aittir

U.S. Government Accountability Office Cost Estimating and Assessment Guide, risk ve belirsizlik analizini güvenilir maliyet tahmininin parçası kabul eder.^[1] Tek nokta sayı olası sonuç aralığını gizler.

AI projesinde maliyet bloklarının driver, aralık ve bağımlılıkları olmalıdır. Rezerv hisle eklenmez; tanımlı belirsizlikten türetilir.

Her rezerv aynı değildir

En az üç havuz ayrı kalmalıdır:

Havuzlar karışınca plan rahat görünür, gerçek hareket alanı daralır.

Geri alınabilir ve geri alınamaz taahhütleri ayırın

Her euro aynı esnekliğe sahip değildir. Aylık tools, süreli freelancer paketi ve kademeli bulut kapasitesi; kira, minimum alım, kalıcı rol veya büyük ön ödemeden daha kolay değişir.

Downside planı her gider için şunu yazar: ne zamana kadar iptal, hangi süre, hangi çıkış maliyeti ve hangi yetenek kaybı?

Taahhüt takvimi son iyi karar noktasını gösterir

Her büyük taahhüdün hâlâ önlenebildiği veya küçültülebildiği bir tarih vardır. Bu tarih ödemeden çok önce olabilir.

Yıllık sözleşme haziranda başlıyor fakat nisan ayında feshedilmeliyse operasyonel karar noktası nisandır. Yalnız hesap bakiyesi izleyen proje bunu geç fark eder.

Finansman sözü nakit değildir

Yatırımcı görüşmesi, hibe başvurusu veya sözlü sipariş temel runway’i uzatmamalıdır. Yalnız güvenilir, hukuken geçerli ve zamanı gerçekçi taahhüt senaryoya kalan riskiyle girebilir.

Bu umut etmeyi engellemez. Umudu ödenmiş fatura gibi işlemeyi engeller.

Finansman tarihi sıfırdan önce gelir

Yeni finansman araştırma, belge, inceleme, pazarlık, karar ve ödeme ister.^[3] Esas tarih “Hesap ne zaman boş?” değildir:

Finansman başlangıcı = güvenlik eşiği − gerçekçi finansman lead time − karar rezervi

Altı aylık süreç için iki aylık runway’de başlamak finansman stratejisi değil, acil çağrıdır.