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