Forward Deployed Engineer Nedir, Şirketinize Ne Katar?

Forward Deployed Engineer (FDE), müşterinin ekibinin yanında çalışan, iş akışını yerinde öğrenen ve yapay zekayı şirketin mevcut sistemlerine bağlayan kodu kendisi yazan mühendistir. Danışman gibi sorunu anlar, yazılım geliştirici gibi çözümü üretime taşır. Yapay zeka denemesi demoda kalmış, CRM, ERP ya da iç araçlara bağlanamamış şirketler için bu rol en çok işe yarayan çalışma biçimlerinden biridir.

Bu yazıda rolün nereden çıktığını, klasik danışmanlıktan ve yazılım tedarikinden farkını, bir FDE'nin ilk haftalarda ne yaptığını ve şirketinizin böyle bir role ne zaman ihtiyaç duyduğunu anlatıyorum.

Forward Deployed Engineer rolü nereden çıktı?

Rol, 2010'ların başında Palantir'de ortaya çıktı. Palantir bu mühendislere şirket içinde "Delta" adını verdi. Şirketin kendi anlatımına göre Delta'lar yazılım platformunu müşteriye kurar, müşterinin iş sorununa göre uyarlar ve başarılarını müşterinin hedefine etkisiyle ölçer. Palantir'in Dev ile Delta rollerini karşılaştıran yazısı farkı tek cümleyle özetler: klasik yazılım mühendisi "tek yetenek, çok müşteri" için çalışır, FDE ise "tek müşteri, çok yetenek" için çalışır.

Son iki yılda rol, yapay zeka şirketleriyle birlikte yeniden gündeme geldi. Bunun nedeni basit: dil modelleri güçlü, ama bir modelin şirketin verisine, yetki yapısına ve günlük iş akışına bağlanması hâlâ elle yapılan mühendislik işidir. The Pragmatic Engineer'ın FDE yazısı rolün neden bu kadar aranır hale geldiğini ayrıntılı biçimde anlatır.

Forward Deployed Engineer ne iş yapar?

Bir FDE'nin işi toplantıda başlar, ama asıl kısmı ekibin günlük çalışmasının içinde geçer. Tipik sorumluluklar şunlardır:

• İş akışını yerinde öğrenmek: Satış, operasyon ya da destek ekibinin bir işi bugün nasıl yaptığını izler. Hangi ekranı açtıklarını, hangi veriyi nereden aldıklarını ve nerede beklediklerini not eder.
• Kullanım senaryosunu daraltmak: "Yapay zekayı CRM'e bağlayalım" gibi geniş bir isteği başlangıcı ve bitişi belli tek bir işe indirir.
• Entegrasyonu kendisi yazmak: Modeli CRM, ERP, e-posta ya da doküman arşivine bağlayan kodu, yetki ayarlarını ve test senaryolarını kendisi hazırlar.
• Gerçek veriyle denemek: İlk sürümü örnek veriyle değil, ekibin gerçek kayıtlarıyla ve kontrollü bir yetkiyle dener.
• Geri bildirimi koda çevirmek: Kullanıcıların itirazlarını ve takıldıkları yerleri haftalık tekrar döngüsünde düzeltir.
• Bilgiyi ekibe devretmek: Sistemin nasıl çalıştığını, nerede durduğunu ve nasıl izleneceğini şirketin kendi ekibine öğretir.

Bu listedeki her madde tek başına yeni değildir. FDE'yi farklı kılan, hepsinin aynı kişide toplanmasıdır.

FDE, klasik yapay zeka danışmanından nasıl ayrılır?

Klasik danışmanlık çoğu zaman bir analiz, bir yol haritası ya da bir öneri raporuyla biter. Rapor değerlidir, ama uygulamayı başka bir ekibe bırakır. Bu devir sırasında bilginin önemli bir kısmı kaybolur.

FDE ise önerdiği şeyi kendisi kurar. Palantir'in aynı yazısında Delta'lar kendi işlerini danışmanlıktan ayırırken bu noktanın altını çizer: danışmanlar genellikle tek seferlik bir analiz ya da öneri üretir, FDE ise kalıcı bir çözümü müşteriyle birlikte kurar.

Farkı somut biçimde görmek için üç modeli yan yana koymak işe yarar:

Konu	Klasik danışmanlık	Yazılım tedarikçisi	Forward Deployed Engineer
Çıktı	Rapor ve yol haritası	Şartnameye göre teslim edilen yazılım	Çalışan iş akışı ve devredilen bilgi
Gereksinim	Görüşmelerden toplanır	Proje başında yazılır	Gerçek kullanım sırasında netleşir
Kod	Yazılmaz ya da başkasına bırakılır	Tedarikçi yazar	Ekibin yanında, aynı kişi yazar
Değişiklik	Yeni bir çalışma gerektirir	Ek iş talebi olur	Haftalık döngünün parçasıdır

Danışman ile çözüm ortağı arasındaki farkı daha ayrıntılı görmek isterseniz yapay zeka çözüm ortağı ile yazılım tedarikçisi arasındaki farkı anlatan yazıya bakabilirsiniz.

Gereksinimler neden toplantıda değil sahada ortaya çıkar?

Yapay zeka projelerinde en sık görülen sorun, demonun iyi çalışıp gerçek sistemde tökezlemesidir. Bunun nedeni çoğu zaman model değildir. Asıl neden, iş akışının yazılı olmayan kurallarıdır.

Bir satış ekibi "aktif müşteri" dediğinde CRM'deki alanı değil, son üç ayda konuşulan firmaları kastediyor olabilir. Bir operasyon ekibi ERP'deki sipariş durumuna değil, depodaki sorumlunun gönderdiği e-postaya güveniyor olabilir. Bu tür kurallar toplantıda nadiren söylenir, çünkü insanlar onları kural olarak görmez. Sistem gerçek veriyle kullanılmaya başlandığında ise hemen görünür hale gelir.

FDE'nin ekibin yanında durmasının nedeni budur. Kullanıcı "bu cevap yanlış" dediğinde mühendis aynı gün nedenini görür ve düzeltir. Bu döngü bir şartname ve onay zinciriyle yürütüldüğünde haftalar alır.

Bir FDE ilk 30 günde neler yapar?

Aşağıdaki akış, orta ölçekli bir şirketin satış destek ekibi için kurgulanmış bir örnektir. Gerçek bir müşteri vakası değildir. Amacı, rolün gündelik işini somut hale getirmektir.

1. hafta, gözlem ve seçim. Mühendis ekipte teklif hazırlayan iki kişiyle birlikte oturur. Bir teklifin hazırlanması için CRM'den müşteri bilgisinin, ERP'den fiyat listesinin ve paylaşılan klasörden eski tekliflerin elle toplandığını görür. Bu iş tek bir kullanım senaryosu olarak seçilir: asistan bu üç kaynaktan bilgiyi toplayıp temsilciye bir teklif taslağı hazırlar, ama müşteriye göndermez.

2. hafta, salt okuma entegrasyonu. Asistan CRM, ERP ve klasöre yalnızca okuma yetkisiyle bağlanır. İlk taslaklar ekibin gerçek talepleri üzerinde denenir. Bu aşamada sistemin hiçbir kayda yazma yetkisi yoktur.

3. hafta, düzeltme döngüsü. Temsilciler taslakların nerede yanlış olduğunu işaretler. Örneğin eski bir fiyat listesinin hâlâ klasörde durduğu ve asistanın onu kullandığı ortaya çıkar. Mühendis hangi kaynağın geçerli kabul edileceğini kurala bağlar.

4. hafta, ölçüm ve devir. Ekip, taslağın kaç kez düzeltme gerektirdiğini ve hazırlık süresinin nasıl değiştiğini kendi kayıtlarıyla izler. Mühendis sistemin nasıl izleneceğini ekibe öğretir ve bir sonraki iş akışı için aday listesini çıkarır.

Bu örnekte başarıyı belirleyen şey modelin seçimi değildir. Başarıyı, doğru işin seçilmesi ve gerçek veriyle hızlı düzeltme yapılması belirler. İlk iş akışının nasıl seçileceğini 30 günlük yapay zeka pilotu çerçevesinde ayrıntılı anlattık.

Şirketinizin bir Forward Deployed Engineer'a ihtiyacı olduğunu nasıl anlarsınız?

Her yapay zeka işi için FDE gerekmez. Hazır bir aracın kurulumu ya da tek bir ekibin kullandığı basit bir otomasyon için bu rol fazla kalabilir. Aşağıdaki işaretlerden birkaçı sizde varsa rol değerli hale gelir:

• Bir yapay zeka denemesi yaptınız ve demo iyi çalıştı, ama üretime geçmedi.
• Kullanmak istediğiniz veri birden fazla sistemde duruyor ve sistemler birbirine bağlı değil.
• İş akışınız şirkete özgü kurallar içeriyor ve bu kurallar yazılı değil.
• İçeride yazılım ekibiniz var, ama yapay zeka entegrasyonuna ayıracak zamanı yok.
• Tedarikçiye verdiğiniz şartnameler proje başladıktan sonra sürekli değişiyor.

İçeride ekip kurmak ile dışarıdan ortak almak arasında kararsızsanız iç ekip mi dış ortak mı sorusunu ele alan yazımız karar için bir başlangıç noktası sunar.

Bir FDE ile çalışmaya başlamadan önce neleri hazırlamalısınız?

FDE'nin hızı, şirketin ona açtığı erişimle doğru orantılıdır. Başlamadan önce şu dört konuyu netleştirmek ilk haftaları kısaltır:

1. Tek bir iş akışı: Başlangıcı, bitişi ve sorumlusu belli bir iş seçin. İlk iş akışı sık tekrarlanan ve hata yapıldığında geri alınabilen bir iş olmalıdır.
2. Bir iş sahibi: Ekipten, mühendisin sorularını aynı gün yanıtlayabilecek bir kişi belirleyin.
3. Erişim ve yetki planı: Hangi sisteme salt okuma, hangisine taslak, hangisine onaylı yazma yetkisi verileceğini yazın. Bu konuyu yapay zeka asistanını mevcut sistemlere bağlama rehberimizde adım adım anlattık.
4. Başarı ölçütü: Neyin iyileşmesini beklediğinizi proje başında ölçülebilir biçimde tanımlayın ve bugünkü durumu kaydedin.

Binode bu rolü nasıl ele alıyor?

Binode'da danışmanlık ile yazılım geliştirmeyi aynı ekipte tutuyoruz. Bunun nedeni, gereksinimlerin önemli kısmının ekip sistemi gerçek veriyle kullanmaya başladığında ortaya çıkmasıdır. Bir iş akışını seçip onu uçtan uca çalışır hale getirmeden ikinci bir işe geçmemeyi tercih ediyoruz.

Şirketinizde bir yapay zeka denemesi var ama üretime geçmediyse, tek bir iş akışını seçip oradan başlamanızı öneriyoruz. Bu konuyu konuşmak isterseniz iletişim sayfamızdan bize yazabilirsiniz.

Sık sorulan sorular

Forward Deployed Engineer ile solutions engineer aynı şey mi?

Tam olarak aynı değildir. Solutions engineer çoğu zaman satış sürecinde ürünü tanıtır ve kurulumu destekler. FDE ise satıştan sonra müşterinin ekibinin içinde çalışır, kodu yazar ve çözümü üretime taşır.

FDE yalnızca büyük şirketler için mi gerekir?

Hayır. Rolün değeri şirket büyüklüğünden çok iş akışının karmaşıklığına bağlıdır. Birden fazla sisteme dokunan ve yazılı olmayan kurallar içeren bir iş akışı küçük bir şirkette de FDE yaklaşımından yararlanır.

Bir FDE projesi ne kadar sürer?

Süre, seçilen iş akışına ve sistemlere erişimin ne kadar hızlı açıldığına bağlıdır. Tek bir iş akışıyla başlayan ve haftalık döngüyle ilerleyen bir çalışma, ilk somut sonucu genellikle birkaç hafta içinde gösterir. Kesin süreyi ilk haftadaki gözlemden sonra vermek daha doğrudur.

FDE şirketin kendi yazılım ekibinin yerini alır mı?

Almaz. FDE'nin hedeflerinden biri, kurduğu sistemi şirketin kendi ekibinin izleyebileceği ve geliştirebileceği hale getirmektir. Bu yüzden devir, işin başından itibaren planın parçasıdır.

---

Yazar: Abdullah Oğuz. Binode'un kurucusudur. Kurumsal yapay zeka dönüşümü, yapay zeka çevresinde yazılım entegrasyonu ve B2B müşteri bulma sistemleri üzerine çalışır.

Kapak fotoğrafı: cottonbro studio / Pexels