פיתוח אזור אישי B2B ב-1C-Bitrix

מדוע אזור אישי B2B נתקע בעיבוד הזמנות ידני

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

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

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

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

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

מה משתנה לאחר ההשקה: זמן ההזמנה, שיעור השגיאות, העומס

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

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

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

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

הרביעי — הפחתת שגיאות בהזמנות הודות לכללי גישה: הקונה רואה רק את הקטלוג שלו ואת התנאים שלו, ובצד 1С-Битрикс נרשם מי ולפי איזה חוזה ביצע את הבקשה. העומס על המנהלים עובר מהזנה לחריגים — פריטים לא טיפוסיים ואישור הנחות.

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

שלוש דרכים למימוש פורטל B2B והמגבלות שלהן

בהתחלה כמעט תמיד עולה שאלה אחת: מה להשאיר לפונקציונליות המובנית של 1С-Битрикс, ומה לכתוב בעצמנו. הפונקציונליות הטיפוסית מכסה את הבסיסי — שיוך עובדים לחברה, מחירים נפרדים לפי חוזים, היסטוריית הזמנות, חשבוניות ומסמכים, תפקידים ומסגרות רכש. אי-ההתאמות מתחילות בחריגים: אישור רב-שלבי, מחיר לפי נפח ודחיות תשלום, מסגרות לפי יחידות משנה.

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

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

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

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

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

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

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

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

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

מקרה בוחן: ספק סיטונאי הסיר את הזנת ההזמנות הידנית

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

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

הרכבנו פורטל B2B על 1С-Битрикс עם אזור אישי: הלקוח רואה את הקטלוג שלו, את התנאים האישיים ואת היתרות, מרכיב הזמנה וחוזר על רכש קודם בכמה פעולות.

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

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

מה לעשות אם הקונים כבר עובדים בפורטל הישן

פורטל ישן לא מכבים בתאריך אחד: תחילה עורכים ספירה של מה שבאמת מחזיק את המכירות — חשבונות הקונים, חוזים, מחירים מאושרים, מסגרות והיסטוריית הזמנות. ב-1С-Битрикс אלה ישויות שונות המקושרות ביניהן, ולכן ההעברה נעשית לא בייצוא אחד, אלא לפי הקשרים.

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

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

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

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

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

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

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

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

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

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

האם האזור האישי יעמוד בשיא העונתי?

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

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

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

נדון במשימה ונחזור עם הערכה, סכמה ותוכנית עבודה

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

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

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

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

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