פתיחה

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

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

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

כל הסדרה

אור – מדוע הן אומצו

אפקט מיידי

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

כוח השכנוע של “הכל נראה”

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

הצעד הראשון של האזרחים

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

צל (1) – “חומת המקצוענים” שמופיעה בשטח

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

  • הכרחיות מבני הבקרה כדי לפצל עיבוד לפי תנאי לקוח צריך תנאי If/Else. כדי לטפל במאות רשומות חייבים ForEach. כדי להתכונן לעיכובים או שגיאות במערכות חיצוניות חייבים Try/Catch. הממשק רק מאפשר לגרור בלוקים; במהות זו עדיין תכנות.

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

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

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

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

צל (2) – נעילת ספקים וקושי בהגירה

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

  • מעבר למוצר של ספק אחר שקול, הלכה למעשה, ל"בניית הכול מחדש".
  • סגירת שירות SaaS או שינוי דרסטי במפרט אינם בשליטת הלקוח ועלולים להפוך בן לילה נכס שנבנה לאורך שנים לחסר ערך.
  • אם בונים על PaaS מסוים, נכבלים לאקוסיסטם של אותה ענן, והוצאתו לסביבה אחרת כמעט בלתי אפשרית.
  • כשמגדירים לוגיקה ב-UI ולא בקוד, קשה לאתר היכן הבעיה, וקשה אפילו לחפש.
  • לעיתים מרכיב דורש “קליק כפול” כדי להבין מה יש בתוכו – דבר שמוריד את הקריאות לרצפה.

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

צל (3) – “ההטיה של הכל נראה” שמסנוורת הנהלות

מהנדסים מזהים מהר מאוד שיגיע רגע האמת מול “חומת המקצוענים”. אבל הנהלות רואות זרימה שצוירה ב-GUI או מסכים שמבריקים על המסך, וממהרות להניח ש"כל אחד יוכל".

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

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

אל עבר עידן “אקסל האל 2.0”

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

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

סיכום

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

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

הבא: המורשת שה-AI הגנרטיבי מציל – והמורשת שהוא נוטש (חלק 4 מתוך 7)