‘সীমহীন ইআরপি ইন্টিগ্রেশন’ একটি মানক প্রতিশ্রুতি, যা বাস্তবে তিন মাসের একটি প্রকল্পের মাধ্যমে অনুসরণ করা হয়। আমরা আমাদের এপিআই প্লেবুক প্রকাশ করছি যাতে আপনার আইটি দল চুক্তি স্বাক্ষরের আগে প্রকৃতপক্ষে কোন ডেটা অনুরোধ করা হচ্ছে তা পরীক্ষা করতে পারে। একটি ইন্টিগ্রেশন প্রকল্প শুরু করার আগে আপনাকে যা জানতে হবে তা এখানে।
আপনার 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 এক্সপোর্ট, আমাদের ভ্যালিডেটরের মাধ্যমে চালানো হয়।
- দিন ৬ থেকে ৮: সমস্যা সমাধান (অভাবিত ফিল্ড, অসামঞ্জস্যপূর্ণ কোডিং)।
- দিন ৯ থেকে ১০: প্রথম DPP-গুলো লাইভ হয়।
তিন মাস নয়, দুই সপ্তাহ। মূল বিষয় হল ম্যাপিং কর্মশালা - এখানেই ডেটার গুণগত মান নির্ধারিত হয়।
কি ভুল হয়: সবচেয়ে সাধারণ সমস্যাগুলো
অনেকগুলো সিস্টেমে পণ্য মাস্টার ডেটা: SAP-এ আইটেম নম্বর আছে, PIM-এ ছবি এবং বিপণন টেক্সট আছে, PLM-এ বিল অফ ম্যাটেরিয়ালস আছে। কারোই একটি সামঞ্জস্যপূর্ণ দৃষ্টিভঙ্গি নেই। সমাধান: প্রকল্প শুরু হওয়ার আগে, প্রতিটি ক্ষেত্রের জন্য কোন সিস্টেমটি ‘সত্যের উৎস’ হবে তা নির্ধারণ করুন।
পিডিএফ হিসেবে সার্টিফিকেট: সরবরাহকারীরা GOTS, OEKO-TEX বা REACH সার্টিফিকেট স্ক্যানকৃত পিডিএফ হিসেবে প্রদান করে। এটি কোনো কাঠামোবদ্ধ ডেটা উৎস নয়। সমাধান: সার্টিফিকেশন সংস্থাগুলো ক্রমশ API কোয়েরি অফার করছে (OEKO-TEX এ ক্ষেত্রে অগ্রণী, যেখানে GOTS পিছিয়ে আছে)। বিকল্পভাবে: ডেটা ম্যানুয়ালি এন্ট্রি করুন, তবে মেয়াদোত্তীর্ণ কোনো সার্টিফিকেট DPP-তে না দেখানোর জন্য মেয়াদোত্তীর্ণতার তারিখ অন্তর্ভুক্ত করুন।
ফর্মুলেশন গোপনীয়তা: বিশেষ করে প্রসাধনী, খাদ্য ও ফার্মাসিউটিক্যালসে, সম্পূর্ণ ফর্মুলেশন একটি ব্যবসায়িক গোপনীয়তা। DPP কি এগুলো প্রকাশ করা উচিত? সমাধান: ESPR-এর তিন-স্তরের মডেল। পণ্য বিভাগটি সর্বজনীনভাবে উপলব্ধ; নিয়ন্ত্রক কর্তৃপক্ষ সম্পূর্ণ ফর্মুলেশন দেখতে পারে। এটি প্রায় কখনোই কোনো বাধা সৃষ্টি করে না, তবে প্রাথমিক পর্যায়েই এটি স্পষ্ট করে নিতে হবে।
CO₂ ডেটা সরবরাহকারীদের উপর ভিত্তি করে: আপনার সরবরাহকারী তার পুরো পোর্টফোলিওর জন্য গড় মান প্রদান করে, প্রতি ব্যাচের জন্য নয়। সমাধান: অস্থায়ীভাবে এটি গ্রহণ করুন; দীর্ঘমেয়াদে সরবরাহকারী চুক্তি সামঞ্জস্য করুন। ESPR একটি নির্দিষ্ট কাট-অফ তারিখ থেকে পণ্য-নির্দিষ্ট মানের প্রয়োজন, কিন্তু বর্তমান অনুশীলন একটি আপস।
স্থানীয় ভাষার সংস্করণ: আপনার ERP সিস্টেমে শুধুমাত্র জার্মান এবং ইংরেজি ভাষায় পণ্যের নাম রয়েছে। 27টি EU দেশের জন্য, আপনাকে আরও ভাষা প্রয়োজন। সমাধান: পরিভাষা ডাটাবেস ব্যবহার করে মেশিন অনুবাদ; এ বিষয়ে আমাদের একটি পৃথক নিবন্ধ রয়েছে।
প্রকল্প শুরু করার আগে আপনাকে যে প্রশ্নগুলো করতে হবে
তিনটি সরবরাহকারীর কাছে RFP পাঠানোর আগে, নিম্নলিখিত প্রশ্নগুলির উত্তর অভ্যন্তরীণভাবে দিন:
১. কতটি পণ্য/আইটেম নম্বরের DPP থাকা উচিত? (১০, ১০,০০০, ১০ লক্ষ?) ২. কোন সিস্টেমগুলি বর্তমানে DPP-সম্পর্কিত ডেটা ধারণ করে? ৩. এই প্রতিটি সিস্টেম কোন বিভাগ পরিচালনা করে? ৪. আপনার কি এমন কোনো মিডলওয়্যার বিনিয়োগ আছে যা ব্যবহার করা উচিত? ৫. আপনার ERP-এর উপরে কি ইতিমধ্যেই কোনো API লেয়ার আছে?
উত্তরগুলো নির্ধারণ করবে তিনটি মডেলের মধ্যে কোনটি আপনার জন্য সঠিক। এবং এগুলো নির্ধারণ করবে একটি প্রকল্প দুই সপ্তাহ নেবে নাকি ছয় মাস।