زمان تقریبی مطالعه: 3 دقیقهروزانه درخواست‌های متنوعی برای واحد فناوری اطلاعات ارسال می‌شود و با توجه به تنوع سرویس‌های ارائه شده در سازمان‌ها و تفاوت بین انواع درخواست‌هایی که مشتریان در ارتباط با سرویس‌ها دارند، تبیین فرآیند انجام درخواست در سازمان‌های سرویس‌دهنده به منظور شناسایی و برآورده کردن نیازهای مشتریان، امری حیاتی است.
واژه‌ی Fulfillment در ITIL توصیفی کلی در باب رفع نیاز کاربران است و همچنین واژه Request توصیفی از اعلام نیاز و درخواست‌های کاربران است که شامل دریافت اطلاعات، راهنمایی و مشاوره یا درخواست‌های کوچکی است که ریسک و هزینه کمی برای سازمان دارد. برای مثال درخواستی مبنی بر افزایش حجم ایمیل.
فرآیند انجام درخواست مشتمل بر پنج بخش است:
- ایجاد کاتالوگ درخواست خدمات و پشتیبانی از ارائه خدمات جهت انجام درخواست‌ها به گونه‌ای اثربخش
- دسته‌بندی درخواست‌ها، بررسی نیاز به دریافت تاییدیه از واحدهای مختلف از جمله مالی و تطابق آن با استانداردها و پارامترها و تعهدات قراردادی
- چگونگی تکمیل درخواست پس از تأیید یا رد و نهایتاً اجرای مدل درخواست در زمان تعهد شده
- نظارت بر مراحل انجام درخواست و ارجاعات آن
- بستن درخواست پس از انجام آن و ارزیابی میزان رضایت کاربران
می‌توانیم برای سنجش کارآیی و اثربخشی این فرآیند شاخص‌های کلیدی مختلفی تعریف کنیم و با تجزیه و تحلیل KPIها تصویر دقیقی از فرآیند به دست آوریم.
برخی از این شاخص‌ها به شرح زیر است:
- کاربران شما تا چه میزان از نحوه رسیدگی به درخواست‌هایشان رضایت دارند؟
- رسیدگی به هر درخواست چقدر زمان می‌برد؟
- میزان هزینه (به طور میانگین بر حسب نوع درخواست سرویس) چقدر است؟
- چه تعداد درخواست در چارچوب SLA انجام شده است؟
- درخواست‌های تائید نشده چه تعدادی است؟
و شاخص‌های دیگری که بر حسب نوع درخواست‌های سازمان شما می‌تواند تعریف شود.
مرز باریک میان فرآیندها
باید در نظر داشت تمامی تماس‌هایی که با واحد فناوری اطلاعات برقرار می‌شود، از نوع درخواست نیستند! باید آن‌ها را بر اساس مدل‌های تعریف‌شده از هر فرآیند بررسی و سپس در قالب فرآیند متناظر پاسخ داد. لکن تشخیص اینکه در اساس کدام فرآیند باید بررسی و پاسخ داده شود، همیشه ساده نیست!
گاهی خرابی در سیستم گزارش می‌شود که باعث کاهش بیش از حد کیفیت سرویس یا توقف در ادامه کار سرویس می‌شود که در فرآیند مدیریت رخداد جای دارد.
البته زمانی که سرویس توسط سازمان سرویس دهنده برای انجام فعالیتی مشخص و در مدت زمانی از پیش تعیین شده قطع می‌شود، رخداد تلقی نمی‌شود.
ضمناً باید در نظر داشت هر سازمانی درخواست‌های خاص خودش را دارد و این درخواست‌ها الزاما باعث قطعی سرویس و تغییرات اساسی نمی‌شود و صرفاً اقداماتی تعیین شده بر اساس برنامه‌ریزی انجام می‌گیرد.
گاهاً ممکن است موردی در یک سازمان از جنس Request و در سازمان دیگر Normal Change باشد که باید در کمیته CAB بررسی شود.
این تفاوت‌ها ناشی از نحوه تعریف سطوح ریسک در سازمان‌ها می‌باشد که باعث می‌شود موردی در یک سازمان با ریسک کم تلقی و در فرآیند انجام درخواست بررسی شود و در سازمان دیگر ریسک بالایی داشته باشد و وارد فرآیند مدیریت تغییر شود.
برای درک این موضوع با ارائه یک مثال ادامه می‌دهیم:
کاربری درخواست جابجایی یک دستگاه را به میز خدمت ارسال می‌کند، در این شرایط ممکن است یک سازمان با توجه به شاخص‌های مطرح شده در دسته‌بندی ریسک‌ها، مورد فوق را با ریسک کمی در نظر بگیرد و در فرآیند انجام درخواست، آن را بررسی کند و در سازمان دیگر این مورد با قرار گرفتن در سطوح بالاتری از ریسک، به عنوان یک Normal Change در فرآیند مدیریت تغییر بررسی شود.
از فرآیند انجام درخواست چه انتظاری داریم؟
در فرآیند انجام درخواست ، میزان پیچیدگی و بروکراسی‌های ناشی از درخواست‌های کاربران به وسیله اعطای دسترسی به آنان کاهش می‌یابد و همچنین چگونگی تمرکز بر پاسخ‌دهی به درخواست‌های کاربران مشخص می‌شود. با توجه به ارتباط فرآیند انجام درخواست با فرآیند مدیریت مالی، با درک هزینه‌های سرویس و میزان منابع و حجم کاری که صرف تکمیل درخواست می‌شود، درنهایت سبب افزایش کارآیی و بررسی و کاهش هزینه می‌شود.
همچنین می‌توان با حذف برخی فرآیندهای ساده و تکرارشونده زمان پاسخگویی به مشتریان را کاهش دهیم. البته هدف نهایی فرآیند انجام درخواست رضایت کاربران است.
این یادداشت در رسانه اینترنتی راه پرداخت نیز منتشر شده است.
برای مطالعه سایر یادداشت های همکاران گروه فناوری پرند در رسانه اینترنتی راه پرداخت، اینجا کلیک کنید.
