30 saniyelik özet
Bir çözümün sunumda etkileyici görünmesi, müşterinin işinde değer üreteceğini göstermez. Kavram kanıtlama, İngilizce adıyla Proof of Concept veya PoC, belirli bir fikrin uygulanabilirliğini sınırlı kapsamda sınar. Pilot ise çözümü gerçek kullanıcılar ve süreçlerle kontrollü biçimde işletir. İlki kritik belirsizliğe odaklanır; ikincisi kullanım, operasyon ve iş sonuçları hakkında kanıt toplar. İyi bir çalışma, başlamadan önce hangi soruya cevap arandığını ve sonuçların hangi karara bağlanacağını tanımlar. Çıktı yalnızca çalışan bir sistem değil, ilerleme, değiştirme veya durdurma kararıdır.
Neden önemli?
İş geliştirme görüşmelerinde müşteri, sağlayıcının referanslarını ve ürün yeteneklerini öğrenebilir. Ancak kendi verisinin kullanılabilirliğini, ekibinin çözümü benimseyip benimsemeyeceğini ve mevcut sistemlerle uyumu henüz bilmiyor olabilir. Bu belirsizlikler çözülmeden kapsamlı bir anlaşmaya gitmek, tarafların farklı beklentilerle yola çıkmasına neden olur.
PoC ve pilot, bu belirsizlikleri daha sınırlı bir yatırım üzerinden değerlendirmeye yardımcı olur. Yine de küçük kapsam otomatik olarak düşük maliyet demek değildir. Veri hazırlama, entegrasyon, eğitim ve kullanıcı desteği ciddi emek gerektirebilir. Denemenin neyi öğreteceği belirsizse, şirketler tam uygulamanın maliyetini küçük parçalara bölerek ödemeye başlayabilir.
Yönetim açısından temel değer, kaynak tahsisinin kanıta dayanmasıdır. Başarılı görünen her deneme yaygınlaştırılmamalıdır. Bazı çözümler teknik olarak çalışır ama mevcut iş hacminde ekonomik anlam taşımaz. Bazıları değer üretir ancak uzmanların sürekli müdahalesine ihtiyaç duyar. Karar, bu koşulları görünür kılmalıdır.
İş analisti ölçülecek ihtiyacı ve mevcut durumun nasıl kaydedileceğini netleştirir. Ürün yöneticisi çözümün ürün yönüyle uyumunu değerlendirir. Product Owner, ürün üzerinde önceliklendirme sorumluluğu taşıyan rol olarak, denemeden öğrenilenleri yapılacak işlere dönüştürür. Proje yönetim ofisi ise kaynak, bağımlılık ve karar noktalarının takibini destekleyebilir.
Terim nedir?
Kavram kanıtlama, bir çözümün kritik varsayımını sınamak için tasarlanmış sınırlı çalışmadır. Örneğin mevcut belgelerden ihtiyaç duyulan bilginin çıkarılıp çıkarılamadığı araştırılabilir. Bunun için bütün kullanıcı arayüzlerini veya üretim ortamını tamamlamak gerekmez. Önemli olan, ele alınan soruyu güvenilir biçimde cevaplayacak kapsamı seçmektir.
Pilot, çözümün sınırlandırılmış bir operasyon içinde denenmesidir. Kullanıcılar gerçek işleri yürütür; hata, destek ihtiyacı, süreç uyumu ve kullanım davranışı gözlenir. Pilotun kapsamı dar olabilir fakat işleyişi temsil etmesi gerekir. Yalnızca en kolay işlemler seçilirse, sonuçlar günlük operasyon hakkında sınırlı bilgi verir.
Demo, ürünün yeteneklerini gösteren tanıtımdır. Prototip, bir fikri incelemek veya geri bildirim almak için hazırlanan erken örnektir. PoC ise kanıt aranan bir çalışmadır. Aynı prototip PoC içinde kullanılabilir; ancak ortaya bir ekran çıkması tek başına kritik varsayımın doğrulandığı anlamına gelmez.
Bu aşamalar her projede aynı sırayla uygulanmak zorunda değildir. Teknik uygulanabilirlik zaten biliniyorsa doğrudan pilot anlamlı olabilir. Belirsizlik yalnızca dar bir teknik konuda ise operasyonel pilot öncesinde küçük bir PoC yeterli olabilir. Yöntem, çözülecek belirsizliğe göre seçilmelidir.
Gerçek vaka: Eczacıbaşı Mission AI programı
Microsoft'un yayımladığı müşteri hikâyesinde, Eczacıbaşı Holding'in farklı şirketlerdeki yapay zekâ çalışmalarını ortak bir geliştirme yaklaşımıyla ele aldığı anlatılıyor. Mission AI programında teknik koçluk ve ortak araçlarla fikirlerden çalışan prototiplere sekiz haftada geçildiği belirtiliyor. Toplam 27 prototipin tamamlandığı, bunların 12'sinin grup genelinde uygulanabilecek yüksek etkili çözümler olarak öne çıkarıldığı aktarılıyor.
Kaynak, çözümlerin çoğunda tam uygulama için ek sistem entegrasyonlarının planlandığını da söylüyor. Bildirilen performans sonuçlarının pilot uygulamaları, erken üretim kullanımları ve doğrulanmış kullanım senaryolarından türetilen projeksiyonları birlikte içerdiği açıkça belirtiliyor.
Dolayısıyla prototiplerin tamamlanması, bütün çözümlerin grup çapında aynı değeri ürettiğinin kanıtı olarak okunamaz. Bu vaka için önemli ayrım, çalışan örnek oluşturmak, operasyon içinde sonuç gözlemek ve daha geniş uygulamaya karar vermek arasındadır. Yıllık fayda projeksiyonları da gerçekleşmiş sonuçlarla aynı kategoride değerlendirilmemelidir. Bu yorum, tedarikçi tarafından yayımlanan vaka metninin çizdiği sınırlar üzerinden yapılmaktadır.
Kaynak: Microsoft, Eczacıbaşı scales AI innovation across sectors with Microsoft Copilot Studio.
Varsayımsal örnek: Teklif belgelerinden karşılaştırma tablosu oluşturmak
Bir satın alma ekibi, farklı tedarikçilerden gelen teklifleri elle karşılaştırır. Yazılım sağlayıcısı belgelerden fiyat, teslimat koşulu ve hizmet kapsamını çıkaran bir çözüm önerir. Müşteri ise belgelerin biçimleri değiştiği için sistemin güvenilir çalışıp çalışmayacağından emin değildir.
İlk çalışma, belge çeşitliliği karşısında gerekli alanların doğru çıkarılıp çıkarılamadığını sınayan bir PoC olarak tasarlanır. Satın alma uzmanları geçmiş belgeler için doğrulanmış bir referans hazırlar. Kolay örneklerin yanında eksik alanlar, farklı para birimleri ve ek sayfalarda yer alan koşullar da değerlendirmeye alınır. Kritik hata türleri baştan belirlenir; sistemin boş bıraktığı bir alan ile yanlış bilgi ürettiği alan ayrı kaydedilir.
Sonuçlar yeterli bulunursa çalışma sınırlı bir satın alma sürecinde pilota geçer. Uzmanlar sistemin hazırladığı tabloyu kontrol ederek kullanır. Belge işleme süresinin yanında düzeltme süresi ve kontrol yükü de izlenir. Hız kazancı, hatalı bir teslimat koşulunun gözden kaçmasına yol açıyorsa başarı değerlendirmesi değişir.
Pilot sonunda ekip, hangi belge türlerinde güvenilir sonuç alındığını ve hangi işlemlerin uzman incelemesi gerektirdiğini raporlar. Yaygınlaştırma kararı, bütün belgeleri otomatik işlemek yerine uygun belge grubuyla başlamak olabilir. Sağlayıcı ile müşteri, kalan entegrasyon işlerini ve destek sorumluluklarını netleştirdikten sonra kapsamlı uygulamayı değerlendirir.
Yaygın üç hata
- Başarı ölçütlerini sonuçları gördükten sonra belirlemek
Çalışma sonunda yalnızca iyi çıkan göstergeleri seçmek, kararın güvenilirliğini azaltır. Başlamadan önce mevcut durum, ölçüm yöntemi, kabul koşulları ve kritik başarısızlık durumları yazılmalıdır. Ölçüt değişmesi gerekiyorsa gerekçe kaydedilmeli; ilk hedefin karşılandığı izlenimi verilmemelidir.
- Denemeyi özel destekle başarılı göstermek
Sağlayıcının uzmanları verileri sürekli düzeltip kullanıcıların bütün sorunlarını anında çözüyorsa pilot günlük işleyişi temsil etmeyebilir. Bu müdahaleler yasaklanmak zorunda değildir; ancak harcanan emek görünür olmalıdır. Yaygınlaştırma sırasında aynı desteğin sağlanıp sağlanamayacağı ve maliyeti ayrıca değerlendirilmelidir.
- Başarılı pilotu otomatik satın alma kararı saymak
Dar kapsamda elde edilen sonuç, bütün birimlerde aynı performansı garanti etmez. Veri hacmi, kullanıcı çeşitliliği ve sistem bağımlılıkları değişebilir. Pilot öncesinde ticari değerlendirme yolu tanımlanmalı; başarı sonrasında hangi ek koşulların karşılanacağı açıklanmalıdır. Öğrenilenler, uygulanabilir bir yaygınlaştırma planına dönüşmelidir.
Mini uygulama / şablon
Denemeye başlamadan önce aşağıdaki karar kaydını müşteri ve sağlayıcı birlikte doldursun:
- Çözülecek iş problemi
- —
- Sınanacak kritik varsayım
- —
- Çalışma türü ve seçilme gerekçesi
- —
- Kapsam içindeki kullanıcılar ve işlemler
- —
- Kapsam dışındaki konular
- —
- Veri kaynakları ve veri hazırlama sorumlusu
- —
- Mevcut durumun ölçümü
- —
- Başarı ölçütleri ve kabul koşulları
- —
- Kritik hata ve durdurma koşulları
- —
- Kullanıcı kontrolü ve destek düzeni
- —
- Takvim, ara değerlendirme ve kapanış tarihi
- —
- Tarafların sağlayacağı kaynaklar
- —
- Ölçümleri doğrulayacak kişi
- —
- Sonuçlara göre değerlendirilecek kararlar
- —
- Yaygınlaştırma için kalan işler
- —
- Ticari karar sahibi
- —
Kapanış raporunda gözlenen sonuçları, yorumları ve geleceğe ilişkin tahminleri ayrı yazın. Başarısız görünen bir deneme, önemli bir varsayımı düşük maliyetle çürüttüyse karar açısından değerli olabilir. Başarıyı yalnızca ürünün satın alınmasına bağlamak, öğrenmenin önemini gölgeler. Asıl ölçüt, elde edilen kanıtın bir sonraki kararı ne kadar sağlamlaştırdığıdır.
İlgili terimler
İş gerekçesi, Yatırım getirisi, Prototip, Minimum uygulanabilir ürün, Kabul kriterleri, Gereksinim doğrulama, Kullanıcı kabul testi, Deney tasarımı, Değişiklik yönetimi, Ürün yol haritası