تدارک ERP از مشکل عملیاتی آغاز میشود، نه از نام محصول
داوطلبی ERP باید روشن سازد کدام تصمیم، ثبت و کنترول باید بهتر شود. نوشتن «مالی، منابع بشری و گدام» کافی نیست؛ داوطلب باید واحدها، موقعیتها، کاربران، سطوح تأیید، اسعار، گزارشها، ادغامها، منابع معلومات و محدودیتهای عملیاتی داخل محدوده را بداند.
نهاد صادرکننده مسئول روش تدارکات، قانون یا قواعد تمویلکننده، صلاحیت ارزیابی و قرارداد نهایی است. این راهنما ابزار پلانگذاری است و جای آن الزامات را نمیگیرد.
۱. پیش از تهیه سند، حاکمیت را تعیین کنید
- مسئول تدارکات، حامی تجارتی، مسئولان روند، ارزیابان تخنیکی و مرجع تأیید را مشخص کنید.
- هدف تدارکات، صلاحیت بودجه، تصمیم مورد نظر و وابستگیهای مهم را ثبت کنید.
- روش وضاحت، تعدیل سند، تعارض منافع، محرمیت و ارتباط با داوطلب را تعریف کنید.
- در صورت الزام قواعد نافذ، مسئول تهیه نیازمندی، ارزیابی و منظوری قرارداد را جدا سازید.
۲. نتیجه و سناریوی واقعی را تشریح کنید
نام عمومی ماژول را به روند end-to-end تبدیل کنید. روند تدارکات میتواند از درخواست، تأیید و نرخگیری تا سفارش، رسید، فاکتور، پرداخت و ثبت حسابداری ادامه یابد. برای هر سناریو نقش، معلومات، حدود تأیید، استثنا، خروجی و شواهد پذیرش را مشخص کنید.
۳. ماتریس قابل پیگیری نیازمندی بسازید
به هر نیاز مهم شناسه بدهید و مطابق روش تأییدشده سازمان دستهبندی کنید. از داوطلب بخواهید وضعیت را واضح بیان کند: امکان استاندارد، تنظیم، توسعه اختصاصی، وابستگی بیرونی، پلان آینده یا انحراف.
- روند، اعتبارسنجی، تأیید و گزارش
- نقش، تفکیک وظیفه و تاریخچه فعالیت
- زبان، RTL، شعبه، واحد و اسعار
- انتقال معلومات، ادغام و وابستگی بیرونی
- دسترسپذیری، سرعت، accessibility و دستگاه
- امنیت، محرمیت، نگهداری، بکاپ و بازیابی
- آموزش، اسناد، نصب، پشتیبانی و خروج
پاسخ «بلی» بدون تشریح یا شواهد نباید با امکان نمایششده و شامل قرارداد یکسان ارزیابی شود.
۴. ماتریس مسئولیت تطبیق را واضح سازید
کار عرضهکننده، کار مشتری و مسئولیت مشترک را جدا کنید. تأیید روند، مالکیت معلومات منبع، پاکسازی، تصمیم تنظیم، دسترسی ادغام، سناریوی تست، UAT، اشتراک آموزش، زیربنا، اجازه cutover و تماس پشتیبانی باید مسئول مشخص داشته باشد.
زمانبندی زمانی معتبر است که وابستگی و مهلت تصمیم هر دو طرف معلوم باشد.
۵. شواهد امنیت متناسب با خطر بخواهید
حساسیت معلومات، فعالیت ممتاز، گروههای کاربر، موقعیت، دسترسی انترنتی، uptime و نیاز بازیابی را توضیح دهید. روش کنترول سورس، تغییر، dependency، secret، محیط، تست، نشر، log، incident و vulnerability را بپرسید.
نام یک framework را خودکار به ادعای تصدیق تبدیل نکنید. شواهد، محدوده و مسئول باید روشن باشد و مسئولیت امنیت تا میزبانی، نگهداری و ختم قرارداد ادامه یابد.
۶. مسئولیت و هزینه کامل را مقایسه کنید
ساختار نرخ قابل مقایسه بخواهید: لایسنس یا اشتراک، تطبیق، تنظیم، توسعه، انتقال، ادغام، زیربنا، سفر، آموزش، مالیه، پشتیبانی، تمدید و موارد اختیاری. تعداد کاربر، محیط، حجم معلومات، ساعت خدمت، اسعار، milestone پرداخت، اعتبار نرخ و قواعد تغییر را ثبت کنید.
۷. نمایش را به شواهد کنترولشده تبدیل کنید
به داوطلبان منتخب سناریو، نقش و زمان یکسان بدهید. از آنان بخواهید امکان موجود را از تنظیم، توسعه پیشنهادی و خدمت بیرونی جدا نشان دهند. پرسشها و وضاحتها را از کانال مجاز ثبت کنید. نمایش عمومی زیبا، اثبات روند واقعی سازمان نیست.
۸. پذیرش و حدود قرارداد را پیش از اعطا تعیین کنید
- خروجیها و مراحل قابل بررسی
- baseline نیازمندی و روش تغییر
- محدوده انتقال و شواهد reconciliation
- محیط تست، طبقهبندی defect و صلاحیت UAT
- cutover، rollback، تحویل و اسناد
- مالکیت معلومات، export، لایسنس و مالکیت فکری
- تضمین، پشتیبانی، سنجش SLA، تمدید و فسخ
وعده مهم ارزیابی باید در قرارداد یا محدوده امضاشده انعکاس یابد.
بسته عملی داوطلبی
بسته کامل معمولاً شامل هدایت، معلومات پسمنظر، محدوده، سناریو، ماتریس نیازمندی، معلومات و ادغام، امنیت، مسئولیت تطبیق، خروجی، روش ارزیابی، قالب پاسخ، جدول تجارتی، شرایط قرارداد و کانال وضاحت است.
منابع اصلی این راهنما
ساختار با مقرره تدارکات پروژههای IPF بانک جهانی، ویرایش ششم و راهنمای فعلی ارزیابی پیشنهادها تطبیق داده شده است. این منابع تنها در محدودهای قابل اجرا است که چارچوب مربوط تعیین کند؛ هر نهاد باید قواعد قانونی، تمویلکننده و داخلی فعلی خود را رعایت کند.