দুই সপ্তাহে ইআরপি ইন্টিগ্রেশন: আপনার নিজস্ব ইন্টারফেস তৈরি করার গাইড

দুই সপ্তাহে ইআরপি ইন্টিগ্রেশন: আপনার নিজস্ব ইন্টারফেস তৈরি করার গাইড

SAP থেকে Odoo-তে - এখানে দেখুন কীভাবে আমাদের REST API ব্যবহার করে Transpareo-কে আপনার বিদ্যমান সিস্টেমের সাথে দুই সপ্তাহে একীভূত করবেন, যা ছয় মাসের প্রকল্পের পরিবর্তে।

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

‘সিলহীন ইআরপি ইন্টিগ্রেশন’ একটি মানক প্রতিশ্রুতি, যা বাস্তবে তিন মাসের একটি প্রকল্পের মাধ্যমে অনুসৃত হয়। আমরা আমাদের গাইড প্রকাশ করছি যাতে আপনার আইটি বিভাগ চুক্তি স্বাক্ষরের আগে প্রকৃতপক্ষে কোন তথ্য প্রয়োজন তা যাচাই করতে পারে। এই নিবন্ধে ব্যাখ্যা করা হয়েছে যে পাসপোর্টের জন্য আপনার সিস্টেম থেকে কী ডেটা প্রয়োজন, এটি আমাদের কাছে পাঠানোর তিনটি উপায়, এবং কেন এটি দুই সপ্তাহে করা যেতে পারে।

আপনার ERP-কে আসলে কী প্রদান করতে হবে

একটি DPP তৈরি করতে, আমাদের প্রতিটি পণ্যের জন্য নিম্নলিখিতগুলি প্রয়োজন:

  • মাস্টার ডেটা - আইটেম নম্বর, বর্ণনা, ভেরিয়েন্ট, ওজন, মাত্রা, চিত্র
  • উপকরণ তালিকা (Bill of materials) ডেটা - পরিমাণ ও পুনর্ব্যবহৃত উপাদানসহ উপাদানসমূহ
  • উৎপত্তি ডেটা - উৎপাদন সাইট, ব্যাচ নম্বর, উৎপাদন তারিখ
  • পরিবেশগত ডেটা - প্রতি ইউনিটে CO₂ সমতুল্য, জল ব্যবহার, শক্তি ব্যবহার
  • সরবরাহকারী ডেটা - কে কোন উপাদান সরবরাহ করে (যথাযথ যাচাই-বাছাইয়ের প্রয়োজনীয়তার জন্য)

তত্ত্বগতভাবে, এই সমস্ত ডেটা আপনার ইআরপি সিস্টেমে উপলব্ধ। তবে, বাস্তবে এটি ৪ থেকে ৭টি মডিউলে ছড়িয়ে আছে: উপকরণ ব্যবস্থাপনা, উৎপাদন, গুণগত মান, সরবরাহকারী মাস্টার ডেটা, কখনও কখনও পরিবেশগত ডেটার জন্য একটি পৃথক মডিউল, এবং কখনও কখনও ফর্মুলেশন এবং বিল অফ ম্যাটেরিয়ালের জন্য একটি নিবেদিত সিস্টেম।

একত্রীকরণ সম্পর্কিত প্রশ্নটি হল না: ‘আপনার ERP কি একটি DPP-কে ডেটা প্রদান করে?’ বরং এটি হল: ‘আপনি কীভাবে পাঁচটি উপ-সিস্টেম থেকে ডেটা একত্রিত করে একটি সুসংগঠিত ডেটাসেট তৈরি করবেন?’

তিনটি পরীক্ষিত পদ্ধতি

পদ্ধতি ১: ERP থেকে ডেটা পুনরুদ্ধার

আধুনিক ERP-গুলোর (SAP S/4HANA Cloud, Dynamics 365, Odoo) সাথে ভালোভাবে কাজ করে। DPP প্রদানকারী ERP-এর ইন্টারফেস (প্রযুক্তিগতভাবে OData বা REST) এর মাধ্যমে ডেটা আহরণ করে। শুধুমাত্র পরিবর্তনগুলো আহরণ করা হয়, তা নির্ধারিত সময় অনুযায়ী বা কোনো ইভেন্ট দ্বারা ট্রিগার হয়ে।

সুবিধা: আপনার পক্ষ থেকে ন্যূনতম ডেভেলপমেন্টের প্রয়োজন; আপনি রিড অ্যাক্সেস প্রদান করেন, এবং প্রোভাইডার রূপান্তর পরিচালনা করে।

অসুবিধা: অতিরিক্ত ইন্টারফেস লেয়ার ছাড়া পুরনো SAP ECC ইনস্টলেশনের সাথে কাজ করে না। কারা কোন ডেটা পড়ার জন্য অনুমোদিত তা নিয়ন্ত্রণ করার জন্য আপনার স্পষ্ট নিয়মের প্রয়োজন।

বিকল্প ২: পরিবর্তন ফরওয়ার্ড করা

আপনার ERP প্রতিটি পরিবর্তনকে একটি ইভেন্ট হিসেবে রিপোর্ট করে (SAP ইভেন্ট মেশ, অ্যাপাচি কাফকা বা র‍্যাবিটএমকিউ-এর মাধ্যমে), এবং DPP প্রদানকারী সেগুলো গ্রহণ করে।

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

অসুবিধা: সেটআপ জটিল এবং এর জন্য এমন অবকাঠামোর প্রয়োজন যা সব আইটি বিভাগেরই থাকে না। সাধারণত ছোট কোম্পানিগুলোর জন্য এটি অতিরিক্ত।

বিকল্প ৩: বিদ্যমান ইন্টিগ্রেশন লেয়ার ব্যবহার করুন

ERP এবং বাহ্যিক সিস্টেমের মধ্যে আপনার ইতিমধ্যেই একটি ইন্টিগ্রেশন লেয়ার (Mulesoft, Boomi, Informatica, Azure Data Factory) রয়েছে। এই লেয়ারটি ইন্টারফেস হিসেবে কাজ করে: DPP প্রদানকারী এর সাথে যোগাযোগ করে, কখনই সরাসরি ERP-এর সাথে নয়।

সুবিধা: বিদ্যমান বিনিয়োগ ব্যবহার করা যায়, নিয়মগুলো স্থিতিশীল থাকে, এবং তৃতীয় পক্ষের জন্য সরাসরি ERP-এ প্রবেশাধিকার থাকে না।

অসুবিধা: ইন্টিগ্রেশন লেয়ারের খরচ আপনার অনুযায়ী বৃদ্ধি পায়।

নির্দিষ্ট প্রকল্পে আমরা যা ভিন্নভাবে করি

অনেক প্রদানকারী সরাসরি আপনার ERP-এ সংযোগ করতে চায়। আমরা সবসময় একটি মধ্যবর্তী ধাপ অন্তর্ভুক্ত করি: আমাদের ইন্টারফেস একটি নিরপেক্ষ ডেটা ফরম্যাট (একটি JSON স্কিমা) গ্রহণ করে, যা আপনি আপনার পছন্দের টুল ব্যবহার করে পূরণ করেন। এর মানে:

  • আপনি নিজে ডেটা প্রস্তুত করতে পারেন, আপনার টিম যে টুলগুলোর সাথে পরিচিত সেগুলো ব্যবহার করে
  • আপনি প্রদানকারী পরিবর্তন করতে পারেন - নিরপেক্ষ ফরম্যাটটি বহনযোগ্য
  • আপনি যে কোনো সময় আপনার সম্পূর্ণ ডেটাসেট পুনরুদ্ধার করতে পারেন - CSV, XLSX, JSON-LD এবং SQL ফরম্যাটে, এবং REST API-র মাধ্যমে
  • আমরা একটি ইমপোর্ট ভ্যালিডেটর প্রদান করি যা আপলোডের আগে আপনার ডেটা যাচাই করে

সম্পূর্ণ ফর্ম্যাট এবং সমস্ত কুয়েরি OpenAPI অনুযায়ী একটি API বিবরণ হিসাবে /apidocs-এ সর্বজনীনভাবে ডকুমেন্ট করা হয়েছে। আপনার আইটি দল চুক্তি স্বাক্ষরের আগে API পর্যালোচনা করতে পারে - যার মধ্যে রয়েছে নমুনা অনুরোধ, ত্রুটি প্রতিক্রিয়া এবং প্রমাণীকরণ বিবরণ।

এই পদ্ধতির বাস্তবায়নের সময়রেখা:

  • দিন ১ থেকে ২: ম্যাপিং কর্মশালা। কোন ERP ফিল্ড কোন DPP ফিল্ডের সাথে মিলে?
  • দিন ৩ থেকে ৫: ERP থেকে প্রাথমিক JSON এক্সপোর্ট, যা আমাদের ভ্যালিডেটর দ্বারা প্রক্রিয়াজাত করা হয়।
  • দিন ৬ থেকে ৮: সমস্যা সমাধান (অনুপস্থিত ফিল্ড, অসামঞ্জস্যপূর্ণ কোডিং)।
  • দিন ৯ থেকে ১০: প্রথম DPP-গুলো লাইভ হয়।

দুই সপ্তাহ, তিন মাস নয়। মূল বিষয় হল ম্যাপিং ওয়ার্কশপ - এখানেই ডেটা গুণগত মান নির্ধারিত হয়।

কি ভুল হয়: সবচেয়ে সাধারণ ফাঁদ

অনেকগুলো সিস্টেমে পণ্য মাস্টার ডেটা: SAP-এ আইটেম নম্বর আছে, PIM-এ ছবি এবং বিপণন টেক্সট আছে, PLM-এ বিল অফ ম্যাটেরিয়ালস আছে। কারো কাছেই একটি সামঞ্জস্যপূর্ণ চিত্র নেই। সমাধান: প্রকল্প শুরু হওয়ার আগে, প্রতিটি ক্ষেত্রের জন্য কোন সিস্টেমটি মাস্টার হবে তা নির্ধারণ করুন।

পিডিএফ হিসেবে সার্টিফিকেট: সরবরাহকারীরা GOTS, OEKO-TEX বা REACH সার্টিফিকেট পিডিএফ স্ক্যান হিসেবে প্রদান করে। এটি কোনো কাঠামোবদ্ধ ডেটা উৎস নয়। সমাধান: সার্টিফিকেশন সংস্থাগুলি ক্রমশই একটি ইন্টারফেসের মাধ্যমে ডেটা পুনরুদ্ধারের বিকল্প দিচ্ছে (OEKO-TEX এ ক্ষেত্রে অগ্রণী, যেখানে GOTS পিছিয়ে আছে)। অন্যথায়, ডেটা ম্যানুয়ালি প্রবেশ করান, তবে বৈধতার তারিখ অন্তর্ভুক্ত করুন যাতে DPP-তে কোনো মেয়াদোত্তীর্ণ সার্টিফিকেট না দেখায়।

ফর্মুলেশনের গোপনীয়তা: বিশেষ করে প্রসাধনী, খাদ্য ও ফার্মাসিউটিক্যালসে, সম্পূর্ণ ফর্মুলেশন একটি ব্যবসায়িক গোপনীয়তা। DPP কি এগুলো প্রকাশ করা উচিত? সমাধান: ESPR-এর তিন-স্তরের মডেল। পণ্য বিভাগটি সর্বজনীনভাবে উপলব্ধ; নিয়ন্ত্রক কর্তৃপক্ষ সম্পূর্ণ ফর্মুলেশন দেখতে পারে। এটি খুব কমই বাধা সৃষ্টি করে, তবে প্রাথমিক পর্যায়েই এটি স্পষ্ট করতে হবে।

CO₂ ডেটা সরবরাহকারীর উপর ভিত্তি করে: আপনার সরবরাহকারী তার পুরো পোর্টফোলিওর জন্য গড় মান প্রদান করে, প্রতি ব্যাচের জন্য নয়। সমাধান: অস্থায়ীভাবে এটি গ্রহণ করুন; দীর্ঘমেয়াদে সরবরাহকারী চুক্তি সামঞ্জস্য করুন। ESPR একটি নির্দিষ্ট কাট-অফ তারিখ থেকে পণ্য-নির্দিষ্ট মানের প্রয়োজন, তবে বর্তমান অনুশীলন একটি আপস।

স্থানীয় ভাষার সংস্করণ: আপনার ERP সিস্টেমে শুধুমাত্র জার্মান এবং ইংরেজি ভাষায় পণ্যের নাম রয়েছে। ২৭টি ইইউ দেশের জন্য, আপনাকে আরও ভাষা প্রয়োজন। সমাধান: পরিভাষা ডাটাবেস ব্যবহার করে মেশিন অনুবাদ; এ বিষয়ে আমাদের একটি পৃথক নিবন্ধ রয়েছে।

প্রকল্পের আগে আপনাকে যে প্রশ্নগুলো করতে হবে

তিনটি সরবরাহকারীর কাছে RFP পাঠানোর আগে, নিম্নলিখিত প্রশ্নগুলির উত্তর অভ্যন্তরীণভাবে দিন:

১. কতটি পণ্য/আইটেম নম্বরের DPP থাকা উচিত? (১০, ১০,০০০, ১০ লক্ষ?) ২. কোন সিস্টেমগুলি বর্তমানে DPP-প্রাসঙ্গিক ডেটা ধারণ করে? ৩. কোন বিভাগ এই প্রতিটি সিস্টেম পরিচালনা করে? ৪. আপনার কি এমন কোনো ইন্টিগ্রেশন লেয়ার আছে যা ব্যবহার করা উচিত? ৫. আপনার ERP-এর মাধ্যমে কি ইতিমধ্যেই কোনো ইন্টারফেস কার্যকর আছে?

এই উত্তরগুলো নির্ধারণ করবে তিনটি পদ্ধতির মধ্যে কোনটি আপনার জন্য সঠিক। এবং এগুলো নির্ধারণ করবে একটি প্রকল্প দুই সপ্তাহের হবে নাকি ছয় মাসের।

এই পোস্ট সম্পর্কে প্রশ্ন

REST ইন্টারফেস কি যথেষ্ট, নাকি আমাদের মিডলওয়্যার দরকার?

ইন্টারফেসটি যথেষ্ট। তিনটি প্যাটার্নের পার্থক্য রূপান্তর কোথায় ঘটে, আমরা কী গ্রহণ করি তাতে নয় - আমাদের ইন্টারফেস একটি নিরপেক্ষ JSON স্কিমা গ্রহণ করে, আপনি যা দিয়েই এটি তৈরি করুন না কেন। আধুনিক ERP থেকে পুল, ইভেন্ট স্ট্রিম এবং বিদ্যমান ইন্টিগ্রেশন লেয়ার - সবই একই এন্ডপয়েন্টে পৌঁছায়। যদি আপনি ইতিমধ্যেই কোনো মিডলওয়্যার ব্যবহার করে থাকেন এবং তা তৃতীয় পক্ষের সাথে চুক্তিবদ্ধ ইন্টারফেস হিসেবে রাখতে চান, তবে মিডলওয়্যার ব্যবহার করা যুক্তিযুক্ত। যদি বর্তমানে আপনার কাছে কোনো মিডলওয়্যার না থাকে, শুধুমাত্র পণ্যের পাসপোর্টের জন্য কোনো মিডলওয়্যার কিনবেন না।

মানচিত্রায়ন কর্মশালায় কী সিদ্ধান্ত নেওয়া হবে?

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

আমাদের সার্টিফিকেটগুলো শুধুমাত্র PDF স্ক্যান হিসেবে পাওয়া যাচ্ছে। এগুলো নিয়ে আমরা কী করব?

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

আমরা কিছুতেই স্বাক্ষর করার আগে কি আমাদের আইটি বিভাগ ইন্টারফেসটি পরীক্ষা করতে পারে?

হ্যাঁ। সম্পূর্ণ স্কিমা এবং সমস্ত এন্ডপয়েন্ট /apidocs-এ OpenAPI স্পেসিফিকেশন হিসেবে উপলব্ধ, সাথে নমুনা অনুরোধ, ত্রুটি প্রতিক্রিয়া এবং প্রমাণীকরণ বিবরণ। এই সব কিছুই বিক্রয় আলোচনার আওতাভুক্ত নয়, তাই আপনার ইন্টিগ্রেশন দল চুক্তি স্বাক্ষরের আগে প্রয়োজনীয় প্রচেষ্টা মূল্যায়ন করতে পারে। যদি কোনো প্রদানকারী এই পর্যায়ে তার API প্রকাশ না করে, তাহলে সেটাই একটি উত্তর।

আমরা যখন প্রদানকারী পরিবর্তন করি, তখন আমাদের ডেটার কী হয়?

তারা এতে সম্মত। ইন্টারফেসটি মালিকানাধীন ফরম্যাটের পরিবর্তে নিরপেক্ষ JSON স্কিমা গ্রহণ করে, এবং আপনার সম্পূর্ণ ডেটাসেট CSV, XLSX, JSON-LD এবং SQL ফরম্যাটে অথবা REST API-এর মাধ্যমে আউটপুট হয়। এটি পরিকল্পনামাফিক - আপনি যে ফরম্যাট পূরণ করেন তা বহনযোগ্য, তাই প্রদানকারী পরিবর্তন করতে সবকিছু আবার নতুন করে তৈরি করার বদলে কেবল এক্সপোর্ট করলেই চলে। ম্যাপিং কর্মশালার আগে প্রতিটি প্রদানকারীকে একই প্রশ্ন করুন, কারণ তখন আপনার ফিল্ডের নামগুলো তাদের মডেলে অন্তর্ভুক্ত হবে।

সংযোগ স্থাপন করতে আসলে কতক্ষণ লাগে?

আমরা যে প্রকল্পগুলোকে সমর্থন করি, সেগুলোতে প্রক্রিয়াটি দুই সপ্তাহ সময় নেয়: দুই দিনের ম্যাপিং, আমাদের ভ্যালিডেটর প্রথম এক্সপোর্টগুলো প্রক্রিয়া করতে তিন দিন, সমস্যা সমাধান করতে তিন দিন, এবং প্রথম পাস সার্টিফিকেট প্রকাশ করতে দুই দিন। দীর্ঘমেয়াদী কাজ কখনোই কোড নিজেই নয়, বরং যা ভ্যালিডেটর উন্মোচন করে - অনুপস্থিত ফিল্ড, অসামঞ্জস্যপূর্ণ কোডিং, এবং এমন মান যার জন্য কেউই দায়িত্ব নিতে চায় না। এই দিনগুলো বাদ না দিয়ে অবশ্যই সময়সূচীতে অন্তর্ভুক্ত করুন। যে প্রকল্প এগুলো এড়িয়ে যায়, তা ফাঁকগুলোও প্রকাশ করে ফেলে।

আমাদের কি একবারে সব পণ্য লিঙ্ক করতে হবে?

না। প্রথমে সেই পণ্যগুলো দিয়ে শুরু করুন যেগুলোর জন্য পাস প্রয়োজন, এবং একটি উৎস সিস্টেমের সাথে - নিরপেক্ষ স্কিমা আংশিক ক্যাটালগকে সম্পূর্ণ ক্যাটালগের মতোই সহজে গ্রহণ করে, এবং ইমপোর্টগুলো পুনরাবৃত্তিমূলক, তাই পরবর্তী রানগুলো ইনভেন্টরি আপডেট করবে। এতে ম্যাপিং কর্মশালা দুই দিনের মধ্যে শেষ করার জন্য যথেষ্ট সংক্ষিপ্ত থাকে। পরে এটিকে সম্প্রসারিত করা একটি ম্যাপিং কাজ, নতুন প্রকল্প নয়।

নিউজলেটারে একীকরণ টিপস

API প্যাটার্ন, ERP ও PIM ইন্টিগ্রেশন এবং ব্যবহারিক গাইড - প্রতি মাসে আপনার ইনবক্সে।