למה AI לבדו לא יתקן תהליכים מיושנים
AI יכול להאיץ משימה בזמן שהלקוח עדיין ממתין. תובנות מהאירוע של Camunda בניו יורק, וגישה מעשית לתכנון מחדש של התהליך סביב התוצאה העסקית.
דמיינו שצוות רכש מוסיף AI לקריאת מסמכי ספקים. חילוץ הנתונים עובד, ההדגמה נראית טוב, ובדיקת כל מסמך מתקצרת. ובכל זאת, הספק מחכה ימים עד שהחשבון שלו פעיל. הבקשה ממתינה בתור לאישור, ומישהו עדיין צריך להעתיק את התוצאה למערכת אחרת.
זו דוגמה להמחשה, אבל היא מעלה שאלה שימושית לכל פרויקט AI: כמה מזמן ההמתנה של הלקוח נובע בכלל מהמשימה ששיפרנו?
בסיכום האירוע של Camunda בניו יורק, שפורסם ב־16 בספטמבר, מתואר מפגש שנערך ב־10 בספטמבר ועסק בתכנון תהליכים מחדש סביב AI. המשתתפים הדגישו ניהול שינוי, אחריות מפוצלת והצורך בתשתית פתוחה. המסקנה המעשית שלנו: לבחון את המסלול המלא מהבקשה ועד להשלמת הטיפול לפני שבוחרים היכן לשלב AI.
מה אפשר ללמוד מהמחקר
לפי מחקר שהוזמן על ידי Camunda, 72% ממקבלי ההחלטות שנשאלו דיווחו על כישלון יוזמות AI בשל בעיות בתהליכים. במקביל, 79% אמרו שהוספת AI לתהליכים קיימים מעוררת פחות התנגדות פנימית מתכנון מחדש. חברת Sapio Research סקרה 1,000 מקבלי החלטות ו־5,000 עובדים בארגונים המעסיקים לפחות 1,000 איש, בארצות הברית, בבריטניה, בגרמניה ובצרפת, ביולי–אוגוסט 2026.
אלה דיווחים עצמיים ממחקר בהזמנת ספק; אין פירושם ש־72% מכלל פרויקטי ה־AI נכשלים. עבור צוות פרויקט, זו סיבה לבדוק את מגבלות התהליך לצד ביצועי המודל.
לאתר את זמן ההמתנה לפני שמבצעים אוטומציה
נחזור לדוגמת הספק. נניח שבדיקת המסמכים מתקצרת מ־30 דקות לשלוש, אבל הבקשה עדיין ממתינה יומיים לאישור. המספרים האלה נועדו להמחשה: הצוות חסך 27 דקות עבודה, אך מקור העיכוב העיקרי נשאר במקומו.
עקבו אחר מדגם של בקשות אמיתיות מרגע ההגעה ועד להשלמת הטיפול. בכל בקשה, תעדו מתי העבודה מתחילה, מתי היא נעצרת, מדוע היא ממתינה ומי יכול לקדם אותה. כללו גם בקשות שהוחזרו לתיקון או ננטשו; בדיקה של מקרים שהושלמו בהצלחה בלבד עלולה להסתיר את העבודה הקשה ביותר.
לאחר מכן בחרו שינוי שמתאים לעיכוב. מידע חסר עשוי להצדיק טופס פתיחה ברור יותר. בדיקות חוזרות עשויות להצדיק רשומה משותפת. תור שאין לו אחראי מחייב החלטה על אחריות. ניתוח מסמכים באמצעות AI הופך למועמד מתאים יותר כשקריאת המסמכים והבנתם הן בעצמן מגבלה משמעותית.
המדריך שלנו לגילוי ומיפוי תהליכים מציע נקודת פתיחה לתיעוד המסלול הזה.
לתכנן את העברת הטיפול באותה קפדנות כמו את משימת ה־AI
בתהליך הספקים שבדוגמה, היינו מגדירים ארבעה דברים לפני הרחבת הפיילוט:
- מה ה־AI מפיק. לצד השדות שחולצו, יש לצרף הפניות לחומר המקורי ולסמן במפורש מידע חסר.
- מה מאפשר להתקדם לשלב הבא. יש להגדיר בתהליך את הבדיקות והאישורים הנדרשים. תשובה שנשמעת סבירה אינה מספיקה כשלעצמה כדי לאשר הפעלת ספק.
- מי מקבל מקרה חריג. יש לקבוע תור לבדיקה, תפקיד אחראי ומועד למענה. הבודק צריך לקבל את המסמכים המקוריים ואת הסיבה שבגללה נדרשת התערבות.
- איך מאשרים שהטיפול הושלם. התהליך מסתיים כשרשומת הספק נוצרה בהצלחה ומגיש הבקשה קיבל הודעה. המלצה שהמודל הפיק היא תוצאת ביניים.
בדקו מוקדם את המקרים המורכבים: מסמכים סותרים, מאשר שאינו זמין ומערכת שלא מחזירה תשובה בזמן לאחר שקיבלה עדכון. לפני ניסיון כתיבה חוזר, בררו אם הניסיון הראשון הצליח, כדי שההתאוששות לא תיצור רשומות כפולות.
להרחבה על סמכות ועל העברת מקרים לבדיקה, קראו על בקרה אנושית בתהליכי AI.
לאפשר גם את השינוי הבא
הדגש באירוע על תקנים פתוחים מציע כיוון שימושי לתכנון. בתהליך הספקים הזה, היינו משתמשים במודל BPMN כדי להציג במפורש את רצף הפעולות ואת מסלולי הטיפול בחריגים, ומגדירים בנפרד את מבנה הקלט והפלט של משימת ה־AI.
ההפרדה הזאת מאפשרת לבדוק שינוי מוגדר: להחליף את מודל ניתוח המסמכים תוך שמירה על דרישות האישור. לפני שמתחילים להשתמש במודל החלופי, בודקים אותו מול אותן דוגמאות, כולל שדות חסרים ומידע סותר.
צריך לתעד גם את מה שמחוץ לתרשים: אינטגרציות, הרשאות גישה, נתונים שמורים ואופן ההתאוששות מתקלות. מודל תהליך בתקן פתוח הוא רק חלק מהמעבר בין מערכות. כשבוחרים פלטפורמת תזמור כמו Camunda, כדאי להעריך גם את המאמץ שיידרש להעברת התלויות האלה.
להפוך את 90 הימים הבאים לניסוי שאפשר למדוד
הנה תוכנית מוצעת לתהליך אחד בהיקף מוגדר. לוח הזמנים הוא מסגרת לתכנון; הגישה למערכות ומורכבות התהליך יקבעו מה אפשר לבצע בפועל.
- ימים 1–30: לקבוע נקודת מוצא. בחרו אחראי לתהליך, בדקו מקרים אמיתיים עם מי שמבצע את העבודה, ומדדו זמן השלמה, זמן המתנה, עבודה חוזרת ומאמץ לכל מקרה שהושלם. בחרו צוואר בקבוק אחד לטיפול.
- ימים 31–60: לבנות ולבדוק את המסלול המעודכן. חברו את המערכות הנדרשות, הגדירו את משימת ה־AI ובדקו אישורים, תקלות והתאוששות. תנו לצוות התפעולי לבחון את העבודה שיקבל בפועל.
- ימים 61–90: להריץ פיילוט מוגבל. השוו מקרים דומים לנקודת המוצא. עקבו אחר החציון וגם אחר המקרים האיטיים, לצד שיעור התיקונים והעלות. הסכימו מראש אילו תוצאות מצדיקות הרחבה ואילו מחייבות סבב תכנון נוסף.
ב־NG Workshop אנחנו ממליצים להגיע לשיחה הראשונה עם תהליך אחד ברור: התוצאה הרצויה, כמה מקרים מייצגים והמקומות שבהם אנשים מתערבים כיום. כך אפשר לדון בהיקף עבודה שימושי ובדרך אמינה למדוד הצלחה.