איך לבנות POC לאוטומציה של אישורים בארגון

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

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

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

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

איזה תהליך אישור מתאים ל-POC?

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

כדאי לחפש תהליך שיש בו:

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

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

להתחיל ממפת החלטה, לא ממסך

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

מפת החלטה פשוטה יכולה לכלול:

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

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

מה לכלול ב-POC הראשון?

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

בשלב ראשון אפשר לכלול:

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

דברים שכדאי להשאיר להמשך:

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

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

איפה נכנסים SAP, BI ו-API פנימי?

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

אפשר לחלק את החיבורים לשלוש רמות:

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

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

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

איך לתכנן הרשאות ובקרה?

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

צריך להגדיר:

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

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

מה עושים עם חריגים?

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

ב-POC כדאי להגדיר מספר חריגים מראש, למשל:

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

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

האם צריך AI בתהליך אישורים?

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

אבל ב-POC ראשון לא כדאי לתת ל-AI סמכות מלאה לאשר או לעדכן מערכת ליבה. עדיף להשתמש בו כעוזר לתהליך:

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

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

איך למדוד הצלחה?

מדדי הצלחה ל-POC צריכים להיות פשוטים ומחוברים לתפעול. לא חייבים להתחיל ממדדים כספיים מורכבים.

אפשר למדוד:

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

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

דוגמה למבנה POC

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

POC ממוקד יכול להיראות כך:

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

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

איך Adaptico ניגשת לזה

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

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

שאלות נפוצות

האם כדאי להתחיל מאוטומציה מלאה של אישורים?

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

האם חייבים לבנות מסך עבודה?

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

מה עדיף: לחבר קודם ל-SAP או להתחיל בלי אינטגרציה?

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

איך יודעים שה-POC מוכן להרחבה?

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

סיכום

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

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