מובילי שינוי בארגונים, מנהלי איכות ומצויינות, מהנדסי תעשיה וניהול, מנהלי ארגון ושיטות אמורים ליצור תהליכים מיטביים, ליזום שיפורים ולוודא שהארגון פועל לפי התהליכים שנקבעו. בהתאם לצורך, הם אמורים להמליץ על תוכנית מתקנת. התוכנית המתקנת יכולה להיות מקומית ברמת פרויקט או צוות, או ברמה יותר רחבה באמצעות מיסוד תהליך ארגוני חדש.

האם אותם מובילי שינוי מתנהלים בעצמם בהתאם לאותם כללים וחוקים אותם הם מחילים על שאר האנשים בארגון? כלומר: האם הם מכינים תוכנית שנתית לניהול השינוי, האיכות ושיפור התהליכים? האם הם עובדים על פי יעדים? על פי תקציבים נתונים? האם הם משקיעים את המאמצים בעיקר ולא בטפל? האם תוכניות השינוי והשיפור "מיושרות" על פי אותה תוכנית שנתית, או שהם נסחפים בעקבות הזדמנויות הנקרות בדרכם? האם סדר העדיפות של השקעת המאמצים נעשה לפי ROI? לפי מה שחשוב באמת? או שמא הסנדלר הולך יחף?

,Organization Process Focus או מיקוד הארגון בתהליכים, הוא אחד מהנושאים בהם מטפל מודל ה-CMMI. מאמר זה נכתב בהשראת המודל בנושא תכנון שיטתי של תהליכי השיפור בארגון. היתרון בפעולה עפ"י המודל הוא בכך שהתהליך המוצע נסקר ובוצע במאות ארגונים ברחבי העולם; בעקבות היישום באותם ארגונים, התקבל משוב, שגרם למודל להשתכלל ולהשתפר. מצאתי שנושא מיקוד הארגון בתהליכים מתאים לכל סוגי הארגונים באשר הם. לדוגמה: תהליכי מכירות, רכש, משאבי אנוש ועוד.

למה נועד תהליך ,Organization Process Focus או מיקוד הארגון בתהליכים ?

מטרת התהליך היא לתכנן, ליישם ולממש פעילויות שיפור בארגון המבוססות על הבנה יסודית של החוזקות וחולשות הנוכחיות של תהליכי הארגון. באומרנו תהליכי הארגון – הכוונה לכל התהליכים בארגון.

הכנת תוכנית השיפור

הכנת תוכנית השיפור מורכבת משלושה צעדים:
1) זיהוי הזדמנויות לשיפור
2) תכנון ויישום פעולות השיפור
3) הטמעת השיפור בארגון, כולל עדכון השיפור כתוצאה משיעורים הנלמדים במהלך ההטמעה

זיהוי הזדמנויות לשיפור

"מועמדים" לשיפור מגיעים ממקורות מגוונים: תוכניות אסטרטגיות המזהות תהליכים הדורשים שיפור,תחקירים והפקת לקחים מפרויקטים שבוצעו, מדידות שנעשות על איכות התהליכים ו/או איכות המוצר ו/או איכות השירות, ממצאים ממבדקים פנימיים או חיצוניים, משוב שהתקבל מלקוחות, תוצאות בנצמרק יחסית לתהליכים של ארגונים דומים או מתחרים, וכן יוזמות שיפור שמגיעות ממנהלים בארגון. הנושאים הדורשים שיפור יכולים לבוא מדיסציפלינות שונות: טכנולוגיות, כספים/חשבות, שירות, פיתוח ועוד. במה נבחר?

כדי שהמאמץ יושקע בכיוון הנכון, דבר ראשון נדרש לזהות את צרכי ויעדי הארגון, ולתעדף אותם בצורה אובייקטיבית. קיימות שיטות רבות לתעדוף. על אחת השיטות, תוכלו לקרוא במאמר – שיפור תהליכים – איפה נקודת ההתחלה ? ; חשוב מאד שהתעדוף יהיה על פי יעדי הארגון וישתף את בעלי העניין הרלוונטיים; לפני שמתחילים, יש לקבל את ברכת הדרך מההנהלה הבכירה. כידוע לכולנו, פעילויות שיפור חייבות להיות "מיושרות" עם הדרך שבה הנהלת הארגון מנהיגה אותו. לאחר שהדרך והמטרה ברורות, נדרש לערוך מבדקים סדרתיים כדי להיות כל הזמן עם היד על הדופק: לזהות חוזקות ולשמר אותן, וכן לזהות חולשות ולמנף אותן לפעולות שיפור; כתוצאה מהמבדקים מזוהות הזדמנויות נוספות לשיפור; שוב יש לתעדף אותן בהתאם לצרכי ומטרות הארגון, וחוזר חלילה. לא נתבלבל עם עניין ה"חוזר חלילה"; כל שנה היעדים והמטרות משתנים במקצת ומקבלים דגשים שונים. לכן נדרש לרענן את רשימת הצרכים והיעדים לפחות אחת לשנה. גם המבדקים הסדרתיים מקבלים דגשים שונים מידי שנה ובהתאם לכך – גם פעולות השיפור.

תכנון ויישום פעולות השיפור

פעולות השיפור מתוכננות ומיושמות. כלומר – נדרש להכין תוכנית שנתית; כל תוכנית שיפור – נדרש להגדירה כפרויקט התחום בזמן, בתקציב, ביעדים מוגדרים, עם צוות ייעודי, המחויב לתוכנית ומקבל את ברכת הדרך מהמנהלים המוודאים שאכן פעילות השיפור מסונכרנת עם צרכי ויעדי הארגון. במקרים מסוימים, לפני מעבר להטמעה רחבה, יתוכנן ויבוצע פיילוט (ניסוי) על פרויקט או שניים. הפיילוט מאפשר לנסות את התהליך החדש בשטח, להפיק לקחים, ולשלב את השיעורים הנלמדים בתכנון פעולות השיפור בטרם תחל ההטמעה הרחבה.

הטמעת השיפור בארגון, כולל עדכון השיפור כתוצאה משיעורים הנלמדים במהלך ההטמעה

כתוצאה מפעילות השיפור, נדרש לייצר פעולות ומנגנונים כדי שיבטיחו שהשיפור ימשיך להיות מיושם גם אחרי שצוות השיפור יסיים את תפקידו. הבטחת המשכיות השיפור הינה אתגרית אף יותר מיישום השיפור עצמו. זאת, כיוון שבתקופת מסוימת, צוות או מוביל נושא ממוקדים בפעולת השיפור ודואגים לכך שהשיפור ייושם. האתגר הוא שהשיפור יהיה בר קיימא, ולא "שגר ושכח". אחת הדרכים לעשות זאת היא באמצעות שדרוג נהלי העבודה הקיימים, כך שיכילו גם את התהליך המשופר;

נאה דורש, נאה מקיים !

פעילות השיפור השנתית צריכה להיות מתוכננת בדיוק כמו כל פעילות אחרת. יוזמות השיפור שייכנסו ל"פורטפוליו השיפורים" יעמדו למבחן על סמך תרומתם והתאמתם לרשימת הצרכים והמטרות של הארגון.  פעילות השיפור תנוהל כפרויקט לכל דבר, ותכלול יעדים ומטרות, תכולה, תקציב וכדומה. בהצלחה!

האם אתם מתכננים את פעילויות השיפור בארגון שלכם? אילו פעולות נקטתם כדי שהשיפור יהיה בר קיימא? אשמח למשוב באחת מהרשתות החברתיות שלהלן.

אני מברכת אתכם על התעניינותכם.
ניצור איתכם קשר בהקדם.

אני מתחייבת שלעולם לא אעביר את כתובת הדואר האלקטרוני שלך לצד שלישי.

עד אז, מוזמנים לקרוא ולהעמיק בשפע המאמרים באתר, ראו –שיתוף ידע לפי נושאים

כמו כן, מוזמנים להצטרף לקבוצת WHATSUP שקטה, בה אנו משתפים אחת לשבוע-שבועיים מאמרון / טיפ בנושא הקשור לאיכות ומצויינות בארגונים.
לוחצים כאן ומצטרפים.

בברכה,
אורנה קמין
מנכ"לית OK יועצים לניהול

 

 

 

 

 

  •  איך נגיע מאיכות למצוינות?
  • איך להשיג הצלחה בת קיימא בארגון?
  • האם 9001 ISO מספיק לנו?
  • האם שמעתם על תקן לניהול אסטרטגיה?
  • מי שמע על תקן ISO 9004/ IQNET 9004   ? (סודי, אמרנו?)
ארגונים רבים במסעם לשיפור האיכות "מיישרים" את התהליכים שלהם לפי תקן 9001 ISO. בהתחלה, הטמעת מערכת איכות מבוססת 9001 ISO מביאה שיפור באיכות התהליכים ובשביעות רצון הלקוחות. לאחר שנתיים שלוש של עבודה לפי תקן בסיסי זה, ארגונים רבים מחפשים את השלב הבא. זאת כיוון שישנם צרכים שאינם מקבלים מענה במסגרת תקני 9001 ISO.
קיימים כמובן מודלים מתקדמים יותר, ואחד מהם, IQNET 9004, ובגרסתו "המגוירת": ת"י 9004 ISO, הוא נושא כתבה זו. מודל זה שייך למשפחה של מודלים למצוינות עסקית, החובקים את כל הדיסציפלינות בארגון, הרבה מעבר למודלים הבסיסיים המטפלים באיכות התוצרים או התהליכים בנושא ספציפי (כגון: מודל CMMI שמתמקד בפיתוח מוצרים ו/או שירות, 27001ISO שמתמקד בנושא אבטחת מידע, ועוד רבים אחרים).
תקן זה הינו מורה דרך להשגת הצלחה בתקיימא של הארגון בסביבה מורכבת ומשתנה באופן תמידי, באמצעות גישת ניהול איכות  כוללת. כדי להצליח לאורך זמן, על הארגון לזהות את כל בעלי העניין החיצוניים (כגון: לקוחות וספקים) והפנימיים (מנהלים, עובדים) ולהבין את צרכיהם וציפיותיהם. בעקבות זאת, לתכנן את המענה לציפיות אלה בדמות תהליכים המבטיחים התנהלות אפקטיבית ושרידות לאורך זמן.
התקן מדריך את הארגון להיות מודע וללמוד באופן שוטף את הסביבה המשתנה, החיצונית והפנימית של הארגון, וליזום ולחדש כדי להשיג את המטרות שקבע לעצמו. תקן זה דוגל בהערכה עצמית ככלי חשוב לסקירת רמת הבְּשֵׁלוּת של הארגון (רמה 1 עד 5). הוא דן בהתנהלות הארגון מבחינת מנהיגות ההנהלה בארגון, ניהול אסטרטגיה, ניהול משאבים ותהליכים, ניהול בעלי עניין וניהול איכות. הוא מדריך לאתר חוזקות וחולשות בתהליכי הארגון, במטרה לשפרם. יכולת ההערכה עצמית של הארגון (את עצמו) חיונית להצלחה בת קיימא כיוון שהיא מאפשרת שיפור מתמיד, ולא רק כתוצאה ממבדק חיצוני המתרחש פעם  ב- 1-3 שנים. תקן ISO 9004/ IQNET 9004 תוכנן כך שתשמר עקביות ותאימות עם תקנים אחרים לניהול כגון 9001 ISO.
נכון לרגע כתיבת המאמר, בודדים הנועזים שאמצו תקן זה וראו ברכה גדולה לעמלם. מדוע מעטים? כיוון שהתקן אינו נדרש על ידי הלקוחות; דווקא בגלל זה – ארגונים הרוצים לבלוט בתחרות, ולעשות אחרת מה-main-stream, מוזמנים לשדרג את תהליכיהם לפי מודל זה.
הציור שלהלן1, נלקח מתוך ת"י 9004 ISO ומראה כיצד מרחיב תקן זה מעבר ל-9001 ISO.
להלן הרחבות תקן ISO 9004/ IQNET 9004  המתמקד בניהול איכות כוללת, מעבר ל9001 ISO, המתמקד בניהול איכות בסיסית:

ניהול אסטרטגיה ומדיניות כללית של הארגון – ההנהלה מגדירה ייעוד, חזון וערכים לארגון, ובעקבותיהם מדיניות ואסטרטגיה החובקת את כל פעילויות הארגון לטווח ארוך, ולטווח קצר. האסטרטגיה מתורגמת ליעדים בטווח הארוך והקצר ונבנית תוכנית להשגתם, תוך כדי תכנון לו"ז ומשאבים נדרשים. ההנהלה סוקרת את מימוש האסטרטגיה בנקודות בדיקה, ומוודאת שהאסטרטגיה מתעדכנת בעקבות השינויים בסביבת הארגון הפנימית והחיצונית. האסטרטגיה מתוקשרת לארגון.

ניהול משאבי הארגון – הארגון מזהה את המשאבים הנדרשים להשגת מטרותיו. ההרחבה מעבר ל9001 ISO מתבטאת בנושאים להם מנהלים את המשאבים, שכאמור, אלה נושאים הכוללים את כל פעילויות הארגון, במובן הכי רחב שאפשר: משאבים פיננסיים, משאבים אנושיים כולל משאבים הנדרשים לשמור על כשירות ומוטיבציה גבוהים, ספקים, תשתיות, סביבת עבודה, ידע, מידע וטכנולוגיה, ואינטגרציה של כל המשאבים תוך ניהול סיכונים והזדמנויות.

ניהול תהליכים – ניהול פרו-אקטיבי של כל תהליכי הארגון, כך שיאפשרו את השגת המטרות ביעילות. הארגון מגדיר תהליכי תכנון, בקרה על התהליכים, ואחריות וסמכות של בעלי העניין בהפעלת התהליכים, והממשקים שלהם לתהליכים אחרים.

ניתור, מדידה, ניתוח וסקירה – ההרחבה מעבר ל9001 ISO היא לנושאים עליהם מפעילים את מתודולוגיות המבדקים, הסקירה והמעקב אחר המדדים, כגון: נושאי שיווק ומכירות, החלטות הנהלה המבוססות על עובדות ונתונים בנוסף לתחושות בטן, ועוד.

שיפור, חדשנות ולמידה – לרוב הארגונים, שיפור מתמיד, חדשנות והתחדשות הינם חיוניים להשגת הצלחה בת-קיימא. התקן מעודד שיטתיות בתהליכי שיפור, חדשנות ולמידה כדי לתמוך בחדשנות וצמיחה.

מזכיר את מודל הפרס הלאומי לאיכות ומצוינות – מה ההבדל?

שני המודלים הינם מודלים המכוונים למצוינות כוללת בארגון, ומכילים אוסף של כללים המדריכים כיצד לנהל את הארגון בצורה טובה. ההדרכה מתבססת על ידע שנצבר ושוכלל במשך שנים על ידי מאות ארגונים בעולם. בשני המקרים, נדרשת התאמה בין המודל האוניברסאלי לארגון הספציפי. ההבדל המרכזי הוא, שמודל הפרס הלאומי מהווה במקרים רבות מאמץ חד-פעמי לצורך השתתפות בתחרות, בעוד ש-ISO 9004/ IQNET 9004  מהווה מודל לשיפור מתמשך.

כלי להערכה עצמית של איכות התהליכים

המודל מכיל כלי להערכה עצמית לפיו כל ארגון יכול לתכנן את מסע השיפור שלו לפי הנושאים בהם תומך המודל, תוך קביעת הרמה הרצויה בכל נושא. כדי למנוע מצב בו מעריכים שונים, נותנים ציונים שונים לאותה שאלה באותו נושא, התקן מגדיר במפורש את רמת התהליכים הנדרשת (ע"ס עדויות ולא ע"ס תחושות) בכל אחת מהרמות 1-5. הרמה נקבעת ע"ס אוסף של שאלות וקריטריונים, כאשר לכל שאלה מוגדר במפורש מה נדרש מהתהליך כדי להיות ברמה 1-5. ציון הנושא מושג על ידי  שקלול רמת כל השאלות השייכות לאותו נושא. כלי הערכה עצמית זה מאפשר לארגונים לעשות את התהליך בעצמם, לזהות פערים בין המצוי הקיים למצב היעד, ולהכין תוכנית לסגירת הפער. אחת לשנה עד שלוש שנים נעשה מבדק על ידי סוקר חיצוני בלתי תלוי ואובייקטיבי. מלבד הפער אותו מזהה הסוקר החיצוני בתהליכי החברה, ניתן בנוסף אף לבדוק את רמת ההערכה העצמית של הארגון ולהשתפר אף בכך. בדרך כלל, ארגונים נוטים להעריך את עצמם ברמה גבוהה יותר ממה שיחשוב הסוקר החיצוני; השוואת ציונים תעזור לשפר את תהליך ההערכה העצמית. כתוצאה מהפער שנוצר בין היעדים שהושגו, לאלה שטרם הושגו, מכינים תוכנית לשיפור כולל משאבים ולו"ז להשגתה.

הציור שלהלן1  נלקח אף הוא מהתקן. הקו הירוק – מציין רמה 5 בכל הנושאים שהיא הרמה המקסימאלית; הקו האדום מתאר את היעדים בכל אחד מהנושאים. הקו הכחול מתאר את הרמה שנמצאה במבדק. כיוון שהתקן מדריך בצורה מפורשת מה נדרש לעשות כדי להיות ברמה נתונה, ניתן להכין תוכנית לסגירה או צמצום של הפער.

רצוי שארגון יכין תוכנית ריאלית במסעו להשגת מצוינות בת קיימא. תוכנית כזו תתבסס על מבדק אבחון שייקבע את הרמה הנוכחית, ובעקבותיה יקבע את הרמה הבאה, שאותה תשיג תוכנית השיפור. לאחר השגת היעדים, קובעים תוכנית חדשה עם יעדים אגרסיביים יותר, וחוזר חלילה. לא בהכרח, השגת רמה 5 בכל הנושאים, תהיה מטרת הארגון.

סיפור מקרה – הטמעת תקן 9004 ISO 9004/ IQNET לניהול הצלחה בתקיימה של ארגון בחטיבת השירות של מוטורולה סולושנס ישראל

חטיבת השירות במוטורולה סולשנס ישראל רואה עצמה כמובילה לא רק את ארגוני השירות של מוטורולה בארץ אלא את ארגוני השירות בארגון העולמי כולו. לכן החליטה החברה בשנת 2009 להטמיע את מודל ISO 9004/ IQNET 9004 בחטיבת השירות.

ממבט על, תהליך העבודה לפי התקן נראה דומה לתהליך אותו עוברים כדי לקבל אישור מסוקר חיצוני להטמעת כל תקן בארגון. המיוחד כאן, שהתהליכים הנסקרים הם התהליכים המטופלים על ידי המודל, וכאמור מטפלים במצוינות ארגונית כוללת.

שלבי התהליך שנעשו כדי לקבל הכרה שחטיבת השירות מנוהלת על סמך עקרונות ISO 9004/ IQNET 9004, מובאים להלן:
1. פגישה עם סוקר חיצוני כדי להתאים את המבדק החיצוני לארגון הנבדק.
תהליך זה כלל בחירת הנושאים הרלוונטיים, והתאמת השאלות לארגון השירות. לא כל הנושאים והשאלות המתאימים לחברה, מתאימים לחטיבה בתוך הארגון. בנוסף, היה צורך להתאים ולתפור את השאלות לארגון שירות, על סמך אינטרפרטציה של השאלות הכלליות לסביבת ארגון שירות.
2. ביצוע מבדק ראשוני
לאחר קבלת תבנית השאלות עם הפרקים הספציפיים המובנים ומותאמים לחטיבת השירות נשארו 214 שאלות למענה . השאלות חולקו ע"י מנהל האיכות לתחומים המתאימים למובילי תהליך באגפים והקבוצות בחטיבת השירות של מוטורולה סולשנס ישראל. כל מנהל אגף וראש קבוצה התבקש להעריך את מצב התהליכים שבתחום אחריותו, ובנוסף – להכין מענה הכולל גם הוכחות וראיות לפעילות האיכות בקבוצה שלו שיכולות להדגים כי אכן פעילות האיכות עומדת בתנאי התקן.
3. ביצוע ראיונות אישיים
מנהל האיכות של חטיבת השירות בצע "ראיון אישי" בן כמה שעות עם כל אחד מהמנהלים בארגון, כדי לאבחן את המצב ולזהות את הפער מול רמה 5 בכל הנושאים.
4. ריכוז ממצאים
מנהל האיכות ריכז את כל הנתונים מהתהליך ע"ג טופס ממוחשב הכולל את המענה לשאלה, הערכה לגבי הציון, ואוסף העדויות התומכות במענה.
5. סגירת פערים
כתוצאה מהמבדק הראשוני, הראיונות, ואיסוף העדויות – הוכנה תוכנית לסגירת הפער להשגת רמה 5 כוללת. חלק מהמאמצים לשיפור, הוטלו על מנהלי האגפים; חלקם – נעשו בסיוע מנהל האיכות של החטיבה.
6. שיתוף סוקר מכון התקנים בתהליך
כל פרק שנשלמה הכנתו הועבר מידית לסוקר מכון התקנים כדי שגם הוא יוכל לראות, בשקיפות מלאה, את כל מענה החטיבה עוד לפני שהוא מגיע לסיקור עצמו. כך יכול היה הסוקר להכין הסתייגויות ו/או המלצות לשיפור בצורה מעמיקה, מעבר לזמן הקצר באתר החברה.
7. בוצעו מקצה שיפורים בתהליכים
תהליכים שזוהו כחסרים – עברו תהליך שיפור שיטתי, כדי שיעמדו בהצלחה ביעד שנקבע – רמה 5.
8. קיום המבדק
לקראת המבדק החיצוני – הוכנו כל העדויות לסוקר; בסיום הסיקור הובאו התוצאות לפני הנהלת החטיבה, ומשתתפים נוספים בתהליך.
9. הכנת תוכנית מתקנת
בעקבות המבדק, הוכנה תכנית מתקנת מפורטת.

לאחר המבדק, מתכונן הארגון למבדק חוזר, כשנה לאחר המבדק הקודם.

תוצאות , תוצאות ו…עוד תוצאות

בעקבות המבדק הראשון, בוצעו שיפורים בנושאים מגוונים בחטיבת השירות. הוקם פורטל איכות ייעודי לחטיבת השירות, הכולל בין היתר את תוכניות ויעדי השיפור. האתר מתעדכן באופן תקופתי. באתר מוצגים יעדי איכות של כל אגפי השירות. הדבר הביא למודעות העובדים את הצורך בעמידה ביעדים אגרסיביים, בשיפור מתמיד ובחתירה למצוינות.
השוואת ביצועים, בין המצב שהיה לפני המבדק ב2009 למצב ב2012, לקראת מבדק חוזר מראה שיפורים מספריים לכל אורך הדרך. רק לשם המחשה – מדידת אי-איכות. המדידה מודדת פעולות בהן משקיעה חטיבת השירות זמן יקר, אך למעשה הן בזבוז, והיו יכולות להימנע אם הניהול היה איכותי יותר. לדוגמה: שעות עבודה המושקעות בביקור חוזר אצל לקוח, כיוון שהתקלה לא טופלה בביקור הראשון. כתוצאה משיפור תהליכים מסיבי, השקעה בהדרכות טכנאים וטכנולוגיות שירות ירדה ההשקעה בעבודה מיותרת זו מלמעלה מ 100 שעות ב 2010 ועד …פחות מ 40 שעות ב 2012. כמובן שהחיסכון הכספי הוא חשוב אך העיקר כאן היא הפחתת אי שביעות הרצון ממקרים שבהם נדרש ביקור חוזר כיוון שהטכנאי לא סגר את הבעיה בביקור אחד.
הישג חשוב נוסף הוא השיפור בשביעות רצון הלקוחות. בשנת 2010 הושגה רמת שביעות רצון ממוצעת של  כ-88% מהלקוחות שנתנו לחברה ציון 5 (הגבוה ביותר) בשלל שאלות סיקור איכות; בשנת 2012 רמת שביעות הרצון עומדת על 93% מהלקוחות שנתנו לחברה ציון 5.

ביצוע Benchmark יחסית לשוק השירות בחו"ל

מוקדי שירות לקוחות, של חברות שמטפלות באתרי קשר, מקבלים הודעות על תקלות. חברות אחרות דומות לעיסוקן בתחום השירות (שמות ספציפיים ניתן לקבל בפנייה למחברים) מסיימות לתקן 50% מהתקלות ביום כניסת התקלה למוקד. שאר התקלות מטופלות למחרת או מאוחר יותר.

חברת מוטורולה סולושנס מסיימת לתקן למעלה מ 72% מהתקלות בו ביום. איך נעשה הדבר ? באמצעות שימוש נרחב בטכנולוגיה מתקדמת, הצבת ציוד גיבוי מתאים באתרי הקשר, שליטה מרחוק במרכזי מערכת לקוח ושיפורי תהליך נוספים שנעשו בעקבות העבודה עם התקן.

סוף דבר

השקעה בתהליכי שירות, מאפשרת למוטורולה סולושנס ישראל להתמודד עם האתגרים של שירות איכותי.  ארגונים עושים הרבה כדי למשוך לקוחות חדשים, אך לא תמיד מקפידים לשמור על הלקוחות הקיימים.  מיסוד תהליכי שירות מסייע גם לשמור על בסיס הלקוחות של החברה, וגם למשוך לקוחות חדשים, ובכך תורם להצלחה העסקית של החברה כולה.

באופן דומה, כל ארגון שישקיע בתהליכי הליבה שלו, ייעל את תהליכיו וישפר את מיצובו יחסית לתחרות. אחד היתרונות המרכזיים של השימוש בתקן הוא בכך שהוא מכניס את נושא ניהול האיכות והמצוינות לכל תהליכי הליבה בחברה בצורה סדורה ושיטתית; כמו כן, השימוש בתקן הוא למעשה הצהרה של החברה שתהליכי איכות ומצויינות רלוונטיים לכל הדיסציפלינות בחברה. 

ביבליוגרפיה:
SI 9004  – תקן ישראלי ת"י 4 ,900 ISO 9004 – Third edition: 2009-11-01, June 2010

המאמר פורסם בעיתון האיגוד הישראלי לאיכות, חודש אוקטובר 2012

מעניין מאוד לדעת – כמה מן הקוראים יסכימו עם מה שבחרתי ככותרת של המאמר הפעם!

אנו לומדים כמה קשה בימים טרופים אלה לשכנע ארגונים, שניהול חדשנות הוא לא מותרות אלא הכרח קיומי! אכן חשוב מאוד לחסוך בהוצאות בתקופה כזו, אבל טעות ניהולית היא לפגוע ביכולת של הארגון לצמוח, ביכולתו למצות הזדמנויות. בעולם משתנה בקצבים הולכים וגדלים מסוכן מאד לחסוך בחדשנות, שכן מה שהיה מוצלח בעבר – כשהתנאים היו שונים – לא בהכרח יצליח בעתיד ובמציאות החדשה. אולם למרות עובדה זו – רובנו הגדול לא רואה בשמירה על הקיים סיכון. סיכון מתקשר בתודעה לחדשנות בלבד. קרן הון סיכון מטפלת בחדשנות.  נוטים לקשור את הסיכונים להתנעת מיזם חדש מחוץ לארגון או פרויקט חדש בתוך הארגון. ואכן – לא כל הדברים החדשים יצליחו, אבל בסביבה סוערת, אם רק נתאמץ לשמר את הקיים ניכשל בוודאות! אפילו התייעלות שאנו מצווים עליה תמיד, ובימים של משבר כלכלי עולמי ביתר שאת מתמיד – גם היא זקוקה לחדשנות כדי להצליח! ניסיון להתייעל בדרכים שגרתיות עלול לגרום ליותר נזק מתועלת!

בעבודתנו כיועצים למנהלים אנחנו מתמודדים עם האתגר הזה עכשיו בימים טרופים אלה יותר מתמיד: איך מחוללים את השינוי הגדול הזה בתפיסת הניהול – מאמונה, שהחדשנות היא מסוכנת – להבנה, שיש בה הסתברות גדולה יותר להצליח מאשר בשמירה על הקיים? שכן מניסיוננו למדנו, שההצלחה בנושא ניהול החדשנות מתחילה בטיפוח תרבות מעודדת יזמות ונטילת סיכונים. אם אתה מעודד את אנשיך ליזום, אם אתה מעריך ומוקיר אותם גם כשהיוזמה לא הצליחה במלואה או אפילו לא הצליחה כלל, אם אתה מגדיר את היוזמה והחדשנות כערכים מרכזיים בארגון – אתה בדרך המובילה לניהול סיכונים כהלכה!

במקום ניהול סיכונים – ניהול אופטימיות

ניהול סיכונים הוא כלי לעידוד חדשנות. והנה רעיון חדשני שלמדתי מעמית בחו"ל – להחליף את המונח ניהול סיכון ב"ניהול אופטימיות". אם ב"ניהול" אנחנו מתכוונים ל "שליטה בהקצאה של משאבים"  – אזי סיכון הוא מחוץ לשליטתנו, אבל אנחנו יכולים לנהל את הגישה שלנו לסיכון! טעות נפוצה בניהול היא אופטימיות יתר, האמונה שאפשר לגבש תכניות ולצפות שהדברים יתרחשו כמתוכנן.

אמנם בניהול פרויקטים יש לאופטימיות מקום חשוב. היא מרכיב מרכזי ביזמות, ויזמות היא סוג הניהול שפרויקטים זקוקים לו. אבל אופטימיות היא "מחלתם המקצועית" של מנהלים בסביבה פרויקטאלית – מהמנכ"לים של סטארטאפים ועד למנהלי פרויקטים בארגונים גדולים, והיא תורמת לכישלונם של פרויקטים מתוך עיוורון לסיכונים שבפרויקט. לכן כדאי באמת ל"נהל אופטימיות" ולא סיכונים והיעד הוא להגיע  לאופטימיות זהירה. בליווי מנהלים בפרוייקטים גדולים ומורכבים מצאנו שאכן זה סוד ההצלחה. (להזכירכם, רק כשליש מן הפרויקטים מצליחים לעמוד ביעדי הפרוייקט המרכזיים – איכות,  זמן ותקציב!) לעיתים מסתבר לנו, שאנחנו משמשים כמנוע העזר לאופטימיות זהירה לצוות המנהל את הפרוייקט!

אופטימיות זהירה

אופטימיות היא גישה חיובית, מעצימה ורציונאלית.  זו גישה לכל אירוע בחיים מתוך אמונה, שאתה יכול להשפיע על התוצאה לטובה. גישה אופטימית זהירה טובה ממנה. היא אינה מתעלמת מן המציאות, מסימני אזהרה, מאירועים, אנשים, מחשבות ורגשות לא נעימים, אבל היא מאפשרת להשתחרר מן ההיבטים השליליים בחיים על ידי התמקדות באותן החלופות, שיש להן סיכוי ליצור תוצאות מועילות.

האופטימי הזהיר פורץ גבולות באמצעות בחינה רציונאלית וחשיבה יצירתית , בעוד שהפסימיסט פשוט לא מחפש פיתרון ואילו האופטימי הלא זהיר שבוי בקונצפציה מסוכנת גם מול מציאות משתנה! אופטימיות זהירה יוצרת ביטחון עצמי מבוסס על הערכה עצמית בסיסית שמאפשר לאדם לדמיין ולממש את חלומותיו. לא אשליה, אלא הבנה של תפקידך אתה ואחריותך שלך בדרך להשגת יעדים ריאליים. כי אין הצלחות ללא נטילת סיכון, אבל כשאתה מנסה להגשים חזון אפשר למזער סיכונים אם אתה אופטימי זהיר. איך עושים זאת? מניחים מראש שהתכנית מכילה סיכונים ומשפרים אותה שוב ושוב תוך כדי תנועה. ממשיכים לאתר במרץ הזדמנויות לשיפורה! ממשיכים לחפש ללא פחד איומים למימושה ומטפלים בהם. מסמלצים (מלשון סימולציות) מה שאפשר, יוצרים פיילוטים ככל הניתן, משתפים פעולה עם אחרים כדי לשלב יכולות ולפזר סיכונים! (אנחנו לא רק מטיפים לאחרים אלא נוהגים כך בעצמנו בקבוצת הייעוץ שלנו ומשתפים פעולה אפילו עם מתחרים כדי להתחדש בעצמנו ולסייע ללקוחותינו להתחדש!)

מבחן הדופק המואץ

בתקופה של האטה כלכלית כולם בודקים את הארנק. למדנו מרנדי קומיסר, יועץ לחדשנות בעמק הסיליקון ומרצה באוניברסיטת סטנפורד, "לבדוק את הדופק לפני שבודקים את הארנק". בימים קשים הכול בודקים קודם כול סיכונים פיננסיים ומשמעויות כלכליות בדרך למימוש החלומות. אבל לדעת קומיסר – השאלה החשובה היא שאלת הלב ולא שאלת הארנק! הוא מייעץ: שאל את עצמך – האם הרעיון החדש מאיץ את הדופק שלך? קומיסר עובד רק עם חברות שמאיצות את הדופק שלו! הוא מאמין, שרק החלטות אותנטיות, כאלה שמונעות על ידי הערכים האמיתיים שלנו, על ידי מה שחשוב לנו באמת בחיינו, מובילות אותנו להצלחה! גם אנחנו בכל ארגון בוחנים את המורשת הארגונית כדי לאתר מה הביא אותו בהצלחה עד הלום – שם טמונים ערכי האמת שלו – מתוכם ניתן לצאת לדרך החדשה עם סיכויי הצלחה טובים. למדנו שלרעיונות חדשים המנותקים מן היכולת הארגונית, מיתרונו היחסי, מן ההיסטוריה שלו, אין סיכוי טוב להצליח! לעומת זאת לרעיון חדש שמשלב להט של יזם עם ידע קיים בארגון ומחויבות לתרום לליבה שלו – לו יש סיכויי מימוש טובים יותר.

מנהיגות בניהול בסביבה מסוכנת

כאמור, בימים קשים בעולם של חוסר ודאות אנשים נוטים להימנע מסיכונים מפחדים ונרתעים מיוזמה. תפקידם של מנהיגים לעזור לארגון לצלוח את המצבים שנתפסים כמסוכנים מאוד בשל חוסר וודאות ולספוג חלק מחוסר הודאות על ידי גיבוש הנחות עבודה שלפיהן יחליטו ויפעלו בארגון. כמנהל, כשאינך יודע מה יקרה – תניח מה יקרה ותנחה את אנשיך לפעול בהתאם. הסכנה הגדולה ביותר במצב של חוסר ודאות היא שארגונים ייכנסו לקיפאון שבו לא קורה כלום, כי כולם ממתינים למידע, להתבהרות המצב! כמנהל עליך לספוג לפחות חלק מחוסר הודאות שמשתקת את אנשיך ולקבוע יעדים – וכך תחזיר להם  את הביטחון לנוע קדימה! לדאבוני בארגונים אנחנו מוצאים לא פעם, שגם המנהלים נותנים לחרדות שמקורן בחוסר הודאות להשתלט עליהם ומשדרים זאת לאנשיהם, וכך הארגון כולו לוקה בשיתוק – תופעה מסוכנת לכשעצמה.

אסור להיכנס לפאניקה וחרדה! עדיף להיות זהירים תמיד, ואולי אפילו פרנואידים תמיד, כמו שלמדנו מאנדי גרוב, המנהל האגדי של אינטל. עדיפה פאניקה מוקדמת, שמייצרת פעילות למזעור הסיכון, מאשר פאניקה מאוחרת ומשתקת.

קרן הון סיכון ארגונית

המומחה המוערך בעולם לניהול חדשנות – גרי האמל – מציע "להכניס את עמק הסיליקון לתוך הארגון". ללמוד מן התרבות ומן הכלים של האזור החדשני ביותר בעולם, עם מספר הסטארטאפים הגדול ביותר בעולם (ישראל שנייה לו!) כיצד לנהל חדשנות גם בתוך ארגונים. אחד הכלים הנפוצים לניהול בעמק הסיליקון ובעולם המיזמים החדשים בכלל הוא "קרן הון סיכון". קרנות כאלה משדרות לבעלי הרעיונות החדשים – בואו אלינו – אצלנו מוכנים ליטול סיכונים ולעזור לך להגשים את חלומותיך! ויש אכן ארגונים ותיקים וגדולים, שכבר הקימו "קרן הון סיכון" פנימית שמשמשת כתובת לבעלי הרעיונות החדשניים בתוך הארגון וכך מעודדת תרבות של יוזמה וחדשנות! בקרן הון הסיכון הפנימית, כמו בחיצוניות, עוזרים ליזם הארגוני לממש את רעיונו. מסייעים לו להכין תכנית עסקית, בוחנים יחד איתו את סיכויי המימוש בכל ההיבטים – הכלכלי, הטכנולוגי המשפטי ועוד – הכול לפי העניין. אם נמצא שהרעיון מוצלח, שיש לו קונים בתוך הארגון באחת היחידות הקיימות, מעבירים אותו כפרוייקט למנהל שמוכן לקלוט אותו אצלו. אם לא נמצא כזה – מוכנים אפילו לסייע לבעל הרעיון לממשו מחוץ לארגון במתכונת של מיזם חדש – בשותפות עם הארגון!

ארגון חפץ חיים, ארגון בר-קיימא, חייב להקצות הון סיכון לבחינה ולמימוש של רעיונות חדשים. ללא נכונות להשקיע, תוך כדי נטילת סיכון, ביוזמות חדשות – מותו ודאי! כאמור, הכי מסוכן לא להסתכן!

תפקיד חדש – מנהל סיכונים

גם בניהול החדשנות וגם בתפעול הקיים יש סיכונים ולצורך התמודדות, יש כבר ארגונים שמינו "מנהלי סיכונים". תפקידם של אלה להבהיר למנהלים בארגון מהם הסיכונים שהם עומדים בפניהם. – CRO Chief Risk Officer מנהל הסיכון הארגוני מדווח למנכ"ל, מקים רשת של נאמנים ביחידות העסקיות (במתכונת דומה לנאמני בטיחות ונאמני איכות ונאמני ידע) ומנחיל בארגון תרבות של ניהול סיכונים. וכמו בניהול בכלל כך גם בניהול סיכונים – אין ניהול בלי מדידה. ומדידה מתחילה באיסוף מידע. ויש כבר מערכות מידע ארגוניות, שאוספות נתונים מכל רחבי הארגון על כלל הסיכונים ומעבדות אותם למידע תומך החלטות.

בעולם הבנקאות הצטבר ניסיון במדידת סיכונים פיננסיים ( אמנם מסתבר שלא מספיק…)  אולם בטיפול באלה לא די.  יש לפתח יכולות ארגוניות גם בניהול סיכונים לא פיננסיים, למשל סיכונים תפעוליים ובטיחותיים, סיכונים משפטיים וסיכונים למוניטין ועוד . פיתוח יכולת חדשה מתחילה ביצירת מודעות -בלמידה, ממשיכה ביצירת מחויבות – בהגדרת יעדים, ועוברת לביצוע ולבקרה עליו. תהליך זה אמנם מחייב הקצאת משאבים – אבל גם מביא תועלת, הוא מפחית את רמת חוסר הוודאות, ומייצר תכניות מגרה לתסריטים שונים, מקצר את זמן התגובה, כשאחד מן הסיכונים מתממש, ונוסך ביטחון בארגון להמשיך לעסוק גם בחדשנות בימים קשים!

חדשנות גם בלמידה

אנו מאמינים שלמידה ארגונית היא המרכיב החשוב ביותר גם בניהול סיכונים – למידה מהצלחות ולמידה מטעויות, אולם בעולם משתנה בקצב הולך וגדל גם הלמידה ושיטותיה צריכות להתחדש! לפעמים מסוכן ללמוד מן העבר.

בעולם הצבאי יודעים את המגבלה הזו היטב – ובכל זאת ידועה האמרה – שהצבא תמיד מתכונן למלחמה שהייתה במקום למלחמה שתהיה! חשוב לשכוח (unlearn!) – את מה שכבר לא רלבנטי, לא יעיל, לא אפקטיבי. מעניין שבאנגלית יש זיקה גדולה יותר בין הלמידה והשכחה – learning ו –unlearning  . זה טוב בעיני שכן זה מזכיר לנו גם את חשיבות הקרבה בין השניים במהות. השילוב שבין שני אלה הוא לב לבה של החשיבה המדעית. בסיומו של פרסום מדעי תמצאו מה עוד יש לחקור באותו נושא ובאילו נסיבות  ממצאי המחקר הנוכחי יופרכו. זו תרבות שאנחנו מסייעים גם לארגונים שאינם אקדמיים לאמץ.  בעידן המידע והידע הלמידה הארגונית היא יכולת הליבה המרכזית של כל ארגון ויש חשיבות רבה לנהל את הלמידה עצמה כתהליך של התחדשות מתמדת. תחקיר והפקת לקחים הם לב ליבה של הלמידה, שכן אנחנו לומדים יותר מכל מן ההתנסות של עצמנו, אבל רצוי שנזכור שגם לקחים מתיישנים ואת אלה שהתיישנו יש למחוק מן הזיכרון הארגוני, שכן הם תוקעים ומקבעים אותו במקום לקדם אותו. הידע מתחדש בקצב מהיר. מצער למצוא שיש ארגונים שמשקיעים את מירב המאמץ בניהול הידע שלהם בהקמת מחסני נתונים, מידע, לקחים ותובנות שמתיישנים במהירות!

בסביבה סוערת שום אסטרטגיה אינה אופטימאלית, ולכן יש לעצב סביבה ארגונית שמעודדת ניסויים  – עיצוב פרוייקטים שמאפשרים ללמוד, להסתגל ולשנות. וחשוב להעז לנסות דברים שיש בהם חידוש אמיתי ולא רק שיפור של הקיים. חבל לבזבז משאבים על ניסוי של משהו שאיננו חדש באמת. בניסוי רדיקלי כולם חייבים לחדש וכך כולם לומדים. (ותועלת נוספת – אם אתם מרבים בניסויים, המתחרים לא מסוגלים לפענח מה אתם בדיוק עושים!) תרבות של ניסויים מאפשרת לנו ללמוד מהר גם מה קורה מחוץ לארגון ומאפשרת להעריך מחדש את האסטרטגיה באופן רציף! אתה מנסה, לומד, משנה, מנסה שוב וחוזר חלילה. זו הדרך הנכונה והיעילה ללמוד! דרך זו מקטינה סיכונים בסביבה של חוסר ודאות!

____________________________________________________________________

הכותבת היא יו"ר קבוצת יועצים לניהול – www.pasher.co.il  – המתמחה בייעוץ אסטרטגי ובניהול חדשנות גם בהתייעלות!

כידוע לרבים מאיתנו, פוסט מורטם הוא תהליך שעושים לחולה לאחר שהוא מת כדי להבין את סיבת המוות. בהשאלה, משתמשים במושג כדי לבצע הפקת לקחים בסוף שלב, או בסוף פרויקט. ארגונים בעלי תהליכים בשלים מאד גאים בתהליכי הפוסט-מורטם שלהם, ובשיעורים שנלמדים בפרויקט אחד ומיושמים בפרויקט אחר.

האם לא עדיף לקיים את דיון הפקת לקחי הפרויקט, לפני שהוא נכשל בהשגת חלק מיעדיו, ובכך למנוע כישלונות אלה?

יד על הלב, כמה מאיתנו באמת חוקרים בהתחלת פרויקט את השיעורים שנלמדו בתהליכי פוסט-מורטם שבוצעו בפרויקטים דומים, ומנסים בצורה פרו-אקטיבית למנוע את הישנותם?

מאמר זה מציע טכניקה שונה לביצוע התהליך, Pre-Mortem, לפני שהחולה/הפרויקט מת, כדי לזהות כשלים לפני שהם קורים. טכניקה זו פורסמה לראשונה על ידי גרי קליין (Gary Klien) ופורסמה בשנת 2007 ב- Harvard Business Review במאמר בשם "Performing a Project Pre-mortem".

לעומת פוסט-מורטם, תהליך של Pre-Mortem חוקר סיבות עתידיות לכישלון הפרויקט טרם סיומו. את ה- Pre-Mortem מבצעים לאחר שכבר הוכנה תוכנית לפרויקט. ה-Pre-Mortem מציע לנוכחים במפגש סיעור המוחות, שידמיינו שהפרויקט כבר הגיע לסיומו, ומה הם יגידו בישיבת ה-Post-Mortem של אותו הפרויקט. מסתבר ששינוי מחשבתי קטן כזה, עוזר לאנשים להשתחרר מההגנות על התכנון שלהם. בישיבות פוסט-מורטם, במקרים בהם הפרויקט לא עמד ביעדיו, לא תמיד אנשים מוכנים לשתף את הסיבות האמיתיות לאי-ההצלחה, ונכנסים למגננה. לעומת זאת, דיון "פוסט מורטם" בטרם עת, מאפשר בקלות יתרה לחפש גורמים פוטנציאלים לאי-הצלחה.

בנוסף, תהליך הpre-mortem מתגבר על הקשיים הבאים, הקורים בתהליך post-mortem:

  • בפוסט מורטם חברי הצוות מנסים להגיע לקונצנזוס, ולא לפגוע, ובכך הולך לאיבוד מידע חשוב. במקום זאת, בתהליך של פרה-מורטם חברי הצוות מחפשים את האילוצים שמונעים זרימה חלקה של ניהול הפרויקט.
  • בפוסט מורטם, יש אנשים שחוששים להצביע על אחרים כאחראים לאי-הצלחה. בפרה-מורטם יותר קל להעלות חששות בתחום אחריות של חבר צוות אחר.
  • תהליך הפרה-מורטם הוא תהליך עם עלות נמוכה, כיוון שהוא תהליך של מניעה. לעומת פוסט-מורטם שדן באירועים (נזקים) שכבר התרחשו.

כאשר מדמיינים את סיום הפרויקט, ועושים בדמיון תהליך של Post-Mortem – מצליחים להגיע לרשימה של סיכונים יותר ריאלית מאשר ללא טכניקה זו.

תיאור פגישת Pre-Mortem

מתבצעות הפעולות הבאות:

  1. הכנה –חברי הצוות מתכנסים, לאחר שקראו את תכנון הפרויקט, או שתכנון הפרויקט מוצג בפניהם; על מנת למקד את סיעור המוחות, ולמנוע מצב של "מטרות נעות ומשתנות", הצוות מסכם מהם יעדי הפרויקט, שאי השגתם מהווה סיכון:
    •  יעדי לו"ז, תכולה או תקציב הפרויקט  אשר אי השגתם מהווה סיכון לפרויקט
    • יעדי איכות המוצר או רמת הביצועים שלו אשר אי השגתם מהווה סיכון למוצר
    • יעדי ביצועים פיננסיים, מוניטין וכדומה  אשר אי השגתם מהווה סיכון עסקי לארגון המפתח את המוצר
  2. "מסע בזמן" – המשתתפים מתבקשים לדמיין שבידם כדור בדולח בו ניתן לראות את העתיד. כרגע הם בישיבת Post-Mortem  בסוף הפרויקט. חברי הצוות מתבקשים לחשוב מה יגידו בישיבת פוסט-מורטם של הפרויקט שלהם. כל אחד מהמשתתפים רושם על מדבקות צהובות את הסיבות שלדעתו "גרמו" לכשלים או הצלחות. המקור לסיבות לכשלים של כל אחד הוא חששות מכל נושא אפשרי בפרויקט, ולא רק הנושאים שבתחום אחריותו. במידת האפשר, מתארים על ציר הזמן של הפרויקט – מתי קרו האירועים.
  3. הכנת רשימת סיבות לכישלון או הצלחה – כ"א מהמשתתפים רושם את הסיבות לכישלון, לדעתו. כאן באה לידי ביטוי האינטואיציה של כל אחד מחברי הצוות. כל חבר צוות מדמיין אירועים אחרים.
  4. איחוד הרשימות האישיות לרשימה כוללת של כל הסיכונים בפרויקט. מוביל סיעור המוחות מסתובב בין שולחנות המשתתפים, מבקש מכל אחד מהמשתתפים, להצהיר בכל רם על סיבה אחת לכישלון או הצלחה; הסיבות נרשמות על הלוח, או שמדביקים את המדבקות הצהובות. עוברים בתור במספר סיבובים – כל משתתף בתורו מצביע על סיבה אחרת לכישלון. בסוף התהליך, יש רשימה מקיפה של סיבות וחששות לפרויקט. מקבצים את הסיבות לקטגוריות, על ידי הזזת המדבקות וקיבוצן לפי קטגוריות.
  5. דיון בוחרים 2-3 סיבות שזוהו כגורמות לכישלון גדול. מגדירים במשותף מהו החשש בדיוק, ומה ניתן לעשות כדי לשכך את עוצמתו, או למנוע את היווצרותו.
  6. תודה מודים למשתתפים ומתפזרים.

הערה : ניתן לעשות גם Pre-Mortem  לפני כל שלב בפרויקט ובאותה צורה להתמקד בחשיבה על גורמים להצלחה או אי הצלחה בשלב שעומד לפניהם.

לאחר פגישת Pre-Mortem 

מתבצעות הפעולות הבאות:

  1. סיכום פגישה – מנחה הדיון מסכם את כל הנושאים שעלו בדיון.
  2. הכנת רשימת סיכונים – מנהל הפרויקט עובר על רשימת החששות שעלו ב-Pre-Mortem  ומתרגם אותם לסיכונים. הסיכונים מוכנסים לטבלת מעקב. כל סיכון עובר ניתוח (הסתברות? השפעה?); הרשימה כולה עוברת תהליך של תיעדוף, כדי לטפל באותם הסיכונים שיכולים לגרום לנזק מרבי לפרויקט. נעזרים גם בזמני התרחשות האירועים כפי שזוהו  ב-pre-mortem.
  3. ניהול סיכונים – טבלת הסיכונים מנוהלת כחלק מתהליך הבקרה של הפרויקט.
  4. חזרתיות – תקופתית חוזרים על תהליך ה-Post Mortem כדי לזהות סיכונים נוספים.

מה בין pre-mortem לניהול סיכונים?

אחת הטכניקות המתקדמות בנושא ניהול פרויקטים, היא טכניקה של ניהול סיכונים. ניהול סיכונים, מתבצע בהכנת תוכנית הפרויקט ולכל אורך חיי הפרויקט, ונועד להפחית את השפעת הסיכונים על השגת יעדי הפרויקט במהלכו ובסופו.

תהליך ניהול סיכונים מורכב מהשלבים הבאים:

  1. זיהוי סיכונים – הכנת רשימת סיכונים;
  2. ניתוח סיכונים – מבחינת ההסתברות שיקרו, ומידת השפעתם השלילית על השגת יעדי הפרויקט;
  3. תכנון אופי הטיפול בסיכון – הכנת תוכניות למניעת סיכונים או לשיכוך השפעתם;
  4. ניטור הסיכונים – מעקב אחר הסיכונים – האם ההסתברות שיקרו או ההשפעה שלהם השתנתה? האם הסיכון הפך לבעיה?

מאמר זה מתמקד בשלב הראשון של ניהול סיכונים – הכנת רשימת סיכונים ראשונית. אחת הטכניקות להכנת רשימת סיכונים ראשונית, היא לקיים פגישת "סיעור מוחות". בפגישה זו המשתתפים מציעים "מועמדים" לסיכונים, כאשר איש לא מבקר, פוסל או שופט את המועמדים של משתתף אחר. תהליך pre-mortem מסייע ליצירת רשימת הסיכונים הראשונית.

מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים.
קישור להצטרפות – כאן

 

רקע

לעיתים קרובות פרויקטים מתקשים בניהול הסיכונים שלהם. מדוע? מכיוון שהגדרת המונח "סיכון לפרויקט" מעורפלת אצלם. במאמר זה אסביר ואחדד את הגדרת המונח "סיכון". אראה שהמפתח לניהול סיכונים אפקטיבי בפרויקט הוא התמקדות, על בסיס תוכנית העבודה, בזיהוי אירועים העלולים לגרום לתוצאות שליליות בפרויקט. אסקור שגיאות נפוצות בזיהוי ובתיאור סיכונים, ואציג בקצרה טכניקה לזיהוי סיכונים.
לא אגע בשיטות לניתוח ולדירוג סיכונים, וכן לא אציג פעולות אפשריות למניעה או הפחתה של סיכונים. אשים את הדגש על הגדרה מועילה של המונח סיכון, שהיא התנאי לזיהוי יעיל של סיכונים. לבסוף אתן מספר המלצות הקשורות לזיהוי סיכונים.

מהו "סיכון לפרויקט" ?

מהו "סיכון" ? האם כל דבר "מסוכן" הוא "סיכון" ? האם כל דבר שלילי הוא סיכון ?

הגדרה: סיכון

סיכון הוא אירוע בחיי הפרויקט, המקיים את הקריטריונים הבאים:

  • עתידי – האירוע עדיין לא קרה
  • לא ודאי – יתכן שיקרה ויתכן שלא
  • ‏ספונטני – אינו בשליטת הפרויקט
  • ‏ספציפי – נוגע להיבט מאד קונקרטי ומוגדר של הפרויקט
  • מזיק – אם יתרחש, יביא לפגיעה ביעדי הפרויקט
  • סיבתי – האירוע הוא הגורם לתוצאה השלילית (ולא התוצאה עצמה)

סיכון הוא אירוע

סיכון הוא אירוע אשר אם יקרה – ישבש את עמידת הפרויקט ביעדים שנקבעו: כסף, לו"ז, תכולת המוצר.
שגיאה נפוצה: התייחסות לדבר שאיננו אירוע כאל סיכון, לדוגמא: "מודולA  הוא סיכון".
בניתוח הסיכון נרצה להעריך את סבירותו. אין משמעות ל"סבירותו של מודול A". סבירות תמיד מאפיינת אירוע.

סיכון הוא אירוע עתידי

סיכון הוא אירוע אשר טרם קרה (וגם ייתכן שכלל לא יקרה). אירוע מזיק או משבש שכבר קרה נקרא "בעיה".
בעיה מצריכה פעולה מתקנת (Corrective Action), בדרך כלל בדחיפות גבוהה. סיכון, לעומת זאת, מצריך פעולת מונעת (Preventive Action), וזה מאפשר חשיבה מוקדמת, הצעת חלופות ובחירה ביניהן.
שגיאה נפוצה: התייחסות לאירוע שכבר קרה כאל סיכון, לדוגמא: "ציוד הבדיקה שרכשנו הגיע עם תקלות".
זאת בעיה, קרי, סיכון שהתממש. את זה כבר לא ניתן למנוע, אלא רק לתקן.

סיכון הוא אירוע לא ודאי

סיכון הוא אירוע שיש לגביו אי ודאות. אין בטחון שיקרה, ואין גם בטחון שלא יקרה. החלטות לגבי טיפול בסיכון צריכות תמיד להתקבל בתנאי אי הודאות הללו. שגיאה נפוצה: התייחסות לאירוע עתידי ודאי כאל סיכון, לדוגמא: "המפתח הראשי יוצא למילואים בחודש הבא למשך 4 שבועות".
זהו לא סיכון אלא אילוץ. תוכנית הפרויקט חייבת להתחשב, בכל רגע, בכל האילוצים המושתים עליה, גם אלה שלא היו קיימים בשלב התכנון הראשוני.

סיכון הוא אירוע ספונטני

סיכון הוא אירוע שאין לפרויקט שליטה ישירה עליו. אם יקרה או לא יקרה לא ייקבע ע"י פעולה כלשהי של הפרויקט, אלא ע"י מציאות חיצונית לפרויקט, דינמית ומשתנה תמידית.
שגיאה נפוצה: התייחסות לאירוע פנימי בפרויקט כאל סיכון, לדוגמא: "קבוצה ‏בפרויקט חוששת שקבוצה ‏ בפרויקט לא תספק לה את התוצר P‏ בזמן".
לצורך ניהול אפקטיבי של הפרויקט, על מנהל הפרויקט לעקוב ולנהל את המחויבויות ההדדיות בין קבוצות העבודה בתוך הפרויקט. זהו ניהול יעיל בהרבה מאשר ניסיון לעקוב אחר כל המטלות ברמה פרטנית. פערים המתגלים ומתוקנים במהלך ניהול המחויבויות ההדדיות בפרויקט אינם סיכונים.

סיכון הוא אירוע ספציפי

על מנת שיתאפשר טיפול יעיל בסיכון, צריך אירוע הסיכון להיות מוגדר באופן ספציפי וקונקרטי, לא בכותרות או בסיסמאות. הגדרת האירוע צריכה לענות על שאלות כגון: מה בדיוק עלול לקרות? על כמה מדובר? למי זה יקרה? מתי? פרויקט שהיה רגיל בעבר לתאר סיכון בצורה כוללנית, ימצא את עצמו, אם יקפיד על הספציפיות, עם רשימה ארוכה של סיכונים. זה לא בהכרח דבר רע, אלא מצביע על כך שיש מכשלות להצלחת הפרויקט אשר איתן יש להתמודד.
שגיאה נפוצה: הגדרת הסיכון בצורה כוללנית ולא מדויקת, לדוגמא: "יתכן מחסור בכ"א לפרויקט"
זה לא מספיק ספציפי כדי להתייחס. יש לברר איזה כוח אדם בדיוק עלול להיות חסר לנו? כמה אנשים? מאילו התמחויות? כל תשובה כאן היא סיכון נפרד, למשל: "יש חשש שמומחה התקשורת יוסי יתעכב בפרויקט הקודם שלו, ולא יהיה זמין לתחילת העבודה על משימותיו בתאריךdd/mm/yyyy".

סיכון הוא אירוע מזיק

סיכון הוא אירוע אשר אם יקרה – ישבש את עמידת הפרויקט ביעדיו המוגדרים. יעדי פרויקט פיתוח כוללים יעדי תכולה של המוצר (כולל איכות), יעדי תקציב ויעדי לו"ז.
שגיאה נפוצה: התייחסות לאירוע המשפיע על היעדים של מישהו אחר ולא הפרויקט, לדוגמא: "אם נספק את המוצר המבוקש –יתכן שהלקוח לא יוכל להרוויח ממנו מספיק כסף".
יעדי הרווח של הלקוח אינם יעדים של הפרויקט. הפרויקט יכול להסב את תשומת לבו של הלקוח להשלכות שונות שתהיינה למוצר על יכולותיו, אך אילו אינם סיכונים לפרויקט. הפרויקט צריך לספק את מה שהוזמן, בתקציב הנתון, בזמן הנדרש.

סיכון הוא אירוע סיבתי

פגיעה ביעדי הפרויקט היא תוצאה. הסיכון הוא אותו אירוע שעלול לגרום לפגיעה הזאת.
שגיאה נפוצה: התייחסות לתוצאת הסיכון כסיכון עצמו, לדוגמא: "אנו חוששים מעיכוב של חודש בסיום פיתוח הרכיב".
עיכוב, או איחור, מתארים את הנזק שבחריגה מלו"ז הפרויקט, את התוצאה של הסיכון. אבל מהי הסיבה לנזק זה ? מהו הגורם ? מהו אותו אירוע שעלול לקרות ואשר בגללו יתעכב הפיתוח? במקרים רבים יסתבר שיש יותר מאירוע אחד שתוצאתו "עיכוב של חודש". כל אירוע כזה הוא סיכון נפרד שיש לטפל בו.

איך מזהים סיכונים ?

את הסיכון יש לזהות מראש, ולטפל בו באחת או יותר מהדרכים המוצעות בשיטות ניהול הסיכונים השונות.
זיהוי הסיכונים מתבצע בשיטת "סיעור מוחות", שעיקרה: המשתתפים מציעים "מועמדים" לסיכונים, כאשר איש לא מבקר, פוסל או שופט את המועמדים של משתתף אחר. רק בתום שלב הרעיונות – בוחנים כל מועמד אל מול קריטריוני הסיכון לעיל. התוצאה תהיה: רשימת סיכונים ורשימת בעיות. הבעיות עוברות לטיפול במסלול פתרון הבעיות של הפרויקט, לא במסלול ניהול הסיכונים.
מועיל מאד לבסס את זיהוי הסיכונים על רשימת מקורות הסיכון של הפרויקט. מקורות הסיכון הן משפחות ונושאים שעלולים "לייצר" סיכונים לפרויקט, לדוגמא: איחור באספקת תוצר מגורם חיצוני, טכנולוגיות חדשניות, אי זמינות של תשתיות ומשאבי אנוש, ועוד. כל אחד מאלה איננו סיכון, אלא מקור שבו יש לחפש את הסיכונים. מומלץ לבצע "סיעור מוחות" עבור כל מקור סיכון בנפרד.

הנחיות להגדרת סיכון

להלן מספר הנחיות והמלצות ששמירה עליהן תעזור להגדיר סיכונים בצורה שתועיל לטיפול בהם:

קשוֹר כל חשש לאירוע

חששות ואי ודאויות צריכות להיות קשורות לאירוע קונקרטי בחיי הפרויקט כדי שאפשר יהיה לנהל אותם כסיכונים. לעיתים לא קושרים את החשש לאירוע ואז נתלים בכל מיני פעולות כאילו שהן פעולות למניעת סיכון, גם כשאינן כאלה. לדוגמא: "לא בטוח שהטכנולוגיה המוצעת תעמוד בביצועים הנדרשים". במצב כזה בדרך כלל יתכנן הפרויקט בדיקה או ניסוי מוקדם, שנועד לאושש או להפריך את הטענה שהטכנולוגיה המדוברת עומדת בביצועים. ניסוי כזה אין לו שום השפעה על הסיכון, והוא למעשה פעולת לימוד. כדי שנוכל לדבר במונחי אירוע, נגדיר את הסיכון כך: "קיים חשש שניסוי הטכנולוגיה יראה שהטכנולוגיה שבחרנו לא תעמוד בביצועים". זהו אירוע הסיכון ואותו צריך לנהל ע"י פעולות מניעה או הפחתה.

אל תלך רחוק מדי

בניתוח הסיכון יש לזהות את האירוע הגורם, ולהעריך את מידת הנזק שייגרם לפרויקט (קרי: מידת הפגיעה ביעד). לעיתים נוטים להרחיב את הניתוח אל מעבר לגבולות הפרויקט, לדוגמא: "אם נאחר אפילו ביום – המוניטין של החברה ייפגע".
חומרת הנזק צריכה להימדד כלפי הפרויקט, ולא כלפי החברה כולה. איחור בעמידה בהתחייבות ללקוח יכול להיות חמור מאד לפרויקט וליעדיו גם אם לא יגרור פגיעה משמעותית במוניטין החברה.
בנוסף, מוניטין החברה אינו יעד של הפרויקט, ובוודאי שאין ביכולתו של פרויקט לנתח השפעה כמותית על מוניטין החברה ולהשקיע ממשאביו המוגבלים בפעולות שכל תכליתן לשמור על המוניטין. הפרויקט צריך לפעול כדי לעמוד ביעדיו המוגדרים ולהשאיר את הדאגה למוניטין – להנהלת החברה.

הבחן בין חוסר ידיעה לבין חוסר וודאות

לעיתים חסרה פיסת מידע הדרושה לצורך העבודה בפרויקט. חוסר זה נקרא "פער ידע". פער ידע איננו סיכון. מתפקידו של הפרויקט להשיג את כל המידע הדרוש. השגת מידע חסר היא מטלה ככל מטלה אחרת בפרויקט, והיא נקראת "השלמת פערי ידע". לדוגמא: האמירה "אין לנו ניסיון בפיתוח יישומים בטכנולוגיה כזאת" מייצגת פער ידע, לא סיכון. איך מתכוון הפרויקט להתמודד עם פער הידע הזה? לגייס אנשים בעלי הידע הנדרש? להכשיר אנשים? להשתמש בשרותיו של יועץ מומחה? על הפרויקט לבחור את הדרך המתאימה להתמודדות, אך לא דרך הגדרת המטלה כסיכון.

חפש סיכונים על בסיס תוכנית העבודה

מרגע שיש תוכנית עבודה – מחפשים אירועים שיש חשש שישבשו את התוכנית. אלה הם סיכוני הפרויקט. כל עוד לא הוחלט על דרך פעולה – אין משמעות לסיכון, מכיוון שאין דרך פעולה העלולה להשתבש. לדוגמא: "הפתרון על בסיס רכיב XYZ מסוכן. עדיף לבחור ברכיב ABC". אמירה כזאת מצביעה, אמנם, על השלכות שליליות של בחירה בחלופת הפתרון, אבל לא על סיכון. בונים דרך פעולה על בסיס הפתרון שנבחר, למשל: ABC, ורק אז מחפשים סיכונים, היינו, את אותם האירועים שעלולים לשבש את ההגעה ליעדים על בסיס פתרון זה.

היערך גם למשימות גדולות

משימה, גם אם היא ארוכה, יקרה, מצריכה מאמץ גדול ו/או משאבים מרובים – היא עדיין משימה, ולא סיכון. לעיתים טועים ומצביעים על משימה יקרה כעל "סיכון". משנערכים לביצוע המשימה – אזי ניתן לחפש סיכונים בדרך הביצוע המתוכננת.

וודא שתוכנית העבודה ריאליסטית

תוכנית עבודה ברת ביצוע היא תנאי מקדים להגעה ליעדי הפרויקט. לעיתים טועים ומגדירים ליקוי תכנוני כסיכון, לדוגמא: "למשימה נדרשים 3 חודשים, אך ההנהלה הקציבה לנו חודש בלבד". תוכנית עבודה לקויה לא תביא את הפרויקט ליעדיו, וזאת ללא קשר לסיכונים. מקרה כנ"ל אינו סיכון אלא סימפטום לאחד או יותר מהבאים:
  • יכולת נמוכה של הגוף המבצע להעריך משך או עלות של עבודה שבאחריותו
  • תרבות עבודה קלוקלת, שבה הגוף המבצע מוסיף להערכות מרווחי ביטחון מוגזמים, וההנהלה, בהיותה מודעת לכך, מקצצת בהערכות, והתוצאה – מעגל קסמים הרסני
  • תרבות ניהולית פגומה, בה ההנהלה מתעלמת מצרכי המיישמים ובונה על "ניסים" במקום על יכולת מדודה ומוכחת

סיכום

הבאתי הגדרה לסיכון בפרויקט וכן הצגתי שיטה לזיהוי סיכונים על בסיס ההגדרה. כמו כן הראיתי דוגמאות לשגיאות נפוצות, ונתתי המלצות במה כדאי להתמקד וממה להימנע. גישה כזאת לסיכונים בכוחה לשפר ולשדרג משמעותית את ניהול הסיכונים בפרויקטים, ועל בסיס זה – את הצלחת הפרויקט.

על המחבר, אלון מודעי

מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 28 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 10 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה, כולל נושא ניהול הסיכונים בפרויקטים.

בדרך כלל מבדק צד שלישי (כזה המקוים ע"י הלקוח או גוף הסמכה/התעדה) נתפש כטרחה ואיום על הארגון. האיום, בפניו עומד הארגון, עלול לנבוע מהחשש שבמהלך המבדק יתגלו פערים אשר עלולים לסכן את מעמדו בעיני הסוקר/הלקוח ולהשפיע על יחסי הגומלין ביניכם.

מצד שני, יש מקום שמנהלי האיכות ו/או עורכי המבדקים הפנימיים בארגון ייחלו לו, שכן אירוע זה בחיי הארגון עשוי לשמש כזרז לארגון לבחון את עצמו, להתייחס בקשב רב יותר להתראות המגיעות מצדכם, ובכנות, הזדמנות לשיפור. ההזדמנות נעוצה ביכולתכם לרתום את כלל הארגון (בגבוי ההנהלה) לתקן את העיוותים ולהשלים את הפערים.

אחד המרכיבים העיקריים להפיכת האירוע המאיים לאירוע מהנה ומועיל נעוץ בהכנה.

להלן מספר טיפים מעשיים כיצד להתכונן היטב למבדק הקרוב שלכם.

טיפ # 1: דע מה מטרת המבדק

דאגו להתקשר לסוקר המיועד לערוך את המבדק באתר שלכם זמן מה לפני הגעתו. בררו עם הסוקר את היקף ותכולת המבדק: כמה ואלו תהליכים יבחנו? כמה ואלו דוגמאות עלינו להציג? מהו המידע הייחודי אותו מצפה הסוקר לראות במהלך המבדק (במיוחד כיום כאשר קיימת דרישה לבחון אפקטיביות התהליכים על בסיס נתונים הנאגרים לאורך זמן רב)? מהו הסיוע שיידרש לסוקר לפני או במהלך המבדק (במיוחד אם המבדק נערך ע"י זרים שאינם דוברים את שפת המקום)?

טיפ # 2: בצעו מבדק מקדים

אם יש לכם תכנית לביצוע מבדקים פנימיים (ואם אין – איך זה?!) מקדו את עורכי המבדקים בתחומים אותם עומדים לסקר בארגון, לפחות חודש לפני המבדק החיצוני המתוכנן. דאגו שתהיה התחייבות ברורה של ההנהלה לכך שהפערים אשר ימצאו במהלך המבדקים הפנימיים יתוקנו תוך יישום פעילות מתקנת שתוגדר על בסיס אתור וניתוח סיבות שורש לפערים.

טיפ # 3: היה אסרטיבי ודרוש מעצמך יותר מאשר, להערכתך, ידרוש הסוקר

וודא שהעובדים בארגונך מבינים שעדיף לכם לאתר את הפערים בעצמכם (כחלק מהמבדק המקדים) מאשר לאפשר ללקוחותיך או גורם חיצוני למצוא פערים אלו. הדרך את עורכי המבדקים הפנימיים "לחפור" ולדרוש כדי להבטיח שכל התחומים נסקרו לעומק. זאת הדרך היחידה להבטיח שלא תהיינה הפתעות במהלך המבדק החיצוני.

טיפ # 4: השתמש באותן רשימות התיוג או דרישות בהן ישתמש הסוקר

למבדקים פורמאליים רבים (כגון מבדק לתקן AS9100) רשימות תיוג או דרישות מבדק זמינים לכל (לעתים בתשלום). השתמש בחומר זה, הכר היטב את תהליך הסיקור המוגדר בו וענה על כל שאלה. אם נתגלו פערים, הכן פעולה מתקנת מתאימה ומתועדת לפני המבדק החיצוני.

טיפ # 5: בחן את הממצאים הקודמים

באם אין זאת הפעם הראשונה שאתם עוברים מבדק כזה, בחן היטב את הממצאים מהמבדקים הקודמים, ולא רק של הלקוח המסוים או גוף ההסמכה הנוכחי. וודא שכל ממצא מהמבדקים הקודמים אינו מהווה יותר בעיה עבורכם. חפש את הבעיה באזורים שונים של הארגון, והן באזור שבו אותרה הבעיה בעבר.

טיפ # 6: וודא שאנשיך מכירים את הנהלים

סוקר טוב יבחן את העמידה של הארגון בדרישות מהמערכת והן התוצאות המתועדות של התהליכים, אולם יעריך גם את הכרת הדרישות והעמידה בהן ע"י העובדים. במבדק אפקטיבי תתקיים אינטראקציה בין הסוקר לבין העובדים והעובדים יידרשו להפגין את ידיעתם את הנהלים המתועדים וכיצד הם מבצעים את תפקידיהם בהתאם לנהלים אלו. הגיוני, שתדאג מראש ובהתמדה להעמקת ידע זה, שאם לא כן תצטרך להביא את כולם לכך "ברגע האחרון".

טיפ # 7: וודא שיש בידיך לספק עדות אובייקטיבית לעמידה במדיניות ונהלי ארגונך

סוקר אפקטיבי ידרוש שתראו לו כיצד אתם עומדים בדרישות. יש סיכוי שהסוקר לא יסמוך רק על דברתך. כאשר מתכוננים למבדק – וודא שעורכי המבדקים הפנימיים שואלים: הראה לי מה אתה עושה. כיצד תוכל להראות לי ולהוכיח שאכן עשית זאת? איך תוכיח שעשית זאת נכון?

מבדקים הם עובדת חיים.

זה תלוי בכם עד כמה מאיימים או מועילים הם יהיו

שלמה ליכטנשטיין משמש כיועץ לקידום האיכות והמצוינות בארגונים, ובעיקר לארגונים העוסקים בתחום האירוספייס. פעיל במסגרת הארגון הבינלאומי לאיכות באירוספייס (IAQG) , העוסק בתקינה בינלאומית ושיפור התהליכים בתעשייה זאת. במסגרת פעילותו, סייע בהכנת הנחיות ומדריכים בנושאים שונים במסגרת ה –SCMH.
שימש כמנהל הפרס הלאומי לאיכות ומצוינות ע"ש יצחק רבין ז"ל (במגזר העסקי) מתחילת 2007 ועד סוף שנת 2009.
חבר הנהלת האיגוד הישראלי לאיכות מ – 2004 ועד 2012, יו"ר מגזר תעשיות ביטחוניות, תעופה וחלל, "עמית" האי"א (2009) ויו"ר הכינוס הבינלאומי ה – 16 (2006).
עד 2007 שימש כר' מינהל ניהול האיכות במטה התעשייה האווירית לישראל בע"מ ופעל רבות לקידות האיכות ומצוינות תפעולית בחברה ובין ספקיה.
אחת מהנחות העבודה בתורת האילוצים של ד"ר אלי גולדרט הינה-"אופטימום לוקלי אינו בהכרח אופטימום גלובלי".
הסבר- שיפור ביצועי יחידה בודדת בארגון והבאתה לנקודת האופטימום בביצועיה אינו בהכרח המקום האופטימלי מנקודת המבט הכוללת (הגלובלית) לארגון.
דוגמא אחת מני רבות- אנשי השיווק הנמדדים בהיקפי מכירות מכוונים להגדלת המכירות, אין המשמעות בהכרח שהיקף הרווחיות הכולל לארגון גדל כתוצאה מכך. לעיתים אף נחזה בירידה ברווחיות הכוללת (כתוצאה מגידול בעלות המכר). ומכאן שהחתירה לאופטימום ברמה הלוקלית בד"כ לא תניב שיפור ביצועים כולל לארגון. אחת מן המתודות לתיאור תופעות בלתי רצויות לפי תורת האילוצים הינה ה"ענן". הענן הינו כלי לניתוח תופעות המחדד את הקונפליקט הקיים/או לא קיים במציאות. קונפליקט כפי שתואר לעיל ייראה כך-

מכאן משתמע שאין כל טעם ביוזמות מקומיות לשיפור שאינן עולות בקנה אחד עם המטרה הגלובלית של הארגון (בהנחה שמטרה זו הוגדרה באופן מפורש וברור).

אל מול גישה זו קיימת גישת ה"סטיספייסר"- שבע הרצון. סטיספייסר הינו מונח שטבע הרברט סיימון חתן פרס נובל עוד בשנות ה-50 בתורת ההחלטות. פירושו שבעת עשיית החלטות תמיד נחליט על סמך מינימום ראיות ולא נגיע לאופטימום של מידע כיון שאין ברשותנו זמן ומשאבים אינסופיים, אנו עוצרים תמיד בנקודה מסוימת שבהכרח אינה האופטימום. בחיים איננו עוסקים כל הזמן באיסוף מידע מקסימלי לפני שנחליט החלטה, אלא תמיד נסתפק בגודל מסוים של מידע, ומימד מסוים של אי וודאות יש בכל החלטה שלנו. בעולם העסקים הסטיספייסר (שבע הרצון) לא יוותר על הרצון לשפר את ביצועיו אך ביודעו שהאופטימום אינו בהישג יד יסתפק בשיפור ביצועיו (בין אם שיפור לוקלי ובין אם גלובלי). הסטיספייסר מציב לעצמו רף ציפיות – רף מטרה אותו הוא שואף לעבור. השאיפה אינה להגיע למדד ביצוע מקסימלי או מינימלי  כלשהו (לדוגמא אפס נפגעי תאונות עבודה) אלא שיפור יחסי ביחס לרף ציפיות מצופה.הסטיספייסר אינו עוסק בבחינת כל מכלול החלופות אלא בוחן סט קטן ומספק של חלופות עד אשר יזהה חלופה המביאה אותו מעבר לרף הציפיות. ברגע שעבר נקודה זו יציב לעצמו רף ציפיות חדש וכך נחזה בתהליך של שיפור מתמיד.

הגישה גם חוסכת בזמן ארגוני (שהוא כמובן יקר ערך) בחיפוש אחר האופטימום (הקיים אך היקר בזמן וכסף להשגה).

2 עקרונות מנחים נדרש שיובילו את הסטיספייסר:
1.      הצבת רף ציפיות גבוה דיו בהתאם לתנאי הסביבה (תחרות, שוק, משקיעים, לקוחות וכדו')
2.       אימוץ הגישה של שיפור מתמיד
עקרון השיפור המתמיד חשוב מאין כמוהו הואיל וקו מנחה בגישה הזו הוא היחסיות- לעת עתה, אנו שואפים לנקודת עבודה טובה יותר אך במשך הזמן המתחרים  ישפרו גם הם ביצועיהם וידביקו את הארגון.
כדוגמא למסגרת המאפשרת שיפורים "משביעי רצון" יושמה בארגון בו אני עובד מסגרת (מועדון) להגשת הצעות לשיפור. היחידה הינו גוף הייצור והרכש המונה כ500 עובדים מתוך ארגון כולל של 1500 עובדים.
המועדון מאפשר הגשת הצעות לשיפור(לא בהכרח הצעות ייעול- הדורשות מדידה כמותית). במשך 4 שנות פעילותו הוגשו למעלה מ3500 הצעות לשיפור. אחת לכמה מן ההצעות הינן פורצות דרך ומביאות לשיפור כולל בכל הארגון ולא רק בגוף הייצור והרכש. אם מנתחים את המועדון בעיניו של הסטיספייסר ברורה לנו התועלת משיפור הביצועים הלוקלי הגם שאינו עולה בהכרח עם זה הגלובלי. שבע הרצון יידע תמיד שאינו בנקודת האופטימום ולא יוותר על השאיפה לשיפור מתמיד (שהוא עיקרון מוביל נוסף בתורת האילוצים). כלומר יש מקום  וטעם להגעה לנקודה משביעת רצון בתפוקות הארגון ללא ויתור על הרצון המתמיד בשיפור הביצועים.
לתגובות/הערות:   boaz.goren10@gmail.com

הקדמה

מאמר זה עוסק באחד מכלי החשיבה של תורת האילוצים לפתרון קונפליקטים בחיי היום יום, הנקרא "ענן". הענן מאפשר התמודדות שיטתית במציאת פתרון לבעיה, מבוסס Win-Win, לעומת הפתרונות המקובלים של וויתור או פשרה.

במהלך היום, צצות כל הזמן בעיות בלתי צפויות שמסיחות את דעתנו מהמטלות העיקריות. במקרים רבים, ההסחה היא כה גדולה, שאנו חייבים לטפל בה כדי שנוכל להתקדם. אחד הכלים של תורת האילוצים, הענן, מניח שלבעיה או לקונפליקט מבנה קבוע. הגדרת הבעיה בצורה מובנית, תוך כדי איסוף המידע הרלוונטי בלבד, ללא רעשים ותוספות שאינן תורמות להבנה, עוזרת לטפל בקונפליקט ביעילות.

בעיה, על פי תורת האילוצים, היא כל דבר שמפריע לנו להשיג את אחד היעדים שלנו. מכאן, שעל מנת לפתור את הקונפליקט, נדרשים שני הצדדים בהגינות להבין ולשתף את הצרכים שלהם (לא תמיד זה קל, במיוחד בסביבה עסקית). כאשר אנו מתמודדים עם בעיה שאנו חושבים שאין לה פיתרון, יש מתחת לפני השטח קונפליקט שמונע את השגת היעד המשותף. הדבר דומה לחוק השלישי של ניוטון – מצד אחד, אנו מפעילים כוח על מנת לפתור את הבעיה, אך בו זמנית הקונפליקט מתחת לפני השטח מפעיל כוח נגדי, כך שסכום הכוחות שווה אפס. אנו מאד מותשים מהמאמץ, אך לא מתקדמים להשגת היעד הרצוי. מטרת כלי החשיבה הקרוי ענן היא לגלות את אותו קונפליקט שמפעיל כוח נגדי לרצון שלנו להשיג את יעדנו.

חקירת בעיה ופיתוח פיתרון באמצעות ה"ענן"   

תרשים קונפליקט באמצעות "ענן":

הענן, מוצג בדיאגראמת חמש התיבות שלהלן:

  • A – המטרה – היעד שאנו רוצים להגיע אליו, אך הקונפליקט מונע מאיתנו להשיג אותו.
  • B,C – שני צרכים שונים שהכרחיים כדי להשיג את המטרה; B ו-C הם למעשה שני צרכים. החיצים מ-B לA- (-B->A), ומC- לA- (-C->A) מציינים שהצרכים B ו-C הם הכרחיים להשגת המטרה A.
  • D, D' – פעולות, רצונות, החלטות שנבחרו כדי להשיג את הצרכים. משמעות החץ מ-D ל-B (D–>B) שיש לעשות את הפעולות D כדי להשיג את הצורך B; באופן דומה, החץ מ- D' ל-C (C<–D'), מציין שיש לעשות את הפעולות D' כדי לממש את הצורך C.

הקונפליקט בא לידי ביטוי, בקו המזוגזג, בכך שהפעולות D ו-D' הן מנוגדות זו לזו. כלומר, הפעולות של D מונעות להשיג את הצורך C, והפעולותD' מונעות להשיג את הצורך B.

מה ראינו עד כה?

,A היא מטרה משותפת ששני הצדדים רוצים להשיג. בגלל זה יש קונפליקט. שני הצדדים מאמינים שהצרכים של כל אחד מהם, B ו-C הם אמיתיים והכרחיים להשגת המטרה. הבעיה היא שכדי להשיג את הצרכים, נדרשות פעולות D ו D', שמפריעות זו לזו, ומכאן נובע המאבק. אם לא היו צרכיםB ו-C לא היה קונפליקט. עצם זה שהקונפליקט לא נפתר – מראה שיש צרכים לא פתורים. כאמור, יש בעיה – אם עושים את D כדי להשיג את B, אנו הורסים את C, ובאופן דומה, אם עושים את D' הורסים את B.

דוגמה:

קונפליקט בין מחלקת הפיתוח או הייצור לבין מחלקת השיווק או המכירות. שיווק/מכירות מעוניינים להכניס שינויים במוצר ברגע האחרון, כדי לענות על צורך חדש בשוק, שבלעדיו המוצר לא יהיה תחרותי. פיתוח/ייצור רוצים לעמוד ביעד שנקבע להם – עמידה בלו"ז. כדי לעמוד בלו"ז, יש להקפיד לא להכניס שינויים במוצר; לעומת זאת – כדי לעמוד בדרישות הלקוחות, יש לענות על הצרכים החדשים שצצו בשוק, ולכן יש להכניס שינויים במוצר.

לאחר שציירנו את הענן – נבדוק את הנחות היסוד. כמו בכל צורך אחר, הקשר בין הפעולות לצורך נקבע באיזו שהיא נקודת זמן בעבר, ומאז לא בדקנו האם הפעולות שיש לנקוט כדי להשיג את הצורך הן אכן הכרחיות, או שיש עוד פעולות נוספות שאפשר לנקוט, או שהצורך לא באמת רלוונטי.

פיתרון הענן – משמאל לימין. דבר ראשון בודקים את הצרכים. האם הם באמת תקפים? בדוגמה שלנו – אפשר לחזור ללקוח ולוודא עימו עד כמה חשוב לו לעמוד בלו"ז. במידה והשינוי מבחינתו הוא הכרחי, ייתכן ויסכים לדחות את הלו"ז. או לחילופין, כשיבין את המשמעות של הכנסת השינוי – יוותר עליו. במקרה כזה, ברגע שצורך אחד נשבר, למעשה אין יותר קונפליקט, ותהליך החיפוש אחר פיתרון Win-Win הגיע לסיומו המוצלח.

במקרה ושני הצרכים עדיין תקפים, נבדוק את דרישות הקדם – האם באמת חייבים אותם? האם אולי אפשר להחליפם במשהו אחר? נבדוק את ההנחות שלנו, ונכתוב אותם: מדוע חייבים את D כדי להשיג את B ? כלומר- מדוע הכנסת שינוי ברגע האחרון גורמת לדחייה בלו"ז? נניח שההנחה היא כי ייכנסו באגים, ולא יהיה זמן לתקנם. האם הנחה זו תקפה? הנחה זו מתבססת על ההנחה שאין מספיק כ"א כדי לבדוק ולתקן. ואולי נגייס את המחלקה המקבילה לעזרה? אולי נפעיל ספק-משנה? כך ממשיכים לבדוק את ההנחות עד שמוצאים הנחה שניתנת לפיתרון בדרך שונה.

באותו אופן בודקים את הצורך של השיווק להכניס שינויים. האם זה באמת נכון שכדי להיות רלוונטי בשוק, לאורך זמן – באמת נדרש השינוי המבוקש? ואם כן, מה יקרה אם השינוי יוכנס בגרסה הבאה? ואולי אם נבין יותר טוב את הלקוח, נוכל לספק את דרישותיו באופן שונה שאינו מצריך שינויים?  וכך הלאה…

כאשר כל בעלי העניין יושבים ביחד ומתקשרים את ההנחות והצרכים שלהם, כדי להגיע למטרה משותפת, יימצא הפיתרון. מאד חשוב, שאת הדיון יעשו כל בעלי העניין יחדיו. כל אחד ישמע ויבין את הצורך של השני, ואת ההנחות שמניח השני לגבי הפעולות שעליו לעשות כדי לממש את הצורך שלו.

"ענן"- כלי חשיבה לטיפול במצבי קונפליקט

כאשר יש אילוץ, המפריע לזרימה חלקה של התהליך וגורם לבעיה, עלינו לשאול שלוש שאלות:

  1. מה לשנות? מהי הבעיה שמפריעה? מה הקונפליקט בין שני אנשים או מצבים?
  2. אל מה לשנות? מה המצב הרצוי? מהי האסטרטגיה להגעה למצב הרצוי?
  3. איך לשנות? מהי הטקטיקה, או הטקטיקות שיש לנקוט כדי להגיע למצב הרצוי.

ה"ענן" מאפשר להציג את המידע לגבי הקונפליקט בצורה ברורה וקצרה, לבחון את הצרכים המתנגדים שיוצרים את הקונפליקט, לבחון את ההנחות שיצרו את הקונפליקט, ובעקבות כל זאת, להגיע לפיתרון מוסכם, המקדם מטרה משותפת של שני הצדדים. הפיתרון מושג תודות לחקירה לעומק של הנחות היסוד שנמצאות בבסיס של שני הצדדים בנמצאים בקונפליקט. חקירה כזו תגלה שלפחות אחד משני הצדדים מניח הנחה מוטעית. הנחה מוטעית היא כזו שבבסיסה יש רק דרך אחת להשיג את המטרה הרצויה. הפרחת ההנחה נגרמת כתוצאה מכך שנמצאות דרכים נוספות להשיג את הצורך של אחד או יותר מהצדדים.

כלומר, אחרי שחשפנו את כל ההנחות ה"מחזיקות" את הקונפליקט (ע"י מענה על השאלה למה בכדי להשיג את הצורך (B) אני חייבת לנקוט בפעולה הזו (D), או למה נקיטת הפעולה (D) תסכן את הצורך (C)?), אנו צריכים או לזהות הנחה שגויה או לנקוט בפעולה אשר תהפוך את אחת ההנחות ללא רלוונטית.

דוגמה לפיתרון קונפליקטים באמצעות ענן מתחום אישי:

נניח שאם לא רוצה שהבת שלה תחזור מאוחר מהחברה שלה. הצורך שעומד מאחורי הרצון של האם הוא לשמור על ביטחונה. כאשר חושפים  ההנחות, ייתכן שאחת מהן תהיה ש"ללכת לבד בחושך זה מסוכן". ההנחה הזאת איננה בהכרח שגויה, אם זאת אפשר לנקוט בפעולה שתהפוך אותה ללא תקפה כמו למשל שאימא של החברה תקפיץ אותה הביתה ברכב.

סיכום: יתרונות ה"ענן" לפיתרון קונפליקטים

יש הטוענים שהפתרונות הנמצאים תודות לשיטה הם פורצי דרך, כיוון שהם כוללים אפשרויות שלפני הניתוח השיטתי לא היו קיימות.
כיצד אתם נוהגים לפתור קונפליקטים בארגון שלכם? האם השיטה נראית לכם ישימה? אשמח אם תשתפו באחת הרשתות החברתיות שקישורן להלן.

ביבליוגרפיה

Theory of Constraints handbook, Edited by James F. Cox III and John G. Schleier, Jr, Teta McGraw Hill Education Private Limited

תחילה, עלינו להבין את ההבדל בין ניהול פרויקטים "מסורתי" לבין ניהול פרויקטים ע"פ תורת האילוצים ("שרשרת קריטית"). יחד עם זאת, אין מטרת המאמר לסקור באופן מלא מהו ניהול פרויקטים ע"פ ה"שרשרת הקריטית" ואף לא את כל ההבדלים. אלא רק את המרכזיים שיעזרו להסביר את האתגרים המרכזיים ביישום זה ומה הם התנאים ההכרחיים להצלחתו.

כמנהל פרויקטים מעל ל 15 שנה ובחמש שנים האחרונות כמנהל פרויקטים ע"פ שיטת ה"שרשרת הקריטית", אם הייתי צריך לסכם במשפט אחד את ההבדל המרכזי בין שתי השיטות, הייתי אומר שזה אופן ההתייחסות לפרויקט כמכלול. בעוד שבגישה המסורתית, מתייחסים לניהול הפרויקט כסכום הניהול של שלביו השונים בנפרד, בגישת השרשרת הקריטית, מתייחסים לפרויקט כישות שלמה בפני עצמה.

השלם לא שווה לסכום חלקיו!

כיוצא מכך, בגישה המסורתית בשל מורכבות הפרויקט, לרוב ננסה לעשות אופטימיזציה לכל שלב בפרויקט בנפרד. מתוך הנחה שאם נעשה אופטימיזציה לכל השלבים, הרי נביא לאופטימיזציה של כלל הפרויקט. ואילו בתורת האילוצים, הגישה הינה לא לעשות אופטימיזציה לוקלית (כל שלב בנפרד). מכיוון שזה לא רק חסר טעם, אלא לפעמים אף מביא לתוצאות הפוכות מהרצויות. אלא נעשה אופטימיזציה גלובאלית, על כל הפרויקט כישות אחת.

הדוגמה הבולטת ביותר לכך בשלב תכנון הפרויקט הינה נושא הבאפרים (הגנות) – בעוד שבגישה המסורתית נהוג לקחת באפר ברמת המשימה (בצורת הגדלת משך המשימה בהתאם לסיכון הגלום בה), בניהול ע"פ "שרשרת קריטית" נהוג לתמחר את משך המשימות ללא באפרים ואת הבאפר לקבוע ברמת כלל הפרויקט. מתוך ידיעה ברורה שיהיו משימות ש"יאחרו" ויצרכו מהבאפר הפרויקטאלי.

"קשב ניהולי" למי שצריך ולא למי ש"צועק"

דוגמה נוספת לכך בשלב הביצוע של הפרויקט הינה אופן ההתייחסות ל"משברים" (משימות שחורגות מהמשך שהוקצה להן בשלב התכנון) –  בגישה המסורתית, מכיוון שההנחה הינה שהפרויקט שווה לסכום השלבים המרכיבים אותו, כל משימה שמתעכבת למעשה גורמת לעיכוב כלל הפרויקט, ולכן מנוהלת כ"אירוע שבר". לעומת זאת בניהול ע"פ "שרשרת קריטית", לא כל עיכוב בכל משימה מנוהל כ"אירוע שבר", אלא רק עיכובים על "השרשרת הקריטית" של הפרויקט (שרשרת המשימות הכי ארוכה בפרויקט של משימות בעלות קשר לוגי או של החלקת משאבים).

אל תדחה למחר מה שאתה יכול לדחות למחרתיים

בארגון שהוא מולטי-פרויקטאלי (מנהל מספר פרויקטים ברגע נתון שלא בהכרח תלויים אחד בשני). בעוד שבגישה ה"מסורתית" יסתכלו על כל פרויקט כעל ישות נפרדת בפני עצמה. ולכן, כדי להתמודד עם אי-הודאות ולמנוע/למזער איחורים תהיה שאיפה להתחיל כל פרויקט כמה שיותר מוקדם (ASAP). בגישת ה TOC (תורת האילוצים) יסתכלו על כל פורטפוליו הפרויקטים כעל ישות וישאפו לא להתחיל את כל הפרויקטים כמה שיותר מוקדם אלא למדרג את השחרור לביצוע.

טיפים ליישום מוצלח של תורת האילוצים בניהול פרויקטים

1.      "Buy-In" בכל רמות הניהול

מניסיוננו שמנו לב שהדבר החשוב ביותר כבר בשלב הראשון ליישום הוא לייצר "אמונה מלאה" בשיטה בקרב הגורמים הרלוונטיים. היישום מחייב "שבירת פרדיגמות ניהול" מסורתיות. וללא אמונה שאכן השיטה החדשה "עובדת" ו"מביאה תוצאות" המנהלים הבכירים לא ישקיעו את האנרגיות הנדרשות מהם כדי לתמוך במהלך החינוך מחדש של הארגון ואילו המנהלים הזוטרים לא "יסתכנו" במהלכים שנראים להם "לא הגיוניים" לעומת הדרך שבה ניהלו פרויקטים עד כה. חשוב להדגיש שטעות רווחת הינה שאפשר להסתפק בהשגת Buy-In בחלק מהרמות הניהוליות. לדוגמה, רק אצל ההנהלה הבכירה תוך הסתמכות על כך שהיא תאכוף את הביצוע על ההנהלה הזוטרה. או להיפך, מתוך ההנחה כי היא (ההנהלה הזוטרה) זו שלמעשה עוסקת בניהול הפרויקט בפועל. גישה זו הינה מוטעית ומסכנת את היישום כולו שכן במקרה כזה חלק משדרת הניהול בארגון מיישמת את השגרות הניהוליות החדשות וחלק לא. לעומת זאת, שמנו לב כי בארגון בו היה Buy-In מלא של כל שרשרת הניהול, גם כאשר התחלף ה"מוביל הניהולי" תקופה מסוימת לאחר תום היישום, עדיין נשמרה מתודת העבודה החדשה ולא דעכה.

2.      "מוביל ניהולי" בכיר

מניסיוננו שמנו לב שלא מספיק שיש Buy-In בקרב כל שדרת הניהול, אלא חייב להיות גם "מוביל ניהולי" בכיר שיוביל את המהלך בתוך הארגון וישמש כ"סוכן שינוי" פנימי בארגון. חשוב לזכור שניהול הפרויקטים בארגון, לרוב איננה המטרה הראשית, אלא אמצעי להגשמת מטרותיו העסקיות של הארגון. לכן חשוב שיהיה מנהל בכיר שימשיך לשמור על הקשב הניהולי שנדרש מההנהלה הבכירה ליישום המהלך. תפקיד נוסף שיש ל"מוביל" הינו לסייע בפתרון מחלוקות על אופן היישום, ולשמש כמוביל צוות היישום הפנים ארגוני (צוות שמורכב מחתך מייצג של אנשי הארגון מכל הרמות הניהוליות, שתפקידו המרכזי להתאים את המתודה הבסיסית לארגון ולשמש כסוכני שינוי בארגון). שמנו לב שבמקרים ובהם לא מונה כבר בתחילהChampion ניהולי (או במידה ונעדר לתקופה ממושכת), היישום אומנם התקדם, אבל בצורה מאוד איטית דבר שסיכן את השגת "חווית הצלחה מהירה" (ראו סעיף בהמשך), ובכך את היישום כולו.

3.      שגרות ניהוליות תומכות

לא אחת הגענו לארגונים שכבר היו בשלבי יישום מתקדמים של CCPM (ניהול פרויקטים ע"פ ה"שרשרת הקריטית"), אך לא הצליחו להשיג את תוצאות השיפור הצפויות מיישום כזה. לרוב, הבעיה בארגונים אלו הייתה שהם אומנם ביצעו את ה"אקטים הטכניים" המתבקשים בניהול פרויקטים ע"פ ה CCPM (כמו "קיצוץ" משכי המשימות והעברת הבאפר מרמת המשימה לרמת הפרויקט) ואף השתמשו בכלי EPM תואמים. אך מה שהיה חסר אלו הן שגרות ניהוליות שתומכות בשינוי התרבות הניהולית המתבקשת. לדוגמה, במידה ועוברים לניהול פרויקט באמצעות באפר פרויקטאלי, יש לוודא קיום שגרות ניהוליות תומכות אשר יוודאו ניצול מושכל של הבאפר ו RECOVERY שלו במידת הצורך. במידה ולא קיימות שגרות כאלו, הבאפר יצרך עד תום עוד לפני סיום הפרויקט, דבר שיצריך לתת  באפר חדש לפרויקט שזה למעשה דחיית סיום הפרויקט.

4.      "מדדים מעצבים"

בכל ארגון קיימת צורת מדידה של הביצוע השוטף לצורכי בקרה והתייעלות. עם היישום של CCPM חשוב לבחון את המדדים הקיימים ולוודא שהם אינם פועלים כנגד היישום. לדוגמה, במידה וקיימת מדידה אחר עמידה ביעד המשימה לעומת התכנון הרי שמדד זה פוגע ביישום CCPM (כפי שציינו בפתח הדברים, המטרה בניהול פרויקט ע"פ CCPM הינה עמידת הפרויקט בזמן ולא עמידת כל משימה בזמן שהוקצה לה). ישנה אמרה נפוצה שאומרת: "אמור לי כיצד אתה מודד אותי, ובהתאם לכך אתנהג". ולכן לעיתים אף נדרש להגדיר מדדים חדשים שיתמכו בתרבות הניהולית החדשה הנדרשת בניהול ע"פ CCPM. לדוגמה מדד הבודק את קצב צריכת הבאפר הפרויקטאלי לעומת קצב התקדמות העבודה על השרשרת הקריטית בפרויקט. לרוב מוצג בצורת גרף המכונה Fever Chart או Trend Chart ומשמש לקבלת החלטות האם נדרשת אסקלציה או לא. ובנוסף משמש ככלי בקבלת החלטה על תעדוף משאבים בין הפרויקטים השונים בארגון מולטי-פרויקטאלי.

מניסיוננו, ארבעת התנאים המוקדמים שתוארו לעיל הינם בגדר תנאי סף ביישום CCPM בארגון. ללא קיום דרישות אלו, הצלחת יישום CCPMמוטלת בספק. בנוסף מניסיוננו, קיימים מספר תנאים נוספים שאומנם אינם מהווים תנאי סף, אך יכולים לשפר בצורה ניכרת את איכות התוצאות המושגות:

1.      חווית הצלחה מהירה

יישום CCPM בארגון גם אם אינו חייב להיות מסובך, אין הוא טריוויאלי. זאת בשל פרדיגמות הניהול שהורגלנו אליהם כל חיינו שחלקן סותרות את המתודה ע"פ ה CCPM. לכן, גם כשיש Buy-In מלא בכל הארגון, קיים קושי לשמר (ואף ליישם במלואם) את השגרות הניהוליות הנדרשות לאורך זמן ללא "חווית הצלחה מהירה". לעומת זאת, חווית הצלחה מהירה, תעזור להאיץ את היישום בארגון. לדוגמה, באחד המקרים מנהל פרויקטים שנרתע מיישום המתודה על כלל הפרויקטים שלו, ביקש מיוזמתו להרחיב היישום, לאחר הצלחת היישום בפרויקט הפיילוט. חשוב להדגיש כי בחירת פרויקט הפיילוט איננה אקראית ומחייבת התחשבות במספר פרמטרים, כדי שהצלחת פרויקט זו אכן תהוו מנוף להכלת היישום על כלל הפרויקטים בארגון. פרמטרים כגון רמת מורכבות הפרויקט, עד כמה משקף את העשייה הארגונית, מי הם בעלי העניין (החל מהמבצעים ועד ללקוחות), מה רמת הקשב הניהולי לה זוכה הפרויקט בארגון ועוד.
דוגמה נוספת הינה יישום מוצלח של single project solution שסלל את הדרך ליישום multi project solution. למרות שלדעת רוב, היישום האחרון הינו היישום שמביא את מירב השיפור ברמת כלל הארגון, ולמרות שהוא פשוט ליישום ואינו מצריך הכנות מרובות או השקעה מרובה מצד צוותי חשיבה. יישום multi project solution הינו הרבה יותר קשה להטמעה בשל שבירת פרדיגמות ניהול מסורתיות "קשות" (ראה בהמשך סעיף "איכות ההקפאה").

2.רמת ההקפדה על כללי ה CCPM בשלבי הפרויקט השונים (שלב התכנון ושלב הביצוע)

ביישום single project solution – אתייחס ספציפית לכלל של קיצוץ משך המשימה ב- 50% מהתמחור ה"רגיל" שלה והוספת באפר פרויקטאלי. במקרה זה, אי הקפדה על קיצוץ משך המשימה לא יביא לכך שהפרויקט יכשל (יחרוג מהזמן). אבל אז, נשאלת השאלה האם עמידה במועד נחשבת הצלחה של CCPM או לא? מנקודת הראות של ארגון שבו רוב הפרויקטים מאחרים, ועכשיו בשל יישום CCPM הם מצליחים לעמוד בזמנים עליהם התחייבו, הרי זו הצלחה. יחד עם זאת לרוב, מיישמי CCPM לא יראו זאת כהצלחה מלאה אלא אם הצלחנו לקצר את משך הפרויקט בכ- 25% בממוצע.
ביישום multi project solution – אתייחס ל"איכות ההקפאה" שמבצע הארגון. אחד מכללי הבסיס ביישום multi הינה להקפיא (לעצור זמנית ואח"כ לשחרר לעבודה בצורה מבוקרת) את העבודה על 25% מהעשייה הפרויקטאלית הארגונית. שימו לב שלא אמרתי 25% מהפרויקטים. יישום חלקי של כלל זה יביא בדר"כ לתוצאות חלקיות (אם בכלל). דוגמה ליישום חלקי הינה "הקפאה" של פרויקטים שעדיין לא יצאו לדרך, או פרויקטים שיצאו לדרך "על הנייר" אבל טרם קיבלו משאבים ולכן עדיין לא באמת יצאו לדרך. דוגמה נוספת ליישום חלקי הינה הקפאה של 25% מהפרויקטים אבל לא "מהעשייה הפרויקטאלית" או הקפאה שאיננה מורידה עומס מהאילוץ של המערכת.

לסיכום, ביצוע שינוי ארגוני למעבר לניהול פרויקטים ע"פ מתודולוגית ה"שרשרת קריטית" (CCPM) הינו מהלך שאין לבצע בקלות ראש. למרות שקיימות תבניות ליישום הנושא מרמת האסטרטגיה ועד לרמת הטקטיקה (Strategic & Tactics Tree), הנושא עדיין מצריך התאמת האימפלמנטציה לכל ארגון בהתאם לצרכיו. כשלון ברתימת כלל שדרת הניהול יביא במקרה הטוב, לשיפור ביצועים זמני ולוקלי אבל לא לשיפור דרמטי וכלל ארגוני וידעך עם הזמן. חשוב לציין שבמאמר זה לא סקרתי כיצד מנהלים פרויקט ע"פ ה"שרשרת הקריטית" ואף לא את שלבי האימפלמנטציה של מעבר לניהול ע"פ ה"שרשרת הקריטית" בארגון. כן ניסיתי לגעת ולהציף נקודות בודדות רלוונטיות לדיון זה (הגורמים להצלחת יישום כזה בארגון). בנוסף לגורמים שנסקרו במאמר זה, קיימים גורמים נוספים המשפעים על הצלחת יישום "שרשרת קריטית" בארגון. במאמר זה התרכזתי בגורמים העיקריים לדעתנו, בהסתמך על ניסיוננו בחמש שנים האחרונות.

למידע נוסף  על ניהול פרויקטים ע"פ עקרונות ה"שרשרת הקריטית" ולגורמים המשפיעים על הצלחת היישום:

1.       מומלץ להתחיל עם הספר "שרשרת קריטית" של ד"ר אלי גולדרט.

2.      "Critical Chain Implementation Factors survey",  University of Wisconsin-Platteville ,Lisa Repp (סקר במסגרת עבודת תיזה לתואר שני). להלן לינק להשתתפות בסקר במידה ועסקתם או הייתם שותפים ביישום CCPM: http://kwiksurveys.com?s=LOLNMM_f587ef06. לקבלת תוצאות הסקר (כפי שנאספו עד כה) מוזמנים לפנות אלי במייל או בטלפון.

למעט הספר "שרשרת קריטית" שתורגם לעברית, רוב הספרות הינה בלועזית.

להלן המונחים הרלוונטיים כפי שמופיעים בספרות הלועזית:

ניהול ע"פ ה"שרשרת קריטית" – Critical Chain Project Management, CCPM
"תורת האילוצים" – Theory Of Constraints, TOC
על כותב המאמר:
לנחום מעל ל- 15 שנות ניסיון בתחום ניהול הפרויקטים ופיתוח תוכנה במתודולוגיות שונות. נחום הינו יוצא יחידת המחשב של ח"א ושימש בעברו כמנהל קבוצת הפיתוח והיישום בבית תוכנה אשר משרת מגוון רחב של ארגונים מהגדולים בתחומם במשק הישראלי. בשנים האחרונות עוסק נחום בהשבחת הפעילות העסקית והפרויקטאלית בחברות, וזאת באמצעות יישום מתודולוגיות ניהול מתקדמות כגון TOC.
ליצירת קשר ניתן לפנות באימייל ל: nahumbb@RedPill-Strategies.com או בטלפון: 054-4350106
להרשמה השאירו פרטים

    x