מרעננים את הפיתוח: Lean – על מה כל המהומה

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

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

Taiichi-Ohno חבר הנהלה בחברת טויוטה, הוא אחד האנשים המזוהים עם פיתוח שיטה בשם Lean Manufacturing אשר הובילה את חברת טויוטה להיות בראש יצרניות הרכב המייצרות מכוניות איכותיות במחירים נמוכים. בשנות ה 2000 היה ברור כבר שהשיטה אינה מוגבלת רק לתעשיית הייצור, והמילה "manufacturing" הושמטה לשם "Lean" המוכר לנו היום.

אם נרצה להגדיר את מהות המתודולוגיה במשפט אחד, יהיה זה המשפט הבא -

“Our target is maximizing value while minimizing waste”

Taiichi Ohno

אך מהי ההגדרה ל value ? מהם wastes וכיצד נזהה אותם במערכת ? ואילו פעולות יש לנקוט בכדי להטמיע את המתודולוגיה בארגון ?

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

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

1. זיהוי ה value

הגדרת ה value היא השלב הקריטי ביותר בתהליך.

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

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

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

2. זיהוי ה- value stream

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

Taiichi הגדיר במפעלי Toyota שמונה סוגים של בזבוז –

Defects, Overproduction, Waiting, non value added processing, Transportation, inventory, motion, unused employee creativity

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

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

Overproduction, Inventory – ייצור מוגבר ומלאים. לדוגמה בעולם התכנה - אם נמשיך ונייצר features שהפיתוח "משער" שיהיה להם צורך בעתיד, אנחנו מבזבזים את זמן הפיתוח, יכולים לגרום לסיכונים חדשים, וכו' ..

Waiting – דוגמה קלסית היא מחלקה אחת המחכה לתוצר ממחלקה אחרת (כדוגמה בדיקות המחכים לפיתוח)

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

המטרה שלנו לאחר שזיהינו את ה-muda בתוך התהליכים– היא לבחון שוב ושוב כיצד ניתן להמעיט אותם. או במילים אחרות - “to minimize the waste”

3. Make the value flow

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

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

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

III. חשיבה מחדש על נהלי העבודה אשר יאפשרו ליצור את הזרימה הנכונה שהגדרנו ב – II

עבודה ע"פ שלושת שלבים אלו תאפשר לנו לייצר את התהליך היעיל ביותר עבור ה value שהגדרנו.

4. Push vs Pull

תהליך הזרימה שהורגלנו אליו בתעשייה בתרבות המערבית הוא דחיפה (push).

מתודולוגית ה Lean אומרת שכיוון זה אינו יעיל, ועלינו להפוך אותו למשיכה (pull).

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

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

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

התשובה פשוטה – כי בחשיבה המערבית אנחנו מונעים תוכנית (plan driven) ולא ערך (value driven).

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

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

שורת סיכום

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

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

בהצלחה!

יוגב טל, PMP

picture source: http://www.markgraban.com/