דפים

יום שני, 12 בנובמבר 2012

Kanban - על מה כל המהומה


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

הקנבאן מגיע אלינו מארץ השמש העולה ע" Taiichi Ohno חבר הנהלה בחברת טויוטה.
נשמע לכם מוכר ? (אם עניתם בשלילה על שאלה זו -  אזי אני ממליץ להתחיל עם Lean על מה כל המהומה בבלוג זה)


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

מהם עקרונות השיטה ?
1.שיקוף "זרם" העבודה
2.מימוש – pull Vs push
3.הגבלת הפעילות ב"ייצור"
4.בקרה ושיפור

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

Taiichi הבין שאם נוכל לשקף (visualize) את זרם העבודה (Flow) הרי שכך נוכל לחסוך את ההשקעה על שלבים א, ו-ג בתהליך, ולתת בצורה מהירה את הפתרון הנדרש. התוצאה הינה קיצור ה cycle time מרגע אישור הדרישה ועד להפיכתה למוצר (production)
במושגי עולם הפיתוח – זרם העבודה מתייחס לכל אותן התחנות שעל דרישה חדשה לעבור לפני הפיכתה למוצר (דהינו – ניתוח, פיתוח, אינטגרציה, בדיקות, וכו' ..)

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

3.הגבלת הפעילות ב"ייצור"
(כן כן, זו לא טעות - הגבלה ולא הגברה)
כאשר אני מעביר סדנאות על קנבאן, השלב הזה תמיד מעורר תמיהה. אם בשלב הראשון הדגשנו את חשיבות זרם העבודה מדוע אנחנו רוצים עתה להגביל אותו ?
התשובה במשפט אחד קשורה לנקודה בה אנחנו רוצים למדוד את הערך (value).
ועכשיו להסבר. נחזור לדוגמה של הצינור -
נניח וזיהינו בעיה אשר קיימת באמצע הצינור ובשל כך הזרימה של המיים בסופו יורדת לחצי. (נניח והצינור חצי מקופל)
האם זה משנה, שבחצי הראשון של הצינור המיים זורמים בלחץ נכון ?
האם הוספה של לחץ מיים חזקה יותר בחצי הראשון תגרום לפתרון הבעיה ?
כמובן שלא.
מדוע ? כי מה שמעניין אותנו הוא הזרימה בסוף הצינור. שם נמצא ה"ערך" אשר אותו אנחנו מודדים.
באותו אופן אם נדמה את החצי הראשון של הצינור לשלב הפיתוח, ואת החצי השני לשלב הבדיקות - 
אם נשקיע יותר ויותר מאמצים בפיתוח ו"נתעלם" מהבעיה שקיימת בחצי השני של הצינור (הבדיקות) הריי שבכך לא נגדיל את ערך התוצאה.
למזלנו אנחנו מדברים על משאבים, ולהבדיל מצינור המיים אנחנו נוכל למקד אותם באזורים שונים בתהליך על מנת שנוכל להתמקד בערך הסופי ולא בתוצר הזמני.
אז איך עושים זאת? המושג מעולם ה kanban נקרא WIP, ראשי תיבות של work in progress
אנו נגביל את המאמץ שאנחנו מוכנים להשקיע בשלב מסויים (לדוגמה מספר המשימות שכרגע בשלב הפיתוח עצמו) .את "שאר" המאמץ נפנה לאזורים אחרים להם זקוקים בתהליך (לדוגמה הבדיקות)

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

שורת סיכום
מספר דברים-
1.   לאורך כל המאמר אני לוקח כדוגמה את הבדיקות כאזור בתהליך אשר מעכב את הזרימה. הסיבה היחידה היא שבמרבית הארגונים היחס בין גודל הפיתוח לבדיקות הוא קטן במספר מכפלות. ולכן לרוב הוא זה הזקוק למאמץ נוסף. (ולא מכל סיבה אחרת)
2.   להבדיל ממתודולוגיות אג'יליות אחרות (כדוגמת Scrum, XP) בהם כבר בשלבים הראשונים יש צורך בהטמעת שינויים גדולים (תהליכים, תפקידים, אחריות, וכו' ..) ב kanban הגישה היא אחרת.
השלב הראשון ב kanban הינו העלאת המצב הקיים אל ה"לוח" מבלי לשנות דבר, ביצוע בחינה ובקרה של הזרימה, זיהוי נקודות צוואר הבקבוק, ורק אז הגדרת פתרון המתאים לבעיה.

בהצלחה!

אין תגובות:

הוסף רשומת תגובה