מדוע צבירת קאשבק ב-Bitrix נשברת תחת עומס
צבירת קאשבק ב-Bitrix כמעט תמיד נשברת לא בלוגיקה של הכללים, אלא ברגע שבו ההזמנה משנה סטטוס. כל עוד ההזמנות נספרות בעשרות ביום, המכניקה מחזיקה מעמד בזכות בדיקות ידניות ו"עיניים" של המנהל.
ברגע שהזרימה גדלה וההזמנות מתחילות להיסגר במקביל, צפים שלושה כשלים טיפוסיים: חוסר סנכרון בין הזמנות לנקודות, צבירה כפולה וטרנזקציות תקועות.
הנפוץ ביותר — חוסר סנכרון. אירוע החלפת הסטטוס מעובד בתהליך אחד, בעוד שכתיבת היתרה באזור האישי מתבצעת בתהליך אחר, וביניהם אין טרנזקציה משותפת. אם בפרק הזמן הזה המטפל נופל או שהאירוע חוזר ממערכת חיצונית, ההזמנה כבר סגורה, והנקודות או שלא נצברו, או שנצברו פעמיים.
הכשל השני — צבירה כפולה בקריאה חוזרת: ריטריי ממודול התשלום, תיקון ידני של הסטטוס על ידי המנהל או סנכרון חוזר עם 1С מפעילים את הכלל בפעם השנייה, כי אין מפתח אידמפוטנטי לפי הזמנה.
השלישי — טרנזקציות תקועות בהזמנות מקבילות. שתי הזמנות של אותו משתמש מעובדות בו-זמנית, שתיהן קוראות את אותה יתרת נקודות, שתיהן כותבות מעל — חלק מהצבירות הולך לאיבוד, והיתרה באזור האישי סוטה מהנתונים במערכת החשבונאית. השגיאה אינה משוחזרת בסביבת בדיקות עם הזמנה אחת, וצפה רק אצל לקוחות אמיתיים.
מפרקים כיצד זה נסגר: נעילות ברמת ההזמנה, מפתחות אידמפוטנטיים, תור נפרד לצבירה והתאמת נקודות מול הזמנות לפי לוח זמנים.
מה נותנת מכניקת קאשבק תקינה
צבירת קאשבק שתוכננה כראוי ב-Bitrix אינה "חלון בונוסים", אלא קו חישוב המשולב בביצוע ההזמנה. כאשר הכללים (קטגוריות מוצרים, צבירה דו-שלבית, חריגים) מתוארים באופן דקלרטיבי ומחושבים בצד השרת, הקונה רואה את ההטבה הסופית ישירות בסל ואינו ממתין לחישוב מחדש לאחר התשלום.
הדבר משפיע ישירות על מהירות ביצוע ההזמנה: לא נוצרים שלבים מיותרים, אישורים ו"נבהיר מאוחר יותר", ולכן יש פחות סלים נטושים במסך האחרון.
האפקט השני — שיעור הרכישות החוזרות. נקודות שנצברות באופן צפוי ומנוצלות ללא הפתעות פועלות כמנגנון החזרה: הלקוח חוזר כי הוא בטוח ביתרה. אם לעומת זאת הצבירה "מהבהבת" — פעם עובדת, פעם לא — האמון בתוכנית יורד מהר יותר מאשר גדל בסיס המשתתפים, והזמנות חוזרות לא מופיעות.
נושא נפרד — תיקונים ידניים של היתרה. כל התערבות ידנית באזור האישי משמעה שמשהו לא עבד בכלל: קטגוריה לא נלקחה בחשבון, חריג לא פעל, הנתונים בין ההזמנה לחשבונית לא תאמו.
אנו בונים את המכניקה כך שמצבים שנויים במחלוקת ייסגרו על ידי לוגיקה ולא על ידי מפעיל: תנועות אידמפוטנטיות, עיבוד חוזר של הזמנה אינו מכפיל נקודות, ביטול והחזרה מבטלים את הצבירה כראוי. כתוצאה מכך התמיכה מפסיקה להיות "הנהלת חשבונות של נקודות".
יציבות הצבירה היא גם צפיות תחת עומס. במבצעי מכירות בשיא, החישוב לא אמור להתחרות על אותם נתונים עם ביצוע ההזמנה: הפעולות מופרדות לשלבים, חישובים מחדש כבדים עוברים לעיבוד ברקע, ומצב היתרה נשאר עקבי. אז המכניקה שורדת פרץ הזמנות ללא אי-התאמות, והצוות — ללא בדיקות לילה.
קטגוריות מוצרים וכללי חישוב קאשבק
כללי חישוב הקאשבק ב-1C-Bitrix בנויים כמערכת תנאים שמוחלים על סל הקניות ברגע ביצוע ההזמנה. ההיגיון הבסיסי — קישור קטגוריית המוצר לאחוז החישוב: הקטגוריה מוגדרת דרך קישור למדורי הקטלוג או למאפייני המוצר, והאחוז נשמר בישות נפרדת, כדי לאפשר שינוי שלו בלי לערוך קוד.
כאשר הלקוח מבצע הזמנה, המערכת עוברת על הפריטים, מזהה את הקטגוריה של כל אחד ומחשבת קאשבק לפי הכלל המתאים.
נקודת המפתח — עדיפות הכללים. אם מוצר נופל בבת אחת תחת כמה תנאים (למשל, הוא נמצא בקטגוריית מבצע ובמקביל משתתף בתוכנית נאמנות כללית), בלי סדר הפעלה מפורש נוצר קונפליקט: החישוב עלול להיכפל או להחיל אחוז לא נכון.
לכן כל כלל מקבל משקל, והמערכת לוקחת את הראשון המתאים לפי סדר עדיפות יורד, ואת השאר עבור אותו פריט היא מתעלמת. זה נותן תוצאה צפויה מראש: הנהלת החשבונות והלקוח רואים את אותה סכום.
חריגים של מוצרים נפתרים במנגנון נפרד — רשימת מק"טים או מאפיין "לא משתתף בקאשבק". החריג נבדק לפני הקטגוריות, ולכן מוצר-חריג לא יקבל חישוב, גם אם פורמלית הוא נופל לקטגוריה עם אחוז.
כך מוסר הקונפליקט בין המבצעים לתוכנית הכללית: פריטי מתנה, מוצרים עם הנחה קבועה או פריטים תחת מגבלה לא שוברים את החישוב.
בנפרד מוגדרת ההתנהגות בעת החזרה חלקית וביטול — הכלל חייב לחשב מחדש את החישוב כראוי, ולא להשאיר קאשבק "תקוע". כל זה מוגדר בלוח הניהול בלי שינוי בליבה, ולכן ניתן לשנות את הכללים בהתאם למשימות שיווקיות, בלי להסתכן בעדכוני הפלטפורמה.
זיכוי דו-שלבי: אישור וזיכוי
זיכוי דו-שלבי מפריד בין רגע ביצוע ההזמנה לרגע האישור: בעת יצירת ההזמנה הנקודות אינן נזקפות לחשבון הלקוח, אלא נכנסות לרזרבה. זה מהותי, מכיוון שההזמנה עשויה להתבטל, התשלום לא לעבור, וחלק מהפריטים — לחזור.
אם לזכות את הקאשבק מיד, הקונה מספיק להוציא את הנקודות לפני שההזמנה אושרה, ובמקרה של ביטול היתרה נכנסת למינוס. רזרבת נקודות פותרת זאת: הסכום שמור ברזרבה, גלוי ללקוח כ"ממתין לאישור", אך אינו משתתף בתשלום הזמנות חדשות.
הזיכוי לאחר התשלום מופעל על ידי שינוי סטטוס ההזמנה. כאשר התשלום מאושר, המטפל מחשב מחדש את הקאשבק לפי הפריטים ששולמו בפועל — תוך התחשבות בהנחות שהוחלו, בקופונים ובכללי הקטגוריות.
בדיוק בשלב זה הנקודות עוברות מהרזרבה ליתרה הזמינה, ובהיסטוריית הפעולות מופיע רשומה עם קישור למספר ההזמנה. סדר זה מגן גם על הלקוח וגם על העסק: הזיכוי תמיד תואם את הכסף שהתקבל בפועל.
תרחיש נפרד — סגירת ההזמנה. אם התשלום עבר, אך ההזמנה בוטלה מאוחר יותר או בוצע החזר, הקאשבק מחושב מחדש בשנית: מה שנזקף מבוטל באופן יחסי לפריטים שהוחזרו. הרזרבה במקרה זה מוסרת ללא זיכוי.
נוח להחזיק את הלוגיקה במטפלי אירועים של שינוי סטטוס, ולא ברגע ביצוע ההזמנה — אז כל שינוי בהזמנה לאחר התשלום מטופל כראוי, ולא מותיר נקודות "תלויות".
עבור הלקוח ההבדל נראה באזור האישי: שני סכומים — נקודות שמורות ברזרבה ונקודות זמינות, עם סטטוס ברור לכל פעולה. זה מסיר את רוב הפניות לתמיכה מסוג "שילמתי, ואין קאשבק": האדם רואה שהזיכוי ממתין לאישור ההזמנה, ולא אבד.
השוואת מצבי צבירת קאשבק
מצב הצבירה קובע באיזה רגע יתרת המשתמש משתנה ואילו אירועים יכולים לבטל אותה. טעות ברמה הזו אינה מתגלה מיד: הנקודות נצברו, ההזמנה בוצעה, וכעבור שבוע מגיע החזר — והיתרה נכנסת למינוס. לכן אין בוחרים את המצב לפי נוחות התצוגה, אלא לפי אילו אירועים בהזמנה נחשבים לבלתי הפיכים.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| מיידי בעת ביצוע ההזמנה | הזמנות פשוטות ללא משלוח ותשלום לאחר מעשה, מוצרים דיגיטליים, שוברי מתנה | החזר או ביטול מחייבים ביטול רישום: אם המשתמש כבר הוציא את הנקודות, היתרה נכנסת למינוס וצריך לסגור אותו ידנית |
| צבירה דו-שלבית | קמעונאות עם משלוח, שבה ההזמנה עוברת כמה סטטוסים | נדרשים טריגרים מפורשים בכל מעבר סטטוס; בשינוי סטטוס ידני על ידי מנהל, הצבירה עלולה שלא לפעול אם המטפל אינו רשום לאירוע הזה |
| צבירה נדחית לפי אירוע | מוצרים עם תקופת החזר ארוכה, שירותים, תשלום לאחר קבלה | המשתמש רואה את הנקודות באיחור — נדרש מונה נפרד של "ממתין לצבירה", אחרת התמיכה מקבלת פניות "איפה הקאשבק" |
צבירה דו-שלבית היא פשרה: מקדמה בנקודות בעת ביצוע ההזמנה והיתרה לאחר סגירת ההזמנה. היא מסירה עומס מהתמיכה, אך מחייבת ששני השלבים יהיו אידמפוטנטיים: קריאה חוזרת של המטפל לא אמורה לצבור נקודות פעמיים.
מצב נדחה נבחר לרוב במקומות שבהם החזר הוא הנורמה ולא היוצא מן הכלל. הנקודות נצברות לפי האירוע "ההזמנה נסגרה" או "תקופת ההחזר חלפה", ועד לרגע הזה הן אינן משתתפות בחישוב ההנחה.
זה מסיר סוג שלם של שגיאות עם יתרה שלילית, אך מוסיף ישות נפרדת — קאשבק נדחה — שצריך להציג באזור האישי ולהביא בחשבון בדוחות.
אפשר לערבב מצבים בחנות אחת, אך הגבולות חייבים להיות מפורשים: קטגוריית המוצר או סוג התשלום קובעים את המצב, ולא לוגיקת ביצוע ההזמנה. אחרת, עם הוספת קטגוריה חדשה, התנהגות הצבירה הופכת לבלתי צפויה.
כיצד אנו מיישמים את מנגנון הקאשבק
את העבודה מתחילים בביקורת: בוחנים כיצד במערכת כבר בנויים ההנחות, תוכניות הבונוסים וההסכמים עם הקונים, היכן מצטלבים תיקונים ידניים של מנהלים וכללים אוטומטיים.
בשלב זה חשוב למצוא קונפליקטים נסתרים — למשל, כאשר קאשבק נצבר על פריט שכבר נמכר בהנחה, או כאשר החזרת מוצר אינה מבטלת את הצבירה. בלי בדיקה כזו, כל לוגיקה חדשה שוברת את החישובים הקיימים.
- ביקורת הלוגיקה הקיימת. מפרקים את סל הקניות, ביצוע ההזמנה, התשלום וההחזרות: היכן מחושבת הסכום, אילו מטפלים כבר מתערבים בו, אילו כללים נמצאים בהגדרות ואילו נוספו בקוד. מתעדים נקודות שבהן ניתן להשתלב בלי לשנות את הליבה.
- סכמת כללים. מתאמים מטריצה: קטגוריות מוצרים ומדורי קטלוג המשתתפים בצבירה, אחוז או סכום קבוע, בסיס החישוב (מחיר לפני או אחרי הנחה), תוקף הבונוסים ותנאי המימוש. כבלוק נפרד — חריגים: פריטים במבצע, מוצרים בהזמנה מיוחדת, שוברי מתנה.
- הגדרת מטפלים. מקשרים את החישוב לאירועים של ביצוע ההזמנה, שינוי סטטוס התשלום וההחזרה. אם המנגנון דו-שלבי — תחילה צוברים באופן מותנה, ואחר כך מאשרים לאחר התשלום או המשלוח, כדי שהבונוסים לא ייצאו על הזמנות שלא שולמו.
- בדיקה על הזמנות בדיקה. מריצים תרחישים: רכישה רגילה, הזמנה בהנחה, החזרה חלקית, ביטול לאחר צבירה, רכישה ממספר הסכמים. משווים את יתרת הקונה לפני ואחרי כל פעולה — פער ולו בפריט אחד משמעו שגיאה בכללים.
- מסירה ותיעוד. מוסרים את סכמת הכללים, תיאור המטפלים והוראות למנהלים: כיצד לשנות אחוז, להוסיף קטגוריות, לטפל בצבירות שנויות במחלוקת. מראים היכן לצפות ביומן הפעולות, כדי שתיקונים לא ידרשו קריאה למפתח.
לאחר המסירה המנגנון חי באופן עצמאי: הכללים משתנים דרך ההגדרות, ולא דרך הקוד. אם יהיה צורך להרחיב את הלוגיקה — למשל, להוסיף רמות נאמנות או מועד תפוגה של בונוסים — המבנה כבר מוכן לכך.
מה הלקוח מקבל לאחר ההטמעה
הטמעת קאשבק היא לא רק קוד, אלא גם סט של נכסים שלפיהם המערכת ממשיכה לפעול לאחר ההשקה. להלן מה שנשאר אצל הלקוח: כללי צבירה, סכימת חריגים, נוהל התאמות ותיעוד. כל סעיף ניתן להעביר למנהל חדש או לקבלן חיצוני בלי לספר אותו מחדש "בעל פה".
- כללי צבירה — מטריצת קטגוריות מוצרים ומדורי קטלוג עם אחוזים, ספים ותנאי התחלת הצבירה. נשמרת בהגדרות המודול ולא בקוד התבנית, ולכן איש השיווק משנה אחוז בלי צורך בשחרור גרסה.
- סכימת חריגים — רשימת מוצרים, מותגים ופריטים במבצע שעליהם הקאשבק אינו חל, עם עדיפות כללים: מה גובר כאשר קטגוריה ומבצע מצטלבים. החריגים מתוארים באופן הצהרתי, והוספת פריט חדש אינה שוברת את החישוב עבור השאר.
- צבירה דו-שלבית — הפרדה בין "נצבר בעת ההזמנה" לבין "זמין לאחר אישור התשלום או סגירת תקופת ההחזרה". הדבר מסיר את הסיכון לתשלום בגין הזמנות שבוטלו והחזרות.
- נוהל התאמות ידניות — סדר הפעולות של המנהל: היכן לראות את יתרת הלקוח, כיצד לבצע צבירה או חיוב, אילו שדות חובה ביומן ומי מאשר את הפעולה. כל הפעולות נרשמות ביומן עם המבצע והסיבה.
- תיעוד — תיאור מבנה אחסון היתרות, נקודות האינטגרציה עם ביצוע ההזמנה ואזור האישי, וכן הוראות לצוות התמיכה לטיפול בפניות אופייניות של לקוחות.
- יומן פעולות ודיווח — ייצוא צבירות וחיובים לפי תקופות, התאמה מול הזמנות, ואיתור אי-התאמות לפני שהלקוח מבחין בהן.
- נוהל שינוי כללים — כיצד לשנות אחוזים וקטגוריות באופן בטוח באתר פעיל: מה חל על הזמנות חדשות ומה מחושב מחדש עבור הזמנות קודמות.
סט כזה מסיר את התלות במפתח מסוים: לוגיקת הצבירה מתוארת, החריגים מפורמלים, והפעולות הידניות מוסדרות בנוהל. תארו את סכימת הנאמנות שלכם — נחזור עם הערכה ותוכנית הטמעה.
מקרה בוחן: כיצד מנענו חיובי כפילות של קאשבק
הלקוח — רשת חנויות קמעונאיות עם תוכנית נאמנות ב-1C-Bitrix: הקאשבק נצבר בשני מקומות — בעת ביצוע ההזמנה ובאמצעות סוכן נפרד לפי עובדת המשלוח. בעת ניתוק הקשר עם שער התשלומים או שליחה חוזרת של הטופס, ההזמנה נוצרה פעמיים, והבונוסים נזקפו לכרטיס הלקוח בשתי עסקאות. שיעור החיובים השגויים הגיע עד 6% מהנפח החודשי, ובדיקת כל מקרה נפלה על כתפי התמיכה.
מה היה לפני
הבעיה לא הופיעה באופן קבוע, אלא בגלים — במבצעים ובימי עומס מוגבר, כאשר תור הסוכנים פיגר אחרי זרימת ההזמנות. הקונים ראו בונוסים מיותרים, בזבזו אותם, והפעולה ההפוכה כבר דרשה תיקון ידני של היתרה.
התמיכה קיבלה עשרות פניות זהות בשבוע, והנהלת החשבונות — אי-התאמות בין חשבון הבונוסים לבין המשלוחים בפועל.
מה שינינו
הפרדנו בין צבירה לחיוב כישויות שונות והכנסנו מפתח אידמפוטנטי לפעולה: כל עסקת קאשבק מקושרת כעת לזוג "הזמנה + סוג פעולה", ורישום חוזר עם אותו מפתח נדחה ברמת המטפל.
את הסוכן העברנו למצב תור עם נעילה על הזמנה מסוימת, ולא על הטבלה כולה, — תהליכים מקבילים הפסיקו לדרוס זה את נתוני זה. בנוסף הוספנו יומן פעולות עם ציון מקור: ניתן לראות מי זקף את הבונוסים — ביצוע ההזמנה, המשלוח או תיקון ידני של המפעיל.
מה התוצאה
שיעור החיובים השגויים ירד מ-6% ל-0.2% — אלו מקרים בודדים שנתפסים בשלב ההתאמה, ולא לאחר תלונת הקונה. הפניות לתמיכה בנושא הבונוסים הצטמצמו פי כשבעה, תיקונים ידניים של היתרה — כמעט לאפס: המפעיל מתערב רק במצבים שנויים במחלוקת אמיתיים. התאמת חשבון הבונוסים עם המשלוחים מתבצעת כעת אוטומטית, ללא בדיקה שורה אחר שורה.
נציין בנפרד, שההגירה בוצעה ללא עצירת תוכנית הנאמנות: עסקאות ישנות הועברו עם מפתחות מוצבים, וחדשות נרשמו כבר לפי הסכימה החדשה. נקבעה גם אפשרות חזרה לאחור — יומן הפעולות מאפשר לשחזר את יתרתו של כל קונה לתאריך שרירותי.
במה שונה צבירת קאשבק בביטריקס ובביטריקס24
צבירת קאשבק בביטריקס ובביטריקס24 — אלו שני סוגים שונים של משימות, למרות שליבה שלהם משותף.
ב-«1C-Bitrix: Управление сайтом» נקודות מתקיימות במאפיינים מותאמים אישית או במבנה אינפובלוק נפרד: אתם בעצמכם קובעים את טבלת האחסון, בעצמכם כותבים מטפלים לצבירה ולחיוב, בעצמכם אחראים לאידמפוטנטיות של הפעולות.
בביטריקס24 אותו מנגנון נשען על ישויות תקניות — חשבון המשתמש והמטבע הפנימי, והצבירה עוברת דרך אירועים של מודול החנות המקוונת. ההבדל עקרוני: במקרה הראשון אתם בונים את הלוגיקה מאפס, בשני — משתלבים במודל חישובים מוכן.
אחסון הנקודות קובע את כל השאר. כאשר היתרה נמצאת במאפיין של המשתמש, אתם מקבלים שליטה מלאה על המבנה, אך מאבדים כלים מוכנים להתאמה ודיווח — כל פעולה יש לתעד ביומן באופן עצמאי.
חשבון תקני בביטריקס24 מספק היסטוריית תנועות, נעילת יתרה בזמן ביצוע הזמנה והגנה מפני חיוב כפול בבקשות מקבילות. בפועל זה מסיר סוג שלם של שגיאות, אשר בסכימה בכתיבה עצמית צפות כבר בסביבת הפרודקשן.
גם המטפלים לצבירה נבדלים בנקודת החיבור. במהדורות «Управление сайтом» הצבירה נתלית בדרך כלל על אירוע ביצוע ההזמנה או על סוכן שמחשב מחדש קטגוריות לפי לוח זמנים.
בביטריקס24 הגיוני יותר להשתמש באירועי חשבון ובכללים לעבודה עם המטבע הפנימי — אז הצבירה מסונכרנת עם תנועת הכספים לפי ההזמנה, ופערים בין היתרה להיסטוריית הרכישות לא נוצרים.
ההבדלים בין המהדורות מוסיפים שכבה נוספת. המהדורות הצעירות של «Управление сайтом» אינן מכילות את מודול החנות המקוונת במלואו, ולכן הקאשבק שם נבנה על אינפובלוקים וטבלאות משל עצמכם.
במהדורות הבכירות ובביטריקס24 זמינים מנגנונים תקניים של הנחות ובונוסים, שניתן להרחיב בכללים של קטגוריות וחריגים. לפני תכנון אנחנו תמיד מתאימים את המהדורה ואת מערך המודולים המחוברים — מכך תלוי אם לכתוב לוגיקה מאפס או לכוונן מוכנה.
מסקנה מעשית: מעבירים פרויקט מ-«Управление сайтом» לביטריקס24 — אל תגררו אחסון נקודות בכתיבה עצמית, העבירו אותו לחשבון תקני. מעבר בכיוון ההפוך דורש פעולה הפוכה.
אנחנו מנתחים את הסכימה הנוכחית של האחסון והמטפלים, מראים היכן היא תיכשל תחת עומס, ומציעים ארכיטקטורת יעד המתאימה למהדורה שלכם.
נדון במשימה שלך בנושא קאשבק
כדי לחזור עם הערכה ותוכנית יישום, עלינו להבין את המכניקה הנוכחית של הצבירה: היכן מחושב הקאשבק, אילו קטגוריות מוצרים משתתפות, כיצד מטופלים חריגים וכיצד התוצאה מגיעה ללקוח.
תאר את המשימה בצורה חופשית — זה מספיק כדי שנגדיר את היקף העבודה ונציע ארכיטקטורה.
- כיצד נצבר כעת הקאשבק: ידנית, באמצעות כללי סל, מטפלי אירועים או שירות חיצוני;
- אילו קטגוריות מוצרים ומדורי קטלוג משתתפים, האם קיימים סדרי עדיפויות ביניהם;
- כיצד מוגדרים החריגים: מוצרים חריגים, מותגים, פריטים במבצע, מוצרים בהזמנה;
- האם נדרש קאשבק דו-שלבי — צבירה מקדמית בעת ההזמנה וסופית לאחר התשלום או המשלוח;
- כיצד נסלק הקאשבק: חלקית, מלאה, עם הגבלת חלק מסכום ההזמנה;
- מה תוקף הנקודות ומה קורה להן בעת החזרה או ביטול הזמנה;
- היכן הלקוח רואה את היתרה: אזור אישי, הודעות דואר, אפליקציה לנייד, מערכת חיצונית;
- אילו אינטגרציות מושפעות: 1С, תוכנית נאמנות, CRM, מחסן, מודול תשלומים.
אם חלק מהמכניקה כבר מיושם ועובד באופן לא יציב, תאר את הסימפטום: נקודות נצברות פעמיים, אינן נסלקות בעת ביצוע ההזמנה, אינן תואמות ל-1С לאחר סנכרון. לפי פרטים אלה נוכל לאתר את הסיבה מהר יותר מאשר לפי תיאור כללי.
תאר את המשימה — נחזור עם הערכת לוחות זמנים, תוכנית יישום והרכב העבודה בכל שלב.