Mielőtt azonban belekezdenénk, mi is az orchestrator? Az orchestrator a UiPath automatizáció-kezelőjének a szíve, ez egy web alapú provisiong, monitorozó és ellenőrző rész az eszköz infrastruktúráján belül. Ha egy zenei példára gondolunk, az orchestrator a karmester, aki a zenekart – ebben az esetben a robotokat – irányítja, akik odafigyelve játszanak le minden hangjegyet a kottából – az esetünkben az egyes lépéseket a folyamatban. Tehát, a kérdést átfogalmazhatnánk úgy is, hogy: legyen-e egyetlen karmester, aki a robot zenekarunkat irányítja teljes cégcsoport szinten, vagy legyen mindenkinek külön karmestere és ezáltal zenekara is.

Az alábbi képen a UiPath Studio Community edition user interfésze látható. (Forrás: UiPath RPA Academy)

A cégcsoport szintű orchestrator előnyei:

 - Több orchestrator fenntartása költséges lehet, különösen manapság: éves licenszek, infrastruktúra költségek, mint a szerverek, adatbázis és üzemeltetési költségek mind összeadódnak – egyetlen orchestrator fenntartása gazdaságosabb.

 - Egy orchestrator esetén elegendő egy céges szintű verzió és ezáltal egyszerűbb a minőségellenőrzés is: a folyamatok és elnevezések szabványai, a keretrendszer megfelelőségek, információ biztonság, csomag verziók stb. mind központosítva vannak.

 - Nincs probléma a verziók közti elcsúszással, amíg több orchestrator esetén a cégcsoport egyes tagjai amint lehet frissíteni szeretnének, mások várnak inkább az utolsó pillanatig. Ez hátráltathatja a céges szintű szabályok szinkronizációját, a hozzáférési jogok kezelését és általánosságban a szabványosítást, mivel a verziók nem biztos, hogy visszafelé is kompatibilisek (különösképp a régebbi orchestratorok esetében) és biztosan nem tartalmazzák ugyanazt a funkcionalitást.

 - Ha minden robot ugyanannak a szabványnak felel meg és ugyanazzal a csomag verzióval fejlesztik, egyszerűbb a komponensek újra hasznosítása is, ami felgyorsíthatja a fejlesztést és csökkentheti a költségeket.

A cégcsoport szintű orchestrator hátrányai:  

 - Biztonsági kérdés: “alagutat” nyitunk az országok/leányvállalatok között, ami problémás lehet információ biztonság szempontból.

 - Az RPA csapatok és RPA folyamatok általában gyorsabban növekednek, ha nincs felettük egy ellenőrző szervezet: az RPA fejlesztés gyors jellegét és általános célját tekintve, a növekedésének a hátráltatása erősen hátrányos lehet.

 - Sokkal kényelmesebb egy saját orchestratorral rendelkező RPA csapatnak, akinek nem kell várnia egy harmadik félre, mint bármilyen más felállásban.

 - A “Ki költözik kihez?” kérdése nehézkes lehet: ha több csapat is elindított már egy orchestratort, mindig nehéz döntés lesz, hogy ki költözik be kihez.

 1. A kevesebb robottal rendelkező csapatok költözzenek? – azon az elven, hogy az költözzön, akinek a kevesebb bútora van; vagy

 2. Minden leányvállalat költözzön be az anyavállalathoz? – azon az elven, hogy az anyavállalatnak kell irányítania az orchestratort; vagy

 3. Mindenki ahhoz költözzön be, aki először indította az orchestratorát? – azon az elven, hogy azok legyenek az irányítók, akik úttörők a technológiában a cégcsoporton belül.

Minden ügyfél más, mindenkinek a saját körülményeit kell figyelembe vennie, egyeztetnie a saját csapatával és mérlegelni a saját, cég-specifikus előnyeit és hátrányait. A tapasztalatunk szerint nincs jó vagy rossz megoldás:

 - Egy ügyfelünknél egy orchestrator irányítja az összes robot kollégát 4 különböző országban – a költség és verzió irányítási előnyök nyertek más szempontokkal szemben.

 - Egy másik ügyfelünknél mindegyik RPA csapat megtartotta a saját orchestratorát – az agilitás és a gyorsaság nyomtak többet a mérlegen.

Általánosságban elmondhatjuk, hogy minél korábban hozzuk meg a döntést, annál jobb. Mi lesz a döntés a te esetedben? Egy vagy több?