כיצד לפתח תוכנית ניהול שינויים ב- IT?
תוכנית ניהול שינויים (CMP), הידועה יותר בשם תהליך בקרת שינוי או תהליך ניהול בקרת שינויים, היא תהליך רשמי המשמש להבטחת שינויים במוצר או במערכת מוחדרים בצורה מבוקרת ומתואמת (כהגדרתה ב- ISO 20000). אין לבלבל בין CMP לבין ניהול שינויים ארגוניים (OCM), המנהל את ההשפעות של תהליכים עסקיים חדשים, כולל אלה הנובעים מהסדרת מערכות ויזמות IT, שינויים במבנה הארגוני או שינויים תרבותיים בארגון. בקיצור, OCM מנהלת את הצד האנשי של השינוי.
מטרת ה- CMP היא להבטיח שההשפעה השלילית של שינויים במערכת טכנולוגיית המידע של החברה תהיה ממוזערת באמצעות תהליך סטנדרטי של ממשל. חלק מהשינויים אינם אופציונליים. אם, למשל, תקן הברקוד משתנה, עליך להסתגל; אם משתנה מבנה הלנת מס, עליך לשנות. עם זאת, כל השינויים מסוג זה עדיין כפופים לממשל.
לעולם לא יכול להיות שנעשים שינויים אד-הוק במערכת או בהליכים ללא פיקוח מסוים. רעיון זה חייב להיות מקורו של ההנהלה הבכירה ולהעבירו, ללא יוצאים מן הכלל, לכל מי שבחברה. ללא גיבוי ברמה הגבוהה ביותר, ה- CMP הוא בזבוז חסר תועלת של זמן וכסף. עם גיבוי נכון, תוכנית זו תחסוך את החברה מכמה טעויות יקרות מאוד.
- 1פתח בקשה לשינוי (RFC): הדבר עשוי לנבוע מניהול בעיות בו מזהים בעיה, או סדרה של נושאים קשורים, ויש צורך בשינוי מקלה בכדי למנוע (או למזער) השפעות עתידיות. מקור ה- RFC עשוי להיווצר גם כתוצאה מהחלטה עסקית שתדרוש שינוי מסוים (הוספה, מחיקה, שינוי) בטכנולוגיה התומכת. RFC עשוי להיות נחוץ גם בגלל השפעות חיצוניות (כלומר תקנות ממשלתיות או שינויים שנעשו על ידי שותפים עסקיים).
- 2השגת קבלת שינוי עסקי: ההחלטה לבצע שינוי היא בדרך כלל החלטה עסקית בה משקללים עלויות לעומת תועלות. גם במצבים בהם השינוי מכוון בתשתיות בלבד (כשל ברכיבים או במערכת) ההחלטה להוציא כסף היא של העסק, ולא של מחלקת ה- IT. יש מקרים שבהם פותחו נהלים מראש לאישור שינויים כגון תחזוקת מערכת חירום, אך ללא קשר למועד האישור, ההחלטה עדיין מוטלת על הנהלת העסק.
- 3יזמו את פרויקט הפיתוח: פיתוח השינוי (כולל בדיקות) הוא פונקציה מונחית IT. במקרה של שינוי חירום (השרת אינו פעיל) פונקציות אלה נקבעות בדרך כלל מראש. כאשר יש לפתח מערכת חדשה, יש מאמץ שיתופי בין המשתמשים העסקיים לבין צוות ה- IT. המערכות תוכננו על ידי IT, התכנון מאושר על ידי השותפים העסקיים (משתמשים), שפותח על ידי IT, נבדק על ידי שילוב של IT והמשתמשים, והמוצר הסופי מאושר על ידי שניהם. יש לשים לב בזהירות להשפעות הנלוות לשינוי החדש על מערכות קיימות.
- 4עברו בשער ניהול השינויים: הוועדה המייעצת לשינויים (CAB) בודקת את כל השינויים לפני שניתן יהיה לייצר אותם. בדרך כלל, ה- CAB יורכב מקבוצת אנשים עם נקודות מבט שונות, רקעים ותחומי התמחות שונים. תפקידם לבדוק את השינוי מנקודת מבט של תהליכים וממשל בכדי להבטיח כי אותרו והופחתו כל הסיכונים הצפויים, וכי קיימות טכניקות פיצוי לכל גורמי החשיפה (דברים שעלולים להשתבש). צוות הפיתוח וספונסר השינוי יציגו את השינוי בפני ה- CAB. הערכת הסיכון תהיה במוקד. אסטרטגיות יישום, תקשורת לבעלי העניין המושפעים, תכניות גיבוי וניטור לאחר היישום הם אלמנטים עליהם נדרש CAB להתמקד. ה- CAB לאאחראי לקבוע אם השינוי מתאים - החלטה זו כבר התקבלה. ה- CAB גם לא אחראי לקבוע אם השינוי הוא חסכוני. שוב, זו בהחלט החלטה עסקית.
- 5יישם את השינוי: אם ה- CAB לא מאשר את השינוי, הסיבות מפורטות (זה תמיד בגלל שסיכונים מסוימים לא הוקלו או שלא תוכננו תקשורת) ולצוות הפיתוח יינתן זמן לתקן את הבעיות ולתזמן פגישה לפני CAB.. אם השינוי אושר, היישום מתוזמן. זה בדרך כלל לא המקרה שה- CAB מיוצג ביישום, אם כי ייתכן שחלק מחברי ה- CAB הם בעלי מומחיות הדרושה במהלך היישום, אך הם לא יהיו נציגים רשמיים של CAB אלא כמומחים בנושא (SME). אופן יישום השינוי, רשימת הבדיקה והצעדים מוגדרים מראש והוצגו בפני ה- CAB ואושרו. יש לתעד היטב את התהליך כולו ולעקוב במדויק אחר התהליך שאושר.
- 6דווח על התוצאות: או שהשינוי יושם בהצלחה ללא בעיות, השינוי בוצע עם בעיות שתוקנו במהלך היישום, השינוי בוצע עם סוגיות שנחשבו כמקובלות, התעוררו סוגיות שלא היו מקובלות והשינוי הוחזר לאחור, או במקרה הגרוע ביותר, השינוי יושם עם בעיות לא מקובלות ולא ניתן היה להחזירו לאחור. תהיה התוצאה אשר תהיה, זה מתועד ומוחזר ל- CAB. CAB אחראי אז להפצת המידע לבעלי העניין ולאחסון ותחזוקת התוצאות במערכת ניהול השינויים (שעשויה להיות בסיס נתונים אוטומטי או מערכת תיוק נייר., אך יש לשמור על המסמכים למטרות ביקורת).
- 7קשר ניהול בעיות לשינויים: יש להשוות בין נושאים המתעוררים לתיעוד ה- CAB של שינויים, כך שניתן יהיה לבודד את כל ההשפעות השליליות הבלתי צפויות של שינוי. לעיתים קרובות לא מבחינים באופן מיידי בהשפעות לא רצויות של שינוי, אלא מזוהים על ידי הופעתן של בעיות במערכות נלוות. לדוגמא, הוספה של מספר שדות למסד נתונים עשויה שלא להשפיע לרעה על המשתמשים באופן ישיר, אך יכולה להשפיע על ביצועי הרשת שברור למשתמשים אחרים שאינם מעורבים ישירות במערכת המתוקנת.
- 8ביקורת מעת לעת על ה- CMP: צריך לבצע לפחות אחת לשנה ביקורת על ה- CMP כדי להבטיח שכל תיעוד השינויים נשמר וזמין. יש לבחון כל מסמך אישור שינויים בכדי להבטיח כי החתימות המתאימות קיימות וכי תוצאות היישום מתועדות כהלכה.
- יש לאשר מראש תחזוקה תקופתית סטנדרטית. אם מדובר בתהליך רגיל להפעלת שרת מחדש ביום ראשון בבוקר בשעה 2:00 לפנות בוקר, אין צורך להגיש RFC בכל פעם, אך יש לאשר את התהליך מראש.
- תחזוקת אד-הוק חייבת לדבוק ב- CMP. כלול דברים כמו בדיקת מערכות כיבוי אש, ניקוי רצפות משנה במרכז הנתונים, בדיקת HVAC ובדיקה ואפילו תחזוקת הדברה. יש חברות שמרחיקות לכת דורשות RFC אם מחליפים נורה במרכז הנתונים (הסולם נפל ופגע ברשת).
- הנהלים צריכים להיות כפופים לניהול שינויים. אם חל שינוי בתזמון גיבוי המערכת, זה חייב לעבור דרך ניהול שינויים. ניתוח כל שינוי מכל סוג שהוא (מערכת או הליך) כדי לקבוע אם קיים סיכון אפשרי כלשהו.
- במערכות בוגרות בהן השינויים שגרתיים יותר, ייתכן שבדיקת ה- CAB תתבצע באופן אלקטרוני בכך שחברי ה- CAB "יאשרו" או לא יאשרו את היישום. זה יכול להפחית את הצורך בפגישות יקרות, מכיוון שאין שינויים חריגים הקשורים ליישום הקרוב.
- סובב את חברי ה- CAB בתדירות גבוהה. קיום תמיד של אותם חברים יכול להוביל למועדפות, וזה יכול להוביל לשחיקה. אתה רוצה ש- CAB שלך יהיה טרי, ישים לב ולא יהיה נתון להשפעות פוליטיות מבחוץ.
- פוליטיקה יכולה לעיתים קרובות להפריע ל- CAB. "שינוי זה נדרש" יכול להיות נכון, אך יכול להיות שהוא גם סדר יום אישי של אחד הבכירים. הנבדק חייב להיות האולטימטיבי סמכות לקבל החלטות על יישום.
שאלות ותשובות
- האם עלי לבנות תוכנית לפיתוח תוכנית ניהול שינויים ב- IT? האם יש כבר אחד כזה? ואם עלי לכתוב את הקוד, באיזו שפה עלי להשתמש?
- כמה זמן לוקח ליצור תוכניות לניהול שינויים ב- IT?
תגובות (1)
- עזר לי לקבל הבנה ראשונית של CMP. מקום טוב להתחיל בו.