פתרון בעיות בהנדסה: המדריך המעשי לפיתוח מוצר

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

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

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

הבעיה האמיתית היא אף פעם לא איפה שחושבים

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

זה לא מקרה נדיר. זה דפוס. אנשים רואים את מה שנשבר, לא את מה שהעמיס עליו עד שנשבר.

הסימפטום עושה רעש והשורש שקט

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

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

בעיה שמוגדרת לא נכון מייצרת עבודה אמיתית סביב תיקון מדומיין.

עם מי מדברים לפני שנוגעים בתכן

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

• מפעיל הרכבה יגיד לכם איפה צריך "לשכנע" חלק להיכנס.

• איש ייצור יספר איזה חלקים מגיעים עם שונות שמקשה על הקו.

• מבקר איכות יראה באילו דגימות התחילו חריגות.

• איש שירות יבדיל בין כשל אקראי לדפוס חוזר.

• מהנדס התכן חייב לחזור למודל בלי אגו, ולשאול מה הונח כמובן מאליו.

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

מתי יודעים שהגענו להגדרה נכונה

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

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

איך לחפור עד לשורש הבעיה בלי לקדוח בטעות

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

חמשת הלמה לא נועדו לישיבת איכות

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

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

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

לעצור לפני שמתחילים להאשים

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

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

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

שורש הבעיה הוא לעיתים תהליכי

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

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

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

הניסוי הנכון שווה אלף פגישות

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

בפיתוח חומרה, ידע קונים דרך ניסוי. לא דרך דעה מנומקת היטב.

מה ניסוי טוב באמת צריך לעשות

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

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

דיון ארוך מייקר את הטעות

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

להלן השוואה פשוטה בין שתי דרכים נפוצות לעבוד:

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

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

לא לבנות POC כאילו הוא המוצר הסופי

אחת הטעויות השכיחות היא להפוך Proof of Concept לפרויקט צדדי עם שאיפות מוגזמות. POC לא צריך להיות יפה. הוא צריך להיות חד. אם אפשר להדפיס חלק במדפסת תלת־ממד כדי לבדוק התאמה מכנית, עשו את זה. אם אפשר לבנות ג'יג פשוט מאלומיניום, אקריל או אפילו חלקים מוכנים מהמדף, עשו את זה. אם צריך לבדוק רכיב בתנאים חריגים, התחילו בבדיקה גסה שתלמד משהו מהר.

במילים אחרות, אל תשאלו "איך נוכיח שזה יעבוד". תשאלו "איך נוכיח מהר שזה לא מה שחשבנו". משם הלמידה מתחילה.

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

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

לעצב פתרון שאפשר לייצר באמת

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

שני פתרונות על השולחן

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

על המסך, הפתרון הראשון מנצח. ברצפת הייצור, בדרך כלל השני.

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

מה DFM משנה בהחלטה

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

כמה שאלות ששווה לשאול מוקדם:

• איך החלק יוצא מהכלי. אם צריך פתרונות תבנית מסובכים, העלות, הסיכון והתחזוקה עולים.

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

• איך בודקים אותו. אם אי אפשר למדוד או לאמת בקלות, איכות תגיע מאוחר מדי.

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

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

לבחור בפתרון המשעמם

הפתרון הנכון הוא לא זה שמרשים את צוות הפיתוח. הוא זה שקו הייצור לא צריך להילחם בו.

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

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

האמת הלא נוחה על בקרת איכות ותיעוד

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

בעיה לא נפתרה עד שאפשר להוכיח את זה

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

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

תיעוד הוא לא ארכיון מת

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

כדי שתיעוד יהיה שימושי, הוא צריך לכלול לפחות את המרכיבים הבאים:

• מה נכשל בפועל. לא ניסוח כללי, אלא תיאור כשל שניתן לזהות.

• מה נבדק בדרך. גם כיוונים שהתגלו כשגויים חשובים, כי הם חוסכים סיבוב חוזר.

• מה שונה ולמה. ההיגיון חשוב לא פחות מהשרטוט עצמו.

• איך מאמתים בעתיד. אחרת אין דרך לסגור מעגל.

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

QA ותיעוד הם חלק מאותה פעולה

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

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

פתרון בעיות הוא לא אירוע, הוא תרבות

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

איך תרבות כזו נראית ביומיום

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

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

מה צוותים חזקים מטפחים

יש כמה הרגלים שמבדילים בין צוות שמכבה שריפות לצוות שבונה יכולת:

• שפה משותפת. כולם יודעים להבדיל בין סימפטום, השערה, שורש כשל ואימות.

• כבוד לייצור. לא מתייחסים לקו כאל תחנת ביצוע, אלא כמקור ידע.

• ניסויים קטנים ומהירים. לא מחכים לפתרון גדול כדי להתחיל ללמוד.

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

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

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

---

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