هنگامی‌که سازمان‌ها شروع به پذیرش بهترین تمرینات ITSM می‌کنند و سفر طولانی به سمت بلوغ ITIL را آغاز می‌کنند، یکی از بزرگ‌ترین موانعی که مشتریان ما با آن مواجه می‌شوند، تعریف مناسب و مفهوم دقیق بین حوادث، درخواست‌های خدمات و مشکلات است. درحالی‌که ممکن است برای برخی این‌ها خیلی واضح به نظر برسد، بسیاری هنوز برای درک تفاوت‌ها و اهمیت درک هر یک از این فرایندهای عملیاتی تلاش می‌کنند.
نسخه 2 ITIL تفاوت زیادی بین حوادث و درخواست‌های خدمات ایجاد نکرد.
افرادی که به‌خوبی در نسخ قدیمی چارچوب ITIL آشنا هستند، به‌شدت استدلال می‌کنند که واقعاً هیچ تفاوتی وجود ندارد – و درخواست خدمات فقط یک نام فانتزی برای یک حادثه است-.
بااین‌حال، نسخه 3 ITIL به ما آموخت که درواقع تفاوت‌های متمایز و مهمی بین این دو نوع سوابق میز خدمات وجود دارد.
حوادث، به عبارت ساده، رویدادهایی هستند که منجر به وقفه در یک یا چند سرویس می‌شوند. درحالی‌که درخواست خدمات به‌طور خاص منجر به تخریب یا شکست مشابه نمی‌شود. در عوض، آنها نیازها یا آرزوهای پیشرفت یا تغییرات هستند. آنها به‌ندرت درخواست‌های تغییر واقعی را ایجاد می‌کنند (هرچند ممکن است). این شامل چیزهایی مانند گرفتن یک مانیتور جایگزین یا یک چاپگر دسکتاپ جدید است. درخواست برای چیزهایی مانند سیستم یا دسترسی به شبکه.
من شخصاً بزرگ‌ترین نقطه اختلاف بین حوادث و درخواست‌های سرویس را در: درخواست تنظیم مجدد رمز عبور حس کردم.
استدلال من همیشه این است که این‌یک درخواست خدمات است، درحالی‌که دیگران ممکن است آن را یک حادثه بدانند، زیرا توانایی فرد را برای انجام‌وظیفه اصلی خود کاهش می‌دهد.
بااین‌حال، سازمان به‌عنوان یک کل باید در مورد نوع این درخواست توافق کند. ما می‌توانیم بحث کنیم تا در پایان برای همه‌چیز اجماع وجود داشته باشد ولی خیلی در جزئیات گرفتار نشوید، تصمیم بگیرید که میز خدمات خود را بهبود بخشید و به جلو حرکت کنید.
سومین عضو این سه‌گانه‌ی گیج‌کننده مدیریت مشکل است.
تصورات غلط بی‌شماری در مورد آنچه یک مشکل است یا نه؟ شنیده‌ام و معتقدم که این دلیل اصلی استفاده کم از آن در عملیات خدمات است.
اول‌ازهمه، یک مشکل حتماً یک حادثه نیست. نه اصلاً. لزوماً یک حادثه تبدیل به یک مشکل نمی‌شود. مشکلات فقط حوادث “واقعاً تأثیرگذار” نیستند. هیچ نسبت جادویی از حادثه به مشکل وجود ندارد – من درواقع شنیده‌ام که کسی ادعا می‌کند که ITIL برای هر حادثه به یک مشکل نیاز دارد. و مشکلات حل نمی‌شود زمانی که قطع برق کاهش‌یافته است.
نه، سوءتفاهم پیش‌آمده هیچ‌یک از این چیزها نیست.
مشکل، مسئله‌ای است که علت اصلی آن هنوز مشخص نشده است. به‌عنوان‌مثال، یک سرور در نیمه‌شب خاموش شده یک مشکل است. این امر به‌ویژه اگر شواهد منطقی وجود داشته باشد که دوباره اتفاق خواهد افتاد. ممکن است یک حادثه مرتبط با آن مطرح شود اگر خاموشی باعث تخریب یا شکست یک سرویس شود، اما اگر زیرساخت‌های شما بسیار اضافی باشد، ممکن است اتفاق نیفتد.
یک خاموشی سرور به‌خودی‌خود یک مشکل را تشکیل می‌دهد. چرا سرور خراب شد؟ این سؤالی است که مدیریت مشکل همیشه می‌پرسد، “چرا؟” درحالی‌که مدیریت حادثه تنها بر بازگرداندن خدمات به همان سرعتی که منطقی است (مبارزه با علائم) متمرکزشده است، علاقه‌ای به اینکه چرا قطعی یا خاموشی رخ‌داده است (درک و از بین بردن علت) ندارد.
مدیریت مشکل یک عمل تحقیقاتی است که علت اصلی را مشخص می‌کند و به دنبال حل آن است تا از تکرار مشکل جلوگیری کند.
مشکلات می‌توانند راه‌حل‌هایی داشته باشند. گاهی اوقات راه‌حل دائمی می‌شود زیرا یا علت ریشه‌ای پیدا نمی‌شود، یا رفع علت ریشه‌ای به‌نوعی بیش‌ازحد سنگین خواهد بود (مالی، منابع عاقلانه و غیره). درحالی‌که یک حادثه همیشه باید حل شود. سرویس باید بازسازی شود.
بگذارید یک مثال روزمره بزنم.
فرض کنید خوش‌خوشان دارید می‌روید شمال با همسر گرامی یا بلانسبت با زید محترمه برای جوج‌زنی! که یکهو اتفاقی می‌افتد که نمی‌دانید اسمش را چه چیزی بگذارید؟
بچه‌های فناوری اطلاعات و خیلی از کاربران هنوز درگیر ۴ تا از مفاهیم ITIL هستند؛ البته حق هم دارند چون تاحدودی گیج کننده است!
آن اتفاق یکهویی، پنچر شدن لاستیک خودروی شماست!
به این، حادثه می‌گویند.
یک راه عالی برای درک تفاوت بین ۴ مفهوم: حوادث، درخواست‌ها و مشکلات و تغییرات این است که در مورد همین پنچری که برای لاستیک خودروی شما اتفاق افتاده بحث کنیم.
در این سناریو اگر در وسط ناکجاآباد هستید و یکی از لاستیک‌ها پنچر شد، فوراً توقف می‌کنید، جک را بیرون می‌کشید و لاستیک را با زاپاس یدک خود تعویض می‌کنید.
تبریک به شما!
در این حالت شما یک حادثه را توانستید خیلی سریع حلوفصل کنید. این یعنی به شمال می‌رسید! و به‌عبارتی سرویس قطع‌شده‌ی سفر شما (از یک نقطه‌به‌نقطه دیگر) به حالت عادی بازگشته و حال می‌توانید آسوده‌خاطر به راهتان ادامه دهید.
اما اگر بین راه یکی دیگر از لاستیک‌ها پنچر شد چه؟
تاکنون فقط افزونگی خرابی سیستم را کاهش داده‌اید ولی هرکدام از لاستیک‌های شما قادرند فاجعه به بارآورند.
دیگر کاری از دستتان ساخته نیست و بدتر آن‌که نمی‌توانید چشمتان را به‌روی دوتای دیگر که هنوز اتفاقی برایشان نیفتاده ببندید.
اینجا بحث یک مشکل به میان می‌آید اگرچه علت ریشه‌ای پنچری را نمی‌دانید ولی با کمی ارزیابی احساس می‌کنید که مشکل از صاف شدن لاستیک‌هاست. اما دانستن این کمک چندانی به شما نمی‌کند و کسی باید آن را حل کند چون از توانایی شما خارج است!
ازآنجایی‌که زاپاس ندارید برای حل این مشکل، یا از سفر بازمی‌مانید یا به دلیل حمل کردن خودرو توسط جرثقیل به تعمیرگاه با تأخیر فراوان می‌رسید.
به این، مشکل می‌گویند.
درهرصورت برای رفع مشکل پیش آمده، تا اتمام زمان رفع پنچری یا تعویض لاستیک باید منتظر بمانید!
در این حالت شاید شما حتی یک درخواست خدمت برای خرید سه لاستیک دیگر(با احتساب همانی که اول خراب شد و توی صندوق عقب است!) نیز ارائه دهید، البته اگر همه‌ی آنها نزدیک به خرابی باشند و البته اگر فرصت دیگری نباشد که با یار به شمال بروید! یعنی سه تا لاستیک نو از همانی که همکنون روی خودرو دارید سفارش می‌دهید یا می‌خرید.
به این، درخواست خدمت می‌گویند.
ولی اگر می‌خواهید جلوی یار پٌز دهید که نیاز به تعویض لاستیک دارید اما نه شبیه آن لاستیک‌های قبلی، ممکن است بخواهید لاستیک اسپرت و پهن و عریضی را روی خودرو بندازید و یا لنت و سیستم ترمز را تغییر دهید تا اینقدر لاستیک‌ها ساییده(!) نشود.
که در این حالت یک تغییر اتفاق می‌افتد.
و به این، تغییر می‌گویند.
این چهار تمرین کلیدی و پرکاربرد در ITIL برای ارائه خدمات عالی به مشتریان شما بسیار مهم هستند. درک تفاوت‌ها، شناسایی صحیح هر یک و حلوفصل مناسب هر یک از آنها، راهی برای بهبود اثربخشی میز خدمات شما خواهد بود.
