فرض کنید کمیته راهبری فناوری اطلاعات از مدیر IT میپرسد: «بلوغ مدیریت تغییر ما چند است؟» پاسخ سریع معمولاً یک عدد است؛ مثلاً «سطح ۳ از ۵». اما چند سؤال بعدی همهچیز را دشوار میکند: این عدد از کجا آمده؟ چه شواهدی آن را پشتیبانی میکند؟ آیا سطح ۳ واقعاً برای این فرایند مناسب است؟ آیا باید همه فرایندها را به سطح ۵ برسانیم؟ و مهمتر از همه، آیا این امتیاز به تصمیم مدیریتی منجر میشود یا فقط یک عدد زیبا در گزارش است؟
COBIT 2019 Performance Management برای پاسخ به همین مسئله طراحی شده است. در COBIT، Capability Level فقط یک برچسب «بلوغ» نیست؛ روشی است برای سنجش اینکه یک فرایند تا چه اندازه واقعاً اجرا، تعریف، اندازهگیری و بهبود داده میشود. اگر این ارزیابی درست انجام شود، میتواند فاصله وضع موجود تا سطح هدف را به یک Roadmap قابل اجرا برای حاکمیت فناوری اطلاعات تبدیل کند.
در این راهنما، تفاوت Capability و Maturity را روشن میکنیم، سطوح ۰ تا ۵ را توضیح میدهیم، روش جمعآوری Evidence و Rating را بررسی میکنیم و نشان میدهیم چگونه بدون افتادن در دام «همهچیز باید سطح ۵ باشد»، یک ارزیابی عملی برای سازمان طراحی کنیم. برای آشنایی کلی با چارچوب نیز میتوانید صفحه COBIT در مدانت را ببینید.
Capability Level در COBIT 2019 دقیقاً چیست؟
ISACA در مدل COBIT 2019، Capability Level را معیاری برای سنجش میزان پیادهسازی و عملکرد یک Process میداند. این مدل از سطح ۰ تا ۵ حرکت میکند؛ از فرایندی که رویکرد منسجم و کامل ندارد تا فرایندی که تعریفشده، قابل اندازهگیری و در مسیر بهبود مستمر است.
نکته مهم این است که Capability Level درباره «خوب یا بد بودن واحد IT» حکم کلی صادر نمیکند. موضوع ارزیابی یک Process مشخص است. ممکن است مدیریت Incident در یک سازمان سطح ۴ باشد اما مدیریت Vendor در همان سازمان سطح ۲. این تفاوت نهتنها طبیعی است، بلکه در بسیاری از موارد مطلوب است؛ چون سطح هدف باید با اهمیت کسبوکاری، ریسک، الزام قانونی و هزینه کنترل متناسب باشد.
تفاوت Capability Level و Maturity Level؛ دو مفهوم مشابه اما یکسان نیستند
یکی از خطاهای رایج در پروژههای COBIT این است که Capability و Maturity بهجای هم استفاده میشوند. در COBIT 2019 این دو مفهوم Scope متفاوتی دارند.
| مفهوم | Scope اصلی | سؤال مدیریتی | نمونه |
|---|---|---|---|
| Capability Level | Process | این فرایند تا چه اندازه درست و پایدار اجرا میشود؟ | Capability فرایند Managed Risk |
| Maturity Level | Focus Area | مجموعه فرایندهای مرتبط با یک حوزه تا چه حد بالغاند؟ | Maturity حوزه امنیت اطلاعات |
ISACA توضیح میدهد که Capability برای Processها بهکار میرود، در حالی که Maturity برای بیان عملکرد در سطح Focus Area مناسبتر است. بنابراین اگر سازمان درباره «بلوغ امنیت سایبری» صحبت میکند، باید مراقب باشد یک امتیاز Process را به کل حوزه تعمیم ندهد.
سطوح ۰ تا ۵ Capability در COBIT 2019
مدل COBIT 2019 شش سطح از ۰ تا ۵ دارد. این سطوح را میتوان به زبان اجرایی چنین خواند:
| سطح | برداشت اجرایی | نشانه معمول در سازمان |
|---|---|---|
| Level 0 | فرایند ناقص یا فاقد Capability پایه | کارها موردی، پراکنده و بدون رویکرد قابل اتکا انجام میشوند |
| Level 1 | فرایند تا حدی Purpose خود را محقق میکند | کار انجام میشود، اما وابسته به افراد و تجربه شخصی است |
| Level 2 | مجموعه پایه و کامل فعالیتها انجام میشود | فرایند اجرا میشود و خروجی قابل تکرار دارد |
| Level 3 | فرایند سازمانیافته و تعریفشده است | Role، Procedure، Template و Asset سازمانی مشخص وجود دارد |
| Level 4 | عملکرد فرایند بهصورت کمی اندازهگیری میشود | KPI، Threshold، Trend و کنترل عملکرد وجود دارد |
| Level 5 | اندازهگیری برای بهبود مستمر استفاده میشود | فرایند فقط اندازهگیری نمیشود؛ بر اساس داده بهینه میشود |
این توصیف یک پیام مهم دارد: سطح بالاتر صرفاً «مستندات بیشتر» نیست. در Level 4، اندازهگیری کمی وارد مدل میشود و در Level 5، همان داده باید به Improvement واقعی منجر شود.
چرا «همه فرایندها باید Level 5 باشند» اشتباه است؟
Level 5 گران است. برای رسیدن به آن معمولاً به استانداردسازی، Data Collection، KPI، Automation، کنترل، Audit و چرخه بهبود نیاز داریم. اگر یک Process برای سازمان اهمیت متوسط دارد، رساندن آن به Level 5 ممکن است ارزش اقتصادی نداشته باشد.
COBIT 2019 بهجای نسخه واحد برای همه سازمانها، روی طراحی یک Governance System متناسب با Context تأکید میکند. Design Factorها، Enterprise Goalها، Risk Profile، Threat Landscape، Compliance Requirement و Role فناوری در کسبوکار میتوانند تعیین کنند که یک Objective به چه Target Capability نیاز دارد.
برای مثال ممکن است در یک بانک، APO13 Managed Security یا DSS05 Managed Security Services هدف Capability بالاتری بخواهد؛ اما همان سازمان برای یک Process کمریسکتر Level 2 یا 3 را کافی بداند. اصل درست این است:
Target Level باید با اهمیت و ریسک Process متناسب باشد، نه با میل سازمان به گرفتن امتیاز بالاتر.
رابطه Capability Level با Goals Cascade
ارزیابی Capability نباید از Strategy جدا باشد. اگر ابتدا Levelها را اندازه بگیریم ولی ندانیم کدام Objective برای کسبوکار مهمتر است، نتیجه به یک پروژه Assessment تبدیل میشود که خروجی عملی محدودی دارد.
مدل بهتر این است:
Stakeholder Need → Enterprise Goal → Alignment Goal → Governance/Management Objective → Target Capability → Improvement Initiative
یعنی ابتدا مشخص میکنیم چه Outcomeای برای کسبوکار مهم است، بعد Objectiveهای مرتبط را اولویت میدهیم و سپس برای Processهای زیر آنها سطح هدف تعریف میکنیم. برای جزئیات این زنجیره، مقاله Goals Cascade در COBIT 2019 را بخوانید.
چطور Target Capability Level تعیین کنیم؟
در یک پروژه واقعی، Target Level بهتر است از ترکیب چند عامل تعیین شود:
- Business Criticality: شکست این Process چه اثری روی درآمد، عملیات یا مشتری دارد؟
- Risk Exposure: ضعف فرایند چه ریسکهایی ایجاد میکند؟
- Regulatory Pressure: آیا قانون، Audit یا استاندارد سطح کنترل بالاتری میخواهد؟
- Cost of Control: هزینه رسیدن از Level 3 به 4 یا 5 چقدر است؟
- Dependency: آیا ضعف این Process، چند Objective مهم دیگر را هم محدود میکند؟
- Strategic Role of IT: فناوری پشتیبان کسبوکار است یا بخش اصلی Product و Revenue؟
ISACA در مثالهای Design Guide نشان میدهد Objectiveهای با اهمیت بالاتر میتوانند Target Capability بالاتری دریافت کنند. نکته کلیدی این است که Target باید حاصل Context و اولویت باشد، نه انتخاب تصادفی.
روش Rating در COBIT؛ Fully، Largely، Partially و Not
برای ارزیابی دقیقتر، Activityها میتوانند با چهار Rating بررسی شوند:
| Rating | درصد تحقق تقریبی | برداشت |
|---|---|---|
| Fully | بیش از 85% | سطح موردنظر تقریباً بهطور کامل محقق شده است |
| Largely | 50% تا 85% | بخش عمده الزامات محقق شده اما Gap مهم وجود دارد |
| Partially | 15% تا 50% | اجرای محدود و ناقص است |
| Not | کمتر از 15% | شواهد کافی برای تحقق سطح وجود ندارد |
این درصدها به معنی تبدیل Assessment به یک فرمول کاملاً مکانیکی نیست. ISACA هم تأکید میکند Rating قضاوت حرفهای است و باید با Evidence معتبر پشتیبانی شود. بنابراین «۸۷ درصد» بدون Evidence، از «Largely» مستند ارزش کمتری دارد.
Evidence چیست و چرا مهمتر از مصاحبه است؟
یکی از خطرهای Assessment این است که تمام نتیجه بر اساس مصاحبه با Process Owner ساخته شود. مدیر فرایند معمولاً تصویر مناسبی از کار دارد، اما Assessment باید بتواند گفتهها را با شواهد تطبیق دهد.
Evidence میتواند شامل موارد زیر باشد:
- Policy و Procedure مصوب
- Workflow واقعی در ابزار ITSM یا GRC
- گزارش Incident، Change، Problem یا Audit
- KPI Dashboard و Trend تاریخی
- RACI و Process Ownership
- نمونه Ticket یا Record واقعی
- گزارش Compliance و Exception
- Meeting Minute و Decision Log
- خروجی Automation یا Control
مدل مناسب، ترکیب Interview + Document Review + Sample Testing + Tool Evidence است. در غیر این صورت Assessment به Self-declaration تبدیل میشود.
نمونه عملی: ارزیابی Capability در مدیریت Incident
فرض کنید سازمان میخواهد Capability فرایند مدیریت Incident را ارزیابی کند.
در Level 1 چه میبینیم؟
Incidentها ثبت و حل میشوند، اما Resolution به تجربه افراد وابسته است. Priority ممکن است بهصورت سلیقهای تعیین شود و Escalation ساختار ثابتی نداشته باشد.
در Level 2 چه چیزی اضافه میشود؟
مجموعه پایه فعالیتها کاملتر و قابل تکرار میشود؛ Incident ثبت، دستهبندی، اولویتبندی، Assign، Resolve و Close میشود و خروجی مورد انتظار قابل مشاهده است.
در Level 3 چه تفاوتی ایجاد میشود؟
Process تعریفشده است. Roleها، Procedure، Template، Priority Matrix، Escalation Rule و Policyهای مشترک سازمانی وجود دارند و تیمها از الگوی واحد استفاده میکنند.
Level 4 چه میخواهد؟
Performance کمی اندازهگیری میشود؛ برای مثال MTTR، SLA Compliance، Reopen Rate، Escalation Rate و First Contact Resolution در بازه زمانی پایش میشوند.
Level 5 چه زمانی معنی دارد؟
سازمان از داده Level 4 برای Improvement استفاده میکند. مثلاً تحلیل Trend نشان میدهد یک Category خاص بیشترین Reopen را دارد؛ Root Cause بررسی میشود، Knowledge یا Workflow اصلاح میشود و اثر اصلاح در دوره بعد اندازهگیری میشود.
اگر برای Incident Management از ابزارهایی مثل ServiceDesk Plus استفاده میکنید، بخش مهمی از Evidence میتواند از Workflow، SLA، Audit Trail و Reportهای خود سامانه استخراج شود. برای مطالب بیشتر درباره ITSM نیز میتوانید به ITIL برای همه در ServiceDeskPlus.ir مراجعه کنید.
نمونه عملی دوم: Capability مدیریت امنیت
در حوزه امنیت، فاصله Levelها میتواند بسیار ملموس باشد.
- در سطح پایین، کنترلها بیشتر واکنشی و وابسته به افراد هستند.
- در Level 3، Policy، Responsibility، Procedure و Control ساختاریافتهتر میشوند.
- در Level 4، Coverage، Control Effectiveness، Incident Trend، Vulnerability SLA و Exceptionها قابل اندازهگیری میشوند.
- در Level 5، دادههای Control Performance برای تغییر Policy، Automation و Risk Treatment بهکار میروند.
همین تفاوت نشان میدهد چرا یک Dashboard پر از KPI بهتنهایی Level 4 یا 5 را ثابت نمیکند. KPI باید به Process Definition متصل باشد و در Level 5 باید Improvement قابل اثبات ایجاد کند.
Assessment را از کجا شروع کنیم؟
برای بیشتر سازمانها، ارزیابی همزمان همه ۴۰ Governance/Management Objective شروع مناسبی نیست. پروژه بسیار بزرگ میشود و احتمال اینکه خروجی به Action تبدیل نشود بالا میرود.
یک روش مرحلهای بهتر است:
- سه تا هفت Objective با بیشترین اهمیت یا ریسک را انتخاب کنید.
- Process Owner را مشخص کنید.
- Current Capability را بر اساس Evidence بسنجید.
- Target Capability را بر اساس Strategy و Risk تعیین کنید.
- Gap بین Current و Target را ثبت کنید.
- Gapها را به Improvement Initiative تبدیل کنید.
- Owner، Deadline، Cost و KPI برای هر Initiative تعریف کنید.
- Assessment را در دوره بعد تکرار کنید.
هدف Assessment نباید تولید یک Heatmap زیبا باشد؛ باید به تصمیم درباره سرمایهگذاری، اولویت و کنترل منجر شود.
Gap Analysis؛ عدد اختلاف کافی نیست
فرض کنید Current Capability برابر ۲ و Target برابر ۴ است. نوشتن «Gap = 2» اطلاعات مدیریتی کمی میدهد. بهتر است Gap به اجزای قابل اقدام شکسته شود.
| Gap | نمونه اقدام | مالک | معیار بسته شدن |
|---|---|---|---|
| Process Definition ناقص | تعریف Procedure و RACI | Process Owner | تصویب و اجرای نسخه استاندارد |
| Evidence پراکنده | ثبت اجباری Workflow در سامانه | ITSM Admin | کاهش فعالیت خارج از سیستم |
| KPI ناکافی | تعریف KPI و Baseline | Governance Office | Dashboard ماهانه قابل اتکا |
| Improvement Loop وجود ندارد | Quarterly Review و Action Tracking | Steering Committee | ثبت و Closure اقدامهای بهبود |
در این مدل، Assessment مستقیماً به Portfolio بهبود متصل میشود.
پنج خطای رایج در ارزیابی Capability
۱. سطح هدف ۵ برای همه Processها
این رویکرد هزینه را بالا میبرد و اولویتبندی را از بین میبرد.
۲. تکیه کامل بر پرسشنامه
Questionnaire برای شروع خوب است، اما بدون Evidence نمیتواند Assessment معتبر بسازد.
۳. استفاده از Average برای پنهان کردن ضعف
میانگینگیری از چند Process میتواند یک Weakness مهم را پنهان کند. Processهای Critical باید جدا دیده شوند.
۴. اشتباه گرفتن Tool Maturity با Process Capability
خرید SIEM، ITSM یا GRC بهتنهایی Capability ایجاد نمیکند. ابزار فقط Enabler است؛ Ownership، Procedure، Control و Measurement نیز لازماند.
۵. Assessment بدون برنامه بهبود
اگر بعد از Assessment هیچ Initiative، Budget یا Owner تعریف نشود، ارزیابی به یک فعالیت تشریفاتی تبدیل میشود.
چطور نتیجه Assessment را به مدیران ارائه کنیم؟
مدیران ارشد معمولاً به جدول صدها Activity نیاز ندارند. خروجی مناسب باید سه لایه داشته باشد:
- Executive View: وضعیت فعلی، Target، ریسک اصلی و اولویت سرمایهگذاری
- Management View: Gapها، Initiativeها، Owner و Timeline
- Assessment Evidence: Activity Rating، Evidence، Interview و Traceability
برای Steering Committee، نمایش Current در برابر Target همراه با Business Impact از نمایش صرف یک عدد بسیار مفیدتر است.
Capability Assessment چه ارتباطی با GRC دارد؟
COBIT فقط برای تیم IT Operations نیست. Capability Assessment میتواند به GRC کمک کند تا وضعیت کنترلها و فرایندهای Governance را بهصورت ساختاریافته بسنجد. برای مثال Objectiveهای مرتبط با Risk، Security، Compliance، Internal Control و Assurance میتوانند بهصورت جداگانه ارزیابی شوند و Gapهای آنها وارد Risk Treatment Plan شوند.
این رویکرد بهخصوص در سازمانی که چند استاندارد یا الزام را همزمان دنبال میکند ارزش دارد؛ چون COBIT میتواند نقش لایه Governance را ایفا کند و اجرای Controls در چارچوبهای دیگر را به Objectiveهای کسبوکار متصل کند.
آیا Capability Level جای Audit را میگیرد؟
خیر. Assessment و Audit هدف یکسانی ندارند. Capability Assessment بیشتر میپرسد «Process تا چه حد توانمند و قابل بهبود است؟» در حالی که Audit میتواند بپرسد «آیا الزام یا Control مشخص رعایت شده است؟»
البته شواهد میتوانند مشترک باشند. گزارش Audit، Exception، Control Test و Compliance Evidence میتوانند ورودی بسیار خوبی برای Capability Assessment باشند. اما یک Capability بالا تضمین نمیکند هیچ Nonconformity وجود ندارد.
هر چند وقت یکبار ارزیابی را تکرار کنیم؟
برای Processهای Critical، دوره سالانه یا ششماهه میتواند منطقی باشد؛ برای حوزههایی که Transformation فعال دارند، بازه کوتاهتر هم ممکن است لازم باشد. اما Frequency باید متناسب با سرعت تغییر، ریسک و هزینه Assessment انتخاب شود.
نکته مهمتر از Frequency، ثبات روش است. اگر در هر دوره Scope، Rating Logic یا Evidence Standard عوض شود، Trend قابل مقایسه نخواهد بود.
نکات کلیدی
- Capability Level در COBIT 2019 برای Process است و از ۰ تا ۵ سنجیده میشود.
- Maturity Level بیشتر برای Focus Area کاربرد دارد؛ این دو مفهوم را یکسان در نظر نگیرید.
- Level 5 هدف پیشفرض همه فرایندها نیست؛ Target باید بر اساس Business، Risk و Cost تعیین شود.
- Rating بدون Evidence معتبر ارزش محدودی دارد.
- Assessment باید به Gap، Initiative، Owner و KPI ختم شود.
- Goals Cascade و Design Factorها کمک میکنند Objectiveهای مهم و Target Capability مناسب انتخاب شوند.
- ابزارهای ITSM، SIEM و GRC میتوانند Evidence و Automation فراهم کنند، اما جای Process Governance را نمیگیرند.
منابع
- ISACA – COBIT Resources
- ISACA – Using COBIT 2019 Performance Management Model to Assess Governance and Management Objectives
- ISACA – Defining Target Capability Levels in COBIT 2019
- ISACA – A COBIT 2019 Use Case: Financial Institutions in Georgia
سخن پایانی
ارزش Capability Assessment در عدد نهایی نیست؛ در کیفیت تصمیمی است که از آن عدد ساخته میشود. اگر سازمان بداند کدام Process برای اهداف کسبوکار حیاتی است، Current Capability را با Evidence واقعی بسنجد و Target را متناسب با Risk و Cost انتخاب کند، COBIT Performance Management میتواند به یک ابزار عملی برای اولویتبندی سرمایهگذاری و بهبود تبدیل شود.
اما اگر همه Processها بدون دلیل Level 5 بخواهند، Ratingها بر اساس برداشت افراد ثبت شوند و بعد از Assessment هیچ Initiative تعریف نشود، نتیجه فقط یک گزارش پرهزینه خواهد بود.
مدانت در پروژههای حاکمیت فناوری اطلاعات، COBIT، GRC و همراستاسازی IT با کسبوکار میتواند در طراحی Scope، Assessment، Gap Analysis، Roadmap و اتصال خروجی ارزیابی به ابزارهای ITSM/GRC همراه سازمان باشد. برای بررسی سناریوی سازمان خود میتوانید از درخواست جلسه و مشاوره مدانت یا مسیر آموزشهای تخصصی مدانت استفاده کنید.
