سند نیازمندی ERP دقیقاً چه چیزی را باید حل کند؟
در پروژه ERP، مشکل اصلی معمولاً کمبود ایده نیست؛ مشکل این است که خواستههای واحدهای مختلف به زبان مشترک و قابلسنجش تبدیل نشدهاند. سند نیازمندی ERP باید این فاصله را پر کند: از نیاز کسبوکار، به نیاز ذینفع، به نیاز راهکار و در نهایت به چیزی که بتوان آن را طراحی، پیادهسازی و آزمون کرد. استاندارد ISO/IEC/IEEE 29148 بر همین چرخه تأکید دارد و میگوید خروجی فرایند نیازمندی باید اطلاعاتی شفاف، ساختیافته و قابلتأیید باشد. (مطابق منابع انتهای مقاله)
برای مدیر پروژه تحول دیجیتال و مدیر فناوری اطلاعات، ارزش سند نیازمندی فقط در ثبت خواستهها نیست؛ ارزش اصلی آن در کمکردن ابهام، کنترل دامنه، و ساختن مبنایی مشترک برای طراحی، تغییر و پذیرش است. IIBA نیز تأکید میکند که ردیابی نیازمندیها و طراحیها، هم به ریشه نیاز کسبوکار و هم به اجزای راهکار و تستها وصل میشود. (مطابق منابع انتهای مقاله)
- هدف کسبوکار و مسئله اصلی
- دامنه درون/بیرون محدوده
- فرایندهای کلیدی و استثناها
- نیازمندیهای عملکردی و غیرعملکردی
- داده، گزارش، امنیت، یکپارچگی
- معیار پذیرش و سنجههای موفقیت
بهجای فهرست خواستهها، سناریو بنویسید
اشتباه رایج این است که سند نیازمندی را بهصورت فهرستی از جملات کلی بنویسیم: «سیستم باید گزارش بدهد»، «فرایند خرید سریع شود» یا «انبار دقیق باشد». این جملات برای بحث اولیه مفیدند، اما برای اجرا کافی نیستند. هر خواسته باید به سناریویی قابل ارزیابی تبدیل شود: چه کسی، در چه موقعیتی، با چه ورودیای، چه کاری انجام میدهد و خروجی مورد انتظار چیست.
الگوی ساده و کاربردی این است: مسئله، بازیگر، محرک، جریان کار، استثناها و معیار پذیرش. این الگو نیازمندی را از سطح شعار به سطح تصمیم طراحی میرساند. راهنمای طراحی Oracle نیز توصیه میکند پیش از طراحی، فرایندهای فعلی، گزارشهای موجود، منابع داده و نیازهای برنامهریزی بررسی شوند.
- مسئله: چرا این نیاز مطرح شده است؟
- بازیگر: کدام نقش یا واحد با آن درگیر است؟
- محرک: چه رویدادی فرایند را شروع میکند؟
- جریان کار و استثناها: مسیر عادی و حالتهای خارج از روال چیست؟
- معیار پذیرش: از کجا میفهمیم راهکار درست کار میکند؟
ساختار پیشنهادی سند نیازمندی ERP
یک سند خوب لازم نیست طولانی و پیچیده باشد؛ باید کامل، منظم و قابل پیگیری باشد. برای بیشتر پروژههای ERP، این ساختار عملی است: هدف کسبوکار، دامنه، ذینفعان، فرایندهای مشمول، وضعیت موجود و مطلوب، نیازمندیهای عملکردی و غیرعملکردی، دادهها و یکپارچگی، مهاجرت داده، گزارشها، امنیت و سطوح دسترسی، معیارهای پذیرش، ریسکها و وابستگیها.
هر نیازمندی باید شناسه یکتا، منبع، اولویت و معیار آزمون داشته باشد. استانداردهای مهندسی نیازمندی و راهنمای IIBA بر شفافیت، قابلیت ردیابی و آزمونپذیری تأکید میکنند. اگر یک نیازمندی را نتوان به ذینفع، تصمیم طراحی یا تست مشخص وصل کرد، هنوز برای ورود به پروژه آماده نیست.
- هدف کسبوکار و مسئله اصلی
- دامنه درون و بیرون محدوده
- فرایندهای کلیدی و استثناها
- نیازمندیهای عملکردی و غیرعملکردی
- داده، گزارش، امنیت و یکپارچگی
- معیار پذیرش و سنجههای موفقیت
چطور مسئلههای واحدها را به نیازمندی قابلارزیابی تبدیل کنیم؟
بهترین نقطه شروع، جلسهای نیست که در آن از واحدها بپرسید «چه میخواهید؟». سؤال بهتر این است: «کدام تصمیم یا فرایند امروز کند، پرخطا یا غیرشفاف است؟» از دل این سؤال، مسئله واقعی بیرون میآید. سپس آن مسئله را به سناریوهای کوچکتر بشکنید؛ مثلاً در خرید: درخواست خرید، تأیید، سفارش، رسید انبار، تطبیق با فاکتور و پرداخت.
برای هر سناریو، حداقل این چهار چیز را بنویسید: ورودی، قانون کسبوکار، خروجی، و معیار پذیرش. اگر نیازمندی به عدد، شرط یا مرز روشن نرسد، هنوز برای طراحی مناسب نیست. در منابع مرجع، قابلیت ردیابی برای کنترل تغییر، مدیریت دامنه، ریسک و هزینه، یک ابزار کلیدی معرفی شده است. (مطابق منابع انتهای مقاله)
- نمونه ضعیف: «گزارش موجودی بهتر شود»
- نمونه بهتر: «مدیر انبار بتواند موجودی لحظهای هر کالا را بر اساس دفتر مرکزی، شعبه و دپارتمان ببیند»
- نمونه ضعیف: «فرایند خرید سریع شود»
- نمونه بهتر: «درخواست خرید بالاتر از سقف ریالی، قبل از ثبت سفارش، نیازمند تأیید مدیر مالی باشد»
خطاهای رایج در نوشتن سند نیازمندی ERP
اولین خطا، نوشتن نیازمندی در سطح راهحل است؛ مثلاً از همان ابتدا میگوییم «یک داشبورد لازم داریم» بدون اینکه بدانیم داشبورد چه مسئلهای را حل میکند. خطای دوم، خلطکردن خواسته با اولویت است؛ همهچیز نمیتواند «فوری» باشد. خطای سوم، نادیدهگرفتن نیازمندیهای غیرعملکردی مثل امنیت، کارایی، دسترسپذیری و نگهداشتپذیری است. خطای چهارم، فراموشکردن انتقال از وضعیت فعلی به وضعیت مطلوب، مثل تبدیل دادهها و آموزش.
IIBA نیازمندیها را به چهار دسته اصلی کسبوکاری، ذینفع، راهکار و انتقالی تقسیم میکند. این تقسیمبندی کمک میکند سند فقط روی «چه چیزی ساخته شود» نماند و به «چگونه از وضعیت فعلی عبور کنیم» هم پاسخ دهد. (مطابق منابع انتهای مقاله)
- راهحلنویسی زودهنگام
- ابهام در اولویتها
- بیتوجهی به نیازمندی غیرعملکردی
- نادیدهگرفتن مهاجرت داده و آموزش
- نبود ردیابی تا تست و پذیرش
قالب کوتاه و عملی برای یک نیازمندی ERP
اگر بخواهید هر نیازمندی را در سند ثبت کنید، این قالب کوتاه بیشترین کارایی را دارد: شناسه، عنوان، مسئله، ذینفع اصلی، شرح نیاز، قانون کسبوکار، دادههای درگیر، استثناها، معیار پذیرش، اولویت، و وابستگیها. این قالب باعث میشود هر نیازمندی هم برای تحلیل کسبوکار قابلفهم باشد و هم برای تیم فنی و QA قابلآزمون.
نمونه: «REQ-PO-01: تأیید خرید بر اساس سقف بودجه». مسئله: درخواستهای خرید بدون کنترل بودجه به سفارش تبدیل میشوند. ذینفع اصلی: مدیر مالی. معیار پذیرش: اگر مبلغ درخواست از سقف مصوب ماهانه بیشتر باشد، سیستم قبل از ثبت سفارش، مسیر تأیید اضافه فعال کند. این نوع نگارش، خواسته را از حد توضیح شفاهی به سناریوی قابلپیادهسازی میرساند. (مطابق منابع انتهای مقاله)
- شناسه یکتا
- شرح مسئله
- قانون کسبوکار
- معیار پذیرش
- اولویت و وابستگی
- مالک نیازمندی
پرسشهای متداول
سند نیازمندی ERP باید چند صفحه باشد؟
عدد ثابت مهم نیست؛ مهم این است که برای هر فرایند کلیدی، مسئله، سناریو، قاعده کسبوکار و معیار پذیرش روشن باشد.
آیا میشود نیازمندی را فقط با مصاحبه نوشت؟
مصاحبه نقطه شروع خوبی است، اما کافی نیست. بهتر است با مشاهده فرایند، بررسی فرمها، گزارشها و دادههای فعلی، سند را تکمیل کنید.
نیازمندی غیرعملکردی را کجا بنویسیم؟
در بخشی جداگانه یا کنار هر سناریو، با شاخصهای روشن مثل زمان پاسخ، سطح دسترسی، نگهداشتپذیری و امنیت.
تفاوت نیازمندی و راهکار چیست؟
نیازمندی میگوید چه مسئلهای باید حل شود؛ راهکار میگوید سیستم چگونه آن را حل خواهد کرد.