מוצר, תוכנה ו־AI מעשי
איך לחדש מערכת ותיקה תוך שמירה על העבודה השוטפת
מודרניזציה של מערכת ותיקה לא חייבת להתחיל בכתיבה מחדש. כך ממפים את המערכת העסקית, מצמצמים סיכון, בוחרים מסלול לכל רכיב ומשחררים שיפורים בשלבים.
מערכת ותיקה היא יותר מקוד ישן. עם השנים יכולים להצטבר בה כללי תמחור, אישורים, חריגים, היסטוריית לקוחות, קיצורי דרך תפעוליים וידע שנרכש בעבודה היומיומית. חלק מהידע מתועד; חלקו עשוי להימצא במסכים, בקבצי אקסל, באינטגרציות ובהרגלים של האנשים שמפעילים את המערכת.
לכן פרויקט מודרניזציה לא צריך להתחיל בשאלה ״באיזו טכנולוגיה חדשה נשתמש?״, אלא בשאלה מעשית יותר: ״מה חייב להמשיך לעבוד בזמן שאנחנו משפרים את המערכת?״
מסלול שמצמצם סיכון מתחיל בדרך כלל בהבנה, בהגנה ובשינוי הדרגתי ומבוקר. לפעמים כתיבה מחדש היא הבחירה הנכונה, אבל עליה להיות מסקנה שמבוססת על ראיות — לא ברירת המחדל.
מתחילים מהעסק, לא רק מהתוכנה
רשימה טכנית יכולה להראות אילו אפליקציות, מסדי נתונים ואינטגרציות קיימים. היא לא מסבירה אילו תהליכים עסקיים נשענים עליהם, אילו חריגים באמת חשובים ומה העובדים עושים כשהתהליך הרשמי אינו מתאים למקרה שבפניהם.
לפני שנוגעים בקוד, כדאי לבנות מפת תפעול שעונה על חמש שאלות:
- מי תלוי במערכת? משתמשי קצה, מנהלים, כספים, שירות לקוחות, שותפים חיצוניים וכל מי שמקבל ממנה דוחות או קבצים.
- אילו תהליכים אסור להשבית? חשוב לזהות פעולות קריטיות, תקופות שבהן אי אפשר לסבול השבתה והחלטות שתלויות במידע עדכני.
- איפה נמצאים הכללים האמיתיים? לא רק בקוד. הם יכולים להסתתר בפרוצדורות במסד הנתונים, במשימות מתוזמנות, באקסלים, בתבניות מייל, באישורים ידניים או בשגרת עבודה שמעולם לא תועדה.
- למה המערכת מחוברת? ממשקי API, העברות קבצים, שירותי הזדהות, סליקה, כלי דיווח ומעברים ידניים בין אנשים וצוותים.
- איפה מרוכז הסיכון? הכנסות, רגולציה, התחייבויות ללקוחות, מידע רגיש, פעולות שאי אפשר לבטל ותהליכים שרק אדם אחד יודע להפעיל.
המפה הזו יוצרת תמונה משותפת לאנשי העסק והטכנולוגיה. היא גם מצמצמת את הסיכון לבנות מחדש רק את הממשק הנראה לעין, בלי לשמר את ההתנהגות התפעולית שהמערכת חייבת להמשיך לספק.
בונים רשת ביטחון לפני שמגבירים קצב
במערכת ותיקה ייתכן שכמעט אין כיסוי אוטומטי, בעוד שהמשתמשים מחזיקים ידע חיוני על ההתנהגות הצפויה ועל חריגים חשובים. תהליך החידוש צריך להפוך את הידע הזה לקריטריוני קבלה, בדיקות רגרסיה וניטור מפורשים.
מתחילים במסלולים שבהם תקלה תגרום את הנזק הגדול ביותר. מתעדים קלטים מייצגים, תוצאות צפויות, הרשאות, אינטגרציות וחריגים חשובים. בהתאם למערכת, רשת הביטחון יכולה לכלול:
- בדיקות רגרסיה מקצה לקצה לתהליכים קריטיים;
- בדיקות חוזה ל-API ולאינטגרציות;
- תיעוד תוצאות של דוחות או חישובים מרכזיים;
- התאמה בין הפלט של המערכת הישנה לפלט החדש;
- ניטור שגיאות, זמני תגובה ותהליכי רקע שנכשלו;
- רישום פעולות לצורך בקרה במקומות רגישים;
- אסטרטגיית חזרה לאחור, התאוששות או צמצום נזק שמתאימה לכל שינוי בייצור ונבדקת מראש.
ב־Bumblebee Studio אנחנו מפתחים את st4ck, שנמצאת כעת באלפא, כדי לחבר בין ההסברים של בעלי העניין לבין ראיות ממאגר הקוד, לארגן את התוצאה כתיעוד ודרישות ולקשור שינויים קריטיים לבדיקות דפדפן חוזרות. האחריות לאישור הכללים העסקיים, החריגים וקריטריוני הקבלה נשארת בידי אנשים.
לא חייבים להגיע לכיסוי מושלם לפני שמתחילים. כן צריך מספיק ראיות כדי לזהות שינוי ששבר משהו שהעסק תלוי בו. ככל שמתקדמים לאזור חדש במערכת, מרחיבים גם את ההגנה סביבו.
בוחרים מסלול לכל רכיב בנפרד
אין אסטרטגיה אחת שמתאימה לכל המערכת. גם בתוך אותה סביבת תוכנה, רכיבים שונים יכולים לדרוש החלטות שונות.
| מסלול | מתי הוא מתאים | הפשרה המרכזית |
|---|---|---|
| מייצבים ומשאירים | הרכיב אמין, מובן ואינו חוסם את העסק | מעט הפרעה, אך המגבלות הטכניות נשארות |
| עוטפים בממשק בטוח | הרכיב עדיין עובד, אבל שירותים חדשים צריכים גישה מסודרת אליו | מרוויחים זמן וגמישות, אך התלות נשארת |
| מחליפים בשלבים | אפשר להעביר תהליך או יכולת אחת בכל פעם | מצמצמים את היקף השינוי בכל שלב, אך החפיפה הזמנית מוסיפה מורכבות |
| כותבים מחדש | המבנה הקיים אינו יכול לתמוך בשינוי הנדרש, וההתנהגות העסקית כבר מובנת היטב | חופש תכנוני גדול יותר, לצד סיכון משמעותי בפיתוח ובהסבה |
| מוציאים משימוש | היכולת אינה בשימוש, כפולה או כבר אינה בעלת ערך | מפחיתים מורכבות, אבל צריך לוודא שאכן אין בה צורך |
הסתכלות כזו מונעת שני קצוות יקרים: להשאיר הכול כי שינוי מרגיש מסוכן, או להחליף הכול רק מפני שהטכנולוגיה ישנה.
יוצרים נקודות חיבור שמאפשרות שינוי ממוקד
צעד טוב בתהליך המודרניזציה יוצר גבול בין מה שחייב להישאר יציב לבין מה שצריך להתפתח. הגבול יכול להיות API, זרם אירועים, תהליך סנכרון, שכבת דיווח או ממשק חדש סביב תהליך קיים.
גבולות טובים מאפשרים לשפר אזור אחד בלי להוציא גרסה של כל המערכת. הם גם מאפשרים להשוות בין ההתנהגות הישנה לחדשה, להעביר קבוצה קטנה של משתמשים למסלול החדש ולחזור לאחור אם התוצאות אינן טובות.
כדאי לתעדף נקודות חיבור שמייצרות ערך עסקי, ולא רק ארכיטקטורה אלגנטית. למשל: קיצור תהליך אישור ידני, הנגשת מידע לצוות נוסף, ביטול הקלדה כפולה, שיפור מסלול לקוח או החלפת אינטגרציה שבירה. לכל צעד צריך להיות יעד תפעולי ברור, גם כשהעבודה שמתחת לפני השטח טכנית מאוד.
מכינים תשתית ל-AI בלי להפוך את כל הפרויקט לפרויקט AI
הוספת עוזר AI אינה פותרת כשלעצמה תהליך לא ברור. בלי כללים ובקרות מפורשים היא עלולה להוסיף אי־ודאות. קל יותר לבדוק ולנהל יכולות AI כשהמערכת שסביבן נשענת על כללים מפורשים, נתונים שאיכותם ומקורם ידועים ופעולות מבוקרות.
תשתית שמוכנה לשילוב AI כוללת בדרך כלל:
- בעלות ברורה על מידע והרשאות גישה מוגדרות;
- נתונים עסקיים מובנים שניתן להתחקות אחר מקורם;
- ממשקים יציבים לכלים שסוכן AI עשוי להפעיל;
- הפרדה ברורה בין המלצה לביצוע פעולה;
- אישור אנושי להחלטות בעלות השלכות;
- תיעוד שמראה איזה מידע התקבל, מה הוחלט ומה השתנה;
- מקרי בדיקה שמבוססים על תהליכים אמיתיים וחריגים;
- התנהגות בטוחה כשחסר מידע או כשהביטחון בתוצאה נמוך.
התשתית הזו יכולה להיות מועילה גם אם לא מוסיפים AI מיד. היא יכולה לשפר את התחזוקה, את החיבור למערכות אחרות ואת הנראות התפעולית. כאשר יש הצדקה לשלב LLM או סוכן, אפשר לעשות זאת בתוך מערכת בעלת גבולות ברורים יותר.
משחררים שינויים בקצב שהארגון יכול לספוג
גם הסבה נכונה מבחינה טכנית יכולה להיכשל אם היא דורשת מהארגון לשנות יותר מדי בבת אחת. צריך לתכנן את ההשקה לפי הקיבולת התפעולית, לא רק לפי קצב הפיתוח.
אפשר להתחיל ממשתמשים פנימיים, מצוות אחד או מקבוצת לקוחות מוגדרת. במקרים אחרים נכון להפעיל את הישן והחדש במקביל, לפתוח תחילה הרשאת קריאה בלבד, או להשתמש בדגל תכונה שמאפשר לחזור במהירות למסלול המוכר. הסבות נתונים צריכות לעבור הרצה מוקדמת על נתוני בדיקה מייצגים ומוגנים כראוי. לאחר מכן משווים בין המקור ליעד ומגדירים מראש נקודת החלטה להמשך ותוכנית התאוששות.
הדרכה, תמיכה ובעלות הן חלק מההשקה. לכל יכולת חדשה מגדירים בעלים: אדם שיודע כיצד היא אמורה להתנהג, איך מזהים בעיה ומי מוסמך להגיב.
רשימת בדיקה לפני השינוי המשמעותי הראשון
לפני שמאשרים שינוי רחב, כדאי לוודא שהצוות יודע לענות על השאלות הבאות:
- איזו תוצאה עסקית אנחנו רוצים לשפר?
- אילו תהליכים חייבים להישאר זמינים לאורך הפרויקט?
- אילו כללים וחריגים אומתו מול משתמשים אמיתיים?
- איזה מידע עובר, משנה בעלות או משנה פורמט?
- אילו מערכות חיצוניות ומעברים ידניים מושפעים?
- איך נשווה בין ההתנהגות הנוכחית להתנהגות החדשה?
- אילו בדיקות, ניטור והתאמות יחשפו רגרסיה?
- מהו הצעד הקטן ביותר שנותן ערך אמיתי בייצור?
- מי מחליט אם הצעד הצליח?
- איך חוזרים לאחור בבטחה?
- איזה רכיב ישן אפשר להסיר אחרי שהפתרון החדש הוכיח את עצמו?
אם חלק מהתשובות עדיין חסרות, זו אינה סיבה לוותר על המודרניזציה. זה סימן שהשלב הראשון שצריך לתקצב הוא למידה וייצוב.
מה צריכה לכלול תוכנית שאפשר לסמוך עליה
תוכנית טובה היא יותר מתרשים ארכיטקטורה של המצב העתידי. היא צריכה לחבר בין העבודה הטכנית למציאות התפעולית ולהציג את אי-הוודאות במקום להסתיר אותה. לכל הפחות, היא צריכה לכלול:
- מפת מערכות, תהליכים, מידע ובעלות;
- ריכוז של כללים קריטיים, חריגים ותלויות;
- רשימה מתועדפת של סיכונים והזדמנויות;
- החלטה לכל רכיב: להשאיר, לעטוף, להחליף, לכתוב מחדש או להוציא משימוש;
- תוכנית לבדיקות רגרסיה ולניטור;
- שלבי השקה עם תנאי קבלה ואפשרויות חזרה לאחור;
- דרך מפורשת להסרת פתרונות ביניים ורכיבים ישנים.
המטרה אינה לגרום לתוכנה הישנה להיראות חדשה. המטרה היא ליצור מערכת שהעסק יכול להמשיך להפעיל היום — ולשנות בביטחון מחר.