הכותרת נשמעת כמו התחלה של בדיחה?
איך עיתונאי מבצע תחקיר עיתונאי לצורך יצירת סיפור שלם, שמוצא גם מוטיבים לסיפור העלילה שלא צפים מיד על פני השטח?
איך חוקר משטרתי אוסף נתונים לצורך פענוח פשע?
איך מנהל איכות, או ארגון ושיטות מוביל תהליך לפיתרון שורש של בעיה?
איך מתחילים להתמודד עם אתגרים כאלה ודומים להם?
הדרך הקלסית לפיתרון בעיות היא מוכוונת פיתרון: מסתכלים סביב, מדברים עם בעלי העניין, אוספים קצת נתונים, עושים סיעור מוחות קצר המעלה סיבות אפשריות שגרמו לתופעה ומיד יש סיפור. לפעמים כדי לחקור את ההתרחשות שקדמו לסיפור/פשע/בעיית איכות צריך לחקור קצת יותר. לשם כך, מחלקים מטלות למעורבים בעניין; ייתכן שביצוע אותן מטלות אכן יעלה על סיבת השורש האמיתית שגרמה לתופעה, אולם לא תמיד, כיוון שהמטלות שקיבלו בעלי העניין לביצוע, ניתנו בחופזה וללא התעמקות בתופעה.
המאמר שלהלן, מציע לשאול שש שאלות בסיסיות המסייעות באיסוף מידע על התופעה, ולספר את הסיפור השלם של הנושא אותו אנו חוקרים.
לפעמים, כדי לעזור לנתח את הבעיה ולענות על השאלות בצורה שתאפשר לנתח את התשובות באופן שיטתי, עלינו לייצר מערכות שאוספות נתונים. במקרים מסוימים, בנוסף גם נתייג את האובייקטים ו/או המשתתפים ו/או מקומות וכדומה, כדי שנוכל בשלב הניתוח לאפיין את הבעיה בצורה מדויקת.
לעומת הדרך הקלסית לפיתרון בעיות שהיא מוכוונת פיתרון, קיימת דרך אחרת לפיתרון בעיות שורש, הפועלת בגישה שהיא מכונות הזדמנות.שיטת 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 מכוסה על ידי שני תחומי תהליך:
זהו תהליך ניהולי, המטפל בתהליך הניהול האדמיניסטרטיבי של דרישות המוצר או השירות ורכיביהם. תהליך ניהול הדרישות מתחיל מקבלת דרישות מהלקוח/ות ומכל בעלי העניין שעשויים לתרום הגדרה של צרכים ו/או אילוצים לגבי המוצר. בעלי העניין יכולים להיות גם גופי רגולציה, גופים מוסדיים שונים בארגון ועוד. הלקוחות מגדירים דרישות במונחי מה נדרש לעשות (למשל: ביצועים, תכונות); כמו כן, מטפל התהליך בשינויים בדרישות.
זהו תהליך הנדסי, המתרגם את דרישות הלקוח לדרישות הנדסיות; מחלק את הדרישות לדיסציפלינות (למשל: חומרה/תוכנה) או תתי מערכות. לאחר שחילקנו דרישות לדיסציפלינות, כל דיסציפלינה אחראית על מימוש הדרישות שבאחריותה. לפעמים אותה דרישה תבוצע על ידי כמה דיסציפלינות. תהליך התכן מתחיל מהדרישות ההנדסיות.
מאמר זה דן בנושא ניהול הדרישות בלבד. נושא פיתוח הדרישות יטופל במאמר אחר.
תהליך ניהול דרישות שיטתי דואג שלאורך כל מחזור הפיתוח יהיה אוסף מוגדר ומאושר של דרישות. כמו כן תהיה הלימה בין תוכניות העבודה של הפרויקט ומוצרי הביניים המופקים בתהליך לדרישות המוצר. אין הכוונה שכל הדרישות יהיו מוגדרות בתחילת הדרך. בהחלט אפשרי לפתח במודל איטרטיבי או אג'ילי. במקרים אלה כל שייאמר להלן, ניתן להתאמה כשמדובר באיטרציות, או במנות אג'יליות.
חמש הפרקטיקות בנושא ניהול שיטתי, מוצגות בדיאגרמה שלהלן, ומפורטות בהמשך:
עשה | ואם לא תעשה… | |
הבנת הדרישות | הגדר מראש מיהם ספקי הדרישות המקובלים ואת הקריטריונים לקבלת הדרישות; השג הבנה מספקי הדרישות לגבי המשמעות של הדרישות; נתח את הדרישות וודא עם הלקוח שהבנת אותן. השג אישור מהלקוח לדרישות הבסיס ובכך רתום אותו לפרויקט המתהווה. | בהיעדר הגדרה ברורה ממי מקבלים דרישות, יש חשש מקבלת דרישות שאין צורך לבצען, או שיש סתירה בין ספקי הדרישות. במידה ואין אישור מהלקוח שדרישותיו הובנו, אין ערובה לכך שהמסר עבר במדויק; |
השגת מחויבות לדרישות | השג מחויבות מכל בעלי העניין בארגון לפיתוח המוצר או השירות בהתאם לדרישות. במקרים רבים, האישור יושג לאחר הבנה עמוקה של משמעות יישום כל הדרישות, וקבלת המשאבים הנדרשים. | אי אפשר להצליח ולסיים פיתוח מוצר או שירות שעומד בדרישות הלקוח בהיעדר מחויבות מגוף הפיתוח לפתח את המוצר בהתאם לדרישות. היעדר מחויבות מצד הפיתוח יכול לנבוע מאי הקצאת המשאבים הנדרשים. |
ניהול שינויים לדרישות | הבן את משמעות השינוי וההשפעה שלו על הפרויקט מבחינת משאבים ולו"ז וכן מבחינת ההשפעה שיש לשינוי בדרישות מסוימות, על דרישות אחרות, וקבל החלטה מושכלת אם וכיצד לטפל בשינוי. | קבלה פזיזה של שינויים בדרישות מבלי להבין את משמעותם, תגרום להתבדרות הפרויקט וחוסר שביעות רצון של הלקוחות ושאר בעלי העניין. |
ניהול עקיבות דו-כיוונית | נהל עקיבות דו כיוונית בין הדרישות המקוריות לדרישות ברמות נמוכות יותר, ובין הדרישות למוצרי ביניים של תהליך הפיתוח, עד לבדיקות המאשרות שכל הדרישות מומשו ונבדקו. | בהיעדר ניהול עקיבות קשה לדעת אם אכן כל הדרישות מומשו. כמו כן, במקרה של שינויים בדרישות מסוימות קשה לדעת במדויק על מה ישפיע השינוי. |
הלימה בין הדרישות לתוכנית העבודה | במהלך כל התנהלות הפרויקט, בדוק שתוכניות העבודה אכן ממשות את כל הדרישות, לפי אבני הדרך שבתוכנית. כלומר, שיש הלימה בין אבני הדרך והתכולה שתוכננה להיות מוכנה בכל אבן דרך. במידה ומצאת סטייה, עדכן את התכנית בהתאם (באמצעות ניהול השינוי). | עלולות להיווצר במהלך הפרויקט אי התאמות בין דרישות הלקוח/ות ותוכנית העבודה לחילופין, אי התאמות שנמצאות יכולות להיות מטופלות בצורה שאינה לוקחת בחשבון את השפעות השינוי. כתוצאה מכך, עלולים להיווצר פיגורים בלו"ז, או שיסתבר שהפרויקט לא ממש את התכולה המובטחת. |
בארגונים לא מעטים מצאתי שנושא ניהול ופיתוח הדרישות הוא "תפוח אדמה לוהט", שמעדיפים להעביר אותו מיד ליד ולדחות את הטיפול בו, עד ש…ימוסדו תהליכים אחרים, או יהיה תקציב מיוחד, או שמחכים לשינוי ארגוני שיגדיר פונקציה של הנדסת מערכות, או שיגדירו את האחריות לנושא בתפר שבין מנהל הפרויקט למנהל התוכנית, … ועוד כהנא וכהנא סיבות. ובינתיים – מתחילים לטפל בנושאים אחרים כמו ניהול בדיקות. קשה מאד לטפל בנושאים הקשורים לפיתוח מאמצע או מסוף הדרך. יתרה מזאת, תנאי לניהול בדיקות טוב הוא ניהול דרישות טוב! המלצתי – גשו ישר לעניין ! התחילו מההתחלה. בהצלחה!
==
האם הנושא מטופל בארגונכם?
איזה גוף אחראי לכך?
אשמח לשיתוף כיצד מנוהלות הדרישות בארגונכם; טוב? פחות טוב?
אשמח לשיתוף באחת הרשתות החברתיות שקישורן להלן
כוונת המשורר במשפט זה היא לעודד ארגונים למדוד את עצמם, כי המדידה הינה זרז ומוטיבציה לשיפור. אך אליה וקוץ בה! בגלל שהתופעה נכונה – אנשים ישפרו תהליכים ותוצאות כדי לשפר את המדידות. ומה קורה במקרים בהם מודדים את הדברים הלא נכונים?…..ניחשתם נכון! הדברים הלא נכונים ישתפרו !
רבות נכתב על נושא המדדים והמדידות במסגרות שונות ומגוונות. במאמר זה אביא את גישת מודל ה-CMMI לנושא. מודל ה-CMMI נחשב למודל הטוב בעולם בנושאי פיתוח, ניהול פרויקטים, תהליכי איכות ותמיכה והשילוב שלהם.
תהליך המדידות הוא תהליך התומך בתהליכים אחרים ואינו עומד בפני עצמו. כל הנאמר במאמר זה נדרש להיות מופעל על תהליכים אחרים אותם נרצה למדוד לצורך מעקב ו/או שיפור. מטרת תהליך המדידה וניתוח תוצאות המדידה היא לפתח יכולת ארגונית לספק נתונים למנהלים ברמות השונות, כדי לתמוך בתהליכי קבלת החלטות.
הפרקטיקות המעורבות בתהליכי המשנה מוצגות באיור שלהלן ומפורטות בהמשך.
בחירת המדידות כוללת גם תכנון מראש כיצד יאספו הנתונים וכיצד הם ינותחו. להלן תיאור הפרקטיקות הנדרשות. אפשר ואפילו סביר לבצע אותן בו זמנית.
| עשה….. | ואם לא תעשה… | |
| 1 | מדדו את הדברים הנכונים ! כדי למסד תהליך שיטתי למדידות עלינו להבין את יעדי הארגון וצרכי המידע, להחליט על סוגי המדידות ואופן ניתוחן שיתמכו ביעדים וצרכים אלה. היעדים נקבעים בתוכניות האסטרטגיות או העסקיות, או תוכניות הפרויקטים, או תוכניות שיפור התהליכים. המדידות שיקבעו בהתבסס על תוכניות אלה יעזרו בהמשך להחליט אם ההתקדמות היא בהתאם ליעדים שנקבעו. | ייתכן ולא תמדדו כלל, או שתמדדו דברים לא נכונים במדידות דברים לא נכונים נכללים סוגי מדידות שאינן בהתאם לנושאים החשובים לארגון. |
| 2 | קבעו ספציפית את המדידות ואת ערכי מטרה למדידות למשל: עבור יעד קיצור לו"ז, יוחלט למדוד את התקדמות הלו"ז; לשם כך, ייקבעו מדידות ספציפיות של עמידה באבני דרך, מדידת אחוז התקדמות הפרויקט מתוך סך כל הפרויקט, וכן מידת הדיוק בהערכות המדידות שעל פיהן נקבע הלו"ז. | יתכן ויהיו בעיות בתיאום הציפיות; אם נדרוש למשל קיצור לו"ז בצורה ערטילאית לא נוכל בהמשך לבחון אם ההתקדמות משביעת רצון. |
| 3 | קבעו את שיטות איסוף הנתונים ושמירתם שיטות איסוף הנתונים ואחסונם, כוללים את הגדרת המקור או המקורות מהם ייאספו הנתונים, לפעמים גם הגדרת כלים לאיסוף נתונים בצורה אוטומטית; הגדרה כזאת תבטיח שיושוו "תפוחים לתפוחים" בצורה אחידה ומשותפת לפרויקטים שונים בארגון. | יתכן ולא תאספו את הנתונים הנכונים, או שלא תהיה אפשרות לאסוף את הנתונים. |
| 4 | קבעו שיטות לניתוח הנתונים קביעת שיטות הניתוח מראש, כולל אופן הבקרה והדיווח, מבטיח שייעשה ניתוח נכון על המידע, וכן לבדוק שלא יהיו חסרים נתונים ברגע האמת | ייתכן ואיסוף הנתונים לא יעשה בצורה נכונה, או שלא יאספו מספיק נתונים שיאפשרו קבלת החלטות |
מדידות נכונות, המבוססות על עדויות אובייקטיביות מאפשרות לבקר ולנתר את התקדמות הפרויקט, ומאפשרות לקבל החלטות המבוססות על נתונים מהשטח, במקום תחושות סובייקטיביות.
| עשה….. | ואם לא תעשה… | |
| 1 | השיגו את הנתונים ! לאחר שתכננתם את אופן איסוף הנתונים, וסוגם – אספו את הנתונים; תהליך האיסוף כולל גם בדיקה שהנתונים נכונים והגיוניים. | אין טעם להסתפק בתכנון, בלי ביצוע |
| 2 | נתחו את הנתונים נתחו את הנתונים, כפי שתכננתם; במידת הצורך, עשו ניתוחים נוספים; סקרו את התוצאות עם בעלי עניין רלוונטיים, הבינו את משמעות התוצאות, והסיקו מסקנות; הכינו את הנתונים כמצגת או כדו"ח למול הקריטריונים להצלחה, כדי לאפשר למנהלים לקבל החלטות על סמך המידע שנאסף ונותח – אילו תוצאות משביעות רצון ואילו נושאים צריך לשפר. | תציגו נתונים שגויים ואולי מגמתיים, ובכך תאבדו את האמינות שלכם |
| 3 | שמרו את התוצאות שמירת הנתונים מאפשרת לנתח מגמות לאורך זמן, וכן להשוות להיסטורית פרויקטים קודמים או מקבילים. | ייתכן ותסיקו מסקנות שגויות כתוצאה מנתון נקודתי |
| 4 | תקשרו את תוצאות המדידות לבעלי עניין רלוונטיים הפצת המידע נעשית בצורה מחזורית וכן המידע נגיש למקבלי ההחלטות. המידע יכול להיות מופק בדוחות, או נגיש לאחזור. | לא דיווחתם לא עשיתם! |
דוגמה לסיכום
יעד עסקי: |
|
מידע נדרש: | הערכה (estimation) של זמן ההשקה |
מטרת המדידה: | לאפשר נראות ללו"ז הפרויקט, כולל יכולת להבחין בסטיות יחסית לתכנון |
סוגי מדידות: | זמן התחלה וסיום מוערך וזמן בפועל של התחלה וסיום של משימות |
מדידות: |
|
קבלת החלטות |
|
==
כיצד אתם מתמודדים עם נושא המדדים והמדידות?
האם אתם מתכננים מראש מה למדוד?
כיצד אתם קובעים ערכים למטרות המדידה?
האם מתקבלות החלטות ניהוליות על סמך ניתוח המדדים? אשמח לשמוע באחת הרשתות החברתיות שקישורן להלן.
לכל אחד מאיתנו מוכר המצב בו עלינו לבחור בחירה אחת מתוך מספר רב של אפשרויות. במקרים רבים אנו בוחרים בצורה שנראית לנו רציונאלית, ובמקרים אחרים בצורה אינטואיטיבית, כאשר אנו סומכים על התחושה שלנו לגבי הבחירה הנכונה. חלק מהבחירות שלנו הן אימפולסיביות. אמנם גם להחלטות האימפולסיביות יש רווחים, עיקריים או משניים, אולם במקרים רבים אם היינו מפעילים שיקול דעת – ייתכן והיינו בוחרים אחרת. מהו הפיתרון הטוב?
יתרה מכך – בהחלטות ארגוניות, כאשר יש מספר בעלי עניין, עם אג'נדות שונות ואף מנוגדות – איזה פיתרון ייבחר?
מודל ה-CMMI נתן את הדעת לסוגיה זו בתחום התהליך Decision Analysis and Resolution (DAR). בתחילה, נועד התהליך כדי לבחור בין מספר פתרונות טכניים לפיתוח מוצרים, למשל: בחירת ארכיטקטורה אופטימאלית מתוך מספר אפשרויות, או בחירת כלים. אולם, התהליך כוחו יפה גם לבעיות שאינן טכניות כלל, למשל: בחירת ספק או יועץ, בחירת המוצרים שייכללו בפורטפוליו ועוד כהנה וכהנה דוגמאות.
התהליך השיטתי מטפל בתהליכי ניתוח וקבלת החלטות. מטרת תהליך קבלת החלטות היא לנתח מספר אפשרויות-החלטה, תוך שימוש בתהליך הערכה פורמאלי הבוחן את אותן אפשרויות למול אוסף קריטריונים עליהם הוחלט מראש.
זהו נושא תומך, כלומר, הפרקטיקות בנושא זה תומכות בקבלת החלטות בכל הנושאים האחרים, הן ברמת הפרויקט והן ברמה הארגונית. למשל, בתהליך בחירת המוצרים שייכנסו לפורטפוליו המוצרים העתידיים. אין זה מספיק לזהות את כל המוצרים המועמדים, אלא יש לפרט מראש את קריטריוני הבחירה שיאפשרו את הבחירה הטובה ביותר: מידת החדשנות, מידת הידע שיש בארגון כדי לפתח ולתמוך במוצר, הפוטנציאל העסקי,ROI וכדומה.
התהליך הפורמאלי מפחית את האופי הסובייקטיבי של ההחלטה ומאפשר בחירה נבונה המתחשבת בצרכים שונים של בעלי העניין. להלן פירוט הצעדים בתהליך:
כאשר עלינו להחליט החלטה הרת-גורל, ברור שנרצה להפעיל תהליך שיטתי. גם ההיפך ברור – לא נפעיל את כל התותחים בשביל החלטות טריוויאליות. אולם, בחיים לא הכול שחור או לבן ורוב ההחלטות נופלות בטווח שבין שני מקרי הקצה שלעיל. כדי לתפקד היטב בטווח הזה – נדרשות הנחיות, המגדירות אם ההחלטה שעל הפרק היא כזו שנפעיל תהליך שיטתי כדי לקבל החלטה. דוגמאות להנחיות להפעלת התהליך:
|
בהיעדר הנחיות ברורות, ברוב המקרים לא יופעל תהליך שיטתי לקבלת החלטות חשובות; במקרים בודדים יופעל התהליך על החלטות חשובות פחות, ובכך יושהה תהליך קבלת ההחלטות, שגם זו בעיה. עדיף לקבל החלטה טובה היום, מאשר החלטה מושלמת מחר.
התהליך דורש להגדיר מראש את הקריטריונים שישמשו להערכה ואת שיטת ההערכה, כדי שציון ההערכה לא יהיה תלוי באופי המעריך (בית הלל או בית שמאי). למשל, הנחיות למתן ציונים לגבי בחינת "התאמה אסטרטגית" של כל מוצר מועמד:
| נושא | 1 | 4 | 7 | 10 | ציון |
| מידת התאמת הפרויקט לאסטרטגיית הארגון | התאמה מינורית | התאמה קטנה. לא פרויקט מפתח | התאמה טובה; מתאים במספר נושאים | התאמה חזקה לאסטרטגיית הארגון | 6 |
| מידת התאמת הפרויקט לאסטרטגיה של קו המוצרים אליו מיועד | התאמה מינורית | התאמה קטנה. לא פרויקט מפתח | התאמה טובה; מתאים במספר נושאים | התאמה חזקה לאסטרטגית הארגון | 7 |
| חשיבות אסטרטגית | מינורית; לא ייגרם כל נזק מהשמטת הפרויקט | בינוני; בעל השפעה פיננסית מורגשת | חשוב; יהיה קשה להצליח אם הפרויקט לא ייכנס לפורטפוליו או ייכשל | גבוה מאד; עתיד הארגון תלוי בפרויקט זה | 8 |
| ציון משוקלל | 70 | ||||
בנוסף, המנגנון קובע אם לתת משקל שונה או זהה לכל אחד מהקריטריונים. למשל:
| קריטריון | משקל | ציון |
| התאמה אסטרטגית | 15% | 70 |
| יתרונות תחרותיים | 15% | 70 |
| סינרגיה עם היכולות הנוכחיות | 15% | 59 |
| הזדמנויות/ סיכונים טכניים | 15% | 37 |
| התאמה לשוק | 20% | 45 |
| הזדמנויות/סיכונים פיננסים | 20% | 43 |
| ציון משוקלל | 50 | |
בהיעדר מנגנון הערכה, תהליך קבלת ההחלטה לא יתחשב בכל הגורמים המשפיעים על תוצאת ההחלטה או שיהיה תלוי באופי המעריכים או בהעדפותיהם האישיות.
קיימים מספר פתרונות אלטרנטיביים לאותה בעיה; בעלי עניין שונים – יעדיפו פתרונות שונים; בשלב זה של התהליך עורכים רשימה של כל הפתרונות האפשריים.
ברור שיש יותר מפיתרון אחד כאשר מפעילים תהליך שכזה. שלב זה מטרתו לוודא שלא נדלג בטעות על פיתרון אפשרי, או שנוריד פיתרון מרשימת הפתרונות במחי יד ובלי שיקול דעת.
בוחרים מראש את השיטה או השיטות להעריך את הפתרונות השונים, למול הקריטריונים שנבחרו להיות כלולים במנגנון ההערכה. רמת הפירוט של השיטות צריכה להיות פרופורציונאלית להחלטה מבחינת עלות, לו"ז, ביצועים, והשפעה על רמת הסיכון. דוגמאות לשיטות הערכה:
|
תהליך הערכת הפתרונות כולל מחזורים של ניתוח, סקירות ודיונים; הבחינה כוללת גם ניתוח סיכונים של כל האפשרויות. במקרים בהם תהליך הערכה לא מאפשר להבחין בצורה משמעותית בין פיתרון אפשרי אחד לשאר הפיתרונות, נדרש לחזור ולבחון – האם הפתרונות המוצעים שונים משמעותית זה מזה? האם נלקחו בחשבון כל הקריטריונים הרלוונטיים?
שלב זה משווה בין כל הפתרונות שנבחנו; לחלק מהקריטריונים יינתן משקל שונה מהשאר; ייבחר הפיתרון שקיבל את הניקוד הגבוה ביותר. חשוב לזכור שההחלטה המתקבלת אינה נעשית בצורה רובוטית-אוטומטית, אלא בדיון של מקבלי ההחלטות על סמך הנתונים המובאים לפניהם. למשל – כאשר יש מספר רב של קריטריונים ולגמר מגיעים מספר מועמדים עם הבדל קטן בניקוד.
תהליך שיטתי טוב לקבלת החלטות יביא להחלטות דומות, גם כאשר מקבלי החלטות שונים עוברים את התהליך. יתרון נוסף לתהליך השיטתי הוא בכך שנעשה תהליך שמתחשב בכל הגורמים בטרם תתקבל החלטה, ובוחן אותם לעומק למול הקריטריונים שנבחרו מראש. כלומר: זהו תהליך שמטייב את תוצאות ההחלטה. תיעוד התהליך והשיקולים עוזר גם בהמשך הדרך כאשר מתפתים לשנות את ההחלטות ושוכחים את הסיבות שהביאו להחלטה; הארגון לומד וצובר ניסיון במשך הזמן, שכן החלטות חדשות יסתמכו על התהליך השיטתי שנעשה עבור ההחלטות הקודמות.
ניהול נכסי התהליך הארגוני הוא תהליך המטפל בבניית כל התשתיות הארגוניות הנדרשות להגדרה ותיאור של התהליכים הסטנדרטים בארגון. התשתית כוללת: נהלים, מדריכים, הנחיות, תבניות, כלים תומכי תהליך, ועוד. הנושא נשמע מאד לא אטרקטיבי, ואוזנינו נוטות להיסתם כשהנושא עולה. כמו כל נושא תשתיתי – למשל כבישים ומדרכות – הנושא אינו מושך תשומת לב ועניין רב. ומה יקרה בהיעדרו? לא נוכל לטפל בכל הנושאים המעניינים המסתמכים על תשתיות אלה. נהיה עסוקים כל היום בפילוס דרכנו בסבך הג'ונגל הארגוני.
אחד מתחומי התהליך של מודל CMMI הוא ניהול נכסי התהליך הארגוני –Organizational Process Definition, השם דגש על תשתית ארגונית טובה כדי לאפשר עקביות בניהול ותפעול. תשתית כזו מאפשרת לצבור את הידע הארגוני ב"מגירות" ובכך לשתף ידע ושיעורים הנלמדים משימוש בתהליכים מיטביים (best practices) או תהליכים שאינם מתאימים.
האיור שלעיל מתאר את שבעת המרכיבים של תשתית תהליכית, ואילו הן:
1 | אוסף נכסי התהליכים של הארגון | אוסף הנכסים אמור לכסות את כל הצרכים של התהליכים של הארגון; נכסים אלה אמורים לתמוך בואריאציות: לפי מבנים ארגוניים, יחידות עסקיות, קווי מוצר, סוגי שירותים ועוד. יכולים להיות מספר תהליכים "מותאמים" (tailored) מהסטנדרט כדי לתמוך בסוגים שונים של מחזורי-חיים של מוצרים או דיסציפלינות. |
2 | תיאורים של סוגי מחזור חיים | התהליך הארגוני המשותף יכול לתמוך במספר סוגי משפחות תהליכים, כדי לתמוך בסוגים שונים של תהליכי פיתוח, למשל על פי מחזור חיים: מפל מים, אג'ייל, ספירלה, אינקרמנטלי, איטרטיבי, ועוד. לכל סוג מחזור חיים – תשתית תהליכית שונה של מסמכים ותבניות. |
3 | הנחיות וקריטריונים להתאמת התהליך | ההנחיות מתארות כיצד להתאים לפרויקט ספציפי את התהליך המתאים לו ממשפחת התהליכים הנתמכים בארגון. התאמות אלה הכרחיות כיון שיש שוני בין הפרויקטים וניסיון לכפות תהליך אחיד אינו מתאים לכולם. מאידך, ההנחיות נדרשות כדי להבטיח שרק התאמות מאושרות יתקבלו ולא איש הישר בעיניו יעשה. |
4 | מאגר מדידות של הארגון | מאגר המדידות כולל מדידות לגבי תוצרי התהליך של פיתוח פרויקטים ומוצרים; כמו כן המאגר מכיל מידע שעוזר לפרש את תוצאות המדידות. |
5 | ספרייה עבור הנכסים הארגוניים | ספריית הנכסים יכולה להיות אלקטרונית; הספרייה מכילה את הנכסים בצורה הגיונית המאפשרת אחזור בעת הצורך. |
6 | סטנדרטים של סביבות עבודה | מאפשר לארגון להפיק תועלת מכך שתת-ארגונים משתמשים באותם כלים, הדרכות וכדומה. התועלות מתבטאות החיסכון תודות לרכש משותף ולשיתוף ידע וניסיון. |
7 | חוקים והנחיות לצוותים | הנחיות לגבי יצירת צוותים; נושאים הקשורים לחוק, רגולציות, אחריות וסמכות של בעלי תפקידים שונים. |
1 | אוסף הנכסים התהליכים של הארגון אינו מוגדר | כל מנהל נאלץ להמציא מחדש את הגלגל עבור הפרויקט/מוצר/ שירות שבאחריותו |
2 | יש תהליך אחיד לכל הפרויקטים | אילוץ להכניס את כולם לאותה שבלונה, יגרום להתנגדות גדולה לאמץ את התהליך הארגוני על ידי מנהלים ועובדים בפרויקטים שהשבלונה לא מתאימה להם |
3 | היעדר הנחיות וקריטריונים להתאמת התהליך | איש הישר בעיניו יעשה. למשל: מנהל של פרויקט גדול יחליט לאמץ תהליך מקוצר של פרויקט קטן, ובכך יפגע בניהול האופטימלי של הפרויקט שלו. |
4 | היעדר מאגר מדידות של הארגון | מקשה על הערכות לגבי פרמטרים שונים של תכנון פרויקט חדש; |
5 | היעדר ספרייה עבור הנכסים הארגוניים | בלגן! |
6 | חוסר סטנדרטים של סביבות עבודה | סביבות עבודה שונות מקשות על שיתוף ידע, עולות הרבה יותר כסף ברכישה ובניהול |
7 | היעדר חוקים והנחיות לצוותים | בלגן! |
במהלך המו"מ לפני הרכבת ממשלת ישראל ה-33 חזינו בתופעה מעניינת של שת"פ בין לפיד ובנט. לפני הבחירות התחרו השניים (וסיעות נוספות) על הגדלת כמות המצביעים אחד על חשבון רעהו, ושאר המתחרים. במהלך המו"מ להרכבת הממשלה, הניב השת"פ שלהם תוצאות טובות יותר לשניהם ביחד וכל אחד לחוד, מאשר לו כל אחד מהם היה מתחרה לבד על עקרונות, קווי יסוד ותיקים; יתרה מזאת – שאר המתחרים בזירה, בעיקר נתניהו, נותרו מופתעים מהאסטרטגיה החדשה.
Co-opetition היא אסטרטגיה עסקית המורכבת משיתוף פעולה (Cooperation) ותחרות (Competition); מטרתה: שיתוף פעולה בין מתחרים כדי להשיג יתרונות שאי אפשר היה להשיגם בדרך אחרת. הגישה העסקית המסורתית התייחסה לסך הרווח האפשרי "כסכום אפס". כלומר: המנצח לוקח את נתח העוגה העיקרי והשאר מתחלקים בשאריות. רעיון ה- Co-opetition הוא שמתחרים המשתפים פעולה, ביחד זוכים בנתח גדול יותר מסכום הנתחים אם לא היו משתפים פעולה ביניהם.
כיצד ייתכן הדבר? הדבר אפשרי, כיוון שגם למתחרים יש נושאים משותפים, ואם ישתפו פעולה – שניהם יצאו נשכרים יותר מאשר אם יתחרו זה בזה בכול. כאשר מספר מתחרים פועלים באותו שוק – ניצחון או זכייה של מתחרה אחד תהיה על חשבון שאר המתחרים. זהו Win-Loseקלסי . למשל: מכרז בו אחד זוכה על חשבון כל השאר. תחרות משמעה – חלוקה של העוגה בחלקים כלשהם בין המתחרים. שיתוף פעולה בין שני מתחרים יעניק לשניהם יתרונות על פני שאר המתחרים: 1) יש יותר ממנצח אחד; 2) נתח העוגה בו כל מתחרה-משת"פ זוכה הינו גדול יותר יחסית מהנתח אותו היה מקבל אם היה לבד בתחרות. מתחרים המשתפים פעולה ביניהם (למרות המחלוקות) משנים את חוקי המשחק, בו שאר המתחרים מתכתשים ומאבדים אנרגיה ומשאבים בתחרות עצמה.
Coopetition שונה מ- Cooperation, בכך ששיתוף הפעולה מתרחש בשדה התחרות. שיתוף פעולה "רגיל" קורה במקרים בהם חברות או אנשים מגדילים את העוגה בזכות השת"פ. בדרך כלל הדבר יקרה כאשר למשת"פים יש אינטרסים שמשלימים זה את זה. למשל: חברה ותיקה עם משאבים, לקוחות וקשרים משתפת פעולה עם חברה צעירה לה יש טכנולוגיה מתקדמת בתחום החברה הותיקה. דוגמה אחרת: שיתוף פעולה בין חברה המפתחת חומרה לחברה המפתחת תוכנה, היוצר מוצר משותף עם ערך מוסף ללקוח הגבוה יותר מאשר סכום הערך של מוצר החומרה והתוכנה.
כלומר – Co-opetition משלב יתרונות של Cooperation עם Competition ==> מלחמה ושלום.
האיור שלהלן, מתאר את זרימת הערך בסביבה העסקית:
ספקים – מספקים משאבים לכל החברות בסביבה עסקית הרלוונטית;
מתחרים – כל החברות, שמבחינת ראות הלקוחות שלנו, גורמים למוצרים או השירותים שלנו להיראות פחות אטרקטיביים;
משתפי פעולה – חברות שהמוצרים שלהן מוסיפים ערך/משלימים את המוצרים שלנו, מבחינת ראות הלקוחות שלנו.
אסטרטגיית ה-Co-opetition מראה שכדי להביא יותר הזדמנויות עסקיות ולהגדיל רווחים, עדיף להפסיק להשקיע מאמצים אינסופיים בלהיות יותר טובים מהמתחרים, אלא לנסות ולהגדיל את סך ההזדמנויות המשותפות למתחרים על ידי שיתוף פעולה המביא תועלת בעלת ערך גבוה יותר.
כדי לשנות את חוקי המשחק, צריך לשנות את צורת הפעולה של אחד או יותר מחמשת האלמנטים הבאים:
שחקנים – אפשר לשנות את תמהיל המשתתפים – מתחרים ומשתפי פעולה עבור החברה;
הוספת ערך – החברה שתוסיף הכי הרבה ערך לשרשרת הערך המתוארת באיור שלעיל, תהיה בעלת השליטה במשחק;
שינוי חוקי המשחק – כאשר אפשר לשנות את חוקי המשחק (ביושר) אפשר לשנות את משחק הכוחות בשוק;
טקטיקות – אפשר לשנות את חוקי המשחק באמצעות שינוי התפיסה של השחקנים בזירה;
תכולה – כאשר מבינים את חוקי המשחק בזירות המשיקות לזירה בה אנו מתחרים, והמשפיעות על הזירה שלנו, אפשר להשיג יתרון תחרותי תוך הזזת גבולות הגזרה.
על הנייר, היו אמורים שני מנהיגי הסיעות הנ"ל להתחרות מול כל שאר הסיעות על כיסאות בממשלה, ועל עיצוב סדר היום לאחר הבחירות, כאשר לכל סיעה אג'נדה משלה. השניים השכילו לשתף פעולה על בסיס המשותף שלהם. בשת"פ זה הם בהחלט שינו את חוקי המשחק, והשיגו תוצאה הרבה יותר טובה לכל אחד מהם, מאשר לו היו מתחרים לחוד.
מקור:
Co-Opetition : A Revolution Mindset That Combines Competition and Cooperation : The Game Theory Strategy That's Changing the Game of Business, Adam M. Brandenburger , Barry J. Nalebuff
האם אתם מכירים דוגמאות נוספות ל-co-opetition ? אשמח לשמוע את תגובתכם בתיבה למטה; דוגמאות מעניינות אשקול להוסיף למאמר.
| מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
