מה זה EDI? איך הוא מקל על הזמנות בין חברות — מ-FAX, מייל והזנה ידנית ל-data integration

“משותף עסקי מגיעה הזמנת רכש ב-FAX, והאחראי מזין אותה למערכת ניהול המכירות.” “פותחים Excel שצורף למייל, בודקים product code וכמות ומעתיקים.” “אחרי האספקה מפיקים חשבונית, וגם אצל הצד השני מזינים את אותו תוכן למערכת הנהלת החשבונות.” בעסקאות בין חברות, לפעמים אותם נתוני הזמנה וחיוב מוזנים שוב ושוב, בכמה חברות ובכמה אחראים.

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

המאמר מסביר מה זה EDI, במה הוא שונה מ-FAX וממייל, ואיך ההטמעה מקלה על העבודה בחברה — דרך דוגמה של עיבוד הזמנות. נשמור על מינימום jargon, אבל את ארבעת המונחים הבאים כדאי להכיר מראש.

1. קודם כל, המסקנה

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

JIPDEC (Japan Information Economy and Society Promotion Association) הוא גוף שעוסק בסטנדרטיזציה ובהסברה בתחומים כמו מסחר אלקטרוני, אבטחת מידע והגנה על מידע אישי, ומפרסם באופן שוטף מידע על קודי חברות ועל EDI. גם במאמר הזה נעזרים בהסבר שלו להגדרת EDI ולתועלת שלו. בהסבר של JIPDEC EDI מתואר כ”חיבור מחשבים של חברות ורשויות לרשת, והחלפה אוטומטית של מסמכים ותעודות כנתונים אלקטרוניים”, ומוצגת גם ההגדרה לפי JIS X 7011.

מטרת ההטמעה של EDI אינה רק לבטל את השימוש בנייר. המטרה העיקרית היא לצמצם עבודה מהסוג הזה.

• הזנה ידנית מול FAX או PDF
• העתקה מ-Excel למערכת ניהול מכירות
• בדיקה בעין של מה שהוזן
• חיפוש הזמנות רכש וחשבוניות
• שיחות טלפון ומיילים לבירור סטטוס הזמנה
• ריכוז מחדש של נתוני מכירות, מלאי וחיוב

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

knowledge map של המאמר

EDI הוא מנגנון שבו חברות מחליפות ביניהן מידע עסקאות כמו הזמנת רכש, הודעת משלוח וחשבונית בפורמט נתונים אלקטרוני שסוכם מראש, כדי לבטל את עצם ההקלדה מחדש הידנית. מעבר להפחתת שגיאות העתקה ולהאצת עיבוד ההזמנות, האפקט נוצר רק כשמקשרים את הנתונים שהתקבלו עד מערכות המלאי, המשלוח והחיוב הפנימיות; אם לא מייבאים אלא מדפיסים ומעבדים ידנית, אין הבדל מ-FAX. פורמט שמותאם לכל שותף בנפרד מייקר את העלות, ולכן EDI מבוסס-סטנדרט או SME Common EDI הם הבחירה המציאותית. Digital Invoice הוא יישום מעשי של אותה גישה לתחום החשבוניות, ולפני ההטמעה מיפוי שיטות ההזמנה והקבלה הנוכחיות לפי שותף קודם לבחירת מוצר.

flowchart LR
    accTitle: knowledge map: החלפת נתונים בין חברות ב-EDI
    accDescr: Diagram שמראה איך EDI מונע הקלדה מחדש ידנית ושגיאות העתקה, איך הוא מאוטמט עיבוד הזמנות ואת הקישור למלאי, משלוח וחיוב, איך פורמט סטנדרטי ו-SME Common EDI עונים על בעיית פורמט נפרד לכל שותף, ואיך Digital Invoice מיישם את אותה גישה בתחום החשבוניות.
    edi["EDI"]
    manual_reentry["הקלדה מחדש ידנית"]
    transcription_error["שגיאת הקלדה בהעתקה"]
    order_processing_lead_time["lead time של עיבוד הזמנות"]
    trading_partner_agreement["הסכם EDI עם לקוח"]
    master_code_alignment["התאמת קודי master (מוצר וכו')"]
    order_to_cash_integration["קישור מלאי, משלוח וחיוב אחרי הזמנה"]
    edi_standard_format["EDI מבוסס-standard"]
    edi_individual_format["EDI נפרד לכל לקוח"]
    sme_common_edi["SME Common EDI"]
    digital_invoice["digital invoice"]
    current_process_inventory["מיפוי שיטות הזמנה נוכחיות"]
    order_status_visibility["נראות סטטוס הזמנה"]
    task_personalization["תלות העבודה באדם אחד"]
    low_frequency_irregular_trading["עסקאות לא-שגרתיות בתדירות נמוכה"]
    high_frequency_recurring_trading["עסקאות שגרתיות בתדירות גבוהה"]
    edi -->|"מפחית"| manual_reentry
    manual_reentry -->|"עלול לגרום ל"| transcription_error
    edi -.->|"מפחית"| transcription_error
    edi -->|"מפחית"| order_processing_lead_time
    edi -->|"דורש"| trading_partner_agreement
    edi -->|"דורש"| master_code_alignment
    edi -->|"מאוטמט את"| order_to_cash_integration
    edi -.->|"דורש"| order_to_cash_integration
    edi -->|"משתמש ב"| edi_standard_format
    edi_standard_format -->|"מומלץ ל"| edi_individual_format
    sme_common_edi -->|"מומלץ ל"| edi_individual_format
    digital_invoice -.->|"משתמש ב"| edi
    current_process_inventory -->|"צריך לבוא לפני"| edi
    edi -->|"מאוטמט את"| order_status_visibility
    order_status_visibility -->|"מפחית"| task_personalization
    edi -.->|"לא מומלץ ל"| low_frequency_irregular_trading
    edi -->|"מומלץ ל"| high_frequency_recurring_trading

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 17, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. בלי EDI, מה קורה בעיבוד ההזמנות

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

flowchart TD
    accTitle: זרימת ההזמנות בלי EDI
    accDescr: תרשים שמראה שנתוני הזמנה מודפסים או מומרים ל-PDF ונשלחים ב-FAX או במייל, הצד המקבל מזין אותם מחדש, והצד המזמין מזין שוב את נתוני המשלוח והחיוב למערכת שלו.
    A["הזנת נתוני הזמנה אצל הצד המזמין"] --> B["הדפסת הזמנת הרכש או המרה ל-PDF"]
    B --> C["שליחה ב-FAX או במייל"]
    C --> D["האחראי בצד המקבל בודק את התוכן"]
    D --> E["הזנה מחדש למערכת של הצד המקבל"]
    E --> F["יצירת נתוני משלוח ונתוני חיוב"]
    F --> G["הצד המזמין מזין שוב למערכת שלו"]

איור 1: זרימת ההזמנות בלי EDI. הנתונים מוזנים מחדש בידי אדם, פעמיים.

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

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

3. עם EDI, איך משתנה עיבוד ההזמנות

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

flowchart LR
    accTitle: זרימת ההזמנות עם EDI
    accDescr: תרשים שמראה שנתוני הזמנה עוברים ממערכת הרכש של הצד המזמין דרך EDI למערכת ניהול המכירות של הצד המקבל, ואישור הזמנה, הודעת משלוח ונתוני חיוב חוזרים באותו מסלול.
    A[מערכת הרכש של הצד המזמין] --> B[נתוני הזמנה]
    B --> C[שליחה והמרה ב-EDI]
    C --> D[מערכת ניהול המכירות של הצד המקבל]
    D --> E[אישור הזמנה]
    D --> F[הודעת משלוח]
    D --> G[נתוני חיוב]
    E --> C
    F --> C
    G --> C
    C --> A

איור 2: זרימת ההזמנות עם EDI. השלבים “הדפסה”, “בדיקה בעין” ו”הזנה מחדש” מאיור 1 נעלמו.

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

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

4. במה EDI שונה ממייל, PDF ו-Excel

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

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

עם זאת, השימוש ב-PDF או ב-Excel עצמו אינו רע. מה שחשוב הוא מה קורה לנתונים אחרי הקבלה. “אדם מזין מול PDF”, “פותחים Excel ומעתיקים”, “קולטים CSV ישירות למערכת”, “רושמים אוטומטית דרך API” — אותו “קובץ אלקטרוני”, ועומס השלב הבא שונה לגמרי. כשבודקים את התועלת של EDI צריך להסתכל לא רק על שיטת השליחה, אלא על מה שאדם עושה אחרי הקבלה.

4.1. מפה של מה שנקרא “EDI”

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

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

5. איזה מידע אפשר להחליף ב-EDI

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

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

1. לבדוק כפילות במספר הזמנה
2. לבדוק שה-product code קיים
3. להקצות מלאי
4. לחשב מועד אספקה
5. לשלוח הוראת משלוח למחסן
6. להחזיר אישור הזמנה לצד המזמין

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

6. איך EDI מקל על העבודה בחברה

כפי שראינו בפרקים 2 עד 4, התועלת הישירה של EDI היא ש”נעלמת ההזנה הידנית מול הזמנת רכש”. בפרק הזה נעבור בשישה סעיפים על מה קורה מכאן והלאה. התועלת אינה רק חיסכון בהזנה.

6.1. אפשר להפנות את זמן האחראי לטיפול בחריגים

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

• הזמנה שחסר בה מלאי
• הזמנה עם מועד אספקה חריג
• הזמנה עם product code שלא רשום
• הזמנה בהיקף גדול
• הזמנה שצריך לבדוק בה מחיר יחידה או תנאי חוזה

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

6.2. אפשר לצמצם שגיאות הזנה

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

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

6.3. אפשר לקצר את עיבוד ההזמנה

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

ב-EDI אפשר לקלוט את הנתונים שהתקבלו אוטומטית למערכת, ולכן מיד אחרי קבלת ההזמנה אפשר להתחיל בקליטה, בדיקת מלאי, חישוב מועד אספקה, הוראת משלוח למחסן, והחזרת אישור הזמנה. כשעיבוד ההזמנה מתקצר, גם הזמן עד למשלוח קל יותר לקצר. גם JIPDEC מונה כתועלת של EDI ייעול וזירוז של עבודה משרדית, אספקה just-in-time, קיצור lead time וצמצום מלאי.

6.4. קל יותר לבדוק מה מצב ההזמנה

כשמערבבים נייר, FAX, מייל ו-Excel, לוקח זמן לברר “איפה ההזמנה הזו עכשיו”. צריך לבדוק אחד אחרי השני את תיבת המייל של האחראי, תיקייה משותפת, קלסר נייר, מערכת ניהול מכירות.

ב-EDI אפשר לקשר ולנהל לפי מספר הזמנה וכדומה את המידע הבא.

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

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

6.5. אפשר לחבר למלאי, למשלוח ולהנהלת חשבונות

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

flowchart TD
    accTitle: השלבים הפנימיים אחרי קבלת נתוני הזמנה
    accDescr: תרשים שמראה את השלבים מקבלת נתוני הזמנה, דרך רישום הזמנה, הקצאת מלאי, הוראת משלוח, רישום מכירה ויצירת נתוני חיוב, עד התאמת תשלומים.
    A["קבלת נתוני הזמנה"] --> B["רישום הזמנה"]
    B --> C["הקצאת מלאי"]
    C --> D["הוראת משלוח"]
    D --> E["רישום מכירה"]
    E --> F["יצירת נתוני חיוב"]
    F --> G["התאמת תשלומים"]

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

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

6.6. אפשר להשתמש בנתוני העסקאות להחלטות ניהול

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

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

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

7. התועלת של EDI בדוגמה פשוטה

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

100 הזמנות × 3 דקות = 300 דקות → 5 שעות ליום

אחרי הטמעת EDI, 80 הזמנות נקלטות אוטומטית ורק 20 נשארות לבדיקה אנושית. אז זה נראה כך.

20 הזמנות × 3 דקות = 60 דקות → שעה ליום

זו דוגמה מפושטת, אבל עבודת ההזנה יורדת מ-5 שעות לשעה. בפועל, מעבר לזה עשוי לרדת גם זמן לבדיקת FAX קשה לקריאה, תיקון שגיאות הזנה, שיחת בירור על תוכן הזמנה, חיפוש הזמנת רכש, ריכוז רשימת הזמנות, והעברה בין אחראים. התועלת של הטמעת EDI אינה רק עלות ישירה כמו “פחות נייר”. יש משמעות גדולה לצמצום בדיקות, הזנות ותיקונים קטנים שחוזרים כל יום.

7.1. חישוב במספרים שלכם

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

(1) מספר הזמנות ביום                          …… A הזמנות
(2) זמן הזנה ובדיקה להזמנה אחת                …… B דקות
(3) שיעור שצפוי לעבור עיבוד אוטומטי ב-EDI     …… C %
(4) ימי עסקים בשנה                            …… D ימים

זמן כיום                    = A × B                         (דקות/יום)
זמן שנשאר אחרי הטמעת EDI    = A × (1 - C ÷ 100) × B         (דקות/יום)
חיסכון ליום                 = A × (C ÷ 100) × B             (דקות/יום)
חיסכון לשנה                 = חיסכון ליום × D ÷ 60          (שעות/שנה)

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

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

8. היתרון של EDI לפי מחלקה

ייעול העבודה ב-EDI אינו מוגבל למחלקת ההזמנות.

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

9. הטמעת EDI לא מאוטומטת את הכול

EDI הוא מנגנון נוח, אבל ההטמעה לבדה לא מאוטומטת את כל העבודה.

9.1. צריך הסכמות עם השותף העסקי

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

להסכמות האלה יש שכבות. JIPDEC מחלק אותן לחמש הבאות. אם מערבבים על איזו שכבה מדובר כשאומרים “מטמיעים EDI”, לא מדברים על אותו דבר.

השוואת מוצרים ושירותים נוטה להתמקד בשתי השכבות העליונות (communication protocol ו-syntax rules), אבל הקושי בהטמעה יושב בשלוש התחתונות. במיוחד “הודעות ושדות נתונים” הוא בדיוק יישור הקודים של 9.2. אם בוחרים מוצר בלי לסגור את זה עם השותף העסקי, אחר כך חוזרים אחורה לתקן.

9.2. צריך ליישר product codes וכדומה

לפעמים הצד המזמין והצד המקבל משתמשים בקודים שונים לאותו מוצר. למשל אצל המזמין הקוד הוא A-001 ואצל המקבל 100245. במקרה כזה צריך טבלת המרה. מעבר ל-product code מיישרים גם שדות מהסוג הזה.

• קוד לקוח
• קוד יעד אספקה
• יחידה
• יחידות באריזה
• סיווג מס
• מטבע
• פורמט תאריך
• encoding

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

9.3. טיפול בחריגים נשאר

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

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

9.4. תהיה תקופה של הפעלה במקביל ל-FAX ולמייל

לא כל הלקוחות יכולים לעבור ל-EDI באותו זמן. לכן בתחילת ההטמעה לפעמים רצים במקביל כמה ערוצי קבלה: EDI, מסך Web, העלאת CSV, מייל, FAX, טלפון.

במצב כזה, גם אחרי הטמעת EDI אי אפשר מיד לצמצם את האחראים על העבודה הישנה. כדי להגדיל תועלת צריך לעבור לפי הסדר מהלקוחות עם נפח העסקאות הגבוה, ולהקטין את מספר ההזמנות שמטופלות ידנית. גם JIPDEC מציין שאם נשאר טיפול ידני ב-FAX ובטלפון, צריך כוח אדם למענה הזה, וקשה לממש במלואה את תועלת הייעול. זו גם הסיבה שבחישוב בפרק 7.1 כדאי לשים את “השיעור שניתן לעבד אוטומטית” בזהירות.

10. לאילו חברות EDI מתאים

EDI נוטה להניב תועלת במיוחד בחברות מהסוג הזה.

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

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

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

11. איך מתקדמים כשבוחנים הטמעת EDI

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

11.1. להכין רשימה של שיטות ההזמנה הנוכחיות

לכל לקוח מרכזים את המידע הבא.

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

11.2. מתחילים מלקוח אחד עם נפח גבוה

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

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

אחרי שמייצבים תפעול מול לקוח אחד, מרחיבים ללקוחות אחרים.

11.3. מצמצמים את מה שמוחלף

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

1. שלב 1: נתוני הזמנה
2. שלב 2: אישור הזמנה ומענה למועד אספקה
3. שלב 3: הודעת משלוח
4. שלב 4: נתוני חיוב

הרחבה מדורגת של הטווח מאפשרת לבדוק תועלת תוך צמצום ההשפעה על העבודה בפועל.

11.4. בודקים חיבור למערכת הפנימית

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

• האם יש קלט ופלט CSV
• האם אפשר להשתמש ב-API
• האם אפשר להתחבר ל-database
• איפה מבצעים המרת product code
• איך מונעים כפילות בנתונים שהתקבלו
• למי מודיעים על שגיאה
• איפה שומרים היסטוריית עיבוד

חשוב לבדוק את שיטת החיבור למערכת הקיימת לפני בחירת מוצר. אם כאן מתברר ש”אין קלט ופלט CSV” או “אין API”, קודם צריך שינוי במערכת הקיימת או מנגנון תיווך, ורק אחר כך בחירת שירות EDI.

12. מדדים שכדאי למדוד אחרי הטמעת EDI

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

• זמן הזנת הזמנה
• הזמן עד לסיום עיבוד הזמנה אחת
• מספר תיקוני הזנה
• מספר רישומים כפולים
• מספר פניות לבירור הזמנה
• מספר איחורי משלוח
• שיעור ההזמנות שעובדו ב-EDI
• שיעור הזמנות החריגות שבדק אדם

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

סיכום

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

השינויים העיקריים שאפשר לצפות מ-EDI:

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

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

נקודת היציאה להטמעת EDI אינה “איזה מוצר”, אלא לבדוק כמה פעמים מזינים את אותו מידע בעבודה הנוכחית. מוצאים את המקומות שבהם אדם מעביר מידע בין FAX, מייל, Excel, מסך Web ומערכת ניהול מכירות, ומשם מחליפים לפי הסדר ב-data integration את העבודות שיש בהן הרבה הזמנות והן סטנדרטיות. זה המסלול המעשי.

למי ששוקל data integration בהזמנות בין חברות

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

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

ב-KomuraSoft LLC אפשר להתייעץ על מיפוי המצב הקיים ועל דרכי מימוש של אינטגרציה עסקית שכוללת אפליקציות Windows עסקיות קיימות, CSV וקבצים באורך קבוע, database ומערכות Web.

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

מקורות

• JIPDEC (Japan Information Economy and Society Promotion Association), מה זה EDI. הגדרת EDI (חיבור מחשבים של חברות ורשויות לרשת, והחלפה אוטומטית של מסמכים ותעודות כנתונים אלקטרוניים), ההגדרה לפי JIS X 7011, המנגנון של המרה הדדית בין פורמט ייחודי לכל חברה לפורמט תקני, וזה שתמונות סריקה ומיילים בטקסט רגיל מובחנים מנתוני EDI.
• JIPDEC, היתרונות של EDI והצורך בתקן EDI. ייעול וזירוז של עבודה משרדית, אספקה just-in-time, קיצור lead time, צמצום מלאי, הפחתת טעויות אנוש, שימוש בניתוח מוצרים מובילים, spend analysis ותחזית ביקוש, הצורך במנגנון המרה לכל לקוח ועלויות שלא מתיישבות כשלא הולכים לפי תקן, חמש ההסכמות הנדרשות (communication protocol, syntax rules, הודעות ושדות נתונים, כללי תפעול עסקיים, הסכם המסגרת לעסקה), וזה שאם מדפיסים נתונים שהתקבלו ומעבדים אותם ביד אין הבדל גדול מ-FAX.
• הסוכנות היפנית לעסקים קטנים ובינוניים, דיגיטציה של הזמנות (EDI משותף לעסקים קטנים ובינוניים). שיפור ביעילות העבודה, הפחתת טעויות אנוש ושיפור יכולת החיפוש ברשומות עסקה כתוצאה מדיגיטציה של הזמנות, והכנת “EDI משותף לעסקים קטנים ובינוניים” שעושה סטנדרטיזציה לעיבוד הזמנות לעסקים קטנים ובינוניים.
• Digital Agency, JP PINT (מפרט סטנדרטי לחשבונית אלקטרונית). Digital Agency מנהלת ומפרסמת כ-Peppol Authority של יפן את “JP PINT”, מפרט הסטנדרט היפני לחשבונית אלקטרונית שמוחלפת ברשת Peppol.

מאמרים קשורים

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

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

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