להלן רשמים ראשוניים ממפגש שולחן עגול בנושא ניהול שינויים.
התמונה הכללית שעולה היא שארגונים מקיימים תהליך מסודר של ניהול שינויים – תאום השינוי, בדיקה לגבי השפעות השינוי, דרכים לביצוע failback וכד'. אצל רובם של הארגונים התהליך מתבצע באמצעות מערכת ממוכנת.
אולם, אצל רובם המכריע של הארגונים, כל שינוי מתבצע בצורה פרטנית ללא הסתכלות מערכתית וללא הסתכלות על היסטוריה. לכן ישנם מקרים של תקלות בעייתיות – לדוגמה אחד הלקוחות תאר מצב בו הורד קו גיבוי של תקשורת והסתבר שאחת האפליקציות בייצור הפסיקה לעבוד.
בגדול, לקוחות התייחסו ל-4 סוגים של בעיות (חלקן קשורות) במצב הנוכחי:
1. התייחסות למשאבים – אין התייחסות כוללנית למשאבי ה-IT לדוגמה, אין רישום מרכזי של "באיזה שטחי דיסק משתמשת אפליקציה X" או לחילופין "איזה אפליקציות יושבות על דיסק Y". לעיתים מידע זה נמצא אבל בתור יוזמה פרטית \ שיטת ניהול של מנהל המשאב (בדוגמה שציינתי – מנהל האחסון).
2. כאשר ישנה תקלה, קשה לזהות את מקור התקלה כלומר ישנה בעיה של Problem determination או root cause analyses .
3. בעיה שקשורה לבעיה הקודמת – אם מסתמכים על הזנה ידנית של מהות השינויים והקינפוג, טעות או פיספוס בהזנה יגרום לכך שזיהוי תקלה יהיה כמעט בלתי אפשרי. לדוגמה אם מתקינים switch חדש ברשת אבל טועים בהזנת כתובות ה- IP, המשתמשים יעבדו ללא בעיה אבל ברגע של תקלה לא ידעו כלל כיצד להתחיל לטפל כי לא מכירים כלל את כתובות ה- IP.
4. גם אם יש תיעוד של הפרטים הטכניים אצל (לדוגמא) איש האחסון או איש האבטחה, בזמן תקלה לא ניתן להגיע לתיעוד זה ולהשתמש בו.
5. ישנן גם בעיות נוספות שפחות הוזכרו בסיטואציה של ניהול שינויים - capacity planning , עמידה ברגולציה מבחינת רשיונות תוכנה, DRP וכד'.
תחת תמונה זו רצוי לציין לטובה את ה"ארגון הפיננסי" שמופיע לקראת סוף הסיכום, ואשר פיתח מערכת ייחודית לסביבת ה- OPEN שבה ישנו רישום כולל של כל המאפיינים הנדרשים של "עץ המערכות" בארגון עם workflow מלא לביצוע השינויים האפליקטיביים והתשתיתיים. בארגון מתקדם זה כל השינויים נרשמים ונשמרים במקום אחד.
לקוחות רבים מצפים להטמעה של סביבת CMDB אשר גם תנהל את השינויים בצורה אחודה וגם תוודא את ביצוע השינויים. לדוגמה, אם מחליטים לפתוח PORT ב- FireWall מסוים, השינוי יופיע במערכת ולאחר מכן המערכת תוודא שהשינוי אכן התבצע כאשר התועלת העקרית שלקוחות מצפים מסביבת CMDB היא שבזמן תקלה ניתן יהיה בקלות לאתר את המקור.
התמונה הכללית שעולה היא שארגונים מקיימים תהליך מסודר של ניהול שינויים – תאום השינוי, בדיקה לגבי השפעות השינוי, דרכים לביצוע failback וכד'. אצל רובם של הארגונים התהליך מתבצע באמצעות מערכת ממוכנת.
אולם, אצל רובם המכריע של הארגונים, כל שינוי מתבצע בצורה פרטנית ללא הסתכלות מערכתית וללא הסתכלות על היסטוריה. לכן ישנם מקרים של תקלות בעייתיות – לדוגמה אחד הלקוחות תאר מצב בו הורד קו גיבוי של תקשורת והסתבר שאחת האפליקציות בייצור הפסיקה לעבוד.
בגדול, לקוחות התייחסו ל-4 סוגים של בעיות (חלקן קשורות) במצב הנוכחי:
1. התייחסות למשאבים – אין התייחסות כוללנית למשאבי ה-IT לדוגמה, אין רישום מרכזי של "באיזה שטחי דיסק משתמשת אפליקציה X" או לחילופין "איזה אפליקציות יושבות על דיסק Y". לעיתים מידע זה נמצא אבל בתור יוזמה פרטית \ שיטת ניהול של מנהל המשאב (בדוגמה שציינתי – מנהל האחסון).
2. כאשר ישנה תקלה, קשה לזהות את מקור התקלה כלומר ישנה בעיה של Problem determination או root cause analyses .
3. בעיה שקשורה לבעיה הקודמת – אם מסתמכים על הזנה ידנית של מהות השינויים והקינפוג, טעות או פיספוס בהזנה יגרום לכך שזיהוי תקלה יהיה כמעט בלתי אפשרי. לדוגמה אם מתקינים switch חדש ברשת אבל טועים בהזנת כתובות ה- IP, המשתמשים יעבדו ללא בעיה אבל ברגע של תקלה לא ידעו כלל כיצד להתחיל לטפל כי לא מכירים כלל את כתובות ה- IP.
4. גם אם יש תיעוד של הפרטים הטכניים אצל (לדוגמא) איש האחסון או איש האבטחה, בזמן תקלה לא ניתן להגיע לתיעוד זה ולהשתמש בו.
5. ישנן גם בעיות נוספות שפחות הוזכרו בסיטואציה של ניהול שינויים - capacity planning , עמידה ברגולציה מבחינת רשיונות תוכנה, DRP וכד'.
תחת תמונה זו רצוי לציין לטובה את ה"ארגון הפיננסי" שמופיע לקראת סוף הסיכום, ואשר פיתח מערכת ייחודית לסביבת ה- OPEN שבה ישנו רישום כולל של כל המאפיינים הנדרשים של "עץ המערכות" בארגון עם workflow מלא לביצוע השינויים האפליקטיביים והתשתיתיים. בארגון מתקדם זה כל השינויים נרשמים ונשמרים במקום אחד.
לקוחות רבים מצפים להטמעה של סביבת CMDB אשר גם תנהל את השינויים בצורה אחודה וגם תוודא את ביצוע השינויים. לדוגמה, אם מחליטים לפתוח PORT ב- FireWall מסוים, השינוי יופיע במערכת ולאחר מכן המערכת תוודא שהשינוי אכן התבצע כאשר התועלת העקרית שלקוחות מצפים מסביבת CMDB היא שבזמן תקלה ניתן יהיה בקלות לאתר את המקור.
אין תגובות:
הוסף רשומת תגובה