תמונת המצב של ניהול שינויים

להלן תמונת המצב של ניהול שינויים בישראל אצל ארגונים מובילים. בעקרון, מי שאחראי על השינוי ועל הפצת התוכנה שנגזרת ממנו הוא מנהל הפרוייקט. מעבר לכך בארגון נמצא בדרך כלל גם מנהל השינויים שהוא גוף שאחראי על כל השינויים גם יחד (לעיתים הוא גם מנהל התפעול). מנהל הפרוייקט דואג לביצוע כל הבדיקות הנדרשות (QA כולל load test אם נדרש) ודואג לכל האישורים הנדרשים (אבטחת מידע...). ישנו טופס של השינוי שכולל את הדרישות מכל מי שמעורב בשינוי. לדוגמה, להחליף את ה- DLL אצל המשתמשים מסוג X ולפתוח את הפורט הספציפי ב- FW וכד'. לעיתים הטופס הוא ידני ולעיתים ממוחשב ברמה כזו או אחרת. לדוגמה, לעיתים הצהרה על "דרגת סיכון" של השינוי. ואז ה- flow של הטופס משתנה. אחד הנושאים שמטופלים בטופס הוא סיטואציה של roll-back במידה והשינוי לא מצליח. יש לציין שחלק אינטגרלי מהטיפול בשינוי הוא צוות השליטה והבקרה שצריך לדאוג לכך שה- agents יותקנו עם ספים מתאימים ושהתמונה העסקית שמתקבלת בקונסול רלוונטית.
כמו כן מתבצעת בארגון ישיבת שינויים שבועית או פעמיים בשבוע שבה דנים בשינויים שאמורים להתבצע וגם דנים בשינויים שהתבצע קודם ומסיקים מסקנות.
כל השינויים בייצור חייבים לעבור תהליך מסוג זה. זאת תמונת מצב קיימת אצל ארגונים רבים בישראל – אנחנו בטוחים שגם בבנק הפועלים.
סוגיה לא פשוטה שקשורה לסיטואציה זו היא טיפול בתקלות חומרה. תקלות חומרה מחייבות טיפול מיידי ולעיתים מתבצעים שינויים בייצור ללא מילוי של הנוהל וגם לעיתים קשר חומרה מתקלקלת ומחליפים אותה בחומרה זה, ישנה גישה שטוענת ששום דבר לא השתנה ולכן אין מה לדווח מבחינת ניהול שינויים.