Oprávnění: Harmonizace organizační struktury

V předchozích textech jsme vysvětlili účel a princip fungování autorizačních polí organizační struktury a mechanismus odvozených rolí („derived roles“) jako jeden ze způsobů efektivní správy rolí pro harmonizované pracovní pozice. Připomeňme, že harmonizované pracovní pozice jsou takové, kdy role "Skladník v Hradci Králové" a "Skladník v Pardubicích" se funkčně neliší, pracují stejným způsobem se stejnými nástroji, a mají pouze vzájemně oddělená svá data. Tímto způsobem rozdělujeme proces tvorby a budoucí správy oprávnění na jednoznačně definované kroky procesu, které jednoznačně definují, jaké úpravy je potřeba provést ve které roli. Tím bráníme prodlením, improvizaci nebo nekoncepčním změnám. Harmonizace a standardizace je velmi silný nástroj. Proto se dnes budeme zabývat myšlenkou, jestli by nebylo vhodné a efektivní, harmonizovat také naše chápaní organizační struktury.

Motivace

Každá role obsahuje vlastní sadu organizačních oprávnění. Jinými slovy řečeno, 100 rolí znamená 100 vzájemně oddělených sad organizačních oprávnění. Když se nad tím ale zamyslíme, máme přeci pouze jednu organizaci, kterou všech těchto 100 rolí popisuje. A všechny role by měly tu jednu

organizaci popisovat stejným způsobem. Neměli bychom proto zvážit vytvořit jeden harmonizovaný

popis organizační struktury? Pak by vlastně oněch 100 dílčích rolí nebylo 100 samostatně zpracovaných sad, ale vlastně jen jedna sada (protože popisujeme jen jednu organizaci!), ze které

vždy použijeme pouze tu část, kterou má konkrétní role autorizovat.

Uvažme následující situaci:

Potřebujeme autorizovat role v organizaci, která má 4 pobočné závody: Ostrava, Jablonec, Písek a

Jihlava. Koncept oprávnění předpokládá 60 rolí z nichž 45 je potřeba připravit ve 4 verzích, jednu roli

pro každou pobočku s organizačním omezením na vlastní data.

Využijeme koncept odvozených oprávnění. 45 rolí pro harmonizované pracovní pozice vytvoříme tak,

že pro organizační pole použijeme hodnotu hvězdička. Těchto 45 rolí poté můžeme použít pro

manažerské pozice, nebo pracovníky podnikové centrály, kteří budou potřebovat přístup ke všem

datům. Dále vytvoříme 4 x 45 odvozených rolí pro jednotlivé pobočky s omezeným organizačním

přístupem. Celkově tedy budeme udržovat 180 oddělených sad organizačních oprávnění. Jmenná

konvence bude reflektovat organizační příslušnost tím, že všechny role budou mít na konci jména

postfix _OVA, _JBL, _PSK a _JHL pro označení příslušné organizační jednotky.

Pro úplnost zmiňme, že standardně má systém SAP ERP 34 polí organizačního přístupu. Náš koncept

oprávnění bude pracovat s 12 z nich.

Vytvoříme dokument (například) ve formátu Microsoft Excel, který popíše pro naše 4 organizační

jednotky jednotlivé kombinace organizačních hodnot. Pro každou jednotku budeme mít minimálně 12

hodnot (pro 12 polí). Ze zkušeností ale plyne, že pro část polí těch hodnot bude více než jen jedna,

takže reálný odhad je například 18 hodnot pro 12 polí pro 4 organizační jednotky.

Jistě si teď říkáte, co je na tom za inovativní myšlenku. Vždyť zkušený administrátor zná svoji

organizaci dostatečně dobře na to, aby organizační oprávnění přiděloval z hlavy a víceméně

konzistentně ve všech 180 rolích. Ne vždy je ale organizace v situaci, že oprávnění konzistentně

spravuje jeden zkušený administrátor. V následujících příkladech se pokusím navrhnout několik

výhod, které by navržená harmonizace přinesla.

Výhody

(1) Organizační struktura bývá velmi stabilní, dříve nebo později se ale změní. Například přibude

nové skladové umístění pro Ostravu. Změnový požadavek pravděpodobně přijde od

uživatelů pro jednu roli (první z mnoha), protože nebudou moci pro nové skladové umístění

pracovat s daty. Můžeme očekávat, že v dalších dnech přijde stejný požadavek pro další role.

Místo toho, abychom čekali na dalšího uživatele, který nebude moci pracovat, protože mu

chybí nové organizační oprávnění, proaktivně aktualizujeme všechny relevantní role.

Budeme postupovat následovně:

a. Do dokumentu organizační struktury si pro Ostravu přidáme novou hodnotu pro

skladové umístění.

b. Vyhledáme v seznamu rolí všechny role pro Ostravu (transakce SE11, tabulka

AGR_DEFINE). Nebo ještě lépe vyhledáme všechny role pro Ostravu, které používají

organizační pole „skladové umístění“ (transakce SE11, tabulka AGR_1252,

AGR_NAME=*_OVA, VARBL=$LGORT). Všechny tyhle role vyžadují aktualizaci, jednu

po druhé tedy v PFCG aktualizujeme.

Tímto způsobem samozřejmě můžeme pracovat i bez zvláštního dokumentu popisujícího

organizační strukturu. Jde vlastně jen o změnu přístupu, kdy nepohlížíme na role jako na

oddělené jednotky, ale jako části celku, který musí být vždycky důsledně a důkladně

aktualizován celý.

(2) Organizační strukturu máme nyní explicitně popsánu v souboru, který lze snadno sdílet

s kolegy. IT kolegové mohou takový soubor sdílet s kolegy v operativě. Všichni budou

používat stejná a správná data i přesto, že například nebyli explicitně informování o nové

organizační změně. Soubor lze také v pravidelných intervalech kontrolovat tak, aby

neobsahoval zastaralé nebo chybné informace. Standardní nástroje SAP nenabízejí jeden

ucelený nástroj pro přehled nad organizační strukturou.

(3) Pro všechny existuje jeden ucelený popis organizace, nic není třeba hledat nebo doplňovat.

Jestliže si například někdo nepamatuje všechny kombinace hodnot “nákupní organizace”

($EKORG) a „zúčtovacího okruhu“ ($BUKRS), místo toho, aby to pokaždé znova hledal, bude

vlastně jen opisovat předpřipravené, zkontrolované a schválené sady organizačních dat.

(4) Když budeme později potřebovat definovat novou roli a odvodit její varianty pro jednotlivé

organizační jednotky, vytvoříme v transakci PFCG jednotlivé odvozené role a hodnoty

organizačních polí prostě jen opíšeme ze souboru. Přibližně jedna minuta práce na jednu roli.

I zkušený administrátor by potřeboval delší čas vydolovat všechny kombinace z paměti.

(5) ...a nakonec si představte opravdu složitou organizaci. Podstatně větší, než je Ostrava,

Jablonec, Písek a Jihlava. Co když je poboček například 30? Náročnost administrace se

radikálně zvyšuje a pamatovat si všechny kombinace je řádově obtížnější. Co když těch 30

poboček má například 3 oblastní vedení? Pro role na úrovni oblastního vedení potřebujeme,

aby měli k dispozici přístupy do všech částí organizace, kterou řídí. Nebo si představme

mezinárodní organizaci, kde může být organizačních úrovní ještě více – například: centrála

organizace (přístup všude), centrála země (přístup do poboček dané země), jednotlivé

fyzické pobočky.

Tip: Zkušený administrátor by mohl nyní namítnout, že stejně musíme vytvořit role omezené

na jednotlivé fyzické pobočky, takže přístup do více poboček najednou lze snadno vyřešit

přidělením všech potřebných individuálních pobočkových rolí uživateli. Naneštěstí je počet

možných přiřazení rolí uživateli shora omezen. A i pokud se pohybujeme pod tímto

technickým limitem, je úprava seznamu rolí uživatele o několika stovkách položek krajně

nepříjemná. Definovat proto zvláštní organizační jednotky pro jednotlivé úrovně řízení a pro ně odvozené role proto může být mnohem méně bolestivé. Vhodné jmenné konvence

v definicích organizačních objektů mohou dále pomoci.

Nevýhody

(1) Hlavní nevýhodou tohoto přístupu je úsilí, které musíme vložit do popisu organizace pomocí

hodnot organizačních oprávnění. Jakým způsobem můžeme tento úkol efektivně řešit si

povíme v separátním příspěvku.

(2) Zdánlivou nevýhodou se může zdát, že každá jednotlivá role bude potřebovat mírně odlišnou

sadu organizačních oprávnění. Například organizační pole $FIKRS ovlivňuje finanční aplikace,

zatímco pole $PERSA ovlivňuje aplikace řízení lidských zdrojů. Proto role pro lidské zdroje pravděpodobně vůbec nebude znát (a tedy potřebovat) hodnoty pro pole $FIKRS. Nevýhoda je však to pouze zdánlivá. Jestliže budeme mít organizaci popsánu například pomocí 12 různých polí (jak jsme si stanovili v příkladu výše) a role pro lidské zdroje, kterou budeme aktuálně upravovat jich bude potřebovat pouze 6, jednoduše zbylých 6 z naší připravené organizační struktury nepoužijeme. Některé hodnoty přeskočit je snadné. Chybějící hodnoty dohledávat je mnohem zdlouhavější práce.