ساعت ۲۲:۳۰ است و تیم امنیت اعلام میکند یک آسیبپذیری جدی باید پیش از شروع شیفت صبح Patch شود. همزمان تیم زیرساخت برای هفته آینده ارتقای Storage را برنامهریزی کرده و Help Desk نیز هر روز دهها تغییر تکراری مثل افزودن Rule مشخص، افزایش فضای یک Volume یا نصب بسته استاندارد را اجرا میکند.
اگر سازمان برای هر سه سناریو یک مسیر تأیید یکسان داشته باشد، یا سرعت عملیات قربانی Bureaucracy میشود یا کنترل ریسک از بین میرود. سؤال کلیدی این است: کدام تغییر واقعاً باید به CAB برود و کدام تغییر میتواند از مسیر استاندارد یا اضطراری عبور کند؟
در Change Enablement هدف این نیست که برای هر تغییر جلسه برگزار شود؛ هدف این است که تعداد تغییرات موفق افزایش پیدا کند، ریسک بهدرستی ارزیابی شود، اختیار تأیید متناسب با ریسک باشد و زمانبندی تغییرها کنترل شود. همین منطق در تعریف فعلی PeopleCert از Change Enablement هم دیده میشود.
سه نوع اصلی تغییر را اول از هم جدا کنیم
در بسیاری از پیادهسازیهای ITSM، تغییرها به سه گروه اصلی Standard، Normal و Emergency تقسیم میشوند. تفاوت اصلی آنها فقط «فوریت» نیست؛ سطح ریسک، میزان تکرارپذیری، کیفیت مستندات، نیاز به ارزیابی و نوع Change Authority نیز متفاوت است.
| نوع تغییر | ویژگی اصلی | نیاز معمول به CAB | نمونه |
|---|---|---|---|
| Standard Change | کمریسک، تکراری، مستند و از قبل تأییدشده | معمولاً خیر | اجرای یک Patch استاندارد روی گروه مشخصی از Endpointها با Runbook ثابت |
| Normal Change | نیازمند ارزیابی ریسک، برنامه، زمانبندی و Authorization | بسته به ریسک؛ برای تغییرهای مهم معمولاً بله | مهاجرت سرویس از یک Server به Cluster جدید |
| Emergency Change | فوری، دارای فشار زمانی و معمولاً برای رفع Incident یا Risk جدی | معمولاً مسیر سریع eCAB یا Authority اضطراری | Patch فوری یک آسیبپذیری بحرانی یا اصلاح Configuration بعد از Outage |
راهنمای رسمی ManageEngine نیز Standard Change را تغییر کمریسک و Pre-approved، Normal Change را تغییری نیازمند فرآیند کامل ارزیابی و تأیید، و Emergency Change را تغییری با فوریت و اثر بالا تعریف میکند.
Standard Change یعنی «کمریسک و تکرارپذیر»، نه «بیاهمیت»
یک اشتباه رایج این است که Standard Change را با تغییر کوچک یکی بدانیم. ممکن است یک تغییر از نظر فنی روی تعداد زیادی سیستم اجرا شود، اما اگر فرآیند آن بارها با موفقیت تکرار شده، ریسک شناختهشده دارد، Rollback مشخص است و از قبل Authorization گرفته، میتواند Standard شود.
ویژگیهای یک Standard Change سالم معمولاً شامل این موارد است:
- Scope دقیق و از قبل تعریفشده است.
- مراحل اجرا Runbook یا Template ثابت دارند.
- Prerequisite و Validation مشخص است.
- ریسک و Impact در اولین طراحی ارزیابی شدهاند.
- Backout یا Recovery Plan روشن است.
- Owner و گروه اجرا معلوماند.
- در صورت تغییر شرایط، مسیر Standard متوقف و Change دوباره ارزیابی میشود.
برای مثال، تعویض یک Printer با مدل کاملاً مشابه یا اجرای یک Patch ماهانه روی گروهی از Serverها میتواند Standard باشد؛ اما اگر Scope، نسخه، Dependency یا روش اجرا عوض شود، دیگر نباید صرفاً به خاطر نام قدیمی Template همان مسیر Pre-approved را ادامه داد.
چه زمانی CAB برای Standard Change لازم نیست؟
اگر CAB هر بار Standard Change را دوباره Review کند، عملاً مزیت Standardization از بین میرود. CAB باید هنگام طراحی یا بازنگری مدل Standard Change درباره Risk، Control، Eligibility و Exception تصمیم بگیرد؛ نه اینکه برای هر اجرای تکراری دوباره همان تصمیم را تکرار کند.
یک مدل اجرایی بهتر این است:
- تغییر ابتدا بهعنوان Normal Change چند بار با موفقیت اجرا شود.
- داده واقعی Failure، Rollback، مدت اجرا و Incident پس از تغییر جمع شود.
- اگر Pattern پایدار و کمریسک شد، Runbook رسمی ساخته شود.
- Change Authority مدل را Pre-approve کند.
- اجرای بعدی با Template و Workflow مشخص انجام شود.
- هر Deviation مهم باعث خروج از مسیر Standard شود.
این رویکرد هم Governance را حفظ میکند و هم Change Queue را از کارهای تکراری خالی نگه میدارد.
Normal Change؛ جایی که Context تعیین میکند CAB لازم است یا نه
Normal Change یک گروه بسیار گسترده است. همه Normal Changeها نیاز ندارند در جلسه کامل CAB بررسی شوند. اختیار تأیید باید براساس Risk، Impact، Complexity و Business Criticality طراحی شود.
مثلاً این دو تغییر هر دو Normal هستند:
- افزایش RAM یک Server غیرحیاتی در محیط Test.
- مهاجرت Database اصلی سامانه مالی به نسخه جدید.
قرار دادن هر دو در یک Approval Path منطقی نیست. تغییر اول ممکن است با Change Manager و Technical Owner قابل تأیید باشد؛ تغییر دوم احتمالاً به CAB، Business Owner، Security، DBA و Service Owner نیاز دارد.
پنج سؤال برای تصمیم اینکه Normal Change به CAB برود یا نه
| سؤال | اگر پاسخ «بله» است |
|---|---|
| آیا تغییر چند سرویس یا Business Unit را تحت تأثیر میگذارد؟ | احتمال نیاز به CAB بیشتر میشود. |
| آیا Rollback دشوار، طولانی یا همراه با Data Risk است؟ | Review چندتخصصی ارزش بیشتری دارد. |
| آیا Dependencyها بین Network، Application، Database و Security پیچیدهاند؟ | CAB یا Review تخصصی پیشنهاد میشود. |
| آیا Failure میتواند SLA، درآمد، Compliance یا امنیت را تحت تأثیر قرار دهد؟ | Change Authority باید سطح بالاتری داشته باشد. |
| آیا این تغییر قبلاً شکست خورده یا Incident ایجاد کرده است؟ | ریسک باید دوباره محاسبه و مسیر Approval تشدید شود. |
در این نقطه CMDB ارزش عملی پیدا میکند. اگر تیم قبل از Approval بداند Source CI به چه Application، Database و Business Serviceهایی وابسته است، تصمیم CAB از «حدس کارشناسی» به ارزیابی مبتنی بر Context نزدیک میشود. در مقاله CI Impact Analysis در ServiceDesk Plus این موضوع را از زاویه Blast Radius و Relationship Map بررسی کردهایم.
CAB دقیقاً چه کاری باید انجام دهد؟
CAB نباید به جلسهای تبدیل شود که در آن ده نفر فقط Change List را مرور و دکمه Approve را تکرار میکنند. ارزش CAB زمانی ایجاد میشود که تصمیم به دید چندتخصصی نیاز دارد.
CAB مؤثر باید بتواند درباره این موارد تصمیم بگیرد:
- Business Impact و Service Impact
- Technical Risk و Dependency
- زمان مناسب اجرا و احتمال Collision با Changeهای دیگر
- Testing Evidence
- Rollout و Backout Plan
- Security و Compliance Impact
- Resource Availability
- Communication Plan
- Success Criteria و Post Implementation Review
بنابراین «عضو ثابت بیشتر» الزاماً به معنی CAB بهتر نیست. برای Change شبکه ممکن است Network، Security و Service Owner مهم باشند؛ برای تغییر ERP حضور Application Owner، DBA، Business Owner و Infrastructure ضروریتر باشد.
Emergency Change؛ سرعت بالا بدون حذف کنترل
Emergency Change زمانی مطرح میشود که تأخیر خودش ریسک بزرگتری ایجاد میکند؛ برای مثال یک Zero-day فعال، اختلال بحرانی سرویس، Failure مرکز داده یا نیاز فوری به اصلاح Configuration.
اما Emergency به معنی «بدون Approval» نیست. در الگوی درست، فرآیند کوتاه میشود ولی Controls اصلی حذف نمیشوند. معمولاً یک Emergency Change Authority یا eCAB کوچک با دسترسی سریع تصمیم میگیرد.
حداقل اطلاعاتی که حتی در Emergency Change باید ثبت شوند:
- دلیل اضطرار و Consequence عدم اجرا
- Scope دقیق
- Risk اصلی
- Owner تصمیم
- Implementation Plan فشرده
- Backout Plan یا Recovery Option
- زمان شروع و پایان
- Evidence و Outcome
- Post Implementation Review پس از تثبیت وضعیت
راهنمای ManageEngine برای Emergency Change نیز بر ارزیابی سریع، Approval تسریعشده و استفاده از eCAB تأکید دارد؛ یعنی سرعت بالا جای Accountability را نمیگیرد.
Emergency Change را به مسیر دور زدن Governance تبدیل نکنید
اگر درصد زیادی از Changeها با برچسب Emergency ثبت میشوند، معمولاً یکی از این مشکلات وجود دارد:
- Planning ضعیف است.
- Change Calendar درست استفاده نمیشود.
- Standard Changeهای پرتکرار تعریف نشدهاند.
- Approval Normal Change بیش از حد کند است.
- تیمها Change را دیر ثبت میکنند.
- فرهنگ سازمانی Emergency را مسیر سریعتر میداند.
یکی از KPIهای ارزشمند، نسبت Emergency Change به کل Changeها و همچنین Success Rate آنهاست. افزایش پیوسته Emergency Change باید Trigger بررسی فرآیند باشد.
eCAB چه فرقی با CAB دارد؟
eCAB یا Emergency Change Advisory Board نسخه کوچکتر و سریعتر Change Authority برای شرایط اضطراری است. ترکیب آن باید از قبل مشخص باشد؛ نه اینکه هنگام Incident تازه دنبال افراد تصمیمگیر بگردیم.
| موضوع | CAB | eCAB |
|---|---|---|
| کاربرد | Normal/Major Changeهای نیازمند Review | Emergency Change |
| زمان تصمیم | برنامهریزیشده | سریع و Incident-driven |
| اعضا | برحسب Scope؛ معمولاً گستردهتر | حداقلی اما دارای Authority کافی |
| مستندات | کامل پیش از اجرا | حداقل ضروری پیش از اجرا + تکمیل پس از اجرا |
| هدف | کاهش ریسک و هماهنگی | بازگرداندن/حفاظت سرویس با کنترل ریسک زمانی |
Change Calendar؛ ابزاری که بسیاری از CABها کمتر از آن استفاده میکنند
بخش مهمی از Failureها نه به خاطر اجرای بد، بلکه به خاطر Collision میان تغییرها رخ میدهد. اگر تیم Network یک Firewall Rule را تغییر دهد، تیم Application همزمان Release انجام دهد و DBA نیز Maintenance Database داشته باشد، Root Cause شکست بعدی مبهم میشود.
Change Calendar باید حداقل این موارد را برای تصمیمگیران روشن کند:
- Changeهای همزمان
- Maintenance Windowها
- Blackout Periodها
- Business Peakها
- Releaseهای مهم
- Dependencyهای مشترک
در ServiceDesk Plus میتوان Change Type، Template، Workflow، CAB، Approval، Rollout/Backout Plan و Change Calendar را در یک جریان واحد مدیریت کرد تا تصمیمگیری از Email و فایل پراکنده خارج شود.
چطور Approval Matrix بسازیم؟
بهجای یک قانون ساده مثل «همه Changeها باید CAB داشته باشند»، یک Approval Matrix براساس Risk طراحی کنید.
| Risk / Impact | نمونه Authority | مسیر |
|---|---|---|
| Low + تکراری | Pre-approved Standard Model | Standard Workflow |
| Low/Medium + محدود | Change Manager + Technical Owner | Normal سبک |
| Medium/High + چندسرویسی | CAB | Normal کامل |
| High + Business Critical | CAB + Business/Executive Authority | Major Change |
| Emergency | eCAB / Emergency Authority | Emergency Workflow |
این Matrix باید با Criticality سرویسها، Compliance و Risk Appetite سازمان هماهنگ شود. هیچ جدول عمومی نمیتواند بدون بومیسازی جای Governance واقعی را بگیرد.
چه زمانی یک Normal Change را Standard کنیم؟
Standardization یکی از Quick Winهای مهم Change Enablement است، اما فقط وقتی داده کافی داریم. معیارهای پیشنهادی برای Candidate شدن:
- حداقل چند اجرای موفق با Scope مشابه
- Failure Rate پایین
- Procedure ثابت و قابل Automation
- زمان اجرای قابل پیشبینی
- Dependency محدود و شناختهشده
- Backout قابل اتکا
- عدم نیاز به تصمیم Business در هر اجرا
اگر این معیارها برقرار باشند، CAB میتواند بهجای Review تکتک اجراها، خود مدل Standard Change را تأیید کند.
چه KPIهایی نشان میدهند Change Enablement درست کار میکند؟
| KPI | برداشت مدیریتی |
|---|---|
| Change Success Rate | چه درصدی بدون Incident، Rollback یا Degradation موفق بودهاند؟ |
| Failed Change Rate | کدام نوع Change بیشترین Failure را دارد؟ |
| Emergency Change Ratio | آیا سازمان بیش از حد Reactive شده است؟ |
| Standard Change Adoption | چند Change تکراری به مسیر استاندارد منتقل شدهاند؟ |
| Average Approval Time | Governance کجا تبدیل به Bottleneck شده است؟ |
| Change-related Incidents | چه میزان Incident مستقیماً پس از Change رخ داده است؟ |
| Backout Rate | کدام Changeها نیاز به بازگشت دارند؟ |
| Unauthorized Change Count | آیا تیمها بیرون از فرآیند رسمی تغییر میدهند؟ |
ServiceDesk Plus چطور این مدل را عملیاتی میکند؟
ServiceDesk Plus امکان ساخت Change Template و Workflowهای جداگانه برای Standard، Emergency و سایر Change Typeها را فراهم میکند. در Workflow میتوان Approval، Notification، Timer، Field Update، Script و API Action تعریف کرد و CAB یا Change Role مناسب را به مراحل مرتبط کرد.
برای سازمانی که هنوز Change را با Email، Excel و پیامرسان مدیریت میکند، مهمترین مزیت این نیست که «فرم بیشتری» داشته باشد؛ مزیت اصلی ایجاد Traceability است: چه کسی درخواست داد، Risk چه بود، چه کسی تأیید کرد، چه CIهایی تحت تأثیر بودند، چه زمانی اجرا شد و نتیجه چه شد.
اگر هدف شما طراحی فرآیند کامل مدیریت تغییر است، محتوای تخصصی CAB در ServiceDesk Plus فارسی و مجموعه راهنماهای ServiceDeskPlus.ir میتوانند برای تکمیل مدل Governance و آموزش تیم استفاده شوند.
یک سناریوی نمونه برای سازمان ۵۰۰ نفره
فرض کنید سازمان سه گروه تغییر دارد:
- Patch ماهانه Endpointها
- ارتقای Applicationهای سازمانی
- رفع اضطراری Vulnerability بحرانی
مدل مناسب میتواند این باشد:
Patch ماهانه: پس از چند اجرای موفق و Pilot، به Standard Change تبدیل شود؛ Approval تکراری حذف شود و فقط Exceptionها به Normal برگردند.
Application Upgrade: Normal Change با Risk Assessment، CI Impact Analysis، UAT، Rollback Plan و CAB متناسب با سرویس.
Critical Vulnerability: Emergency Change با eCAB، محدوده سریع، Validation امنیتی و PIR اجباری پس از اجرا.
در این مدل CAB کوچکتر نشده است؛ هدفمندتر شده است.
نکات کلیدی برای جلوگیری از CAB Bottleneck
- هر Change را به CAB نفرستید.
- Standard Changeها را Pre-approved و Template-driven کنید.
- Approval Level را Risk-based طراحی کنید.
- برای Emergency مسیر eCAB از قبل مشخص داشته باشید.
- Change Calendar را برای Collision Detection جدی بگیرید.
- از CMDB برای Impact Analysis استفاده کنید.
- تغییرهای پرتکرار را Candidate استانداردسازی کنید.
- Failure و Emergency Ratio را ماهانه Review کنید.
- Post Implementation Review را فقط برای Changeهای شکستخورده نگه ندارید؛ برای Changeهای پرریسک موفق هم درسآموخته ثبت کنید.
سخن پایانی
سؤال درست این نیست که «آیا CAB لازم است یا نه؟»؛ سؤال درست این است که برای این سطح از ریسک، چه Change Authority و چه مقدار Governance لازم است؟
Standard Change باید سرعت بدهد، Normal Change باید متناسب با Risk کنترل شود و Emergency Change باید بدون حذف Accountability مسیر سریع داشته باشد. وقتی همه Changeها وارد یک Approval Path میشوند، یا عملیات کند میشود یا تیمها فرآیند را دور میزنند.
اگر میخواهید Change Enablement را در ServiceDesk Plus با Template، Workflow، CAB/eCAB، CMDB، Change Calendar و Approval Matrix متناسب با ساختار سازمان خود طراحی کنید، مدانت خدمات پیادهسازی و سفارشیسازی ServiceDesk Plus، استعلام لایسنس ManageEngine و آموزش تخصصی را ارائه میکند.
منابع
- PeopleCert – ITIL Change Enablement
- PeopleCert Community – Change Enablement and change types
- ManageEngine – Standard vs Normal vs Emergency Change
- ManageEngine – Emergency Change Process
- ManageEngine ServiceDesk Plus – Change Management Software
