EDI কী? কোম্পানিগুলোর মধ্যে অর্ডার গ্রহণ-প্রদান কীভাবে সহজ হয় ── FAX, ইমেইল ও ম্যানুয়াল এন্ট্রি থেকে ডেটা ইন্টিগ্রেশনে

«ব্যবসায়িক অংশীদারের কাছ থেকে FAX-এ পারচেজ অর্ডার আসে, কর্মী সেলস ম্যানেজমেন্ট সিস্টেমে ইনপুট করেন» «ইমেইলে অ্যাটাচ করা Excel খুলে পণ্য কোড ও পরিমাণ দেখে কপি করে লেখেন» «ডেলিভারির পর ইনভয়েস বানিয়ে অন্য পক্ষও সেই বিষয় অ্যাকাউন্টিং সিস্টেমে ইনপুট করেন» ── কোম্পানি-কোম্পানি লেনদেনে একই অর্ডার তথ্য বা বিলিং তথ্য একাধিক কোম্পানি, একাধিক কর্মী বারবার ইনপুট করেন।

এই বারবার ইনপুট কমিয়ে অর্ডার দেওয়া, অর্ডার নেওয়া, শিপিং, বিলিং ইত্যাদি ডেটা কোম্পানির মধ্যে সরাসরি আদান-প্রদান করার ব্যবস্থাই EDI। EDI শুনলে বড় কোম্পানি ডেডিকেটেড লাইন দিয়ে চালু করা বড় সিস্টেম মনে হতে পারে, কিন্তু সার অনেক সরল। অংশীদারের কাছ থেকে আসা তথ্য মানুষ পড়ে আবার ইনপুট করেন না, কম্পিউটার সরাসরি প্রসেস করতে পারে এমন ডেটা হিসেবে বিনিময় করেন। এটুকুই।

এই নিবন্ধে EDI কী, FAX ও ইমেইলের সঙ্গে কী ফারাক, চালু করলে কোম্পানির কাজ কীভাবে সহজ হয় — অর্ডার গ্রহণ-প্রদানকে উদাহরণ ধরে সাজায়। পরিভাষা কম রাখব, তবে আগে এই চারটি ধরে রাখুন।

1. আগে উপসংহার

EDI হলো কোম্পানিগুলো পারচেজ অর্ডার, শিপিং নোটিস, ইনভয়েস ইত্যাদি লেনদেনের তথ্য আগে ঠিক করা ফরম্যাটের ইলেকট্রনিক ডেটা হিসেবে বিনিময় করার ব্যবস্থা।

Japan Information Economy and Society Promotion Association (JIPDEC) ইলেকট্রনিক কমার্স, তথ্য নিরাপত্তা, ব্যক্তিগত তথ্য সুরক্ষা ইত্যাদি ক্ষেত্রে স্ট্যান্ডার্ডাইজেশন ও প্রচার করে, এবং কোম্পানি কোড ও EDI নিয়ে তথ্য নিয়মিত প্রকাশ করে। এই নিবন্ধেও EDI-এর সংজ্ঞা ও ফল নিয়ে সেই সংস্থার ব্যাখ্যা দেখা যায়। JIPDEC-এর ব্যাখ্যা-তে EDI-কে «কোম্পানি বা প্রশাসনিক সংস্থা ইত্যাদি কম্পিউটার নেটওয়ার্কে জুড়ে স্লিপ ও নথি ইলেকট্রনিক ডেটা হিসেবে স্বয়ংক্রিয় বিনিময় করা» বলে বর্ণনা করা হয়েছে, সঙ্গে JIS X 7011-এর সংজ্ঞাও পরিচয় করানো হয়েছে।

EDI চালু করার উদ্দেশ্য শুধু কাগজ তুলে দেওয়া নয়। মূল উদ্দেশ্য এ ধরনের কাজ কমানো।

• FAX বা PDF দেখে ম্যানুয়াল এন্ট্রি
• Excel থেকে সেলস ম্যানেজমেন্ট সিস্টেমে ট্রান্সক্রিপশন
• ইনপুট করা বিষয় চোখে যাচাই
• পারচেজ অর্ডার বা ইনভয়েস খোঁজার কাজ
• অর্ডারের অবস্থা জানতে ফোন বা ইমেইল
• সেলস, ইনভেন্টরি, বিলিং ডেটা আবার সারাংশ করা

এক কথায়, EDI হলো কোম্পানি ও কোম্পানির মাঝে থেমে থাকা ডেটাকে সেভাবেই বইতে দেওয়ার ব্যবস্থা।

এই নিবন্ধের জ্ঞান মানচিত্র

EDI পারচেজ অর্ডার, শিপমেন্ট নোটিস, ইনভয়েসের মতো লেনদেনের তথ্য কোম্পানির মধ্যে আগে ঠিক করা ইলেকট্রনিক ডেটার ফরম্যাটে বিনিময় করে, মানুষের হাতে পুনঃইনপুটটাই তুলে দেওয়ার ব্যবস্থা। কপি করে ইনপুটের ভুল কমানো ও অর্ডার প্রক্রিয়া দ্রুত করার পাশাপাশি, পাওয়া ডেটা কোম্পানির ভিতরের স্টক · শিপমেন্ট · বিলিং সিস্টেম পর্যন্ত যুক্ত হলে তবেই ফল আসে; ইমপোর্ট না করে প্রিন্ট করে হাতে প্রক্রিয়া করলে FAX থেকে আলাদা নয়। ট্রেডিং পার্টনারভেদে আলাদা ফরম্যাট খরচ বাড়ায়, তাই স্ট্যান্ডার্ডভিত্তিক EDI বা SME কমন EDI বাস্তবসম্মত পছন্দ হয়। ডিজিটাল ইনভয়েস এই চিন্তা ইনভয়েস ক্ষেত্রে প্রয়োগের অনুশীলন, এবং চালু করার আগে বর্তমান অর্ডার দেওয়া-নেওয়ার পদ্ধতি ট্রেডিং পার্টনারভেদে তালিকা করা পণ্য বাছাইয়ের চেয়ে আগে আসে।

flowchart LR
    accTitle: EDI দিয়ে কোম্পানির মধ্যে ডেটা বিনিময়ের জ্ঞান মানচিত্র
    accDescr: EDI কীভাবে ম্যানুয়াল পুনঃইনপুট ও কপি করে ইনপুটের ভুল আটকায় এবং অর্ডার প্রক্রিয়াকরণ ও স্টক · শিপমেন্ট · বিলিং সংযোগ কীভাবে স্বয়ংক্রিয় করে, স্ট্যান্ডার্ড ফরম্যাট ও SME কমন EDI প্রতি অংশীদারের আলাদা ফরম্যাটের সমস্যার কী জবাব দেয়, ডিজিটাল ইনভয়েস এই চিন্তা বিলিং ক্ষেত্রে কীভাবে প্রয়োগ করে—এই সম্পর্ক দেখানো চিত্র
    edi["EDI (ইলেকট্রনিক ডেটা বিনিময়)"]
    manual_reentry["পাওয়া তথ্যের ম্যানুয়াল পুনঃইনপুট"]
    transcription_error["কপি করে ইনপুটের ভুল"]
    order_processing_lead_time["অর্ডার প্রক্রিয়াকরণের lead time"]
    trading_partner_agreement["ট্রেডিং পার্টনারের সাথে EDI চুক্তি"]
    master_code_alignment["পণ্য কোডসহ মাস্টার সামঞ্জস্য"]
    order_to_cash_integration["অর্ডারের পর স্টক, শিপমেন্ট, বিলিং সংযোগ"]
    edi_standard_format["স্ট্যান্ডার্ডভিত্তিক EDI"]
    edi_individual_format["প্রতি অংশীদারের আলাদা EDI"]
    sme_common_edi["SME কমন EDI"]
    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

চিত্রে, টানা রেখা সবসময় সত্য এমন সম্পর্ককে এবং ভাঙা রেখা শর্তসাপেক্ষ সম্পর্ককে নির্দেশ করে (শর্তগুলো বিস্তারিত পাতায় প্রতিটি সম্পর্কের ব্যাখ্যায় আছে)। সম্পর্কের সম্পূর্ণ তালিকা (মোট 17, প্রমাণ ও নিশ্চয়তার মাত্রাসহ) এবং প্রধান ধারণাগুলোর সংজ্ঞা জ্ঞান মানচিত্রের বিস্তারিত পাতায় সংগ্রহ করা আছে (জাপানি ভাষায়)। তথ্য: 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 না থাকলে অর্ডার গ্রহণ-প্রদানের ধারা। ডেটা দুবার মানুষের হাত দিয়ে আবার ইনপুট হচ্ছে

এই ধারায় পণ্য কোড, পণ্যের নাম, পরিমাণ, ইউনিট প্রাইস, ডেলিভারি তারিখ, ডেলিভারি গন্তব্য — একই তথ্য বারবার ইনপুট হয়। প্রথম অর্ডার ডেটা ইতিমধ্যে অর্ডার দেওয়া পক্ষের কম্পিউটারে আছে, তবু কাগজ বা PDF-এ বদলানোর ফলে গ্রহণকারী পক্ষে মানুষ আবার পড়ে কম্পিউটারে ইনপুট করেন।

সমস্যা তথ্য ইলেকট্রনিক না হওয়া নয়। একবার ডেটা হিসেবে তৈরি তথ্য মানুষ পড়ার নথিতে বদলে অন্য পক্ষে আবার ডেটায় ফেরানো।

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. পণ্য কোড আছে কি না যাচাই করা
3. ইনভেন্টরি অ্যালোকেট করা
4. ডেলিভারি তারিখ হিসাব করা
5. গুদামে শিপিং নির্দেশ পাঠানো
6. অর্ডার দেওয়া পক্ষে অর্ডার কনফার্মেশন ফেরানো

শিপিংয়ের পর শিপিং রেকর্ড থেকে সেলস ধরে বিলিং ডেটাও বানানো যায়। অর্থাৎ EDI শুধু যোগাযোগের ফিচার নয়, অর্ডার গ্রহণ-প্রদানকে প্রবেশপথ ধরে তার পরের ইনভেন্টরি, শিপিং, সেলস, বিলিং পর্যন্ত জোড়ার ভিত্তি।

6. EDI কোম্পানির কাজ কীভাবে সহজ করে

অধ্যায় 2 থেকে 4 পর্যন্ত দেখা গেছে, EDI-এর সরাসরি ফল «পারচেজ অর্ডার দেখে ম্যানুয়াল এন্ট্রি না থাকা»। এই অধ্যায়ে তার পর কী হয় ছয় ভাগে সাজায়। ফল শুধু ইনপুটের ঘণ্টা কমানো নয়।

6.1. কর্মীর সময় ব্যতিক্রম সামলানোয় সরানো যায়

ম্যানুয়াল এন্ট্রি না থাকলে কর্মীর সময়ের ব্যবহার বদলায়। সব অর্ডার মানুষ প্রসেস করেন না, সাধারণ অর্ডার স্বয়ংক্রিয় প্রসেস হয়, বিচার লাগে শুধু সেগুলো মানুষ দেখেন — এই রূপ দাঁড় করানো যায়। মানুষের দেখা উচিত উদাহরণস্বরূপ এ ধরনের অর্ডার।

• ইনভেন্টরি কম এমন অর্ডার
• সাধারণের চেয়ে আলাদা ডেলিভারি তারিখের অর্ডার
• পণ্য কোড নিবন্ধিত নেই এমন অর্ডার
• বড় অর্ডার
• ইউনিট প্রাইস বা চুক্তির শর্ত যাচাই লাগে এমন অর্ডার

ইনপুটে ছুটে থাকলে এই যাচাই পিছিয়ে যায়। EDI-এর মূল্য «কাজ কমে»র চেয়ে «কমে যাওয়া সময় সেই অর্ডারে লাগানো যায় যেখানে সত্যি নজর দিতে হয়»তে।

6.2. ইনপুট ত্রুটি কমানো যায়

মানুষ ইনপুট করলে একটা সম্ভাবনায় ভুল হয়ই। পণ্য কোড এক অঙ্ক ভুল, পরিমাণ 10 না লিখে 100, ডেলিভারি গন্তব্য গুলিয়ে যাওয়া, কাঙ্ক্ষিত ডেলিভারি তারিখ ভুল পড়া, একই অর্ডার দুবার নিবন্ধন — এই ধরনের ভুল।

EDI-তেও মূল ডেটা নিজে ভুল হলে সমস্যা হয়। তবে ঠিক বানানো ডেটা অন্য পক্ষে আবার ইনপুট করতে হয় না, তাই ট্রান্সক্রিপশনের ধাপে যে ত্রুটি ওঠে তা কমে। Small and Medium Enterprise Agencyও অর্ডার গ্রহণ-প্রদানের ডিজিটালাইজেশনের ফল হিসেবে কাজের দক্ষতা বাড়া, মানুষের ত্রুটি কমা, লেনদেনের রেকর্ড খোঁজা সহজ হওয়াকে তুলে ধরে।

6.3. অর্ডার প্রসেসিং তাড়াতাড়ি করা যায়

FAX বা ইমেইলে কর্মী পাওয়া টের পেয়ে বিষয় দেখে ইনপুট শেষ না করা পর্যন্ত অর্ডার প্রসেসিং শুরু হয় না। অর্ডার বেশি দিনে ইনপুটের অপেক্ষা জমে, কর্মী ছুটিতে থাকলে প্রসেসিং পিছিয়ে যায়।

EDI-তে পাওয়া ডেটা স্বয়ংক্রিয়ভাবে সিস্টেমে ইমপোর্ট করা যায়, তাই অর্ডার পাওয়ার সঙ্গে সঙ্গে অর্ডার গ্রহণ, ইনভেন্টরি যাচাই, ডেলিভারি তারিখ হিসাব, গুদামে শিপিং নির্দেশ, অর্ডার কনফার্মেশন ফেরানো — এই প্রসেসিং শুরু করা যায়। অর্ডার প্রসেসিং তাড়াতাড়ি হলে শিপিং পর্যন্ত সময়ও ছোট করা সহজ হয়। JIPDECও EDI-এর ফল হিসেবে অফিসের কাজের দক্ষতা ও গতি, just-in-time ডেলিভারি, লিড টাইম ছোট করা, ইনভেন্টরি কমানো ইত্যাদি তুলে ধরে।

6.4. অর্ডারের অবস্থা দেখা সহজ হয়

কাগজ, FAX, ইমেইল, Excel মিশে থাকলে «সেই অর্ডার এখন কী অবস্থায়» খুঁজতে সময় লাগে। কর্মীর ইনবক্স, শেয়ারড ফোল্ডার, কাগজের ফাইল, সেলস ম্যানেজমেন্ট সিস্টেম ক্রমে দেখতে হয়।

EDI-তে অর্ডার নম্বর ইত্যাদি ধরে পরের তথ্য বেঁধে রাখা যায়।

• কখন অর্ডার পেয়েছেন
• ঠিকমতো ইমপোর্ট হয়েছে কি না
• অর্ডার কনফার্মেশন ফেরানো হয়েছে কি না
• শিপ হয়ে গেছে কি না
• গ্রহণ যাচাই হয়েছে কি না
• বিল হয়েছে কি না
• ত্রুটি বা আবার পাঠানো হয়েছে কি না

জিজ্ঞাসা এলেও কর্মীর স্মৃতি বা ব্যক্তিগত ইমেইলের উপর না ভর করে প্রসেসিং ইতিহাস থেকে দেখা যায়।

6.5. ইনভেন্টরি, শিপিং, অ্যাকাউন্টিংয়ের সঙ্গে জোড়া যায়

পাওয়া ডেটা ভিতরের সিস্টেমের সঙ্গে জোড়ালে অর্ডার নিবন্ধনের পরের ধাপও অটোমেট করা যায়।

flowchart TD
    accTitle: পাওয়া অর্ডার ডেটার ভিতরের পরবর্তী ধাপ
    accDescr: অর্ডার ডেটা গ্রহণ থেকে অর্ডার নিবন্ধন, ইনভেন্টরি অ্যালোকেশন, শিপিং নির্দেশ, সেলস booking, বিলিং ডেটা তৈরি, পেমেন্ট reconciliation পর্যন্ত ধাপ দেখানো হয়েছে
    A["অর্ডার ডেটা গ্রহণ"] --> B["অর্ডার নিবন্ধন"]
    B --> C["ইনভেন্টরি অ্যালোকেশন"]
    C --> D["শিপিং নির্দেশ"]
    D --> E["সেলস booking"]
    E --> F["বিলিং ডেটা তৈরি"]
    F --> G["পেমেন্ট reconciliation"]

চিত্র 3: পাওয়া অর্ডার ডেটা ভিতরে যে ধাপগুলো পেরোয়। কতদূর জোড়াবেন তাতে চালু করার ফল ঠিক হয়

উল্টোদিকে EDI-তে অর্ডার ডেটা পেয়েও সেটা প্রিন্ট করে মানুষ সেলস ম্যানেজমেন্ট সিস্টেমে ইনপুট করলে ফল সীমিত। JIPDECও বলে, EDI-তে পাওয়া ডেটা ভিতরের সিস্টেমে ইমপোর্ট না করে প্রিন্ট করে হাতে প্রসেস করলে FAX থেকে বড় ফারাক থাকে না। EDI শুধু অংশীদারের সঙ্গে যোগাযোগ চালু করা নয়, পাওয়া ডেটা ভিতরের কাজের কতদূর পর্যন্ত বইবে সেটা জরুরি।

6.6. লেনদেনের ডেটা ব্যবস্থাপনার সিদ্ধান্তে লাগে

কাগজ বা PDF-এ পাওয়া পারচেজ অর্ডার রাখা থাকলেও সারাংশ করা কঠিন। EDI-তে লেনদেনের তথ্য স্ট্রাকচার্ড ডেটা হিসেবে জমে, তাই এ ধরনের বিশ্লেষণে নিয়ে যাওয়া যায়।

• পণ্যভেদে অর্ডার পরিমাণ
• অংশীদারভেদে সেলসের ধারা
• সপ্তাহের দিন ও সময় অনুযায়ী অর্ডারের প্রবণতা
• ডেলিভারি দেরির অবস্থা
• স্টকআউট বেশি এমন পণ্য
• অর্ডার থেকে শিপিং পর্যন্ত সময়
• রিটার্ন বা সংশোধন বেশি এমন লেনদেন

JIPDECও বলে, EDI ডেটা ইনভেন্টরি অ্যালোকেশন, প্রোডাকশন অ্যারেঞ্জমেন্ট, রিসিভিং ও শিপিং ইনস্পেকশন, অ্যাকাউন্টস রিসিভেবল posting-এর মতো দৈনন্দিন কাজের সঙ্গে বেস্ট-সেলার বিশ্লেষণ, spend analysis, ডিমান্ড ফোরকাস্টের মতো ব্যবস্থাপনার সিদ্ধান্তের উপকরণ হিসেবেও ব্যবহার করা যায়। EDI দিয়ে ডেটা জমা হওয়ার অবস্থা বানানো শুধু কার্যদক্ষতা নয়, ভবিষ্যতের ইনভেন্টরি অপটিমাইজেশন ও ডিমান্ড ফোরকাস্টের ভিত্তিও।

7. সরল উদাহরণে EDI-এর ফল ভাবা

ধরা যাক এক হোলসেল কোম্পানি দিনে 100টি অর্ডার FAX বা ইমেইলে পায়, এক অর্ডার সেলস ম্যানেজমেন্ট সিস্টেমে ইনপুট করে বিষয় যাচাই করতে গড়ে 3 মিনিট লাগে।

100টি × 3 মিনিট = 300 মিনিট → দিনে 5 ঘণ্টা

EDI চালুর পর 80টি স্বয়ংক্রিয় ইমপোর্ট হয়, বাকি 20টি শুধু মানুষ দেখেন — ধরলে এমন দাঁড়ায়।

20টি × 3 মিনিট = 60 মিনিট → দিনে 1 ঘণ্টা

সরল উদাহরণ, কিন্তু ইনপুটের কাজ 5 ঘণ্টা থেকে 1 ঘণ্টা হয়। বাস্তবে এর সঙ্গে পড়া কঠিন 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 চালাব» আলোচনা আসলে কোন স্তরের কথা তা গুলিয়ে ফেললে কথা মিলে না।

প্রোডাক্ট বা সার্ভিস তুলনা উপরের দুই স্তরে (কমিউনিকেশন প্রোটোকল ও সিনট্যাক্স রুল) ঝুঁকে পড়ে, কিন্তু চালু করতে কষ্ট হয় নিচের তিন স্তরে। বিশেষ করে «মেসেজ ও ডেটা আইটেম» পরের 9.2-এ আসা কোড গোছানোই, এটা অংশীদারের সঙ্গে না মিলিয়ে শুধু প্রোডাক্ট ঠিক করলে পরে ফিরে আসতে হয়।

9.2. পণ্য কোড ইত্যাদি মিলিয়ে রাখতে হয়

অর্ডার দেওয়া পক্ষ ও গ্রহণকারী পক্ষে একই পণ্যে আলাদা কোড ব্যবহার হতে পারে। অর্ডার দেওয়া পক্ষে পণ্য কোড A-001, গ্রহণকারী পক্ষে 100245 — এমন কেস। তখন কোড বদলানোর মিল সারণি লাগে। পণ্য কোড ছাড়াও এ ধরনের ফিল্ড সাজাতে হয়।

• অংশীদার কোড
• ডেলিভারি গন্তব্য কোড
• ইউনিট
• প্যাক কোয়ান্টিটি
• ট্যাক্স ক্যাটাগরি
• মুদ্রা
• তারিখের ফরম্যাট
• ক্যারেক্টার এনকোডিং

ডেটা পাঠানো-নেওয়া গেলেও ফিল্ডের অর্থ না মিললে ঠিক লেনদেন হয় না।

9.3. ব্যতিক্রম সামলানো থেকে যায়

সাধারণ অর্ডার স্বয়ংক্রিয় প্রসেস গেলেও ইনভেন্টরি কম, ডিসকন্টিনিউ পণ্য, সাধারণের চেয়ে আলাদা দাম, জরুরি অর্ডার, অর্ডার বদল, অর্ডার বাতিল, আংশিক ডেলিভারি, রিটার্ন, ডেটার ঘাটতি — এ ধরনের ব্যতিক্রম লেনদেন থেকে যায়।

জরুরি কথা সব জোর করে অটোমেট করা নয়। সাধারণ প্রসেসিং ও ব্যতিক্রম প্রসেসিং আলাদা করে সাধারণ প্রসেসিং অটোমেট করা, বিচার লাগে শুধু সেগুলো মানুষের কাছে পাঠানো নকশাই বাস্তব। অধ্যায় 6.1-এ বলা «মানুষের দেখা উচিত অর্ডার» এখানকার ব্যতিক্রমই।

9.4. FAX ও ইমেইলের সঙ্গে পাশাপাশি চলার সময় আসে

সব অংশীদার একসঙ্গে EDI-তে যেতে পারেন না। তাই চালুর শুরুতে EDI, Web স্ক্রিন, CSV আপলোড, ইমেইল, FAX, ফোন — একাধিক গ্রহণ পদ্ধতি পাশাপাশি চলতে পারে।

এই অবস্থায় EDI চালু করলেও আগের কাজের কর্মী সঙ্গে সঙ্গে কমানো যায় না। ফল বাড়াতে লেনদেনের পরিমাণ বেশি অংশীদার থেকে ক্রমে সরাতে হয়, হাতে সামলানো সংখ্যা কমাতে হয়। JIPDECও বলে, FAX বা ফোনের মতো হাতে করা কাজ থেকে গেলে সেই কাজ সামলানোর লোক লাগে, দক্ষতার ফল পুরোপুরি পাওয়া কঠিন। অধ্যায় 7.1-এর হিসাবে «স্বয়ংক্রিয় প্রসেস হতে পারে এমন অনুপাত» কম রেখে শুরু করার কারণও এখানে।

10. EDI যে কোম্পানিতে মানায়

EDI বিশেষ করে এ ধরনের কোম্পানিতে ফল বেশি দেয়।

• প্রতিদিন বা প্রতি সপ্তাহে একই অংশীদারের সঙ্গে অর্ডার গ্রহণ-প্রদান হয়
• অর্ডার সংখ্যা বা লাইনের সংখ্যা বেশি
• FAX বা ইমেইল থেকে সিস্টেমে ট্রান্সক্রিপশন হয়
• ইনপুট ভুল বা ডুপ্লিকেট নিবন্ধন হয়
• অর্ডার যাচাইয়ের ফোন বা ইমেইল বেশি
• অর্ডার নেওয়ার পর ইনভেন্টরি, শিপিং, বিলিংয়ের প্রসেসিং চলে
• কর্মী ছুটিতে থাকলে প্রসেসিং থেমে যায়
• অর্ডার ইতিহাস বা লেনদেনের অবস্থার সারাংশ করতে সময় লাগে

অন্যদিকে বছরে কয়েকবার মাত্র লেনদেন হয় এমন পক্ষ বা প্রতিবার অর্ডারের বিষয় বড় করে বদলায় এমন লেনদেনে EDI গড়ে তোলা ও চালানোর খরচ ফল ছাড়িয়ে যেতে পারে।

EDI চালাবেন কি না কোম্পানির আকার দিয়েই ঠিক হয় না। Small and Medium Enterprise Agencyও ছোট ও মাঝারি উদ্যোগের অর্ডার গ্রহণ-প্রদান স্ট্যান্ডার্ড করার «SME Common EDI» তৈরি করেছে, এবং বিশেষ টার্মিনাল ও কাগজ কমিয়ে স্লিপ ডেটা হিসেবে এক জায়গায় রাখার দক্ষতা দেখিয়েছে। দেখার বিষয় কর্মীর সংখ্যা নয়, বারবার হওয়া ইনপুট, যাচাই, ট্রান্সক্রিপশনের পরিমাণ।

11. EDI চালু বিবেচনা করার সময় এগোনোর পথ

EDI বিবেচনা করতে শুরুতেই প্রোডাক্ট বা কমিউনিকেশন পদ্ধতি বেছে নেওয়া দরকার নেই। আগে এখনকার কাজ সাজান।

11.1. এখনকার অর্ডার গ্রহণ-প্রদানের পদ্ধতি তালিকা করুন

অংশীদারভেদে এই তথ্য সাজান।

এই সাজানোতে EDI করলে ফল বেশি যে অংশীদার বা কাজ সেগুলো দেখা যায়। অধ্যায় 7.1-এর হিসাবে বসানো সংখ্যা ও সময়ও এই সারণি থেকে নেওয়া যায়।

11.2. লেনদেনের পরিমাণ বেশি এক কোম্পানি থেকে শুরু করুন

শুরুতেই সব অংশীদার লক্ষ্য করলে মিলানোর বিষয় বাড়ে, চালু লম্বা হয়। আগে এই শর্তে মিলে এমন অংশীদার এক কোম্পানি বেছে নেওয়াই বাস্তব।

• লেনদেনের সংখ্যা বেশি
• নিয়মিত অর্ডার বেশি
• কর্মীদের যোগাযোগ সহজ
• সিস্টেম ইন্টিগ্রেশনের বোঝাপড়া আছে
• প্রভাব মাপা সহজ

এক কোম্পানিতে অপারেশন দাঁড় করিয়ে তারপর অন্য অংশীদারে বাড়ান।

11.3. বিনিময়ের বিষয় সীমাবদ্ধ করুন

শুরুতেই কোটেশন, অর্ডার গ্রহণ, শিপিং, গ্রহণ যাচাই, বিলিং, পেমেন্ট সব লক্ষ্য করা দরকার নেই। উদাহরণ: ইনপুটের বোঝা সবচেয়ে বেশি অর্ডার ডেটা আগে EDI করে এভাবে ধাপে ধাপে বাড়ানো যায়।

1. প্রথম ধাপ: অর্ডার ডেটা
2. দ্বিতীয় ধাপ: অর্ডার কনফার্মেশন ও ডেলিভারি তারিখের উত্তর
3. তৃতীয় ধাপ: শিপিং নোটিস
4. চতুর্থ ধাপ: বিলিং ডেটা

ধাপে ধাপে বিষয় বাড়ালে মাঠে প্রভাব চাপা রেখে ফল দেখা যায়।

11.4. ভিতরের সিস্টেমের সঙ্গে সংযোগ যাচাই করুন

EDI সার্ভিস চালু করলেও বিদ্যমান সেলস ম্যানেজমেন্ট সিস্টেমে ডেটা ইমপোর্ট না গেলে ম্যানুয়াল এন্ট্রি থেকে যায়। আগে এগুলো যাচাই করুন।

• CSV ইনপুট-আউটপুট ফিচার আছে কি না
• API ব্যবহার করা যায় কি না
• ডেটাবেসের সঙ্গে ইন্টিগ্রেশন সম্ভব কি না
• পণ্য কোড রূপান্তর কোথায় হবে
• পাওয়া ডেটার ডুপ্লিকেট কীভাবে ঠেকাবেন
• ত্রুটি কাকে জানাবেন
• প্রসেসিং ইতিহাস কোথায় রাখবেন

প্রোডাক্ট বাছাইয়ের আগে বিদ্যমান সিস্টেমের সঙ্গে সংযোগের উপায় যাচাই করা জরুরি। এখানে «CSV ইনপুট-আউটপুট নেই» «API নেই» জানা গেলে EDI সার্ভিস বাছাইয়ের আগে বিদ্যমান সিস্টেম পক্ষের সংশোধন বা মধ্যবর্তী ব্যবস্থা রাখা আগে আসে।

12. EDI চালুর পর মাপতে চাওয়া সূচক

EDI চালু করলে «ব্যবহার করা যাচ্ছে»তে থেমে না থেকে কাজ কতটা বদলেছে দেখুন। উদাহরণস্বরূপ এই সূচক চালুর আগে-পরে তুলনা করুন। অধ্যায় 7.1-এর হিসাবের সংখ্যা সরাসরি মাপা মানে বদলালে ধারণা ও বাস্তবের ফারাকও সেভাবে দেখা যায়।

• অর্ডার ইনপুটে যে সময় লাগে
• এক অর্ডার প্রসেস হতে যে সময় লাগে
• ইনপুট সংশোধনের সংখ্যা
• ডুপ্লিকেট নিবন্ধনের সংখ্যা
• অর্ডার যাচাইয়ের জিজ্ঞাসার সংখ্যা
• শিপিং দেরির সংখ্যা
• EDI-তে প্রসেস হওয়া অর্ডারের অনুপাত
• মানুষ যাচাই করা ব্যতিক্রম অর্ডারের অনুপাত

EDI-তে জরুরি ডেটা পাঠানো যায় কি না নয়। হাতে করা কাজ সত্যি কমেছে, প্রসেসিং তাড়াতাড়ি হয়েছে, ভুল কমেছে কি না দিয়ে মূল্যায়ন করুন।

সারসংক্ষেপ

EDI হলো কোম্পানির মধ্যে ওঠা অর্ডার, শিপিং, বিলিং ইত্যাদি তথ্য কম্পিউটার সরাসরি প্রসেস করতে পারে এমন ইলেকট্রনিক ডেটা হিসেবে বিনিময় করার ব্যবস্থা। FAX-কে ইমেইলে বদলালে কাগজ কমতে পারে, ম্যানুয়াল এন্ট্রি থেকে যেতে পারে। EDI-এর আসল ফল অংশীদারের কাছ থেকে পাওয়া ডেটা সেলস ম্যানেজমেন্ট, ইনভেন্টরি, শিপিং, অ্যাকাউন্টিং ইত্যাদি ভিতরের সিস্টেমে সরাসরি জোড়া যায় তাতে।

EDI থেকে যা আশা করা যায় মূল বদল এগুলো।

• পারচেজ অর্ডার দেখে ম্যানুয়াল এন্ট্রি কমানো
• ট্রান্সক্রিপশন থেকে ইনপুট ত্রুটি কমানো
• অর্ডার গ্রহণ থেকে শিপিং পর্যন্ত প্রসেসিং তাড়াতাড়ি করা
• অর্ডার ও বিলিংয়ের প্রসেসিংয়ের অবস্থা দেখা সহজ করা
• ইনভেন্টরি, শিপিং, সেলস, বিলিং জোড়া
• জমে থাকা লেনদেনের ডেটা সারাংশ ও ডিমান্ড ফোরকাস্টে লাগানো
• কর্মী ব্যক্তির উপর নির্ভর করা কাজ কমানো

তবে EDI সার্ভিস চুক্তি করলেই যথেষ্ট নয়। পণ্য কোড ইত্যাদি ডেটা গোছাতে হয়, অংশীদারের সঙ্গে অপারেশন নিয়ম ঠিক করতে হয়, বিদ্যমান ভিতরের সিস্টেমে ডেটা ইমপোর্ট করা যায় এমন করতে হয়।

EDI চালুর শুরু «কোন প্রোডাক্ট ব্যবহার করবেন» নয়, এখনকার কাজে একই তথ্য কতবার ইনপুট হয় তা দেখা। FAX, ইমেইল, Excel, Web স্ক্রিন, সেলস ম্যানেজমেন্ট সিস্টেমের মধ্যে মানুষ তথ্য বয়ে নিয়ে যাচ্ছেন যে জায়গাগুলো, সেখান থেকে সংখ্যা বেশি ও নিয়মিত কাজ ক্রমে ডেটা ইন্টিগ্রেশনে বদলানোই বাস্তব।

অর্ডার গ্রহণ-প্রদানের ডেটা ইন্টিগ্রেশন বিবেচনা করছেন

কোম্পানিগুলোর মধ্যে অর্ডার গ্রহণ-প্রদান দক্ষ করতে চাইলেও এখনকার FAX, ইমেইল, Excel অপারেশন কোথা থেকে আবার সাজাবেন বুঝতে না পারলে আগে কাজের ধারা সাজাতে হয়।

অংশীদারের কাছ থেকে কোন ফরম্যাটে তথ্য আসে, ভিতরের কোন সিস্টেমে ইনপুট হয়, তার পর ইনভেন্টরি, শিপিং, বিলিংয়ের সঙ্গে কীভাবে জোড়া — এগুলো দেখলে অটোমেট করা যায় এমন পরিসর দেখা যায়।

KomuraSoft LLC-তে বিদ্যমান Windows ব্যবসায়িক অ্যাপ, CSV ও ফিক্সড-লেংথ ফাইল, ডেটাবেস, Web সিস্টেম ইত্যাদিসহ ব্যবসায়িক ইন্টিগ্রেশন নিয়ে বর্তমান অবস্থা সাজানো ও বাস্তবায়নের পথ বিবেচনায় পরামর্শ নেওয়া যায়।

পুরো সিস্টেম পাল্টে ফেলার ধরে না নিয়ে এখনকার ব্যবস্থা রেখে শুধু ম্যানুয়াল এন্ট্রির অংশ কমানোর গঠনও বিবেচনা করা যায়।

তথ্যসূত্র

• JIPDEC (Japan Information Economy and Society Promotion Association), EDI কী. EDI-এর সংজ্ঞা (কোম্পানি বা প্রশাসনিক সংস্থা ইত্যাদি কম্পিউটার নেটওয়ার্কে জুড়ে স্লিপ ও নথি ইলেকট্রনিক ডেটা হিসেবে স্বয়ংক্রিয় বিনিময় করা), JIS X 7011-এর সংজ্ঞা, প্রতি কোম্পানির নিজস্ব ফরম্যাট ও স্ট্যান্ডার্ড ফরম্যাটের পারস্পরিক রূপান্তরের ব্যবস্থা, স্ক্যান করা ছবি বা সাধারণ বাক্যের ইমেইল EDI ডেটা থেকে আলাদা হওয়া নিয়ে।
• JIPDEC, EDI-এর সুবিধা ও EDI স্ট্যান্ডার্ডের প্রয়োজন. অফিসের কাজের দক্ষতা ও গতি, just-in-time ডেলিভারি, লিড টাইম ছোট করা, ইনভেন্টরি কমানো, মানুষের ত্রুটি সরানো, বেস্ট-সেলার বিশ্লেষণ, spend analysis ও ডিমান্ড ফোরকাস্টে ব্যবহার, স্ট্যান্ডার্ড না মানলে অংশীদারভেদে রূপান্তরের ব্যবস্থা লাগে ও খরচ মেলে না, চুক্তি লাগে এমন পাঁচ বিষয় (কমিউনিকেশন প্রোটোকল, সিনট্যাক্স রুল, মেসেজ ও ডেটা আইটেম, অপারেশন চুক্তি, লেনদেনের মূল চুক্তি), পাওয়া ডেটা প্রিন্ট করে হাতে প্রসেস করলে FAX থেকে বড় ফারাক না থাকা নিয়ে।
• Small and Medium Enterprise Agency, অর্ডার গ্রহণ-প্রদানের ডিজিটালাইজেশন (SME Common EDI). অর্ডার গ্রহণ-প্রদানের ডিজিটালাইজেশনে কাজের দক্ষতা বাড়া, মানুষের ত্রুটি কমা, লেনদেনের রেকর্ড খোঁজা সহজ হওয়া, ছোট ও মাঝারি উদ্যোগের অর্ডার গ্রহণ-প্রদান স্ট্যান্ডার্ড করার «SME Common EDI» তৈরি নিয়ে।
• Digital Agency, JP PINT (ইলেকট্রনিক ইনভয়েসের স্ট্যান্ডার্ড স্পেসিফিকেশন). Digital Agency জাপানের Peppol Authority হিসেবে Peppol নেটওয়ার্কে আদান-প্রদান হওয়া জাপানের ইলেকট্রনিক ইনভয়েস স্ট্যান্ডার্ড স্পেসিফিকেশন «JP PINT» পরিচালনা ও প্রকাশ করে নিয়ে।

সম্পর্কিত নিবন্ধ

কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।

সম্পর্কিত বিষয়

এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।

এই বিষয়ের সাথে সম্পর্কিত সেবা

নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।

লেখকের প্রোফাইল

নিবন্ধের লেখকের পরিচিতি পৃষ্ঠা।

Go Komura

KomuraSoft LLC-এর প্রতিনিধি

Windows সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।