مدل عملیاتی فناوری اطلاعات چیست؟ از Strategy تا ITIL 5 و COBIT
بسیاری از سازمانها استراتژی فناوری دارند، ابزار هم دارند، حتی فرایندهای ITIL را هم تا حدی پیاده کردهاند؛ اما وقتی یک سرویس حیاتی دچار اختلال میشود، هنوز معلوم نیست چه کسی صاحب تصمیم است، چه تیمی باید اقدام کند، کدام شاخص مهمتر است و چرا پروژههای فناوری با وجود هزینه بالا، ارزش قابلدیدن ایجاد نمیکنند. اینجا مسئله کمبود نرمافزار نیست؛ مسئله نبود یک مدل عملیاتی فناوری اطلاعات روشن است.
مدل عملیاتی IT توضیح میدهد فناوری در عمل چگونه کار میکند: تصمیمها کجا گرفته میشوند، نقشها چگونه تقسیم شدهاند، بودجه و ظرفیت چگونه تخصیص مییابد، سرویس و محصول دیجیتال چگونه طراحی و تحویل میشود، امنیت در کدام نقطه وارد کار میشود و عملکرد با چه شاخصهایی سنجیده میشود. به زبان ساده، Strategy میگوید «کجا میرویم» و Operating Model میگوید «هر روز چگونه حرکت میکنیم».
چرا سازمانها به Operating Model نیاز دارند؟
فرض کنید مدیرعامل از CIO میخواهد ظرف شش ماه تجربه کارکنان در خدمات داخلی بهتر شود. تیم زیرساخت پیشنهاد مانیتورینگ جدید میدهد، Service Desk روی SLA تمرکز میکند، امنیت چند کنترل تازه میخواهد و تیم نرمافزار Portal جدیدی پیشنهاد میدهد. همه پیشنهادها میتوانند درست باشند؛ اما اگر مدل عملیاتی مشترکی وجود نداشته باشد، هر تیم مسئله را از زاویه خودش حل میکند.
مدل عملیاتی این پراکندگی را جمع میکند. به جای اینکه هر واحد KPI مستقل داشته باشد، یک Outcome مشترک تعریف میشود؛ مثلاً «کاهش زمان از درخواست تا دریافت خدمت». بعد مشخص میشود کدام Value Stream، کدام Service Owner، کدام Platform و کدام Practice باید برای این Outcome کار کنند.
ITIL 5 چه چیزی به این بحث اضافه کرده است؟
نسخه جدید ITIL در ۲۰۲۶ دامنه خود را از Service Management سنتی به مدیریت یکپارچه محصولات و خدمات دیجیتال توسعه داده است. در منابع رسمی PeopleCert، تأکید زیادی بر Value Stream، Experience، Product and Service Lifecycle و همکاری میان تیمها دیده میشود. این جهتگیری مهم است چون مدل عملیاتی مدرن دیگر نمیتواند تیم توسعه، عملیات، Service Desk، امنیت و محصول را بهصورت جزایر جدا طراحی کند.
در ITIL Version 5 چرخهای از فعالیتهای Discover، Design، Acquire، Build، Transition، Operate، Deliver و Support مطرح میشود. این نگاه برای Operating Model بسیار کاربردی است؛ چون به جای تمرکز صرف بر Process، سؤال اصلی این میشود که ارزش از ایده تا تجربه کاربر چگونه جریان پیدا میکند و در هر مرحله چه نقش، اطلاعات و تصمیمی لازم است.
COBIT کجای مدل عملیاتی قرار میگیرد؟
ITIL برای مدیریت محصول و خدمت زبان عملیاتی قدرتمندی میدهد، اما سازمان همچنان به Governance نیاز دارد. COBIT این بخش را کامل میکند. در COBIT، Governance و Management از هم تفکیک میشوند: Governance جهت، اولویت و نظارت را تعیین میکند؛ Management برنامهریزی، ساخت، اجرا و پایش را پیش میبرد.
پنج دامنه COBIT یعنی EDM، APO، BAI، DSS و MEA کمک میکنند Operating Model فقط به Service Desk و عملیات روزانه محدود نشود. تصمیمهای سرمایهگذاری، معماری، تأمینکننده، امنیت، ریسک، تغییر و ارزیابی عملکرد باید داخل یک سیستم مدیریتی واحد دیده شوند.
هفت تصمیم اصلی در طراحی مدل عملیاتی IT
۱. فناوری برای سازمان چه نقشی دارد؟
در بعضی سازمانها IT نقش Support دارد؛ در بعضی دیگر مستقیماً محصول و درآمد میسازد. Operating Model این تفاوت را باید منعکس کند. اگر فناوری برای کسبوکار حیاتی است، Governance، Product Management، Architecture و Reliability نمیتوانند نقش فرعی داشته باشند.
۲. واحد مدیریت چیست: پروژه، سرویس یا محصول؟
یکی از خطاهای رایج این است که همه چیز به شکل پروژه دیده شود. پروژه تمام میشود، اما سرویس باقی میماند. برای سامانههای حیاتی بهتر است مالکیت پس از Go-Live روشن باشد: Service Owner یا Product Owner چه کسی است؟ بودجه بهبود مستمر از کجا میآید؟ Technical Debt چگونه مدیریت میشود؟
۳. تصمیمها کجا گرفته میشوند؟
همه تصمیمها نباید به کمیته برسند و همه تصمیمها هم نباید در اختیار یک تیم باشد. Change کمریسک، استاندارد معماری، پذیرش ریسک، خرید نرمافزار و Incident بحرانی سطوح اختیار متفاوتی میخواهند. RACI بهتنهایی کافی نیست؛ باید Decision Rights روشن باشد.
۴. Value Streamها چگونه طراحی میشوند؟
به جای ساختن دهها Process مجزا، مسیرهای واقعی ارزش را ببینید. نمونهها: Joiner تا آمادهبهکارشدن کارمند، Incident تا بازیابی سرویس، درخواست نرمافزار تا تحویل، Vulnerability تا Remediation، ایده تا Release. هر Value Stream باید Owner، ورودی، خروجی، KPI و وابستگیهایش را داشته باشد.
۵. چه چیزی متمرکز و چه چیزی توزیعشده است؟
معماری، امنیت پایه، Identity، Service Management Platform و Vendor Governance معمولاً از استاندارد مشترک سود میبرند. در مقابل، بعضی تصمیمهای محصول و فرایند باید نزدیک به واحد کسبوکار باقی بمانند. هدف، تمرکز حداکثری نیست؛ هدف جلوگیری از دوبارهکاری و تعارض است.
۶. ابزارها چه نقشی دارند؟
Operating Model نباید با نام نرمافزار شروع شود، اما بدون Platform هم عملیاتی نمیشود. ServiceDesk Plus میتواند لایه ITSM/ESM را پوشش دهد، OpManager و ابزارهای ITOM برای مشاهدهپذیری زیرساخت به کار میروند، AssetExplorer و Endpoint Central لایه دارایی و Endpoint را تکمیل میکنند و در امنیت، ابزارهایی مانند Log360، PAM360 و ADAudit Plus شواهد و کنترلهای عملیاتی را فراهم میکنند.
۷. موفقیت با چه چیزی سنجیده میشود؟
تعداد Ticket بستهشده، Uptime یا تعداد Project تحویلشده به تنهایی ارزش را نشان نمیدهد. مدل عملیاتی باید ترکیبی از Outcome، Flow، Experience، Risk و Cost داشته باشد. برای مثال در Service Desk علاوه بر SLA میتوان Reopen Rate، Self-Service Adoption و CSAT را دید؛ در Portfolio علاوه بر On-Time Delivery باید Benefit Realization و Cost of Delay را هم سنجید.
یک سناریوی واقعی: سازمانی با ده ابزار و صفر مالکیت
سازمانی را تصور کنید که Service Desk، Monitoring، SIEM، Endpoint Management، CMDB و Project Management دارد. هر تیم Dashboard خودش را دارد و هر Vendor قرارداد خودش را. هنگام اختلال سامانه فروش، NOC میگوید شبکه سالم است، تیم سرور میگوید VM روشن است، تیم نرمافزار منتظر Database است و Service Desk فقط تعداد تماسها را ثبت میکند.
در مدل عملیاتی بازطراحیشده، ابتدا Business Service تعریف میشود. سرویس مالک دارد، CIهای حیاتی در CMDB مشخصاند، Monitoring به Service View متصل است، Major Incident Roleها از قبل تعیین شدهاند و Communication Plan وجود دارد. مسئله همان زیرساخت است، اما شکل کار کاملاً متفاوت میشود.
Operating Model و ساختار سازمانی یک چیز نیستند
تغییر چارت سازمانی بهتنهایی مدل عملیاتی را اصلاح نمیکند. ممکن است واحدها را ادغام کنید اما Decision Rights، Data Flow و KPI همچنان قدیمی بماند. Operating Model مجموعهای از چند مؤلفه است: Governance، ساختار، Role، Process/Value Stream، Information، Technology، Sourcing، Skills و Culture.
این نگاه با COBIT نیز همراستاست؛ زیرا Governance System فقط Process نیست و Culture، People، Information و Services/Infrastructure را هم در بر میگیرد.
فرهنگ سازمانی؛ بخش نامرئی Operating Model
دو سازمان ممکن است یک Process و یک نرمافزار داشته باشند اما خروجی کاملاً متفاوت بگیرند. اگر تیمها Incident را پنهان کنند، Change شکستخورده را گزارش نکنند یا KPI را برای زیباتر شدن Dashboard دستکاری کنند، هیچ چارچوبی نجاتبخش نیست.
فرهنگ مطلوب Operating Model بر Transparency، Ownership، Learning و Blameless Improvement تکیه دارد. هدف این نیست که خطا حذف شود؛ هدف این است که خطا زود دیده شود، سریع مهار شود و به یادگیری تبدیل شود.
از کجا شروع کنیم؟
یک Transformation بزرگ و چندساله لازم نیست. بهتر است از یک Service یا Value Stream مهم شروع شود. Current State را مستند کنید، Owner و Outcome را روشن کنید، Bottleneckها را پیدا کنید، ابزارها و نقشها را روی جریان واقعی قرار دهید و سپس KPIهای محدود اما قابل اقدام تعریف کنید.
صفحه مشاوره مدیریت فناوری اطلاعات مدانت برای همین نوع Assessment طراحی شده است. اگر مسئله بیشتر انتخاب ابزار و Vendor است، مسیر انتخاب نرمافزار و RFP مناسبتر است. برای سازمانهایی که بخشی از عملیات را برونسپاری میکنند نیز مدل MSP باید با Operating Model هماهنگ شود، نه اینکه به یک قرارداد جدا از معماری مدیریتی تبدیل شود.
جدول ساده طراحی Operating Model
| سؤال | خروجی مورد انتظار |
|---|---|
| چه Outcomeی مهم است؟ | هدف قابلاندازهگیری کسبوکار |
| مالک سرویس/محصول کیست؟ | Accountability روشن |
| جریان ارزش چیست؟ | Value Stream انتها به انتها |
| تصمیم کجا گرفته میشود؟ | Decision Rights و Governance |
| چه دادهای لازم است؟ | Single Source of Truth و KPI |
| چه Platformهایی لازماند؟ | Technology Architecture |
| چه چیزی برونسپاری میشود؟ | Sourcing و Vendor Model |
| چگونه بهتر میشویم؟ | Continual Improvement Backlog |
سخن پایانی
مدل عملیاتی فناوری اطلاعات حلقه مفقوده بین Strategy و اجرای روزمره است. سازمانی که فقط چارچوب، ابزار یا چارت دارد، هنوز Operating Model ندارد. مدل خوب مشخص میکند چه کسی برای چه ارزشی مسئول است، تصمیمها چگونه گرفته میشوند، کار چگونه از ابتدا تا انتها جریان پیدا میکند و فناوری چگونه نتیجه کسبوکار را قابل سنجش میکند.
