দুই সপ্তাহে ইআরপি ইন্টিগ্রেশন: আপনার নিজস্ব এপিআই ইন্টিগ্রেশনের জন্য একটি প্লেবুক

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

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

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

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

তত্ত্বগতভাবে, এই সমস্ত তথ্য আপনার ERP সিস্টেমে উপলব্ধ। তবে বাস্তবে, এটি ৪ থেকে ৭টি মডিউলে ছড়িয়ে আছে: মেটেরিয়ালস ম্যানেজমেন্ট (MM), প্রোডাকশন (PP), কোয়ালিটি ম্যানেজমেন্ট (QM), সাপ্লায়ার ম্যানেজমেন্ট (LFA1), কখনও কখনও পরিবেশগত ডেটার জন্য একটি পৃথক EHS মডিউল, এবং কখনও কখনও ফর্মুলেশনের জন্য একটি PLM সিস্টেম।

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

তিনটি পরীক্ষিত ইন্টিগ্রেশন প্যাটার্ন

প্যাটার্ন ১: OData / REST পুল

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

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

অসুবিধা: অতিরিক্ত API লেয়ার ছাড়া পুরনো SAP ECC ইনস্টলেশনের সাথে কাজ করে না। ডেটা অ্যাক্সেস অনুরোধের উপর আপনার গভর্নেন্স প্রয়োজন।

নমুনা ২: ইভেন্ট-ভিত্তিক ইন্টিগ্রেশন

SAP ইভেন্ট মেশ, Apache Kafka, RabbitMQ। আপনার ERP পরিবর্তন ইভেন্ট প্রকাশ করে; DPP প্রদানকারী সেগুলো গ্রহণ করে।

সুবিধা: প্রায় রিয়েল-টাইম, সুন্দরভাবে স্কেলযোগ্য, ডিকাপল্ড।

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

প্যাটার্ন ৩: মিডলওয়্যার / ETL

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

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

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

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

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

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

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

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

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

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

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

অনেকগুলো সিস্টেমে পণ্য মাস্টার ডেটা: SAP-এ আইটেম নম্বর আছে, PIM-এ ছবি এবং বিপণন টেক্সট আছে, PLM-এ বিল অফ ম্যাটেরিয়ালস আছে। কারোই কোনো সুসংগত দৃশ্য নেই। সমাধান: প্রকল্পের শুরুতে নির্ধারণ করুন কোন সিস্টেমটি কোন ফিল্ডের জন্য ‘সত্যের উৎস’ ।

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

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

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

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

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

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

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

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