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

מסמך אפיון לדוגמה: תבנית מלאה לאפיון מערכת או אפליקציה

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

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

לפני התבנית: בשביל מה המסמך הזה

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

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

הדוגמה שתלווה אותנו היא בדויה: חברת שירות למזגנים עם מוקד של 12 נציגים, 2 סדרנים ו-40 טכנאי שטח. היום הכול רץ על אקסל, טלפונים וקבוצות WhatsApp. החברה רוצה CRM שמנהל כל קריאת שירות, מהשיחה הראשונה ועד החשבונית.

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

התבנית, סעיף אחר סעיף

1. מטרה ומדדי הצלחה

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

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

מדדהיוםיעדמתי מודדים
קריאות שנסגרות בביקור הראשון68%80%חצי שנה אחרי ההשקה
זמן מפתיחת קריאה ועד שיבוץ טכנאי4 שעות בממוצעשעה3 חודשים אחרי ההשקה
שיחות ״מתי מגיעים?״ למוקדכ-300 בשבועירידה של 50%3 חודשים אחרי ההשקה

2. משתמשים ותפקידים

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

תפקידכמהמה עושים במערכתמכשיר
נציג מוקד12פותחים קריאות וקובעים מועד עם הלקוחמחשב
סדרן2משבצים טכנאים ומנהלים את לוח היוםמחשב עם מסך גדול
טכנאי שטח40רואים את הביקורים של היום, מתעדים וסוגרים קריאותטלפון Android, לפעמים בלי קליטה
מנהל שירות3עוקבים אחרי חריגות, מאשרים זיכויים וקוראים דוחותמחשב
לקוחאלפיםמקבל SMS, עוקב אחרי הביקור ומבטל אם צריךהטלפון שלו, בלי להתחבר

3. תהליכים מרכזיים

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

התהליך הראשי: קריאת שירות מקצה לקצה

  1. לקוח מתקשר. הנציג מזהה אותו לפי מספר הטלפון, או פותח לקוח חדש.
  2. הנציג פותח קריאה: סוג התקלה, המכשיר, הכתובת ורמת הדחיפות.
  3. המערכת מציעה חלונות זמן לפי אזור וזמינות, והנציג קובע מועד עם הלקוח.
  4. הלקוח מקבל SMS עם אישור וקישור למעקב.
  5. הסדרן משבץ טכנאי, או מאשר את השיבוץ שהמערכת הציעה.
  6. הטכנאי מסמן ״בדרך״, והלקוח מקבל עדכון עם זמן הגעה משוער.
  7. הטכנאי מתעד את התיקון, את החלקים ואת התמונות, מחתים את הלקוח וסוגר את הקריאה.
  8. המערכת מפיקה חשבונית ושולחת אותה ללקוח.

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

4. רשימת מסכים

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

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

5. כללים עסקיים

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

מס׳כללדוגמה
1לקוח עם חוזה שירות בתוקף לא משלם דמי ביקור. חלקים מחויבים לפי המחירון שבחוזההחוזה בתוקף עד 31.12 והביקור ב-15.12: דמי הביקור 0 ש״ח
2ביקור חוזר על אותה תקלה תוך 30 יום לא מחויב, ומסומן בדוח האיכות כ״חזרה״המזגן תוקן ב-1.6 ונשבר שוב ב-20.6: הביקור בחינם
3אי אפשר לסגור קריאה בלי תמונה אחת לפחות וחתימת לקוח, או סיבה מתועדת להיעדרןהלקוח סירב לחתום: הטכנאי בוחר סיבה מרשימה סגורה
4זיכוי מעל 500 ש״ח דורש אישור של מנהל שירותזיכוי של 350 ש״ח: הנציג מאשר לבד
5קריאה דחופה (אין קירור, ובבית יש תינוק, קשיש או חולה) משובצת באותו יום, גם אם הטכנאי כבר מלאקריאה ב-10:00 בבוקר מקבלת ביקור עד סוף היום
Background

יש לכם מסמך אפיון שצריך עין נוספת?

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

6. מטריצת הרשאות

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

פעולהנציגסדרןטכנאימנהל שירותלקוח
פתיחת קריאהכןכןלאכןלא
צפייה בפרטי לקוחכןכןרק בביקורים של היוםכןרק בפרטים שלו
שינוי שיבוץלאכןלאכןלא
סגירת קריאהלאלארק קריאות שלוכןלא
אישור זיכוי מעל 500 ש״חלאלאלאכןלא
ייצוא רשימת לקוחותלאלאלאכן, ונרשם ב-Audit Logלא
ביטול ביקורכןכןלאכןרק שלו, עד 3 שעות לפני המועד

7. נתונים ואינטגרציות

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

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

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

8. דרישות לא פונקציונליות

נבדק לאחרונה: ספטמבר 2026. המידע כללי ואינו ייעוץ משפטי.

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

תחוםהדרישה בדוגמה
ביצועיםחיפוש לקוח לפי טלפון מחזיר תוצאה תוך שנייה, כש-60 משתמשים עובדים במקביל
זמינות99.5% בשעות הפעילות (07:00 עד 22:00). אפליקציית הטכנאי ממשיכה לעבוד בלי קליטה ומסנכרנת כשהקליטה חוזרת
אבטחהכניסת עובדים עם אימות דו-שלבי, הצפנה בתעבורה ובאחסון, ותיעוד מלא של כל צפייה וייצוא (Audit Log)
פרטיותאילו נתונים אישיים נשמרים ולמה, מי ניגש אליהם, ואחרי כמה שנים מוחקים לקוח שלא חזר
נגישותעמוד המעקב ללקוח עומד בת״י 5568. גם מסכי העובדים נבנים לפי אותה רמה
שפה ותצוגהעברית מימין לשמאל, מספרי טלפון ישראליים ותאריכים בפורמט יום.חודש.שנה

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

נגישות. ת״י 5568 מבוסס על הנחיות WCAG 2.0 ברמה AA, ותקנות שוויון זכויות לאנשים עם מוגבלות (התאמות נגישות לשירות) מחייבות אותו באתרים שנותנים שירות לציבור. בדוגמה שלנו, עמוד המעקב ללקוח הוא שירות כזה. כתבו באפיון את רמת התקן, את המסכים שבהיקף, מי בודק ומתי, ומי כותב את הצהרת הנגישות. נגישות שנזכרים בה רק לפני ההשקה מחייבת לפתוח מחדש מסכים שכבר נבנו.

9. אנליטיקה ומדידה

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

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

10. מחוץ להיקף

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

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

11. שאלות פתוחות

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

שאלהמי עונהעד מתיעל מה היא משפיעה
הטכנאים עובדים עם טלפון של החברה או עם טלפון פרטי?מנהל התפעוללפני תחילת הפיתוחאבטחה וניהול מכשירים
למערכת הנהלת החשבונות יש API?סמנכ״ל הכספיםשבוע 1היקף האינטגרציה
כמה שנים של היסטוריה עוברות מהאקסל?מנהל השירותשבוע 2היקף הסבת הנתונים
לקוחות עסקיים צריכים אזור אישי משלהם?המנכ״ללפני גרסה 2היקף גרסה 2

מה סוגרים מראש, ומה מחליטים מול גרסה עובדת

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

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

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

שאלות נפוצות

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

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

כמה עולה אפיון מערכת? שלב אפיון אצלנו מתחיל ב-15,000 ש״ח ויכול להגיע ל-45,000 ש״ח, לפי היקף המערכת. מה מקבלים בו ומתי אפשר לוותר עליו, פירטנו במדריך לשלב האפיון.

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

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

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

[ צרו קשר ]

ספרו לנו מה אתם בונים.

יותר מ-250 ארגונים סומכים עלינו. נחזור אליכם תוך יום עסקים אחד.

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

קבעו שיחת היכרות ←