הסברים בסיסיים על Roles ו-Authorization במערכת SAP:

​

הרבה מהיועצים הפונקציונליים נתקלים בסוגיות של אי הבנה לגבי מהם Roles ומהם Authorizations במערכת ה-SAP. מסמך זה יעזור לסקרנים מבינינו לדעת מהו בדיוק הקונספט שמושגים אלו מייצגים ואיך הם עובדים. ליועצים פוקנציונליים יש הרבה שאלות שעולות לגבי הקונספט הזה ואחת מהשאלות העיקריות פה היא מדוע יועצים פוקנציונליים צריכים לדאוג לגבי נושא ה-Roles וה-Authorization כאשר זהו התפקיד של צוות ה-BASIS?

חשוב להבין שלא מדובר רק על משימה שעל צוות ה-BASIS לבצע מקצה לקצה (כמו פעילויות אחרות), אלא זוהי פעילות משולבת שצריכים לבצע 2 הצוותים: צוות ה-BASIS והצוותים הפונקציונליים. לצוות ה-BASIS יש ידע לגבי הנושאים הבאים: User Management, Roles Creation, Profile Creation, Roles and Profile assignment, Authorization assignments ועוד.

אך הבעיה העיקרית ברוב המקרים עולה כאשר השאלות הבאות נותרות ללא מענה ע"י צוות ה-BASIS:

1. למי להקצות את ה-Roles או ה-Transactions?

2. מה עליהם להגביל ב-Transaction וכן עבור מי?

3. איך להגדיר את ההרשאות עבור Custom transactions?

שאלות אלו ועוד רבות אחרות לא ניתן למענה מצד צוות ה-BASIS. לכן, זהו תפקידו של היועץ הפונקציונלי להנחות אותם לגבי זרימת התהליך הספציפית ולגבי המבנה הארגוני הספציפי.

נסביר את מה שדיברנו עליו עם דוגמא קטנה, נניח שיש לנו צוות תחזוקה באופן הבא:

1. Supervisor - אחראי להנחות כלפי מטה או לגבי דרישות של תחזוקה מונעת.

2. Maintenance In-Charge - אחראי להקצאת המשימות לעיל למהנדסים.

3. ראש מחלקה - אחראי לאישור משימות התחזוקה.

כעת, היועץ הפונקציונלי מודע היטב לכך שה-Supervisor נדרש רק לטרנזקציות שקשורות להתראות (נניח: IW21, IW22, IW28, IW29), ה-Maintenance In-Charge נזקק רק לחלק מהטרנזקציות שקשורות להתראות (נניח: IW22, IW28, IW29) וכן לטרנזקציות אחרות שקשורות להזמנות (נניח: IW31, IW32, IW38, IW39), וכן בנוסף לאלו הוא נדרש להרשאות מיוחדות כגון: שחרור הזמנות, מתן היתרים, השלמות טכניות ועוד.

אם נסתכל מנקודת מבטם של צוות ה-BASIS, זה לא ברור להם מה הדרישות של המשתמש ולכן הם לא יכולים לקבל החלטות עקב זאת, אם דרישות המשתמש אמורים לספק היועצים הפונקציונליים. אך העניין המרכזי שעולה ברוב המקרים אצל היועצים הפונקציונליים שהם לא מבינים בקונספט שנקרא Roles and Authorizations.

​

מהו הקונספט של Roles And Authorization?

​

הקונספט של Roles and Authorization מאפשר למשתמשים לגשת ל-SAP Standard וכן ל-Custom Transactions בצורה מאובטחת.

SAP מספקת קבוצה מסוימת של Generic Standard roles עבור מגוון רחב של מודולים ומגוון תרחישים.

אנחנו יכולים גם להגדיר Roles מותאמים ע"י המשתמש בהתבסס על תרחישי הפרויקט כאשר אנחנו שמים לנגד עינינו את הקונספט הבא:

יש, ברמה הבסיסית, 2 סוגים של Roles:

1. Master Roles - עם טרנזקציות, אובייקטי הרשאה ועם כל ניהול הרמות הארגוניות.

2. Derived Roles - עם ניהול כל הרמות הארגוניות, הטרנזקציות ואובייקטי ההרשאה שמועתקים מה-Master Role.

הסיבה שעומדת מאחורי הקונספט שתואר לעיל היא על מנת לעשות את תהליך ניהול ה-Roles הרבה יותר פשוט.

​

מהם המרכיבים של Role?

​

בין אם מדובר על Master Role או אם מדובר על Derived Role, לשניהם יש את המרכיבים הבאים בתוכם:

1. קודים של טרנזקציות.

2. פרופיל

3. אובייקטי הרשאה

4. רמה ארגונית.

 

נסביר על כל אחד מהמרכיבים שתוארו לעיל:

​

1. קודים של טרנזקציות: קודים של טרזנקציות SAP (סטנדרטיות או: custom).

2. פרופיל: פרופילים הם למעשה האובייקטים ששומרים הלכה למעשה את נתוני ההרשאה, לעומת זאת Roles הם ה-Containers שמכילים את נתוני ה-profile authorization.

3. אובייקטי הרשאה: אובייקטים אלו מגדירים את היחסים בין שדות שונים וכן עוזרים בהגבלה/היתר של ערכים לשדות אלו (דוגמא לאובייקט הרשאה: I_VORG_ORD (פעולות עסקיות עבור הזמנות), מכיל יחס בין השדות: AUFART = סוג הזמנה וכן: BETRVORG טרנזקציה עסקית).

אובייקטי הרשאה למעשה מוגדרים בתוכניות שמורצות עבור כל טרזנקציות ספציפיות. אנחנו גם יכולים ליצור אובייקטי הרשאה מותאמים אישית עבור כל טרנזקציה ספציפית (בד"כ טרנזקציה מותאמת אישית).

רמה ארגונית: מגדיר את האלמנטים הארגוניים ב-SAP כגון: Company Code, Plant, Planning Plant, Purchase organization, Sales organization, Work Centers וכו'...

נניח שאנחנו מעוניינים לקחת כדוגמא את יצירת Role עבור: Maintenance In-charges בתעשיה ספציפית שאחראי על מפעלי תחזוקה שונים. נתבונן בתרחיש הבא:

Company = תהיה בשביל הדוגמא: C1, מפעלי תחזוקה יהיו: M1, M2, M3 וכן: M4 (לכן, נניח שיש 4 משמרות בפועל).

לכן, כמו שצייננו למעלה, ל-Maintenance In-charge יהיו את הזכויות לגשת לטרנזקציות הבאות - IW22, IW23, IW28, IW29, IW31, IW38 וכן: IW39 אך לא יהיו לא את ההרשאות לשחרר את הזמנת התחזוקה.

הסבר עם דוגמא:

לכן, בהתחשב בדוגמא לעיל, ניצור Master role שיתופי עבור כל ה-Maintenance In-charges נניח נקרא לו: ZMPM_MAIN_IN_CHARGE_ROLE (ניתן לראות ששם ה-Role מתחיל ב-Z) וכל הראשי תיבות שלו זה: ZMPM_MAIN_IN_CHARGE_ROLE

הפירוש של הקיצור זה Z Master Role for Plant Maintenance.

כעת, בהתבסס על ה-Master Role שהראינו, אנחנו צריכים ליצור Derived Roles עבור כל ה-4  בעלי התפקידים: Maintenance In-Charge. נניח אנחנו יוצרים אחד עבור הראשון, שמו יהיה: ZDPM_MAIN_IN_CHARGE_ROLE_M1 שמבצע ייחוס ל-Master Role שתיארנו למעלה שקוראים לו: ZMPM_MAIN_IN_CHARGE_ROLE

כעת זה יעתיק את כל הטרנזקציות ואובייקטי ההרשאה מה-Master Role אך אינו יעתיק את הרמה הארגונית שהקצננו ל-Master Role. זאת אומרת שאנחנו צריכים לתחזק את הרמה הארגונית עבור ה-Roles שיורשים