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

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

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

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

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

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

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

ההבחנה המרכזית

הוצאת חובה - משהו שה-Notified Body או הרשות בודקים ישירות כתנאי לתעודה, או שנדרש בטקסט הרגולציה עצמה (MDR, ISO 13485, ISO 14971) בלי אלטרנטיבה. בלי זה, אין הגשה, ואין מבדק שלב 2.

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

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

הכלל המעשי לבדיקת כל סעיף תקציב:

"אם הסעיף הזה לא קיים ביום המבדק - האם הסוקר יכול לסגור את זה כאי-התאמה שחוסמת תעודה?"

תשובה חיובית מסמנת הוצאת חובה.

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

מה חייבים לתקצב לפני הסמכה

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

• ניהול סיכונים לפי ISO 14971. קובץ סיכונים מלא — תהליך מתועד מהזיהוי ועד האימות שאמצעי ההפחתה עובדים בפועל (לא טבלה חד-פעמית של ניהול סיכונים). קובץ סיכונים רדוד הוא אחת הסיבות הנפוצות ביותר לאי-התאמות משמעותיות בשלב 2.

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

• אימות ותיקוף (Verification & Validation). בדיקות מעבדה, בדיקות ביצועים, ואם רלוונטי תיקוף תוכנה לפי IEC 62304. סעיף שקל לזלזל בו בתכנון מוקדם כי הוא נראה "טכני" ולא "רגולטורי", אבל בלי ראיות אימות ותיקוף מתועדות אין תיק טכני שלם.

• הנדסת שימושיות / גורם אנושי. קובץ Usability Engineering לפי IEC 62366-1, כולל בדיקות פורמטיביות ותיקוף סאמטיבי, נדרש כחלק מהתיק הטכני לכל מוצר, לא רק למוצרים מורכבים במיוחד.

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

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

• אגרות Notified Body (שלב 1+2). כולל בדיקת התיק הטכני. סעיף שברור מראש בעלות, אבל חברות רבות שוכחות לתקצב את סבב ההבהרות שכמעט תמיד מגיע אחרי שלב 1 — עבודה נוספת פנימית או עם יועץ, לפני שמגיעים לסבב 2 בכלל.

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

• נציג מורשה באיחוד האירופי (EU Authorized Representative). חובה לכל יצרן שאינו רשום בתוך האיחוד האירופי לפני שיווק מוצר כלשהו בשוק האירופי ורלוונטי לרוב היצרנים הישראליים. עלות שנתית קבועה, לא חד-פעמית.

• ביטוח אחריות מוצר / כיסוי פיננסי. MDR סעיף 10(16) מחייב כיסוי פיננסי פרופורציונלי לסיווג הסיכון של המוצר.הנציגים המורשים דורשים הוכחה לכך כתנאי לעבודה משותפת.

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

סעיפי חובה מותנית — תלוי בסוג המוצר

• תשתית סייבר בסיסית (IEC 81001-5-1 / דרישות Annex I ב-MDR) — חובה רק אם המוצר הוא SaMD או מכשיר מחובר. מוצר שאינו כזה לא נדרש בסעיף הזה כלל.

• בדיקות ביו-תאימות (ISO 10993) — חובה רק אם המוצר במגע ישיר או עקיף עם הגוף או עם רקמות.

• ליווי חיצוני ל-Person Responsible — רלוונטי רק אם בארגון אין איש צוות שעונה על תנאי הכשירות של MDR סעיף 15. אם יש, זה תפקיד פנימי בלי עלות תקציבית נפרדת, רק זמן ניהולי.

מה אפשר לדחות בלי סיכון

• תוכנת מערכת ניהול איכות ייעודית (eQMS). נוחה, אבל אינה תנאי להסמכה ראשונה. חברה קטנה יכולה לרוץ עם Word, Excel, ובקרת גרסאות (כולל תיקיית "פעיל" מול "ארכיון") ולעבור מבדק בהצלחה. שווה לשקול מעבר לתוכנה כשמספר הנהלים והרשומות גדל מעבר למה שניתן לנהל ידנית בביטחון.

• מחקר PMCF מלא. Post-Market Clinical Follow-up נדרש כתוכנית ביחס לתקופה שאחרי השיווק, לא כתנאי לקבלת התעודה עצמה. תוכנית ה-PMS/PMCF צריכה להיות מוגדרת בתיק, אבל ביצוע המחקר בפועל נדחה לשלב שבו המוצר כבר בשוק.

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

• אינטגרציית UDI מתקדמת (ERP/מחסן). הקצאת UDI ורישום ב-EUDAMED נדרשים כחלק מסעיפי החובה. מה שנדחה הוא אינטגרציה של מערכות UDI לתשתית ה-ERP או המחסן ברמת אוטומציה מלאה. שדרוג שרלוונטי כשההיקף התפעולי מצדיק אותו.

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

• הסמכת ISO 27001. תשתית סייבר בסיסית היא חובה מותנית (ראו למעלה) אם המוצר הוא SaMD או מכשיר מחובר ולא ניתנת לדחייה במקרה כזה. מה שכן אפשר לדחות היא ההסמכה הפורמלית ל-ISO 27001 עצמה, שאינה תנאי להסמכת המוצר.

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

• רישום בשווקים נוספים מעבר לשוק ההשקה (FDA, Health Canada וכו'). כל שוק נוסף מביא תקציב רישום ותיעוד נפרד. לדחות עד שיש החלטה ממשית להתרחב לשוק הזה.

• מנוי לתוכנת מעקב רגולציה (regulatory intelligence). כלי נוח בהיקף גדול, לא נדרש כשעוקבים ידנית אחרי עדכוני MDCG ו-FDA בשלב הראשוני.

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

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

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

איך לבנות את סדר העדיפויות בפועל

1. לרשום את כל סעיפי החובה מלמעלה ולקבל הצעת מחיר ריאלית לכל אחד (לא הערכה גסה) — כולל סבב הבהרות צפוי מול הגוף המסמיך.

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

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

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

אז מה התקציב שלכם ואיך אתם מנהלים אותו?

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