ניהול שינויים (Change Management) היא שיטה (טכניקה) לניהול ובקרה של שינויים או שיפורים המוכנסים במערכת. שינויים מבוצעים לאורך כל שלבי מחזור חייה של מערכת, הן בשלבי האפיון והבניה והן בתקופת התחזוקה. המושג ניהול שינויים משיק למושג ניהול תצורה ונכון לומר שניהול שינויים היא אחת הטכניקות המשרתות ניהול תצורה. על ניהול השינויים ובקרתם מופקד צוות מיוחד בפרויקט או בארגון, הפועל לפי תהליך מוגדר וברור של (בקרת) שינויים.
ניהול שינויים (Change Management) היא שיטה (טכניקה) לניהול ובקרה של שינויים או שיפורים המוכנסים במערכת. שינויים מבוצעים לאורך כל שלבי מחזור חייה של מערכת, הן בשלבי האפיון והבניה והן בתקופת התחזוקה. המושג ניהול שינויים משיק למושג ניהול תצורה ונכון לומר שניהול שינויים היא אחת הטכניקות המשרתות ניהול תצורה. על ניהול השינויים ובקרתם מופקד צוות מיוחד בפרויקט או בארגון, הפועל לפי תהליך מוגדר וברור של (בקרת) שינויים.
קיצור של שינוי ושיפור. שו"ש הוא בקשה לשינוי, הוספה או ביטול של דרישה או יכולת מוגדרת ומוסכמת ברכיב אחד או יותר של מערכת. בדרך כלל מיועד השינוי להקנות יכולת חדשה או לשפר ביצועים או יכולת קיימת ברכיבי חומרה ותוכנה של מערכת. בין גורמי השינוי ניתן למנות:
· שינויי או"ש (ארגון ושיטות)
· שינויים עסקיים ומבצעיים
· בעיות שנתגלו בתכן
· בעיות תכן שאותרו בשלב התחזוקה
· תובנות שנרכשו עם הזמן
· שיפורים טכנולוגיים שהתפתחו מאז רישום דרישות המערכת המקוריות
ראוי לציין כי בעוד ששינוי שאושר מהווה דרישה חדשה או עדכון לדרישה קיימת, תקלה היא סטייה או חריגה מדרישה מוגדרת ומוסכמת (אפיון/ עיצוב/ סטנדרט).
מקובל להבחין בשתי קבוצות של שינויים:
כל שינוי המשפיע על תפקוד, צורה או התאמה ( Form, Fit & Function) של התוצר. מחייב אישור הלקוח.
שינוי מינורי של המבנה הטכנולוגי או שינוי באלגוריתם ואשר אינו משפיע על תפקוד התוצר, צורתו או דרישות ההתאמה שלו. שינויים אלה ניתנים ליישום גם ללא אישור הלקוח.
עקרונות התהליכים לניהול שינויים דומים במהותם בין אם הפיתוח והתחזוקה של המערכת מתבצעים על ידי גורמים פנים ארגוניים או אם נמסרו לביצוע על ידי ספק חיצוני או קבלן משנה. בפרק זה יוצגו העקרונות המשותפים. ההיבטים המיוחדים של שינויים בפרויקטים המבוצעים ע"י גורם חיצוני יפורטו בהמשך.
האחריות על ניהול השינויים מוטלת על מנהל הפרויקט. בסמכותו של מנהל הפרויקט להטיל את ניהול השינויים על גורם אחר מטעמו, אך אין הדבר גורע מאחריותו לנושא.
קיים הבדל בין בקשה לשינוי המוגשת בשלבי הפיתוח לבין זו המוגשת בשלב התחזוקה. בשלבי הפיתוח הבקשה לשינוי מטופלת "תוך כדי תנועה" ויש משמעות לעיתוי ולדחיפות שבו תטופל הדרישה. ככל שהשינוי יטופל ויאושר מוקדם יותר ניתן יהיה לעצור או לשנות, במידת הצורך, תהליכים הקשורים לשינוי ולהקטין את עלויות הפיתוח הנובעות מן השינוי והשלכותיו.
בשלב התחזוקה, לעומת זאת, אפשרי לצבור מספר בקשות לשינוי ולקבץ את תהליך אישורן ומימושן בהתאם לתדירות הפקת המהדורות או בהתאם לאירועים המחייבים מהדורה חדשה. לדוגמא סיום תמיכה של ספק במוצר/ תוכנת תשתית או חוק / תקנה הנכנסים לתוקף במועד קובע.
ניהול איכותי של שינוי מחייב בין היתר גם תיקונים בתיעוד המערכת. בשלב הפיתוח יש לדאוג לעדכון תיקי האפיון או העצוב בשינויים שאושרו כגון שינויי תהליכים, שדות מיון בדו"חות וכד'. בשלב התחזוקה יתועדו השינויים בתיק המערכת, המדריך למשתמש, תיק התפעול וכד'
התרשים שלהלן מגדיר תהליך אופייני לניהול שינויים בפרויקט / מערכת:
ייזום בקשה לשינוי יכול להיות בכל שלב במחזור חיי המערכת ע"י כל גורם רלוונטי:
· משתמשים/לקוחות כתוצאה משינויי צרכים, שינוי חוקים, שינוי של או"ש, הפקת לקחים, שינויים עסקיים / מבצעיים וכו'.
· צוותי הפיתוח האורגניים או אצל ספקים חיצוניים - כתוצאה מתובנות חדשות או זיהוי אילוצים / חידושים טכנולוגים רלוונטיים. ראוי לציין כי ההתייחסות לבקשת ספק ל- Waver (הצעה לפתרון זמני, ביטול או דחייה במועד הספקה של תוצר או טובין המהווה דרישת מערכת) תהיה כאל בקשה לשינוי לכל דבר ועניין, והטיפול בה יעשה לפי השיטה שנקבעה לניהול שינויים.
עם קבלת בקשה לשינוי (RFC - Request For Change) ימלא נציג צוות הפיתוח או התחזוקה טופס בקשה לשינוי (ראה פרק תוצרים להלן) באמצעות טופס יעודי או באמצעות כלי ממוכן. הבקשה חייבת לכלול את מירב הנתונים על מנת שיהיה בידי מקבלי ההחלטות מספיק נתונים לדון בבקשה.
לאחר מילוי הנתונים הנדרשים, ניתן לקבוע את המסלול לטיפול בבקשה בהתאם לנוהלי הארגון. בדרך כלל יהיה בסמכותו של מנהל הפרויקט לאשר שינויים המתואמים עם הלקוח במידה ואינם סותרים דרישות אחרות של המערכת או שלא יגרמו לחריגה מלו"ז הפרויקט ותקציבו. בכל מקרה אחר, יובאו בקשות השינויים בפני ועדת שינויים.
שינויים בפרויקטים המבוצעים ע"י ספק חיצוני, אשר צפויים לגרום לחריגה מתקציב הפרויקט או מלוח הזמנים שנקבע, יחייבו אישור של ועדת ההיגוי או פורום ניהולי של הפרויקט אשר ידונו בבקשות במתכונת ועדת שינויים ויפעלו להרחבת ההסכם עם הספק באמצעות הגורמים המורשים. בפרויקטים המנוהלים בצה"ל למשל, הגורם המורשה להתקשרות הוא משרד הביטחון.
בקשה לשינוי תעלה בפני ועדת שינויים (CCB - Change Control Board) אשר תורכב ממגוון מומחים שייצגו את האספקטים השונים של הפרויקט:
· מהנדס מערכת
· מומחי יישום
· אנשי תשתיות
· מנהל הפרויקט
· אנשי תפעול
· נציג אבטחת איכות
· משתתפים אחרים אשר יזומנו לפי צורך
תפקידה של הועדה לדון בפרטי בקשות השינויים, לבדוק ולנתח את הממצאים והמשמעויות ולקבל החלטות לגבי המשך הפעילות. לדוגמא:
· לקבל את השינוי במלואו ולהורות על מימושו.
· לקבל חלק מהשינוי או להורות על ביצוע הבקשה תוך דחייה של חלקים שונים בפרטיה.
· לדחות את הבקשה במלואה.
· לבקש להביא בפני הועדה פרטים נוספים על הבקשה
· להטיל על גורמים מקצועיים לבצע אימות של נתונים
· לדחות את ביצוע השינוי לגרסאות הבאות
· לתעדף את השינויים המאושרים לביצוע
· החלטות אחרות
תוצאות החלטות הוועדה יסוכמו ויתועדו.
במסגרת גיבוש תוכנית הפיתוח והאיכות, לאחר אישור הפרויקט, יוגדרו סמכויות ועדת השינויים ותחומי פעילותה:
· באיזה סדרי גודל של שינויים אמורה הועדה לטפל (היקף לו"ז ותקציב)?
· אילו החלטות רשאית הועדה לקבל?
· תדירות התכנסותה של הועדה
· שיבוץ שינויים למהדורות הבאות.
· מסגרת תקציבית – הסמכויות התקציביות שבמסגרתן יש לוועדה סמכות לאשר שינויים. כמו כן, יש לקבוע האם לוועדה יש סמכות לבצע חריגות תקציביות? ובאילו סדרי גודל?
· לוחות זמנים: במקרים בהם יש לשינויים השפעות על לו"ז הפרויקט, מה הן סמכויות הועדה לאשר שינויים שעלולים לגרום לשינוי בתוכנית העבודה או לחריגות בלו"ז?
· קביעת עדיפויות לביצוע השינויים
· קביעת תכולת השינוי
לאחר תהליך אישור השינויים ע"י הגורמים המתאימים, נדרש לבצע תהליך של תיאום צפיות מול הלקוח או מומחה היישום. בתהליך זה יש לסקור את רשימת השינויים שהועברו כבקשות לביצוע ולהציג את הסטטוס שהוחלט לגבי כל שינוי תוך הצגת נימוקים והסברים. בסופו של תהליך, חייבת להתקבל תמונה ברורה, חד משמעית, מאושרת ומקובלת ע"י שני הצדדים לגבי מכלול השינויים שעומדים על הפרק ולגבי המשך הפעילויות המאושרות לביצוע.
המשך הטיפול בשינויים המאושרים יתבצע בהתאם למנגנוני הפיתוח הקיימים בארגון (אפיון, עיצוב, בנייה, בדיקות מערכת וכו').
מנהל הפרויקט יתחזק את רשימת השינויים (ראה דוגמא לתבנית ניהול שינויים בפרק תוצרים להלן) אשר תהווה בסיס לדיוני ועדת השינויים ותתעדכן מעת לעת. עבור כל שינוי ישמרו הפרטים הבאים:
· מס' מזהה
· מהות השינוי
· משאבים עיקריים (כ"א, תקציב)
· סטאטוס השינוי: אושר, אושר חלקית או נדחה, טרם הוחלט
· עדיפות
· מהדורה למימוש
פרויקטים אשר מבוצעים באמצעות ספק או גורם חיצוני לארגון מתנהלים על בסיס הזמנה המגדירה, בין היתר, מסגרת תקציבית ומסמכים חוזיים המגדירים את תכולת העבודה (ראה קיט SOW של הפרויקט בכרך זה). מאחר ולשינויים הנדרשים במהלך הפרויקט יש בדרך כלל השפעה על מחיר הפרויקט ולוחות הזמנים, מנגנון ניהול השינויים בפרויקטים כאלה חייב להיות מובנה כך, שהגורמים המוסמכים בארגון להוציא הזמנה או הרחבה להזמנה יהיו שותפים לתהליך. בפרויקטים המבוצעים עבור צה"ל לדוגמא, משתתף נציג משרד הביטחון בועדת ההיגוי או פורום פרויקט המתפקדים, בין היתר, כוועדת שינויים (CCB) לכל דבר ועניין.
בפרויקטים המתנהלים מול ספק חיצוני יכלול מסמך ה- SOW פרק המגדיר את תהליך אישור, ניהול והזמנת השינויים בין אם ניזום השינוי ע"י המזמין או ע"י הספק. היות ואין כמעט פרויקט שאין בו שינויים, מומלץ להגדיר מראש משאבים לביצוע שינויים בהיקף מסוים ללא צורך בהרחבת ההזמנה. לפרטים נוספים ראה דוגמא לפרק השינויים במסמך SOW בלשונית תוצרים להלן.
טופס הבקשה מכיל נתונים רבי חשיבות והכרחיים להמשך התהליך בהיותם בסיס הנתונים לקבלת ההחלטות לגבי עתידם של השינויים.
אם הלקוח הוא יוזם השינוי, לא חלה עליו חובת מילוי נתונים אלה, אלא אם כן, יש ביכולתו לתרום מידע. אם מקור השינוי הוא ביוזמת הצוותים הטכניים, גם כשהפיתוח או התחזוקה מבוצעים ע"י גורם חיצוני, עליהם למלא את הטופס תוך ציון האם אלה הן הערכות ראשוניות בלבד או הערכות לאחר בדיקה מדוקדקת.
רשימה מרכזת של השינויים בפרויקט/מערכת. לרשימה מועברים פרטים עיקריים של השינוי כגון:
· מהות השינוי
· משמעות מבחינת כוח אדם, תקציב ולוחות זמנים
· עדיפות הביצוע
· סטאטוס השינוי
· מהדורה למימוש