אוטומציה עסקית לעסק קטן: איך בוחרים תהליך ראשון

מתחילים מכאב מדיד, לא משם של כלי

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

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

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

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

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

מדרגים מועמדים באמצעות כרטיס ניקוד אחיד

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

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

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

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

מודדים את קו הבסיס לפני שמשנים את התהליך

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

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

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

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

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

מגדירים גבולות, אחריות וכללי פרטיות

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

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

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

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

מציירים את המסלול הרגיל ואת החריגים לפני החיבור

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

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

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

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

אירוע חדש
  -> אימות שדות
    -> חסר מידע: exception_queue + reason
    -> מידע תקין: בדיקת event_id
      -> כבר קיים: duplicate_ignored
      -> חדש: יצירת רשומה
        -> יצירת משימת מעקב
        -> שליחת אישור
        -> completed

בונים פיילוט קטן עם נתונים ידועים מראש

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

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

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

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

הופכים את תרחישי הפיילוט לבדיקות קבלה מחייבות

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

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

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

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

מעבירים אחריות לצוות באמצעות הדרכה קצרה ומעשית

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

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

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

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

משיקים בהדרגה ושומרים מסלול ידני לחזרה בטוחה

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

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

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

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

פותרים תקלות לפי המקום שבו התהליך נשבר

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

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

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

מתחזקים את התהליך עם בדיקה שבועית ואחריות ברורה

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

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

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

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

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

מחליטים אם להרחיב, לתקן או לעצור ובוחרים את הצעד הבא

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

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

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

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

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

אוטומציה עסקית: שלוש נקודות התחלה לפי הבעיה

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

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