توسعه عملکرد کیفی (QFD)

 بخش بیستم؛ توسعه عملکرد کیفی (Quality Function Deployment)

توسعه عملکرد کیفی (QFD) یک ابزار عالی برای کمک به ایجاد و اولویت بندی الزامات مشتری است. یکی از جنبه های مهم در توسعه محصول و کیفیت آن، تبدیل الزامات مشتریان به معیارهای کمی عملکرد فنی (TPMs) است که حروف اختصاری برای عبارت Quantitative Technical Performance Measures است. از آنجایی که همه الزامات به یک اندازه اهمیت ندارند، اولویت بندی و رتبه بندی آنها ضروری است تا به مهمترین ویژگی ها توجه بیشتری شود.

QFD در ژاپن شکل گرفت و اولین بار در کارخانه کشتی سازی کوبه زیرمجموعه صنایع سنگین میتسوبیشی در سال ۱۹۷۲ معرفی شد. دنبال کردن دو هدف منجر به شکل گیری مفهوم QFD شد. این دو هدف عبارت بود از :

۱-تبدیل نیازهای کاربران و مشتریان به ویژگی های کیفی در مرحله طراحی،

۲- تبدیل ویژگی های کیفی جدید در مرحله طراحی به نقاط کنترلی و بازرسی های لازم قبل از شروع به تولید محصول.

QFD یک فعالیت گروهی و میان رشته ای برای برنامه ریزی، طراحی محصولات یا خدمات جدید (بهبود یافته) است به گونه ای که:

-بر نیازهای مشتری تمرکز می کند.

– از محیط رقابتی و پتانسیل بازاریابی برای اولویت بندی اهداف طراحی محصول استفاده می کند.

– باعث شکل گیری کار تیمی و تقویت آن می شود.

– انعطاف پذیری در مستند سازی فرآیند.

– نیازهای مشتری را به اهداف قابل اندازه گیری تبدیل می کند، به طوری که محصولات و خدمات مناسب در اولین بار سریعتر و به درستی به بازار معرفی می شوند.

ابزارهای پایه برای تجزیه و تحلیل و ایجاد ساختار داده های کیفی در QFD استفاده می شود. این ابزارها برای ایجاد ماتریسی از نیاز مشتری و ویژگی ها/معیارهای محصول استفاده می شوند. صدای مشتریان (Voices of customers) توسط مشاهدات و مصاحبه ها جمع آوری می شود که سپس برای ساختن یک نمودار جدولی سازماندهی می شود.

به طور مشابه، ویژگی و معیارهای کیفی محصول نیز دسته بندی و در قالب یک نمودار جدولی (درختی) نمایش داده می شود که صدای شرکت نام دارد (Voice of the company). در گام بعدی جدول صدای مشتری در محور y و جدول صدای شرکت در محور x قرار می گیرد و بین این دو جدول یک ماتریسی را تشکیل می دهیم که به عنوان ماتریس QFD یا خانه کیفیت (House of Quality) به اختصار HOQ نامگذاری شده است.

این ماتریس برای ارزیابی روابط بین آیتم ها در هر دو بعد استفاده می شود. رابطه بین سطرها و ستون ها را می توان با کمک نمادهایی علامتگذاری کرد. ماتریس HOQ یک منبع ارزشمند برای طراحان است و کارشناسان از آن به عنوان راهی برای خلاصه کردن و تبدیل الزامات به مشخصات طراحی استفاده می کنند.

HOQ، از طریق نیازهای مشتری و تجزیه و تحلیل رقابتی، به شناسایی اجزای فنی حیاتی که نیاز به تغییر دارند کمک می کند. سپس مسائل مهم از طریق ماتریس‌ بررسی می‌شوند تا مهم‌ترین جنبه‌ها در عملیات تولید وکنترل کیفیت برای تولید محصولی که نیازهای مشتری و تولیدکننده را در یک زمان چرخه توسعه کوتاه‌تر برآورده می‌کند، شناسایی شود. شکل (۱) اجزا یک ماتریس خانه کیفیت را نشان می دهد.

شکل ۱- اجزاء خانه کیفیت  HOQ

مرحله حیاتی برای تکمیل ماتریس، تعیین نوع ارتباط مابین نیاز مشتری در مقابل ویژگی های طراحی است. برای تعیین نوع رابطه از دو کلید واژه چه نیازی وجود دارد (what) و چگونه باید تأمین شود (How) استفاده می شود. به طور خاص، ما به دنبال روابط مستقیمی هستیم که در آن ویژگی های طراحی، نیاز کاربر را برآورده کند. چهار نوع نماد برای تعیین رابطه استفاده می شود:

⦿  خیلی قوی (۸)

●  متوسط (۶)

○ ضعیف (۴)

△ خیلی ضعیف (۲)

بعد از تعیین نوع رابطه، گام بعدی در تجزیه و تحلیل ماتریس HOQ، محاسبه وزن برای هر یک از الزامات در طراحی است. یک مدل رایج استفاده از شاخص اهمیت فنی نرمال شده NTI (Normalized Technical importance) برای شناسایی ویژگی‌های بحرانی است که به صورت زیر تعریف می شود:

 که در این روابط :

User Rating _j : منظور میزان اهمیت j امین نیاز توسط کاربر (مشتری) است. این اهمیت و رتبه بندی نیازها با یک عدد مشخص می شود. عدد بالا نشان دهنده با اهمیت بودن آن نیاز است (برای مثال می توان از اعداد بین ۱ تا ۵ استفاده کرد. که عدد ۵ به معنی بالاترین اهمیت و عدد ۱ به معنی کمترین است یا می توان با همین امتیازها در ماتریس HOQ هم بیان کرد. به عبارت دیگر با اهمیت ترین نیاز عدد ۸ و کم اهمیت ترین عدد ۲ می گیرد.

Relative Importance _ij : مقدار رابطه بین ویژگی طراحی iام با نیاز jام مشتری در ماتریس HOQ است که با چهار حالت خیلی قوی (۸)، متوسط (۶)، ضعیف (۴) و خیلی ضعیف (۲) مشخص شده است.

Individual Rating : به ازای هر نیاز، مجوع روابط آن را با بقیه ویژگی های طراحی و فنی حساب می کنیم و بعد در رتبه اهمیت که مشتری به این نیاز داده است ضرب کرده و در انتها بین اعداد بدست آمده بیشترین مقدار را پیدا می کنیم.  

رتبه‌بندی NTI از حاصل تقسیم رتبه‌ مربوط به‌ هر نیاز (Individual Rating)، نسبت به بیشترین مقدار (عمل نرمالایز کردن) برای شناسایی الزامات مهم استفاده می‌کند. البته راه های زیادی برای ارزیابی اهمیت الزامات وجود دارد. به عنوان مثال، می توان از کاربران خواست که همه الزامات را به ترتیب رتبه بندی کنند. اگر تعداد ویژگی های مورد نظر زیاد نباشد، این رویکرد ممکن است به خوبی کار کند.

 با این حال، اگر حجم نیازمندی‌ها زیاد شود و ساختارهای سلسله مراتبی زیادی را شامل شود (مانند الزامات کاربر، الزامات قابلیت استفاده، الزامات عملکردی، الزامات محیطی و غیره)، رتبه‌بندی همزمان آنها در دسته‌های مختلف برای مشتریان دشوار بوده و باید از نوعی مدل ها برای کمک به فرآیند تصمیم گیری استفاده کنیم. برای مثال می توان از مدل فرآیند تحلیل سلسله مراتبی AHP (Analytical Hierarchical Process) استفاده کرد.

شکل ۲- طراحی و اجرای ماتریس خانه کیفیت در محیط اکسل 

مدیریت الزامات (Requirements Management)

مدیریت نیازمندی ها یکی از مهم ترین ارکان در طراحی و توسعه محصول است. یک برنامه مدیریت نیازمندی که به خوبی اجرا شده باشد می تواند کارایی پروژه را برای کلیه مراحل ازجمله تجزیه و تحلیل عملکرد تا تأیید طراحی، به میزان قابل توجهی افزایش دهد و حتی ارتباط بین ذینفعان را تسهیل کند.

تغییرات دیرهنگام در طراحی به دلیل مدیریت ضعیف نیازمندی ها می تواند باعث تأخیر در زمان تکمیل پروژه و افزایش هزینه ها شود. اگر نیازمندی‌ها اساس طراحی و توسعه محصول هستند، مدیریت الزامات و نیازمندی‌ها عبارت است از شالوده ای که خانه (عملکردهای محصول) خود را بر روی آن می سازیم.

به طور کلی، مدیریت الزامات فرآیندی از مستندسازی، طبقه بندی، تجزیه و تحلیل، ردیابی و اولویت بندی الزامات محصول در یک پایگاه داده به صورت ساختاریافته است که امکان ارتباط موثر بین الزامات و سایر عناصر طراحی محصول و همچنین کنترل تغییرات را فراهم می کند.

مدیریت الزامات یک فرآیند مستمر در طول فرآیند طراحی است. نگرانی اصلی آن کنترل موثر جهت یکپارچه سازی اطلاعات مربوط به الزامات تولید و حفظ آن در طول چرخه حیات تکمیل محصول است. هدف آن در نهایت برآورده کردن نیاز مشتریان، کاربران و به طور کلی ذینفعان است.

به عنوان بخشی از تلاش‌های برنامه‌ریزی پروژه طراحی و توسعه محصول، مدیریت الزلمات با تجزیه و تحلیل و استخراج اهداف، مأموریت‌ و محدودیت ها آغاز می‌شود. پس از جمع‌آوری الزامات و تحلیل اولیه، برنامه‌ریزی را برای نیازمندی‌ها ارائه می‌کند تا بتوان آنها را به زبان فنی ترجمه کرد.

برای اینکار هم از قالبی استاندارد استفاده می شود تا ویژگی‌های هر نیاز و همچنین روابط آن با سایر نیازها مستند گردد. روابط بین نیازها باید به صورت سلسله مراتبی باشد چراکه نیازمندی های سطوح پایین می تواند نیازهای سطوح بالاتر را تکمیل یا اصلاح نماید.

چرا مدیریت الزامات؟

۱-طراحی محصول نیاز محور است. الزامات در کل فرآیند طراحی و حتی چرخه عمر محصول مورد نیاز است. الزامات باید در هر نقطه از مراحل قابل بازیابی باشد. برای یک سیستم بزرگ و پیچیده، حجم نیازها بسیار زیاد است. جای تعجب نیست که ده ها هزار مورد در سطوح و دسته های مختلف جمع آوری می شوند. ثبت و مدیریت این تعداد زیادی از ویژگی های مد نظر، خودش یک چالش است.

با حجم زیاد از ویژگی و روابط پیچیده بین آنها و سایر مولفه ها در طراحی محصول،  نمی توان برای یک مدیریت قابل اتکاء به روش های ساده ای مانند اسناد کاغذی یا حافظه انسانی وابسته بود. ابزارهای مدیریت سیستم های مبتنی بر پایگاه داده برای مدیریت حجم عظیمی از اطلاعات مربوط به نیازمندی ها مورد نیاز است و طراحان می توانند فقط بر روی فعالیت های طراحی تمرکز داشته باشند.

یک ابزار مدیریت الزامات سیستم (Systems Requirements Management Tool) که به درستی انتخاب شده می تواند کارایی پروژه طراحی محصول را به میزان قابل توجهی افزایش دهد و در نتیجه در زمان و هزینه صرفه جویی کند.

۲-با توجه به ماهیت الزامات و ویژگی ها، غیرمعمول نیست که یک پروژه بزرگ و پیچیده نیازمند فرآیند اصلاح دائمی باشد. تغییرات ممکن است در هر مرحله از طراحی محصول رخ دهد از جمله:

– تلاش برای استفاده از یک فناوری جدید،

-مشتریان نیازهای خود را تغییر داده اند،

-خطای جدید در طراحی شناسایی شده است،

– محیط کاربری جدید اضافه شده است،

– قوانین و مقررات جدید تازه از تنور درآمده و غیره.

در بیشتر مواقع، ایجاد تغییرات به خودی خود چالش مهمی نیست بلکه این تاثیر تغییرات است که باعث مشکلات زیادی می شود. همانطور که می دانیم طراحی محصول توسط الزامات هدایت می شود، روابط متقابل بین عناصر طراحی بسیار پیچیده است. ایجاد یک تغییر کوچک در یکی می تواند یک اثر دومینو وار داشته و منجر به یک واکنش زنجیره ای شود که در نهایت تأثیر زیادی در ساختار سلسله مراتبی خواهد داشت.

روند اجرای تغییرات باید رسمی و به شدت کنترل شده باشد. اکثر ابزارهای مدیریت الزامات، نرم افزارهای کامپیوتری مبتنی بر ساختار پایگاه داده هستند. بنابراین، آنها می توانند به راحتی عناصر مرتبط در سیستم و روابط بین آنها را تعیین کنند و به طور قابل توجهی زمان و تلاش لازم برای آماده سازی اجرای تغییرات را کم کرده و در نتیجه هزینه های مربوطه را کاهش می دهد. ثابت شده است که مدیریت الزامات موثرترین راه برای اجرای تغییرات مربوط به پروژه طراحی است.

۳-مدیریت الزامات، قابلیت ردیابی را فراهم می کند. قابلیت ردیابی یکی از ویژگی های کلیدی در طراحی است. در زمینه مهندسی محصول، قابلیت ردیابی به موارد زیر اشاره دارد:

توانایی (توصیف) دنبال کردن یک ویژگی و نیاز، از مبدأ آن و از طریق ثبت مشخصات، تا استقرار و استفاده بعدی و همچنین در تمام مراحل و فازهای توسعه محصول.

قابلیت ردیابی یکی از مهمترین عوامل برای اطمینان از منطقی بودن فرآیند طراحی محصول است. در میان صدها یا هزاران فعالیت و تلاش، قابلیت ردیابی اطمینان حاصل می کند که همه این فعالیت ها به خوبی برنامه ریزی شده و روی اصول انجام می شود. قابلیت ردیابی یکی از مهم ترین دلایلی است که چرا مدیریت الزامات ضروری است.

ویژگی های مد نظر برای یک محصول از منابع مختلف و در قالب های مختلف می آید. در طول چرخه حیات سیستم، این ویژگی ها مراحل تکاملی مختلفی را پشت سر گذاشته و در نهایت، از طریق انواعی از عملکردهای محصول برآورده می‌شوند.

طراحی برخی از محصولات پیچیده، معمولاً ماهها و حتی سالها طول می کشد. در طول دوره انتقال طولانی، ما می خواهیم تک تک تغییرات و تحولات را برای هر یک از الزامات مستند کرده تا اطمینان حاصل کنیم که طراحی مسیر درست را دنبال می کند. حفظ قابلیت ردیابی، روند تأیید را در مراحل بعدی تسهیل می کند.

دو مفهوم مرتبط با ردیابی عبارت است از ردیابی افقی و عمودی. برخی از الزامات اولیه سطح بالا ممکن است توسط الزامات سطوح پایین تر که به احتمال زیاد نتیجه فعالیت تیم های طراحی یا مدل های تصمیم گیری است، پالایش شوند که به آن ردیابی افقی (Horizontal traceability) گفته می شود، زیرا در خود بدنه نیازمندی رخ می دهد. اما سایر الزاماتی که توسط برخی منابع خارجی خواسته شده و باید محصول آنها را تأمین کند، قابلیت ردیابی عمودی (Vertical traceability) نام دارد.

قابلیت ردیابی را می توان با استفاده از ماتریس ردیابی (Traceability matrix)، نمودار جریان سلسله مراتبی (Hierarchical flow chart)، گزارش ها و جداول بر اساس نیازهای تحلیل، ارائه کرد.

منبع:

Systems Engineering Design Principles and Models, Dahi Liu