כל תוכנית אוטומציה ארגונית נתקלת באותו קיר. ניתוב כרטיסים ב-ServiceNow, תיקון סחיפת Terraform, סיבוב תעודות, הקצאת קבוצות ב-AD, פריסת עדכוני SCCM, תזמור צינורות CI/CD. עשרת או עשרים תהליכי העבודה הראשונים מצדיקים את ההשקעה בקלות, ומתמטיקת ההחזר על ההשקעה מחזיקה מעמד עד שמספר תהליכי העבודה חוצה את המאות וחלק משמעותי מהשבוע של צוות ה-IT עובר מבניית אוטומציה חדשה לשמירה על האוטומציה הקיימת מלקרוס.

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

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

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

מה באמת אומר ריפוי עצמי

הביטוי משמש בצורה רופפת, אז אהיה ישיר לגבי מה שזה בפועל.

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

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

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

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

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

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

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

הנה איך זה נראה בפועל. נניח שאתם מאטמטים הקצאת גישה לעובדים. עובד חדש מתחיל ביום שני והתהליך צריך ליצור חשבונות ב-Active Directory, להקצות חברות בארגון GitHub שלהם, לשייך קבוצות Okta, ולפתוח כרטיס Jira שמאשר השלמה. צעד אחד מושך את רשומת העובד ממערכת ה-HR שלכם. שדה הכוונה שלו לא אומר רק "קבל את רשומת העובד." הוא אומר: "צעד זה הוא מקור האמת לכל החלטת הקצאה במורד הזרימה. תפקיד, מחלקה ותאריך תחילה מרשומה זו קובעים אילו קבוצות AD מוקצות, אילו צוותי GitHub מוקצים, ואילו מדיניות Okta חלות. אם צעד זה מחזיר נתונים ישנים או חלקיים, כל צעד במורד הזרימה יקצה גישה שגויה."

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

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

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

צפייה בזמן אמת פירושה תפיסת בעיות לפני שהן הופכות לכשלים

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

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

זה עדיין תהליך העבודה שלכם

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

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

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

ניהול זה בכל ערוץ שאתם כבר משתמשים בו

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

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

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

מה זה באמת משנה עבור צוותי IT

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

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

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

זמין מהיום

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

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

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