AutoScheduler.AI ২১ সেপ্টেম্বর ২০২৬-এ তাদের AI App Builder ঘোষণা করে এবং জানায়, এটি তাদের Warehouse AI Platform-এ সাধারণ ব্যবহারের জন্য পাওয়া যাচ্ছে। গুদামকর্মীরা প্ল্যাটফর্মে যুক্ত কার্যক্রম-সংক্রান্ত তথ্য ও optimization সরঞ্জাম ব্যবহার করে সাধারণ ভাষায় অ্যাপের বর্ণনা দেন। কোম্পানির বক্তব্য, উপযুক্ত অ্যাপ গুদাম ব্যবস্থাপনা ব্যবস্থায়—অর্থাৎ WMS-এ—কাজ পাঠিয়ে তা বাস্তবায়নও করতে পারে। কোম্পানির ঘোষণা
কোনো শিফটের মধ্যে চোখে পড়া সমস্যার বিবরণ স্পষ্ট থাকতে থাকতেই সেটিকে কাজে লাগার মতো সরঞ্জামে রূপ দেওয়া—একটি সাইট ম্যানেজারের কাছে এটাই সুযোগ। সেই সরঞ্জাম সতর্কবার্তা দেখাবে, পরিবর্তনের পরামর্শ দেবে নাকি কাজ তৈরি করবে, তা আলাদা পরিচালনাগত সিদ্ধান্ত। কোনো অ্যাপ মজুত স্থানান্তরে প্রভাব ফেললে ভুলে সীমিত জায়গা এবং গুদামের কর্মীর সময় নষ্ট হতে পারে।
বড় পরিবর্তন
- কী বদলেছে: AutoScheduler-এর বক্তব্য, গুদাম দলগুলো এখন স্বাভাবিক ভাষায় নির্দেশ দিয়ে তাদের সংযুক্ত প্ল্যাটফর্মের ভেতরে অ্যাপ তৈরি করতে পারে। এটি ঘোষিত সক্ষমতা; কার্যক্রমে উন্নতির স্বাধীনভাবে মাপা ফল নয়।
- কেন গুরুত্বপূর্ণ: স্থানীয় জ্ঞান দ্রুত কার্যকর সফটওয়্যারে রূপ নিতে পারে, যা প্রচলিত দৃশ্যপটে ধরা না পড়া ব্যতিক্রম শনাক্ত করতে দলকে সাহায্য করবে। কাজ তৈরি করা অ্যাপকে বিদ্যমান পরিকল্পনা ও অনুমতিও মানতে হবে।
- কী লক্ষ করবেন: অ্যাপটি নির্দিষ্ট কোনো বিলম্ব ঠেকায় কি না—এবং একই স্থানান্তরের কাজ একাধিকবার তৈরি, এড়ানো যেত এমন বাড়তি নাড়াচাড়া, কিংবা শিফটের অন্যত্র সমস্যা সৃষ্টি না করে কি না।
গুদামের কাজের অর্থ বোঝা, পর্দার নকশার মতোই জরুরি
AutoScheduler-এর বর্তমান বাস্তবায়ন-পৃষ্ঠায় বিদ্যমান ব্যবস্থায় পড়ার প্রবেশাধিকার, ভাগ করা গুদাম-ধারণায় তথ্যের মানচিত্র তৈরি এবং সাইটের নিয়ম জানা পরিচালকদের মাধ্যমে যাচাইয়ের কথা আছে। সেখানে অ্যাপ তৈরি আর পুরো কার্যক্রমের মডেল তৈরি ও optimization-এর আলাদা পরিসরের কাজকে পৃথক করা হয়েছে। এটি প্রক্রিয়া সম্পর্কে বিক্রেতার বিবরণ; কোনো স্থাপিত ব্যবস্থার বিষয়ে আমাদের মূল্যায়ন নয়। প্ল্যাটফর্ম বাস্তবায়ন
মজুতের অভিন্ন সংজ্ঞা বিশেষভাবে জরুরি। “পাওয়া যাচ্ছে” লেখা কোনো সংখ্যা বোঝাতে পারে—পণ্য বাস্তবে আছে, নির্দিষ্ট অর্ডারে ব্যবহার করা যাবে, নাকি এখনো গ্রহণের অপেক্ষায় আছে। শুধু তথ্যক্ষেত্রগুলো পড়তে পারে বলেই অ্যাপ নিরাপদে এই অর্থগুলোকে এক করে ধরতে পারে না।
Microsoft-এর মজুত-সংক্রান্ত নথিতে এর নির্দিষ্ট উদাহরণ আছে: তাদের ব্যবস্থা হাতে থাকা এবং অর্ডার করা হলেও এখনো না-পাওয়া—দুই ধরনের পণ্য সংরক্ষণের সুযোগ দেয়। কোনো নির্দিষ্ট বিক্রয়-অর্ডারের জন্য সংরক্ষিত মজুত সেই সংরক্ষণ বাতিল না করা পর্যন্ত অন্য অর্ডারের জন্য সরিয়ে নেওয়া থেকেও সুরক্ষিত থাকে। এগুলো Dynamics 365-এর নথিভুক্ত আচরণ; AutoScheduler-এর সঙ্গে সংযোগ থাকার প্রমাণ নয়। মজুত সংরক্ষণ
অ্যাপ-নির্মাতার জন্য এর অর্থ, গুদাম-সংক্রান্ত দক্ষতা তথ্য-মডেলেও থাকতে হবে। হিসাব কোন পরিমাণ ধরে হবে এবং তার অবস্থা কী অনুমতি দেয়—কর্মীদের এ বিষয়ে একমত হতে হবে। বিভিন্ন ধরনের মজুত যোগ করা দৃশ্যপট আশ্বস্ত করতে পারে, অথচ প্রয়োজনের সময় বাছাইয়ের নির্দিষ্ট স্থানে ব্যবহারযোগ্য পণ্য নাও থাকতে পারে।
অভিজ্ঞ পরিকল্পনাকারী বুঝতে পারেন, কোন আগাম সতর্কতা কাজে লাগে আর কোন সংখ্যা নিয়মিত অপ্রয়োজনীয় খোঁজাখুঁজির কারণ হয়। সেই ব্যক্তি সরাসরি অ্যাপ তৈরিতে অংশ নিতে পারলে দল সমস্যাটি ব্যাখ্যা ও ভুল বোঝাবুঝি সংশোধনে কম সময় দিতে পারে। নির্দিষ্ট পার্থক্যটি সঠিকভাবে ধরতে পারলেই লাভ হবে—আর তা যাচাই করার জন্য মূল নথিও হাতে থাকবে।
যে ঘাটতির জন্য পুনরায় মজুতের কাজ আগেই তৈরি হয়েছে
একটি ইচ্ছাকৃতভাবে সরল উদাহরণ ধরা যাক। পণ্য বাছাইয়ের স্থানে ১৮টি কার্টন আছে। পাঠানোর শেষ সময়ের আগে অর্ডারে ৪২টি কার্টন লাগবে। আরও ২৪টি কার্টনের জন্য পুনরায় মজুতের কাজ ইতিমধ্যে তৈরি আছে, আর ওই স্থানে সর্বোচ্চ ৪৮টি কার্টন রাখা যায়। সব পরিমাণ একই এককে মাপা। এগুলো ব্যাখ্যার জন্য উদাহরণ—কোনো গ্রাহক-ফল বা নতুন পণ্যের পরীক্ষা নয়।
একটি অ্যাপ যদি শুধু বর্তমান মজুতের সঙ্গে চাহিদা তুলনা করে, তবে ২৪ কার্টনের ঘাটতি দেখবে। স্বয়ংক্রিয়ভাবে আরও ২৪ কার্টনের অনুরোধ পাঠালে আগে পরিকল্পিত কাজটির পুনরাবৃত্তি হবে। বাছাই শুরু হওয়ার আগেই দুই দফার পণ্য এসে গেলে মোট ৬৬ কার্টন হবে—স্থানটির ৪৮ কার্টনের ধারণক্ষমতার বেশি। হিসাব ঠিক, কিন্তু সিদ্ধান্তে বিদ্যমান অঙ্গীকার এবং বাস্তবে পণ্য সরানোর সময় বাদ পড়েছে।
আরও কার্যকর পর্যবেক্ষক যন্ত্রে ঘাটতির পাশাপাশি অপেক্ষমাণ পুনরায় মজুতের কাজটিও দেখাবে। এর প্রশ্ন হবে, মজুত দরকার হওয়ার আগে কাজটি শেষ হওয়ার সম্ভাবনা আছে কি না। দেরি হলে পরিকল্পনাকারী কারণ খতিয়ে দেখতে বা অনুমোদিত অগ্রাধিকার বদলাতে পারেন। আরেকটি স্থানান্তরের কাজ তৈরি করলেই বিলম্বের সমাধান হবে, এমন নয়।
বিদ্যমান গুদাম-সফটওয়্যারেও প্রাসঙ্গিক পরিকল্পনা-যুক্তি রয়েছে। Microsoft-এর পুনরায় মজুত-সংক্রান্ত নথিতে template দিয়ে ঠিক করা চাহিদা-ভিত্তিক এবং সর্বনিম্ন/সর্বোচ্চ কৌশলের বর্ণনা আছে। নির্দিষ্ট সেটিংয়ে চাহিদা অনুযায়ী মজুতের হিসাবে আগে থেকেই চলমান পুনরায় মজুতের কাজে সংরক্ষিত নয়—এমন পরিমাণও ধরা যেতে পারে। WMS-এর চারপাশে দ্বিতীয় সিদ্ধান্তকারী যোগ করার আগে এর কনফিগারেশন পরীক্ষা করার কথাই এটি মনে করিয়ে দেয়। পুনরায় মজুতের পরিচিতি
অ্যাপটি একটি ব্যতিক্রম পরিষ্কার করে দেখাতে পারে: অর্ডারটি এমন একটি পুনরায় মজুতের ওপর নির্ভর করছে, যা প্রত্যাশামতো এগোয়নি। এই যোগসূত্র দেখালে পরিকল্পনাকারীকে একাধিক পর্দার তথ্য মিলিয়ে দেখতে কম সময় লাগতে পারে। প্রাসঙ্গিক নথি কতক্ষণ আগে হালনাগাদ হয়েছে, সেটিও দেখানো উচিত। পণ্য সরানোর কাজ শেষ হলেও নিশ্চয়তা না এলে, কাউকে আবার পাঠানোর কারণ হিসেবে সেটি নীরবে ব্যবহার করা যাবে না।
ধারণক্ষমতার কারণে পুনরায় মজুতের কাজ অপেক্ষায় রাখা যুক্তিসংগত হতে পারে। Dynamics 365-এ এমন সুবিধার নথি আছে, যেখানে কোনো স্থানের ধারণক্ষমতার চেয়ে বেশি কাজ তৈরি করা গেলেও মজুত যথেষ্ট কমা পর্যন্ত কাজটি শেষ করার অনুমোদন আটকে রাখা হয়। এক মুহূর্তে পরিকল্পিত চাহিদা উপলভ্য স্থানের চেয়ে বেশি হতে পারে। স্থানের ধারণক্ষমতা সামলানো
তাই আমাদের উদাহরণে অপেক্ষমাণ কাজটির অবস্থা পরীক্ষা করা দরকার। প্রতিটি অপেক্ষমাণ কাজকে ব্যর্থ বলে চিহ্নিত করা অ্যাপ কর্মীদের যুক্তিসংগত সীমা ভাঙতে চাপ দিতে পারে। সতর্কবার্তার সঙ্গে যুক্ত ব্যাখ্যাও তার পরিচালনাগত মূল্যের অংশ।
অ্যাপ প্রকাশের অনুমতি আর কাজ তৈরি করার অনুমতি এক নয়
AutoScheduler-এর বাস্তবায়ন নির্দেশিকায় আলাদা প্রবেশাধিকার-ভূমিকা, নির্দিষ্ট পরিচালনাগত দায়িত্বপ্রাপ্ত ব্যক্তি এবং কাজ না পাঠিয়ে তা পরীক্ষা করার বিবরণ আছে। তাদের FAQ বলছে, আগে অনুমোদিত পদক্ষেপগুলো সংযুক্ত ব্যবস্থায় বাস্তবায়নের সুযোগ সচেতনভাবে চালু করতে হয়। পণ্য মূল্যায়নে এই নথিভুক্ত নিয়ন্ত্রণগুলো প্রাসঙ্গিক; তবে নির্দিষ্ট সাইটে সেগুলো আছে ও কীভাবে কনফিগার করা, তা আলাদাভাবে যাচাই করতে হবে। পদক্ষেপ ও পরিচালনব্যবস্থা
মজুত পুনরায় ভরার পর্যবেক্ষকটির প্রাথমিক পরিসর হতে পারে ঝুঁকিতে থাকা কাজ দেখানো এবং পরিকল্পনাকারীকে জানানো। এতে মেঝেতে নতুন স্থানান্তরের কাজ না বাড়িয়ে যুক্তি অর্থবহ ব্যতিক্রম শনাক্ত করছে কি না পরীক্ষা করা যায়। পরে সাইট কাজ তৈরি বা অগ্রাধিকার বদলানোর অনুমতি দিলে কোন পদক্ষেপ নেওয়া যাবে এবং নির্দেশ WMS-এ পৌঁছানোর সময় কোন শর্তগুলো তখনও মানতে হবে—তা সুনির্দিষ্ট করে দিতে হবে।
গ্রহণকারী ব্যবস্থাটিও গুরুত্বপূর্ণ। নির্দেশ পাঠানোর সময়ের মধ্যে অ্যাপের আগের পর্যবেক্ষণ পুরোনো হয়ে যেতে পারে। অন্য কোনো ব্যবহারকারী কাজটি বদলে থাকতে পারেন বা মজুত সংরক্ষণ করতে পারেন। সংযোগ ব্যবস্থায় বর্তমান অবস্থা পরীক্ষা করে অনুরোধ গৃহীত, প্রত্যাখ্যাত, নাকি মনোযোগ প্রয়োজন—তা জানাতে হবে। শুধু অনুরোধ পাঠানো সফল হলেই গুদামের পণ্য সরানো হয়েছে প্রমাণ হয় না।
অ্যাপ বন্ধ করলেও সীমাবদ্ধতা থাকে। নকশা করা থাকলে এটি ভবিষ্যতের অনুরোধ আটকাতে পারে, কিন্তু ইতিমধ্যে সরানো কার্টন শারীরিকভাবে আগের জায়গায় ফেরাতে পারে না। বরাদ্দ হয়ে যাওয়া কাজ নিয়ে সাইটের স্বাভাবিক পরিচালনাপ্রক্রিয়ায় সমন্বিত সিদ্ধান্ত দরকার। অ্যাপটির মালিককে জানতে হবে এ পরিণতি কে সামলাবেন—বিশেষ করে যিনি অ্যাপটি বানিয়েছেন তিনি অনুপস্থিত থাকলে।
স্থানীয় উন্নতি একই সম্পদের জন্য প্রতিযোগিতা করতে পারে
কোনো সরঞ্জাম বারবার দেখা দেওয়া, ভালোভাবে বোঝা একটি বাদ পড়া বিষয় সামলালে আশাবাদী সম্ভাবনাটি সবচেয়ে জোরালো হয়। পরিকল্পনাকারী দেখেন, প্রচলিত ড্যাশবোর্ডে স্পষ্ট হওয়ার আগেই একটি শ্রেণির মজুত পূরণের কাজ জরুরি হয়ে পড়ে। লক্ষ্যভিত্তিক পর্যবেক্ষকটি অপ্রয়োজনীয় পুনঃতদন্ত ঠেকানোর মতো যথেষ্ট প্রসঙ্গসহ সমস্যাটি আগে দেখাতে পারে। ব্যতিক্রমটি জানা কর্মীরা শিফটে ব্যবহৃত তথ্য সরাসরি উন্নত করার সুযোগ পাবেন।
হতাশাবাদী চিত্রটি হলো, আপাতদৃষ্টিতে যুক্তিসংগত অনেক অ্যাপ বারবার অগ্রাধিকার বদলায়। একটি মজুত পূরণের কাজ এগিয়ে দেয়, আরেকটি পণ্য পাঠানো ত্বরান্বিত করে, তৃতীয়টি পণ্য গ্রহণকে অগ্রাধিকার দেয়। প্রত্যেকটি যদি একই কর্মী বা সরঞ্জাম পাওয়া যাবে ধরে নেয়, তবে এক সারি উন্নত করতে গিয়ে অন্যটি অপেক্ষায় পড়তে পারে। অভিন্ন তথ্য-উৎস থাকলেই প্রতিদ্বন্দ্বী লক্ষ্যগুলোর মীমাংসা হয় না।
অ্যাপগুলোর মধ্যকার বিরোধ কে মেটাবেন, সাইটের নেতাদের তা চিহ্নিত করা উচিত। কোনো সরঞ্জাম দ্রুত পণ্য সরানোর পরামর্শ দিতে পারে, অথচ বৃহত্তর পরিকল্পনা আরও গুরুত্বপূর্ণ সময়সীমার জন্য সম্পদ রেখে দেয়। এই মতভেদের পরিচালনাগত ব্যাখ্যা থাকা দরকার। সুপারিশটি কেন বাস্তবসম্মত ছিল না তা কর্মীরা জানাতে পারবেন, যাতে স্থানীয়ভাবে কাজে লাগা ব্যতিক্রম স্থায়ীভাবে বিভ্রান্তিকর নিয়ম না হয়ে দাঁড়ায়।
অ্যাপটি যে বিলম্ব সরানোর কথা, সেটাই মাপুন
পণ্য চালুর ঘোষণা একটি পণ্যের দাবি প্রতিষ্ঠা করে; অন্য গুদামে এর সুফল কতটা, তা নয়। ব্যবস্থাপক আরও সীমিত প্রশ্নে মজুত-পূরণ অ্যাপটি মূল্যায়ন করতে পারেন: দেরিতে পণ্য আসার কারণে বাছাইয়ের কাজ ব্যাহত হওয়া কি কমেছে—অথচ অপ্রয়োজনীয় নাড়াচাড়া বা অন্যত্র অঙ্গীকার রক্ষা না করার ঘটনা বাড়েনি?
কোন সতর্কতা থেকে পদক্ষেপ নেওয়া হয়েছে, সংশ্লিষ্ট কাজটির কী হয়েছে এবং পদক্ষেপটি কাজে লেগেছে কি না—তার নথি দরকার। নীরব অ্যাপ সমস্যা চোখ এড়াতে পারে; অতিরিক্ত সতর্কবার্তা দেওয়া অ্যাপ নতুন কাজ তৈরি করতে পারে। উপেক্ষা করা সতর্কবার্তার নমুনাও পরীক্ষা করুন, গৃহীত সুপারিশও; আর চাহিদা ও কর্মীসংখ্যার পার্থক্য মাথায় রেখে বিভিন্ন শিফটের তুলনা করুন।
অ্যাপ বানাতে ব্যয় করা সময়ের সঙ্গে তথ্যের মানচিত্র করা, সুপারিশ যাচাই এবং সরঞ্জাম রক্ষণাবেক্ষণের ব্যয়ও হিসাব করতে হবে। দ্রুত নির্মাণ তখনো লাভজনক হতে পারে, যদি প্রথম সংস্করণ শুধু কী ঘটছে তা ভালোভাবে দেখায়। কিন্তু চলমান ব্যয় ন্যায্যতা পাওয়ার জন্য কাউকে যথেষ্ট নিয়মিত ভালো গুদাম-সিদ্ধান্ত নিতে সাহায্য করতে হবে।
পরের প্রদর্শনীতে অ্যাপ-নির্মাতাকে এমন ঘাটতি দিন, যার জন্য পণ্য ইতিমধ্যেই পথে রয়েছে। কাজটি দেরি হলে, শেষ হলে কিংবা ধারণক্ষমতার কারণে আটকে গেলে কী করা উচিত—তা ব্যাখ্যা করতে বলুন। সুন্দর পর্দা কত দ্রুত তৈরি করে তার চেয়ে এতে এর উপযোগিতা বেশি স্পষ্ট হবে।
