איך לתכנן ownership לתהליך אוטומטי שחוצה צוותים ומערכות

קטגוריה: AI & אוטומציה | תאריך: אוגוסט 2026

תהליך אוטומטי בארגון כמעט אף פעם לא שייך רק לצוות אחד. הוא יכול להתחיל בבקשה עסקית, לקרוא נתונים מ-SAP, להציג סטטוס ב-BI, לשלוח התראה לצוות תפעול, לפתוח משימה לצוות כספים, ולעדכן מערכת פנימית בסוף הדרך.

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

בלי ownership ברור, אוטומציה יכולה להפוך מהר מתהליך שמקצר עבודה לתהליך שאף אחד לא מרגיש בעלות עליו. המשתמשים רואים סטטוס לא ברור, צוות ה-IT מקבל תקלות בלי הקשר עסקי, והצוות העסקי לא יודע אם לחכות, לטפל ידנית או לעצור את התהליך.

לכן תכנון ownership הוא לא עניין ארגוני צדדי. הוא חלק מהארכיטקטורה של אוטומציה, אינטגרציה ו-AI בארגון.

למה ownership חשוב לפני שמרחיבים אוטומציה?

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

הבעיות מתחילות כאשר:

• התהליך נכשל אבל לא ברור מי אמור לטפל.
• משתמש עסקי לא יודע אם הסטטוס תקין או תקוע.
• צוות טכני רואה שגיאה אבל לא יודע מה המשמעות העסקית שלה.
• שינוי קטן במערכת אחת שובר תהליך במערכת אחרת.
• אין בעלים שמחליט האם חריג מסוים צריך כלל אוטומטי, טיפול ידני או חסימה.
• אף אחד לא יודע מי רשאי לאשר עדכון למערכת ליבה.

אוטומציה טובה לא רק מבצעת פעולה. היא מגדירה מי אחראי על כל שלב, מי מקבל החלטה, ומי מטפל כאשר התהליך יוצא מהמסלול הרגיל.

להפריד בין בעלים עסקי לבעלים טכני

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

בתהליך אוטומטי צריך לפחות שני סוגי ownership:

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

לדוגמה, בתהליך שמעדכן נתון ב-SAP אחרי אישור עסקי, הצוות הטכני יכול להיות אחראי על API, לוגים והרשאות. אבל ההחלטה אילו חריגים מותר לאשר, מה עושים כשחסר שדה, ומתי עוצרים את התהליך צריכה להיות אצל בעלים עסקי.

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

למפות ownership לפי סטטוס, לא רק לפי מערכת

תהליך שחוצה מערכות לא צריך ownership לפי "מי מחזיק את SAP" או "מי אחראי על הדוח". הוא צריך ownership לפי מצב התהליך.

כדאי למפות את הסטטוסים המרכזיים ולשאול לגבי כל אחד:

• מי רואה את הסטטוס?
• מי אחראי לפעולה הבאה?
• האם נדרש טיפול אנושי?
• האם מותר למערכת לנסות שוב אוטומטית?
• מתי צריך להסלים לבעלים עסקי?
• איזה לוג או הסבר צריך להישמר?

לדוגמה:

• "נקלט" יכול להיות באחריות המערכת.
• "חסר נתון חובה" יכול לעבור לצוות תפעול.
• "ממתין לאישור" שייך לבעלים עסקי או מאשר מוגדר.
• "כשל עדכון" שייך לבעלים טכני, אבל עם השפעה עסקית ברורה.
• "נדרש טיפול חריג" צריך בעלים עסקי שמחליט מה עושים.

מיפוי כזה מונע מצב שבו חריגים נופלים בין צוותים כי כל אחד רואה רק חלק מהתמונה.

להגדיר אחריות לחריגים כבר ב-POC

POC לא צריך לפתור את כל החריגים האפשריים. אבל הוא כן צריך להראות איך הארגון יתמודד עם חריגים.

כדאי לבחור כמה תרחישים מייצגים:

1. נתון חסר או לא תקין.
2. הרשאה חסרה לקריאה או עדכון.
3. מערכת יעד לא זמינה.
4. החלטה עסקית שאינה חד משמעית.
5. כפילות או סתירה בין מערכות.

לכל תרחיש צריך להגדיר בעלים ופעולת טיפול. האם המערכת עוצרת? האם היא פותחת משימה? האם היא שולחת התראה? האם היא מציגה את המקרה במסך חריגים? האם מותר לבצע retry?

הנקודה אינה לבנות מנגנון מסובך. הנקודה היא להראות שהאוטומציה לא מתעלמת מהמציאות התפעולית של הארגון.

מה צריך להופיע בלוג כדי לתמוך ב-ownership?

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

לוג שימושי לתהליך עסקי צריך לכלול יותר משגיאות טכניות. הוא צריך לענות על שאלות תפעוליות:

• מי או מה התחיל את התהליך?
• איזה סטטוס התקבל בכל שלב?
• אילו מערכות נקראו או עודכנו?
• האם הפעולה היתה אוטומטית, המלצה או אישור אנושי?
• מי אישר פעולה רגישה?
• מה היתה סיבת הכשל או החריג?
• מי קיבל אחריות לטיפול הבא?

כאשר הלוג בנוי סביב התהליך ולא רק סביב הקוד, גם הצוות העסקי וגם הצוות הטכני יכולים לדבר על אותה מציאות.

איפה AI משנה את מודל האחריות?

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

גישה מעשית היא להפריד בין שלושה סוגי פעולות:

• קריאה: AI מסייע להבין מידע ממסמך, דוח או מערכת.
• המלצה: AI מציע פעולה, סיווג או תשובה.
• ביצוע: פעולה שמשנה סטטוס, פותחת משימה או מעדכנת מערכת.

בדרך כלל, ככל שהפעולה קרובה יותר לעדכון מערכת ליבה או החלטה עסקית רגישה, כך צריך ownership ברור יותר ואישור אנושי מוגדר יותר.

כך אפשר להשתמש ב-AI כדי לקצר עבודה בלי לטשטש אחריות.

איך להתחיל בפועל?

לפני שמרחיבים אוטומציה קיימת או בונים תהליך חדש, כדאי לבצע מיפוי קצר:

1. לבחור תהליך אחד שחוצה לפחות שתי מערכות או שני צוותים.
2. לרשום את הסטטוסים המרכזיים שלו.
3. לסמן מי אחראי לפעולה הבאה בכל סטטוס.
4. להפריד בין בעלים עסקי, בעלים טכני ומטפל יומיומי.
5. להגדיר שלושה חריגים נפוצים ומה עושים בכל אחד.
6. להחליט אילו פעולות דורשות אישור אנושי.
7. להגדיר אילו לוגים חייבים להישמר.

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

סיכום

אוטומציה שחוצה צוותים ומערכות צריכה יותר מחיבור טכני. היא צריכה ownership ברור: מי אחראי לתהליך, מי מטפל בחריגים, מי מאשר פעולה רגישה, ומי יודע להסביר מה קרה כאשר יש תקלה.

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