Ar-Ge Kooperatifleri Kurulumu, İç Tüzük ve Danışma Kurulu İşleyişi

Bir teknoloji topluluğunu, araştırma ekibini veya ortak proje grubunu sürdürülebilir bir tüzel yapıya dönüştürmek isteyenlerin karşısına yalnızca kuruluş belgeleri çıkmaz. Asıl mesele ortak ekonomik amacın, proje yönetiminin, fikri mülkiyet haklarının, karar yetkilerinin ve gelir modelinin daha kuruluş aşamasında anlaşılır hale getirilmesidir. On yıllık yazılım, proje ve teknoloji organizasyonu deneyimimde, iyi fikirlerin çoğu zaman teknik yetersizlikten değil görev ve yetki sınırlarının baştan yazılmamasından dolayı yavaşladığını gördüm. Ar-Ge Kooperatifleri Kurulumu, İç Tüzük ve Danışma Kurulu İşleyişi bu nedenle yalnızca bir kuruluş prosedürü olarak değil, ortak araştırma üretiminin nasıl yönetileceğini belirleyen bütüncül bir yönetişim konusu olarak ele alınmalıdır. Bu rehberde Ar-Ge kooperatifi nasıl kurulur ve kuruluş şartları nelerdir, Ar-Ge ve teknoloji kooperatifi ana sözleşmesi nasıl hazırlanır, teknoloji kooperatiflerinde iç tüzük görev yetki ve karar alma süreçleri nasıl tasarlanır ve Ar-Ge kooperatifi danışma kurulu nasıl oluşturulur ve nasıl çalışır gibi soruları uygulamaya dönük biçimde inceleyeceğiz.

Önemli bir not da ekleyelim. Türkiye'de kooperatif kuruluşu ve işleyişi 1163 sayılı Kooperatifler Kanunu, Türk Ticaret Kanunu, ilgili ikincil mevzuat, kooperatif türüne ilişkin örnek ana sözleşmeler ve yetkili idarenin uygulamalarıyla birlikte değerlendirilmelidir. Bilimsel Araştırma ve Geliştirme Kooperatifi, Ticaret Bakanlığının Bakanlıkça kuruluş işlemleri yürütülen kooperatif türleri arasında yer almaktadır. Genel kooperatif kuruluşunda en az yedi ortak şartı bulunmaktadır ve ana sözleşme MERSİS üzerinden hazırlanarak ilgili kuruluş ve tescil süreçleri yürütülmektedir. Bu içerik yol haritası oluşturmak amacı taşır; kuruluş öncesinde somut ana sözleşme, vergi, fikri mülkiyet ve sözleşme yapısının yetkili hukuk ve mali müşavirlik uzmanlarıyla ayrıca değerlendirilmesi gerekir.

Ar-Ge Kooperatifi Nedir?

Ar-Ge kooperatifi, ortakların araştırma, teknoloji geliştirme, proje üretme, bilgi paylaşma, ortak altyapı kullanma ve ekonomik menfaatlerini birlikte geliştirme ihtiyacını kooperatif modeli içinde organize etmeyi hedefleyen bir yapıdır. Kooperatif modeli değişir ortaklı ve değişir sermayeli yapısıyla klasik sermaye şirketlerinden farklı bir ortaklık mantığı taşır. Bilimsel Araştırma ve Geliştirme Kooperatifi açısından esas değer, farklı uzmanlıkların ortak proje üretme kapasitesini hukuki ve ekonomik bir çerçeveye taşımaktır. Yazılım geliştirici, akademisyen, mühendis, girişimci ve tüzel kişiler uygun ortaklık koşulları içinde ortak hedefler etrafında buluşabilir. Ancak yapının yalnızca “proje yapalım” düşüncesiyle değil ortakların hangi ekonomik menfaatini nasıl geliştireceğini açıklayan gerçek bir iş modeliyle kurulması gerekir.

Bilimsel Araştırma ve Geliştirme Kooperatifi Nedir?

Bilimsel Araştırma ve Geliştirme Kooperatifi, araştırma ve geliştirme faaliyetlerini ortak ekonomik menfaat temelinde örgütlemek amacıyla kurulabilen kooperatif türlerinden biridir. Yapı ortak proje hazırlama, araştırma yürütme, teknoloji geliştirme, ürünleştirme, ortak altyapı kullanımı ve işbirliği modelleri için kurumsal zemin sağlayabilir. Kooperatifin hangi işleri yapabileceği yalnız isminden hareketle değil ana sözleşmesindeki amaç ve faaliyet hükümlerinden değerlendirilmelidir. Bu nedenle kuruluş aşamasında mevcut faaliyetleri olduğu kadar üç veya beş yıl içinde yürütülmesi muhtemel faaliyetleri de düşünmek önemlidir. Fazla dar yazılan faaliyet alanları ileride gereksiz ana sözleşme değişikliği ihtiyacı doğurabilirken sınırsız ve belirsiz ifadeler de yönetim ve uygulama sorunlarına neden olabilir.

Ar-Ge Kooperatifinin Temel Amacı

Ar-Ge kooperatifinin temel amacı, ortakların tek başlarına daha yüksek maliyetle gerçekleştirebileceği araştırma ve teknoloji faaliyetlerini işbirliği içinde yürütmelerini kolaylaştırmaktır. Ortak laboratuvar, yazılım altyapısı, GPU kapasitesi, test ekipmanı, proje yönetimi veya uzman danışmanlık hizmetleri paylaşılabilir. Bunun yanında ortakların geliştirdiği projelerin fikri mülkiyet, fonlama ve ticarileştirme süreçleri için kurumsal mekanizmalar oluşturulabilir. Burada kooperatifin amacı yalnız maliyet paylaşmak değil ortakların ekonomik ve mesleki kapasitesini yükselten bir araştırma ekosistemi oluşturmaktır. Bu amaç ana sözleşmede açık, iç çalışma esaslarında ise uygulanabilir prosedürlere dönüşmüş biçimde yer almalıdır.

Kimler Ar-Ge Kooperatifi Kurabilir?

Kooperatifler gerçek ve tüzel kişiler tarafından kurulabilir ve genel kuruluş kuralı olarak en az yedi kurucu gerekir. Kurucuların yalnız sayı şartını tamamlayan kişilerden seçilmesi sağlıklı değildir. Araştırma, teknoloji, finans, proje geliştirme, hukuk, fikri mülkiyet, sektör bağlantıları ve operasyon gibi birbirini tamamlayan yetkinliklerin kurucu ekipte bulunması önemli avantaj sağlar. Tüzel kişilerin ortak olduğu yapılarda temsil ve yetki belgelerinin kuruluş sürecinde doğru hazırlanması gerekir. Ortakların kooperatiften beklediği ekonomik faydanın birbirinden tamamen farklı olması ise ilerleyen dönemde ciddi yönetişim çatışmaları yaratabileceği için başlangıçta ortak amaç konusunda açık mutabakat kurulmalıdır.

Hangi Alanlarda Faaliyet Gösterebilir?

Ar-Ge kooperatifinin faaliyet alanı ana sözleşmesinde yazılı amaç ve konularla uyumlu olmalıdır. Yazılım geliştirme, bilimsel araştırma, mühendislik, prototipleme, proje hazırlama, eğitim, danışmanlık, fikri mülkiyet yönetimi, ürün geliştirme ve ulusal veya uluslararası işbirlikleri örnek faaliyet alanları olabilir. Ancak her faaliyet otomatik biçimde serbest kabul edilmemeli, özel izin veya lisans gerektiren sektörler ayrıca incelenmelidir. Sağlık, finans, enerji veya kişisel veri yoğun alanlarda proje geliştirilmesi halinde sektörel mevzuatın etkisi baştan değerlendirilmelidir. İyi faaliyet tanımı hem mevcut proje portföyünü destekler hem de kooperatifin ileride gerçekçi biçimde genişleyebileceği alanları kapsar.

Ar-Ge Kooperatifi Hangi Problemleri Çözer?

Ar-Ge kooperatifi özellikle dağınık uzmanlık, yüksek araştırma maliyeti, ortak altyapı eksikliği ve proje bazlı işbirliğinin sürdürülememesi gibi sorunlara çözüm üretmek için kullanılabilir. Küçük firmalar tek başlarına uzman araştırmacı, laboratuvar veya güçlü hesaplama altyapısı sağlayamayabilir. Kooperatif modeli bu kaynakların ortak ekonomik amaç doğrultusunda paylaşılmasına yardımcı olabilir. Aynı zamanda üniversite, sektör ve teknoloji toplulukları arasında proje geliştirme konusunda daha kurumsal bir muhatap oluşturabilir. Fakat kooperatif modeli kendi başına talep veya gelir üretmez; sorun gerçekten ortaksa ve üyeler kaynak paylaşmaya hazırsa anlamlı hale gelir.

Ar-Ge Kooperatifi ile Diğer Organizasyon Modellerinin Farkı

Ar-Ge kooperatifi seçimi yalnız hukuki yapı tercihi değildir. Şirket, dernek, vakıf, teknoloji topluluğu veya girişimcilik merkezi farklı amaçlara ve yönetişim ihtiyaçlarına cevap verir. Kooperatif modeli özellikle ortakların ekonomik menfaatini karşılıklı yardım ve dayanışma içinde geliştirme ihtiyacının güçlü olduğu durumlarda anlam kazanır. Yatırımcı odaklı sermaye büyümesi veya tek kurucunun kontrolü hedefleniyorsa başka yapılar daha uygun olabilir. Kuruluş öncesi fizibilitede ilk sorulardan biri bu nedenle “Neden kooperatif?” olmalıdır.

Ar-Ge Kooperatifi ve Limited/Anonim Şirket

Limited veya anonim şirket genellikle sermaye, pay sahipliği ve ticari büyüme ekseninde yapılandırılır. Kooperatif ise ortakların belirli ekonomik menfaatlerini dayanışma içinde geliştirme mantığını taşır ve değişir ortaklı yapısıyla farklı bir yönetişim zemini oluşturur. Bir teknoloji ürününün yatırım alarak hızlı ölçeklenmesi hedefleniyorsa sermaye şirketi modeli daha uygun olabilir. Buna karşılık çok sayıda uzman veya işletmenin ortak araştırma altyapısından yararlanması hedefleniyorsa kooperatif modeli anlamlı hale gelebilir. Karar, vergi veya kuruluş kolaylığına indirgenmemeli; sermaye ihtiyacı, karar modeli, gelir dağılımı, ortaklık yapısı ve uzun vadeli strateji birlikte değerlendirilmelidir.

Ar-Ge Kooperatifi ve Dernek

Dernek ve kooperatif arasında temel farklardan biri amaç ve ekonomik yapı tarafında görülür. Dernekler kazanç paylaşma dışında belirli ortak amaçları gerçekleştirmek üzere örgütlenirken kooperatifler ortaklarının belirli ekonomik menfaatlerini koruma ve geliştirme amacı taşır. Teknoloji topluluklarında eğitim, sosyal etkileşim ve gönüllü etkinlikler dernek modeline daha yakın olabilir. Ortakların araştırma, üretim, hizmet veya ticarileştirme faaliyetlerinden ekonomik fayda sağlaması hedefleniyorsa kooperatif yapısı ayrıca değerlendirilebilir. Bazı yapılarda topluluk veya dernek ile kooperatifin görevlerini birbirinden ayıran paralel model de tercih edilebilir.

Ar-Ge Kooperatifi ve Vakıf

Vakıf, belirli ve sürekli bir amaca özgülenen malvarlığı temelinde farklı hukuki yapıya sahiptir. Kooperatif ise ortaklık, ekonomik menfaat ve ortakların katılımı etrafında çalışır. Araştırma bursları, bilimsel destek veya uzun vadeli kamusal yarar amaçlı fon yönetimi için vakıf yaklaşımı değerlendirilebilir. Ortakların birlikte proje yürütmesi, ortak altyapı kullanması ve ekonomik faaliyet içinde yer alması durumunda kooperatif modeli daha uygun olabilir. Seçim yapılırken yalnız hukuki form değil yönetim, finansman ve ortakların karar süreçlerindeki rolü karşılaştırılmalıdır.

Ar-Ge Kooperatifi ve Teknoloji Topluluğu

Teknoloji topluluğu gönüllülük, bilgi paylaşımı, etkinlik ve networking açısından oldukça esnek çalışabilir. Ancak sözleşme imzalama, ortak varlık edinme, gelir elde etme veya uzun vadeli proje yükümlülüğü üstlenme ihtiyacı büyüdükçe tüzel yapı gereksinimi ortaya çıkabilir. Ar-Ge kooperatifi bu noktada topluluğun tamamının yerine geçmek zorunda değildir. Topluluk eğitim, açık etkinlik ve gönüllü katılım alanında devam ederken kooperatif seçilmiş ortakların ekonomik ve proje bazlı faaliyetlerini yürütebilir. Bu görev ayrımı doğru kurulursa topluluğun açıklığı korunurken ticari ve hukuki sorumluluklar daha anlaşılır hale gelir.

Ar-Ge Kooperatifi ve Girişimcilik Merkezi

Girişimcilik merkezi çoğu zaman girişimlere eğitim, ofis, mentorluk ve bağlantı sağlayan destek organizasyonu olarak çalışır. Ar-Ge kooperatifinde ise ortakların kooperatif üzerindeki ekonomik ve yönetsel ilişkisi daha doğrudan olabilir. Girişimcilik merkezi farklı şirketleri desteklerken kooperatif ortak kaynak üretimi ve ortak projeler üzerinde yoğunlaşabilir. İki model birbirini dışlamaz; kooperatif kendi içinde girişimcilik programları veya kuluçka benzeri çalışmalar tasarlayabilir. Ancak bu faaliyetlerin ana sözleşmedeki amaçla ve kooperatif ortaklarının ekonomik menfaatiyle nasıl bağlandığı açık biçimde kurulmalıdır.

Hangi Durumda Kooperatif Modeli Tercih Edilmeli?

Kooperatif modeli ortakların birlikte kaynak kullanması, proje geliştirmesi ve ekonomik fayda üretmesi gerçekten merkezi ihtiyaçsa güçlü adaydır. Kurucular yalnız yatırımcı değil aktif katılımcı olmayı planlıyorsa model daha anlamlı hale gelir. Ortak araştırma altyapısı, ortak proje ofisi veya ortak fikri mülkiyet portföyü gibi hedefler kooperatif yaklaşımını destekleyebilir. Buna karşılık tek ürün etrafında yüksek risk sermayesi yatırımı ve hızlı hisse devri planlanan girişimlerde sermaye şirketi modeli daha doğal olabilir. Fizibilite aşamasında kooperatifin seçilme nedeni bir paragrafla açıklanamıyorsa kuruluş kararını biraz daha çalışmak faydalıdır.

Teknoloji Topluluğundan Ar-Ge Kooperatifine Geçiş

Teknoloji toplulukları çoğu zaman birkaç gönüllünün etkinlik ve proje üretmesiyle başlar. Topluluk büyüdükçe para toplama, sözleşme yapma, ekipman edinme, proje geliri yönetme ve fikri mülkiyet konuları daha belirgin hale gelir. Ar-Ge kooperatifine geçiş bu ihtiyaçların kurumsal çerçeveye taşınmasını sağlayabilir. Ancak bütün topluluk üyelerini otomatik olarak kooperatif ortağı yapmak gerekli veya doğru olmayabilir. Geçiş planında gönüllü topluluk faaliyetleri ile kooperatifin ekonomik faaliyetleri açık biçimde ayrılmalıdır.

Gönüllü Topluluktan Tüzel Kişiliğe Geçiş

Gönüllü yapı hızlı karar verebilir fakat hukuki sorumluluk çoğu zaman birkaç kişinin üzerinde kalır. Tüzel kişilik sözleşme, banka hesabı, personel, proje ve malvarlığı yönetimini kurumsallaştırır. Buna karşılık muhasebe, genel kurul, yönetim, kayıt ve mevzuat yükümlülükleri getirir. Bu nedenle geçiş yalnız büyümenin doğal sonucu olarak değil gerçek operasyon ihtiyacına cevap olarak planlanmalıdır. Kurucular yeni yapının getireceği sorumlulukları ve düzenli idari maliyeti kabul etmeye hazır olmalıdır.

Topluluk Faaliyetleri ile Ticari Faaliyetlerin Ayrılması

Topluluğun ücretsiz etkinlikleri, açık eğitimleri ve gönüllü projeleri kooperatifin ücretli danışmanlık veya ürün geliştirme faaliyetleriyle karıştırılmamalıdır. Hangi markanın hangi etkinliği yürüttüğü ve gelir veya giderin hangi yapıya ait olduğu anlaşılır olmalıdır. Bu ayrım hem üyelerin beklentisini hem mali süreçleri kolaylaştırır. Açık kaynak topluluk projesinin kooperatif tarafından ticarileştirilmesi planlanıyorsa hak sahipliği ve lisans koşulları önceden belirlenmelidir. Şeffaf görev ayrımı topluluk güvenini korumak için temel unsurdur.

Kurucu Çekirdek Ekibin Belirlenmesi

Kurucu çekirdek ekip yalnız en aktif topluluk üyelerinden oluşmak zorunda değildir. Kooperatifin iş modeline göre hukuk, finans, ürün, sektör, yazılım ve araştırma deneyimi önem kazanabilir. Kurucu olmak yönetim kurulunda sürekli görev almak anlamına da gelmemelidir. Roller ve beklentiler kuruluş öncesi yazılı biçimde konuşulmalıdır. Bu çalışma ileride “Ben farklı bir yapı bekliyordum” türündeki anlaşmazlıkları önemli ölçüde azaltır.

Ortak Ekonomik Menfaatin Tanımlanması

Kooperatif fikrinin merkezinde ortakların ekonomik menfaatinin açık biçimde tanımlanması gerekir. Ortaklar daha düşük maliyetli altyapıya mı ulaşacak, daha büyük proje konsorsiyumlarına mı katılacak, ortak satış mı yapacak, yoksa Ar-Ge kapasitesini mi paylaşacak soruları cevaplanmalıdır. Birden fazla fayda olabilir ancak öncelik sırası belirlenmelidir. Ortak ekonomik menfaat ana sözleşmenin amaç hükümlerine ve yıllık iş planına yansıtılmalıdır. Belirsiz amaç zaman içinde her üyenin kooperatifi başka yöne çekmesine neden olabilir.

Mevcut Topluluk Markası ve Varlıklarının Durumu

Topluluğun daha önce kullandığı marka, alan adı, sosyal medya hesabı, logo, Git deposu ve ekipman varsa bunların hukuki sahipliği incelenmelidir. Bir kişinin adına kayıtlı alan adının otomatik olarak kooperatife ait olduğu varsayılamaz. Devir, kullanım lisansı veya ortak kullanım modeli açık biçimde yazılabilir. Gönüllülerin geliştirdiği yazılımlar için copyright ve açık kaynak lisansları ayrıca kontrol edilmelidir. Yeni tüzel yapı kurulmadan önce mevcut varlık envanteri hazırlamak ileride yaşanabilecek hak tartışmalarını önemli ölçüde azaltır.

Ar-Ge Kooperatifi Kurmadan Önce Fizibilite

Kuruluş belgesini hazırlamak, iş modelini doğrulamaktan daha kolaydır. Bu nedenle kooperatif kurulmadan önce ekonomik, teknik ve yönetsel fizibilite çalışması yapılmalıdır. Potansiyel ortakların gerçekten ortak kaynak kullanıp kullanmayacağı, ilk projelerin nereden geleceği ve ilk yılın sabit giderlerinin nasıl karşılanacağı hesaplanmalıdır. Ayrıca gelir gecikmesi, proje başarısızlığı ve ortakların beklenenden düşük katkı sağlaması gibi riskler düşünülmelidir. İyi fizibilite kuruluşu geciktirmez; yanlış yapıyı kurup daha sonra düzeltmek için harcanacak zamanı azaltır.

Hangi Problemi Çözüyoruz?

Kooperatifin çözmek istediği problem bir veya iki cümlede açıklanabilmelidir. Örneğin bölgedeki küçük teknoloji şirketlerinin tek başına erişemediği uzmanlık ve Ar-Ge altyapısını ortak kullanması hedeflenebilir. “Teknoloji geliştirmek istiyoruz” tek başına yeterli problem tanımı değildir. Sorunun kim tarafından, ne sıklıkla ve hangi maliyetle yaşandığı araştırılmalıdır. Problem gerçek değilse hukuki yapı kurulsa bile sürdürülebilir proje akışı oluşmaz.

Ortakların Gerçek Bir Ar-Ge İhtiyacı Var mı?

Potansiyel ortaklarla yalnız fikir seviyesinde değil somut ihtiyaç üzerinden görüşmek gerekir. Hangi laboratuvar, yazılım, uzman veya fonlama kabiliyetine ihtiyaç duydukları sorulabilir. Ortakların mevcut durumda bu ihtiyacı nasıl karşıladığı da önemlidir. Hiçbir ortağın kaynak ayırmaya hazır olmadığı ihtiyaçlar kooperatif için zayıf talep sinyalidir. İlk üyelerin birkaç somut proje veya ortak yatırım niyeti göstermesi fizibiliteyi güçlendirir.

Ortak Kaynak Kullanımı Ekonomik mi?

Ortak kaynak mantığı kooperatif modelinin güçlü faydalarından biri olabilir. GPU sunucusu, test cihazı veya uzman danışman tek bir ortak için pahalıyken ortak kullanım ekonomik olabilir. Ancak kullanım yoğunluğu çok düşükse satın alma yerine kiralama daha doğru seçenek olabilir. Kaynak başına toplam sahip olma maliyeti, bakım ve işletme giderleri hesaplanmalıdır. Yatırım kararları prestij değil kullanım ihtiyacı üzerinden verilmelidir.

Potansiyel Proje Portföyü

Kuruluş öncesinde en az birkaç gerçekçi proje fikri tanımlamak faydalıdır. Projelerin teknik konusu, potansiyel müşterisi, fon kaynağı ve ekip ihtiyacı kısaca yazılabilir. Aynı kurucu grubun tamamen farklı alanlarda onlarca fikir önermesi odak problemi gösterebilir. İlk yıl için iki veya üç odak araştırma alanı seçmek uygulamayı kolaylaştırır. Portföy zamanla yeni ortaklar ve piyasa ihtiyaçları doğrultusunda genişletilebilir.

İlk 12 Aylık İş Planı

İlk on iki ay için kuruluş, proje kazanımı, altyapı, ortak sayısı ve gelir hedefleri gerçekçi biçimde yazılmalıdır. Her ay kesin gelir tahmini yapmak mümkün olmayabilir fakat kritik kilometre taşları belirlenebilir. Örneğin ilk çeyrekte kuruluş ve iki pilot proje, ikinci çeyrekte fon başvurusu ve ortak altyapı kurulumu hedeflenebilir. İş planı yönetim kurulunun yıllık önceliklerini destekler. Düzenli gözden geçirildiğinde stratejik dağılmanın önüne geçmeye yardımcı olur.

Gelir ve Gider Tahmini

Gelir tahmininde proje gelirleri, hizmet, eğitim, danışmanlık, lisans veya ortak katkıları ayrı kalemlerde değerlendirilmelidir. Gider tarafında personel, muhasebe, hukuk, ofis, altyapı, yazılım lisansı ve proje maliyetleri bulunabilir. Fon veya hibe henüz kesinleşmeden garanti gelir gibi bütçeye yazılmamalıdır. Nakit akışı özellikle proje ödemelerinin gecikmesi ihtimaline göre test edilmelidir. İlk yıl için muhafazakâr senaryo hazırlamak yönetim kuruluna daha gerçekçi karar alanı sağlar.

Risk Analizi

Risk analizi yalnız teknik başarısızlığı değil ortak, finans, mevzuat, fikri mülkiyet ve itibar risklerini de kapsamalıdır. Tek müşteriye bağımlılık yüksek finansal risk oluşturabilir. Tek teknik lidere bağımlılık ise operasyonel risk yaratır. Her önemli risk için olasılık, etki ve azaltma aksiyonu yazılabilir. Yönetim kurulu risk listesini belirli dönemlerde güncelleyerek stratejik kararlarında kullanmalıdır.

Ar-Ge Kooperatifi Kaç Kişiyle Kurulur?

Türkiye'deki genel kooperatif kuruluş kuralına göre bir kooperatif en az yedi ortak tarafından imzalanacak ana sözleşmeyle kurulur. Bu nedenle kuruluş kontrol listesinde “en az yedi kurucu hazır mı?” sorusu kritik bir başlangıç maddesidir. Ancak yedi kişinin imza vermesi işleyen kooperatif için yeterli değildir. Kurucu ortakların ortak ekonomik amaç, finansal katkı ve çalışma beklentileri konusunda uyum göstermesi gerekir. Yasal asgari sayı ile sağlıklı kurucu ekip büyüklüğünü birbirinden ayırmak önemlidir.

Kurucu Ortakların Belirlenmesi

Kurucu seçiminde yalnız kişisel yakınlık değil kooperatifin ihtiyacı olan yetkinlik ve sorumluluk kapasitesi dikkate alınmalıdır. Her kurucunun kooperatife neden katıldığı açıkça konuşulmalıdır. Yönetim, araştırma, satış, fonlama ve operasyon gibi alanlarda katkı beklentileri yazılabilir. Kurucu ortaklık uzun vadeli hukuki ve ekonomik ilişki doğurduğu için yalnız “sayıyı tamamlamak” amacıyla kişi eklenmemelidir. İyi kurucu ekip kooperatifin ilk proje ve yönetişim kültürünü belirler.

Gerçek Kişi Ortaklar

Gerçek kişiler kooperatife ana sözleşme ve mevzuat koşulları çerçevesinde ortak olabilir. Yazılım geliştirici, araştırmacı, girişimci veya başka mesleklerden kişiler kooperatif amacına uygun katkı sunabilir. Ortaklık yalnız teknik üretim anlamına gelmez; iş geliştirme ve fikri mülkiyet gibi alanlar da değer taşır. Ortak kabul kriterlerinin herkese eşit ve nesnel uygulanması önemlidir. Ortaklık ile proje çalışanlığı veya danışmanlık statüsünün birbirinden ayrılması da gereklidir.

Tüzel Kişi Ortaklar

Tüzel kişiler de kooperatif ortaklığı bakımından değerlendirilebilir ve kuruluşta temsil belgeleri önem kazanır. Yazılım şirketi, başka bir uygun tüzel yapı veya sektörel kurum kooperatifin ortak ekonomik amacına katkı sağlayabilir. Tüzel kişinin kooperatif içindeki temsilcisinin kim olacağı ve yetkisinin kapsamı açık olmalıdır. Şirket ortağının kendi ticari çıkarı ile kooperatif projesi çatıştığında çıkar çatışması prosedürü uygulanmalıdır. Özellikle proje ve fikri mülkiyet anlaşmalarında tüzel kişinin mevcut IP'si açıkça tanımlanmalıdır.

Kurucu Ortaklarda Aranacak Yetkinlikler

Ar-Ge kooperatifi için yalnız teknik beceri yeterli değildir. Araştırma, ürün, proje, hukuk, mali yönetim, sektör bağlantısı ve satış gibi yetkinliklerin dengeli bulunması faydalıdır. Her kurucunun tüm alanlarda uzman olması beklenmez. Önemli olan ekip olarak gerekli fonksiyonların karşılanabilmesidir. Eksik kalan alanlar dış danışman veya profesyonel çalışanlarla desteklenebilir.

Multidisipliner Kurucu Ekip Neden Önemlidir?

Ar-Ge projeleri teknik başarı kadar finansman, ürün ve ticarileştirme bilgisi gerektirir. Yalnız yazılım geliştiricilerden oluşan ekip güçlü teknoloji geliştirebilir fakat satış ve sözleşme tarafında zorlanabilir. Yalnız iş geliştirme odaklı yapı ise araştırma niteliğini zayıflatabilir. Multidisipliner ekip farklı riskleri kuruluş öncesinde fark etmeyi kolaylaştırır. Danışma kurulunun yapısı da kurucu ekipte eksik kalan uzmanlıkları tamamlayacak şekilde tasarlanabilir.

Ar-Ge Kooperatifi Kuruluş Süreci

Kuruluş süreci kooperatif türünün belirlenmesiyle başlar ve ana sözleşme, MERSİS, kuruluş izni, ticaret sicili ve tescil işlemleriyle devam eder. Bilimsel Araştırma ve Geliştirme Kooperatifi için Ticaret Bakanlığının güncel kuruluş belgeleri ve başvuru prosedürü dikkate alınmalıdır. Ana sözleşme MERSİS üzerinden hazırlanır ve ilgili Ticaret Sicili Müdürlüğü işlemleri yürütülür. Örnek ana sözleşmede yapılacak değişiklikler kuruluş izninin değerlendirilme yöntemini etkileyebilir. Başvurudan önce güncel belge listesi doğrudan Ticaret Bakanlığı ve ilgili Ticaret Sicili Müdürlüğünden kontrol edilmelidir.

Kooperatif Türünün Belirlenmesi

İlk adım gerçekten Bilimsel Araştırma ve Geliştirme Kooperatifi modelinin hedef faaliyetlerle uyumlu olduğunu doğrulamaktır. Kooperatifin adı ile gerçek iş modeli arasında bağ bulunmalıdır. Başka kooperatif türünün faaliyet mantığı daha uygun olabilir. Tür seçimi kuruluş izin merciini, örnek ana sözleşmeyi ve bazı uygulama ayrıntılarını etkileyebilir. Bu nedenle tür kararı kuruluş dosyasından önce verilmelidir.

Kurucu Ortakların Kesinleştirilmesi

Kurucuların kimlik veya tüzel kişilik belgeleri kadar sermaye ve ortaklık taahhütleri de netleştirilmelidir. Son anda kurucu değiştirmek başvuru belgelerinin yeniden hazırlanmasına yol açabilir. Her kurucu ana sözleşmeyi okuyarak hak ve sorumluluklarını anlamalıdır. Yönetim kurulu için düşünülen kişiler de gerekli şartlar açısından ayrıca değerlendirilmelidir. Kurucu listesi kesinleşmeden MERSİS işlemlerine başlamak gereksiz tekrar oluşturabilir.

Ana Sözleşmenin Hazırlanması

Ana sözleşme kooperatifin temel hukuki çerçevesidir. Unvan, merkez, amaç, sermaye, ortaklık, organlar ve diğer zorunlu konular mevzuata uygun biçimde yer almalıdır. Ticaret Bakanlığının MERSİS'te bulunan örnek ana sözleşmesinden yararlanılabilir. Ancak kooperatifin gerçek iş modeline göre değişiklik ihtiyacı varsa bunun kuruluş izin sürecine etkisi değerlendirilmelidir. Fikri mülkiyet veya danışma kurulu gibi operasyonel ayrıntıların tamamını ana sözleşmeye doldurmak yerine hangi konunun iç düzenlemeye bırakılacağı bilinçli seçilmelidir.

MERSİS İşlemleri

Ana sözleşme MERSİS üzerinden hazırlanır ve sistemden başvuru numarası alınır. Kurucuların bilgilerinin doğru girilmesi sonraki sicil işlemlerinin sorunsuz ilerlemesi açısından önemlidir. Unvan ve merkez bilgileri önceden kontrol edilmelidir. Ana sözleşmenin seçilen örnek metin ve varsa değişikliklerle uyumu dikkatle gözden geçirilmelidir. Güncel MERSİS ekranları ve işlem adımları zamanla değişebileceği için kuruluş tarihinde resmi yönlendirme esas alınmalıdır.

Ticaret Sicili İşlemleri

MERSİS işlemlerinin ardından ilgili Ticaret Sicili Müdürlüğündeki imza, belge ve tescil aşamaları yürütülür. Ana sözleşmedeki imzaların yetkilendirilmiş personel huzurunda atılmasına ilişkin güncel kurallar dikkate alınmalıdır. Sicil müdürlüğünün talep ettiği ek belgeler kuruluş türüne ve kurucuların niteliğine göre farklılaşabilir. Başvuru öncesi kontrol listesi almak süreci hızlandırır. Eksik belgeyle gidip tekrar randevu almak yerine dosyanın önceden kontrol edilmesi pratik açıdan büyük zaman kazandırır.

Kuruluş İzin Başvurusu

Bilimsel Araştırma ve Geliştirme Kooperatifi Ticaret Bakanlığının Bakanlıkça kuruluş işlemi yürütülen kooperatif türleri arasındadır. Kuruluş izin başvurusunda Bakanlığın güncel sayfasında belirtilen dilekçe, kuruluş bilgi formu ve ana sözleşme gibi belgeler hazırlanmalıdır. Örnek ana sözleşmede değişiklik yapılmışsa inceleme kapsamı farklılaşabilir. Başvuru evrakında faaliyet konusu ve amaç ifadelerinin birbiriyle uyumlu olması önemlidir. Kuruluş tarihinde Bakanlığın güncel belge listesi esas alınmalıdır.

Gerekli Belgelerin Hazırlanması

Belge listesi kurucu ortakların gerçek veya tüzel kişi olmasına göre ek evraklar içerebilir. Yetki belgeleri, ana sözleşme nüshaları ve başvuru formlarının güncel formatta hazırlanması gerekir. Belgelerde unvan veya adres farklılığı gibi küçük uyumsuzluklar süreci geciktirebilir. Dosya tesliminden önce tek bir kişi tarafından çapraz kontrol yapılması faydalıdır. Elektronik ve fiziksel kopyaların düzenli arşivlenmesi kuruluş sonrası işlemleri de kolaylaştırır.

Tescil ve Tüzel Kişiliğin Kazanılması

Kuruluş izni sonrasında kooperatifin ticaret siciline tescili ve ilgili ilan işlemleri tamamlanır. Tüzel kişiliğin kazanılmasının ardından kooperatif artık kendi adına hak ve yükümlülük sahibi olabilir. Ancak bu aşama operasyonun hemen başlayabileceği anlamına gelmez. Vergi, banka, muhasebe, elektronik sistemler ve gerekli diğer kayıtlar tamamlanmalıdır. Yönetim kurulu da ilk organizasyon ve yetki kararlarını usulüne uygun biçimde almalıdır.

Kuruluş Sonrası İlk İşlemler

Kuruluş sonrasında yasal defterler, muhasebe düzeni, banka hesabı, yetki ve imza süreçleri planlanmalıdır. Yönetim kurulu yıllık iş planı, bütçe ve ilk proje portföyünü değerlendirmelidir. KOOPBİS ve diğer güncel kooperatif yükümlülükleri ayrıca takip edilmelidir. İç çalışma esasları, çıkar çatışması, IP ve proje kabul prosedürleri mümkünse ilk büyük proje başlamadan yürürlüğe alınmalıdır. Kuruluş tamamlandıktan sonra yönetişim belgelerini aylarca ertelemek daha sonra proje çatışmalarını artırabilir.

Ar-Ge Kooperatifi Ana Sözleşmesinde Neler Bulunmalı?

Ana sözleşme kooperatifin hukuki kimliğini, amaçlarını, sermaye yapısını, ortaklık rejimini ve temel organlarını belirler. 1163 sayılı Kooperatifler Kanunu ana sözleşmede yer alması gereken zorunlu hükümler için temel çerçeveyi oluşturur. MERSİS'teki örnek ana sözleşme kuruluş sürecinde önemli referanstır. Ar-Ge kooperatifinde özellikle faaliyet konusu, ortaklık şartları, yönetim ve fikri mülkiyetle ilişkili genel prensiplerin iş modeliyle uyumlu olması gerekir. Bununla birlikte günlük proje değerlendirme prosedürü gibi değişmesi muhtemel ayrıntılar iç çalışma esaslarında tutulabilir.

Unvan

Kooperatif unvanı seçilen türü ve hukuki niteliği doğru yansıtmalıdır. Marka adıyla ticaret unvanı aynı olmak zorunda olmayabilir. Unvanın MERSİS ve ticaret sicili açısından uygunluğu kontrol edilmelidir. İleride kullanılacak alan adı ve marka başvuruları da mümkünse erken aşamada araştırılmalıdır. Benzer isimlerin yaratabileceği marka ve iletişim riski göz önüne alınmalıdır.

Merkez

Kooperatifin merkezi ana sözleşmede açık biçimde belirtilir. Merkez değişikliği hukuki ve sicil işlemleri doğurabileceği için adres stratejisi baştan düşünülmelidir. Ar-Ge ekiplerinin uzaktan çalışması merkezin önemini ortadan kaldırmaz. Resmi tebligat ve kayıt düzeninin sağlıklı işlemesi gerekir. Ortak çalışma alanı kullanılacaksa adresin resmi kullanım şartları kontrol edilmelidir.

Süre

Kooperatif belirli veya belirsiz süreli yapılandırılabilir ve ana sözleşme buna göre hazırlanır. Ar-Ge faaliyetleri uzun vadeli olduğu için süre kararı stratejiyle birlikte düşünülmelidir. Tek bir proje için kurulan yapı ile sürekli proje portföyü hedefleyen kooperatif aynı planlamaya sahip değildir. Süre hükmü tasfiye ve devam kararlarını da etkileyebilir. Örnek ana sözleşmedeki hüküm somut hedeflerle birlikte değerlendirilmelidir.

Amaç ve Faaliyet Konuları

Amaç ve faaliyet maddeleri kooperatifin ne için var olduğunu hukuki metne dönüştürür. Araştırma, yazılım, ürün geliştirme, eğitim, danışmanlık ve ticarileştirme gibi faaliyetler gerçek iş planıyla uyumlu biçimde yazılmalıdır. Çok dar metin büyümeyi, çok belirsiz metin ise yönetişim netliğini zayıflatabilir. Özel mevzuata tabi faaliyetler varsa ayrıca incelenmelidir. Ana sözleşmenin bu bölümü kuruluş sonrası sözleşme ve proje kararlarında sürekli referans olacaktır.

Sermaye ve Paylar

Sermaye ve ortaklık payları kooperatifin finansal başlangıç yapısını belirler. Kurucuların ne kadar sermaye taahhüt edeceği ve ödeme şartları açık olmalıdır. Ar-Ge kooperatiflerinde yalnız sermaye yetmez; düzenli proje ve işletme nakit akışı ayrıca planlanmalıdır. Emek veya fikri mülkiyet katkısının sermaye ilişkisi hukuk ve muhasebe bakımından ayrıca incelenmelidir. Proje gelir dağılımı sermaye payı kavramıyla karıştırılmamalıdır.

Ortaklık Şartları

Ortaklık şartları kooperatif amacına uygun ve mevzuatla uyumlu biçimde belirlenmelidir. Mesleki yetkinlik, faaliyet alanı veya ekonomik ilişki gibi kriterler objektif yazılabilir. Keyfî ve ayrımcı kabul uygulamalarından kaçınılmalıdır. Ortaklık kriterleri iç düzenlemeyle detaylandırılacaksa ana sözleşmeye aykırı yeni şartlar getirilemez. Her başvuruda aynı değerlendirme yöntemi kullanılmalıdır.

Ortaklığa Kabul

Yeni ortakların başvuru ve değerlendirme yöntemi baştan belirlenmelidir. Başvuruda mesleki profil, kooperatife katkı ve çıkar çatışması bilgisi alınabilir. Yönetim kurulunun karar süreci ana sözleşme ve mevzuatla uyumlu yürütülmelidir. Kabul edilmeyen başvuruların gerekçelendirilmesi yönetişim kalitesini artırabilir. Ortaklık kararları proje bazlı personel seçimiyle karıştırılmamalıdır.

Ortaklıktan Çıkma ve Çıkarma

Ortaklıktan çıkış ve çıkarma koşulları açık olmadığında en büyük sorunlar kriz dönemlerinde ortaya çıkar. Devam eden proje, kaynak kod, ticari sır ve mali hakların çıkıştan nasıl etkileneceği ayrıca sözleşmelerde düzenlenmelidir. Kooperatif ortaklığının sona ermesi daha önce imzalanmış gizlilik veya IP yükümlülüklerini otomatik olarak kaldırmayabilir. Çıkarma kararlarında mevzuat ve ana sözleşme prosedürü dikkatle uygulanmalıdır. Süreç kişisel çatışma değil kurumsal kural temelinde yürütülmelidir.

Genel Kurul

Genel kurul kooperatifin temel karar organıdır ve kanundan kaynaklanan yetkileri bulunur. Ana sözleşmede toplantı, çağrı ve karar süreçleri mevzuata uygun biçimde düzenlenmelidir. Genel kurulun devredilemez yetkileri iç tüzük veya danışma kurulu kararıyla başka organa verilemez. Yıllık faaliyet ve mali kararlar düzenli gündeme alınmalıdır. Dijital belge ve raporlama hazırlığı toplantıların daha anlaşılır yürütülmesini sağlar.

Yönetim Kurulu

Yönetim kurulu kooperatifin temsil ve idaresinden sorumlu temel organdır. Üye sayısı, görev süresi ve seçilme şartları ana sözleşme ve mevzuat çerçevesinde belirlenir. Ar-Ge kooperatifinde yönetim kurulunun proje, sözleşme, bütçe ve risk kararları için düzenli bilgi akışı kurması gerekir. Danışma kurulu görüşleri yönetim kararlarını destekleyebilir fakat yönetim kurulunun hukuki sorumluluğunu ortadan kaldırmaz. Yetki devri yapılacak alanların sınırları yönetim kurulu kararlarıyla açık tutulmalıdır.

Denetim

Kooperatifin denetim sistemi yürürlükteki mevzuat ve ana sözleşme hükümleri doğrultusunda yapılandırılmalıdır. Mali kayıt, yönetim kararları ve yasal yükümlülükler düzenli olarak kontrol edilmelidir. Proje bazlı fon kullanımı varsa proje raporlama ve dış denetim şartları ayrıca bulunabilir. İç kontrol mekanizması hukuki denetimin yerine geçmez ancak riskleri erken fark etmeye yardımcı olur. Şeffaf raporlama ortakların kooperatife güvenini doğrudan etkiler.

Hesaplar

Gelir, gider, yedek akçe ve diğer mali hükümler kooperatif mevzuatıyla uyumlu olmalıdır. Proje gelirlerinin muhasebe kayıtları ana faaliyet gelirlerinden ayrı izlenebilir. Fon veya hibe gelirlerinin kullanım şartları proje sözleşmesine göre takip edilmelidir. Ortaklara yapılan ödemelerin hukuki ve vergisel niteliği doğru belirlenmelidir. İyi proje muhasebesi yönetim kuruluna hangi çalışmanın gerçekten ekonomik değer ürettiğini gösterir.

Dağılma ve Tasfiye

Kooperatifin sona ermesi halinde yalnız para ve ekipman değil fikri mülkiyet ve araştırma verilerinin de ne olacağı önem kazanır. Ana sözleşmedeki tasfiye hükümleri mevzuata uygun olmalıdır. Açık kaynak repository, patent veya lisans geliri bulunan yapılarda tasfiye öncesi hak envanteri hazırlanmalıdır. Proje müşterilerine karşı devam eden sözleşmeler ayrıca değerlendirilmelidir. Kuruluş sırasında bu ihtimal uzak görünse bile doğru tasfiye hükmü ileride ciddi belirsizlikleri önler.

Ar-Ge Kooperatifinin Faaliyet Konuları Nasıl Yazılmalı?

Faaliyet konuları kooperatifin gerçek çalışma alanlarını kapsamalı ve amaç maddesiyle mantıksal bağ kurmalıdır. Bilimsel araştırmadan yazılım geliştirmeye, eğitimden ticarileştirmeye kadar geniş faaliyetler mümkün olabilir fakat her biri kooperatifin ortak ekonomik menfaatiyle ilişkilendirilmelidir. “Her türlü ticari faaliyet” gibi aşırı genel ifadeler iyi iş modeli yerine geçmez. Ayrıca özel izin gerektiren işlerin faaliyete eklenmesi o iznin gerekliliğini ortadan kaldırmaz. Metin kuruluş danışmanı, hukuk uzmanı ve iş modeli ekibi tarafından birlikte değerlendirilmelidir.

Bilimsel Araştırma

Bilimsel araştırma kooperatifin temel faaliyetlerinden biri olacaksa araştırma alanları ve çalışma yöntemleri makul kapsamda tanımlanabilir. Üniversite ve bağımsız araştırmacılarla ortak çalışma imkânı düşünülmelidir. Araştırma verisi, etik ve yayın politikaları iç düzenlemelerde detaylandırılabilir. Fon destekli projelerin raporlama yükümlülükleri ayrıca takip edilmelidir. Araştırma faaliyeti ticarileştirme baskısı altında bilimsel dürüstlükten ödün vermemelidir.

Yazılım ve Teknoloji Geliştirme

Yazılım geliştirme, prototipleme, platform ve teknoloji ürünleri Ar-Ge kooperatifinin önemli faaliyet alanlarından biri olabilir. Kaynak kod sahipliği ve açık kaynak kullanımı proje başlamadan belirlenmelidir. Müşteri projesi ile kooperatifin kendi ürün projesi farklı IP modeline ihtiyaç duyabilir. DevOps, test ve siber güvenlik standartları teknik politika olarak tanımlanabilir. Yazılım gelir modeli lisans, proje hizmeti veya abonelik gibi farklı yapılar üzerinden kurgulanabilir.

Proje Hazırlama

Kooperatif ortakları veya dış paydaşlar için Ar-Ge projesi hazırlama faaliyeti yürütülebilir. Proje fikrinin teknik ve ticari doğrulaması yapılmalıdır. Fon başvurusunda gerçekçi olmayan vaatlerden kaçınılmalıdır. Proje yazım hizmeti ile projenin yürütücülüğü ayrı sorumluluk alanlarıdır. Başvuru öncesi yönetim kurulu onay mekanizması oluşturmak mali ve hukuki taahhütleri kontrol altında tutar.

Danışmanlık

Ar-Ge, teknoloji, proje, dijital dönüşüm veya ürün geliştirme danışmanlığı gelir kaynağı olabilir. Danışmanlık hizmetinin kapsamı kooperatif ana sözleşmesiyle uyumlu olmalıdır. Müşteri sözleşmelerinde teslimat, sorumluluk, gizlilik ve fikri mülkiyet hükümleri açık yazılmalıdır. Ortaklardan hangisinin hizmeti sağlayacağı ve kooperatifin payı önceden belirlenmelidir. Danışmanlık gelirinin ortak Ar-Ge kapasitesini desteklemesi sürdürülebilir finansman için avantaj yaratabilir.

Eğitim

Teknik eğitim ve atölyeler hem gelir hem bilgi paylaşımı aracı olabilir. Eğitim faaliyetinin kooperatif amaçlarıyla ilişkisi açık olmalıdır. Eğitmen ücretleri ve içerik hakları önceden belirlenmelidir. Topluluk için ücretsiz eğitim ile kurumsal ücretli eğitim birbirinden ayrılabilir. Eğitim çıktılarından açık kaynak içerik oluşturulacaksa lisans politikası uygulanmalıdır.

Ürün Geliştirme

Kooperatif ortak araştırma sonuçlarını ürünleştirebilir. Ürünün sahibi, yatırım bütçesi, proje ekibi ve gelir modeli proje başlangıcında tanımlanmalıdır. Ortaklardan birinin projeden ayrılması ürün sahipliğini belirsiz hale getirmemelidir. Ürün roadmap'i teknik heyecan yerine kullanıcı ihtiyacına dayanmalıdır. Ticarileştirme kararı yönetim kurulu ve ilgili proje sözleşmeleri çerçevesinde yürütülmelidir.

Üretim

Ar-Ge sonucunda fiziksel ürün üretimi planlanıyorsa üretim faaliyeti ve gerekli izinler ayrıca değerlendirilmelidir. Prototip üretimi ile seri üretim farklı altyapı ve sorumluluk gerektirir. Kalite standardı, tedarik ve ürün sorumluluğu yönetilmelidir. Kooperatif doğrudan üretim yapabilir veya sözleşmeli üretici kullanabilir. Karar yatırım büyüklüğü ve ortakların kapasitesi üzerinden verilmelidir.

Ticarileştirme

Ar-Ge çıktısının pazara ulaşması kooperatif için ekonomik değerin oluştuğu önemli aşamadır. Lisanslama, doğrudan satış, spin-off veya müşteri projesi gibi modeller düşünülebilir. Her model farklı IP ve gelir paylaşım düzeni gerektirir. Ticarileştirme kararında proje ekibinin katkısı ve kooperatif altyapısının rolü birlikte değerlendirilmelidir. Gelir dağılım ilkelerinin proje başarıya ulaştıktan sonra değil en başta belirlenmesi daha sağlıklıdır.

Fikri ve Sınai Haklar

Patent, faydalı model, tasarım, marka ve yazılım haklarının yönetimi kooperatif faaliyetlerinin merkezinde olabilir. Her proje için background ve foreground IP ayrımı yapılmalıdır. Hak sahipliği ile gelir paylaşımı aynı kavram değildir ve ayrı düzenlenebilir. Akademik yayın hakkı da ticarileştirme planıyla dengelenmelidir. Fikri mülkiyet kararlarının uzman görüşüyle alınması ilerideki yatırım ve lisans süreçlerini kolaylaştırır.

Ulusal ve Uluslararası İşbirlikleri

Üniversite, teknokent, sanayi kuruluşu ve araştırma kurumlarıyla işbirliği proje kapasitesini büyütebilir. Uluslararası konsorsiyumlar farklı sözleşme ve IP kuralları getirebilir. Yetkili temsil ve mali taahhüt sınırları yönetim kurulunca kontrol edilmelidir. Ortaklık anlaşmaları kooperatifin kendi ana sözleşmesiyle uyumlu olmalıdır. İşbirliği sayısından çok nitelikli proje ve bilgi transferi hedeflenmelidir.

Ana Sözleşme ile İç Tüzük Arasındaki Fark

Ana sözleşme kooperatifin kuruluş ve temel yönetişim belgesidir. İç tüzük veya çalışma esasları ise ana sözleşmenin yerine geçmeden günlük operasyon, proje kabulü, danışma kurulu ve iç süreçleri daha ayrıntılı hale getirebilir. Her iç düzenleme hukuka ve ana sözleşmeye uygun olmak zorundadır. Ana sözleşmeyle kanunen genel kurula veya yönetim kuruluna verilen yetki iç düzenlemeyle danışma kuruluna devredilemez. Bu ayrım Ar-Ge ve teknoloji kooperatifi ana sözleşmesi nasıl hazırlanır sorusunun yanında teknoloji kooperatiflerinde iç tüzük görev yetki ve karar alma süreçleri konusunun da temelidir.

Ana Sözleşmenin Hukuki Rolü

Ana sözleşme kooperatifin unvanı, amacı, ortaklığı, sermayesi ve organları gibi temel konuları belirler. Tescil edilmiş hukuki belge niteliği taşır ve iç süreçlerin üst çerçevesidir. Yönetim kurulu veya iç tüzük ana sözleşmeye aykırı karar üretemez. Ana sözleşme değişiklikleri mevzuattaki prosedüre göre gerçekleştirilir. Bu nedenle sık değişecek operasyon ayrıntılarını gereksiz yere ana sözleşmeye taşımak pratik değildir.

İç Tüzük / Çalışma Esaslarının Rolü

İç tüzük proje başvurusu, danışma kurulu toplantısı, çıkar çatışması, kaynak kullanımı ve raporlama gibi günlük işleyişi standartlaştırabilir. Belgenin adı “iç tüzük”, “çalışma usul ve esasları” veya başka uygun bir iç düzenleme olabilir. Hukuki zorunluluk ve kabul usulü somut düzenlemenin niteliğine göre değerlendirilmelidir. Yönetim kurulu tarafından uygulanacak prosedürlerle genel kurul kararını gerektiren konular birbirinden ayrılmalıdır. İyi iç düzenleme üyelerin “Bu durumda ne yapacağız?” sorusuna hızlı ve tutarlı cevap verir.

Hangi Konular Ana Sözleşmede Olmalı?

Kanunen zorunlu hükümler ve kooperatifin temel yapısını belirleyen konular ana sözleşmede bulunmalıdır. Amaç, ortaklık rejimi, sermaye ve temel organlar bunun örnekleridir. Kooperatifin faaliyet alanının sınırları da ana sözleşmede tanımlanmalıdır. Danışma kurulunun kurumsal yapıda sürekli ve önemli rolü olacaksa hukuki danışmanlıkla ana sözleşmedeki yeri ayrıca değerlendirilebilir. Günlük form ve puanlama yöntemi gibi ayrıntılar ise daha esnek iç düzenlemelerde tutulabilir.

Hangi Konular İç Düzenlemeye Bırakılabilir?

Proje başvuru formu, puanlama kriterleri, danışma kurulu gündem yöntemi, repository kullanımı ve açık kaynak katkı prosedürü iç düzenlemeye bırakılabilecek örnek konulardır. Bu tür süreçler proje deneyimiyle sık değişebilir. Yönetim kurulunun hukuki yetkisini kısıtlayan veya genel kurul yetkisini devreden hükümler iç düzenlemeye konulmamalıdır. İç düzenlemenin hangi organ tarafından kabul ve güncelleneceği başlangıçta yazılmalıdır. Belge versiyon numarası ve yürürlük tarihiyle arşivlenmelidir.

İç Düzenleme Ana Sözleşmeye Aykırı Olabilir mi?

Hayır, iç düzenlemeler ana sözleşmenin ve yürürlükteki mevzuatın üstüne çıkamaz. Aykırılık halinde iç düzenlemenin ilgili hükmü uygulanabilirlik problemi yaratır. Bu nedenle iç tüzük hazırlanırken ana sözleşme maddeleriyle çapraz kontrol yapılmalıdır. Özellikle ortak kabulü, yönetim yetkisi ve mali taahhüt gibi konular risklidir. İç düzenlemeler kabul edilmeden önce hukuki inceleme yapılması faydalıdır.

İç Tüzük Nasıl Güncellenmeli?

İç tüzüğün hangi organ tarafından ve hangi çoğunlukla değiştirileceği belge içinde açık yazılmalıdır. Her değişiklik versiyon ve tarih bilgisiyle kayda alınmalıdır. Büyük yönetişim değişikliklerinde ortakların bilgilendirilmesi güveni artırır. Devam eden projelerin eski düzenleme altında kazanılmış hakları varsa geçiş hükmü gerekebilir. Yılda en az bir kez uygulama sorunları üzerinden belgenin gözden geçirilmesi faydalıdır.

Ar-Ge Kooperatifi İç Tüzüğünün Önerilen Yapısı

Ar-Ge kooperatifinin iç tüzüğü günlük işleyişi sade, öngörülebilir ve denetlenebilir hale getirmelidir. Belge ana sözleşmenin tekrarı olmamalı, uygulamada ihtiyaç duyulan süreçleri açıklamalıdır. Proje kabulü, IP, açık kaynak, çıkar çatışması ve danışma kurulu gibi Ar-Ge'ye özgü konular özellikle önemlidir. Çok uzun ve kimsenin okumadığı bir metin yerine uygulamada gerçekten kullanılan hükümler yazılmalıdır. Her önemli süreç form, kayıt ve sorumlu kişiyle desteklenirse iç tüzük yaşayan bir yönetim aracına dönüşür.

Amaç

Amaç bölümü iç düzenlemenin neden hazırlandığını açıklar. Proje yönetimi, ortak kaynak kullanımı, şeffaf karar ve danışma mekanizmaları burada özetlenebilir. Ana sözleşmenin amaç maddesi tekrarlanmak yerine iç düzenlemenin fonksiyonu belirtilmelidir. Belgenin hukuki hiyerarşide ana sözleşmeye tabi olduğu yazılabilir. Bu açıklık yorum uyuşmazlığını azaltır.

Kapsam

Kapsam hangi kişiler, organlar, projeler ve faaliyetler için kuralların geçerli olduğunu belirtir. Ortak olmayan proje çalışanlarının hangi maddelere tabi olduğu ayrıca açıklanabilir. Danışmanlar ve stajyerler için gizlilik veya veri güvenliği hükümleri uygulanabilir. Dış müşteri sözleşmesindeki hükümlerin önceliği gerektiğinde tanımlanmalıdır. Kapsam açık değilse aynı kuralın kime uygulanacağı konusunda tartışma çıkar.

Tanımlar

Proje, ortak, araştırmacı, background IP, foreground IP, danışma kurulu ve teknik komite gibi kavramlar tanımlanmalıdır. Aynı kelimenin farklı ekiplerce farklı anlamda kullanılması önlenir. Tanımlar mümkün olduğunca kısa tutulmalıdır. Kanuni kavramlarda mevzuatla çelişen yeni anlamlar oluşturulmamalıdır. Teknik terimler de gerektiğinde sözlük şeklinde eklenebilir.

Organizasyon Yapısı

Genel kurul, yönetim kurulu, operasyon ekibi, danışma kurulu ve proje ekiplerinin ilişkisi şema ile desteklenebilir. Kimin kime rapor verdiği açık olmalıdır. Danışma kurulunun karar değil görüş organı olduğu özellikle belirtilmelidir. Teknik komiteler proje değerlendirmesinde görev alabilir ancak nihai yetki ilgili hukuki organda kalmalıdır. Organizasyon şeması yeni ortakların sisteme uyumunu kolaylaştırır.

Üyelik ve Katkı Kuralları

Ortakların proje ve topluluk faaliyetlerine katkı beklentileri tanımlanabilir. Ancak ana sözleşmeye aykırı ek ortaklık şartı oluşturulmamalıdır. Emek katkısının nasıl kayıt altına alınacağı açıklanabilir. Gönüllü katkı ile ücretli proje emeği birbirinden ayrılmalıdır. Böylece katkı tartışmaları daha nesnel verilerle yürütülebilir.

Proje Başvuru Süreci

Proje fikirlerinin standart form üzerinden alınması portföy yönetimini kolaylaştırır. Problem, teknik yaklaşım, bütçe, ekip, IP ve potansiyel kullanıcı bilgileri talep edilebilir. Ön inceleme kriterleri başvuru sahibine açık olmalıdır. Çok ağır form erken fikirlerin gelmesini engelleyebilir. Aşamalı başvuru sistemi daha pratik olabilir.

Proje Değerlendirme Süreci

Teknik, ekonomik ve IP değerlendirmesi birbirinden ayrılabilir. Danışma kurulunun görüşü alınabilir fakat karar yetkisi açıkça belirtilmelidir. Değerlendirme puanı otomatik kabul anlamına gelmeyebilir. Stratejik uyum ve bütçe kapasitesi de yönetim kurulunca incelenir. Sonuç ve gerekçe başvuru sahibine kayıtlı biçimde bildirilmelidir.

Kaynak Tahsisi

GPU, laboratuvar, bütçe ve uzman zamanı gibi kıt kaynakların nasıl tahsis edileceği yazılmalıdır. Öncelik sistemi proje puanı ve sözleşme yükümlülükleriyle ilişkilendirilebilir. Tek ortağın kaynakları sürekli kullanması diğer ortaklarda adalet sorunu yaratabilir. Rezervasyon ve kullanım kotası uygulanabilir. Acil müşteri veya fon projesi için istisna prosedürü tanımlanmalıdır.

Fikri Mülkiyet

Her proje başlamadan önce hak sahipliği modeli seçilmelidir. Kooperatif mülkiyeti, ortak mülkiyet veya lisans modeli farklı ihtiyaçlara cevap verir. Background IP proje öncesi beyan edilmelidir. Foreground IP'nin kim tarafından hangi oranda kullanılacağı proje sözleşmesinde netleşmelidir. İç tüzük genel prensibi verirken somut proje sözleşmesi ayrıntıyı belirleyebilir.

Gizlilik

Gizli bilginin tanımı, erişimi ve paylaşımı belirlenmelidir. Her bilgi otomatik olarak gizli kabul edilirse günlük işbirliği zorlaşabilir. Ticari sır, kişisel veri ve henüz yayımlanmamış araştırma ayrı sınıflandırılabilir. Projeden ayrılma sonrasında devam edecek yükümlülükler sözleşmelerde açık olmalıdır. Güvenlik politikası gizlilik kurallarını teknik önlemlerle desteklemelidir.

Açık Kaynak Politikası

Hangi projelerin açık kaynak yayımlanabileceği ve kim tarafından onaylanacağı tanımlanmalıdır. Lisans seçimi teknik ekip tek başına yapmamalı, IP ve iş modeliyle birlikte değerlendirilmelidir. Üçüncü taraf dependency lisansları kontrol edilmelidir. Contributor Guide ve Code of Conduct sürdürülebilir katkıyı destekler. Açık kaynak kararı ticarileştirmeye engel olmak zorunda değildir, doğru lisans modeliyle birlikte tasarlanabilir.

Çıkar Çatışması

Ortağın veya danışma kurulu üyesinin değerlendirdiği projede kişisel ekonomik menfaati varsa beyan yükümlülüğü bulunmalıdır. Çatışmalı kişi ilgili görüşme ve değerlendirmeden çekilmelidir. Kayıtların gizlilik sınırları içinde tutulması gerekir. Tek seferlik beyan yerine proje bazlı güncelleme daha güvenlidir. İyi çıkar çatışması sistemi güveni korur ve kararların meşruiyetini güçlendirir.

Danışma Kurulu

Danışma kurulunun amacı, üye seçimi, görev süresi ve çalışma yöntemi iç düzenlemede ayrıntılı yazılabilir. Kurulun bağlayıcı karar yetkisi olmadığı açıkça belirtilmelidir. Yönetim kurulu belirli stratejik konuları görüş için danışma kuruluna gönderebilir. Kurul kendi gündem önerilerini de iletebilir. Tavsiye kararlarının yazılı kaydı kurumsal hafıza oluşturur.

Raporlama

Proje ekiplerinin hangi sıklıkta teknik ve mali rapor hazırlayacağı belirtilmelidir. Aşırı raporlama Ar-Ge zamanını tüketebilir. Kritik kilometre taşı, bütçe sapması ve riskler kısa formatta izlenebilir. Yönetim kurulu portföy görünümünü düzenli almalıdır. Danışma kuruluna yalnız karar vermesi gereken teknik özetler sunulabilir.

Etik ve Disiplin

Bilimsel dürüstlük, veri manipülasyonu, intihal, taciz ve gizlilik ihlali gibi konular için temel ilkeler belirlenmelidir. İhlal bildirim kanalı güvenli olmalıdır. Disiplin kararlarının hangi organ tarafından verileceği ana sözleşme ve mevzuatla uyumlu düzenlenmelidir. Savunma ve kayıt süreçleri adil yürütülmelidir. Etik mekanizma kişisel anlaşmazlığı cezalandırma aracına dönüşmemelidir.

Değişiklik ve Yürürlük

Belgenin hangi tarihte yürürlüğe girdiği ve hangi organ tarafından kabul edildiği belirtilmelidir. Değişiklik usulü açık olmalıdır. Yeni versiyonlar eski metinlerin üzerine kaydedilmemeli, arşivlenmelidir. Devam eden projeler için geçiş kuralı gerekebilir. Ortaklar önemli değişikliklerden haberdar edilmelidir.

Ar-Ge Kooperatifinin Organları ve Yönetişim Yapısı

Kooperatifin hukuki organları ile operasyonel veya danışma amaçlı kurullar birbirinden ayrılmalıdır. Genel kurul ve yönetim kurulu kanundan ve ana sözleşmeden kaynaklanan konuma sahiptir. Danışma kurulu ve teknik komiteler ise iç organizasyon içinde destekleyici roller üstlenebilir. Bu yapıların isimlerinin benzer olması yetkilerinin eşit olduğu anlamına gelmez. İyi yönetişim, kimin tavsiye verdiğini ve kimin hukuki karar aldığını herkes için görünür hale getirir.

Genel Kurul

Genel kurul ortakların temel irade ve karar organıdır. Kanunda ve ana sözleşmede belirlenen yetkileri kullanır. Yıllık faaliyetler, yönetim ve diğer temel konular genel kurul gündemine gelir. Proje ekipleri genel kurulun yerine geçemez. Şeffaf bilgilendirme ortakların bilinçli karar vermesini destekler.

Yönetim Kurulu

Yönetim kurulu kooperatifin temsil ve idaresini yürütür. Strateji, bütçe uygulaması, sözleşme ve proje portföyü gibi alanlarda sorumluluk taşır. Danışma kurulundan görüş alabilir fakat nihai sorumluluk kendisindedir. Yetki devri yapılırken sınır ve imza düzeni açık olmalıdır. Düzenli toplantı ve karar kaydı hukuki ve yönetsel güvenlik sağlar.

Denetim Mekanizması

Denetim mali ve yönetsel işlemlerin mevzuata uygunluğunu kontrol etmeye yardımcı olur. İç kontrol ile yasal denetim birbirinden ayrılmalıdır. Fonlu projelerin ayrıca bağımsız denetim gereksinimi olabilir. Denetim bulguları iyileştirme amacıyla yönetim kuruluna ve gerektiğinde genel kurula sunulmalıdır. Tekrar eden bulgular sistem problemi olarak ele alınmalıdır.

Operasyon Ekibi

Operasyon ekibi günlük proje, finans, iletişim ve idari işleri yürütebilir. Profesyonel çalışanlar ortak olmak zorunda değildir. Görev tanımları yönetim kurulunca belirlenmelidir. Operasyon ekibinin hukuki temsil yetkisi varsa açık yetkilendirme gerekir. Gönüllü çalışma ile ücretli profesyonel görev ayrımı net tutulmalıdır.

Proje Ekipleri

Her Ar-Ge projesi kendi proje yürütücüsü ve teknik ekibine sahip olabilir. Proje ekibi bütçe ve teslimat açısından yönetim kuruluna veya belirlenen operasyon sorumlusuna rapor verir. Fikri mülkiyet ve gizlilik sözleşmeleri ekip üyeleriyle proje başlamadan tamamlanmalıdır. Proje ekibi kooperatifin genel stratejisi dışında mali taahhüt veremez. Dış uzmanların sorumluluğu da sözleşmeyle düzenlenmelidir.

Danışma Kurulu

Danışma kurulu bilimsel, teknik, ticari veya stratejik konularda görüş sağlayan destek yapısıdır. Hukuki yönetim organı gibi hareket etmemelidir. Kurulun üyeleri kooperatif ortağı olmak zorunda olmayabilir; bu durum somut düzenleme ve sözleşmelerle netleştirilmelidir. Çıkar çatışması ve gizlilik hükümleri üyeler için önemlidir. Yönetim kuruluna düzenli fakat bağlayıcı olmayan rapor sunabilir.

Teknik Komiteler

Teknik komiteler yapay zekâ, siber güvenlik, enerji veya başka uzmanlık alanlarında proje değerlendirme yapabilir. Komitelerin görevi bilgi üretmek ve teknik görüş sunmaktır. Bütçe veya ortaklık kararı verme yetkileri ancak hukuken mümkün ve usulüne uygun biçimde tanımlanmışsa kullanılabilir. Çoğu yapıda teknik komite danışma niteliğinde kalmalıdır. Uzmanlık süreli görevlerle proje ihtiyacına göre güncellenebilir.

Genel Kurulun Rolü

Genel kurul kooperatifin ortak iradesini yansıtan temel organdır. Yasal olarak kendisine bırakılmış yetkiler başka organa devredilemez. Bu nedenle danışma kurulu veya yönetim kurulunun sınırları belirlenirken genel kurul yetkileri başlangıç noktası olmalıdır. Ar-Ge projelerinin günlük teknik kararları genel kurula taşınmamalı, stratejik ve hukuki karar seviyesi korunmalıdır. Genel kurulun etkili olabilmesi için ortaklara toplantı öncesinde yeterli bilgi sağlanması gerekir.

Genel Kurulun Temel Yetkileri

Genel kurul mevzuat ve ana sözleşmede kendisine verilen temel kararları alır. Yönetim ve denetimle ilgili seçimler, finansal konular ve ana sözleşme değişiklikleri önemli örneklerdir. Yönetim kurulu genel kurul kararlarını uygulamakla sorumludur. Proje yönetim sistemi genel kurulun yetkilerini aşındırmamalıdır. Yetki matrisi hazırlanırken hukuki danışmanlık alınması faydalıdır.

Devredilemeyecek Yetkiler

Kanunun genel kurula bıraktığı devredilemez yetkiler iç tüzükle danışma kuruluna veya başka komiteye verilemez. Bu kural özellikle danışma kurulu tasarımında önemlidir. “Danışma kurulu onayı olmadan hiçbir karar alınamaz” gibi hükümler yönetim organlarının hukuki yetkisiyle çatışabilir. Bunun yerine belirli konularda görüş alınması öngörülebilir. Nihai karar yetkisi ilgili organda kalmalıdır.

Yıllık Faaliyetlerin Değerlendirilmesi

Yıllık faaliyet raporu aktif projeleri, gelirleri, ortaklık gelişimini ve önemli riskleri özetlemelidir. Ar-Ge çıktıları yalnız proje sayısıyla değil patent, ürün, açık kaynak, istihdam ve ticarileştirme sonuçlarıyla gösterilebilir. Başarısız projeler de gizlenmeden öğrenilen derslerle raporlanmalıdır. Bu şeffaflık ortakların stratejik yönü değerlendirmesini kolaylaştırır. Rapor gereksiz teknik ayrıntı yerine karar için anlamlı bilgi sunmalıdır.

Bütçe ve Mali Kararlar

Kooperatifin mali planı yıllık stratejiyle uyumlu olmalıdır. Araştırma bütçesi, personel, altyapı ve proje finansmanı birlikte değerlendirilir. Büyük yatırım kararlarının hangi organda alınacağı ana sözleşme ve mevzuat çerçevesinde belirlenmelidir. Fon gelirlerinin kullanım koşulları ayrıca takip edilmelidir. Mali raporlama ortakların anlayabileceği formatta hazırlanmalıdır.

Ana Sözleşme Değişiklikleri

Ana sözleşme değişiklikleri mevzuattaki izin ve genel kurul prosedürlerine göre yürütülür. İç tüzük değişikliğiyle ana sözleşme fiilen değiştirilemez. Faaliyet konusu genişletilecekse hukuki süreç önceden planlanmalıdır. Değişiklik gerekçesi ortaklara anlaşılır biçimde açıklanmalıdır. Tescil ve diğer gerekli işlemler tamamlanmadan yeni hükmün uygulama durumu ayrıca kontrol edilmelidir.

Yönetim ve Denetimin Seçimi

Yönetim ve denetim görevleri için yalnız teknik popülerlik değil hukuki şartlar, sorumluluk ve yetkinlik dikkate alınmalıdır. Adayların çıkar çatışması ve zaman kapasitesi değerlendirilmelidir. Görev süresi boyunca performans ve raporlama beklentileri açık olmalıdır. Seçim sonrasında görev dağılımı ve yetki belgeleri tamamlanmalıdır. Yönetim kurulu üyeliği prestij değil hukuki sorumluluk taşıyan bir görevdir.

Yönetim Kurulunun Rolü

Yönetim kurulu kooperatifin strateji ve günlük idare arasındaki ana karar merkezidir. Ar-Ge projelerinde sözleşme, bütçe, kaynak tahsisi ve risk kararları bu kurulun sorumluluğunda önemli yer tutar. Teknik detayların tamamını yönetim kurulunun çözmesi gerekmez; uzman komitelerden ve danışma kurulundan görüş alınabilir. Ancak dış uzman görüşü yönetim kurulunun sorumluluğunu ortadan kaldırmaz. Düzenli karar kaydı ve yetki matrisi kurumsal yönetimin temelidir.

Stratejik Yönetim

Yönetim kurulu kooperatifin hangi araştırma alanlarına odaklanacağını ve hangi iş modellerini geliştireceğini belirlemelidir. Her yeni teknoloji trendinin peşinden gitmek strateji değildir. Üyelerin ekonomik ihtiyacı, bölgesel fırsatlar ve mevcut yetkinlik birlikte değerlendirilmelidir. Danışma kurulu teknolojik gelişmeler hakkında görüş verebilir. Nihai strateji yönetim kurulu ve gerektiğinde genel kurul yetkileri içinde oluşturulur.

Kooperatifin Temsil ve İdaresi

Kooperatif adına sözleşme imzalama ve üçüncü kişilerle ilişki kurma yetkisi hukuki temsil düzenine uygun olmalıdır. İmza yetkisi kimdeyse sınırlar açıkça belirlenmelidir. Proje yürütücüsü teknik görüşmede kooperatif adına mali taahhüt vermemelidir. Yetki limitleri farklı tutarlar için kademeli oluşturulabilir. Bu düzen hem hız hem kontrol sağlar.

Proje Portföyü Yönetimi

Yönetim kurulu tüm projeleri aynı anda kabul etmek yerine kapasite ve stratejik uyumu değerlendirmelidir. Teknik puanı yüksek proje finansal olarak sürdürülemez olabilir. Projelerin risk, bütçe ve insan kaynağı yükü birlikte görülmelidir. Portföy toplantıları üç aylık dönemlerde yapılabilir. Başarısız veya düşük öncelikli projeleri durdurabilmek de iyi portföy yönetiminin parçasıdır.

Bütçe Uygulaması

Onaylanmış bütçenin proje ve operasyon düzeyinde uygulanması yönetim kurulunca izlenir. Sapmalar için önceden eşik belirlenebilir. Proje ekibi belirli limit içinde harcama yapabilir, daha yüksek tutarlar yönetim onayına tabi tutulabilir. Fonlu projelerde harcama uygunluğu ayrıca kontrol edilmelidir. Nakit akışı yalnız muhasebe raporu değil yönetim karar aracıdır.

İnsan Kaynakları

Kooperatif çalışanları, proje bazlı uzmanlar ve ortakların emek katkısı farklı hukuki ilişkilerdir. İş sözleşmesi gereken durumlar gönüllü katkı gibi gösterilmemelidir. Ücret, görev ve performans kriterleri açık olmalıdır. Proje sona erdiğinde personelin devam durumu önceden planlanabilir. Araştırma kurumunda güçlü insan kaynağı yönetimi teknik başarının önemli koşuludur.

İşbirliği ve Sözleşmeler

Üniversite, şirket ve diğer kurumlarla işbirliği yapılırken amaç, bütçe, IP ve sorumluluk hükümleri dikkatle incelenmelidir. Standart sözleşme şablonları hız kazandırabilir fakat her projeye kör biçimde uygulanmamalıdır. Cross-border projelerde yabancı hukuk ve veri aktarımı sorunları çıkabilir. Danışma kurulu işbirliği fırsatı önerebilir. Sözleşme imza yetkisi yine hukuki temsil düzenine tabidir.

Risk Yönetimi

Yönetim kurulu teknik, finansal, hukuki ve itibar risklerini düzenli izlemelidir. Her proje için risk kaydı oluşturulabilir. Kritik risk gerçekleşmeden önce azaltma planı hazırlanmalıdır. Danışma kurulu özellikle bilimsel veya teknoloji riskleri konusunda görüş sağlayabilir. Risk raporu kararları geciktiren bürokrasi değil beklenmedik kayıpları azaltan araç olarak kullanılmalıdır.

Ar-Ge Kooperatifinde Danışma Kurulu Nedir?

Danışma kurulu kooperatifin bilimsel, teknik, sektörel veya stratejik konularda dış ve iç uzman görüşüne düzenli erişmesini sağlayan yardımcı yapıdır. Kooperatifler Kanunundaki temel organlarla karıştırılmamalıdır. Danışma kurulu kendi başına kooperatifi temsil eden veya kanuni yönetim yetkisini kullanan organ gibi tasarlanmamalıdır. Ar-Ge kooperatifi danışma kurulu nasıl oluşturulur ve nasıl çalışır sorusunun en önemli cevabı, görev ile yetki arasındaki bu ayrımdır. Kurulun çalışma esasları iç düzenlemeyle belirlenebilir ve verdiği tavsiyeler kayıt altına alınabilir.

Danışma Kurulu Neden Kurulur?

Yönetim kurulunun bütün bilimsel ve teknik alanlarda uzman olması beklenemez. Danışma kurulu farklı disiplinlerden bilgi getirerek proje ve strateji kararlarının kalitesini artırabilir. Üniversite, sanayi ve teknoloji ekosistemiyle bağlantı kurmaya yardımcı olabilir. Fon, IP ve ticarileştirme gibi konularda erken uyarı sağlayabilir. Ancak kurul yalnız prestijli isimlerden oluşup hiç çalışmıyorsa gerçek değer üretmez.

Danışma Kurulu Bir Yönetim Organı mıdır?

Danışma kurulu adı üzerinde danışma amacı taşıyan yardımcı yapı olarak tasarlanmalıdır. Kanuni yönetim organlarının yerine geçmez. Yönetim kurulunun temsil, bütçe ve idare yetkilerini kullanamaz. İç tüzükle danışma kuruluna bağlayıcı veto yetkisi verilmesi hukuki yetki yapısıyla çatışma yaratabilir. Görev tanımında “görüş bildirir”, “öneri sunar” ve “değerlendirir” gibi ifadeler tercih edilmelidir.

Tavsiye ile Karar Yetkisi Arasındaki Fark

Tavsiye karar organına bilgi ve uzman görüşü sunar. Nihai karar ise hukuken yetkili organ tarafından alınır ve sorumluluğu da o organ taşır. Örneğin danışma kurulu bir Ar-Ge projesinin teknik açıdan güçlü olduğunu belirtebilir. Yönetim kurulu bütçe veya strateji gerekçesiyle projeyi yine de kabul etmeyebilir. Bu fark tutanaklarda ve iç düzenlemede açık biçimde korunmalıdır.

Yönetim Kurulu ile İlişkisi

Danışma kurulu raporlarını yönetim kuruluna sunabilir. Yönetim kurulu belirli proje veya stratejik soruları kuruldan görüş için isteyebilir. Kurulun sekretaryası yönetim kurulu gündemiyle koordineli çalışabilir. Danışma görüşüne uyulmaması halinde her zaman uzun gerekçe zorunluluğu oluşturmak pratik olmayabilir, ancak önemli ayrışmalarda kısa kayıt kurumsal öğrenme sağlar. İki kurul arasında emir komuta ilişkisi yerine açık görev ayrımı bulunmalıdır.

Genel Kurulla İlişkisi

Danışma kurulu genel kurulun yetkilerini kullanamaz. Yıllık faaliyet raporuna danışma kurulu değerlendirmesi eklenebilir. Genel kurul üyeleri stratejik karar verirken kurulun görüşlerinden yararlanabilir. Danışma kurulu üyelerinin genel kurulda oy hakkı ancak ayrıca ortaklık sıfatlarından doğuyorsa söz konusu olabilir. Danışma üyeliği tek başına ortaklık veya oy hakkı oluşturmaz.

Teknik Komitelerle İlişkisi

Teknik komiteler belirli proje veya uzmanlık alanlarında daha detaylı inceleme yapabilir. Danışma kurulu ise daha geniş stratejik bakış sağlayabilir. Örneğin yapay zekâ teknik komitesi model değerlendirmesi yaparken danışma kurulu etik, ticarileştirme ve işbirliği boyutunu birlikte ele alabilir. Aynı kişilerin iki yapıda bulunması mümkün olsa da çıkar çatışması gözetilmelidir. Raporlama akışı tekrar eden toplantıları azaltacak şekilde sade tutulmalıdır.

Danışma Kurulunda Kimler Yer Almalı?

Danışma kurulu üyeleri yalnız tanınmış isimlerden seçilmemelidir. Kooperatifin proje portföyü ve stratejik ihtiyaçlarına gerçek katkı sunabilecek farklı uzmanlıkların dengesi önemlidir. Akademi, teknoloji, finans, fikri mülkiyet ve sektör bilgisi birlikte düşünülebilir. Üyelerin toplantılara zaman ayırabilecek olması prestijden daha değerlidir. Beş kişilik aktif kurul, on beş kişilik fakat toplantıya katılmayan listeden daha işlevseldir.

Akademisyenler

Akademisyenler araştırma yöntemi, bilimsel yayın ve üniversite bağlantıları açısından değer sağlayabilir. Projelerin gerçekten yeni bilgi üretip üretmediğini değerlendirebilirler. Akademik teşvik ile ticari gizlilik arasında denge kurulması gerekebilir. Akademisyenin kendi üniversitesinin izin ve etik kuralları ayrıca dikkate alınmalıdır. Projeyle ekonomik ilişkisi varsa çıkar çatışması beyan edilmelidir.

Ar-Ge Uzmanları

Ar-Ge uzmanları proje tasarımı, teknoloji hazırlık seviyesi ve fonlama konusunda deneyim sağlayabilir. Araştırma faaliyeti ile rutin mühendislik işini ayırmada yardımcı olabilirler. Proje planlarının ölçülebilir teknik kilometre taşlarına dönüşmesine katkı sunabilirler. Fon başvurusu deneyimi avantaj sağlar. Ancak yalnız hibe kriterlerine odaklanmak yerine gerçek ürün ve bilimsel değer korunmalıdır.

Yazılım ve Teknoloji Profesyonelleri

Deneyimli yazılım ve teknoloji profesyonelleri mimari, güvenlik, ölçek ve ürünleştirme konusunda pratik görüş sağlayabilir. Akademik olarak güçlü fakat üretimde uygulanması zor fikirlerin riskini gösterebilirler. Open source ve platform ekosistemi hakkında güncel deneyim sunabilirler. Tek teknoloji yığınına aşırı bağlı üyeler yerine farklı alanlardan kişiler tercih edilebilir. Kurulun görevi proje ekibinin yerine kod yazmak değil karar kalitesini artırmaktır.

Girişimciler

Girişimciler müşteri problemi, ürün pazar uyumu ve ticarileştirme açısından farklı perspektif getirir. Teknik olarak başarılı ürünün neden pazarda karşılık bulmayabileceğini erken gösterebilirler. Yatırım ve iş modeli deneyimi değerli olabilir. Ancak her Ar-Ge projesinin hızlı startup modeline dönüşmesi gerekmez. Bilimsel ve toplumsal etki projeleri ayrı değer üretebilir.

Fikri Mülkiyet Uzmanları

IP uzmanları patentlenebilirlik, lisans ve hak devri konularında erken uyarı sağlar. Proje yayına çıkmadan önce koruma stratejisi belirlenebilir. Açık kaynak lisanslarıyla patent stratejisinin birlikte değerlendirilmesi önemlidir. Danışma kurulu seviyesinde genel görüş sunabilirler, somut başvuru için ayrıca profesyonel hizmet gerekebilir. Gizli buluş bilgisine erişim nedeniyle gizlilik sözleşmesi önemlidir.

Finans ve Fonlama Uzmanları

Fon uzmanları ulusal ve uluslararası çağrıların proje portföyüyle eşleştirilmesine yardımcı olabilir. Bütçe ve eş finansman gereksinimlerinin erken anlaşılmasını sağlarlar. Her fonun alınması iyi proje anlamına gelmez. Kooperatif stratejisi yalnız çağrılara göre şekillenmemelidir. Fon fırsatı stratejik projeyi hızlandırmak için araç olarak görülmelidir.

Sektör Temsilcileri

Sektör temsilcileri gerçek işletme problemlerini ve satın alma dinamiklerini danışma kuruluna taşır. Ar-Ge çıktısının saha koşullarına uygunluğunu değerlendirebilirler. Tek şirketin taleplerinin bütün portföyü yönlendirmesine izin verilmemelidir. Birden fazla sektör perspektifi denge sağlayabilir. Ticari sır ve çıkar çatışması prosedürü burada özellikle önemlidir.

Teknoloji Topluluğu Temsilcileri

Teknoloji topluluğu temsilcileri yerel geliştiricilerin ihtiyaçlarını ve açık kaynak kültürünü kooperatife taşıyabilir. Junior geliştirici programları ve gönüllü projeler hakkında görüş sunabilirler. Topluluğun ticari faaliyetlerle karıştırılmaması için görev sınırı açık tutulmalıdır. Gönüllülerin emeği otomatik olarak kooperatif malvarlığı kabul edilmemelidir. İşbirliği açık ve karşılıklı fayda temelinde yürütülmelidir.

Üniversite ve Teknokent Temsilcileri

Üniversite ve teknokent temsilcileri laboratuvar, akademisyen, öğrenci ve teknoloji transfer imkânlarına erişim sağlayabilir. Proje konsorsiyumu oluşturmak kolaylaşabilir. Kurumsal temsilcinin resmi yetkisi ve kişisel görüşü birbirinden ayrılmalıdır. Protokol gerektiren işbirlikleri uygun yetkili organlarca imzalanmalıdır. Danışma üyeliği kurumsal işbirliği sözleşmesinin yerine geçmez.

Danışma Kurulu Üyeleri Nasıl Seçilmeli?

Danışma kurulunun kalitesi üye seçiminin şeffaf ve ihtiyaca dayalı olmasına bağlıdır. Uzmanlık, deneyim, tarafsızlık ve gerçek katılım kapasitesi birlikte değerlendirilmelidir. Üye seçiminde yalnız kişisel çevreye dayanmak kurulun çeşitliliğini azaltabilir. Görev süresi ve yeniden görevlendirme kuralları kurulun yenilenmesini sağlar. Üyelik başlamadan gizlilik ve çıkar çatışması beyanları tamamlanmalıdır.

Uzmanlık Kriterleri

Her üyenin hangi uzmanlık boşluğunu doldurduğu açık olmalıdır. Örneğin siber güvenlik, yapay zekâ, ürünleşme veya patent alanı seçilebilir. Aynı uzmanlıktan çok fazla üye kurul perspektifini daraltabilir. Proje portföyü değiştikçe uzmanlık ihtiyacı da güncellenebilir. Kurul üyeliği süreli tasarlanarak bu esneklik korunabilir.

Mesleki Deneyim

Mesleki deneyim yalnız yıl sayısıyla değerlendirilmemelidir. Benzer Ar-Ge projelerinde gerçek sorumluluk taşımış olmak önemlidir. Başarısız proje deneyimi de doğru öğrenmeler üretmişse değerlidir. Üyenin karmaşık kararları sade biçimde anlatabilmesi kurul için avantajdır. CV kadar referans ve somut proje örnekleri incelenebilir.

Akademik Yetkinlik

Akademik üyelerde araştırma alanının kooperatif projeleriyle ilişkisi önemlidir. Yayın sayısı tek kriter olmamalıdır. Uygulamalı araştırma, sanayi işbirliği ve proje yürütme deneyimi ayrıca değerlendirilebilir. Genç akademisyenlere de kurul veya teknik komitelerde alan açılabilir. Çeşitlilik farklı araştırma yaklaşımlarının bir araya gelmesini sağlar.

Sektör Deneyimi

Sektör deneyimi projenin gerçek kullanıcı ve satın alma koşullarını anlamada faydalıdır. Özellikle B2B projelerde karar süreçleri ve regülasyon bilgisi kritik olabilir. Sektör temsilcisinin kendi şirketine fırsat aktarmaması için çıkar çatışması kuralları uygulanmalıdır. Aynı kişinin proje müşterisi ve tarafsız değerlendirici olması doğru değildir. Gerektiğinde ilgili gündem maddesinde toplantıdan çekilmelidir.

Tarafsızlık

Danışma üyesi her projede tamamen ekonomik ilişkiden bağımsız olmayabilir. Önemli olan çatışmayı açıklamak ve karar sürecini korumaktır. Tarafsızlık beyanı üyelik başlangıcında alınabilir. Proje bazlı güncelleme mekanizması ayrıca kurulmalıdır. Şeffaf çekilme kuralı kurul güvenilirliğini artırır.

Çıkar Çatışması Kontrolü

Adayın ortaklık, yatırım, danışmanlık ve yakın ekonomik ilişkileri beyan edilebilir. Bu bilgiler yalnız gerekli kişilerce erişilebilir biçimde saklanmalıdır. Çatışma üyeliğe mutlak engel olmayabilir. Belirli projelerde müzakere dışı kalma yeterli olabilir. Ancak sürekli çatışma kurul etkinliğini bozuyorsa üyelik uygunluğu yeniden değerlendirilmelidir.

Görev Süresi

Belirli görev süresi kurulun yenilenmesini ve hesap verebilirliğini kolaylaştırır. Bir veya iki yıllık dönemler değerlendirilebilir. Süre sonunda katılım ve ihtiyaç tekrar gözden geçirilir. Görev süresi içinde erken ayrılma prosedürü yazılmalıdır. Süresiz üyelik kurulu zamanla pasif hale getirebilir.

Yeniden Görevlendirme

Başarılı ve aktif üyeler yeniden görevlendirilebilir. Ancak otomatik yenileme yerine katkı ve ihtiyaç değerlendirmesi yapılmalıdır. Aynı üyelerin uzun süre kalması kurumsal hafıza sağlar fakat yeni perspektifleri azaltabilir. Kademeli rotasyon iyi denge oluşturur. Yeniden görevlendirme kararı ilgili yetkili organ tarafından alınmalıdır.

Üyeliğin Sona Ermesi

Görev süresinin bitmesi, istifa, sürekli devamsızlık veya ciddi çıkar çatışması üyeliğin sona erme nedenleri olabilir. Süreç iç tüzükte açık yazılmalıdır. Gizlilik yükümlülüğü üyelik bittikten sonra da devam edebilir. Erişim ve hesap yetkileri sona ererken kapatılmalıdır. Kurul dokümanlarının kişisel cihazlarda tutulmasıyla ilgili veri politikası uygulanmalıdır.

Danışma Kurulu Çalışma Usul ve Esasları

Danışma kurulu ancak düzenli işleyen prosedüre sahip olduğunda değer üretir. Toplantı sıklığı, çağrı, gündem, görüş oluşturma ve raportörlük görevleri yazılı hale getirilmelidir. Kurulun bağlayıcı karar organı olmadığı terminolojide de korunmalıdır. “Karar” yerine “tavsiye kararı” veya “görüş” ifadesi kullanılabilir. Dijital toplantı ve belge erişimi özellikle farklı şehirlerden üyeler için süreci kolaylaştırır.

Toplantı Sıklığı

Üç aylık düzenli toplantı birçok Ar-Ge kooperatifi için pratik başlangıç olabilir. Yoğun proje dönemlerinde ek toplantı yapılabilir. Çok sık toplantı üyelerin katılımını azaltabilir. Acil görüş gereken konular yazılı değerlendirme yöntemiyle ele alınabilir. Sıklık proje portföyünün büyüklüğüne göre düzenlenmelidir.

Toplantıya Çağrı

Toplantı çağrısının kim tarafından ve kaç gün önce yapılacağı yazılmalıdır. Gündem ve temel belgeler çağrıyla birlikte iletilmelidir. Son dakika yüzlerce sayfalık doküman göndermek iyi değerlendirme üretmez. Acil toplantı için daha kısa süreli istisna tanımlanabilir. Çağrı kayıtları sekretarya tarafından tutulmalıdır.

Gündemin Oluşturulması

Gündem yönetim kurulu talepleri ve danışma üyelerinin önerileriyle hazırlanabilir. Her gündem maddesinde beklenen çıktı belirtilmelidir. “Proje hakkında konuşma” yerine “teknik riskler hakkında görüş oluşturma” daha iyi tanımdır. Bilgilendirme maddeleri ile görüş istenen maddeler ayrılmalıdır. Gündem yoğunluğu toplantı süresine uygun tutulmalıdır.

Toplantı Nisabı

Danışma kurulunun toplantı nisabı iç çalışma esaslarında belirlenebilir. Bu nisap hukuki organların kanuni nisaplarıyla karıştırılmamalıdır. Kurul yalnız görüş ürettiği için katılım modeli amaca göre tasarlanabilir. Çok düşük katılımla “kurul görüşü” oluşturmak temsil sorununa yol açabilir. Uzmanlık alanına göre davetli dış görüş de alınabilir.

Görüş Oluşturma

Kurul mümkünse ortak görüş oluşturmaya çalışabilir. Farklı görüşler varsa azınlık veya alternatif görüşler de tutanağa geçirilebilir. Bilimsel konularda zorla oybirliği aramak doğru değildir. Belirsizlik ve varsayımlar raporda açıkça belirtilmelidir. Yönetim kurulu farklı görüşleri karar verirken değerlendirebilir.

Tavsiye Kararlarının Kayda Alınması

Her önemli görüş kısa tutanak veya raporla kayıt altına alınmalıdır. Tavsiyenin dayandığı bilgi ve varsa riskler belirtilmelidir. Kişisel sohbet notları resmi görüş yerine geçmemelidir. Yönetim kurulunun aldığı sonraki karar da ayrı kayıt oluşturur. Bu arşiv ileride benzer projelerde değerli kurumsal bilgi sağlar.

Raportör

Raportör toplantı notlarını ve görüş metinlerini hazırlar. Raportör danışma kurulu üyesi veya sekretarya personeli olabilir. Teknik konuları yanlış özetlememek için taslak ilgili üyelerce kontrol edilebilir. Tutanaklar gereksiz kişisel yorum içermemelidir. Gizli proje belgeleri güvenli alanda saklanmalıdır.

Sekretarya

Sekretarya toplantı takvimi, belge dağıtımı ve kayıt süreçlerini yönetir. Bu görev genellikle kooperatif operasyon ekibi tarafından yürütülebilir. Sekretarya danışma kurulunun görüşünü değiştiren karar organı değildir. Belge erişim izinlerini takip etmelidir. Üyelik sona erdiğinde erişimleri kaldırmak da sekretarya sürecinin parçasıdır.

Çevrim İçi Toplantı

Farklı şehir ve ülkelerdeki uzmanlarla çevrim içi toplantı pratik avantaj sağlar. Kullanılacak platformun veri güvenliği ihtiyacı proje niteliğine göre değerlendirilmelidir. Çok gizli araştırma konusu için ek güvenlik önlemleri gerekebilir. Kimlik ve katılım kaydı tutulabilir. Elektronik toplantı usulü iç çalışma esaslarında açıklanmalıdır.

Yıllık Faaliyet Raporu

Danışma kurulu yıllık olarak hangi projeleri değerlendirdiğini ve hangi stratejik önerileri sunduğunu özetleyebilir. Gizli proje detayları kamuya açık raporda yer almamalıdır. Yönetim kuruluna sunulan daha ayrıntılı iç rapor ayrı olabilir. Rapor kurulun toplantı sayısından çok yarattığı stratejik katkıyı göstermelidir. Bir sonraki yılın çalışma öncelikleri de rapora eklenebilir.

Danışma Kurulunun Görevleri

Danışma kurulunun görevleri teknik uzmanlık ile stratejik bakışı kooperatif karar mekanizmasına taşımaktır. Görev listesi açık olmadığı zaman kurul ya sembolik hale gelir ya da yönetim kurulunun alanına girmeye başlar. Ar-Ge stratejisi, proje portföyü, teknoloji eğilimleri, bilimsel nitelik ve ticarileşme potansiyeli uygun danışma konularıdır. Kurul görüş verir, gerekli veriyi talep eder ve riskleri görünür hale getirir. Nihai uygulama ve temsil sorumluluğu ilgili kooperatif organlarında kalır.

Ar-Ge Stratejisine Görüş Vermek

Danışma kurulu kooperatifin araştırma odaklarının bilimsel ve sektörel anlamını değerlendirebilir. Yeni teknoloji alanlarının gerçek potansiyeli tartışılabilir. Yönetim kuruluna iki veya üç yıllık araştırma önceliği önerilebilir. Her trendin stratejiye alınması yerine mevcut yetkinlikle uyum aranmalıdır. Görüşler yıllık strateji güncellemesinde kullanılabilir.

Proje Portföyünü Değerlendirmek

Projeler tek tek güçlü görünse bile birlikte kaynak çatışması yaratabilir. Danışma kurulu portföyde tekrar eden veya birbirini tamamlayan çalışmalar konusunda görüş sağlayabilir. Bilimsel risk ve ortak araştırma altyapısı kullanımı değerlendirilebilir. Bütçe tahsisi nihai olarak yetkili yönetim organının konusudur. Danışma görüşü karar kalitesini destekler.

Teknolojik Eğilimleri Takip Etmek

Yeni framework veya popüler araçları listelemek teknoloji eğilimi takibi için yeterli değildir. Kurul teknolojinin kooperatif projelerine gerçek etkisini değerlendirmelidir. Regülasyon, pazar ve açık kaynak ekosistemi birlikte izlenebilir. Yılda bir teknoloji radar raporu hazırlanabilir. Bu rapor yatırım ve eğitim önceliklerini destekler.

Yeni Araştırma Alanları Önermek

Üyeler akademik veya sektörel gelişmelere dayanarak yeni araştırma alanı önerebilir. Her öneri küçük keşif çalışmasıyla doğrulanabilir. Kaynak ve ekip bulunmadan büyük proje başlatılmamalıdır. Kooperatif ortaklarının ekonomik menfaatiyle bağlantı aranmalıdır. Yeni alanlar mevcut projeleri kesintiye uğratmadan portföye alınmalıdır.

Üniversite ve Sanayi İşbirliğini Geliştirmek

Danışma üyelerinin bağlantıları ortak proje fırsatları yaratabilir. Ancak bağlantı kurmak tek başına kurumsal sözleşme anlamına gelmez. Üniversite protokolleri ve mali taahhütler yetkili organlarca yürütülmelidir. Akademisyen ve sektör temsilcilerinin aynı proje etrafında buluşması bilgi transferini güçlendirir. Başarılı işbirliği ölçümü protokol sayısından çok ortak çıktı üzerinden yapılmalıdır.

Fonlama Fırsatlarına İlişkin Görüş Vermek

Fon çağrıları proje portföyüyle eşleştirilebilir. Kurul projenin çağrıya teknik uyumunu değerlendirebilir. Finans ve proje uzmanları bütçe risklerini görünür hale getirebilir. Yalnız fon var diye kooperatif stratejisinin dışında proje üretilmemelidir. Fon araçtır, araştırma stratejisinin kendisi değildir.

Projelerin Bilimsel Niteliğini Değerlendirmek

Ar-Ge etiketi taşıyan her yazılım projesi bilimsel araştırma niteliği göstermeyebilir. Danışma kurulu teknik belirsizlik, yeni bilgi üretimi ve yöntem açısından değerlendirme yapabilir. Rutin entegrasyon işleri ile gerçek araştırma ayrılabilir. Bu ayrım fon başvurularında da önemlidir. Bilimsel görüş yazılı gerekçeyle kaydedilmelidir.

Etki ve Ticarileşme Potansiyelini Değerlendirmek

Teknik olarak başarılı araştırmanın kullanıcı veya ekonomik etki üretip üretmeyeceği ayrıca değerlendirilmelidir. Hedef pazar, lisans modeli ve ölçeklenebilir iş modeli tartışılabilir. Sosyal veya bölgesel etki de yalnız ticari gelir kadar önemli olabilir. Her proje aynı ticari kriterle değerlendirilmemelidir. Proje amacıyla uyumlu etki göstergeleri seçilmelidir.

Danışma Kurulunun Yetki Sınırları

Danışma kurulunun en önemli tasarım konusu ne yapabileceğinden çok ne yapamayacağının açıklanmasıdır. Kurul bağlayıcı yönetim kararı alamaz, kooperatifi temsil etmez ve genel kurulun devredilemez yetkilerini kullanamaz. Mali taahhüt, ortaklık ve personel kararları yetkili kooperatif organlarında kalmalıdır. Bu sınırlar üyeleri değersizleştirmez; aksine hukuki sorumluluk ile uzman görüşünü doğru yere yerleştirir. Ar-Ge kooperatifi danışma kurulu nasıl oluşturulur ve nasıl çalışır sorusunun güvenli cevabı bu yetki matrisinin yazılı hale getirilmesidir.

Bağlayıcı Karar Alamama Prensibi

Danışma kurulunun görüşleri öneri niteliğinde olmalıdır. Yönetim kurulu görüşü kabul edebilir, değiştirebilir veya gerekçesiyle farklı karar alabilir. Danışma raporunda “onaylandı” yerine “olumlu görüş verildi” gibi terminoloji tercih edilebilir. Bu ayrım özellikle hukuki sorumluluk açısından önemlidir. Kurulun prestiji bağlayıcı yetki vermeden de korunabilir.

Yönetim Kurulunun Yetkilerine Müdahale Edilmemesi

Yönetim kurulu temsil, idare ve kanundan kaynaklanan sorumluluklarını başka bir gayriresmî yapıya bırakamaz. Danışma kurulunun her sözleşmeye veto hakkı koyması yönetişim sorununa yol açabilir. Bunun yerine büyük teknoloji yatırımlarında ön görüş alınması kuralı belirlenebilir. Yönetim kurulu nihai kararı kendi toplantısında almalıdır. Sorumluluk ile karar yetkisi aynı yerde kalmalıdır.

Genel Kurulun Devredilemez Yetkilerinin Korunması

Genel kurula kanunla bırakılan yetkiler danışma kuruluna verilemez. İç tüzük ana sözleşme veya kanunu aşamaz. Danışma kurulu genel kurul gündemi hakkında rapor hazırlayabilir fakat karar veremez. Ortakların oy hakkı danışma üyeliğiyle değişmez. Bu sınır ana sözleşme ve iç düzenlemede tutarlı biçimde korunmalıdır.

Mali Taahhüt Verme Yetkisi

Danışma kurulu üyesi kooperatif adına harcama veya sözleşme taahhüdünde bulunmamalıdır. Proje bütçesinin yeterli olduğunu belirten görüş mali onay anlamına gelmez. İmza yetkisi kooperatifin temsil düzenine göre belirlenir. Dış toplantılarda danışma üyesinin sıfatı açıkça ifade edilmelidir. Bu yaklaşım üçüncü taraflarda yanlış temsil algısını önler.

Kooperatifi Temsil Yetkisi

Danışma üyeliği kendiliğinden temsil yetkisi oluşturmaz. Kooperatif adına resmi açıklama veya sözleşme yapılacaksa ayrıca yetkilendirme gerekir. Konferans veya bilimsel toplantıda kurul üyesi kooperatifi temsil edecekse kapsam yazılı belirlenebilir. Basın açıklamaları iletişim politikasıyla uyumlu olmalıdır. Yetkisiz temsil riski özellikle uluslararası işbirliklerinde önemlidir.

Personel ve Ortaklık Kararları

Danışma kurulu adaylar hakkında uzmanlık görüşü verebilir. Ancak personel işe alımı ve ortaklık kabulü yetkili organlarca yapılmalıdır. Kurul üyelerinin kendi öğrencisi veya şirket çalışanı aday olduğunda çıkar çatışması doğabilir. İlgili üye değerlendirmeden çekilmelidir. Tavsiye ile karar sınırı burada da korunmalıdır.

Danışma Kurulunda Çıkar Çatışması Yönetimi

Ar-Ge projeleri fon, patent ve ticari fırsat ürettiği için danışma kurulu üyelerinin çıkar çatışması yaşaması mümkündür. Bu durum tek başına etik ihlal değildir. Sorun çatışmanın gizlenmesi veya karar sürecini etkilemesine izin verilmesidir. Yazılı beyan, görüşmeden çekilme ve kayıt sistemi en temel korumalardır. Gizlilik yükümlülüğü de çıkar çatışması politikasının ayrılmaz parçasıdır.

Çıkar Çatışmasının Tanımı

Çıkar çatışması üyenin kişisel, ticari veya akademik menfaatinin tarafsız değerlendirmeyi etkileyebileceği durumdur. Ortaklık, danışmanlık, yatırım veya yakın aile ilişkisi örnek olabilir. Tanım aşırı geniş tutulursa kurul çalışamaz hale gelebilir. Makul önem eşiği belirlenmelidir. Şüphe durumunda beyan etmeyi teşvik eden kültür oluşturulmalıdır.

Proje ile İlişkili Üyenin Beyanı

Üye gündem kendisine gönderildiğinde çatışma ihtimalini sekretaryaya bildirmelidir. Beyan toplantı sırasında da yapılabilir. Mali detayların gereksiz biçimde bütün kurula açıklanması gerekmez. Çatışmanın niteliği ve uygulanacak tedbir yeterli olabilir. Kayıt gizlilik kurallarıyla saklanmalıdır.

Müzakereye Katılmama

Çatışmalı üye ilgili proje tartışmasına katılmayabilir. Toplantının diğer bölümlerine devam edebilir. Uzman görüşüne ihtiyaç varsa yalnız teknik bilgi sağladıktan sonra değerlendirme kısmından çıkması düşünülebilir. Bu yöntem iç tüzükte açıklanmalıdır. Tutanakta çekilme durumu kaydedilmelidir.

Oy/Görüş Sürecinden Çekilme

Danışma kurulu bağlayıcı oy kullanmasa bile toplu görüş oluşturma sürecinde etkili olabilir. Çatışmalı kişinin değerlendirme puanı veya görüş sonucuna katılmaması gerekir. Teknik veri sağlaması ile tavsiye oluşturması ayrılmalıdır. Bu yöntem diğer üyelerin bağımsız değerlendirmesini korur. Aynı prensip proje değerlendirme komitelerinde de uygulanabilir.

Çıkar Çatışması Sicili

Üyelerin beyanları ve hangi toplantıda çekildikleri kayıt altına alınabilir. Sicil kamuya açık olmak zorunda değildir. Erişim yalnız gerekli yönetim ve denetim kişileriyle sınırlı tutulmalıdır. Düzenli güncelleme yapılmalıdır. Kayıt gelecekte karar sürecinin şeffaflığını kanıtlamaya yardımcı olur.

Gizlilik Yükümlülüğü

Danışma üyeleri henüz yayımlanmamış araştırma, müşteri verisi ve kaynak kod bilgisine erişebilir. Bu nedenle gizlilik sözleşmesi üyelik başlamadan tamamlanmalıdır. Bilgi yalnız görev kapsamında kullanılmalıdır. Üyelik bitince doküman erişimleri kaldırılmalıdır. Gizlilik yükümlülüğünün devam süresi sözleşmede açık olmalıdır.

Ar-Ge Projeleri Kooperatife Nasıl Kabul Edilmeli?

Her proje fikrini doğrudan geliştirmeye almak kaynakların dağılmasına neden olur. Ar-Ge kooperatifi proje kabulünü teknik, ticari, IP ve stratejik aşamalara bölebilir. Danışma kurulu bilimsel ve teknik görüş sunarken yönetim kurulu bütçe ve resmi kabul kararını verir. Proje kabul edildikten sonra görev, bütçe, hak sahipliği ve raporlama proje sözleşmesinde yazılı hale getirilmelidir. Böylece proje portföyü kişisel ilişkiler yerine ortak kriterlerle yönetilir.

Proje Fikri Başvurusu

Başvuru ilk aşamada kısa tutulabilir. Problem, çözüm yaklaşımı, hedef kullanıcı, teknik belirsizlik ve ekip bilgisi yeterli olabilir. Fikir erken aşamadaysa detaylı bütçe istemek gereksizdir. Başvurular standart sistemde arşivlenmelidir. Aynı fikirlerin tekrarını görmek strateji açısından da bilgi sağlar.

Ön Kontrol

Ön kontrol projenin kooperatif amacı, etik ve temel uygunluk şartlarını karşılayıp karşılamadığını değerlendirir. Eksik başvurular geliştirilmek üzere geri gönderilebilir. Açıkça kapsam dışı projeler erken elenerek uzman zamanından tasarruf edilir. Çıkar çatışması bu aşamada belirlenebilir. Ön kontrol teknik detay değerlendirmesinin yerine geçmez.

Teknik İnceleme

Teknik inceleme projenin araştırma niteliğini, yapılabilirliğini ve temel risklerini değerlendirir. Teknik komite veya uzman hakemler kullanılabilir. Kullanılacak teknoloji adı tek başına yenilik kanıtı değildir. Teknik belirsizlik ve yeni bilgi üretme potansiyeli önemlidir. Sonuç kısa raporla kaydedilmelidir.

Ticari İnceleme

Her Ar-Ge projesi ticari ürün olmak zorunda değildir. Ancak ticari hedef varsa kullanıcı ihtiyacı, pazar, maliyet ve gelir modeli değerlendirilmelidir. Kamu yararı veya açık kaynak projelerinde farklı etki kriterleri kullanılabilir. Ticarileştirme uzmanı teknik ekibin varsayımlarını sorgulayabilir. Projenin amacı ile değerlendirme kriteri uyumlu olmalıdır.

Fikri Mülkiyet İncelemesi

Başvuru aşamasında mevcut patent, açık kaynak kod ve önceki IP ilişkileri incelenmelidir. Proje ekibinin getirdiği background IP kaydedilmelidir. Üçüncü taraf lisansların ileride ticarileştirmeyi sınırlayıp sınırlamadığı kontrol edilmelidir. Patent araştırması gerekiyorsa uzman desteği alınabilir. IP sorunu proje bittikten sonra çözülmeye bırakılmamalıdır.

Danışma Kurulu Görüşü

Danışma kurulu teknik ve bilimsel değerlendirmeyi bütüncül biçimde inceleyebilir. Projenin stratejik potansiyeli hakkında görüş sunabilir. Çıkar çatışmalı üyeler değerlendirmeye katılmamalıdır. Görüş tavsiye niteliğinde olmalıdır. Yönetim kuruluna puan ve kısa gerekçeyle sunulması karar sürecini kolaylaştırır.

Yönetim Kurulu Kararı

Nihai kabul kararı yetkili yönetim kurulu tarafından alınır. Teknik puanın yanında bütçe ve kapasite de değerlendirilir. Proje reddedilirse uygun olduğunda gerekçe kaydedilebilir. Şartlı kabul modeli kullanılabilir. Örneğin müşteri doğrulaması veya ek fon sağlanması proje başlangıç koşulu olabilir.

Proje Sözleşmesi

Kabul edilen proje için ekip, bütçe, IP, gizlilik ve raporlama şartları yazılı hale getirilmelidir. Müşteri veya fon sağlayıcı varsa dış sözleşmelerle uyum sağlanmalıdır. Proje yürütücüsünün harcama ve teknik karar yetkisi belirlenmelidir. Projeden ayrılma ve başarısız kapanış senaryosu da yazılmalıdır. İyi proje sözleşmesi teknik ekibin yönetişim tartışmaları yerine araştırmaya odaklanmasını sağlar.

Örnek 100 Puanlık Ar-Ge Proje Değerlendirme Modeli

Yüz puanlık model proje değerlendirmesinde ortak dil oluşturmak için kullanılabilir. Puanlama hiçbir zaman otomatik yönetim kararı olarak görülmemelidir. Değerlendiriciler her puan için kısa gerekçe yazmalıdır. Projenin niteliğine göre ağırlıklar yönetim kurulu tarafından dönemsel olarak güncellenebilir. Aşağıdaki model bilimsel nitelik, yenilik, ekip, ticari potansiyel, IP, işbirliği ve bölgesel etkiyi birlikte ele alan örnek bir çerçevedir.

Ar-Ge Niteliği — 20 Puan

Ar-Ge niteliği projenin teknik belirsizliğini ve yeni bilgi üretme potansiyelini değerlendirmelidir. Rutin yazılım entegrasyonları düşük puan alabilir. Araştırma yöntemi ve test edilebilir hipotez güçlü sinyal oluşturur. Puanın yüksek olması projenin otomatik kabulü değildir. Teknik risk ve yapılabilirlik ayrıca değerlendirilir.

Teknik Belirsizlik

Teknik belirsizlik mevcut bilgiyle sonucun önceden kesin biçimde bilinmemesini ifade eder. Sadece zor kod yazmak Ar-Ge belirsizliği değildir. Proje belirli teknik soruyu deney veya prototiple araştırmalıdır. Belirsizliğin ölçülebilir olması gerekir. Sonuç başarısız olsa bile yeni bilgi üretilebilir.

Bilimsel Derinlik

Bilimsel derinlik kullanılan yöntem, literatür ve deney tasarımıyla ilişkilidir. Her proje akademik yayın hedeflemek zorunda değildir. Ancak iddialar ölçülebilir kanıta dayanmalıdır. Uzman değerlendirmesi yöntem hatalarını erken gösterebilir. Gereksiz akademik dil teknik değerin yerine geçmemelidir.

Yeni Bilgi Üretme Potansiyeli

Proje yalnız bilinen çözümü uygulamıyorsa yeni bilgi üretme potansiyeli taşır. Bu bilgi algoritma, süreç veya teknoloji davranışı hakkında olabilir. Sonucun yayınlanması zorunlu değildir. Kurumsal bilgi de ekonomik değer üretir. Öğrenme proje sonunda kayıt altına alınmalıdır.

Yenilikçilik — 15 Puan

Yenilikçilik ürün, süreç veya kullanılan teknik yaklaşım üzerinden değerlendirilebilir. “AI kullanıyor” veya “blockchain içeriyor” gibi ifadeler tek başına yenilik kanıtı değildir. Yeniliğin kullanıcı problemi veya teknik avantajı açıklanmalıdır. Mevcut çözümlerle karşılaştırma yapılmalıdır. Bölgesel yenilik ile küresel yenilik farklı seviyelerde puanlanabilir.

Ürün Yeniliği

Ürün yeniliği kullanıcıya yeni veya önemli ölçüde geliştirilmiş değer sunmayı ifade eder. Görsel değişiklik tek başına güçlü yenilik olmayabilir. Kullanıcı davranışında veya sonuçta anlamlı fark aranmalıdır. Prototip ve kullanıcı testi kanıt sağlayabilir. Yenilik gerçek kullanım bağlamında değerlendirilmelidir.

Süreç Yeniliği

Süreç yeniliği mevcut bir işin daha hızlı, ucuz veya güvenilir yapılmasını sağlayabilir. Sanayi işbirliği projelerinde önemli değer taşır. Mevcut baseline ölçülmeden iyileşme iddiası zayıf kalır. Süre, maliyet veya hata oranı hedefleri yazılabilir. Proje sonunda önceki durumla karşılaştırma yapılmalıdır.

Teknoloji Yeniliği

Teknoloji yeniliği yeni teknik yöntem veya mimari geliştirilmesini kapsayabilir. Yeni kütüphane kullanmak kendi başına teknoloji yeniliği değildir. Araştırma sonucunda ölçülebilir performans veya yetenek farkı oluşmalıdır. Patent ve açık kaynak potansiyeli değerlendirilebilir. Yeniliğin bakım ve sürdürülebilirlik maliyeti de hesaba katılmalıdır.

Teknik Yapılabilirlik — 15 Puan

Teknik yapılabilirlik projenin kaynak ve zaman içinde gerçekleştirilebilirliğini ölçer. Çok yüksek bilimsel değer fakat erişilemeyen veri veya donanım projenin riskini artırır. Kritik dependency'ler belirlenmelidir. Gerekirse önce küçük PoC yapılabilir. Puan yalnız iyimser proje sunumuna değil mevcut kapasiteye dayanmalıdır.

Ekip Yetkinliği — 15 Puan

Ekip yetkinliği teknik bilgi, araştırma deneyimi ve proje yönetimi kapasitesini birlikte kapsar. Tek bir yıldız geliştirici yerine dengeli ekip tercih edilebilir. Eksik uzmanlık dış danışmanla tamamlanabilir. Zaman ayırma kapasitesi CV kadar önemlidir. Ekipte kritik kişinin ayrılması risk planında değerlendirilmelidir.

Ekonomik/Ticari Potansiyel — 10 Puan

Ticari potansiyel hedef müşterinin problemi ve ödeme isteği üzerinden değerlendirilmelidir. Büyük pazar tahmini tek başına yeterli değildir. İlk müşteri veya pilot sinyali güçlü kanıt sağlar. Akademik veya sosyal etki projesinde bu kriterin ağırlığı değiştirilebilir. Puanlama proje amacına göre uygulanmalıdır.

Fikri Mülkiyet Potansiyeli — 10 Puan

IP potansiyeli patent, lisans, know-how veya copyright değeri üzerinden değerlendirilebilir. Her proje patentlenebilir olmak zorunda değildir. Açık kaynak stratejisi de değerli olabilir. Freedom to operate ve üçüncü taraf lisansları dikkate alınmalıdır. IP'nin ticarileştirme stratejisiyle ilişkisi açıklanmalıdır.

İşbirliği Potansiyeli — 10 Puan

Üniversite, sanayi veya diğer ortaklarla işbirliği projenin bilgi ve kaynak kapasitesini artırabilir. İşbirliği yalnız protokol imzalamak anlamına gelmez. Somut görev ve çıktı paylaşımı olmalıdır. Kooperatif ortaklarının birlikte çalışmasını sağlayan projeler ayrıca değerli olabilir. Çok fazla partner koordinasyon maliyeti de yaratabileceği için gerçek ihtiyaç aranmalıdır.

Sosyal ve Bölgesel Etki — 5 Puan

Bölgesel istihdam, yetenek gelişimi ve yerel firmalara sağlanan teknoloji değeri ölçülebilir. Sosyal etki yalnız iletişim sloganı olmamalıdır. Hedeflenen fayda için gösterge belirlenmelidir. Diyarbakır gibi büyüyen teknoloji ekosistemlerinde yerel yeteneğin projeye katılımı önemli çıktı olabilir. Ticari ve sosyal etki birlikte değerlendirilebilir.

Proje Yürütücüsü ve Ar-Ge Ekibi Nasıl Belirlenmeli?

Proje ekibi yalnız en iyi teknik uzmanlardan değil araştırmayı sonuca taşıyacak tamamlayıcı rollerden oluşmalıdır. Proje yürütücüsü teknik ve idari koordinasyonu birlikte yönetebilmelidir. Büyük projelerde teknik lider ile mali proje sorumlusu ayrılabilir. Öğrenci ve stajyerlerin katkısı eğitim ve gözetim planıyla desteklenmelidir. Her rolün yetki ve raporlama sınırı proje sözleşmesinde yazılmalıdır.

Proje Yürütücüsünün Görevleri

Proje yürütücüsü hedef, zaman, ekip ve risk koordinasyonunu sağlar. Yönetim kuruluna düzenli ilerleme raporu sunar. Bütçeyi yetki sınırları içinde takip eder. Fikri mülkiyet ve veri politikalarının uygulanmasını gözetir. Teknik kararların tamamını tek başına vermek zorunda değildir.

Teknik Lider

Teknik lider mimari ve araştırma yönteminin günlük uygulanmasına liderlik eder. Büyük teknik kararları dokümante eder. Code review ve kalite standartlarını koordine eder. Proje yürütücüsüyle düzenli risk değerlendirmesi yapar. Tek kişiye bilgi bağımlılığı oluşturmamak için mentoring ve dokümantasyon sorumluluğu da taşımalıdır.

Araştırmacılar

Araştırmacılar deney tasarımı, literatür, veri analizi ve teknik hipotezlerin doğrulanmasında görev alır. Akademik ve endüstriyel araştırmacılar birlikte çalışabilir. Araştırma kayıtları tekrar üretilebilir biçimde tutulmalıdır. Yayın ve patent zamanlaması proje başlangıcında konuşulmalıdır. Etik standartlar bütün araştırmacılar için geçerli olmalıdır.

Yazılım Geliştiriciler

Yazılım geliştiriciler araştırma çıktısını prototip veya ürün sistemine dönüştürür. Kod kalitesi, test ve güvenlik standartları proje niteliğine göre belirlenmelidir. Repository erişimleri rol bazlı yönetilmelidir. Geliştiricilerin yalnız implementasyon değil teknik araştırma sürecine de katkısı olabilir. AI destekli coding araçlarının kullanımı veri ve IP politikasıyla uyumlu olmalıdır.

Ürün ve Tasarım Ekibi

Ürün ve tasarım ekibi araştırma fikrinin gerçek kullanıcı problemiyle bağlantısını korur. Kullanıcı görüşmeleri ve prototip testleri yapabilir. Teknik başarının ürün başarısıyla aynı olmadığı gerçeğini görünür hale getirir. Araştırma ekibiyle düzenli senkronizasyon gerekir. Kullanıcı verileri işleniyorsa kişisel veri kuralları uygulanmalıdır.

Mali/İdari Proje Sorumlusu

Fonlu veya büyük bütçeli projelerde mali sorumlu harcama uygunluğunu ve raporlamayı takip eder. Teknik ekipten farklı uzmanlık gerektirir. Satın alma belgeleri ve ödeme takvimi düzenli tutulmalıdır. Fon sağlayıcı raporları son haftaya bırakılmamalıdır. Proje yürütücüsüyle aylık bütçe kontrolü yapılabilir.

Dış Uzmanlar

Dış uzmanlar proje ekibinde bulunmayan belirli yetkinliği kısa süreli sağlayabilir. Sözleşmede teslimat, gizlilik ve IP hükümleri açık olmalıdır. Danışmanlık hizmeti ile kooperatif ortaklığı birbirinden bağımsız ilişkidir. Ücret ve sorumluluk kapsamı önceden belirlenmelidir. Kritik bilgi dış uzmanda tek başına kalmamalıdır.

Öğrenci ve Stajyer Araştırmacılar

Öğrenci ve stajyerler gerçek Ar-Ge projelerinde değerli öğrenme fırsatı elde edebilir. Ancak ücretsiz işgücü gibi kullanılmamalıdır. Görevleri eğitim seviyesine uygun olmalı ve mentor atanmalıdır. Gizlilik ve veri erişimi minimum ihtiyaç prensibine göre verilmelidir. Başarılı öğrenciler junior araştırmacı programına geçebilir.

“En İyi Programlama Dili” Ar-Ge Projelerinde Bir Kriter midir?

Ar-Ge projesinde tek bir en iyi programlama dili yoktur. Proje problemi, araştırma araçları, performans ihtiyacı, ekip yetkinliği ve açık kaynak ekosistemi birlikte değerlendirilmelidir. Popüler teknoloji seçmek bilimsel yenilik anlamına gelmez. Bazı projelerde Python hızlı araştırma sağlar, başka projede farklı dil güvenlik veya performans nedeniyle daha uygun olabilir. Teknoloji seçimi proje değerlendirme puanında isim üzerinden değil gerekçeli teknik uygunluk üzerinden ele alınmalıdır.

Tek Bir En İyi Dil Neden Yoktur?

Her programlama dili farklı çalışma alanlarında avantaj ve maliyet taşır. Veri bilimi, embedded sistem ve web uygulaması aynı gereksinime sahip değildir. Ekip deneyimi üretkenliği doğrudan etkiler. Kütüphane ve tooling desteği de seçimde önemlidir. Bu nedenle dil karşılaştırması proje bağlamından kopuk yapılmamalıdır.

Proje Problemine Göre Teknoloji Seçimi

Önce çözülmek istenen teknik problem tanımlanmalıdır. Gecikme, güvenlik, veri hacmi ve donanım entegrasyonu gibi gereksinimler yazılabilir. Teknoloji bu gereksinimleri karşılayacak seçeneklerden seçilmelidir. Gerekiyorsa küçük benchmark veya PoC yapılabilir. Karar teknik decision record içinde saklanmalıdır.

Teknik Ekibin Yetkinliği

Ekibin bildiği teknoloji geliştirme ve debugging süresini azaltır. Yeni dil öğrenmek araştırma için gerekli olabilir fakat süre maliyeti hesaba katılmalıdır. Tek kişinin bildiği teknoloji bus factor yaratabilir. Eğitim planı oluşturulabilir. İşe alım ve sürdürülebilir bakım da değerlendirilmelidir.

Uzun Vadeli Bakım

Ar-Ge prototipi başarılı olduğunda ürünleşme ihtimali doğabilir. Çok özel ve bakımı zor teknoloji ileride maliyet yaratabilir. Prototip ile production çözümünün aynı olması zorunlu değildir. Ancak geçiş maliyeti baştan bilinmelidir. Açık dokümantasyon ve test sürdürülebilirliği artırır.

Açık Kaynak Ekosistemi

Olgun açık kaynak kütüphaneler geliştirme hızını artırabilir. Ancak lisans ve bakım durumu kontrol edilmelidir. Terk edilmiş dependency araştırma projesini riske atabilir. Kritikte kullanılan kütüphanenin güvenlik güncellemeleri izlenmelidir. Açık kaynak kullanımı kooperatif politikasına göre kayıt altına alınabilir.

Performans ve Ölçeklenebilirlik

Performans ihtiyacı gerçek workload üzerinden belirlenmelidir. Henüz bin kullanıcı yokken milyon kullanıcı için mimari kurmak gereksiz maliyet oluşturabilir. Araştırma projesinde kritik algoritma için benchmark yapılabilir. Ölçeklenebilirlik teknik uygunluğun yalnız bir boyutudur. Bakım ve geliştirici deneyimi de kararın parçasıdır.

Lisans ve Maliyet

Programlama dili ücretsiz olsa bile kullanılan runtime, kütüphane veya platform maliyet doğurabilir. Ticari lisans koşulları ticarileştirme planını etkileyebilir. Cloud bağımlılığı da uzun vadeli maliyete dahil edilmelidir. Open source lisans uyumluluğu kontrol edilmelidir. Teknoloji kararı toplam sahip olma maliyetiyle değerlendirilmelidir.

Yazılımcı Olmak İsteyenler Ar-Ge Kooperatifine Nasıl Dahil Edilebilir?

Ar-Ge kooperatifi yalnız deneyimli uzmanların proje yaptığı kapalı yapı olmak zorunda değildir. Junior araştırmacı programı, mentorluk, pair programming ve açık kaynak katkıları yeni geliştiriciler için kontrollü öğrenme alanı yaratabilir. Üretim sistemlerine erişim kademeli verilmelidir. Eğitim ile ücretli proje emeği arasındaki sınır açık tutulmalıdır. Başarılı program hem yerel yetenek havuzunu büyütür hem kooperatifin gelecekteki insan kaynağını geliştirir.

Junior Araştırmacı Programı

Junior programı belirli süre ve öğrenme hedefleriyle tasarlanabilir. Katılımcılara küçük araştırma veya prototip görevleri verilebilir. Her katılımcıya mentor atanmalıdır. Program sonunda somut proje veya açık kaynak contribution hedeflenebilir. Değerlendirme yalnız kod miktarına göre yapılmamalıdır.

Mentorluk

Mentorluk teknik bilgi kadar araştırma yaklaşımı ve ekip kültürünü aktarır. Mentor her problemi çözmek yerine düşünme yöntemini öğretmelidir. Düzenli kısa görüşmeler uygulanabilir. Mentor yükü dengeli dağıtılmalıdır. Program sonunda mentee'nin bağımsızlaşması temel başarı göstergesidir.

Pair Programming

Pair programming yeni geliştiricinin gerçek kod tabanını daha hızlı anlamasını sağlar. Özellikle kritik veya belirsiz görevlerde etkilidir. Sürekli zorunlu tutulması gerekli değildir. Mentor ve junior roller zamanla değişebilir. Oturum sonrasında öğrenilen noktaların kısa notu dokümantasyona dönüşebilir.

Code Review

Code review yeni geliştiricinin standartları ve sistem tasarımını öğrenmesi için güçlü araçtır. Yorumlar yalnız hatayı değil nedenini açıklamalıdır. Aynı hatalar tekrar ediyorsa dokümantasyon geliştirilebilir. Review kişisel eleştiri değil kod ve çözüm tartışması olarak yürütülmelidir. Psychological safety öğrenmeyi hızlandırır.

Gerçek Ar-Ge Projelerine Katılım

Junior geliştiriciler yalnız eğitim projesinde kalmamalıdır. Uygun risk seviyesinde gerçek proje görevleri verilmelidir. Mentor review ve test süreçleri güvenli alan sağlar. Gizli veya kritik veriye erişim rol bazlı sınırlandırılmalıdır. Gerçek proje deneyimi araştırma ile üretim arasındaki farkı öğretir.

Teknik Seminerler

Kooperatif üyeleri ve dış uzmanlar düzenli teknik seminer verebilir. Konular aktif projelerin ihtiyacına göre seçilebilir. Yalnız sunum yerine demo ve uygulama yapılması öğrenmeyi artırır. Kayıtların açık yayımlanması IP ve gizlilik açısından kontrol edilmelidir. Eğitim içeriği toplulukla paylaşılabiliyorsa bölgesel etki büyür.

Açık Kaynak Katkısı

Açık kaynak projeler junior geliştiricilere gerçek review ve collaboration deneyimi sunar. Good first issue etiketleri giriş kolaylığı sağlar. Contributor Guide açık olmalıdır. Katkıların lisans ve IP şartları baştan belirtilmelidir. Başarılı katkıcılar daha büyük proje rollerine geçebilir.

Fikri Mülkiyet Hakları Nasıl Yönetilmeli?

Ar-Ge kooperatiflerinde en kritik belgelerden biri IP politikasıdır. Proje başlamadan önce kimin hangi fikri mülkiyeti getirdiği ve proje sırasında üretilecek hakların nasıl yönetileceği belirlenmelidir. Patent, kaynak kod, veri seti ve akademik yayın farklı hak rejimleri doğurabilir. Müşteri sözleşmesi veya fon programı özel hak koşulları getirebilir. Genel iç politika ile proje bazlı IP sözleşmesi birlikte kullanılmalıdır.

Proje Öncesinde Mevcut Fikri Mülkiyet

Proje ekibinin daha önce geliştirdiği kod, patent veya know-how proje başlamadan kayıt altına alınmalıdır. Bu varlıklar otomatik olarak kooperatifin mülkiyetine geçmez. Kullanım hakkı gerekiyorsa lisans koşulları yazılmalıdır. Proje sonunda background IP'nin geliştirilmiş versiyonunun durumu ayrıca düşünülmelidir. Envanter sözleşmeye eklenebilir.

Background IP

Background IP proje başlamadan önce taraflardan birine ait olan fikri mülkiyettir. Kaynak kod, algoritma veya patent buna örnek olabilir. Projede kullanılacaksa hangi kapsamda lisanslandığı belirlenmelidir. Mülkiyet ile kullanım hakkı ayrılmalıdır. Bu kayıt proje sonunda “Bu kod zaten benimdi” tartışmasını azaltır.

Proje Sırasında Üretilen Fikri Mülkiyet

Proje içinde yeni geliştirilen yazılım, buluş ve veri çıktıları foreground IP olarak değerlendirilebilir. Hak sahipliği çalışan, ortak, kooperatif ve müşteri ilişkisine göre ayrıca incelenmelidir. Tek bir genel cümle bütün projeler için yeterli olmayabilir. Proje sözleşmesi açık hüküm içermelidir. Gelir paylaşımı mülkiyet oranından ayrı düzenlenebilir.

Foreground IP

Foreground IP proje çalışmaları sonucunda ortaya çıkan yeni hakları ifade eder. Kooperatif mülkiyeti veya ortak mülkiyet modeli seçilebilir. Fon programları özel şart getirebilir. Patent başvurusu öncesi akademik yayın yapılması yenilik şartını etkileyebileceğinden zamanlama önemlidir. IP komitesi veya uzman görüşü kullanılabilir.

Patent Hakları

Patent potansiyeli bulunan buluşlar kamuya açıklanmadan önce değerlendirilmelidir. Buluş sahipliği ile patent hakkı ilişkisi somut hukuki durumda uzmanlık gerektirir. Başvuru maliyeti ve koruma ülkeleri stratejik seçilmelidir. Her teknik yeniliği patentlemek ekonomik değildir. Lisans veya ticari sır modeli daha uygun olabilir.

Faydalı Model

Uygun buluşlarda faydalı model koruması değerlendirilebilir. Patentten farklı koşul ve kapsamı olduğu için uzman görüşü gerekir. Projenin ticarileştirme planıyla ilişkisi kurulmalıdır. Koruma maliyeti potansiyel değerle karşılaştırılmalıdır. Başvurudan önce kamuya açıklama riskine dikkat edilmelidir.

Tasarım Hakları

Fiziksel ürün veya görsel tasarım içeren projelerde tasarım koruması gündeme gelebilir. Yazılım arayüzü gibi alanlarda uygulanabilir hak türü somut ürünle birlikte değerlendirilmelidir. Tasarımcı ve kooperatif arasındaki hak ilişkisi sözleşmeyle açıklanmalıdır. Müşteri için geliştirilen tasarımda hak devri farklı olabilir. Marka ve tasarım stratejisi birlikte ele alınabilir.

Yazılım ve Kaynak Kod

Yazılım eser niteliği ve copyright açısından özel sözleşme hükümlerine ihtiyaç duyabilir. Repository sahipliği tek başına hukuki hak sahipliğini belirlemez. Çalışan, danışman ve ortak geliştiricilerin katkı ilişkileri yazılı olmalıdır. Open source dependency hakları ayrıca kontrol edilmelidir. Kaynak kodun müşteri veya kooperatif arasında devri açık sözleşmeyle yapılmalıdır.

Akademik Yayınlar

Akademik yayın kooperatifin bilimsel görünürlüğünü artırabilir. Ancak patent veya ticari sır korunmadan yapılan yayın hak kaybı yaratabilir. Yayın öncesi IP review prosedürü oluşturulmalıdır. Yazarlık katkı esaslarına göre belirlenmelidir. Müşteri gizliliği ve kişisel veri kuralları da dikkate alınmalıdır.

Ticari Sırlar

Her teknik bilgi patentlenmek zorunda değildir. Bazı algoritma, veri veya üretim yöntemi ticari sır olarak korunabilir. Bu durumda erişim ve gizlilik sistemi güçlü olmalıdır. Bilginin kimlere açıldığı kayıt altına alınabilir. İşten veya projeden ayrılan kişiler için devam eden yükümlülükler sözleşmede yer almalıdır.

Lisanslama

Kooperatif sahip olduğu IP'yi üçüncü kişilere lisanslayabilir. Münhasır veya münhasır olmayan lisans modelleri farklı ekonomik sonuç doğurur. Coğrafya, süre ve kullanım alanı açık yazılmalıdır. Open source lisanslarıyla ticari lisans modeli bir arada kullanılabilir. Lisans geliri dağılımı iç politika ve proje sözleşmesiyle uyumlu olmalıdır.

Ticarileştirme Gelirleri

IP'den doğan gelir kooperatif, proje ekibi ve ilgili ortaklar arasında nasıl değerlendirileceği baştan belirlenmelidir. Kooperatif mevzuatı ve vergisel sonuçlar dikkate alınmalıdır. Gelir paylaşımı teknik katkıyı teşvik ederken ortaklar arasında adaleti korumalıdır. Patent maliyetleri ve kooperatif genel gider payı hesaba katılabilir. Her proje için aynı oran zorunlu olmayabilir.

Ortak Geliştirilen Yazılımın Hakları Kime Ait Olmalı?

Ortak yazılım projelerinde hak sahipliği için tek doğru model yoktur. Kooperatif mülkiyeti, ortak mülkiyet, proje ekibi mülkiyeti veya lisans yaklaşımı seçilebilir. Önemli olan modelin kod yazılmadan önce taraflarca anlaşılmasıdır. Repository hesabının kimin adına olduğu ile copyright sahipliği aynı konu değildir. Müşteri projesi ve kooperatifin kendi ürünü için farklı modeller kullanılabilir.

Kooperatif Mülkiyeti Modeli

Kooperatif projenin IP'sini merkezi olarak sahiplenebilir. Bu model lisanslama ve yatırım kararlarını kolaylaştırabilir. Proje ekibine gelir payı veya başka teşvik modeli verilebilir. Hak devri gereken katkılarda yazılı sözleşme yapılmalıdır. Ortak ayrıldığında ürünün devamlılığı daha kolay korunabilir.

Ortak Mülkiyet Modeli

Birden fazla tarafın ortak hak sahipliği bazı konsorsiyum projelerinde kullanılabilir. Ancak lisans, satış ve değişiklik kararlarının nasıl alınacağı ayrıntılı düzenlenmelidir. Ortaklardan birinin ayrılması sorun yaratabilir. Uluslararası projelerde hukuk farkları ayrıca değerlendirilmelidir. Yönetim maliyeti yüksek olduğu için gerçekten gerekli olduğunda tercih edilmelidir.

Proje Ekibi Mülkiyeti

Belirli girişim veya araştırma ekibi IP'nin sahibi kalabilir. Kooperatif kullanım veya ticarileştirme lisansı alabilir. Bu model girişim spin-off hedeflerinde anlamlı olabilir. Kooperatifin yaptığı altyapı ve finansman katkısının karşılığı açık olmalıdır. Hakların proje ekibindeki bireyler arasında nasıl dağıldığı ayrıca düzenlenmelidir.

Lisans Modeli

Hak sahipliği bir tarafta kalırken kooperatife geniş kullanım lisansı verilebilir. Bu yaklaşım background IP içeren projelerde esneklik sağlar. Lisansın süresi, bölgesi ve alt lisans hakkı açık olmalıdır. Açık kaynak bileşenler lisans kapsamına göre ayrıca yönetilir. Ticarileştirme geliri sözleşmeyle paylaşılabilir.

Müşteri Projesinde Hak Devri

Müşteri özel geliştirme karşılığında tüm kaynak kod haklarını isteyebilir. Bu durumda kooperatif daha önce sahip olduğu genel kütüphane ve background IP'yi yanlışlıkla devretmemelidir. Sözleşmede müşteri için özel üretilen kısım ayrılabilir. Tekrar kullanılabilir ortak bileşenler lisanslanabilir. Fiyatlandırma hak devri kapsamını yansıtmalıdır.

Kaynak Kod Deposunun Sahipliği

Repository kooperatifin kurumsal hesabında tutulabilir. Bu operasyonel süreklilik sağlar. Ancak Git deposu mülkiyeti hukuki IP sahipliğinin tek kanıtı değildir. Erişimler rol bazlı yönetilmelidir. Proje bittiğinde arşiv, erişim ve devir prosedürü uygulanmalıdır.

Open Source ve İşbirliği Politikası

Açık kaynak Ar-Ge kooperatifleri için hem bilgi paylaşımı hem yetenek geliştirme aracı olabilir. Ancak lisans seçimi, katkı kabulü ve güvenlik süreçleri belirlenmeden repository açmak risklidir. Projenin ticari modeli ve IP stratejisi open source kararıyla birlikte düşünülmelidir. Bazı bileşenler açık, müşteri verisi veya özel modüller kapalı tutulabilir. Politika bütün proje ekiplerinin anlayabileceği pratik kurallar içermelidir.

Açık Kaynak Kullanım Politikası

Üçüncü taraf açık kaynak paketlerin hangi koşullarda kullanılabileceği yazılmalıdır. Lisans, güvenlik ve bakım durumu kontrol edilebilir. Kritik dependency'ler envantere alınmalıdır. Geliştiricinin her paket için uzun onay beklemesi gereksiz sürtünme yaratabilir. Risk seviyesine göre otomatik araç ve istisna modeli kurulabilir.

Open Source Proje Yayınlama Kriterleri

Projenin açık kaynak yapılması yönetim ve IP değerlendirmesinden geçebilir. Müşteri gizliliği veya patent planı varsa yayın ertelenebilir. Kodun güvenlik ve secret taraması yapılmalıdır. README ve lisans dosyası olmadan repository yayımlanmamalıdır. Maintainer sorumluluğu belirlenmelidir.

Lisans Seçimi

Lisans seçimi projenin ticari ve topluluk hedeflerine göre yapılmalıdır. Permissive ve copyleft lisanslar farklı yükümlülükler getirir. “En popüler lisansı seçelim” yaklaşımı yeterli değildir. Üçüncü taraf dependency lisanslarıyla uyum kontrol edilmelidir. Gerektiğinde fikri mülkiyet uzmanı görüşü alınmalıdır.

MIT

MIT lisansı oldukça izin verici açık kaynak lisanslarından biridir. Kullanım, değiştirme ve dağıtım açısından geniş özgürlük sağlar. Copyright ve lisans bildirimlerinin korunması gerekir. Ticari kullanım mümkündür. Projenin iş modeliyle uyumu yine değerlendirilmelidir.

Apache

Apache License 2.0 izin verici yapısının yanında patent hükümleriyle de bilinir. Kurumsal projelerde tercih edilebilir. NOTICE ve lisans yükümlülükleri doğru uygulanmalıdır. Dependency uyumluluğu kontrol edilmelidir. Hukuki yorum gereken durumlarda uzman görüşü alınmalıdır.

GPL ve Copyleft

GPL ailesi türev çalışmaların dağıtımı konusunda copyleft yükümlülükleri getirebilir. Bu durum kapalı kaynak ticari ürün planlarını etkileyebilir. Kullanılan GPL bileşenin nasıl entegre edildiği önemlidir. Geliştiricilerin lisansı yalnız teknik araç seçimi olarak görmemesi gerekir. Proje başlamadan lisans uyumluluğu değerlendirilmelidir.

Katkı Kabul Süreci

Dış contributor'ların pull request gönderebilmesi için teknik ve hukuki kurallar açıklanmalıdır. Review ve test gereksinimleri standartlaştırılabilir. Büyük katkılarda CLA ihtiyacı değerlendirilebilir. Contributor'ın üçüncü taraf kodu izinsiz getirmemesi beklenmelidir. Maintainer son kabul kararını repository politikasıyla verir.

Contributor Guide

Contributor Guide local setup, issue seçimi, branch ve PR sürecini açıklamalıdır. Yeni katılımcının ilk katkısını kolaylaştırır. Teknik gereksinimler güncel tutulmalıdır. Çok uzun rehber yerine adım adım başlangıç bölümü faydalıdır. Topluluk katkısını sürdürülebilir hale getirir.

Code of Conduct

Code of Conduct saygılı ve güvenli topluluk davranışı için ortak beklenti oluşturur. İhlal bildirim kanalı belirtilmelidir. Moderasyon sorumluları açık olmalıdır. Kurallar yalnız dış contributor'a değil maintainer ve ortaklara da uygulanmalıdır. Uygulamada hiç işletilmeyen belge yerine gerçek süreç oluşturulmalıdır.

Kod İnceleme

Open source PR'lar güvenlik, kalite ve lisans açısından incelenmelidir. Yeni contributor'lara yapıcı feedback verilmesi retention'ı artırır. Tek maintainer'a bağımlılık azaltılmalıdır. Otomatik testler review yükünü düşürebilir. Kritik değişikliklerde iki reviewer kuralı uygulanabilir.

Güvenlik Açığı Bildirimi

Public issue üzerinden kritik güvenlik açığı paylaşılması istenmeyebilir. SECURITY dosyasında özel bildirim kanalı tanımlanabilir. Gelen raporların sorumlusu belirlenmelidir. Düzeltme ve disclosure takvimi koordine edilmelidir. Güvenlik araştırmacılarına saygılı süreç uygulanmalıdır.

Sürüm Yönetimi

Semantic versioning veya başka uygun sürüm modeli seçilebilir. Release notları kullanıcıların değişiklikleri anlamasını sağlar. Breaking change politikası açık olmalıdır. Maintainer yetkisi kurumsal hesap üzerinden yönetilmelidir. Eski sürümlerin destek süresi belirtilebilir.

Açık Kaynak Projelerde Fikri Mülkiyet Nasıl Korunur?

Açık kaynak yayımlamak fikri mülkiyetten vazgeçmek anlamına gelmez. Copyright sahibi belirli lisans koşullarıyla başkalarına kullanım hakkı verir. Contributor hakları ve üçüncü taraf kod kullanımı açık biçimde yönetilmelidir. Kooperatif projelerinde kimin copyright sahibi olduğunun bilinmesi lisanslama yetkisinin temelidir. Open source politika ile IP politikası birbirinden bağımsız değil, birlikte tasarlanmalıdır.

Açık Kaynak ile Kamu Malı Arasındaki Fark

Açık kaynak kod lisans koşulları altında kullanıma açılır. Kamu malı yaklaşımında hak durumu farklı olabilir. Repository'nin public olması otomatik olarak açık kaynak lisansı verildiği anlamına gelmez. Lisans dosyası mutlaka bulunmalıdır. Kullanıcıların hak ve yükümlülükleri açık hale getirilmelidir.

Copyright Sahipliği

Kodu kimin yazdığı ve hangi ilişki içinde yazdığı copyright sahipliğini etkileyebilir. Çalışan, danışman ve gönüllü contribution'ları aynı değildir. Kooperatifin lisanslama yapabilmesi için gerekli hakları edinmiş olması gerekir. Contributor sözleşmeleri bu nedenle önemlidir. Repository history destekleyici kayıt sağlar fakat tek hukuki belge değildir.

Katkıda Bulunanların Hakları

Contributor kendi yazdığı kod üzerinde hak sahibi olabilir. Projeye katkı yaparken kullanılan lisans altında belirli haklar verir. Büyük projelerde Developer Certificate of Origin veya CLA gibi modeller değerlendirilebilir. Katkı politikası repository'de açık olmalıdır. Gönüllünün emeği varsayımla devredilmiş kabul edilmemelidir.

Contributor License Agreement

CLA contributor'ın projeye hangi lisans ve hakları verdiğini açıklaştırabilir. Her küçük proje için zorunlu olmayabilir. Çift lisans veya ticari lisanslama planında daha önemli hale gelebilir. CLA metni hukuki uzmanla hazırlanmalıdır. Katkı sürecini gereksiz zorlaştırmayacak dijital imza yöntemi kullanılabilir.

Üçüncü Taraf Kod Kullanımı

Contributor'ın başka projeden kopyaladığı kod lisans sorunu yaratabilir. Review sırasında provenance kontrolü yapılmalıdır. Dependency scanner yardımcı olabilir. Kod snippet'leri bile lisans yükümlülüğü taşıyabilir. Eğitim ve geliştirici rehberi riski azaltır.

Lisans Uyumluluğu

Birden fazla lisans aynı projede birbiriyle uyumsuz olabilir. Özellikle copyleft dependency'lerde dağıtım modeli dikkatle incelenmelidir. SBOM veya dependency inventory kullanılabilir. Yeni paket eklenirken otomatik policy kontrolü faydalıdır. Kritik ticari projelerde periyodik lisans denetimi yapılabilir.

Ar-Ge Kooperatifinde Proje Gelirleri Nasıl Yönetilmeli?

Proje geliri kooperatifin sürdürülebilirliği için önemli kaynak olabilir ancak dağılım yöntemi baştan belirlenmelidir. Proje ekibi maliyeti, kooperatif genel gideri, ortak altyapı ve IP payı birbirinden ayrılabilir. “Gelir gelince paylaşırız” yaklaşımı başarılı proje sonrasında en büyük çatışmalardan birini yaratır. Bütçe modeli proje başlamadan onaylanmalıdır. Kooperatif mevzuatı, vergi ve muhasebe sonuçları profesyonel uzmanlarla birlikte değerlendirilmelidir.

Proje Geliri

Proje geliri müşteri, fon veya lisans kaynağından gelebilir. Gelirin brüt tutarı dağıtılabilir net gelir değildir. Vergi, proje maliyeti ve diğer yükümlülükler dikkate alınmalıdır. Ödeme takvimi nakit akışını etkiler. Proje ekibine yapılacak ödemeler sözleşme ve muhasebe niteliğine göre yürütülmelidir.

Kooperatif Genel Gider Payı

Her proje muhasebe, yönetim, hukuk ve altyapı giderlerinden yararlanır. Bu nedenle proje bütçesinde makul genel gider payı ayrılabilir. Oran projeye ve fon kurallarına göre değişebilir. Çok yüksek pay projeyi rekabetsiz hale getirebilir. Çok düşük pay ise kooperatif operasyonunu sürdürülemez kılar.

Proje Ekibi Maliyeti

Proje ekip üyelerinin ücret ve sözleşme maliyetleri bütçede açık görülmelidir. Ortakların emek katkısı otomatik olarak ücretsiz kabul edilmemelidir. Hangi işin gönüllü, hangisinin ücretli olduğu yazılmalıdır. Uzun projelerde enflasyon ve ücret artışı riski düşünülmelidir. Gerçek maliyet bilinmeden proje fiyatı belirlemek zarar yaratabilir.

Dış Hizmet Giderleri

Laboratuvar, danışman, cloud ve hukuk gibi dış hizmetler projeye özel maliyet oluşturabilir. Satın alma yöntemi fon sağlayıcı kurallarına uygun olmalıdır. Tek tedarikçiye bağımlılık risk yaratabilir. Harcama öncesi yetki sınırı bulunmalıdır. Fatura ve sözleşmeler proje koduyla arşivlenebilir.

Ortak Altyapı Fonu

Proje gelirinin küçük bölümü ortak altyapı yatırımına ayrılabilir. GPU, test cihazı veya internal platform bu fondan desteklenebilir. Fon kullanımına ilişkin yıllık plan yönetim kurulunca hazırlanabilir. Ortakların hangi yatırımların yapıldığını görmesi şeffaflık sağlar. Kaynak yalnız bir projenin ihtiyaçlarına sürekli yönelmemelidir.

Fikri Mülkiyet Gelirleri

Patent veya yazılım lisansından elde edilen gelir farklı projelerden gelebilir. Hak sahipleri ve kooperatif arasındaki paylaşım modeli IP politikasıyla uyumlu olmalıdır. Lisans yönetimi ve patent masrafları düşülebilir. Gelirin bir bölümü yeni araştırma fonuna aktarılabilir. Vergisel sonuçlar ayrıca değerlendirilmelidir.

Proje Sonrası Gelir Dağılım İlkeleri

Ürün proje bittikten sonra yıllarca gelir üretirse dağılım sistemi devam edebilir. Proje ekibinden ayrılan kişinin haklarının durumu sözleşmede yazılmalıdır. Yeni ekiplerin bakım katkısı da dikkate alınabilir. Sabit oran yerine dönemsel royalty modeli kullanılabilir. Kooperatif hukukuyla uyum profesyonel danışmanlıkla doğrulanmalıdır.

Ortakların Katkıları Nasıl Ölçülmeli?

Kooperatif ortağının katkısı yalnız sermaye yatırımı değildir. Emek, teknik bilgi, müşteri ağı, IP, ekipman ve mentoring farklı değer biçimleridir. Bütün katkıları tek puana dönüştürmek kolay görünse de adaletsizlik yaratabilir. Katkı kaydı proje ve strateji planlamasında kullanılmalı, ortakların temel hukuki haklarını keyfî biçimde değiştirmemelidir. Belirli proje gelir paylaşımı için ayrı katkı modeli kurulabilir.

Sermaye Katkısı

Sermaye kooperatifin finansal kapasitesini destekler. Ancak yüksek sermaye katkısı her karar alanında daha fazla söz hakkı anlamına gelmeyebilir. Kooperatifin oy ve ortaklık sistemi mevzuat ve ana sözleşmeye göre işler. Proje finansmanına ek katkılar ayrı sözleşmeyle düzenlenebilir. Mali katkı açık kayıtlarda izlenmelidir.

Emek Katkısı

Ortaklar proje veya kooperatif operasyonuna emek sunabilir. Harcanan saat tek başına değeri göstermez. Görevin niteliği ve sonucu önemlidir. Ücretli iş ile gönüllü katkı ayrılmalıdır. Emek karşılığı ödeme yapılacaksa hukuki ve vergisel ilişki doğru kurulmalıdır.

Teknik Bilgi

Uzmanlık bazı projelerde sermayeden daha değerli olabilir. Teknik bilgi mentoring, architecture veya araştırma yöntemi olarak katkıya dönüşebilir. Bilginin proje üzerinde yarattığı sonuç değerlendirilmelidir. Tek kişinin uzmanlığına bağımlılık azaltılmalıdır. Knowledge sharing teşvik edilmelidir.

Fikri Mülkiyet

Ortak mevcut patent veya yazılımını projeye sunabilir. Bunun mülkiyet devri mi yoksa kullanım lisansı mı olduğu açık yazılmalıdır. Değerleme gerekiyorsa bağımsız uzman desteği alınabilir. IP katkısı proje bittikten sonra da önem taşıyabilir. Gelir paylaşımı sözleşmeyle düzenlenmelidir.

Müşteri ve İş Ağı

Ortağın yeni müşteri veya proje konsorsiyumu getirmesi ekonomik değer oluşturabilir. Referral ve iş geliştirme katkısı şeffaf biçimde kaydedilebilir. Sadece ilişki iddiası katkı sayılmamalıdır. Gerçek sözleşme veya proje sonucu önemlidir. Komisyon veya teşvik varsa önceden belirlenmelidir.

Laboratuvar / Donanım

Ortak kendi laboratuvar veya cihazını kooperatif projesine kullandırabilir. Kullanım bedeli ve sorumluluk koşulları yazılmalıdır. Ekipmanın hasar veya bakım riski düzenlenmelidir. Kooperatifin satın alması yerine paylaşım modeli ekonomik olabilir. Kullanım kayıtları proje maliyetine eklenebilir.

Proje Geliştirme

Yeni proje fikrini fonlanabilir veya satılabilir seviyeye taşımak önemli katkıdır. Yalnız fikir söylemek ile proje geliştirmek farklıdır. Müşteri görüşmesi, bütçe ve konsorsiyum oluşturma somut işlerdir. Proje kabulünde katkı sahipleri kaydedilebilir. Sonraki gelir modelinde bu katkı sözleşmeye göre dikkate alınabilir.

Mentorluk

Mentorluk genç geliştiricilerin ve yeni ortakların üretim kapasitesini artırır. Saat sayısından çok sonuç değerlendirilmelidir. Junior'ın bağımsız proje alabilmesi güçlü etkidir. Mentorluk kooperatifin insan kaynağı yatırımının parçasıdır. Yıllık etki raporunda görünür hale getirilebilir.

Ortak Kaynak ve Ar-Ge Altyapısı Yönetimi

Kooperatif modelinin somut faydalarından biri pahalı araştırma altyapısının ortak kullanımı olabilir. Laboratuvar, test cihazı, GPU ve cloud credit için kullanım politikası oluşturulmalıdır. Kaynak tahsisinde proje önceliği ve adalet dengelenmelidir. Güvenlik ve veri izolasyonu teknik olarak uygulanmalıdır. Kullanım oranları yatırımların ekonomik olup olmadığını gösterir.

Laboratuvar

Laboratuvar kullanımında güvenlik ve erişim kuralları bulunmalıdır. Cihaz yetkinliği olmayan kişiler gözetimsiz çalışmamalıdır. Proje rezervasyonu sistem üzerinden yapılabilir. Sarf malzemesi maliyetleri proje bazında izlenebilir. Üniversite ortak laboratuvarları için protokol hükümleri uygulanmalıdır.

Test Cihazları

Test cihazlarının kalibrasyon ve bakım takvimi tutulmalıdır. Hatalı cihaz araştırma sonucunu geçersiz hale getirebilir. Kullanım sonrası hasar veya arıza kayıt altına alınmalıdır. Eğitim gerektiren cihazlar için yetkili kullanıcı listesi oluşturulabilir. Yatırım kararı kullanım yoğunluğuna göre verilmelidir.

Sunucular

Sunucu kaynakları proje bazlı erişim ve kota ile yönetilebilir. Hassas projeler birbirinden izole edilmelidir. Backup ve log politikası uygulanmalıdır. Kullanılmayan kaynak düzenli temizlenebilir. On-premise ve cloud maliyeti karşılaştırılmalıdır.

GPU Kaynakları

GPU özellikle yapay zekâ projelerinde kıt ve maliyetli olabilir. Rezervasyon ve kota sistemi adil kullanım sağlar. Büyük eğitim işleri düşük kullanım saatlerine planlanabilir. Proje bazlı maliyet raporu tutulabilir. Hassas veri kullanılan eğitimlerde güvenlik koşulları ayrıca uygulanmalıdır.

Cloud Credit

Cloud credit programları başlangıçta maliyeti azaltabilir. Ancak kredi bittiğinde gerçek maliyetin ne olacağı hesaplanmalıdır. Proje ekipleri bütçe alarmı kullanmalıdır. Kişisel hesaplar yerine kurumsal cloud organizasyonu tercih edilmelidir. Veri bölgesi ve sözleşme şartları kontrol edilmelidir.

Yazılım Lisansları

Ortak lisans satın almak maliyet avantajı sağlayabilir. Kullanıcı sayısı ve lisans koşulları düzenli takip edilmelidir. Lisansın ortaklar tarafından bağımsız ticari projelerde kullanılıp kullanılamayacağı sözleşmeden kontrol edilmelidir. Open source alternatifler değerlendirilebilir. Kullanılmayan lisanslar yenilenmemelidir.

Coworking Alanları

Fiziksel ortak çalışma alanı ekipler arası bilgi akışını güçlendirebilir. Ancak sürekli ofis maliyeti gerçek kullanım yoğunluğuyla karşılaştırılmalıdır. Hibrit çalışma modeli daha ekonomik olabilir. Güvenli ağ ve toplantı alanları sağlanmalıdır. Laboratuvar içeren projelerde fiziksel alanın önemi artabilir.

Rezervasyon ve Kullanım Kotası

Kıt kaynaklarda şeffaf rezervasyon sistemi çatışmayı azaltır. Proje önceliği, fon sözleşmesi ve aciliyet kriterleri yazılmalıdır. Kotalar sürekli sabit kalmak zorunda değildir. Kullanım istatistiğine göre güncellenebilir. İstisna kararları kayıt altına alınmalıdır.

Üniversite–Sanayi–Kooperatif İşbirliği

Ar-Ge kooperatifinin güçlü modellerinden biri üniversite bilgisini sanayi problemiyle buluşturmaktır. Kooperatif proje geliştirme, operasyon ve ortak altyapı tarafında köprü görevi görebilir. Ancak her işbirliği kurumsal protokol, fikri mülkiyet ve bütçe açısından açık biçimde düzenlenmelidir. Akademisyenin kişisel danışmanlığı ile üniversite adına yürütülen proje birbirinden farklıdır. Başarılı model ortak çıktı ve bilgi transferi üretir.

Üniversitelerle Protokoller

Protokoller ortak proje, laboratuvar ve eğitim alanlarını tanımlayabilir. Genel niyet protokolü tek başına somut proje sözleşmesinin yerine geçmez. IP ve mali şartlar proje bazında ayrıca yazılabilir. Yetkili imza süreçleri kurumlar arasında farklı olabilir. Gerçek uygulama takvimi olmayan protokoller sembolik kalabilir.

Akademisyen Katılımı

Akademisyenler danışman, araştırmacı veya proje ortağı olarak farklı biçimde yer alabilir. Üniversite mevzuatı ve izin süreçleri dikkate alınmalıdır. Yayın ve patent beklentileri baştan konuşulmalıdır. Proje zamanı gerçekçi planlanmalıdır. Akademik katkı yalnız isim eklemekten ibaret olmamalıdır.

Öğrenci Projeleri

Öğrenciler tez, staj veya bitirme projesi yoluyla kooperatif çalışmalarına katılabilir. Eğitim hedefleri ticari teslimat baskısının önüne geçmemelidir. Veri ve IP koşulları öğrenciye açık anlatılmalıdır. Mentor atanmalıdır. Başarılı öğrenciler mezuniyet sonrası proje ekibine katılabilir.

Ortak Laboratuvar

Üniversite laboratuvarıyla ortak kullanım yüksek ekipman maliyetini azaltabilir. Rezervasyon, sorumluluk ve sarf malzemesi kuralları protokolde yazılmalıdır. Ticari proje kullanımına izin verilip verilmediği net olmalıdır. Verilerin laboratuvar sisteminde saklanması güvenlik açısından değerlendirilmelidir. Cihaz bakım sorumluluğu açık tutulmalıdır.

Tez ve Araştırma Projeleri

Kooperatif gerçek sektör problemlerini tez konusuna dönüştürebilir. Akademik bağımsızlık korunmalıdır. Gizli bilgi ve yayın zamanı önceden konuşulmalıdır. Sonucun ürünleşmesi halinde IP paylaşımı ayrıca düzenlenmelidir. Tez öğrencisi yalnız ücretsiz Ar-Ge personeli olarak görülmemelidir.

Teknoloji Transfer Ofisleri

TTO'lar proje, patent ve üniversite işbirliği süreçlerinde destek sağlayabilir. Akademik buluşların ticarileştirilmesi için kurumsal kanal oluştururlar. Kooperatif TTO ile düzenli proje görüşmesi yapabilir. Yetki ve gelir paylaşım şartları üniversite politikalarına göre değişebilir. Erken iletişim sonradan yaşanacak IP sorunlarını azaltır.

Teknokent İşbirliği

Teknokentler girişim ve Ar-Ge şirketleriyle bağlantı sağlayabilir. Kooperatif üyeleri için proje ve mentorluk fırsatları oluşabilir. Vergi veya teşvik avantajları otomatik olarak kooperatife uygulanıyor varsayılmamalıdır. Somut faaliyet ve mevzuat uygunluğu ayrıca incelenmelidir. İşbirliği etkinlikten çok ortak proje üretimine yönelmelidir.

Ortak Fon Başvuruları

Üniversite ve sanayi ortak fon başvurularında farklı rol ve bütçeler üstlenebilir. Konsorsiyum sözleşmesi hazırlanmalıdır. IP ve yayın hakları başvuru öncesi konuşulmalıdır. Proje yönetim sorumluluğu net olmalıdır. Fon şartları ana sözleşme ve kooperatif kapasitesiyle uyumlu olmalıdır.

Diyarbakır Yazılım Topluluğu ve Ar-Ge Kooperatifi Modeli

Diyarbakır'daki yazılım topluluğu yapısı yerel geliştiricileri, akademiyi ve işletmeleri ortak projelerde buluşturmak için önemli bir başlangıç noktası oluşturabilir. Kooperatif modeli düşünüldüğünde topluluk faaliyetleriyle ekonomik proje faaliyetleri birbirinden ayrılmalıdır. Diyarbakır Yazılım Topluluğu'nun mevcut yapısı ve yaklaşımı hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alınabilir. Mevcut proje çalışmalarını incelemek için https://www.diyarbakiryazilim.com.tr/projects sayfası kullanılabilir. Yerel sanayiyle dijital dönüşüm işbirliği perspektifini geliştirmek isteyenler için https://www.diyarbakiryazilim.com.tr/posts/sanayi-odalari-ile-is-birliginde-yerel-dijital-donusum-stratejileri içeriği de yararlı bir devam noktasıdır.

Yerel Yazılım Yeteneğini Ortak Projelere Dönüştürmek

Yerel geliştirici yeteneği çoğu zaman farklı şirket veya bireysel projelerde dağınık bulunur. Kooperatif ortak proje mekanizmasıyla bu uzmanlıkları belirli sanayi problemleri etrafında birleştirebilir. Geliştiricilerin kooperatif ortağı olması tek katılım modeli değildir. Proje çalışanı, mentor veya open source contributor rolleri de kullanılabilir. Yetkinlik ve ilgi alanı veri tabanı proje ekiplerinin daha hızlı kurulmasını sağlar.

Topluluk ile Kooperatif Arasındaki İş Bölümü

Topluluk ücretsiz etkinlik, networking ve açık öğrenme alanında çalışabilir. Kooperatif sözleşmeli Ar-Ge projesi, ortak altyapı ve ticarileştirme faaliyetlerini yürütebilir. Marka kullanımı ve iletişim dili açık biçimde ayrılmalıdır. Gönüllü topluluk emeğinin ticari projeye aktarılması halinde katılımcı onayı ve sözleşme gerekir. Bu iş bölümü her iki yapının güçlü yönünü korur.

Açık Kaynak Proje Havuzu

Topluluk ve kooperatif ortak açık kaynak proje havuzu oluşturabilir. Her projenin lisansı, maintainer'ı ve hedefi açık olmalıdır. Junior geliştiriciler küçük issue'larla katılım sağlayabilir. Kooperatif ticari projelerinde kullanılacak open source bileşenler IP politikasıyla uyumlu olmalıdır. Başarılı projeler bölgesel teknoloji görünürlüğünü artırabilir.

Akademi–Topluluk–Özel Sektör İşbirliği

Üç taraf farklı kaynak sağlar. Akademi araştırma, topluluk yetenek ve özel sektör gerçek problem getirebilir. Kooperatif bu ilişkide proje ve sözleşme yönetimi sağlayabilir. Her tarafın hak ve sorumluluğu proje bazında yazılmalıdır. Başarı etkinlik sayısıyla değil ortak projelerin sonuçlarıyla ölçülmelidir.

Yerel Firmaların Ar-Ge Problemlerinin Toplanması

Yerel firmalarla problem discovery görüşmeleri yapılabilir. Şirketlerden “hangi yazılımı istiyorsunuz?” yerine hangi operasyon veya teknoloji problemini yaşadıkları sorulmalıdır. Benzer sorunlar ortak Ar-Ge projesine dönüşebilir. Ticari sır içeren bilgiler gizlilik altında toplanmalıdır. Problem havuzu yıllık proje portföyünün önemli girdisi olabilir.

Ortak Araştırma Ekipleri

Bir projede üniversite araştırmacısı, yerel geliştirici ve sektör uzmanı birlikte çalışabilir. Proje yürütücüsü koordinasyonu sağlamalıdır. Görev ve IP paylaşımı başlangıçta belirlenmelidir. Ortak ekip modeli bilgi transferini hızlandırır. Proje sonunda öğrenilen yöntemler uygun ölçüde toplulukla paylaşılabilir.

Mentorluk ve Teknik Eğitim

Deneyimli geliştiriciler ve akademisyenler düzenli mentoring programına katkı sunabilir. Eğitimler gerçek proje ihtiyaçlarına bağlanmalıdır. Yeni katılımcıların yalnız seminer dinlemek yerine uygulama yapması sağlanmalıdır. Open source contribution güçlü öğrenme çıktısı olabilir. Mentoring programının etkisi katılımcıların ilerleyen dönemde bağımsız proje rolü üstlenmesiyle görülebilir.

Diyarbakır'daki Yazılımcılar Ar-Ge Projelerine Nasıl Dahil Edilmeli?

Ar-Ge projelerine geliştirici seçerken “en iyi yazılımcı” gibi belirsiz etiketler yerine proje ihtiyacına uygun yetkinlik matrisi kullanılmalıdır. GitHub ve portföy yararlı veri sunabilir fakat tek kriter olmamalıdır. Araştırma yöntemi, takım çalışması ve dokümantasyon becerisi bazı projelerde kod hızından daha önemlidir. Junior ve senior adaylar farklı rol beklentileriyle değerlendirilmelidir. Açık başvuru ve şeffaf proje görevleri yerel yetenek havuzunu genişletir.

“En İyi Yazılımcı” Yerine Yetkinlik Matrisi

Yetkinlik matrisi teknoloji, domain, araştırma ve collaboration alanlarını ayrı değerlendirir. Proje hangi yetkinliği gerektiriyorsa aday buna göre seçilir. Her geliştiricinin her alanda üst seviye olması gerekmez. Ekip olarak tamamlayıcılık daha önemlidir. Matris eğitim planını da destekleyebilir.

GitHub ve Portföy

GitHub gerçek kod ve collaboration örnekleri sunabilir. Ancak private projelerde çalışan kişinin public contribution'ı az olabilir. Commit sayısı kalite göstergesi değildir. README, review ve tasarım kararları daha anlamlı olabilir. Portföy aday görüşmesinde teknik tartışma başlangıcı olarak kullanılmalıdır.

Araştırma Deneyimi

Ar-Ge projelerinde hipotez kurma ve deney tasarlama becerisi önemlidir. Akademik deneyim avantaj olabilir fakat zorunlu değildir. Geliştiricinin belirsiz problemle nasıl çalıştığı sorulabilir. PoC ve benchmark hazırlama deneyimi değerlidir. Araştırma sonucu olumsuz çıktığında öğrenmeyi dokümante edebilmesi beklenir.

Proje Deneyimi

Adayın daha önce hangi sorumlulukları taşıdığı incelenmelidir. Projenin büyüklüğünden çok somut rol önemlidir. Production sorumluluğu ve müşteriye teslim deneyimi farklı değerler taşır. Başarısız proje deneyiminden ne öğrendiği sorulabilir. Deneyim bağlama göre değerlendirilmelidir.

Teknik Uzmanlık

Teknik uzmanlık proje ihtiyacına göre seçilmelidir. Backend, AI, embedded veya security farklı beceriler gerektirir. Teknoloji adı bilmek tek başına yeterli değildir. Problem çözme ve debugging yetkinliği de test edilmelidir. Uzmanın bilgisini ekiple paylaşma becerisi önemlidir.

Takım Çalışması

Ar-Ge projeleri farklı disiplinlerin birlikte çalışmasını gerektirir. İletişim ve feedback alma becerisi teknik yetkinlik kadar önem kazanabilir. Pairing veya küçük takım çalışması değerlendirme sürecine eklenebilir. Bireysel yarışma kültüründen kaçınılmalıdır. Takım başarısı ortak outcome üzerinden değerlendirilmelidir.

Açık Kaynak Katkısı

Open source contribution collaboration ve kod kalitesi hakkında değerli sinyal olabilir. Ancak zorunlu seçim kriteri yapılmamalıdır. İş ve aile koşulları kişilerin gönüllü contribution fırsatını etkiler. Katkı varsa issue, review ve documentation da incelenmelidir. Kooperatif open source projeleriyle yeni geliştiricilere katkı alanı sağlayabilir.

Mentorluk Yetkinliği

Senior geliştirici yalnız kendi koduyla değil başkalarının gelişimiyle değer üretir. Mentorluk yetkinliği teknik açıklama ve sabır gerektirir. Junior'ların bağımsızlaşması iyi sonuç göstergesidir. Mentor sayısı sınırlıysa proje onboarding kapasitesi düşebilir. Bu nedenle senior seçiminde mentoring kapasitesi dikkate alınabilir.

Ar-Ge Kooperatifinin Finansman Kaynakları

Sürdürülebilir kooperatif tek fon kaynağına bağlı olmamalıdır. Ortak sermayesi, hizmet geliri, proje geliri, sponsorluk, fon ve lisans gelirleri farklı kombinasyonlarda kullanılabilir. Hibe gelirlerini sürekli işletme giderinin tek kaynağı yapmak risklidir. Ticari gelir ile araştırma finansmanı arasında denge kurulmalıdır. Her finansman türünün sözleşme ve raporlama yükümlülüğü ayrıca değerlendirilmelidir.

Ortak Sermayesi

Kuruluş sermayesi ilk operasyon giderlerini karşılamaya yardımcı olur. Yalnız asgari yasal yükümlülüğü karşılayan sermaye gerçek iş planı için yetersiz kalabilir. İlk on iki aylık nakit ihtiyacı ayrıca hesaplanmalıdır. Ek sermaye veya başka finansman gerekebilir. Ortak katkıları şeffaf kaydedilmelidir.

Hizmet Gelirleri

Danışmanlık, eğitim ve teknoloji geliştirme hizmetleri düzenli gelir sağlayabilir. Hizmet faaliyeti kooperatifin Ar-Ge odağını tamamen tüketmemelidir. Belirli bölüm araştırma fonuna aktarılabilir. Proje fiyatlaması gerçek maliyeti kapsamalıdır. Müşteri sözleşmeleri standartlaştırılabilir.

Ar-Ge Proje Gelirleri

Fonlu veya müşteri destekli Ar-Ge projeleri temel finansman kaynağı olabilir. Ödeme takvimi nakit akışına göre planlanmalıdır. Eş finansman gereken programlar ayrıca kaynak gerektirir. Proje gelirleri amacı dışında kullanılmamalıdır. Raporlama yükümlülükleri proje ekibi tarafından baştan bilinmelidir.

Kurumsal Sponsorluk

Sponsor şirketler eğitim, araştırma veya açık kaynak programlarını destekleyebilir. Sponsorluk karşılığında ne sunulduğu açık sözleşmeyle belirlenmelidir. Sponsorun proje sonuçlarına uygunsuz kontrol sağlamasına izin verilmemelidir. Marka kullanım kuralları yazılmalıdır. Bilimsel bağımsızlık korunmalıdır.

Ulusal Destek Programları

Ulusal fon programları kooperatifin proje niteliğine göre değerlendirilebilir. Her program kooperatif türünü uygun başvuru sahibi kabul etmeyebilir. Güncel çağrı koşulları tek tek incelenmelidir. Uygunluk doğrulanmadan proje bütçesi fon varmış gibi planlanmamalıdır. Başvuru ve raporlama kapasitesi kurumsallaştırılabilir.

Uluslararası Fonlar

Uluslararası fonlar daha büyük konsorsiyum ve araştırma imkânı sağlayabilir. İngilizce proje yönetimi ve mali raporlama kapasitesi gerekir. Consortium agreement ve IP şartları önemlidir. Kur farkı ve ödeme takvimi risk oluşturabilir. İlk uluslararası proje için deneyimli danışman veya partner desteği faydalı olabilir.

Üniversite ve Sanayi Projeleri

Üniversite ve sanayi ortak projeleri farklı finansman kaynaklarını birleştirebilir. Kooperatif proje yönetimi veya teknoloji geliştirme rolü üstlenebilir. Görev ve bütçe dağılımı baştan belirlenmelidir. Üniversite IP politikası ayrıca dikkate alınmalıdır. Proje sonrası ticarileştirme planı sözleşmeye yansıtılabilir.

Fikri Mülkiyet Lisans Gelirleri

Patent veya yazılım lisanslama tekrarlayan gelir yaratabilir. Bunun için kooperatifin lisanslama yetkisine sahip olması gerekir. Royalty takibi düzenli yapılmalıdır. Lisans sözleşmelerindeki performans şartları izlenmelidir. Gelirin bir bölümü yeni araştırma yatırımlarına ayrılabilir.

Fon ve Hibe Başvuruları Nasıl Yönetilmeli?

Fon başvurusu son gün hazırlanan belge işi olmamalıdır. Çağrı takibi, uygunluk, konsorsiyum, bütçe ve teknik içerik ayrı iş akışları olarak yönetilebilir. Her başvurunun yönetim kurulunca mali ve hukuki açıdan onaylanması faydalıdır. Gerçekçi olmayan KPI ve proje çıktıları ileride raporlama riski yaratır. Başvuru kabul edilirse proje sözleşmesi ve iç proje planı birbiriyle uyumlu hale getirilmelidir.

Çağrı Takibi

Ulusal ve uluslararası çağrılar düzenli veri tabanında izlenebilir. Son başvuru tarihi, uygunluk ve tema kaydedilir. Her çağrı için proje üretmek yerine portföyle eşleşme aranmalıdır. Aylık fon toplantısı yeterli olabilir. Danışma kurulu stratejik çağrılar hakkında görüş sunabilir.

Uygunluk Kontrolü

Kooperatifin başvuru sahibi veya ortak olarak uygun olup olmadığı resmi çağrı metninden kontrol edilmelidir. Sektör, kuruluş tarihi veya mali kapasite şartları bulunabilir. Varsayıma dayalı başvuru zaman kaybına neden olur. İhtiyaç halinde program yetkilisinden yazılı açıklama alınabilir. Uygunluk kaydı proje dosyasında saklanmalıdır.

Proje Konsorsiyumu

Konsorsiyum yalnız güçlü isimlerden değil gerçek görev paylaşımı yapabilecek partnerlerden oluşmalıdır. Her partnerin bütçesi ve deliverable'ı açık olmalıdır. Koordinatörlük önemli idari kapasite gerektirir. IP ve yayın hükümleri consortium agreement içinde detaylandırılabilir. Partner değişim riski için yedek plan düşünülebilir.

Bütçe

Proje bütçesi teknik planın finansal yansımasıdır. Gerçek personel, cihaz ve hizmet maliyetleri kullanılmalıdır. Uygun olmayan giderler fon tarafından reddedilebilir. Eş finansman gereksinimi nakit akışına eklenmelidir. Bütçe yalnız proje yazarı tarafından değil mali sorumlu tarafından da kontrol edilmelidir.

Görev Dağılımı

Her work package ve deliverable için sorumlu belirlenmelidir. Aynı kişi bütün kritik işleri üstlenmemelidir. Akademik ve teknik görevler gerçek kapasiteye göre dağıtılmalıdır. Proje takvimi izin ve satın alma sürelerini içermelidir. Görev matrisi başvuru sonrası execution planına dönüşür.

Proje Yazımı

Proje metni teknik iddia ile ölçülebilir hedefleri bağlamalıdır. Genel teknoloji ifadeleri yerine problem ve yöntem açıklanmalıdır. Ar-Ge niteliği açık biçimde ortaya konmalıdır. Bütçe ve iş paketleri metinle uyumlu olmalıdır. Son kontrol farklı bir uzman tarafından yapılabilir.

Başvuru Onayı

Kooperatif adına yapılan başvuru mali ve hukuki taahhüt yaratabilir. Bu nedenle yetkili yönetim organının onayı alınmalıdır. İmza yetkisi kontrol edilmelidir. Konsorsiyum sorumlulukları karar öncesi okunmalıdır. Başvurunun son dakikada imzaya getirilmesi yönetişim riskidir.

Proje Sonrası Raporlama

Fon kabul edildiğinde raporlama takvimi proje planına eklenmelidir. Teknik ve mali veri proje boyunca toplanmalıdır. Son hafta geriye dönük belge aramak hata riskini artırır. Deliverable sahipleri belirlenmelidir. Proje kapandıktan sonra audit ve saklama süresi devam edebilir.

Ar-Ge Kooperatifinde Araştırma Etiği

Araştırma etiği kooperatifin bilimsel güvenilirliğinin temelidir. Veri manipülasyonu, intihal ve yazarlık anlaşmazlıkları yalnız akademik kurumların konusu değildir. Ürün ve ticari Ar-Ge çalışmalarında da veri doğruluğu karar kalitesini etkiler. Etik ihlal bildirim mekanizması güvenli ve tarafsız olmalıdır. Proje liderleri sonuç baskısı altında olumsuz deneyleri gizlememelidir.

Bilimsel Dürüstlük

Araştırma sonuçları gerçek veri ve yöntemle raporlanmalıdır. Hedeflenen sonuç çıkmadığında veri değiştirilmemelidir. Olumsuz sonuç da yeni bilgi üretir. Deney kayıtları tekrar incelenebilir biçimde tutulmalıdır. Fon ve müşteri raporlarında aynı dürüstlük standardı uygulanmalıdır.

Veri Manipülasyonu

Sonucu daha olumlu göstermek için veri silmek veya değiştirmek ciddi etik sorundur. Data cleaning işlemleri belgelenmelidir. Outlier çıkarma kriteri sonuca göre değişmemelidir. Otomatik analiz pipeline'ı versiyonlanabilir. Kritik çalışmalarda bağımsız review yapılabilir.

İntihal

Başka kişilerin metin, kod veya araştırma fikrini kaynak göstermeden kullanmak etik ve hukuki risk yaratır. Kodda lisans yükümlülükleri ayrıca önemlidir. AI araçları tarafından verilen metinlerin kaynağı da kontrol edilmelidir. Akademik yayınlarda atıf standartları uygulanmalıdır. Eğitim programlarında bu konu açıkça öğretilmelidir.

Yazarlık ve Katkı

Akademik veya teknik yayınlarda yazar listesi gerçek katkıya dayanmalıdır. Yönetici olduğu için otomatik yazar eklemek doğru değildir. Katkı rolleri proje boyunca kaydedilebilir. Yazarlık anlaşmazlığı yayın sonuna bırakılmamalıdır. Açık katkı standardı ekip güvenini artırır.

İnsan ve Araştırma Verileri

İnsan katılımcı veya kişisel veri içeren araştırmalar özel etik ve hukuki yükümlülük doğurabilir. Gerekli etik kurul ve açık rıza süreçleri proje türüne göre değerlendirilmelidir. Veri minimizasyonu uygulanmalıdır. Hassas veriye erişim sınırlandırılmalıdır. Araştırma amacı dışında kullanım yapılmamalıdır.

Çıkar Çatışmaları

Araştırmacının proje sonucundan doğrudan ekonomik fayda sağlaması tarafsızlığı etkileyebilir. Bu durum beyan edilmelidir. Değerlendirme ve yayın süreçlerinde bağımsız review kullanılabilir. Çatışma her zaman projeyi durdurmayı gerektirmez. Şeffaf yönetim yeterli olabilir.

Etik İhlal Bildirim Mekanizması

Çalışan ve araştırmacılar güvenli kanaldan ihlal bildirebilmelidir. Misilleme korkusu olmamalıdır. Bildirimler yetkili ve tarafsız kişilerce incelenmelidir. Asılsız iddia ile iyi niyetli ihbar ayrılmalıdır. Sonuç ve gerekli düzeltme kayıt altına alınmalıdır.

Yapay Zekâ Kullanım Politikası

Ar-Ge kooperatiflerinde AI araçları kod, araştırma ve veri analizi için yaygın biçimde kullanılabilir. Ancak gizli müşteri verisinin dış servislere aktarılması, hatalı kaynak üretimi ve lisans belirsizliği gibi riskler vardır. Politika “AI yasaktır” veya “her yerde kullanın” kadar basit olmamalıdır. Veri sınıfına göre hangi araçların kullanılabileceği belirlenebilir. İnsan denetimi bütün önemli teknik ve bilimsel çıktılarda korunmalıdır.

AI ile Kod Üretimi

AI destekli coding araçları boilerplate ve araştırma süresini azaltabilir. Üretilen kod review ve test sürecinden geçmelidir. Geliştirici anlamadığı kodu production'a taşımamalıdır. Güvenlik ve lisans riski kritik projelerde ayrıca kontrol edilmelidir. AI kullanımı code ownership sorumluluğunu ortadan kaldırmaz.

AI ile Araştırma ve Veri Analizi

AI literatür taraması ve veri analizi için yardımcı olabilir. Üretilen kaynak ve istatistikler doğrulanmalıdır. Model halüsinasyonu bilimsel rapora yanlış bilgi taşıyabilir. Hassas araştırma verisi onaysız dış araca yüklenmemelidir. Yöntem bölümünde AI kullanımının açıklanması gerektiği durumlar proje ve yayın politikasına göre belirlenebilir.

Gizli Verilerin AI Araçlarına Aktarılması

Müşteri kaynak kodu veya kişisel veri public AI servislerine kopyalanmamalıdır. Kurumsal sözleşmeli araçların veri kullanma koşulları incelenmelidir. Data classification politikası hangi bilginin hangi araca gidebileceğini açıklamalıdır. Geliştiricilere somut örnekler verilmelidir. DLP ve erişim politikaları teknik koruma sağlayabilir.

Kaynak ve Atıf Kontrolü

AI tarafından verilen akademik kaynaklar gerçek olmayabilir. Her atıf orijinal kaynaktan doğrulanmalıdır. Kod örneğinin lisans durumu belirsizse doğrudan kopyalanmamalıdır. Araştırmacı nihai içeriğin sorumluluğunu taşır. AI çıktısı bağımsız bilimsel kaynak yerine kullanılamaz.

İnsan Denetimi

AI çıktıları özellikle kritik teknik kararlarda insan uzman tarafından gözden geçirilmelidir. Model önerisi karar gerekçesi değildir. Safety, security ve finansal etki yüksek alanlarda ek review gerekir. Otomasyon hatayı ölçekleyebileceği için kontrol önemlidir. İnsan denetimi projenin sorumlu kişisini ortadan kaldırmaz.

AI Çıktılarının Fikri Mülkiyet Boyutu

AI çıktılarının hak sahipliği ve eğitim verisiyle ilişkisi kullanılan araç ve hukuk alanına göre değişebilir. Ticari projede sağlayıcının kullanım şartları okunmalıdır. AI tarafından üretilen içeriğe güvenerek patent veya copyright stratejisi kurulmadan uzman görüşü alınmalıdır. Hassas ürünlerde provenance kayıtları tutulabilir. Politika teknolojik ve hukuki gelişmelere göre düzenli güncellenmelidir.

Veri Yönetişimi ve Siber Güvenlik

Ar-Ge kooperatifleri kaynak kod, müşteri verisi, araştırma sonucu ve ticari sır gibi yüksek değerli bilgi işler. Veri yönetişimi projenin sonuna bırakılmamalıdır. Hangi verinin hassas olduğu, kimlerin erişebileceği ve ne kadar süre saklanacağı belirlenmelidir. Repository ve cloud güvenliği kurumsal hesaplarla yönetilmelidir. Proje sona erdiğinde veri devri veya güvenli silme prosedürü uygulanmalıdır.

Araştırma Verisinin Sınıflandırılması

Veri açık, iç kullanım, gizli ve çok hassas gibi seviyelere ayrılabilir. Her sınıf için depolama ve paylaşım kuralı belirlenir. Bütün veriyi en yüksek seviyede sınıflandırmak iş akışını gereksiz zorlaştırabilir. Proje sahibi sınıflandırmadan sorumlu olabilir. Yeni veri türü ortaya çıktığında sınıf güncellenebilir.

Erişim Yetkileri

Minimum yetki prensibi uygulanmalıdır. Proje çalışanı yalnız ihtiyacı olan repository ve veriye erişmelidir. Ayrılan kişinin erişimi aynı gün kapatılmalıdır. Admin hesapları sınırlı tutulmalıdır. Düzenli access review yapılabilir.

Veri Saklama

Her verinin süresiz saklanması gerekli değildir. Sözleşme, fon veya mevzuat saklama süresi getirebilir. Süresi dolan gereksiz kişisel veri silinmelidir. Araştırma tekrar üretilebilirliği için gerekli veri ayrı değerlendirilebilir. Retention policy yazılı olmalıdır.

Yedekleme

Kritik repository ve araştırma verisi yedeklenmelidir. Yalnız backup almak yeterli değildir, geri yükleme testi yapılmalıdır. Ransomware riskine karşı ayrı veya immutable kopya değerlendirilebilir. Proje önemi RPO ve RTO hedefini belirler. Backup erişimleri de korunmalıdır.

Kişisel Veriler

KVKK kapsamına giren kişisel veriler için hukuki işleme şartı ve güvenlik yükümlülükleri değerlendirilmelidir. Gereksiz veri toplanmamalıdır. Test ortamlarında gerçek kişisel veri kullanımı azaltılmalıdır. Erişim logları tutulabilir. Uluslararası servis kullanımı veri aktarımı açısından ayrıca incelenmelidir.

Ticari Sırlar

Müşteri veya ortakların ticari sırları proje verisinden ayrı sınıflandırılabilir. NDA tek başına teknik koruma sağlamaz. Erişim, şifreleme ve paylaşım kontrolü gerekir. Danışma kurulu üyelerinin erişimi de ihtiyaca göre sınırlandırılmalıdır. Proje sonunda veri iade veya silme şartı uygulanmalıdır.

Repository Güvenliği

Kurumsal repository hesaplarında MFA ve branch protection uygulanabilir. Secret'lar kod içine yazılmamalıdır. Dependency ve vulnerability taraması yapılabilir. Dış contributor izinleri minimum tutulmalıdır. Backup ve ownership kurumsal hesapta kalmalıdır.

Proje Sonunda Veri Devri veya Silme

Müşteri projesinde verinin kime teslim edileceği sözleşmede yazılmalıdır. Yasal veya teknik saklama gereği yoksa gereksiz kopyalar silinmelidir. Backup sistemindeki retention ayrıca kontrol edilmelidir. Devir işlemi tutanakla kayıt altına alınabilir. Araştırma verisinin anonimleştirilmiş kopyasının saklanması gerekiyorsa hukuki dayanak değerlendirilmelidir.

Proje Performansı Nasıl Ölçülmeli?

Ar-Ge projesinin başarısı yalnız zamanında tamamlanma değildir. Teknik kilometre taşları, prototip, MVP, patent, yayın, open source çıktı ve ticari sonuç farklı proje tiplerinde kullanılabilir. Başarısız deney de doğrulanmış öğrenme üretiyorsa değerli olabilir. Ölçütler proje başlangıcında belirlenmelidir. Fon sağlayıcının KPI'ları kooperatifin kendi öğrenme ve ekonomik etki göstergeleriyle birlikte izlenebilir.

Teknik Kilometre Taşları

Teknik milestone ölçülebilir sonuç içermelidir. “AI modülü geliştirilecek” yerine belirli doğruluk veya performans testi tanımlanabilir. Her milestone kabul kriterine sahip olmalıdır. Riskli milestone'lar erken tarihe konabilir. Gecikme halinde proje planı güncellenmelidir.

Prototip

Prototip teknik veya kullanıcı hipotezini düşük maliyetle test eder. Production kalitesi hedeflenmeyebilir. Hangi soruya cevap verdiği açık olmalıdır. Prototip sonucu yeni proje kararına dönüşmelidir. Başarısız prototip de değerli teknik bilgi üretir.

MVP

MVP gerçek kullanıcıya minimum değer sunarak ürün hipotezini test eder. Prototipten farklı olarak gerçek kullanım davranışı ölçülebilir. Ar-Ge projesinde araştırma çıktısının ürünleşme aşaması olabilir. Başarı metriği önceden belirlenmelidir. Kullanıcı geri bildirimi sonraki yatırım kararını şekillendirir.

Patent

Patent başvurusu bazı projelerde güçlü çıktı olabilir. Ancak başvuru sayısı tek başına etkiyi göstermez. Patent koruma ve ticarileştirme stratejisiyle ilişkili olmalıdır. Maliyet ve pazar önemi değerlendirilmelidir. Her proje patent hedeflemek zorunda değildir.

Akademik Yayın

Yayın araştırma kalitesini ve görünürlüğü artırabilir. Hakemli yayın süreçleri uzun sürebilir. Patent öncesi açıklama riski kontrol edilmelidir. Ortakların yazarlık katkısı şeffaf belirlenmelidir. Yayın sayısı tek başarı göstergesi olarak kullanılmamalıdır.

Açık Kaynak Çıktısı

Open source kütüphane veya araç community impact üretebilir. Star sayısı tek başına başarı değildir. Aktif contributor ve gerçek kullanım daha anlamlıdır. Güvenlik ve bakım sorumluluğu devam eder. Projenin lisans stratejisi ekonomik hedefle uyumlu olmalıdır.

Ticari Ürün

Ar-Ge çıktısının ürüne dönüşmesi önemli ticarileştirme sonucudur. Satış, kullanıcı ve retention verileri izlenebilir. İlk gelir tek başına uzun vadeli başarı değildir. Product-market fit ayrıca değerlendirilmelidir. Teknik ekip bakım ve support kapasitesini planlamalıdır.

Oluşturulan İstihdam

Yeni araştırmacı ve geliştirici istihdamı bölgesel etki göstergesi olabilir. Sadece kişi sayısı değil sürdürülebilir istihdam önemlidir. Junior programlardan işe geçiş ayrıca ölçülebilir. Proje bitince bütün kadronun dağılması sürdürülebilirlik açısından risklidir. İnsan kaynağı etkisi yıllık raporda gösterilebilir.

Elde Edilen Fon

Fon miktarı projenin kaynak çekme kapasitesini gösterir. Ancak alınan fon kullanıcı veya bilimsel etki üretmediyse tek başına başarı değildir. Fon başına çıktı değerlendirilebilir. Proje raporlama performansı da önemlidir. Strateji yalnız fon büyüklüğüne göre yönetilmemelidir.

Ar-Ge Kooperatifinin Yıllık Performansı Nasıl Ölçülmeli?

Kooperatifin yıllık performansı mali gelirden daha geniş çerçevede değerlendirilmelidir. Aktif ve tamamlanan projeler, IP, open source, üniversite işbirliği, yeni ortaklar ve bölgesel etki birlikte raporlanabilir. Aynı göstergelerin yıllar içindeki trendi stratejik bilgi sağlar. Sayıların arkasındaki proje kalitesi ve ekonomik sürdürülebilirlik unutulmamalıdır. Yıllık şeffaflık ve etki raporu ortaklar ile paydaşlar arasındaki güveni güçlendirir.

Aktif Ar-Ge Projesi Sayısı

Aktif proje sayısı kapasite kullanımını gösterir. Çok fazla eşzamanlı proje ekip odağını dağıtabilir. Proje büyüklüğü ve bütçesi de değerlendirilmelidir. WIP sınırı portföy seviyesinde uygulanabilir. Kaliteli az proje bazen daha fazla etki üretir.

Tamamlanan Projeler

Tamamlanan proje sayısı teslimat kapasitesini gösterir. Başarısız kapatılan projeler de doğru nedenlerle kapatılmışsa öğrenme çıktısı taşır. Süre, bütçe ve teknik hedef birlikte değerlendirilebilir. Proje sonrası dersler kaydedilmelidir. Tamamlama oranını artırmak uğruna düşük değerli projeler seçilmemelidir.

Ticarileşen Projeler

Ürüne, lisansa veya müşteri hizmetine dönüşen projeler ekonomik etki sağlar. Ticarileşme oranı proje türüne göre farklı olabilir. Temel bilim projelerini aynı kriterle değerlendirmek doğru değildir. Gelir ve kullanıcı etkisi ayrıca izlenebilir. Ticarileştirme süresi uzun olabileceği için çok yıllı trend değerlidir.

Patent ve Fikri Haklar

Patent, tasarım ve yazılım portföyü kurumsal varlık oluşturabilir. Sayı kadar kullanım ve lisans geliri önemlidir. Süresi geçmiş veya ekonomik değeri olmayan haklar maliyet yaratabilir. Yıllık IP portföy review yapılabilir. Açık kaynak stratejisi de aynı raporda yer alabilir.

Açık Kaynak Katkıları

Kooperatifin yayımladığı veya katkı yaptığı open source projeler bilgi paylaşımı etkisi oluşturur. Contributor ve adoption verisi kullanılabilir. Yalnız repository sayısı yeterli değildir. Bakımı yapılmayan projeler arşivlenebilir. Topluluk katkısı bölgesel yetenek gelişimiyle ilişkilendirilebilir.

Üniversite İşbirlikleri

Ortak araştırma, tez ve laboratuvar projeleri sayılabilir. Protokol sayısından çok somut çıktı önemlidir. Ortak yayın veya ürün güçlü kanıt sağlar. Öğrenci katılımı ayrıca ölçülebilir. İşbirliği memnuniyeti yıllık görüşmeyle değerlendirilebilir.

Yeni Ortaklar

Yeni ortak sayısı büyümeyi gösterir ancak tek başına başarı değildir. Aktif olmayan çok sayıda ortak yönetişim yükü yaratabilir. Ortakların proje ve kaynak kullanım katılımı incelenmelidir. Çıkış oranı da önemli sinyaldir. Nitelikli ve amaç uyumlu büyüme hedeflenmelidir.

Proje Gelirleri

Proje geliri ekonomik sürdürülebilirliğin önemli göstergesidir. Brüt gelir yerine maliyet sonrası katkı da analiz edilmelidir. Tek müşteriye bağımlılık ayrıca izlenmelidir. Gelirin ne kadarının yeni Ar-Ge'ye yatırıldığı gösterilebilir. Nakit akışı yıllık gelirden farklı olarak değerlendirilmelidir.

Bölgesel Ekonomik Etki

Yerel istihdam, yerel firma işbirliği ve yeni teknoloji ürünleri bölgesel etki oluşturabilir. Etki ölçümü iddialı genel ifadeler yerine gerçek veriye dayanmalıdır. Kaç firmaya pilot yapıldığı ve kaç yeni teknik iş oluştuğu raporlanabilir. Üniversite mezunlarının bölgede kalması uzun vadeli gösterge olabilir. Bu veri kamu ve sektör işbirliği için de değerlidir.

Ortaklık Başvuruları Nasıl Değerlendirilmeli?

Kooperatif büyüdükçe ortaklık başvuruları sistematik hale getirilmelidir. Ön yeterlilik, yetkinlik, katkı potansiyeli ve değer uyumu birlikte değerlendirilebilir. Başvuru prosedürü ana sözleşme ve mevzuata uygun olmalıdır. Keyfî kararlar güven ve eşitlik problemi yaratır. Yönetim kurulu nihai değerlendirmeyi açık kriterler üzerinden yapmalıdır.

Ön Yeterlilik

Başvuru sahibinin temel ortaklık şartlarını karşılayıp karşılamadığı kontrol edilir. Eksik belge tamamlatılabilir. Açık uygunsuzluk erken aşamada belirlenir. Teknik değerlendirme gereksiz yere uzatılmaz. Kriterler başvurana önceden açıklanabilir.

Mesleki Yetkinlik

Ar-Ge kooperatifinde mesleki yetkinlik değerli olabilir fakat ortaklık modeline göre zorunluluk seviyesi değişebilir. Teknik olmayan iş geliştirme veya finans uzmanları da katkı sağlayabilir. Değerlendirme yalnız diploma üzerinden yapılmamalıdır. Gerçek deneyim ve katkı alanı önemlidir. Ana sözleşmedeki ortaklık şartlarıyla uyum korunmalıdır.

Ar-Ge Tecrübesi

Araştırma projesi, ürün geliştirme veya patent deneyimi avantaj sağlayabilir. Yeni mezunların ortak olmasını otomatik engellemek gerekli olmayabilir. Mentorluk ve öğrenme kapasitesi de değerlendirilebilir. Kooperatifin insan kaynağı stratejisiyle uyum aranmalıdır. Deneyim farklı uzmanlıklarla dengelenebilir.

Kooperatife Katkı Potansiyeli

Başvuru sahibinin hangi proje, uzmanlık veya kaynakla katkı sunacağı konuşulmalıdır. Yalnız pasif yatırım beklentisi kooperatif modeline uyumlu olmayabilir. Katkı her ay çalışma zorunluluğu anlamına gelmez. Uzman görüşü veya müşteri ağı da değerli olabilir. Beklentiler baştan açık olmalıdır.

Ortak Değerlere Uyum

Araştırma etiği, açık iletişim ve işbirliği kooperatif kültürünün temel değerleri olabilir. Başvuru sahibinin bu ilkelerle uyumu görüşmede değerlendirilebilir. Belirsiz “kültür uyumu” kavramı ayrımcı kararlara dönüşmemelidir. Somut davranış ilkeleri kullanılmalıdır. Code of Conduct ortaklara da uygulanabilir.

Çıkar Çatışması

Adayın kooperatifle rekabet eden veya ilişkili ekonomik faaliyetleri olabilir. Bu durum otomatik engel değil yönetilmesi gereken çatışma olabilir. Gizlilik ve proje erişimi buna göre düzenlenebilir. Sürekli ve ağır çatışma ortaklık uygunluğunu etkileyebilir. Beyan yazılı alınmalıdır.

Yönetim Kurulu Değerlendirmesi

Nihai ortaklık kararı mevzuat ve ana sözleşme uyarınca yetkili organ tarafından alınır. Kriterlerin tutarlı uygulanması gerekir. Danışma kurulundan teknik profil hakkında görüş alınabilir ancak ortaklık kararını o vermez. Karar kayıt altına alınmalıdır. Ortak kabulünün ardından onboarding programı uygulanabilir.

Kooperatiften veya Projeden Ayrılma Süreci

Ayrılma süreçleri başlangıçta yazılmadığında proje ortasında ciddi risk oluşur. Ortaklıktan çıkış ile proje ekibinden ayrılma aynı hukuki işlem değildir. Devam eden iş, kod, veri ve IP teslimi ayrı yönetilmelidir. Gizlilik yükümlülükleri belirli süre devam edebilir. Sağlıklı offboarding hem ayrılan kişiyi hem kooperatifi korur.

Ortaklıktan Çıkış

Ortaklıktan çıkış ana sözleşme ve Kooperatifler Kanunundaki prosedüre göre yürütülmelidir. Mali haklar ilgili hükümlere göre değerlendirilir. Devam eden proje sözleşmesi ayrıca geçerliliğini koruyabilir. Erişim ve temsil yetkileri güncellenmelidir. Çıkış kişisel anlaşmazlık halinde bile resmi süreçle yürütülmelidir.

Proje Ekibinden Ayrılma

Ortak projeden ayrılabilir fakat kooperatif ortaklığı devam edebilir. Proje yürütücüsü görev devri planı oluşturmalıdır. Kullanılmayan erişimler kapatılmalıdır. Tamamlanmamış görevler yeni sorumluya aktarılmalıdır. Ücret ve hak hesapları sözleşmeye göre tamamlanmalıdır.

Devam Eden İşlerin Teslimi

Ayrılan kişi açık görev, karar ve teknik riskleri belgelemelidir. Handover yalnız dosya paylaşmak değildir. Yeni sorumluyla kısa bilgi aktarımı yapılabilir. Kritik erişim ve secret'lar güvenli biçimde devredilmelidir. Teslim tutanağı faydalı olabilir.

Kaynak Kod Devri

Kod kurumsal repository'de tutuluyorsa devir daha kolaydır. Kişisel cihaz veya hesabında kalan kod taşınmalıdır. Branch ve açık PR'lar gözden geçirilmelidir. Secret ve erişim anahtarları yenilenebilir. IP sahipliği proje sözleşmesine göre devam eder.

Araştırma Verisi

Yerel cihazda bulunan araştırma verisi kurumsal sisteme aktarılmalıdır. Kişisel veri veya ticari sır ise güvenli silme gerekebilir. Araştırma notları da proje tekrar üretilebilirliği için önemlidir. Açık yayımlanacak veri ayrıca hazırlanabilir. Veri devir kaydı tutulmalıdır.

Fikri Mülkiyet

Ayrılma daha önce yapılan IP sözleşmesini otomatik olarak sona erdirmez. Patent veya royalty hakları varsa koşullar uygulanır. Yeni geliştirilen IP'nin teslimi tamamlanmalıdır. Kişinin background IP'si ayrı kalabilir. Uyuşmazlık riski varsa hukuki görüş alınmalıdır.

Gizlilik Yükümlülüğünün Devamı

Gizlilik sözleşmesi projeden ayrılma sonrası belirli süre devam edebilir. Süre ve kapsam sözleşmede açık olmalıdır. Genel mesleki bilgi gereksiz biçimde sınırlanmamalıdır. Ticari sırların korunması devam eder. Ayrılan kişiye yükümlülükler offboarding sırasında hatırlatılabilir.

Başarısız Ar-Ge Projeleri Nasıl Kapatılmalı?

Ar-Ge faaliyetinde her proje başarıya ulaşmaz ve bu doğal bir sonuçtur. Problem başarısızlık değil ne zaman durdurulacağını bilememektir. Teknik engel, bütçe, fon kesintisi veya pazar değişimi nedeniyle proje kapatılabilir. Kapatma kararı yönetim kurulu tarafından kayıtlı gerekçeyle alınmalıdır. Veri, IP ve öğrenilen dersler korunarak başarısızlık kurumsal bilgiye dönüştürülmelidir.

Teknik Başarısızlık

Araştırma hipotezi yanlış çıkabilir veya hedef performansa ulaşılamayabilir. Bu durum otomatik kötü proje yönetimi değildir. Yapılan deneyler ve sonuçlar kaydedilmelidir. Başka teknik yaklaşım ekonomik değilse proje durdurulabilir. Öğrenilen bilgi sonraki projelerde kullanılabilir.

Bütçe Aşımı

Maliyet başlangıç tahminini aşabilir. Aşımın nedeni teknik belirsizlik veya kötü planlama olabilir. Yönetim kurulu ek yatırımın beklenen değeri karşılayıp karşılamadığını değerlendirmelidir. Sunk cost etkisine dikkat edilmelidir. Yalnız geçmişte çok para harcandığı için projeye devam edilmemelidir.

Fon Kesintisi

Fon sağlayıcı desteği kesildiğinde alternatif finansman değerlendirilebilir. Kooperatifin genel bütçesini riske atacak devam kararı verilmemelidir. Proje ekip sözleşmeleri gözden geçirilmelidir. Fon şartlarına göre veri ve rapor teslimi yapılmalıdır. IP hakları proje sözleşmesine göre korunmalıdır.

Pazar Koşullarının Değişmesi

Teknik proje iyi ilerlerken kullanıcı veya pazar ihtiyacı ortadan kalkabilir. Yeni regülasyon veya teknoloji değişimi ürünü gereksiz hale getirebilir. Proje pivot edilebilir. Araştırma çıktısının başka kullanım alanı araştırılabilir. Devam kararı yalnız teknik başarıya dayanmamalıdır.

Proje Kapatma Kararı

Kapatma kriterleri mümkünse proje başlangıcında belirlenmelidir. Yönetim kurulu teknik ve mali raporu değerlendirir. Danışma kurulu bilimsel görüş sağlayabilir. Karar gerekçesi ve tarih kayıt altına alınır. Ekibe açık iletişim yapılmalıdır.

Öğrenilen Dersler

Proje kapanışında kısa retrospektif yapılmalıdır. Hangi varsayımın yanlış olduğu ve hangi yöntemin işe yaradığı yazılır. Suçlama yerine sistem öğrenmesi hedeflenir. Uygun bilgiler diğer ekiplerle paylaşılabilir. Bu kayıt gelecekte aynı hatanın tekrarını azaltır.

IP ve Veri Arşivi

Başarısız proje de değerli kod, veri veya patent potansiyeli bırakabilir. Hak sahipliği ve lisans durumu kontrol edilmelidir. Repository read-only arşive alınabilir. Hassas veri retention politikasına göre silinmelidir. Gelecekte yeniden başlatma ihtimali varsa dokümantasyon korunmalıdır.

Ar-Ge Kooperatifi İçin Yıllık Yönetişim Takvimi

Yıllık yönetişim takvimi zorunlu toplantılar ile stratejik review süreçlerini tek planda toplar. Genel kurul, yönetim kurulu, danışma kurulu ve proje portföyü toplantıları önceden planlanabilir. Mali raporlama ve risk değerlendirmesi aynı takvimde yer alabilir. Böylece kritik süreçler son dakikaya kalmaz. Takvim yasal son tarihlerle birlikte dijital olarak takip edilmelidir.

Yıllık Genel Kurul

Genel kurul mevzuattaki süre ve usule göre planlanmalıdır. Belgeler ortaklara zamanında sunulmalıdır. Faaliyet ve mali raporlar anlaşılır formatta hazırlanmalıdır. Önemli ana sözleşme değişikliği varsa önceden hukuki inceleme yapılmalıdır. Toplantı sonrası gerekli bildirim ve KOOPBİS işlemleri zamanında tamamlanmalıdır.

Yönetim Kurulu Toplantıları

Yönetim kurulu proje yoğunluğuna göre aylık veya daha sık toplanabilir. Her toplantı için gündem önceden hazırlanmalıdır. Sürekli operasyon detayı yerine stratejik karar ve riskler ele alınmalıdır. Kararlar usulüne uygun biçimde kaydedilmelidir. Acil karar prosedürü ayrıca belirlenebilir.

Danışma Kurulu Toplantıları

Danışma kurulu üç veya dört aylık dönemlerde toplanabilir. Büyük proje veya stratejik ihtiyaçta ek toplantı yapılabilir. Gündem teknik değerlendirme için yeterli hazırlıkla gönderilmelidir. Çıkar çatışmaları toplantı öncesi kontrol edilmelidir. Yıllık rapor son toplantıda hazırlanabilir.

Proje Portföyü Değerlendirmesi

Üç aylık portföy review aktif, riskli ve yeni projeleri birlikte değerlendirir. Kaynak çatışmaları görünür hale gelir. Düşük öncelikli proje durdurulabilir. Yeni proje kabulü kapasiteye göre yapılır. Bu süreç “her fikri başlatalım” alışkanlığını engeller.

Mali Raporlama

Aylık gelir, gider ve nakit akışı yönetim kuruluna sunulabilir. Proje bütçe sapmaları ayrıca gösterilir. Fon projeleri kendi raporlama dönemine göre takip edilir. Yıllık mali rapor genel kurul için hazırlanır. Muhasebe verisi proje yönetimiyle entegre olmalıdır.

Risk Değerlendirmesi

Risk register en az çeyreklik güncellenebilir. Yeni müşteri, teknoloji veya mevzuat riski eklenir. En yüksek riskler için owner ve aksiyon atanır. Gerçekleşen risklerden öğrenme yapılır. Danışma kurulu teknik risklerde destek sağlayabilir.

Ar-Ge Stratejisi Güncellemesi

Yılda bir strateji oturumu kooperatifin odak alanlarını gözden geçirir. Proje ve pazar verisi kullanılır. Yeni araştırma alanları eklenebilir. Artık anlamlı olmayan odaklar bırakılabilir. Danışma kurulu görüşü yönetim kurulunun kararını destekler.

Yıllık Şeffaflık ve Etki Raporu

Rapor proje, finans, IP, eğitim ve bölgesel etki göstergelerini özetleyebilir. Gizli müşteri verisi açıklanmamalıdır. Başarısız projeler de öğrenme perspektifiyle yer alabilir. Ortaklar ve kamu için farklı ayrıntı seviyeleri hazırlanabilir. Düzenli rapor kurumsal güveni artırır.

Ar-Ge Kooperatifi Kurulurken Yapılan Hatalar

Kuruluş aşamasındaki en yaygın hatalar belge eksikliğinden çok iş modeli ve yönetişim belirsizliğinden kaynaklanır. Tüzel kişiliği hızlı kurmak gerçek ekonomik ihtiyeti otomatik olarak çözmez. Ortak roller, IP, proje gelirleri ve danışma kurulunun yetkileri açık değilse ilk başarılı proje bile çatışma yaratabilir. Bu nedenle kuruluş evrakıyla paralel olarak işleyiş belgeleri hazırlanmalıdır. Hukuk, mali yönetim ve teknik proje tasarımı aynı masada değerlendirilmelidir.

İş Modeli Olmadan Tüzel Kişilik Kurmak

Kooperatif kurmak gelir üretmek anlamına gelmez. İlk proje portföyü ve müşteri ihtiyacı bilinmeden sabit giderler başlar. Üyeler kısa sürede motivasyon kaybedebilir. Fizibilite ve on iki aylık plan önce hazırlanmalıdır. Tüzel kişilik doğrulanmış işbirliği modelinin aracı olmalıdır.

Ortakların Rollerini Belirsiz Bırakmak

Her kurucu kendisini yönetici veya proje lideri sanabilir. Görev ve beklenti yazılmadığında kişisel çatışma oluşur. Kurucu olmak sürekli operasyon rolü anlamına gelmez. Yönetim, teknik ve iş geliştirme görevleri ayrılmalıdır. Düzenli performans ve rol review yapılabilir.

Ana Sözleşme ile İç Tüzüğü Karıştırmak

Ana sözleşmeye her operasyon detayını yazmak esnekliği azaltır. İç tüzükle kanuni yetkiyi değiştirmeye çalışmak ise hukuki risk yaratır. Hangi konunun hangi belgeye ait olduğu kuruluşta belirlenmelidir. Değişiklik usulleri farklıdır. Hukuki inceleme bu ayrımı netleştirir.

Danışma Kuruluna Fazla Yetki Vermek

Danışma kurulu uzman görüşü sağlamak için vardır. Bağlayıcı yönetim veya veto yetkisi verilmesi organlar arasındaki sınırı bozabilir. Yönetim kurulu sorumluluk taşırken karar gücünü başka yapıya bırakamaz. Kurul görüşleri yazılı ve tavsiye niteliğinde tutulmalıdır. Yetki matrisi herkesle paylaşılmalıdır.

IP Haklarını Proje Başlamadan Belirlememek

Proje başarılı olduktan sonra IP daha değerli hale gelir ve anlaşmazlık ihtimali artar. Bu nedenle background ve foreground haklar baştan belirlenmelidir. Ortak, çalışan ve danışman katkıları farklı ilişkilerdir. Open source dependency'ler kontrol edilmelidir. Yazılı proje IP sözleşmesi temel güvenlik sağlar.

Proje Gelir Dağılımını Belirsiz Bırakmak

Gelir oluşmadan paylaşım konuşmak bazen gereksiz görülür. Oysa gelir geldikten sonra herkes katkısını farklı hatırlar. Kooperatif genel gideri ve proje ekibi payı baştan yazılmalıdır. Vergi ve muhasebe sonuçları uzmanla değerlendirilmelidir. Şeffaf model ekip motivasyonunu korur.

Open Source Politikasını Oluşturmamak

Geliştiriciler alışkanlıkla farklı lisanslı paketler kullanabilir. Proje sonunda lisans uyumsuzluğu ticarileştirmeyi engelleyebilir. Public repository açılması müşteri gizliliğini ihlal edebilir. Basit bir open source policy bu riskleri azaltır. Otomatik dependency taraması süreci destekleyebilir.

Çıkar Çatışmasını Yönetmemek

Küçük ekosistemlerde kişilerin birden fazla rolü olabilir. Danışma kurulu üyesi aynı zamanda yatırımcı veya müşteri olabilir. Çatışmayı yok saymak güveni azaltır. Beyan ve çekilme prosedürü uygulanmalıdır. Şeffaf yönetilen çatışma çoğu zaman kontrol edilebilir.

Ar-Ge Kooperatifi Kuruluş Kontrol Listesi

Kuruluş kontrol listesi hukuki belge hazırlığının yanında ekonomik ve yönetsel hazırlığı da kontrol etmelidir. En az yedi kurucu, ana sözleşme ve MERSİS işlemleri temel başlangıçtır. Bunun yanında iş modeli, IP politikası, proje kabul mekanizması ve ilk yıl portföyü hazırlanmadan operasyon erken başlayabilir. Danışma kurulunun yetki sınırları ayrıca yazılmalıdır. Aşağıdaki sorular kuruluş toplantısında madde madde gözden geçirilebilir.

Ortak ekonomik amaç net mi?

Her kurucu kooperatifin hangi ortak ekonomik ihtiyacı çözdüğünü aynı şekilde anlatabilmelidir. Farklı beklentiler varsa kuruluş öncesi konuşulmalıdır. Amaç ana sözleşmeye doğru yansıtılmalıdır. Yıllık iş planı bu amaçtan türemelidir. Belirsiz amaç en büyük stratejik risktir.

En az yedi kurucu hazır mı?

Genel kooperatif kuruluşunda en az yedi ortak şartı bulunmaktadır. Kurucular yalnız sayı tamamlamak için seçilmemelidir. Kimlik ve temsil belgeleri önceden hazırlanmalıdır. Sermaye taahhütleri net olmalıdır. Kurucular ana sözleşmenin sonuçlarını anlamalıdır.

İş modeli oluşturuldu mu?

Kooperatifin ilk yıl nasıl gelir üreteceği açıklanmalıdır. Hizmet, proje, fon ve lisans kaynakları ayrı değerlendirilmelidir. Sabit giderler hesaplanmalıdır. Fon çıkmazsa devam senaryosu hazırlanmalıdır. İş modeli üç ayda bir gözden geçirilebilir.

Ana sözleşme hazır mı?

MERSİS üzerinden hazırlanacak ana sözleşme resmi örnek ve mevzuatla uyumlu olmalıdır. Faaliyet maddeleri gerçek iş planını kapsamalıdır. Değişiklik yapılacaksa kuruluş izin sürecine etkisi değerlendirilmelidir. Kurucular son metni okumalıdır. Hukuki kontrol yapılması faydalıdır.

MERSİS süreci planlandı mı?

Kurucuların bilgileri ve unvan seçimi önceden hazırlanmalıdır. Başvuru numarası sonrası ticaret sicili süreci planlanmalıdır. Yetkilendirilmiş imza işlemleri güncel prosedüre göre yürütülmelidir. Sistem ekranları değişebileceği için resmi yönlendirme kontrol edilmelidir. Tek sorumlu koordinatör işleri hızlandırır.

Kuruluş belgeleri tamamlandı mı?

Bakanlığın Bilimsel Araştırma ve Geliştirme Kooperatifi için güncel belge listesi kontrol edilmelidir. Dilekçe, kuruluş bilgi formu ve ana sözleşme gibi temel belgeler hazırlanır. Tüzel kurucular için ek yetki belgeleri gerekebilir. Dosyadaki unvan ve adres bilgileri tutarlı olmalıdır. Teslim öncesi çapraz kontrol yapılmalıdır.

İç çalışma esasları hazır mı?

İlk proje başlamadan iç çalışma esaslarının temel bölümleri hazır olmalıdır. Proje kabul, kaynak tahsisi ve çıkar çatışması süreçleri önceliklidir. Belge ana sözleşmeye aykırı olmamalıdır. Değişiklik usulü yazılmalıdır. Kurucular belgeyi uygulayabilecek kadar sade tutmalıdır.

IP politikası var mı?

Background ve foreground IP için genel prensip belirlenmelidir. Yazılım, patent ve open source ayrı başlıklar gerektirir. Her proje için özel sözleşme yapılabilir. Çalışan ve danışman katkıları kayıt altına alınmalıdır. IP politikasız Ar-Ge projesi önemli risk taşır.

Proje kabul mekanizması tanımlandı mı?

Proje fikirlerinin kimden ve nasıl alınacağı açık olmalıdır. Teknik, ticari ve IP değerlendirme aşamaları oluşturulabilir. Danışma kurulu görüşü ile yönetim kurulu kararı ayrılmalıdır. Puanlama modeli gerekçeli kullanılmalıdır. Kabul sonrası proje sözleşmesi zorunlu hale getirilebilir.

Danışma kurulunun yetki sınırları açık mı?

Danışma kurulu görüş organı olarak tanımlanmalıdır. Kooperatifi temsil veya mali taahhüt yetkisi bulunmamalıdır. Yönetim ve genel kurul yetkilerine müdahale etmemelidir. Çıkar çatışması prosedürü bulunmalıdır. Tavsiye görüşleri yazılı kayda alınmalıdır.

Açık kaynak politikası oluşturuldu mu?

Hangi lisansların kullanılabileceği ve repository yayın yetkisi belirlenmelidir. Dependency taraması yapılabilir. Contributor Guide ve security reporting hazırlanmalıdır. Müşteri kodu açık kaynak projeye karışmamalıdır. IP ve open source politikası birlikte çalışmalıdır.

İlk 12 aylık proje portföyü hazır mı?

İlk yıl için birkaç gerçekçi proje belirlenmelidir. Her projenin ekip, bütçe ve potansiyel gelir bilgisi olmalıdır. Yalnız fikir listesi yeterli değildir. Kapasiteye göre önceliklendirme yapılmalıdır. İlk portföy kooperatifin iş modelini doğrulayacak kadar somut olmalıdır.

Sıkça Sorulan Sorular

Ar-Ge kooperatifleriyle ilgili soruların büyük bölümü kuruluş sayısı, ana sözleşme, iç tüzük, danışma kurulu ve fikri mülkiyet üzerinde yoğunlaşır. Her kooperatifin iş modeli farklı olduğu için tek şablon bütün yapılar için yeterli değildir. Bununla birlikte 1163 sayılı Kooperatifler Kanunu, Ticaret Bakanlığının güncel kuruluş prosedürü ve kooperatif ana sözleşmesi temel hukuki çerçeveyi oluşturur. Danışma kurulu gibi iç yapılar bu çerçeveyi değiştirmeden tasarlanmalıdır. Aşağıdaki yanıtlar kuruluş hazırlığında en sık gündeme gelen noktaları özetler.

Ar-Ge kooperatifi kaç kişiyle kurulur?

Türkiye'deki genel kooperatif kuruluş kuralına göre kooperatif en az yedi ortak tarafından imzalanacak ana sözleşmeyle kurulur. Bilimsel Araştırma ve Geliştirme Kooperatifi kuruluşunda da güncel resmi prosedür bu genel hukuki çerçeveyle birlikte değerlendirilir. Kurucu sayısını yalnız yediye tamamlamak yeterli değildir. Ortak ekonomik amaç, sermaye ve çalışma beklentileri de net olmalıdır. Kuruluş tarihinde Ticaret Bakanlığı ve ilgili sicil müdürlüğünün güncel belge ve işlem şartları ayrıca kontrol edilmelidir.

Yazılım şirketleri Ar-Ge kooperatifine ortak olabilir mi?

Kooperatifler gerçek ve tüzel kişiler tarafından kurulabildiği için tüzel kişilerin ortaklığı mümkündür. Somut yazılım şirketinin ortaklık şartlarını karşılayıp karşılamadığı ana sözleşmeye göre değerlendirilmelidir. Tüzel kişinin temsil ve yetki belgeleri kuruluş veya ortaklık başvurusunda gerekli olabilir. Şirket ile kooperatif arasındaki proje ve IP ilişkisi ayrıca sözleşmeyle düzenlenmelidir. Ortaklık statüsü kooperatifle yapılan ticari sözleşmelerin yerine geçmez.

Üniversite akademisyenleri ortak olabilir mi?

Akademisyenlerin ortaklığı genel ortaklık koşulları yanında görev yaptıkları kurumun mevzuat ve izin süreçleri açısından da değerlendirilmelidir. Akademisyenin ortak, danışma kurulu üyesi veya proje danışmanı olması farklı ilişkilerdir. Üniversite adına kurumsal işbirliği yapılacaksa ayrıca yetkili protokol gerekir. Çıkar çatışması ve akademik yayın hakları baştan konuşulmalıdır. Somut durumda kurum ve hukuk uzmanı görüşü alınması faydalıdır.

Ar-Ge kooperatifi ticari faaliyet yapabilir mi?

Kooperatif ortaklarının ekonomik menfaatlerini geliştirme amacı taşıdığı için ana sözleşmesi ve mevzuatla uyumlu ekonomik faaliyetler yürütebilir. Ancak her ticari faaliyet otomatik olarak ana sözleşme kapsamına girmez. Özel izin gerektiren sektörler ayrıca değerlendirilmelidir. Gelir ve giderlerin kooperatif muhasebesinde doğru izlenmesi gerekir. Ticari faaliyet kooperatif amacından kopuk ayrı bir işletmeye dönüşmemelidir.

Ar-Ge kooperatifi yazılım geliştirebilir mi?

Amaç ve faaliyet konuları buna uygun biçimde düzenlenmişse yazılım ve teknoloji geliştirme faaliyetleri yürütülebilir. Proje bazlı yazılım hizmeti veya kooperatifin kendi ürünü farklı IP modellerine ihtiyaç duyabilir. Kaynak kod, open source dependency ve müşteri hakları proje başlamadan belirlenmelidir. Siber güvenlik ve veri politikası uygulanmalıdır. Yazılım geliştirme yalnız kod üretimi değil ürün, test ve bakım sorumluluğunu da kapsar.

Ar-Ge kooperatifinin iç tüzüğü zorunlu mudur?

“İç tüzük” adıyla ayrı bir belgenin zorunluluğu somut kooperatif türü, ana sözleşme ve ilgili mevzuat çerçevesinde değerlendirilmelidir. Bununla birlikte proje kabulü, IP, danışma kurulu ve kaynak tahsisi gibi konular için yazılı iç çalışma esasları oluşturmak yönetişim açısından son derece faydalıdır. İç düzenleme ana sözleşmeye veya kanuna aykırı olamaz. Genel kurul veya yönetim kurulunun kanuni yetkilerini değiştiremez. Belgenin kim tarafından kabul edileceği hukuki niteliğine göre belirlenmelidir.

Ana sözleşme ile iç tüzük arasındaki fark nedir?

Ana sözleşme kooperatifin tescilli temel kuruluş ve yönetişim belgesidir. İç tüzük veya çalışma esasları günlük operasyon ve süreçleri detaylandırabilir. İç düzenleme ana sözleşmenin yerine geçmez ve ona aykırı olamaz. Proje puanlama veya danışma toplantısı gibi sık değişebilecek konular iç düzenlemeye daha uygundur. Ortaklık ve kanuni organların temel yetkileri ise ana sözleşme ve mevzuat çerçevesinde kalmalıdır.

Danışma kurulu oluşturmak zorunlu mudur?

Danışma kurulu kooperatifin kanuni temel organlarından biri olarak zorunlu kabul edilmemelidir. Ar-Ge yapısının ihtiyaçlarına göre iç yönetişim mekanizması olarak oluşturulabilir. Bilimsel ve teknik uzman görüşüne düzenli erişim sağladığı için faydalıdır. Kurulun görev ve yetki sınırları yazılı olmalıdır. Oluşturulması planlanıyorsa ana sözleşme ve iç düzenlemeyle uyumu hukuki olarak kontrol edilmelidir.

Danışma kurulu yönetim kurulunun yerine geçebilir mi?

Hayır, danışma kurulu yönetim kurulunun hukuki temsil ve idare sorumluluğunu üstlenmemelidir. Yönetim kurulu karar verirken danışma görüşünden yararlanabilir. Danışma kuruluna veto veya bağlayıcı mali karar yetkisi vermek yetki yapısıyla çatışma yaratabilir. Nihai karar ilgili kanuni organda kalmalıdır. Bu ayrım çalışma esaslarında açıkça yazılmalıdır.

Danışma kurulu üyeleri ortak olmak zorunda mı?

Danışma kurulunun iç düzenleme kapsamında uzman görüşü veren yapı olarak tasarlanması halinde üyelerin tamamının kooperatif ortağı olması zorunlu bir ihtiyaç değildir. Akademisyen, sektör profesyoneli veya IP uzmanı dışarıdan görev alabilir. Ancak somut yapının ana sözleşme ve iç düzenleme hükümleri kontrol edilmelidir. Ortak olmayan üyeye temsil veya oy hakkı doğmaz. Gizlilik ve çıkar çatışması sözleşmeleri ayrıca yapılmalıdır.

Danışma kurulu üyelerine ücret ödenebilir mi?

Ücret veya huzur hakkı benzeri ödeme modeli ancak kooperatifin hukuki ve mali çerçevesine uygun şekilde tasarlanmalıdır. Danışma üyeleriyle hizmet veya danışmanlık ilişkisi kurulabilir. Ödemenin hangi karar ve sözleşmeye dayandığı açık olmalıdır. Vergi ve muhasebe niteliği mali müşavir ve hukuk uzmanıyla değerlendirilmelidir. Gönüllü üyelik varsa masraf iadesi prosedürü ayrıca tanımlanabilir.

Ar-Ge projesinde geliştirilen yazılım kime ait olur?

Bu sorunun tek otomatik cevabı yoktur. Çalışan, danışman, ortak, kooperatif ve müşteri arasındaki sözleşmeler hak sahipliğini etkiler. Background ve foreground IP ayrımı yapılmalıdır. Müşteri projesinde hak devri, kooperatif ürününde merkezi mülkiyet veya lisans modeli seçilebilir. Proje başlamadan yazılı IP sözleşmesi hazırlanması en güvenli yaklaşımdır.

Açık kaynak projeleri Ar-Ge kooperatifi üzerinden geliştirilebilir mi?

Evet, kooperatif amaç ve faaliyetleriyle uyumlu açık kaynak projeler geliştirilebilir. Lisans ve copyright sahipliği baştan belirlenmelidir. Contributor kabul süreci ve güvenlik politikası hazırlanmalıdır. Açık kaynak yayınlama ticari ürün geliştirmeye engel olmak zorunda değildir. Dual licensing veya açık çekirdek gibi farklı modeller değerlendirilebilir.

Teknoloji toplulukları Ar-Ge kooperatifi kurabilir mi?

Topluluk kendi başına hukuki kişi değilse kurucu kişiler veya uygun tüzel kişiler üzerinden süreç yürütülür. En az yedi kurucu ve diğer resmi şartlar sağlanmalıdır. Topluluk üyelerinin tamamının ortak olması gerekli değildir. Topluluk ve kooperatif faaliyetleri açık biçimde ayrılmalıdır. Marka ve mevcut proje hakları kuruluş öncesi incelenmelidir.

Diyarbakır Yazılım Topluluğu gibi topluluklar kooperatif modeliyle nasıl işbirliği yapabilir?

Topluluk eğitim, etkinlik ve açık kaynak alanında devam ederken kooperatif sözleşmeli Ar-Ge ve ticarileştirme faaliyetlerini yürütebilir. Yerel geliştiriciler proje ekiplerine yetkinliklerine göre katılabilir. Üniversite ve sanayi ile ortak problem havuzu oluşturulabilir. Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about adresinden, proje çalışmaları hakkında ise https://www.diyarbakiryazilim.com.tr/projects adresinden bilgi alınabilir. Model tasarlanırken gönüllü topluluk emeği ile kooperatifin ekonomik faaliyetleri arasında şeffaf sınır korunmalıdır.

Ar-Ge kooperatifi nasıl kurulur ve kuruluş için hangi şartlar gereklidir?

Ar-Ge kooperatifi nasıl kurulur ve kuruluş şartları nelerdir sorusunun başlangıç cevabı en az yedi kurucu, uygun ana sözleşme ve resmi kuruluş süreçlerinin tamamlanmasıdır. Bilimsel Araştırma ve Geliştirme Kooperatifi için ana sözleşme MERSİS üzerinden hazırlanır ve Ticaret Bakanlığının ilgili kuruluş izin belgeleri dikkate alınır. Ticaret Sicili Müdürlüğündeki imza ve tescil işlemleri güncel prosedüre göre tamamlanır. Kuruluş öncesinde ortak ekonomik amaç ve ilk on iki aylık iş planı da hazırlanmalıdır. Resmi belge ve işlem şartları değişebileceği için başvuru tarihinde Ticaret Bakanlığının güncel sayfası ve ilgili Ticaret Sicili Müdürlüğü mutlaka kontrol edilmelidir.

Ar-Ge kooperatifinin ana sözleşmesi ve iç tüzüğü nasıl hazırlanır?

Ar-Ge ve teknoloji kooperatifi ana sözleşmesi nasıl hazırlanır sorusunda MERSİS'teki güncel örnek ana sözleşme ve 1163 sayılı Kooperatifler Kanunu temel alınmalıdır. Ana sözleşme kooperatifin amaç, sermaye, ortaklık ve organ yapısını belirler. İç tüzük veya çalışma esasları ise proje kabulü, danışma kurulu, IP, açık kaynak ve kaynak tahsisi gibi uygulama süreçlerini detaylandırabilir. İç düzenleme ana sözleşmeye veya mevzuata aykırı olamaz. Somut metinlerin kuruluş öncesinde kooperatif hukuku konusunda uzman hukukçu ve mali müşavir tarafından birlikte incelenmesi güçlü risk kontrolü sağlar.

Ar-Ge kooperatiflerinde yönetim, denetim ve danışma kurullarının görevleri nelerdir?

Yönetim kurulu kooperatifin temsil ve idaresinden sorumlu temel organdır. Genel kurulun ve diğer kanuni yapıların yetkileri mevzuat ve ana sözleşmeyle belirlenir, denetim ise ilgili hukuki çerçeve içinde yürütülür. Danışma kurulu bilimsel ve teknik görüş veren yardımcı yapı olarak tasarlanabilir. Danışma kurulu yönetim kurulunun yerine geçmemeli ve kooperatif adına bağlayıcı mali veya temsil kararı almamalıdır. Teknoloji kooperatiflerinde iç tüzük görev yetki ve karar alma süreçleri hazırlanırken bu yetki ayrımı açık biçimde yazılmalıdır.

Ar-Ge kooperatifinde danışma kurulu üyeleri nasıl belirlenir ve karar süreçlerine nasıl katılır?

Ar-Ge kooperatifi danışma kurulu nasıl oluşturulur ve nasıl çalışır sorusunda ilk kriter proje portföyünün ihtiyaç duyduğu uzmanlıktır. Akademisyen, yazılım profesyoneli, sektör uzmanı, IP danışmanı ve finans uzmanı gibi farklı profiller seçilebilir. Görev süresi, toplantı sıklığı, gizlilik ve çıkar çatışması kuralları iç çalışma esaslarında yazılmalıdır. Kurul teknik veya stratejik tavsiye sunmalı, yönetim kurulu ise hukuken kendi yetkisindeki nihai kararı almalıdır. Çıkar çatışmalı üyenin ilgili proje görüşmesinden çekilmesi karar süreçlerinin güvenilirliğini güçlendirir.

Ar-Ge kooperatifi kuruluşu ve iç tüzük danışmanlığı yakınımda nerede bulunur?

Ar-Ge kooperatifi kuruluşu ve hukuki danışmanlık hizmeti veya Ar-Ge ve teknoloji kooperatifi danışmanlığı yakınımda araması yaparken yalnız kuruluş evrakı hazırlayan değil iş modeli, ana sözleşme, IP, proje yönetimi ve yönetişim süreçlerini birlikte değerlendirebilen uzmanlarla çalışmak faydalıdır. Kooperatif kuruluşu hukuki, mali ve operasyonel boyut taşıdığı için hukukçu, mali müşavir ve teknoloji proje uzmanının birlikte çalışması çoğu durumda daha güvenli sonuç verir. Diyarbakır Yazılım Topluluğu'nun yerel teknoloji ve proje çalışmalarını değerlendirmek için https://www.diyarbakiryazilim.com.tr/about ve https://www.diyarbakiryazilim.com.tr/projects adresleri incelenebilir. Yerel kurumlarla dijital dönüşüm işbirliği yaklaşımı için https://www.diyarbakiryazilim.com.tr/posts/sanayi-odalari-ile-is-birliginde-yerel-dijital-donusum-stratejileri içeriği de kullanılabilir. Kuruluş görüşmesine ortakların listesi, ilk proje fikirleri, sermaye planı ve taslak görev dağılımıyla gitmek danışmanlık sürecini daha verimli hale getirir.

Sonuç

Ar-Ge Kooperatifleri Kurulumu, İç Tüzük ve Danışma Kurulu İşleyişi yalnızca MERSİS başvurusu ve ticaret sicili tescilinden ibaret değildir. Sağlam model ortak ekonomik amaç, doğru ana sözleşme, uygulanabilir iç çalışma esasları, açık IP politikası, gerçekçi proje kabul sistemi ve sınırları belirlenmiş danışma mekanizması üzerine kurulmalıdır. Danışma kurulu yönetim kurulunun yerine geçmeden bilimsel ve teknik karar kalitesini yükseltebilir; proje ekipleri ise açık yetki ve sorumlulukla çalışabilir. Ar-Ge Kooperatifleri Kurulumu, İç Tüzük ve Danışma Kurulu İşleyişi doğru tasarlandığında yerel yazılım yeteneğini, akademik bilgiyi ve sanayi problemlerini sürdürülebilir ortak projelere dönüştürebilecek güçlü bir çalışma modeli ortaya çıkabilir. Diyarbakır'da teknoloji, araştırma ve ortak proje ekosistemine dair çalışmaları takip etmek ve bağlantı kurmak için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz.