קאנבאן (Kanban) – תהליך שמתנהל מעצמו

1. החברה מגדירה ומאיישת תפקיד בשם ״מנהלי מלאי״.
2. כשהמלאי מגיע לרמה הנמוכה ("מלאי מינימום") מנהל המלאי מבצע הזמנה על מנת למלא את המלאי לרמה הגבוהה (מה שנקרא בטעות "מלאי אופטימום"[ג]). 
3. "מלאי האופטימום" היא תחזית סטטיסטית, של מנהלי המלאי, על הביקוש העתידי לחלק. 
4. מנהלי המלאי הם בעלי הבנה קטנה בייצור. ה"חלקים" ומבחינתם אלו יכולים להיות מנועי בואינג 747 או עגבניות. Same Same. 
5. חלק גדול מהעבודה של מנהלי המלאי מושקע בזיהוי הפריטים והזמנת החלק הנכון. לכל חלק יהיה שם, מספר קטלוגי פנימי, מספר קטלוגי יצרן, פרטים לזיהוי היצרן, תמונות שיסייעו (למנהלי המלאי – האנשים במפעל כבר יודעים) לזהות את החלקים וכו'. אופרציה שלמה. הזמנות מלאי לרוב נעשות באצוות (batch) על מנת "לקבל מחיר טוב יותר ולחסוך כסף במחלקת המלאי".

הגישה המערבית לייעול התהליך היה רכישת תוכנה יקרה עם מיליון אפשרויות (ניהול מלאי הוא עסק מסובך) שתסייע למנהלי המלאי לעבוד מהר יותר ("Send an order by one-click").
גישת ה LEAN, שצמחה מיפן, הייתה לשלוח את כל מנהלי המלאי להיות עובדי ייצור – ולבטל כמעט כליל את תפקיד ניהול המלאי.

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

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

קאנבאן (kanban), שהחל כתהליך של טויוטה, הפך עם השנים לתהליך עולמי:

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

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

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

קאנבאן Kanban בתוכנה
על פניה, קאנבאן היא מתודולוגיה מאוד פשוטה: היא מגדירה 4 חוקים שיש למלא:

• גרמו לתהליך להיות נראה (visible) ע"י פרסום גלוי של מידע-מפתח[ד].
• הגבילו את מספר הפריטים שבעבודה (Work In Progress = WIP)
• הגדירו מדדי הצלחה ופרסמו אותם.
• שפרו, באופן עקבי, את התהליך.

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

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

אם ראיתם פעם את רשימת המטלות של ארגון סאפורט (כלומר Product Backlog), אתם בוודאי יודעים שיכולים להיות עשרות קייסים בטיפולו של כל צוות. אי-ניהול ה Sprint Backlog יכול ליצור מצב לא יעיל בו אנשי-הצוות במקביל על הכל (חוק התיכנותיקה: "ל Context Switch תמיד יש מחיר"). באירגון סאפורט קשה מאוד "להתחיל קייס ולסיים" – מכיוון שיש תלויות חיצוניות.
לשם כך מגדירים בקאנבאן מגבלה בשם Work In Progress. המגבלה מחייבת את הצוות, מצד אחד, לא לעבוד במקביל על יותר ממספר פריטים (כל צוות קובע עם הזמן את ה WIP שלו). מצד שני היא מחייבת את הצוות "לסיים" נושאים ויהי-מה, אחרת כל ה slots של ה WIP יתמלאו – והצוות לא יוכל להמשיך לעבוד.

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

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

למרות שקאנבאן נתפרה לצוות ללא Deliverables – גם צוותי פיתוח יכולים לעשות קאנבאן והיטב. באופן אישי אני מעדיף  לעשות "קאנבאן עם ספרינטים". לקחת את קאנבאן כפי שהוא, ללא תפקידים מיוחדים (Scrum Master) או טקסים (Stand-Up Sit-Down meeting ואחרים), אבל עדיין עם תצוגת התקדמות יזומה בצורת ספרינט רביו: "מה עשינו בשבועיים-שלושה האחרונים".

שיהיה בהצלחה!

—

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

[ג] רכישה של חלקים שיושבים במחסן במשך זמן ללא שימוש = מינוס בבנק וריביות. הרבה רכיבים כאלו זה בהחלט לא "אופטימום".

[ד] ברוח ה Waterfall האהוב, הצעד הראשון של ארגונים רבים במימוש Scrum או Kanban הוא השגת תוכנה (יקרה) שתעזור לנהל את התהליך בצורה Efficient (= מהירה לכאורה). ניהול הסטטוס של הצוות בתוך תוכנה, כך שצריך לגשת למחשב וללחוץ כמה קליקים על מנת לראות נתון כלשהו, היא הדרך ליצור חוסר-נראות. האאא הרגלים רעים…