TEKMER Başvuru Dosyası Hazırlama: Problemden Bütçeye Uygulamalı Rehber

TEKMER başvuru dosyası nasıl hazırlanır?

TEKMER başvuru dosyası; probleminizi, teknoloji çözümünüzü, ekibinizi, mevcut kanıtlarınızı ve çalışma planınızı aynı hikâye içinde anlatmalıdır. İyi dosya en uzun dosya değildir. Değerlendiren kişinin bugün nerede olduğunuzu, neyi henüz bilmediğinizi ve merkezden hangi desteği istediğinizi anlamasını sağlar. Önce ilgili merkezin güncel formunu ve belge taleplerini öğrenin; ardından bu rehberdeki hazırlık yöntemini kendi başvurunuza uyarlayın.

Bu yazı bütün TEKMER'ler için tek bir zorunlu belge listesi ilan etmez. Başvuru koşulları ilgili kurum ve programa göre değerlendirilmelidir. Buradaki amaç, teknik veya ticari anlatımınızın tutarlı olmasını sağlayacak bir çalışma düzeni önermektir. Bir başvuru formunu doldurmak ile projenin mantığını kurmak farklı işlerdir. Önce mantığı netleştirirseniz farklı formlara bilgi aktarmak daha kolay olur ve çelişki riski azalır.

KOSGEB Teknoloji Merkezi Destek Programı teknoloji merkezlerinin gelişimine yönelik resmî çerçeveyi sunar. Bir girişimin belirli bir merkeze kabulü için ise o merkezin güncel değerlendirme süreci öğrenilmelidir. Merkez işletmecisine yönelik program belgeleriyle girişim başvurusunu karıştırmamak, hazırlığın doğru yerden başlamasına yardımcı olur. Aşağıdaki içerik özgün bir dosya hazırlama rehberidir.

Önce başvurunun amacını tek cümlede yazın

Dosyayı hazırlamadan önce neden başvurduğunuzu açıklayan bir cümle kurun. Çalışma alanı, müşteri doğrulaması, teknik mentörlük, ekip gelişimi veya yatırım hazırlığı farklı amaçlardır. Hepsine ihtiyaç duyabilirsiniz; fakat öncelik sırası belli olmalıdır. Önümüzdeki altı ayda çözmek istediğiniz en önemli darboğazı belirlemek, dosyanın diğer bölümlerini de daha tutarlı hale getirir. Genel destek istiyoruz ifadesi değerlendirme için yeterince açıklayıcı değildir.

Varsayımsal bir yazılım girişimi için amaç, küçük işletmelerle ilk pilotları yürütmek ve ürünün kullanımını doğrulamak olabilir. Donanım girişimi içinse belirli bir teknik belirsizliği azaltmak ve saha denemesine hazırlanmak öncelikli olabilir. Bu iki ekip aynı başvuru formunu doldursa bile anlatımları farklı olmalıdır. Formdaki başlıkları birbirinden bağımsız cevaplamak yerine, her cevabın temel amaca nasıl bağlandığını düşünün.

Amaç cümlenizi kurucu ekibin bütün üyeleriyle paylaşın. Herkes farklı bir öncelik söylüyorsa dosyaya başlamadan önce bu ayrılığı konuşun. Başvuru görüşmesinde kurucuların birbirini tamamlaması beklenir; aynı soruya çelişkili cevaplar vermesi projenin anlaşılmasını zorlaştırır. Ortak bir amaç, bütün ayrıntılarda aynı düşünmek anlamına gelmez. Hangi konuda karar verildiğini ve hangi konunun hâlâ tartışıldığını bilmek anlamına gelir.

Problem bölümünü çözümünüzden bağımsız anlatın

Problem bölümünde önce müşterinin bugün yaşadığı durumu açıklayın. Hangi işi yapmaya çalışıyor, hangi aşamada zorlanıyor ve bu zorluğun sonucu ne oluyor? Çözümünüzün özelliklerini bu bölüme taşımamaya çalışın. Müşterinin problemi sizden önce de var olmalıdır. Ürünümüz olmadığı için süreç verimsiz ifadesi yerine, mevcut iş akışındaki gözlemlenebilir güçlüğü anlatmak daha ikna edicidir.

Problemi destekleyen kanıtlar varsa türünü belirtin. Müşteri görüşmesi, saha gözlemi, kullanım kaydı veya deney sonucu farklı bilgiler sağlar. Birkaç görüşmeden elde edilen bulguyu bütün pazarın kesin davranışı gibi sunmayın. Görüştüğünüz kitlenin sınırını ve henüz öğrenilmesi gereken konuları yazın. Bu açıklık, dosyanızı zayıflatmaz; iddialarınızın neye dayandığını göstererek güvenilirliğini artırır.

Problemin sıklığını ve önemini de düşünün. Nadir yaşanan ama yüksek sonuç doğuran bir sorunla sık yaşanan küçük bir aksaklık farklı ürün ve satış modeli gerektirebilir. Henüz nicel ölçümünüz yoksa hangi veriyi toplamayı planladığınızı açıklayın. Başvuruyu okuyan kişi yalnızca ilginç bir fikir değil, gerçek bir ihtiyacı araştıran ekip görmelidir. Problem bölümünün görevi bu bağlantıyı kurmaktır.

Çözümü kullanıcı akışı ve teknoloji bileşeniyle açıklayın

Çözüm bölümünü iki katmanda yazmak yararlıdır. İlk katmanda kullanıcı ürünle ne yapacak sorusunu cevaplayın. İkinci katmanda bunu mümkün kılan teknoloji bileşenini anlatın. Teknik terimler gerekli olabilir; fakat her terimin ürünün değerine nasıl katkı verdiği anlaşılmalıdır. Bir değerlendirme kurulunda farklı uzmanlıklar bulunabileceğini düşünerek, ayrıntıya girmeden önce genel resmi açık biçimde kurun.

Varsayımsal bir belge işleme ürününde kullanıcı dosyayı yüklüyor, sistem belirli alanları çıkarıyor ve kullanıcı sonucu kontrol ediyor olabilir. Bu akış ürünün kullanımını anlatır. Kullanılan yöntem, hata yönetimi ve veri işleme yaklaşımı ise teknik katmanı açıklar. İkisinin ayrı anlatılması, teknolojinin sadece sunumu süsleyen bir ifade olarak kalmasını önler. Değerlendiren kişi ürünün nerede çalıştığını daha kolay kavrar.

Bugün çalışan özellikleri, geliştirme aşamasındakileri ve ileride düşünülenleri ayırın. Demo yalnızca sınırlı veriyle çalışıyorsa bunu söyleyin. Yol haritasındaki özelliği mevcut ürün gibi göstermek sonraki görüşmede güven sorunu yaratabilir. Dosyanızda küçük ama doğrulanmış bir kapasiteyi açıkça anlatmak, çok geniş fakat belirsiz bir vizyondan daha yararlı olabilir. Vizyonunuz bulunsun; ancak bugünkü durumun yerini almasın.

Yenilik iddiasını karşılaştırma üzerinden kurun

Projenin yenilik tarafını anlatırken benzersiziz veya rakipsiziz gibi geniş ifadelerden kaçının. Müşterinin bugün kullandığı alternatifleri araştırın. Alternatif yalnızca başka bir teknoloji şirketi olmayabilir; elektronik tablo, manuel işlem veya dışarıdan hizmet de olabilir. Bu seçeneklerin hangi ihtiyacı karşıladığını ve sizin hangi noktada farklılaştığınızı açıklayın. Gerçek alternatifleri tanımak, ürünün konumunu daha sağlam kurar.

Karşılaştırma tablosunda bütün alanlarda kendinizi üstün göstermeye çalışmayın. Her çözümün belirli koşullarda güçlü veya zayıf yönleri olabilir. Sizin öncelikli kullanım senaryonuzu seçmeniz bu yüzden önemlidir. Örneğin daha hızlı kurulabilen bir ürün, daha az özelleştirme sunabilir. Bu bir hata olmak zorunda değildir; hedef müşteriye uygun bir tercih olabilir. Dosyada bu tercihin mantığını anlatın.

Teknik yenilik ile ticari farklılaşmayı da ayırın. Yeni bir yöntem geliştirmek, yeni bir müşteri segmentine ulaşmak ve farklı hizmet modeli kurmak aynı iddia değildir. Projenizde hangileri varsa ayrı açıklayın. Kanıtlanmamış bir avantajı ölçülmüş sonuç gibi yazmayın. Bir iddiayı test etmek için hangi denemenin yapılacağını belirtmek, yenilik bölümünü tanıtım metninden uygulanabilir araştırma planına dönüştürür.

Kanıt dosyasını küçük ve izlenebilir tutun

Başvuruya eklenecek kanıtların amacı dosyayı ağırlaştırmak değil, önemli iddiaları desteklemektir. Ürün ekranı, kısa demo, müşteri görüşmesi özeti veya test sonucu seçerken hangi cümleyi desteklediğini düşünün. İlgisiz belge sayısını artırmak okuyanın dikkatini dağıtabilir. Her ekin başına kısa açıklama, tarih ve kapsam bilgisi koyun. Böylece değerlendiren kişi belgeyi neden gördüğünü anlar.

Kanıtları gerçekleşmiş, planlanmış ve görüşme aşamasında şeklinde ayırabilirsiniz. İmzalanmamış iş birliğini kesinleşmiş ortaklık, olumlu görüşmeyi satış, kayıt olan kullanıcıyı aktif kullanıcı olarak göstermeyin. Bu kavramlar farklı gelişim aşamalarını ifade eder. Dosyada küçük bir sayı kullanmak sorun değildir; sayının doğru tanımlanması daha önemlidir. Şeffaf anlatım, görüşmede daha yararlı sorular sorulmasını sağlar.

Hassas bilgi içeren belgelerde paylaşım kapsamını ayrıca değerlendirin. Bütün müşteri verisini veya teknik ayrıntıyı ilk başvuruda sunmak gerekmeyebilir. İlgili merkezin istediği kanıt türünü öğrenin ve uygun özet hazırlayın. Kişisel veya ticari bilgileri gereksiz yere çoğaltmadan projenin durumunu gösterebilmek iyi dosya yönetiminin parçasıdır. Belge düzeni, başvuru sonrasında yatırım veya ortaklık görüşmelerinde de işinize yarayabilir.

Ekip bölümünde ünvan yerine sorumluluk gösterin

Ekip bölümünde özgeçmişleri art arda sıralamak yerine proje için gerekli işleri ve bu işleri kimin üstlendiğini açıklayın. Teknik geliştirme, ürün yönetimi, satış, operasyon ve finansal takip gibi alanlarda sorumluluk dağılımı görünür olmalıdır. Her iş için ayrı kişi bulunması gerekmez; küçük ekipte bir kişi birden fazla rol üstlenebilir. Önemli olan kritik işlerin sahipsiz kalmamasıdır.

Kurucuların projeye ayıracağı zamanı dürüstçe belirtin. Tam zamanlı çalışma planı ile fiilî çalışma durumu farklıysa ayrımı açıklayın. Dışarıdan alınacak hizmetlerin kapsamını da yazın. Bir danışmanın veya hizmet sağlayıcının katkısı ile kurucu ekibin iç yetkinliği aynı şey değildir. Değerlendiren kişinin projenin hangi bilgiye doğrudan sahip olduğunu ve hangi kaynaklara bağımlı olduğunu anlaması gerekir.

Eksik yetkinlikleri saklamak yerine tamamlama planını anlatın. İlk müşteri görüşmesini yapacak kişi belirsizse bu, teknik ürünün gelişmesini de etkileyebilir. Ekip bölümünün sonunda önümüzdeki dönemde hangi rolün güçlendirilmesi gerektiğini yazabilirsiniz. Böylece TEKMER'den beklenen mentörlük veya bağlantı ihtiyacı somutlaşır. İyi ekip anlatımı geçmiş başarı kadar bugünkü çalışma düzenini de görünür hale getirir.

İş planını faaliyet ve karar noktalarına bölün

İş planında yalnızca ürün geliştirilecek, satış yapılacak gibi geniş başlıklar kullanmak ilerlemeyi izlemeyi zorlaştırır. Her dönemde hangi işin tamamlanacağını ve o işin hangi kararı mümkün kılacağını yazın. Müşteri görüşmeleri yapılması bir faaliyettir; hedef müşteri tanımının netleştirilmesi ise bir karar çıktısı olabilir. İkisini birlikte göstermek, takvimin neden o sırayla kurulduğunu açıklar.

Varsayımsal üç aylık planda önce problem görüşmeleri, sonra sınırlı prototip, ardından küçük pilot bulunabilir. Ancak her girişimin sırası aynı değildir. Teknik belirsizliği yüksek projede önce yapılabilirlik denemesi gerekebilir. Satış yapan şirkette ise ürün geliştirmekten önce kullanım verisini incelemek daha anlamlı olabilir. Planı genel bir şablona değil, en önemli belirsizliğin çözülme sırasına göre düzenleyin.

Bağımlılıkları belirtmeyi unutmayın. Müşteriden veri gelmeden başlayamayacak çalışma, laboratuvar erişimine bağlı test veya belirli bir kişinin katılımını gerektiren faaliyet varsa bunu yazın. Takvimde yalnızca iyimser senaryoya yer vermek gecikmelerin etkisini görünmez kılar. Alternatif çalışma adımını düşünmek, başvuru dosyasının gerçek bir yönetim aracına dönüşmesini sağlar. Plan uygulanırken değişebilir; değişimin gerekçesi kaydedilmelidir.

Bütçeyi iş planıyla aynı mantıkta hazırlayın

Bütçedeki her kalemin hangi faaliyete hizmet ettiğini göstermek yararlıdır. Yazılım, dış hizmet, ekipman veya saha gideri, belirli bir iş paketine bağlanmalıdır. Böylece yalnızca toplam para ihtiyacını değil, kaynağın hangi sonucu üretmek için kullanılacağını anlatırsınız. Bir kalem çok büyük görünüyorsa neden gerekli olduğunu açıklayın. Gereksiz görünen giderler, dosyanın diğer bölümlerinin güvenilirliğini de etkileyebilir.

Tahmin ile alınmış teklif arasındaki farkı belirtin. Henüz fiyat araştırması yapılmamış bir gideri kesin maliyet gibi sunmayın. Personel zamanı veya kurucu emeği gibi unsurların plan üzerindeki etkisini de düşünün. Bütün işlerin mevcut ekibin boş zamanında yapılacağını varsaymak takvimi gerçekçi olmaktan uzaklaştırabilir. Bütçe, yalnızca para tablosu değil kaynak kullanımının açıklamasıdır.

Teşvik planı varsa ilgili programın güncel koşullarını ayrıca kontrol edin. Bir giderin proje için gerekli olması, otomatik olarak desteklenebilir olduğu anlamına gelmez. Teknoloji şirketleri teşvik rehberi genel çerçeveyi anlamanıza yardımcı olabilir. Başvuru bütçesinde onaylanmamış desteği kesin kaynak olarak göstermemek, değerlendiren kişinin finansman riskini doğru anlamasını sağlar.

Merkezden beklediğiniz katkıyı önceliklendirin

TEKMER'e başvururken merkezden istediğiniz katkıyı üç ana başlıkla sınırlamak başlangıç için yararlı olabilir. Bu bir resmî kural değil, anlatımı netleştiren bir yöntemdir. Örneğin müşteri görüşmesine hazırlık, belirli teknik mentörlük ve düzenli ekip çalışma alanı isteyebilirsiniz. Her ihtiyacın neden önemli olduğunu ve hangi dönemde ortaya çıkacağını belirtin. Böylece talep listesi genel temennilerden oluşmaz.

İhtiyaçların hepsini merkezin karşılamasını beklemeyin. Bazı çalışmalar girişimin kendi ekibi, dış uzmanı veya farklı bir kurumla yürütülebilir. Başvuru görüşmesinde bu iş bölümünü konuşmak yararlıdır. Merkezin sunduğu hizmetlerle sizin beklediğiniz katkı arasında fark varsa bunu erken fark etmek her iki tarafın zamanını korur. Uygunluk değerlendirmesi yalnızca merkezin sizi seçmesi değil, sizin de çalışma modelini anlamanızdır.

Genel yapı için TEKMER nedir? yazısını inceleyebilirsiniz. Ankara'da Orion TEKMER'e başvurmak isteyen ekipler ön başvuru alanından proje özetini paylaşabilir. Formu göndermeden önce iletişim bilgilerini, bağlantıları ve ek dosyaları kontrol edin. Başvuru yapılması otomatik kabul veya finansman garantisi oluşturmaz; sonraki görüşmenin hazırlığını başlatır.

Son okumayı bir değerlendirme provası gibi yapın

Dosyanın son sürümünü projeyi tanımayan bir kişiye okutun. Beş dakika sonunda probleminizi, çözümünüzü ve ne istediğinizi kendi kelimeleriyle anlatmasını isteyin. Yanlış anlaşılan bölüm varsa yalnızca daha fazla ayrıntı eklemek yerine cümlelerin yapısını sadeleştirin. Teknik doğruluk ile açıklık birlikte sağlanmalıdır. Okuyanın her ayrıntıyı ezberlemesi değil, projenin mantığını doğru kavraması hedeflenir.

Kurucu ekip kısa bir görüşme provası yapabilir. Bir kişi neden şimdi, diğeri müşteri kim, üçüncüsü hangi kanıt var sorularını sorsun. Cevaplar dosyadaki bilgilerle uyumlu olmalıdır. Prova sırasında yeni bir iddia ortaya çıkıyorsa bunun dayanağını kontrol edin. Başvuruyu son anda daha etkileyici göstermek için eklenen doğrulanmamış ifadeler sonraki görüşmeyi zorlaştırabilir. Tutarlılık, süslü anlatımdan daha değerlidir.

Dosyalara açık isim ve sürüm tarihi verin. Eski sunumla yeni bütçenin birlikte gönderilmesini önlemek için tek bir gönderim klasörü oluşturabilirsiniz. Bağlantıların açıldığını ve demo erişiminin çalıştığını kontrol edin. Başvurudan sonra yeni gelişme olursa önceki bilgiyi sessizce değiştirmek yerine güncellemenin ne olduğunu açıklayın. Böyle bir takip düzeni, değerlendirme sürecinde güvenilir ve çalışması kolay bir ekip izlenimi oluşturur.

Gönderim öncesinde dosyadaki sayıları ayrıca kontrol edin. Ekip büyüklüğü, müşteri görüşmesi adedi, bütçe toplamı ve takvim tarihleri farklı bölümlerde aynı anlamla kullanılmalıdır. Bir bölümde pilot, başka bir bölümde satış olarak geçen ilişki varsa düzeltin. Sayısal tutarlılık yalnızca hesap hatasını önlemek için değil, projenin mevcut durumunu doğru anlatmak için önemlidir.

Başvuruya eklenen bağlantıların izinlerini de gözden geçirin. Değerlendiren kişinin erişemediği bir demo veya yalnızca kurucu hesabında açılan belge, dosyanın incelenmesini zorlaştırabilir. Paylaşımı gerektiği kapsamda ayarlayın; gereksiz geniş erişim vermek yerine istenen içeriğin doğru kişi tarafından görülebildiğinden emin olun. Bağlantının çalışması ile içeriğin güncel olması farklı kontrollerdir, ikisini de yapın.

Gönderimden sonra dosyanın bir kopyasını ve gönderildiği tarihi saklayın. Görüşmeye çağrıldığınızda hangi sürümün değerlendirildiğini bilmek, açıklamalarınızı aynı bilgi seti üzerinden kurmanızı sağlar. Arada ürün veya ekip değişikliği olduysa bunu kısa bir güncelleme notuyla anlatın. Yeni bilgiyi eski sonuçların içine karıştırmadan sunmak, değerlendirme sürecinde karşılıklı anlaşılmayı ve sağlıklı geri bildirim almayı kolaylaştırır.

Başvuru takibini tek kişinin sorumluluğuna vermek de yararlıdır. Gelen soruların zamanında cevaplanması ve ekibin aynı bilgiyi paylaşması, değerlendirme sürecinin daha düzenli ilerlemesini sağlar.

Sık sorulan sorular

TEKMER başvuru dosyası kaç sayfa olmalı?

Önce ilgili merkezin istediği biçim ve sınırlar öğrenilmelidir. Genel olarak dosyanın görevi, temel soruları gereksiz tekrar olmadan cevaplamaktır. Uzunluk tek başına kalite göstergesi değildir. Kısa ana anlatım ve gerektiğinde incelenebilecek ekler, karmaşık projelerde okumayı kolaylaştırabilir.

Henüz müşterim yoksa başvuru hazırlayabilir miyim?

İlgili programın uygunluk koşulları ayrıca değerlendirilmelidir. Dosya hazırlığı açısından müşteriniz olmadığını açıkça belirtin ve problemi nasıl araştırdığınızı anlatın. Planlanan görüşmeleri gerçekleşmiş satış gibi göstermeyin. Bir sonraki doğrulama adımınızı ve bu adımda hangi desteğe ihtiyaç duyduğunuzu açıklayın.

Demo çalışmıyorsa dosyayı göndermemeli miyim?

Başvuru takvimi ve istenen kanıt türü önemlidir. Çalışmayan bir demoyu hazır ürün gibi sunmak yerine mevcut aşamayı açıklayın. Ekran taslağı, teknik deneme veya ürün akışı farklı kanıtlar olabilir; bunları doğru adlandırın. Merkezin hangi bilgiyle değerlendirme yapabildiğini doğrudan sorun.

Başvuru reddedilirse aynı dosya tekrar gönderilir mi?

Önce yeniden başvuru koşullarını ve paylaşılabiliyorsa değerlendirme geri bildirimini öğrenin. Dosyayı yalnızca biçimsel olarak değiştirmek yerine eksik kanıtı, uyumsuzluğu veya plan sorununu anlamaya çalışın. Yeni başvuruda neyin değiştiğini açıkça gösterin. Her kurumun yeniden değerlendirme yöntemi aynı olmayabilir.