פילוט אוטומציה: איך מריצים ניסוי שאפשר לסמוך על התוצאה שלו

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

מה בוחרים לפילוט

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

שלוש דרכים סבירות לתחום:

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

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

מה מודדים, ומתי

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

כמה זמן מריצים

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

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

הטעות שהופכת פילוט לחסר ערך

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

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

מה לרשום במהלך הפילוט

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

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

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

קריטריון ההחלטה, מראש

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

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

מה עושים כשהפילוט נכשל?

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

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

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

מי צריך לדעת שרץ פילוט

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

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

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

איך מרחיבים אחרי פילוט מוצלח

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

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

מקורות

• אוטומציה לעסקים קטנים בישראל
• Make - טיפול בשגיאות בתרחישים