সাশ্রয় কি সত্যি? Bottleneck এবং সংখ্যা টাকায় রূপান্তরিত হওয়ার তিনটি পথ

এই গাইড costing শেখানোর জন্য নয় -- সেই কাজ industry guide-গুলো করে। এটি সেই প্রশ্নের উত্তর দেয় যা প্রতিটি cost sheet-এর পেছনে দাঁড়িয়ে থাকে: আপনি যে সাশ্রয় বের করেছেন, তার অর্থ কি প্লান্টের হাতে সত্যিই তত টাকা বেশি আছে?

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

প্রতিটি প্লান্ট দেখেছে এমন উদাহরণ

আপনি একটি operation উন্নত করলেন এবং cycle time ছয় মিনিট থেকে চার মিনিট হয়ে গেল। Sheet দুই মিনিটকে machine hour rate ও বার্ষিক volume দিয়ে গুণ করে একটি সুন্দর সংখ্যা দেখায়।

কিন্তু সেই operation যদি কখনো constraint নাই হয়ে থাকে -- যদি এটি আগে থেকেই আগের operation বা order-এর জন্য অপেক্ষা করছিল -- তাহলে improvement-এর পর প্লান্ট একই পরিমাণ dispatch করবে, একই বেতন দেবে এবং একই বিদ্যুৎ খাবে। যা বেড়েছে তা শুধু idle time।

সংখ্যা থেকে প্রকৃত টাকা পর্যন্ত মাত্র তিনটি পথ

মাত্র তিনটি, এবং অন্তত একটির নাম আপনার বলতে পারা উচিত:

1. কোনো ব্যক্তি বা shift সরে যায় -- বেতন দেওয়া সত্যিই বন্ধ হয়।
2. আপনি বেশি বিক্রি করেন -- খালি হওয়া capacity প্রকৃত বিদ্যমান order দিয়ে পূরণ হয়।
3. কোনো লাইনের খরচ কমে যার invoice আসে -- কম উপকরণ, কম বিদ্যুৎ, কম outsourcing।

তৃতীয় পথটি সবচেয়ে বিশ্বাসযোগ্য এবং রক্ষা করা সবচেয়ে সহজ, কারণ এটি stores issue slip বা supplier invoice-এ চিহ্ন রেখে যায়। প্রথম দুটির জন্য কাউকে সিদ্ধান্ত নিতে হয়; সেগুলো নিজে নিজে হয় না।

Constraint-ই পুরো লাইনের output নির্ধারণ করে

Bottleneck হলো সবচেয়ে ধীর operation, এবং পুরো লাইনের output তার সমান হয়। বাকি সব operation, যত দ্রুতই হোক, শেষমেশ তারই অপেক্ষা করে।

এর দুটি ফলাফল আছে, এবং দ্বিতীয়টিই বাদ পড়ে:

• Constraint-এ বাঁচানো এক ঘণ্টা পুরো প্লান্টের জন্য এক ঘণ্টার বাড়তি output।
• অন্য কোথাও বাঁচানো ঘণ্টা কিছুই বদলায় না -- যতক্ষণ না সেই খালি সময় দিয়ে shift কমান, মানুষ কমান, বা আরও tight resource-এর কাজ তাতে বসান।

Constraint খুঁজতে time study লাগে না: লাইন ধরে হাঁটুন এবং সেই operation খুঁজুন যার সামনে মাল জমে আছে এবং পেছনে কেউ অপেক্ষা করছে না। অথবা জিজ্ঞাসা করুন সবসময় কোন operation-এ overtime হয়।

Constraint ঘোষণা করুন এবং সিস্টেমকে যাচাই করতে দিন

Labour ও machine উভয় section-এ একটি field আছে যা জিজ্ঞাসা করে এই লাইনটি constraint কিনা। এটি গণনায় অংশ নেয় না: এতে কিছু যোগ, বিয়োগ বা গুণ হয় না।

এর একমাত্র কাজ সতর্কতা চালু করা: কোনো লাইনকে constraint বলে ঘোষণা না করলে এবং সেই একই লাইন সাশ্রয় দেখালে, সিস্টেম স্পষ্ট বলে দেয় এই টাকা হয়তো শুধু idle time।

তাই কোনো লাইনকে constraint নয় বলা আপনার case দুর্বল করে না। এটি আপনাকে reviewer-এর আগেই প্রশ্ন করায় -- এবং তারপরও উপরের তিনটি পথের একটি বলতে পারলে, সেই পথ verification section-এ লিখুন এবং case ঠিক হয়ে যাবে।

Cash saving ও cost avoidance একই দাবি নয়

দুটোই বৈধ। দুটো একে অপরের বদলে ব্যবহার করা যায় না, এবং পাঠকের জানা দরকার আপনি কোনটির দাবি করছেন।

Cost avoidance সত্যি, কিন্তু এটি একটি অনুমানের উপর দাঁড়িয়ে -- যে সেই খরচ সত্যিই আসার কথা ছিল। সেই অনুমান লিখে রাখুন, পাঠকের উপর অনুমান ছেড়ে দেবেন না।

যখন সংখ্যা খারাপ দেখায় এবং পরিবর্তন তবুও সঠিক

কিছু improvement খরচ বৃদ্ধি হিসেবে বের হয় এবং তবুও সঠিক হয়। সবচেয়ে স্পষ্ট ক্ষেত্র batch size কমানোর: বছরে setup বেশি, তাই per part setup cost বাড়ে।

বিনিময়ে যা পাওয়া যায় -- কম lead time, কম WIP, তাড়াতাড়ি ধরা পড়া defect -- তা unit cost sheet মাপতেই পারে না, এবং batch size কমতে দেখলেই সিস্টেম সরাসরি এই কথা বলে দেয়।

Publish করার আগে পাঁচটি প্রশ্ন

1. এই improvement constraint-এ নাকি অন্য কোথাও?
2. অন্য কোথাও হলে: টাকা পর্যন্ত তিনটি পথের কোনটি আমি সত্যিই বলতে পারি?
3. এটি cash saving নাকি cost avoidance? আমি বলেছি কি?
4. Cost avoidance হলে: তার পেছনের অনুমান লেখা আছে?
5. এমন কোনো সুবিধা আছে যা sheet মাপতে পারে না? সেটা mechanism section-এ আছে কি?

এই পাঁচটির কোনোটিই আপনার সংখ্যা ছোট করে না। এগুলো সেটিকে প্রশ্নের সামনে টিকে থাকার যোগ্য করে তোলে -- এবং এটাই নির্ধারণ করে অন্য কোনো প্লান্ট কখনো আপনার কাজ copy করবে কিনা।