Service Owner در ITIL 5؛ مالک سرویس کیست و چه مسئولیتی دارد؟
در بسیاری از سازمانها همه میدانند چه کسی مدیر شبکه است، چه کسی مدیر نرمافزار است و چه کسی مسئول Service Desk است؛ اما وقتی سؤال میکنیم «مالک سرویس ایمیل سازمانی کیست؟» یا «چه کسی درباره کیفیت انتهابهانتهای سرویس فروش آنلاین پاسخگوست؟» پاسخ ناگهان مبهم میشود. هر تیم بخشی از سرویس را مدیریت میکند، ولی هیچکس مالک نتیجه نهایی نیست.
اینجاست که نقش Service Owner اهمیت پیدا میکند. در نگاه جدید ITIL، مخصوصاً با پررنگترشدن Product و Service Management در ITIL Version 5، سرویس نباید فقط مجموعهای از Server، Application و Ticket باشد. هر سرویس باید هدف، مشتری، ارزش، هزینه، ریسک، تجربه و یک مالک روشن داشته باشد.
Service Owner دقیقاً کیست؟
Service Owner فردی است که نسبت به یک سرویس مشخص، پاسخگویی انتهابهانتها دارد. این نقش لزوماً همه کارهای فنی را انجام نمیدهد و مدیر مستقیم همه تیمهای درگیر هم نیست. مسئولیت اصلی او این است که مطمئن شود سرویس در طول چرخه عمر خود ارزش مورد انتظار را ایجاد میکند، کیفیت آن قابل قبول است، ریسکها مدیریت میشوند و بهبودها فراموش نمیشوند.
در ITIL Version 5، نقشهایی مانند Service Owner، Product Owner، Service Manager، Experience Manager و Process Lead در مسیرهای حرفهای رسمی PeopleCert دیده میشوند. این نشان میدهد مدیریت سرویس دیگر صرفاً اداره عملیات روزانه نیست؛ مالکیت، تجربه، محصول و ارزش در کنار هم قرار گرفتهاند.
مشکل سازمان بدون Service Owner چیست؟
وقتی مالک سرویس نداریم، مسئولیت بین تیمها خرد میشود. تیم زیرساخت Availability را میسنجد، تیم Application Performance را، Service Desk تعداد Ticket را، Security رخدادها را و Finance هزینه را. هر کدام بخشی از حقیقت را دارند، اما کسی تصویر کامل را نمیبیند.
نتیجه میتواند همان پدیده معروف «همه KPIها سبزند ولی کاربر ناراضی است» باشد. یک سرویس ممکن است ۹۹.۹ درصد Availability داشته باشد اما Login آن کند باشد، Changeهای آن مرتب Incident بسازند یا هزینه نگهداریاش بدون ارزش تجاری بالا برود. Service Owner باید این تکهها را کنار هم بگذارد.
Service Owner با Service Manager چه تفاوتی دارد؟
در بعضی سازمانها این دو نقش روی یک نفر قرار میگیرند، اما مفهومی یکسان نیستند. Service Manager معمولاً روی عملیات، هماهنگی، فرایندها و کیفیت اجرای خدمات تمرکز میکند. Service Owner بیشتر روی نتیجه کل سرویس و پاسخگویی بلندمدت تمرکز دارد.
| نقش | تمرکز اصلی | سؤال کلیدی |
|---|---|---|
| Service Owner | ارزش و عملکرد کل سرویس | آیا این سرویس برای مشتری و سازمان نتیجه درست میسازد؟ |
| Service Manager | مدیریت و هماهنگی عملیات سرویس | آیا سرویس درست و پایدار اداره میشود؟ |
| Product Owner | اولویت و ارزش Product Backlog | چه چیزی باید بعدی ساخته یا بهبود داده شود؟ |
| Process Owner | اثربخشی یک Process/Practice | آیا این فرایند در کل سازمان درست کار میکند؟ |
در سازمان کوچک ممکن است یک نفر چند نقش داشته باشد؛ مشکل از جایی شروع میشود که Roleها اصلاً تعریف نشده باشند.
Service Owner و Product Owner؛ مرز کجاست؟
در محیطهای دیجیتال، Product و Service به هم نزدیک شدهاند. ITIL Version 5 نیز همین واقعیت را پذیرفته و Product و Service Management را در یک Lifecycle منسجمتر میبیند. با این حال Product Owner معمولاً بر Backlog، نیازهای کاربر و اولویت توسعه تمرکز میکند، در حالی که Service Owner باید عملکرد واقعی سرویس بعد از تحویل را هم ببیند.
مثلاً در یک سامانه منابع انسانی، Product Owner ممکن است تصمیم بگیرد قابلیت درخواست مرخصی جدید چه اولویتی دارد. Service Owner باید بپرسد آیا کل سرویس HR Portal قابل اتکاست، SLA دارد، پشتیبانی میشود، امنیتش مناسب است و تجربه کاربر در طول زمان بهتر میشود یا نه.
مسئولیتهای اصلی Service Owner
مسئولیت Service Owner را میتوان در چند محور دید: تعریف Outcome و Scope سرویس، شناخت Stakeholderها، کنترل کیفیت، مدیریت ریسک، نظارت بر هزینه، هماهنگی Supplierها، تصمیمگیری درباره Improvement و دفاع از سرویس در سطح Governance.
او باید بتواند پاسخ دهد: سرویس برای چه کسی است؟ چه Value Proposition دارد؟ کدام Business Capability به آن وابسته است؟ چه SLA یا XLAهایی مهماند؟ بیشترین Incidentها از کجا میآیند؟ Service Cost چقدر است؟ چه Riskهایی پذیرفته شدهاند؟ چه Improvementهایی در Backlog داریم؟
Service Owner نباید تبدیل به «صاحب همه کارها» شود
یکی از اشتباهات رایج این است که مالکیت را با اجرا یکی بدانیم. Service Owner نباید خودش همه Incidentها را حل کند، Patch نصب کند یا هر Change را شخصاً اجرا کند. اگر چنین شود، نقش از سطح Ownership به سطح Operations سقوط میکند.
مالک واقعی بیشتر شبیه رهبر یک اکوسیستم است. او باید مطمئن شود Roleها روشناند، تیمها با هم کار میکنند، داده کافی وجود دارد و تصمیمها بر اساس Outcome گرفته میشوند.
یک Service Owner چه KPIهایی باید ببیند؟
فقط SLA کافی نیست. یک Dashboard خوب برای Service Owner باید چند بُعد را کنار هم قرار دهد:
- Availability و Reliability سرویس
- MTTR و تعداد Major Incident
- Change Failure Rate
- حجم و Trend درخواستها
- رضایت یا Experience کاربران
- هزینه کل ارائه سرویس
- ریسکها و Vulnerabilityهای باز
- ظرفیت و Performance
- درصد Improvementهای تکمیلشده
- وابستگیها و وضعیت Supplierها
اگر فقط حجم Ticket را بسنجیم، سرویس را با Service Desk اشتباه گرفتهایم. Service Owner باید از فناوری تا تجربه و اقتصاد سرویس را ببیند.
رابطه Service Owner و Service Catalog
Service Catalog بدون Owner خیلی زود تبدیل به فهرست اسامی میشود. برای هر سرویس باید حداقل Owner، Description، Customer، Support Group، SLA، Hours، Dependencies و Contact روشن باشد.
اگر در ServiceDesk Plus از Service Catalog استفاده میکنید، تعیین مالکیت میتواند کمک کند Catalog از یک فرم درخواست فراتر رود و به نقشه واقعی خدمات تبدیل شود.
Service Owner و CMDB
CMDB پاسخ میدهد سرویس از چه CIهایی ساخته شده و چه وابستگیهایی دارد. Service Owner باید از این تصویر برای Impact Analysis استفاده کند. اگر یک Database، Firewall یا API حیاتی تغییر میکند، مالک سرویس باید بداند چه Outcomeای در معرض ریسک قرار میگیرد.
برای همین کیفیت CMDB برای Service Owner موضوع فنی فرعی نیست. راهنمای CMDB Health در ServiceDesk Plus نشان میدهد CIهای تکراری، Stale یا بدون Relationship چطور تصمیمگیری را خراب میکنند.
Service Owner و Incident Management
در Incident Management روزمره، Service Owner نباید Micro-manage کند. اما در Major Incident و Patternهای تکراری حضورش مهم میشود. او باید ببیند آیا Incident صرفاً یک خطای فنی بود یا نشانه ضعف طراحی سرویس، Capacity، Supplier، Change یا Monitoring.
بعد از Major Incident، یکی از خروجیهای مهم برای Service Owner این است که اقدام اصلاحی به Improvement Backlog تبدیل شود و بین تیمها گم نشود.
Service Owner و Change
هر Change کوچک نیاز به تأیید Service Owner ندارد؛ این کار سرعت سازمان را نابود میکند. اما Changeهای پرریسک یا اثرگذار بر Outcome سرویس باید در مدل Governance جایگاه روشنی داشته باشند.
Service Owner میتواند معیارهای Risk، Freeze Window، Business Calendar و Dependency را در تصمیم Change نمایندگی کند. مقاله Freeze Window و Change Calendar در ServiceDesk Plus نمونهای از همین نگاه است.
Service Owner و Supplier Management
در سرویسهای مدرن، بخشی از زنجیره اغلب بیرون سازمان است: Cloud، ISP، MSP، Software Vendor یا پیمانکار Application. Service Owner باید عملکرد این اجزا را با Outcome سرویس مرتبط کند.
اگر Supplier SLA خودش را رعایت کرده ولی End-to-End Service شکست خورده، Service Owner نمیتواند گزارش سبز Vendor را پایان بحث بداند. این همان جایی است که SIAM هم اهمیت پیدا میکند. در مقاله SIAM چیست؟ به مسئله مدیریت چندتأمینکننده پرداختهایم.
چه کسی باید Service Owner شود؟
بهترین Service Owner لزوماً ارشدترین فرد فنی نیست. فرد مناسب باید هم سرویس و فناوری را بفهمد، هم زبان کسبوکار را. باید قدرت Influence داشته باشد، چون بسیاری از تیمهای درگیر به او گزارش مستقیم نمیدهند.
ویژگیهای مفید شامل نگاه End-to-End، توان تحلیل داده، درک هزینه و ریسک، ارتباط با Stakeholder، تصمیمگیری در تعارض و توان تبدیل مشکل به Improvement است.
مدل RACI برای مالکیت سرویس
برای جلوگیری از ابهام، میتوان یک RACI ساده ساخت. Service Owner معمولاً نسبت به Outcome سرویس Accountable است. Support Teamها، Infrastructure، Application و Security در حوزههای خود Responsible هستند. Business Owner و Risk/Compliance ممکن است Consulted باشند و کاربران و Stakeholderهای دیگر Informed.
نکته کلیدی این است که برای هر سرویس فقط یک نقطه Accountable روشن داشته باشیم. چند مالک برابر معمولاً یعنی هیچ مالک واقعی.
سناریوی واقعی؛ سرویس ایمیل سازمانی
فرض کنید Microsoft 365 ایمیل سازمان را تأمین میکند. Messaging Team تنظیمات Exchange را انجام میدهد، Identity Team حسابها را مدیریت میکند، Security روی MFA و Phishing کار میکند و Service Desk Ticket میگیرد. بدون Service Owner، هر تیم موفقیت را جداگانه تعریف میکند.
Service Owner باید تصویر کلی را بسازد: Delivery Reliability، Login Experience، Mail Flow، Security Incident، License Cost، Delegation Risk، Support Volume و Satisfaction. اگر هزینه بالا رفته ولی Mailboxهای بلااستفاده زیادند، موضوع اوست. اگر MFA امن است اما Login کاربران را مختل کرده، موضوع اوست. اگر Supplier Incident دارد، باز هم موضوع اوست.
چطور Service Ownership را در ۳۰ روز راه بیندازیم؟
هفته اول ۱۰ تا ۲۰ سرویس حیاتی را مشخص کنید. هفته دوم برای هر سرویس Owner و Business Stakeholder تعیین کنید. هفته سوم KPI، SLA، Risk و Dependencyهای اصلی را تعریف کنید. هفته چهارم یک Service Review واقعی برگزار کنید و فقط دادههایی را نگه دارید که تصمیم ایجاد میکنند.
قرار نیست در یک ماه Service Management کامل شود. هدف این است که ابهام مالکیت از بین برود و سرویسها صاحب پاسخگویی شوند.
Service Review باید چه سؤالاتی بپرسد؟
جلسه Service Review نباید گزارشخوانی باشد. پنج سؤال کافی است: چه چیزی برای کاربر بدتر شده؟ چه Riskی در حال رشد است؟ چه Incident یا Change الگوی تکراری دارد؟ کدام هزینه بدون Value بالا رفته؟ و چه Improvementی تا جلسه بعد Owner و Deadline دارد؟
اگر جلسه فقط نمودارهای سبز را مرور کند، مالکیت سرویس به تشریفات تبدیل میشود.
جایگاه ابزار در مالکیت سرویس
ابزار ITSM میتواند Service Catalog، SLA، CMDB، Incident، Change، Survey و Dashboard را کنار هم قرار دهد. اما Tool بهخودیخود Owner تولید نمیکند. ابتدا Role و Accountability باید روشن شود، بعد داده در ابزار سازماندهی شود.
برای پیادهسازی این مدل در ابزار میتوانید راهنمای ServiceDesk Plus و صفحه لایسنس ServiceDesk Plus را ببینید.
سخن پایانی
Service Owner پاسخی به یک مشکل ساده اما عمیق است: سرویسها از مرز تیمها عبور میکنند، اما مسئولیتها معمولاً داخل همان مرزها میمانند. وقتی یک نفر مالک Outcome انتهابهانتها باشد، Availability، تجربه، هزینه، ریسک و Improvement در یک تصویر واحد دیده میشوند.
در ITIL Version 5 که Product و Service Lifecycle بیش از گذشته به هم نزدیک شدهاند، این نقش اهمیت بیشتری پیدا میکند. سازمان بالغ فقط نمیپرسد «چه کسی این سیستم را پشتیبانی میکند؟»؛ میپرسد «چه کسی مالک ارزش این سرویس است؟»
منابع
PeopleCert – ITIL Foundation Version 5
PeopleCert – ITIL Product Version 5
PeopleCert – ITIL Service Version 5
