ERP آماده یا اختصاصی؟ تصمیم بر پایهٔ هزینهٔ نگه‌داری

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

مرز منابع: ستون این مقاله استاندارد ERP دولت کنیا (ICTA) است که متن آن را خوانده‌ایم؛ این استاندارد برای نهادهای دولتی کنیاست و برای کسب‌وکار ایرانی الزام نیست؛ آن را فقط به‌عنوان نمونهٔ یک چک‌لیست قراردادی منظم نقل می‌کنیم. از وبلاگ‌های فروشنده فقط ساختار روش آمده است. هیچ عدد هزینه یا مقایسهٔ نام‌دار نداریم. قاعدهٔ «بخر آنچه تمایزآفرین نیست» و مثال‌ها توصیهٔ نویسنده‌اند؛ قواعد حقوقی و مالیاتی ایران بررسی نشده است.

سؤال درست: کدام قابلیت تمایزآفرین است؟

برای هر قابلیت سه پرسش بپرسید (توصیهٔ نویسنده):

1. آیا رقبای شما همین کار را با ابزار استاندارد انجام می‌دهند؟ (دفتر کل، حقوق، خرید ساده: بله.)
2. آیا این فرایند دلیل انتخاب شدن شما توسط مشتری است؟ (قاعدهٔ قیمت‌گذاری خاص، زمان‌بندی ویژهٔ تولید، شبکهٔ توزیع منحصربه‌فرد.)
3. اگر آن را استاندارد کنیم، چه چیزی از دست می‌دهیم و آیا از دست‌رفتنش قابل‌تحمل است؟

پاسخ «بله، استاندارد است» یعنی بخرید و فرایند را با آن تطبیق دهید. «تمایزآفرین است» یعنی یک لایهٔ نازک اختصاصی بسازید، نه یک ERP کامل.

چهار گزینه

سفارشی‌سازی با دروازهٔ تصمیم

استاندارد ICTA کنیا می‌گوید در اکتساب ERP پیکربندی/توسعه بر سفارشی‌سازی اولویت دارد تا وابستگی بلندمدت به فروشنده کم شود، و هر سفارشی‌سازی باید با «بیانیهٔ اثر» ارائه شود: دلیل کسب‌وکاری که پیکربندی یا قابلیت استاندارد جوابگو نیست، تحلیل هزینهٔ بلندمدت (پیچیدگی ارتقا، وابستگی به فروشنده، نگهداری) و ارزیابی ریسک پایداری و ارتقا؛ پیش از شروع توسعه هم تأیید کتبی لازم است. این ایده برای هر سازمانی کارا است. نمونهٔ ساده (توصیهٔ نویسنده):

Kognitos می‌گوید سفارشی‌سازی دامنهٔ تست، اصطکاک ارتقا و هزینهٔ عملیاتی را در طول عمر سیستم افزایش می‌دهد؛ Trupeer هم در قالب fit-gap پیشنهاد می‌کند افزونه جدا و سازگار با ارتقا ساخته شود. هر دو را «توصیه‌های فروشنده» بخوانید، اما با منطق استاندارد ICTA هم‌خوان‌اند.

مالکیت و خروج

اگر سفارشی‌سازی دارید، سه سؤال قراردادی را از پیش جواب دهید. ICTA کنیا نمونهٔ دقیقی دارد: برای اجزای سفارشی، مالکیت کد و مالکیت فکری باید به کارفرما منتقل شود یا دست‌کم حقوق دائمی، غیرقابل‌فسخ و بدون حق امتیاز برای استفاده، تغییر، نگه‌داری و انتقال کد داده شود؛ برای اجزای حیاتی هم escrow کد نزد نمایندهٔ مستقل لازم است که حداقل دو بار در سال و با هر انتشار بزرگ به‌روز شود؛ و برای داده باید قرارداد نسخهٔ کامل را در قالب باز و ماشین‌خوان با فرهنگ داده و اسکیما تحویل دهد و تا ۹۰ روز در انتقال کمک کند. این‌ها برای نهادهای دولتی کنیا نوشته شده‌اند؛ برای شرکت شما نسخهٔ سبک‌تر همین پرسش‌ها را (با وکیل خودتان) مطرح کنید. این مقاله حقوق قراردادها و مالکیت فکری ایران را بررسی نکرده است.

مثال فرضی: سه قابلیت یک شرکت پخش

شرکتی فرضی را در نظر بگیرید که کالا از چند تأمین‌کننده می‌خرد و به فروشگاه‌ها می‌رساند. سه قابلیت را دسته‌بندی می‌کنیم (مثال نویسنده، نه داده واقعی):

الگوی سوم را «لایهٔ نازک» می‌نامیم: ERP منبع سفارش و موجودی است؛ سرویس اختصاصی فقط محاسبهٔ متمایز را انجام می‌دهد و از طریق یک قرارداد API روشن (فیلدها، نسخه، خطاها) به ERP وصل است. اگر ERP عوض شد، فقط آداپتور اتصال تغییر می‌کند، نه منطق متمایز.

اگر ساخت اختصاصی انتخاب کردید: حداقل‌های نگه‌داری

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

هزینهٔ مالکیت: چه چیزهایی را بشمارید

• برای خرید: اشتراک/مجوز، پیکربندی، آموزش، مهاجرت، ارتقا و پشتیبانی.
• برای ساخت: توسعه، تست، امنیت، ارتقای وابستگی‌ها، مستندات، پایش و عملیات، و ظرفیت تیم برای سال‌های بعد.
• برای هر دو: ریسک جابه‌جایی نیرو و هزینهٔ خروج.

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

جدول تصمیم

آستانه‌ها (مثلاً «۱ تا ۳ شکاف») تقریبی و توصیهٔ نویسنده‌اند، نه عدد مرجع. نقطهٔ شروع برای نوشتن نیازمندی‌ها: برنامه‌ریزی پروژهٔ نرم‌افزاری.

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

• مقایسه فقط با قیمت سال اول.
• ساخت چیزی که استاندارد است.
• سفارشی‌سازی بدون بیانیه و بدون مالک.
• قرارداد بدون خروج داده و مستندات.
• ساخت اختصاصی بدون تیم نگه‌داری.

چک‌لیست

1. هر قابلیت به «استاندارد» یا «تمایزآفرین» دسته‌بندی شده است.
2. برای هر سفارشی‌سازی بیانیهٔ اثر نوشته و تأیید شده است.
3. برآورد پنج‌ساله هزینهٔ مالکیت برای هر گزینه ثبت شده است.
4. مالکیت کد، مستندات و escrow (برای اجزای حیاتی) در قرارداد روشن است.
5. خروج داده با قالب باز و فرهنگ داده تعریف شده است.
6. ظرفیت نگه‌داری داخلی ارزیابی شده است.
7. جنبه‌های حقوقی و مالیاتی ایران را از وکیل/حسابدار و منبع رسمی روز گرفته‌اید.

منابع و مراجع

• ERP Standard (Government ICT Standards), clauses 6.1.2.1, 6.1.2.4 and data exit — ICT Authority, Kenya، 2026.
• ERP Implementation: Phases, Failure Rates, and the Workaround Trap — Kognitos.
• Free Fit-Gap Analysis Template for ERP Implementations — Trupeer.
• Implementation (Odoo implementation methodology) — Odoo S.A..