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