שדרוג מערכות: כואב אבל פחות

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

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

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

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

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

4. בדיקות המערכת – בכל עבודת תוכניתן יש 5%-15% טעויות, קחו את זה בחשבון. ככל שהחלק הידני בתהליך השדרוג נרחב יותר וודאו שאתם מקצים משאבי בדיקות מתאימים. כיום, המערכת שלכם יציבה וצופנת בחובה השקעה אמיתית של שנים רבות. החלפת מערכת תוך מתן מענה לכל אותן הדקויות, היא תהליך מורכב שמצריך אין סוף בדיקות. ככל שתקפידו בבדיקות, ותתכננו אותן בצורה ריאלית (חודש בדיקה על חודש כתיבה), יהיה יותר סיכוי שתעלו לאוויר במועד המתוכנן.

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

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

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

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

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

הכותב הוא מייסד ומנכ"ל חברת פיירפליי