UiPath Automation Hub’da Form, Idea Flow ve KPI Tasarımı

Merhaba, bu yazımızda UiPath Automation Hub üzerinde gerçekleştirdiğim form özelleştirme, değerlendirme versiyonları, Idea Flow, KPI ve maliyet-fayda analizi çalışmalarını ele alacağız. Uygulamada dikkat ettiğim noktaları ve bu çalışmalar sırasında edindiğim deneyimleri paylaşacağım. Şimdiden iyi okumalar.

Otomasyon projelerinde çoğunlukla geliştirme aşamasına odaklanıyoruz. Ancak geliştirmeye başlamadan önce talebin doğru anlaşılması, otomasyona uygunluğunun değerlendirilmesi ve beklenen faydanın hesaplanması gerekiyor.

Automation Hub üzerindeki çalışmalarımın önemli bir kısmı, bu bilgilerin tutarlı biçimde toplanması ve değerlendirilmesi üzerineydi. Formdaki bir sorunun ifadesinden KPI formülüne, değerlendirme versiyonundan kullanıcı yetkisine kadar birçok detayın sonucu etkileyebildiğini gördüm.

1. Talep ve Süreç Gereksinimi Formlarının Tasarlanması

Çalışmalarım kapsamında, otomasyon talebinin alınması ve ayrıntılı süreç bilgilerinin toplanması için iki ayrı form geliştirdim.

İlk aşamada kullanıcının ihtiyacını anlaşılır biçimde aktarabilmesine odaklandım. Ayrıntılı değerlendirmede ise işlem hacmi, süre, çalışma sıklığı ve kullanılan uygulamalar gibi bilgileri ele aldım.

Form tasarlarken her soruyu şu açıdan değerlendirdim: Bu cevap, süreç hakkında hangi kararı vermemize yardımcı olacak?

Örneğin, “İşlem hacmi nedir?” sorusu farklı şekillerde yorumlanabilir. Bir kullanıcı kendi günlük işlem sayısını, başka bir kullanıcı bütün ekibin aylık toplamını yazabilir. Sayısal cevap alınmasına rağmen iki veri aynı anlamı taşımayabilir.

Bu nedenle soruların açıklamalarında dönem, birim ve kapsamın net olmasına dikkat ettim.

Alan	Netleştirilmesi gereken bilgi
İşlem hacmi	Günlük, aylık veya yıllık toplam mı?
İşlem süresi	Tek bir işlem için harcanan süre mi?
Çalışan sayısı	Süreci gerçekleştiren toplam kişi sayısı mı?
Çalışma sıklığı	Hacmin ait olduğu dönemle nasıl ilişkilendiriliyor?
Maliyet	Hangi dönem ve maliyet kapsamı kullanılıyor?

Formları güncellerken gereksiz veya farklı yorumlanabilen soruları da yeniden değerlendirdim. Bazı alanları kaldırdım ve bu alanların bağlı olduğu KPI hesaplamalarını güncelledim.

Bu çalışma bana, formun sadeleştirilmesiyle hesaplama tasarımının birlikte ele alınması gerektiğini gösterdi.

2. Assessment Özelleştirmeleri ve Versiyon Yönetimi

Temel, üst düzey ve ayrıntılı değerlendirme alanlarında soruları, açıklamaları ve KPI’ları düzenledim. Assessment versiyonları oluşturarak bu değişiklikleri test ettim.

Versiyon yönetiminde dikkat ettiğim nokta, değişikliğin yalnızca form görünümünü etkilememesiydi. Bir sorunun anlamı, cevap seçenekleri veya KPI formülü değiştiğinde değerlendirme sonucunun nasıl etkilendiğini de kontrol etmek gerekiyor.

Örneğin, işlem hacmi sorusu aylık yerine yıllık toplamı alacak şekilde güncelleniyorsa formülün de buna uyarlanması gerekir. Alanın adı değiştirilip hesaplama aynı bırakılırsa sonuç beklenenden farklı çıkabilir.

Bu nedenle güncellemeleri şu sırayla ele aldım:

1. Sorunun veya hesaplamanın neden değiştiğini belirlemek.
2. İlgili alanları ve bağlı KPI’ları incelemek.
3. Yeni versiyonda düzenlemeyi yapmak.
4. Örnek cevaplarla sonucu kontrol etmek.
5. Mevcut taleplere etkisini değerlendirmek.

Automation Hub’da değerlendirme versiyonlarının yönetilebilmesi, bu değişiklikleri takip edebilmek açısından önemli bir imkân sunuyor.

3. Assessment ile Idea Flow Arasındaki Bağlantı

Çalışmalarımda değerlendirme versiyonlarını ilgili Idea Flow’larla eşleştirdim. Burada formu hazırlamakla, hangi akışta hangi versiyonun kullanılacağını belirlemenin ayrı adımlar olduğunu deneyimledim.

Automation Hub’da bir Idea Flow için kullanılacak değerlendirme versiyonu seçilebiliyor. Bu seçim, kullanıcıya sunulan değerlendirme içeriğini belirliyor.

Yeni Talepler ve Mevcut Talepler Arasındaki Fark

Idea Flow üzerinde kullanılacak assessment versiyonunu değiştirmek, mevcut bütün taleplerin otomatik olarak yeni versiyona taşındığı anlamına gelmez. Yeni oluşturulan talepler seçilen versiyonu kullanırken, daha önce değerlendirilmiş mevcut talepler kendi versiyonlarını koruyabilir. Mevcut taleplerin versiyon geçişi ayrıca ele alınmalıdır.

Örnek olarak, bir akışta V1 kullanılırken V2’yi seçtiğimizi düşünelim:

Durum	Beklenen davranış
Değişiklikten sonra oluşturulan yeni talep	Akışta seçilen V2 değerlendirmesi kullanılır.
V1 ile değerlendirilmiş mevcut talep	Yalnızca akış seçiminin değişmesiyle V2’ye taşınmaz.
Mevcut talebin ayrıca V2’ye geçirilmesi	Ortak soruların cevapları korunur; yeni zorunlu soruların tamamlanması gerekir.

Bu örnek, daha önce değerlendirilmiş talepleri esas alır. İlk değerlendirmesine henüz geçmemiş taleplerin davranışı, yaşam döngüsündeki aşamalarıyla birlikte kontrol edilmelidir. Birden fazla kaydın geçişi için kullanılabilecek Mass Update işlemini de ayrı bir versiyon güncelleme adımı olarak değerlendirmek gerekir.

Bu nedenle form güncellemelerinin ardından talep oluşturma deneyimini de kontrol ettim. Hazırladığım soruların ve açıklamaların ilgili akışta beklediğim şekilde görüntülenmesini test ettim.

Idea Flow tarafında ise aşamalarla kullanıcı sorumluluklarını birlikte değerlendirdim. Bir talebin hangi aşamada olduğu kadar, o aşamada kimden hangi işlemin beklendiği de anlaşılır olmalı.

Kendi deneyimimde şu soruların netleştirilmesini önemli buldum:

• İlk incelemeyi kim yapacak?
• Eksik süreç bilgilerini kim tamamlayacak?
• Teknik değerlendirmeyi kim gerçekleştirecek?
• Talebin sonraki aşamaya geçişini kim yönetecek?
• Bu kullanıcılar hangi bilgileri düzenleyebilecek?

Akış tasarımı ve yetkilendirme birlikte değerlendirildiğinde, talebin ilerleyişini test etmek de kolaylaşıyor.

4. Automation Potential ve Ease of Implementation

Değerlendirmelerde üzerinde çalıştığım iki önemli gösterge, Automation Potential ve Ease of Implementation oldu.

Bu göstergeler farklı sorulara cevap veriyor:

Gösterge	Anlamı
Automation Potential	Süreçteki iş yükünün otomasyona uygun bölümünü ifade eder.
Ease of Implementation	Otomasyonun uygulanma kolaylığını ifade eder.

Ease of Implementation değerinde yüksek puan, daha yüksek uygulama kolaylığı anlamına geliyor. Dolayısıyla bu göstergeyi “zorluk puanı” olarak yorumlamamak gerekiyor.

Uygulamada bu iki değeri birlikte değerlendirdim. Bir sürecin otomasyon potansiyelinin yüksek olması, geliştirmesinin de kolay olacağı anlamına gelmiyor.

Örneğin, tekrarlayan iş yükü yüksek bir süreçte birden fazla uygulama, farklı işlem yolları veya değişken ekran yapıları bulunabilir. Bu durumda beklenen faydayla uygulama koşullarını birlikte incelemek gerekir.

Temsili olarak %80 Automation Potential ve %40 Ease of Implementation değerine sahip bir süreç, yüksek otomasyon potansiyeli taşırken uygulama açısından daha fazla inceleme gerektirebilir. Ease of Implementation değerinin %40 olması, geliştirme eforunun %40 olduğu veya projenin %40 olasılıkla başarılı olacağı anlamına gelmez. Bu değerler algoritmanın değerlendirme göstergeleridir; doğrudan süre ya da başarı olasılığı değildir.

Benim için bu göstergeler, süreç hakkında teknik değerlendirmeyi destekleyen veriler oldu.

5. Manuel İş Yükünden Beklenen Faydaya Geçiş

KPI çalışmalarımda en çok dikkat ettiğim konulardan biri, mevcut manuel iş yüküyle beklenen otomasyon faydasının ayrılmasıydı.

Basit bir örnek üzerinden ilerleyelim. Aşağıdaki sayılar tamamen temsilidir:

• Yıllık işlem sayısı: 12.000 işlem/yıl
• İşlem başına manuel süre: 5 dakika/işlem

Yıllık manuel iş yükü:

12.000 işlem/yıl × 5 dakika/işlem = 60.000 dakika/yıl

Saat birimine dönüştürdüğümüzde:

60.000 dakika/yıl ÷ 60 dakika/saat = 1.000 saat/yıl

Bu değer, sürecin mevcut manuel iş yükünü gösterir. Tamamının otomasyonla kazanılacağını henüz söylemez.

Otomasyon potansiyelinin %70 olduğunu varsayarsak:

1.000 saat/yıl × (70 / 100) = 700 saat/yıl beklenen kapasite kazanımı

Buradaki %70, bu hesaplama kapsamında manuel iş yükünün otomasyona uygun kabul edilen bölümünü temsil eder. İşlemlerin %70 daha hızlı gerçekleştiği anlamına gelmez. Geriye kalan 300 saat/yıl, bu basitleştirilmiş modelde otomasyonla kazanım hesabına dâhil edilmeyen iş yüküdür.

Automation Hub’ın standart fayda hesaplamalarında da yıllık saat kazanımı, yıllık iş yükü ve otomasyon potansiyeli üzerinden hesaplanıyor.

Bu hesaplamaları değerlendirirken manuel kalacak adımları, kontrol ihtiyacını ve istisnaları da dikkate aldım. Hesaplanan potansiyel faydayla canlı kullanımda gerçekleşen kazanımın farklı aşamalara ait olduğunu gözetmek gerekiyor.

Çalışma Sıklığında Mükerrer Hesaplama Riski

Çalışma sıklığı seçeneklerini farklı periyotları kapsayacak şekilde düzenledim. Burada hacmin hangi dönem için alındığıyla sıklığın nasıl kullanıldığı birlikte kontrol edilmeli.

Örneğin, aylık işlem hacmi 500 ise yıllık hacim şu şekilde hesaplanır:

500 işlem/ay × 12 ay/yıl = 6.000 işlem/yıl

İşlem başına süre 5 dakika olduğunda:

6.000 işlem/yıl × 5 dakika/işlem ÷ 60 dakika/saat = 500 saat/yıl

Ancak forma zaten 6.000 işlem/yıl girilmişse bu değeri tekrar 12 ile çarpmak, yıllık hacmi 12 kat fazla hesaplamak anlamına gelir.

Haftalık veya günlük süreçlerde de aynı yaklaşım geçerlidir. Günlük bir hacim yıllıklandırılırken sürecin hafta içi, hafta sonu veya belirli günlerde çalışması dikkate alınmalıdır. Kullanılan dönem çarpanı, gerçek çalışma takvimine uygun seçilmelidir.

Bu nedenle yalnızca formülün çalışmasını kontrol etmekle yetinmedim; çıkan değerin süreç açısından anlamlı olup olmadığını da değerlendirdim.

FTE Hesabı

FTE (Full-Time Equivalent), iş yükünün tam zamanlı çalışan kapasitesi cinsinden karşılığını ifade eder. FTE hesabında kullandığım temel ilişki şu şekildeydi:

FTE karşılığı = Yıllık iş yükü (saat/yıl) / Bir çalışanın yıllık çalışma kapasitesi (saat/yıl)

Bir çalışanın yıllık çalışma kapasitesi, yıllık çalışma günü ile günlük çalışma süresinin çarpılmasıyla hesaplanır. Tamamen temsili değerlerle:

• Yıllık iş yükü: 1.000 saat/yıl
• Bir çalışanın yıllık çalışma kapasitesi: 250 gün/yıl × 7 saat/gün = 1.750 saat/yıl
• FTE karşılığı: 1.000 / 1.750 ≈ 0,57 FTE

Bu sonuç, iş yükünün bir tam zamanlı çalışanın yıllık kapasitesinin yaklaşık %57’sine karşılık geldiğini gösterir.

Hesaplamada yıllık çalışma günü ve günlük çalışma süresi, kurumun kabul ettiği varsayımlara göre belirlenmeli; pay ve payda aynı zaman biriminde kullanılmalıdır. Bu örnekte her iki değer de saat/yıl cinsindedir.

Ayrıca FTE karşılığını iş yükünün bir ifadesi olarak ele aldım. Bu değerin doğrudan personel azaltımı veya gerçekleşmiş finansal tasarruf anlamına geldiğini varsaymamak gerekiyor.

Bu örnekte hesaplanan 0,57 FTE, sürecin toplam manuel iş yüküne aittir. %70 otomasyon potansiyeliyle bulunan 700 saat/yıl beklenen kazanımın FTE karşılığı ise 700 / 1.750 = 0,40 FTE olur. Toplam iş yükünün FTE karşılığıyla beklenen kazanımın FTE karşılığını ayrı değerlendirmek gerekir.

6. KPI Formüllerini Değiştirirken Mevcut Talepler

KPI formüllerini güncellerken yeni oluşturulan taleplerin yanında mevcut talepleri de kontrol ettim.

Automation Hub’da fikirler yeni değerlendirme versiyonuna geçirildiğinde, değişen KPI formülleri için mevcut cevaplar üzerinden yeniden hesaplama yapılabiliyor. Bu nedenle versiyon değişikliğinin değerlendirme sonuçlarına etkisi incelenmeli.

Bu kontrollerde özellikle şu durumlara odaklandım:

• Formdan kaldırılan sorular.
• Anlamı veya birimi değişen alanlar.
• Güncellenen çalışma günü ve maliyet parametreleri.
• Mevcut cevapların yeni hesaplamaya uygunluğu.
• Eksik cevapların sonuç üzerindeki etkisi.

Kullandığım yöntemlerden biri, aynı örnek cevaplarla eski ve yeni hesaplama sonuçlarını karşılaştırmaktı. Sonuç değiştiğinde bunun beklenen bir formül değişikliğinden mi, yoksa yanlış veri yorumundan mı kaynaklandığını kontrol ettim.

Formül Değişikliğine Sayısal Bir Örnek

Yıllık hacmi 12.000 işlem, işlem süresi 5 dakika olan bir süreç düşünelim. Eski hesaplamada güncel olmayan bir varsayım nedeniyle 4 dakika kullanılıyorsa sonuç 800 saat/yıl çıkar. Süre 5 dakika olarak düzeltildiğinde sonuç 1.000 saat/yıl olur.

%70 otomasyon potansiyeliyle beklenen kazanım da 560 saat/yıl değerinden 700 saat/yıl değerine çıkar. Bu temsili örnekte değişiklik, işlem hacmindeki artıştan değil, hesaplama varsayımının düzeltilmesinden kaynaklanır.

Aylık hacim sorusunun yıllık hacim sorusuna dönüştürülmesi gibi birim değişikliklerinde ise mevcut sayısal cevabın aynı kalması yeterli değildir. Eski cevap 1.000 işlem/ay anlamına geliyorsa, yeni alanda 1.000 işlem/yıl olarak yorumlanmamalıdır. Versiyon geçişinden önce verinin anlamı ve gerekiyorsa dönüşümü kontrol edilmelidir.

Ayrıca bir soru başka bir KPI formülünde kullanılıyorsa, soruyu kaldırmadan önce bu bağımlılık düzenlenmelidir. Görünürlük ayarını değiştirmekle soruyu ve hesaplamadaki etkisini kaldırmak aynı işlem değildir.

7. Cost Benefit Analysis ve Revised KPI’lar

İlk değerlendirmeyle elde edilen sonuçları, Cost Benefit Analysis aşamasındaki değerlerle karşılaştırarak çalıştım.

İlk aşamada süreç hakkında belirli varsayımlar bulunabilir. Teknik inceleme ilerledikçe otomasyon kapsamı, uygulanabilirlik ve maliyet bilgileri daha net hâle gelebilir.

Automation Hub’da değerlendirme algoritmasının hesapladığı göstergelerle teknik uzmanların Cost Benefit Analysis üzerinde belirlediği değerler karşılaştırılabiliyor. Pipeline tarafında da revize sonuçları yansıtan KPI alanları bulunuyor.

Bu nedenle raporları incelerken yalnızca rakama bakmak yeterli olmuyor. Rakamın ilk değerlendirmeden mi, yoksa güncellenmiş maliyet-fayda analizinden mi geldiğini anlamak gerekiyor.

Benim için önemli olan, ilk tahminle güncel değerlendirmenin izlenebilir olmasıydı. Böylece fayda beklentisindeki değişikliğin nedenini daha açık biçimde değerlendirebildim.

İlk ve Revize Tahminin Karşılaştırılması

Aynı yıllık manuel iş yükü için otomasyon potansiyelinin teknik inceleme sonrasında değiştiğini varsayalım:

Gösterge	İlk değerlendirme	Revize değerlendirme
Yıllık manuel iş yükü	1.000 saat/yıl	1.000 saat/yıl
Otomasyon potansiyeli	%70	%60
Beklenen kapasite kazanımı	700 saat/yıl	600 saat/yıl

Bu temsili örnekte manuel iş yükü değişmemiştir. Beklenen kazanımın azalmasının nedeni, otomasyona alınabilecek kapsamın daha ayrıntılı değerlendirilmesidir. Revize tahmin de gerçekleşmiş sonuç değil, güncellenmiş bir öngörüdür.

Kapasite Kazanımı, Parasal Fayda ve Net Fayda

Bu kavramları ayrı okumak gerekir:

• Kapasite kazanımı: Saat/yıl veya FTE olarak ifade edilen beklenen iş yükü kazanımıdır.
• Parasal fayda: Kazanılan kapasitenin kabul edilen maliyet varsayımlarıyla parasal karşılığıdır; doğrudan nakit tasarrufu anlamına gelmeyebilir.
• Net fayda: Seçilen analiz döneminde, hesaplanan faydadan ilgili otomasyon maliyetlerinin çıkarılmasıyla değerlendirilir.

Basitleştirilmiş ve tamamen temsili olarak saatlik çalışan maliyetinin 300 TL/saat olduğunu varsayalım:

600 saat/yıl × 300 TL/saat = 180.000 TL/yıl brüt kapasite faydası

İlk yıl için 80.000 TL tek seferlik uygulama maliyeti ve 30.000 TL işletim/bakım maliyeti kabul edilirse:

İlk yıl net faydası = 180.000 − 80.000 − 30.000 = 70.000 TL

Bu örnek kavramsal bir hesaplamadır. Automation Hub üzerindeki sonuçlar, Cost Benefit Analysis’e girilen maliyet kalemleri, dönemler ve kullanılan varsayımlar üzerinden değerlendirilmelidir. Özellikle tek seferlik geliştirme maliyetiyle her yıl tekrarlayan maliyetler ayrı ele alınmalıdır.

8. Kategori ve Yetkilendirme Tasarımı

Kategori yapıları ve kullanıcı yetkileri üzerinde de düzenlemeler yaptım. Taleplerin doğru başlıklar altında toplanmasını ve kullanıcıların sorumluluklarına uygun işlemleri gerçekleştirebilmesini ele aldım.

Yetkilendirmede şu işlemleri ayrı değerlendirdim:

• Talep oluşturma.
• Talebi görüntüleme.
• İçeriği düzenleme.
• Talebin bulunduğu aşamayı değiştirme.
• Akış tasarımını yönetme.

Bu işlemlerin tamamının aynı kullanıcıya verilmesi gerekmeyebilir. Bu nedenle önce kullanıcının gerçekleştirmesi beklenen işi belirleyip ardından ilgili izinleri kontrol ettim.

Bazı kayıtlarda yaşanan düzenleme sorunlarında kullanıcı rolünü, kategori erişimini, Idea Access ayarlarını ve akış aşamasındaki izinleri birlikte inceledim. Teknik incelemeyi ekran görüntüleri ve HAR kayıtlarıyla destekledim.

Örneğin, bir kullanıcı talebi görüntüleyebiliyor ancak düzenleyemiyorsa bunu yalnızca kategori erişimiyle açıklamak yeterli olmayabilir. Şu kontrolleri ayrı ele almak gerekir:

Kontrol	İncelenecek nokta
Kullanıcı rolü	Kullanıcının gerçekleştirebileceği işlemler
Kategori erişimi	İlgili kategori kapsamındaki yetkisi
Kayıt üzerindeki erişim	İlgili talepteki collaborator rolü ve Idea Access ayarları
Akış aşaması	Mevcut aşamada izin verilen düzenleme ve geçiş işlemleri

Benzer şekilde, talep içeriğini düzenlemekle aşama geçişini gerçekleştirmek ayrı ihtiyaçlardır. Birinin çalışması diğerinin de çalıştığını göstermez. Bu kontrolleri yaparken kullanıcıya daha geniş yetki vermeden önce eksikliğin hangi katmanda olduğunu belirlemeye odaklandım.

Bu çalışmalar, yetki kontrollerinin gerçek kullanıcı ve kayıt senaryolarıyla yapılmasının önemini gösterdi.

9. Değişiklikleri Nasıl Test Ettim?

Form, akış ve KPI düzenlemelerini birlikte test ettim. Bir alanın ekranda görünmesi, değişikliğin tamamlandığını göstermiyor; cevabın kaydedilmesi ve hesaplamaya doğru yansıması da gerekiyor.

Kontrollerimde şu noktalara odaklandım:

Kontrol	Amaç
Yeni talep oluşturma	Doğru form ve versiyonun sunulduğunu görmek
Mevcut talebi düzenleme	Güncellemenin mevcut kayıtlara etkisini incelemek
Farklı cevaplarla hesaplama	KPI sonucunu doğrulamak
Kullanıcı rolleriyle işlem yapma	Yetkilerin kullanım ihtiyacını karşıladığını görmek
Form kopyalama	Alanların ve açıklamaların taşındığını kontrol etmek
Cost Benefit Analysis karşılaştırması	İlk ve revize değerleri doğru yorumlamak

Örneğin, form kopyalama sırasında dosya yükleme sorusunun taşınmadığı bir durumla karşılaştım. Bu deneyimden sonra kopyalanan formu doğrudan kullanmak yerine alanlarını tek tek kontrol etmeye daha fazla dikkat ettim.

Sayısal Sonuçların Doğrulanması

Aşağıdaki temsili test verileri, formülün yalnızca hata vermeden çalışmasını değil, beklenen sonucu üretmesini de kontrol etmek için kullanılabilir:

Test girdisi	Beklenen sonuç
12.000 işlem/yıl, 5 dakika/işlem	1.000 saat/yıl manuel iş yükü
500 işlem/ay, 12 ay/yıl, 5 dakika/işlem	500 saat/yıl manuel iş yükü
1.000 saat/yıl iş yükü, %70 otomasyon potansiyeli	700 saat/yıl beklenen kapasite kazanımı
1.000 saat/yıl iş yükü, 1.750 saat/yıl çalışan kapasitesi	Yaklaşık 0,57 FTE toplam iş yükü
700 saat/yıl beklenen kazanım, 1.750 saat/yıl çalışan kapasitesi	0,40 FTE beklenen kapasite kazanımı
1.000 saat/yıl iş yükü, %0 otomasyon potansiyeli	0 saat/yıl beklenen kazanım
1.000 saat/yıl iş yükü, %100 otomasyon potansiyeli	1.000 saat/yıl beklenen kazanım

Boş değer, sıfır ve geçersiz girdi durumları da ayrıca kontrol edilmelidir. Özellikle çalışan kapasitesi gibi bölen olarak kullanılan alanlarda sıfır değerinin hesaplama hatasına yol açması önlenmelidir. Eksik veriden üretilen bir sonuçla gerçek sıfır sonucunun kullanıcı tarafından ayırt edilebilmesi önemlidir.

10. Bu Çalışmalardan Ne Öğrendim?

Automation Hub üzerindeki çalışmalarım, otomasyon geliştirmeye talebin oluştuğu noktadan bakmamı sağladı.

En belirgin öğrendiğim konu, form tasarımıyla hesaplama tasarımının birbirinden ayrı düşünülemeyeceğiydi. Bir sorunun açıklaması değiştiğinde, o cevabı kullanan formüllerin de incelenmesi gerekiyor. Benzer şekilde değerlendirme versiyonunun güncellenmesi, ilgili Idea Flow’un ve mevcut taleplerin kontrolünü de beraberinde getiriyor.

Bu çalışmalar sırasında teknik doğrulamanın yanında kullanıcı deneyimine de odaklandım. Kullanıcının soruyu doğru anlaması, değerlendirme ekibinin doğru bilgiye ulaşmasını sağlıyor.

Automation Hub’da hazırladığım yapılar ve yaptığım testler sayesinde, bir otomasyon talebinin geliştirmeye hazır hâle gelmesi için gereken adımları daha yakından deneyimledim. Doğru sorular, açık hesaplama varsayımları ve test edilmiş yetkiler, bu sürecin daha anlaşılır ilerlemesine katkı sağlıyor.

Bir sonraki yazıda görüşmek üzere.

Sayısal örnekler temsilidir; kurum veya proje verisi içermez. Teknik ekranlar ve özellikler kullanılan sürüme göre farklılık gösterebilir.