FAX অর্ডার Web-এ সরাতে হলে ── দ্বৈত পরিচালনার সময়কালের নকশা ও ধাপে ধাপে মাইগ্রেশন

আগের নিবন্ধ «EDI কী? কোম্পানিগুলোর মধ্যে অর্ডার গ্রহণ-প্রদান কীভাবে সহজ হয়»-এ FAX বা ইমেইলে পাওয়া অর্ডার মানুষ আবার ইনপুট করে সেই কাজকে সিস্টেম-সিস্টেম ডেটা বিনিময়ে বদলানোর ব্যবস্থা সাজিয়েছিলাম।

এই নিবন্ধ তার পরের পর্ব। বিষয় «ব্যবস্থা বোঝা» থেকে এক ধাপ এগিয়ে কীভাবে মাইগ্রেট করবেন।

«FAX অর্ডার Web-এ নিতে চাই» অনুরোধ সাধারণত এভাবেই চলতে থাকে।

«তবে এমন ব্যবসায়িক অংশীদার আছে যারা শুধু FAX ব্যবহার করতে পারে»

«সেলস ম্যানেজমেন্ট সিস্টেম এখন যেমন আছে তেমনই রাখতে চাই»

«সুইচওভারের সময় অর্ডার থেমে গেলে সমস্যা»

অর্থাৎ ব্যবহারিক চ্যালেঞ্জ Web অর্ডার সিস্টেম বানানো নয়। FAX থেকে যাওয়া অবস্থায় Web-এ ধাপে ধাপে সরানোর সময়কাল কীভাবে নকশা করবেন সেটাই।

এই নিবন্ধ FAX অর্ডারের Web রূপান্তরকে চারটি কেন্দ্রে সাজায়: দ্বৈত পরিচালনার সময়কালের নকশা, মধ্যবর্তী রূপ হিসেবে CSV ইমপোর্ট, পণ্য ও ব্যবসায়িক অংশীদারের মাস্টার ডেটা প্রস্তুতি, এবং অংশীদারদের সাথে নেওয়ার উপায়।

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

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

FAX অর্ডারের Web রূপান্তর পরিকল্পনা করার সময় মূল কথাগুলো এগুলো।

• লক্ষ্য «FAX বন্ধ করা» নয়, «যে অর্ডার মানুষ ইনপুট করেন তার সংখ্যা কমানো»তে রাখুন
• FAX ও Web-এর দ্বৈত পরিচালনার সময়কাল অবশ্যই আসবে ধরে নিয়ে সময়সীমা ও পরিমাপের উপায় আগে নকশা করুন
• গ্রহণ পদ্ধতি (চ্যানেল) একাধিক হলেও ভিতরের অর্ডার প্রসেসিং এক লাইনে জমা করুন
• সঙ্গে সঙ্গে Web স্ক্রিনে ইনপুট চাইবেন না, মধ্যবর্তী রূপ হিসেবে CSV ইমপোর্ট রাখুন
• Web অর্ডার স্ক্রিনে পণ্য ও ব্যবসায়িক অংশীদারের মাস্টার সরাসরি দেখা যায়, তাই মাস্টার ডেটা আগে গোছান
• সব অংশীদারকে একসঙ্গে সুইচ করবেন না, সংখ্যা ও সহযোগিতার মাত্রা দিয়ে শ্রেণি করে ক্রমে মাইগ্রেট করুন

JIPDEC (জিপডেক; Japan Information Economy and Society Promotion Association। PrivacyMark ব্যবস্থা ও স্ট্যান্ডার্ড কোম্পানি কোড পরিচালনার জন্য পরিচিত সংস্থা) স্ট্যান্ডার্ড কোম্পানি কোড প্রকল্পের ব্যাখ্যা পাতা «EDI-এর সুবিধা ও স্ট্যান্ডার্ডের প্রয়োজন»-এ বলে: «হাতে করা কাজ, FAX ও ফোন সামলানো থেকে গেলে তার জন্য লোক রাখতে হয়, 100% অটোমেশন বা মেকানাইজেশন হয় না, দক্ষতার ফলও পুরোপুরি পাওয়া যায় না।» তাই দ্বৈত পরিচালনার সময়কালকে «অগত্যা হয়ে যায়» বলে ফেলে না রেখে, সেটাকে ছোট করার পরিকল্পনা নিজেই নকশার বিষয় করতে হয়।

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

এই নিবন্ধ FAX অর্ডার হঠাৎ পুরো Web-এ না সরিয়ে, ম্যানুয়াল ইনপুট অর্ডারের সংখ্যা কমানোকে লক্ষ্য করে ধাপে ধাপে মাইগ্রেশনের ডিজাইন নিয়ে আলোচনা করে। গ্রহণ চ্যানেল একাধিক হলেও কোম্পানির ভিতরের অর্ডার প্রক্রিয়া এক প্রক্রিয়ায় গোছানো হয়, CSV ইমপোর্ট নামের মধ্যবর্তী রূপ মাঝে রেখে তারপর গ্রাহককে অর্ডার সংখ্যা ও সহযোগিতার মাত্রা অনুযায়ী A · B · C-তে শ্রেণিবদ্ধ করা হয়, পাইলট এক কোম্পানিতে টেমপ্লেট তৈরি করে ছড়ানো হয়। সমান্তরাল চালনার সময়কালে সময়সীমা ও লক্ষ্যমান সংখ্যায় সেট করা হয়, গ্রহণ চ্যানেল কলাম দিয়ে চ্যানেলভেদে সংখ্যা প্রতি মাসে মাপা হয়। কোড রূপান্তর টেবিল রাখে পণ্যের পরিবর্তন আগে জানে যে পক্ষ, অর্থাৎ নিজের কোম্পানি। CSV ইমপোর্টের পরে স্ট্যান্ডার্ড কোম্পানি কোড বা EDI-এর মতো উপরের রূপ আসে।

flowchart LR
    accTitle: FAX অর্ডার Web-এ সরানো ধাপে ধাপে মাইগ্রেশনের জ্ঞান মানচিত্র
    accDescr: ম্যানুয়াল ইনপুট অর্ডারের সংখ্যা কমানোকে লক্ষ্য ধরে, CSV ইমপোর্ট নামের মধ্যবর্তী রূপ ও গ্রাহক শ্রেণিবিন্যাস · পাইলটে টেমপ্লেট তৈরির মধ্য দিয়ে সমান্তরাল চালনার সময়কাল সময়সীমা বেঁধে ছোট করার ধাপে ধাপে মাইগ্রেশন ডিজাইন দেখানো চিত্র
    fax_order_web_migration["FAX অর্ডারের Web মাইগ্রেশন (ধাপে ধাপে)"]
    dual_operation_period["সমান্তরাল চালনার সময়কাল"]
    transcription_volume_reduction_goal["ম্যানুয়াল ইনপুট অর্ডার কমানোর লক্ষ্য"]
    all_at_once_web_migration["একসাথে পুরো Web মাইগ্রেশন"]
    indefinite_dual_operation["সমান্তরাল চালনার মেয়াদহীন স্থায়ীকরণ"]
    dual_operation_deadline_target["সমান্তরাল চালনার সময়সীমা ও লক্ষ্য"]
    channel_migration_kpi["চ্যানেলভেদে সংখ্যা মাপা"]
    receiving_channel_field["গ্রহণ চ্যানেল কলাম"]
    csv_import_intermediate_form["CSV ইমপোর্ট — মধ্যবর্তী রূপ"]
    csv_file_format_spec["CSV ফাইল ফরম্যাটের চুক্তি"]
    master_data_readiness["পণ্য ও গ্রাহক মাস্টারের প্রস্তুতি"]
    pilot_partner_approach["পাইলট এক কোম্পানিতে টেমপ্লেট তৈরি"]
    partner_classification["গ্রাহক শ্রেণিবিন্যাস (A/B/C)"]
    unified_order_channel_processing["গ্রহণ চ্যানেল একাধিক, অভ্যন্তরীণ প্রক্রিয়া একটি"]
    code_mapping_ownership_rule["কোড রূপান্তর টেবিলের মালিকানা"]
    all_or_nothing_import_validation["এক ত্রুটিতে পুরো ইমপোর্ট বন্ধ"]
    import_failure_notification["ইমপোর্ট ব্যর্থতার ন্যূনতম নোটিফিকেশন"]
    cross_channel_rule_consistency["চ্যানেল জুড়ে নিয়ম এক করা"]
    duplicate_order_registration["ডুপ্লিকেট নিবন্ধন"]
    fax_handling_improvement["FAX গ্রহণের ধরন উন্নত করা"]
    edi["EDI (ইলেকট্রনিক ডেটা বিনিময়)"]
    standardized_business_code["স্ট্যান্ডার্ড কোম্পানি কোড"]
    fax_order_web_migration -->|"পূর্বশর্ত"| dual_operation_period
    transcription_volume_reduction_goal -->|"প্রস্তাবিত সমাধান"| fax_order_web_migration
    all_at_once_web_migration -->|"কারণ হতে পারে"| indefinite_dual_operation
    transcription_volume_reduction_goal -->|"প্রতিরোধ করে"| all_at_once_web_migration
    dual_operation_deadline_target -->|"কমায়"| indefinite_dual_operation
    channel_migration_kpi -->|"ব্যবহার করে"| receiving_channel_field
    dual_operation_deadline_target -->|"দিয়ে যাচাই"| channel_migration_kpi
    csv_import_intermediate_form -->|"প্রস্তাবিত সমাধান"| fax_order_web_migration
    csv_import_intermediate_form -->|"ব্যবহার করে"| csv_file_format_spec
    csv_import_intermediate_form -->|"পূর্বশর্ত"| master_data_readiness
    pilot_partner_approach -->|"পূর্বশর্ত"| master_data_readiness
    partner_classification -->|"প্রস্তাবিত সমাধান"| fax_order_web_migration
    partner_classification -->|"আগে করা উচিত"| pilot_partner_approach
    unified_order_channel_processing -->|"প্রস্তাবিত সমাধান"| fax_order_web_migration
    code_mapping_ownership_rule -.->|"প্রস্তাবিত সমাধান"| csv_import_intermediate_form
    all_or_nothing_import_validation -.->|"প্রস্তাবিত সমাধান"| csv_import_intermediate_form
    all_or_nothing_import_validation -->|"পূর্বশর্ত"| import_failure_notification
    cross_channel_rule_consistency -->|"প্রস্তাবিত সমাধান"| fax_order_web_migration
    cross_channel_rule_consistency -->|"কমায়"| duplicate_order_registration
    fax_handling_improvement -->|"প্রস্তাবিত সমাধান"| dual_operation_period
    edi -->|"উত্তরসূরি"| csv_import_intermediate_form
    standardized_business_code -.->|"প্রস্তাবিত সমাধান"| edi
    partner_classification -->|"প্রতিরোধ করে"| all_at_once_web_migration

চিত্রে, টানা রেখা সবসময় সত্য এমন সম্পর্ককে এবং ভাঙা রেখা শর্তসাপেক্ষ সম্পর্ককে নির্দেশ করে (শর্তগুলো বিস্তারিত পাতায় প্রতিটি সম্পর্কের ব্যাখ্যায় আছে)। সম্পর্কের সম্পূর্ণ তালিকা (মোট 23, প্রমাণ ও নিশ্চয়তার মাত্রাসহ) এবং প্রধান ধারণাগুলোর সংজ্ঞা জ্ঞান মানচিত্রের বিস্তারিত পাতায় সংগ্রহ করা আছে (জাপানি ভাষায়)। তথ্য: JSON-LD / Turtle

2. একবারে পুরো Web রূপান্তর কেন সহজে ব্যর্থ হয়

FAX অর্ডারের Web রূপান্তরের একটা বৈশিষ্ট্য আছে যা শুধু ভিতরের সিস্টেমের সুবিধায় ঠিক করা যায় না। অর্ডার পাঠায় ব্যবসায়িক অংশীদার।

সব অংশীদারকে «আগামী মাস থেকে Web-এ অর্ডার দিন» বলে জানানো পদ্ধতি সহজেই এ ধরনের ব্যর্থতায় যায়।

• শুধু FAX-এ অর্ডার দিতে পারে এমন অংশীদার «ব্যতিক্রম» না থেকে «পরিকল্পনার বাধা» হয়ে দাঁড়ায়
• অংশীদারভেদে পরিস্থিতি আলাদা, তবু সবাইকে একই ডেডলাইন চাপানো হয়
• মাইগ্রেট না করা অংশীদারের অর্ডার FAX-এই আসতে থাকে, দ্বৈত পরিচালনা অনির্দিষ্টকাল চলতে থাকে
• «Web করেও লোক কমেনি» মূল্যায়নে প্রকল্প থেমে যায়

কারণ লক্ষ্য «FAX তুলে দেওয়া»তে রাখা।

লক্ষ্য বদলে «যে অর্ডার মানুষ ইনপুট করেন তার সংখ্যা কমানো»তে রাখলে পরিকল্পনা বাস্তব হয়। উদাহরণ: অর্ডারের 70% ধরে রাখা উপরের অংশীদাররাই Web বা CSV-তে গেলে, বাকি 30% FAX-এ থাকলেও ইনপুটের কাজ অনেক কমে।

পুরো জিনিস একবারে না নড়িয়ে, প্রভাব বেশি যেখানে সেখান থেকে ক্রমে নড়ানো। ধাপে ধাপে মাইগ্রেশনের মূল কথা এটাই।

3. মাইগ্রেশনের পরের চেহারা ── প্রবেশপথ একাধিক, ভিতরের প্রসেসিং এক লাইন

ধাপে ধাপে মাইগ্রেশন নকশা করার আগে লক্ষ্যের আকৃতি আগে আঁকুন।

মূল কথা, গ্রহণ চ্যানেল ও অর্ডার প্রসেসিং আলাদা করে ভাবা।

flowchart LR
    ORDER["কমন অর্ডার ডেটা<br/>(ফরম্যাট এক করা)"]
    BACK["অভ্যন্তরীণ প্রসেসিং<br/>ইনভেন্টরি অ্যালোকেশন·শিপিং·বিলিং"]
    subgraph CH["গ্রহণ চ্যানেল"]
        FAX["FAX"]
        MAIL["ইমেইল অ্যাটাচমেন্ট"]
        CSV["CSV ইমপোর্ট"]
        WEB["Web অর্ডার স্ক্রিন"]
    end
    FAX -->|"কর্মী ইনপুট করেন"| ORDER
    MAIL -->|"কর্মী ইনপুট করেন"| ORDER
    CSV -->|"স্বয়ংক্রিয় ইমপোর্ট"| ORDER
    WEB -->|"স্বয়ংক্রিয় নিবন্ধন"| ORDER
    ORDER --> BACK

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

উল্টোদিকে চ্যানেলভেদে আলাদা প্রসেসিং বা আলাদা খাতা বানালে চ্যানেল বাড়ার সঙ্গে কাজ জটিল হয়, দ্বৈত পরিচালনার বোঝা বাড়তেই থাকে।

FAX-এ আসা অর্ডারও কর্মী ইনপুট করার মুহূর্তে অন্য চ্যানেলের মতো একই অর্ডার ডেটা হয়ে যাক। মাইগ্রেশন মানে এই ছবিতে «কর্মী ইনপুট করেন» সারিতে যাওয়া সংখ্যা কমিয়ে «স্বয়ংক্রিয় ইমপোর্ট» ও «স্বয়ংক্রিয় নিবন্ধন» সারিতে যাওয়া সংখ্যা বাড়ানোর কাজ।

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

4. মধ্যবর্তী রূপ হিসেবে CSV ইমপোর্ট

FAX থেকে সোজা Web স্ক্রিনে ইনপুটে সরাতে বলা ব্যবসায়িক অংশীদারের জন্য ভারী হতে পারে।

অর্ডার দেওয়া পক্ষের চোখে Web স্ক্রিনে ইনপুট মানে «নিজের পারচেজিং সিস্টেম বা Excel-এ বানানো অর্ডার আবার অন্যের স্ক্রিনে লেখা»। অংশীদার নিজের ব্যবস্থায় অর্ডার ডেটা বানাচ্ছেন তো সেই ডেটা ফাইল হিসেবে নিয়ে ইমপোর্ট করা দুই পক্ষেরই কাজ কমায়।

তাই মধ্যবর্তী রূপ হিসেবে CSV (বা Excel) ইমপোর্ট রাখুন।

প্রথম ধাপ: CSV ইমেইল অ্যাটাচমেন্টে নিয়ে কর্মী ইমপোর্ট ফিচারে পড়েন
দ্বিতীয় ধাপ: অংশীদার Web পাতা থেকে CSV আপলোড করেন, স্বয়ংক্রিয়ভাবে ইমপোর্ট হয়
তৃতীয় ধাপ: নিয়মিত হয়ে যাওয়া অংশীদার Web অর্ডার স্ক্রিন বা EDI-তে যান

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

CSV ইমপোর্ট নকশা করার সময় অন্তত এই বিষয়গুলো ঠিক করুন।

এই 6টি বিষয়ের মধ্যে বাস্তবে সবচেয়ে বেশি টানাটানি হয় কোড ব্যবস্থা নিয়ে। «অংশীদারের পণ্য কোডে পাঠাতে বলবেন» না «নিজেদের পণ্য কোডে বদলিয়ে পাঠাতে বলবেন» — তাতে রূপান্তর সারণি কে রাখবেন তা ঠিক হয়। সেলস থেকে আসে «অংশীদারকে আমাদের কোডে পাঠালে আমাদের সুবিধা», তথ্য সিস্টেম থেকে আসে «অংশীদারভেদে রূপান্তর সারণি রাখা বোঝা»।

সিদ্ধান্তের জায়গা: রূপান্তর সারণি রাখবে «পণ্যের বদল আগে যে জানে» সেই পক্ষ। নতুন পণ্য ও ডিসকন্টিনিউ আগে জানে নিজেরা, তাই নিজেদের দিকে রূপান্তর রাখলে পণ্য বদলের সঙ্গে সব অংশীদারকে «কোড সারণি বদলান» বলে ধরতে হয় না। অংশীদারকে নিজেদের কোড মনে রাখতে বলা শুরুতে সহজ, কিন্তু প্রতি বদলে যতজন ততবার খবর দিতে হয়। এই এক পালা মাইগ্রেশনের আগে মিটিয়ে রাখলে পরে «কেন এই নকশা» আবার ব্যাখ্যা করতে হয় না।

আর একটা বিষয় সরাসরি অপারেশনে লাগে: ত্রুটি ফেরত দেওয়ার উপায়। ইমপোর্ট নীতিতে «সব সারি ত্রুটিতে থামান» (এক সারিও ভুল হলে কিছুই ইমপোর্ট হবে না) আংশিক ঢুকে পড়া অর্ডার পরে তাড়ানোর চেয়ে নিরাপদ। তবে সেটা দাঁড়ায় এই ধরে যে থেমে যাওয়া খবর অবশ্যই কাউকে পৌঁছায়। ন্যূনতম গঠন এমন হতে পারে।

• ভিতরে ইমেইল নোটিফিকেশন ── অর্ডার গ্রহণের মেইলিং লিস্টে «ইমপোর্ট ব্যর্থ» স্বয়ংক্রিয় পাঠান। বিষয়ে ফাইলের নাম ও অংশীদারের নাম, বডিতে ত্রুটির সারি নম্বর ও কারণ («পণ্য কোড ABC-123 মাস্টারে নেই» ইত্যাদি) সাজান।
• অ্যাডমিন স্ক্রিনের ইমপোর্ট ইতিহাস ── সফল, ব্যর্থ, অপ্রক্রিয়াকৃত এক নজরে দেখা যায় এমন স্ক্রিন রাখুন। ইমেইল চোখ এড়ালেও সকালে এখানে তাকালে ধরা পড়ে।
• অংশীদারকে খবর ── শুরুতে অটো-রিপ্লাই নয়, ভিতরের কর্মী বিষয় দেখে তারপর খবর দেন। Web আপলোড পদ্ধতিতে গেলে আপলোড স্ক্রিনে তখনই ত্রুটি দেখানোর রূপে সরান।

«ত্রুটি লগে আছে, দেখে নিন» নকশা দ্বৈত পরিচালনার সময়কালে মানায় না। কর্মী FAX সামলাতেই ব্যস্ত।

CSV দেখতে সরল, কিন্তু ক্যারেক্টার এনকোডিং, লাইন ব্রেক, কমা ও কোটেশনের ব্যবহারে ফাঁদ বেশি। ইমপোর্ট প্রসেসিং বাস্তবায়নের প্রযুক্তিগত সতর্কতা «CSV ফাইল হ্যান্ডলিং-এর ব্যবহারিক গাইড»-এ সাজানো আছে।

মনে রাখুন, CSV ইমপোর্ট চূড়ান্ত রূপ নয়, মধ্যবর্তী রূপ। এখানে ঠিক করা ফিল্ড সংজ্ঞা ও কোড ব্যবস্থা পরে Web অর্ডার ও EDI-এরও ভিত্তি হয়ে থাকে।

5. পণ্য ও ব্যবসায়িক অংশীদারের মাস্টার ডেটা আগে গোছান

FAX অর্ডারে মাস্টারের ঘাটতি কর্মী নিজে সামলান।

উদাহরণ: অর্ডার ফর্মে পুরোনো পণ্যের নাম থাকলেও কর্মী «এটা এখনকার এই পণ্য» বলে পড়ে ইনপুট করেন। ইউনিট «কেস» লেখা থাকলেও এক কেসে কত পিস মনে রেখে রূপান্তর করেন।

CSV ইমপোর্ট বা Web অর্ডারে গেলে এই পড়ে বোঝা যন্ত্র করে। তার উপর Web অর্ডার স্ক্রিনে পণ্য মাস্টার সরাসরি অংশীদারের চোখে পড়ে।

তাই মাইগ্রেশনের আগে অন্তত এগুলো গোছাতে হয়।

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

এখানে জরুরি কথা, সব মাস্টার নিখুঁত করে তারপর শুরু করার চেষ্টা না করা। সেই অপেক্ষায় মাইগ্রেশন আর শুরু হয় না।

বাস্তব পথ: প্রথমে যে অংশীদার মাইগ্রেট করবেন (পাইলট) তার পণ্য ও ডেলিভারি গন্তব্যের পরিসরই আগে গোছান, অংশীদার বাড়ার সঙ্গে পরিসর বাড়ান। মাস্টার গোছানোর কাজ নিজেই ধাপে ধাপে মাইগ্রেশনের ফেজে ঢোকান।

6. দ্বৈত পরিচালনার সময়কালের নকশা

FAX ও Web (CSV)-এর দ্বৈত পরিচালনা মাইগ্রেশন চলাকালে অবশ্যই আসে। নকশা না করে ফেলে রাখলে দ্বৈত পরিচালনাই স্বাভাবিক হয়ে যায়, «চ্যানেল যত বেড়েছে কাজও তত বেড়েছে» অবস্থা হয়।

দ্বৈত পরিচালনার সময়কালের নকশা মানে নিচের বিষয়গুলো ঠিক করা।

6.1. সময়সীমা ও লক্ষ্যমান ঠিক করুন

«কতদিনের মধ্যে অর্ডার সংখ্যার কত ভাগ স্বয়ংক্রিয় ইমপোর্ট হবে» সংখ্যায় ঠিক করুন। যেমন «6 মাসে FAX অর্ডারের অনুপাত 70% থেকে 30%-এ নামানো»।

ডেডলাইনহীন দ্বৈত পরিচালনা সেভাবেই স্থায়ী হয়ে যায়। লক্ষ্য না পৌঁছালেও ডেডলাইন থাকলে «মাইগ্রেশন এগোচ্ছে না কেন» অংশীদারভেদে দেখার কাজে যায়।

6.2. চ্যানেলভেদে সংখ্যা প্রতি মাসে মাপুন

মাইগ্রেশন কতদূর গেছে অনুভূতি নয়, সংখ্যায় ধরুন।

• চ্যানেলভেদে অর্ডার সংখ্যা (FAX, ইমেইল অ্যাটাচমেন্ট, CSV, Web)
• ম্যানুয়াল এন্ট্রি করা অর্ডারের সংখ্যা ও সময়
• ইমপোর্ট ত্রুটির সংখ্যা ও কারণ
• ইনপুট সংশোধন ও ডুপ্লিকেট নিবন্ধনের সংখ্যা

আগের নিবন্ধে বলা চালু করার পর মাপতে চাওয়া সূচক একই যুক্তি। চ্যানেল ভেঙে মাপলে «কোন অংশীদারকে ধরলে প্রভাব বেশি» দেখা যায়।

সমস্যা হলো এগুলো কীভাবে জমা করবেন। ব্যবস্থা না রেখে «প্রতি মাসে গুনব» ঠিক করলে প্রথম মাসেই থেমে যায়। নিশ্চিত উপায়: অর্ডার ডেটা নিজেই পরিমাপের একটা ফিল্ড যোগ করা।

বিদ্যমান সেলস ম্যানেজমেন্ট সিস্টেমে কলাম যোগ করা না গেলে ইমপোর্ট প্রসেসিং ও ইনপুট স্ক্রিনের লগ আলাদা টেবিলে রেখে সেখানে সারাংশ করুন। যেভাবেই হোক, মাপার উপায় ঠিক করুন মাইগ্রেশন শুরুর আগে। পরে বলা ফেজ বিচারের (অধ্যায় 8) মানদণ্ড চ্যানেল অনুপাত। অনুপাত না পেলে পরের ফেজে যাবেন না দাঁড়াবেন তা ঠিক করা যায় না।

6.3. অপারেশন নিয়ম চ্যানেলগুলোর মধ্যে এক করুন

দ্বৈত পরিচালনার সময়কালে বিভ্রান্তি বেশি হয় চ্যানেলভেদে ব্যবসার নিয়ম আলাদা হলে।

• অর্ডার কাট-অফ সময় FAX ও Web-এ এক কি না
• অর্ডার বদল ও বাতিল কোন চ্যানেলে নেবেন (Web-এ নেওয়া অর্ডারের বদল FAX-এ নিলে মিলিয়ে দেখতে হয়)
• স্টক না থাকলে খবর দেওয়ার উপায় চ্যানেলভেদে বদলায় কি না
• অর্ডার নম্বর চ্যানেল পেরিয়ে অনন্য কি না (ডুপ্লিকেট নিবন্ধন ধরতে দরকার)

বিশেষ করে «Web-এ অর্ডার দিয়ে সঙ্গে সঙ্গে ফোন বা FAX-এ বদল» প্যাটার্ন অবশ্যই আসে। বদল কোন চ্যানেলে নেবেন, কোন ডেটা কে সোজা করবেন আগে ঠিক করুন।

6.4. FAX নেওয়ার উপায়ও উন্নতির বিষয় করুন

দ্বৈত পরিচালনার সময়কালে FAX থেকে যায়। থেকে যাবে ধরে নিলে FAX পক্ষের প্রসেসিংও উন্নতির বিষয়।

• FAX মাল্টিফাংশন প্রিন্টারে নিয়ে PDF করুন, কাগজের ব্যবস্থাপনা ছাড়ুন
• পাওয়া PDF অর্ডার ফোল্ডারে জমা করে প্রসেসিংয়ের অবস্থা (অপ্রক্রিয়াকৃত, ইনপুট হয়ে গেছে, হোল্ড) রাখুন
• ইনপুটের পর FAX মূল (PDF) ও অর্ডার ডেটা অর্ডার নম্বরে বেঁধে পরে মিলিয়ে দেখা যায় করুন

«FAX একদিন যাবে তাই হাত দেব না» ভাবলে দ্বৈত পরিচালনার সময়কালের বোঝা নামে না। মাইগ্রেশন শেষ না হওয়া পর্যন্ত FAX প্রসেসিংও একই অর্ডার ডেটায় মেশা আর একটা চ্যানেল হিসেবে ধরুন।

7. ব্যবসায়িক অংশীদারদের সাথে নেওয়ার উপায়

ধাপে ধাপে মাইগ্রেশন সফল কি না ভিতরের কাজের চেয়ে অংশীদারদের কাছে যাওয়ার উপর বেশি নির্ভর করে।

7.1. অংশীদারদের শ্রেণি করুন

সব অংশীদারকে একভাবে না ধরে আগে শ্রেণি করুন।

প্রভাব ঠিক করে A ও B। C অংশীদারকে জোর করে সরাতে খরচই বাড়ে, তাই «FAX-ও নিতে থাকব» স্পষ্ট বলে দেওয়া যায় এমন পক্ষ।

7.2. পাইলট এক কোম্পানি বেছে নিন

শুরুতেই একাধিক কোম্পানি পাশাপাশি মাইগ্রেট না করে আগে এক কোম্পানিতে অপারেশন দাঁড় করান। বেছে নেওয়ার মানদণ্ড আগের নিবন্ধের মতোই।

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

পাইলটে CSV ফরম্যাট, ত্রুটির সময় খবর দেওয়ার উপায়, মাস্টারের মিল সারণি, জানানোর নথি ইত্যাদি «ছাঁচ» বানিয়ে দ্বিতীয় কোম্পানি থেকে সেই ছাঁচই আবার ব্যবহার করুন।

7.3. অংশীদারের সুবিধা দিয়ে জানান

অংশীদারের চোখে অর্ডার দেওয়ার পদ্ধতি বদল নিজেদের সুবিধার অনুরোধ। জানানো নিজেদের দক্ষতা নয়, অংশীদারের সুবিধা দিয়ে বলুন।

• অর্ডার কনফার্মেশন তাড়াতাড়ি ফেরে, তাই «পেয়েছেন কি না» ফোন লাগে না
• ভুল পড়ে ভুল শিপমেন্ট ও পরিমাণের গড়মিল কমে
• অর্ডার ইতিহাস নিজে দেখা যায়, আবার অর্ডার দেওয়া সহজ হয় (Web অর্ডারের ক্ষেত্রে)
• FAX পাঠানোর কাজ ও পাঠানোর ত্রুটিতে আবার পাঠানো যায় না

সঙ্গে ব্যবহারিক যত্নও কাজে লাগে।

• অপারেশন ধাপ এক পাতার ম্যানুয়ালে জমা করুন (কয়েকটা স্ক্রিনের ব্যাখ্যায় যথেষ্ট পরিসর রাখুন)
• শুরুর তারিখ ও পাশাপাশি চলার সময়সীমা স্পষ্ট করুন («◯ মাস থেকে Web-এও নেব। FAX-ও আপাতত চলবে»)
• প্রথম কয়েকবার FAX ও Web যেদিক দিয়েই আসুক নিন, জিজ্ঞাসায় সঙ্গে সঙ্গে সাড়া দিন

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

ছোট ও মাঝারি উদ্যোগের অর্ডার গ্রহণ-প্রদানের ডিজিটালাইজেশন নিয়ে জাপানের Small and Medium Enterprise Agency SME Common EDIসহ স্ট্যান্ডার্ডাইজেশনের উদ্যোগ ও ফল পরিচয় করায়। শিল্প সংঘ বা প্রধান অংশীদার এ ধরনের স্ট্যান্ডার্ডে থাকলে নিজস্ব ফরম্যাট নয়, স্ট্যান্ডার্ডে মেলানোর পথও বিবেচনা করুন।

8. ধাপে ধাপে মাইগ্রেশনের মডেল কেস

এ পর্যন্ত যা এসেছে সময়ের ধারায় মডেলে সাজায়। সময়সীমা উদাহরণমাত্র, অংশীদারের সংখ্যা ও ভিতরের দল অনুযায়ী বদলায়।

ফেজ 0-এর «বর্তমান অবস্থা সাজানো» আগের নিবন্ধের অর্ডার গ্রহণ-প্রদানের পদ্ধতির তালিকা সরাসরি ব্যবহার করা যায়।

আর অর্ডার ম্যানেজমেন্ট নিজে Web সিস্টেমে সরানো উচিত কি না, ডেস্কটপ অ্যাপেই রাখা উচিত কি না নিয়ে দ্বিধা থাকলে «Windows অ্যাপ Web-এ সরানো উচিত কি না»-এ সিদ্ধান্তের কাঠামো সাজানো আছে। গ্রহণ চ্যানেলের Web রূপান্তর ও ভিতরের সিস্টেমের Web রূপান্তর আলাদা করে ঠিক করা যায়।

9. সাধারণ হোঁচট ও মোকাবিলা

শেষে বাস্তব মাইগ্রেশনে যে হোঁচটগুলো সহজে আসে সেগুলো সাজায়।

সারসংক্ষেপ

FAX অর্ডারের Web রূপান্তর সিস্টেম বানানোর কাজের চেয়ে মাইগ্রেশনের সময়কাল নকশা করার কাজ বেশি।

• লক্ষ্য «FAX বন্ধ করা» নয়, «যে অর্ডার মানুষ ইনপুট করেন তার সংখ্যা কমানো»তে রাখুন
• গ্রহণ চ্যানেল একাধিক থাকতে পারে, কিন্তু ভিতরের অর্ডার ডেটা ও প্রসেসিং এক লাইনে জমা করুন
• সঙ্গে সঙ্গে Web স্ক্রিনে ইনপুট চাইবেন না, CSV ইমপোর্ট মধ্যবর্তী রূপ হিসেবে রাখুন
• মাস্টার গোছানো প্রথমে যে অংশীদার মাইগ্রেট করবেন তার পরিসর থেকে ধাপে ধাপে এগোন
• দ্বৈত পরিচালনার সময়কালে ডেডলাইন ও লক্ষ্যমান রাখুন, চ্যানেলভেদে সংখ্যায় অগ্রগতি মাপুন
• অংশীদারদের সংখ্যা ও সহযোগিতার মাত্রা দিয়ে শ্রেণি করে পাইলট এক কোম্পানিতে ছাঁচ বানিয়ে তারপর বাড়ান

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

অর্ডার গ্রহণ-প্রদানের Web রূপান্তর বিবেচনা করছেন

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

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

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

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

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

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

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

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

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

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

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

Go Komura

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

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