سازمانی اعلام میکند فرآیند مدیریت تغییر آن «بلوغ سطح ۴» دارد، اما وقتی از تیم میخواهید Evidence نشان دهد، فقط چند فرم، یک دستورالعمل قدیمی و گزارشهای پراکنده ارائه میشود. مشکل از خود COBIT نیست؛ مشکل از این تصور است که Capability Level یک برچسب مدیریتی است، نه نتیجه ارزیابی شواهد واقعی.
COBIT Performance Management یا CPM در COBIT 2019 چارچوبی برای ارزیابی عملکرد اجزای نظام حاکمیت و مدیریت فراهم میکند. در ارزیابی Process Capability، سطحها از ۰ تا ۵ تعریف میشوند و هر سطح انتظار مشخصی از فعالیتها و عملکرد فرآیند دارد.
این مقاله توضیح میدهد چگونه Capability Level در COBIT 2019 را بهصورت عملی ارزیابی کنیم، چه تفاوتی با Maturity دارد، چه Evidenceهایی نیاز داریم و چگونه از امتیازدهی صوری جلوگیری کنیم.
Capability و Maturity یکی نیستند
در COBIT 2019، Capability معمولاً به عملکرد یک Process مشخص اشاره دارد، در حالی که Maturity نگاه گستردهتری به یک Focus Area یا مجموعهای از اجزای نظام حاکمیت دارد. این دو را نباید بدون دقت جایگزین یکدیگر کرد.
| مفهوم | تمرکز | پرسش اصلی |
|---|---|---|
| Capability | یک Process | این فرآیند تا چه سطحی فعالیتهای مورد انتظار را اجرا میکند؟ |
| Maturity | Focus Area / Governance System | این حوزه تا چه حد به سطح بلوغ پایدار رسیده است؟ |
سطوح Capability از 0 تا 5 چه معنایی دارند؟
COBIT 2019 برای Process Capability شش سطح از ۰ تا ۵ در نظر میگیرد. تفسیر عملی آنها چنین است:
| سطح | برداشت عملی | نشانه سازمانی |
|---|---|---|
| 0 | فرآیند به هدف خود نمیرسد یا شواهد ناچیز است | فعالیتها پراکنده یا عملاً انجام نمیشوند |
| 1 | Process Purpose تا حدی محقق میشود | کار انجام میشود اما وابسته به افراد است |
| 2 | فعالیتهای پایه منظمتر و کاملتر اجرا میشوند | رویههای مشخص و خروجی قابل تکرار دیده میشود |
| 3 | فرآیند سازمانیافته و تعریفشده است | Role، روش و استاندارد سازمانی مشخص است |
| 4 | فرآیند کمی و قابل سنجش مدیریت میشود | Metric و کنترل Performance وجود دارد |
| 5 | فرآیند بهینه و بهبودمحور است | بهبود مستمر بر اساس داده انجام میشود |
این جدول یک ترجمه عملیاتی برای فهم بهتر است؛ ارزیابی واقعی باید بر اساس فعالیتها و معیارهای رسمی COBIT انجام شود.
چرا نمیتوان مستقیماً سطح 4 یا 5 داد؟
یکی از خطاهای رایج این است که مدیران از روی تجربه یا تصور کلی یک سطح بالا تعیین میکنند. Capability باید مرحلهای ارزیابی شود. اگر فعالیتهای سطح پایینتر بهاندازه کافی محقق نشده باشند، پرش به سطح بالاتر اعتبار ندارد.
برای مثال، فرآیندی که هنوز Roleهای آن مبهم است و اجرای آن وابسته به افراد است، نمیتواند صرفاً با داشتن Dashboard به سطح ۴ برسد.
Evidence در ارزیابی Capability چیست؟
Evidence فقط Policy نیست. باید نشان دهد فعالیت واقعاً اجرا شده و نتیجه تولید کرده است.
| نوع Evidence | نمونه |
|---|---|
| Policy/Procedure | روش مصوب مدیریت تغییر |
| Operational Record | Change Recordهای واقعی |
| Role Evidence | RACI و Assignment |
| Performance Evidence | KPI، SLA، Trend |
| Control Evidence | Approval، Review، Audit Trail |
| Improvement Evidence | Action Plan و نتایج اصلاحات |
یک مثال: ارزیابی Change Management
فرض کنید میخواهیم فرآیند تغییر را ارزیابی کنیم. صرف وجود فرم Change کافی نیست.
برای سطحهای پایینتر چه میبینیم؟
- Change ثبت میشود؛
- مالک مشخص دارد؛
- Approval انجام میشود؛
- نتیجه پیادهسازی ثبت میشود.
برای سطحهای بالاتر چه چیزی اضافه میشود؟
- Risk Model استاندارد؛
- Metric مثل Change Success Rate؛
- تحلیل Emergency Change؛
- Post Implementation Review؛
- Trend Analysis؛
- Improvement Backlog.
بنابراین Capability بالاتر به معنی «فرم بیشتر» نیست؛ به معنی کنترل، اندازهگیری و بهبود بهتر است.
Rating فعالیتها چگونه باید انجام شود؟
در ارزیابی رسمی COBIT باید میزان دستیابی به فعالیتها و Practiceهای مورد انتظار بر اساس شواهد تعیین شود. مهم است که Assessment Team از تعریفهای ثابت استفاده کند تا دو ارزیاب برای Evidence مشابه امتیاز کاملاً متفاوت ندهند.
برای کاهش Subjectivity:
- Criteria را قبل از مصاحبه تعریف کنید؛
- Evidence Required را مشخص کنید؛
- نمونهگیری انجام دهید؛
- مصاحبه را با سند تطبیق دهید؛
- Assessment Note نگه دارید؛
- Disagreement را ثبت و Review کنید.
مصاحبه بهتنهایی Evidence نیست
اگر Process Owner بگوید «همه Changeها CAB میروند»، باید نمونه Change Record و Approval Trail نیز وجود داشته باشد. ادعای شفاهی بدون Evidence عملی نباید مبنای Capability بالا قرار گیرد.
چه Processهایی را اول ارزیابی کنیم؟
لازم نیست همه Objectives را همزمان ارزیابی کنید. انتخاب Scope باید از Risk و Business Priority بیاید.
| سناریو | حوزه پیشنهادی |
|---|---|
| ریسک امنیتی بالا | Security، Risk، Access، Incident |
| اختلال زیاد سرویس | Availability، Incident، Problem، Change |
| هزینه IT نامشخص | Portfolio، Budget، Asset، Vendor |
| تحول دیجیتال | Architecture، Program، Change، Benefits |
برای تبدیل استراتژی به اولویتهای حاکمیتی، مقاله Goals Cascade در COBIT 2019 مسیر مناسبی ارائه میدهد.
Capability Target را چگونه تعیین کنیم؟
هدف همه Processها نباید Level 5 باشد. رسیدن به سطح بالا هزینه دارد و همیشه Value ایجاد نمیکند. Target باید با Criticality هماهنگ باشد.
مثلاً:
- فرآیند حیاتی امنیتی ممکن است Target بالاتری نیاز داشته باشد؛
- فرآیند کمریسک شاید در Level 2 یا 3 کاملاً کافی باشد؛
- سطح هدف باید با Risk Appetite و Business Need توجیه شود.
Gap Analysis؛ خروجی اصلی Assessment چیست؟
Assessment نباید فقط یک عدد تولید کند. خروجی ارزشمند، Gap بین وضعیت فعلی و Target است.
| فیلد | مثال |
|---|---|
| Current Level | 2 |
| Target Level | 3 |
| Gap | عدم استانداردسازی Role و Procedure |
| Action | تعریف RACI و Workflow رسمی |
| Owner | ITSM Manager |
| Due Date | سهماهه بعد |
از Dashboard سبز جعلی جلوگیری کنید
اگر تیم ارزیابی تحت فشار باشد که نتیجه «خوب» نشان دهد، Assessment ارزش خود را از دست میدهد. چند کنترل ساده:
- Evidence Sampling مستقل؛
- Cross Interview؛
- ثبت ضعفها بدون حذف مدیریتی؛
- تفکیک Current State و Target State؛
- عدم تبدیل Assessment به ابزار ارزیابی فردی کارکنان.
ارتباط CPM با 7 Component نظام حاکمیت
Process فقط یکی از Componentهای COBIT است. اگر Process خوب تعریف شده باشد اما Skills، Information، Culture یا Organizational Structure مناسب نباشد، عملکرد واقعی نظام حاکمیت محدود میشود.
مقاله ۷ Component نظام حاکمیت COBIT 2019 این بخش را کامل میکند.
KPIهای خود برنامه Assessment
| KPI | هدف |
|---|---|
| Evidence Coverage | کاهش ارزیابی مبتنی بر ادعا |
| Assessment Consistency | همگرایی نظر ارزیابان |
| Gap Closure Rate | پیگیری اقدام اصلاحی |
| Reassessment Improvement | سنجش پیشرفت واقعی |
| High-risk Gap Aging | جلوگیری از بازماندن ضعف حیاتی |
چکلیست ارزیابی Capability
- Scope را بر اساس Risk تعیین کنید.
- Process Owner را مشخص کنید.
- Evidence List بسازید.
- مصاحبه و Sample را ترکیب کنید.
- سطحها را مرحلهای ارزیابی کنید.
- Current و Target را جدا نگه دارید.
- Gap را به Action قابل اندازهگیری تبدیل کنید.
- Owner و Due Date تعیین کنید.
- Reassessment زمانبندی کنید.
نکات کلیدی
- Capability و Maturity یک مفهوم واحد نیستند.
- Level بالا بدون Evidence معتبر نیست.
- پرش از ضعفهای پایه به سطح ۴ یا ۵ معنی ندارد.
- Assessment باید Gap و Action تولید کند، نه فقط Score.
- Target Level باید بر اساس Risk و Value تعیین شود.
- Process تنها یکی از اجزای نظام حاکمیت COBIT است.
منابع
سخن پایانی
COBIT Performance Management زمانی مفید است که سازمان را مجبور کند بین «ادعا» و «شواهد» تفاوت بگذارد. Capability Level نه یک نشان افتخار است و نه هدفی که همه Processها باید تا ۵ بالا بروند؛ ابزاری است برای فهم وضعیت واقعی، تعیین سطح هدف و ساخت Roadmap بهبود.
مدانت خدمات مشاوره COBIT و حاکمیت فناوری اطلاعات، ارزیابی وضعیت موجود، طراحی Roadmap، آموزش و پیادهسازی GRC را ارائه میدهد. برای شروع برنامه ارزیابی میتوانید از طریق مشاوره مدانت درخواست بررسی Scope و Gap Assessment بدهید.
