משחקים רציניים

ינואר 18, 2017 • בלוג • סמדר כהן איסבורנו (Smadar Cohen Isvoranu)

לימוד ותרגול מהלך פיתוח מוצר באמצעות Set-Base Concurrent Engineering: סמדר כהן-איסבורנו מסכמת סדנת פיתוח מוצרים וטכנולוגיות ע”פ עקרונות ה-Lean בהנחייתה של ד”ר מוניקה רוסי.

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

 Lean Global Network. הסדנה – בהנחייתה של ד”ר מוניקה רוסי מהמחלקה לניהול, כלכלה והנדסה תעשייתית באוניברסיטת Politecnico di Milano שבאיטליה – שילבה גם משחקים רציניים (“serious games”). לאחר שהבנו את הקונטקסט ואת הערכים הבסיסיים של ה-Lean, התנסינו מעט בהערכת ומדידת הבזבוז בארגון שלנו, ולשם כך שיחקנו במשחק הבא: קיבלנו מטלה לבנות דגם של מטוס מלגו, המורכב מ-4 חלקים: גוף, תא-טייס, זנב וכנפיים. קיבלנו הנחיות ברורות, מפרט טכני ודרישות לקוח מפורטות, ויצאנו לדרך, כמובן לא לפני שבחרנו שם ליחידת הפיתוח שלנו.

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

דפי תכנון והגדרת מרחב האפשרויות של כל אחת מתתי-המערכות

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

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

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

אז מה היה לנו כאן? למדנו בכיף מערכת טכנית הנדסית מורכבת ואת עקרונות תפיסת ניהול הפיתוח ותכנון מהלך ייצור מוצר חדש על פי שיטת Lean Product &Process Development) LPPD).

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

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

סמדר כהן-איסבורנו, ILE

כתיבת תגובה

האימייל לא יוצג באתר.