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

תמונה: dreamstime

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

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

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

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

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

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

מי באמת יודע?

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

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

  תמונה: dreamstime

מפענחים אילוצים ומגבלות

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

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

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

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

אתגרים והחלטות קריטיות

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

כך בונים תמונה מלאה

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

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

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

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