Více entit v rámci jedné licence

Pokud má vaše firma více právních nebo a/nebo geografických entit (např. jste skupina, která sdružuje několik dceřiných společností, nebo jste jedna firma, ale máte pobočky v různých zemích, které pracují nezávisle), budete řešit otázku, zda mít jen jednu licenci nebo více. V tomto článku se dozvíte důležité informace pro vaše rozhodování mezi těmito variantami. 

Varianta s jednou licencí je na začátku většinou lákavější, protože pochopitelně znamená úsporu nákladů v porovnání s více licencemi. Přestože lze v ATS Recruitis pracovat s více entitami v rámci jednoho účtu není to tak, že na jednom účtu lze vytvořit více separátních podentit s vlastním IČO, GDPR pravidly apod. a tak je potřeba zvážit všechny dopady každé z variant a konkrétní preference ve vaší firmě v náborovém procesu. 

V následujícím přehledu se dozvíte, jak jednotlivé varianty fungují a jaké jsou jejich plusy a minusy.

Varianta s jednou licencí 

Kdy o této variantě uvažovat?

Tato varianta je možná, pokud chcete a můžete sdílet jednotný talentpool s jedněmi GDPR pravidly a také pokud můžete komunikovat v rámci firmy jedním jazykem s identickou sadou procesů, štítků apod.

Plusy:

• Nižší cena (platíte jen 1 licenci) 
• Možnost mít jediného administrátora pro všechny entity a zaručit konzistentní práci napříč entitami (flow náboru, emailové šablony apod.)
• Reporting z jednoho místa s možností oddělit data pro jednotlivé entity

Minusy:

• Nelze mít rozdílná GDPR pravidla pro každou z entit
• Pokud potřebujete používat více jazyků budete mít řadu prvků v systému multiplikovanou jen kvůli jazyku (flow náboru, štítky, filtrační položky, důvody zamítnutí, odpovědní formuláře atd.)
• Pokud každá entita používá jiné publikační kanály, budou všechny k dispozici všem

Typické příklady firem, které toto využívají:

• Firma je skupina menších českých startupů, , kde chtějí zavést a vynutit standardizovat procesy a mají jen jedno místo, odkud řídí HR procesy. 
• Firma má pobočku v Česku a na Slovensku a sdílejí jednotné procesy.
• Firma má pobočku v několika zemích v Evropě s centrálním HR a vše komunikují v angličtině.

💡 Zda více entit může mít stejná GDPR pravidla a zda můžete sdílet talentpool musí potvrdit váš DPO nebo obecně osoba, která má u vás ve firmě na starosti otázku GDPR

 

Varianta s více licencemi

Kdy o této variantě uvažovat?

Tato varianta je jedinou možností, pokud mají jednotlivé entity různá GDPR pravidla a pokud nemohou nebo nechtějí sdílet společný talentpool. V této variantě má tedy každá entita svoji vlastní licenci, kde si sami definují vše přesně podle svých individuálních potřeb - ať už jazykových, procesních nebo legislativních.

Plusy:

• Každá entita si může vše nastavit přesně podle svých potřeb a zvyklostí (GDPR, procesy, publikační kanály apod.)
• Každá entita vidí jen svůj obsah
• Není třeba zavádět “umělé” rozlišovače pro různé položky v systému (štítky, důvody zamítnutí)

Minusy:

• Vyšší cena

💡 Pokud i ve variantě s více licencemi chcete mít pouze jediného administrátora, lze to udělat tak, že jeden uživatel s rolí administrátora bude mít účet ve všech entitách a bude se mezi nimi jen přepínat - viz tento článek.

Typické příklady firem, které toto využívají:

• Firma je skupina firem získaných akvizicemi, které mají vlastní autonomní pravidla a procesy.
• Firma má pobočky v 5 zemích po Evropě, kde se v každé z nich mluví odlišným jazykem a není možné vynutit jeden společný jazyk.

 

Praktický příklad nastavení více entit pod jednou licencí

Jste firma, která vznikla sloučením dvou původně konkurenčních firem "Autodoprava Novák" a "Spedition Procházka" a chcete pracovat nad společným talentpoolem kandidátů s jednotným procesem.

V rámci nastavení narazíte především na tyto otázky:

Jak oddělit pobočky?

V rámci editace poboček (odkaz) máte v editaci možnost ke každé pobočce doplnit údaje včetně jejího názvu, kde můžete uvést jméno dané entity (tedy v našem případě, jestli jde o firmu "Autodoprava Novák" nebo "Spedition Procházka").

Při přiřazování poboček k jednotlivým pozicím v rámci editace pozice, tak pobočky jednotlivých firem snadno rozlišíte. 

Jak oddělit pozice?

Pro oddělení pozic nemusíte používat nějaké specifické názvy nebo kódy v názvech pozic, pro tento účel slouží v ATS tzv. "Filtrační položky" (odkaz na nastavení), kterými můžete pozice pro jednotlivé entity oddělit. 

Více o využití a fungování filtračních položek se dozvíte v tomto článku: Praktické využití filtračních položek.

Tedy v našem příkladu si například vytvoříte kategorii "Firma" a v ní položky "Autodoprava Novák" nebo "Spedition Procházka". V nastavení pozic pak každé pozici přiřadíte příslušnou firmu. 

Filtrační položky mají i svůj význam také pro filtrování pozic pro kariérní web a dat pro analytiku.

 

Jak nastavit role a práva?

Toto záleží hodně na tom, jak moc nebo málo chcete mezi jednotlivými firmami spolupracovat. 

Scénář 1 - "Centrální HR a oddělené firmy"

• Vytvoříte si za celou skupinu jednoho uživatele s rolí "Administrátor" (ten jediný může nastavovat firemní nastavení a vidí celý a kompletní talentpool.
• Pro recruitéry z jednotlivých firem si vytvoříte uživatele s rolí "Personalista" (tedy mohou vidět pouze své pozice, které si založili a kandidáty na nich)
• Pokud je třeba, aby někdo z jednotlivých firem viděl celý talentpool, vytvoříte ho s rolí "Hlavní personalista" (tedy vidí všechny pozice a všechny kandidáty, ale nemůže měnit nastavení firmy jako administrátor)

Scénář 2 - "Jednotlivé firmy jsou rovnocenné"

• Z každé firmy vyberete jednoho administrátora tak, aby si v každé firmě mohli nastavovat položky z firemního nastavení (flow náboru, filtrační položky, důvody zamítnutí atd.)
• Recruitéři budou mít primárně roli "Hlavní personalista" a uvidí tak celý talentpool a všechny pozice

Jak ošetřit logo v emailech?

Emailové zprávy mohou obecně mít jen jedno logo (každá licence umožňuje použít jen jedno firemní logo), ale v rámci emailových šablon můžete použít "trik", který při vypnutí firemního loga (nebo při použití loga skupiny) umožní v těle emailu použít logo konkrétní firmy. V tomto článku naleznete popis takového řešení. 

Jak zařídit napojení na více kariérních webů?

Toto lze zařídit pomocí filtračních položek, jak bylo popsáno výše v bodě o oddělení pozic. 

V rámci načítání pozic přes API na jednotlivé kariérní weby pak stačí v GET volání výpisu pozic použít j filtraci pomocí filter_id[], kde zadáte pro každou firmu ID její filtrační položky. 

Konkrétní detaily se správci vašich kariérních stránek mohou dozvědět v naší API dokumentaci pro volání výpisu pozic.

Jak oddělit data v analytice?

Zde jsou odpovědí opět filtrační položky, které jsou součástí filtrace dat napříč jednotlivými metrikami a reporty. Zde je důležité vědět, že přestože filtrační položky se vztahují primárně k pozicím, kandidáti z těchto pozic je "dědí". Neboli, pokud v našem případě mám jednu pozici s filtrační položkou "Autodoprava Novák" a na ni 2 kandidáty, tak pak pokud v reportu kandidátů dam filtrovat podle filtrační položky "Autodoprava Novák" ukáží se mi právě tito dva kandidáti.

 

💡 Praktický příklad - Přidání druhé entity pod jednu licenci 

ituace, kdy pod jednou licencí v rámci ATS Recruitis chcete mít více entit nemusí vzniknout hned na začátku spolupráce, ale může k ní dojít až ve chvíli, kdy už třeba jedna licence pro jednu entitu nějaký čas běží.

V takovém případě, pokud se rozhodnete pro jednu licenci, budete řešit situaci, kdy jedna entita má už vše nastavené podle sebe a ta druhá bude do toho vstupovat a bude nutné provádět určité úpravy i u stávající entity.

Níže uvádíme příklad check-listu, kterým byste si měli projít a jednotlivá klíčová nastavení a položky systému, které je třeba promyslet, jak zapracovat. Pro snadnější orientaci uvádíme příklad, kdy máte existující českou entitu “CZ” a chcete do její licence přidat slovenskou entitu “SK” (jazyková rozdílnost rozhodování jasně definuje).

🔘 Ověření shody GDPR

• Zde nejde tolik o to, zda textace GDPR souhlasu je identická, ale o to, na kolik let je souhlas udělen.
• V rámci jedné licence nelze mít více pravidel GDPR, tedy ani více délek maximální doby souhlasu.

🔘 Přidání zaměstnanců SK pobočky

• Na úvod stačí přidat jednoho kolegu z SK pobočky s právy administrátora a ten pak může přidávat další uživatele z SK pobočky.
• Pro výběr administrátora je také důležité zda může pomoci s nastavením položek, které budou čistě pro SK pobočku.
• Důležitá bude také diskuse a vzájemná spolupráce při volbě, zda dané položky nastavení nechat jen jedny, nebo dělat dvě sady (více se dozvíte v popisu jednotlivých položek níže).

🔘 Nastavení filtrační položky jasně definující pozice entity CZ a entity SK

• Protože talentpool budete mít společný, je pro orientaci v pozicích. kandidátech dobré mít jednu klíčovou filtrační položku, která vám data jasně rozdělí
• Takže si např. vytvoříte kategorii “Pobočka” s hodnotami “CZ a “SK”, kterou dáte jako povinnou, aby při vytvoření pozice bylo nutné ji nastavit.
• Zvažte také, zda je možné, aby některé pozice byla společná po obě entity, nebo zda lze vždy vybrat jen jednu možnost (podle toho nastavte volbu u dané kategorie filtračních položek “Je možné vybrat více položek”.
• U CZ pozic si ji zpětně nastavte u všech a u “SK” pozice se bude doplňovat postupně při vzniku každé pozice.
• Tuto filtrační polžku můžete využít nejen v rámci ATS Recruitis pro filtrování pozic v UI, ale také např. přes API pro filtraci pozic na jednotlivé kariérní stránky entit nebo filtraci na společných kariérních stránkách.

🔘 Pobočky

• Pobočku (nebo i více poboček, pokud jich má SK entita více) může také nastavit rovnou administrátor SK entity
• U poboček je důležité, aby kromě adresy obsahovali také název pobočky.
  • Ten se pak propisuje jako název firmy např. u pozvánek na pohovor apod.
  • Tedy, pokud se slovenská pobočka jmenuje např. “Recruits.io, s.r.o. Slovakia” a česká  “Recruits.io, s.r.o. Česko”, chcete, aby chodily názvy poboček podle lokality správně a nemátly k
  • Flow náboru
  • Toto je jedna z položek, kde je na zvážení, zda nechat jedno společné, nebo přidat speciální pro SK entitu
  • Ve většině případů ale patrně zvítězí varianta mít pro SK vlastní flow
  • Kromě jednoduchosti (že není třeba mít názvy stavů dvojjazyčně nebo vymýšlet pracně univerzální názvy nebo zkratky) je to pak praktické i třeba z pohledu analytiky, kdy se vám přes filtraci flow oddělí data od sebe.
  • Je také pravděpodobné, že každá entita bude mít více než 1 flow.
  • andidáta.

🔘 Nastavení odpovědních formulářů 

• Odpovědní formuláře budou sloužit pro komunikaci směrem ke kandidátům a proto je potřeba je nastavit speciálně pro SK pobočku ve slovenštině.
• Důležitou součástí je také vytvoření slovenských GDPR souhlasů, které se pak do formuláře přidají.
  • Text GDPR souhlasů není jen o překladu do jiného jazyka, ale je možné, že se v jiné zemi může mírně lišit implementace GDPR nebo i implementace GDPR v rámci dané pobočky.
  • Pokud jsou pobočky také jiné právní entity, např. v ráci skupiny firem, mělo by podle dikce GDPR být také rozlišeno, pro kterou entitu dávám souhlast a tedy, pokud mám entity 2, měly by ve formuláři pro CZ být 2 GDPR souhlasy - jeden pro CZ a druhý pro SK.
• Zde je odkaz na článek s praktickou ukázkou nastavení zahraniční pozce včetně formuláře a GDPR souhlasů

🔘 Emailové šablony

• Šablony emailů jsou opět něco, co pro SK entitu budete muset nastavit tak jako tak.
• V případě, že jako dvě entity máte jednotné logo, stačí použít to, které systém nabízí v hlavičce emailu, pokud se loga liší, je třeba to hlavní zrušit a loga s vkládat do emailových šablon jako obrázek (např. pod podpis)
• Nezapomeňte ani na systémové zprávy typu “Automatická odpověď”, které musíte mít ve slovenštině pro slovenské inzeráty

🔘 Flow náboru

• Toto je jedna z položek, kde je na zvážení, zda nechat jedno společné, nebo přidat speciální pro SK entitu.
• Ve většině případů ale patrně zvítězí varianta mít pro SK vlastní flow.
  • Kromě jednoduchosti (že není třeba mít názvy stavů dvojjazyčně nebo vymýšlet pracně univerzální názvy nebo zkratky) je to pak praktické i třeba z pohledu analytiky, kdy se vám přes filtraci flow oddělí data od sebe.
  • Je také pravděpodobné, že každá entita bude mít více než 1 flow a jiný počet (např. podle typu pozic, které obsazují, rozdílné práci z hiring manažery, apod.)

🔘 Důvody zamítnutí 

• Důvody zamítnutí jsou jediná položka, kterou nelze nějak rozčlenit do kategorií (jako např. štítky nebo filtrační položky) a tak musíte mít vždy jen jednu sadu.
• Šlo by pochopitelně jednotlivé položky duplikovat podle jazyka, ale to by mohlo mít negativní dopad na UI (musel bych dlouho scrollovat, než bych našel důvod na konci seznamu) a také pro statistiku (ten samý důvod by existoval 2x).
• Firmy toto často řeší tak, že zvolí jeden společný jazyk (např. EN, nebo si položky nazvou dvojjazyčně (např.  “Nedostatečné vzdělání / Nedostatočné vzdelanie”).

🔘 Štítky

• Štíky nabízejí volbu, kdy si můžete vytvořit pro všechny, nebo jen pro některé, vlastní kategorii např. “Skills - CZ” a “Skills - SK” a tam mí své položky a používat je pro své pozice a kandidáty.
• Ale i zde asi bude praktičtější mít jednu sadu a tu rozšiřovat tak, kde něco  z SK entity chybí, protože se tím nevytvoří duplicita pro reporting nebo hledání v talentpoolu  (i když toto samozřejmě záleží na tom, jak mezi dvěma entitami funguje spolupráce a sdílení v rámci talentpoolu a může být naopak žádoucí oddělení dodržovat). 

🔘 Filtrační položky

• Kromě filtrační položky zmíněné výše, která řídí příslušnost pozice k entitě můžete mít. a pravděpodobně také budete mít, další kategorie.
• Filtrační položky mají stejnou logiku a strukturu jako štítky - tedy sdružují se do kategorií a těch si můžete udělat neomezené množství, některé společné, některé individuální pro každou pobočku
• Podobně jako u štítků i zde je na zvážení, jak moc chcete mít pool pozic propojený nebo oddělený a zda je lepší filtrační položky striktně oddělovat a duplikovat nebo naopak spojovat. 

🔘 Šablony pracovních nabídek

• Pokud používáte offer management v rámci ATS Recruitis budete také potřebovat vytvořit šablony pracovních nabídek v jazyce SK entity, s jejich popisem, benefity atd.

🔘 Publikační kanály

• Je pravděpodobné, že SK entita bude mít jiné publikační kanály než CZ entita.
• Nastavení kanálů je nezávislé a může jich být kolik chce, klidně i duplicitně, pokud např. některý pracovní portál používají obě entity každá pod svým účtem a chtějí to tak zachovat.

🔘 Import kandidátů 

• SK entita si do ATS Recruitis pochopitelně bude chtít také převést své existující kandidáty ze svého současného systému.
• V situaci, kdy se tito kandidát dohrávají do rozběhnuté CZ instance je při importu důležité pohlídat si, aby tito kandidáti byli jasně označení zdrojem (např. “Import SK”) nebo štítkem (pokud má každý kandidát u sebe také svůj původní zdroj).