- קבל קישור
- X
- אימייל
- אפליקציות אחרות
אני זוכרת את הפעם הראשונה שכתבנו את נוהל הפיתוח. זה היה בתחילת הדרך. היינו חברה קטנה, היה לנו מוצר ראשון בפיתוח מתקדם, ומבדק ההסמכה הראשון כבר נראה באופק. ישבנו בחדר ישיבות קטן עם לפטופים פתוחים וקפה שהתקרר מהר מדי, וניסינו להחליט איך אנחנו רוצים שהתהליך ייראה. לא איך הוא "אמור" להיראות לפי הספר, אלא איך הוא יעבוד אצלנו באמת.
כתבנו נוהל פשוט וברור. כזה שאפשר להסביר בשיחה אחת. היה בו היגיון פנימי והוא שיקף את המציאות הארגונית: מי יוזם, מי בודק, מי מאשר, ואיפה זה מתועד.
הוא לא היה מושלם, אבל הוא היה שלנו והוא עבד בשבילנו.
במבדק הפנימי הראשון הבאנו יועצת חיצונית והיא העלתה הערה קטנה. משהו לא היה מוגדר מספיק ברור. לא דרמה. פתחנו CAPA לפי הנוהל הפנימי שלנו, הוספנו את ההבהרות הרלוונטיות לנוהל, והמשכנו הלאה.
כמה חודשים אחר כך הגיע מבדק חיצוני. כאן כבר נכנסו לעומק. הסוקר שאל שאלות טובות. הוא רצה לראות עקביות, רצה להבין איך אנחנו מדגימים שליטה, איך אנחנו מראים עקיבות בין דרישות לביצוע. שוב מצאנו את עצמנו מעדכנים את אותו נוהל. הוספנו טבלה, חידדנו אחריות, הכנסנו התייחסות מפורשת יותר לסיכונים. על פניו, שום דבר לא הרגיש מיותר. להיפך, הכל הרגיש נכון.
ואז הגיעה רגולציה חדשה. פתאום אותן פעילויות קיבלו דגשים אחרים וציפיות אחרות. היינו חייבים להתאים את עצמנו, וכמו תמיד, המקום הטבעי להכניס אליו את השינויים היה הנוהל הקיים.
בכל פעם אמרתי לעצמי: זה רק עדכון. זה רק חידוד. זה רק כדי לוודא שבמבדק הבא לא נשמע שוב את אותה הערה. וכך, בלי שתכננו, הנוהל התחיל להתנפח.
כמה שנים אחרי אותה ישיבה ראשונה, ישבתי עם מנהל פיתוח חדש שנכנס לחברה ועברנו על מערכת האיכות כחלק מתהליך החפיפה שלו. כשהגענו לנוהל המדובר, הוא הסתכל עלי ושאל: "זה באמת מה שקורה בפועל"?
השאלה הזאת עצרה אותי, כי התשובה הייתה מורכבת. כן, זה משקף את כל מה שלמדנו בדרך. כן, כל סעיף שם נולד מסיבה טובה: בין אם ממצא במבדק, CAPA, או שינוי רגולטורי. אבל האם עצרנו אי פעם להסתכל על התמונה הכוללת או שרק הוספנו נדבך על נדבך?
היום אני יכולה לומר שזאת תופעה שאני רואה הרבה בארגונים. במקום לעצור ולתכנן מחדש, אנחנו מעדיפים לתקן נקודתית. זה טבעי וזה מהיר יותר. זה מאפשר לסגור את ה-CAPA ולהמשיך הלאה. אבל עם הזמן, התיקונים הנקודתיים הופכים לארכיטקטורה שלמה, שלא בטוח שמישהו באמת תכנן.
המורכבות הזאת מתחילה לחלחל לארגון. פתאום צריך יותר זמן להסביר תהליך. יש יותר חריגים, יותר מקרים גבוליים, יותר שאלות של "אבל מה קורה אם…". לפעמים מוצאים את עצמנו מפנים אנשים לסעיף 4.3.7 שמפנה לנספח ג’ שמפנה לטופס אחר. הכול מתועד והכל מכוסה, אבל התחושה כבר פחות נוחה והמסמך ארוך...
האירוניה היא שברוב המקרים, הכוונה המקורית הייתה לייצר שליטה ובהירות. אף אחד לא רצה לבנות מערכת מסורבלת. להיפך, רצינו להראות לסוקר שאנחנו שולטים בתהליך. רצינו להגן על החברה מפני טעויות חוזרות ולהיות "בשלים יותר".
השאלה שאני שואלת היום, כשאני מלווה חברות בתהליכי צמיחה או לקראת מבדקים משמעותיים, היא לא "מה חסר בנוהל", אלא "האם הנוהל עדיין מספר סיפור קוהרנטי".
נוהל טוב הוא תיאור של דרך העבודה. כשקוראים אותו מהתחלה ועד הסוף, צריך להבין איך הדברים זורמים. איפה הם מתחילים ואיפה הם מסתיימים. מי מחזיק באחריות בכל שלב. אם כל עדכון נוסף שובר קצת את הזרימה הזו, בסוף מתקבלת מערכת שמרגישה מאולצת. והיא גם מסובכת.
יש חברות שעושות צעד אמיץ אחת לכמה שנים: הן עוצרות וכותבות את הנוהל מחדש. לא מוחקות את מה שלמדו, אלא מארגנות אותו מחדש בצורה נקייה. לוקחות את כל התוספות, הדרישות, ההערות מהמבדקים, ובונות אותן במבנה מסודר והגיוני שמשרת את הארגון הנוכחי ולא את זה שהיה לפני חמש שנים.
זה דורש זמן וחשיבה. לפעמים זה גם דורש להודות שחלק מהתוספות כבר לא באמת רלוונטיות. אבל התוצאה שווה את זה. כי אז הנוהל חוזר להיות כלי עבודה, ולא אוסף של תגובות היסטוריות לאירועים.
הרגולציה תמשיך להשתנות, בזה אתם יכולים להיות בטוחים. גם המבדקים לא ייעלמו ופעולות מתקנות תמיד יהיו חלק מהחיים שלנו. זו המציאות של עולם המדיקל. השאלה היא איך אנחנו מנהלים את ההצטברות. האם אנחנו מאפשרים לה להכתיב את המבנה, או שאנחנו בוחרים מדי פעם לעצור, להסתכל על כל הבניין, ולשאול אם הוא עדיין עומד בצורה שאנחנו גאים בה.
בסוף, מערכת איכות בוגרת לא נמדדת רק ביכולת שלה להגיב לממצאים, אלא גם ביכולת שלה לשמור על פשטות יחסית בתוך מורכבות רגולטורית. זו עבודה מתמשכת וזה לגמרי אפשרי.
ואם תוך כדי קריאה אתם מזהים נוהל אחד אצלכם שעבר יותר מדי "שיפוצים" - אולי זו הזדמנות טובה לפתוח אותו לא כדי להוסיף עוד סעיף, אלא כדי לחשוב מחדש על כל הסיפור שהוא מספר.
תגובות
הוסף רשומת תגובה