הגדרת אנליטיקה חזויה למכירות ב-1C-Bitrix

אנליטיקה חזויה ב-1C-Bitrix: היכן נשברת תחזית המכירות

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

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

שורש הבעיה — איכות הנתונים ב-CRM. אנליטיקה חזויה ב-1C-Bitrix עובדת לא על כרטיסים "גולמיים", אלא על מערך מאפיינים מוכן: שלב העסקה והזמן בו, מקור הליד, היסטוריית נגיעות, הסכום והשינויים בו, פעילות הלקוח.

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

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

איחוד הזרימות למאגר אחד עם עדכון סדיר — זה שבלעדיו אנליטיקה חזויה ב-1C-Bitrix נשארת הדגמה ולא כלי עבודה.

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

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

מפרקים כיצד זה נסגר: מביקורת נתונים ואיחוד מקורות ועד מודל תחזית המשולב בדוחות 1C-Bitrix.

מה נותן יישום של אנליטיקה חזויה

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

מה משתנה באופן מדיד:

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

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

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

גישות לבניית מודל תחזית: השוואה

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

מה קובע את הבחירה

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

כיצד אנו מסירים את המגבלות

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

שלבי הטמעת אנליטיקה חזויה

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

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

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

תארו אילו נתונים קיימים במערכת שלכם — נחזור עם הערכה ותוכנית לפי שלבים אלה.

מה הלקוח מקבל לידיו

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

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

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

מקרה בוחן: תחזית מכירות למחלקה של 40 מנהלים

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

לפני הפרויקט התחזית החודשית נאספה ידנית — ראשי הקווים איחדו ייצוא נתונים מ-1С:Управление торговлей ומ-CRM לטבלה משותפת, כל איטרציה ארכה יומיים, והפער בין התוכנית לביצוע בפועל בסוף החודש הגיע ל-35-40%.

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

מה שינינו

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

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

מדדים לפני ואחרי

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

במה שונה אנליטיקה חזויה מדיווח רגיל?

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

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

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

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

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

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

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

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

ספקות טכניים נפוצים

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

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

איך התחזית קשורה ל-1С והאם האינטגרציה לא תשבור את הנהלת החשבונות?

נתונים על חשבוניות, תשלומים ומשלוחים נלקחים מ-1С, ופעילויות ושלבים — מ-CRM. החיבור נעשה לפי לקוחות ומסמכים, וההחלפה מוגדרת בכיוון אחד — לקריאה בלבד, כדי שהאנליטיקה לא תוכל לשנות רשומות חשבונאיות.

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

מה קורה למודל אחרי ההשקה — מישהו מתחזק אותו?

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

נדון במשימת החיזוי שלכם

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

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

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

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

מה להכין מצדכם:

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

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

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