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

מה אוטומציה עסקית אמורה לשפר?

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

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

איך בוחרים תהליך ראשון?

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

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

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

Power Automate, Zapier או פיתוח API?

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

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

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

מה עושים כשאין למערכת API?

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

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

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

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

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

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

מי מקבל התראה כשהאוטומציה נעצרת?

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

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

מה בודקים בהרשאות ובמידע שעובר?

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

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

מתי כדאי לשלב AI בתוך אוטומציה?

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

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

איך מודדים תועלת בלי להבטיח מספרים מראש?

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

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

מה לבקש לפני שעוברים לעבודה שוטפת?

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

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