למה רוב פרויקטי האוטומציה נכשלים? 3 סיבות מהשטח
70% מפרויקטי האוטומציה לא מספקים תוצאות. אחרי עשרות פרויקטים ראיתי 3 סיבות שחוזרות שוב ושוב — ואף אחת מהן לא טכנית.
למה רוב פרויקטי האוטומציה נכשלים? 3 סיבות מהשטח
70% מפרויקטי האוטומציה לא מספקים את התוצאות שהובטחו. הספקת תקציב, הספקת זמן — ובסוף אנשי הצוות עובדים בדיוק כמו קודם.
תשובה ישירה: רוב הפרויקטים לא נכשלים בגלל טכנולוגיה גרועה. הם נכשלים כי אוטמים את התהליך הלא נכון, מבלי שיש מישהו שאחראי על הצלחה, ומבלי שמודדים כלום אחרי ההשקה.
סיבה 1: אוטמים את התהליך הלא נכון — ומהר
הטעות הנפוצה ביותר: מישהו בהנהלה שמע על אוטומציה, זיהה תהליך שנראה "מסובך" — ומיד מזמינים פרויקט.
הבעיה? תהליכים שנראים מסובכים לרוב מסובכים מסיבה. לעתים קרובות הם מסובכים כי יש בהם שיקול דעת אנושי שחשוב, חריגים שמשתנים כל שבוע, או תלויות בין מחלקות שאיש לא מיפה.
אוטומציה של תהליך שבור לא תקן אותו — היא תשכפל את השבר בקצב גבוה יותר.
בלקוחות שלי, אני תמיד מתחיל עם שאלה אחת לפני כל דיון טכני: "האם התהליך הזה עובד טוב כשאדם עושה אותו?" אם התשובה היא לא — האוטומציה תחכה.
הפתרון: לפני שנוגעים בכלי, ממפים את התהליך עם מי שעושה אותו ביום-יום. לא עם המנהל — עם העובד. השלב הזה לוקח שבוע ומונע בזבוז של 80,000 ₪.
סיבה 2: אין בעלים — ויש יתומים
האוטומציה הותקנה. הספק סגר את הפרויקט. ואז...
הכלי מפסיק לעבוד כי ה-API של ספק חיצוני השתנה. אין מי שיודע לתקן. מחלקה אחת ממשיכה להשתמש, שתיים אחרות חזרו לאקסל. אחרי שנה, אף אחד לא זוכר למה האוטומציה הותקנה מלכתחילה.
בלקוחות שלי ראיתי את זה שוב ושוב: חברה משקיעה 120,000 ₪ בפרויקט, ואחרי 8 חודשים אף אחד לא משתמש בו. לא כי הוא לא עבד — כי אף אחד לא היה אחראי לוודא שהוא עובד.
אוטומציה היא לא מוצר שקונים פעם אחת. היא תשתית חיה שצריכה מישהו שאחראי עליה.
הפתרון: לפני ההשקה, מגדירים "בעלים" פנימי לכל אוטומציה. לא מחלקת IT בכללי — אדם ספציפי עם שם ומשמעת אחריות. הוא שמקבל התראה כשמשהו נשבר, הוא שמחליט על שינויים.
סיבה 3: לא מודדים — ולכן לא יודעים אם הצלחתם
שאלתי פעם מנהל שאמר לי שפרויקט האוטומציה שלו "עבד מצוין": "כמה שעות חסכתם בחודש?"
הוא לא ידע.
לא בגלל שהוא רשלן — אלא כי מראש לא הגדירו מה הצלחה נראית כמו. לא היה baseline של זמן לפני הפרויקט, לא היה מדד שעות לאחריו, ולא הייתה נקודת בדיקה.
כשאין מדידה, כל דבר נראה הצלחה — ולא ניתן ללמוד כלום לפרויקט הבא. גרוע מזה: קשה לקבל תקציב לפרויקט הבא כי אין מה להציג בפני ההנהלה.
הפתרון: לפני ההשקה, מגדירים 3 מדדים ברורים עם מספרים. לדוגמה: "כרגע עיבוד הזמנה לוקח 12 דקות לעובד. אחרי האוטומציה הוא אמור לקחת פחות מ-2 דקות. נבדוק אחרי 60 יום." זה הכל. בלי KPI מורכבים — מספר לפני, מספר אחרי, תאריך בדיקה.
דוגמה אמיתית: 90,000 ₪ שירדו לטמיון
לקוח בתחום הלוגיסטיקה פנה אלי אחרי שפרויקט אוטומציה קודם נכשל. הם שילמו 90,000 ₪ לאוטומציה של תהליך קליטת הזמנות.
כשנכנסתי לבדוק, גיליתי את שלוש הסיבות ביחד: התהליך המקורי היה שבור (20% מהזמנות דרשו טיפול ידני מיוחד שלא תועד), לא היה בעלים פנימי, ואחרי ההשקה אף אחד לא בדק אם הכלי עובד.
בנינו מחדש — הפעם נכון. שלושה חודשים, 40,000 ₪, ובסוף חיסכון של 3 משרות חלקיות. ההבדל לא היה בטכנולוגיה. היה בתהליך שבנינו סביבה.
אם קראת את זה ואתה מזהה אחת מהסיבות האלה בפרויקט שלך — עכשיו זה הזמן לעצור לפני שמשקיעים עוד.
רוצה לבדוק אם פרויקט האוטומציה שלך הולך בכיוון הנכון? קבע שיחת ייעוץ של 30 דקות — חינם, בלי התחייבות. נעבור ביחד על התהליך שאתה רוצה לאטמן ואגיד לך בישרה אם הוא מוכן.
צריכים עזרה ליישם את זה בעסק?
Alpha MF מתמחה באוטומציה, AI, ואינטגרציות. שיחת ייעוץ ראשונה — 30 דקות חינם.
דברו איתנו ←