הטמעה ולמידה ארגונית

איך יודעים אם השינוי לא עבד או פשוט לא יושם

למה כדאי לבדוק את ההטמעה לפני שפוסלים את ההשערה

שני שמשיאן, עובדת סוציאלית ומטפלת, מייסדת ALNA · עודכן ספטמבר 2026

"ניסינו את זה, וזה לא עבד"

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

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

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

שתי שאלות שונות לגמרי

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

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

הספרות המקצועית מציעה: להפריד תמיד בין מדידת נאמנות היישום (implementation fidelity), האם הפעולה קרתה כמתוכנן, לבין מדידת התוצאה עצמה.

מה בודקים לפני שבודקים תוצאה

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

האם מי שאמור לבצע את השינוי בכלל התחיל לעשות אותו?

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

האם זה קרה בתדירות ובאיכות שתוכננו, או רק חלקית ולפעמים?

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

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

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

האם היו חסמים טכניים או תפעוליים שבשקט מנעו את הביצוע?

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

כשמגלים שהבעיה היא הטמעה, לא השערה

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

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

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

ואם השינוי כן יושם ועדיין לא עבד

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

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

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

למה קל כל כך לדלג על השאלה הזאת

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

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

מקורות והמשך קריאה

  • Basch, C.E., Sliepcevich, E.M., Gold, R.S., Duncan, D.F., Kolbe, L.J. (1985). "Avoiding Type III Errors in Health Education Program Evaluations: A Case Study". Health Education Quarterly, מאמר מלא
  • Carroll, C., Patterson, M., Wood, S. et al. (2007). "A conceptual framework for implementation fidelity". Implementation Science, מאמר מלא
  • OBM Network, העמותה המקצועית לניהול ביצועים ארגוני. obmnetwork.com
  • Consolidated Framework for Implementation Research (CFIR), מסגרת מוכרת להערכת יישום התערבויות. cfirguide.org

ניסיתם שינוי שלא הניב תוצאה?

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

קראו גם: למה המלצה טובה עלולה להיכשל בהטמעה · אותה תקיעות, סיבות שונות, פעולות שונות