Tek platform mu, beş ayrı proje mi?

Kurumlarda yeni bir ihtiyaç ortaya çıktığında ilk refleks çoğunlukla bir yazılım projesidir. Eğitim için bir platform, saha ekipleri için bir mobil uygulama, proje takibi için başka bir araç, ERP verisine erişim için ayrı bir entegrasyon. Her biri kendi içinde makul bir karardır. Beşinci projeye gelindiğinde ise kurumun elinde beş ayrı ada vardır.

Ayrı projelerin görünmeyen maliyeti

Ayrı projelerin maliyeti yalnızca geliştirme ve lisans bedeli değildir. Asıl maliyet, her projede yeniden yapılan işlerde birikir:

• Kimlik ve yetki her sistemde yeniden tanımlanır; kimin neye erişeceği beş ayrı yerde yönetilir.

• Kişiler, kurumlar ve projeler her sistemde yeniden oluşturulur; aynı müşteri beş farklı kayıtla yaşar.

• Sistemleri birbirine bağlayan entegrasyonlar zamanla kendi başına bir bakım yükü olur.

• Kullanıcı işini bitirmek için ekranlar arasında dolaşır; bağlam her geçişte biraz daha kaybolur.

Bu tabloya yapay zekâ eklendiğinde sorun büyür. Her adaya ayrı bir asistan eklenebilir, ama her biri yalnızca kendi adasını görür. Teklifin durumunu bilen, eğitimin kimlere verildiğini bilmez; sahadaki olayı gören, ilgili projenin sorumlusunu tanımaz.

Ortak bir çekirdek neyi değiştirir

Hexense’te uygulamalar federe yetenekler olarak çalışır. Bir uygulama eklemek, ekrana bir modül daha koymak değil, ortak zekâya yeni bir yetenek kazandırmaktır. Varlıklar, ilişkiler, aksiyonlar, görevler, yetkiler, hafıza ve agent’lar uygulamalar arasında ortaktır.

Örneğin CaniasX, ERP bağlamını ve yeteneklerini Hexense’e taşır. HexRTLS konum ve olay bilgisini getirir. LXStudio etkileşimli öğrenme deneyimlerini destekler. Üçü de aynı kişileri, aynı projeleri ve aynı yetki modelini kullanır; ERP’deki bir sipariş, sahadaki bir olay ve verilen bir eğitim aynı bağlamda birbirine bağlanabilir.

Agent karar verir, uygulama işlemi güvenle yapar

Ortak çekirdek, yapay zekânın kurumsal işlemleri serbestçe yürütmesi anlamına gelmez. Agent neyin yapılması gerektiğine karar verir; işlemin güvenilir biçimde nasıl yapılacağını uygulama belirler. Doğrulama, yetki kontrolü, iş kuralları, veri bütünlüğü ve denetim izi uygulamaların kendi servislerinde durur.

Doğrudan veritabanı değil, kontrollü servisler

Federasyon, sistemlerin birbirinin veritabanına doğrudan erişmesi değildir. Her uygulama yeteneklerini kontrollü API’ler ve servisler üzerinden açar. Böylece yeni bir yetenek eklemek, mevcut sistemlerin güvenlik ve tutarlılık sınırlarını delmez.

Kayıt sistemleri yerinde kalır

Ortak platform, ERP’nin ya da CRM’in yerine geçmek zorunda değildir. Kayıt sistemleri kaydın sahibi olmaya devam eder. Hexense bunların üzerinde ortak bir zekâ ve etkileşim yüzeyi olur: kullanıcı ayrı ekranlara gitmek yerine, ilgili yetenek işin bağlamında karşısına gelir. Yeni bir uygulama değil; uygulamalarınızın ortak zekâ yüzeyi.

Ayrı proje ne zaman hâlâ doğru seçimdir?

Her ihtiyaç ortak platforma taşınmak zorunda değildir. Bir ihtiyaç kurumun geri kalanıyla bağlam paylaşmıyorsa, kısa ömürlüyse ya da tamamen kendi kuralları olan bir alanda çalışıyorsa, ayrı bir araç daha basit olabilir. Karar verirken üç soru işe yarar:

• Bu ihtiyaç, diğer sistemlerdeki kişilere, kurumlara ve projelere dokunuyor mu?

• Aynı yetki modeline ve aynı denetim izine ihtiyaç duyuyor mu?

• Agent’ların bu alanda bilgi toplaması ya da iş yapması bekleniyor mu?

Cevapların çoğu evetse, yeni bir proje başlatmak yerine platforma bir yetenek eklemek çoğu zaman hem daha hızlı hem de uzun vadede daha az yük getiren yoldur. Çünkü her yeni yetenek, bir öncekinin oluşturduğu bağlamın üzerine kurulur.