אוטומציה לתהליכים עסקיים כחלק מפרויקט פיתוח תוכנה

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

בפרויקטים רבים זו דווקא טעות.

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

ההבדל יכול להיות משמעותי.

אוטומציה מתחילה בתהליך, לא בכלי

הטעות הנפוצה היא להתחיל מהשאלה: “איזה כלי אוטומציה אפשר להטמיע?”

אבל הכלי אינו המטרה.

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

אפשר לחבר כלי אוטומציה לכל אחד מהשלבים.

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

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

לכן, אוטומציה טובה מתחילה במיפוי של התהליך.

אילו תהליכים מתאימים במיוחד לאוטומציה?

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

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

1. הפעולה חוזרת על עצמה בתדירות גבוהה.
2. יש סדר פעולות שניתן להגדיר.
3. נדרש זמן עבודה משמעותי.
4. טעויות אנוש גורמות לעלות או לעיכוב.

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

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

אוטומציה אינה בהכרח “החלפת עובד”

זו נקודה שחשוב להבין.

במקרים רבים, המטרה אינה להחליף את האדם אלא להעביר אליו רק את החלקים בתהליך שבהם נדרש שיקול דעת.

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

כך האדם לא נעלם מהתהליך. התפקיד שלו משתנה.

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

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

כאן מתחיל ההבדל בין אוטומציה חיצונית לבין אוטומציה כחלק מפרויקט תוכנה.

נניח שחברה מפתחת מערכת לניהול הזמנות.

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

אבל אפשר גם לתכנן את המערכת כך שאירועים מסוימים יפעילו תהליכים באופן מובנה.

לדוגמה:

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

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

החיבור בין מערכות הוא חלק מרכזי

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

הם צריכים לגרום למערכות שונות לדבר זו עם זו.

לדוגמה:

CRM ←  ERP ←  מערכת חיוב ←  שירות לקוחות.

או:

טופס באתר ←  CRM ←  מערכת ניהול משימות ←  הודעה לצוות.

כאן נכנסות לתמונה אינטגרציות ו-APIs.

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

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

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

לפעמים האוטומציה העסקית הטובה ביותר היא דווקא פעולה פשוטה.

לדוגמה:

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

אין צורך להכניס AI לכל תהליך רק משום שהוא קיים.

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

מתי AI כן יכול להיכנס לתמונה?

AI הופך מעניין כאשר התהליך אינו מבוסס רק על חוקים קבועים.

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

במקום:

“אם X אז Y”

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

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

איך יודעים אם אוטומציה הצליחה?

לא לפי מספר האוטומציות שנבנו.

מדד טוב יותר הוא ההשפעה על התהליך.

לדוגמה:

זו גם הסיבה שכדאי למדוד את התהליך לפני הפיתוח.

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

אוטומציה טובה היא חלק מהארכיטקטורה

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

זה יכול להיות הבדל משמעותי לעומת ניסיון “להדביק” אוטומציות למערכת קיימת.

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

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