מודלים או מתודולוגיות לניהול פיתוח מחלקים את הידע הנדרש לפיתוח מוצר לתחומים. כל תחום מכיל פרקטיקות עם ידע מפורט, המדריך כיצד לעשות את התהליכים השייכים לאותו תחום. תהליכי פיתוח המוצר מחולקים לקוביות, כאשר ידע המצטבר, נאסף במסמכים וסיכומי פגישות. תפוקות של תחום אחד הן תוצרים המשמשים כתשומות לתחום הבא אחריו ברצף היצירה של המוצר. כדי להמחיש, את התחומים מציירים כקוביות, ואת התוצרים העוברים בין התחומים מציירים עם חיצים.
למשל: מחזור תהליך פיתוח מוצר, מחולק לקוביות כדלהלן, כאשר החיצים הם התוצרים שעוברים משלב לשלב:
ציור 1 – מחזור חיי פיתוח מוצר
החלוקה לריבועים, וההנחה שהתהליך זורם ברצף נוחות כדי להסביר את שיטת העבודה. אולם המציאות אינה מסתדרת בריבועים, והמידע אינו זורם מצד אחד לצד שני בסדר מופתי. ניסיונות לחלק כל ריבוע לחלוקות משנה, ועוד חלוקות משנה, בתוספת חיצים המתארים תשומות ותפוקות בין תהליכי המשנה – גם הם לעולם לא יתארו את המצב לאשורו. בשטח, חלק מהתהליכים מתנהלים במקביל, ישנם בעלי עניין רבים, המשפיעים או מושפעים מכל פעילות שקורית, ובנוסף – ישנו ידע וניסיון רב של הנפשות הפועלות,המשפיעות על זרימת המידע וביצועי הפרויקט.
אחד האמצעים לתאר תהליך פיתוח מוצר מקצה לקצה הוא תהליך כולל הנקרא "ניהול מחזור חיי פיתוח מוצר" – Product Life Cycle Management (PLCM), הכולל את הרכיבים הבאים:
כיוון שהכלים הקיימים לתאר תהליכים הם מסמכים, האתגר הגדול הוא לתאר את המציאות המורכבת בשני מימדים בלבד באמצעות טבלאות ואיורים המכילים ריבועים, חיצים וכדומה.
תיעוד כולל של תהליך ניהול פיתוח מוצר מורכב מהאלמנטים הבאים:
לכל שלב, מתוארים הפרטים הבאים:
כדי לפשט את התהליך ככל שניתן מחד, ומאידך לפרט מה נדרש לעשות בפרטי פרטים, המלצתנו היא לוותר על ציור סיזיפי של תרשים התהליך, ולייצר טבלה אחת כוללת המפרטת את כל הפעילויות ובעלי העניין. הטבלה אמנם גדולה, אך ברגע נתון, משתמשים במספר שורות (המייצגות תהליכים) מאד מצומצם.
התהליך מתאים לחברות אשר להן לפחות אחד מהמאפיינים הבאים:
בחברות אלה, תהליך ניהול המוצר הופך להיות השפה המשותפת, באמצעותה מנהלים ומתאמים התחייבויות פנימיות ומספקים תוצרים ותוצרי ביניים.
דוגמאות לחברות המשתמשות בניהול מחזור חיים כולל: מוטורולה, מלנוקס, נייס, קומברס ואחרות.
מדוע פרויקטים מצליחים? שאלת מיליון הדולר. אם היינו יודעים את התשובה, היינו יודעים לחזור על ההצלחה שוב ושוב. ואיך בכלל מודדים הצלחה? כשמחפשים בגוגל – הצלחה בניהול פרויקטים או כישלון בניהול פרויקטים – מקבלים מאות אלפי התייחסויות. אין ספק, נושא מאתגר שמעניין רבים; חידה בלתי מפוצחת, בינתיים.
בדרך כלל אנחנו רגילים לחשוב במונחים של השגת יעדים, סיום מוצלח, אירוע שיא, ניצחון; יש המגדירים הצלחה כהיפך מכישלון. כלומר: אם הפרויקט לא נכשל סימן שהצלחנו. משום מה, כישלונות הם מאד ברורים. ההצלחה – יותר חמקמקה.
ארגון שמודד לאורך זמן את הצלחות או אי הצלחות הפרויקטים שלו במונחים כמותיים, יכול ללמוד על היכולות האמיתיות שלו. כתוצאה מכך, התכנון וההתחייבויות של הפרויקטים החדשים הינם מדויקים יותר. הכרת היכולות האמיתיות מאפשרת גם לחשב החזר על השקעה לפני שנכנסים להתחייבות על פרויקט, ואף להחליט שלא נכנסים להרפתקה לא מוצלחת חדשה.
מנהלי פרויקטים וצוותי הפרויקט – רוצים לדעת מה חשוב לארגון, כיצד מודדים אותם, ואיך עליהם לתעדף את המשימות שלהם. יש ארגונים בהם הכי חשוב לעמוד בלו"ז, גם במחיר חריגות בתקציב. תעדוף שכזה יבוא לידי ביטוי במדדים. משוב על הצלחה, מאפשר לקבל הכרה ולהמשיך להשתפר מפרויקט לפרויקט.
מאד חשוב להגדיר מהו פרויקט מוצלח. חשוב לא פחות, להגדיר בצורה רחבה. לא מספיק רק לסיים בזמן, בתכולה ובתקציב, אלא לעמוד באוסף של יעדים שמודדים מכלול של מטרות, ולאורך זמן. מדידה לאורך זמן היא חשובה ביותר, כיוון שבמקרים רבים מנהלים מביאים את הפרויקט שלהם לקו הסיום, קוצרים את פירות ההצלחה, ועוברים לפרויקט אחר שמחים וטובי לב. למעשה רק במימד הזמן אפשר למדוד הצלחה אמיתית. נניח שפרויקט עמד ביעדי הזמן, תכולה ותקציב – ולאחר זמן מתברר שהלקוחות לא מרוצים מהתכולה, או מהאיכות, וכדומה – מה קורה? תוצאות אי-ההצלחה מחושבות במקום אחר – או שמקימים פרויקט או גרסאות המשך, שעיקר מטרתם היא לעשות את מה שהיה באמת צריך לעשות הפרויקט המקורי, או שארגון אחר (תמיכה למשל) מטפל בתיקונים, או כל פיתרון יצירתי אחר. התקציב של פרויקטי ההמשך לא נחשב כחריגה בתקציב הפרויקט המקורי; משימות התיקון החדשות מנוהלות בגאנט אחר של גרסה חדשה, כך שחריגה מלו"ז הפרויקט המקורי – גם היא אינה מורגשת.
כל מי שמנהל פרויקט, או מנהל קבוצת פרויקטים מחפש תוצאות כמותיות; אוסף מדדים מספריים. באמצעות המדדים אפשר לראות האם הפרויקט עמד בתוצאות המתוכננות. המטרה המרכזית של המדידה היא הפקת לקחים ושיפור, לקראת הפרויקטים הבאים.
רוב התוצאות נמדדות בצורה רציפה, סקלה של ערכים, ולא שחור/לבן, עמד/לא עמד. לכן, גם כאשר פרויקט עמד בהצלחה במדדים שלו, עדיין ניתן להמשיך ולהרים את הרף – לשפר עוד את התוצאות.
כאמור, המדידה היא תלוית ארגון, ותלויה במטרות הספציפיות של הארגון. תמיד נחפש מדדים אובייקטיבים, שאינם תלויים בפרשנות סובייקטיבית של המודד או הנמדד. מדד טוב הוא מדד שמעורר השראה, כך שעמידה מוצלחת בו מקדמת את הפרויקט, והיא למעשה מתואמת עם המטרות הכלליות של הארגון. נראה ברור…אך לא תמיד מקוים. אמחיש באמצעות דוגמה: בארגון מסוים בודקים את יעילות ביצוע הסקירות במדדים מעיקים: כמה זמן השקיעו אנשים בקריאת מסמכים לפני הסקירה? כמה באגים לדף נמצאו וכדומה. כדי למדוד מדדים אלה, צריך לדווח על מספר העמודים במסמך הנסקר, מספר השעות שהושקעו מראש בקריאת המסמכים, מספר הדפים שנסקרו בפגישה אחת וכדומה. כיוון שהמדד מעיק – אנשים מדווחים בכעס מספרים אקראיים.
הכי בסיסי – מדדי "השילוש הקדוש" בניהול פרויקטים: לו"ז, תכולה ותקציב; שיעור חשוב שלמדתי והריהו לפניכם – לא לסגור פרויקט בתאריך הסיום שלו, אלא להמשיך את כל הפעילויות הקשורות אליו, על אותו גאנט, אותו תקציב ואותה רשימה של דרישות/תכונות ממנה נבנה הפרויקט המקורי. כך ניתן יהיה למדוד את הביצועים האמיתיים של הפרויקט.
מדידת התכולה – קריטית ביותר להצלחת הפרויקט; כדי להצליח במדידה זו, חשוב להבין את דרישות הלקוח או הלקוחות, ולקבל את אישורם על התכולה המתוכננת.
תכנון הלו"ז –מושפע מצורכי הלקוחות, או הארגון מבחינת Time-to-Market; קשה יותר להצליח בפרויקט עם לו"ז צפוף.
הצלחה בשלושת המדדים הקלסיים היא קריטית. בדרך כלל, חריגה במדד אחד, גוררת גם חריגה בשאר המדדים, כתוצאה ממאמץ לחזור למסלול. מאמץ זה דינו – הזזת לו"ז, או חריגה בתקציב, או שינוי תכולה, או שילוב של גורמים אלה.
מדידת מדדים אלה – תיעשה באופן יחסי, באחוזים, כדי שנוכל להשוות פרויקטים בגדלים שונים.
מדידת שביעות רצון הלקוחות הינה בסיסית, ונחשבת לאחת מדרישות החובה של תקן 9001 ISO ; רצוי ביותר למדוד את שביעות רצון הלקוח במהלך הפרויקט (שיתופו באבני דרך והתייחסות למשוב ממנו), בסוף הפרויקט (האם התוצר לשביעות רצונו), ותקופתית לאחר סיום הפרויקט, כדי לבדוק את שביעות רצונו מהמוצר או השירות, לאורך זמן.
מדידת שביעות הרצון אינה חייבת להיות באמצעות סקר או שאלונים. במקרים רבים – תהליך זה אינו יעיל, כיוון שלא תמיד הלקוחות עונים, וכאשר הם עונים – הם עונים בדיוק לשאלות שהם נשאלו. מניסיוני, כאשר הדבר אפשרי – עדיף למדוד את שביעות הרצון בביקורים אצל הלקוחות. המבקר הוא מנהל בכיר או מנכ"ל, הנפגש עם מנכ"ל או מנהל בכיר מטעם הלקוח. אפשר בשיחה ללמוד רבות: בנוסף לשביעות הרצון מהמוצר או השירות, אפשר לשמוע יותר בפרטים משוב על ביצועי המוצר, התעניינות שלו במוצרים של מתחרים, צרכים לא ממומשים ועוד. עצם הביקור עצמו, כבר מעלה את שביעות הרצון של הלקוח.
מדידה נוספת עקיפה של שביעות רצון הלקוח, היא מדידת הנכונות להמלצה. שואלים את הלקוח עד כמה יהיה מוכן להמליץ על הארגון ללקוחות נוספים בסקלה שבין 0 ל-10. ציון 9-10 נחשב ללקוח מרוצה, 7-8 נחשב ללקוח פסיבי, אדיש; כל ציון אחר נחשב כלקוח לא מרוצה.
מדדי ביצוע הינם ספציפיים לפרויקט. מדדים אלה הינם תלויי סוג הפרויקט, מורכבות הפרויקט או המוצר/שירות אותו מפתחים, מידת החדשנות שבו, גודלו, מספר האתרים בעולם בו מתנהל הפרויקט ועוד. רצוי להגדיר מספר קטן של מדדים, מתוך אוסף המדדים הכללי, כמדדים שהם קריטיים להצלחה.
המקום להגדיר את המדדים הביצועיים הוא בשלב תכנון הפרויקט. ביצוע הבקרה לאורך הפרויקט כולל מעקב שוטף במונחי אותם מדדי הביצוע שהוגדרו.
הוכח שאיכות המערכת/המוצר/השירות מושפעת באופן ישיר ומובהק מאיכות התהליך שיצר אותם. מדידת עמידת הפרויקט בתהליכי העבודה שהוגדרו לו נעשית באמצעות מבדקים פנימיים. אחת האפשרויות למדידה שכזאת היא באמצעות מדד מספרי שמרכז את מדידת איכות התהליכים בדף אחד. ראו: מבדקים פנימיים – הצגת תוצאות בצורה כמותית בתמונה אחת (השווה אלף מילים).
מדדי הפרויקט – נמדדים באופן רציף או באבני דרך מרכזיות, ולא רק בסוף הפרויקט, כדי שאפשר יהיה לבצע פעילות מתקנת ולחזור למסלול, בטרם יהיה מאוחר.
לכל ארגון – אוסף המטרות והיעדים משלו. לכל פרויקט בתוך ארגון מסויים – אוסף היעדים משלו. את היעדים מתעדים בתוכנית איכות לפרויקט, או תוכנית תכנון הפרויקט, מציגים אותה לצוות בישיבת הפתיחה (Kick-off) ומתחייבים עליהם. צורת מדידת הנתונים, תכיפות הצגתם מסוכמים מראש בתחילת הדרך, כדי שיהיה ברור לכולם על מה ואיך הם נמדדים. בנוסף, תכנון הפרויקט כולל גם את אופן ותדירות הבקרה על עמידה במדדים.
איך אתם מודדים הצלחה בניהול פרויקטים? מה ניסיונכם במדידת הצלחה של פרויקטים? אשמח לשיתוף באחת הרשתות החברתיות שקישורן להלן.
יש ארגונים, שעבורם לעבור מבדק של 9001 ISO זה סרט בלהות; לאחרים, זה בכלל לא סרט אלא דרך חיים. בשבילכם, אותם אלה שחושבים על התהליך כסרט, ריכזתי את עיקר הפעילויות הנדרשות לפי שלבי העבודה. הנחת העבודה להערכות הזמנים – לארגון המונה עד 20 איש.
כמובן, שמשך הזמן בפועל תלוי בגורמים רבים: גודל הארגון, מורכבות הארגון, רמת בשלות התהליכים בארגון, מידת שיתוף הפעולה של אנשי הארגון עם יועץ האיכות ועוד.
בתיאור שלהלן – יועץ האיכות יכול להיות מומחה בארגון או יועץ חיצוני.
למה? | הקמת מערכת איכות מתועדת ויעילה לצורך השגת שביעות רצון לקוח ושיפור מתמיד | ||
מי? | יועץ איכות | ||
כמה זמן? | כשבועיים עד חודש | ||
מה?  |
| ||
הערות |
|
למה? | הטמעת מערכת איכות אחידה (עד כדי התאמות מאושרות בארגון) |
מי? | הארגון, בסיוע יועץ איכות |
כמה זמן? | כחודש |
מה?  |
|
מה?  | ווידוא שהארגון אכן פועל על פי המערכת לניהול האיכות שנבחרה; תמיכת ההנהלה הבכירה בתהליך ההטמעה וייזום תהליכי שיפור |
מי? | יועץ איכות בסיוע הארגון |
כמה זמן? | שבועיים עד חודש |
מה? | ביצוע מבדקים פנימיים הכנות לסקר הנהלה וביצוע סקר הנהלה |
מה?  | קבלת אישור מגורם מוסמך שאכן מערכת האיכות מתפקדת על פי התקן |
מי? | נציג הארגון |
כמה זמן? | גמיש |
מה? | 1) הגשת הצעות למכוני הסמכה 2) בחירת הארגון המסמיך 3) מסירה של ספר הנהלים לארגון המסמיך לבדיקה מקדימה ואישור 4) מבדק של הארגון המסמיך
5) קבלת התעודה מהארגון המסמיך |
אנחנו נשדרג עבורכם את מערכת ניהול האיכות שלכם,נדמיין ששתולים לנו בארגון מחוללי תקלות בלתי נראים, המפריעים לנו להתקדם בדרכנו. כל פעם שאנו נתקלים ונופלים כתוצאה מהתוצר של אותם מחוללים, אנו מזיזים הצידה את המכשול וממשיכים בדרכנו. דרכנו אצה לנו. המטרה חשובה לנו. לכן, מיד לאחר שנפלנו כתוצאה מהמכשול – אנו קמים מיד, שמים פלסטר, מזיזים את המכשול, וממשיכים בריצתנו. הגענו למטרתנו, ומיד אנו יוצאים לדרך חדשה (פרויקט חדש). שוב אנו הולכים באותה הדרך, ונופלים באותן מהמורות. לפעמים, המהמורות נראות קצת שונות ולפעמים יש לנו תחושת דזה-וו – האם כבר נפלנו לבור הזה? שוב, אין זמן – קדימה! המטרה מחכה.
הגיוני? אולי כדאי לחשוב לפני שמתחילים שוב את הריצה המטורפת – אולי נגיע יותר מהר, או בפחות מאמץ – אם נטפל באותם מחוללי תקלות בלתי נראים המכשילים אותנו? טיפול כזה הוא בעצם תהליך של מניעת תקלות, שמשמעותו – ניתוח סיבות השורש של תקלות שקרו ותיקונן, כדי למנוע את הישנותן.
התקלות הן מסוגים שונים: קיימות תקלות ברמת ארגון, או ברמת פרויקט.
כדי למנוע את התקלות, נחקור את סיבות השורש שלהן, ונעשה תיקון יסודי. כתוצאה מהתיקון –ביצועי התהליך שבו טיפלנו – ישתפרו. הבטחה באחריות: נתמיד בכך לאורך זמן – נראה ברכה בעמלנו. מה עושים כשיש יותר מידי תקלות? נטפל בכולן, אך לא הגיוני לחקור את סיבת השורש של כולן, מבחינת החזר על ההשקעה. לכן נבחר בקפידה מספר תקלות ונתמקד במניעתן. נבחר באותן תקלות, שפוטנציאל הנזק שלהן הוא הגדול ביותר, ו/או שההחזר על ההשקעה הוא גדול מבחינת שיפור בפרמטרים חשובים לארגון, כגון: איכות, יעילות, זמן סבב ועוד.
טיפ 1: שילוב תהליכי מניעה לכל שלב בפרויקט, יעזור יותר מאשר הסקת מסקנות בסוף הפרויקט. השיפור יגיע כתוצאה ממניעת תקלות בטרם יוצרו, וכן מיצירת תנאים וסביבה שתאפשר לחזור על הצלחות מהעבר, של פרויקטים קודמים או מקבילים.
מספר תנאי קדם הכרחיים, כדי שנהיה מסוגלים לחקור את הסיבות לתופעות:
האיור שלהלן מתאר את תהליך ניתוח סיבות השורש ופתירתן, ואת הפרקטיקות של תהליך זה. סופו של התהליך הוא בתוכנית פעולה לטיפול שורשי בסיבות לתקלה. מאמר ההמשך – סיפור מקרה על הטמעת תהליך מניעת תקלות, מתאר את חיי הפרויקט והארגון, לאחר הטמעת השיעורים שנלמדו בחיי היום-יום, ומודעות לפעולות שיש לעשות כדי למנוע את חזרת אותן התקלות.
גג
גגגגג
גגגג
גגג
גגג
גגגג
גגג
פירוט תהליך ניתוח סיבות שורש ופתירתן:
סיבת שורש היא גורם שמתחיל סדרת פעולות שגורמת לתופעה הנצפית.
נפעיל תהליך שיטתי לקבלת החלטות, כדי לבחור את ה-תופעה בה נתמקד. טריגר להתחלת התהליך נגרם מאירועים שקרו (תגובה), או מפעולת מניעה שנעשית בצורה סדרתית (פרו-אקטיביות).
דוגמאות לאירוע: תקלה שדווחה על ידי לקוחות או משתמשים, או תקלה שנמצאה בבדיקות או סקר עמיתים, או תוצאות של מדידות החורגות מהתוכנית או תוצאות סקר שביעות רצון.
דוגמה לפעולה סדרתית: התחלת שלב בפרויקט;
עתה, יש לבחור את התופעה אותה רוצים להמשיך לחקור. נבחר את התופעה לאחר העמקה במספר פרמטרים: מקור, השפעה, תדירות המופע של התקלה, דמיון בין תופעות, עלות הניתוח, הזמן והמשאבים הדרושים, ועוד.
לבסוף נתחם את גבולות הגזרה לניתוח התופעה; נגדיר בברור את המטרות והציפיות של השיפור, בעיני בעלי העניין.
ננתח את הסיבות לאותן תופעות שנבחרו, ונציע דרכי פעולה כדי להתמודד עימן.
ניתוח סיבת השורש מתבצע בפגישה, עם מומחי תוכן בתופעה שנבחרה, היכולים לנתח את סיבת השורש. רצוי מאד לשתף גם נציגים של אלה שיהיו אחראיים אחר כך לביצוע הפעולות הנדרשות כדי לטפל בתופעה. יעילות הניתוח עולה ככל שהניתוח מתבצע על נתוני אמת, ובסמוך לאירוע עצמו.
דוגמאות לניתוח סיבות שורש: שיטת "עצם הדג", או שימוש בטבלאות שממיינות את התופעות לפי קריטריונים שהוגדרו מראש/פרטו, או סיעור מוחות.
לאחר ניתוח שיטתי של מספר תופעות, נאגד אותן לקבוצות לפי מכנה משותף. למשל: תופעות שמקורן תהליך הגדרות לקוי, או חוסר במיומנויות, חוסר בתקשורת וכדומה.
נציע דרכי פעולה כדי לטפל באותן קבוצות. דרכי הפעולה יכללו שינויים בתהליך מסוים, בהדרכה, שימוש בכלים ושיטות, וכדומה. לפעמים, דרכי הפעולה ימליצו על שימוש בשיטות מיטביות ידועות (Best Practices) כגון: הוספת רשימות תיוג (Check-List) המחייבות ביצוע פעולות מסוימות; הכנסת תהליכים אוטומטיים; הוספת פרקטיקות לתוך התהליך, כגון: ישיבת ייזום לשלב, בו דנים בכל התקלות או ההצלחות שקרו בשלב זה ומתכננים את השלב בהתאם לתוצאה הרצויה.
תיעוד אופייני של תוכנית פעולה משתמש בפרמטרים הבאים: אחראי על הפעולה המוצעת, תיאור התופעה לטיפול, תיאור הסיבה לתופעה, קטגוריית הסיבה, השלב שבה זוהתה הסיבה, תיאור הפעולה, משאבים נדרשים לביצוע הפעולה ולו"ז, התועלות הצפויות ממימוש תוכנית הפעולה, הערכת עלות לתיקון לטיפול שורש,קטגורית תוכנית הפעולה.
בשלב זה, סיבות השורש של אותן תקלות שנותחו מטופלות באופן שיטתי.
בשלב ניתוח הסיבה, הוצעו פעולות לתיקון שורש, כדי למנוע או להפחית את התופעות הלא רצויות. בשלב זה מופעלים מספר קריטריונים כדי לתעדף ולבחור את אותן הפעולות שיתנו החזר גבוה על השקעה. קריטריונים: עלות, השפעה על האיכות או פרמטרים אחרים, ועוד.
לחלק מההצעות, מופעלת תוכנית פעולה או פיילוט. מידע שנאסף בשלב זה, כולל נושאים כגון: לו"ז, עלות, הסברים להחלטות מרכזיות, ועוד.
פעולות שיגרמו לתוצאות חיוביות ממשיות, יוטמעו רוחבית בארגון.
בשלב זה, מנתחים את תוצאות תוכנית הפעולה או הפיילוט מבחינת ההשפעה שלהם על הביצועים. במידה וההשפעה חיובית – תישקל בחיוב הטמעה רחבה. בכל מקרה – מתעדים את התוצאות, והסיבות להמשך הדרך.
תיעוד התהליך, הנתונים והמסקנות חיוניים, לצורך ניתוחים עתידיים או שימוש בפרויקטים מקבילים.
טיפ 2: אפשרי ואף רצוי להפעיל את התהליך על נושאים שמטרידים את ההנהלה ו/או העובדים, כדי לסלק את הגורם לתופעה המטרידה.
התהליך המתואר, מפרט את תהליך חקר סיבות השורש, ואת ההמלצות לתיקון התהליכים. למשל, הכנסה של תהליך Kickoff לשלב (לא רק לפרויקט כולו). בכל שלב – מנהל הפרויקט סוקר את הפרקטיקות החדשות ומכניס אותן לתוכנית שלו. על החיים שאחרי…במאמר הבא. תהליך השיפור הוא מתמיד. לאחר שפתרנו תקלה מהשורש, נמשיך לפתור את התקלות הבאות. לפעמים תקלה אחת מסתירה את הבאות אחריה. שרשור שכזה, שפיתרון בעיה אחת חושף את הבאה אחריה, יכול להביא להטמעה של תהליכים חדשים נוספים.
התהליך שתואר לעיל מדבר על חקר סיבות השורש לתקלות, כדי להפחית את השפעתן השלילית. אותו תהליך בדיוק נעשה כדי לחקור הצלחות, כדי לחזור עליהן.
חקר סיבות השורש לתופעות (תקלות או הצלחות), ובעקבותיו – שיפור ושדרוג תהליכי העבודה, תומך בהעברת ידע של שיעורים שנלמדים בפרויקט אחד – לשאר הפרויקטים בארגון. במקרים רבים, נעשות פעולות של הפקת לקחים, אך המסקנות לגבי סיבות השורש אינן מיושמות, וכתוצאה מכך לא נהנים מפירות ההשקעה. התהליך אינו מסובך, אך דורש שיטתיות ומשמעת.
מקור:
CMMI For Development, Guidelines for Process Integration and Product Improvement, third edition, Mary-Beth Chrissis, Mike Korad, Sandy Shrum
הכותרת נשמעת כמו התחלה של בדיחה?
איך עיתונאי מבצע תחקיר עיתונאי לצורך יצירת סיפור שלם, שמוצא גם מוטיבים לסיפור העלילה שלא צפים מיד על פני השטח?
איך חוקר משטרתי אוסף נתונים לצורך פענוח פשע?
איך מנהל איכות, או ארגון ושיטות מוביל תהליך לפיתרון שורש של בעיה?
איך מתחילים להתמודד עם אתגרים כאלה ודומים להם?
הדרך הקלסית לפיתרון בעיות היא מוכוונת פיתרון: מסתכלים סביב, מדברים עם בעלי העניין, אוספים קצת נתונים, עושים סיעור מוחות קצר המעלה סיבות אפשריות שגרמו לתופעה ומיד יש סיפור. לפעמים כדי לחקור את ההתרחשות שקדמו לסיפור/פשע/בעיית איכות צריך לחקור קצת יותר. לשם כך, מחלקים מטלות למעורבים בעניין; ייתכן שביצוע אותן מטלות אכן יעלה על סיבת השורש האמיתית שגרמה לתופעה, אולם לא תמיד, כיוון שהמטלות שקיבלו בעלי העניין לביצוע, ניתנו בחופזה וללא התעמקות בתופעה.
המאמר שלהלן, מציע לשאול שש שאלות בסיסיות המסייעות באיסוף מידע על התופעה, ולספר את הסיפור השלם של הנושא אותו אנו חוקרים.
לפעמים, כדי לעזור לנתח את הבעיה ולענות על השאלות בצורה שתאפשר לנתח את התשובות באופן שיטתי, עלינו לייצר מערכות שאוספות נתונים. במקרים מסוימים, בנוסף גם נתייג את האובייקטים ו/או המשתתפים ו/או מקומות וכדומה, כדי שנוכל בשלב הניתוח לאפיין את הבעיה בצורה מדויקת.
לעומת הדרך הקלסית לפיתרון בעיות שהיא מוכוונת פיתרון, קיימת דרך אחרת לפיתרון בעיות שורש, הפועלת בגישה שהיא מכונות הזדמנות.שיטת DMAIC מפעילה צוות הפועל בחמישה שלבים:
טכניקת 5 Ws + 1 H , מתאימה לשלב הראשון, הגדרת ההזדמנות/ הבעיה, ומסייעת לצוות להגדיר את ההזדמנות.
השיטה שתוארה לעיל משמשת גם עיתונאים המבצעים תחקיר עיתונאי כדי לבנות סיפור שלם, ואפילו חוקרים במשטרה המנסים לפענח מקרה פלילי.
לקוחות מתלוננים ומחפשים את המנכ"ל או את המנהלים הבכירים ודורשים תיקון מיידי לתקלה שקרתה? המנהלים מתרוצצים כדי להרגיע ולפתור בעיות? פותרים תקלה אחת ומיד נכנסות שלוש חדשות? יש עוד ועוד בעיות?…הקמתם מרכז שירות ותמיכה והתומכים משמשים שק חבטות ללקוחות? מנסים לפתור בעיות ולא תמיד מצליחים? התלונות הולכות ונערמות ויחד עם זה התומכים נשחקים וחלקם עוזבים?לא נעים, בהחלט…אבל יש גם יותר גרוע.
מה יותר גרוע מלקוח שמתלונן? לקוח לא מרוצה שלא מתלונן ולאחר שהסאה גדשה, פשוט מוצא אלטרנטיבה ועוזב.
מה עושים? מקימים מרכז שירות לקוחות ונותנים מענה לפניות או לפחות ממנים גורם אחד מרכזי שירכז את הפניות מהלקוחות והמענה להם; נותנים לתומכים כלים טכניים ורכים כדי לענות כהלכה ללקוחות, ועוד כהנה וכהנה.
המיקוד במרכז לשירות לקוחות הוא פתרון מהיר ואפקטיבי של תקלות הנוצרות משימוש במוצר או מהשירות. מאמר זה מרחיב את התהליך ומוסיף תשתית שמטרתה למנוע את הישנות התקלות.
תקלה בתהליך מתן השירות מוגדרת ככזאת שאם לא תטופל תגרום לכך שהספק שנותן את השירות לא יעמוד בהתחייבויות שלו. חלק מההתחייבות כתובות בהסכם השירות, וחלקן האחר ברור מאליו – למשל שהמוצר יעבוד לפי התצורה שהלקוח קבע, מתוך תפריט האפשרויות שסופקו לו.
התהליך כולל את הפעילויות הבאות:
להלן שני סוגים מרכזיים:
דוגמאות: באג בתוכנה שגורם להפסקת מתן שירות, או מזוודה שהולכת לאיבוד בשדה התעופה;
בהגדרה, לכל תקלה בשירות יש סיבת שורש הגורמת לה, גם אם ספק השירות אינו מודע לה או זיהה אותה. יש סיבות שורש שאינן גורמות מיידית לתקלה. למשל: תקלה הנגרמת מאופן שימוש נדיר במוצר או בשירות יכולה להתגלות לאחר זמן רב של שימוש סטנדרטי במוצר/שירות. לפעמים, הסרת גורם השורש אינה משתלמת כלכלית. במקרים אלה, נמצא מעקפים או אפילו נפתור בעיות בצורה מקומית כל פעם שהן קורות. |
התהליך לטיפול בתקלות ומניעת הישנותן כולל שלושה תהליכים מרכזיים, המתחלקים לתהליכי משנה:
תהליך הכנת התשתית כולל שני תהליכי משנה:
המתודולוגיה מתארת את פונקציות הארגון המעורבות בפיתרון ומניעה של תקלות, השיטות והכלים בהם משתמשים, וכן את האחראים לטיפול במשימות לאורך מחזור חיי תקלה. בדרך כלל השיטה מתועדת בכתב, וכוללת גם הגדרה של מסגרת זמן מוגדר מראש לפיתרון התקלות.
השיטה מגדירה גם את התהליך שבו הלקוחות יכולים לדווח על תקלה ואת התהליך שבו משתפים את המדווחים על מצב התקלה ואופן הטיפול בה. כמו כן, השיטה מתארת תהליך לזיהוי הלקוחות שעלולים להיות מושפעים מהתקלה שהתגלתה, גם אם הם טרם גילו אותה, ואת אופן הטיפול בהם.
במקרים רבים, הארגון מקים מרכז שירות או מרכז תמיכה בלקוחות. פונקציה זו באה במגע עם הלקוחות, מקבלת את התלונות והתקלות, מספקת מעקפים, ומטפלת בתקלות. המאמר שלהלן מתמקד בטכניקה לאיתור בעיות השורש של התקלות ונקיטת פעולות כדי למנוע את הישנותן. יצויין שניהול שיטתי של מרכז שירות מטפל בנושאים נוספים, כגון: מניעת שחיקה של התומכים, אך נושאים אלה אינם בתכולת מאמר זה.
התקלות מסווגות במספר פרמטרים אורתוגונליים המסייעים בחיפוש הגורמים לתקלות, בהגדרת אופן הטיפול, ובמידת האסקלציה שנדרש לעשות:
מערכת לניהול תקלות כוללת כלים, שיטות ומדיה לאחסון ותיעוד התקלות ותהליך הטיפול בהם. המערכת יכולה להיות אוטומטית או ידנית. המערכת מאפשרת לאגור ולנתח נתונים היסטוריים, כגון תקלות שקרו, מעקפים שנעשו וכדומה. נתונים אלה מסייעים בניתוח ופיתרון התקלות החדשות.
תהליך ניהול התקלות עד לסגירתן, כולל חמישה תהליכי משנה:
התהליך כולל איסוף פרטים על הסביבה בה קרתה התקלה ואופן השימוש שגרם לתקלה.
זיהוי התקלה כולל ניתוח והבנת המקור של התקלה, למשל:
התיעוד כולל אפיון התקלה בהתאם לסוגי המאפיינים שנקבעו מראש: קטגוריות, עדיפות, חומרה וכדומה.
ניתוח התקלה יאפיין את אופן התגובה: החל מלא לעשות דבר ולהמשיך לנטר את האירוע, וכלה בהדרכת המשתמשים לגבי השימוש הנכון במוצר/שירות, הפעלת מעקף שכבר הוכן מראש, או כל פיתרון מוכר אחר להתמודדות עם התקלה.
פיתרון התקלה יתבסס על הניתוח שנעשה לתקלה. יתכן שהפיתרון שנבחר יפתור את התקלה באופן חלקי, או שלא יפתור אותה כלל. במקרים אלה, נדרש לחזור לשלב הניתוח, ולהעמיק כדי למצוא פיתרון שונה נוסף.
פיתרון באמצעות מעקף, או מיחזור של פיתרון שבוצע בעבר, יכול לשכך את הכאב של התקלה ולהשקיט את ההמולה, כדי שאפשר יהיה להקדיש את הזמן לפיתרון גורם השורש. במערכות גדולות עם תקלות מרובות (מה לעשות, קורה…) מומלץ לשקול להקים מאגר של מעקפים ופתרונות שבוצעו בעבר.
במידה וסופק פיתרון, מטרת הניטור הינה לתעד את הפעולות שנעשו ולוודא שאכן רמת השירות חזרה לעמוד בציפיות המשתמשים. כשמתקבל אישור על שביעות רצון מהלקוח, סוגרים את התקלה במערכת. במידה והתקלה לא נפתרה לשביעות רצון המשתמשים, יופעל מנגנון אסקלציה.
תקשורת עם בעלי העניין חשובה תמיד; חשיבות התקשורת עם מדווח התקלה ואלה המושפעים ממנה כל עוד לא נפתרה התקלה חשובה שבעתיים. כאשר משתפים את הלקוחות והמשתמשים במידע הקשור בתקלה הם יותר סלחניים ומסייעים. כמו כן, תיאום בין הצוות שהגדיר את פתרון התקלה לצוות שאחראי ליישם את הפתרון בשטח הינו חשוב ביותר כדי למזער את ההפרעה למתן השירות. אישור לסגירת התקלה מתקבל ממדווח התקלה לאחר אימות שהפיתרון אכן פתר את הבעיה. התקשורת עם בעלי העניין מתועדת לאורך כל מחזור חיי התקלה, כדי לא לאבד מידע, ולא לחזור על איסוף מידע שכבר נעשה. לאחר מכן, תיעשה תוכנית פעולה מקיפה ומעמיקה כדי להתמודד עם סיבות השורש.
מטרת תהליך זה היא לצמצם את הנזק מתקלות פוטנציאליות עתידיות. תהליך זה בוחר מספר תקלות ומנתח כיצד למנוע את הישנותן בעתיד. לאחר שמסוכמת דרך הפעולה ננקטות פעולות תיקון שורש על ידי "יוצרי התקלה". פעולות אלה, תורמות להפחתת כמות התקלות ובכך תורמות להעלאת שביעות הרצון של הלקוחות, והפחתת העומס על מרכז השירות/תמיכה בלקוחות. סיבת השורש במקרים רבים שונה מהסיבה שגרמה לתקלה. למשל: סיבת השורש לתקלה בשירות שנגרמת משבר באחד מרכיבי המוצר יכולה להיות תהליך ניהול דרישות לא אופטימאלי שלא ניתח נכון את העומסים הצפויים על אותו רכיב. תיקון התקלה המיידי יחליף את החלק השבור ואולי אף יוסיף מעקף שינתב את העומס לרכיב מקביל. תיקון השורש יכול לקחת זמן רב יותר.
תהליך העבודה על סיבות השורש מורכב משלושה תהליכי משנה:
תהליכי ניתוח סיבות השורש של התקלות נעשה עם הגורמים הרלוונטיים ש"יצרו" את התקלה. נעשית הערכת המשמעות של תיקון גורמי השורש. לעיתים, ניתוח עלות-תועלת של תיקון סיבת השורש, יכול ללמד, שמטעמים עסקיים, כדאי להסתפק במעקף. לכן, מומלץ לנהל מסד נתונים עם תיאורי התקלות, סיבותיהן ומעקפיהן, בהתאמה. בסופו של תהליך הניתוח יוחלט על אופן הפעולה.
מעקפים, הם הפיתרון האופטימאלי, כל עוד לא הוסרו גורמי השורש לתקלות. לכן נדרש ליצור מסד נתונים של תקלות ופתרונות הביניים שלהם. גם פיתרונות הביניים צריכים להיות מאומתים בשטח, ולקבל אישור שאכן הם פותרים את התקלה.
לאחר שהניתוח מצא את סיבות השורש, במידה והוחלט על ביצוע פעולות להפחתת תקלות עתידיות – הן מתוכננות ומבוצעות. התכנון מפרט תוכנית מה לעשות – מי? מה? מתי? לאחר מכן, מבצעים את התוכנית ועוקבים שאכן כמות התקלות יורדת.
תהליך תיקון תקלות מהשורש נועד להגדיל את שביעות רצון הלקוחות מאיכות השירות, ולהגדיל את יעילות התפעול של מרכז השירות ללקוח, כיוון שבטווח הארוך התהליך אמור להקטין את כמות התקלות. במידה ותהליך הפקת הלקחים נעשה בצורה מעמיקה, על ידי שיפור תהליכי הפיתוח והבקרה, יש סיכוי טוב שימנעו גם בעיות שטרם קרו.
התהליך שתואר לעיל נראה ברור מאליו. למרות זאת, תצפיותיי בארגונים השונים מראות שבודדים הארגונים שמשקיעים מאמץ בסילוק גורמי השורש. רובם מסתפקים בתיקון הבעיות לאחר שהן קרו.
מקור: CMMI For Services, Version 1.3, CMMI-SVC, V1.3, November 2010 – Incident Resolution and Prevention
התשובה הפשטנית לשאלה שלעיל, נמצאת בתוך השאלה עצמה – לתת שירות ללקוחות. כדי לענות עליה, נרצה להבין: מי הלקוחות? איזה שירות הם מצפים לקבל? תוך כמה זמן? וכדומה.
אולם, השאלה הייתה – מהי המטרה החשובה ביותר?
האם מטרת מרכז שירות הלקוחות היא אחת מהמפורטות להלן?
לרוב, מרכז השירות ללקוחות מתמקד בטיפול ותיקון תקלות המדווחות על ידי הלקוחות. האתגר הוא לטפל בלקוחות בנוסף לטיפול בתקלות. לא סתם המרכז נקרא "מרכז שירות לקוחות" ולא "מרכז תיקון תקלות". מרכז השירות ללקוחות הוא מקום המפגש עם הלקוחות, וככזה יכול להיות מנוף ללמידה ולשיפור ארגוני. מרכז שירות הלקוחות נתקל באופני שימוש מיוחדים, לא תמיד סטנדרטים של הלקוחות במוצר או בשירות. לא כל הפניות הן תלונות. לפעמים – שאלות או בקשות עזרה. אם למרכז שירות הלקוחות צינור למחלקות אחרות, למשל מחלקת R&D, דרכו הוא יוכל להעביר את ההתנסויות בשטח – מאד יועיל; במידה והארגון גם ישתמש בידע הזה לפעילות מונעת ומתקנת של הסרת בעיות מהמקור – שביעות הרצון של הלקוחות תעלה בהדרגה.
כל המטרות שתוארו לעיל הן מטרות ראויות, שאפשר אפילו למדוד אותן, למשל: להוריד את כמות התלונות הנפתחות; לקצר את משך הטיפול בבעיה; להוריד את כמות התקלות שנפתחות מחדש כיוון שתלונת הלקוח לא טופלה כראוי; לדאוג לכך שסוג התקלה הספציפי שדווח לא יחזור על עצמו….כל התשובות נכונות, אך עדיין חסר מרכיב קטן שיכול לעשות את ההבדל. למרכיב הזה קוראים נשמה או בשפה המקצועית: "ניהול חווית הלקוח". הכוונה במונח זה היא לשנות את חווית הלקוח ורגשותיו בעקבות ניסיון גרוע מבחינתו בשימוש במוצר. חוויה זו לא קשורה לעובדות. עובדה יכולה להיות מוצר תקול או המתנה ארוכה לשירות, או כל דבר אחר. רוב מרכזי השירות מתמקדים בטיפול בשינוי העובדות: תיקון מהיר או החלפה של המוצר, קיצור זמני המתנה וכדומה. לפעמים טיפול בעובדות מניח את דעת הלקוחות, אך זה לא מספיק.
הדרך האופטימלית לשמר את הלקוח היא באמצעות אספקת ומצרים ושירותים איכותיים, וביצוע פעולות פרואקטיביות כדי לתמוך בלקוח. ובכל זאת, תקלות קורות. במקרים אלה, מטרת מרכז שירות הלקוחות החשובה ביותר היא לשנות את הרגשות הטעונים שיש ללקוח כלפי החברה, ובכך לתרום לשימור הלקוחות. מרכז שירות יכול לשנות את חווית הלקוח לחיובית, גם במקרה שישנה בעיית איכות. חוויה חיובית תיווצר בעקבות מגע אנושי קשוב, מנומס, מבין, מקצועי ותומך, יחד עם טיפול ענייני בבעיה. התומך יוודא שבעיית הלקוח קיבלה מענה; לעיתים, בדיקה שהבעיה אכן נפתרה יכולה להתבצע רק לאחר זמן מה. המדידה הטובה עבור מרכז הלקוחות היא אם בעקבות הממשק הטוב עם הלקוח, הלקוח ימשיך לרכוש מוצרים ושירותים מהחברה ואף ימליץ עליה לחבריו ומכריו.
נראה לכם או שהגזמתי? אשמח לשיתוף עם תשובה באחת הרשתות החברתיות שקישורן בתחתית הדף.
| מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
קבעתם הסכם עם ספק לביצוע חלק מהעבודה בפרויקט, ועם סיום עבודתו גיליתם פערים גדולים בין מה שרציתם וקיבלתם? נדרשתם לעשות שינויים בתכולת העבודה שנסגרה מול הספק ומצאתם את עצמכם "שבויים" בידי הספק? או להיפך: עשיתם הסכם עם ספק שגרם לספק להיות מאד לא מרוצה מהעבודה איתכם בגלל תקשורת לקויה, או בגלל שהפסיד כסף? גיליתם מאוחר מידי שהתוצרים שאתם עומדים לקבל אינם באיכות שתכננתם, או שעומד להיות פיגור גדול במסירת תוצרים מהספק שעלול לגרום לפיגור בפרויקט כולו?
מהנדסים ומנהלים המפתחים מוצרים ושירותים נדרשים לרכוש פריטים ו/או שירותים המשמשים אותם לצורך עבודתם. למשל: תוכנות, חומרות, חומרי גלם לפיתוח דגמים וכדומה. לפעמים רכש זה נעשה חד-פעמית. בשל היותם מומחים בתחומם, ובדרך כלל אינם מומחים ברכש, קיים סיכון לניהול כושל של הספקים. נושא שכיח לתקלות מול ספקים הוא אופן ניהול השינויים בדרישות במהלך הפרויקט. חוסר ניסיון בנושא עלול להביא למשמעויות חמורות בעלות הפרויקט, תכולתו ואיכותו, עד כדי התנגשות חוזית מול הספק. טעות בבחירת ספק או רכיב יכולה לגרום לכך שהרוכב הפרויקט ייפול בגלל מסמר הקטן.
למי מיועד התהליך? התהליך נועד למנהלים ומהנדסים, הנדרשים לרכוש מוצרים ו/או שירותים לצורך עבודתם. התהליך כולל:
למי לא מיועד התהליך שלהלן? התהליך לא מיועד לניהול "גולגולות". דהיינו: לאותם קבלני משנה העובדים כחלק מצוות הפרויקט. כאשר "הגולגלות" הן חלק מצוות הפרויקט הפנימי, אופן הניהול של "הגולגלות" נעשה בהתאם לתהליכי ניהול הפרויקט השיטתי "הרגיל". כמו כן, התהליך המתואר אינו מטפל ברכש שוטף לצורכי תפעול או ייצור שנעשה על ידי מחלקת הרכש בארגון. במקרים אלה, מדובר על רכש בו צוות הפיתוח כבר אמר את דברו לגבי אופן הפיתרון הרצוי לו, והרכש פועל עצמאית על פי שיקוליו.
מאמר זה מטפל בניהול שיטתי של רכש מוצרי מדף, פריטים ושירותים מספקים, הנדרשים ע"י צוותי הפיתוח לצורך עבודתם. המאמר מפרט את התהליך השיטתי המומלץ על ידי מודל ה-CMMI לרכש מוצרים, מערכות ושירותים, כולל מיקור חוץ של חלק מעבודת הפיתוח לקבלני משנה.
תהליך ניהול הסכמים עם ספקים (Supplier Agreement Management) של מודל ה- CMMI נועד למסד את מערכת היחסים בין ארגון הפיתוח לספקיו. ההסכם יכול להיות גם עם גוף פנימי בתוך הארגון. כאשר מדובר בהחלטת רכש משמעותית מבחינת עלות או השפעה על הפרויקט, מומלץ להשתמש במקביל גם בתהליך שיטתי לקבלת החלטות.
1) החליטו על סוג הרכש.
סוג הרכש ישפיע על תהליך הרכש, ובעלי העניין שייקחו בו חלק. דוגמאות: רכישת מוצר מהמדף, רכישה מספק באמצעות חוזה, רכש פנימי, רכש מהלקוח, רכש מרשימת ספקים מועדפת או קומבינציה של חלק מהאפשרויות שתוארו עד כה.
2) בחרו ספקים
הגדירו קריטריונים לתהליך הבחירה, כגון: יכולת הספק לעמוד בדרישות הפרויקט, מיקומו הגיאוגרפי, ניסיון הספק והיסטורית ביצועיו, שביעות רצון לקוחותיו ומחיר.
3) מסדו התקשרות עם הספק באמצעות מסמך המתאר את ההסכמה בין הצדדים
המסמך יכול להיות כתוב כחוזה, הסכם לקניית רישיונות, הסכם לקבלת רמת שירות נאותה, מסמך הבנות או כל צורה אחרת מוסכמת על הצדדים; בהתאם לצורך – ערב את המחלקה המשפטית של הארגון.
טיפים חשובים:
4) נהלו את הפעילויות מול הספק כמוסכם
ניהול הפעילויות מול הספקים נעשית בהתאם להסכם הכתוב. פעילויות אלה כוללות מעקב אחר עמידה באבני דרך, בדיקות שהתוצרים עומדים בדרישות ובאיכות; כמו כן פעילות זו כוללת ניהול תקשורת בצורה פורמאלית: אישור מסמכים המתקבלים מהספק, דו"חות שבועיים, ישיבות מעקב חודשיות, תהליכי אסקלצייה לבעיות, איש קשר מוגדר וכדומה.
5) הקפידו בתהליך קבלת התוצרים מהספק
בדקו ואמתו שהתוצרים עומדים בדרישות כפי שנמסרו לספק; ערכו סקירות עם הספק על תוצרים, וודאו שהוא מבין את הדרישות ממנו בכניסה לשלב מסויים, וודאו שהתוצרים מתאימים לדרישות בסיום אותו שלב, בצעו בדיקות קבלה, דווחו על חריגים עד לשביעות רצון מהתוצר המוגמר
6) וודאו שילוב של התוצר הנרכש בתוך המוצר המפותח על ידי צוות הפרויקט
תכננו ונהלו את הפעילויות הנדרשות, כולל הדרכות, תמיכה טכנית ותחזוקה
ייתכן והמתואר לעיל נראה ברור מאליו; ייתכן וחלקכם עושים אותו באופן אינטואיטיבי. מיסוד תהליך שיטתי בנושא זה מאפשר להפוך את הידע כיצד לנהל הסכמים מול שותפים לרכוש החברה. תיעוד התהליך מאפשר להשתמש בניסיון שנצבר עם ספקים מסוימים או עם סוגי רכש מסוימים לטובת רכישות עתידיות.
או קיי, תכננתם היטב את הפרויקט שלכם; יצאתם לדרך בשעה טובה. כיצד אתם מוודאים שאתם אכן במסלול ומתקדמים בהתאם לתוכנית? אולי יותר נכון לשאול – כיצד אתם מוודאים כל הזמן שתובילו את הפרויקט לסיומו המוצלח, לשביעות רצון הלקוחות ושאר בעלי העניין? ניהול נכון של הפרויקט בודק כל הזמן את ההתקדמות למול התוכנית, אך בד בבד גם מוודא גמישות למול המציאות בשטח; לא תמיד נכון לבצע את התוכנית ויהי מה.
סיפור מהחיים – באחד הארגונים שאני מכירה, קיימת הפרדה מוחלטת בין קבוצות המוצר והשיווק לקבוצת הפיתוח. קבוצת הפיתוח נמדדת רק על ביצועים למול התוכנית. לאחר מספר חודשים של תכנון מדוקדק התחיל פרויקט פיתוח מוצר חדש. כשהפרויקט היה עמוק בשלב הפיתוח, חלו שינויים בשוק, וכתוצאה מכך דרשו מנהלי השיווק לערוך שינויים בתוכנית. החלה מהומת אלוהים, בין קבוצת הפיתוח שהתבצרה בתכנון המקורי, שעל ביצועה היא נמדדת, למול קבוצת המוצר שכבר אין לה צורך במוצר המקורי אותו דרשה ואף אישרה את תכנונו. (סוף הסיפור, אגב, היה בכלל לא שמח..)
תהליך שיטתי לבקרת התנהלות הפרויקט מטרתו לספק הבנה של התקדמות הפרויקט, כדי לאפשר נקיטת פעילות מתקנת כאשר הפרויקט סוטה מתכנונו המקורי. המאמר שלהלן מביא את גישת מודל ה-CMMI לתהליך בקרה שיטתי בנושא. תהליך מקביל מטפל במקרים כאשר נוצרים שינויים בדרישות.
פעילויות 1-7 שלעיל מטרתן לזהות סטיות בהתקדמות הפרויקט למול התכנון שלו; פעילויות 8-10 מטרתן לנתח את הנתונים שנאספו, ובמידה שהפרויקט סוטה מהמסלול המתוכנן – להחזירו למסלול.
האיור שלהלן, מסכם את עשרת הפרקטיקות, בשפת מודל ה-CMMI:
י יודע מהו הנושא המככב בכל תחקיר על פרויקט שנכשל?……מי שניחש שהנושא קשור לניהול ופיתוח דרישות – צדק! זהו כמובן לא הנושא היחיד, אך בהחלט נושא שחוזר בתדירות גבוהה. מסתבר שלהבין את דרישות הלקוחות, ולנהל אותן במהלך מחזור הפיתוח זהו נושא סבוך וקשה; הסיבות לכך הן רבות. בהיעדר ניהול דרישות שיטתי, ייתכן והמוצר או השירות שתפתחו לא יממש את כל הדרישות שהלקוחות בקשו מכם. בהיעדר תשתית טובה לניהול דרישות, שינויים שקורים במהלך הפרויקט, כולל שינויים בדרישות יכולים להביא להתבדרות של הפרויקט.
מחזור החיים של פיתוח מוצרים ושירותים מתחיל בהגדרת הדרישות. "כמו שנציע את המיטה כך נישן עליה". כלומר, אופן הבנת הדרישות וניהולן משפיע בצורה משמעותית על התוצר הסופי.
מאמר זה מנסה להתמודד עם הנושא באמצעות תהליך שיטתי, בהנחיית מודל ה-CMMI שמטפל בין היתר בנושא הנדסת מערכת.
הטיפול בדרישות, על פי מודל ה-CMMI מכוסה על ידי שני תחומי תהליך:
זהו תהליך ניהולי, המטפל בתהליך הניהול האדמיניסטרטיבי של דרישות המוצר או השירות ורכיביהם. תהליך ניהול הדרישות מתחיל מקבלת דרישות מהלקוח/ות ומכל בעלי העניין שעשויים לתרום הגדרה של צרכים ו/או אילוצים לגבי המוצר. בעלי העניין יכולים להיות גם גופי רגולציה, גופים מוסדיים שונים בארגון ועוד. הלקוחות מגדירים דרישות במונחי מה נדרש לעשות (למשל: ביצועים, תכונות); כמו כן, מטפל התהליך בשינויים בדרישות.
זהו תהליך הנדסי, המתרגם את דרישות הלקוח לדרישות הנדסיות; מחלק את הדרישות לדיסציפלינות (למשל: חומרה/תוכנה) או תתי מערכות. לאחר שחילקנו דרישות לדיסציפלינות, כל דיסציפלינה אחראית על מימוש הדרישות שבאחריותה. לפעמים אותה דרישה תבוצע על ידי כמה דיסציפלינות. תהליך התכן מתחיל מהדרישות ההנדסיות.
מאמר זה דן בנושא ניהול הדרישות בלבד. נושא פיתוח הדרישות יטופל במאמר אחר.
תהליך ניהול דרישות שיטתי דואג שלאורך כל מחזור הפיתוח יהיה אוסף מוגדר ומאושר של דרישות. כמו כן תהיה הלימה בין תוכניות העבודה של הפרויקט ומוצרי הביניים המופקים בתהליך לדרישות המוצר. אין הכוונה שכל הדרישות יהיו מוגדרות בתחילת הדרך. בהחלט אפשרי לפתח במודל איטרטיבי או אג'ילי. במקרים אלה כל שייאמר להלן, ניתן להתאמה כשמדובר באיטרציות, או במנות אג'יליות.
חמש הפרקטיקות בנושא ניהול שיטתי, מוצגות בדיאגרמה שלהלן, ומפורטות בהמשך:
עשה | ואם לא תעשה… | |
הבנת הדרישות | הגדר מראש מיהם ספקי הדרישות המקובלים ואת הקריטריונים לקבלת הדרישות; השג הבנה מספקי הדרישות לגבי המשמעות של הדרישות; נתח את הדרישות וודא עם הלקוח שהבנת אותן. השג אישור מהלקוח לדרישות הבסיס ובכך רתום אותו לפרויקט המתהווה. | בהיעדר הגדרה ברורה ממי מקבלים דרישות, יש חשש מקבלת דרישות שאין צורך לבצען, או שיש סתירה בין ספקי הדרישות. במידה ואין אישור מהלקוח שדרישותיו הובנו, אין ערובה לכך שהמסר עבר במדויק; |
השגת מחויבות לדרישות | השג מחויבות מכל בעלי העניין בארגון לפיתוח המוצר או השירות בהתאם לדרישות. במקרים רבים, האישור יושג לאחר הבנה עמוקה של משמעות יישום כל הדרישות, וקבלת המשאבים הנדרשים. | אי אפשר להצליח ולסיים פיתוח מוצר או שירות שעומד בדרישות הלקוח בהיעדר מחויבות מגוף הפיתוח לפתח את המוצר בהתאם לדרישות. היעדר מחויבות מצד הפיתוח יכול לנבוע מאי הקצאת המשאבים הנדרשים. |
ניהול שינויים לדרישות | הבן את משמעות השינוי וההשפעה שלו על הפרויקט מבחינת משאבים ולו"ז וכן מבחינת ההשפעה שיש לשינוי בדרישות מסוימות, על דרישות אחרות, וקבל החלטה מושכלת אם וכיצד לטפל בשינוי. | קבלה פזיזה של שינויים בדרישות מבלי להבין את משמעותם, תגרום להתבדרות הפרויקט וחוסר שביעות רצון של הלקוחות ושאר בעלי העניין. |
ניהול עקיבות דו-כיוונית | נהל עקיבות דו כיוונית בין הדרישות המקוריות לדרישות ברמות נמוכות יותר, ובין הדרישות למוצרי ביניים של תהליך הפיתוח, עד לבדיקות המאשרות שכל הדרישות מומשו ונבדקו. | בהיעדר ניהול עקיבות קשה לדעת אם אכן כל הדרישות מומשו. כמו כן, במקרה של שינויים בדרישות מסוימות קשה לדעת במדויק על מה ישפיע השינוי. |
הלימה בין הדרישות לתוכנית העבודה | במהלך כל התנהלות הפרויקט, בדוק שתוכניות העבודה אכן ממשות את כל הדרישות, לפי אבני הדרך שבתוכנית. כלומר, שיש הלימה בין אבני הדרך והתכולה שתוכננה להיות מוכנה בכל אבן דרך. במידה ומצאת סטייה, עדכן את התכנית בהתאם (באמצעות ניהול השינוי). | עלולות להיווצר במהלך הפרויקט אי התאמות בין דרישות הלקוח/ות ותוכנית העבודה לחילופין, אי התאמות שנמצאות יכולות להיות מטופלות בצורה שאינה לוקחת בחשבון את השפעות השינוי. כתוצאה מכך, עלולים להיווצר פיגורים בלו"ז, או שיסתבר שהפרויקט לא ממש את התכולה המובטחת. |
בארגונים לא מעטים מצאתי שנושא ניהול ופיתוח הדרישות הוא "תפוח אדמה לוהט", שמעדיפים להעביר אותו מיד ליד ולדחות את הטיפול בו, עד ש…ימוסדו תהליכים אחרים, או יהיה תקציב מיוחד, או שמחכים לשינוי ארגוני שיגדיר פונקציה של הנדסת מערכות, או שיגדירו את האחריות לנושא בתפר שבין מנהל הפרויקט למנהל התוכנית, … ועוד כהנא וכהנא סיבות. ובינתיים – מתחילים לטפל בנושאים אחרים כמו ניהול בדיקות. קשה מאד לטפל בנושאים הקשורים לפיתוח מאמצע או מסוף הדרך. יתרה מזאת, תנאי לניהול בדיקות טוב הוא ניהול דרישות טוב! המלצתי – גשו ישר לעניין ! התחילו מההתחלה. בהצלחה!
==
האם הנושא מטופל בארגונכם?
איזה גוף אחראי לכך?
אשמח לשיתוף כיצד מנוהלות הדרישות בארגונכם; טוב? פחות טוב?
אשמח לשיתוף באחת הרשתות החברתיות שקישורן להלן
