30 saniyelik özet

Feasibility study, yani fizibilite çalışması, bir çözümün belirli koşullarda uygulanabilir olup olmadığını inceler. Teknik kapasitenin yanında maliyet, operasyon, zaman, kaynak ve geçerli yükümlülükler değerlendirilir. Amaç, sevilen fikri onaylatmak değil; seçenekleri, engelleri ve belirsizlikleri karar verilebilir hale getirmektir. İyi bir fizibilite sonucu her zaman “başlayalım” olmaz. “Önce şu varsayımı sınayalım”, “kapsamı daraltalım” veya “bu seçeneği durduralım” da değerli sonuçlardır. İş analisti, mevcut kanıtın hangi kararı desteklediğini ve hangi soruların açık kaldığını ayırmalıdır.

Neden önemli?

Bir yönetici, proje kârlılığını anlık gösteren bir ürün istediğinde ekip hızla ekranları ve entegrasyonları konuşmaya başlayabilir. Ancak gelir bilgisi güncel, personel maliyeti gecikmeli ve giderler ay sonunda kesinleşiyorsa ürünün temel vaadi henüz uygulanabilir değildir. Ekranın çalışması, gösterdiği kârlılığın karar vermek için güvenilir olması anlamına gelmez.

Bu fark erken görülmezse geliştirme ilerledikçe yatırımı savunmak zorlaşır. Ürün tamamlanabilir ama kullanıcıların ihtiyacını karşılamayabilir. Üstelik sorunun çözümü yeni teknoloji değil, veri toplama sürecinin değiştirilmesi olabilir. Fizibilite, çözümün bağlı olduğu koşulları görünür kılar.

C-level, yani üst düzey yönetim bakışında konu kaynak tahsisidir. Bir projeye ayrılan para, uzmanlık ve zaman başka bir ihtiyaca ayrılamaz. Bu nedenle yalnızca seçilen çözümün yapılabilirliğine bakmak yetersizdir. Alternatifler aynı problem ve başarı ölçütü üzerinden karşılaştırılmalıdır. Bugünkü düzeni sürdürmenin sonuçları da açıkça değerlendirilmelidir; mevcut durum maliyetsiz kabul edilmemelidir.

Terim nedir?

Fizibilite, sınırları belirlenmiş bir seçeneğin uygulanma koşullarını araştırır. “Bir platform geliştirebilir miyiz?” sorusu fazla geniştir. “Mevcut veri kaynaklarıyla, belirlenen kullanıcı grubuna güvenilir proje maliyeti bilgisi sunabilir miyiz?” sorusu daha değerlendirilebilir bir çerçeve oluşturur.

Teknik boyut; veri kalitesi, entegrasyon, performans ve ekip yetkinliği gibi unsurları kapsar. Operasyonel boyut, çözümün günlük süreçte nasıl kullanılacağını ve bakım sorumluluğunu ele alır. Ekonomik boyut, kurulumun yanında işletme, destek, geçiş ve çıkış maliyetlerini inceler. Zaman boyutu ise takvimdeki bağımlılıkları ve kaynakların gerçekten kullanılabilir olup olmadığını değerlendirir. Geçerli hukuki veya sözleşmesel gereklilikler de ilgili uzmanlarla incelenir.

Business case, yani iş gerekçesi, yatırımın neden yapılmaya değer olduğunu savunur. Fizibilite ile yakından ilişkilidir; fakat ikisi aynı soruyu cevaplamaz. Bir çözüm uygulanabilir olabilir, ancak maliyeti ve beklenen değeri yatırım önceliğini desteklemeyebilir. Buna karşılık değerli bir fikir, mevcut koşullarda uygulanamayabilir. Fizibilite bulguları iş gerekçesini besler; yatırım onayının yerine geçmez.

Varsayım, henüz yeterli kanıtla doğrulanmamış kabuldür. Risk ise hedefi etkileyebilecek belirsiz bir durumdur. “Kullanıcılar veriyi düzenli girecek” bir varsayımdır; girişlerin gecikmesi nedeniyle raporun güvenilmez hale gelmesi bir risktir. İkisini ayırmak, neyin araştırılacağını ve neye karşı önlem alınacağını netleştirir.

Hassasiyet analizi, maliyet veya talep gibi önemli varsayımlar değiştiğinde sonucun nasıl değiştiğini inceler. Ancak dayanağı olmayan rakamlara farklı değerler vermek kanıt üretmez. Tahminlerin kaynağı ve belirsizlik düzeyi önce açıklanmalıdır.

Gerçek vaka: Aflowan’ın yeni ürün fikrini araştırması

Sheffield Hallam University’nin vaka anlatımına göre Aflowan, yaratıcı sektör için uzmanlık gerektiren araçlar üreten bir şirkettir. Yeni ürün fikrini ilerletmek için gerekli bazı uzmanlık bilgilerinden yoksun olduğu için üniversiteden fizibilite değerlendirmesi istemiştir. Ürünün ayrıntıları gizlilik ve olası patent niteliği nedeniyle açıklanmamıştır.

Ekip, benzer araçları ve üretimlerinde kullanılan teknolojileri araştırmış; mevcut araçların şirketin çözmek istediği problem karşısındaki performansını incelemiştir. Çalışma, mevcut seçeneklerin odaklanılan ihtiyacı yeterince karşılamadığını ve daha ileri araştırma yapılabilecek alanlar bulunduğunu belirlemiştir.

Üniversite, araştırma ve modelleme önerileriyle birlikte olası finansman kaynaklarını da işaret etmiştir. Şirket yöneticisinin değerlendirmesi, daha fazla çalışma gerektiğini ve prototip hazırlamaya başlamak için yeterli bilgi oluşmuş olabileceğini ifade etmektedir.

Bu anlatım, ticari başarının veya tamamlanmış üretimin kanıtı değildir. Analitik açıdan değeri, soyut fikri araştırılabilir sonraki adımlara dönüştürmesidir. Fizibilite, bilinmeyenleri tamamen ortadan kaldırmadan da bir sonraki taahhüdün kapsamını belirlemeye yardımcı olabilir.

Kaynak: Sheffield Hallam University, Feasibility Assessment for a New Product.

Varsayımsal örnek: Proje kârlılığı görünürlüğü

Bir danışmanlık şirketi, proje yöneticilerinin maliyet sapmalarını daha erken fark etmesini istiyor. Başlangıç talebi “anlık kârlılık ürünü” olsa da analist önce karar ihtiyacını araştırıyor: Yöneticiler hangi veriye dayanarak hangi müdahaleyi yapacak? Görüşmelerde temel ihtiyacın, dönem kapanışını beklemeden maliyet eğilimini değerlendirmek olduğu varsayılsın.

Çalışma, mevcut raporlama aracını yapılandırma, dış hizmet satın alma ve özel yazılım geliştirme seçeneklerini karşılaştırıyor. Mevcut süreci sürdürmek de referans seçenek olarak değerlendiriliyor. Her seçenek için aynı veri kapsamı ve kullanıcı görevi esas alınıyor; geniş kapsamlı özel ürün, dar kapsamlı hazır hizmetle doğrudan karşılaştırılmıyor.

Teknik incelemede zaman kayıtlarının gecikmesi ve giderlerin sonradan kesinleşmesi ortaya çıkıyor. Bu koşulda “anlık kesin kâr” vaadi desteklenemiyor. Bunun yerine geçici maliyet görünümü sunmak değerlendiriliyor. Ekranda kesinleşmiş ve tahmini verinin ayrılması, hem gereksinim hem de güvenilirlik koşulu haline geliyor.

Ekonomik inceleme, lisans veya geliştirme bedeliyle sınırlı tutulmuyor. Veri temizleme, finans ekibinin kontrol işi, eğitim ve bakım da hesaba katılıyor. Operasyonel inceleme, güncellemeleri kimin takip edeceğini ve hatalı kayıtta düzeltme sorumluluğunu belirliyor.

Sonraki adım olarak sınırlı bir pilot, yani küçük kapsamlı gerçek kullanım denemesi öneriliyor. Pilot başlamadan önce kabul edilebilir veri gecikmesi ve uzlaştırma farkları ilgili yöneticilerle belirleniyor. Bunların sayısal eşikleri veri incelenmeden uydurulmuyor. Pilot, bütün şirket için başarı kanıtı sayılmıyor; daha büyük yatırım öncesinde belirli varsayımları sınamak için kullanılıyor.

Yaygın üç hata

  1. Seçilmiş fikre onay aramak

Yalnızca tercih edilen çözümü incelemek, alternatiflerin değerini gizler. Problem ve başarı ölçütünü çözümden önce tanımlayın. Satın alma, geliştirme, süreç iyileştirme ve mevcut düzeni sürdürme seçeneklerini uygun kapsamlarla karşılaştırın.

  1. Belirsiz tahminleri kesin sonuç gibi sunmak

Geliştirme maliyeti tahmini veya kullanıcı ilgisi, ölçülmüş sonuç değildir. Her önemli iddianın kaynağını ve kanıt düzeyini belirtin. Sonuç hangi varsayıma çok duyarlıysa bir sonraki araştırmayı o alana yöneltin.

  1. Teknik yapılabilirliği genel uygulanabilirlik saymak

Bir entegrasyon çalışabilir, fakat veri sahibi güncelleme sürecini sürdüremeyebilir. Çözümün günlük işletimini, sorumluları ve takvim bağımlılıklarını değerlendirin. “Yazılımı yapabiliriz” yanıtını “çözümü sürdürebiliriz” yanıtından ayrı ele alın.

Mini uygulama / şablon

Bir yatırım fikri seçin. Önce çözülecek problemi yazın; ardından her seçenek için aynı değerlendirme alanlarını doldurun.

Problem ve etkilenen kullanıcı
—
Desteklenecek karar veya iş sonucu
—
Kapsam ve kapsam dışı alanlar
—
Karşılaştırılan seçenekler
—
Teknik gereklilikler ve bağımlılıklar
—
Operasyonel değişiklikler ve sorumlular
—
Kurulum, işletme, geçiş ve çıkış maliyetleri
—
Takvim ve kaynak koşulları
—
Uzman değerlendirmesi gerektiren yükümlülükler
—
Kritik varsayımlar ve mevcut kanıt
—
Sonucu etkileyen başlıca riskler
—
Eksik kanıtı elde etme yöntemi
—
İlerleme, daraltma veya durdurma koşulları
—
Önerilen sonraki adım ve karar sahibi
—

Sonuç bölümünde kanıtın desteklediği kararı açık yazın. Tam yatırım için yeterli bilgi yoksa hangi araştırmanın veya denemenin gerektiğini belirtin. Bir sonraki adımın da maliyeti, sorumlusu ve beklenen çıktısı tanımlı olmalıdır. Böylece “biraz daha araştıralım” ifadesi, ucu açık bir bekleme yerine somut bir çalışma kararına dönüşür.

İlgili terimler

Business Case, Business Objective, Problem Statement, Gap Analysis, Scope ve Out of Scope, Prototype ve MVP, KPI ve Metrics, Requirements Elicitation, Change Request ve Impact Analysis