מסמך אפיון — מערכת ניהול פרויקטים סולאריים, Triple S

גרסה: 1.0 · תאריך: 17 ביוני 2026

לקוח: Triple S — Triples Renewable Energy (סולארי / PV)

ספק: אלעד יעקובוביץ'

סקופ נעול: ₪29,000 · 60 יום · אבני-דרך 20/40/40

יעד אינטגרציה: Priority ERP Release 23.1 (build 19/01/24) על MS-SQL · HTML5 Client 23.1 · Priority Client Plugin

מסמך זה מבוסס על פגישת האפיון מ-17.6.2026, על 19 תשובות אלעד ל-44 שאלות האפיון, ועל חומרי המקור (תבנית "עופר אריאלה", זרימת 21 השלבים של אריאלה, קטלוג סוגי המכירה, אינפוגרפיקת 4 שלבי-העל). נושאים שנותרו פתוחים מצוינים במפורש לאורך המסמך.

1. מטרת המערכת

מערכת לניהול מקצה-לקצה של פרויקטים להתקנת מערכות סולאריות (PV), אגירה, רישוי ועבודות חשמל. המערכת אינה מחליפה את Priority — היא שכבת תהליך/סטטוס/צ'ק-ליסט מעליו, שמטרתה:

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

נקודות הכאב שהמערכת פותרת: המעבר מכירות+רישוי → תכנון+ביצוע, חיבור הלו"ז לתזרים, וריבוי מערכות (SALES / PV / Priority).

2. ארכיטקטורת-על — מנוע תבניות

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

פתיחת פרויקט
   └─ בחירת משפחה (1 מתוך 5 משפחות-העל)
        └─ בחירת סיווג (PV / לא-PV → אם PV: SMART / FULL ...)
             └─ טעינת תבנית: שלבים + שדות + אחראים + תנאי-מעבר  (אוטומטית)
                  └─ הפרויקט "זז בתוך עץ" — בכל רגע רואה רק את ההגדרות הרלוונטיות לשלב שלו

• 5 משפחות-על של פרויקטים, עץ לכל אחת. ענפי העץ נגזרים מקטלוג סוגי המכירה הקיים בפריוריטי (ראו §3). קטגוריות-העל: מערכת ביתית · מסחרית · שדרוג · אגירה · רישוי · עבודות חשמל.
• פרמטרי מול קבוע: השלד (סוג מסך, סוגי סטטוס, מבנה תזרים) קבוע; השלבים/השדות/האחראים פרמטריים לפי סוג המכירה. שינוי סוג המכירה משנה את התבנית.
• פרויקט יכול לשלב כמה תחומים (PV + רישוי + עבודות), או להיות חד-תחומי (למשל רק רישוי, או רק הגדלת חיבור).
• חיווי הקשר רציף: ממשק שמציג למשתמש כל הזמן היכן הוא בעץ ומה ההגדרות הפעילות — ככל שהפרויקט גדל, יש יותר אבני-דרך, וצריך למנוע בלבול.

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

תלות (סוכם 18.6): בניית התבניות מותנית ברשימת פרויקטים ושלבים נקייה ומאושרת. צוות Triple S ימלא את כל הפרויקטים והשלבים — נקיים ומאושרים — עד סוף יוני 2026. הרשימה הזו (יחד עם טפסי המערכת שעופר אסף — ראו §5) היא קלט מחייב לבניית התבניות ולמיפוי השדות.

3. מקורות-אמת ואינטגרציית Priority

כלל ברזל: לכל שדה — מקור-אמת אחד; כל השאר לקריאה בלבד. שני מקורות-אמת לאותו שדה אסורים (סתירות → החלטות על נתון שגוי).

אינטגרציית Priority (REST / OData):

• שלב א' — קריאה: המערכת מושכת נתונים מפריוריטי.
• שלב ב' — כתיבה: הזנת נתונים חזרה דרך המערכת (יצירה/עדכון הזמנה, הפקת ת.מ/חשבונית, שינוי סטטוס, צביעת רכש/תעודות לפרויקט).

סוגי המכירה בפריוריטי (קטלוג קיים): 001 SMART · 002 FULL · 003 הגדלת חיבור · 004 שדרוג · 007 היתר בנייה · 009 רישוי הגדלה · 012 חיבור חדש · 013 רישוי PV · 018 מערכת ביתית · 020 בדיקת התכנות · 021 תכנון · 022 ביתית SMART · 025 משולב אגירה · 027 אגירה · 028 שירות אגירה · 029 הסכם שירות · 031 רישוי אגירה.

אגירה = 3 סוגי אסדרה: 800 שעות · אסדרת שוק · behind-the-meter.

חסם / פתוח: ה-API בתשלום (רישיון + מודול + טרנזקציות שטריפל אס רוכשת). 13 שאלות הועברו לפריוריטי. ההתחייבות לכיסוי מלא של 21 השלבים מותנית בתשובות — בפרט: אילו פעולות זמינות רק מהמסך ולא מה-API, ותמיכה ב-Webhooks מול polling. ראו §12 (סיכונים).

4. תפקידים והרשאות (5 תפקידים)

ההרשאות מוגדרות בתבנית.

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

5. ארבעת המסכים

1. דשבורד — קריאה בלבד. מציג, לא מחזיק נתונים. מרכז משימות, סטטוסים ו"צפי מול ביצוע". קורא מ-3 המסכים האחרים בלבד (כדי שלא ייווצר מקור-אמת שני).
2. משימות. הצ'ק-ליסט היומיומי לכל משתמש — נטען מהתבנית של הפרויקט.
3. פרויקטים. מבט הפרויקט: שלבים, סטטוסים, שדות חובה, מסמכים, נתוני כספים מפריוריטי (קריאה).
4. לו"ז ביצוע. GANT/לו"ז שמזין את צפי התזרים.

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

קלט (סוכם 18.6): עופר אסף/בנה אפליקציה קטנה עם טפסים רלוונטיים רבים לממשק המערכת. הטפסים האלה יועברו לאלעד ויוטמעו בממשק כפי שסוכם — הם קלט ישיר למיפוי השדות ולעיצוב 4 המסכים (במיוחד "משימות" ו"פרויקטים"). לחלופין, הדרך הפשוטה והיעילה ביותר: עופר יכול לשתף את אלעד כ-collaborator ב-repository של האפליקציה שבנה. כך הטפסים והלוגיקה נגישים להטמעה ישירה ומסונכרנת, בלי העברת קבצים ידנית.

6. מודל הסטטוסים, השדות ותנאי-המעבר

סטטוסים (שלב 1): עד 7 למחלקה — פתוח → בעבודה → ממתין לקלט → תקוע → סגור + 2 ייעודיים לתחום.

שדות חובה: 3-5 למחלקה. מסמכים מצורפים: עד 2.

כל סטטוס/שדה נוסף = 1-2 ימי פיתוח + הסכמה + הדרכה → נכנס לשלב 2 לפי שימוש בפועל אחרי 60 יום.

לוגיקת תנאי-המעבר (gates):

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

• תנאי המעבר ממכירות+רישוי לתכנון+ביצוע (חובה בשלב 1): אישור כניסה · הפקת הדמיה · יציאה לסיור טכני ראשוני.
• כל תנאי מעבר יכול להתנהג בשני מצבים:

- חוסם (block): המערכת מונעת מעבר עד שכל הסעיפים שבתנאי המעבר מסומנים.

- מתריע (alert): המערכת מאפשרת מעבר אך מתריעה על סעיף חסר.

פתוח להחלטת צוות: מתי כל תנאי מעבר חוסם ומתי רק מתריע — ייקבע פריט-פריט ברמת הצוות (איתי/אריאלה/עופר). כן: האם 3 תנאי הכניסה הם כל תנאי המעבר או שיש נוספים. תנאי-מעבר נוספים (רישוי→תכנון, ביצוע→שירות) — גם הם בתבנית.

7. זרימת 21 השלבים + כללי הכספים

זרימת אריאלה ("כיום מול רצוי" — רוב השלבים זהים; ההבדל = שיטתיות ואוטומציה, לא שינוי תהליך):

1. הצעת מחיר + סל מוצר
2. פתיחת פרויקט + שם
3. הזמנת לקוח (שלבי תשלום)
4. שינוי סטטוס הזמנה
5. העברה לגבייה / תכנון / מכרוז
6. ת.מ מקדמה
7. חשבונית
8. ת.מ שליחת הדמיה
9. חשבונית
10. מכרוז ציוד לפי תכנון
11. תיווך רכש (כל ציוד SMART מתועד גם אם לא נרכש ע"י Triple S)
12. בחירת קבלן ביצוע
13. עדכון גודל מערכת (בפריוריטי)
14. רכש לפרויקט
15. ת.מ לכל שלב ביצוע + חיוב
16. חשבונית
17. חריגים
18. ת.מ חריגים
19. חשבונית
20. צביעת כל הרכש לפי פרויקט
21. צביעת כל תעודות המשלוח לפי פרויקט

כללי הכספים (לב האפיון — לחישוב רווחיות פרויקט):

הדרבן המרכזי: הודעות אוטומטיות בין מחלקות + צביעה נכונה (רכש ותעודות לפי פרויקט) = הבסיס לחישוב רווחיות אמין.

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

8. תזרים תפעולי (חודשי + רבעוני, צפי-מול-ביצוע)

• תפעולי בלבד בשלב 1: כמה כסף צפוי להיכנס באיזה חודש לפי לו"ז הפרויקטים. רווחיות / גבייה / עמלות = שלב 2.
• רזולוציה: חודשי + רבעוני בו-זמנית. לא יומי, לא שבועי, לא שנתי.
• "צפי מול ביצוע" מופיע כברירת-מחדל בכל מסך ניהול — כעמודה צמודה לצפי, לא כדוח נפרד.

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

9. מיגרציית נתונים

• שלב 1 — מינימום: רק הפרויקטים הפעילים נכון להיום + הלקוחות שלהם.
• ארכיון פרויקטים סגורים = שלב 2 (ייבוא היסטוריה מלאה = חודש עבודה בפני עצמו, ללא תועלת תפעולית מובהקת).
• חלוקת אחריות: ניקוי הנתונים → Triple S · פורמט הייבוא → אלעד.
• תנאי מקדים (סוכם 18.6): צוות Triple S ימלא את כל הפרויקטים והשלבים — נקיים ומאושרים — עד סוף יוני 2026. רשימה נקייה זו היא הבסיס למיגרציה (וגם לבניית התבניות, §2).

10. קריטריוני קבלה לבטא

1. ניתן לפתוח פרויקט, לבחור משפחה + סיווג, והמערכת טוענת אוטומטית את התבנית הנכונה (שלבים/שדות/אחראים/תנאי-מעבר).
2. 4 המסכים פעילים; הדשבורד מציג נתונים מ-3 המסכים בלבד (קריאה בלבד).
3. 5 התפקידים אוכפים את היקף הראייה הנכון.
4. כל שדה נמשך ממקור-האמת היחיד שהוגדר לו; אין שדה כפול.
5. תנאי המעבר ממכירות+רישוי לתכנון+ביצוע אוכף את 3 התנאים, במצב חוסם/מתריע לפי הגדרת התבנית.
6. צפי תזרים תפעולי חודשי + רבעוני מוצג, עם "צפי מול ביצוע" צמוד.
7. כללי הכספים (הכנסות/הוצאות/צביעה) מיושמים נכון בתחשיב רווחיות הפרויקט.
8. אינטגרציית פריוריטי קוראת נתונים בפועל (כתלות בתשובות ה-API).
9. הפרויקטים הפעילים הוגרו ונראים במערכת.

11. תיחום שלב-1 מול שלב-2

שלב 1 (₪29K / 60 יום): מנוע תבניות ל-5 משפחות + עץ · עד 7 סטטוסים/מחלקה, 3-5 שדות, ≤2 מסמכים · 4 מסכים · 5 תפקידים · אינטגרציית קריאה מפריוריטי · צפי תזרים תפעולי חודשי+רבעוני + צפי-מול-ביצוע · הודעות בין-מחלקתיות + צביעת רווחיות · מיגרציית פרויקטים פעילים.

שלב 2 / בקשות שינוי: ארכיון סגורים · צפי פיננסי מלא (רווחיות/גבייה/עמלות) · דוחות מחלקתיים ייעודיים · סטטוסים/שדות נוספים לפי שימוש · מנגנון מלא לאבני-דרך נדחות ותשלומים יוצאים · כל דרישה מיוחדת שאינה חוסמת תפעול ליבה.

כלל ברירת-מחדל: כל דרישה מיוחדת = שלב 2, אלא אם היא חוסמת תפעול ליבה של מחלקה.

12. סיכונים

13. אבני-דרך (20 / 40 / 40 · 60 יום)