8D রিপোর্ট কীভাবে লিখবেন: D0–D8 ও টয়োটার 8 ধাপ পদ্ধতি
আপনার গ্রাহকের রিসিভিং ইনস্পেকশনে কিছু ব্র্যাকেট টলারেন্সের বাইরে পাওয়া গেল। কয়েক ঘণ্টার মধ্যে তাদের সাপ্লায়ার কোয়ালিটি ইঞ্জিনিয়ার ইমেইল করলেন: "দয়া করে 8D দিয়ে উত্তর দিন।" তাদের সাপ্লায়ার কোয়ালিটি ম্যানুয়ালে প্রথম উত্তরের জন্য 24 ঘণ্টা দেওয়া আছে। এই সময়ে যদি আপনি কারখানার ভেতরের সাধারণ ডিফেক্ট রিপোর্ট পাঠান, যেখানে কারণের জন্য এক লাইন আর সমাধানের জন্য এক লাইন, তাহলে রিপোর্টটি ফেরত আসার সম্ভাবনা বেশি।
8D রিপোর্ট হলো গ্রাহককে দেওয়া একটি নির্দিষ্ট ক্রমের রিপোর্ট। এতে প্রথম সাড়া থেকে শুরু করে মূল কারণ, সংশোধনমূলক ব্যবস্থা এবং পুনরাবৃত্তি ঠেকানোর উপায় পর্যন্ত সবকিছু থাকে। ভালো 8D-র মূল কথা হলো দুটি আলাদা মূল কারণ। একটি হলো অকারেন্স কজ (occurrence cause), অর্থাৎ ত্রুটিপূর্ণ পার্ট কেন তৈরি হলো। অন্যটি হলো এসকেপ কজ (escape cause), অর্থাৎ গ্রাহকের কাছে পৌঁছানোর আগে কেন ধরা পড়ল না। জাপানি কোয়ালিটি টিমও একই ভাগ ব্যবহার করে। তারা বলে হাসসেই গেন'ইন (hassei gen'in, ঘটার কারণ) আর র্যুশুতসু গেন'ইন (ryushutsu gen'in, বেরিয়ে যাওয়ার কারণ)।
গ্রাহক আপনার লেখার ভাষা বিচার করেন না। তিনি দেখেন দুটি কারণের প্রতিটির বিরুদ্ধে আপনি সিস্টেম-স্তরের প্রতিকার নিয়েছেন কি না। এই লেখায় আছে 8D কোথা থেকে এসেছে এবং টয়োটার 8 ধাপ থেকে কীভাবে আলাদা। আরও আছে D0 থেকে D8 পর্যন্ত প্রতিটি ধাপে কী লিখবেন, কোন কোন কারণে 8D ফেরত আসে, এবং বারবার ব্যবহার করার মতো একটি চেকলিস্ট ও প্রশ্নের তালিকা।
সূচিপত্র
- 8D রিপোর্ট কী?
- গ্রাহক কখন 8D চান, আর কত তাড়াতাড়ি
- D0–D8 ধাপ এক নজরে
- D0–D3: টিম, সমস্যার বর্ণনা ও কনটেইনমেন্ট
- D4: অকারেন্স ও এসকেপ মূল কারণ আলাদা করুন
- D5–D6: স্থায়ী ব্যবস্থা বাছাই ও যাচাই
- D7–D8: পুনরাবৃত্তি প্রতিরোধ ও সমাপ্তি
- কেন 8D ফেরত আসে
- টেমপ্লেট: D4–D5-এর কারণ-ব্যবস্থা টেবিল
- শুরুর আগে গ্রাহককে যে প্রশ্নগুলো করবেন
- এই নির্দেশিকার সীমা
- প্রশ্নোত্তর (FAQ)
- সূত্র
8D রিপোর্ট কী?
8D রিপোর্টে লেখা থাকে একটি টিম কীভাবে কোয়ালিটি সমস্যাটি আটটি ধাপে (discipline) সমাধান করেছে এবং কী খুঁজে পেয়েছে। Siemens 8D রিপোর্টকে বর্ণনা করে আট ধাপের সমস্যা-সমাধান প্রক্রিয়ার ফলাফল হিসেবে। ম্যানুফ্যাকচারিং নন-কনফরমিটি সামলাতে এবং ধারাবাহিক উন্নয়ন চালাতে এই প্রক্রিয়া ব্যবহার হয়।
"8D" হলো পদ্ধতির নাম, আর রিপোর্ট হলো তার রেকর্ড। উদ্দেশ্য শুধু ফরম পূরণ করা নয়। উদ্দেশ্য হলো টিম কীভাবে সমস্যাটি সমাধান করল তার একটি ট্রেইল রেখে যাওয়া, যাতে গ্রাহক পরে তা যাচাই করতে পারেন।
উৎস: Ford, TOPS ও Global 8D
8D-র শুরু Ford Motor Company-তে। Ford-এর Powertrain বিভাগের ম্যানেজমেন্ট চেয়েছিল এমন একটি পদ্ধতি, যাতে ডিজাইন, ম্যানুফ্যাকচারিং ইঞ্জিনিয়ারিং ও প্রোডাকশনের লোকজন টিম হিসেবে দীর্ঘদিনের সমস্যায় কাজ করতে পারে। সেই লক্ষ্যে 1986 সালে একটি ম্যানুয়াল ও প্রশিক্ষণ কোর্স তৈরির কাজ শুরু হয়।
ম্যানুয়ালের প্রথম সংস্করণ, Team Oriented Problem Solving (TOPS), বের হয় 1987 সালে। 1990-এর দশকের শেষ দিকে Ford এটি সংশোধন করে Global 8D (G8D) বানায়। এই সংশোধনে যোগ হয় D0, যেখানে লক্ষণ ও জরুরি ব্যবস্থা লেখা হয়। আরও যোগ হয় এসকেপ পয়েন্ট (escape point) ধারণা: যে বিন্দুতে সমস্যাটি ধরা পড়ার কথা ছিল কিন্তু পড়েনি।
আজ বেশিরভাগ গ্রাহক যে নয় ধাপের D0–D8 ফরম্যাট ব্যবহার করেন, সেটি G8D-র ওপর ভিত্তি করে। কিছু সূত্রে বলা হয়েছে, 8D-র সঙ্গে MIL-STD-1520-এর কিছু মিল আছে। এটি নন-কনফর্মিং ম্যাটেরিয়ালের সংশোধনমূলক ব্যবস্থা নিয়ে 1974 সালের মার্কিন প্রতিরক্ষা বিভাগের একটি স্ট্যান্ডার্ড। তবে 8D-কে সরাসরি প্রভাবিত করেছে কি না, তা নিয়ে মতভেদ আছে। 8D শুরু হয়েছিল অটো শিল্পে, এখন খাদ্য, স্বাস্থ্যসেবা ও ইলেকট্রনিক্স ম্যানুফ্যাকচারিংয়েও ছড়িয়েছে।
8D বনাম টয়োটার 8 ধাপ সমস্যা-সমাধান পদ্ধতি
8D-র সঙ্গে সবচেয়ে বেশি গুলিয়ে ফেলা হয় টয়োটার আট ধাপের সমস্যা-সমাধান প্রক্রিয়া, যা TBP (Toyota Business Practices) নামেও পরিচিত। দুটিতেই আটটি ধাপ, কিন্তু উৎস আলাদা এবং ব্যবহারও আলাদা। Ford-এর 8D সাধারণত গ্রাহককে ডিফেক্টের উত্তর জানানোর ফরম্যাট হিসেবে ব্যবহৃত হয়।
টয়োটার আট ধাপ শুরু হয় সমস্যা পরিষ্কার করা ও লক্ষ্য ঠিক করা দিয়ে। তারপর মূল কারণ (shin'in) খুঁজে বের করা, আর শেষে ফলাফল স্থায়ী করা। এটি নিজের প্রতিষ্ঠানের ভেতরে সমস্যা সমাধানের চিন্তাপদ্ধতি। এক পাতার A3 শিটে সারসংক্ষেপ করার জন্য এটি সুপরিচিত।
চিন্তাভাবনার বেশিরভাগই মেলে। তবে প্রতিটিতে এমন একটি ধাপ আছে যা অন্যটিতে নেই: 8D-তে কনটেইনমেন্ট (D3), আর টয়োটার আট ধাপে লক্ষ্য নির্ধারণ।
টয়োটার পদ্ধতির ধাপের নাম উৎসভেদে একটু আলাদা হয়। সারিগুলো উদ্দেশ্যের মিল দেখে সাজানো, হুবহু এক-এক মিল নয়।
গ্রাহক 8D চাইলে এবং আপনার টিম আগেই টয়োটার আট ধাপে সমস্যাটি বিশ্লেষণ করে থাকলে সেই কাজের বেশিরভাগ আবার ব্যবহার করা যায়। সমস্যা ভেঙে দেখার ধাপে যে সমস্যাটি সংকীর্ণ করেছেন, সেটি D2-তে যাবে। মূল কারণ বিশ্লেষণ যাবে D4-তে, আর স্ট্যান্ডার্ডাইজেশন যাবে D7-তে।
যেটি বাদ দেওয়া যাবে না: 8D-তে কনটেইনমেন্টের পরিধি আর এসকেপ কজ আলাদা আলাদা বিষয় হিসেবে দেখাতে হয়। অভ্যন্তরীণ উন্নয়ন রেকর্ড যেমন আছে তেমনই জমা দিলে সাধারণত এই দুটিই বাদ পড়ে, আর সেটি ফেরত আসার একটি পরিচিত কারণ।
8D বনাম অভ্যন্তরীণ ডিফেক্ট রিপোর্ট
অভ্যন্তরীণ ডিফেক্ট রিপোর্টের প্রধান কাজ অন্য বিভাগকে জানানো কী ঘটেছে আর কীভাবে ঠিক করা হয়েছে। প্রতিটি কোম্পানি নিজের মতো করে লেখে, আর কারণ ও সমাধান হয়তো এক লাইন করে।
8D হলো এমন একটি নথি যা দিয়ে গ্রাহক বিচার করেন আপনি তাদের কোয়ালিটি রক্ষা করতে পারবেন কি না। তাই তিনটি জিনিস আলাদাভাবে দেখাতে হয়: ত্রুটিপূর্ণ পার্ট গ্রাহকের কাছে পৌঁছানো কীভাবে ঠেকিয়েছেন, সেগুলো কেন তৈরি হয়েছিল, আর কেন ইনস্পেকশন ফাঁকি দিয়ে বেরিয়ে গেল।
8D লিখুন এমন প্রমাণ হিসেবে, যা দেখে গ্রাহক সিদ্ধান্ত নিতে পারেন আপনি তাদের কোয়ালিটি রক্ষা করতে পারবেন কি না।
অনেক কোম্পানি অভ্যন্তরীণ ডিফেক্টের ক্ষেত্রেও 8D-র চিন্তা কাজে লাগায় এবং ফরমের একটি সহজ অভ্যন্তরীণ সংস্করণ রাখে।
বেশিরভাগ কোম্পানিতে গ্রাহকের সঙ্গে যোগাযোগের জায়গা হিসেবে কোয়ালিটি অ্যাসিউরেন্স বিভাগই 8D লেখে। কিন্তু প্রোডাকশন, প্রোডাকশন ইঞ্জিনিয়ার (seisan gijutsu) ও ডিজাইনের সহযোগিতা ছাড়া মূল কারণ বিশ্লেষণ আর সংশোধনমূলক ব্যবস্থা এগোয় না।
গ্রাহক কখন 8D চান, আর কত তাড়াতাড়ি
সবচেয়ে সাধারণ ঘটনা হলো আপনার পাঠানো পার্টসে ডিফেক্ট ধরা পড়া। গ্রাহক সেটি রিসিভিং ইনস্পেকশনে বা অ্যাসেম্বলি লাইনে পেতে পারেন, কিংবা মাঠে (field) কোনো ব্যর্থতার সূত্র ধরে আপনার পার্টে পৌঁছাতে পারেন।
অটো শিল্পে 8D এত প্রচলিত হওয়ার বড় কারণ IATF 16949, অর্থাৎ অটোমোটিভ কোয়ালিটি ম্যানেজমেন্ট স্ট্যান্ডার্ড। এর ক্লজ 10.2.3 "Problem solving"-এ একটি নথিবদ্ধ সমস্যা-সমাধান প্রক্রিয়া চাওয়া হয়েছে, যাতে থাকতে হবে:
- কনটেইনমেন্ট ও অন্তর্বর্তী ব্যবস্থা
- মূল কারণ বিশ্লেষণ
- অনুরূপ প্রোডাক্ট ও প্রক্রিয়ার ওপর প্রভাব বিবেচনা করে সিস্টেমিক কারেক্টিভ অ্যাকশন
- কার্যকারিতা যাচাই
- PFMEA ও কন্ট্রোল প্ল্যানের মতো নথির পর্যালোচনা ও আপডেট
একই ক্লজে বলা আছে, গ্রাহক কোনো নির্দিষ্ট সমস্যা-সমাধান প্রক্রিয়া, টুল বা ফরম্যাট নির্ধারণ করে দিলে সেটিই ব্যবহার করতে হবে, যদি না গ্রাহক অন্যভাবে অনুমোদন দেন। তাই গ্রাহক "8D-তে উত্তর দিন" বললে নিজের ফরম নয়, গ্রাহকের ফরম ব্যবহার করুন।
IATF 16949 বাংলাদেশের জাতীয় স্ট্যান্ডার্ড নয়। এটি IATF-এর প্রকাশিত অটোমোটিভ কোয়ালিটি স্ট্যান্ডার্ড, যা সাধারণত গ্রাহকের চুক্তি ও সাপ্লায়ার কোয়ালিটি ম্যানুয়ালের মাধ্যমে আপনার কাছে আসে। আপনার গ্রাহকের ম্যানুয়ালে কোন সংস্করণ বা কোন শর্ত প্রযোজ্য, সেটি তাদের কাছ থেকেই নিশ্চিত করুন।
শিল্প সংস্থাও 8D-র নির্দেশিকা প্রকাশ করেছে। জার্মান অটোমোবাইল শিল্প সংস্থার (VDA) কোয়ালিটি ম্যানেজমেন্ট সেন্টার VDA QMC 2018 সালে একটি 8D পুস্তিকা প্রকাশ করেছে। মার্কিন Automotive Industry Action Group (AIAG) প্রকাশ করে CQI-20, একটি কার্যকর সমস্যা-সমাধান গাইড। গ্রাহকভেদে ফরম ও খুঁটিনাটি শর্ত আলাদা হওয়ার একটি কারণ হলো, গ্রাহকরা আলাদা আলাদা গাইড অনুসরণ করেন।
সময়সীমা আসে গ্রাহকের ম্যানুয়াল থেকে
কোন ধাপ কবে জমা দিতে হবে, সেটি প্রতিটি গ্রাহকের সাপ্লায়ার কোয়ালিটি ম্যানুয়ালে ঠিক করা থাকে। সবার জন্য এক নিয়ম নেই, তাই প্রথমে নিশ্চিত করুন ফরম ও সময়সীমা।
একটি উদাহরণ জার্মান অটো পার্টস নির্মাতা MAHLE-এর "1-5-20 নিয়ম"। অভিযোগের তারিখ থেকে সাপ্লায়ারকে 1 দিনের (24 ঘণ্টা) মধ্যে কনটেইনমেন্ট জানাতে হয়। 5 কর্মদিবসের মধ্যে জানাতে হয় মূল কারণ ও সংশোধনমূলক ব্যবস্থা। আর 20 কর্মদিবসের মধ্যে জানাতে হয় বাস্তবায়িত ব্যবস্থা ও পুনরাবৃত্তি প্রতিরোধ।
এই উদাহরণের মতো, গ্রাহক অনেক সময় 8D একবারে না চেয়ে ধাপে ধাপে চান, প্রতিটি ধাপের নিজস্ব সময়সীমা সহ।
এটি একটি কোম্পানির নিয়ম। সময়সীমা ও ধাপের ভাগ গ্রাহকভেদে আলাদা, তাই সবসময় গ্রাহকের কোয়ালিটি ম্যানুয়াল দেখে নিন।
ধাপে ধাপে সময়সীমা থাকলে প্রথম উত্তরের সময় মূল কারণ জানা থাকতে হয় না। বরং প্রথম রিপোর্টে "কারণ: অপারেটরের ভুল" লিখে পরে সংশোধন করলে বিশ্বাসযোগ্যতা কমে। যা জানেন আর যা তদন্তাধীন, দুটো আলাদা করে লিখুন এবং সময়মতো জমা দিন।
D0–D8 ধাপ এক নজরে
ধাপগুলো চারটি পর্বে ভাগ করলে বোঝা সহজ হয়। প্রথমে গ্রাহককে রক্ষার জন্য প্রথম সাড়া, তারপর মূল কারণের অনুসন্ধান, তারপর স্থায়ী ব্যবস্থা ও পুনরাবৃত্তি প্রতিরোধ, আর শেষে সমাপ্তি।
আগে গ্রাহককে রক্ষা করুন, তারপর কারণ খুঁজুন, তারপর সিস্টেম-স্তরের প্রতিকার দিয়ে পুনরাবৃত্তি ঠেকান।
কিছু গ্রাহক D0 ছাড়া শুধু D1–D8 (আট ধাপ) ব্যবহার করেন। ফরমভেদে ধাপের নামও সামান্য আলাদা হয়।
ক্রমের একটি অর্থ আছে। মূল কারণের কাজের আগে D3 কনটেইনমেন্ট আসে, কারণ অনুসন্ধানে সময় লাগে, আর এই সময়ে ত্রুটিপূর্ণ পার্ট গ্রাহকের কাছে যেতে থাকলে চলবে না। D5 ও D6 আলাদা, কারণ ব্যবস্থা বেছে নেওয়া আর বাস্তবায়ন করে প্রমাণ করা যে কাজ করছে দুটি আলাদা কাজ। নিচে প্রতিটি পর্ব ধরে ধরে দেখা হলো।
D0–D3: টিম, সমস্যার বর্ণনা ও কনটেইনমেন্ট
এই চারটি ধাপ সাধারণত গ্রাহককে দেওয়া প্রথম উত্তরে থাকে। এখানে অস্পষ্ট লিখলে পরের মূল কারণ বিশ্লেষণও দিক হারাবে।
D0: জরুরি সাড়া ও 8D দরকার কি না
D0-তে লক্ষণ লিখুন, আর আনুষ্ঠানিক 8D শুরুর আগে যে জরুরি ব্যবস্থা নিয়েছেন তা লিখুন। যেমন অভিযোগ আসার সঙ্গে সঙ্গে ওই লটের শিপমেন্ট বন্ধ করেছেন, অথবা গ্রাহকের লাইনে বদলি পার্টস পাঠিয়েছেন।
প্রতিটি অভ্যন্তরীণ ডিফেক্টে পূর্ণ 8D চালালে কোনো টিমই সামাল দিতে পারবে না। তাই G8D-তে D0 দিয়ে ঠিক করা হয় 8D দরকার কি না। তবে গ্রাহক নিজে 8D চাইলে সেটি নিজে ঠিক করার সুযোগ খুব কম থাকে।
D1: টিম
D1-এ সমস্যায় কাজ করা লোকজনের তালিকা দিন। শুধু একজন কোয়ালিটি ইঞ্জিনিয়ারের নাম দেবেন না। প্রোডাকশন, প্রোডাকশন ইঞ্জিনিয়ার, ডিজাইন এবং দরকার হলে আপনার নিজের সাপ্লায়ারকে নিয়ে বিভিন্ন বিভাগের টিম বানান।
MAHLE-এর ম্যানুয়ালে চাওয়া হয়েছে টিম সদস্যদের দায়িত্বসহ তালিকা এবং একজন টিম লিডার, যিনি 8D বাস্তবায়নের দায়িত্বে থাকবেন। সেখানে একজন ম্যানেজমেন্ট চ্যাম্পিয়নের কথাও আছে, যিনি টিমের দরকারি রিসোর্স অনুমোদন করেন।
প্রতিটি সদস্যের শুধু নাম ও বিভাগ নয়, ভূমিকাও লিখুন। তাহলে গ্রাহক বুঝতে পারেন টিম আসলে ব্যবস্থাগুলো বাস্তবায়ন করতে পারবে কি না।
D2: 5W2H ও Is/Is Not দিয়ে সমস্যার বর্ণনা
টিমগুলো প্রায়ই D2 তাড়াহুড়ো করে সারে, অথচ 8D-র মান সবচেয়ে বেশি তফাত হয় যে ধাপগুলোতে, এটি তার একটি। শুধু "অ্যাপিয়ারেন্স ডিফেক্ট" বা "ডাইমেনশনাল ডিফেক্ট" লিখবেন না। কোন বৈশিষ্ট্য স্পেকের বাইরে গেছে এবং কতটা, তা লিখুন।
একটি প্রচলিত কাঠামো 5W2H: কী, কখন, কোথায়, কে, কেন, কীভাবে এবং কতটুকু। এর সঙ্গে নিচের তথ্যগুলোও জোগাড় করুন:
- উৎপাদনের তারিখ
- শিফট
- লট নম্বর
- মাপের ফলাফল
- ত্রুটিপূর্ণ পার্টসের পরিমাণ
আরেকটি কার্যকর টুল হলো Is/Is Not তুলনা। যেসব অবস্থায় ডিফেক্ট দেখা যাচ্ছে, তার পাশে একই রকম যেসব অবস্থায় দেখা যাচ্ছে না সেগুলো রাখুন। তাহলে সম্ভাব্য কারণের তালিকা দ্রুত ছোট হয়ে আসে।
কারণের সূত্র লুকিয়ে আছে "Is" আর "Is Not"-এর পার্থক্যে।
বোঝানোর জন্য একটি কাল্পনিক উদাহরণ। এখানে "2 নম্বর প্রেস", "8 সেপ্টেম্বর থেকে" ও "নাইট শিফট"—এই তিনটির মধ্যে যে পরিবর্তন মেলে (সেটআপ, যন্ত্র, অপারেটর ইত্যাদি), তা খুঁজতে হবে।
D2-তেই জিজ্ঞেস করা শুরু করুন, একই সমস্যা অন্য কোথাও হচ্ছে কি না। একই যন্ত্র বা ডাই ব্যবহার করা অন্য পার্ট নম্বর প্রভাবিত হয়েছে কি না আগেভাগে দেখে নিলে D7-এ ছড়িয়ে দেওয়ার কাজ অনেক সহজ হয়।
D3: অন্তর্বর্তী কনটেইনমেন্ট
কারণ জানা না পর্যন্ত ত্রুটিপূর্ণ পার্ট যেন গ্রাহকের কাছে না যায়, D3 তা নিশ্চিত করে। MAHLE-এর ম্যানুয়ালে লেখা আছে কনটেইনমেন্ট গ্রাহককে রক্ষার জন্য। শুধু নিজের লাইনে ডিফেক্ট ঠিক করা যথেষ্ট নয়।
পরিধি ঠিক করতে সাপ্লাই চেইনে পেছনের দিকে যান: গ্রাহকের কাছে থাকা স্টক, ট্রানজিটে থাকা পার্টস, আপনার ফিনিশড-গুডস গুদাম, আর WIP (প্রক্রিয়াধীন বা আধা-তৈরি মাল)। সন্দেহজনক পার্টস কোয়ারেন্টাইনে রেখে 100% ইনস্পেকশন, বাছাই বা রিওয়ার্ক করুন। মাল জাহাজে বা কন্টেইনারে পাঠানো হয়ে থাকলে ট্রানজিটে থাকা পরিমাণ আলাদা করে লিখুন।
8D-তে শুধু ব্যবস্থাটি লিখলে হবে না। এগুলোও রাখুন:
- প্রতিটি জায়গায় কতটুকু মাল আওতায় এসেছে
- বাছাইয়ের ফলাফল (কতটি পরীক্ষায় কতটি ডিফেক্ট)
- দায়িত্বপ্রাপ্ত ব্যক্তি ও শুরুর তারিখ
গ্রাহক এটাও জানতে চাইবেন যে আপনার বাছাইয়ের পদ্ধতিতেই ডিফেক্ট ফসকে যেতে পারে কি না। ইনস্পেকশন পদ্ধতি ও গ্রহণযোগ্যতার মানদণ্ড সংযুক্ত করলে ফেরত আসার সম্ভাবনা কমে।
আরও লিখুন ক্লিন পয়েন্ট (clean point): যে লট থেকে আপনি নিশ্চিত যে শুধু ভালো পার্ট যাচ্ছে। কনটেইনমেন্ট অস্থায়ী। D6-এ স্থায়ী ব্যবস্থা কাজ করছে প্রমাণ হওয়া পর্যন্ত এটি চালু থাকে।
D4: অকারেন্স ও এসকেপ মূল কারণ আলাদা করুন
D4 হলো 8D-র প্রাণ, আর গ্রাহক এই ধাপটিই সবচেয়ে খুঁটিয়ে দেখেন। মূল কথা: প্রতিটি ডিফেক্টের কমপক্ষে দুই ধরনের কারণ আছে।
কারণের তিনটি স্তর
প্রথমটি অকারেন্স কজ (occurrence cause): ত্রুটিপূর্ণ পার্ট কেন তৈরি হলো। দ্বিতীয়টি এসকেপ কজ (escape cause): গ্রাহকের কাছে পৌঁছানোর আগে ইনস্পেকশন কেন এটি আটকাতে পারল না। Siemens-ও D4-কে দুটি পথের অনুসন্ধান বলে বর্ণনা করে, একটি অকারেন্সের জন্য, অন্যটি এসকেপের জন্য।
MAHLE-এর ম্যানুয়াল আরও এক ধাপ গভীরে যায় এবং জিজ্ঞেস করে সমস্যাটি কেন প্রতিরোধ করা গেল না। এখানে ডেভেলপমেন্ট পর্ব ও সিস্টেম দেখা হয়। একে অনেকে সিস্টেম মূল কারণ বলে, আর এখানে প্রশ্ন হলো FMEA বা স্ট্যান্ডার্ডে কোনো ফাঁক ছিল কি না।
একটি ডিফেক্ট থেকে "কেন বানালাম" আর "কেন পাঠালাম" আলাদা করে খুঁজুন।
এসকেপ কজ G8D-তে যোগ হওয়া এসকেপ পয়েন্টের সঙ্গে মেলে, অর্থাৎ যে কন্ট্রোল পয়েন্টে ডিফেক্টটি ধরা পড়ার কথা ছিল। শুধু অকারেন্স কজ লেখা 8D ফেরত আসার সম্ভাবনা বেশি।
শুধু অকারেন্স কজ ঠিক করে ইনস্পেকশন ব্যবস্থা আগের মতো রেখে দিলে অন্য কোনো কারণে তৈরি ডিফেক্ট আবার গ্রাহকের কাছে পৌঁছাতে পারে। দুটি কারণ আলাদা করে লিখলে দুই দিক থেকেই ব্যবস্থা নেওয়া যায়: বানাবেন না, আর পাঠাবেন না।
বিশ্লেষণের টুল বেছে নেওয়া
কারণ খুঁড়ে দেখার প্রচলিত টুল হলো 5 Why (জাপানে বলে naze-naze bunseki), ফিশবোন (ইশিকাওয়া) ডায়াগ্রাম এবং ফল্ট ট্রি অ্যানালাইসিস (FTA)। MAHLE-এর ম্যানুয়াল টুল বেছে নেয় কারণ সম্পর্কে আপনার আগে থেকে সন্দেহ আছে কি না তার ভিত্তিতে। সন্দেহ থাকলে 5 Why দিয়ে মূল কারণ খুঁজে নিশ্চিত করুন।
কারণ অজানা আর সমস্যা তুলনামূলক সহজ হলে আগে ফিশবোন ডায়াগ্রামে সম্ভাব্য কারণ তালিকা করুন, তারপর 5 Why বা FTA দিয়ে ছোট করুন। জটিল সমস্যার জন্য ম্যানুয়ালে পরিসংখ্যানগত পদ্ধতির কথাও আছে।
ফিশবোন ডায়াগ্রামে সাধারণত সম্ভাব্য কারণগুলো 6M-এর অধীনে সাজানো হয়: man (মানুষ), material, measurement, machine, method এবং mother nature (পরিবেশ)। 8D-তে মূল নিয়ম হলো অকারেন্স কজ ও এসকেপ কজের জন্য আলাদা আলাদা 5 Why চালানো।
একই ডিফেক্ট দুই পথে খুঁজলে প্রতিকারের জায়গা আলাদা হয়ে যায়।
চিত্র 5-এর মতো একই কাল্পনিক উদাহরণ। "অপারেটরের অসতর্কতা"-তে থামবেন না; সিস্টেমের ফাঁক না পাওয়া পর্যন্ত খুঁড়তে থাকুন।
ডিফেক্ট পুনরুৎপাদন করে মূল কারণ যাচাই করুন
5 Why-তে যে কারণে পৌঁছালেন সেটি তখনও অনুমান। 8D-তে এমন ফলাফল দিতে হয় যা দেখায় এই কারণেই আসলে ডিফেক্ট তৈরি হয়েছে। MAHLE-এর ম্যানুয়াল সাপ্লায়ারদের কাছে চায় ডিফেক্ট পুনরুৎপাদন করে, অথবা কারণটিকে চালু ও বন্ধ করে দেখিয়ে যে ডিফেক্ট আসে ও যায়।
উদাহরণে, টেস্ট স্ট্রোকে দেখানো যে ক্ষয়ে যাওয়া পাঞ্চ বড় আকারের হোল বানায় আর নতুন পাঞ্চ লাগালে মাপ আবার স্পেকের মধ্যে ফিরে আসে। এটি কারণের পক্ষে গ্রাহককে ভালো প্রমাণ দেয়।
টেস্টের শর্ত ও ফলাফল ছবি ও মাপের ডেটাসহ সংযুক্ত করুন। যে কারণ "অনুমান করা হচ্ছে" বা "মনে করা হয়" দিয়ে শেষ হয়, তাকে সাধারণত যাচাই-না-হওয়া কারণ হিসেবে ধরা হয়।
D5–D6: স্থায়ী ব্যবস্থা বাছাই ও যাচাই
D4-এ কারণ নিশ্চিত হলে সেটি দূর করার একটি স্থায়ী ব্যবস্থা বেছে নিন, বাস্তবায়ন করুন এবং প্রমাণ করুন যে তা কাজ করছে। D3-এর কনটেইনমেন্ট তোলা যাবে কি না, তা এর ফলাফলের ওপর নির্ভর করে।
প্রতিটি কারণের জন্য একটি করে ব্যবস্থা মেলান
D5-এ D4-এর তালিকার প্রতিটি কারণের জন্য একটি মিলে যাওয়া ব্যবস্থা দিন। অকারেন্স কজ আর এসকেপ কজের ব্যবস্থা আলাদা করে লিখুন। প্রতিটি কারণের পাশে তার ব্যবস্থা রাখা একটি টেবিল থাকলে গ্রাহক সহজে দেখতে পান কিছু বাদ পড়েছে কি না।
একাধিক বিকল্প থাকলে কার্যকারিতা, খরচ, বাস্তবায়নের সময় ও পার্শ্বপ্রতিক্রিয়ার ঝুঁকি তুলনা করে বলুন কেন এটি বেছেছেন। নতুন ব্যবস্থা অন্য কোনো ডিফেক্ট তৈরি করতে পারে কি না তা যে যাচাই করেছেন, সেটি দেখালে রিপোর্ট আরও বিশ্বাসযোগ্য হয়।
কেন শুধু "রিট্রেনিং" দিলে ফেরত আসে
ফেরত আসার একটি প্রচলিত কারণ হলো ব্যবস্থা শুধু "অপারেটরকে আবার প্রশিক্ষণ দিয়েছি" বা "সতর্কতা নোটিশ টাঙিয়েছি"। MAHLE-এর ম্যানুয়ালে পরিষ্কার লেখা আছে, অটো শিল্পে 8D-তে শুধু প্রক্রিয়ার উন্নয়নই কারেক্টিভ অ্যাকশন হিসেবে গণ্য হয়। রিমাইন্ডার বা কর্মী প্রশিক্ষণের মতো মানুষনির্ভর ব্যবস্থা প্রক্রিয়ার উন্নয়ন হিসেবে ধরা হয় না।
সতর্ক থাকলেও মানুষ ভুল করে, আর প্রশিক্ষণের প্রভাব সময়ের সঙ্গে কমে আসে। গ্রাহক সেই ব্যবস্থাই গ্রহণ করেন, যাতে কারও ভুল হলেও ডিফেক্ট তৈরি বা চালান হয় না।
মানুষের সতর্কতার ওপর নির্ভর করা ব্যবস্থার জায়গায় এমন ব্যবস্থা আনুন যা সিস্টেমের ভেতরেই প্রতিরোধ গেঁথে দেয়।
এর মানে প্রশিক্ষণ অপ্রয়োজনীয় নয়। সিস্টেম বদলের কারণে পদ্ধতি পাল্টালে নতুন পদ্ধতির প্রশিক্ষণ D6-এরই অংশ।
ওয়ার্ক ইন্সট্রাকশন সংশোধন করার পর ফ্লোরে তা মানা না হলে কোনো লাভ নেই। ফিক্সচার ও সেন্সর দিয়ে ভুল ঘটার সুযোগই বন্ধ করে দেওয়ার ধারণাটি পোকা-ইয়োকে (poka-yoke, ভুল-প্রতিরোধ) নামে পরিচিত, আর অনেক কারখানা এটি ব্যবহার করে।
কার্যকারিতা যাচাই ও কনটেইনমেন্ট তোলা
D6-এ বাস্তবায়নের তারিখ, দায়িত্বপ্রাপ্ত ব্যক্তি এবং যাচাইয়ের ফলাফল লিখুন। MAHLE-এর ম্যানুয়ালে দুই ধরনের যাচাইয়ের কথা আছে। একটি দ্রুত যাচাই, যেখানে বাস্তবায়নের পরপর ইচ্ছে করে ব্যর্থতার শর্ত তৈরি করে দেখা হয় ডিফেক্ট ফিরে আসে কি না। অন্যটি দীর্ঘমেয়াদি যাচাই, যেখানে প্রসেস ক্যাপাবিলিটি ও ব্যর্থতার বিশ্লেষণ ব্যবহার হয়।
"সমাধানের পর কোনো ডিফেক্ট হয়নি" যথেষ্ট নয়। ডেটা দেখান, যেমন আগে-পরে ডিফেক্ট রেট বা প্রসেস ক্যাপাবিলিটি ইনডেক্স, কিংবা নির্দিষ্ট সময়ে উৎপাদন ও ডিফেক্টের সংখ্যা। কোন কোন লট ও তারিখ যাচাই করেছেন তাও লিখুন।
স্থায়ী ব্যবস্থা নিশ্চিত হলে D3-এর কনটেইনমেন্ট (বাছাই ইত্যাদি) তুলে নিন। কনটেইনমেন্ট তোলার তারিখ আর সেই সিদ্ধান্তের ভিত্তি 8D-তে লিখে রাখুন।
D7–D8: পুনরাবৃত্তি প্রতিরোধ ও সমাপ্তি
D6 পর্যন্ত এসে বর্তমান ডিফেক্ট সমাধান হয়ে যায়, কিন্তু 8D এখানে শেষ হয় না। D7-এর কাজ হলো একই ধরনের সমস্যা যেন অন্য প্রোডাক্টে বা ভবিষ্যতের প্রোডাক্টে না আসে।
স্ট্যান্ডার্ড আপডেট করুন
D7-এ সমাধানটি কোম্পানির স্ট্যান্ডার্ডে গেঁথে দিন। MAHLE-এর ম্যানুয়ালে আপডেটের জন্য এই নথিগুলোর কথা আছে:
- ড্রয়িং
- FMEA
- কন্ট্রোল প্ল্যান
- স্পেশাল ক্যারেক্টারিস্টিকসের তালিকা
- প্রোডাক্ট ও প্রক্রিয়ার স্ট্যান্ডার্ড
- মেইনটেন্যান্স প্ল্যান
FMEA পর্যালোচনা সবচেয়ে গুরুত্বপূর্ণ। এই ব্যর্থতার কারণ FMEA-তে আগে থেকে ভাবা না থাকলে ওই ফাঁকটিই সিস্টেম কারণগুলোর একটি।
ব্যর্থতার মোড ও কারণ যোগ করে রেটিং এবং প্রতিরোধ ও শনাক্তকরণের নিয়ন্ত্রণ আপডেট করলে শিক্ষাটি পরের প্রোডাক্ট ও প্রক্রিয়া ডিজাইনে পৌঁছায়। FMEA-তে তথ্য জোগানো একটি কাঠামোবদ্ধ ডিজাইন রিভিউয়ের জন্য DRBFM ও FMEA-র পার্থক্যের নির্দেশিকা দেখুন।
ইয়োকোতেন ও লেসন্স লার্নড
ইয়োকোতেন (yokoten, অনুভূমিক বিস্তার) জাপানি শব্দ, কিছু ইংরেজি ম্যানুয়ালে একে "read across" বলা হয়। এর মানে বর্তমান অনুরূপ প্রোডাক্ট ও প্রক্রিয়ায় একই সমস্যা আছে কি না যাচাই করা এবং দরকার হলে একই সমাধান প্রয়োগ করা। উদাহরণে, একই ধরনের পাঞ্চ ব্যবহার করা অন্য ডাই ও প্রেসগুলোতেও পাঞ্চ বদলের ভিত্তি স্ট্রোক সংখ্যায় আনতে হবে।
লেসন্স লার্নড (lessons learned) হলো ভবিষ্যতের প্রোডাক্ট ও প্রক্রিয়ার ডিজাইনে একই ব্যর্থতা যাতে না ঘটে তার ব্যবস্থা, যেমন ডিজাইন স্ট্যান্ডার্ড ও চেকলিস্টে যোগ করা। দুটিকে আলাদা করে লিখলে গ্রাহকের বুঝতে সুবিধা হয়: ইয়োকোতেন বলে যা এখন আছে তার কথা, লেসন্স লার্নড বলে যা পরে বানাবেন তার কথা।
D8-এ কী লিখবেন
D8 দিয়ে 8D শেষ হয়। টিম রিপোর্ট সম্পূর্ণ করে, সবার কাজের স্বীকৃতি দেয় এবং যা শিখেছে ও গ্রাহকের যে ফিডব্যাক পেয়েছে তা শেয়ার করে। অনেক ফরমে সমাপ্তির তারিখ, অনুমোদনকারী এবং গ্রাহককে চূড়ান্ত রিপোর্ট পাঠানোর তারিখ চাওয়া হয়।
টিমকে ধন্যবাদ জানানো নিছক আনুষ্ঠানিকতা মনে হতে পারে। কিন্তু এতে এমন কর্মপরিবেশ গড়ে ওঠে যেখানে মানুষ পরের সমস্যা সমাধানেও সাহায্য করতে চায়। সেজন্যই G8D এটিকে আলাদা একটি ধাপ হিসেবে রেখেছে।
কেন 8D ফেরত আসে
জমা দেওয়ার আগে শেষবার দেখার জন্য এই পয়েন্টগুলো ব্যবহার করুন। গ্রাহকের কোয়ালিটি ইঞ্জিনিয়ার এগুলোই প্রথমে দেখেন।
এগুলোর একটিও না মিললে 8D ফেরত আসার সম্ভাবনা বেশি।
কারণ "অপারেটরের ভুল"-এ আটকে আছে
মূল কারণের ঘরে "অপারেটর চেক করেননি" বা "অসাবধানতাজনিত ভুল" লেখা 8D ফেরত আসার সম্ভাবনা বেশি। গ্রাহক জানতে চান প্রক্রিয়াটি কেন সেই অপারেটরকে ভুল করার সুযোগ দিল। ভুলটির পথ তৈরি করেছে এমন পদ্ধতি, ফিক্সচার, লেবেলিং ও প্রশিক্ষণ ব্যবস্থা পর্যন্ত খুঁড়ে দেখুন।
কারণ ও ব্যবস্থা মিলছে না
আরেকটি প্রচলিত ফাঁক: D4-এর কিছু কারণের ব্যবস্থা আছে, বাকিগুলোর নেই। কিংবা ব্যবস্থার তালিকায় এমন কিছু আছে যা কোনো লেখা কারণ ব্যাখ্যা করে না। D4 ও D5 পাশাপাশি একটি টেবিলে রেখে দেখুন, প্রতিটি কারণের ব্যবস্থা আছে কি না এবং প্রতিটি ব্যবস্থা কোনো কারণের সঙ্গে যুক্ত কি না।
সময়সীমা রক্ষা করতে গিয়ে বিষয়বস্তু পাতলা
সময়সীমা ধরার জন্য যাচাই-না-হওয়া কারণ বা বাস্তবায়ন-না-করা ব্যবস্থাকে "সম্পন্ন" লেখা ঝুঁকিপূর্ণ। চলমান বিষয়ে "তদন্তাধীন" লিখুন, সম্ভাব্য শেষের তারিখ দিন এবং ধাপে ধাপে উত্তর দিন। শেষ বিচারে এতে গ্রাহকের আস্থা ভালোভাবে রক্ষা পায়।
টেমপ্লেট: D4–D5-এর কারণ-ব্যবস্থা টেবিল
আগের অংশের এক-এক মিল যাচাই এই ছকে টেবিল করে দেওয়া হলো। আপনার গ্রাহকের নির্ধারিত 8D ফরমের সঙ্গে মিলিয়ে বদলে নিন। সারিগুলোতে চিত্র 5 ও 7-এর কাল্পনিক ব্র্যাকেট উদাহরণ ব্যবহার করা হয়েছে। নিজের কারণ ও ব্যবস্থা দিয়ে বদলে নিন।
| কারণের ধরন | মূল কারণ (D4) | কীভাবে যাচাই হয়েছে | স্থায়ী ব্যবস্থা (D5) | দায়িত্বপ্রাপ্ত ব্যক্তি / তারিখ | কার্যকারিতার প্রমাণ (D6) |
|---|---|---|---|---|---|
| অকারেন্স | টুলের আয়ুর মানদণ্ড নেই; পাঞ্চ বদল প্রতিটি অপারেটরের ওপর ছাড়া | টেস্ট স্ট্রোক: ক্ষয়ে যাওয়া পাঞ্চে হোল বড় হয়; নতুন পাঞ্চে আবার স্পেকের মধ্যে ফেরে | স্ট্রোক সংখ্যা দিয়ে পাঞ্চ বদল; প্রেসের কাউন্টার বদলের সময় জানায় | (নাম / তারিখ) | (আগে-পরে ডিফেক্ট রেট বা ক্যাপাবিলিটি; যাচাই করা লট ও সময়কাল) |
| এসকেপ | কন্ট্রোল প্ল্যানের ইনস্পেকশন ফ্রিকোয়েন্সিতে টুল ক্ষয়ের বিষয়টি ধরা হয়নি | (কীভাবে দেখালেন যে শুধু প্রথম পিস মাপলে ধীরে ধীরে বাড়া ক্ষয় ধরা পড়ে না) | নির্দিষ্ট স্ট্রোক পরপর হোলের ব্যাস মাপা; কন্ট্রোল প্ল্যান সংশোধন | (নাম / তারিখ) | (যাচাই করা লট ও সময়কাল) |
| সিস্টেম | (FMEA, কন্ট্রোল প্ল্যান বা স্ট্যান্ডার্ডের ফাঁক) | (পর্যালোচনার ফলাফল) | (D7 আপডেট: FMEA, স্ট্যান্ডার্ড, ইয়োকোতেনের পরিধি) | (নাম / তারিখ) | (আপডেট হওয়া নথি, রিভিশন নম্বর) |
শুরুর আগে গ্রাহককে যে প্রশ্নগুলো করবেন
ফরম ও সময়সীমা গ্রাহকভেদে আলাদা, তাই শুরুতেই গ্রাহকের সাপ্লায়ার কোয়ালিটি যোগাযোগকারীর কাছে এই বিষয়গুলো নিশ্চিত করুন। গ্রাহকরা প্রায়ই সাপ্লায়ার কোয়ালিটি ম্যানুয়ালে তাদের চাহিদা ব্যাখ্যা করেন। আপনার কাছে না থাকলে সর্বশেষ সংস্করণটি চেয়ে নিন।
- কোন 8D ফরম ব্যবহার করব? আপনাদের কি নির্ধারিত টেমপ্লেট আছে?
- প্রতিটি ধাপের সময়সীমা কত (যেমন কনটেইনমেন্ট, মূল কারণ, চূড়ান্ত সমাপ্তি)?
- D0 লাগবে, নাকি শুধু D1–D8?
- কনটেইনমেন্ট কোন কোন জায়গা ধরবে: আপনাদের স্টক, ট্রানজিটের মাল, আর আমাদের স্টক ও WIP?
- ক্লিন পয়েন্ট (প্রথম নিশ্চিত ভালো লট) কীভাবে জানাব?
- চলমান বিষয়ে কি সম্ভাব্য তারিখসহ "তদন্তাধীন" লিখে জমা দিয়ে পরে 8D আপডেট করতে পারব?
- 8D গ্রহণ ও বন্ধ করতে আপনাদের কী প্রমাণ লাগবে (ডেটার সময়কাল, লটের সংখ্যা)?
প্রথম যোগাযোগে একটি ছোট ইমেইল ভালো কাজ করে। গ্রাহকের সঙ্গে সাধারণত ইংরেজিতেই যোগাযোগ হয়, তাই নমুনাটি ইংরেজিতে দেওয়া হলো। বন্ধনীর জায়গাগুলো নিজের তথ্য দিয়ে বদলে নিন:
"Thank you for informing us of the issue with [part number], lot [number]. We have stopped shipping the affected lot and started containment. To make sure our 8D meets your requirements, could you confirm the form you would like us to use and the deadline for each stage? We will send D1–D3 by [date and time]."
গ্রাহক আপনার কারখানা অডিট করার সময়ও কারেক্টিভ অ্যাকশনের অনুরোধ আসে।
এই নির্দেশিকার সীমা
- 8D ফরম, ধাপের নাম ও সময়সীমা গ্রাহকভেদে আলাদা। গ্রাহকের নিজস্ব সাপ্লায়ার কোয়ালিটি ম্যানুয়াল ও নির্ধারিত ফরম সবসময় এই নির্দেশিকার ওপরে।
- এখানে উদ্ধৃত সময়সীমা ও শর্ত (1-5-20 নিয়ম, টিমের ভূমিকা, টুল বাছাই, প্রশিক্ষণকে কীভাবে ধরা হয়, D7-এ আপডেটের নথি) একটি কোম্পানি, MAHLE-এর ম্যানুয়াল থেকে নেওয়া। অন্য গ্রাহক ভিন্ন নিয়ম দিতে পারেন।
- টয়োটার আট ধাপ 8D-র সঙ্গে উদ্দেশ্যের মিল দেখে মেলানো হয়েছে। উৎসভেদে ধাপের নাম আলাদা, আর মিলটি হুবহু নয়।
- চিত্র 5, 7 ও 8 এবং টেমপ্লেটের ব্র্যাকেট উদাহরণ কাল্পনিক। এটি শুধু দেখায় ঘরগুলো কীভাবে পূরণ করতে হয়।
- এই নির্দেশিকা তৈরির সময় 8D-র ফরম্যাট নির্ধারণ করে এমন কোনো বাংলাদেশি (BSTI) স্ট্যান্ডার্ডের সঙ্গে মিল আমরা যাচাই করতে পারিনি। তাই কোনো সমতুল্যতা দাবি করা হয়নি। কোন স্ট্যান্ডার্ড ও কোন সংস্করণ প্রযোজ্য, তা গ্রাহকের কাছ থেকে নিশ্চিত করুন।
প্রশ্নোত্তর (FAQ)
8D ও টয়োটার 8 ধাপ পদ্ধতির পার্থক্য কী?
8D এসেছে Ford থেকে, আর সাধারণত গ্রাহককে ডিফেক্টের উত্তর জানাতে ব্যবহৃত হয়। এতে কনটেইনমেন্ট ধাপ (D3) আছে এবং অকারেন্স ও এসকেপ কারণ আলাদা করে চাওয়া হয়। টয়োটার আট ধাপ কারখানার ভেতরের সমস্যা-সমাধান পদ্ধতি, সাধারণত A3 শিটে সারসংক্ষেপ করা হয়, আর এতে লক্ষ্য নির্ধারণের একটি ধাপ আছে যা 8D-তে নেই। এক পদ্ধতির বিশ্লেষণ অন্যটিতে নেওয়া যায়, তবে 8D-তে কনটেইনমেন্ট আর এসকেপ কজ আলাদা করে লিখতেই হয়।
8D কি আট ধাপ, নাকি নয়?
মূল পদ্ধতিতে আটটি discipline ছিল, D1 থেকে D8। Ford-এর Global 8D যোগ করেছে D0, যেখানে জরুরি সাড়া আর পূর্ণ 8D দরকার কি না সেই সিদ্ধান্ত থাকে। তাই অনেক ফরমে এখন D0 থেকে D8, মোট নয় ধাপ। কিছু গ্রাহক এখনও শুধু D1–D8 ব্যবহার করেন।
8D-তে এসকেপ পয়েন্ট কী?
এটি সেই কন্ট্রোল পয়েন্ট যেখানে সমস্যাটি ধরা পড়ার কথা ছিল কিন্তু পড়েনি, যেমন প্রক্রিয়ার ভেতরের চেক বা আউটগোয়িং ইনস্পেকশন। ধারণাটি G8D যোগ করেছে। রিপোর্টে এটিই এসকেপ কজের শুরুর বিন্দু, অর্থাৎ ত্রুটিপূর্ণ পার্ট কেন গ্রাহকের কাছে পৌঁছাল তার কারণ।
অপারেটর প্রশিক্ষণ কি গ্রহণযোগ্য কারেক্টিভ অ্যাকশন?
একা নয়। যেমন MAHLE-এর ম্যানুয়ালে বলা আছে, অটো শিল্পে শুধু প্রক্রিয়ার উন্নয়নই 8D-র কারেক্টিভ অ্যাকশন হিসেবে গণ্য হয়, আর রিমাইন্ডার বা কর্মী প্রশিক্ষণ নয়। তবে সিস্টেম বদলের কারণে পদ্ধতি পাল্টালে প্রশিক্ষণ দরকার, আর সেটি D6-এর অংশ হিসেবে জানাতে হয়।
সূত্র
- 8D-র উৎস, TOPS, G8D, MIL-STD-1520: Wikipedia, "Eight disciplines problem solving"; AllAboutLean, "The History of the Eight Disciplines Problem Solving (8D)"
- 8D রিপোর্টের সংজ্ঞা ও D4-এর দুটি পথ: Siemens, "8D Report" (জাপানি ভাষার পাতা)
- 1-5-20 নিয়ম, প্রতিটি ধাপের চাহিদা, মানুষনির্ভর ব্যবস্থার বিবেচনা, আপডেটের নথি: MAHLE Supplier Quality Assurance, "8D Process" (PDF)
- IATF 16949 ক্লজ 10.2.3, Problem solving: "IATF 16949:2016 Clause 10.2.3 Problem solving" (ব্যাখ্যা); IATF16949 Kouryaku, "10.2.3 Problem solving requirements" (জাপানি ভাষায়)
- টয়োটার আট ধাপ সমস্যা-সমাধান ও TBP: Gemba Academy, "TBP: Toyota Business Practice"; Lean Enterprise Academy, "Back to Basics: Problem Solving at Toyota"; OJT Solutions, "The 8 Steps of Problem Solving" (জাপানি ভাষায়); Toyota Enterprise, "Toyota-style kaizen (problem solving) training" (জাপানি ভাষায়)
- VDA-র 8D পুস্তিকা: VDA QMC, "8D – Problemlösung in 8 Disziplinen" (1st edition, November 2018)
- AIAG CQI-20: AIAG, "CQI-20 Effective Problem Solving Guide"
জাপানি ভাষায় মূল লেখাএই গাইডটি জাপানের পাঠকদের জন্য লেখা একটি MONOSCOPE লেখা থেকে তৈরি: 8Dレポートの書き方｜D0〜D8の手順・原因分析とトヨタの8ステップとの違い
সম্পাদক সম্পর্কে
MONOSCOPE সম্পাদকFOUNDER & EDITORকারখানার যন্ত্রপাতি নির্মাতা ও প্ল্যান্ট প্রকৌশল প্রতিষ্ঠানে প্রায় দশ বছর যন্ত্রপাতির প্রস্তাব, নকশা ও চালু করার কাজ করার পর ডিজিটাল মার্কেটিংয়ে আসেন। এখন B2B উৎপাদকদের ওয়েব পরামর্শক হিসেবে তাদের পণ্য ও প্রযুক্তি সহজভাবে তুলে ধরতে সাহায্য করেন। জাপানের জাতীয় লাইসেন্স Energy Manager এবং তৃতীয় শ্রেণির প্রধান বৈদ্যুতিক প্রকৌশলীর অধিকারী।
২০১৭ সাল থেকে একটি প্রকৌশল ব্লগ (৫০০টির বেশি লেখা) এবং প্রায় ২০,০০০ গ্রাহকের একটি জাপানি ইউটিউব চ্যানেল চালাচ্ছেন। প্রতিটি গাইড জাপানি কারখানার দৃষ্টিকোণ থেকে লেখা এবং উদ্ধৃত মানের সঙ্গে মিলিয়ে দেখা।
