Siparişe Dayalı Ar-Ge Projesinde Müşteri Değişiklikleri Nasıl Kaydedilir?

Müşteri için geliştirilen bir prototipin testleri sürerken yeni bir özellik istenebilir. İlk bakışta küçük görünen talep, sensörün değişmesini, yazılımın yeniden geliştirilmesini ve ek doğrulama testlerini gerektirebilir. Proje ekibi değişikliği hemen uygulayıp kayıtları sonra tamamladığında ilk hedef, yeni iş ve ek maliyet arasındaki ilişki kaybolur.

TÜBİTAK 1707 sipariş Ar-Ge araştırması yapan işletmeler için müşteri ihtiyacını ve geliştirme işini yazılı tanımlamak bu nedenle önemlidir. Bu rehberdeki kayıt düzeni şirket içi uygulama önerisidir. Resmî proje değişikliği, gider kabulü ve bildirim işlemleri ilgili çağrı metni, destek kararı ve uygulama kurallarından kontrol edilmelidir.

İlk hedefi ölçülebilir bir kabul planına bağlayın

Projenin başındaki “üretim verimliliğini artıran sistem” açıklaması tek başına test planı oluşturmaz. Hangi koşulda neyin ölçüleceği, başlangıç durumunun nasıl kaydedileceği ve sonuç değerlendirmesini kimin yapacağı tanımlanmalıdır. Hedeflenen performansın hangi deney veya saha uygulamasıyla sınanacağı baştan yazılırsa sonraki talep daha kolay değerlendirilir.

TÜBİTAK'ın 1707 program sayfasında tedarikçi kuruluşun Ar-Ge çalışmalarını yürütmesi, müşteri kuruluşun ise projenin hedefe uygun ilerlemesini izlemesi açıklanır. Bu roller şirket içindeki teknik ve ticari sorumlulara kadar somutlaştırılabilir. Hibe Raporu ile hazırlık görüşmesinde yalnız kurum isimlerini değil, test verisini üretecek ve değerlendirecek ekipleri de belirtin.

Değişiklik talebini uygulanabilir bir iş tanımına dönüştürün

Müşterinin e-postasındaki yeni özelliği doğrudan görev listesine eklemek yerine önce neden istendiğini açıklayın. Talep mevcut hedefin daha iyi tarif edilmesi mi, yeni bir kullanım senaryosu mu, yoksa ticari ürünün ek bir sürümü mü? Geliştirme ekibinin tahmini, müşteri beklentisiyle aynı belge üzerinde görülebilmelidir.

İç değişiklik kaydında talep tarihi, gerekçe, etkilenen iş paketi, süre tahmini, ek kaynak ve beklenen test çıktısı yer alabilir. Bunlar resmî form yerine önerilen çalışma alanlarıdır. İlgili programa yapılacak bildirimin kapsamı ve zamanı ayrıca belirlenir. Şirketin kendi toplantısında “kabul edildi” yazması kurumun değişikliği kabul ettiği anlamına gelmez.

Teknik belirsizlik ile ek üretim talebini ayırın

Bir prototipin hedef sıcaklıkta çalışmaması yeni deneyler gerektirebilir. Buna karşılık aynı tasarımın daha fazla sayıda üretilmesi farklı bir iş yükü doğurur. Her ek maliyetin Ar-Ge niteliği taşıdığını varsaymadan problemin nedenini açıklayın. Seri üretim hazırlığı, müşteri teslimi ve araştırma çalışmasının çıktıları ayrı izlenmelidir.

Varsayımsal bir projede sensör ölçümünün titreşim altında bozulduğu görülsün. Ek deneme hangi varsayımı sınayacak, başarısız olursa hangi alternatif değerlendirilecek ve mevcut tasarımın hangi kısmı değişecek? Bu soruların cevapları teknik kayıt oluşturur. “Müşteri istediği için değiştirildi” ifadesi ise deneyin içeriğini tek başına açıklamaz.

Değişiklik kararında süre ve maliyeti birlikte gösterin

Bir ek özelliğin yalnızca satın alınacak parça bedelini hesaplamak eksik sonuç verebilir. Mühendislik zamanı, test düzeneğinin kullanımı, dış hizmet, yeniden numune üretimi ve saha ziyaretinin etkisi de değerlendirilmelidir. Önerilen bütçeyle gerçekleşen harcamayı birbirine karıştırmadan takip edin.

Müşteri katkısının takvimini görünür tutun

TÜBİTAK 1707 sipariş Ar-Ge kapsamında müşteri ve tedarikçi arasındaki eş finansman ilişkisi, proje bütçesinin parçasıdır. Ödeme yükümlülükleri seçilen çağrı ve sözleşme üzerinden okunmalıdır. Eski bir çağrıdaki bütçe veya oranı bütün dönemlere aktarmak yerine başvuru yapılan metnin sürümünü dosyaya bağlayın.

Nakit tablosunda müşterinin planlanan ödemesi, gerçekleşen tahsilat ve kurumdan beklenen ödeme ayrı izlenebilir. Ek iş nedeniyle oluşan nakit ihtiyacı da bu takvime eklenmelidir. Projenin teknik olarak ilerlemesi, tedarikçinin bütün harcamaları önceden finanse edebildiğini göstermez. Geciken müşteri ödemesinin hangi iş paketini etkilediği yönetim toplantısında açıkça görülmelidir.

Test sonucunu ilk hedef ve değişiklik geçmişiyle birlikte teslim edin

Son raporda yalnızca çalışan prototipin fotoğrafının bulunması, geliştirme sürecini açıklamaya yetmeyebilir. Hangi testin ne sonuç verdiğini ve tasarımın hangi gerekçeyle değiştiğini ilişkilendirin. Başarısız denemelerin kaydı da teknik kararın dayanağını göstermeye yardımcı olur. Son sürüm numarasıyla test edilen sürüm uyuşmalıdır.

Ticari kullanım ve fikri haklar konusunda müşteriyle imzalanan sözleşmedeki hükümleri kontrol edin. İşbirliği yapılması, bütün kullanım haklarının kendiliğinden aynı tarafa ait olduğu sonucunu doğurmaz. Yeni bir sektör veya ülke için kullanım talebi geldiğinde teknik teslimle lisanslama sorularını birlikte değerlendirin.

Hibe Raporu ile proje türünü ve hazırlık dosyasını netleştirin

Hibe Raporu Ar-Ge programları kataloğunda TÜBİTAK 1507 başvurusu, müşteri ortaklı çalışma ve üniversite işbirliği gibi farklı yapıları araştırabilirsiniz. TÜBİTAK 1505 üniversite sanayi işbirliği arayışındaki bir işletmenin ortaklık ve çıktı yapısı ayrıca değerlendirilmelidir. Program seçimi yalnız proje adındaki teknoloji kelimesine dayanmaz.

HibeRaporu paneline şirket profilinizle birlikte müşteri ihtiyacını, teknik belirsizliği ve mevcut çalışma planını girerek devlet destekleri uygunluk analizi hazırlığı yapın. Destek başvuru dosyası hazırlama görüşmesine değişiklik geçmişini ve güncel iş paketlerini getirin. Böylece devlet destekleri raporu, ilk fikirden son test planına kadar aynı proje sürümüne dayanır.