יום שישי, 20 בספטמבר 2013

איכות

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

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

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

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

אבטחת איכות (Quality Assurance = QA) – זה מכלול הצעדים והפעולות שנועדו להבטיח איכות תקינה ב-100% מהמוצרים (או תהליכי השירות. זה אומר שנדרש לעבוד כל הזמן לשפר את איכותם של התהליכים, לנתח את הכשלים כשהם מתגלים (ולא לאסוף סטטיסטיקות מבלי לעשות כלום איתן), לנתח את סיבות השורש לליקויים שמתגלים ולתקן אותם.

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

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

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

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

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

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


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

סוף שבוע מוצלח לכולנו, ומועדים לשמחה

אין תגובות:

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

אשמח כמובן לתגובות. תודה :-)