Kavram kanıtlama çalışması (PoC), bir fikrin uygun koşullarda çalışabildiğini gösterir. Canlı bir sistemin ise her gün, gerçek kullanıcılar için, gerçek veriyle ve kendisi düşünülmeden kurulmuş sistemlerin yanında çalışması gerekir. Pek çok kurum bu farkı, başarılı bir demonun ardından aylarca süren sessizlikle yaşayarak öğrenir. Bu yazıda PoC projelerinin neden yarıda kaldığı ve bir projenin, demonun canlıya ulaşma ihtimalini gerçekçi kılacak şekilde nasıl aşamalandırılabileceği anlatılmaktadır.

PoC projeleri neden yarıda kalır

Yarıda kalan PoC projelerinin çoğu birkaç ortak nedene dayanır. Bu nedenlerin hiçbiri dar anlamda teknik değildir ve hepsi projenin ilk haftalarında tespit edilebilir.

  • İş sahibinin olmaması. Çalışmayı bir inovasyon veya BT ekibi sponsorluyor, ancak operasyonel birimde kimse bu çalışma nedeniyle bir süreci değiştirmeyi kabul etmiyor.
  • Veri erişiminin varsayılması. Demoda elle hazırlanmış bir dışa aktarım kullanılmış, gerçek veri ise kendi sahipleri, yetkileri ve kalite sorunları olan sistemlerde duruyor.
  • Mevcut sistemlerle entegrasyonun planlanmaması. Prototip tek başına çalıştığı için ERP, CRM veya üretim sistemleriyle bağlantı maliyeti hiç hesaplanmıyor.
  • Kabul kriterlerinin eksikliği. Net bir hedef yoksa başarı bir görüş meselesi haline gelir ve başarılı ilan edilemeyen bir projeye ek bütçe ayrılması nadirdir.

Demonun ötesinde canlı sistem için gerekenler

Demo ana akışı kapsar. Canlı bir sistem ise ana akışın çevresindeki her şeyi de kapsamak zorundadır. Aşağıdaki liste, bir kurumsal sistemin canlıya alınmadan önce sahip olmasını beklediğimiz unsurları içerir.

  • Kurumsal kimlik sağlayıcısına bağlı kimlik doğrulama ve yetkilendirme, gerçek iş fonksiyonlarına uygun rollerle.
  • Kullanıcılar bildirmeden önce operatörün hataları, yavaş istekleri ve başarısız işleri görmesini sağlayan loglama ve izleme.
  • Alanları, formatları, güncelleme sıklığını ve kaynak sistemin beklenmeyen veri göndermesi durumunda yapılacakları tanımlayan veri sözleşmeleri.
  • Otomatikleştirilmiş ve önceden denenmiş dağıtım ve geri alma prosedürleri, böylece hatalı bir sürüm dakikalar içinde geri çekilebilir.
  • Mimariyi, arayüzleri, yapılandırmayı ve işletim prosedürlerini kapsayan dokümantasyon.
  • Nöbet sorumluluğu üstlenen, olayları çözmek için gerekli erişim ve bilgiye sahip, adı belli bir sorumlu.

Proje nasıl aşamalandırılır

Aşamalı yaklaşım, her yatırımı o ana kadar öğrenilenlerle orantılı tutar. İlk adım keşif aşamasıdır. Bu aşamada iş problemi, etkilenen kişiler, ilgili sistemler ve mevcut veriler netleştirilir. Çıktı, kısa bir doküman ve devam edilip edilmeyeceğine dair bir karardır.

Ardından, önceden üzerinde anlaşılmış ölçülebilir tek bir kabul kriteriyle PoC çalışması yapılır. Bir doküman sınıflandırma sistemi için bu kriter, ayrılmış bir örnek kümesi üzerinde asgari doğruluk oranı olabilir. Bir tahminleme modeli için ise mevcut manuel yönteme göre bir hata eşiği olabilir. Amaç, net bir evet ya da hayır cevabı almaktır.

Sonraki adım, gerçek veri ve sınırlı sayıda gerçek kullanıcıyla yürütülen pilot uygulamadır. Entegrasyon sorunları, veri kalitesi problemleri ve süreç soruları bu aşamada ortaya çıkar. Pilotu canlıya hazırlık çalışması izler. Bu çalışma güvenlik incelemesini, performans testlerini, izlemeyi, yedekleme ve geri yüklemeyi, dağıtım hattını kapsar. Son aşama teslimdir. Eğitim, dokümantasyon ve kimin neye ne kadar sürede yanıt vereceğini belirten bir destek düzeni bu aşamada tamamlanır.

Sözleşme öncesinde tedarikçiye sorulacak sorular

Alıcı taraf, birkaç doğrudan soruyla çok şey öğrenebilir. Tedarikçi tarafında kim keşiften teslime kadar projede kalacak. Her aşamanın kabul kriterleri nelerdir ve bunların karşılanıp karşılanmadığına kim karar verir. Sistem canlıya alındıktan sonra nasıl izlenecek ve arıza durumunda kim bilgilendirilecek. Kaynak kodun, eğitilmiş modellerin ve dokümantasyonun sahibi kimdir. Sistem nasıl dağıtılacak ve başarısız bir sürüm nasıl geri alınacak.

İşin hangi bölümlerinin müşteriye bağlı olduğunu ve bunların hangi tarihlere kadar tamamlanması gerektiğini sormak da yerindedir. Veri erişimi, test ortamları ve konu uzmanları bunlara örnektir. Müşteri tarafındaki gecikmeler takvimin kaymasının yaygın nedenlerinden biridir ve bunların baştan adlandırılması yönetimini kolaylaştırır.

Sonuç

PoC'den canlıya geçiş, büyük ölçüde sahiplik, veri, entegrasyon ve işletim konularına bağlıdır. Gösterilen teknoloji ise sürecin yalnızca bir parçasını oluşturur. Bu soruları erken aşamada çözen ve işi net kriterlerle aşamalandıran kurumlar, bitmeyen pilot çalışmalarda daha az zaman harcar, kullanıcıların güvendiği sistemleri işletmeye ise daha fazla zaman ayırır.