Kurumsal Şirketlerle Pilot Proje ve PoC Rehberi: Denemeden Ticari Karara

Kurumsal pilot proje ve PoC nasıl hazırlanır?

İyi bir kurumsal pilot proje, belirli bir problemin sınırlı kapsamda denenmesini ve sonuçta bir ticari karar verilmesini sağlar. PoC, yani kavram kanıtı, çoğunlukla teknik bir yaklaşımın uygulanabilirliğini sınar. Pilot ise ürünün belirli kullanıcılar ve gerçek iş koşulları içindeki kullanımını inceleyebilir. Bu terimler kurumdan kuruma farklı kullanıldığı için taraflar önce kendi çalışmalarının amacını netleştirmelidir.

Girişim açısından kritik konu, denemenin sonunda neyin öğrenileceğidir. Birkaç haftalık çalışma yalnızca güzel bir sunum üretirse satış süreci ilerlemeyebilir. Buna karşılık dar bir problem için sağlam veri ve açık karar ölçütü oluşturulması, hem olumlu hem olumsuz sonucu yararlı hale getirir. Bu yazı sözleşme örneği değil, görüşme ve proje hazırlığı rehberidir.

Buradaki senaryolar varsayımsaldır. Belirli bir kurumun satın alma koşullarını, Orion TEKMER'in müşteri bağlantılarını veya gerçekleşmiş proje sonuçlarını temsil etmez. Hukuki, mali ve sektörel yükümlülükler somut projeye göre uzmanlarla değerlendirilmelidir. Amaç, girişim ile kurumsal müşteri arasındaki ilk çalışmanın daha net yönetilmesini sağlamaktır.

1. Denemenin hangi kararı destekleyeceğini yazın

Pilot başlamadan önce cevaplanacak tek ana soru seçin. Sistem teknik olarak kurulabiliyor mu, kullanıcı işi tamamlayabiliyor mu, mevcut sürece göre anlamlı fayda oluşuyor mu? Bunların hepsini aynı küçük çalışmada cevaplamak mümkün olmayabilir. Öncelik belirlemek kapsamı ve gerekli kaynakları daha anlaşılır hale getirir.

Ana soru müşterinin kararıyla bağlantılı olmalıdır. Örneğin sonuç olumlu olursa bir bölümde ücretli kullanıma geçilmesi değerlendirilecek mi? Yoksa kurum yalnızca teknolojiyi tanımak mı istiyor? İki durum da meşru olabilir, fakat girişimin emek ve gelir beklentisi farklı kurulmalıdır. Tanışma çalışmasını satışa yakın fırsat gibi görmek nakit planını yanıltabilir.

Başlangıç notunda neyin kanıt sayılacağı da yazılmalıdır. Bir çalışanın olumlu yorumu, farklı kullanıcıların işi tekrar edebilmesi veya belirlenen teknik koşulların karşılanması farklı düzeyde kanıttır. Taraflar aynı sonucu farklı yorumlamasın diye değerlendirme yöntemi önceden konuşulmalıdır.

Karar tarihi bulunması önemlidir. Pilot bittiğinde herkesin takvimi doluysa sonuçlar aylarca bekleyebilir. İlk toplantıda kapanış görüşmesini planlamak, projenin yalnızca teknik ekibin gündeminde kalmasını önleyebilir. Bu görüşmede karar verecek rollerin hazır olması gerekir.

2. Kurum içindeki proje sahibini ve karar yolunu bulun

Kurumsal müşteride ürünü seven kişi ile proje için kaynak ayırabilen kişi farklı olabilir. Pilotun sürdürülebilmesi için günlük koordinasyonu yapacak bir proje sahibi gerekir. Bunun yanında teknik değerlendirme, veri erişimi, satın alma ve nihai iş kararı için kimlerin devreye gireceği anlaşılmalıdır.

Girişim bu haritayı bir güç gösterisi olarak değil, iş akışı olarak ele almalıdır. Hangi belge kime gider, hangi onay hangi aşamada gerekir ve kimin yokluğu takvimi durdurur? Soruların cevabı erken alındığında bekleme süreleri daha doğru planlanır. Kurumun iç süreci hakkında tahminde bulunmak yerine açıkça sormak daha verimlidir.

Tek bir kişiye bağımlı ilişki kırılgan olabilir. Proje sahibi görev değiştirirse veya izne ayrılırsa çalışmanın ne olacağı konuşulabilir. Kısa bir ortak durum notu ve paylaşılan karar kaydı, projenin bilgisini kişisel e-posta dizilerinden çıkarır. Ancak bilgi paylaşımı kurumun izin ve erişim düzenine uygun olmalıdır.

TEKMER içindeki iş geliştirme görüşmeleri, bu rol haritasını hazırlamaya yardımcı olabilir. Tanıştırma veya bir etkinlikte görüşme fırsatı, kurumun pilot kabul ettiği anlamına gelmez. Resmî proje kapsamı ve sorumluluklar taraflar arasında ayrıca netleştirilmelidir.

3. Kapsamı bir sayfaya sığdırın

Pilot kapsamı kısa yazılamıyorsa tarafların beklentileri yeterince net olmayabilir. Bir sayfada problem, kullanıcı grubu, veri kapsamı, teslimler, süre ve kapsam dışı işler yer alabilir. Bu belge ayrıntılı sözleşmenin yerine geçmez; o sözleşmeye gidecek iş tanımını anlaşılır kılar.

Kullanıcı grubunun sınırı önemlidir. İlk pilot bir ekipte denenirken başka bölümlerin talepleri projeye eklenebilir. Her yeni kullanım biçimi yeni veri, eğitim ve destek ihtiyacı doğurabilir. Bu nedenle kapsam değişikliğinin nasıl değerlendirileceği baştan konuşulmalıdır. Değişiklik mümkün olabilir, ancak bedelsiz ve takvimsiz olmamalıdır.

Teslim tanımları gözlemlenebilir olmalıdır. “Entegrasyon tamamlanacak” yerine hangi veri akışının hangi ortamda çalışacağı yazılabilir. “Raporlama yapılacak” deniyorsa raporun kime, hangi sıklıkta ve hangi bilgiyle sunulacağı belirlenebilir. Belirsiz kelimeler projenin sonunda farklı beklentiler doğurur.

Kapsam dışı işleri açık söylemek müşteriyi uzaklaştırmak zorunda değildir. Tam tersine, sınırlı çalışmanın neden küçük tutulduğunu anlatır. Girişim ilk pilotta bütün ürünü kurmak yerine karar için gerekli parçayı teslim eder. Böylece sonraki aşamanın iş yükü ve fiyatı daha gerçekçi konuşulabilir.

4. Başlangıç durumunu ölçmeden fayda iddiası kurmayın

Yeni çözümün etkisini anlamak için mevcut durum bilinmelidir. İş bugün nasıl yapılıyor, hangi kaynaklar kullanılıyor ve nerede bekleniyor? Başlangıç verisi olmadan sonucun daha iyi olduğu söylenebilir, fakat bu iddianın dayanağı zayıf kalır. Pilotun bir bölümü mevcut yöntemi anlamaya ayrılabilir.

Ölçüm yalnızca süreye odaklanmak zorunda değildir. Hata sonrası tekrar işleme, bilgi arama, onay bekleme veya kullanıcı memnuniyeti de önemli olabilir. Seçilen ölçütler müşterinin problemiyle ilişkili olmalıdır. Ölçmesi kolay olduğu için ilgisiz bir göstergeyi başarı ölçütü yapmak yanıltıcıdır.

Dış değişkenleri de not edin. Pilot sırasında ekip yapısı, iş hacmi veya kullanılan başka araçlar değişirse sonuçların tamamı yeni ürüne bağlanmamalıdır. Bu durum çalışmayı değersiz kılmaz; yorumun sınırlarını gösterir. Sonuç raporunda gözlenen etki ile olası açıklamalar ayrılmalıdır.

Ölçümü yapan kişi ve yöntem sabit tutulabildiğinde karşılaştırma daha anlaşılır olur. Kullanıcı tahminleri ile sistem kayıtlarını aynı veri türü gibi sunmamak gerekir. Her kaydın nasıl elde edildiği belli olduğunda müşteri sonucu daha rahat değerlendirir ve sonraki karar için hangi ek kanıtın gerektiğini görür.

5. Veri, erişim ve kurulum sorumluluklarını netleştirin

Birçok pilot teknik zorluktan önce gerekli erişimlerin sağlanamaması nedeniyle bekler. Kullanıcı hesabı, örnek veri, test ortamı veya kurum içi ağ izni zaman alabilir. Bunlar girişimin takviminde görünmez bırakılırsa teslim tarihi gerçekçi olmaz. Başlangıç koşullarını açık yazmak bu sorunu azaltır.

Her girdi için sağlayan taraf, tarih ve yeterlilik koşulu belirlenebilir. Örneğin veri dosyası teslim edilmesi tek başına yeterli olmayabilir; biçimin açıklanması ve testte kullanılmasının uygun olması da gerekebilir. Girişim veriyi aldıktan sonra ilk inceleme yapıp eksikleri kısa sürede bildirmelidir.

Ürünün dış hizmetler veya bulut bileşenleri kullanması halinde veri akışı anlaşılır biçimde anlatılmalıdır. Kurumsal müşterinin güvenlik ve gizlilik beklentileri öğrenilmeden varsayılan kurulumla ilerlemek gecikme yaratabilir. Teknik ve hukuki değerlendirme gereken konular ilgili uzmanlara taşınmalıdır.

Pilot sonunda erişimlerin kapatılması, verilerin tutulması veya silinmesi gibi işler de proje planına dahil edilmelidir. Deneme bittikten sonra belirsiz kalan hesaplar ve dosyalar, kapanışın tamamlanmadığını gösterir. Bu işlemlerin yöntemi ve sorumluluğu tarafların koşullarına göre açıkça belirlenmelidir.

6. Ücret ve emek dengesini açık konuşun

Pilotun ücretli veya ücretsiz olması tek başına iyi ya da kötü olduğu anlamına gelmez. Asıl soru, girişimin ne kadar kaynak ayırdığı ve bu kaynağın hangi öğrenme veya ticari değeri ürettiğidir. Ücretsiz deneme geniş entegrasyon, özel geliştirme ve sürekli destek gerektiriyorsa maliyet görünür hale getirilmelidir.

Teklifte keşif, kurulum, pilot desteği ve ek geliştirme işleri ayrı gösterilebilir. Böylece müşteri hangi kısmın tekrar kullanılabilir ürün, hangi kısmın kendisine özgü çalışma olduğunu anlar. Girişim de tekrar eden ürünü ile hizmet gelirini karıştırmadan planlayabilir.

Ödeme takvimi, kabul koşulları ve giderlerin kim tarafından karşılanacağı konuşulmalıdır. Bu konuların ayrıntılı düzenlemesi uygun uzman incelemesiyle yapılmalıdır. İş görüşmesinde ise tarafların beklentilerinin açık olması gerekir. Sadece toplam bedel üzerinde anlaşmak, teslim ve ödeme tartışmalarını kendiliğinden çözmez.

Müşterinin referans olarak kullanılabilmesi veya sonuçların yayımlanması da otomatik varsayılmamalıdır. Ücretsiz çalışma karşılığında görünürlük beklentisi varsa bunun nasıl ve hangi onayla gerçekleşeceği netleştirilmelidir. Bir kurumun adını tanıtımda kullanma izni, pilotun başarılı olmasıyla kendiliğinden doğmaz.

7. Teknik ilerlemeyi ticari ilerlemeden ayrı takip edin

Pilot panosunda teknik işler tamamlanırken satış fırsatı yerinde sayabilir. Bu nedenle iki ayrı ilerleme hattı izlemek yararlıdır. Teknik hatta kurulum, test ve hata giderme; ticari hatta karar ölçütü, bütçe görüşmesi ve sonraki aşama değerlendirmesi bulunabilir. Her iki hattın sorumluları belli olmalıdır.

Haftalık toplantı yalnızca yapılan işleri saymakla geçmemelidir. Hangi risk arttı, hangi karar bekliyor ve kimin girdisi gerekiyor? Bu sorular konuşulduğunda toplantı bir durum sunumundan çalışma aracına dönüşür. Her notun yanına sahip ve tarih yazılması takip yükünü azaltır.

Sorunlar ortaya çıktığında önce kapsamla ilişkileri incelenmelidir. Bir hata kabul ölçütünü etkiliyorsa öncelikli olabilir. Kapsam dışı yeni bir özellik ise sonraki aşamaya bırakılabilir. Her talebi acil kabul etmek, pilotun asıl sorusunu cevaplamasını engelleyebilir.

Müşteri ile paylaşılacak rapor kısa ama somut olmalıdır. Tamamlanan teslimler, gözlenen sonuçlar, açık sorunlar ve gelecek hafta beklenen girdiler yeterli bir temel oluşturabilir. Girişim içindeki ayrıntılı teknik kayıtlarla müşterinin karar için ihtiyaç duyduğu özet birbirinden ayrılabilir.

8. Varsayımsal örnek: depo iş akışı yazılımı

Kurgusal bir girişim, depodaki toplama görevlerini daha anlaşılır biçimde sıraya koyan yazılım geliştirmiş olsun. Müşteri ilk görüşmede bütün depoda kullanım ister. Girişim, bu kapsamın ilk deneme için fazla geniş olduğunu görür ve tek bir iş akışında sınırlı kullanıcı grubuyla başlamayı önerir. Amaç, kullanıcıların görevleri daha az geri dönüşle tamamlayıp tamamlamadığını incelemektir.

Başlangıçta mevcut süreç gözlenir. Bazı gecikmelerin yazılımdan değil ürün yerleşiminden kaynaklandığı anlaşılır. Bu nedenle pilot sonuçları yorumlanırken fiziksel düzen değişiklikleri ayrıca kaydedilir. Ürün yalnızca kendi etkileyebildiği adımlar üzerinden değerlendirilir.

Deneme sırasında başka bir bölüm yeni rapor ister. Taraflar talebi kaydeder, fakat ilk kapsamın sonuna eklemez. Kapanış görüşmesinde temel kullanımın sonucu ve yeni raporun ayrı iş paketi ele alınır. Böylece pilot bitiş tarihi belirsiz biçimde uzamaz.

Bu örnek, küçük kapsamın düşük hedef anlamına gelmediğini gösterir. Dar çalışma müşterinin gerçek kararına hizmet ediyorsa daha büyük kullanıma geçiş için sağlam zemin sağlayabilir. Senaryo gerçek bir müşteriyi veya doğrulanmış verim artışını anlatmaz; proje tasarımını somutlaştırmak için kullanılmıştır.

9. Ar-Ge desteği ile sıradan pilotu karıştırmayın

Her pilot çalışma Ar-Ge projesi değildir. Hazır bir ürünün kurulması, kullanıcı eğitimi veya rutin uyarlama farklı nitelikte işler olabilir. Destek programı düşünülüyorsa projenin teknik içeriği ve ilgili çağrının koşulları birlikte incelenmelidir. Sırf kurumsal müşteri bulunduğu için otomatik destek hakkı olduğu söylenemez.

TÜBİTAK'ın 1707 program sayfası, müşteri kuruluş ile KOBİ ölçeğindeki tedarikçi kuruluşun birlikte yer aldığı, ticarileşme odaklı Ar-Ge yaklaşımını açıklar. Bu yapı, müşteri ihtiyacının geliştirme sürecine bağlanmasına bir örnektir. Başvuru uygunluğu ve güncel çağrı koşulları resmî belgelerden ayrıca kontrol edilmelidir.

Destek başvurusu yapılacaksa pilot planı ile destek dosyası tutarlı olmalıdır. İş paketleri, sorumluluklar ve beklenen çıktılar iki ayrı hikâye anlatmamalıdır. Bununla birlikte başvuru takvimi müşterinin iş takvimiyle uyuşmayabilir. Bu fark nakit ve kaynak planında görünür tutulmalıdır.

TEKMER içinde program değerlendirmesi konusunda yönlendirme alınabilir; fakat merkezi kullanmak destek sonucunu garanti etmez. Girişimin doğru programa, doğru giderlerle ve uygun iş tanımıyla başvurması gerekir. Destek, müşteri problemini doğrulama çalışmasının yerine geçmemelidir.

10. Kapanış raporunu satış sunumu değil karar belgesi yapın

Kapanış raporu başlangıç sorusuna dönmelidir. Hangi koşullarda ne denendi, ne gözlendi ve hangi sınırlar kaldı? Yalnızca olumlu ekran görüntülerinden oluşan bir sunum, sonraki yatırım veya satın alma kararına yeterli dayanak sağlamaz. Başarılı ve sorunlu örnekler birlikte değerlendirilmelidir.

Sonuçlar teknik uygunluk, kullanıcı deneyimi ve ekonomik anlam bakımından ayrı yazılabilir. Bir alandaki güçlü sonuç diğerindeki eksikliği gizlememelidir. Örneğin kullanıcılar ürünü kolay bulabilir, ancak kurulum maliyeti geniş kullanım için yüksek olabilir. Bu durumda sonraki çalışma maliyeti azaltmaya odaklanabilir.

Üç karar seçeneği hazırlayın: ticari kullanımı değerlendirmek, sınırlı ek kanıt toplamak veya devam etmemek. Her seçeneğin gerekçesi ve sonraki sorumlusu belli olsun. “İletişimde kalalım” cümlesi tek başına proje kapanış kararı değildir. Girişim fırsatın durumunu gerçekçi sınıflandırmalıdır.

Pilot tecrübesini ürün yol haritasına aktarırken müşteriye özgü işleri ayırın. Aynı ihtiyaç başka müşterilerde de görülüyorsa genel ürün özelliği olabilir. Tek kuruma özgü gereksinim ise hizmet işi olarak yönetilebilir. Bu ayrım, girişimin hangi iş modelinde büyümek istediğini açık tutar.

Sık sorulan sorular

PoC ile pilot aynı şey mi?

Terimler her kurumda aynı kullanılmaz. Genel olarak PoC bir yaklaşımın yapılabilirliğine, pilot ise sınırlı gerçek kullanımına odaklanabilir. Önemli olan terimin kendisinden çok çalışmanın amacı, kapsamı ve karar ölçütünün ortak anlaşılmasıdır.

Kurumsal müşteri ücretsiz pilot istiyorsa kabul edilmeli mi?

Kaynak ihtiyacı, öğrenme değeri ve ticari ilerleme ihtimali birlikte değerlendirilmelidir. Sınırsız özel geliştirme içeren ücretsiz çalışma girişimi zorlayabilir. Dar kapsam, süre ve kapanış kararı olmadan kabul vermek yerine beklentileri netleştirmek yararlıdır.

Başarılı pilot mutlaka satışa dönüşür mü?

Hayır. Bütçe, öncelik, satın alma süreci veya kurum içi değişiklikler sonucu etkileyebilir. Bu nedenle ticari karar yolu pilotun başında konuşulmalı, teknik başarı ile sipariş birbirine eşit kabul edilmemelidir.

TEKMER pilot müşteri bulmayı garanti eder mi?

Hayır. Merkezin iş geliştirme ve ağ olanakları değerlendirilebilir, ancak müşteri kararı ayrı bir süreçtir. Orion ön başvuru formunda hedef müşteri ve pilot ihtiyacını somut anlatmak, beklentilerin daha iyi anlaşılmasına yardımcı olur.

Pilot sırasında kapsam değişirse ne yapılmalı?

Yeni talep önce mevcut karar sorusuyla karşılaştırılmalıdır. Talep temel sonucu değerlendirmek için zorunluysa etkisi birlikte incelenebilir. Süre, ücret, veri ihtiyacı ve sorumluluk değişiyorsa bunlar kayda alınmalıdır. İlk planı sessizce genişletmek, tarafların farklı bir projede çalıştığını geç fark etmesine yol açabilir. Talep sonraki aşamaya aitse ayrı iş olarak saklanabilir; her iyi fikrin aynı pilot içinde uygulanması gerekmez.

Girişim pilot bitmeden yeni müşteri aramayı bırakmalı mı?

Tek bir denemeye bütün satış kapasitesini ayırmak dikkatle değerlendirilmelidir. Pilot önemli öğrenme sağlayabilir, fakat tek müşterinin ihtiyaçları bütün pazarın ihtiyaçlarını temsil etmeyebilir. Ekip kaynaklarına uygun biçimde başka görüşmeleri sürdürebilir. Böylece pilot sırasında ortaya çıkan taleplerin başka kurumlarda da karşılık bulup bulmadığı görülür. Burada amaç mevcut müşterinin işini aksatmak değil, ürün yönünü tek bir örnekten çıkarmamaktır.

Kapanış toplantısına nasıl hazırlanılmalı?

Başlangıç kapsamını, ölçüm yöntemini ve gözlenen sonuçları aynı dosyada birleştirin. Açık kalan noktaları saklamadan belirtin. Sonraki aşama için gereken iş, süre ve sorumlulukları taslak olarak hazırlayın. Müşterinin toplantıda hangi kararı verebileceğini önceden öğrenin. Karar veremeyecek bir ekibe kesin satın alma sonucu bekleyerek gitmek iki tarafı da zorlayabilir. Toplantı sonunda karar çıkmazsa hangi bilginin eksik olduğu ve kimin tamamlayacağı belirlenmelidir. Bu kayıt, projenin belirsiz biçimde açık kalmasını önler. Girişimin yatırım hazırlığında da pilotun gerçek durumunu doğru anlatmasına yardımcı olur. Deneme tamamlandı, ticari değerlendirme sürüyor ve sipariş alındı ifadeleri ayrı aşamalar olarak kullanılmalıdır.