انتخاب نرمافزار تولید
چکلیست انتخاب نرمافزار مدیریت تولید و کنترل کیفیت
برای انتخاب نرمافزار مدیریت تولید، فهرست بلند قابلیتها کافی نیست. باید ببینیم سفارش، مواد مصرفی، کنترل کیفیت و محصول نهایی در کار واقعی چگونه به هم وصل میشوند. این چکلیست کمک میکند جلسه معرفی را با پرسشهای روشن و معیارهای قابل بررسی پیش ببرید.
پیش از مقایسه نرمافزارها، مسئله مجموعه را مشخص کنید
از سه پرسش شروع کنید: الان کدام اطلاعات دیر پیدا میشود، کدام ثبتها تکراری است و کدام تصمیمها به داده قابل اتکا دسترسی ندارند؟ پاسخ «همه چیز را یکپارچه میخواهیم» برای ارزیابی کافی نیست. مثلاً مشخص کنید باید مواد مصرفی یک دستگاه را پیدا کنید یا موجودی قابل مصرف برای سفارش بعدی را بدانید؛ این دو نیاز، سناریوهای متفاوت دارند.
نوع تولید را هم روشن کنید. در تولید تیراژی، مثل چسب صنعتی یا محصولات آرایشی، ممکن است سوابق یک گروه محصول را دنبال کنید؛ در ساخت دستگاه، سابقه هر واحد اهمیت دارد. طبق نامگذاری TraceFlow، بچ نامبر مربوط به گروه ورودی، لات نامبر مربوط به گروه محصول نهایی و شماره سریال مربوط به هر محصول تکی است. نرمافزار باید در جلسه با مدل واقعی تولید شما بررسی شود.
- سه مسئله اصلی و یک نمونه واقعی از هر مسئله را بنویسید.
- نوع تولید، واحدهای درگیر و مرز پروژه اولیه را مشخص کنید.
- نیازهای ضروری را از موارد مطلوب و قابل بررسی در آینده جدا کنید.
- مسئول تصمیم، مسئول داده و کاربران هر بخش را تعیین کنید.
یک سناریوی مشترک برای دموی همه گزینهها آماده کنید
برای مقایسه منصفانه، از ارائهدهندگان نخواهید فقط مسیر دلخواه خودشان را نمایش دهند. یک سناریوی فرضی مشترک بدهید: دریافت یک گروه قطعه، کنترل ورودی، مصرف در سفارش، ثبت نتیجه کنترل محصول و تحویل به مشتری. سپس از شناسه محصول به مواد مصرفی برگردید. مسیر معمول را ببینید و بعد یک اصلاح یا نتیجه نامنطبق به مثال اضافه کنید.
برای نمونه میتوانید ساخت دو ترازوی آزمایشگاهی با سریالهای فرضی LB-301 و LB-302 را مطرح کنید. اگر تولیدتان تیراژی است، بهجای آن یک لات شامپو با مواد ورودی مشخص انتخاب کنید. دادهها آموزشیاند و نباید شامل اطلاعات محرمانه مشتریان باشند. نشاندادن این سناریو، به معنی موجودبودن تمام جزئیات آن در هر نرمافزار نیست؛ همین جلسه برای روشنشدن مرز قابلیتهاست.
چه معیارهایی را در جدول مقایسه ثبت کنیم؟
برای هر معیار، نتیجه را با عبارتهایی مثل «نمایش داده شد»، «نیازمند تنظیم»، «نیازمند بررسی» یا «ارائه نمیشود» ثبت کنید. کنار آن، مدرک یا توضیح جلسه و مسئول پیگیری را بنویسید. پاسخ شفاهی مبهم را با قابلیت آماده یکسان حساب نکنید. اگر موردی برای شروع کار ضروری است، روش تحویل و معیار پذیرش آن باید روشن شود.
وزن معیارها را خود مجموعه تعیین کند. برای یک سازنده دستگاه، سابقه هر سریال ممکن است حیاتی باشد؛ برای مجموعه دیگر، برنامه مواد یا ثبت کنترلهای هر گروه اولویت دارد. جمعکردن امتیازها بدون توجه به یک نیاز ضروریِ برآوردهنشده، میتواند نتیجه گمراهکننده بدهد. جدول زیر نقطه شروع است، نه نسخه ثابت برای همه صنایع.
| محور | پرسش کلیدی | شاهد موردنیاز |
|---|---|---|
| تولید | مواد مصرفی به کدام سفارش و محصول متصل میشوند؟ | نمایش یک سفارش نمونه و سوابق آن |
| انبار | مبنای موجودی و کسری مواد چیست؟ | توضیح محاسبه با مقدارهای معلوم |
| کیفیت | نتیجه کنترل به چه موردی مربوط است؟ | رسیدن از محصول یا ورودی به نتیجه کنترل |
| ردیابی | آیا مسیر رفت و برگشت سوابق روشن است؟ | ردیابی بچ ورودی تا لات یا سریال و برعکس |
| دسترسی و داده | حدود نقشها و روش تحویل داده چیست؟ | نمایش موارد موجود و توافق درباره بقیه |
| استقرار | چه کسی آموزش، انتقال و پذیرش را انجام میدهد؟ | برنامه، مسئول و معیار پذیرش مکتوب |
کنترل کیفیت و ردیابی را جدا از تولید نبینید
در ارزیابی نرمافزار کنترل کیفیت، فقط وجود فرم یا نمودار کافی نیست. ببینید نتیجه کنترل ورودی به کدام بچ مواد مربوط است و نتیجه کنترل نهایی به کدام لات محصول یا سریال دستگاه وصل میشود. برای وضعیت نامنطبق هم بپرسید چه کسی تصمیم میگیرد و نتیجه تصمیم کجا ثبت میشود. این ارتباطها کمک میکنند معنی گزارش روشن باشد.
اگر سازمان شما الزامات ISO 13485 یا استاندارد دیگری دارد، مسئول کیفیت باید نیازهای قابل اعمال را مشخص کند و شواهد مربوط به نرمافزار را بررسی کند. خرید نرمافزار یا ثبت الکترونیکی سوابق، بهتنهایی اثبات انطباق یا تضمین دریافت گواهی نیست. TraceFlow گواهی یا مجوز صادر نمیکند؛ نقش آن را باید در کنار روشهای اجرایی و مسئولیتهای سازمان ارزیابی کرد.
پیش از تصمیم نهایی درباره استقرار و پشتیبانی چه بپرسیم؟
هزینه و زمان پروژه فقط به خرید نرمافزار محدود نیست. آمادهسازی کد کالا، بررسی موجودی، آموزش کاربران و انتقال داده هم نیاز به مسئول و زمان دارند. درباره قالب داده قابل دریافت، سوابق قابل انتقال، روش پشتیبانگیری، بازیابی و خروجی اطلاعات سؤال کنید و پاسخ را برای همان نسخه و شرایط پیشنهادی دریافت کنید. هیچکدام را صرفاً از نام محصول فرض نگیرید.
همچنین حدود پشتیبانی، شیوه اعلام مشکل، دامنه تنظیمات و مسئول بهروزرسانی را روشن کنید. اگر اتصال به ابزار دیگری لازم است، نام سیستم، نوع داده، تناوب تبادل و مسئولیت هر طرف باید مشخص شود. در این مقاله وعده اتصال آماده، زمان تحویل یا تعرفه خاصی برای TraceFlow داده نمیشود؛ این موارد باید در بررسی نیاز و توافق همکاری تعیین شوند.
- چه اطلاعاتی قبل از شروع باید آماده و تأیید شود؟
- چه مواردی در نسخه فعلی موجود است و چه مواردی نیاز به بررسی دارد؟
- آموزش کاربران و پشتیبانی در چه دامنهای ارائه میشود؟
- روش پشتیبانگیری، آزمون بازیابی و دسترسی به خروجی داده چیست؟
- چه سناریویی معیار پذیرش و شروع بهرهبرداری خواهد بود؟
پذیرش نرمافزار را با یک گردش کامل انجام دهید
بهتر است پیش از گسترش استفاده، یک گردش محدود را از ابتدا تا انتها بررسی کنید و نتیجه مورد انتظار را از قبل بنویسید. مثلاً مسئول انبار، تولید و کیفیت هرکدام بخش خود را ثبت کنند؛ سپس سابقه محصول، مواد مصرفی و نتیجه کنترل با هم تطبیق داده شود. اختلافها باید ثبت و پیگیری شوند، نه اینکه با حدس کاربران نادیده گرفته شوند.
برای بررسی TraceFlow، ابتدا قابلیتها و تصاویر صفحات مرتبط را ببینید و همین چکلیست را به جلسه معرفی بیاورید. هدف انتخاب ابزاری متناسب با کار مجموعه است، نه گرفتن پاسخ مثبت به همه پرسشها. مشخصبودن محدودیتها پیش از شروع، از تکیه بر فرضهای نادرست بهتر است. اگر هنوز از اکسل استفاده میکنید، مقاله مقایسه روش ثبت اطلاعات نیز میتواند نقطه شروع خوبی باشد.
