RPA Bütçesinin Neresi Lisans? UiPath Projelerinde Maliyetin Gerçek Dağılımı

Otomasyon gündeme geldiğinde ilk toplantıda sorulan soru genellikle aynıdır: Lisans ne kadar? Soru anlaşılırdır, çünkü bütçe talebine yazılacak ilk rakam odur. Ancak bir yıl sonra programın devam edip etmeyeceğini belirleyen kalem çoğu zaman lisans olmaz.

Bu yazıda UiPath tarafında maliyetin nasıl dağıldığını, hangi kalemlerin ilk teklifte görünmediğini ve lisans ihtiyacının nasıl daha sağlıklı tahmin edileceğini ele alıyoruz.

Lisans tam olarak neyin bedeli?

RPA lisansı kabaca iki şeyi kapsar: robotların çalışma hakkı ve bu robotları yöneten katman. Robot tarafında temel ayrım, bir kullanıcının başlattığı otomasyonlar ile sunucuda kendi başına çalışanlar arasındadır. Yönetim tarafında ise robotların nerede, ne zaman ve hangi sırayla çalışacağını belirleyen, hata durumunda uyaran ve kayıt tutan orkestrasyon katmanı bulunur.

Bu ayrım maliyet açısından önemlidir. Çoğu kurumun ilk aklına gelen senaryo kullanıcıya bağlı olan taraftadır: bir çalışan tuşa basar, robot onun yerine formu doldurur. Oysa ölçek ekonomisi diğer tarafta oluşur. Gece çalışan, kimseyi beklemeyen bir robot günde saatlerce iş yapar; masaüstünde bir kullanıcıyı bekleyen robot ise o kullanıcının mesaisi kadar çalışır.

İlk teklifte görünmeyen kalemler

Lisans bedeli sözleşmede yazar. Bütçeyi asıl zorlayan kalemler ise genellikle şunlardır.

Geliştirme. Bir sürecin otomasyona alınması; o sürecin yazıya dökülmesi, istisnalarının belirlenmesi, test edilmesi ve devreye alınması demektir. Süreç ne kadar çok istisna barındırıyorsa geliştirme o kadar uzar. "Basit" diye tarif edilen süreçlerin çoğu, konuşulmaya başlandığında on beş farklı özel durum çıkarır.

Ortam ve altyapı. Robotların çalışacağı makineler, bu makinelerin eriştiği uygulamaların lisansları, ağ ve yetki tanımları. Robot bir kullanıcı gibi davranır; dolayısıyla ihtiyaç duyduğu her sistemde bir kullanıcısı olması gerekir.

Bakım. En çok hafife alınan kalem budur; aşağıda ayrıca ele alıyoruz.

Değişiklik yönetimi. Süreci bugüne kadar elle yürüten ekibin yeni akışa geçmesi, istisna durumlarında ne yapacağını bilmesi ve robotun çıktısına güvenmesi gerekir. Bu güven kendiliğinden oluşmaz.

Süreç sahipliği. Robot bir sürecin sahibi değildir. Mevzuat değiştiğinde, ekran güncellendiğinde veya iş kuralı revize edildiğinde birinin bunu fark edip iletmesi gerekir.

Bakım neden ayrı bir bütçe kalemidir?

Bir robot, insanın kullandığı arayüzü kullanıyorsa, o arayüz değiştiğinde çalışmayı bırakır. Uygulamadaki bir alanın yeri değişir, portal yeni bir onay ekranı ekler, tarayıcı sürüm atlar; robot durur.

Bu, RPA'in kusuru değil doğasıdır. Ancak bütçe yaparken hesaba katılması gerekir. Pratikte maliyeti düşüren yaklaşım şudur: mümkün olan her yerde ekran yerine servis kullanmak. Hedef sistemin bir servisi varsa, robotu ekrana bakmaya zorlamak yerine o servisi çağırmak hem daha hızlı hem de çok daha dayanıklı olur. Ekran otomasyonu, başka yolu olmadığında başvurulacak yöntemdir; varsayılan yöntem değil.

Kaç lisans gerekir?

Bu sorunun cevabı tahminden değil süreçten çıkar. İhtiyaç duyulan robot kapasitesi kabaca üç bilgiye bağlıdır: sürecin bir işleminin ne kadar sürdüğü, günlük işlem adedi ve bu işlemlerin tamamlanması gereken zaman aralığı.

Gün içinde eşit dağılan bir iş yükü ile ay sonunda üç güne sıkışan bir iş yükü, aynı hacme sahip olsalar bile aynı kapasiteyi gerektirmez. Mutabakat, bordro ve dönem sonu raporlama gibi süreçler yılın belirli günlerinde yığılır. Kapasiteyi ortalamaya göre planlayan kurumlar, tam da en kritik günde robotların yetişmediğini görür.

İki yönlü hata da maliyetlidir. Fazla lisans, kullanılmayan kapasitenin parasını ödemek demektir. Az lisans ise sırada bekleyen işler, gecikmeler ve otomasyona duyulan güvenin sarsılması demektir. İkincisi genellikle daha pahalıya mal olur, çünkü programın kendisini tartışmaya açar.

Doğru sıra: önce süreç, sonra lisans

Lisans miktarını sağlıklı belirlemenin yolu, otomasyona alınacak süreçleri ve hacimlerini önce görmekten geçer. Kurumların bir kısmı bu bilgiyi atölye çalışmalarıyla çıkarabilir. Süreçlerin sistem kayıtlarında iz bıraktığı durumlarda ise süreç madenciliği daha kesin bir tablo verir: sürecin gerçekte hangi adımlardan geçtiğini, nerede beklediğini ve hangi varyasyonun ne sıklıkta yaşandığını varsayıma dayanmadan gösterir.

Bu sıralamanın pratik faydası şudur: elinizde hacim ve süre verisi olduğunda lisans görüşmesi bir pazarlık olmaktan çıkıp bir hesap hâline gelir.

Nereden başlamalı

Bütçeyi lisans kaleminden başlatmak yerine şu üç soruyla başlamak daha sağlıklı sonuç verir:

• Hangi süreçler, hangi hacimle ve hangi zaman kısıtıyla çalışıyor?
• Bu süreçlerde ekran yerine servis kullanılabilecek noktalar var mı?
• Devreye alındıktan sonra otomasyonun sahibi kim olacak?

Üçüncü sorunun cevabı yoksa, lisans sayısını doğru bulmuş olmanız tek başına bir şey değiştirmez.

Native Dijital olarak UiPath tarafında lisans hizmetleri ve RPA danışmanlığı sunuyoruz. Bir sürecin otomasyona uygun olup olmadığını konuşmak isterseniz bize yazın.