מנהל תמיכה לא אמור להעתיק פרטי לקוחות מתיבת דואר ל-CRM, לחפש בשלוש מערכות את היסטוריית החשבון, לנתב בעיה לצוות הנכון ולכתוב את אותו עדכון סטטוס שוב ושוב. ובכל זאת, הרצף הזה עדיין מגדיר את העבודה היומיומית בחברות צומחות רבות. ההבנה מהי אוטומציה של תהליכים עסקיים מתחילה בזיהוי ההעברות החוזרות האלה כבעיות של תכנון תפעולי, ולא רק כעבודה אדמיניסטרטיבית.
מהי אוטומציה של תהליכים עסקיים?
אוטומציה של תהליכים עסקיים, או BPA, היא שימוש בתוכנה כדי לבצע, לתאם ולנטר תהליכי עבודה עסקיים חוזרים עם התערבות אנושית מוגבלת. היא מחברת את המערכות, הכללים, הנתונים, המסמכים והאישורים שמעורבים בתהליך, כך שהעבודה עוברת לשלב המתאים הבא באופן עקבי.
תהליך יכול להתחיל בבקשת לקוח, במסמך שהועלה, בהזמנה חדשה או במועד יעד בכספים. האוטומציה יכולה לאמת קלטים, לשלוף רשומות רלוונטיות, ליצור משימות, להפעיל אישורים, לעדכן מערכות מחוברות, לשלוח התראות ולתעד נתיב ביקורת. המטרה אינה להוציא אנשים מכל תהליך. המטרה היא להסיר העברות ידניות, המתנה מיותרת, טעויות שניתן למנוע ומאמץ דל ערך מהעבודה שאנשים עושים.
עבור מנהל תפעול, השאלה המעשית היא פחות "האם אפשר להפוך את זה לאוטומטי?" ויותר "אילו חלקים צריכים לרוץ אוטומטית, אילו החלטות דורשות בדיקה, והאם תהליך העבודה יכול לפעול באופן אמין על פני המערכות שיש לנו בפועל?"
BPA היא יותר מאוטומציה של משימה בודדת
כלל ששולח מייל אחרי הגשת טופס הוא שימושי, אבל הוא אינו בהכרח תוכנית לאוטומציה של תהליכים עסקיים. BPA מטפלת בתהליך עבודה מקצה לקצה, כולל התנאים שמתניעים אותו, הלוגיקה העסקית שמנהלת אותו, המערכות שהוא נוגע בהן, האנשים שצריכים לאשר חריגים והתוצאה שמוכיחה שהוא עבד.
קחו לדוגמה תהליך קליטת ספק חדש. אוטומציה בסיסית עשויה ליצור רשומה כשטופס מוגש. תהליך BPA מלא יכול לאסוף מסמכי מס ובנק, לאמת שדות נדרשים, לבדוק עמידה בדרישות מדיניות, לנתב מקרים בסיכון גבוה למחלקה המשפטית או לכספים, ליצור רשומת ספק ב-ERP, לעדכן את המבקש ולשמור ראיה לכל אישור.
ההבחנה הזו חשובה כי אוטומציה מפוצלת לעיתים קרובות מזיזה עבודה במקום לבטל אותה. אם צוותים עדיין מתאימים רשומות ידנית, רודפים אחרי אישורים בצ'אט או מזינים מחדש נתונים לפלטפורמה פיננסית, תהליך העבודה נשאר שביר.
ל-BPA, ל-RPA ול-AI יש תפקידים שונים
המונחים האלה מקובצים לעיתים קרובות יחד, אבל הם פותרים בעיות שונות.
אוטומציה רובוטית של תהליכים, או RPA, משתמשת בדרך כלל בבוטים של תוכנה כדי לבצע פעולות חוזרות בממשק משתמש קיים, כמו העברת נתונים בין אפליקציות מורשת. היא יכולה להיות אפקטיבית כשאין API זמין, אבל היא עלולה להיות רגישה לשינויים בממשק ולהקשר חלקי של התהליך.
BPA רחבה יותר. היא מתזמרת את תהליך העבודה עצמו: תנועת נתונים, כללים, אישורים, התראות, אינטגרציות, חריגים ודיווח. עליה להשתמש בממשקי API ובאינטגרציות ישירות בין מערכות ככל שניתן, כי הם בדרך כלל אמינים וקלים יותר לתחזוקה מאוטומציה מבוססת מסכים.
AI מוסיף שכבה מועילה כשהתהליך כולל מידע לא מובנה או צורך בתמיכה בשיקול דעת. רכיב AI יכול לסווג בקשות נכנסות, לחלץ שדות ממסמכים, לסכם היסטוריית תיק, לנסח תשובה או לזהות חריגים צפויים. אין להתייחס אליו כתחליף בלתי מבוקר לכללים עסקיים. בתהליכי עבודה רגישים מבחינה רגולטורית, פלטי ה-AI צריכים מעקות בטיחות, ספי ודאות, מסלולי בקרה אנושית ותיעוד ברור.
היכן אוטומציה של תהליכים עסקיים מייצרת ערך אמיתי
המועמדים החזקים ביותר ל-BPA הם תהליכים חוזרים בנפח גבוה עם קלטים מוגדרים והשפעה עסקית מדידה. הם חוצים לעיתים קרובות כמה מחלקות או מערכות, ולכן ייתכן שאוטומציית מדף לבדה לא תספיק.
בתפעול לקוחות, האוטומציה יכולה למיין פניות, להעשיר אותן בנתוני חשבון, לנתב אותן לפי סוג הבעיה ורמת השירות ולהכין לנציגים את ההקשר הרלוונטי. התוצאה היא זמני תגובה מהירים יותר בלי לאלץ את הנציגים לחפש בכלים מנותקים.
בכספים, תהליך עבודה יכול לקלוט חשבוניות, לחלץ פרטים מרכזיים, להתאים אותן להזמנות רכש, לסמן חריגים, לנתב בקשות אישור ולסנכרן רשומות מאושרות עם פלטפורמת הנהלת חשבונות או ERP. הרווח אינו רק פחות הקלדות. זו שליטה טובה יותר בתזמון התשלומים, בחריגים ובראיות לביקורת.
בביטוח, בהלוואות, באדמיניסטרציה רפואית ובסביבות אחרות עתירות מסמכים, BPA יכולה לתאם קליטה, איסוף מסמכים, אימות, שיוך תיקים והסלמה. AI יכול לסייע בפרשנות מסמכים, אבל התהליך עדיין צריך בקרות דטרמיניסטיות סביב זכאות, נתונים רגישים, סמכות החלטה ושמירת רשומות.
גם צוותי מוצר והנדסה מרוויחים. תהליכי עבודה אוטומטיים יכולים ליצור משימות הטמעה מדרישות מאושרות, לסנכרן נתוני מוצר בין מערכות, להריץ בדיקות איכות ולעדכן בעלי עניין כששחרור גרסה או אינטגרציה נכשלים. תרחישי השימוש האלה מצמצמים את החיכוך התפעולי ככל שהחברה גדלה.
הארכיטקטורה מאחורי אוטומציה אמינה
אוטומציה מועילה אינה שרשרת של טריגרים מנותקים. היא מערכת מבוקרת עם בעלות ברורה וטיפול בכשלים.
בבסיסה, הארכיטקטורה צריכה מקור אמת לכל תחום נתונים. פרטי הלקוחות עשויים להשתייך ל-CRM, הרשומות הפיננסיות ל-ERP, שיחות התמיכה לפלטפורמת שירות והמסמכים למאגר מאובטח. שכבת האוטומציה מתאמת בין המערכות האלה בלי ליצור עותקים סותרים של אותם נתונים.
היא צריכה גם כללים עסקיים מפורשים. לדוגמה, חשבונית מעל סף מסוים עשויה לדרוש שני אישורים. בקשת שירות מלקוח אסטרטגי עשויה לקבל ניתוב בעדיפות. מסמך עם מידע חסר עשוי לחזור למבקש במקום להיכנס לעיבוד בהמשך התהליך. הכללים צריכים להיות גלויים, מנוהלים בגרסאות וקלים לבדיקה.
ניהול חריגים חשוב באותה מידה. אף תהליך עבודה בייצור לא צריך להניח שכל רשומה שלמה או שכל אינטגרציה זמינה. הוא צריך לוגיקת ניסיונות חוזרים לכשלים זמניים, תורים לבדיקה ידנית, התראות על תיקים תקועים ודרך ברורה לתקן בעיה בלי להשחית נתונים קשורים.
אבטחה ורגולציה הן חלק מהתכנון, לא בדיקה מאוחרת. זה כולל גישה מבוססת תפקידים, אישורי גישה מאובטחים, הצפנה היכן שמתאים, צמצום נתונים, לוגי ביקורת, דרישות שמירת מידע ובקרות על מה שמודל AI יכול לגשת אליו או לפעול עליו. תהליך עבודה שחוסך זמן אבל חושף נתונים מפוקחים אינו אוטומציה מוצלחת.
איך להטמיע אוטומציה של תהליכים עסקיים בלי ליצור עוד מורכבות
נקודת הפתיחה הנכונה היא תהליך עם עלות ברורה של עיכוב או טעות. מפו את תהליך העבודה הנוכחי כפי שהוא פועל בפועל, כולל מעקפים בגיליונות אלקטרוניים, צווארי בקבוק באישורים, הזנה כפולה ומסלולי חריגים. תרשימי תהליך שמבוססים רק על מסמכי מדיניות מפספסים לעיתים קרובות את הצעדים שהעובדים נוקטים כדי שהעבודה תמשיך לזוז.
לאחר מכן, קבעו בסיס השוואה. מדדו זמן מחזור, נפח, זמן טיפול ידני, שיעורי שגיאות, צבר, ביצועי רמת שירות ועלות עבודה חוזרת. המדדים האלה הופכים הצעת אוטומציה למקרה עסקי ומאפשרים לשפוט אם הפריסה סיפקה ערך.
בשלב הבא, החליטו מה צריך לעבור סטנדרטיזציה לפני שהוא עובר אוטומציה. אוטומציה של תהליך לא ברור או לא עקבי עלולה רק לגרום להחלטות גרועות לקרות מהר יותר. חלק מהשונות לגיטימית, במיוחד עבור לקוחות בעלי ערך גבוה או מקרים מורכבים. התכנון צריך להבחין בין מסלול סטנדרטי, מסלול חריגים מבוסס כללים ומסלול של החלטה אנושית.
פיילוט הוא בדרך כלל ההטמעה הראשונה ההגיונית. עליו לכסות חלק משמעותי מתהליך העבודה, להתממשק למערכות אמיתיות הקרובות לסביבת הייצור ולכלול משתמשים אמיתיים. אב טיפוס שרק מדגים יכולת AI או טופס במסלול האידיאלי אינו מספיק כדי לאמת השפעה תפעולית.
אחרי הפיילוט, חזקו את תהליך העבודה לקראת ייצור. הוסיפו ניטור, תרחישי בדיקה, הרשאות, התאוששות משגיאות, תיעוד, בעלות ונהלי ניהול שינויים. ככל שכללים עסקיים ומערכות מחוברות משתנים, האוטומציה דורשת תחזוקה בדיוק כמו כל תוכנה קריטית אחרת לעסק.
טעויות נפוצות ב-BPA
הטעות הראשונה היא להתייחס לאוטומציה כאל רכישת כלי ולא כאל החלטה על מודל תפעולי. פלטפורמה יכולה להאיץ את המסירה, אבל היא לא יכולה לפתור בעלות לא ברורה, איכות נתונים ירודה או מדיניות סותרת.
השנייה היא אוטומציה מוגזמת של החלטות שדורשות אחריותיות. המלצות שנוצרות על ידי AI יכולות לזרז בדיקה, אבל על החברה להגדיר מתי אדם חייב לאשר, לעקוף או לחקור תוצר. הדבר רלוונטי במיוחד בחיתום, בבקרות פיננסיות, בהחלטות תעסוקה ובאינטראקציות מוסדרות עם לקוחות.
השלישית היא בניית חיבורי נקודה-לנקודה ללא אסטרטגיית אינטגרציה סקיילבילית. ככל שמתווספים כלים, תלויות לא מתועדות הופכות קשות לאבטחה, לבדיקה ולתחזוקה. ארכיטקטורה מחושבת מפחיתה את הסיכון הזה.
ולבסוף, צוותים רבים מודדים פעילות במקום תוצאות. מספר הצעדים האוטומטיים אומר מעט על הערך. מדדים טובים יותר כוללים קיצור זמן מחזור, עלות נמוכה יותר לתיק, פחות שגיאות, שיעורי ציות משופרים, גבייה מהירה יותר וגידול בקיבולת בלי גיוס עובדים באותו יחס.
להפוך אוטומציה ליתרון תפעולי
התשובה לשאלה מהי אוטומציה של תהליכים עסקיים אינה רק תוכנה שמבצעת עבודה ברקע. זו דרך ממושמעת לתכנן מחדש את זרימת העבודה בעסק, כך שמערכות ואנשים מטפלים כל אחד במשימות שהם מתאימים להן ביותר.
היוזמות עם התשואה הגבוהה ביותר הן בדרך כלל ממוקדות: לבטל לולאת אישור מתעכבת, לצמצם צבר של עיבוד מסמכים, לחבר העברת לקוח מקוטעת או לתת לצוותים נתונים אמינים בנקודת הפעולה. התחילו שם, בנו את הבקרות הנדרשות לייצור, ותנו לתוצאות תפעוליות מדידות לקבוע לאן האוטומציה תתרחב בהמשך.
