Ar-Ge ve Danışmanlık

Nerede işe yarıyor

Bu alandaki işlerin ortak noktası, henüz yapılacak şeyin ne olduğunun bilinmemesi. Bir hattı otomatikleştirmek belirli bir iştir; “bu kontrolü kamerayla yapabilir miyiz” ise önce bir soru, sonra iş. Aradaki mesafeyi kapatmak danışmanlığın konusu.

En sık karşılaştığımız durumlar:

• Yatırım kararı öncesi. Bütçe onaya girecek ama teknik uygunluk belirsiz; rakamlar tedarikçi sunumlarından geliyor.
• Teklifler karşılaştırılamıyor. Aynı iş için gelen üç teklif üç farklı işi tarif ediyor, fiyat farkının nereden geldiği anlaşılmıyor.
• Mevcut sistem beklentiyi karşılamıyor. Sistem çalışıyor ama hedeflenen çevrim süresine ya da kalite oranına ulaşılamıyor; nedeninin kontrolde mi, mekanikte mi, proseste mi olduğu bilinmiyor.
• Elde bir fikir var, karşılığı yok. Yeni bir ürün, özel bir makine veya bir test tezgahı düşünülüyor; ilk adımın ne olacağı belirsiz.
• Birden fazla tedarikçi var, tek sorumlu yok. Mekanik, elektrik ve yazılım ayrı firmalarda; arayüzlerde kalan işler kimsenin kapsamında değil.

Bu durumların hiçbirinde ilk çıktı bir teklif değil, bir değerlendirme oluyor. Danışmanlık işini uygulamadan ayrı tutmamızın sebebi de bu: neyin yapılacağı belirlenmeden verilen fiyat, kapsamı sonradan tartışılacak bir fiyattır.

Kavram doğrulamanın amacı

Bir PoC’nin amacı çalıştığını göstermek değil, çalışmayacaksa ucuza öğrenmektir. Bu ayrım pratikte her şeyi değiştiriyor. Amaç göstermek olduğunda deney, başarılı olacağı bilinen koşullarda kurulur: temiz numuneler, sabit ışık, seçilmiş parçalar. Amaç öğrenmek olduğunda deney en zor koşulu hedefler.

Bu yüzden çalışmaya başlamadan iki şey yazılıyor: sınanacak tek soru ve başarı ölçütü. Ölçüt sayısal olmak zorunda — “iyi sonuç verdi” bir sonuç değil. Ölçüt baştan yazıldığında, sonuç olumsuz çıksa bile karar netleşir; sonradan yazıldığında elde ne varsa başarı sayılır.

Deney kurgusunda üç şeyi ayrı tutuyoruz: neyin ölçüleceği, hangi koşulda ölçüleceği ve kaç tekrarla ölçüleceği. Tek numunede alınan iyi sonuç bilgi taşımaz; kararı taşıyacak olan, değişkenliğin görüldüğü tekrarlı ölçümdür. Bu yüzden PoC çıktısının içinde ham ölçüm verisi ve deney kaydı da bulunuyor — sonuç yalnız bir cümle olarak değil, tekrar edilebilir biçimde teslim ediliyor.

Olumsuz sonucun geçerli çıktı olduğunu baştan söylüyoruz. Birkaç haftalık bir deneyle kapatılan bir yatırım, aynı bilgiyi devreye alma sırasında öğrenmekten çok daha ucuza gelir.

Teknik şartname ve teklif değerlendirme

Kötü yazılmış bir şartnamenin en görünür sonucu, tekliflerin karşılaştırılamaz hâle gelmesidir. “Yüksek hassasiyetli ölçüm yapılacaktır” cümlesi her tedarikçiye farklı bir şey söyler; biri ±0,1 mm, diğeri ±0,01 mm anlar ve fiyatlar arasındaki üç kat fark açıklanamaz görünür. Aynı belirsizlik kabul aşamasında geri döner: sistem teslim edilir, ölçüt olmadığı için tartışma başlar.

Şartname yazarken uyduğumuz kurallar:

• Her gereksinim ölçülebilir yazılır: değer, tolerans, ölçüm yöntemi ve koşul birlikte.
• Kabul kriterleri şartnamenin parçası olur; FAT ve SAT protokolleri sözleşmeyle birlikte belirlenir, teslimde uydurulmaz.
• Kapsam sınırları açık yazılır: saha kablolaması, mekanik uyarlama, eğitim ve dokümantasyon kimin işi.
• Marka dayatılmaz ama arayüz standardı dayatılır — haberleşme protokolü, veri formatı, kaynak kodun teslimi.

Teklifleri değerlendirirken bir karşılaştırma matrisi çıkarıyoruz: teknik uygunluk, kapsam dışı bırakılan işler, yedek parça ve destek erişimi, bakım ekibinin bilgi seti. Ucuz teklifin kapsamdan çıkardığı işler genelde farkın kaynağıdır.

Dikkat ettiğimiz noktalar

Olgunluk değerlendirmesi mevcut durumdan başlar. Veri toplamayan bir tesise tahmin modeli önermek sıra atlamaktır; önce ölçüm altyapısı gelir.

Prototipin üretim kodu olmadığı yazılı olarak söylenir. PoC kodu hızlı yazılır ve kısıtları vardır; “nasılsa çalışıyor” diye sahaya alınması, sonradan sebebi bulunamayan duruşlar üretir.

Yol haritası kararlara bağlanır. Her aşamanın sonunda “devam / dur / yönü değiştir” noktası olur; on iki aylık kesintisiz plan, ilk ölçüm geldiğinde çöpe gider.

Anahtar teslim işte arayüzler tek elde toplanır. Mekanik, elektrik ve yazılımı farklı firmalar yaptığında en çok gecikme bu üçünün buluştuğu yerde çıkıyor: sinyal listesi eşleşmiyor, montaj sırası çakışıyor, kimse o kalemi kendi kapsamında görmüyor. Proje yönetimini aldığımızda bu arayüzler yazılı bir sorumluluk tablosuna dönüşüyor.

Diğer çözüm alanlarıyla ilişkisi

Danışmanlık çıktısı çoğunlukla bir uygulama işine dönüşüyor: fizibilitesi olumlu çıkan bir kalite kontrol fikri görüntü işleme ve kamera sistemleri kapsamında hayata geçiyor, hat üzerindeki uygulama endüstriyel otomasyon tarafına bağlanıyor. Prototipin ölçüm ve raporlama ihtiyacı ise yazılım ve uygulama geliştirme ile karşılanıyor.