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