فرض کنید واحد منابع انسانی درخواست ایجاد کاربر جدید را با ایمیل میفرستد، مدیر واحد در پیامرسان تأیید میکند، تیم IT فرم جداگانهای دارد و در نهایت مشخص نیست چه کسی چه چیزی را تصویب کرده است. همین الگوی پراکنده برای درخواست VPN، نرمافزار، لپتاپ، دسترسی، خرید و دهها خدمت دیگر تکرار میشود. نتیجه، تأخیر، دوبارهکاری و SLA مبهم است.
Service Catalog در ServiceDesk Plus کمک میکند درخواستهای پرتکرار به سرویسهای استاندارد با فرم، Approval، SLA، Assignment و Automation مشخص تبدیل شوند. این مقاله روی طراحی کاتالوگی تمرکز دارد که واقعاً قابل استفاده باشد؛ نه فهرستی طولانی از فرمها.
Service Catalog چه مسئلهای را حل میکند؟
کاتالوگ خدمات باید رابط عملی بین کاربر و تیم ارائهدهنده خدمت باشد. کاربر لازم نیست ساختار داخلی IT را بداند؛ باید سرویس موردنظر را انتخاب کند، اطلاعات لازم را بدهد و بداند چه زمانی نتیجه میگیرد.
| بدون Catalog | با Catalog |
|---|---|
| درخواست آزاد و مبهم | فرم استاندارد |
| Approval خارج سیستم | Approval ثبتشده |
| SLA نامشخص | SLA بر اساس Service |
| Assignment دستی | Routing خودکار |
| گزارش دشوار | داده ساختاریافته |
ServiceDesk Plus چه امکاناتی برای Service Request دارد؟
ServiceDesk Plus از Service Catalog، Request Template، Approval، SLA، Workflow و Automation برای مدیریت Service Request پشتیبانی میکند. هدف عملی این قابلیتها این است که هر Service Definition به یک Workflow اجرایی تبدیل شود.
برای مشاهده مسیر تجاری محصول، صفحه ServiceDesk Plus مدانت مرجع اصلی لایسنس، استقرار و خدمات سفارشیسازی است.
از کجا شروع کنیم؟
اشتباه رایج این است که پروژه با ساخت صدها Service Item شروع شود. بهتر است ابتدا ۱۰ تا ۲۰ درخواست پرتکرار و پرهزینه انتخاب شوند.
کاندیدهای مناسب
- ایجاد حساب کاربری؛
- دسترسی VPN؛
- درخواست نرمافزار؛
- تجهیزات کاربر جدید؛
- افزایش دسترسی؛
- درخواست خرید؛
- Reset یا Unlock تخصصی؛
- Onboarding و Offboarding.
فرم خوب باید چه ویژگیای داشته باشد؟
فرم Service Request باید فقط اطلاعات لازم را بگیرد. فیلد زیاد باعث Abandonment میشود و فیلد کم باعث رفتوبرگشت با کاربر میشود.
| نوع فیلد | کاربرد |
|---|---|
| Required | اطلاعات ضروری برای Fulfillment |
| Conditional | فقط وقتی شرط خاص برقرار است |
| Hidden/Derived | داده داخلی سیستم |
| Approval Context | هزینه، مدیر، واحد، سطح دسترسی |
Approval را به تعداد مرحلهها تبدیل نکنید
Approval بیشتر الزاماً کنترل بهتر نیست. اگر هر درخواست ساده سه تأیید بخواهد، کاربران مسیر رسمی را دور میزنند. Approval باید بر اساس Risk، Cost و Access Level طراحی شود.
نمونه
- نرمافزار رایگان استاندارد: بدون Approval؛
- نرمافزار لایسنسدار: مدیر + Asset/License Owner؛
- دسترسی ممتاز: مدیر + Security؛
- خرید سرمایهای: مدیر + Procurement/Finance.
SLA باید با Service واقعی مرتبط باشد
SLA واحد برای همه درخواستها اشتباه است. تهیه لپتاپ، ساخت User و فعالسازی VPN زمانهای متفاوت دارند. هر Catalog Item باید Target مشخص داشته باشد.
Automation کجا بیشترین ارزش را میدهد؟
Automation زمانی ارزش دارد که Task یا تصمیم تکراری باشد. ServiceDesk Plus میتواند Routing، Notification، Task و Workflow را استاندارد کند و از Integration برای اجرای عملیات بیرونی استفاده کند.
اگر سازمان به Integrationهای سفارشی نیاز دارد، مقاله Webhook در ServiceDesk Plus خوشه مرتبطی برای اتصال ITSM به سیستمهای دیگر است.
Service Catalog و Onboarding
Onboarding مثال خوبی از Service Request چندمرحلهای است. HR درخواست را آغاز میکند، Manager نقش را مشخص میکند، IT Account و Device را آماده میکند و Security Access را کنترل میکند.
برای سمت Identity Automation، Onboarding و Offboarding با ADManager Plus میتواند مکمل این فرآیند باشد.
Catalog را بر اساس زبان کاربر طراحی کنید
نامهایی مثل «Provisioning Tier-2 Identity Resource» برای تیم IT قابل فهماند، اما برای کاربر خوب نیستند. عنوان سرویس باید بر اساس Intent کاربر نوشته شود: «درخواست دسترسی VPN» یا «درخواست لپتاپ برای نیروی جدید».
تفکیک Service Request از Incident
Incident یعنی چیزی خراب شده؛ Service Request یعنی کاربر چیزی استاندارد میخواهد. اگر این دو با هم مخلوط شوند، SLA، Reporting و Workflow خراب میشود.
دانشنامه تفاوت Incident و Service Request برای این تفکیک مفهومی مفید است.
سناریوی عملی: درخواست VPN
- کاربر Service «دسترسی VPN» را انتخاب میکند.
- فرم واحد سازمانی، مدت دسترسی و دلیل را میگیرد.
- مدیر مستقیم Approval میدهد.
- درخواست به Network/Security Assign میشود.
- Taskهای ایجاد Account و MFA اجرا میشوند.
- کاربر Notification دریافت میکند.
- پس از Validation، Request بسته میشود.
چه گزارشهایی بسازیم؟
- Top Requested Services؛
- Approval Delay؛
- Fulfillment Time؛
- SLA Breach by Service؛
- Reopen Rate؛
- Request Volume by Department؛
- Automation Coverage.
Catalog Governance
هر Service باید Owner داشته باشد. اگر Owner مشخص نباشد، فرم و SLA بهمرور قدیمی میشوند. بهتر است بازبینی دورهای برای Service Itemها تعریف شود.
چکلیست طراحی
- Service Owner مشخص است.
- نام سرویس با زبان کاربر نوشته شده است.
- فرم حداقل فیلد لازم را دارد.
- Approval مبتنی بر Risk است.
- SLA مستقل تعریف شده است.
- Assignment و Task Automation فعال است.
- Integrationهای لازم مشخصاند.
- KPI برای Service تعریف شده است.
- بازبینی دورهای Catalog انجام میشود.
نکات کلیدی
- Service Catalog باید کاربرمحور باشد.
- Approval زیاد معادل کنترل بهتر نیست.
- هر Service باید SLA و Owner داشته باشد.
- Automation را روی کارهای تکراری متمرکز کنید.
- Incident و Service Request را جدا نگه دارید.
منابع
- ManageEngine ServiceDesk Plus — Service Catalog
- ManageEngine — Service Catalog Administration
- ManageEngine ServiceDesk Plus — Product Overview
سخن پایانی
Service Catalog موفق فقط یک صفحه زیبا در Portal نیست؛ باید درخواست مبهم را به Workflow استاندارد، قابل اندازهگیری و قابل Automation تبدیل کند. ServiceDesk Plus این مسیر را با فرم، Approval، SLA، Task و Integration فراهم میکند.
مدانت خدمات خرید و تمدید لایسنس ServiceDesk Plus، طراحی Service Catalog، سفارشیسازی فرم و Workflow، Approval، SLA، Integration، فارسیسازی، تقویم شمسی، آموزش و پشتیبانی ارائه میکند. برای بررسی پروژه به ServiceDesk Plus مدانت یا تماس با مدانت مراجعه کنید.
