תקן AS9100D פותח על ידי האיגוד לאיכות בתעשיות התעופה והחלל International Aerospace Quality Group IAQG. התקן מחייב ארגונים בתעשיות התעופה וכן את הספקים של אותם ארגונים לעבוד לפי הכללים המחייבים של התקן כדי להיות ספק מורשה בתעשייה זו.
חברות העוסקות בתחום התעופתי, להן תקן 9100 AS, נדרשות לעדכן את מערכת האיכות שלהן למהדורה החדשה AS 9100-D עד ספטמבר 2018. המהדורה החדשה הושקה בארץ לפני כשנה. כנראה הארגון המוביל את התקן, IAQG, מצפה לעדכון מערכת האיכות בארגונים במהירות של מטוס או טיל.
נזכור כי לספקים של תעשיית התעופה והחלל, תקן זה משמש תנאי סף כדי להיות ספק לחברות בתחום. במקרים אלה נכונה אימרת חז"ל: "מתוך שלא בא לשמה, בא לשמה", כלומר: מטמיעי התקן יוצאים נשכרים מיתרונותיו, גם אם הם מטמיעים אותו בגלל דרישה של לקוחות.
מאמר זה, מתרכז בעיקר בשינויים בין המהדורות, כדי לסייע למי שצריך לעדכן למהדורת AS 9100-D במהירות.
הצורך הכי בסיסי ומיידי – תקן AS9100-D מתבסס על תקן ISO 9001:2015 ומוסיף לו דרישות ספציפיות הנדרשות לתחום התעופה. ISO 9001 הוא תקן לניהול איכות בסיסי שחובה על ארגונים לעבוד לפי המהדורה החדשה, ISO 9001:2015, לא יאוחר מספטמבר 2018. תקן AS9100-D מכיל את כל השינויים והתוספות של המהדורה ISO 9001:2015 ובנוסף – צרכים נוספים שזוהו בשנים האחרונות.
עדכון תקן AS9100-D, נותן לתעשיות התעופה, החלל והביטחון את היתרונות הבאים:
להלן פירוט של השינויים העיקריים בין מהדורת תקן AS9100-C למהדורת תקן AS9100-D.
השינויים במהדורה AS9100D כוללים את כל השינויים והתוספות של המהדורה ISO 9001:2015, כולל ניהול סיכונים והזדמנויות בתהליכים, במוצר ובארגון. העדכון למהדורה D בא בעקבות מהדורת 2015 של ISO-9001 וכולל אותה בשלמותה. בנוסף על שינוי מבנה התקן בהתאם למבנה החדש של ISO-9001 שכלל הזזה וניסוח של תוספות התקן, הוכנסו תוספות שעיקרן להלן.
מוצר בטוח לשימוש הוא מוצר שהארגון יכול להבטיח שלא ייגרם נזק לא סביר לאנשים או רכוש כתוצאה משימוש במוצר.
הארגון נדרש לתכנן, ליישם ולבקר את התהליכים המבטיחים את בטיחות המוצר במהלך כל מחזור חיי המוצר. תהליכים אלה יכולים לכלול:
פריט מזויף הוא פריט לא מקורי שמחקה פריט מקורי.
הארגון נדרש לתכנן, ליישם ולבקר תהליכים כדי למנוע שימוש בחלקים מזויפים והכללתם במוצרים המיועדים ללקוחות. תהליכים למניעת שימוש בחלקים מזויפים יכללו:
הארגון נדרש לנהל סיכונים תפעוליים כדי להבטיח את איכות המוצרים והשירותים שהארגון מספק ללקוחותיו. מעבר לדרישות הבסיסיות של ISO 9001, הארגון נדרש להגדיר במפורש:
הדרישה למודעות העובדים לנושאים הקשורים לאיכות הורחבה. מעבר לדרישות הבסיסיות ב-9001:2015 ISO למודעות העובדים למדיניות האיכות, יעדי איכות, תרומתם לניהול האיכות ולמשמעות של אי התאמות והצורך לטיפול בהם, נוספה דרישה למודעות העובדים לתרומה לאיכות המוצר, בטיחותו והתנהגות אתית.
בעיקרון, אלה השינויים המרכזיים. מניסיוני במבדקי שדרוג – אלה מבדקים מאד יסודיים שעוברים מחדש על כל סעיפי התקן ולא רק על השינויים והתוספות. הזדמנות לרענן את כל מערכת האיכות ולוודא שאכן היא עובדת כהלכה.
מכירים את עיקרון הפרטו – 80-20? 20% מהלקוחות שלנו נותנים לנו 80% מהערך/תמורה/נתח שוק שלנו? לפעמים זה אפילו 90-10, ובמקרי קיצון של חברות סטארט-אפ מתחילות יכול להיות גם 99-1, כלומר: לקוח אחד מרכזי שמולו עובדים.
איך נדע להקשיב ולהבין במיוחד את הצרכים הספציפיים של אותם לקוחות מעטים שנותנים לנו ערך גבוה במיוחד? איך לבנות תהליך ממוקד ששם את המענה לצרכים ולאינטרסים של לקוחות אלו בראש סדר העדיפות שלנו תוך בניית תהליך המבטיח ביצוע של ההתחייבויות שלנו מולם ובונה אמון הדדי?
שיחות שאני עורכת עם מנהלים בארגונים להם מספר קטן ביותר של לקוחות (אך כל לקוח הוא משמעותי ביותר) מלמדת כי הדרך שלהם להתמודד עם הנושא היא בעצם בעבודה השוטפת הרגילה. ההרגשה היא כי אין מה לבדוק את שביעות רצונם כיוון שמתנהלת מולם עבודה שוטפת וההנחה הסמויה היא שאם הייתה אי שביעות רצון בסיכוי גבוהה ביותר שהנושא היה עולה באחד המפגשים/שיחות השוטפות. ובכן, זאת הנחה שלא תמיד עומדת במבחן המציאות.
כדי להבטיח שהמציאות לא תעמיד במבחן את הנחותינו – המאמר איך נבדוק את שביעות הרצון של הלקוחות המיוחדים שלנו? מציע שיטה פרואקטיבית לעבוד עם לקוחות מיוחדים שכאלה. השיטה היא בהשראת שיטת Balanced Scorecard (סרגל הישגים מאוזן) שנועדה במקור לניהול ביצועים פנימי של ארגון. השיטה מאתגרת כיוון שהיא דורשת עבודת צוות משותפת ספק-לקוח בשקיפות לאורך זמן ובצורה הדוקה.
מעוניינים לדעת איך? מוזמנים לקרוא את המאמר איך נבדוק את שביעות הרצון של הלקוחות המיוחדים שלנו?
לאותם קוראים הסבורים שהשיטה דקדקנית ודרשנית מידי – מזכירה לכם את שיטת הנכונות להמלצה. אפשר להגיד ששיטה זו היא בקצה השני של הסקאלה מבחינת מאמץ ההשקעה: עד שתי שאלות ללקוח. שיטה זאת מתאימה לכל החברות, לאו דווקא לחברות עם מספק קטן של לקוחות. החל מהמחצית השנייה של 2017 אני ממליצה ללקוחותינו בתחום 9001 ISO להשתמש במדד זה, והתגובות מהשימוש בו טובות מאד (פרטים במערכת למתעניינים..) מבחינת המשוב המשמעותי המתקבל מהלקוחות.
לסיכום,
ניוזלטר זה נותן לכם אפשרות לטעום שיטות יצירתיות לחזק את הקשר שלכם עם הלקוחות שלכם, כדי שלא תחשבו שהדרך היחידה הקיימת היא באמצעות סקר לקוחות הנעשה במקרים רבים כלאחר יד וכדי לצאת ידי חובה.
מקווה שתרמתי לכם,..
שלכם
אורנה קמין
מכירים את עיקרון הפרטו 80-20? דהיינו: 20% מהלקוחות שלנו נותנים לנו 80% מהערך/תמורה/נתח שוק שלנו? לפעמים זה אפילו 90%-%10, ובמקרי קיצון של חברות סטארט-אפ מתחילות יכול להיות גם 99%-%1. כלומר: לקוח אחד מרכזי או אפילו לקוח פוטנציאלי אחד שמולו עובדים.
איך נדע להקשיב ולהבין במיוחד את הצרכים הספציפיים של אותם לקוחות מעטים שנותנים לנו ערך גבוה במיוחד? איך לבנות תהליך ממוקד ששם את המענה לצרכים ולאינטרסים של לקוחות אלו בראש סדר העדיפות שלנו תוך בניית תהליך המבטיח ביצוע של ההתחייבויות שלנו מולם ובונה אמון הדדי?
במקרי קיצון כאלה, התהליכים הסטנדרטיים לבדיקת שביעות רצון לקוח לא מתאימים. הכוונה לביצוע סקרי שביעות רצון לקוחות, סקרי שביעות רצון משתמשים, משוב מלקוחות מיד לאחר אספקת מוצרים ושירותים, מדידת מידת נכונות הלקוחות להמליץ עלינו, הפקת לקחים מאירועים של נטישת לקוחות, ניתוח תביעות אחריות ועוד.
משום מה, הרבה ארגונים חושבים שכדי לבדוק את שביעות רצון הלקוחות עושים סקר שביעות רצון. מה קורה במקרים של חברות הזנק (Start-up) שאין להם עדיין לקוחות, או שמספר הלקוחות שלהם קטן? חברות טכנולוגיות, במיוחד חברות צעירות, עובדות במשך חודשים רבים (לעיתים אף שנים) עם לקוחות פוטנציאלים על הוכחת היתכנות של הפתרון שלהם (Proof-of-concept). במקרים אלה, הנטייה השגוייה היא להגדיר את תהליך בדיקת שביעות רצון הלקוחות כלא רלוונטי. הסיבות לכך: "אנו נפגשים עימם באופן שוטף ואם הם לא היו מרוצים היינו יודעים", או: " לא צריך לעשות סקר על לקוחות לא קיימים או שהם קיימים אך מועטים".
המאמר שלהלן מציע דרך להתמודד עם סוגיה זו. ההצעה תקפה גם לחברות שיש להן הרבה לקוחות, אך הן מעוניינות להשקיע יותר במספר מצומצם של לקוחות אסטרטגיים. התהליך המוצע תפור לצרכים של לקוח ספציפי, ולכן, אפשרי לעשות אותו רק עם מספר קטן של לקוחות או לקוחות פוטנציאלים ששביעות הרצון שלהם היא קריטית להצלחת החברה.
הרעיון של Customer Score Card בא בהשראת מתודולוגיית Score Card ארגונית, עם טוויסט בעלילה. בעוד ש- Score Card ארגוני מטרתו לסנכרן את כל הארגון סביב אוסף של מטרות ויעדים, Customer Score Card מטרתו לייצר שיח ייחודי בין החברה ללקוח המיוחד שלה. כיוון שתהליך זה דורש מיקוד מיוחד לכל לקוח, ניתן לעשות אותו מול מספר קטן יחסית של לקוחות.
תהליך Customer Score Card מאפשר לשתף פעולה עם לקוח כדי לפתח פתרון חדש לצורך שטרם ניתן לו פתרון. זאת בנוסף למענה לאי-התאמות שזוהו על ידי הלקוח או פערים בין מה שיש למה שרצוי שיהיה. שירות מיוחד יכול לעזור ללקוח לפתור בעיות אפילו אם הן אינן קשורות למוצר הספציפי שלנו.
הצלחה עם הלקוחות המיוחדים היא כאשר אנו בונים מולם אמון ושביעות רצון גבוהים, הבאים לידי ביטוי ברצונם להמשיך ולעבוד אתנו לאורך זמן.
גורמי ההצלחה המרכזיים:
א. כמו בכל יוזמה – מנהיגות ומעורבות של ההנהלה הבכירה
ב. מיקוד של העובדים ביצירת ערך מיוחד ללקוח
ג. התחייבות משותפת עם הלקוח להשגת תוצאות
ד. שקיפות – שיתוף מידע עם הלקוחות בתהליך העבודה מולם
מרכיבי התהליך:
הדוגמה שלהלן מדגימה כיצד עוקבים עם הלקוח לגבי התקדמות בנושאים תהליכיים. באופן דומה אפשר כמובן לשים גם יעדים מדידים ספציפיים לפונקציונאליות הרצויה של המוצר/שירות.
הטבלה שלהלן משווה את שיטת Customer Score Card לסקר שביעות רצון.
מאפשרת ללקוח להעריך את הביצועים של החברה ביחס לציפיותיו בנושאים החשובים לו ביותר.
מאפשר לחברה להתאים את הביצועים שלה לאותם לקוחות מועדפים ולהראות התקדמות לאורך זמן
מגייסת את מיקוד ההנהלה הבכירה בהשגת היעדים החשובים ללקוח, תוך הקצאת משאבים ותשומת לב ניהולית
מה אתם אומרים על השיטה? האם תשתמשו בה? מחכה לדיונים ושיתופים באחת הרשתות החברתיות שקישורן להלן.
| מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
נושא ניוזלטר זה הינו – ניהול מתודולוגי בחברות הזנק (Start-up). התנהגות "סטארטפיסטית" מוכרת היא ריצה קדימה שמתמקדת בפיתוח מוצר חדשני כדי לצאת לשוק הכי מהר שאפשר. מעגלים פינות, חותכים תהליכים סדורים, כדי להראות לעולם את המוצר החדשני, להיות מספיק משמעותיים כדי שלקוחות יתעניינו במוצר החדש ואף יביעו כוונות הצטיידות. רק אחרי שיש התעניינות חברות אלה מתחילות לחשוב על הטמעת תהליכים יעילים ושיטתיים, ברוב המקרים – כתוצאה מדרישה של לקוחות, או לקוחות פוטנציאלים. שלב ההבנה בצורך בעבודה שיטתית מגיע יחד עם ההכרה שלא מספיק שיש חזון ורעיון לכבוש את העולם. בלי תשתית תהליכית קשה מאד לעבור את משוכת הביצוע. דהיינו – למכור מוצרים איכותיים, קלים לתחזוקה ולשינוי ושיהוו בסיס לקו מוצרים עתידי של החברה. משום מה, נהוג לחשוב שכך עובדים בחברת Start-up; חשוב לי לציין שההתנהגות "סטארטפיסטית" קיימת גם בחברות מבוססות משיקולים שונים.
המאמר הראשון, ניהול מתודולוגי בחברת הזנק – וגר זאב עם כבש ? דן בהבדלים בין חברות מבוססות וחברות Start-up, ומציע פטנט סודי לגישור על הפער. הסוד יתגלה לקוראי המאמר שיתמידו לקרוא עד סופו. אשמח לשמוע מכל מי שגילה את הסוד את דעתו בעניין זה במייל חוזר אלי
עתה, נניח שעבדנו בחברה באופן "סטארטפיסטי" ובשעה טובה הלקוחות שלנו מתעניינים במוצר או בחברה. הלקוחות מבקשים מאיתנו לראות את מסמכי המתודולוגיה ואת תוצרי התהליך. מה עושים? איך מייצרים יש מאיין?…. יש פיתרון. מה עושים? מפתחים הפוך / מהנדסים לאחור. בשפה המקצועית קוראים לזה: הנדסה הפוכה / Reverse-engineering . מוזמנים לקרוא מאמר בנושא –
Reverse-engineering – עובדים הפוך! קודם מפתחים מוצר ורק אחר כך משקיעים בהגדרה מסודרת שלו! תקין? לא תקין? מה דעתכם על הרעיון? אני מביעה את רעיונותיי במאמרים. אשמח אם תשתפו אותי אם אתם חושבים כמוני.
לסיום, מאמר בונוס – איך נדע אם פרויקטים מצליחים או מוצלחים? מוזמנים לקרוא.
קריאה מהנה ומועילה,
שלכם,
אורנה קמין
מכירים חברות שיש להן חזון לעתיד טוב יותר, רעיון למוצר טכנולוגי מעולה והן שועטות קדימה לפתח את המוצר, הכי מהר שאפשר, מעגלים פינות, חותכים תהליכים סדורים, כדי להראות לעולם את הרעיון שלהם, ורק אחרי שיש התעניינות הם מתחילים לחשוב על הטמעת תהליכים יעילים ושיטתיים, שהרי לא מספיק שיש חזון ורעיון לכבוש את העולם. בלי תשתית תהליכית קשה מאד לעבור את משוכת הביצוע. דהיינו – למכור מוצרים איכותיים, קלים לתחזוקה ולשינוי ושיהוו בסיס לקו מוצרים עתידי של החברה. ברגע אמת זה, החברה נדרשת לעצור, להנדס לאחור, לחשב מסלול מחדש ואז להמשיך קדימה. ההינדוס לאחור הוא קשה, אך בלעדיו קשה הרבה יותר להמשיך קדימה.
הינדוס לאחור הוא תהליך שבו מנסים לפענח את תפקוד המוצר, הפונקציונאליות והמבנה שלו על סמך ההתנהגות שלו או על סמך פיצוח הקוד שמפעיל אותו. זהו תהליך הפוך לתהליך פיתוח רגיל של מוצר.
תהליך פיתוח מוצר או גרסה או איטרציה כולל באופן כללי את השלבים הבאים:
כל המתודולוגיות לפיתוח מוצרים מגדירות מסלול שכיוונו מההתחלה ועד לסיום. מדוע להגדיר פעילות בכיוון הפוך? מהקוד אחורנית לפענוח הפונקציונאליות של המוצר?
להנדסה הפוכה מגוון סיבות.
שמעתם על חברה שעושה הנדסה לאחור למוצרים שלה עצמה? מה לדעתכם יכולה להיות הסיבה לכך? הניחו שהמפתחים שפתחו את הקוד נמצאים בחברה.
ובכן…
מסתבר שהתופעה נפוצה ביותר. ישנן חברות סטרט-אפ ואחרות שיש להן רעיון למוצר חדש. חברות אלה, פותחות במרוץ כנגד הזמן לפתח אב-טיפוס, לפעמים לרשום פטנטים, להראות את המוצר לעולם, לחפש לקוחות שיתעניינו במוצר וירצו לקנות אותו או לשלב אותו במוצר שלהם. רק אחרי שיש התעניינות במוצר, מתחילות חברות אלה "להתמסד", ולפתח בדיעבד מסמכי דרישות מפורטים, לשחזר את ארכיטקטורת המוצר וכדומה.
התופעה קיימת גם בחברות ותיקות. גם בחברות אלה מוצרים לא תמיד מפותחים באופן סדור, חלק מהמפתחים עזבו או קודמו או שמפאת הזמן שעבר פרטי פיתוח המוצר נשכחו. הנדסה לאחור מתגברת על אובדן ידע שכזה.
הנדוס לאחור הוא הכרחי ממגוון סיבות:
לאחר שקיימים מתעניינים ויש פוטנציאל למוצר – החברה מחליטה לחזור לדרך המלך ולהשלים את כל קיצורי הדרך.
המוצר ממשיך להתפתח; נוספות לו תכונות חדשות; משנים תכנות קיימות; באגים מתגלים. בלי מסמכי מחזור החיים, קשה מאד להמשיך ולעשות שינויים במוצר ולתחזק אותו.
חלק מהמפתחים עוזבים, ובא דור חדש שלא עסק בפיתוח הראשוני …
הלקוחות הפוטנציאלים מבקשים לראות את מסמכי הפרויקט כדי להיות בטוחים שהם לא קונים חתול בשק.
על מנת להבין את המוצר מתוך הקוד שלו נדרש לפענח את הקוד, את המעגל חשמלי, או את הפונקציונאליות של המוצר. רק מהנדסי מערכת או מהנדסי תוכנה טובים יכולים לפצח קוד קיים, לתעד אותו, ולהבין את הפונקציונאליות שלו. מהנדסים אלה עושים עבודת בילוש אינטנסיבית ומפצחים צעד אחר צעד את הקוד. מאתגר למצוא מהנדסים שיסכימו לקחת משימה שכזו על עצמם. הרבה מהמפתחים מעדיפים הנדסה או פיתוח רגילים, כיוון ששם לשיטתם הם יכולים להביא לידי ביטוי את הפוטנציאל שלהם;
האמת – שלקרוא ולהבין קוד שמישהו אחר כתב ולא תעד, קשה בעשרות מונים מאשר לכתוב קוד על לוח חלק מההתחלה. מקצוענים בהנדסת מערכת / הנדסת תוכנה יכולים לעשות זאת. מכירים כאלה? מחפשים כאלה? גלו לי בבקשה.
באופן אישי, אני כמובן בעד הליך פיתוח שיטתי ומסודר. ברם, החיים הם לא שחור לבן אלא פלטה אינסופית של צבעים. יש בהחלט מצבים שחברות דוהרות קדימה עם המוצר החדשני שלהן. בשלב ההתחלתי, אין להם עדיין לקוחות והן רוצות לבחון את היענות השוק למוצר שלהם. ברגע שיש היענות טובה, החברה עוברת משלב של חברה חדשנית שממוקדת במוצר שלה, לחברה שמבינה שכדי להצליח צריך לחזק את התשתית התהליכית ולבנות בסיס איתן ממנו אפשר להמשיך ולצמוח.
מה ההעדפה שלכם? לפתח או לפענח? האם נתקלתם בצורך בהנדסה הפוכה? כיצד התמודדתם עם צורך זה? אשמח לדיון ושיתופים באחת הרשתות החברתיות שקישורן להלן.
| מזמינה אותך להצטרף לקבוצת WhatsApp שקטה וחינמית שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
