Son Nefesinde Bile Fedakar Otomasyon Robotları

Bir Robot Düşerse…

Bir Web, Masaüstü veya Mobil uygulama geliştirdiğinizde onu kullanmak ve kullanılırken izlemek size her zaman haz verir ve gururlandırır. Fakat günümüzde bu tür uygulamalar son kullanıcı tarafından hayatımızın olağan parçaları olarak algılanıyor. Yani kapının koluna basıldığında açılması kadar normal. Hiçbirimiz “Aaa Instagram ne güzel açıldı, baksana ne güzel kullanıyorum” demiyor, öyle değil mi?

Bu durum RPA robotları için henüz böyle değil. Sorunsuz ve hızlı çalışan bir robotu izlemek hala herkes için eğlenceli ve tatmin edici bir görüntü, neticede bizim yerimize çalışıyorlar. Tabii “Exception” almadıkları sürece…

Nedir bu Exception?

RPA dünyasında bazı terimleri çok sık duyacaksınız, bunların başında Exception’lar geliyor. Öncelikle bilmeyenler için terminolojiyi netleştirelim. Happy Path, sürecin hiçbir problem olmadan ve en kısa kırılımdan başarılı bir şekilde tamamlandığı mucizevi akışa deniyor. Adeta düz bir çubuk gibi! Ancak neredeyse hiçbir işletme süreci böyle değil, daha çok bir ağaç gibi dallanıyorlar.

Happy Path

Exception / Unhappy Path

System Exception’lar süreç içinde öngörülememiş dolayısıyla “Handle” edilmemiş hatalardır. Bir posta kutusunu dinleyip içindeki PDF faturaları SAP sistemine işleyen bir süreç düşünelim. Bu süreç içinde ağ bağlantısı nedeniyle SAP Logon’un açılmaması veya girdi olan PDF dosyasının bozuk olması gerçekten birer System Exception’dır. Fakat bir de süreç içinde öngörülebilen ve sistemsel olmayan hatalar veya kurallar vardır. Yine aynı senaryoyu düşünelim, örneğin kullanıcı şunu diyebilir “10.000TL üstü faturaları farklı bir şekilde kaydediyoruz” yahut “Fatura tarihi 30 gün geçmiş faturaları işlemiyoruz” Bunlar birer Business Exception olarak tanımlandığında robot kullanıcıya güzelce “İletilen fatura 10.000TL üstüdür, lütfen Ahmet bey ile iletişime geçiniz” diyebilir.

Öngörü!

System Exception ve Business Exception tanım olarak çok net ayrışmış olmasına rağmen, bazı durumlarda neyin Business neyin System Exception olacağına kullanıcı ve süreç mühendisi karar verir, nasıl mı? Bir süreçte yazılım mühendisine anlatılmayan ve dolayısıyla “Handle” etmediği her Business Exception, bir System Exception adayıdır.

Aynı senaryo üzerinden netleştirelim. SAP ekranında fatura tarihi alanı zorunlu alan olsun ve bu alan boş olduğunda SAP ekran geçişine izin vermesin. (Ki kullananlar iyi bilir altta kırmızı uyarısını çıkarır orada çakılır kalır adeta, başka alana bile dokundurmaz.) Eğer siz bu durumu yazılım mühendisine aktarırsanız, girdide bu alan boş geldiğinde sürece başlamadan uyarı yollar ve bitirirsiniz. Aksi halde robot mevcut veriler ile çalışmayı dener girişi yaptıktan sonra sıradaki ekranı arar ve devam etmeyi bekler. Ancak beklenen ekran gelmeyecek ve süreciniz program beklendiği gibi çalışmadığı için System Exception ile patlayacaktır. Kullanıcıya “İlettiğiniz fatura eksik veri içeriyor.” demek varken, neden “Aranan UI elementi bulunamadı. Süreç sonlandırıyor.” diye garip bir sistem hata mesajı iletelim ki?

Konuşmasını, oturmasını kalkmasını bilen robot!

Bu istisnaların detaylı ve doğru tanımlanması, aslında RPA sürecinin kalitesini, anlaşılırlığını ve verimliliğini artırır. Bu durum kullanıcı memnuniyeti sağlar. Zira her “Business Excepiton” kullanıcı için anlamlı bir dönüştür ve kullanıcının robotla sağlık bir şekilde konuşabilmesini mümkün kılar.

Son nefesinde bile fedakâr robot!

Doğru geliştirilen bir sürecin her koşulda “Job Fail” gerçekleşmemesi beklenir. ReFramework gibi sağlam yapılar kullanıldığında çok farklı System Exception’lar art arda oluşa ve robot katma değer üretemese bile, bu durumu kurtaracak en azından açtığı uygulamaları kapatacak ve ortamı bulduğu gibi bırakacaktır. En önemlisi ise son nefesinde bile kullanıcısına dönüş sağlayacaktır, “Yapamadım çünkü bunlar bunlar oldu…”

Robot başka neden düşer?

Robot bu şekilde süreç/platform kaynaklı düşebilir, peki ya başka? Robotlar makine, network ve DB kaynaklı da düşebilir. Özellikle ortak alanda tutulan config dosyaları, ortak alandan veya mail yoluyla okunan girdiler network sorunlarına gebedir. Robot makinası ve Orchestrator makinası kaynaklı düşmeleri ise yalnızca bir süreci değil ortamdaki tüm süreçleri etkileyeceğinden oldukça can acıtıcı olacaktır. Bu durumları hızlıca tespit ve müdahale etmenin en kolay yolu ise Monitoring yapmak olacaktır.

RPA Monitoring mi?

IT uzmanlarının artık ezbere bildiği Monitoring araçları ve yöntemleri konusuna değil, UiPath’in onlara ekstra neler sağladığına değineceğiz. UiPath Orchestrator, Monitoring’e iki şekilde imkân tanıyor. İlki Rest API Endpoint’leri, diğeri ise Webhooklar. Orchestrator’ın web arayüzünde erişilebilen her bilgiye ve yapılabilen her işleme API’lar aracılığıyla da erişilebilir. Bu bilgilere robotların durumları da dahil!

Bir robot varsayılan olarak 30 saniyede bir Orchestrator’a “Ben buradayım!” der ve yine varsayılan olarak 90 saniye boyunca bu bilgi gelmezse o robot “Unresponsive” olarak işaretlenir ve görev atanmaz. Robot durumlarına düzenli API çağrıları yaparak erişebilir ve buna göre aksiyon alınabilir. Güzel bir entegrasyon imkanı öyle değil mi?

Peki… Bir sorun olduğunda siz ona gitmeden Orchestrator size gelse? Webhook’lar tam olarak bunun için buradalar. UiPath Orchestrator’da “X” olayı olduğunda “Y” adresine çağrı at şeklinde ayar yapılabiliyor. Bu sayede sürekli istek atmak yerine, yalnızca gerekli olduğunda istekler alınabiliyor.

Robot düşerse kim kaldırır?

Robotların düşme tiplerini, nedenlerini ve önemini konuştuk. Ancak her şeye rağmen olur da düşerse kim ayağa kaldırır? Bizce bunun cevabı RPA Admin. Dijital dönüşüm ve RPA konusunda ciddi organizasyonlarda bu rolün hayati bir önem taşıdığını düşünüyoruz. Çünkü RPA Admin hem altyapı hem de süreçler konusunda organizasyon içindeki merkez üssü oluyor ve tarafların hem iletişimde kalmasını hem de robotların ayakta kalmasını sağlıyor.