שלוש תפישות שגויות באיתור תהליכי RPA
אחד האתגרים המרכזיים בתחום ה-RPA הוא איתור תהליכים מתאימים בעלי ערך ארגוני גבוה. במסגרת פעילותנו בעשרות ארגונים מהגדולים במשק, כאינטגרטור המוביל בארץ בתחום ה-RPA, אנו נתקלים בשלוש תפישות שגויות של ארגונים בניסיון לאתר תהליכי RPA, הן בתחילת המסע הרובוטי, ולעיתים גם בשלבים מאוחרים יותר שלו:
א. התייחסות לתהליכי RPA שבוצעו בארגונים דומים כבסיס טוב לבחירת תהליכים עבור הארגון.
ב. אימוץ התפישה כי יועצים חיצוניים יוכלו לאתר בארגון תהליכי RPA בצורה מיטבית.
ג. כלי Discovery אוטומטיים יאתרו תהליכי RPA נסתרים לארגון, במהירות וקלות.
הסיבות לאי ההתאמה של שלוש התפישות
מניסיוננו למדנו כי שלוש התפישות הללו הן לא בהכרח המתאימות ועלולות להביא ארגונים לחוסר מיקוד, בזבוז זמן ומשאבים גם יחד, ואף לתוצאות בעייתיות:
א. RPA במהותו הוא פיתוח ספציפי המותאם לדרישות, תשתיות, מערכות ושיטות היישום של הארגון, ולא פתרון ג'נרי.
בשל ההבדלים המובנים הנ"ל, תהליכי RPA שפותחו בארגון דומה מאותו ורטיקל, ביחידות מקבילה, עשויים להיות בעלי ערך גדול לארגון שפיתחם, ומאידך לא מעניינים לארגון המקביל.
ניסיון אימוץ רעיונות, רק כי ארגון מקביל מימש תהליכים כנ"ל, לרוב יסתיים בבחינת סרק, כשבמקרה הגרוע תהליכי RPA שלא יפתרו אתגר מהותי יודממו, ובשורה התחתונה יבזבזו משאבים רבים וימנעו מיקוד באיתור ופיתוח תהליכי ה-RPA המתאימים לארגון הספציפי.
ב. בעלי התפקידים בארגון מכירים את כאביו ואתגריו טוב יותר מכל יועץ חיצוני.
לעיתים מכח "אפקט ההילה", ארגונים סוברים כי ליועץ חיצוני מנוסה ב-RPA יהיה יתרון משמעותי בהובלת איתור תהליכי RPA.
בפועל, בעקבות חוסר ההיכרות הספציפית עם הארגון, בשילוב האפשרות להטיה מהסעיף הקודם, כל אותם יתרונות תיאורטיים של היועץ החיצוני מתבטלים.
בבואו לראיין יחידות בארגון, היועץ החיצוני יתקל לרוב בהתנגדויות מצד עובדי היחידה, בייחוד אם טרם נחשפו לתועלות הרובוטיות וחוששים שהרובוטים יגזלו את מקומם. בנוסף לכך, קל יחסית לתמרן את היועץ החיצוני במידע שגוי או לא מדויק, בשל היכרותו המוגבלת, והתוצאה עלולה להיות מסקנות והמלצות שגויות.
היתרונות המרכזיים של אינטגרטור חיצוני בתחום ה-RPA הן יכולות פיתוח RPA גבוהות, היכרות עומק עם הפלטפורמה הרובוטית, וראייה יישומית רחבה, כתוצאה מהתנסות בפיתוח מקביל בארגונים רבים.
תפקיד חשוב אחר של אינטגרטור הוא סיוע בתצורה ומתודולוגיה נכונה להקמת COE ל-RPA הארגוני, אך יתרונו היחסי אינו באיתור התהליכים הספציפיים של הארגון.
ג. פלטפורמות ה-Discovery האוטומטיות, בוודאי ביכולותיהן הנוכחיות, מורכבות ליישום כולל פענוח הפלטים שלהן, כך שמתחייבת השקעה גדולה רק בכדי להגיע לתובנות הגולמיות.
לרוב כלי ה-Discovery נותנים משקל גם לחלקי תהליכים חוזרים שוליים, ובעקבות כך יכולים להציף "רעשים" לתהליכים מועמדים רבים, שאחרי בחינה מתברר כי לא משתלם לבצע עבורם אוטומציה רובוטית, ובכך עשויים לפגוע במיקוד תהליך האיתור ולבזבז זמן יקר.
מניסיוננו, ראיונות עם מנהלי היחידות הרלוונטיות תורמים לאיתור תהליכים מועמדים ל-RPA בצורה מהירה, ממוקדת, ויעילה יותר מכלי ה-Discovery האוטומטיים.
אפילו במקרה האידיאלי התיאורטי, שכלי ה-Discovery יציפו תהליכים רלוונטיים, פרקטית כמעט כל תהליך RPA מפותח בתצורה שונה ומשודרגת ביחס לתצורת התפעול האנושית הנוכחית, כאשר המיפוי האוטומטי יספק תמונה של המצב הקיים בלבד, ולא יהווה אפיון של התהליך העתידי.
אם כך, מהן בכל זאת הדרכים המיטביות לאיתור אותם תהליכים?
מיקוד ביחידות רלוונטיות – RPA הוא פלטפורמה לאוטומציה לתפעול בארגון. לפיכך, האזורים המתאימים ביותר לאיתור תהליכים רובוטיים הן יחידות התפעול המרכזיות ועתירות העובדים בפרט.
דוגמאות לסוגי יחידות כנ"ל הן מוקדים, חדרים עורפיים, לוגיסטיקה, כספים, IT ועוד. כיוון אחר הוא ארגונים עם סניפים/יחידות המבצעות פעילויות דומות באופן מבוזר בארגון (בתחומים כגון בריאות, בנקאות, קמעונאות וכדומה), אשר עשויים לקבל מענה רובוטי מרכזי.
או"ש מוביל איתור תהליכים – או"ש הוא הגוף הארגוני האידיאלי להובלת איתור תהליכי RPA. יש לו את הידע הארגוני הרוחבי, היכרות עמוקה עם היחידות ואתגריהן, ומיומנות באיתור ומיפוי תהליכים.
האו"ש יכול לבצע ראיונות ומיפויים ביחידות מהאזורים הרלוונטיים ל-RPA בנקל.
סדנאות ארגוניות של RPA והאקטונים – לאחר ביצוע מספר תהליכי RPA ראשוניים, מומלץ מאד לקיים סדנאות פנימיות עם מנהלי יחידות רלוונטיות בארגון, במטרה להציג דוגמאות ליכולות שכבר מומשו בארגון, וכך להגיע ללידים וחשיפה ארגונית רבה לתהליכים נוספים.
שלב יותר מתקדם הוא ביצוע תחרות ארגונית נושאת פרסים בין צוותים, לאיתור תהליכי RPA בעלי ערך מהותי.
סדנאות אלו גם גורמות להפגת החשש הראשוני משילוב הרובוטים בארגון.
תוכניות עבודה של ה-IT בארגון – לאחר שה-RPA הופך להיות חלק מארגז הכלים הטכנולוגי הארגוני, ניתן לבצע בחינה של משימות שונות בתוכנית העבודה של ה-IT ולאתר תהליכים ש-RPA יכול לתת להם מענה מיטבי בעלות תועלת למול יתר החלופות, כולל יישום משימות שביצוען נדחה, מאחר שאינן כדאיות למימוש בחלופה אחרת.
דו"חות ביקורת ותלונות לקוחות – מציפים בין היתר סיכונים תפעוליים ותהליכים לא יעילים, שלעיתים ניתן לתת להם מענה באמצעות תהליכי RPA, לפי העניין.
בקשות יזומות מצד יחידות – ארגון שמגיע לשלב הפקטורי ב-RPA עם COE ויכולת דליברי חזקה ואיכותית, מביא באופן טבעי להגדלת הביקוש לתהליכי ה-RPA, ובעקבות הבאזזז הארגוני החיובי נוצר ביקוש במשיכה מצד היחידות השונות.