Garments Production Planning-এ Order Delay আগে থেকে বুঝবেন কীভাবে: দৈনিক ডেটা থেকে ৮টি Early Warning Signal

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

TNA ক্যালেন্ডার বলে দেয় কোন কাজ কবে শেষ হওয়ার কথা। কিন্তু TNA-র তারিখ পার হওয়ার পর জানলে দেরি হয়ে গেছে। Early warning মানে তারিখ পার হওয়ার আগেই, গতিপথ দেখে বোঝা যে এই গতিতে চললে তারিখ মিলবে না।

প্রথমে দরকার একটি বাস্তবসম্মত Target

Delay ধরার সব হিসাব target-এর সঙ্গে তুলনায় দাঁড়িয়ে থাকে। Target যদি শুরু থেকেই অবাস্তব হয়, তাহলে প্রতিদিনই “পিছিয়ে” দেখাবে এবং কেউ আর সংকেতকে গুরুত্ব দেবে না। Target আসে line capacity থেকে:

Line capacity (pcs/day) = (Operator সংখ্যা × দৈনিক কর্মমিনিট × প্রত্যাশিত Efficiency %) ÷ SMV

SMV (Standard Minute Value) হলো একটি পোশাক তৈরিতে স্ট্যান্ডার্ড সময়, আর Efficiency হলো লাইন সেই স্ট্যান্ডার্ডের কত শতাংশ গতিতে কাজ করছে। সূত্র ও উদাহরণ বিস্তারিত আছে SMV ও Sewing Line Efficiency Calculation লেখায়। এখানে মনে রাখার বিষয় দুটি:

• নতুন স্টাইলের প্রথম দুই-তিন দিন efficiency কম থাকে (learning curve)। Target-এ এটি ধরা না থাকলে প্রথম সপ্তাহের সংকেত ভুল পড়া হবে।

• Target ঠিক করতে হবে “এই লাইনের গত তিন মাসের গড় efficiency” দিয়ে, কল্পিত ৭০–৮০ শতাংশ দিয়ে নয়।

যে চারটি সংখ্যা প্রতিদিন হিসাব করবেন

দৈনিক production report-এ লাইনপ্রতি output লেখা থাকে। কিন্তু output একা কিছু বলে না; নিচের চারটি derived সংখ্যা বলে।

১. Achievement %

Achievement % = দৈনিক Actual output ÷ দৈনিক Target × 100

একদিন ৮৫ শতাংশ হওয়া স্বাভাবিক। টানা তিন দিন ৮৫ শতাংশের নিচে থাকা সংকেত।

২. Cumulative shortfall

Cumulative shortfall = Σ (দৈনিক Target − দৈনিক Actual), উৎপাদন শুরুর দিন থেকে আজ পর্যন্ত

প্রতিদিনের ছোট ঘাটতি জমে কত হলো, সেটাই এই সংখ্যা। এক দিনের target-এর সমান হয়ে গেলে বুঝতে হবে এক দিন পিছিয়ে আছেন।

৩. Required daily rate

Required daily rate = বাকি quantity ÷ বাকি কর্মদিবস (shipment-এর আগে finishing ও packing-এর দিন বাদ দিয়ে)

এটিই সবচেয়ে কার্যকর সংকেত। Required rate যদি প্রতিদিন বাড়তে থাকে, মানে লাইন ঘাটতি পূরণ করছে না। আর required rate যদি লাইনের capacity ছাড়িয়ে যায়, তাহলে Overtime বা বাড়তি লাইন ছাড়া অর্ডার যাবে না—এটা আগে জানলে সস্তায় সমাধান হয়।

৪. Projected finish date

Projected finish = আজ + (বাকি quantity ÷ গত ৫ দিনের গড় Actual output) কর্মদিবস

Target নয়, বাস্তব গড় দিয়ে ভাগ করুন। এই তারিখ যদি TNA-র sewing complete তারিখের পরে পড়ে, সেটাই Delay-র আগাম ঘোষণা।

একটি অর্ডারের গতিপথ — উদাহরণ (কাল্পনিক সংখ্যা)

নিচের সংখ্যাগুলো শুধু পদ্ধতি বোঝানোর জন্য; কোনো বাস্তব ফ্যাক্টরির তথ্য নয়।

৮ম দিনের শেষে হিসাব:

• মোট উৎপাদন = (3 × 900) + (5 × 1,200) = 2,700 + 6,000 = 8,700 pcs

• Target অনুযায়ী হওয়ার কথা = 8 × 1,500 = 12,000 pcs

• Cumulative shortfall = 12,000 − 8,700 = 3,300 pcs (দুই দিনের বেশি target)

• বাকি quantity = 30,000 − 8,700 = 21,300 pcs; বাকি দিন = 12

• Required daily rate = 21,300 ÷ 12 = 1,775 pcs/day—লাইনের capacity 1,600-এর চেয়ে বেশি

• Projected finish = 21,300 ÷ 1,200 = 17.75 → ১৮ কর্মদিবস, অথচ হাতে আছে ১২। অর্থাৎ এই গতিতে প্রায় ৬ দিন দেরি।

এই উদাহরণে ৮ম দিনেই পরিষ্কার: learning curve পার হওয়ার পরও লাইন target-এর ৮০ শতাংশে আটকে আছে, আর required rate capacity ছাড়িয়ে গেছে। এখন সিদ্ধান্ত নেওয়ার সময়—১২ দিন হাতে রেখে। ১৮তম দিনে একই হিসাব করলে সিদ্ধান্তের জায়গা থাকত না।

গুরুত্বপূর্ণ কথা: ৪র্থ দিনেই সংকেত ছিল। Learning curve শেষে output 1,200-এ এসে থেমে গেছে, 1,500-এ ওঠেনি। যে ফ্যাক্টরিতে required daily rate প্রতিদিন হিসাব হয়, সেখানে ৪র্থ-৫ম দিনেই প্রশ্নটা উঠত: কেন উঠছে না?

৮টি Early Warning Signal: সংকেত → মানে → করণীয়

শেষ সংকেতটি আলাদা করে বলা দরকার। অনেক ফ্যাক্টরিতে দেরির প্রথম প্রতিক্রিয়া OT। কিন্তু OT দিয়ে যদি output না বাড়ে, তাহলে খরচ বাড়ছে আর দেরিও থাকছে। OT dependency কমানোর প্রথম ধাপ এই সংকেতটি সময়মতো ধরা।

Downtime: যে সময় রিপোর্টে থাকে না

দৈনিক রিপোর্টে output লেখা হয়, কিন্তু মেশিন নষ্ট, সুতা নেই, বিদ্যুৎ নেই, approval sample আসেনি—এই সময়গুলো সাধারণত কোথাও লেখা হয় না। ফলে output কম হলে দোষ পড়ে operator-এর ওপর, অথচ কারণ ছিল অন্য কোথাও।

Downtime % = মোট থেমে থাকা মিনিট ÷ (Operator সংখ্যা × দৈনিক কর্মমিনিট) × 100

লাইন সুপারভাইজারকে দিয়ে শুধু তিনটি তথ্য লেখান: কখন থামল, কতক্ষণ, কেন (মেশিন / material / বিদ্যুৎ / অন্য)। এক সপ্তাহের ডেটা জমলেই দেখা যায় কোন কারণটা বারবার আসছে। Capacity সূত্রে প্রত্যাশিত efficiency-র ভেতরে downtime ধরা থাকে; বাস্তব downtime তার চেয়ে বেশি হলে target আর মিলবে না।

Material: Production-এর আগেই যে Delay শুরু হয়

Sewing floor-এ যে দেরি দেখা যায়, তার একটা বড় অংশ আসলে শুরু হয় fabric বা trims in-house হওয়ার আগে। প্রতিটি চলমান ও আসন্ন অর্ডারের জন্য তিনটি প্রশ্নের উত্তর সাপ্তাহিক মিটিংয়ে থাকা উচিত:

• Fabric কত শতাংশ in-house, বাকিটার ETA কবে, আর সেটি cutting plan-এর সঙ্গে মেলে কি না?

• Trims ও accessories-এর কোন আইটেম এখনো আসেনি, আর সেটি কোন operation-এ লাগবে—শুরুতে না শেষে?

• Approval (lab dip, trim card, PP sample) কোনটি pending, আর তার জন্য কোন কাজ আটকে আছে?

Material-এর দেরি sewing-এর হিসাবে ধরা পড়ে না, কারণ তখনো production শুরু হয়নি। তাই TNA-র material milestone-গুলো আলাদা করে ট্র্যাক করতে হয়।

Escalation: কে, কখন, কী করবে

সংকেত ধরা পড়ার পর যদি ঠিক না থাকে কে সিদ্ধান্ত নেবে, তাহলে ধরা পড়েও লাভ নেই। একটি সহজ তিন স্তরের নিয়ম:

1. লাইন স্তর (একই দিনে): Achievement % ৮৫-এর নিচে বা একটি station-এ WIP জমলে সুপারভাইজার সেদিনই line balancing ঠিক করবেন।

2. Production manager স্তর (২৪ ঘণ্টায়): Cumulative shortfall এক দিনের target ছাড়ালে বা required rate capacity-র ৯০ শতাংশের ওপরে উঠলে—বাড়তি operator, শিফট বা লাইন ভাগ করার সিদ্ধান্ত।

3. ম্যানেজমেন্ট ও merchandising স্তর (৪৮ ঘণ্টায়): Projected finish TNA-র তারিখ ছাড়ালে Buyer-এর সঙ্গে আলোচনা—আংশিক shipment, তারিখ পরিবর্তন বা উৎপাদন অন্য ইউনিটে সরানো।

প্রতিটি স্তরের জন্য থ্রেশহোল্ড সংখ্যায় লেখা থাকলে “মনে হচ্ছে একটু পিছিয়ে আছি” ধরনের অস্পষ্ট আলোচনা বন্ধ হয়।

দৈনিক Production Monitoring চেকলিস্ট

প্রতিদিন সকালে, আগের দিনের রিপোর্ট হাতে নিয়ে, প্রতিটি চলমান অর্ডারের জন্য:

• প্রতিটি লাইনের Achievement % হিসাব হয়েছে এবং ৮৫-এর নিচে থাকা লাইন চিহ্নিত?

• Cumulative shortfall আপডেট হয়েছে?

• Required daily rate হিসাব হয়েছে এবং গতকালের সঙ্গে তুলনা হয়েছে—বাড়ছে না কমছে?

• Projected finish date TNA-র sewing complete তারিখের সঙ্গে মেলানো হয়েছে?

• Downtime-এর কারণ ও মিনিট লেখা হয়েছে?

• Rework/alter সংখ্যা output থেকে আলাদা করে দেখা হয়েছে?

• আগামী ৭ দিনে যে material বা approval লাগবে, তার status জানা আছে?

• কোনো থ্রেশহোল্ড পার হলে নির্ধারিত ব্যক্তিকে জানানো হয়েছে?

এই আটটি প্রশ্নের উত্তর দিতে পাঁচ-সাতটি লাইনের ফ্যাক্টরিতে Excel-এ ১৫–২০ মিনিট লাগে, যদি দৈনিক রিপোর্ট সময়মতো আসে। সমস্যা হয় যখন রিপোর্ট দুপুরে আসে, cutting-এর তথ্য আলাদা খাতায় থাকে, আর store-এর in-house status কেউ জানে না। তখন হিসাবটা করা হয় সপ্তাহে একবার, আর সংকেত ধরা পড়ে দেরিতে।

ডেটা একসঙ্গে থাকলে সংকেত নিজে থেকেই দেখা যায়

উপরের প্রতিটি হিসাবের উপাদান—target, দৈনিক output, cutting input, material status, TNA তারিখ—ফ্যাক্টরির ভিন্ন ভিন্ন বিভাগে তৈরি হয়। Garments ERP-র module ও প্রসেস ফ্লো নিয়ে লেখাটিতে দেখানো হয়েছে কীভাবে merchandising, store ও production-এর তথ্য একটি ধারায় প্রবাহিত হলে এই মেলানোর কাজটা আর হাতে করতে হয় না। যে ফ্যাক্টরি এখনো Excel-এ আছে, তাদের জন্য প্রথম ধাপ সফটওয়্যার নয়—প্রথম ধাপ হলো উপরের চারটি সংখ্যা প্রতিদিন একই সময়ে, একই টেমপ্লেটে হিসাব করার অভ্যাস। Vertically integrated গ্রুপের জন্য Octapus Solution-এর Matrix ERP (বর্তমানে Beta / early access) merchandising-এর TNA-তে কোনো তারিখ পিছিয়ে গেলে alert দেওয়ার সুবিধা রাখে; তবে সংকেত পড়ার নিয়মটা যেকোনো টুলের আগে ফ্যাক্টরির নিজস্ব অভ্যাস হতে হয়।

আপনার ফ্যাক্টরির production monitoring ও daily reporting প্রক্রিয়া নিয়ে কথা বলতে চাইলে আমাদের সঙ্গে যোগাযোগ করুন।