EDI क्या है? Companies के बीच order processing कैसे आसान होता है — FAX, email और manual entry से data integration तक

“Trading partner से FAX पर purchase order आता है, और staff उसे sales management system में enter करता है।” “Email के साथ आया Excel खोलते हैं, product code और quantity चेक करके उतारते हैं।” “Delivery के बाद invoice बनता है, और सामने वाली company वही जानकारी अपने accounting system में enter करती है।” Companies के बीच के transactions में एक ही order और billing जानकारी कई companies, कई लोग, बार-बार enter करते रहते हैं।

इस duplicate entry को घटाकर purchase order, sales order, shipping, invoice जैसे data को companies के बीच सीधे बाँटने वाला mechanism EDI है। EDI सुनते ही dedicated line पर चलने वाला बड़ा enterprise system दिमाग में आ सकता है। असल बात उससे कहीं सीधी है। Trading partner से आई जानकारी को staff पढ़कर दोबारा enter न करे, computer उसे ज्यों का त्यों process कर सके — data के रूप में exchange हो। बस इतना।

इस लेख में EDI क्या है, FAX और email से क्या फर्क है, और लगाने पर company का काम कैसे हल्का होता है — order processing को उदाहरण बनाकर cover किया गया है। Jargon कम रखेंगे, लेकिन ये चार शब्द पहले साफ़ कर लें।

1. निष्कर्ष पहले

EDI वह mechanism है जिसमें companies purchase order, shipping notice, invoice जैसी trade जानकारी पहले तय किए electronic data format में exchange करती हैं।

Japan Information Economy and Society Promotion Association (JIPDEC) electronic commerce, information security और personal-information protection जैसे क्षेत्रों में standardization और awareness का काम करती है, और company code तथा EDI पर जानकारी लगातार प्रकाशित करती है। इस लेख में EDI की परिभाषा और असर पर उसी संस्था की explanation का सहारा लिया गया है। JIPDEC की explanation EDI को “companies और administrative agencies अपने computers को network से जोड़कर, slips और documents को electronic data के रूप में automatic exchange करें” कहती है, और साथ में JIS X 7011 वाली परिभाषा भी देती है।

EDI लगाने का मकसद सिर्फ कागज़ खत्म करना नहीं है। मुख्य मकसद इस तरह का काम घटाना है।

• FAX या PDF देखकर manual entry
• Excel से sales management system में transcription
• Enter की गई बात की आँख से जाँच
• Purchase order या invoice ढूँढना
• Order status पूछने वाली phone call और email
• Sales, inventory, billing data दोबारा aggregate करना

एक वाक्य में: EDI वह mechanism है जो दो companies के बीच अटके data को बहने देता है।

इस लेख का knowledge map

EDI purchase order, shipping notice, invoice जैसी trade जानकारी companies के बीच पहले तय electronic data format में exchange करता है, ताकि मिली जानकारी की manual re-entry ही खत्म हो। Transcription errors कम होना और order processing तेज़ होना इसके अलावा, मिला data internal inventory, shipping, billing systems तक जुड़े तभी असर निकलता है — import न कर print करके हाथ से process करें तो FAX से फर्क नहीं। हर trading partner का अलग format cost बढ़ाता है, इसलिए standard पर आधारित EDI या SME Common EDI realistic विकल्प बनते हैं। Digital invoice इसी सोच को invoice क्षेत्र पर लगाने का practice है, और लगाने से पहले मौजूदा order methods का trading-partner-wise inventory लेना product selection से ऊपर की प्राथमिकता है।

flowchart LR
    accTitle: EDI से companies के बीच data exchange का knowledge map
    accDescr: EDI manual re-entry और transcription errors कैसे रोकता है, order processing तथा inventory, shipping, billing integration कैसे automate करता है, standard format और SME Common EDI per-partner custom format की समस्या का क्या जवाब देते हैं, और digital invoice इसी सोच को invoicing पर कैसे लगाता है — ये relations दिखाने वाला diagram।
    edi["EDI (Electronic Data Interchange)"]
    manual_reentry["मिली जानकारी की manual re-entry"]
    transcription_error["transcription error"]
    order_processing_lead_time["order processing lead time"]
    trading_partner_agreement["trading partner के साथ EDI agreement"]
    master_code_alignment["product code आदि का master data alignment"]
    order_to_cash_integration["order के बाद inventory, shipping, billing integration"]
    edi_standard_format["standard पर आधारित EDI"]
    edi_individual_format["हर trading partner का अलग EDI"]
    sme_common_edi["SME Common EDI"]
    digital_invoice["digital invoice"]
    current_process_inventory["मौजूदा order methods का inventory"]
    order_status_visibility["order status visibility"]
    task_personalization["काम का person-dependent होना"]
    low_frequency_irregular_trading["low-frequency, irregular trading"]
    high_frequency_recurring_trading["high-frequency, regular repeat trading"]
    edi -->|"mitigate करता है"| manual_reentry
    manual_reentry -->|"cause हो सकता"| transcription_error
    edi -.->|"mitigate करता है"| transcription_error
    edi -->|"mitigate करता है"| order_processing_lead_time
    edi -->|"require करता है"| trading_partner_agreement
    edi -->|"require करता है"| master_code_alignment
    edi -->|"automate करता है"| order_to_cash_integration
    edi -.->|"require करता है"| order_to_cash_integration
    edi -->|"use करता है"| edi_standard_format
    edi_standard_format -->|"recommended उपाय"| edi_individual_format
    sme_common_edi -->|"recommended उपाय"| edi_individual_format
    digital_invoice -.->|"use करता है"| edi
    current_process_inventory -->|"पहले करना चाहिए"| edi
    edi -->|"automate करता है"| order_status_visibility
    order_status_visibility -->|"mitigate करता है"| task_personalization
    edi -.->|"recommended नहीं"| low_frequency_irregular_trading
    edi -->|"recommended उपाय"| high_frequency_recurring_trading

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 17, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

2. EDI न हो तो order processing में क्या होता है

पहले वह order processing सोचें जिसमें EDI नहीं है। Ordering company में purchasing staff अपने system या Excel में order बनाता है, उसे purchase order के रूप में print करता है, और FAX या email से trading partner को भेजता है। Receiving company में आया हुआ purchase order staff चेक करता है और अपने sales management system में enter करता है। उसके बाद order confirmation, shipping notice, delivery note, invoice बनाकर ordering company को लौटाते हैं, और ordering company भी वही जानकारी inventory system या accounting system में enter करती है।

flowchart TD
    accTitle: EDI के बिना order processing का flow
    accDescr: Order data print या PDF बनकर FAX या email से जाता है, और दोनों तरफ लोग उसे फिर से system में enter करते हैं
    A["Ordering company में order data enter"] --> B["Purchase order print या PDF"]
    B --> C["FAX या email से भेजना"]
    C --> D["Receiving company का staff content चेक करता है"]
    D --> E["Receiving company के system में दोबारा enter"]
    E --> F["Shipping data और billing data बनाना"]
    F --> G["Ordering company फिर अपने system में enter"]

चित्र 1: EDI न हो तो order processing का flow। Data दो बार staff के हाथ से दोबारा enter होता है।

इस flow में product code, product name, quantity, unit price, delivery date, ship-to — वही जानकारी बार-बार enter होती है। मूल order data पहले से ordering company के computer में है। कागज़ या PDF बन जाने के कारण receiving company का staff उसे फिर पढ़ता है और computer में फिर enter करता है।

समस्या यह नहीं कि जानकारी electronic नहीं थी। समस्या यह है कि एक बार data बन चुकी जानकारी staff के पढ़ने वाले document में बदल दी गई, और सामने वाली company में वह फिर data बन गई।

3. EDI लगाने पर order processing कैसे बदलता है

EDI में ordering company के system में बना order data, receiving company के system के पढ़ सकने वाले format में convert होकर ज्यों का त्यों भेज दिया जाता है। Receiving company का staff purchase order देखकर enter नहीं करता — मिला हुआ data sales management system में import हो जाता है।

flowchart LR
    accTitle: EDI के साथ order processing का flow
    accDescr: Order data EDI से sales management system में जाता है, और confirmation, shipping, billing data purchasing system तक लौटता है
    A["Ordering company का purchasing system"] --> B["Order data"]
    B --> C["EDI से भेजना और convert"]
    C --> D["Receiving company का sales management system"]
    D --> E["Order confirmation"]
    D --> F["Shipping notice"]
    D --> G["Billing data"]
    E --> C
    F --> C
    G --> C
    C --> A

चित्र 2: EDI के साथ order processing का flow। चित्र 1 वाले “print”, “आँख से चेक”, “दोबारा enter” के steps गायब हैं।

Ordering company से receiving company को order data जाता है, receiving company से ordering company को order confirmation, shipping, billing जैसा data लौटता है। Staff document देखकर transcribe करे, वह step बीच में नहीं आता — system से system data जाता है। यही बात है।

JIPDEC की explanation में हर company के अपने format वाले data को standard format में convert करना, और receiving company में standard से अपने format में convert करना — यही EDI का mechanism बताया गया है।

4. EDI और email, PDF, Excel में क्या फर्क है

अक्सर लगता है, “Purchase order PDF बनाकर email कर रहे हैं, तो electronic हो ही गया।” कागज़ डाक से भेजने से तेज़ है, रखना भी आसान है। लेकिन अगर लेने वाला PDF देखकर system में enter कर रहा है, तो entry का काम बचा रहता है। फर्क कुछ ऐसा बैठता है।

JIPDEC की explanation में slip की scanned image, या सामान्य वाक्यों में लिखी email, computer के दोबारा process कर सकने वाले EDI data से अलग मानी गई है। Web screen पर staff के हाथ से enter करना भी, सख्ती से देखें तो computers के बीच automatic exchange नहीं है।

हाँ, PDF या Excel इस्तेमाल करना अपने आप में गलत नहीं है। ज़रूरी यह है कि मिली जानकारी उसके बाद कैसे process होती है। “PDF देखकर staff enter करे”, “Excel खोलकर copy करे”, “CSV system में सीधे import हो”, “API से automatic register हो” — सब “electronic file” हैं, बाद का बोझ बिलकुल अलग है। EDI का असर आंकते समय सिर्फ भेजने का तरीका नहीं, receive के बाद staff क्या कर रहा है, वह देखना पड़ता है।

4.1. “EDI” कहलाने वाली चीज़ों का नक्शा

अब तक “EDI” एक शब्द में लिखा, लेकिन practical रूप से सोचने लगें तो कई नाम निकलते हैं। पहले जगह-जगह का संबंध साफ़ हो तो product description पढ़ते समय भटकाव कम होता है।

वर्ग के दो ही अक्ष हैं। एक: exchange का format हर partner की अलग spec है, या व्यापक सहमति वाला standard। दूसरा: आखिर में staff screen चलाता है, या system से system जाता है। इन दो अक्षों पर अपनी मौजूदा हालत और विकल्प रखें तो दिखेगा कि कहाँ ठीक करने से असर निकलेगा।

5. EDI से कौन-सी जानकारी exchange हो सकती है

EDI सिर्फ purchase order का mechanism नहीं है। Companies के बीच के transactions में निकलने वाली कई तरह की जानकारी exchange हो सकती है।

उदाहरण: order data मिलते ही receiving company का system ये processing कर सकता है।

1. Order number duplicate तो नहीं, चेक करना
2. Product code मौजूद है, चेक करना
3. Inventory allocate करना
4. Delivery date निकालना
5. Warehouse को shipping instruction भेजना
6. Ordering company को order confirmation लौटाना

Shipping के बाद shipping record से sales booking हो सकती है, और billing data बन सकता है। यानी EDI सिर्फ communication feature नहीं। Order processing को entry बनाकर, उसके बाद inventory, shipping, sales, billing तक जोड़ने की नींव है।

6. EDI company के काम को कैसे हल्का करता है

अध्याय 2 से 4 तक जैसा देखा, EDI का सीधा असर यह है कि “purchase order देखकर manual entry खत्म हो जाती है।” इस अध्याय में उसके आगे क्या होता है, छह बिंदुओं में रखा गया है। असर सिर्फ entry effort घटाना नहीं है।

6.1. Staff का समय exception handling पर लग सकता है

Manual entry हटते ही staff का समय कैसे खर्च होता है, वह बदलता है। हर order staff न करे — routine orders automatic हों, जहाँ फैसला चाहिए वही staff देखे। Staff को ये orders देखने चाहिए, मिसाल के तौर पर।

• Inventory कम पड़ रहा हो
• Delivery date सामान्य से अलग हो
• Product code registered न हो
• बड़े volume के orders
• Unit price या contract terms चेक करने हों

Entry में डूबे रहें तो ये जाँचें टलती रहती हैं। EDI की value “काम घट गया” से ज़्यादा यह है कि “बचा समय उन orders पर लगे जिन पर सच में ध्यान चाहिए।”

6.2. Entry errors घट सकते हैं

Staff के enter करने में एक probability पर गलती होती है। Product code का एक अंक गलत, quantity 10 की जगह 100, ship-to बदल जाना, requested delivery date गलत पढ़ना, वही order दो बार register होना — ऐसे ही।

EDI में भी मूल data गलत हो तो समस्या आती है। लेकिन सही बना data सामने दोबारा enter नहीं करना पड़ता, इसलिए transcription वाली stage की गलतियाँ घटती हैं। Small and Medium Enterprise Agency (Japan) भी order processing के digitalization के असर में work efficiency बढ़ना, human error घटना, और transaction records की searchability बढ़ना गिनाती है।

6.3. Order processing तेज़ हो सकता है

FAX या email में staff को receive दिखे, content चेक हो, entry खत्म हो — तब जाकर order processing शुरू होता है। Orders वाले दिन entry की कतार लगती है, staff छुट्टी पर हो तो processing रुकती है।

EDI में मिला data automatic system में import हो सकता है, इसलिए order मिलते ही order accept, inventory check, delivery-date calculation, warehouse को shipping instruction, order confirmation लौटाना — ये processing शुरू हो सकती है। Order processing तेज़ हो तो shipment तक का समय भी छोटा करना आसान होता है। JIPDEC भी EDI के असर में clerical काम की efficiency और गति, just-in-time delivery, lead time घटना, inventory घटना गिनाती है।

6.4. Order status देखना आसान होता है

कागज़, FAX, email, Excel मिले-जुले हों तो “वह order अभी कहाँ है” निकालने में समय लगता है। Staff का mailbox, shared folder, कागज़ की file, sales management system — एक-एक करके देखना पड़ता है।

EDI में order number वगैरह को कुंजी बनाकर यह जानकारी जोड़कर रखी जा सकती है।

• Order कब मिला
• सही import हुआ या नहीं
• Order confirmation लौटी या नहीं
• Ship हो चुका या नहीं
• Inspection / goods receipt हुआ या नहीं
• Invoice हो चुका या नहीं
• Error या resend हुआ या नहीं

Query आए तो staff की याद या personal email पर निर्भर न रहकर processing history से देख सकते हैं।

6.5. Inventory, shipping, accounting से जोड़ सकते हैं

मिला हुआ data internal systems से जोड़ें तो order register के बाद का काम भी automatic हो सकता है।

flowchart TD
    accTitle: Received order data का internal downstream flow
    accDescr: Order receive से payment reconciliation तक का chain; कितना आगे connect करते हैं, उसी से EDI का असर तय होता है
    A["Order data receive"] --> B["Order register"]
    B --> C["Inventory allocation"]
    C --> D["Shipping instruction"]
    D --> E["Sales booking"]
    E --> F["Billing data बनाना"]
    F --> G["Payment reconciliation"]

चित्र 3: मिला हुआ order data internal रूप से जिन बाद के steps से गुज़रता है। कितना आगे जोड़ें, वही implementation का असर तय करता है।

उलटा, EDI से order data आ भी जाए, उसे print करके staff sales management system में enter करे, तो असर सीमित रहता है। JIPDEC भी कहती है कि EDI से मिला data internal system में import न कर print करके हाथ से process करें तो FAX से बड़ा फर्क नहीं। EDI सिर्फ trading partner से communication लगाना नहीं — मिला data internal operations में कितनी दूर बहे, यही मायने रखता है।

6.6. Trade data management decisions में इस्तेमाल हो सकता है

कागज़ या PDF पर आया purchase order, रख भी लें तो aggregate करना मुश्किल है। EDI में trade जानकारी structured data के रूप में जमा होती है, इसलिए ये analysis जुड़ सकते हैं।

• Product-wise order volume
• Customer-wise sales trend
• Weekday / time-of-day की order pattern
• Delivery delay कितनी बार
• Stock-out ज़्यादा वाले products
• Order से shipment तक का समय
• Return या correction ज़्यादा वाले transactions

JIPDEC भी कहती है कि EDI data inventory allocation, production scheduling, inbound/outbound inspection, receivables booking जैसे रोज़ के काम के साथ best-seller analysis, spend analysis, demand forecasting जैसी management decisions की सामग्री बन सकता है। EDI से data इकट्ठा हो सकने की हालत बनाना सिर्फ efficiency नहीं — आगे inventory optimization और demand forecasting की शर्त भी है।

7. एक सादे उदाहरण से EDI का असर

मान लें एक wholesale company एक दिन में 100 orders FAX या email से लेती है, और एक order को sales management system में enter कर content चेक करने में औसत 3 मिनट लगते हैं।

100 orders × 3 मिनट = 300 मिनट → एक दिन में 5 घंटे

EDI के बाद 80 automatic import हों, बाकी 20 staff चेक करे, तो ऐसा बैठता है।

20 orders × 3 मिनट = 60 मिनट → एक दिन में 1 घंटा

Simplified उदाहरण है, लेकिन entry का काम 5 घंटे से 1 घंटा हो जाता है। असल में इसके ऊपर पढ़ने में मुश्किल FAX चेक करना, entry गलती सुधारना, order content पूछने वाली phone, purchase order ढूँढना, order list aggregate करना, staff के बीच handover — यह समय भी घट सकता है। EDI लगाने का असर “कागज़ का खर्च घटा” जैसे direct cost तक सीमित नहीं। रोज़ दोहराए जाने वाले छोटे check, entry, correction घटाना बड़ी बात है।

7.1. अपनी संख्याओं से हिसाब लगाएँ

ऊपर के 100 orders और 3 मिनट सिर्फ उदाहरण हैं। अपनी संख्याएँ रखकर हिसाब करें। चाहिए सिर्फ चार संख्याएँ।

(1) एक दिन के orders                       …… A orders
(2) एक order की entry और check का समय     …… B मिनट
(3) EDI से automatic process होने का अनुमान …… C %
(4) साल के working days                    …… D दिन

अभी लगने वाला समय        = A × B                    (मिनट/दिन)
EDI के बाद बचा समय         = A × (1 - C ÷ 100) × B    (मिनट/दिन)
एक दिन की बचत              = A × (C ÷ 100) × B        (मिनट/दिन)
एक साल की बचत              = एक दिन की बचत × D ÷ 60  (घंटे/साल)

(3) का “automatic process होने वाला हिस्सा” अगले अध्यायों वाले exceptions कितने हैं, उसी से तय होता है। शुरू से ऊँची संख्या मत रखें। पहले यह गिनें कि volume वाले कुछ top customers कुल का कितना % हैं। Customer-wise count अध्याय 11.1 की list बनाने से निकल आता है।

ध्यान रहे, इस हिसाब से निकलता समय की बचत है, सीधा बचने वाला staff cost नहीं। बचा समय कहाँ लगेगा (exception handling की quality बढ़ाना, दूसरा काम, overtime घटाना) — यह तय हो तब जाकर यह संख्या implementation के असर के रूप में समझाई जा सकती है।

8. विभाग के हिसाब से EDI के फायदे

EDI से होने वाला सुधार सिर्फ order-receiving department तक सीमित नहीं।

जानकारी कहाँ है, साफ़ हो जाता है, assigned staff के अलावा भी status देखना आसान होता है। इसलिए EDI सिर्फ entry effort नहीं, काम के एक व्यक्ति पर टिके रहने को भी घटाता है।

9. EDI लगा दिया तो सब automatic नहीं हो जाता

EDI सुविधा वाला mechanism है, लेकिन लगा देने भर से सारा काम automatic नहीं होता।

9.1. Trading partner से समझौता चाहिए

Companies के बीच data exchange के लिए कम से कम ये बातें तय करनी पड़ती हैं। कौन-सी जानकारी exchange होगी, कौन सा data format, कब send/receive, order change या cancellation कैसे सँभालें, error आए तो क्या करें, वही data दोबारा भेजा जाए तो क्या करें, और किस बिंदु पर order legally पूरा माना जाएगा।

इन समझौतों की परतें हैं। JIPDEC उन्हें पाँच में रखती है। “EDI लगाएँगे” वाली बात असल में किस परत की है, यह गड़बड़ा जाए तो चर्चा जुड़ती नहीं।

Products और services की तुलना ऊपरी दो परतों (communication protocol और syntax rules) पर अटकती है, लेकिन लगाने में मेहनत नीचे की तीन परतों में होती है। खास तौर पर “message और data items” अगले 9.2 वाला code alignment ही है। इसे trading partner से साफ़ किए बिना सिर्फ product चुन लिया तो बाद में काम दोहराना पड़ता है।

9.2. Product codes वगैरह एक लाइन पर लाने पड़ते हैं

Ordering company और receiving company में एक ही product के अलग codes हो सकते हैं। Ordering company में A-001, receiving company में 100245 — ऐसा। तब codes बदलने की mapping table चाहिए। Product code के अलावा ये items भी साफ़ करें।

• Customer code
• Ship-to code
• Unit
• Pack quantity
• Tax category
• Currency
• Date format
• Character encoding

Data send/receive हो जाए, fields का मतलब न मिले तो सही transaction नहीं बनता।

9.3. Exception handling बचता है

Routine orders automatic हो जाएँ, तब भी inventory कम, discontinued product, सामान्य से अलग price, rush order, order change, cancellation, partial delivery, return, data कमी — ये exceptional transactions रहते हैं।

ज़रूरी यह नहीं कि सब कुछ ज़बरदस्ती automatic हो। Routine और exception अलग करें, routine automatic हो, जहाँ फैसला चाहिए वही staff के पास जाए — यही realistic design है। अध्याय 6.1 वाले “staff को देखने वाले orders” यहीं के exceptions हैं।

9.4. FAX और email के साथ चलने का period आता है

सारे trading partners एक साथ EDI पर नहीं आ सकते। इसलिए शुरुआत में EDI, Web screen, CSV upload, email, FAX, phone — कई receiving methods साथ चल सकते हैं।

इस हालत में EDI लगा देने से पुराने काम वाले staff तुरंत कम नहीं होते। असर बढ़ाने के लिए volume वाले partners से क्रम से migrate करें, हाथ से सँभाले जाने वाले cases घटाते जाएँ। JIPDEC भी कहती है कि FAX और phone जैसा manual processing बचा रहे तो उसके लोग रखने पड़ते हैं, और efficiency का फायदा पूरा नहीं मिलता। अध्याय 7.1 के हिसाब में “automatic process वाला हिस्सा” कम रखकर चलने की वजह भी यही है।

10. EDI किन companies के लिए ठीक बैठता है

EDI खास तौर पर इन companies में असर दिखाता है।

• रोज़ या हर हफ़्ते उन्हीं trading partners से order आना-जाना
• Order count या line items ज़्यादा
• FAX या email से system में transcription हो रही हो
• Entry गलती या duplicate registration हो रही हो
• Order confirm करने वाली phone और email ज़्यादा हों
• Order के बाद inventory, shipping, billing चलता हो
• Assigned staff छुट्टी पर हो तो processing रुक जाए
• Order history या transaction status aggregate करने में समय लगे

दूसरी तरफ, साल में कुछ बार वाला partner, या हर बार order content बहुत अलग — वहाँ EDI बनाने-चलाने की cost असर से बड़ी हो सकती है।

EDI लगाना है या नहीं, यह सिर्फ company की size से नहीं तय होता। Small and Medium Enterprise Agency (Japan) ने SMEs के order processing को standard बनाने वाला “SME Common EDI” तैयार किया है, और specialized terminals तथा कागज़ घटाकर slips को data के रूप में एक जगह manage करने से efficiency दिखाती है। देखने वाली चीज़ headcount नहीं, बार-बार होने वाली entry, check, transcription की मात्रा है।

11. EDI सोचते समय आगे कैसे बढ़ें

EDI सोचते समय शुरू से product या communication method चुनने की ज़रूरत नहीं। पहले मौजूदा काम साफ़ करें।

11.1. मौजूदा order methods की list बनाएँ

हर trading partner पर यह जानकारी साफ़ करें।

यह साफ़ होते ही दिखता है कि EDI से असर किन partners या काम पर बड़ा होगा। अध्याय 7.1 के हिसाब में जाने वाले count और समय भी इसी table से निकलते हैं।

11.2. Volume वाले एक partner से शुरू करें

शुरू से सारे partners को दायरे में लेंगे तो coordinate करने वाली बातें बढ़ेंगी, rollout लंबा खिंच जाएगा। पहले ऐसा एक partner चुनना realistic है जो इन शर्तों पर बैठे।

• Transaction volume ज़्यादा
• Routine orders ज़्यादा
• दोनों तरफ staff से बात आसान
• System integration की समझ है
• असर मापना आसान है

एक partner पर operation पक्का हो, फिर बाकी पर फैलाएँ।

11.3. Exchange का दायरा छोटा रखें

शुरू से quotation, order receipt, shipping, inspection, billing, payment सब एक साथ लेने की ज़रूरत नहीं। उदाहरण: सबसे भारी entry वाले order data को पहले EDI करें, फिर चरणों में बढ़ाएँ।

1. Stage 1: Order data
2. Stage 2: Order confirmation / delivery-date response
3. Stage 3: Shipping notice
4. Stage 4: Billing data

दायरा चरणों में बढ़ाने से field पर असर सीमित रखते हुए असर देखा जा सकता है।

11.4. Internal system से connection चेक करें

EDI service लगा भी दें, existing sales management system में data import न हो तो manual entry बचती है। पहले ये बिंदु चेक करें।

• CSV का import/export है या नहीं
• API इस्तेमाल हो सकता है या नहीं
• Database से integration संभव है या नहीं
• Product code conversion कहाँ होगी
• Received data का duplicate कैसे रोकें
• Error की सूचना किसे जाए
• Processing history कहाँ रहे

Product चुनने से पहले existing system से जोड़ने का तरीका चेक करना ज़रूरी है। यहाँ “CSV import/export नहीं है”, “API नहीं है” निकल आए तो EDI service चुनने से पहले existing system की modification या एक intermediate layer तैयार करना आगे आता है।

12. EDI लगने के बाद मापने लायक metrics

EDI लग गया तो “अब चलता है” पर मत रुकें। काम कितना बदला, वह देखें। उदाहरण के लिए ये metrics implementation से पहले और बाद तुलना करें। अध्याय 7.1 के हिसाब की संख्याएँ ज्यों की त्यों measured values से बदल दें तो अनुमान और असल का फर्क भी दिख जाता है।

• Order entry में लगने वाला समय
• एक order process होने तक का समय
• Entry corrections की संख्या
• Duplicate registrations की संख्या
• Order confirm करने वाली queries की संख्या
• Shipping delay की संख्या
• EDI से process हुए orders का हिस्सा
• staff ने चेक किए exception orders का हिस्सा

EDI में ज़रूरी बात data भेज पाना नहीं है। Manual काम सच में घटा, processing तेज़ हुई, गलतियाँ घटीं — इसी से आँकें।

Summary

EDI वह mechanism है जिसमें companies के बीच निकलने वाली order, shipping, billing जानकारी computer के ज्यों की त्यों process कर सकने वाले electronic data के रूप में exchange होती है। FAX को email से बदल देने भर से कागज़ घट सकता है, लेकिन manual entry रह जाती है। EDI का असल असर यह है कि trading partner से मिला data sales management, inventory, shipping, accounting जैसे internal systems तक सीधे जुड़ सके।

EDI से अपेक्षित मुख्य बदलाव ये हैं।

• Purchase order देखकर होने वाली manual entry घटाना
• Transcription से होने वाली entry errors घटाना
• Order से shipment तक की processing तेज़ करना
• Order और invoice की processing status देखना आसान करना
• Inventory, shipping, sales, billing जोड़ना
• जमा trade data को aggregate और demand forecasting में इस्तेमाल करना
• एक व्यक्ति पर टिके काम को घटाना

लेकिन EDI service का contract भर काफी नहीं। Product codes जैसा data साफ़ करना, trading partners से operation rules तय करना, और existing internal system में data import हो सकना ज़रूरी है।

EDI लगाने की शुरुआत “कौन सा product” नहीं, मौजूदा काम में एक ही जानकारी कितनी बार enter हो रही है — यह देखना है। FAX, email, Excel, Web screen, sales management system के बीच जहाँ staff जानकारी ढो रहा है, वहाँ से volume ज़्यादा और routine काम को क्रम से data integration पर बदलना realistic है।

Order processing की data integration सोच रहे हैं

Companies के बीच order processing आसान करना है, लेकिन मौजूदा FAX, email, Excel को कहाँ से सुधारें साफ़ न हो, तो पहले काम का flow साफ़ करना पड़ता है।

Trading partner से जानकारी किस format में आती है, internal किस system में enter होती है, उसके बाद inventory, shipping, billing से कैसे जुड़ती है — यह देखने से automate हो सकने वाला दायरा दिखने लगता है।

KomuraSoft LLC पर existing Windows business apps, CSV और fixed-length files, database, Web systems समेत business integration की मौजूदा हालत साफ़ करने और realization के तरीके पर consult किया जा सकता है।

पूरी तरह rebuild मानकर नहीं चलना। मौजूदा setup रखते हुए सिर्फ manual entry वाला हिस्सा घटाने वाला ढाँचा भी देखा जा सकता है।

संदर्भ

• JIPDEC (Japan Information Economy and Society Promotion Association), EDI क्या है. EDI की परिभाषा (companies और administrative agencies computers को network से जोड़कर slips और documents को electronic data के रूप में automatic exchange करें), JIS X 7011 वाली परिभाषा, हर company के अपने format और standard format की आपसी conversion वाला mechanism, scanned image और सामान्य वाक्यों वाली email को EDI data से अलग मानना।
• JIPDEC, EDI के फायदे और EDI standard की ज़रूरत. Clerical काम की efficiency और गति, just-in-time delivery, lead time घटना, inventory घटना, human error हटाना, best-seller analysis, spend analysis और demand forecasting में इस्तेमाल, standard न मानें तो हर trading partner पर conversion mechanism चाहिए और cost नहीं बैठती, तय करने लायक पाँच बातें (communication protocol, syntax rules, message और data items, business operation rules, basic trading agreement), मिला data print कर हाथ से process करें तो FAX से बड़ा फर्क नहीं।
• Small and Medium Enterprise Agency (Japan), Order processing का digitalization (SME Common EDI). Order processing के digitalization से work efficiency, human error घटना, transaction records की searchability, और SMEs के order processing को standard बनाने वाले “SME Common EDI” की तैयारी।
• Digital Agency (Japan), JP PINT (electronic invoice की standard spec). Digital Agency जापान की Peppol Authority के रूप में Peppol network पर चलने वाली जापान की electronic invoice standard spec “JP PINT” manage और publish करती है।

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।