Make, n8n או Zapier: איך לבחור לפי פיילוט זהה ולא לפי רשימת פיצ'רים

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

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

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

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

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

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

מגדירים את הפיילוט הזהה ואת גבולות האחריות שלו

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

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

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

{
  "event_id": "lead_20260908_001",
  "submitted_at": "2026-09-08T09:30:00Z",
  "name": "דנה כהן",
  "company": "גליל פתרונות",
  "email": "DANA@EXAMPLE.CO.IL",
  "phone": "050 123 4567",
  "topic": "אוטומציית שירות",
  "urgency": "high",
  "consent_to_contact": true
}

כותבים חוזה קבלה לפני שפותחים את כלי הבנייה

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

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

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

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

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

מממשים את אותו פיילוט ב-Make ומודדים פעולות וזרימת bundles

ב-Make בנו Scenario שמתחיל ב-webhook, מנרמל את השדות, מחפש event_id ביעד הבדיקה וממשיך לפי התוצאה. מסלול אחד מסיים אירוע כפול ללא כתיבה, ומסלול שני יוצר רשומה. לאחר יצירה, פצלו לפי urgency ושלחו התראה מתאימה. שמות המודולים המדויקים תלויים ביעד הנתונים ובערוץ ההתראה שבחרתם, ולכן המדריך אינו מניח תווית ממשק מסוימת.

לפי התיעוד הרשמי של Make על operations (נפתח בחלון חדש), operation היא הרצה של מודול שמעבד או בודק נתונים, ומודולים עשויים לרוץ פעם לכל bundle. המשמעות המעשית היא שלא מספיק לספור "ליד אחד". רשמו כמה operations וכמה credits, אם הממשק מציג אותם בתוכנית שלכם, נצרכו בהרצה תקינה, בכפילות ובכשל. מסלול ארוך או fan-out של bundles יכול לשנות את הצריכה גם כשמספר הלידים נשאר קבוע.

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

1. צרו webhook ייעודי לפיילוט ושלחו אליו את מטען הבדיקה.
2. מפו רק את השדות שנקבעו בחוזה והוסיפו בדיקות לשדות חובה.
3. נרמלו email ו-phone לפני חיפוש הרשומה.
4. חפשו event_id ופצלו בין duplicate לבין create.
5. לאחר יצירה מוצלחת, נתבו לפי urgency ושלחו התראה.
6. הוסיפו מסלול טיפול בשגיאה שמתעד event_id, השלב שנכשל והודעת השגיאה.
7. הריצו את ששת מבחני הקבלה ורשמו זמן ויחידות שימוש בפועל.

מממשים ב-n8n ובוחרים במפורש בין Cloud לאירוח עצמי

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

החלטת הפריסה היא חלק מההשוואה. התיעוד הרשמי של n8n (נפתח בחלון חדש) מציג n8n Cloud כשירות מנוהל ו-Self-hosted כפריסה בשליטת הארגון. אירוח עצמי מעניק שליטה בסביבה ובהגדרות, אך הארגון מקבל אחריות על התקנה, עדכונים, אבטחה, גיבוי וניטור. מדריכי האירוח העדכניים נמצאים תחת ‎/deploy/host-n8n/‎. אל תתנו לעלות רישיון אפסית במהדורת Community להסתיר שעות תפעול או עלות תשתית.

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

1. בחרו Cloud או Self-hosted ורשמו מי אחראי לתפעול האפשרות שנבחרה.
2. צרו webhook בדיקה ומפו את אותו JSON בדיוק.
3. בצעו נרמול ואימות לפני כל כתיבה.
4. חפשו event_id ופצלו בין עצירה תקינה לבין יצירה.
5. צרו רשומה ורק לאחר הצלחה הפעילו את ענף ההתראה.
6. תעדו כשל עם event_id ונתוני שלב מספיקים לשחזור בלי לחשוף מידע מיותר.
7. הריצו את חוזה הקבלה ורשמו זמן בנייה, זמן תיקון ומספר executions כפי שמוצג בסביבה שלכם.

מממשים ב-Zapier ובודקים שימוש לפי פעולות שהצליחו

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

לפי התיעוד הרשמי של Zapier על מדידת tasks (נפתח בחלון חדש), task הוא בדרך כלל action שהושלם בהצלחה. ה-trigger עצמו, וכן Filter או Paths, אינם נספרים כ-tasks לפי אותו מסמך, בעוד שפעולות מצליחות במסלול כן נספרות. יש חריגים ומוצרי Zapier בעלי מדידה אחרת, ולכן המדד הקובע הוא Task usage בחשבון בזמן הבדיקה ולא חישוב תיאורטי המבוסס על מחיר או מסך ישן.

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

1. הגדירו טריגר שמקבל את מטען הבדיקה ושמרו עותק של הקלט.
2. אמתו שדות חובה ונרמלו אותם לפני החיפוש.
3. חפשו event_id והפסיקו אירוע כפול לפני פעולת יצירה.
4. צרו את הרשומה ורק אחר כך הפעילו את ענף ההתראה.
5. הריצו ליד תקין, כפילות, קלט חסר וכשל יעד.
6. בדקו את היסטוריית הריצות ואת Task usage בפועל עבור כל תרחיש.
7. תעדו מי רשאי לבצע replay ומה עליו לבדוק לפני כן.

• ה-Zap אינו יוצר רשומה שנייה בהרצה חוזרת
• ההתראה נשלחת רק לאחר כתיבה מוצלחת
• היסטוריית הריצה מאפשרת לזהות את event_id שנכשל
• מדידת השימוש נלקחה מהחשבון ולא מהערכה

מודדים עלות שימוש בלי להיתפס למחיר פתיחה

השוואת מחיר הוגנת מתחילה ביחידת העבודה שהעסק באמת צורך, לא במספר שמופיע בכותרת של עמוד תמחור. ב-Make יש למדוד את ה-operations או יחידות השימוש שמוצגות בחשבון עבור כל תרחיש. ב-Zapier יש למדוד את ה-tasks שנרשמו בפועל. ב-n8n יש לתעד executions לפי הסביבה, ובאירוח עצמי להוסיף גם תשתית, גיבוי, עדכונים וזמן תפעול. המונחים אינם שקולים זה לזה, ולכן אין להמיר operation ל-task ביחס שרירותי.

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

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

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

בודקים כשל, ניסיון חוזר ושחזור בלי ליצור ליד נוסף

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

מנגנוני טיפול בשגיאות וניסיון חוזר שונים בין הפלטפורמות וגם עשויים להיות תלויי תוכנית או הגדרה. אל תסתמכו על ברירת מחדל. ב-Make בדקו בפועל מה עושה מסלול הטיפול שהגדרתם. ב-n8n בדקו את נתוני ה-execution ואת מסלול השגיאה שבניתם. ב-Zapier בדקו את סטטוס הריצה והאם אפשר לבצע replay בחשבון. התיעוד הרשמי של Zapier מדגיש שמחיקת רשומת היסטוריה אינה מבטלת פעולה שכבר בוצעה.

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

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

מגדירים אחריות, הרשאות ותחזוקה לפני הבחירה

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

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

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

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

מתכננים מעבר כך שהפיילוט לא ינעל אתכם לפלטפורמה

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

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

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

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

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

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

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

מכפילים כל ציון במשקל ומחברים. בדוגמה מתקבלים 370 ל-Make, 350 ל-n8n ו-350 ל-Zapier מתוך 500. הפער קטן, לכן ההחלטה אינה אוטומטית. הצוות בוחר Make כי התהליך דורש הסתעפות והמתחזק הצליח למסור אותו למחליף, אך קובע בדיקה מחדש אם צריכת השימוש חורגת מהתחזית במשך חודשיים. צוות עם DevOps ודרישת שליטה בתשתית עשוי להגיע לתוצאה אחרת.

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

מסיימים במבחני קבלה, מסירה וצעד הבא

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

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

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

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