ההחלטה על החלפת מערכת מידע מרכזית בארגון (כגון ERP, CRM, גביה ואפילו רכיב תשתיתי מרכזי כמו בסיס נתונים) , היא מורכבת. אך כאשר הוחלט להחליף, פרוייקט כזה, לרוב, צפוי להיתקל בקשיים. הסיבות האפשריות הן רבות (כמכפלת המשתמשים בכמות התהליכים, בכמות הספקים המעורבים וברכיבי הטכנולוגיה השונים). אז איך בכל זאת משפרים את סיכויי ההצלחה? בפוסט זה נעלה מספר עקרונות להתנהלות שיעשו הבדל:
8 דגשים לפרויקט החלפת מערכת מידע:
1. לקצר את התקופה שמתחילת הפרויקט עד הרגע שהמערכת החדשה עולה לאוויר - ככל שניתן. את עיקרון הקיצור נרחיב עם:
יש לוותר או לדחות כל פונקציונאליות שאינה קריטית.
אסור לשאוף ל"מוכנות מלאה" השאיפה לשלמות היא הגורם המרכזי לרוב הכשלונות. הסיבה היא שכל פרק בעבודת צוותי הטכנולוגיה של מערכות מידע, אורך זמן. מאידך, בארגון דינאמי, קצב השינויים גבוה. יחד עם השינויים התכופים משתנים הצרכים וסדרי העדיפות. כשהשינוי הארגוני המהיר פוגש את קצב הביצוע, שהוא איטי מטבעו – הארגון נכנס למצב של אי ספיקה.
2. מרגע התחלת הפרוייקט, אסור לפתח במערכת הישנה במקביל לפרויקט. מאחר וכל שינוי או תוספת במערכת הישנה מרחיבה את תכולת הפרוייקט גם במערכת החדשה. פועל יוצא הכרחי הוא - ייקור משמעותי של הפרויקט הנובע מפיתוח כפול (ראה גם בפוסט המקושר ) יחד עם הפיכת הפרויקט ל"אין סופי" תוך זילות בלו"ז ובמשאבים המוקצים. על כן: אם אפשר לדחות את השינוי עד לאחר עליית המערכת החדשה – לדחות. אם לא – שיפותח קודם במערכת החדשה.
3. חשוב לבסס שותפות עם משתמשי המערכת ולוודא שהם פעילים ולא רק, אלא גם נושאים באחריות(!), מבינים את ההכרח בצמצום הפונקציונאליות, בבדיקות ומובילים את ההטמעה.
4. חשוב שההנהלה תסוכך ותוודא תזמון נכון של הפרויקט. כלומר: שינויים קריטים לארגון, שיודעים עליהם, יבוצעו לפני תחילת הפרוייקט. שינויי בעלוו על הפרק במהלך הפרוייקט יידחו לאחריו. מרווח נשימה ניהולי ישפר את איכות הפרויקט. מומלץ להטמיע את התובנה שיש להתכונן לתקופת "בצורת" פונקציונאלית. מרגע שפרויקט מתחיל, אין שינויים במערכת (אחרת – ראה סעיף 2).
5. לוודא שהמשאבים הנדרשים לביצוע הפרוייקט מוכנים בטרם תחילת הפרויקט (כ"א מיומן בכל המקצועות הנדרשים, ידע זמין, ספקים חיצונים, תשתיות והחלטות ניהוליות שחשוב לקבל לפני תחילת המרוץ) ומוקצים לפי הצורך, כולל גיבויי המשאבים בצווארי בקבוק.
6. לוודא שתוכניות ההסבה של הנתונים מהמערכת הישנה לחדשה וההחלטות הקשורות אליהן, הושלמו בטרם התחיל הפרוייקט.
7. לעלות לאויר בהינתן פונקציונאליות מינימאלית! (MVP) אמירה זו מטפלת בלוח הזמנים, גם בהעברת משקל המאמץ הארגוני למערכת החדשה והיא חשובה גם באספקטים של ניהול המשאבים וסיכויי ההצלחה. החלק השני של האמירה -שלאחר "גוש הפונקציונאליות" הגדול, הפרוייקט לא הסתיים, אלא ימשיך להתקדם בסבבים קצרים ויכנס לשגרת הפיתוח המנוהלת.
8. לנהל את ההטמעה באופן אקטיבי:
הכנה ושיתוף המשתמשים.
הדרכה שיטתית ובד"כ מומלץ TTT (Train The Trainer) כך שהמשתמשים בארגון לוקחים שותפים ואחריות.
ניהול מוקד התקלות לאחר הפעלת המערכת, הפעלת מנגנון תיעדוף, הקצאת משאבים לפתרון תקלות. ניהול מדיד של התקלות והשפעתם עם הקפדה על התכנסות ליעדים.
יש היקפים ויש היקפים...
יש מקרי קצה שכדאי גם להתייחס אליהם. לדוגמא - מקרה קצה אחד הוא שהמערכת משרתת ארגון ענק, כמו בית חולים גדול ורמת ההטמעה היא גבוהה (אלפים רבים של משתמשים). ראשית, במקרה כזה, יש לשאול שאלה אסטרטגית: האם נכון שכל הארגון עובד על אותה מערכת וכפוף לסט צווארי בקבוק אחד. בהנחה ויש לכך סיבה טובה, כדאי להוסיף 3 דגשים:
עקב הגודל, יש לפרק את הפרוייקט לחלקים בלתי תלויים ולהרכיב מבנה הפרוייקט בהתאם. תתי הפרוייקטים צריכים להיות בהיקף שהארגון יכול "לעכל" (שאפשר לסיים אותו בהתחשב בעקרונות הנ"ל).
סדר הפיתוח הוא קריטי יותר מארגונים קטנים ולכן החלקים המשותפים וההכרחיים לכל שאר חלקי הפרויקט הבאים אחריהם ותלויים בהם "יכבשו" ראשונים.
בין המערכת הישנה ומערכת החדשה יהיו ממשקים בזמן אמת אבל המאסטר הוא המערכת החדשה.
על דרך המשל
אם נשתמש במינוח צבאי, תקופת הזמן בה הארגון מחליף מערכת מידע מרכזית תהייה משולה למעבר בשטח השמדה שהמעבר בו הכרחי. כלומר, בזמן המעבר בתוואי שטח הזה, הכוח שלנו נמצא בנחיתות, כך שהוא פגיע מאד ויכולת התגובה שלו מוגבלת. תחשבו על מעבר הכרחי בנקיק צר.
עד הכניסה, לכאורה כל השטח פתוח. מה שמאפשר לנו לתכנן את המעבר באופן מסודר (כמו להשאיר כוח שמגן עלינו מתא שטח שולט). נמשיל זאת להתארגנות בטרם תחילת הפרויקט.
מרגע הכניסה, לכוח שנכנס אפשרויות הלחימה מוגבלות ביותר, עד לרגע היציאה. לכן נעשה מאמץ עליון לסיים את המעבר מהר, שהרי לא נרצה להמתין לאוייב או לשטפון. נמשיל זאת לצימצום מירבי של תכולת השלב הראשון של הפרויקט.
לא כל הכוח נכנס ביחד לשטח ההשמדה (בארגונים גדולים הקריטייות עולה) לכן נחלק את הכוח/הפרויקט.
כשזה המעבר היחיד, כל נסיון לעבור בדרך שאינה מובילה ליעד יאריך את הדרך לפחות פי 2. לכן נתכנן היטב ונעבור...
