2. خیلی سریع و درست به کاربران اطلاع دهید.
در یک جهان ایده آل، شما باید یک لیست از افرادی که در صورت وقوع حادثه مهم باید مطلع شوند را همواره داشته باشید. موضوع اطلاع رسانی در ITIL یکی از سطرهای کلیدی در ماتریسRACI[2] است و البته شناسایی مخاطبین و ذینفعان و کاربران مرتبط با حادثه مورد نظر از طریق روابط[۳] بین آیتم های پیکربندی[۴] امکانپذیراست. (بشرط آنکه روابط بین اقلام پیکربندی را از قبل در سرویس دسک تعریف کرده باشید) با این حال، واقعیت این است که اغلب اطلاع رسانی دقیق و سریع به افراد مرتبط بسیار سخت است. بنابراین اطمینان حاصل نمایید که برای اطلاع رسانی به افراد مناسب، اطلاعات درست را در زمان مناسب- زمانی که یک حادثه عمده رخ می دهد- به اطلاع افراد مرتبط می رسانید. در یک وضعیت حادثه مهم، ممکن است مجبور شوید با بعضی یا حتی همه موارد زیر ارتباط برقرار کنید:
- مشتریان/کاربران عصبانی
- ذینفعان کسب و کار فرعی و مدیران ارائه خدمات
- تیم های فنی تحت فشار
- نهادهای نظارتی
مطمئن شوید که افراد مناسب با ذینفعان مرتبط صحبت می کنند. به عنوان مثال، در ارتباط با تطابق و تیم های حقوقی، اگر طرف مقابل شما یک ارایه دهنده یا پیمانکار خارجی است.
هنگام برقراری ارتباطات لازم مطمین شوید که اطلاعات پایه به اندازه کافی روشن و آسان قابل فهم هستند. اگر هر گونه اطلاعاتی راجب یک راه حل خاص در اختیار دارید، برای پیشبرد آن کار اطلاعات را با افراد مرتبط به اشتراک بگذارید.
هنگام ارتباط حوادث مهم مطمئن شوید که شامل موارد ذیل است:
- عنوان حادثه و مرجع رسیدگی
- تاثیر آن بر کسب و کار
- سرویس و پایگاه کاربری آسیب دیده
- هر گونه راه حل و یا اطلاعاتی برای خود خدمتی[۵] کاربران
- جزئیات تماس برای میز کار
- زمان بروز رسانی بعدی.
3. یک طرح عملی ایجاد کنید.
پشت سر هم به تیم پشتیبانی خود سر بزنید شبیه یک فرمانده عملیات همه چیز را تحت نظارت و کنترل داشته باشد و شروع به جمع آوری یک برنامه عملی کنید. اطمینان حاصل کنید که تمام تیم های کلیدی را جمع آوری کرده اید تا چیزی از دست نرود و همه چیز به سرعت در حال انجام است. سریع، کارآمد و مهربان باشید. به خاطر داشته باشید که افراد تحت تأثیر فشار این حادثه به شدت در استرس بسیاری به سر می برند و تزریق استرس بیشتر کاری جز افزایش نرخ خطاهای انسانی و دوباره کاری و دوباره کاری نیست بنابراین زمان[۶] بخرید یک زمان توافق شده با مشتریان و طبق آن پیش بروید هرگز چیزی ایده آل پیش نمی رود بنابراین در برخورد با ذینفعان مختلف و کارشناسان فنی نهایت تمرکز و واقع بینی را داشته باشید.
4. به طور مرتب چک کنید.
به روز رسانی منظم با تیم های پشتیبانی و کسب و کار را مرتبا بررسی نمایید. اگر شما متعهد به رعایت زمان توافق شده SLAهستید با افراد فنی جهت به روز رسانی ها ملاقات و جلساتی را ترتیب دهید مرتبا افراد را برای به روزرسانی ها تعقیب نکنید – زیرا شما به آنها در دور زدن فرایند مدیریت رویداد مهم (بخشی از عملیات مدیریت حادثه در ITIL 4) کمک می کنید و دخالت مستقیم در عملکرد تیم های مربوطه باعث سرخوردگی بیشتر و تاخیر در نتیجه نهایی خواهد شد.
5. تغییرات لازم را اعمال کنید.
هنگامی که یک حل و فصل شناسایی شده فردی را بگمارید تا آن را بررسی کند و برخی آزمایش اولیه انجام دهد. پس از اطمینان از بازخورد حل و فصل در فضای آزمایشگاهی یک تغییر اضطراری را مطرح و در صورت لزوم، درخواست را به یک هیئت مشاوره تغییر اضطراری (CAB) برای تایید اجرای تغییر ارسال نمایید. پیاده سازی تغییرات در هر سازمانی متفاوت است، بعضی از شرکت ها اجازه می دهند که یک تغییر به طور پیش فرض اجرا شود تا بلافاصله یک خرابی را تعمیر کند. برخی اوقات نیاز به یک نسخه فشرده از روند تغییر دارید – بنابراین هر کاری که برای صاف کردن راه تعمیرات می توانید انجام دهید ارایه نمایید.
6. به کاربران اطلاع دهید که حادثه را حل کرده اید.
بازهم اطلاع رسانی و این وزنه بسیار مهم در مدیریت حوادث ...
اطلاع رسانی به کاربران در هنگام بستن درخواست! را فراموش نکنید.
هنگامی که تعمیراتی را برای حل حادثه انجام داده اید، دقت کنید که تیم مربوطه بررسی های مناسب را انجام داده باشند و سپس با برخی از کاربران آسیب دیده تماس بگیرید تا اطمینان حاصل شود که همه چیز به درستی انجام شده و بخوبی کار می کند. زمانیکه تأیید کردید که همه چیز همان است که باید باشد، اطلاعیه نهایی را در مورد این حادثه منتشر و اعلام کنید که مشکل به کلی مرتفع شده و همه چیز خوب است.
7. درسی که از تعمیر این حادثه آموخته اید را ثبت و مستند کنید.
هنگامی که یک حادثه حل شد، پنج یا ده دقیقه طول می کشد تا کارشناسان اقدامات کلیدی و درسهایی که از این حادثه به دست آورده اند را یاد بگیرند. اکنون فراغ بال بیشتری دارید با خیال آسوده می توانید بررسی جامعتری داشته باشید و دقیقا مشخص کنید که علت وقوع چنین حادثه ای چه بود!؟ پس باید همه چیز را به تصویر بکشید رعایت این مرحله برای مدیریت مشکل و بهبود مستمر و مدیریت پایگاه دانش الزامی است بنابراین هنگامی که همه درگیر روزمرگی هستند و با BAU[7] خود دست و پنجه نرم می کنند، یک جلسه بررسی کوتاه را برنامه ریزی کنید. این می تواند در رابطه با مدیریت مشکل و بهبود مستمر مثمر ثمر واقع شود، زیرا حوادث مهم به تجزیه و تحلیل علت اصلی نیاز دارند و هدف از درس های بالقوه آموخته شده برای جلوگیری از وقوع این مسئله در آینده است. در این حال، قوانین مستندسازی را وضع کنید و یک مستند شفاف از این حادثه، اطلاعات ریشه ای اضافی و هر چیزی که برای جلوگیری از عود مجدد آن باید انجام شود را در محلی ثبت و ضبط کنید سپس برای بهبود مستمر و رفع سرچشمه علت وقع و جلوگیری از وقوع دوباره مشکل را در فرصتی مناسب برای همیشه ریشه کن کنید.
[۱] Incident Management
[۲] Responsibility-Accountability-Consulted-Informed
[۳] Relationships
[۴] CI- Configuration Item
[۵] Self Service
[۶] SLA
[۷] کسب و کارِ مرسوم» (Business as usual) به وضعیتی گفته میشود که یک سازمان مطابق رویههای بومی و مرسوم خود به فعالیت ادامه میدهد یعنی علیرغم وجود راهکار و یا حتی فراهم بودن بستر مورد نظر، باز نمی خواهد تن به تغییر وضعیت جدید بدهد!
[…] مقاله مرتبط: مدیریت کامل حوادث در ITSM […]
[…] مدیریت کامل حوادث در ITSM […]
[…] مدیریت کامل حوادث در ITSM […]
[…] مدیریت کامل حوادث در ITSM […]
[…] مدیریت کامل حوادث در ITSM […]
[…] مدیریت کامل حوادث در ابزار ITSM […]