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

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

אל מול גישה זו קיימת גישת ה"סטיספייסר"- שבע הרצון. סטיספייסר הינו מונח שטבע הרברט סיימון חתן פרס נובל עוד בשנות ה-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

הקדמה לתורת האילוצים

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

המתודולוגיה פותחה ושוכללה על ידי ד"ר אלי גולדרט ז"ל (31 במרץ 1947- 11 ביוני 2011) , ויושמה עד היום במגוון דיסציפלינות במהלך 30 השנה האחרונות. היישום הראשון שהגיע לעולם היה בסוף שנות ה- 70 ברצפת הייצור, המשיך בשנות ה- 80 בנושאי שיווק ומכירות, בשנות ה- 90 – לוגיסטיקה והפצה, ובנוסף – ניהול פרויקטים; בתחילת שנות ה- 2000 – נושאים של אסטרטגיה ומכירות. בשנים האחרונות עשה ד"ר גולדרט אינטגרציה של כל מה שפיתח כל חייו לראיה הוליסטית כללית המתאימה למעשה לכל ארגון באשר הוא, ואף לפתרונות של אתגרים במישור האישי.

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

ארבעת עמודי התווך של תורת האילוצים

1.      Inherent Simplicity – פשוט, פשוט!

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

עולם הניהול הוא תזזיתי. הרבה נושאים נראים מסובכים; המנהלים רצים מנושא לנושא, ופותרים בעיה אחר בעיה. הבעיה היא ש – Common Sense is not so common; אם המנהל של הארגון לא מצליח להבין מה לא עובד, או לא מצליח לנהל תוכנית שתוציא את הארגון שלו מהבוץ, או לא מצליח להסביר בכמה משפטים מה צריך לעשות – הדבר מעיד שעדיין לא נמצאה בעיית השורש, או בשפת ה-TOC – האילוץ העיקרי שמונע את הזרימה החלקה של התהליכים. כל עוד לא נפתור את קונפליקט השורש, אנו מפספסים את היכולת לפתור את בעיית הארגון.

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

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

2.      Every Conflict can be removed

כל קונפליקט או אילוץ ניתן להסרה

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

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

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

3.      People are Good – Always a Win-Win

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

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

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

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

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

4.      Every Situation can be substantially Improved  – עיקרון השיפור המתמיד

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

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

סיכום

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

מקורות:
1.  הרצאה של ד"ר אלי גולדרט על תורת האילוצים, באוניברסיטת תל-אביב – 14.10.2010
2.  הדרכת TOC for ever flourishing Company על ידי מכון גולדרט
להרשמה השאירו פרטים

    x