ServiceDesk Plus
فرض کنید ServiceDesk Plus چند سال است در واحد فناوری اطلاعات سازمان شما خوب کار میکند. کاربران درخواست ثبت میکنند، تیم IT پاسخ میدهد، SLA دارید و همه چیز تا حد زیادی مرتب است. حالا منابع انسانی میگوید: «ما هم میخواهیم درخواست گواهی اشتغال، جذب نیرو و امور پرسنلی را در همین سامانه داشته باشیم.» مالی هم میگوید: «پس تنخواه، پرداخت و پیگیری اسناد را هم اضافه کنیم.» واحد اداری هم فرمهای تعمیرات، کارت تردد و خدمات ساختمان را میخواهد.
اینجا یک سؤال کاملاً منطقی مطرح میشود:
واقعاً چرا باید سراغ ESM برویم؟
نمیشود در همان ServiceDesk Plus چند فرم بسازیم، تکنسینهای واحدهای دیگر را اضافه کنیم و کاری کنیم فقط درخواستهای واحد خودشان را ببینند؟
پاسخ کوتاه: بله، میشود. و اتفاقاً برای خیلی از سازمانها همین روش نقطه شروع منطقیتری است. اما این مدل با ESM یکی نیست. تفاوت اصلی از جایی شروع میشود که واحدهای غیر IT دیگر فقط چند فرم و چند پاسخگو نیستند و میخواهند واقعاً مثل یک مرکز خدمات مستقل کار کنند.
سناریو: یک ServiceDesk و چهار واحد سازمانی
شرکتی با ۵۰۰ کارمند را تصور کنید. واحد IT هفت تکنسین دارد. منابع انسانی سه کارشناس دارد، مالی دو کارشناس و واحد اداری هم دو نفر را برای رسیدگی به درخواستها معرفی کرده است.
در ServiceDesk Plus معمولی میتوان برای هر واحد Support Group ساخت، فرمها و Service Templateهای مخصوص طراحی کرد، با Business Rule درخواست هر فرم را به گروه مربوط فرستاد و برای تکنسینها Role تعریف کرد تا فقط درخواستهای گروه خودشان را ببینند.
یعنی میشود چنین ساختاری داشت:
- گروه IT با تکنسینهای شبکه، زیرساخت و نرمافزار
- گروه منابع انسانی با کارشناسان HR
- گروه مالی با کارشناسان مالی
- گروه خدمات اداری با پاسخگویان همان واحد
فرم «درخواست گواهی اشتغال» مستقیماً به HR میرود. فرم «درخواست پرداخت» به مالی میرود. فرم «خرابی لپتاپ» هم همچنان برای IT است. پس اگر نیاز شما فقط این باشد که کارشناس HR تیکتهای شبکه را نبیند و کارشناس IT هم وارد امور HR نشود، الزاماً از روز اول به ESM نیاز ندارید.
پس ESM دقیقاً چه چیزی را عوض میکند؟
در مدل ساده، همه این گروهها هنوز داخل یک Service Desk Instance قرار دارند. یعنی چند بخش داخل یک محیط مشترک ساختهاید. ESM یک لایه بالاتر میرود: هر واحد میتواند Service Desk Instance مستقل خودش را داشته باشد؛ مثلاً IT، منابع انسانی، مالی، تدارکات یا Facilities.
هر Instance میتواند فرمها، کاتالوگ خدمات، SLA، Workflow، تکنسینها، نقشها و تنظیمات خودش را داشته باشد، در حالی که کاربر نهایی از یک پرتال سازمانی به سرویسهایی که مجاز است دسترسی پیدا میکند.
به زبان ساده: در ServiceDesk معمولی چند میز را داخل یک اتاق بزرگ جدا میکنید. در ESM برای هر واحد یک اتاق مستقل میسازید، ولی ورودی ساختمان برای کاربر یکی باقی میماند.
تفاوت ServiceDesk Plus و ServiceDesk Plus ESM در یک نگاه
| موضوع | ServiceDesk Plus در یک Instance | ServiceDesk Plus با ESM |
|---|---|---|
| ساختار | همه واحدها داخل یک Service Desk هستند و با Group و Role تفکیک میشوند. | برای هر واحد میتوان Service Desk Instance مستقل داشت. |
| فرمها و کاتالوگ خدمات | فرمهای IT، HR، مالی و اداری در یک ساختار مشترک ساخته میشوند. | هر Instance کاتالوگ و فرمهای خودش را دارد. |
| تکنسینها | تکنسینهای واحدهای مختلف در همان سرویسدسک تعریف و با گروه و Role محدود میشوند. | هر Instance تکنسینهای خودش را دارد و دسترسی بین Instanceها مستقل است. |
| محرمانگی | با Role و Group میتوان دید را محدود کرد، اما محیط مدیریتی مشترک است. | مرز داده و فرایند در سطح Instance ایجاد میشود؛ مناسب اطلاعات حساستر. |
| مدیریت | مدیریت عمدتاً متمرکز است. | هر واحد میتواند مدیریت عملیاتی مستقلتری داشته باشد. |
| SLA و Workflow | قابل تفکیک است، ولی همه تنظیمات در یک فضای مشترک نگهداری میشوند. | هر واحد SLA و Workflow متناسب با مدل کاری خودش دارد. |
| پرتال کاربر | کاربر یک سرویسدسک با سرویسهای مختلف میبیند. | پرتال ESM دسترسی یکپارچه به Service Deskهای مرتبط را فراهم میکند. |
| گزارش | تفکیک بیشتر با Group و Filter انجام میشود. | هر Service Desk استقلال بیشتری در عملیات و گزارش دارد. |
| سادگی | سادهتر و مناسب شروع. | ساختارمندتر و مناسب رشد چند واحد خدماتی. |
پاسخ روشن به سؤال تکنسینهای واحدهای دیگر
بله؛ میتوانید تکنسینهای منابع انسانی، مالی یا اداری را در همان ServiceDesk Plus اضافه کنید و دسترسی آنها را محدود کنید تا فقط درخواستهای گروه خودشان را ببینند.
برای مثال سه کارشناس HR را عضو Support Group منابع انسانی میکنید و Role آنها را روی مشاهده درخواستهای گروه یا درخواستهای تخصیصیافته محدود میکنید. تیم IT هم ساختار خودش را حفظ میکند و قرار نیست با اضافه شدن تکنسینهای HR، تکنسینهای IT جابهجا یا حذف شوند.
این مدل برای شروع، اثبات نیاز و حتی برخی سازمانهای کوچک و متوسط کاملاً مناسب است.
اما یک نکته مهم وجود دارد: HR در این حالت هنوز «یک سرویسدسک مستقل» نیست؛ فقط یک گروه در همان Instance است. وقتی نیازهای واحدها پیچیدهتر شوند، این تفاوت اهمیت پیدا میکند.
چه زمانی همان ServiceDesk معمولی کافی است؟
فرض کنید منابع انسانی فقط سه فرم دارد:
- درخواست گواهی اشتغال
- درخواست معرفینامه
- اصلاح اطلاعات پرسنلی
حجم درخواستها پایین است، اطلاعات فوقمحرمانهای در تیکتها ثبت نمیشود، همان مدیر IT مدیریت نرمافزار را انجام میدهد و HR فقط میخواهد دو یا سه کارشناسش درخواستهای خودش را ببیند.
در این حالت ساخت Instance جدا ممکن است بیش از نیاز شما باشد. میتوانید:
- یک Support Group برای HR بسازید.
- تکنسینهای HR را فقط به همان گروه متصل کنید.
- Role آنها را محدود کنید.
- Service Templateهای HR را طوری طراحی کنید که درخواست مستقیماً به گروه HR برود.
- برای Finance و Facilities نیز در صورت نیاز همین الگو را تکرار کنید.
این معماری هم ساده است، هم سریع و هم برای شروع هزینه و پیچیدگی کمتری دارد.
چه زمانی وقت رفتن به ESM رسیده است؟
حالا همان سازمان را شش ماه بعد تصور کنید. HR علاوه بر گواهی اشتغال، درخواست حقوق و مزایا، شکایت کارکنان، ارزیابی عملکرد، جذب و خروج نیرو را مدیریت میکند. مالی اسناد پرداخت و اطلاعات قراردادها را ثبت میکند. اداری درخواست کارت دسترسی و جابهجایی اتاق را مدیریت میکند. هر مدیر هم داشبورد، SLA و گردش تأیید خودش را میخواهد.
اینجا دیگر موضوع فقط «چند فرم اضافه» نیست.
۱. وقتی دادهها حساساند
درخواست خرابی پرینتر با پرونده شکایت پرسنلی یا اطلاعات مالی یک جنس نیست. هرچه محرمانگی و حساسیت داده بیشتر باشد، جداسازی در سطح Instance منطقیتر میشود.
۲. وقتی هر واحد صاحب فرایند خودش است
IT با Incident، Problem و Change کار میکند. HR چرخه جذب، خروج و امور پرسنلی دارد. مالی گردش تأیید پرداخت دارد. Facilities با تعمیرات، فضای فیزیکی و دسترسی ساختمان سروکار دارد. این تفاوتها در ابتدا با چند فرم حل میشوند، اما بعد به فرایندهای مستقل تبدیل میشوند.
۳. وقتی مدیر هر واحد استقلال میخواهد
اگر مدیر منابع انسانی بخواهد فرمها، SLAها، Technicianها و گردشکارهای خودش را مدیریت کند، منطقی نیست برای هر تغییر کوچک منتظر Admin واحد IT بماند. این یکی از نقاطی است که ESM ارزش عملیاتی پیدا میکند.
۴. وقتی کاتالوگ خدمات شلوغ شده است
اگر کاربر در یک صفحه با دهها فرم IT، مالی، اداری و HR روبهرو شود، تجربه کاربری ضعیف میشود. معماری ESM کمک میکند سرویسها بر اساس Service Desk مربوط منظم شوند، در حالی که نقطه ورود کاربر همچنان یکپارچه باقی میماند.
۵. وقتی گزارشها باید واقعاً مستقل باشند
تا وقتی چند فرم محدود دارید، فیلتر گزارش بر اساس Group کافی است. اما وقتی هر واحد KPI، SLA، Owner، فرایند و سیاست خودش را دارد، استقلال Service Deskها برای مدیریت و گزارشگیری ارزش زیادی پیدا میکند.
سناریوی استخدام یک نیروی جدید
این سناریو خیلی خوب تفاوت ITSM و ESM را نشان میدهد.
قرار است یک نیروی جدید شنبه وارد سازمان شود. HR باید اطلاعات او را ثبت کند. IT باید لپتاپ، حساب کاربری و ایمیل آماده کند. واحد اداری باید کارت تردد بدهد. مالی هم باید اطلاعات حساب و حقوق را ثبت کند.
از دید کارمند این فقط یک اتفاق است: ورود به سازمان.
اما پشت صحنه چهار نوع خدمت با چهار مالک متفاوت وجود دارد. در یک سازمان کوچک میتوان این کار را با Task، Group و Business Rule در همان ServiceDesk مدیریت کرد. وقتی سازمان بزرگتر میشود، منطقیتر است هر واحد Service Desk خودش را داشته باشد و فرایندهای بین واحدی با طراحی مشخص به هم متصل شوند.
آیا یک تکنسین میتواند در دو Instance باشد؟
بله، اگر واقعاً نیاز عملیاتی وجود داشته باشد. اما دسترسی Technician در هر Instance مستقل است. تکنسین IT صرفاً به خاطر Technician بودن در IT، به Instance منابع انسانی دسترسی خودکار ندارد.
اگر فردی باید در دو Service Desk نقش Technician داشته باشد، دسترسی و لایسنس لازم برای هر Instance باید بررسی شود. این استقلال یکی از تفاوتهای مهم ESM با مدل چند Group در یک ServiceDesk است.
آیا ESM یعنی همه واحدها با هم قاطی میشوند؟
خیر؛ اتفاقاً فلسفه اصلی ESM این است که تجربه کاربر یکپارچه باشد، اما مالکیت سرویسها و دادهها مرزبندی مشخص داشته باشد.
کاربر فقط میگوید «من یک خدمت میخواهم». او نباید نگران باشد پشت صحنه کدام تیم مسئول آن است. اما سازمان باید بداند:
- مالک این خدمت کدام واحد است؟
- چه کسانی مجازند درخواست را ببینند؟
- چه SLAای اعمال میشود؟
- چه کسی باید تأیید کند؟
- گزارش این سرویس متعلق به چه مدیری است؟
ESM این مرزبندی را ساختاریتر میکند.
پیشنهاد عملی: مهاجرت مرحلهای، نه یکباره
برای بسیاری از سازمانها بهترین تصمیم این نیست که از همان روز اول همه واحدها را ESM کنند. مسیر منطقیتر میتواند سه مرحله داشته باشد.
مرحله اول: اثبات نیاز
مثلاً HR را با چند فرم، یک Support Group و دو یا سه تکنسین در همان ServiceDesk فعلی راهاندازی کنید. دسترسیها را محدود و حجم درخواستها را اندازهگیری کنید.
مرحله دوم: تشخیص نشانههای استقلال
اگر HR به SLA متفاوت، Workflowهای چندمرحلهای، گزارش مستقل، مدیریت جدا یا محرمانگی بیشتر رسید، آن را بهعنوان کاندید ESM در نظر بگیرید.
مرحله سوم: Service Desk مستقل
برای HR یک Instance مستقل ایجاد کنید و همین منطق را برای Finance، Facilities یا واحدهای دیگر تکرار کنید. IT هم Service Desk خودش را حفظ میکند.
برای سازمان شما کدام مدل منطقیتر است؟
| وضعیت | معماری مناسبتر |
|---|---|
| فقط چند فرم محدود برای HR یا اداری دارید | همان ServiceDesk + Group + Role |
| تعداد تکنسینهای غیر IT کم است و مدیریت مرکزی مشکلی ندارد | همان ServiceDesk |
| فقط میخواهید تکنسین HR تیکتهای HR را ببیند | Group + Role معمولاً کافی است |
| HR، مالی یا حقوقی دادههای حساس و سیاست مستقل دارند | ESM منطقیتر است |
| هر واحد مدیر، SLA، Workflow و کاتالوگ خدمات مستقل میخواهد | ESM |
| کاربر باید از یک پرتال به چند مرکز خدمات سازمانی دسترسی داشته باشد | ESM |
| هنوز مطمئن نیستید | از Group شروع کنید و بر اساس رشد واقعی مهاجرت کنید |
سخن پایانی
ServiceDesk Plus معمولی آنقدر انعطاف دارد که بتوانید واحدهای دیگر را هم با فرم، Group، Role و Technicianهای مخصوص وارد سامانه کنید. بنابراین پاسخ سؤال اصلی این مقاله مثبت است: بله، میتوانید تکنسینهای واحدهای دیگر را اضافه کنید و دسترسی آنها را فقط به درخواستهای همان واحد محدود کنید.
اما ESM زمانی ارزش واقعی پیدا میکند که دیگر مسئله شما «چند فرم جدید» نباشد؛ بلکه چند واحد سازمانی بخواهند مثل یک Service Desk واقعی، با داده، مدیریت، فرایند و کاتالوگ خدمات مستقل کار کنند.
اگر فقط چند میز جدید میخواهید، همان اتاق فعلی را مرتب کنید. اگر HR، مالی و اداری هرکدام باید اتاق خودشان را داشته باشند ولی کاربر از یک ورودی مشترک وارد ساختمان شود، آن وقت ESM همان معماری درست است.
سناریوی سازمان خودتان را بررسی کنید
اگر نمیدانید ساختار فعلی ServiceDesk Plus شما با Group و Role قابل گسترش است یا بهتر است Instanceهای ESM طراحی شوند، قبل از خرید لایسنس اضافه، تعداد تکنسینها، محرمانگی داده، گردشکارها و استقلال مدیریتی واحدها را بررسی کنید.
درخواست جلسه بررسی و دمو · معرفی ServiceDesk Plus · آموزش ServiceDesk Plus
منابع رسمی
- Enterprise Service Management در ServiceDesk Plus
- استفاده از ServiceDesk Plus برای واحدهای مختلف سازمان
- تفکیک واحدها با Technician Group و Role
- Role و Access Control برای تکنسینها
