نقش کارکنان فناوری اطلاعات در افزایش نرخ حوادث کاربران

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

مشکل کجاست؟

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

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

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

تصور کنید جنگلی آتش گرفته، خاموش کردن آتش با ابزار و هر راهکاری نظیر: (چند نفر حافظ دلسوز طبیعت، هواپیمای آب‌پاش، کپسول آتش‌نشانی و بیل!) یک چیز است و وجود علف‌های خشک و بادهای موافق که سبب سرعت سرایت و تشدید دامنه‌ی شعله‌ها می‌شود یک چیز دیگر. در هر صورت آتش در حال نابودی تک‌تک درختان است، ذغال شدن تنه‌ی درختان و چهره‌ی سیاه و دلگیر جنگلِ سوخته ماحصل این آتش جهنمی است.

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

اگر فناوری اطلاعات را یک جنگل در نظر بگیریم پس هر سرویس یک درخت است! حافظان دلسوز طبیعت، کارکنان پشتیبانی لایه‌ی پیشخوان هستند و هواپیما و کپسول و بیل و خاک، راهکارهای حل مشکل‌اند. راهکارهای شناخته شده برای مشکلات شناخته شده! اما وجود علف خشک در سطح زمین و باد موافق آتش، مشکلات ناشناخته است و به واقع برخورد با آن چندان امکانپذیر نیست. خُب چکنیم با چند بیل و چند تشت آب برویم سراغ آتش!؟

پاسخ، بله چون آتش در حال پیشرفت است!

نتیجه: سوختن اکثر درختان، آسیب دیدن حافظان طبیعت

اما پیش از این چه باید می‌کردیم که به این روز نیافتیم؟

باید ببینم چه کسی و چه چیزی این آتش را به راه انداخته و چرا!؟

چهار علت طبیعی اصلی برای آتش‌سوزی جنگل عبارتند از: آذرخش، فوران آتشفشانی، جرقه در اثر فروافتادن صخره‌ها و احتراق خودبخود اما دخالت و فعالیت‌های انسانی نظیر: روشن کردن آتش برای جوجه کباب و چایی ذغالی! جرقه‌های ماشین‌آلات و ته‌سیگارهای دورانداخته‌شده و آتش‌زدن بقایای محصولات کشاورزی بعنوان علل عمدی همیشه مطرح می‌شود!

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

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

مثال‌هایی از علل وقوع خرابی‌های طبیعی در فناوری اطلاعات می‌تواند مواردی نظیر: سوخته شدن پاور یک سیستم، کنده شدن سوکت کابل شبکه، هنگ کردن سرور، اتمام کارتریج پرینتر، عدم آموزش کاربر و … باشد

و علل عمدی می‌تواند شامل: تغییر پورت وب یک نرم‌افزار تحت وب، تغییر دسترسی به نرم‌افزار، انجام پالیسی‌های امنیتی جدید، تغییر منابع سخت‌افزاری یک سرور، تغییر روش ورود به فلان نرم‌افزار، تغییر سناریو پرینت سرور و….

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

در ITIL تمرین مدیریت حادثه یا Incident Management برای رفع رجوع همین موارد مطرح شده. هدف آن ثبت و رسیدگی به حوادث و به حالت نرمال درآوردن تغییر وضعیت یک سرویس معیوب به یک سرویس سالم است. اما باید دقت داشت که اگرچه این تمرین برای هر نوع علت خرابی اعم از عمدی یا طبیعی می‌تواند به کار گرفته شود اما ماهیت درست آن رسیدگی به علل طبیعی خرابی سرویس‌هاست.

پس شک نکنید اگر جلوی تغییرات ناآگاهانه، را نگیرید باعث و بانی تمام این خرابی‌ها و شعله‌ور شدن آتش به جان جنگل شمائید! پس بدون بررسی دقیق، بدون برنامه‌ی پشتیبان، بدون ارزیابی ریسک و خطرات آن و بدون اطلاع‌رسانی انجام هر تغییری یک امر غلط است و کسی که با نظر شخصی یا تصمیم فوری و بدون ملاحظه! مصّر به انجام آن است یعنی عمداً می‌خواهد آتشی برپا کند!  تردید نیست در اینصورت با صدها نیروی پشتیبان نیز از پس حجم خرابی‌ها برنخواهید آمد. بنابراین رویکرد مهم فناوری اطلاعات برای پرهیز از این موضوع استفاده از مدیریت تغییر صحیح است!

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

فراموش نکنید هیچ تغییری را کوچک نشمرید! یک تغییر به‌ظاهر کوچک می‌تواند منجر به فاجعه شود! همچنان که یک ته‌سیگار می‌تواند جنگلی را به آتش بکشد!

هادی احمدی

نوشته باعث بیشتر خرابی‌ها خودِ واحد فناوری اطلاعات است! اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

الگوریتم مدیریت خدمات و مولفه‌های خدمت

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

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

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

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

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

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

مبانی ITIL چیست؟

در نسخه ITIL4، از چرخه‌ی حیات خدمت به سمت زنجیره‌ی ارزش خدمت رسیدیم از فرایند به تمرین. این یعنی چه؟

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

اما در زنجیره‌ی ارزش، به عرض زمان اشاره می‌کند یعنی کیفیت عمر و اینکه از ماحصل زندگی کردن ما بعنوان یک انسان چه رسالتی مورد انتظار است ما برای چه هستم و هدف از ۱۰۰ سال زندگی کردن چه ارزشی به همراه دارد؟

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

وقتی یک خدمت طراحی می‌کنید که خرابی‌های پرینتر را پوشش دهد یعنی قصد دارید تا ارزش منفی (تاثیر بد خرابی‌ پرینتر در کسب و کار) را بدست آورید هرچند خدمات مربوط به پشتیبانی و خرابی در ظاهر ارزش مثبت خلق نمی‌کند اما شکی نیست کاهش ارزش نرخ خرابی یعنی کاهش ارزش منفی و کاهش ارزش منفی نیز یعنی ارزش مثبت

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

ادامه مطلب در صفحه بعد…

نوشته الگوریتم مدیریت خدمات و مولفه‌های خدمت اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

مدیریت کامل حوادث در ITSM

بهترین تمرینات برای حل موثر حوادث مهم در فناوری اطلاعات و ارتباطات

اگر مدیر انفورماتیک سازمانی هستید تشخیص اینکه چه حادثه ای بزرگ است و چه حادثه ای کوچک؟ و یا کدام اتفاق مهم است و چه اتفاقی عادی!؟ نیازمند بررسی موردی و تحقیقات پیرامونی بسیاری است همین بررسی موردی و تحقیقات پیرامونی بی تردید زمانبر خواهد بود شما با شناسایی سرویس ها و خدمات موثر و کلیدی سازمان براحتی از روی تاثیر حوادث بر کسب و کار به اهمیت و بزرگی آن پی خواهید برد و نیازی به بررسی دقیق تر برای تشخیص بزرگی هر حادثه ای ندارید مثلا از کار افتادن ماوس یک کاربر تاثیر آنچنانی روی کسب و کار سازمان نمی گذارد اما اگر وب سایت یا تنها درگاه ارتباط با مشتری سازمان از کار بیافتد یعنی فاجعه! محسوب می شود پس بنابراین پرداختن به حوادث مهم امری کلیدی در مدیریت حوادث[۱] است.

حوادث مهم، تنش زا هستند. اکثر حوادث مهم ناشی از سلسله تغییرات ناآگاهانه قبلی است! و گاهی نیز برای بار نخست است که اتفاق می افتد. بنابراین بزرگی یا مهم بودن یک حادثه به تأثیر آن بر روی کسب و کار باز می گردد.

اگرچه هر حادثه ای کوچکی و گاهاً به ظاهر کم اهمیت هم می تواند به سرعت یک تنش بسیار بزرگی را به دنبال داشته باشد. در جهان فناوری نیز یک حادثه یا وقفه ای چند لحظه ای می تواند کل عملکرد یک سازمان را زیر سوال ببرد بنابراین تمامی حوادثی که در روز در سازمان رخ می دهند هر کدام می توانند فاجعه ای به بار آورند و تنش زا باشند بخصوص حوادثی که به مسائل فناوری اطلاعات مربوط هستند زیرا این دست از حوادث مستقیما بر روند عملیات و نتایج تجاری هر کسب و کاری تأثیر منفی می گذارد. ITIL 4 این دست از حوادث را به عنوان “حادثه ای با تاثیر قابل توجه در کسب و کار، که نیاز به یک راه حل فوری دارد” تعریف می کند.

خیلی از تأثیراتی که بر کسب و کار احساس می شوند علاوه بر بار حیثیتی، بار مالی بهمراه دارد بنابراین حوادث مهم نه تنها دارایی های سازمان را به خطر می اندازد بلکه سبب تحمیل هزینه های بسیاری نیز خواهد کرد که یا از جیب می رود یا از آبرو!

مثلا کسب و کار یک فروشگاه اینترنتی یک وب سایت است! در دسترس نبودن وب سایت، هک شدن، کندی و… حتی در کسری از ثانیه یک تنش بسیار بزرگ است و یا اینکه نرم افزار تولید یک کارخانه لحظه ای از کار بیفتد یعنی فاجعه در تولید… پس اهمیت رسیدگی به چنین حوادثی در این نوع بسیار ضروری است.

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

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

در این مبحث، شیوه ای برای مدیریت حوادث تنش زا به طور موثر ارایه خواهم کرد که در بردارنده چندین نکته کلیدی برای مدیریت بهتر اتفاقات بزرگ است.

1. حقایق را بررسی کنید!

اولین کاری که هنگام برخورد با حوادث مهم باید انجام دهید این است که مطئمن شوید که همه حقایق را دارید بررسی می کنید برای این موضوع باید فهرستی از پرسشهای کلیدی را مطرح کنید و یافته های خود را در ارتباط با حادثه رخ داده شده مستند نمایید:

• چه تاثیری بر روی کسب و کار می گذارد؟
• چه خدماتی تحت تاثیر قرار می گیرد؟
• چه گروهی از کاربران تحت تاثیر قرار می گیرند؟ آیا بخش یا مکان مشخصی است یا کل کاربران سازمان متاثر از این حادثه هستند؟
• کدام گروه کارشناسان پشتیبانی متولی رسیدگی به این حادثه هستند؟ آیا ما افراد مناسب را درگیر کرده ایم؟
• آیا همه در امنیت هستند؟ اول از همه، مراقب کاربران خود باشید و اطمینان حاصل کنید که همه از خطر احتمالی دور هستند. به ویژه اگر این حادثه مربوط به چیزی مانند سرقت اطلاعات ژنراتور، تعمیر و نگهداری UPS، و یا چاه ارت.
• آیا باید تیم های پشتیبانی دیگر را آگاه کنیم؟
• این حادثه ناشی از چه اتفاقی است آیا ناشی از یک یا مجموعه ای از فعالیت های تغییرات قبلی است؟
• آیا پیش از این راهکار یا خطا شناخته شده و مستندی داشته ایم؟
• آیا برای رسیدگی و رفع حادثه به پشتیبانی شخص ثالث (نظیر پیمانکاران) نیاز داریم؟
• آیا باید به مشتریان پیشین نیز اطلاع دهیم؟
• آیا این حادثه ناشی از نقص امنیتی است و باید سطح امنیتی را افزایش دهیم؟
• آیا سرویس میز خدمت IT قادر به مقابله با حجم فعلی تماس های مرتبط است؟
• مدت زمان بازگردانی وضعیت فعلی به حالت عادی چقدر است؟
• زمان واقعی برای به روز رسانی چه هنگامی است؟

اصول اولیه را تحت پوشش قرار دهید تا از مسله بدقت آگاهی یابید و بتوانید به همه (یا حداقل) سؤالاتی که توسط مشتری (ها) و مدیریت ارشد از شما پرسیده خواهد شد، به درستی پاسخ دهید.

ادامه مطلب در صفحه بعد…

نوشته مدیریت کامل حوادث در ITSM اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

مستند ITIL4 در ۲۴ صفحه با پوشش تغییرات اولیه در چارچوب ITIL به قلم هادی احمدی تدوین و نگاشته شده از لینک زیر قادر به دانلود آن می باشید برای باز کردن فایل از رمز: www.medanet.ir از استفاده فرمایید.

[دانلود یافت نشد]، یک اختصار انگلیسی است به معنای: کتابخانه زیرساخت فناوری اطلاعات و در حقیقت چارچوبی مستند و تدوین شده از مجموعه ی تمرینات موفق برای مدیریت خدمات فناوری اطلاعات [۲](ITSM) است که بر هماهنگ کردن خدمات فناوری اطلاعات با نیازهای کسب و کار تمرکز دارد. این بدان معنا نیست که برای مدیریت خدمات فناوری اطلاعات فقط این چارچوب تدوین شده، خیر! چارچوب های بسیاری شبیه ITIL برای مدیریت و ارایه خدمات فناوری اطلاعات طراحی و تدوین شده اند که طبق آخرین گزارشات گارتنر[۳] ITIL محبوب ترین و پر استفاده ترین آنهاست.[۴]

در یک جمله، ITIL: بهترین تمرینات[۵]  برای مدیریت خدمات فناوری اطلاعات است!

بنابراین هدف کلی آن مدیریت خدمات انفورماتیک است (اگرچه اخیراً استفاده از این چارچوب برای کلیه مراکز و واحدهای خدماتی غیر انفورماتیکی سازمان ها هم پیشنهاد شده است!)  این چارچوب یک استاندارد نیست و سازمان شما، با یا بدون آن، ممیزی نخواهد شد به عبارتی اگر آنرا بکار نبرید کسی یا ناظری، سازمان شما را بازخواست نخواهد کرد و الزام و دستورالعملی اجرایی شبیه استاندارد ISO و… هم نیست بلکه شامل مجموعه ای از به روش هایی است که طی ۲۰ سال در جهان مورد استفاده قرار گرفته است. بنابراین ارزیابی انطباق پیاده سازی آن توسط هیچ شخص ثالث یا سازمان مستقلی انجام نخواهد شد و مدرک بین المللی ITIL نیز صرفاٌ برای افراد است نه سازمان ها!

این یعنی ITIL مستحب هست و واجب نیست! یعنی نبود آن مشکلی ایجاد نمی کند اما بودنش دنیایی مزایا برای سازمان ها بهمراه خواهد آورد و البته زمانی که آنرا پیاده سازی کنید آنزمان است که خواهید فهمید که در نبودش! چقدر مشکل داشتید!

“ITIL به سازمان کمک می کند تا به طور مساوی در (حادثه، مشکل، تغییر) مشارکت منظمی داشته باشند، فرآیندها را یکپارچه می کند تا جریان ارتباطی بسیار سریع تر، مختصر و کارآمدتری داشته باشید و با حفظ و افزایش سطح رضایتمندی مشتری/کاربر نهایی به نجات کسب و کار و سازمان می پردازد و در نهایت با بهبود مستمر، شما را همیشه رو به جلو پیش خواهد برد با ITIL به استقبال تغییرات تازه می روید و با مدیریت صحیح آن از خطرات آنها نیز به دور خواهید ماند ضمن اینکه ITIL برای خلق ارزش مثبت است.

 مسیر ITIL بهترین برای رسیدن به بهترین راه حل ها”

این چارچوب، همپوشانی بسیار گسترده ای دارد و تمام سازمان را تحت لوای خود قرار خوهد داد. فراموش نکنید که رسیدن به این نتایج مطلوب، دشوار نیست و تنها چیزی که باید توسط ITIL پوشش داده شود تا نتایج بهتر به دست آید. فهم کلی مدیریت است!

بیش از ۲۰ سال است که از بار نخستی که مفهومی برای مدیریت سامانه‌های اطلاعاتی یا ITIL ارایه شد می گذرد. در اوایل دهه ۸۰ میلادی شرکت IBM با ارایه مفهوم سیستم‌های اصلی به عنوان یک سیستم مدیریت برای سامانه‌های اطلاعاتی منتشر شد که بعدها به کتاب زرد معروف شد و همین مفاهیم طی ۲۰ سال پایه‌های کتابخانه زیربنایی فناوری اطلاعات را بنا نهاد از آن زمان تاکنون ۳ نسخه از ITIL می گذرد و اخیرا نیز نسخه چهارم به آن افزوده شد.

ادامه مطلب در صفحه بعد…

نوشته مستند ITIL4 اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.