برای مدیریت درخواست تغییر در پروژه، پیشنهاد جدید را به نسخهٔ مصوب دامنه متصل کنید، اثر آن را بسنجید و تصمیمِ صاحب اختیار را پیش از اجرا ثبت کنید. سپس برنامه و معیار پذیرش را مطابق تصمیم به‌روز کنید. پیام «این مورد را هم اضافه کنید» تا زمانی که اثر و مجوز آن روشن نشده، مبنای کافی برای تعهد جدید تیم نیست.
این راهنما برای پروژه‌های خدمات فناوری اطلاعات، استقرار ERP و یکپارچه‌سازی سامانه‌ها نوشته شده است. خروجی آن یک فرم کوتاه و گردش تصمیم قابل‌استفاده است. ترتیب کار، نقش‌ها و کنترل‌های پیشنهادی زیر، الگوی تحریریه‌اند و باید با اختیارهای واقعی سازمان تطبیق داده شوند؛ مثال پایانی نیز سناریوی آموزشی است.
۱. چه چیزی درخواست تغییر محسوب می‌شود؟
ابتدا «خط مبنا» را مشخص کنید: نسخهٔ مورد توافقِ خروجی‌ها، محدودیت‌ها و معیار پذیرش که کار بر اساس آن برنامه‌ریزی شده است. تغییر دامنه ممکن است افزودن قابلیت، حذف یک خروجی یا عوض‌شدن شرط پذیرش باشد. برای مثال، درخواست پشتیبانی از انبار دوم در اتصالی که فقط برای یک انبار طراحی شده، نیازمند بررسی اثر است؛ حتی اگر کاربر آن را تغییر کوچکی بداند.
انجمن مدیریت پروژهٔ APM، کنترل تغییر را ثبت، ارزیابی و تصمیم دربارهٔ تغییر خط مبنای مصوب تعریف می‌کند. آن را از مدیریت گسترده‌تر تغییر سازمانی جدا بدانید؛ آموزش و پذیرش کاربران، موضوعی وسیع‌تر از تعیین تکلیف یک درخواست پروژه است.
| نوع مورد | پرسش تشخیص | اقدام پیشنهادی |
|---|---|---|
| نقص خروجی | آیا نتیجه با معیار مصوب مغایرت دارد؟ | ثبت نقص و پیگیری رفع طبق تعهد موجود |
| ابهام | آیا دو تفسیر از توافق فعلی وجود دارد؟ | تعیین تفسیر معتبر و ثبت مرجع تصمیم |
| تغییر | آیا خروجی یا شرط مصوب عوض می‌شود؟ | ثبت درخواست و ارزیابی اثر پیش از تعهد |
این جدول ابزار گفت‌وگوست؛ اگر مرز نقص و تغییر روشن نیست، مالک پروژه باید به سند مرجع مراجعه کند و نظر تصمیم‌گیر مجاز را بگیرد. دسته‌بندی یک‌طرفهٔ هر اشکال به‌عنوان «کار اضافه» اختلاف را حل نمی‌کند. در راهنمای تحویل سفارش از فروش به اجرا، بستهٔ شروع کار توضیح داده شده است؛ اینجا موضوع، تصمیم دربارهٔ درخواست‌های بعد از تثبیت آن مبناست.
۲. یک فرم کوتاه اما قابل تصمیم بسازید
برای هر درخواست، شناسهٔ یکتا و پیوند به پروژه داشته باشید. متن پیام اولیه را به توصیف قابل بررسی تبدیل کنید: چه چیزی باید تغییر کند، چرا لازم است و کدام نسخهٔ فعلی را تحت تأثیر قرار می‌دهد؟ اگر درخواست از جلسه یا پیام‌رسان آمده، خلاصهٔ توافق را در پروندهٔ مرجع ثبت کنید تا تصمیم به جست‌وجوی پیام‌های پراکنده وابسته نماند.
فرم اولیه می‌تواند این اجزا را داشته باشد: درخواست‌کننده، تاریخ، شرح وضع فعلی، خروجی پیشنهادی، دلیل، فوریت و پیامد انجام‌نشدن. بخش ارزیابی را جدا نگه دارید: مسئول بررسی، فرض‌های برآورد، وابستگی‌ها و گزینه‌های اجرا. بخش تصمیم نیز باید نتیجه، تصمیم‌گیر، زمان، شروط و نسخهٔ مستندات مربوط را نگه دارد.
درخواست‌کننده معمولاً مسئله و ارزش مورد انتظار را توضیح می‌دهد؛ مسئول فنی اثر را برآورد می‌کند و مالک پروژه هماهنگی را بر عهده دارد. این نقش‌ها لزوماً اختیار تصویب یکسان ندارند. برای درخواست ناقص، فهرست اطلاعات لازم و مسئول تکمیل را بنویسید؛ «نیازمند بررسی» بدون اقدام بعدی، فقط نام تازه‌ای برای انتظار است.
۳. اثر را روی کل تعهد بسنجید
ارزیابی را به مدت برنامه‌نویسی محدود نکنید. بررسی کنید چه آزمون، آموزش، مستند، دسترسی یا هماهنگی بیرونی باید تغییر کند. افزودن یک فیلد ممکن است ساده به نظر برسد، اما اگر در خروجی اتصال و گزارش مصرف شود، چند نقطهٔ وابسته دارد. موارد نامعلوم را به‌صورت فرض ثبت کنید و روشن کنید کدام ابهام مانع تصمیم قطعی است.
برای هر درخواست، چند گزینهٔ قابل مقایسه تهیه کنید: اجرای کامل، اجرای محدود، جابه‌جایی با بخشی از دامنه یا تعویق. برای هر گزینه بنویسید چه چیزی تحویل می‌شود و چه چیزی به بررسی بعدی می‌رود. برآورد باید مرجع، تاریخ و حدود اعتبار داشته باشد؛ عددی که پیش از دریافت مشخصات داده شده، تعهد قطعی زمان تحویل محسوب نشود.
در راهنمای ارزیابی درخواست تغییر Microsoft نیز اختیار تصمیم به نوع و اثر تغییر وابسته است. پیشنهاد عملی این مقاله آن است که اثر بر دامنه، زمان، منابع، هزینه، کیفیت و ریسک را کنار هم بنویسید. اگر درخواست دیگری هنوز تصویب نشده، وابستگی به آن را صریح کنید تا دو تصمیم ناهماهنگ، یک برنامهٔ ناممکن نسازند.
۴. اختیار تصویب و نتیجهٔ تصمیم را روشن کنید
پیش از ورود درخواست‌ها، مرز اختیار را مشخص کنید: چه تصمیمی در اختیار مدیر پروژه است و کدام تغییر باید به حامی پروژه یا مرجع بالاتر ارجاع شود؟ معیار را با سازمان توافق کنید؛ این مقاله مبلغ یا مدت ثابتی را برای همهٔ پروژه‌ها پیشنهاد نمی‌کند. تغییر کم‌زحمت هم ممکن است به‌دلیل اثر بر دسترسی یا تعهد تحویل، به اختیار دیگری نیاز داشته باشد.
| نتیجه | مدرک لازم در پرونده | گام بعد |
|---|---|---|
| تصویب | گزینهٔ پذیرفته‌شده، مرجع اختیار و شروط | به‌روزرسانی برنامه و تخصیص اجرا |
| رد | دلیل و مرجع تصمیم | اطلاع به درخواست‌کننده و حفظ سابقه |
| تعویق | علت، شرط بازگشایی و موعد بازبینی | پیگیری در همان پرونده |
«اطلاعات کافی نیست» مرحلهٔ تکمیل پرونده است؛ آن را با تصویب مشروط اشتباه نگیرید. در تصویب مشروط، شرط شروع و مسئول احراز آن معلوم باشد. موافقت برای بررسی فنی نیز مجوز اجرای تغییر در محیط عملیاتی نیست. اگر فوریت واقعی وجود دارد، مسیر اضطراری ازپیش‌تعریف‌شده با صاحب اختیار و ثبت شواهد به‌کار رود؛ فوریت نباید تصمیم را بی‌ردپا کند.
۵. تصمیم را تا اجرای پذیرفته‌شده دنبال کنید
پس از تصویب، نسخهٔ تازهٔ برنامه و معیار پذیرش را به درخواست پیوند دهید و نسخهٔ قبلی را نگه دارید. مسئول اجرا باید بداند کدام خروجی مجاز است، چه پیش‌نیازی دارد و پایان کار با چه شاهدی تأیید می‌شود. اگر تصمیم زمان تحویل را تغییر می‌دهد، افراد متأثر باید از همان نسخهٔ جدید مطلع شوند.
برای تغییر فنی، محیط آزمون، بازهٔ اجرا و روش بازگشت متناسب با ریسک را مشخص کنید. پس از اجرا، شاهد آزمون و پذیرنده را ثبت کنید و سپس درخواست را ببندید. اتمام کار فنی، پذیرش خروجی و بستن پرونده را رویدادهای جدا ببینید. اگر آزمون ناموفق بود، نتیجه و اقدام بعدی در همان زنجیرهٔ تصمیم بماند؛ سابقه را با ویرایش توضیح اولیه پاک نکنید.
۶. مثال آموزشی: اضافه‌شدن انبار دوم به یک اتصال
فرض کنید پروژه‌ای برای اتصال سفارش‌های یک فروشگاه به ERP با یک انبار مصوب شده است. در میانهٔ کار، درخواست می‌شود انبار دوم هم پوشش داده شود. این سناریو ساختگی است و نتیجهٔ پروژهٔ واقعی آسیاپرداز را گزارش نمی‌کند. درخواست باید روشن کند منظور، نمایش موجودی تجمیعی است یا انتخاب انبار برای هر سفارش؛ این دو خروجی، آزمون پذیرش یکسان ندارند.
مسئول فنی، اثر احتمالی بر نگاشت انبار، سطح دسترسی، سفارش ناقص و جلوگیری از پردازش تکراری را بررسی می‌کند. مالک پروژه گزینهٔ اجرای جداگانه در مرحلهٔ بعد را هم کنار اجرای هم‌زمان می‌گذارد. تصمیم‌گیر می‌تواند یک گزینه را با معیار پذیرش روشن تصویب کند؛ مثلاً رفتار سفارش هنگام نبود موجودی در انبار منتخب باید پیش از اجرا تعیین شود.
اگر برای تعیین رفتار، نمونهٔ داده یا تصمیم بهره‌بردار لازم باشد، درخواست تا دریافت آن کامل نیست. به‌روزرسانی وظیفه‌ها پس از تصمیم انجام می‌شود و هر وظیفه به همان درخواست ارجاع می‌دهد. این روش قرار نیست از پیش ثابت کند تغییر مفید یا زیان‌آور است؛ اطلاعات لازم برای تصمیم و پیگیری نتیجه را فراهم می‌کند.
۷. در Odoo 19 چگونه پرونده را قابل پیگیری کنیم؟
طبق مستند ایجاد وظیفه در Odoo 19، وظیفه می‌تواند عنوان، مسئول، برچسب و موعد داشته باشد. برای یک پایلوت می‌توان درخواست را به وظیفهٔ مشخص پروژه متصل کرد و پیوند مستند ارزیابی و تصمیم را در پرونده نگه داشت. انتخاب وظیفه به‌عنوان ظرف پیگیری، پیشنهاد اجرایی است؛ کنترل اجباری تصویب باید جداگانه طراحی و بررسی شود.
وضعیت Changes Requested با پروندهٔ تغییر پروژه فرق دارد
در راهنمای مراحل و وضعیت‌های Odoo 19، ستون‌های کانبان قابل تنظیم‌اند، اما وضعیت‌های وظیفه مفهوم جداگانه دارند. وضعیت‌های Changes Requested و Approved با انتقال وظیفه به مرحلهٔ دیگر پاک می‌شوند و وضعیت به In Progress برمی‌گردد. بنابراین این علامت‌ها را سابقهٔ پایدارِ تصویب دامنه فرض نکنید.
اگر سازمان به محدودکردن تصویب به نقش معین، نگهداری نسخهٔ تصمیم یا جلوگیری از اجرا پیش از تأیید نیاز دارد، آن سناریو را در محیط آزمایش نصب خود بررسی کند. تغییر نام ستون به «مصوب» به‌تنهایی این کنترل‌ها را ایجاد نمی‌کند. این راهنما وجود گردش آمادهٔ کنترل تغییر، امکانات یکسان همهٔ نسخه‌ها یا پیکربندی خاصی در سیستم شما را فرض نمی‌کند.
۸. پایلوت را با پرونده‌های واقعیِ بی‌ابهام شروع کنید
خطاهای رایج عبارت‌اند از ثبت درخواست پس از انجام کار، جایگزین‌کردن پیام شفاهی با مدرک تصمیم و بستن موردِ معوق بدون موعد بازبینی. برای پایلوت، یک پروژه و مسیر تصمیم مشخص انتخاب کنید. سه حالت تصویب، رد و نیاز به اطلاعات بیشتر را مرور کنید و ببینید آیا نفر بعدی می‌تواند فقط با خواندن پرونده، مبنای اقدام را بفهمد.
کنترل تغییر زمانی قابل اتکاست که درخواست به خط مبنا، تصمیم به صاحب اختیار و اجرا به شاهد پذیرش متصل باشد. برای تطبیق این مسیر با پروژه‌ها و نصب Odoo سازمان خود، می‌توانید از خدمات مشاورهٔ آسیاپرداز برای تعیین دامنهٔ پایلوت استفاده کنید.
محدودهٔ اعتبار: منابع رسمی پیوندشده و مستندات نسخهٔ ۱۹ Odoo در ۷ نوامبر ۲۰۲۶ بررسی شدند. فرم، تفکیک نقش‌ها، کنترل‌های اجرایی و مثال، پیشنهاد تحریریه‌اند؛ آزمون تولید، آمار بهبود یا نتیجهٔ مشتری به آن‌ها نسبت داده نشده است.