API'si olmayan eski sistemlerde, insanın ekranda yaptığı tekrar eden adımları üstlenen yazılım robotları kuruyoruz. Robot kendi kullanıcı hesabıyla ve takvime bağlı çalışır; beklenmedik bir durumda tahmin yürütmez, durur ve işi ekran görüntüsüyle birlikte insana devreder.
Her ofisin, kimsenin adını koymadığı bir işi vardır: sabah bir programı açıp ekrandaki listeyi başka bir programa tek tek girmek. Banka ekstresini indirip muhasebeye işlemek, pazaryeri panelinden sipariş listesini kopyalayıp sevkiyat dosyasına yapıştırmak, gelen e-postadaki Excel'i satır satır sisteme aktarmak. Bu iş genellikle tek bir kişinin üzerindedir ve o kişi izne çıktığında iş durur. Kimse bunu bir süreç olarak görmez, çünkü hiçbir prosedürde yazmaz ve hiçbir raporda görünmez. Oysa gün içinde saatler tutar, mesai sonunun yorgunluğunda hata üretir ve hatanın nerede yapıldığı çoğu zaman ancak haftalar sonra, bir mutabakat tutmadığında fark edilir.
Bu işin doğru çözümü çoğu zaman entegrasyondur: iki sistem birbirine bağlanır ve veri elle taşınmaz. Ne var ki sahada bu her zaman mümkün olmaz. Kullanılan program yıllar önce yazılmıştır, dışarıya bir arayüzü (API) yoktur; yazan firmaya ulaşılamaz ya da geliştirme yapmak istemez. Kimi zaman da gelen geliştirme teklifi, o işin bir yıllık elle yapılma maliyetinden yüksek çıkar. Bazen lisans sözleşmesi veri tabanına doğrudan yazmayı yasaklar, bazen de yazmak destek kapsamını düşürür. Kimi zaman sistem zaten yakında değişecektir ve bugün ona entegrasyon yatırımı yapmak mantıklı değildir. Kısacası doğru kapı kapalıdır, ama iş her sabah aynı şekilde yapılmaya devam etmektedir.
Robotik süreç otomasyonu (RPA) tam bu noktada devreye girer. RPA, insanın ekranda yaptığı adımları, yani pencereyi açmayı, alana tıklamayı, veriyi yazmayı, kaydete basmayı ve listeyi indirmeyi kurallara bağlayıp tekrarlanabilir biçimde çalıştıran bir yazılım robotudur. Robot hedef sistemin arayüzünü tıpkı bir kullanıcı gibi kullanır; bu yüzden o programda hiçbir değişiklik yapılması, hiçbir güncelleme talep edilmesi gerekmez. Robotun kendi kullanıcı hesabı ve kendi yetki sınırı olur, ne zaman çalışacağı bir takvime bağlanır ve attığı her adım kayda geçer. Beklemediği bir ekranla karşılaştığında ise devam etmez; durur ve işi bir insana devreder. Robot böylece bir çalışanın kısayolu değil, denetlenebilir bir sistem bileşeni olarak kurulmuş olur.
Bu işi dürüst kurmanın şartı, RPA'nın ne olmadığını baştan söylemektir. Hedef sistemin arayüzü (API) varsa doğru çözüm RPA değil entegrasyondur; entegrasyon daha hızlı çalışır, daha ucuza kurulur ve çok daha dayanıklıdır. RPA ise ekrana bağımlıdır: sistem bir güncellemeyle ekran düzenini değiştirdiğinde robot durur ve bakım gerektirir. Bu bakım yükü işin gerçeğidir ve projeye baştan yazılır. Ayrıca kötü kurgulanmış bir süreci robotlaştırmak onu düzeltmez, yalnızca hatayı hızlandırır; bu yüzden robota geçmeden önce sürecin gereksiz adımlarını ayıklarız. RPA'yı kalıcı bir mimari olarak değil, entegrasyonun mümkün olmadığı yerde çalışan bir köprü olarak öneririz.
Yıllardır kullanılan, işini görmeye devam eden ama dışarıya veri arayüzü sunmayan programlar. Yazan firmaya ulaşılamıyor, kaynak kod elde yok ya da veri tabanına doğrudan yazmak sözleşme gereği mümkün değil. Bu firmalarda robot, sistemi hiç değiştirmeden ekran üzerinden çalışır ve elle yapılan aktarımı üstlenir.
Banka ekstresi indirme, dekont eşleştirme, cari mutabakat ve fatura kaydı gibi işlerin her gün tekrarlandığı muhasebe ve finans ekipleri. Adımlar bellidir, karar payı azdır, hacim yüksektir. Robot bu adımları gece çalıştırır; ekip sabah yalnızca istisna kuyruğuna bakar. Kazanç sadece zamanda değil, dikkat hatalarının azalmasındadır.
Sipariş, stok ve fiyat bilgisini birden çok pazaryeri veya tedarikçi panelinden elle toplayan ekipler. Panellerin bir kısmı API sunar, bir kısmı sunmaz. Sunanlar için entegrasyon kurar, sunmayanlar için robot yazar ve ikisini aynı akışta birleştiririz. Panelin kullanım şartlarına aykırı bir kullanım söz konusuysa bunu baştan söyleriz.
Yeni bir ERP veya sektörel yazılım seçilmiş, geçiş aylar sürecek. Bu dönemde eski ve yeni sistem bir arada çalışır, aynı veri iki yerde tutulur ve aradaki eşitleme ekibin sırtında kalır. Robot bu geçici köprüyü kurar, geçiş tamamlanınca kaldırılır. RPA'nın en dürüst kullanım alanlarından biri budur.
| Yetenek | Ne sağlar |
|---|---|
| Robota uygunluk elemesi | Her tekrar eden iş robot işi değildir. Adımların kural olarak yazılabilmesi, girdinin yapılı olması, hacmin anlamlı olması ve istisnaların sayılabilir olması aranır. Bu elemede sık çıkan sonuç şudur: işin bir kısmı zaten arayüzle çözülebilir, bir kısmı gereksizdir ve kaldırılabilir, geriye kalan asıl kısım robota verilir. Elemeyi atlayan RPA projeleri genellikle bakım yükü altında sessizce terk edilir. |
| Masaüstü, web ve terminal ekranı otomasyonu | Robot; Windows masaüstü uygulamalarında, tarayıcıdaki web panellerinde ve eski terminal ekranlarında çalışabilir. Alanlar mümkün olduğunca konuma göre değil kimliğe göre seçilir, böylece pencere boyutu veya ekran çözünürlüğü değiştiğinde robot bozulmaz. Konum tabanlı tıklama yalnızca başka yol kalmadığında ve bunun kırılgan olduğu yazılı olarak belirtilerek kullanılır. |
| Çalışma takvimi, kuyruk ve sıra yönetimi | Robotlar gece, vardiya sonunda ya da bir olay tetiklendiğinde çalışır. İşler kuyruğa alınır; her kayıt tek tek işlenir ve durumu ayrı ayrı tutulur. Böylece bin satırlık bir aktarım ortada kesildiğinde baştan başlamak gerekmez, kaldığı yerden devam eder. Aynı anda kaç robotun çalışacağı ve hedef sistemi ne kadar yoracağı da sınırlandırılır. |
| İstisna yönetimi ve insana devir | Robot beklemediği bir ekranla karşılaştığında tahmin yürütmez, durur. İşlem istisna kuyruğuna düşer; ekran görüntüsü ve o ana kadar atılan adımlar kaydedilir, sorumluya bildirim gider. Gerektiğinde yarım kalan işlem geri alınır. Sessizce yanlış veri yazan bir robot, hiç çalışmayan robottan çok daha pahalıdır ve tasarımı bu ilkeye göre yaparız. |
| Kimlik, yetki ve parola yönetimi | Robot bir çalışanın hesabını ödünç almaz; kendi kullanıcı hesabıyla ve yalnızca yapacağı işe yetecek yetkiyle çalışır. Parolalar koda gömülmez, şifreli bir kasada tutulur, çalışma anında alınır ve loglara düşmez. Robotun yaptığı her işlem kendi kimliğiyle kaydedilir; böylece denetimde bu kaydı kim girdi sorusunun cevabı belirsiz kalmaz. |
| Robot envanteri ve yönetişim | Hangi robot hangi süreci çalıştırıyor, sahibi kim, hangi sistemlere dokunuyor, en son ne zaman güncellendi ve bozulduğunda kim aranacak: hepsi tek bir envanterde tutulur. Robot sayısı arttıkça kimsenin ne yaptığını bilmediği robotlar birikir; envanter ve sahiplik bunu baştan engeller. Değişiklikler sürümlenir ve gerektiğinde eski sürüme dönülür. |
| Belge okuma ile birleşik akışlar | Girdi PDF veya taranmış evraksa robot tek başına yetmez. Belgeden alan çıkarma ile robot birlikte kurgulanır: belge okunur, alanlar çıkarılır, güven skoru düşük olanlar insana sorulur ve doğrulanan veriyi robot sisteme işler. Böylece okuma ve giriş adımı tek akışta yürür, arada yeniden elle yazılan bir ara dosya kalmaz. |
Sahada işi fiilen yapan kişiyle birlikte adımları ekran ekran çıkarırız. İlk sorduğumuz soru, hedef sistemin bir arayüzü (API) olup olmadığıdır. Varsa RPA önermez, entegrasyon öneririz. Yoksa hangi adımların robota, hangilerinin insanda kalacağını birlikte belirleriz. Bu aşama tek bir süreç için genellikle birkaç gün sürer ve sonunda kapsamı yazılı olarak paylaşırız.
Robota geçmeden önce süreçten gereksiz adımlar ayıklanır; çünkü olduğu gibi robotlaştırılan bozuk bir süreç yalnızca daha hızlı bozulur. Kalan adımlar istisnalarıyla birlikte tek tek yazılır. Bu yazılı akış hem geliştirmenin hem de ileride bakımın temeli olur. Aynı çalışmada işin hangi sıklıkta ve hangi hacimde tekrarlandığını da kayda geçiririz.
Robot kısa döngülerle geliştirilir: önce ana akış, sonra istisnalar. Sistem yanıt vermezse, kayıt zaten varsa veya alan beklenenden farklıysa ne olacağı tek tek kurgulanır. İlk robot için tipik süre 3-6 haftadır; bağlanacak ekran sayısı ve istisnaların çeşidi bu süreyi belirler. Her sürüm önce sizin test ortamınızda çalıştırılır.
Robot bir süre insanla paralel çalışır: robot işler, sonucu insan doğrular. Bu dönemde yakalanan farklar robota geri yazılır. Paralel çalışma atlandığında robotun sessiz hataları ancak aylar sonra fark edilir; bu yüzden bu adımı kısaltmayı önermiyoruz. Paralel çalışmanın ne zaman biteceğine, yakalanan fark oranı düştüğünde birlikte karar veririz.
Robot takvime bağlanır, izleme ve uyarılar açılır, robot envanterine kaydedilir. Ekibe hangi durumda ne yapılacağı yazılı olarak devredilir. Hedef sistem güncellendiğinde robotun bakım gerektirebileceğini baştan planlar, bu bakımı SLA kapsamında yürütürüz. Robot bir gün gereksizleşirse kaldırılması da aynı düzen içinde yapılır ve envanterden düşülür.
Hedef sistemin bir arayüzü (API) varsa cevap net: entegrasyon. Entegrasyon daha hızlı çalışır, daha az bakım ister ve ekran değişikliğinden etkilenmez. RPA'yı yalnızca bu kapı kapalıyken öneririz; yani arayüz yoksa, üretici geliştirme yapmıyorsa ya da veri tabanına yazmak sözleşme veya destek kapsamı nedeniyle mümkün değilse. Keşifte ilk kontrol ettiğimiz şey budur. Arayüz varken size RPA satmayız, çünkü iki yıl sonra bakım faturasını ödeyen taraf siz olursunuz.
Ekran düzeni değişirse bozulabilir ve bunu saklamıyoruz. Riski azaltmak için alanları konuma göre değil kimliğe göre seçeriz; robot beklediği ekranı bulamadığında yanlış işlem yapmak yerine durur. Bozulduğunda sessiz kalmaz, uyarı gider ve iş istisna kuyruğunda bekler. Ekran değişikliğinden kaynaklanan düzeltmeler bakım kapsamında yürür. RPA'yı bu nedenle kalıcı bir mimari değil, entegrasyon mümkün olana kadar çalışan bir köprü olarak konumlandırırız.
Hayır. Kuralı yazıya dökülemeyen, her seferinde insan yorumu gerektiren işler robota uygun değildir; girdinin serbest metin olduğu ve istisnaların kurala bağlanamadığı durumlar da öyle. Ayrıca bot korumasını aşan, iki faktörlü doğrulamayı devre dışı bırakan veya hedef sistemin kullanım şartlarına aykırı otomasyonlar geliştirmiyoruz. Böyle bir talep geldiğinde nedenini açıklar, varsa teknik ve sözleşmeye uygun alternatifi öneririz. Kapsam dışı bıraktığımız adımları da yazılı olarak bildiririz.
Robot işin tamamını değil, tekrar eden ve karar içermeyen adımını alır. Geriye kalan iş genellikle istisnaların incelenmesi, kontrol ve karar tarafıdır; bu kısım insanda kalır ve iş yükü çoğu zaman buraya kayar. Robotun devrettiği istisnalara bakacak birinin olması işin şartıdır. Kimsenin sahiplenmediği bir robot kısa sürede kimsenin güvenmediği robota dönüşür ve sonunda kapatılır. Bu yüzden devirde sorumluyu birlikte belirleriz.
Robot yalnızca kendisine tanımlanan yetki kadarını görür. Bir çalışanın hesabıyla değil kendi kullanıcı hesabıyla çalışır ve o hesaba sadece işini yapacak yetki verilir. Parolalar koda veya dosyaya yazılmaz; şifreli bir kasada tutulur, çalışma anında alınır ve loglara düşmez. Robotun her işlemi kendi kimliğiyle kaydedilir, böylece denetimde işlem izi kopmaz. Robotun çalıştığı sunucu ve tuttuğu kayıtlar sizin altyapınızda kalır.
Yazıya dökülmüş süreç akışları ve istisna senaryoları; çalışan robotlar ve çalışma takvimleri; kuyruk ve istisna ekranı; parola kasası bağlantısı ile yetki tanımları; robot envanteri, sürüm geçmişi ve izleme uyarıları. Hangi adımın neden robota verilmediğini de yazılı olarak bırakırız. Robotların kaynak kodu, dokümanı ve ürettiği kayıtlar size aittir; belirli bir RPA aracına ya da bize kilitlenmezsiniz.
30 dakikalık keşif görüşmesinde ihtiyacınızı dinler, özele mi yoksa hazır çözüme mi ihtiyacınız olduğunu dürüstçe söyleriz.
Süreçlerinizin envanterini çıkarır, gerçek hâllerini BPMN 2.0 ile haritalar, her birine bir sahip ve bir ölçü tanımlarız. Ardından bir süreç motoru (BPMS) üzerinde işletir; çevrim süresini, bekleme noktalarını ve darboğazı ölçeriz. Tek bir akış yeterliyse bunu da açıkça söyleriz.
Detay →Raporun altındaki katmanı kurarız: kaynak sistemlerden ETL veya ELT ile veri çekilir; ham, işlenmiş ve sunum katmanlarında modellenir; geçmişiyle birlikte saklanır. Metrik tanımları tek bir veri sözlüğünde sabitlenir, kalite kontrolleri sessiz bozulmaları daha yükleme sırasında yakalar.
Detay →Aynı müşterinin üç kez açıldığı, aynı malzemenin iki kodla durduğu kayıt düzenini onarırız. Eşleştirme kuralları, benzerlik skoru ve inceleme kuyruğuyla mükerrer kayıtlar tekilleştirilir, altın kayıt üretilir ve kaynak sistemlere geri dağıtılır; yeni kayıt açılırken benzer kayıt uyarısı devreye girer.
Detay →Tanı amaçlı görüntüleme yazılımı üretmiyoruz; mevcut PACS'ınız yerinde kalır. Biz cihaz worklist'i, hasta kaydı, istem, rapor ve paylaşım arasındaki boşluğu kapatan katmanı kurarız: görüntü doğru hastaya bağlanır, bekleyen istem görünür olur, arşivin saklama ve yedekleme durumu denetlenebilir hale gelir.
Detay →Başvuru, kayıt, şube yerleştirme, ders programı, yoklama, not, karne, veli iletişimi ve taksit takibini tek kayıt üzerinde birleştiren öğrenci bilgi sistemi kuruyoruz. Kurumun kendi takvimine ve kendi ücret politikasına göre kurgulanır; hazır bir paketin kalıbına girmeniz gerekmez. Kaynak kod ve veri kuruma aittir.
Detay →Numunenin kabul edildiği andan analiz sertifikasına kadar tüm adımları tek kayıt üzerinde yürüten laboratuvar bilgi yönetim sistemi kuruyoruz: barkodlu numune takibi, metot kütüphanesi, cihaz bağlantısı, spesifikasyon kontrolü, kademeli onay ve denetime hazır kayıt düzeni.
Detay →
