קיצור תולדות ה SCRUM, חלק 2 – עקרונות ה LEAN

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

לא משנה באיזו מתודולוגיה אג'ילית תבחרו לעבוד ובאיזו תעשייה, שווה להכיר את המקור – הרי הוא ה (TPS (Toyota Production System של חברת טויוטה. להלן כמה מהערונות העיקריים של ה TPS שאומצו ע"י תנועת ה LEAN. קרוב לוודאי שכמה מהמושגים שאציין ישמעו לכם מוכרים.

שייך לסדרה: אג'ייל – מתודולוגיות פיתוח רזות

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, כל פעם שאני שומע את הפועל "נדחוף" (פיצ'ר/תוצר/יזמה) נאמר – אני בודק האם מדובר בתוספת שלא באמת נחוצה ע"פ בחינה אובייקטיבית.

קיצור תולדות ה SCRUM, חלק 1

לעיתים אנו, בתעשיית התוכנה, נוטים לחשוב שאנו התעשייה החדשנית והמתקדמת ביותר. ״טכנולוגיה גבוהה״ הוא אכן שם מעורר גאווה.

לא מעטים יספרו על גוגל – חברה שכמוה לא הייתה מעולם: ״איזו חברה מאפשרת לעובדים לעסוק יום בשבוע במה שמתחשק להם??". ויש גם את SCRUM, XP וכל תנועת ה Agile: מי שמע על דבר דומה בתעשייה המסורתית?

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

שייך לסדרה: אג'ייל – מתודולוגיות פיתוח רזות

מי שעוד מתמודד עם הבנת SCRUM – מוזמן לבדוק את התרגום העברי לספרון המצויין: "סקראם מהשוחות" (שוחה – קדמת שדה הקרב)

במשך השנים תעשיית התוכנה חיפשה רבות, אך כמעט ולא מצאה כלים שמסייעים משמעותית לפריון (Productivity) : לא OO, לא IDEs, לא שפות תכנות חדישות, לא שיתוף קוד ולא SOA. אולי אפילו ההפך [1].

היו מספר שיפורים מורגשים. המעבר משפת אסמבלי לשפות עליות היה שיפור גדול מאוד. השימוש ב Garbage Collator הוא עוד שיפור מובהק. גם המעבר לעבודה במתודולגית SCRUM נראה כשיפור משמעותי. כנראה הגדול בעשור האחרון.

SCRUM (ואג'ייל בכלל) לא רק מסייע לפריון, אלא לרוב גם עוזר ליצור מוצר שמשביע את דרישות הלקוח בצורה טובה יותר ואף מסייע להטמעת איכות גבוהה יותר [2].

בואו ונחזור אל ההיסטוריה, מאין הגיע ה SCRUM/AGILE/LEAN וכיצד הוא נוצר…

מפעל המכוניות של משפחת טויודה

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

בשנת 1937 הקים טויודה חברה לייצור מכוניות – תחום מבטיח שצמח במהרה. אולם באותה תקופה ביפן לא היו מקובלות הלוואות, מכירה באשראי או השקעות חיצוניות (כגון Venture Capital). זו הייתה מגבלה חמורה ליכולת של העסק לצמוח במהירות. רק לאחר שסיים את ייצור batch של רכבים יכול היה למכור אותם ברווח קטן ולהתחיל ב batch גדול מעט יותר. מהירות הכנת ה batch (מה שנקרא Lead Time) וכמות המזומנים הזמינה בכיס בכל רגע נתון, הפכו להיות הגורם המרכזי ביכולת החברה לצמוח. טויודה התמקד במשימה: פיתוח הדרכים היעילות ביותר לקיצור ה Lead Time והגדלת ההון הנזיל.

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

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

יעילות נוסח המהפכה התעשייתית / Waterfall
יעילות עור-ועצמות

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

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

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

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

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

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

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

  • המכוניות של טויוטה לא כ"כ גרועות.
  • המכוניות של טויוטה, באופן מוזר, אינן מתקלקלות.
עוד ועוד לקחות רכשו את "המכוניות שאינן מתקלקלות" וחברות הרכב נלחצו וניסו להבין "איך היפנים עושים את זה?" [5].
ב1980 פורמה כתבה ברשת NBC שעוררה הדים בשם "?If Japan Can, Why can't we".

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

אימוץ השיטות של טויוטה בעולם המערבי
השם שנתנו האמריקאים לשיטה היפנית הוא Lean Manufacturing ולרעיון של ניהול מלאי – (Just In Time (JIT. שם אמריקאי ומדריכים אמריקאים עזרו רבות לקבל בחום את השיטה. אימוץ השיטה התחיל אמנם מתעשיית הרכב אולם התפשט לתעשיות אחרות רבות. כיום רוב תעשיית הייצור, אך גם חלק גדול ממגזר השירותים, הבנייה, רשתות קמעוניות ואפילו משרדי ראיית חשבון והמוסדות האקדמים אימצו את עקרונות ה Lean. הייתרון התחרותי הינו כ"כ חד-משמעי, כך שבתעשייה בה קם שחקן שאימץ את השיטה בהצלחה – נאלצו שאר המתחרות לאמץ אותה גם כן על מנת לשרוד[6]. אם תבקרו, למשל, בסניף של דומינוס פיצה ותצפו בעובדים בפעולה – תוכלו לזהות רבים מהעקרונות שאציין בהמשך. אם תשאלו את העובדים האם הם עובדים "Lean" קרוב לוודאי שתענו: "מה?? … לא. סתם. ככה אנחנו עובדים פה".

בתעשיית התוכנה, היו כמה נסיונות ליישם מתודולוגיות פיתוח המבוססות על עקרונות ה Lean כבר באמצע שנות ה-90. תשומת הלב המשמעותית הגיעה לדעתי עם הופעת ה Extreme Programming אותה הציג קנת בק – מתודולוגיה קיצונית אך מעוררת מחשבה.
עולם התוכנה נתן שם משלו לסגנון ה LEAN ושמו: Agile. עבודה רבה נעשתה ע"י מרי וטום פופנדיק אשר חזרו למקורות ועזרו לתרגם את רעיונות ה LEAN לעולם התוכנה בצורה מקיפה [7]. בשנת 2001 התכנסו כמה מראשי המתודולוגיות השונות לחתום על מסמך הסכמות המשותף לכל המתודולוגיות – הרי הוא ה Agile Manifesto.

נראה שרק שבאמצע שנות האלפיים ה Agile "חצה את התהום" – והגיע למיינסטרים. כיום חברות רבות, כגון Microsoft, Yahoo, Google, SAP, IBM, Salesforce ועוד אימצו בחלקים כאלו או אחרים את SCRUM ובהצלחה.

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

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

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

[1] מה שנקרא "There is no Silver bullet".

[2] ישנם דיווחים על הצלחה של SCRUM בחברות שונות, גדולות וקטנות – אך עדיין מוקדם לדעת בוודאות מה גודל ההצלחה. מנסיון אישי, קשה לי לחשוב על שינוי משמעותי בתעשייה בעשור האחרון שמשתווה ל Agile. למשל, TDD הוא נהדר – אבל הוכח כבר שאינו מתאים לכל אחד = אינו scalable ברמת התעשייה. SCRUM הצליח אצל אנשים שאהבו אותו יותר ופחות, ארגונים קטנים וגדולים, פרוייקטי פיתוח ותחזוקה. כמובן שיש ש SCRUM לפעמים הצליח פחות ולפעמים יותר.
[3] כמובן שהשפל הגדול היה האטה משמעותית במגמה, אך זה רק היה עיכוב – והיא המשיכה  והתעצמה.

[4] מספר משיכות המכחול לכתיבת "טויוטה" הוא שמונה. מספר מזל בתרבות היפנית, שאינה נקייה מאלמנטים מיסטיים.

[5] כיום לטויוטה (ולמותג היקרה שלה – לקסוס) יש רק ייתרון קל באיכות ע"פ המתחרות האחרות (ע"פ סקרי J.D Power אשר בונים בסיס נתונים על תקלות ברכב של עשרות אלפי לקוחות). בשנות ה-80 פער האיכות היה משמעותי ביותר, אך נראה שהפער הצטמצם בכך שכל חברות הרכב בעולם אימצו את שיטת ה Lean.

[6] דוגמא טובה היא DELL שהצליחה לייצר מחשבים מהר, טוב וזול מהמתחרות ושברה את השוק. HP אימצה את שיטות ה Lean גם כן, התאוששה, סגרה פערים ואפילו התקדמה קצת מעבר.

[7] הספר הבולט והמומלץ ביותר הוא כנראה Lean Software Development שיצא ב 2003 אך עדיין מאוד רלוונטי.