פיתוח LPPD נבדל מתכנון בשיטות הפיתוח המסורתי בעבודה הקבוצתית המתואמת ובהקפדה על תכנון ריאלי ודינמי. מילים יפות? שלמה מגדל, מנחה LPPD במכון ILE, מתאר איך זה נראה בפועל.
בחדר נכחו מספר צוותי פיתוח (מכניקה, תוכנה, אלקטרוניקה, חומרים) שעמלו יחד ולחוד על בניית תוכנית עבודה מפורטת ומתואמת לרבעון הבא. מה שבלט לעין היה הצבעוניות של גיליונות התכנון – עשרות פתקיות בצבעים שכל אחד סימל רכיב (feature) במסגרת תכנית פיתוח טכנולוגי מקיפה ומורכבת. הסנכרון הרוחבי של התוכניות נקבע במקטעי עבודה של שבועיים. הצוותים נדרשו להגדיר מטרה ברורה לכל מקטע, כך שתהליך הפיתוח יחולק למשימות ותוצרי ביניים ברורים שניתן לבדוק את השגתם אחת לשבועיים.
שוחחתי עם אחד ממנהלי הצוותים על ההבדל בין תכנון LPPD לבין תכנון פיתוח מוצר מסורתי:
במה שונה בעיניך תכנון ארגוני LPPD מן התכנון המסורתי בו הורגלת?
"גם בעבר היינו בונים תכנית עבודה, לא הגענו לרמת פירוט כה גבוהה. בנוסף, גם כשהייתה לנו תכנית פרויקט פיתוח ברורה, זמן קצר לאחר הוצאתה לפועל התברר שנדרש עדכון. כל יחידה בנתה את התוכנית בנפרד מבלי לקבל מחויבות של היחידות המקצועיות האחרות. כמעט תמיד נאלצנו לעדכן את התוכנית במהלך השנה. היום אנחנו יושבים עם הצוותים השותפים לפרויקט לבנות יחד את התוכנית לרבעון הקרוב, בעוד התוכנית השנתית משמשת רק מסגרת חשיבה ראשונית. ההעמקה נעשית רק לגבי רבעון אחד על מנת לא לבזבז זמן על תכנון שממילא ישתנה לגבי הרבעונים האחרים."
ובכל זאת מה השתנה ברמת התכנון השנתי?
"אחד העקרונות המרכזיים בגישת LPPD הוא העיקרון של העברת המאמץ לתחילת התהליך (Front Load the Product Development process). הצוות בונה תכנית שנתית המבוססת על חקר טבעה וביצועיה של תת המערכת ודרך השתלבותה בעבודת המערכת כולה. הרעיון הוא שמרגע שבחרת והוכחת אמפירית את הקונספט שלך – לאחר מיון, אלימינציה ובחירה מתוך סט רחב של אפשרויות1. והגדרת התיאום האופטימאלי בין רכיבי המערכת – המרחק לאב-טיפוס מתקצר ובהתאמה מתמעטים מכשולים בלתי צפויים בשלבים מתקדמים של הפיתוח."
מה לגבי עבודת הצוות עצמו?
"כמוביל צוות הייתי נפגש בנפרד עם כל חבר צוות ומתאם עמו את תכנית העבודה האישית שלו, משום שההבנה העמוקה של התוכנית והתמונה הכוללת היו באחריותי הבלעדית. היום אנחנו בונים את תכנית הפיתוח יחד עם כלל המעורבים בפרויקט. כל אחד מהשותפים לצוות מבין לעומק את המכלול ולא רק את חלקו. דפוס פעולה זה מאפשר לכל חבר צוות לדעת למה עבודתו חשובה ואיך היא משולבת בתוכנית הכוללת. אף פעם לא היה לנו זמן לשבת ולתכנן כך את העבודה. הדיון הפורה והשאלות שעולות מראים לי עד כמה הבנה מעמיקה של המערכת ומשימות העבודה כבר בשלב התכנון חיוניים על מנת שהעבודה תזרום."
מה השתנה בגישת ניהול המשאבים?
"עד היום העמסנו על עצמנו 120% מקיבולת היכולות שלנו. רצינו לוודא שכל משאב ינוצל במלואו. עכשיו אנחנו מבינים שצריך להשאיר מקום לבלתי מתוכנן ולא לתכנן ליותר מ-80% מקיבולת העבודה של הצוות. תוכנית כזאת ממוקדת בזרימת העבודה ובאפקטיביות הצוות כולו ולא ביעילות המשאבים."
תמונה 1 – תכנית רבעונית חזותית שיצר הצוות:
הצוות הניהולי הבכיר ליווה מקרוב את התהליך שתיארנו, כך גם מנהלת תכנית הפיתוח2 שנציגיה הצטרפו לצוותים השונים. הצוותים רשמו על הלוח את הפערים שזוהו בעת כתיבת התכניות על מנת לדון בהם יחד עם הצוות הניהולי. חלק מהפערים נגעו למשאבים חסרים, ואחרים להיעדר הסכמה בין צוותי העבודה לצוות מנהלת תכנית הפיתוח לגבי מועדי המסירה של התוצרים. עצם זיהוי והבנת הפערים וחלוקת האחריות הברורה לפתרונם מהווה שינוי מהגישה המסורתית, בה התכנית יושבת על יסודות מעורערים מלכתחילה, ומתגלה במהלך העבודה שאין מספיק משאבי פיתוח, אין מחויבות מספקת של היחידות המקצועיות, אין סנכרון עם צוותים מקבילים ובעיות רבות אלו עוצרות את זרימת העבודה.
המשוב כבסיס חיוני ללמידה
אחד הרעיונות המסדרים של תכנון ארגוני LPPD הוא מעגל התכנון, הכולל מסירה (cascading) של יעדים ברורים מלמעלה (מההנהלה) למטה (לצוותי העבודה) ומשוב חוזר (catch ball) באשר ליכולת ההשגה של אותם יעדים. כאשר הצוותים מעלים את המכשולים העומדים בדרכם להשגת יעדי הפיתוח שהוטלו עליהם חשוב מאד שיהיה מישהו קשוב וזמין "לתפוס את הכדור" ולהחזיר תשובות / הנחיות / שאלות נוספות עד לקבלת החלטות וסיכום ברור. כך נצא לדרך עם תכנית (מתגלגלת) לרבעון הבא המתואמת עם כל הגורמים הקשורים, ברורה למבצעי העבודה, מוסכמת על נציגי הלקוח (מנהלת התוכנית) וללא פערים פתוחים.
המעבר מתוכנית לתכנון
תוכנית סטאטית, טובה כל שתהיה בנקודת זמן נתון, אינה מספיקה על מנת להשיג את היעדים3. יש להמשיך את המאמץ הארגוני המתואם לאורך כל הרבעון כתהליך תכנון דינמי, הכולל משוב מהצוותים הפעילים בשטח. במקצב של שבועיים יפגשו מובילי הצוותים בחדר הניהול של הפרויקט (ביפנית: Obeya) על מנת לטפל במשותף בבעיות שיצוצו במהלך הביצוע. כך מתקיים המשוב החוזר מהמציאות אל תוך התכנית והיא מתעדכנת בהתאמה ובאופן מסונכרן עם כל מרכיביה. המפגש ב-Obeya מתנהל על פי עקרונות של ניהול חזותי4, כאשר הדיון ממוקד רק בסטיות מהתכנית שהצוות לא הצליח להתמודד עמן בעצמו ויש להן השפעה על צוותים אחרים ו/או על עמידה ביעדי הפרוגראמה. תרבות של שקיפות וערבות הדדית מובילה את השיח.
תמונה 2 – דוגמה של חדר ניהול (Obeya) :
לסיכום אני ממליץ לכם לשאול את עצמכם:
- האם יש לנו בארגון מנגנון שמבטיח תיאום וסנכרון רוחבי ומחויבות הדדית להצלחה?
- האם שיטת התכנון שלנו נכונה? כמה זמן אנחנו מבזבזים על בניית תוכניות שנתיות (קפואות) שאינן מתעדכנות כלל בהמשך השנה?
- האם אנחנו מעמיסים על המשאבים שלנו יותר מ-80% מהקיבולת שלהם?
- מהו המקצב של הפרויקט שלנו? האם יש לנו קצב אחיד בארגון?
- איך אנחנו יוצרים ומוודאים העברת משוב בזמן אמת מגורמי הביצוע לגורמי הניהול?
- האם יש לנו מי שיקלוט את המשוב, יתייחס לקולות העולים מהשטח ויגיב להם באופן מיידי?
- כיצד נעצים את האנשים שלנו ונשתף אותם, לכל אורך הפרויקט, לא רק בביצוע העבודה אלא גם בתכנון העבודה?
1 על פי שימוש במתודה Set Base Concurrent Engineering: ראו המאמר Serious Games של חברת ILE סמדר כהן-איסבורנו באתר LEI Lean Post. ראו גם: "ניהול סיכונים בניסוי תחילה", בעז תמיר, 1 למרץ 2016.
2 מנהלת תכנית הפיתוח מהווה שלב-ביניים בבניית תפיסת ה-Chief Engineer, או ה-Entrepreneur System Design (ESD), המהווה יסוד חיוני בתכנית LPPD.
ראו גם: "לפתח מוצר נחשק", בעז תמיר, 27 מרץ 2016.
פורסם גם באתר Planet Lean: Boaz Tamir, “Developing A product Your Customers Covet”, Planet Lean 22 June, 2016.
3 ראו: כשהתוכנית הופכת לבעיה, בעז תמיר, 7 ליוני 2016.
4 "ניהול חזותי שאינו קישוט", ג'ון דרוגוסז, 4 לינואר 2017.
כתיבת תגובה