Her ekranı bir sahip, tasarruf edilen süre ve izlenebilir bir iş sonucu ile bağlayarak kurum içinde yapay zeka ile oluşturulmuş yazılımları nasıl iç satışa sunacağınızı öğrenin.
Birçok dahili demo aynı kibar tepkiyi alır: "İlginç." Bu olumlu gibi duyulsa da genellikle insanlar işlerini değiştirmek için bir neden görmemiştir.
Sorun nadiren yalnızca yazılım olur. Daha sık olarak demo, ekibin her hafta değerlendirildiği kritere bağlanmaz.
İnsanlar kurum içinde yapay zeka ile oluşturulmuş yazılımı sunarken genellikle hız, otomasyon veya uygulamanın ne kadar hızlı geliştirildiğiyle başlarlar. Bu dikkat çeker, ama liderlerin gerçekten önemsediği soruları yanıtlamaz: bunu kim kullanacak, hangi işi iyileştiriyor ve hangi sonuç değişecek?
Belirsiz iddialar alıcıları duraklatır. "Daha iyi verim" ve "daha az manuel iş" kulağa hoş gelir, ancak bütçe toplantısında savunması zordur. Finans lideri, operasyon müdürü veya bölüm başkanı somut bir şeye ihtiyaç duyar.
En ikna edici gerekçe genellikle basittir. Tek bir net süreç sahibi, o kişinin günlük işindeki net bir sorun ve takip edilmeye değer tek bir net sonuç vardır.
Bu yapı yoksa demo fikir amaçlı bir prototip gibi hissedilir, gerekli bir araç gibi değil. İnsanlar benimseme, belirsiz sahiplik ve işe yarar görünen ama gerçek iş akışının parçası olmayan başka bir uygulama endişesi duyar.
Küçük bir örnek farkı gösterir. Bir ekranı "destek için bir AI panosu" olarak sunduğunuzda bu geniş ve isteğe bağlı görünür. Eğer onu "destek liderinin her sabah acil istekleri 30 dakika yerine 10 dakikada ayırdığı ekran" olarak sunarsanız, değerin değerlendirilmesi çok daha kolay olur.
Bu kayma önemlidir. Ekran artık sadece bir özellik değildir. Bir kişinin işi, bir zaman kazancı ve daha hızlı yanıt süreleri veya daha az kaçırılan vaka gibi bir iş sonucu ile bağlantılıdır.
Her ekran gerçek işle bağlandığında konuşma değişir. "Buna neden ihtiyacımız var?" yerine ekipler "Bunu ilk olarak nasıl test ederdik?" diye sormaya başlar. İşte o zaman dahili yazılım için iş gerekçesi gerçek hissetmeye başlar.
Büyük bir vizyonla başlamayın. Herkesin zaten tanıdığı bir süreçle başlayın. Bir aracın kendi günlerine nereye uyduğunu kolayca hayal edebildiklerinde insanlara güven daha hızlı kurulur.
En iyi başlangıç genellikle hafifçe rahatsız eden tekrar eden bir görevdir. Tam bir departman dönüşümü değil. Çok takımlı bir dönüşüm değil. İnsanların önem vermesi için yeterince sık gerçekleşen tek bir iştir.
Onay talepleri, lead devri, fatura kontrolleri, destek bileti triajı ve haftalık durum güncellemeleri iyi örneklerdir. Bu adımları, gecikmeleri ve küçük rahatsızlıkları ekip zaten bilir, bu yüzden açıklaması kolaydır.
En çok önemli olan tanıdıklık hissidir. Sunumunuzu duyduklarında insanların "Evet, şu anda tam olarak böyle yapıyoruz" demesi gerekir. Bu direnç seviyesini hemen düşürür.
Toplantılarda ve sohbetlerde zaten gündeme gelen acı noktalarını dinleyin. Yöneticiler sık sık "aynı veriyi iki kez giriyoruz" veya "bu her zaman onay beklerken takılıyor" gibi şeyler söylüyorsa, halihazırda davanıza ham madde var demektir.
İyi bir ilk süreç genellikle birkaç özellikle tanımlanır. Her hafta veya her gün olur, net bir başlangıcı ve bitişi vardır, küçük bir grubu içerir ve iki dakika içinde açıklanabilir. Beş takımın aynı anda anlaşmasına bağlıysa, muhtemelen ilk sunum için çok geniştir.
Küçük kapsam bir güçtür. Dar bir örnek, iç paydaşlar için test edilebilir olduğu için daha güvenlidir. Ayrıca yazılımı demo etmeyi de kolaylaştırır.
Bu yüzden "operasyonlar için bir AI uygulaması" demek yerine, "gelen talepleri toplayan, eksik bilgileri kontrol eden ve doğru kişiye yönlendiren bir araç" diye sunun. Bu somuttur. İnsanlar buna tepki verebilir.
Bu noktada hızlı prototipleme yardımcı olur. Koder.ai gibi bir platform, tanıdık bir iş akışını sohbetten basit bir web veya mobil uygulamaya dönüştürebilir; bu, ekiplerin soyut bir fikre değil gerçek bir şeye tepki vermesini sağlar.
Bir ekran, bir kişi açıkça sahiplendiğinde savunması çok daha kolaydır. Sunumunuzda o ekranı en çok kullanan rolü, orada neyi tamamlamaya ihtiyaç duyduklarını ve bunun iş günlerinde neden önemli olduğunu adlandırın.
Bu konuşmayı basit tutar. "Bu gösterge panosu satış, finans ve desteğe yardımcı olur" demek yerine, "Bu ekran satış operasyonları yöneticisinin teklif taleplerini tek bir yerde onaylamasına yardımcı olur" deyin. İnsanlar sahipliği uzun bir özellik listesini anlamaktan çok daha hızlı kavrar.
Yararlı bir ekran üç temel soruyu yanıtlar:
Bunları bir cümlede cevaplayamıyorsanız ekran muhtemelen çok fazla şey yapıyordur.
Çok sayıda role bağlı ekranlar genellikle davayı zayıflatır. Taraflar arası tartışmaları davet eder çünkü her paydaş farklı bir ihtiyacı görür. Birisi daha fazla alan ister, diğeri daha az adım, başkası ekranın araçta olup olmamasını sorgular.
Daha temiz bir yaklaşım, karışık amaçlı ekranları daha küçük, role dayalı görünümlere bölmektir. Bir talep alma ekranı yeni talepleri gözden geçiren bir takım liderine ait olabilir. Ayrı bir durum ekranı ilerlemeyi takip eden bir operasyon koordinatörüne ait olabilir. Her ekranın bir ana kullanıcısı ve net bir bitiş çizgisi olur.
Bu yapı, sunumu daha güvenilir kılar. Paydaşların tüm şirkette geniş değer hayal etmeleri gerekmez. Bir ekranın tek bir sahibi olduğunu, tek bir önemli görevi desteklediğini görebilirler.
Bir prototip sunuyorsanız formatı sade tutun:
Prototipi Koder.ai'de oluşturduysanız, onu aynı formatla ekran ekran gezinerek gösterin. Bütün uygulamayı tek bir büyük sistem olarak sunmayın. Odaklanmış bir ekran geniş bir sözden daha inandırıcıdır.
Her ekranın basit bir soruya cevap vermesi gerekir: burada ne hızlanıyor?
Bir sayfa her şeyi yapıyormuş gibi görünürse insanlar hiçbirini hatırlamaz. O ekrandaki ana görevi seçin ve zaman kazancını sade bir dille tanımlayın. "Akıllı otomasyon" veya "daha iyi iş akışı" gibi etiketleri atlayın. Kişinin gerçekten neyi daha hızlı yaptığına söyleyin.
"Bu gösterge panosu ekip verimliliğini artırır" demeyin. "Bu ekran ops yöneticisinin üç tablo yerine 15 dakika yerine 2 dakikada geç kalan siparişleri bulmasını sağlar" deyin.
Böyle bir ifade daha güvenilirdir. Net bir iddia inandırıcı hissedilir; büyük bir vaat ise değil.
Ekranda görünen eylemle başlayın. Bu sayfanın yardımcı olduğu tek iş nedir? İzin talebi göndermek, faturayı onaylamak, müşteri kaydını güncellemek veya haftalık özet oluşturmak olabilir.
Sonra faydayı o tam göreve harcanan zamanda tasarruf olarak açıklayın. Ekran alanları otomatik dolduruyorsa fayda daha hızlı veri girişi; eksik öğeleri gruplayorsa hata aramak için daha az zaman; ilk taslağı oluşturuyorsa sıfırdan yazmaya göre daha az dakika.
Dakika tasarrufları belirsiz söylemlerden daha güvenilirdir. Çoğu ekip "daha hızlı" veya "daha verimli" gibi kelimelere itiraz eder çünkü bu kelimeler tek başına hiçbir şey ifade etmez. Ama "Rapor hazırlamayı 25 dakikadan 8 dakikaya indirir" gibi cümlelere tepki verebilirler çünkü işi canlandırabilirler.
Basit bir örnek yardımcı olur. Bir finans ekranının makbuzları okuyup gider detaylarını otomatik doldurduğunu hayal edin. Faydası "daha iyi gider yönetimi" değil; "Çalışan, form önceden doldurulduğu için masraf talebini 12 dakikadan 4 dakikaya gönderebilir" olur.
Koder.ai ile oluşturulmuş bir uygulamayı demo ediyorsanız, her sayfada aynı deseni kullanın: bir rol, bir görev, bir zaman tasarrufu. Sonra durun. O noktanın yerleşmesine izin verin.
Zaman tasarrufu faydalıdır, ama liderler onay verdikleri işin ölçülebilir bir sonuca dönüşmesini ister. Bir ekranın her istekte 10 dakika tasarruf sağlaması hoş gelir. Bir ekranın onay süresini dört günden iki güne düşürmesi ise dikkat çeker.
Bunu gerçek kılmanın en kolay yolu her ekranı lansmandan sonra izlenebilecek tek bir sayıya bağlamaktır. Basit tutun. Bir ekran geribildirimleri ortadan kaldırıyorsa sonuç daha az gecikme olabilir. İncelemeleri hızlandırıyorsa sonuç daha hızlı onay olabilir. Manuel girişi azaltıyorsa sonuç yeniden iş gerekmesinin azalması olabilir.
İyi bir sonuç üç parçaya sahiptir: bir başlangıç değeri (baseline), bir hedef ve daha sonra nasıl kontrol edileceği. Yöneticiler şu anda tedarikçi taleplerini 48 saatte onaylıyorsa hedefiniz 24 saat olabilir. Lansmandan sonra yeni ortalamayı eskisiyle karşılaştırırsınız.
Liderlerin genellikle önem verdiği sonuçlar: daha hızlı onay süreleri, daha az kaçırılan devralmalar, eksik gönderimlerden kaynaklanan yeniden işlemenin azalması, talepler için daha kısa geri dönüş süresi veya ek personel eklemeden haftalık işlenen talep sayısının artması gibi metriklerdir.
Bunların ne olmadığını fark edin. Bunlar "daha iyi verim" gibi belirsiz ifadeler değildir. Bir elektronik tablo, gösterge paneli veya haftalık rapor ile takip edilebilecek sayılardır.
Gerçekçi bir örnek konuyu netleştirir. Koder.ai gibi bir platformla yapılmış dahili bir satın alma uygulamasını düşünün. Bir talep ekranı her müdür başına 8 dakika kazandırıyorsa orada durmayın. Bunun neyi değiştirdiğini gösterin: onaylar bir iş günü hızlanır, acil satın almalar daha az bekler ve operasyon ekibi haftada daha fazla talep kapatır.
Vaadlerde dikkatli olun. "Bu departmanı dönüştürecek" işe yaramaz. "Mevcut talep hacmi ve kaldırılan adımlara dayanarak ortalama onay süresini %30 azaltmalıdır" çok daha güçlüdür.
Eğer ekip lansmandan sonra sonucu ölçemiyorsa, sonuç hâlâ çok belirsizdir.
İçinde dava yaparken işe odaktan başlayın. İnsanların zaten izlediği sırayla iş akışını haritalayın, ilk ekrandan son ekrana kadar.
Bu konuşmayı tanıdık tutar. Yeni bir araca, mevcut süreçlerini içinde gördüklerinde çok daha açık olurlar.
Basit bir dört adımlı yapı iyi çalışır:
Her ekranı tek bir kişiye bağlayın. Bir ekran üç takıma ait gibi görünürse sunum çabucak bulanıklaşır.
Örneğin, Ekran 1 satış koordinatörü tarafından yeni bir talep girmek için kullanılabilir. Fayda veri girişini 10 dakikadan 3 dakikaya indirmek olabilir. Sonuç yalnızca "daha hızlı iş" değil; haftada 20 daha fazla talebin işlenmesi, daha az gecikme veya daha az fazla mesai olabilir.
Her ekran için aynı deseni tekrarlayın. Bir sahip, bir fayda, bir sonuç. Bu belirsiz bir demoyu insanların takip edebileceği bir iş gerekçesine dönüştürür.
Demoda bir iş akışını gösterin, tüm ürünü değil. Araç Koder.ai üzerinde inşa edilmişse, oluşturma hızı arka plan bilgisi olabilir ama odak noktası odadaki ana mesaj olmamalıdır. Ana mesaj, bu belirli iş akışının daha kolay, daha hızlı ve ölçülmesi daha kolay hale geldiğidir.
Kısa demolar genelde geniş olanlardan daha iyi çalışır. Başlangıç noktasını, her ekrandaki eylemi, tasarruf edilen zamanı ve sonunda sonucu gösterin.
Küçük bir istekle bitirin. İlk gün tam bir dağıtım istemeyin. Bir ekip, bir sahip grubu ve bir başarı metriği ile sınırlı bir pilot isteyin. Bu daha güvenli görünür, size gerçek sayılar verir ve sonraki onayı çok daha kolay yapar.
İK ve işe alım yöneticileri tarafından kullanılan bir çalışan işe alım uygulamasını hayal edin. Amaç "AI"yi satmak değil. Amaç yeni işe alınanların ilk haftasında gecikmeye neden olan dağınık süreci düzeltmektir.
İlk ekran İK'ya aittir. Her yeni çalışanı gösterir, vergi formları, bordro verileri, dizüstü bilgisayar seçimi ve imzalanmış belgeler gibi eksik detayları vurgular ve takipleri tek yerde tutar. Süreç sahibi İK operasyonlarıdır. Zaman tasarrufu açık: İK, insanları e-posta ve tablolar arasında kovalayarak daha az zaman harcar.
Şimdi bir sayı ekleyin. Eğer İK şu anda kişi başı ortalama 20 dakika harcıyorsa ve bu ekran bunu 8 dakikaya indiriyorsa, kişi başı 12 dakika tasarruf olur. Aylık 40 işe alımda bu sekiz saat eder, artı bordro veya erişim kurulumunun gecikmesi daha az olur.
İkinci ekran işe alım yöneticisine aittir. Birinci gün öncesi onaylamaları gerektiren görevleri (rol erişimi, ekipman, eğitim, tanıtımlar) gösterir. Uzun e-posta zincirleri yerine yönetici tek bir ekranda onaylar, reddeder veya soru sorar.
Zaman tasarrufu daha az gidip gelme ve daha hızlı onaydır. Eğer onaylar genelde üç gün sürüyorsa ve bu ekran bunu bir güne düşürürse, yeni işe alınanlar ihtiyaç duydukları şeylerle başlama olasılığı çok daha yüksek olur.
Ölçülebilir sonuç sunumun iş yapmasını sağlar. İlk ay için iki sayıyı takip edin: kaç çalışan ilk gün tam hazır ve kaç onboarding görevi geç tamamlandı. Eğer ilk gün hazır olma oranı %70'ten %90'a yükselir ve geç görevler ayda 24'ten 10'a düşerse, gerekçe anlatması kolay bir hale gelir.
Kopyalanacak desen budur: bir ekran, bir sahip, bir zaman tasarrufu faydası ve bir iş sonucu.
Zayıf sunumlar genellikle bir sebepten başarısız olur: insanlar uygulamanın gerçek işe nasıl uyduğunu göremez.
Yaygın hata, hikâyesi olmayan çok fazla ekran göstermek. Hızlıca 10 sayfayı geçirmek etkileyici görünebilir ama insanlar "Bunu ilk kim kullanıyor ve neden?" diye sorar. Her ekranın bir işi olduğu bir görevi baştan sona yürütmek çok daha iyidir.
Diğer bir hata, kaynağı gösterilmeyen tek bir büyük ROI sayısı kullanmaktır. "Yılda 2.000 saat kazandıracak" demek şüphe yaratır. İnsanlar sayının nereden geldiğini bilmek ister. Basit bir hesaplamayı göstermek — görev sıklığı, şu anki süre ve yeni akışın kaldırdığı zaman — bile daha güçlüdür.
Farklı bölümler tek bir sunuma karıştırıldığında dava da zayıflar. Finans, operasyon ve satış aynı yürüyüşte görünürse her kişi sadece kendisine ait kısmı duyar ve sonuçta gürültü olur. Örnek o kadar dar olmalı ki bir süreç sahibi "Evet, bu benim takımımın problemini çözüyor" diyebilsin.
Bir diğer sık hata, teknoloji hakkında konuşmayı işle ilgili problemden önce yapmaktır. Çoğu paydaş bir aracın AI kullandığı için satın almaz. Daha az manuel adım, daha hızlı onay, daha az hata veya daha kısa yanıt süreleri ile ilgilenirler. İlk beş dakika modeller, ajanlar veya uygulamanın nasıl üretildiğiyle geçerse iş gerekçesini kaybedebilirsiniz.
Toplantıdan önce hızlı bir öz-değerlendirme yardımcı olur:
Bunlardan herhangi birine hayırsa, hikâyeyi sıkılaştırın.
Toplantıdan önce demo ve notlarınızda hızlıca göz gezdirin. Herhangi bir ekran açıklaması zorsa, odadaki insanlar da bunu hisseder.
İyi bir dahili yazılım iş gerekçesi uzun bir kurulum gerektirmeden takip edilebilir olmalıdır. Bir yönetici kim kullanıyor, neyi tasarruf ediyor ve bunun neden önemli olduğunu yaklaşık beş dakikada görebilmelidir.
Her ekranın bir sahibi olduğundan emin olun. İki takım "biraz" sahipleniyorsa değer hızla bulanıklaşır. Ayrıca her ekranın basit bir zaman tasarrufu cümlesi olsun, örneğin "Bu haftalık durum güncellemelerini 30 dakikadan 5 dakikaya indirir."
Sonra her ekranı bir iş metriğine bağlayın. Ekiplerin zaten önem verdiği sayıları kullanın: yanıt süresi, hata oranı, iş başına maliyet, anlaşma döngü süresi veya ayda harcanan saat gibi. Tanıdık ölçüler benimsemeyi kolaylaştırır.
Açıklamanızı sade dilde tutun. Birisi sormazsa araç detaylarına girme. Bir ekran için sahibi adlandıramıyorsanız, o ekranı toplantıdan çıkarın. Fazladan ekranlar genellikle davayı zayıflatır çünkü yeni sorular doğurur.
Yararlı bir test notlarınızı projeye dahil olmayan birine göstermek olabilir. Eğer beş dakika içinde değeri tekrar edebiliyorsa sunum muhtemelen yeterince nettir. Değilse, her ekranın dört temel soruyu yanıtlayana kadar hikâyeyi sıkılaştırın: kim sahip, neyi tasarruf ediyor, hangi sayı hareket ediyor ve bu şimdi neden önemli.
İnsanların "bir gün" değil "gelecek hafta" çalışır halde hayal edebileceği kadar küçük başlayın. Gecikme, tekrarlayan iş veya devralma problemleri yaratan bir iş akışı seçin. İyi bir pilot dar, tanıdık ve mevcut yöntemle kolayca karşılaştırılabilir olmalıdır.
Süreç beş ekrandan oluşuyorsa, hepsini birden savunmaya çalışmayın. Her ekran için üç şeyi yazın: o adımı kim sahipleniyor, ne kadar zaman tasarrufu sağlıyor ve hangi iş sonucu iyileşmeli. Bu dava daha kolay takip edilir ve savunulur.
Basit bir pilot planı yeterlidir:
O ilk inceleme önemlidir. Bir yönetici size hikâyenin nerede belirsiz olduğunu, metriğin nerede zayıf olduğunu veya hangi ekranın yanlış problemi çözdüğünü söyleyebilir. Bu geri bildirimi geniş bir toplantıda almak yerine sessiz bir incelemede duymak çok daha iyidir.
Herkesin güvendiği basit metrikleri kullanın. Haftalık tasarruf edilen saatler, azalan manuel giriş sayısı, daha hızlı onay süresi veya daha az destek bileti gibi ölçüler geniş iddialardan daha inandırıcıdır.
Diyelim pilot satın alma onaylarını kapsıyor. Bir ekran departman yöneticisine ait, talep detaylarını otomatik doldurarak zaman kazandırıyor ve onay süresini iki günden aynı güne indirmeyi hedefliyor. Bu tartışmak için somut bir durumdur.
Uygulamayı hızlıca kurup test etmeniz gerekiyorsa, Koder.ai ekiplerin basit bir süreç fikrini sohbet yoluyla çalışan bir web, sunucu veya mobil uygulamaya dönüştürmesine yardımcı olabilir. Bu, paydaşların slaytlar yerine gerçek bir akışa tepki vermesini sağlar.
İlk pilotı odaklı, ölçülebilir ve anlatması kolay tutun. Bir faydalı iş akışını anladıktan sonra insanlar ikinci bir akışa çok daha açık olur.
Gecikmelere veya tekrar eden işe neden olan tanıdık bir iş akışıyla başlayın. Dar ve iyi bilinen bir süreç açıklaması yapmak, anlatımı kolaylaştırır, demo etmeyi basitleştirir ve paydaşların ilk olarak test etmesi için daha güvenli olur.
Sahiplik değeri netleştirir. Bir ekranın tek bir ana kullanıcısı olduğunda, insanlar kimlerin kullandığını, hangi işi bitirmeye yardımcı olduğunu ve o adımın neden önemli olduğunu çabucak anlayabilir.
Gözle görülen bir işe bağlayın. Şöyle söyleyin: "Bu, fatura incelemeyi 15 dakikadan 5 dakikaya indirir." Genel verimlilik iddiaları yerine açık, ölçülebilir bir zaman tasarrufunu ifade edin.
Lansmandan sonra değişmesi beklenen tek bir iş metriği seçin. İyi örnekler: onay süresi, hata oranı, geç kalan işler, yanıt süresi veya hafta başına işlenen istek sayısıdır.
Kısa ve tek bir iş akışına odaklanmış tutun. Her ekranı kim kullanıyor, orada ne hızlanıyor ve sonunda hangi sonucun iyileşmesi bekleniyor gösterin.
Hayır — başlangıçta tam dağıtım istemeyin. Bir ekip, bir iş akışı ve bir başarı metriğiyle dar bir pilot isteyin. Bu daha düşük riskli görünür ve genişlemeye geçmeden önce gerçek kanıt sağlar.
Önce iş problemini konuşun. Çoğu paydaş araçta kullanılan teknolojiye değil, daha az manuel adım, daha hızlı onay veya daha az hataya önem verir. Toplantının ilk beş dakikası modeller veya nasıl oluşturulduğu ile geçmemeli.
Mevcut hacim, şu an harcanan süre ve yeni akışın kaldırdığı süreye dayanan basit bir tahmin kullanın. Kabaca yapılmış bir hesap bile kaynağı olmayan büyük bir yıllık sayıdan daha inandırıcıdır.
Ekranı daha küçük, role dayalı görünümlere ayırın. Bu, iş akışını savunmayı kolaylaştırır ve çakışan ihtiyaçlar hakkında tartışmaları önler.
Koder.ai, tanıdık bir süreci sohbet yoluyla çalışan bir web, sunucu veya mobil uygulamaya dönüştürmenize yardımcı olur. Bu, paydaşların soyut bir fikir yerine gerçek bir akışa tepki vermesini sağlar.
