شما در حال خواندن درس بررسی سیستم‌های برنامه‌ریزی و کنترل تولید از MRP تا ERP چیست از مجموعه برنامه‌ریزی و کنترل تولید هستید.

آشنایی با سیستم mrp، سیستم mrp 2 و سیستم ERP

در گذشته‌های نه چندان دور، کسب‌وکارها برای هر بخش از فعالیت‌شان، از نرم‌افزار متفاوتی استفاده می‌کردند؛ البته که امروز هم این رویه‌ در بسیاری از کسب‌وکارها به چشم می‌خورد. مثلاً شاید یک کارخانه برای برنامه‌ریزی تولید از نرم‌افزار MRP، برای ثبت ورودی‌ها و خروجی‌ها از نرم‌افزار انبارداری، برای ثبت سفارشات مشتریان از نرم‌افزار فروش و برای ارتباط با مشتریان از یک نرم‌افزار CRM مستقل استفاده کند.

این در حالی است که بسیاری از این فعالیت‌ها به هم مربوطند، مثلاً برنامه‌های تولید و سفارشات مشتریان بایستی در محاسبات مالی در نظر گرفته شوند، یا شکایات مشتریان و مقادیر موجودی، ملاحظات مهمی برای برنامه‌ریزی تولید به حساب می‌آیند.

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

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

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

در امتداد اجرای این ایده، امروزه سیستم‌هایی به نام ERP توسعه یافته‌اند که میان بخش‌های زیادی از کسب‌وکار ارتباط برقرار می‌کنند و بدین لحاظ یک بسته نرم‌افزاری جامع محسوب می‌شوند. تهیه یک نسخه کامل از ERP می‌تواند به نیازهایمان برای برنامه‌ریزی تولید نیز پاسخ دهد؛ اما اگر برنامه‌ریزی تولید را محوریت قرار دهیم، علاوه بر ERP، بسته‌های نرم‌افزاری کوچک‌تر از جمله MRP و MRP II نیز وجود دارند که می‌توانند متناسب با شرایط، گزینه‌های مناسب‌تری نسبت به ERP باشند.

در این درس توضیحاتی در مورد نرم‌افزارهای MRP و MRP II و ERP ارائه خواهیم کرد. همچنین از آن جا که بیشتر محتویات ارائه شده در مورد این نرم‌افزارها از سوی توسعه‌دهندگان ارائه شده‌اند، گاه بیش از حد به نقاط قوت توجه کرده و چالش‌ها را نادیده گرفته‌اند. بدین جهت برای تعدیل این دسته از مطالب، توجه ویژه‌ای به چالش‌های پیاده‌سازی و بهره‌برداری از این سیستم‌ها خواهیم داشت.

سیستم MRP

سیستم ERP حاصل تجمیع نرم‌افزارهای کوچک‌تر بوده است، بدین جهت هر کدام از آن نرم‌افزارهای کوچک‌تر را می‌توانیم سر آغازی برای شکل‌گیری ERP بدانیم. با این وجود وقتی در چهارچوب برنامه‌ریزی و کنترل تولید به موضوع می‌نگریم، مناسب است که نرم‌افزارهای MRP را به عنوان مبدأ توسعه نرم‌افزارهای ERP در نظر بگیریم. در هر حال اولاً نرم‌افزارهای MRP قبل از ERP به وجود آمده‌اند و ثانیاً تمام قابلیت‌های یک نرم‌افزار MRP را می‌توانیم در نرم‌افزارهای ERP بیابیم.

با این وجود، قدمت طولانی MRP و قابلیت‌های بیشتر ERP باعث نشده که استفاده از MRP کنار گذاشته شود، بلکه امروزه نیز نرم‌افزارهای MRP متنوعی به بازار عرضه می‌شوند و طرفداران زیادی دارند؛ چرا که بسیاری از کسب‌وکارها نیازی به امکانات گسترده ERP ندارند یا ممکن است هماهنگ کردن تمام بخش‌های کسب‌وکار خود با یک نرم‌افزار را در تعارض با منافع‌شان بدانند.

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

اولین نرم‌افزار MRP با مشارکت General Electric و Rolls Royce در اوایل دهه ۱۹۵۰ ایجاد شد؛ اما اولین استفاده تجاری از آن منتسب به شرکت Black and Decker در سال ۱۹۶۴ است. نتایج مطلوب استفاده از این نرم‌افزارها باعث شد که کسب‌وکارهای زیادی از آن‌ها استقبال کنند، طوری که در سال ۱۹۷۵ بیش از  ۷۰۰ کمپانی از MRP استفاده می‌کردند و این تعداد در سال ۱۹۸۱ به ۸۰۰۰ کسب‌وکار رسید.

برای این که بدانیم نرم‌افزار MRP چه قابلیت‌هایی دارد، مفید است به توضیحات درس برنامه‌ریزی مواد مورد نیاز‌ مراجعه کنیم. MRP یکی از مراحل برنامه‌ریزی تولید است که روی مواد مورد نیاز تمرکز دارد. بدین جهت اکثر نرم‌افزارهای MRP دارای امکاناتی برای ایجاد BOM، مدیریت موجودی‌، مدیریت برون‌سپاری، انجام اقدامات نظارتی، تعیین زمان و مقدار تولید، تعیین زمان‌ و مقدار خرید اقلام و تعیین زمان و مقدار تحویل سفارشات هستند. ضمن این که نرم‌افزارهای MRP معمولاً امکان برنامه‌ریزی زمان‌بندی اصلی را نیز دارند و به برنامه‌ریزی مواد مورد نیاز محدود نمی‌شوند.

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

سیستم MRP II

در امتداد ایده تجمیع نرم‌افزارها، سیستم MRP II نسخه کامل‌تری از MRP است که در دهه ۱۹۸۰ ارائه شد؛ بنابراین MRP II همان MRP با ماژول‌ها و قابلیت‌های بیشتر است. برای مثال MRP فقط برای برنامه‌ریزی مواد مورد نیاز است، اما در یک سیستم MRP II ممکن است قابلیت تعیین زمان‌بندی ماشین‌آلات، ثبت اطلاعات فروش، پیش‌بینی تقاضا و برنامه‌ریزی تقاضا نیز پیش‌بینی شده باشد.

البته نرم‌افزارهای MRP II متنوعی ارائه شده که هر کدام قابلیت‌های منحصر به فردی دارند؛ لذا نمی‌توانیم به طور مطلق در مورد امکانات و توانمندی‌های این نرم‌افزارها صحبت کنیم. اما شاخصه اصلی MRP II وجود ماژول‌های متنوع‌تر، پوشش دادن بخش‌های بیشتری از کسب‌وکار و توجه بیشتر به سایر مراحل برنامه‌ریزی تولید است. بنابراین نظر به این که MRP II مراحل بیشتری از فرایند برنامه‌ریزی تولید و بخش‌های بیشتری از کسب‌وکار را پوشش می‌دهد، می‌تواند تصمیم‌های دقیق‌تری اتخاذ کند و عملکرد بهتری در پیش‌بینی پیامدهای ناشی از تغییر در پارامترها داشته باشد.

ایده MRP II یا افزودن ماژول‌های دیگر به MRP در دهه ۱۹۸۰ فراتر از زیرساخت‌های آن زمان بود. در آن زمان، رایانه‌ها قدرت زیادی برای نگهداری و پردازش حجم زیاد طلاعات را نداشتند؛ بدین جهت استفاده از نرم‌افزارهای مثل MRP II‌ به سرمایه‌گذاری قابل توجهی در زیرساهت‌ها نیاز داشت و کم‌تر کسب‌وکاری از عهده‌ی هزینه‌های آن بر می‌آمد. این محدودیت سبب می‌شد که توسعه‌دهندگان در اضافه کردن ماژول‌های مختلف احتیاط کنند؛ اما به تدریج پیشرفت‌های تکنولوژی و ارتقای زیرساخت‌ها به رفع موانع کمک کردند و نرم‌افزارهای جامع‌تری ارائه شدند. امروزه سیستم‌های MRP II‌ جامع‌تر از نرم‌افزارهایی هستند که در گذشته ارائه می‌شدند، اما جامعیت آن‌ها به اندازه‌ای نیست که همه منابع کسب‌وکار را در بر بگیرند و از عبارت ERP برای آن‌ها استفاده کنیم.

سیستم ERP

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

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

از میان MRP و MRP II و ERP کدام گزینه مناسب‌تر است؟

برای انتخاب سیستم نرم‌افزاری مناسب نباید به عناوین MRP و MRP II و ERP بسنده کنیم. این عناوین لزوماً توصیف درستی از امکانات واقعی سیستم نیستند. برای مثال گاه نرم‌افزارهایی با عنوان ERP ارائه می‌شوند که هنوز بسیاری از ماژول‌های آن‌ها آماده نشده و عملاً در حد یک نرم‌افزار MRP II هستند. همچنین شاید محصولی به عنوان ERP ارائه شده باشد، اما از میان امکاناتش فقط ماژول MRP را خریداری کنیم؛ در این حالت عنوان نرم‌افزار ERP‌، اما امکانات تهیه شده در حد MRP است. بنابراین در قدم اول، باید عناوین را رها کرده و امکانات و قابلیت‌های واقعی نرم‌افزار را مبنا قرار دهیم.

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

در شرایطی که هزینه پیاده‌سازی از سیستم MRP به طور قابل توجهی کم‌تر از تهیه ماژول MRP از یک سیستم ERP باشد، باید سیستم مناسب را بر اساس نیازهای خود در آینده انتخاب کنیم. اگر می‌دانیم در آینده نیازی به یک سیستم جامع نخواهیم داشت، پیاده‌سازی گزینه اول منطقی است. اما اگر می‌دانیم که پیاده‌سازی سیستم MRP کافی نیست و تا چندی بعد به یک سیستم جامع‌تری نیاز خواهیم داشت، بایستی هزینه‌های جایگزین کردن سیستم مثل: تعویض قطعات سخت‌افزاری، پرداخت هزینه مجدد برای تهیه سیستم جدید، آموزش دوباره به کارکنان، وقفه در توسعه سیستم و انتقال اطلاعات قدیمی به سیستم جدید را نیز لحاظ کنیم.

مزایای استفاده از نرم‌افزارهای MRP و ERP

در این بخش از درس، به تعدادی از مهم‌ترین مزایای استفاده از سیستم‌های برنامه‌ریزی شامل نسخه‌های مختلف MRP و ERP اشاره خواهیم کرد.

۱- ادغام و تمرکز داده‌ها: نرم‌افزارهای MRP II و ERP با احاطه بر بخش‌های مختلف کسب‌وکار می‌توانند داده‌های مربوط به آن‌ها را در یک بانک اطلاعاتی واحد ادغام کنند. این کار فواید زیادی دارد، برای مثال: وقتی یک داده تغییر می‌کند، داده‌های مرتبط با آن هم به طور خودکار اصلاح می‌شوند، زمان مورد نیاز برای دسترسی به اطلاعات مختلف یا پردازش آن‌ها کاهش می‌یابد، نظارت بر بخش‌های مختلف و اعمال اقدامات کنترلی تسهیل می‌شود، تصمیم‌ها ناظر بر اطلاعات جامع‌تری اتخاذ می‌شوند، گزارش‌ها سریع‌تر و دقیق‌تر تنظیم می‌شوند و همچنین لازم نیست دائماً بعضی داده‌ها در نرم‌افزارها یا دفاتر مختلف ثبت شوند. استفاده از MRP نیز می‌تواند همین مزایا را تا حدودی به همراه داشته باشد، با این ملاحظه که همه قابلیت‌های آن محدود به بخش خاصی از فرایند برنامه‌ریزی تولید هستند.

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

۳- کاهش زمان پردازش اطلاعات: رایانه‌ها می‌توانند اطلاعات را با سرعت زیادی بخوانند و پردازش کنند. مثلاً نرم‌افزار MRP می‌تواند یک تغییر ساده در BOM را تنها در چند ثانیه روی رکوردهای مربوط به مواد مرتبط با آن اعمال کند، یا تنها در چند ثانیه یک گزارش استاندارد از برنامه‌های تولید تهیه کند، یا داده‌های مربوط به یک کالا را از میان انبوهی از داده‌های مختلف بیابد، یا محاسبات لازم برای تعیین زمان‌بندی ماشین‌آلات را در کوتاه‌ترین زمان انجام دهد. این در حالی است که گاه یافتن یک سند در بخش بایگانی سازمان، تهیه یک گزارش ساده، انجام محاسبات ریاضی یا پیش‌بینی تقاضا با روش‌های سنتی به صرف ساعت‌ها یا روزها زمان نیاز دارد.

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

۵- ایجاد چارچوب و سیستمی برای انجام فعالیت‌ها: در شرایطی که بسیاری از کسب‌وکارها چارچوب و فرایند مشخصی برای انجام فعالیت‌های خود ندارند، نرم‌افزارهای MRP و ERP بر اساس استانداردها و فرایندهای مشخصی طراحی می‌شوند. در کسب‌وکارهایی که فرایندهای کاری آن‌ها توسعه نیافته است، پیاده‌سازی سیستم‌هایی مثل MRP و ERP می‌تواند راه خوبی برای سازمان‌دهی فعالیت‌ها باشد. گفتنی است که توسعه‌دهندگان نرم‌افزارهای مشهور مثل SAP و ORACLE به واسطه در اختیار داشتن منابع مالی و سابقه همکاری با واحدهای صنعتی بزرگ، فرایندها و استانداردهای کارآمدی را پیش‌بینی کرده‌اند که پیوستن به آن‌ها، برای بیشتر کسب‌وکارها، بهبود عملکرد بخش‌های مختلف و افزایش بهره‌وری را به همراه خواهد داشت.

۶- افزایش بهره‌وری: مزایایی مثل انجام سریع‌تر کارها، دسترسی موثرتر و سریع به اطلاعات، انجام خودکار فعالیت‌ها، پیاده‌سازی استانداردهای مناسب در سازمان و عملکرد بهتر سیستم‌های می‌تواند به بهبود عملکرد بخش‌های مختلف و افزایش بهره‌وری کسب‌وکار منتهی شود.

۷- کاهش هزینه‌ها: پیاده‌سازی سیستم MRP یا ERP علاوه بر سرمایه‌گذاری اولیه، هزینه‌های ثابت و متغیر مختلفی را تحمیل می‌کند؛ اما از طرفی می‌تواند با افزایش بهره‌وری، مجموع هزینه‌ها را کاهش دهد. لذا نمی‌توانیم تضمین کنیم که پیاده‌سازی این سیستم‌ها لزوماً به کاهش هزینه منتهی شود، زیرا گاه هزینه‌های ناشی از پیاده‌سازی و استفاده از آن‌ها بیشتر از منافع استفاده از آن‌هاست. با این حال، اگر تصمیم برای پیاده‌سازی سیستم آگاهانه و هدفمند باشد، می‌توانیم انتظار داشته باشیم که در میان مدت یا بلندمدت، بهره‌وری افزایش و مجموع هزینه‌ها کاهش یابد.

چالش‌ها و معایب استفاده از نرم‌افزارهای MRP و ERP

استفاده از نرم‌افزارهای MRP و ERP می‌تواند چالش‌ها و معایبی به همراه داشته باشد. باید توجه داشته باشیم که برای پیاده‌سازی این نرم‌افزارها دو راه قابل تصور است. راه اول این است که کسب‌وکار رأساً سیستمی را متناسب با خواسته‌ها و نیازهای خود طراحی کند؛ پیمودن این مسیر پرهزینه و زمان‌بر فقط برای تعداد کمی از سازمان‌های بزرگ توجیه‌پذیر است. راه دوم، استفاده از سیستم‌های تجاری موجود در بازار است که از قبل طراحی شده‌ و به همان شکل در دسترس مشتریان قرار می‌گیرند. هر کدام از این راه‌ها، مزایا و چالش‌های خاصی دارند، اما آن چه در این بخش ارائه می‌کنیم ناظر به پیمودن راه دوم و استفاده از سیستم‌های غیراختصاصی است.

۱- هزینه‌های مربوط به پیاده‌سازی و بهره‌برداری از سیستم

پیاده‌سازی سیستم‌هایی مثل MRP و ERP می‌تواند هزینه‌های مختلفی در پی داشته باشد. بسیاری از ما تصور می‌کنیم که این هزینه‌ها به «حق استفاده از نرم‌افزار» و «هزینه پشتیبانی ماهیانه» محدودند، بدین جهت تخمین اولیه‌مان از هزینه‌ها کم‌تر از مقدار واقعی آن‌هاست. برای تصمیم‌گیری در مورد پیاده‌سازی سیستم و همچنین برای انتخاب مناسب‌ترین بسته نرم‌افزاری، ضروری است برآورد دقیق‌تری از هزینه‌ها داشته باشیم. در این بخش، فهرستی از هزینه‌های محتلف را ارائه خواهیم کرد. هر چند که این فهرست هم کامل نیست؛ زیرا متناسب با شرایط ممکن است هزینه‌های دیگری نیز وجود داشته باشد، ضمن این که هزینه‌های غیر مستقیم زیادی وجود دارد که عملاً شناسایی و فهرست کردن همه آن‌ها مقدور نیست. با این وجود تلاش کرده‌ایم که به مهم‌ترین هزینه‌های قابل توجه و رایج اشاره کنیم.

هزینه‌های مربوط به حق استفاده از نرم‌افزار: امتیاز یا لایسنس استفاده از نرم‌افزارها معمولاً به دو روش اعطا می‌شود. روش اول این است که امتیاز استفاده از نرم‌افزار را برای دوره‌های زمانی محدود، مثلاً‌ ماهیانه و سالیانه، اعطا می‌شود. روش دوم این است که امتیاز استفاده از نرم‌افزار محدودیت زمانی ندارد و کاربر می‌تواند برای همیشه از آن استفاده کند. در رابطه با نرم‌افزارهای جامع مثل ERP معمولاً امکانات نرم‌افزار در قالب ماژول‌های جداگانه ارائه می‌شوند، طوری که متقاضی می‌تواند فقط بعضی از ماژول‌ها را خریداری کند و هزینه کم‌تری بپردازد. اما نکته‌ای که برای محاسبه دقیق‌تر هزینه‌ها باید لحاظ کنیم این است که گاه توسعه‌دهندگان در ازای موضوعات و اتفاقات ظاهراً ساده‌ای مثل ایجاد دسترسی به نرم‌افزار برای کاربران جدید، تغییر دادن فرمت گزارش‌ها یا زیاد شدن حجم اطلاعات، مبالغ اضافه دریافت می‌کنند. این امور در هر حال اتفاق می‌افتند، مثلاً به مرور کارکنان جدید به مجموعه‌مان اضافه می‌شوند که لازم است برای آن‌ها نام کاربری و رمز عبور تعریف کنیم، یا بسیار اتفاق می‌افتد که بخواهیم عناوین مندرج در گزارش‌ها را تغییر دهیم، یا تردیدی نیست که به مرور حجم اطلاعات افزایش یابد. لذا باید قبل از تهیه یک بسته نرم‌افزاری، استعلام بگیریم که چه اموری مشمول هزینه‌اند و تعرفه هر کدام چقدر است.

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

هزینه‌های مربوط به سخت‌افزارهای مورد نیاز: استفاده از نرم‌افزارهایی مثل MRP و ERP مستلزم تنظیمات نصب تجهیزات سخت‌افزاری برای نگهداری از اطلاعات و ایجاد ارتباط بین رایانه‌ها و تجهیزات است. لذا باید بدانیم سیستم مورد نظر به چه تجهیزاتی نیاز دارد، این تجهیزات تا چه زمانی قابل استفاده هستند و تهیه و نگهداری از آن‌ها چقدر هزینه دارد.

هزینه‌های مربوط به نصب و راه‌اندازی: نصب تجهیزات سخت‌افزاری و پیکربندی نرم‌افزار معمولا مشمول پرداخت هزینه هستند.

هزینه‌های مربوط به آموزش کارکنان: استفاده از نرم‌افزارهای MRP و ERP و مدیریت آن‌ها مستلزم آموزش آن به کارکنان است. لذا باید ببینیم که آموزش به ایشان چقدر زمان می‌برد و چقدر هزینه تحمیل می‌کند.

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

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

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

۲- چالش‌های مربوط به امنیت اطلاعات

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

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

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

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

۳- منطبق نبودن مفروضات سیستم و کسب‌وکار

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

این در حالی است که خیلی اوقات تغییر دادن فرایندهایی که به واسطه‌ی سال‌ها آزمون و خطا در سازمان توسعه یافته‌اند و عملرد خوبی دارند، منطقی نیست؛ زیرا تغییر این فرایندها می‌تواند به طور قابل توجهی از بهره‌وری بکاهد.

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

۴- مقاومت در برابر تغییر

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

۵- دشوار بودن ورود اطلاعات قبلی به سیستم جدید

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

۶- آموزش نحوه استفاده از سامانه به کارکنان

استفاده از سیستم‌های برنامه‌ریزی به آموزش نیاز دارد. این آموزش‌ها برای همه افراد یکسان نیستند. هر نرم‌افزار ماژول‌ها و امکاناتی دارد که فقط برای بعضی واحدها و نفرات مشخص کارایی دارند. بنابراین چالش اول این است که نمی‌توانیم از منابع آموزشی یکسان برای همه نفرات استفاده کنیم. البته بعضی از نرم‌افزارها مثل SAP و ORACLE شناخته شده هستند و افراد زیادی روش کار با ماژول‌های مختلف آن را بلدند.

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

۷- ناپایداری اینترنت و ایجاد وقفه در جریان اطلاعات

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

۸- پشتیبانی ضعیف ارائه‌دهندگان نرم‌افزار

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

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

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

0 پاسخ

دیدگاه خود را ثبت کنید

تمایل دارید در گفتگوها شرکت کنید؟
در گفتگو ها شرکت کنید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *