ההבדל בין "קראתי והבנתי" לבין "אני יודע איך לעשות את זה"

 

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

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

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

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

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

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

אז למה זה קורה?

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

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

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

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

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

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

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

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

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

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

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

ובנקודה הזו, כבר הרבה יותר קשה לתקן.