انتخاب نرم‌افزار ERP: روش پنج‌گامی

بیشتر پروژه‌های انتخاب ERP با یک جدول مقایسهٔ ویژگی‌ها شروع می‌شوند و با یک نمایش فروشنده تمام می‌شوند. مشکل: در نمایش، فروشنده فرایند خودش را اجرا می‌کند، نه فرایند شما. این مقاله روش دیگری را پیشنهاد می‌کند: ابتدا نقشهٔ فرایند و معیار پذیرش، سپس fit-gap، سپس پایلوت کوچک و معیار خروج.

مرز منابع: روش‌های fit-gap و تحلیل GAP را از مستندات Odoo، Oracle و چند فروشندهٔ ERP گرفته‌ایم؛ چون فروشنده‌اند، فقط ساختار روش را نقل کرده‌ایم، نه ادعای کارایی. هیچ رده‌بندی یا مقایسهٔ نام‌دار فروشندگان نمی‌دهیم و هیچ آماری دربارهٔ شکست یا هزینه نقل نمی‌کنیم. معیارها و نمونهٔ جدول‌ها توصیهٔ نویسنده‌اند. قواعد حسابداری و مالیاتی ایران بررسی نشده است.

گام اول: نقشهٔ فرایند، نه فهرست ویژگی

سه تا پنج فرایند سرتاسری را انتخاب کنید که بیشترین ارزش یا درد را دارند: مثلاً «سفارش تا دریافت وجه»، «خرید تا پرداخت»، «برنامه‌ریزی و تولید» یا «ورود کالا تا موجودی». برای هرکدام بنویسید:

• ورودی و خروجی و نقش‌های درگیر؛
• استثناهای واقعی (سفارش ناقص، مرجوعی، تغییر قیمت پس از تأیید، ارسال جزئی)؛
• مالک فرایند؛
• یک عدد پایه (زمان چرخه، تعداد خطا یا ساعت کار دستی در هفته).

مقدار استثناها اهمیت دارد: سامانه‌ای که مسیر خوشحال را خوب نشان می‌دهد ولی استثناهای شما را نمی‌پوشاند، بعد از راه‌اندازی هزینهٔ پنهان تولید می‌کند. برای شیوهٔ نوشتن نیازمندی پیش از کدنویسی، برنامه‌ریزی پروژهٔ نرم‌افزاری را ببینید.

گام دوم: معیار پذیرش پیش از دیدن فروشنده

معیار پذیرش یعنی جمله‌هایی که بعداً بشود با «بله/خیر» ارزیابی‌شان کرد. نمونه‌ها (توصیهٔ نویسنده):

گام سوم: fit-gap با چهار سرنوشت برای هر شکاف

Odoo در روش پیاده‌سازی خود می‌گوید تحلیل GAP به مشتری اجازه می‌دهد مشخصات را با نرم‌افزار تطبیق دهد، شک‌ها دربارهٔ امکان‌پذیری را برطرف کند و برنامه و بودجهٔ روشن بگیرد؛ خروجی آن نگاشت نیاز به قابلیت، برنامه و یک اثبات مفهوم با دموی جریان‌های کلیدی است. نمونه‌ای از ساختار جدول:

Kognitos هر شکاف را چهار سرنوشت می‌داند: پیکربندی، سفارشی‌سازی با توجیه تجاری، تغییر فرایند یا راه‌حل بیرون از سیستم، و هشدار می‌دهد راه‌حل بیرونی چون در بودجه و تأیید دیده نمی‌شود، زیر فشار زمان بیشتر انتخاب می‌شود. به همین دلیل در جدول بالا باید «راه‌حل دور» را هم صراحتاً ثبت کنید و مالک و تاریخ بازبینی بگذارید. قالب Trupeer سه پرسش پیش از ساخت پیشنهاد می‌کند: نیاز واقعی است یا عادت؟ آیا کسب‌وکار می‌تواند فرایند استاندارد را بپذیرد؟ و هزینهٔ نگهداری آن در ارتقاهای بعدی چقدر است؟

گام چهارم: پایلوت و داده واقعی

پایلوت را طوری طراحی کنید که فروشنده «داده شما» را اجرا کند: یک ماه سفارش واقعی با استثناها، نه داده نمونه. Odoo از «اثبات مفهوم» با دموی جریان‌های کلیدی نام می‌برد؛ ما پیشنهاد می‌کنیم مالکان فرایند خودشان کلیک کنند، نه فروشنده. در پایان پایلوت هر معیار پذیرش را با بله/خیر ثبت کنید. Linserv توصیه می‌کند فاز کشف جداگانه تأیید و تأمین مالی شود: کم‌هزینه، کم‌ریسک و با داده واقعی برای تصمیم بزرگ‌تر؛ این همان منطق پایلوت است.

سناریوی نمایش به‌جای نمایش فروشنده

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

1. این مرحله با تنظیمات استاندارد انجام شد یا با کد/ماژول اضافه؟ اگر اضافه، هزینهٔ نگهداری آن در ارتقا با چه کسی است؟
2. اگر کاربر اشتباه کرد (مثلاً سفارش را با کد تکراری ثبت کرد) سیستم چه می‌کند؟
3. همین گزارش را برای یک بازهٔ دلخواه و با فیلتر ما نشان دهید.
4. داده را چگونه از سیستم فعلی ما وارد می‌کنید و تطبیق را چگونه نشان می‌دهید؟
5. پس از راه‌اندازی، پشتیبانی چه ساعت‌هایی و با چه کانالی در دسترس است؟

پاسخ‌ها را در همان جدول معیار پذیرش ثبت کنید. جمله‌هایی مثل «این قابلیت در نقشهٔ راه است» را «gap» حساب کنید، نه «fit».

امتیازدهی ساده به‌جای رده‌بندی

برای مقایسهٔ سه تا پنج گزینه یک ماتریس وزنی بسازید و وزن‌ها را قبل از دیدن گزینه‌ها تعیین کنید (وگرنه وزن‌ها به نفع گزینهٔ محبوب تغییر می‌کنند). نمونه با اعداد فرضی:

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

گام پنجم: معیار خروج

معیار خروج یعنی شرط توقف پروژهٔ انتخاب یا کنار گذاشتن گزینه‌ای مشخص. پیشنهاد (توصیهٔ نویسنده):

• اگر بیش از یک‌سوم فرایندهای اصلی به سفارشی‌سازی سنگین نیاز دارند، گزینه کنار می‌رود؛ (آستانه را شما مشخص کنید، ما عدد مرجع نداریم).
• اگر فروشنده نمی‌تواند استثناهای مکتوب را در پایلوت اجرا کند.
• اگر هزینهٔ نگهداری سفارشی‌سازی‌ها از ظرفیت تیم بیرون است.
• اگر مالک داده یا مالک فرایند حاضر به پذیرش تغییر نیست.

چرا رده‌بندی ندهیم؟

جدول‌هایی که «بهترین ERP» را اعلام می‌کنند معمولاً معیار و داده‌شان معلوم نیست. معیار شما (فرایند، داده، استثناها، هزینهٔ نگهداری) با معیار نویسندهٔ آن جدول یکی نیست. به‌جای رده‌بندی، سه تا پنج گزینه را با همین جدول معیار پذیرش بسنجید. نقش‌های لازم در تیم ارزیابی را در نقش‌های پروژهٔ نرم‌افزاری ببینید؛ و اگر مسئلهٔ شما پیش از ERP بودن، انتخاب فناوری است، انتخاب پشتهٔ فناوری را بخوانید.

اشتباهات رایج

• شروع از فهرست ویژگی‌ها و دموی فروشنده.
• نداشتن استثناها در فرایند مکتوب.
• پذیرش «راه‌حل دور» بدون ثبت و مالک.
• تصمیم‌گیری بدون مالکان فرایند.
• سفارشی‌سازی برای هر عادت.
• نداشتن معیار خروج؛ پروژه فقط جلو می‌رود.

چک‌لیست انتخاب

1. سه تا پنج فرایند سرتاسری با استثناها و مالک مکتوب است.
2. برای هر فرایند یک عدد پایه ثبت شده است.
3. معیار پذیرش بله/خیر نوشته شده است.
4. جدول fit-gap با چهار سرنوشت و مالک دارد.
5. پایلوت با داده واقعی و کاربران خودتان انجام می‌شود.
6. معیار خروج پیش از شروع نوشته شده است.
7. هزینهٔ نگهداری سفارشی‌سازی‌ها برآورد شده است.
8. الزامات حسابداری و مالیاتی از حسابدار و منبع رسمی روز بررسی شده، نه این مقاله.

منابع و مراجع

• Implementation (Odoo implementation methodology) — Odoo S.A..
• ERP Implementation: Phases, Failure Rates, and the Workaround Trap — Kognitos.
• Free Fit-Gap Analysis Template for ERP Implementations — Trupeer.
• Creating an ERP Implementation Project Plan — Oracle.
• 3.0 — Project Methodology — Linserv.