Kaizen – “שיפור מתמיד”
העקרון לפיו אין לקפוא לרגע השמרים – יש לשפר כל הזמן. מי שמכיר ארגונים יודע שאין סוף לשיפורים האפשריים. אפילו אם הגענו לקצה האופטימיזציה האפשרית, הסביבה העסקית והטכנולוגית משתנה כל הזמן ויוצרת הזדמנויות שיפור נוספות. אנו עושים Retrospective בסיום כל ספרינט ב SCRUM על מנת להמשיך ולהשתפר כל הזמן [1]. השיפור איננו תלוי ביזמה מיוחדת של העובדים – הוא נדרש ומצופה כל הזמן. אנו מקצים זמן מיוחד על מנת לעצור הכל, להתבונן על ביצועינו – ולשפר.

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

הנה דוגמא משירות המילואים בצה”ל: בשירות המילואים אני מפעיל ציוד מסוים. במשך כמה שנים אנו מוזמנים לקורס רענון של הפעלת הציוד: “זכרו – X לא בשימוש, Y עובד לפי הסדר 1…2…3”. מאחר והקורס נמשך בעצלתיים במשך שבוע (וחזר על עצמו שנה אחר שנה) – גברו התלונות מצד אנשי המילואים. תשובת הקצינים של היחידה הייתה (חישבו: חשיבה מערבית – שיפור התהליך הקיים) לקצר את הקורס לשלושה ימים, להפוך את השירות לאינטנסיבי וממושך (כלומר – מ 8 בבוקר עד 7 בערב). רוב אנשי המילואים שבעו נחת, או לפחות הפסיקו להתלונן. לא נראה שניתן היה לשפר את הקורס הרבה מעבר.
אם מומחה TPS היה עושה את אותם המילואים, הוא בוודאי היה שם לב שהמכשירים אותם אנחנו מפעילים אינם נוחים לשימוש. ע”י ביטול (פיסי) של הפקדים של פונקציות שכבר אינן רלוונטיות כיום בצה”ל ושילוט נכון על המכשיר – ייתכן ולא היינו זקוקים לקורס רענון בכלל. במקום לשנן את הכשלים בשימושיות של הציוד – ניתן היה במהלך לא מסובך להפוך את הציוד להיות קל-לשימוש.

5Y, בעצם 5xWhy – “לפתור בעיות מהשורש”
עוד עקרון חשוב הוא תחקור מעמיק על מנת לפתור בעיות מהשורש. ע”פ עיקרון ה 5Y, בכל פעם שנתקלים בבעיה יש לעצור ולשאול את השאלה “למה?” חמש פעמים – ורק אז לגשת לביצוע הפיתרון.

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

למי שעבר אי-פעם בחברת תוכנה ישראלית דיי ברור שאם יציג למנהל ניתוח 5Y, קרוב לוודאי שישמע “טוב, הלכת רחוק. ככה זה אצלנו ואף אחד מאיתנו לא ישנה את זה. חבל על הזמן שבזבזת”.
בכל זאת ניתן להתחיל ב 2Y – ניתוח כזה יתקבל כנראה בברכה ויציג שיפור מורגש על פני המצב הקיים.

Stop the Line” – Jidoka”
עקרון מחמיר זה אומר שברגע שיש תקלה (לדוגמא זיהוי חלק לא תקין בפס הייצור) יש לעצור מיד את הקו, לתחקר במקום את הסיבה (זה יהיה נאמר 2Y, לא 5Y), לתקן ורק אז להמשיך ולהפעיל את פס הייצור. היכולת של תחקור ותיקון מהירים היא קריטית להצלחה – ובאחריותם של העובדים (לא סביר להשבית את הקו עד שהמנהל יהיה זמין).

בהקשר זה אני רוצה להציג עקרון מרכזי נוסף של ה TPS (שקשור גם ל 5Y): תיקון בעיות מהשורש והמנעות מהוספת תלאי / שכבה מרפדת.

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

אם נפעל ע”פ עקרונות ה LEAN נעבור ממצב 1 (השמאלי) למצב 2 (במרכז) – בו יש פחות Waste. אולם במצב זה בעיה שעד עתה הייתה מוסתרת – מוענת מאיתנו להמשיך.

כאן צצה דילמה חשובה: להחזיר את ה Waste שהיה בכדי “להעלים” את הבעיה (לא!) או האם לפתור את הבעיה מהשורש ולשמר מצב עם מעט ה Waste (כן!). לרוב, הוספת Waste חזרה היא הדרך הקלה לפעולה. במשך שנים, פעולה כזו נחשבה ל Best Practice ניהולי.

הנה כמה דוגמאות:

• בעיה: אנו מאחרים ב Deliveries. פתרון Waterfall: להכפיל כל הערכת זמנים פי 2, ראש הקבוצה יכפיל את ההערכות פי 1.5 ומנהל הפיתוח יוסיף עוד שבועיים משלו “בצד”.
  • פתרון אגי’לי: שיפור תהליך הערכה כך שיהיה ניתן להסתמך עליו או יצירת חוזה “גמיש” עם הלקוחות, בו מתחייבים על חלק מהתכולות, וחלק אחר נתון להספק משתנה של גוף הפיתוח.
  • הערה: ע”פ ה LEAN כל Buffer הוא Waste, ויש לצמצם buffers למינימום האפשרי.
• בעיה: אין תקשורת טובה בין קבוצת הפיתוח לקבוצת ה QA. פתרון Waterfall: נוסיף מסמכים שישמשו כתקשורת (!Waste – סביר להניח שרוב העבודה על מסמכים אלו תהיה בזבוז זמן. ייתכן ותעלה הטענה “על שיפור צריך לשלם” – אך זו טעות לוגית, מכיוון שבמקרה זה סביר שנשלם יותר משנדרש).
  • פתרון אג’ילי: למצוא דרכים לשפר את התקשורת בצורה לא בזבזנית: להושיב את הקבוצות קרוב אחת לשנייה, לצרף את ה QA למפגשי סנכרון יעילים עם קבוצת הפיתוח וכו’.
• בעיה: עובד מסוים לא מבצע עבודתו כראוי. פתרון Waterfall: שמישהו אחר יעשה זאת במקומו. או אולי – נוסיף מישהו בכיר שיפקח על כל צעד שלו.
  • פתרון אג’ילי: לחנוך ולסייע לאותו אדם לבצע את העבודה שלו כראוי ולהגיע לעצמאות.
• בעיה: שינוי קוד רוחבי במערכת פספס קומפוננטה מסוימת. פתרון Waterfall: להוסיף לכל מסמך Design פרק עם כל הקומפוננטות או ביצוע ישיבות עדכון בה ישתתף נציג מכל קומפוננטה לכל שינוי במערכת.
  • פתרון אג’ילי: לייצר רישום: מי רלוונטי לאיזו קומפוננטה, ולאמן את כל אנשים בפיתוח להשתמש בה בתבונה. זה יכול להיות תהליך ארוך וקשה יותר ליישום – אך בסיומו יהיה מעט מאוד Waste.

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

Kanban (“ארגזים מסומנים”)
עקרון חשוב נוסף ב TPS הוא החתירה ל “Flow”. מצב בו התהליך מתקתק בצורה טבעית, קלה וכמעט בלתי מורגשת אך בכל זאת – יעילה להפליא. חידוש משמעותי בפילוסופיה האג’ילית הוא שימוש עקרי במשיכה “Pull” כנגד דחיפה [2]”Push” המקובלת בניהול המסורתי.

בתעשייה המסורתית, היו מייצרם בקצב בו המכונות יכולות לעבוד – במקום בקצב בו נדרשת התוצר. בתעשיית התוכנה הקבלה אפשרית היא פיתוח 100 פי’צרים במוצר חדש (כי זה מוצר מבטיח וחשוב להצליח בו) מקום לפתח רק 20 פיצ’רים שידועים שנדרשים. הקצב נקבע ע”פ יכולת הייצור ולא ע”פ הביקוש.

הרעיון של Kanban הוא ליצור רצף (Flow) של משיכות. טויוטה אינה מזמינה כל חודש מהספקים שלה כמות קבועה של חומר גלם וחלקים. היא איננה יודעת כמה מכוניות מדגם זה או אחר הלקוחות באמת יזמינו. במקום זאת, כשיש הזמנה לרכב – רק אז נשלחת בקשה למחלקת ההרכבה (השלב האחרון בשרשרת ייצור הרכב), זו שולחת את הדרישות שלה למחלקות הייצור השונות ואלו מזמינות את החלקים מהספק.
כיצד מזמינים 18 ברגים להרכבת דלת? כמובן שזה יהיה בזבוז. טויוטה מחזיקה מלאי מינימאלי. במחלקת הדלתות יש 10 ארגזים של ברגים. כל פעם שארגז מתרוקן שמים אותו בערמה של ארגזים ריקים. על הארגז רשום בצד אחד “ברגים מסוג 123” ומצד שני “מחלקת דלתות – צוות יושימושי”. הארגז יישלח (ביחד עם ארגזים אחרים ריקים) לספק – אשר ימלא אותו בברגים ע”פ הכיתוב: “ברגים 123”. הארגז יחזור מלא בחלק החסר לשולח – במקרה שלנו הצוות של יושימושי במחלקת הדלתות.

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

Amplify Learning / Amplify Feedback
עוד עקרון חשוב, שהוא אולי המוכר ביותר במתודולוגית SCRUM, הוא העקרון של קיצור מחזורי ה feedback על מנת להגביר את הלמידה.

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

וכו’

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

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

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

מנהלים בעולם התוכנה נוטים להתכחש לכמות העבודה המבוזבזת בגלל חוסר ניידותם של העובדים – אולם לאחר שהניידות  מתאפשרת, מתברר לכולם עד כמה אפשר היה להשתמש בכלי זה. בעולם ה Agile הצוותים הם אוטונומים ויכולים לבצע פי’צר שהלקוח מבין מתחילתו ועד סופו. הצוות לא אמור לחכות ל “API מצוות B” – הוא יכול לבצע הכל בעצמו ולא יהיה מצב שקומפוננטות לא מעניינות מתפתחות יתר-על-המידה בגלל שיש מישהו שיודע רק לפתח בהן והיה לו זמן מיותר.

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

Genchi Genbutsu – “לכלך את הידיים”
עקרון זה טוען שהבנה טובה נרכשת רק דרך עשייה. במקום שמנהלים יקראו ספרים על SCRUM ויביטו בו מרחוק – עליהם להתנסות ולהצטרף לצוות SCRUM. על הארכיטקטים ללכך את הידיים בקוד ולא להסתפק בישיבה במגדל השן ולהעיר הערות. על המפתחים להתקין את המוצר בעצמם בסביבה דומה לזו של לקוח בכדי ללמוד מה מצפה ללקוח או ה QA שמשתמש בקוד שלהם.

[1] Retrospective גם מתמפה לעקרון ב TPS שנקרא Hansei – התבוננות עצמית.

[2] לאחר שיצא לי לחוות את Agile ועקרון ה Flow, כל פעם שאני שומע את הפועל “נדחוף” (פיצ’ר/תוצר/יזמה) נאמר – אני בודק האם מדובר בתוספת שלא באמת נחוצה ע”פ בחינה אובייקטיבית.

• את המשימה (למשל: בניית רכב) יש לחלק למשימות פשוטות וסדרתיות.
• על המנהל להדריך את העובד ולהקים עבורו סביבת עבודה אופטימלית ליעילות גבוהה – אין להשאיר דבר ליד המקרה (או מוחו המוגבל של העובד).
• כל עובד מתמחה במשימה ספציפית ומתוגמל ע”פ הספק.
• הקמת מכוונת הכי גדולות, הכי יעילות בעזרתן כל עובד יוכל לבצע משימה כלשהי במהירות אדירה.
• ניהול מלאי מספיק גדול בכדי שהמכונות לא יפסיקו לעבוד לרגע. Time is money, friend.

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

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

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

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

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

תרומה משמעותית נוספת הייתה של פרופ’ אדוארד דמינג, חוקר אמריקאי שהציג גישה חדשה לאיכות: “איכות אינו שלב בתהליך, איכות צריכה להיות שזורה בתהליך – לכל אורכו” (מה שנקרא TQM – Total Quality Management). בעוד שבארה”ב לא התייחסו אליו ברצינות, ביפן גילו עניין עצום בתורתו, אימצו אותה והוא קיבל מעמד של גורו-על.

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

יעילות נוסח טויוטה / Agile / Lean

מפגש התרבויות

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

לעזרת היפנים, במקרה, הגיע משבר האנרגיה של 1973 – כאשר מדינות ערב עצרו את אספקת הנפט למערב כתגובה לתמיכתן בישראל במלחמת יום הכיפורים. מחירי הנפט האמירו בצורה חדה (המחיר עלה פי 4 תוך זמן קצר. בחישוב מנורמל להיום: מ 15$ ל 60$ לחבית). התלות של המערב בנפט הייתה טוטאלית: עסקים הפסיקו לעבוד (לא יכלו לייצר ברווח), הכלכלה קרסה ולחלופות זולות ומיידיות לאנרגיה היה ביקוש רב. הצרכנים האמריקאים החלו לחפש רכבים הצורכים מעט דלק וכך שיחק מזלן של היצרניות היפניות: הן הצליחו לחדור בצורה משמעותית לשוק האמריקאי. משבר האנרגיה הסתיים ב 1974 כאשר מצד אחד ארה”ב דרשה מישראל לסגת מסיני (לא, נראה שזו לא הייתה יזמה ישראלית. חומרי הלימוד של משרד החינוך בהסטוריה הם קצת מגמתיים) ומצד שני בריטניה הציגה בפומבי תוכנית אופרטיבית לפלוש למדינות ערב ולקחת את הנפט בכוח.
אותה שנה הספיקה לטויוטה להגיע למספיק לקוחות אמריקאים בכדי שיגלו שני דברים:

• המכוניות של טויוטה לא כ”כ גרועות.
• המכוניות של טויוטה, באופן מוזר, אינן מתקלקלות.