(Lean Product Development)
מאת: סא”ל יריב חסר ואיציק בן לוי
בשנים האחרונות חיל האוויר הטמיע את תפיסת ה- “לין” במרבית תהליכי הייצור והאחזקה שלו. הטמעת תפיסה זו, על פי רוב באמצעות שיטת הקייזן, הייתה מוצלחת מאוד והביאה לחסכון משאבים וזמן ניכר כמעט בכל אחד מהתהליכים בהם יושמה. בעקבות הצלחת תהליכים אלו ובמקביל למגמות העולמיות בתחום, נכון לבחון את תפיסת ה- “לין” גם בפיתוח מערכות, אמל”ח ויישומים. מאמר זה נועד להציג בקצרה את עיקרי התפיסה ואת אפשרויות התאמתה למערכת הצבאית.
רקע
תהליכי הפיתוח בעולם הביטחוני ידועים בהיותם מורכבים מאוד בהיבטי האתגר הטכנולוגי, היקף הפיתוח והמערכת, האפיון המבצעי, תפיסת הקישוריות, היבטי הבטיחות ואמינות המוצר. כפועל יוצא, תהליכים אלו ידועים כעתירי משאבים ולו”ז. ניסיון העבר מלמד כי על פי רוב משלב הרעיון ועד לשלב היכולת המבצעית יכולים לעבור בין 13 ל-20 שנה, בהתאם למידת האתגר הטכנולוגי המושג בפרויקט.
למרות המאפיינים הייחודיים של תהליכים אלו, ניתן ואף רצוי ללמוד ולאמץ מתודולוגיות אזרחיות לפיתוח מוצרים ומערכות, והדבר אכן נעשה הן בתוך המערכת הצבאית והן בתעשיות הביטחוניות. מתודות מסוג הTQM- וה-TOC, סטנדרטים דוגמת ה-ISO וה-CMMI, הולכים ומהווים אבני יסוד בכל תהליך ניהול פרויקטים. במקביל, סטנדרטים טכניים אזרחיים וצבאיים ואף קוד חופשי ופתוח מהווים את הבסיס להרבה מהמערכות המפותחות כיום בצה”ל.
עניינו של מאמר זה הינו בשיטת ניהול הפרויקטים הנהוגה ברוב מערכת הביטחון ובחיל האוויר בפרט. שיטות אלו, הגם שמיישמות הרבה מהמתודות הפופולאריות בעולם, אין מצליחות לקצר את היקפי לו”ז הפרויקטים והמשאבים הרבים המושקעים בהם, בעיקר בהיבטי כוח אדם. המעניין הוא כי עיקר יעודן של השיטות הללו הינו להבטיח את העמידה בלוחות הזמנים ובהיקף המשאבים המתוכנן. מכאן, שבעוד שמערכת הביטחון מצליחה להבטיח ברמת סמך גבוהה את לוחות הזמנים, המשאבים ואבני הדרך בפיתוח מערכות, היא מתעלמת לחלוטין מהאתגר האמיתי שבהקטנת היקפי המשכים והמשאבים המושקעים בפיתוח המערכות!
הפרדוקס המדובר נובע דווקא מהשימוש במתודות אזרחיות פופולאריות, כדוגמת ה-TOC, אשר מטרתן העיקרית היא לשפר את יכולת החיזוי של מנהלי הפרויקטים. הדבר נובע מכך שבעולם העסקי אין סימפטיה לחברות אשר אינן מצליחות לחזות את ביצועיהם הרבעונייםquarter., ומכאן את תהליכי הפיתוח שלהם.
בחינה של תעשיה אזרחית מסורתית כדוגמת תעשיית הרכב תוכל להסביר גם את היבטי יכולת החיזוי וגם את המשמעויות של תפיסת פיתוח רזה ביחס לתפיסות הקיימות. לפני כ-30 שנה, תעשיית המכוניות היפנית פיתוח מודל חדש המאפשר ייצור בשליש הזמן, ובמחצית העלות של התעשייה האמריקאית. רק שישית מתוכניות הפיתוח של היפנים מאחרות, לעומת מחצית מהתוכניות של ארה”ב ובנוסף מכוניות שפותחו באמצעות שיטות אלו היו מהירות יותר, זולות יותר ונחשבות מוצלחות.
אם נביט על שיטות הפיתוח המקובלות כיום, בהשוואה לשיטות הפיתוח של מכוניות מאותה התקופה, נמצא כי היפנים השתמשו בהנדסה משולבת לפיתוח מוצר. שיטה זו התמקדה פחות בתהליך עצמו אלא בתקשורת בין האנשים ובהנדסה משולבת, ואומצה ע”י תעשיית הרכב בשנים האחרונות. טויוטה מהווה דוגמא טובה לנושא. היא הגדירה כמה כללי יסוד בהנדסה משולבת, ובפרט שיש להתחיל את הפיתוח מוקדם ככל הניתן עם מרחב גדול של אפשרויות כאשר תהליך הצמצום שלהם נעשה ע”י סדרת אבי טיפוסי שהולכים והופכים מדויקים יותר ויותר.
הייחוד של כלל יסוד זה הוא שהפיתוח מתחיל למעשה מרגע שהקונספט הראשוני של הרכב מאושר. הוא מתקדם בקצב מהיר, למרות בחינה של מספר אפשרויות במקביל. בהתאם, המחויבות לתכן יחיד נדחית כל עוד הדבר אפשרי. לדוגמא, מידות הרכב הראשיות אינן מוגדרות סופית עד שהחלקים הראשונים יוצרו והורכבו. For example, Toyota’s
הפרדוקס בחיזוי לוחות זמנים
הדרך הטובה ביותר להבטיח תוצאות ולוח זמנים בפיתוח מערכות הוא להתחיל מוקדם ככל הניתן, ללמוד ולתכנן כל הזמן, לבצע מאוחר ככל האפשר ולספק את התוצר מהר. למרות שזה נשמע מאוד הגיוני, נראה כי הדבר בניגוד לטבעו של ניהול פרויקט פיתוח, שאמור לשלב ניהול מסודר וסדרתי שמצידו מבטיח לכאורה עמידה טובה יותר בתחזיות. בנוסף, הטכניקה להעריך לוחות זמנים מסתמכת על הנחות עבודה בסיסיות קבועות שלא מאפשרות את הגמישות המתבטאת בעקרונות שלעיל. כפועל יוצא, הגישות המסורתיות לניהול פיתוח מערכות מניחות כי היסוד הוא קבוע, עם אפשרות מעטה מאד לשינויים.
הפרדוקס מתבטא בכך שהמאמץ לשיפור החיזוי של לוחות הזמנים והגדרתם המדויקת יוצרת אפקט הפוך. בפועל הרי מתחוללים כל הזמן שינויים ביחס לתוכנית המקורית. ככלל, השיטות המסורתיות רגישות מאוד ביחס להתמודדות עם שינויים. בכל זאת, ככל שהמערכת מורכבת יותר, כך גדל הצורך ללמידה ותכנון שמהווה את הבסיס לשיטות הניהול המסורתיות. מה שלמעשה נדרש הוא תפיסה המעודדת למידה, ולא מחייבת ביצוע עד שהלמידה הושלמה. זו הסיבה מדוע בטויוטה לדוגמא, כלל לא מנסים לומר בדיוק את מימדי פח הרקיעה עד שהם מייצרים ומרכיבים את כלל החלקים. הם פשוט מעדיפים לשלם יותר עבור שינויים בלתי צפויים מאשר לחיות עם חלקים שלכאורה מתאימים אבל למעשה פועלים בצורה שגויה.
ברור כי הקטנת כמות האפשרויות המעורבות בקבלת החלטה מגדילה את היכולת לחזות את התוצאה. אולם, אם ניתן להגיע להחלטות המבוססות על עובדות ולא תחזיות, מתקבלות תוצאות צפויות יותר. ה- Product Development Lean הינה אומנות ותפיסה המתבססת על עובדות ולא תחזיות. ביסודה, המתודה מפתחת יכולת להגיב לאירועים כפי שהם מתפתחים, במקום להוקיר את היכולת לתזמן ולתכנן את כל האירועים מראש.
עקרונות Lean Product Development (LPD)
בהמשך מאמר זה אנו דנים כיצד ניתן ליישם תפיסת LEAN בפרויקטי פיתוח. העקרונות שיוצגו אינם בהכרח לפעולה מיידית כלשהי. הם בעיקר קווים מנחים לגיבוש תהליכים ונהלים בסביבת העבודה.
התחלה מוקדמת
התחלת כל פעילות פיתוח כאשר קיים מספיק מידע כדי להתחיל, ללא המתנה לפירוט או פרטים. איסוף כלל המעורבים בפרויקט יחד על מנת להתוות את הפרטים ולהתניע הפעילות. תחילת הפיתוח במקביל להעלאת צורך הינה לכאורה בזבזנית בהשקעה ואף עלולה לגרום למחויבות לתכן ולפתרון לא מיטביים. מנגד היא מייצרת תועלות רבות בהבנת הצרכים לעומקם, היכרות עם גבולות הישימות של המערכת וגם רכיבים לשימוש עתידי. כדי להתמודד עם המגרעות של הגישה יש להבטיח פיתוח מודולארי מבוסס אבני בניין כלליות ותקינה אחידה, שתקטין את היקפי ההשקעה ובמקביל תאפשר החלפת רכיבים שגויים או מוטעים בקלות.
דגש מיוחד נכון לתת לתהליך הגדרת הדרישות המבצעיות בפרויקט. איסוף כלל הדרישות בתהליך מקדים לפיתוח נועד לכישלון עקב מורכבות המערכות המפותחות וכתוצאה מיכולות טכנולוגיות רבות שאינן מוכרות כלל לרוב הלקוחות. כפועל יוצא, פיתוח משולב עם הגדרת דרישות בשלב מוקדם מייצר צוות של אנשים טכניים הנחשפים לתהליכי הלקוח ולקוחות הנחשפים ליכולות הטכנולוגיה. בסופו של תהליך שכזה מתקבל אפיון טוב בהרבה מכל אפיון שנעשה כשלב מקדים, ובמקביל מרכיבי מערכת משמעותיים נמצאים בשלבי בשלות מגוונים. תהליך שכזה אורך זמן ועלול שלא להיות יעיל, בעיקר כתלות במחויבות ללוחות הזמנים המקוריים, בגישה של הלקוחות לתהליך ובאיכות המפתחים המובילים אותו. ישנם מספר טכניקות מוכרות ופשוטות יחסית לניהול תהליך זה והתמודדות מוצלחת עם הסיכונים שלעיל, אולם הרחבתן הינה מעבר לתיחום מאמר זה.
ככלל, כאשר מעבירים את המידע כמסמכים מקבוצה אחת לקבוצה אחרת בתהליך, הרבה מהמידע בעל פה והידע האנושי החיוני להצלחת הפרויקט יאבד בדרך, ובנוסף, תהליך המשוב החוזר לא מתקיים. יש להימנע מיצירת חומות בין הקבוצות ולהקפיד על תקשורת דו סטרית בין כל חברי הצוות.
היבט נוסף של תחילת פיתוח מוקדם הינו כאמור ארכיטקטורת ותכן המערכת. לרוב קיימת נטייה לפצל בעיות לבעיות משנה נפרדות. כפועל יוצא, בחינת התכן במרחב הבעיה נעשה בשלב מאוד מאוחר ורק לאחר וידוא פתרון בעיות המשנה. השימוש באבי טיפוס והפיתוח המקדים בכללותו מבטיחים את ההתייחסות התמידית ובחינת הבעיה המרכזית לכל אורך הדרך.
למידה מתמדת
הקפדה על ראייה רחבה, בחינת אפשרויות רבות, כשבמקביל, פיתוח ובדיקת חבילות קטנות המסוגלות לתפקד בצורה עצמאית. חבילות אלו הן לא סופיות וצפויות להשתנות ככל שהמערכת מתעצבת ומתייצבת. לפיכך, על חבילות אלו להיות פשוטות ועמידות כך שיאפשרו להתעדכן ולהתעדן לאורך הדרך. לכאורה, למידה מתמדת נשמעת כמו רעיון טוב ופשוט עד ההבנה וההכרה כי משמעותה הינה מפרטים טכניים ומבצעיים משתנים לכל משך הפיתוח. המשמעות של השיטה המסורתית להגדרת המפרט בתחילת הפרויקט הינה יצירת תוכנית המבוססת על ספקולציה, פרועה מדי או שמרנית מדי כתלות בתנאי ההתחלה ומכאן גם תוצאותיה אינן מובטחות. בנוסף, בעולם הטכנולוגי הנוכחי ובקצב השינויים בעולם גם הצרכים, וגם הפתרונות משתנים, ולהקפאתם בשלב מוקדם מתלווה מחיר. למרות הכתוב לעיל, הכל מסכימים כי תכנון הוא דבר טוב. הבעיה שתוכניות העבודה עצמן הן שבדרך כלל חסרי תועלת, במיוחד בפרויקט פיתוח. חשוב לזכור כי המטרה היא לא להיות מסוגל לחזות את העתיד, אלא להיות מסוגל להגיב בעתיד כפי שהעניינים מתפתחים. יכולת זו להסתגל למציאות היא הנותנת לארגונים את היתרון התחרותי שלהם.
טכניקה בסיסית בלימוד מתמיד הינה פיתוח מחזורי המייצר תוספת ערך קטנה ללקוח ומאפשר את בחינתה ואת כיווני ההתפתחות עבורה. על המחזורים להתרחש במרווחים קצרים ורצוי קבועים. ככל הניתן וכדי להשתלב עם העקרונות הנוספים עלינו לשמר את מירב האפשרויות פתוחות בכל מחזור, במקביל לשימור האפשרות להעביר באופן מיידי לייצור את המערכת או המוצר שהתקבל בסוף המחזור (ומכאן נדרשת בקרת איכות מוצר ותהליך במהלך המחזור עצמו). ככל שהתהליך מתקדם ומשתפר, מחזורים נוספים התורמים ערך מתווספים למוצר, באופן ששומר על פשטות התהליך ומבטל את הצורך בחזרה מלאה על כלל המחזורים.
דחיית מחויבויות
דחיית מחויבות פירושה שמירה על מירב האפשרויות פתוחות כל עוד הדבר אפשרי. זהו מושג יסודי בתפיסת הפיתוח הרזה. שחרור מצימודים הוא המפתח ליצירת המנגנון לדחיית מחויבויות. טכניקות אלה כבר ידועות מזה שנים רבות בפיתוח תוכנה. לזה יש להוסיף פירוק לגורמים יסודיים, כלומר שיפור התכנון במקביל לפיתוח הקוד ובדיקות אוטומטיות, אשר חיוניות לשמירת היכולת לשינוי המערכת לא רק במהלך הפיתוח, אלא לאורך כל החיים של המוצר.
האפשרות לעכב החלטות בלתי הפיכות גורמת להן להיות מבוססות על אירועים ידועים, ולא על תחזיות. גם כאשר החלטות צריכות להיעשות לפני שכל העובדות מצויות, ישנן דרכים רבות לעכב התחייבות. אם רמת הוודאות נמוכה, אזי נכון לנסות לעכב את ההחלטה, ככל האפשר. במידה ולא, יש לנסות ולמצוא דרכים להקטין את התלות של ההחלטה בתחזיות.
ככלל, ההחלטות צריכה להתבצע ברגע האחרון האפשרי, הרגע שבו אי קבלת ההחלטה מבטלת אלטרנטיבה חשובה. קבלת החלטה לפני הרגע האחרון האפשרי, פירושה קבלת החלטה ללא האינפורמציה הטובה ביותר האפשרית. מנגד, עיכוב בקבלת ההחלטה מעבר נקודת זו פירושו לתת להחלטה להתקבל באופן עצמאי.
יש לזכור כי הדבר אינו פוטר מהצורך בתכנון ההחלטות והיערכות אליהם כך שכאשר מגיע הזמן לקבלתן, הבעיות נחקרו וניתן לקבל ולבצע אותן. לכן, המשלים לעקרון זה הינו הצורך ביכולת תגובה מהירה, משום שעל פי רוב נגלה כי יכולת התגובה הארגונית שלנו היא המכתיבה את המועד לקבלת המחויבות. כדי ליצור יכולת שכזו ולשפרה, יש לבחון כיצד לקלוט ולהטמיע שינוי גם טכנולוגי וגם ארגוני. ארכיטקטורה מבוססת הפרדה לשכבות, הימנעות מחזרה על פיתוח רכיבים, שילוב בדיקות האיכות כחלק מהמוצר המפותח, יצירת “אזורי גמישות” מוכוונים, הימנעות מרכיבים שאינם חיוניים, הם בין הטכניקות המומלצות ליישום בהקשרים אלו.
אספקה מהירה
היכולת לספק מהר היא סימן ליכולת תפעול מעולה, הרעיון בדחיית מחויבות הוא לקבל החלטה מאוחר ככל האפשר, וכך ניתן לקבל החלטות המבוססות על הידע העדכני ביותר. למרות זאת, אין הגיון לעכב את המחויבות אם לא ניתן יהיה לספק מהר את המוצר (ובכך להשלים את החסר בלו”ז הפרויקט). המהירות מצמצמת את אורכו של תהליך המשוב ופירושו שאתה מתנהג על פי המידע העדכני ביותר האפשרי.
בפיתוח פרויקטים, אמינות, הדירות, ואספקה מהירה באופן מתמיד מהווים סימן להצטיינות בביצוע. כדי להבטיח את יכולת האספקה יש לנתח את התהליכים בפרויקט, את צווארי הבקבוק והשפעתם על העבודה. גישה זו, מבוססת תורת התורים, נועדה לשתי מטרות:
לשמור על המתנה קצרה ככל האפשר.
להזרים את העבודה מהר ככל האפשר.
אחד מלקחי תורת התורים הוא שלא תמיד מתקבל הטוב ביותר על ידי הפעלת המשאבים ב-100% יכולת. לדוגמא, הפעלת מחשב ושרתים במלוא תפוקתם, תגרום למחשב לעבוד לאט בכל אחת ממשימותיו. תיאורית התורים מוכיחה כי הקטנת גודל הקבוצות מאפשרת אספקת שירות מהיר יותר עם רמות ניצול גבוהות יותר. הרעיון הוא לחלק את הפיתוח לקבוצות קטנות ורבות של חבילות עבודה זורמות, ולא לתכנן משך אחד גדול של עבודה. יישומים נוספים של תורת התורים באים לידי ביטוי גם בתפיסת ה-TOC, המוכרת ונפוצה.
האתגר הוא בהקמת יכולת תזמון עצמי למערכת, להכשיר את המעורבים בפרויקט בהתאם וליצור יכולת לאיזון של התהליך. פעמים רבות, לא ניתן יהיה להקים מערכת מרכזית המשמשת לתזמון, עקב מהירות התגובה והיקף המידע הדרוש לכך, ולכן נדרש לסגל את האנשים לחשיבה מערכתית וכוללת שתאפשר לכל אחד מהם להתאים עצמו לצרכי מערך הפיתוח כולו.
דגש מיוחד צריך להינתן לסבב הראשון. סבב זה הינו משמעותי מאוד משום שבו הלקוחות המבצעיים יכולים לקבוע את סדרי העדיפויות, ואילו צוות הפיתוח מעריך את יכולתו לבצע את הסבב הבא.
הקפדה על אופטימיזציה גלובלית
יש לנו נטייה חזקה לפרק מערכות מורכבות לחלקים קטנים כי כך הם קלים יותר לניהול, בנפרד. תופעה זו גורמת להתנהגות של אופטימיזציה מקומית. בשיטות המקובלות בניהול פרויקטים יש לפרק כל פרויקט לחבילות עבודה (WBS), ולנהל את העלות ולוחות הזמנים של חבילות עבודה נפרדות. פרוק לחבילות עבודה הוא אמנם מפתה, אבל לעתים קרובות הוא יוצר אופטימיזציה מקומית ופוגם בתמונה הכוללת. ניהול חבילה מופרדת של משימות מתעלם מזרימת שרשרת הערך. הוא עוסק בעלויות ובזמן הדרושים למשימות, אבל לא לוקח בחשבון את הערך של הדברים שלא נעשים. המדידה המסורתית של עלות הפרויקט, לוח הזמנים, והיקפו הכספי היא אמצעי בלבד ואל לה להפוך למטרה בפני עצמה. נכון לפתח מדדים ייחודיים אשר משקפים את הערך העסקי לפרויקט. ככלל, יעיל יותר למדוד ביצועים של צוות, ולא ביצועים של בודדים, כשיטה המעודדת את שיתוף הפעולה.
בנה יושרה
כאשר הזרימה היא מהירה, אין מקום לעבודה באיכות ירודה. פירוש הדבר כי מסמכי הבדיקות והאינטגרציה לאימות הדרישות המבצעיות של הלקוחות הם חלק מהפיתוח עצמו. אין אירועים המתוכננים לביצוע “לאחר הפיתוח”, הבדיקות משולבות בפיתוח בדיוק כמו רכיבי המערכת עצמם, והבדיקות הינן חלק מאספקת המוצר ללקוח ולמשתמש המבצעי. גישה זו מבטיחה את האחריות והמחויבות האישית של כל אחד מחברי הפרויקט לתוצאה הסופית ולא לאבן דרך פנימית כלשהי.
איסוף הדרישות ומעקב אחר הדרישות מהווים בסיס למוצר איכותי. חשיבה “רזה” מתחילה עם ההנחה כי כל בני האדם, בחלק מן הזמן, יעשו טעויות, ולכן יש צורך בתהליך mistake-proof של כל פעילות האדם. הרעיון הוא להניח כי כל טעות להיעשות תעשה, ולכן יש לשים מנגנוני הגנה כך שטעויות יהיו בלתי אפשריות. כל מערכת עשויה להשתנות בעתיד, לכן היא צריכה לבוא עם מפרט בדיקות, כך שלאחר עריכת שינויים, יהיה בלתי אפשרי לפגוע בשאר המערכת. טכניקות כגון אלו המשלבות בדיקות ואינטגרציה בתוך הפיתוח, נמצאות בבסיס תהליך ייצור המוצר. דווקא בעידן של משאבים מוגבלים, בדיקות אוטומטיות של המוצר תהינה ההשקעה הטובה ביותר ותאפשר תכן מבוסס בדיקה.
הבדיקות הבסיסיות שיש להקפיד עליהן הן אלו שנכתבו ע”י המפתחים ובוצעו על ידם. היושרה המקצועית של המפתחים תבטיח את המוטיבציה לבדיקות, ואילו התהליך התומך יאפשר את הביצוע האיכותי. בנוסף, חייבים לכלול בתהליך גם בדיקות לקוח מבצעי, אשר יביאו לידי ביטוי את ההגינות במתן המענה לצרכי הלקוחות.
העצמת הצוות
כאשר זרימת העבודה מהירה והתגובה מהירה, אין זמן לבקרה מרכזית. סביבת העבודה צריכה להיות בנויה כך שאנשים עובדים עבודה עצמית. אנשים, לא מערכות ונהלים, מפתחים פרויקטים. ארגונים העובדים בשיטת ה-Lean ממוקדים באנשים אשר עושים את העבודה. אלו צריכים לתכנן התהליכים הנדרשים להיות מותאמים לשינויים באופן רציף. בתהליכי פיתוח מסורתיים מדגישים את תהליכי הדוקומנטציה המתאימים יותר לייצור מאשר לפיתוח. לדוגמא, במקום לגייס מהנדסי תעשייה לתכנון תהליכי הייצור, טויוטה לימדו את העובדים כיצד להיות מהנדסי תעשייה אשר יעצבו את שיטות עבודות משלהם באמצעות תוכניות הכשרה אגרסיביות ועידוד עובדים בעלי כישורים לבצע שיפור מתמיד.
עקרונית, יצירת סביבת פיתוח מתאימה כרוכה בשחרור המגבלות מהאנשים העובדים והעברה מעמיקה של מטרת הפעילות, במקום מתן הנחיות ספציפיות. משעה שהצוות מבין מה המטרה, הם יידעו האם התהליכים הקיימים כיום דורשים שיפור. כל פרויקט פיתוח צריך להתחיל בבחירת צוות מתאים להשגת המשימה, וכל סבב פיתוח צריך להתחיל בסיקור התהליכים ועדכונם. חשוב להקצות את הזמן לבניית התהליך הנכון.
מנע בזבוב
הדבר היחיד שיש לעשות הוא לספק ערך ללקוח. כל דבר אחר הוא בזבוז. חיסול הבזבוז הוא שלב חשוב הדרוש כדי להזרים ערך ללקוח. יצירת זרימת ערך במהירות היא אחת מעקרונות היסוד של חשיבת ה- LEAN. למעשה, מומלץ ללכת בעקבות הלקוח מאיתור הצורך, דרך הגדרת סדר העדיפויות, קבלת האישורים, העברה לפיתוח, ביצוע תהליך הפיתוח ועד ההתקנה הסופית. יש לצפות בכל שלב של תהליך זה, ולחשוב איך ניתן לספק ערך רב יותר, אמין יותר, ומהיר יותר.
ניתוח מרכיבי הבזבוז במרבית פרויקטי הפיתוח מעלה את הגורמים הבאים: זמני המתנה, מלאי ועבודה חלקית שאינה מסתיימת, עבודה נוספת ומיותרת, (OVER SPEC), עלויות החלפה בעבודה על כמה פרויקטים במקביל, חוסר בהדרכות והטמעה בשלבי הביניים ועם המסירה הסופית, טיפול בתקלות לאורך הדרך, חוסר אמון בין השותפים לפרויקט. כל אחד מגורמים אלו גורר מגוון רב של פעילויות מניעה והתמודדות. נכון לבחון את העוצמות של כל אחד מהמרכיבים בהקשרי הפרויקט המסוים ובהתאם להחליט על היקף ההתמודדות עם הבזבוז הנוצר בתהליך.
סיכום
בפרויקטי פיתוח, יש לקבל את חוסר הוודאות המובנית שבו ולאמץ אסטרטגיות להתמודדות יעילה עם כך. הדרך הפחות יעילה כדי להתמודד עם אי וודאות היא להעמיד פנים שהיא לא קיימת. לצערנו זו הגישה הרווחת כיום בניהול פרויקטי פיתוח.
אחת האסטרטגיות הבסיסיות להתמודדות עם חוסר וודאות היא גיוון והיא פועלת היטב גם בניהול פרויקטי פיתוח. הימנעות מפיתוח מערכות העשויות כמקשה אחת, לטובת אסטרטגיה של פיתוח ובחינת מרכיבים בתהליך מחזורי. פיתוח מצטבר שכזה, במיוחד כאשר משולב עם שחרור בשלבים, מספק אפשרות לחלק פרויקטים לחבילות קטנות שניתן לנטר בנפרד. דרך נוספת להתמודדות עם אי ודאות הינה שימוש באופציות עתידיות על מגוון תרחישים. תפיסת הפיתוח הרזה מעודדת התחלה מוקדמת עם מערך של אפשרויות, ושמירת אפשרויות אלה פתוחות כל עוד ניתן, כך שההחלטות הסופיות יתבצעו מאוחר ככל האפשר. בנוסף, מתאפשר גילוי אפשרויות חדשות באמצעות סידרה של מחזורי לימוד ובחינה.
תפיסת הפיתוח הרזה שהוצגה במאמר זה מאמצת ומתאימה את העקרונות שהביאו תוצרים משמעותיים בתהליכי ייצור לעולם פרויקטי הפיתוח תוך שימת דגש על ההתמודדות עם חוסר וודאות באמצעות גיוון, פיתוח וקידום אפשרויות חלופיות ובעיקר בניית מערכת ארגונית ואנושית המאפשרת הסתגלות והתאמה מהירה לצרכים המשתנים, תוך אספקה ומענה מהיר ומיידי.
לעניות דעתנו, יש מקום לבצע חשיבה והתאמת תהליכי הפיתוח הצבאיים תוך התבססות על העקרונות שנדונו לעיל. להערכתנו, פוטנציאל התועלת בהיבטי משאבים ולו”ז הינו דומה לכל הפחות להיקפי הצלחה של מתודת הLEAN בתהליכי הייצור. מכיוון שתהליך בניין הכוח ופיתוח הפרויקטים מהווים מרכיב משמעותי בשגרת העיסוק הצבאית, היקפי הצלחה שכאלו מגלמים בתוכם פוטנציאל התייעלות וחסכון עצום.
מקורות
- Optimizing Lean Product Development for Aerospace and Defense Manufacturers, Aberdeen Group, 2009.
- Lean Development & the Predictability Paradox, Mary Poppendieck, 2003.
- עקרונות למחקר ופיתוח בעידן הנוכחי, יריב חסר, מערכות 2007.
