مراحل پیاده‌سازی ERP کم‌ریسک

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

مرز منابع: ساختار مراحل از مستندات Oracle و Odoo و راهنمای چند شرکت پیاده‌سازی (Linserv، NETLINKS، Exactlly) گرفته شده است. چون این‌ها فروشنده یا مشاورند، هیچ آمار مدت یا هزینه از آن‌ها نقل نکرده‌ایم. مدت هر مرحله و آستانه‌های پیشنهادی، توصیهٔ نویسنده‌اند. قواعد حسابداری و مالیاتی ایران بررسی نشده است.

نمای کلی مراحل

Linserv مراحل کشف، طراحی، ساخت، اعتبارسنجی، راه‌اندازی و بهینه‌سازی را می‌شمارد و Odoo اجرا را در چرخه‌هایی از تحلیل، توسعه، اعتبارسنجی و آموزش کاربران کلیدی می‌داند. ما همین ساختار را به عنوان چارچوب می‌گیریم؛ هر مرحله «شرط ورود به مرحلهٔ بعد» دارد.

پیش از ساخت: طراحی و کنترل تغییر

خروجی طراحی باید سه چیز باشد: نقشهٔ فرایند «به‌عنوان طراحی‌شده» (to-be)، فهرست شکاف‌ها با سرنوشت هر کدام، و فهرست یکپارچه‌سازی‌ها با مالک هر فیلد. اگر مرحلهٔ انتخاب را با fit-gap انجام داده‌اید، همین جدول وارد این مرحله می‌شود. دو قاعدهٔ سادهٔ کنترل تغییر (توصیهٔ نویسنده):

• هر درخواست تغییر پس از تثبیت طراحی، با «نیاز یا عادت؟»، هزینهٔ ساخت و هزینهٔ نگهداری ارزیابی می‌شود و فقط با تأیید مالک فرایند و مالک بودجه وارد می‌شود.
• راه‌حل‌های بیرون از سیستم (اکسل کنار ERP) ثبت می‌شوند با مالک و تاریخ بازبینی؛ بدون ثبت، پس از چند ماه بخشی از فرایند رسمی می‌شوند.

تقویم نمونه (فرضی) از دید ترتیب، نه مدت

ما مدت زمان مرجع نداریم و عمداً هفته نمی‌نویسیم؛ ترتیب و شرط ورود به مرحلهٔ بعد مهم است:

1. طراحی تأییدشده ← شروع ساخت.
2. مهاجرت آزمایشی اول ← رفع مشکلات داده ← مهاجرت آزمایشی دوم.
3. دو مهاجرت با گزارش تطبیق پذیرفته‌شده ← آغاز UAT.
4. UAT امضاشده و آموزش تمام‌شده ← تمرین cutover.
5. تمرین cutover با زمان‌بندی قابل‌قبول و rollback اثبات‌شده ← تعیین تاریخ راه‌اندازی.

پیشنهاد: تاریخ راه‌اندازی را تا پایان مرحلهٔ ۵ قطعی نکنید و ترجیحاً آن را با مرز یک دورهٔ مالی هماهنگ کنید تا تطبیق مانده‌ها ساده‌تر شود؛ این هماهنگی را حسابدار شما باید تأیید کند.

چه کسی چه می‌کند؟

مهاجرت و پاک‌سازی داده

Exactlly می‌گوید مهاجرت فقط «export از قدیم و import در جدید» نیست و تصمیم‌هایی دربارهٔ دامنه، مالکیت، پاک‌سازی، تبدیل، نگاشت، اعتبارسنجی، زمان‌بندی و تطبیق می‌خواهد؛ و بین مالک و مجری فرق می‌گذارد: صحت داده با کسب‌وکار است، اجرا می‌تواند با فروشنده باشد. Oracle توالی را این‌طور می‌گوید: بازرسی، استخراج، پاک‌سازی و تبدیل، نگاشت به ساختار ERP، بارگذاری، مقایسه با منبع و تست یکپارچگی. همچنین یادآوری می‌کند لازم نیست همهٔ تاریخچه منتقل شود؛ معمولاً حدود دو سال، مگر الزامات انطباق بیشتر بخواهد. (الزامات نگه‌داری سوابق در ایران را باید از منبع رسمی و حسابدار بپرسید؛ این مقاله بررسی نکرده است.)

ماتریس نگاشت (نمونه):

دو مهاجرت آزمایشی

Linserv «حداقل دو مهاجرت آزمایشی» را الزامی می‌داند چون داده همیشه کثیف‌تر از انتظار است؛ NETLINKS هم می‌گوید مهاجرت تمرین است نه یک رویداد. بعد از هر بار بارگذاری:

1. تعداد رکورد مبدأ و مقصد را برای هر شیء مقایسه کنید.
2. مجموع‌های کنترلی (جمع مانده‌ها، جمع موجودی) را تطبیق دهید؛ NETLINKS می‌گوید مانده‌های افتتاحیه باید با تراز آزمایشی قدیم تطبیق کند.
3. نمونه‌ای از رکوردها را دستی بررسی کنید، نه فقط مجموع‌ها.
4. هر مشکل را با مالک و تاریخ ثبت کنید؛ «پاک‌سازی بعداً» ممنوع.

اعتبارسنجی و آموزش

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

راه‌اندازی: runbook و راه برگشت

Exactlly توصیه می‌کند cutover را از «روز اول» به عقب بنویسید: چه چیزی باید درست باشد که کاربران صبح کار کنند؟ NETLINKS هم سؤال مهم را این می‌داند: اگر در ساعت سوم مشکلی پیش آمد، آیا پیش از شروع روز کاری می‌توانید به سیستم قدیم برگردید؟ اگر پاسخ «بله» روشن نیست، آماده نیستید. اجزای runbook (توصیهٔ ترکیبی نویسنده):

• توقف ثبت در سیستم قدیم در لحظهٔ مشخص؛
• مهاجرت دلتای نهایی؛
• فعال‌سازی کاربران و دسترسی‌ها؛
• تطبیق مانده‌ها و موجودی؛
• آزمون دودی فرایندهای کلیدی؛
• جلسهٔ go/no-go با تصمیم‌گیرندگان نام‌دار؛
• مراحل rollback نوشته و تمرین‌شده.

تمرین کامل cutover را پیش از اجرای واقعی در محیط آزمایشی انجام دهید و زمان هر مرحله را ثبت کنید؛ ایده «runbook که اجرا نشده فقط نظریه است» از Exactlly می‌آید.

پشتیبانی پس از راه‌اندازی

Linserv پشتیبانی ویژه (هایپرکر) را یک تا دو هفته پیشنهاد می‌کند و بعد مرحلهٔ بهینه‌سازی با بازبینی و آموزش هدفمند. این بازه برای همهٔ سازمان‌ها یکسان نیست؛ ملاک شما باید «چرخهٔ بسته‌شدن مالی نخست» و روند مشکلات باشد. پایش سیستم با متریک و هشدار و آمادگی تولید نرم‌افزار چارچوب عملیاتی خوبی برای این دوره‌اند.

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

• مهاجرت یک‌بار و بدون تطبیق.
• تست با داده نمونه یا با دموی فروشنده.
• آموزش کاربران در هفتهٔ آخر.
• cutover بدون rollback تمرین‌شده.
• تحویل بدون مالک نگه‌داری.
• انتقال همهٔ تاریخچه بدون ضرورت.

چک‌لیست

1. مالک داده برای هر شیء مهاجرت تعیین شده است.
2. ماتریس نگاشت فیلدها نوشته شده است.
3. حداقل دو مهاجرت آزمایشی با گزارش تطبیق انجام شده است.
4. مانده‌های افتتاحیه با تراز آزمایشی قدیم تطبیق کرده‌اند.
5. UAT با داده واقعی و کاربران نهایی انجام و امضا شده است.
6. آموزش نقش‌محور تمام شده است.
7. runbook و rollback تمرین شده است.
8. جلسهٔ go/no-go با تصمیم‌گیرندگان نام‌دار برگزار می‌شود.
9. پشتیبانی ویژه و مالک نگه‌داری مشخص است.
10. الزامات حسابداری، مالیاتی و نگه‌داری سوابق از منبع رسمی روز و حسابدار بررسی شده است.

منابع و مراجع

• Creating an ERP Implementation Project Plan — Oracle.
• 3.0 — Project Methodology — Linserv.
• Odoo Implementation Checklist — NETLINKS.
• ERP Implementation, Data Migration & Go-Live — Exactlly.
• Implementation (Odoo implementation methodology) — Odoo S.A..