מבקרים פנימיים בחברת הובלת מטענים לוקחים RPA למבחן דרכים

אוטומציה רובוטית של תהליכים robotic process automation) – RPA) מקבלת תשומת לב רבה לאחרונה עקב יכולתה לייעל תהליכים ולשפר יעילות. בפשטות, RPA היא אוטומציה באמצעות רובוטים וירטואליים (בוטים) של משימות מבוססות-מחשב שבאופן מסורתי מבוצעות על ידי אנשים. בוטים של RPA מורכבים מתוכנות שמבצעות פעולות חזרתיות באופן זהה לאנשים שמבצעים אותן.

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

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

היכולות החזקות של טכנולוגיה זו מאפשרות שימוש ב-RPA עבור יישומים רבים, מאיטמוט של התאמות חשבון לביצוע של משימות ביקורת. בהתחשב ביכולות אלו, מחלקת הביקורת הפנימית ב-YRC Worldwide (YRCW), חברת הובלה המתמחה בהובלת מטענים ובשירותים לוגיסטיים עבור חברות שילוח בצפון אמריקה, השיקה תוכנית פיילוט ליישום טכנולוגיית ה-RPA. הפיילוט הצליח ונתן אור ירוק לתוכנית יישום פורמלית ולפריסה של RPA בעתיד.

התנופה לעבר RPA

מחלקת הביקורת הפנימית ב-YRCW מונה 17 עובדים ומחולקת לשתי קבוצות – קבוצה אחת מתמקדת בציות רגולטורי, במתן הבטחה מבוססת סיכון במוקד העורפי ובשירותי ייעוץ; הקבוצה השנייה מתמקדת בציות ובסקירות תפעוליות עבור יותר מ-300 הטרמינלים למטענים ברשת YRCW. פיילוט ה-RPA של מחלקת הביקורת הפנימית התמקד בתחום הביקורת הפנימית עבור הטרמינלים.

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

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

היערכות לאוטומציה

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

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

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

הוכחת היתכנות

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

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

קידום יוזמת ה-RPA

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

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

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

הפיילוט של הבוט

השלב האחרון בהוכחת ההיתכנות כלל פיתוח של בוט כפיילוט. הפיתוח כלל כמה שלבים:

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

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

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

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

תוצאות הפיילוט

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

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

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

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

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

הדרך קדימה

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

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

כלי שינוי

כמו רוב הכלים הטכנולוגיים, כלי ה-RPA אינו פתרון של one-size-fits-all. מודל היישום שלו ופוטנציאל הערך שלו יהיו שונים בכל ארגון וארגון. בסופו של דבר, הערך שב-RPA הוא באיטמוט של פעילויות סטנדרטיות המבוצעות בתדירות גבוהה. למחלקות ביקורת פנימית שתוכניות הביקורת שלהן מכילות התקשרויות משמעותיות שחוזרות על עצמן להבטחת ציות, תהיה הצדקה טובה יותר ליישום ה-RPA מאשר למחלקות שתוכניותיהן מכילות שיעור גבוה יותר של פרויקטים תפעוליים ושל שירותי ייעוץ. עבור מחלקות ביקורת פנימית שבהן יישום ה-RPA הוא הגיוני – זה יכול להיות game-changer.

מיומנויות בפיתוח בוטים

התחלת השימוש ב-RPA אינה מחייבת מיומנויות מיוחדות. רוב כלי ה-RPA כוללים סוגים של ממשק משתמש גרפי טיפוסיים עם פונקציות של point and click המסייעות למשתמשים מתחילים להתחיל מיד.

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

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

תחשבו לפני שאתם מבצעים אוטומציה

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

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

“*This article was reprinted with permission from the April 09, 2020 issue of Internal Auditor magazine, published by The Institute of Internal Auditors, Inc., and has been translated from English to Hebrew.”

אודות הכותב/ת

ריק רייט