پاسخ کوتاه این است: خیر، ServiceDesk Plus بهصورت رسمی و Native چیزی به نام CSDM ندارد. CSDM یا Common Service Data Model یک چارچوب و مدل داده اختصاصی ServiceNow است که برای استانداردسازی مدلسازی سرویسها، اپلیکیشنها، CIها و روابط آنها در CMDB استفاده میشود.
اما این پاسخ به معنای ضعف مطلق ServiceDesk Plus نیست. ServiceDesk Plus دارای CMDB، CI Relationship، Service Catalog، Business Service، IT Service و قابلیت تحلیل اثر از طریق رابطه میان CIهاست. بنابراین سازمان میتواند با طراحی درست، بخشی از منطق سرویسمحور CSDM را در ServiceDesk Plus پیادهسازی کند؛ فقط نباید آن را با CSDM Native در ServiceNow یکی دانست.
چرا این سؤال مهم است؟
در بسیاری از سازمانها، CMDB فقط بهعنوان فهرستی از داراییها دیده میشود؛ سرورها، نرمافزارها، تجهیزات شبکه، دیتابیسها، سرویسها و مالکین. اما برای تصمیمگیری در Incident، Change، Problem، BCM یا IRM فقط داشتن فهرست کافی نیست. سازمان باید بداند هر CI به کدام سرویس، فرآیند، تیم، ریسک، کنترل و تعهد کسبوکار متصل است.
اینجاست که در ServiceNow مفهوم CSDM وارد میشود. CSDM تلاش میکند CMDB را از یک مخزن داده فنی، به یک مدل سرویسمحور قابل استفاده برای ITSM، ITOM، IRM، BCM و Operational Resilience تبدیل کند.
CSDM چیست؟
CSDM مخفف Common Service Data Model است. ServiceNow آن را بهعنوان مدل داده استانداردی معرفی میکند که مدیران پلتفرم باید هنگام پیکربندی محصولات و اپلیکیشنهای ServiceNow دنبال کنند. این مدل به سازمان کمک میکند دادههای مرتبط با سرویسها، اپلیکیشنها و CIها در جای درست CMDB قرار بگیرند و برای گزارشگیری، تحلیل اثر و اتوماسیون قابل استفاده باشند.
به زبان ساده، CMDB میگوید «چه چیزهایی داریم»، اما CSDM توضیح میدهد «این چیزها چگونه به سرویسهای کسبوکار، سرویسهای فنی، اپلیکیشنها و ارزش عملیاتی سازمان متصل هستند».
آیا ServiceDesk Plus CSDM دارد؟
ServiceDesk Plus چارچوب رسمی CSDM را بهصورت Native ندارد. یعنی در مستندات ManageEngine، ماژولی با نام CSDM یا مدل نسخهبندیشدهای مانند CSDM 3.0، CSDM 4.0 یا CSDM 5.0 وجود ندارد.
با این حال، ServiceDesk Plus دارای قابلیتهایی است که برای ساخت یک مدل سرویسمحور بسیار مهماند:
- CMDB برای نگهداری Configuration Itemها
- CI Type برای تعریف انواع داراییها و سرویسها
- CI Relationship برای نمایش وابستگی میان CIها
- Relationship Map برای مشاهده ارتباطات
- Business Service و IT Service در ساختار CMDB
- Service Catalog برای استانداردسازی درخواستهای خدمت
- اتصال CIها به Incident، Problem و Change
- امکان تحلیل اثر تغییر یا اختلال بر سرویسها
بنابراین ServiceDesk Plus CSDM ندارد، اما میتواند با طراحی درست CMDB و Service Catalog، به یک مدل عملیاتی نزدیک به CSDM برسد.
جدول تفاوت CSDM در ServiceNow و مدلسازی CMDB در ServiceDesk Plus
| موضوع | ServiceNow با CSDM | ServiceDesk Plus با CMDB |
|---|---|---|
| ماهیت مدل | چارچوب رسمی، استاندارد و نسخهبندیشده ServiceNow | CMDB عملیاتی با امکان طراحی سفارشی CI Type و رابطهها |
| نام CSDM | وجود دارد و بخشی از راهنمای رسمی ServiceNow است | بهصورت رسمی و Native وجود ندارد |
| مدلسازی سرویس | ساختارمند بر اساس Business Application، Application Service، Technical Service و Service Offering | قابل طراحی با Business Service، IT Service، CI Type و Relationship |
| وابستگیها | بر پایه مدل داده استاندارد و جدولهای مشخص CMDB | بر پایه CI Relationship و Relationship Map |
| استفاده در ITSM | بسیار ساختارمند و یکپارچه با ماژولهای ServiceNow | قابل استفاده در Incident، Problem، Change و Service Catalog |
| استفاده در BCM و IRM | قابل اتصال به ماژولهای IRM، BCM و Operational Resilience در اکوسیستم ServiceNow | نیازمند طراحی دستی، فیلدهای سفارشی، گزارشگیری و فرآیند Governance |
| پیچیدگی اجرا | نیازمند بلوغ داده، تیم پلتفرم و حاکمیت جدی | سادهتر برای سازمانهای متوسط، اما وابسته به طراحی درست |
| مناسب برای | سازمانهای بزرگ با نیاز جدی به مدل سرویس، ریسک، تابآوری و اتوماسیون گسترده | سازمانهایی که ITSM، Asset، Change و CMDB عملیاتی میخواهند، اما الزام به CSDM رسمی ندارند |
مزایای مدل سرویسمحور در ServiceDesk Plus
حتی بدون CSDM Native، طراحی درست CMDB در ServiceDesk Plus میتواند ارزش عملیاتی قابل توجهی ایجاد کند.
۱. تحلیل اثر قبل از Change
وقتی CIها و سرویسها رابطهمند شوند، تیم Change میتواند قبل از اجرای تغییر، اثر آن را روی سرویسهای حیاتی بررسی کند. این موضوع مخصوصاً قبل از CAB اهمیت دارد. برای مطالعه بیشتر، مقاله CI Impact Analysis در ServiceDesk Plus را ببینید.
۲. افزایش کیفیت CMDB
یک CMDB ناسالم، خروجیهای اشتباه تولید میکند. CIهای تکراری، رکوردهای قدیمی، رابطههای ناقص و مالکیتهای نامشخص باعث میشوند تحلیل اثر، گزارشگیری و مدیریت تغییر قابل اتکا نباشد. مدانت در مقاله CMDB Health در ServiceDesk Plus به همین موضوع پرداخته است.
۳. اتصال Service Catalog به عملیات واقعی
Service Catalog زمانی ارزشمند است که فقط یک فرم درخواست نباشد؛ بلکه به سرویس، SLA، Approval، Task و مالکیت عملیاتی متصل شود. در ServiceDesk Plus میتوان با طراحی درست Service Catalog و CMDB، درخواستهای خدمت را به مدل عملیاتی نزدیکتر کرد. مقاله Service Catalog در ServiceDesk Plus در همین زمینه مفید است.
۴. آمادگی بهتر برای Incident و Problem
وقتی مشخص باشد هر CI به چه سرویسهایی وابسته است، در زمان Incident تیم پشتیبانی سریعتر میفهمد مشکل از کجا شروع شده و چه سرویسهایی تحت تأثیر قرار گرفتهاند. همین دید برای Root Cause Analysis در Problem Management نیز حیاتی است.
۵. پایهسازی برای BCM و IRM
اگرچه ServiceDesk Plus ماژول CSDM ندارد، اما یک CMDB خوب میتواند پایهای برای اتصال سرویسهای حیاتی به برنامههای بازیابی، ریسکها، کنترلها و ممیزیها باشد؛ البته این بخش معمولاً به طراحی فرآیند، فیلدهای سفارشی، گزارشگیری و یکپارچهسازی با ابزارهای دیگر نیاز دارد.
چگونه در ServiceDesk Plus مدلی نزدیک به CSDM بسازیم؟
مرحله اول: سرویسهای حیاتی را مشخص کنید
قبل از ورود به CIها، باید بدانید کدام سرویسها برای کسبوکار حیاتی هستند. نمونهها میتواند شامل سامانه مالی، سیستم فروش، سرویس احراز هویت، سامانه ارتباط با مشتری، سرویس اینترنت شعب یا زیرساخت ایمیل سازمانی باشد.
مرحله دوم: CI Typeها را درست طراحی کنید
در CMDB فقط سرور و لپتاپ ثبت نکنید. برای Business Service، IT Service، Application، Database، Network Device، Cloud Resource و Vendor Dependency هم مدل مشخص داشته باشید. هر CI Type باید Attributeهای مرتبط و قابل نگهداری داشته باشد.
مرحله سوم: رابطهها را جدی بگیرید
ارزش CMDB در رابطههاست. اگر مشخص نباشد اپلیکیشن به کدام دیتابیس، دیتابیس به کدام سرور، سرور به کدام سرویس و سرویس به کدام فرآیند کسبوکار متصل است، CMDB فقط یک انبار رکورد خواهد بود.
مرحله چهارم: Service Catalog را به مدل سرویس وصل کنید
درخواستهای Service Catalog باید به سرویسهای واقعی، گروههای پشتیبانی، SLA، Approval و Taskهای عملیاتی متصل باشند. این کار باعث میشود Catalog فقط ویترین درخواست نباشد، بلکه بخشی از مدل مدیریت سرویس شود.
مرحله پنجم: Change و Incident را به CIها متصل کنید
هر Incident، Problem یا Change مهم باید به CI مرتبط وصل شود. این اتصال در طول زمان داده ارزشمندی برای تحلیل تکرار خرابی، تشخیص ریشه مشکل، تحلیل اثر تغییر و اولویتبندی سرمایهگذاری IT ایجاد میکند.
مرحله ششم: مالکیت و Governance تعریف کنید
برای هر سرویس و CI مهم باید مالک مشخص باشد. نقشهایی مانند Service Owner، Application Owner، CI Owner، CMDB Manager و Change Manager باید مسئولیت روشن داشته باشند. بدون مالکیت، CMDB بهمرور به دادهای قدیمی و غیرقابل اعتماد تبدیل میشود.
مرحله هفتم: گزارشهای مدیریتی بسازید
برای نزدیک شدن به ارزش CSDM، فقط ثبت داده کافی نیست. باید گزارشهای عملیاتی و مدیریتی داشته باشید؛ مانند:
- سرویسهای حیاتی بدون مالک
- CIهای مهم بدون رابطه
- تغییرهای انجامشده روی سرویسهای حیاتی
- Incidentهای پرتکرار بر اساس Business Service
- CIهای فاقد داده بهروز
- سرویسهای بدون برنامه بازیابی یا RTO مشخص
- ریسکهای مرتبط با سرویسهای حیاتی
BCM و IRM در این بحث چه نقشی دارند؟
BCM یا Business Continuity Management به سازمان کمک میکند در زمان اختلال، عملیات حیاتی را ادامه دهد یا سریعتر بازیابی کند. IRM یا Integrated Risk Management نیز ریسک، کنترل، انطباق و اثر کسبوکار را به هم متصل میکند.
در ServiceNow، CSDM میتواند پایه مشترکی برای اتصال CMDB به BCM، IRM و Operational Resilience باشد. در ServiceDesk Plus، این اتصال بهصورت آماده و همسطح با ServiceNow وجود ندارد؛ اما با طراحی CMDB، فیلدهای سفارشی، گزارشهای مدیریتی و یکپارچهسازی با ابزارهای ریسک و تداوم کسبوکار، میتوان به بخشی از این ارزش رسید.
چه زمانی ServiceDesk Plus کافی است و چه زمانی ServiceNow مناسبتر است؟
| نیاز سازمان | گزینه مناسبتر |
|---|---|
| مدیریت Incident، Request، Change، Asset و CMDB عملیاتی | ServiceDesk Plus میتواند انتخاب اقتصادی و کاربردی باشد |
| طراحی Service Catalog، SLA، Approval و فرآیندهای ITSM | ServiceDesk Plus برای بسیاری از سازمانها کافی است |
| مدل داده بسیار پیشرفته سرویسمحور در سطح Enterprise | ServiceNow با CSDM قویتر است |
| اتصال Native میان CMDB، IRM، BCM و Operational Resilience | ServiceNow مناسبتر است |
| بودجه محدودتر و نیاز به پیادهسازی سریعتر ITSM | ServiceDesk Plus منطقیتر است |
| نیاز به Governance پیچیده، Service Portfolio و Data Model استاندارد جهانی | ServiceNow انتخاب کاملتری است |
جمعبندی
ServiceDesk Plus CSDM ندارد؛ اگر منظور از CSDM همان چارچوب رسمی ServiceNow باشد، پاسخ قطعی «خیر» است. اما ServiceDesk Plus CMDB دارد و با کمک CI Relationship، Business Service، IT Service، Service Catalog و اتصال به Incident، Problem و Change میتواند یک مدل سرویسمحور عملیاتی بسازد.
تفاوت اصلی اینجاست: در ServiceNow، CSDM یک چارچوب رسمی و Native است. در ServiceDesk Plus، باید با طراحی درست CMDB، تعریف رابطهها، استانداردسازی Service Catalog، تعیین مالکیت و Governance، مدل مشابه را بهصورت سفارشی پیادهسازی کرد.
اگر هدف سازمان فقط ITSM و CMDB عملیاتی باشد، ServiceDesk Plus میتواند گزینهای مناسب و اقتصادی باشد. اما اگر سازمان به یک مدل Enterprise برای IRM، BCM، Operational Resilience و Service Portfolio نیاز دارد، ServiceNow با CSDM ساختار کاملتری ارائه میدهد.
مدانت میتواند در طراحی، پیادهسازی و بهینهسازی ServiceDesk Plus، CMDB، Service Catalog، Change Management و مدلسازی سرویسهای حیاتی به سازمانها کمک کند. برای برنامهریزی خرید، ارتقا یا انتخاب نسخه مناسب ManageEngine، مقاله خرید لایسنس ManageEngine نیز میتواند نقطه شروع خوبی باشد.
منابع
- ServiceNow Documentation: Common Service Data Model
- ServiceNow: Common Services Data Model
- ServiceNow: How to model and manage services with CSDM
- ManageEngine ServiceDesk Plus: Configuration Management Database
- ManageEngine ServiceDesk Plus: CI Relationships
- ServiceDesk Plus Help: Service Catalog
