Hizmet
AI WorkflowEngineering
Ekibinizin zamanını alan işleri, kontrollü yapay zekâ iş akışlarına dönüştürüyoruz. Teklif hazırlama, içerik kontrolü, talep sınıflandırma ve katalog bakımı gibi süreçleri; şirket verileriniz, iş kurallarınız, sistem bağlantılarınız ve insan onaylarınızla birlikte tasarlıyoruz.
Tanım
AI Workflow Engineering nedir?
AI Workflow Engineering, bir işin tamamlanması için yapay zekâ modellerinin, şirket bilgilerinin, yazılım sistemlerinin, iş kurallarının ve insan müdahalelerinin birlikte tasarlanması, uygulanması ve izlenmesidir. Türkçede yapay zekâ iş akışı mühendisliği olarak ifade edilebilir.
Bir teklif hazırlama sürecinde CRM kaydı okunur, eksik bilgiler belirlenir, onaylı hizmet ve fiyat kaynakları bulunur, taslak üretilir, tutarlılık kontrol edilir ve yetkili kişinin değerlendirmesine sunulur. İşin tamamlandığına ilişkin karar, yalnız modelin ürettiği metne dayanmaz; belirlenen kabul koşulları ve hedef sistemdeki kayıt da kontrol edilir.
Bir AI iş akışının kapsamı şu sorularla netleşir: İş nasıl başlıyor? Hangi bilgiye erişiliyor? Hangi adımda yapay zekâ gerekiyor? Kim hangi işlemi onaylıyor? Bir bağlantı koptuğunda ne oluyor? İşin doğru tamamlandığını nasıl anlıyoruz?
Uygunluk
Hangi işletmeler ve ekipler için uygun?
Bu hizmet, tekrarlanan iş hacmi bulunan ve süreçteki zaman ya da kalite kaybını ölçebilen ekipler için değerlendirilir. Şirket büyüklüğü kadar verinin erişilebilirliği, sistem bağlantıları ve sürecin sahibinin belli olması önemlidir.
| Ekip | Sık karşılaşılan ihtiyaç | Değerlendirilebilecek başlangıç |
|---|---|---|
| Pazarlama ve içerik | Çok sayıda taslağın marka, kaynak ve ürün bilgisi açısından incelenmesi | İçerik kalite kontrolü ve editöre işaretli taslak |
| B2B satış | CRM, fiyat listesi ve hizmet bilgisinden teklif hazırlanması | Kaynaklı teklif taslağı ve eksik bilgi kontrolü |
| Müşteri hizmetleri | Gelen taleplerin doğru ekibe yönlendirilmesi ve güncel yanıtın bulunması | Talep sınıflandırma ve temsilciye yanıt önerisi |
| E-ticaret | Ürün alanları, açıklamalar ve politikalar arasında tutarsızlık | Ürün bilgisi kontrolü ve onaylı güncelleme kuyruğu |
| Büyüme ve operasyon | Farklı raporlardan düzenli karar özeti hazırlanması | Kaynakları izlenebilen rapor ve aksiyon taslağı |
| Çok markalı yapılar | Her marka için ayrı bilgi, dil ve onay düzeni | Marka bazlı erişim ve kontrol akışları |
İlk görüşmede son dönemdeki iş adedi, hazırlık ve kontrol süresi, sık hata türleri, kullanılan sistemler ve karar sahibi belirlenir. Az tekrarlanan, sürekli kapsam değiştiren ya da doğru bilgi kaynağı bulunmayan işler için önce süreç düzenleme gerekebilir. Basit bir yazılım kuralı ihtiyacı karşılıyorsa gereksiz yapay zekâ katmanı eklenmez.
Örnekler
Hangi iş akışlarını tasarlayabiliriz?
Aşağıdaki senaryolar hizmetin uygulanabileceği örnekleri gösterir. Entegrasyon, veri erişimi, otomatik eylemler ve kabul koşulları proje kapsamında belirlenir. Bunlar tamamlanmış müşteri vakası değildir.
Kaynaklı teklif hazırlama
Satış ekibi, CRM'deki müşteri ihtiyacını onaylı hizmet kapsamı ve fiyat bilgisiyle bir araya getirir. İş akışı gerekli alanları kontrol eder, uygun kaynakları seçer ve düzenlenebilir bir teklif taslağı hazırlar. Kapsam, fiyat, para birimi ve geçerlilik tarihi birlikte doğrulanır. İlk pilotta gönderim, indirim kararı ve bağlayıcı taahhüt yetkili kişide kalabilir.
Ölçüm: Kabul edilen teklif başına toplam insan süresi, fiyat ve kapsam hatası, yeniden çalışma.
İçerik kalite kontrolü ve yayın hazırlığı
İçerik taslağı; marka terminolojisi, güncel ürün bilgisi ve izin verilen kaynaklarla karşılaştırılır. Sistem çelişkili iddiayı, eksik kaynağı ve dil sorununu gerekçesiyle işaretler. Bir metnin akıcı olması doğruluğu kanıtlamaz; sayısal iddialar ve önemli ürün özellikleri kaynakla eşleştirilir. Yayın kararı editörde kalır.
Ölçüm: Kaçırılan kritik hata, yanlış alarm, kontrol süresi ve ilk incelemede kabul.
Müşteri talebi sınıflandırma ve yanıt desteği
Talep; konu, aciliyet ve ilgili ürün gibi ölçütlerle sınıflandırılır. Yetkili bilgi tabanından uygun içerik bulunur, temsilciye yanıt önerisi ve kaynak sunulur. İade, şikâyet ya da sözleşme yorumu gibi konular ilgili uzmana yönlendirilir. Bilgi bulunamadığında sistem cevap uydurmak yerine eksikliği bildirir.
Ölçüm: Doğru yönlendirme, yanıtın kabulü, çözüm süresi, tekrar başvuru ve insan devrinin uygunluğu.
Ürün bilgisi ve katalog bakımı
Ürün açıklamaları ile PIM, ERP ya da başka yetkili kayıtlar karşılaştırılır. Eksik alan, yanlış varyant, güncelliğini yitirmiş özellik ve kanal tutarsızlığı değişiklik önerisine dönüşür. İş akışı ürün gerçeğini modelin tahminiyle doldurmaz; güncelleme yetkisi varsa belirlenmiş alanlarla sınırlı işlem yapılır.
Ölçüm: Doğru alan oranı, kabul edilen güncelleme, yanlış kayda yazma ve güncelleme gecikmesi.
Raporlama ve aksiyon hazırlığı
Analitik, reklam, CRM ya da destek sistemlerindeki veriler tanımlı dönem ve metriklerle birleştirilir. Hesaplamalar kod veya güvenilir veri sorguları üzerinden yapılır; yapay zekâ bulguların açıklanmasına yardımcı olur. Kaynağı gelmeyen veri tahminle tamamlanmaz; gözlenen değişim ile olası neden ayrılır.
Ölçüm: Sayısal doğruluk, veri tamlığı, rapor hazırlama süresi ve analistin düzeltme yükü.
Marka bilgisi ve itibar güncelleme akışları
Ölçüm ya da araştırma sürecinden gelen yanlış bilgi, eski açıklama veya kaynak değişikliği kaydı kontrol edilebilir bir göreve çevrilir. Doğru bilgi ve sorumlusu bulunur, düzeltme taslağı hazırlanır ve gereken onaya yönlendirilir. Bu akış, dış yapay zekâ platformunun yanıtını doğrudan değiştirme yetkisi sağlamaz.
Ölçüm: Bilginin doğrulanma ve güncellenme süresi, eksik kaynaklar ve açık kalan işler.
Çalışma örneği
Bir teklif iş akışı nasıl çalışır?
Aşağıdaki örnekte amaç, satış sorumlusunun inceleyebileceği kaynaklı teklif taslağı hazırlamaktır. Müşteriye otomatik gönderim örneğin kapsamına dahil değildir.
| Adım | Yapılan iş | Kontrol |
|---|---|---|
| 1. Talebi alma | CRM kaydı veya formdan ihtiyacı almak | Kullanıcının kayda erişimi, zorunlu alanlar, görev kimliği |
| 2. Bilgiyi bulma | İlgili hizmet, fiyat ve kapsam kayıtlarını seçmek | Yetki, kaynak sürümü ve geçerlilik |
| 3. Taslak üretme | İhtiyaca uygun metni ve kapsam önerisini hazırlamak | Kaynak bağlantıları ve eksik bilgi işaretleri |
| 4. Doğrulama | Fiyat, para birimi, alanlar ve kapsamı kontrol etmek | Kod kuralları ve gerekli uzman incelemesi |
| 5. Onay | Değişiklikleri yetkili kişiye göstermek | Onayın belirli taslak ve kaynak sürümüne bağlı olması |
| 6. Kaydetme | Onaylı taslağı yetkili sisteme yazmak | Aynı işin ikinci kez yazılmaması |
| 7. Sonucu doğrulama | Doğru müşteri kaydında doğru sürümün bulunduğunu kontrol etmek | Hedef kayıt ve işlem sonucu |
Onay henüz verilmemişse görev beklemede kalır; ret ya da düzeltme isteğinde kayıt işlemi yapılmaz. İlk uygulamada kontrollü bir süreç seçmek; kalite sorununun kaynaktan mı, modelden mi, kurallardan mı yoksa bağlantıdan mı geldiğini anlamayı kolaylaştırır.
Teslimler
Hizmet kapsamında neler teslim edilir?
Teslimler seçilen aşamaya bağlıdır. Keşif çalışması ile çalışan üretim sistemi aynı teslim sayılmaz; kapsam ve kabul koşulları proje başlangıcında yazılır.
| Teslim | İçerik | Müşteri açısından karşılığı |
|---|---|---|
| Süreç ve fırsat haritası | Mevcut adımlar, sahipler, süre, hata ve darboğazlar | Hangi işe neden başlanacağını görme |
| Fizibilite ve iş gerekçesi | Veri ve erişim uygunluğu, toplam maliyet, fayda varsayımları | Devam, kapsam daraltma veya durdurma kararı |
| İş akışı tasarımı | Girdi ve çıktı, yapay zekâ ile kural adımları, onay, hata yolları | Uygulama ekibinin kullanabileceği teknik ve iş tanımı |
| Entegrasyon kapsamı | Dahil sistemler, izinler, alanlar ve veri akışı | Hangi bağlantının hangi işlemi yapacağını bilme |
| Pilot uygulama | Kapsamdaki çalışan akış ve sınırlı kullanım | Gerçek örneklerde doğrulanabilen davranış |
| Değerlendirme paketi | Test senaryoları, ölçütler, sonuçlar ve bilinen sınırlar | "Çalışıyor" kararının dayanağı |
| Operasyon görünümü | Başarı, hata, bekleyen iş, insan devri, süre ve maliyet | Günlük durumu izleme |
| Devir ve işletim dokümanı | Sürümler, sorumlular, erişim ve hata yönetimi | Bakımı ve ekip değişimini yönetme |
Kaynak kodu ve akış dosyalarının teslimi, mevcut bileşenlerin lisansları, kullanım hakları ve platform hesaplarının sahipliği sözleşmede açıkça belirlenir. Üçüncü taraf yazılımın lisansı proje teslimiyle ortadan kalkmaz.
Süreç
Keşiften canlı kullanıma nasıl ilerliyoruz?
Süreç keşfi ve fizibilite
Mevcut işin başlangıç ve bitişini, iş adedini, insan süresini, hata türlerini ve kullanılan sistemleri inceleriz. Süreç sahibiyle kabul edilebilir sonucu tanımlarız. Çıktı; sınırları belli ilk iş akışı, başlangıç ölçümü, veri ve erişim ihtiyaçları ile gerekçeli bir devam kararıdır. Fizibilite, otomasyonun bu süreçte ekonomik olmadığını da gösterebilir.
Mimari ve kontrol tasarımı
Her adımın hangi bilgiye erişeceği, hangi işlemi yapabileceği, ne zaman duracağı ve kime devredileceği belirlenir. Sayısal hesaplar ve kesin iş kuralları uygulama katmanına yerleştirilir; yapay zekâ yorumlama veya üretim gerektiren adımlarda kullanılır. Çıktı; akış şeması, veri sözleşmesi, erişim ve onay düzeni, model seçimi gerekçesi ve değerlendirme planıdır.
Pilot ve kalite değerlendirmesi
Kapsamdaki akış geliştirilir; geliştirmede kullanılmamış örnekler ve hata senaryolarıyla değerlendirilir. İlk kullanım gölge çalışma veya sınırlı kullanıcı grubuyla başlayabilir. Gölge çalışmada akış gerçek işe paralel öneri üretir; yetkili sisteme kendiliğinden yazmaz. Demo görünümü, üretim kabulünün yerine geçmez.
Üretime alma ve ekip devri
Erişim, performans, alarm, bekleyen işler ve manuel işleyişe dönüş kontrol edilir. İlgili ekipler onay ekranını, istisna kuyruğunu ve hata bildirimini kullanmayı öğrenir. Çıktı; kapsamı kabul edilmiş canlı kullanım, isimlendirilmiş süreç ve teknik sahipleri ile işletim planıdır.
İşletim ve iyileştirme
Model, API, veri ve iş kuralları zamanla değişebilir. İşletim kapsamı; hata takibi, kalite örneklemesi, sürüm değerlendirmesi ve kararlaştırılmış değişiklikleri içerir. Destek saatleri, olay öncelikleri, müdahale ve çözüm hedefleri sözleşmede belirlenir. Kesintisiz destek ancak buna uygun ekip ve teknik düzenle sunulur.
Çalışma modeli
Nasıl birlikte çalışabiliriz?
| Çalışma biçimi | Uygun ihtiyaç | Kapsamın sınırı |
|---|---|---|
| Keşif ve mimari tasarım | Yatırım öncesi süreç, değer ve uygulama planını netleştirmek | Çalışan entegrasyon teslimi ayrıca kapsamlandırılır |
| Tasarım ve pilot uygulama | Tek bir süreci gerçek örneklerde çalıştırıp değerlendirmek | Kullanıcı, sistem, işlem ve hacim sınırları belirlenir |
| Müşteri ekibiyle uygulama | Mevcut teknik ekip veya uygulama ortağıyla ilerlemek | Geliştirme, dağıtım, kabul ve bakım sorumluları ayrı yazılır |
| Yönetilen işletim | Kabul edilmiş akışı düzenli takip etmek ve geliştirmek | Destek saatleri ve değişiklik kapsamı açıkça belirlenir |
Planlama örneği olarak, erişimleri hazır tek bir süreç için keşif 1 ila 2 hafta, pilot 4 ila 6 hafta olarak ele alınabilir. Bunlar sabit teslim taahhüdü değildir. Veri hazırlığı, yeni bağlantılar, onay süreçleri ve test sonuçları takvimi değiştirir.
Metrikler
Başarıyı hangi metriklerle ölçüyoruz?
Hedef, işe başlamadan önce tanımlanır. Daha çok taslak üretmek, daha çok model çağırmak veya daha fazla adımı otomatikleştirmek tek başına başarı değildir. Sonucu kalite, kapsam ve gerçek insan yüküyle birlikte değerlendiririz.
| Ölçüt | Tanım | Yorum |
|---|---|---|
| Uçtan uca tamamlanma | Belirlenen sürede kabul edilmiş sonuç bölü tanımlı iş grubundaki akışa alınmış uygun işler | Başarısız ve devredilen işler gizlenmez |
| İlk denemede kabul | Yeniden deneme veya düzeltme olmadan kabul edilen işler bölü aynı gruptaki uygun işler | Sonradan düzeltilen başarıdan ayrı raporlanır |
| İnsan süresi | Hazırlık, kontrol, düzeltme ve istisna yönetimi süresi | Yalnız taslak üretim süresiyle sınırlanmaz |
| Kritik hata | Yanlış fiyat, yanlış müşteri, yetkisiz işlem veya belirlenmiş ciddi hata | Ortalama puanla örtülmez, ayrı incelenir |
| Hata kaçırma ve yanlış alarm | Gerçek hatayı atlama; doğru çıktıya gereksiz itiraz | İçerik ve kalite kontrolünde birlikte değerlendirilir |
| Kabul edilen iş başına maliyet | Kapsamdaki toplam işletim ve insan maliyeti bölü kabul edilmiş sonuçlar | Başarısız denemelerin maliyeti de dahildir |
| İnsan devri | İnsana geçen uygun işler bölü aynı gruptaki akışa alınmış uygun işler | Gereken devir doğru davranış olabilir |
| Çevrim süresi | İşin alınmasından doğrulanmış sonucuna kadar geçen süre | İnsan onayı bekleme süresi dahil, bileşenleriyle gösterilir |
| Benimseme | Akışa alınan uygun işler bölü dönemdeki toplam uygun işler | Demo ilgisi ve aktif kullanım ayrılır |
Bekleyen işler ayrıca gösterilir. Aynı görevin üç kez denenmesi üç tamamlanmış iş sayılmaz. Gelir ya da dönüşüm etkisi iddia edilecekse uygun bir karşılaştırma ve takip dönemi gerekir; üretim hızı tek başına satış artışını kanıtlamaz.
Kavramlar
Otomasyon, workflow, ajan ve chatbot arasındaki fark
Bir işin adımları belirliyse yapay zekâ destekli workflow uygun olabilir. Gerekli alt adımlar önceden kestirilemiyorsa, sınırları tanımlanmış bir ajan bazı kararları dinamik verebilir.
| Kavram | Esas rolü | Örnek |
|---|---|---|
| Kural tabanlı otomasyon | Açık koşulu belirli işlemle eşleştirmek | Onaylı kaydı ilgili listeye aktarmak |
| Yapay zekâ destekli workflow | Tasarlanmış akışın belirli adımlarında yorumlama veya üretim | Talep sınıflandırma, kaynak bulma, taslak ve onay |
| Yapay zekâ ajanı | Verilen hedef ve sınırlar içinde sonraki adımı ya da araç kullanımını seçmek | İzin verilen kaynaklarda eksik şirket bilgisini araştırmak |
| Chatbot | Kullanıcıyla konuşma arayüzü sunmak | Bilgi sorma veya iş talebi başlatma |
| Arayüz otomasyonu | Uygulamaların arayüzünde işlem yapmak | API'si olmayan eski panelde kontrollü veri girişi |
Bu kavramlar birleşebilir. Bir chatbot iş akışını başlatabilir; bir iş akışı yapay zekâ ajanı çağırabilir; arayüz otomasyonu model yorumu kullanabilir. Seçim; işin belirsizliği, mevcut sistemler, kontrol ihtiyacı ve bakım maliyetine bağlıdır.
Teknik rehber
Teknik olarak bir AI iş akışı nasıl kurulur?
Her işe benzersiz bir görev kimliği verilir. Girdi, kullanılan kaynak sürümü, akış ve model sürümü, denemeler ve işin durumu ilişkilendirilir. "Onay bekliyor", "düzeltme gerekiyor", "işlem sonucu belirsiz" ve "tamamlandı" farklı durumlardır. Bir servis zaman aşımına uğradığında dış sistemde işlem gerçekleşmiş olabilir; aynı isteği körlemesine tekrarlamak yerine hedef kayıt kontrol edilir. Mümkün olduğunda idempotency anahtarı ve kayıt sürümü gibi mekanizmalarla yinelenen işlem önlenir.
Para birimi, fiyat listesi, indirim sınırı, zorunlu alan ve yetki kontrolü gibi kesin koşullar modele bırakılmamalıdır. Yapay zekâ; metin yorumlama, sınıflandırma, özetleme veya taslak üretimi için kullanılabilir. Yapılandırılmış çıktı biçimi, alanların doğruluğunu tek başına garanti etmez. Bir modelin "eminim" demesi, doğrulanmış bir güven olasılığı değildir.
Düzeltme döngülerine deneme, süre ve maliyet sınırı konur. Sınır dolunca görev aynı hatayı tekrarlayarak sürdürülmez; uygun kuyruğa devredilir. Uzun insan onaylarında durumun uygulama yeniden başlasa da korunması gerekir. Kalıcılık uygun bir checkpointer ve depolama düzeniyle sağlanır; yalnız bellek içi saklama üretim yeniden başlamasında aynı güvenceyi vermez.
Zincirleme, işin sabit alt adımlara ayrılmasıdır. Yönlendirme, girdiye göre uygun yolun seçilmesidir. Paralel çalışma, bağımsız kontrollerin aynı anda yürütülmesidir. Koordinatör ve çalışanlar deseninde alt görevler ihtiyaçla belirlenir. Değerlendirme ve iyileştirme deseninde çıktı ölçütlerle tekrar gözden geçirilir. Bu desenler birbirini dışlamaz; karmaşıklık ölçülen ihtiyaca göre eklenir.
Bir modele verilen bağlam; görev talimatını, ilgili belgeleri, araç tanımlarını, önceki adımların gerekli sonuçlarını ve izinleri içerebilir. Context engineering bu bilginin seçimini, kapsamını ve güncelliğini tasarlar. Müşteri ve marka sınırları korunur; eski fiyat, ilgisiz kayıt ve başka müşteriye ait bilgi bağlama karışmamalıdır. Prompt tasarımı bu çalışmanın bir parçasıdır, eksik veriyi tek başına gidermez.
RAG, yanıt veya taslak hazırlanmadan önce ilgili dış bilginin bulunup modele sunulması yaklaşımıdır. Dosya havuzu, veritabanı, arama altyapısı veya başka yetkili kaynaklar kullanılabilir; her proje için vektör veritabanı zorunlu değildir. Kaynağın tarihi, sahibi, erişim hakkı ve sürümü önemlidir. RAG bütün yanlış yanıtları ortadan kaldıran bir garanti değildir.
Model Context Protocol, yapay zekâ uygulamalarının araç ve kaynaklarla bağlantısını tanımlayan bir protokoldür. Kullanılabilir, ancak standart API veya mevcut bağlayıcı ihtiyacı karşılıyorsa ayrıca eklenmesi gerekmez. Protokolün yetkilendirme mekanizmaları bulunur; bunların varlığı işletmenin kayıt düzeyindeki izinlerini ve işlem onayını otomatik uygulamaz. Ürünün adı, verinin doğru olduğunu kanıtlamaz.
Değerlendirme
Kalite testleri ve değerlendirme nasıl yapılır?
Bir AI iş akışı, normal girdiler kadar eksik, çelişkili veya hatalı koşullarda da değerlendirilmelidir. Klasik yazılım testleri, model çıktısının değerlendirilmesi ve uzman incelemesi farklı soruları cevaplar.
| Değerlendirme katmanı | Kontrol edilen | Örnek |
|---|---|---|
| Yazılım ve entegrasyon testleri | Kurallar, alanlar, yetkiler, bağlantı ve tekrar davranışı | Aynı isteğin iki kayıt üretmemesi |
| Çıktı değerlendirmesi | Doğruluk, kapsam, kaynakla tutarlılık ve görev başarısı | Teklifteki hizmetin briefle uyumu |
| Uzman incelemesi | Belirsiz, bağlamsal veya önemli iş kararları | Yanıtın politika ve müşteri durumu açısından uygunluğu |
| İş sonucu doğrulaması | Hedef sistemde doğru sonucun bulunması | Doğru müşteri kaydında onaylı taslak |
Pilot için hangi senaryolar hazırlanır?
Başlangıçta temsil gücü olan geçmiş işler seçilir. Geliştirme örnekleriyle kabul örnekleri ayrılır. Kabul senaryoları arasında eksiksiz talep, eksik fiyat ya da müşteri bilgisi, çelişen kaynaklar, yetkisiz kullanıcı, harici belgede iş akışını yönlendirmeye çalışan talimat, aynı isteğin tekrarı, bağlantının kopması ve onay beklerken fiyatın değişmesi bulunur.
Pilot ne zaman başarılı sayılır?
Kabul ölçütleri test sonucunu gördükten sonra değiştirilmez. Uygun işlerde kalite tabanı, insan yükü, işlem doğruluğu ve maliyet birlikte değerlendirilir. Kritik bir hata ortalama kalite puanının içinde gizlenmez. Model çıktısı aynı girdide değişebileceğinden kritik görevler birden fazla denemeyle değerlendirilir; yalnız en başarılı deneme raporlanmaz.
Yetki ve güvenlik
İnsan onayı, yetki ve veri güvenliği nasıl tasarlanır?
Özerklik tek bir aç ya da kapat kararı değildir. Bilgi okuma, taslak üretme, iç kaydı güncelleme, müşteriye mesaj gönderme ve finansal taahhüt oluşturma farklı yetkilerdir. İş akışı, görevin ihtiyaç duyduğu erişimle sınırlandırılır.
Onay ekranında ne görülmeli?
Onay veren kişi; hangi kaydın değişeceğini, mevcut ve önerilen değeri, kaynağı, işlem kapsamını ve varsa tutarı görebilmelidir. Kaynak veya kritik parametre değişirse önceki onayın geçerliliği yeniden kontrol edilir. Müşteri adına iletişim göndermek, taslak hazırlamadan ayrı bir işlem olarak yetkilendirilir.
Harici belgelerdeki talimatlar
Web sayfası, PDF veya e-posta, iş akışının okuyacağı veridir. Bu içerikteki "önceki kuralları yok say" gibi ifadeler uygulamanın izinlerini değiştiremez. İzin verilen araçlar, hedefler ve işlem parametreleri uygulama katmanında sınırlandırılır. İzinli bir araç da yanlış hedefle kullanılabilir; yetki sınırları tek başına bu riski ortadan kaldırmaz.
Veriler nerede işlenir ve saklanır?
Veri akış haritası; kaynak sistemi, modele gönderilen alanları, barındırmayı, logları, değerlendirme örneklerini ve bağlı hizmetleri kapsar. Kendi sunucunuzda çalışan bir otomasyon harici model API'si çağırıyorsa ilgili veri sunucu dışına çıkabilir. KVKK gereksinimleri gerçek kullanım üzerinden değerlendirilir; hukuki değerlendirme ile teknik uygulama sorumluluğu proje içinde belirlenir.
Teknoloji
Hangi teknolojileri kullanıyoruz?
Teknoloji seçimi, müşterinin mevcut sistemleri ve iş akışının ihtiyaçlarıyla başlar. Hazır bağlayıcı, görsel otomasyon, özel kod ve yönetilen platform seçenekleri; yetki, veri akışı, test edilebilirlik, bakım ve toplam maliyetle karşılaştırılır. Aşağıdakiler değerlendirilebilecek seçeneklerdir; her projede kullanılmaları gerekmez.
| İhtiyaç | Değerlendirilebilecek seçenek | Seçim ölçütü |
|---|---|---|
| Sistem bağlantıları ve görsel akış | n8n, Make, Zapier veya mevcut platformun otomasyonu | Bağlayıcı kapsamı, hata davranışı, lisans ve hacim maliyeti |
| Özel durum ve akış kontrolü | Özel uygulama kodu, gerektiğinde LangGraph | Test, kalıcı durum ve uygulama ekibinin yetkinliği |
| Uzun bekleme ve güvenilir yürütme | Mevcut kuyruk altyapısı veya Temporal gibi çözümler | Kalıcılık, tekrar davranışı ve işletim yükü |
| Kurumsal çalışma ortamı | Microsoft veya Salesforce ekosistemindeki mevcut yetenekler | Var olan lisans, veri sınırları ve kurumun teknik düzeni |
| Model kullanımı | Göreve uygun API veya uygun şartlarda yerel model | Kalite, gecikme, veri koşulları ve toplam maliyet |
| Bilgi erişimi | Mevcut arama, dosya, SQL ve API, gerekirse vektör arama | Güncellik, kaynak bulunabilirliği ve erişim hakları |
| İzleme ve değerlendirme | Mevcut gözlemleme düzeni veya uygun uzman araç | İş kimliğinden sonuca ve maliyete izlenebilirlik |
Bir fiyatlandırma birimi, tamamlanmış iş birimiyle aynı olmayabilir. Yeniden denemeler, model kullanımı ve insan kontrolü toplam maliyete ayrıca yansır. Kaynak kodu erişilebilir bir platformun her ticari kullanım biçimi sınırsız olmayabilir; lisans ve kullanım koşulları teklif döneminde doğrulanır.
Ekonomi
Maliyet ve yatırım değeri nasıl hesaplanır?
İlk hesap, mevcut işi doğru tamamlamak için harcanan insan süresi ve doğrudan giderlerle başlar. Yeni akışta yalnız model ücreti değil; kontrol, düzeltme, istisna, bağlantı, altyapı, değerlendirme ve bakım maliyeti de hesaba katılır.
Kabul edilen iş başına maliyet = Aynı kapsamdaki toplam işletim ve insan maliyeti / Kabul edilmiş iş sayısı. Kabul edilmiş iş sayısı sıfırsa bu metrik hesaplanamaz. Kurulum maliyeti ayrıca gösterilir veya açık bir dönem üzerinden amorti edilir.
Kazanılan zaman nakit tasarrufu mudur?
Her zaman değil. Bir ekip aynı ücretle daha fazla iş yapabilir; bu kapasite kazanımıdır. Gerçek gider azalması veya ek katkı kârı oluşmuşsa finansal etki ayrıca ölçülür. Üç ayrı gösterge kullanmak daha açıklayıcıdır: serbestleşen çalışma saati, yararlı işe aktarılabilen kapasitenin ekonomik karşılığı ve gerçekleşen nakit etkisi. Aynı fayda hem iş gücü tasarrufu hem ek gelir altında iki kez sayılmaz.
Açık varsayımlarla ekonomik değer örneği
Aşağıdaki rakamlar temsili hesaplamadır; Webtures fiyatı, müşteri sonucu veya getiri vaadi değildir. Avro yalnız hesap birimidir. Varsayımlar: mevcut iş başına insan süresi 20 dakika, yeni akışta kontrol ve istisnalar dahil 6 dakika, saatlik iş gücü maliyet karşılığı 35 avro, insan kontrolü dışındaki ek aylık işletim gideri 2.100 avro, başlangıç yatırımı 19.200 avro.
| Senaryo | Aylık uygun iş | Kullanım | Kapasite aktarımı | Kullanılabilir kapasite | Aylık kapasite değeri | Ek gider sonrası net |
|---|---|---|---|---|---|---|
| Düşük | 750 | %60 | %50 | 52,5 saat | 1.837,50 € | −262,50 € |
| Baz | 1.500 | %80 | %70 | 196 saat | 6.860 € | 4.760 € |
| Yüksek | 2.250 | %85 | %80 | 357 saat | 12.495 € | 10.395 € |
Baz senaryo hesabı: 1.500 × 14 / 60 × 0,80 × 0,70 = 196 saat; 196 × 35 = 6.860 €; 6.860 − 2.100 = 4.760 €. Bu modelde başlangıç yatırımını karşılama süresi baz senaryoda yaklaşık 4 işletim ayı, yüksek senaryoda yaklaşık 1,85 aydır. Düşük senaryoda net değer negatif olduğu için geri kazanım süresi hesaplanmaz. Bunlar gerçekleşmiş nakit geri ödeme süresi değildir. Fizibilitenin olumsuz çıkması, yanlış bir yatırımı önleyen değerli bir sonuçtur.
İşletim
Model ve sistemler değiştiğinde akış nasıl yönetilir?
Model, istem, kaynak havuzu, API ve iş kuralı değişiklikleri sürüm olarak kaydedilir. Yeni sürüm önce uygun testlerde değerlendirilir; gerekirse sınırlı kullanımla açılır. Sistemin geri bildirim alması, kendi yetkisini veya çalışma mantığını kontrolsüz değiştirmesi anlamına gelmez.
Günlük işletim görünümünde başarısız işler, artan gecikme, maliyet sıçraması ve bekleyen onaylar yer alır. Her alarmın bir sorumlusu ve yapılacak işlemi bulunur. Bir olayda yazma işlemleri durdurulabilir, etkilenen kayıtlar belirlenir ve manuel işleyişe geçilebilir. Önceki yazılım sürümüne dönmek, daha önce gönderilmiş mesajı veya dış sistemde yapılmış her değişikliği kendiliğinden geri almaz.
Müşteriye devirde akış dosyası veya kodla birlikte sistem envanteri, sürüm bilgisi, testler, izleme, erişim yönetimi ve sorun giderme dokümanı teslim kapsamına alınır. Çalışmanın yalnız tek kişinin bilgisine bağlı kalmaması hedeflenir.
Konum
Diğer AI hizmetlerimizle görev dağılımı
AI Workflow Engineering, belirlenmiş bir işin sistemler arasında tamamlanmasına odaklanır. İlgili hizmetler ise kendi iş sonuçlarını sahiplenir. Aynı bilgi veya bağlantı çalışmasının birden fazla adla tekrar fiyatlanmaması için kapsam birlikte planlanır.
Görünürlük tarafı
Generative Engine Optimization markanın yapay zekâ yanıtlarında bulunmasını sahiplenir. Workflow Engineering; araştırma, içerik kontrolü ve güncelleme iş akışlarını kurar.
İtibar tarafı
Online İtibar Yönetimi marka bilgisinin doğruluğunu ve düzeltme takibini sahiplenir. Workflow Engineering kanıtlı düzeltme görevini ve bilgi bakım sürecini üretir.
Deneyim tarafı
Agent Experience insan ya da dış ajanların görevi tamamlayabilmesini sahiplenir. Workflow Engineering iç sistemlerde görev devrini, bilgi erişimini ve işlem desteğini sağlar.
Ticaret tarafı
Agentic Commerce Readiness ürün ve ticari işlem deneyimini sahiplenir. Workflow Engineering katalog bakımını, uyuşmazlık ve istisna yönetimini yürütür.
Ölçüm tarafı
AI & Agentic Analytics görünürlükten ve görevden gerçek sonuca ölçümü sahiplenir. Workflow Engineering doğru olay, görev ve maliyet kayıtlarını üretir.
Beklenen yaklaşım
Başlangıçta teknoloji kararının gerekçesini, kapsam dışı işleri ve müşteri sorumluluklarını görünür kılarız. Programın çıktısı, ölçülebilen bir süreç ve devredilebilir uygulama bilgisidir.
Sık sorulan sorular
AI Workflow Engineering hakkında
Üretken yapay zekâ danışmanlığı; kullanım senaryosu, teknoloji, veri ve uygulama kararlarını kapsayabilir. AI Workflow Engineering bu kararları belirli bir işin girdisi, adımları, sistem bağlantıları, onayları ve sonucuyla somutlaştırır. Keşif danışmanlığı, pilot uygulama ve işletim farklı kapsamlar olarak satın alınabilir.
Hayır. Kuralları ve adımları açık olan işler basit otomasyonla çözülebilir. Dil yorumlama gereken adımlara yapay zekâ eklenebilir; dinamik araştırma veya araç seçimi ihtiyacı varsa sınırları belirli ajan değerlendirilir. Ajan sayısı kalite ölçütü değildir.
Sohbet arayüzü ihtiyacı varsa kapsamlandırılabilir. Ancak bir form, CRM olayı veya zamanlanmış görev de iş akışını başlatabilir. Hangi arayüzün gerektiği kullanıcı görevine göre belirlenir; her iş için chatbot tasarlanmaz.
API, veri dışa aktarma, mevcut bağlayıcı ve yetki imkânları incelenir. Hazır bağlantı bulunması, bütün alan ve işlem ihtiyaçlarının karşılandığı anlamına gelmez. Özel entegrasyon ve varsa arayüz otomasyonunun bakım maliyeti ayrıca değerlendirilir.
Hayır. Birçok ihtiyaç mevcut model, uygun bağlam, yetkili bilgi erişimi ve iş kurallarıyla karşılanabilir. Fine-tuning veya başka özel model çalışmaları ayrı bir ihtiyaç ve veri değerlendirmesi gerektirir. Güncel fiyat ya da müşteri kaydını modele ezberletmek, kaynağa doğru zamanda erişmenin yerine geçmez.
Bu, model ve barındırma seçimine bağlıdır. API'ye hangi alanların gideceği, kayıtlarda ne saklanacağı ve alt hizmetlerin nerede çalışacağı veri akış haritasında gösterilir. Sağlayıcının veri kullanımı ve saklama koşulları kullanılan ürün ve sözleşme özelinde incelenir.
Her adımda aynı onay gerekmez. Okuma, taslak, iç güncelleme, dış iletişim ve mali sonuç doğuran işlemler ayrı değerlendirilir. Onay, belirsizliği veya işlemin etkisini yönetmeye hizmet etmeli; gerekli bilgiler onay veren kişiye gösterilmelidir.
Önceden bütün işletmelere geçerli bir oran verilemez. Başlangıç iş yükü, kontrol ve düzeltme ihtiyacı, kullanım, kalite ve işletim gideri ölçülür. Kazanılan zaman kapasite oluşturabilir; gerçek nakit tasarrufu ayrıca kanıtlanmalıdır.
Süreç karmaşıklığı, bağlantılar, veri hazırlığı, işlem yetkileri, değerlendirme, hacim ve destek kapsamı esas alınır. Keşif, pilot, üretime geçiş ve aylık işletim bedelleri ayrı gösterilebilir. Platform ve harici model ücretlerinin dahil olup olmadığı teklifte belirtilir.
Tek süreç ve hazır erişim için 1 ila 2 haftalık keşif ve 4 ila 6 haftalık pilot bir planlama örneği olabilir. Yeni sistem bağlantısı, veri sorunu veya ek onay ihtiyacı süreyi değiştirir. Üretime geçiş kararı test ve kabul sonuçlarına bağlıdır.
Hata türüne göre yeniden deneme, düzeltme kuyruğu, insan devri veya yazma işlemlerini durdurma uygulanır. Belirsiz işlem sonucu hedef sistemden kontrol edilir. Hata sorumlusu, bildirim yolu ve manuel devam planı işletim kapsamına yazılır.
Garanti değildir. Yeni model bazı görevlerde daha iyi, bazılarında farklı davranabilir. Kalite, maliyet ve gecikme aynı görev setinde değerlendirilir. Kontrolsüz otomatik güncelleme yerine sürüm kararı ve gerektiğinde geri dönüş yolu kullanılır.
Müşteriye özel geliştirme, mevcut bileşenler, üçüncü taraf lisansları ve kullanım hakları teklifte ayrı tanımlanır. Devir kapsamı yalnız koddan oluşmaz; yapılandırma, testler, dokümantasyon, hesap ve erişim yönetimi de belirlenir.
Keşif ve süreç tasarımıyla başlanabilir. Pilot ve canlı işletim için teknik sorumluluk Webtures, müşteri veya belirlenen uygulama ortağı arasında açıkça atanır. Sorumlusu olmayan bir üretim sistemi devreye alınmaz.
Bu kavramlar farklı odakları anlatır. MLOps model yaşam döngüsüne, LLMOps dil modeli uygulamalarının geliştirme ve işletimine, AIOps bilgi teknolojileri operasyonlarında yapay zekâ kullanımına odaklanır. AI Workflow Engineering iş sürecinin tamamlanmasını tasarlar; ihtiyaç halinde bu yetkinliklerle birlikte çalışır.
Görünürlük aracı markanın hangi yanıt ve kaynaklarda bulunduğunu ölçmeye yardımcı olabilir. İş akışı ise bu bulgudan inceleme, görev, onay ve güncelleme süreci üretir. Kullanılabilecek veri ve entegrasyonlar proje bazında doğrulanır.