راه پرداخت
رسانه فناوری‌های مالی ایران

چرا به فرآیند Request Fulfillment (تحقق درخواست) نیاز داریم؟

پروین اشرفی پور؛ مسئول فروش و امور مشتریان گروه فناوری پرند / روزانه درخواست‌های متنوعی برای واحد فناوری اطلاعات ارسال می‌شود و با توجه به تنوع سرویس‌های ارائه شده در سازمان‌ها و تفاوت بین انواع درخواست‌هایی که مشتریان در ارتباط با سرویس‌ها دارند، تبیین فرآیند مدیریت درخواست در سازمان‌های سرویس‌دهنده جهت شناسایی و برآورده کردن نیازهای مشتریان، امری حیاتی است.

واژه  Fulfillment در ITIL  به عنوان توصیف کلی از رفع نیاز کاربران تعریف می‌شود و همچنین واژه Request  به عنوان توصیفی از اعلام نیاز و درخواست‌هاي کاربران شامل دریافت اطلاعات، راهنمایی و مشاوره یا درخواست‌های کوچکی که ریسک و هزینه کمی برای سازمان دارد، در نظر گرفته می‌شود؛ برای مثال درخواستی مبنی بر افزایش حجم ایمیل.

فرآیند تحقق درخواست مشتمل بر پنج بخش است:

  • ایجاد کاتالوگ درخواست خدمات و پشتیبانی از ارائه خدمات جهت انجام درخواست‌ها به گونه‌ای اثربخش
  • دسته‌بندی درخواست‌ها، بررسی نیاز به دریافت تاییدیه از واحدهای مختلف از جمله مالی و تطابق آن با استانداردها و پارامترها و تعهدات قراردادی 
  • چگونگی تکمیل درخواست پس از تأیید یا رد و نهایتاً اجراي مدل درخواست در زمان تعهد شده
  • نظارت بر مراحل انجام درخواست و ارجاعات آن 
  • بستن درخواست پس از تحقق آن و ارزیابی میزان رضایت کاربران

می‌توانیم برای سنجش کارآیی و اثربخشی این فرآیند شاخص‌های کلیدی مختلفی تعریف کنیم و با تجزیه و تحلیل KPIها تصویر دقیقی از فرآیند به دست آوریم.

برخی از این شاخص‌ها به شرح زیر است:

  • کاربران شما تا چه میزان از نحوه رسیدگی به درخواست‌هایشان رضایت دارند؟
  • رسیدگی به هر درخواست چقدر زمان می‌برد؟
  • میزان هزینه (به طور میانگین بر حسب نوع درخواست سرویس) چقدر است؟
  • چه تعداد درخواست‌ در چارچوب SLA انجام شده است؟
  • درخواست‌های تائید نشده چه تعدادی است؟

و شاخص‌های دیگری که بر حسب نوع درخواست‌های سازمان شما می‌تواند تعریف شود.

.

مرز باریک میان فرآیندها

باید در نظر داشت تمامی تماس‌هایی که با واحد فناوری اطلاعات برقرار می‌شود، از نوع درخواست نمی‌باشد! باید آن‌ها را بر اساس مدل‌های تعریف‌شده از هر فرآیند بررسی و سپس در قالب فرآیند متناظر پاسخ داد. لکن تشخیص اینکه در اساس کدام فرآیند باید بررسی و پاسخ داده شود، همیشه ساده نیست!

گاهی خرابی در سیستم گزارش می‌شود که باعث کاهش بیش از حد کیفیت سرویس یا توقف در ادامه کار سرویس می‌شود که در فرآیند مدیریت رخداد جای دارد. 

البته زمانی که سرویس توسط سازمان سرویس دهنده برای انجام فعالیتی مشخص و در مدت زمانی از پیش تعیین شده قطع می‌شود، رخداد تلقی نمی‌شود. 

در صورت تمایل به کسب اطلاعات بیشتر در این خصوص به مقاله مدیریت رخداد (Incident Management) چیست؟ مراجعه کنید.

ضمناً باید در نظر داشت هر سازمانی درخواست‌های خاص خودش را دارد و این درخواست‌ها الزاما باعث قطعی سرویس و تغییرات اساسی نمی‌شود و صرفاً اقداماتی تعیین شده بر اساس برنامه‌ریزی انجام می‌گیرد. 

گاهاً ممکن است موردی در یک سازمان از جنس Request  و در سازمان دیگر Normal Change  باشد که باید در کمیته CAB بررسی شود.

این تفاوت‌ها ناشی از نحوه تعریف سطوح ریسک در سازمان‌ها می‌باشد که باعث می‌شود موردی در یک سازمان با ریسک کم تلقی و در فرآیندRequest Fulfillment  بررسی شود و در سازمان دیگر ریسک بالایی داشته باشد و وارد فرآیندChange Management  شود.

برای درک این موضوع با ارائه یک مثال ادامه می‌دهیم:

کاربری درخواست جابجایی یک دستگاه را به میز خدمت ارسال می‌کند، در این شرایط ممکن است یک سازمان با توجه به شاخص‌های مطرح شده در دسته‌بندی ریسک‌ها، مورد فوق را با ریسک کمی در نظر بگیرد و در فرآیند تحقق درخواست، آن را بررسی کند و در سازمان دیگر این مورد با قرار گرفتن در سطوح بالاتری از ریسک، به عنوان یک Normal Change در فرآیند مدیریت تغییر بررسی شود.

.

از «مدیریت درخواست» چه می‌خواهیم؟

در این فرآیند، میزان پیچیدگی و بروکراسی‌های ناشی از درخواست‌های کاربران به وسیله اعطای دسترسی به آنان کاهش می‌یابد و همچنین چگونگی تمرکز بر پاسخ‌دهی به درخواست‌های کاربران مشخص می‌شود. با توجه به ارتباط فرآیند مدیریت درخواست با فرآیند مدیریت مالی، با درک هزینه‌های سرویس و میزان منابع و حجم کاری که صرف تکمیل درخواست می‌شود، نهایتاً باعث افزایش کارایی و بررسی و کاهش هزینه می‌شود.

همچنین می‌توان با حذف برخی فرآیندهای ساده و تکرارشونده زمان پاسخگویی به مشتریان را کاهش دهیم. البته هدف نهایی فرآیند مدیریت درخواست خدمات، رضایت کاربران است.

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.