מתי אוטומציה לא משתלמת - חמישה מקרים שבהם עדיף להישאר ידני

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

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

1. נפח נמוך מדי

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

שש פעמים חצי שעה זה שלוש שעות בחודש. בעלות שעה אמיתית של כ-104 שקל, זה כ-312 שקל בחודש, או כ-3,700 שקל בשנה. פרויקט אוטומציה של 15,000 שקל יחזיר את עצמו בארבע שנים - ורוב התהליכים לא שורדים ארבע שנים בלי לשנות צורה.

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

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

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

2. התהליך עדיין משתנה

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

סימני זיהוי:

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

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

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

3. הנתונים לא אמינים

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

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

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

4. ההחלטה דורשת שיפוט אמיתי

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

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

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

5. המערכת סגורה

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

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

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

מבחן מהיר לפני שמזמינים הצעת מחיר

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

מקרה שישי, גבולי: אין מי שיחזיק את זה

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

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

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

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

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

הדבר שכן שווה תמיד

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

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

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