המדריך נבדק ביום 30.07.2026 מול רשות המסים, רשות התאגידים, הרשות להגנת הפרטיות, מערך הסייבר הלאומי ונציבות שוויון זכויות לאנשים עם מוגבלות. מוצרים, מחירים, ממשקים והצהרות ספק משתנים במהירות; יש לבדוק מחדש עד 28.10.2026 ולדרוש הדגמה וראיות עדכניות לפני רכישה או חידוש.
התשובה הקצרה
לא מתחילים מרשימת תוכנות. מתחילים ממפת עבודה: מי המשתמשים, איזה מידע נאסף, אילו מסמכים צריך להפיק, אילו אישורים ובקרות נדרשים, ואילו תהליכים אסור שייפלו בין מערכות. רק לאחר מכן בוחרים אם צריך מערכת אחת, כמה מערכות מחוברות או פתרון מצומצם.
מערכת טובה לעמותה אינה זו שיש בה הכי הרבה כפתורים. היא זו שמאפשרת לבצע את העבודה האמיתית בפחות טעויות, מפרידה סמכויות, שומרת נתיב ביקורת, מפיקה נתונים בזמן, מגינה על מידע אישי, עוברת ביקורת וניתנת להחלפה בלי לאבד את ההיסטוריה.
הבחירה מסתיימת רק לאחר ארבעה דברים: תרחישי הדגמה שעבדו על נתוני ניסיון, בדיקת ספק ואבטחה, חוזה שמגן על הנתונים והיציאה, ופיילוט עם בדיקות קבלה. המלצה בקבוצת משתמשים יכולה ללמד מה אנשים מחפשים, אבל אינה ראיה לעמידה בדין, אבטחה או התאמה לעמותה מסוימת.
קודם מגדירים את הבעיה
במשך שבוע עד שבועיים מתעדים את התהליך הקיים בלי לייפות אותו:
- מאין מגיע ליד או פנייה;
- מי פותח תורם, מוטב, ספק, חבר או מתנדב;
- היכן נשמרת הסכמה לדיוור;
- איך תרומה עוברת מסליקה לקבלה, לבנק ולהנהלת חשבונות;
- מי מאשר תשלום ומי מבצע אותו;
- איך נשמרות אסמכתאות;
- מי מבצע התאמות בנק וסליקה;
- איך מתקנים טעות ומי רואה את התיקון;
- איך מפיקים דוח לוועד, לרואה החשבון, לתורם או לרשות;
- מה קורה כשעובד עוזב;
- כמה קבצי אקסל ידניים נוצרים בדרך.
לכל שלב מסמנים בעל תפקיד, קלט, פלט, מערכת, אישור, סיכון וזמן. פעולה שמבוצעת פעמיים בשתי מערכות היא מועמדת לאינטגרציה; פעולה שאין לה בעלים היא בעיית תהליך ולא בעיית תוכנה.
מחליטים מה חייב להיות במערכת
מחלקים דרישות לשלוש רמות:
חובה ביום העלייה
אלו תהליכים שבלעדיהם אי אפשר לעבוד או לעמוד בחובה: ניהול משתמשים והרשאות, מסמכים חשבונאיים, ייבוא יתרות, תיעוד תורמים, ייצוא לרואה החשבון, גיבוי, דוחות ביקורת והמשכיות.
חובה בתוך שלושה חודשים
אוטומציות, חיבור סליקה, טפסים, דיוור, ניהול מתנדבים, מדדים, התאמות מתקדמות וממשקי בנק.
רצוי
לוחות מחוונים יפים, בינה מלאכותית, אפליקציה, חתימה דיגיטלית, פורטל אישי או כל יכולת שלא הוכח שתפתור כאב ממשי.
החלוקה מגינה מפני שתי טעויות: רכישת מערכת כבדה שהצוות אינו מסוגל להטמיע, ובחירת מערכת זולה שאינה עומדת בליבת החובות.
בוחרים ארכיטקטורה, לא רק מוצר
קיימות שלוש אפשרויות סבירות:
- מערכת מרכזית אחת — מתאימה כאשר רוב התהליכים נתמכים היטב, הצוות קטן וחשוב לצמצם חיבורים. היתרון הוא תמונה אחידה; החיסרון הוא תלות בספק ופערים במודולים חלשים.
- מערכות מומחיות מחוברות — למשל הנהלת חשבונות, CRM, סליקה ודיוור. היתרון הוא עומק; החיסרון הוא זהויות כפולות, חיבורים, התאמות ואחריות מפוצלת.
- ליבה קטנה ותהליכים ידניים מבוקרים — מתאימה לעמותה בתחילת דרכה, כאשר מספר הפעולות קטן. ידני אינו בהכרח לא תקין אם יש הרשאות, תיעוד, גיבוי והתאמה; אוטומציה אינה בהכרח בקרה.
אין מערכת ש“מאחדת הכול” רק מפני שהיצרן מציג מסך אחד. צריך לבדוק אם הנתונים אכן נשמרים במקור אחד, אם מודול אחד מעדכן את האחר, מי בעל הרשומה הקובעת, ומה קורה כשהחיבור נכשל. השאלה איזו שיטת הנהלת חשבונות ומערכת מתאימות להיקף העמותה מטופלת בנפרד ב־Q-126; השאלה על תדירות התאמות ובקרה מטופלת ב־Q-128.
דרישות כספיות וחשבונאיות
אם המערכת מפיקה קבלות, חשבוניות, מנהלת מלאי או הנהלת חשבונות, בודקים במרשם רשות המסים את תוקף תעודת הרישום של התוכנה ואת המודולים המכוסים. עצם הופעת תוכנה במרשם אינה אישור שהיא מתאימה לעמותות, מאובטחת, זמינה או מכילה את כל הבקרות; היא בדיקת סף למסמכים ולמערכת החשבונות הממוחשבת.
מכינים תרחישי הדגמה ולא שאלת “האם המערכת יודעת”:
- תרומה בכרטיס, העברה, המחאה דחויה ומטבע חוץ;
- תרומה שבוטלה או הוחזרה;
- תרומה ייעודית לפרויקט;
- דמי חבר ותשלום עבור שירות;
- פיצול תקבול, זיכוי ותיקון;
- תשלום לספק עם מסמך, אישור וניכוי מס;
- קופה קטנה ומקדמה לעובד;
- התאמת בנק, סליקה וקבלה;
- דוח לפי קרן, פרויקט, סניף ומקור מימון;
- סגירת תקופה בלי אפשרות לערוך בדיעבד ללא הרשאה ונתיב ביקורת.
לכל תרחיש הספק צריך להראות מסך, מסמך, רישום, דוח ופעולת תיקון. צילום מסך שיווקי אינו בדיקת קבלה.
תרומות ישראל החל מ־2026
מוסד ציבור בעל אישור סעיף 46 חייב, החל מ־1 בינואר 2026, לדווח על התרומות שקיבל באמצעות מערכת תרומות ישראל. ניתן לדווח ידנית, או באמצעות תוכנת הנהלת חשבונות המחוברת לשירות. לכן עמותה בעלת סעיף 46 צריכה לשאול:
- האם התוכנה מחוברת בפועל למערכת, לא רק “מתוכננת להתחבר”;
- מי מנהל הרשאות מול רשות המסים;
- כיצד נשמר מספר הדיווח;
- מה קורה כשהממשק אינו זמין;
- כיצד מתקנים או מבטלים דיווח;
- איך מונעים קבלה כפולה;
- איך מייצאים רשימת חריגים לבקרה.
אין לבחור תוכנה רק בגלל חיבור זה. אם החיבור נכשל, צריכה להיות דרך לזהות את הכשל ולהשלים את הדיווח בלי לאבד התאמה בין הקבלה, התקבול והדיווח.
תורמים, מוטבים, חברים ומתנדבים
מערכת CRM לעמותה עשויה להחזיק מידע רגיש מאוד: מצב כלכלי, בריאות, משפחה, מוגבלות, תרומות, בקשות סיוע, הערכות מקצועיות ופרטי ילדים. תיקון 13 לחוק הגנת הפרטיות הרחיב והבהיר את הגדרת המידע האישי ואת קטגוריית המידע בעל רגישות מיוחדת. לפני ייבוא שואלים לא רק “האם יש מקום לשדה”, אלא למה צריך אותו, מי יראה אותו, לכמה זמן ישמר ואיך אדם יממש זכויות.
דרישות שימושיות:
- רשומה אחת לאדם עם מנגנון איחוד כפילויות מבוקר;
- הפרדה בין תורם, מוטב, חבר, עובד וספק גם כאשר אותו אדם ממלא כמה תפקידים;
- היסטוריית הסכמות, הסרות ומקור הנתון;
- הרשאות לפי תפקיד, תוכנית ואזור;
- שדות רגישים מוסתרים כברירת מחדל;
- תיעוד גישה ושינוי;
- לוח שמירה ומחיקה;
- טיפול בבקשת עיון או תיקון;
- ייצוא מלא של הרשומה וההיסטוריה;
- הפרדה בין סביבת אמת לסביבת בדיקות.
לא מעתיקים מידע אמיתי להדגמת ספק. יוצרים נתוני דמה שמייצגים את המורכבות בלי לחשוף אדם.
אבטחת מידע ופרטיות
העמותה נשארת אחראית למידע גם כשהוא בענן של ספק. המדריך לתקנות אבטחת מידע מחייב לחשוב על מסמך הגדרות מאגר, סקר סיכונים, הרשאות, תיעוד, אירועים, גיבוי, הצפנה, זיהוי וגישה מרחוק לפי רמת האבטחה והנסיבות.
בדיקת ספק לפני התקשרות
תקנה 15 והנחיית הרשות להגנת הפרטיות דורשות לבחון את סיכוני ההתקשרות, להגדיר את תנאיה ולפקח על הספק. מבקשים תשובות וראיות בנושאים:
- היכן נשמרים הנתונים ובאילו מדינות;
- מי קבלני המשנה ומה תפקידם;
- הצפנה בתעבורה ובאחסון;
- אימות רב־שלבי;
- הפרדת לקוחות;
- גיבוי, שחזור ותרגול;
- ניהול חולשות ועדכונים;
- בדיקות חדירה והיקפן;
- רישום פעולות וניטור;
- תגובה לאירוע וזמן הודעה;
- מחיקת נתונים ועותקי גיבוי בסיום;
- זמינות, יעדי שירות ותמיכה;
- תהליך הצטרפות ועזיבת עובד;
- אפשרות ביקורת וקבלת דוחות.
תעודה או הצהרה של ספק היא ראיה אחת, לא סוף הבדיקה. מערך הסייבר הלאומי מפרסם מתודה ושאלון ספקים שמטרתם להעריך סיכון ולקבוע דרישות ובקרות; במאגר הערכה עצמית אף מודגש שהפרסום מבוסס על הצהרת הספק. מתאימים את עומק הבדיקה לרגישות ולהיקף, ולא מסתפקים בלוגו תקן באתר.
החוזה עם הספק
נספח פרטיות ואבטחה צריך לקבוע:
- מטרות העיבוד והמידע המותר;
- איסור שימוש עצמי, פרסום או אימון מודל ללא אישור ובסיס מתאים;
- עובדים וקבלני משנה מורשים;
- מקום אחסון והעברה מחוץ לישראל;
- בקרות אבטחה מינימליות;
- הודעה מיידית על חשש לאירוע ושיתוף בחקירה;
- סיוע בזכויות נושאי מידע ובדרישות רשות;
- לוגים, פיקוח וביקורת;
- שמירה ומחיקה;
- ייצוא בפורמט שימושי;
- החזרת נתונים וסיום גישה;
- לוחות זמנים, אחריות ושיפוי לפי ייעוץ.
נספח כללי של הספק אינו בהכרח עונה על הפעילות. רושמים מי בעל השליטה במאגר, מי מחזיק או מעבד, ואילו פעולות מותרות לכל צד בהתאם לדין העדכני.
הרשאות והפרדת תפקידים
בונים מטריצת הרשאות לפני הקמת משתמשים:
- מי רשאי לצפות;
- מי ליצור או לשנות;
- מי לאשר;
- מי לבצע;
- מי לבטל;
- מי לייצא;
- מי לנהל משתמשים;
- מי לצפות בלוג;
- מי סוגר תקופה.
אדם שמנהל משתמשים אינו חייב לראות מידע טיפולי. מגייס תרומות אינו צריך לערוך פקודות יומן. מי שמכין תשלום אינו מאשר אותו לבדו. ספק תמיכה מקבל גישה נקודתית, מתועדת ומוגבלת בזמן. חשבון משותף פוגע ביכולת לדעת מי פעל ומקשה לבטל גישה בעזיבה.
בודקים אם המערכת יכולה לאכוף את המטריצה או רק “להציג תפקידים”. בפיילוט מנסים בפועל לעקוף הרשאה, לייצא רשימה, לבטל פעולה ולשנות רשומה סגורה.
נגישות ושימושיות
אם המערכת מספקת שירות לציבור באמצעות אתר או יישומון — טופס תרומה, פורטל מוטבים, הרשמה, תשלום או מידע — בודקים את חובות הנגישות החלות. נציבות השוויון מבהירה ששירות ציבורי באינטרנט עשוי להיות חייב בהתאמות לפי תקנות נגישות השירות.
גם מערכת פנימית צריכה להיות שמישה לצוות מגוון. תרחישי הקבלה כוללים:
- ניווט מקלדת;
- קורא מסך;
- כותרות ותוויות;
- ניגודיות והגדלה;
- הודעות שגיאה ברורות;
- עברית, ימין־לשמאל ותאריכים;
- עבודה במסך קטן;
- ייצוא מסמך נגיש;
- זמן ביצוע של פעולה שכיחה.
אין לקבל תשובה “אנחנו עומדים בתקן” בלי פירוט גרסה, היקף, תאריך בדיקה, חריגים ותוכנית תיקון. אם השירות קריטי, משלבים משתמשים עם מוגבלות בבדיקת הקבלה.
אינטגרציות ונתונים
לכל חיבור מגדירים:
- מערכת מקור;
- מזהה משותף;
- כיוון העדכון;
- תדירות;
- בעלים עסקי וטכני;
- שגיאות צפויות;
- התראה;
- תיקון והרצה חוזרת;
- התאמה תקופתית.
חיבור שעובד בשקט עלול גם להיכשל בשקט. לכן מבקשים דוח חריגים ומדד של רשומות שנשלחו, התקבלו, נדחו וממתינות. אין למחוק נתוני מקור מיד לאחר סנכרון.
בייבוא ראשוני עובדים בשלבים: מיפוי שדות, ניקוי כפילויות, נתוני ניסיון, בדיקת ספירות וסכומים, חתימת בעל הנתונים, ורק אז ייבוא מלא. שומרים עותק מקור קפוא ויומן המרה.
בעלות על הנתונים ויכולת יציאה
לפני רכישה מבצעים “תרגיל פרידה”:
- מבקשים ייצוא מלא מנתוני הדגמה.
- בודקים שהוא כולל קבצים, הערות, קשרים, מזהים, סטטוסים, הסכמות, לוגים ומסמכים — לא רק רשימת אנשי קשר.
- פותחים את הקבצים בכלי אחר.
- מודדים כמה עבודה נדרשת לשחזר את ההקשרים.
- בודקים מחיר וזמן לייצוא בסיום.
- דורשים אישור מחיקה, לרבות אצל קבלני משנה ועותקים לפי מדיניות הגיבוי.
חוזה צריך לקבוע שהנתונים שייכים לעמותה, באיזה פורמט יימסרו, תוך כמה זמן, מה קורה בזמן מחלוקת תשלום וכמה זמן תינתן גישה לקריאה לאחר הודעת סיום. “אפשר לייצא CSV” אינו מספיק אם המסמכים והקשרים נשארים נעולים.
זמינות, גיבוי והמשכיות
הספק מתבקש להציג יעדי זמינות, גיבוי, נקודת שחזור וזמן התאוששות. העמותה מחליטה מה היא באמת צריכה:
- כמה שעות יכולה לעבוד בלי המערכת;
- כמה נתונים מותר לאבד;
- אילו פעולות חייבות להימשך ידנית;
- מי מודיע לצוות ולציבור;
- איך משלימים פעולות לאחר החזרה.
לא מסתפקים באמירה “יש גיבוי”. מבקשים מועד תרגיל שחזור אחרון, תוצאתו והיקף הנתונים שנבדקו. הנחיות מערך הדיגיטל הלאומי למעבר מערכת לתחזוקה מדגישות יעדי זמינות, התאוששות, אובדן נתונים וניסוי שחזור; אלו עקרונות שימושיים גם לעמותה, אף שהמסמך נכתב למערכות ממשלתיות.
השוואת ספקים
מעניקים משקל לפני קבלת הצעות, למשל:
- התאמה לתהליכי חובה — 30%;
- כספים, ביקורת וציות — 20%;
- אבטחה, פרטיות והמשכיות — 20%;
- שימושיות, עברית ונגישות — 10%;
- נתונים, אינטגרציות ויציאה — 10%;
- עלות כוללת ושירות — 10%.
המשקלים הם דוגמה, לא כלל. עמותה טיפולית תיתן משקל גבוה יותר לפרטיות; עמותה עם אלפי תרומות תיתן משקל גבוה להתאמות ולממשק רשות המסים.
כל ספק מקבל אותם תרחישים ואותו שאלון. מציינים בנפרד:
- נתמך כיום;
- נתמך באמצעות הגדרה;
- דורש פיתוח;
- מתוכנן בעתיד;
- אינו נתמך.
יכולת עתידית מקבלת אפס עד שהיא מופיעה בהתחייבות חוזית עם מועד ובדיקת קבלה. מבקשים שני ממליצים דומים בגודל ובפעילות ושואלים אותם על תקלות, תמיכה, ייצוא, עדכוני מחיר ואירוע אבטחה — לא רק אם הם “מרוצים”.
העלות הכוללת
מחשבים שלוש שנים לפחות:
- רישיונות ומשתמשים;
- הקמה והגדרות;
- ניקוי והסבת נתונים;
- פיתוח וחיבורים;
- סליקה והודעות;
- אחסון וגיבוי;
- תמיכה והדרכה;
- בדיקות אבטחה ונגישות;
- תחזוקה ושינויים;
- ייצוא וסיום;
- זמן עבודה פנימי.
מחיר נמוך למשתמש יכול להפוך יקר כאשר צריך פיתוח לכל דוח. מחיר גבוה אינו הוכחה להתאמה. מתקצבים גם מנהל פרויקט מטעם העמותה; הטמעה ללא בעלים פנימי כמעט תמיד הופכת את הספק לבעל התהליך.
פיילוט ובדיקות קבלה
הפיילוט משתמש בנתוני דמה ומכסה יום עבודה, חודש וסוף שנה:
- פתיחת רשומה;
- תרומה וקבלה;
- ביטול ותיקון;
- תשלום ואישור;
- ייבוא בנק או סליקה;
- התאמה;
- דוח לפרויקט ולוועד;
- ייצוא לרואה החשבון;
- שינוי הרשאה;
- עזיבת עובד;
- גיבוי וייצוא;
- כשל חיבור.
לכל בדיקה יש תוצאה צפויה, ראיה, אחראי וסטטוס. פער קריטי אינו “יסודר אחרי העלייה” בלי פתרון זמני מאושר ומועד חוזי.
מעבר לייצור
מעלים בגלים:
- מקפיאים שינויי נתונים במערכת הישנה לזמן מוגדר.
- מגבים ומייצאים.
- מסבים ומאמתים ספירות, סכומים ומדגמים.
- פותחים משתמשים לפי מטריצה.
- מדריכים לפי תפקיד.
- מפעילים תמיכה מוגברת.
- משאירים מערכת ישנה לקריאה לתקופה מוסכמת.
- מבצעים בדיקת 30, 60 ו־90 יום.
לא מוחקים מקור עד שהוועד או בעל התהליך קיבל דוח התאמה והחוזה מאפשר זאת. חריגים מנוהלים ברשימה אחת עם בעלים ומועד.
ממשל שוטף
אחת לרבעון בודקים:
- משתמשים והרשאות;
- חשבונות לא פעילים;
- ייצוא חריג;
- תקלות ואירועים;
- התאמות שלא הושלמו;
- גיבויים ושחזורים;
- קבלני משנה חדשים;
- עדכוני מוצר וחוזה;
- בקשות פרטיות;
- ביצועי תמיכה;
- שימוש בפועל לעומת עלות.
אחת לשנה הוועד מקבל תמונת סיכון ועלות ומחליט אם להמשיך, לשנות או לצאת. ספק קבוע אינו פטור מבקרה תקופתית.
סימני אזהרה
- הספק מסרב להציג ייצוא לפני חתימה;
- אין אימות רב־שלבי או לוג פעולות;
- כל העובדים מקבלים הרשאת מנהל;
- אין תשובה היכן הנתונים נשמרים;
- “תואם חוק” ללא מסמך וראיות;
- חיבור עתידי מוצג כיכולת קיימת;
- סביבת הדגמה כוללת מידע של לקוח אמיתי;
- הספק אינו מתחייב להודיע על אירוע;
- המחיר אינו כולל הסבה, תמיכה או יציאה;
- אין אפשרות לבצע תיקון בלי למחוק היסטוריה;
- לא ניתן להפריד בין מידע טיפולי לכספי;
- אין דרך לבדוק כשל סנכרון;
- תעודת רישום תוכנה אינה בתוקף או אינה מכסה את המודול;
- פורטל ציבורי אינו נבדק לנגישות.
תיק החלטה לוועד
לפני חתימה שומרים:
- מסמך צרכים ותרחישים;
- מטריצת דרישות ומשקלים;
- שלוש הצעות או הסבר מנומק לחלופה;
- שאלון ספק וראיות;
- ניתוח פרטיות ואבטחה;
- תוצאות פיילוט;
- עלות כוללת;
- סיכוני תלות ויציאה;
- חוזה ונספחים;
- המלצת צוות והחלטת ועד;
- תוכנית הטמעה ומדדי הצלחה.
החלטה טובה אינה “בחרנו מוצר X”. היא מסבירה מדוע הוא מתאים, אילו פערים נשארו, מי מטפל בהם, מה התקציב ומה יגרום לעצור או להחליף.
מתי צריך איש מקצוע
נדרשת בדיקה פרטנית כאשר המערכת מחזיקה מידע בריאותי או טיפולי, מידע על קטינים, מידע פיננסי בהיקף גדול, עיבוד בחו״ל, בינה מלאכותית, זיהוי ביומטרי, חיבור לחשבונות בנק, פורטל ציבורי מרכזי, פיתוח מותאם או הסבה ממערכת שאין ממנה ייצוא תקין. בהתאם לסיכון משלבים רואה חשבון, יועץ פרטיות, אבטחת מידע, נגישות, משפט וטכנולוגיה.
המדריך אינו ממליץ על מוצר מסוים ואינו מבטיח שמערכת הרשומה ברשות המסים או ספק המופיע במאגר כלשהו מתאים לעמותה. הבחירה צריכה להישען על התהליך, הראיות, החוזה ובדיקות הקבלה של העמותה עצמה.