Request Life Cycle در ServiceDesk Plus؛ کنترل مسیر تیکت از ثبت تا بسته‌شدن

یکی از مشکلات رایج Service Desk این است که Statusها زیاد می‌شوند اما هیچ‌کس دقیقاً نمی‌داند یک درخواست از چه وضعیتی می‌تواند به کدام وضعیت برود. یک Technician مستقیماً Ticket را از Open به Closed می‌برد، دیگری آن را بین چند وضعیت جابه‌جا می‌کند و در پایان گزارش‌ها قابل اعتماد نیستند. Request Life Cycle در ServiceDesk Plus برای حل همین آشفتگی ساخته شده است.

Request Life Cycle یا RLC به شما اجازه می‌دهد مسیر حرکت Request را تعریف کنید؛ یعنی مشخص کنید چه Statusهایی وجود دارند، Transitionهای مجاز چیست، چه کسی اجازه اجرای هر Transition را دارد و در چه شرایطی حرکت به مرحله بعد ممکن است.

چرا Status به‌تنهایی کافی نیست؟

داشتن Statusهایی مثل Open، In Progress، On Hold، Resolved و Closed فقط نام‌گذاری مرحله‌هاست. بدون Life Cycle، Technician می‌تواند بسته به Permission یا تنظیمات، میان وضعیت‌ها آزادانه حرکت کند. این آزادی در تیم کوچک شاید مسئله نباشد، اما در سازمان بزرگ باعث از بین رفتن کنترل فرایند می‌شود.

RLC Status را به Workflow تبدیل می‌کند. در نتیجه «Resolved» دیگر فقط یک انتخاب از Drop-down نیست؛ یک مرحله است که رسیدن به آن می‌تواند نیازمند Resolution، Worklog، Approval یا شرط‌های خاص باشد.

Request Life Cycle از چه اجزایی ساخته می‌شود؟

هسته RLC شامل Statusها و Transitionهاست. Status نشان می‌دهد Request اکنون در چه مرحله‌ای قرار دارد. Transition مشخص می‌کند حرکت از یک Status به Status دیگر تحت چه شرایطی مجاز است.

در Transition می‌توان نقش اجراکننده، شرط، Action و محدودیت‌های لازم را تعریف کرد. نتیجه این است که Workflow فقط روی کاغذ نیست؛ خود نرم‌افزار آن را Enforcement می‌کند.

نمونه ساده؛ از Open تا Closed

فرض کنید مسیر استاندارد شما چنین باشد: Open → Assigned → In Progress → Resolved → Closed. اگر بدون RLC کار کنید، ممکن است Technician از Assigned مستقیم به Closed برود. با RLC می‌توانید این مسیر را محدود کنید و بگویید Closed فقط بعد از Resolved امکان‌پذیر است.

همچنین می‌توانید مسیر بازگشت تعریف کنید. مثلاً اگر کاربر Resolution را نپذیرفت، درخواست از Resolved دوباره به In Progress برگردد.

Transition چیست؟

Transition همان دروازه بین دو Status است. هر Transition می‌تواند نام معنادار داشته باشد، مثل Start Work، Resolve، Reopen یا Close. این نام‌گذاری برای Technician بهتر از تغییر مستقیم Status است، چون Action واقعی را نمایش می‌دهد.

وقتی Technician روی Resolve کلیک می‌کند، سیستم می‌تواند قبل از تغییر Status بررسی کند آیا Resolution تکمیل شده، فیلدهای اجباری پر شده‌اند و شرایط مورد نیاز برقرار هستند یا نه.

نقش‌ها و Permission در RLC

همه Transitionها نباید برای همه قابل اجرا باشند. ممکن است Start Work را Technician اجرا کند، Approve Closure را Supervisor و Reopen را Requester یا Technician مجاز.

این مدل کمک می‌کند Workflow سازمانی بدون دادن Permissionهای بیش از حد اجرا شود. اصل Least Privilege فقط برای امنیت نیست؛ برای کنترل فرایند نیز مهم است.

شرط‌ها چه کاربردی دارند؟

Conditionها اجازه می‌دهند Transition فقط در وضعیت خاصی فعال شود. مثلاً اگر Category برابر Security Incident باشد، بستن Ticket بدون تأیید Security Team مجاز نباشد. یا اگر Priority برابر High است، Escalation و Review اضافی فعال شود.

با این روش لازم نیست برای هر سناریو Template کاملاً جداگانه بسازید؛ بخشی از منطق را می‌توان در Lifecycle کنترل کرد.

RLC و Approval

در Requestهایی که Approval دارند، Life Cycle می‌تواند جلوی عبور زودهنگام را بگیرد. مثلاً درخواست خرید نرم‌افزار تا زمانی که Approval Manager و Finance انجام نشده، وارد Fulfillment نشود.

این کنترل باعث می‌شود Technician مجبور نباشد دستی وضعیت Approval را بررسی کند. Workflow باید خودش مانع حرکت غیرمجاز شود.

RLC و Service Catalog

قدرت واقعی RLC زمانی دیده می‌شود که برای Service Catalog طراحی شود. هر Service Request می‌تواند مسیر مشخصی داشته باشد. درخواست لپ‌تاپ، دسترسی VPN و نصب نرم‌افزار الزاماً Lifecycle یکسان ندارند.

برای طراحی Catalog می‌توانید مقاله Service Catalog در ServiceDesk Plus را هم ببینید.

RLC و SLA

Life Cycle نباید طوری طراحی شود که SLA را پنهان کند. مثلاً On Hold اگر بی‌قاعده استفاده شود، می‌تواند Resolution Time را مصنوعی بهتر نشان دهد. بنابراین باید دقیقاً مشخص باشد چه Transitionهایی Request را وارد Hold می‌کنند و چه کسی اجازه دارد این کار را انجام دهد.

برای کنترل Escalationها، مقاله SLA Escalation در ServiceDesk Plus مکمل خوبی است.

طراحی بد RLC چه شکلی است؟

یکی از بدترین طراحی‌ها، Lifecycle بسیار شلوغ با ده‌ها Status و Transition است. Technician به‌جای حل مسئله باید مسیر Workflow را حفظ کند. اصل خوب این است که فقط Stageهایی را ایجاد کنید که ارزش مدیریتی، کنترلی یا گزارشی دارند.

اگر دو Status در عمل هیچ تفاوتی در مسئولیت، SLA یا Action ندارند، احتمالاً یکی از آن‌ها اضافی است.

سناریو؛ درخواست دسترسی

فرض کنید کاربر درخواست دسترسی به یک Application حساس می‌دهد. مسیر می‌تواند New → Manager Approval → Security Review → Fulfillment → Verification → Closed باشد. هر Transition Owner مشخص دارد.

اگر Manager رد کند، درخواست به Rejected می‌رود. اگر Security نیاز به اطلاعات بیشتر داشته باشد، به Need More Info برمی‌گردد. این مسیر در RLC قابل دیدن و کنترل است و دیگر به حافظه Technician وابسته نیست.

RLC و Audit

وقتی Transitionها کنترل‌شده باشند، Audit Trail معنی بیشتری پیدا می‌کند. می‌توان دید چه کسی، چه زمانی و از چه مرحله‌ای Request را عبور داده است. برای محیط‌های Compliance این موضوع مهم‌تر از ظاهر Workflow است.

چطور RLC را طراحی کنیم؟

قبل از ورود به نرم‌افزار، مسیر واقعی Request را روی کاغذ بکشید. Statusها، تصمیم‌ها، Approverها و Exceptionها را مشخص کنید. سپس فقط بخش‌هایی را وارد ابزار کنید که نیاز به Enforcement دارند.

بهتر است ابتدا روی یک Service Request پرتکرار Pilot کنید و بعد Lifecycle را گسترش دهید.

KPIهای مناسب

بعد از اجرا، تعداد Reopen، زمان ماندن در هر Stage، تعداد Transitionهای برگشتی، درصد Requestهای بسته‌شده بدون Resolution و تعداد Exceptionها را بررسی کنید. اگر کاربران دائماً Workflow را دور می‌زنند، مشکل از آموزش یا طراحی است.

RLC با Workflow Automation چه تفاوتی دارد؟

Automation می‌تواند Assignment، Notification یا Field Update انجام دهد. RLC روی کنترل State Transition تمرکز دارد. این دو مکمل‌اند. Life Cycle می‌گوید چه حرکتی مجاز است؛ Automation می‌تواند هنگام آن حرکت Action لازم را اجرا کند.

چه زمانی RLC ارزش بیشتری دارد؟

در سازمان‌هایی با Technician زیاد، شیفت‌های مختلف، Audit Requirement، Service Catalog گسترده یا Workflowهای Approval، RLC ارزش زیادی دارد. در Help Desk بسیار کوچک شاید طراحی پیچیده آن لازم نباشد.

سخن پایانی

Request Life Cycle ابزاری برای زیباترکردن Workflow نیست؛ راهی است برای تبدیل قواعد عملیاتی به رفتار واقعی نرم‌افزار. وقتی Statusها، Transitionها و مسئولیت‌ها روشن باشند، گزارش‌ها معتبرتر می‌شوند، خطای انسانی کم می‌شود و Technician دقیقاً می‌داند مرحله بعد چیست.

اگر قصد دارید ServiceDesk Plus را از Ticketing ساده به ITSM کنترل‌شده تبدیل کنید، RLC یکی از قابلیت‌هایی است که باید جدی بگیرید. برای شناخت کامل‌تر محصول، راهنمای ServiceDesk Plus را ببینید.

منابع

ManageEngine ServiceDesk Plus Help
ManageEngine ServiceDesk Plus