RFC در مدیریت خدمات فناوری اطلاعات معمولاً مخفف Request for Change یا «درخواست تغییر» است؛ رکوردی رسمی برای پیشنهاد، ارزیابی، تأیید، زمانبندی و پیگیری یک تغییر در سرویس یا زیرساخت IT. هدف RFC این نیست که فقط بگوید «چه چیزی تغییر کند». یک RFC خوب باید دلیل تغییر، دامنه، CIهای تحت تأثیر، ریسک، زمان اجرا، برنامه بازگشت و معیار موفقیت را روشن کند تا تصمیمگیری درباره تغییر بر اساس داده انجام شود. RFC معمولاً چه اطلاعاتی دارد؟ شرح و دلیل تغییر سرویسها و Configuration Itemهای تحت تأثیر Impact، Risk و Urgency زمانبندی و Maintenance Window Plan اجرا، Test Plan و Rollback Plan مالک تغییر و تیمهای درگیر تأییدها و نتیجه نهایی تغییر RFC چه ارتباطی با CAB دارد؟ همه تغییرها الزاماً به جلسه CAB نیاز ندارند. نوع تغییر، ریسک و مدل Change Authority تعیین میکند چه سطحی از تأیید لازم است. برای تغییرهای مهم، اطلاعات RFC ورودی اصلی ارزیابی است. برای جزئیات بیشتر مقاله CAB چیست؟ را ببینید. RFC با Incident یا Service Request چه تفاوتی دارد؟ Incident برای بازگرداندن سرویس مختلشده است؛ Service Request برای دریافت یک خدمت از پیش تعریفشده؛ اما RFC برای ایجاد یک تغییر کنترلشده در محیط است. یک Incident ممکن است در نهایت به RFC منجر شود، اما این دو یک رکورد و یک هدف ندارند. در ابزارهایی مانند ServiceDesk Plus میتوان Change را به Incident، Problem، CI و Approval مرتبط کرد تا سابقه تصمیم و اثر تغییر قابل ردیابی باشد. سخن پایانی RFC یک فرم اداری نیست؛ نقطه شروع کنترل ریسک تغییر است. هرچه اطلاعات اثر، ریسک، بازگشت و معیار موفقیت دقیقتر باشد، احتمال اجرای تغییر بدون اختلال بیشتر میشود.