עקרון הזרימה הרציפה בטויוטה או הבסיס לצוותים אג’יליים?

בקצרה:

בהרחבה:

כפי שארחיב בסדרת פוסטים בזמן הקרוב, שיטת העבודה של טויוטה שהתפרסמה בשנות ה- 80′ הפכה להיות מהמפורסמות בעולם ומכונה TPS- Toyota Production System. שיטת העבודה שלה מתבססת על פירמידת עקרונות הניהול אשר שמה בקידמה את המצויינות התפעולית שלה והיא נלמדת כיום בקורסים רבים במגוון התארים, שכן יש בה אספקטים ניהוליים, תפעוליים, מוצריים וכו’ שיש בהם מה ללמוד לכל אחד ואחד. מערכת הניהול של טויוטה היא בעצם הבסיס ל – Lean Management ולכל תיאוריות ה- Lean Startup וכו’ שבאו בעקבותיה. גם מינוחים המוכרים לנו כיויום כמו KANBAN ותפיסת השיפור המתמיד (המכונה KAIZEN ביפנית), הם מונחים שהוטבעו בעקבות השיטה של טויטה. אז מאיפה זה התחיל, ואיך העקרונות האלו דומים – אפרט בפוסטים הבאים ובינתיים אצרף רק תמונה של העקרונות המרכזיים, לקראת הפוסטים הבאים.

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

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

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

אבל מה הבעיות בשיטה כזו?

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

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

ולכן מה טויוטה מציעה ומה התועלת בשיטה זו?

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

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

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

אז איך זה נוגע לעולם פיתוח התוכנה?

הרבה מחלקות פיתוח בתחילת דרכן מחולקות ל- Front end, Back End, QA וכו’. המחלקות נדרשות לסנכרון משמעותי ביניהן כדי לייצר בסוף קטע קוד שהוא באמת מועיל ללקוח והרבה פעמים מחלקה אחת תכתוב את החלק שלה ולאחר מכן הקוד יישב על המדף ויחכה למחלקה אחרת שתסיים את החלק השני. כתוצאה מכך, קוד שיושב על המדף ולא נמצא בפרודקשיין הופך להיות ישן וכאשר מגיע למרג’וג’ דורש תיקונים ועדכונים כדי לצאת. לא רק זה, אלא שכל עניין האחריות על משהו שבסוף עובד מתפרס על פני יותר מדי אחראים.

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

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

האם גם אתם אנשי אופרציה העוסקים בתהליכי עבודה, מתודולוגיות וכלים בעולמות הפיתוח? אם כן, נשמח שתצטרפו לקבוצת Engineering Operations בוואטסאפ ותעקבו אחרינו בעמוד ה- Linked In שלנו.