Root Cause Analysis-এর ৫টি জনপ্রিয় টুল: সমস্যার “মূল” খুঁজে বের করার সহজ উপায়

ভূমিকা: একটি সাধারণ সোমবার সকাল

রাফি সাহেব একটি মাঝারি আকারের গার্মেন্টস কারখানার Production Manager। সোমবার সকালে অফিসে ঢুকতেই তার মোবাইলে একটি বার্তা এলো—গত সপ্তাহে shipment হওয়া একটি বড় lot-এ কাস্টমার থেকে complaint এসেছে। ৮% পণ্যে stitching defect পাওয়া গেছে, এবং buyer পুরো lot নিয়ে প্রশ্ন তুলেছে।

রাফি সাহেবের প্রথম প্রতিক্রিয়া ছিল স্বাভাবিক—”কোন operator এই ভুল করেছে, তাকে খুঁজে বের করো।” কিন্তু QA ম্যানেজার শিলা আপা তাকে থামিয়ে বললেন, “স্যার, শুধু একজন মানুষকে দোষ দিলে সমস্যা আবার ঘটবে। চলুন, আমরা সমস্যার আসল শিকড়টা খুঁজে বের করি।”

এভাবেই শুরু হলো একটি যাত্রা—যেখানে রাফি সাহেব এবং তার টিম একে একে ব্যবহার করলেন Root Cause Analysis-এর পাঁচটি জনপ্রিয় টুল। চলুন, তাদের সঙ্গে সঙ্গে আমরাও শিখে নিই এই টুলগুলো আসলে কী, এবং কীভাবে কাজ করে।

টুল ১: 5 Why Analysis — প্রশ্নের পর প্রশ্ন

শিলা আপা প্রথমেই হোয়াইটবোর্ডে লিখলেন একটি প্রশ্ন: “কেন এই defect হলো?”

এটাই হলো 5 Why Analysis-এর মূল ধারণা—একটি সমস্যার পেছনে বারবার “কেন” জিজ্ঞাসা করতে করতে মূল কারণ পর্যন্ত পৌঁছানো। সাধারণত পাঁচবার “কেন” জিজ্ঞাসা করলেই আসল কারণ বেরিয়ে আসে, যদিও সংখ্যাটি নির্দিষ্ট নয়—কখনো তিনবারেই কারণ পাওয়া যায়, কখনো সাতবার লাগে।

টিম মিলে বিশ্লেষণ শুরু করলো:

1. কেন stitching-এ defect হলো? — কারণ thread tension সঠিক ছিল না।
2. কেন thread tension সঠিক ছিল না? — কারণ machine calibration করা হয়নি।
3. কেন machine calibration করা হয়নি? — কারণ maintenance schedule অনুসরণ করা হয়নি।
4. কেন maintenance schedule অনুসরণ করা হয়নি? — কারণ maintenance টিমের কাছে আপডেটেড schedule ছিল না।
5. কেন আপডেটেড schedule ছিল না? — কারণ কোনো নির্দিষ্ট ব্যক্তি এই schedule maintain করার দায়িত্বে ছিলেন না।

রাফি সাহেব অবাক হয়ে বললেন, “তার মানে দোষটা operator-এর নয়, বরং আমাদের maintenance system-এর!” এই ছোট্ট আবিষ্কারই দেখিয়ে দিলো, কেন 5 Why এত জনপ্রিয়—এটি সহজ, দ্রুত, এবং কোনো জটিল প্রশিক্ষণ ছাড়াই যে কেউ ব্যবহার করতে পারে।

টুল ২: Fishbone Diagram (Ishikawa Diagram) — মাছের কাঁটার মতো বিশ্লেষণ

পরদিন টিম বসলো আরেকটি বড় মিটিংয়ে। এবার শুধু একটি কারণ নয়, বরং সবগুলো সম্ভাব্য কারণ একসঙ্গে দেখতে চাইলেন শিলা আপা। তিনি বোর্ডে আঁকলেন একটি মাছের কাঁটার মতো আকৃতি—এটাই Fishbone Diagram, যা জাপানি বিজ্ঞানী কাওরু ইশিকাওয়ার নামানুসারে Ishikawa Diagram নামেও পরিচিত।

মাছের মাথায় লেখা হলো মূল সমস্যা—”Stitching Defect”। আর কাঁটাগুলোতে ভাগ করা হলো সম্ভাব্য কারণের বিভিন্ন ক্যাটাগরি:

• Man (মানুষ): কর্মীদের দক্ষতা ও প্রশিক্ষণ
• Machine (মেশিন): calibration ও maintenance
• Method (পদ্ধতি): SOP অনুসরণ করা হচ্ছে কিনা
• Material (উপকরণ): thread ও fabric-এর গুণগত মান
• Measurement (পরিমাপ): inspection পদ্ধতি সঠিক কিনা
• Environment (পরিবেশ): কর্মক্ষেত্রের আলো ও তাপমাত্রা

টিম প্রতিটি ক্যাটাগরির নিচে সম্ভাব্য কারণ লিখতে লাগলো। এই পদ্ধতির সৌন্দর্য হলো, এটি একসঙ্গে অনেকগুলো দৃষ্টিকোণ থেকে সমস্যা দেখতে সাহায্য করে, এবং কোনো একটি কারণ যেন হারিয়ে না যায় তা নিশ্চিত করে। রাফি সাহেব বললেন, “এখন পুরো ছবিটা স্পষ্ট হচ্ছে—শুধু মেশিন নয়, method এবং measurement-এও দুর্বলতা আছে।”

টুল ৩: Pareto Analysis — কোন সমস্যাটা আগে সমাধান করবো?

Fishbone Diagram থেকে টিম প্রায় ১৫টি সম্ভাব্য কারণ খুঁজে পেলো। কিন্তু সবগুলো একসঙ্গে সমাধান করার মতো সময় বা সম্পদ তাদের ছিল না। এখানেই কাজে এলো Pareto Analysis।

এই পদ্ধতির ভিত্তি হলো বিখ্যাত 80/20 নিয়ম—অর্থাৎ, সাধারণত ৮০% সমস্যার পেছনে দায়ী থাকে মাত্র ২০% কারণ। টিম গত তিন মাসের defect data সংগ্রহ করে একটি bar chart তৈরি করলো, যেখানে প্রতিটি কারণের ফ্রিকোয়েন্সি বড় থেকে ছোট আকারে সাজানো হলো।

ফলাফল দেখে সবাই চমকে গেলো—মোট defect-এর প্রায় ৭৫% আসছিলো মাত্র দুইটি কারণ থেকে: machine calibration সমস্যা এবং thread quality। বাকি ১৩টি কারণ মিলিয়ে মাত্র ২৫% অবদান রাখছিলো।

শিলা আপা বললেন, “আমরা যদি প্রথমে এই দুইটি কারণেই মনোযোগ দিই, তাহলে সবচেয়ে কম সময়ে সবচেয়ে বেশি ফলাফল পাবো।” রাফি সাহেব বুঝলেন, কেন Pareto Analysis-কে বলা হয় “smart prioritization tool”—এটি সীমিত সম্পদ দিয়ে সর্বোচ্চ প্রভাব ফেলার পথ দেখায়।

টুল ৪: Fault Tree Analysis — উল্টো দিক থেকে সমস্যা দেখা

এতদিন টিম কারণ থেকে শুরু করে সমস্যার দিকে এগোচ্ছিলো। কিন্তু production head সাহেদ ভাই একটি ভিন্ন দৃষ্টিভঙ্গি নিয়ে এলেন—Fault Tree Analysis (FTA)। এই পদ্ধতিতে উল্টো দিক থেকে চিন্তা করা হয়—প্রথমে চূড়ান্ত ব্যর্থতা (top event) নির্ধারণ করে, তারপর সেই দিকে যাওয়ার সম্ভাব্য সবগুলো পথ একটি tree-এর মতো diagram-এ ভেঙে দেখানো হয়, logical AND/OR gate ব্যবহার করে।

সাহেদ ভাই বোর্ডে লিখলেন top event: “Customer Complaint on Stitching Defect”। এরপর তিনি দেখালেন, এই ঘটনা ঘটতে হলে নিচের যেকোনো একটি (OR gate) শর্ত পূরণ হতে হবে:

• Machine malfunction এবং (AND) inspection ব্যর্থতা একসঙ্গে ঘটেছে
• অথবা, thread quality সমস্যা এবং (AND) incoming material inspection skip হয়েছে

এই visual mapping দেখে টিম বুঝতে পারলো, একটি মাত্র কারণ নয়, বরং একাধিক ব্যর্থতার সমন্বয়েই এই বড় সমস্যা তৈরি হয়েছে। FTA বিশেষভাবে জটিল এবং high-risk system-এ কার্যকর, যেখানে একাধিক factor একসঙ্গে মিলে বড় দুর্ঘটনা বা ব্যর্থতা ঘটাতে পারে—যেমন aviation, manufacturing safety, বা এই ক্ষেত্রে quality failure।

টুল ৫: Failure Mode and Effects Analysis (FMEA) — ভবিষ্যতের জন্য প্রস্তুতি

সমস্যার তাৎক্ষণিক সমাধান তো হলো, কিন্তু রাফি সাহেব চাইলেন এমন কিছু, যা ভবিষ্যতে একই ধরনের সমস্যা প্রতিরোধ করবে। এখানেই টিম ব্যবহার করলো সবচেয়ে systematic টুল—FMEA (Failure Mode and Effects Analysis)।

এই পদ্ধতিতে সম্ভাব্য প্রতিটি failure mode-কে তিনটি মানদণ্ডে স্কোর করা হয়:

• Severity (S): সমস্যাটি কতটা গুরুতর
• Occurrence (O): সমস্যাটি কতবার ঘটতে পারে
• Detection (D): সমস্যাটি সময়মতো ধরা পড়ার সম্ভাবনা কতটা

এই তিনটি স্কোর গুণ করে পাওয়া যায় Risk Priority Number (RPN), যা দেখে বোঝা যায় কোন সমস্যাটি সবচেয়ে বেশি জরুরি ভিত্তিতে সমাধান করা দরকার।

টিম machine maintenance, thread inspection, এবং operator training—প্রতিটি সম্ভাব্য failure point-এর জন্য RPN হিসাব করলো। সবচেয়ে বেশি RPN স্কোর পেলো “unplanned machine calibration miss”। তাই তারা একটি preventive maintenance checklist তৈরি করলো, যেখানে প্রতিটি মেশিনের calibration date এবং দায়িত্বপ্রাপ্ত ব্যক্তির নাম স্পষ্টভাবে উল্লেখ থাকবে।

শিলা আপা হাসিমুখে বললেন, “এখন আমরা শুধু আজকের সমস্যা সমাধান করছি না, বরং আগামী দিনের সমস্যাও প্রতিরোধ করছি।”

গল্পের শেষে: ফলাফল কী হলো?

তিন সপ্তাহ পর, রাফি সাহেবের কারখানার defect rate ৮% থেকে নেমে এলো ১.৫%-এ। Buyer সন্তুষ্ট হলেন, এবং তারা পরবর্তী অর্ডারের পরিমাণ আরও বাড়ানোর প্রস্তাব দিলেন।

এই গল্প থেকে আমরা শিখলাম, Root Cause Analysis কোনো একক টুল নয়—বরং এটি একটি চিন্তাভাবনার পদ্ধতি, যেখানে বিভিন্ন পরিস্থিতিতে বিভিন্ন টুল ব্যবহার করা হয়:

শেষ কথা

সমস্যা সবসময়ই আসবে—এটাই ব্যবসার বাস্তবতা। কিন্তু পার্থক্যটা তৈরি হয় সেখানে, যখন একটি প্রতিষ্ঠান শুধু উপরিভাগের লক্ষণ সারিয়ে তোলার বদলে সমস্যার আসল শিকড় খুঁজে বের করে। রাফি সাহেবের কারখানার গল্পটা তাই শুধু একটি সমাধানের গল্প নয়—এটি একটি মানসিকতার পরিবর্তনের গল্প, যেখানে “কার দোষ” থেকে সরে এসে “কেন ঘটলো” প্রশ্ন করাই আসল সমাধানের পথ দেখায়।

পরের বার যখন আপনার প্রতিষ্ঠানে কোনো সমস্যা দেখা দেবে, মনে রাখবেন—উত্তরটা হয়তো এই পাঁচটি টুলের কোনো একটির মধ্যেই লুকিয়ে আছে।